Re: [IPsec] WGLC on draft-ietf-ipsecme-qr-ikev2-04
> > 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. OK, I think it's a good suggestion. Thank you, Valery. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
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
Re: [IPsec] WGLC on draft-ietf-ipsecme-qr-ikev2-04
Classification: UNCLASSIFIED
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' .
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 ...".
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).
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
Re: [IPsec] WGLC on draft-ietf-ipsecme-qr-ikev2-04
> > 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. > > I believe the document is ready. We (libreswan) have implemented it and > performed successful interop with 3 other vendors (Cisco, Apple, Elvis+) I agree with Paul that the document is ready. I would only add that the protocol is quite stable - no changes were made to it within last year (since December 2017), only some clarifications. Regards, Valery. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] WGLC on draft-ietf-ipsecme-qr-ikev2-04
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. I believe the document is ready. We (libreswan) have implemented it and performed successful interop with 3 other vendors (Cisco, Apple, Elvis+) It is important because this eliminates one of the very few reasons left why people would need to run IKEv1 instead of IKEv2. Paul ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
