Re: [Emu] Roman Danyliw's No Objection on draft-ietf-emu-tls-eap-types-12: (with COMMENT)

[Alan DeKok <[e-mail]>]

On Feb 15, 2023, at 9:53 PM, Roman Danyliw via Datatracker <[e-mail]> wrote:
> ** Section 2.4
>   It is therefore RECOMMENDED that EAP servers always send a TLS
>   NewSessionTicket message, even if resumption is not configured.  When
>   the EAP peer attempts to use the ticket, the EAP server can instead
>   request a full authentication.  Implementations SHOULD NOT send
>   NewSessionTicket messages until the "inner tunnel" authentication has
>   completed, in order to take full advantage of the message as a
>   protected success indication.
> 
> It is my understanding that this SHOULD NOT is based in implementation
> realities.  Can text be added to establish the basis for this not being “MUST
> NOT”.  Please also add cross-references as appropriate into the document on the
> same topic.

  The issue is discussed in more detail in the Security Considerations section.  I'll add some text here which references RFC 8446 Section 4.6.1.

  In short, TLS 1.3 allows for NewSessionTicket to be sent from the server, even before the application data has been processed.  This means that a client could connect, get a ticket, disconnect, and then immediately "resume" the session, without ever being fully authenticated.

  As a result, EAP implementations have to either reject session tickets which were sent before the user was authenticated, or delay sending NewSessionTicket until after the user has been authenticated.

  On closer examination, the text about NewSessionTicket is in the "TTLS" section, but is really applicable to all TLS-based EAP methods.  I'll move the text from the Security Considerations section to a new section discussing TLS NewSessionTicket messages in more detail.  Here's some new text:

Section "Handling of TLS NewSessionTicket Messages"

In some cases, client certificates are not used for TLS-based EAP
methods.  In those cases, the user is authenticated only after
successful completion of the inner tunnel authentication.  However,
[RFC84346] Section 4.6.1 allows that "At any time after the server has
received the client Finished message, it MAY send a NewSessionTicket
message."  This message is sent by the server before the inner
authentication method has been run, and therefore before the user has
been authenticated.

This separation of data allows for a "time of use, time of check"
security issue.  Malicious clients can begin a session and receive a
NewSessionTicket message.  The malicious client can then abort the
authentication session, and use the obtained NewSessionTicket to
"resume" the previous session.  The malicious client can then obtain
network access without ever being authenticated.

As a result, EAP servers MUST NOT permit sessions to be resumed until
after authentication has successfully completed.  This requirement may
be met in a number of ways.  Where possible, implementations SHOULD
NOT send TLS NewSessionTicket messages until the "inner tunnel"
authentication has completed successfully.  However, the interaction
between EAP implementations and any underlying TLS library may be
complex, and this behavior may not always be possible.

Is is up to the EAP server to ensure that it does not allow for
insecure uses of EAP.  It may not be possible to delay the TLS
NewSessionTicket messages until the "inner tunnel" authentication has
completed successfully.  In that case, the EAP server MUST NOT allow
the session ticket to be valid (or validated) until after the "inner
tunnel" authentication has completed.

For example, if the ticket is cached on the server, the server coudl
skip caching the session ticket until after authentication has
completed.  Alternatively, the server could mark up the session ticket
with a flag stating whether or not authentication has completed.

This issue is not relevant for EAP-TLS, which uses client certificates
for authentication.  It is only relevant for TLS-based EAP methods
which do not use the TLS layer to authenticate