Subject: Re: Comments on draft-ietf-krb-wg-kerberos-clarifications-00.txt

From: Sam Hartman <[email-masked]>
Date: 11 Mar 2002 14:37:04 -0500

>>>>> "John" == John Brezak <[email-masked]> writes:

    John> A few comments/nits: 1) Section 1.4.1 - 3rd paragraph - The
    John> server behavior is described, what about the KDC? For the
    John> KDC is the SHOULD a MUST?

No, I'd think a MUST NOT.  Authorization data can be used by a client
to restrict the use a ticket even if the KDC does not understand it.

There is a question of course about whether the TGS is a server or a
KDC.  I believe some of the things Cliff wants to do with
authorization data assume that a TGS normally passes it on.

I'm actually not sure I like the second paragraph there in 1.4.1.
Something very similar was in the text I sent to Cliff, although he
did clean it up a bit.  But on reflection, I'm not sure I actually
like the idea.  Tom, any comments?

    John> 2) Are we leaving anonymous tickets in?

No, I thought we agree to take them out.  Apparently no one got around
to doing so for this draft.

    John> 5) Section 3.6.1 - To remain compatible with MIT and
    John> Heimdal, the encrypted part of the KERB-CRED message in a
    John> GSSAPI initial context token is encrypted with the null
    John> enctype. Microsoft does use the null enctype when either
    John> des-cbc-crc or des-cbc-md5 is used to retain compat with
    John> other implementations. For rc4-hmac, the encrypted part of
    John> the kerb-cred is encrypted with rc4-hmac.

Note that Heimdal always encrypts and thus is not compatible with
released MIT code.  MIT code is being changed to accept either
encrypted or unencrypted messages to deal with this.
    John> 9) Section 5.2.7.4 - There is a comment about "not clear
    John> whether ETYPE-INFO or PW-SALT should take precedence if they
    John> conflict". I do not believe there is currently a case where
    John> they conflict. PW-SALT is only included in a pa-data of a
    John> AS-REP while ETYPE-INFO is ever only in the e-data of a
    John> KRB-ERROR. PW-SALT is only used when preauth is not
    John> required. I would like to see use of PW-SALT depricated
    John> because it can only tell you about a single salt value per
    John> enctype. In this case providing an ETYPE-INFO can be in a
    John> non-preauth case of an AS-REP and server the same purpose as
    John> the PW-SALT.

OK.  It certainly wasn't clear to use that you were forbidden to have
both a etype-info and a pw-salt in the same as-rep response.

    John> 10) Section 5.3.1 - "authorization-data" - The second
    John> paragraph implies that authorization-data carried in the
    John> Authenticator is added to the ticket in the case of the
    John> TGS-REQ. Is this correct?

Certainly the authorization data in the kdc-req is added.  I had
always thought the authorization data in the authenticator was only
for the TGS's use.

    John> 11) Section 5.4.1 - "CANONICALIZE" flag - How about this
    John> description instead - "The CANONICALIZE option indicates
    John> that the client will accept the return of a principal name
    John> different from the principal names in the request. This can
    John> apply to either the cname or sname fields. If the KDC does
    John> not support name-canonicalization, the option is ignored and
    John> the appropriate KDC_ERR_C_PRINCIPAL_UNKNOWN or
    John> KDC_ERR_S_PRINCIPAL_UNKNOWN error is returned.

Why do you think this is better than a reference to your draft?
    John> 15) Section 6.2 - Include a note about a KDC never returning
    John> a KRB_AP_ERR_REPEAT. It must always return a response to a
    John> request (regardless of transport mechanism).

    John> 16) Section 7.2 - NT-SMTP-NAME (7) and NT-ENTERPRISE (10)
    John> are both defined. NT-ENTERPRISE is used in
    John> Kerb-Referrals. What is NT-SMTP-NAME (7) used for?

Hmm, I thought this was from referals.  If not,  this may be unused.

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 11 Mar 2002 15:20:56 -0500

> authorization data assume that a TGS normally passes it on.

Hmmm, while I don't know what's best in this case, I think we should
have variations on AD-IF-RELEVANT to make a distinction between
"critical to the TGS" and "critical to the apps". Call these, say,
AD-IF-TGS-RELEVANT and AD-IF-AP-RELEVANT.

The semantics would be the same as AD-IF-RELEVANT but one would apply
only when the receiver is the TGS and the other only when the receiver
is an application.

I.e., an AD element inside an AD-IF-TGS-RELEVANT would be non-critical
for the TGS but critical for applications; an AD element inside
an AD-IF-AP-RELEVANT would be critical for the TGS but non-critical for
applications; an AD element inside an AD-IF-RELEVANT would be
non-critical to the TGS as well as to apps; and an AD element not
contained by any of the AD-IF-*RELEVANT containers would be critical to
the TGS *and* applications.

Cheers,

Nico
-- 
-DISCLAIMER: an automatically appended disclaimer may follow. By posting-
-to a public e-mail mailing list I hereby grant permission to distribute-
-and copy this message.-

Visit our website at http://www.ubswarburg.com

This message contains confidential information and is intended only 
for the individual named.  If you are not the named addressee you 
should not disseminate, distribute or copy this e-mail.  Please 
notify the sender immediately by e-mail if you have received this 
e-mail by mistake and delete this e-mail from your system.

E-mail transmission cannot be guaranteed to be secure or error-free 
as information could be intercepted, corrupted, lost, destroyed, 
arrive late or incomplete, or contain viruses.  The sender therefore 
does not accept liability for any errors or omissions in the contents 
of this message which arise as a result of e-mail transmission.  If 
verification is required please request a hard-copy version.  This 
message is provided for informational purposes and should not be 
construed as a solicitation or offer to buy or sell any securities or 
related financial instruments.

---

From: Sam Hartman <[email-masked]>
Date: 11 Mar 2002 15:58:18 -0500

I agree we need these semantics, but I suspect that the targeted for
application class probably already gives us this.
>>>>> "Nicolas" == Nicolas Williams <[email-masked]> writes:

    Nicolas> On Mon, Mar 11, 2002 at 02:37:04PM -0500, Sam Hartman
    >>  No, I'd think a MUST NOT.  Authorization data can be used by a
    >> client to restrict the use a ticket even if the KDC does not
    >> understand it.
    >> 
    >> There is a question of course about whether the TGS is a server
    >> or a KDC.  I believe some of the things Cliff wants to do with

    Nicolas> Hmmm, while I don't know what's best in this case, I
    Nicolas> think we should have variations on AD-IF-RELEVANT to make
    Nicolas> a distinction between "critical to the TGS" and "critical
    Nicolas> to the apps". Call these, say, AD-IF-TGS-RELEVANT and
    Nicolas> AD-IF-AP-RELEVANT.

    Nicolas> The semantics would be the same as AD-IF-RELEVANT but one
    Nicolas> would apply only when the receiver is the TGS and the
    Nicolas> other only when the receiver is an application.

    Nicolas> I.e., an AD element inside an AD-IF-TGS-RELEVANT would be
    Nicolas> non-critical for the TGS but critical for applications;
    Nicolas> an AD element inside an AD-IF-AP-RELEVANT would be
    Nicolas> critical for the TGS but non-critical for applications;
    Nicolas> an AD element inside an AD-IF-RELEVANT would be
    Nicolas> non-critical to the TGS as well as to apps; and an AD
    Nicolas> element not contained by any of the AD-IF-*RELEVANT
    Nicolas> containers would be critical to the TGS *and*
    Nicolas> applications.

    Nicolas> Cheers,

    Nicolas> Nico -- -DISCLAIMER: an automatically appended disclaimer
    Nicolas> may follow. By posting- -to a public e-mail mailing list
    Nicolas> I hereby grant permission to distribute- -and copy this
    Nicolas> message.-

    Nicolas> Visit our website at http://www.ubswarburg.com

    Nicolas> This message contains confidential information and is
    Nicolas> intended only for the individual named.  If you are not
    Nicolas> the named addressee you should not disseminate,
    Nicolas> distribute or copy this e-mail.  Please notify the sender
    Nicolas> immediately by e-mail if you have received this e-mail by
    Nicolas> mistake and delete this e-mail from your system.

    Nicolas> E-mail transmission cannot be guaranteed to be secure or
    Nicolas> error-free as information could be intercepted,
    Nicolas> corrupted, lost, destroyed, arrive late or incomplete, or
    Nicolas> contain viruses.  The sender therefore does not accept
    Nicolas> liability for any errors or omissions in the contents of
    Nicolas> this message which arise as a result of e-mail
    Nicolas> transmission.  If verification is required please request
    Nicolas> a hard-copy version.  This message is provided for
    Nicolas> informational purposes and should not be construed as a
    Nicolas> solicitation or offer to buy or sell any securities or
    Nicolas> related financial instruments.