Re: [Emu] Issue 59 - Key Update

Alan DeKok <aland@deployingradius.com> Mon, 12 April 2021 11:58 UTC

Return-Path: <aland@deployingradius.com>
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 B31463A1AAA for <emu@ietfa.amsl.com>; Mon, 12 Apr 2021 04:58:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 XMaDWw3qk7zr for <emu@ietfa.amsl.com>; Mon, 12 Apr 2021 04:58:34 -0700 (PDT)
Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC8DD3A1A7C for <emu@ietf.org>; Mon, 12 Apr 2021 04:58:33 -0700 (PDT)
Received: from [192.168.46.152] (24-52-251-6.cable.teksavvy.com [24.52.251.6]) by mail.networkradius.com (Postfix) with ESMTPSA id E3109317; Mon, 12 Apr 2021 11:58:31 +0000 (UTC)
Authentication-Results: NetworkRADIUS; dmarc=none (p=none dis=none) header.from=deployingradius.com
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
From: Alan DeKok <aland@deployingradius.com>
In-Reply-To: <CAOgPGoA_rFLppfSFLp3-yBq5Vd9Cc4=qY1FTxg3s118Q7qkofQ@mail.gmail.com>
Date: Mon, 12 Apr 2021 07:58:30 -0400
Cc: EMU WG <emu@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <8ED83E4F-68D1-49FB-9328-4B98E691A88A@deployingradius.com>
References: <CAOgPGoA_rFLppfSFLp3-yBq5Vd9Cc4=qY1FTxg3s118Q7qkofQ@mail.gmail.com>
To: Joseph Salowey <joe@salowey.net>
X-Mailer: Apple Mail (2.3608.120.23.2.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/emu/CCVJOBQ82xxparhuknaUmsnRdlI>
Subject: Re: [Emu] Issue 59 - Key Update
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: Mon, 12 Apr 2021 11:58:39 -0000

On Apr 11, 2021, at 10:40 PM, Joseph Salowey <joe@salowey.net> wrote:
> This does seem to require some more specification.  Here is a proposal. 
> 
> "TLS 1.3 introduced the Post-Handshake KeyUpdate message which is not useful and not expected in EAP-TLS.  Implementations SHOULD NOT send a KeyUpdate message.  If a KeyUpdate message is received then an implementation SHOULD ignore the message and it SHOULD NOT send a KeyUpdate message in response."
>
> I think this is better than "implementations MUST NOT send this message and MUST fail upon reception".  The problem here is that the EAP TLS implementation may not have control over this behavior.  

  It looks like key update messages are explicitly requested by either party.  From OpenSSL:

  https://www.openssl.org/docs/man1.1.1/man3/SSL_key_update.html

  If the KeyUpdate message is sent only when requested, it would make sense to forbid sending it.  EAP-TLS has no reason to just randomly change the encryption keys used for TLS.  EAP-TLS is using TLS for authentication, and not for bulk data transfer.

  If the underlying TLS library randomly sends it (or sends it subject to unknown criteria), then the EAP-TLS implementation (peer or authenticator) should be able to detect it via a callback:

https://www.openssl.org/docs/man1.0.2/man3/SSL_set_msg_callback.html

  There appears to be no way for the application to tell the TLS library to ignore the message.

  The safest thing would seem to be:

a) forbidding EAP-TLS implementations from explicitly requesting it

b) noting that TLS libraries may still do key updates

c) noting that EAP-TLS implementations can often detect key updates, and

d) leaving it to the implementation to decide what to do.

  i.e. "We don't know why you'd use it.  But if someone else does use it, and it works, great.  Otherwise, buyer beware".

  Alan DeKok.