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

Martin Thomson <mt@lowentropy.net> Fri, 08 January 2021 08:25 UTC

Return-Path: <mt@lowentropy.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 4BB553A1107 for <tls@ietfa.amsl.com>; Fri, 8 Jan 2021 00:25:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.12
X-Spam-Level:
X-Spam-Status: No, score=-2.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=lowentropy.net header.b=W9jPkC9A; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=USz6PNW/
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 bVmxp8vjaTFU for <tls@ietfa.amsl.com>; Fri, 8 Jan 2021 00:25:21 -0800 (PST)
Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 953A63A1106 for <tls@ietf.org>; Fri, 8 Jan 2021 00:25:21 -0800 (PST)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id AD74E5C035A; Fri, 8 Jan 2021 03:25:20 -0500 (EST)
Received: from imap10 ([10.202.2.60]) by compute1.internal (MEProxy); Fri, 08 Jan 2021 03:25:20 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm1; bh=hGuXHRFF7zsmq66HBI9aussgRdSGG4S M3gtPJnB9eTU=; b=W9jPkC9ApKzALGZC1jwvmAYy9N5z2noIATvuUWcSnHudAPI hJrK4aGKQr/Yb5BKSAcgMC3G3hlvl/fgNEqP9McUBKSA+rtILXQ3y58+UWD/XJ4A nMbxDMHZRyMqf+JT6u6/bDsX15xagbjFEVyySgHF0lGdsTPtOT2/HFHEsOcMszqe DDwSgEnhVqudSYgYwcO2sOfIuI2gbnQLe/hUTKoVgcjeIR8YjsCqcrX59cJXZmB4 xyVLUzmTefUvuQqZcUy2Q6VOGQOGLAtNCjddmPrSjtbdupb05g5tZcndIvt1OGg3 LfKJDhvZOpNWdV8IR0RxN/92LfsNpr44C7oVElQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=hGuXHR FF7zsmq66HBI9aussgRdSGG4SM3gtPJnB9eTU=; b=USz6PNW/J8CBnNywu/i4ym kNaG/9UcmXqMs5ZzuOnFSfI/58He3N+LgvvnLsozOtH5Ck360N4Pfn+XVIcP1Hzh 2yGYrWeZT9tgiNeCozyjNxUfeZm7snDn+lgyGPYL7EeWSSutLR7dtoJ9snP5XlQ2 MfM6Z+qLRLoQUjsR8tT/TpLKcJbav2XChaaPC3W6mxNmXO0wYzxiG5fpvjoSpbDo J0dJBxPRqM0T0OoI/mUkwHs1ZJz3sXxfYtvhZZs4//e0l/I10SapudISaJoa8el1 /8CssyvGe4IuwIFBMpPfnfpN4WA1osxwicn0hKq3oAyfVNiok20w6EQ4mq3raLIw ==
X-ME-Sender: <xms:8Bb4X6Xf1B5dZwCpqJVKuw2H0Hev_20247lDH_pDS_TPFVuzBTLvew> <xme:8Bb4X2mTo-sDbbNlN4IjJsW0AdFag312R5x0shpGX5zfBcacgxsSWZ5Ly1inUfVPp Sismu4nAmJFpEtR0-o>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrvdegfedgudegkecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefofgggkfgjfhffhffvufgtsehttdertderreejnecuhfhrohhmpedfofgr rhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhhofigvnhhtrhhophihrdhnvghtqeenuc ggtffrrghtthgvrhhnpeelfedugfelgeeigfeuveeludejjeeutdelgedvteehueevhfdv hefggeeuffeivdenucffohhmrghinhepihgvthhfrdhorhhgnecuvehluhhsthgvrhfuih iivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhhtsehlohifvghnthhrohhphidr nhgvth
X-ME-Proxy: <xmx:8Bb4X-ZxQjXayKL6M4nVXueuKarLguIwab3ULlSdPY-svx5LQcyWAg> <xmx:8Bb4XxWPihj3s7wx31PBgRZVwqCCazXlQcFeU650o_v8SfE4LMK7EA> <xmx:8Bb4X0mOK0lfwDm_rTywcwyKXEqQwuYNdto25CV-YfJ8X6M3GjGADA> <xmx:8Bb4X2Rqle1GwEUOFYZvb_ClrwWvRQrRZiQ0_bZ9eTNVkEl7KenIrw>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 357952013A; Fri, 8 Jan 2021 03:25:20 -0500 (EST)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.3.1-61-gb52c239-fm-20201210.001-gb52c2396
Mime-Version: 1.0
Message-Id: <02c1fbac-f23c-46af-b5fd-caa3cc7cf8e1@www.fastmail.com>
In-Reply-To: <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> <b2b24b86-2cc0-7d01-2474-c9b25b856d0c@ericsson.com>
Date: Fri, 08 Jan 2021 19:25:00 +1100
From: Martin Thomson <mt@lowentropy.net>
To: Mohit Sethi M <mohit.m.sethi@ericsson.com>, "tls@ietf.org" <tls@ietf.org>
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/XnxlqfyDH_uUIE3uSz_eTyoWiNQ>
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 08:25:23 -0000

On Fri, Jan 8, 2021, at 18:54, Mohit Sethi M wrote:
> 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.

Sounds good to me.

> 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. 

Maybe, as I said, it depends.

> 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).

This suggests that the values aren't critical to any decision making process made by either peer and maybe you don't need to include them.  I would check a little more thoroughly though.  One implementation not using them isn't strong enough evidence that they aren't used at all.  If those identifiers determine what certificate is selected, or anything like that, then it would be good to ensure that peers agree on what they were.  That might mean making them available in implementations that did not previously use them.  On the other hand, if they are always going to be anonymous identifiers that have no bearing on the TLS operation, don't worry about it and use the empty string.