Hi William,
thank you for your review.
Hi Valery,
Previously, I’ve reviewed this draft before the working group adoption. I’ve
reviewed the lasted version and I think it’s in the good shape.
Here I have only two questions for your confirmation.
1. If the initiator proposes USE_PPK_INT in the request but the responder
doesn’t include it in the response, then the initiator still includes
PPK_IDENTITY_KEY when creating the Child SA, how should the responder process
at this time? The other similar situation
If the responder doesn’t include USE_PPK_INT, then it either doesn’t support
this extension or is not configured to use it.
In both cases it will ignore PPK_IDENTITY_KEY as unknown status notification
(in the second case – it is “unknown” notification in the current context).
2. is that the initiator doesn’t include USE_PPK_INT when creating the
IKE_SA but includes PPK_IDENTITY_KEY when creating the Child SA. Should the
responder reply with NO_PROPOSAL_CHOSEN, or ignore the PPK_IDENTITY_KEY and
process as usual?
Using PPKs in CRETE_CHILD_SA is independent from using them in initial
exchanges. Thus, it doesn’t matter for this case whether USE_PPK_INT was
included in IKE_SA_INIT or not.
If the responder does not supports using PPKs in CREATE_CHILD_SA or is not
configured to use them, it will ignore PPK_IDENTITY_KEY.
If the responder supports using PPKs in CREATE_CHILD_SA, but the initiator did
not include any PPK_IDENTITY_KEY in the request (or included “wrong” PPKs),
then, in case using PPKs is mandatory for the responder, it replies with
NO_PROPOSAL_CHOSEN.
3. Currently, PPK confirmation in the PPK_IDENTITY_KEY is only generated
by the initiator and validated by the responder, is there a need to let the
responder generate a new PPK confirmation in the response and validated by the
initiator?
No, this asymmetry is intentional. The purpose of PPK confirmation is to avoid
situations when due to PPK values mismatch (as result of misconfiguration)
the responder cannot even decrypt the following request and respond with an
error notification. Thus, checking PPK confirmation assures the responder that
the protocol can always complete, even in case of errors. There is no point to
send PPK confirmation in the opposite direction – it gives no new information
to initiator and only complicates protocol (e.g. – what to do if the responder
sends back a different confirmation for the key – how proceed with this?).
One nit in the second paragraph in section 3.2: s/THe PPK Confirmation/The PPK
Confirmation.
Fixed, thank you.
Regards,
Valery.
Regards & Thanks！
Wei PAN (潘伟)
_______________________________________________
IPsec mailing list -- ipsec@ietf.org
To unsubscribe send an email to ipsec-le...@ietf.org
