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

[Joseph Salowey <[e-mail]>]

On Wed, Feb 15, 2023 at 7:29 PM Alan DeKok <[e-mail]>
wrote:

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


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


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

"The interaction between EAP implementations and any underlying TLS library
may be
complex, and the server may not be able to guarantee when a session is
cached
or what information is associated with the cached session.  It is up to the
EAP
server to ensure that it does not allow for insecure uses of EAP. In these
cases the server MUST assume that inner authentication has not completed
and it MUST run the inner authentication methods in the resumed tunnel
before granting
access.  If the server is able to include the state of the client's
authentication in the cached
session state or if the server can guarantee that the newSessionTicket
message is only sent
after successful authentication, then it MAY have a policy that uses this
information to skip
inner methods."



> 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.
>
>
[Joe] I think we can remove the above paragraph.


> 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.
>
>
[Joe] How about:

"For example, if the server has a flag in its server side cache to indicate
successful client authentication, it would not set this flag until inner
authentication
completes.  Alternatively, if the server is generating a client side ticket
to indicate
successful client authentication then it MUST defer sending the
newSessionTicket
message until client 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
>
>
[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.