Re: addresses and IKEv2

[Stephen Kent <kent@bbn.com>]

Alex,

>Steve,
>
>Whom are you kidding?  Just because *you* don't change a DNS name bound
>to a machine for 18 months doesn't mean that Yahoo doesn't on-the-fly
>direct your HTTP post to one of 50 different servers depending on query
>loads, etc.  When one designs a system one has to account for many
>types of usage.  But at the same time you have to decide what to not
>support.  For example should IPsec identify either a user or a host?
>I would argue that only a host, and possibly a port, should be
>identified, since IPsec is operating between the routing and transport
>layers.

I could easily ask who do you think YOU are kidding with a claim that 
a new globally unique ID scheme for computers is either needed of 
feasible. I don't care to which Yahoo machine I connect. I care only 
that the machine represents Yahoo, period. And, if one wanted to use 
IPsec for HTTP (vs. SSL) many folks have suggested that the right 
answer is to terminate the SAs at a load balancer in front of the 
servers, not within each server. The argument about what granularity 
of authentication IPsec should provide is an old one on this list. 
if I have a single user system, then the mapping from machine to 
person is 1-1 at any time and thus is makes as much sense to 
authenticate the person as the machine.  There is no human being 
layer in the TCP/IP stack, or in the OSI model.  It may be desirable 
to use higher layer authentication for identifying individuals in 
some cases, but it's quite reasonable to perform this authentication 
at the lowest layer offering an end-to-end service, i.e., the IP 
layer, when the machine where the SA terminates is under the control 
of a single user.


>For you it may be simple to juggle multiple types of addresses (DNS, IP,
>email, whatever). But to establish and manage IPsec sessions reliably
>across millions of machines and tens of thousands of organizations, day
>after day, year in and year out, with software written by hundred's of
>protocol programmers in many companies and countries, is in practice a
>nightmare. It took 3 years for the industry to be able to interoperate
>with 3DES, some firms had to go through certification half a dozen times.
>Is that what you want the industry to go through again by requiring
>multiple ways of addressing hosts? To be successful, IPsec needs a simple
>way to retrieve the key that actually does the work of authenticating the
>host.  Neither DNS nor IP address are designed to do this well, they do
>their respective existing jobs only too well.

Most of the preceding commentary is completely irrelevant to our 
discussion. But, what you seem to be proposing is to embark on the 
creation of a new class of IDs for machines that, by themselves, have 
no utility in managing access, since they are not meaningful to the 
people who have to manage all of this.  It seem to me that your vague 
proposal flies in the face of the management concerns you allude to 
above.

>Neither an IP address nor a DNS name will work because they are too
>ephemeral.  Binding them into a certificate is just a snapshot of a
>transient address to host key binding. All it does is introduce more
>complexity, with certs littered about containing outdated host addresses,
>not to mention yet another interoperability headache with certificate
>authorities, revocation lists, etc.

In the vast majority of cases we don't care which machine is being 
used to connect anywhere. We care about the binding of the machine to 
a human user or some sort of an organizational affiliation. That's 
what various forms of IDs, managed at levels higher that machine IDs 
and address, do for us.

>BTW, quit asking for a definition of "security".  You know damn well it's
>self referential.  It's like asking for a definition of "money" or "time".
>
>For that matter, so is the definition of an IPsec host "address".

I don't recall asking you what security meant.  The reason for asking 
Eric was to determine what the underlying requirement are in terms of 
standard security services  (confidentiality, integrity, 
authentication, access control, ...) so that I could better 
understand what Eric was looking for. If you think security is an 
undefinable term, maybe that explains why you are unable to 
articulate a clear reason for the form of ID you believe is needed.

Steve