Re: [Emu] Notes on session resumption with TLS-based EAP methods

[Alan DeKok <[e-mail]>]

On Mar 11, 2019, at 12:52 PM, John Mattsson <[e-mail]> wrote:
> There seems to be agreement on the list to add security considerations on authorization and resumption. With the text from Alan as a basis (thanks again Alan!), I have added the sections below to draft-ietf-emu-eap-tls13.
> 
> Some high level changes from Alas text:
> - Some considerations also cover the EAP peer
> - Description of encapsulation protocols moved from resumption to authorization
> - Added that revocation status and authorization may change before resumption

  Sounds good.

> Discussing with me co-author, we agreed that cross-method resumption may be best to discuss in Alans document that talks about various TLS-based EAP methods. That document is expected to go into the various methods in more detail.

  It may be worth mentioning it here, and saying that the implementations should be aware of it, and take steps to address it.

> 2.2.  Identity Verification
> 
>   The identity provided in the EAP-Response/Identity is not
>   authenticated by EAP-TLS.  Unauthenticated information SHALL NOT be
>   used for accounting purposes or to give authorization.  The
>   authenticator and the EAP server MAY examine the identity presented
>   in EAP-Response/Identity for purposes such as routing and EAP method
>   selection.  They MAY reject conversations if the identity does not
>   match their policy.  Note that this also applies to resumption, see
>   Sections 2.1.2, 5.6, and 5.7.

  That looks good.

> 5.6.  Authorization
> 
>   EAP-TLS may be encapsulated in other protocols, such as PPP
>   [RFC1661], RADIUS [RFC2865], Diameter [RFC6733], or PANA [RFC5191].
>   Systems implementing those protocols interact with EAP-TLS and can
>   make policy decisions and enforce authorization based on information
>   from the EAP-TLS exchange.  The encapsulating protocols can also
>   provide additional, non-EAP information to the EAP server.  This
>   information can include, but is not limited to, information about the
>   authenticator, information about the EAP peer, or information about
>   the protocol layers below EAP (MAC addresses, IP addresses, port
>   numbers, WiFi SSID, etc.).
> 
>   As noted in Section 2.2, the identity presented in EAP-Response/
>   Identity is not authenticated by EAP-TLS and therefore trivial for an

nit:  "therefore is trivial", or "is therefore trivial"

>   attacker to forge, modify, or replay.  Authorization and accounting
>   MUST be based on authenticated information such as information in the
>   certificate or the PSK identity and cached data provisioned for
>   resumption as described in Section 5.7.  Note that the requirements
>   for Network Access Identifiers (NAIs) specified in Section 4 of
>   [RFC7542] still apply and MUST be followed.
> 
>   Policy decisions are often based on a mixture of information from
>   TLS, EAP, and encapsulating protocols.  EAP servers MAY reject
>   conversations based on unauthenticated information such as an unknown

nit: I'd say "based on examining unauthenticated information"

  Otherwise it could be seen as rejecting the session if unauthenticated information *exists*.

>   MAC address or an identity provided in in EAP-Response/Identity that
>   do not match a certain policy.
> 
> 5.7.  Resumption
> 
>   There are a number of security issues related to resumption that are
>   not described in [RFC5216].  The problems, guidelines, and
>   requirements in this section therefore applies to all version of TLS.
> 
>   When resumption occurs, it is based on cached information at the TLS
>   layer.  As described in Section 2.2, the identity provided in the
>   EAP-Response/Identity is not authenticated by EAP-TLS.
> 
>   To perform resumption in a secure way, the EAP peer and EAP server
>   need to be able to securely retrieve information such as certificate
>   chains, revocation status, and other authorization information from
>   the initial full handshake.  We use the term "cached data" to
>   describe such information.  Any authorization applied during
>   resumption MUST be done using this cached data.

  It might be worth mentioning the unauthenticated data here, too.

>   There are two ways to retrieve the needed information.  The first
>   method is that the TLS server and client caches the information
>   locally, identified by an identifier and secured by the other party
>   showing proof-of-position of a key obtained from the initial full
>   handshake.  For TLS versions before 1.3, the identifier can be the
>   session ID, for TLS 1.3, the identifier is the PSK identity.  The
>   second method is via [RFC5077], where the TLS server encapsulates the
>   information into a ticket and forwards it to the client.  The client
>   can subsequently do resumption using the obtained ticket.  Note that
>   the client still need to cache the information locally.  The

nit: "needs"

>   following requirements apply to both methods.
> 
>   If the EAP server or EAP client do not apply any authorization
>   policies, they MAY allow resumption where no cached data is
>   available.  In all other cases, they MUST cache data during the
>   initial full authentication to enable resumption.  The cached data
>   MUST be sufficient to make authorization decisions during resumption.
>   If cached data cannot be retrieved in a secure way, resumption MUST
>   NOT be done.
> 
>   The above requirements also apply if the EAP server expects some
>   system to perform accounting for the session.  Since accounting must
>   be tied to an authenticated identity, and resumption does not supply
>   such an identity, accounting is impossible without access to cached
>   data.
> 
>   Some information such as IP addresses and the identity provided in
>   EAP-Response/Identity may change between the initial full handshake
>   and resumption.  This change creates a "Time of check, time of use"
>   (TOCTOU) security vulnerability.  A malicious or compromised user
>   could supply one set of data during the initial authentication, and a
>   different set of data during resumption, potentially leading to them
>   obtaining access that they should not have.
> 
>   If any authorization, accounting, or policy decisions were made with
>   information that have changed since the initial full handshake and
>   resumption, and if change may lead to a different decision, such
>   decisions MUST be reevaluated.  It is RECOMMENDED that authorization,
>   accounting, and policy decisions are reevaluated based on the
>   information given in the resumption.  EAP servers MAY reject
>   resumption where the information supplied during resumption does not
>   match the information supplied during the original authentication.
>   Where a good decision is unclear, EAP servers SHOULD err on the side
>   of caution, and therefore reject the resumption.
> 
>   Any security policies for authorization and revocation MUST be
>   followed also for resumption.  The EAP client and server MAY need to
>   recheck the authorization and revocation status of the other party.
>   The certificates may have been revoked since the initial full
>   handshake and the authorizations of the other party may have been
>   reduced.

  Very good points, and something I had missed.

>   It is difficult to state the above requirements more precisely.  If
>   the EAP server determine that the user is acting maliciously, they
>   MUST reject the resumption.  It's up to each implementation and / or
>   deploymentment of EAP-TLS to determine which information to examine,
>   and which policies to apply.
> 
> _______________________________________________
> Emu mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/emu