Just to clarify, are you describing EAP-PEAP or EAP-TTLS wrapping PEAP? I'm still learning a lot of this stuff... but, my understanding is that PEAP doesn't do TLS but TTLS + PEAP does. Right?
Fact remains, though, that users will probably bypass any certificate warnings (if allowed) and send their passwords to rogue APs. EAP-TLS mitigates this. Definitely pros & cons, but that's a clear win for EAP-TLS.
There are a lot of things that'd be nice to see in Wifi. Binding the SSID is an interesting one, though I suspect the folks working on this stuff were reluctant to rely on (and trust) the Web PKI CAs. If you're gonna push your own root cert, you might as well push a RADIUS SAN along with it, I guess.
You can roll your own with https://github.com/smallstep/certificates. We maintain major open source projects and contribute a lot to other projects. I don’t think that means everything we do has to be open source. Sorry this one wasn’t. Doing this in pure open source would be a book, not a blog post.
Love Let’s Encrypt — we’re sponsors — but using them for WiFi is a terrible idea. You need internal PKI for WiFi.
Well... the title is hyperbolic (as titles are wont to be), but the goal was to configure Wifi that aligns with the CNSA Suite[1] / CNSSP 15[2], which I think is fair to call "NSA-grade" since they wrote the standard.
If the NSA wants to get a certificate that your system trusts there are already dozens of organizations with root certs in your system trust store that they can strongarm. Most organizations can't afford to have the NSA in their threat model. You better not be using public clouds, GSuite, Okta, Azure AD/Entra, etc. This is a difficult security posture to maintain, especially at scale.
For most organizations, delegating the operation of sensitive security infrastructure to a third party results in better security, not worse. Yes, you're trusting a third party. But you're also outsourcing sensitive security operations to experts.
And, we also have on-prem and open source if you really need something air-gapped ;)
For home wifi this is totally overkill. Better security is always nice but, in this case, there's a significant usability & interop tradeoff for home use (though that may change over time... we'll see).
For business / enterprise settings, this has real value. Distributing a password to everyone doesn't scale and alternative EAP methods have huge security problems. For managed devices, certs can be pushed and EAP-TLS can be configured easily. And it's all seamless for end users[1].
For example, EAP-TLS mitigates "evil twin" attacks, where a rogue access point broadcasts your SSID. If you're using something like EAP-PEAP, which is password based, the user is sending a password to the RADIUS server. If they connect to a rogue AP, they just sent their password to the bad guy. If the password is their LDAP/AD/Okta password, that could be very bad.
There are a variety of mitigations for this sort of attack but, without getting into details, EAP-TLS is widely considered the most secure option. So, yea, if you're relying exclusively on wifi for security you're doing it wrong. But that doesn't mean you don't need to secure your wifi.
I work at smallstep. Yes. This also works with FreeRadius! We decided to integrate RADIUS into our product since setting up FreeRadius is complicated and, if you're just doing EAP-TLS for Wifi, you don't need all of the features. You don't need to use our hosted RADIUS though.
In this case you're getting an industrial-grade CA with a properly managed private key, etc. Still, fair. We usually include warnings about this, but looks like we forgot this time. Curse of knowledge. I'll see about getting a warning on there asap.
Not sure about the RADIUS server, but connections to the CA use TLS for SCEP and/or ACME DA so the CA root cert needs to be trusted for TLS. There may be some way to configure more narrow trust for just this one interaction, but I'm not aware of any such mechanism in the current releases of macOS/iOS/iPadOS/tvOS.
> For the use case cited -- blocking MAC spoofing, EAP-TLS doesn't quite solve it
The idea would be to rely on the client certificate authentication and not use MAC filtering at all. For example, you could have an EAP-TLS network that's unrestricted and not let Mallory on it. Or you could use RADIUS reply attributes to put Mallory on a restricted vlan.
What would happen if you tried to reconnect to the network and the AP didn't have the pre-shared key? Presumably, you'd prompt the user and ask them if they want to connect. This is the same pattern as trust-on-first-use (TOFU) for SSH, except for non-expert users. It's a good thought but I think it'd fall apart in practice. You'd still be vulnerable to phishing / evil twin APs.
This is not a technical limitation though. It's a policy limitation.
In theory, a name-constrained intermediate for `.example.com` has no more authority and poses no greater risk than a wildcard leaf certificate for `.example.com`. In both cases the private key can be used to authenticate as any subdomain of `example.com`.
But, name constraints are verified by relying parties (the clients and servers that are actually authenticating remote peers using certificates). It's hard to be certain that everything has implemented name constraints properly. This is, ostensibly and as far as I know, the reason CA/Browser forum hasn't allowed name constrained intermediates.
At some point it probably makes sense to just pull the bandaid off.
I'm biased because I'm the founder of the company, but you should check out the certificate management toolchain (CA[1] and CLI[2]) we've built at smallstep. A big focus of the project is human-friendliness. It's not perfect (yet) but I think we've made some good progress.
We also have a hosted option[3] with a free tier that should work for individuals, homelabs, pre-production, and even small production environments. We've started building out a management UI there, and it does map to the CLI as you've described :).
You can put "name constraints" on an intermediate that, in theory, can restrict the intermediate to only signing certs for a particular subdomain. In theory, name-constrained intermediate certificate for `.example.com` would have no more authority than a wildcard certificate for `.example.com`.
But, name constraints are enforced by "relying parties" -- HTTPS/TLS clients & servers that are validating certificates and authenticating remote peers. In practice, there's a risk that a broken/misconfigured relying party would trust a cert for google.com signed by an intermediate that's name constrained / only trusted to issue for `*.example.com`.
Yes, your understanding is correct. I think it's slightly better than you suggest... since instance identity authentication only works once per instance (by default) you'd probably have some other monitoring stuff in your stack that would notice if a VM went rogue. If a `foo` instance got a cert for `bar` your CD stack would presumably still consider it a `foo` instance and, for example, add it to DNS as `foo`. Then connections to that instance would fail (since it can't authenticate as `foo`) and, hopefully, you'd notice.
Still, this is hand-wavey and complicated and not ideal from a security perspective. It's a lot better than not having certificates at all, but it'd be even better if this gap were closed.
To close this gap we need some sort of enrollment process. The reason we didn't add this for MVP is it's kind of complicated. I think we'd need some policy at the CA that maps VM identities to the workload identities the VM is authorized to run. We need to figure out what would run this enrollment step to add the mappings (probably different for different stacks) and how that thing would authenticate to the CA.
We've also been a bit reluctant to add ad-hoc policy stuff to the CA because we have a generic policy solution that we've been working on. Once that's released it'll give us a much better foundation for this sort of stuff.
Finally, there are other ways to build a stronger enrollment mechanism today. We have a JWT-based one-time-token authentication mechanism[1] that you can use, where a "provisioner" (e.g., something in your CD pipeline like Puppet or Kubernetes) issues a one-time token for a workload to get a certificate from `step-ca`. In this flow the JWT contains the workload's identity, so whatever issues the JWT controls certificate enrollment. This flow has pretty much the same characteristics as an IID+enrollment flow.
Finally, we have ACME support coming soon (next week, actually). So that'll be another option if you want a stronger binding to an instance's FQDN.
Hope this makes sense. Happy to answer any additional questions!
See the comparison to cfssl below. Step has lots more features, is easier to use, and harder to misuse. Relative to easy-rsa, the most important difference is that step-ca is a service that can issue certs via an API. Combined with step it can also help with lots of cert management tasks like root distribution and automated renewal.
Yep. AWS's instance identity implementation is crap. I want to write a follow-up blog post about this. They also don't rotate their keys and their tokens don't expire. To top it off, their implementation is buggy and terribly documented. Honestly it's pretty shameful. They have the resources to fix it, and they should fix it. GCP's implementation is the best. It's JWT-based and heavily inspired by OAuth OIDC identity tokens and uses a lot of the same infrastructure. Azure's is a close second. None are perfect.
That said, even AWS's crappy implementation is super useful, and really the only good way to do this (that I know of?). We've tried to mitigate this risk somewhat by making tokens single use. I'd like to also add a way to send a token to `step-ca` to say "this server doesn't need a certificate" that basically marks the instance as "used" without issuing anything. If everything that uses IIDs did this, and you ran through all of your services at startup and either authenticated or said "I never need to use this service", it would provide some protection.
Cool that's good feedback. We've been working on a web interface that we could maybe turn into an electron app for this sort of stuff.
I'm probably pressing my luck promoting here but if you do a bunch of cert related stuff check out our `step certificate` command group at https://smallstep.com/docs/cli/certificate/#commands -- it does a bunch of cool stuff like dumping x509 as JSON and extracting public keys and linting certs and it's way easier to use than openssl. Might be useful in your scripts.
Fact remains, though, that users will probably bypass any certificate warnings (if allowed) and send their passwords to rogue APs. EAP-TLS mitigates this. Definitely pros & cons, but that's a clear win for EAP-TLS.
There are a lot of things that'd be nice to see in Wifi. Binding the SSID is an interesting one, though I suspect the folks working on this stuff were reluctant to rely on (and trust) the Web PKI CAs. If you're gonna push your own root cert, you might as well push a RADIUS SAN along with it, I guess.