RFC 8062

Anonymity Support for Kerberos

📅 published February 2017, from ietf

RFC 8062: Anonymity Support for Kerberos 🎀

okay bestie, this is RFC 8062, and it's giving privacy glow-up ✨ It's a Standards Track spec from the IETF, published in February 2017, with ISSN 2070-1721. The main authors are L. Zhu and P. Leach (both Microsoft Corporation), S. Hartman (Hadron Industries), and S. Emery, Ed. (Oracle). It obsoletes RFC 6112 and updates RFCs 4120, 4121, and 4556 💜

Abstract 💖

okay so this doc adds extensions to Kerberos so a client can talk securely to an application service without revealing who it is, or without revealing more than its Kerberos realm 🫶 It also lets a client grab anonymous credentials without outing itself to the Kerberos Key Distribution Center (KDC) 🦋

It updates RFCs 4120, 4121, and 4556, and it obsoletes RFC 6112 and moves that doc to Historic 💅 RFC 6112 had errors, and nothing that actually exists in the wild can interoperate with its protocol. This spec describes one that works with multiple implementations, so it's the one to follow 🌸

Status of This Memo 🧚

this is an Internet Standards Track document 💅

it's a product of the Internet Engineering Task Force (IETF), so it reflects the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). If you want more on Internet Standards, check Section 2 of RFC 7841 🍓

for the current status, any errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc8062 ✨

Copyright Notice 🌈

this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stood on the publication date. Please actually read those, bestie, because they spell out your rights and restrictions for this document 📜 Any Code Components pulled out of this doc must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License 🔥

this doc may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The people who control the copyright in some of that material may not have given the IETF Trust permission to allow modifications outside the IETF Standards Process 🙈 Unless you get an adequate license from those copyright holders, this doc can't be modified outside the IETF Standards Process, and derivative works can't be made outside it either. The only exceptions are formatting it for publication as an RFC or translating it into languages other than English 💅

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 ✨

okay so sometimes a Kerberos [RFC4120] client wants to authenticate a server and/or protect its communications without revealing its own identity 🙈 Picture an app that gives read access to a research database and lets anyone run queries. A client of that service might want to authenticate the service so it can trust the info it gets back, but it might not want to tell the service who it is, for privacy reasons 💜

this spec adds Kerberos extensions that let a client authenticate the Key Distribution Center (KDC) and request an anonymous ticket 🦋 The client can then use that anonymous ticket to authenticate the server and protect later client-server communications, which is so iconic 👑

with the extensions in this spec, the client can ask for an anonymous ticket where it still reveals its identity to its own KDC. Or it can hide its identity completely by using anonymous Public Key Cryptography for Initial Authentication in Kerberos (PKINIT), as defined in Section 4.1 🫶 After that, using the returned anonymous ticket, the client stays anonymous in later Kerberos exchanges with the KDCs on the cross-realm authentication path and with the server it's talking to 🌸

in this spec, the client realm in the anonymous ticket is the anonymous realm name whenever anonymous PKINIT was used to get the ticket. If the client authenticated with its long-term keys, the client realm is its real realm name instead 🧚 Also, note that being in a realm can imply being a member of the community that realm represents 💅

the interaction with the Generic Security Service Application Program Interface (GSS-API) is described after the protocol description ✨

this spec replaces [RFC6112] to fix technical errors in that one. RFC 6112 is now Historic, and implementing RFC 6112 is NOT RECOMMENDED 🚫 Every known implementation follows this spec, not RFC 6112 💖

1.1. Changes since RFC 6112 🍓

in Section 7, the pepper2 string "KeyExchange" that RFC 6112 used is now in all capital letters, so it matches the string real implementations actually use 💅

the requirement for the anonymous option to be set when an anonymous ticket is used in a Ticket-Granting Service (TGS) request went from a MUST down to a SHOULD 🌈 At least one implementation doesn't require it, and it isn't necessary for both the anonymous option and the anonymous ticket to serve as the indicator of request type 🦋

the authorization data type name "AD-INITIAL-VERIFIED-CAS" that RFC 6112 used is now spelled "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 read as described in [RFC2119] 📜

3. Definitions 🧚

the anonymous Kerberos realm name is a well-known realm name based on [RFC6111]. Its value is the literal "WELLKNOWN:ANONYMOUS" 🦋

the anonymous Kerberos principal name is a well-known Kerberos principal name based on [RFC6111] 💜 Its name-type field is KRB_NT_WELLKNOWN [RFC6111], and its name-string field is a sequence of two KerberosString components: "WELLKNOWN" and "ANONYMOUS" 🫶

the anonymous ticket flag is 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, used to show that a ticket is anonymous ✨

an anonymous ticket is a ticket with all of these properties 👑

The cname field contains the anonymous Kerberos principal name.
The crealm field contains the client's realm name or the anonymous realm name.
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. 🙈
The anonymous ticket flag is set.

the anonymous KDC option is bit 16 (with the first bit being bit 0) in the KDCOptions 💖

           KDCOptions      ::= KerberosFlags
             -- anonymous(16)
             -- KDCOptions and KerberosFlags are defined in [RFC4120]

as Section 4 explains, the anonymous KDC option gets set to request an anonymous ticket in an Authentication Service (AS) request or a Ticket-Granting Service (TGS) request 🍓

4. Protocol Description 🦋

okay so 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 laid out like this: first it covers the protocol actions specific to AS exchanges, then the ones for TGS exchanges 🌈 After that come the protocol actions shared by both AS and TGS, plus the ones in subsequent exchanges ✨

4.1. Anonymity Support in AS Exchange

okay bestie, the client asks for an anonymous ticket by setting the anonymous KDC option in an AS exchange 💅

The Kerberos client can use its long-term keys, its X.509 certificates [RFC4556], or any other pre-authentication data to authenticate to the KDC and request an anonymous ticket in an AS exchange, as long as the KDC already knows who the client is 🔐

If the client is anonymous in the AS request, 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 doesn't have a key to encrypt the reply (this can happen when, for example, the KDC doesn't 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 the corresponding client name and client realm of the KDC reply. The client MUST use the client name and 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 it fills in the authorization data for an anonymous ticket. Hard boundary, no exceptions 🫶

The AD_INITIAL_VERIFIED_CAS authorization data, as defined in [RFC4556], contains the issuer name of the client certificate. This authorization isn't applicable and MUST NOT be present in the returned anonymous ticket when anonymous PKINIT is used. When the client is authenticated (so anonymous PKINIT isn't used), if it's undesirable to disclose that 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 its 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 🧚

Like we said earlier in this section, the client can request an anonymous ticket by authenticating to the KDC with its identity. Alternatively, the Kerberos client can request an anonymous ticket without revealing its identity to the KDC, like this: 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. The anonymous client doesn't have an associated asymmetric key pair, so 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 together with PKINIT is called "anonymous PKINIT" 🎀 If anonymous PKINIT is used, the realm name in the returned anonymous ticket MUST be the anonymous realm.

When the KDC gets the anonymous PKINIT request from the client, it 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 verifying the binding between the client's public key and the client name), but it still does every other applicable check and proceeds as normal, according to [RFC4556]. For example, the AS MUST check whether 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 isn't present in the request, the KDC MUST return a KRB-ERROR with the code KDC_ERR_PUBLIC_KEY_ENCRYPTION_NOT_SUPPORTED [RFC4556]. If everything 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 doesn't 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 the 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 🌈

When the client receives the KDC reply that contains an anonymous ticket and PA_PK_AS_REP [RFC4556] pre-authentication data, it can then authenticate the KDC based on the KDC's signature in the PA_PK_AS_REP. If the KDC's signature is missing from the KDC reply (meaning the reply is anonymous), the client MUST reject the returned ticket if it can't otherwise authenticate the KDC 🧐

A KDC that supports anonymous PKINIT MUST indicate its support for PKINIT, according to Section 3.4 of [RFC4556]. On top of that, such a KDC MUST indicate support for anonymous PKINIT by including a padata element with a padata-type of PA_PKINIT_KX and an empty padata-value when it includes PA-PK-AS-REQ in an error reply 💜

When it's included in a KDC error, PA_PKINIT_KX indicates support for anonymous PKINIT. As discussed in Section 7, when it's included in an AS-REP, PA_PKINIT_KX proves that the KDC and the client both contributed to the session key for any use of Diffie-Hellman key agreement with PKINIT 🔥

Note that to get an anonymous ticket with the anonymous realm name, the client MUST set the client name as the anonymous principal in the request when it asks for an anonymous ticket in an AS exchange. Anonymous PKINIT is the only way in this specification to generate an anonymous ticket with the anonymous realm as the client realm 👑

4.2. Anonymity Support in TGS Exchange

The client requests an anonymous ticket by setting the anonymous KDC option in a TGS exchange. In that request, the client can use a normal Ticket-Granting Ticket (TGT) with its 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 its identity in an AS exchange by 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.

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, if the ticket in the TGS request is a normal ticket, the returned anonymous ticket contains the anonymous principal as the client name and the true realm of the client as the client realm. In all cases, according to [RFC4120], the client name and client realm in the EncTicketPart of the reply MUST match the corresponding client name and client realm of the anonymous ticket in the reply. The client MUST use the client name and 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 make sure client confidentiality isn't 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, so that all embedded authorization elements are interpreted. The TGS SHOULD NOT populate identity-based authorization data into an anonymous ticket, because that kind of authorization data typically reveals the client's identity 🕵️‍♀️ The specification of a new authorization data type MUST specify the processing rules for that authorization data when an anonymous ticket is returned. If there's no processing rule defined for an authorization data element, or the element is unknown, the TGS MUST process it when an anonymous ticket is returned, as follows:

If the authorization data element may reveal the client's identity, it MUST be removed unless otherwise specified.
If the authorization data element that could reveal the client's identity is meant to restrict the use of the ticket or limit the rights otherwise conveyed in the ticket, it can't be removed just 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 applies to both critical and optional authorization data.
If the authorization data element is unknown, the TGS MAY remove it, 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's 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's undesirable to disclose that 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 client's authentication path. The unordered set of realms in the transited field, if present, can reveal which realm may potentially be the client's realm 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 ✨

okay so in both AS and TGS exchanges, the realm field in the KDC request is ALWAYS the realm of the target KDC 🎀, even when the client wants an anonymous ticket. the anonymous realm does NOT go in there, bestie 💅

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 🙈 that's the whole point of anonymous, periodt 🦋

unless anonymous PKINIT is used, if a client requires anonymous communication, then the client MUST check that the ticket in the reply is actually anonymous 🔍 it does this by looking for the anonymous ticket flag in the flags field of the EncKDCRepPart. why do we have to double-check? because KDCs ignore unknown KDC options 💀 so a KDC that doesn't understand the anonymous KDC option won't throw an error. it'll just hand you a normal ticket, and you'd never know unless you checked 😭

after that, the subsequent client and server communications proceed as described in [RFC4120] 🌸

ngl this one is important: the anonymous principal name and realm only apply to the client in Kerberos messages 👑. the server CANNOT be anonymous in any Kerberos message under this spec. the server always has a real identity 💜

a server accepting an anonymous service ticket can assume that later requests using the same ticket came from the same client ✨. requests with different tickets are likely from different clients. it's giving detective energy 🕵️‍♀️

last thing for this section: when a server gets an anonymous ticket, the transited policy check works the same way as for a normal ticket IF the client's realm is not the anonymous realm 🧚. if the client realm IS the anonymous realm, then absent other information, any realm in the authentication path is allowed by the cross-realm policy check. so yeah, a bit of a wide-open door 🚪

5. Interoperability Requirements 🫶

okay the main vibe here: conforming implementations MUST support the anonymous principal with a non-anonymous realm 🔥. they MAY also support the anonymous principal with the anonymous realm using anonymous PKINIT, but that part is optional 🌈

6. GSS-API Implementation Notes 🧚‍♀️

so GSS-API defines the name_type GSS_C_NT_ANONYMOUS [RFC2743] to represent the anonymous identity 🎀. on top of that, 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 matches the GSS-API anonymous principal 🙈. BUT a principal with the anonymous principal name and a non-anonymous realm is an authenticated principal 💅, so it does NOT correspond to the GSS-API anonymous principal with the GSS_C_NT_ANONYMOUS name type. don't mix these up, it's giving identity crisis 😭

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 🍓. the same syntax has to be used along with the name type GSS_C_NT_ANONYMOUS when displaying and exporting the anonymous principal with the anonymous realm 💜.

at the GSS-API [RFC2743] level, an initiator or client asks for an anonymous principal with the anonymous realm by asserting the "anonymous" flag when calling GSS_Init_Sec_Context() 🦋. the GSS-API implementation MAY provide its own implementation-specific ways of requesting an anonymous principal with a non-anonymous realm ✨.

GSS-API doesn't know about or define "anonymous credentials" 🫠, so the printable name of the anonymous principal will rarely be used by or matter to the initiator or client. it matters for the acceptor or server, though 👑, when it makes an authorization decision based on the initiator name returned from the acceptor side once the security context is established.

A GSS-API initiator MUST carefully check the resulting context attributes from the initial call to GSS_Init_Sec_Context() when requesting anonymity 🚨. the reason: as in the GSS-API tradition and for backwards compatibility, anonymity is just another optional context attribute. the mechanism might not recognize the attribute at all, or anonymity might be unavailable for some other reason. if that happens, 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, and that's something that can rarely be "undone" 😭💀

Portable initiators are RECOMMENDED to use default credentials whenever possible 🌸, and to request anonymity only through the input anon_req_flag [RFC2743] to GSS_Init_Sec_Context() 🎀.

7. PKINIT Client Contribution to the Ticket Session Key 🔑

this section was motivated by protocol analysis of anonymous PKINIT (defined in this document) in building secure channels [RFC6113] and subsequent channel bindings [RFC5056] 🧠. so to let anonymous PKINIT apps form secure channels, all implementations of anonymous PKINIT need to meet the requirements in this section. otherwise there's no connection to the rest of the document, so it's kind of its own little world 🌍

PKINIT is useful for constructing secure channels 🦋. to make sure an active attacker can't create separate channels to the client and KDC with the same known key, it's desirable that neither the KDC nor the client unilaterally determines the ticket session key 👑. the specific reason the ticket session key is derived jointly gets discussed at the end of this section 👀.

so to get there, 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 then gets 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 the US-ASCII [ANSI.X3-4] string "PKINIT", and the input pepper2 is the 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]

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 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 binds the party that generated the session key to 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 do a Diffie-Hellman key exchange to get a shared key, and that key would become the 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 could just decrypt the session key and ticket using the Diffie-Hellman key from the attacker-KDC exchange, re-encrypt it with the key from the attacker-client exchange, and keep 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 the client can verify ✅. that's the iconic plot twist 👑.

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 values 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, and unneeded bits are removed from the tail ✂️✨.

8. Security Considerations 🔒

okay bestie, this part is serious, so listen up 🫶 Since KDCs just ignore options they don't understand, a client that needs anonymity has to check that the ticket it gets back is actually anonymous 🕵️‍♀️ A KDC that doesn't understand the anonymous option won't hand back an anonymous ticket, so you can't just assume you got one.

Using this mechanism means the client doesn't reveal its identity to the server 💖 But the client's identity can still leak to the KDC of the server principal (when that server is in a different realm from the client) and to 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. 😭 Please, please check it first!

Some servers really must never learn who the client is, like an anonymous poll service 🗳️ For those, the KDC can set a server-principal-specific policy so that any normal service ticket can never be issued to those server principals. Iconic behaviour, honestly 💅

Now, if the KDC that issued an anonymous ticket kept records linking identities to anonymous tickets, anyone who got hold of those records could break the anonymity 📂💀 It gets worse: most (for now all) KDCs answer requests the moment they arrive, so traffic analysis on the connection to the KDC lets an attacker match client identities to the anonymous tickets issued. Some parts of the tickets are sent in plaintext on the wire, so that matching is pretty straightforward for a third-party observer 🙈

A service that is authenticated by anonymous principals might also work out who the client is, by looking at quasi-static protocol information like the IP address a request came from, or by linking multiple uses of the same anonymous ticket 🧩 Not iconic for privacy, ngl.

Two mechanisms protect the client identity so that an attacker would never be able to see it sent to the KDC: the FAST facility with the hide-client-names option in [RFC6113], and the Kerberos5 starttls option [RFC6251] ✨🔐 Transport- or network-layer security between the client and the server also helps stop someone tracking a particular ticket and linking it to a user. And clients can limit how often a ticket is reused, which keeps ticket linking down 🌸

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. 🛡️ But 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 📝 No anonymous sneaking into the audit log, periodt.

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, so they now point to this document ✨

IANA also updated the reference for PA_PKINIT_KX (147) in the "Pre-authentication and Typed Data" registry so it points here too 🦋

10. References 📚

10.1. Normative References

Here are the normative refs, bestie. Every single one, exactly as written 🫶

[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>.

[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

And these are the informative ones, the nice-to-know reads 🌷

[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 gave 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 gave 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 🩷

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

That's the whole RFC, bestie! 🌈✨ You made it through every section, and the anonymity story is officially complete 💜👑

📦 where this page comes from

ietf: rfc8062 2017-02
💖 girlified by claude-haiku-5-5 on 2026-10-18: a language model's rewrite of the original, under its terms