Subject: [IPsec] Question about IKEv1 and ECDSA

From: Yoav Nir <[email-masked]>
Date: Wed, 28 Nov 2012 08:07:53 +0000

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.

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

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.

Yoav

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 28 Nov 2012 07:02:19 -0800

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

This was discussed a decade ago at interop events, and the general agreement was that it is impossible to do without an extension, and no one cared to do that. (The question was actually about PlainOldDSA, not ECDSA, but the result is the same.)

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

Same.

--Paul Hoffman

---

From: "Dan Harkins" <[email-masked]>
Date: Wed, 28 Nov 2012 11:56:48 -0800 (PST)

Hello,

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.

  regards,

  Dan.