Re: [Emu] Minor PR on eap-tls13

Joseph Salowey <joe@salowey.net> Fri, 25 June 2021 00:12 UTC

Return-Path: <joe@salowey.net>
X-Original-To: emu@ietfa.amsl.com
Delivered-To: emu@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01C4B3A308D for <emu@ietfa.amsl.com>; Thu, 24 Jun 2021 17:12:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=salowey-net.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YTu88sFU4ASd for <emu@ietfa.amsl.com>; Thu, 24 Jun 2021 17:12:15 -0700 (PDT)
Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CC3F3A308B for <emu@ietf.org>; Thu, 24 Jun 2021 17:12:15 -0700 (PDT)
Received: by mail-lj1-x22b.google.com with SMTP id r16so10130805ljk.9 for <emu@ietf.org>; Thu, 24 Jun 2021 17:12:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salowey-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=oXGP/vDb18dbHoq6mKj6c72CBrw4eCwHBgo+zodq134=; b=Dr1aWyNK7Z0hVn4XikMWKhmBqAZH+VkAlODuJlmWebrsYudrbPo85LtDVstfnd6E6R IFXUeHRXldoRY6FpdcQ3EQkWDHYTb602Jwh2osSpwO7mrhf+38jAlH1Atk5Vn/nxeKau dDqyjJVEC8cRl2iPNR4bd4qvhnD20RZwdgxJt5nj56EkDGZi5DLWkiFUb8hmOQiPmln3 0exCdwJXhU6i0ZZgLHt7iBZkprxue1+uuS16F4w4QH9u7l2aNFC0FDySeT+qAHh2Z2mk GnrulCWnZQQdZGQbnULhPA/ps9KbfS5ICyKtv8a4LfWjQ69Q+zGZIdPBm1TGf5vh9r5e zHjQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=oXGP/vDb18dbHoq6mKj6c72CBrw4eCwHBgo+zodq134=; b=SXMpK6rvexhZ3f4TUf5p/gZiFKmc3GGeOe8ceMPyjerfSeY0WJNL/Gcz22nACjajN+ ROTF5VYmQcj4b2oJJeAWdlYDR249w8QOusWLWnMKKvrC4EAPP95LsIu68Szadn9Fm5Hk N9ZjikEckqgBNnkvMb35Fzfuau9wfJSvFulcEwUk1RqTFYMfZiQpNRcITeRE3avyKx7C lWOAJKNPtktvaU6KgiZCyYfU6uVKhU2Ej/BttfRZUtA6IIsi8GaNonT7WAKvn0U5eNdU 13e0sfYExkU3q99W2kvv83KE0MnCudG5XzjWKezjh8mzss/XKCDZYKzNGPZ5gHrRjYt8 U+/A==
X-Gm-Message-State: AOAM533kpqOCZhRY3mEr7hujO4CPPdGipVVIdPXrzcw6/+feD3OO7Ej7 CQreTHMxefeZqFjlATkiK1QiVxzcYqpbm0mf1b449Qo1VfUj5w==
X-Google-Smtp-Source: ABdhPJyb/KGn83MPRq2HNw84nXCAtfCKZ4TywBf9jMoJSgicedS005bgjMMPyuu+qiO73p9U8A2yVHCLxxTK96F1Ngs=
X-Received: by 2002:a2e:9cc3:: with SMTP id g3mr5875833ljj.366.1624579928619; Thu, 24 Jun 2021 17:12:08 -0700 (PDT)
MIME-Version: 1.0
References: <784048A1-DFF5-4D84-8468-9A8C97C0DEA7@deployingradius.com> <CAOgPGoAdTc6FW9Zg17WpckpSY-EBaCkZT_Pd--WKXb4nQ56BvA@mail.gmail.com>
In-Reply-To: <CAOgPGoAdTc6FW9Zg17WpckpSY-EBaCkZT_Pd--WKXb4nQ56BvA@mail.gmail.com>
From: Joseph Salowey <joe@salowey.net>
Date: Thu, 24 Jun 2021 17:11:57 -0700
Message-ID: <CAOgPGoDP6oWSCrdTBHWv7tL=uRdXkOgj=YRTmDx3CitVCFbONQ@mail.gmail.com>
To: Alan DeKok <aland@deployingradius.com>
Cc: EMU WG <emu@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000008e115d05c58bfd61"
Archived-At: <https://mailarchive.ietf.org/arch/msg/emu/PBO_K3x_66exDur7GUYn5G41Ssw>
Subject: Re: [Emu] Minor PR on eap-tls13
X-BeenThere: emu@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "EAP Methods Update \(EMU\)" <emu.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/emu>, <mailto:emu-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/emu/>
List-Post: <mailto:emu@ietf.org>
List-Help: <mailto:emu-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/emu>, <mailto:emu-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 25 Jun 2021 00:12:21 -0000

On Thu, Jun 24, 2021 at 4:43 PM Joseph Salowey <joe@salowey.net> wrote:

>
>
> On Tue, Jun 22, 2021 at 6:02 AM Alan DeKok <aland@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
>>
>