Re: [Emu] Working Group Last Call for draft-ietf-emu-tls-eap-types

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"user@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: anonymous@aalto.fi
> CA certificate: ca-certificates.crt
> PEAP version: Automatic
> Inner authentication: MSCHAPv2
> Username: firstname.lastname@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