doc: Add RFC documents

1 files changed, 899 insertions, 0 deletions

diff --git a/doc/rfc/rfc6112.txt b/doc/rfc/rfc6112.txt
new file mode 100644
index 0000000..b407759
--- /dev/null
+++ b/doc/rfc/rfc6112.txt
@@ -0,0 +1,899 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                            L. Zhu
+Request for Comments: 6112                                      P. Leach
+Updates: 4120, 4121, 4556                          Microsoft Corporation
+Category: Standards Track                                     S. Hartman
+ISSN: 2070-1721                                        Painless Security
+                                                              April 2011
+
+
+                     Anonymity Support for Kerberos
+
+Abstract
+
+   This document defines extensions to the Kerberos protocol to allow a
+   Kerberos client to securely communicate with a Kerberos application
+   service without revealing its identity, or without revealing more
+   than its Kerberos realm.  It also defines extensions that allow a
+   Kerberos client to obtain anonymous credentials without revealing its
+   identity to the Kerberos Key Distribution Center (KDC).  This
+   document updates RFCs 4120, 4121, and 4556.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc6112.
+
+Copyright Notice
+
+   Copyright (c) 2011 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+
+
+Zhu, et al.                  Standards Track                    [Page 1]
+
+RFC 6112               Kerberos Anonymity Support             April 2011
+
+
+   This document may contain material from IETF Documents or IETF
+   Contributions published or made publicly available before November
+   10, 2008.  The person(s) controlling the copyright in some of this
+   material may not have granted the IETF Trust the right to allow
+   modifications of such material outside the IETF Standards Process.
+   Without obtaining an adequate license from the person(s) controlling
+   the copyright in such materials, this document may not be modified
+   outside the IETF Standards Process, and derivative works of it may
+   not be created outside the IETF Standards Process, except to format
+   it for publication as an RFC or to translate it into languages other
+   than English.
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+   2.  Conventions Used in This Document  . . . . . . . . . . . . . .  3
+   3.  Definitions  . . . . . . . . . . . . . . . . . . . . . . . . .  3
+   4.  Protocol Description . . . . . . . . . . . . . . . . . . . . .  5
+     4.1.  Anonymity Support in AS Exchange . . . . . . . . . . . . .  5
+       4.1.1.  Anonymous PKINIT . . . . . . . . . . . . . . . . . . .  6
+     4.2.  Anonymity Support in TGS Exchange  . . . . . . . . . . . .  7
+     4.3.  Subsequent Exchanges and Protocol Actions Common to AS
+           and TGS for Anonymity Support  . . . . . . . . . . . . . .  9
+   5.  Interoperability Requirements  . . . . . . . . . . . . . . . . 10
+   6.  GSS-API Implementation Notes . . . . . . . . . . . . . . . . . 10
+   7.  PKINIT Client Contribution to the Ticket Session Key . . . . . 11
+     7.1.  Combining Two Protocol Keys  . . . . . . . . . . . . . . . 12
+   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 13
+   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
+   10. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 15
+   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
+     11.1. Normative References . . . . . . . . . . . . . . . . . . . 15
+     11.2. Informative References . . . . . . . . . . . . . . . . . . 16
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al.                  Standards Track                    [Page 2]
+
+RFC 6112               Kerberos Anonymity Support             April 2011
+
+
+1.  Introduction
+
+   In certain situations, the Kerberos [RFC4120] client may wish to
+   authenticate a server and/or protect communications without revealing
+   the client's own identity.  For example, consider an application that
+   provides read access to a research database and that permits queries
+   by arbitrary requesters.  A client of such a service might wish to
+   authenticate the service, to establish trust in the information
+   received from it, but might not wish to disclose the client's
+   identity to the service for privacy reasons.
+
+   Extensions to Kerberos are specified in this document by which a
+   client can authenticate the Key Distribution Center (KDC) and request
+   an anonymous ticket.  The client can use the anonymous ticket to
+   authenticate the server and protect subsequent client-server
+   communications.
+
+   By using the extensions defined in this specification, the client can
+   request an anonymous ticket where the client may reveal the client's
+   identity to the client's own KDC, or the client can hide the client's
+   identity completely by using anonymous Public Key Cryptography for
+   Initial Authentication in Kerberos (PKINIT) as defined in
+   Section 4.1.  Using the returned anonymous ticket, the client remains
+   anonymous in subsequent Kerberos exchanges thereafter to KDCs on the
+   cross-realm authentication path and to the server with which it
+   communicates.
+
+   In this specification, the client realm in the anonymous ticket is
+   the anonymous realm name when anonymous PKINIT is used to obtain the
+   ticket.  The client realm is the client's real realm name if the
+   client is authenticated using the client's long-term keys.  Note that
+   the membership of a realm can imply a member of the community
+   represented by the realm.
+
+   The interaction with Generic Security Service Application Program
+   Interface (GSS-API) is described after the protocol description.
+
+2.  Conventions Used in This Document
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC2119].
+
+3.  Definitions
+
+   The anonymous Kerberos realm name is defined as a well-known realm
+   name based on [RFC6111], and the value of this well-known realm name
+   is the literal "WELLKNOWN:ANONYMOUS".
+
+
+
+Zhu, et al.                  Standards Track                    [Page 3]
+
+RFC 6112               Kerberos Anonymity Support             April 2011
+
+
+   The anonymous Kerberos principal name is defined as a well-known
+   Kerberos principal name based on [RFC6111].  The value of the name-
+   type field is KRB_NT_WELLKNOWN [RFC6111], and the value of the name-
+   string field is a sequence of two KerberosString components:
+   "WELLKNOWN", "ANONYMOUS".
+
+   The anonymous ticket flag is defined as bit 16 (with the first bit
+   being bit 0) in the TicketFlags:
+
+           TicketFlags     ::= KerberosFlags
+             -- anonymous(16)
+             -- TicketFlags and KerberosFlags are defined in [RFC4120]
+
+   This is a new ticket flag that is used to indicate that a ticket is
+   an anonymous one.
+
+   An anonymous ticket is a ticket that has all of the following
+   properties:
+
+   o  The cname field contains the anonymous Kerberos principal name.
+
+   o  The crealm field contains the client's realm name or the anonymous
+      realm name.
+
+   o  The anonymous ticket contains no information that can reveal the
+      client's identity.  However, the ticket may contain the client
+      realm, intermediate realms on the client's authentication path,
+      and authorization data that may provide information related to the
+      client's identity.  For example, an anonymous principal that is
+      identifiable only within a particular group of users can be
+      implemented using authorization data and such authorization data,
+      if included in the anonymous ticket, would disclose the client's
+      membership of that group.
+
+   o  The anonymous ticket flag is set.
+
+   The anonymous KDC option is defined as bit 16 (with the first bit
+   being bit 0) in the KDCOptions:
+
+           KDCOptions      ::= KerberosFlags
+             -- anonymous(16)
+             -- KDCOptions and KerberosFlags are defined in [RFC4120]
+
+
+
+
+
+
+
+
+
+Zhu, et al.                  Standards Track                    [Page 4]
+
+RFC 6112               Kerberos Anonymity Support             April 2011
+
+
+   As described in Section 4, the anonymous KDC option is set to request
+   an anonymous ticket in an Authentication Service (AS) request or a
+   Ticket Granting Service (TGS) request.
+
+4.  Protocol Description
+
+   In order to request an anonymous ticket, the client sets the
+   anonymous KDC option in an AS request or a TGS request.
+
+   The rest of this section is organized as follows: it first describes
+   protocol actions specific to AS exchanges, then it describes those of
+   TGS exchanges.  These are then followed by the description of
+   protocol actions common to both AS and TGS and those in subsequent
+   exchanges.
+
+4.1.  Anonymity Support in AS Exchange
+
+   The client requests an anonymous ticket by setting the anonymous KDC
+   option in an AS exchange.
+
+   The Kerberos client can use the client's long-term keys, the client's
+   X.509 certificates [RFC4556], or any other pre-authentication data,
+   to authenticate to the KDC and requests an anonymous ticket in an AS
+   exchange where the client's identity is known to the KDC.
+
+   If the client in the AS request is anonymous, the anonymous KDC
+   option MUST be set in the request.  Otherwise, the KDC MUST return a
+   KRB-ERROR message with the code KDC_ERR_BADOPTION.
+
+   If the client is anonymous and the KDC does not have a key to encrypt
+   the reply (this can happen when, for example, the KDC does not
+   support PKINIT [RFC4556]), the KDC MUST return an error message with
+   the code KDC_ERR_NULL_KEY [RFC4120].
+
+   When policy allows, the KDC issues an anonymous ticket.  If the
+   client name in the request is the anonymous principal, the client
+   realm (crealm) in the reply is the anonymous realm, otherwise, the
+   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 name and the client
+   realm returned in the KDC-REP in subsequent message exchanges when
+   using the obtained anonymous ticket.
+
+   Care MUST be taken by the KDC not to reveal the client's identity in
+   the authorization data of the returned ticket when populating the
+   authorization data in a returned anonymous ticket.
+
+
+
+
+Zhu, et al.                  Standards Track                    [Page 5]
+
+RFC 6112               Kerberos Anonymity Support             April 2011
+
+
+   The AD-INITIAL-VERIFIED-CAS authorization data, as defined in
+   [RFC4556], contains the issuer name of the client certificate.  This
+   authorization is not applicable and MUST NOT be present in the
+   returned anonymous ticket when anonymous PKINIT is used.  When the
+   client is authenticated (i.e., anonymous PKINIT is not used), if it
+   is undesirable to disclose such information about the client's
+   identity, the AD-INITIAL-VERIFIED-CAS authorization data SHOULD be
+   removed from the returned anonymous ticket.
+
+   The client can use the client keys to mutually authenticate with the
+   KDC and request an anonymous Ticket Granting Ticket (TGT) in the AS
+   request.  In that case, the reply key is selected as normal,
+   according to Section 3.1.3 of [RFC4120].
+
+4.1.1.  Anonymous PKINIT
+
+   This sub-section defines anonymous PKINIT.
+
+   As described earlier in this section, the client can request an
+   anonymous ticket by authenticating to the KDC using the client's
+   identity; alternatively, without revealing the client's identity to
+   the KDC, the Kerberos client can request an anonymous ticket as
+   follows: the client sets the client name as the anonymous principal
+   in the AS exchange and provides 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.
+   Because the anonymous client does not have an associated asymmetric
+   key pair, the client MUST choose the Diffie-Hellman key agreement
+   method by filling in the Diffie-Hellman domain parameters in the
+   clientPublicValue [RFC4556].  This use of the anonymous client name
+   in conjunction with PKINIT is referred to as anonymous PKINIT.  If
+   anonymous PKINIT is used, the realm name in the returned anonymous
+   ticket MUST be the anonymous realm.
+
+   Upon receiving the anonymous PKINIT request from the client, the KDC
+   processes the request, according to Section 3.1.2 of [RFC4120].  The
+   KDC skips the checks for the client's signature and the client's
+   public key (such as the verification of the binding between the
+   client's public key and the client name), but performs otherwise
+   applicable checks, and proceeds as normal, according to [RFC4556].
+   For example, the AS MUST check if the client's Diffie-Hellman domain
+   parameters are acceptable.  The Diffie-Hellman key agreement method
+   MUST be used and the reply key is derived according to Section
+   3.2.3.1 of [RFC4556].  If the clientPublicValue is not present in the
+   request, the KDC MUST return a KRB-ERROR with the code
+   KDC_ERR_PUBLIC_KEY_ENCRYPTION_NOT_SUPPORTED [RFC4556].  If all goes
+   well, an anonymous ticket is generated, according to Section 3.1.3 of
+   [RFC4120], and PA_PK_AS_REP [RFC4556] pre-authentication data is
+
+
+
+Zhu, et al.                  Standards Track                    [Page 6]
+
+RFC 6112               Kerberos Anonymity Support             April 2011
+
+
+   included in the KDC reply, according to [RFC4556].  If the KDC does
+   not have an asymmetric key pair, it MAY reply anonymously or reject
+   the authentication attempt.  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.
+
+   Upon receipt of the KDC reply that contains an anonymous ticket and
+   PA_PK_AS_REP [RFC4556] pre-authentication data, the client can then
+   authenticate the KDC based on the KDC's signature in the
+   PA_PK_AS_REP.  If the KDC's signature is missing in the KDC reply
+   (the reply is anonymous), the client MUST reject the returned ticket
+   if it cannot authenticate the KDC otherwise.
+
+   A KDC that supports anonymous PKINIT MUST indicate the support of
+   PKINIT, according to Section 3.4 of [RFC4556].  In addition, such a
+   KDC MUST indicate support for anonymous PKINIT by including a padata
+   element of padata-type PA_PKINIT_KX and empty padata-value when
+   including PA-PK-AS-REQ in an error reply.
+
+   When included in a KDC error, PA_PKINIT_KX indicates support for
+   anonymous PKINIT.  As discussed in Section 7, when included in an AS-
+   REP, PA_PKINIT_KX proves that the KDC and client both contributed to
+   the session key for any use of Diffie-Hellman key agreement with
+   PKINIT.
+
+   Note that in order to obtain an anonymous ticket with the anonymous
+   realm name, the client MUST set the client name as the anonymous
+   principal in the request when requesting an anonymous ticket in an AS
+   exchange.  Anonymity PKINIT is the only way via which an anonymous
+   ticket with the anonymous realm as the client realm can be generated
+   in this specification.
+
+4.2.  Anonymity Support in TGS Exchange
+
+   The client requests an anonymous ticket by setting the anonymous KDC
+   option in a TGS exchange, and in that request the client can use a
+   normal Ticket Granting Ticket (TGT) with the client's identity, or an
+   anonymous TGT, or an anonymous cross-realm TGT.  If the client uses a
+   normal TGT, the client's identity is known to the TGS.
+
+   Note that the client can completely hide the client's identity in an
+   AS exchange using anonymous PKINIT, as described in the previous
+   section.
+
+
+
+
+
+
+
+Zhu, et al.                  Standards Track                    [Page 7]
+
+RFC 6112               Kerberos Anonymity Support             April 2011
+
+
+   If the ticket in the PA-TGS-REQ of the TGS request is an anonymous
+   one, the anonymous KDC option MUST be set in the request.  Otherwise,
+   the KDC MUST return a KRB-ERROR message with the code
+   KDC_ERR_BADOPTION.
+
+   When policy allows, the KDC issues an anonymous ticket.  If the
+   ticket in the TGS request is an anonymous one, the client name and
+   the client realm are copied from that ticket; otherwise, the ticket
+   in the TGS request is a normal ticket, the returned anonymous ticket
+   contains the client name as the anonymous principal and the client
+   realm as the true realm of the client.  In all cases, 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 name and the client realm returned in the KDC-REP in
+   subsequent message exchanges when using the obtained anonymous
+   ticket.
+
+   Care MUST be taken by the TGS not to reveal the client's identity in
+   the authorization data of the returned ticket.  When propagating
+   authorization data in the ticket or in the enc-authorization-data
+   field of the request, the TGS MUST ensure that the client
+   confidentiality is not violated in the returned anonymous ticket.
+   The TGS MUST process the authorization data recursively, according to
+   Section 5.2.6 of [RFC4120], beyond the container levels such that all
+   embedded authorization elements are interpreted.  The TGS SHOULD NOT
+   populate identity-based authorization data into an anonymous ticket
+   in that such authorization data typically reveals the client's
+   identity.  The specification of a new authorization data type MUST
+   specify the processing rules of the authorization data when an
+   anonymous ticket is returned.  If there is no processing rule defined
+   for an authorization data element or the authorization data element
+   is unknown, the TGS MUST process it when an anonymous ticket is
+   returned as follows:
+
+   o  If the authorization data element may reveal the client's
+      identity, it MUST be removed unless otherwise specified.
+
+   o  If the authorization data element, that could reveal the client's
+      identity, is intended to restrict the use of the ticket or limit
+      the rights otherwise conveyed in the ticket, it cannot be removed
+      in order to hide the client's identity.  In this case, the
+      authentication attempt MUST be rejected, and the TGS MUST return
+      an error message with the code KDC_ERR_POLICY.  Note this is
+      applicable to both critical and optional authorization data.
+
+
+
+
+
+
+Zhu, et al.                  Standards Track                    [Page 8]
+
+RFC 6112               Kerberos Anonymity Support             April 2011
+
+
+   o  If the authorization data element is unknown, the TGS MAY remove
+      it, or transfer it into the returned anonymous ticket, or reject
+      the authentication attempt, based on local policy for that
+      authorization data type unless otherwise specified.  If there is
+      no policy defined for a given unknown authorization data type, the
+      authentication MUST be rejected.  The error code is KDC_ERR_POLICY
+      when the authentication is rejected.
+
+   The AD-INITIAL-VERIFIED-CAS authorization data, as defined in
+   [RFC4556], contains the issuer name of the client certificate.  If it
+   is undesirable to disclose such information about the client's
+   identity, the AD-INITIAL-VERIFIED-CAS authorization data SHOULD be
+   removed from an anonymous ticket.
+
+   The TGS encodes the name of the previous realm into the transited
+   field, according to Section 3.3.3.2 of [RFC4120].  Based on local
+   policy, 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.  The unordered set of realms in the transited field, if
+   present, can reveal which realm may potentially be the realm of the
+   client or the realm that issued the anonymous TGT.  The anonymous
+   Kerberos realm name MUST NOT be present in the transited field of a
+   ticket.  The true name of the realm that issued the anonymous ticket
+   MAY be present in the transited field of a ticket.
+
+4.3.  Subsequent Exchanges and Protocol Actions Common to AS and TGS for
+      Anonymity Support
+
+   In both AS and TGS exchanges, the realm field in the KDC request is
+   always the realm of the target KDC, not the anonymous realm when the
+   client requests an anonymous ticket.
+
+   Absent other information, the KDC MUST NOT include any identifier in
+   the returned anonymous ticket that could reveal the client's identity
+   to the server.
+
+   Unless anonymous PKINIT is used, if a client requires anonymous
+   communication, then the client MUST check to make sure that the
+   ticket in the reply is actually anonymous by checking the presence of
+   the anonymous ticket flag in the flags field of the EncKDCRepPart.
+   This is because KDCs ignore unknown KDC options.  A KDC that does not
+   understand the anonymous KDC option will not return an error, but
+   will instead return a normal ticket.
+
+   The subsequent client and server communications then proceed as
+   described in [RFC4120].
+
+
+
+
+
+Zhu, et al.                  Standards Track                    [Page 9]
+
+RFC 6112               Kerberos Anonymity Support             April 2011
+
+
+   Note that the anonymous principal name and realm are only applicable
+   to the client in Kerberos messages, the server cannot be anonymous in
+   any Kerberos message per this specification.
+
+   A server accepting an anonymous service ticket may assume that
+   subsequent requests using the same ticket originate from the same
+   client.  Requests with different tickets are likely to originate from
+   different clients.
+
+   Upon receipt of an anonymous ticket, the transited policy check is
+   performed in the same way as that of a normal ticket if the client's
+   realm is not the anonymous realm; if the client realm is the
+   anonymous realm, absent other information any realm in the
+   authentication path is allowed by the cross-realm policy check.
+
+5.  Interoperability Requirements
+
+   Conforming implementations MUST support the anonymous principal with
+   a non-anonymous realm, and they MAY support the anonymous principal
+   with the anonymous realm using anonymous PKINIT.
+
+6.  GSS-API Implementation Notes
+
+   GSS-API defines the name_type GSS_C_NT_ANONYMOUS [RFC2743] to
+   represent the anonymous identity.  In addition, Section 2.1.1 of
+   [RFC1964] defines the single string representation of a Kerberos
+   principal name with the name_type GSS_KRB5_NT_PRINCIPAL_NAME.  The
+   anonymous principal with the anonymous realm corresponds to the GSS-
+   API anonymous principal.  A principal with the anonymous principal
+   name and a non-anonymous realm is an authenticated principal; hence,
+   such a principal does not correspond to the anonymous principal in
+   GSS-API with the GSS_C_NT_ANONYMOUS name type.  The [RFC1964] name
+   syntax for GSS_KRB5_NT_PRINCIPAL_NAME MUST be used for importing the
+   anonymous principal name with a non-anonymous realm name and for
+   displaying and exporting these names.  In addition, this syntax must
+   be used along with the name type GSS_C_NT_ANONYMOUS for displaying
+   and exporting the anonymous principal with the anonymous realm.
+
+   At the GSS-API [RFC2743] level, an initiator/client requests the use
+   of an anonymous principal with the anonymous realm by asserting the
+   "anonymous" flag when calling GSS_Init_Sec_Context().  The GSS-API
+   implementation MAY provide implementation-specific means for
+   requesting the use of an anonymous principal with a non-anonymous
+   realm.
+
+   GSS-API does not know or define "anonymous credentials", so the
+   (printable) name of the anonymous principal will rarely be used by or
+   relevant for the initiator/client.  The printable name is relevant
+
+
+
+Zhu, et al.                  Standards Track                   [Page 10]
+
+RFC 6112               Kerberos Anonymity Support             April 2011
+
+
+   for the acceptor/server when performing an authorization decision
+   based on the initiator name that is returned from the acceptor side
+   upon the successful security context establishment.
+
+   A GSS-API initiator MUST carefully check the resulting context
+   attributes from the initial call to GSS_Init_Sec_Context() when
+   requesting anonymity, because (as in the GSS-API tradition and for
+   backwards compatibility) anonymity is just another optional context
+   attribute.  It could be that the mechanism doesn't recognize the
+   attribute at all or that anonymity is not available for some other
+   reasons -- and in that case the initiator MUST NOT send the initial
+   security context token to the acceptor, because it will likely reveal
+   the initiators identity to the acceptor, something that can rarely be
+   "un-done".
+
+   Portable initiators are RECOMMENDED to use default credentials
+   whenever possible, and request anonymity only through the input
+   anon_req_flag [RFC2743] to GSS_Init_Sec_Context().
+
+7.  PKINIT Client Contribution to the Ticket Session Key
+
+   The definition in this section was motivated by protocol analysis of
+   anonymous PKINIT (defined in this document) in building tunneling
+   channels [RFC6113] and subsequent channel bindings.  In order to
+   enable applications of anonymous PKINIT to form channels, all
+   implementations of anonymous PKINIT need to meet the requirements of
+   this section.  There is otherwise no connection to the rest of this
+   document.
+
+   PKINIT is useful for constructing tunneling channels.  To ensure that
+   an attacker cannot create a channel with a given name, it is
+   desirable that neither the KDC nor the client unilaterally determine
+   the ticket session key.  To achieve that end, a KDC conforming to
+   this definition MUST encrypt a randomly generated key, called the KDC
+   contribution key, in the PA_PKINIT_KX padata (defined next in this
+   section).  The KDC contribution key is then combined with the reply
+   key to form the ticket session key of the returned ticket.  These two
+   keys are then combined using the KRB-FX-CF2 operation defined in
+   Section 7.1, where K1 is the KDC contribution key, K2 is the reply
+   key, the input pepper1 is American Standard Code for Information
+   Interchange (ASCII) [ASAX34] string "PKINIT", and the input pepper2
+   is ASCII string "KeyExchange".
+
+
+
+
+
+
+
+
+
+Zhu, et al.                  Standards Track                   [Page 11]
+
+RFC 6112               Kerberos Anonymity Support             April 2011
+
+
+   PA_PKINIT_KX      147
+     -- padata for PKINIT that contains an encrypted
+     -- KDC contribution key.
+
+   PA-PKINIT-KX  ::= EncryptedData -- EncryptionKey
+     -- Contains an encrypted key randomly
+     -- generated by the KDC (known as the KDC contribution key).
+     -- Both EncryptedData and EncryptionKey are defined in [RFC4120]
+
+   The PA_PKINIT_KX padata MUST be included in the KDC reply when
+   anonymous PKINIT is used; it SHOULD be included if PKINIT is used
+   with the Diffie-Hellman key exchange but the client is not anonymous;
+   it MUST NOT be included otherwise (e.g., when PKINIT is used with the
+   public key encryption as the key exchange).
+
+   The padata-value field of the PA-PKINIT-KX type padata contains the
+   DER [X.680] [X.690] encoding of the Abstract Syntax Notation One
+   (ASN.1) type PA-PKINIT-KX.  The PA-PKINIT-KX structure is an
+   EncryptedData.  The cleartext data being encrypted is the DER-encoded
+   KDC contribution key randomly generated by the KDC.  The encryption
+   key is the reply key and the key usage number is
+   KEY_USAGE_PA_PKINIT_KX (44).
+
+   The client then decrypts the KDC contribution key and verifies the
+   ticket session key in the returned ticket is the combined key of the
+   KDC contribution key and the reply key as described above.  A
+   conforming client MUST reject anonymous PKINIT authentication if the
+   PA_PKINIT_KX padata is not present in the KDC reply or if the ticket
+   session key of the returned ticket is not the combined key of the KDC
+   contribution key and the reply key when PA-PKINIT-KX is present in
+   the KDC reply.
+
+7.1.  Combining Two Protocol Keys
+
+   KRB-FX-CF2() combines two protocol keys based on the pseudo-random()
+   function defined in [RFC3961].
+
+   Given two input keys, K1 and K2, where K1 and K2 can be of two
+   different enctypes, the output key of KRB-FX-CF2(), K3, is derived as
+   follows:
+
+    KRB-FX-CF2(protocol key, protocol key, octet string,
+              octet string)  ->  (protocol key)
+
+    PRF+(K1, pepper1) -> octet-string-1
+    PRF+(K2, pepper2) -> octet-string-2
+    KRB-FX-CF2(K1, K2, pepper1, pepper2) ->
+           random-to-key(octet-string-1 ^ octet-string-2)
+
+
+
+Zhu, et al.                  Standards Track                   [Page 12]
+
+RFC 6112               Kerberos Anonymity Support             April 2011
+
+
+   Where ^ denotes the exclusive-OR operation.  PRF+() is defined as
+   follows:
+
+   PRF+(protocol key, octet string) -> (octet string)
+
+   PRF+(key, shared-info) -> pseudo-random( key,  1 || shared-info ) ||
+                pseudo-random( key, 2 || shared-info ) ||
+                pseudo-random( key, 3 || shared-info ) || ...
+
+   Here the counter value 1, 2, 3, and so on are encoded as a one-octet
+   integer.  The pseudo-random() operation is specified by the enctype
+   of the protocol key.  PRF+() uses the counter to generate enough bits
+   as needed by the random-to-key() [RFC3961] function for the
+   encryption type specified for the resulting key; unneeded bits are
+   removed from the tail.
+
+8.  Security Considerations
+
+   Since KDCs ignore unknown options, a client requiring anonymous
+   communication needs to make sure that the returned ticket is actually
+   anonymous.  This is because a KDC that does not understand the
+   anonymous option would not return an anonymous ticket.
+
+   By using the mechanism defined in this specification, the client does
+   not reveal the client's identity to the server but the client
+   identity may be revealed to the KDC of the server principal (when the
+   server principal is in a different realm than that of the client),
+   and any KDC on the cross-realm authentication path.  The Kerberos
+   client MUST verify the ticket being used is indeed anonymous before
+   communicating with the server, otherwise, the client's identity may
+   be revealed unintentionally.
+
+   In cases where specific server principals must not have access to the
+   client's identity (for example, an anonymous poll service), the KDC
+   can define server-principal-specific policy that ensures any normal
+   service ticket can NEVER be issued to any of these server principals.
+
+   If the KDC that issued an anonymous ticket were to maintain records
+   of the association of identities to an anonymous ticket, then someone
+   obtaining such records could breach the anonymity.  Additionally, the
+   implementations of most (for now all) KDC's respond to requests at
+   the time that they are received.  Traffic analysis on the connection
+   to the KDC will allow an attacker to match client identities to
+   anonymous tickets issued.  Because there are plaintext parts of the
+   tickets that are exposed on the wire, such matching by a third-party
+   observer is relatively straightforward.  A service that is
+   authenticated by the anonymous principals may be able to infer the
+
+
+
+
+Zhu, et al.                  Standards Track                   [Page 13]
+
+RFC 6112               Kerberos Anonymity Support             April 2011
+
+
+   identity of the client by examining and linking quasi-static protocol
+   information such as the IP address from which a request is received,
+   or by linking multiple uses of the same anonymous ticket.
+
+   Two mechanisms, the FAST facility with the hide-client-names option
+   in [RFC6113] 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 reused to minimize
+   ticket linking.
+
+   The client's real identity is not revealed when the client is
+   authenticated as the anonymous principal.  Application servers MAY
+   reject the authentication in order to, for example, prevent
+   information disclosure or as part of Denial of Service (DoS)
+   prevention.  Application servers MUST avoid accepting anonymous
+   credentials in situations where they must record the client's
+   identity; for example, when there must be an audit trail.
+
+9.  Acknowledgements
+
+   JK Jaganathan helped editing early revisions of this document.
+
+   Clifford Neuman contributed the core notions of this document.
+
+   Ken Raeburn reviewed the document and provided suggestions for
+   improvements.
+
+   Martin Rex wrote the text for GSS-API considerations.
+
+   Nicolas Williams reviewed the GSS-API considerations section and
+   suggested ideas for improvements.
+
+   Sam Hartman and Nicolas Williams were great champions of this work.
+
+   Miguel Garcia and Phillip Hallam-Baker reviewed the document and
+   provided helpful suggestions.
+
+   In addition, the following individuals made significant
+   contributions: Jeffrey Altman, Tom Yu, Chaskiel M Grundman, Love
+   Hornquist Astrand, Jeffrey Hutzelman, and Olga Kornievskaia.
+
+
+
+
+
+
+
+
+Zhu, et al.                  Standards Track                   [Page 14]
+
+RFC 6112               Kerberos Anonymity Support             April 2011
+
+
+10.  IANA Considerations
+
+   This document defines a new 'anonymous' Kerberos well-known name and
+   a new 'anonymous' Kerberos well-known realm based on [RFC6111].  IANA
+   has added these two values to the Kerberos naming registries that are
+   created in [RFC6111].
+
+11.  References
+
+11.1.  Normative References
+
+   [ASAX34]    American Standards Institute, "American Standard Code for
+               Information Interchange", ASA X3.4-1963, June 1963.
+
+   [RFC1964]   Linn, J., "The Kerberos Version 5 GSS-API Mechanism",
+               RFC 1964, June 1996.
+
+   [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
+               Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2743]   Linn, J., "Generic Security Service Application Program
+               Interface Version 2, Update 1", RFC 2743, January 2000.
+
+   [RFC3961]   Raeburn, K., "Encryption and Checksum Specifications for
+               Kerberos 5", RFC 3961, February 2005.
+
+   [RFC4120]   Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
+               Kerberos Network Authentication Service (V5)", RFC 4120,
+               July 2005.
+
+   [RFC4556]   Zhu, L. and B. Tung, "Public Key Cryptography for Initial
+               Authentication in Kerberos (PKINIT)", RFC 4556,
+               June 2006.
+
+   [RFC5652]   Housley, R., "Cryptographic Message Syntax (CMS)",
+               STD 70, RFC 5652, September 2009.
+
+   [RFC6111]   Zhu, L., "Additional Kerberos Naming Constraints",
+               RFC 6111, April 2011.
+
+   [X.680]     "Abstract Syntax Notation One (ASN.1): Specification of
+               Basic Notation", ITU-T Recommendation X.680: ISO/IEC
+               International Standard 8824-1:1998, 1997.
+
+   [X.690]     "ASN.1 encoding rules: Specification of Basic Encoding
+               Rules (BER), Canonical Encoding Rules (CER) and
+               Distinguished Encoding Rules (DER)", ITU-T Recommendation
+               X.690  ISO/IEC International Standard 8825-1:1998, 1997.
+
+
+
+Zhu, et al.                  Standards Track                   [Page 15]
+
+RFC 6112               Kerberos Anonymity Support             April 2011
+
+
+11.2.  Informative References
+
+   [RFC6113]   Hartman, S. and L. Zhu, "A Generalized Framework for
+               Kerberos Pre-Authentication", RFC 6113, April 2011.
+
+   [STARTTLS]  Josefsson, S., "Using Kerberos V5 over the Transport
+               Layer Security (TLS) protocol", Work in Progress,
+               August 2010.
+
+Authors' Addresses
+
+   Larry Zhu
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA  98052
+   US
+
+   EMail: larry.zhu@microsoft.com
+
+
+   Paul Leach
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA  98052
+   US
+
+   EMail: paulle@microsoft.com
+
+
+   Sam Hartman
+   Painless Security
+
+   EMail: hartmans-ietf@mit.edu
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al.                  Standards Track                   [Page 16]
+