Re: [IPsec] #121: Rekeying IKE SAs: KEr errors and PRF question

[<[e-mail]>]

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