Re: [Emu] [lamps] EAP/EMU recommendations for client cert validation logic
Or... just stop using those certs/roots already? We’ve already identified that there is absolutely zero reason to do so in the extant status quo, because it still requires manual configuration. You get no benefits and clearly downsides, so just... don’t do that? Any complaints about how that existing PKI is managed is just a complaint that it doesn’t fit your purposes and doesn’t do what you want, which is fine: that’s the entire point. If you don’t like CAs being required to do what they say, and be held accountable to stated policies, then sure, let them issue whatever they want and decide unilaterally what the risks are. Of course, then you’ll end up with situations like CAs issuing certificates with duplicate serial numbers, with one of the duplicates being a CA certificate used for active MITM of user connections, and the issuing CA complaining that revoking would be disruptive for those other holders with the same serial number. Which is a real thing that happened, and indistinguishable from a policy perspective to Alan’s example. Or you can deal with the commiserate legal risks involved in selectively enforcing when you agree or disagree with the CA’s risk assessment and what is “reasonable”, with the CA who issues certificates used for MITM lamenting it’s “unfair” and “inconsistent” that they aren’t allowed to declare there is no risk for those certificates, while other CAs get to declare there’s no risk for EAP-TLS, despite their policies stating they don’t allow it. If you don’t want to deal with those problems, which are messy and complex, then yes, manually configure your certs, and don’t manually configure ones that expose you to all of this. Problem solved, and no need for Dickens. I can appreciate that, if you’re not involved with managing a PKI or trust store, it would seem undesirable to actually enforce standards and contracts and policies as they were written, especially when inconvenient. Yet documents like RFC 3647 exist precisely because the world is not a technocratic utopia, trust is a hard problem, and it exists in a world where there are messy and complex legal problems. If you want to use want to use PKI, and you want to do more than just require explicit manual configuration, then you have to deal with all of that and more. You can pretend it doesn’t exist, but you can’t escape that reality.. DigiNotar is an example, but one of dozens at this point. Manual configuration lets you localize that to things you control, and so that’s an eminently reasonable status quo. On Sat, Jan 18, 2020 at 12:34 AM Owen Friel (ofriel) wrote: > If the PKI community as a whole (vendors, standards bodies, consortia, > CAs) has managed to engineer a situation where, according to the strict > letter of the law, CAs would have no choice but to revoke operators > identity certificates for many of their services if Alan was actually mean > and wrote his script, which would cause widespread outages, then, quoting > Charles Dickens, "the law is a ass", and I'm with Alan and Richard and the > law (the CP/CPS) should probably change. > > > -Original Message- > > From: Spasm On Behalf Of Alan DeKok > > Sent: 17 January 2020 19:39 > > To: Ryan Sleevi > > Cc: sp...@ietf.org; Michael Richardson ; Joseph > > Salowey ; Benjamin Kaduk ; EMU WG > > > > Subject: Re: [lamps] [Emu] EAP/EMU recommendations for client cert > validation > > logic > > > > > > On Jan 17, 2020, at 12:33 PM, Ryan Sleevi wrote: > > > 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. > > > >I'm not sure how a RADIUS server will disable WiFi. They are > entirely separate > > systems. > > > > > 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? > > > > The RADIUS server has a domain name, which is commonly used in the > > certificate. > > > > If that is insufficient for the CAs purposes, then we should also > acknowledge > > that the revocation requirement likely also applies to SMTP, XMPP, DNS > over > > TLS, and IMAP. i.e. *all* non-WWW protocols which use TLS. > > > > We should not single-out EAP / RADIUS as mis-using the certificates in > this > > manner. The mis-use of these certificates in other protocols is orders > of > > magnitude larger than the EAP / RADIUS problem. > > > > > 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 > > > > EAP supplicants follow RFC 5216 Section 5.3. > > > > > 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
Re: [Emu] [lamps] Using public CA infrastructure for autonomic bootstrapping over EAP.
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
[Emu] using public CAs for IDevID and device certificates
Michael Richardson wrote: > 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] 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 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. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Using public CA infrastructure for autonomic bootstrapping over EAP.
On Jan 17, 2020, at 5:19 PM, Michael Richardson wrote: > } 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" 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. > 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. Yes. I've omitted BSRKI comments. I have less to contribute there > 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. I'm not clear on "include". > 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. 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. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] [lamps] EAP/EMU recommendations for client cert validation logic
Ryan Sleevi wrote: > 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 certsign.ro uses a Fortinet.com certificate on their SMTP server. Does Fortinet.com's CSP permit SMTP usage? The certificate does not have the serverAuth bit set. > 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? "accessible" is not defined. maybe CAFORUM needs to write port 443 from now on? If you were part of eduroam, and you uses ryan-i...@sleevi.com as your identity, then the roaming mechanism would connect eventually to your Radius server using that name. Thus, it is accessible. Your gear analogy is understood, but for many of us, we see the specs as having been designed by lawyers rather than engineers in order to maximize profit and minimize interoperability. I'm not arguing we are right. It just feels like needless and wastefully restrictive attempts to create market verticals. > 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. And yet, almost every single thing out there would like to be connected to by a browser. They can't, so we have an app-per-thing, and/or no-security. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
[Emu] Using public CA infrastructure for autonomic bootstrapping over EAP.
{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 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
Re: [Emu] [lamps] EAP/EMU recommendations for client cert validation logic
On Jan 17, 2020, at 12:33 PM, Ryan Sleevi wrote: > 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. I'm not sure how a RADIUS server will disable WiFi. They are entirely separate systems. > 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? The RADIUS server has a domain name, which is commonly used in the certificate. If that is insufficient for the CAs purposes, then we should also acknowledge that the revocation requirement likely also applies to SMTP, XMPP, DNS over TLS, and IMAP. i.e. *all* non-WWW protocols which use TLS. We should not single-out EAP / RADIUS as mis-using the certificates in this manner. The mis-use of these certificates in other protocols is orders of magnitude larger than the EAP / RADIUS problem. > 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 EAP supplicants follow RFC 5216 Section 5.3. > 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", True. > as well as "Some of the answers in #1 are problematic and you should try and > discourage them" There were *allegations* of problems. > 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. If I was mean, I would write scripts to troll the net for mis-use of certificates in SMTP, XMPP, IMAP, VPNs, etc. Then, make the script auto-submit notices to the relevant CAs. That process is simple to do, and by the above rules, would require the CAs to revoke the relevant certs. i.e. certs which affect a high percentage of daily internet traffic. If that scenario were to play out, I suspect that CAs would very quickly stop revoking the relevant certs. A straight-forward approach to enforcing the rules would be over-ruled by simple practicalities: Turning off big chunks of the Internet is a non-starter. As Michael Richardson pointed out, then solution here is likely to fix the rules, not the protocols. > 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. And therefore we need a different root store for *each* of EAP, RADIUS, SMTP, XMPP, IMAP, DNS over TLS, VPNs, etc. Note that we need *different* stores for EAP and RADIUS, because RADIUS server are reachable on port 2083 as RADIUS over TLS, *and* they implement TLS over EAP, which in turn carried over RADIUS. Different use-cases, different root stores. There may be significant push-back against that many root stores. > 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 That's good, but insufficient. There is a lot more verification that EAP supplicants need to do before automatically trusting a root CA. I suspect that most CAs already know that their customers mis-use certs for non-WWW purposes. EAP / RADIUS is just a minor (almost insignificant) part of this problem. I also suspect most CAs operate based on the hope that no one notices, and then requires them to revoke many, many, certificates. Alan DeKok. ___ Emu mailing
Re: [Emu] [lamps] EAP/EMU recommendations for client cert validation logic
On Jan 17, 2020, at 1:29 PM, Michael Richardson wrote: > You omitted an important part of that output, which is the name of the CA, > which I include below. Sure. > It could be that the CSP permits SMTP, or SUBMISSION service. > Ryan has suggested that CAs could put EAP-TLS (or EAP-TEAP) into their CSP, > and that also seems like an out. I agree. > 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. As such, this discussion should more productively focussed on non-HTTP mis-uses of id-kp-serverAuth. Which means pretty much everything using TLS. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] [lamps] EAP/EMU recommendations for client cert validation logic
Alan DeKok wrote: > Perhaps we should try? > $ openssl s_client -connect smtp.mozilla.org:587 -starttls smtp > mozilla.crt > $ openssl x509 -text -in mozilla.crt You omitted an important part of that output, which is the name of the CA, which I include below. It could be that the CSP permits SMTP, or SUBMISSION service. Ryan has suggested that CAs could put EAP-TLS (or EAP-TEAP) into their CSP, and that also seems like an out. 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. The detail: Issuer: C = US, O = DigiCert Inc, CN = DigiCert SHA2 Secure Server CA Subject: C = US, ST = California, L = Mountain View, O = Mozilla Corporation, OU = WebOps, CN = smtp.mozilla.org But, let's do some more tests: dooku-[/var/tmp](2.6.5) mcr 10051 %host letsencrypt.org letsencrypt.org has address 162.243.166.170 letsencrypt.org has IPv6 address 2604:a880:400:d1::89c:7001 letsencrypt.org mail is handled by 5 alt2.aspmx.l.google.com. dooku-[/var/tmp](2.6.5) mcr 10052 %echo QUIT | openssl s_client -connect alt2.aspmx.l.google.com:25 -starttls smtp >| letsencrypt.crt dooku-[/var/tmp](2.6.5) mcr 10053 %openssl x509 -text -in letsencrypt.crt| grep Issuer Issuer: C = US, O = Google Trust Services, CN = GTS CA 1O1 CA Issuers - URI:http://pki.goog/gsr2/GTS1O1.crt What do CA's do? dooku-[/var/tmp](2.6.5) mcr 10054 %host digicert.com digicert.com has address 45.60.121.229 digicert.com has address 45.60.131.229 digicert.com mail is handled by 20 us-smtp-inbound-2.mimecast.com. dooku-[/var/tmp](2.6.5) mcr 10055 %echo QUIT | openssl s_client -connect us-smtp-inbound-2.mimecast.com:25 -starttls smtp >| digicert-smtp.crt depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global Root G2 dooku-[/var/tmp](2.6.5) mcr 10056 %openssl x509 -text -in digicert-smtp.crt| grep Issuer Issuer: C = US, O = DigiCert Inc, CN = DigiCert Global CA G2 CA Issuers - URI:http://cacerts.digicert.com/DigiCertGlobalCAG2.crt What's that quote about doctor's fixing themselves? -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] [lamps] EAP/EMU recommendations for client cert validation logic
On Wed, Jan 15, 2020 at 11:07 PM Benjamin Kaduk 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,
Re: [Emu] [lamps] EAP/EMU recommendations for client cert validation logic
On 1/16/20 6:07 AM, Benjamin Kaduk wrote: > 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? This seems like a reasonable way forward to me. --Mohit ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
