From nobody Wed Mar 9 15:27:54 2022 Return-Path: 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 D8B7C3A11FA; Wed, 9 Mar 2022 15:27:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.767 X-Spam-Level: X-Spam-Status: No, score=-0.767 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, NORMAL_HTTP_TO_IP=0.001, NUMERIC_HTTP_ADDR=1.242, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-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 (1024-bit key) header.d=ericsson.com 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 VQddvNv5B7cM; Wed, 9 Mar 2022 15:27:47 -0800 (PST) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70045.outbound.protection.outlook.com [40.107.7.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 271C33A11F9; Wed, 9 Mar 2022 15:27:46 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=manmXEUfFjOOEj6hqhP0Sv0uSpOw9aVAjDfAuSFiVyxUSyfJg8GXA02Y60cuN2UmhpM1jJZAoIsxQ2rVopBqG2oaN9cNcU3Efn0oG9H4HHM8pH9MslPxzaC1G/A2LESjxJOauhneSvTusSCMRj23pCYGicWww74vrLB2H7JX+I4a22U20wmrwyl1MZys21fWYtQ7QnkoXlucm/AkbWwQRRsrJ1A4A4cDgJUka1OukrJLxOfUuxFf2hvhgPaifCbfAhdujuC0iDdWDZZPE7VEZXcMiIDwQbq6x0UmRoYOROgduD/uwYxOvmfdopdLCMTsks+vFgptbZBt3fjsRqYN9g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Nu+CMZHcWEkqj0YNlPHEM5f0ljc5rDC1uNYlioozRAA=; b=B5TmRQfQcvxbMKhSgNA9ptdMDPgnZW+cMjExBch+WJe+XKzom6KS9uuKfkspeYc22JcE4CtxSRwIakx5umiXwbzHHOKMs3Bhx4oGUjrbyhUOebK0p8cXRKkOhj482/4k0TIU5ElhOsyWi6LMI7k4kv6F/hNTBJTeHsqCrgG2A4jM48R70ZsqI/6nUQwq4FyyX8FBOaUoTYz0v+mWOZE98hJZh1V7dE/uiY1eVkPmiZjz00oJBfJdEpere0wLnoWZlaT4ItjkezxLoqk2NmeKvI+7uLoqH3ba9R5TumVWCgdclF/RjN/6KeMaUVDfZ8Wodkv/5QbDWzQ7GeF7YFOi3w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Nu+CMZHcWEkqj0YNlPHEM5f0ljc5rDC1uNYlioozRAA=; b=Q5cEwbqLN38ubJXowq9tUPWnBMwh5IiC+3a6oqausMYUPJ7EwSkTDN2RR6SZwPyIBJe3tJNU9JLNzERjXoO+c3trfjFToceMCA12ysyqLuKras8bZz5HU/cnzai1scMa1SOriPiJpuuaasv4WRmkgvzRKKXSOUfI+VKSeXLrwos= Received: from HE1PR07MB4217.eurprd07.prod.outlook.com (2603:10a6:7:96::33) by AM0PR07MB6388.eurprd07.prod.outlook.com (2603:10a6:20b:157::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5081.7; Wed, 9 Mar 2022 23:27:40 +0000 Received: from HE1PR07MB4217.eurprd07.prod.outlook.com ([fe80::a10e:4f8d:2a7f:ffac]) by HE1PR07MB4217.eurprd07.prod.outlook.com ([fe80::a10e:4f8d:2a7f:ffac%5]) with mapi id 15.20.5061.018; Wed, 9 Mar 2022 23:27:40 +0000 From: Francesca Palombini To: Cigdem Sengul , Jean Mahoney CC: "art@ietf.org" , "draft-ietf-ace-mqtt-tls-profile.all@ietf.org" , "last-call@ietf.org" , Ace Wg Thread-Topic: [Last-Call] Artart last call review of draft-ietf-ace-mqtt-tls-profile-14 Thread-Index: AQHYMxuhODAeRcypj0CrSX9trQSP4ay3sVn2 Date: Wed, 9 Mar 2022 23:27:40 +0000 Message-ID: References: <164643005466.28393.1552756094187219874@ietfa.amsl.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=ericsson.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 662b51cf-f9ed-44dd-1806-08da02246787 x-ms-traffictypediagnostic: AM0PR07MB6388:EE_ x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 87RRdmn2M0uZfBrBe75fYhX8EIP7BOboNhVd3r2KDVhhnOurwM5XINwrtuJMfmSHUEzrTDDNZb2USmFL+7ZF9ZC1pr/l2kpttT/Y3X9om1iptylKW15Vwr/1D98dL80s4KcaXuJ2zPbxciIQWLnUd1jLxai3z+P7FNr/qoWPWQKTJ0ObZ3jCGJFwrZL7JZTAznPui3afjxWp9ILa3xth0GaORtFNMjrSABGcVqpPcHIsi0oD9+nVQlP+FQ8ayO+8GZ/xvDzYB8aTcJkvbYff7UPl4EDZXiVhrvQ+slMCfm0qmNUQ4pfQQjfAoZUse+Pu+IgVM/sO15LNKgbztQ77mNjScwybYvRtQTpME4w8UGLa4FyTJQ3WIhh3yv88jFYo4rhmaWSJWkiGw+xFELin7illS3zq1ACSLK/mWsgf0CoUMczlprsafphQNL10s8Qirpe1oHnRLT/OtYMgI4UVCag+53A33GYpQXulYen/0rU7uvZQfE6dUlaZRcNjsvJtKg9VYqeeYP3y40P/EO+cHAPrrW1a04lqRoSjQ0Okt7yg2+4BNfHfnLg4dVS0G2g4EYxfa8zurEFtnFKsES983GsgYPDbKg46gE8CBKHdwbnoIaUfqXRuTHkKQjGNUxwFTv7EFEvvgZcu0Vk/MS2MJloEuXvMo5st4G1e6a2MiKYo6KDpWtYJcL4jOD1z42hPFycXcYil4RegfoIUdYvh/zK7efDHRRGY2NH6dxB5+bxr9Ppf9isWJ46ato1zfdNyQQdQRx64B0oKbJLEVDV7tQrftgCEPIIP46ttI8mr49Hpqox68REuX8D98cnjPWxuXzTdnL7qNWr8Wp0YIqTSjNki0mZst14NiQ66XiZMffnfBdazXEDgMAfqYkL70tPDZUDMywGE1DLP9R1RWOkDMQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR07MB4217.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(4636009)(366004)(4326008)(966005)(8676002)(166002)(30864003)(54906003)(66446008)(66946007)(6506007)(7696005)(2906002)(76116006)(66476007)(66556008)(64756008)(38070700005)(91956017)(9686003)(122000001)(83380400001)(86362001)(55016003)(53546011)(186003)(26005)(5660300002)(38100700002)(8936002)(110136005)(52536014)(33656002)(71200400001)(82960400001)(316002)(44832011)(508600001)(87944003); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?Windows-1252?Q?/saj/5eZMl00tZL+Qm70avpYtMBDj/X0sVMgrQn/mGmausIOdxzdtU3D?= =?Windows-1252?Q?4Wuc0hsNdvqZA4BkEvtGLIMwGqgUlO6xhkq4ed84sXOqurQ3YPUShcmP?= =?Windows-1252?Q?yefkgkTPlbviboonE18nrEAskwgVT81deOHg6e5j5nQbHUghNdklVBo8?= =?Windows-1252?Q?JRw12pPR40gT3GlzYDaTIEfqTkXPF8fZsYEB3JAlDtfLnHbHjt1nYoBi?= =?Windows-1252?Q?exkIOIU7uf+5aiwtjV3Eky25ZuClJ5qgomLBgI/uWINcfymAL2gE+goY?= =?Windows-1252?Q?c6w1lNT0OfwsGjMAv6hLavqJhtaW+x+HXgKbbMt+1ZwAGx1unadmzteU?= =?Windows-1252?Q?IYVxEml9ZNCaSgIG+NtnZE9/UEEDfSZUIdHY9DyBQd39hAVDPhll7pLF?= =?Windows-1252?Q?JnWzjsC3DOv8dR1xst2phJB1tfTR9slNwTZhtdcycMMP0IMLTj70i6nv?= =?Windows-1252?Q?WCQv0lEsWueJ3lNqGzYE6kL6SCGRDdSWBHgNXxjiJE0mNwEed8U5zYLZ?= =?Windows-1252?Q?AT2mizXwe/hS0/ps+QxU2AK5jhbIlOJKelqyqB+Wp9cL7Imb33lQ4G4O?= =?Windows-1252?Q?JVkOyjYvn7uAhH2uHiBdnIVxyJl2XvHekyITTV1FF922uHrdCeIRVoWE?= =?Windows-1252?Q?XaTytDLuPzyB+LB2hQUWgVksu1nxW0MGb2GDI0kZV5WW+qr7BeiCuZHg?= =?Windows-1252?Q?evpYAH2UdTNIejaPa/qmt4AR9Sqe1ieA1frbY3bz4hYXf3yZ2oJcPCx2?= =?Windows-1252?Q?TvMj3LK5Wh5SEzN5FZLzjdsSJQhqCmvmPh6JTMWkKE5sRpj8rL4YiDUZ?= =?Windows-1252?Q?JyPLu0YG190Z8SLe4PGqGNQ+D9u2G3ca3zos6MzpxkDi7TZxqGssVIEr?= =?Windows-1252?Q?ZhsEomMRpGoc82vK1zWcstvZq96PyyZUSuBRYF++LOtmp3KNXP+xjKZF?= =?Windows-1252?Q?nMdsvXWiKKx4dlleKjXnk8YNB6mcaL918ZALKHbGcHKPFy7JKcRSmkAk?= =?Windows-1252?Q?D6MQAyiC7vmfdlccl611ZNxCriEJwYbfoqt5lHjkAjyObGcOyHVp5Ivk?= =?Windows-1252?Q?BHlYV4UfNr/eol2HypGC+1CoMP14yKx51DIQWMODIkn7Xseo2sIxrirs?= =?Windows-1252?Q?zeRWpSKEE3M2yQZQu240zRC+VJYRCEMUthHAFz3bklNxCXSp8ic0iodK?= =?Windows-1252?Q?r+CP7jDhdhZGHB1FVZhXmlCDfkHvNArSsO858BzQ3QNXeNwBOALH+XH2?= =?Windows-1252?Q?ACFb5nd/ntp6rzQ9SkFnfCBfiTFoeLKPWAcfBTCiSdRzZRLmM04UOa2M?= =?Windows-1252?Q?a+8sh248auwj9ArHc+gyxEFNJmU6joOi0hwJUvq7zXfQNZlw9leKPPka?= =?Windows-1252?Q?uz3XYIJ5qoXcoyKpamvuETuyZZ0kZ2u4J0tI2ncP/8/sXYhE5dQkHLmI?= =?Windows-1252?Q?HFMgxgJUKUzXIugE4N0mbw5AntEZmudCIgujWn+Yz+Q/DQuDhnAyOmAq?= =?Windows-1252?Q?eGYaLLlw9lZXcrB2JQvTL/NP3OIfo5qczSIIxamAGhA7usrMERLkbbSO?= =?Windows-1252?Q?qRTpAYZJEzwvnJeq1KNmkbPCAOujxvUZ3PH0KDrDJsx6KagzIihUIWY4?= =?Windows-1252?Q?+5w/fkV2GQsY8/u7UJH7hmvr?= Content-Type: multipart/alternative; boundary="_000_HE1PR07MB42177EE2866E544D286A4AE9980A9HE1PR07MB4217eurp_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: HE1PR07MB4217.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 662b51cf-f9ed-44dd-1806-08da02246787 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Mar 2022 23:27:40.3925 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: qI8dgIpgVDsoRDwKfivK8rohNLDyvSy7u43OxURwv3H0dCjMVPMcTg/bmD6gjl93N4OnU7DxSZAyuKaRyozUAsQCo6wNNpYIcW3leTg1B0fcgOuAP8G4+646FOZPVgtt X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB6388 Archived-At: Subject: Re: [Ace] [Last-Call] Artart last call review of draft-ietf-ace-mqtt-tls-profile-14 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2022 23:27:53 -0000 --_000_HE1PR07MB42177EE2866E544D286A4AE9980A9HE1PR07MB4217eurp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Jean: thank you very much for your thoughtful review! Cigdem, thank you for= addressing it, I do believe it improves the document. Just one note: for the downref to informative documents (for those document= s that were actually included in the text), please revert the change =96 RF= C 6234 and RFC 8032 were correctly referenced as normative, since they are = mandatory to implement. MQTT standards are also correctly referenced normat= ively. Jean was only noting these appear as downrefs, but downrefs are not = =93mistakes=94, they just require more attention =96 see https://www.rfc-ed= itor.org/info/bcp97 for more information. Downrefs are usually Last Called = to make sure the community is aware of them, except for those that have app= eared as downref for many documents and don=92t need to be Last Called expl= icitly anymore: https://datatracker.ietf.org/doc/downref/. Thanks, Francesca From: last-call on behalf of Cigdem Sengul Date: Tuesday, 8 March 2022 at 19:37 To: Jean Mahoney Cc: art@ietf.org , draft-ietf-ace-mqtt-tls-profile.all@ietf.o= rg , last-call@ietf.org , Ace Wg Subject: Re: [Last-Call] Artart last call review of draft-ietf-ace-mqtt-tls= -profile-14 Dear Jean, Thank you for your review. I implemented changes and prepared a pull request at: https://github.com/ac= e-wg/mqtt-tls-profile/pull/102 Below is a summary of how I revised the text according to your suggestions,= and corrected references for this document (removing unused references due= to changes of text etc.) I have still kept MQTT as normative, as the docum= ent is about MQTT, but is it expected to be informative when the reference = is a non-RFC? Kind regards, --Cigdem On Fri, 4 Mar 2022 at 21:40, Jean Mahoney via Datatracker > wrote: Reviewer: Jean Mahoney Review result: Ready with Issues This document is ready but has minor issues with wording and references. Minor issues: Section 1: The subject seems to be missing in the following sentence. Should "recommended" be normative? Current: The Client-AS and RS-AS MAY also use protocols other than HTTP, e.g. Constrained Application Protocol (CoAP) [RFC7252] or MQTT; it is recommended that TLS is used to secure these communication channels between Client-AS and RS-AS. Perhaps (add "exchanges", split into two sentences): The Client-AS and RS-AS exchanges MAY also use protocols other than HTTP, e.g., Constrained Application Protocol (CoAP) [RFC7252] or MQTT. It is recommended that TLS is used to secure these communication channels between Client-AS and RS-AS. [CS: Done.] Section 2.2.4.2.2: I'm having difficulty parsing the following normative statements. Does "MUST" also cover the Authentication Data (i.e., MUST be s= et to "ace" and MUST contain Authentication Data)? If the Authentication Data = MUST NOT be empty, MUST it contain the 8-byte RS nonce or could it contain somet= hing else? Current: The AUTH packet to continue authentication includes the Authentication Method, which MUST be set to "ace" and Authentication Data. The Authentication Data MUST NOT be empty and contains an 8-byte RS nonce as a challenge for the Client (Figure 6). [CS: Revised as: The Broker continues authentication using an AUTH packet that contains the = Authentication Method and the Authentication Data. The Authentication Method MUST be set to "ace"= , and the Authentication Data MUST NOT be empty and contain an 8-byte RS nonce as a challenge for the Client. ] Section 4: I'm having difficulty parsing the following. Is it talking about using a challenge from the current TLS session? Current: To re-authenticate, the Client MUST NOT use Proof-of-Possession using a challenge from the TLS session during the same TLS session to avoid re-using the same challenge value from the TLS-Exporter. [CS: Revised: If re-authenticating during the current TLS session, the Client MUST NOT us= e the method described in Section 2.2.4.2.1, Proof-of-Possession using a challenge from the TLS session, to avoid re-using the same challenge value from the TLS-Exporter. ] Section 6.1: Could more guidance or examples of necessary policies be provi= ded here? Current: However, stored Session state can be discarded as a result of administrator policies, and Brokers SHOULD implement the necessary policies to limit misuse. [CS: Revised as: "However, stored Session state can be discarded as a result of administrator action or policies (e.g. defining an automated response based on storage capabilities), and Brokers SHOULD implement the n= ecessary policies to limit misuse." Would this work? ] References: idnits identifies the following issues. The three informative R= FCs are already listed in the downrefs registry, though (https://datatracker.ietf.org/doc/downref). =3D=3D Unused Reference: 'I-D.ietf-ace-oauth-params' is defined on line 1= 499, but no explicit reference was found in the text [CS: This is fixed based on the revision for genart review, and the ID is r= eferenced.] =3D=3D Unused Reference: 'RFC7251' is defined on line 1563, but no explic= it reference was found in the text [CS: Reference removed; added RFC 8442 for the PSK cipher reference] =3D=3D Unused Reference: 'RFC8422' is defined on line 1609, but no explic= it reference was found in the text [CS: Now cited] =3D=3D Unused Reference: 'RFC8705' is defined on line 1625, but no explic= it reference was found in the text [CS: Removed as does not apply to the current text] -- Possible downref: Non-RFC (?) normative reference: ref. 'MQTT-OASIS-Standard' -- Possible downref: Non-RFC (?) normative reference: ref. 'MQTT-OASIS-Standard-v5' [CS: OK for these two, I feel on the fence as the document is about MQTT. Is the downref suggested because this is a Non-RFC and a standard coming fr= om OASIS] ** Downref: Normative reference to an Informational RFC: RFC 6234 [CS: Moved to Informative references] ** Downref: Normative reference to an Informational RFC: RFC 7251 [CS: Reference removed] ** Downref: Normative reference to an Informational RFC: RFC 8032 [CS: Moved to informative] =3D=3D Outdated reference: A later version (-04) exists of draft-ietf-ace-pubsub-profile-01 [CS: Fixed.] Appendix A: Perhaps add a reference to [I-D.ietf-ace-oauth-authz] for the origin of the checklist. [CS: Added: "Based on the requirements on profiles for the ACE framework [I-D.ietf-ace-oauth-authz], this document fulfills the following: " Nits: Section 1: The following list is somewhat hard to read. Current: Implementations MAY also use "application/ace+cbor" content type, and CBOR encoding [RFC8949], and CBOR Web Token (CWT) [RFC8392] and associated PoP semantics to reduce the protocol memory and bandwidth requirements. Perhaps: To reduce protocol memory and bandwidth requirements, implementations MAY also use 'application/ace+cbor' content type, CBOR encoding [RFC8949], and CBOR Web Token (CWT) [RFC8392] with its associated PoP semantics. [CS: Fixed] Section 2.2.3.2: Would it clarify the normative text= to split this sentence into two? Current: ...a client MAY omit support for the cipher suites TLS_PSK_WITH_AES_128_CCM_8 and TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8, but for TLS 1.2, MUST support TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256 for PSK and TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 for RPK, as recommended in [RFC7525] (and adjusted to be a PSK cipher suite as appropriate). Perhaps: ...a client MAY omit support for the cipher suites TLS_PSK_WITH_AES_128_CCM_8 and TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8. For TLS 1.2, however, a client MUST support ... [CS: Fixed] Section 2.3: "an an exact" / "an exact" [CS: Fixed] Section 2.4.1: Does the authentication check fail for any of these cases? Current: If the Client does not provide a valid token or omits the Authentication Data field and the Broker has no token stored for the Client or the token or Authentication data are malformed, or if the Will flag is set, the authorization checks for the Will topic fails, authentication fails. Perhaps: Authentication can fail for the following reasons: * the Client does not provide a valid token or omits the Authentication Data field, * the Broker has no token stored for the Client, * the token or Authentication data are malformed, or * if the Will flag is set, the authorization check for the Will topic fa= ils. [CS: the conditions are separated at each "or", so revised as: "Authentication can fail for the following reasons: o If the Client does not provide a valid token, o the Client omits the Authentication Data field and the Broker has no token stored for the Client, o the token or Authentication data are malformed, or o if the Will flag is set, the authorization checks for the Will topic fails." Section 3.3: "has a token token permits" / "has a token that permits" [CS: Fixed] Section 5: Would the following be clearer as a list? Current: The MQTT session state is identified by the Client Identifier and includes state on client subscriptions; messages with QoS levels 1 and 2, and which have not been completely acknowledged or are pending transmission to the Client; and if the Session is currently not connected, the time at which the Session will end and Session State will be discarded. Perhaps: The MQTT session state is identified by the Client Identifier and includes the following: * Client subscription state, * messages with QoS levels 1 and 2 that either have not been completely acknowledged or are pending transmission to the Client, and * if the Session is currently not connected, the time at which the Session will end and Session State will be discarded. [CS: Done] Section 6: Perhaps switching the order here would improve readability: Current: ... MQTT v5.0 clients are NOT RECOMMENDED to use the flows described in this section. Perhaps: ... the flows described in this section are NOT RECOMMENDED for use by MQTT v5.0 clients. [CS: Done] Figure 11: endoded / encoded [CS: Fixed] Section 6.2: "and not attempt" / "and do not attempt" [CS: Fixed] "no more authorized" / "no longer authorized" [CS: Fixed] Section 7.2: The spacing after the colons is inconsistent. [CS: Fixed to have all with a single space after the colon.] Formatting and terminology: According to Wikipedia, MQTT is no longer considered an acronym (i.e., it n= o longer needs to be expanded). [CS: Is it OK that we leave things as they are, as this will affect title e= tc.] Could the terms "RS" and "Broker" be consistently scoped? That is, "RS" is = used when talking about OAuth interactions, and "Broker" is used when talking ab= out MQTT interactions? (From Section 1: "In the rest of the document, the terms "RS", "MQTT Server" and "Broker" are used interchangeably.) [CS: Revised as much as possible so that Broker is used when we refer to th= e entity defined in this profile, and RS is used more for generic OAuth interactions] Check the use of single and double quotation marks, for instance: 'application/ace+json' vs "application/ace+cbor" '0x18 (Cont. Authentication)' vs "0x18 (Continue Authentication)" [CS: Switched to double quotes, but removed quotation marks around reason c= odes as in the MQTT standard.] Because the acronym for "proof-of-possession" was given in the introduction= , the rest of the instances can be replaced with "PoP". Same with other acron= yms used, like PSK. Just expand on first use and use the acronym thereafter. [CS: Done for PoP, was done for PSK/RPK for genart review.] --_000_HE1PR07MB42177EE2866E544D286A4AE9980A9HE1PR07MB4217eurp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Jean: tha= nk you very much for your thoughtful review! Cigdem, thank you for addressi= ng it, I do believe it improves the document.

&nbs= p;

Just one = note: for the downref to informative documents (for those documents that we= re actually included in the text), please revert the change =96 RFC 6234 an= d RFC 8032 were correctly referenced as normative, since they are mandatory to implement. MQTT standards are also = correctly referenced normatively. Jean was only noting these appear as down= refs, but downrefs are not =93mistakes=94, they just require more attention= =96 see https://www.rfc-editor.or= g/info/bcp97 for more information. Downrefs are usually Last Called to = make sure the community is aware of them, except for those that have appear= ed as downref for many documents and don=92t need to be Last Called explicitly anymore: https://datatracker.ietf.org/doc/downref/.

&nbs= p;

Thanks, Francesca

&nbs= p;

From: last-call <last-call-bounces@ietf.org= > on behalf of Cigdem Sengul <cigdem.sengul@gmail.com>
Date: Tuesday, 8 March 2022 at 19:37
To: Jean Mahoney <mahoney@nostrum.com>
Cc: art@ietf.org <art@ietf.org>, draft-ietf-ace-mqtt-tls-profi= le.all@ietf.org <draft-ietf-ace-mqtt-tls-profile.all@ietf.org>, last-= call@ietf.org <last-call@ietf.org>, Ace Wg <ace@ietf.org>
Subject: Re: [Last-Call] Artart last call review of draft-ietf-ace-m= qtt-tls-profile-14

Dear Jean, 

Thank you for your revi= ew. 

I implemented changes a= nd prepared a pull request at: https://github.com/ace-wg= /mqtt-tls-profile/pull/102

 

Below is a summary of h= ow I revised the text according to your suggestions, and corrected ref= erences for this document (removing unused references due to changes of tex= t etc.) I have still kept MQTT as normative, as the document is about MQTT, but is it expected to be informative when the = reference is a non-RFC?

 

Kind regards,=

--Cigdem 

 

On Fri, 4 Mar 2022 at 2= 1:40, Jean Mahoney via Datatracker <= noreply@ietf.org> wrote:

Reviewer: Jean Mahoney<= br> Review result: Ready with Issues

This document is ready but has minor issues with wording and references.
Minor issues:

Section 1: The subject seems to be missing in the following sentence.
Should "recommended" be normative?

Current:
   The Client-AS and RS-AS MAY also use protocols other
   than HTTP, e.g.  Constrained Application Protocol (CoAP) = [RFC7252] or
   MQTT; it is recommended that TLS is used to secure these
   communication channels between Client-AS and RS-AS.

Perhaps (add "exchanges", split into two sentences):
   The Client-AS and RS-AS exchanges MAY also use protocols other=
   than HTTP, e.g., Constrained Application Protocol (CoAP) [RFC7= 252] or
   MQTT. It is recommended that TLS is used to secure these
   communication channels between Client-AS and RS-AS.=

 

[CS: Done.]<= /p>

 


Section 2.2.4.2.2: I'm having difficulty parsing the following normative statements. Does "MUST" also cover the Authentication Data (i.e.,= MUST be set
to "ace" and MUST contain Authentication Data)? If the Authentica= tion Data MUST
NOT be empty, MUST it contain the 8-byte RS nonce or could it contain somet= hing
else?

Current:
   The AUTH packet to continue authentication includes the
   Authentication Method, which MUST be set to "ace" an= d Authentication
   Data.  The Authentication Data MUST NOT be empty and cont= ains an
   8-byte RS nonce as a challenge for the Client (Figure 6).=

 

[CS: Revised as:

The Broker c= ontinues authentication using an AUTH packet that contains the Authenticati= on Method

and the Auth= entication Data. The Authentication Method MUST be set to "ace", = and the Authentication Data MUST NOT be empty and contain

an 8-byte RS= nonce as a challenge for the Client.

]=

 


Section 4: I'm having difficulty parsing the following. Is it talking about=
using a challenge from the current TLS session?

Current:
   To re-authenticate, the
   Client MUST NOT use Proof-of-Possession using a challenge from= the
   TLS session during the same TLS session to avoid re-using the = same
   challenge value from the TLS-Exporter.

 

[CS: Revised:

If re-authenticating du= ring the current TLS session, the Client MUST NOT use the method
   described in Section 2.2.4.2.1, Proof-of-Possession using a ch= allenge
   from the TLS session, to avoid re-using the same challenge val= ue from

   the TLS-Ex= porter.

] 


Section 6.1: Could more guidance or examples of necessary policies be provi= ded
here?

Current:
   However, stored Session state can be discarded as a
   result of administrator policies, and Brokers SHOULD implement= the
   necessary policies to limit misuse.

 

[CS: Revised as:

"However, stored Session st= ate can be discarded as a result

of administr= ator action or policies (e.g. defining an automated

response bas= ed on storage capabilities), and Brokers SHOULD implement the necessary pol= icies to limit

misuse."<= /p>

 

Would this work?

]


References: idnits identifies the following issues. The three informative R= FCs
are already listed in the downrefs registry, though
(htt= ps://datatracker.ietf.org/doc/downref).

  =3D=3D Unused Reference: 'I-D.ietf-ace-oauth-params' is defined on l= ine 1499,
     but no explicit reference was found in the text

 

[CS: This is fixed base= d on the revision for genart review, and the ID is referenced.]<= /p>

 


  =3D=3D Unused Reference: 'RFC7251' is defined on line 1563, but no e= xplicit
     reference was found in the text 

[CS: Reference removed;= added RFC 8442 for the PSK cipher reference] 


  =3D=3D Unused Reference: 'RFC8422' is defined on line 1609, but no e= xplicit
     reference was found in the text

 

[CS: Now cited] 


  =3D=3D Unused Reference: 'RFC8705' is defined on line 1625, but no e= xplicit
     reference was found in the text

[CS: Removed as does no= t apply to the current text] 


  -- Possible downref: Non-RFC (?) normative reference: ref.
     'MQTT-OASIS-Standard'

  -- Possible downref: Non-RFC (?) normative reference: ref.
     'MQTT-OASIS-Standard-v5'

 

[CS: OK for these two, = I feel on the fence as the document is about MQTT. 

Is the downref sug= gested because this is a Non-RFC and a standard coming from OASIS]

 


  ** Downref: Normative reference to an Informational RFC: RFC 6234

 

[CS: Moved to Informati= ve references] 


  ** Downref: Normative reference to an Informational RFC: RFC 7251

 

[CS: Reference removed]=  


  ** Downref: Normative reference to an Informational RFC: RFC 8032

 

 [CS: Moved to inf= ormative]


  =3D=3D Outdated reference: A later version (-04) exists of
     draft-ietf-ace-pubsub-profile-01

 

[CS: Fixed.] =


Appendix A: Perhaps add a reference to [I-D.ietf-ace-oauth-authz] for the origin of the checklist.

 

[CS: Added:<= /p>

"Based on the requ= irements on profiles for the ACE framework

   [I-D.ietf-= ace-oauth-authz], this document fulfills the following: "


Nits:

Section 1: The following list is somewhat hard to read.

Current:
   Implementations
   MAY also use "application/ace+cbor" content type, an= d CBOR encoding
   [RFC8949], and CBOR Web Token (CWT) [RFC8392] and associated P= oP
   semantics to reduce the protocol memory and bandwidth requirem= ents.

Perhaps:
   To reduce protocol memory and bandwidth requirements, implemen= tations
   MAY also use 'application/ace+cbor' content type, CBOR encodin= g
   [RFC8949], and CBOR Web Token (CWT) [RFC8392] with its associa= ted PoP
   semantics.

 

[CS: Fixed] <= /o:p>


Section 2.2.3.2: Would it clarify the normative text to split this sentence
into two?

Current:
   ...a client MAY omit support for the cipher suites
  TLS_PSK_WITH_AES_128_CCM_8 and TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8,    but for TLS 1.2, MUST support TLS_ECDHE_PSK_WITH_AES_128_GCM_S= HA256
   for PSK and TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 for RPK, a= s
   recommended in [RFC7525] (and adjusted to be a PSK cipher suit= e as
   appropriate).

Perhaps:
   ...a client MAY omit support for the cipher suites
   TLS_PSK_WITH_AES_128_CCM_8 and TLS_ECDHE_ECDSA_WITH_AES_128_CC= M_8.
   For TLS 1.2, however, a client MUST support ...

 

[CS: Fixed] <= /o:p>


Section 2.3: "an an exact" / "an exact"

 

[CS: Fixed] <= /o:p>


Section 2.4.1: Does the authentication check fail for any of these cases?
Current:
   If the Client does not provide a valid token or omits the
   Authentication Data field and the Broker has no token stored f= or the
   Client or the token or Authentication data are malformed, or i= f the
   Will flag is set, the authorization checks for the Will topic = fails,
   authentication fails.

Perhaps:
   Authentication can fail for the following reasons:

   * the Client does not provide a valid token or omits the Authe= ntication
     Data field,

   * the Broker has no token stored for the Client,

   * the token or Authentication data are malformed, or

   * if the Will flag is set, the authorization check for the Wil= l topic fails.

 

[CS: the conditions are= separated at each "or", so revised as:

"Authentication ca= n fail for the following reasons:


   o  If the Client does not provide a valid token,

   o  the Client omits the Authentication Data field and the= Broker has
      no token stored for the Client,

   o  the token or Authentication data are malformed, or

   o  if the Will flag is set, the authorization checks for = the Will
      topic fails."

 

 


Section 3.3: "has a token token permits" / "has a token that= permits"

[CS: Fixed] <= /o:p>


Section 5: Would the following be clearer as a list?

Current:
   The MQTT session state is
   identified by the Client Identifier and includes state on clie= nt
   subscriptions; messages with QoS levels 1 and 2, and which hav= e not
   been completely acknowledged or are pending transmission to th= e
   Client; and if the Session is currently not connected, the tim= e at
   which the Session will end and Session State will be discarded= .

Perhaps:
   The MQTT session state is identified by the Client Identifier = and
   includes the following:

   * Client subscription state,

   * messages with QoS levels 1 and 2 that either have not been      completely acknowledged or are pending transmission to = the
     Client, and

   * if the Session is currently not connected, the time at which= the
     Session will end and Session State will be discarded.

 

[CS: Done] 


Section 6: Perhaps switching the order here would improve readability:

Current:
   ... MQTT v5.0 clients are NOT
   RECOMMENDED to use the flows described in this section.

Perhaps:
   ... the flows described in this section are NOT RECOMMENDED fo= r
   use by MQTT v5.0 clients.

[CS: Done]

 


Figure 11: endoded / encoded

 

[CS: Fixed] <= /o:p>


Section 6.2:  "and not attempt" / "and do not attempt&q= uot;

 

[CS: Fixed] <= /o:p>


              "no more authorized&q= uot; / "no longer authorized"

[CS: Fixed] <= /o:p>


Section 7.2: The spacing after the colons is inconsistent.

 

[CS: Fixed to have all = with a single space after the colon.] 


Formatting and terminology:

According to Wikipedia, MQTT is no longer considered an acronym (i.e., it n= o
longer needs to be expanded).

[CS: Is it OK that we l= eave things as they are, as this will affect title etc.]


Could the terms "RS" and "Broker" be consistently scope= d? That is, "RS" is used
when talking about OAuth interactions, and "Broker" is used when = talking about
MQTT interactions? (From Section 1: "In the rest of the document, the = terms
"RS", "MQTT Server" and "Broker" are used int= erchangeably.)

 

[CS: Revised as much as= possible so that Broker is used when we refer to the entity defined in thi= s profile, 

and RS is used more for= generic OAuth interactions] 


Check the use of single and double quotation marks, for instance:

   'application/ace+json' vs "application/ace+cbor"
   '0x18 (Cont. Authentication)' vs "0x18 (Continue Authenti= cation)"

 

[CS: Switched to double= quotes, but removed quotation marks around reason codes as in the MQTT sta= ndard.]

 


Because the acronym for "proof-of-possession" was given in the in= troduction,
the rest of the instances can be replaced with "PoP". Same with o= ther acronyms
used, like PSK. Just expand on first use and use the acronym thereafter.

[CS: Done for PoP, was = done for PSK/RPK for genart review.] 

--_000_HE1PR07MB42177EE2866E544D286A4AE9980A9HE1PR07MB4217eurp_--