Re: [Emu] [TLS] 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: emu@ietfa.amsl.com
Delivered-To: emu@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2600E3A0E17 for <emu@ietfa.amsl.com>; Tue, 5 Jan 2021 08:47:06 -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=unavailable 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 gkYijXhVj5zW for <emu@ietfa.amsl.com>; Tue, 5 Jan 2021 08:47:04 -0800 (PST)
Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com [IPv6:2a00:1450:4864:20::129]) (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 352523A0E12 for <emu@ietf.org>; Tue, 5 Jan 2021 08:47:04 -0800 (PST)
Received: by mail-lf1-x129.google.com with SMTP id b26so74148058lff.9 for <emu@ietf.org>; Tue, 05 Jan 2021 08:47:04 -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=C7X2YgW6fIbKzX58ThJhDy7lUVgKeLU3oDdKbgsqHhAIp0FdGxoJi1/DjOFJcpH1wf /1Ok2ccd/e1R2Qc/jYGK5JY1RX+MtAkXEuhaaOndG7BUOXayq0+bP7PITi0r9KRbvkiB EOcLYU06/v4ozzt0LtEkzNjFcEf8Hqcxa4Vga3UYwAW/gRzoIrh6f2joCfPNbEJcWZwm iTHs1Ewl8Po9pkPxTnYDf7VStxDcSin5BBXdwhhmIjsXDFayuOvFO8vUG9NSasALvqv7 4U7FEuV94ORxpi4/OCx8LVjEztO48QDr7i8NP0xxyS+WuJsQSNUd+TyEoK79EMf9BUJd m/3Q==
X-Gm-Message-State: AOAM530UIEXETBtCRXUjG4ywLKZQ1OmsFv58QcrJLQZVFzAvo+9UCf9H EOQvcSqkcE0eXswWrkUoa5cUrA3u257J3GHi+rXZaw==
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, 05 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/emu/eJUWVUSW5LverMvs_owIz1oGEck>
Subject: Re: [Emu] [TLS] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)
X-BeenThere: emu@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "EAP Methods Update \(EMU\)" <emu.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/emu>, <mailto:emu-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/emu/>
List-Post: <mailto:emu@ietf.org>
List-Help: <mailto:emu-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/emu>, <mailto:emu-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 05 Jan 2021 16:47:06 -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
>