[PATCH] OpenSSL: Accept certificates marked for both server and client use
andersk at MIT.EDU
Sat Feb 15 05:24:38 EST 2014
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
Implementations SHOULD use the Extended Key
Usage (see Section 18.104.22.168 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 22.214.171.124 of [RFC3280]).
3) The issuer included the id-kp-serverAuth identifier in the
certificate (see Section 126.96.36.199 [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
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:
More information about the HostAP