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

From: "John Brezak" <[email-masked]>
Date: Thu, 28 Feb 2002 17:43:46 -0800

A few comments/nits:

1) Section 1.4.1 - 3rd paragraph - The server behavior is described,
what about the KDC? For the KDC is the SHOULD a MUST?

2) Are we leaving anonymous tickets in?

3) Section 2.9 - text says "three additional options", but only 2 are
enumerated.

4) Section 3.1.4 - residual reference to "e-cksum".

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

6) Section5.2.1 - Is it necessary to suggest the use of CHOICE anymore?
I would suggest removing the 4th and 5th paragraphs.

7) Section 5.2.1 - Paragraph 8. As I understand it, there is no escape
sequence for using UTF-8 in GeneralString at all. So everything beyond
the 2nd sentence should be removed.

8) Section 5.2.7 - The padata-type for pa-etype-info should be 11 (not
10) in the table.

9) Section 5.2.7.4 - There is a comment about "not clear whether
ETYPE-INFO or PW-SALT should take precedence if they conflict". I do not
believe there is currently a case where they conflict. PW-SALT is only
included in a pa-data of a AS-REP while ETYPE-INFO is ever only in the
e-data of a KRB-ERROR. PW-SALT is only used when preauth is not
required. I would like to see use of PW-SALT depricated because it can
only tell you about a single salt value per enctype. In this case
providing an ETYPE-INFO can be in a non-preauth case of an AS-REP and
server the same purpose as the PW-SALT.

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

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

12) Section 5.4.1 - "till" - Since till is no longer optional, the text
implying that it is should be removed and the special value used for the
time included. I will find out what value Windows2000 uses for "maximum
till time allowed by realm".

13) Section 5.4.2 - padata - refers to section 6.3.2 - should be 5.2.7.3

14) Section 6.2 - Add note about when it is appropriate for the KDC to
return a KDC-ERR-BAD-PVNO error. I would recommend that it is never an
appropriate error especially given that we agree that the pvno field in
the messages is not useful. So anything other than "5" is a badly formed
request and should be dropped.

15) Section 6.2 - Include a note about a KDC never returning a
KRB_AP_ERR_REPEAT. It must always return a response to a request
(regardless of transport mechanism).

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

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
John Brezak                       * mailto:[email-masked]
Microsoft Corporation        * 425-706-2602
One Microsoft Way
Redmond, WA 98052