Re: [IPsec] RFC4869 bis submitted

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

I strongly agree with Yoav and Dan on decoupling the authentication method 
from the suite.  This places an unnatural configuration burden on an IKE 
implementation.  It is proper to configure one's choice of certificate -- 
but it is not natural to configure the certificate's authentication 
algorithm independently of simply choosing the desired certificate or CA.

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

How would such an implementation handle RFC 4308?  Our own implementation 
supports sending offers with and without PFS, but it does seem odd to me 
that these RFCs would punt on the decision to use PFS.  There are valid 
reasons for either approach (CPU cost versus key independence).  I suppose 
we could create separate versions of the suites with and without PFS, but 
it's probably ok for the suites to simply be "opinionated".  I guess that 
means we'd go with PFS=on.

Scott Moonen (smoonen@us.ibm.com)
z/OS Communications Server TCP/IP Development
http://www.linkedin.com/in/smoonen

From:
Dan McDonald <danmcd@sun.com>
To:
Yoav Nir <ynir@checkpoint.com>
Cc:
"ipsec@ietf.org" <ipsec@ietf.org>, "Law, Laurie" <lelaw@tycho.ncsc.mil>
Date:
11/11/2009 03:54 PM
Subject:
Re: [IPsec] RFC4869 bis submitted

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
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec