Re: [Emu] RFC7170bis and lack of identities

Alexander Clouter <alex+ietf@coremem.com> Fri, 03 February 2023 11:57 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 DCD05C16B5A5 for <emu@ietfa.amsl.com>; Fri, 3 Feb 2023 03:57:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.798
X-Spam-Level:
X-Spam-Status: No, score=-2.798 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_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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="1aXQ+GoK"; dkim=pass (2048-bit key) header.d=messagingengine.com header.b="ELMp+pyO"
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 Joun9fklRUsD for <emu@ietfa.amsl.com>; Fri, 3 Feb 2023 03:57:39 -0800 (PST)
Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (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 10620C14F693 for <emu@ietf.org>; Fri, 3 Feb 2023 03:57:15 -0800 (PST)
Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id F1F655C01A0 for <emu@ietf.org>; Fri, 3 Feb 2023 06:57:14 -0500 (EST)
Received: from imap46 ([10.202.2.96]) by compute5.internal (MEProxy); Fri, 03 Feb 2023 06:57:14 -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=fm2; t=1675425434; x=1675511834; bh=7tOjRDH+EJ deMh9uDqY0ldFViqqNO9/t7UKls5dR6C4=; b=1aXQ+GoKqbOJ3rJppFa+dobs4P VPZYka7kiQwLXbGeRj6o/ULbCHBnYqd46H5dhzn7WA2B54udSbEcSHek57UShXCH BXbNkCzU2pagTvsaNjCCekMpFBS4XnpKmjZaO3i2GA0r632StV4ZH8+nWEQsjiuZ haqsDLjPHRRiQM0y1ObwcSnqgF3KwepQN4aKuqRLMQm9nXuKyEbygas9K/PqV35J haXehpBg5vCVy5CTF1qlKLmReUeh+pjgFdB2F1QVkzvrDUaBmqyi9oXRmw5vvjvJ mHjC/dwILbzwjbgVHR1un9ya6dZqeYMbLL6myqzvp/lLDJX3BwUCl0ztF1zw==
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= fm3; t=1675425434; x=1675511834; bh=7tOjRDH+EJdeMh9uDqY0ldFViqqN O9/t7UKls5dR6C4=; b=ELMp+pyOvDP5NBhFWgePZkmnU4cHsiI2FMy3yvk5UKk/ p7j8lj4kYtqLl8fQhCwDk3R+HkqXt0exWnDUJbEeirwRvHhZwUBqoQeXwl93HcBr GhT/fJja40JeGtkGez560YiPJtscT1NcWUn3SxaQhwS2cr/gN40UaOCG8oSLuNw6 yA7MZJNQmvYsEcVnVeAhLc97FOXsOyTaZDItoen7xDuXJjCMOk/8DRm36P/qVcyY RlIZWXLzGB7vGjPM8hu4xDdhL86PNEoIEEqibysQrmKP4jrYs1hsOMbk6fauUv7p V/AI17TjJN+p7u/70UGOYAZ16jtR/cVsSpoUebg29g==
X-ME-Sender: <xms:mvbcYycbuQGfwyqwey548706QFnLIG50HxyGvPhV7UElaa4ZKHaZRA> <xme:mvbcY8O1HyxNxY4XOw_ZFP3n04G1pLlo4KYVv9kkxa0Dk2mOF_QyE2JLEGQxQYZeS qL13VajY887eYFMRw>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrudegtddgfedtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderredtnecuhfhrohhmpedftehlvgigrghnuggvrhcuvehlohhuthgvrhdfuceorghl vgigodhivghtfhestghorhgvmhgvmhdrtghomheqnecuggftrfgrthhtvghrnhepuddtvd ehvdfgvdeijeehfffgleegudfhtedvtdduudekffejjeeihfeludektedunecuffhomhgr ihhnpehivghtfhdrohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmh grihhlfhhrohhmpegrlhgvgidoihgvthhfsegtohhrvghmvghmrdgtohhm
X-ME-Proxy: <xmx:mvbcYzju8eewO_8t4LFLubrDIrpQKHEATEiLmOoIPEop1nxBvHGHpg> <xmx:mvbcY_8pjI75ONGPVtVbAnY1WRB29MYF6z0Y-hb3U6YafFv0KA-ZLQ> <xmx:mvbcY-u_wLTtsRqB64xVyCSwmEI7-N3_8Pbk6AQclEKydtJkl7Enpw> <xmx:mvbcY84jreK5Z1-s-sPk-czyu12cIUdreihVoPXTLZBHD-iuBofHvA>
Feedback-ID: ie3614602:Fastmail
Received: by mailuser.nyi.internal (Postfix, from userid 501) id BC8962A20080; Fri, 3 Feb 2023 06:57:14 -0500 (EST)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.9.0-alpha0-107-g82c3c54364-fm-20230131.002-g82c3c543
Mime-Version: 1.0
Message-Id: <3d7a8076-4b7e-4a92-b9ce-de5e3c810c39@app.fastmail.com>
In-Reply-To: <E7F39732-D012-4D2A-A34F-44965763C808@deployingradius.com>
References: <972E80E4-CB18-4154-A407-5BC04D2677FE@deployingradius.com> <45426003-4eb9-9c31-d66b-3d2b51896bcb@lear.ch> <FFFD2F98-2E7F-4603-9B85-E6C80ACE0799@deployingradius.com> <1165a702-ee9e-4269-8af1-0406eb798de0@app.fastmail.com> <E7F39732-D012-4D2A-A34F-44965763C808@deployingradius.com>
Date: Fri, 03 Feb 2023 11:56:54 +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/5DLQCPfX1nztUkRajoS_nglKAPk>
Subject: Re: [Emu] RFC7170bis and lack of identities
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: Fri, 03 Feb 2023 11:57:43 -0000

On Thu, 2 Feb 2023, at 19:16, Alan DeKok wrote:
>> The documentation does not but I did see Appendix C.9 lets the client state what it wants to do:
>> 
>> https://datatracker.ietf.org/doc/html/draft-ietf-emu-rfc7170bis-03#name-c9-peer-requests-inner-meth
>
>   i.e. the client authenticates in phase 1, via something like a client cert.
>
>   That flow does look a little odd to me:

Another chunk of greyness (at least to me) is the server has sent a Result TLV (not intermediate) and then later after another method or chain of methods it is expected to send it again.

Should we state somewhere that the client can "effectively rollback the entire inner state machine" so Result TLV is not final for the whole session?

Should the client be able to do this multiple times?

On a related note, the document does litter with ('Result-TLV') and without the hyphen ('Result TLV') all over the place for this and other attributes.

Makes Ctrl-F a bit of a pain...do we think we should fix this up; personally prefer *with* the hyphen so I can steer results towards statements about TLVs rather than stand alone words?

>   I think it would just need Identity-Hint?
>
> Identity-Hint "bob" --> 
>
>                 <-- Basic-Password-Auth-Req
>
> Basic-Password-Auth-Resp  "bob" password "hello" -->
>

Eugh, all this time I have been reading 'Identity-Hint' as 'Identity-Type'.

>> To trim a round trip, you could add language on for servers supporting this MAY wish to treat this as a username if the server would only send a Basic-Password-Auth-Req asking for the same information anyway...to trim a round trip.
>> 
>> I'm unable to think of a time why you would respond to a username request differently for an inner method, so it should be safe...mostly.
>
>   Different authentication types required for user / machine auth?  
> Password for users, and EAP-TLS for machines?

I was thinking more:

Identity-Hint = "bob" -->

                      <-- EAP-Identity Request

EAP-Identity Response = "not bob" -->

                      <-- huh? wat?!

>   For me it's also partly about not forbidding certain work flows.  
> Right now, "select auth based on identity" is either impossible, or 
> requires extra "oopsie" packet exchanges.  That doesn't seem right.

Reducing RTT's smells like something to resolve for TEAPv2?

Maybe we can use it as a carrot to persuade other vendors to move it it...one day.

Cheers