Classification: UNCLASSIFIED Hi Valery, Thanks for your quick reply.
>> 2. Section Upgrade procedure - We recommend changing the statement "As >> an optional second step, after all nodes have been upgraded, the >> administrator may then go back ... and mark the use of PPK as mandatory." to >> "After all nodes have been upgraded, the administrator SHOULD go back ...". > > I don't think the proposed change is justified. The requirement language > (MAY, SHOULD, MUST etc.) it IETF documents is usually used in > protocol descriptions when some actions are required (or prohibited) to > achieve interoperability. Section "Upgrade procedure" is not > concerned with the protocol itself, it is just a recommended algorithm for > upgrading some system for using PPK. It is not the only algorithm > possible. And it isn't concerned with interoperability of different protocol > implementations. So, I'd leave the text as is. We agree with your interpretation that a capital SHOULD might not be appropriate, but we still feel a lowercase "should" in place of "may" will encourage more administrators to complete the upgrade procedure. >> 3. IKEv2 with EAP authentication -the EAP-ikev2 protocol description >> in the draft is different from that in the >> EAP-IKEv2 RFC 5106 beyond what we expect because of PPK use (i.e >> Initiator does not send an AUTH payload in the first EAP-Req message). > > This is a confusion. The draft is not relevant to RFC 5106, so the whole > comment is a result of misunderstanding. > Let me explain. The EAP protocol is a framework for various authentication > protocols, called EAP methods. > A lot of EAP methods are defined (see > https://www.iana.org/assignments/eap-numbers/eap-numbers.xhtml#eap-numbers-4). > > The IKEv2 accommodates EAP as an alternative way to authenticate peers. How > EAP is used in IKEv2 is defined in RFC 7296 - the core > IKEv2 spec (in particular see Section 2.16). The confusion comes from the > fact, that there is also an EAP method called EAP-IKEv2, > defined in RFC 5106. This RFC describes how IKEv2-like protocol can be used > inside EAP framework to achieve authentication, but it has > nothing to do with how EAP framework is used within IKEv2. The draft is > concerned with the latter, clarifying things for PPK use case. > It is not concerned with EAP-IKEv2 EAP method. We reviewed this again and you are completely right. Thanks for explaining the difference. Best regards, Jonathan -----Original Message----- From: Valery Smyslov <smyslov.i...@gmail.com> Sent: December-14-18 2:09 AM To: Hammell, Jonathan F <jonathan.hamm...@cyber.gc.ca>; ipsec@ietf.org Subject: RE: [IPsec] WGLC on draft-ietf-ipsecme-qr-ikev2-04 Hi Jonathan, thank you for your review. Please see my comments inline. > The Canadian Centre for Cyber Security has reviewed > draft-ietf-ipsecme-qr-ikev2-04 and recommends the authors address the > following comments before proceeding to IESG. > > 1. The table on Page 8 refers to the term 'HAVE PPK' - this term is > not used elsewhere in the document. To understand the table the reader is > left to surmise its meaning. We understand the term as the Responder > being configured with a PPK for the Initiator (identified by the PPK_ID). > We recommend either defining what > is meant by 'HAVE PPK' or changing the term from 'HAVE PPK' to > 'Configured with PPK for the initiator' which is how it is described in the > Upgrade procedure or more simply as 'Configured with PPK' . I see your point. We'll think how to make this text more clear. > 2. Section Upgrade procedure - We recommend changing the statement "As > an optional second step, after all nodes have been upgraded, the > administrator may then go back ... and mark the use of PPK as mandatory." to > "After all nodes have been upgraded, the administrator SHOULD go back ...". I don't think the proposed change is justified. The requirement language (MAY, SHOULD, MUST etc.) it IETF documents is usually used in protocol descriptions when some actions are required (or prohibited) to achieve interoperability. Section "Upgrade procedure" is not concerned with the protocol itself, it is just a recommended algorithm for upgrading some system for using PPK. It is not the only algorithm possible. And it isn't concerned with interoperability of different protocol implementations. So, I'd leave the text as is. > 3. IKEv2 with EAP authentication -the EAP-ikev2 protocol description > in the draft is different from that in the > EAP-IKEv2 RFC 5106 beyond what we expect because of PPK use (i.e > Initiator does not send an AUTH payload in the first EAP-Req message). This is a confusion. The draft is not relevant to RFC 5106, so the whole comment is a result of misunderstanding. Let me explain. The EAP protocol is a framework for various authentication protocols, called EAP methods. A lot of EAP methods are defined (see https://www.iana.org/assignments/eap-numbers/eap-numbers.xhtml#eap-numbers-4). The IKEv2 accommodates EAP as an alternative way to authenticate peers. How EAP is used in IKEv2 is defined in RFC 7296 - the core IKEv2 spec (in particular see Section 2.16). The confusion comes from the fact, that there is also an EAP method called EAP-IKEv2, defined in RFC 5106. This RFC describes how IKEv2-like protocol can be used inside EAP framework to achieve authentication, but it has nothing to do with how EAP framework is used within IKEv2. The draft is concerned with the latter, clarifying things for PPK use case. It is not concerned with EAP-IKEv2 EAP method. Regards, Valery. > a. Firstly, none of the message types from RFC 5106 are used in the > draft: EAP-Req, EAP-Res and EAP-Success for example. We recommend using the > same notation as in the RFC to describe EAP with PPK. > b. The draft uses the term "EAP" whose meaning is unclear but assumed to mean > an EAP type message. > c. The biggest difference appears to be the fact that it is the Responder who > sends the EAP-success message. > This may be done because an extra IKE_AUTH exchange will be performed, but an > explanation could be useful. > > We highlight two messages below (**) from the draft that appear to > not fit the RFC's description. Also it is not clear what is meant by the term > EAP in the messages, we assume that it stands for EAP-Req or EAP-Res. > > The portion of the description in the draft (without the IKE_SA_INIT > and IKE_AUTH exchanges) is > > Initiator Responder > ---------------------------------------------------------------- > HDR, SK {IDi, [CERTREQ,] > [IDr,] SAi2, > TSi, TSr} --> > <-- HDR, SK {IDr, [CERT,] AUTH, > EAP} > ** HDR, SK {EAP} --> > <-- HDR, SK {EAP (success)} ** > > > Compared with the protocol described in RFC 5106 without the > initial exchanges > > 5. R<-I: EAP-Req (HDR, SK{IDi, [CERT], [CERTREQ], [NFID], AUTH}) > 6. R->I: EAP-Res (HDR, SK{IDr, [CERT], AUTH}) > * 7. R<-I: EAP-Success > > Figure 1: EAP-IKEv2 Full, Successful Protocol Run > > > Best regards, > Jonathan > > On Fri, 30 Nov 2018, Waltermire, David A. (Fed) wrote: > > > This message starts a working group last call (WGLC) on > > draft-ietf-ipsecme-qr-ikev2-04, which will conclude > on December 14, 2018 at UTC 23:59. Please review and provide feedback > on the -04 version > (https://datatracker.ietf.org/doc/draft-ietf-ipsecme-qr-ikev2/). Please > indicate if you believe this draft is ready for publication or if you have > comments that must be addressed before the draft progresses to the IESG. > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
