openssh unix dev - Sep 2007 - GSSAPI vs load-balanced servers - anything we can do?

Dear all,

(apologoies - this has nothing to do with 4.7 being out, but is rather a 
long-standing issue that regularly bites us).

Is there anything I could do to further the case of
https://bugzilla.mindrot.org/show_bug.cgi?id=1008

As a summary, GSSAPI auth against machine in a DNS load-balanced server 
farm fails. SSH-1 Kerberos works.

DNS load-balanced farm:
Individual machines in the farm  have separate IP addresses (ipA, ipB), 
separate  hostnames (nameA, nameB, ..) and separate Kerberos identities 
(host/nameA.domain at REALM) . A common DNS name (clustername) resolves to 
one or several IPs. Reverse lookup on the IP gives the individual 
machine name. (seems to be a common & cheap way to spread load).

The problem is that GSSAPI insists on doing its own DNS lookup 
(forward+reverse) to determine the (Kerberos) identity of the server, 
and has a fair chance of getting a different reply. So a typical session 
looks like

client: gethostbyname( clustername) -> ipA
         connect (ipA)
         (KEX and other wonderful SSH stuff)
         do GSSAPI auth
             gethostbyname(clustername) -> ipB
             gethostbyaddr( ipB) -> nameB
             get service ticket for host/nameB.domain at REALM
             send ticket to connected machine (nameA)
server: huh? Enotmynameinticketgoaway.

The GSSAPI behaviour is apparently mandated by RFC1964
(2.1.3):
>    When a reference to a name of this type is resolved, the
"hostname"
>    is canonicalized by attempting a DNS lookup and using the fully-
>    qualified domain name which is returned, or by using the
"hostname"
>    as provided if the DNS lookup fails.  The canonicalization operation
>    also maps the host's name into lower-case characters.
so is unlikely to change.

The only workaround seems to be feeding the canonical hostname (or IP) 
of the  currently-connected server machine into GSSAPI, instead of the 
hostname the user provided (this is what SSH-1 Kerberos did, by the way).
While in principle we could change the reverse DNS of the cluster 
machines to point to the cluster name, this would introduce confusion 
for everything that known already which exact host to connect to.


This is a client-side issue, so no amount of patching on the server will 
make this issue go away. In addition, we need to convince vendors to 
provide patches to their deployed "legacy" versions, which is made 
difficult by the fact that this is not fixed "upstream". We seem to
have
convinced Red Hat that this is an issue.

Two-line patch is at https://bugzilla.mindrot.org/attachment.cgi?id=1202.
https://bugzilla.mindrot.org/show_bug.cgi?id=1008 also has a more 
elaborate version by Simon that introduces a new config option.

I'd be happy to forward-port either to 4.7, if there is a chance that 
this will get applied one day.


Sorry for the lengthy post, thanks for your time.
Jan

On 14/09/07 22:26, Simon Wilkinson wrote:
..
> RFC4120 (the revised Kerberos RFC) states
>    Implementations of Kerberos and protocols based on Kerberos MUST NOT
>    use insecure DNS queries to canonicalize the hostname components of
>    the service principal names
> 
> So, I suspect that the language in 1964 will get updated at some point 
> in the future. There are already vendors who ship Kerberos GSSAPI 
> libraries with canonicalisation disabled.
Interesting (even though this is just for Kerberos, not GSSAPI - and the 
GSSAPI RFC 2743 still says "the 'hostname' may (as an example 
implementation strategy) be canonicalized by attempting a DNS 
lookup"..). But "GSSAPI-for-SSH" rfc4462 is rather clear on the
issue.

Do you know whether there is something foreseen to determine whether a 
given GSSAPI library will do canonicalization?
> Bear in mind, too, that the client side GSSAPI support is completely 
> mechanism independent - you can use it with X509 based mechanisms such 
> as GSI, and indeed any other GSSAPI mech that you have a library for. 
> So, hardcoding canonicalisation is the wrong thing to do.
Thanks for reminding me. For now, we seem to get by with client-side 
canonicalization due to Kerberos being the only native mechanism on the 
server-side (i.e. without Globus patches).
> The best bet at the moment is to provide a configuration option that 
> allows the user to indicate whether or not they wish to trust the DNS to 
> canonicalise the host name - which is what my GSSAPITrustDNS patch does 
> (This patch is also included in my GSSAPI patch bundle, which really 
> needs updated to 4.7 ...)
Nice, looking forward to it. It means we would have to store two 
identities in the keytab (hostname+DNS-cluster-name), I remember that 
you had a path for using both as well somewhere. Will have a look.


Regards
Jan