RE: Proposed Configuration payload for IKEv2

[Hugo Krawczyk <hugo@ee.technion.ac.il>]

On Thu, 19 Dec 2002, Paul Hoffman / VPNC wrote:

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

I thought that the burden of proof should be on the proponent...

In any case I was not referring to the man-in-the-middle attacks 
that we are discussing in a parallel threat and which are based on the bad
practice of using same credentials in protected and unprotected runs.

Here I am talking about weaknesses in the cryptographic logic of the
SLA protocol. But since there is enough traffic regarding the other MitM 
attacks (and it is late) I prefer to postpone this issue for next week.

The bottom line is that the cryptography of SLA is open to attacks
against the "consistency" (or "mutual belief") requirement for
authenticated key exchanges (see, for example, my SIGMA paper).
Yet, since SLA is specifically intended for use in the client-server
model of legacy authentication the practical significance of the
*specific* attacks that I can see is questionable. 
Still I believe that these weaknesses will have to be repaired (at least
to avoid the publication of crypto papers that break the protocol :). 
I will write more about this next week.

Hugo   

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