Sean,
Sean Doran wrote:
> | Furthermore, if the host ID is cryptographic in nature (e.g.
> | a public key), it's even fairly easy to show that the update
> | messages are not forged. Even further, if you use public keys,
> | you can even *delegate* the right to send update messages...
>
> One approach to this -- if memory serves, it originated with Ran Atkinson --
> is to associate an IPSEC SA with INADDR_ANY, thus reducing the problem to
> a decision on whether to use a properly decrypted incoming packet's
> source address as a destination address for return traffic, or to
> use some other "handle". In other words, the crypto key becomes
> the topology-independent identifier -- there can be many per host --
> and the trick is what to do about the topology-dependent address,
> so that you can reach the SA who can decrypt the message.
Right. INADDR_ANY works well for inbound SAs. However, handling
outbound SAs would require changes to IPsec, basically requiring
that the SA lookup is based on the recipients host ID, not IP
address. Thus, in fact the whole IPsec policy engine needs to
be revised. (But that would only be good...)
From my point of view, there may be several "layers" of these
topology-independent identifier keys: it looks best to have
public keys as the long living identifiers, and take any SAs
(and associated keys) as "cached" short living representations
of the public keys. But that's an implementation detail, the
important thing is that if you use public keys (or something
similar) as your primary identifiers, you make many signalling
related security problems much easier to solve. End-host
mobility and multi-homing are the prime examples of this, but
it looks like that it could make many other security problems
easier, as well.
> Naturally, this is a flavour of the key-distribution problem.
Well, I don't really see any key-distribution problem here.
If you use the keys as your host IDs, you learn the key as
you learn your peer's ID, which you need anyway. But perhaps
I just don't understand what you mean; could you elaborate?
On the other hand, there still do exist various trust related
problems. Just the fact that you have someone's key doesn't
say much, unless you positively know that someone by some other
means and can tell how much and in which respects you trust
that someone. However, that problem is more or less unrelated
to the host ID lookup problem. Sure you can take the point-of-view
that both the host ID lookup and trust management problems must
be solved with a single mechanism, but at least I would like to
keep them conceptually different.
--Pekka Nikander
This archive was generated by hypermail 2b29 : Mon Aug 04 2003 - 04:10:04 EDT