Kerberos Principal Name Canonicalization and Cross-Realm Referrals
updates
- rfc-4120 — The Kerberos Network Authentication Service (V5)
Extracted elements (32)
Client referrals use an error response (KDC_ERR_WRONG_REALM) while server referrals use a cross-realm TGT response, because for client referrals the KDC cannot issue a ticket for a principal not in its realm, whereas for server referrals the KDC can return a useful credential (a cross-realm TGT) to advance the lookup chain.
The NT-ENTERPRISE name type was introduced to unify email and Kerberos principal names, allowing users to log on with a familiar alias (e.g., 'alice@EXAMPLE.COM') without knowing the actual realm of their Kerberos principal. This lets administrators move principals across realms transparently.
The realm organization model uses a KDC-side trusted name service rather than client-side DNS lookups to resolve principals to realms, eliminating reliance on insecure DNS queries (which RFC 4120 prohibits) and the administrative burden of maintaining per-client host-to-realm mapping tables.
The Section 11 negotiation mechanism was designed to complement FAST rather than replace it. FAST requires an armor ticket not available to all clients, so the negotiation mechanism provides a baseline level of request-integrity protection for deployments that cannot use FAST.
The AD-LOGIN-ALIAS information SHOULD be dropped in the general cross-realm ticket-granting case because the use of AD-KDC-ISSUED authorization data elements in cross-realm cases has not been well explored. However, a realm MAY re-sign alias information from certain trusted realms.
When PKINIT (RFC 4556) is used with Windows implementations, the NT-ENTERPRISE client name is encoded as a Subject Alternative Name extension in the client's X.509 certificate using otherName with type-id id-ms-sc-logon-upn (1.3.6.1.4.1.311.20.2.3) and a KerberosString value.
Windows 2000/2003 implemented an earlier form of referrals using PA-SVR-REFERRAL-INFO (type 20) with a PA-SVR-REFERRAL-DATA structure containing referred-realm and optional referred-name. The referred-realm is redundant with the realm in the returned TGT's second component.
A client MUST reject a response for which it sent PA-REQ-ENC-PA-REP if the ENC-PA-REP ticket flag is set and the PA-REQ-ENC-PA-REP padata item is absent or the checksum is not successfully verified.
Clients MUST restrict service name changes sufficiently that the client ends up talking to the correct password-changing service. Clients SHOULD carefully restrict acceptable service names when no protection beyond RFC 4120 is in use.
If PA-REQ-ENC-PA-REP is sent in the request, the KDC MUST include PA-REQ-ENC-PA-REP in the encrypted-pa-data of any generated reply, containing a checksum over the AS-REQ or TGS-REQ using the reply key, checksum type required for the reply key encryption type, and key usage KEY_USAGE_AS_REQ (56).
Implementations MUST support the FAST negotiation mechanism described in Section 11. Clients conforming to this specification MUST send PA-REQ-ENC-PA-REP (149) padata in all AS requests, and KDCs MUST always set the enc-pa-rep (15) ticket flag in all issued tickets.
Names MUST NOT be changed in the response to a TGS request, even though KDCs may maintain aliases. Services MUST NOT make distinctions based on which alias appears in the issued ticket because the service name in a ticket is not cryptographically protected.
The canonical principal name for an alias MUST NOT be in the form of a ticket-granting service name, as that would be construed as a cross-realm referral rather than an alias mapping.
The client logon mechanism MUST use additional information such as the client realm and/or authorization attributes from the service ticket presented to the workstation when mapping logon credentials to a local account, rather than trusting the client name in the AS response.
The Kerberos client MUST explicitly request the 'canonicalize' KDC option (bit 15) in the AS-REQ or TGS-REQ to trigger referral or name-canonicalization processing. Without this flag, the KDC will not return referrals or alternative principal names.
When a client referral lookup is unsuccessful, the KDC MUST return KDC_ERR_C_PRINCIPAL_UNKNOWN. When lookup succeeds but the account is in another realm, the KDC MUST return KDC_ERR_WRONG_REALM with the true or closer realm in crealm. The client MUST NOT use the cname from this error.
AD-LOGIN-ALIAS (ad-type 80) is an authorization data element wrapped in AD-KDC-ISSUED that lists one or more aliases for a principal. It is included in initial credentials and copied into additional credentials to permit authorization decisions based on aliases and support user-to-user exchanges.
In server referrals, when the canonicalize flag is set and the principal is not found locally, the KDC MAY return a cross-realm TGT (referral TGT) to the next hop on the trust path. The server name of the returned ticket will differ from the server name in the request.
PA-REQ-ENC-PA-REP (padata type 149) is sent by clients in AS requests (and optionally TGS requests) to indicate support for the FAST negotiation mechanism. Its value SHOULD be empty and MUST be ignored by the KDC upon receipt.
The enc-pa-rep ticket flag (bit 15) is set by the KDC in all issued tickets to indicate KDC support for the FAST negotiation mechanism defined in this document. Clients use this flag to detect if the facility was available but stripped by an attacker.
The NT-ENTERPRISE principal name type contains one component (a realm-defined string) intended as an alias for another principal in the enterprise. It is transmitted as a single component in the client name field of AS-REQ with name type NT-ENTERPRISE, enabling users to log on as 'alice@EXAMPLE.COM' regardless of which sub-realm contains their account.
PA-REQ-ENC-PA-REP (type 149) has been registered in the Kerberos 'Pre-authentication and Typed Data' IANA registry.
An attacker cannot mount a downgrade attack against the negotiation facility because KDC support is indicated by a ticket flag (enc-pa-rep). However, an attacker can strip the client's indication of support, which the client will detect but the KDC will not learn about.
In the shared-password case, a man-in-the-middle can alter the client principal name in the request or replay a prior KDC response with modified PA-ETYPE-INFO, causing a client to unknowingly authenticate with wrong credentials without the attacker knowing the password.
KDC_ERR_WRONG_REALM is an unprotected error response, so an attacker may redirect a client to authenticate to an unintended realm. This can provide the attacker an advantage in attacking client credentials, especially in shared-password scenarios.
The referral mechanism creates attack opportunities because KDC request and response fields defined in RFC 4120 are not protected. FAST (RFC 6113) fully mitigates these issues by protecting both request and response; the Section 11 negotiation mechanism provides partial protection by detecting modification of requests that result in replies.
Without FAST, changing the server name in the request is a significant attack: an attacker can direct a user authenticating to send confidential information to a server under attacker control. Clients SHOULD restrict acceptable server names, especially for the password-changing service.
Client referral loop: client sends AS-REQ → if KDC_ERR_WRONG_REALM is received, client sends new AS-REQ to the realm specified in crealm of the error → repeat until AS-REP is received or the true realm is found. Implementations SHOULD limit referral hops to 5 to avoid infinite loops.
Server referral chain: client sends TGS-REQ with canonicalize set → KDC returns cross-realm TGT to next hop → client sends TGS-REQ to that realm → repeat until a service ticket is received. Implementations SHOULD limit this chain to 5 referrals.
AD-LOGIN-ALIAS is encoded as an ASN.1 SEQUENCE with a login-aliases field containing a SEQUENCE of one or more PrincipalName values (ad-type number 80), wrapped in AD-KDC-ISSUED.
EncKDCRepPart is extended with an optional 'encrypted-pa-data [12] SEQUENCE OF PA-DATA' field. This field MUST be absent unless the 'canonicalize' KDC option is set or the PA-REQ-ENC-PA-REP padata item is sent by the client.
KDCOptions is extended with the 'canonicalize' bit at position 15. Setting this bit signals to the KDC that the client accepts replies where principal names differ from those requested, enabling referral and canonicalization processing.