Paul Hoffman writes:
> We earlier agreed in issue #50 to make the KEr in Section 1.3.2
> (Rekeying IKE SAs with the CREATE_CHILD_SA Exchange) mandatory:
> <-- HDR, SK {SA, Nr, KEr}
> Note that this is not in the current draft, but will be in the next one.
>
> So, what happens if the responder does not include a KEr, following
> the syntax in RFC 4306? Does the process revert back to using only
> the SK_d and the new nonces, or does the responder reject the
> request and indicate its preferred DH group in the
> INVALID_KE_PAYLOAD notification payload (section 1.3)? The latter
> seems much more likely, given the text in 2.18. If so, we should say
> so explicitly.
Note, that this can only happen if initiator allowed responder to not
give KEr. Initiator tells the responder whether it requires
Diffie-Hellman by listing Diffie-Hellman groups in its SA payload. If
it does not include group 0 (NONE) then responder does not have option
to send KEr (both for RFC4306 and IKEv2bis implementations).
RFC4306 implementations are allowed to include the Diffie-Hellman
group 0 (NONE), but IKEv2bis implementations are not allowed to
include it anymore.
This means that if RFC4306 implementation talks as initiator to the
IKEv2bis responder implementation and RFC4306 implementation selects
Diffie-Hellman group 0, and does not include KEi then IKEv2bis
implementation will return INVALID_KE_PAYLOAD and request RFC4306
implementation to select some other group (provided the RFC4306
implementation listed any acceptable group in its SA payload). If they
cannot find group which is acceptable for both then the negotiation
will fail with NO_PROPOSAL_CHOSEN.
On the other hand if IKEv2bis implementation talks as initiator to the
RFC4306 implementation, then IKEv2bis implementation will include KEi,
and MUST NOT include group 0 (NONE) in its SA payload, thus RFC4306
implementation is not allowed to select group 0, meaning it must
return proper KEr, or NO_PROPOSAL_CHOSEN if none of the groups were
acceptable (or INVALID_KE_PAYLOAD if group selected by KEi was not
acceptable, but some other group in SA payload is).
This means that if either end is IKEv2bis implementation, there cannot
be situation where KEr is ignored, and where we would not have g^ir
(new) for SKEYSEED calculation.
I do not think we need extra text for this, as if implementors follow
the currect text in section 2.18 which says IKEv2bis implementations
MUST NOT propose the value "NONE, and MUST NOT accept such proposal,
then there is no problem.
> Section 2.18 also states that in the case of the old and new IKE SA
> selecting different PRFs, that the rekeying exchange (for SKEYSEED)
> is done using the *old* IKE SA's PRF. What happens after that? The
> end of section 2.18 says that SK_d, etc are computed from SKEYSEED
> as specified in section 2.14. If the PRF changed, which PRF is used
> for the prf+ calculations, the old PRF or the new PRF?
I would interpret "because the rekeying exchange belongs to the old
IKE SA, it is the old IKE SA's PRF that is used", to cover also the
SK_d, SK_ai, etc generation and also prf+ uses. First thing that uses
new PRF, is when new IKE SA is used to generate KEYMAT, or SKEYSEED
for next IKE SA rekey. But I agree this is not very clear, and could
be clarified.
--
kivi...@iki.fi
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
