Generic Security Service Application Program Interface (GSS-API) Domain-Based Service Names Mapping for the Kerberos V GSS Mechanism
Extracted elements (7)
Because the Kerberos V core protocol internationalization project is incomplete, the document cannot fully specify internationalization of domain-based principal names. ACE-encoded names (IDNA) are specified as the interim approach to ensure interoperability.
The same name canonicalization considerations and methods used elsewhere in the Kerberos V GSS-API mechanism (RFC 4121) and Kerberos V (RFC 4120) in general apply to domain-based principal names.
GSS_C_NT_DOMAINBASED_SERVICE names SHOULD be mapped to Kerberos V principal names such that <service> becomes the first component, <hostname> the second, <domain> the third, and the realm corresponds to the domain name treated as a hostname.
Implementations SHOULD use a Kerberos V name-type of NTT-SRVT-HST-DOMAIN (value 12) for domain-based principal names, but MAY use NT-UNKNOWN instead.
Kerberos V GSS-API mechanism implementations MUST use ACE-encoded internationalized domain names (per RFC 3490/IDNA) for the hostname and domain name slots of a Kerberos V domain-based principal name.
A Kerberos V domain-based principal name has three components: (0) service name, (1) hostname, (2) domain name, with a realm derived from the domain name treated as a hostname. For example, '[email protected]@ds1.foo.example' maps to 'ldap/ds1.foo.example/[email protected]'.
It is important for security that the realm of a domain-based principal name be derived from the hostname component of the input, rather than from the domain name slots. Deriving the realm from the domain name slots instead would undermine the security properties of domain-based naming.