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

Alexander Clouter <alex+ietf@coremem.com> Wed, 04 January 2023 13:22 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 AA3CAC13A052 for <emu@ietfa.amsl.com>; Wed, 4 Jan 2023 05:22:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.099
X-Spam-Level:
X-Spam-Status: No, score=-7.099 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_HI=-5, RCVD_IN_MSPIKE_H2=-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=DIHP+ZUq; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=S5zt5Kko
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 qv3pwGeQGuwS for <emu@ietfa.amsl.com>; Wed, 4 Jan 2023 05:22:16 -0800 (PST)
Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.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 8AC9BC14CE3C for <emu@ietf.org>; Wed, 4 Jan 2023 05:22:16 -0800 (PST)
Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.west.internal (Postfix) with ESMTP id 550D63200786 for <emu@ietf.org>; Wed, 4 Jan 2023 08:22:15 -0500 (EST)
Received: from imap46 ([10.202.2.96]) by compute5.internal (MEProxy); Wed, 04 Jan 2023 08:22:15 -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=1672838534; x=1672924934; bh=A15qSoae6+ PDhVKeft1Ohv6wb0/JLW0GJJ+9ZHAMTg8=; b=DIHP+ZUqyuKV66ATskDoMr+oa0 eEEbsj66YyzvETbSLB+i/uhm3OSDSvRL32bv6yM7Kshotufo+d+eM9opw+qy6532 foJFFk+oqFSI2fqiGTkU1SV4EPuEr6C8Ebp1ZY9+u2HmXfvTuCifsfxHxh65Ox67 FEv0AYlkSnPjykk1E7teKMtbqms3Xjeoe6QtnG6nO98cl8ewX0rvSyxuN28o3YWf BJWO/vm2CKkw1M3g5KVzGHLlwBJScgDCcppOqNvCuZMxmEzKZdDDKOY9/D/0vkFv 6702gLQd3iGkfSoaCgn14DCZnw8wuCEz5JbsF7udQuNNfiQj2tDdRAWtMjKw==
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=1672838534; x=1672924934; bh=A15qSoae6+PDhVKeft1Ohv6wb0/J LW0GJJ+9ZHAMTg8=; b=S5zt5Kkoeq4KU1Bmxc0AdoH3RIRbtWoGfWycMwZFQrKQ 9EM5I7H9F/V6+YXm5xcqBPzmi+koBvink3kiWiAAI487+ZIDuOoDRjDQz/dobPG9 tRm7v9idrllx4K1e88KU2/+QdT9VFwB/yKVNkGvbMh1Rm8IHCLOQ+5CEPvAES1KK 7+7qlNblOQF4RHFqwPeVPGGDKSICZv8i6viTUn+2Zs7l8x8hiL82vq5F43obnc1f 8pfFZlDvG68M3z50lpX24Izc3wZcCT1+FcVZn+uPhmTZKBRCrr/VKjIXdMuFSzxY YV5Mgp7u3ZLJ45ReaHfB864NQvCYfyeOf9Yx/nNRZQ==
X-ME-Sender: <xms:hn21Y_JEcZgKwyTov3jh3_fC93cKN-M8ELxlusfHbIk6g7z5qTyRpw> <xme:hn21YzLjOV_wsH97o_cEe2ZUh97OB8M1MRHdO3DLLQvdurLIoabogJ4t9vtV2cDdr t8f7iC9Yz-mwBVCDA>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrjeeigdehudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreertdenucfhrhhomhepfdetlhgvgigrnhguvghrucevlhhouhhtvghrfdcuoegrlhgv gidoihgvthhfsegtohhrvghmvghmrdgtohhmqeenucggtffrrghtthgvrhhnpedutddvhe dvgfdvieejheffgfelgeduhfetvddtuddukeffjeejiefhledukeetudenucffohhmrghi nhepihgvthhfrdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrg hilhhfrhhomheprghlvgigodhivghtfhestghorhgvmhgvmhdrtghomh
X-ME-Proxy: <xmx:hn21Y3sAPVO6VkXBwJFWiVvot2Gac8RniDbGl5RmGftcMUfknIVTSA> <xmx:hn21Y4Yir59rPTVF_v7SfYItpG1uv2pP1tBSVld3-P1-HW9xEsUIwg> <xmx:hn21Y2bbYZojjglN_QkuZ-taZzoxDTjTYaHH2N7nwvCix2b_r8Gq7Q> <xmx:hn21Y_mbttHC9vuR4X9zWuWsaLIQv9suB6dVO4AKpV9mxlwtuxaltA>
Feedback-ID: ie3614602:Fastmail
Received: by mailuser.nyi.internal (Postfix, from userid 501) id C0D832A20080; Wed, 4 Jan 2023 08:22:14 -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: <86d13413-bfb1-4d63-8e71-fa5f06f9865b@app.fastmail.com>
In-Reply-To: <5e1ba7f8-c21e-4052-b702-037856e8588c@app.fastmail.com>
References: <166428153120.54333.17278955597896126770@ietfa.amsl.com> <5e1ba7f8-c21e-4052-b702-037856e8588c@app.fastmail.com>
Date: Wed, 04 Jan 2023 13:21:53 +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/MywxHW_ytcpCS_h9XFsHOU6_f_I>
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 13:22:20 -0000

On Wed, 4 Jan 2023, at 09:17, Alexander Clouter wrote:
>
> For TEAP (and similarly for FAST) we need to do more than just state 
> "PACs are dead use NewSessionTicket"[1].

Looks like I jumped at this too quickly, there is some text from the original RFC7170:

https://datatracker.ietf.org/doc/html/draft-ietf-emu-rfc7170bis-01#name-tls-session-resume-using-a-
https://datatracker.ietf.org/doc/html/draft-ietf-emu-rfc7170bis-01#section-3.8.1

It clearly states PAC-Info is not to be used when NewSessionTicket is so we can get rid of it and all its sub-attributes.

Though not described, I guess we can *assume* A-ID/Authority-ID is tracked via the Outer-TLV values, though we now lose A-ID-Info and I-ID.

It is not described (or shown) but I suppose we can *assume* the conversation (which can be started by the peer with PAC-TLV[PAC-Type]) is otherwise:

[server] TLS NewSessionTicket
[peer] PAC-Acknowledgement inside tunnel

The peer can request several PACs upfront (though as only Tunnel-PAC is supported this probably has not be exercised) there is no language about if the server has to respond in order, especially as it is (by policy) allowed to ignore some of those requests.

So fortunately no need for the 'extensions' field, but maybe this is more a change to the RFC7170bis draft rather than here to firm up how to use NewSessionTicket around A-ID/Authority-ID and a explicit declaration that PAC's must be provisioned in order they were requested?