Re: [IPsec] RFC4869 bis submitted

Dan McDonald <> Wed, 11 November 2009 20:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D8B693A692A for <>; Wed, 11 Nov 2009 12:52:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.046
X-Spam-Status: No, score=-6.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id YukBG5WGHm5J for <>; Wed, 11 Nov 2009 12:52:16 -0800 (PST)
Received: from (brmea-mail-2.Sun.COM []) by (Postfix) with ESMTP id 0C13A3A684A for <>; Wed, 11 Nov 2009 12:52:16 -0800 (PST)
Received: from ([]) by (8.13.6+Sun/8.12.9) with ESMTP id nABKqehM019154; Wed, 11 Nov 2009 20:52:40 GMT
Received: from (everywhere.East.Sun.COM []) by (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nABKqeYO009521; Wed, 11 Nov 2009 15:52:40 -0500 (EST)
Received: from (localhost []) by (8.14.3+Sun/8.14.3) with ESMTP id nABKqdcb109262; Wed, 11 Nov 2009 15:52:39 -0500 (EST)
Received: (from danmcd@localhost) by (8.14.3+Sun/8.14.3/Submit) id nABKqcDL109261; Wed, 11 Nov 2009 15:52:38 -0500 (EST)
X-Authentication-Warning: danmcd set sender to using -f
Date: Wed, 11 Nov 2009 15:52:38 -0500
From: Dan McDonald <>
To: Yoav Nir <>
Message-ID: <>
References: <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
Organization: Sun Microsystems, Inc. - Solaris Networking & Security
User-Agent: Mutt/1.5.19 (2009-01-05)
Cc: "" <>, "Law, Laurie" <>
Subject: Re: [IPsec] RFC4869 bis submitted
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 11 Nov 2009 20:52:16 -0000

On Wed, Nov 11, 2009 at 10:07:31PM +0200, Yoav Nir wrote:
> While the algorithms and DH groups are subject to configuration in the UI
> and negotiation in IKE, the algorithm used to sign the certificates is
> outside the IKE implementation. You usually have a certificate that you
> need to use, and it's the CA's decision whether this is signed with RSA,
> DSA or ECDSA. There's even some ambiguity, because it's not necessarily
> true, that the public key in the certificate is for the same algorithms
> used to sign the certificate.

I strongly agree with Yoav here.

Especially given certificate operations are much rarer in IKEv2 (given their
SAs last indefinitely long), would 2048-bit RSA or 4096-bit RSA certs be
unreasonable?  I understand the cert-chain issues with weak hashes, but those
do not come directly into play during the IKE exchange.  (Imagine self-signed
certs for IKE, e.g.)

> The UI suites RFC that defined VPN-A and VPN-B did not mandate RSA or
> DSA. I don't see why 4869 or 4869-bis should. I don't think it's part of
> the algorithm configuration.

Also --> the new bis document talks about IKEv1's Phase 2 Diffie-Hellman as a
MAY without saying it.  I quote:

  Rekeying of Phase 2 (for IKEv1) or the CREATE_CHILD_SA (for IKEv2)
  MUST be supported by both parties in this suite.  The initiator of
  this exchange MAY include a new Diffie-Hellman key; if it is
  included, it MUST use the 256-bit random ECP group.  If the
  initiator of the exchange includes a Diffie-Hellman key, the
  responder MUST include a Diffie-Hellman key, and it MUST use the
  256-bit random ECP group.

Many IKEv1's have Phase 2 PFS as an on/off switch.  It would be nice if you
picked one for these (either always-on or always-off).