Subject: RE: Question about 3280bis keyUsage and extKeyUsage consistency

From: "Manger, James H" <[email-masked]>
Date: Thu, 2 Jun 2005 10:33:29 +1000

The id-kp-clientAuth extended key usage indicates that a public key can be used for "TLS WWW client authentication" [RFC 3280, page 41], ie https connections using mutual authentication.  This is not the same purpose as an IPSec VPN connection.

Some extended key usage OIDs where defined for IPSec, but later deprecated.

Theoretically, a PKIX-compliant IPSec system MUST recognize keyUsage & extendedKeyUsage extensions [RFC 3280, 4.2, page 25].  An IPSec system should only reject a certificate based on the keyUsage extension if:
* the extension is present; and
* the digitalSignature bit is not set;
Any other combination should be acceptable (eg no ku, ku with dig.Sig & nonRep., ku with just dig.Sig., ku with every bit set, ...).
An IPSec system should only reject a certificate based on the extendedKeyUsage extension if:
* the extension is present; and
* doesn't contain anyExtendedKeyUsage or any of the deprecated IPSec OIDs.
Any other combination should be acceptable (eg no eku, eku with any.EKU. & id-kp-codeSigning, ...).

If I was writing IPSec software I would probably make the list of acceptable extendedKeyUsage OIDs easily configurable so things such as id-kp-clientAuth could be added for interoperability even though it is not strictly correct.

P.S. I am not an expert on IPSec or the vagaries of various IPSec products.

----- -----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Eric Grenier (egrenier)
Sent: Thursday, 2 June 2005 5:04 AM
To: [email-masked]
Subject: Question about 3280bis keyUsage and extKeyUsage consistency

...
The follow-up question...  In a situation where an IPSec VPN client
application uses end entity certificates for user authentication
purposes to a head-end device.  Which combinations of keyUsage and
extKeyUsage would be most correct?  My interpretation of the draft
suggests a keyUsage of digitalSignature and nonRepudiation as minimum
requirements along with an optional extKeyUsage of clientAuth.

An issue has arisen where a cert does not have the nonRepudiation bit
asserted but it does have digitalSignature and clientAuth.  Given that
the nature of IPSec VPNs provides a non-repudiation service is requiring
the nonRepudiation bit to be set reasonable even if the cert has an
extKeyUsage of clientAuth?

Appreciate any insight,

---

From: [email-masked] (Peter Gutmann)
Date: Thu, 02 Jun 2005 19:58:34 +1200

"Manger, James H" <[email-masked]> writes:

>Theoretically, a PKIX-compliant IPSec system MUST recognize keyUsage &
>extendedKeyUsage extensions

The last time I looked at it (some years ago), cert-handling in IPsec
implementations ranged from almost nonexistant through to to poor (for example
they would accept any sort of roughly certificate-shaped object provided it
had the exact fields they wanted (for example an FQDN as the CN) set up in the
exact way they expected them).  This may have improved a bit since then.
Paul, any comments?

Peter.