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

From: John Mattsson <[email-masked]>
Date: Mon, 11 Mar 2019 16:52:25 +0000

Hi,

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

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.

The text below is what I plan to submit at midnight UTC time. I there are comments before that, I can try to update the text, otherwise we can work on the text in the coming weeks before Prague.

Cheers,
John

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.

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

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

   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.

---

From: Alan DeKok <[email-masked]>
Date: Mon, 11 Mar 2019 13:16:09 -0400

> - 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 th…

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

>   Sections 2.1.2, 5.6, and 5.7.

  That looks good.

>   Identity is not authenticated by EAP-TLS and therefore trivial for an

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

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

>   resumption MUST be done using this cached data.

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

>   the client still need to cache the information locally.  The

nit: "needs"

>   handshake and the authorizations of the other party may have been

  Very good points, and something I had missed.

> _______________________________________________
> Emu mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/emu