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

> > 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. 

We've interpreted it as follows: 1) the old IKE SA's PRF is used to 
produce SKEYSEED, but 2) the new IKE SA's PRF is used to produce SK_x.

We've successfully interoperated with a number of other platforms that 
seem to have made the same interpretation.

Scott Moonen (smoonen@us.ibm.com)
z/OS Communications Server TCP/IP Development
http://www.linkedin.com/in/smoonen

From:
Tero Kivinen <kivinen@iki.fi>
To:
Paul Hoffman <paul.hoffman@vpnc.org>
Cc:
IPsecme WG <ipsec@ietf.org>
Date:
11/24/2009 08:55 AM
Subject:
[IPsec]  #121: Rekeying IKE SAs: KEr errors and PRF question

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. 
-- 
kivinen@iki.fi
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec