Re: [IPsec] RFC4869 bis submitted

[Dan McDonald <[e-mail]>]

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).

Dan