host name resolution, again (krb5-1.3-alpha1 is available)

[Donn Cave]

Quoth Sam Hartman <hartmans at mit.edu>:
| In my opinion the correct way to do clustering is the return a CNAME
| to the cluster address not an A record.  I believe this can be made to
| work.

Will this really satisfy everyone, though?  I mean, assuming that the
virtue of this approach is that h_name comes back as the actual
host name pointed to by the CNAME.

For more insight into the posture here, I looked for IETF drafts and
found this from Neuman et al. --
http://www.ietf.org/internet-drafts/draft-ietf-krb-wg-kerberos-clarifications-03.txt

I'll append the whole section that bears on this.  My interpretion
is that you're not allowed to use h_name in this way - at least,
if you're using it to domain-extend the name, you'd have to compare
the result to verify that you did _not_ get an alias lookup.

I'm assuming DNS service that does not meet Neuman et al.'s standard
for "secure", as I think any application would have to assume that.

	Donn Cave, University Computing Services, University of Washington
	donn at u.washington.edu
-----------------------------
 1.2. Choosing a principal with which to communicate 

    The Kerberos protocol provides the means for verifying (subject to 
    the assumptions in 1.5) that the entity with which one communicates 
    is the same entity that was registered with the KDC using the claimed 
    identity (principal name). It is still necessary to determine whether 
    that identity corresponds to the entity with which one intends to 
    communicate. 

    When appropriate data has been exchanged in advance, this 
    determination may be performed syntactically by the application 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 
    server and when transmitted.  Thus, for example, one should not rely 
    on an unprotected domain name system record to map a host alias to 
    the primary name of a server, accepting the primary name as the party 
    one intends to contact, since an attacker can modify the mapping and 
    impersonate the party with which one intended to communicate. 

    Implementations of Kerberos and protocols based on Kerberos MUST NOT 
    use insecure DNS queries to canonicalize the hostname components of 
    the service principal names.  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 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 an KDC implementation. 

    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 about whether the service name is case folded 
    to lower case or whether reverse resolution is used. To maximize 
    interoperability and security, applications SHOULD provide security 
    mechanisms with names which result from folding the user-entered name 
    to lower case, without performing any other modifications or 
    canonicalization.