Protocol Action: 'Additional Kerberos Naming Constraints' to Proposed Standard

[The IESG <[e-mail]>]

The IESG has approved the following document:
- 'Additional Kerberos Naming Constraints'
  <draft-ietf-krb-wg-naming-07.txt> as a Proposed Standard

This document is the product of the Kerberos Working Group.

The IESG contact persons are Tim Polk and Sean Turner.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ietf-krb-wg-naming/



Technical Summary

  This document defines new naming constraints for well-known Kerberos
  principal name and well-known Kerberos realm names.  This document
  updates RFC4120.

Working Group Summary

  This document represents the consensus of the Kerberos Working Group.

Document Quality

  This document defines the syntax of well-known Kerberos principal
  and realm names, which may be used by future protocol extensions
  or in other cases where a name with special meaning is required.
  The Kerberos Working Group is currently considering at least one
  extension which will define such names.

Personnel

   Jeffrey Hutzelman is the Document Shepherd.  Tim Polk is the 
   Responsible Area Director.

RFC Editor Note

s/Jeffery/Jeffrey/

 In Section 1:
 OLD:
    This document is to remedy these issues by defining well-known
    Kerberos names and the protocol behavior when a well-known name is
    used but not supported.
 NEW:
    This document remedies these issues by defining well-known
    Kerberos names and the protocol behavior when a well-known name is
    used but not supported.

 OLD:
    In the case of the anonymity support, it is critical that
    deployed Kerberos implementations that do not support anonymity MUST
    fail the authentication if the anonymity name pair is used, therefore
    no access is granted accidentally to a principal who's name happens
    to match with that of the anonymous identity.
 NEW:
    In the case of the anonymity support, it is critical that
    deployed Kerberos implementations that do not support anonymity
    fail the authentication if the anonymity name pair is used, therefore
    no access is granted accidentally to a principal who's name happens
    to match with that of the anonymous identity.
 (deleting the word "MUST")


 In Section 3.1 (case change):
 OLD:
    A well-known principal name MUST have at least two or more
    KerberosString components, and the first component must be the string
    literal "WELLKNOWN".
 NEW:
    A well-known principal name MUST have at least two or more
    KerberosString components, and the first component MUST be the string
    literal "WELLKNOWN".

 Also in Section 3.1, replace "KDC" by "Key Distribution Center (KDC)".

 In Section 4:
 OLD:
    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.

 NEW:
    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, accidental reuse of names MUST be avoided.

 In Section 6:
 OLD:
    "Specification Required".
 NEW:
    "Specification Required", as specified in [RFC5226]

 In Section 7.1, add the following normative reference:

    [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
               IANA Considerations Section in RFCs", BCP 26, RFC 5226,
               May 2008.