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
On Fri, Jan 17, 2020 at 05:19:39PM -0500, Michael Richardson wrote:
>
> {I've intentionally broken the thread, and I'm restarting the discussion.
> Please forgive the length}
>
> Alan DeKok 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 only IP addresses, and it currently makes no
>statement about ULA 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
