ietf-corpus

rfc-8062

Anonymity Support for Kerberos

L. Zhu, P. Leach, S. Hartman, S. Emery (Editor)
date2017-02 streamIETF areasec wgkitten statusPROPOSED STANDARD pages18 canonicalhttps://www.rfc-editor.org/rfc/rfc8062 doi10.17487/RFC8062
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.

obsoletes

updates

Extracted elements (28)

design-rationale §1.1

RFC 8062 obsoletes RFC 6112 because RFC 6112 contained errors—most notably, the pepper2 string was incorrectly cased as 'KeyExchange' rather than 'KEYEXCHANGE', making the protocol non-interoperable with all known implementations. The requirement to use the anonymous KDC option when an anonymous ticket is used in a TGS request was also reduced from MUST to SHOULD.

security

design-rationale §7

The KDC contribution key mechanism (PA_PKINIT_KX) prevents a man-in-the-middle attacker from intercepting an anonymous PKINIT exchange: without it, an MITM could perform separate DH exchanges with both client and KDC, decrypt the session key, and relay the ticket while keeping a copy. Binding the ticket session key to a KDC-generated key encrypted under the DH reply key forces the session key to be verifiable by the client.

security, crypto

interoperability-note §5

Conforming implementations MUST support the anonymous principal with a non-anonymous realm, and MAY support the anonymous principal with the anonymous realm using anonymous PKINIT.

security, privacy

normative-requirement §7 MUST

A conforming client MUST reject anonymous PKINIT authentication if PA_PKINIT_KX is absent from the KDC reply, or if the ticket session key is not the combined key of the KDC contribution key and the reply key as specified.

security, crypto

normative-requirement §6 MUST

A GSS-API initiator MUST carefully check resulting context attributes from GSS_Init_Sec_Context() when requesting anonymity and MUST NOT send the initial security context token to the acceptor if the anonymity attribute was not granted.

security, privacy

normative-requirement §4.1.1 MUST

A KDC supporting anonymous PKINIT MUST indicate PKINIT support per Section 3.4 of RFC 4556 and MUST include a padata element of padata-type PA_PKINIT_KX with empty padata-value in any PA-PK-AS-REQ error reply to signal anonymous PKINIT support.

security, crypto

normative-requirement §4.1 MUST

If an anonymous client requests a ticket and the KDC has no key to encrypt the reply (e.g., no PKINIT support), the KDC MUST return KDC_ERR_NULL_KEY.

security

normative-requirement §4.2 SHOULD

If an anonymous ticket is used in the PA-TGS-REQ of a TGS request, the anonymous KDC option SHOULD be set. The TGS MUST NOT reveal the client's identity in authorization data of the returned anonymous ticket.

security, privacy

normative-requirement §4.1 MUST

If the client in an AS request is anonymous, the anonymous KDC option MUST be set in the request; otherwise, the KDC MUST return a KRB-ERROR with code KDC_ERR_BADOPTION.

security, privacy

normative-requirement §7 MUST

PA_PKINIT_KX MUST be included in the KDC reply when anonymous PKINIT is used; it SHOULD be included when PKINIT is used with DH key exchange and the client is non-anonymous; it MUST NOT be included when PKINIT uses public key encryption as the key exchange.

security, crypto

normative-requirement §4.2 MUST NOT

The anonymous Kerberos realm name MUST NOT appear in the transited field of a ticket. The TGS MAY omit the previous realm from the transited field if the cross-realm TGT is anonymous, to hide the authentication path.

security, privacy

normative-requirement §4.1 MUST NOT

The KDC MUST NOT include any identifier in the returned anonymous ticket's authorization data that could reveal the client's identity. The AD_INITIAL_VERIFIED_CAS authorization data MUST NOT be present when anonymous PKINIT is used.

security, privacy

normative-requirement §4.3 MUST

Unless anonymous PKINIT is used, a client requiring anonymous communication MUST verify that the returned ticket has the anonymous ticket flag set, because KDCs that do not understand the anonymous option silently return a normal ticket.

security, privacy

normative-requirement §4.2 MUST

When an anonymous ticket is returned by the TGS, if an authorization data element of unknown type has no defined processing rule, the authentication MUST be rejected with KDC_ERR_POLICY. If an element would reveal the client's identity but is needed to restrict ticket use, the TGS MUST also reject with KDC_ERR_POLICY.

security, privacy

normative-requirement §4.1.1 MUST

When anonymous PKINIT is used, the KDC MUST use the Diffie-Hellman key agreement method and derive the reply key per Section 3.2.3.1 of RFC 4556. If clientPublicValue is absent, the KDC MUST return KDC_ERR_PUBLIC_KEY_ENCRYPTION_NOT_SUPPORTED.

security, crypto

protocol-element §3

An anonymous ticket must have the anonymous Kerberos principal name in cname, the client realm in crealm (either the client's real realm or the anonymous realm), no client-identity-revealing information, and the anonymous ticket flag set.

security, privacy

protocol-element §4.1.1

Anonymous PKINIT: the client sets the client name to the anonymous principal, provides PA_PK_AS_REQ with empty signerInfos and absent certificates, and MUST use Diffie-Hellman key agreement by populating clientPublicValue. This is the only mechanism to obtain a ticket with the anonymous realm as the client realm.

security, privacy, crypto

protocol-element §7.1

KRB-FX-CF2 combines two protocol keys K1 and K2 using PRF+(K1, pepper1) XOR PRF+(K2, pepper2), then applies random-to-key(). For anonymous PKINIT, K1 is the KDC contribution key, K2 is the reply key, pepper1 is 'PKINIT', and pepper2 is 'KEYEXCHANGE'.

security, crypto

protocol-element §7

PA_PKINIT_KX (padata type 147) is a padata element whose value is a DER-encoded PA-PKINIT-KX structure (an EncryptedData) containing a randomly generated KDC contribution key encrypted with the reply key using key usage KEY_USAGE_PA_PKINIT_KX (44).

security, crypto

protocol-element §3

The anonymous KDC option is defined as bit 16 (first bit being bit 0) in the KDCOptions KerberosFlags field, set by the client to request an anonymous ticket in an AS or TGS request.

security, privacy

protocol-element §3

The anonymous Kerberos realm name is the well-known realm name 'WELLKNOWN:ANONYMOUS'. The anonymous Kerberos principal name has name-type KRB_NT_WELLKNOWN and name-string sequence ['WELLKNOWN', 'ANONYMOUS'].

security, privacy

protocol-element §3

The anonymous ticket flag is defined as bit 16 (first bit being bit 0) in the TicketFlags KerberosFlags field, used to indicate that a ticket is an anonymous one.

security, privacy

registry §9

IANA updated the 'Well-Known Kerberos Principal Names' registry entry for 'anonymous' and the 'Well-Known Kerberos Realm Names' registry entry for 'anonymous' to refer to RFC 8062. IANA also updated the 'Pre-authentication and Typed Data' registry entry for PA_PKINIT_KX (147) to refer to this document.

registry, security

security-consideration §8 MUST

A client's identity may be revealed to the KDC of the server principal (when in a different realm) and to any KDC on the cross-realm authentication path, even when using anonymous tickets. The Kerberos client MUST verify the ticket is anonymous before communicating with the server.

security, privacy

security-consideration §8 MUST

Application servers MUST avoid accepting anonymous credentials in situations where they must record the client's identity (e.g., when an audit trail is required). Servers MAY reject anonymous authentication to prevent information disclosure or as part of DoS prevention.

security, privacy

security-consideration §8

FAST with the hide-client-names option (RFC 6113) and Kerberos5 starttls (RFC 6251) can protect client identity in transit to the KDC. Clients can also limit ticket reuse to minimize ticket-linking attacks.

security, privacy

security-consideration §8

Traffic analysis on connections to the KDC can allow an attacker to match client identities to anonymous tickets because there are plaintext parts of tickets exposed on the wire. Additionally, a service can potentially infer a client's identity from quasi-static information such as IP address or by linking multiple uses of the same anonymous ticket.

security, privacy

wire-format §7

PA-PKINIT-KX is encoded as ASN.1 EncryptedData (DER). The cleartext is the DER-encoded KDC contribution key (an EncryptionKey). The encryption key is the reply key; the key usage number is KEY_USAGE_PA_PKINIT_KX (44).

security, crypto