Re: [Ace] Genart last call review of draft-ietf-ace-mqtt-tls-profile-15

Theresa Enghardt <ietf@tenghardt.net> Sat, 05 March 2022 02:42 UTC

Return-Path: <ietf@tenghardt.net>
X-Original-To: ace@ietfa.amsl.com
Delivered-To: ace@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9C6E3A0D18; Fri, 4 Mar 2022 18:42:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.109
X-Spam-Level:
X-Spam-Status: No, score=-2.109 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, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=tenghardt.net
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 2nOfYaKVdX9s; Fri, 4 Mar 2022 18:42:44 -0800 (PST)
Received: from mail.hemio.de (mail.hemio.de [136.243.12.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBDF33A084B; Fri, 4 Mar 2022 18:42:14 -0800 (PST)
Received: from user.client.invalid (localhost [136.243.12.180]) by mail.hemio.de (Postfix) with ESMTPSA id BEE49AA; Sat, 5 Mar 2022 03:42:09 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tenghardt.net; s=20170414; t=1646448131; bh=cqEnvMelfiQl/aW5AzXFWSHhJu1feWSFRqKYjF+gkVc=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=ezZ9x4x3ydn++1hdUGDHj+jMOrLB5fWhe9s1Zu45Ouoqz0jTztD2QILOXGZDQgVTX os3fHv14BVPaZAXjyr5KgVlYTk/H/fUZNwyh8dkT3HpQqenxN+mDvVCHujUgn06fwo DIDh5Y+ltDgJleNAEKnjDhBSoM62uMFj9qgJOEFnKYJL8+uceVyEw0g6LicSvR+acd h80pt5CPSqQzctIcWJ8rYeIo5lBAx6D2LNIGAe3AV/K7t6qHuXAaVWVNuBJsOlebpv j87xMHPdnYmJRtkWVkXh97IiGNMwNWnuayQ24QYJRiXU4yH9FzB6rcmuJ45OAkA1vB cK10Ql7M6rzYQ==
Message-ID: <c7cb09c0-ccd2-1c16-c1ee-1e39608ace95@tenghardt.net>
Date: Fri, 04 Mar 2022 18:42:07 -0800
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0
Content-Language: en-US
To: Cigdem Sengul <cigdem.sengul@gmail.com>
Cc: gen-art@ietf.org, Ace Wg <ace@ietf.org>, draft-ietf-ace-mqtt-tls-profile.all@ietf.org, last-call@ietf.org
References: <164625142349.18034.6160062151802397570@ietfa.amsl.com> <CAA7SwCPcLsw_fSShi8z924w9fmWkKSyjM55y8rznc8V8rOeeiQ@mail.gmail.com>
From: Theresa Enghardt <ietf@tenghardt.net>
In-Reply-To: <CAA7SwCPcLsw_fSShi8z924w9fmWkKSyjM55y8rznc8V8rOeeiQ@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/894t4PURm_2aV4j4SOqhLB49qGw>
Subject: Re: [Ace] Genart last call review of draft-ietf-ace-mqtt-tls-profile-15
X-BeenThere: ace@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" <ace.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ace>, <mailto:ace-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ace/>
List-Post: <mailto:ace@ietf.org>
List-Help: <mailto:ace-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ace>, <mailto:ace-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 05 Mar 2022 02:42:51 -0000

Dear Cigdem,

Thank you for preparing the revised version, it looks pretty good to me.

Some replies inline:

On 3/4/22 14:23, Cigdem Sengul wrote:
>
>
>     Section 1.3:
>
>     "Will
>                        If the network connection is not closed
>     normally, […]"
>     I suggest to make this a bit more specific:
>     Does "the network connection" refer to a TCP connection, or a TLS
>     session? Or
>     does it refer to MQTT's notion of "connection"? Does "not closed
>     normally" mean
>     anything other than a FIN-ACK exchange to close a TCP connection?
>     Or does it
>     depend on the used transport protocol (however, in this document,
>     it should all
>     refer to TLS over TCP iiuc?) If the notion of a "network
>     connection is not
>     closed normally" is a well-defined concept in this context, please
>     provide a
>     reference if possible.
>
>
> [CS: Introduced a formal definition of Network Connection to 
> MQTT-related terminology - as defined in MQTT standard.
> To the Will definition, added the situations when the connection is 
> considered not to have closed normally.
> Question: Normal disconnection is DISCONNECT with reason code is 0x00, 
> according to MQTT standard - is this definition also needed?"

[TE] So "not closed normally" means any way to terminate the Network 
Connection, other than DISCONNECT with reason code 0x00? If so, I think 
this would be a good addition to the definition, either as its own 
definition or added to the "Will" definition.


>
>     Section 2.1
>
>     "The PoP token includes a 'cnf' parameter with a
>        symmetric or asymmetric PoP key. "
>     The 'cnf' (and 'rs_cnf' in Section 2.2.1) parameter is mentioned
>     here and in
>     some other places, but it is not obvious what it means and why it is
>     special/important. I suggest to provide a brief explanation or
>     reference.
>
> [CS: Added for cnf:
> The AS includes a 'cnf' parameter to the PoP token,
>    to declare that the Client possesses a particular key and RS can
>    cryptographically confirm that the Client has possession of that key.
>    The 'cnf' parameter is REQUIRED if a symmetric key is used, and MAY
>    be present for asymmetric proof-of-possession keys, as described in
>    [I-D.ietf-ace-oauth-params].
>
> rs_cnf:
> Otherwise, to authenticate the Broker, the Client MUST validate a 
> public key from a
>    X.509 certificate or an RPK from the Broker against the 'rs_cnf' 
> parameter in the token response, which contains information about the
>    public key used by the RS to authenticate if the token type is "pop"
>    and asymmetric keys are used as defined in 
> [I-D.ietf-ace-oauth-params].

[TE] These explanations already help, thanks! However, and this might 
just be me, but I keep wondering what 'cnf' stands for, i.e., if it is 
an acronym for something, and if it is, if it makes sense to expand the 
acronym. But it might just be a string that comes from "somewhere", 
which is fine with me, too. :)


Best,
Reese (aka Theresa)