Subject: Re: [Ipsec] Is this a good use of the INVALID_KE_PAYLOAD notification?

From: venkyee s <[email-masked]>
Date: Thu, 3 May 2007 02:35:07 -0700 (PDT)

Hello,

As per RFC 718, section 2.4 its clear that IKE_SA_INIT may be retried upon INVALID_KE_PAYLOD.

2.4.  Interaction of COOKIE and INVALID_KE_PAYLOAD

   There are two common reasons why the initiator may have to retry the
   IKE_SA_INIT exchange: the responder requests a cookie or wants a
   different Diffie-Hellman group than was included in the KEi payload.
   Both of these cases are quite simple alone, but it is not totally
   obvious what happens when they occur at the same time, that is, the
   IKE_SA_INIT exchange is retried several times.
The following should be absolutely possible and IKE_SA_INIT can be successful. 
      Initiator                   Responder
     -----------                 -----------
      HDR(A,0), SAi1, KEi, Ni -->
                              <-- HDR(A,0),
                                            N(INVALID_KE_PAYLOAD)
      HDR(A,0), SAi1, KEi',Ni -->
                              <-- HDR(A,B), SAr1, KEr, NrYour Interpretation 2 should be feasible.

Regards,
_Venkyee

----- Original Message ----
From: Christian Kaas-Petersen (AH/LMD) <[email-masked]>
To: [email-masked]
Sent: Thursday, May 3, 2007 4:58:44 PM
Subject: [Ipsec] Is this a good use of the INVALID_KE_PAYLOAD notification?

Let host A initiate the following IKEv2 exchange (either an
IKE_SA_INIT or CREATE_CHILD_SA exchange) with host Z.  For this
example, only the SA and KE payloads are relevant.

     host A                          host Z

              ---------------->
              IKEv2 Request containing
              SA payload with two proposals
                    proposal 1: ... D-H = 1 ...
                    proposal 2: ... D-H = 2 ...
              KE payload with DH keyhalf using D-H = 1
                              (because proposal 1
                              is host A's preferred proposal)

             <----------------
             IKEv2 Response containing
             INVALID_KE_PAYLOAD notification specifying D-H = 5

How shall host A interpret the response?

Interpretation 1: Host Z did not indicate a D-H group among the
                  proposals submitted.  Thus host A has
                  no hope that retransmitting with another
                  KE payload will bring success, therefore
                  exchange has failed.

Interpretation 2: Host Z has by naming a new D-H group
                  indicated, that host A should come up with
                  a stronger set of proposals.  This could
                  be useful, if the number of proposals
                  is huge such that host A sort of
                  sematically fragment the total set
                  of proposals in order to keep packet size
                  low.

Is there a right answer? Are both valid?  Are both useful?

Christian

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

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

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

---

From: "Christian Kaas-Petersen \(AH/LMD\)" <[email-masked]>
Date: Thu, 3 May 2007 11:48:17 +0200

Originally KEi was sent; in the retry KEi' is sent.  But in
both cases SAi1 is used (not SAi1 and SAi1').  Thus it is not
obvious INVALID_KE_PAYLOAD can be used to signal a change in
SAi1.  Therefore I think the example referred is not fully
illustrative of what is allowed.

Please also comment on: is it a relevant feature to be
able to break up large SA-payloads in smaller chunks in
order to keep packet size low.

Christian

> -----Original Message-----
> From: venkyee s [mailto:[email-masked]] 
> Sent: 3. maj 2007 11:35
> To: Christian Kaas-Petersen (AH/LMD); [email-masked]
> Subject: Re: [Ipsec] Is this a good use of the 
> INVALID_KE_PAYLOAD notification?
> 
> Hello,
> 
>                               <-- HDR(A,B), SAr1, KEr, Nr
> Your Interpretation 2 should be feasible.
> 
> Regards,
> _Venkyee
> 
> 
> 
> ________________________________
> 
> Ahhh...imagining that irresistible "new car" smell?
> Check out new cars at Yahoo! Autos. 
> <http://us.rd.yahoo.com/evt=48245/*http://autos.yahoo.com/new_
> cars.html;_ylc=X3oDMTE1YW1jcXJ2BF9TAzk3MTA3MDc2BHNlYwNtYWlsdGF
> ncwRzbGsDbmV3LWNhcnM->  
>

---

From: <[email-masked]>
Date: Thu, 3 May 2007 15:40:40 +0300

> illustrative of what is allowed.

I agree with what Martin Willi already said: if the responder 
doesn't accept any of the initiator's proposals, it should reply 
with NO_PROPOSAL_CHOSEN, not INVALID_KE_PAYLOAD.

> Please also comment on: is it a relevant feature to be able to 
> break up large SA-payloads in smaller chunks in order to keep 
> packet size low.

No. This messes up the semantics of the negotiation and could lead to
downgrade attacks. The initiator should propose what it finds
acceptable; and "what it finds acceptable" should be changed only
manually by the administrator (and certainly *not* based on any
unauthenticated payloads sent by the responder).

Best regards,
Pasi