Subject: [Emu] draft-ietf-emu-eap-tls13-11: Updates RFC 5216

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 21 Oct 2020 09:00:49 +0000

Hi all,

the draft says it updates the earlier EAP-TLS version and claims that the updates are related to

* Section 5.6 Authorization
* Section 5.7 Resumption

The content of Section 5.6 actually does not relate to EAP-TLS but is generic to all EAP methods. I don't think it even belongs in an EAP method document.

The content of Section 5.7 claims that there are aspects of resumptions that are not described in the earlier version of EAP-TLS. The focus is then on the way how the cached data is stored, an implementation-specific aspect, that is not specific to EAP-TLS because the concept of caching is used by other EAP methods too. Then, there is a threat presented whereby the authorization information changes between the full handshake and the resumption handshake. I believe that this is not a threat that is unique to EAP-TLS because this can happen even when there is no resumption. Nothing prevents you from checking authorization again when you do resumption though and even during an ongoing session. I would argue that there is a lot of text in there that has nothing to do with EAP-TLS but rather concerns the whole system in which EAP is used. If this is indeed a problem, I believe it should be covered in a separate document. I don't think it is a problem because extensions for RADIUS and Diameter have been developed to address this issue to revoke authorization during the lifetime of a session.

Here is where it gets confusing. The introduction says "This document defines how to use EAP-TLS with TLS 1.3 (or higher) and does not change how EAP-TLS is used with older versions of TLS." To me, this does not sound like an update.

Reading more carefully one can notice that the actual update to EAP-TLS is hidden in Section 5.8 "Privacy Considerations" and Section 5.10 "Discovered Vulnerabilities".

Section 5.8 says:
"
   it is RECOMMENDED for EAP peers to not use EAP-TLS with
   TLS 1.2 and static RSA based cipher suites without privacy.  This
   implies that an EAP peer SHOULD NOT continue the handshake if a TLS
   1.2 EAP server responds to an empty certificate message with a TLS
   alert message.
"

Section 5.10 says:
"
EAP-TLS implementations
   SHOULD mitigate known attacks and follow the recommendations in
   [RFC7525] and [I-D.ietf-tls-oldversions-deprecate].
"

Interestingly, RFC 7525 does not talk about EAP (and instead focuses on applications like  HTTP, SMTP, IMAP, POP, SIP, and XMPP, as noted in the abstract). RFC 7525, for example, does not mandate OCSP. It also recommends RSA, which draft-ietf-emu-eaptlscert and this draft does not do. There seems to be contradiction here.

At a minimum, I would clarify in the introduction what the updates to RFC 5216 are. This will help those implementers that focus on a variant of EAP-TLS that uses version 1.2. As mentioned above, I don't believe Sections 5.6 and 5.7 belong to this document. Leave it in there if someone in the group gets paid by the number of published pages.

Ciao
Hannes
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

---

From: Alan DeKok <[email-masked]>
Date: Wed, 21 Oct 2020 09:35:55 -0400

> The content of Section 5.6 actually does not relate to EAP-TLS but is generic to all EAP methods. I don't think it even belongs in an EAP method document.

  The second paragraph is generic to all EAP methods.  But it's explanatory, and doesn't offer specific security advice.

  The third paragraph is relevant to EAP-TLS, even if the first part true for all EAP methods.  However, the second part refers to the PSK used for resumption, and is specific to EAP-TLS.  As such, I believe that the text should stay.  

> The content of Section 5.7 claims that there are aspects of resumptions that are not described in the earlier version of EAP-TLS. The focus is then on the way how the cached data is stored, an implementation-specific aspect, that is not specific to EAP-TLS because the concept of caching is used by other EAP methods too.

  That's nice, but I don't recall any other document which discusses cached data with respect to EAP.  Since we're updating EAP-TLS here, I think it's relevant.

  i.e. if we could refer to another document, that would be preferred.  Since no other document exists, we need to discuss security considerations with respect to EAP-TLS.  Even if the discussion is _also_ relevant to non-TLS EAP methods.

> Then, there is a threat presented whereby the authorization information changes between the full handshake and the resumption handshake. I believe that this is not a threat that is unique to EAP-TLS because this can happen even when there is no resumption.

  Yes.

  However, the identity used for authentication changes when doing resumption.  This change means that authorization based on identities is more difficult than with "normal" authentication.  As such, there are attacks unique to resumption which must be mitigated.

  Perhaps this point could be made more clear.  i.e. instead of the focus being on cached data, the focus could be on changing identities, and how cached data can help detect and address that change.

> Nothing prevents you from checking authorization again when you do resumption though and even during an ongoing session. I would argue that there is a lot of text in there that has nothing to do with EAP-TLS but rather concerns the whole system in which EAP is used. If this is indeed a problem, I believe it should be covered in a separate document.

  Given the time frame and the need to update EAP-TLS for TLS 1.3, I disagree.  It is a problem, and it should be addressed here.

> I don’t think it is a problem because extensions for RADIUS and Diameter have been developed to address this issue to revoke authorization during the lifetime of a session.

  This document should give guidance on how to implement EAP-TLS securely.  RADIUS and Diameter don't help with issues such as the identity changing for resumption.

> Here is where it gets confusing. The introduction says "This document defines how to use EAP-TLS with TLS 1.3 (or higher) and does not change how EAP-TLS is used with older versions of TLS." To me,…

 It doesn't not change earlier versions of EAP-TLS.  But it gives new guidance.  Perhaps this could be clearer.

> At a minimum, I would clarify in the introduction what the updates to RFC 5216 are. This will help those implementers that focus on a variant of EAP-TLS that uses version 1.2.

  I agree.

> As mentioned above, I don't believe Sections 5.6 and 5.7 belong to this document. Leave it in there if someone in the group gets paid by the number of published pages.

  Or if the authors wish to give practical, timely, advice to implementors of EAP-TLS.

  Alan DeKok.

---

From: Mohit Sethi M <[email-masked]>
Date: Sat, 31 Oct 2020 17:06:03 +0000

Hi Hannes,

This text and guidance was specifically requested by working group members like Alan. Unless the text is wrong, I don't see any point in removing it. Other TLS-based EAP methods are obviously free to use parts of this text relevant to them. Note that their resumption and authorization might be even more complex as some decisions may depend on the inner authentication method.

--Mohit

On 10/21/20 12:00 PM, Hannes Tschofenig wrote:
Hi all,

The content of Section 5.7 claims that there are aspects of resumptions that are not described in the earlier version of EAP-TLS. The focus is then on the way how the cached data is stored, an implementation-specific aspect, that is not specific to EAP-TLS because the concept of caching is used by other EAP methods too. Then, there is a threat presented whereby the authorization information changes between the full handshake and the resumption handshake. I believe that this is not a threat that is unique to EAP-TLS because this can happen even when there is no resumption. Nothing prevents you from checking authorization again when you do resumption though and even during an ongoing session. I would argue that there is a lot of text in there that has nothing to do with EAP-TLS but rather concerns the whole system in which EAP is used. If this is indeed a problem, I believe it should be covered in a separate document. I don’t think it is a problem because extensions for RADIUS and Diameter have been developed to address this issue to revoke authorization during the lifetime of a session.

Section 5.8 says:
"

Section 5.10 says:
"
EAP-TLS implementations

Ciao
Hannes

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