Subject: [IPsec] Closing some of the open tickets for IKEv2bis

From: Yoav Nir <[email-masked]>
Date: Mon, 25 Jan 2010 08:12:13 +0200

Hi all

We would like to begin closing IKEv2bis issue at a faster rate than we are opening new ones. Paul has sent the list a several issues. Some we have discussed, others - not so much. Here's a summary of three issues, which I think are ready for closure.

Issue #138 - Calculations involving Ni/Nr
=========================================
Section 2.14: "only the first 64 bits of Ni and the first 64 bits of Nr are used in the calculation". This section has two calculations involving Ni/Nr, but this sentence should only apply to the former. Suggested rephrasing: "the calculation" -> "when calculating SKEYSEED (but all bits are used when calculating SK_*)"

There was just one response (from me), and I suggested the following text:
   only the first 64 bits of Ni and the first 64 bits of Nr are used in calculating SKEYSEED, but all the bits are used for input to the prf+ function.

If anyone else has comments about this issue, please raise them NOW, because we are going to close this in a few days.

Issue #139 - Keying material taken in the order for RoHC
========================================================
One of the differences between RFC 4306 and the IKEv2bis draft is in Section 2.17, Generating Key Material for Child SAs. Appendix E.2 of the IKEv2bis draft indicates the following:
In Section 2.17, removed "If multiple IPsec protocols are negotiated, keying material is taken in the order in which the protocol headers will appear in the encapsulated packet" because multiple IPsec protocols cannot be negotiated at one time.
Is it possible to leave the quoted text in the spec? I agree that multiple IPsec protocols cannot be negotiated at one time; however, the text is useful for ROHCoIPsec implementers, where multiple keys may need to be generated for a ROHC-enabled Child SA.
For example, if a ROHC-enabled Child-SA with ROHC_INTEG [draft-ietf-rohc-ikev2-extensions-hcoipsec-09] is instantiated, first the IPsec encryption/authentication keying material will be taken, then an additional key will be taken for the algorithm used to verify the proper decompression of packet headers.

I said I preferred to leave the text as it is, and let RoHC specify their modifications (which they did). Valery, Tero, and David chimed in, correctly pointing out that if multiple extensions are negotiated (RoHC + GCM + some future extension) it is up to the base document to specify the order between them. I'm convinced. Paul also suggested some text (below) for a bulleted list of two points. Tero suggested a third (encryption before authentication), but Valery pointed out that this is already in 4301.

   If the Child SA negotiation includes some future IPsec protocol(s)
   in addition to (or instead of) ESP or AH (e.g., ROHC_INTEG), then
   (1) all keys for SAs carrying data from the initiator to the
   responder are taken before SAs going in the reverse direction, and
   (2) keying material for the IPsec protocols are taken in the order
   in which the protocol headers will appear in the encapsulated
   packet.

If anyone else has comments about this issue, please raise them NOW, because we are going to close this in a few days.

Issue #141 - Silently deleting the Child SA after a CHILD_SA_NOT_FOUND
======================================================================
Section 2.25: "A peer that receives a CHILD_SA_NOT_FOUND
notification SHOULD silently delete the Child SA": Is this really
necessary? I think this notification should only occur in cases where
DELETE payload for this Child SA pair has already been sent, and
probably has been processed already by the time the CHILD_SA_NOT_FOUND
notification is received.

No responses were received for this. My opinion is that CHILD_SA_NOT_FOUND will usually not occur at all. Even if lifetime is the same on both peers, rekeying is always done earlier than deleting (for example, if your SAs last 1 hour, you might rekey at 58 minutes, but only delete after 60 minmutes), so collisions of rekey and delete will be rare. Because of this, I believe that the CHILD_SA_NOT_FOUND will stem from some mismatch in the SAD between the two peers. Yes, this probably indicates a bug somewhere, but these things do happen. I believe the text should stay, as it clarifies that the peer does not need to create a new INFORMATIONAL exchange with a DELETE payload to discard. In fact the text already has in brackets "(if it still exists)"

If anyone else has comments about this issue, please raise them NOW, because we are going to close this in a few days.

I would also like to take this opportunity to ask people to look into issue #140 (No SPD entry for transport mode), as I think this one needs some serious discussion before closing.

Yoav

---

From: "Valery Smyslov" <[email-masked]>
Date: Mon, 25 Jan 2010 10:53:09 +0300

Yoav Nir writes:

> One of the differences between RFC 4306 and the IKEv2bis draft is in
Section 2.17, Generating Key Material for Child SAs. Appendix E.2 of the
IKEv2bis draft indicates the following:
> In Section 2.17, removed "If multiple IPsec protocols are negotiated,
keying material is taken in the order in which the protocol headers will
appear in the encapsulated packet" because multiple IPsec protocols cannot
be negotiated at one time.
> Is it possible to leave the quoted text in the spec? I agree that multiple
IPsec protocols cannot be negotiated at one time; however, the text is
useful for ROHCoIPsec implementers, where multiple keys may need to be
generated for a ROHC-enabled Child SA.
> For example, if a ROHC-enabled Child-SA with ROHC_INTEG
[draft-ietf-rohc-ikev2-extensions-hcoipsec-09] is instantiated, first the
IPsec encryption/authentication keying material will be taken, then an
additional key will be taken for the algorithm used to verify the proper
decompression of packet headers.
>
> I said I preferred to leave the text as it is, and let RoHC specify their
modifications (which they did). Valery, Tero, and David chimed in, correctly
pointing out that if multiple extensions are negotiated (RoHC + GCM + some
future extension) it is up to the base document to specify the order between
them. I'm convinced. Paul also suggested some text (below) for a bulleted
list of two points. Tero suggested a third (encryption before
authentication), but Valery pointed out that this is already in 4301.
> If anyone else has comments about this issue, please raise them NOW,
because we are going to close this in a few days.

Sorry for being tedious, but I don't understand whether proposed text is in
addition
to current one, or replaces it. Current text from draft-07 overlaps with
RFC4301,
which already prescribes the order for deriving encryption and
authentication keys
for single SA. I see no point to repeat this rule (at least in RFC2119
terms).

I would suugest replacing current text from draft-07:
========================================================
   For ESP and AH, a single Child SA negotiation results in two security
   associations (one in each direction).  Keying material MUST be taken
   from the expanded KEYMAT in the following order:

   o  The encryption key (if any) for the SA carrying data from the
      initiator to the responder.

   o  The authentication key (if any) for the SA carrying data from the
      initiator to the responder.

   o  The encryption key (if any) for the SA carrying data from the
      responder to the initiator.

   o  The authentication key (if any) for the SA carrying data from the
      responder to the initiator.
========================================================

with the following:
========================================================
   A single CHILD_SA negotiation may result in multiple security
   associations.  ESP and AH SAs exist in pairs (one in each direction),
   so two SAs are created in a single Child SA negotiation for them.
   Furthermore, Child SA negotiation may include some future IPsec
protocol(s)
   in addition to (or instead of) ESP or AH (e.g., ROHC_INTEG).
   In any case, keying material for each child SA MUST be taken from the
   expanded KEYMAT in the following order:

   o  All keys for SAs carrying data from the initiator to the responder
      are taken before SAs going in the reverse direction.

   o  If multiple IPsec protocols are negotiated, keying material is
      taken in the order in which the protocol headers will appear in
      the encapsulated packet.

   If IPsec protocol requires multiple keys, the order in which they are
derived
   from SA's keyng material MUST be described in protocol specification. For
ESP
   and AH [IPSECARCH] defines the order, namely: the encryption key (if any)
   MUST be taken from the first bits and the integrity key (if any) MUST be
taken
   from the remaining bits.
========================================================

Regards,
Valery Smyslov.

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 25 Jan 2010 13:44:06 +0200

Yoav Nir writes:
> Section 2.14: "only the first 64 bits of Ni and the first 64 bits of
> Nr are used in the calculation". This section has two calculations
> involving Ni/Nr, but this sentence should only apply to the former.
> Suggested rephrasing: "the calculation" -> "when calculating
> SKEYSEED (but all bits are used when calculating SK_*)" 
> 
>    only the first 64 bits of Ni and the first 64 bits of Nr are used
> in calculating SKEYSEED, but all the bits are used for input to the
> prf+ function. 

That change is ok for me.

> Section 2.17, Generating Key Material for Child SAs. Appendix E.2 of
> the IKEv2bis draft indicates the following: 
> In Section 2.17, removed "If multiple IPsec protocols are
> negotiated, keying material is taken in the order in which the
> protocol headers will appear in the encapsulated packet" because
> multiple IPsec protocols cannot be negotiated at one time. 
> Is it possible to leave the quoted text in the spec? I agree that
> multiple IPsec protocols cannot be negotiated at one time; however,
> the text is useful for ROHCoIPsec implementers, where multiple keys
> may need to be generated for a ROHC-enabled Child SA. 
> [draft-ietf-rohc-ikev2-extensions-hcoipsec-09] is instantiated,
> first the IPsec encryption/authentication keying material will be
> taken, then an additional key will be taken for the algorithm used
> to verify the proper decompression of packet headers. 
> 
> I said I preferred to leave the text as it is, and let RoHC specify
> their modifications (which they did). Valery, Tero, and David chimed
> in, correctly pointing out that if multiple extensions are
> negotiated (RoHC + GCM + some future extension) it is up to the base
> document to specify the order between them. I'm convinced. Paul also
> suggested some text (below) for a bulleted list of two points. Tero
> suggested a third (encryption before authentication), but Valery
> pointed out that this is already in 4301. 
> 

This two bullet version is fine by me, I had missed the text in the
RFC4301, so my proposed 3rd bullet is not need.

> No responses were received for this.

I proposed new text for this:

http://www.ietf.org/mail-archive/web/ipsec/current/msg05695.html

> My opinion is that CHILD_SA_NOT_FOUND will usually not occur at all.
> Even if lifetime is the same on both peers, rekeying is always done
> earlier than deleting (for example, if your SAs last 1 hour, you
> might rekey at 58 minutes, but only delete after 60 minmutes), so
> collisions of rekey and delete will be rare. Because of this, I
> believe that the CHILD_SA_NOT_FOUND will stem from some mismatch in
> the SAD between the two peers. Yes, this probably indicates a bug
> somewhere, but these things do happen. I believe the text should
> stay, as it clarifies that the peer does not need to create a new
> INFORMATIONAL exchange with a DELETE payload to discard. In fact the
> text already has in brackets "(if it still exists)"

That bracketed part was added to solve this #141. 

> because we are going to close this in a few days.

So I think this issue can already be closed, as the at least from my
point of view the fix has already been added to the -07 version. 

> I would also like to take this opportunity to ask people to look
> into issue #140 (No SPD entry for transport mode), as I think this
> one needs some serious discussion before closing. 

As I pointed out in my email
http://www.ietf.org/mail-archive/web/ipsec/current/msg05694.html
I need more information what RFC5555 really needs before I can comment
on this issue. I used about half an hour writing about 200 lines of
more detailed analysis about the issue, but then ended up deleting it
when I realized that it is no point for me to go and try to cover all
possible cases, as everything depends what RFC5555 really needs.
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 25 Jan 2010 13:47:42 +0200

> I would suugest replacing current text from draft-07:

That change looks fine for me.
-- 
[email-masked]

---

From: Yoav Nir <[email-masked]>
Date: Mon, 25 Jan 2010 13:54:05 +0200

> point of view the fix has already been added to the -07 version. 

Thanks. Closed.