RE: Requirements for IKEv2 implementations

[Russ Housley <housley@vigilsec.com>]

Greg:

I question the PSS as the mandatory to implement.  While I am for an 
advocate for this algorithm, I do not think that it is widely deployed 
today.  I think that RSA PKCS#1 v1.5 is a more appropriate signature 
algorithm for MUST.  RSA PSS is the up and coming signature algorithm, and 
as such I think that SHOULD is the way to go.

Russ

At 04:20 PM 4/29/2003 -0700, Gregory Lebovitz wrote:
>...Interesting silence to this post...
>
>MY WG and Security Area member perspective:
>Certificates are good security and we should try as much as we can to help
>implementations adopt them. Any worthwhile IKEv1 implementation today can
>handle certs. IKEv2 should be no different.
>
>My NetScreen employee perspective:
>Our implementations do both today, so its no big deal if certs are required.
>
>Market observer perspective:
>PKI has been a royal pain for many interested in IPsec VPNs. Just ask the
>PKI vendors. They have abandoned the application as a focus for their
>development, marketing and sales. At an absolute minimum, PSS is a MUST.
>
>Gregory.
>
> > -----Original Message-----
> > From: Paul Hoffman / VPNC [mailto:paul.hoffman@vpnc.org]
> > Sent: Saturday, April 26, 2003 4:21 PM
> > To: ipsec@lists.tislabs.com
> > Subject: Requirements for IKEv2 implementations
> >
> >
> > Greetings again. The -05 draft of IKEv2 introduced the
> > following requirements:
> >
> >     For an implementation to be called conforming to this
> > specification,
> >     it MUST be possible to configure it to accept the following:
> >
> >     PKIX Certificates containing and signed by RSA keys of
> > size 1024 or
> >     2048 bits, where the ID passed is any of ID_KEY_ID, ID_FQDN,
> >     ID_RFC822_ADDR, or ID_DER_ASN1_DN.
> >
> >     Shared key authentication where the ID passes is any of ID_KEY_ID,
> >     ID_FQDN, or ID_RFC822_ADDR.
> >
> >     Authentication where the responder authenticates using PKIX
> >     Certificates and the initiator authenticates using shared key
> >     authentication.
> >
> > I don't remember seeing this discussed in the WG before now.
> >
> > There are many reasons why an implementation might not want to
> > support PKIX certificates, including the fact that many vendors find
> > that PKIX is too complicated to support securely. In some security
> > environments, other forms of public key infrastructures are more
> > appropriate for some security uses. And, of course, for systems that
> > have the ability to create and distribute good shared secrets, PKIX
> > support is just dangerous bloat.
> >
> > The minimum that is needed for interoperability is shared secrets.
> > The document already has requirements for handling large shared
> > secrets, so we don't need to worry about limitations that reduce to
> > passwords. Requiring both shared secrets *and* PKIX-specific public
> > key support does not help interoperability, and because of the nature
> > of PKIX, hurts it significantly. We only need to mandate one or the
> > other, and given the ugly reality of PKIX, it should only be
> > sufficiently long shared secrets.
> >
> > --Paul Hoffman, Director
> > --VPN Consortium
> >