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

Mohit Sethi M <mohit.m.sethi@ericsson.com> Fri, 08 January 2021 07:54 UTC

Return-Path: <mohit.m.sethi@ericsson.com>
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 C75953A10B7 for <tls@ietfa.amsl.com>; Thu, 7 Jan 2021 23:54:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.613
X-Spam-Level:
X-Spam-Status: No, score=-2.613 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.25, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.262, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 9AmuyPiPPp83 for <tls@ietfa.amsl.com>; Thu, 7 Jan 2021 23:54:27 -0800 (PST)
Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80051.outbound.protection.outlook.com [40.107.8.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E03253A10BA for <tls@ietf.org>; Thu, 7 Jan 2021 23:54:26 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=W2Fp1EGS7CXI100Tzwv1SayLsuVRxeRN0c2q9goN3qusQ0EsQ+VhuB3hFbi7TM9WFIaaJIaBOJS3Jfo9Prh5vGyIk5ubwaF1AOwHB4U76V0rzEdp3V4/LFU+VQV3KGs6/wbtRahfqE1uY4BdcNuhWL+puEx24mo/pxKY5R5SzY5e0Wyl8ayfjAFRr49US0VBXxap3U1EhKIXEBl6rrQEz0ZQWSgAuvpdt5b62FqJbhE7Ri0i5uQnQewWvn529OIoYhqHKAGcpz131NUg+VMLX/gYKjqqRT9Bv4e2XwNHhL3vdWzc2QXQi85tSHunZC6exPu3s2XR3twmgmQP3Zqtzw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=kIGY/rvSraLtUtyPytxUcrMFz7vTxW0iIE3RGGMILg8=; b=Jlv/XRAQ3z6YXDZIQyoZhdTo3X/kLM2Ksi9Pq9w772yeCgWxlUMvU6MKIAMFOa2eGV9Tgzl2bJ7pXLZHDObeh4ea6eZq5x6c8utmWLm+WwYWPZQwLGbGJ5v+p0u/7Z5F/A7jRa4qfg+zNjgD3vM44Ib/LmP05xMz4UjiH2VA9IfH7zfyvrFM7nvIshtNQPr8s+wOg6yCMxyR4E5WDO30oGl3TINarjJUx6aja4mwCqzyg1PUhhcFjzrtaXnd6B7dhu9a7RlyPR0yC4rEvOd9paNYlwze+BQRKNlV36lu12pFBR5e4/x8KCq9myk98fUuLekHQk+3Bt6Ys73K/vf6GQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=kIGY/rvSraLtUtyPytxUcrMFz7vTxW0iIE3RGGMILg8=; b=i5TRn2xosXvzEWxXRsrcfTtWpDGBpXH0ALQPplJU28k6y2WLG+XMoeh/TYPX+82LQhXlEk7bATFZHpMfyBLPW2pKikMFfAQ/Z65wAVD/dfNkawSLN6oIrkL+TwtucSiGtKspql4kyIJjFCCrM+2jYPgivifFS0fzw/KtbYixqWA=
Received: from HE1PR0701MB2394.eurprd07.prod.outlook.com (2603:10a6:3:70::13) by HE1PR0701MB2203.eurprd07.prod.outlook.com (2603:10a6:3:26::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3742.4; Fri, 8 Jan 2021 07:54:24 +0000
Received: from HE1PR0701MB2394.eurprd07.prod.outlook.com ([fe80::a012:f1c5:3df:a9d7]) by HE1PR0701MB2394.eurprd07.prod.outlook.com ([fe80::a012:f1c5:3df:a9d7%12]) with mapi id 15.20.3742.010; Fri, 8 Jan 2021 07:54:24 +0000
From: Mohit Sethi M <mohit.m.sethi@ericsson.com>
To: Martin Thomson <mt@lowentropy.net>, "tls@ietf.org" <tls@ietf.org>
Thread-Topic: [TLS] [Emu] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)
Thread-Index: AQHW433EhC0VQoQD00eQIvj4fWSy5A==
Date: Fri, 8 Jan 2021 07:54:24 +0000
Message-ID: <b2b24b86-2cc0-7d01-2474-c9b25b856d0c@ericsson.com>
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> <3CB58153-8CCA-4B1E-B530-BA67A6035310@deployingradius.com> <CAOgPGoA3U+XpZMY7J+KGovNx6MtAdEzRaGW33xVJdQNWSi4LVg@mail.gmail.com> <770e6a49-52fc-4e8b-91af-48f85e581fbb@www.fastmail.com>
In-Reply-To: <770e6a49-52fc-4e8b-91af-48f85e581fbb@www.fastmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
authentication-results: lowentropy.net; dkim=none (message not signed) header.d=none;lowentropy.net; dmarc=none action=none header.from=ericsson.com;
x-originating-ip: [188.67.160.225]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 4c0fc280-4193-4caf-badd-08d8b3aa9d98
x-ms-traffictypediagnostic: HE1PR0701MB2203:
x-microsoft-antispam-prvs: <HE1PR0701MB22036E0334C6954006ED8319D0AE0@HE1PR0701MB2203.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: M82Uh+Xo4KytYJC6J//MXjF3EnlLXhe4J6B4+dH+WXw/JOa7Yh6qiJ2jnKj8wKA37HY59tf5M6YgQ6TxeP+QUHeSiwiYnafdPKFL4+/VfRJceX8IMvxipzEJa+roieg96Ff6heRBx+kachbn4ZmlREA1rFyy0MuUxQmaYwsQ1MyQVjn2iN2e+tQ/0835T2zqnfPM8GRQiOZVnCUnAtCygimddwq/z6Z+CTWbTQcsPaekWBsdfJ5Lve0QMQJ/Zvs60uZSwMQal4ht5C3J5PKxfBvtm6Cf0BhbFosYguxbB4+aJ4VXBJjweephu2oC62MNAjKBOhf+3eNKaJFucT8RiS6PQo3TrbXxgpThzq4/zv1peZfZcDWOyOTewGI2r4TkeFGAmTmQaaf3mu5x69DlYUYtQBokUTEb/CRyJKZsx6vragg6gmEZYXsG/mRNkwjAABjlGjVzY50E146lAYhOhBTYgGWRCWTNfQX0Ni0z8sXt757cIDjep/5zBeZrQHhg5w1+drGes90w/XzJ/31YeecHD7LBPO1d4NiOaVhzHslXo2V7lhtdyEjVtCyJl9RH
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0701MB2394.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(136003)(366004)(346002)(376002)(39860400002)(2906002)(66556008)(8676002)(66946007)(66446008)(66476007)(316002)(64756008)(26005)(76116006)(966005)(8936002)(478600001)(83380400001)(71200400001)(5660300002)(31696002)(110136005)(186003)(36756003)(6486002)(2616005)(53546011)(6506007)(86362001)(31686004)(6512007)(43740500002)(45980500001); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: =?utf-8?B?WW5icTU3V3dHL0ZRcHh0MmJJKzhiVG5wQ052a05RM2NDbUhPd3Zmc2tsREF6?= =?utf-8?B?b1U2Q01Uc0Q0NENCamRFL1RzRzNVQUlpR1VVV2NORXoreFVCeHB5U21Bb2Rt?= =?utf-8?B?eVFPM0FIMlgvSmxETVREaFE0UWptUVNuS2UrdUpvWElMWUlWcTdBU1luVmJE?= =?utf-8?B?ZW1Dc0Z4UVlEbDZlQUoweVlTdXQrWXhReERWZ08zTFo5Q2lFand0SExkNzJ5?= =?utf-8?B?aXJ5Z3IwT2FIU1UwSFZyMlNscWpMaXpsZ3RUUVI4aE1EMCtOVmxJMUFOOURo?= =?utf-8?B?NDVYM005RVp4dlp0ZE5NKzYrMXZHaEo5TWdvUlIvY1lFY3NNNXlISEhMVlcz?= =?utf-8?B?UWNvQWt5MUdsRTZRUFVidEVZTE91OTllWHBUdFRnV2kyQ0swTTYydTdhWCtD?= =?utf-8?B?TVltdjZhbFRTWlNQT011Tm1oZW4rRi9Bclpud3VlaTRLaDczd2hIWEd5STNI?= =?utf-8?B?amttcmlBLzFxaXZaMWhpNUhMUXlIR2pLcTJSamFBaDdiQzUvN29KUzFIa1Ix?= =?utf-8?B?T3RvMnZQOTNVVGEvUzdRSGR1QmQ5S0RwNkJRNXJadDVoekpManM0SzZlYTJC?= =?utf-8?B?NUVmbG1jTDBOTTF5eVljdzZMRGVJWExBd0g5YktzUE1nRElBMUVCVG1udS9F?= =?utf-8?B?UXJFRllYMjZDNTNQM3F1UkxSV1VmVUIxQWNoSjFLc3h5N3hWKzZjcS92S2xQ?= =?utf-8?B?c3V5TkJBVmRiKzhqUG41NkQvK04rUmtxek5zNEh0V1pFaHNFSTJhbC80NHo5?= =?utf-8?B?U3NKU1RuNlhUd0kxUTRTS0RYNkcva2NMV0Zub0RySXBJU2JNYnZoWm84WXpG?= =?utf-8?B?Q0V0dTEzcUpwd25EMldKUGFsRkRpN1BkYWkyS0pLV1cxVlcxQTM0bVo4QnFB?= =?utf-8?B?bVQ1M05keG9pRm1lTEtJSCtUVmxpOFlMSXVmZlBNU3diZFNPc3psd0ZCRk43?= =?utf-8?B?Z2NFTEVJbWpPeEw5bWl6UGtDSnhtYXBrRmtyeEE4L3E4aHBsMEFmbGRDZ2Mx?= =?utf-8?B?TDl1SzRWa21OL1NLYnFaRTFIU0NPMXdQVHQ2emFkcURSL2E2eUpmYWpIWHFJ?= =?utf-8?B?c2IyZTZseFkzSjZGUEFVSWl4NkRxdFFSaVp3cFkxaUszOWdpbkU3OGtuMXNC?= =?utf-8?B?VTUzeUZNMnJCTkpPb2wwV0ljN2czQ0ZydkdsUDREakdvUUlVOFJYTmsva3ZM?= =?utf-8?B?MWdMVDNObllnSWZHY1dGTUJwSk0zczFOVkwyVUlqdTVpdEtpbS9hRTFvdUFY?= =?utf-8?B?WDNnSkZNb2t6VWVwMVZnQi82WFRUYS9SL0dRN3FOVTM4U3IzcW1laDhkRGtL?= =?utf-8?Q?dr3xirzwVArvk=3D?=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <856E903EF200E846BE2A5411734144B4@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: HE1PR0701MB2394.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 4c0fc280-4193-4caf-badd-08d8b3aa9d98
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jan 2021 07:54:24.1939 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: gYwnbHTxCgOdRNqKpI+e0u6JZp7ONjd3kETT2a1NquMXfJeM5sgWnLnsLViQu6TiyVSJZCzV71NPAIMTibQ/wuNkH+oSiQWxjTG1TkDmlkE=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2203
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/j6krMViFsEd28HbA8Mx4ExRAsKI>
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: Fri, 08 Jan 2021 07:54:29 -0000

Hi Martin,

Thanks for pointing this out. I think Ben also mentioned this in his 
review. I am not sure if it is necessary to add the type-code to the 
label when it is already part of the label string as 'EAP_TLS'. Other 
TLS based EAP methods should ideally register labels of the form 
EXPORTER_EAP_TTLS_MSK or EXPORTER_EAP_FAST_MSK (instead of reusing the 
EAP-TLS label) as is currently done in 
https://tools.ietf.org/html/draft-ietf-emu-tls-eap-types-01.

I do agree with your point about the incorrect usage of the context. 
Perhaps the ideal choice here would be Server-Id and Peer-Id (if client 
certificate is used): https://tools.ietf.org/html/rfc5216#section-5.2. 
However, I checked the wpa_supplicant implementation and currently these 
values are not available. As far as I can tell, the Server-Id and 
Peer-Id are not exported for any EAP method. So we'll need to think 
what's the right thing to do: update implementation/use some other 
sensible value/or leave the context empty (which is allowed in RFC 5705).

--Mohit

On 1/8/21 12:41 AM, Martin Thomson wrote:
> Hi Joe,
>
> Thanks for doing this, I think that this is a distinct improvement (and I will take your word for the difficulties involved with further splits).
>
> One point that I made poorly perhaps, and was dismissed, might be worth restating:
>
> MSK = TLS-Exporter("EXPORTER_EAP_TLS_MSK", Type-Code, 64)
>
> The inclusion of a type code as context is, I believe, a misuse of the field.  As this is a fixed value, the value is being used for domain separation.  However, that is the function of the exporter label input.  The label exists to establish that this is EAP-TLS and the key is (in this case) MSK.  If you need different derivations for different type codes, I strongly suggest that this be included in the label.
>
> The Context input exists to pull in variables from the context that endpoints might need to agree on.  It is not for domain separation.  For example, if you thought it necessary to authenticate the Identity values that client and server exchange, you might add those to this field.  (As an aside, you might want to consider that as their value could be used to determine what parameters to feed into the TLS handshake.)
>
> If, however, you have an adjacent usage of EAP that wants its own MSK, then that is domain separation.  The right thing to do would be to create new labels for that usage.
>
> This might be a fine point in light of the fact that these all just get fed into HKDF, but I think that it is important to respect the purpose for which these inputs were designed.
>
> Cheers,
> Martin
>
> On Wed, Jan 6, 2021, at 17:24, Joseph Salowey wrote:
>>
>> On Tue, Jan 5, 2021 at 8:31 AM Alan DeKok <aland@deployingradius.com> wrote:
>>> On Jan 5, 2021, at 11:13 AM, Mohit Sethi M <mohit.m.sethi@ericsson.com> 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?
>>>    Yes.
>>>
>>>    Perhaps as Joe suggested: EXPORTER_EAP_TLS_MSK and EXPORTER_EAP_TLS_EMSK, which seem simple enough.
>>>
>> [Joe] I created a pull request
>> (https://github.com/emu-wg/draft-ietf-emu-eap-tls13/pull/17)  with the
>> proposed labels.  Is this change going to cause significant problems
>> for implementation?
>>   
>>>    Alan DeKok.
>>>
>>> _______________________________________________
>>> TLS mailing list
>>> TLS@ietf.org
>>> https://www.ietf.org/mailman/listinfo/tls
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls