Subject: Re: Requirements for IKEv2 implementations

From: [email-masked]
Date: Thu, 1 May 2003 18:09:34 -0400

> 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 was a long though indecisive discussion of RSA vs DSS keys and
required key sizes about six months ago. I don't believe the other issues
have been discussed.  I believe there has been expressed a consensus for
for following very ambitious goal: it must be possible to configure any two
implementations that conform to the RFC to interoperate. I have been adding
conformance requirements as people point out places where the spec allows
two implementations that include all of the MUSTs to fail to interoperate.
I'm sure we will find more in interoperability testing, but we should find
only bugs in implementations and bugs in the spec. Not legitimately
differing interpretations.

There will certainly be cases where the goal will not be met. There are
asymmetric cases where a laptop designed to connect to a corporate firewall
may not have a smarts to accept a connection from a similarly configured
laptop. And the "can be configured" language is critical. Deployments are
likely to restrict what forms of authentication they accept and what
algorithms they use. So in some sense, requiring configurability doesn't
guarantee anything. But in practice, I believe it will make a big
difference.

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

I have no particular preference here. In the early days of IKEv2, there was
no shared key authentication, so certificate based authentication was a
MUST. At first, shared key authentication was optional, but I was convinced
that because of its wide deployment in IKEv1, it also should be a MUST. I
think it would be fairly harmless to make authentication using raw RSA keys
also be a MUST, but no one made a case for it until now. I think it would
be a mistake to remove the requirement for certificate based
authentication, because it is hard, people would be tempted to leave it
out, and I believe that's where we want to end up in the long run. But it's
not my decision... what do people want?

I would have expected the issue of ID types to be more controversial. I
added the language last year attempting to respond to the issues raised by
your Revised Identity proposals.

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

As currently written, a node may identify itself by any of those four ID
types, and the other end MUST be capable of accepting any of them and using
them to find a policy (again, must be capable of being configured to accept
any of them). If this set were smaller, it would make life easier for the
parsers but less flexible in terms of allowed configurations.

      --Charlie

---

From: Paul Hoffman / VPNC <[email-masked]>
Date: Thu, 1 May 2003 15:56:57 -0700

At 6:09 PM -0400 5/1/03, [email-masked] wrote:
>I think it would
>out, and I believe that's where we want to end up in the long run.

That's all well and good, but that doesn't match the definition for 
MUST in 2119.

--Paul Hoffman, Director
--VPN Consortium

---

From: "Zimmerman, Mark" <[email-masked]>
Date: Thu, 1 May 2003 21:07:43 -0400

-----Original Message-----
From: Paul Hoffman / VPNC [mailto:[email-masked]] 
Sent: Thursday, May 01, 2003 5:06 PM
To: [email-masked]
Subject: RE: Requirements for IKEv2 implementations

At 4:20 PM -0700 4/29/03, Gregory Lebovitz wrote:
>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.

>That's what SHOULD is for. The current text says MUST.

>  Any worthwhile IKEv1 implementation today can
>handle certs.

>Sorry, but that is just plain wrong. There are many "worthwhile" 
>implementations that don't do certs. There are plenty of "worthwhile" 
>implementations that do certs wrong, such as doing things with certs 
>that the IKEv1 specs say they SHOULD NOT do.

Agreed, and as with anything it also depends on how the solution is being
implemented. ICSA Labs has 47 tested IKEv1 products using PSK that have been
certified as interoperable. None of which I would call "not" worthwhile.

As the alternative, for those that have implemented PKI, 11 products have
been tested and certified within our 1.1 Criteria program which mandates
Certificate authentication all which have been tested and certified as being
interoperable with each other. It all depends on what the customer needs,
but making PKI a MUST at this point is jumping the gun. SHOULD is
appropriate.

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

>Exactly right. But there is no reason for two MUSTs for authentication.

Again, Agreed,I feel like a red headed step-child when trying to resolve
issues with PKI vendors or even getting support on our own test bench CA's

Mark Zimmerman
IPSec Technology Program Manager
ICSA Labs

>--VPN Consortium

***********************************************************************
This message is intended only for the use of the intended recipient and
may contain information that is PRIVILEGED and/or CONFIDENTIAL.  If you
are not the intended recipient, you are hereby notified that any use,
dissemination, disclosure or copying of this communication is strictly
prohibited.  If you have received this communication in error, please
destroy all copies of this message and its attachments and notify us
immediately.
***********************************************************************