On Jul 4, 2022, at 2:56 PM, Mohit Sethi <mo...@iki.fi> wrote: > > Some late last call comments: > > 1. For PEAP and TTLS, it is no longer possible to use client certificates > without phase 2 authentication. Does the same restriction apply to TEAP. I > think it would make sense to add an explanation on why this was done?
I think it should be done for TEAP, too. The text could mirror TEAP: The practice of using client certificates with no "inner tunnel" method is forbidden when TEAP is used with TLS 1.3. If there is a requirement to use client certificates with no inner tunnel methods, then EAP-TLS should be used instead of TEAP. > How about using server certificate in phase 1 and client certificate in phase > 2 (with no further inner methods)? TEAP supports such behavior for TLS 1.2 to > hide client identity? My inclination is to forbid that for TLS 1.3. However, TEAP can do multiple inner method authentication (host + user), unlike TTLS and PEAP. Which means that it is possible to do TEAP with inner EAP-TLS, and then also inner "other method". Perhaps the document could just say it's NOT RECOMMENDED to do TEAP with only inner EAP-TLS. > Would it not be better to simply mandate at least one NewSessionTicket > message? I can see situations where resumption isn't used. > I can think of a TTLS deployment where some peers only authenticate with > client certificates while other peers authenticate with client certificates > and one-time passwords in phases 2. Depending on the type of authentication, > peers are put in different VLANs. I'm not sure how that affects NewSessionTicket? One-time passwords in phase 2 are a significant issue with EAP methods. Where people have tried to deploy them, there are many issues. They just don't work in practice for a host of reasons. The simplest one is that the supplicant caches the inner identity, and re-uses it when the WiFi signal is lost / re-gained. While a NewSessionTicket will help here, it won't always help. There are situations where the end user will be prompted again (sometimes repeatedly!) in a short period of time. I would suggest that one-time passwords in phase 2 are NOT RECOMMENDED, unless the passwords can be automatically entered without human intervention. > 2. I don't think this makes sense: > > >> Implementations SHOULD NOT use inner identities which contain an NAI >> realm. >> > > >> if the inner identity does contain an NAI realm, the inner >> realm SHOULD be either an exact copy of the outer realm, or be a >> subdomain of the outer realm. >> > > Eliot would agree that there are all kinds of IoT uses cases where the outer > NAI has a realm of the device manufacturer while the inner NAI has a realm of > the enterprise where the device is installed (or vice-versa). I think that's best described as "surprising" from an EAP standpoint. The outer NAI is overwhelmingly used to determine routing, as with Eduroam. Having different outer / inner NAIs means that the routing is broken: * packets get sent to "example.com" * the example.com server sees authentication requests for "example.net", and says "that's not me, why did you send these packets to me?" For the IoT case, we would never route the authentication packets to the device manufacturer. So it's not clear to me why the outer NAI has to contain that value. If this is a necessary use-case, I would suggest requiring that these authentications MUST be handled locally, with no routing. This issue is why I was proposing to define the outer NAI realm of "@eap.arpa". Those packets are clearly labelled as "site local", and are not forwarded. > I also don't understand why this is bad: > > >> For example, if a user >> has an inner identity of >> "u...@example.com" >> , then it generally makes >> no sense to have an outer identity of "@example.org". >> > Most university guidelines for eduroam recommend exactly what you are trying > to prevent. For example: > https://www.aalto.fi/en/services/installation-instructions-for-eduroam says: I haven't seen this recommendation in most universities. My discussions with the eduroam people make me believe that such configurations are in fact discouraged by the wider Eduroam recommendations. >> Review your settings in the Wi-Fi Settings window: >> Wireless security: WPA & WPA2 Enterprise >> Authentication: Protected EAP (PEAP) >> Anonymous identity: anonym...@aalto.fi >> CA certificate: ca-certificates.crt >> PEAP version: Automatic >> Inner authentication: MSCHAPv2 >> Username: firstname.lastn...@aalto.fi >> Password: <your Aalto password> Which is using the same realm for both outer / inner identities. So I don't understand why there's an issue. Incidentally the recommendation violates the RFCV 7542 recommendation to just use @aalto.fi as the outer NAI. i.e. an outer *user* portion of the NAI is not needed. But both *realms* are identical for inner and outer NAIs. > @Joe: I am not confident that this section has had sufficient review. I am > generally not comfortable with the text. This draft was anyways about TLS 1.3 > for TEAP/PEAP/TTLS etc. I think this is going way beyond what the draft > originally was trying to solve. This section describes wide-spread practice in the community for about a decade. While the updated text is not specific to TLS 1.3 and TTLS / PEAP / FAST / TEAP, it does give guidelines to users of TTLS / etc. for TLS 1.3. WhichI think is critical for success in real-world use-cases. > 3. Section 2.4 says: > >> the response from the EAP peer MUST be either >> EAP-Success or EAP-Failure. >> > I though the Success and Failure messages are sent by the EAP server? That was a typo, already addressed in a previous comment. > 4. Section 4 says: > > >> If either peer or server instead >> initiates an inner tunnel method >> > I thought you have mandated the use of an inner tunnel method? So why the > 'if'? Resumption doesn't use an inner tunnel method. So the "if" is necessary. Alan DeKok. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
