Re: [Emu] WG Last Call for Using EAP-TLS with TLS 1.3

Alan DeKok <> Fri, 07 May 2021 22:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E7BD53A0991 for <>; Fri, 7 May 2021 15:02:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 f5feiabJTk6V for <>; Fri, 7 May 2021 15:02:25 -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 C9BDD3A34F8 for <>; Fri, 7 May 2021 15:00:37 -0700 (PDT)
Received: from [] ( []) by (Postfix) with ESMTPSA id 455BC167; Fri, 7 May 2021 22:00:35 +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: Fri, 7 May 2021 18:00:33 -0400
Cc: Jorge Vergara <>, EMU WG <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <>
To: Joseph Salowey <>
X-Mailer: Apple Mail (2.3608.
Archived-At: <>
Subject: Re: [Emu] WG Last Call for Using EAP-TLS with TLS 1.3
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: Fri, 07 May 2021 22:02:31 -0000

On May 7, 2021, at 5:18 PM, Joseph Salowey <> wrote:
> [Joe] I think the one issue that was raised during TLS review was that using the same label for MSK and EMSK could make it more difficult to separate out the derivations of these keys at the TLS level.  For example, example, perhaps the TLS implementation could restrict access to the MSK and EMSK independently depending upon hte caller.

  I'll have to think about that a little more before I understand the underlying objection.

  From what I can see, MSK and EMSK are specific to EAP-TLS.  They are derived in the EAP-TLS application, by passing EAP-TLS parameters to TLS key exporters.

  So the TLS layer has no concept of what MSK or EMSK are.  As a result, the TLS layer should have minimal input into what those keys are, or how they are derived.

  Alan DeKok.