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? 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? Would it not be
better to simply mandate at least one NewSessionTicket message? 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.
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 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:
*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>
@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.
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?
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'?
--Mohit
On 6/8/22 19:16, Joseph Salowey wrote:
This is the working group last call for draft-ietf-emu-tls-eap-types.
You can find the document here:
https://datatracker.ietf.org/doc/html/draft-ietf-emu-tls-eap-types
<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-emu-tls-eap-types&data=05%7C01%7Csethim1%40aaltofi.mail.onmicrosoft.com%7C983f8dc1a09344ffefba08da496a4b67%7Cae1a772440414462a6dc538cb199707e%7C1%7C0%7C637903018430350080%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&sdata=VzzXUxFfIQiLJ4JwBcBBDcWaK4jh0HrVZLSsLlrbNjA%3D&reserved=0>
Please respond to the list with comments by June 24, 2022. Responses
that indicate that you have read the draft and think it is ready to
move forward are also useful.
Thanks,
Joe & Mohit
_______________________________________________
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
