there is no such thing as a "canonical domain name" for a host.
Kerberos tried to invent such a concept, but it didn't work all that
well. I would much rather have some real IP-level endpoint identifier.
If that's what we're securing, that's what we should be using.
mumble. as far as I can tell, both DNS names and IP addresses
are hopelessly overloaded and are likely to stay that way until
we figure out how to make a major architectural change.
I get amused when layer 3 folks tell me that overloading of IP
addresses is bad and that we therefore need to overload DNS names
even more. But it doesn't make any more sense to me to increase the
overloading of IP addresses (which are fundamentally names of
locations of network attachment points - all other uses are in
some sense overloading) in order to reduce overloading of DNS names.
it seems to me that if you want to authenticate to a specific host
then you need to use an identifier that is uniquely associated with
that host, like the hosts's serial number, so I'd want to have
certificates that could associate that serial number with a key.
but in most cases (at least from an apps guy's view of the world)
I don't care about any particular host - what I want to authenticate
is a service, and it could be on any hosts. in such cases I want
to use the service name (which in today's world is usually a DNS name)
as the authentication identifier. I could probably make a case for
authenticating to IP addresses also, but for me this is the most
difficult one to justify.
bottom line is I think we have a need for SAs to be bindable to
several different kinds of identifiers. I question the notion
that IPsec should be "security at the IP layer" because to me
IP is only a way of moving payload from one place to another - it
has little to do with the services that humans care about
and in whose identities they need to trust.
Keith