[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: IPSEC Security Gateways & NAT


I have witnessed this for (too many) years:

people complaint about the complexity of the protocol,
at the same time they ask for richer functionality,
and insist to get the added features with even less complexity.

Sorry guys but there is no free lunch...

Yes, IKE is complex. There are two main reasons for it:

(1) ISAKMP is very complex and IKE was designed with the REQUIREMENT to
    fit in the ISAKMP framework

(2) IKE was designed with a lot of requirements and optional
    functionalities: in particular, four different modes of authentication,
    with and without public keys, with and without identity protection,
    with and without aggressive mode, with pfs and without pfs in quick
    mode, with old groups and new ones too.

If you want to simplify the protocol, first decide on a SUBSET of
requirements, eliminate options and voila you'll have a simpler subset of
IKE. But as long as you ask for more functionality then you have to pay
the current complexity price AND MORE.

SKEYID and related key derivation is the SIMPLEST possible mechanism I can
think of to support in a UNIFORM way the myriad of current requirements
and options. I actually worked hard to make SKEYID the only changing piece
with all of SKEYID_a/d/e and HASH_I/R all derived in the SAME way in
spite of all the different modes.

Now specifically on pre-shared key mode as referred to in this thread.
As Dan said you can bind the key to ID_KEYID instead of the ip address.
This will hide the party identities but different uses of the key will
be "linkable". You want to eliminate linkability? No problem: ADD
complexity (e.g, change the value of  ID_KEYID with each use of the key,
no two uses will have the same ID and an attacker will not be able to link
between these values. Nice and COMPLEX). 

And there are other solutions to the binding of the key to the ip
address. If I understand Dan correctly he wants to allow binding the 
keys to the party identities rather than the in-the-clear ip address.
Want that? No problem: ADD COMPLEXITY.
Here is the (simplest) solution.

What you can do is the following: leave everything as it is defined now
for pre-shared key mode, except for SKEYID_e. Instead of deriving it from
SKEYID as currently done, define it as something like 
prf(Ni_b | Nr_b, g^xy). Now you do not need to know the pre-shared
key in order to decrypt the identities.
Quite simple, right? but then you DEPARTED from the uniform derivation of
SKEYID_e. No big deal just some more complexity.

As I said: there's no free lunch.

Hugo

PS: just to make it clear: the above proposed change is for pre-shared
mode only, other modes and derivations are unchanged


On Wed, 13 Jun 2001, Dan Harkins wrote:

> On 13 Jun 2001 12:24:28 EDT you wrote
> > 
> > I agree that it is a problem that the IKE ID is tied to the source and
> > destinatin IP address.  Currently, however, the __ONLY__ time there is
> > this particular problem is when using pre-shared static keys for
> > authentication.  Well, first, I would suggest people not use
> > pre-shared static keys.  That suggestion notwithstanding, wouldn't it
> > be better if this problem was fixed completely, so that pre-shared
> > static keys are _NOT_ tied to the IP Source Address?
> 
> The reason it was done that way is that there was a desire to force the
> keys to contain something known only by the peers (which is why signature 
> mode was described as "the least secure"). There was also a requirement 
> for identity protection. Those two combined to give us what we have today.
> You need to get the pre-shared secret to use to derive a key to protect
> the identity which is used to find the pre-shared key. That wouldn't work
> so the key is bound to all you can know at that time-- the IP address.
> Actually, using ID_KEYID identity and Aggressive Mode can give you identity
> protection (since the keyid can be any opaque blob) with pre-shared keys
> but that's really not an elegant solution.
> 
> Provided that the Diffie-Hellman is authenticated I guess we could say
> that the resultant secret is something known only by the parties to
> the exchange and therefore having g^xy (and not the pre-shared key) is
> good enough. But I'm not a cryptographer and I didn't come up with the
> key derivation. 
> 
> I'm all for simplifying and unifying SKEYID generation. Are there any 
> comments on this proposal? Hugo, are you out there?
> 
>   Dan.
> 
>
Follow-Ups: References: