Re: addresses and IKEv2

[Alex Alten <Alten@attbi.com>]

Steve,

At 08:10 PM 5/29/2002 -0400, Stephen Kent wrote:
>At 4:43 PM -0700 5/24/02, Alex Alten wrote:
>>Steve,
>>
>>I'm not talking about a host's local database.  We need a way to uniquely
>>AND SECURELY identify any host worldwide from any other host.  You don't
>>want to replicate this information to every host, you'd have over 100
million
>>entries to distribute to each one!
>
>Oh, well, you've moved the problem well beyond the bounds of the 
>IPsec WG, given this description of what you are looking for. Also, 
>given my earlier comments about the desirability of not creating new 
>ID forms for use in access control systems, I think we have a 
>fundamental disagreement here.
>

Fair enough.  I firmly believe that IPsec cannot operate in a vacuum, there
has to be a supporting infrastructure that works well with it.  The two are
necessarily intertwined with design decisions recursively effecting each
other.
But this may be beyond the IPsec WG charter, although I would argue that it
should be a vital part of it.

>>I like DNS too, a nice simple hierarchy, it is easy to uniquely name hosts,
>>and a simple distributed model for managing the address space. But it has a
>>crippling drawback from a security perspective.  A DNS name cannot be any
>>better
>>at identifying a host than it's resolved IP address.
>>And we know how
>>ephemeral IP addresses can be given the rise of DHCP and NAT.  The only
>>secure way to absolutely identify a host is to assign it a (randomly) unique
>>crypto key.  But before you can pull the correct key (RSA or AES) you
need to
>>find it.  For this you need a unique number that doesn't keep being changed
>>underneath you.  So unfortunately DNS doesn't make the cut.  No amount of
>>wishful
>>thinking is going to make it work properly for us.
>
>I think your argument above is faulty. If I choose to use DNS names 
>as a basis for access control decisions, and if I have credentials 
>(e.g., certificates) that allow a machine or person to verify that 
>the entity at the other end of a key management exchange is the 
>entity with the DNS name in question, then I can dynamically bind the 
>name to the current address at the time an SA is created and I have 
>achieved the access control goals without needing to introduce the 
>sort of new ID scheme to which you are alluding. 
>
>

Let's follow your arguement through.  I need to establish an IPsec 
connection to www.kent.com.  It is currently assigned to machine A which
has an address of 200.200.200.1.  The next morning the admin decides to
change the DNS entry to point to machine B at 200.200.200.2.  Now my
IPsec connection will fail, even though machine A at 200.200.200.1 is
still active!  Why? Because the key is residing on A not on B.  So using
a cert with a DNS name bound to the key is useless.  Any system relying
on it will quickly run into the problem of how do you keep DNS names and
keys in synch across multiple machines.  And it is *not* good security
practice to keep transferring private authentication keys (either AES or
RSA) from machine to machine every time a DNS entry changes.  It makes a
mockery of using a key to automate the authentication of a particular
machine.  So certs are useless, you need the flexibility of reassigning a
new DNS name to A's key!  But how can I find the new DNS name for A in order
to get the correct key?  To solve this problem, if you don't allow the DNS
name www.kent.com to change to B then you defeat one of the main reasons to
use DNS.  A catch-22 results.  Therefore PKI certs & DNS don't mix.

Also, if you require DNS as the ID, then how do we address machines without
a DNS name?  To anticipate your answer, then use a cert bound to an IP
address. But even then we still have the problem of dynamically assigned IP
addresses via NAT or DHCP.  Again another catch-22 results.

So it turns out that neither DNS nor IP addresses can satisfy our need to be
able to reliably get the proper key needed to start up the IPsec connection.

I am arguing that the key should be bound to the machine itself, regardless
of it's address(es).  The ID I speak of is really a key ID assigned to that
machine, in a sense very similar to a PGP key ID.  But with the significant
difference that we assign an ID to the key, rather than generating it from
the key.


>>To reiterate my position: IPsec needs to have a global, secure address space
>>that uniquely identifies every participating host.  It needs to be simple to
>>understand, distributable, and easy to manage.  And it needs to be able to
>>dynamically map into the IP address space on demand, including private
>>network non-routable addresses.
>>
>>That's the requirements as I see them.  Anything less than this means
>>you can't use IPsec unencumbered across the Internet.
>
>we don't need a global, secure address space. we need secure means of 
>mapping IDs to credentials, and mapping those IDs to SA, in real 
>time, as you note immediately above. These two notions are not the 
>same.
>

Right, I had already agreed with Ken Brown earlier that global and secure are
not required.  However global would simplify the problem significantly.  In
fact I would argue it would be almost impossible to build a world-wide system
among many organizations using IPsec otherwise.  Secure doesn't actually make
sense since the ID is being used to bootstrap getting the key.  So the ID 
cannot be secure in and of itself.  The IPsec system must be able to carefully
bootstrap from an insecure state to a secure state.

- Alex

--

Alex Alten
Alten@ATTBI.com