The IESG has approved the following document: - 'Anonymity Support for Kerberos' <draft-ietf-krb-wg-anon-12.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-anon/ Technical Summary This document defines extensions to the Kerberos protocol for the Kerberos client to authenticate the Kerberos Key Distribution Center and the Kerberos server, without revealing the client's identity. These extensions can be used to secure communication between the anonymous client and the server. This document updates RFC4120. Working Group Summary This document represents the consensus of the Kerberos Working Group. Document Quality This document extends the Kerberos protocol to provide new features for use when the client does not wish to reveal its identity to an application server. At least one vendor has indicated intent to implement this feature in their Kerberos clients and servers and to make use of it for some applications. It is also referenced in other ongoing work in the IETF. Personnel Jeffrey Hutzelman is the Document Shepherd. Tim Polk is the Responsible Area Director. RFC Editor Note Please make the following changes prior to publication: In Section 4 (a/an): OLD: In order to request an anonymous ticket, the client sets the anonymous KDC option in an AS request or an TGS request. NEW: In order to request an anonymous ticket, the client sets the anonymous KDC option in an AS request or a TGS request. In Section 4.1: OLD: client realm is the realm of the AS. According to [RFC4120] the client name and the client realm in the EncTicketPart of the reply MUST match with the corresponding client name and the client realm of the anonymous ticket in the reply; the client MUST use the client NEW: client realm is the realm of the AS. According to [RFC4120] the client name and the client realm in the EncTicketPart of the reply MUST match with the corresponding client name and the client realm of the KDC reply; the client MUST use the client In Section 4.1.1, graf 1: s/anonymity/anonymous/ In Section 4.1.1, graf 2 (wording and 3852/5652 reference update): OLD: the client sets the client name as the anonymous principal in the AS exchange and provides a PA_PK_AS_REQ pre-authentication data [RFC4556] where both the signerInfos field and the certificates field of the SignedData [RFC3852] of the PA_PK_AS_REQ are empty. NEW: the client sets the client name as the anonymous principal in the AS exchange and provides a PA_PK_AS_REQ pre-authentication data [RFC4556] where the signerInfos field of the SignedData [RFC5652] of the PA_PK_AS_REQ is empty, and the certificates field is absent. And again, in Section 4.1.1, graf 3: OLD: If the KDC replies anonymously, both the signerInfos field and the certificates field of the SignedData [RFC3852] of PA_PK_AS_REP in the reply are empty. The server name in the anonymous KDC reply contains the name of the TGS. NEW: If the KDC replies anonymously, the signerInfos field of the SignedData [RFC5652] of PA_PK_AS_REP in the reply is empty, and the certificates field is absent. The server name in the anonymous KDC reply contains the name of the TGS. In Section 4.2 (commas): OLD: the TGS MAY omit the previous realm if the cross realm TGT is an anonymous one in order to hide the authentication path of the client. NEW: the TGS MAY omit the previous realm, if the cross realm TGT is an anonymous one, in order to hide the authentication path of the client. In Section 4.3, graf 7, s/preformed/performed/ In Section 8, graf 3: s/insure/ensures/ In Section 8, before graf 5, insert: Two mechanisms, the FAST facility with the hide-client-names option in [FAST] and the Kerberos5 starttls option [STARTTLS protect the client identity so that an attacker would never be able to observe the client identity sent to the KDC. Transport or network layer security between the client and the server will help prevent tracking of a particular ticket to link a ticket to a user. In addition, clients can limit how often a ticket is re-used to minimize ticket linking. In Section 11.1: OLD: [RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852, July 2004. NEW: [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 5652, September 2009. Also in Section 11.1, add the following normative references: [X680] Abstract Syntax Notation One (ASN.1): Specification of Basic Notation, ITU-T Recommendation X.680 (1997) | ISO/IEC International Standard 8824-1:1998. [X690] ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER), ITU-T Recommendation X.690 (1997)| ISO/IEC International Standard 8825-1:1998. In Section 11.2, add the following informative reference (note this document has already been approved by the IESG) [STARTTLS] Josefsson, S., "Using Kerberos V5 over the Transport Layer Security (TLS) Protocol", draft-josefsson-kerberos5-starttls (work in progress), 2010. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
