Additional Kerberos Naming Constraints
RFC 6111

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

Lars Eggert No Objection

(Tim Polk; former steering group member) Yes

(Adrian Farrel; former steering group member) No Objection

(Alexey Melnikov; former steering group member) No Objection

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; former steering group member) No Objection

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/

(Gonzalo Camarillo; former steering group member) No Objection

(Jari Arkko; former steering group member) No Objection

(Peter Saint-Andre; former steering group member) No Objection

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?

(Ralph Droms; former steering group member) No Objection

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?

(Robert Sparks; former steering group member) No Objection

(Ron Bonica; former steering group member) No Objection

(Sean Turner; former steering group member) No Objection

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

(Stewart Bryant; former steering group member) No Objection