doc: Add RFC documents

1 files changed, 1011 insertions, 0 deletions

diff --git a/doc/rfc/rfc8062.txt b/doc/rfc/rfc8062.txt
new file mode 100644
index 0000000..c3eaf1c
--- /dev/null
+++ b/doc/rfc/rfc8062.txt
@@ -0,0 +1,1011 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                            L. Zhu
+Request for Comments: 8062                                      P. Leach
+Obsoletes: 6112                                    Microsoft Corporation
+Updates: 4120, 4121, 4556                                     S. Hartman
+Category: Standards Track                              Hadron Industries
+ISSN: 2070-1721                                            S. Emery, Ed.
+                                                                  Oracle
+                                                           February 2017
+
+
+                     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.  This document obsoletes
+   RFC 6112 and reclassifies that document as Historic.  RFC 6112
+   contained errors, and the protocol described in that specification is
+   not interoperable with any known implementation.  This specification
+   describes a protocol that interoperates with multiple
+   implementations.
+
+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 7841.
+
+   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/rfc8062.
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al.                  Standards Track                    [Page 1]
+
+RFC 8062               Kerberos Anonymity Support          February 2017
+
+
+Copyright Notice
+
+   Copyright (c) 2017 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.
+
+   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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al.                  Standards Track                    [Page 2]
+
+RFC 8062               Kerberos Anonymity Support          February 2017
+
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
+     1.1.  Changes since RFC 6112  . . . . . . . . . . . . . . . . .   4
+   2.  Conventions Used in This Document . . . . . . . . . . . . . .   4
+   3.  Definitions . . . . . . . . . . . . . . . . . . . . . . . . .   4
+   4.  Protocol Description  . . . . . . . . . . . . . . . . . . . .   6
+     4.1.  Anonymity Support in AS Exchange  . . . . . . . . . . . .   6
+       4.1.1.  Anonymous PKINIT  . . . . . . . . . . . . . . . . . .   7
+     4.2.  Anonymity Support in TGS Exchange . . . . . . . . . . . .   8
+     4.3.  Subsequent Exchanges and Protocol Actions Common to AS
+           and TGS for Anonymity Support . . . . . . . . . . . . . .  10
+   5.  Interoperability Requirements . . . . . . . . . . . . . . . .  11
+   6.  GSS-API Implementation Notes  . . . . . . . . . . . . . . . .  11
+   7.  PKINIT Client Contribution to the Ticket Session Key  . . . .  12
+     7.1.  Combining Two Protocol Keys . . . . . . . . . . . . . . .  14
+   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  14
+   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  15
+   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  16
+     10.1.  Normative References . . . . . . . . . . . . . . . . . .  16
+     10.2.  Informative References . . . . . . . . . . . . . . . . .  17
+   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  17
+   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  18
+
+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
+
+
+
+
+Zhu, et al.                  Standards Track                    [Page 3]
+
+RFC 8062               Kerberos Anonymity Support          February 2017
+
+
+   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
+   a membership in 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.
+
+   This specification replaces [RFC6112] to correct technical errors in
+   that specification.  RFC 6112 is classified as Historic;
+   implementation of RFC 6112 is NOT RECOMMENDED.  All known
+   implementations comply with this specification and not RFC 6112.
+
+1.1.  Changes since RFC 6112
+
+   In Section 7, the pepper2 string "KeyExchange" used in RFC 6112 is
+   corrected to appear in all capital letters to comply with the string
+   actually used by implementations.
+
+   The requirement for the anonymous option to be used when an anonymous
+   ticket is used in a Ticket-Granting Service (TGS) request is reduced
+   from a MUST to a SHOULD.  At least one implementation does not
+   require this; it is not necessary that both the anonymous option and
+   anonymous ticket be used as an indicator of request type.
+
+   The authorization data type name "AD-INITIAL-VERIFIED-CAS" used in
+   RFC 6112 is corrected to appear as "AD_INITIAL_VERIFIED_CAS" in this
+   document.
+
+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 4]
+
+RFC 8062               Kerberos Anonymity Support          February 2017
+
+
+   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" and "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 as being in a particular group of users can be
+      implemented using authorization data.  Such authorization data, if
+      included in the anonymous ticket, would disclose that the client
+      is a member of the group observed.
+
+   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]
+
+   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.
+
+
+
+
+
+Zhu, et al.                  Standards Track                    [Page 5]
+
+RFC 8062               Kerberos Anonymity Support          February 2017
+
+
+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 request 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.  As specified by [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.
+
+   The KDC MUST NOT reveal the client's identity in the authorization
+   data of the returned ticket when populating the authorization data in
+   a returned anonymous ticket.
+
+   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
+
+
+
+Zhu, et al.                  Standards Track                    [Page 6]
+
+RFC 8062               Kerberos Anonymity Support          February 2017
+
+
+   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's key 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
+   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
+
+
+
+
+Zhu, et al.                  Standards Track                    [Page 7]
+
+RFC 8062               Kerberos Anonymity Support          February 2017
+
+
+   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.  Anonymous 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, 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.
+
+   If the ticket in the PA-TGS-REQ of the TGS request is an anonymous
+   one, the anonymous KDC option SHOULD be set in the request.
+
+
+
+
+
+
+
+Zhu, et al.                  Standards Track                    [Page 8]
+
+RFC 8062               Kerberos Anonymity Support          February 2017
+
+
+   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.
+
+   The TGS MUST NOT 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.
+
+   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.
+
+
+
+Zhu, et al.                  Standards Track                    [Page 9]
+
+RFC 8062               Kerberos Anonymity Support          February 2017
+
+
+   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].
+
+   Note that the anonymous principal name and realm are only applicable
+   to the client in Kerberos messages, and 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.
+
+
+
+
+Zhu, et al.                  Standards Track                   [Page 10]
+
+RFC 8062               Kerberos Anonymity Support          February 2017
+
+
+   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
+   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.
+
+
+
+
+
+
+
+
+Zhu, et al.                  Standards Track                   [Page 11]
+
+RFC 8062               Kerberos Anonymity Support          February 2017
+
+
+   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 initiator's identity to the acceptor, something that can rarely
+   be "undone".
+
+   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 secure
+   channels [RFC6113] and subsequent channel bindings [RFC5056].  In
+   order to enable applications of anonymous PKINIT to form secure
+   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 secure channels.  To ensure that an
+   active attacker cannot create separate channels to the client and KDC
+   with the same known key, it is desirable that neither the KDC nor the
+   client unilaterally determine the ticket session key.  The specific
+   reason why the ticket session key is derived jointly is discussed at
+   the end of this section.  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 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 US-ASCII [ANSI.X3-4] string "PKINIT", and
+   the input pepper2 is US-ASCII string "KEYEXCHANGE".
+
+   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]
+
+
+
+Zhu, et al.                  Standards Track                   [Page 12]
+
+RFC 8062               Kerberos Anonymity Support          February 2017
+
+
+   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 that
+   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.
+
+   This protocol provides a binding between the party that generated the
+   session key and the Diffie-Hellman exchange used to generate the
+   reply key.  Hypothetically, if the KDC did not use PA-PKINIT-KX, the
+   client and KDC would perform a Diffie-Hellman key exchange to
+   determine a shared key, and that key would be used as a reply key.
+   The KDC would then generate a ticket with a session key encrypting
+   the reply with the Diffie-Helman agreement.  A man-in-the-middle
+   (MITM) attacker would just decrypt the session key and ticket using
+   the Diffie-Hellman key from the attacker-KDC Diffie-Hellman exchange
+   and re-encrypt it using the key from the attacker-client Diffie-
+   Hellman exchange, while keeping a copy of the session key and ticket.
+   This protocol binds the ticket to the Diffie-Hellman exchange and
+   prevents the MITM attack by requiring the session key to be created
+   in a way that can be verified by the client.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al.                  Standards Track                   [Page 13]
+
+RFC 8062               Kerberos Anonymity Support          February 2017
+
+
+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)
+
+   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's
+   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.
+
+
+
+Zhu, et al.                  Standards Track                   [Page 14]
+
+RFC 8062               Kerberos Anonymity Support          February 2017
+
+
+   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 the 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) KDCs 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
+   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 [RFC6251], 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.  IANA Considerations
+
+   This document defines an 'anonymous' Kerberos well-known name and an
+   'anonymous' Kerberos well-known realm based on [RFC6111].  IANA has
+   updated these two entries in the "Well-Known Kerberos Principal
+   Names" and "Well-Known Kerberos Realm Names" registries,
+   respectively, to refer to this document.
+
+   In addition, IANA has updated the reference for PA_PKINIT_KX (147) in
+   the "Pre-authentication and Typed Data" registry to refer to this
+   document.
+
+
+
+Zhu, et al.                  Standards Track                   [Page 15]
+
+RFC 8062               Kerberos Anonymity Support          February 2017
+
+
+10.  References
+
+10.1.  Normative References
+
+   [ANSI.X3-4]
+              American National Standards Institute, "Coded Character
+              Set - 7-bit American Standard Code for Information
+              Interchange", ANSI X3-4, 1986.
+
+   [RFC1964]  Linn, J., "The Kerberos Version 5 GSS-API Mechanism",
+              RFC 1964, DOI 10.17487/RFC1964, June 1996,
+              <http://www.rfc-editor.org/info/rfc1964>.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119,
+              DOI 10.17487/RFC2119, March 1997,
+              <http://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC2743]  Linn, J., "Generic Security Service Application Program
+              Interface Version 2, Update 1", RFC 2743,
+              DOI 10.17487/RFC2743, January 2000,
+              <http://www.rfc-editor.org/info/rfc2743>.
+
+   [RFC3961]  Raeburn, K., "Encryption and Checksum Specifications for
+              Kerberos 5", RFC 3961, DOI 10.17487/RFC3961, February
+              2005, <http://www.rfc-editor.org/info/rfc3961>.
+
+   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
+              Kerberos Network Authentication Service (V5)", RFC 4120,
+              DOI 10.17487/RFC4120, July 2005,
+              <http://www.rfc-editor.org/info/rfc4120>.
+
+   [RFC4556]  Zhu, L. and B. Tung, "Public Key Cryptography for Initial
+              Authentication in Kerberos (PKINIT)", RFC 4556,
+              DOI 10.17487/RFC4556, June 2006,
+              <http://www.rfc-editor.org/info/rfc4556>.
+
+   [RFC5652]  Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
+              RFC 5652, DOI 10.17487/RFC5652, September 2009,
+              <http://www.rfc-editor.org/info/rfc5652>.
+
+   [RFC6111]  Zhu, L., "Additional Kerberos Naming Constraints",
+              RFC 6111, DOI 10.17487/RFC6111, April 2011,
+              <http://www.rfc-editor.org/info/rfc6111>.
+
+   [RFC6112]  Zhu, L., Leach, P., and S. Hartman, "Anonymity Support for
+              Kerberos", RFC 6112, DOI 10.17487/RFC6112, April 2011,
+              <http://www.rfc-editor.org/info/rfc6112>.
+
+
+
+Zhu, et al.                  Standards Track                   [Page 16]
+
+RFC 8062               Kerberos Anonymity Support          February 2017
+
+
+   [X.680]    International Telecommunications Union, "Information
+              technology - 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]    International Telecommunications Union, "Information
+              technology - 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.
+
+10.2.  Informative References
+
+   [RFC5056]  Williams, N., "On the Use of Channel Bindings to Secure
+              Channels", RFC 5056, DOI 10.17487/RFC5056, November 2007,
+              <http://www.rfc-editor.org/info/rfc5056>.
+
+   [RFC6113]  Hartman, S. and L. Zhu, "A Generalized Framework for
+              Kerberos Pre-Authentication", RFC 6113,
+              DOI 10.17487/RFC6113, April 2011,
+              <http://www.rfc-editor.org/info/rfc6113>.
+
+   [RFC6251]  Josefsson, S., "Using Kerberos Version 5 over the
+              Transport Layer Security (TLS) Protocol", RFC 6251,
+              DOI 10.17487/RFC6251, May 2011,
+              <http://www.rfc-editor.org/info/rfc6251>.
+
+Acknowledgments
+
+   JK Jaganathan helped edit early draft revisions of RFC 6112.
+
+   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 the 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.
+
+
+
+
+
+
+Zhu, et al.                  Standards Track                   [Page 17]
+
+RFC 8062               Kerberos Anonymity Support          February 2017
+
+
+   In addition, the following individuals made significant
+   contributions: Jeffrey Altman, Tom Yu, Chaskiel M. Grundman, Love
+   Hornquist Astrand, Jeffrey Hutzelman, and Olga Kornievskaia.
+
+   Greg Hudson and Robert Sparks provided helpful text in this document.
+
+Authors' Addresses
+
+   Larry Zhu
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA  98052
+   United States of America
+
+   Email: larry.zhu@microsoft.com
+
+
+   Paul Leach
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA  98052
+   United States of America
+
+   Email: pauljleach@msn.com
+
+
+   Sam Hartman
+   Hadron Industries
+
+   Email: hartmans-ietf@mit.edu
+
+
+   Shawn Emery (editor)
+   Oracle
+
+   Email: shawn.emery@gmail.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al.                  Standards Track                   [Page 18]
+