When checking whether this document is ready for WGLC I did quick
review of it. Here are my comments:
----------------------------------------------------------------------
1. Introduction
...
[RFC8784] defines an IKEv2 extension for protecting
today's IPsec traffic against future quantum computers.
When referencing to numbers always use the "name" of the document and
only add RFC number as a reference. This will help readers to read the
document, when they do not need to keep mapping from RFC number to
name of the document in their head.
I.e., change to:
Mixing PPKs in the IKEv2 for post-quantum security [RFC8784]
defines an IKEv2 extension for protecting today's IPsec traffic
against future quantum computers.
--
1. Introduction
At the time
this extension was being developed, it was a consensus in the IPSECME
WG that only IPsec traffic needs to have such a protection. It was
believed that no sensitive information is transferred over IKE SA and
extending the protection to also cover IKE SA traffic would require
serious modifications to core IKEv2 protocol, that contradicted to
one of the goals to minimize such changes.
This is not really correct. At the time it was seen that doing IKEv2
rekey immediately after IKE SA is created will solve this problem and
it is already standardized how it can be done, so there was no need to
make special case for those users who happen to use IKEv2 sending
their propriatery data that needs protection.
I still think adding special mode for those rare use cases will just
cause more problems than what it solves. If the users who required
this would simply have added few lines to their code to use childless
initial SA (RFC6023) and then immediately trigger standard IKE SA
rekey they could have been protected since PPK rfc was published.
More correct way of saying this would be:
At the time of this extension was developed it was a consensus that
doing the IKE SA rekey immediately after IKE SA is created would
provide protection for the IKE SA itself and solve the situations
where sensitive information would be transferred over IKE SA. It was
considered that special protocol just for that was not needed, as
there was already existing standard way to achieve same result.
Now, when we already have IKE_INTERMEDIATE that means we do not need
another special exchange, and can use it, so making this method now is
easier.
--
Since [RFC8784] was written, a new IKE_INTERMEDIATE exchange for
IKEv2 was defined in [RFC9242]. While the primary motivation for
developing this exchange was to allow multiple key exchanges to be
used in IKEv2 (which is defined in [RFC9370]), the IKE_INTERMEDIATE
exchange itself can be used for other purposes too.
Expand the names of the RFCs in this paragraph too.
--
This specification makes use of the IKE_INTERMEDIATE exchange to
define an alternative approach to [RFC8784], which allows getting
protection against quantum computers for initial IKE SA.
I do not think this is alternative approach to the RFC (which could be
IEEE specification :-), it is alternative approach protocol described
in that RFC, so saying "alternative approach to the mixing PPK to the
IKEv2".
--
Another issue with [RFC8784] is that it assumes that PPKs are static
entities, which are changed very infrequently. For this reason PPKs
are only used once - when an initial IKE SA is established. This
restriction makes it difficult to use [RFC8784] when PPKs are changed
relatively frequently, for example as a result of Quantum Key
Distribution (QKD). If a fresh PPK becomes available before the IKE
SA is expired, there is no way to use it except for deleting this IKE
SA and re-creating a new once from scratch using the fresh PPK.
I think it would be good idea to define how to describe the "Mixing
PPKs in the IKEv2 for post-quantum security [RFC8784]" in this
document, just using [RFC8784] is not a good way to do that. Perhaps
using something like "the original PPK approach" or similar would be
better.
Change most use of RFC8784 to that or add the name before the RFC
reference. Also change "[RFC7296]" to "IKEv2 [RFC7296]".
--
3.1. Creating Initial IKE SA
* PPK_ID (variable) -- PPK_ID as defined in Section 5.1 of
[RFC8784].
I assume the receiver will know the length of the PPK_ID by knowing
that PPK Confirmation is fixed length of 8 octets? Perhaps this should
be stated here.
--
3.1. Creating Initial IKE SA
The PPK_IDENTITY_KEY is a Status Type IKEv2 notification. Its Notify
Why do we need a new status notification, why can't we used the
PPK_IDENTITY notification have already defined in Mixing PPK in the
IKEv2 for Post-quantum Security [RFC8784]?
Instead of having new status type, we could simply define new PPK_ID
format, which would include the PPK Confirmation. I.e., define
PPK_ID_OPAQUE_WITH_CONFIRMATION (3) and define its format to be
exactly as PPK_ID_OPAQUE except the last 8 octets are PPK Confirmation
field as described in Figure 1.
This could also be defined so that it has internal format specifying
the length of the confirmation field, and then confirmation field, and
the the ID data.
This would allow using that PPK_ID format also with old PPK method.
--
3.1.1. Computing IKE SA Keys
This section computes keys differently from the Multiple Key Exchanges
in the IKEv2 [RFC9370], which uses:
SKEYSEED(n) = prf(SK_d(n-1), SK(n) | Ni | Nr)
Why does this use different method of generating the keys than
multiple key exchanges? We did have some cryptographers checking the
one in Multiple Key Exchanges so perhaps reusing the same would be
better. In this case the PPK can be assumed to be shared secret
between devices, i.e., SK(n).
--
3.2. Using PPKs in the CREATE_CHILD_SA Exchange
Can the implemenation try use N(PPK_IDENTITY_KEY, PPK_ID_1) in child
exchange even if the initial IKE SA was created using old PPK method,
or if no PPK method was used at all when creating initial IKE SA?
Those are status Notify payloads, so they will be ignored by receiver
if it does not support them, or does not want to use them, and if it
resposes with PPK_IDENTITY notify, then initiator will know that it
supported PPK and wanted to use it in the this child sa exchange.
This would allow using PPK in specific Child SAs only (i.e., you could
use non PPK in most SAs but some of the child SAs might still use it).
It would also allow upgrading your IKEv2 SA from non PPK to PPK
enabled one, by rekeying IKEv2 SA with PPK_IDENTITY notifies.
--
Appendix A. Comparison this Specification with RFC8784
The main disadvantage of the approach defined in this document is
that it requires an additional round trip (the IKE_INTERMEDIATE
exchange) to set up IKE SA. However, if the IKE_INTERMEDIATE
exchange has to be used for some other purposes in any case, then PPK
stuff can be piggybacked with other payloads, thus eliminating this
penalty.
This is not really true, as if using old PPK method and user wants to
protect IKE v2 SA it would need to do, IKE_SA_INIT, IKE_AUTH, and
CREATE_CHILD_SA (to rekey IKE SA), and now it uses IKE_SA_INIT,
IKE_INTERMEDIATE and IKE_AUTH, so the number of round trips is same
for same protection.
Another difference is that this will provide PPK protection for IDi
and IDr, and CERT and CERTREQ payloads, which is not provided by the
old PPK method, even if rekeying is used.
Also this method needs to pick PPKs without the help of IDi and IDr,
as they are not available when picking PPK, but as initiator needs to
pick PPK in old method without help of IDr and responder only has one
to pick from the difference is not big...
--
kivi...@iki.fi
_______________________________________________
IPsec mailing list -- ipsec@ietf.org
To unsubscribe send an email to ipsec-le...@ietf.org
