{I've intentionally broken the thread, and I'm restarting the discussion.
Please forgive the length}Alan DeKok <[email protected]> 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 protected] http://www.sandelman.ca/ | ruby on rails [ -- Michael Richardson <[email protected]>, Sandelman Software Works -= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ Emu mailing list [email protected] https://www.ietf.org/mailman/listinfo/emu
