Subject: RE: [Ipsec] Rekeying IKE_SAs with the CREATE_CHILD_SA exhange

From: [email-masked]
Date: Fri, 28 Oct 2005 16:43:53 +0300

Tero Kivinen:
> I do not think we can or will change the IKEv2 draft now, but we can
> add to the clarification document a text saying "this feature is not
> supposed to be used, no need to implement this". You can add text
> there saying, that you still think it is techincally allowed by the
> IKEv2 draft, but as it is useless to do IKE SA rekey without
> diffie-hellman, nobody should implement that feature. 

Here's my proposal for text:

  There has been some confusion whether doing a new Diffie-Hellman
  exchange is mandatory when the IKE_SA is rekeyed.

  It seems that this case is allowed by the current IKEv2
  specification.  Section 2.18 shows the Diffie-Hellman term (g^ir) in
  brackets, and the change history appendix mentions this as one
  change between draft versions -00 and -01.  Section 3.3.3 does not
  contradict this when it says that including the D-H transform is
  mandatory: although including the transform is mandatory, it can
  contain the value "NONE".

  However, having the option to skip the Diffie-Hellman exchange
  when rekeying the IKE_SA does not add useful functionality to the
  protocol.  The main purpose of rekeying the IKE_SA is to ensure that
  the compromise of old keying material does not provide information
  about the current keys, or vice versa.  This requires performing the
  Diffie-Hellman exchange when rekeying.  Furthermore, it is likely
  that this option would have been removed from the protocol as
  unnecessary complexity had it been discussed earlier.

  Given this, we recommend that implementations should have a
  hard-coded policy that requires performing a new Diffie-Hellman
  exchange when rekeying the IKE_SA.  In other words, the initiator
  should not propose the value "NONE" for the D-H transform, and the
  responder should not accept such a proposal.  This policy also 
  implies that a succesful exchange rekeying the IKE_SA always 
  includes the KEi/KEr payloads.

Best regards,
Pasi

_______________________________________________
Ipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipsec

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 28 Oct 2005 16:51:47 +0300

>   includes the KEi/KEr payloads.

Looks good for me. 
-- 
[email-masked]