Additional Kerberos Naming Constraints
RFC 6111

Note: This ballot was opened for revision 07 and is now closed.

(Tim Polk) Yes

(Jari Arkko) No Objection

(Ron Bonica) No Objection

(Stewart Bryant) No Objection

(Gonzalo Camarillo) No Objection

(Ralph Droms) No Objection

Comment (2010-10-05)
No email
send info
Section 3.1:

   If a well-known principal name is used as the client principal name
   or the server principal name but not supported, the Authentication
   Service (AS) [RFC4120] and the application server MUST reject the
   authentication attempt.

What does "not supported" mean here?  How does this behavior compare with the behavior of currently deployed ASs; i.e., will an AS implemented before this document was written reject the authentication attempt?

(Lars Eggert) No Objection

(Adrian Farrel) No Objection

(Alexey Melnikov) No Objection

Comment (2010-10-07)
No email
send info
In section 3.1: is the string "WELLKNOWN" case sensitive?

6.  IANA Considerations

   This document provides the framework for defining well-known Kerberos
   names and Kerberos realms.  A new IANA registry should be created to
   contain well-known Kerberos names and Kerberos realms that are
   defined based on this document.  The evaluation policy is
   "Specification Required".

This needs (at least) an Informative reference to RFC 5226.

(Dan Romascanu) No Objection

Comment (2010-10-05)
No email
send info
1. Please expand KDC at first occurence. 

2. In the Security Considerations section: 

> It is possible to have name collision with well-known names because
   Kerberos as defined in [RFC4120] does not reserve names that have
   special meanings, consequently care MUST be taken to avoid accidental
   reuse of names.

s/care MUST be taken to avoid accidental reuse of names/accidental reuse of names MUST be avoided/

(Peter Saint-Andre) No Objection

Comment (2010-10-05)
No email
send info
I would like to echo Ralph's comment: given that RFC 4120 does not have the concept of reserved names, this specification cannot legislate the behavior of applications that currently conform to RFC 4120 but not this specification. Furthermore, it would be helpful to describe the recommended behavior of a client that supports reserved names when it interacts with an authentication service or ticket granting service that does not support reserved names; for example, does the client need to discard the ticket it receives?

(Robert Sparks) No Objection

(Sean Turner) No Objection

Comment (2010-10-05)
No email
send info
1) Sec 1: It's odd that there's a 2119 requirement in the intro (before the requirements terminology).  Could this be reworked?

2) Sec 1: r/is to remedy/remedies

3) Sec 1: It would be nice to have some text that indicates say which parts of 4120 you're updating.  Section 6.1, 6.2, 7.5.7, and 7.5.8 right?  Side note: Interesting that in 4120 Section 6.2 uses NT-TYPENAME while 7.5.8 uses the prefix KRB and underscores instead of dashes (KRB_NT_TYPENAME).  Should KRB_NT_WELLKNOWN also be NT-WELLKNOWN?

4) Sec 3.1, 2nd para, 2nd sentence: r/must/MUST