Subject: [Anima] Registrar certificate EKU bits

From: Michael Richardson <[email-masked]>
Date: Tue, 20 Jul 2021 16:40:35 -0400

When debugging another issue, I found that my test Registrar had stopped
being able to connect to my MASA.  Some upgrades to Openssl, Apache meant
that one of those two decided the Extended Key Usage for the client
certificates had better be right.

What I found:
  1) If there is no EKU, then it's all okay.
  2) If there is an EKU, and it contains only cmcRA, then it is rejected.
  3) If I add "clientAuth" EKU, then it works.

I don't know if this is enforced in Apache (via some callback), or within OpenSSL.
There are nothing logged in Apache, so I think it's autocratic actions by
a minor patch level of OpenSSL, and Apache probably needs to override the
behaviour.  Or, it could be Apache's certificate verify callback.
The lack of logging on the server is a serious problem.

What does occur is that there is a TLS level response, an SSL Alert, saying
that the certificate was rejected.

Perhaps someone else will find this email useful.
Mostly, it convinces me to never set any EKU bits.
I guess, I need to set serverAuth too, now that I think about it.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Alan DeKok <[email-masked]>
Date: Tue, 20 Jul 2021 16:54:10 -0400

> I don't know if this is enforced in Apache (via some callback), or within OpenSSL.

  Having run into similar issues, I suspect a combination of both.  OpenSSL does it's own validations, and the application using OpenSSL can add more.

  For EAP, we've added our own certificate validation callbacks, largely to shut off much of the automatic behavior of OpenSSL.

  i.e. the "heavy lifting" of checking ASN.1 formats and certificate chains is up to OpenSSL.  But the validity of the contents of each cert is up to the application.

> The lack of logging on the server is a serious problem.

  That is a wide-spread issue.  We've added voluminous debug logging, which is horrible for the average user, but allows anyone *reading* it to trivially debug fairly complex issues.

> that the certificate was rejected.

  "Failed"

  Why?

  "Failed".

  <sigh>

> I guess, I need to set serverAuth too, now that I think about it.

  Yes.

  Alan DeKok.

---

From: Esko Dijk <[email-masked]>
Date: Wed, 21 Jul 2021 07:41:46 +0000

Hello all,

I have run into the same issue and decided to check the RFCs on this behaviour. Turns out, it is correct behaviour per specifications. See RFC5280 section 4.2.1.12.

If the EKU is present, it will restrict the allowed usage purposes of the certificate to only those items listed in the EKU. So, if a client needs to use such certificate for DTLS/TLS, it needs to add id-kp-clientAuth.
And if a server needs to use such certificate for DTLS/TLS it needs id-kp-serverAuth.

Consequence for a Registrar server, that MUST have id-kp-cmcRA set, is that it also needs id-kp-serverAuth set in the EKU.  Older DTLS 1.2 stacks for example may not check EKU yet in such a way (e.g. an older Scandium I used did not check) but I expect never 1.2/1.3 stacks to check EKU.

@Michael this could be worth adding to our constrained-BRSKI draft as a clarification, as it seems non-trivial. (It was to me for sure.)
And maybe also keep this for considerations for a BRSKI-bis document.

Regards
Esko

-----Original Message-----
From: Anima <[email-masked]> On Behalf Of Alan DeKok
Sent: Tuesday, July 20, 2021 22:54
To: Michael Richardson <[email-masked]>
Cc: Anima WG <[email-masked]>
Subject: Re: [Anima] Registrar certificate EKU bits

  "Failed"

  Why?

  "Failed".

  <sigh>

  Yes.

  Alan DeKok.

_______________________________________________
Anima mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/anima

---

From: Michael Richardson <[email-masked]>
Date: Mon, 26 Jul 2021 22:18:04 -0400

Esko Dijk <[email-masked]> wrote:
    > If the EKU is present, it will restrict the allowed usage purposes of
    > the certificate to only those items listed in the EKU. So, if a client
    > needs to use such certificate for DTLS/TLS, it needs to add
    > id-kp-clientAuth.

    > Consequence for a Registrar server, that MUST have id-kp-cmcRA set, is
    > that it also needs id-kp-serverAuth set in the EKU.  Older DTLS 1.2
    > stacks for example may not check EKU yet in such a way (e.g. an older
    > Scandium I used did not check) but I expect never 1.2/1.3 stacks to
    > check EKU.

    > @Michael this could be worth adding to our constrained-BRSKI draft as a
    > clarification, as it seems non-trivial. (It was to me for sure.)

So, I've opened https://github.com/anima-wg/constrained-voucher/issues/146.
I agree that we should put it constrained-voucher.

It sounds like you also think it deserves an errata.

---

From: Peter van der Stok <[email-masked]>
Date: Tue, 27 Jul 2021 10:24:41 +0200

To be quite honest:

A section describing certificate requirements (grouping them all) is 
necessary for constrained voucher and BRSKI RFC.
Suggestion: a new document?

Peter
Michael Richardson schreef op 2021-07-27 04:18:

> So, I've opened 
> https://github.com/anima-wg/constrained-voucher/issues/146.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 27 Jul 2021 10:23:29 -0400

> Suggestion: a new document?

Maybe. What does the WG think?

Existing documents that already deal with 90% of the certificate issues:
         what about draft-richardson-masa-operational-considerations and
         draft-richardson-registrar-operational-considerations?

(yes, I think one needs to be reposted)