RFC 6112

Anonymity Support for Kerberos

📅 published April 2011, from ietf

RFC 6112: Anonymity Support for Kerberos 🎀

Okay bestie, here's the title block 💖. This is an Internet Standards Track document from the IETF (Internet Engineering Task Force), and it's RFC 6112 🦋. It was published in April 2011, and it's giving official energy.

  • Authors: L. Zhu (Microsoft Corporation), P. Leach (Microsoft Corporation), and S. Hartman (Painless Security) ✨
  • Category: Standards Track
  • ISSN: 2070-1721
  • Date: April 2011
  • Updates: RFCs 4120, 4121, and 4556 💅 (this one is giving those older RFCs a glow-up)
  • Obsoletes: nothing is listed in the header

Abstract 🌸

So this doc adds extensions to Kerberos so a client can talk securely to an application service without revealing its identity, or without revealing more than its Kerberos realm 🫶. It also adds extensions that let a client get anonymous credentials without revealing its identity to the Kerberos Key Distribution Center (KDC) 🔒. And yes, it updates RFCs 4120, 4121, and 4556 ✨.

Status of This Memo 📜

This is an Internet Standards Track document. It's a product of the IETF, and it represents 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 info on Internet Standards, check Section 2 of RFC 5741.

Want the current status, any errata, or a way to send feedback? Head to http://www.rfc-editor.org/info/rfc6112 🦋.

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. Please read these carefully, because they spell out your rights and restrictions for this document 📖. Code Components pulled out of this document 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 document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The people controlling the copyright in some of that material may not have given the IETF Trust permission to allow modifications outside the IETF Standards Process. So unless you get an adequate license from whoever controls that copyright, 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. The exceptions are formatting it for publication as an RFC, or translating 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

1. Introduction ✨

Okay so picture this: the Kerberos [RFC4120] client might want to authenticate a server and/or protect its communications without revealing its own identity 🙈. Main example: an app that gives read access to a research database and lets anyone send 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 document specifies extensions to Kerberos 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 💜.

With these extensions, the client can request an anonymous ticket in two ways. It can reveal 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 🦋. Once it has the returned anonymous ticket, the client stays anonymous in later Kerberos exchanges with KDCs on the cross-realm authentication path and with the server it's talking to 🫶.

In this specification, the client realm in the anonymous ticket is the anonymous realm name when anonymous PKINIT is used to get the ticket. If the client is authenticated using its long-term keys, the client realm is its real realm name. Also, note that being a member of 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 🧚.

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 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]. The value of its name-type field is KRB_NT_WELLKNOWN [RFC6111], and the value of 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]

It's a new ticket flag, and it's used to show that a ticket is an anonymous one ✨.

An anonymous ticket is a ticket that has all of the following 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. That said, the ticket may still contain the client realm, intermediate realms on the client's authentication path, and authorization data that might give info related to the client's identity. For example, an anonymous principal that's only identifiable within a particular group of users can be implemented with authorization data, and if that authorization data is included in the anonymous ticket, it would disclose the client's membership of that group 🫣.
  • 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 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 🦋

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 like this: first, the protocol actions specific to AS exchanges, then the ones for TGS exchanges. After those comes a section on protocol actions common to both AS and TGS, plus the ones for subsequent exchanges 🧚.

4.1. Anonymity Support in AS Exchange 🌈

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. Then it requests an anonymous ticket in an AS exchange, where the KDC knows the client's identity ✨.

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 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. According to [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 it uses the anonymous ticket it got 🎀.

Care MUST be taken by the KDC not to reveal the client's identity in the authorization data of the returned ticket when it fills in the authorization data for an anonymous ticket 🫣.

The AD-INITIAL-VERIFIED-CAS authorization data, as defined in [RFC4556], contains the issuer name of the client certificate. This authorization is not applicable, so it MUST NOT be present in the returned anonymous ticket when anonymous PKINIT is used. When the client is authenticated (meaning anonymous PKINIT is not used) and it's undesirable to disclose that info 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 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 ✨

okay so this subsection is all about anonymous PKINIT 🎀 it's the sneaky-cute way to get a ticket without the KDC ever learning who you are 🦋

remember how the client can ask for an anonymous ticket by logging in with its own identity? well, there's another route where the KDC never sees your name at all 🫣 the client sets the client name to the anonymous principal in the AS exchange, then sends PA_PK_AS_REQ pre-authentication data [RFC4556] where the signerInfos field of the SignedData [RFC5652] is empty and the certificates field is absent. no keypair, no cap, so the client MUST choose the Diffie-Hellman key agreement method by filling in the Diffie-Hellman domain parameters in the clientPublicValue [RFC4556]. this whole combo of anonymous client name plus PKINIT is what we call anonymous PKINIT 💅 and if anonymous PKINIT is used, the realm name in the returned anonymous ticket MUST be the anonymous realm 👑

now the KDC's turn 🧚 when it gets an anonymous PKINIT request, it processes it according to Section 3.1.2 of [RFC4120]. it skips the checks on the client's signature and public key (like checking that the public key is bound to the client name), but it still does every other applicable check and carries on 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 isn't 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 gets generated according to Section 3.1.3 of [RFC4120], and PA_PK_AS_REP [RFC4556] pre-auth data goes into 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 it does reply anonymously, the signerInfos field of the SignedData [RFC5652] in PA_PK_AS_REP is empty, and the certificates field is absent. the server name in that anonymous reply holds the name of the TGS 🌸

on the client side 🫶 once the client gets a KDC reply with an anonymous ticket and PA_PK_AS_REP data, it can authenticate the KDC using the KDC's signature in PA_PK_AS_REP. but if the signature is missing (the reply is anonymous), the client MUST reject the returned ticket if it can't authenticate the KDC some other way 😭

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

when it shows up in a KDC error, PA_PKINIT_KX means "yep, I support anonymous PKINIT" ✨ and as Section 7 discusses, when it's 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 🌈

one more important bit 🚨 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 asking for an anonymous ticket in an AS exchange. and anonymity 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 asks for 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 TGS knows the client's identity 👀

fun fact: the client can completely hide its identity in an AS exchange using anonymous PKINIT, which we just covered in the previous section 🧚

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 already anonymous, the client name and client realm get copied from that ticket. if it's a normal ticket, the returned anonymous ticket contains the anonymous principal as the client name, and the client's true realm 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. and the client MUST use the client name and client realm returned in the KDC-REP in later message exchanges when it uses the anonymous ticket 💅

now the privacy part, which is seriously important 🔐 the TGS MUST take care not to reveal the client's identity in the authorization data of the returned ticket. when it propagates authorization data in the ticket or in the enc-authorization-data field of the request, the TGS MUST make sure the client's 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], going past the container levels so that all embedded authorization elements get interpreted 🧩 the TGS SHOULD NOT put identity-based authorization data into an anonymous ticket, because that kind of data typically reveals the client's identity 🙈 any new authorization data type MUST specify its processing rules for when an anonymous ticket is returned. and 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 cannot 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. 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 the 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 you'd rather not disclose that info about the client's identity, the AD-INITIAL-VERIFIED-CAS authorization data SHOULD be removed from an anonymous ticket 🌸

the TGS puts 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 leave out the previous realm if the cross-realm TGT is anonymous, to hide the client's authentication path. the unordered set of realms in the transited field, if it's there, can reveal which realm might 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 🧚‍♀️

in both AS and TGS exchanges, the realm field in the KDC request is always the realm of the target KDC, and never the anonymous realm, even when the client asks for 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, a client that needs anonymous communication MUST check that the ticket in the reply is actually anonymous, by looking for the anonymous ticket flag in the flags field of the EncKDCRepPart. why? because KDCs ignore unknown KDC options. a KDC that doesn't understand the anonymous KDC option won't return an error; it'll just quietly give you a normal ticket 💀

after that, the client and server communications carry on as described in [RFC4120] 💖

note that 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 specification 👑

a server accepting an anonymous service ticket can assume that later requests using the same ticket come from the same client ✨ requests with different tickets are likely to come from different clients 🦋

when an anonymous ticket comes in, the transited policy check works the same 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 🌍

5. Interoperability Requirements 🫶

okay the final bit for this part 💅 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 🔐

okay so GSS-API already has a name_type called GSS_C_NT_ANONYMOUS [RFC2743] for the anonymous identity 🫶. Then Section 2.1.1 of [RFC1964] gives us the single-string way to write a Kerberos principal name, using the name_type GSS_KRB5_NT_PRINCIPAL_NAME. The anonymous principal in the anonymous realm is the GSS-API anonymous principal ✨. BUT, and this is the tea 🍵, an anonymous principal name paired with a non-anonymous realm is an authenticated principal. So it does not match the GSS-API anonymous principal with GSS_C_NT_ANONYMOUS. The [RFC1964] name syntax for GSS_KRB5_NT_PRINCIPAL_NAME MUST be used when you import the anonymous principal name with a non-anonymous realm, and also when you display and export those names. And this syntax must 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 setting the "anonymous" flag when it calls GSS_Init_Sec_Context() 🎀. The GSS-API implementation MAY offer its own implementation-specific ways to ask for an anonymous principal with a non-anonymous realm 💅.

GSS-API doesn't know or define "anonymous credentials", so the (printable) name of the anonymous principal will rarely be used by or relevant to the initiator or client 🙈. The printable name matters for the acceptor or server, though, when it makes an authorization decision based on the initiator name that comes back from the acceptor side once the security context is successfully established 👑.

A GSS-API initiator MUST carefully check the resulting context attributes from the initial call to GSS_Init_Sec_Context() when it requests anonymity 🚨. That's because, as is the GSS-API tradition and for backwards compatibility, anonymity is just another optional context attribute. The mechanism might not recognise the attribute at all, or anonymity might not be available for some other reason. In that case the initiator MUST NOT send the initial security context token to the acceptor, because it will likely reveal the initiator's identity to the acceptor, and that is something that can rarely be "un-done" 😭.

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 🗝️

The stuff in this section was inspired by protocol analysis of anonymous PKINIT (which is defined in this document) for building tunneling channels [RFC6113] and the channel bindings that come after 🌈. So, to let apps built on anonymous PKINIT form channels, every implementation of anonymous PKINIT needs to meet the requirements in this section. Otherwise there's no connection to the rest of this document 🫶.

PKINIT is super useful for building tunneling channels ✨. To make sure an attacker can't create a channel with a given name, it's desirable that neither the KDC nor the client decides the ticket session key on their own 🔒. To get there, a KDC that follows this definition MUST encrypt a randomly generated key, called the KDC contribution key, inside the PA_PKINIT_KX padata (defined right after this) 🎁. 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 American Standard Code for Information Interchange (ASCII) [ASAX34] string "PKINIT", and the input pepper2 is the 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, for example when PKINIT is used with 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 that the KDC randomly generated 🧁. 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 checks 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 isn't in the KDC reply, or if the ticket session key of the returned ticket isn't the combined key of the KDC contribution key and the reply key when PA-PKINIT-KX is 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)

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 as many bits as the random-to-key() [RFC3961] function needs for the encryption type of the resulting key, and unneeded bits are removed from the tail ✂️.

8. Security Considerations 🚨

Since KDCs ignore unknown options, a client that needs anonymous communication has to make sure the returned ticket really is anonymous 👀. That's because a KDC that doesn't understand the anonymous option won't return an anonymous ticket. Yikes 💀.

By using the mechanism in this specification, the client doesn't reveal its identity to the server. BUT the client identity may still be revealed to the KDC of the server principal (when the server principal is in a different realm from the client), and to any KDC on the cross-realm authentication path 😱. The Kerberos client MUST verify that the ticket being used really is anonymous before it talks to the server, otherwise the client's identity may be revealed by accident 🫠.

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 NEVER gets issued to these server principals 🗳️.

If the KDC that issued an anonymous ticket kept records linking identities to anonymous tickets, then anyone who got hold of those records could break the anonymity 📂. Also, the implementations of most (for now, all) KDCs respond to requests at the time they're received. So traffic analysis on the connection to the KDC lets an attacker match client identities to the anonymous tickets issued 🕵️. Because some plaintext parts of the tickets are exposed on the wire, that matching is pretty straightforward for a third-party observer 😬. A service that's authenticated by anonymous principals may be able to infer the client's identity by looking at and linking quasi-static protocol information, like the IP address a request came from, or by linking multiple uses of the same anonymous ticket 🔗.

Two mechanisms protect the client identity so an attacker never gets to see the client identity sent to the KDC: the FAST facility with the hide-client-names option in [RFC6113], and the Kerberos5 starttls option [STARTTLS] 🛡️. Transport or network layer security between the client and the server helps stop a particular ticket from being tracked back to a user ✨. And clients can limit how often a ticket is reused, which makes ticket linking harder 🌸.

The client's real identity is not revealed when the client is authenticated as the anonymous principal 🎭. Application servers MAY reject the authentication, for example to 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 edit early revisions of this document 💕.

Clifford Neuman contributed the core notions of this document 🧠.

Ken Raeburn reviewed the document and offered 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 👑🌈.

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 📚✨

okay bestie, here are the big docs this spec leans on, the ones that are literally the foundation 💅

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

11.2. Informative References 🧠

these are the extra-credit reads, super helpful but not strictly required to build it 🙈

  • [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 💌

the lovely humans who wrote this, and how to reach them 🫶

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
📦 where this page comes from