Additional Kerberos Naming Constraints
draft-ietf-krb-wg-naming-07

[Ballot comment]
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.

[Ballot comment]
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?

[Ballot comment]
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/

[Ballot comment]
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

[Ballot comment]
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?

waiting for draft-ietf-krb-anon before initiating IESG evaluation.  WG chairs determined that a
second IETF Last Call is not needed - the changes are in -anon, which is getting a second Last Call

IANA Last Call comments:

Upon approval of this document, the IANA will create the following
registry "Well Known Kerberos Names" located at
http://www.iana.org/assignments/TBD

Registration Policy: Specification Required
Initial contents of this registry will be:

Well Known Principal Names Reference
-------------------------- --------------------


Well Known Realm Names Reference
---------------------- --------------------


We understand the above to be the only IANA Action for this
document.