On Thu, Jun 24, 2021 at 4:43 PM Joseph Salowey wrote:
>
>
> On Tue, Jun 22, 2021 at 6:02 AM Alan DeKok
> 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
