Re: [TLS] [Emu] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

Alan DeKok <> Tue, 05 January 2021 15:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 63B3A3A0E39; Tue, 5 Jan 2021 07:32:45 -0800 (PST)
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 awm9ZMQoOBJp; Tue, 5 Jan 2021 07:32:43 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8B3033A1001; Tue, 5 Jan 2021 07:32:42 -0800 (PST)
Received: from [] ( []) by (Postfix) with ESMTPSA id B722679; Tue, 5 Jan 2021 15:32:39 +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: Tue, 05 Jan 2021 10:32:38 -0500
Cc: Joseph Salowey <>, "" <>, EMU WG <>, Martin Thomson <>, Benjamin Kaduk <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <>
To: Mohit Sethi M <>
X-Mailer: Apple Mail (2.3608.
Archived-At: <>
Subject: Re: [TLS] [Emu] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 05 Jan 2021 15:32:46 -0000

On Jan 5, 2021, at 10:05 AM, Mohit Sethi M <> wrote:
> This sounds reasonable. I was initially hesitant to change because we have working implementations.

  Nothing has been published in an official release.  So we have some time.

  But I'm at the point now where I'd like to release the next version of FreeRADIUS.  We've implemented the current draft.  If there's still uncertainty, then I will disable TLS 1.3 support before the release.  It's better to forbid something than to do it wrong.

> But after a brief glance at the current hostap implementation:; I am convinced that using separate labels for MSK and EMSK is better. The current implementation seems incorrect. 

  IIRC hostap has EAP-TLS working for TLS 1.3.  The PEAP and TTLS patches have not yet been merged.

> About the IV: RFC 5247 (published after RFC 5216) says the following (
>> As a result, its use has been deprecated and it is
>>       OPTIONAL for EAP methods to generate it.  However, when it is
>>       generated, it MUST be unpredictable.
> Should we still export it in EAP-TLS with TLS 1.3?

  I don't recall any uses of it.  

> And the same question for Enc-SEND-Key and Enc-RECV-Key. They are defined in RFC 2548:, but not exported or used in hostap/freeradius implementations. It could be that they are still used by Microsoft but I am unsure?

   I'm not sure what is meant by Enc-SEND-Key.    RFC 2548 Section 2.4.2 defines MS-MPPE-Send-Key.  That and MS-MPPE-Recv-Key are used everywhere in WiFi.  FreeRADIUS and hostap both export and use these fields.

  Removing MS-MPPE-Send-Key and/or MS-MPPE-Recv-Key will destroy global WiFi.

  Alan DeKok.