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

[Joseph Salowey <[e-mail]>]

Thanks Alan, your text looks good.

On Thu, Feb 16, 2023 at 5:48 AM Alan DeKok <[e-mail]>
wrote:

> 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.
>
>