Paul Hoffman wrote:
> 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?
This would happen only if the responder's SA payload has value "NONE"
for transform type 4, right?
But the text in Section 2.18 already prohibits this...
> 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.
>
> 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?
SK_* are computed from SKEYSEED using the new IKE SA's PRF.
Best regards,
Pasi
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
