GSSAPI vs load-balanced servers - anything we can do?
Jan Iven
jan.iven at cern.ch
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.
Regards
Jan
More information about the openssh-unix-dev
mailing list