Re: Turning off hostname canonicalisation

[Buck Huppmann <buckh@pobox.com>]

On Sat, Sep 10, 2005 at 02:00:43PM +0100, Markus Moeller wrote:

> The other issue I see in enterprise environments is the use of CNAMEs and 
> Global Server Load Balancing for load balancing, disaster recovery or 
> simple failover . In these cases canonicalisation is very useful since you 
> wouldn't need to synchronise keytabs on different systems. (it may not be 
> as secure, but you could mitigate the risk in other ways)

while i hate to take this discussion off onto the philosophical track,
what you're talking about seems to be at odds with the fundamental objec-
tive of Kerberos to authenticate a client and a server to one another. of
course, this depends on what one's definition of ``server'' is, but, in the
absence of some specified really tight integration with the naming service
and some guarantees as to its trustworthiness (security-wise, at least),
then Kerberos should just take the principal name it's given and not mess
with it. (even RFC 4120's concession to allow static suffixing seems iffy,
although probably the minimum necessary evilness required for backwards
compatibility.) it's up to whoever's running the server to make sure that
all machines and their software that're purporting to be some server can
prove it by having recourse to the server's key for protocol operations,
despite the administrative inconvenience. it doesn't seem like it should
be Kerberos' job, at any rate, to put your clients at the mercy of naming-
service security guarantees (nonexistent, for most intents and purposes)

[total derailment ahead]

of course, what would really be nice would be some Kerberos extensions
to DNS so you could trust DNS and then specify how Kerberos implementa-
tions should takes names from a Kerberos-secured DNS and canogrify them,
based on SRV lookups or what have you, and make your Kerberos implemen-
tation a one-stop shop for safe server lookup and authentication stuff
(within the scope of intra- and pre-existing cross-realm relationships,
i mean), so that if the hybrid Kerberos-DNS can give you an address and
successfully carries out an authentication exchange then you know it was
all done securely, according to whatever your friendly Kerberos and DNS
administrators' policies are, although none of this is spanned by either
the DNS or Kerberos job description and obviously would benefit from it
all being integrated into the operating system's APIs and fries to go
with it, too. and i guess this ignores making it all abstractable behind
the GSSAPI interfacen and not undercutting whatever work people are do-
ing to resolve naming issues for GSSAPI generally and Kerberos apart
from DNS names, but i'll admit i'm selfishly unconcerned about all that