--- /dev/null
+\r
+\r
+NETWORK WORKING GROUP L. Zhu\r
+Internet-Draft P. Leach\r
+Updates: 4120, 4121 and 4556 Microsoft Corporation\r
+(if approved) October 8, 2008\r
+Intended status: Standards Track\r
+Expires: April 11, 2009\r
+\r
+\r
+ Anonymity Support for Kerberos\r
+ draft-ietf-krb-wg-anon-10\r
+\r
+Status of this Memo\r
+\r
+ By submitting this Internet-Draft, each author represents that any\r
+ applicable patent or other IPR claims of which he or she is aware\r
+ have been or will be disclosed, and any of which he or she becomes\r
+ aware will be disclosed, in accordance with Section 6 of BCP 79.\r
+\r
+ Internet-Drafts are working documents of the Internet Engineering\r
+ Task Force (IETF), its areas, and its working groups. Note that\r
+ other groups may also distribute working documents as Internet-\r
+ Drafts.\r
+\r
+ Internet-Drafts are draft documents valid for a maximum of six months\r
+ and may be updated, replaced, or obsoleted by other documents at any\r
+ time. It is inappropriate to use Internet-Drafts as reference\r
+ material or to cite them other than as "work in progress."\r
+\r
+ The list of current Internet-Drafts can be accessed at\r
+ http://www.ietf.org/ietf/1id-abstracts.txt.\r
+\r
+ The list of Internet-Draft Shadow Directories can be accessed at\r
+ http://www.ietf.org/shadow.html.\r
+\r
+ This Internet-Draft will expire on April 11, 2009.\r
+\r
+Abstract\r
+\r
+ This document defines extensions to the Kerberos protocol to allow a\r
+ Kerberos client to securely communicate with a Kerberos application\r
+ service without revealing its identity, or without revealing more\r
+ than its Kerberos realm. It also defines extensions which allow a\r
+ Kerberos client to obtain anonymous credentials without revealing its\r
+ identity to the Kerberos Key Distribution Center (KDC). This\r
+ document updates RFC 4120, RFC 4121, and RFC 4556.\r
+\r
+\r
+\r
+\r
+\r
+\r
+Zhu & Leach Expires April 11, 2009 [Page 1]\r
+\f\r
+Internet-Draft Kerberos Anonymity Support October 2008\r
+\r
+\r
+Table of Contents\r
+\r
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3\r
+ 2. Conventions Used in This Document . . . . . . . . . . . . . . 3\r
+ 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3\r
+ 4. Protocol Description . . . . . . . . . . . . . . . . . . . . . 5\r
+ 4.1. Anonymity Support in AS Exchange . . . . . . . . . . . . . 5\r
+ 4.1.1. Anonymous PKINIT . . . . . . . . . . . . . . . . . . . 6\r
+ 4.2. Anonymity Support in TGS Exchange . . . . . . . . . . . . 7\r
+ 4.3. Subsequent Exchanges and Protocol Actions Common to AS\r
+ and TGS for Anonymity Support . . . . . . . . . . . . . . 9\r
+ 5. Interoperability Requirements . . . . . . . . . . . . . . . . 10\r
+ 6. GSS-API Implementation Notes . . . . . . . . . . . . . . . . . 10\r
+ 7. PKINIT Client Contribution to the Ticket Session Key . . . . . 11\r
+ 7.1. Combinging Two protocol Keys . . . . . . . . . . . . . . . 12\r
+ 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13\r
+ 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13\r
+ 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14\r
+ 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14\r
+ 11.1. Normative References . . . . . . . . . . . . . . . . . . . 14\r
+ 11.2. Informative References . . . . . . . . . . . . . . . . . . 15\r
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15\r
+ Intellectual Property and Copyright Statements . . . . . . . . . . 16\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+Zhu & Leach Expires April 11, 2009 [Page 2]\r
+\f\r
+Internet-Draft Kerberos Anonymity Support October 2008\r
+\r
+\r
+1. Introduction\r
+\r
+ In certain situations, the Kerberos [RFC4120] client may wish to\r
+ authenticate a server and/or protect communications without revealing\r
+ the client's own identity. For example, consider an application\r
+ which provides read access to a research database, and which permits\r
+ queries by arbitrary requestors. A client of such a service might\r
+ wish to authenticate the service, to establish trust in the\r
+ information received from it, but might not wish to disclose the\r
+ client's identity to the service for privacy reasons.\r
+\r
+ Extensions to Kerberos are specified in this document by which a\r
+ client can authenticate the Key Distribution Center (KDC) and request\r
+ an anonymous ticket. The client can use the anonymous ticket to\r
+ authenticate the server and protect subsequent client-server\r
+ communications.\r
+\r
+ By using the extensions defined in this specification, the client can\r
+ request an anonymous ticket where the client may reveal the client's\r
+ identity to the client's own KDC, or the client can hide the client's\r
+ identity completely by using anonymous Public Key Cryptography for\r
+ Initial Authentication in Kerberos (PKINIT) as defined in\r
+ Section 4.1. Using the returned anonymous ticket, the client remains\r
+ anonymous in subsequent Kerberos exchanges thereafter to KDCs on the\r
+ cross-realm authentication path, and to the server with which it\r
+ communicates.\r
+\r
+ In this specification, the client realm in the anonymous ticket is\r
+ the anonymous realm name when anonymous PKINIT is used to obtain the\r
+ ticket. The client realm is the client's real realm name if the\r
+ client is authenticated using the client's long term keys. Note that\r
+ the membership of a realm can imply a member of the community\r
+ represented by the realm.\r
+\r
+ The interaction with Generic Security Service Application Program\r
+ Interface (GSS-API) is described after the protocol description.\r
+\r
+\r
+2. Conventions Used in This Document\r
+\r
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",\r
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this\r
+ document are to be interpreted as described in [RFC2119].\r
+\r
+\r
+3. Definitions\r
+\r
+ The anonymous Kerberos realm name is defined as a well-known realm\r
+\r
+\r
+\r
+Zhu & Leach Expires April 11, 2009 [Page 3]\r
+\f\r
+Internet-Draft Kerberos Anonymity Support October 2008\r
+\r
+\r
+ name based on [KRBNAM], and the value of this well-known realm name\r
+ is the literal "WELLKNOWN:ANONYMOUS".\r
+\r
+ The anonymous Kerberos principal name is defined as a well-known\r
+ Kerberos principal name based on [KRBNAM]. The value of the name-\r
+ type field is KRB_NT_WELLKNOWN [KRBNAM], and the value of the name-\r
+ string field is a sequence of two KerberosString components:\r
+ "WELLKNOWN", "ANONYMOUS".\r
+\r
+ The anonymous ticket flag is defined as bit 14 (with the first bit\r
+ being bit 0) in the TicketFlags:\r
+\r
+ TicketFlags ::= KerberosFlags\r
+ -- anonymous(14)\r
+ -- TicketFlags and KerberosFlags are defined in [RFC4120]\r
+\r
+ This is a new ticket flag that is used to indicate a ticket is an\r
+ anonymous one.\r
+\r
+ An anonymous ticket is a ticket that has all of the following\r
+ properties:\r
+\r
+ o The cname field contains the anonymous Kerberos principal name.\r
+\r
+ o The crealm field contains the client's realm name or the anonymous\r
+ realm name.\r
+\r
+ o The anonymous ticket contains no information that can reveal the\r
+ client's identity. However the ticket may contain the client\r
+ realm, intermediate realms on the client's authentication path,\r
+ and authorization data that may provide information related to the\r
+ client's identity. For example, an anonymous principal that is\r
+ identifiable only within a particular group of users can be\r
+ implemented using authorization data and such authorization data,\r
+ if included in the anonymous ticket, would disclose the client's\r
+ membership of that group.\r
+\r
+ o The anonymous ticket flag is set.\r
+\r
+ The anonymous KDC option is defined as bit 14 (with the first bit\r
+ being bit 0) in the KDCOptions:\r
+\r
+ KDCOptions ::= KerberosFlags\r
+ -- anonymous(14)\r
+ -- KDCOptions and KerberosFlags are defined in [RFC4120]\r
+\r
+ As described in Section 4, the anonymous KDC option is set to request\r
+ an anonymous ticket in an Authentication Service (AS) request or an\r
+\r
+\r
+\r
+Zhu & Leach Expires April 11, 2009 [Page 4]\r
+\f\r
+Internet-Draft Kerberos Anonymity Support October 2008\r
+\r
+\r
+ Ticket Granting Service (TGS) request.\r
+\r
+\r
+4. Protocol Description\r
+\r
+ In order to request an anonymous ticket, the client sets the\r
+ anonymous KDC option in an AS request or an TGS request.\r
+\r
+ The rest of this section is organized as follows: it first describes\r
+ protocol actions specific to AS exchanges, then it describes those of\r
+ TGS exchange. These are then followed by the decription of protocol\r
+ actions common to both AS and TGS and those in subsequent exchanges.\r
+\r
+4.1. Anonymity Support in AS Exchange\r
+\r
+ The client requests an anonymous ticket by setting the anonymous KDC\r
+ option in an AS exchange.\r
+\r
+ The Kerberos client can use the client's long term keys, or the\r
+ client's X.509 certificates [RFC4556], or any other preauthenication\r
+ data, to authenticate to the KDC and requests an anonymous ticket in\r
+ an AS exchange where the client's identity is known to the KDC.\r
+\r
+ If the client in the AS request is anonymous, the anonymous KDC\r
+ option MUST be set in the request. Otherwise, the KDC MUST return a\r
+ KRB-ERROR message with the code KDC_ERR_BADOPTION.\r
+\r
+ If the client is anonymous and the KDC does not have a key to encrypt\r
+ the reply (this can happen when, for example, the KDC does not\r
+ support PKINIT [RFC4556]), the KDC MUST return an error message with\r
+ the code KDC_ERR_NULL_KEY [RFC4120].\r
+\r
+ When policy allows, the KDC issues an anonymous ticket. If the\r
+ client name in the request is the anonymous principal, the client\r
+ realm (crealm) in the reply is the anonymous realm, otherwise the\r
+ client realm is the realm of the AS. According to [RFC4120] the\r
+ client name and the client realm in the EncTicketPart of the reply\r
+ MUST match with the corresponding client name and the client realm of\r
+ the anonymous ticket in the reply; the client MUST use the client\r
+ name and the client realm returned in the KDC-REP in subsequent\r
+ message exchanges when using the obtained anonymous ticket.\r
+\r
+ Care MUST be taken by the KDC not to reveal the client's identity in\r
+ the authorization data of the returned ticket when populating the\r
+ authorization data in a returned anonymous ticket.\r
+\r
+ The AD-INITIAL-VERIFIED-CAS authorization data as defined in\r
+ [RFC4556] contains the issuer name of the client certificate. This\r
+\r
+\r
+\r
+Zhu & Leach Expires April 11, 2009 [Page 5]\r
+\f\r
+Internet-Draft Kerberos Anonymity Support October 2008\r
+\r
+\r
+ authorization is not applicable and MUST NOT be present in the\r
+ returned anonymous ticket when anonymous PKINIT is used. When the\r
+ client is authenticated (i.e. anonymous PKINIT is not used), if it is\r
+ undesirable to disclose such information about the client's identity,\r
+ the AD-INITIAL-VERIFIED-CAS authorization data SHOULD be removed from\r
+ the returned anonymous ticket.\r
+\r
+ The client can use the client keys to mutually authenticate with the\r
+ KDC, request an anonymous TGT in the AS request. And in that case,\r
+ the reply key is selected as normal according to Section 3.1.3 of\r
+ [RFC4120].\r
+\r
+4.1.1. Anonymous PKINIT\r
+\r
+ This sub-section defines anonymity PKINIT.\r
+\r
+ As described earlier in this section, the client can request an\r
+ anonymous ticket by authenticating to the KDC using the client's\r
+ identity; alternatively without revealing the client's identity to\r
+ the KDC, the Kerberos client can request an anonymous ticket as\r
+ follows: the client sets the client name as the anonymous principal\r
+ in the AS exchange and provides a PA_PK_AS_REQ pre-authentication\r
+ data [RFC4556] where both the signerInfos field and the certificates\r
+ field of the SignedData [RFC3852] of the PA_PK_AS_REQ are empty.\r
+ Because the anonymous client does not have an associated asymmetric\r
+ key pair, the client MUST choose the Diffie-Hellman key agreement\r
+ method by filling in the Diffie-Hellman domain parameters in the\r
+ clientPublicValue [RFC4556]. This use of the anonymous client name\r
+ in conjunction with PKINIT is referred to as anonymous PKINIT. If\r
+ anonymous PKINIT is used, the realm name in the returned anonymous\r
+ ticket MUST be the anonymous realm.\r
+\r
+ Upon receiving the anonymous PKINIT request from the client, the KDC\r
+ processes the request according to Section 3.1.2 of [RFC4120]. The\r
+ KDC skips the checks for the client's signature and the client's\r
+ public key (such as the verification of the binding between the\r
+ client's public key and the client name), but performs otherwise-\r
+ applicable checks, and proceeds as normal according to [RFC4556].\r
+ For example, the AS MUST check if the client's Diffie-Hellman domain\r
+ parameters are acceptable. The Diffie-Hellman key agreement method\r
+ MUST be used and the reply key is derived according to Section\r
+ 3.2.3.1 of [RFC4556]. If the clientPublicValue is not present in the\r
+ request, the KDC MUST return a KRB-ERROR with the code\r
+ KDC_ERR_PUBLIC_KEY_ENCRYPTION_NOT_SUPPORTED [RFC4556]. If all goes\r
+ well, an anonymous ticket is generated according to Section 3.1.3 of\r
+ [RFC4120] and a PA_PK_AS_REP [RFC4556] pre-authentication data is\r
+ included in the KDC reply according to [RFC4556]. If the KDC does\r
+ not have an asymmetric key pair, it MAY reply anonymously or reject\r
+\r
+\r
+\r
+Zhu & Leach Expires April 11, 2009 [Page 6]\r
+\f\r
+Internet-Draft Kerberos Anonymity Support October 2008\r
+\r
+\r
+ the authentication attempt. If the KDC replies anonymously, both the\r
+ signerInfos field and the certificates field of the SignedData\r
+ [RFC3852] of PA_PK_AS_REP in the reply are empty. The server name in\r
+ the anonymous KDC reply contains the name of the TGS.\r
+\r
+ Upon receipt of the KDC reply that contains an anonymous ticket and a\r
+ PA_PK_AS_REP [RFC4556] pre-authentication data, the client can then\r
+ authenticate the KDC based on the KDC's signature in the\r
+ PA_PK_AS_REP. If the KDC's signature is missing in the KDC reply\r
+ (the reply is anonymous), the client MUST reject the returned ticket\r
+ if it cannot authenticate the KDC otherwise.\r
+\r
+ A KDC that supports anonymous PKINIT MUST indicate the support of\r
+ PKINIT according to Section 3.4 of [RFC4556].\r
+\r
+ Note that in order to obtain an anonymous ticket with the anonymous\r
+ realm name, the client MUST set the client name as the anonymous\r
+ principal in the request when requesting an anonymous ticket in an AS\r
+ exchange. Anonymity PKINIT is the only way via which an anonymous\r
+ ticket with the anonymous realm as the client realm can be generated\r
+ in this specification.\r
+\r
+4.2. Anonymity Support in TGS Exchange\r
+\r
+ The client requests an anonymous ticket by setting the anonymous KDC\r
+ option in a TGS exchange, and in that request the client can use a\r
+ normal Ticket Granting Ticket (TGT) with the client's identity, or an\r
+ anonymous TGT, or an anonymous cross realm TGT. If the client uses a\r
+ normal TGT, the client's identity is known to the TGS.\r
+\r
+ Note that the client can completely hide the client's identity in an\r
+ AS exchange using anonymous PKINIT as described in the previous\r
+ section.\r
+\r
+ If the ticket in the PA-TGS-REQ of the TGS request is an anonymous\r
+ one, the anonymous KDC option MUST be set in the request. Otherwise,\r
+ the KDC MUST return a KRB-ERROR message with the code\r
+ KDC_ERR_BADOPTION.\r
+\r
+ When policy allows, the KDC issues an anonymous ticket. If the\r
+ ticket in the TGS request is an anonymous one, the client name and\r
+ the client realm are copied from that ticket; otherwise the ticket in\r
+ the TGS request is a normal ticket, the returned anonymous ticket\r
+ contains the client name as the anonymous principal and the client\r
+ realm as the true realm of the client. In all cases, according to\r
+ [RFC4120] the client name and the client realm in the EncTicketPart\r
+ of the reply MUST match with the corresponding client name and the\r
+ client realm of the anonymous ticket in the reply; the client MUST\r
+\r
+\r
+\r
+Zhu & Leach Expires April 11, 2009 [Page 7]\r
+\f\r
+Internet-Draft Kerberos Anonymity Support October 2008\r
+\r
+\r
+ use the client name and the client realm returned in the KDC-REP in\r
+ subsequent message exchanges when using the obtained anonymous\r
+ ticket.\r
+\r
+ Care MUST be taken by the TGS not to reveal the client's identity in\r
+ the authorization data of the returned ticket. When propagating\r
+ authorization data in the ticket or in the enc-authorization-data\r
+ field of the request, the TGS MUST ensure that the client\r
+ confidentiality is not violated in the returned anonymous ticket.\r
+ The TGS MUST process the authorization data recursively according to\r
+ Section 5.2.6 of [RFC4120] beyond the container levels such that all\r
+ embedded authorization elements are interpreted. The TGS SHOULD NOT\r
+ populate identity-based authorization data into an anonymous ticket\r
+ in that such authorization data typically reveals the client's\r
+ identity. The specification of a new authorization data type MUST\r
+ specify the processing rules of the authorization data when an\r
+ anonymous ticket is returned. If there is no processing rule defined\r
+ for an authorization data element or the authorization data element\r
+ is unknown, the TGS MUST process it when an anonymous ticket is\r
+ returned as follows:\r
+\r
+ o If the authorization data element may reveal the client's\r
+ identity, it MUST be removed unless otherwise specified.\r
+\r
+ o If the authorization data element, that could reveal's the\r
+ client's identity. is intended to restrict the use of the ticket\r
+ or limit the rights otherwise conveyed in the ticket, it cannot be\r
+ removed in order to hide the client's identity. In this case, the\r
+ authentication attempt MUST be rejected, and the TGS MUST return\r
+ an error message with the code KDC_ERR_POLICY. Note this is\r
+ applicable to both critical and optional authorization data.\r
+\r
+ o If the authorization data element is unknown, the TGS MAY remove\r
+ it, or transfer it into the returned anonymous ticket, or reject\r
+ the authentication attempt, based on local policy for that\r
+ authorization data type unless otherwise specified. If there is\r
+ no policy defined for a given unknown authorization data type, the\r
+ authentication MUST be rejected. The error code is KDC_ERR_POLICY\r
+ when the authentication is rejected.\r
+\r
+ The AD-INITIAL-VERIFIED-CAS authorization data as defined in\r
+ [RFC4556] contains the issuer name of the client certificate. If it\r
+ is undesirable to disclose such information about the client's\r
+ identity, the AD-INITIAL-VERIFIED-CAS authorization data SHOULD be\r
+ removed from an anonymous ticket.\r
+\r
+ The TGS encodes the name of the previous realm into the transited\r
+ field according to Section 3.3.3.2 of [RFC4120]. Based on local\r
+\r
+\r
+\r
+Zhu & Leach Expires April 11, 2009 [Page 8]\r
+\f\r
+Internet-Draft Kerberos Anonymity Support October 2008\r
+\r
+\r
+ policy, the TGS MAY omit the previous realm if the cross realm TGT is\r
+ an anonymous one in order to hide the authentication path of the\r
+ client. The unordered set of realms in the transited field, if\r
+ present, can reveal which realm may potentially be the realm of the\r
+ client or the realm that issued the anonymous TGT. The anonymous\r
+ Kerberos realm name MUST NOT be present in the transited field of a\r
+ ticket. The true name of the realm that issued the anonymous ticket\r
+ MAY be present in the transited field of a ticket.\r
+\r
+4.3. Subsequent Exchanges and Protocol Actions Common to AS and TGS for\r
+ Anonymity Support\r
+\r
+ In both AS and TGS exchanges, the realm field in the KDC request is\r
+ always the realm of the target KDC, not the anonymous realm when the\r
+ client requests an anonymous ticket.\r
+\r
+ Absent other information the KDC MUST NOT include any identifier in\r
+ the returned anonymous ticket that could reveal the client's identity\r
+ to the server.\r
+\r
+ Unless anonymous PKINIT is used, if a client requires anonymous\r
+ communication then the client MUST check to make sure that the ticket\r
+ in the reply is actually anonymous by checking the presence of the\r
+ anonymous ticket flag in the flags field of the EncKDCRepPart. This\r
+ is because KDCs ignore unknown KDC options. A KDC that does not\r
+ understand the anonymous KDC option will not return an error, but\r
+ will instead return a normal ticket.\r
+\r
+ The subsequent client and server communications then proceed as\r
+ described in [RFC4120].\r
+\r
+ Note that the anonymous principal name and realm are only applicable\r
+ to the client in Kerberos messages, the server cannot be anonymous in\r
+ any Kerberos message per this specification.\r
+\r
+ A server accepting an anonymous service ticket may assume that\r
+ subsequent requests using the same ticket originate from the same\r
+ client. Requests with different tickets are likely to originate from\r
+ different clients.\r
+\r
+ Upon receipt of an anonymous ticket, the transited policy check is\r
+ preformed in the same way as that of a normal ticket if the client's\r
+ realm is not the anonymous realm; if the client realm is the\r
+ anonymous realm, absent other information any realm in the\r
+ authentication path is allowed by the cross-realm policy check.\r
+\r
+\r
+\r
+\r
+\r
+\r
+Zhu & Leach Expires April 11, 2009 [Page 9]\r
+\f\r
+Internet-Draft Kerberos Anonymity Support October 2008\r
+\r
+\r
+5. Interoperability Requirements\r
+\r
+ Conforming implementations MUST support the anonymous principal with\r
+ a non-anonymous realm, and they MAY support the anonymous principal\r
+ with the anonymous realm using anonymous PKINIT.\r
+\r
+\r
+6. GSS-API Implementation Notes\r
+\r
+ GSS-API defines the name_type GSS_C_NT_ANONYMOUS [RFC2743] to\r
+ represent the anonymous identity. In addition, Section 2.1.1 of\r
+ [RFC1964] defines the single string representation of a Kerberos\r
+ principal name with the name_type GSS_KRB5_NT_PRINCIPAL_NAME. The\r
+ anonymous principal with the anonymous realm corresponds to the GSS-\r
+ API anonymous principal. A principal with the anonymous principal\r
+ name and a non-anonymous realm is an authenticated principal, hence\r
+ such a principal does not correspond to the anonymous principal in\r
+ GSS-API with the GSS_C_NT_ANONYMOUS name type. The [RFC1964] name\r
+ syntax for GSS_KRB5_NT_PRINCIPAL_NAME MUST be used for importing the\r
+ anonymous principal name with a non-anonymous realm name and for\r
+ displaying and exporting these names.\r
+\r
+ At the GSS-API [RFC2743] level, an initiator/client requests the use\r
+ of an anonymous principal with the anonymous realm by asserting the\r
+ "anonymous" flag when calling GSS_Init_Sec_Context(). The GSS-API\r
+ implementation MAY provide implementation-specific means for\r
+ requesting the use of an anonymous principal with a non-anonymous\r
+ realm.\r
+\r
+ GSS-API does not know or define "anonymous credentials", so the\r
+ (printable) name of the anonymous principal will rarely be used by or\r
+ relevant for the initiator/client. The printable name is relevant\r
+ for the acceptor/server when performing an authorization decision\r
+ based on the initiator name that is returned from the acceptor side\r
+ upon the successful security context establishment.\r
+\r
+ A GSS-API initiator MUST carefully check the resulting context\r
+ attributes from the initial call to GSS_Init_Sec_Context() when\r
+ requesting anonymity, because (as in the GSS-API tradition and for\r
+ backwards compatibility) anonymity is just another optional context\r
+ attribute. It could be that the mechanism doesn't recognize the\r
+ attribute at all or that anonymity is not available for some other\r
+ reasons -- and in that case the initiator MUST NOT send the initial\r
+ security context token to the acceptor, because it will likely reveal\r
+ the initiators identity to the acceptor, something that can rarely be\r
+ "un-done".\r
+\r
+ Portable initiators are RECOMMENDED to use default credentials\r
+\r
+\r
+\r
+Zhu & Leach Expires April 11, 2009 [Page 10]\r
+\f\r
+Internet-Draft Kerberos Anonymity Support October 2008\r
+\r
+\r
+ whenever possible, and request anonymity only through the input\r
+ anon_req_flag [RFC2743] to GSS_Init_Sec_Context().\r
+\r
+\r
+7. PKINIT Client Contribution to the Ticket Session Key\r
+\r
+ The definition in this section was motivated by protocol analysis of\r
+ anonymous PKINIT (defined in this document) in building tunneling\r
+ channels [FAST] and subsequent channel bindings. In order to enable\r
+ applications of anonymous PKINIT to form channels, all\r
+ implementations of anonymous PKINIT need to meet the requirements of\r
+ this section. There is otherwise no connection to the rest of this\r
+ document.\r
+\r
+ PKINIT is useful for constructing tunneling channels. To ensure that\r
+ an attacker cannot create a channel with a given name, it is\r
+ desirable that neither the KDC nor the client can unilaterally\r
+ determine the ticket session key. To achieve that end, a KDC\r
+ conforming to this definition MUST encrypt a randomly generated key,\r
+ called the KDC contribution key, in the PA_PKINIT_KX padata (defined\r
+ next in this section). The KDC contribution key is then combined\r
+ with the reply key to form the ticket session key of the returned\r
+ ticket. These two keys are then combined using the KRB-FX-CF2\r
+ operation defined in Section 7.1, where K1 is the KDC contribution\r
+ key, K2 is the reply key, the input pepper1 is American Standard Code\r
+ for Information Interchange (ASCII) [ASAX34] string "PKINIT", and the\r
+ input pepper2 is ASCII string "KeyExchange".\r
+\r
+ PA_PKINIT_KX 135\r
+ -- padata for PKINIT that contains an encrypted\r
+ -- KDC contribution key.\r
+\r
+ PA-PKINIT-KX ::= EncryptedData -- EncryptionKey\r
+ -- Contains an encrypted key randomly\r
+ -- generated by the KDC (known as the KDC contribution key).\r
+ -- Both EncryptedData and EncryptionKey are defined in [RFC4120]\r
+\r
+ The PA_PKINIT_KX padata MUST be included in the KDC reply when\r
+ anonymous PKINIT is used; it SHOULD be included if PKINIT is used\r
+ with the Diffie-Helleman key exchange but the client is not\r
+ anonymous; it MUST NOT be included otherwise (e.g. when PKINIT is\r
+ used with the public key encryption as the key exchange).\r
+\r
+ The padata-value field of the PA-PKINIT-KX type padata contains the\r
+ DER [X680] [X690] encoding of the Abstract Syntax Notation One\r
+ (ASN.1) type PA-PKINIT-KX. The PA-PKINIT-KX structure is a\r
+ EncryptedData. The clear text data being encrypted is the DER\r
+ encoded Kerberos session key randomly generated by the KDC. The\r
+\r
+\r
+\r
+Zhu & Leach Expires April 11, 2009 [Page 11]\r
+\f\r
+Internet-Draft Kerberos Anonymity Support October 2008\r
+\r
+\r
+ encryption key is the reply key and the key usage number is\r
+ KEY_USAGE_PA_PKINIT_KX (44).\r
+\r
+ The client then decrypts the KDC contribution key and verifies the\r
+ ticket session key in the returned ticket is the combined key of the\r
+ KDC contribution key and the reply key as described above. A\r
+ conforming client MUST reject anonymous PKINIT authentication if the\r
+ PA_PKINIT_KX padata is not present in the KDC reply or if the ticket\r
+ session key of the returned ticket is not the combined key of the KDC\r
+ contribution key and the reply key when PA-PKINIT-KX is present in\r
+ the KDC reply.\r
+\r
+7.1. Combinging Two protocol Keys\r
+\r
+ KRB-FX-CF2() combines two protocol keys based on the pseudo-random()\r
+ function defined in [RFC3961].\r
+\r
+ Given two input keys, K1 and K2, where K1 and K2 can be of two\r
+ different enctypes, the output key of KRB-FX-CF2(), K3, is derived as\r
+ follows:\r
+\r
+ KRB-FX-CF2(protocol key, protocol key, octet string,\r
+ octet string) -> (protocol key)\r
+\r
+ PRF+(K1, pepper1) -> octet-string-1\r
+ PRF+(K2, pepper2) -> octet-string-2\r
+ KRB-FX-CF2(K1, K2, pepper1, pepper2) ->\r
+ random-to-key(octet-string-1 ^ octet-string-2)\r
+\r
+ Where ^ denotes the exclusive-OR operation. PRF+() is defined as\r
+ follows:\r
+\r
+ PRF+(protocol key, octet string) -> (octet string)\r
+\r
+ PRF+(key, shared-info) -> pseudo-random( key, 1 || shared-info ) ||\r
+ pseudo-random( key, 2 || shared-info ) ||\r
+ pseudo-random( key, 3 || shared-info ) || ...\r
+\r
+ Here the counter value 1, 2, 3 and so on are encoded as a one-octet\r
+ integer. The pseudo-random() operation is specified by the enctype\r
+ of the protocol key. PRF+() uses the counter to generate enough bits\r
+ as needed by the random-to-key() [RFC3961] function for the\r
+ encryption type specified for the resulting key; unneeded bits are\r
+ removed from the tail.\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+Zhu & Leach Expires April 11, 2009 [Page 12]\r
+\f\r
+Internet-Draft Kerberos Anonymity Support October 2008\r
+\r
+\r
+8. Security Considerations\r
+\r
+ Since KDCs ignore unknown options, a client requiring anonymous\r
+ communication needs to make sure that the returned ticket is actually\r
+ anonymous. This is because a KDC that that does not understand the\r
+ anonymous option would not return an anonymous ticket.\r
+\r
+ By using the mechanism defined in this specification, the client does\r
+ not reveal the client's identity to the server but the client\r
+ identity may be revealed to the KDC of the server principal (when the\r
+ server principal is in a different realm than that of the client),\r
+ and any KDC on the cross-realm authentication path. The Kerberos\r
+ client MUST verify the ticket being used is indeed anonymous before\r
+ communicating with the server, otherwise the client's identity may be\r
+ revealed unintentionally.\r
+\r
+ In cases where specific server principals must not have access to the\r
+ client's identity (for example, an anonymous poll service), the KDC\r
+ can define server principal specific policy that insure any normal\r
+ service ticket can NEVER be issued to any of these server principals.\r
+\r
+ If the KDC that issued an anonymous ticket were to maintain records\r
+ of the association of identities to an anonymous ticket, then someone\r
+ obtaining such records could breach the anonymity. Additionally, the\r
+ implementations of most (for now all) KDC's respond to requests at\r
+ the time that they are received. Traffic analysis on the connection\r
+ to the KDC will allow an attacker to match client identities to\r
+ anonymous tickets issued. Because there are plaintext parts of the\r
+ tickets that are exposed on the wire, such matching by a third party\r
+ observer is relatively straightforward. A service that is\r
+ authenticated by the anonymous principals may be able to infer the\r
+ identity of the client by examining and linking quasi-static protocol\r
+ information such as the IP address from which a request is received,\r
+ or by linking multiple uses of the same anonymous ticket.\r
+\r
+ The client's real identity is not revealed when the client is\r
+ authenticated as the anonymous principal. Application servers MAY\r
+ reject the authentication in order to, for example, prevent\r
+ information disclosure or as part of Denial of Service (DOS)\r
+ prevention. Application servers MUST avoid accepting anonymous\r
+ credentials in situations where they must record the client's\r
+ identity; for example, when there must be an audit trail.\r
+\r
+\r
+9. Acknowledgements\r
+\r
+ JK Jaganathan helped editing early revisions of this document.\r
+\r
+\r
+\r
+\r
+Zhu & Leach Expires April 11, 2009 [Page 13]\r
+\f\r
+Internet-Draft Kerberos Anonymity Support October 2008\r
+\r
+\r
+ Clifford Neuman contributed the core notions of this document.\r
+\r
+ Ken Raeburn reviewed the document and provided suggestions for\r
+ improvements.\r
+\r
+ Martin Rex wrote the text for GSS-API considerations.\r
+\r
+ Nicolas Williams reviewed the GSS-API considerations section and\r
+ suggested ideas for improvements.\r
+\r
+ Sam Hartman and Nicolas Williams were great champions of this work.\r
+\r
+ Miguel Garcia and Phillip Hallam-Baker reviewed the document and\r
+ provided helpful suggestions.\r
+\r
+ In addition, the following individuals made significant\r
+ contributions: Jeffrey Altman, Tom Yu, Chaskiel M Grundman, Love\r
+ Hornquist Astrand, Jeffrey Hutzelman, and Olga Kornievskaia.\r
+\r
+\r
+10. IANA Considerations\r
+\r
+ This document defines a new 'anonymous' Kerberos well-known name and\r
+ a new 'anonymous' Kerberos well-known realm based on [KRBNAM]. IANA\r
+ is requested to add these two values to the Kerberos naming\r
+ registries that are created in [KRBNAM].\r
+\r
+\r
+11. References\r
+\r
+11.1. Normative References\r
+\r
+ [ASAX34] American Standard Code for Information Interchange, \r
+ ASA X3.4-1963, American Standards Association, June 17, \r
+ 1963.\r
+\r
+ [KRBNAM] Zhu, L., "Additional Kerberos Naming Constraints",\r
+ draft-ietf-krb-wg-naming (work in progress), 2008.\r
+\r
+ [RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism",\r
+ RFC 1964, June 1996.\r
+\r
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate\r
+ Requirement Levels", BCP 14, RFC 2119, March 1997.\r
+\r
+ [RFC2743] Linn, J., "Generic Security Service Application Program\r
+ Interface Version 2, Update 1", RFC 2743, January 2000.\r
+\r
+ [RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)",\r
+ RFC 3852, July 2004.\r
+\r
+ [RFC3961] Raeburn, K., "Encryption and Checksum Specifications for\r
+ \r
+\r
+\r
+Zhu & Leach Expires April 11, 2009 [Page 14]\r
+\f\r
+Internet-Draft Kerberos Anonymity Support October 2008\r
+\r
+\r
+ Kerberos 5", RFC 3961, February 2005.\r
+\r
+ [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The\r
+ Kerberos Network Authentication Service (V5)", RFC 4120,\r
+ July 2005.\r
+\r
+ [RFC4556] Zhu, L. and B. Tung, "Public Key Cryptography for Initial\r
+ Authentication in Kerberos (PKINIT)", RFC 4556, June 2006.\r
+\r
+\r
+ [X680] ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002,\r
+ Information technology - Abstract Syntax Notation One\r
+ (ASN.1): Specification of basic notation.\r
+ \r
+ [X690] ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002,\r
+ Information technology - ASN.1 encoding Rules:\r
+ Specification of Basic Encoding Rules (BER), Canonical\r
+ Encoding Rules (CER) and Distinguished Encoding Rules\r
+ (DER). \r
+ \r
+11.2. Informative References\r
+\r
+ [FAST] Zhu, L. and S. Hartman, "A Generalized Framework for\r
+ Kerberos Pre-Authentication",\r
+ draft-ietf-krb-wg-preauth-framework (work in progress),\r
+ 2008.\r
+\r
+\r
+Authors' Addresses\r
+\r
+ Larry Zhu\r
+ Microsoft Corporation\r
+ One Microsoft Way\r
+ Redmond, WA 98052\r
+ US\r
+\r
+ Email: lzhu@microsoft.com\r
+\r
+\r
+ Paul Leach\r
+ Microsoft Corporation\r
+ One Microsoft Way\r
+ Redmond, WA 98052\r
+ US\r
+\r
+ Email: paulle@microsoft.com\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+Zhu & Leach Expires April 11, 2009 [Page 15]\r
+\f\r
+Internet-Draft Kerberos Anonymity Support October 2008\r
+\r
+\r
+Full Copyright Statement\r
+\r
+ Copyright (C) The IETF Trust (2008).\r
+\r
+ This document is subject to the rights, licenses and restrictions\r
+ contained in BCP 78, and except as set forth therein, the authors\r
+ retain all their rights.\r
+\r
+ This document and the information contained herein are provided on an\r
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS\r
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND\r
+ THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS\r
+ OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF\r
+ THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED\r
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.\r
+\r
+\r
+Intellectual Property\r
+\r
+ The IETF takes no position regarding the validity or scope of any\r
+ Intellectual Property Rights or other rights that might be claimed to\r
+ pertain to the implementation or use of the technology described in\r
+ this document or the extent to which any license under such rights\r
+ might or might not be available; nor does it represent that it has\r
+ made any independent effort to identify any such rights. Information\r
+ on the procedures with respect to rights in RFC documents can be\r
+ found in BCP 78 and BCP 79.\r
+\r
+ Copies of IPR disclosures made to the IETF Secretariat and any\r
+ assurances of licenses to be made available, or the result of an\r
+ attempt made to obtain a general license or permission for the use of\r
+ such proprietary rights by implementers or users of this\r
+ specification can be obtained from the IETF on-line IPR repository at\r
+ http://www.ietf.org/ipr.\r
+\r
+ The IETF invites any interested party to bring to its attention any\r
+ copyrights, patents or patent applications, or other proprietary\r
+ rights that may cover technology that may be required to implement\r
+ this standard. Please address the information to the IETF at\r
+ ietf-ipr@ietf.org.\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+Zhu & Leach Expires April 11, 2009 [Page 16]\r
+\f\r
+\r
git.samba.org / metze / heimdal / wip.git / commitdiff