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./
- s/(and [I-D.ietf-ipsecme-g-ikev2] specifies how to do this)/ (as specified in
[I-D.ietf-ipsecme-g-ikev2])/
- 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/
- 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.
- 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.
Rgs,
Panos
_______________________________________________
IPsec mailing list -- ipsec@ietf.org
To unsubscribe send an email to ipsec-le...@ietf.org
