[PATCH] OpenSSL: Accept certificates marked for both server and client use

[Anders Kaseorg]

On 02/15/2014 02:48 AM, Jouni Malinen wrote:
> On Sat, Feb 15, 2014 at 12:21:32AM -0500, Anders Kaseorg wrote:
>> Commit 51e3eafb68e15e78e98ca955704be8a6c3a7b304 was too strict in
>> forbidding certificates marked for client use.  For example, this
>> broke the MIT SECURE wireless network.  The extended key usage is a
>> _list_ of allowed uses, and rather than checking that client use is
>> not in the list, we should check that server use is in the list.
>
> This is unfortunate.. This check was added based on an explicit
> specification requirement on the server certificate being rejected if
> it contains id-kp-clientAuth and as such, that commit was actually
> following that requirement on purpose in the way that would trigger
> based on any entry matching.

I?m not seeing that specification requirement.  I looked at EAP-TLS (RFC 
5216):

    Implementations SHOULD use the Extended Key
    Usage (see Section 4.2.1.13 of [RFC3280]) extension and ensure that
    at least one of the following is true:

    1) The certificate issuer included no Extended Key Usage identifiers
       in the certificate.
    2) The issuer included the anyExtendedKeyUsage identifier in the
       certificate (see Section 4.2.1.13 of [RFC3280]).
    3) The issuer included the id-kp-serverAuth identifier in the
       certificate (see Section 4.2.1.13 [RFC3280]).

and EAP-TTLS (RFC 5281):

    Clients and servers should implement policies related to the Extended
    Key Usage (EKU) extension [RFC5280] of certificates it receives, to
    ensure that the other party's certificate usage conforms to the
    certificate's purpose.  Typically, a client EKU, when present, would
    be expected to include id-kp-clientAuth; a server EKU, when present,
    would be expected to include id-kp-serverAuth.  Note that absence of
    the EKU extension or a value of anyExtendedKeyUsage implies absence
    of constraint on the certificate's purpose.

and the specification of id-ce-extKeyUsage itself (RFC 5280):

    If the extension is present, then the certificate MUST only be used
    for one of the purposes indicated.  If multiple purposes are
    indicated the application need not recognize all purposes indicated,
    as long as the intended purpose is present.  Certificate using
    applications MAY require that the extended key usage extension be
    present and that a particular purpose be indicated in order for the
    certificate to be acceptable to that application.

    If a CA includes extended key usages to satisfy such applications,
    but does not wish to restrict usages of the key, the CA can include
    the special KeyPurposeId anyExtendedKeyUsage in addition to the
    particular key purposes required by the applications.  Conforming CAs
    SHOULD NOT mark this extension as critical if the anyExtendedKeyUsage
    KeyPurposeId is present.  Applications that require the presence of a
    particular purpose MAY reject certificates that include the
    anyExtendedKeyUsage OID but not the particular OID expected for the
    application.

This is all about requiring certain key usage values to be included; 
there?s nothing about requiring other values to be excluded.

Admittedly, I should fix the patch to accept anyExtendedKeyUsage 
(XKU_ANYEKU) as well.

> I understand the view that this should not break (reasonably) deployed
> existing networks and this may require some reconsideration. However, I
> don't think that this change to require id-kp-serverAuth to be present
> would be good either since it would likely break even more use cases. It
> might be more reasonable to reject the server based on id-kp-clientAuth
> being present without id-kp-serverAuth.

We don?t reject if the EKU extension is missing entirely, and my patch 
doesn?t change that.  Are you worried about certificates that explicitly 
include an EKU extension listing none of id-kp-clientAuth, 
id-kp-serverAuth, or anyExtendedKeyUsage?

> Would it be possible to get the MIT SECURE server certificate that hits
> this new constraint on id-kp-clientAuth being present? This would be
> useful for further discussion on possible spec changes/clarifications.

Can I extract it from wpa_supplicant?  (I don?t have any kind of special 
access to the servers.  All that MIT provides is these fingerprints: 
http://kb.mit.edu/confluence/x/YgAwB .)

Anders