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. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
