On Jun 20, 2025, at 3:32 PM, Benjamin Kaduk <ka...@mit.edu> wrote:
>
> Thanks for the updates in the -07; they largely address my concerns.
> The main point I see as open is nailing down the TLS-PSK situation for
> EAP-TLS (noting in particular that if we use a well-known PSK value then
> TLS-PSK does not provide server authentication).
Sure. I can add some text addressing this issue.
> I was trying to say that a given TLS server "usually" (there is a good bit
> of handwaving here) expects all of its clients to either use a certificate
> to authenticate the server or use PSK; the situation for TLS clients
> talking to a specific server is even more strongly so, with it being a very
> strang (and often difficult) flow for a client to say "talk to server X, I
> will accept either a certificate chaining to these CAs or successful proof
> of knowledge of this PSK as server authentication".
I'll just delete the last paragraph about TLS-PSK, and update an earlier
paragraph:
This identifier signals the EAP server that the peer wishes to obtain
"peer unauthenticated access" as per {{RFC5216, Section 2.1.1}} and
{{RFC9190}}. Note that peer unauthenticated access MUST provide for
authentication of the EAP server, such as with a server certificate.
Using TLS-PSK with a well-known PSK value is generally not appropriate,
as it would not provide server authentication.
This section also has some generic text on requirements for the EAP methods.
I've moved that text earlier in the document, into its own section. It also
notes that it's OK to use methods that don't authenticate the EAP server, so
long as some later element can be authenticated. e.g. HTTPS provisioning
server.
> I thought we were trying to claim that EPI was 1:1 with provisioning
> method, such that EAP-TLS provisioning behavior would need to be fully
> specified in this document (to the extent that it interacts with the TLS
> handshake used for EAP).
The text suggests that the EAP-TLS EPI is for captive portal authentication:
This document defines an identifier "por...@tls.eap.arpa", which is
the first step towards enabling unauthenticated client provisioning in
EAP-TLS. The purpose of the identifier is to allow EAP peers to
signal EAP servers that they wish to obtain a "captive portal" style
network access.
Captive portals are already widely used for WiFi, with well-known SSIDs that
provide no authentication or security. The "por...@tls.eap.arpa
<mailto:por...@tls.eap.arpa>" identifier allows exactly the same functionality
as exists today, except that the WiFi connections can now be better protected.
> If we can defer things to the specific technique used to provision
> credentials after EAP-TLS establishment, that would be ok, but I don't
> think the current specification gives us rope to make the TLS handshake
> behavior of the EAP-TLS connection depend on a provisioning mechanism when
> the choice of provisioning mechanism is not indicated in the EPI.
The proposal for "por...@tls.eap.arpa <mailto:por...@tls.eap.arpa>" is to
provide captive portal access, not to provision credentials. So I think it's
fine.
I'll clarify the text.
>>> I would probably also say something to clarify that the (lowercase!) raw
>>> ASCII
>>> byte string of the NAI name is used directly as the PSK, without other
>>> processing, but that's just at a comment level.
>>
>> The text already says that the PSK identity must be the same as the EAP
>> Identifier (i.e. NAI), and also used as the PSK. I'll add some clarifying
>> text.
>
> (as noted above) using a well-known value as the PSK itself cannot provide
> server authentication.
> If we're going to say that "all provisioning methods [...] MUST Define a
> way to authenticate the server. This authentication can happen either at
> the EAP layer (as with EAP-TLS), [...]" then I think we need EAP-TLS with
> TLS-PSK to authenticate the server as well. Am I missing something?
See earlier text which allows unauthenticated servers, so long as the later
provisioning server is authenticated.
> (It looks like we have some text in §5 that mentions TTLS and PEAP as using
> the EPI for identity+password that also impacts their ability to perform
> server authentication if TLS-PSK is used.)
That's fine. See above.
>>> ## Comments
>>>
>>> ### division of responsibility between this doc and provisioning methods
>>>
>>> In §5 we have some discussion about how our predefined provisioning NAIs
>>> will
>>> interact with existing EAP types, including a statement that where TLS-based
>>> methods have inner identity/authentication, those credentials "MUST be the
>>> provisioning identifier", among other requirements. I'm not sure I
>>> understand
>>> why we need to tie our hands so strongly in this document, when any given
>>> provisioning identifier is going to be specific to a single EAP method (per
>>> §6.2 and 3.4.1). Why is it necessary for the core protocol framework
>>> specifically to impose this requirement, vs the individual provisioning
>>> methods doing so (with guidance from the framework as a useful default)?
>>
>> I don't see why provisioning methods would need to define per-method
>> credentials.
>
> I don't either, but that doesn't mean I can prove they would never need to
> do so.
I can change that to "SHOULD be the provisioning identifier".
>>> I do see that the registration procedure is merely "expert review" so there
>>> may not always be a document that would be able to hold such a requirement.
>>> But it seems like we could say "unless otherwise specified, assume that the
>>> password is the provisioning identifier" and leave room for future
>>> evolution.
>>
>> I can make it a SHOULD.
>
> It looks like you changed §5¶2 but we also have a MUST in §5¶3 that talks
> about inner identity/password.
Fixed.
> % EAP peers therefore MUST trak which provisioning methods have been tried,
> % and not repeat the same method to the same EAP server when receiving an
> % EAP Nak, within the scope of the current network attachment. EAP peers
> SHOULD
> % retain this state for at least a day, but MAY discard state after such a
> % delay, allowing them to retry the provisioning method at a much later
> % time, which allows for the possibility that the server has implemented
> % the provisioning method in question.
How about:
Since there is no way to signal whether the failed provisioning is due
to a transient failure on the EAP server, or whether it is due to the
EAP server not supporting that provisioning method, EAP peers SHOULD
err on the side of long delays between retrying the same provisioning
method to an EAP server. EAP peers MAY retry a given provisioning
method after a sufficiently long interval that the EAP server might
have implemented the provisioning method, e.g., at least a day, and
perhaps no more than a month.
>>> Do we need to specifically include in this section the content from §6.4
>>> that
>>> the Method Type must provide MSK and EMSK?
>>
>> Yes. I'll add a note.
>
> (I am not seeing this one.)
The draft says:
The EAP Method Type MUST provide an MSK and EMSK as defined in
{{RFC3748}}. Failure to provide these keys means that the method will
not be usable within an authentication framework which requires those
methods, such as with IEEE 802.1X.
Alan DeKok.
_______________________________________________
Emu mailing list -- emu@ietf.org
To unsubscribe send an email to emu-le...@ietf.org
