Subject: [IPsec] Five more issues to close in IKEv2bis

From: Yoav Nir <[email-masked]>
Date: Mon, 1 Feb 2010 13:27:49 +0200

Hi all.

Yet another batch of issues that we wish to close.

Issue #140 - No SPD entry for transport mode
============================================
Section 2.23.1: If the responder doesn't find SPD entry for transport mode with the modified traffic selectors, and does a lookup with the original selectors, if it finds an entry for transport mode, can it use it? (And would that screw up the initiator processing of the reply? Unfortunately, this question is relevant for RFC 5555...)

Pasi and Tero had a discussion about this on list. Apparently, the strange scenario is with a multi-homed host, where IKE went through one interface, while IPsec went through another, so that IKE was NATted, but IPsec was not. Tero thinks such a case would never work, while Pasi thinks it is allowed by RFC 4301 (though probably won't work with most implementations)

I think the scenario is so far-fetched (because discovering NAT in IKE makes IPsec UDP-encapsulated), that we can afford to ignore it for now. If it comes up in real life, somebody will get the opportunity to write an extension document.

Unless people feel strongly otherwise, I suggest we close this issue in a couple of days without text changes.

Issue #148 - Historical Cookie Discussion
=========================================
In 2.6, first paragraph: the historical discussion going back to the previous century is very confusing to a newcomer: instead of saying what a cookie is, we tell a story. I suggest to remove this discussion or move it to the end of the section.
Can we separate the cookie discussion into its own subsection? For two reasons: it is an implementation hint, rather than a specification (as opposed to the normative text on SPIs earlier in 2.6); and it is not very important, given the prevalence of DDos.

Both me and Pasi said we were not confused by this, and nobody else chimed in.  I agree with Pasi - the path of least resistance is to leave it as is.

Issue #150 - What happens if the peer receives TEMPORARY_FAILURE and ...
========================================================================
2.8.2: we should add a sentence on what happens if the peer receives 
TEMPORARY_FAILURE and does not understand it (because it's new to this spec).

Keith explained how this issue came about. In any case, I think this can be closed with an addition of the following short paragraph:

   Support of the TEMPORARY_FAILURE notification is not negotiated, so older
   peers may get it. In that case, they will treat it as any other unknown 
   error notification and fail the exchange. Since the other peer has 
   already rekeyed the exchange, this does not have any ill effects.

Again, if you object to this, please speak up now.

Issue #151 - Explicit calculation of AUTH
=========================================
2.16: it would be useful if we added the explicit calculation of AUTH. For example, is the padding string required for EAP as well? There are two cases, with MSK and with SK_pi+SK_pr.

No discussion for this issue.

I suggest the following paragraph should be added to section 2.15, right after the explicit AUTH calculation (added here for clarity):

   For the initiator:
      AUTH = prf( prf(Shared Secret, "Key Pad for IKEv2"),
                       <InitiatorSignedOctets>)
   For the responder:
      AUTH = prf( prf(Shared Secret, "Key Pad for IKEv2"),
                       <ResponderSignedOctets>)

   For EAP authentication (see [Section 2.16]), there are two cases. If the 
   EAP method is key-generating, substitute "MSK" for "Shared Secret" above. 
   For non-key-generating methods, use SK_pi and SK_pr for the two formulas
   above respectively.

Would this satisfy everybody?

Issue #152 - EAP failure and acknowledgement
============================================
2.16: if the responder sends an EAP Failure, is this IKE message acknowledged by the initiator?

Yaron & Tero discussed this a bit, and the conclusion was to change the text in 2.21 as follows

Before:
   Only authentication failures (AUTHENTICATION_FAILED) and malformed
   messages (INVALID_SYNTAX) lead to a deletion of the IKE SA without
   requiring an explicit INFORMATIONAL exchange carrying a DELETE
   payload.  Other error conditions MAY require such an exchange if
   policy dictates that this is needed.

After:
   Only authentication failures (AUTHENTICATION_FAILED and EAP failure) and
   Malformed messages (INVALID_SYNTAX) lead to a deletion of the IKE SA
   Without requiring an explicit INFORMATIONAL exchange carrying a DELETE
   payload.  Other error conditions MAY require such an exchange if
   policy dictates that this is needed.

And also add at the end of 2.16:
   If the exchange is terminated with EAP Failure, an AUTHENTICATION_FAILED
   notification is not sent.

Unless anybody objects, we will make these changes in the draft.

Yoav

---

From: Yaron Sheffer <[email-masked]>
Date: Tue, 2 Feb 2010 11:06:45 +0200

Here's a concrete rewording proposal.

Old:

The term "cookies" originates with Karn and Simpson [PHOTURIS] in Photuris, an early proposal for key management with IPsec, and it has persisted. The Internet Security Association and Key Management Protocol (ISAKMP) [ISAKMP] fixed message header includes two eight-octet fields titled "cookies", and that syntax is used by both IKEv1 and IKEv2, although in IKEv2 they are referred to as the "IKE SPI" and there is a new separate field in a Notify payload holding the cookie. The initial two eight-octet fields in the header are used as a connection identifier at the beginning of IKE packets. Each endpoint chooses one of the two SPIs and MUST choose them so as to be unique identifiers of an IKE SA. An SPI value of zero is special and indicates that the remote SPI value is not yet known by the sender.

New:

The initial two eight-octet fields in the header, termed "IKE SPIs", are used as a connection identifier at the beginning of IKE packets. Each endpoint chooses one of the two SPIs and MUST choose them so as to be unique identifiers of an IKE SA. An SPI value of zero is special and indicates that the remote SPI value is not yet known by the sender.

[Add as the last paragraph of 2.6:]

A note on terminology: the term "cookies" originates with Karn and Simpson [PHOTURIS] in Photuris, an early proposal for key management with IPsec, and it has persisted. The Internet Security Association and Key Management Protocol (ISAKMP) [ISAKMP] fixed message header includes two eight-octet fields titled "cookies", and that syntax is used by both IKEv1 and IKEv2, although in IKEv2 they are referred to as the "IKE SPI" and there is a new separate field in a Notify payload holding the cookie.

Thanks,
	Yaron

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Yoav Nir
> Sent: Monday, February 01, 2010 13:28
> To: [email-masked]
> Subject: [IPsec] Five more issues to close in IKEv2bis
> 
> 
> Hi all.
> 
> Section 2.23.1: If the responder doesn't find SPD entry for transport
> mode with the modified traffic selectors, and does a lookup with the
> original selectors, if it finds an entry for transport mode, can it use
> it? (And would that screw up the initiator processing of the reply?
> Unfortunately, this question is relevant for RFC 5555...)
> 
> Pasi and Tero had a discussion about this on list. Apparently, the
> strange scenario is with a multi-homed host, where IKE went through one
> interface, while IPsec went through another, so that IKE was NATted,
> but IPsec was not. Tero thinks such a case would never work, while Pasi
> thinks it is allowed by RFC 4301 (though probably won't work with most
> implementations)
> 
> I think the scenario is so far-fetched (because discovering NAT in IKE
> makes IPsec UDP-encapsulated), that we can afford to ignore it for now.
> If it comes up in real life, somebody will get the opportunity to write
> an extension document.
> 
> In 2.6, first paragraph: the historical discussion going back to the
> previous century is very confusing to a newcomer: instead of saying
> what a cookie is, we tell a story. I suggest to remove this discussion
> or move it to the end of the section.
> Can we separate the cookie discussion into its own subsection? For two
> reasons: it is an implementation hint, rather than a specification (as
> opposed to the normative text on SPIs earlier in 2.6); and it is not
> very important, given the prevalence of DDos.
> 
> Both me and Pasi said we were not confused by this, and nobody else
> chimed in.  I agree with Pasi - the path of least resistance is to
> leave it as is.
> 
> 
> 
> Keith explained how this issue came about. In any case, I think this
> can be closed with an addition of the following short paragraph:
> 
> 2.16: it would be useful if we added the explicit calculation of AUTH.
> For example, is the padding string required for EAP as well? There are
> two cases, with MSK and with SK_pi+SK_pr.
> 
> I suggest the following paragraph should be added to section 2.15,
> right after the explicit AUTH calculation (added here for clarity):
> 
>    For the initiator:
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec
> 
> Scanned by Check Point Total Security Gateway.

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 2 Feb 2010 09:25:29 -0800

>A note on terminology: the term "cookies" originates with Karn and Simpson [PHOTURIS] in Photuris, an early proposal for key management with IPsec, and it has persisted. The Internet Security Associ…

I support this change.

--Paul Hoffman, Director
--VPN Consortium

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 8 Feb 2010 17:39:40 +0200

Yoav Nir writes:
> Unless people feel strongly otherwise, I suggest we close this issue
> in a couple of days without text changes.

I support closing this without changes.

> what a cookie is, we tell a story. I suggest to remove this
> discussion or move it to the end of the section. 
> Can we separate the cookie discussion into its own subsection? For
> two reasons: it is an implementation hint, rather than a
> specification (as opposed to the normative text on SPIs earlier in
> 2.6); and it is not very important, given the prevalence of DDos. 
> 

I also support closing this without changes. 

> Issue #150 - What happens if the peer receives TEMPORARY_FAILURE and ...

That text looks good for me.

> 2.16: it would be useful if we added the explicit calculation of
> AUTH. For example, is the padding string required for EAP as well?
> There are two cases, with MSK and with SK_pi+SK_pr. 
> 

I think the EAP authentation paragraph could be at the end of the
section, not right after the AUTH calculation, as the next paragraph
clearly assumes it is right after the AUTH calculation as it starts:

   where the string "Key Pad for IKEv2" is 17 ASCII characters without
   null termination.  The shared secret can be variable length.  ...

> Issue #152 - EAP failure and acknowledgement

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

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 8 Feb 2010 17:41:54 +0200

Yaron Sheffer writes:
> The term "cookies" originates with Karn and Simpson [PHOTURIS] in
> Photuris, an early proposal for key management with IPsec, and it
> has persisted. The Internet Security Association and Key Management
> Protocol (ISAKMP) [ISAKMP] fixed message header includes two
> eight-octet fields titled "cookies", and that syntax is used by both
> IKEv1 and IKEv2, although in IKEv2 they are referred to as the "IKE
> SPI" and there is a new separate field in a Notify payload holding
> the cookie. The initial two eight-octet fields in the header are
> used as a connection identifier at the beginning of IKE packets.
> Each endpoint chooses one of the two SPIs and MUST choose them so as
> to be unique identifiers of an IKE SA. An SPI value of zero is
> special and indicates that the remote SPI value is not yet known by
> the sender. 
> 
> New:
> 
> The initial two eight-octet fields in the header, termed "IKE SPIs",
> are used as a connection identifier at the beginning of IKE packets.
> Each endpoint chooses one of the two SPIs and MUST choose them so as
> to be unique identifiers of an IKE SA. An SPI value of zero is
> special and indicates that the remote SPI value is not yet known by
> the sender. 
> 
> A note on terminology: the term "cookies" originates with Karn and
> Simpson [PHOTURIS] in Photuris, an early proposal for key management
> with IPsec, and it has persisted. The Internet Security Association
> and Key Management Protocol (ISAKMP) [ISAKMP] fixed message header
> includes two eight-octet fields titled "cookies", and that syntax is
> used by both IKEv1 and IKEv2, although in IKEv2 they are referred to
> as the "IKE SPI" and there is a new separate field in a Notify
> payload holding the cookie. 

That change is fine too (altough I could also accept leaving it as it
is). 
-- 
[email-masked]