From nobody Mon Jul 1 15:02:46 2019 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 E4FBA1200E7; Mon, 1 Jul 2019 15:02:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 3iLUHAc81B2v; Mon, 1 Jul 2019 15:02:41 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 549C0120180; Mon, 1 Jul 2019 15:02:35 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 1 Jul 2019 15:02:29 -0700 From: Jim Schaad To: CC: Date: Mon, 1 Jul 2019 15:02:27 -0700 Message-ID: <100401d53058$adaba420$0902ec60$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdUwVMsPrO4eaCUqSFed24IOTUzCIA== Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: [Ace] Possible issues to be resolved 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: Mon, 01 Jul 2019 22:02:45 -0000 I was trying to get some work done in terms of getting this profile implemented and came up with the following questions: 1. In section 3.1, it references the kid that was assigned in section 3.2. I was not able to find a kid field in Table 1. How is this value to be obtained? 2. In section 3.2, the following requirements are imposed: * The AS MAY assign an identifier to the client * The AS MUST assign an identifier to the RS * The client identifiers MUST be unique in the set of all clients on a single RS * The RS identifiers MUST be unique in the set of all RS for any given client. If it is not required to assign an identifier for the client, how can it be unique? If there are multiple AS, each with a set of unique RS, are the AS servers expected to coordinate in order to make the RS identifiers unique? 3. The example in figure 5 is incorrect. It should be single not double quotes for clientId and serverId. 4. Please review the update CWT example with the most recent profile text on having only a single CWT on the RS. I don't know that this needs an update but it probably does. 5. If the AS creates a new, from scratch, CWT with the same clientId in the case of a change in permissions, what happens with regards to the RS matching to an existing context as oppose to treating it as a conflict. This is going to be potentially even more of a problem in the case that the RS changed the client ID and did not keep the full CWT around. Jim From nobody Wed Jul 3 01:20:07 2019 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 2F1B61207AD; Wed, 3 Jul 2019 01:19:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=unavailable autolearn_force=no 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 e5tujRalLeCV; Wed, 3 Jul 2019 01:19:31 -0700 (PDT) Received: from smtp.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 220BD120784; Wed, 3 Jul 2019 01:19:31 -0700 (PDT) Received: from [192.168.217.110] (p548DC676.dip0.t-ipconnect.de [84.141.198.118]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.uni-bremen.de (Postfix) with ESMTPSA id 45dvCj0bQjzyXp; Wed, 3 Jul 2019 10:19:29 +0200 (CEST) From: Carsten Bormann Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mao-Original-Outgoing-Id: 583834767.013062-bdf4889171780bfa535d450990982355 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Wed, 3 Jul 2019 10:19:28 +0200 Message-Id: To: Ace Wg , core , cose , cbor@ietf.org, t2trg@irtf.org X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: [Ace] Constrained Node/Network Cluster @ IETF105: FINAL AGENDA 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, 03 Jul 2019 08:19:40 -0000 From nobody Wed Jul 3 01:39:11 2019 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 7E51B120691; Wed, 3 Jul 2019 01:39:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 NxBvF5fFf-i6; Wed, 3 Jul 2019 01:39:07 -0700 (PDT) Received: from smtp.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87B851202E3; Wed, 3 Jul 2019 01:39:07 -0700 (PDT) Received: from [192.168.217.110] (p548DC676.dip0.t-ipconnect.de [84.141.198.118]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.uni-bremen.de (Postfix) with ESMTPSA id 45dvDl2NLzzyTX; Wed, 3 Jul 2019 10:20:23 +0200 (CEST) From: Carsten Bormann Content-Type: text/plain; charset=utf-8 X-Mao-Original-Outgoing-Id: 583834821.1630419-43cd4d155cf509da54f578df08c885de Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Message-Id: Date: Wed, 3 Jul 2019 10:20:23 +0200 To: Ace Wg , core , cose , cbor@ietf.org, t2trg@irtf.org X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: [Ace] Constrained Node/Network Cluster @ IETF105: FINAL AGENDA 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, 03 Jul 2019 08:39:10 -0000 Here is my usual eclectic condensed agenda based on the FINAL AGENDA for IETF105. Remember that, even though this will now go to the printers, there is still some potential for changes. Conflicts that meet the eye: COSE/TEEP stays; ROLL/SUIT/DINRG and 6TISCH/ACE are maybe slightly less annoying. LAKE and LOOPS have been disentangled, thank you. I have put in some side meetings, but that picture may still change (and I don't understand the timezone logic of that system, so it may be all wrong). All times are EDT (Eastern Daylight Time) =3D=3D UTC -4 hours. (Pure UTC times at https://datatracker.ietf.org/meeting/agenda-utc are useful for those who want to listen from remote.) Gr=C3=BC=C3=9Fe, Carsten FRIDAY, July 19, 2019 -- OMA/T2TRG Work Meeting - @ Ericsson Montreal Office (St-Laurent) SATURDAY/SUNDAY, July 20/21, 2019 -- Hackathon (including various interops) - Centre Ville SUNDAY, July 21, 2019 -- Sun 1700-1900 Welcome Reception - Place du Canada -- Sun 1800-2000 Hot RFC Lightning Talks - Viger MONDAY, July 22, 2019 1000-1200 Morning Session I Van Horne SEC acme Automated Certificate Management = Environment WG St-Catherine SEC *** teep Trusted Execution Environment = Provisioning WG Laurier TSV loops Local Optimizations on Path Segments BOF 1330-1530 Afternoon Session I St-Catherine INT *** 6lo IPv6 over Networks of = Resource-constrained Nodes WG Place du Canada SEC secdispatch Security Dispatch WG Van Horne TSV taps Transport Services WG 1550-1750 Afternoon Session II Laurier ART httpbis Hypertext Transfer Protocol WG St-Catherine OPS v6ops IPv6 Operations WG Van Horne SEC *** lake Lightweight Authenticated Key Exchange = BOF 1810-1910 Afternoon Session III Laurier ART dispatch Dispatch WG - Joint with ARTAREA TUESDAY, July 23, 2019 0830-0945 Side Meetings / Open Time C2 (21st Floor) IoT Onboarding and MUD (0900..1030?) Place du Canada IETF tdd Technology Deep Dive - How NICs Work = Today 1000-1200 Morning Session I St-Catherine ART *** cbor Concise Binary Object Representation = Maintenance and Extensions WG - 1000-1130 St-Catherine INT ipwave IP Wireless Access in Vehicular = Environments WG - 1130-1200 Notre Dame IRTF icnrg Information-Centric Networking Duluth OPS anima Autonomic Networking Integrated Model = and Approach WG Van Horne SEC cacao Collaborative Automated Course of Action = Operations for Cyber Security BOF Place du Canada TSV quic QUIC WG 1330-1500 Afternoon Session I Centre Ville OPS anima Autonomic Networking Integrated Model = and Approach WG 1520-1650 Afternoon Session II Duluth INT intarea Internet Area Working Group WG Place du Canada IRTF irtfopen IRTF Open Meeting Van Horne SEC oauth Web Authorization Protocol WG Collier CoRAL side meeting (1500..1700?) 1710-1810 Afternoon Session III Duluth ART *** core Constrained RESTful Environments WG Laurier INT 6man IPv6 Maintenance WG Place du Canada SEC tls Transport Layer Security WG WEDNESDAY, July 24, 2019 1000-1200 Morning Session I Van Horne IRTF*** dinrg Decentralized Internet Infrastructure St-Catherine RTG *** roll Routing Over Low power and Lossy = networks WG Viger SEC *** suit Software Updates for Internet of Things = WG Place du Canada TSV quic QUIC WG 1330-1530 Afternoon Session I Place du Canada GEN netrqmts IETF Meeting Network = Requirements BOF Laurier IRTF pearg Privacy Enhancements and Assessments = Research Group Viger IRTF*** t2trg Thing-to-Thing St-Catherine RTG bier Bit Indexed Explicit Replication WG Centre Ville RTG detnet Deterministic Networking WG 1550-1650 Afternoon Session II St-Catherine RTG babel Babel routing protocol WG Centre Ville RTG detnet Deterministic Networking WG Van Horne SEC *** rats Remote ATtestation ProcedureS WG THURSDAY, July 25, 2019 1000-1200 Morning Session I Duluth ART *** core Constrained RESTful Environments WG Place du Canada SEC tls Transport Layer Security WG Laurier TSV tsvwg Transport Area Working Group WG 1330-1530 Afternoon Session I Duluth INT dnssd Extensions for Scalable DNS Service = Discovery WG Viger IRTF coinrg Computing in the Network Proposed = Research Group Laurier IRTF panrg Path Aware Networking RG Place du Canada SEC saag Security Area Open Meeting 1550-1720 Afternoon Session II Laurier ART httpbis Hypertext Transfer Protocol WG Duluth INT 6man IPv6 Maintenance WG Place du Canada IRTF cfrg Crypto Forum Van Horne RTG rift Routing In Fat Trees WG St-Catherine SEC *** rats Remote ATtestation ProcedureS WG Centre Ville TSV tsvarea Transport Area Open Meeting 1740-1910 Afternoon Session III Duluth INT *** 6tisch IPv6 over the TSCH mode of IEEE = 802.15.4e WG Centre Ville SEC *** ace Authentication and Authorization for = Constrained Environments WG Place du Canada SEC mls Messaging Layer Security WG St-Catherine TSV rmcat RTP Media Congestion Avoidance = Techniques WG FRIDAY, July 26, 2019 1000-1200 Morning Session I Notre Dame ART ice Interactive Connectivity Establishment = WG Centre Ville INT *** lpwan IPv6 over Low Power Wide-Area Networks = WG Place du Canada IRTF maprg Measurement and Analysis for Protocols Laurier SEC mls Messaging Layer Security WG Duluth SEC oauth Web Authorization Protocol WG 1220-1350 Afternoon Session I Van Horne SEC *** cose CBOR Object Signing and Encryption WG St-Catherine SEC *** teep Trusted Execution Environment = Provisioning WG Place du Canada TSV tsvwg Transport Area Working Group WG From nobody Wed Jul 3 09:50:43 2019 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 6F5C1120432 for ; Wed, 3 Jul 2019 09:50:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 61SX8iPNcWtB for ; Wed, 3 Jul 2019 09:50:35 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 735E6120496 for ; Wed, 3 Jul 2019 09:50:34 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 3 Jul 2019 09:50:27 -0700 From: Jim Schaad To: Date: Wed, 3 Jul 2019 09:50:26 -0700 Message-ID: <131801d531bf$6be286e0$43a794a0$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_1319_01D53184.BF842410" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdUxvto1bn33DDjkQBy0vEuiankoRA== Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: [Ace] Filling out the agenda for Montreal 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, 03 Jul 2019 16:50:42 -0000 ------=_NextPart_000_1319_01D53184.BF842410 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit It is time for the chairs to start building the agenda for the F2F in Montreal. If you want a presentation slot, please let ace-chairs@ietf.org know the following: * What document or topic is this about * Who is doing the presentation * How long you think this will take * Are you going to be remote, if so is there going to be a backup locally * Will there be a new document published by the deadline As always - try and get use the slides well before the meeting so people can look at them and get some topic background if needed. Please try and get the presentations focused on where the authors need input from the working group rather than a history of what is being done and what has been changed. Use the F2F time wisely. Jim ------=_NextPart_000_1319_01D53184.BF842410 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

It is time for the chairs to start building the agenda = for the F2F in Montreal.  If you want a presentation slot, please = let  ace-chairs@ietf.org = know the following:

 

  • What document or topic = is this about
  • Who is doing the = presentation
  • How long you think = this will take
  • Are you going to be = remote, if so is there going to be a backup locally
  • Will there be a new document published by the = deadline

 

As always = – try and get use the slides well before the meeting so people can = look at them and get some topic background if needed.  Please try = and get the presentations focused on where the authors need input from = the working group rather than a history of what is being done and what = has been changed.  Use the F2F time wisely.

 

Jim

 

------=_NextPart_000_1319_01D53184.BF842410-- From nobody Fri Jul 5 05:15:57 2019 Return-Path: X-Original-To: ace@ietf.org Delivered-To: ace@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 20C741201D6; Fri, 5 Jul 2019 05:15:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ace@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.98.2 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ace@ietf.org Message-ID: <156232894904.21728.15957687723306707312@ietfa.amsl.com> Date: Fri, 05 Jul 2019 05:15:49 -0700 Archived-At: Subject: [Ace] I-D Action: draft-ietf-ace-key-groupcomm-02.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2019 12:15:49 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Authentication and Authorization for Constrained Environments WG of the IETF. Title : Key Provisioning for Group Communication using ACE Authors : Francesca Palombini Marco Tiloca Filename : draft-ietf-ace-key-groupcomm-02.txt Pages : 36 Date : 2019-07-05 Abstract: This document defines message formats and procedures for requesting and distributing group keying material using the ACE framework, to protect communications between group members. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ace-key-groupcomm/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ace-key-groupcomm-02 https://datatracker.ietf.org/doc/html/draft-ietf-ace-key-groupcomm-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-key-groupcomm-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jul 5 10:40:42 2019 Return-Path: X-Original-To: ace@ietf.org Delivered-To: ace@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FBE91201EB; Fri, 5 Jul 2019 10:40:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ace@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.98.2 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ace@ietf.org Message-ID: <156234843637.21671.8484280337022799312@ietfa.amsl.com> Date: Fri, 05 Jul 2019 10:40:36 -0700 Archived-At: Subject: [Ace] I-D Action: draft-ietf-ace-key-groupcomm-oscore-02.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2019 17:40:41 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Authentication and Authorization for Constrained Environments WG of the IETF. Title : Key Management for OSCORE Groups in ACE Authors : Marco Tiloca Jiye Park Francesca Palombini Filename : draft-ietf-ace-key-groupcomm-oscore-02.txt Pages : 30 Date : 2019-07-05 Abstract: This document describes a method to request and provision keying material in group communication scenarios where the group communication is based on CoAP and secured with Object Security for Constrained RESTful Environments (OSCORE). The proposed method delegates the authentication and authorization of new client nodes that join an OSCORE group through a Group Manager server. This approach builds on the ACE framework for Authentication and Authorization, and leverages protocol-specific transport profiles of ACE to achieve communication security, proof-of-possession and server authentication. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ace-key-groupcomm-oscore/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ace-key-groupcomm-oscore-02 https://datatracker.ietf.org/doc/html/draft-ietf-ace-key-groupcomm-oscore-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-key-groupcomm-oscore-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 8 07:35:26 2019 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 338D4120236 for ; Mon, 8 Jul 2019 07:35:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, 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 To8MTO3EwYYi for ; Mon, 8 Jul 2019 07:35:09 -0700 (PDT) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60085.outbound.protection.outlook.com [40.107.6.85]) (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 20EEA1201A0 for ; Mon, 8 Jul 2019 07:35:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XF1F4UziWLj1leBIM+01vsiH/dWWHWZglTkQMZQau4NEvT6JqbtqQ2Oeo/BqGw9hfGGht0OUvOEfj3krFbi7y7QH8d0Q5eRPgILH3QtAIslzvg0CGuPd38XqVvaq89giWI10XH7/00fIP4cWHC4vaZYZ8a1a2QCGfk5fES3LxcdkGQxKe42snJjRA8v7r+7BRfDIxADNnlci6C0FCtqbJVxtvR486M/HuDZT+DoKHyn7/pXL9d1S62pLn2Afav62p6Zm76qb1VSFdn6dzDak7Q7ChqOreg8uLDsHcrdyBBtVowFrwHXAAVVl3JvLfCWdyqhCPS4+3EgK5ojb+bUinw== 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-SenderADCheck; bh=ZtfqMElVrIVVpSFUUqIvwytS0cRKs4BY2CJIYtF29xY=; b=QmbrgZxyphyF2a+3mWl1wiIY70MFyXyhxIZlUCSpsW/m4ywiuToAPI2l2g8WMbN/1mLjDotC6t1F+qCacgcfzfiFwjgK7gPJON0fDrXjPECHNRAz+SSHbPBy5yvhSi/Ik9axuAZJB8xbqQ+w8YvsxVGGfKtRhbWFH6dtHDbArVxiILTouptYfWTAkzBCjtU/7cK31/OZx/fwakvLXL3I+wuWWWUrz8MqSCuYYucpQqDyYPc7VP5LUKCQzj9Iw1R4HmwHM9W/9L/eXurvnFPQePDleCDCPBJiQrguKemtpOMin/KHYLVopGWkVEyX9Nnb4gf3eQftJgadXgSanK/69Q== 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=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ZtfqMElVrIVVpSFUUqIvwytS0cRKs4BY2CJIYtF29xY=; b=BMaqLYP3pMp9A12EN0PXFtwSx7h3WYiQcWLVM1R2s7CqC8bh70L98yXFP7XyC0CufHXW/46TWpK3fEsYFacIOLqxiAVdI7GELudZfWSTb9Wsg2X/aK4hj0agxVVhxS7TVdfHDbgknU6Xt76NIb65W4fue9OpMqmMoL2AetysjjA= Received: from HE1PR0701MB2746.eurprd07.prod.outlook.com (10.168.185.17) by HE1PR0701MB2442.eurprd07.prod.outlook.com (10.168.128.136) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2073.7; Mon, 8 Jul 2019 14:35:03 +0000 Received: from HE1PR0701MB2746.eurprd07.prod.outlook.com ([fe80::d958:9685:d091:3b9a]) by HE1PR0701MB2746.eurprd07.prod.outlook.com ([fe80::d958:9685:d091:3b9a%3]) with mapi id 15.20.2073.008; Mon, 8 Jul 2019 14:35:03 +0000 From: Francesca Palombini To: Marco Tiloca , "ace@ietf.org" Thread-Topic: [Ace] Comments draft-palombini-ace-coap-pubsub-profile-04 Thread-Index: AQHU7qzQFt4F2rm7+kuMJHE7mGDl7abBeNQA Date: Mon, 8 Jul 2019 14:35:03 +0000 Message-ID: <628B690B-0D38-44F8-BDEA-CC1195F4524C@ericsson.com> References: <7ccc6f5e-fdc2-95e2-b1b6-01f2708e0cd9@ri.se> In-Reply-To: <7ccc6f5e-fdc2-95e2-b1b6-01f2708e0cd9@ri.se> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=francesca.palombini@ericsson.com; x-originating-ip: [158.174.219.143] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 9974bb7a-dcd4-4835-91b5-08d703b1771e x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:HE1PR0701MB2442; x-ms-traffictypediagnostic: HE1PR0701MB2442: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 00922518D8 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(346002)(396003)(136003)(39860400002)(376002)(199004)(189003)(55674003)(53936002)(33656002)(3846002)(478600001)(6116002)(6246003)(25786009)(76116006)(66946007)(66556008)(486006)(36756003)(66574012)(2501003)(5660300002)(86362001)(64756008)(66476007)(73956011)(316002)(66446008)(6306002)(6512007)(6436002)(6486002)(229853002)(110136005)(81166006)(71200400001)(81156014)(8936002)(71190400001)(26005)(2906002)(186003)(76176011)(6506007)(102836004)(99286004)(7736002)(256004)(66066001)(68736007)(305945005)(966005)(44832011)(446003)(11346002)(14444005)(14454004)(476003)(8676002)(2616005); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2442; H:HE1PR0701MB2746.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: MV19jVycKGOZwr+MD8huCFOfCIFiLgwIHORoqXw+K0PWNrLomdmxq3qDFnFuu9e/jgPbGhmi6essso5ofmSMv7ObRPKoLetxSkx3yJWOkfbLammD8lf8k79GI/G1UwPkEb6RFI8mUyreaetuowcrO55N8z2o0+iAKW+Y5neuwtjDvYqdqS1TgHrxKxZQj0OmA/D5Q5rf+Scs24iu+6q72Zp4Pl61hfH1GeoxVhiiPb5u1FKQSzUeV+Nz9I5b76pv5ZPoiYg2wxx25WsbWOqoJHdpQBCpNybrZAwG+1gF3FTmNhqfxqlkOqJenEj/zqehzm2sZWpTRknhTignefQO9gS282M7ZFFZbO0SkBMHUy2nxMFW35a6Ic+8oLH8dIeD1xL19WgLWOChs3YS3Oda2kRmzTbTmRNIGfvRtN9KPhM= Content-Type: text/plain; charset="utf-8" Content-ID: <428753A1AADCB24094AABBC8FCBDF659@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 9974bb7a-dcd4-4835-91b5-08d703b1771e X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jul 2019 14:35:03.4883 (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: francesca.palombini@ericsson.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2442 Archived-At: Subject: Re: [Ace] Comments draft-palombini-ace-coap-pubsub-profile-04 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: Mon, 08 Jul 2019 14:35:21 -0000 SGkgTWFyY28sDQoNClRoYW5rcyBhIGxvdCBmb3IgdGhpcyByZXZpZXchIEkgZmluYWxseSBtYW5h Z2VkIHRvIGluY2x1ZGUgeW91ciBjb21tZW50cyBhbmQgdXBkYXRlIHRoZSBkb2N1bWVudCwgYW5k IHdpbGwgYmUgcG9zdGluZyBhIG5ldyB2ZXJzaW9uIHNvb24uIFlvdSBjYW4gc2VlIHRoZSBQUiB0 byB0aGlzIHVwZGF0ZSBoZXJlIGluIHRoZSBtZWFudGltZTogaHR0cHM6Ly9naXRodWIuY29tL0Vy aWNzc29uUmVzZWFyY2gvY29hcC1wdWJzdWItcHJvZmlsZS9wdWxsLzIgDQpBbnN3ZXJzIGlubGlu ZS4NCg0KVGhhbmtzLA0KRnJhbmNlc2NhDQoNCu+7v09uIDA5LzA0LzIwMTksIDEwOjE4LCAiQWNl IG9uIGJlaGFsZiBvZiBNYXJjbyBUaWxvY2EiIDxhY2UtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhh bGYgb2YgbWFyY28udGlsb2NhQHJpLnNlPiB3cm90ZToNCg0KICAgIEhpLA0KICAgIA0KICAgIFBs ZWFzZSwgZmluZCBiZWxvdyBzb21lIGNvbW1lbnRzIG9uIHRoaXMgcHJvZmlsZS4gSSBob3BlIGl0 IGhlbHBzIQ0KICAgIA0KICAgIEJlc3QsDQogICAgL01hcmNvDQogICAgDQogICAgLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQogICAgDQogICAgW0Fic3RyYWN0XQ0KICAgIA0KICAgICJUaGlzIHBy b2ZpbGUgcmVsaWVzIG9uIHRyYW5zcG9ydCBsYXllciBvciBhcHBsaWNhdGlvbiBsYXllciBzZWN1 cml0eSB0bw0KICAgIGF1dGhvcml6ZSB0aGUgcHVibGlzaGVyIHRvIHRoZSBicm9rZXIiIGlzIGR1 ZSB0byB0aGUgY3VycmVudCBwcm9maWxlcyBvZg0KICAgIEFDRSwgcmlnaHQ/IE90aGVyd2lzZSwg dGhpcyBjYW4gYmUgKGV2ZW4pIG1vcmUgZ2VuZXJhbCB3aXRob3V0DQogICAgbWVudGlvbmluZyBw YXJ0aWN1bGFyIGxheWVycy4NCiAgICANCkZQOiBUaGF0IGlzIGNvcnJlY3QsIHRoYXQgaXMgZHVl IHRvIHdoYXQgcHJvZmlsZSBvZiBBQ0UgaXMgdXNlZC4gSSBoYXZlbid0IG1hZGUgYSBjaGFuZ2Ug aGVyZS4NCiAgICANCiAgICBbU2VjdGlvbiAxXQ0KICAgIA0KICAgIEhlcmUgdGhlIGNsYWltZWQg c2NvcGUgaXMgYXV0aG9yaXppbmcgbm9kZXMsIGJ1dCBpdCBpcyBhY3R1YWxseSBhbHNvDQogICAg YWJvdXQga2V5IHByb3Zpc2lvbmluZyAoU2VjdGlvbiAzLjEpIGFuZCBhY3R1YWwgY29tbXVuaWNh dGlvbiAoU2VjdGlvbiA2LjEpLg0KICAgIA0KRlA6IFJpZ2h0LCBJIGFkZGVkIHNvbWUgdGV4dCBh Ym91dCB0aGF0Lg0KICAgIA0KICAgIFtTZWN0aW9uIDJdDQogICAgDQogICAgSGVyZSB0aGUgY2xh aW1lZCBzY29wZSBpcyBwcm90ZWN0aW5nIGNvbW11bmljYXRpb24gKGluIGEgYnJvYWQgc2Vuc2Up LA0KICAgIHdoaWxlIGl0IGNhbiBhZ2FpbiBtZW50aW9uIGFsc28gYXV0aG9yaXppbmcgbm9kZXMg KGFzIHBlciBBQ0UpIGFuZCBrZXkNCiAgICBwcm92aXNpb25pbmcgKFNlY3Rpb24gMy4xKS4NCg0K RlA6IFllcywgYWRkZWQgdGV4dCBhYm91dCB0aGF0IGFzIHdlbGwuDQogICAgDQogICAgSSBiZWxp ZXZlIHRoYXQgdGhlIHBhcmFncmFwaCAiVGhlcmUgYXJlIGZvdXIgcGhhc2VzLCAuLi4iIGFuZCB0 aGUNCiAgICBudW1iZXJlZCBsaXN0IHdvdWxkIHJlYWQgYmV0dGVyIGlmIHBsYWNlZCByaWdodCBi ZWZvcmUgdGhlIGZpbmFsDQogICAgcGFyYWdyYXBoICJOb3RlIHRoYXQgQVMxIGFuZCBBUzIgLi4u Ig0KICAgIA0KRlA6IEkgdHJpZWQgdG8gbWFrZSB0aGlzIGNoYW5nZSBidXQgY291bGQgbm90IHNw bGl0IHRoZSBudW1iZXJlZCBsaXN0IGZyb20gdGhlIGZvbGxvd2luZyBwYXJhZ3JhcGgsIHNpbmNl IGl0IHRhbGtzIGFib3V0IHRoaXMgZXhjaGFuZ2UgaW4gcGFydGljdWxhciwgc28gSSBlbmRlZCB1 cCBub3QgaW1wbGVtZW50aW5nIHRoaXMgb25lLiBXZSBjYW4gZGlzY3VzcyBtb3JlIGFib3V0IHRo aXMuDQogICAgDQogICAgW1NlY3Rpb24gMy4xXQ0KICAgIA0KICAgIEkgdGhpbmsgdGhpcyB3aWxs IGFsc28gbmVlZCBhIHdheSBmb3IgY2xpZW50cyB0byBhZ3JlZSB3aXRoIHRoZSBBUzIgb24NCiAg ICB0aGUgY29ycmVjdCBmb3JtYXQgb2YgdGhlaXIgb3duIHB1YmxpYyBrZXkgKGlmIHRoZXkgZG9u J3Qga25vdyBhbHJlYWR5KSwNCiAgICBzaW1pbGFybHkgdG8gd2hhdCBzdWdnZXN0ZWQgaW4gYWNl LWtleS1ncm91cGNvbW0tb3Njb3JlLiBUaGUgb25seSB0eXBlDQogICAgb2YgYXBwcm9hY2ggdGhh dCB3b3VsZCBub3Qgd29yayBpcyB0aGUgb25lIGVtYmVkZGVkIHdpdGggYSBUb2tlbiBQT1NULA0K ICAgIHNpbmNlIHRoYXQgZG9lcyBub3QgaGFwcGVuIHdpdGggQVMyLg0KDQpGUDogUmlnaHQsIEkg bm93IHNwZWNpZmllZCB0aGUgb3B0aW9uYWwga2V5IGZvcm1hdCBuZWdvY2lhdGlvbiBpbiB0aGUg ZG9jdW1lbnQuIA0KICAgIA0KICAgIFRoZSB0ZXh0IHNheXM6ICIuLi4gdGhlIEFTMiBpcyBib3Ro IHRoZSBBUyBhbmQgdGhlIEtEQywgLi4uIHNvIHRoZQ0KICAgIEF1dGhvcml6YXRpb24gUmVzcG9u c2UgYW5kIHRoZSBQb3N0IFRva2VuIG1lc3NhZ2UgYXJlIG5vdCBuZWNlc3NhcnkiIC4NCiAgICBT aG91bGRuJ3Qgd2UgdGhlbiBoYXZlIHRoZSBUb2tlbiBQT1NUIHRvIHRoZSBLREMgZGVmaW5lZCBh cyBvcHRpb25hbA0KICAgIGFscmVhZHkgaW4gYWNlLWtleS1ncm91cGNvbW0gPyBTZWUgZm9yIGlu c3RhbmNlIGl0cyBGaWd1cmUgMi4NCg0KRlA6IE5vLCB3ZSBkbyBub3QgbmVlZCB0byBjaGFuZ2Ug dGhhdCBpbiBLZXkgZ3JvdXBjb21tLCBhcyB0aGF0IHdvdWxkIGJlIG1vcmUgY29tcGxpY2F0ZWQg dG8gbW90aXZhdGUuDQogICAgDQogICAgSW4gdGhlIEtleSBEaXN0cmlidXRpb24gUmVxdWVzdCwg b25seSBvbmUgcm9sZSBjYW4gYmUgaW5kaWNhdGVkIGluDQogICAgc2NvcGUuIFdoYXQgaWYgYSBj bGllbnQgd2FudHMgdG8gYmUgYm90aCBwdWJsaXNoZXIgYW5kIHN1YnNjcmliZXI/IFRoaXMNCiAg ICBzZWVtcyBhbGxvd2VkIGluIFNlY3Rpb24gMy4zIG9mIGNvcmUtY29hcC1wdWJzdWIgLiBTaG91 bGQgYSBjbGllbnQNCiAgICBzZXBhcmF0ZWx5IGNvbnRhY3QgdGhlIEFTMiBtdWx0aXBsZSB0aW1l cz8NCiAgICANCkZQOiBGaXhlZCB0aGF0Lg0KDQogICAgSW4gdGhlIEF1dGhvcml6YXRpb24gUmVz cG9uc2UsIHRoZSAncHJvZmlsZScgZmllbGQgY2FuIHBvaW50IGF0IFNlY3Rpb24NCiAgICA4LjEg d2hlcmUgdGhlIHByb2ZpbGUgdmFsdWUgaXMgZGVmaW5lZC4NCg0KRlA6IE9rLCBkb25lLg0KICAg IA0KICAgIEluIHRoZSBBdXRob3JpemF0aW9uIFJlc3BvbnNlLCBzZWUgYWJvdmUgZm9yIHRoZSAn c2NvcGUnIGZpZWxkIGluIGNhc2UNCiAgICBvZiBhIGNsaWVudCB0aGF0IHdhbnRzIHR3byByb2xl cy4NCiAgICANCkZQOiBZZXMsIHNhbWUuDQogICAgDQogICAgW1NlY3Rpb24gNF0NCiAgICANCiAg ICBQYWdlIDgsIHNlY29uZCBidWxsZXQgcG9pbnQsIGl0IGNhbiBzYXkgIi4uLiBwcm90ZWN0IHRo ZSBwdWJsaWNhdGlvbg0KICAgIGVuZC10by1lbmQgd2l0aCB0aGUgc3Vic2NyaWJlcnMgKHNlZSBT ZWN0aW9uIDYuMSkiLg0KICAgIA0KRlA6IE9rLCBhZGRlZA0KICAgIA0KICAgIFtTZWN0aW9uIDVd DQogICAgDQogICAgUGFnZSA5LCBpdCBjYW4gc2F5ICIuLi4ga2V5aW5nIG1hdGVyaWFsIHRvIHZl cmlmeSB0aGUgcHVibGljYXRpb24NCiAgICBwcm90ZWN0ZWQgZW5kLXRvLWVuZCB3aXRoIHRoZSBw dWJsaXNoZXJzIi4NCg0KRlA6IE9rLCBhZGRlZA0KICAgIA0KICAgIA0KICAgIFtTZWN0aW9uIDZd DQogICAgDQogICAgSXQgd291bGQgYmUgZ29vZCB0byByZWZlciB0byBjb3JlLWNvYXAtcHVic3Vi ICwgYW5kIGl0cyB1c2FnZSBvZiBPYnNlcnZlDQogICAgZm9yIHN1YnNjcmlwdGlvbnMuDQoNCkZQ OiBPaywgYWRkZWQNCiAgICANCiAgICBUaGUgdGV4dCBzYXlzOiAiVGhlIChGKSBtZXNzYWdlIGlz IC4uLiAsIHdoaWNoIGlzIHVucHJvdGVjdGVkLiIgLA0KICAgIGFsdGhvdWdoIFNlY3Rpb24gMyBh ZG1pdHRlZCB0aGUgcG9zc2liaWxpdHkgb2YgY29tbXVuaWNhdGlvbiBzZWN1cmVkDQogICAgYWxz byBiZXR3ZWVuIEJyb2tlciBhbmQgU3Vic2NyaWJlcnMuDQogICAgDQpGUDogdGhhdCdzIHJpZ2h0 LCBJIGFkZGVkIHNvbWUgdGV4dCBhYm91dCB0aGF0Lg0KICAgIA0KICAgIFtTZWN0aW9uIDYuMV0N CiAgICANCiAgICBJbiB0aGUgdW5wcm90ZWN0ZWQgaGVhZGVycyBvZiB0aGUgQ09TRSBvYmplY3Qs IHdoYXQgaXMgdXNlZCBhcyBQYXJ0aWFsIElWPw0KICAgIA0KRlA6IEkgYWRkZWQgc29tZXRoaW5n IGFib3V0IHRoaXMsIGFsdGhvdWdoIHRoaXMgcHJvYmFibHkgcmVxdWlyZXMgbW9yZSB0aGlua2lu Zy4NCiAgICANCiAgICBbU2VjdGlvbiA4LjJdDQogICAgDQogICAgVGhlIHZhbHVlIG9mICdQcm9m aWxlJyBzaG91bGQgYmUgImNvYXBfcHVic3ViJyAsIGNvbnNpc3RlbnRseSB3aXRoIHRoZQ0KICAg IG5hbWUgb2YgdGhlIHByb2ZpbGUgcmVnaXN0ZXJlZCBpbiBTZWN0aW9uIDguMS4NCg0KRlA6IFll cywgdGhpcyBuZWVkZWQgdXBkYXRlLg0KICAgIA0KICAgIC0tIA0KICAgIE1hcmNvIFRpbG9jYQ0K ICAgIFBoLkQuLCBTZW5pb3IgUmVzZWFyY2hlcg0KICAgIA0KICAgIFJJU0UgUmVzZWFyY2ggSW5z dGl0dXRlcyBvZiBTd2VkZW4NCiAgICBEaXZpc2lvbiBJQ1QNCiAgICBJc2Fmam9yZHNnYXRhbiAy MiAvIEtpc3RhZ8OlbmdlbiAxNg0KICAgIFNFLTE2NCA0MCBLaXN0YSAoU3dlZGVuKQ0KICAgIA0K ICAgIFBob25lOiArNDYgKDApNzAgNjAgNDYgNTAxDQogICAgaHR0cHM6Ly93d3cucmkuc2UNCiAg ICANCiAgICANCiAgICANCg0K From nobody Mon Jul 8 08:38:22 2019 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 126F11202A6; Mon, 8 Jul 2019 08:38:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, 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 MRLl9CHcK2BY; Mon, 8 Jul 2019 08:38:03 -0700 (PDT) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00064.outbound.protection.outlook.com [40.107.0.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B648120287; Mon, 8 Jul 2019 08:37:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=cHa8UUraw+jCe3OI4tSouZlct4GpfGQm696lS73/ir5JM48MlAq6TgEVZzsjwv5aW4Yh1t/cTHDmNchVWASSxrio5G4ruLGEagtwZbUBeiPMM+ChjSgqumPnB/MPZJeX9o7CDcBJkH4PvofXhU83z71x1C4b1M7Fmrz0IdDCQ0vyxfofJY54nCBJ0+v76BKgSEtediNVs0hfLwszM9ANhBi8Lelhv3HtG1dv4PvRtlqaZ8gSpP4L0OZz4Q/D5K/kSKQwVPWnI/OIA5bKZ12Cw+6rFI6vYTHWrdAJpDLO2OQrQRxPhOyQU+fJmBTgapnhkfGvBPVwT3acQ138XxzlTQ== 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-SenderADCheck; bh=7xPpbHLA6D14rVkkm8SbPVWASi1JhtW0bzZMuT2UZzI=; b=Q7tLBpHwGNIVQfwYSgoWKtbYb6yUYjxzh6YIcBToyk8ANEDpHT7KEj4LWaYTkBAtizyf6cXzYfT7qYG9YAwIo4VVDdIBEqXBNtukMBRopHVu+YA+GrE7lQLr98yTGMQ1a8lSOYZK5nLm6TA+o5mFxPbtsM65myBHzfzb9yU1CP/eG/5zQ4v8VCRGBC9i8ZSNBUEi8DKCtYZoadsfeiolSjROP4Z0J40irgbFd5jOC7PxkNsFnsEXwdO6nc7fBUerFWz/76zc8aHDtILcXYJqzu07ZbsckxyzkD480xbaLYBpMaeklbcJshA49CsnpjWlMFLO2cFaLGT8dynScJn7Pg== 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=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=7xPpbHLA6D14rVkkm8SbPVWASi1JhtW0bzZMuT2UZzI=; b=mEH7+ycF/kSMognwI0ZN3by/fl6MBpF/lpo/YgsmjmbFfNs/QSkX/2LiFNsXlMtcLQxq5eFkFxfpNwh1z7e3ULn4UI0mPpd2RgzXz5PJyV1ITUQQ9Z7foG/ORmf+C+2uR5glV2TgijpF5OZPLuom7ZocjS0HsLMCRmH0LI7nYas= Received: from HE1PR0701MB2746.eurprd07.prod.outlook.com (10.168.185.17) by HE1PR0701MB2394.eurprd07.prod.outlook.com (10.168.128.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2073.10; Mon, 8 Jul 2019 15:37:50 +0000 Received: from HE1PR0701MB2746.eurprd07.prod.outlook.com ([fe80::d958:9685:d091:3b9a]) by HE1PR0701MB2746.eurprd07.prod.outlook.com ([fe80::d958:9685:d091:3b9a%3]) with mapi id 15.20.2073.008; Mon, 8 Jul 2019 15:37:49 +0000 From: Francesca Palombini To: Ace Wg , "ace-chairs@ietf.org" Thread-Topic: New Version Notification for draft-palombini-ace-coap-pubsub-profile-05.txt Thread-Index: AQHVNaJzWaSkjedINEGBFjadqLT2bKbA/HOA Date: Mon, 8 Jul 2019 15:37:49 +0000 Message-ID: <5AB5A7A3-2386-466E-BE42-E20658A093E8@ericsson.com> References: <156259998182.1043.5083008677416180390.idtracker@ietfa.amsl.com> In-Reply-To: <156259998182.1043.5083008677416180390.idtracker@ietfa.amsl.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=francesca.palombini@ericsson.com; x-originating-ip: [158.174.219.143] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 414ad3a8-7ea2-42dd-bbbf-08d703ba3be0 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:HE1PR0701MB2394; x-ms-traffictypediagnostic: HE1PR0701MB2394: x-ms-exchange-purlcount: 5 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 00922518D8 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(376002)(136003)(346002)(396003)(39860400002)(366004)(53754006)(199004)(189003)(36756003)(71190400001)(486006)(76176011)(71200400001)(478600001)(44832011)(33656002)(14444005)(256004)(86362001)(53936002)(6512007)(2473003)(6306002)(966005)(14454004)(25786009)(11346002)(6506007)(450100002)(2616005)(476003)(66574012)(446003)(99286004)(102836004)(15650500001)(6116002)(3846002)(73956011)(76116006)(66476007)(66946007)(66446008)(64756008)(66556008)(26005)(229853002)(186003)(68736007)(8936002)(81156014)(2906002)(8676002)(81166006)(316002)(6436002)(7736002)(305945005)(110136005)(5660300002)(2501003)(66066001)(6486002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2394; H:HE1PR0701MB2746.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: Z/METbOTaYRZ7i5bxR0oBtxYFps8xccynM/3Xnjn53AyhT8Wkbx7fK7JtGL8VidbgrWrX9RVSdVP2+HRiidRYk4Kls+pEkCuB8MtJPG0C2EwUWhRadn25c78fmmt8k5PCljgq9Lbm5y1cXw0xsnY9KtGlzOb9kZbhK4YLb0zuFuduwBgg8kkgjjpkvJOXW5chyB/U9fepBn3rpIO8lZtHHSnklW/kOJCHV+tJUA+hL0wlaRG74b6zmoJdeatH4LLjIe4mFh8Hd2ZQitsUgPxJvamnS0i47H5zaqKIFJF6zJGZMb94ulV2TSLn6AXEuKmpO6yu8M/5Gq4NWJw34LTszCDQaDj1yVU2weJFkFY1XZ3K5SuzgQVI924KAT5TcS6s35TCyRFb5yhhO9oIXUnW2DsaT4fPTVKDIITMg2Q+nM= Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 414ad3a8-7ea2-42dd-bbbf-08d703ba3be0 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jul 2019 15:37:49.7729 (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: francesca.palombini@ericsson.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2394 Archived-At: Subject: [Ace] FW: New Version Notification for draft-palombini-ace-coap-pubsub-profile-05.txt 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: Mon, 08 Jul 2019 15:38:14 -0000 SGkgYWxsLA0KDQpJIGp1c3Qgc3VibWl0dGVkIGEgbmV3IHZlcnNpb24gb2YgdGhlIEFDRSBwcm9m aWxlIG9mIENvQVAgcHVic3ViLg0KDQpUaGlzIHZlcnNpb24gbWFrZXMgdGhlIHVwZGF0ZXMgbmVj ZXNzYXJ5IHRvIGNvbXBseSB3aXRoIGFjZS1rZXktZ3JvdXBjb21tLCBhcyB3ZWxsIGFzIGFuc3dl ciBNYXJjbydzIHJldmlldyAodGhhbmsgeW91IE1hcmNvISkgYW5kIHNvbWUgb3RoZXIgbWlub3Ig Y2hhbmdlcy4gQW55IGZlZWRiYWNrIGlzIHdlbGNvbWUhDQoNCkNoYWlyczogSSdkIGxpa2UgdG8g YXNrIGZvciA1LzEwIG1pbnV0ZXMgcHJlc2VudGF0aW9uIHRpbWUgZHVyaW5nIElFVEYxMDUuIEkg d291bGQgYmUgcHJlc2VudGluZyBpbiBwZXJzb24sIG5vdCByZW1vdGUuIFBvc3NpYmx5LCBhZnRl ciBhY2Uta2V5LWdyb3VwY29tbSwgYXMgdGhpcyBkcmFmdCBkZXBlbmRzIG9uIHRoYXQgb25lLg0K DQpUaGFua3MsDQpGcmFuY2VzY2ENCg0K77u/T24gMDgvMDcvMjAxOSwgMTc6MzMsICJpbnRlcm5l dC1kcmFmdHNAaWV0Zi5vcmciIDxpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+IHdyb3RlOg0KDQog ICAgDQogICAgQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LXBhbG9tYmluaS1hY2UtY29hcC1w dWJzdWItcHJvZmlsZS0wNS50eHQNCiAgICBoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVk IGJ5IEZyYW5jZXNjYSBQYWxvbWJpbmkgYW5kIHBvc3RlZCB0byB0aGUNCiAgICBJRVRGIHJlcG9z aXRvcnkuDQogICAgDQogICAgTmFtZToJCWRyYWZ0LXBhbG9tYmluaS1hY2UtY29hcC1wdWJzdWIt cHJvZmlsZQ0KICAgIFJldmlzaW9uOgkwNQ0KICAgIFRpdGxlOgkJQ29BUCBQdWItU3ViIFByb2Zp bGUgZm9yIEF1dGhlbnRpY2F0aW9uIGFuZCBBdXRob3JpemF0aW9uIGZvciBDb25zdHJhaW5lZCBF bnZpcm9ubWVudHMgKEFDRSkNCiAgICBEb2N1bWVudCBkYXRlOgkyMDE5LTA3LTA4DQogICAgR3Jv dXA6CQlJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCiAgICBQYWdlczoJCTE5DQogICAgVVJMOiAgICAg ICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1wYWxvbWJp bmktYWNlLWNvYXAtcHVic3ViLXByb2ZpbGUtMDUudHh0DQogICAgU3RhdHVzOiAgICAgICAgIGh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXBhbG9tYmluaS1hY2UtY29hcC1w dWJzdWItcHJvZmlsZS8NCiAgICBIdG1saXplZDogICAgICAgaHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LXBhbG9tYmluaS1hY2UtY29hcC1wdWJzdWItcHJvZmlsZS0wNQ0KICAgIEh0 bWxpemVkOiAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0 LXBhbG9tYmluaS1hY2UtY29hcC1wdWJzdWItcHJvZmlsZQ0KICAgIERpZmY6ICAgICAgICAgICBo dHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtcGFsb21iaW5pLWFjZS1jb2Fw LXB1YnN1Yi1wcm9maWxlLTA1DQogICAgDQogICAgQWJzdHJhY3Q6DQogICAgICAgVGhpcyBzcGVj aWZpY2F0aW9uIGRlZmluZXMgYSBwcm9maWxlIGZvciBhdXRoZW50aWNhdGlvbiBhbmQNCiAgICAg ICBhdXRob3JpemF0aW9uIGZvciBwdWJsaXNoZXJzIGFuZCBzdWJzY3JpYmVycyBpbiBhIHB1Yi1z dWIgc2V0dGluZw0KICAgICAgIHNjZW5hcmlvIGluIGEgY29uc3RyYWluZWQgZW52aXJvbm1lbnQs IHVzaW5nIHRoZSBBQ0UgZnJhbWV3b3JrLiAgVGhpcw0KICAgICAgIHByb2ZpbGUgcmVsaWVzIG9u IHRyYW5zcG9ydCBsYXllciBvciBhcHBsaWNhdGlvbiBsYXllciBzZWN1cml0eSB0bw0KICAgICAg IGF1dGhvcml6ZSB0aGUgcHVibGlzaGVyIHRvIHRoZSBicm9rZXIuICBNb3Jlb3ZlciwgaXQgcmVs aWVzIG9uDQogICAgICAgYXBwbGljYXRpb24gbGF5ZXIgc2VjdXJpdHkgZm9yIHB1Ymxpc2hlci1i cm9rZXIgYW5kIHN1YnNjcmliZXItYnJva2VyDQogICAgICAgY29tbXVuaWNhdGlvbi4NCiAgICAN CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQogICAgDQogICAgDQogICAgUGxlYXNlIG5v dGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Yg c3VibWlzc2lvbg0KICAgIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBh dmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQogICAgDQogICAgVGhlIElFVEYgU2VjcmV0YXJp YXQNCiAgICANCiAgICANCg0K From nobody Mon Jul 8 09:06:21 2019 Return-Path: X-Original-To: ace@ietf.org Delivered-To: ace@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 961F41202C7; Mon, 8 Jul 2019 09:06:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: internet-drafts@ietf.org To: Cc: ace@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.98.3 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ace@ietf.org Message-ID: <156260197251.803.8979695371238590535@ietfa.amsl.com> Date: Mon, 08 Jul 2019 09:06:12 -0700 Archived-At: Subject: [Ace] I-D Action: draft-ietf-ace-oscore-profile-08.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2019 16:06:20 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Authentication and Authorization for Constrained Environments WG of the IETF. Title : OSCORE profile of the Authentication and Authorization for Constrained Environments Framework Authors : Francesca Palombini Ludwig Seitz Göran Selander Martin Gunnarsson Filename : draft-ietf-ace-oscore-profile-08.txt Pages : 27 Date : 2019-07-08 Abstract: This memo specifies a profile for the Authentication and Authorization for Constrained Environments (ACE) framework. It utilizes Object Security for Constrained RESTful Environments (OSCORE) to provide communication security, server authentication, and proof-of-possession for a key owned by the client and bound to an OAuth 2.0 access token. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ace-oscore-profile/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ace-oscore-profile-08 https://datatracker.ietf.org/doc/html/draft-ietf-ace-oscore-profile-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-oscore-profile-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 8 09:10:39 2019 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 8B066120298; Mon, 8 Jul 2019 09:10:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, 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 AMiZJSKgarXs; Mon, 8 Jul 2019 09:10:24 -0700 (PDT) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60054.outbound.protection.outlook.com [40.107.6.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D826A1202FC; Mon, 8 Jul 2019 09:10:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=GRsFh2GE2m9z/ZjDMHdz9q+AUC/cV7xZkcpQm/gH2MZTdServ2rhAn+RAgJxAuq1lZwZ6hfP+dbE7FMalpssY4oo3ds5QOlny43WxspoADBlzCTUmD5MRjMbcxnVSmk+hR4RHMvDjqDH4Rk38Voi6nTzd/xG32OfWIivNHXwHSEjyxpTACtZbIBCfWIv54KTZX2gXROCb3bYcxHMAFbZTePrNMI50Y85Qy/suoqdmwzfnCjioIDP7jo/dnjm694f9Artww9mcrPxRrvlMd1EM4zz3uHLZgQ+D1TqCOyrmD+1OQJqzkloxYIt6y5FLbPkB0kRCC/Hn1YzCzFsAO6WSA== 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-SenderADCheck; bh=GrqWuBwbWrGIJuoUq0wtdRMRjqgLuKQO/zR46xj4T0M=; b=kihl+gQ7h+TuG25czp27IpzBmpagibWZ8vpnPQ0P5RSo5RMSpbRWo+ueIPpaP9ydUXPRo4JKGJ/XY0oNuZJ0vYygFYSWnFNKps+Z5ylA2vDHPa9TInO+4PM46OcArordUiRLyAc+ludUvi+sQlGaVnxjxjrAR6oEPC40kOR+7i/b6KyAyGHuGARvzdCo5iwR5btLhD8Kr0WgpjSDI7EqKmz1Ty+uTw2mExAtjkIyaB80udRTbdERS135Y9XRXJLfNrIRA2IKgjp9mQQjAk7CuhQtFgMKxDA27JKRQ2ElT9jHmPqn6+ag+GfjGjwiqvkKhX4SULdXP/99DUInlMn1aw== 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=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=GrqWuBwbWrGIJuoUq0wtdRMRjqgLuKQO/zR46xj4T0M=; b=lmX0lx+iVaiAsR71po0ZQdazM0JXispfi7aMrNLxNoZ1wjMwCQeUm5XDqfGN7WOIkuy1dRe++6uM11za1WN3eN31QZKcQOcOj3N70nhisxwCxoPQxT+ZPfumqm1zy9dm4/qL+wdT4LTFDer3WQBePc8oppKUJ+PiuT2g5VynCNk= Received: from HE1PR0701MB2746.eurprd07.prod.outlook.com (10.168.185.17) by HE1PR0701MB2332.eurprd07.prod.outlook.com (10.168.124.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2073.3; Mon, 8 Jul 2019 16:10:15 +0000 Received: from HE1PR0701MB2746.eurprd07.prod.outlook.com ([fe80::d958:9685:d091:3b9a]) by HE1PR0701MB2746.eurprd07.prod.outlook.com ([fe80::d958:9685:d091:3b9a%3]) with mapi id 15.20.2073.008; Mon, 8 Jul 2019 16:10:15 +0000 From: Francesca Palombini To: Ace Wg CC: "ace-chairs@ietf.org" Thread-Topic: New Version Notification for draft-ietf-ace-oscore-profile-08.txt Thread-Index: AQHVNacUjJP94yDVe0q4JVG+ohCjZabBBXqA Date: Mon, 8 Jul 2019 16:10:15 +0000 Message-ID: References: <156260197282.803.17466347474423325764.idtracker@ietfa.amsl.com> In-Reply-To: <156260197282.803.17466347474423325764.idtracker@ietfa.amsl.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=francesca.palombini@ericsson.com; x-originating-ip: [158.174.219.143] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 30f5a52e-351e-48bb-078f-08d703bec3ca x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:HE1PR0701MB2332; x-ms-traffictypediagnostic: HE1PR0701MB2332: x-ms-exchange-purlcount: 6 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 00922518D8 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(376002)(366004)(346002)(396003)(39860400002)(136003)(189003)(199004)(53754006)(99286004)(14444005)(256004)(68736007)(478600001)(14454004)(7736002)(305945005)(25786009)(8936002)(4326008)(102836004)(6506007)(446003)(11346002)(86362001)(186003)(26005)(76176011)(966005)(66066001)(450100002)(486006)(2616005)(476003)(66574012)(71200400001)(6306002)(71190400001)(6512007)(33656002)(229853002)(8676002)(2473003)(316002)(6436002)(6486002)(53936002)(5660300002)(6116002)(81166006)(81156014)(76116006)(44832011)(73956011)(36756003)(3846002)(15650500001)(2906002)(66946007)(66476007)(66556008)(64756008)(66446008)(6916009); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2332; H:HE1PR0701MB2746.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: TGBmDs1rFbhGEdhgLFvWe0FG3XjVJGqNB5lC0o2Bb3sM9pukJbTn6yj1NtTYc6i10MLx9FxvPBvZ7SQgDcLmIKAgnIfN/sqJGde5u5b1hDaNfKOQ3G71a8pUdLCrsbKhKxgYcvIlkG1QmPsVKhFCgFmcvgkV4wDix5Wm3bQS02CyNzlBdhoeAAWRk/3J2I6QwPEipqkYzz6WdbqorKiGzG06xUNIVvP3K7Pd10YlgRT68g/ImnUpIw7g1f65jdY1GOCdngvYCCMRua/DXp4ytIFl+nTP3Y5HrR/Ei3w/wdNXOmwrB1XXZiKSViW790Cul1UMvM1PiAafUSaPnbfBtt3NjsHuyqxsQaFbDGJor7zOSRn0kx0bz6aGgvek5wlSPLVI9zcm7og63kKTJEv1jN7XL7hesS0LpdHso7XQNmA= Content-Type: text/plain; charset="utf-8" Content-ID: <880C13EA4B22A24EAF43F3BAB3515A3E@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 30f5a52e-351e-48bb-078f-08d703bec3ca X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jul 2019 16:10:15.7232 (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: francesca.palombini@ericsson.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2332 Archived-At: Subject: [Ace] FW: New Version Notification for draft-ietf-ace-oscore-profile-08.txt 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: Mon, 08 Jul 2019 16:10:37 -0000 SGkgYWxsLA0KDQpJIGp1c3Qgc3VibWl0dGVkIHYtMDggb2YgdGhlIE9TQ09SRSBwcm9maWxlLiBU aGlzIHZlcnNpb24gYW5zd2VycyB0aGUgbGF0ZXN0IGNvbW1lbnRzIGZyb20gSmltLCBwbHVzIGEg Y291cGxlIG1vcmUgaXNzdWVzIHRoYXQgd2VyZSBsZWZ0IG9uIHRoZSBnaXRodWIgaXNzdWUgdHJh Y2tlciAoaXNzdWUgIzEzIGFuZCBmb2xsb3dpbmcsIGF0IGh0dHBzOi8vZ2l0aHViLmNvbS9hY2Ut d2cvYWNlLW9zY29yZS1wcm9maWxlL2lzc3Vlcz91dGY4PSVFMiU5QyU5MyZxPWlzJTNBaXNzdWUg KQ0KDQpDaGFpcnM6IEkgd291bGQgbGlrZSB0byByZXF1ZXN0IDEwIG1pbnV0ZXMgYXQgSUVURjEw NS4gSSB3b3VsZCBiZSBwcmVzZW50aW5nLCBpbiBwZXJzb24uIA0KDQpUaGFua3MsDQpGcmFuY2Vz Y2ENCg0K77u/T24gMDgvMDcvMjAxOSwgMTg6MDYsICJpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmci IDxpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+IHdyb3RlOg0KDQogICAgDQogICAgQSBuZXcgdmVy c2lvbiBvZiBJLUQsIGRyYWZ0LWlldGYtYWNlLW9zY29yZS1wcm9maWxlLTA4LnR4dA0KICAgIGhh cyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgRnJhbmNlc2NhIFBhbG9tYmluaSBhbmQg cG9zdGVkIHRvIHRoZQ0KICAgIElFVEYgcmVwb3NpdG9yeS4NCiAgICANCiAgICBOYW1lOgkJZHJh ZnQtaWV0Zi1hY2Utb3Njb3JlLXByb2ZpbGUNCiAgICBSZXZpc2lvbjoJMDgNCiAgICBUaXRsZToJ CU9TQ09SRSBwcm9maWxlIG9mIHRoZSBBdXRoZW50aWNhdGlvbiBhbmQgQXV0aG9yaXphdGlvbiBm b3IgQ29uc3RyYWluZWQgRW52aXJvbm1lbnRzIEZyYW1ld29yaw0KICAgIERvY3VtZW50IGRhdGU6 CTIwMTktMDctMDgNCiAgICBHcm91cDoJCWFjZQ0KICAgIFBhZ2VzOgkJMjcNCiAgICBVUkw6ICAg ICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYt YWNlLW9zY29yZS1wcm9maWxlLTA4LnR4dA0KICAgIFN0YXR1czogICAgICAgICBodHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWFjZS1vc2NvcmUtcHJvZmlsZS8NCiAg ICBIdG1saXplZDogICAgICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYt YWNlLW9zY29yZS1wcm9maWxlLTA4DQogICAgSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaWV0Zi1hY2Utb3Njb3JlLXByb2ZpbGUNCiAg ICBEaWZmOiAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0 LWlldGYtYWNlLW9zY29yZS1wcm9maWxlLTA4DQogICAgDQogICAgQWJzdHJhY3Q6DQogICAgICAg VGhpcyBtZW1vIHNwZWNpZmllcyBhIHByb2ZpbGUgZm9yIHRoZSBBdXRoZW50aWNhdGlvbiBhbmQN CiAgICAgICBBdXRob3JpemF0aW9uIGZvciBDb25zdHJhaW5lZCBFbnZpcm9ubWVudHMgKEFDRSkg ZnJhbWV3b3JrLiAgSXQNCiAgICAgICB1dGlsaXplcyBPYmplY3QgU2VjdXJpdHkgZm9yIENvbnN0 cmFpbmVkIFJFU1RmdWwgRW52aXJvbm1lbnRzDQogICAgICAgKE9TQ09SRSkgdG8gcHJvdmlkZSBj b21tdW5pY2F0aW9uIHNlY3VyaXR5LCBzZXJ2ZXIgYXV0aGVudGljYXRpb24sDQogICAgICAgYW5k IHByb29mLW9mLXBvc3Nlc3Npb24gZm9yIGEga2V5IG93bmVkIGJ5IHRoZSBjbGllbnQgYW5kIGJv dW5kIHRvIGFuDQogICAgICAgT0F1dGggMi4wIGFjY2VzcyB0b2tlbi4NCiAgICANCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgDQogICAgDQogICAgDQogICAgUGxlYXNlIG5vdGUgdGhhdCBp dCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lv bg0KICAgIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUg YXQgdG9vbHMuaWV0Zi5vcmcuDQogICAgDQogICAgVGhlIElFVEYgU2VjcmV0YXJpYXQNCiAgICAN CiAgICANCg0K From nobody Tue Jul 9 01:37:06 2019 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 80434120397 for ; Tue, 9 Jul 2019 01:37:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=risecloud.onmicrosoft.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 fmIzcK09GWnk for ; Tue, 9 Jul 2019 01:37:01 -0700 (PDT) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-ve1eur03on0609.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe09::609]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 993C7120385 for ; Tue, 9 Jul 2019 01:37:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=RISEcloud.onmicrosoft.com; s=selector2-RISEcloud-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ePYD6a0WvUemIgxitmefxMiUiUcXSrV0Rw0LLKWigTE=; b=P5Bx90+NMfvMpyTg/1asOedZkWh7cufE8e1uXjiJS7MsVn6SvPazLPlN3QMC3J18zkTP3eYP6o1Oj/isIg8O7ndyv8alUA3heI0p5MYN4cqIJnX8lxLiANwh8WS5/HlUDuJM2eZ1Oe51pEdGUYzgxj5Gnutrxz8C/Rd6cJ35uCk= Received: from DB6P18901CA0009.EURP189.PROD.OUTLOOK.COM (2603:10a6:4:16::19) by DB6P189MB0344.EURP189.PROD.OUTLOOK.COM (2603:10a6:6:3a::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2052.19; Tue, 9 Jul 2019 08:36:57 +0000 Received: from HE1EUR02FT058.eop-EUR02.prod.protection.outlook.com (2a01:111:f400:7e05::204) by DB6P18901CA0009.outlook.office365.com (2603:10a6:4:16::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.2052.18 via Frontend Transport; Tue, 9 Jul 2019 08:36:57 +0000 Authentication-Results: spf=pass (sender IP is 194.218.146.197) smtp.mailfrom=ri.se; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=ri.se; Received-SPF: Pass (protection.outlook.com: domain of ri.se designates 194.218.146.197 as permitted sender) receiver=protection.outlook.com; client-ip=194.218.146.197; helo=mail.ri.se; Received: from mail.ri.se (194.218.146.197) by HE1EUR02FT058.mail.protection.outlook.com (10.152.11.31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.20.2052.19 via Frontend Transport; Tue, 9 Jul 2019 08:36:56 +0000 Received: from [10.8.3.4] (10.116.0.226) by sp-mail-2.sp.se (10.100.0.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Tue, 9 Jul 2019 10:36:56 +0200 References: <156240621606.15187.3440015439928595257.idtracker@ietfa.amsl.com> To: From: Marco Tiloca Openpgp: preference=signencrypt Autocrypt: addr=marco.tiloca@ri.se; prefer-encrypt=mutual; keydata= mQENBFSNeRUBCAC44iazWzj/PE3TiAlBsaWna0JbdIAJFHB8PLrqthI0ZG7GnCLNR8ZhDz6Z aRDPC4FR3UcMhPgZpJIqa6Zi8yWYCqF7A7QhT7E1WdQR1G0+6xUEd0ZD+QBdf29pQadrVZAt 0G4CkUnq5H+Sm05aw2Cpv3JfsATVaemWmujnMTvZ3dFudCGNdsY6kPSVzMRyedX7ArLXyF+0 Kh1T4WUW6NHfEWltnzkcqRhn2NcZtADsxWrMBgZXkLE/dP67SnyFjWYpz7aNpxxA+mb5WBT+ NrSetJlljT0QOXrXMGh98GLfNnLAl6gJryE6MZazN5oxkJgkAep8SevFXzglj7CAsh4PABEB AAG0Nk1hcmNvIFRpbG9jYSAobWFyY28udGlsb2NhQHJpLnNlKSA8bWFyY28udGlsb2NhQHJp LnNlPokBNwQTAQgAIQUCWkAnkAIbAwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRDuJmS0 DljaQwEvCACJKPJIPGH0oGnLJY4G1I2DgNiyVKt1H4kkc/eT8Bz9OSbAxgZo3Jky382e4Dba ayWrQRFen0aLSFuzbU4BX4O/YRSaIqUO3KwUNO1iTC65OHz0XirGohPUOsc0SEMtpm+4zfYG 7G8p35MK0h9gpwgGMG0j0mZX4RDjuywC88i1VxCwMWGaZRlUrPXkC3nqDDRcPtuEGpncWhAV Qt2ZqeyITv9KCUmDntmXLPe6vEXtOfI9Z3HeqeI8OkGwXpotVobgLa/mVmFj6EALDzj7HC2u tfgxECBJddmcDInrvGgTkZtXEVbyLQuiK20lJmYnmPWN8DXaVVaQ4XP/lXUrzoEzuQENBFSN eRUBCACWmp+k6LkY4/ey7eA7umYVc22iyVqAEXmywDYzEjewYwRcjTrH/Nx1EqwjIDuW+BBE oMLRZOHCgmjo6HRmWIutcYVCt9ieokultkor9BBoQVPiI+Tp51Op02ifkGcrEQNZi7q3fmOt hFZwZ6NJnUbA2bycaKZ8oClvDCQj6AjEydBPnS73UaEoDsqsGVjZwChfOMg5OyFm90QjpIw8 m0uDVcCzKKfxq3T/z7tyRgucIUe84EzBuuJBESEjK/hF0nR2LDh1ShD29FWrFZSNVVCVu1UY ZLAayf8oKKHHpM+whfjEYO4XsDpV4zQ15A+D15HRiHR6Adf4PDtPM1DCwggjABEBAAGJAR8E GAECAAkFAlSNeRUCGwwACgkQ7iZktA5Y2kPGEwf/WNjTy3z74vLmHycVsFXXoQ8W1+858mRy Ad0a8JYzY3xB7CVtqI3Hy894Qcw4H6G799A1OL9B1EeA8Yj3aOz0NbUyf5GW+iotr3h8+KIC OYZ34/BQaOLzdvDNmRoGHn+NeTzhF7eSeiPKi2jex+NVodhjOVGXw8EhYGkeZLvynHEboiLM 4TbyPbVR9HsdVqKGVTDxKSE3namo3kvtY6syRFIiUz5WzJfYAuqbt6m3TxDEb8sA9pzaLuhm fnJRc12H5NVZEZmE/EkJFTlkP4wnZyOSf/r2/Vd0iHauBwv57cpY6HFFMe7rvK4s7ME5zctO Ely5C6NCu1ZaNtdUuqDSPA== X-Forwarded-Message-Id: <156240621606.15187.3440015439928595257.idtracker@ietfa.amsl.com> Message-ID: Date: Tue, 9 Jul 2019 10:36:50 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: <156240621606.15187.3440015439928595257.idtracker@ietfa.amsl.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="4AY2jqvplSeD5O9I4XXMpK7Uxw20dkXtN" X-Originating-IP: [10.116.0.226] X-ClientProxiedBy: sp-mail-2.sp.se (10.100.0.162) To sp-mail-2.sp.se (10.100.0.162) X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:194.218.146.197; IPV:NLI; CTRY:SE; EFV:NLI; SFV:NSPM; SFS:(10009020)(4636009)(396003)(376002)(136003)(39860400002)(346002)(2980300002)(199004)(189003)(21480400003)(5660300002)(6916009)(235185007)(69596002)(336012)(14444005)(5024004)(478600001)(64126003)(65956001)(68736007)(2351001)(22756006)(65806001)(15650500001)(40036005)(65826007)(386003)(186003)(77096007)(31686004)(2906002)(70206006)(33964004)(76176011)(70586007)(36756003)(606006)(71190400001)(86362001)(6666004)(356004)(476003)(126002)(66574012)(446003)(11346002)(568964002)(2616005)(2473003)(31696002)(54896002)(6306002)(236005)(3846002)(6116002)(486006)(44832011)(16526019)(316002)(966005)(8936002)(58126008)(16576012)(229853002)(53936002)(16586007)(81156014)(81166006)(8676002)(106002)(22746008)(7736002)(26005)(74482002); DIR:OUT; SFP:1101; SCL:1; SRVR:DB6P189MB0344; H:mail.ri.se; FPR:; SPF:Pass; LANG:en; PTR:InfoDomainNonexistent; A:1; MX:1; X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: af3cb29b-9115-410a-b1d8-08d704489a37 X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(4709080)(1401327)(2017052603328)(7193020); SRVR:DB6P189MB0344; X-MS-TrafficTypeDiagnostic: DB6P189MB0344: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:8273; X-Forefront-PRVS: 0093C80C01 X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Message-Info: GeGRP70GWu7hrAKMsUlVApW5DdKUY35FRo3p3clPgrr8ekLmaNp4ZzyMe/268K0VjYJ5kTzjVxyH76pXLjclkEpEYf1HoDAm7KNAsZW4BaKmCt0ZUUasaTQd9pG9glIjHKnrrMWGtK1YbCR0rJhdqsDG5fVxyAIghsGyMyPlVjgL8FmzbRB2GMpLpWpk3an7qJxmDtG3RZRO7L62RjkSL3zQxbHca7xOvzeuo4dtczf4yMGY4eIph0SpiRFXUjiClNamCo56h9xu1T9c9u0zZjjXf8DUfXcNayCCWQoUqg5lrcUbmvNamTT42iHAaDNufuO6S1Snn8estlfxkPF12GY4yhtIvS9IVI9zfQXUfgfkBn4R/7okNniKbJAf0czwu0LDPZn0LF1g1NJ8qF5zis2TsI5v+7OWANoYEKhccL4= X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Jul 2019 08:36:56.7011 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: af3cb29b-9115-410a-b1d8-08d704489a37 X-MS-Exchange-CrossTenant-Id: 5a9809cf-0bcb-413a-838a-09ecc40cc9e8 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=5a9809cf-0bcb-413a-838a-09ecc40cc9e8; Ip=[194.218.146.197]; Helo=[mail.ri.se] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6P189MB0344 Archived-At: Subject: [Ace] Fwd: New Version Notification for draft-tiloca-ace-group-oscore-profile-00.txt 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: Tue, 09 Jul 2019 08:37:05 -0000 --4AY2jqvplSeD5O9I4XXMpK7Uxw20dkXtN Content-Type: multipart/mixed; boundary="owHqLCaSFfSelWpnwRN2gfWlKXwmzAton"; protected-headers="v1" From: Marco Tiloca To: ace@ietf.org Message-ID: Subject: Fwd: New Version Notification for draft-tiloca-ace-group-oscore-profile-00.txt References: <156240621606.15187.3440015439928595257.idtracker@ietfa.amsl.com> In-Reply-To: <156240621606.15187.3440015439928595257.idtracker@ietfa.amsl.com> --owHqLCaSFfSelWpnwRN2gfWlKXwmzAton Content-Type: multipart/alternative; boundary="------------A3C6064ED12345A2C7A2A4E2" Content-Language: en-US This is a multi-part message in MIME format. --------------A3C6064ED12345A2C7A2A4E2 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello ACE, We have recently submitted a new draft "Group OSCORE Profile of the Authentication and Authorization for Constrained Environments Framework" https://tools.ietf.org/html/draft-tiloca-ace-group-oscore-profile The document describes a profile of ACE where client and server can communicate with OSCORE and Group OSCORE. This supports fine-grained access control in group communication environments, where different group members have different access rights to resources of other group members. The pairwise OSCORE security context between the client and server is established in a way similar to the OSCORE profile of ACE, and is securely bound to the Group OSCORE security context previously obtained when joining the OSCORE group. Comments are very welcome! Best, /Marco -------- Forwarded Message -------- Subject: New Version Notification for draft-tiloca-ace-group-oscore-profile-00.txt Date: Sat, 6 Jul 2019 02:43:36 -0700 From: internet-drafts@ietf.org To: Ludwig Seitz , Marco Tiloca , Rikard Hoeglund , Francesca Palombini A new version of I-D, draft-tiloca-ace-group-oscore-profile-00.txt has been successfully submitted by Marco Tiloca and posted to the IETF repository. Name: draft-tiloca-ace-group-oscore-profile Revision: 00 Title: Group OSCORE Profile of the Authentication and Authorization for Constrained Environments Framework Document date: 2019-07-06 Group: Individual Submission Pages: 29 URL: https://www.ietf.org/internet-drafts/draft-tiloca-ace-group-oscore-profil= e-00.txt Status: https://datatracker.ietf.org/doc/draft-tiloca-ace-group-oscore-profile/ Htmlized: https://tools.ietf.org/html/draft-tiloca-ace-group-oscore-profile-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-tiloca-ace-group-oscore-profi= le Abstract: This document specifies a profile for the Authentication and Authorization for Constrained Environments (ACE) framework. The profile uses Object Security for Constrained RESTful Environments (OSCORE) and/or Group OSCORE to provide communication security between a Client and (a group of) Resource Server(s). Furthermore, the profile uses (Group) OSCORE to provide server authentication, and OSCORE to achieve proof-of-possession for a key owned by the Client and bound to an OAuth 2.0 Access Token. Also, the profile provides proof-of-group-membership for the Client, by securely binding the pre-established Group OSCORE Security Context to the pairwise OSCORE Security Context newly established with the Resource Server. Please note that it may take a couple of minutes from the time of submiss= ion until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --------------A3C6064ED12345A2C7A2A4E2 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello ACE,

We have recently submitted a new draft "Group OSCORE Profile of the Authentication and Authorization for Constrained Environments Framework"

https://tools.ietf.org/html/draf= t-tiloca-ace-group-oscore-profile

The document describes a profile of ACE where client and server can communicate with OSCORE and Group OSCORE. This supports fine-grained access control in group communication environments, where different group members have different access rights to resources of other group members.

The pairwise OSCORE security context between the client and server is established in a way similar to the OSCORE profile of ACE, and is securely bound to the Group OSCORE security context previously obtained when joining the OSCORE group.

Comments are very welcome!

Best,
/Marco


-------- Forwarded Message --------
Sub= ject: New Version Notification for draft-tiloca-ace-group-oscore-profile-00.txt
Dat= e: Sat, 6 Jul 2019 02:43:36 -0700
Fro= m: internet-drafts@ietf.org
To:= Ludwig Seitz <ludwig.seitz@ri.se>, Marco Tiloca <marco.tiloca@ri.se>, Rikard Hoeglund <rikard.hoglund@ri.se>, Francesca Palombini <francesca.palombini@ericsson.com>



A new version of I-D, draft-tiloca-ace-group-oscore-profile-00.txt<= br> has been successfully submitted by Marco Tiloca and posted to the IETF repository.

Name: draft-tiloca-ace-group-oscore-profile
Revision: 00
Title: Group OSCORE Profile of the Authentication and Authorization for Constrained Environments Framework
Document date: 2019-07-06
Group: Individual Submission
Pages: 29
URL: https://www.ietf.org= /internet-drafts/draft-tiloca-ace-group-oscore-profile-00.txt
Status: https://datatracker.ie= tf.org/doc/draft-tiloca-ace-group-oscore-profile/
Htmlized: https://tools.ietf.org/html= /draft-tiloca-ace-group-oscore-profile-00
Htmlized: https://datatracker.ietf.o= rg/doc/html/draft-tiloca-ace-group-oscore-profile


Abstract:
This document specifies a profile for the Authentication and
Authorization for Constrained Environments (ACE) framework. The
= profile uses Object Security for Constrained RESTful Environments (OSCORE) and/or Group OSCORE to provide communication security
between a Client and (a group of) Resource Server(s). Furthermore,<= br> the profile uses (Group) OSCORE to provide server authentication, and
OSCORE to achieve proof-of-possession for a key owned by the Client
and bound to an OAuth 2.0 Access Token. Also, the profile provides<= br> proof-of-group-membership for the Client, by securely binding the pre-established Group OSCORE Security Context to the pairwise OSCORE
Security Context newly established with the Resource Server.



Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

--------------A3C6064ED12345A2C7A2A4E2-- --owHqLCaSFfSelWpnwRN2gfWlKXwmzAton-- --4AY2jqvplSeD5O9I4XXMpK7Uxw20dkXtN Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEOEo4cV326Z7GypVg7iZktA5Y2kMFAl0kUiIACgkQ7iZktA5Y 2kNgnQf/Rfui72P+Yr8+p4CbSHGuX/8Uu/Nst9GhpletGqQDb2vViCFSyE38tryi L7SzdRTd2i8DLKhouxn49cR4V3RGIWxak4j2JJMUmpii4gDpvyGbBpZBOV4DpNvg uwfsvNnzqd4o5zL12zPYdkOxyxgrRbhQpfKdy1dD2YOpFLwqXDmmjDJieDUgSo+z eMypIuIvrFpk/EJh7xIiF6O5uNlW3PHsPb0SWEKsahDd8AgBgjfYteUgyH+UyqJr mVjarJTXU2qG9SFqTW/jxvlnUbFsMi2GD9nZOT/w3Lf780RtSTORLMotcwc97k5P TxTejyim7Yh+Ut92I2N9EOdNFzNQvg== =Zwul -----END PGP SIGNATURE----- --4AY2jqvplSeD5O9I4XXMpK7Uxw20dkXtN-- From nobody Tue Jul 9 10:20:58 2019 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 0DD4C1201F1 for ; Tue, 9 Jul 2019 10:20:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.572 X-Spam-Level: * X-Spam-Status: No, score=1.572 tagged_above=-999 required=5 tests=[AC_BR_BONANZA=0.001, BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.247, FREEMAIL_FROM=0.001, FUZZY_CREDIT=1.678, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no 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 SlSGBSK57dcc for ; Tue, 9 Jul 2019 10:20:45 -0700 (PDT) Received: from mail-vk1-f181.google.com (mail-vk1-f181.google.com [209.85.221.181]) (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 EBA691201DA for ; Tue, 9 Jul 2019 10:20:44 -0700 (PDT) Received: by mail-vk1-f181.google.com with SMTP id m17so3330894vkl.2 for ; Tue, 09 Jul 2019 10:20:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=AX0M5uSpkE7Vr1vej/ewIQtAvxIpYGCmV85CvXnl4tc=; b=I8pBeCPkN3JNqLgKcrx1C4WWom6kthAzBwVMyqvAC87M5O6Sh5bNobSnzlSjr3BJsa AMYSxiTzqjSbU23rJJQVzQeOFgkZ+37GoDBXI97GQOfxDR/60z4x86prxrx9dvTHUZ2A XB7BMZ5Y+pPcJ6WV7wA+ZYuzvzy2O0K0Emhz6oc2Jl08ElSVwc/sSBjgY94vCaPHjFcN j3ck1FPX0oSGs/V55puB4F3176fsvguFenPrB80F7NXtnJ/oC4XSdhWmYX1GM0+134gj QvFz/jflaQXNu1zSNEdRY2VmFKSbHbIgFuHIY1SsWOXxkMRISvIv+YfZbu/2iugGJcqp MTcQ== X-Gm-Message-State: APjAAAVVZwG/yHC6mL107avlabpVFy83YmlUMHAtRiqTikNqtwwb9aJr Kk6zbBDF8i/k1gZ8V5eiopB5Zz+oie2MLTWkIAd60wJC X-Google-Smtp-Source: APXvYqyiNpCVw5vpK9J9txAo8cu02J4/19MeYpzYhsQKmkUJFtOQsCBVFiqJ8PhQOOf6ZZBAoKPXXXeur6iD7j/Rxhs= X-Received: by 2002:a1f:3c82:: with SMTP id j124mr8619488vka.47.1562692842321; Tue, 09 Jul 2019 10:20:42 -0700 (PDT) MIME-Version: 1.0 From: Daniel Migault Date: Tue, 9 Jul 2019 13:20:31 -0400 Message-ID: To: ace@ietf.org Content-Type: multipart/alternative; boundary="000000000000c27be0058d42c726" Archived-At: Subject: [Ace] draft-ietf-ace-key-groupcomm-02 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: Tue, 09 Jul 2019 17:20:56 -0000 --000000000000c27be0058d42c726 Content-Type: text/plain; charset="UTF-8" Hi, Please find some comments while reading the document. I also have some high level questions that I might have missed in the draft or that are defined somewhere else. The group seems to be defined by its group members and each member are registered with read or write access. What is unclear to me is how these properties (read, write) affect the group communication. Are there any specific cryptographic material or different access policies implemented by the RS for each role ? I am not entirely clear how the group communication is protected. In particular, I am wondering if the source is authenticated or if the key is shared between the different members of the group. I am also wondering how the public key associated to each group member is used by another member. Please find some comments on the documents. Yours, Daniel ACE Working Group F. Palombini Internet-Draft Ericsson AB Intended status: Standards Track M. Tiloca Expires: January 6, 2020 RISE AB July 05, 2019 Key Provisioning for Group Communication using ACE draft-ietf-ace-key-groupcomm-02 Abstract This document defines message formats and procedures for requesting and distributing group keying material using the ACE framework, to protect communications between group members. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on January 6, 2020. Copyright Notice Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Palombini & Tiloca Expires January 6, 2020 [Page 1] Internet-Draft Key Provisioning for Group Communication July 2019 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Authorization to Join a Group . . . . . . . . . . . . . . . . 6 3.1. Authorization Request . . . . . . . . . . . . . . . . . . 7 3.2. Authorization Response . . . . . . . . . . . . . . . . . 7 3.3. Token Post . . . . . . . . . . . . . . . . . . . . . . . 8 4. Key Distribution . . . . . . . . . . . . . . . . . . . . . . 11 4.1. Key Distribution Request . . . . . . . . . . . . . . . . 12 4.2. Key Distribution Response . . . . . . . . . . . . . . . . 13 5. Removal of a Node from the Group . . . . . . . . . . . . . . 16 5.1. Expired Authorization . . . . . . . . . . . . . . . . . . 16 5.2. Request to Leave the Group . . . . . . . . . . . . . . . 16 6. Retrieval of New or Updated Keying Material . . . . . . . . . 17 6.1. Key Re-Distribution Request . . . . . . . . . . . . . . . 18 6.2. Key Re-Distribution Response . . . . . . . . . . . . . . 19 7. Retrieval of Public Keys for Group Members . . . . . . . . . 19 7.1. Public Key Request . . . . . . . . . . . . . . . . . . . 20 7.2. Public Key Response . . . . . . . . . . . . . . . . . . . 20 8. ACE Groupcomm Parameters . . . . . . . . . . . . . . . . . . 21 9. ACE Groupcomm Request Type . . . . . . . . . . . . . . . . . 22 10. Security Considerations . . . . . . . . . . . . . . . . . . . 23 10.1. Update of Keying Material . . . . . . . . . . . . . . . 24 10.2. Block-Wise Considerations . . . . . . . . . . . . . . . 24 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 11.1. ACE Authorization Server Request Creation Hints Registry 25 11.2. ACE Public Key Encoding Registry . . . . . . . . . . . . 25 11.3. ACE Groupcomm Parameters Registry . . . . . . . . . . . 26 11.4. Ace Groupcomm Request Type Registry . . . . . . . . . . 26 11.5. ACE Groupcomm Key Registry . . . . . . . . . . . . . . . 27 11.6. ACE Groupcomm Profile Registry . . . . . . . . . . . . . 28 11.7. ACE Groupcomm Policy Registry . . . . . . . . . . . . . 28 11.8. Sequence Number Synchronization Method Registry . . . . 29 11.9. Expert Review Instructions . . . . . . . . . . . . . . . 29 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 12.1. Normative References . . . . . . . . . . . . . . . . . . 30 12.2. Informative References . . . . . . . . . . . . . . . . . 31 Appendix A. Requirements on Application Profiles . . . . . . . . 33 Appendix B. Document Updates . . . . . . . . . . . . . . . . . . 33 B.1. Version -01 to -02 . . . . . . . . . . . . . . . . . . . 34 B.2. Version -00 to -01 . . . . . . . . . . . . . . . . . . . 34 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 35 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35 Palombini & Tiloca Expires January 6, 2020 [Page 2] Internet-Draft Key Provisioning for Group Communication July 2019 1. Introduction This document expands the ACE framework [I-D.ietf-ace-oauth-authz] to define the format of messages used to request, distribute and renew the keying material in a group communication scenario, e.g. based on multicast [RFC7390][I-D.dijk-core-groupcomm-bis] or on publishing- subscribing [I-D.ietf-core-coap-pubsub]. This is a nit which may be due to my english. My my reading of "e.g. based on " seems to be misleading here - at least to me. I am interpreting the text as 7390 and the two other drafts as examples that could take advantage of the current document. As these document do not seem to consider multicast communication in general - 7390 seem slimited to one-to-many -, this gives, in my opinion a false impression that the scheme describe in this document is much more general. While we do not want to prevent other protocol to re-use the scheme defined here, I believe it would be safer to restrict the current document to these latest document as they provide the group communication framework we are using here. In these were only examples, I would expect the document to provide a description how a more generic framework. The ACE framework is based on CBOR [RFC7049], so CBOR is the format used in this specification. However, using JSON [RFC8259] instead of CBOR is possible, using the conversion method specified in Sections 4.1 and 4.2 of [RFC7049]. This is a comment and there is probably a common understanding of the text above I am missing. My reading is that CBOR and JSON are supported, meaning that I could send a JSON packet or a CBOR packet. Unless this is natively supported, it seems to indicate that two format are supported and I woudl be inclined to say we shoudl maybe pick one of them for inter-operability. In this case CBOR might be appropriated. I am reading that the support for JSON is easily adapted from the current documentation, but not so much recommended. Profiles that use group communication can build on this document to specify the selection of the message parameters defined in this document to use and their values. Known applications that can benefit from this document would be, for example, those addressing group communication based on multicast [RFC7390][I-D.dijk-core-groupcomm-bis] or publishing/subscribing [I-D.ietf-core-coap-pubsub] in ACE. I would suggest to limit the document to these documents, especially if we do not envision any other cases while writing this document. I believe it woudl be also important to remind some characteristics of these groups. Typically it seems these groups envisioned one-to-many communication and are not highly dynamic. I believe it woudl be helpful to have the limitations or characteristics of these groups, so future application could easily see if the key management propose fits their requirements. If the application requires backward and forward security, updated keying material is generated and distributed to the group members (rekeying), when membership changes. A key management scheme performs the actual distribution of the updated keying material to the group. In particular, the key management scheme rekeys the current group members when a new node joins the group, and the remaining group members when a node leaves the group. This document provides a message format for group rekeying that allows to fulfill these requirements. Rekeying mechanisms can be based on [RFC2093], [RFC2094] and [RFC2627]. The latest paragraph provides a high level view of how the protocol works. This is very helpful, but maybe additional text - or a dedicated use case section may be needed to provide the full life cycle of the keys. Typically, I am wondering one a group keys are managed at the initialization of the group. My interpretation of the text is that if I have 1000 battery power motes in my home and each of them join the group one by one, I will have 1000 key updates. I believe it would be good to clarify this. 1.1. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. These words may also appear in this document in lowercase, absent their normative meanings. Readers are expected to be familiar with the terms and concepts described in [I-D.ietf-ace-oauth-authz] and [RFC8152], such as Authorization Server (AS) and Resource Server (RS). This document additionally uses the following terminology: o Transport profile, to indicate a profile of ACE as per Section 5.6.4.3 of [I-D.ietf-ace-oauth-authz]. That is, a transport profile specifies the communication protocol and communication security protocol between an ACE Client and Resource Palombini & Tiloca Expires January 6, 2020 [Page 3] Internet-Draft Key Provisioning for Group Communication July 2019 Server, as well as proof-of-possession methods, if it supports proof-of-possession access tokens. Tranport profiles of ACE include, for instance, [I-D.ietf-ace-oscore-profile], [I-D.ietf-ace-dtls-authorize] and [I-D.ietf-ace-mqtt-tls-profile]. o Application profile, to indicate a profile of ACE that defines how applications enforce and use supporting security services they require. These services include, for instance, provisioning, revocation and (re-)distribution of keying material. An application profile may define specific procedures and message formats. 2. Overview +------------+ +-----------+ | AS | | KDC | | | .-------->| | +------------+ / +-----------+ ^ / | / v / +-----------+ +------------+ / +------------+ |+-----------+ | Client |<-' | Dispatcher | ||+-----------+ | |<-------->| (RS) |<------->|| Group | +------------+ +------------+ +| members | +-----------+ Figure 1: Key Distribution Participants The following participants (see Figure 1) take part in the authorization and key distribution. o Client (C): node that wants to join the group communication. It can request write and/or read rights. I am wondering if one can have write access without having read access. It seems to me - but I might be wrong - that write access provides read access. If that is correct, I am wondering if we could have read or write. The figure seems to give two roles of the Client: 1) the ability to join the group with some interactions with KDC as well as 2) the ability to send message with some interactions with the Dispatcher. I am wondering if there are any reasons the latest is not mentioned. o Authorization Server (AS): same as AS in the ACE Framework; it enforces access policies, and knows if a node is allowed to join the group with write and/or read rights. o Key Distribution Center (KDC): maintains the keying material to protect group communications, and provides it to Clients authorized to join the group. During the first part of the exchange (Section 3), it takes the role of the RS in the ACE Framework. During the second part (Section 4), which is not based on the ACE Framework, it distributes the keying material. In addition, it provides the latest keying material to group members when requested. If required by the application, the KDC renews Palombini & Tiloca Expires January 6, 2020 [Page 4] Internet-Draft Key Provisioning for Group Communication July 2019 and re-distributes the keying material in the group when membership changes. o Dispatcher: entity through which the Clients communicate with the group and which distributes messages to the group members. Examples of dispatchers are: the Broker node in a pub-sub setting; a relayer node for group communication that delivers group messages as multiple unicast messages to all group members; an implicit entity as in a multicast communication setting, where messages are transmitted to a multicast IP address and delivered on the transport channel. This document specifies the message flows and formats for: o Authorizing a new node to join the group (Section 3), and providing it with the group keying material to communicate with the other group members (Section 4). o Removing of a current member from the group (Section 5). o Retrieving keying material as a current group member (Section 6 and Section 7). o Renewing and re-distributing the group keying material (rekeying) upon a membership change in the group (Section 4.2 and Section 5). Figure 2 provides a high level overview of the message flow for a node joining a group communication setting. C AS KDC Dispatcher Group | | | | Member | | | | \ | | Authorization Request | | | | Defined | |----------------------------->| | | | in the ACE | | | | | | framework | | Authorization Response | | | | | |<-----------------------------| | | | | | | | | | | |--------- Token Post ---------------->| | / | | | | | |---- Key Distribution Request ------->| | | | | | | |<--- Key Distribution Response ------ | --- Group Rekeying ----->| | | | |<================== Protected communication ===|================>| | | | Figure 2: Message Flow Upon New Node's Joining "Defined in the ACE framework" : it is unclear to me if it designates the DIspatcher of the Authorization and Token Post exchanges. I think that is the latest. I understand the Dispatcher is not involved in the distribution of the keying material, but only to the distribution of the messages. If that is correct, it does not appear clearly on the figure, maybe placing Dispatcher and Group Members below the Group Keying arrow would clarify this. I think Protected communication is not in the scope of this draft, so it might specified as well as it is being done for the ACE framework - if that is correct. Protected communication is usually interpreted as end-to-end security and this may not be achieved with group communication. Maybe secure group communication might be more appropriated. Palombini & Tiloca Expires January 6, 2020 [Page 5] Internet-Draft Key Provisioning for Group Communication July 2019 The exchange of Authorization Request and Authorization Response between Client and AS MUST be secured, as specified by the transport profile of ACE used between Client and KDC. The exchange of Key Distribution Request and Key Distribution Response between Client and KDC MUST be secured, as a result of the transport profile of ACE used between Client and KDC. All further communications between the Client and the KDC MUST be secured, for instance with the same security mechanism used for the Key Distribution exchange. All communications between a Client and the other group members MUST be secured using the keying material provided in Section 4. 3. Authorization to Join a Group This section describes in detail the format of messages exchanged by the participants when a node requests access to a group. The first part of the exchange is based on ACE [I-D.ietf-ace-oauth-authz]. As defined in [I-D.ietf-ace-oauth-authz], the Client requests from the AS an authorization to join the group through the KDC (see Section 3.1). If the request is approved and authorization is granted, the AS provides the Client with a proof-of-possession access token and parameters to securely communicate with the KDC (see Section 3.2). Communications between the Client and the AS MUST be secured, according to the transport profile of ACE used. The Content-Format used in the messages is the one specified by the used transport profile of ACE (e.g. application/ace+cbor for the first two messages and application/cwt for the third message, depending on the format of the access token). Figure 3 gives an overview of the exchange described above. Client AS KDC | | | |---- Authorization Request: POST /token ------>| | | | | |<--- Authorization Response: 2.01 (Created) ---| | | | | |----- POST Token: POST /authz-info --------------->| | | Figure 3: Message Flow of Join Authorization Palombini & Tiloca Expires January 6, 2020 [Page 6] Internet-Draft Key Provisioning for Group Communication July 2019 3.1. Authorization Request The Authorization Request sent from the Client to the AS is as defined in Section 5.6.1 of [I-D.ietf-ace-oauth-authz] and MUST contain the following parameters: o 'grant_type', with value "client_credentials". Additionally, the Authorization Request MAY contain the following parameters, which, if included, MUST have the corresponding values: I believe the value is understood as the value in a dictionary (key, value) - rather then the value of the value itself. I suggest to provide explicitly how the AS behaves if the value format is not recognized or if the provided value is unknown to the AS. More specifically, is the parameter ignored or the exchange aborted. o 'scope', containing the identifier of the specific group (or topic in the case of pub-sub) that the Client wishes to access, and optionally the role(s) that the Client wishes to take. This value is a CBOR array encoded as a byte string, which contains: * As first element, the identifier of the specific group or topic. * Optionally, as second element, the role (or CBOR array of roles) the Client wishes to take in the group. The encoding of the group or topic identifier and of the role identifiers is application specific. o 'audience', with an identifier of a KDC. o 'req_cnf', as defined in Section 3.1 of [I-D.ietf-ace-oauth-params], optionally containing the public key or a reference to the public key of the Client, if it wishes to communicate that to the AS. o Other additional parameters as defined in [I-D.ietf-ace-oauth-authz], if necessary. 3.2. Authorization Response The Authorization Response sent from the AS to the Client is as defined in Section 5.6.2 of [I-D.ietf-ace-oauth-authz] and MUST contain the following parameters: o 'access_token', containing the proof-of-possession access token. o 'cnf' if symmetric keys are used, not present if asymmetric keys are used. This parameter is defined in Section 3.2 of [I-D.ietf-ace-oauth-params] and contains the symmetric proof-of- possession key that the Client is supposed to use with the KDC. Palombini & Tiloca Expires January 6, 2020 [Page 7] Internet-Draft Key Provisioning for Group Communication July 2019 o 'rs_cnf' if asymmetric keys are used, not present if symmetric keys are used. This parameter is as defined in Section 3.2 of [I-D.ietf-ace-oauth-params] and contains information about the public key of the KDC. o 'exp', contains the lifetime in seconds of the access token. This parameter MAY be omitted if the application defines how the expiration time is communicated to the Client via other means, or if it establishes a default value. Additionally, the Authorization Response MAY contain the following parameters, which, if included, MUST have the corresponding values: Same comment as above regarding the MUST statement. o 'scope', which mirrors the 'scope' parameter in the Authorization Request (see Section 3.1). Its value is a CBOR array encoded as a byte string, containing: * As first element, the identifier of the specific group or topic the Client is authorized to access. * Optionally, as second element, the role (or CBOR array of roles) the Client is authorized to take in the group. The encoding of the group or topic identifier and of the role identifiers is application specific. o Other additional parameters as defined in [I-D.ietf-ace-oauth-authz], if necessary. The access token MUST contain all the parameters defined above (including the same 'scope' as in this message, if present, or the 'scope' of the Authorization Request otherwise), and additionally other optional parameters that the transport profile of ACE requires. When receiving an Authorization Request from a Client that was previously authorized, and which still owns a valid non expired access token, the AS replies with an Authorization Response with a new access token. 3.3. Token Post The Client sends a CoAP POST request including the access token to the KDC, as specified in Section 5.8.1 of [I-D.ietf-ace-oauth-authz]. If the specific transport profile of ACE defines it, the Client MAY use a different endpoint than /authz-info at the KDC to post the access token to. Palombini & Tiloca Expires January 6, 2020 [Page 8] Internet-Draft Key Provisioning for Group Communication July 2019 Optionally, the Client might need to request necessary information concerning the public keys in the group, as well as concerning the algorithm and related parameters for computing signatures in the group. In such a case, the joining node MAY ask for that information to the KDC in this same request. To this end, it sends the CoAP POST request to the /authz-info endpoint using the Content-Format "application/ace+cbor" defined in Section 8.14 of [I-D.ietf-ace-oauth-authz], and includes also the following parameters: That the Client MAY ask for this information suggests that this is not necessary. It would maybe worth indicating when these information are not requested. I see two cases 1) when public key is not involved, and 2) when this is pre-configured or provided by other means. I am not sure these cases make senses, but in the latest cases, it would be good to specify why we do not end up in a dead lock. Public key is associated with authentication. I understand that the authentication is necessary to the RS rather than the group members. If that is correct, I believe that specifying the entity associated to the public key - here the RS - would be clearer. o 'sign_info' defined in Section 3.3.1, encoding the CBOR simple value Null, to require information and parameters on the signature algorithm and on the public keys used in the group. o 'pub_key_enc' defined in Section 3.3.2, encoding the CBOR simple value Null, to require information on the exact encoding of public keys used in the group. The CDDL notation of the 'sign_info' and 'pub_key_enc' parameters formatted as in the request is given below. sign_info_req = nil pub_key_enc_req = nil Alternatively, the joining node may retrieve this information by other means. After successful verification, the Client is authorized to receive the group keying material from the KDC and join the group. In particular, the KDC replies to the Client with a 2.01 (Created) response, using Content-Format "application/ace+cbor" defined in Section 8.14 of [I-D.ietf-ace-oauth-authz]. The payload of the 2.01 response is a CBOR map, which MUST include a nonce N generated by the KDC. The Client may use this nonce for proving the possession of its own private key (see the 'client_cred_verify' parameter in Section 4). Optionally, if they were included in the request, the AS MAY include the 'sign_info' parameter as well as the 'pub_key_enc' parameter defined in Section 3.3.1 and Section 3.3.2 of this specification, respectively. The 'sign_info' parameter MUST be present if the POST request included the 'sign_info' parameter with value Null. If present, the 'sign_info' parameter of the 2.01 (Created) response is a CBOR array formatted as follows. Palombini & Tiloca Expires January 6, 2020 [Page 9] Internet-Draft Key Provisioning for Group Communication July 2019 o The first element 'sign_alg' is an integer or a text string, indicating the signature algorithm used in the group. It is required of the application profiles to define specific values for this parameter. o The second element 'sign_parameters' indicates the parameters of the signature algorithm. Its structure depends on the value of 'sign_alg'. It is required of the application profiles to define specific values for this parameter. If no parameters of the signature algorithm are specified, 'sign_parameters' MUST be encoding the CBOR simple value Null. o The third element 'sign_key_parameters' indicates the parameters of the key used with the signature algorithm. Its structure depends on the value of 'sign_alg'. It is required of the application profiles to define specific values for this parameter. If no parameters of the key used with the signature algorithm are specified, 'sign_key_parameters' MUST be encoding the CBOR simple value Null. The 'pub_key_enc' parameter MUST be present if the POST request included the 'pub_key_enc' parameter with value Null. If present, the 'pub_key_enc' parameter of the 2.01 (Created) response is a CBOR integer, indicating the encoding of public keys used in the group. The values of this field are registered in the "ACE Public Key Encoding" Registry, defined in Section 11.2. It is required of the application profiles to define specific values to use for this parameter. The CDDL notation of the 'sign_info' and 'pub_key_enc' parameters formatted as in the response is given below. sign_info_res = [ sign_alg : int / tstr, sign_parameters : any / nil, sign_key_parameters : any / nil ] pub_key_enc_res = int Note that the CBOR map specified as payload of the 2.01 (Created) response may include further parameters, e.g. according to the signalled transport profile of ACE. Note that this step could be merged with the following message from the Client to the KDC, namely Key Distribution Request. Palombini & Tiloca Expires January 6, 2020 [Page 10] Internet-Draft Key Provisioning for Group Communication July 2019 3.3.1. 'sign_info' Parameter The 'sign_info' parameter is an OPTIONAL parameter of the AS Request Creation Hints message defined in Section 5.1.2. of [I-D.ietf-ace-oauth-authz]. This parameter contains information and parameters about the signature algorithm and the public keys to be used between the Client and the RS. Its exact content is application specific. 3.3.2. 'pub_key_enc' Parameter The 'pub_key_enc' parameter is an OPTIONAL parameter of the AS Request Creation Hints message defined in Section 5.1.2. of [I-D.ietf-ace-oauth-authz]. This parameter contains information about the exact encoding of public keys to be used between the Client and the RS. Its exact content is application specific. 4. Key Distribution This section defines how the keying material used for group communication is distributed from the KDC to the Client, when joining the group as a new member. If not previously established, the Client and the KDC MUST first establish a pairwise secure communication channel using ACE. I have the impression that such agreement is performed during the registration request / resopnse with the AS. Is that correct or are we considering another exchange ? The exchange of Key Distribution Request-Response MUST occur over that secure channel. The Client and the KDC MAY use that same secure channel to protect further pairwise communications, that MUST be secured. During this exchange, the Client sends a request to the AS, specifying the group it wishes to join (see Section 4.1). Then, the KDC verifies the access token and that the Client is authorized to join that group; if so, it provides the Client with the keying material to securely communicate with the member of the group (see Section 4.2). The Content-Format used in the messages is set to application/cbor. I believe the paragraph above describes how the secure channel is established between the Client and the KDC. If that is correct that may be mention explicitly. I would suggest to replace "During this exchange" by "During the Authorization request/respons e exchange". Figure 4 gives an overview of the exchange described above. Client KDC | | |---- Key Distribution Request: POST /group-id --->| | | |<--- Key Distribution Response: 2.01 (Created) ---| | | Figure 4: Message Flow of Key Distribution to a New Group Member Palombini & Tiloca Expires January 6, 2020 [Page 11] Internet-Draft Key Provisioning for Group Communication July 2019 The same set of message can also be used for the following cases, when the Client is already a group member: o The Client wishes to (re-)get the current keying material, for cases such as expiration, loss or suspected mismatch, due to e.g. reboot or missed group rekeying. This is further discussed in Section 6. o The Client wishes to (re-)get the public keys of other group members, e.g. if it is aware of new nodes joining the group after itself. This is further discussed in Section 7. Additionally, the format of the payload of the Key Distribution Response (Section 4.2) can be reused for messages sent by the KDC to distribute updated group keying material, in case of a new node joining the group or of a current member leaving the group. The key management scheme used to send such messages could rely on, e.g., multicast in case of a new node joining or unicast in case of a node leaving the group. Note that proof-of-possession to bind the access token to the Client is performed by using the proof-of-possession key bound to the access token for establishing secure communication between the Client and the KDC. If the application requires backward security, the KDC SHALL generate new group keying material and securely distribute it to all the current group members, using the message format defined in this section. Application profiles may define alternative message formats. I am wondering why SHALL is introduced here as MUST has been used throughout the document. I do not see any difference between SHALL and MUST, so if that is correct, I would recommend to use MUST throughout the document. 4.1. Key Distribution Request The Client sends a Key Distribution Request to the KDC. This corresponds to a CoAP POST request to the endpoint in the KDC associated to the group to join. The endpoint in the KDC is associated to the 'scope' value of the Authorization Request/ Response. The payload of this request is a CBOR map which MUST contain the following fields: o 'type', encoded as a CBOR int, with value 1 ("key distribution"). Additionally, the CBOR map in the payload MAY contain the following fields, which, if included, MUST have the corresponding values: o 'scope', with value the specific resource that the Client is authorized to access (i.e. group or topic identifier) and role(s), encoded as in Section 3.1. Palombini & Tiloca Expires January 6, 2020 [Page 12] Internet-Draft Key Provisioning for Group Communication July 2019 o 'get_pub_keys', if the Client wishes to receive the public keys of the other nodes in the group from the KDC. The value is an empty CBOR array. This parameter may be present if the KDC stores the public keys of the nodes in the group and distributes them to the Client; it is useless to have here if the set of public keys of the members of the group is known in another way, e.g. it was provided by the AS. For large groups, there might be a need to limit the size of the response and so to enable that the batch of keys be retrieved in multiple exchanges or via another redirection mechanism. o 'client_cred', with value the public key or certificate of the Client, encoded as a CBOR byte string. If the KDC is managing (collecting from/distributing to the Client) the public keys of the group members, this field contains the public key of the Client. The default encoding for public keys is COSE Keys. Alternative specific encodings of this parameter MAY be defined in applications of this specification. o 'client_cred_verify', encoded as a CBOR byte string. This parameter contains a signature computed by the Client over the nonce N received from the KDC in the 2.01 (Created) response to the token POST request (see Section 3.3). The Client computes the signature by using its own private key, whose corresponding public key is either directly specified in the 'client_cred' parameter or included in the certificate specified in the 'client_cred' parameter. This parameter MUST be present if the 'client_cred' parameter is present. o 'pub_keys_repos', can be present if a certificate is present in the 'client_cred' field, with value a list of public key repositories storing the certificate of the Client. This parameter is encoded as a CBOR array of CBOR text strings, each of which specifies the URI of a key repository. 4.2. Key Distribution Response The KDC verifies that the 'scope' received in the Key Distribution Request, if present, is a subset of the 'scope' stored in the access token associated to this client. If verification fails, the KDC MUST respond with a 4.01 (Unauthorized) error message. If the Key Distribution Request is not formatted correctly (e.g. no 'scope' field present while expected, or unknown fields present), the KDC MUST respond with 4.00 (Bad Request) error message. If verification succeeds, the KDC sends a Key Distribution success Response to the Client. The Key Distribution success Response corresponds to a 2.01 Created message. The payload of this response is a CBOR map, which MUST contain: Palombini & Tiloca Expires January 6, 2020 [Page 13] Internet-Draft Key Provisioning for Group Communication July 2019 o 'kty', identifying the key type of the 'key' parameter. The set of values can be found in the "Key Type" column of the "ACE Groupcomm Key" Registry. Implementations MUST verify that the key type matches the application profile being used, if present, as registered in the "ACE Groupcomm Key" registry. o 'key', containing the keying material for the group communication, or information required to derive it. The exact format of the 'key' value MUST be defined in applications of this specification. Additionally, documents specifying the key format MUST register it in the "ACE Groupcomm Key" registry, including its name, type and application profile to be used with, as defined in the "ACE Groupcomm Key" registry, defined in Section 11.5. +----------+----------------+---------+-------------------------+ | Name | Key Type Value | Profile | Description | +----------+----------------+---------+-------------------------+ | Reserved | 0 | | This value is reserved | +----------+----------------+---------+-------------------------+ Figure 5: Key Type Values Optionally, the Key Distribution Response MAY contain the following parameters, which, if included, MUST have the corresponding values: o 'profile', with value a CBOR integer that MUST be used to uniquely identify the application profile for group communication. The value MUST be registered in the "ACE Groupcomm Profile" Registry. o 'exp', with value the expiration time of the keying material for the group communication, encoded as a CBOR unsigned integer or floating-point number. This field contains a numeric value representing the number of seconds from 1970-01-01T00:00:00Z UTC until the specified UTC date/time, ignoring leap seconds, analogous to what specified in Section 2 of [RFC7519]. o 'pub_keys', may only be present if 'get_pub_keys' was present in the Key Distribution Request. This parameter is a CBOR byte string, which encodes the public keys of all the group members paired with the respective member identifiers. The default encoding for public keys is COSE Keys, so the default encoding for 'pub_keys' is a CBOR byte string wrapping a COSE_KeySet (see [RFC8152]), which contains the public keys of all the members of the group. In particular, each COSE Key in the COSE_KeySet includes the identifier of the corresponding group member as value of its 'kid' key parameter. Alternative specific encodings of Palombini & Tiloca Expires January 6, 2020 [Page 14] Internet-Draft Key Provisioning for Group Communication July 2019 this parameter MAY be defined in applications of this specification. o 'group_policies', with value a CBOR map, whose entries specify how the group handles specific management aspects. These include, for instance, approaches to achieve synchronization of sequence numbers among group members. The elements of this field are registered in the "ACE Groupcomm Policy" Registry. This specification defines the two elements "Sequence Number Synchronization Method" and "Key Update Check Interval", which are summarized in Figure 6. Application profiles that build on this document MUST specify the exact content format of included map entries. +-----------------+-------+----------|--------------------|------------+ | Name | CBOR | CBOR | Description | Reference | | | label | type | | | |-----------------+-------+----------|--------------------|------------| | Sequence Number | TBD1 | tstr/int | Method for a re- | [[this | | Synchronization | | | cipient node to | document]] | | Method | | | synchronize with | | | | | | sequence numbers | | | | | | of a sender node. | | | | | | Its value is taken | | | | | | from the 'Value' | | | | | | column of the | | | | | | Sequence Number | | | | | | Synchronization | | | | | | Method registry | | | | | | | | | Key Update | TBD2 | int | Polling interval | [[this | | Check Interval | | | in seconds, to | document]] | | | | | check for new | | | | | | keying material at | | | | | | the KDC | | +-----------------+-------+----------|--------------------|------------+ Figure 6: ACE Groupcomm Policies o 'mgt_key_material', encoded as a CBOR byte string and containing the administrative keying material to participate in the group rekeying performed by the KDC. The exact format and content depend on the specific rekeying scheme used in the group, which may be specified in the application profile. Specific application profiles that build on this document need to specify how exactly the keying material is used to protect the group communication. Palombini & Tiloca Expires January 6, 2020 [Page 15] Internet-Draft Key Provisioning for Group Communication July 2019 5. Removal of a Node from the Group This section describes at a high level how a node can be removed from the group. If the application requires forward security, the KDC SHALL generate new group keying material and securely distribute it to all the current group members but the leaving node, using the message format defined in Section 4.2. Application profiles may define alternative message formats. 5.1. Expired Authorization If the AS provides Token introspection (see Section 5.7 of [I-D.ietf-ace-oauth-authz]), the KDC can optionally use and check whether: o the node is not authorized anymore; o the access token is still valid, upon its expiration. Either case, once aware that a node is not authorized anymore, the KDC has to remove the unauthorized node from the list of group members, if the KDC keeps track of that. 5.2. Request to Leave the Group A node can actively request to leave the group. In this case, the Client can send a request formatted as follows to the KDC, to abandon the group. The client MUST use the protected channel established with ACE, mentioned in Section 4. To request to leave a group, the client MUST send a CoAP POST request to the endpoint in the KDC associated to the group to leave (same endpoint used in Section 4.1 for Key Distribution requests). The payload of this Leave Request is a CBOR map which MUST contain: o 'type', encoded as a CBOR int, with value 2 ("leave"). o 'scope', with value the specific resource that the Client is authorized to access (i.e. group or topic identifier) and wants to leave, encoded as in Section 3.1. The 'role' field is omitted. Note that the 'role' field is omitted since such a request should only be used to leave a group altogether. If the leaving node wants to be part of a group with fewer roles, it does not need to communicate that to the KDC, and can simply stop acting according to such roles. Palombini & Tiloca Expires January 6, 2020 [Page 16] Internet-Draft Key Provisioning for Group Communication July 2019 If the Leave Request is such that the KDC cannot extract all the necessary information to understand and process it correctly (e.g. no 'scope' field present), the KDC MUST respond with a 4.00 (Bad Request) error message. Otherwise, the KDC MUST remove the leaving node from the list of group members, if the KDC keeps track of that. Note that, after having left the group, a node may wish to join it again. Then, as long as the node is still authorized to join the group, i.e. it has a still valid access token, it can re-request to join the group directly to the KDC without needing to retrieve a new access token from the AS. This means that the KDC needs to keep track of nodes with valid access tokens, before deleting all information about the leaving node. 6. Retrieval of New or Updated Keying Material A node stops using the group keying material upon its expiration, according to the 'exp' parameter specified in the retained COSE Key. Then, if it wants to continue participating in the group communication, the node has to request new updated keying material to the KDC. In this case, and depending on what part of the keying material is expired, the client may need to communicate to the KDC its need for that part to be renewed: for example, if the Client uses an individual key to protect outgoing traffic and has to renew it, the node may request a new one, or new input material to derive it, without renewing the whole group keying material. The Client may perform the same request to the KDC also upon receiving messages from other group members without being able to retrieve the material to correctly decrypt them. This may be due to a previous update of the group keying material (rekeying) triggered by the KDC, that the Client was not able to receive or decrypt. Note that policies can be set up so that the Client sends a request to the KDC only after a given number of unsuccessfully decrypted incoming messages. It is application dependent and pertaining to the particular message exchange (e.g. [I-D.ietf-core-oscore-groupcomm]) to set up policies that instruct clients to retain unsuccessfully decrypted messages and for how long, so that they can be decrypted after getting updated keying material, rather than just considered non valid messages to discard right away. The same request could also be sent by the client without being triggered by a failed decryption of a message, if the client wants to confirm that it has the latest group keying material. If that is the case, the client will receive from the KDC the same group keying material it has in memory. Palombini & Tiloca Expires January 6, 2020 [Page 17] Internet-Draft Key Provisioning for Group Communication July 2019 Note that the difference between the keying material renewal request and the keying material update request is that the first one triggers the KDC to produce new keying material for that node, while the second one only triggers distribution (the renewal might have happened independently, because of expiration). Once a node receives new individual keying material, other group members may need to use the update keying material request to retrieve it. Alternatively, the re-distribution of keying material can be initiated by the KDC, which e.g.: o Can maintain an Observable resource to send notifications to Clients when the keying material is updated. Such a notification would have the same payload as the Key Re-Distribution Response defined in Section 6.2. o Can send the payload of the Key Re-Distribution Response as one or multiple multicast requests to the members of the group, using secure rekeying schemes such as [RFC2093][RFC2094][RFC2627]. o Can send unicast requests to each Client over a secure channel, with the Key Re-Distribution Response as payload. o Can act as a publisher in a pub-sub scenario, and update the keying material by publishing on a specific topic on a broker, which all the members of the group are subscribed to. Note that these methods of KDC-initiated key re-distribution have different security properties and require different security associations. 6.1. Key Re-Distribution Request To request a re-distribution of keying material, the Client sends a shortened Key Distribution Request to the KDC (Section 4.1), formatted as follows. The payload MUST contain the following fields: o 'type', encoded as a CBOR int, with value 3 ("update key") if the request is intended to retrieve updated group keying material, and 4 ("new") if the request is intended for the KDC to produce and provide new individual keying material for the Client. o 'scope', which contains only the identifier of the specific group or topic, encoded as in Section 3.1. That is, the role field is not present. Palombini & Tiloca Expires January 6, 2020 [Page 18] Internet-Draft Key Provisioning for Group Communication July 2019 6.2. Key Re-Distribution Response The KDC receiving a Key Re-Distribution Request MUST check that it is storing a valid access token from that client for that scope. If that is not the case, i.e. it does not store the token or the token is not valid for that client for the scope requested, the KDC MUST respond with a 4.01 (Unauthorized) error message. Analogously to Section 4.2, if the Key Re-Distribution Request is not formatted correctly (e.g. no 'scope' field present, or unknown fields present), the KDC MUST respond with a 4.00 (Bad Request) error message. Otherwise, the KDC replies to the Client with a Key Distribution Response, which MUST include the 'kty', 'key' and 'exp' parameters specified in Section 4.2. The Key Distribution Response MAY also include the 'profile', 'group_policies' and 'mgt_key_material' parameters specified in Section 4.2. Note that this response might simply re-provide the same keying material currently owned by the Client, if it has not been renewed. 7. Retrieval of Public Keys for Group Members In case the KDC maintains the public keys of group members, a node in the group can contact the KDC to request public keys of either all group members or a specified subset, using the messages defined below. Figure 7 gives an overview of the exchange described above. Client KDC | | |---- Public Key Request: POST /group-id --->| | | |<--- Public Key Response: 2.01 (Created) ---| | | Figure 7: Message Flow of Public Key Request-Response Note that these messages can be combined with the Key Re-Distribution messages in Section 6, to request at the same time the keying material and the public keys. In this case, either a new endpoint at the KDC may be used, or additional information needs to be sent in the request payload, to distinguish these combined messages from the Public Key messages described below, since they would be identical otherwise. I am wondering why public key is needed in a context of group communication. I do not expect group members but only by the RS. It is unclear to me how the Palombini & Tiloca Expires January 6, 2020 [Page 19] Internet-Draft Key Provisioning for Group Communication July 2019 7.1. Public Key Request To request public keys, the Client sends a shortened Key Distribution Request to the KDC (Section 4.1), formatted as follows. The payload of this request MUST contain the following fields: o 'type', encoded as a CBOR int, with value 5 ("pub keys"). o 'get_pub_keys', which has as value a CBOR array including either: * no elements, i.e. an empty array, in order to request the public key of all current group members; or * N elements, each of which is the identifier of a group member encoded as a CBOR byte string, in order to request the public key of the specified nodes. o 'scope', which contains only the identifier of the specific group or topic, encoded as in Section 3.1. That is, the role field is not present. 7.2. Public Key Response The KDC replies to the Client with a Key Distribution Response containing only the 'pub_keys' parameter, as specified in Section 4.2. The payload of this response contains the following field: o 'pub_keys', which contains either: * the public keys of all the members of the group, if the 'get_pub_keys' parameter of the Public Key request was an empty array; or * the public keys of the group members with the identifiers specified in the 'get_pub_keys' parameter of the Public Key request. The KDC may enforce one of the following policies, in order to handle possible identifiers that are included in the 'get_pub_keys' parameter of the Public Key request but are not associated to any current group member. o The KDC silently ignores those identifiers. o The KDC retains public keys of group members for a given amount of time after their leaving, before discarding them. As long as such Palombini & Tiloca Expires January 6, 2020 [Page 20] Internet-Draft Key Provisioning for Group Communication July 2019 public keys are retained, the KDC provides them to a requesting Client. Either case, a node that has left the group should not expect any of its outgoing messages to be successfully processed, if received after its leaving, due to a possible group rekeying occurred before the message reception. 8. ACE Groupcomm Parameters This specification defines a number of fields used during the message exchange. The table below summarizes them, and specifies the CBOR key to use instead of the full descriptive name. Palombini & Tiloca Expires January 6, 2020 [Page 21] Internet-Draft Key Provisioning for Group Communication July 2019 +--------------+----------+---------------+ | Name | CBOR Key | CBOR Type | +--------------+----------+---------------+ | scope | TBD | array | +--------------+----------+---------------+ | get_pub_keys | TBD | array | +--------------+----------+---------------+ | client_cred | TBD | byte string | +--------------+----------+---------------+ | client_cred_ | TBD | byte string | | verify | | | +--------------+----------+---------------+ | pub_keys_ | TBD | array | | repos | | | +--------------+----------+---------------+ | kty | TBD | int / byte | | | | string | +--------------+----------+---------------+ | key | TBD | see "ACE | | | | Groupcomm | | | | Key" Registry | +--------------+----------+---------------+ | profile | TBD | int | +--------------+----------+---------------+ | exp | TBD | int / float | +--------------+----------+---------------+ | pub_keys | TBD | byte string | +--------------+----------+---------------+ | group_ | TBD | map | | policies | | | +--------------+----------+---------------+ | mgt_key_ | TBD | byte string | | material | | | +--------------+----------+---------------+ | type | TBD | int | +--------------+----------+---------------+ 9. ACE Groupcomm Request Type This specification defines a number of types of requests. The table below summarizes them. Palombini & Tiloca Expires January 6, 2020 [Page 22] Internet-Draft Key Provisioning for Group Communication July 2019 +------------------+----------+ | Name | Value | +------------------+----------+ | key distribution | 1 | +------------------+----------+ | leave | 2 | +------------------+----------+ | update key | 3 | +------------------+----------+ | new | 4 | +------------------+----------+ | pub keys | 5 | +------------------+----------+ 10. Security Considerations When a Client receives a message from a sender for the first time, it needs to have a mechanism in place to avoid replay, e.g. Appendix B.2 of [I-D.ietf-core-object-security]. The KDC must renew the group keying material upon its expiration. The KDC should renew the keying material upon group membership change, and should provide it to the current group members through the rekeying scheme used in the group. The KDC may enforce a rekeying policy that takes into account the overall time required to rekey the group, as well as the expected rate of changes in the group membership. That is, the KDC may not rekey the group at every membership change, for instance if members' joining and leaving occur frequently and performing a group rekeying takes too long. Instead, the KDC may rekey the group after a minum number of group members have joined or left within a given time interval, or during predictable network inactivity periods. However, this would result in the KDC not constantly preserving backward and forward security. In fact, newly joining group members could be able to access the keying material used before their joining, and thus could access past group communications. Also, until the KDC performs a group rekeying, the newly leaving nodes would still be able to access upcoming group communications that are protected with the keying material that has not yet been updated. Palombini & Tiloca Expires January 6, 2020 [Page 23] Internet-Draft Key Provisioning for Group Communication July 2019 10.1. Update of Keying Material A group member can receive a message shortly after the group has been rekeyed, and new keying material has been distributed by the KDC. In the following two cases, this may result in misaligned keying material between the group members. In the first case, the sender protects a message using the old keying material. However, the recipient receives the message after having received the new keying material, hence not being able to correctly process it. A possible way to ameliorate this issue is to preserve the old, recent, keying material for a maximum amount of time defined by the application. By doing so, the recipient can still try to process the received message using the old retained keying material as second attempt. Note that a former (compromised) group member can take advantage of this by sending messages protected with the old retained keying material. Therefore, a conservative application policy should not admit the storage of old keying material. In the second case, the sender protects a message using the new keying material, but the recipient receives that request before having received the new keying material. Therefore, the recipient would not be able to correctly process the request and hence discards it. If the recipient receives the new keying material shortly after that and the sender endpoint uses CoAP retransmissions, the former will still be able to receive and correctly process the message. In any case, the recipient should actively ask the KDC for an updated keying material according to an application-defined policy, for instance after a given number of unsuccessfully decrypted incoming messages. 10.2. Block-Wise Considerations If the block-wise options [RFC7959] are used, and the keying material is updated in the middle of a block-wise transfer, the sender of the blocks just changes the keying material to the updated one and continues the transfer. As long as both sides get the new keying material, updating the keying material in the middle of a transfer will not cause any issue. Otherwise, the sender will have to transmit the message again, when receiving an error message from the recipient. Compared to a scenario where the transfer does not use block-wise, depending on how fast the keying material is changed, the nodes might consume a larger amount of the network resending the blocks again and again, which might be problematic. Palombini & Tiloca Expires January 6, 2020 [Page 24] Internet-Draft Key Provisioning for Group Communication July 2019 11. IANA Considerations This document has the following actions for IANA. 11.1. ACE Authorization Server Request Creation Hints Registry IANA is asked to register the following entries in the "ACE Authorization Server Request Creation Hints" Registry defined in Section 8.1 of [I-D.ietf-ace-oauth-authz]. o Name: sign_info o CBOR Key: TBD (range -256 to 255) o Value Type: any o Reference: [[This specification]] o Name: pub_key_enc o CBOR Key: TBD (range -256 to 255) o Value Type: integer o Reference: [[This specification]] 11.2. ACE Public Key Encoding Registry This specification establishes the "ACE Public Key Encoding" IANA Registry. The Registry has been created to use the "Expert Review Required" registration procedure [RFC8126]. Expert review guidelines are provided in Section 11.9. It should be noted that, in addition to the expert review, some portions of the Registry require a specification, potentially a Standards Track RFC, be supplied as well. The columns of this Registry are: o Name: This is a descriptive name that enables easier reference to the item. The name MUST be unique. It is not used in the encoding. o Value: The value to be used to identify this public key encoding. This value MUST be unique. The value can be a positive or a negative integer. Integer values between 0 and 255 are designated as Standards Track Document required. Integer values from 256 to 65535 are designated as Specification Required. Integer values of Palombini & Tiloca Expires January 6, 2020 [Page 25] Internet-Draft Key Provisioning for Group Communication July 2019 greater than 65535 are designated as expert review. Integer values less than -65536 are marked as private use. o Description: This field contains a brief description for this public key encoding. o Reference: This field contains a pointer to the public specification providing the public key encoding, if one exists. The value 0 is to be marked as "Reserved". 11.3. ACE Groupcomm Parameters Registry This specification establishes the "ACE Groupcomm Parameters" IANA Registry. The Registry has been created to use the "Expert Review Required" registration procedure [RFC8126]. Expert review guidelines are provided in Section 11.9. The columns of this Registry are: o Name: This is a descriptive name that enables easier reference to the item. The name MUST be unique. It is not used in the encoding. o CBOR Key: This is the value used as CBOR key of the item. These values MUST be unique. The value can be a positive integer, a negative integer, or a string. o CBOR Type: This contains the CBOR type of the item, or a pointer to the registry that defines its type, when that depends on another item. o Reference: This contains a pointer to the public specification for the format of the item, if one exists. This Registry has been initially populated by the values in Section 8. The specification column for all of these entries will be this document. 11.4. Ace Groupcomm Request Type Registry This specification establishes the "ACE Groupcomm Request Type" IANA Registry. The Registry has been created to use the "Expert Review Required" registration procedure [RFC8126]. Expert review guidelines are provided in Section 11.9. The columns of this Registry are: Palombini & Tiloca Expires January 6, 2020 [Page 26] Internet-Draft Key Provisioning for Group Communication July 2019 o Name: This is a descriptive name that enables easier reference to the item. The name MUST be unique. It is not used in the encoding. o Value: This is the value used to identify the request. These values MUST be unique. The value must be a positive integer. o Reference: This contains a pointer to the public specification for the format of the item, if one exists. This Registry has been initially populated by the values in Section 9. The reference column for all of these entries will be this document. The value 0 is to be marked as "Reserved". 11.5. ACE Groupcomm Key Registry This specification establishes the "ACE Groupcomm Key" IANA Registry. The Registry has been created to use the "Expert Review Required" registration procedure [RFC8126]. Expert review guidelines are provided in Section 11.9. The columns of this Registry are: o Name: This is a descriptive name that enables easier reference to the item. The name MUST be unique. It is not used in the encoding. o Key Type Value: This is the value used to identify the keying material. These values MUST be unique. The value can be a positive integer, a negative integer, or a string. o Profile: This field may contain one or more descriptive strings of application profiles to be used with this item. The values should be taken from the Name column of the "ACE Groupcomm Profile" Registry. o Description: This field contains a brief description of the keying material. o References: This contains a pointer to the public specification for the format of the keying material, if one exists. This Registry has been initially populated by the values in Figure 5. The specification column for all of these entries will be this document. Palombini & Tiloca Expires January 6, 2020 [Page 27] Internet-Draft Key Provisioning for Group Communication July 2019 11.6. ACE Groupcomm Profile Registry This specification establishes the "ACE Groupcomm Profile" IANA Registry. The Registry has been created to use the "Expert Review Required" registration procedure [RFC8126]. Expert review guidelines are provided in Section 11.9. It should be noted that, in addition to the expert review, some portions of the Registry require a specification, potentially a Standards Track RFC, be supplied as well. The columns of this Registry are: o Name: The name of the application profile, to be used as value of the profile attribute. o Description: Text giving an overview of the application profile and the context it is developed for. o CBOR Value: CBOR abbreviation for the name of this application profile. Different ranges of values use different registration policies [RFC8126]. Integer values from -256 to 255 are designated as Standards Action. Integer values from -65536 to -257 and from 256 to 65535 are designated as Specification Required. Integer values greater than 65535 are designated as Expert Review. Integer values less than -65536 are marked as Private Use. o Reference: This contains a pointer to the public specification of the abbreviation for this application profile, if one exists. 11.7. ACE Groupcomm Policy Registry This specification establishes the "ACE Groupcomm Policy" IANA Registry. The Registry has been created to use the "Expert Review Required" registration procedure [RFC8126]. Expert review guidelines are provided in Section 11.9. It should be noted that, in addition to the expert review, some portions of the Registry require a specification, potentially a Standards Track RFC, be supplied as well. The columns of this Registry are: o Name: The name of the group communication policy. o CBOR label: The value to be used to identify this group communication policy. Key map labels MUST be unique. The label can be a positive integer, a negative integer or a string. Integer values between 0 and 255 and strings of length 1 are Palombini & Tiloca Expires January 6, 2020 [Page 28] Internet-Draft Key Provisioning for Group Communication July 2019 designated as Standards Track Document required. Integer values from 256 to 65535 and strings of length 2 are designated as Specification Required. Integer values of greater than 65535 and strings of length greater than 2 are designated as expert review. Integer values less than -65536 are marked as private use. o CBOR type: the CBOR type used to encode the value of this group communication policy. o Description: This field contains a brief description for this group communication policy. o Reference: This field contains a pointer to the public specification providing the format of the group communication policy, if one exists. This registry will be initially populated by the values in Figure 6. 11.8. Sequence Number Synchronization Method Registry This specification establishes the "Sequence Number Synchronization Method" IANA Registry. The Registry has been created to use the "Expert Review Required" registration procedure [RFC8126]. Expert review guidelines are provided in Section 11.9. It should be noted that, in addition to the expert review, some portions of the Registry require a specification, potentially a Standards Track RFC, be supplied as well. The columns of this Registry are: o Name: The name of the sequence number synchronization method. o Value: The value to be used to identify this sequence number synchronization method. o Description: This field contains a brief description for this sequence number synchronization method. o Reference: This field contains a pointer to the public specification describing the sequence number synchronization method. 11.9. Expert Review Instructions The IANA Registries established in this document are defined as expert review. This section gives some general guidelines for what the experts should be looking for, but they are being designated as experts for a reason so they should be given substantial latitude. Palombini & Tiloca Expires January 6, 2020 [Page 29] Internet-Draft Key Provisioning for Group Communication July 2019 Expert reviewers should take into consideration the following points: o Point squatting should be discouraged. Reviewers are encouraged to get sufficient information for registration requests to ensure that the usage is not going to duplicate one that is already registered and that the point is likely to be used in deployments. The zones tagged as private use are intended for testing purposes and closed environments, code points in other ranges should not be assigned for testing. o Specifications are required for the standards track range of point assignment. Specifications should exist for specification required ranges, but early assignment before a specification is available is considered to be permissible. Specifications are needed for the first-come, first-serve range if they are expected to be used outside of closed environments in an interoperable way. When specifications are not provided, the description provided needs to have sufficient information to identify what the point is being used for. o Experts should take into account the expected usage of fields when approving point assignment. The fact that there is a range for standards track documents does not mean that a standards track document cannot have points assigned outside of that range. The length of the encoded value should be weighed against how many code points of that length are left, the size of device it will be used on, and the number of code points left that encode to that size. 12. References 12.1. Normative References [I-D.ietf-ace-oauth-authz] Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and H. Tschofenig, "Authentication and Authorization for Constrained Environments (ACE) using the OAuth 2.0 Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-24 (work in progress), March 2019. [I-D.ietf-ace-oauth-params] Seitz, L., "Additional OAuth Parameters for Authorization in Constrained Environments (ACE)", draft-ietf-ace-oauth- params-05 (work in progress), March 2019. Palombini & Tiloca Expires January 6, 2020 [Page 30] Internet-Draft Key Provisioning for Group Communication July 2019 [I-D.ietf-core-oscore-groupcomm] Tiloca, M., Selander, G., Palombini, F., and J. Park, "Group OSCORE - Secure Group Communication for CoAP", draft-ietf-core-oscore-groupcomm-05 (work in progress), July 2019. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, October 2013, . [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", RFC 8152, DOI 10.17487/RFC8152, July 2017, . 12.2. Informative References [I-D.dijk-core-groupcomm-bis] Dijk, E., Wang, C., and M. Tiloca, "Group Communication for the Constrained Application Protocol (CoAP)", draft- dijk-core-groupcomm-bis-00 (work in progress), March 2019. [I-D.ietf-ace-dtls-authorize] Gerdes, S., Bergmann, O., Bormann, C., Selander, G., and L. Seitz, "Datagram Transport Layer Security (DTLS) Profile for Authentication and Authorization for Constrained Environments (ACE)", draft-ietf-ace-dtls- authorize-08 (work in progress), April 2019. [I-D.ietf-ace-mqtt-tls-profile] Sengul, C., Kirby, A., and P. Fremantle, "MQTT-TLS profile of ACE", draft-ietf-ace-mqtt-tls-profile-00 (work in progress), May 2019. [I-D.ietf-ace-oscore-profile] Palombini, F., Seitz, L., Selander, G., and M. Gunnarsson, "OSCORE profile of the Authentication and Authorization for Constrained Environments Framework", draft-ietf-ace- oscore-profile-07 (work in progress), February 2019. Palombini & Tiloca Expires January 6, 2020 [Page 31] Internet-Draft Key Provisioning for Group Communication July 2019 [I-D.ietf-core-coap-pubsub] Koster, M., Keranen, A., and J. Jimenez, "Publish- Subscribe Broker for the Constrained Application Protocol (CoAP)", draft-ietf-core-coap-pubsub-08 (work in progress), March 2019. [I-D.ietf-core-object-security] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, "Object Security for Constrained RESTful Environments (OSCORE)", draft-ietf-core-object-security-16 (work in progress), March 2019. [RFC2093] Harney, H. and C. Muckenhirn, "Group Key Management Protocol (GKMP) Specification", RFC 2093, DOI 10.17487/RFC2093, July 1997, . [RFC2094] Harney, H. and C. Muckenhirn, "Group Key Management Protocol (GKMP) Architecture", RFC 2094, DOI 10.17487/RFC2094, July 1997, . [RFC2627] Wallner, D., Harder, E., and R. Agee, "Key Management for Multicast: Issues and Architectures", RFC 2627, DOI 10.17487/RFC2627, June 1999, . [RFC7390] Rahman, A., Ed. and E. Dijk, Ed., "Group Communication for the Constrained Application Protocol (CoAP)", RFC 7390, DOI 10.17487/RFC7390, October 2014, . [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, . [RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in the Constrained Application Protocol (CoAP)", RFC 7959, DOI 10.17487/RFC7959, August 2016, . [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, . Palombini & Tiloca Expires January 6, 2020 [Page 32] Internet-Draft Key Provisioning for Group Communication July 2019 Appendix A. Requirements on Application Profiles This section lists the requirements on application profiles of this specification,for the convenience of application profile designers. o Specify the communication protocol the members of the group must use (e.g., multicast CoAP). o Specify the security protocol the group members must use to protect their communication (e.g., group OSCORE). This must provide encryption, integrity and replay protection. o Specify the encoding and value of the identifier of group or topic and role of 'scope' (see Section 3.1). o Specify and register the application profile identifier (see Section 4.1). o Specify the acceptable values of 'kty' (see Section 4.2). o Specify the format and content of 'group_policies' entries (see Section 4.2). o Optionally, specify the format and content of 'mgt_key_material' (see Section 4.2). o Optionally, specify tranport profile of ACE [I-D.ietf-ace-oauth-authz] to use between Client and KDC. o Optionally, specify the encoding of public keys, of 'client_cred', and of 'pub_keys' if COSE_Keys are not used (see Section 4.2). o Optionally, specify the acceptable values for parameters related to signature algorithm and signature keys: 'sign_alg', 'sign_parameters', 'sign_key_parameters', 'pub_key_enc' (see Section 3.3). o Optionally, specify the negotiation of parameter values for signature algorithm and signature keys, if 'sign_info' and 'pub_key_enc' are not used (see Section 3.3). Appendix B. Document Updates RFC EDITOR: PLEASE REMOVE THIS SECTION. Palombini & Tiloca Expires January 6, 2020 [Page 33] Internet-Draft Key Provisioning for Group Communication July 2019 B.1. Version -01 to -02 o Editorial fixes. o Distinction between transport profile and application profile (Section 1.1). o New parameters 'sign_info' and 'pub_key_enc' to negotiate parameter values for signature algorithm and signature keys (Section 3.3). o New parameter 'type' to distinguish different Key Distribution Request messages (Section 4.1). o New parameter 'client_cred_verify' in the Key Distribution Request to convey a Client signature (Section 4.1). o Encoding of 'pub_keys_repos' (Section 4.1). o Encoding of 'mgt_key_material' (Section 4.1). o Improved description on retrieval of new or updated keying material (Section 6). o Encoding of 'get_pub_keys' in Public Key Request (Section 7.1). o Extended security considerations (Sections 10.1 and 10.2). o New "ACE Public Key Encoding" IANA Registry (Section 11.2). o New "ACE Groupcomm Parameters" IANA Registry (Section 11.3), populated with the entries in Section 8. o New "Ace Groupcomm Request Type" IANA Registry (Section 11.4), populated with the values in Section 9. o New "ACE Groupcomm Policy" IANA Registry (Section 11.7) populated with two entries "Sequence Number Synchronization Method" and "Key Update Check Interval" (Section 4.2). o Improved list of requirements for application profiles (Appendix A). B.2. Version -00 to -01 o Changed name of 'req_aud' to 'audience' in the Authorization Request (Section 3.1). Palombini & Tiloca Expires January 6, 2020 [Page 34] Internet-Draft Key Provisioning for Group Communication July 2019 o Defined error handling on the KDC (Sections 4.2 and 6.2). o Updated format of the Key Distribution Response as a whole (Section 4.2). o Generalized format of 'pub_keys' in the Key Distribution Response (Section 4.2). o Defined format for the message to request leaving the group (Section 5.2). o Renewal of individual keying material and methods for group rekeying initiated by the KDC (Section 6). o CBOR type for node identifiers in 'get_pub_keys' (Section 7.1). o Added section on parameter identifiers and their CBOR keys (Section 8). o Added request types for requests to a Join Response (Section 9). o Extended security considerations (Section 10). o New IANA registries "ACE Groupcomm Key Registry", "ACE Groupcomm Profile Registry", "ACE Groupcomm Policy Registry" and "Sequence Number Synchronization Method Registry" (Section 11). o Added appendix about requirements for application profiles of ACE on group communication (Appendix A). Acknowledgments The following individuals were helpful in shaping this document: Ben Kaduk, John Mattsson, Jim Schaad, Ludwig Seitz, Goeran Selander and Peter van der Stok. The work on this document has been partly supported by VINNOVA and the Celtic-Next project CRITISEC; and by the EIT-Digital High Impact Initiative ACTIVE. Authors' Addresses Palombini & Tiloca Expires January 6, 2020 [Page 35] Internet-Draft Key Provisioning for Group Communication July 2019 Francesca Palombini Ericsson AB Torshamnsgatan 23 Kista SE-16440 Stockholm Sweden Email: francesca.palombini@ericsson.com Marco Tiloca RISE AB Isafjordsgatan 22 Kista SE-16440 Stockholm Sweden Email: marco.tiloca@ri.se Palombini & Tiloca Expires January 6, 2020 [Page 36] --000000000000c27be0058d42c726 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,=C2=A0

Please find some comments whi= le reading the document. I also have some high level questions that I might= have missed in the draft or that are defined somewhere else.=C2=A0

The group seems to be defined by its group members and ea= ch member are registered with read or write access. What is unclear to me i= s how these properties (read, write) affect the group communication. Are th= ere any specific cryptographic material or different access policies implem= ented by the RS for each role ?

I am not entirely = clear how the group communication is protected. In particular, I am wonderi= ng if the source is authenticated or if the key is shared between the diffe= rent members of the group. I am also wondering how the public key associate= d to each group member is used by another member.=C2=A0 =C2=A0


Please find some comments on the documents.=

Yours,=C2=A0
Daniel
=C2=A0=C2= =A0




ACE Working Group =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 F. Palombini
Internet-Draf= t =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 Ericsson AB
Intended status: Standards Track =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 M. Tiloca
Expires: January 6, 2020 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 RISE AB
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0July 05, 2019


= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Key Provisioning for Group Communi= cation using ACE
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 draft-ietf-ace-key-groupcomm-02

Abstract

=C2=A0 =C2= =A0This document defines message formats and procedures for requesting
= =C2=A0 =C2=A0and distributing group keying material using the ACE framework= , to
=C2=A0 =C2=A0protect communications between group members.

S= tatus of This Memo

=C2=A0 =C2=A0This Internet-Draft is submitted in = full conformance with the
=C2=A0 =C2=A0provisions of BCP 78 and BCP 79.<= br>
=C2=A0 =C2=A0Internet-Drafts are working documents of the Internet E= ngineering
=C2=A0 =C2=A0Task Force (IETF).=C2=A0 Note that other groups = may also distribute
=C2=A0 =C2=A0working documents as Internet-Drafts.= =C2=A0 The list of current Internet-
=C2=A0 =C2=A0Drafts is at https://datatracker.ietf.= org/drafts/current/.

=C2=A0 =C2=A0Internet-Drafts are draft docu= ments valid for a maximum of six months
=C2=A0 =C2=A0and may be updated,= replaced, or obsoleted by other documents at any
=C2=A0 =C2=A0time.=C2= =A0 It is inappropriate to use Internet-Drafts as reference
=C2=A0 =C2= =A0material or to cite them other than as "work in progress."
=
=C2=A0 =C2=A0This Internet-Draft will expire on January 6, 2020.
Copyright Notice

=C2=A0 =C2=A0Copyright (c) 2019 IETF Trust and the= persons identified as the
=C2=A0 =C2=A0document authors.=C2=A0 All righ= ts reserved.

=C2=A0 =C2=A0This document is subject to BCP 78 and the= IETF Trust's Legal
=C2=A0 =C2=A0Provisions Relating to IETF Documen= ts
=C2=A0 =C2=A0(https= ://trustee.ietf.org/license-info) in effect on the date of
=C2=A0 = =C2=A0publication of this document.=C2=A0 Please review these documents
= =C2=A0 =C2=A0carefully, as they describe your rights and restrictions with = respect
=C2=A0 =C2=A0to this document.=C2=A0 Code Components extracted f= rom this document must
=C2=A0 =C2=A0include Simplified BSD License text = as described in Section 4.e of
=C2=A0 =C2=A0the Trust Legal Provisions a= nd are provided without warranty as
=C2=A0 =C2=A0described in the Simpli= fied BSD License.




Palombini & Tiloca =C2=A0 =C2=A0 = =C2=A0 Expires January 6, 2020 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0[Page 1]
=0C
Internet-Draft =C2=A0Key Provisioning for G= roup Communication =C2=A0 =C2=A0 =C2=A0 July 2019


Table of Conte= nts

=C2=A0 =C2=A01.=C2=A0 Introduction =C2=A0. . . . . . . . . . . .= . . . . . . . . . . . . =C2=A0 3
=C2=A0 =C2=A0 =C2=A01.1.=C2=A0 Termino= logy . . . . . . . . . . . . . . . . . . . . . . . =C2=A0 3
=C2=A0 =C2= =A02.=C2=A0 Overview =C2=A0. . . . . . . . . . . . . . . . . . . . . . . . = . . =C2=A0 4
=C2=A0 =C2=A03.=C2=A0 Authorization to Join a Group . . . .= . . . . . . . . . . . . =C2=A0 6
=C2=A0 =C2=A0 =C2=A03.1.=C2=A0 Authori= zation Request . . . . . . . . . . . . . . . . . . =C2=A0 7
=C2=A0 =C2= =A0 =C2=A03.2.=C2=A0 Authorization Response =C2=A0. . . . . . . . . . . . .= . . . . =C2=A0 7
=C2=A0 =C2=A0 =C2=A03.3.=C2=A0 Token Post =C2=A0. . . = . . . . . . . . . . . . . . . . . . . . =C2=A0 8
=C2=A0 =C2=A04.=C2=A0 K= ey Distribution =C2=A0. . . . . . . . . . . . . . . . . . . . . . =C2=A011<= br>=C2=A0 =C2=A0 =C2=A04.1.=C2=A0 Key Distribution Request =C2=A0. . . . . = . . . . . . . . . . . =C2=A012
=C2=A0 =C2=A0 =C2=A04.2.=C2=A0 Key Distri= bution Response . . . . . . . . . . . . . . . . =C2=A013
=C2=A0 =C2=A05.= =C2=A0 Removal of a Node from the Group =C2=A0. . . . . . . . . . . . . . = =C2=A016
=C2=A0 =C2=A0 =C2=A05.1.=C2=A0 Expired Authorization . . . . . = . . . . . . . . . . . . . =C2=A016
=C2=A0 =C2=A0 =C2=A05.2.=C2=A0 Reques= t to Leave the Group =C2=A0. . . . . . . . . . . . . . . =C2=A016
=C2=A0= =C2=A06.=C2=A0 Retrieval of New or Updated Keying Material . . . . . . . .= . =C2=A017
=C2=A0 =C2=A0 =C2=A06.1.=C2=A0 Key Re-Distribution Request .= . . . . . . . . . . . . . . =C2=A018
=C2=A0 =C2=A0 =C2=A06.2.=C2=A0 Key= Re-Distribution Response =C2=A0. . . . . . . . . . . . . . =C2=A019
=C2= =A0 =C2=A07.=C2=A0 Retrieval of Public Keys for Group Members =C2=A0. . . .= . . . . . =C2=A019
=C2=A0 =C2=A0 =C2=A07.1.=C2=A0 Public Key Request = =C2=A0. . . . . . . . . . . . . . . . . . . =C2=A020
=C2=A0 =C2=A0 =C2= =A07.2.=C2=A0 Public Key Response . . . . . . . . . . . . . . . . . . . =C2= =A020
=C2=A0 =C2=A08.=C2=A0 ACE Groupcomm Parameters =C2=A0. . . . . . .= . . . . . . . . . . . =C2=A021
=C2=A0 =C2=A09.=C2=A0 ACE Groupcomm Requ= est Type =C2=A0. . . . . . . . . . . . . . . . . =C2=A022
=C2=A0 =C2=A01= 0. Security Considerations . . . . . . . . . . . . . . . . . . . =C2=A023=C2=A0 =C2=A0 =C2=A010.1.=C2=A0 Update of Keying Material =C2=A0. . . . .= . . . . . . . . . . =C2=A024
=C2=A0 =C2=A0 =C2=A010.2.=C2=A0 Block-Wise= Considerations =C2=A0. . . . . . . . . . . . . . . =C2=A024
=C2=A0 =C2= =A011. IANA Considerations . . . . . . . . . . . . . . . . . . . . . =C2=A0= 25
=C2=A0 =C2=A0 =C2=A011.1.=C2=A0 ACE Authorization Server Request Crea= tion Hints Registry =C2=A025
=C2=A0 =C2=A0 =C2=A011.2.=C2=A0 ACE Public = Key Encoding Registry . . . . . . . . . . . . =C2=A025
=C2=A0 =C2=A0 =C2= =A011.3.=C2=A0 ACE Groupcomm Parameters Registry =C2=A0. . . . . . . . . . = . =C2=A026
=C2=A0 =C2=A0 =C2=A011.4.=C2=A0 Ace Groupcomm Request Type Re= gistry =C2=A0. . . . . . . . . . =C2=A026
=C2=A0 =C2=A0 =C2=A011.5.=C2= =A0 ACE Groupcomm Key Registry . . . . . . . . . . . . . . . =C2=A027
= =C2=A0 =C2=A0 =C2=A011.6.=C2=A0 ACE Groupcomm Profile Registry . . . . . . = . . . . . . . =C2=A028
=C2=A0 =C2=A0 =C2=A011.7.=C2=A0 ACE Groupcomm Pol= icy Registry =C2=A0. . . . . . . . . . . . . =C2=A028
=C2=A0 =C2=A0 =C2= =A011.8.=C2=A0 Sequence Number Synchronization Method Registry =C2=A0. . . = . =C2=A029
=C2=A0 =C2=A0 =C2=A011.9.=C2=A0 Expert Review Instructions . = . . . . . . . . . . . . . . =C2=A029
=C2=A0 =C2=A012. References =C2=A0.= . . . . . . . . . . . . . . . . . . . . . . . . =C2=A030
=C2=A0 =C2=A0 = =C2=A012.1.=C2=A0 Normative References . . . . . . . . . . . . . . . . . . = =C2=A030
=C2=A0 =C2=A0 =C2=A012.2.=C2=A0 Informative References . . . . = . . . . . . . . . . . . . =C2=A031
=C2=A0 =C2=A0Appendix A.=C2=A0 Requir= ements on Application Profiles . . . . . . . . =C2=A033
=C2=A0 =C2=A0App= endix B.=C2=A0 Document Updates . . . . . . . . . . . . . . . . . . =C2=A03= 3
=C2=A0 =C2=A0 =C2=A0B.1.=C2=A0 Version -01 to -02 =C2=A0. . . . . . . = . . . . . . . . . . . . =C2=A034
=C2=A0 =C2=A0 =C2=A0B.2.=C2=A0 Version = -00 to -01 =C2=A0. . . . . . . . . . . . . . . . . . . =C2=A034
=C2=A0 = =C2=A0Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . =C2= =A035
=C2=A0 =C2=A0Authors' Addresses =C2=A0. . . . . . . . . . . . = . . . . . . . . . . . =C2=A035






Palombini & T= iloca =C2=A0 =C2=A0 =C2=A0 Expires January 6, 2020 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[Page 2]
=0C
Internet-Draft =C2=A0Key = Provisioning for Group Communication =C2=A0 =C2=A0 =C2=A0 July 2019

=
1.=C2=A0 Introduction

=C2=A0 =C2=A0This document expands the ACE= framework [I-D.ietf-ace-oauth-authz] to
=C2=A0 =C2=A0define the format = of messages used to request, distribute and renew
=C2=A0 =C2=A0the keyin= g material in a group communication scenario, e.g. based on
=C2=A0 =C2= =A0multicast [RFC7390][I-D.dijk-core-groupcomm-bis] or on publishing-
= =C2=A0 =C2=A0subscribing [I-D.ietf-core-coap-pubsub].
<mglt>
<= br>This is a nit which may be due to my english. My my reading of "e.g= .
based on " seems to be misleading here - at least to me. I am
= interpreting the text as 7390 and the two other drafts as examples that
= could take advantage of the current document. As these document do not
s= eem to consider multicast communication in general - 7390 seem slimited
= to one-to-many -, this gives, in my opinion a false impression that the
= scheme describe in this document is much more general.=C2=A0 While we do no= t
want to prevent other protocol to re-use the scheme defined here, Ibelieve it would be safer to restrict the current document to these
lat= est document as they provide the group communication framework we are
us= ing here. In these were only examples, I would expect the document to
pr= ovide a description how a more generic framework.

</mglt>
= =C2=A0 =C2=A0The ACE framework is based
=C2=A0 =C2=A0on CBOR [RFC7049], = so CBOR is the format used in this specification.
=C2=A0 =C2=A0However, = using JSON [RFC8259] instead of CBOR is possible, using the
=C2=A0 =C2= =A0conversion method specified in Sections 4.1 and 4.2 of [RFC7049].
<mglt>
This is a comment and there is probably a common understan= ding of the
text above I am missing. My reading is that CBOR and JSON ar= e supported,
meaning that I could send a JSON packet or a CBOR packet. U= nless this is
natively supported, it seems to indicate that two format a= re supported
and I woudl be inclined to say we shoudl maybe pick one of = them for
inter-operability. In this case CBOR might be appropriated.
I am reading that the support for JSON is easily adapted from the
c= urrent documentation, but not so much recommended.
</mglt>
=C2=A0 =C2=A0Profiles that use group communication can build on this docum= ent to
=C2=A0 =C2=A0specify the selection of the message parameters defi= ned in this
=C2=A0 =C2=A0document to use and their values.=C2=A0 Known a= pplications that can
=C2=A0 =C2=A0benefit from this document would be, f= or example, those addressing
=C2=A0 =C2=A0group communication based on m= ulticast
=C2=A0 =C2=A0[RFC7390][I-D.dijk-core-groupcomm-bis] or publishi= ng/subscribing
=C2=A0 =C2=A0[I-D.ietf-core-coap-pubsub] in ACE.

&= lt;mglt>
I would suggest to limit the document to these documents, es= pecially if
we do not envision any other cases while writing this docume= nt.

I believe it woudl be also important to remind some characteris= tics of
these groups. Typically it seems these groups envisioned one-to-= many
communication and are not highly dynamic. I believe it woudl be hel= pful
to have the limitations or characteristics of these groups, so futu= re
application could easily see if the key management propose fits their=
requirements.
</mglt>

=C2=A0 =C2=A0If the application = requires backward and forward security, updated
=C2=A0 =C2=A0keying mate= rial is generated and distributed to the group members
=C2=A0 =C2=A0(rek= eying), when membership changes.=C2=A0 A key management scheme
=C2=A0 = =C2=A0performs the actual distribution of the updated keying material to=C2=A0 =C2=A0the group.=C2=A0 In particular, the key management scheme rek= eys the
=C2=A0 =C2=A0current group members when a new node joins the gro= up, and the
=C2=A0 =C2=A0remaining group members when a node leaves the = group.=C2=A0 This document
=C2=A0 =C2=A0provides a message format for gr= oup rekeying that allows to fulfill
=C2=A0 =C2=A0these requirements.=C2= =A0 Rekeying mechanisms can be based on [RFC2093],
=C2=A0 =C2=A0[RFC2094= ] and [RFC2627].

<mglt>
The latest paragraph provides a hig= h level view of how the protocol
works. This is very helpful, but maybe = additional text - or a dedicated
use case section may be needed to provi= de the full life cycle of the
keys. Typically, I am wondering one a grou= p keys are managed at the
initialization of the group. My interpretation= of the text is that if I
have 1000 battery power motes in my home and e= ach of them join the group
one by one, I will have 1000 key updates. I b= elieve it would be good to
clarify this. =C2=A0 =C2=A0


</m= glt>

1.1.=C2=A0 Terminology

=C2=A0 =C2=A0The key words &qu= ot;MUST", "MUST NOT", "REQUIRED", "SHALL"= ;, "SHALL NOT",
=C2=A0 =C2=A0"SHOULD", "SHOULD = NOT", "RECOMMENDED", "MAY", and "OPTIONAL&quo= t; in this
=C2=A0 =C2=A0document are to be interpreted as described in [= RFC2119].=C2=A0 These
=C2=A0 =C2=A0words may also appear in this documen= t in lowercase, absent their
=C2=A0 =C2=A0normative meanings.

=C2= =A0 =C2=A0Readers are expected to be familiar with the terms and concepts=C2=A0 =C2=A0described in [I-D.ietf-ace-oauth-authz] and [RFC8152], such = as
=C2=A0 =C2=A0Authorization Server (AS) and Resource Server (RS).
<= br>=C2=A0 =C2=A0This document additionally uses the following terminology:<= br>
=C2=A0 =C2=A0o =C2=A0Transport profile, to indicate a profile of ACE= as per
=C2=A0 =C2=A0 =C2=A0 Section 5.6.4.3 of [I-D.ietf-ace-oauth-auth= z].=C2=A0 That is, a
=C2=A0 =C2=A0 =C2=A0 transport profile specifies th= e communication protocol and
=C2=A0 =C2=A0 =C2=A0 communication security= protocol between an ACE Client and Resource



Palombini &= Tiloca =C2=A0 =C2=A0 =C2=A0 Expires January 6, 2020 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[Page 3]
=0C
Internet-Draft =C2=A0K= ey Provisioning for Group Communication =C2=A0 =C2=A0 =C2=A0 July 2019
<= br>
=C2=A0 =C2=A0 =C2=A0 Server, as well as proof-of-possession methods,= if it supports
=C2=A0 =C2=A0 =C2=A0 proof-of-possession access tokens.= =C2=A0 Tranport profiles of ACE
=C2=A0 =C2=A0 =C2=A0 include, for instan= ce, [I-D.ietf-ace-oscore-profile],
=C2=A0 =C2=A0 =C2=A0 [I-D.ietf-ace-dt= ls-authorize] and [I-D.ietf-ace-mqtt-tls-profile].

=C2=A0 =C2=A0o = =C2=A0Application profile, to indicate a profile of ACE that defines how=C2=A0 =C2=A0 =C2=A0 applications enforce and use supporting security serv= ices they
=C2=A0 =C2=A0 =C2=A0 require.=C2=A0 These services include, fo= r instance, provisioning,
=C2=A0 =C2=A0 =C2=A0 revocation and (re-)distr= ibution of keying material.=C2=A0 An
=C2=A0 =C2=A0 =C2=A0 application pr= ofile may define specific procedures and message
=C2=A0 =C2=A0 =C2=A0 fo= rmats.

2.=C2=A0 Overview

=C2=A0 =C2=A0 =C2=A0 =C2=A0+--------= ----+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+------= -----+
=C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 AS =C2=A0 =C2=A0 | =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0K= DC =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0.-------->| =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0+------------+ =C2=A0 = =C2=A0 =C2=A0 / =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+-----------+
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0^ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 /
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0v =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 / =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +----= -------+
=C2=A0 =C2=A0 =C2=A0 =C2=A0+------------+ =C2=A0 / =C2=A0 =C2= =A0 =C2=A0+------------+ =C2=A0 =C2=A0 =C2=A0 =C2=A0|+-----------+
=C2= =A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 Client =C2=A0 |<-' =C2=A0 =C2=A0 = =C2=A0 | Dispatcher | =C2=A0 =C2=A0 =C2=A0 =C2=A0||+-----------+
=C2=A0 = =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<-------= ->| =C2=A0 =C2=A0(RS) =C2=A0 =C2=A0|<------->|| =C2=A0 Group =C2= =A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0+------------+ =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0+------------+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 +| =C2=A0members =C2= =A0|
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+-----------+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Figure 1: K= ey Distribution Participants

=C2=A0 =C2=A0The following participants= (see Figure 1) take part in the
=C2=A0 =C2=A0authorization and key dist= ribution.

=C2=A0 =C2=A0o =C2=A0Client (C): node that wants to join t= he group communication.=C2=A0 It
=C2=A0 =C2=A0 =C2=A0 can request write = and/or read rights.
<mglt>
I am wondering if one can have write= access without having read access.
It seems to me - but I might be wron= g - that write access provides read
access. If that is correct, I am won= dering if we could have read or
write.

The figure seems to give t= wo roles of the Client: 1) the ability to join
the group with some inter= actions with KDC as well as 2) the ability to
send message with some int= eractions with the Dispatcher. I am wondering
if there are any reasons t= he latest is not mentioned.
</mglt>

=C2=A0 =C2=A0o =C2=A0A= uthorization Server (AS): same as AS in the ACE Framework; it
=C2=A0 =C2= =A0 =C2=A0 enforces access policies, and knows if a node is allowed to join=
=C2=A0 =C2=A0 =C2=A0 the group with write and/or read rights.

= =C2=A0 =C2=A0o =C2=A0Key Distribution Center (KDC): maintains the keying ma= terial to
=C2=A0 =C2=A0 =C2=A0 protect group communications, and provide= s it to Clients
=C2=A0 =C2=A0 =C2=A0 authorized to join the group.=C2=A0= During the first part of the
=C2=A0 =C2=A0 =C2=A0 exchange (Section 3),= it takes the role of the RS in the ACE
=C2=A0 =C2=A0 =C2=A0 Framework.= =C2=A0 During the second part (Section 4), which is not based
=C2=A0 =C2= =A0 =C2=A0 on the ACE Framework, it distributes the keying material.=C2=A0 = In
=C2=A0 =C2=A0 =C2=A0 addition, it provides the latest keying material= to group members
=C2=A0 =C2=A0 =C2=A0 when requested.=C2=A0 If required= by the application, the KDC renews




Palombini & Tilo= ca =C2=A0 =C2=A0 =C2=A0 Expires January 6, 2020 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0[Page 4]
=0C
Internet-Draft =C2=A0Key Pro= visioning for Group Communication =C2=A0 =C2=A0 =C2=A0 July 2019

=C2=A0 =C2=A0 =C2=A0 and re-distributes the keying material in the group w= hen
=C2=A0 =C2=A0 =C2=A0 membership changes.

=C2=A0 =C2=A0o =C2= =A0Dispatcher: entity through which the Clients communicate with the
=C2= =A0 =C2=A0 =C2=A0 group and which distributes messages to the group members= .
=C2=A0 =C2=A0 =C2=A0 Examples of dispatchers are: the Broker node in a= pub-sub setting;
=C2=A0 =C2=A0 =C2=A0 a relayer node for group communic= ation that delivers group
=C2=A0 =C2=A0 =C2=A0 messages as multiple unic= ast messages to all group members; an
=C2=A0 =C2=A0 =C2=A0 implicit enti= ty as in a multicast communication setting, where
=C2=A0 =C2=A0 =C2=A0 m= essages are transmitted to a multicast IP address and delivered
=C2=A0 = =C2=A0 =C2=A0 on the transport channel.

=C2=A0 =C2=A0This document s= pecifies the message flows and formats for:

=C2=A0 =C2=A0o =C2=A0Aut= horizing a new node to join the group (Section 3), and
=C2=A0 =C2=A0 =C2= =A0 providing it with the group keying material to communicate with
=C2= =A0 =C2=A0 =C2=A0 the other group members (Section 4).

=C2=A0 =C2=A0= o =C2=A0Removing of a current member from the group (Section 5).

=C2= =A0 =C2=A0o =C2=A0Retrieving keying material as a current group member (Sec= tion 6
=C2=A0 =C2=A0 =C2=A0 and Section 7).

=C2=A0 =C2=A0o =C2=A0= Renewing and re-distributing the group keying material (rekeying)
=C2=A0= =C2=A0 =C2=A0 upon a membership change in the group (Section 4.2 and Secti= on 5).

=C2=A0 =C2=A0Figure 2 provides a high level overview of the m= essage flow for a
=C2=A0 =C2=A0node joining a group communication settin= g.

=C2=A0 C =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0AS =C2=A0 =C2=A0 KDC =C2=A0= Dispatcher =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Group
=C2=A0 | =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0| = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Member
=C2=A0 | =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2= =A0| \ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 | =C2= =A0 =C2=A0 Authorization Request =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 | =C2= =A0 =C2=A0 =C2=A0 =C2=A0| | Defined =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |-----= ------------------------>| =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 = =C2=A0| | in the ACE =C2=A0 =C2=A0|
=C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0| =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0| | framework =C2=A0= =C2=A0 |
=C2=A0 | =C2=A0 =C2=A0 Authorization Response =C2=A0 | =C2=A0 = =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0| | =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |<-----------------------------| =C2=A0= =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0| | =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 = =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0| | =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |--------- Token Post ---------------->= | =C2=A0 =C2=A0 =C2=A0 =C2=A0| / =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 |
=C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 |
=C2=A0 |---- Key Distribution Request ------->| = =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 |
=C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |<--- Key Distribution Response ------= | --- Group Rekeying ----->|
=C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |<=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Protected communication =3D=3D=3D|= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>|
=C2=A0 | =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |

= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Figure 2: Message Flow Upo= n New Node's Joining
<mglt>
"Defined in the ACE framew= ork" : it is unclear to me if it designates
the DIspatcher of the A= uthorization and Token Post exchanges. I think
that is the latest.
I understand the Dispatcher is not involved in the distribution of thekeying material, but only to the distribution of the messages. If that
= is correct, it does not appear clearly on the figure, maybe placing
Disp= atcher and Group Members below the Group Keying arrow would clarify
this= .

I think Protected communication is not in the scope of this draft= , so it
might specified as well as it is being done for the ACE framewor= k - if
that is correct.

Protected communication is usually inter= preted as end-to-end security
and this may not be achieved with group co= mmunication. Maybe secure
group communication might be more appropriated= .
</mglt>


Palombini & Tiloca =C2=A0 =C2=A0 =C2=A0 = Expires January 6, 2020 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0[Page 5]
=0C
Internet-Draft =C2=A0Key Provisioning for Group Co= mmunication =C2=A0 =C2=A0 =C2=A0 July 2019


=C2=A0 =C2=A0The exch= ange of Authorization Request and Authorization Response
=C2=A0 =C2=A0be= tween Client and AS MUST be secured, as specified by the transport
=C2= =A0 =C2=A0profile of ACE used between Client and KDC.

=C2=A0 =C2=A0T= he exchange of Key Distribution Request and Key Distribution
=C2=A0 =C2= =A0Response between Client and KDC MUST be secured, as a result of the
= =C2=A0 =C2=A0transport profile of ACE used between Client and KDC.

= =C2=A0 =C2=A0All further communications between the Client and the KDC MUST= be
=C2=A0 =C2=A0secured, for instance with the same security mechanism = used for the
=C2=A0 =C2=A0Key Distribution exchange.

=C2=A0 =C2= =A0All communications between a Client and the other group members MUST
= =C2=A0 =C2=A0be secured using the keying material provided in Section 4.
3.=C2=A0 Authorization to Join a Group

=C2=A0 =C2=A0This sectio= n describes in detail the format of messages exchanged by
=C2=A0 =C2=A0t= he participants when a node requests access to a group.=C2=A0 The first
= =C2=A0 =C2=A0part of the exchange is based on ACE [I-D.ietf-ace-oauth-authz= ].

=C2=A0 =C2=A0As defined in [I-D.ietf-ace-oauth-authz], the Client= requests from
=C2=A0 =C2=A0the AS an authorization to join the group th= rough the KDC (see
=C2=A0 =C2=A0Section 3.1).=C2=A0 If the request is ap= proved and authorization is
=C2=A0 =C2=A0granted, the AS provides the Cl= ient with a proof-of-possession access
=C2=A0 =C2=A0token and parameters= to securely communicate with the KDC (see
=C2=A0 =C2=A0Section 3.2).=C2= =A0 Communications between the Client and the AS MUST be
=C2=A0 =C2=A0se= cured, according to the transport profile of ACE used.=C2=A0 The
=C2=A0 = =C2=A0Content-Format used in the messages is the one specified by the used<= br>=C2=A0 =C2=A0transport profile of ACE (e.g. application/ace+cbor for the= first two
=C2=A0 =C2=A0messages and application/cwt for the third messa= ge, depending on the
=C2=A0 =C2=A0format of the access token).

= =C2=A0 =C2=A0Figure 3 gives an overview of the exchange described above.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Client =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0AS =C2=A0KDC
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 |
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |---- Authorization Request: POST /token --= ---->| =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 | =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |<--- Aut= horization Response: 2.01 (Created) ---| =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 |----- POST Token: POST /authz-info --------------->|<= br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Figure 3: Me= ssage Flow of Join Authorization






Palombini &= Tiloca =C2=A0 =C2=A0 =C2=A0 Expires January 6, 2020 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[Page 6]
=0C
Internet-Draft =C2=A0K= ey Provisioning for Group Communication =C2=A0 =C2=A0 =C2=A0 July 2019
<= br>
3.1.=C2=A0 Authorization Request

=C2=A0 =C2=A0The Authorizati= on Request sent from the Client to the AS is as
=C2=A0 =C2=A0defined in = Section 5.6.1 of [I-D.ietf-ace-oauth-authz] and MUST
=C2=A0 =C2=A0contai= n the following parameters:

=C2=A0 =C2=A0o =C2=A0'grant_type'= ;, with value "client_credentials".

=C2=A0 =C2=A0Additiona= lly, the Authorization Request MAY contain the following
=C2=A0 =C2=A0pa= rameters, which, if included, MUST have the corresponding values:

&l= t;mglt>
I believe the value is understood as the value in a dictionar= y (key,
value) - rather then the value of the value itself.

I su= ggest to provide explicitly how the AS behaves if the value format
is no= t recognized or if the provided value is unknown to the AS. More
specifi= cally, is the parameter ignored or the exchange aborted.
</mglt><= br>
=C2=A0 =C2=A0o =C2=A0'scope', containing the identifier of t= he specific group (or topic
=C2=A0 =C2=A0 =C2=A0 in the case of pub-sub)= that the Client wishes to access, and
=C2=A0 =C2=A0 =C2=A0 optionally t= he role(s) that the Client wishes to take.=C2=A0 This value
=C2=A0 =C2= =A0 =C2=A0 is a CBOR array encoded as a byte string, which contains:
=C2=A0 =C2=A0 =C2=A0 * =C2=A0As first element, the identifier of the speci= fic group or
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0topic.

=C2=A0 =C2= =A0 =C2=A0 * =C2=A0Optionally, as second element, the role (or CBOR array o= f
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0roles) the Client wishes to take in = the group.

=C2=A0 =C2=A0 =C2=A0 The encoding of the group or topic i= dentifier and of the role
=C2=A0 =C2=A0 =C2=A0 identifiers is applicatio= n specific.

=C2=A0 =C2=A0o =C2=A0'audience', with an identif= ier of a KDC.

=C2=A0 =C2=A0o =C2=A0'req_cnf', as defined in = Section 3.1 of
=C2=A0 =C2=A0 =C2=A0 [I-D.ietf-ace-oauth-params], optiona= lly containing the public key
=C2=A0 =C2=A0 =C2=A0 or a reference to the= public key of the Client, if it wishes to
=C2=A0 =C2=A0 =C2=A0 communic= ate that to the AS.

=C2=A0 =C2=A0o =C2=A0Other additional parameters= as defined in
=C2=A0 =C2=A0 =C2=A0 [I-D.ietf-ace-oauth-authz], if neces= sary.

3.2.=C2=A0 Authorization Response

=C2=A0 =C2=A0The Auth= orization Response sent from the AS to the Client is as
=C2=A0 =C2=A0def= ined in Section 5.6.2 of [I-D.ietf-ace-oauth-authz] and MUST
=C2=A0 =C2= =A0contain the following parameters:

=C2=A0 =C2=A0o =C2=A0'acces= s_token', containing the proof-of-possession access token.

=C2= =A0 =C2=A0o =C2=A0'cnf' if symmetric keys are used, not present if = asymmetric keys
=C2=A0 =C2=A0 =C2=A0 are used.=C2=A0 This parameter is d= efined in Section 3.2 of
=C2=A0 =C2=A0 =C2=A0 [I-D.ietf-ace-oauth-params= ] and contains the symmetric proof-of-
=C2=A0 =C2=A0 =C2=A0 possession k= ey that the Client is supposed to use with the KDC.




Palo= mbini & Tiloca =C2=A0 =C2=A0 =C2=A0 Expires January 6, 2020 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[Page 7]
=0C
Internet-Dr= aft =C2=A0Key Provisioning for Group Communication =C2=A0 =C2=A0 =C2=A0 Jul= y 2019


=C2=A0 =C2=A0o =C2=A0'rs_cnf' if asymmetric keys = are used, not present if symmetric
=C2=A0 =C2=A0 =C2=A0 keys are used.= =C2=A0 This parameter is as defined in Section 3.2 of
=C2=A0 =C2=A0 =C2= =A0 [I-D.ietf-ace-oauth-params] and contains information about the
=C2= =A0 =C2=A0 =C2=A0 public key of the KDC.

=C2=A0 =C2=A0o =C2=A0'e= xp', contains the lifetime in seconds of the access token.=C2=A0 This=C2=A0 =C2=A0 =C2=A0 parameter MAY be omitted if the application defines = how the
=C2=A0 =C2=A0 =C2=A0 expiration time is communicated to the Clie= nt via other means, or
=C2=A0 =C2=A0 =C2=A0 if it establishes a default = value.

=C2=A0 =C2=A0Additionally, the Authorization Response MAY con= tain the following
=C2=A0 =C2=A0parameters, which, if included, MUST hav= e the corresponding values:

<mglt>
Same comment as above re= garding the MUST statement.
</mglt>

=C2=A0 =C2=A0o =C2=A0&#= 39;scope', which mirrors the 'scope' parameter in the Authoriza= tion
=C2=A0 =C2=A0 =C2=A0 Request (see Section 3.1).=C2=A0 Its value is = a CBOR array encoded as a
=C2=A0 =C2=A0 =C2=A0 byte string, containing:<= br>
=C2=A0 =C2=A0 =C2=A0 * =C2=A0As first element, the identifier of the= specific group or topic
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the Client is= authorized to access.

=C2=A0 =C2=A0 =C2=A0 * =C2=A0Optionally, as s= econd element, the role (or CBOR array of
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0roles) the Client is authorized to take in the group.

=C2=A0 = =C2=A0 =C2=A0 The encoding of the group or topic identifier and of the role=
=C2=A0 =C2=A0 =C2=A0 identifiers is application specific.

=C2=A0= =C2=A0o =C2=A0Other additional parameters as defined in
=C2=A0 =C2=A0 = =C2=A0 [I-D.ietf-ace-oauth-authz], if necessary.

=C2=A0 =C2=A0The ac= cess token MUST contain all the parameters defined above
=C2=A0 =C2=A0(i= ncluding the same 'scope' as in this message, if present, or the=C2=A0 =C2=A0'scope' of the Authorization Request otherwise), and = additionally
=C2=A0 =C2=A0other optional parameters that the transport p= rofile of ACE requires.

=C2=A0 =C2=A0When receiving an Authorization= Request from a Client that was
=C2=A0 =C2=A0previously authorized, and = which still owns a valid non expired
=C2=A0 =C2=A0access token, the AS r= eplies with an Authorization Response with a
=C2=A0 =C2=A0new access tok= en.

3.3.=C2=A0 Token Post

=C2=A0 =C2=A0The Client sends a CoA= P POST request including the access token to
=C2=A0 =C2=A0the KDC, as sp= ecified in Section 5.8.1 of [I-D.ietf-ace-oauth-authz].
=C2=A0 =C2=A0If = the specific transport profile of ACE defines it, the Client MAY
=C2=A0 = =C2=A0use a different endpoint than /authz-info at the KDC to post the
= =C2=A0 =C2=A0access token to.





Palombini & Tiloca= =C2=A0 =C2=A0 =C2=A0 Expires January 6, 2020 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0[Page 8]
=0C
Internet-Draft =C2=A0Key Prov= isioning for Group Communication =C2=A0 =C2=A0 =C2=A0 July 2019


= =C2=A0 =C2=A0Optionally, the Client might need to request necessary informa= tion
=C2=A0 =C2=A0concerning the public keys in the group, as well as co= ncerning the
=C2=A0 =C2=A0algorithm and related parameters for computing= signatures in the
=C2=A0 =C2=A0group.=C2=A0 In such a case, the joining= node MAY ask for that information
=C2=A0 =C2=A0to the KDC in this same = request.=C2=A0 To this end, it sends the CoAP POST
=C2=A0 =C2=A0request = to the /authz-info endpoint using the Content-Format
=C2=A0 =C2=A0"= application/ace+cbor" defined in Section 8.14 of
=C2=A0 =C2=A0[I-D.= ietf-ace-oauth-authz], and includes also the following
=C2=A0 =C2=A0para= meters:

<mglt>
That the Client MAY ask for this information= suggests that this is not
necessary. It would maybe worth indicating wh= en these information are not
requested. I see two cases 1) when public k= ey is not involved, and 2)
when this is pre-configured or provided by ot= her means.

I am not sure these cases make senses, but in the latest= cases, it would
be good to specify why we do not end up in a dead lock.=

Public key is associated with authentication. I understand that the=
authentication is necessary to the RS rather than the group members. If=
that is correct, I believe that specifying the entity associated to the=
public key - here the RS - would be clearer.

</mglt>
<= br>=C2=A0 =C2=A0o =C2=A0'sign_info' defined in Section 3.3.1, encod= ing the CBOR simple
=C2=A0 =C2=A0 =C2=A0 value Null, to require informat= ion and parameters on the signature
=C2=A0 =C2=A0 =C2=A0 algorithm and o= n the public keys used in the group.

=C2=A0 =C2=A0o =C2=A0'pub_k= ey_enc' defined in Section 3.3.2, encoding the CBOR simple
=C2=A0 = =C2=A0 =C2=A0 value Null, to require information on the exact encoding of p= ublic
=C2=A0 =C2=A0 =C2=A0 keys used in the group.

=C2=A0 =C2=A0T= he CDDL notation of the 'sign_info' and 'pub_key_enc' param= eters
=C2=A0 =C2=A0formatted as in the request is given below.

= =C2=A0 =C2=A0 =C2=A0 sign_info_req =3D nil

=C2=A0 =C2=A0 =C2=A0 pub_= key_enc_req =3D nil

=C2=A0 =C2=A0Alternatively, the joining node may= retrieve this information by
=C2=A0 =C2=A0other means.

=C2=A0 = =C2=A0After successful verification, the Client is authorized to receive=C2=A0 =C2=A0the group keying material from the KDC and join the group.=C2= =A0 In
=C2=A0 =C2=A0particular, the KDC replies to the Client with a 2.0= 1 (Created)
=C2=A0 =C2=A0response, using Content-Format "applicatio= n/ace+cbor" defined in
=C2=A0 =C2=A0Section 8.14 of [I-D.ietf-ace-o= auth-authz].

=C2=A0 =C2=A0The payload of the 2.01 response is a CBOR= map, which MUST include a
=C2=A0 =C2=A0nonce N generated by the KDC.=C2= =A0 The Client may use this nonce for
=C2=A0 =C2=A0proving the possessio= n of its own private key (see the
=C2=A0 =C2=A0'client_cred_verify&#= 39; parameter in Section 4).

=C2=A0 =C2=A0Optionally, if they were i= ncluded in the request, the AS MAY include
=C2=A0 =C2=A0the 'sign_in= fo' parameter as well as the 'pub_key_enc' parameter
=C2=A0 = =C2=A0defined in Section 3.3.1 and Section 3.3.2 of this specification,
= =C2=A0 =C2=A0respectively.

=C2=A0 =C2=A0The 'sign_info' para= meter MUST be present if the POST request
=C2=A0 =C2=A0included the '= ;sign_info' parameter with value Null.=C2=A0 If present, the
=C2=A0 = =C2=A0'sign_info' parameter of the 2.01 (Created) response is a CBO= R array
=C2=A0 =C2=A0formatted as follows.



Palombini &= ; Tiloca =C2=A0 =C2=A0 =C2=A0 Expires January 6, 2020 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[Page 9]
=0C
Internet-Draft =C2=A0K= ey Provisioning for Group Communication =C2=A0 =C2=A0 =C2=A0 July 2019
<= br>
=C2=A0 =C2=A0o =C2=A0The first element 'sign_alg' is an inte= ger or a text string,
=C2=A0 =C2=A0 =C2=A0 indicating the signature algo= rithm used in the group.=C2=A0 It is
=C2=A0 =C2=A0 =C2=A0 required of th= e application profiles to define specific values for
=C2=A0 =C2=A0 =C2= =A0 this parameter.

=C2=A0 =C2=A0o =C2=A0The second element 'sig= n_parameters' indicates the parameters of
=C2=A0 =C2=A0 =C2=A0 the s= ignature algorithm.=C2=A0 Its structure depends on the value of
=C2=A0 = =C2=A0 =C2=A0 'sign_alg'.=C2=A0 It is required of the application p= rofiles to define
=C2=A0 =C2=A0 =C2=A0 specific values for this paramete= r.=C2=A0 If no parameters of the
=C2=A0 =C2=A0 =C2=A0 signature algorith= m are specified, 'sign_parameters' MUST be
=C2=A0 =C2=A0 =C2=A0 = encoding the CBOR simple value Null.

=C2=A0 =C2=A0o =C2=A0The third = element 'sign_key_parameters' indicates the parameters
=C2=A0 = =C2=A0 =C2=A0 of the key used with the signature algorithm.=C2=A0 Its struc= ture
=C2=A0 =C2=A0 =C2=A0 depends on the value of 'sign_alg'.=C2= =A0 It is required of the
=C2=A0 =C2=A0 =C2=A0 application profiles to d= efine specific values for this parameter.
=C2=A0 =C2=A0 =C2=A0 If no par= ameters of the key used with the signature algorithm are
=C2=A0 =C2=A0 = =C2=A0 specified, 'sign_key_parameters' MUST be encoding the CBOR s= imple
=C2=A0 =C2=A0 =C2=A0 value Null.

=C2=A0 =C2=A0The 'pub_= key_enc' parameter MUST be present if the POST request
=C2=A0 =C2=A0= included the 'pub_key_enc' parameter with value Null.=C2=A0 If pres= ent,
=C2=A0 =C2=A0the 'pub_key_enc' parameter of the 2.01 (Creat= ed) response is a CBOR
=C2=A0 =C2=A0integer, indicating the encoding of = public keys used in the group.
=C2=A0 =C2=A0The values of this field are= registered in the "ACE Public Key
=C2=A0 =C2=A0Encoding" Regi= stry, defined in Section 11.2.=C2=A0 It is required of the
=C2=A0 =C2=A0= application profiles to define specific values to use for this
=C2=A0 = =C2=A0parameter.

=C2=A0 =C2=A0The CDDL notation of the 'sign_inf= o' and 'pub_key_enc' parameters
=C2=A0 =C2=A0formatted as in= the response is given below.

=C2=A0 =C2=A0 =C2=A0 sign_info_res =3D= [
=C2=A0 =C2=A0 =C2=A0 =C2=A0 sign_alg : int / tstr,
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 sign_parameters : any / nil,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 s= ign_key_parameters : any / nil
=C2=A0 =C2=A0 =C2=A0 ]

=C2=A0 =C2= =A0 =C2=A0 pub_key_enc_res =3D int

=C2=A0 =C2=A0Note that the CBOR m= ap specified as payload of the 2.01 (Created)
=C2=A0 =C2=A0response may = include further parameters, e.g. according to the
=C2=A0 =C2=A0signalled= transport profile of ACE.

=C2=A0 =C2=A0Note that this step could be= merged with the following message from
=C2=A0 =C2=A0the Client to the K= DC, namely Key Distribution Request.





Palombini &= Tiloca =C2=A0 =C2=A0 =C2=A0 Expires January 6, 2020 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 10]
=0C
Internet-Draft =C2=A0Key Pr= ovisioning for Group Communication =C2=A0 =C2=A0 =C2=A0 July 2019

3.3.1. =C2=A0'sign_info' Parameter

=C2=A0 =C2=A0The 's= ign_info' parameter is an OPTIONAL parameter of the AS Request
=C2= =A0 =C2=A0Creation Hints message defined in Section 5.1.2. of
=C2=A0 =C2= =A0[I-D.ietf-ace-oauth-authz].=C2=A0 This parameter contains information an= d
=C2=A0 =C2=A0parameters about the signature algorithm and the public k= eys to be
=C2=A0 =C2=A0used between the Client and the RS.=C2=A0 Its exa= ct content is application
=C2=A0 =C2=A0specific.

3.3.2. =C2=A0= 9;pub_key_enc' Parameter

=C2=A0 =C2=A0The 'pub_key_enc' = parameter is an OPTIONAL parameter of the AS
=C2=A0 =C2=A0Request Creati= on Hints message defined in Section 5.1.2. of
=C2=A0 =C2=A0[I-D.ietf-ace= -oauth-authz].=C2=A0 This parameter contains information
=C2=A0 =C2=A0ab= out the exact encoding of public keys to be used between the Client
=C2= =A0 =C2=A0and the RS.=C2=A0 Its exact content is application specific.
<= br>4.=C2=A0 Key Distribution

=C2=A0 =C2=A0This section defines how t= he keying material used for group
=C2=A0 =C2=A0communication is distribu= ted from the KDC to the Client, when joining
=C2=A0 =C2=A0the group as a= new member.

=C2=A0 =C2=A0If not previously established, the Client = and the KDC MUST first
=C2=A0 =C2=A0establish a pairwise secure communic= ation channel using ACE.

<mglt>
I have the impression that= such agreement is performed during the
registration request / resopnse = with the AS. Is that correct or are we
considering another exchange ? </mglt>

The
=C2=A0 =C2=A0exchange of Key Distribution Req= uest-Response MUST occur over that
=C2=A0 =C2=A0secure channel.=C2=A0 Th= e Client and the KDC MAY use that same secure
=C2=A0 =C2=A0channel to pr= otect further pairwise communications, that MUST be
=C2=A0 =C2=A0secured= .

=C2=A0 =C2=A0During this exchange, the Client sends a request to t= he AS,
=C2=A0 =C2=A0specifying the group it wishes to join (see Section = 4.1).=C2=A0 Then, the
=C2=A0 =C2=A0KDC verifies the access token and tha= t the Client is authorized to
=C2=A0 =C2=A0join that group; if so, it pr= ovides the Client with the keying
=C2=A0 =C2=A0material to securely comm= unicate with the member of the group (see
=C2=A0 =C2=A0Section 4.2).=C2= =A0 The Content-Format used in the messages is set to
=C2=A0 =C2=A0appli= cation/cbor.

<mglt>
I believe the paragraph above describes= how the secure channel is
established between the Client and the KDC. I= f that is correct that may
be mention explicitly. I would suggest to rep= lace "During this exchange"
by "During the Authorization = request/respons e exchange".

</mglt>

=C2=A0 =C2= =A0Figure 4 gives an overview of the exchange described above.

=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Client =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 KDC
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 |---- Key Distribution Request: POST /group-id = --->|
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |<--- Key Distr= ibution Response: 2.01 (Created) ---|
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|

=C2=A0 =C2=A0 =C2=A0Figure 4= : Message Flow of Key Distribution to a New Group Member



Pal= ombini & Tiloca =C2=A0 =C2=A0 =C2=A0 Expires January 6, 2020 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 11]
=0C
Internet-Draft = =C2=A0Key Provisioning for Group Communication =C2=A0 =C2=A0 =C2=A0 July 20= 19


=C2=A0 =C2=A0The same set of message can also be used for the= following cases,
=C2=A0 =C2=A0when the Client is already a group member= :

=C2=A0 =C2=A0o =C2=A0The Client wishes to (re-)get the current key= ing material, for
=C2=A0 =C2=A0 =C2=A0 cases such as expiration, loss or= suspected mismatch, due to e.g.
=C2=A0 =C2=A0 =C2=A0 reboot or missed g= roup rekeying.=C2=A0 This is further discussed in
=C2=A0 =C2=A0 =C2=A0 S= ection 6.

=C2=A0 =C2=A0o =C2=A0The Client wishes to (re-)get the pub= lic keys of other group
=C2=A0 =C2=A0 =C2=A0 members, e.g. if it is awar= e of new nodes joining the group after
=C2=A0 =C2=A0 =C2=A0 itself.=C2= =A0 This is further discussed in Section 7.

=C2=A0 =C2=A0Additionall= y, the format of the payload of the Key Distribution
=C2=A0 =C2=A0Respon= se (Section 4.2) can be reused for messages sent by the KDC to
=C2=A0 = =C2=A0distribute updated group keying material, in case of a new node
= =C2=A0 =C2=A0joining the group or of a current member leaving the group.=C2= =A0 The key
=C2=A0 =C2=A0management scheme used to send such messages co= uld rely on, e.g.,
=C2=A0 =C2=A0multicast in case of a new node joining = or unicast in case of a node
=C2=A0 =C2=A0leaving the group.

=C2= =A0 =C2=A0Note that proof-of-possession to bind the access token to the Cli= ent
=C2=A0 =C2=A0is performed by using the proof-of-possession key bound= to the access
=C2=A0 =C2=A0token for establishing secure communication = between the Client and
=C2=A0 =C2=A0the KDC.

=C2=A0 =C2=A0If the = application requires backward security, the KDC SHALL generate
=C2=A0 = =C2=A0new group keying material and securely distribute it to all the
= =C2=A0 =C2=A0current group members, using the message format defined in thi= s
=C2=A0 =C2=A0section.=C2=A0 Application profiles may define alternativ= e message
=C2=A0 =C2=A0formats.

<mglt>
I am wondering wh= y SHALL is introduced here as MUST has been used
throughout the document= . I do not see any difference between SHALL and
MUST, so if that is corr= ect, I would recommend to use MUST throughout
the document.
</mgl= t>

4.1.=C2=A0 Key Distribution Request

=C2=A0 =C2=A0The Cl= ient sends a Key Distribution Request to the KDC.=C2=A0 This
=C2=A0 =C2= =A0corresponds to a CoAP POST request to the endpoint in the KDC
=C2=A0 = =C2=A0associated to the group to join.=C2=A0 The endpoint in the KDC is
= =C2=A0 =C2=A0associated to the 'scope' value of the Authorization R= equest/
=C2=A0 =C2=A0Response.=C2=A0 The payload of this request is a CB= OR map which MUST
=C2=A0 =C2=A0contain the following fields:

=C2= =A0 =C2=A0o =C2=A0'type', encoded as a CBOR int, with value 1 (&quo= t;key distribution").

=C2=A0 =C2=A0Additionally, the CBOR map i= n the payload MAY contain the following
=C2=A0 =C2=A0fields, which, if i= ncluded, MUST have the corresponding values:

=C2=A0 =C2=A0o =C2=A0&#= 39;scope', with value the specific resource that the Client is
=C2= =A0 =C2=A0 =C2=A0 authorized to access (i.e. group or topic identifier) and= role(s),
=C2=A0 =C2=A0 =C2=A0 encoded as in Section 3.1.


Palombini & Tiloca =C2=A0 =C2=A0 =C2=A0 Expires January 6, 2020 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 12]
=0C
Internet-Dra= ft =C2=A0Key Provisioning for Group Communication =C2=A0 =C2=A0 =C2=A0 July= 2019


=C2=A0 =C2=A0o =C2=A0'get_pub_keys', if the Client= wishes to receive the public keys of
=C2=A0 =C2=A0 =C2=A0 the other nod= es in the group from the KDC.=C2=A0 The value is an empty
=C2=A0 =C2=A0 = =C2=A0 CBOR array.=C2=A0 This parameter may be present if the KDC stores th= e
=C2=A0 =C2=A0 =C2=A0 public keys of the nodes in the group and distrib= utes them to the
=C2=A0 =C2=A0 =C2=A0 Client; it is useless to have here= if the set of public keys of
=C2=A0 =C2=A0 =C2=A0 the members of the gr= oup is known in another way, e.g. it was
=C2=A0 =C2=A0 =C2=A0 provided b= y the AS.

<mglt>
For large groups, there might be a need to= limit the size of the
response and so to enable that the batch of keys = be retrieved in
multiple exchanges or via another redirection mechanism.=
</mglt>

=C2=A0 =C2=A0o =C2=A0'client_cred', with v= alue the public key or certificate of the
=C2=A0 =C2=A0 =C2=A0 Client, e= ncoded as a CBOR byte string.=C2=A0 If the KDC is managing
=C2=A0 =C2=A0= =C2=A0 (collecting from/distributing to the Client) the public keys of
= =C2=A0 =C2=A0 =C2=A0 the group members, this field contains the public key = of the
=C2=A0 =C2=A0 =C2=A0 Client.=C2=A0 The default encoding for publi= c keys is COSE Keys.
=C2=A0 =C2=A0 =C2=A0 Alternative specific encodings= of this parameter MAY be defined in
=C2=A0 =C2=A0 =C2=A0 applications o= f this specification.

=C2=A0 =C2=A0o =C2=A0'client_cred_verify&#= 39;, encoded as a CBOR byte string.=C2=A0 This
=C2=A0 =C2=A0 =C2=A0 para= meter contains a signature computed by the Client over the
=C2=A0 =C2=A0= =C2=A0 nonce N received from the KDC in the 2.01 (Created) response to
= =C2=A0 =C2=A0 =C2=A0 the token POST request (see Section 3.3).=C2=A0 The Cl= ient computes the
=C2=A0 =C2=A0 =C2=A0 signature by using its own privat= e key, whose corresponding public
=C2=A0 =C2=A0 =C2=A0 key is either dir= ectly specified in the 'client_cred' parameter or
=C2=A0 =C2=A0 = =C2=A0 included in the certificate specified in the 'client_cred'=C2=A0 =C2=A0 =C2=A0 parameter.=C2=A0 This parameter MUST be present if t= he 'client_cred'
=C2=A0 =C2=A0 =C2=A0 parameter is present.
<= br>=C2=A0 =C2=A0o =C2=A0'pub_keys_repos', can be present if a certi= ficate is present in
=C2=A0 =C2=A0 =C2=A0 the 'client_cred' fiel= d, with value a list of public key
=C2=A0 =C2=A0 =C2=A0 repositories sto= ring the certificate of the Client.=C2=A0 This
=C2=A0 =C2=A0 =C2=A0 para= meter is encoded as a CBOR array of CBOR text strings, each of
=C2=A0 = =C2=A0 =C2=A0 which specifies the URI of a key repository.

4.2.=C2= =A0 Key Distribution Response

=C2=A0 =C2=A0The KDC verifies that the= 'scope' received in the Key Distribution
=C2=A0 =C2=A0Request, = if present, is a subset of the 'scope' stored in the access
=C2= =A0 =C2=A0token associated to this client.=C2=A0 If verification fails, the= KDC MUST
=C2=A0 =C2=A0respond with a 4.01 (Unauthorized) error message.=

=C2=A0 =C2=A0If the Key Distribution Request is not formatted corre= ctly (e.g. no
=C2=A0 =C2=A0'scope' field present while expected,= or unknown fields present), the
=C2=A0 =C2=A0KDC MUST respond with 4.00= (Bad Request) error message.

=C2=A0 =C2=A0If verification succeeds,= the KDC sends a Key Distribution success
=C2=A0 =C2=A0Response to the C= lient.=C2=A0 The Key Distribution success Response
=C2=A0 =C2=A0correspo= nds to a 2.01 Created message.=C2=A0 The payload of this response
=C2=A0= =C2=A0is a CBOR map, which MUST contain:




Palombini &= ; Tiloca =C2=A0 =C2=A0 =C2=A0 Expires January 6, 2020 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 13]
=0C
Internet-Draft =C2=A0Key Pr= ovisioning for Group Communication =C2=A0 =C2=A0 =C2=A0 July 2019

=C2=A0 =C2=A0o =C2=A0'kty', identifying the key type of the '= key' parameter.=C2=A0 The set
=C2=A0 =C2=A0 =C2=A0 of values can be = found in the "Key Type" column of the "ACE
=C2=A0 =C2=A0 = =C2=A0 Groupcomm Key" Registry.=C2=A0 Implementations MUST verify that= the key
=C2=A0 =C2=A0 =C2=A0 type matches the application profile being= used, if present, as
=C2=A0 =C2=A0 =C2=A0 registered in the "ACE G= roupcomm Key" registry.

=C2=A0 =C2=A0o =C2=A0'key', con= taining the keying material for the group communication,
=C2=A0 =C2=A0 = =C2=A0 or information required to derive it.

=C2=A0 =C2=A0The exact = format of the 'key' value MUST be defined in applications
=C2=A0= =C2=A0of this specification.=C2=A0 Additionally, documents specifying the = key
=C2=A0 =C2=A0format MUST register it in the "ACE Groupcomm Key&= quot; registry,
=C2=A0 =C2=A0including its name, type and application pr= ofile to be used with, as
=C2=A0 =C2=A0defined in the "ACE Groupcom= m Key" registry, defined in Section 11.5.

=C2=A0 =C2=A0 =C2=A0+= ----------+----------------+---------+-------------------------+
=C2=A0 = =C2=A0 =C2=A0| Name =C2=A0 =C2=A0 | Key Type Value | Profile | Description = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0+-------= ---+----------------+---------+-------------------------+
=C2=A0 =C2=A0 = =C2=A0| Reserved | 0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2= =A0 =C2=A0 =C2=A0 =C2=A0 | This value is reserved =C2=A0|
=C2=A0 =C2=A0 = =C2=A0+----------+----------------+---------+-------------------------+
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0Figure 5: Key Type Values

=C2=A0 =C2=A0Optionall= y, the Key Distribution Response MAY contain the following
=C2=A0 =C2=A0= parameters, which, if included, MUST have the corresponding values:

= =C2=A0 =C2=A0o =C2=A0'profile', with value a CBOR integer that MUST= be used to uniquely
=C2=A0 =C2=A0 =C2=A0 identify the application profi= le for group communication.=C2=A0 The
=C2=A0 =C2=A0 =C2=A0 value MUST be= registered in the "ACE Groupcomm Profile" Registry.

=C2= =A0 =C2=A0o =C2=A0'exp', with value the expiration time of the keyi= ng material for
=C2=A0 =C2=A0 =C2=A0 the group communication, encoded as= a CBOR unsigned integer or
=C2=A0 =C2=A0 =C2=A0 floating-point number.= =C2=A0 This field contains a numeric value
=C2=A0 =C2=A0 =C2=A0 represen= ting the number of seconds from 1970-01-01T00:00:00Z UTC
=C2=A0 =C2=A0 = =C2=A0 until the specified UTC date/time, ignoring leap seconds,
=C2=A0 = =C2=A0 =C2=A0 analogous to what specified in Section 2 of [RFC7519].
=C2=A0 =C2=A0o =C2=A0'pub_keys', may only be present if 'get_p= ub_keys' was present in
=C2=A0 =C2=A0 =C2=A0 the Key Distribution Re= quest.=C2=A0 This parameter is a CBOR byte
=C2=A0 =C2=A0 =C2=A0 string, = which encodes the public keys of all the group members
=C2=A0 =C2=A0 =C2= =A0 paired with the respective member identifiers.=C2=A0 The default
=C2= =A0 =C2=A0 =C2=A0 encoding for public keys is COSE Keys, so the default enc= oding for
=C2=A0 =C2=A0 =C2=A0 'pub_keys' is a CBOR byte string = wrapping a COSE_KeySet (see
=C2=A0 =C2=A0 =C2=A0 [RFC8152]), which conta= ins the public keys of all the members of
=C2=A0 =C2=A0 =C2=A0 the group= .=C2=A0 In particular, each COSE Key in the COSE_KeySet
=C2=A0 =C2=A0 = =C2=A0 includes the identifier of the corresponding group member as value=C2=A0 =C2=A0 =C2=A0 of its 'kid' key parameter.=C2=A0 Alternativ= e specific encodings of




Palombini & Tiloca =C2=A0 = =C2=A0 =C2=A0 Expires January 6, 2020 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 [Page 14]
=0C
Internet-Draft =C2=A0Key Provisioning for= Group Communication =C2=A0 =C2=A0 =C2=A0 July 2019


=C2=A0 =C2= =A0 =C2=A0 this parameter MAY be defined in applications of this
=C2=A0 = =C2=A0 =C2=A0 specification.

=C2=A0 =C2=A0o =C2=A0'group_policie= s', with value a CBOR map, whose entries specify how
=C2=A0 =C2=A0 = =C2=A0 the group handles specific management aspects.=C2=A0 These include, = for
=C2=A0 =C2=A0 =C2=A0 instance, approaches to achieve synchronization= of sequence
=C2=A0 =C2=A0 =C2=A0 numbers among group members.=C2=A0 The= elements of this field are
=C2=A0 =C2=A0 =C2=A0 registered in the "= ;ACE Groupcomm Policy" Registry.=C2=A0 This
=C2=A0 =C2=A0 =C2=A0 sp= ecification defines the two elements "Sequence Number
=C2=A0 =C2=A0= =C2=A0 Synchronization Method" and "Key Update Check Interval&qu= ot;, which are
=C2=A0 =C2=A0 =C2=A0 summarized in Figure 6.=C2=A0 Applic= ation profiles that build on this
=C2=A0 =C2=A0 =C2=A0 document MUST spe= cify the exact content format of included map
=C2=A0 =C2=A0 =C2=A0 entri= es.

+-----------------+-------+----------|--------------------|-----= -------+
| =C2=A0 =C2=A0 =C2=A0Name =C2=A0 =C2=A0 =C2=A0 | CBOR =C2=A0| = =C2=A0 CBOR =C2=A0 | =C2=A0 =C2=A0Description =C2=A0 =C2=A0 | Reference =C2= =A0|
| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | label |= =C2=A0 type =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
|---------= --------+-------+----------|--------------------|------------|
| Sequenc= e Number | TBD1 =C2=A0| tstr/int | Method for a re- =C2=A0 | [[this =C2=A0 = =C2=A0 |
| Synchronization | =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0| cipient node to =C2=A0 =C2=A0| document]] |
| Method =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0| synchronize with =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0|
| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= | =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| sequence numb= ers =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
| =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 | =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0| of a sender node. =C2=A0| =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0|
| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| Its= value is taken | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
| =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 | = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| from the 'Value' =C2=A0 | =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
| =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0| column of the =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|
| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 | =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| Sequenc= e Number =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
| =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0= | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| Synchronization =C2=A0 =C2=A0| =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
| =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0| Method registry =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0|
| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= | =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0|
| Key Update =C2=A0 =C2=A0 =C2=A0| TBD2 =C2=A0= | =C2=A0 int =C2=A0 =C2=A0| Polling interval =C2=A0 | [[this =C2=A0 =C2=A0 = |
| Check Interval =C2=A0| =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0| in seconds, to =C2=A0 =C2=A0 | document]] |
| =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 | =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| check for new =C2=A0 =C2=A0 =C2=A0| =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0| keying material at | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=
| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2= =A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| the KDC =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
+--= ---------------+-------+----------|--------------------|------------+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0Figure 6: ACE Groupcomm Policies

=C2=A0 =C2=A0o =C2=A0'mgt_ke= y_material', encoded as a CBOR byte string and containing
=C2=A0 =C2= =A0 =C2=A0 the administrative keying material to participate in the group=C2=A0 =C2=A0 =C2=A0 rekeying performed by the KDC.=C2=A0 The exact forma= t and content
=C2=A0 =C2=A0 =C2=A0 depend on the specific rekeying schem= e used in the group, which
=C2=A0 =C2=A0 =C2=A0 may be specified in the = application profile.

=C2=A0 =C2=A0Specific application profiles that= build on this document need to
=C2=A0 =C2=A0specify how exactly the key= ing material is used to protect the group
=C2=A0 =C2=A0communication.


Palombini & Tiloca =C2=A0 =C2=A0 =C2=A0 Expires January 6,= 2020 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 15]
=0C
= Internet-Draft =C2=A0Key Provisioning for Group Communication =C2=A0 =C2=A0= =C2=A0 July 2019


5.=C2=A0 Removal of a Node from the Group
<= br>=C2=A0 =C2=A0This section describes at a high level how a node can be re= moved from
=C2=A0 =C2=A0the group.

=C2=A0 =C2=A0If the applicatio= n requires forward security, the KDC SHALL generate
=C2=A0 =C2=A0new gro= up keying material and securely distribute it to all the
=C2=A0 =C2=A0cu= rrent group members but the leaving node, using the message format
=C2= =A0 =C2=A0defined in Section 4.2.=C2=A0 Application profiles may define alt= ernative
=C2=A0 =C2=A0message formats.

5.1.=C2=A0 Expired Authori= zation

=C2=A0 =C2=A0If the AS provides Token introspection (see Sect= ion 5.7 of
=C2=A0 =C2=A0[I-D.ietf-ace-oauth-authz]), the KDC can optiona= lly use and check
=C2=A0 =C2=A0whether:

=C2=A0 =C2=A0o =C2=A0the = node is not authorized anymore;

=C2=A0 =C2=A0o =C2=A0the access toke= n is still valid, upon its expiration.

=C2=A0 =C2=A0Either case, onc= e aware that a node is not authorized anymore, the
=C2=A0 =C2=A0KDC has = to remove the unauthorized node from the list of group
=C2=A0 =C2=A0memb= ers, if the KDC keeps track of that.

5.2.=C2=A0 Request to Leave the= Group

=C2=A0 =C2=A0A node can actively request to leave the group.= =C2=A0 In this case, the
=C2=A0 =C2=A0Client can send a request formatte= d as follows to the KDC, to abandon
=C2=A0 =C2=A0the group.=C2=A0 The cl= ient MUST use the protected channel established
=C2=A0 =C2=A0with ACE, m= entioned in Section 4.

=C2=A0 =C2=A0To request to leave a group, the= client MUST send a CoAP POST request
=C2=A0 =C2=A0to the endpoint in th= e KDC associated to the group to leave (same
=C2=A0 =C2=A0endpoint used = in Section 4.1 for Key Distribution requests).=C2=A0 The
=C2=A0 =C2=A0pa= yload of this Leave Request is a CBOR map which MUST contain:

=C2=A0= =C2=A0o =C2=A0'type', encoded as a CBOR int, with value 2 ("l= eave").

=C2=A0 =C2=A0o =C2=A0'scope', with value the sp= ecific resource that the Client is
=C2=A0 =C2=A0 =C2=A0 authorized to ac= cess (i.e. group or topic identifier) and wants to
=C2=A0 =C2=A0 =C2=A0 = leave, encoded as in Section 3.1.=C2=A0 The 'role' field is omitted= .

=C2=A0 =C2=A0Note that the 'role' field is omitted since s= uch a request should
=C2=A0 =C2=A0only be used to leave a group altogeth= er.=C2=A0 If the leaving node wants
=C2=A0 =C2=A0to be part of a group w= ith fewer roles, it does not need to
=C2=A0 =C2=A0communicate that to th= e KDC, and can simply stop acting according to
=C2=A0 =C2=A0such roles.<= br>


Palombini & Tiloca =C2=A0 =C2=A0 =C2=A0 Expires January = 6, 2020 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 16]
=0CInternet-Draft =C2=A0Key Provisioning for Group Communication =C2=A0 =C2= =A0 =C2=A0 July 2019


=C2=A0 =C2=A0If the Leave Request is such t= hat the KDC cannot extract all the
=C2=A0 =C2=A0necessary information to= understand and process it correctly (e.g. no
=C2=A0 =C2=A0'scope= 9; field present), the KDC MUST respond with a 4.00 (Bad
=C2=A0 =C2=A0Re= quest) error message.=C2=A0 Otherwise, the KDC MUST remove the leaving
= =C2=A0 =C2=A0node from the list of group members, if the KDC keeps track of= that.

=C2=A0 =C2=A0Note that, after having left the group, a node m= ay wish to join it
=C2=A0 =C2=A0again.=C2=A0 Then, as long as the node i= s still authorized to join the
=C2=A0 =C2=A0group, i.e. it has a still v= alid access token, it can re-request to
=C2=A0 =C2=A0join the group dire= ctly to the KDC without needing to retrieve a new
=C2=A0 =C2=A0access to= ken from the AS.=C2=A0 This means that the KDC needs to keep
=C2=A0 =C2= =A0track of nodes with valid access tokens, before deleting all
=C2=A0 = =C2=A0information about the leaving node.

6.=C2=A0 Retrieval of New = or Updated Keying Material

=C2=A0 =C2=A0A node stops using the group= keying material upon its expiration,
=C2=A0 =C2=A0according to the '= ;exp' parameter specified in the retained COSE Key.
=C2=A0 =C2=A0The= n, if it wants to continue participating in the group
=C2=A0 =C2=A0commu= nication, the node has to request new updated keying material to
=C2=A0 = =C2=A0the KDC.=C2=A0 In this case, and depending on what part of the keying=
=C2=A0 =C2=A0material is expired, the client may need to communicate to= the KDC
=C2=A0 =C2=A0its need for that part to be renewed: for example,= if the Client uses
=C2=A0 =C2=A0an individual key to protect outgoing t= raffic and has to renew it,
=C2=A0 =C2=A0the node may request a new one,= or new input material to derive it,
=C2=A0 =C2=A0without renewing the w= hole group keying material.

=C2=A0 =C2=A0The Client may perform the = same request to the KDC also upon
=C2=A0 =C2=A0receiving messages from o= ther group members without being able to
=C2=A0 =C2=A0retrieve the mater= ial to correctly decrypt them.=C2=A0 This may be due to
=C2=A0 =C2=A0a p= revious update of the group keying material (rekeying) triggered
=C2=A0 = =C2=A0by the KDC, that the Client was not able to receive or decrypt.
=C2=A0 =C2=A0Note that policies can be set up so that the Client sends a = request
=C2=A0 =C2=A0to the KDC only after a given number of unsuccessfu= lly decrypted
=C2=A0 =C2=A0incoming messages.=C2=A0 It is application de= pendent and pertaining to the
=C2=A0 =C2=A0particular message exchange (= e.g. =C2=A0[I-D.ietf-core-oscore-groupcomm])
=C2=A0 =C2=A0to set up poli= cies that instruct clients to retain unsuccessfully
=C2=A0 =C2=A0decrypt= ed messages and for how long, so that they can be decrypted
=C2=A0 =C2= =A0after getting updated keying material, rather than just considered
= =C2=A0 =C2=A0non valid messages to discard right away.

=C2=A0 =C2=A0= The same request could also be sent by the client without being
=C2=A0 = =C2=A0triggered by a failed decryption of a message, if the client wants to=
=C2=A0 =C2=A0confirm that it has the latest group keying material.=C2= =A0 If that is the
=C2=A0 =C2=A0case, the client will receive from the K= DC the same group keying
=C2=A0 =C2=A0material it has in memory.

=


Palombini & Tiloca =C2=A0 =C2=A0 =C2=A0 Expires January 6, = 2020 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 17]
=0C
I= nternet-Draft =C2=A0Key Provisioning for Group Communication =C2=A0 =C2=A0 = =C2=A0 July 2019


=C2=A0 =C2=A0Note that the difference between t= he keying material renewal request
=C2=A0 =C2=A0and the keying material = update request is that the first one triggers
=C2=A0 =C2=A0the KDC to pr= oduce new keying material for that node, while the
=C2=A0 =C2=A0second o= ne only triggers distribution (the renewal might have
=C2=A0 =C2=A0happe= ned independently, because of expiration).=C2=A0 Once a node receives
= =C2=A0 =C2=A0new individual keying material, other group members may need t= o use
=C2=A0 =C2=A0the update keying material request to retrieve it.
=C2=A0 =C2=A0Alternatively, the re-distribution of keying material can= be
=C2=A0 =C2=A0initiated by the KDC, which e.g.:

=C2=A0 =C2=A0o= =C2=A0Can maintain an Observable resource to send notifications to
=C2= =A0 =C2=A0 =C2=A0 Clients when the keying material is updated.=C2=A0 Such a= notification
=C2=A0 =C2=A0 =C2=A0 would have the same payload as the Ke= y Re-Distribution Response
=C2=A0 =C2=A0 =C2=A0 defined in Section 6.2.<= br>
=C2=A0 =C2=A0o =C2=A0Can send the payload of the Key Re-Distribution= Response as one or
=C2=A0 =C2=A0 =C2=A0 multiple multicast requests to = the members of the group, using
=C2=A0 =C2=A0 =C2=A0 secure rekeying sch= emes such as [RFC2093][RFC2094][RFC2627].

=C2=A0 =C2=A0o =C2=A0Can s= end unicast requests to each Client over a secure channel,
=C2=A0 =C2=A0= =C2=A0 with the Key Re-Distribution Response as payload.

=C2=A0 =C2= =A0o =C2=A0Can act as a publisher in a pub-sub scenario, and update the
= =C2=A0 =C2=A0 =C2=A0 keying material by publishing on a specific topic on a= broker,
=C2=A0 =C2=A0 =C2=A0 which all the members of the group are sub= scribed to.

=C2=A0 =C2=A0Note that these methods of KDC-initiated ke= y re-distribution have
=C2=A0 =C2=A0different security properties and re= quire different security
=C2=A0 =C2=A0associations.

6.1.=C2=A0 Ke= y Re-Distribution Request

=C2=A0 =C2=A0To request a re-distribution = of keying material, the Client sends a
=C2=A0 =C2=A0shortened Key Distri= bution Request to the KDC (Section 4.1),
=C2=A0 =C2=A0formatted as follo= ws.=C2=A0 The payload MUST contain the following fields:

=C2=A0 =C2= =A0o =C2=A0'type', encoded as a CBOR int, with value 3 ("updat= e key") if the
=C2=A0 =C2=A0 =C2=A0 request is intended to retrieve= updated group keying material, and
=C2=A0 =C2=A0 =C2=A0 4 ("new&qu= ot;) if the request is intended for the KDC to produce and
=C2=A0 =C2=A0= =C2=A0 provide new individual keying material for the Client.

=C2= =A0 =C2=A0o =C2=A0'scope', which contains only the identifier of th= e specific group
=C2=A0 =C2=A0 =C2=A0 or topic, encoded as in Section 3.= 1.=C2=A0 That is, the role field is
=C2=A0 =C2=A0 =C2=A0 not present.





Palombini & Tiloca =C2=A0 =C2=A0 =C2=A0 Expire= s January 6, 2020 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 18= ]
=0C
Internet-Draft =C2=A0Key Provisioning for Group Communication = =C2=A0 =C2=A0 =C2=A0 July 2019


6.2.=C2=A0 Key Re-Distribution Re= sponse

=C2=A0 =C2=A0The KDC receiving a Key Re-Distribution Request = MUST check that it is
=C2=A0 =C2=A0storing a valid access token from tha= t client for that scope.

=C2=A0 =C2=A0If that is not the case, i.e. = it does not store the token or the
=C2=A0 =C2=A0token is not valid for t= hat client for the scope requested, the KDC
=C2=A0 =C2=A0MUST respond wi= th a 4.01 (Unauthorized) error message.=C2=A0 Analogously
=C2=A0 =C2=A0t= o Section 4.2, if the Key Re-Distribution Request is not formatted
=C2= =A0 =C2=A0correctly (e.g. no 'scope' field present, or unknown fiel= ds present),
=C2=A0 =C2=A0the KDC MUST respond with a 4.00 (Bad Request)= error message.

=C2=A0 =C2=A0Otherwise, the KDC replies to the Clien= t with a Key Distribution
=C2=A0 =C2=A0Response, which MUST include the = 'kty', 'key' and 'exp' parameters
=C2=A0 =C2=A0s= pecified in Section 4.2.=C2=A0 The Key Distribution Response MAY also
= =C2=A0 =C2=A0include the 'profile', 'group_policies' and &#= 39;mgt_key_material'
=C2=A0 =C2=A0parameters specified in Section 4.= 2.

=C2=A0 =C2=A0Note that this response might simply re-provide the = same keying
=C2=A0 =C2=A0material currently owned by the Client, if it h= as not been renewed.

7.=C2=A0 Retrieval of Public Keys for Group Mem= bers

=C2=A0 =C2=A0In case the KDC maintains the public keys of group= members, a node in
=C2=A0 =C2=A0the group can contact the KDC to reques= t public keys of either all
=C2=A0 =C2=A0group members or a specified su= bset, using the messages defined
=C2=A0 =C2=A0below.

=C2=A0 =C2= =A0Figure 7 gives an overview of the exchange described above.

=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Client =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 KDC
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0|---- Public Key Request: POST /group-id --->|
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<--- Public Key Respons= e: 2.01 (Created) ---|
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0|

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Figure 7: Me= ssage Flow of Public Key Request-Response

=C2=A0 =C2=A0Note that the= se messages can be combined with the Key Re-Distribution
=C2=A0 =C2=A0me= ssages in Section 6, to request at the same time the keying
=C2=A0 =C2= =A0material and the public keys.=C2=A0 In this case, either a new endpoint = at
=C2=A0 =C2=A0the KDC may be used, or additional information needs to = be sent in
=C2=A0 =C2=A0the request payload, to distinguish these combin= ed messages from the
=C2=A0 =C2=A0Public Key messages described below, s= ince they would be identical
=C2=A0 =C2=A0otherwise.

<mglt>=
I am wondering why public key is needed in a context of group
commun= ication. I do not expect group members but only by the RS.

It is un= clear to me how the
</mglt>





Palombini &= ; Tiloca =C2=A0 =C2=A0 =C2=A0 Expires January 6, 2020 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 19]
=0C
Internet-Draft =C2=A0Key Pr= ovisioning for Group Communication =C2=A0 =C2=A0 =C2=A0 July 2019

7.1.=C2=A0 Public Key Request

=C2=A0 =C2=A0To request public keys,= the Client sends a shortened Key Distribution
=C2=A0 =C2=A0Request to t= he KDC (Section 4.1), formatted as follows.=C2=A0 The payload
=C2=A0 =C2= =A0of this request MUST contain the following fields:

=C2=A0 =C2=A0o= =C2=A0'type', encoded as a CBOR int, with value 5 ("pub keys&= quot;).

=C2=A0 =C2=A0o =C2=A0'get_pub_keys', which has as va= lue a CBOR array including either:

=C2=A0 =C2=A0 =C2=A0 * =C2=A0no e= lements, i.e. an empty array, in order to request the
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0public key of all current group members; or

=C2=A0 = =C2=A0 =C2=A0 * =C2=A0N elements, each of which is the identifier of a grou= p member
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0encoded as a CBOR byte string= , in order to request the public
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0key o= f the specified nodes.

=C2=A0 =C2=A0o =C2=A0'scope', which c= ontains only the identifier of the specific group
=C2=A0 =C2=A0 =C2=A0 o= r topic, encoded as in Section 3.1.=C2=A0 That is, the role field is
=C2= =A0 =C2=A0 =C2=A0 not present.

7.2.=C2=A0 Public Key Response
=C2=A0 =C2=A0The KDC replies to the Client with a Key Distribution Respons= e
=C2=A0 =C2=A0containing only the 'pub_keys' parameter, as spec= ified in
=C2=A0 =C2=A0Section 4.2.=C2=A0 The payload of this response co= ntains the following
=C2=A0 =C2=A0field:

=C2=A0 =C2=A0o =C2=A0= 9;pub_keys', which contains either:

=C2=A0 =C2=A0 =C2=A0 * =C2= =A0the public keys of all the members of the group, if the
=C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0'get_pub_keys' parameter of the Public Key req= uest was an empty
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0array; or

=C2= =A0 =C2=A0 =C2=A0 * =C2=A0the public keys of the group members with the ide= ntifiers
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0specified in the 'get_pub= _keys' parameter of the Public Key
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0request.

=C2=A0 =C2=A0The KDC may enforce one of the following po= licies, in order to handle
=C2=A0 =C2=A0possible identifiers that are in= cluded in the 'get_pub_keys'
=C2=A0 =C2=A0parameter of the Publi= c Key request but are not associated to any
=C2=A0 =C2=A0current group m= ember.

=C2=A0 =C2=A0o =C2=A0The KDC silently ignores those identifie= rs.

=C2=A0 =C2=A0o =C2=A0The KDC retains public keys of group member= s for a given amount of
=C2=A0 =C2=A0 =C2=A0 time after their leaving, b= efore discarding them.=C2=A0 As long as such




Palombini &= amp; Tiloca =C2=A0 =C2=A0 =C2=A0 Expires January 6, 2020 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 20]
=0C
Internet-Draft =C2=A0Ke= y Provisioning for Group Communication =C2=A0 =C2=A0 =C2=A0 July 2019

=C2=A0 =C2=A0 =C2=A0 public keys are retained, the KDC provides them = to a requesting
=C2=A0 =C2=A0 =C2=A0 Client.

=C2=A0 =C2=A0Either = case, a node that has left the group should not expect any of
=C2=A0 =C2= =A0its outgoing messages to be successfully processed, if received after=C2=A0 =C2=A0its leaving, due to a possible group rekeying occurred before= the
=C2=A0 =C2=A0message reception.

8.=C2=A0 ACE Groupcomm Param= eters

=C2=A0 =C2=A0This specification defines a number of fields use= d during the message
=C2=A0 =C2=A0exchange.=C2=A0 The table below summar= izes them, and specifies the CBOR
=C2=A0 =C2=A0key to use instead of the= full descriptive name.












=
























Palombini & Tiloca =C2=A0 =C2=A0 =C2=A0 Ex= pires January 6, 2020 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Pag= e 21]
=0C
Internet-Draft =C2=A0Key Provisioning for Group Communicati= on =C2=A0 =C2=A0 =C2=A0 July 2019


=C2=A0 =C2=A0+--------------+-= ---------+---------------+
=C2=A0 =C2=A0| Name =C2=A0 =C2=A0 =C2=A0 =C2= =A0 | CBOR Key | CBOR Type =C2=A0 =C2=A0 |
=C2=A0 =C2=A0+--------------+= ----------+---------------+
=C2=A0 =C2=A0| scope =C2=A0 =C2=A0 =C2=A0 = =C2=A0| =C2=A0 TBD =C2=A0 =C2=A0| array =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
= =C2=A0 =C2=A0+--------------+----------+---------------+
=C2=A0 =C2=A0| = get_pub_keys | =C2=A0 TBD =C2=A0 =C2=A0| array =C2=A0 =C2=A0 =C2=A0 =C2=A0 = |
=C2=A0 =C2=A0+--------------+----------+---------------+
=C2=A0 =C2= =A0| client_cred =C2=A0| =C2=A0 TBD =C2=A0 =C2=A0| byte string =C2=A0 |
= =C2=A0 =C2=A0+--------------+----------+---------------+
=C2=A0 =C2=A0| = client_cred_ | =C2=A0 TBD =C2=A0 =C2=A0| byte string =C2=A0 |
=C2=A0 =C2= =A0| verify =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0+----------= ----+----------+---------------+
=C2=A0 =C2=A0| pub_keys_ =C2=A0 =C2=A0|= =C2=A0 TBD =C2=A0 =C2=A0| array =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 = =C2=A0| repos =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0+--= ------------+----------+---------------+
=C2=A0 =C2=A0| kty =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 TBD =C2=A0 =C2=A0| int / byte =C2=A0 =C2= =A0|
=C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| string =C2=A0 =C2=A0 =C2=A0 =C2=A0|
= =C2=A0 =C2=A0+--------------+----------+---------------+
=C2=A0 =C2=A0| = key =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 TBD =C2=A0 =C2=A0| see "= ;ACE =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| Groupcomm =C2=A0 = =C2=A0 |
=C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| Key" Registry |
=C2=A0 =C2=A0= +--------------+----------+---------------+
=C2=A0 =C2=A0| profile =C2= =A0 =C2=A0 =C2=A0| =C2=A0 TBD =C2=A0 =C2=A0| int =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 |
=C2=A0 =C2=A0+--------------+----------+---------------+=C2=A0 =C2=A0| exp =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 TBD =C2=A0 = =C2=A0| int / float =C2=A0 |
=C2=A0 =C2=A0+--------------+----------+---= ------------+
=C2=A0 =C2=A0| pub_keys =C2=A0 =C2=A0 | =C2=A0 TBD =C2=A0 = =C2=A0| byte string =C2=A0 |
=C2=A0 =C2=A0+--------------+----------+---= ------------+
=C2=A0 =C2=A0| group_ =C2=A0 =C2=A0 =C2=A0 | =C2=A0 TBD = =C2=A0 =C2=A0| map =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0| p= olicies =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0+--------------+------= ----+---------------+
=C2=A0 =C2=A0| mgt_key_ =C2=A0 =C2=A0 | =C2=A0 TBD= =C2=A0 =C2=A0| byte string =C2=A0 |
=C2=A0 =C2=A0| material =C2=A0 =C2= =A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0+--------------+----------+------------= ---+
=C2=A0 =C2=A0| type =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 TBD =C2=A0= =C2=A0| int =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0+--------= ------+----------+---------------+

9.=C2=A0 ACE Groupcomm Request Ty= pe

=C2=A0 =C2=A0This specification defines a number of types of requ= ests.=C2=A0 The table
=C2=A0 =C2=A0below summarizes them.









Palombini & Tiloca =C2=A0 =C2=A0 =C2=A0 Ex= pires January 6, 2020 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Pag= e 22]
=0C
Internet-Draft =C2=A0Key Provisioning for Group Communicati= on =C2=A0 =C2=A0 =C2=A0 July 2019


=C2=A0 =C2=A0+----------------= --+----------+
=C2=A0 =C2=A0| =C2=A0 =C2=A0 Name =C2=A0 =C2=A0 =C2=A0 = =C2=A0 | =C2=A0Value =C2=A0 |
=C2=A0 =C2=A0+------------------+---------= -+
=C2=A0 =C2=A0| key distribution | =C2=A0 =C2=A01 =C2=A0 =C2=A0 |
= =C2=A0 =C2=A0+------------------+----------+
=C2=A0 =C2=A0| leave =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A02 =C2=A0 =C2=A0 |
=C2= =A0 =C2=A0+------------------+----------+
=C2=A0 =C2=A0| update key =C2= =A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A03 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0+-------= -----------+----------+
=C2=A0 =C2=A0| new =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A04 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0+-----= -------------+----------+
=C2=A0 =C2=A0| pub keys =C2=A0 =C2=A0 =C2=A0 = =C2=A0 | =C2=A0 =C2=A05 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0+------------------= +----------+

10.=C2=A0 Security Considerations

=C2=A0 =C2=A0W= hen a Client receives a message from a sender for the first time, it
=C2= =A0 =C2=A0needs to have a mechanism in place to avoid replay, e.g.
=C2= =A0 =C2=A0Appendix B.2 of [I-D.ietf-core-object-security].

=C2=A0 = =C2=A0The KDC must renew the group keying material upon its expiration.
=
=C2=A0 =C2=A0The KDC should renew the keying material upon group member= ship
=C2=A0 =C2=A0change, and should provide it to the current group mem= bers through
=C2=A0 =C2=A0the rekeying scheme used in the group.

= =C2=A0 =C2=A0The KDC may enforce a rekeying policy that takes into account = the
=C2=A0 =C2=A0overall time required to rekey the group, as well as th= e expected
=C2=A0 =C2=A0rate of changes in the group membership.

= =C2=A0 =C2=A0That is, the KDC may not rekey the group at every membership c= hange,
=C2=A0 =C2=A0for instance if members' joining and leaving occ= ur frequently and
=C2=A0 =C2=A0performing a group rekeying takes too lon= g.=C2=A0 Instead, the KDC may
=C2=A0 =C2=A0rekey the group after a minum= number of group members have joined or
=C2=A0 =C2=A0left within a given= time interval, or during predictable network
=C2=A0 =C2=A0inactivity pe= riods.

=C2=A0 =C2=A0However, this would result in the KDC not consta= ntly preserving
=C2=A0 =C2=A0backward and forward security.=C2=A0 In fac= t, newly joining group members
=C2=A0 =C2=A0could be able to access the = keying material used before their
=C2=A0 =C2=A0joining, and thus could a= ccess past group communications.=C2=A0 Also,
=C2=A0 =C2=A0until the KDC = performs a group rekeying, the newly leaving nodes
=C2=A0 =C2=A0would st= ill be able to access upcoming group communications that are
=C2=A0 =C2= =A0protected with the keying material that has not yet been updated.






Palombini & Tiloca =C2=A0 =C2=A0 =C2=A0 Expire= s January 6, 2020 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 23= ]
=0C
Internet-Draft =C2=A0Key Provisioning for Group Communication = =C2=A0 =C2=A0 =C2=A0 July 2019


10.1.=C2=A0 Update of Keying Mate= rial

=C2=A0 =C2=A0A group member can receive a message shortly after= the group has been
=C2=A0 =C2=A0rekeyed, and new keying material has be= en distributed by the KDC.=C2=A0 In
=C2=A0 =C2=A0the following two cases= , this may result in misaligned keying
=C2=A0 =C2=A0material between the= group members.

=C2=A0 =C2=A0In the first case, the sender protects = a message using the old keying
=C2=A0 =C2=A0material.=C2=A0 However, the= recipient receives the message after having
=C2=A0 =C2=A0received the n= ew keying material, hence not being able to correctly
=C2=A0 =C2=A0proce= ss it.=C2=A0 A possible way to ameliorate this issue is to preserve
=C2= =A0 =C2=A0the old, recent, keying material for a maximum amount of time def= ined
=C2=A0 =C2=A0by the application.=C2=A0 By doing so, the recipient c= an still try to
=C2=A0 =C2=A0process the received message using the old = retained keying material
=C2=A0 =C2=A0as second attempt.=C2=A0 Note that= a former (compromised) group member can
=C2=A0 =C2=A0take advantage of = this by sending messages protected with the old
=C2=A0 =C2=A0retained ke= ying material.=C2=A0 Therefore, a conservative application
=C2=A0 =C2=A0= policy should not admit the storage of old keying material.

=C2=A0 = =C2=A0In the second case, the sender protects a message using the new
= =C2=A0 =C2=A0keying material, but the recipient receives that request befor= e
=C2=A0 =C2=A0having received the new keying material.=C2=A0 Therefore,= the recipient
=C2=A0 =C2=A0would not be able to correctly process the r= equest and hence discards
=C2=A0 =C2=A0it.=C2=A0 If the recipient receiv= es the new keying material shortly after
=C2=A0 =C2=A0that and the sende= r endpoint uses CoAP retransmissions, the former
=C2=A0 =C2=A0will still= be able to receive and correctly process the message.=C2=A0 In
=C2=A0 = =C2=A0any case, the recipient should actively ask the KDC for an updated=C2=A0 =C2=A0keying material according to an application-defined policy, f= or
=C2=A0 =C2=A0instance after a given number of unsuccessfully decrypte= d incoming
=C2=A0 =C2=A0messages.

10.2.=C2=A0 Block-Wise Consider= ations

=C2=A0 =C2=A0If the block-wise options [RFC7959] are used, an= d the keying material
=C2=A0 =C2=A0is updated in the middle of a block-w= ise transfer, the sender of the
=C2=A0 =C2=A0blocks just changes the key= ing material to the updated one and
=C2=A0 =C2=A0continues the transfer.= =C2=A0 As long as both sides get the new keying
=C2=A0 =C2=A0material, u= pdating the keying material in the middle of a transfer
=C2=A0 =C2=A0wil= l not cause any issue.=C2=A0 Otherwise, the sender will have to
=C2=A0 = =C2=A0transmit the message again, when receiving an error message from the<= br>=C2=A0 =C2=A0recipient.

=C2=A0 =C2=A0Compared to a scenario where= the transfer does not use block-wise,
=C2=A0 =C2=A0depending on how fas= t the keying material is changed, the nodes might
=C2=A0 =C2=A0consume a= larger amount of the network resending the blocks again and
=C2=A0 =C2= =A0again, which might be problematic.





Palombini &= ; Tiloca =C2=A0 =C2=A0 =C2=A0 Expires January 6, 2020 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 24]
=0C
Internet-Draft =C2=A0Key Pr= ovisioning for Group Communication =C2=A0 =C2=A0 =C2=A0 July 2019

11.=C2=A0 IANA Considerations

=C2=A0 =C2=A0This document has the f= ollowing actions for IANA.

11.1.=C2=A0 ACE Authorization Server Requ= est Creation Hints Registry

=C2=A0 =C2=A0IANA is asked to register t= he following entries in the "ACE
=C2=A0 =C2=A0Authorization Server = Request Creation Hints" Registry defined in
=C2=A0 =C2=A0Section 8.= 1 of [I-D.ietf-ace-oauth-authz].

=C2=A0 =C2=A0o =C2=A0Name: sign_inf= o

=C2=A0 =C2=A0o =C2=A0CBOR Key: TBD (range -256 to 255)

=C2= =A0 =C2=A0o =C2=A0Value Type: any

=C2=A0 =C2=A0o =C2=A0Reference: [[= This specification]]

=C2=A0 =C2=A0o =C2=A0Name: pub_key_enc

= =C2=A0 =C2=A0o =C2=A0CBOR Key: TBD (range -256 to 255)

=C2=A0 =C2=A0= o =C2=A0Value Type: integer

=C2=A0 =C2=A0o =C2=A0Reference: [[This s= pecification]]

11.2.=C2=A0 ACE Public Key Encoding Registry

= =C2=A0 =C2=A0This specification establishes the "ACE Public Key Encodi= ng" IANA
=C2=A0 =C2=A0Registry.=C2=A0 The Registry has been created= to use the "Expert Review
=C2=A0 =C2=A0Required" registration= procedure [RFC8126].=C2=A0 Expert review guidelines
=C2=A0 =C2=A0are pr= ovided in Section 11.9.=C2=A0 It should be noted that, in addition
=C2= =A0 =C2=A0to the expert review, some portions of the Registry require a
= =C2=A0 =C2=A0specification, potentially a Standards Track RFC, be supplied = as
=C2=A0 =C2=A0well.

=C2=A0 =C2=A0The columns of this Registry a= re:

=C2=A0 =C2=A0o =C2=A0Name: This is a descriptive name that enabl= es easier reference to
=C2=A0 =C2=A0 =C2=A0 the item.=C2=A0 The name MUS= T be unique.=C2=A0 It is not used in the
=C2=A0 =C2=A0 =C2=A0 encoding.<= br>
=C2=A0 =C2=A0o =C2=A0Value: The value to be used to identify this pu= blic key encoding.
=C2=A0 =C2=A0 =C2=A0 This value MUST be unique.=C2=A0= The value can be a positive or a
=C2=A0 =C2=A0 =C2=A0 negative integer.= =C2=A0 Integer values between 0 and 255 are designated
=C2=A0 =C2=A0 =C2= =A0 as Standards Track Document required.=C2=A0 Integer values from 256 to<= br>=C2=A0 =C2=A0 =C2=A0 65535 are designated as Specification Required.=C2= =A0 Integer values of




Palombini & Tiloca =C2=A0 =C2= =A0 =C2=A0 Expires January 6, 2020 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 [Page 25]
=0C
Internet-Draft =C2=A0Key Provisioning for Gr= oup Communication =C2=A0 =C2=A0 =C2=A0 July 2019


=C2=A0 =C2=A0 = =C2=A0 greater than 65535 are designated as expert review.=C2=A0 Integer=C2=A0 =C2=A0 =C2=A0 values less than -65536 are marked as private use.
=C2=A0 =C2=A0o =C2=A0Description: This field contains a brief descript= ion for this
=C2=A0 =C2=A0 =C2=A0 public key encoding.

=C2=A0 =C2= =A0o =C2=A0Reference: This field contains a pointer to the public
=C2=A0= =C2=A0 =C2=A0 specification providing the public key encoding, if one exis= ts.

=C2=A0 =C2=A0The value 0 is to be marked as "Reserved"= .

11.3.=C2=A0 ACE Groupcomm Parameters Registry

=C2=A0 =C2=A0= This specification establishes the "ACE Groupcomm Parameters" IAN= A
=C2=A0 =C2=A0Registry.=C2=A0 The Registry has been created to use the = "Expert Review
=C2=A0 =C2=A0Required" registration procedure [= RFC8126].=C2=A0 Expert review guidelines
=C2=A0 =C2=A0are provided in Se= ction 11.9.

=C2=A0 =C2=A0The columns of this Registry are:

= =C2=A0 =C2=A0o =C2=A0Name: This is a descriptive name that enables easier r= eference to
=C2=A0 =C2=A0 =C2=A0 the item.=C2=A0 The name MUST be unique= .=C2=A0 It is not used in the
=C2=A0 =C2=A0 =C2=A0 encoding.

=C2= =A0 =C2=A0o =C2=A0CBOR Key: This is the value used as CBOR key of the item.= =C2=A0 These
=C2=A0 =C2=A0 =C2=A0 values MUST be unique.=C2=A0 The value= can be a positive integer, a
=C2=A0 =C2=A0 =C2=A0 negative integer, or = a string.

=C2=A0 =C2=A0o =C2=A0CBOR Type: This contains the CBOR typ= e of the item, or a pointer
=C2=A0 =C2=A0 =C2=A0 to the registry that de= fines its type, when that depends on
=C2=A0 =C2=A0 =C2=A0 another item.<= br>
=C2=A0 =C2=A0o =C2=A0Reference: This contains a pointer to the publi= c specification for
=C2=A0 =C2=A0 =C2=A0 the format of the item, if one = exists.

=C2=A0 =C2=A0This Registry has been initially populated by t= he values in
=C2=A0 =C2=A0Section 8.=C2=A0 The specification column for = all of these entries will be
=C2=A0 =C2=A0this document.

11.4.=C2= =A0 Ace Groupcomm Request Type Registry

=C2=A0 =C2=A0This specificat= ion establishes the "ACE Groupcomm Request Type" IANA
=C2=A0 = =C2=A0Registry.=C2=A0 The Registry has been created to use the "Expert= Review
=C2=A0 =C2=A0Required" registration procedure [RFC8126].=C2= =A0 Expert review guidelines
=C2=A0 =C2=A0are provided in Section 11.9.<= br>
=C2=A0 =C2=A0The columns of this Registry are:




Pa= lombini & Tiloca =C2=A0 =C2=A0 =C2=A0 Expires January 6, 2020 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 26]
=0C
Internet-Draf= t =C2=A0Key Provisioning for Group Communication =C2=A0 =C2=A0 =C2=A0 July = 2019


=C2=A0 =C2=A0o =C2=A0Name: This is a descriptive name that = enables easier reference to
=C2=A0 =C2=A0 =C2=A0 the item.=C2=A0 The nam= e MUST be unique.=C2=A0 It is not used in the
=C2=A0 =C2=A0 =C2=A0 encod= ing.

=C2=A0 =C2=A0o =C2=A0Value: This is the value used to identify = the request.=C2=A0 These
=C2=A0 =C2=A0 =C2=A0 values MUST be unique.=C2= =A0 The value must be a positive integer.

=C2=A0 =C2=A0o =C2=A0Refer= ence: This contains a pointer to the public specification for
=C2=A0 =C2= =A0 =C2=A0 the format of the item, if one exists.

=C2=A0 =C2=A0This = Registry has been initially populated by the values in
=C2=A0 =C2=A0Sect= ion 9.=C2=A0 The reference column for all of these entries will be
=C2= =A0 =C2=A0this document.=C2=A0 The value 0 is to be marked as "Reserve= d".

11.5.=C2=A0 ACE Groupcomm Key Registry

=C2=A0 =C2=A0= This specification establishes the "ACE Groupcomm Key" IANA Regis= try.
=C2=A0 =C2=A0The Registry has been created to use the "Expert = Review Required"
=C2=A0 =C2=A0registration procedure [RFC8126].=C2= =A0 Expert review guidelines are
=C2=A0 =C2=A0provided in Section 11.9.<= br>
=C2=A0 =C2=A0The columns of this Registry are:

=C2=A0 =C2=A0o= =C2=A0Name: This is a descriptive name that enables easier reference to=C2=A0 =C2=A0 =C2=A0 the item.=C2=A0 The name MUST be unique.=C2=A0 It is = not used in the
=C2=A0 =C2=A0 =C2=A0 encoding.

=C2=A0 =C2=A0o =C2= =A0Key Type Value: This is the value used to identify the keying
=C2=A0 = =C2=A0 =C2=A0 material.=C2=A0 These values MUST be unique.=C2=A0 The value = can be a
=C2=A0 =C2=A0 =C2=A0 positive integer, a negative integer, or a= string.

=C2=A0 =C2=A0o =C2=A0Profile: This field may contain one or= more descriptive strings of
=C2=A0 =C2=A0 =C2=A0 application profiles t= o be used with this item.=C2=A0 The values should
=C2=A0 =C2=A0 =C2=A0 b= e taken from the Name column of the "ACE Groupcomm Profile"
= =C2=A0 =C2=A0 =C2=A0 Registry.

=C2=A0 =C2=A0o =C2=A0Description: Thi= s field contains a brief description of the keying
=C2=A0 =C2=A0 =C2=A0 = material.

=C2=A0 =C2=A0o =C2=A0References: This contains a pointer t= o the public specification
=C2=A0 =C2=A0 =C2=A0 for the format of the ke= ying material, if one exists.

=C2=A0 =C2=A0This Registry has been in= itially populated by the values in Figure 5.
=C2=A0 =C2=A0The specificat= ion column for all of these entries will be this
=C2=A0 =C2=A0document.<= br>





Palombini & Tiloca =C2=A0 =C2=A0 =C2=A0 Expi= res January 6, 2020 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page = 27]
=0C
Internet-Draft =C2=A0Key Provisioning for Group Communication= =C2=A0 =C2=A0 =C2=A0 July 2019


11.6.=C2=A0 ACE Groupcomm Profil= e Registry

=C2=A0 =C2=A0This specification establishes the "ACE= Groupcomm Profile" IANA
=C2=A0 =C2=A0Registry.=C2=A0 The Registry = has been created to use the "Expert Review
=C2=A0 =C2=A0Required&qu= ot; registration procedure [RFC8126].=C2=A0 Expert review guidelines
=C2= =A0 =C2=A0are provided in Section 11.9.=C2=A0 It should be noted that, in a= ddition
=C2=A0 =C2=A0to the expert review, some portions of the Registry= require a
=C2=A0 =C2=A0specification, potentially a Standards Track RFC= , be supplied as
=C2=A0 =C2=A0well.

=C2=A0 =C2=A0The columns of t= his Registry are:

=C2=A0 =C2=A0o =C2=A0Name: The name of the applica= tion profile, to be used as value of
=C2=A0 =C2=A0 =C2=A0 the profile at= tribute.

=C2=A0 =C2=A0o =C2=A0Description: Text giving an overview o= f the application profile
=C2=A0 =C2=A0 =C2=A0 and the context it is dev= eloped for.

=C2=A0 =C2=A0o =C2=A0CBOR Value: CBOR abbreviation for t= he name of this application
=C2=A0 =C2=A0 =C2=A0 profile.=C2=A0 Differen= t ranges of values use different registration
=C2=A0 =C2=A0 =C2=A0 polic= ies [RFC8126].=C2=A0 Integer values from -256 to 255 are
=C2=A0 =C2=A0 = =C2=A0 designated as Standards Action.=C2=A0 Integer values from -65536 to<= br>=C2=A0 =C2=A0 =C2=A0 -257 and from 256 to 65535 are designated as Specif= ication
=C2=A0 =C2=A0 =C2=A0 Required.=C2=A0 Integer values greater than= 65535 are designated as
=C2=A0 =C2=A0 =C2=A0 Expert Review.=C2=A0 Integ= er values less than -65536 are marked as
=C2=A0 =C2=A0 =C2=A0 Private Us= e.

=C2=A0 =C2=A0o =C2=A0Reference: This contains a pointer to the pu= blic specification of
=C2=A0 =C2=A0 =C2=A0 the abbreviation for this app= lication profile, if one exists.

11.7.=C2=A0 ACE Groupcomm Policy Re= gistry

=C2=A0 =C2=A0This specification establishes the "ACE Gro= upcomm Policy" IANA
=C2=A0 =C2=A0Registry.=C2=A0 The Registry has b= een created to use the "Expert Review
=C2=A0 =C2=A0Required" r= egistration procedure [RFC8126].=C2=A0 Expert review guidelines
=C2=A0 = =C2=A0are provided in Section 11.9.=C2=A0 It should be noted that, in addit= ion
=C2=A0 =C2=A0to the expert review, some portions of the Registry req= uire a
=C2=A0 =C2=A0specification, potentially a Standards Track RFC, be= supplied as
=C2=A0 =C2=A0well.

=C2=A0 =C2=A0The columns of this = Registry are:

=C2=A0 =C2=A0o =C2=A0Name: The name of the group commu= nication policy.

=C2=A0 =C2=A0o =C2=A0CBOR label: The value to be us= ed to identify this group
=C2=A0 =C2=A0 =C2=A0 communication policy.=C2= =A0 Key map labels MUST be unique.=C2=A0 The label
=C2=A0 =C2=A0 =C2=A0 = can be a positive integer, a negative integer or a string.
=C2=A0 =C2=A0= =C2=A0 Integer values between 0 and 255 and strings of length 1 are


Palombini & Tiloca =C2=A0 =C2=A0 =C2=A0 Expires January 6, 202= 0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 28]
=0C
Inte= rnet-Draft =C2=A0Key Provisioning for Group Communication =C2=A0 =C2=A0 =C2= =A0 July 2019


=C2=A0 =C2=A0 =C2=A0 designated as Standards Track= Document required.=C2=A0 Integer values
=C2=A0 =C2=A0 =C2=A0 from 256 t= o 65535 and strings of length 2 are designated as
=C2=A0 =C2=A0 =C2=A0 S= pecification Required.=C2=A0 Integer values of greater than 65535 and
= =C2=A0 =C2=A0 =C2=A0 strings of length greater than 2 are designated as exp= ert review.
=C2=A0 =C2=A0 =C2=A0 Integer values less than -65536 are mar= ked as private use.

=C2=A0 =C2=A0o =C2=A0CBOR type: the CBOR type us= ed to encode the value of this group
=C2=A0 =C2=A0 =C2=A0 communication = policy.

=C2=A0 =C2=A0o =C2=A0Description: This field contains a brie= f description for this
=C2=A0 =C2=A0 =C2=A0 group communication policy.<= br>
=C2=A0 =C2=A0o =C2=A0Reference: This field contains a pointer to the= public
=C2=A0 =C2=A0 =C2=A0 specification providing the format of the g= roup communication
=C2=A0 =C2=A0 =C2=A0 policy, if one exists.

= =C2=A0 =C2=A0This registry will be initially populated by the values in Fig= ure 6.

11.8.=C2=A0 Sequence Number Synchronization Method Registry
=C2=A0 =C2=A0This specification establishes the "Sequence Number= Synchronization
=C2=A0 =C2=A0Method" IANA Registry.=C2=A0 The Regi= stry has been created to use the
=C2=A0 =C2=A0"Expert Review Requir= ed" registration procedure [RFC8126].=C2=A0 Expert
=C2=A0 =C2=A0rev= iew guidelines are provided in Section 11.9.=C2=A0 It should be noted
= =C2=A0 =C2=A0that, in addition to the expert review, some portions of the R= egistry
=C2=A0 =C2=A0require a specification, potentially a Standards Tr= ack RFC, be
=C2=A0 =C2=A0supplied as well.

=C2=A0 =C2=A0The colum= ns of this Registry are:

=C2=A0 =C2=A0o =C2=A0Name: The name of the = sequence number synchronization method.

=C2=A0 =C2=A0o =C2=A0Value: = The value to be used to identify this sequence number
=C2=A0 =C2=A0 =C2= =A0 synchronization method.

=C2=A0 =C2=A0o =C2=A0Description: This f= ield contains a brief description for this
=C2=A0 =C2=A0 =C2=A0 sequence= number synchronization method.

=C2=A0 =C2=A0o =C2=A0Reference: This= field contains a pointer to the public
=C2=A0 =C2=A0 =C2=A0 specificati= on describing the sequence number synchronization
=C2=A0 =C2=A0 =C2=A0 m= ethod.

11.9.=C2=A0 Expert Review Instructions

=C2=A0 =C2=A0Th= e IANA Registries established in this document are defined as
=C2=A0 =C2= =A0expert review.=C2=A0 This section gives some general guidelines for what=
=C2=A0 =C2=A0the experts should be looking for, but they are being desi= gnated as
=C2=A0 =C2=A0experts for a reason so they should be given subs= tantial latitude.



Palombini & Tiloca =C2=A0 =C2=A0 =C2= =A0 Expires January 6, 2020 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 [Page 29]
=0C
Internet-Draft =C2=A0Key Provisioning for Group Com= munication =C2=A0 =C2=A0 =C2=A0 July 2019


=C2=A0 =C2=A0Expert re= viewers should take into consideration the following points:

=C2=A0 = =C2=A0o =C2=A0Point squatting should be discouraged.=C2=A0 Reviewers are en= couraged
=C2=A0 =C2=A0 =C2=A0 to get sufficient information for registra= tion requests to ensure
=C2=A0 =C2=A0 =C2=A0 that the usage is not going= to duplicate one that is already
=C2=A0 =C2=A0 =C2=A0 registered and th= at the point is likely to be used in deployments.
=C2=A0 =C2=A0 =C2=A0 T= he zones tagged as private use are intended for testing purposes
=C2=A0 = =C2=A0 =C2=A0 and closed environments, code points in other ranges should n= ot be
=C2=A0 =C2=A0 =C2=A0 assigned for testing.

=C2=A0 =C2=A0o = =C2=A0Specifications are required for the standards track range of point=C2=A0 =C2=A0 =C2=A0 assignment.=C2=A0 Specifications should exist for spe= cification
=C2=A0 =C2=A0 =C2=A0 required ranges, but early assignment be= fore a specification is
=C2=A0 =C2=A0 =C2=A0 available is considered to = be permissible.=C2=A0 Specifications are
=C2=A0 =C2=A0 =C2=A0 needed for= the first-come, first-serve range if they are expected
=C2=A0 =C2=A0 = =C2=A0 to be used outside of closed environments in an interoperable way.=C2=A0 =C2=A0 =C2=A0 When specifications are not provided, the descriptio= n provided
=C2=A0 =C2=A0 =C2=A0 needs to have sufficient information to = identify what the point is
=C2=A0 =C2=A0 =C2=A0 being used for.

= =C2=A0 =C2=A0o =C2=A0Experts should take into account the expected usage of= fields when
=C2=A0 =C2=A0 =C2=A0 approving point assignment.=C2=A0 The = fact that there is a range for
=C2=A0 =C2=A0 =C2=A0 standards track docu= ments does not mean that a standards track
=C2=A0 =C2=A0 =C2=A0 document= cannot have points assigned outside of that range.=C2=A0 The
=C2=A0 =C2= =A0 =C2=A0 length of the encoded value should be weighed against how many=C2=A0 =C2=A0 =C2=A0 code points of that length are left, the size of dev= ice it will be
=C2=A0 =C2=A0 =C2=A0 used on, and the number of code poin= ts left that encode to that
=C2=A0 =C2=A0 =C2=A0 size.

12.=C2=A0 = References

12.1.=C2=A0 Normative References

=C2=A0 =C2=A0[I-D= .ietf-ace-oauth-authz]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 H. Tschofenig, "Authentication and = Authorization for
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Const= rained Environments (ACE) using the OAuth 2.0
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 Framework (ACE-OAuth)", draft-ietf-ace-oauth-= authz-24
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (work in progr= ess), March 2019.

=C2=A0 =C2=A0[I-D.ietf-ace-oauth-params]
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Seitz, L., "Additional OAut= h Parameters for Authorization
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 in Constrained Environments (ACE)", draft-ietf-ace-oauth-
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 params-05 (work in progres= s), March 2019.







Palombini & Tiloca =C2= =A0 =C2=A0 =C2=A0 Expires January 6, 2020 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 [Page 30]
=0C
Internet-Draft =C2=A0Key Provisioning= for Group Communication =C2=A0 =C2=A0 =C2=A0 July 2019


=C2=A0 = =C2=A0[I-D.ietf-core-oscore-groupcomm]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Tiloca, M., Selander, G., Palombini, F., and J. Park,
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "Group OSCORE - Secur= e Group Communication for CoAP",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 draft-ietf-core-oscore-groupcomm-05 (work in progress),
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 July 2019.

=C2=A0 = =C2=A0[RFC2119] =C2=A0Bradner, S., "Key words for use in RFCs to Indic= ate
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Requirement Levels&= quot;, BCP 14, RFC 2119,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 DOI 10.17487/RFC2119, March 1997,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 <http= s://www.rfc-editor.org/info/rfc2119>.

=C2=A0 =C2=A0[RFC7049] = =C2=A0Bormann, C. and P. Hoffman, "Concise Binary Object
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Representation (CBOR)", RFC 704= 9, DOI 10.17487/RFC7049,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 October 2013, <h= ttps://www.rfc-editor.org/info/rfc7049>.

=C2=A0 =C2=A0[RFC812= 6] =C2=A0Cotton, M., Leiba, B., and T. Narten, "Guidelines for
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Writing an IANA Consideration= s Section in RFCs", BCP 26,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 RFC 8126, DOI 10.17487/RFC8126, June 2017,
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <https://www.rfc-editor.org/info/rfc8126>.

=C2=A0= =C2=A0[RFC8152] =C2=A0Schaad, J., "CBOR Object Signing and Encryption= (COSE)",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 RFC 8152= , DOI 10.17487/RFC8152, July 2017,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 <https= ://www.rfc-editor.org/info/rfc8152>.

12.2.=C2=A0 Informative = References

=C2=A0 =C2=A0[I-D.dijk-core-groupcomm-bis]
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Dijk, E., Wang, C., and M. Tiloca, &= quot;Group Communication
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 for the Constrained Application Protocol (CoAP)", draft-
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 dijk-core-groupcomm-bis-00 (work= in progress), March 2019.

=C2=A0 =C2=A0[I-D.ietf-ace-dtls-authorize= ]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Gerdes, S., Bergmann,= O., Bormann, C., Selander, G., and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 L. Seitz, "Datagram Transport Layer Security (DTLS)
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Profile for Authentication= and Authorization for
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = Constrained Environments (ACE)", draft-ietf-ace-dtls-
=C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 authorize-08 (work in progress), April = 2019.

=C2=A0 =C2=A0[I-D.ietf-ace-mqtt-tls-profile]
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Sengul, C., Kirby, A., and P. Fremantle,= "MQTT-TLS profile
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= of ACE", draft-ietf-ace-mqtt-tls-profile-00 (work in
=C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 progress), May 2019.

=C2=A0 =C2= =A0[I-D.ietf-ace-oscore-profile]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 Palombini, F., Seitz, L., Selander, G., and M. Gunnarsson,
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "OSCORE profile of th= e Authentication and Authorization
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 for Constrained Environments Framework", draft-ietf-ace-=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 oscore-profile-07 (wor= k in progress), February 2019.



Palombini & Tiloca =C2=A0= =C2=A0 =C2=A0 Expires January 6, 2020 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 [Page 31]
=0C
Internet-Draft =C2=A0Key Provisioning for= Group Communication =C2=A0 =C2=A0 =C2=A0 July 2019


=C2=A0 =C2= =A0[I-D.ietf-core-coap-pubsub]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 Koster, M., Keranen, A., and J. Jimenez, "Publish-
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Subscribe Broker for the Constrai= ned Application Protocol
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 (CoAP)", draft-ietf-core-coap-pubsub-08 (work in
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 progress), March 2019.

=C2=A0 =C2= =A0[I-D.ietf-core-object-security]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "Object Security for = Constrained RESTful Environments
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 (OSCORE)", draft-ietf-core-object-security-16 (work in
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 progress), March 2019.
=
=C2=A0 =C2=A0[RFC2093] =C2=A0Harney, H. and C. Muckenhirn, "Group = Key Management
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Protocol= (GKMP) Specification", RFC 2093,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 DOI 10.17487/RFC2093, July 1997,
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 <https://www.rfc-editor.org/info/rfc2093>.

=C2=A0 =C2= =A0[RFC2094] =C2=A0Harney, H. and C. Muckenhirn, "Group Key Management=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Protocol (GKMP) Archit= ecture", RFC 2094,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= DOI 10.17487/RFC2094, July 1997,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 <https://= www.rfc-editor.org/info/rfc2094>.

=C2=A0 =C2=A0[RFC2627] =C2= =A0Wallner, D., Harder, E., and R. Agee, "Key Management for
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Multicast: Issues and Architectu= res", RFC 2627,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 DO= I 10.17487/RFC2627, June 1999,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 <https://www= .rfc-editor.org/info/rfc2627>.

=C2=A0 =C2=A0[RFC7390] =C2=A0R= ahman, A., Ed. and E. Dijk, Ed., "Group Communication for
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 the Constrained Application Proto= col (CoAP)", RFC 7390,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 DOI 10.17487/RFC7390, October 2014,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 <https://www.rfc-editor.org/info/rfc7390>.

=C2=A0 =C2=A0[RFC= 7519] =C2=A0Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (JWT)", RFC 7519, D= OI 10.17487/RFC7519, May 2015,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 <https://www= .rfc-editor.org/info/rfc7519>.

=C2=A0 =C2=A0[RFC7959] =C2=A0B= ormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 the Constrained Application Protocol= (CoAP)", RFC 7959,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 DOI 10.17487/RFC7959, August 2016,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 <h= ttps://www.rfc-editor.org/info/rfc7959>.

=C2=A0 =C2=A0[RFC825= 9] =C2=A0Bray, T., Ed., "The JavaScript Object Notation (JSON) Data=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Interchange Format",= STD 90, RFC 8259,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 DOI = 10.17487/RFC8259, December 2017,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 <https://= www.rfc-editor.org/info/rfc8259>.






Palombi= ni & Tiloca =C2=A0 =C2=A0 =C2=A0 Expires January 6, 2020 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 32]
=0C
Internet-Draft =C2= =A0Key Provisioning for Group Communication =C2=A0 =C2=A0 =C2=A0 July 2019<= br>

Appendix A.=C2=A0 Requirements on Application Profiles

= =C2=A0 =C2=A0This section lists the requirements on application profiles of= this
=C2=A0 =C2=A0specification,for the convenience of application prof= ile designers.

=C2=A0 =C2=A0o =C2=A0Specify the communication protoc= ol the members of the group must
=C2=A0 =C2=A0 =C2=A0 use (e.g., multica= st CoAP).

=C2=A0 =C2=A0o =C2=A0Specify the security protocol the gro= up members must use to
=C2=A0 =C2=A0 =C2=A0 protect their communication = (e.g., group OSCORE).=C2=A0 This must
=C2=A0 =C2=A0 =C2=A0 provide encry= ption, integrity and replay protection.

=C2=A0 =C2=A0o =C2=A0Specify= the encoding and value of the identifier of group or topic
=C2=A0 =C2= =A0 =C2=A0 and role of 'scope' (see Section 3.1).

=C2=A0 =C2= =A0o =C2=A0Specify and register the application profile identifier (see
= =C2=A0 =C2=A0 =C2=A0 Section 4.1).

=C2=A0 =C2=A0o =C2=A0Specify the = acceptable values of 'kty' (see Section 4.2).

=C2=A0 =C2=A0o= =C2=A0Specify the format and content of 'group_policies' entries (= see
=C2=A0 =C2=A0 =C2=A0 Section 4.2).

=C2=A0 =C2=A0o =C2=A0Optio= nally, specify the format and content of 'mgt_key_material'
=C2= =A0 =C2=A0 =C2=A0 (see Section 4.2).

=C2=A0 =C2=A0o =C2=A0Optionally= , specify tranport profile of ACE
=C2=A0 =C2=A0 =C2=A0 [I-D.ietf-ace-oau= th-authz] to use between Client and KDC.

=C2=A0 =C2=A0o =C2=A0Option= ally, specify the encoding of public keys, of 'client_cred',
=C2= =A0 =C2=A0 =C2=A0 and of 'pub_keys' if COSE_Keys are not used (see = Section 4.2).

=C2=A0 =C2=A0o =C2=A0Optionally, specify the acceptabl= e values for parameters related
=C2=A0 =C2=A0 =C2=A0 to signature algori= thm and signature keys: 'sign_alg',
=C2=A0 =C2=A0 =C2=A0 'si= gn_parameters', 'sign_key_parameters', 'pub_key_enc' (s= ee
=C2=A0 =C2=A0 =C2=A0 Section 3.3).

=C2=A0 =C2=A0o =C2=A0Option= ally, specify the negotiation of parameter values for
=C2=A0 =C2=A0 =C2= =A0 signature algorithm and signature keys, if 'sign_info' and
= =C2=A0 =C2=A0 =C2=A0 'pub_key_enc' are not used (see Section 3.3).<= br>
Appendix B.=C2=A0 Document Updates

=C2=A0 =C2=A0RFC EDITOR: P= LEASE REMOVE THIS SECTION.







Palombini & T= iloca =C2=A0 =C2=A0 =C2=A0 Expires January 6, 2020 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 [Page 33]
=0C
Internet-Draft =C2=A0Key Provi= sioning for Group Communication =C2=A0 =C2=A0 =C2=A0 July 2019


B= .1.=C2=A0 Version -01 to -02

=C2=A0 =C2=A0o =C2=A0Editorial fixes.
=C2=A0 =C2=A0o =C2=A0Distinction between transport profile and applic= ation profile
=C2=A0 =C2=A0 =C2=A0 (Section 1.1).

=C2=A0 =C2=A0o = =C2=A0New parameters 'sign_info' and 'pub_key_enc' to negot= iate
=C2=A0 =C2=A0 =C2=A0 parameter values for signature algorithm and s= ignature keys
=C2=A0 =C2=A0 =C2=A0 (Section 3.3).

=C2=A0 =C2=A0o = =C2=A0New parameter 'type' to distinguish different Key Distributio= n
=C2=A0 =C2=A0 =C2=A0 Request messages (Section 4.1).

=C2=A0 =C2= =A0o =C2=A0New parameter 'client_cred_verify' in the Key Distributi= on Request
=C2=A0 =C2=A0 =C2=A0 to convey a Client signature (Section 4.= 1).

=C2=A0 =C2=A0o =C2=A0Encoding of 'pub_keys_repos' (Secti= on 4.1).

=C2=A0 =C2=A0o =C2=A0Encoding of 'mgt_key_material'= (Section 4.1).

=C2=A0 =C2=A0o =C2=A0Improved description on retriev= al of new or updated keying
=C2=A0 =C2=A0 =C2=A0 material (Section 6).
=C2=A0 =C2=A0o =C2=A0Encoding of 'get_pub_keys' in Public Key= Request (Section 7.1).

=C2=A0 =C2=A0o =C2=A0Extended security consi= derations (Sections 10.1 and 10.2).

=C2=A0 =C2=A0o =C2=A0New "A= CE Public Key Encoding" IANA Registry (Section 11.2).

=C2=A0 = =C2=A0o =C2=A0New "ACE Groupcomm Parameters" IANA Registry (Secti= on 11.3),
=C2=A0 =C2=A0 =C2=A0 populated with the entries in Section 8.<= br>
=C2=A0 =C2=A0o =C2=A0New "Ace Groupcomm Request Type" IANA= Registry (Section 11.4),
=C2=A0 =C2=A0 =C2=A0 populated with the values= in Section 9.

=C2=A0 =C2=A0o =C2=A0New "ACE Groupcomm Policy&q= uot; IANA Registry (Section 11.7) populated
=C2=A0 =C2=A0 =C2=A0 with tw= o entries "Sequence Number Synchronization Method" and "Key<= br>=C2=A0 =C2=A0 =C2=A0 Update Check Interval" (Section 4.2).

= =C2=A0 =C2=A0o =C2=A0Improved list of requirements for application profiles=
=C2=A0 =C2=A0 =C2=A0 (Appendix A).

B.2.=C2=A0 Version -00 to -01=

=C2=A0 =C2=A0o =C2=A0Changed name of 'req_aud' to 'audi= ence' in the Authorization
=C2=A0 =C2=A0 =C2=A0 Request (Section 3.1= ).




Palombini & Tiloca =C2=A0 =C2=A0 =C2=A0 Expires J= anuary 6, 2020 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 34]=0C
Internet-Draft =C2=A0Key Provisioning for Group Communication =C2= =A0 =C2=A0 =C2=A0 July 2019


=C2=A0 =C2=A0o =C2=A0Defined error h= andling on the KDC (Sections 4.2 and 6.2).

=C2=A0 =C2=A0o =C2=A0Upda= ted format of the Key Distribution Response as a whole
=C2=A0 =C2=A0 =C2= =A0 (Section 4.2).

=C2=A0 =C2=A0o =C2=A0Generalized format of 'p= ub_keys' in the Key Distribution Response
=C2=A0 =C2=A0 =C2=A0 (Sect= ion 4.2).

=C2=A0 =C2=A0o =C2=A0Defined format for the message to req= uest leaving the group
=C2=A0 =C2=A0 =C2=A0 (Section 5.2).

=C2=A0= =C2=A0o =C2=A0Renewal of individual keying material and methods for group<= br>=C2=A0 =C2=A0 =C2=A0 rekeying initiated by the KDC (Section 6).

= =C2=A0 =C2=A0o =C2=A0CBOR type for node identifiers in 'get_pub_keys= 9; (Section 7.1).

=C2=A0 =C2=A0o =C2=A0Added section on parameter id= entifiers and their CBOR keys
=C2=A0 =C2=A0 =C2=A0 (Section 8).

= =C2=A0 =C2=A0o =C2=A0Added request types for requests to a Join Response (S= ection 9).

=C2=A0 =C2=A0o =C2=A0Extended security considerations (Se= ction 10).

=C2=A0 =C2=A0o =C2=A0New IANA registries "ACE Groupc= omm Key Registry", "ACE Groupcomm
=C2=A0 =C2=A0 =C2=A0 Profile= Registry", "ACE Groupcomm Policy Registry" and "Sequen= ce
=C2=A0 =C2=A0 =C2=A0 Number Synchronization Method Registry" (Se= ction 11).

=C2=A0 =C2=A0o =C2=A0Added appendix about requirements fo= r application profiles of ACE
=C2=A0 =C2=A0 =C2=A0 on group communicatio= n (Appendix A).

Acknowledgments

=C2=A0 =C2=A0The following in= dividuals were helpful in shaping this document: Ben
=C2=A0 =C2=A0Kaduk,= John Mattsson, Jim Schaad, Ludwig Seitz, Goeran Selander and
=C2=A0 =C2= =A0Peter van der Stok.

=C2=A0 =C2=A0The work on this document has be= en partly supported by VINNOVA and
=C2=A0 =C2=A0the Celtic-Next project = CRITISEC; and by the EIT-Digital High Impact
=C2=A0 =C2=A0Initiative ACT= IVE.

Authors' Addresses









<= br>Palombini & Tiloca =C2=A0 =C2=A0 =C2=A0 Expires January 6, 2020 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 35]
=0C
Internet-= Draft =C2=A0Key Provisioning for Group Communication =C2=A0 =C2=A0 =C2=A0 J= uly 2019


=C2=A0 =C2=A0Francesca Palombini
=C2=A0 =C2=A0Ericss= on AB
=C2=A0 =C2=A0Torshamnsgatan 23
=C2=A0 =C2=A0Kista =C2=A0SE-1644= 0 Stockholm
=C2=A0 =C2=A0Sweden

=C2=A0 =C2=A0Email: francesca.palombini@ericsson.com=


=C2=A0 =C2=A0Marco Tiloca
=C2=A0 =C2=A0RISE AB
=C2=A0 =C2= =A0Isafjordsgatan 22
=C2=A0 =C2=A0Kista =C2=A0SE-16440 Stockholm
=C2= =A0 =C2=A0Sweden

=C2=A0 =C2=A0Email: marco.tiloca@ri.se




























<= br>




Palombini & Tiloca =C2=A0 =C2=A0 =C2=A0 Expires = January 6, 2020 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 36]<= br>

--000000000000c27be0058d42c726-- From nobody Wed Jul 10 09:23:33 2019 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 AE03F120642; Wed, 10 Jul 2019 09:23:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.105 X-Spam-Level: X-Spam-Status: No, score=-0.105 tagged_above=-999 required=5 tests=[AC_BR_BONANZA=0.001, BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.247, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no 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 47TGHgiwqJcH; Wed, 10 Jul 2019 09:23:18 -0700 (PDT) Received: from mail-vk1-f171.google.com (mail-vk1-f171.google.com [209.85.221.171]) (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 8ECF8120497; Wed, 10 Jul 2019 09:22:46 -0700 (PDT) Received: by mail-vk1-f171.google.com with SMTP id b64so578259vke.13; Wed, 10 Jul 2019 09:22:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=wyoGAZVbjGevFcrUa7kcwV79koOEpYrNJY6kJCRK32E=; b=OPvhP0gZpMJKoeAJjYAwS+i82iNMLFX8Ai+23IAJaiM1GxuGPk8OguxeY8+pQA9dOd fFdTOIFjCns0GrxiYvJLz53oQi7k7RH7iCuKV1F3s8wyQ9GUc8qHpDZKbiugW+4WkifW HGB2WymbBgHTel0mbPtZpU8SFFkTzOmhIaWISAchA8yNoIFTY0GsWIWl9l5Fub4oXHuH T6wrIo+VcSIadL+HSqkYNbMY6x9O9rfoATRfqpsSJvX31njAcNhOGQG6lgYLqiUDxGX5 aR9EDg28dgJObd1qaV8+CPYj4QJ4jPtb+u9fq3wWqQ9Ym+nbcFnqBna0sf9ASBCyQ/gv a8vw== X-Gm-Message-State: APjAAAVYhGSTI1ViMywbhOztWn6MjoZaySyesyCGWOY5a8nFtEa6oDY1 X3r4pR3pqALgCU0l2BuN3WLKiXV1qQ3fVKyB81o= X-Google-Smtp-Source: APXvYqzApp9s06KMcSYRb2UL9sFziRJ5ATBk1Graj1BQwhuqlzasyuCbhEPXd9XBgyiOOYEScqg0nMyHTlzsMKWSne8= X-Received: by 2002:a1f:728b:: with SMTP id n133mr7010031vkc.84.1562775764238; Wed, 10 Jul 2019 09:22:44 -0700 (PDT) MIME-Version: 1.0 References: <009c01d510e9$7eada030$7c08e090$@augustcellars.com> <001001d5118e$aa155290$fe3ff7b0$@augustcellars.com> In-Reply-To: From: Daniel Migault Date: Wed, 10 Jul 2019 12:22:33 -0400 Message-ID: To: Cigdem Sengul Cc: Jim Schaad , draft-ietf-ace-mqtt-tls-profile@ietf.org, ace@ietf.org Content-Type: multipart/alternative; boundary="0000000000004a8428058d5616ad" Archived-At: Subject: Re: [Ace] Comments on draft-ietf-ace-mqtt-tls-profile 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, 10 Jul 2019 16:23:32 -0000 --0000000000004a8428058d5616ad Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, Please find my in line comments on the current draft 00. These are indicated as . Yours, Daniel ACE Working Group C. Sengul Internet-Draft Nominet Intended status: Standards Track A. Kirby Expires: November 8, 2019 Oxbotica P. Fremantle University of Portsmouth May 7, 2019 MQTT-TLS profile of ACE draft-ietf-ace-mqtt-tls-profile-00 Abstract This document specifies a profile for the ACE (Authentication and Authorization for Constrained Environments) to enable authorization in an MQTT-based publish-subscribe messaging system. Proof-of- possession keys, bound to OAuth2.0 access tokens, are used to authenticate and authorize publisher and subscriber clients. The protocol relies on TLS for confidentiality and server authentication. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on November 8, 2019. Copyright Notice Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect Sengul, et al. Expires November 8, 2019 [Page 1] Internet-Draft MQTT-TLS profile of ACE May 2019 to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 1.2. ACE-Related Terminology . . . . . . . . . . . . . . . . . 4 1.3. MQTT-Related Terminology . . . . . . . . . . . . . . . . 4 2. Basic Protocol Interactions . . . . . . . . . . . . . . . . . 5 2.1. Authorizing Connection Establishment . . . . . . . . . . 6 2.1.1. Client Authorization Server (CAS) and Authorization Server (AS) Interaction . . . . . . . . . . . . . . . 7 2.1.2. Client Connection Request to the Broker . . . . . . . 8 2.1.3. Token Validation . . . . . . . . . . . . . . . . . . 10 2.1.4. The Broker's Response to Client Connection Request . 11 2.2. Authorizing PUBLISH Messages . . . . . . . . . . . . . . 12 2.2.1. PUBLISH Messages from the Publisher Client to the Broker . . . . . . . . . . . . . . . . . . . . . . . 12 2.2.2. PUBLISH Messages from the Broker to the Subscriber Clients . . . . . . . . . . . . . . . . . . . . . . . 12 2.3. Authorizing SUBSCRIBE Messages . . . . . . . . . . . . . 13 2.4. Token Expiration . . . . . . . . . . . . . . . . . . . . 13 2.5. Handling Disconnections and Retained Messages . . . . . . 13 3. Improved Protocol Interactions with MQTT v5 . . . . . . . . . 14 3.1. Token Transport via Authentication Exchange (AUTH) . . . 14 3.2. Authorization Errors and Client Re-authentication . . . . 16 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 5. Security Considerations . . . . . . . . . . . . . . . . . . . 17 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 18 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 7.1. Normative References . . . . . . . . . . . . . . . . . . 18 7.2. Informative References . . . . . . . . . . . . . . . . . 19 Appendix A. Checklist for profile requirements . . . . . . . . . 20 Appendix B. The Authorization Information Endpoint . . . . . . . 21 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 1. Introduction This document specifies a profile for the ACE framework [I-D.ietf-ace-oauth-authz]. In this profile, clients and a resource server use MQTT to communicate. The protocol relies on TLS for communication security between entities. The basic protocol interactions follow MQTT v3.1.1 - the OASIS Standard [MQTT-OASIS-Standard]. In addition, this document describes Sengul, et al. Expires November 8, 2019 [Page 2] Internet-Draft MQTT-TLS profile of ACE May 2019 improvements to the basic protocol with the new MQTT v5.0 - the OASIS Standard [MQTT-OASIS-Standard-v5] (e.g., improved authentication exchange and error reporting). Both versions are expected to be supported in practice, and therefore, covered in this document. I understand that the basic protocol refers to MQTTv3.3.1.1 It might be clearer to explicitly mention that MQTT v3.1.1 is the basic protocol. The other way around could be to remove to the basis protocol" in the latest sentence. Probably that my missing background on MQTT, but -at least for my personnal knowledge - I believe that some clarification over the support of the v5 and v3.1.1 could be clarified. When support for both version is mentioned, I am wondering if this documents mandate that any RS implements both v3.1.1 AND v5 or if it states that v3.1.1 is by no way being sunset. In other words, it is envisioned that some system will use v3.1.1 *for ever* in which case their associated is expected to support v3.1.1. The same will occur for v5 respectively. Another alternative could be that MQTTv5 adds functionalities to v3.1.1, leading to some sort of backward compatibility that are sufficient in most cases. MQTT is a publish-subscribe protocol and supports two main types of client operation: publish and subscribe. Once connected, a client can publish to multiple topics, and subscribe to multiple topics; however, for this document, these actions are described separately. The MQTT broker is responsible for distributing messages published by the publishers to the appropriate subscribers. Each publish message contains a topic, which is used by the broker to filter the subscribers for the message. Subscribers must subscribe to the topics to receive the corresponding messages. In this document, message topics are treated as resources. Clients use an access token, bound to a key (the proof-of-possession key) to authorize with the MQTT broker their connection and publish/subscribe permissions to topics. In the context of this ACE profile, the MQTT broker acts as the resource server. To provide communication confidentiality and resource server authentication, TLS is used. Clients use client authorization servers [I-D.ietf-ace-actors] to obtain tokens from the authorization server. The communication protocol between the client authorization server and the authorization server is assumed to be HTTPS. Also, if the broker supports token introspection, it is assumed to use HTTPS to communicate with the authorization server. These interfaces MAY be implemented using other protocols, e.g., CoAP or MQTT. I have the impression that the proposed alternatives are unsecured. I am wondering if that is intentional. I believe that these communications needs to be secured appropriately. My understanding is that MQTT will work on top of TCP/TLS. If that is correct, I am wondering if it is envisioned that a full HTTP client is embedded into small motes, or a minimal library restricted to support the interaction with the AS. The reason I am asking this question is related to a discussion we had in homenet, so that is only for my personal knowledge and unrelated to MQTT. This document makes the same assumptions as the Section 4 of the ACE framework [I-D.ietf-ace-oauth-authz] regarding client and RS registration with the AS and establishing of keying material. This document describes the authorization of the following exchanges between publisher and subscriber clients, and the broker. o Connection establishment between the clients and the broker o Publish messages from the publishers to the broker, and from the broker to the subscribers o Subscribe messages from the subscribers to the broker In Section 2, these exchanges are described based on the MQTT v3.1.1 - the OASIS Standard [MQTT-OASIS-Standard]. These exchanges are also supported by the new MQTT v5 - the OASIS Standard [MQTT-OASIS-Standard-v5]. Section 3 describes how they may be improved by the new MQTT v5. Sengul, et al. Expires November 8, 2019 [Page 3] Internet-Draft MQTT-TLS profile of ACE May 2019 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174], when, and only when, they appear in all capitals, as shown here. 1.2. ACE-Related Terminology The terminology for entities in the architecture is defined in OAuth 2.0 RFC 6749 [RFC6749] and ACE actors [I-D.ietf-ace-actors], such as "Client" (C), "Resource Server" (RS) and "Authorization Server" (AS). The term "endpoint" is used following its OAuth definition, to denote resources such as /token and /introspect at the AS. The term "Resource" is used to refer to an MQTT "topic name," which is defined in Section 1.3. Hence, the "Resource Owner" is any entity that can authoritatively speak for the "topic". scetion 1.3 defines the Topic name. It might be more helpful to the reader if the exact same term is used both in the text of the document and in the terminology - that is even considering upper/lower letters. I am wondering if broker should be defined as well. Similarly, there seems that Clients are composed of various sub clients ( client authorisation server, client (MQTT), subscriber, publisher). Maybe these different designation could be defined as well in the terminology section. Maybe also some designations might not be necessary to introduce. Certain security-related terms such as "authentication", "authorization", "confidentiality", "(data) integrity", "message authentication code", and "verify" are taken from RFC 4949 [RFC4949]. 1.3. MQTT-Related Terminology The document describes message exchanges as MQTT protocol interactions. For additional information, please refer to the MQTT v3.1.1 - the OASIS Standard [MQTT-OASIS-Standard] or the MQTT v5 - the OASIS Standard [MQTT-OASIS-Standard-v5]. Topic name The label attached to an application message, which is matched to a subscription. Topic filter An expression that indicates interest in one or more topic names. Topic filters may include wildcards. Subscription A subscription comprises a Topic filter and a maximum quality of service (QoS). I am wondering why the subscription does not consider the identity(ies), location(s) of the subscriber(s). I the reason that this parameters are define over an established session, which in the case of MQTT is TCP/TLS. I also suspect there is a MQTT session handling subscribers, publisher connectivity. Application Message The data carried by the MQTT protocol. The data has an associated QoS level and a Topic name. Sengul, et al. Expires November 8, 2019 [Page 4] Internet-Draft MQTT-TLS profile of ACE May 2019 MQTT sends various control messages across a network connection. The following is not an exhaustive list and the control packets that are not relevant for authorization are not explained. These include, for instance, the PUBREL and PUBCOMP packets used in the 4-step handshake required for the QoS level 2. CONNECT Client request to connect to the broker. After a network connection is established, this is the first packet sent by a client. CONNACK The broker connection acknowledgment. The first packet sent from the broker to a client is a CONNACK packet. CONNACK packets contain return codes indicating either a success or an error state to a client. PUBLISH Publish packet that can be sent from a client to the broker, or from the broker to a client. PUBACK Response to PUBLISH packet with QoS level 1. PUBACK can be sent from the broker to a client or a client to the broker. PUBREC Response to PUBLISH packet with QoS level 2. PUBREC can be sent from the broker to a client or a client to the broker. SUBSCRIBE The client subscribe request. SUBACK Subscribe acknowledgment. PINGREQ A ping request sent from a client to the broker. It signals to the broker that the client is alive, and is used to confirm that the broker is still alive. 2. Basic Protocol Interactions This section describes the following exchanges between publisher and subscriber clients, the broker, and the authorization server according to the MQTT v3.1.1 - the OASIS Standard [MQTT-OASIS-Standard]. These exchanges are compatible also with the new MQTT v5 - the OASIS Standard [MQTT-OASIS-Standard-v5]. In addition, Section 3 describes how these exchanges may be improved with the MQTT v5. Sengul, et al. Expires November 8, 2019 [Page 5] Internet-Draft MQTT-TLS profile of ACE May 2019 o Authorizing connection establishment between the clients and the broker o Authorizing publish messages from the publishers to the broker, and from the broker to the subscribers o Authorizing subscribe messages from the subscribers to the broker Message topics are treated as resources. The publisher and subscriber clients are assumed to have identified the topics of interest out-of-band (topic discovery is not a feature of the MQTT protocol). A connection request carries a token specifying the permissions that the client has (e.g., publish permission to a given topic). A resource owner can pre-configure policies at the AS that give clients publish or subscribe permissions to different topics. 2.1. Authorizing Connection Establishment This section specifies how publishers and subscribers establish an authorized connection to an MQTT broker. The token request and response use the /token endpoint of the authorization server, as specified in Section 5 of the ACE framework [I-D.ietf-ace-oauth-authz]. Figure 1 shows the basic protocol flow during connection establishment. The step (C), client onboarding, is out of the scope of this document. Steps (E) and (F) are optional. Sengul, et al. Expires November 8, 2019 [Page 6] Internet-Draft MQTT-TLS profile of ACE May 2019 +----------------+ +---(A) Token request----| Client | | | Authorization | | +-(B) Access token-->| Server | | | |________________| | | | | | (C) Client On-boarding | | | | | +---------v-----+ +--v-------------+ | Publisher or | | | | Subscriber | | Authorization | |_______________| | Server | | ^ |________________| | | | ^ (D)Connection (G)Connection | | request + response | | access token | | | | | | | +---v--------------+ | | | Broker | | +(E)Introspection-| Resource Server | | request (optional) | | +-(F)Introspection---->|__________________| response (optional) Figure 1: Connection establishment 2.1.1. Client Authorization Server (CAS) and Authorization Server (AS) Interaction The first step in the protocol flow (Figure 1 (A)) is the token acquisition by the client authorization server (CAS) from the AS. If a client has enough resources and can support HTTPS, or optionally the AS supports MQTTS, these steps can instead be carried out by a client directly. MQTTS and CAS should in my opinion be mentioned in the terminology section. "optionally" might be clarified further. The introduction mentioned HTTPS was considered as the supported protocol. but it seems here that the support of HTTPS may not be obvious, in which case the support of MQTTS might be RECOMMENDED/SHOULD or even stronger. The recommendation may also be associated to current deployments, especially concerning how AS are dedicated to a technology or not. I do not see strong recommendations for the AS to support one specific protocol, so I believe clarification/discussions on MQTTS / HTTPS should be provided in the document. """ other underlying protocols are not prohibited from being supported in the future, such as HTTP/2, MQTT, BLE and QUIC. """ When requesting an access token from the AS, the CAS MAY include parameters in its request as defined in Section 5.6.1 of the ACE framework [I-D.ietf-ace-oauth-authz]. The content type is set to "application/json". The profile parameter is set to 'mqtt_tls'. If the AS successfully verifies the access token request and authorizes the client for the indicated audience (e.g., RS) and scopes (e.g., publish/subscribe permissions over topics), the AS issues an access token (Figure 1 (B)). The response includes the parameters described in Section 5.6.2 of the ACE framework [I-D.ietf-ace-oauth-authz]. The included token is assumed to be Proof-of-Possession (PoP) token by default. Hence, a 'cnf' parameter Sengul, et al. Expires November 8, 2019 [Page 7] Internet-Draft MQTT-TLS profile of ACE May 2019 with a symmetric or asymmetric PoP key is returned. The token may be a reference, or a CBOR or JWT web token. Note that the 'cnf' parameter in the web tokens are to be consumed by the resource server and not the client. For more information on Proof of Possession semantics in JWTs see RFC 7800 [RFC7800] and for CWTs, see Proof-of- Possession Key Semantics for CBOR Web Tokens (CWTs) [I-D.ietf-ace-cwt-proof-of-possession]. In the case of an error, the AS returns error responses for HTTP- based interactions as ASCII codes in JSON content, as defined in Section 5.2 of RFC 6749 [RFC6749]. 2.1.2. Client Connection Request to the Broker Once the client acquires the token, it can use it to request an MQTT connection to the broker over a TLS session with server authentication (Figure 1 (D)). This section describes the client transporting the token to the broker (RS) via the CONNECT control message after the TLS handshake. This is similar to an earlier proposal by Fremantle et al. [fremantle14]. An improvement to this is presented in Section 3 for the MQTT v5 - the OASIS Standard [MQTT-OASIS-Standard-v5]. I believe the description of the improvement has been omitted. It woudl help the reader to get an overview of the improvement. Alternatively, the token may be used for the TLS session establishment as described in the DTLS profile for ACE [I-D.gerdes-ace-dtls-authorize]. In this case, both the TLS PSK and RPK handshakes MAY be supported. This may additionally require that the client transports the token to the broker before the connection establishment. To this end, the broker MAY support /authz-info endpoint via the "authz-info" topic. Then, to transport the token, clients publish to "authz-info" topic unauthorized. The topic "authz-info" MUST be publish-only for clients (i.e., the clients are not allowed to subscribe to it). This option is described in more detail in Appendix B. When the client wishes to connect to the broker, it uses the CONNECT message of MQTT. Figure 2 shows the structure of the MQTT CONNECT control message. Sengul, et al. Expires November 8, 2019 [Page 8] Internet-Draft MQTT-TLS profile of ACE May 2019 0 8 16 24 32 +------------------------------------------------------+ |CPT=3D1 | Rsvd.|Remaining len.| Protocol name len. =3D 4 | +------------------------------------------------------+ | 'M' 'Q' 'T' 'T' | +------------------------------------------------------+ | Proto.level=3D4|Connect flags| Keep alive | +------------------------------------------------------+ | Payload | | Username as access token (UTF-8) | | Password length (2 Bytes) | | Password data as signature/MAC (binary) | | ... | +------------------------------------------------------+ Figure 2: MQTT CONNECT control message. (CPT=3DControl Packet Type, Rsvd=3DReserved, len.=3Dlength, Proto.=3DProtocol) To communicate the necessary connection parameters, the Client uses the appropriate flags of the CONNECT message. Figure 3 shows how the MQTT connect flags MUST be set to initiate a connection with the broker. +-----------------------------------------------------------+ |User name|Pass.|Will retain|Will QoS|Will Flag|Clean| Rsvd.| | flag |flag | | | | | | +-----------------------------------------------------------+ | 1 | 1 | X | X X | X | 1 | 0 | +-----------------------------------------------------------+ Figure 3: MQTT CONNECT flags. (Rsvd=3DReserved) To ensure that the client and the broker discard any previous session and start a new session, the Clean Session Flag MUST be set to 1. The Will flag indicates that a Will message needs to be sent when a client disconnection occurs. The situations in which the Will message is published include disconnections due to I/O or network failures, and the server closing the networking connection due to a protocol error. The client may set the Will flag as desired (marked as 'X' in Figure 3). If the Will flag is set to 1 and the broker accepts the connection request, the broker must store the Will message, and publish it when the network connection is closed according to Will QoS and Will retain parameters, and MQTT Will management rules. Section 2.5 explains how the broker deals with the retained messages in further detail. Figure mentions Will Flag while the text mentions Will flag. >From the paragraph, I cannot figure out what a Will message is. Maybe that could be explained or a reference to it may be indicated. Sengul, et al. Expires November 8, 2019 [Page 9] Internet-Draft MQTT-TLS profile of ACE May 2019 Finally, Username and Password flags MUST be set to 1 to ensure that the Payload of the CONNECT message includes both Username and Password fields. The CONNECT message defaults to ACE for authentication and authorization. For the basic operation described in this section, the Username field MUST be set to the access token. The Password field MUST be set to the keyed message digest (MAC) or signature associated with the access token for proof-of-possession. The client MAY apply the PoP key either to the entire request by computing a keyed message digest (for symmetric key) or a digital signature (for asymmetric key). The CONNECT message is assumed to have enough randomness in the payload, and inside a TLS session (excluding the 0-RTT case) will not be exposed to a replay attack. When either cannot be guaranteed, the Password MAY also contain a nonce. Section 3.1.3 of MQTT v3.1.1 - the OASIS Standard [MQTT-OASIS-Standard] defines the MQTT Username as a UTF-8 encoded string, which is prefixed by a 2-byte length field followed by UTF-8 encoded character data up to 65535 bytes. Therefore an access token that is not a valid UTF-8 MUST be Base64 [RFC4648] encoded. (The MQTT Password allows binary data up to 65535 bytes, and so, does not require encoding.) 2.1.3. Token Validation RS MUST verify the validity of the token. This validation MAY be done locally (e.g., in the case of a self-contained token) or the RS MAY send an introspection request to the AS. If introspection is used, this section follows similar steps to those described in Sections 5.7 of the ACE framework [I-D.ietf-ace-oauth-authz]. The communication between AS and RS MAY be HTTPS, but it, in every case, MUST be confidential, mutually authenticated and integrity protected. The broker MUST check if the token is active either using 'exp' claim of the token or 'active' parameter of the introspection response. The access token is constructed by the AS such that RS can associate the access token with the client key. This document assumes that the Access Token is a PoP token as described in [I-D.ietf-ace-oauth-authz]. Therefore, the necessary information is contained in the 'cnf' claim of the access token and may use either public or shared key approaches. The client uses the signature or the MAC in the password field to prove the possession of the key. The resource server validates the signature or the MAC over the contents of the packet, authenticating the client. Sengul, et al. Expires November 8, 2019 [Page 10] Internet-Draft MQTT-TLS profile of ACE May 2019 The broker uses the scope field in the token (or in the introspection result) to determine the publish and subscribe permissions for the client. If the Will flag is set, then the broker MUST check that the token allows the publication of the Will message too. If the token is not self-contained and the broker uses token introspection, it MAY cache the validation result to decide whether to accept subsequent PUBLISH and SUBSCRIBE messages as these messages, which are sent after a connection set-up, do not contain access tokens. If the introspection result is not cached, then the RS needs to introspect the saved token for each request. Scope strings SHOULD be encoded as a permission, followed by an underscore, followed by a topic filter. Two permissions apply to topics: 'publish' and 'subscribe'. An example scope field may contain multiple such strings, space delimited, e.g., 'publish_topic1 subscribe_topic2/#'. Hence, this access token would give 'publish' permission to the 'topic1', 'subscribe' permission to all the subtopics of 'topic2'. Also, if present in the access token, RS must check that the 'iss' corresponds to AS, the 'aud' field (if not used to define topics) corresponds to RS. It also has to check whether 'nbf' and 'iat' claims are present and valid. 2.1.4. The Broker's Response to Client Connection Request Based on the validation result (obtained either via local inspection or using the /introspection interface of the AS), the broker MUST send a CONNACK message to the client. The broker responses may follow either the MQTT v3.1.1 - the OASIS Standard [MQTT-OASIS-Standard] or the MQTT v5 - the OASIS Standard [MQTT-OASIS-Standard-v5], depending on which version(s) the broker supports. I believe that references to MQTTv3.1.1 and MQTTv5 provided in the introduction are sufficient, and there is no need to have teh reference anytime MQTT is invoked. In MQTT v3.1.1 - the OASIS Standard [MQTT-OASIS-Standard], it is not possible to support AS discovery via sending a tokenless CONNECT message to the broker. This is because a CONNACK packet does not include a means to provide additional information to the client. Therefore, AS discovery needs to take place out-of-band. This is remedied in the MQTT v5 - the OASIS Standard [MQTT-OASIS-Standard-v5] and a solution is described in Section 3. If the RS accepts the connection, it MUST store the token. Sengul, et al. Expires November 8, 2019 [Page 11] Internet-Draft MQTT-TLS profile of ACE May 2019 2.2. Authorizing PUBLISH Messages 2.2.1. PUBLISH Messages from the Publisher Client to the Broker On receiving the PUBLISH message, the broker MUST use the type of message (i.e., PUBLISH) and the topic name in the message header to compare against the cached token or its introspection result. If the client is allowed to publish to the topic, the RS must publish the message to all valid subscribers of the topic. The broker may also return an acknowledgment message if the QoS level is greater than or equal to 1. In case of a failure, it is not possible to return an error in MQTT v3.1.1 - the OASIS Standard [MQTT-OASIS-Standard]. Acknowledgement messages only indicate success. In the case of an authorization error, the broker SHOULD disconnect the client. Otherwise, it MUST ignore the PUBLISH message. Also, DISCONNECT messages are only sent from a client to the broker. So, server disconnection needs to take place below the application layer. However, in MQTT v5 - the OASIS Standard [MQTT-OASIS-Standard-v5], it is possible to indicate failure and provide a reason code. Section 3 describes in more detail how MQTT v5 handles PUBLISH authorization errors. 2.2.2. PUBLISH Messages from the Broker to the Subscriber Clients To forward PUBLISH messages to the subscribing clients, the broker identifies all the subscribers that have valid matching topic subscriptions (i.e., the tokens are valid, and token scopes allow a subscription to the particular topic name). The broker sends a PUBLISH message with the topic name and the topic message to all the valid subscribers. In MQTT, after connection establishment, there is no way to inform a client that an authorization error has occurred for previously subscribed topics, e.g., token expiry. In the case of an authorization error, the broker disconnects the client. In the MQTT v3.1.1 - the OASIS Standard [MQTT-OASIS-Standard], the MQTT DISCONNECT messages are only sent from a client to the broker. Therefore, the server disconnection needs to take place below the application layer. In MQTT v5 - the OASIS Standard [MQTT-OASIS-Standard-v5], a server-side DISCONNECT message is possible and described in Section 3. Sengul, et al. Expires November 8, 2019 [Page 12] Internet-Draft MQTT-TLS profile of ACE May 2019 2.3. Authorizing SUBSCRIBE Messages In MQTT, a SUBSCRIBE message is sent from a client to the broker to create one or more subscriptions to one or more topics. The SUBSCRIBE message may contain multiple topic filters. The topic filters may include wildcard characters. On receiving the SUBSCRIBE message, the broker MUST use the type of message (i.e., SUBSCRIBE) and the topic filter in the message header to compare against the stored token or introspection result. As a response to the SUBSCRIBE message, the broker issues a SUBACK message. For each topic filter, the SUBACK packet includes a return code matching the QoS level for the corresponding topic filter. In the case of failure, the return code, in MQTT v3.1.1, must be 0x80 indicating 'Failure'. In MQTT v5, the appropriate return code is 0x87, indicating that the client is 'Not authorized'. Note that, in both MQTT versions, a reason code is returned for each topic filter. Therefore, the client may receive success codes for a subset of its topic filters, while being unauthorized for the rest. 2.4. Token Expiration The broker MUST check for token expiration whenever a CONNECT, PUBLISH or SUBSCRIBE message is received or sent. The broker SHOULD check for token expiration on receiving a PINGREQUEST message. This may allow for early detection of a token expiry. The token expiration is checked by checking the 'exp' claim of a CWT/ JWT or via performing an introspection request with the Authorization server as described in Section 5.7 of the ACE framework [I-D.ietf-ace-oauth-authz]. In the basic operation, token expirations MAY lead to disconnecting the associated client. However, in MQTT v5 - the OASIS Standard [MQTT-OASIS-Standard-v5], better error handling and re-authentication are possible. This is explained in more detail in Section 3. 2.5. Handling Disconnections and Retained Messages According to MQTT v3.1.1 - the OASIS Standard [MQTT-OASIS-Standard], only Client DISCONNECT messages are allowed. In MQTT v5 - the OASIS Standard [MQTT-OASIS-Standard-v5], server-side DISCONNECT messages are possible, allowing to return '0x87 Not Authorized' return code to the client. In the case of a DISCONNECT, due to the Clean Session flag, the broker deletes all session state but MUST keep the retained messages. By setting a RETAIN flag in a PUBLISH message, the publisher Sengul, et al. Expires November 8, 2019 [Page 13] Internet-Draft MQTT-TLS profile of ACE May 2019 indicates to the broker that it should store the most recent message for the associated topic. Hence, the new subscribers can receive the last sent message from the publisher for that particular topic without waiting for the next PUBLISH message. In the case of a disconnection, the broker MUST continue publishing the retained messages as long as the associated tokens are valid. In case of disconnections due to network errors or server disconnection due to a protocol error (which includes authorization errors), the Will message must be sent if the client supplied a Will in the CONNECT request message. The token provided in the CONNECT request must cover the Will topic. The Will message MUST be published to the Will topic when the network connection is closed regardless of whether the corresponding token has expired. 3. Improved Protocol Interactions with MQTT v5 In the new MQTT v5 - the OASIS Standard [MQTT-OASIS-Standard-v5], several new capabilities are introduced, which enable better integration with ACE. The newly enhanced authentication and re- authentication methods support a wider range of authentication flows beyond username and password. With the MQTT v5, there is a clearly defined approach for using token-based authorization. Also, it is possible for a client to request a re-authentication avoiding disconnection. Finally, MQTT v5 generally improves error reporting, enabling better response to authorization failures during publishing messages to the subscribers. Given that MQTT provides a better integration with ACE, I am wondering if MQTTv5 should not be considered as the primary description and having MQTT3.1.1 related to legacy MQTT. This is seems to me simply re-ordering th= e sections. However, the message carried would be to move to MQTTv5 when possible. I also believe that a recommendation on supporting MQTTv5 should me made in the document. 3.1. Token Transport via Authentication Exchange (AUTH) To initiate the authentication and authorization flow, as before, the CAS initiates the token request as in Section 2.1. When the client wishes to connect to the RS (broker), it uses the CONNECT message of MQTT. Figure 4 shows the structure of the MQTT CONNECT control message used in MQTT v5. Sengul, et al. Expires November 8, 2019 [Page 14] Internet-Draft MQTT-TLS profile of ACE May 2019 0 8 16 24 32 +------------------------------------------------------+ |CPT=3D1 | Rsvd.|Remaining len.| Protocol name len. =3D 4 | +------------------------------------------------------+ | 'M' 'Q' 'T' 'T' | +------------------------------------------------------+ | Proto.level=3D5|Connect flags| Keep alive | +------------------------------------------------------+ | Property length | | Auth. Method (0x15) | 'ace' | | Auth. Data (0x16) | empty or token or | | token + PoP data | +------------------------------------------------------+ Figure 4: MQTT CONNECT control message. (CPT=3DControl Packet Type, Rsvd=3DReserved, len.=3Dlength, Proto.=3DProtocol) To communicate the necessary connection parameters, the client uses the appropriate flags of the CONNECT message. To achieve a clean session (i.e., the session should start without an existing session), the new MQTT v5 session flags MUST be set appropriately: the Clean Start Flag MUST be set to 1 and Session Expiry Interval MUST be set to 0. With the enhanced authentication capabilities, it is not necessary to overload the username and password fields in the CONNECT message for ACE authentication. Nevertheless, the RS MUST support both methods for supporting the token: (1) Token transport via username and password and (2) using the new AUTH (Authentication Exchange) method. The token transport via username and password is as described in Section 2.1.2. The rest of this section describes the AUTH method. As mentioned before, it might be better to mention what to do and explain in MQTT why we overload the username/password. To use the AUTH method, the username flag MUST be set to 0, and the password flag MUST be set to 0. The client can set the Authentication Method as a property of a CONNECT packet by setting Auth Properties (with the property identifier 0x15). The client must MUST set the UTF-8 encoded string containing the name of the authentication method as 'ace'. If the RS does not support this profile, it sends a CONNACK with a Reason Code of '0x8C (Bad authentication method)' The Authentication Method is followed by the Authentication Data, which has a property identifier 0x16. Authentication data is binary data and is defined by the authentication method. The RS MAY support different implementations for transporting the authentication data. The first option is that Authentication data contains both the token and the keyed message digest (MAC) or signature as described in Section 2.1.2. The encoding of this field MAY use CBOR and COSE. In Sengul, et al. Expires November 8, 2019 [Page 15] Internet-Draft MQTT-TLS profile of ACE May 2019 this case, the token validation proceeds as described in Section 2.1.3 and the server responds with a CONNACK. The reason code of the CONNACK is '0x00 (Success)' if the authentication is successful. In case of an invalid PoP token, the CONNACK reason code is '0x87 (Not Authorized)'. The second option that RS may accept is a challenge/response protocol. If the Authentication Data only includes the token, the RS MUST respond with an AUTH packet, with the Authenticate Reason Code set to '0x18 (Continue Authentication)'. This packet includes the Authentication Method, which MUST be set to 'ace' and Authentication Data. The Authentication Data MUST NOT be empty and contains a challenge for the client. The client responds to this with an AUTH packet, with a reason code '0x18 (Continue Authentication)'. Similarly, the client packet sets the Authentication Method to 'ace'. The Authentication Data in the client's response contains the signature or MAC computed over the RS's challenge. To this, the server responds with a CONNACK and return code '0x00 (Success)' if the authentication is successful. In case of an invalid PoP token, the CONNACK reason code is '0x87 (Not Authorized)'. Finally, this document allows the CONNECT message to have an empty Authentication Data field. This is the AS discovery option and the RS responds with the CONNACK reason code '0x87 (Not Authorized)' and includes a User Property for the AS information. AS Information contains the absolute URI of AS, and MAY also contain a cnonce as described in the Section 5.1 of the ACE framework [I-D.ietf-ace-oauth-authz]. This information MAY be CBOR encoded. 3.2. Authorization Errors and Client Re-authentication MQTT v5 allows better error reporting. To take advantage of this for PUBLISH messages, the QoS level should be set to greater than or equal to 1. This guarantees that RS responds with either a PUBACK or PUBREC packet with reason code '0x87 (Not authorized)' in the case of an authorization error. Similarly, for the SUBSCRIBE case, the SUBACK packet has a reason code set to '0x87 (Not authorized)' for the unauthorized topic(s). When RS is forwarding PUBLISH messages to the subscribed clients, it may discover that some of the subscribers are no more authorized due to expired tokens. In this case, the RS SHOULD send a DISCONNECT message with the reason code '0x87 (Not authorized)'. Note that the server-side DISCONNECT is a new feature of MQTT v5 (in MQTT v3.1.1, the server needed to drop the connection). RS MUST stop forwarding messages to the unauthorized subscribers. In the case of a PUBACK with '0x87 (Not authorized)', the client can update its token using the Re-authentication feature of MQTT v5. Sengul, et al. Expires November 8, 2019 [Page 16] Internet-Draft MQTT-TLS profile of ACE May 2019 Also, the clients can proactively update their tokens without waiting for such a PUBACK. To re-authenticate, the client sends an AUTH packet with reason code '0x19 (Re-authentication)'. The client MUST set the authentication method as 'ace' and transport the new token in the Authentication Data. The client and the RS go through the same steps for proof of possession validation as described in the previous section. If the re-authentication fails, the server MUST send a DISCONNECT with the reason code '0x87 (Not Authorized)'. 4. IANA Considerations The following registrations are done for the ACE OAuth Profile Registry following the procedure specified in [I-D.ietf-ace-oauth-authz]. Note to the RFC editor: Please replace all occurrences of "[RFC- XXXX]" with the RFC number of this specification and delete this paragraph. Profile name: mqtt_tls Profile description: Profile for delegating client authentication and authorization using MQTT as the application protocol and TLS For transport layer security. Profile ID: Change controller: IESG Reference: [RFC-XXXX] 5. Security Considerations This document specifies a profile for the Authentication and Authorization for Constrained Environments (ACE) framework [I-D.ietf-ace-oauth-authz]. Therefore, the security considerations outlined in [I-D.ietf-ace-oauth-authz] apply to this work. In addition, the security considerations outlined in MQTT v3.1.1 - the OASIS Standard [MQTT-OASIS-Standard] and MQTT v5 - the OASIS Standard [MQTT-OASIS-Standard-v5] apply. Mainly, this document provides an authorization solution for MQTT, the responsibility of which is left to the specific implementation in MQTT v5 - the OASIS Standard [MQTT-OASIS-Standard-v5]. In the following, we comment on a few relevant issues based on the current MQTT specifications. In this document, RS uses the PoP access token to authenticate the client. If the client is able, TLS certificates sent from the client Sengul, et al. Expires November 8, 2019 [Page 17] Internet-Draft MQTT-TLS profile of ACE May 2019 can be used by the RS to authenticate the client. The TLS certificate from the RS MUST be used by the client to authenticate the RS. To authorize a client's publish and subscribe requests in an ongoing session, the RS caches the access token after accepting the connection from the client. However, if some permissions are revoked in the meantime, the RS may still grant publish/subscribe to revoked topics until the session ends or the token expires. When permissions change dynamically, it is expected that AS follows a reasonable expiration strategy for the access tokens. The RS may monitor client behaviour to detect potential security problems, especially those affecting availability. These include repeated token transfer attempts to the public "authz-info" topic, repeated connection attempts, abnormal terminations, and clients that connect but do not send any data. If the RS supports the public "authz-info" topic, described in Appendix B, then this may be vulnerable to a DDoS attack, where many clients use the "authz-info" public topic to transport fictitious tokens, which RS may need to store indefinitely. 6. Privacy Considerations The privacy considerations outlined in [I-D.ietf-ace-oauth-authz] apply to this work. In MQTT, the RS is a central trusted party and may forward potentially sensitive information between clients. Clients may choose to encrypt the payload of their messages. However, this would not provide privacy for other properties of the message such as topic name. 7. References 7.1. Normative References [I-D.gerdes-ace-dtls-authorize] Gerdes, S., Bergmann, O., Bormann, C., Selander, G., and L. Seitz, "Datagram Transport Layer Security (DTLS) Profile for Authentication and Authorization for Constrained Environments (ACE)", draft-gerdes-ace-dtls- authorize-01 (work in progress), March 2017. Sengul, et al. Expires November 8, 2019 [Page 18] Internet-Draft MQTT-TLS profile of ACE May 2019 [I-D.ietf-ace-oauth-authz] Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and H. Tschofenig, "Authentication and Authorization for Constrained Environments (ACE) using the OAuth 2.0 Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-24 (work in progress), March 2019. [MQTT-OASIS-Standard] Banks, A., Ed. and R. Gupta, Ed., "OASIS Standard MQTT Version 3.1.1 Plus Errata 01", 2015, . [MQTT-OASIS-Standard-v5] Banks, A., Ed., Briggs, E., Ed., Borgendale, K., Ed., and R. Gupta, Ed., "OASIS Standard MQTT Version 5.0", 2017, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 7.2. Informative References [fremantle14] Fremantle, P., Aziz, B., Kopecky, J., and P. Scott, "Federated Identity and Access Management for the Internet of Things", research International Workshop on Secure Internet of Things, September 2014, . [I-D.ietf-ace-actors] Gerdes, S., Seitz, L., Selander, G., and C. Bormann, "An architecture for authorization in constrained environments", draft-ietf-ace-actors-07 (work in progress), October 2018. Sengul, et al. Expires November 8, 2019 [Page 19] Internet-Draft MQTT-TLS profile of ACE May 2019 [I-D.ietf-ace-cwt-proof-of-possession] Jones, M., Seitz, L., Selander, G., Erdtman, S., and H. Tschofenig, "Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs)", draft-ietf-ace-cwt-proof-of- possession-06 (work in progress), February 2019. [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, . [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, . [RFC7800] Jones, M., Bradley, J., and H. Tschofenig, "Proof-of- Possession Key Semantics for JSON Web Tokens (JWTs)", RFC 7800, DOI 10.17487/RFC7800, April 2016, . Appendix A. Checklist for profile requirements o AS discovery: For the basic protocol using either MQTT v3.1.1 or MQTT v5, the clients/client authorization servers need to be configured out-of-band. RS does not provide any hints to help AS discovery. AS discovery is possible with the MQTT v5 extensions described in Section 3. o The communication protocol between the client and RS: MQTT o The security protocol between the client and RS: TLS o Client and RS mutual authentication: RS provides a server certificate during TLS handshake. Client transports token and MAC via the MQTT CONNECT message. Other methods for transporting the token with the MQTT v5 extensions described in Section 3. o Content format: For the HTTPS interactions with AS, "application/ json". The MQTT payloads may be formatted JSON or CBOR. o PoP protocols: Either symmetric or asymmetric keys can be supported. o Unique profile identifier: mqtt_tls o Token introspection: RS uses HTTPS /introspect interface of AS. o Token request: CAS uses HTTPS /token interface of AS. Sengul, et al. Expires November 8, 2019 [Page 20] Internet-Draft MQTT-TLS profile of ACE May 2019 o /authz-info endpoint: It MAY be supported using the method described in Appendix B, not protected. o Token transport: In MQTT CONNECT message or using the AUTH extensions for MQTT v5 described in Section 3. Appendix B. The Authorization Information Endpoint The main document described a method for transporting tokens inside MQTT CONNECT messages. In this section, we describe an alternative method to transport an access token. The method consists of the MQTT broker accepting PUBLISH messages to a public "authz-info" topic. A client using this method MUST first connect to the broker, and publish the access token using the "authz- info" topic. The broker must verify the validity of the token (i.e., through local validation or introspection). After publishing the token, the client disconnects from the broker and is expected to try reconnecting over TLS. In MQTT v3.1.1, after the client published to the "authz-info" topic, it is not possible for the broker to communicate the result of the token verification. In MQTT v5, the broker can return 'Not authorized' error to a PUBLISH request for QoS greater or equal to 1. In any case, any token authorization failure affect the subsequent TLS handshake, which can prompt the client to obtain a valid token. Acknowledgements The authors would like to thank Ludwig Seitz for his review and his input on the authorization information endpoint, presented in the appendix. Authors' Addresses Cigdem Sengul Nominet 2 Kingdom Street London W2 6BD UK Email: Cigdem.Sengul@nominet.uk Sengul, et al. Expires November 8, 2019 [Page 21] Internet-Draft MQTT-TLS profile of ACE May 2019 Anthony Kirby Oxbotica 1a Milford House, Mayfield Road, Summertown Oxford OX2 7EL UK Email: anthony@anthony.org Paul Fremantle University of Portsmouth School of Computing, Buckingham House Portsmouth PO1 3HE UK Email: paul.fremantle@port.ac.uk Sengul, et al. Expires November 8, 2019 [Page 22] On Fri, May 24, 2019 at 4:57 AM Cigdem Sengul wrote: > Hello, > > Thanks, Jim, this was helpful, and it also triggered that I go back and > read the introspection section of the core draft again. > > >> >> >> [JLS] For introspection, but not for a published token, the token could >> be =E2=80=9Crevoked=E2=80=9D by the RS. In this case a new introspectio= n check would lead >> to that information. There may be ways to deal with this in the >> introspection dialog and not need to be called up here. The question wo= uld >> be does the exi field mean =E2=80=93 recheck the token or discard the to= ken. >> > > Understood. We definitely need to clarify here what we do with exi field > if it exists, and if it doesn't exist. The MAY language we used in the > draft is not appropriate if exi does not exist. > We considered the expiration time in the introspection response as a > revocation signal and hence RS discards the token. (The basic flow was: = RS > receives a token, introspects it, caches the result and then when it > expires, it revokes the token - which may next lead to different steps > depending on the version of the MQTT.) > But if introspection is done to handle the case of dynamic authorisation > decisions, and exi would signal a recheck indeed. > Will clarify. > > Thanks, > --Cigdem > > > >> >> >> Jim >> >> >> >> >> >> 7. That is correct. Will add the clarification. >> >> >> >> Thanks, >> >> --Cigdem >> >> >> >> >> >> >> >> >> >> On Wed, May 22, 2019 at 10:58 PM Jim Schaad >> wrote: >> >> Thanks for the updates from my last message. This has helped quite a bi= t. >> >> 1. A discussion of the use of raw public keys rather than certificates >> for >> the server may be in order. This can refer to the same RPK issues from >> the >> current DTLS document. It may also be that this just uses normal >> certificate processing and that should be noted as well, but some >> discussion >> of deciding if the subject name/alt name matches the token returned from >> the >> AS. >> >> For the connect message there are a couple of issues that need to be >> thought >> about. >> >> 2. What items are required to be in the connect message. The response = to >> my last message suggested that a client identifier is required to be >> present >> but that is not documented. >> >> 3. It is not completely clear what portions of the CONNECT message are >> being covered by the signature/MAC value. As an example, is the passwor= d >> field omitted entirely or is it set to a zero length password. In >> addition >> to this, from the couple of implementations that I have looked at the >> entire >> packet is not passed out of the base server code for authentication >> purposes. This might need to be taken into account in terms of what is >> used >> for the body and how it is constructed. (As a side note, the >> implementations that I have looked at so far also think that the passwor= d >> is >> a text string rather than a binary value which is going to be a short te= rm >> issue as well.) >> >> 4. I must admit that I am disappointed that there is no challenge >> response >> mechanism in the MQTT specifications. I don't know that anything can be >> done at this point about it but there are some security issues that need >> to >> be highlighted because of this in the security considerations section. >> Only >> the v3 seems to have this problem. Also doing the channel binding would >> deal with this problem as well. Might just need some general discussion= s >> around the channel binding text. >> >> 5. Is there an intention to provide a "standard" format for the scope >> field >> or just to leave it as ad hoc? >> >> 6. It might be reasonable in section 2.1.3 to note that even if a resul= t >> is >> cached, that cached check should be limited for a specific amount of tim= e >> to >> recheck if the token is still active. More of an issue in terms of how >> long >> to cache for introspection. >> >> 7. In section 2.1.4 - I would presume that the last paragraph should be >> extended to say that the token is stored only for the length of the >> connection. That is the token always needs to be supplied every time a >> connect message is sent. >> >> Jim >> >> >> _______________________________________________ >> Ace mailing list >> Ace@ietf.org >> https://www.ietf.org/mailman/listinfo/ace >> >> _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > --0000000000004a8428058d5616ad Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,=C2=A0

Please find my in line commen= ts on the current draft 00. These are indicated as <mglt></mglt>= ;.=C2=A0=C2=A0

Yours,=C2=A0
Daniel
=





ACE Working Group =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0C. Sengul=
Internet-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Nominet
Intended status: S= tandards Track =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0A. Kirby
Expires: No= vember 8, 2019 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 O= xbotica
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 P= . Fremantle
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 University of Portsmouth
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0May 7, 2019
<= br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 MQTT-TLS profile of ACE
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-ietf-ace-mqtt-tls-profile-00=

Abstract

=C2=A0 =C2=A0This document specifies a profile for = the ACE (Authentication and
=C2=A0 =C2=A0Authorization for Constrained E= nvironments) to enable authorization
=C2=A0 =C2=A0in an MQTT-based publi= sh-subscribe messaging system.=C2=A0 Proof-of-
=C2=A0 =C2=A0possession k= eys, bound to OAuth2.0 access tokens, are used to
=C2=A0 =C2=A0authentic= ate and authorize publisher and subscriber clients.=C2=A0 The
=C2=A0 =C2= =A0protocol relies on TLS for confidentiality and server authentication.
Status of This Memo

=C2=A0 =C2=A0This Internet-Draft is submitt= ed in full conformance with the
=C2=A0 =C2=A0provisions of BCP 78 and BC= P 79.

=C2=A0 =C2=A0Internet-Drafts are working documents of the Inte= rnet Engineering
=C2=A0 =C2=A0Task Force (IETF).=C2=A0 Note that other g= roups may also distribute
=C2=A0 =C2=A0working documents as Internet-Dra= fts.=C2=A0 The list of current Internet-
=C2=A0 =C2=A0Drafts is at https://datatracker.iet= f.org/drafts/current/.

=C2=A0 =C2=A0Internet-Drafts are draft do= cuments valid for a maximum of six months
=C2=A0 =C2=A0and may be update= d, replaced, or obsoleted by other documents at any
=C2=A0 =C2=A0time.= =C2=A0 It is inappropriate to use Internet-Drafts as reference
=C2=A0 = =C2=A0material or to cite them other than as "work in progress."<= br>
=C2=A0 =C2=A0This Internet-Draft will expire on November 8, 2019.
Copyright Notice

=C2=A0 =C2=A0Copyright (c) 2019 IETF Trust and= the persons identified as the
=C2=A0 =C2=A0document authors.=C2=A0 All = rights reserved.

=C2=A0 =C2=A0This document is subject to BCP 78 and= the IETF Trust's Legal
=C2=A0 =C2=A0Provisions Relating to IETF Doc= uments
=C2=A0 =C2=A0(h= ttps://trustee.ietf.org/license-info) in effect on the date of
=C2= =A0 =C2=A0publication of this document.=C2=A0 Please review these documents=
=C2=A0 =C2=A0carefully, as they describe your rights and restrictions w= ith respect



Sengul, et al. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0Expires November 8, 2019 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0[Page 1]
=0C
Internet-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 MQTT-TLS profile of ACE =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0May 2019


=C2=A0 =C2=A0to this document.=C2=A0 Code Com= ponents extracted from this document must
=C2=A0 =C2=A0include Simplifie= d BSD License text as described in Section 4.e of
=C2=A0 =C2=A0the Trust= Legal Provisions and are provided without warranty as
=C2=A0 =C2=A0desc= ribed in the Simplified BSD License.

Table of Contents

=C2=A0= =C2=A01.=C2=A0 Introduction =C2=A0. . . . . . . . . . . . . . . . . . . . = . . . . =C2=A0 2
=C2=A0 =C2=A0 =C2=A01.1.=C2=A0 Requirements Language . = . . . . . . . . . . . . . . . . . =C2=A0 4
=C2=A0 =C2=A0 =C2=A01.2.=C2= =A0 ACE-Related Terminology . . . . . . . . . . . . . . . . . =C2=A0 4
= =C2=A0 =C2=A0 =C2=A01.3.=C2=A0 MQTT-Related Terminology =C2=A0. . . . . . .= . . . . . . . . . =C2=A0 4
=C2=A0 =C2=A02.=C2=A0 Basic Protocol Interac= tions . . . . . . . . . . . . . . . . . =C2=A0 5
=C2=A0 =C2=A0 =C2=A02.1= .=C2=A0 Authorizing Connection Establishment =C2=A0. . . . . . . . . . =C2= =A0 6
=C2=A0 =C2=A0 =C2=A0 =C2=A02.1.1.=C2=A0 Client Authorization Serve= r (CAS) and Authorization
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0Server (AS) Interaction . . . . . . . . . . . . . . . =C2=A0 7=C2=A0 =C2=A0 =C2=A0 =C2=A02.1.2.=C2=A0 Client Connection Request to the B= roker . . . . . . . =C2=A0 8
=C2=A0 =C2=A0 =C2=A0 =C2=A02.1.3.=C2=A0 Tok= en Validation =C2=A0. . . . . . . . . . . . . . . . . . =C2=A010
=C2=A0 = =C2=A0 =C2=A0 =C2=A02.1.4.=C2=A0 The Broker's Response to Client Connec= tion Request =C2=A0. =C2=A011
=C2=A0 =C2=A0 =C2=A02.2.=C2=A0 Authorizing= PUBLISH Messages =C2=A0. . . . . . . . . . . . . . =C2=A012
=C2=A0 =C2= =A0 =C2=A0 =C2=A02.2.1.=C2=A0 PUBLISH Messages from the Publisher Client to= the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Broker =C2= =A0. . . . . . . . . . . . . . . . . . . . . . . =C2=A012
=C2=A0 =C2=A0 = =C2=A0 =C2=A02.2.2.=C2=A0 PUBLISH Messages from the Broker to the Subscribe= r
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Clients . . . .= . . . . . . . . . . . . . . . . . . . =C2=A012
=C2=A0 =C2=A0 =C2=A02.3.= =C2=A0 Authorizing SUBSCRIBE Messages =C2=A0. . . . . . . . . . . . . =C2= =A013
=C2=A0 =C2=A0 =C2=A02.4.=C2=A0 Token Expiration =C2=A0. . . . . . = . . . . . . . . . . . . . . =C2=A013
=C2=A0 =C2=A0 =C2=A02.5.=C2=A0 Hand= ling Disconnections and Retained Messages . . . . . . =C2=A013
=C2=A0 = =C2=A03.=C2=A0 Improved Protocol Interactions with MQTT v5 . . . . . . . . = . =C2=A014
=C2=A0 =C2=A0 =C2=A03.1.=C2=A0 Token Transport via Authentica= tion Exchange (AUTH) =C2=A0. . . =C2=A014
=C2=A0 =C2=A0 =C2=A03.2.=C2=A0= Authorization Errors and Client Re-authentication . . . . =C2=A016
=C2= =A0 =C2=A04.=C2=A0 IANA Considerations . . . . . . . . . . . . . . . . . . = . . . =C2=A017
=C2=A0 =C2=A05.=C2=A0 Security Considerations . . . . . .= . . . . . . . . . . . . . =C2=A017
=C2=A0 =C2=A06.=C2=A0 Privacy Consid= erations =C2=A0. . . . . . . . . . . . . . . . . . . =C2=A018
=C2=A0 =C2= =A07.=C2=A0 References =C2=A0. . . . . . . . . . . . . . . . . . . . . . . = . . =C2=A018
=C2=A0 =C2=A0 =C2=A07.1.=C2=A0 Normative References =C2=A0.= . . . . . . . . . . . . . . . . . =C2=A018
=C2=A0 =C2=A0 =C2=A07.2.=C2= =A0 Informative References =C2=A0. . . . . . . . . . . . . . . . . =C2=A019=
=C2=A0 =C2=A0Appendix A.=C2=A0 Checklist for profile requirements . . .= . . . . . . =C2=A020
=C2=A0 =C2=A0Appendix B.=C2=A0 The Authorization I= nformation Endpoint . . . . . . . =C2=A021
=C2=A0 =C2=A0Acknowledgements= =C2=A0. . . . . . . . . . . . . . . . . . . . . . . . =C2=A021
=C2=A0 = =C2=A0Authors' Addresses =C2=A0. . . . . . . . . . . . . . . . . . . . = . . . =C2=A021

1.=C2=A0 Introduction

=C2=A0 =C2=A0This docume= nt specifies a profile for the ACE framework
=C2=A0 =C2=A0[I-D.ietf-ace-= oauth-authz].=C2=A0 In this profile, clients and a resource
=C2=A0 =C2= =A0server use MQTT to communicate.=C2=A0 The protocol relies on TLS for
= =C2=A0 =C2=A0communication security between entities.=C2=A0 The basic proto= col
=C2=A0 =C2=A0interactions follow MQTT v3.1.1 - the OASIS Standard=C2=A0 =C2=A0[MQTT-OASIS-Standard].=C2=A0 In addition, this document descr= ibes



Sengul, et al. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Expire= s November 8, 2019 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[= Page 2]
=0C
Internet-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 MQTT-TL= S profile of ACE =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0May= 2019


=C2=A0 =C2=A0improvements to the basic protocol with the n= ew MQTT v5.0 - the OASIS
=C2=A0 =C2=A0Standard [MQTT-OASIS-Standard-v5] = (e.g., improved authentication
=C2=A0 =C2=A0exchange and error reporting= ).=C2=A0 Both versions are expected to be
=C2=A0 =C2=A0supported in prac= tice, and therefore, covered in this document.

<mglt>

I= understand that the basic protocol refers to MQTTv3.3.1.1 It might be
c= learer to explicitly mention that MQTT v3.1.1 is the basic protocol.
The= other way around could be to remove to the basis protocol" in the
= latest sentence.

Probably that my missing background on MQTT, but -= at least for my
personnal knowledge - I believe that some clarification = over the support
of the v5 and v3.1.1 could be clarified.=C2=A0 When sup= port for both version
is mentioned, I am wondering if this documents man= date that any RS
implements both v3.1.1 AND v5 or if it states that v3.1= .1 is by no way
being sunset. In other words, it is envisioned that some= system will use
v3.1.1 *for ever* in which case their associated is exp= ected to support
v3.1.1. The same will occur for v5 respectively. Anothe= r alternative
could be that MQTTv5 adds functionalities to v3.1.1, leadi= ng to some
sort of backward compatibility that are sufficient in most ca= ses.

</mglt>

=C2=A0 =C2=A0MQTT is a publish-subscribe = protocol and supports two main types of
=C2=A0 =C2=A0client operation: p= ublish and subscribe.=C2=A0 Once connected, a client
=C2=A0 =C2=A0can pu= blish to multiple topics, and subscribe to multiple topics;
=C2=A0 =C2= =A0however, for this document, these actions are described separately.
= =C2=A0 =C2=A0The MQTT broker is responsible for distributing messages publi= shed by
=C2=A0 =C2=A0the publishers to the appropriate subscribers.=C2= =A0 Each publish message
=C2=A0 =C2=A0contains a topic, which is used by= the broker to filter the
=C2=A0 =C2=A0subscribers for the message.=C2= =A0 Subscribers must subscribe to the
=C2=A0 =C2=A0topics to receive the= corresponding messages.

=C2=A0 =C2=A0In this document, message topi= cs are treated as resources.=C2=A0 Clients
=C2=A0 =C2=A0use an access to= ken, bound to a key (the proof-of-possession key) to
=C2=A0 =C2=A0author= ize with the MQTT broker their connection and publish/subscribe
=C2=A0 = =C2=A0permissions to topics.=C2=A0 In the context of this ACE profile, the = MQTT
=C2=A0 =C2=A0broker acts as the resource server.=C2=A0 To provide c= ommunication
=C2=A0 =C2=A0confidentiality and resource server authentica= tion, TLS is used.

=C2=A0 =C2=A0Clients use client authorization ser= vers [I-D.ietf-ace-actors] to
=C2=A0 =C2=A0obtain tokens from the author= ization server.=C2=A0 The communication
=C2=A0 =C2=A0protocol between th= e client authorization server and the
=C2=A0 =C2=A0authorization server = is assumed to be HTTPS.=C2=A0 Also, if the broker
=C2=A0 =C2=A0supports = token introspection, it is assumed to use HTTPS to
=C2=A0 =C2=A0communic= ate with the authorization server.=C2=A0 These interfaces MAY be
=C2=A0 = =C2=A0implemented using other protocols, e.g., CoAP or MQTT. =C2=A0

= <mglt>
I have the impression that the proposed alternatives are un= secured. I am
wondering if that is intentional. I believe that these com= munications
needs to be secured appropriately.
=C2=A0
My understan= ding is that MQTT will work on top of TCP/TLS. If that is
correct, I am = wondering if it is envisioned that a full HTTP client is
embedded into s= mall motes, or a minimal library restricted to support
the interaction w= ith the AS. The reason I am asking this question is
related to a discuss= ion we had in homenet, so that is only for my
personal knowledge and unr= elated to MQTT.

</mglt>

=C2=A0 This document
=C2=A0 = =C2=A0makes the same assumptions as the Section 4 of the ACE framework
= =C2=A0 =C2=A0[I-D.ietf-ace-oauth-authz] regarding client and RS registratio= n with
=C2=A0 =C2=A0the AS and establishing of keying material.

= =C2=A0 =C2=A0This document describes the authorization of the following exc= hanges
=C2=A0 =C2=A0between publisher and subscriber clients, and the br= oker.

=C2=A0 =C2=A0o =C2=A0Connection establishment between the clie= nts and the broker

=C2=A0 =C2=A0o =C2=A0Publish messages from the pu= blishers to the broker, and from the
=C2=A0 =C2=A0 =C2=A0 broker to the = subscribers

=C2=A0 =C2=A0o =C2=A0Subscribe messages from the subscri= bers to the broker

=C2=A0 =C2=A0In Section 2, these exchanges are de= scribed based on the MQTT v3.1.1
=C2=A0 =C2=A0- the OASIS Standard [MQTT= -OASIS-Standard].=C2=A0 These exchanges are also
=C2=A0 =C2=A0supported = by the new MQTT v5 - the OASIS Standard
=C2=A0 =C2=A0[MQTT-OASIS-Standar= d-v5].=C2=A0 Section 3 describes how they may be
=C2=A0 =C2=A0improved b= y the new MQTT v5.



Sengul, et al. =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0Expires November 8, 2019 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0[Page 3]
=0C
Internet-Draft =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 MQTT-TLS profile of ACE =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0May 2019


1.1.=C2=A0 Requirements Language
=C2=A0 =C2=A0The key words "MUST", "MUST NOT", "= REQUIRED", "SHALL", "SHALL NOT",
=C2=A0 =C2=A0&= quot;SHOULD", "SHOULD NOT", "RECOMMENDED", "N= OT RECOMMENDED", "MAY", and
=C2=A0 =C2=A0"OPTIONAL&q= uot; in this document are to be interpreted as described in BCP
=C2=A0 = =C2=A014 [RFC2119] [RFC8174], when, and only when, they appear in all
= =C2=A0 =C2=A0capitals, as shown here.

1.2.=C2=A0 ACE-Related Termino= logy

=C2=A0 =C2=A0The terminology for entities in the architecture i= s defined in OAuth
=C2=A0 =C2=A02.0 RFC 6749 [RFC6749] and ACE actors [I= -D.ietf-ace-actors], such as
=C2=A0 =C2=A0"Client" (C), "= Resource Server" (RS) and "Authorization Server" (AS).
=C2=A0 =C2=A0The term "endpoint" is used following its OAuth de= finition, to denote
=C2=A0 =C2=A0resources such as /token and /introspec= t at the AS.

=C2=A0 =C2=A0The term "Resource" is used to r= efer to an MQTT "topic name," which
=C2=A0 =C2=A0is defined in= Section 1.3.=C2=A0 Hence, the "Resource Owner" is any entity
= =C2=A0 =C2=A0that can authoritatively speak for the "topic".
<= br><mglt>
scetion 1.3 defines the Topic name. It might be more hel= pful to the
reader if the exact same term is used both in the text of th= e document
and in the terminology - that is even considering upper/lower= letters. =C2=A0

I am wondering if broker should be defined as well.=

Similarly, there seems that Clients are composed of various sub cl= ients
( client authorisation server, client (MQTT), subscriber, publishe= r).
Maybe these different designation could be defined as well in theterminology section. Maybe also some designations might not be necessaryto introduce.
</mglt>



=C2=A0 =C2=A0Certain secur= ity-related terms such as "authentication",
=C2=A0 =C2=A0"= ;authorization", "confidentiality", "(data) integrity&q= uot;, "message
=C2=A0 =C2=A0authentication code", and "ve= rify" are taken from RFC 4949 [RFC4949].

1.3.=C2=A0 MQTT-Relate= d Terminology

=C2=A0 =C2=A0The document describes message exchanges = as MQTT protocol
=C2=A0 =C2=A0interactions.=C2=A0 For additional informa= tion, please refer to the MQTT
=C2=A0 =C2=A0v3.1.1 - the OASIS Standard = [MQTT-OASIS-Standard] or the MQTT v5 -
=C2=A0 =C2=A0the OASIS Standard [= MQTT-OASIS-Standard-v5].

=C2=A0 =C2=A0Topic name
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0The label attached to an application message, wh= ich is
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0matched to a subscriptio= n.

=C2=A0 =C2=A0Topic filter
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0An expression that indicates interest in one or more topic
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0names.=C2=A0 Topic filters may include wi= ldcards.

=C2=A0 =C2=A0Subscription
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0A subscription comprises a Topic filter and a maximum quality<= br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0of service (QoS).
<mglt&g= t;
I am wondering why the subscription does not consider the identity(ie= s),
location(s) of the subscriber(s). I the reason that this parameters = are
define over an established session, which in the case of MQTT is
= TCP/TLS. I also suspect there is a MQTT session handling subscribers,
pu= blisher connectivity.

</mglt>

=C2=A0 =C2=A0Application = Message
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The data carried by the= MQTT protocol.=C2=A0 The data has an
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0associated QoS level and a Topic name.




Sengul, et= al. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Expires November 8, 2019 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[Page 4]
=0C
Internet-Dr= aft =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 MQTT-TLS profile of ACE =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0May 2019


=C2=A0 =C2= =A0MQTT sends various control messages across a network connection.=C2=A0 T= he
=C2=A0 =C2=A0following is not an exhaustive list and the control pack= ets that are
=C2=A0 =C2=A0not relevant for authorization are not explain= ed.=C2=A0 These include, for
=C2=A0 =C2=A0instance, the PUBREL and PUBCO= MP packets used in the 4-step handshake
=C2=A0 =C2=A0required for the Qo= S level 2.

=C2=A0 =C2=A0CONNECT
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0Client request to connect to the broker.=C2=A0 After a network=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0connection is established, this i= s the first packet sent by a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0cl= ient.

=C2=A0 =C2=A0CONNACK
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0The broker connection acknowledgment.=C2=A0 The first packet sent
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0from the broker to a client is a CONN= ACK packet.=C2=A0 CONNACK
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0packe= ts contain return codes indicating either a success or
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0an error state to a client.

=C2=A0 =C2=A0PUB= LISH
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Publish packet that can be= sent from a client to the broker,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0or from the broker to a client.

=C2=A0 =C2=A0PUBACK
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Response to PUBLISH packet with QoS level= 1.=C2=A0 PUBACK can be
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0sent fr= om the broker to a client or a client to the broker.

=C2=A0 =C2=A0PU= BREC
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Response to PUBLISH packet= with QoS level 2.=C2=A0 PUBREC can be
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0sent from the broker to a client or a client to the broker.
=C2=A0 =C2=A0SUBSCRIBE
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The cl= ient subscribe request.

=C2=A0 =C2=A0SUBACK
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0Subscribe acknowledgment.

=C2=A0 =C2=A0PINGREQ A= ping request sent from a client to the broker.=C2=A0 It signals
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0to the broker that the client is alive, a= nd is used to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0confirm that the = broker is still alive.

2.=C2=A0 Basic Protocol Interactions

= =C2=A0 =C2=A0This section describes the following exchanges between publish= er and
=C2=A0 =C2=A0subscriber clients, the broker, and the authorizatio= n server
=C2=A0 =C2=A0according to the MQTT v3.1.1 - the OASIS Standard<= br>=C2=A0 =C2=A0[MQTT-OASIS-Standard].=C2=A0 These exchanges are compatible= also with the
=C2=A0 =C2=A0new MQTT v5 - the OASIS Standard [MQTT-OASIS= -Standard-v5].=C2=A0 In
=C2=A0 =C2=A0addition, Section 3 describes how t= hese exchanges may be improved
=C2=A0 =C2=A0with the MQTT v5.


Sengul, et al. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Expires November 8, 2= 019 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[Page 5]
=0C<= br>Internet-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 MQTT-TLS profile of AC= E =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0May 2019

=C2=A0 =C2=A0o =C2=A0Authorizing connection establishment between the cli= ents and the
=C2=A0 =C2=A0 =C2=A0 broker

=C2=A0 =C2=A0o =C2=A0Aut= horizing publish messages from the publishers to the broker,
=C2=A0 =C2= =A0 =C2=A0 and from the broker to the subscribers

=C2=A0 =C2=A0o =C2= =A0Authorizing subscribe messages from the subscribers to the broker
=C2=A0 =C2=A0Message topics are treated as resources.=C2=A0 The publisher = and
=C2=A0 =C2=A0subscriber clients are assumed to have identified the t= opics of
=C2=A0 =C2=A0interest out-of-band (topic discovery is not a fea= ture of the MQTT
=C2=A0 =C2=A0protocol).

=C2=A0 =C2=A0A connectio= n request carries a token specifying the permissions that
=C2=A0 =C2=A0t= he client has (e.g., publish permission to a given topic). =C2=A0A
=C2= =A0 =C2=A0resource owner can pre-configure policies at the AS that give cli= ents
=C2=A0 =C2=A0publish or subscribe permissions to different topics.<= br>
2.1.=C2=A0 Authorizing Connection Establishment

=C2=A0 =C2=A0= This section specifies how publishers and subscribers establish an
=C2= =A0 =C2=A0authorized connection to an MQTT broker.=C2=A0 The token request = and
=C2=A0 =C2=A0response use the /token endpoint of the authorization s= erver, as
=C2=A0 =C2=A0specified in Section 5 of the ACE framework
= =C2=A0 =C2=A0[I-D.ietf-ace-oauth-authz].

=C2=A0 =C2=A0Figure 1 shows= the basic protocol flow during connection
=C2=A0 =C2=A0establishment.= =C2=A0 The step (C), client onboarding, is out of the scope
=C2=A0 =C2= =A0of this document.=C2=A0 Steps (E) and (F) are optional.



<= br>

















= Sengul, et al. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Expires November 8, 2019 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[Page 6]
=0C
I= nternet-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 MQTT-TLS profile of ACE = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0May 2019


= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+----------------+
=C2=A0 =C2=A0 = =C2=A0 +---(A) Token request----| Client =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
= =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| Authorization =C2=A0|
=C2=A0 =C2=A0 =C2= =A0 | =C2=A0 +-(B) Access token-->| Server =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=
=C2=A0 =C2=A0 =C2=A0 | =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|________________|
=C2=A0 =C2=A0 =C2=A0 |= =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0 | =C2=A0 | =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(C) Client On-boarding<= br>=C2=A0 =C2=A0 =C2=A0 | =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2= =A0 =C2=A0 | =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0+---------v-----+
=C2=A0 =C2=A0+--v-------------+ =C2=A0 =C2= =A0 =C2=A0 =C2=A0| Publisher or =C2=A0|
=C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0| Subscr= iber =C2=A0 =C2=A0|
=C2=A0 =C2=A0| =C2=A0Authorization | =C2=A0 =C2=A0 = =C2=A0 =C2=A0|_______________|
=C2=A0 =C2=A0| =C2=A0Server =C2=A0 =C2=A0= =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 = =C2=A0 ^
=C2=A0 =C2=A0|________________| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0^= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (D)Connection =C2=A0(G)Connectio= n
=C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 request + =C2=A0 =C2=A0response
=C2=A0 =C2=A0 =C2=A0 |= =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 access tok= en =C2=A0|
=C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 +---v--------------+
=C2=A0 =C2=A0 =C2=A0 | =C2=A0 = =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 Br= oker =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0+= (E)Introspection-| Resource Server =C2=A0|
=C2=A0 =C2=A0 =C2=A0 | =C2=A0= request (optional) | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0 +-(F)Introspection---->|____________= ______|
=C2=A0 =C2=A0 =C2=A0 =C2=A0 response (optional)

=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Figure 1: Co= nnection establishment

2.1.1.=C2=A0 Client Authorization Server (CAS= ) and Authorization Server (AS)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Interaction<= br>
=C2=A0 =C2=A0The first step in the protocol flow (Figure 1 (A)) is t= he token
=C2=A0 =C2=A0acquisition by the client authorization server (CA= S) from the AS.=C2=A0 If
=C2=A0 =C2=A0a client has enough resources and = can support HTTPS, or optionally
=C2=A0 =C2=A0the AS supports MQTTS, the= se steps can instead be carried out by a
=C2=A0 =C2=A0client directly.
<mglt>
MQTTS and CAS should in my opinion be mentioned in th= e terminology
section.

"optionally" might be clarified= further. The introduction mentioned
HTTPS was considered as the support= ed protocol. but it seems here that
the support of HTTPS may not be obvi= ous, in which case the support of
MQTTS might be RECOMMENDED/SHOULD or e= ven stronger. The recommendation
may also be associated to current deplo= yments, especially concerning how
AS are dedicated to a technology or no= t. I do =C2=A0not see strong
recommendations for the AS to support one s= pecific protocol, so I
believe clarification/discussions on MQTTS / HTTP= S should be provided in
the document. =C2=A0

"""=C2=A0 =C2=A0other underlying
=C2=A0 =C2=A0protocols are not prohibite= d from being supported in the future, such
=C2=A0 =C2=A0as HTTP/2, MQTT,= BLE and QUIC.
"""

</mglt>

=C2=A0 =C2= =A0When requesting an access token from the AS, the CAS MAY include
=C2= =A0 =C2=A0parameters in its request as defined in Section 5.6.1 of the ACE<= br>=C2=A0 =C2=A0framework [I-D.ietf-ace-oauth-authz].=C2=A0 The content typ= e is set to
=C2=A0 =C2=A0"application/json".=C2=A0 The profile= parameter is set to 'mqtt_tls'.

=C2=A0 =C2=A0If the AS succ= essfully verifies the access token request and
=C2=A0 =C2=A0authorizes t= he client for the indicated audience (e.g., RS) and
=C2=A0 =C2=A0scopes = (e.g., publish/subscribe permissions over topics), the AS
=C2=A0 =C2=A0i= ssues an access token (Figure 1 (B)).=C2=A0 The response includes the
= =C2=A0 =C2=A0parameters described in Section 5.6.2 of the ACE framework
= =C2=A0 =C2=A0[I-D.ietf-ace-oauth-authz].=C2=A0 The included token is assume= d to be
=C2=A0 =C2=A0Proof-of-Possession (PoP) token by default.=C2=A0 H= ence, a 'cnf' parameter



Sengul, et al. =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0Expires November 8, 2019 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0[Page 7]
=0C
Internet-Draft =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 MQTT-TLS profile of ACE =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0May 2019


=C2=A0 =C2=A0with a symmetri= c or asymmetric PoP key is returned.=C2=A0 The token may be
=C2=A0 =C2= =A0a reference, or a CBOR or JWT web token.=C2=A0 Note that the 'cnf= 9;
=C2=A0 =C2=A0parameter in the web tokens are to be consumed by the re= source server
=C2=A0 =C2=A0and not the client.=C2=A0 For more informatio= n on Proof of Possession
=C2=A0 =C2=A0semantics in JWTs see RFC 7800 [RF= C7800] and for CWTs, see Proof-of-
=C2=A0 =C2=A0Possession Key Semantics= for CBOR Web Tokens (CWTs)
=C2=A0 =C2=A0[I-D.ietf-ace-cwt-proof-of-poss= ession].

=C2=A0 =C2=A0In the case of an error, the AS returns error = responses for HTTP-
=C2=A0 =C2=A0based interactions as ASCII codes in JS= ON content, as defined in
=C2=A0 =C2=A0Section 5.2 of RFC 6749 [RFC6749]= .

2.1.2.=C2=A0 Client Connection Request to the Broker

=C2=A0= =C2=A0Once the client acquires the token, it can use it to request an MQTT=
=C2=A0 =C2=A0connection to the broker over a TLS session with server=C2=A0 =C2=A0authentication (Figure 1 (D)).=C2=A0 This section describes t= he client
=C2=A0 =C2=A0transporting the token to the broker (RS) via the= CONNECT control
=C2=A0 =C2=A0message after the TLS handshake.=C2=A0 Thi= s is similar to an earlier
=C2=A0 =C2=A0proposal by Fremantle et al. [fr= emantle14].=C2=A0 An improvement to this
=C2=A0 =C2=A0is presented in Se= ction 3 for the MQTT v5 - the OASIS Standard
=C2=A0 =C2=A0[MQTT-OASIS-St= andard-v5]. =C2=A0

<mglt>
I believe the description of the = improvement has been omitted. It woudl
help the reader to get an overvie= w of the improvement.
</mglt>

=C2=A0 Alternatively, the to= ken may be used for
=C2=A0 =C2=A0the TLS session establishment as descri= bed in the DTLS profile for
=C2=A0 =C2=A0ACE [I-D.gerdes-ace-dtls-author= ize].=C2=A0 In this case, both the TLS PSK
=C2=A0 =C2=A0and RPK handshak= es MAY be supported.=C2=A0 This may additionally require
=C2=A0 =C2=A0th= at the client transports the token to the broker before the
=C2=A0 =C2= =A0connection establishment.=C2=A0 To this end, the broker MAY support
= =C2=A0 =C2=A0/authz-info endpoint via the "authz-info" topic.=C2= =A0 Then, to transport
=C2=A0 =C2=A0the token, clients publish to "= authz-info" topic unauthorized.=C2=A0 The
=C2=A0 =C2=A0topic "= authz-info" MUST be publish-only for clients (i.e., the
=C2=A0 =C2= =A0clients are not allowed to subscribe to it).=C2=A0 This option is
=C2= =A0 =C2=A0described in more detail in Appendix B.

=C2=A0 =C2=A0When = the client wishes to connect to the broker, it uses the CONNECT
=C2=A0 = =C2=A0message of MQTT.=C2=A0 Figure 2 shows the structure of the MQTT CONNE= CT
=C2=A0 =C2=A0control message.









=





Sengul, et al. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Ex= pires November 8, 2019 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0[Page 8]
=0C
Internet-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 MQT= T-TLS profile of ACE =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0May 2019


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A08 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A016 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A024 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A032
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +-----------------------= -------------------------------+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |CPT= =3D1 | Rsvd.|Remaining len.| Protocol =C2=A0name len. =3D 4 |
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 +-------------------------------------------------= -----+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0'M' 'Q' = 9;T' 'T' =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +------------------------------= ------------------------+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | Proto.lev= el=3D4|Connect flags| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Keep alive =C2=A0 = =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +---------------------------= ---------------------------+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | Payloa= d =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 Userna= me as access token (UTF-8) =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 Password le= ngth (2 Bytes) =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 = =C2=A0 Password data as signature/MAC (binary) =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0|
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ... =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0|
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +-------------------------------= -----------------------+

=C2=A0 =C2=A0 Figure 2: MQTT CONNECT contro= l message. =C2=A0(CPT=3DControl Packet Type,
=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0Rsvd=3DReserved, len.=3Dlength, Proto.=3DProtoc= ol)

=C2=A0 =C2=A0To communicate the necessary connection parameters,= the Client uses
=C2=A0 =C2=A0the appropriate flags of the CONNECT messa= ge.=C2=A0 Figure 3 shows how the
=C2=A0 =C2=A0MQTT connect flags MUST be= set to initiate a connection with the
=C2=A0 =C2=A0broker.

=C2= =A0 =C2=A0+-----------------------------------------------------------+
= =C2=A0 =C2=A0|User name|Pass.|Will retain|Will QoS|Will Flag|Clean| Rsvd.|<= br>=C2=A0 =C2=A0| flag =C2=A0 =C2=A0|flag | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2= =A0 | =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0+------------------------------= -----------------------------+
=C2=A0 =C2=A0| 1 =C2=A0 =C2=A0 =C2=A0 | 1= =C2=A0 | =C2=A0 =C2=A0X =C2=A0 =C2=A0 =C2=A0| =C2=A0 X X =C2=A0| =C2=A0 X = =C2=A0 =C2=A0 | =C2=A01 =C2=A0 | =C2=A00 =C2=A0|
=C2=A0 =C2=A0+---------= --------------------------------------------------+

=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Figure 3: MQTT CONNECT flags. =C2=A0(Rsv= d=3DReserved)

=C2=A0 =C2=A0To ensure that the client and the broker = discard any previous session
=C2=A0 =C2=A0and start a new session, the C= lean Session Flag MUST be set to 1.

=C2=A0 =C2=A0The Will flag indic= ates that a Will message needs to be sent when a
=C2=A0 =C2=A0client dis= connection occurs.=C2=A0 The situations in which the Will
=C2=A0 =C2=A0m= essage is published include disconnections due to I/O or network
=C2=A0 = =C2=A0failures, and the server closing the networking connection due to a=C2=A0 =C2=A0protocol error.=C2=A0 The client may set the Will flag as de= sired (marked
=C2=A0 =C2=A0as 'X' in Figure 3).=C2=A0 If the Wil= l flag is set to 1 and the broker
=C2=A0 =C2=A0accepts the connection re= quest, the broker must store the Will
=C2=A0 =C2=A0message, and publish = it when the network connection is closed
=C2=A0 =C2=A0according to Will = QoS and Will retain parameters, and MQTT Will
=C2=A0 =C2=A0management ru= les.=C2=A0 Section 2.5 explains how the broker deals with the
=C2=A0 =C2= =A0retained messages in further detail.

<mglt>
Figure menti= ons Will Flag while the text mentions Will flag.

From the paragraph= , I cannot figure out what a Will message is. Maybe
that could be explai= ned or a reference to it may be indicated.

</mglt>


Sengul, et al. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Expires November 8, 2= 019 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[Page 9]
=0C<= br>Internet-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 MQTT-TLS profile of AC= E =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0May 2019

=C2=A0 =C2=A0Finally, Username and Password flags MUST be set to 1 to ens= ure that
=C2=A0 =C2=A0the Payload of the CONNECT message includes both U= sername and
=C2=A0 =C2=A0Password fields.

=C2=A0 =C2=A0The CONNEC= T message defaults to ACE for authentication and
=C2=A0 =C2=A0authorizat= ion.=C2=A0 For the basic operation described in this section,
=C2=A0 =C2= =A0the Username field MUST be set to the access token.=C2=A0 The Password=C2=A0 =C2=A0field MUST be set to the keyed message digest (MAC) or signa= ture
=C2=A0 =C2=A0associated with the access token for proof-of-possessi= on.=C2=A0 The client
=C2=A0 =C2=A0MAY apply the PoP key either to the en= tire request by computing a
=C2=A0 =C2=A0keyed message digest (for symme= tric key) or a digital signature (for
=C2=A0 =C2=A0asymmetric key).=C2= =A0 The CONNECT message is assumed to have enough
=C2=A0 =C2=A0randomnes= s in the payload, and inside a TLS session (excluding the
=C2=A0 =C2=A00= -RTT case) will not be exposed to a replay attack.=C2=A0 When either
=C2= =A0 =C2=A0cannot be guaranteed, the Password MAY also contain a nonce.
<= br>=C2=A0 =C2=A0Section 3.1.3 of MQTT v3.1.1 - the OASIS Standard
=C2=A0= =C2=A0[MQTT-OASIS-Standard] defines the MQTT Username as a UTF-8 encoded=C2=A0 =C2=A0string, which is prefixed by a 2-byte length field followed = by UTF-8
=C2=A0 =C2=A0encoded character data up to 65535 bytes.=C2=A0 Th= erefore an access token
=C2=A0 =C2=A0that is not a valid UTF-8 MUST be B= ase64 [RFC4648] encoded. =C2=A0(The
=C2=A0 =C2=A0MQTT Password allows bi= nary data up to 65535 bytes, and so, does not
=C2=A0 =C2=A0require encod= ing.)

2.1.3.=C2=A0 Token Validation

=C2=A0 =C2=A0RS MUST veri= fy the validity of the token.=C2=A0 This validation MAY be
=C2=A0 =C2=A0= done locally (e.g., in the case of a self-contained token) or the RS
=C2= =A0 =C2=A0MAY send an introspection request to the AS.=C2=A0 If introspecti= on is
=C2=A0 =C2=A0used, this section follows similar steps to those des= cribed in
=C2=A0 =C2=A0Sections 5.7 of the ACE framework [I-D.ietf-ace-o= auth-authz].=C2=A0 The
=C2=A0 =C2=A0communication between AS and RS MAY = be HTTPS, but it, in every case,
=C2=A0 =C2=A0MUST be confidential, mutu= ally authenticated and integrity protected.

=C2=A0 =C2=A0The broker = MUST check if the token is active either using 'exp' claim
=C2= =A0 =C2=A0of the token or 'active' parameter of the introspection r= esponse.

=C2=A0 =C2=A0The access token is constructed by the AS such= that RS can associate
=C2=A0 =C2=A0the access token with the client key= .=C2=A0 This document assumes that the
=C2=A0 =C2=A0Access Token is a Po= P token as described in
=C2=A0 =C2=A0[I-D.ietf-ace-oauth-authz].=C2=A0 T= herefore, the necessary information is
=C2=A0 =C2=A0contained in the = 9;cnf' claim of the access token and may use either
=C2=A0 =C2=A0pub= lic or shared key approaches.=C2=A0 The client uses the signature or
=C2= =A0 =C2=A0the MAC in the password field to prove the possession of the key.=
=C2=A0 =C2=A0The resource server validates the signature or the MAC ove= r the
=C2=A0 =C2=A0contents of the packet, authenticating the client.




Sengul, et al. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Expir= es November 8, 2019 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page = 10]
=0C
Internet-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 MQTT-TLS pr= ofile of ACE =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0May 201= 9


=C2=A0 =C2=A0The broker uses the scope field in the token (or = in the introspection
=C2=A0 =C2=A0result) to determine the publish and s= ubscribe permissions for the
=C2=A0 =C2=A0client.=C2=A0 If the Will flag= is set, then the broker MUST check that the
=C2=A0 =C2=A0token allows t= he publication of the Will message too.

=C2=A0 =C2=A0If the token is= not self-contained and the broker uses token
=C2=A0 =C2=A0introspection= , it MAY cache the validation result to decide whether
=C2=A0 =C2=A0to a= ccept subsequent PUBLISH and SUBSCRIBE messages as these
=C2=A0 =C2=A0me= ssages, which are sent after a connection set-up, do not contain
=C2=A0 = =C2=A0access tokens.=C2=A0 If the introspection result is not cached, then = the
=C2=A0 =C2=A0RS needs to introspect the saved token for each request= .

=C2=A0 =C2=A0Scope strings SHOULD be encoded as a permission, foll= owed by an
=C2=A0 =C2=A0underscore, followed by a topic filter.=C2=A0 Tw= o permissions apply to
=C2=A0 =C2=A0topics: 'publish' and 's= ubscribe'.=C2=A0 An example scope field may
=C2=A0 =C2=A0contain mul= tiple such strings, space delimited, e.g., 'publish_topic1
=C2=A0 = =C2=A0subscribe_topic2/#'.=C2=A0 Hence, this access token would give &#= 39;publish'
=C2=A0 =C2=A0permission to the 'topic1', 'su= bscribe' permission to all the
=C2=A0 =C2=A0subtopics of 'topic2= '.

=C2=A0 =C2=A0Also, if present in the access token, RS must ch= eck that the 'iss'
=C2=A0 =C2=A0corresponds to AS, the 'aud&= #39; field (if not used to define topics)
=C2=A0 =C2=A0corresponds to RS= .=C2=A0 It also has to check whether 'nbf' and 'iat'
=C2= =A0 =C2=A0claims are present and valid.

2.1.4.=C2=A0 The Broker'= s Response to Client Connection Request

=C2=A0 =C2=A0Based on the va= lidation result (obtained either via local inspection
=C2=A0 =C2=A0or us= ing the /introspection interface of the AS), the broker MUST
=C2=A0 =C2= =A0send a CONNACK message to the client.

=C2=A0 =C2=A0The broker res= ponses may follow either the MQTT v3.1.1 - the OASIS
=C2=A0 =C2=A0Standa= rd [MQTT-OASIS-Standard] or the MQTT v5 - the OASIS Standard
=C2=A0 =C2= =A0[MQTT-OASIS-Standard-v5], depending on which version(s) the broker
= =C2=A0 =C2=A0supports.
<mglt>
I believe that references to MQTT= v3.1.1 and MQTTv5 provided in the
introduction are sufficient, and there= is no need to have teh reference
anytime MQTT is invoked. =C2=A0
<= ;/mglt>

=C2=A0 =C2=A0In MQTT v3.1.1 - the OASIS Standard [MQTT-OA= SIS-Standard], it is not
=C2=A0 =C2=A0possible to support AS discovery v= ia sending a tokenless CONNECT
=C2=A0 =C2=A0message to the broker.=C2=A0= This is because a CONNACK packet does not
=C2=A0 =C2=A0include a means = to provide additional information to the client.
=C2=A0 =C2=A0Therefore,= AS discovery needs to take place out-of-band.=C2=A0 This is
=C2=A0 =C2= =A0remedied in the MQTT v5 - the OASIS Standard [MQTT-OASIS-Standard-v5]=C2=A0 =C2=A0and a solution is described in Section 3.

=C2=A0 =C2= =A0If the RS accepts the connection, it MUST store the token.





Sengul, et al. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Expires Nove= mber 8, 2019 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 11]
= =0C
Internet-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 MQTT-TLS profile o= f ACE =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0May 2019

2.2.=C2=A0 Authorizing PUBLISH Messages

2.2.1.=C2=A0 PUBLISH M= essages from the Publisher Client to the Broker

=C2=A0 =C2=A0On rece= iving the PUBLISH message, the broker MUST use the type of
=C2=A0 =C2=A0= message (i.e., PUBLISH) and the topic name in the message header to
=C2= =A0 =C2=A0compare against the cached token or its introspection result.
=
=C2=A0 =C2=A0If the client is allowed to publish to the topic, the RS m= ust publish
=C2=A0 =C2=A0the message to all valid subscribers of the top= ic.=C2=A0 The broker may
=C2=A0 =C2=A0also return an acknowledgment mess= age if the QoS level is greater
=C2=A0 =C2=A0than or equal to 1.

= =C2=A0 =C2=A0In case of a failure, it is not possible to return an error in= MQTT
=C2=A0 =C2=A0v3.1.1 - the OASIS Standard [MQTT-OASIS-Standard].=C2= =A0 Acknowledgement
=C2=A0 =C2=A0messages only indicate success.=C2=A0 I= n the case of an authorization
=C2=A0 =C2=A0error, the broker SHOULD dis= connect the client.=C2=A0 Otherwise, it MUST
=C2=A0 =C2=A0ignore the PUB= LISH message.=C2=A0 Also, DISCONNECT messages are only sent
=C2=A0 =C2= =A0from a client to the broker.=C2=A0 So, server disconnection needs to tak= e
=C2=A0 =C2=A0place below the application layer.=C2=A0 However, in MQTT= v5 - the OASIS
=C2=A0 =C2=A0Standard [MQTT-OASIS-Standard-v5], it is po= ssible to indicate failure
=C2=A0 =C2=A0and provide a reason code.=C2=A0= Section 3 describes in more detail how
=C2=A0 =C2=A0MQTT v5 handles PUB= LISH authorization errors.

2.2.2.=C2=A0 PUBLISH Messages from the Br= oker to the Subscriber Clients

=C2=A0 =C2=A0To forward PUBLISH messa= ges to the subscribing clients, the broker
=C2=A0 =C2=A0identifies all t= he subscribers that have valid matching topic
=C2=A0 =C2=A0subscriptions= (i.e., the tokens are valid, and token scopes allow a
=C2=A0 =C2=A0subs= cription to the particular topic name).=C2=A0 The broker sends a
=C2=A0 = =C2=A0PUBLISH message with the topic name and the topic message to all the<= br>=C2=A0 =C2=A0valid subscribers.

=C2=A0 =C2=A0In MQTT, after conne= ction establishment, there is no way to inform a
=C2=A0 =C2=A0client tha= t an authorization error has occurred for previously
=C2=A0 =C2=A0subscr= ibed topics, e.g., token expiry.=C2=A0 In the case of an
=C2=A0 =C2=A0au= thorization error, the broker disconnects the client.=C2=A0 In the MQTT
= =C2=A0 =C2=A0v3.1.1 - the OASIS Standard [MQTT-OASIS-Standard], the MQTT=C2=A0 =C2=A0DISCONNECT messages are only sent from a client to the broker= .
=C2=A0 =C2=A0Therefore, the server disconnection needs to take place b= elow the
=C2=A0 =C2=A0application layer.=C2=A0 In MQTT v5 - the OASIS St= andard
=C2=A0 =C2=A0[MQTT-OASIS-Standard-v5], a server-side DISCONNECT m= essage is
=C2=A0 =C2=A0possible and described in Section 3.


<= br>




Sengul, et al. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Exp= ires November 8, 2019 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Pag= e 12]
=0C
Internet-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 MQTT-TLS = profile of ACE =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0May 2= 019


2.3.=C2=A0 Authorizing SUBSCRIBE Messages

=C2=A0 =C2= =A0In MQTT, a SUBSCRIBE message is sent from a client to the broker to
= =C2=A0 =C2=A0create one or more subscriptions to one or more topics.=C2=A0 = The
=C2=A0 =C2=A0SUBSCRIBE message may contain multiple topic filters.= =C2=A0 The topic
=C2=A0 =C2=A0filters may include wildcard characters.
=C2=A0 =C2=A0On receiving the SUBSCRIBE message, the broker MUST use = the type of
=C2=A0 =C2=A0message (i.e., SUBSCRIBE) and the topic filter = in the message header
=C2=A0 =C2=A0to compare against the stored token o= r introspection result.

=C2=A0 =C2=A0As a response to the SUBSCRIBE = message, the broker issues a SUBACK
=C2=A0 =C2=A0message.=C2=A0 For each= topic filter, the SUBACK packet includes a return
=C2=A0 =C2=A0code mat= ching the QoS level for the corresponding topic filter.=C2=A0 In
=C2=A0 = =C2=A0the case of failure, the return code, in MQTT v3.1.1, must be 0x80=C2=A0 =C2=A0indicating 'Failure'.=C2=A0 In MQTT v5, the appropria= te return code is
=C2=A0 =C2=A00x87, indicating that the client is '= Not authorized'.=C2=A0 Note that, in
=C2=A0 =C2=A0both MQTT versions= , a reason code is returned for each topic filter.
=C2=A0 =C2=A0Therefor= e, the client may receive success codes for a subset of its
=C2=A0 =C2= =A0topic filters, while being unauthorized for the rest.

2.4.=C2=A0 = Token Expiration

=C2=A0 =C2=A0The broker MUST check for token expira= tion whenever a CONNECT,
=C2=A0 =C2=A0PUBLISH or SUBSCRIBE message is re= ceived or sent.=C2=A0 The broker SHOULD
=C2=A0 =C2=A0check for token exp= iration on receiving a PINGREQUEST message.=C2=A0 This
=C2=A0 =C2=A0may = allow for early detection of a token expiry.

=C2=A0 =C2=A0The token = expiration is checked by checking the 'exp' claim of a CWT/
=C2= =A0 =C2=A0JWT or via performing an introspection request with the Authoriza= tion
=C2=A0 =C2=A0server as described in Section 5.7 of the ACE framewor= k
=C2=A0 =C2=A0[I-D.ietf-ace-oauth-authz].=C2=A0 In the basic operation,= token
=C2=A0 =C2=A0expirations MAY lead to disconnecting the associated= client.
=C2=A0 =C2=A0However, in MQTT v5 - the OASIS Standard [MQTT-OAS= IS-Standard-v5],
=C2=A0 =C2=A0better error handling and re-authenticatio= n are possible.=C2=A0 This is
=C2=A0 =C2=A0explained in more detail in S= ection 3.

2.5.=C2=A0 Handling Disconnections and Retained Messages
=C2=A0 =C2=A0According to MQTT v3.1.1 - the OASIS Standard [MQTT-OASI= S-Standard],
=C2=A0 =C2=A0only Client DISCONNECT messages are allowed.= =C2=A0 In MQTT v5 - the OASIS
=C2=A0 =C2=A0Standard [MQTT-OASIS-Standard= -v5], server-side DISCONNECT messages
=C2=A0 =C2=A0are possible, allowin= g to return '0x87 Not Authorized' return code to
=C2=A0 =C2=A0th= e client.

=C2=A0 =C2=A0In the case of a DISCONNECT, due to the Clean= Session flag, the
=C2=A0 =C2=A0broker deletes all session state but MUS= T keep the retained messages.
=C2=A0 =C2=A0By setting a RETAIN flag in a= PUBLISH message, the publisher



Sengul, et al. =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0Expires November 8, 2019 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 [Page 13]
=0C
Internet-Draft =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 MQTT-TLS profile of ACE =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0May 2019


=C2=A0 =C2=A0indicates to the b= roker that it should store the most recent message
=C2=A0 =C2=A0for the = associated topic.=C2=A0 Hence, the new subscribers can receive the
=C2= =A0 =C2=A0last sent message from the publisher for that particular topic=C2=A0 =C2=A0without waiting for the next PUBLISH message.=C2=A0 In the ca= se of a
=C2=A0 =C2=A0disconnection, the broker MUST continue publishing = the retained
=C2=A0 =C2=A0messages as long as the associated tokens are = valid.

=C2=A0 =C2=A0In case of disconnections due to network errors = or server
=C2=A0 =C2=A0disconnection due to a protocol error (which incl= udes authorization
=C2=A0 =C2=A0errors), the Will message must be sent i= f the client supplied a Will
=C2=A0 =C2=A0in the CONNECT request message= .=C2=A0 The token provided in the CONNECT
=C2=A0 =C2=A0request must cove= r the Will topic.=C2=A0 The Will message MUST be
=C2=A0 =C2=A0published = to the Will topic when the network connection is closed
=C2=A0 =C2=A0reg= ardless of whether the corresponding token has expired.

3.=C2=A0 Imp= roved Protocol Interactions with MQTT v5

=C2=A0 =C2=A0In the new MQT= T v5 - the OASIS Standard [MQTT-OASIS-Standard-v5],
=C2=A0 =C2=A0several= new capabilities are introduced, which enable better
=C2=A0 =C2=A0integ= ration with ACE.=C2=A0 The newly enhanced authentication and re-
=C2=A0 = =C2=A0authentication methods support a wider range of authentication flows<= br>=C2=A0 =C2=A0beyond username and password.=C2=A0 With the MQTT v5, there= is a clearly
=C2=A0 =C2=A0defined approach for using token-based author= ization.=C2=A0 Also, it is
=C2=A0 =C2=A0possible for a client to request= a re-authentication avoiding
=C2=A0 =C2=A0disconnection.=C2=A0 Finally,= MQTT v5 generally improves error reporting,
=C2=A0 =C2=A0enabling bette= r response to authorization failures during publishing
=C2=A0 =C2=A0mess= ages to the subscribers.

<mglt>
Given that MQTT provides a = better integration with ACE, I am wondering
if MQTTv5 should not be cons= idered as the primary description and having
MQTT3.1.1 related to legacy= MQTT. This is seems to me simply re-ordering the
sections. However, the= message carried would be to move to MQTTv5 when
possible.

I als= o believe that a recommendation on supporting MQTTv5 should me made
in t= he document.

</mglt>

3.1.=C2=A0 Token Transport via Au= thentication Exchange (AUTH)

=C2=A0 =C2=A0To initiate the authentica= tion and authorization flow, as before, the
=C2=A0 =C2=A0CAS initiates t= he token request as in Section 2.1.=C2=A0 When the client
=C2=A0 =C2=A0w= ishes to connect to the RS (broker), it uses the CONNECT message of
=C2= =A0 =C2=A0MQTT.=C2=A0 Figure 4 shows the structure of the MQTT CONNECT cont= rol
=C2=A0 =C2=A0message used in MQTT v5.















Sengul, et al. =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0Expires November 8, 2019 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 [Page 14]
=0C
Internet-Draft =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 MQTT-TLS profile of ACE =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0May 2019


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A08 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A016 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A024 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A032
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +---------= ---------------------------------------------+
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 |CPT=3D1 | Rsvd.|Remaining len.| Protocol =C2=A0name len. =3D 4 = |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +----------------------------------= --------------------+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0'M' = 'Q' 'T' 'T' =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +----------------= --------------------------------------+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 | Proto.level=3D5|Connect flags| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Keep= alive =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +-------------= -----------------------------------------+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Property l= ength =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0|
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0Auth. Method (0x15) | 'ace' =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Auth. Data (0x16) =C2=A0 | empty or token or= =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0token + PoP data =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 +----------------------------------------------------= --+

=C2=A0 =C2=A0 Figure 4: MQTT CONNECT control message. =C2=A0(CPT= =3DControl Packet Type,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0Rsvd=3DReserved, len.=3Dlength, Proto.=3DProtocol)

=C2=A0 =C2= =A0To communicate the necessary connection parameters, the client uses
= =C2=A0 =C2=A0the appropriate flags of the CONNECT message.=C2=A0 To achieve= a clean
=C2=A0 =C2=A0session (i.e., the session should start without an= existing session),
=C2=A0 =C2=A0the new MQTT v5 session flags MUST be s= et appropriately: the Clean
=C2=A0 =C2=A0Start Flag MUST be set to 1 and= Session Expiry Interval MUST be set
=C2=A0 =C2=A0to 0.

=C2=A0 = =C2=A0With the enhanced authentication capabilities, it is not necessary to=
=C2=A0 =C2=A0overload the username and password fields in the CONNECT m= essage for
=C2=A0 =C2=A0ACE authentication.=C2=A0 Nevertheless, the RS M= UST support both methods
=C2=A0 =C2=A0for supporting the token: (1) Toke= n transport via username and
=C2=A0 =C2=A0password and (2) using the new= AUTH (Authentication Exchange) method.
=C2=A0 =C2=A0The token transport= via username and password is as described in
=C2=A0 =C2=A0Section 2.1.2= .=C2=A0 The rest of this section describes the AUTH method.

<mglt= >
As mentioned before, it might be better to mention what to do andexplain in MQTT why we overload the username/password. =C2=A0
</mgl= t>

=C2=A0 =C2=A0To use the AUTH method, the username flag MUST be= set to 0, and the
=C2=A0 =C2=A0password flag MUST be set to 0.=C2=A0 Th= e client can set the
=C2=A0 =C2=A0Authentication Method as a property of= a CONNECT packet by setting
=C2=A0 =C2=A0Auth Properties (with the prop= erty identifier 0x15).=C2=A0 The client must
=C2=A0 =C2=A0MUST set the U= TF-8 encoded string containing the name of the
=C2=A0 =C2=A0authenticati= on method as 'ace'.=C2=A0 If the RS does not support this
=C2=A0= =C2=A0profile, it sends a CONNACK with a Reason Code of '0x8C (Bad
= =C2=A0 =C2=A0authentication method)'

=C2=A0 =C2=A0The Authentica= tion Method is followed by the Authentication Data,
=C2=A0 =C2=A0which h= as a property identifier 0x16.=C2=A0 Authentication data is binary
=C2= =A0 =C2=A0data and is defined by the authentication method.=C2=A0 The RS MA= Y support
=C2=A0 =C2=A0different implementations for transporting the au= thentication data.
=C2=A0 =C2=A0The first option is that Authentication = data contains both the token
=C2=A0 =C2=A0and the keyed message digest (= MAC) or signature as described in
=C2=A0 =C2=A0Section 2.1.2.=C2=A0 The = encoding of this field MAY use CBOR and COSE.=C2=A0 In



Sengu= l, et al. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Expires November 8, 2019 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 15]
=0C
Internet-Dra= ft =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 MQTT-TLS profile of ACE =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0May 2019


=C2=A0 =C2=A0= this case, the token validation proceeds as described in
=C2=A0 =C2=A0Se= ction 2.1.3 and the server responds with a CONNACK.=C2=A0 The reason
=C2= =A0 =C2=A0code of the CONNACK is '0x00 (Success)' if the authentica= tion is
=C2=A0 =C2=A0successful.=C2=A0 In case of an invalid PoP token, = the CONNACK reason code
=C2=A0 =C2=A0is '0x87 (Not Authorized)'.=

=C2=A0 =C2=A0The second option that RS may accept is a challenge/re= sponse
=C2=A0 =C2=A0protocol.=C2=A0 If the Authentication Data only incl= udes the token, the RS
=C2=A0 =C2=A0MUST respond with an AUTH packet, wi= th the Authenticate Reason Code
=C2=A0 =C2=A0set to '0x18 (Continue = Authentication)'.=C2=A0 This packet includes the
=C2=A0 =C2=A0Authen= tication Method, which MUST be set to 'ace' and Authentication
= =C2=A0 =C2=A0Data.=C2=A0 The Authentication Data MUST NOT be empty and cont= ains a
=C2=A0 =C2=A0challenge for the client.=C2=A0 The client responds = to this with an AUTH
=C2=A0 =C2=A0packet, with a reason code '0x18 (= Continue Authentication)'.
=C2=A0 =C2=A0Similarly, the client packet= sets the Authentication Method to 'ace'.
=C2=A0 =C2=A0The Authe= ntication Data in the client's response contains the
=C2=A0 =C2=A0si= gnature or MAC computed over the RS's challenge.=C2=A0 To this, the
= =C2=A0 =C2=A0server responds with a CONNACK and return code '0x00 (Succ= ess)' if
=C2=A0 =C2=A0the authentication is successful.=C2=A0 In cas= e of an invalid PoP token,
=C2=A0 =C2=A0the CONNACK reason code is '= 0x87 (Not Authorized)'.

=C2=A0 =C2=A0Finally, this document allo= ws the CONNECT message to have an empty
=C2=A0 =C2=A0Authentication Data= field.=C2=A0 This is the AS discovery option and the
=C2=A0 =C2=A0RS re= sponds with the CONNACK reason code '0x87 (Not Authorized)' and
= =C2=A0 =C2=A0includes a User Property for the AS information.=C2=A0 AS Info= rmation
=C2=A0 =C2=A0contains the absolute URI of AS, and MAY also conta= in a cnonce as
=C2=A0 =C2=A0described in the Section 5.1 of the ACE fram= ework
=C2=A0 =C2=A0[I-D.ietf-ace-oauth-authz].=C2=A0 This information MA= Y be CBOR encoded.

3.2.=C2=A0 Authorization Errors and Client Re-aut= hentication

=C2=A0 =C2=A0MQTT v5 allows better error reporting.=C2= =A0 To take advantage of this for
=C2=A0 =C2=A0PUBLISH messages, the QoS= level should be set to greater than or
=C2=A0 =C2=A0equal to 1.=C2=A0 T= his guarantees that RS responds with either a PUBACK or
=C2=A0 =C2=A0PUB= REC packet with reason code '0x87 (Not authorized)' in the case of<= br>=C2=A0 =C2=A0an authorization error.=C2=A0 Similarly, for the SUBSCRIBE = case, the
=C2=A0 =C2=A0SUBACK packet has a reason code set to '0x87 = (Not authorized)' for
=C2=A0 =C2=A0the unauthorized topic(s).=C2=A0 = When RS is forwarding PUBLISH messages to
=C2=A0 =C2=A0the subscribed cl= ients, it may discover that some of the subscribers
=C2=A0 =C2=A0are no = more authorized due to expired tokens.=C2=A0 In this case, the RS
=C2=A0= =C2=A0SHOULD send a DISCONNECT message with the reason code '0x87 (Not=
=C2=A0 =C2=A0authorized)'.=C2=A0 Note that the server-side DISCONNE= CT is a new feature
=C2=A0 =C2=A0of MQTT v5 (in MQTT v3.1.1, the server = needed to drop the
=C2=A0 =C2=A0connection).=C2=A0 RS MUST stop forwardi= ng messages to the unauthorized
=C2=A0 =C2=A0subscribers.

=C2=A0 = =C2=A0In the case of a PUBACK with '0x87 (Not authorized)', the cli= ent can
=C2=A0 =C2=A0update its token using the Re-authentication featur= e of MQTT v5.



Sengul, et al. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0Expires November 8, 2019 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 [Page 16]
=0C
Internet-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 M= QTT-TLS profile of ACE =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0May 2019


=C2=A0 =C2=A0Also, the clients can proactively updat= e their tokens without waiting
=C2=A0 =C2=A0for such a PUBACK.=C2=A0 To = re-authenticate, the client sends an AUTH
=C2=A0 =C2=A0packet with reaso= n code '0x19 (Re-authentication)'.=C2=A0 The client MUST
=C2=A0 = =C2=A0set the authentication method as 'ace' and transport the new = token in
=C2=A0 =C2=A0the Authentication Data.=C2=A0 The client and the = RS go through the same
=C2=A0 =C2=A0steps for proof of possession valida= tion as described in the previous
=C2=A0 =C2=A0section.=C2=A0 If the re-= authentication fails, the server MUST send a
=C2=A0 =C2=A0DISCONNECT wit= h the reason code '0x87 (Not Authorized)'.

4.=C2=A0 IANA Con= siderations

=C2=A0 =C2=A0The following registrations are done for th= e ACE OAuth Profile
=C2=A0 =C2=A0Registry following the procedure specif= ied in
=C2=A0 =C2=A0[I-D.ietf-ace-oauth-authz].

=C2=A0 =C2=A0Note= to the RFC editor: Please replace all occurrences of "[RFC-
=C2=A0= =C2=A0XXXX]" with the RFC number of this specification and delete thi= s
=C2=A0 =C2=A0paragraph.

=C2=A0 =C2=A0Profile name: mqtt_tls
=
=C2=A0 =C2=A0Profile description: Profile for delegating client authent= ication and
=C2=A0 =C2=A0authorization using MQTT as the application pro= tocol and TLS For
=C2=A0 =C2=A0transport layer security.

=C2=A0 = =C2=A0Profile ID:

=C2=A0 =C2=A0Change controller: IESG

=C2=A0= =C2=A0Reference: [RFC-XXXX]

5.=C2=A0 Security Considerations
=C2=A0 =C2=A0This document specifies a profile for the Authentication and<= br>=C2=A0 =C2=A0Authorization for Constrained Environments (ACE) framework<= br>=C2=A0 =C2=A0[I-D.ietf-ace-oauth-authz].=C2=A0 Therefore, the security c= onsiderations
=C2=A0 =C2=A0outlined in [I-D.ietf-ace-oauth-authz] apply = to this work.

=C2=A0 =C2=A0In addition, the security considerations = outlined in MQTT v3.1.1 -
=C2=A0 =C2=A0the OASIS Standard [MQTT-OASIS-St= andard] and MQTT v5 - the OASIS
=C2=A0 =C2=A0Standard [MQTT-OASIS-Standa= rd-v5] apply.=C2=A0 Mainly, this document
=C2=A0 =C2=A0provides an autho= rization solution for MQTT, the responsibility of
=C2=A0 =C2=A0which is = left to the specific implementation in MQTT v5 - the OASIS
=C2=A0 =C2=A0= Standard [MQTT-OASIS-Standard-v5].=C2=A0 In the following, we comment on a<= br>=C2=A0 =C2=A0few relevant issues based on the current MQTT specification= s.

=C2=A0 =C2=A0In this document, RS uses the PoP access token to au= thenticate the
=C2=A0 =C2=A0client.=C2=A0 If the client is able, TLS cer= tificates sent from the client



Sengul, et al. =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0Expires November 8, 2019 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 [Page 17]
=0C
Internet-Draft =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 MQTT-TLS profile of ACE =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0May 2019


=C2=A0 =C2=A0can be used by the= RS to authenticate the client.=C2=A0 The TLS
=C2=A0 =C2=A0certificate f= rom the RS MUST be used by the client to authenticate
=C2=A0 =C2=A0the R= S.

=C2=A0 =C2=A0To authorize a client's publish and subscribe re= quests in an ongoing
=C2=A0 =C2=A0session, the RS caches the access toke= n after accepting the
=C2=A0 =C2=A0connection from the client.=C2=A0 How= ever, if some permissions are revoked
=C2=A0 =C2=A0in the meantime, the = RS may still grant publish/subscribe to revoked
=C2=A0 =C2=A0topics unti= l the session ends or the token expires.=C2=A0 When permissions
=C2=A0 = =C2=A0change dynamically, it is expected that AS follows a reasonable
= =C2=A0 =C2=A0expiration strategy for the access tokens.

=C2=A0 =C2= =A0The RS may monitor client behaviour to detect potential security
=C2= =A0 =C2=A0problems, especially those affecting availability.=C2=A0 These in= clude
=C2=A0 =C2=A0repeated token transfer attempts to the public "= authz-info" topic,
=C2=A0 =C2=A0repeated connection attempts, abnor= mal terminations, and clients that
=C2=A0 =C2=A0connect but do not send = any data.=C2=A0 If the RS supports the public
=C2=A0 =C2=A0"authz-i= nfo" topic, described in Appendix B, then this may be
=C2=A0 =C2=A0= vulnerable to a DDoS attack, where many clients use the "authz-info&qu= ot;
=C2=A0 =C2=A0public topic to transport fictitious tokens, which RS m= ay need to
=C2=A0 =C2=A0store indefinitely.

6.=C2=A0 Privacy Cons= iderations

=C2=A0 =C2=A0The privacy considerations outlined in [I-D.= ietf-ace-oauth-authz]
=C2=A0 =C2=A0apply to this work.

=C2=A0 =C2= =A0In MQTT, the RS is a central trusted party and may forward
=C2=A0 =C2= =A0potentially sensitive information between clients.=C2=A0 Clients may
= =C2=A0 =C2=A0choose to encrypt the payload of their messages.=C2=A0 However= , this would
=C2=A0 =C2=A0not provide privacy for other properties of th= e message such as topic
=C2=A0 =C2=A0name.

7.=C2=A0 References
7.1.=C2=A0 Normative References

=C2=A0 =C2=A0[I-D.gerdes-ace-dt= ls-authorize]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Gerdes, S= ., Bergmann, O., Bormann, C., Selander, G., and
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 L. Seitz, "Datagram Transport Layer Security = (DTLS)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Profile for Auth= entication and Authorization for
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 Constrained Environments (ACE)", draft-gerdes-ace-dtls-
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 authorize-01 (work in prog= ress), March 2017.








Sengul, et al. =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0Expires November 8, 2019 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 18]
=0C
Internet-Draft =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 MQTT-TLS profile of ACE =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0May 2019


=C2=A0 =C2=A0[I-D.ietf-a= ce-oauth-authz]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Seitz, = L., Selander, G., Wahlstroem, E., Erdtman, S., and
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 H. Tschofenig, "Authentication and Authori= zation for
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Constrained = Environments (ACE) using the OAuth 2.0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-2= 4
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (work in progress), M= arch 2019.

=C2=A0 =C2=A0[MQTT-OASIS-Standard]
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Banks, A., Ed. and R. Gupta, Ed., "OAS= IS Standard MQTT
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Versio= n 3.1.1 Plus Errata 01", 2015, <http= ://docs.oasis-
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 open.org/mqtt/mqt= t/v3.1.1/mqtt-v3.1.1.html>.

=C2=A0 =C2=A0[MQTT-OASIS-Standard= -v5]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Banks, A., Ed., Br= iggs, E., Ed., Borgendale, K., Ed., and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 R. Gupta, Ed., "OASIS Standard MQTT Version 5.0"= ;, 2017,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <http://docs.oasis-open.org/= mqtt/mqtt/v5.0/os/
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = mqtt-v5.0-os.html>.

=C2=A0 =C2=A0[RFC2119] =C2=A0Bradner, S., &qu= ot;Key words for use in RFCs to Indicate
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Requirement Levels", BCP 14, RFC 2119,
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 DOI 10.17487/RFC2119, March 1997,=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <https://www.rfc-editor.org/info/rfc2119&= gt;.

=C2=A0 =C2=A0[RFC4648] =C2=A0Josefsson, S., "The Base16, B= ase32, and Base64 Data
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <https://www.rfc-editor.org/info/rfc4648>.
=
=C2=A0 =C2=A0[RFC8174] =C2=A0Leiba, B., "Ambiguity of Uppercase vs= Lowercase in RFC
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 2119 = Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 May 2017, <https://www.rfc-editor.org/info/rfc8174>.<= br>
7.2.=C2=A0 Informative References

=C2=A0 =C2=A0[fremantle14]<= br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Fremantle, P., Aziz, B.= , Kopecky, J., and P. Scott,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 "Federated Identity and Access Management for the Internet
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 of Things", research = International Workshop on Secure
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 Internet of Things, September 2014,
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 <http://dx.doi.org/10.1109/SIoT.2014.8>.

=C2=A0 =C2=A0[I-D= .ietf-ace-actors]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Gerde= s, S., Seitz, L., Selander, G., and C. Bormann, "An
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 architecture for authorization in constr= ained
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 environments"= ;, draft-ietf-ace-actors-07 (work in
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 progress), October 2018.






Sengul, e= t al. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Expires November 8, 2019 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 19]
=0C
Internet-Draft = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 MQTT-TLS profile of ACE =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0May 2019


=C2=A0 =C2=A0[= I-D.ietf-ace-cwt-proof-of-possession]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 Jones, M., Seitz, L., Selander, G., Erdtman, S., and H.
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Tschofenig, "Proof-of= -Possession Key Semantics for CBOR
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 Web Tokens (CWTs)", draft-ietf-ace-cwt-proof-of-
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 possession-06 (work in progre= ss), February 2019.

=C2=A0 =C2=A0[RFC4949] =C2=A0Shirey, R., "I= nternet Security Glossary, Version 2",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007,=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <https://www.rfc-editor.org/info/rfc4949= >.

=C2=A0 =C2=A0[RFC6749] =C2=A0Hardt, D., Ed., "The OAuth 2= .0 Authorization Framework",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 RFC 6749, DOI 10.17487/RFC6749, October 2012,
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <https://www.rfc-editor.org/info/rfc6749>.

=C2= =A0 =C2=A0[RFC7800] =C2=A0Jones, M., Bradley, J., and H. Tschofenig, "= Proof-of-
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Possession Ke= y Semantics for JSON Web Tokens (JWTs)",
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 RFC 7800, DOI 10.17487/RFC7800, April 2016,
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <https://www.rfc-editor.org/info/rfc7800>.=

Appendix A.=C2=A0 Checklist for profile requirements

=C2=A0 = =C2=A0o =C2=A0AS discovery: For the basic protocol using either MQTT v3.1.1= or
=C2=A0 =C2=A0 =C2=A0 MQTT v5, the clients/client authorization serve= rs need to be
=C2=A0 =C2=A0 =C2=A0 configured out-of-band.=C2=A0 RS does= not provide any hints to help AS
=C2=A0 =C2=A0 =C2=A0 discovery.=C2=A0 = AS discovery is possible with the MQTT v5 extensions
=C2=A0 =C2=A0 =C2= =A0 described in Section 3.

=C2=A0 =C2=A0o =C2=A0The communication p= rotocol between the client and RS: MQTT

=C2=A0 =C2=A0o =C2=A0The sec= urity protocol between the client and RS: TLS

=C2=A0 =C2=A0o =C2=A0C= lient and RS mutual authentication: RS provides a server
=C2=A0 =C2=A0 = =C2=A0 certificate during TLS handshake.=C2=A0 Client transports token and = MAC
=C2=A0 =C2=A0 =C2=A0 via the MQTT CONNECT message.=C2=A0 Other metho= ds for transporting the
=C2=A0 =C2=A0 =C2=A0 token with the MQTT v5 exte= nsions described in Section 3.

=C2=A0 =C2=A0o =C2=A0Content format: = For the HTTPS interactions with AS, "application/
=C2=A0 =C2=A0 =C2= =A0 json".=C2=A0 The MQTT payloads may be formatted JSON or CBOR.
<= br>=C2=A0 =C2=A0o =C2=A0PoP protocols: Either symmetric or asymmetric keys = can be
=C2=A0 =C2=A0 =C2=A0 supported.

=C2=A0 =C2=A0o =C2=A0Uniqu= e profile identifier: mqtt_tls

=C2=A0 =C2=A0o =C2=A0Token introspect= ion: RS uses HTTPS /introspect interface of AS.

=C2=A0 =C2=A0o =C2= =A0Token request: CAS uses HTTPS /token interface of AS.



Sengul, et al. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Expires November 8, 2019 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 20]
=0C
Intern= et-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 MQTT-TLS profile of ACE =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0May 2019


=C2=A0 = =C2=A0o =C2=A0/authz-info endpoint: It MAY be supported using the method=C2=A0 =C2=A0 =C2=A0 described in Appendix B, not protected.

=C2=A0= =C2=A0o =C2=A0Token transport: In MQTT CONNECT message or using the AUTH=C2=A0 =C2=A0 =C2=A0 extensions for MQTT v5 described in Section 3.
Appendix B.=C2=A0 The Authorization Information Endpoint

=C2=A0 = =C2=A0The main document described a method for transporting tokens inside=C2=A0 =C2=A0MQTT CONNECT messages.=C2=A0 In this section, we describe an= alternative
=C2=A0 =C2=A0method to transport an access token.

= =C2=A0 =C2=A0The method consists of the MQTT broker accepting PUBLISH messa= ges to
=C2=A0 =C2=A0a public "authz-info" topic.=C2=A0 A clien= t using this method MUST first
=C2=A0 =C2=A0connect to the broker, and p= ublish the access token using the "authz-
=C2=A0 =C2=A0info" t= opic.=C2=A0 The broker must verify the validity of the token (i.e.,
=C2= =A0 =C2=A0through local validation or introspection).=C2=A0 After publishin= g the
=C2=A0 =C2=A0token, the client disconnects from the broker and is = expected to try
=C2=A0 =C2=A0reconnecting over TLS.

=C2=A0 =C2=A0= In MQTT v3.1.1, after the client published to the "authz-info" to= pic,
=C2=A0 =C2=A0it is not possible for the broker to communicate the r= esult of the
=C2=A0 =C2=A0token verification.=C2=A0 In MQTT v5, the brok= er can return 'Not
=C2=A0 =C2=A0authorized' error to a PUBLISH r= equest for QoS greater or equal to 1.
=C2=A0 =C2=A0In any case, any toke= n authorization failure affect the subsequent
=C2=A0 =C2=A0TLS handshake= , which can prompt the client to obtain a valid token.

Acknowledgeme= nts

=C2=A0 =C2=A0The authors would like to thank Ludwig Seitz for hi= s review and his
=C2=A0 =C2=A0input on the authorization information end= point, presented in the
=C2=A0 =C2=A0appendix.

Authors' Addre= sses

=C2=A0 =C2=A0Cigdem Sengul
=C2=A0 =C2=A0Nominet
=C2=A0 = =C2=A02 Kingdom Street
=C2=A0 =C2=A0London =C2=A0W2 6BD
=C2=A0 =C2=A0= UK

=C2=A0 =C2=A0Email: C= igdem.Sengul@nominet.uk









Sengul, = et al. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Expires November 8, 2019 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 21]
=0C
Internet-Draf= t =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 MQTT-TLS profile of ACE =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0May 2019


=C2=A0 =C2=A0A= nthony Kirby
=C2=A0 =C2=A0Oxbotica
=C2=A0 =C2=A01a Milford House, May= field Road, Summertown
=C2=A0 =C2=A0Oxford =C2=A0OX2 7EL
=C2=A0 =C2= =A0UK

=C2=A0 =C2=A0Email: ant= hony@anthony.org


=C2=A0 =C2=A0Paul Fremantle
=C2=A0 =C2= =A0University of Portsmouth
=C2=A0 =C2=A0School of Computing, Buckingham= House
=C2=A0 =C2=A0Portsmouth =C2=A0PO1 3HE
=C2=A0 =C2=A0UK

= =C2=A0 =C2=A0Email: paul.frema= ntle@port.ac.uk













=




















Sengul, et al. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Expires Novem= ber 8, 2019 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 22]
<= /div>


On Fri, May 24, 2019 at 4:57 AM Cigdem Sengul <cigdem.sengul@gmail.com> wrote= :
Hello,=C2=A0

Thanks, Jim, this was helpful= , and it also triggered that I go back and read the introspection section o= f the core draft again.=C2=A0


=

=C2=A0

= [JLS] For introspection, but not for a= published token, the token could be =E2=80=9Crevoked=E2=80=9D by the RS.= =C2=A0 In this case a new introspection check would lead to that informatio= n.=C2=A0 There may be ways to deal with this in the introspection dialog an= d not need to be called up here.=C2=A0 The question would be does the exi f= ield mean =E2=80=93 recheck the token or discard the token.=C2=A0


Understood.= We definitely need to clarify here what we do with exi field if it exists,= and if it doesn't exist. The MAY language we used in the draft is not = appropriate if exi does not exist.=C2=A0
We considered the expira= tion time in the introspection response as a revocation signal and hence RS= discards the token.=C2=A0 (The basic flow was: RS receives a token, intros= pects it, caches the result and then when it expires, it revokes the token = - which may next lead to different steps depending on the version of the MQ= TT.)
But if introspection is done to handle the case of dynamic a= uthorisation decisions, and exi would signal a recheck indeed.=C2=A0=C2=A0
Will clarify.=C2= =A0

Thanks,
--Cigdem=C2=A0
<= div>
=C2=A0

=C2=A0

Jim

=C2=A0

=C2=A0

7. That is correct. Will add the clarification.=C2=A0

<= /div>

=C2=A0

Thanks,

= --Cigdem=C2=A0

= =C2=A0

=C2=A0

=

=C2=A0

=C2=A0

= On Wed, May 22, 2019 at 10:58 PM Jim Schaad <ietf@augustcellars.com> wrote:

Thanks for= the updates from my last message.=C2=A0 This has helped quite a bit.
1.=C2=A0 A discussion of the use of raw public keys rather than certifica= tes for
the server may be in order.=C2=A0 This can refer to the same RPK= issues from the
current DTLS document.=C2=A0 It may also be that this j= ust uses normal
certificate processing and that should be noted as well,= but some discussion
of deciding if the subject name/alt name matches th= e token returned from the
AS.

For the connect message there are a= couple of issues that need to be thought
about.

2.=C2=A0 What it= ems are required to be in the connect message.=C2=A0 The response to
my = last message suggested that a client identifier is required to be presentbut that is not documented.

3.=C2=A0 It is not completely clear wh= at portions of the CONNECT message are
being covered by the signature/MA= C value.=C2=A0 As an example, is the password
field omitted entirely or = is it set to a zero length password.=C2=A0 In addition
to this, from the= couple of implementations that I have looked at the entire
packet is no= t passed out of the base server code for authentication
purposes.=C2=A0 = This might need to be taken into account in terms of what is used
for th= e body and how it is constructed.=C2=A0 (As a side note, the
implementat= ions that I have looked at so far also think that the password is
a text= string rather than a binary value which is going to be a short term
iss= ue as well.)

4.=C2=A0 I must admit that I am disappointed that there= is no challenge response
mechanism in the MQTT specifications.=C2=A0 I = don't know that anything can be
done at this point about it but ther= e are some security issues that need to
be highlighted because of this i= n the security considerations section.=C2=A0 Only
the v3 seems to have t= his problem.=C2=A0 Also doing the channel binding would
deal with this p= roblem as well.=C2=A0 Might just need some general discussions
around th= e channel binding text.

5.=C2=A0 Is there an intention to provide a = "standard" format for the scope field
or just to leave it as a= d hoc?

6.=C2=A0 It might be reasonable in section 2.1.3 to note that= even if a result is
cached, that cached check should be limited for a s= pecific amount of time to
recheck if the token is still active.=C2=A0 Mo= re of an issue in terms of how long
to cache for introspection.

7= .=C2=A0 In section 2.1.4 - I would presume that the last paragraph should b= e
extended to say that the token is stored only for the length of theconnection.=C2=A0 That is the token always needs to be supplied every time= a
connect message is sent.

Jim


______________________= _________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listi= nfo/ace

_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
--0000000000004a8428058d5616ad-- From nobody Fri Jul 12 09:52:06 2019 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 CBCAE12026D; Fri, 12 Jul 2019 09:52:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 YyXcTvPUTplM; Fri, 12 Jul 2019 09:52:02 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FB5E1201E6; Fri, 12 Jul 2019 09:52:02 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 12 Jul 2019 09:51:55 -0700 From: Jim Schaad To: CC: Date: Fri, 12 Jul 2019 09:51:55 -0700 Message-ID: <006501d538d2$1e344f90$5a9ceeb0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AdU3eNA6c9mofJxHSGiD+iIXzRM8LQ== X-Originating-IP: [73.180.8.170] Archived-At: Subject: [Ace] Comments on draft-ietf-ace-key-groupcomm-02 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: Fri, 12 Jul 2019 16:52:05 -0000 1. Figure 2 is a bit odd in that the marker for the ACE framework appears to be attached to the Dispatcher and not to the set of messages w/ the AS and KDC. One of the things you might want to consider is to move to the V3 xml2rfc language where you can do this is SVG and get a cleaner picture. (Although this requires some changes on the datatracker and I am not sure how fast they are coming in.) 2. Section 3 - I am not sure that the last line of the second paragraph matches what you are doing in this document. I would expect that there is either no content type of ace+cbor as a general rule. 3. Section 3.1 - I already noted this but I think you need to be able to specify multiple elements in the scope. Look at the scope definition in the MQTT draft. Additionally - is the default common to implement one or the only one? 4. Section 3.3 - Is there going to be a method to get these values if I post the token as part of a symmetric DTLS connection to the KDC? 5. Section 4.1 - I don't like signing just the nonce from the KDC for client_cred_verify - never sign something that you are not supplying some data for or you have an oracle. 6. Section 4.2 - I am wondering if you considered using 'cnf' to in all of the places where you are passing keys around? 7. Section 6 - The end of the first paragraph is confusing me. I don't understand the conditions and actions that are being documented here. 8. I am trying to understand what the structure that this is placing on the KDC is, at least in concept. If you start with KDC has resources /post tokens here /group id 1 /group id 2 ... /group id n So far I have no problems with this. You next apparently have the conceptual structure of /group id x /scope 1 /scope 2 /scope 3 Now the problem I have with this is that all of these scopes are going to have the same group id and thus will have the same group keying context. If this is the case, then I am not sure that I fully understand why having multiple scopes makes any sense. Jim From nobody Fri Jul 12 12:03:13 2019 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 181791201E0; Fri, 12 Jul 2019 12:03:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 MSzCkIkw6O9L; Fri, 12 Jul 2019 12:03:05 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7915120271; Fri, 12 Jul 2019 12:03:01 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 12 Jul 2019 12:02:56 -0700 From: Jim Schaad To: CC: Date: Fri, 12 Jul 2019 12:02:55 -0700 Message-ID: <008d01d538e4$6b41f000$41c5d000$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AdU40jZb/pylaZXkTd66J5tRntf3lw== X-Originating-IP: [73.180.8.170] Archived-At: Subject: [Ace] Comments on draft-ietf-ace-key-groupcomm-oscore-02 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: Fri, 12 Jul 2019 19:03:07 -0000 1. Abstract - You should probably be referencing draft-ietf-ace-key-groupcomm. 2. How much can we simplify this document is you don't duplicate all of the text from key-groupcomm? 3. See comment on the other document about using cnf. Given the amount of duplication it is really hard to read these two documents together as one is never sure if they are going to contradict each other. Jim From nobody Wed Jul 17 05:27:03 2019 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 87951120094 for ; Wed, 17 Jul 2019 05:27:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, 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 hfmvFC8mdWEr for ; Wed, 17 Jul 2019 05:26:59 -0700 (PDT) Received: from NAM05-DM3-obe.outbound.protection.outlook.com (mail-eopbgr730041.outbound.protection.outlook.com [40.107.73.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAF8512008F for ; Wed, 17 Jul 2019 05:26:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZRaS8YGWiqLYV5AVhebScqx0/Ix8YEkN6Edq6TIVWFrllNat+nZ1ZJC6f1fgMzzsWfzbLbg2QnEuHY+0yljTFAf+kgfrG1ekBKZZNJhioNVJVYNcgoCumK+qZ07iYybllxI4Xo/uQO67yq/DNAnC9lSsl2hAcNNrxJSI4oEGksgcL2+rGXsaCdyAbLbgnHCPlULi294YfT/2FaldC6rI1FNys2SduAWiVZLJDOzZsngrhfvSqHqBgtBDSyjbGtcMVf3oTlLh2yBUFMUtb8Vh76da9G8VTWZPU6lMc6eTJ34G/lFQfg4Kh8ogETk58JmRiXG/ZOWXMpSlCsKGhtbLcQ== 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-SenderADCheck; bh=ihvXBgjOxEo4pajh2zN8WAlZuwdT7Lj3qxM2a9IcClc=; b=nm/uy2+vqrC4PIYxlVXwWwAoKN3Snp8+j8C5UPd8WqXpl8E8R0hYnmsLnkT6xa9LwsgBCuDq1Pm4dyC9K8O9LS5WUgjGjjk/SKIbhr7JGfGigh2AodHmupD4UBE6NI83bKTpnPHM29Q8rzjTS3GPHMRfve7biEnJM3uiZw6I+7186f01KCfkzAlT6dt+ifDDlFo/9I0YG5Dp3J/nFbubUI7kG5DJ3qxIQqkjH1794KHcQqXaOVKgVoosC6DzAxw7s0u4rDylAjTHImkMd2jWvBJ8naf+spwF8dd1w9bHgmAjhxCd6A0caiJeEomogHmfoGTbjMJWvlsmr+s5plCXiA== 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=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ihvXBgjOxEo4pajh2zN8WAlZuwdT7Lj3qxM2a9IcClc=; b=qebG9lIPFO/1yKN5nI1q9jSHv4NGs/XbMGJqPM2L66/vxeYAcot3FK3d+foh4PBlrlnTjDjzc3F/CzwFlb1Egj+CnhVGUObk6m6iSUGDHn73ELCAOjofp/jGP8KikPZd0Ee5rhTR7EiMmM5XM4Ur3fUZMyoHf/rHNqeqSRxOJLA= Received: from DM6PR15MB3531.namprd15.prod.outlook.com (10.141.164.29) by DM6PR15MB3418.namprd15.prod.outlook.com (20.179.52.29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2073.14; Wed, 17 Jul 2019 12:26:57 +0000 Received: from DM6PR15MB3531.namprd15.prod.outlook.com ([fe80::24e9:771d:1846:da08]) by DM6PR15MB3531.namprd15.prod.outlook.com ([fe80::24e9:771d:1846:da08%5]) with mapi id 15.20.2073.012; Wed, 17 Jul 2019 12:26:57 +0000 From: Daniel Migault To: Ace Wg Thread-Topic: ace@IETF105 Thread-Index: AdU8mqOd8J3b0CyqQzeyMuC+yHRe5A== Date: Wed, 17 Jul 2019 12:26:57 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=daniel.migault@ericsson.com; x-originating-ip: [96.22.11.62] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 8fb00276-87fc-435f-ad08-08d70ab20f87 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:DM6PR15MB3418; x-ms-traffictypediagnostic: DM6PR15MB3418: x-ms-exchange-purlcount: 3 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:5797; x-forefront-prvs: 01018CB5B3 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(376002)(39860400002)(346002)(366004)(396003)(199004)(189003)(5660300002)(4743002)(74316002)(26005)(6436002)(14454004)(478600001)(86362001)(81166006)(66446008)(6116002)(64756008)(790700001)(7736002)(66556008)(3846002)(54896002)(55016002)(66476007)(966005)(6306002)(33656002)(66946007)(81156014)(68736007)(76116006)(256004)(9686003)(71190400001)(53936002)(6916009)(71200400001)(8936002)(7696005)(558084003)(66066001)(44832011)(8676002)(52536014)(99286004)(25786009)(316002)(6506007)(2906002)(9326002)(186003)(102836004)(486006)(476003); DIR:OUT; SFP:1101; SCL:1; SRVR:DM6PR15MB3418; H:DM6PR15MB3531.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: e9dWm+pqJwzKwJ5loVHcWQ7oeSEThX83G72qYctHcjeMnUqTy65ncYwW3qZt/wg2m3oUnw6LoGret76sGiTUeWupPCn/zmfrrAceffU1Wea+oD5nK/w1Ic/ozp2sBZGasDsw2k7ZaIQiAI42A9TclXf2/h9PDUS6D9pcWRfoireDj+Yf7qJEHfTszShfiz25R3XObNTle6kWWCnOCNoBVhyjGJu88QHlqnlV569wyewMvU09piBEMtMI5IEtgxkRiXjfGdzUZauJ4GVPlVWV4ZE43m4tmX22Aoty5wKqoa0sSzmpz4pZCYJ6BzSdRbfW77+GzL/PnKbDhNds0SrMZ3XzCQBiWMH/jXWBDqmKkl794PUO9MXTZavSC+1DVXuIRJ+mxxDYb5MgCvQcShVkMQAb9uAMVPuqHfsCMzudd20= Content-Type: multipart/alternative; boundary="_000_DM6PR15MB3531E76D2CDDC117AEFA84DAE3C90DM6PR15MB3531namp_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8fb00276-87fc-435f-ad08-08d70ab20f87 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jul 2019 12:26:57.6351 (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: daniel.migault@ericsson.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR15MB3418 Archived-At: Subject: [Ace] ace@IETF105 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, 17 Jul 2019 12:27:01 -0000 --_000_DM6PR15MB3531E76D2CDDC117AEFA84DAE3C90DM6PR15MB3531namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, The current agenda has been posted [1]. If you want to add a topic please l= et us know as soon as possible. If you are presenting, please provide the m= aterial by Sunday 21. Yours, Daniel [1] https://datatracker.ietf.org/meeting/105/materials/agenda-105-ace-00 --_000_DM6PR15MB3531E76D2CDDC117AEFA84DAE3C90DM6PR15MB3531namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

The current agenda has been posted [1]. If you want = to add a topic please let us know as soon as possible. If you are presentin= g, please provide the material by Sunday 21.

 

Yours,
Daniel

 

[1] https://datatracker.ietf.org/meeting/105/materia= ls/agenda-105-ace-00

--_000_DM6PR15MB3531E76D2CDDC117AEFA84DAE3C90DM6PR15MB3531namp_-- From nobody Fri Jul 19 04:21:46 2019 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 CD17712016D; Fri, 19 Jul 2019 04:21:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=risecloud.onmicrosoft.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 R25yIMBI-hH9; Fri, 19 Jul 2019 04:21:41 -0700 (PDT) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80078.outbound.protection.outlook.com [40.107.8.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A457112001E; Fri, 19 Jul 2019 04:21:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=c3SueMc8ZN2wmc96LQDTeA29ogiDFysC/jY9DZUdz8IL4o7rQMMG86Tk4P2q29Xs6ZpqIBbtJGajJruiuo/+MOlZEDQ5Z6cIQKfZOvQ8XBm+ia13bK415EQjT0OI64hwY/ZtoBm0uaE5Ji49fZU3zGF5YL4DJQwhLXEZTmAhTEo5VRscL+VKNFBPGRlston2UP7qZvZ8faAtFXk3Xh6nwfdtTRkYfAOPlJcJ0RDwQDggRbtVdL8p+pKOifslYNg0r0UqqtSex9KFyxEbBit5rm3NXhI7gtv+7Gw5DJa1yxn9Eejs70HFuAdly7R4CyqKIPrSmsZ1kuAtE3aXvHJGnw== 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-SenderADCheck; bh=WHNgpcXnGoEG8DRC93B0/kQeAXfj5k/PhE0u5bXq+2Q=; b=lmVWRTOMQ3YcCoDNVWvoJrbqBtTXUBKahh8STtf/65uSmMXsu3rjdriYkaS9keOmN9ExorFTuPE2xYglbIBiKe5BM6xmjDY/ajmDWEAdLPuDfK/YKEdtjbs6JJ29efZO014IsVKaESFcH7fsQdddJ3qi5u6dqog81hwxlbLYl5Wo9Avq+Mb+uDhzXrs0NAhfP7VFtHU/b3A/DMOxoNd6jY37rNagRrOY4nNPJDDOgWQh2h6NNWRXQ3UFx7bmHhf0V0m8JJaoyMNiD4l6bJ/u8tk4KErxlIqyWw1ytVM8LlE6U8BseOFkcHHl/BeKEnlVyzOXcIsHz2eyUE8BGbcI+g== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass (sender ip is 194.218.146.197) smtp.rcpttodomain=ietf.org smtp.mailfrom=ri.se;dmarc=bestguesspass action=none header.from=ri.se;dkim=none (message not signed);arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=RISEcloud.onmicrosoft.com; s=selector2-RISEcloud-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=WHNgpcXnGoEG8DRC93B0/kQeAXfj5k/PhE0u5bXq+2Q=; b=nHaQErnQViGwE0VMczjDJFnCuLb5AbGtGTPERb5c8QwvUmuwcbaRp2akc7/L9EHar5Ijd2rHajFiDkXJSU2d9GmRrXV+VXfFGRxpHD9AFQxfwbaIggawOB8hFdDC3By6V6UKevC8IkHXe0dKYC2kdapFjo4zGVPDmKYEyPmL5CY= Received: from VI1P189CA0018.EURP189.PROD.OUTLOOK.COM (2603:10a6:802:2a::31) by VI1P18901MB0221.EURP189.PROD.OUTLOOK.COM (2603:10a6:801:9::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2094.11; Fri, 19 Jul 2019 11:21:38 +0000 Received: from AM5EUR02FT055.eop-EUR02.prod.protection.outlook.com (2a01:111:f400:7e1e::208) by VI1P189CA0018.outlook.office365.com (2603:10a6:802:2a::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.2094.14 via Frontend Transport; Fri, 19 Jul 2019 11:21:38 +0000 Authentication-Results: spf=pass (sender IP is 194.218.146.197) smtp.mailfrom=ri.se; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=ri.se; Received-SPF: Pass (protection.outlook.com: domain of ri.se designates 194.218.146.197 as permitted sender) receiver=protection.outlook.com; client-ip=194.218.146.197; helo=mail.ri.se; Received: from mail.ri.se (194.218.146.197) by AM5EUR02FT055.mail.protection.outlook.com (10.152.9.191) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.20.2052.19 via Frontend Transport; Fri, 19 Jul 2019 11:21:37 +0000 Received: from [10.112.134.122] (10.100.0.158) by sp-mail-2.sp.se (10.100.0.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Fri, 19 Jul 2019 13:21:37 +0200 To: CC: "ace@ietf.org" From: Ludwig Seitz Message-ID: <7000332e-9853-fcc5-c98f-b2d8f2fb4060@ri.se> Date: Fri, 19 Jul 2019 13:21:37 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms000803010206060004050600" X-Originating-IP: [10.100.0.158] X-ClientProxiedBy: sp-mail-2.sp.se (10.100.0.162) To sp-mail-2.sp.se (10.100.0.162) X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:194.218.146.197; IPV:NLI; CTRY:SE; EFV:NLI; SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(376002)(346002)(396003)(136003)(2980300002)(189003)(199004)(16586007)(5660300002)(58126008)(235185007)(186003)(106002)(69596002)(4326008)(16576012)(336012)(5024004)(2906002)(14444005)(16526019)(2616005)(2351001)(33964004)(31686004)(356004)(316002)(44832011)(26005)(386003)(65826007)(476003)(486006)(22756006)(126002)(40036005)(31696002)(86362001)(450100002)(6116002)(36756003)(568964002)(3846002)(70206006)(70586007)(7736002)(6916009)(64126003)(478600001)(8676002)(81166006)(68736007)(53936002)(8936002)(65806001)(305945005)(81156014)(71190400001)(65956001); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1P18901MB0221; H:mail.ri.se; FPR:; SPF:Pass; LANG:en; PTR:InfoDomainNonexistent; MX:1; A:1; X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: ca8a4aeb-bc6f-43ce-ce5a-08d70c3b440a X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(4709080)(1401327)(2017052603328)(7193020); SRVR:VI1P18901MB0221; X-MS-TrafficTypeDiagnostic: VI1P18901MB0221: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-Forefront-PRVS: 01039C93E4 X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Message-Info: E8QQYbWuQHvP/cc3maJcIOeHvq9Mkmbdp+hCXtEVsOEAU0Em0KcfEHo/YFt+/Oiwi1lT1bhDUoPKcGkr8i+wDrO+2ijYCrWUKLhV2pPgS+/jQsEDHWo+92z0JAM2l+JdPbWzsbQylvxkOn20EYzP4CE8TXRM2AWyRE/d2XsDQIc2Gu3XUqVCbTFJM5iv/YAYNLRtFhs5lfFd8lHFnEbRls/QIclJeGfSwGJQ7LSOPh6Bgr68Px5rZOsmQ3+j4IxchUoA4HhdGqrFzRafl4DSGvIoychcnMiU28iAkWb0Xx09cCiOk1zv4AlxbZ86Eel9+rWg8t6EEH1xT+wbbTgdG23iPYhIYYITbsourY6aLzq0v7hwW89xX4RfGf9KbyXWm5u9k6rYYVs2VO4vSq1x6qG38PZ2iK/IaHKG2ssPQlw= X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Jul 2019 11:21:37.9676 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: ca8a4aeb-bc6f-43ce-ce5a-08d70c3b440a X-MS-Exchange-CrossTenant-Id: 5a9809cf-0bcb-413a-838a-09ecc40cc9e8 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=5a9809cf-0bcb-413a-838a-09ecc40cc9e8; Ip=[194.218.146.197]; Helo=[mail.ri.se] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1P18901MB0221 Archived-At: Subject: [Ace] Review of draft-ietf-ace-key-groupcomm 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: Fri, 19 Jul 2019 11:21:44 -0000 --------------ms000803010206060004050600 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable Hello Francesca, Marco, I have finally managed to read the whole of draft-ietf-ace-key-groupcomm = and have a few comments for you: Figure 2: I suggest you move the "Defined in ..." to the left they way it is now, it looks as if the Dispatcher was defined in the ACE = framework. =3D=3D "3.1. MUST contain ... 'grant_type'" This is no longer true. Grant_type was made optional in one of the=20 latest updates of the ACE framework. When it is absent,=20 grant_type=3Dclient_credentials is assumed as default. =3D=3D 3.3 "... and includes the following parameters: " How is that supposed to work? The framework defines sending of the token = to /authz-info as a CoAP POST, where the payload is the bytes of the=20 token. In order to include additional parameters you would have to=20 redefine this payload to be a CBOR map (as the OSCORE profile does). =3D=3D The whole section 3 talks about parameters send back and forth between=20 the client and the KDC without defining how these are carried. It seems=20 to be implied that there are CBOR maps in the payload, but that should=20 be made explicit, especially where it differs from what the framework=20 defines. =3D=3D 3.1 the text about the parameters in the client's post to the=20 /authz-info endpoint at the KDC talks about parameters "sign_info" and=20 "pub_key_enc" and claims they are specified in 3.3.1 and 3.3.2, but=20 these sections specify the parameters for the "AS request creation=20 hints" messages and not in this context. At least some clarification=20 should be added. =3D=3D Section 4 "If not previously established, the Client and the KDC MUST first establish a pairwise secure communication channel using ACE." This sentence is not strictly correct. Using what part of ACE? The ACE=20 framework just says that you should establish a secure communication=20 channel, it's the specific profiles that define how these channels are=20 established. Please add some clarification. =3D=3D "The Client and the KDC MAY use that same secure channel to protect=20 further pairwise communications, that MUST be secured." This is very questionable use of requirements language. How do I claim=20 or test conformance with the second MUST? =3D=3D Section 4: "The same set of message ..." should be "messages" =3D=3D " Note that proof-of-possession to bind the access token to the Client is performed by using the proof-of-possession key bound to the access= token for establishing secure communication between the Client and the KDC." This may or may not be true for a specific secure communication protocol (e.g. think of DTLS with X.509 certificates without client=20 authentication). You need to require this from the underlying secure=20 communication protocol. =3D=3D 4.1 "The endpoint in the KDC is associated to the 'scope' value of the=20 Authorization Request/Response." Associated how? This is too unspecific to lead to interoperable=20 implementations. I would like to see this association specified in detail= =2E =3D=3D 4.2 "as defined in the "ACE Groupcomm Key" registry, defined in Section=20 11.5." If possible, rephrase this to avoid the double use of "defined". =3D=3D 5.2 "If the leaving node wants to be part of a group with fewer roles, it=20 does not need to communicate that to the KDC, and can simply stop acting = according to such roles." There are legitimate cases where a node might want to explicitly=20 deactivate roles it is currently using (principle of least priviledge)=20 and not just stop using them. =3D=3D 6. "Then, if it wants to continue participating in the group communication, the node has to request new updated keying material to= the KDC." should be "... keying material from the KDC." =3D=3D Sections 8. and 9. Would be nice if there also were back-references to where those=20 parameters are defined in the draft. /Ludwig --=20 Ludwig Seitz, PhD Security Lab, RISE Phone +46(0)70-349 92 51 --------------ms000803010206060004050600 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DT0wggYWMIID/qADAgECAg8BaKlzCTJTye3phLaz/cIwDQYJKoZIhvcNAQELBQAwRzELMAkG A1UEBhMCU0UxFDASBgNVBAoMC1RlbGlhU29uZXJhMSIwIAYDVQQDDBlUZWxpYVNvbmVyYSBD bGFzcyAyIENBIHYyMB4XDTE5MDIwMTE0MjUxNVoXDTIxMDIwMTE0MjUxNFowgYsxCzAJBgNV BAYTAlNFMS4wLAYDVQQKDCVSSVNFIFJlc2VhcmNoIEluc3RpdHV0ZXMgb2YgU3dlZGVuIEFC MRUwEwYDVQQDDAxMdWR3aWcgU2VpdHoxEjAQBgNVBAUTCUx1ZHdpZ1NlaTEhMB8GCSqGSIb3 DQEJARYSbHVkd2lnLnNlaXR6QHJpLnNlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAlJNmRfcsto5I/yXrBIi9QroZtfAMttc1Eznv5iPCK++eFUArODhITO7k9rtlQX5D8vYF v4vzZex58YWZhvGMzDj9FdpD/PHKOxL/frlrreChuissPWo5M88DmL3V1oyGzvgeRqaafpEi 0/2+gezMFlABm/BXj3/0Fiw5Sxub7essE27EtDK05nAbUB69kfLHBEytbTAuuSb11hC1dpTf itMZkzSFwsBCyPtIv3GRt9xgnOPK4RRpHidv1GLYXNQQ7xEGhFy4qbZ2NSfM+56SSRswvW9P 5n81ZmZ4FWkiJouUIYtZ2ifncBJL4DC2chjsywDEz5No7kYrGxc5oOm1YQIDAQABo4IBuDCC AbQwHwYDVR0jBBgwFoAUnhn/5Q06/gCXFT9p8dxaPKoMlIMwHQYDVR0OBBYEFKZHZ8MZNNP5 tXMPjeFiw01pUWbtMA4GA1UdDwEB/wQEAwIFoDBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEB DDA6MDgGCCsGAQUFBwIBFixodHRwczovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEu Y29tL0NQUzAdBgNVHREEFjAUgRJsdWR3aWcuc2VpdHpAcmkuc2UwTQYDVR0fBEYwRDBCoECg PoY8aHR0cDovL2NybC0yLnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYWNsYXNz MmNhdjIuY3JsMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjB+BggrBgEFBQcBAQRy MHAwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnRydXN0LnRlbGlhLmNvbTBFBggrBgEFBQcw AoY5aHR0cDovL2NhLnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYWNsYXNzMmNh djIuY2VyMA0GCSqGSIb3DQEBCwUAA4ICAQCk0GOalOCjEJObuBeMg0QREtBP/2ona16npn+T v5R3Vjk5UsQdOaOosgVjADX68C83dyfPiWR4UfNJoTBcM8JLpEXIm+xC4BiDPTPHYvgkhgXt 9VWCRWXOMfT/UPXjiGsbPuNWja1LQzF5KOmM826kHVZItHuDY6kJLE4OZ+apFvVKtSLQJJLA 4MlDVwp5+XsZi4cftcX5HdgLdChodUPKq3XVfALfXM/p81XEFBTYOHNplr3cQytDQjsnCZnS Ic4UpsxrArNxDO9+AKu/s1Fbq494AhHj4oHcg4DIjhHUzbPCLP19Gqp4dflr/V7Ulg3d+4Zh bmSAn1cffrzvvkjVrqMgQOoHQTl2QyO9n/oJ/9CSYRmhFsQMPun9LM/p5l58dTZp53B3LgA6 FFrxnntlZnTPh3bvsMJvUQ+AoiXyQwnkdxUrhoM+gUz36t3JSA8g48h7BhPsnwQ/YrarAhJ8 ifuzykTQmDseWLjJKyFflddy/azAlPQjgSMMWOZCo2s+l+WwPISf33nls2Aec/vvG5auYHS6 pwWuVKuwZTPgJfHanZTNpBM5y0jVBz6tr8AHZypnCONgyUYA4uec3v5oWz4FvLEnlKnMGoK3 OeFGvfHG0tbP25HbdN3AJYP0EUo56wfkBOYsnmn4mEYdk2GHkJNfaQRBJljH0T7TOcmcDjCC Bx8wggUHoAMCAQICEGN8C9eFpb8p2mAtfE16cLEwDQYJKoZIhvcNAQELBQAwNzEUMBIGA1UE CgwLVGVsaWFTb25lcmExHzAdBgNVBAMMFlRlbGlhU29uZXJhIFJvb3QgQ0EgdjEwHhcNMTQx MDE2MDgzOTMwWhcNMzIxMDE2MDUwNDAwWjBHMQswCQYDVQQGEwJTRTEUMBIGA1UECgwLVGVs aWFTb25lcmExIjAgBgNVBAMMGVRlbGlhU29uZXJhIENsYXNzIDIgQ0EgdjIwggIiMA0GCSqG SIb3DQEBAQUAA4ICDwAwggIKAoICAQC0PpW2qcWGnStqfa5DjrUi79Kz2SySUlJ1kiEQ1Pd/ LWbnsEwFYPqOJwAf6ZtEDtQ/9Z1VkVNQ6MkD++keqk7648x0YANgMyiJsWrbd0TKOObtlXdJ pb5qesJ5nOAdVeL3z6lgrkZx+fsUfTV+lLRGRh2+RWzZTjPAvKotY3nAwXCHtwI5v3FKuR10 aJ9+CEOka02KSUzGjcGZwMk2io0DxLELf1gPRvqE9xmn4ioXLqpluozb4Fo9ewydufTLQc3/ I63uPQh8BlLPPIGzWb4iBDq2zbWlbx0KlH/UlUZ7fjzp6N6cAqZ2NnDaCOnnIRfUYeNXFG8/ aiBeFOpEeEpclr5QUwr9HLKL1QiyQtc/wW8acQFoKuGi8myiAch7k7S0rmU5gT05je+OTzWh Oaw7gmDdndYY1mjkPkzpQ+hxyfnwUsAitUq9j0imFOLxKWLH4QNbyuDIMvDyezzJWzMy3XPB LiLSH9CBLVQHRoQ+WW8xD4rnmvQtoGZM72og2iNf4/JCHL1AJYhQtaRjYgm3rhvAP0HhSVAB Z5aHM52ylJHC3JwUyuFm8S9A2ffY9rUTffMLWmDCnX0QAP9bKr6+ACogm4DBUj3ftYodI2TD 6F8+VjSFuCzGDPuCjK+fQ2c3wqziwFl+NgoGI9Vgc6x5+0ocKkiQAIYFaQ3SyGmI6QIDAQAB o4ICFTCCAhEwgYoGCCsGAQUFBwEBBH4wfDAtBggrBgEFBQcwAYYhaHR0cDovL29jc3AudHJ1 c3QudGVsaWFzb25lcmEuY29tMEsGCCsGAQUFBzAChj9odHRwOi8vcmVwb3NpdG9yeS50cnVz dC50ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5jZXIwEgYDVR0TAQH/BAgw BgEB/wIBADBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEBAjA6MDgGCCsGAQUFBwIBFixodHRw czovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQUzAOBgNVHQ8BAf8EBAMC AQYwgcYGA1UdHwSBvjCBuzBAoD6gPIY6aHR0cDovL2NybC0zLnRydXN0LnRlbGlhc29uZXJh LmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNybDB3oHWgc4ZxbGRhcDovL2NybC0xLnRydXN0 LnRlbGlhc29uZXJhLmNvbS9jbj1UZWxpYVNvbmVyYSUyMFJvb3QlMjBDQSUyMHYxLG89VGVs aWFTb25lcmE/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnkwHQYDVR0OBBYEFJ4Z /+UNOv4AlxU/afHcWjyqDJSDMB8GA1UdIwQYMBaAFPCPWTgAs/WPmpYM1ev6e6oX6BMSMA0G CSqGSIb3DQEBCwUAA4ICAQB5wuZFNXR5ko9cu7PcpIyH8xaoGfpimP2GTg7qVuL92D/idIlj pqMm93WC9mgL/Uy6DExoF8xSLurLaiajoU+VG6ZWg0F7P1AXARNt0RpWI5SphxBQYM2751S8 vC/22k8Vi+qpQVIREqQPVXCIEH7U6eCY9gEVzdq9l1yPoI8n0D2a8V6GCv0RVkmIpa16rNYD tTw4j3Ha56/Ua33C3qeZh1dIfkaU2h4CGHd2Em3v5LLMsEh8dqUeG9yIcCU+8RUgDahNxWMe MGxzrhwk8WBV6xeoQp20p7cSHbSbyHJURC1n+nVrgdh8hbw6WOgFhNA5tCPDZ0oSF+uHfj+b ioZE3AlYdcEqHJA9A9sO58F4/Qg/yp9oYuT0ZpKb4hmzeqDXvk5KRFNfHlhTt35i+qmas9wB 11MXbYd5WwqEhZH6HWO5H7XKJP7olxmEC0W3OKlpKafq1iPsBN5ycRfUrXFss0Ax6vpCq0XA 3LYePpQ44hOU+qrkR1M0a7Eo3++3TpP4cV+FZiO4aZYZ3yZftSRHwWpGiDBdWOdTKR2GJi7Z z/OxacrmwmM1Z+WcigldbG8f3IMnOLK4X0uXjhVeAHrhuttQuM8i+4TNXgsZbmfEKNDQIQPO /lbacsGHWFB/U2y6SXVEkZs2xIciRA0iZNTv7mbIL8SZmf5wpbjDCYHiCjGCAzgwggM0AgEB MFowRzELMAkGA1UEBhMCU0UxFDASBgNVBAoMC1RlbGlhU29uZXJhMSIwIAYDVQQDDBlUZWxp YVNvbmVyYSBDbGFzcyAyIENBIHYyAg8BaKlzCTJTye3phLaz/cIwDQYJYIZIAWUDBAIBBQCg ggGvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE5MDcxOTEx MjEzN1owLwYJKoZIhvcNAQkEMSIEII0dJ4K8lNGqigft1/nt3z2oz7gGUOEj3v2zuaau5S7T MGkGCSsGAQQBgjcQBDFcMFowRzELMAkGA1UEBhMCU0UxFDASBgNVBAoMC1RlbGlhU29uZXJh MSIwIAYDVQQDDBlUZWxpYVNvbmVyYSBDbGFzcyAyIENBIHYyAg8BaKlzCTJTye3phLaz/cIw awYLKoZIhvcNAQkQAgsxXKBaMEcxCzAJBgNVBAYTAlNFMRQwEgYDVQQKDAtUZWxpYVNvbmVy YTEiMCAGA1UEAwwZVGVsaWFTb25lcmEgQ2xhc3MgMiBDQSB2MgIPAWipcwkyU8nt6YS2s/3C MGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0D BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwIC ASgwDQYJKoZIhvcNAQEBBQAEggEAPZUTHGL4f49suO3Un1hjU90wZBYTsL13nAbBW6+8TUfp NIxsmkhJg6htT8Au8+pK2p+S02+LAmNr93hNavfCQeNv5WzAwOQEmElCKepT/s/Iyd/jK4FD 9/tB9JK03XFscH0OJLr3X/2SLKT1bJOHLNGvXuGExsegPtHr3KBw5zNc4vGVtYDyhqPPXa/R sm5u+MP/H10hkD0gPgSRUxz9c6kDuQsi5aRWln/MnPVbf40SNWXhYvVqzwLFWAzVpHpttjZf Z+fdtX7QNkFhWm+HoVO5iZqX2XA5fMrfRalL+C4M0Jb7jCgJlFoZTjeg0CSbociF4yMBlIEJ gEQRryZuIwAAAAAAAA== --------------ms000803010206060004050600-- From nobody Mon Jul 22 04:14:54 2019 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 D9923120164; Mon, 22 Jul 2019 04:14:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=risecloud.onmicrosoft.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 0EmLHLpBCEpj; Mon, 22 Jul 2019 04:14:49 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-eopbgr150072.outbound.protection.outlook.com [40.107.15.72]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 255C41200DB; Mon, 22 Jul 2019 04:14:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=BMKkmp6F0KJQOYr/D2a5CU2PRBcrHLBrCuWBtKoqdk7PaprMz0PR39h9OY/f/V6/b2nEoFV1IFBRIZfo62Mjuzx3Goc/nc2l5j3S5JqcNkxecJ17web4taJUvdJD3R3QfC4CfJAoj6+HOx/GrTNCOBmx+kOwpw1zy1TExUQiC6n789eidR7N+uE/u+l7ijdAjWIu7RUL56/YEm3xTCkshjfKSy4iUAoJk7BwfoubtpJjh+W+gCYvkJ/Q6rNVKhrBXSuz4v3DyHnbVRnAYoZxXBdlu6Yeu3U+cqk1lcZWWTAxHVEhbgXzUwnR4iOC4Xlbkah4C4opqHoGjU6vbsKanQ== 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-SenderADCheck; bh=twTtgK2U+DJs4c0W1cAeFdKG/mLpEjfwU6IZST5Ym+o=; b=O9wH5hab/xqfYxjqPA1eaMFL1+EDe+QYCPGUDYkDZatCqYVoTndfr0zpSJgn9wE2GWMO8vkkM49Db5hNQRt5jhfEG5gltFpgUztXOa8+F7WQQnBboH+Z+PSmAiwGuqVTXKlKTNYoHCW1e8rBNnOAt96IDOZhViZzWQAbbisRmJxggyMcjuVnPvyropX7/KiG1O3t2Kk1tj9c8LiviGORMFUSvVkUhpC+61MrsmA/iMg7W+OcNUrFd0JXxj1yQH/8jG95meB4Nh9o/mcAxj/byQTpyEiTcbDoaYMl/P/y0eBeNB18IBT6fjncB04rNfOkN6sAcQAcuBFirWbLv+C+ZQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass (sender ip is 194.218.146.197) smtp.rcpttodomain=ietf.org smtp.mailfrom=ri.se;dmarc=bestguesspass action=none header.from=ri.se;dkim=none (message not signed);arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=RISEcloud.onmicrosoft.com; s=selector2-RISEcloud-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=twTtgK2U+DJs4c0W1cAeFdKG/mLpEjfwU6IZST5Ym+o=; b=E0kB+t3NrvL/5eFbociNPky4K/pS9cHojNaYgMe0uIh/ylo1M+y1o5JGzA1dpSkRg/aVLrN7aX3l52CjAPuRhcf0n6wbHFNtMbDpwqxxASS6kUv+ZU3dkHqGjNhUHB45YsC8IP9SGXoErfWGEBVpnqKoNDeQBsD8Bk6GcpM724E= Received: from HE1P18901CA0022.EURP189.PROD.OUTLOOK.COM (2603:10a6:3:8b::32) by VI1P18901MB0221.EURP189.PROD.OUTLOOK.COM (2603:10a6:801:9::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2094.16; Mon, 22 Jul 2019 11:14:46 +0000 Received: from AM5EUR02FT012.eop-EUR02.prod.protection.outlook.com (2a01:111:f400:7e1e::202) by HE1P18901CA0022.outlook.office365.com (2603:10a6:3:8b::32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.2094.12 via Frontend Transport; Mon, 22 Jul 2019 11:14:46 +0000 Authentication-Results: spf=pass (sender IP is 194.218.146.197) smtp.mailfrom=ri.se; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=ri.se; Received-SPF: Pass (protection.outlook.com: domain of ri.se designates 194.218.146.197 as permitted sender) receiver=protection.outlook.com; client-ip=194.218.146.197; helo=mail.ri.se; Received: from mail.ri.se (194.218.146.197) by AM5EUR02FT012.mail.protection.outlook.com (10.152.8.82) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.20.2052.19 via Frontend Transport; Mon, 22 Jul 2019 11:14:46 +0000 Received: from [10.112.134.122] (10.100.0.158) by sp-mail-2.sp.se (10.100.0.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Mon, 22 Jul 2019 13:14:46 +0200 To: CC: "ace@ietf.org" From: Ludwig Seitz Message-ID: Date: Mon, 22 Jul 2019 13:14:23 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms080609060609060809080201" X-Originating-IP: [10.100.0.158] X-ClientProxiedBy: sp-mail-3.sp.se (10.100.0.163) To sp-mail-2.sp.se (10.100.0.162) X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:194.218.146.197; IPV:NLI; CTRY:SE; EFV:NLI; SFV:NSPM; SFS:(10009020)(4636009)(136003)(39860400002)(346002)(396003)(376002)(2980300002)(199004)(189003)(568964002)(44832011)(476003)(2616005)(126002)(86362001)(65956001)(8936002)(336012)(65806001)(31696002)(2351001)(70206006)(2906002)(68736007)(70586007)(235185007)(5024004)(14444005)(6116002)(3846002)(69596002)(81156014)(81166006)(5660300002)(58126008)(486006)(316002)(16576012)(16586007)(53936002)(71190400001)(8676002)(16526019)(36756003)(186003)(106002)(22756006)(40036005)(7736002)(386003)(305945005)(6916009)(64126003)(33964004)(4326008)(65826007)(6666004)(356004)(22746008)(450100002)(31686004)(26005)(478600001); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1P18901MB0221; H:mail.ri.se; FPR:; SPF:Pass; LANG:en; PTR:InfoDomainNonexistent; A:1; MX:1; X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: c19acef4-47e3-46eb-7a3a-08d70e95cdf8 X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(4709080)(1401327)(2017052603328)(7193020); SRVR:VI1P18901MB0221; X-MS-TrafficTypeDiagnostic: VI1P18901MB0221: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-Forefront-PRVS: 01068D0A20 X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Message-Info: CEf+L9Iu2ws8clDu9rwMsJAzXwZhQESSi5zNoN7oNP7ChHPj6+AHyULFAR++3lwIMvl1TkNAUfDnyi1QrRFsc0Ci05aolqVLPKQujrfFUpkQvS+Omuj/LVe/Gp/vEWRd1P4tAfMnM6DJCGxCSiXbsn+6qMlhVwRxzoCkRQW9cQ8rMPxvHjoa/WkNOwlsVs6NrkPtAafRCo3SRgyahAubl0Iw9lBP/S0RNEAuCejfMutDvne7DfXSY6xiDXrPoHaxwKfVm7lWvudO/JuPaIi74ggyOktd9gY6qpy6rx43H+UqToh3OsePgUGlhTWmZlGgXP3L+9ImH/Y0pEO422zZtS0aE/24rkjP7KQiou3K4tgvZ9H3Q5qjZhBiaJeBmG5UyRMsMeNRYvCzRVKGEbD6BZQ7VGEigFxep9sHMP4MHpg= X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Jul 2019 11:14:46.3793 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: c19acef4-47e3-46eb-7a3a-08d70e95cdf8 X-MS-Exchange-CrossTenant-Id: 5a9809cf-0bcb-413a-838a-09ecc40cc9e8 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=5a9809cf-0bcb-413a-838a-09ecc40cc9e8; Ip=[194.218.146.197]; Helo=[mail.ri.se] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1P18901MB0221 Archived-At: Subject: [Ace] Review of draft-ietf-ace-key-groupcomm-oscore 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: Mon, 22 Jul 2019 11:14:53 -0000 --------------ms080609060609060809080201 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable Hello Marco, Jiye, Francesca, I have read draft-ietf-ace-key-groupcomm-02 and I have a few comments=20 for you: =3D=3D 1.1 "The URI of a join resource is fixed." How can that be a requirement? The Group Manager might also be a mobile=20 unit that changes address as it moves through different networks. Perhaps rephrase to "The URI-Path of a join resource is fixed"? =3D=3D 1.1 "Monitor: ... This corresponds to the term "silent server" used in=20 [I-D.ietf-core-oscore-groupcomm]." Any special reason for defining an separate equivalent term? Otherwise=20 this only makes the set of documents harder to read. =3D=3D 2. "To this end, the AS must signal the specific transport profile to use,=20 consistently with requirements and assumptions defined in the ACE=20 framework [I-D.ietf-ace-oauth-authz]." Note that in the ACE framework the AS does not have the obligation to=20 signal the profile, since the assumed base-case is that the profiles are = pre-configured and well-known in most constrained applications (this is=20 an update from previous versions of the ACE framework). =3D=3D All document: Update references to OSCORE to point to RFC 8613 =3D=3D 2. "2. The joining node transfers authentication and authorization=20 information to the Group Manager by posting the obtained Access=20 Token (see Section 4)." Although it is explained in section 4 you might want to mention already=20 here _where_ the information is POSTed (or replace "posting" with "sendin= g") =3D=3D 2. "5. The joining node and the Group Manager maintain the secure=20 channel, to support possible future communications." Maintaining such a channel is costly in terms of memory, is that really=20 a requirement? Also in the case of object security, speaking of a 'channel' is misleadin= g. =3D=3D 3.2 "Also, the 'profile' parameter ..." See previous comment on profile being optional in the ACE framework =3D=3D 4. "the Access Token post" I don't think this term is well-understood in general. I'd suggest=20 removing it with something less REST-centric for the uninitiated reader, = like e.g. "the sending of the Access Token to ..." =3D=3D 4.1 " Note that the CBOR map specified as payload of the 2.01 (Created) response may include further parameters," Note that the ACE framework does not specify this response payload to be = a CBOR map. Please explicitly state here that you are deviating from the = default payload format in the ACE framework. =3D=3D 4.2 "In case the joining node knows the encoding of public keys in the=20 OSCORE group, as well as the countersignature algorithm and possible=20 associated parameters used in the OSCORE group, the included public key=20 MUST be in a consistent format. " What is a "consistent format"? Please rephrase to be more specific. Or did you mean "compatible format"? =3D=3D 4.3 "That is, the public key has to be encoded as expected in the OSCORE=20 group, and has to be consistent with the counter signature algorithm and = possible associated parameters used in the OSCORE group." What is "consistent with the ... algorithms and ... parameters"? Did you mean "compatible"? =3D=3D 4.3 "The 'profile' parameter MUST be present and has value=20 coap_group_oscore_app (TBD), which is defined in Section 9.3 of this=20 specification." See comments on 'profile' before. =3D=3D 6. "In this case, the joining node MAY not provide again its own public key = to the Group Manager," This could be misunderstood to mean "MAY NOT ...", how about rephrasing=20 this to: "MAY choose not to provide ..." ? =3D=3D 7. "When doing so, the Group Manager MAY take a best effort to preserve the = same unchanged Sender IDs for all group members" This is incorrect use of requirements language. This 'MAY' can not be=20 tested and the arguments for claiming conformance to this requirement=20 would be quite diffuse. I suggest to require maintaining the Sender IDs. = Why should the GM change them in the first place? Regards, Ludwig --=20 Ludwig Seitz, PhD Security Lab, RISE Phone +46(0)70-349 92 51 --------------ms080609060609060809080201 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DT0wggYWMIID/qADAgECAg8BaKlzCTJTye3phLaz/cIwDQYJKoZIhvcNAQELBQAwRzELMAkG A1UEBhMCU0UxFDASBgNVBAoMC1RlbGlhU29uZXJhMSIwIAYDVQQDDBlUZWxpYVNvbmVyYSBD bGFzcyAyIENBIHYyMB4XDTE5MDIwMTE0MjUxNVoXDTIxMDIwMTE0MjUxNFowgYsxCzAJBgNV BAYTAlNFMS4wLAYDVQQKDCVSSVNFIFJlc2VhcmNoIEluc3RpdHV0ZXMgb2YgU3dlZGVuIEFC MRUwEwYDVQQDDAxMdWR3aWcgU2VpdHoxEjAQBgNVBAUTCUx1ZHdpZ1NlaTEhMB8GCSqGSIb3 DQEJARYSbHVkd2lnLnNlaXR6QHJpLnNlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAlJNmRfcsto5I/yXrBIi9QroZtfAMttc1Eznv5iPCK++eFUArODhITO7k9rtlQX5D8vYF v4vzZex58YWZhvGMzDj9FdpD/PHKOxL/frlrreChuissPWo5M88DmL3V1oyGzvgeRqaafpEi 0/2+gezMFlABm/BXj3/0Fiw5Sxub7essE27EtDK05nAbUB69kfLHBEytbTAuuSb11hC1dpTf itMZkzSFwsBCyPtIv3GRt9xgnOPK4RRpHidv1GLYXNQQ7xEGhFy4qbZ2NSfM+56SSRswvW9P 5n81ZmZ4FWkiJouUIYtZ2ifncBJL4DC2chjsywDEz5No7kYrGxc5oOm1YQIDAQABo4IBuDCC AbQwHwYDVR0jBBgwFoAUnhn/5Q06/gCXFT9p8dxaPKoMlIMwHQYDVR0OBBYEFKZHZ8MZNNP5 tXMPjeFiw01pUWbtMA4GA1UdDwEB/wQEAwIFoDBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEB DDA6MDgGCCsGAQUFBwIBFixodHRwczovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEu Y29tL0NQUzAdBgNVHREEFjAUgRJsdWR3aWcuc2VpdHpAcmkuc2UwTQYDVR0fBEYwRDBCoECg PoY8aHR0cDovL2NybC0yLnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYWNsYXNz MmNhdjIuY3JsMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjB+BggrBgEFBQcBAQRy MHAwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnRydXN0LnRlbGlhLmNvbTBFBggrBgEFBQcw AoY5aHR0cDovL2NhLnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYWNsYXNzMmNh djIuY2VyMA0GCSqGSIb3DQEBCwUAA4ICAQCk0GOalOCjEJObuBeMg0QREtBP/2ona16npn+T v5R3Vjk5UsQdOaOosgVjADX68C83dyfPiWR4UfNJoTBcM8JLpEXIm+xC4BiDPTPHYvgkhgXt 9VWCRWXOMfT/UPXjiGsbPuNWja1LQzF5KOmM826kHVZItHuDY6kJLE4OZ+apFvVKtSLQJJLA 4MlDVwp5+XsZi4cftcX5HdgLdChodUPKq3XVfALfXM/p81XEFBTYOHNplr3cQytDQjsnCZnS Ic4UpsxrArNxDO9+AKu/s1Fbq494AhHj4oHcg4DIjhHUzbPCLP19Gqp4dflr/V7Ulg3d+4Zh bmSAn1cffrzvvkjVrqMgQOoHQTl2QyO9n/oJ/9CSYRmhFsQMPun9LM/p5l58dTZp53B3LgA6 FFrxnntlZnTPh3bvsMJvUQ+AoiXyQwnkdxUrhoM+gUz36t3JSA8g48h7BhPsnwQ/YrarAhJ8 ifuzykTQmDseWLjJKyFflddy/azAlPQjgSMMWOZCo2s+l+WwPISf33nls2Aec/vvG5auYHS6 pwWuVKuwZTPgJfHanZTNpBM5y0jVBz6tr8AHZypnCONgyUYA4uec3v5oWz4FvLEnlKnMGoK3 OeFGvfHG0tbP25HbdN3AJYP0EUo56wfkBOYsnmn4mEYdk2GHkJNfaQRBJljH0T7TOcmcDjCC Bx8wggUHoAMCAQICEGN8C9eFpb8p2mAtfE16cLEwDQYJKoZIhvcNAQELBQAwNzEUMBIGA1UE CgwLVGVsaWFTb25lcmExHzAdBgNVBAMMFlRlbGlhU29uZXJhIFJvb3QgQ0EgdjEwHhcNMTQx MDE2MDgzOTMwWhcNMzIxMDE2MDUwNDAwWjBHMQswCQYDVQQGEwJTRTEUMBIGA1UECgwLVGVs aWFTb25lcmExIjAgBgNVBAMMGVRlbGlhU29uZXJhIENsYXNzIDIgQ0EgdjIwggIiMA0GCSqG SIb3DQEBAQUAA4ICDwAwggIKAoICAQC0PpW2qcWGnStqfa5DjrUi79Kz2SySUlJ1kiEQ1Pd/ LWbnsEwFYPqOJwAf6ZtEDtQ/9Z1VkVNQ6MkD++keqk7648x0YANgMyiJsWrbd0TKOObtlXdJ pb5qesJ5nOAdVeL3z6lgrkZx+fsUfTV+lLRGRh2+RWzZTjPAvKotY3nAwXCHtwI5v3FKuR10 aJ9+CEOka02KSUzGjcGZwMk2io0DxLELf1gPRvqE9xmn4ioXLqpluozb4Fo9ewydufTLQc3/ I63uPQh8BlLPPIGzWb4iBDq2zbWlbx0KlH/UlUZ7fjzp6N6cAqZ2NnDaCOnnIRfUYeNXFG8/ aiBeFOpEeEpclr5QUwr9HLKL1QiyQtc/wW8acQFoKuGi8myiAch7k7S0rmU5gT05je+OTzWh Oaw7gmDdndYY1mjkPkzpQ+hxyfnwUsAitUq9j0imFOLxKWLH4QNbyuDIMvDyezzJWzMy3XPB LiLSH9CBLVQHRoQ+WW8xD4rnmvQtoGZM72og2iNf4/JCHL1AJYhQtaRjYgm3rhvAP0HhSVAB Z5aHM52ylJHC3JwUyuFm8S9A2ffY9rUTffMLWmDCnX0QAP9bKr6+ACogm4DBUj3ftYodI2TD 6F8+VjSFuCzGDPuCjK+fQ2c3wqziwFl+NgoGI9Vgc6x5+0ocKkiQAIYFaQ3SyGmI6QIDAQAB o4ICFTCCAhEwgYoGCCsGAQUFBwEBBH4wfDAtBggrBgEFBQcwAYYhaHR0cDovL29jc3AudHJ1 c3QudGVsaWFzb25lcmEuY29tMEsGCCsGAQUFBzAChj9odHRwOi8vcmVwb3NpdG9yeS50cnVz dC50ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5jZXIwEgYDVR0TAQH/BAgw BgEB/wIBADBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEBAjA6MDgGCCsGAQUFBwIBFixodHRw czovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQUzAOBgNVHQ8BAf8EBAMC AQYwgcYGA1UdHwSBvjCBuzBAoD6gPIY6aHR0cDovL2NybC0zLnRydXN0LnRlbGlhc29uZXJh LmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNybDB3oHWgc4ZxbGRhcDovL2NybC0xLnRydXN0 LnRlbGlhc29uZXJhLmNvbS9jbj1UZWxpYVNvbmVyYSUyMFJvb3QlMjBDQSUyMHYxLG89VGVs aWFTb25lcmE/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnkwHQYDVR0OBBYEFJ4Z /+UNOv4AlxU/afHcWjyqDJSDMB8GA1UdIwQYMBaAFPCPWTgAs/WPmpYM1ev6e6oX6BMSMA0G CSqGSIb3DQEBCwUAA4ICAQB5wuZFNXR5ko9cu7PcpIyH8xaoGfpimP2GTg7qVuL92D/idIlj pqMm93WC9mgL/Uy6DExoF8xSLurLaiajoU+VG6ZWg0F7P1AXARNt0RpWI5SphxBQYM2751S8 vC/22k8Vi+qpQVIREqQPVXCIEH7U6eCY9gEVzdq9l1yPoI8n0D2a8V6GCv0RVkmIpa16rNYD tTw4j3Ha56/Ua33C3qeZh1dIfkaU2h4CGHd2Em3v5LLMsEh8dqUeG9yIcCU+8RUgDahNxWMe MGxzrhwk8WBV6xeoQp20p7cSHbSbyHJURC1n+nVrgdh8hbw6WOgFhNA5tCPDZ0oSF+uHfj+b ioZE3AlYdcEqHJA9A9sO58F4/Qg/yp9oYuT0ZpKb4hmzeqDXvk5KRFNfHlhTt35i+qmas9wB 11MXbYd5WwqEhZH6HWO5H7XKJP7olxmEC0W3OKlpKafq1iPsBN5ycRfUrXFss0Ax6vpCq0XA 3LYePpQ44hOU+qrkR1M0a7Eo3++3TpP4cV+FZiO4aZYZ3yZftSRHwWpGiDBdWOdTKR2GJi7Z z/OxacrmwmM1Z+WcigldbG8f3IMnOLK4X0uXjhVeAHrhuttQuM8i+4TNXgsZbmfEKNDQIQPO /lbacsGHWFB/U2y6SXVEkZs2xIciRA0iZNTv7mbIL8SZmf5wpbjDCYHiCjGCAzgwggM0AgEB MFowRzELMAkGA1UEBhMCU0UxFDASBgNVBAoMC1RlbGlhU29uZXJhMSIwIAYDVQQDDBlUZWxp YVNvbmVyYSBDbGFzcyAyIENBIHYyAg8BaKlzCTJTye3phLaz/cIwDQYJYIZIAWUDBAIBBQCg ggGvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE5MDcyMjEx MTQyM1owLwYJKoZIhvcNAQkEMSIEIK/HQvAuZ1I5iWwg0d6bYvRSqGlQXIa4OIUB3/2uDsaM MGkGCSsGAQQBgjcQBDFcMFowRzELMAkGA1UEBhMCU0UxFDASBgNVBAoMC1RlbGlhU29uZXJh MSIwIAYDVQQDDBlUZWxpYVNvbmVyYSBDbGFzcyAyIENBIHYyAg8BaKlzCTJTye3phLaz/cIw awYLKoZIhvcNAQkQAgsxXKBaMEcxCzAJBgNVBAYTAlNFMRQwEgYDVQQKDAtUZWxpYVNvbmVy YTEiMCAGA1UEAwwZVGVsaWFTb25lcmEgQ2xhc3MgMiBDQSB2MgIPAWipcwkyU8nt6YS2s/3C MGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0D BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwIC ASgwDQYJKoZIhvcNAQEBBQAEggEATF16yxLQ+xv94neoTvUNG1n7iEwR39MXCrXpSO+IRfTV d9qFPtj8dEpqahqAqpmoJNyNB7yq5p8gsEqatTc9tx3IYNKQVvlDKg2+gpWjWN2TyBABKWAK cAkzaKeWDW/CTAVyxtcLoWmMuTunQvTRSjLvwO18ZVUSCNy0ipyeU4CjWj4ms8/JC1RbEwbD nGEa05+w96bhw2y2WnxNOY4PUmaGWeVntz2Zz+MUOWedlnOdqLsyr0tNanOyHIA/mB2iRL4/ zXFRR6VEnhHKusgjxybqL4upIqS42RqhI7hdijJBtvSioOlbgf66seW8Lo5Ewazyrco3McR9 K71feHcshAAAAAAAAA== --------------ms080609060609060809080201-- From nobody Tue Jul 23 05:55:51 2019 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 CC36812023E; Tue, 23 Jul 2019 05:55:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 PrRw9DPqEneL; Tue, 23 Jul 2019 05:55:48 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1523120119; Tue, 23 Jul 2019 05:55:47 -0700 (PDT) Received: from Jude (31.133.136.216) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 23 Jul 2019 05:55:42 -0700 From: Jim Schaad To: 'Ludwig Seitz' , CC: References: <7000332e-9853-fcc5-c98f-b2d8f2fb4060@ri.se> In-Reply-To: <7000332e-9853-fcc5-c98f-b2d8f2fb4060@ri.se> Date: Tue, 23 Jul 2019 08:55:33 -0400 Message-ID: <01aa01d54155$eef81900$cce84b00$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQJf+ajF1rkBUZakyaBa5B6VdiyBKqXCtRDQ Content-Language: en-us X-Originating-IP: [31.133.136.216] Archived-At: Subject: Re: [Ace] Review of draft-ietf-ace-key-groupcomm 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: Tue, 23 Jul 2019 12:55:50 -0000 -----Original Message----- From: Ace On Behalf Of Ludwig Seitz Sent: Friday, July 19, 2019 7:22 AM To: draft-ietf-ace-key-groupcomm@ietf.org Cc: ace@ietf.org Subject: [Ace] Review of draft-ietf-ace-key-groupcomm Hello Francesca, Marco, I have finally managed to read the whole of draft-ietf-ace-key-groupcomm = and have a few comments for you: =3D=3D 5.2 "If the leaving node wants to be part of a group with fewer roles, it=20 does not need to communicate that to the KDC, and can simply stop acting = according to such roles." There are legitimate cases where a node might want to explicitly=20 deactivate roles it is currently using (principle of least priviledge)=20 and not just stop using them. [JLS] I trimmed because I only wanted to address this one topic. I = totally agree that there are cases where a node might want to deactivate = roles, however in the case of group communication I don't see how this = could be done in a reasonable manner. =20 If a node says - please stop advertising my public key because I am no = longer a publisher, that is reasonable for a KDC to start doing. = However, there are currently no provisions in the protocol for a KDC to = advertise that fact to all of the subscribers. Even if a key roll over = were to occur, as the node still is part of the group, it can produce = the correct key material and sign a message. A subscriber with the = signature key would successfully validate the signature and accept it = the message, only those subscribers which had not yet pulled down a = public key would fail to validate the message. This would require a new mechanism for the purpose of asking if a public = key is still associated with a specific key identifier (which is a good = reason for the note about keeping the same key ids when rolling keys). = I am not sure that the traffic would be worth the effort for this small = gain. Note that for a gated transmission system such as a pub-sub server, the = node can get lesser privilege for the gate system without getting less = privilege for the KDC. Jim /Ludwig --=20 Ludwig Seitz, PhD Security Lab, RISE Phone +46(0)70-349 92 51 From nobody Thu Jul 25 07:54:42 2019 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 F0BF7120284; Thu, 25 Jul 2019 07:54:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 o-G5o0hgp4mD; Thu, 25 Jul 2019 07:54:33 -0700 (PDT) Received: from mail-qt1-x831.google.com (mail-qt1-x831.google.com [IPv6:2607:f8b0:4864:20::831]) (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 BB5E4120296; Thu, 25 Jul 2019 07:54:32 -0700 (PDT) Received: by mail-qt1-x831.google.com with SMTP id w17so5020564qto.10; Thu, 25 Jul 2019 07:54:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=q6YDCErZOogTdEDSW8GoDTGtPMyOFthtkm3Fv9FFrmc=; b=EBHa7MvPjUztyAdU142S0dFIlsC9BXpqmfk6JUr1V3/g6maRFidRh3hziBm4It5Efp cnHJjTMYkiYi4pyRVY8tUHKkpAIRH/kF/3MmRzYs3+wnLgX98hDpvKtatsedjoQf/qnm VqMaPgPzuOSlb9/iBvN9IFFTUApck26Spp2/YuztcjXq6eJQEh6baydzkth6TrEUKtOQ sC1TLazFAD1Dho7pd7kfWeWp+NCSdCovRD8koYuPYbVCVwN5YvT5b+1lo/sjWYEILb1Q ap5FP0RPaD84ggrVpGqCpWpM4SQ5YNhsSQvFcaPu4vhtN0Pn1F82+RZpxVNB8TAdDCb0 SsGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=q6YDCErZOogTdEDSW8GoDTGtPMyOFthtkm3Fv9FFrmc=; b=M/u65jKo/PoP3eOIP+BD++fMmXntt0F7MXWa6fbOMJ4QEM3uXU/qlJNQKmIWKeBd5D 6tpBcA+sPA2HyPA8ERAeiO8QjNyHFWiU0VpS/lVqZDQYi+wJDE6J1W2G+KoDrU+M1hzH asRJttlx+zvdbuXvGaAnh26pQ/JtkRRqJyx9FfhZjMetLmpcUnGXRHxtEB6azwliFwX3 L/QTUthRbJOkYSr/mNgxEMeqjWHd6mfmWQVW9u6uqafPG8Np31H6m+mYnrkvDDHNNgYZ bnG+D9F0hLN0B/IJqRZ582whnLUAMSkwDel9V8rYdswQpQRkWzxHKgfRBXhzJ2lp1emo a05g== X-Gm-Message-State: APjAAAWxfm8DLO4+NVxsg9qHJz4xy7EV/Al4X7hbM+RjbstRwFCr+ygG 9GKPJZjwVMRhK4k/9GmwChjlvXYvEcyMvK1u6s/xECKwd+I= X-Google-Smtp-Source: APXvYqx6JSL9t+dQTUqQYETwLrsQpcn4ldMwSpchvGqOmoNavjfuUWlecOoRwlXXPesyq3LUM3T4YI7c+jIMmgHIaHA= X-Received: by 2002:a0c:b627:: with SMTP id f39mr65248084qve.72.1564066471637; Thu, 25 Jul 2019 07:54:31 -0700 (PDT) MIME-Version: 1.0 References: <009c01d510e9$7eada030$7c08e090$@augustcellars.com> <001001d5118e$aa155290$fe3ff7b0$@augustcellars.com> In-Reply-To: From: Cigdem Sengul Date: Thu, 25 Jul 2019 15:54:19 +0100 Message-ID: To: Daniel Migault Cc: Jim Schaad , draft-ietf-ace-mqtt-tls-profile@ietf.org, ace@ietf.org Content-Type: multipart/alternative; boundary="000000000000727810058e829ab4" Archived-At: Subject: Re: [Ace] Comments on draft-ietf-ace-mqtt-tls-profile 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: Thu, 25 Jul 2019 14:54:39 -0000 --000000000000727810058e829ab4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello Daniel, Thank you very much for your comments. I have commented on them below and created corresponding GitHub issues to be addressed soon. One thing that affects how we address most of the comments is the order of presentation of MQTT v5 and MQTT v3.1.1. I completely agree that if the order is reversed, and v3.1.1. 1 is presented for backward compatibility, this would improve the document. This is the highest priority issue, and all the other issues will be addressed once that change is made. Other comments and pointers to Github are inline. Let me know if I missed anything. Sincerely, --Cigdem ... > improvements to the basic protocol with the new MQTT v5.0 - the OASIS > Standard [MQTT-OASIS-Standard-v5] (e.g., improved authentication > exchange and error reporting). Both versions are expected to be > supported in practice, and therefore, covered in this document. > > > > I understand that the basic protocol refers to MQTTv3.3.1.1 It might be > clearer to explicitly mention that MQTT v3.1.1 is the basic protocol. > The other way around could be to remove to the basis protocol" in the > latest sentence. > > Probably that my missing background on MQTT, but -at least for my > personnal knowledge - I believe that some clarification over the support > of the v5 and v3.1.1 could be clarified. When support for both version > is mentioned, I am wondering if this documents mandate that any RS > implements both v3.1.1 AND v5 or if it states that v3.1.1 is by no way > being sunset. In other words, it is envisioned that some system will use > v3.1.1 *for ever* in which case their associated is expected to support > v3.1.1. The same will occur for v5 respectively. Another alternative > could be that MQTTv5 adds functionalities to v3.1.1, leading to some > sort of backward compatibility that are sufficient in most cases. > > > Cigdem: This would be somewhat clarified when we present MQTT v5 first and recommend its use. https://github.com/ace-wg/mqtt-tls-profile/issues/12 Everything that is described for MQTT v3.1. is doable by MQTT v5, and therefore there is backward compatibility. However, it has to be signalled to the client indeed. The broker should advertise which version(s) it supports. https://github.com/ace-wg/mqtt-tls-profile/issues/9 > > > Clients use client authorization servers [I-D.ietf-ace-actors] to > obtain tokens from the authorization server. The communication > protocol between the client authorization server and the > authorization server is assumed to be HTTPS. Also, if the broker > supports token introspection, it is assumed to use HTTPS to > communicate with the authorization server. These interfaces MAY be > implemented using other protocols, e.g., CoAP or MQTT. > > > I have the impression that the proposed alternatives are unsecured. I am > wondering if that is intentional. I believe that these communications > needs to be secured appropriately. > > My understanding is that MQTT will work on top of TCP/TLS. If that is > correct, I am wondering if it is envisioned that a full HTTP client is > embedded into small motes, or a minimal library restricted to support > the interaction with the AS. The reason I am asking this question is > related to a discussion we had in homenet, so that is only for my > personal knowledge and unrelated to MQTT. > > > Cigdem: The resource-constrained client needs to support MQTT and ACE only. The client authorisation server (CAS) and resource broker (server) (RS) need to support HTTPS - they may want to communicate over MQTT or CoAP but these need to be secured as expected from CAS-AS and RS-AS security requirements of ACE core document. You have a later comment on this, which I respond to there but it will be tied to the same Github issue. Created GitHub issue: https://github.com/ace-wg/mqtt-tls-profile/issues/10 > > > The term "Resource" is used to refer to an MQTT "topic name," which > is defined in Section 1.3. Hence, the "Resource Owner" is any entity > that can authoritatively speak for the "topic". > > > scetion 1.3 defines the Topic name. It might be more helpful to the > reader if the exact same term is used both in the text of the document > and in the terminology - that is even considering upper/lower letters. > > I am wondering if broker should be defined as well. > > Similarly, there seems that Clients are composed of various sub clients > ( client authorisation server, client (MQTT), subscriber, publisher). > Maybe these different designation could be defined as well in the > terminology section. Maybe also some designations might not be necessary > to introduce. > > Cigdem: Will make sure consistency in upper/lower characters. Will define the broker. Yes, we assumed there may be a CAS that will speak HTTPS to get the tokens from AS. Or if the client itself is capable of doing that, it would not need a CAS. Other than that, the MQTT client software may act both as a publisher or subscriber. We only separated them for the clarity of presentation. Also, there are some command line MQTT clients that just publish or just subscribe. Still, I would not consider publisher/subscriber pieces as sub-clients. I think we explain this in the text but will also bring it to the Terminology section. Github issue: https://github.com/ace-wg/mqtt-tls-profile/issues/11 > > > > Subscription > A subscription comprises a Topic filter and a maximum quality > of service (QoS). > > I am wondering why the subscription does not consider the identity(ies), > location(s) of the subscriber(s). I the reason that this parameters are > define over an established session, which in the case of MQTT is > TCP/TLS. I also suspect there is a MQTT session handling subscribers, > publisher connectivity. > > > Cigdem : This is the standard definition in MQTT. We have not modified this. MQTT broker maintains connections to all clients; there is a way to keep alive. The CONNECT message establishes the session. > > > 2.1.1. Client Authorization Server (CAS) and Authorization Server (AS) > Interaction > > The first step in the protocol flow (Figure 1 (A)) is the token > acquisition by the client authorization server (CAS) from the AS. If > a client has enough resources and can support HTTPS, or optionally > the AS supports MQTTS, these steps can instead be carried out by a > client directly. > > > MQTTS and CAS should in my opinion be mentioned in the terminology > section. > > "optionally" might be clarified further. The introduction mentioned > HTTPS was considered as the supported protocol. but it seems here that > the support of HTTPS may not be obvious, in which case the support of > MQTTS might be RECOMMENDED/SHOULD or even stronger. The recommendation > may also be associated to current deployments, especially concerning how > AS are dedicated to a technology or not. I do not see strong > recommendations for the AS to support one specific protocol, so I > believe clarification/discussions on MQTTS / HTTPS should be provided in > the document. > > """ > other underlying > protocols are not prohibited from being supported in the future, such > as HTTP/2, MQTT, BLE and QUIC. > """ > > > Cigdem: Will fix. It is RECOMMENDED that HTTPS is used. If AS supports MQTT, MQTTS can be used, both this implies a publish/subscribe communication model for token issuance. For compatibility with other ASes, this may be left as HTTPS. Similarly for token introspection, if MQTTS is used, then it is a publish/subscribe communication model. We do not prohibit their use - will add other protocols. Github issue at https://github.com/ace-wg/mqtt-tls-profile/issues/10 > 2.1.2. Client Connection Request to the Broker > > Once the client acquires the token, it can use it to request an MQTT > connection to the broker over a TLS session with server > authentication (Figure 1 (D)). This section describes the client > transporting the token to the broker (RS) via the CONNECT control > message after the TLS handshake. This is similar to an earlier > proposal by Fremantle et al. [fremantle14]. An improvement to this > is presented in Section 3 for the MQTT v5 - the OASIS Standard > [MQTT-OASIS-Standard-v5]. > > > I believe the description of the improvement has been omitted. It woudl > help the reader to get an overview of the improvement. > > > Yes, the improvement is now there are specific fields that can be used for authorisation in MQTT v5, and overloading of password/username fields can be avoided. This will be better explained when the order of MQTTv5 and MQTT v3.1.1.1 is changed. Github issue at https://github.com/ace-wg/mqtt-tls-profile/issues/12 > > > The Will flag indicates that a Will message needs to be sent when a > client disconnection occurs. The situations in which the Will > message is published include disconnections due to I/O or network > failures, and the server closing the networking connection due to a > protocol error. The client may set the Will flag as desired (marked > as 'X' in Figure 3). If the Will flag is set to 1 and the broker > accepts the connection request, the broker must store the Will > message, and publish it when the network connection is closed > according to Will QoS and Will retain parameters, and MQTT Will > management rules. Section 2.5 explains how the broker deals with the > retained messages in further detail. > > > Figure mentions Will Flag while the text mentions Will flag. > > From the paragraph, I cannot figure out what a Will message is. Maybe > that could be explained or a reference to it may be indicated. > > > Cigdem : Sure, will pay attention to be consistent with the capitalisations. The Will message is indeed the client=E2=80=99s will when it dies. That=E2= =80=99s why it is sent in the case of a disconnection. Will improve its explanation. I can this also to MQTT terminology section: *Will Message:* An Application Message which is published by the Server after the Network Connection is closed in cases where the Network Connection is not closed normally. If Will Flag is set, then the payload of the Connect message has information about the Will message. The Will Message consists of the Will Properties, Will Topic, and Will Payload fields in the CONNECT Payload. Github issue:https://github.com/ace-wg/mqtt-tls-profile/issues/13 https://github.com/ace-wg/mqtt-tls-profile/issues/11 > > The broker responses may follow either the MQTT v3.1.1 - the OASIS > Standard [MQTT-OASIS-Standard] or the MQTT v5 - the OASIS Standard > [MQTT-OASIS-Standard-v5], depending on which version(s) the broker > supports. > > I believe that references to MQTTv3.1.1 and MQTTv5 provided in the > introduction are sufficient, and there is no need to have teh reference > anytime MQTT is invoked. > > Cigdem: Will remove, and it will improve the readability of the document. https://github.com/ace-wg/mqtt-tls-profile/issues/14 > 3. Improved Protocol Interactions with MQTT v5 > > In the new MQTT v5 - the OASIS Standard [MQTT-OASIS-Standard-v5], > several new capabilities are introduced, which enable better > integration with ACE. The newly enhanced authentication and re- > authentication methods support a wider range of authentication flows > beyond username and password. With the MQTT v5, there is a clearly > defined approach for using token-based authorization. Also, it is > possible for a client to request a re-authentication avoiding > disconnection. Finally, MQTT v5 generally improves error reporting, > enabling better response to authorization failures during publishing > messages to the subscribers. > > > Given that MQTT provides a better integration with ACE, I am wondering > if MQTTv5 should not be considered as the primary description and having > MQTT3.1.1 related to legacy MQTT. This is seems to me simply re-ordering > the > sections. However, the message carried would be to move to MQTTv5 when > possible. > > I also believe that a recommendation on supporting MQTTv5 should me made > in the document. > > > Cigdem: This is a good idea. We kept the order because of historical reasons. Will work on that as a first requirement before fixing other GitHub issues. https://github.com/ace-wg/mqtt-tls-profile/issues/12 > > hentication capabilities, it is not necessary to > overload the username and password fields in the CONNECT message for > ACE authentication. Nevertheless, the RS MUST support both methods > for supporting the token: (1) Token transport via username and > password and (2) using the new AUTH (Authentication Exchange) method. > The token transport via username and password is as described in > Section 2.1.2. The rest of this section describes the AUTH method. > > > As mentioned before, it might be better to mention what to do and > explain in MQTT why we overload the username/password. > > Cigdem: If the order of descriptions is changed, then we can clarify this better. Github issue: https://github.com/ace-wg/mqtt-tls-profile/issues/12 On Fri, May 24, 2019 at 4:57 AM Cigdem Sengul wrote: > Hello, >> >> Thanks, Jim, this was helpful, and it also triggered that I go back and >> read the introspection section of the core draft again. >> >> >>> >>> >>> [JLS] For introspection, but not for a published token, the token could >>> be =E2=80=9Crevoked=E2=80=9D by the RS. In this case a new introspecti= on check would lead >>> to that information. There may be ways to deal with this in the >>> introspection dialog and not need to be called up here. The question w= ould >>> be does the exi field mean =E2=80=93 recheck the token or discard the t= oken. >>> >> >> Understood. We definitely need to clarify here what we do with exi field >> if it exists, and if it doesn't exist. The MAY language we used in the >> draft is not appropriate if exi does not exist. >> We considered the expiration time in the introspection response as a >> revocation signal and hence RS discards the token. (The basic flow was:= RS >> receives a token, introspects it, caches the result and then when it >> expires, it revokes the token - which may next lead to different steps >> depending on the version of the MQTT.) >> But if introspection is done to handle the case of dynamic authorisation >> decisions, and exi would signal a recheck indeed. >> Will clarify. >> >> Thanks, >> --Cigdem >> >> >> >>> >>> >>> Jim >>> >>> >>> >>> >>> >>> 7. That is correct. Will add the clarification. >>> >>> >>> >>> Thanks, >>> >>> --Cigdem >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> On Wed, May 22, 2019 at 10:58 PM Jim Schaad >>> wrote: >>> >>> Thanks for the updates from my last message. This has helped quite a >>> bit. >>> >>> 1. A discussion of the use of raw public keys rather than certificates >>> for >>> the server may be in order. This can refer to the same RPK issues from >>> the >>> current DTLS document. It may also be that this just uses normal >>> certificate processing and that should be noted as well, but some >>> discussion >>> of deciding if the subject name/alt name matches the token returned fro= m >>> the >>> AS. >>> >>> For the connect message there are a couple of issues that need to be >>> thought >>> about. >>> >>> 2. What items are required to be in the connect message. The response >>> to >>> my last message suggested that a client identifier is required to be >>> present >>> but that is not documented. >>> >>> 3. It is not completely clear what portions of the CONNECT message are >>> being covered by the signature/MAC value. As an example, is the passwo= rd >>> field omitted entirely or is it set to a zero length password. In >>> addition >>> to this, from the couple of implementations that I have looked at the >>> entire >>> packet is not passed out of the base server code for authentication >>> purposes. This might need to be taken into account in terms of what is >>> used >>> for the body and how it is constructed. (As a side note, the >>> implementations that I have looked at so far also think that the >>> password is >>> a text string rather than a binary value which is going to be a short >>> term >>> issue as well.) >>> >>> 4. I must admit that I am disappointed that there is no challenge >>> response >>> mechanism in the MQTT specifications. I don't know that anything can b= e >>> done at this point about it but there are some security issues that nee= d >>> to >>> be highlighted because of this in the security considerations section. >>> Only >>> the v3 seems to have this problem. Also doing the channel binding woul= d >>> deal with this problem as well. Might just need some general discussio= ns >>> around the channel binding text. >>> >>> 5. Is there an intention to provide a "standard" format for the scope >>> field >>> or just to leave it as ad hoc? >>> >>> 6. It might be reasonable in section 2.1.3 to note that even if a >>> result is >>> cached, that cached check should be limited for a specific amount of >>> time to >>> recheck if the token is still active. More of an issue in terms of how >>> long >>> to cache for introspection. >>> >>> 7. In section 2.1.4 - I would presume that the last paragraph should b= e >>> extended to say that the token is stored only for the length of the >>> connection. That is the token always needs to be supplied every time a >>> connect message is sent. >>> >>> Jim >>> >>> >>> _______________________________________________ >>> Ace mailing list >>> Ace@ietf.org >>> https://www.ietf.org/mailman/listinfo/ace >>> >>> _______________________________________________ >> Ace mailing list >> Ace@ietf.org >> https://www.ietf.org/mailman/listinfo/ace >> > --000000000000727810058e829ab4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Daniel,=C2=A0

Th= ank you very much for your comments. I have commented on them below and cre= ated corresponding GitHub issues to be addressed soon.=C2=A0

=
One thing that affects how we address most of the comments is th= e order of presentation of MQTT v5 and MQTT v3.1.1.=C2=A0
I compl= etely agree that if the order is reversed, and v3.1.1. 1 is presented for b= ackward compatibility, this would improve the document.=C2=A0 This is the h= ighest priority issue, and all the other issues will be addressed once that= change is made.=C2=A0

Other comments and pointers= to Github are inline. Let me know if I missed anything.=C2=A0
Sincerely,
--Cigdem=C2=A0

...
=C2=A0 =C2=A0improvements to the basic protocol with t= he new MQTT v5.0 - the OASIS
=C2=A0 =C2=A0Standard [MQTT-OASIS-Standard-= v5] (e.g., improved authentication
=C2=A0 =C2=A0exchange and error repor= ting).=C2=A0 Both versions are expected to be
=C2=A0 =C2=A0supported in = practice, and therefore, covered in this document.

<mglt>
<= br>I understand that the basic protocol refers to MQTTv3.3.1.1 It might be<= br>clearer to explicitly mention that MQTT v3.1.1 is the basic protocol.The other way around could be to remove to the basis protocol" in the=
latest sentence.

Probably that my missing background on MQTT, b= ut -at least for my
personnal knowledge - I believe that some clarificat= ion over the support
of the v5 and v3.1.1 could be clarified.=C2=A0 When= support for both version
is mentioned, I am wondering if this documents= mandate that any RS
implements both v3.1.1 AND v5 or if it states that = v3.1.1 is by no way
being sunset. In other words, it is envisioned that = some system will use
v3.1.1 *for ever* in which case their associated is= expected to support
v3.1.1. The same will occur for v5 respectively. An= other alternative
could be that MQTTv5 adds functionalities to v3.1.1, l= eading to some
sort of backward compatibility that are sufficient in mos= t cases.

</mglt>

<= div>Cigdem:=C2=A0
This would be somewhat clarified when we presen= t MQTT v5 first and recommend its use.=C2=A0

Everything that is = described for MQTT v3.1. is doable by MQTT v5, and therefore there is backw= ard compatibility.
However, it has to be signalled to the client = indeed.=C2=A0

The broker should advertise wh= ich version(s) it supports.=C2= =A0

https://github.co= m/ace-wg/mqtt-tls-profile/issues/9





=C2=A0 =C2= =A0Clients use client authorization servers [I-D.ietf-ace-actors] to
=C2= =A0 =C2=A0obtain tokens from the authorization server.=C2=A0 The communicat= ion
=C2=A0 =C2=A0protocol between the client authorization server and th= e
=C2=A0 =C2=A0authorization server is assumed to be HTTPS.=C2=A0 Also, = if the broker
=C2=A0 =C2=A0supports token introspection, it is assumed t= o use HTTPS to
=C2=A0 =C2=A0communicate with the authorization server.= =C2=A0 These interfaces MAY be
=C2=A0 =C2=A0implemented using other prot= ocols, e.g., CoAP or MQTT. =C2=A0

<mglt>
I have the impress= ion that the proposed alternatives are unsecured. I am
wondering if that= is intentional. I believe that these communications
needs to be secured= appropriately.
=C2=A0
My understanding is that MQTT will work on top= of TCP/TLS. If that is
correct, I am wondering if it is envisioned that= a full HTTP client is
embedded into small motes, or a minimal library r= estricted to support
the interaction with the AS. The reason I am asking= this question is
related to a discussion we had in homenet, so that is = only for my
personal knowledge and unrelated to MQTT.

</mglt&g= t;

Cigdem:=C2=A0

=C2=A0The resource-constrained client needs to support= MQTT and ACE only.=C2=A0

The client authorisation serve= r (CAS) and resource broker (server)=C2=A0 (RS) need to support HTTPS - they may want to communicat= e over MQTT or CoAP but these need to be secured as expected from CAS-AS an= d RS-AS security requirements of ACE core document.=C2=A0

You have a later comment on this, which I re= spond to there but it will be tied to the same Github issue.=C2=A0

Created GitHub issue: https://github.com/ace-wg/mqtt-tls-profile/issues/10



=C2=A0 =C2=A0The term "Resource" is used to refer= to an MQTT "topic name," which
=C2=A0 =C2=A0is defined in Sec= tion 1.3.=C2=A0 Hence, the "Resource Owner" is any entity
=C2= =A0 =C2=A0that can authoritatively speak for the "topic".

= <mglt>
scetion 1.3 defines the Topic name. It might be more helpfu= l to the
reader if the exact same term is used both in the text of the d= ocument
and in the terminology - that is even considering upper/lower le= tters. =C2=A0

I am wondering if broker should be defined as well.
Similarly, there seems that Clients are composed of various sub clien= ts
( client authorisation server, client (MQTT), subscriber, publisher).=
Maybe these different designation could be defined as well in the
te= rminology section. Maybe also some designations might not be necessary
t= o introduce.
</mglt>

<= div>Cigdem:=C2=A0

Will make sure consistency in = upper/lower characters.=C2=A0

Will define the broker.=C2=A0


Yes, we assumed there may be a= CAS that will speak HTTPS to get the tokens from AS. Or if the client itse= lf is capable of doing that, it would not need a CAS.=C2=A0


Other than that, the MQTT clie= nt software may act both as a publisher or subscriber. We only separated th= em for the clarity of presentation.=C2=A0=C2=A0

Als= o, there are some=C2=A0command line MQTT clients that just publish or just = subscribe.=C2=A0

Still, I would not consider pu= blisher/subscriber pieces as sub-clients.=C2=A0 I think we explain this in the text but will also b= ring it to the Terminology section.

Github issue: ht= tps://github.com/ace-wg/mqtt-tls-profile/issues/11

=


=C2=A0 =C2=A0Subscription
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0A subscription comprises a Topic filter and a maximum quality
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0of service (QoS).
<mglt>
= I am wondering why the subscription does not consider the identity(ies),location(s) of the subscriber(s). I the reason that this parameters aredefine over an established session, which in the case of MQTT is
TCP/TL= S. I also suspect there is a MQTT session handling subscribers,
publishe= r connectivity.

</mglt>

<= /div>
Cigdem :=C2=A0

This is the standard definitio= n in MQTT. We have not modified this.=C2=A0

MQTT broker maintains connecti= ons to all clients; there is a way to keep alive. The CONNECT message estab= lishes the session.=C2=A0



2.1.1.=C2=A0 Client Authorization Server (CAS) and Authoriz= ation Server (AS)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Interaction

=C2=A0 = =C2=A0The first step in the protocol flow (Figure 1 (A)) is the token
= =C2=A0 =C2=A0acquisition by the client authorization server (CAS) from the = AS.=C2=A0 If
=C2=A0 =C2=A0a client has enough resources and can support = HTTPS, or optionally
=C2=A0 =C2=A0the AS supports MQTTS, these steps can= instead be carried out by a
=C2=A0 =C2=A0client directly.

<mg= lt>
MQTTS and CAS should in my opinion be mentioned in the terminolog= y
section.

"optionally" might be clarified further. Th= e introduction mentioned
HTTPS was considered as the supported protocol.= but it seems here that
the support of HTTPS may not be obvious, in whic= h case the support of
MQTTS might be RECOMMENDED/SHOULD or even stronger= . The recommendation
may also be associated to current deployments, espe= cially concerning how
AS are dedicated to a technology or not. I do =C2= =A0not see strong
recommendations for the AS to support one specific pro= tocol, so I
believe clarification/discussions on MQTTS / HTTPS should be= provided in
the document. =C2=A0

"""
=C2=A0 = =C2=A0other underlying
=C2=A0 =C2=A0protocols are not prohibited from be= ing supported in the future, such
=C2=A0 =C2=A0as HTTP/2, MQTT, BLE and = QUIC.
"""

</mglt>

Cigdem:=C2=A0

Will fix. It is RECOMMENDED th= at HTTPS is used. If AS supports MQTT, MQTTS can be used, both this implies= a publish/subscribe communication model for token issuance. For compatibil= ity with other ASes, this may be left as HTTPS.=C2=A0


Similarly for token introspect= ion, if MQTTS is used, then it is a publish/subscribe communication model.<= span class=3D"gmail-Apple-converted-space">=C2=A0


We do not prohibit their use -= will add other protocols.

Github issue at=C2=A0https://github.com/ace-wg/mqtt-tls-profile/issues/10=


=

2.1.2.=C2=A0 Client Connection Request to the Bro= ker

=C2=A0 =C2=A0Once the client acquires the token, it can use it t= o request an MQTT
=C2=A0 =C2=A0connection to the broker over a TLS sessi= on with server
=C2=A0 =C2=A0authentication (Figure 1 (D)).=C2=A0 This se= ction describes the client
=C2=A0 =C2=A0transporting the token to the br= oker (RS) via the CONNECT control
=C2=A0 =C2=A0message after the TLS han= dshake.=C2=A0 This is similar to an earlier
=C2=A0 =C2=A0proposal by Fre= mantle et al. [fremantle14].=C2=A0 An improvement to this
=C2=A0 =C2=A0i= s presented in Section 3 for the MQTT v5 - the OASIS Standard
=C2=A0 =C2= =A0[MQTT-OASIS-Standard-v5]. =C2=A0

<mglt>
I believe the de= scription of the improvement has been omitted. It woudl
help the reader = to get an overview of the improvement.
</mglt>


Yes, the improvement is now th= ere are specific fields that can be used for authorisation in MQTT v5, and = overloading of password/username fields can be avoided.=C2=A0

This will be better = explained when the order of MQTTv5 and MQTT v3.1.1.1 is changed.=C2=A0

Github issue at=C2=A0https://github.com/ace-wg/mqtt-tls-profile/issues/12=



=C2=A0 =C2=A0The Will flag indicates that a Will message nee= ds to be sent when a
=C2=A0 =C2=A0client disconnection occurs.=C2=A0 The= situations in which the Will
=C2=A0 =C2=A0message is published include = disconnections due to I/O or network
=C2=A0 =C2=A0failures, and the serv= er closing the networking connection due to a
=C2=A0 =C2=A0protocol erro= r.=C2=A0 The client may set the Will flag as desired (marked
=C2=A0 =C2= =A0as 'X' in Figure 3).=C2=A0 If the Will flag is set to 1 and the = broker
=C2=A0 =C2=A0accepts the connection request, the broker must stor= e the Will
=C2=A0 =C2=A0message, and publish it when the network connect= ion is closed
=C2=A0 =C2=A0according to Will QoS and Will retain paramet= ers, and MQTT Will
=C2=A0 =C2=A0management rules.=C2=A0 Section 2.5 expl= ains how the broker deals with the
=C2=A0 =C2=A0retained messages in fur= ther detail.

<mglt>
Figure mentions Will Flag while the tex= t mentions Will flag.

From the paragraph, I cannot figure out what = a Will message is. Maybe
that could be explained or a reference to it ma= y be indicated.

</mglt>

=
Cigdem :

Sure, will pay attention to be= consistent with the capitalisations.=C2=A0

The Will message is indeed the= client=E2=80=99s will when it dies. That=E2=80=99s why it is sent in the c= ase of a disconnection. Will improve its explanation.=C2=A0

I can this also to MQTT termin= ology section:=C2=A0

Will Message:

An Application Message which is = published by the Server after the Network Connection is closed in cases whe= re the Network Connection is not closed normally.=C2=A0

If Will Flag is set, then the pa= yload of the Connect message has information about the Will message.=C2=A0

The Will Message consists of the= Will Properties, Will Topic, and Will Payload fields in the CONNECT Payloa= d.

Github issue:https://github.com/ace-wg/mqtt-tls-profile/issues/13

https= ://github.com/ace-wg/mqtt-tls-profile/issues/11




=C2= =A0 =C2=A0The broker responses may follow either the MQTT v3.1.1 - the OASI= S
=C2=A0 =C2=A0Standard [MQTT-OASIS-Standard] or the MQTT v5 - the OASIS= Standard
=C2=A0 =C2=A0[MQTT-OASIS-Standard-v5], depending on which vers= ion(s) the broker
=C2=A0 =C2=A0supports.
<mglt>
I believe th= at references to MQTTv3.1.1 and MQTTv5 provided in the
introduction are = sufficient, and there is no need to have teh reference
anytime MQTT is i= nvoked. =C2=A0
</mglt>

Cigdem:=C2=A0


Will remove, and it will improve the readability of the document.= =C2=A0



3.=C2=A0 Improved Protocol Interactions with MQTT v5

=C2=A0 =C2=A0= In the new MQTT v5 - the OASIS Standard [MQTT-OASIS-Standard-v5],
=C2=A0= =C2=A0several new capabilities are introduced, which enable better
=C2= =A0 =C2=A0integration with ACE.=C2=A0 The newly enhanced authentication and= re-
=C2=A0 =C2=A0authentication methods support a wider range of authen= tication flows
=C2=A0 =C2=A0beyond username and password.=C2=A0 With the= MQTT v5, there is a clearly
=C2=A0 =C2=A0defined approach for using tok= en-based authorization.=C2=A0 Also, it is
=C2=A0 =C2=A0possible for a cl= ient to request a re-authentication avoiding
=C2=A0 =C2=A0disconnection.= =C2=A0 Finally, MQTT v5 generally improves error reporting,
=C2=A0 =C2= =A0enabling better response to authorization failures during publishing
= =C2=A0 =C2=A0messages to the subscribers.

<mglt>
Given that= MQTT provides a better integration with ACE, I am wondering
if MQTTv5 s= hould not be considered as the primary description and having
MQTT3.1.1 = related to legacy MQTT. This is seems to me simply re-ordering the
secti= ons. However, the message carried would be to move to MQTTv5 when
possib= le.

I also believe that a recommendation on supporting MQTTv5 shoul= d me made
in the document.

</mglt>

Cigdem:

This is a good idea. We kept t= he order because of historical reasons. Will work on that as a first requir= ement before fixing other GitHub issues. =C2=A0


=C2=A0 hentication cap= abilities, it is not necessary to
=C2=A0 =C2=A0overload the username and= password fields in the CONNECT message for
=C2=A0 =C2=A0ACE authenticat= ion.=C2=A0 Nevertheless, the RS MUST support both methods
=C2=A0 =C2=A0f= or supporting the token: (1) Token transport via username and
=C2=A0 =C2= =A0password and (2) using the new AUTH (Authentication Exchange) method.=C2=A0 =C2=A0The token transport via username and password is as described= in
=C2=A0 =C2=A0Section 2.1.2.=C2=A0 The rest of this section describes= the AUTH method.

<mglt>
As mentioned before, it might be b= etter to mention what to do and
explain in MQTT why we overload the user= name/password. =C2=A0
</mglt>

Cigdem:=C2=A0If the order of descriptions is changed,= then we can clarify this better.= =C2=A0

Github issue: ht= tps://github.com/ace-wg/mqtt-tls-profile/issues/12


= =C2=A0On Fri, May 24, 2019 at 4:57 AM Cigdem Sengul <cigdem.sengul@gmail.com> w= rote:
Hello,=C2=A0

Thanks, Jim, this was helpf= ul, and it also triggered that I go back and read the introspection section= of the core draft again.=C2=A0


=C2=A0

[JLS] For = introspection, but not for a published token, the token could be =E2=80=9Cr= evoked=E2=80=9D by the RS.=C2=A0 In this case a new introspection check wou= ld lead to that information.=C2=A0 There may be ways to deal with this in t= he introspection dialog and not need to be called up here.=C2=A0 The questi= on would be does the exi field mean =E2=80=93 recheck the token or discard = the token.=C2=A0

=
Understood. We definitely need to clarify here what we do wi= th exi field if it exists, and if it doesn't exist. The MAY language we= used in the draft is not appropriate if exi does not exist.=C2=A0
We considered the expiration time in the introspection response as a revo= cation signal and hence RS discards the token.=C2=A0 (The basic flow was: R= S receives a token, introspects it, caches the result and then when it expi= res, it revokes the token - which may next lead to different steps dependin= g on the version of the MQTT.)
But if introspection is done to ha= ndle the case of dynamic authorisation decisions, and exi would signal a re= check indeed.=C2=A0= =C2=A0
Will clarify.=C2=A0

Thanks,
<= div>--Cigdem=C2=A0

=C2=A0

= =C2=A0

Jim

=C2=A0

=C2=A0

7. That is corre= ct. Will add the clarification.=C2=A0

=C2=A0

Th= anks,

--Cigdem=C2=A0<= /u>

=C2=A0

=C2=A0

=C2=A0

<= u>=C2=A0

On Wed, May 22, 201= 9 at 10:58 PM Jim Schaad <ietf@augustcellars.com> wrote:

=

Thanks for the updates from m= y last message.=C2=A0 This has helped quite a bit.

1.=C2=A0 A discus= sion of the use of raw public keys rather than certificates for
the serv= er may be in order.=C2=A0 This can refer to the same RPK issues from thecurrent DTLS document.=C2=A0 It may also be that this just uses normal
= certificate processing and that should be noted as well, but some discussio= n
of deciding if the subject name/alt name matches the token returned fr= om the
AS.

For the connect message there are a couple of issues t= hat need to be thought
about.

2.=C2=A0 What items are required to= be in the connect message.=C2=A0 The response to
my last message sugges= ted that a client identifier is required to be present
but that is not d= ocumented.

3.=C2=A0 It is not completely clear what portions of the = CONNECT message are
being covered by the signature/MAC value.=C2=A0 As a= n example, is the password
field omitted entirely or is it set to a zero= length password.=C2=A0 In addition
to this, from the couple of implemen= tations that I have looked at the entire
packet is not passed out of the= base server code for authentication
purposes.=C2=A0 This might need to = be taken into account in terms of what is used
for the body and how it i= s constructed.=C2=A0 (As a side note, the
implementations that I have lo= oked at so far also think that the password is
a text string rather than= a binary value which is going to be a short term
issue as well.)
4.=C2=A0 I must admit that I am disappointed that there is no challenge re= sponse
mechanism in the MQTT specifications.=C2=A0 I don't know that= anything can be
done at this point about it but there are some security= issues that need to
be highlighted because of this in the security cons= iderations section.=C2=A0 Only
the v3 seems to have this problem.=C2=A0 = Also doing the channel binding would
deal with this problem as well.=C2= =A0 Might just need some general discussions
around the channel binding = text.

5.=C2=A0 Is there an intention to provide a "standard&quo= t; format for the scope field
or just to leave it as ad hoc?

6.= =C2=A0 It might be reasonable in section 2.1.3 to note that even if a resul= t is
cached, that cached check should be limited for a specific amount o= f time to
recheck if the token is still active.=C2=A0 More of an issue i= n terms of how long
to cache for introspection.

7.=C2=A0 In secti= on 2.1.4 - I would presume that the last paragraph should be
extended to= say that the token is stored only for the length of the
connection.=C2= =A0 That is the token always needs to be supplied every time a
connect m= essage is sent.

Jim


_____________________________________= __________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace<= /u>

_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
--000000000000727810058e829ab4-- From nobody Thu Jul 25 08:33:05 2019 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 E885512021D; Thu, 25 Jul 2019 08:33:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.557 X-Spam-Level: X-Spam-Status: No, score=-1.557 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.091, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no 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 2Rh3sagvKpm2; Thu, 25 Jul 2019 08:32:58 -0700 (PDT) Received: from mail-vs1-f42.google.com (mail-vs1-f42.google.com [209.85.217.42]) (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 473F31201BB; Thu, 25 Jul 2019 08:32:58 -0700 (PDT) Received: by mail-vs1-f42.google.com with SMTP id 2so33943355vso.8; Thu, 25 Jul 2019 08:32:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=nm1sPFyQxyBTarslFzWImtjpfeVV/lLwAIv3IbdNRIA=; b=kAbjrGQ+yFqTb0krCvbeUdCUrgRi+dYjr5pBVZkGInAb9BwB9I1pO44GHEUBedeceI pO1x4hQ8zHgVQQ+9lv/a8uFQkrgyQaHE87RieG2R4LsS9F7k2eujc2019t6FpvrqS5uM dOMNBXII+/FUboya2jPxgWG/A+naZbqKj1MPofI1k1ITrEK8PiG8D+XV5JK7mNN42ALQ dO6nPHbkny8ZypSZiQhPeP+dfBRo/9yIprplQw/iGhrMxcOU7VFP0wvoPQZNu53oOSaj jXkLluiqzXTl+Iz76vEqzpk24m9knE8wehQaIe0aUwqXFd8kMz/dB2JeENE6GlVLWyTS Ag9g== X-Gm-Message-State: APjAAAWkFmUo6ce/lO8JuQI4hWjA0r+SmadB4YrvLiPFqyqcp9vbc/7p SH8libVoHly6xwhlcnDk7lvsxOhlqZ3eSEpSn/mw7A== X-Google-Smtp-Source: APXvYqyzeWa421Ovdt7//+2jLCJ0eX9RG4Z6GCvpTY1M7pyRTJfUoJYouUtXDvu0qVPsksOzNWXsyqD3oHzwwtD9f4E= X-Received: by 2002:a67:e90c:: with SMTP id c12mr11606358vso.97.1564068776944; Thu, 25 Jul 2019 08:32:56 -0700 (PDT) MIME-Version: 1.0 References: <009c01d510e9$7eada030$7c08e090$@augustcellars.com> <001001d5118e$aa155290$fe3ff7b0$@augustcellars.com> In-Reply-To: From: Daniel Migault Date: Thu, 25 Jul 2019 11:32:45 -0400 Message-ID: To: Cigdem Sengul Cc: draft-ietf-ace-mqtt-tls-profile@ietf.org, Jim Schaad , ace@ietf.org Content-Type: multipart/alternative; boundary="000000000000daa9fa058e8323ff" Archived-At: Subject: Re: [Ace] Comments on draft-ietf-ace-mqtt-tls-profile 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: Thu, 25 Jul 2019 15:33:03 -0000 --000000000000daa9fa058e8323ff Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable looks fine to me, thanks for addressing them. Let the WG know when you have a stable version, so that further reviews can be provided. Yours, Daniel On Thu, Jul 25, 2019 at 10:54 AM Cigdem Sengul wrote: > Hello Daniel, > > Thank you very much for your comments. I have commented on them below and > created corresponding GitHub issues to be addressed soon. > > One thing that affects how we address most of the comments is the order o= f > presentation of MQTT v5 and MQTT v3.1.1. > I completely agree that if the order is reversed, and v3.1.1. 1 is > presented for backward compatibility, this would improve the document. > This is the highest priority issue, and all the other issues will be > addressed once that change is made. > > Other comments and pointers to Github are inline. Let me know if I missed > anything. > > Sincerely, > --Cigdem > > ... >> improvements to the basic protocol with the new MQTT v5.0 - the OASIS >> Standard [MQTT-OASIS-Standard-v5] (e.g., improved authentication >> exchange and error reporting). Both versions are expected to be >> supported in practice, and therefore, covered in this document. >> >> >> >> I understand that the basic protocol refers to MQTTv3.3.1.1 It might be >> clearer to explicitly mention that MQTT v3.1.1 is the basic protocol. >> The other way around could be to remove to the basis protocol" in the >> latest sentence. >> >> Probably that my missing background on MQTT, but -at least for my >> personnal knowledge - I believe that some clarification over the support >> of the v5 and v3.1.1 could be clarified. When support for both version >> is mentioned, I am wondering if this documents mandate that any RS >> implements both v3.1.1 AND v5 or if it states that v3.1.1 is by no way >> being sunset. In other words, it is envisioned that some system will use >> v3.1.1 *for ever* in which case their associated is expected to support >> v3.1.1. The same will occur for v5 respectively. Another alternative >> could be that MQTTv5 adds functionalities to v3.1.1, leading to some >> sort of backward compatibility that are sufficient in most cases. >> >> >> > > Cigdem: > This would be somewhat clarified when we present MQTT v5 first and > recommend its use. > https://github.com/ace-wg/mqtt-tls-profile/issues/12 > > Everything that is described for MQTT v3.1. is doable by MQTT v5, and > therefore there is backward compatibility. > However, it has to be signalled to the client indeed. > > The broker should advertise which version(s) it supports. > > https://github.com/ace-wg/mqtt-tls-profile/issues/9 > > > >> >> >> Clients use client authorization servers [I-D.ietf-ace-actors] to >> obtain tokens from the authorization server. The communication >> protocol between the client authorization server and the >> authorization server is assumed to be HTTPS. Also, if the broker >> supports token introspection, it is assumed to use HTTPS to >> communicate with the authorization server. These interfaces MAY be >> implemented using other protocols, e.g., CoAP or MQTT. >> >> >> I have the impression that the proposed alternatives are unsecured. I am >> wondering if that is intentional. I believe that these communications >> needs to be secured appropriately. >> >> My understanding is that MQTT will work on top of TCP/TLS. If that is >> correct, I am wondering if it is envisioned that a full HTTP client is >> embedded into small motes, or a minimal library restricted to support >> the interaction with the AS. The reason I am asking this question is >> related to a discussion we had in homenet, so that is only for my >> personal knowledge and unrelated to MQTT. >> >> >> > > Cigdem: > > The resource-constrained client needs to support MQTT and ACE only. > > The client authorisation server (CAS) and resource broker (server) (RS) > need to support HTTPS - they may want to communicate over MQTT or CoAP bu= t > these need to be secured as expected from CAS-AS and RS-AS security > requirements of ACE core document. > > You have a later comment on this, which I respond to there but it will be > tied to the same Github issue. > > Created GitHub issue: https://github.com/ace-wg/mqtt-tls-profile/issues/1= 0 > >> >> >> The term "Resource" is used to refer to an MQTT "topic name," which >> is defined in Section 1.3. Hence, the "Resource Owner" is any entity >> that can authoritatively speak for the "topic". >> >> >> scetion 1.3 defines the Topic name. It might be more helpful to the >> reader if the exact same term is used both in the text of the document >> and in the terminology - that is even considering upper/lower letters. >> >> I am wondering if broker should be defined as well. >> >> Similarly, there seems that Clients are composed of various sub clients >> ( client authorisation server, client (MQTT), subscriber, publisher). >> Maybe these different designation could be defined as well in the >> terminology section. Maybe also some designations might not be necessary >> to introduce. >> >> > > Cigdem: > > Will make sure consistency in upper/lower characters. > > Will define the broker. > > > Yes, we assumed there may be a CAS that will speak HTTPS to get the token= s > from AS. Or if the client itself is capable of doing that, it would not > need a CAS. > > > Other than that, the MQTT client software may act both as a publisher or > subscriber. We only separated them for the clarity of presentation. > > Also, there are some command line MQTT clients that just publish or just > subscribe. > > Still, I would not consider publisher/subscriber pieces as sub-clients. = I > think we explain this in the text but will also bring it to the Terminolo= gy > section. > > Github issue: https://github.com/ace-wg/mqtt-tls-profile/issues/11 > >> >> >> >> Subscription >> A subscription comprises a Topic filter and a maximum quality >> of service (QoS). >> >> I am wondering why the subscription does not consider the identity(ies), >> location(s) of the subscriber(s). I the reason that this parameters are >> define over an established session, which in the case of MQTT is >> TCP/TLS. I also suspect there is a MQTT session handling subscribers, >> publisher connectivity. >> >> >> > > Cigdem : > > This is the standard definition in MQTT. We have not modified this. > > MQTT broker maintains connections to all clients; there is a way to keep > alive. The CONNECT message establishes the session. > >> >> >> 2.1.1. Client Authorization Server (CAS) and Authorization Server (AS) >> Interaction >> >> The first step in the protocol flow (Figure 1 (A)) is the token >> acquisition by the client authorization server (CAS) from the AS. If >> a client has enough resources and can support HTTPS, or optionally >> the AS supports MQTTS, these steps can instead be carried out by a >> client directly. >> >> >> MQTTS and CAS should in my opinion be mentioned in the terminology >> section. >> >> "optionally" might be clarified further. The introduction mentioned >> HTTPS was considered as the supported protocol. but it seems here that >> the support of HTTPS may not be obvious, in which case the support of >> MQTTS might be RECOMMENDED/SHOULD or even stronger.. The recommendation >> may also be associated to current deployments, especially concerning how >> AS are dedicated to a technology or not. I do not see strong >> recommendations for the AS to support one specific protocol, so I >> believe clarification/discussions on MQTTS / HTTPS should be provided in >> the document. >> >> """ >> other underlying >> protocols are not prohibited from being supported in the future, such >> as HTTP/2, MQTT, BLE and QUIC. >> """ >> >> >> > > Cigdem: > > Will fix. It is RECOMMENDED that HTTPS is used. If AS supports MQTT, MQTT= S > can be used, both this implies a publish/subscribe communication model fo= r > token issuance. For compatibility with other ASes, this may be left as > HTTPS. > > > Similarly for token introspection, if MQTTS is used, then it is a > publish/subscribe communication model. > > > We do not prohibit their use - will add other protocols. > > Github issue at https://github.com/ace-wg/mqtt-tls-profile/issues/10 > > >> 2.1.2. Client Connection Request to the Broker >> >> Once the client acquires the token, it can use it to request an MQTT >> connection to the broker over a TLS session with server >> authentication (Figure 1 (D)). This section describes the client >> transporting the token to the broker (RS) via the CONNECT control >> message after the TLS handshake. This is similar to an earlier >> proposal by Fremantle et al. [fremantle14]. An improvement to this >> is presented in Section 3 for the MQTT v5 - the OASIS Standard >> [MQTT-OASIS-Standard-v5]. >> >> >> I believe the description of the improvement has been omitted. It woudl >> help the reader to get an overview of the improvement. >> >> >> > Yes, the improvement is now there are specific fields that can be used fo= r > authorisation in MQTT v5, and overloading of password/username fields can > be avoided. > > This will be better explained when the order of MQTTv5 and MQTT v3.1.1.1 > is changed. > > Github issue at https://github.com/ace-wg/mqtt-tls-profile/issues/12 > >> >> >> The Will flag indicates that a Will message needs to be sent when a >> client disconnection occurs. The situations in which the Will >> message is published include disconnections due to I/O or network >> failures, and the server closing the networking connection due to a >> protocol error. The client may set the Will flag as desired (marked >> as 'X' in Figure 3). If the Will flag is set to 1 and the broker >> accepts the connection request, the broker must store the Will >> message, and publish it when the network connection is closed >> according to Will QoS and Will retain parameters, and MQTT Will >> management rules. Section 2.5 explains how the broker deals with the >> retained messages in further detail. >> >> >> Figure mentions Will Flag while the text mentions Will flag. >> >> From the paragraph, I cannot figure out what a Will message is. Maybe >> that could be explained or a reference to it may be indicated. >> >> >> > > Cigdem : > > Sure, will pay attention to be consistent with the capitalisations. > > The Will message is indeed the client=E2=80=99s will when it dies. That= =E2=80=99s why it > is sent in the case of a disconnection. Will improve its explanation. > > I can this also to MQTT terminology section: > > *Will Message:* > > An Application Message which is published by the Server after the Network > Connection is closed in cases where the Network Connection is not closed > normally. > > If Will Flag is set, then the payload of the Connect message has > information about the Will message. > > The Will Message consists of the Will Properties, Will Topic, and Will > Payload fields in the CONNECT Payload. > > Github issue:https://github.com/ace-wg/mqtt-tls-profile/issues/13 > > https://github.com/ace-wg/mqtt-tls-profile/issues/11 > > > >> >> The broker responses may follow either the MQTT v3.1.1 - the OASIS >> Standard [MQTT-OASIS-Standard] or the MQTT v5 - the OASIS Standard >> [MQTT-OASIS-Standard-v5], depending on which version(s) the broker >> supports. >> >> I believe that references to MQTTv3.1.1 and MQTTv5 provided in the >> introduction are sufficient, and there is no need to have teh reference >> anytime MQTT is invoked. >> >> > > Cigdem: > > > Will remove, and it will improve the readability of the document. > https://github.com/ace-wg/mqtt-tls-profile/issues/14 > > > >> 3. Improved Protocol Interactions with MQTT v5 >> >> In the new MQTT v5 - the OASIS Standard [MQTT-OASIS-Standard-v5], >> several new capabilities are introduced, which enable better >> integration with ACE. The newly enhanced authentication and re- >> authentication methods support a wider range of authentication flows >> beyond username and password. With the MQTT v5, there is a clearly >> defined approach for using token-based authorization. Also, it is >> possible for a client to request a re-authentication avoiding >> disconnection. Finally, MQTT v5 generally improves error reporting, >> enabling better response to authorization failures during publishing >> messages to the subscribers. >> >> >> Given that MQTT provides a better integration with ACE, I am wondering >> if MQTTv5 should not be considered as the primary description and having >> MQTT3.1.1 related to legacy MQTT. This is seems to me simply re-ordering >> the >> sections. However, the message carried would be to move to MQTTv5 when >> possible. >> >> I also believe that a recommendation on supporting MQTTv5 should me made >> in the document. >> >> >> > > Cigdem: > > This is a good idea. We kept the order because of historical reasons. Wil= l > work on that as a first requirement before fixing other GitHub issues. > https://github.com/ace-wg/mqtt-tls-profile/issues/12 > >> >> hentication capabilities, it is not necessary to >> overload the username and password fields in the CONNECT message for >> ACE authentication. Nevertheless, the RS MUST support both methods >> for supporting the token: (1) Token transport via username and >> password and (2) using the new AUTH (Authentication Exchange) method. >> The token transport via username and password is as described in >> Section 2.1.2. The rest of this section describes the AUTH method. >> >> >> As mentioned before, it might be better to mention what to do and >> explain in MQTT why we overload the username/password. >> >> > > > Cigdem: If the order of descriptions is changed, then we can clarify this > better. > > Github issue: https://github.com/ace-wg/mqtt-tls-profile/issues/12 > > > On Fri, May 24, 2019 at 4:57 AM Cigdem Sengul > wrote: > >> Hello, >>> >>> Thanks, Jim, this was helpful, and it also triggered that I go back and >>> read the introspection section of the core draft again. >>> >>> >>>> >>>> >>>> [JLS] For introspection, but not for a published token, the token coul= d >>>> be =E2=80=9Crevoked=E2=80=9D by the RS. In this case a new introspect= ion check would lead >>>> to that information. There may be ways to deal with this in the >>>> introspection dialog and not need to be called up here. The question = would >>>> be does the exi field mean =E2=80=93 recheck the token or discard the = token. >>>> >>> >>> Understood. We definitely need to clarify here what we do with exi fiel= d >>> if it exists, and if it doesn't exist. The MAY language we used in the >>> draft is not appropriate if exi does not exist. >>> We considered the expiration time in the introspection response as a >>> revocation signal and hence RS discards the token. (The basic flow was= : RS >>> receives a token, introspects it, caches the result and then when it >>> expires, it revokes the token - which may next lead to different steps >>> depending on the version of the MQTT.) >>> But if introspection is done to handle the case of dynamic authorisatio= n >>> decisions, and exi would signal a recheck indeed. >>> Will clarify. >>> >>> Thanks, >>> --Cigdem >>> >>> >>> >>>> >>>> >>>> Jim >>>> >>>> >>>> >>>> >>>> >>>> 7. That is correct. Will add the clarification. >>>> >>>> >>>> >>>> Thanks, >>>> >>>> --Cigdem >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Wed, May 22, 2019 at 10:58 PM Jim Schaad >>>> wrote: >>>> >>>> Thanks for the updates from my last message. This has helped quite a >>>> bit. >>>> >>>> 1. A discussion of the use of raw public keys rather than certificate= s >>>> for >>>> the server may be in order. This can refer to the same RPK issues fro= m >>>> the >>>> current DTLS document. It may also be that this just uses normal >>>> certificate processing and that should be noted as well, but some >>>> discussion >>>> of deciding if the subject name/alt name matches the token returned >>>> from the >>>> AS. >>>> >>>> For the connect message there are a couple of issues that need to be >>>> thought >>>> about. >>>> >>>> 2. What items are required to be in the connect message. The respons= e >>>> to >>>> my last message suggested that a client identifier is required to be >>>> present >>>> but that is not documented. >>>> >>>> 3. It is not completely clear what portions of the CONNECT message ar= e >>>> being covered by the signature/MAC value. As an example, is the >>>> password >>>> field omitted entirely or is it set to a zero length password. In >>>> addition >>>> to this, from the couple of implementations that I have looked at the >>>> entire >>>> packet is not passed out of the base server code for authentication >>>> purposes. This might need to be taken into account in terms of what i= s >>>> used >>>> for the body and how it is constructed. (As a side note, the >>>> implementations that I have looked at so far also think that the >>>> password is >>>> a text string rather than a binary value which is going to be a short >>>> term >>>> issue as well.) >>>> >>>> 4. I must admit that I am disappointed that there is no challenge >>>> response >>>> mechanism in the MQTT specifications. I don't know that anything can = be >>>> done at this point about it but there are some security issues that >>>> need to >>>> be highlighted because of this in the security considerations section. >>>> Only >>>> the v3 seems to have this problem. Also doing the channel binding wou= ld >>>> deal with this problem as well. Might just need some general >>>> discussions >>>> around the channel binding text. >>>> >>>> 5. Is there an intention to provide a "standard" format for the scope >>>> field >>>> or just to leave it as ad hoc? >>>> >>>> 6. It might be reasonable in section 2.1.3 to note that even if a >>>> result is >>>> cached, that cached check should be limited for a specific amount of >>>> time to >>>> recheck if the token is still active. More of an issue in terms of ho= w >>>> long >>>> to cache for introspection. >>>> >>>> 7. In section 2.1.4 - I would presume that the last paragraph should = be >>>> extended to say that the token is stored only for the length of the >>>> connection. That is the token always needs to be supplied every time = a >>>> connect message is sent. >>>> >>>> Jim >>>> >>>> >>>> _______________________________________________ >>>> Ace mailing list >>>> Ace@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ace >>>> >>>> _______________________________________________ >>> Ace mailing list >>> Ace@ietf.org >>> https://www.ietf.org/mailman/listinfo/ace >>> >> _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > --000000000000daa9fa058e8323ff Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
looks fine to me, thanks for addressing them. Let the WG k= now when you have a stable version, so that further reviews can be provided= .

Yours,=C2=A0
Daniel=C2=A0

On Thu, Jul 2= 5, 2019 at 10:54 AM Cigdem Sengul <cigdem.sengul@gmail.com> wrote:
Hello Daniel= ,=C2=A0

Thank you very much for your comments. I have co= mmented on them below and created corresponding GitHub issues to be address= ed soon.=C2=A0

One thing that affects how we addre= ss most of the comments is the order of presentation of MQTT v5 and MQTT v3= .1.1.=C2=A0
I completely agree that if the order is reversed, and= v3.1.1. 1 is presented for backward compatibility, this would improve the = document.=C2=A0 This is the highest priority issue, and all the other issue= s will be addressed once that change is made.=C2=A0

Other comments and pointers to Github are inline. Let me know if I missed= anything.=C2=A0

Sincerely,
--Cigdem=C2= =A0

...
=C2=A0 =C2=A0improvements= to the basic protocol with the new MQTT v5.0 - the OASIS
=C2=A0 =C2=A0S= tandard [MQTT-OASIS-Standard-v5] (e.g., improved authentication
=C2=A0 = =C2=A0exchange and error reporting).=C2=A0 Both versions are expected to be=
=C2=A0 =C2=A0supported in practice, and therefore, covered in this docu= ment.

<mglt>

I understand that the basic protocol refer= s to MQTTv3.3.1.1 It might be
clearer to explicitly mention that MQTT v3= .1.1 is the basic protocol.
The other way around could be to remove to t= he basis protocol" in the
latest sentence.

Probably that my= missing background on MQTT, but -at least for my
personnal knowledge - = I believe that some clarification over the support
of the v5 and v3.1.1 = could be clarified.=C2=A0 When support for both version
is mentioned, I = am wondering if this documents mandate that any RS
implements both v3.1.= 1 AND v5 or if it states that v3.1.1 is by no way
being sunset. In other= words, it is envisioned that some system will use
v3.1.1 *for ever* in = which case their associated is expected to support
v3.1.1. The same will= occur for v5 respectively. Another alternative
could be that MQTTv5 add= s functionalities to v3.1.1, leading to some
sort of backward compatibil= ity that are sufficient in most cases.

</mglt>

Cigdem:=C2=A0
This would be som= ewhat clarified when we present MQTT v5 first and recommend its use.=C2=A0<= /div>

Everything that is described for MQTT v3.1. is= doable by MQTT v5, and therefore there is backward compatibility.
However, it has to be signalled to the client indeed.=C2=A0

The= broker should advertise which version(s) it supports.=C2=A0

https://github.com/a= ce-wg/mqtt-tls-profile/issues/9





=C2=A0 =C2=A0Clients use client authorization servers [I-D.iet= f-ace-actors] to
=C2=A0 =C2=A0obtain tokens from the authorization serve= r.=C2=A0 The communication
=C2=A0 =C2=A0protocol between the client auth= orization server and the
=C2=A0 =C2=A0authorization server is assumed to= be HTTPS.=C2=A0 Also, if the broker
=C2=A0 =C2=A0supports token introsp= ection, it is assumed to use HTTPS to
=C2=A0 =C2=A0communicate with the = authorization server.=C2=A0 These interfaces MAY be
=C2=A0 =C2=A0impleme= nted using other protocols, e.g., CoAP or MQTT. =C2=A0

<mglt><= br>I have the impression that the proposed alternatives are unsecured. I am=
wondering if that is intentional. I believe that these communicationsneeds to be secured appropriately.
=C2=A0
My understanding is that = MQTT will work on top of TCP/TLS. If that is
correct, I am wondering if = it is envisioned that a full HTTP client is
embedded into small motes, o= r a minimal library restricted to support
the interaction with the AS. T= he reason I am asking this question is
related to a discussion we had in= homenet, so that is only for my
personal knowledge and unrelated to MQT= T.

</mglt>

Cig= dem:=C2=A0

=C2=A0<= /span>The resource-constrained client needs to support MQTT and ACE only.=C2=A0=

The= client authorisation server (CAS) and resource broker (server)=C2=A0 (= RS) need to support HTTPS - they may want to communicate over MQTT or CoAP = but these need to be secured as expected from CAS-AS and RS-AS security req= uirements of ACE core document.=C2=A0

You have a later comment on this, whi= ch I respond to there but it will be tied to the same Github issue.=C2=A0

Created GitHub issue: https://github.com/ace-wg/mqtt-tls-profile/is= sues/10



=C2=A0 =C2=A0The term "Resour= ce" is used to refer to an MQTT "topic name," which
=C2= =A0 =C2=A0is defined in Section 1.3.=C2=A0 Hence, the "Resource Owner&= quot; is any entity
=C2=A0 =C2=A0that can authoritatively speak for the = "topic".

<mglt>
scetion 1.3 defines the Topic nam= e. It might be more helpful to the
reader if the exact same term is used= both in the text of the document
and in the terminology - that is even = considering upper/lower letters. =C2=A0

I am wondering if broker sho= uld be defined as well.

Similarly, there seems that Clients are com= posed of various sub clients
( client authorisation server, client (MQTT= ), subscriber, publisher).
Maybe these different designation could be de= fined as well in the
terminology section. Maybe also some designations m= ight not be necessary
to introduce.
</mglt>

Cigdem:=C2=A0

Wil= l make sure consistency in upper/lower characters.=C2=A0

Wil= l define the broker.=C2=A0


Yes= , we assumed there may be a CAS that will speak HTTPS to get the tokens fro= m AS. Or if the client itself is capable of doing that, it would not need a= CAS.=C2=A0


Oth= er than that, the MQTT client software may act both as a publisher or subsc= riber. We only separated them for the clarity of presentation.=C2=A0=C2=A0

Also, there are some=C2=A0command line MQTT clients that just publish = or just subscribe.=C2=A0

Sti= ll, I would not consider publisher/subscriber pieces as sub-clients.=C2=A0 I think we explain this in the text but will also bring it to the Termin= ology section.

Github issue: https://github.com/ace-wg/mqtt-tls-profile/issues/11<= /a>




2.1.1= .=C2=A0 Client Authorization Server (CAS) and Authorization Server (AS)
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 Interaction

=C2=A0 =C2=A0The first step = in the protocol flow (Figure 1 (A)) is the token
=C2=A0 =C2=A0acquisitio= n by the client authorization server (CAS) from the AS.=C2=A0 If
=C2=A0 = =C2=A0a client has enough resources and can support HTTPS, or optionally=C2=A0 =C2=A0the AS supports MQTTS, these steps can instead be carried out= by a
=C2=A0 =C2=A0client directly.

<mglt>
MQTTS and CAS= should in my opinion be mentioned in the terminology
section.

&= quot;optionally" might be clarified further. The introduction mentione= d
HTTPS was considered as the supported protocol. but it seems here that=
the support of HTTPS may not be obvious, in which case the support ofMQTTS might be RECOMMENDED/SHOULD or even stronger.. The recommendationmay also be associated to current deployments, especially concerning how<= br>AS are dedicated to a technology or not. I do =C2=A0not see strong
re= commendations for the AS to support one specific protocol, so I
believe = clarification/discussions on MQTTS / HTTPS should be provided in
the doc= ument. =C2=A0

"""
=C2=A0 =C2=A0other underlying=C2=A0 =C2=A0protocols are not prohibited from being supported in the futu= re, such
=C2=A0 =C2=A0as HTTP/2, MQTT, BLE and QUIC.
""&quo= t;

</mglt>



2.1.2.=C2=A0 Client Conne= ction Request to the Broker

=C2=A0 =C2=A0Once the client acquires th= e token, it can use it to request an MQTT
=C2=A0 =C2=A0connection to the= broker over a TLS session with server
=C2=A0 =C2=A0authentication (Figu= re 1 (D)).=C2=A0 This section describes the client
=C2=A0 =C2=A0transpor= ting the token to the broker (RS) via the CONNECT control
=C2=A0 =C2=A0m= essage after the TLS handshake.=C2=A0 This is similar to an earlier
=C2= =A0 =C2=A0proposal by Fremantle et al. [fremantle14].=C2=A0 An improvement = to this
=C2=A0 =C2=A0is presented in Section 3 for the MQTT v5 - the OAS= IS Standard
=C2=A0 =C2=A0[MQTT-OASIS-Standard-v5]. =C2=A0

<mgl= t>
I believe the description of the improvement has been omitted. It = woudl
help the reader to get an overview of the improvement.
</mg= lt>


Yes= , the improvement is now there are specific fields that can be used for aut= horisation in MQTT v5, and overloading of password/username fields can be a= voided.=C2=A0

This will be better explained when the order of MQTTv5 and MQ= TT v3.1.1.1 is changed.=C2=A0

Github issue at=C2=A0https://github.com/ace-wg/mqtt-tls-profile/iss= ues/12



=C2=A0 =C2=A0The Will flag indicat= es that a Will message needs to be sent when a
=C2=A0 =C2=A0client disco= nnection occurs.=C2=A0 The situations in which the Will
=C2=A0 =C2=A0mes= sage is published include disconnections due to I/O or network
=C2=A0 = =C2=A0failures, and the server closing the networking connection due to a=C2=A0 =C2=A0protocol error.=C2=A0 The client may set the Will flag as de= sired (marked
=C2=A0 =C2=A0as 'X' in Figure 3).=C2=A0 If the Wil= l flag is set to 1 and the broker
=C2=A0 =C2=A0accepts the connection re= quest, the broker must store the Will
=C2=A0 =C2=A0message, and publish = it when the network connection is closed
=C2=A0 =C2=A0according to Will = QoS and Will retain parameters, and MQTT Will
=C2=A0 =C2=A0management ru= les.=C2=A0 Section 2.5 explains how the broker deals with the
=C2=A0 =C2= =A0retained messages in further detail.

<mglt>
Figure menti= ons Will Flag while the text mentions Will flag.

From the paragraph= , I cannot figure out what a Will message is. Maybe
that could be explai= ned or a reference to it may be indicated.

</mglt>
<= /div>

Cigdem :

Sur= e, will pay attention to be consistent with the capitalisations.=C2=A0

The= Will message is indeed the client=E2=80=99s will when it dies. That=E2=80= =99s why it is sent in the case of a disconnection. Will improve its explan= ation.=C2=A0

I c= an this also to MQTT terminology section:=C2=A0

Wi= ll Message:

An Ap= plication Message which is published by the Server after the Network Connec= tion is closed in cases where the Network Connection is not closed normally= .=C2= =A0

If Wi= ll Flag is set, then the payload of the Connect message has information abo= ut the Will message.=C2=A0

The W= ill Message consists of the Will Properties, Will Topic, and Will Payload f= ields in the CONNECT Payload.

Github issue:https://github.com/ace-wg/mqtt-tls-pr= ofile/issues/13

https://git= hub.com/ace-wg/mqtt-tls-profile/issues/11



=C2=A0 =C2=A0The broker responses may follow either the MQT= T v3.1.1 - the OASIS
=C2=A0 =C2=A0Standard [MQTT-OASIS-Standard] or the = MQTT v5 - the OASIS Standard
=C2=A0 =C2=A0[MQTT-OASIS-Standard-v5], depe= nding on which version(s) the broker
=C2=A0 =C2=A0supports.
<mglt&= gt;
I believe that references to MQTTv3.1.1 and MQTTv5 provided in theintroduction are sufficient, and there is no need to have teh referenceanytime MQTT is invoked. =C2=A0
</mglt>

Cig= dem:=C2=A0


Will remove, and it will improve the readability of the d= ocument.=C2=A0




3.=C2=A0 Improved Protocol Interactions with MQTT v5
=C2=A0 =C2=A0In the new MQTT v5 - the OASIS Standard [MQTT-OASIS-Stand= ard-v5],
=C2=A0 =C2=A0several new capabilities are introduced, which ena= ble better
=C2=A0 =C2=A0integration with ACE.=C2=A0 The newly enhanced a= uthentication and re-
=C2=A0 =C2=A0authentication methods support a wide= r range of authentication flows
=C2=A0 =C2=A0beyond username and passwor= d.=C2=A0 With the MQTT v5, there is a clearly
=C2=A0 =C2=A0defined appro= ach for using token-based authorization.=C2=A0 Also, it is
=C2=A0 =C2=A0= possible for a client to request a re-authentication avoiding
=C2=A0 =C2= =A0disconnection.=C2=A0 Finally, MQTT v5 generally improves error reporting= ,
=C2=A0 =C2=A0enabling better response to authorization failures during= publishing
=C2=A0 =C2=A0messages to the subscribers.

<mglt>= ;
Given that MQTT provides a better integration with ACE, I am wondering=
if MQTTv5 should not be considered as the primary description and havin= g
MQTT3.1.1 related to legacy MQTT. This is seems to me simply re-orderi= ng the
sections. However, the message carried would be to move to MQTTv5= when
possible.

I also believe that a recommendation on supporti= ng MQTTv5 should me made
in the document.

</mglt>

Cigdem:

Thi= s is a good idea. We kept the order because of historical reasons. Will wor= k on that as a first requirement before fixing other GitHub issues. =C2=A0


=C2= =A0 hentication capabilities, it is not necessary to
=C2=A0 =C2=A0overlo= ad the username and password fields in the CONNECT message for
=C2=A0 = =C2=A0ACE authentication.=C2=A0 Nevertheless, the RS MUST support both meth= ods
=C2=A0 =C2=A0for supporting the token: (1) Token transport via usern= ame and
=C2=A0 =C2=A0password and (2) using the new AUTH (Authentication= Exchange) method.
=C2=A0 =C2=A0The token transport via username and pas= sword is as described in
=C2=A0 =C2=A0Section 2.1.2.=C2=A0 The rest of t= his section describes the AUTH method.

<mglt>
As mentioned = before, it might be better to mention what to do and
explain in MQTT why= we overload the username/password. =C2=A0
</mglt>
=


Cigdem:=C2=A0If the order of des= criptions is changed, then we can clarify this better.=C2=A0

Github issue: https://github.com/ace-wg/mqtt-tls-profile/issues/12<= /span>


=C2=A0On Fri, May 24, 2019 at 4:57 AM Cigdem Seng= ul <cigdem.= sengul@gmail.com> wrote:
Hello,=C2=A0

T= hanks, Jim, this was helpful, and it also triggered that I go back and read= the introspection section of the core draft again.=C2=A0


=C2=A0

[JLS] For introspection, but not = for a published token, the token could be =E2=80=9Crevoked=E2=80=9D by the = RS.=C2=A0 In this case a new introspection check would lead to that informa= tion.=C2=A0 There may be ways to deal with this in the introspection dialog= and not need to be called up here.=C2=A0 The question would be does the ex= i field mean =E2=80=93 recheck the token or discard the token.=C2=A0=


Understo= od. We definitely need to clarify here what we do with exi field if it exis= ts, and if it doesn't exist. The MAY language we used in the draft is n= ot appropriate if exi does not exist.=C2=A0
We considered the exp= iration time in the introspection response as a revocation signal and hence= RS discards the token.=C2=A0 (The basic flow was: RS receives a token, int= rospects it, caches the result and then when it expires, it revokes the tok= en - which may next lead to different steps depending on the version of the= MQTT.)
But if introspection is done to handle the case of dynami= c authorisation decisions, and exi would signal a recheck indeed.=C2=A0=C2=A0
=
Will clarify.= =C2=A0

Thanks,
--Cigdem=C2=A0

=C2=A0
=

=

<= /u>=C2=A0

Jim

=C2=A0

=C2=A0

7. That is c= orrect. Will add the clarification.=C2=A0

=C2=A0

Thanks,

--Cigdem=C2=A0<= u>

=C2=A0

=

=C2=A0

=C2=A0

=C2=A0

On Wed, May 22, 2= 019 at 10:58 PM Jim Schaad <ietf@augustcellars.com> wrote:

Thanks for the updates from my last me= ssage.=C2=A0 This has helped quite a bit.

1.=C2=A0 A discussion of t= he use of raw public keys rather than certificates for
the server may be= in order.=C2=A0 This can refer to the same RPK issues from the
current = DTLS document.=C2=A0 It may also be that this just uses normal
certifica= te processing and that should be noted as well, but some discussion
of d= eciding if the subject name/alt name matches the token returned from theAS.

For the connect message there are a couple of issues that need = to be thought
about.

2.=C2=A0 What items are required to be in th= e connect message.=C2=A0 The response to
my last message suggested that = a client identifier is required to be present
but that is not documented= .

3.=C2=A0 It is not completely clear what portions of the CONNECT m= essage are
being covered by the signature/MAC value.=C2=A0 As an example= , is the password
field omitted entirely or is it set to a zero length p= assword.=C2=A0 In addition
to this, from the couple of implementations t= hat I have looked at the entire
packet is not passed out of the base ser= ver code for authentication
purposes.=C2=A0 This might need to be taken = into account in terms of what is used
for the body and how it is constru= cted.=C2=A0 (As a side note, the
implementations that I have looked at s= o far also think that the password is
a text string rather than a binary= value which is going to be a short term
issue as well.)

4.=C2=A0= I must admit that I am disappointed that there is no challenge responsemechanism in the MQTT specifications.=C2=A0 I don't know that anything= can be
done at this point about it but there are some security issues t= hat need to
be highlighted because of this in the security consideration= s section.=C2=A0 Only
the v3 seems to have this problem.=C2=A0 Also doin= g the channel binding would
deal with this problem as well.=C2=A0 Might = just need some general discussions
around the channel binding text.
<= br>5.=C2=A0 Is there an intention to provide a "standard" format = for the scope field
or just to leave it as ad hoc?

6.=C2=A0 It mi= ght be reasonable in section 2.1.3 to note that even if a result is
cach= ed, that cached check should be limited for a specific amount of time torecheck if the token is still active.=C2=A0 More of an issue in terms of h= ow long
to cache for introspection.

7.=C2=A0 In section 2.1.4 - I= would presume that the last paragraph should be
extended to say that th= e token is stored only for the length of the
connection.=C2=A0 That is t= he token always needs to be supplied every time a
connect message is sen= t.

Jim


_______________________________________________Ace mailing list
Ace@= ietf.org
https://www.ietf.org/mailman/listinfo/ace

_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
--000000000000daa9fa058e8323ff-- From nobody Tue Jul 30 08:56:19 2019 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 4595C120187; Tue, 30 Jul 2019 08:56:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.199 X-Spam-Level: X-Spam-Status: No, score=-1.199 tagged_above=-999 required=5 tests=[ADVANCE_FEE_2_NEW_FORM=1, BAYES_00=-1.9, FILL_THIS_FORM=0.001, FILL_THIS_FORM_LONG=2, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no 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 JOKfcXMYg2Qs; Tue, 30 Jul 2019 08:56:15 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 B1897120127; Tue, 30 Jul 2019 08:56:11 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x6UFu7ex005833 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 30 Jul 2019 11:56:09 -0400 Date: Tue, 30 Jul 2019 10:56:06 -0500 From: Benjamin Kaduk To: draft-ietf-ace-cwt-proof-of-possession.all@ietf.org Cc: ace@ietf.org Message-ID: <20190730155605.GM47715@kduck.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: [Ace] AD review of draft-ietf-ace-cwt-proof-of-possession-06 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: Tue, 30 Jul 2019 15:56:17 -0000 We should be consistent across examples about whether the use of CBOR diagnostic notation also requires a disclaimer about "with linebreaks for readability". Section 2 Presenter Party that proves possession of a private key (for asymmetric key cryptography) or secret key (for symmetric key cryptography) to a recipient. nit: it might be worth either capitalizing Recipient to point to the following item more clearly, or specifying "recipient of a CWT" for parallelism with Recipient. (If we do the former we should capitalize Presenter in the following definition. But since we don't use the capitalized terms throughout the text, it wouldn't be my own preference.) Section 3.2 This example key expired in 2013. While the example will "always" be expired for an archival document, it might be worth making it more timely with respect to the publication date. (This holds for basically all time values in the document's examples.) Value 2 for 'kty' should have diagnostic notation /EC2/, not /EC/. [I did not check that the example x and y coordinates are in fact points on P256.] The "COSE_Key" member MAY also be used for a COSE_Key representing a symmetric key, provided that the CWT is encrypted so that the key is not revealed to unintended parties. The means of encrypting a CWT is explained in [RFC8392]. If the CWT is not encrypted, the symmetric key MUST be encrypted as described in Section 3.3. It's hard for me to escape the conclusion that this paragraph needs to be a dedicated section with a bit more discussion about how exactly this usage is performed and encoded. Section 3.3 Is the /HMAC256/ the conventional diagnostic notation for alg value 5 (noting that RFC 8152 calls it both "HMAC256/256" and "HMAC w/ SHA-256")? The following example CWT Claims Set of a CWT (using CBOR diagnostic notation, with linebreaks for readability) illustrates the use of an encrypted symmetric key as the "Encrypted_COSE_Key" member value: { /iss/ 1 : "coaps://server.example.com", /sub/ 2 : "24400320", /aud/ 3: "s6BhdRkqt3", /exp/ 4 : 1311281970, /iat/ 5 : 1311280970, /cnf/ 8 : { /COSE_Encrypt0/ 2 : [ Should this be "/Encrypted_COSE_Key/" and not "/COSE_Enrypt0/"? [I did not validate the COSE_Encrypt0 output] Section 3.4 { /iss/ 1 : "coaps://server.example.com", /aud/ 3 : "coaps://client.example.org", Is it in any way confusing to use client.example.org as opposed to, say, resource.example.org as the audience? /exp/ 4 : 1361398824, /cnf/ 8 : { /kid/ 2 : h'dfd1aa976d8d4575a0fe34b96de2bfad' /kid/ in the 'cnf' map has key 3, not 2. Note that the use of a Key ID to identify a proof-of-possesion key needs to be carefully circumscribed, as described below and in Section 6. Where the Key ID is not a cryptographic value derived from the key or where all of the parties involved are not validating the cryptographic derivation, it is possible to get into situations where the same Key ID is being used for multiple keys. The I don't think this quite covers the needed properties, since we also need some assurance that all parties are interpreting the kid value in the same way. It may be possible to construct such a scenario via an attacker replaying a stolen token or even just inadvertent confusion by some party (quite plausible when we consider scenarios that involve the same key being described by different 'kid' values in messages with different recipients). In particular, if the situation arises where an attacker is able to choose the 'kid' value that will be used, they could deliberately cause a collision with a legitimate value used by some other party. In the world of constrained Internet of Things (IoT) devices, there is frequently a restriction on the size of Key IDs, either because of table constraints or a desire to keep message sizes small. These restrictions are going to protocol dependent. For example, DTLS can nit: "going to be" or maybe even just "are protocol dependent". use a Key ID of any size. However, if the key is being used with COSE encrypted message, then the length of the key needs to be minimized and may have a limit as small as one byte. nit: is this "length of the key" or "length of the key ID"? Note that the value of a Key ID is not always the same for different parties. When sending a COSE encrypted message with a shared key, the Key ID may be different on both sides of the conversation, with the appropriate one being included in the message based on the recipient of the message. While this recipient-dependence is probably unavoidable (as the requisite namespacing would use more space on the wire than is reasonable for many applications), it does merit some security considerations text, noting that such messages are context-dependant and could be misinterpreted if presented in a different context. Audience restrictions, as mentioned in Section 4, provide substantial protection in this regard, but are not necessarily a complete solution. o A recipient can decide not to use a CWT based on a created Key ID if it does not fit the recipient's requirements. I'm not sure I understand the semantics being described here. Are we saying that the issuer might give a presenter a CWT, and by the time the presenter presents the CWT to the recipient, the recipient says "this is no good" and denies the transaction in question, forcing the presenter to go back to the issuer and try again? (How do we know that the issuer would make any different choices the second time around?) o If an issuer is going to use the Key ID confirmation method and is not going to guarantee that serial number uniqueness is going to be preserved, the recipient needs to have that information configured into it so that appropriate actions can be taken. nit: this is the only place in the document that talks about "serial number"s. Do we say what the "appropriate actions" are somewhere else in the document? Section 3.5 Note that another means of proving possession of the key when it is a symmetric key is to encrypt the key to the recipient. The means of obtaining a key for the recipient is likewise protocol specific. While true, there are some subtleties here, namely that the recipient needs some way of knowing that it is the presenter (as opposed to some other party) that has actually performed that encryption. In Kerberos we perform this key confirmation by using the encrypted (session) key for subsequent protocol exchanges, and if the presenter fails to process those exchanges then it is clear the presenter does not actually possess the key. This document does not seem to describe the need for such subsequent confirmation (or, alternately, the consequences of failing to do so.) Section 4 A recipient might not understand the "cnf" claim. Applications that require the proof-of-possession keys communicated with it to be understood and processed MUST ensure that the parts of this specification that they use are implemented. nit(?): I'm not sure I'm parsing this sentence correctly: is "communicated with it" referring to "CWTs that include the 'cnf' claim"? To avoid replay attacks when the proof-of-possession tokens are sent to presenters, a security protocol, which uses mechansims such as nonces or timestamps, has to be utilized. [...] I suspect the RFC Editor will want to reword this sentence to avoid the excessive parentheticals and awkward passive-voice construction. I'll be bold and suggest a more dramatic rewording to preempt that: "Proof of possession only provides the intended security gains when the proof is known to be current and not subject to replay attacks; security protocols using mechanisms such as nonces and timestamps can be used to avoid this risk of replay when sending proof-of-possession tokens to [presenters or recipients]". Note that I am not sure if the original was intended to refer to the transfer of PoP tokens to presenters (as written) or recipients (where risk of replay is more traditionally concerned). from changing any elements conveyed within the CWT payload. Special care has to be applied when carrying symmetric keys inside the CWT since those not only require integrity protection but also confidentiality protection. Do we want to reiterate the common mechanisms for providing confidentiality protection here, or just leave the existing text earlier in the document to cover it? Section 5 This sort of correlation can occur even for subsequent connections between the same two parties if observed by a passive observer (e.g., in the case of a mobile client that changes location). I forget if we have strong enough guarantees on the use of transport-level encryption that would prevent such CWTs from being observed in this fashion. Section 6 ensure correct processing. The recipient needs to be able to use credentials to verify the authenticity, integrity, and potentially the confidentiality of the CWT and its content. This requires the Just from a rhetorical point of view, can you help me understand how credentials would be used to verify the confidentiality of a CWT? It seems like this depends on either (or both of) how the CWT is transmitted or how it is prepared, and I am not sure how the recipient's credentials come into play. recipient to know information about the issuer. Likewise, there needs to be agreement between the issuer and the recipient about the claims being used (which is also true of CWTs in general). We briefly discuss the presenter (in the guise of the subject) in the next paragraph when we talk about key IDs, but are there any other cases where there needs to be coordination with the presenter? Would distributing a symmetric PoP key be considered to fall under this mantle? When an issuer creates a CWT containing a Key ID claim, it needs to make sure that it does not issue another CWT containing the same Key ID with a different content, or for a different subject, within the lifetime of the CWTs, unless intentionally desired. Failure to do so may allow one party to impersonate another party, with the potential to gain additional privileges. Likewise, if PoP keys are used for nit: "same Key ID with a different content" doesn't seem quite right, as the "content" of a Key ID is surely the key-ID value itself. Perhaps "referring to" would be more appropriate. I think we should probably give the reader some indication of what semantics might be attributed to the "intentionally desired" case. It doesn't necessarily need to be a specific example, but we could say what the relevant properties/attributes that might lead to such a situation would be. multiple different kinds of CWTs in an application and the PoP keys are identified by Key IDs, care must be taken to keep the keys for the different kinds of CWTs segregated so that an attacker cannot cause the wrong PoP key to be used by using a valid Key ID for the wrong kind of CWT. Audience restrictions can come into play here, too, right? In that a restricted audience of all the CWTs in turn limits the scope of administration in which this care/segregation needs to be enforced. Section 7 Criteria that should be applied by the Designated Experts include determining whether the proposed registration duplicates existing functionality, determining whether it is likely to be of general applicability or whether it is useful only for a single application, and evaluating the security properties of the item being registered and whether the registration makes sense. I know we've been using (variations of) this text for a while, but it seems to me that it could be more clear than it currently is -- is duplication of functionality grounds for denial of registration? What about general vs. specific applicability? The latter seems more clearly applicable for determining which range from which to allocate, since that has impact on the encoding size. Can the experts insist on updates to the security considerations text of a specification prior to granting approval, or are they limited to denying registration of values with poor security properties or insufficient documentation thereof? Section 7.2.1 Change Controller: For Standards Track RFCs, list the "IESG". For others, give the name of the responsible party. Other details (e.g., postal address, email address, home page URI) may also be included. In light of the GDPR and similar regulations (and, as is done in RFC 8602), we may not want to keep all of these, especially postal address, given the lack of a clear need. Specification Document(s): Reference to the document or documents that specify the parameter, preferably including URIs that can be used to retrieve copies of Is the reference required to be publicly accessible? If not, is it required that a copy be made available to the experts and IANA? Section 7.2.2 o Confirmation Method Name: "Encrypted_COSE_Key" o Confirmation Method Description: Encrypted COSE_Key o JWT Confirmation Method Name: "jwe" o Confirmation Key: 2 o Confirmation Value Type(s): COSE_Encrypt or COSE_Encrypt0 structure (with an optional corresponding COSE_Encrypt or COSE_Encrypt0 tag) Do we want to say something about how, in the case when the tag is omitted, the application protocol specification needs to indicate how to determine which one is in use? Section 8.2 I think [JWT] needs to be normative, as we have a SHOULD-level requirement for the audience restriction procedures it specifies. I just want to check that it's intentional/desired to mix descriptive reference tags (e.g., [JWS]) and RFC-number tags (e.g., [RFC7800]) for the referenced RFCs. Acknowledgements, Authors The datatracker is currently accepting XML v3 format drafts, and the RFC Editor's target cutover date for the end of August is quite soon, so feel free to consider using an XML v3 submission with UTF-8 representations of names not well represented by the ASCII subset. From nobody Tue Jul 30 10:10:25 2019 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 2915B12017C; Tue, 30 Jul 2019 10:10:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 NoEfKZ9tVxCi; Tue, 30 Jul 2019 10:10:21 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 209D6120089; Tue, 30 Jul 2019 10:10:21 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 30 Jul 2019 10:10:14 -0700 From: Jim Schaad To: 'Benjamin Kaduk' , CC: References: <20190730155605.GM47715@kduck.mit.edu> In-Reply-To: <20190730155605.GM47715@kduck.mit.edu> Date: Tue, 30 Jul 2019 10:10:12 -0700 Message-ID: <010701d546f9$a8281da0$f87858e0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQGSG8HHJPznl9Uxd4m73YTJRCcQLKdpsoGQ X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Ace] AD review of draft-ietf-ace-cwt-proof-of-possession-06 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: Tue, 30 Jul 2019 17:10:24 -0000 Comments inline. -----Original Message----- From: Benjamin Kaduk Sent: Tuesday, July 30, 2019 8:56 AM To: draft-ietf-ace-cwt-proof-of-possession.all@ietf.org Cc: ace@ietf.org Subject: AD review of draft-ietf-ace-cwt-proof-of-possession-06 We should be consistent across examples about whether the use of CBOR diagnostic notation also requires a disclaimer about "with linebreaks for readability". [JLS] I don't believe that this disclaimer needs to be present. Unlike the JSON document where what is being presented is in fact JSON, what is being presented here is simply a more user friendly readable version of the binary data. (A different question would be if the hex should be presented but that is not what the ACE group is doing in general.) Section 2 Presenter Party that proves possession of a private key (for asymmetric key cryptography) or secret key (for symmetric key cryptography) to a recipient. nit: it might be worth either capitalizing Recipient to point to the following item more clearly, or specifying "recipient of a CWT" for parallelism with Recipient. (If we do the former we should capitalize Presenter in the following definition. But since we don't use the capitalized terms throughout the text, it wouldn't be my own preference.) Section 3.2 This example key expired in 2013. While the example will "always" be expired for an archival document, it might be worth making it more timely with respect to the publication date. (This holds for basically all time values in the document's examples.) Value 2 for 'kty' should have diagnostic notation /EC2/, not /EC/. [I did not check that the example x and y coordinates are in fact points on P256.] The "COSE_Key" member MAY also be used for a COSE_Key representing a symmetric key, provided that the CWT is encrypted so that the key is not revealed to unintended parties. The means of encrypting a CWT is explained in [RFC8392]. If the CWT is not encrypted, the symmetric key MUST be encrypted as described in Section 3.3. It's hard for me to escape the conclusion that this paragraph needs to be a dedicated section with a bit more discussion about how exactly this usage is performed and encoded. Section 3.3 Is the /HMAC256/ the conventional diagnostic notation for alg value 5 (noting that RFC 8152 calls it both "HMAC256/256" and "HMAC w/ SHA-256")? [JLS] HMAC 256/256 is the algorithm name while HMAC w/ SHA-256 is descriptive. I believe that this is completely consistent in RFC 8152. The following example CWT Claims Set of a CWT (using CBOR diagnostic notation, with linebreaks for readability) illustrates the use of an encrypted symmetric key as the "Encrypted_COSE_Key" member value: { /iss/ 1 : "coaps://server.example.com", /sub/ 2 : "24400320", /aud/ 3: "s6BhdRkqt3", /exp/ 4 : 1311281970, /iat/ 5 : 1311280970, /cnf/ 8 : { /COSE_Encrypt0/ 2 : [ Should this be "/Encrypted_COSE_Key/" and not "/COSE_Enrypt0/"? [I did not validate the COSE_Encrypt0 output] Section 3.4 { /iss/ 1 : "coaps://server.example.com", /aud/ 3 : "coaps://client.example.org", Is it in any way confusing to use client.example.org as opposed to, say, resource.example.org as the audience? /exp/ 4 : 1361398824, /cnf/ 8 : { /kid/ 2 : h'dfd1aa976d8d4575a0fe34b96de2bfad' /kid/ in the 'cnf' map has key 3, not 2. Note that the use of a Key ID to identify a proof-of-possesion key needs to be carefully circumscribed, as described below and in Section 6. Where the Key ID is not a cryptographic value derived from the key or where all of the parties involved are not validating the cryptographic derivation, it is possible to get into situations where the same Key ID is being used for multiple keys. The I don't think this quite covers the needed properties, since we also need some assurance that all parties are interpreting the kid value in the same way. It may be possible to construct such a scenario via an attacker replaying a stolen token or even just inadvertent confusion by some party (quite plausible when we consider scenarios that involve the same key being described by different 'kid' values in messages with different recipients). In particular, if the situation arises where an attacker is able to choose the 'kid' value that will be used, they could deliberately cause a collision with a legitimate value used by some other party. [JLS] I don't agree with that. It should be assumed by all implementations that there will be collisions between kid values. Except in very specific cases such as all of the kids being assigned by a group keying server, there is no way for the assumption of a single kid value being assigned once on a recipient basis will ever be a true statement. In the world of constrained Internet of Things (IoT) devices, there is frequently a restriction on the size of Key IDs, either because of table constraints or a desire to keep message sizes small. These restrictions are going to protocol dependent. For example, DTLS can nit: "going to be" or maybe even just "are protocol dependent". use a Key ID of any size. However, if the key is being used with COSE encrypted message, then the length of the key needs to be minimized and may have a limit as small as one byte. nit: is this "length of the key" or "length of the key ID"? Note that the value of a Key ID is not always the same for different parties. When sending a COSE encrypted message with a shared key, the Key ID may be different on both sides of the conversation, with the appropriate one being included in the message based on the recipient of the message. While this recipient-dependence is probably unavoidable (as the requisite namespacing would use more space on the wire than is reasonable for many applications), it does merit some security considerations text, noting that such messages are context-dependant and could be misinterpreted if presented in a different context. Audience restrictions, as mentioned in Section 4, provide substantial protection in this regard, but are not necessarily a complete solution. [JLS] Again I don't understand this, but I think that your concern goes away if you do not assume that kid values are going to be unique for an entity. o A recipient can decide not to use a CWT based on a created Key ID if it does not fit the recipient's requirements. I'm not sure I understand the semantics being described here. Are we saying that the issuer might give a presenter a CWT, and by the time the presenter presents the CWT to the recipient, the recipient says "this is no good" and denies the transaction in question, forcing the presenter to go back to the issuer and try again? (How do we know that the issuer would make any different choices the second time around?) o If an issuer is going to use the Key ID confirmation method and is not going to guarantee that serial number uniqueness is going to be preserved, the recipient needs to have that information configured into it so that appropriate actions can be taken. nit: this is the only place in the document that talks about "serial number"s. Do we say what the "appropriate actions" are somewhere else in the document? Section 3.5 Note that another means of proving possession of the key when it is a symmetric key is to encrypt the key to the recipient. The means of obtaining a key for the recipient is likewise protocol specific. While true, there are some subtleties here, namely that the recipient needs some way of knowing that it is the presenter (as opposed to some other party) that has actually performed that encryption. In Kerberos we perform this key confirmation by using the encrypted (session) key for subsequent protocol exchanges, and if the presenter fails to process those exchanges then it is clear the presenter does not actually possess the key. This document does not seem to describe the need for such subsequent confirmation (or, alternately, the consequences of failing to do so.) Section 4 A recipient might not understand the "cnf" claim. Applications that require the proof-of-possession keys communicated with it to be understood and processed MUST ensure that the parts of this specification that they use are implemented. nit(?): I'm not sure I'm parsing this sentence correctly: is "communicated with it" referring to "CWTs that include the 'cnf' claim"? To avoid replay attacks when the proof-of-possession tokens are sent to presenters, a security protocol, which uses mechansims such as nonces or timestamps, has to be utilized. [...] I suspect the RFC Editor will want to reword this sentence to avoid the excessive parentheticals and awkward passive-voice construction. I'll be bold and suggest a more dramatic rewording to preempt that: "Proof of possession only provides the intended security gains when the proof is known to be current and not subject to replay attacks; security protocols using mechanisms such as nonces and timestamps can be used to avoid this risk of replay when sending proof-of-possession tokens to [presenters or recipients]". Note that I am not sure if the original was intended to refer to the transfer of PoP tokens to presenters (as written) or recipients (where risk of replay is more traditionally concerned). from changing any elements conveyed within the CWT payload. Special care has to be applied when carrying symmetric keys inside the CWT since those not only require integrity protection but also confidentiality protection. Do we want to reiterate the common mechanisms for providing confidentiality protection here, or just leave the existing text earlier in the document to cover it? Section 5 This sort of correlation can occur even for subsequent connections between the same two parties if observed by a passive observer (e.g., in the case of a mobile client that changes location). I forget if we have strong enough guarantees on the use of transport-level encryption that would prevent such CWTs from being observed in this fashion. [JLS] No we don't. Most of the time we are sending CWTs in the clear and not over a transport-level encrypted channel. Section 6 ensure correct processing. The recipient needs to be able to use credentials to verify the authenticity, integrity, and potentially the confidentiality of the CWT and its content. This requires the Just from a rhetorical point of view, can you help me understand how credentials would be used to verify the confidentiality of a CWT? It seems like this depends on either (or both of) how the CWT is transmitted or how it is prepared, and I am not sure how the recipient's credentials come into play. recipient to know information about the issuer. Likewise, there needs to be agreement between the issuer and the recipient about the claims being used (which is also true of CWTs in general). We briefly discuss the presenter (in the guise of the subject) in the next paragraph when we talk about key IDs, but are there any other cases where there needs to be coordination with the presenter? Would distributing a symmetric PoP key be considered to fall under this mantle? When an issuer creates a CWT containing a Key ID claim, it needs to make sure that it does not issue another CWT containing the same Key ID with a different content, or for a different subject, within the lifetime of the CWTs, unless intentionally desired. Failure to do so may allow one party to impersonate another party, with the potential to gain additional privileges. Likewise, if PoP keys are used for nit: "same Key ID with a different content" doesn't seem quite right, as the "content" of a Key ID is surely the key-ID value itself. Perhaps "referring to" would be more appropriate. I think we should probably give the reader some indication of what semantics might be attributed to the "intentionally desired" case. It doesn't necessarily need to be a specific example, but we could say what the relevant properties/attributes that might lead to such a situation would be. multiple different kinds of CWTs in an application and the PoP keys are identified by Key IDs, care must be taken to keep the keys for the different kinds of CWTs segregated so that an attacker cannot cause the wrong PoP key to be used by using a valid Key ID for the wrong kind of CWT. Audience restrictions can come into play here, too, right? In that a restricted audience of all the CWTs in turn limits the scope of administration in which this care/segregation needs to be enforced. Section 7 Criteria that should be applied by the Designated Experts include determining whether the proposed registration duplicates existing functionality, determining whether it is likely to be of general applicability or whether it is useful only for a single application, and evaluating the security properties of the item being registered and whether the registration makes sense. I know we've been using (variations of) this text for a while, but it seems to me that it could be more clear than it currently is -- is duplication of functionality grounds for denial of registration? What about general vs. specific applicability? The latter seems more clearly applicable for determining which range from which to allocate, since that has impact on the encoding size. Can the experts insist on updates to the security considerations text of a specification prior to granting approval, or are they limited to denying registration of values with poor security properties or insufficient documentation thereof? Section 7.2.1 Change Controller: For Standards Track RFCs, list the "IESG". For others, give the name of the responsible party. Other details (e.g., postal address, email address, home page URI) may also be included. In light of the GDPR and similar regulations (and, as is done in RFC 8602), we may not want to keep all of these, especially postal address, given the lack of a clear need. Specification Document(s): Reference to the document or documents that specify the parameter, preferably including URIs that can be used to retrieve copies of Is the reference required to be publicly accessible? If not, is it required that a copy be made available to the experts and IANA? [JLS] It is not clear to me that this is an Designated Expert registry. It is only referred to once in the JWT Confirmation Method Name and that could refer to the JWT registry and not this one. Section 7.2.2 o Confirmation Method Name: "Encrypted_COSE_Key" o Confirmation Method Description: Encrypted COSE_Key o JWT Confirmation Method Name: "jwe" o Confirmation Key: 2 o Confirmation Value Type(s): COSE_Encrypt or COSE_Encrypt0 structure (with an optional corresponding COSE_Encrypt or COSE_Encrypt0 tag) Do we want to say something about how, in the case when the tag is omitted, the application protocol specification needs to indicate how to determine which one is in use? [JLS] This is easy as the number of elements in the array is different between the two. Section 8.2 I think [JWT] needs to be normative, as we have a SHOULD-level requirement for the audience restriction procedures it specifies. [JLS] Should this be indirect through the CWT spec rather than via the JWT spec? I just want to check that it's intentional/desired to mix descriptive reference tags (e.g., [JWS]) and RFC-number tags (e.g., [RFC7800]) for the referenced RFCs. [JLS] I have no problem with this. I find descriptive reference tags to be easier to identify than RFC number tags for which I only know couple of them. Acknowledgements, Authors The datatracker is currently accepting XML v3 format drafts, and the RFC Editor's target cutover date for the end of August is quite soon, so feel free to consider using an XML v3 submission with UTF-8 representations of names not well represented by the ASCII subset. From nobody Tue Jul 30 12:31:26 2019 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 2CEAC120156; Tue, 30 Jul 2019 12:31:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 NFLnBbgRi05Q; Tue, 30 Jul 2019 12:31:19 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 684D412010F; Tue, 30 Jul 2019 12:31:19 -0700 (PDT) Received: from [192.168.217.120] (p548DCCB9.dip0.t-ipconnect.de [84.141.204.185]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 45ymrP4KPczyNP; Tue, 30 Jul 2019 21:31:17 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: <010701d546f9$a8281da0$f87858e0$@augustcellars.com> Date: Tue, 30 Jul 2019 21:31:17 +0200 Cc: Benjamin Kaduk , draft-ietf-ace-cwt-proof-of-possession.all@ietf.org, ace@ietf.org X-Mao-Original-Outgoing-Id: 586207875.3243459-12457b4f99cd80d08c82c52f15160361 Content-Transfer-Encoding: quoted-printable Message-Id: <6A3D405F-F702-4FAB-834B-C258043C655E@tzi.org> References: <20190730155605.GM47715@kduck.mit.edu> <010701d546f9$a8281da0$f87858e0$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Ace] AD review of draft-ietf-ace-cwt-proof-of-possession-06 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: Tue, 30 Jul 2019 19:31:23 -0000 On Jul 30, 2019, at 19:10, Jim Schaad wrote: > From: Benjamin Kaduk =20 >=20 > We should be consistent across examples about whether the use of CBOR > diagnostic notation also requires a disclaimer about "with linebreaks = for > readability". >=20 > [JLS] I don't believe that this disclaimer needs to be present. = Unlike the > JSON document where what is being presented is in fact JSON, what is = being > presented here is simply a more user friendly readable version of the = binary > data. =20 Right. But it is still useful for the reader to be able to look up how = that notation works. CBOR diagnostic notation was originally defined in Section 6 of RFC = 7049, precisely for the purpose of discussing CBOR data items in a = human-readable way. Many current documents make use of some extensions of the original = diagnostic notation, such as the use of whitespace in hex strings. = These extensions are documented in Appendix G of RFC 8610, Extended = Diagnostic Notation (EDN). This is what always should be referenced, = and then no disclaimer is needed. Gr=C3=BC=C3=9Fe, Carsten PS.: > (A different question would be if the hex should be presented but > that is not what the ACE group is doing in general.) I don=E2=80=99t think that showing a hex representation of the encoded = bytes is needed either; CBOR should be well-known enough to readers of = this document via CWT already. From nobody Tue Jul 30 15:03:31 2019 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 8D211120073; Tue, 30 Jul 2019 15:03:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.198 X-Spam-Level: X-Spam-Status: No, score=-1.198 tagged_above=-999 required=5 tests=[ADVANCE_FEE_2_NEW_FORM=1, BAYES_00=-1.9, FILL_THIS_FORM=0.001, FILL_THIS_FORM_LONG=2, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no 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 WSZiN-RkBB4r; Tue, 30 Jul 2019 15:03:26 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 59A5B120045; Tue, 30 Jul 2019 15:03:26 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x6UM3HHU019951 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 30 Jul 2019 18:03:19 -0400 Date: Tue, 30 Jul 2019 17:03:16 -0500 From: Benjamin Kaduk To: Jim Schaad Cc: draft-ietf-ace-cwt-proof-of-possession.all@ietf.org, ace@ietf.org Message-ID: <20190730220316.GT47715@kduck.mit.edu> References: <20190730155605.GM47715@kduck.mit.edu> <010701d546f9$a8281da0$f87858e0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <010701d546f9$a8281da0$f87858e0$@augustcellars.com> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [Ace] AD review of draft-ietf-ace-cwt-proof-of-possession-06 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: Tue, 30 Jul 2019 22:03:30 -0000 Noting that there are several points that Jim left to the authors to reply to, also inline... On Tue, Jul 30, 2019 at 10:10:12AM -0700, Jim Schaad wrote: > Comments inline. > > -----Original Message----- > From: Benjamin Kaduk > Sent: Tuesday, July 30, 2019 8:56 AM > To: draft-ietf-ace-cwt-proof-of-possession.all@ietf.org > Cc: ace@ietf.org > Subject: AD review of draft-ietf-ace-cwt-proof-of-possession-06 > > We should be consistent across examples about whether the use of CBOR > diagnostic notation also requires a disclaimer about "with linebreaks for > readability". > > [JLS] I don't believe that this disclaimer needs to be present. Unlike the > JSON document where what is being presented is in fact JSON, what is being > presented here is simply a more user friendly readable version of the binary > data. (A different question would be if the hex should be presented but > that is not what the ACE group is doing in general.) Taking it out is fine by me; I just want us to be internally consistent :) > Section 2 > > Presenter > Party that proves possession of a private key (for asymmetric key > cryptography) or secret key (for symmetric key cryptography) to a > recipient. > > nit: it might be worth either capitalizing Recipient to point to the > following item more clearly, or specifying "recipient of a CWT" for > parallelism with Recipient. > (If we do the former we should capitalize Presenter in the following > definition. But since we don't use the capitalized terms throughout the > text, it wouldn't be my own preference.) > > Section 3.2 > > This example key expired in 2013. While the example will "always" be > expired for an archival document, it might be worth making it more timely > with respect to the publication date. (This holds for basically all time > values in the document's examples.) > > Value 2 for 'kty' should have diagnostic notation /EC2/, not /EC/. > > [I did not check that the example x and y coordinates are in fact points on > P256.] > > The "COSE_Key" member MAY also be used for a COSE_Key representing a > symmetric key, provided that the CWT is encrypted so that the key is > not revealed to unintended parties. The means of encrypting a CWT is > explained in [RFC8392]. If the CWT is not encrypted, the symmetric > key MUST be encrypted as described in Section 3.3. > > It's hard for me to escape the conclusion that this paragraph needs to be a > dedicated section with a bit more discussion about how exactly this usage is > performed and encoded. > > Section 3.3 > > Is the /HMAC256/ the conventional diagnostic notation for alg value 5 > (noting that RFC 8152 calls it both "HMAC256/256" and "HMAC w/ SHA-256")? > > [JLS] HMAC 256/256 is the algorithm name while HMAC w/ SHA-256 is > descriptive. I believe that this is completely consistent in RFC 8152. Er, I'm not sure what you're saying is best to use in the diagnostic notation. > The following example CWT Claims Set of a CWT (using CBOR diagnostic > notation, with linebreaks for readability) illustrates the use of an > encrypted symmetric key as the "Encrypted_COSE_Key" member value: > > { > /iss/ 1 : "coaps://server.example.com", > /sub/ 2 : "24400320", > /aud/ 3: "s6BhdRkqt3", > /exp/ 4 : 1311281970, > /iat/ 5 : 1311280970, > /cnf/ 8 : { > /COSE_Encrypt0/ 2 : [ > > Should this be "/Encrypted_COSE_Key/" and not "/COSE_Enrypt0/"? > > [I did not validate the COSE_Encrypt0 output] > > Section 3.4 > > { > /iss/ 1 : "coaps://server.example.com", > /aud/ 3 : "coaps://client.example.org", > > Is it in any way confusing to use client.example.org as opposed to, say, > resource.example.org as the audience? > > /exp/ 4 : 1361398824, > /cnf/ 8 : { > /kid/ 2 : h'dfd1aa976d8d4575a0fe34b96de2bfad' > > /kid/ in the 'cnf' map has key 3, not 2. > > Note that the use of a Key ID to identify a proof-of-possesion key > needs to be carefully circumscribed, as described below and in > Section 6. Where the Key ID is not a cryptographic value derived > from the key or where all of the parties involved are not validating > the cryptographic derivation, it is possible to get into situations > where the same Key ID is being used for multiple keys. The > > I don't think this quite covers the needed properties, since we also need > some assurance that all parties are interpreting the kid value in the same > way. It may be possible to construct such a scenario via an attacker > replaying a stolen token or even just inadvertent confusion by some party > (quite plausible when we consider scenarios that involve the same key being > described by different 'kid' values in messages with different recipients). > In particular, if the situation arises where an attacker is able to choose > the 'kid' value that will be used, they could deliberately cause a collision > with a legitimate value used by some other party. > > [JLS] I don't agree with that. It should be assumed by all implementations > that there will be collisions between kid values. Except in very specific > cases such as all of the kids being assigned by a group keying server, there > is no way for the assumption of a single kid value being assigned once on a > recipient basis will ever be a true statement. Thanks; that's a good point, and this jogs loose some of the previous discussions we had on the list about key IDs. (Looking back at the quoted text from the document, I wonder if all readers will understand that "cryptographic value derived from the key" needs to include enough bits of cryptographic output to make the chance of brute-force/random collision acceptably small.) It does still seem potentially useful to have agreement among parties as to whether key IDs are arbitrary identifiers or cryptographically derived, though my above discussion about scenarios and consequences is flawed as you note. > In the world of constrained Internet of Things (IoT) devices, there > is frequently a restriction on the size of Key IDs, either because of > table constraints or a desire to keep message sizes small. These > restrictions are going to protocol dependent. For example, DTLS can > > nit: "going to be" or maybe even just "are protocol dependent". > > use a Key ID of any size. However, if the key is being used with > COSE encrypted message, then the length of the key needs to be > minimized and may have a limit as small as one byte. > > nit: is this "length of the key" or "length of the key ID"? > > Note that the value of a Key ID is not always the same for different > parties. When sending a COSE encrypted message with a shared key, > the Key ID may be different on both sides of the conversation, with > the appropriate one being included in the message based on the > recipient of the message. > > While this recipient-dependence is probably unavoidable (as the requisite > namespacing would use more space on the wire than is reasonable for many > applications), it does merit some security considerations text, noting that > such messages are context-dependant and could be misinterpreted if presented > in a different context. > Audience restrictions, as mentioned in Section 4, provide substantial > protection in this regard, but are not necessarily a complete solution. > > [JLS] Again I don't understand this, but I think that your concern goes away > if you do not assume that kid values are going to be unique for an entity. I think you are right about the concern going away. Should we add some text to make it more explicit that all recipients should expect key-ID collisions to occur and be prepared to do the necessary processing/validation to resolve collisions? > o A recipient can decide not to use a CWT based on a created Key ID > if it does not fit the recipient's requirements. > > I'm not sure I understand the semantics being described here. Are we saying > that the issuer might give a presenter a CWT, and by the time the presenter > presents the CWT to the recipient, the recipient says "this is no good" and > denies the transaction in question, forcing the presenter to go back to the > issuer and try again? (How do we know that the issuer would make any > different choices the second time around?) > > o If an issuer is going to use the Key ID confirmation method and is > not going to guarantee that serial number uniqueness is going to > be preserved, the recipient needs to have that information > configured into it so that appropriate actions can be taken. > > nit: this is the only place in the document that talks about "serial > number"s. > Do we say what the "appropriate actions" are somewhere else in the document? > > Section 3.5 > > Note that another means of proving possession of the key when it is a > symmetric key is to encrypt the key to the recipient. The means of > obtaining a key for the recipient is likewise protocol specific. > > While true, there are some subtleties here, namely that the recipient needs > some way of knowing that it is the presenter (as opposed to some other > party) that has actually performed that encryption. In Kerberos we perform > this key confirmation by using the encrypted (session) key for subsequent > protocol exchanges, and if the presenter fails to process those exchanges > then it is clear the presenter does not actually possess the key. This > document does not seem to describe the need for such subsequent confirmation > (or, alternately, the consequences of failing to do so.) > > Section 4 > > A recipient might not understand the "cnf" claim. Applications that > require the proof-of-possession keys communicated with it to be > understood and processed MUST ensure that the parts of this > specification that they use are implemented. > > nit(?): I'm not sure I'm parsing this sentence correctly: is "communicated > with it" referring to "CWTs that include the 'cnf' claim"? > > To avoid replay attacks when the proof-of-possession > tokens are sent to presenters, a security protocol, which uses > mechansims such as nonces or timestamps, has to be utilized. [...] > > I suspect the RFC Editor will want to reword this sentence to avoid the > excessive parentheticals and awkward passive-voice construction. I'll be > bold and suggest a more dramatic rewording to preempt that: "Proof of > possession only provides the intended security gains when the proof is known > to be current and not subject to replay attacks; security protocols using > mechanisms such as nonces and timestamps can be used to avoid this risk of > replay when sending proof-of-possession tokens to [presenters or > recipients]". Note that I am not sure if the original was intended to refer > to the transfer of PoP tokens to presenters (as > written) or recipients (where risk of replay is more traditionally > concerned). > > from changing any elements conveyed within the CWT payload. Special > care has to be applied when carrying symmetric keys inside the CWT > since those not only require integrity protection but also > confidentiality protection. > > Do we want to reiterate the common mechanisms for providing confidentiality > protection here, or just leave the existing text earlier in the document to > cover it? > > Section 5 > > This sort of correlation can occur even for subsequent connections between > the same two parties if observed by a passive observer (e.g., in the case of > a mobile client that changes location). I forget if we have strong enough > guarantees on the use of transport-level encryption that would prevent such > CWTs from being observed in this fashion. > > [JLS] No we don't. Most of the time we are sending CWTs in the clear and > not over a transport-level encrypted channel. I don't propose that we add or suggest remediation measures, but do think we should note the risk. > Section 6 > > ensure correct processing. The recipient needs to be able to use > credentials to verify the authenticity, integrity, and potentially > the confidentiality of the CWT and its content. This requires the > > Just from a rhetorical point of view, can you help me understand how > credentials would be used to verify the confidentiality of a CWT? It seems > like this depends on either (or both of) how the CWT is transmitted or how > it is prepared, and I am not sure how the recipient's credentials come into > play. > > recipient to know information about the issuer. Likewise, there > needs to be agreement between the issuer and the recipient about the > claims being used (which is also true of CWTs in general). > > We briefly discuss the presenter (in the guise of the subject) in the next > paragraph when we talk about key IDs, but are there any other cases where > there needs to be coordination with the presenter? Would distributing a > symmetric PoP key be considered to fall under this mantle? > > When an issuer creates a CWT containing a Key ID claim, it needs to > make sure that it does not issue another CWT containing the same Key > ID with a different content, or for a different subject, within the > lifetime of the CWTs, unless intentionally desired. Failure to do so > may allow one party to impersonate another party, with the potential > to gain additional privileges. Likewise, if PoP keys are used for > > nit: "same Key ID with a different content" doesn't seem quite right, as the > "content" of a Key ID is surely the key-ID value itself. Perhaps "referring > to" would be more appropriate. > I think we should probably give the reader some indication of what semantics > might be attributed to the "intentionally desired" case. It doesn't > necessarily need to be a specific example, but we could say what the > relevant properties/attributes that might lead to such a situation would be. > > multiple different kinds of CWTs in an application and the PoP keys > are identified by Key IDs, care must be taken to keep the keys for > the different kinds of CWTs segregated so that an attacker cannot > cause the wrong PoP key to be used by using a valid Key ID for the > wrong kind of CWT. > > Audience restrictions can come into play here, too, right? In that a > restricted audience of all the CWTs in turn limits the scope of > administration in which this care/segregation needs to be enforced. > > Section 7 > > Criteria that should be applied by the Designated Experts include > determining whether the proposed registration duplicates existing > functionality, determining whether it is likely to be of general > applicability or whether it is useful only for a single application, > and evaluating the security properties of the item being registered > and whether the registration makes sense. > > I know we've been using (variations of) this text for a while, but it seems > to me that it could be more clear than it currently is -- is duplication of > functionality grounds for denial of registration? What about general vs. > specific applicability? The latter seems more clearly applicable for > determining which range from which to allocate, since that has impact on the > encoding size. Can the experts insist on updates to the security > considerations text of a specification prior to granting approval, or are > they limited to denying registration of values with poor security properties > or insufficient documentation thereof? > > Section 7.2.1 > > Change Controller: > For Standards Track RFCs, list the "IESG". For others, give the > name of the responsible party. Other details (e.g., postal > address, email address, home page URI) may also be included. > > In light of the GDPR and similar regulations (and, as is done in RFC 8602), > we may not want to keep all of these, especially postal address, given the > lack of a clear need. > > Specification Document(s): > Reference to the document or documents that specify the parameter, > preferably including URIs that can be used to retrieve copies of > > Is the reference required to be publicly accessible? If not, is it required > that a copy be made available to the experts and IANA? > > [JLS] It is not clear to me that this is an Designated Expert registry. It > is only referred to once in the JWT Confirmation Method Name and that could > refer to the JWT registry and not this one. Section 7 (toplevel) says that all new registries established by this document use Specification Required [RFC8126], which includes review by an expert or experts. > Section 7.2.2 > > o Confirmation Method Name: "Encrypted_COSE_Key" > o Confirmation Method Description: Encrypted COSE_Key > o JWT Confirmation Method Name: "jwe" > o Confirmation Key: 2 > o Confirmation Value Type(s): COSE_Encrypt or COSE_Encrypt0 > structure (with an optional corresponding COSE_Encrypt or > COSE_Encrypt0 tag) > > Do we want to say something about how, in the case when the tag is omitted, > the application protocol specification needs to indicate how to determine > which one is in use? > > [JLS] This is easy as the number of elements in the array is different > between the two. Okay, so you think it's obvious to anyone who goes off and tries to implement it, so we don't need to say anything? > Section 8.2 > > I think [JWT] needs to be normative, as we have a SHOULD-level requirement > for the audience restriction procedures it specifies. > > [JLS] Should this be indirect through the CWT spec rather than via the JWT > spec? Perhaps. (The text in question in this doc is in Section 4, "Applications utilizing proof of possession SHOULD also utilize audience restriction, as described in Section 4.1.3 of [JWT], as it provides additional protections.") I guess JWT itself doesn't even use the phrase "audience restrictions", so perhaps just changing to the CWT ref is enough, here. > I just want to check that it's intentional/desired to mix descriptive > reference tags (e.g., [JWS]) and RFC-number tags (e.g., [RFC7800]) for the > referenced RFCs. > > [JLS] I have no problem with this. I find descriptive reference tags to be > easier to identify than RFC number tags for which I only know couple of > them. Sure. I don't need to impose my personal preference on anyone, here; it would be up to the RFC Editor to enforce a consistent style, if anyone should. -Ben > Acknowledgements, Authors > > The datatracker is currently accepting XML v3 format drafts, and the RFC > Editor's target cutover date for the end of August is quite soon, so feel > free to consider using an XML v3 submission with UTF-8 representations of > names not well represented by the ASCII subset. > From nobody Tue Jul 30 15:49:56 2019 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 5073A1201C9; Tue, 30 Jul 2019 15:49:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 4EPrXPexHcjG; Tue, 30 Jul 2019 15:49:52 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 576361200F5; Tue, 30 Jul 2019 15:49:51 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 30 Jul 2019 15:49:44 -0700 From: Jim Schaad To: 'Benjamin Kaduk' CC: , References: <20190730155605.GM47715@kduck.mit.edu> <010701d546f9$a8281da0$f87858e0$@augustcellars.com> <20190730220316.GT47715@kduck.mit.edu> In-Reply-To: <20190730220316.GT47715@kduck.mit.edu> Date: Tue, 30 Jul 2019 15:49:43 -0700 Message-ID: <015301d54729$15be9360$413bba20$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQGSG8HHJPznl9Uxd4m73YTJRCcQLAFlLak0Ab5iZXGnUPjiMA== X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Ace] AD review of draft-ietf-ace-cwt-proof-of-possession-06 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: Tue, 30 Jul 2019 22:49:54 -0000 I have deleted things I am not replying to. -----Original Message----- From: Benjamin Kaduk Sent: Tuesday, July 30, 2019 3:03 PM To: Jim Schaad Cc: draft-ietf-ace-cwt-proof-of-possession.all@ietf.org; ace@ietf.org Subject: Re: AD review of draft-ietf-ace-cwt-proof-of-possession-06 Noting that there are several points that Jim left to the authors to reply to, also inline... On Tue, Jul 30, 2019 at 10:10:12AM -0700, Jim Schaad wrote: > Comments inline. > > -----Original Message----- > From: Benjamin Kaduk > Sent: Tuesday, July 30, 2019 8:56 AM > To: draft-ietf-ace-cwt-proof-of-possession.all@ietf.org > Cc: ace@ietf.org > Subject: AD review of draft-ietf-ace-cwt-proof-of-possession-06 > > Section 3.3 > > Is the /HMAC256/ the conventional diagnostic notation for alg value 5 > (noting that RFC 8152 calls it both "HMAC256/256" and "HMAC w/ SHA-256")? > > [JLS] HMAC 256/256 is the algorithm name while HMAC w/ SHA-256 is > descriptive. I believe that this is completely consistent in RFC 8152. Er, I'm not sure what you're saying is best to use in the diagnostic notation. [JLS] I would use the algorithm name if it was up to me. That is what I did in the COSE documents. > Section 3.4 > > { > /iss/ 1 : "coaps://server.example.com", > /aud/ 3 : "coaps://client.example.org", > > Is it in any way confusing to use client.example.org as opposed to, > say, resource.example.org as the audience? > > /exp/ 4 : 1361398824, > /cnf/ 8 : { > /kid/ 2 : h'dfd1aa976d8d4575a0fe34b96de2bfad' > > /kid/ in the 'cnf' map has key 3, not 2. > > Note that the use of a Key ID to identify a proof-of-possesion key > needs to be carefully circumscribed, as described below and in > Section 6. Where the Key ID is not a cryptographic value derived > from the key or where all of the parties involved are not validating > the cryptographic derivation, it is possible to get into situations > where the same Key ID is being used for multiple keys. The > > I don't think this quite covers the needed properties, since we also > need some assurance that all parties are interpreting the kid value in > the same way. It may be possible to construct such a scenario via an > attacker replaying a stolen token or even just inadvertent confusion > by some party (quite plausible when we consider scenarios that involve > the same key being described by different 'kid' values in messages with different recipients). > In particular, if the situation arises where an attacker is able to > choose the 'kid' value that will be used, they could deliberately > cause a collision with a legitimate value used by some other party. > > [JLS] I don't agree with that. It should be assumed by all implementations > that there will be collisions between kid values. Except in very > specific cases such as all of the kids being assigned by a group > keying server, there is no way for the assumption of a single kid > value being assigned once on a recipient basis will ever be a true statement. Thanks; that's a good point, and this jogs loose some of the previous discussions we had on the list about key IDs. (Looking back at the quoted text from the document, I wonder if all readers will understand that "cryptographic value derived from the key" needs to include enough bits of cryptographic output to make the chance of brute-force/random collision acceptably small.) It does still seem potentially useful to have agreement among parties as to whether key IDs are arbitrary identifiers or cryptographically derived, though my above discussion about scenarios and consequences is flawed as you note. [JLS] Yes I agree that it could do better about talking about lengths for the purpose of non-collision. I don't think that I care much about the issue of brute-forcing as even if there is a faked kid, the shared secret would still need to be determined which is more difficult. And as below, I don't think this is ever going to be a very big issue for the IoT world as long enough kid values collides with as small as possible messages. > In the world of constrained Internet of Things (IoT) devices, there > is frequently a restriction on the size of Key IDs, either because of > table constraints or a desire to keep message sizes small. These > restrictions are going to protocol dependent. For example, DTLS > can > > Section 5 > > This sort of correlation can occur even for subsequent connections > between the same two parties if observed by a passive observer (e.g., > in the case of a mobile client that changes location). I forget if we > have strong enough guarantees on the use of transport-level encryption > that would prevent such CWTs from being observed in this fashion. > > [JLS] No we don't. Most of the time we are sending CWTs in the clear > and not over a transport-level encrypted channel. I don't propose that we add or suggest remediation measures, but do think we should note the risk. [JLS] reasonable (I guess) > Section 6 > > Section 7.2.1 > > Change Controller: > For Standards Track RFCs, list the "IESG". For others, give the > name of the responsible party. Other details (e.g., postal > address, email address, home page URI) may also be included. > > In light of the GDPR and similar regulations (and, as is done in RFC > 8602), we may not want to keep all of these, especially postal > address, given the lack of a clear need. > > Specification Document(s): > Reference to the document or documents that specify the parameter, > preferably including URIs that can be used to retrieve copies of > > Is the reference required to be publicly accessible? If not, is it > required that a copy be made available to the experts and IANA? > > [JLS] It is not clear to me that this is an Designated Expert > registry. It is only referred to once in the JWT Confirmation Method > Name and that could refer to the JWT registry and not this one. Section 7 (toplevel) says that all new registries established by this document use Specification Required [RFC8126], which includes review by an expert or experts. [JLS] All one of them. I think this can be pulled down close to the actual registry declaration. > Section 7.2.2 > > o Confirmation Method Name: "Encrypted_COSE_Key" > o Confirmation Method Description: Encrypted COSE_Key > o JWT Confirmation Method Name: "jwe" > o Confirmation Key: 2 > o Confirmation Value Type(s): COSE_Encrypt or COSE_Encrypt0 > structure (with an optional corresponding COSE_Encrypt or > COSE_Encrypt0 tag) > > Do we want to say something about how, in the case when the tag is > omitted, the application protocol specification needs to indicate how > to determine which one is in use? > > [JLS] This is easy as the number of elements in the array is different > between the two. Okay, so you think it's obvious to anyone who goes off and tries to implement it, so we don't need to say anything? [JLS] Yes I think so > Section 8.2 > > I think [JWT] needs to be normative, as we have a SHOULD-level > requirement for the audience restriction procedures it specifies. > > [JLS] Should this be indirect through the CWT spec rather than via the > JWT spec? Perhaps. (The text in question in this doc is in Section 4, "Applications utilizing proof of possession SHOULD also utilize audience restriction, as described in Section 4.1.3 of [JWT], as it provides additional protections.") I guess JWT itself doesn't even use the phrase "audience restrictions", so perhaps just changing to the CWT ref is enough, here. [JLS] Yeah, I looked at both and it seemed to me that the text was essentially the same in both documents. Jim *** -Ben