diff options
Diffstat (limited to 'third_party/heimdal/doc/standardisation/rfc6112.txt')
| -rw-r--r-- | third_party/heimdal/doc/standardisation/rfc6112.txt | 899 |
1 files changed, 899 insertions, 0 deletions
diff --git a/third_party/heimdal/doc/standardisation/rfc6112.txt b/third_party/heimdal/doc/standardisation/rfc6112.txt new file mode 100644 index 00000000000..b407759662c --- /dev/null +++ b/third_party/heimdal/doc/standardisation/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] + |