Hi Vukašin,
Hi Valery,
While updating the code logic to the latest version of the draft some questions
came up to me:
1. Assume the initiator and responder both already support RFC 8784.
If the initiator sends USE_PPK_ALT notify, and does not support
IKE_INTERMEDIATE exchange, will the initiator and responder be able to use the
alternative PPK rotation for rekeying the SA's and creating new PPK-protected
SA's?
That is, can this alternative approach be used independent of the
IKE_INTERMEDIATE exchange support?
A sentence in the draft "The initiator that supports both RFC8784 and this
specification MAY include both the USE_PPK_ALT (along with the
INTERMEDIATE_EXCHANGE_SUPPORTED) and the USE_PPK notifications if it is
configured to use either specification." makes me think the alternative
approach, thus also the PPK rotation and rekeying, must be used only if the
INTERMEDIATE exchange occurs.
2. Similarly, assume neither the initiator nor the responder support RFC 8784
and INTERMEDIATE exchange. Can they implement the alternative approach and use
it for, e.g. rekeying (and adding PPK protection to the original unprotected
IKE SA) and creating new PPK-protected SA's?
The current draft assumes that alternative use of PPK is only possible
if peers support the IKE_INTERMEDIATE exchange:
The IKE initiator which supports the IKE_INTERMEDIATE exchange and
wants to use PPK to protect initial IKE SA includes the
INTERMEDIATE_EXCHANGE_SUPPORTED notification and a notification of
type USE_PPK_ALT in the IKE_SA_INIT request.
Thus, peers may only negotiate support for the alternative approach if
they also support IKE_INTERMEDIATE.
However, the situation with the CREATE_CHILD_SA exchange is a bit
trickier.
Actually, the initiator may include PPK_IDENTITY_KEY notification in
this exchange
even if it didn’t negotiate the support for this extension in the
IKE_SA_INIT.
In this case, if the responder doesn’t support use of PPKs in
CREATE_CHILD_SA
(even if it supports use PPKS in the initial exchange) or is
configured to tie
these two cases (don’t use it in CREATE_CHILD_SA unless negotiation is
successful in IKE_SA_INIT),
then the responder will ignore this notification and the SA will be
created with no PPK.
This may also happen even if the responder supports use of PPKs in
CREATE_CHILD_SA,
but for any reason cannot use them right now, e.g. no proposed PPKs
are available.
The two situations may look unrealistic, but clarity on the issues would be
better for cleaner code logic. I suggest a sentence or two are added somewhere
(with MUST, SHOULD, etc. wording) that would clarify how implementations should
behave in the above two situations. In the case I missed something in the draft
about this, I apologize.
I think some clarification may be added, that the use of PPKs in
CREATE_CHILD_SA
is somewhat independent from initial exchanges, however, the initiator
must be prepared
to the situation, when the responder doesn’t support this
functionality or refuses to use it.
Any thoughts whether this approach is OK?
Regards,
Valery.
Thank you in advance!
Regards,
Vukašin
_______________________________________________
IPsec mailing list -- ipsec@ietf.org
To unsubscribe send an email to ipsec-le...@ietf.org
