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

Joseph Salowey <> Tue, 05 January 2021 06:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 327BE3A086D for <>; Mon, 4 Jan 2021 22:44:58 -0800 (PST)
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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id rA9KSB0SMzyh for <>; Mon, 4 Jan 2021 22:44:56 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::136]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2A3053A0876 for <>; Mon, 4 Jan 2021 22:44:56 -0800 (PST)
Received: by with SMTP id s26so70101445lfc.8 for <>; Mon, 04 Jan 2021 22:44:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=EvGGSU8Nvt+iE7j4EQaT6AFIj7w0TKGDskqlSq+DJS8=; b=QCRpVRQ0ojJB7eoXyG10YP8WjgoVTQJqxxlrxGLw7sepcroJNixYhnrcivyEx45/Q/ 5olPYXTRMWnIPtU7FIIRtEi5z7BSqngnCziy78JbbBrDSFFIEY+Bnroxp7l8hYWESRia UUn7rkv4f6H9Fjs97duMtDeEvhoQt6gY3SiXqxiQIr3YRuydrS4S4sXf1VTmta1O1oRI laMZkHZylBzRadMRVxha04B17RkQcUSNlRMXq8uau+buefYmuorAFua7y5/umwpkBEnf Oy+Z4AxgMKGOBf1YQwsRcZMjKb/J0eaj5G5zE7eQG5397LbW4qcPJoM8+jfPOkWqIB1d /M/w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=EvGGSU8Nvt+iE7j4EQaT6AFIj7w0TKGDskqlSq+DJS8=; b=nT/ulSgXO7ibqsqXpNRd2XwUqOPV43jo/B4No4/e2DQyawBIcuSCi9M5DGM16CWzKG 9CeoJdMSbR1MYKJ3Jjw8Hzvf6fHNtIgpXm2iQsU25YwtUog+dmXjFSnHzE8vf67l01Pv XQX7JZ8fkviDraJgS528m8SMaZ7U0uM2R4KuMoTYBQcpmhtbnguLSVB/pDa1zitlTKSt rjLFncylH+0sKRKAdtVZYn9xR7DaV03ohDzA1v0WNfzvbNWfwOAH/U/Jm8PbIezFLrhs rq2FD9Gu1bEVhwf+T1pgqa4bbSMGQaeu5maBw6rOt0ujO8bu5mdvQJljT2H3cddwSHXK yQFg==
X-Gm-Message-State: AOAM532ggTM3D9zfkjh4Vvs3F5vw3I/btJIcstUBRGNGole/PZLFQish /tGzjj/4ev7LabgfHMlsrCWxm4QU9jlvr3ON0DRuYw==
X-Google-Smtp-Source: ABdhPJw2y5qfXBAYEIprZv+N761N8QPI13aHnkhlfafOdBERvnHYtp9nNqGPyCrf7kVvnTK4ym2pk2h3Iuunbcu4vT0=
X-Received: by 2002:a19:4907:: with SMTP id w7mr19879410lfa.198.1609829094071; Mon, 04 Jan 2021 22:44:54 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
From: Joseph Salowey <>
Date: Mon, 04 Jan 2021 22:44:42 -0800
Message-ID: <>
To: Alan DeKok <>
Cc: Martin Thomson <>, EMU WG <>, Benjamin Kaduk <>, "<>" <>
Content-Type: multipart/alternative; boundary="0000000000004d353905b8218b18"
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 06:44:58 -0000

On Mon, Jan 4, 2021 at 6:08 AM Alan DeKok <> wrote:

> On Jan 3, 2021, at 10:44 PM, Martin Thomson <> wrote:
> > # Key Schedule
> >
> > The other thing I observe is the way that this slices up the exporter
> output.  This was something that old versions of TLS did, but TLS 1.3 did
> away with.  Though RFC 5216 did this, EAP-TLS for TLS 1.3 doesn't need to.
> This could - and should - do the same.  All it means is having more
> exporter labels.
>   That's easy enough to change at this state.  The question is what are
> those labels?

  And, we're getting very close to needing an implementation soon.  RFC
> 8446 is over two years old.  Web services have started serious migration to
> TLS 1.3.  But we still don't even have a standard for EAP.  I suggest that
> this is an issue.
>   At this point, we have inter-operability of TLS 1.3 for EAP-TLS, with
> the major EAP peer / server implementations.  This code is alpha, and not
> in any major release.  But we need to decide fairly soon what we're doing,
> as testing and releases take time.
>   The alternative is to dither around for another year or two, all the
> while relying on legacy TLS versions for 802.1X / WiFi authentication.
> i.e. packets which are trivially monitored by anyone with a WiFi card.
> > I appreciate that this uses exporters now rather than abusing the
> internal PRF.  That's good.  The next step is to dispense with the
> intermediate values (Key_Material, MSK, EMSK, IV) and all the slicing that
> occurs and use the TLS exporter for each of the six values that the
> protocol requires.  I also note that the 0x0D value is used multiple times,
> unnecessarily, both as a context strong to the exporter and as a prefix to
> the session ID.
>   If EAP-TLS was the only TLS-based EAP method, I would agree with you.
> But it's not.  Historically, each TLS-based EAP method uses it's own key
> derivations, using method-specific strings.  This practice made
> implementations more difficult and error-prone.

[Joe] It may be worth having separate exporter tags for EMSK and MSK.
and EXPORTER_EAP_TLS_EMSK).   I believe current applications define the use
EAP key material based on the MSK or EMSK.   The mechanism for splitting
the MSK into Enc-RECV-Key and Enc-SNED-Key I believe is only used in
specific legacy cases (WEP, MPPE?) and may still be the radius attributes
used in some deployments, so I don't think we should alter that
derivation.   I'm not sure where the IV is used, but I don't think
splitting it up more will be helpful.

>   The use of 0x0D is to allow standard key derivations across TLS-based
> EAP methods.  The other methods replaced the 0x0D byte with their own EAP
> type value.  This practice greatly simplifies implementations.
>   See for
> more information.
>   Alan DeKok.
> _______________________________________________
> Emu mailing list