Protocol Action: 'Anonymity Support for Kerberos' to Proposed Standard

[The IESG <[e-mail]>]

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.