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

Re: IPSEC Security Gateways & NAT

Dan Harkins <dharkins@lounge.org> writes:

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

Except that there is no identity protection.  The identity MUST be the
IP Addresses, and those are visible to any passive eavesdropper.

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

>From whom are you trying to protect the identity?  As I said, in the
current situation, even a passive eavesdropper learns that, because it
must be an IP Address.  Messages 5 and 6 only verify it.  An
alternative by Radia, as I mentioned in a previous post, would protect
both identities from a passive eavesdropper.  Just encrypt the IDs in
the DH secret.

No, that doesn't provide you authentication, but that's ok.  Messages
5 and 6 do that.  You don't have to encrypt messages 5 and 6 directly
with a key derived from the shared secret.  In fact, I think all you
need is a valid MAC (with a key derived from the shared secret) to
prove authentication.

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

Think about the process this way:

	1) Compute a key agreement using DH
	2) Encrypt the identities in the agreed-upon key
	3) Authenticate step 1 (and 2) using the shared secret with the
	   peer (now that you know the identity).

> I'm all for simplifying and unifying SKEYID generation. Are there any 
> comments on this proposal? Hugo, are you out there?
> 
>   Dan.

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord@MIT.EDU                        PGP key available
Follow-Ups: References: