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

Paul Hoffman <paul.hoffman@vpnc.org> Tue, 24 November 2009 00:18 UTC

Return-Path: <paul.hoffman@vpnc.org>
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F32D28C0E1 for <ipsec@core3.amsl.com>; Mon, 23 Nov 2009 16:18:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.93
X-Spam-Level:
X-Spam-Status: No, score=-5.93 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xe5PZd5pY4Ro for <ipsec@core3.amsl.com>; Mon, 23 Nov 2009 16:18:58 -0800 (PST)
Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 4E9603A67B5 for <ipsec@ietf.org>; Mon, 23 Nov 2009 16:18:58 -0800 (PST)
Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id nAO0Irme043397 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <ipsec@ietf.org>; Mon, 23 Nov 2009 17:18:53 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0
Message-Id: <p06240845c730d6c840bf@[10.20.30.158]>
Date: Mon, 23 Nov 2009 16:18:51 -0800
To: IPsecme WG <ipsec@ietf.org>
From: Paul Hoffman <paul.hoffman@vpnc.org>
Content-Type: text/plain; charset="us-ascii"
Subject: [IPsec] #121: Rekeying IKE SAs: KEr errors and PRF question
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 24 Nov 2009 00:18:59 -0000

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.

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?

--Paul Hoffman, Director
--VPN Consortium