Subject: [Ipsec] INVALID_KE_PAYLOAD and clarifications document

From: Tero Kivinen <[email-masked]>
Date: Tue, 20 Sep 2005 23:09:30 +0300

There are couple of issues noticed here in the ipsec bake-off event
about the INVALID_KE_PAYLOAD that could use some more clarification in
clarifications document.

----------------------------------------------------------------------
2.1  SPI values in IKE_SA_INIT exchange
...
   Since the IKE_SA_INIT request always has a zero responder SPI, the
   value will not be actually used by the initiator.  Thus, we think
   sending a zero value is correct also in this case.
----------------------------------------------------------------------

I think another possible interpreation would be that if responder
allocated responder SPI in those error messages, it actually also
generated some state, thus the initiator should use that responder SPI
to help the responder to keep track of that state.

On the other hand there is no reason to generate state in those cases,
thus the responder should always send responder SPI as zero.

So for the responder: Use SPIr as zero unless you allocate state.

For initiator: copy the SPIr from the previous message (most likely it
is zero).

Another issue is the section 2.4. It is missing the most common case
that everybody is using:

      Initiator                   Responder
     -----------                 -----------
      HDR(A,0), SAi1, KEi, Ni -->
                              <-- HDR(A,0), N(COOKIE)
      HDR(A,0), N(COOKIE), SAi1, KEi, Ni  -->
                              <-- HDR(A,0), N(INVALID_KE_PAYLOAD)
      HDR(A,0), N(COOKIE), SAi1, KEi', Ni -->
                              <-- HDR(A,B), SAr1, KEr, Nr

I.e. if you have received a cookie during the exchange, you need to
use that in all the future versions of the IKE_SA_INIT messages. This
will cut out one round trip in the exchange.
-- 
[email-masked]

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

---

From: Yoav Nir <[email-masked]>
Date: Tue, 20 Sep 2005 21:58:14 -0400

Comments inline.

> about the INVALID_KE_PAYLOAD that could use some more clarification in

Is this really necessary? I think it needlessly complicates things for 
the initiator. It creates two distinct behaviors the initiator can 
expect. When the initiator tries again, suppose the responder responds 
with another SPIr. Does this matter? Should the initiator stop the 
exchange?

> Another issue is the section 2.4. It is missing the most common case

This assumes that the cookie is still valid.  If you use the algorithm 
suggested in section 2.6 of the draft (bottom of page 19), then it is. 
But the draft does not mandate this algorithm, and it's certainly 
possible that the cookie is calculated based on the contents of the KE 
payload. In such a case the original cookie is not valid.
This brings up another issue.  Does the draft specify what a responder 
should do if it receives an invalid cookie? We know what it should do 
with a valid cookie and what it should do with no cookie at all (send a 
cookie), but what if the cookie does not compute?  Silently discard?  
Send the correct cookie?

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 21 Sep 2005 16:00:29 +0300

Yoav Nir writes:
> expect.

Actually no it does not. Initiator will simply use the same SPIr that
was sent to him. He does not need to know how or why the other end
selected his SPIr, so he simply uses that as normally. 

> When the initiator tries again, suppose the responder responds 
> with another SPIr.

Why would the responder respond with another SPIr? If he has allocated
some SPIr because of he allocated some state, he are going to use the
same SPIr. If he allocated SPIr because of bug in his code, that
should be fixed, or at least he should except to get it back. 

> Does this matter? Should the initiator stop the 
> exchange?

Initiator should process it just like normally when SPIr changes in
the middle. Some implementations will consider it new IKE SA, some
will simply continue checking the SPI they allocated (SPIi in this
case), and continue with that IKE SA (or even update the SPIr). The
IKEv2 used to have feature where the responder could change his own
SPIr, but that was removed. The current text says:

----------------------------------------------------------------------
2.6 Cookies
...
   message. Since the SPI chosen by the original initiator of the
   IKE_SA is always sent first, an endpoint with multiple IKE_SAs open
   that wants to find the appropriate IKE_SA using the SPI it assigned
   must look at the I(nitiator) Flag bit in the header to determine
   whether it assigned the first or the second eight octets.
...
----------------------------------------------------------------------

So that does not really say what you should do in case the SPI that
the other end allocated changes.

Anyways as the responder should not allocate state in either cookie
nor in the invalid ke payload messages, the easiest thing is to say
that SPIr must be zero for all of those cases, and in that case it
does not really matter what initiator does if the SPIr is non-zero.

I myself have implemented it so that we always send SPIr as zero in
those cases, but if the other end used some other SPIr in those cases,
I will copy that SPIr to the next message I send out (as I assume
there was some reason for it to use non-zero SPIr). 

> suggested in section 2.6 of the draft (bottom of page 19), then it is. 

True. Note also that is completely valid for the cookie not be valid
in any of the cases, as it might be the responder has just changed the
cookie calculation secret so many times during the exchange that old
cookies are not valid. 

> payload. In such a case the original cookie is not valid.

Yes, and in that case the responder returns me the new cookie:

       Initiator                   Responder
      -----------                 -----------
                               <-- HDR(A,0), N(COOKIE')
       HDR(A,0), N(COOKIE'), SAi1, KEi', Ni  -->

> should do if it receives an invalid cookie?

As he cannot distinguish an old cookie before laste secret version
change, and completely random cookie, I assume it is supposed to
generate new cookie, and send that to the initiator:

----------------------------------------------------------------------
   If a new value for <secret> is chosen while there are connections
   in the process of being initialized, an IKE_SA_INIT might be
   returned with other than the current <VersionIDofSecret>. The
   responder in that case MAY reject the message by sending another
   response with a new cookie or it MAY keep the old value of <secret>
   around for a short time and accept cookies computed from either
   one. 
----------------------------------------------------------------------

> We know what it should do with a valid cookie and what it should do
> with no cookie at all (send a cookie), but what if the cookie does
> not compute? Silently discard? Send the correct cookie?

Send correct cookie. Cookie generartion is cheap, so why not allow
connections to work also under attack (even if there is thousands of
faked messages coming in requesting cookies, there might be still one
valid message coming in and it should respond to it with cookie). 
-- 
[email-masked]