Re: addresses and IKEv2

[Stephen Kent <kent@bbn.com>]

Alex,
>        SNIP
>>
>>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.

My experience suggests that your examples are not representative.  The DNS names for my personal computers remain constant over time, even across hardware changes. If I had to tran sfer private keys every time I got a new computer to which i would assign the same DNS name, I'd have to do that maybe once every 18-24 months. At that rate, I could easily afford to revoke the old cert and issue a new one, in case security provisions made it hard to transfer private keys from one machine to the next. Also, if I need to authenticate a person, vs. a machine, then I would use of RFC822 address form of name, and implement it in  a fashion consistent with personal mobility, e.g., see the SACRED work. So, no, I don't agree with your conclusion above, and I don't think you have provided a convincing example to support that conclusion.

>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.

If I want to authenticate a person, vs. a machine, I would use a cert with an RFC822 address. If I want to authenticate a machine with no DNS name, then I could use other name forms, even distinguished names. But, to decide what sort of names are needed here, i think you need to provide some good examples of what machines have no DNS names, but I need to authenticate them, so that we can better understand the real problem.
 
>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.

Key IDs for machines seem useless to me, in isolation. They are meaningless, initially, and one would have to establish a scheme for mapping them to names that we do use and understand, in order to make use of them for access control purposes. As an analogy I have a passport number that uniquely identifies me among all US passport holders, but it is generally useless as an identifier because I am not known by that 9-digit number, to anyone but the State dept., U.S. Immigrations, and the like. But the creation of a mapping of the sort you would need is a tremendous undertaking, and it is not clear how it would be done and how it would be better than the sort of alternatives we were discussing above.

>>>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.

Absent a better definition of "secure" I can't tell what you mean here.

Steve