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

["Hammell, Jonathan F" <[e-mail]>]

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.