[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Requirements for IKEv2 implementations



Ooops.  So much of the message was about certificates, that was the context 
under which I expanded the PSS acronym.  Upon further reflection, it is 
obvious that Greg was not talking about a signature algorithm.

  By PSS, Greg meant "pre-shared secret."

Sorry for the noise ...

Russ

>Date: Wed, 30 Apr 2003 16:17:47 -0400
>To: Gregory Lebovitz <Gregory@netscreen.com>, "'Paul Hoffman / VPNC'" 
><paul.hoffman@vpnc.org>, ipsec@lists.tislabs.com
>From: Russ Housley <housley@vigilsec.com>
>Subject: RE: Requirements for IKEv2 implementations
>
>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
>> >