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

From: John Mattsson <[email-masked]>
Date: Fri, 22 Feb 2019 07:46:25 +0000

Alan DeKok <[email-masked]>;; wrote:

 >This security bug was completely missed in RFC 5216.  This new draft should rectify that error.
>
 >i.e. using an NAI of "example.org" in the first session, and "example.com" in the second session.
>
 >Not only is this entirely permitted by the current spec, it's not even discussed as an issue.  And it means that the protocol is open to a large number of time of use, time of check" security bugs which could cause serious breaches of networks.

I think Section 2.2 of RFC 5216 do discuss this issue, but it does not explicitly mention resumption. The text is also too soft. 

----------------
 2.2.  Identity Verification

   As noted in Section 5.1 of [RFC3748]:

      It is RECOMMENDED that the Identity Response be used primarily for
      routing purposes and selecting which EAP method to use.  EAP
      Methods SHOULD include a method-specific mechanism for obtaining
      the identity, so that they do not have to rely on the Identity
      Response.

   As part of the TLS negotiation, the server presents a certificate to
   the peer, and if mutual authentication is requested, the peer
   presents a certificate to the server.  EAP-TLS therefore provides a
   mechanism for determining both the peer identity (Peer-Id in
   [KEYFRAME]) and server identity (Server-Id in [KEYFRAME]).  For
   details, see Section 5.2.

   Since the identity presented in the EAP-Response/Identity need not be
   related to the identity presented in the peer certificate, EAP-TLS
   implementations SHOULD NOT require that they be identical.  However,
   if they are not identical, the identity presented in the EAP-
   Response/Identity is unauthenticated information, and SHOULD NOT be
   used for access control or accounting purposes.
----------------

Suggestion to add to Section 2.2 of EAP-TLS 1.3

"The identity presented in the EAP-Response/Identity is unauthenticated information, and SHALL NOT be used for access control or accounting purposes. Note that this also applies to resumption."

/John

---

From: Alan DeKok <[email-masked]>
Date: Fri, 22 Feb 2019 07:51:15 -0500

> I think Section 2.2 of RFC 5216 do discuss this issue, but it does not explicitly mention resumption. The text is also too soft. 

  I think that section discusses an entirely different issue, that has nothing to do with resumption.

> "The identity presented in the EAP-Response/Identity is unauthenticated information, and SHALL NOT be used for access control or accounting purposes. Note that this also applies to resumption."

  This text means that resumption is impossible in all practical networks.

  Why?  Because the user was originally authenticated via the credentials they provide: the certificate.  As per Section 2.2, any policies applied to that user are applied based on those credentials.

  When resumption happens, those credentials are not supplied.  The only ID provided is the EAP-Response/Identity, which systems are forbidden from trusting.

  So we now have resumption where we don't know the identity of who is resuming.  We don't know what policies were applied to them previously.  We don't know what policies to apply to them now.

  Therefore, any *practical* resumption is impossible.

  In my opinion, the document MUST give guidance for implementors and site administrators:

* if resumption is used, the implementation MUST cache sufficient information for the system to make appropriate policy decisions on resumption

* resumption MUST be rejected if no cached information is available, as we have no idea what policies to apply

* the document MUST discuss the use of EAP-TLS in other protocols such as PPP, PANA, RADIUS, and Diameter.  Just a mention that they exist is fine.

* These protocols MAY carry additional information about the user and/or the machine involved.    e.g. MAC, switch IP, port, etc.

* When systems make policy decisions on that additional information, the systems MUST be aware that the additional information can be different between the original authentication and any resumption

* This difference creates a "Time of check, time of use" (TOCTOU) security issue with the policies.  i.e. The user can leverage the TOCTOU issue to get one policy applied for the original authentication, and a different policy applied for resumption.

* That difference allows users to exploit the system, and get access that they should not have.

* Implementations SHOULD add such information to the above cache for the session, so they can look for discrepancies between the original authentication and resumption

* where there are discrepancies, the resumption SHOULD be rejected.

  I don't understand why there's so little concern about people being able to PWN your network.  It's a disaster.

  We can't just paper over this issue.  It's a major security flaw that's designed into the protocol.  It needs to be addressed.

  Alan DeKok.

---

From: Arran Cudbard-Bell <[email-masked]>
Date: Sat, 23 Feb 2019 08:47:01 +0800

> * if resumption is used, the implementation MUST cache sufficient information for the system to make appropriate policy decisions on resumption

Maybe something about not relying on the outer identity to apply any kind of autz policies?  Administrators may assume some kind of binding between the outer identity, the original session, and the resumed session, and assume it'll be consistent. In reality the user can provide any outer identity they like.

I know this is covered by the above point, but I feel it's worth documenting this case explicitly.

> * resumption MUST be rejected if no cached information is available, as we have no idea what policies to apply

I'd argue if cached information is expected and non is available, resumption MUST be rejected.  For the majority of cases the security policies applied to the different TLS based EAP methods will be identical.

I agree with the rest of the points.

-Arran

---

From: Alan DeKok <[email-masked]>
Date: Sat, 23 Feb 2019 14:14:51 -0500

> Maybe something about not relying on the outer identity to apply any kind of autz policies?  Administrators may assume some kind of binding between the outer identity, the original session, and the…

  Yes.  The NAI document discusses this situation:

https://tools.ietf.org/html/rfc7542#section-4.2

  That discussion unfortunately doesn't discuss resumption.

> I know this is covered by the above point, but I feel it's worth documenting this case explicitly.

  Yes.  An explicit reference to the above section would help.

> I'd argue if cached information is expected and non is available, resumption MUST be rejected.  For the majority of cases the security policies applied to the different TLS based EAP methods will b…

  Yes, that has to happen, too.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Tue, 26 Feb 2019 12:29:16 -0500

Here's my $0.02 on updates to the "Security Considerations" section.

---
5.9.  Authorization

   We note that EAP-TLS may be encapsulated in other protocols, such as
   PPP [RFC1661], RADIUS [RFC2865], Diameter [RFC6733], or PANA
   [RFC5191].  Systems implementing those protocols can make policy
   decisions, and can enforce authorization based on information from
   the EAP-TLS exchange.  As such, we need to discuss interactions
   between those protocols and EAP-TLS.  For generality, we state
   requirements on EAP servers, instead of updating those other
   protocols.

   As noted in Section 2.2, above, the EAP-Response / Identity is
   unauthenticated.  EAP servers therefore MUST NOT make policy decisions based on
   that identity.  Instead, where they make policy decisions, EAP
   servers MUST base those decisions on authenticated identities, such
   as information from the client certificate, or from the PSK identity
   provisioned for resumption, or from other cached information as
   described in the next section.

   We note that this requirement does not over-ride the requirements
   given in [RFC7542] Section 4.  EAP servers which use the NAI format
   necessarily also MUST follow the requirements of the NAI
   specification.

   In order to implement the requirements of [RFC7542], EAP servers MAY
   examine the EAP-Response / Identity field, and reject authentication
   if they determine that the field is in any way unsuitable.

   In short, EAP servers MUST NOT authorize sessions based the EAP-
   Response / Identity field.  The field is untrusted, and may be
   trivially forged.

5.10.  Resumption

   There are a number of security issues related to resumption.
   [RFC516] is unfortunately silent on this topic, so we discuss this
   issue in detail here.  We note that the problems outlined here are
   also relevant to earlier versions of TLS.  The solutions are also
   similar.

   When resumption occurs, it largely occurs based on the cached TLS
   data, at the TLS layer.  The only credentials supplied during this
   resumption are the EAP-Response/Identity.  However, as noted above in
   Section 2.2, the identity presented in the EAP-Response/Identity is
   unauthenticated information, and SHALL NOT be used for access control
   or accounting purposes. Note that this also applies to resumption.

   This requirement gives us a conundrum.  We have a successful
   resumption, but we have no idea what identity is being used in that
   resumption.  We are thus unable to apply any authorization to that
   authentication request.  Since we have no way to authorize the user,
   the only secure step we can take is to reject the session.  This
   rejection removes any possibility of resumption.

   The solution to this conundrum is to associate authentication
   credentials and authorization information with the original
   authentication.  That information can then be obtained and applied
   during resumption.

   There are two ways to make this association.  The first method is via
   [RFC5077], where the TLS server encapsulates the session state into a
   ticket and forwards it to the client.  The client can subsequently
   resume a session using the obtained ticket.  The second method is
   where the TLS server caches information about the TLS session, based
   on a unique key.  For TLS versions before 1.3, this key can be the
   session ID.  For TLS 1.3, this key is the unique PSK identity.

   The following requirements apply to both methods of associating
   additional data with the TLS session.  For simplicity, we use the
   term "cached data" to mean any authentication credentials or
   authorization information that has been associated with the TLS
   session via either session tickets, or via caching on the TLS server.

   Where the EAP server applies no authorization policies to TLS
   sessions, it MAY allow resumption where no cached data is available.
   That is, if no policies are applied during the original
   authentication, it is acceptable to not apply policies during any
   resumption.

   In all other cases, the EAP server MUST cache data during the
   original authentication.  This cached data MUST be sufficient to make
   authorization decisions during session resumption.  Where this cached
   data is unavailable, the resumption MUST be rejected, as no policies
   can be meaningfully applied.

   Any authorization applied during resumption MUST be done using the
   cached data, and MUST NOT be done by examining the EAP-Response /
   Identity that was supplied during resumption.  As noted earlier, that
   identity is unauthenticated and therefore insecure.

   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.

   As discussed in the previous section, EAP-TLS may be carried inside
   of another protocol.  This encapsulation creates further security
   issues with resumption.

   These encapsulating protocols can provide additional, non-EAP
   information to the EAP server.  This information can include, but is
   not limited to, the following data:

   * MAC address of the EAP peer * IP address of the EAP peer *
   Informtion about the ethernet switch to which the EAP peer is
   connecting
      * MAC address of the switch
      * IP address of the switch
      * switch port used by the EAP peer
   * Wifi SSID
   * Information about the ethernet layer used by the EAP peer

   The EAP server also has access to the cached EAP-Response / Identity
   from the original authentication.

   None of these fields are authenticated or secured.  As a result, any
   or all of these fields can change between the original
   authentication, and resumption.  This change creates a "Time of
   check, time of use" (TOCTOU) security vulnerability.  A malicious
   user could supply one set of data during authentication, and a
   different set of data during resumption.  The malicious user could
   then obtain different authorization during resumption, potentially
   leading to them obtaining access that they should not have.

   When EAP servers make policy decisions based on unauthenticated
   information, they MUST then add that information to the cached data
   described above.  This cached information MUST be used as part of any
   policy decision or authorization made for resumption.  That
   requirement allows the EAP peer to potentially obtain the same
   authorization as for the original session.  The requirement also
   ensures that where accounting is needed, the resumption is correctly
   accounted for via the original authentication credentials.

   The new information given during resumption SHOULD also be used as
   part of any policy decision or authorization made for 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.

   It is difficult for us to state the above requirement more precisely
   than the above.  We cannot require that the resumption be rejected in
   all cases.  For example, it may be permissible for a user to change
   switch ports, and still use resumption.  It may be permissible for
   for the user to request additional authorization during resumption.

   Where EAP servers determine that the user is acting maliciously, they
   MUST reject the resumption.

   We can unfortunately provide little additional guidelines here.  It
   is up to each implementation and / or deploymentment of EAP-TLS to
   determine which information to examine, and which policies apply.