Re: [David Leonard] draft-ietf-secsh-gsskeyex-09.txt comments

[Sam Hartman <hartmans-ietf%mit.edu@localhost>]

The handling of hostname canonicalization in GSSAPI is a thorny issue.
The short answer is that you need to get a canonical hostname from the
user or from secure DNS.  Since you don't have secure DNS, you need it
from the user.

RFC 2743 and 2744 have somewhat outdated thinking on this point.

While it is not a GSS spec, the discussion of this issue in RFC 4120
represents more current thinking.


     When appropriate data has been exchanged in advance, the application
     may perform this determination syntactically based on the application
     protocol specification, information provided by the user, and
     configuration files.  For example, the server principal name
     (including realm) for a telnet server might be derived from the
     user-specified host name (from the telnet command line), the "host/"
     prefix specified in the application protocol specification, and a
     mapping to a Kerberos realm derived syntactically from the domain
     part of the specified hostname and information from the local
     Kerberos realms database.

     One can also rely on trusted third parties to make this
     determination, but only when the data obtained from the third party
     is suitably integrity-protected while resident on the third-party



  Neuman, et al.              Standards Track                     [Page 9]
  
  RFC 4120                      Kerberos V5                      July 2005


     server and when transmitted.  Thus, for example, one should not rely
     on an unprotected DNS record to map a host alias to the primary name
     of a server, accepting the primary name as the party that one intends
     to contact, since an attacker can modify the mapping and impersonate
     the party.

     Implementations of Kerberos and protocols based on Kerberos MUST NOT
     use insecure DNS queries to canonicalize the hostname components of
     the service principal names (i.e., they MUST NOT use insecure DNS
     queries to map one name to another to determine the host part of the
     principal name with which one is to communicate).  In an environment
     without secure name service, application authors MAY append a
     statically configured domain name to unqualified hostnames before
     passing the name to the security mechanisms, but they should do no
     more than that.  Secure name service facilities, if available, might
     be trusted for hostname canonicalization, but such canonicalization
     by the client SHOULD NOT be required by KDC implementations.

     Implementation note: Many current implementations do some degree of
     canonicalization of the provided service name, often using DNS even
     though it creates security problems.  However, there is no
     consistency among implementations as to whether the service name is
     case folded to lowercase or whether reverse resolution is used.  To
     maximize interoperability and security, applications SHOULD provide
     security mechanisms with names that result from folding the user-
     entered name to lowercase without performing any other modifications
     or canonicalization.