Additional Kerberos Naming Constraints
updates
- rfc-4120 — The Kerberos Network Authentication Service (V5)
Extracted elements (18)
The TGS rules for well-known principal names (MAY reject for client, SHOULD reject for server) are intentionally asymmetric to allow incremental updates and ease migration: a well-known client principal accepted in one realm should permit cross-realm TGTs to function even when not all realms in the cross-realm path have been updated.
This document was created because RFC 4120 did not reserve Kerberos names with special meanings, leading protocol designers to use obscure names to avoid collision. Even a registry cannot prevent deployed implementations from accidentally reusing names, which could grant unintended access.
The DOMAIN-X500-COMPRESS encoding for transited realms can be used when the client or server realm is reserved or when a reserved realm appears in the transited field. However, abbreviation forms that build on a preceding name cannot be used at the start of a transited encoding if the client's realm is a well-known realm. The null-subfield form cannot be used adjacent to a well-known realm.
The AS and the application server MUST reject authentication if a well-known realm name is used as the client or server realm but is not supported.
The TGS MAY reject authentication if an unsupported well-known principal name is used as the client principal, and SHOULD reject if an unsupported well-known name is used as the server principal name. This asymmetry allows incremental cross-realm migration.
The TGS MAY reject authentication when an unsupported well-known realm name is used as the client realm, and SHOULD reject when used as the server realm but not supported.
The TGS MUST NOT encode a well-known Kerberos realm name into the transited field of a ticket. Parties checking the transited realm path MUST reject any path that includes a well-known realm.
Unless otherwise specified, all principal names involving a well-known realm name are reserved; if such a reserved principal name is used but not supported and authentication is rejected, the error code MUST be KRB_AP_ERR_PRINCIPAL_RESERVED.
Unless otherwise specified, if a well-known principal name is used but not supported in any other place in Kerberos messages, authentication MUST fail with KRB_AP_ERR_PRINCIPAL_UNKNOWN.
When a KDC checks a transited realm path containing a well-known realm, the TRANSITED-POLICY-CHECKED flag MUST NOT be set in the resulting ticket.
A new Kerberos principal name type KRB_NT_WELLKNOWN (value 11) is defined for well-known principal names. A well-known principal name MUST have at least two KerberosString components, and the first component MUST be the string literal "WELLKNOWN".
A new well-known realm name type is defined as an "other" style realm name with the NAMETYPE part set to "WELLKNOWN", yielding the form "other: WELLKNOWN:realm-name". This type is designated for well-known Kerberos realms.
Error code KRB_AP_ERR_PRINCIPAL_RESERVED (value 84) is defined for when a reserved Kerberos principal name (any principal involving a well-known realm name) is used but not supported and authentication is rejected.
Error code KRB_AP_ERR_PRINCIPAL_UNKNOWN (value 82) is defined and MUST be returned when a well-known Kerberos principal name is used but not supported. No accompanying error data is defined.
Error code KRB_AP_ERR_REALM_UNKNOWN (value 83) is defined and MUST be returned when a well-known Kerberos realm name is used but not supported. No accompanying error data is defined.
Two new IANA registries are created: one for well-known Kerberos principal names and one for well-known Kerberos realm names, both defined under the framework established by this document. The evaluation policy for each registry is "Specification Required" per RFC 5226.
If a well-known principal name was created before a KDC was updated to conform to this specification, it SHOULD be renamed. The provisioning code that manages account creation MUST be updated to disallow creation of principals with unsupported well-known names.
Name collisions with well-known names are possible because RFC 4120 does not reserve names with special meanings. If a well-known name is not supported, authentication MUST fail; otherwise, access may be granted unintentionally. A KDC supporting this spec but not anonymous authentication could inadvertently grant anonymous users access if a principal is created with the anonymous principal's name.