Re: [IPsec] WGLC on draft-ietf-ipsecme-qr-ikev2-04

2018-12-17 Thread Valery Smyslov
> > 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

2018-12-14 Thread Hammell, Jonathan F
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  
Sent: December-14-18 2:09 AM
To: Hammell, Jonathan F ; 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 co

Re: [IPsec] WGLC on draft-ietf-ipsecme-qr-ikev2-04

2018-12-13 Thread Valery Smyslov
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 comment

Re: [IPsec] WGLC on draft-ietf-ipsecme-qr-ikev2-04

2018-12-13 Thread Hammell, Jonathan F
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

2018-12-03 Thread Valery Smyslov
> > 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

2018-12-01 Thread Paul Wouters

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


[IPsec] WGLC on draft-ietf-ipsecme-qr-ikev2-04

2018-11-30 Thread Waltermire, David A. (Fed)
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.

Regards,
Dave and Tero

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec