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

[Alan DeKok <[e-mail]>]

On Feb 16, 2023, at 1:28 AM, Joseph Salowey <[e-mail]> wrote:
> [Joe] I think having a separate section in the security considerations for Session Resumption is a good idea.   A few comments on the text below since I think there is a potential difference between how TTLS  recommends overloading newSessionTicket as a protected result indicator and uses of NesSessionTicket in other methods where it can be used for session resumption of TLS while still executing an inner method.  

  OK

> 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.
> 
> [Joe]  I suggest changing the last sentence to:
> 
> "If the server assumes the ticket was issued after the client was authenticated then,
> the malicious client can then obtain network access without ever being authenticated. "

  It's the "server" as whole, but really the TLS implementation.  A naive EAP implementation can "hand off" all TLS work to a TLS library.  The library then magically allows resumption and the EAP server has a security issue.   Perhaps change it to:

If the server allows the session to
resume without verifying that the user had first been authenticated,
the malicious client can then obtain network access without ever being
authenticated 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.
> 
> 
> [Joe] How about the following.

  I find the suggested text a bit harder to read.  For me, there is a clear distinction between the EAP application, and the underlying TLS library it uses.  Microsoft has a common TLS library used by multiple applications.  OpenSSL plays a similar role elsewhere.

  It's a good idea to suggest re-running the inner method on resumption where session tickets cannot be validated.  And also that policies can control whether resumed sessions are resumed, or the inner methods are run.  This is how my software works, and it's good to explain those issues in this document.

  After some major rework, how about the following text.  For me, it goes through all possibilities in excruciating detail.  I can say this is what implementors need, because I've run into pretty much all of these issues.

As a result, EAP servers MUST NOT assume that a user has been
authenticated simply because a TLS session is being resumed.  Even if
a session is being resumed, an EAP server MAY have policies which
still force the inner authentication methods to be run.  For example,
the users password may have expired in the time interval between first
authenticaction, and session resumption.

The guidelines given here therefore describe situations where an EAP
server is permitted to allow session resumption, not where it is
required to allow session resumption.  An EAP server could simply
refuse to issue session tickets, or could run the full inner
authentication even if a session was resumed.

Where session tickets are used, the EAP server SHOULD track the
successful completion of an inner authentication, and associate that
status with any session tickets issued for that session.  This
requirement can be met in a number of different ways.

One way is for the EAP server to simply not send any TLS
NewSessionTicket messages until the inner authentication has completed
successfully.  The EAP server then knows that the existence of a
session ticket is proof that a user was authenticated, and the session
can be resumed.

Another way is for the EAP server to simple discard or invalidate any
session tickets until after the inner authentication has
completed successfully.  When the user is authenticated, a new TLS
NewSessionTicket message can be sent to the client, and the new ticket
cached and/or validated.

Another way is for the EAP server to associate the inner
authentication status with each session ticket.  When a session ticket
is used, the authentication status is checked.  When a session ticket
shows that the inner authentication did not succeed, the EAP
server MUST run the inner authentication method(s) in the resumed
tunnel, and grant only access based on the success or failure of those
inner methods/

However, the interaction between EAP implementations and any
underlying TLS library may be complex, and the EAP server may not be
able to make the above guarantees.  Where the EAP server is unable to
determine the users authentication status from the session ticket, it
MUST assume that inner authentication has not completed and it MUST
run the inner authentication methods in the resumed tunnel before
granting access.

> 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 
> 
> 
> [Joe]  SInce TLS 1.3 allows for client authentication at anytime, but EAP-TLS only allows it during the initial handshake change the first sentence to:
> 
> This issue is not relevant for EAP-TLS, which only uses client certificates for authentication
> in the TLS handshake. 

  Sure.

  Alan DeKok.