Re: [IPsec] Question about IKEv1 and ECDSA

["Dan Harkins" <[e-mail]>]

  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.