Yoav Nir writes: > Issue #140 - No SPD entry for transport mode > ============================================ > 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. > 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. I also support closing this without changes. > 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. That text looks good for me. > 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? 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 > ============================================ > 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. That change looks good for me... -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
