Hi Valery,
Thanks for your clarification.
As “support” is not equal to “is configured to use”, I suggest the following
modifications to the paragraph below in section 3.1, because the responder
supporting both specifications can choose none to use if it is configured not
to use PPK.
OLD:
Note, that this negotiation is independent from negotiation of using
PPKs in the IKE_AUTH exchange. The initiator that supports both use
PPKS in IKE_AUTH [RFC8784] and use PPKS in IKE_INTERMEDIATE MAY
include both the USE_PPK_INT (along with the
INTERMEDIATE_EXCHANGE_SUPPORTED) and the USE_PPK notifications if it
is configured to use either specification. However, the responder
supporting both specifications have to choose one to use, thus it
MUST return either USE_PPK_INT or USE_PPK notification in the
response, but not both.
NEW:
Note, that this negotiation is independent from negotiation of using
PPKs in the IKE_AUTH exchange. The initiator that supports both use
PPKS in IKE_AUTH [RFC8784] and use PPKS in IKE_INTERMEDIATE MAY
include both the USE_PPK_INT (along with the
INTERMEDIATE_EXCHANGE_SUPPORTED) and the USE_PPK notifications if it
is configured to use either specification. However, if the responder
supports both specifications and is configured to use PPKs, it has to choose
one to use, thus it
MUST return either USE_PPK_INT or USE_PPK notification in the
response, but not both.
Regards & Thanks！
Wei PAN (潘伟)
From: Valery Smyslov <smyslov.i...@gmail.com>
Sent: Thursday, November 14, 2024 3:34 PM
To: Panwei (William) <william.pan...@huawei.com>
Cc: ipsec@ietf.org
Subject: RE: Review of draft-ietf-ipsecme-ikev2-qr-alt-04
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).
1. 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.
1. 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
