On Thu, Jun 24, 2021 at 4:43 PM Joseph Salowey <j...@salowey.net> wrote:
> > > On Tue, Jun 22, 2021 at 6:02 AM Alan DeKok <al...@deployingradius.com> > wrote: > >> 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. >> > > 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." > > > 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? > > > >> _______________________________________________ >> Emu mailing list >> Emu@ietf.org >> https://www.ietf.org/mailman/listinfo/emu >> >
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu