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 protected] [mailto:[email protected]] On Behalf
> Of Yoav Nir
> Sent: Monday, February 01, 2010 13:28
> To: [email protected]
> Subject: [IPsec] Five more issues to close in IKEv2bis
>
>
> 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
>
> _______________________________________________
> IPsec mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/ipsec
>
> Scanned by Check Point Total Security Gateway.
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
