On Wed, Jan 15, 2020 at 11:07 PM Benjamin Kaduk <ka...@mit.edu> wrote:
> A couple things that stand out to me from having basically read the whole > thread in one go (this is not intended to be an exhaustive list of open > questions): > > It was implied but not fully clear to me, that Ryan thinks that someone so > inclined could, right now, go around trying to connect to wifi using EAP > authentication, grab a packet capture of the remote server using its > id-kp-serverAuth certificate for authenticating the TLS-over-EAP > connection, and report that certificate to its issuing CA as "misuse" > requiring prompt revocation, at least for several major CAs. It's quite > probably that I missed them as they went by, but specific links to specific > CA policy documents that would classify such certificate usage as "misuse" > (requiring revocation) would help clarify things, at least for me. > While I think people are missing the forest for the tree, here's an example CP/CPS from a CA: https://www.certsign.ro/media/document/ZytpRDNNUTFHR01Ra2MxVUx4REdQZz09/original/CPS%20OV%20SSL_v%201.10_April%202019.pdf 1.4.2 Prohibited certificate uses > Any usage of a certificate other than the usage explicitly allowed in the > CPS, is prohibited. > 1.4.1 Appropriate certificate uses > Certificates may be used in applications that satisfy at least the > following conditions: > • Manage properly the public and private keys, > • Certificates and associated public keys are used in compliance with > their declared > purpose, confirmed by CERTSIGN, > • Have built-in mechanisms of certificate status verification, > certification path creation > and validation control (signature availability, expiration date etc.), > • Provides relevant information regarding certificates and their status > for users. It's already been flagged, for the CA to fix in their next CP/CPS update ( https://bugzilla.mozilla.org/show_bug.cgi?id=1403453 ), that they're conflating requirements on Relying Party applications (i.e. those that verify certificates) and Subscriber applications (i.e. those that serve certificates). Does your RADIUS endpoint support and use OCSP stapling and disable WiFi if the certificate is expired? No? Then it's a potential violation of this CP/CPS. Now, folks might be unhappy with that, thinking certSIGN isn't a "major" CA. Here's DigiCert's CPS - https://www.digicert.com/wp-content/uploads/2019/11/DigiCert_CPS_v420.pdf . 4.9.1 states that: > DigiCert may revoke a certificate within 24 hours and will revoke a > Certificate within 5 days if one or more of the following occurs: .... > 3. The Subscriber or the cross-certified CA breached a material obligation > under the CP, this CPS, or the relevant agreement; DigiCert's Subscriber Agreement (the relevant agreement) is at https://www.digicert.com/legal-repository/Subscriber-Agreement.pdf and, in Section 2.2, makes reference to their Certificate Terms Of Use - https://www.digicert.com/legal-repository/Certificate-Terms-of-Use.pdf This Terms of Use has gems like (in Section 12) > Customer will use passwords that > are randomly generated with at least 16 characters containing uppercase > letters, lowercase letters, numbers, and symbols > to transport Private Keys. Customer will only allow Customer’s employees, > agents, and contractors to access or use Private > Keys if the employee, agent, or contractor has undergone a background > check by Customer (to the extent allowed by law) > and has training or experience in PKI and other information security > fields. And in Section 16: > Customer will only use a TLS/SSL Certificate on the servers accessible > at the domain names listed in the issued Certificate Remind me how an EAP-TLS/RADIUS server is accessible at that domain name? And if someone points their domain name to my server, would that require revocation? Or in Section 17: > DigiCert may revoke a Certificate without notice for the reasons stated in > the CPS, including if DigiCert reasonably believes > that: > .... f. the Certificate was used without authorization, outside of its intended > purpose or used to sign Suspect Code; > id-kp-serverAuth sure does seem to mean "WWW server", since RFC 5280 states: > id-kp-serverAuth OBJECT IDENTIFIER ::= { id-kp 1 } > -- TLS WWW server authentication This may seem pedantic and overbroad (OK, it definitely is), but that's the entire meta-point here. There's two parts of discussion from the thread: 1) What do extant clients do, today, in the verification of certificates used in EAP-TLS 2) What should future clients do, 'tomorrow', to make this easier to use and secure, ideally by default. Much of the answer was around #2, which is "Don't try to glom on to something existing, you need to build your own thing", as well as "Some of the answers in #1 are problematic and you should try and discourage them" In the hopes it makes it more accessible, imagine a situation where both Ben and I need gears (widgets, sprockets, take your pick). Ben needs gears that are 4cm in diameter and capable of being used in temperatures from 0-20 degrees Celsius. I need gears that are 4cm in diameter and capable of being used in temperatures from 0-30 degrees Celsius. We both get our gears from a single supplier: Cogswell's Cogs Ben has a bunch of spare gears around for my equipment, and realizes he can just use my gears in his equipment, and everything just works. Our requirements are seen as compatible. That's convenient! However, when Ben approaches Cogswell's Cogs, to sign a supply agreement, it's important that the contract doesn't say "Ben will get 100 of whatever gears Ryan gets". Instead, Ben should say "Ben will get 100 gears that are 4cm in diameter and capable of being used in temperatures from 0-20 degrees Celsius": what Ben actually requires. That's because I may (read: will) change my gears to be 5cm in the future, and be used in temperatures from 15-45 degrees Celsius, and those won't work anymore for Ben. However, if Ben's contract says "I'll have what Ryan's having", then that's what he's going to get, and sad times will be had. I certainly won't have much sympathy for Ben, when Ben comes asking that I change my equipment back to how it used to be, because Ben's needs are different than my needs, and it's entirely Ben's fault for not specifying his contract based on what he required, rather than what I was getting. Similarly, it'd be a bad idea to give instructions to say "Ryan's gears work with Ben's equipment", especially when my specs can and will change. They can even end up completely incompatible. For example, Ben might require durable, long-lived gears, because Ben's equipment goes into hard to reach places that are difficult to service, and thus that they may be made of metal. My gears might be made of metal now, but that's expensive for the machining and milling, and I may be planning to switch to plastic, as part of ensuring they're mass-market affordable and easily replaceable. To connect it back to the discussion: The discussion about revocation, and what a CA's CP/CPS says is or isn't allowed for a usage, matters, because browsers require CAs promptly revoke those certificates in 24 hours/5 days for situations when they specify bad requirements. Can problematic CAs fix their CP/CPS to allow this? Yes. But you've still got a host of other expectations/requirements that can and will diverge, over time. In the specific context of thinking about "#2" - what a touch-free future looks like - having it use the same root store as Web browsers is the anti-pattern, because the requirements are different. It's like Ben saying "I want Ryan's gears", rather than thinking about "I need gears that are 4cm in diameter, capable of being used in temperatures from 0-20 degrees Celsius, and durable enough to be used in hard to reach places" - and finding someone who can and will manufacture those for you. You might end up using Cogwell's Cogs, just like I do, and it might be that, for a time, our gears are produced on the same production line - but your requirements and my requirements aren't intertwined. > Is there anything better for implementations to actually do (as distinct > from what we write down as recommendations) than to start setting up a > parallel (purpose-specific) PKI now and trusting that in parallel with what > they're currently doing, with the hope of being able to have a flag day > many years down the line when the new PKI becomes the only thing that's > trusted? > There's no doubt the status quo is "Everything is manually configured" and "It's inconsistent what is validated". The goal is to get to #2, "It just works" - Define your requirements (the certificate profile) - Define your policies (what do you expect CAs to verify, and how do they verify) - Provide a way to distinguish "new certificates" from "The old and manual cruft" - for example, an explicit EKU - Pick your poison.... er, CAs... for the new root store (e.g. as WiFi Alliance has done, or Wireless Power Consortium has done, or plenty of vendors have done) - Have CAs issue certificates with both EKUs (old and new) in the leaf. It's a SEQUENCE for a reason. - Have supplicants configured that - If new EKU is present, look in built-in store - If old EKU is present, require manual configuration This gets you half-way to #2: things can just work if you pick one of the new-CAs with new-EKUs, and otherwise require manual configuration for old-EKUs At that point, supplicant vendors can slowly phase out support for 'old EKU' - If the certificate is manually generated by the wifi server, it is 'easy' to just generate certificates with the new EKU (potentially with *both* new and old EKUs) - If the certificate is coming from a "Web PKI" CA, it intentionally 'breaks' / makes this case difficult. Similarly, RADIUS/EAP-TLS servers can require, when certificates are being installed, that the 'new' EKU be present (potentially alongside the 'old' EKU), and that the certificate conforms with the 'new' profile. At some point, down the line, you can explicitly prohibit the new root store from issuing with id-kp-serverAuth. Supplicants will all be looking for/requiring the new EKU. Your RADIUS/EAP-TLS servers will all be requiring the new EKU to be configured. But when, where, and how you cross that rubicon is up to y'all, and that's the only flag day involved: when to turn off the old.
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
