GSSAPI vs load-balanced servers - anything we can do?

Jan Iven jan.iven at
Tue Sep 18 01:28:36 EST 2007

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.


More information about the openssh-unix-dev mailing list