RFC 6806
Kerberos Principal Name Canonicalization and Cross-Realm Referrals
Kerberos Principal Name Canonicalization and Cross-Realm Referrals 🎀
Okay bestie, let's get into RFC 6806! 🦋 The title block is giving: it's an IETF doc, RFC number 6806, on the Standards Track (so it's an official Internet standard, no cap). S. Hartman (Painless Security) is the editor, with K. Raeburn (MIT) and L. Zhu (Microsoft Corporation) as co-authors, and it dropped in November 2012 with ISSN 2070-1721. It updates RFC 4120 and doesn't obsolete anything. 💅
Abstract ✨
Okay so this memo is all about how a Kerberos Key Distribution Center (KDC) can answer ticket requests from clients that don't have detailed config info about the realms of users or services. 💖 The KDC handles requests for principals in other realms by sending back either a referral error or a cross-realm Ticket-Granting Ticket (TGT) to another realm on the referral path. The client then uses that referral info to reach the target principal's realm and grab the ticket. 🧚 The memo also gives a way to check that a request hasn't been messed with in transit. It updates RFC 4120. 😭
Status of This Memo
This is an Internet Standards Track document. 🔥
This doc is a product of the Internet Engineering Task Force (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). For more on Internet Standards, check Section 2 of RFC 5741. 🌸
For the current status, any errata, and how to give feedback, go to http://www.rfc-editor.org/info/rfc6806. 🫶
Copyright Notice
Copyright (c) 2012 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) as in effect on the date of publication. Please read these carefully, because they spell out your rights and restrictions for 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 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 person(s) controlling the copyright in some of that material may not have granted the IETF Trust the right to allow modifications outside the IETF Standards Process. Without an adequate license from those copyright holders, 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 exception is 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 . . . . . . . . . . . . . . 4
3. Requesting a Referral . . . . . . . . . . . . . . . . . . . . 4
4. Realm Organization Model . . . . . . . . . . . . . . . . . . . 5
4.1. Trust Assumptions . . . . . . . . . . . . . . . . . . . . 5
5. Enterprise Principal Name Type . . . . . . . . . . . . . . . . 6
6. Name Canonicalization . . . . . . . . . . . . . . . . . . . . 7
7. Client Referrals . . . . . . . . . . . . . . . . . . . . . . . 9
8. Server Referrals . . . . . . . . . . . . . . . . . . . . . . . 10
9. Cross-Realm Routing . . . . . . . . . . . . . . . . . . . . . 11
10. Caching Information . . . . . . . . . . . . . . . . . . . . . 11
11. Negotiation of FAST and Detecting Modified Requests . . . . . 12
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
13. Security Considerations . . . . . . . . . . . . . . . . . . . 13
13.1. Shared-Password Case . . . . . . . . . . . . . . . . . . . 16
13.2. Pre-Authentication Data . . . . . . . . . . . . . . . . . 16
14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
15.1. Normative References . . . . . . . . . . . . . . . . . . . 17
15.2. Informative References . . . . . . . . . . . . . . . . . . 17
Appendix A. Compatibility with Earlier Implementations of
Name Canonicalization . . . . . . . . . . . . . . . . 181. Introduction ✨
Okay so the current Kerberos Authentication Service (AS) and Ticket-Granting Service (TGS) implementations, as defined in [RFC4120], build principal names from a known user or service name plus a realm. 🎀 A service name usually comes from the name of the service and the DNS host name of the computer providing it. Lots of Kerberos deployments use one single realm where everybody is in the same place, which is simple. 💅 But when there are multiple Kerberos realms, the client needs to figure out which realm a user or service is in before it makes an AS or TGS request, and traditionally that means you have to configure the client for it. 😭
When you've got multiple realms, users have to know what realm they're in before they can get a Ticket-Granting Ticket (TGT) through an AS request. 🙈 But honestly, people would rather use a familiar name that isn't tied to their Kerberos realm, like an email-style name from [RFC5322]. This memo describes a way for a user to specify a user principal name that's an alias for their Kerberos principal name. That alias is the name they'd use to get a TGT from a Kerberos KDC. The user principal name no longer has a direct link to the Kerberos principal or realm, so the administrator can move a user's principal to other realms and the user never has to notice. ✨
Once you've got a TGT, you want to access services in any Kerberos realm you have an authentication path to, from your principal's realm. 🦋 To do that, the client needs to know which realm the target service principal is in before it makes the TGS request. Kerberos implementations usually keep a table that maps DNS host names to Kerberos realms. The host name the user supplied, or its domain part, gets looked up in that table. (That lookup is often based on whatever host name lookup was done with insecure DNS queries, which breaks [RFC4120].) The realm that comes back is then used to complete the target service principal name. Even if insecure DNS queries weren't used, managing that table is still a headache. 💀
This traditional approach means every client needs really detailed config about the hosts providing services and their realms. 🍓 That client-side config is super costly to administer, especially when there are lots of realms and computers in the environment. 😩
This memo fixes these problems and makes administration easier by cutting down how much config each Kerberos computer needs. 👑 It describes a mechanism that lets the KDC handle name canonicalization, provide principal aliases for users and services, and figure out the trusted realm authentication path by generating referrals to other realms to locate principals. 🌈
This memo introduces two kinds of KDC referrals:
- Client referrals, in which the client doesn't know which realm contains a user account.
- Server referrals, in which the client doesn't know which realm contains a server account.
Both of these open up new opportunities for an attacker. 🔥 To avoid those attacks, the memo provides a mechanism to protect the integrity of the request between the client and the KDC. This mechanism complements the Flexible Authentication Secure Tunnels (FAST) facility provided in [RFC6113]. The memo also provides a mechanism to negotiate whether FAST is available. Among other benefits, this can be used to protect errors generated by the referral process. 🧚
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. Requesting a Referral 🌸
Okay so to request referrals as defined in later sections, the Kerberos client MUST explicitly request the "canonicalize" KDC option (bit 15) [RFC4120] for the AS-REQ or TGS-REQ. 🔥 This flag tells the KDC that the client is ready to receive a reply containing a principal name other than the one it requested. 💅
KDCOptions ::= KerberosFlags
-- canonicalize (15)
-- other KDCOptions values omittedWhen sending names with the "canonicalize" KDC option, the client should expect that names in the KDC's reply MAY be different from the name in the request. 🦋 A referral TGT is a cross-realm TGT that is returned with the server name of the ticket being different from the server name in the request [RFC4120]. ✨
4. Realm Organization Model 🍓
This memo assumes the world of principals is arranged on multiple levels: the realm, the enterprise, and the world. 🌈 A KDC may issue tickets for any principal in its realm, or cross-realm tickets for realms it has a direct cross-realm relationship with. 👑 The KDC also has access to a trusted name service that can resolve any name from within its enterprise into a realm closer along the authentication path to the service. 🧚 That trusted name service means there's no need for an untrusted DNS lookup for name resolution. 🙌
Here's an example config, where the lines show cross-realm relationships:
EXAMPLE.COM
/ \
/ \
ADMIN.EXAMPLE.COM DEV.EXAMPLE.COMIn this setup, every user in the EXAMPLE.COM enterprise can have a principal name like alice@EXAMPLE.COM, all with the same realm portion. 💖 On top of that, servers at EXAMPLE.COM should be able to have DNS host names from any DNS domain, no matter which Kerberos realm their principals live in. 🎀
4.1. Trust Assumptions 🔐
Okay so, every cross-realm relationship has two players. There's the issuing realm, which mints a cross-realm ticket, and the consuming realm, which uses that ticket. Just by existing, this relationship implies a level of trust that the consuming realm gives the issuing realm. 🫶
Whenever a service in the consuming realm allows an authentication path that goes through the issuing realm, that service is trusting the issuing realm to accurately represent who the authenticated principal is and to accurately represent any information about the transited path. And if the consuming realm's KDC sets the transited policy checked flag, the KDC is making that same trust assumption a service would. Bestie, that's a whole vibe. 💅
This trust is transitive across a multi-hop authentication path. The service's realm trusts every hop along the path that's closer to the client to accurately represent the authenticated identity and the transited information. So any KDC along that path could impersonate the client. Yikes 😭
KDC-signed or KDC-issued authorization data usually implies extra trust. How much trust that implies, from both a security and an operational point of view, is still an ongoing conversation while this specification is being developed. Because of that, the discussion is out of scope for this memo. 🙈
Administrators have a few tools to limit the trust that cross-realm relationships cause. A service or KDC can control which authentication paths are acceptable. For example, if a given realm isn't permitted on the authentication path for a particular client, then that realm can't affect the trust placed in that client principal. ✨ Consuming realms can also have a lot of control by deciding which principals go on an access-control list. If no client using a given issuing realm in its authentication paths is permitted to access a resource, then that issuing realm isn't trusted in access decisions about that resource. Main character energy for the access list 👑
Here's the tea: creating a cross-realm relationship implies pretty little inherent trust in the issuing realm. The big trust only kicks in once principals that depend on that issuing realm get access to resources. 🌸 That said, two deployment characteristics can make the trust from the initial relationship bigger. First, a number of realms give any principal access to some resources. Access decisions about those resources involve a degree of trust in every issuing realm in the transited graph. Second, lots of realms don't limit which principals their users can grant access to. In those realms, creating a cross-realm relationship hands the decision to trust that realm over to the users of the consuming realm. In that situation, creating the cross-realm relationship is the main trust decision point under the administrator's control. Iykyk, it's a big deal 🍓
5. Enterprise Principal Name Type 🎀
The NT-ENTERPRISE principal name type holds one component: a string of realm-defined content. It's meant to be used as an alias for another principal name in some realm in the enterprise. It's used to carry the alias name, not the real principal names inside the realms, so it's only useful when name canonicalization is requested. 🧚
The whole point is to unify email and security principal names. For example, every user at EXAMPLE.COM could have a client principal name like joe@EXAMPLE.COM, even though those principals live in multiple realms. That global name is just another alias for the true client principal name, which tells you which realm holds the principal. So the accounts alice in the realm DEV.EXAMPLE.COM and bob in ADMIN.EXAMPLE.COM could log on as alice@EXAMPLE.COM and bob@EXAMPLE.COM. Cute, right? 💖
This uses a new principal name type, because the KDC-REQ message only has a single client realm (crealm) field, and the realm portion of this name matches the Kerberos realm the request is made to. So the entire name alice@EXAMPLE.COM is sent as a single component in the client name field of the AS-REQ message, with a name type of NT-ENTERPRISE [RFC4120] (plus the local realm name). If the client account lives in the local realm, the KDC recognizes this name type and transforms the requested name into the true principal name. The true principal name can have a different name type than the requested one. Typically, the true principal name will be an NT-PRINCIPAL [RFC4120]. 🦋
6. Name Canonicalization 🌈
A service or account can have multiple principal names. For example, if a host is known by several names, host-based services on it might be known by several names too, so the client doesn't need a secure directory service to figure out the right host name to use. To avoid having to update the host every time a new alias shows up, the KDC can hand the mapping information to the client during credential acquisition. Smart, no? ✨
If the "canonicalize" KDC option is set, the KDC MAY change the client and server principal names and types in the AS response and ticket from the ones in the request. Names MUST NOT be changed in the response to a TGS request, even though it's super common for KDCs to keep a set of aliases for service principals. No matter which alias a client asks for, the same service key gets used. The difference is that in the TGS request, the client gets a ticket for the alias it requested. Services MUST NOT make distinctions based on which alias is in the issued ticket, because the service name in a ticket isn't cryptographically protected and can be changed by parties other than the KDC. Don't be that service 🙅♀️
For example, the AS request might specify a client name of "bob@EXAMPLE.COM" as an NT-ENTERPRISE name with the "canonicalize" KDC option set, and the KDC will come back with a client name of "104567" as an NT-UID [RFC4120]. 🎀
(It's assumed that the client finds out whether the KDC supports the NT-ENTERPRISE name type through out-of-band mechanisms. 🙈)
See Section 11 for a mechanism to detect modification of the request between the client and KDC. But for the best protection, Flexible Authentication Secure Tunneling (FAST) [RFC6113] or another mechanism that protects the entire KDC exchange SHOULD be used. Clients MAY reject responses from a KDC where the client or server name is changed if the KDC doesn't support such a mechanism. 😭
Clients SHOULD reject an AS response that changes the server name, unless the response is protected by such a mechanism or the new server name is one the client explicitly expected. For example, many clients let the realm name change in an AS response, even when the response isn't protected. See Section 13 for a discussion of the tradeoffs in allowing unprotected responses. Tradeoffs are everything 💅
To allow authorization decisions to be based on aliases as well as on the canonicalized form of a principal name, the KDC MAY include the following authorization data element, wrapped in AD-KDC-ISSUED, in the initial credentials, and copy it from a ticket-granting ticket into additional credentials:
AD-LOGIN-ALIAS ::= SEQUENCE { -- ad-type number 80 --
login-aliases [0] SEQUENCE (SIZE (1..MAX)) OF PrincipalName,
...
}The login-aliases field lists one or more of the aliases the principal is known by. 🍓
Besides allowing authorization based on aliases, this also allows user-to-user exchanges where the party receiving the authenticator only knows the other party by an alias. The recipient of such an authenticator SHOULD check the AD-LOGIN-ALIAS names, if present, in addition to the normal client name field, against the identity of the party it wants to authenticate with. Either one should be allowed to match. (Heads up: this isn't backwards compatible with [RFC4120]. If the server side of the user-to-user exchange doesn't support this extension and doesn't know the true principal name, authentication may fail when the alias is sought in the client name field.) 💀
The use of AD-KDC-ISSUED authorization data elements in cross-realm cases hasn't been well explored at the time of writing, so we'll only specify including this data in the one-realm case. The AD-LOGIN-ALIAS information SHOULD be dropped in the general cross-realm case. However, a realm MAY implement a policy of accepting and re-signing alias information provided by certain trusted realms in the cross-realm ticket-granting service (wrapping it in a new AD-KDC-ISSUED element). 🦋
The canonical principal name for an alias MUST NOT be in the form of a ticket-granting service name, because in the case of server name canonicalization, that would be read as a cross-realm referral, which is described below. 🌸
7. Client Referrals ✨
Okay bestie, the simplest kind of ticket referral is when a user asks for a ticket with an AS-REQ 💖. The client machine sends that AS-REQ to a realm it trusts to map principals, like its own realm 🏠. So for alice@EXAMPLE.COM, the client MAY optimistically send the request to EXAMPLE.COM 🦋. The realm in the AS-REQ is always the name of the realm the request is for, as specified in [RFC4120] ✨.
Then the KDC tries to find the name in its own local account database 🔍. If the account is there in the realm of the request, it SHOULD send back a KDC reply with the right ticket 🎀.
If the account isn't in the realm from the request and the "canonicalize" KDC option is set, the KDC may look up the client principal name using some kind of name service or directory service 🧚. If that lookup fails, it MUST return KDC_ERR_C_PRINCIPAL_UNKNOWN [RFC4120] 💀. If the lookup works, it MUST return KDC_ERR_WRONG_REALM [RFC4120] 👑. In that error message, the crealm field will hold either the client's true realm or another realm that MAY have better info about it 🌈. The client MUST NOT use the cname from that error message 🙈.
If the client gets a KDC_ERR_WRONG_REALM error, it issues a brand new AS request with the same client principal name it used for the first one. That request goes to the realm named in the realm field of the Kerberos error message from the first request 🦋. (The client realm name gets updated in the new request to point at this new realm.) The client SHOULD repeat these steps until it finds the true realm of the client 💅. To avoid infinite referral loops, an implementation should limit the number of referrals. A suggested limit is 5 referrals before giving up 🛑.
Since the same client name goes to both the referring realm and the referred-to realm, both realms have to recognize the same client names 🫶. In particular, the referring realm cannot (usefully) define principal name aliases that the referred-to realm won't know 🙃.
The true principal name of the client, returned in AS-REP, can be validated in a later TGS message exchange. Its value gets sent back to the KDC through the authenticator in the PA-TGS-REQ padata [RFC4120] 🔁. However, this means trusting the referred-to realm's KDCs 😬. Clients should limit the referral mappings they accept to realms trusted through some local policy. A few factors that might go into such a policy include:
- Any realm indicated by the local KDC, if the returned
KRB-ERRORmessage is protected by some additional means, for example, FAST - A list of realms configured by an administrator
- Any realm accepted by the user when explicitly prompted
One common approach is to limit referrals to realms that can build an authentication path back to the service principal of the local machine 🏡. This tends to work well when realms are mostly inside one organization and every realm that can form an authentication path back to the local machine has a reasonable level of mapping trust 🌸. Deployments with more complex trust, for example, a high probability of malicious realms, are likely to need more complex policy. They MAY need to prompt the user before accepting some referrals 🚨.
There is currently no provision for changing the client name in a client referral response 🙅♀️.
8. Server Referrals
Okay so the main difference with server referrals is that the KDC hands back a referral TGT instead of an error message like it does with client referrals 🎁.
If the "canonicalize" flag in the KDC options is set, and the KDC can't find the principal locally (either as a regular principal or as an alias for another local principal), the KDC MAY return a cross-realm ticket-granting ticket. That TGT goes to the next hop on the trust path toward a realm that may be able to resolve the principal name 🛤️.
The client uses this referral info to request a chain of cross-realm ticket-granting tickets until it reaches the realm of the server. Then it can expect to receive a valid service ticket 🎟️.
Still, an implementation should limit how many referrals it processes so it doesn't get stuck in an infinite referral loop 🌀. A suggested limit is 5 referrals before giving up.
The client may cache the mapping of the requested name to the name of the next realm to use, along with the principal name to ask for (see Section 10) 🧠.
Here's an example of a client asking for a service ticket for a service in realm DEV.EXAMPLE.COM, where the client lives in ADMIN.EXAMPLE.COM 🍓.
+NC = Canonicalize KDCOption set
C: TGS-REQ sname=http/foo.dev.example.com +NC to ADMIN.EXAMPLE.COM
S: TGS-REP sname=krbtgt/EXAMPLE.COM@ADMIN.EXAMPLE.COM
C: TGS-REQ sname=http/foo.dev.example.com +NC to EXAMPLE.COM
S: TGS-REP sname=krbtgt/DEV.EXAMPLE.COM@EXAMPLE.COM
C: TGS-REQ sname=http/foo.dev.example.com +NC to DEV.EXAMPLE.COM
S: TGS-REP sname=http/foo.dev.example.com@DEV.EXAMPLE.COMNote that any referral or alias processing of the server name in user-to-user authentication should use the same data as client name canonicalization or referral. Otherwise, the name one user used to log in might not be useable by another for user-to-user authentication to the first 🚫.
9. Cross-Realm Routing
[RFC4120] lets a KDC return a closer referral ticket when a cross-realm TGT is requested 🗺️. This specification extends that behavior when the canonicalize flag is set. When this flag is set, a KDC MAY return a TGT for a realm closer to the service, for any service, as discussed in the previous section ✨. When a client follows such a referral, it includes the realm of the referred-to realm in the generated request 💌.
When the canonicalize flag is not set, the rules defined in RFC 4120 apply 📜.
10. Caching Information
Sometimes the client wants extra credentials for the same service principal, maybe with different authorization-data restrictions or other changed attributes 🔄. A server referral from a KDC can be taken as a sign that the requested principal doesn't currently exist in the local realm 👀. Clearly, it would cut down on network traffic if clients could cache that info and use it when getting the second set of credentials for a service. Otherwise they'd always have to recheck with the local KDC to see if the name has been created locally 😩.
When the TGT expires, the previously returned referral from the local KDC should be considered invalid. The local KDC must be asked again for information about the desired service principal name ⏰. (Note that the client may get back multiple referral TGTs from the local KDC to the same remote realm, each with different lifetimes. The lifetime information SHOULD be properly associated with the requested service principal names. Simply having another TGT for the same remote realm doesn't extend the validity of previously acquired info about one service principal name 🧾.)
So KDC authors and maintainers should consider which factors (e.g., DNS alias lifetimes) they may or may not want to fold into credential expiration times when referrals are involved 🧐.
11. Negotiation of FAST and Detecting Modified Requests
Implementations of this specification MUST support the FAST negotiation mechanism described in this section 🔐. This mechanism detects KDC requests that an attacker modified, as long as those requests still get a reply instead of an error. On top of that, it gives a secure way to check whether a KDC supports FAST 🕵️♀️.
Clients conforming to this specification MUST send new pre-authentication data of type PA-REQ-ENC-PA-REP (149) in all AS requests. They MAY send this padata type in TGS requests too 💅. The value of this padata item SHOULD be empty, and its value MUST be ignored by a receiving KDC. Sending this padata item signals support for this negotiation mechanism 🚦. KDCs conforming to this specification must always set the ticket flag enc-pa-rep (15) in all the tickets they issue. This ticket flag shows that the KDC supports the mechanism 🎫.
The KDC response [RFC4120] is extended to support an extra field that holds encrypted pre-authentication data 🧩.
EncKDCRepPart ::= SEQUENCE {
key [0] EncryptionKey,
last-req [1] LastReq,
nonce [2] UInt32,
key-expiration [3] KerberosTime OPTIONAL,
flags [4] TicketFlags,
authtime [5] KerberosTime,
starttime [6] KerberosTime OPTIONAL,
endtime [7] KerberosTime,
renew-till [8] KerberosTime OPTIONAL,
srealm [9] Realm,
sname [10] PrincipalName,
caddr [11] HostAddresses OPTIONAL,
encrypted-pa-data [12] SEQUENCE OF PA-DATA OPTIONAL
}The encrypted-pa-data element MUST be absent unless either the "canonicalize" KDC option is set or the PA-REQ-ENC-PA-REP padata item is sent 🙅.
If the PA-REQ-ENC-PA-REP padata item is sent in the request, then the KDC MUST include a PA-REQ-ENC-PA-REP padata item in the encrypted-pa-data item of any KDC reply it generates 🎁. The PA-REQ-ENC-PA-REP pa-data value holds the checksum computed over the type AS-REQ or TGS-REQ in the request. The checksum key is the reply key, the checksum type is the required checksum type for the encryption type of the reply key, and the key usage number is KEY_USAGE_AS_REQ (56) 🔢. If the KDC supports FAST, then the KDC MUST include a padata of type PA-FX-FAST in any encrypted-pa-data sequence it generates. The padata item MUST be empty when sending, and the contents of the padata item MUST be ignored when receiving 🌈.
A client MUST reject a response it sent PA-REQ-ENC-PA-REP for if the ENC-PA-REP ticket flag is set and the PA-REQ-ENC-PA-REP padata item is absent, or if the checksum isn't successfully verified 🚨. Don't skip this one, bestie 😭.
12. IANA Considerations
PA-REQ-ENC-PA-REP has been registered in the Kerveros "Pre-authentication and Typed Data" registry <http://www.iana.org/assignments/kerberos-parameters> 📋✨
13. Security Considerations 🔐💅
okay bestie, this is the part where we get SERIOUS 😭🫶 it's giving "read every word before you ship" energy, so buckle up.
For the AS exchange case, the logon mechanism has to be careful about trusting a name the user never actually authenticated with 🙈 like, the name someone types in a logon screen might not be the name they authenticate as, especially if a KDC_ERR_WRONG_REALM error came back. The Kerberos naming info that actually counts for logon is the client name and client realm in the service ticket for the workstation, the one the user got with their initial TGT 🎟️ So instead of trusting the client name in the AS response, a workstation SHOULD do an AP-REQ authentication against itself as a service and use the client name in the ticket the KDC issued for its service. Trust the ticket, not the vibes ✨
How the client name and client realm get mapped to a local account is a local decision 🧚 but the client logon mechanism MUST use extra info, like the client realm and/or authorization attributes from the service ticket the user presented to the workstation, when mapping logon credentials to a local account. Non-negotiable, periodt 💅
Now, not every field in a KDC reply defined by [RFC4120] is protected 😬 None of the fields that [RFC4120] defines for an AS request are protected, and some info in a TGS request might not be either. The referrals mechanism opens up several attack opportunities because of these unprotected fields. FAST [RFC6113] can completely mitigate these issues by protecting both the KDC request and response 🛡️ BUT, FAST requires that a client get an armor ticket before authenticating, and not every realm lets every client obtain one. Also, while it's expected to be uncommon, a client might want to use name canonicalization while obtaining an armor ticket. The mechanism in Section 11 detects modification of the request between the KDC and client, so it helps mitigate some attacks, but it's not the whole fix 🙃
There's also a big widely deployed base of implementations that use name canonicalization or server referrals WITHOUT the negotiation mechanism or FAST 💀 So implementations might only have the limited protection from [RFC4120], or the negotiation mechanism discussed here, or FAST. All three situations matter from a security standpoint, so don't skip any of them, bestie.
⚠️ An attacker cannot mount a downgrade attack against a client. The negotiation mechanism in this document is securely indicated by the presence of a ticket flag, so a client WILL detect if the facility was available but not used.
Okay, but here's the plot twist 🍿 an attacker CAN strip the indication that a client supports the negotiation facility. The client learns from the response that this happened, but the KDC won't learn that the client is under attack. So for a single round-trip Kerberos exchange, the KDC might think everything went great while the client knows it got attacked 😭 Packet loss or client failure can produce a similar result, and that is not a significant vulnerability, so chill.
The negotiation facility in this document securely indicates the presence of FAST 🔥 So if a client wants to use FAST whenever it's available, an attacker cannot force the client to downgrade away from FAST. An attacker MAY be able to stop a client from getting an armor ticket, for example by answering a request for anonymous Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) [RFC4556] with an error response 🙄
If FAST is used, then the communications between the client and KDC are protected 🥹 However, name canonicalization puts a new responsibility on mapping principals onto the KDC. That can increase the number of KDCs involved in an authentication, which adds more trusted third parties to the exchange. More hands in the cookie jar, more risk 🍪
If only the negotiation mechanism is used, the request from the client to the KDC is protected, but not all of the response is. In particular, the client name is NOT protected, and neither is the ticket 😬 An attacker can potentially modify these fields. Changing the client name results in a denial of service. When the client tries to authenticate to a service (including the TGS), it builds an AP-REQ message. That message includes a client name that MUST match the client name in the ticket according to [RFC4120]. So if the client name gets changed, the resulting ticket will fail when used. This is undesirable because the authentication gets separated from the later failure, which can confuse problem determination 🧩 If the ticket gets replaced with another ticket, later authentication to a service will fail, because the client won't know the session key for the other ticket. If the ticket is simply modified, authentication to a service will fail just like it does under [RFC4120]. More significant attacks are possible if a KDC violates the requirements of [RFC4120] and issues two tickets with the same session key, or if a service violates the requirements of [RFC4120] and doesn't check the client name against the one in the ticket. Yikes 💀
There's an additional attack possible when FAST is NOT used against KDC_ERR_WRONG_REALM 🚨 Since this is an error response and not an AS response, it isn't protected by the negotiation mechanism. So an attacker may be able to convince a client to authenticate to a realm other than the one intended. If the attacker is off-path, this could give them an advantage in attacking the client's credentials. Also, check the discussion of shared passwords below 👀
It gets even more serious if no protection beyond [RFC4120] is used 😱 In this case, neither the client name nor the service name is protected between the client and KDC. In the general case, if an attacker changes the client name, authentication will fail because the client won't have the right credentials (password, certificate, or other) to authenticate as the user the attacker picked. Still, see the discussion of shared passwords below 🙃 Changing the server name can be a VERY significant attack. For example, if a user is authenticating in order to send some confidential info, the attacker could grab that info by pointing the user at a server under the attacker's control 🕵️ The server name in the response IS protected by [RFC4120], but the one in the request is NOT. Thankfully, users are typically authenticating to the "krbtgt" service in an AS exchange 🙌 Clients that permit changes to the server name when no protection beyond [RFC4120] is in use SHOULD carefully restrict which service names are acceptable. One critical case to consider is the password-changing service. When a user authenticates to change their password, they use an AS authentication directly to the password-changing service. Clients MUST restrict service name changes enough that the client ends up talking to the correct password-changing service. No wrong turns allowed 🚫
13.1. Shared-Password Case 🔑
This is a special case to examine: when the user is known (or correctly suspected) to use the same password for multiple accounts 👯 A man-in-the-middle attacker can either alter the request on its way to the KDC, changing the client principal name, or reply to the client with a response the KDC previously sent in reply to a request from the attacker. The client can then decrypt the response, since the user has the key. If the default "salt" generated from the principal name is used to produce the user's key, a PA-ETYPE-INFO or PA-ETYPE-INFO2 preauth record may need to be added or altered by the attacker, so the client software generates the key needed for the message it will receive. None of this requires the attacker to know the user's password, and without further checking, it could cause the user to unknowingly use the wrong credentials 😵💫
In normal operation as described in [RFC4120], a generated AP-REQ message includes a copy of the client's idea of its own principal name in the Authenticator field. If this differs from the name in the KDC-generated ticket, the application server will reject the message 🙅♀️
With client name canonicalization as described in this document, the client may get its principal name from the response from the KDC. Using the wrong credentials may give an attacker an advantage 😤 For example, if a client uses one principal for administrative operations and another for less privileged operations, an attacker may coerce the client into using the wrong privilege, either to make some later operation succeed or to make it fail. Chaotic evil behavior 💀
13.2. Pre-Authentication Data 🧾
In cases of credential renewal, forwarding, or validation, if credentials are sent to the KDC that are NOT an initial ticket-granting ticket for the client's home realm, the encryption key used to protect the TGS exchange is one known to a third party (namely, the service the credential was issued for) 👀 So in that kind of exchange, the protection described earlier may be compromised by the service. This is not generally believed to be a problem 🤷♀️ If it turns out to be one, some form of explicit TGS armor could be added to FAST.
14. Acknowledgments 🫶
John Brezak, Mike Swift, and Jonathan Trostle wrote the initial version of this document 🌟
Karthik Jaganathan contributed to earlier versions 💜
Sam Hartman's work on this document was funded by the MIT Kerberos Consortium 🎀
15. References 📚
15.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
Kerberos Network Authentication Service (V5)", RFC 4120,
July 2005.
[RFC6113] Hartman, S. and L. Zhu, "A Generalized Framework for
Kerberos Pre-Authentication", RFC 6113, April 2011.15.2. Informative References
[RFC4556] Zhu, L. and B. Tung, "Public Key Cryptography for Initial
Authentication in Kerberos (PKINIT)", RFC 4556, June 2006.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, May 2008.
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
October 2008.
[XPR] Trostle, J., Kosinovsky, I., and M. Swift, "Implementation
of Crossrealm Referral Handling in the MIT Kerberos
Client", Network and Distributed System Security
Symposium, February 2001.Appendix A. Compatibility with Earlier Implementations of Name Canonicalization ✨
Okay bestie, this appendix is all about the older name-canonicalization setup that shipped with Microsoft Windows 2000 and Windows 2003 🕰️. Those releases used an earlier form of it [XPR], and the differences are kinda iconic. Here's the tea 🫖:
- Windows includes an additional encrypted padata element 🔐. The preauth data type definition inside the encrypted preauth data looks like this:
PA-SVR-REFERRAL-INFO 20
PA-SVR-REFERRAL-DATA ::= SEQUENCE {
referred-name [1] PrincipalName OPTIONAL,
referred-realm [0] Realm
}}The referred-principal is never sent 🙈. The referred-realm shows up in TGS replies and holds the realm name of the realm the client is referred to. It's kinda redundant, since it matches the realm in the second component of the returned TGT 💅.
- When PKINIT [RFC4556] is used, the NT-ENTERPRISE client name gets encoded as a Subject Alternative Name (SAN) extension [RFC5280] in the client's X.509 certificate 📜. The
otherNamefield for this SAN extension has the type AnotherName [RFC5280]. Thetype-idfield of AnotherName isid-ms-sc-logon-upn(1.3.6.1.4.1.311.20.2.3), and itsvaluefield is a KerberosString [RFC4120]. That KerberosString is the single component in the name-string [RFC4120] sequence for the matching NT-ENTERPRISE name type. Main character energy 👑.
In Microsoft's current implementation, global catalogs make any domain in one forest reachable from any other domain in that same forest, or from a domain in another trusted forest, with 3 or fewer referrals 🌐. So what's a forest? It's a collection of realms with hierarchical trust relationships 🌳. There can be multiple trust trees in one forest, and each child and parent realm pair, plus each root realm pair, has bidirectional transitive direct trust between them 🫶.
Quick aside: the Microsoft implementation only lets one NT-ENTERPRISE alias exist. We might want to allow multiple aliases and even report them in AD-LOGIN-ALIAS, but since there was only ever one, that question never really came up 🙈.
Authors' Addresses 🦋
Sam Hartman (editor)
Painless Security
EMail: hartmans-ietf@mit.edu
Kenneth Raeburn
Massachusetts Institute of Technology
EMail: raeburn@mit.edu
Larry Zhu
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
US
EMail: lzhu@microsoft.com📦 where this page comes from
- ietf: rfc6806 2012-11
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms