Subject: [Emu] Using public CA infrastructure for autonomic bootstrapping over EAP.

From: Michael Richardson <[email-masked]>
Date: Fri, 17 Jan 2020 17:19:39 -0500

{I've intentionally broken the thread, and I'm restarting the discussion.
Please forgive the length}

Alan DeKok <[email-masked]> wrote:
    >> Certainly, some of the excitement for ACME/Letsencrypt with DNS-01 challenge
    >> is that it makes it easy to get a certificate for a non-HTTP thing.
    >>
    >> I think we need to fix the lawyers, not the protocol.

    > That is likely the best approach.  At this point, use of
    > id-kp-serverAuth is wide-spread *outside* of HTTP.  EAP / RADIUS is not
    > unique in it's mis-use of that OID.

I went back to your message at:
  https://mailarchive.ietf.org/arch/msg/spasm/S4tO5yE_HP9CC6qd8WudY9Ln3oM

to be sure what the state of the art is today:
}  a) the current practice in TLS-based EAP methods is to use certificates with
}     "id-kp-serverAuth" OID set for Extended Key Usage.
}  b) many supplicants check for this OID, and refuse to perform authentication
}     if it is missing
}  c) supplicants do not check DNS names or any other field in the certificates
}  d) as a result of this lack of verification, supplicants ship with all known
}     CAs disabled for TLS-based EAP methods"

[c] is a problem that we partly want to fix.
[a] LetsEncrypt and other ACME mechanism technically work to get certificates
    from public CAs that can be used for this.

These certificates can, and *ARE* being used for SMTP, XMPP, as well as HTTPS.
Using these certificates for things other than HTTPS might violate the CSP of
the CAs involved, one would have to read the relevant CSPs.
At least one CA is using a certificate that would appear to be a "stock"
HTTPS certificate on an SMTP server.
I know dozens of places that have wildcard certificates (which all bind to
the same private key, which I really rather hate) which are then used for all
manner of things.
I think I've seen certificates being advertised for use in email servers, but
I'd have to go back and be sure.

Let's go back to the start with goals and requirements.

0) there is nothing broken with manual provisioning of private CAs to be used
   in Enterprise-WPA (EAP-TLS, etc.) uses of EAP/802.1X.  This can continue
   as is.  The server certificate needs to have id-kp-serverAuth OID set in
   order to be trustable by comododity clients as deployed today.
   There is very little use of additional OIDs, even those some have been defined.
   Clients do not insist upon them, and *as a result*, it is technically
   possible to use certificates issued by public CAs here.

1) we have some protocols that do autonomic onboarding of devices.
   BRSKI is one such protocol. Not the first, but the most public and most
   cross-vertical one. But probably it won't be the last one!

   **BRSKI does not require that the domain owner have a public CA**

   In fact, BRSKI provides a mechanism that permit a devices to autonomically
   develop trust in a private CA via the pinned voucher artifact.
   One can proceed to do EST/RFC7030 if one wants after and get the local
   list of of private CAcerts.

   In some wired situations it is also possible to use *JUST* EST/RFC7030 for
   enrollment, if the client(pledge) is willing to trust the certificate of
   the server, such as because it comes via public trust.  I will note that
   EST uses HTTPS, and having a name from a public CA could not reasonably
   break any CSP.

   While the CAFORUM rules forbid certificates for private names
   (foobar.corp, foobar.internal), and it also forbids issuance for RFC1918
   addresses, it currently permits certificates for public names (foo.example.com), even
   if those addresses have AAAA only IP addresses, and it currently makes no
   statement about ULA AAAA addresses in public names.
   Whether this is a loophole of intention or omission, I don't know.
   (I have running code)

   There are a number of industrial uses for EST/RFC7030 where the interest
   is in validating the IDevID of the pledge in order to detect counterfeit
   products.
   It is not apparent how this (EST-only) can be done over WiFi in an
   autonomic way, and thus this is one of the places for BRSKI protocols like
   BRSKI-TEAP.  But, again BRSKI does not require a public CA/name.

2) BRSKI (-like) protocols suggest that the domain owner (the Registrar) be
   connected to a private CA to issue LDevID.  There is a desire to simplify
   this requirement in order to make use of ACME based systems to replace the
   local Registrar/CA. (see draft-friel-acme-integrations, and also
   draft-moriarty-acme-client and draft-moriarty-acme-overview )

   It is certainly the case that use of LetsEncrypt via ACME is a significant
   carrot.  For smaller operator (including residential and SOHO), there is
   SIGNIFICANT interest.

   draft-moriarty-acme-client writes:
   3.  End User Client Certificates

      A client certificate used to authenticate an end user may be used for
       mutual authentication in TLS, ***EAP-TLS***, or messaging.  The client

   (to be very very very clear: not a consensus document at this point!!!!)
   [See followup message, I don't want to distract this thread too much]

3) If the Registrar (which is probably also the EAP-TLS/EAP-TEAP
   authenticator end-point) has a certificate from a public CA, (and this is
   pinned in an RFC8366 voucher), then there become a few challenges due to a desire to:

   a) change / rekeying the public key.
      Pinning the CA+DN rather than the EE cert can solve this, at the cost
      of adding complexity to the pledge.

   b) being able to change from CA X to Y, which means that only the DN can
      be pinned. In effect, the rfc822Name!

   Note that the voucher is typically only evaluated at onboarding time.
   In an online (nonced) process, then that happens mere seconds after the
   voucher is issued, and the changes in (a) and (b) do not matter much.

   During the EST process, the pledge can get trust anchors with which to validate
   the Registrar/Authentication-Server.  The specific CA which is currently
   being used can be returned.  It matters little whether it is public or
   private.

   {I personally do not think that running a private CA is that big a deal if
   you are willing to write a hundred lines of code to manage it.  It
   certainly is a pain if you expect the operator to use openssl command line!
   (But, then I'm regularly told that my solutions are too complex for regular people)}

   The trust anchor will get used regularly to do EAP/WPA operations from the device.
   The ability to validate the certificate is not affected by the (a) change
   above.

   The problem is that as currently described, we do not say to pin the DN.
   So *ANY* name from that CA will be valid for that connection.  In the case
   of public CA, then this means that the client would connect to any network
   that has an EE from the same CA.  That's way too easy to spoof.  Hell, it
   can occur easily by non-malicious actors: just two offices or houses
   within WIFI distance.

   And as described above, there is currently no validation of the DN by
   current clients, nor is there validation of extensions.

   The (b) switch is probably, in my opinion, not tractable easily.
   RFC7030's /cacerts (section 4.1.3) returns the certificates (plural) are
   returned.  If the (b) switch could be coordinated enough in advance to
   permit normal RFC7030 renewals to get the Y trust anchor that could work.

===============

So, it seems that we ought to:
  a) suggest that EAP-TLS (and EAP-TEAP) clients should include the DN
     (rfc822Name) of the certificate that they should be talking to.

  b) we should perhaps have an OID extension in the CA certificate (trust
     anchor) that says if the CA will use the id-kp-eapOverLAN bit or not.
     (or other extensions)
     If so, then the client should insist that the resulting extension be present.
     Maybe there is another way to do this that would be easier, but this
     makes sense to me.

  c) We may want to Update RFC7030 /cacerts to say something about creating
     an expiry/retry time in the certs-only CMC Simple PKI Repsonse.
     I don't see a date in a RFC5652 Signed-Only certs-only container that
     could be used to cause pledges to get the /cacerts earlier than the
     expiry time of the CA.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Alan DeKok <[email-masked]>
Date: Fri, 17 Jan 2020 17:33:10 -0500

> }     CAs disabled for TLS-based EAP methods"

  For (d), CAs are disabled also because of protocols like EAP-TTLS with embedded PAP.  If the supplicant trusted a root CA, then it would trust any certificate signed by that CA, and expose the users clear-text password to anyone.

  Supplicants now check:

* for a named SSID
* the CA is manually enabled for that SSID
* the server certificate is known (pre-configured or downloaded and cached)

  All of those conditions have to be met before EAP is performed.

> [c] is a problem that we partly want to fix.

  Yes.

>   possible to use certificates issued by public CAs here.

  Yes.

  I've omitted BSRKI comments.  I have less to contribute there

>     (rfc822Name) of the certificate that they should be talking to.

  I'm not clear on "include".

>     Maybe there is another way to do this that would be easier, but this

  There may be other ways.  Taken to the extreme, each use-case for TLS should have its own OID.

  I don't know that there's a good solution here.

  On a related note, Stefan Winter had a proposal for a standard configuration for EAP:

https://tools.ietf.org/html/draft-winter-opsawg-eap-metadata-02

That would seem to solve all of the provisioning problem.  There are still verification problems.

  I suspect we need to clearly separate the two situations, i.e.:

1) a supplicant magically has the information it needs to authenticate.  What does that information look like?  What's in the certs?

2) a supplicant is unconfigured, how is it possible to get the supplicant to state (1) above?  Is the information available in state (1) helpful for provisioning?

  Alan DeKok.

---

From: Michael Richardson <[email-masked]>
Date: Fri, 17 Jan 2020 17:40:37 -0500

> [See followup message, I don't want to distract this thread too much]

It would also be very nice to be use LetsEncrypt for device certificates,
and draft-moriarty-acme-client speaks to some of this, but given 90-day
LetsEncrypt expiry, that won't fly. (I have running code that deals
with the factory processing)

Having an IDevID on a thing (router, appliance, home router) with a public CA
trust path means that one connect to it from a stock browser/smartphone
without error.
Yes, that implies the thing has a name (the name is in the certificate), and
that the name is resolvable by the browser, at least locally.
That's possible, particularly given IPv6 ULA AAAA RR for home routers,
but also using local DNS mechanisms. (again, I have running code)

It is, sadly, not feasible to buy certificates from a public CA, as the
current CAFORUM 2yr (25 month) limit won't work for most supply chain
logistics.  The CAFORUM has been discussing 13 month limits, with noises
for even shorter terms.  I read the lists for awhile, but I don't know if
13 months went to a vote yet.

Okay, I thought: no problem, just get an Enterprise sub-CA with a
nameconstraint limiting issued certificates. That was a thing at one
point.   Surely, I can then control the expiry dates myself?
There was even a CVE about windows-server not validating the name constrained
correctly a decade ago.

I did persue this anyway about a year ago with a few CAs. Only one of them
actually could spell "Enterprise CA"!! It's just not offered, as a result,
I think of the newer CAFORUM rules.  I am sad, but I understand why it
happened.

yes, Enterprise CAs were in order O($10K-USD),
but spread over 100K+ product instances, that's not a huge cost.

I was offered a hosted sub-CA. If I wanted it to have a public trust
anchor, the price was $450/certificate. (Yes, I got the decimal place
right. I did ask for confirmation here twice. I was expecting $4.50/certificate,
with some minimal commitment, given that it would have a PathNameConstraint).
That's for a 25 month certificate, which I thought, maybe is long enough for
the step after proof-of-concept.

With BRSKI ANIMA/ACP, selling into Operators and Enterprises, using a
private CA for the IDevID is just barely acceptable, as those operators
can just probably configure new trust anchors into the Registrar.  Maybe.
With good enough software.  Maybe we can come up with some additional
mechanism, maybe involving SRV and/or TLSA records.

This probably won't fly into the residential or SOHO space, thus the interest
in either having a public trust anchor for IDevID signing, or... CREATING A
NEW SET OF semi-public CAs.    Honestly, this project would be simple
compared to what I've seen of the US Federal cross-CA system :-)

I wrote two documents in December which I'd appreciate feedback on:
1) Operational Considerations for Manufacturer Authorized Signing Authority
   draft-richardson-anima-masa-considerations-01

   This is about the private CA used to sign the IDevID.

2) Operational Considerations for BRSKI Registrar
   draft-richardson-anima-registrar-considerations-01
   This is about the private CA that the operator is expected to run.

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 17 Jan 2020 19:47:32 -0800

Hi Michael,

You mention in a couple places that EAP server certificate should be
identifying an rfc822Name DN, and I think I'm confused about what you mean.
(I suspect I'm seeing "rfc822Name" and jumping to what ACP does, which is
wrong.)  Could you walk through an example of what that would look like to
help un-confuse me?

Thanks,

Ben

> _______________________________________________
> Spasm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spasm