RE: Proposed Configuration payload for IKEv2

[Paul Hoffman / VPNC <paul.hoffman@xxxxxxxx>]

At 4:58 AM +0200 12/20/02, Hugo Krawczyk wrote:
> You have to be very careful when you change the cryptographic logic in
> IKEv2. Is the protocol you are proposing still secure?

Somehow, we thought that *you* might answer that question. :-)

> It seems to me, at least at first glance, that the protocol may be open to
> some form of man-in-the-middle attack (or more precisely, "server in the
> middle"). Have you checked that?

As I understand it, the server-in-the-middle attack that has been 
discussed this last month requires that the messages being passed in 
the IPsec remote access protocol have the same format as the messages 
being passed in the legacy authentication protocol. If that is a 
correct understanding, then it seems like we aren't susceptible to it 
because we have our own message format for CHRE payloads.

> At the functional (and security) level the identity of the server (and/or
> its certificate) seems to be missing in message 2. Is this just an
> overlook, or is it deliberate? In any case I would not like to assume that
> the client always has this cert in advance or that there is a single PK
> with which the server's signature is to be verified. Note that there may
> be, in principle, more than one server answering the client's request.

The model we assumed was that the initiator knew the identity of the 
responder. You are correct, there might be a pool of responders. We 
could certainly add a certificate in message 2 for that. As per the 
discussion earlier this year, in the remote access case, it is fine 
to expose the identity of the responder to passive snooping if it is 
a remote access server.

--Paul Hoffman, Director
--VPN Consortium