Re: [Emu] Consensus call on EAP-TLS key derivation

Alan DeKok <> Mon, 10 May 2021 12:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4078F3A1BAD for <>; Mon, 10 May 2021 05:50:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.898
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id izhEV3f1WpV4 for <>; Mon, 10 May 2021 05:50:41 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CFA8A3A1BA9 for <>; Mon, 10 May 2021 05:50:40 -0700 (PDT)
Received: from [] ( []) by (Postfix) with ESMTPSA id 735612C2; Mon, 10 May 2021 12:50:37 +0000 (UTC)
Authentication-Results: NetworkRADIUS; dmarc=none (p=none dis=none)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
From: Alan DeKok <>
In-Reply-To: <>
Date: Mon, 10 May 2021 08:50:35 -0400
Cc: EMU WG <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: Joseph Salowey <>
X-Mailer: Apple Mail (2.3608.
Archived-At: <>
Subject: Re: [Emu] Consensus call on EAP-TLS key derivation
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "EAP Methods Update \(EMU\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 10 May 2021 12:50:45 -0000

On May 9, 2021, at 1:54 PM, Joseph Salowey <> wrote:
> We had discussion on the list on whether to include context in the key derivation, but we never closed on the issue of separating out the MSK and EMSK derivation.  As a result several implementers have gone down the path of implementing what is in draft 13 and not separating out the derivation.  The main difference is that draft 15 separated out the EMSK and MSK derivation using two different labels while draft 13 used a single label to derive key material which is partitioned into two keys.   The reason for the change was to enable different access control for these two different quantities for different callers, however in practice it is EAP-TLS application which needs access to both keys that is the caller of the TLS library so this separation is not particularly useful.   Therefore the recommendation is to align with implementation and derive the MSK and EMSK by partitioning the key material from the key material produced by a single label of the exporter function. 
> Please respond to the list if you support the change below or not to revert some of the text in the key derivation section.  If you object to the change please state why.  Please respond by May 20,2021.

  We should revert to the -13 key derivations.

  Alan DeKok.