Re: [Emu] I-D Action: draft-ietf-emu-tls-eap-types-09.txt

Alexander Clouter <alex+ietf@coremem.com> Wed, 04 January 2023 09:17 UTC

Return-Path: <alex+ietf@coremem.com>
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 99B0BC14CF02 for <emu@ietfa.amsl.com>; Wed, 4 Jan 2023 01:17:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.796
X-Spam-Level:
X-Spam-Status: No, score=-2.796 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_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=coremem.com header.b=J5RzWgtp; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=r/tuIfq+
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ava34xGrWu8q for <emu@ietfa.amsl.com>; Wed, 4 Jan 2023 01:17:32 -0800 (PST)
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DD25C14CEE2 for <emu@ietf.org>; Wed, 4 Jan 2023 01:17:32 -0800 (PST)
Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id AA79F5C010A for <emu@ietf.org>; Wed, 4 Jan 2023 04:17:31 -0500 (EST)
Received: from imap46 ([10.202.2.96]) by compute5.internal (MEProxy); Wed, 04 Jan 2023 04:17:31 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=coremem.com; h= cc:content-type:date:date:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to; s=fm1; t=1672823851; x=1672910251; bh=5axLh00Rr5 L7QCuWaia+DFhNVG7EO9f9NW7dxb2K44s=; b=J5RzWgtpYlOesdgl2BlfeAa14/ whfLEQsvXeU8x1xNsIN7LbCNG5tIXOyirsY4n1mKpln7SPlQf08kfZEpAq7tkREa I7qr05kNOpoLt1DzQTMfRMhS9ygDVGbpRuAtBu8zqFDqiMsTw5umF8f9HUOR7YsB NWVCabYWJ7sfqvM+3sQRc3xNkPBeMlXbTfaqz+vUiI/dziboVRo3stSXd3ZirFze +iqapp+3VRg6EKKewQeZ8ai/Ing2+3v47jwIlQZPyDp5zNNeWW14sY7VBRmYkQER 5ejk/seNxR3I5GfM8nrS1Nb/bX5T87vPiMmjfkACN4bqBNxGSsBCH8qJX0Aw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:date:feedback-id :feedback-id:from:from:in-reply-to:in-reply-to:message-id :mime-version:references:reply-to:sender:subject:subject:to:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; t=1672823851; x=1672910251; bh=5axLh00Rr5L7QCuWaia+DFhNVG7E O9f9NW7dxb2K44s=; b=r/tuIfq+L+hq2p9iLrc0NF/m/79iDcFE3n5tYL36qvzZ 5zILCmRv18uA6+q4I1wedOL4v92KEmKCVTFwPtMZbCekxBcVTEa4wqMN8dD/Rf9F 6TxAp3iu4xScEMkHdQigQyrpleRpBATHSvBzj6wGodvvCtgVaK2fktBTZRj1ia2+ Nwc/CDlFXgPZTMAJer+UWxpz0KoI0BjGJgjDKts/LWh4uOVPzaxC0RmASAPHVsJB v+JIsfFBI8KOlHYbszzwBY1DZepIlnNke9UM/9HDkqwi2JVH19zu8Ck3ZUUDGj7I aIhlUuH6I7ERwc+3sFZo3q8t8X4kGR98uTG1evsGjw==
X-ME-Sender: <xms:K0S1YyZ1b1ZJMoRJdWzDT_Q6zhNd4b3cmCjUGVdJGivJs2WtJTAUbA> <xme:K0S1Y1YhsyuUc9Bv6cktgCMkHJysq4H4ya8BGeXJZHJH8Kxg27KOxVDtWs5yWWjPF J_alB94B2F7iZyGFw>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrjeeigddtudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreertdenucfhrhhomhepfdetlhgvgigrnhguvghrucevlhhouhhtvghrfdcuoegrlhgv gidoihgvthhfsegtohhrvghmvghmrdgtohhmqeenucggtffrrghtthgvrhhnpeektdfhud efvedufeehvdeigeefkeehtdetveefffduieffieeludeuhfetgeehvdenucffohhmrghi nheprhhftgdqvgguihhtohhrrdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrg hrrghmpehmrghilhhfrhhomheprghlvgigodhivghtfhestghorhgvmhgvmhdrtghomh
X-ME-Proxy: <xmx:K0S1Y8_N4NHiWSu6oiyaZbRR0OQ0_P5ijVmOtnoHtH3qd0fA5b2OvQ> <xmx:K0S1Y0oHV9c-mHTf5HIdF0bTXmlkh0iv3j0d24mX7q0hpodhQGr-Kg> <xmx:K0S1Y9paFgGAm323e7hI9uqCU6sSUd9wTXh0iffk0YbRCmbbgpr8IQ> <xmx:K0S1Y60e73IBNv9sAsNS_0HkvDrN3yTY6JNFLpYwQlcvumwZevv8wg>
Feedback-ID: ie3614602:Fastmail
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 7EA9F2A20080; Wed, 4 Jan 2023 04:17:31 -0500 (EST)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.7.0-alpha0-1185-g841157300a-fm-20221208.002-g84115730
Mime-Version: 1.0
Message-Id: <5e1ba7f8-c21e-4052-b702-037856e8588c@app.fastmail.com>
In-Reply-To: <166428153120.54333.17278955597896126770@ietfa.amsl.com>
References: <166428153120.54333.17278955597896126770@ietfa.amsl.com>
Date: Wed, 04 Jan 2023 09:17:10 +0000
From: Alexander Clouter <alex+ietf@coremem.com>
To: EMU WG <emu@ietf.org>
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/emu/jKMaQpI2Txdl9go4gnaiYD65meo>
Subject: Re: [Emu] I-D Action: draft-ietf-emu-tls-eap-types-09.txt
X-BeenThere: emu@ietf.org
X-Mailman-Version: 2.1.39
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: Wed, 04 Jan 2023 09:17:37 -0000

On Tue, 27 Sep 2022, at 13:25, internet-drafts@ietf.org wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the EAP Method Update WG of the IETF.
>
>   Title           : TLS-based EAP types and TLS 1.3
>   Author          : Alan DeKok
>   Filename        : draft-ietf-emu-tls-eap-types-09.txt
>   Pages           : 21
>   Date            : 2022-09-27

For TEAP (and similarly for FAST) we need to do more than just state "PACs are dead use NewSessionTicket"[1].

Crucially what goes into 'ticket'? Is this value just the PAC-TLV and parsed by the peer to extract the PSK identity? If so this would rub up against the 'opaque label' nature of the field.

I think we should describe how to use the 'extensions' field and define an 'ExtensionType' for our PAC-TLV[2]. We also need to state that some of those sub-attributes are handled differently:

 * PAC-Key: replaced by internal TLS library magic
 * PAC-Opaque: replaced by value of 'NewSessionTicket.ticket'?
 * PAC-Info
   * PAC-Lifetime: replaced by ticket_lifetime+ticket_add_add
   * A-ID: still used
   * I-ID: still used
   * A-ID-Info: still used
   * PAC-Type: still used
 * PAC-Acknowledgement: no longer used

Thanks

[1] https://www.rfc-editor.org/rfc/rfc8446#section-4.6.1
[2] https://www.rfc-editor.org/rfc/rfc7170.html#section-4.2.12