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

Joseph Salowey <joe@salowey.net> Tue, 05 January 2021 16:47 UTC

Return-Path: <joe@salowey.net>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A3CA3A101E for <tls@ietfa.amsl.com>; Tue, 5 Jan 2021 08:47:05 -0800 (PST)
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, 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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=salowey-net.20150623.gappssmtp.com
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 K4zWuQIKQKLw for <tls@ietfa.amsl.com>; Tue, 5 Jan 2021 08:47:03 -0800 (PST)
Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A5C83A0E17 for <tls@ietf.org>; Tue, 5 Jan 2021 08:47:02 -0800 (PST)
Received: by mail-lf1-x135.google.com with SMTP id o19so74153597lfo.1 for <tls@ietf.org>; Tue, 05 Jan 2021 08:47:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salowey-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Lt8IffBj/9kNyW3vYQnfdp+5a9CuUZGTWI/7BgzKkr8=; b=XKRHJEzuDmpFyVDJxWyf7l16Us42pFt/3ha8QrnWJk8KreZAmyn8/3njsZ/eS9ZkN8 cxcTXlmpzrMWPAZffvCoOYADfFslU+Vv8FbAROHUqA/3AgjARpTZtwm2St0lA8hW8dgF sSkoyDJIi0GB38GHRCwhlf9IncZQ+qlWBEtzcsEu+DfM2ealn1SV09MatoNbkBElyg9a bjCOu8e/0PgR1U2VrcchdqfxY5INCE+q4jLw9O3/SkKwqPu+2AXjzIxvwTsiHnun4HwN vtA6Gd2bOhVCyTfWWs0Fqr8KL9by+grPHIG0UQAPCjp7iAVrPVKFOx0M64tzjWkhn9o1 WYWQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Lt8IffBj/9kNyW3vYQnfdp+5a9CuUZGTWI/7BgzKkr8=; b=SBsCPNLqbWvy754wogD2uzj/drqSg7wY+hQhyQfIoJx0lalO7V8mTwvfnPFzhzTx2g Xrk5mLMNf9T8hxiQgP/TYU+rgy5aRQ8F9mDZJoVF8apm+Ftevlowj1uH3hAnffVBbNrB v0sFRwdh4mjeBqybxidvDXTQd8ThK0LMFRWF053AWpoZBuPsgkHIiLlrk3EOzj1VvG3M qVBpp0I4sRHPoRyeGfYl3UuFYvPuMV8diOh0oURuiLaztPV2VHHWuri7yPCJqorNtBc0 zYfnd72wFMVP4DuGS/YwlU9Yed/5aGT9dRzKcD0TK+e4w17Yw4hSmdtqRLCR2xybUpEd 3v1Q==
X-Gm-Message-State: AOAM531up/qFqxTOGAVFXpJM7j2ARtDqzCV7NjZCssDkXn4km11+mtm3 dqKIOvSNI1qXFwfkyEY0wryo53w2xHtM2zz3FuWsnw==
X-Google-Smtp-Source: ABdhPJyMkhYybZ5MyaCPrbL864ZgOIL//Ell8nW6CLtPET7o6Cphwne1aMFxedryH+oqHd0MJAbEh9C7ZEizmVuCy2E=
X-Received: by 2002:a2e:9dc1:: with SMTP id x1mr233700ljj.32.1609865220850; Tue, 05 Jan 2021 08:47:00 -0800 (PST)
MIME-Version: 1.0
References: <160815821055.25925.15897627611548078426@ietfa.amsl.com> <20201216223842.GR64351@kduck.mit.edu> <0f2b05db-5c98-43d4-aae3-cf620814bacc@www.fastmail.com> <A4BBA31B-8754-4D8C-B0F1-D1C6C859F6AE@deployingradius.com> <CAOgPGoBvBzhA0q4gFqpFSm2HkAs6NoyLc6RVZYLtTYsNd02i8A@mail.gmail.com> <e669002f-caff-1e6e-e28b-d09157eb0c07@ericsson.com> <6241F0B6-C722-449E-AC3A-183DE330E7B5@deployingradius.com> <9ddd1593-3131-f5cc-d0db-74bf3db697bf@ericsson.com>
In-Reply-To: <9ddd1593-3131-f5cc-d0db-74bf3db697bf@ericsson.com>
From: Joseph Salowey <joe@salowey.net>
Date: Tue, 5 Jan 2021 08:46:49 -0800
Message-ID: <CAOgPGoBZynEYsetFuTmxHkoeBwS9hbwVUHPtAFBeL3924Swr7w@mail.gmail.com>
To: Mohit Sethi M <mohit.m.sethi=40ericsson.com@dmarc.ietf.org>
Cc: Alan DeKok <aland@deployingradius.com>, Mohit Sethi M <mohit.m.sethi@ericsson.com>, EMU WG <emu@ietf.org>, Benjamin Kaduk <kaduk@mit.edu>, "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000a0480705b829f494"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/HFNIz89LsfSM2L3D_fvrOZMf294>
Subject: Re: [TLS] [Emu] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 05 Jan 2021 16:47:05 -0000

On Tue, Jan 5, 2021 at 8:14 AM Mohit Sethi M <mohit.m.sethi=
40ericsson.com@dmarc.ietf.org> wrote:

> Hi Alan,
> Cleaning up the email. The current draft says the exporter should be
> called once as:
>
>    Key_Material = TLS-Exporter("EXPORTER_EAP_TLS_Key_Material",
>                                Type-Code, 128)
>
> and then split the 128 into MSK (64) and EMSK (64). As said, from initial
> glance, it seems the exporter is called twice (once in eap_tls_get_emsk and
> once in eap_tls_getKey). Both the calls are with exactly the same context,
> context length, and labels. In getKey, the EMSK parts are cleared with
>
> os_memset(eapKeyData + EAP_TLS_KEY_LEN, 0, EAP_EMSK_LEN);
>
> while in get_emsk, they are read with
>
> 		os_memcpy(emsk, eapKeyData + EAP_TLS_KEY_LEN,
> 				  EAP_EMSK_LEN);
>
> Maybe we can live with this. But if exporter is called twice, we should
> use different labels as suggested by Martin?
>
> Regarding the Enc-Recv-Key and Enc-Send-Key, you obviously know more. I
> was thrown off by Joe's comment "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 the fact that other EAP methods only export MSK.
> Other EAP methods leave it to the AAA architecture for splitting up the
> MSK. Why should EAP-TLS be different?
>
[Joe] EAP TLS was defined before the keying framework so it
explicitly called out those keys.  Originally, there were RADIUS attributes
for carrying send key and receive key material defined for MPPE.  These
were reused to carry key material when WEP was integrated with 802.1x/EAP.
 With 802.11i and the EAP revision things were made more formal and the MSK
was defined, but the same RADIUS attributes were used for key transport.
Essentially, 802.11i takes the First half of the MSK and uses it as the PMK
for the 4-way handshake, this is transported to the authenticator in the
ms-mppe-recv-key attribute.   The second half of the key is sent in the
ms-mppe-send-key attribute and may be used by some other IEEE
specifications.   Newer attributes have been developed for key transport in
RADIUS over the years.  I don't know their adoption rate at this
point.  THe EMSK was developed as a key that was shared between the AAA
(EAP Server) and supplicant (EAP-Peer) that is not known to the
EAP-Authenticator.   We could leave the definition of how to derive the
receive and send keys from the MSK in the EAP-TLS spec and reference it
from this one.  Or we could just include it.



> --Mohit
> _______________________________________________
> Emu mailing list
> Emu@ietf.org
> https://www.ietf.org/mailman/listinfo/emu
>