Subject: [Emu] Minor PR on eap-tls13

From: Alan DeKok <[email-masked]>
Date: Tue, 22 Jun 2021 09:02:36 -0400

https://github.com/emu-wg/draft-ietf-emu-eap-tls13/issues/86

  I didn't see anything on cross-protocol use of certs.

  i.e. Section 2.2 suggests that the certs contain an FQDN.  But it's likely bad practice to allow the same cert to be used for EAP, and for WWW.

  There's some suggested text forbidding this behavior.

  I would have expected similar text to be part of RFC 8446, but I couldn't find anything relevant.

---

5.11 Certificate Reuse

Certificates used for EAP-TLS MUST NOT be used in any other protocol besides EAP. Section 2.2 above suggests that certificates typically have one or more FQDNs in the SAN extension. However, those fields are for EAP validation only, and do not indicate that the certificates are suitable for use on WWW (or other) protocol server on the named host.

Allowing the same certificate to be used in multiple protocols would possibly allow for an attacker to authenticate via one protocol, and then "resume" that session in another protocol. Section 5.7 above suggests that authorization rules should be re-applied on resumption, but does not mandate this behavior. As a result, this cross-protocol resumption could allow the attacker to bypass authorization policies, and toobtain undesired access to secured systems. The simplest way to prevent this attack is to forbid the use of the same certificate across multiple protocols.

---

From: Joseph Salowey <[email-masked]>
Date: Thu, 24 Jun 2021 16:43:03 -0700

On Tue, Jun 22, 2021 at 6:02 AM Alan DeKok <[email-masked]>
wrote:

>   i.e. Section 2.2 suggests that the certs contain an FQDN.  But it's
> likely bad practice to allow the same cert to be used for EAP, and for WWW.
>
> Certificates used for EAP-TLS MUST NOT be used in any other protocol
> besides EAP. Section 2.2 above suggests that certificates typically have
> one or more FQDNs in the SAN extension. However, those fields are for EAP
> validation only, and do not indicate that the certificates are suitable for
> use on WWW (or other) protocol server on the named host.
>
> Allowing the same certificate to be used in multiple protocols would
> possibly allow for an attacker to authenticate via one protocol, and then
> "resume" that session in another protocol. Section 5.7 above suggests that
> authorization rules should be re-applied on resumption, but does not
> mandate this behavior. As a result, this cross-protocol resumption could
> allow the attacker to bypass authorization policies, and toobtain undesired
> access to secured systems. The simplest way to prevent this attack is to
> forbid the use of the same certificate across multiple protocols.
>

My comment is that we should mark this as cross protocol attacks.  We
should consider a separate work item to define ALPN for EAP-TLS.  Here is a
revision to Alan's suggestion as section "5.11 Cross-Protocol attacks" or
perhaps an addition to 5.7

"Section 2.2  suggests that certificates typically have one or more FQDNs
in the SAN extension. However, those fields are for EAP validation only,
and do not indicate whether the certificates are suitable for use with
another protocol server on the named host. If the same certificate and the
resumption cache is usable in EAP-TLS and another protocol an attacker
could authenticate via one protocol, and then "resume" that session in
another protocol.

Section 5.7 above suggests that authorization rules should be re-applied on
resumption, but does not mandate this behavior. As a result, this
cross-protocol resumption could allow the attacker to bypass authorization
policies, and to obtain undesired access to secured systems. Along with
making sure that appropriate authorization information is available and
used during resumption, using different certificates and resumption caches
for different protocols is RECOMMENDED to help keep different protocol
usages separate."

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

---

From: Joseph Salowey <[email-masked]>
Date: Thu, 24 Jun 2021 17:11:57 -0700

On Thu, Jun 24, 2021 at 4:43 PM Joseph Salowey <[email-masked]> wrote:

> Section 5.7 above suggests that authorization rules should be re-applied
> on resumption, but does not mandate this behavior. As a result, this
Actually, PR#83 removes the MAY that makes the authorization behavior on
resumption optional.  Do you still think we need to add this text to
section 5.7?

---

From: Alan DeKok <[email-masked]>
Date: Mon, 28 Jun 2021 08:58:24 -0400

On Jun 24, 2021, at 8:11 PM, Joseph Salowey <[email-masked]> wrote:
> Actually, PR#83 removes the MAY that makes the authorization behavior on resumption optional.  Do you still think we need to add this text to section 5.7?

 No, we can leave it as-is.

  Alan DeKok.