Subject: [Ipsec] downgrade attacks on IKEv2

From: Ali Fessi <[email-masked]>
Date: Wed, 13 Dec 2006 12:50:44 +0100

Hi all,

I have a question on the negotiation of the IKE_SA in IKEv2:

The SA proposals in the IKE_SA_INIT exchange are not integrity 
protected, nor they are involved in the generation of the AUTH payload 
in the IKE_AUTH exchange.

So how can the Responder be sure that the set of proposals that he 
received from the Initiator is correct and how can the Initiator be sure 
that he received the correct crypto suite that has been chosen by Responder?

Couldn't this be misused for a downgrade attack which allow a 
man-in-the-middle attacker to force the usage of insecure (or less 
secure) algorithms for the IKE_SA?

Regards,
  Ali
-- 
Ali Fessi
Computer Networks and Internet
Wilhelm Schickard Institute for Computer Science
University of Tuebingen, Germany
Phone: +49 7071 29-70576 / Fax: +49 7071 29-5220
EMail: [email-masked]
Web: http://net.informatik.uni-tuebingen.de/~fessi/

_______________________________________________
Ipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipsec

---

From: Alejandro Perez Mendez <[email-masked]>
Date: Wed, 13 Dec 2006 13:20:21 +0100

Hi Ali

> in the IKE_AUTH exchange.

The SA proposals in the IKE_SA_INIT exchange are involved in the
generation of the AUTH payload since the entire IKE_SA_INIT message are
used in the AUTH payload computation, as said in the RFC 4306, section
2.15:

        << For the responder, the octets to
   be signed start with the first octet of the first SPI in the header
   of the second message and end with the last octet of the last payload
   in the second message.  Appended to this (for purposes of computing
   the signature) are the initiator's nonce Ni (just the value, not the
   payload containing it), and the value prf(SK_pr,IDr') where IDr' is
   the responder's ID payload excluding the fixed header. >> 

Regards,
Alejandro

---

From: <[email-masked]>
Date: Wed, 13 Dec 2006 14:22:52 +0200

Hi,

The SA payloads in the IKE_SA_INIT exhange *are* involved
in the generation of the AUTH payload. See RFC 4306 Section 2.15:

   "For the responder, the octets to be signed start with the first
   octet of the first SPI in the header of the second message and end
   with the last octet of the last payload in the second message."

Here "the second message" is the IKE_SA_INIT response, and:
    
   "[...] the initiator signs the first message, starting with the 
   first octet of the first SPI in the header and ending with the 
   last octet of the last payload."

Here "the first message" is the IKE_SA_INIT request.

Best regards,
Pasi

> -----Original Message-----
> From: ext Ali Fessi [mailto:[email-masked]] 
> Sent: 13 December, 2006 13:51
> To: [email-masked]
> Subject: [Ipsec] downgrade attacks on IKEv2
> 
> Hi all,
> 
> protected, nor they are involved in the generation of the 
> AUTH payload in the IKE_AUTH exchange.
> 
> received from the Initiator is correct and how can the 
> Initiator be sure that he received the correct crypto suite that 
> has been chosen by Responder?
>

---

From: Ali Fessi <[email-masked]>
Date: Wed, 13 Dec 2006 13:47:54 +0100

Hi Pasi and Alejandro,

ok, thanks for the quick response.

I just misunderstood whether the "first message" and "second message" 
refer to the first and second message of the entire protocol or whether 
they refer to the first and second message of the IKE_AUTH exchange.

Best Regards,
  Ali

---

From: Francis Dupont <[email-masked]>
Date: Wed, 13 Dec 2006 23:16:12 +0100

In your previous mail you wrote:

   
=> they are as everything sent before the AUTH payload covered by it.

[email-masked]