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
