]> Kerberos Ticket flag indicating KDC support for resolving hostname aliases MIT Kerberos Consortium
77 Massachusetts Ave Cambridge Massachusetts USA tlyu@mit.edu
Network Working Group Internet Engineering Task Force Kerberos This document specifies a Kerberos Ticket flag that indicates that the Key Distribution Center (KDC) can resolve hostname aliases in service principal names. This document updates RFC 4120.
This document specifies a new Kerberos Ticket flag that indicates that the Key Distribution Center (KDC) is capable of resolving hostname aliases. A Kerberos client can interpret the presence of this Ticket flag as a recommendation to avoid using potentially insecure DNS lookups to canonicalize hostnames when constructing Kerberos principal names.
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 RFC 2119.
When attempting to authenticate to a Kerberos application service, existing Kerberos client implementations typically perform hostname canonicalization when constructing the Kerberos service principal. In practice, these clients canonicalize using insecure DNS, contrary to the recommendations in RFC 4120. Implementations are not consistent about whether they use forward resolution (looking up an address record for the user-provided hostname and returning the accompanying canonical hostname) or reverse resolution (taking the IP address from a forward resolution and returning the reverse pointer (PTR) record) to canonicalize hostname components of Kerberos service principal names.
If a KDC has knowledge of all hostname aliases for host-based service principal names in its realm, it SHOULD set the kdc-resolves-aliases (number TBD) flag in the Ticket and EncKDCRepPart for all tickets it issues.
If a client receives an EncKDCRepPart that has the flag kdc-resolves-aliases set, it SHOULD NOT attempt to canonicalize hostnames in service principal names for the realm whose KDC set that flag. Instead, the client SHOULD use the unchanged user-provided hostname when constructing the service principal name. The following behaviors in RFC 4120 are still permitted: clients MAY append a statically configured domain name to unqualified hostname, and clients SHOULD fold the hostname to lowercase.
TBD
TBD.
The new ticket flag described in this document allows Kerberos realm administrators to communicate a recommendation to clients that they not attempt any hostname canonicalization when constructing service principal names. This avoids the use of insecure DNS to resolve hostnames, which can allow principal name substitution attacks in some environments.
Thanks to Sam Hartman, Love Hornquist Astrand, and many others who suggested this idea and contributed to its evolution.
&RFC2119; &RFC4120; Information technology -- Abstract Syntax Notation One (ASN.1): Specification of basic notation -- ITU-T Recommendation X.680 (ISO/IEC International Standard 8824-1:2008) ISO Information technology -- 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:2008) ISO &RFC1510;