Hi Panos,
thank you for your revew.
Hi Valery,
I reviewed draft-ietf-ipsecme-ikev2-qr-alt-04 of the draft and below is some
feedback:
One comment is that I prefer
SKEYSEED' = prf+ (PPK, SK_d)
{SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr}
= prf+ (SKEYSEED', Ni | Nr | SPIi | SPIr )
over
SKEYSEED(n) = prf(SK_d(n-1), SK(n) | Ni | Nr)
{SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr}
= prf+ (SKEYSEED', Ni | Nr | SPIi | SPIr )
where SK(n)=PPK
I can't think of a way to exploit it, but the PPK could be a secret that did
not come from a key exchange, so it may be distinguishable from random.
Stirring the PPK in SKEYSEED matches the spirit for RFC8784 and does not
need the RFC9370 implementation to have access to the PPK. All secrets in
RFC9370 come from a key agreement, not from a static config.
More importantly, SKEYSEED' = prf+ (PPK, SK_d) matches a Key Based KDF as
per SP800-108 where K is the PPK and SKd_is the input to the PRF plus the
counter. So, it aligns well for key based key derivation in counter mode as
specified in SP 800-108. I would suggest to introduce some context unique to
the exchange, maybe Ni | Nr or the SPIs but that is not mandatory.
Nits / suggestions:
- s/storing VPN communications today and decrypting it later/storing VPN
communications today and decrypting them later/
- s/before the IKE SA is expired/before the IKE SA expires/
- s/and for rekeys operations/and for rekey operations/
- s/modifications to core IKEv2 protocol, that contradicted to one of the
goals to minimize such changes/modifications to core IKEv2 protocol. The
goal was to minimize such changes./
I changed to "One of the goals was." (I presume there were several
goals, no?)
- s/(and [I-D.ietf-ipsecme-g-ikev2] specifies how to do this)/ (as specified
in [I-D.ietf-ipsecme-g-ikev2])/
Oops. This para is a bit out-of-date, since it was written before
key wrapping was added to G-IKEv2. I updated the whole para to match the
current situation:
However, in some situations it is desirable to have this protection
for IKE SA from the very beginning, when an initial IKE SA is
created. An example of such situation is Group Key Management
protocol using IKEv2, defined in [I-D.ietf-ipsecme-g-ikev2]. In this
protocol group policy and session keys are transferred from Group
Controller/Key Server (GCKS) to Group Members (GM) immediately once
an initial IKE SA is created. While session keys are additionally
protected with a key derived from SK_d (and thus are immune to
quantum computers if PPKs [RFC8784] are employed), the other
sensitive data, including group policy, is not.
- s/Another issue with use of PPKs/Another issue with using PPKs/
- s/MUST ignore any data/MUST ignore any data in the notification/
- s/negotiation of using PPKs in the IKE_AUTH exchange/optional PPK
negotiation in the IKE_AUTH exchange/
Hmm. I believe the proposed change is wrong. It sounds to me that
the negotiation takes place in IKE_AUTH,
while the original meaning was that we negotiate use of PPKs in
IKE_AUTH (the negotiation still takes place in IKE_SA_INIT).
If the current text is confusing, then perhaps:
- s/negotiation of using PPKs in the IKE_AUTH exchange/ negotiation of using
PPKs as specified in [RFC8784]/
- s/ 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 / both the use of PPKs in IKE_AUTH
[RFC8784] and in IKE_INTERMEDIATE MAY include both the USE_PPK_INT and the
USE_PPK notifications if configured to do so./
- s/ specifications have to choose one to use/ specifications has to choose
one to use/
- I would not repeat the PPK_IDENTITY_KEY notification in Figure 1. I would
just reference it from RFC8784 and briefly mention the two fields it
includes.
This notification is introduced in this draft, RFC8784 used the
PPK_IDENTITY notification (w/o confirmation), which is also used in this
draft.
I think that it is better to keep the full specification for the
new notification.
- The combinations of optional or mandatory PPK at the end of section 3.1
would be summarized with a table like Table 1 in RFC8784. The would be more
clear for implementers like that.
OK, I see your point. I'll think a bit more how to proceed better
with this.
Thank you, I made all the changes in my local copy (waiting for
more reviews).
Regards,
Valery.
Rgs,
Panos
_______________________________________________
IPsec mailing list -- ipsec@ietf.org
To unsubscribe send an email to ipsec-le...@ietf.org
