Re: [Emu] Short review of draft-friel-tls-eap-dpp-01
On Jul 28, 2021, at 12:26 PM, Dan Harkins wrote: > Assuming everything can be assigned a username and a password is what is > wrong. Yes. That was intended to be just an example, though. > If you're concerned about *standard* EAP methods being used in *standard* ways > then think about what we're proposing: > > 1. No change to RFC 7170 > 2. No change to RFC 8773 > 3. No change to RFC 7250 > 4. a new name assignment from a name registry created by an I-D (soon to be > RFC) That's good. One of the goals of my draft was minimal changes to existing systems. For example, the TEAP RFC is ~7 years old, and based on 3-4 years of work before that. Yet it was only recently that people started implementing it, and discovered serious issues. > So what we're proposing is using an EAP method in a way in it was defined and > using > TLS to authenticate it using tools which were defined to authenticate TLS. > We're just > proposing to use those tools in a new way. Yup. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Short review of draft-friel-tls-eap-dpp-01
On Jul 28, 2021, at 12:16 PM, Dan Harkins wrote: > I think you're reading a bit too much into "provisioning mode" here. There > was never an intention in TEAP to allow for the PKCS10/PKCS7 exchange to be > done after an anonymous Phase 1. The anonymous Phase 1 was used to get a > tunnel up in order to facilitate an exchange would would make the TEAP > connection > be mutually authenticated. The text in 3.8.3 implies that Phase 2 always > follows > an unauthenticated Phase 1 and Phase 2 MUST be mutually authenticated. OK. 7170 is a little unclear on that. > So the "this topic" you're alluding to is not really what 3.8.3 was talking > about. Sure. So there's still some need for bootstrapping, then? >> In contrast, the user work flow here is "connect to Eduroam, log in with >> your username and password". It really can't get simpler than that. > > *That* use case can't get any simpler. The 10,000 students can enter their > username/password on their 10,000 laptops. That's not what DPP or TLS-pok is > dealing with. It's 10,000 sensors with no practical user interface. Eduroam > doesn't work for 10,000 sensors with no practical user interface. I agree. My document is about users, and therefore the use-cases talk about users. But the real goal is provisioning. The "username / password" exchange happens after provisioning. It could (with no loss of generality) use another method, such as client certificates. > I don't think you're trying to solve the same problem we are. Pretty much. I suspect there may be some overlap, and I'd like to see if there's some possible synergy. > Nowhere do we propose to use EAP as a generic transport layer for > provisioning. TEAP / FAST are getting close. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Short review of draft-friel-tls-eap-dpp-01
On 7/28/21 5:06 AM, Alan DeKok wrote: On Jul 27, 2021, at 1:50 PM, Alan DeKok wrote: We are trying to avoid wheel reinvention. The novel bit here is the mutual authentication in the TLS stack based on the already defined Wi-Fi Alliance DPP bootstrap key. The novel bit in the EAP-DPP draft, yes. My leaning is more and more towards just using EAP for authentication, and doing provisioning via standard networking protocols. For example, the Wi-Fi Alliance Passpoint R3 defines unauthenticated EAP. It's essentially EAP-TLS, but using the extended EAP types with the Wifi Alliance enterprise number. This requirement means that all supplicants and servers have to be updated to support this method. Multiple that by more standards bodies, vendors, IETF working groups, and we end up with a massive amount of EAP types. All trying to get similar things done. This is already happening. Or, we define unauthenticated EAP as using "f...@eap.arpa". The supplicants need to be updated once to support that. Different use-cases can just request different methods via changing the username portion. And once they have network access, run separate utilities to do their magic provisioning. Mashing everything into EAP seems just... wrong. Assuming everything can be assigned a username and a password is what is wrong. If you're concerned about *standard* EAP methods being used in *standard* ways then think about what we're proposing: 1. No change to RFC 7170 2. No change to RFC 8773 3. No change to RFC 7250 4. a new name assignment from a name registry created by an I-D (soon to be RFC) So what we're proposing is using an EAP method in a way in it was defined and using TLS to authenticate it using tools which were defined to authenticate TLS. We're just proposing to use those tools in a new way. Dan. -- "The object of life is not to be on the side of the majority, but to escape finding oneself in the ranks of the insane." -- Marcus Aurelius ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Short review of draft-friel-tls-eap-dpp-01
Hi Alan, On 7/27/21 10:50 AM, Alan DeKok wrote: On Jul 27, 2021, at 1:23 PM, Owen Friel (ofriel) wrote: [ofriel] the goal here is to push the provisioning info (e.g. CA roots, peer identity certs) inside TEAP using existing TEAP mechanisms e.g. Trusted Server Root, PKCS#7 TLVs. That presumes everyone uses TEAP, all of the time. This is likely to not be the case for a while, if ever. Well that's what we're trying to address. Making something more useful is a goal and the fact that currently that thing isn't quite as useful as it could/should be shouldn't be a reason not to make it more useful. TEAP also has the issue of bootstrapping. RFC 7170 Section 3.8.3 described an unauthenticated provisioning mode, but suggests that Phase 2 still has mutual authentication. It's not clear how the parties can identify each other in that case. The document appears to be silent on the topic. I think you're reading a bit too much into "provisioning mode" here. There was never an intention in TEAP to allow for the PKCS10/PKCS7 exchange to be done after an anonymous Phase 1. The anonymous Phase 1 was used to get a tunnel up in order to facilitate an exchange would would make the TEAP connection be mutually authenticated. The text in 3.8.3 implies that Phase 2 always follows an unauthenticated Phase 1 and Phase 2 MUST be mutually authenticated. An RA (which is what the server is acting as on behalf of a CA) needs to authenticate the user before it passes the CSR off, that's (part of) the service it's providing. Otherwise we'd end up with Kevin Mitnick getting a certificate in the name of "a...@deployingradius.com". That would not be a trustworthy CA and it's certificates would be useless garbage. So the "this topic" you're alluding to is not really what 3.8.3 was talking about. This draft solves that issue, among others. For example, what about the use-case of Eduroam? 10,000 students show up to a university which uses a private CA. Assuming that all of the devices support TEAP, they are still unable to perform "mutual authentication, and TEAP becomes ToFU. Similarly, DPP may work, but that requires creation and distribution of new keys In contrast, the user work flow here is "connect to Eduroam, log in with your username and password". It really can't get simpler than that. *That* use case can't get any simpler. The 10,000 students can enter their username/password on their 10,000 laptops. That's not what DPP or TLS-pok is dealing with. It's 10,000 sensors with no practical user interface. Eduroam doesn't work for 10,000 sensors with no practical user interface. The first stage of this proposal requires no changes to existing supplicants. A simple client-side utility can perform the requisite actions, and configure the supplicant. Running code is available: https://networkradius.github.io/automatic-eap/ The core of the work is a ~300 line Python script. OS vendors could ship this today. Network administrators could add a few records to DNS/WWW. Getting EAP connectivity then becomes trivial. It requires minimal coordination, and minimal new software. So when I go to that URL it has some requirements for simple deployment. "All that's required is that the client system have... 3. a username... 4. a password". Again, trying to put a username/password on 10,000 sensors that have no user interface and assuring that the RADIUS server to which these 10,000 sensors will be authenticating using Eduroam have all the right info is the pain-in-the-ass we're trying to address. I don't think you're trying to solve the same problem we are. We are trying to avoid wheel reinvention. The novel bit here is the mutual authentication in the TLS stack based on the already defined Wi-Fi Alliance DPP bootstrap key. The spec doesn't require (or use) DPP bootstrapping. It uses the key extracted from a DPP bootstrapping process so I think you're doing a semantic exercise here-- a distinction with no difference. This draft is different from a number of related issues in that it solves a different problem, and in a different way: * it leverages web PKI to bootstrap TLS-based EAP methods * it does provisioning over standard internet protocols, instead of extending the supplicant. I think both of the above are useful. Using EAP as a generic transport layer for provisioning seems like a poor choice. Nowhere do we propose to use EAP as a generic transport layer for provisioning. Dan. -- "The object of life is not to be on the side of the majority, but to escape finding oneself in the ranks of the insane." -- Marcus Aurelius ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Short review of draft-friel-tls-eap-dpp-01
On Jul 27, 2021, at 1:50 PM, Alan DeKok wrote: >> We are trying to avoid wheel reinvention. The novel bit here is the mutual >> authentication in the TLS stack based on the already defined Wi-Fi Alliance >> DPP bootstrap key. The novel bit in the EAP-DPP draft, yes. My leaning is more and more towards just using EAP for authentication, and doing provisioning via standard networking protocols. For example, the Wi-Fi Alliance Passpoint R3 defines unauthenticated EAP. It's essentially EAP-TLS, but using the extended EAP types with the Wifi Alliance enterprise number. This requirement means that all supplicants and servers have to be updated to support this method. Multiple that by more standards bodies, vendors, IETF working groups, and we end up with a massive amount of EAP types. All trying to get similar things done. This is already happening. Or, we define unauthenticated EAP as using "f...@eap.arpa". The supplicants need to be updated once to support that. Different use-cases can just request different methods via changing the username portion. And once they have network access, run separate utilities to do their magic provisioning. Mashing everything into EAP seems just... wrong. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Short review of draft-friel-tls-eap-dpp-01
On Jul 27, 2021, at 1:23 PM, Owen Friel (ofriel) wrote: > [ofriel] the goal here is to push the provisioning info (e.g. CA roots, peer > identity certs) inside TEAP using existing TEAP mechanisms e.g. Trusted > Server Root, PKCS#7 TLVs. That presumes everyone uses TEAP, all of the time. This is likely to not be the case for a while, if ever. TEAP also has the issue of bootstrapping. RFC 7170 Section 3.8.3 described an unauthenticated provisioning mode, but suggests that Phase 2 still has mutual authentication. It's not clear how the parties can identify each other in that case. The document appears to be silent on the topic. This draft solves that issue, among others. For example, what about the use-case of Eduroam? 10,000 students show up to a university which uses a private CA. Assuming that all of the devices support TEAP, they are still unable to perform "mutual authentication, and TEAP becomes ToFU. Similarly, DPP may work, but that requires creation and distribution of new keys In contrast, the user work flow here is "connect to Eduroam, log in with your username and password". It really can't get simpler than that. The first stage of this proposal requires no changes to existing supplicants. A simple client-side utility can perform the requisite actions, and configure the supplicant. Running code is available: https://networkradius.github.io/automatic-eap/ The core of the work is a ~300 line Python script. OS vendors could ship this today. Network administrators could add a few records to DNS/WWW. Getting EAP connectivity then becomes trivial. It requires minimal coordination, and minimal new software. > We are trying to avoid wheel reinvention. The novel bit here is the mutual > authentication in the TLS stack based on the already defined Wi-Fi Alliance > DPP bootstrap key. The spec doesn't require (or use) DPP bootstrapping. This draft is different from a number of related issues in that it solves a different problem, and in a different way: * it leverages web PKI to bootstrap TLS-based EAP methods * it does provisioning over standard internet protocols, instead of extending the supplicant. I think both of the above are useful. Using EAP as a generic transport layer for provisioning seems like a poor choice. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Short review of draft-friel-tls-eap-dpp-01
-Original Message- From: Emu On Behalf Of Alan DeKok Sent: 19 July 2021 00:40 To: EMU WG Subject: [Emu] Short review of draft-friel-tls-eap-dpp-01 No major notes here. There's still a lot of TBD in the document. :) NITS: Section 3 says: ... For unprovisioned devices that desire to take advantage of TLS-POK, there is no initial realm in which to construct an NAI (see [RFC4282]) so the initial EAP Identity response SHOULD contain simply the name "TLS-POK" in order to indicate to the Authenticator that an EAP method that supports TLS-POK SHOULD be started. * RFC 4282 has been deprecated by RFC 7542 * There just might be a user with name "TLS-POK", so using bare names is likely not a good idea. After looking at this, EAP-NOOB, and my latest document, there seem to be some overlap with EAP identities. EAP-NOOB suggests a ".arpa" realm. It would be good to agree on, and use, a common naming scheme. My suggestion is to define "eap.arpa" for EAP purposes. This realm would be defined to be handled locally at the EAP server. i.e. never proxied. And used only for provisioning purposes. We can then have: * n...@eap.arpa for EAP-NOOB * tls-...@eap.arpa for this document * perhaps "provision...@eap.arpa for "I want a captive portal / provisioning network". I have some updates pending to my document which discusses this concept. One issue we currently have today is that there's no standard way for an EAP client to say "I want network access, but I don't really care who it's from, and I don't really care to prove who I am". This kind of authentication-less network access is still useful, as noted in the EAP-TLS 1.3 document. Similar provisioning is in EAP-FAST and TEAP. I suspect that would be useful to have full network capabilities for provisioning. While it can be nice to push all kinds of provisioning into an EAP method, TBH that seems like re-inventing the wheel. [ofriel] the goal here is to push the provisioning info (e.g. CA roots, peer identity certs) inside TEAP using existing TEAP mechanisms e.g. Trusted Server Root, PKCS#7 TLVs. We are trying to avoid wheel reinvention. The novel bit here is the mutual authentication in the TLS stack based on the already defined Wi-Fi Alliance DPP bootstrap key. Instead, we could just have the EAP client go "I want access as @eap.arp" or maybe "provision...@eap.arpa". It then gets a "captive portal" network, and can rely on the rest of the TCP/IP stack, and the web PKI to download complex provisioning data. From an implementation point of view, updating EAP clients and servers is hard. It takes a long time for changes to be written, tested, and widely deployed. In contrast, if the client had access to a provisioning network, it can be easier to write a simpler utility which downloads information. Among other benefits, there is also a clear separation of roles between network access, and configuration changes. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
[Emu] Short review of draft-friel-tls-eap-dpp-01
No major notes here. There's still a lot of TBD in the document. :) NITS: Section 3 says: ... For unprovisioned devices that desire to take advantage of TLS-POK, there is no initial realm in which to construct an NAI (see [RFC4282]) so the initial EAP Identity response SHOULD contain simply the name "TLS-POK" in order to indicate to the Authenticator that an EAP method that supports TLS-POK SHOULD be started. * RFC 4282 has been deprecated by RFC 7542 * There just might be a user with name "TLS-POK", so using bare names is likely not a good idea. After looking at this, EAP-NOOB, and my latest document, there seem to be some overlap with EAP identities. EAP-NOOB suggests a ".arpa" realm. It would be good to agree on, and use, a common naming scheme. My suggestion is to define "eap.arpa" for EAP purposes. This realm would be defined to be handled locally at the EAP server. i.e. never proxied. And used only for provisioning purposes. We can then have: * n...@eap.arpa for EAP-NOOB * tls-...@eap.arpa for this document * perhaps "provision...@eap.arpa for "I want a captive portal / provisioning network". I have some updates pending to my document which discusses this concept. One issue we currently have today is that there's no standard way for an EAP client to say "I want network access, but I don't really care who it's from, and I don't really care to prove who I am". This kind of authentication-less network access is still useful, as noted in the EAP-TLS 1.3 document. Similar provisioning is in EAP-FAST and TEAP. I suspect that would be useful to have full network capabilities for provisioning. While it can be nice to push all kinds of provisioning into an EAP method, TBH that seems like re-inventing the wheel. Instead, we could just have the EAP client go "I want access as @eap.arp" or maybe "provision...@eap.arpa". It then gets a "captive portal" network, and can rely on the rest of the TCP/IP stack, and the web PKI to download complex provisioning data. From an implementation point of view, updating EAP clients and servers is hard. It takes a long time for changes to be written, tested, and widely deployed. In contrast, if the client had access to a provisioning network, it can be easier to write a simpler utility which downloads information. Among other benefits, there is also a clear separation of roles between network access, and configuration changes. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
