[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: IPSEC Security Gateways & NAT
Is'nt one step missing in the process? That is the responder on receiving
the
first message has to check the policy and accept a matching SA proposal.
The responder needs some way of getting to the policy.
It is either the identifier or ip address of the peer that has to be used as
the key to get to the policy.
That implies ip address has to be used as the key if identity protection
is required - right?
-- sankar --
-----Original Message-----
From: owner-ipsec@lists.tislabs.com
[mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Hugo Krawczyk
Sent: Wednesday, June 13, 2001 4:22 PM
To: Derek Atkins
Cc: ipsec list
Subject: Re: IPSEC Security Gateways & NAT
Derek, I have not seen Radia's paper so I can't comment on it.
However, what you say here:
> 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).
is indeed a good explanation of the rationale for the change to pre-shared
mode I suggested in a previous message.
This is why I changed SKEYID_e to depend on g^xy only but left the
HASH_I/R computations to depend on the preshared key (SKEYID)
Hugo
Follow-Ups:
References: