Hi:
On 7/4/22 22:28, Alan DeKok wrote:
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.
You don't have to use resumption. You just need to send NewSessionTicket
as a protected success indication. I thought the reason for for
forbidding use of client certificates without phase 2 authentication was
lack of protected success indication. Perhaps there is some other
reason? This is why I wrote in my original comment: "I think it would
make sense to add an explanation on why this was done? ".
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.
One-time password was only an example. Perhaps a wrong one. I just
wanted to highlight that we were forbidding TTLS/PEAP and now TEAP
deployments from using client certificates without phase 2
authentication. But there can be deployments where some peers use client
certificates without phase 2 authentication while other peers use client
certificates with additional phase 2 authentication (password, etc.).
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.
The draft currently says that inner identity should not have a realm.
However, the example above, and many other guidance documents I have
seen do use a realm in the inner identity.
--Mohit
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
