Subject: RE: Requirements for IKEv2 implementations

From: Gregory Lebovitz <[email-masked]>
Date: Tue, 29 Apr 2003 16:20:27 -0700

...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:[email-masked]]
> Sent: Saturday, April 26, 2003 4:21 PM
> To: [email-masked]
> 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
>

---

From: Michael Richardson <[email-masked]>
Date: Tue, 29 Apr 2003 22:17:25 -0400

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Gregory" == Gregory Lebovitz <[email-masked]> writes:
    Gregory> PKI vendors. They have abandoned the application as a focus for their
    Gregory> development, marketing and sales. At an absolute minimum, PSS is
    Gregory> a MUST. 

  Why can't we make self-signed PKIX certificates a MUST?
  {This is a compromise for me. I prefer to make raw RSA keys a MUST}

  (sure, you can use a CA if you want, but that's not the interop-MUST)

  Why do we have to be dependant upon the PKI vendors?  At least they have
begun to honest about dropping the ball on this.

]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [

---

From: Paul Hoffman / VPNC <[email-masked]>
Date: Tue, 29 Apr 2003 21:00:21 -0700

>   Why can't we make self-signed PKIX certificates a MUST?

Because we are only supposed to be discussing things that have 
already been agreed to in the WG. You have brought this up many times 
and gotten virtually no support for it. Nothing in IKEv2 prohibits 
it, but there was not enough support to make it even a SHOULD, much 
less a MUST.

--Paul Hoffman, Director
--VPN Consortium