Re: [IPsec] Question about IKEv1 and ECDSA

"Dan Harkins" <> Wed, 28 November 2012 19:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 127E021F8593 for <>; Wed, 28 Nov 2012 11:56:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.265
X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id OF7AkBgC5Yyn for <>; Wed, 28 Nov 2012 11:56:48 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 99AC821F8590 for <>; Wed, 28 Nov 2012 11:56:48 -0800 (PST)
Received: from (localhost []) by (Postfix) with ESMTP id 93F031022400A; Wed, 28 Nov 2012 11:56:47 -0800 (PST)
Received: from (SquirrelMail authenticated user by with HTTP; Wed, 28 Nov 2012 11:56:48 -0800 (PST)
Message-ID: <>
In-Reply-To: <>
References: <>
Date: Wed, 28 Nov 2012 11:56:48 -0800
From: Dan Harkins <>
To: Yoav Nir <>
User-Agent: SquirrelMail/1.4.14 [SVN]
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Cc: IPsecme WG <>
Subject: Re: [IPsec] Question about IKEv1 and ECDSA
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion of IPsec protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 28 Nov 2012 19:56:49 -0000


On Wed, November 28, 2012 12:07 am, Yoav Nir wrote:
> Hi
> I know we don't like IKEv1 questions, but RFC 4754 does mention it, so
> here goes. And sorry if this has been discussed before. I couldn't find
> it.

  What do you mean "we"? :-)

> In IKEv1 the authentication method is negotiated as an SA parameter. So
> presumably the Initiator proposes RSA signatures, ECDSA with the P-256
> curve, etc, and the Responder chooses one of them. This happens in packets
> #1 and #2.
> Later the certificate to actually present (in packets #5 and #6) is chosen
> based on a Certificate Request payload, and availability. This is
> different from IKEv2, where authentication method is implied by the
> certificates rather than negotiated.
> So two questions:
> 1. Is it impossible to have one peer authenticate with RSA while the other
> authenticates with ECDSA, or even to mix curves?  Or am I missing
> something?

  No, they both have to do ECDSA. The way that ECDSA was added to IKEv1--
make it bound to the curve-- was unfortunate. That means that you can't
really mix curves either after agreeing to do ECDSA with one particular
curve. It would have be much more useful to divorce the curve from the
willingness to do ECDSA. But oh well.

> 2. What if an IKE endpoint has >1 certificates, but the one best-suited
> for the certificate request has a different type key than the one agreed
> to in packet #2?

  Tough luck. You agreed to ECDSA with a particular curve and that's what
you go with.

> If I'm not missing something, it seems like IKEv1 is the wrong vehicle for
> the gradual introduction of ECDSA.  I'm not proposing to fix it, just
> trying to understand.

  It should work in the general case but you have pointed out some
conditions that make it somewhat suboptimal. I believe the ECDSA tiger
team has properly addressed these issues for IKEv2. Please speak up
if you disagree.