From nobody Mon Jun 5 18:26:43 2017 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 25A5C12EB6C; Mon, 5 Jun 2017 18:26:34 -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.53.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149671239411.3941.12998153965739248286@ietfa.amsl.com> Date: Mon, 05 Jun 2017 18:26:34 -0700 Archived-At: Subject: [Ace] I-D Action: draft-ietf-ace-cbor-web-token-05.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2017 01:26:34 -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 of the IETF. Title : CBOR Web Token (CWT) Authors : Michael B. Jones Erik Wahlstr枚m Samuel Erdtman Hannes Tschofenig Filename : draft-ietf-ace-cbor-web-token-05.txt Pages : 23 Date : 2017-06-05 Abstract: CBOR Web Token (CWT) is a compact means of representing claims to be transferred between two parties. The claims in a CWT are encoded in the Concise Binary Object Representation (CBOR) and CBOR Object Signing and Encryption (COSE) is used for added application layer security protection. A claim is a piece of information asserted about a subject and is represented as a name/value pair consisting of a claim name and a claim value. CWT is derived from JSON Web Token (JWT), but uses CBOR rather than JSON. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ace-cbor-web-token/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ace-cbor-web-token-05 https://datatracker.ietf.org/doc/html/draft-ietf-ace-cbor-web-token-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-cbor-web-token-05 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 Jun 5 18:29:48 2017 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 C21FB12EB79 for ; Mon, 5 Jun 2017 18:29:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 tMLb2E_e3u-D for ; Mon, 5 Jun 2017 18:29:44 -0700 (PDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0096.outbound.protection.outlook.com [104.47.33.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E26D812EB6C for ; Mon, 5 Jun 2017 18:29:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=XBmOWw4lmjl+7ku3eECFUra5Ca1FMIdEIbtcXrrGEpU=; b=KbcWmAnVYf+UX1V+HrwOxk/PUHdA2I6UdlIe20dspsOfAxyeuCECqz9AnFAz9ojH3LK4KvvN+7Cu+OoOx8SZXvggmUUar5GhpkuSgon4kIRr7V0BsPHX2AR0HvRBI2FvJfksHApre4AY6YyJWr8s3Ww0WLTDpfz2q8CpGwqPUwY= Received: from CY4PR21MB0504.namprd21.prod.outlook.com (10.172.122.14) by CY4PR21MB0277.namprd21.prod.outlook.com (10.173.193.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1178.0; Tue, 6 Jun 2017 01:29:41 +0000 Received: from CY4PR21MB0504.namprd21.prod.outlook.com ([10.172.122.14]) by CY4PR21MB0504.namprd21.prod.outlook.com ([10.172.122.14]) with mapi id 15.01.1178.003; Tue, 6 Jun 2017 01:29:41 +0000 From: Mike Jones To: "ace@ietf.org" Thread-Topic: CBOR Web Token (CWT) specification addressing WGLC feedback Thread-Index: AdLeXwZenRzeHWneQmCLtgjFBGGXSA== Date: Tue, 6 Jun 2017 01:29:41 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Ref=https://api.informationprotection.azure.com/api/72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetBy=mbj@microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2017-06-05T18:29:39.7035177-07:00; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic; Sensitivity=General authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:4898:80e8:6::36] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR21MB0277; 7:GVtxD0+1XWpZjuCRB/jOMOufYPevzlUxI4hnN3PdMPrQb0/IE4zEd6YEVV21auGDthtQNpdMSjfYX1vCXXY2kmmNFtBsTkfidHXyVabKeJxLhbYDfJE5EZsKNAlM57e5gCUKG2Uh3FhXISl+BH6c0TNH2rtJWaf+3Ym89vxk1ZoHXDwXWsrodD1WdM1aUBXKfWUlklenc1LTC7189zg+jijIwjlqI8AVlb1pX8E8qgV8aV5kf6XEDBaAhAejAvrOE+eHs+bkXIYNpe0XfrQj7pX6BisVhLyNezZCt2O8ctdr7nja5z2PziwT1ByRD6o4GH4lkTa1Xrr0BYbWvNv+VrJBOAf2r0zwUNkdum1QpH5ltV3JshV+r6bmUz7xsqfnRj/zrjOHWXgskYwd+gMvUfwpDm3FmAaTtuR1R2sBeRhhyQ6vMDiyZTMx+T9yV80MWEs85NWyV6VnmbFDeP/NeEk4rhjsbPa+4a7C2TdpVyxTuPhC2rZ5CcMfzwaE0X7qPjqgL6edMD5ceAvMxSU8sY/N7UyzZSMS3xtrUpQq3Tlg5IL2JiqTVe3f1Bb0m53dGyLFk3M0KvuI/jp5zb8p+bpipuj/FQBmxSezBX5AjyCgH5P9A0j6PZpvkAF8iZMLUb6smCD3IXmFveVFaCt/Ru5eVdtRarls47XHG8q9CJBxswSlt9B9RpzVWNb/95xsPV2Qcz4841QsKhJejpPzTQ4ovah14+7VRe1EqXVDmD9BjxoqKpqAlewNBl9iWUyNWuUMj4zsgBg5r2gYzn5xdnozp+7p1e/+LpStvb+rlYcM770k8n94nTPEMKSCJ7dD x-ms-office365-filtering-correlation-id: 017b801d-b8ce-48ec-91d5-08d4ac7b812d x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:CY4PR21MB0277; x-ms-traffictypediagnostic: CY4PR21MB0277: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(31418570063057)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(601004)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(10201501046)(93006095)(93001095)(3002001)(6055026)(61426038)(61427038)(6041248)(20161123560025)(20161123555025)(20161123564025)(20161123558100)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR21MB0277; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR21MB0277; x-forefront-prvs: 033054F29A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39850400002)(39400400002)(39450400003)(39840400002)(39410400002)(39860400002)(209900001)(5640700003)(14454004)(50986999)(2906002)(5660300001)(966005)(54356999)(25786009)(10090500001)(2351001)(189998001)(8990500004)(86612001)(86362001)(5005710100001)(8676002)(81166006)(1730700003)(102836003)(6116002)(790700001)(122556002)(8936002)(7736002)(6506006)(606005)(54896002)(6436002)(6306002)(9686003)(2501003)(236005)(7696004)(99286003)(55016002)(33656002)(7906003)(5630700001)(77096006)(74316002)(53376002)(38730400002)(110136004)(2900100001)(478600001)(10290500003)(3660700001)(3280700002)(6916009)(53936002)(72206003)(6606295002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0277; H:CY4PR21MB0504.namprd21.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR21MB0504F48BAB4AEBD6F7FF7EEDF5CB0CY4PR21MB0504namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Jun 2017 01:29:41.3674 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0277 Archived-At: Subject: [Ace] CBOR Web Token (CWT) specification addressing WGLC feedback X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 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, 06 Jun 2017 01:29:47 -0000 --_000_CY4PR21MB0504F48BAB4AEBD6F7FF7EEDF5CB0CY4PR21MB0504namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable A new CBOR Web Token (CWT) draft has been published that addresses the Work= ing Group Last Call (WGLC) feedback received. Changes were: * Say that CWT is derived from JWT, rather than CWT is a profile of= JWT. * Used CBOR type names in descriptions, rather than major/minor typ= e numbers. * Clarified the NumericDate and StringOrURI descriptions. * Changed to allow CWT claim names to use values of any legal CBOR = map key type. * Changed to use the CWT tag to identify nested CWTs instead of the= CWT content type. * Added an example using a floating-point date value. * Acknowledged reviewers. Thanks to Samuel Erdtman for doing the majority of the editing for this dra= ft. As always, people are highly encouraged to validate the examples. The specification is available at: * https://tools.ietf.org/html/draft-ietf-ace-cbor-web-token-05 An HTML-formatted version is also available at: * http://self-issued.info/docs/draft-ietf-ace-cbor-web-token-05.htm= l -- Mike P.S. This notice was also posted at http://self-issued.info/?p=3D1695 and = as @selfissued. --_000_CY4PR21MB0504F48BAB4AEBD6F7FF7EEDF5CB0CY4PR21MB0504namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

A new CBOR Web Token (CWT) draft has been published = that addresses the Working Group Last Call (WGLC) feedback received.  = Changes were:

·         Say that CWT is derived from JWT, rather tha= n CWT is a profile of JWT.

·         Used CBOR type names in descriptions, rather= than major/minor type numbers.

·         Clarified the NumericDate and StringOrURI de= scriptions.

·         Changed to allow CWT claim names to use valu= es of any legal CBOR map key type.

·         Changed to use the CWT tag to identify neste= d CWTs instead of the CWT content type.

·         Added an example using a floating-point date= value.

·         Acknowledged reviewers.

 

Thanks to Samuel Erdtman for doing the majority of t= he editing for this draft.  As always, people are highly encouraged to= validate the examples.

 

The specification is available at:

 

An HTML-formatted version is also available at:=

·      &n= bsp;  http://self-issued.info/docs/draft-ietf-ace-cbor-web-token-05.ht= ml

 

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;        -- Mike

 

P.S.  This notice was also posted at http://self-issued.info/?p=3D1695 and as @selfissued.

 

--_000_CY4PR21MB0504F48BAB4AEBD6F7FF7EEDF5CB0CY4PR21MB0504namp_-- From nobody Tue Jun 6 02:57:35 2017 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 8436A129C11 for ; Tue, 6 Jun 2017 02:57:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=alibaba-inc.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 yFu1LgJ2b7SW for ; Tue, 6 Jun 2017 02:57:31 -0700 (PDT) Received: from out0-195.mail.aliyun.com (out0-195.mail.aliyun.com [140.205.0.195]) by ietfa.amsl.com (Postfix) with ESMTP id 50073129C0C for ; Tue, 6 Jun 2017 02:57:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1496743047; h=Date:Subject:From:To:Message-ID:Mime-version:Content-type; bh=2WNiyA0ZhkL6aDv7frlYWj8DTTVOn5Hq4yr5iFGXmwc=; b=fRPCs8rCiiRbrhZF2xLZsxFGIgZaiJXnePZVwprOrorEUCTIZWl23C4iVw1d4uJquJFUl7f5DDIA96FWpF45pH0lvpKEclXw1HFaohTSAvD2Hnw78HrLvri3f34xz1MGTgKzjeajJuEPv4Nfqa/MGRr0OjLC3oawsk1titmhbPQ= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R211e4; FP=0|-1|-1|-1|0|-1|-1|-1; HT=e02c03269; MF=kepeng.lkp@alibaba-inc.com; NM=1; PH=DS; RN=4; SR=0; TI=SMTPD_---.8AdkG0P_1496743037; Received: from 30.27.109.248(mailfrom:kepeng.lkp@alibaba-inc.com ip:106.11.34.15) by smtp.aliyun-inc.com(127.0.0.1); Tue, 06 Jun 2017 17:57:20 +0800 User-Agent: Microsoft-MacOutlook/14.6.8.160830 Date: Tue, 06 Jun 2017 17:57:16 +0800 From: "Kepeng Li" To: "Kepeng Li" , CC: Kathleen Moriarty , "Hannes.Tschofenig@gmx.net" Message-ID: Thread-Topic: [Ace] Call for adoption for draft-gerdes-ace-dtls-authorize Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3579616640_6611410" Archived-At: Subject: Re: [Ace] Call for adoption for draft-gerdes-ace-dtls-authorize X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 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, 06 Jun 2017 09:57:33 -0000 > 此邮件使用 MIME 格式。由于邮件阅读程序不能识别 此格式，因此，可能无法识别该邮件的分部或部分内容。 --B_3579616640_6611410 Content-type: text/plain; charset="GB2312" Content-transfer-encoding: quoted-printable Hi all, Based on the feedback we received in the Chacago F2F meeting and the mailin= g list, it is concluded that we got enough supports to adopt this document,. Authors: Please resubmit the draft as draft-ietf-ace-dtls-authorize-00. Thanks, Kind Regards Kepeng & Hannes =B7=A2=BC=FE=C8=CB: Ace on behalf of Li Kepeng =C8=D5=C6=DA: Thursday, 11 May 2017 at 3:24 PM =D6=C1: =B3=AD=CB=CD: Kathleen Moriarty , "Hannes.Tschofenig@gmx.net" =D6=F7=CC=E2: [Ace] Call for adoption for draft-gerdes-ace-dtls-authorize Hello all, =20 This note begins a Call For Adoption for draft-gerdes-ace-dtls-authorize [1= ] to be adopted as an ACE working group item. The call ends on 26th May, 2017= . =20 Keep in mind that adoption of a document does not mean the document as-is i= s ready for publication. It is merely acceptance of the document as a startin= g point for what will be the final product of the ACE working group. The working group is free to make changes to the document according to the normal consensus process. =20 Please reply on this thread with expressions of support or opposition, preferably with comments, regarding accepting this as a work item. =20 Thanks =20 Kind Regards Kepeng and Hannes (ACE co-chairs) =20 [1] https://datatracker.ietf.org/doc/draft-gerdes-ace-dtls-authorize/ --B_3579616640_6611410 Content-type: text/html; charset="GB2312" Content-transfer-encoding: quoted-printable
Hi all,

Based on the feedback we rece= ived in the Chacago F2F meeting and the mailing list, it is concluded that w= e got enough supports to adopt this document,.

Au= thors: Please resubmit the draft as draft-ietf-ace-dtls-authorize-00.
<= /div>

Thanks,
Kind Regards
Kepeng= & Hannes

=B7=A2=BC=FE=C8=CB: Ace <ace-bounces@ietf.org>= on behalf of Li Kepeng <kepe= ng.lkp@alibaba-inc.com>
=C8=D5=C6=DA: Thursday, 11 May 2017 at 3:24 PM
=D6=C1: <Ace@ietf.org>
=B3=AD=CB=CD: Kathleen Moriarty <Kathleen.Moriarty.ietf@gmail.com>, "Hannes.Tschofenig@gmx.net" <Hannes.Tschofenig@gmx.net>=D6=F7=CC=E2: [Ace] Call for adoption for = draft-gerdes-ace-dtls-authorize

Hello all,
 
This note begins a Call For Adoption for draft-gerdes-ace-dtls-auth=
orize [1] to be ado=
pted as an ACE working group item. The call ends on 26th May, 2017.

 

= 
Keep in m=
ind that adoption of a document does not mean the document as-is is ready fo=
r publication. It is merely acceptance of the document as a starting point f=
or what will be the final product of the ACE working group. The working grou=
p is free to make changes to the document according to the normal consensus =
process.
&nb=
sp;
Please reply on this thread with expressions of support or oppositio=
n, preferably with comments, regarding accepting this as a work item.=

 

Thanks
 
Kind Regards
Kepeng a=
nd Hannes (ACE co-chairs)

 



--B_3579616640_6611410-- From paul.fremantle@port.ac.uk Thu Jun 8 03:14:38 2017 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 BC00312E76A for ; Thu, 8 Jun 2017 03:14:38 -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, 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=port.ac.uk 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 i3Xw5ixPyBSY for ; Thu, 8 Jun 2017 03:14:35 -0700 (PDT) Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::22f]) (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 B30F112E6D7 for ; Thu, 8 Jun 2017 03:14:34 -0700 (PDT) Received: by mail-qt0-x22f.google.com with SMTP id u19so35571509qta.3 for ; Thu, 08 Jun 2017 03:14:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=port.ac.uk; s=google-20130730; h=mime-version:from:date:message-id:subject:to; bh=tIjHH/KTGCG56vAAwVeF2hBOpTTrSrrwkNeDmC0H3lc=; b=f7Qnj6Z8bgD1mOISWrGWAbLhmlIlTTojIjXnNrgoCdtXzXi7IcI43jocNUqSzQ14tW NPibj5w/tf5A8xYn400mzOb7Ju6ct+NDtIKhgfwIr6ApoSEnTyZ7MzSU5y6zXd/hBGF8 pkqg1mcAkNXlm+NI5ld7qAxljS0td5H72305w= 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=tIjHH/KTGCG56vAAwVeF2hBOpTTrSrrwkNeDmC0H3lc=; b=RIyKzuLstkU4jFbyc+9XbZz7O/J0L2g9gg7fEOHsWDN7xs+X/WW/6L8ICTvyZFC88h bVCLa3FUMl6q+QHHtjTkJQS1QzhkCKTsFjEtL2udfX4bX4xuAqv1+SkrFtMFUOItsU2p lfZAlGYPh9Wc/Dj3IR2u6IQ4bK+98Ae5nov4eRLfiWn6Mc/BjXDJ8hXdKc4a5OA4PGj8 fz5bAuGKlfw3nke0uWVZcF3RCSAcAQqeNvhLT6c8b/Blm2SvFTEXYScccEaTfmahzKXV tryyCN+ABhuQ0ciLesuTeMQp9Ol8cvFraQWMp4O5qpWYRhRw8gPJcpk1f6IrhG3Xzy3k X0+g== X-Gm-Message-State: AKS2vOxJciBPmvazXnBXtx3iY0Y78o8wBUZIk3paPYElRGxMyiBRGmVf tG56Rbi/sa7LF0PQWqLnXlLm/w8Y9gEzaF4= X-Received: by 10.55.179.1 with SMTP id c1mr24083585qkf.80.1496916873606; Thu, 08 Jun 2017 03:14:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.53.68 with HTTP; Thu, 8 Jun 2017 03:14:13 -0700 (PDT) From: Paul Fremantle Date: Thu, 8 Jun 2017 11:14:13 +0100 Message-ID: To: ace@ietf.org Content-Type: multipart/alternative; boundary="94eb2c0657548299000551701ed1" Archived-At: Subject: [Ace] Comments on draft-sengul-ace-mqtt-tls-profile-00 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 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, 08 Jun 2017 12:09:25 -0000 --94eb2c0657548299000551701ed1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi I would like to make some comments on the draft draft-sengul-ace-mqtt-tls-profile-00. Since this is my first post to the group, let me briefly introduce myself. I have previously sat on the MQTT TC at OASIS and I also have participated in the W3C and OASIS before. I haven't yet done anything at the IETF, so I realise that I have to learn a different approach, which I'm looking forward to. I also am the lead author on one a paper that is cited by the draft [1]. Since then I have extended the flows around MQTT and OAuth2 to include use of the Authorization Code flow and Refresh Flow, which are documented in [2] and also available in an open source repository in Github [3]. My approach so far has used Bearer tokens, not PoP tokens, so the cited work is not directly applicable to the proposal, but I believe may have some useful input. There is also another paper on the subject at [5]. 1) I think this proposal is really useful and welcome. 2) I'd like to make an overall comment regarding the MQTT specification. The current standard (v3.1.1) is widely adopted and used, and will likely remain so for a while still. However, there are issues in using it with OAuth2, especially around request-response flows. These issues seem to be resolved in the proposed working draft [4] for MQTT 5.0 (the replacement version). Therefore it would seem like a good idea for this proposed mapping of ACE to MQTT to look at the current 3.1.1 and proposed 5.0 versions as two different approaches, where it might be positive to postpone certain aspects into the 5.0 approach that are hard to deal with in 3.1.1. I will call these out below. 3) I'd be interested to know why the specification calls out the Will message handling, as it seems that it proposes the normal MQTT behaviour. Maybe I misunderstood? 4) The proposal to allow clients to include the token in the payload of publish messages (2.2.1) seems to me to be challenging. The problem is that MQTT 3.1.1 has no way of adding headers to the message, so I can understand that this is a way around this. However, I feel that this mixes up the layering of the protocol. This is one area where MQTT 5.0 will solve a problem (with MQTT Properties, and the ability to reauthenticate), so I would suggest considering that this be removed and dealt with in a MQTT 5.0 specific way. 5) There is some description of how the server should acknowledge messages in 2.2.1. Again, as in point 3, if there is no change to the default behaviour of MQTT then it maybe better not to call it out in this specification. 6) In 2.2.2, the specification calls out the behaviour of the broker onbound, once a publish message is received. This seems to imply that all the publishers and subscribers to a broker are using ACE. Is that an assumption of this spec or can it support both ACE and non-ACE systems. For example, an ACE-based publisher and a subscriber that uses a traditional MQTT authorisation scheme? Since the authorisation of subscribers using ACE is covered in 2.3, maybe it is not necessary to have 2.2.2 at all 7) The approach proposed in Appendix B seems to enable DoS attacks against the broker. It is not clear to me on reading this what the benefits are, but that is probably my lack of knowledge of the ACE approach. Can someone please help me understand the purpose of this flow. 8) Appendix C seems to be trying to deal with the situation where a client's token has expired but it may carry on working with reduced permissions and this will be signalled with a special message to a system topic. This seems overly complex to put in the specification. Again, this will be resolved with MQTT 5.0 where the broker will be able to request the client to re-authenticate without dropping the connection, and also will be able to drop the connection more gracefully. Looking at this from a client device development perspective, it seems that there are two options: a) Build a client that can cope with listening for "downgrade" messages and that can cope with downgraded permissions when tokens expire b) Build a client that can cope with abrupt disconnections, and can deal with expired tokens. Since clients already have to have logic to handle (b) anyway, the value of (a) seems less. 9) I hope this hasn't come across as overly negative. There is a lot I like about this specification but I felt that a detailed set of comments would be useful to the authors. Also I may well have misunderstood aspects of this spec! 10) I'd be very interested in adding support for flows that are currently out of band in this spec. At the moment, as I understand it, a device would need to support HTTPS or another protocol to interact with the AS. In [2] I have mapped the token flows, refresh flows etc into MQTT and it might be useful to standardise these. Let me know if that is of interest. Thanks Paul [1] Fremantle, Paul, et al. "Federated identity and access management for the internet of things." *Secure Internet of Things (SIoT), 2014 International Workshop on*. IEEE, 2014. [2] Fremantle, Paul, and Benjamin Aziz. "OAuthing: privacy-enhancing federation for the Internet of Things." (2016). [3] https://github.com/pzfreo/oauthing [4] MQTT v5.0 Working Draft 13: https://www.oasis-open.org/committees/download.php/60716/mqtt-v5.0-wd13.pdf [5] Fremantle, Paul, Jacek Kopeck=C3=BD, and Benjamin Aziz. "Web api manage= ment meets the internet of things." *European Semantic Web Conference*. Springer International Publishing, 2015. --=20 Paul Fremantle Doctoral Researcher, University of Portsmouth, School of Computing Visiting Scientist, Institute of the Architecture of Application Systems, Stuttgart Visiting Lecturer, Software Engineering Programme, Oxford University Co-Founder, WSO2 Apache Member and Committer email: paul.fremantle@port.ac.uk, paul@fremantle.org twitter: pzfreo / skype: paulfremantle / blog: http://pzf.fremantle.org --94eb2c0657548299000551701ed1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi

I would like to make some comments o= n the draft=C2=A0draft-sengul-ace-mqtt-tls-profile-00.=C2=A0

=
Since this is my first post to the group, let me briefly introdu= ce myself. I have previously sat on the MQTT TC at OASIS and I also have pa= rticipated in the W3C and OASIS before. I haven't yet done anything at = the IETF, so I realise that I have to learn a different approach, which I&#= 39;m looking forward to.

I also am the lead author= on one a paper that is cited by the draft [1]. Since then I have extended = the flows around MQTT and OAuth2 to include use of the Authorization Code f= low and Refresh Flow, which are documented in [2] and also available in an = open source repository in Github [3]. My approach so far has used Bearer to= kens, not PoP tokens, so the cited work is not directly applicable to the p= roposal, but I believe may have some useful input. There is also another pa= per on the subject at [5].

1) I think this proposa= l is really useful and welcome.=C2=A0

2) I'd l= ike to make an overall comment regarding the MQTT specification. The curren= t standard (v3.1.1) is widely adopted and used, and will likely remain so f= or a while still. However, there are issues in using it with OAuth2, especi= ally around request-response flows. These issues seem to be resolved in the= proposed working draft [4] for MQTT 5.0 (the replacement version). Therefo= re it would seem like a good idea for this proposed mapping of ACE to MQTT = to look at the current 3.1.1 and proposed 5.0 versions as two different app= roaches, where it might be positive to postpone certain aspects into the 5.= 0 approach that are hard to deal with in 3.1.1. I will call these out below= .

3) I'd be interested to know why the specifi= cation calls out the Will message handling, as it seems that it proposes th= e normal MQTT behaviour. Maybe I misunderstood?

4)= The proposal to allow clients to include the token in the payload of publi= sh messages (2.2.1) seems to me to be challenging. The problem is that MQTT= 3.1.1 has no way of adding headers to the message, so I can understand tha= t this is a way around this. However, I feel that this mixes up the layerin= g of the protocol. This is one area where MQTT 5.0 will solve a problem (wi= th MQTT Properties, and the ability to reauthenticate), so I would suggest = considering that this be removed and dealt with in a MQTT 5.0 specific way.=

5) There is some description of how the server sh= ould acknowledge messages in 2.2.1. Again, as in point 3, if there is no ch= ange to the default behaviour of MQTT then it maybe better not to call it o= ut in this specification.

6) In 2.2.2, the specifi= cation calls out the behaviour of the broker onbound, once a publish messag= e is received. This seems to imply that all the publishers and subscribers = to a broker are using ACE. Is that an assumption of this spec or can it sup= port both ACE and non-ACE systems. For example, an ACE-based publisher and = a subscriber that uses a traditional MQTT authorisation scheme? Since the a= uthorisation of subscribers using ACE is covered in 2.3, maybe it is not ne= cessary to have 2.2.2 at all=C2=A0

7) The approach= proposed in =C2=A0Appendix B seems to enable DoS attacks against the broke= r. It is not clear to me on reading this what the benefits are, but that is= probably my lack of knowledge of the ACE approach. Can someone please help= me understand the purpose of this flow.

8) Append= ix C seems to be trying to deal with the situation where a client's tok= en has expired but it may carry on working with reduced permissions and thi= s will be signalled with a special message to a system topic. This seems ov= erly complex to put in the specification. Again, this will be resolved with= MQTT 5.0 where the broker will be able to request the client to re-authent= icate without dropping the connection, and also will be able to drop the co= nnection more gracefully. Looking at this from a client device development = perspective, it seems that there are two options:
a) Build a clie= nt that can cope with listening for "downgrade" messages and that= can cope with downgraded permissions when tokens expire
b) Build= a client that can cope with abrupt disconnections, and can deal with expir= ed tokens.
Since clients already have to have logic to handle (b)= anyway, the value of (a) seems less.=C2=A0

9) I h= ope this hasn't come across as overly negative. There is a lot I like a= bout this specification but I felt that a detailed set of comments would be= useful to the authors. Also I may well have misunderstood aspects of this = spec!

10) I'd be very interested in adding sup= port for flows that are currently out of band in this spec. At the moment, = as I understand it, a device would need to support HTTPS or another protoco= l to interact with the AS. In [2] I have mapped the token flows, refresh fl= ows etc into MQTT and it might be useful to standardise these. Let me know = if that is of interest.

Thanks
Paul

[1]=C2=A0Fremantle, Paul, et al. "Federated identity and access = management for the internet of things."=C2=A0Secure Internet of Things (SIoT), 20= 14 International Workshop on. IEEE, 2014.

[2]=C2=A0Fremantle, Paul, and Benjamin Aziz= . "OAuthing: privacy-enhancing federation for the Internet of Things.&= quot; (2016).


=

[5]=C2=A0Fremantle, Paul, Jacek Kop= eck=C3=BD, and Benjamin Aziz. "Web api management meets the internet o= f things."=C2=A0European Semantic Web Conference. Springer International Publishing, 2015.


--
Paul Frema= ntle
Doctoral Researcher, University of Portsmouth, School of Computing=
Visiting Scientist,=C2=A0Institute of the Architecture of Applic= ation Systems, Stuttgart
Visiting Lecturer, Software Engineering = Programme, Oxford University
Co-= Founder, WSO2
Apache Member and Committer
<= /div>
twitter: pzfreo / skype: = paulfremantle / blog: http://pzf.fremantle.org
--94eb2c0657548299000551701ed1-- From nobody Thu Jun 8 05:43:51 2017 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 7CE9812EAB2 for ; Thu, 8 Jun 2017 05:43:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.401 X-Spam-Level: X-Spam-Status: No, score=-5.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, 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 uaD0PB7H0Rf7 for ; Thu, 8 Jun 2017 05:43:47 -0700 (PDT) Received: from se-out2.mx-wecloud.net (se-out2.mx-wecloud.net [89.221.255.177]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D25012EAB1 for ; Thu, 8 Jun 2017 05:43:46 -0700 (PDT) Received: from sp-mail-2.sp.se (unknown [194.218.146.197]) by se-out2.mx-wecloud.net (Postfix) with ESMTPS id 681A2222542 for ; Thu, 8 Jun 2017 12:43:43 +0000 (UTC) Received: from [192.168.0.166] (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_256_CBC_SHA384_P384) id 15.1.669.32; Thu, 8 Jun 2017 14:43:44 +0200 To: References: From: Ludwig Seitz Message-ID: <740f63dd-2ea7-ec1b-ac7a-725fcd703fa5@ri.se> Date: Thu, 8 Jun 2017 14:43:38 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.116.0.226] X-ClientProxiedBy: sp-mail-1.sp.se (10.100.0.161) To sp-mail-2.sp.se (10.100.0.162) X-CMAE-Score: 0 X-CMAE-Analysis: v=2.2 cv=Nc2W7yL4 c=1 sm=1 tr=0 a=L5DDne6A+dD0FbDkt2Fblw==:117 a=L5DDne6A+dD0FbDkt2Fblw==:17 a=sZ8rJzgPlrQA:10 a=IkcTkHD0fZMA:10 a=LWSFodeU3zMA:10 a=g0UXVq6QYMBOwDO39OUA:9 a=iBk5iD2MpXr8SjMv:21 a=vDRXrfbxAAUgMswk:21 a=QEXdDO2ut3YA:10 X-Virus-Scanned: clamav-milter 0.99.2 at MailSecurity X-Virus-Status: Clean X-MailSecurity-Status: 0 X-Scanned-By: WeCloud MailSecurity X-MailSecurity-Score: 0 Archived-At: Subject: Re: [Ace] Comments on draft-sengul-ace-mqtt-tls-profile-00 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 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, 08 Jun 2017 12:43:49 -0000 Hello Paul, although I'm not one of the authors of this draft, I feel I can help with the two questions concerning appendices B and C. Please find my comments inline. Feel free to ask for further clarifications. /Ludwig On 2017-06-08 12:14, Paul Fremantle wrote: > Hi > > I would like to make some comments on the > draft draft-sengul-ace-mqtt-tls-profile-00. > ... > 7) The approach proposed in Appendix B seems to enable DoS attacks > against the broker. It is not clear to me on reading this what the > benefits are, but that is probably my lack of knowledge of the ACE > approach. Can someone please help me understand the purpose of this flow. As you described in 4), sending the token in the payload of MQTT messages is challenging. Therefore Appendix B describes a way to submit tokens to the broker previous to requests (both publish and subscribe). Obviously you can overload the broker with fake access tokens using the authz-info topic, but since all clients (both publishers and subscribers) will be unauthorized before they first transmit their access token (in whatever way they do that), the broker has to make a leap of faith to accept data that might potentially be an access token in some way. I don't see this way as being more dangerous than any other method of initially providing an access token to the broker. This flow is analogous to what the ACE framework defines, i.e. an unprotected REST resource "authz-info" to which client can POST their access tokens. > 8) Appendix C seems to be trying to deal with the situation where a > client's token has expired but it may carry on working with reduced > permissions and this will be signalled with a special message to a > system topic. I think there is a slight misunderstanding in the second part of that sentence. Appendix C deals with the situation where a client's token has either expired or otherwise become invalid and the broker whishes to inform the client of this situation. I was told that there is currently no message defined in MQTT for signaling a broker side disconnect to the client. This was created as a workaround to that problem. Furthermore the proposal in Appendix C deals with cases where a client has a successful connection and a valid token, but whishes to submit an additional token granting further access rights. -- Ludwig Seitz, PhD Security Lab, RISE SICS Phone +46(0)70-349 92 51 From nobody Thu Jun 8 05:49:00 2017 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 A3D0E12EAB6 for ; Thu, 8 Jun 2017 05:48:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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_PASS=-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 6OIw_cfCMKJx for ; Thu, 8 Jun 2017 05:48:57 -0700 (PDT) Received: from mail-ot0-x230.google.com (mail-ot0-x230.google.com [IPv6:2607:f8b0:4003:c0f::230]) (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 43542129432 for ; Thu, 8 Jun 2017 05:48:57 -0700 (PDT) Received: by mail-ot0-x230.google.com with SMTP id t31so22671633ota.1 for ; Thu, 08 Jun 2017 05:48:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=tJziGPLzRfqUHxJmQKpCgDpd91cQDQdRzmx32NUsGgs=; b=UsoZlO42OmXQbu1cbtsk/K++r0RAVEAUBz4o4UNs7H2Mo4uPCJstl3LXpIvLlJ8B/8 B9O5Eu8t6JrL0rIjJ2kT9CLS5DeB2UUz6/exjFj3lzwIztAmRArd4Q+HNk11OqbUsWT6 0ZbaGn7aj6Ejf1hfkWgaDDkA1XQdxk6DAmaVifJTpXdgW73NuXYioSBi0uCuAYYIS3LG HW7A7XWGSVu0A1AkhxqymGdxLdcLGRhPtpZPYHz9anvBs1d4K6ir21xNWfwWsQQJKEoj udTDTY+MFZtAKVY8t0r3tihd5oQny06qi3NJHWG2+2HU05L6NOC1SeBdT40zD74RK9qs +5yA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=tJziGPLzRfqUHxJmQKpCgDpd91cQDQdRzmx32NUsGgs=; b=hMyd5ucq4HjvoU4Zm0+tuwYrBlJjwVEy1/BbPJUoKLK8TDO6gFQXAgpOMEzdsVk5sT YWf9tQFGOZgd2ru84XBidDl6ARDIyLQ0jQyYv0CAqvAg291rJ8h6EaZNe8Mt/H29YyGZ vdU2nGj3HS3IQ0ebFSh37pSmabHlb0DNBg0SVkVNV1TeNEf+5s2C+i7ufcNbysBNrm62 2XBG7VAEPE7dA04g/0Ugxuw/IOqoGTDbFCPffsVgu/Kf8z9/by1rkoOS+IbUTwkPM3m2 pZLcOsx6kfCteoM9WGrp8a6JOye7J9/xyj92oHLMjUcNHw77xE3pXan58MFh5YsyeWQk 27lA== X-Gm-Message-State: AODbwcDoxxHOFVUvn7+IwKvjmWG47RXrLTBgZnjQOt86Hr/ST4kQNMAe PVbrJF1ABA/vuy9iNMFABGnkaEaKZg== X-Received: by 10.157.36.34 with SMTP id p31mr17431332ota.12.1496926136499; Thu, 08 Jun 2017 05:48:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.65.6 with HTTP; Thu, 8 Jun 2017 05:48:56 -0700 (PDT) In-Reply-To: <740f63dd-2ea7-ec1b-ac7a-725fcd703fa5@ri.se> References: <740f63dd-2ea7-ec1b-ac7a-725fcd703fa5@ri.se> From: Cigdem Sengul Date: Thu, 8 Jun 2017 13:48:56 +0100 Message-ID: To: Ludwig Seitz Cc: "ace@ietf.org" Content-Type: multipart/alternative; boundary="001a113cfa369f168b055172464a" Archived-At: Subject: Re: [Ace] Comments on draft-sengul-ace-mqtt-tls-profile-00 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 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, 08 Jun 2017 12:48:59 -0000 --001a113cfa369f168b055172464a Content-Type: text/plain; charset="UTF-8" Thanks Paul, I will be responding to your comments soon (away from my desk at rsac unplugged today :) ) And thanks Ludwig, for offering clarifications. Later, --Cigdem On Thursday, June 8, 2017, Ludwig Seitz wrote: > Hello Paul, > > although I'm not one of the authors of this draft, I feel I can help with > the two questions concerning appendices B and C. Please find my comments > inline. Feel free to ask for further clarifications. > > /Ludwig > > On 2017-06-08 12:14, Paul Fremantle wrote: > >> Hi >> >> I would like to make some comments on the draft >> draft-sengul-ace-mqtt-tls-profile-00. >> >> ... > >> 7) The approach proposed in Appendix B seems to enable DoS attacks >> against the broker. It is not clear to me on reading this what the benefits >> are, but that is probably my lack of knowledge of the ACE approach. Can >> someone please help me understand the purpose of this flow. >> > As you described in 4), sending the token in the payload of MQTT messages > is challenging. Therefore Appendix B describes a way to submit tokens to > the broker previous to requests (both publish and subscribe). > > Obviously you can overload the broker with fake access tokens using the > authz-info topic, but since all clients (both publishers and subscribers) > will be unauthorized before they first transmit their access token (in > whatever way they do that), the broker has to make a leap of faith to > accept data that might potentially be an access token in some way. I don't > see this way as being more dangerous than any other method of initially > providing an access token to the broker. > > This flow is analogous to what the ACE framework defines, i.e. an > unprotected REST resource "authz-info" to which client can POST their > access tokens. > > > 8) Appendix C seems to be trying to deal with the situation where a >> client's token has expired but it may carry on working with reduced >> permissions and this will be signalled with a special message to a system >> topic. >> > > I think there is a slight misunderstanding in the second part of that > sentence. Appendix C deals with the situation where a client's token has > either expired or otherwise become invalid and the broker whishes to inform > the client of this situation. I was told that there is currently no message > defined in MQTT for signaling a broker side disconnect to the client. This > was created as a workaround to that problem. > Furthermore the proposal in Appendix C deals with cases where a client has > a successful connection and a valid token, but whishes to submit an > additional token granting further access rights. > > > -- > Ludwig Seitz, PhD > Security Lab, RISE SICS > Phone +46(0)70-349 92 51 > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > --001a113cfa369f168b055172464a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks Paul, I will be responding to your comments soon (away from my desk = at rsac unplugged today :) )

And thanks Ludwig, for offe= ring clarifications.
Later,
--Cigdem

On Thursday= , June 8, 2017, Ludwig Seitz <ludw= ig.seitz@ri.se> wrote:
Hello Paul,=

although I'm not one of the authors of this draft, I feel I can help wi= th the two questions concerning appendices B and C. Please find my comments= inline. Feel free to ask for further clarifications.

/Ludwig

On 2017-06-08 12:14, Paul Fremantle wrote:
Hi

I would like to make some comments on the draft draft-sengul-ace-mqtt-tls-p= rofile-00.

...
7) The approach proposed in=C2=A0 Appendix B seems to enable DoS attacks ag= ainst the broker. It is not clear to me on reading this what the benefits a= re, but that is probably my lack of knowledge of the ACE approach. Can some= one please help me understand the purpose of this flow.
As you described in 4), sending the token in the payload of MQTT messages i= s challenging. Therefore Appendix B describes a way to submit tokens to the= broker previous to requests (both publish and subscribe).

Obviously you can overload the broker with fake access tokens using the aut= hz-info topic, but since all clients (both publishers and subscribers) will= be unauthorized before they first transmit their access token (in whatever= way they do that), the broker has to make a leap of faith to accept data t= hat might potentially be an access token in some way. I don't see this = way as being more dangerous than any other method of initially providing an= access token to the broker.

This flow is analogous to what the ACE framework defines, i.e. an unprotect= ed REST resource "authz-info" to which client can POST their acce= ss tokens.


8) Appendix C seems to be trying to deal with the situation where a client&= #39;s token has expired but it may carry on working with reduced permission= s and this will be signalled with a special message to a system topic.

I think there is a slight misunderstanding in the second part of that sente= nce. Appendix C deals with the situation where a client's token has eit= her expired or otherwise become invalid and the broker whishes to inform th= e client of this situation. I was told that there is currently no message d= efined in MQTT for signaling a broker side disconnect to the client. This w= as created as a workaround to that problem.
Furthermore the proposal in Appendix C deals with cases where a client has = a successful connection and a valid token, but whishes to submit an additio= nal token granting further access rights.


--
Ludwig Seitz, PhD
Security Lab, RISE SICS
Phone +46(0)70-349 92 51

_______________________________________________
Ace mailing list
Ace@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/ace
--001a113cfa369f168b055172464a-- From nobody Thu Jun 8 05:53:33 2017 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 162F512E044 for ; Thu, 8 Jun 2017 05:53:32 -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, 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=port.ac.uk 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 Iymg30eqHxMO for ; Thu, 8 Jun 2017 05:53:29 -0700 (PDT) Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::22b]) (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 B96A5129BA2 for ; Thu, 8 Jun 2017 05:53:28 -0700 (PDT) Received: by mail-qt0-x22b.google.com with SMTP id u12so39806252qth.0 for ; Thu, 08 Jun 2017 05:53:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=port.ac.uk; s=google-20130730; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/spAun8HnNGAIpr8Vswmr1xmhl4ALdL+of5F6HmaYyg=; b=lShIGYehc0bSyDR3U4Yq/naV7LHsWpdzQJho20SioipwPByJrChDzfQ5JvpJ12Xo8i z8XONiycIg8oLVMirWOi4vm+vrHZTr3hjT6Ocsjjbs0wls4hAkYyWotvrqnVA5BZDRVf MivH6iK9MSolthaahBK3NBSaIiQQ18OjciKPo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=/spAun8HnNGAIpr8Vswmr1xmhl4ALdL+of5F6HmaYyg=; b=AJhjmVP1YSTSPGO/7BMfCb6uIGETg/qikKXM/7rlPlJoXIakcfem3T6nSJYdU8csqh m6OvbLWAtFdovhylZtWG4KitXNxEc0DnchoG2YUtYGdMSNPFrWz14+D6Wiz9IxReqG6Z bz/0BKYGmNtaJ+tnK0JWkg+Y4FgILkHRD52xOrV6fs/kb90DhvBxIIk35yhErHjCslwb WBJdLexJnOVWYZlXa1++VZEcL/bFvKyiESqDpgRQ29aHGaKCPYlwMQWrwbA8+UBSgI7l RGe/5Hads7frNQ5Tbd9Yc5qlcVAyJvsrKK9HaoBmNkf1ANGqpFYrGXyHrsGeE3Nubrw9 ubGA== X-Gm-Message-State: AODbwcA5sysfV4zidbIIQoUxvLBPApgsAa96O49C2PcD9Aq7ucBUYSfw ZUsy5LgUzKJHOuUXOWYZQPvbJVcKtzV0 X-Received: by 10.200.10.131 with SMTP id d3mr43487268qti.227.1496926407762; Thu, 08 Jun 2017 05:53:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.53.68 with HTTP; Thu, 8 Jun 2017 05:53:07 -0700 (PDT) In-Reply-To: <740f63dd-2ea7-ec1b-ac7a-725fcd703fa5@ri.se> References: <740f63dd-2ea7-ec1b-ac7a-725fcd703fa5@ri.se> From: Paul Fremantle Date: Thu, 8 Jun 2017 13:53:07 +0100 Message-ID: To: Ludwig Seitz Cc: ace@ietf.org Content-Type: multipart/alternative; boundary="089e08226300ca419a05517256c3" Archived-At: Subject: Re: [Ace] Comments on draft-sengul-ace-mqtt-tls-profile-00 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 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, 08 Jun 2017 12:53:32 -0000 --089e08226300ca419a05517256c3 Content-Type: text/plain; charset="UTF-8" Ludwig Thanks very much for the quick response and the useful info. For the first issue, I can see that there is an analogous model to the ACE approach on CoAP. I guess there is a difference with MQTT. In MQTT, for the client to publish to an unsecured topic, they need to CONNECT with no credentials, which many MQTT users would not like. While a DoS attacker could make many CONNECT messages with incorrect credentials, this is something that is already expected from the MQTT server's perspective, and the server can disconnect the connection quickly. In the case where a DoS attacker can connect without credentials, they can simply leave the connection open without publishing, or attempt to publish to other topics, etc, whereby they can use a lot more resources on the server than if they simply try a bad CONNECT packet. This is because of the connection-oriented model of MQTT. As for the second point, I now understand it much better. I will need to think about this in more detail. Best Paul On 8 June 2017 at 13:43, Ludwig Seitz wrote: > Hello Paul, > > although I'm not one of the authors of this draft, I feel I can help with > the two questions concerning appendices B and C. Please find my comments > inline. Feel free to ask for further clarifications. > > /Ludwig > > On 2017-06-08 12:14, Paul Fremantle wrote: > >> Hi >> >> I would like to make some comments on the draft >> draft-sengul-ace-mqtt-tls-profile-00. >> >> ... > >> 7) The approach proposed in Appendix B seems to enable DoS attacks >> against the broker. It is not clear to me on reading this what the benefits >> are, but that is probably my lack of knowledge of the ACE approach. Can >> someone please help me understand the purpose of this flow. >> > As you described in 4), sending the token in the payload of MQTT messages > is challenging. Therefore Appendix B describes a way to submit tokens to > the broker previous to requests (both publish and subscribe). > > Obviously you can overload the broker with fake access tokens using the > authz-info topic, but since all clients (both publishers and subscribers) > will be unauthorized before they first transmit their access token (in > whatever way they do that), the broker has to make a leap of faith to > accept data that might potentially be an access token in some way. I don't > see this way as being more dangerous than any other method of initially > providing an access token to the broker. > > This flow is analogous to what the ACE framework defines, i.e. an > unprotected REST resource "authz-info" to which client can POST their > access tokens. > > > 8) Appendix C seems to be trying to deal with the situation where a >> client's token has expired but it may carry on working with reduced >> permissions and this will be signalled with a special message to a system >> topic. >> > > I think there is a slight misunderstanding in the second part of that > sentence. Appendix C deals with the situation where a client's token has > either expired or otherwise become invalid and the broker whishes to inform > the client of this situation. I was told that there is currently no message > defined in MQTT for signaling a broker side disconnect to the client. This > was created as a workaround to that problem. > Furthermore the proposal in Appendix C deals with cases where a client has > a successful connection and a valid token, but whishes to submit an > additional token granting further access rights. > > > -- > Ludwig Seitz, PhD > Security Lab, RISE SICS > Phone +46(0)70-349 92 51 > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > -- Paul Fremantle Doctoral Researcher, University of Portsmouth, School of Computing Visiting Scientist, Institute of the Architecture of Application Systems, Stuttgart Visiting Lecturer, Software Engineering Programme, Oxford University Co-Founder, WSO2 Apache Member and Committer email: paul.fremantle@port.ac.uk, paul@fremantle.org twitter: pzfreo / skype: paulfremantle / blog: http://pzf.fremantle.org --089e08226300ca419a05517256c3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Ludwig

Thanks very much for the quick r= esponse and the useful info.=C2=A0

For the first i= ssue, I can see that there is an analogous model to the ACE approach on CoA= P. I guess there is a difference with MQTT. In MQTT, for the client to publ= ish to an unsecured topic, they need to CONNECT with no credentials, which = many MQTT users would not like. While a DoS attacker could make many CONNEC= T messages with incorrect credentials, this is something that is already ex= pected from the MQTT server's perspective, and the server can disconnec= t the connection quickly. In the case where a DoS attacker can connect with= out credentials, they can simply leave the connection open without publishi= ng, or attempt to publish to other topics, etc, whereby they can use a lot = more resources on the server than if they simply try a bad CONNECT packet. = This is because of the connection-oriented model of MQTT.

As for the second point, I now understand it much better. I will ne= ed to think about this in more detail.=C2=A0

Best<= /div>
Paul

On 8 June 2017 at 13:43, Ludwig Seitz <ludwig.seitz@ri.se>= ; wrote:
Hello Paul,

although I'm not one of the authors of this draft, I feel I can help wi= th the two questions concerning appendices B and C. Please find my comments= inline. Feel free to ask for further clarifications.

/Ludwig

On 2017-06-08 12:14, Paul Fremantle wrote:
Hi

I would like to make some comments on the draft draft-sengul-ace-mqtt-tls-p= rofile-00.

 ...
7) The approach proposed in=C2=A0 Appendix B seems to enable DoS attacks ag= ainst the broker. It is not clear to me on reading this what the benefits a= re, but that is probably my lack of knowledge of the ACE approach. Can some= one please help me understand the purpose of this flow.
 As you described in 4), sending the token in the payload of MQTT messages i= s challenging. Therefore Appendix B describes a way to submit tokens to the= broker previous to requests (both publish and subscribe).

Obviously you can overload the broker with fake access tokens using the aut= hz-info topic, but since all clients (both publishers and subscribers) will= be unauthorized before they first transmit their access token (in whatever= way they do that), the broker has to make a leap of faith to accept data t= hat might potentially be an access token in some way. I don't see this = way as being more dangerous than any other method of initially providing an= access token to the broker.

This flow is analogous to what the ACE framework defines, i.e. an unprotect= ed REST resource "authz-info" to which client can POST their acce= ss tokens.


8) Appendix C seems to be trying to deal with the situation where a client&= #39;s token has expired but it may carry on working with reduced permission= s and this will be signalled with a special message to a system topic.

I think there is a slight misunderstanding in the second part of that sente= nce. Appendix C deals with the situation where a client's token has eit= her expired or otherwise become invalid and the broker whishes to inform th= e client of this situation. I was told that there is currently no message d= efined in MQTT for signaling a broker side disconnect to the client. This w= as created as a workaround to that problem.
Furthermore the proposal in Appendix C deals with cases where a client has = a successful connection and a valid token, but whishes to submit an additio= nal token granting further access rights.


--
Ludwig Seitz, PhD
Security Lab, RISE SICS
Phone +46(0)70-349 92 51

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



--
Paul Fremantle
Doctora= l Researcher, University of Portsmouth, School of Computing
Visit= ing Scientist,=C2=A0Institute of the Architecture of Application Systems, S= tuttgart
Visiting Lecturer, Software Engineering Programme, Oxfor= d University
Co-Founder, WSO2
Apache = Member and Committer
twitter: pzfreo / skype: paulfremantle / = blog: http://pzf.fre= mantle.org
--089e08226300ca419a05517256c3-- From nobody Thu Jun 8 07:29:11 2017 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 D6C8A12E04D; Thu, 8 Jun 2017 07:29:09 -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.54.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149693214984.14664.17316774939767231984@ietfa.amsl.com> Date: Thu, 08 Jun 2017 07:29:09 -0700 Archived-At: Subject: [Ace] I-D Action: draft-ietf-ace-dtls-authorize-00.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2017 14:29:10 -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 of the IETF. Title : Datagram Transport Layer Security (DTLS) Profile for Authentication and Authorization for Constrained Environments (ACE) Authors : Stefanie Gerdes Olaf Bergmann Carsten Bormann G枚ran Selander Ludwig Seitz Filename : draft-ietf-ace-dtls-authorize-00.txt Pages : 17 Date : 2017-06-08 Abstract: This specification defines a profile for delegating client authentication and authorization in a constrained environment by establishing a Datagram Transport Layer Security (DTLS) channel between resource-constrained nodes. The protocol relies on DTLS for communication security between entities in a constrained network. A resource-constrained node can use this protocol to delegate management of authorization information to a trusted host with less severe limitations regarding processing power and memory. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ace-dtls-authorize/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ace-dtls-authorize-00 https://datatracker.ietf.org/doc/html/draft-ietf-ace-dtls-authorize-00 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 Thu Jun 8 08:57:47 2017 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 E9799128DE7 for ; Thu, 8 Jun 2017 08:57:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 S5_cGKwTzI1b for ; Thu, 8 Jun 2017 08:57:44 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (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 3BF38128BA2 for ; Thu, 8 Jun 2017 08:57:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v58FveqO010597 for ; Thu, 8 Jun 2017 17:57:40 +0200 (CEST) Received: from aung.tzi.org (unknown [IPv6:2001:638:708:301:224:d6ff:fe13:2040]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3wk96r2BvMz3ZCC for ; Thu, 8 Jun 2017 17:57:40 +0200 (CEST) From: Olaf Bergmann To: References: Date: Thu, 08 Jun 2017 17:57:39 +0200 In-Reply-To: (Kepeng Li's message of "Tue, 06 Jun 2017 17:57:16 +0800") Message-ID: <87zidi3218.fsf@aung.informatik.uni-bremen.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Ace] Call for adoption for draft-gerdes-ace-dtls-authorize X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 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, 08 Jun 2017 15:57:46 -0000 Hi all, "Kepeng Li" writes: > Based on the feedback we received in the Chacago F2F meeting and the > mailing list, it is concluded that we got enough supports to adopt > this document,. > > Authors: Please resubmit the draft as > draft-ietf-ace-dtls-authorize-00. Thank you very much, we now have resubmitted draft-gerdes-ace-dtls-authoriz= e-01 as draft-ietf-ace-dtls-authorize-00. The sources still live at https://github.com/obgm/ace-dtls-profile. Gr=C3=BC=C3=9Fe Olaf From nobody Fri Jun 9 08:56:26 2017 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 DF84C129481 for ; Fri, 9 Jun 2017 08:56:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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_PASS=-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 v6OC0LMtYAkK for ; Fri, 9 Jun 2017 08:56:22 -0700 (PDT) Received: from mail-ot0-x22a.google.com (mail-ot0-x22a.google.com [IPv6:2607:f8b0:4003:c0f::22a]) (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 4EEC21243F3 for ; Fri, 9 Jun 2017 08:56:22 -0700 (PDT) Received: by mail-ot0-x22a.google.com with SMTP id i31so40926269ota.3 for ; Fri, 09 Jun 2017 08:56:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=TlzJxFee91wWLQH9GerRafLKk5HdFkhgnL+P3risMbU=; b=A5zfrLNyyb2Mqk7YNaLQuymZjkPJFoECT66XIRmwbtZgso7jrh+Mjjo/SVkstZvEmk iTU3BI1zvDxjdUsNtMOAd108jcQImuJjKqG/14GxF3LCpzV1VGdjDbGBauPeZyxEixXa W4ss30wkzY8pHKtbiMQTixF1ktkLk2DjGe6H+bzdvbtJa3diJZCVm5Aq31TsGsWAaIt8 gJ3Y89Qd9T/6JaXG8PiRDTOdo+JaoVc8qceeDG/qpB8+X7KOomnryK8Kpb+d/EE59q8M RvwAYV3K8wu5IbBw45DZ2xPeZJOaRkxh6+3NbjjXlW/LAU4BfFjek6yIETLoeKDnlG+F iDww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=TlzJxFee91wWLQH9GerRafLKk5HdFkhgnL+P3risMbU=; b=T+u/DTkZ7ZqPuePpIwz0jO614j27UL2itj92+IF5djCkKJGfP7+FH6KmFmnATwSHmY jb+BMreP/HlmKwMU1zXzUxxIg1KbX8/jWIHaMFGfd+B/ahSHoPH02Fo9OIykVmyIM1wf 3DUxHPNRexTB1j+8WdugoU99LdF5iItxO9q3eeYUEhB2D+waMCPkQ/d4WOiPs6ik1KOz pP/FO6VxmiYjLx92vQZrDGqDivz06xOIiu8eJ/O3ihRbIqsjQsG5pd8cig8NvAI+cfju zblVcqFNK/252xQCsWE9fhOMbz3r4fZkRifJ7snvu7uVu2nKN5lEW6hi0pR+l8rFAyfH k4RQ== X-Gm-Message-State: AKS2vOwoKxNJYmVizy599mcHL0kMvXRxChAzqGuHTmyQzezvjXDy7yuI TV7Fv+haIra+iN60SJeEZ0hlosPeuA== X-Received: by 10.157.82.42 with SMTP id e42mr25011894oth.153.1497023781649; Fri, 09 Jun 2017 08:56:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.65.6 with HTTP; Fri, 9 Jun 2017 08:56:21 -0700 (PDT) In-Reply-To: References: From: Cigdem Sengul Date: Fri, 9 Jun 2017 16:56:21 +0100 Message-ID: To: Paul Fremantle Cc: ace@ietf.org Content-Type: multipart/alternative; boundary="f403043542dcb9c37105518902d2" Archived-At: Subject: Re: [Ace] Comments on draft-sengul-ace-mqtt-tls-profile-00 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 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, 09 Jun 2017 15:56:25 -0000 --f403043542dcb9c37105518902d2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello Paul, Again, thank you very much for your comments. We would be very happy to work with you on this draft. We can try together to incorporate some of your suggestions and your OAuth/MQTT work into the draft. Answers are below for the rest of your comments. > 2) I'd like to make an overall comment regarding the MQTT specification. > The current standard (v3.1.1) is widely adopted and used, and will likely > remain so for a while still. However, there are issues in using it with > OAuth2, especially around request-response flows. These issues seem to be > resolved in the proposed working draft [4] for MQTT 5.0 (the replacement > version). Therefore it would seem like a good idea for this proposed > mapping of ACE to MQTT to look at the current 3.1.1 and proposed 5.0 > versions as two different approaches, where it might be positive to > postpone certain aspects into the 5.0 approach that are hard to deal with > in 3.1.1. I will call these out below. > Indeed. We were aware of the work on MQTT version 5.0 when we set out to write the draft. But, we did not know when it would be approved. So, we decided to base the work on the official standard. But, we hinted in the draft that some of the implementation difficulties can be ironed out with the new version of MQTT. Once the new version becomes official, it would be useful to update the spec to cover both versions. > 3) I'd be interested to know why the specification calls out the Will > message handling, as it seems that it proposes the normal MQTT behaviour. > Maybe I misunderstood? > In our draft, we included all the MQTT messages that would be affected by an authorisation decision. This was to make sure we do not leave any gaps, when the MQTT v3.1 is considered. Also, in our draft, the broker triggers server disconnects due to authorisation problems. Hence, we are creating a condition where a WILL message would be appropriate (the WILL message should be sent of course only if the client specified it in the CONNECT). > > 4) The proposal to allow clients to include the token in the payload of > publish messages (2.2.1) seems to me to be challenging. The problem is th= at > MQTT 3.1.1 has no way of adding headers to the message, so I can understa= nd > that this is a way around this. However, I feel that this mixes up the > layering of the protocol. This is one area where MQTT 5.0 will solve a > problem (with MQTT Properties, and the ability to reauthenticate), so I > would suggest considering that this be removed and dealt with in a MQTT 5= .0 > specific way. > We were aware this does cross protocol layers, but we wanted an mechanism for the client to push a new token without disconnecting, reconnecting & re-subscribing to topics. It is optional - the fallback would be to disconnect & reconnect with a new token. We're open to further feedback about whether this is a good idea. > 5) There is some description of how the server should acknowledge message= s > in 2.2.1. Again, as in point 3, if there is no change to the default > behaviour of MQTT then it maybe better not to call it out in this > specification. > Yes, this can be shortened. We can just say: "the broker behaves according to the MQTT spec and may or may not send an ACK depending on the QoS level". We wish to still keep some information for the broker response for completeness sake. > > 6) In 2.2.2, the specification calls out the behaviour of the broker > onbound, once a publish message is received. This seems to imply that all > the publishers and subscribers to a broker are using ACE. Is that an > assumption of this spec or can it support both ACE and non-ACE systems. F= or > example, an ACE-based publisher and a subscriber that uses a traditional > MQTT authorisation scheme? Since the authorisation of subscribers using A= CE > is covered in 2.3, maybe it is not necessary to have 2.2.2 at all > We thought about the possibility of supporting ACE & non-ACE clients. This is an interesting idea: would allow us to support legacy clients. But, in a mixed scenario, the broker then also needs an authorisation function, e.g. using ACLs, separately from the authorisation server. This is to make sure that only =E2=80=9Cauthorised=E2=80=9D clients publish= /subscribe to =E2=80=9Cprotected=E2=80=9D topics. The draft doesn't exclude this possibility. It's worth including 2.2.2 for clarity, to explain how the broker forwards the PUBLISH messages to clients, and specifically the behaviour on token expiry. We'll try to make it more concise. > > 7) The approach proposed in Appendix B seems to enable DoS attacks > against the broker. It is not clear to me on reading this what the benefi= ts > are, but that is probably my lack of knowledge of the ACE approach. Can > someone please help me understand the purpose of this flow. > This, as stated by Ludwig, was put in to support /authz-info of ACE. It was to support the PoP keys to be used in TLS handshake between the client and the broker. But yes, the MQTT server needs to be resistant to DoS attempts pre-authorisation. MQTT needs to resist DoS before and during CONNECT (TCP holding, excess data). MQTT with /authz-info needs to implement similar resistance, for example dropping connections that fail to authenticate in a timely fashion, and blocking repeated offenders, so there's little difference in theory - although resistance pre-CONNECT may already exist in some broker implementations. A discussion can be put in Security Considerations. > > 8) Appendix C seems to be trying to deal with the situation where a > client's token has expired but it may carry on working with reduced > permissions and this will be signalled with a special message to a system > topic. This seems overly complex to put in the specification. Again, this > will be resolved with MQTT 5.0 where the broker will be able to request t= he > client to re-authenticate without dropping the connection, and also will = be > able to drop the connection more gracefully. Looking at this from a clien= t > device development perspective, it seems that there are two options: > a) Build a client that can cope with listening for "downgrade" messages > and that can cope with downgraded permissions when tokens expire > b) Build a client that can cope with abrupt disconnections, and can deal > with expired tokens. > Since clients already have to have logic to handle (b) anyway, the value > of (a) seems less. > > Indeed, this section was put in for better error handling. Some of these issues may be resolved with the new MQTT v5.0. The option of feeding new tokens can be handled here - but, again the reauthentication approach may help with this issue in MQTT v5. We need to check MQTT v5 and think a bit more on this. We need to clarify the draft so that this section is described more clearly (also to include some of the points Ludwig raised). 9) I hope this hasn't come across as overly negative. There is a lot I like > about this specification but I felt that a detailed set of comments would > be useful to the authors. Also I may well have misunderstood aspects of > this spec! > > Not at all, we wholeheartedly appreciate the response & opportunity for discussion! Thanks, Cigdem and Anthony --f403043542dcb9c37105518902d2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Paul,
<= font face=3D"arial, helvetica, sans-serif">Again, thank you very much for y= our comments.
We would be very happy to work with you on this = draft.=C2=A0 We can try together to incorporate some of =C2=A0your suggesti= ons and your OAuth/MQTT work into the draft.=C2=A0

Answers are below for the rest of your comments.


2) I'd like to make an overall comment = regarding the MQTT specification. The current standard (v3.1.1) is widely a= dopted and used, and will likely remain so for a while still. However, ther= e are issues in using it with OAuth2, especially around request-response fl= ows. These issues seem to be resolved in the proposed working draft [4] for= MQTT 5.0 (the replacement version). Therefore it would seem like a good id= ea for this proposed mapping of ACE to MQTT to look at the current 3.1.1 an= d proposed 5.0 versions as two different approaches, where it might be posi= tive to postpone certain aspects into the 5.0 approach that are hard to dea= l with in 3.1.1. I will call these out below.
=
Indeed. We were aware of the work on MQTT version 5.0 when = we set out to=C2=A0=C2=A0write the draft. But, we did not know when it woul= d be approved. So, we decided to base the work on the official standard. Bu= t, we hinted in the draft that some of the implementation difficulties can = be ironed out with the new version of MQTT.
Once the new versi= on becomes official, it would be useful to update the spec to cover both ve= rsions.

=

3) I'd be interested to know why the specification = calls out the Will message handling, as it seems that it proposes the norma= l MQTT behaviour. Maybe I misunderstood?

<= /div>
In our draft, we included all =C2=A0the MQTT messages that would = be affected by an authorisation decision. This was to make sure we do not l= eave any gaps, when the MQTT v3.1 is considered. Also, in our draft, the br= oker triggers server disconnects due to authorisation problems. Hence, we a= re creating a condition where a WILL message would be appropriate=C2=A0(the WILL message should be sent of cou= rse only if the client specified it in the CONNECT).
=C2=A0

4) The proposal to allow client= s to include the token in the payload of publish messages (2.2.1) seems to = me to be challenging. The problem is that MQTT 3.1.1 has no way of adding h= eaders to the message, so I can understand that this is a way around this. = However, I feel that this mixes up the layering of the protocol. This is on= e area where MQTT 5.0 will solve a problem (with MQTT Properties, and the a= bility to reauthenticate), so I would suggest considering that this be remo= ved and dealt with in a MQTT 5.0 specific way.

We were aware this does cross protocol layers, but we wante= d an mechanism for the client to push a new token without disconnecting, re= connecting & re-subscribing to topics.=C2=A0 It is optional - the fallb= ack would be to disconnect & reconnect with a new token.=C2=A0 We'r= e open to further feedback about whether this is a good idea. =C2=A0


5) = There is some description of how the server should acknowledge messages in = 2.2.1. Again, as in point 3, if there is no change to the default behaviour= of MQTT then it maybe better not to call it out in this specification.

Yes, this can be shortened.=C2=A0 = We can just say: "the broker behaves according to the MQTT spec and ma= y or may not send an ACK depending on the QoS level". We wish to still= keep some information for the broker response for completeness sake.
=C2=A0

= 6) In 2.2.2, the specification calls out the behaviour of the broker onboun= d, once a publish message is received. This seems to imply that all the pub= lishers and subscribers to a broker are using ACE. Is that an assumption of= this spec or can it support both ACE and non-ACE systems. For example, an = ACE-based publisher and a subscriber that uses a traditional MQTT authorisa= tion scheme? Since the authorisation of subscribers using ACE is covered in= 2.3, maybe it is not necessary to have 2.2.2 at all=C2=A0

We thought about the possibility of suppor= ting ACE & non-ACE clients.=C2=A0 This is an interesting idea: would al= low us =C2=A0to support legacy clients.=C2=A0
But, in a mixed sce= nario, the broker then also needs an authorisation function, e.g. using ACL= s, separately from the authorisation server. =C2=A0
This is to ma= ke sure that only =E2=80=9Cauthorised=E2=80=9D clients publish/subscribe to= =E2=80=9Cprotected=E2=80=9D topics.=C2=A0
The draft doesn't = exclude this possibility.

It's worth including= 2.2.2 for clarity, to explain how the broker forwards the PUBLISH messages= to clients, and specifically the behaviour on token expiry.=C2=A0 We'l= l try to make it more concise.
=C2=A0

7) The approach proposed in =C2=A0App= endix B seems to enable DoS attacks against the broker. It is not clear to = me on reading this what the benefits are, but that is probably my lack of k= nowledge of the ACE approach. Can someone please help me understand the pur= pose of this flow.

This, a= s stated by Ludwig, was put in to support /authz-info of ACE.=C2=A0 It was = to support the PoP keys to be used in TLS handshake between the client =C2= =A0and the broker.=C2=A0 But yes, the MQTT server needs to be resistant to = DoS attempts pre-authorisation. MQTT needs to resist DoS before and during = CONNECT (TCP holding, excess data). MQTT with /authz-info needs to implemen= t similar resistance, for example dropping connections that fail to authent= icate in a timely fashion, and blocking repeated offenders, so there's = little difference in theory - although resistance pre-CONNECT may already e= xist in some broker implementations.=C2=A0 A discussion can be put in Secur= ity Considerations.
=C2=A0

8) Appendix C seems to be trying to deal wit= h the situation where a client's token has expired but it may carry on = working with reduced permissions and this will be signalled with a special = message to a system topic. This seems overly complex to put in the specific= ation. Again, this will be resolved with MQTT 5.0 where the broker will be = able to request the client to re-authenticate without dropping the connecti= on, and also will be able to drop the connection more gracefully. Looking a= t this from a client device development perspective, it seems that there ar= e two options:
a) Build a client that can cope with listening for= "downgrade" messages and that can cope with downgraded permissio= ns when tokens expire
b) Build a client that can cope with abrupt= disconnections, and can deal with expired tokens.
Since clients = already have to have logic to handle (b) anyway, the value of (a) seems les= s.=C2=A0


In= deed, this section was put in for better error handling. Some of these issu= es may be resolved with the new MQTT v5.0.
The option of feeding = new tokens can =C2=A0be handled here - but, again the reauthentication appr= oach may help with this issue in MQTT v5. We need to check MQTT v5 and thin= k a bit more on this.
We need to clarify the draft so that this s= ection is described =C2=A0more clearly (also to include some of the points = Ludwig raised).

9) I hope this hasn't come across as overly negative. = There is a lot I like about this specification but I felt that a detailed s= et of comments would be useful to the authors. Also I may well have misunde= rstood aspects of this spec!

Not at all, we wholeheartedly appreciate the response & op= portunity for discussion!

Thanks,=C2=A0
<= div>Cigdem and Anthony=C2=A0
--f403043542dcb9c37105518902d2-- From nobody Sat Jun 10 23:05:01 2017 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 8F6F6128961 for ; Sat, 10 Jun 2017 23:05:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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=port.ac.uk 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 zjShL_HxhV4E for ; Sat, 10 Jun 2017 23:04:57 -0700 (PDT) Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::233]) (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 066481243FE for ; Sat, 10 Jun 2017 23:04:56 -0700 (PDT) Received: by mail-qt0-x233.google.com with SMTP id w1so101338880qtg.2 for ; Sat, 10 Jun 2017 23:04:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=port.ac.uk; s=google-20130730; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=fAlpwS4HrXgfNVs3jATl3qtoe2uZojV0J+BhlyUQWT0=; b=tZA3q6ZSQyVrn5dk7sp2W5/m512m2eYDfb3XOygKeCkYTTLYmQWNw9AyEuMjK9pIQl 9EQ6UBMVS7J4V41hy0UGNNLXxi6Gst3GRgDsHAdt2sObjOjtrqtDG9jQvIbnLf/QXGm9 MN1WQ3XO0/ZIoWkhTpsqAbbHUsRh8Zgwe16Bg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=fAlpwS4HrXgfNVs3jATl3qtoe2uZojV0J+BhlyUQWT0=; b=Bq8ul47c2aoEHHzAjP1i9yrR/AY5ovpivjTMHg3Bcd3RB9rP1DMgqjpkZo7nJIwYE/ fAGeLyZwysSau7gaBQt2FcKPa0bXOX57EsFmTM0MPyR3AIx0JytnLIgZakcv88e4bkzo ERizKh03RMRjJ7ZB5w2QiT6sukBJBg6MXRDMCOT+fC1McYoGLIDITJy8uV9RJGGpR7Se 6pEW5f2DujmEPA2QUKURkEFep4qXDLkFP7Q+KHNfvGHsHqB5txsf2u3X/BZWeYzfUDWx BrWU8jKNy0op5A/Q0JlJp0cjJEhbqoDJT7SX9ABLhI4zku2wSSKUENnsXIDJAmJPHUbb yrjg== X-Gm-Message-State: AKS2vOwnpvGZzSL4UTuHnxzlzfUfw7MRqYcHrVkoceovcmiS1gECXBex n837nYvZlnz93qbdKinOkgbqok6kHWqI X-Received: by 10.200.10.129 with SMTP id d1mr2081518qti.227.1497161095784; Sat, 10 Jun 2017 23:04:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.53.68 with HTTP; Sat, 10 Jun 2017 23:04:35 -0700 (PDT) In-Reply-To: References: From: Paul Fremantle Date: Sun, 11 Jun 2017 07:04:35 +0100 Message-ID: To: Cigdem Sengul Cc: ace@ietf.org Content-Type: multipart/alternative; boundary="089e0822b7b04945ca0551a8fbe0" Archived-At: Subject: Re: [Ace] Comments on draft-sengul-ace-mqtt-tls-profile-00 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 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: Sun, 11 Jun 2017 06:05:01 -0000 --089e0822b7b04945ca0551a8fbe0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Cigdem and Anthony Thanks for the feedback. We would be very happy to work with you on this draft. We can try together > to incorporate some of your suggestions and your OAuth/MQTT work into th= e > draft. > I'd be very happy to collaborate. > > Answers are below for the rest of your comments. > > >> 2) I'd like to make an overall comment regarding the MQTT specification. >> The current standard (v3.1.1) is widely adopted and used, and will likel= y >> remain so for a while still. However, there are issues in using it with >> OAuth2, especially around request-response flows. These issues seem to b= e >> resolved in the proposed working draft [4] for MQTT 5.0 (the replacement >> version). Therefore it would seem like a good idea for this proposed >> mapping of ACE to MQTT to look at the current 3.1.1 and proposed 5.0 >> versions as two different approaches, where it might be positive to >> postpone certain aspects into the 5.0 approach that are hard to deal wit= h >> in 3.1.1. I will call these out below. >> > > Indeed. We were aware of the work on MQTT version 5.0 when we set out > to write the draft. But, we did not know when it would be approved. So, = we > decided to base the work on the official standard. But, we hinted in the > draft that some of the implementation difficulties can be ironed out with > the new version of MQTT. > Once the new version becomes official, it would be useful to update the > spec to cover both versions. > That seems like a great approach. I'd be happy to help with this. > > >> 3) I'd be interested to know why the specification calls out the Will >> message handling, as it seems that it proposes the normal MQTT behaviour= . >> Maybe I misunderstood? >> > > In our draft, we included all the MQTT messages that would be affected > by an authorisation decision. This was to make sure we do not leave any > gaps, when the MQTT v3.1 is considered. Also, in our draft, the broker > triggers server disconnects due to authorisation problems. Hence, we are > creating a condition where a WILL message would be appropriate (the WILL > message should be sent of course only if the client specified it in the > CONNECT). > I see. I think this is a good idea, but I think it would be useful to state that this is the default MQTT behaviour and that this spec is not overriding it. > > >> >> 4) The proposal to allow clients to include the token in the payload of >> publish messages (2.2.1) seems to me to be challenging. The problem is t= hat >> MQTT 3.1.1 has no way of adding headers to the message, so I can underst= and >> that this is a way around this. However, I feel that this mixes up the >> layering of the protocol. This is one area where MQTT 5.0 will solve a >> problem (with MQTT Properties, and the ability to reauthenticate), so I >> would suggest considering that this be removed and dealt with in a MQTT = 5.0 >> specific way. >> > > We were aware this does cross protocol layers, but we wanted an mechanism > for the client to push a new token without disconnecting, reconnecting & > re-subscribing to topics. It is optional - the fallback would be to > disconnect & reconnect with a new token. We're open to further feedback > about whether this is a good idea. > I would be interested to hear what others think. My own experience of MQTT and other pub/sub systems would make me believe we would be better to support this in MQTT 5, but not in MQTT 3. I understand that it is optional, but in general I feel that constrained choices are better in constrained device scenarios. > > >> 5) There is some description of how the server should acknowledge >> messages in 2.2.1. Again, as in point 3, if there is no change to the >> default behaviour of MQTT then it maybe better not to call it out in thi= s >> specification. >> > > Yes, this can be shortened. We can just say: "the broker behaves > according to the MQTT spec and may or may not send an ACK depending on th= e > QoS level". We wish to still keep some information for the broker respons= e > for completeness sake. > Sounds good. > >> 6) In 2.2.2, the specification calls out the behaviour of the broker >> onbound, once a publish message is received. This seems to imply that al= l >> the publishers and subscribers to a broker are using ACE. Is that an >> assumption of this spec or can it support both ACE and non-ACE systems. = For >> example, an ACE-based publisher and a subscriber that uses a traditional >> MQTT authorisation scheme? Since the authorisation of subscribers using = ACE >> is covered in 2.3, maybe it is not necessary to have 2.2.2 at all >> > > We thought about the possibility of supporting ACE & non-ACE clients. > This is an interesting idea: would allow us to support legacy clients. > But, in a mixed scenario, the broker then also needs an authorisation > function, e.g. using ACLs, separately from the authorisation server. > This is to make sure that only =E2=80=9Cauthorised=E2=80=9D clients publi= sh/subscribe to > =E2=80=9Cprotected=E2=80=9D topics. > The draft doesn't exclude this possibility. > It's worth including 2.2.2 for clarity, to explain how the broker forwards > the PUBLISH messages to clients, and specifically the behaviour on token > expiry. We'll try to make it more concise. > Couldn't we point to the next section and say that "when the subscriber is also using this profile, the broker then behaves as in 2.2.3" or something similar? I agree that dealing with token expiry is important. > > >> >> 7) The approach proposed in Appendix B seems to enable DoS attacks >> against the broker. It is not clear to me on reading this what the benef= its >> are, but that is probably my lack of knowledge of the ACE approach. Can >> someone please help me understand the purpose of this flow. >> > > This, as stated by Ludwig, was put in to support /authz-info of ACE. It > was to support the PoP keys to be used in TLS handshake between the clien= t > and the broker. But yes, the MQTT server needs to be resistant to DoS > attempts pre-authorisation. MQTT needs to resist DoS before and during > CONNECT (TCP holding, excess data). MQTT with /authz-info needs to > implement similar resistance, for example dropping connections that fail = to > authenticate in a timely fashion, and blocking repeated offenders, so > there's little difference in theory - although resistance pre-CONNECT may > already exist in some broker implementations. A discussion can be put in > Security Considerations > I agree that a discussion of the pros and cons of this approach would be valuable. I'm not clear on the benefits of using POP keys in TLS handshakes. Can you please point me where to look? > > >> >> 8) Appendix C seems to be trying to deal with the situation where a >> client's token has expired but it may carry on working with reduced >> permissions and this will be signalled with a special message to a syste= m >> topic. This seems overly complex to put in the specification. Again, thi= s >> will be resolved with MQTT 5.0 where the broker will be able to request = the >> client to re-authenticate without dropping the connection, and also will= be >> able to drop the connection more gracefully. Looking at this from a clie= nt >> device development perspective, it seems that there are two options: >> a) Build a client that can cope with listening for "downgrade" messages >> and that can cope with downgraded permissions when tokens expire >> b) Build a client that can cope with abrupt disconnections, and can deal >> with expired tokens. >> Since clients already have to have logic to handle (b) anyway, the value >> of (a) seems less. >> >> > Indeed, this section was put in for better error handling. Some of these > issues may be resolved with the new MQTT v5.0. > The option of feeding new tokens can be handled here - but, again the > reauthentication approach may help with this issue in MQTT v5. We need to > check MQTT v5 and think a bit more on this. > We need to clarify the draft so that this section is described more > clearly (also to include some of the points Ludwig raised). > I'm still not clear that it isn't simpler and more effective to force the client to reconnect. In MQTT clients and servers are expected to be able to deal with unannounced disconnects. For example, many people use MQTT over 3G connections or other unreliable connections. Thanks for the feedback. Let me know how I can best join in the contribution. Best Paul --=20 Paul Fremantle Doctoral Researcher, University of Portsmouth, School of Computing Visiting Scientist, Institute of the Architecture of Application Systems, Stuttgart Visiting Lecturer, Software Engineering Programme, Oxford University Co-Founder, WSO2 Apache Member and Committer email: paul.fremantle@port.ac.uk, paul@fremantle.org twitter: pzfreo / skype: paulfremantle / blog: http://pzf.fremantle.org --089e0822b7b04945ca0551a8fbe0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Cigdem and Anthony

Thanks for the feedb= ack.

We would be very happy= to work with you on this draft.=C2=A0 We can try together to incorporate s= ome of =C2=A0your suggestions and your OAuth/MQTT work into the draft.=C2= =A0

I'd be very happ= y to collaborate.
=C2=A0

Answers are below for the rest of your co= mments.


2= ) I'd like to make an overall comment regarding the MQTT specification.= The current standard (v3.1.1) is widely adopted and used, and will likely = remain so for a while still. However, there are issues in using it with OAu= th2, especially around request-response flows. These issues seem to be reso= lved in the proposed working draft [4] for MQTT 5.0 (the replacement versio= n). Therefore it would seem like a good idea for this proposed mapping of A= CE to MQTT to look at the current 3.1.1 and proposed 5.0 versions as two di= fferent approaches, where it might be positive to postpone certain aspects = into the 5.0 approach that are hard to deal with in 3.1.1. I will call thes= e out below.

Indeed. W= e were aware of the work on MQTT version 5.0 when we set out to=C2=A0=C2=A0= write the draft. But, we did not know when it would be approved. So, we dec= ided to base the work on the official standard. But, we hinted in the draft= that some of the implementation difficulties can be ironed out with the ne= w version of MQTT.
Once the new version becomes official, it= would be useful to update the spec to cover both versions.

That seems like a gre= at approach. I'd be happy to help with this.
=C2=A0


3) I'd be interested to know why the = specification calls out the Will message handling, as it seems that it prop= oses the normal MQTT behaviour. Maybe I misunderstood?

= In= our draft, we included all =C2=A0the MQTT messages that would be affected = by an authorisation decision. This was to make sure we do not leave any gap= s, when the MQTT v3.1 is considered. Also, in our draft, the broker trigger= s server disconnects due to authorisation problems. Hence, we are creating = a condition where a WILL message would be appropriate=C2=A0(the WILL message should be sent of course only if = the client specified it in the CONNECT).

I see. I think this is a good idea, but I think it= would be useful to state that this is the default MQTT behaviour and that = this spec is not overriding it.
=C2=A0
=C2= =A0

4) Th= e proposal to allow clients to include the token in the payload of publish = messages (2.2.1) seems to me to be challenging. The problem is that MQTT 3.= 1.1 has no way of adding headers to the message, so I can understand that t= his is a way around this. However, I feel that this mixes up the layering o= f the protocol. This is one area where MQTT 5.0 will solve a problem (with = MQTT Properties, and the ability to reauthenticate), so I would suggest con= sidering that this be removed and dealt with in a MQTT 5.0 specific way.

We were aware this does cr= oss protocol layers, but we wanted an mechanism for the client to push a ne= w token without disconnecting, reconnecting & re-subscribing to topics.= =C2=A0 It is optional - the fallback would be to disconnect & reconnect= with a new token.=C2=A0 We're open to further feedback about whether t= his is a good idea. =C2=A0
I would be interested to hear what others think. My own experie= nce of MQTT and other pub/sub systems would make me believe we would be bet= ter to support this in MQTT 5, but not in MQTT 3. I understand that it is o= ptional, but in general I feel that constrained choices are better in const= rained device scenarios.
=C2=A0
<= div>


5) There is some description of how the server should = acknowledge messages in 2.2.1. Again, as in point 3, if there is no change = to the default behaviour of MQTT then it maybe better not to call it out in= this specification.

Yes= , this can be shortened.=C2=A0 We can just say: "the broker behaves ac= cording to the MQTT spec and may or may not send an ACK depending on the Qo= S level". We wish to still keep some information for the broker respon= se for completeness sake.

=
Sounds good.
=C2=A0

6) In = 2.2.2, the specification calls out the behaviour of the broker onbound, onc= e a publish message is received. This seems to imply that all the publisher= s and subscribers to a broker are using ACE. Is that an assumption of this = spec or can it support both ACE and non-ACE systems. For example, an ACE-ba= sed publisher and a subscriber that uses a traditional MQTT authorisation s= cheme? Since the authorisation of subscribers using ACE is covered in 2.3, = maybe it is not necessary to have 2.2.2 at all=C2=A0

We thought about the possibility of suppo= rting ACE & non-ACE clients.=C2=A0 This is an interesting idea: would a= llow us =C2=A0to support legacy clients.=C2=A0
But, in a mixed sc= enario, the broker then also needs an authorisation function, e.g. using AC= Ls, separately from the authorisation server. =C2=A0
This is to m= ake sure that only =E2=80=9Cauthorised=E2=80=9D clients publish/subscribe t= o =E2=80=9Cprotected=E2=80=9D topics.=C2=A0
The draft doesn't= exclude this possibility.
<= br>
It's worth including 2.2.= 2 for clarity, to explain how the broker forwards the PUBLISH messages to c= lients, and specifically the behaviour on token expiry.=C2=A0 We'll try= to make it more concise.
Couldn't we point to the next section and say that "w= hen the subscriber is also using this profile, the broker then behaves as i= n 2.2.3" or something similar? I agree that dealing with token expiry = is important.
=C2=A0
=C2=A0

7) The approach proposed in =C2=A0Appendix B seems to enable DoS attacks = against the broker. It is not clear to me on reading this what the benefits= are, but that is probably my lack of knowledge of the ACE approach. Can so= meone please help me understand the purpose of this flow.

This, as stated by Ludwig, was put i= n to support /authz-info of ACE.=C2=A0 It was to support the PoP keys to be= used in TLS handshake between the client =C2=A0and the broker.=C2=A0 But y= es, the MQTT server needs to be resistant to DoS attempts pre-authorisation= . MQTT needs to resist DoS before and during CONNECT (TCP holding, excess d= ata). MQTT with /authz-info needs to implement similar resistance, for exam= ple dropping connections that fail to authenticate in a timely fashion, and= blocking repeated offenders, so there's little difference in theory - = although resistance pre-CONNECT may already exist in some broker implementa= tions.=C2=A0 A discussion can be put in Security Considerations
=

I agree that a discussio= n of the pros and cons of this approach would be valuable. I'm not clea= r on the benefits of using POP keys in TLS handshakes. Can you please point= me where to look? =C2=A0
=
=C2=A0

= 8) Appendix C seems to be trying to deal with the situation where a client&= #39;s token has expired but it may carry on working with reduced permission= s and this will be signalled with a special message to a system topic. This= seems overly complex to put in the specification. Again, this will be reso= lved with MQTT 5.0 where the broker will be able to request the client to r= e-authenticate without dropping the connection, and also will be able to dr= op the connection more gracefully. Looking at this from a client device dev= elopment perspective, it seems that there are two options:
a) Bui= ld a client that can cope with listening for "downgrade" messages= and that can cope with downgraded permissions when tokens expire
b) Build a client that can cope with abrupt disconnections, and can deal w= ith expired tokens.
Since clients already have to have logic to h= andle (b) anyway, the value of (a) seems less.=C2=A0


Indeed, this section was p= ut in for better error handling. Some of these issues may be resolved with = the new MQTT v5.0.
The option of feeding new tokens can =C2=A0be = handled here - but, again the reauthentication approach may help with this = issue in MQTT v5. We need to check MQTT v5 and think a bit more on this.
We need to clarify the draft so that this section is described =C2= =A0more clearly (also to include some of the points Ludwig raised).

I'm still not cl= ear that it isn't simpler and more effective to force the client to rec= onnect. In MQTT clients and servers are expected to be able to deal with un= announced disconnects. For example, many people use MQTT over 3G connection= s or other unreliable connections.=C2=A0

Thanks fo= r the feedback. Let me know how I can best join in the contribution.
<= div>
Best
Paul


--
Paul Fremantle
Doctoral= Researcher, University of Portsmouth, School of Computing
Visiti= ng Scientist,=C2=A0Institute of the Architecture of Application Systems, St= uttgart
Visiting Lecturer, Software Engineering Programme, Oxford= University
Co-Founder, WSO2
Apache M= ember and Committer
twitter: pzfreo / skype: paulfremantle / b= log: http://pzf.frem= antle.org
--089e0822b7b04945ca0551a8fbe0-- From nobody Sun Jun 11 22:46:51 2017 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 377FA129BF7 for ; Sun, 11 Jun 2017 22:46:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.401 X-Spam-Level: X-Spam-Status: No, score=-5.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, 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 G3ev6UzOPsEK for ; Sun, 11 Jun 2017 22:46:46 -0700 (PDT) Received: from se-out2.mx-wecloud.net (se-out2.mx-wecloud.net [89.221.255.177]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E6141276AF for ; Sun, 11 Jun 2017 22:46:46 -0700 (PDT) Received: from sp-mail-2.sp.se (unknown [194.218.146.197]) by se-out2.mx-wecloud.net (Postfix) with ESMTPS id B835622240E for ; Mon, 12 Jun 2017 05:46:42 +0000 (UTC) Received: from [192.168.0.166] (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_256_CBC_SHA384_P384) id 15.1.669.32; Mon, 12 Jun 2017 07:46:43 +0200 To: References: From: Ludwig Seitz Message-ID: <553642ab-c736-049d-41e0-1f9c81804e38@ri.se> Date: Mon, 12 Jun 2017 07:46:42 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.116.0.226] X-ClientProxiedBy: sp-mail-1.sp.se (10.100.0.161) To sp-mail-2.sp.se (10.100.0.162) X-CMAE-Score: 0 X-CMAE-Analysis: v=2.2 cv=Nc2W7yL4 c=1 sm=1 tr=0 a=L5DDne6A+dD0FbDkt2Fblw==:117 a=L5DDne6A+dD0FbDkt2Fblw==:17 a=sZ8rJzgPlrQA:10 a=IkcTkHD0fZMA:10 a=LWSFodeU3zMA:10 a=48vgC7mUAAAA:8 a=P1x8CNr21yRxr_jwE1wA:9 a=QEXdDO2ut3YA:10 a=w1C3t2QeGrPiZgrLijVG:22 X-Virus-Scanned: clamav-milter 0.99.2 at MailSecurity X-Virus-Status: Clean X-MailSecurity-Status: 0 X-Scanned-By: WeCloud MailSecurity X-MailSecurity-Score: 0 Archived-At: Subject: Re: [Ace] Comments on draft-sengul-ace-mqtt-tls-profile-00 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 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, 12 Jun 2017 05:46:49 -0000 On 2017-06-11 08:04, Paul Fremantle wrote: ~snip~ > This, as stated by Ludwig, was put in to support /authz-info of > ACE. It was to support the PoP keys to be used in TLS handshake > between the client and the broker. But yes, the MQTT server needs > to be resistant to DoS attempts pre-authorisation. MQTT needs to > resist DoS before and during CONNECT (TCP holding, excess data). > MQTT with /authz-info needs to implement similar resistance, for > example dropping connections that fail to authenticate in a timely > fashion, and blocking repeated offenders, so there's little > difference in theory - although resistance pre-CONNECT may already > exist in some broker implementations. A discussion can be put in > Security Considerations > > > I agree that a discussion of the pros and cons of this approach would be > valuable. I'm not clear on the benefits of using POP keys in TLS > handshakes. Can you please point me where to look? > The idea is to use the key used in the TLS handshake (e.g. the pre-shared key when an RFC 4279 handshake is used or the raw public key for a RFC 7250 handshake) as the POP key. This way the TLS handshake provides the proof of possession (for asymmetric keys you need to require client authentication). Have a look at https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-07 for more background on PoP. /Ludwig -- Ludwig Seitz, PhD Security Lab, RISE SICS Phone +46(0)70-349 92 51 From nobody Sun Jun 11 23:29:41 2017 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 4F0EC1289C3 for ; Sun, 11 Jun 2017 23:29:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.5 X-Spam-Level: X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=port.ac.uk 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 cQqnUKFvCdbq for ; Sun, 11 Jun 2017 23:29:38 -0700 (PDT) Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::229]) (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 14784126B72 for ; Sun, 11 Jun 2017 23:29:37 -0700 (PDT) Received: by mail-oi0-x229.google.com with SMTP id s3so48797556oia.0 for ; Sun, 11 Jun 2017 23:29:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=port.ac.uk; s=google-20130730; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc; bh=QdEwH2UnjpO4BpVMdLeDYPDH/KFnh3X/MRfBzqR8qeQ=; b=Aj13bNt+zXH1y7ln1+MTfQNcVPoa3Rmsg6LrSoaHCiEcrf/Eoqa8L+RW2a/9CLWevt /3IdJm6PvO4HZ3WFCI/2VVbm+Pu4G34Iz3aVa55pU3pFaWzQI8P0kKSNxgeqLEzG2P+K BwSuOWSNE8r0pgs2iXbPwVPMODZjbd59yq66Y= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc; bh=QdEwH2UnjpO4BpVMdLeDYPDH/KFnh3X/MRfBzqR8qeQ=; b=ZOjrTHBa4OG5JkXjCK3EasBEUTNc/l9mtbbWhsr6mEH1SxbaHl1lORI7WxFPSHAFRK 7bxpRMars9YfpSQUECIDZi1xZ1LFtPB4I1A8EdS0BOF1v0PiSh0aZvfsNeyHhxcHweIf h/qYaOluuPxbcfZTilc54w5ImWexc0a12zO36v3TwJBiYLHLoTRO/CL+30kyDOY5qV2M ULAmVGgpBzYV/OJ+pG9cJv4a/mEiaGL/x5xxY4tzv0SHAiiI9Gd97c/Su3iWqJ2pfJTI DEJIyaOuP9me97x3G/8OiLS8AtLBcmwMmzkOSyOjaId+P3cE2NAGs2O/FkDZFuZKb2tu 1hVA== X-Gm-Message-State: AODbwcDU5UEAcsTECMMvDc7+LYbC+Lyr1V2+Q0XJ/zRxt4VL9DfMrRIj IesEQcZQ6bY86MBKEz4= X-Received: by 10.202.206.212 with SMTP id e203mr16991305oig.206.1497248977120; Sun, 11 Jun 2017 23:29:37 -0700 (PDT) Received: from mail-ot0-f169.google.com (mail-ot0-f169.google.com. [74.125.82.169]) by smtp.gmail.com with ESMTPSA id i50sm4550695otd.43.2017.06.11.23.29.36 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 11 Jun 2017 23:29:36 -0700 (PDT) Received: by mail-ot0-f169.google.com with SMTP id t31so61615220ota.1 for ; Sun, 11 Jun 2017 23:29:36 -0700 (PDT) X-Received: by 10.157.56.91 with SMTP id r27mr26668943otd.235.1497248976092; Sun, 11 Jun 2017 23:29:36 -0700 (PDT) MIME-Version: 1.0 Reply-To: paul.fremantle@port.ac.uk Received: by 10.157.23.136 with HTTP; Sun, 11 Jun 2017 23:29:35 -0700 (PDT) Received: by 10.157.23.136 with HTTP; Sun, 11 Jun 2017 23:29:35 -0700 (PDT) In-Reply-To: <553642ab-c736-049d-41e0-1f9c81804e38@ri.se> References: <553642ab-c736-049d-41e0-1f9c81804e38@ri.se> From: Paul Fremantle Date: Mon, 12 Jun 2017 07:29:35 +0100 X-Gmail-Original-Message-ID: Message-ID: To: Ludwig Seitz Cc: ace@ietf.org Content-Type: multipart/alternative; boundary="001a114177ee5c48120551bd71cf" Archived-At: Subject: Re: [Ace] Comments on draft-sengul-ace-mqtt-tls-profile-00 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 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, 12 Jun 2017 06:29:40 -0000 --001a114177ee5c48120551bd71cf Content-Type: text/plain; charset="UTF-8" Thanks Ludwig. Paul On 12 Jun 2017 6:46 am, "Ludwig Seitz" wrote: > On 2017-06-11 08:04, Paul Fremantle wrote: > ~snip~ > >> This, as stated by Ludwig, was put in to support /authz-info of >> ACE. It was to support the PoP keys to be used in TLS handshake >> between the client and the broker. But yes, the MQTT server needs >> to be resistant to DoS attempts pre-authorisation. MQTT needs to >> resist DoS before and during CONNECT (TCP holding, excess data). >> MQTT with /authz-info needs to implement similar resistance, for >> example dropping connections that fail to authenticate in a timely >> fashion, and blocking repeated offenders, so there's little >> difference in theory - although resistance pre-CONNECT may already >> exist in some broker implementations. A discussion can be put in >> Security Considerations >> >> >> I agree that a discussion of the pros and cons of this approach would be >> valuable. I'm not clear on the benefits of using POP keys in TLS >> handshakes. Can you please point me where to look? >> >> > The idea is to use the key used in the TLS handshake (e.g. the pre-shared > key when an RFC 4279 handshake is used or the raw public key for a RFC 7250 > handshake) as the POP key. > This way the TLS handshake provides the proof of possession (for > asymmetric keys you need to require client authentication). > > Have a look at https://tools.ietf.org/html/dr > aft-ietf-oauth-pop-architecture-07 for more background on PoP. > > /Ludwig > > > -- > Ludwig Seitz, PhD > Security Lab, RISE SICS > Phone +46(0)70-349 92 51 > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > --001a114177ee5c48120551bd71cf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Ludwig.

Paul

On 12 Jun 2017 6:46 am, "Ludwig Seitz" <ludwig.seitz@ri.se> wrote:
On 2017-06-11 08:04, Paul Fremantle wrote:<= br> ~snip~
=C2=A0 =C2=A0 This, as stated by Ludwig, was put in to support /authz-info = of
=C2=A0 =C2=A0 ACE.=C2=A0 It was to support the PoP keys to be used in TLS h= andshake
=C2=A0 =C2=A0 between the client=C2=A0 and the broker.=C2=A0 But yes, the M= QTT server needs
=C2=A0 =C2=A0 to be resistant to DoS attempts pre-authorisation. MQTT needs= to
=C2=A0 =C2=A0 resist DoS before and during CONNECT (TCP holding, excess dat= a).
=C2=A0 =C2=A0 MQTT with /authz-info needs to implement similar resistance, = for
=C2=A0 =C2=A0 example dropping connections that fail to authenticate in a t= imely
=C2=A0 =C2=A0 fashion, and blocking repeated offenders, so there's litt= le
=C2=A0 =C2=A0 difference in theory - although resistance pre-CONNECT may al= ready
=C2=A0 =C2=A0 exist in some broker implementations.=C2=A0 A discussion can = be put in
=C2=A0 =C2=A0 Security Considerations


I agree that a discussion of the pros and cons of this approach would be va= luable. I'm not clear on the benefits of using POP keys in TLS handshak= es. Can you please point me where to look?


The idea is to use the key used in the TLS handshake (e.g. the pre-shared k= ey when an RFC 4279 handshake is used or the raw public key for a RFC 7250 = handshake) as the POP key.
This way the TLS handshake provides the proof of possession (for asymmetric= keys you need to require client authentication).

Have a look at https://tools.ietf.or= g/html/draft-ietf-oauth-pop-architecture-07 for more backgrou= nd on PoP.

/Ludwig


--
Ludwig Seitz, PhD
Security Lab, RISE SICS
Phone +46(0)70-349 92 51

_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
--001a114177ee5c48120551bd71cf-- From nobody Mon Jun 12 03:43:01 2017 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 77ED91294F3 for ; Mon, 12 Jun 2017 03:42:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 sK7CcumNbh0j for ; Mon, 12 Jun 2017 03:42:57 -0700 (PDT) Received: from lb3-smtp-cloud2.xs4all.net (lb3-smtp-cloud2.xs4all.net [194.109.24.29]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 493E21294D8 for ; Mon, 12 Jun 2017 03:42:56 -0700 (PDT) Received: from webmail.xs4all.nl ([IPv6:2001:888:0:22:194:109:20:199]) by smtp-cloud2.xs4all.net with ESMTP id Xmit1v00W4qMJlQ01mitVj; Mon, 12 Jun 2017 12:42:54 +0200 Received: from AMontpellier-654-1-119-36.w90-0.abo.wanadoo.fr ([90.0.134.36]) by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Mon, 12 Jun 2017 12:42:53 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 12 Jun 2017 12:42:53 +0200 From: peter van der Stok To: ace@ietf.org, anima@ietf.org Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <149726370019.10357.2434726817483988279.idtracker@ietfa.amsl.com> References: <149726370019.10357.2434726817483988279.idtracker@ietfa.amsl.com> Message-ID: <1da3b214e4be22e843701e1694b29954@xs4all.nl> X-Sender: stokcons@xs4all.nl User-Agent: XS4ALL Webmail Archived-At: Subject: [Ace] Fwd: New Version Notification for draft-vanderstok-ace-coap-est-02.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 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, 12 Jun 2017 10:42:59 -0000 Dear all, A new version of est-coaps draft has been submitted to the ACE working group. Apart from many editorial changes, this version includes: - a first security considerations section - a section about http/coap proxying - DTLS Proof of possession has been clarified - discovery of content formats - better link with text of anima keyinfra draft. We hope that the ACE WG likes this work and may consider promoting this draft to a WG document. Greetings peter -------- Oorspronkelijke bericht -------- Onderwerp: New Version Notification for draft-vanderstok-ace-coap-est-02.txt Datum: 2017-06-12 12:35 Afzender: internet-drafts@ietf.org Ontvanger: "Panos Kampanakis" , "Sandeep S. Kumar" , "Sandeep Kumar" , "Peter Van der Stok" , "Peter van der Stok" , "Martin Furuhed" , "Shahid Raza" A new version of I-D, draft-vanderstok-ace-coap-est-02.txt has been successfully submitted by Peter van der Stok and posted to the IETF repository. Name: draft-vanderstok-ace-coap-est Revision: 02 Title: EST over secure CoAP (EST-coaps) Document date: 2017-06-12 Group: Individual Submission Pages: 37 URL: https://www.ietf.org/internet-drafts/draft-vanderstok-ace-coap-est-02.txt Status: https://datatracker.ietf.org/doc/draft-vanderstok-ace-coap-est/ Htmlized: https://tools.ietf.org/html/draft-vanderstok-ace-coap-est-02 Htmlized: https://datatracker.ietf.org/doc/html/draft-vanderstok-ace-coap-est-02 Diff: https://www.ietf.org/rfcdiff?url2=draft-vanderstok-ace-coap-est-02 Abstract: Low-resource devices in a Low-power and Lossy Network (LLN) can operate in a mesh network using the IPv6 over Low-power Wireless Personal Area Networks (6LoWPAN) and IEEE 802.15.4 link-layer standards. Provisioning these devices in a secure manner with keys (often called secure bootstrapping) used to encrypt and authenticate messages, is the subject of Bootstrapping of Remote Secure Key Infrastructures (BRSKI) [I-D.ietf-anima-bootstrapping-keyinfra] and 6tisch Secure Join [I-D.ietf-6tisch-dtsecurity-secure-join]. Enrollment over Secure Transport (EST) [RFC7030], based on TLS and HTTP, is used in BRSKI. Low-resource devices often use the lightweight Constrained Application Protocol (CoAP) [RFC7252] for message exchanges. This document defines how low-resource devices are expected to use EST over secure CoAP (EST-coaps) for secure bootstrapping and certificate enrollment. 6LoWPAN fragmentation management and extensions to CoAP registries are needed to enable EST-coaps. 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 From nobody Mon Jun 12 11:19:29 2017 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 2488012EB4F for ; Mon, 12 Jun 2017 11:19:28 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 ZIZvC5V9Wbyt for ; Mon, 12 Jun 2017 11:19:26 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (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 A653012969E for ; Mon, 12 Jun 2017 11:19:25 -0700 (PDT) Received: from [192.168.91.196] ([80.92.114.129]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MV1wf-1dLnez3aX7-00YQRx; Mon, 12 Jun 2017 20:19:17 +0200 To: "Ace@ietf.org" From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Cc: Hannes Tschofenig , Kepeng Li Message-ID: <3675935b-c09d-8b34-c439-b0c5405a00d5@gmx.net> Date: Mon, 12 Jun 2017 20:19:15 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:jiZ5KlZzZVgQKt3GimNQLNf0yWELc8TxUUwnUykVS3fiRwMtcmF Csl5oKUhxryJb6CsSCbdxgMkUNzm+x/iKDtvyjhzCZmzLdwVJm2DYAEFQFclIdq+rpozaQ9 2g3Q6c8xlqz5WRn8LFLDn644Ixptcb5fKNglF3tEZIKO+3FWpX7mdnrTBBLrJfdoRiVJ0KR MIP4np1/ExBu2fT/m1mMA== X-UI-Out-Filterresults: notjunk:1;V01:K0:PVugMi9ggB4=:E1tuLz6Emxr+t8z73Xsf4G sigw5d32kHcyiE7wPNNkgq+tBQONhKgsa8OIfOu4VpuTnEm4s+xI9oDovLL7rsyhibRJ8xkpS 0BEcpX37hzMeOAT5BlvyrLzyLcYs30vOBU9e1dGXdxpjgbQbpuk5EbCRlm44xGdnBCdYGtHrO OiSxyS+oSRzHBdNVEUFiJonUy2g4KmE4H+Po20Po7uoyqEpFpnOQLI3GGv+Gngw3/CbIVC1TY GDt+fsDDo3FjKCjiS8jPC9mAByQxn7gx6SsPXO6L66v9dOCGiO8FJeYB4lj4Ug4/NYNHluloD ullefPHFgWSYcPH3VWKSzasXLY6Lq5RcPFku2TmvvSoJTiplWK9sSD0jCWJmW6qQl30jdYXJo tiicuilpVeTBFZ3Y4RFzGqVygVxOW7hrbH97zLtSs65Ll89hIB9eeUeRek0U+I/9EsUeArhGz rVl6saqEhQZ7lgFW8NzNEoUCGIcEi84a8u0uQ0Kt74qPhJj8FZpxs0qIa9k3t7FtcJatg9pMF PBqCokdvi0lE8vWfSb+1JQ1D69kvwPEhtlcDyHAMlmxSNeUImMFkHau9AXrbQb7p9JDuanGpC veqTh25lAPMjgkyxk7krLKAOlJzl/Ko9veSDdY6rmtg9qyjbZFZXAYFoHOTLkDdiMNEfvX0s5 ExsKQ5gLJy2ZutFwkeQDHTdOtoLKwe4EKDVfIaL/pR5hFrpfNs5mmuFLH7ruepg+cJNOaQ5pk qNCF3kChV6g8XMYUfQEdgaUsWzfgGVvv0iFu2oGXubbgLJoPtWZb3QB4IxgCt3Ols7zOVZ0GZ UYeKVXT Archived-At: Subject: [Ace] Potential uses of PoP keys in CBOR Web Tokens (CWTs) X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 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, 12 Jun 2017 18:19:28 -0000 Hi all, RFC 7800 defines how to communicate Proof of Possession (PoP) keys for JSON Web Tokens (JWTs) [RFC 7519]. The CBOR Web Token (CWT) draft-ietf-ace-cbor-web-token spec defines the CBOR/COSE equivalent of the JSON/JOSE JWT spec. The ACE working group is planning to also define a CBOR/COSE equivalent of RFC 7800 and is interested in knowing how you might use CBOR proof-of-possession keys for CWTs. Please drop us a message if you are using CBOR PoP keys for CWTs. We would like to learn more about your usage. Ciao Hannes & Kepeng From nobody Mon Jun 12 14:03:49 2017 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 83E631296CF for ; Mon, 12 Jun 2017 14:03:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 kG3wQmEduFMd for ; Mon, 12 Jun 2017 14:03:45 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0111.outbound.protection.outlook.com [104.47.38.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAE1A129AB8 for ; Mon, 12 Jun 2017 14:03:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=UVRYPtEZUWru/KtTKC9t2EKRjue1x3SU3FVhvQpjnV4=; b=bUlskwSPsCVSRe/kCbLfgrB303q3aKIzQSQi4CRga8E6WkgVv+jyNKCY+cz3cCnwopMQpj2aRum3D0sxTgOJK6Vk9CxvJFL4vsHYYIFb9lkI8rPD6S8RvVve14xVTxOpypOXWOJ68wNqqZWINi6hzp+8Hxgp4PeOjzXTNNJcuPs= Received: from SN1PR0301MB2029.namprd03.prod.outlook.com (10.163.226.27) by SN1PR0301MB2031.namprd03.prod.outlook.com (10.163.226.29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1157.12; Mon, 12 Jun 2017 21:03:42 +0000 Received: from SN1PR0301MB2029.namprd03.prod.outlook.com ([10.163.226.27]) by SN1PR0301MB2029.namprd03.prod.outlook.com ([10.163.226.27]) with mapi id 15.01.1157.017; Mon, 12 Jun 2017 21:03:42 +0000 From: Anthony Nadalin To: Hannes Tschofenig , "Ace@ietf.org" CC: Hannes Tschofenig , Kepeng Li Thread-Topic: [Ace] Potential uses of PoP keys in CBOR Web Tokens (CWTs) Thread-Index: AQHS46hy2P5cN4m07Eypw54/l/kxrqIhti+A Date: Mon, 12 Jun 2017 21:03:42 +0000 Message-ID: References: <3675935b-c09d-8b34-c439-b0c5405a00d5@gmx.net> In-Reply-To: <3675935b-c09d-8b34-c439-b0c5405a00d5@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Ref=https://api.informationprotection.azure.com/api/72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetBy=tonynad@microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2017-06-12T14:03:37.7220045-07:00; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic; Sensitivity=General authentication-results: gmx.net; dkim=none (message not signed) header.d=none;gmx.net; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:4898:80e8:f::61c] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; SN1PR0301MB2031; 7:emUbRrQDyFF8dTuMqHnwDpLEW4WkAJUcB3WCDZZk/Hx6dyrvB9bZBqGtGw/0Ze1YD89el21gbA7zKCYdm86W1fIWr4bhuZmoqkDHMdZXNxpnuib2W5eEBm7uCtrTRKk9KpMIpTxJJrMqCGTKbnfO9OGi5aDDRlh0TKATWe9y7QVMvBISK/cWRliacgRVcHBGEMh/+U28C7drIpaoTcHWAnUFADKzisnlOZ0DOflsc+jRIUMeCz014dwrGFj1ppFa9DS5HjBgVw/GAnUl/0c/HDu61fgU2qz2FbxOwVNQ8x6fP9QEZ5VJX5tD8eyywLnbcLYaDG4sAdohcKy44mNGHdn4VOyFc3/cWE8gNmka16c= x-ld-processed: 72f988bf-86f1-41af-91ab-2d7cd011db47,ExtAddr x-ms-traffictypediagnostic: SN1PR0301MB2031: x-ms-office365-filtering-correlation-id: 514cc0bb-1016-4f04-2e20-08d4b1d681b7 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:SN1PR0301MB2031; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(180628864354917)(189930954265078)(219752817060721); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(601004)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(10201501046)(3002001)(93006095)(93001095)(6055026)(61426038)(61427038)(6041248)(20161123562025)(20161123560025)(20161123555025)(201703131423075)(201703061421075)(201703161042150)(20161123558100)(20161123564025)(6072148)(6042181)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:SN1PR0301MB2031; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:SN1PR0301MB2031; x-forefront-prvs: 03361FCC43 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(53754006)(377454003)(13464003)(33656002)(2950100002)(7696004)(5660300001)(10090500001)(5005710100001)(2501003)(2906002)(3280700002)(8990500004)(8936002)(102836003)(86362001)(53546009)(3660700001)(25786009)(4326008)(575784001)(966005)(14454004)(86612001)(189998001)(122556002)(8676002)(81166006)(77096006)(74316002)(305945005)(229853002)(2900100001)(6436002)(54906002)(7736002)(50986999)(54356999)(76176999)(10290500003)(55016002)(6306002)(9686003)(38730400002)(99286003)(53936002)(6506006)(498600001)(6246003)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR0301MB2031; H:SN1PR0301MB2029.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jun 2017 21:03:42.1494 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0301MB2031 Archived-At: Subject: Re: [Ace] Potential uses of PoP keys in CBOR Web Tokens (CWTs) X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 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, 12 Jun 2017 21:03:48 -0000 So I believe that there are other uses for this technology, for instance he= re at Microsoft we have "compact tokens" and looking forward to using CWT a= nd POP as a standard instead of what we have created. FIDO also has a use c= ase for CWT and POP for the Client to Authenticator Protocol, which uses CB= OR and CWT today. I think it makes sense to define POP for CWT in it's own = specification as there will be many stand-alone usages for POP for CWT. -----Original Message----- From: Ace [mailto:ace-bounces@ietf.org] On Behalf Of Hannes Tschofenig Sent: Monday, June 12, 2017 11:19 AM To: Ace@ietf.org Cc: Hannes Tschofenig ; Kepeng Li Subject: [Ace] Potential uses of PoP keys in CBOR Web Tokens (CWTs) Hi all, RFC 7800 defines how to communicate Proof of Possession (PoP) keys for JSON= Web Tokens (JWTs) [RFC 7519]. The CBOR Web Token (CWT) draft-ietf-ace-cbor= -web-token spec defines the CBOR/COSE equivalent of the JSON/JOSE JWT spec. The ACE working group is planning to also define a CBOR/COSE equivalent of = RFC 7800 and is interested in knowing how you might use CBOR proof-of-posse= ssion keys for CWTs. Please drop us a message if you are using CBOR PoP keys for CWTs. We would = like to learn more about your usage. Ciao Hannes & Kepeng _______________________________________________ Ace mailing list Ace@ietf.org https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.ietf= .org%2Fmailman%2Flistinfo%2Face&data=3D02%7C01%7Ctonynad%40microsoft.com%7C= 0f499d2726c74f8c11ab08d4b1bf922f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0= %7C636328883729061751&sdata=3DhxYGYRTqzC1qIEo4efvJdc%2B99GRldim68GwELwGIc8M= %3D&reserved=3D0 From nobody Mon Jun 12 14:11:35 2017 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 9FA3F129ACD for ; Mon, 12 Jun 2017 14:11:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 M20aIW9Ee9cX for ; Mon, 12 Jun 2017 14:11:31 -0700 (PDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0134.outbound.protection.outlook.com [104.47.40.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19720129ABE for ; Mon, 12 Jun 2017 14:11:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Kk75K0rzTa1I3ETBwkAOJJohwJCbqBWzb9dYN8MurU0=; b=kWK7okfDJRiNWg8KiW2oAwNab+ThgfrajNJArRzmC0/S+Y6S2/BoGT2V0qO8X7h1DFXNEBgoL3lrp2wioyAIeC9h77cnp98r0GhP++Bv+TN3VXamwOkPbynACeDDwjd1reWlxPXSEKTTHKX9lpEFZchIJaifthQyQmxGhDAmpq4= Received: from CY4PR21MB0504.namprd21.prod.outlook.com (10.172.122.14) by CY4PR21MB0117.namprd21.prod.outlook.com (10.173.189.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1199.3; Mon, 12 Jun 2017 21:11:29 +0000 Received: from CY4PR21MB0504.namprd21.prod.outlook.com ([10.172.122.14]) by CY4PR21MB0504.namprd21.prod.outlook.com ([10.172.122.14]) with mapi id 15.01.1178.008; Mon, 12 Jun 2017 21:11:28 +0000 From: Mike Jones To: Anthony Nadalin , Hannes Tschofenig , "Ace@ietf.org" CC: Hannes Tschofenig , Kepeng Li Thread-Topic: [Ace] Potential uses of PoP keys in CBOR Web Tokens (CWTs) Thread-Index: AQHS46hxzpvVMmEHjUeQedvH7vt1b6Iht20AgAABseA= Date: Mon, 12 Jun 2017 21:11:27 +0000 Message-ID: References: <3675935b-c09d-8b34-c439-b0c5405a00d5@gmx.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Ref=https://api.informationprotection.azure.com/api/72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetBy=tonynad@microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2017-06-12T14:03:37.7220045-07:00; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic; Sensitivity=General authentication-results: microsoft.com; dkim=none (message not signed) header.d=none;microsoft.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:4898:80e8:d::36] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR21MB0117; 7:YFrZeJ7Br28s/+2ws4A2h67UmEHDtZdsnfwIGlaEbpa31yV7Ur0+0jJr5/qeBEM3ILD9GJl0ruDde6mbvyfVFXwiZ+Yky/LD9CcK3VEDZWvZAMMOMb3Y2v6anawkPxTVamKDyeyhtu4OfMxr8KBM3OHwmXDwtXvvaSgOtroVDjo7ZSuzy3QeOdheK/vrMIVZXQ4AmIdR3CD8EcCQn9tv7dlynj5Iyj/ykLAeq4yJqSidzSVA5Yj+D1akxFbaQn9AI5cqkMeIYkAAWmRacaQP9VUHjJQVhsa0Fe0r8TamrjXEhj1oda58sWYMUo6DDOYTzRZZnc4Xp+UU0Ah3p4gvMuHKLdxMHitdbvcI0H+x/owQ73BvWN5vzFFOU+c34sVnQyJsPEkON4QDz7DAtFloG8b2mV4CP4l9KIe8oeCy+THlS2GCH1fMPL6D7jVcgP2WBu5in1REOz5HUZxKKEgZwBI1Vxgqx9Oy6ueLzGyIIJ1kGnbcd80+rRDYibMOYIBHuqTYeF4xN0mgTceLHwlHwrUEkKfwglq5GdoWwARw/IRHuaE91o9k5uRss6Kf2NxyN1WXiJm/fe5E3MrsLX9hpApv8s+tm/mc2uKbIEWpYZCp/i3X4aBcCSmx0GuKkMfq6xISm8HAMUNCI/NMno6iKFl/7weohWQ9cTiiZUijvUAxQYi/w3VV7NM+wXy8CIgBgt3LHlrntciqHm8LaElgOGZieVhsDgPWD3zlBZlHdKMSvfcKFGFvckcjkRQqbS3eqLVZXkDm5bWaFmACqrfopB+RJkJyScABQvYCVDU8OTGHdiJbZ+ukAY8YgnaVdQlU x-ld-processed: 72f988bf-86f1-41af-91ab-2d7cd011db47,ExtAddr x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10019020)(6009001)(39840400002)(39400400002)(39850400002)(39410400002)(39860400002)(39450400003)(377454003)(53754006)(13464003)(229853002)(72206003)(86612001)(575784001)(8990500004)(6436002)(6506006)(966005)(122556002)(86362001)(10090500001)(1511001)(5005710100001)(10290500003)(3280700002)(478600001)(3660700001)(2906002)(102836003)(14454004)(2950100002)(305945005)(6246003)(7736002)(54356999)(76176999)(50986999)(7696004)(38730400002)(81166006)(33656002)(9686003)(8676002)(2561002)(8936002)(55016002)(189998001)(6306002)(54906002)(99286003)(25786009)(2900100001)(53546009)(77096006)(74316002)(4326008)(53936002)(5660300001)(2501003); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0117; H:CY4PR21MB0504.namprd21.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-ms-office365-filtering-correlation-id: 4100b624-2de5-4712-5392-08d4b1d797a3 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081)(201702281549075); SRVR:CY4PR21MB0117; x-ms-traffictypediagnostic: CY4PR21MB0117: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(180628864354917)(189930954265078)(248736688235697)(219752817060721); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(601004)(2401047)(5005006)(8121501046)(10201501046)(100000703101)(100105400095)(3002001)(93006095)(93001095)(6055026)(61426038)(61427038)(6041248)(20161123560025)(20161123555025)(20161123564025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR21MB0117; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR21MB0117; x-forefront-prvs: 03361FCC43 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jun 2017 21:11:28.4980 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0117 Archived-At: Subject: Re: [Ace] Potential uses of PoP keys in CBOR Web Tokens (CWTs) X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 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, 12 Jun 2017 21:11:34 -0000 I'll add to this that if the FIDO 2.0 Client to Authenticator Protocol (CTA= P) spec uses this PoP key representation, one of the callers of this will b= e implementations of the W3C WebAuthn specification. -----Original Message----- From: Ace [mailto:ace-bounces@ietf.org] On Behalf Of Anthony Nadalin Sent: Monday, June 12, 2017 2:04 PM To: Hannes Tschofenig ; Ace@ietf.org Cc: Hannes Tschofenig ; Kepeng Li Subject: Re: [Ace] Potential uses of PoP keys in CBOR Web Tokens (CWTs) So I believe that there are other uses for this technology, for instance he= re at Microsoft we have "compact tokens" and looking forward to using CWT a= nd POP as a standard instead of what we have created. FIDO also has a use c= ase for CWT and POP for the Client to Authenticator Protocol, which uses CB= OR and CWT today. I think it makes sense to define POP for CWT in it's own = specification as there will be many stand-alone usages for POP for CWT. -----Original Message----- From: Ace [mailto:ace-bounces@ietf.org] On Behalf Of Hannes Tschofenig Sent: Monday, June 12, 2017 11:19 AM To: Ace@ietf.org Cc: Hannes Tschofenig ; Kepeng Li Subject: [Ace] Potential uses of PoP keys in CBOR Web Tokens (CWTs) Hi all, RFC 7800 defines how to communicate Proof of Possession (PoP) keys for JSON= Web Tokens (JWTs) [RFC 7519]. The CBOR Web Token (CWT) draft-ietf-ace-cbor= -web-token spec defines the CBOR/COSE equivalent of the JSON/JOSE JWT spec. The ACE working group is planning to also define a CBOR/COSE equivalent of = RFC 7800 and is interested in knowing how you might use CBOR proof-of-posse= ssion keys for CWTs. Please drop us a message if you are using CBOR PoP keys for CWTs. We would = like to learn more about your usage. Ciao Hannes & Kepeng _______________________________________________ Ace mailing list Ace@ietf.org https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.ietf= .org%2Fmailman%2Flistinfo%2Face&data=3D02%7C01%7Ctonynad%40microsoft.com%7C= 0f499d2726c74f8c11ab08d4b1bf922f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0= %7C636328883729061751&sdata=3DhxYGYRTqzC1qIEo4efvJdc%2B99GRldim68GwELwGIc8M= %3D&reserved=3D0 _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace From nobody Fri Jun 16 16:56:38 2017 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 AB520129540; Fri, 16 Jun 2017 16:56:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 nM8JdYlIWS9x; Fri, 16 Jun 2017 16:56:35 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (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 CB18F12953F; Fri, 16 Jun 2017 16:56:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v5GNuUVG003810; Sat, 17 Jun 2017 01:56:30 +0200 (CEST) Received: from [192.168.217.124] (p5DC7F3A7.dip0.t-ipconnect.de [93.199.243.167]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3wqHMd617KzDK04; Sat, 17 Jun 2017 01:56:29 +0200 (CEST) From: Carsten Bormann Content-Type: text/plain; charset=utf-8 X-Mao-Original-Outgoing-Id: 519350189.453979-e3b2d906e8bab442948f66a848a5cc63 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Sat, 17 Jun 2017 01:56:29 +0200 Message-Id: <2DB0474F-900D-42FD-B2C5-F61F396B751C@tzi.org> To: ace , core , cose , cbor@ietf.org, t2trg@irtf.org X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [Ace] Constrained Node/Network Cluster @ IETF99: DRAFT AGENDA X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 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, 16 Jun 2017 23:56:37 -0000 Here is my usual eclectic condensed agenda based on the DRAFT AGENDA for IETF99. Remember that there is still quite some potential for changes. ACE people are going to miss DISPATCH (ARTAREA) again -- not sure if there would have been be any discussions relevant to Constrained Nodes/Networks in ARTAREA, but it doesn't make sense with this scheduling. CORE people will miss both ANIMA and (in-week) ICNRG. ROLL people will miss SAAG, ouch. And LPWAN is on the second half of QUIC. All no disasters, AFAICS, but not pain-free. All times are CEST (UTC+0200). (You can get pure UTC times on https://datatracker.ietf.org/meeting/agenda-utc, for those who want to listen from remote.) Gr=C3=BC=C3=9Fe, Carsten SATURDAY/SUNDAY -- T2TRG -- ICNRG -- Hackathon (including various interops) MONDAY, July 17, 2017 0930-1200 Morning Session I Congress H III ART dispatch Dispatch WG - 09:30-11:30 Grand Hilton BR INT 6man IPv6 Maintenance WG Congress H I SEC *** ace Authentication and Authorization for = Constrained Environments WG Congress H III SEC curdle CURves, Deprecating and a Little more = Encryption WG - 11:30-12:00 1330-1530 Afternoon Session I Karlin I/II INT *** 6tisch IPv6 over the TSCH mode of IEEE = 802.15.4e WG Grand Hilton BR INT homenet Home Networking WG 1550-1720 Afternoon Session II Karlin I/II ART *** cbor Concise Binary Object Representation = Maintenance and Extensions WG Berlin/Brussels SEC tokbind Token Binding WG 1740-1840 Afternoon Session III Athens/Barcel. RTG babel Babel routing protocol WG Grand Hilton BR TSV tsvarea Transport Area Open Meeting TUESDAY, July 18, 2017 0930-1200 Morning Session I Congress H II OPS v6ops IPv6 Operations WG Congress H I TSV taps Transport Services WG 1330-1530 Afternoon Session I Grand Hilton BR IRTF*** t2trg Thing-to-Thing Berlin/Brussels SEC oauth Web Authorization Protocol WG Congress H I TSV tsvwg Transport Area Working Group WG 1550-1750 Afternoon Session II Karlin I/II INT *** 6lo IPv6 over Networks of = Resource-constrained Nodes WG Congress H I IRTF cfrg Crypto Forum WEDNESDAY, July 19, 2017 0930-1200 Morning Session I Congress H I ART *** core Constrained RESTful Environments WG Karlin I/II IRTF icnrg Information-Centric Networking Congress H III OPS anima Autonomic Networking Integrated Model = and Approach WG Congress H II RTG rtgarea Routing Area Open Meeting Grand Hilton BR SEC tls Transport Layer Security WG Karlin III TSV rmcat RTP Media Congestion Avoidance = Techniques WG 1330-1500 Afternoon Session I Grand Hilton BR ART httpbis Hypertext Transfer Protocol WG Congress H III IRTF panrg Proposed Path Aware Networking Congress H II RTG ideas IDentity Enabled Networks BOF 1520-1650 Afternoon Session II Grand Hilton BR ART httpbis Hypertext Transfer Protocol WG THURSDAY, July 20, 2017 0930-1200 Morning Session I Grand Hilton BR INT intarea Internet Area Working Group WG Congress H II IRTF maprg Measurement and Analysis for Protocols Congress H I RTG detnet Deterministic Networking WG 1330-1530 Afternoon Session I Berlin/Brussels ART ice Interactive Connectivity Establishment = WG Grand Hilton BR OPS v6ops IPv6 Operations WG Karlin I/II RTG *** roll Routing Over Low power and Lossy = networks WG Congress H III SEC saag Security Area Open Meeting 1550-1750 Afternoon Session II Athens/Barcel. INT ipwave IP Wireless Access in Vehicular = Environments WG Grand Hilton BR TSV quic QUIC WG 1810-1910 Afternoon Session III Berlin/Brussels ART uta Using TLS in Applications WG Athens/Barcel. INT *** lwig Light-Weight Implementation Guidance WG Karlin I/II RTG bier Bit Indexed Explicit Replication WG Congress H III TSV tsvwg Transport Area Working Group WG FRIDAY, July 21, 2017 0930-1130 Morning Session I Berlin/Brussels INT dnssd Extensions for Scalable DNS Service = Discovery WG Karlin I/II INT *** lpwan IPv6 over Low Power Wide-Area Networks = WG Karlin III SEC oauth Web Authorization Protocol WG Grand Hilton BR TSV quic QUIC WG 1150-1320 Afternoon Session II Congress H III ART *** core Constrained RESTful Environments WG Grand Hilton BR SEC acme Automated Certificate Management = Environment WG From nobody Sun Jun 18 12:21:47 2017 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 ABDA81294C9; Sun, 18 Jun 2017 12:21:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=augustcellars.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 y2ETgrHde96t; Sun, 18 Jun 2017 12:21:43 -0700 (PDT) Received: from mail4.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 75B141294C8; Sun, 18 Jun 2017 12:21:43 -0700 (PDT) Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1497813692; h=from:subject:to:date:message-id; bh=E0f821iTFNCsAjMZzyUaSJ/T8k9hV73631uR3sFcaIg=; b=fiYHY3uTjIdTv51fHbGfZHXQ3qYxbB10lSlYjNWoOSNp7v4CUBJE0ts/ZbhAKQvcUqhYl8imgT6 CT9d6cJ3DG6iiNo9jq2q4EMSJe3o7WX47W4dEa1WNijbp/Mh1mFPZGu7iK7Np1CdmBhnYe6lnVoDB 2XUNWtXz6CFgf+JWJO7bmQmR8X+YxX8v8lVTyx7mbQ0y07VYGfCDEGg6L/3REoacI9hRGSCS4UdOZ y0ITqeXfJtKl+rtgSye23MB0+/1viMlYBJ353Z+A0UfrkD+RxzJ+XCNPHt1t/Zmo54zXzHXzdPmLG C65q9Js0IyQVsAC2RljvpZpo6Tagye+LB+Rw== Received: from mail2.augustcellars.com (192.168.1.201) by mail4.augustcellars.com (192.168.1.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Sun, 18 Jun 2017 12:21:31 -0700 Received: from Hebrews (24.21.96.37) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Sun, 18 Jun 2017 12:20:58 -0700 From: Jim Schaad To: CC: References: <149671239411.3941.12998153965739248286@ietfa.amsl.com> In-Reply-To: <149671239411.3941.12998153965739248286@ietfa.amsl.com> Date: Sun, 18 Jun 2017 12:21:28 -0700 Message-ID: <006101d2e868$17c8e3d0$475aab70$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQIaEBRr5jC1xCcXZVQxVO5bX+OccqGVQkRg X-Originating-IP: [24.21.96.37] Archived-At: Subject: Re: [Ace] I-D Action: draft-ietf-ace-cbor-web-token-05.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 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: Sun, 18 Jun 2017 19:21:46 -0000 Comments on this version of the draft. Section 7 - Step 6 & 7 - I do not know if it is legal to have a CWT CBOR = tag at this point Section 7 - In Step 7 - it must be a valid CBOR map not just a valid = CBOR object. Appendix A.3 - I was unable to reproduce the example. I assume that = this means that a deterministic signature algorithm is not being used. = While a verifier cannot tell if one is being used, the COSE document = does strongly suggest that one be used. Additionally, it helps in = testing if one is used so that a signature creator can be more easily = tested. Appendix A.5 - I was unable to reproduce the example. Specially the tag = value does not match with the one that I compute. Appendix A.6 - I did not try to reproduce given that a) I would not = generate the same signature and b) the example A.5 failed. Minor: In section 1.1 s/In COSE/In CBOR/ - this is a comment on CBOR not on = COSE In section 2: s/CBOR encoded claim key/CBOR claim key/ =20 * I am unsure why you would think that encoded is needed here.=20 * Should this be CWT rather than CBOR? * Why is section 3.1 "Claim Names" rather than "Claim Keys" In section 2: Is there a reason not to define CWT claim value in this = section In section 3.1.1 and on - the following might be considered cleaner = s/except that the format MUST be a/except that the value MUST be of = type/ Section 9.1.2 - I would suggest assigning a name to the reserved entry -----Original Message----- From: Ace [mailto:ace-bounces@ietf.org] On Behalf Of = internet-drafts@ietf.org Sent: Monday, June 5, 2017 6:27 PM To: i-d-announce@ietf.org Cc: ace@ietf.org Subject: [Ace] I-D Action: draft-ietf-ace-cbor-web-token-05.txt 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 of the IETF. Title : CBOR Web Token (CWT) Authors : Michael B. Jones Erik Wahlstr=C3=B6m Samuel Erdtman Hannes Tschofenig Filename : draft-ietf-ace-cbor-web-token-05.txt Pages : 23 Date : 2017-06-05 Abstract: CBOR Web Token (CWT) is a compact means of representing claims to be transferred between two parties. The claims in a CWT are encoded in the Concise Binary Object Representation (CBOR) and CBOR Object Signing and Encryption (COSE) is used for added application layer security protection. A claim is a piece of information asserted about a subject and is represented as a name/value pair consisting of a claim name and a claim value. CWT is derived from JSON Web Token (JWT), but uses CBOR rather than JSON. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ace-cbor-web-token/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ace-cbor-web-token-05 https://datatracker.ietf.org/doc/html/draft-ietf-ace-cbor-web-token-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ace-cbor-web-token-05 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/ _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace From nobody Mon Jun 19 06:11:31 2017 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 D541A129451 for ; Mon, 19 Jun 2017 06:11:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, 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 N9FVzASgM2rH for ; Mon, 19 Jun 2017 06:11:27 -0700 (PDT) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (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 4F23E12EC16 for ; Mon, 19 Jun 2017 06:11:27 -0700 (PDT) Received: by mail-qk0-x22c.google.com with SMTP id d14so32696803qkb.1 for ; Mon, 19 Jun 2017 06:11:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=uZYgOw4Z/j9CktopyUEvWRNcJ3mmb4mb96NBVpSpoOA=; b=RJN94WNduuA8hS9lHhDWbHhWEzMEGnQzipBK77rH2EtvtahmyeeCqW7clQhdCj6WcE ALJa+h3oCjfe3RgRgb3tkIWkucyEq+gYlw6dl69vTW7wZZRWUxYeRbEXJMJ4ATpzb0Vi vpgr5joztPJA2ApvJiJjVH22k9eB8JAeo4y8KqW14HoaF2Ade6/OmuCXShZ4ZfvH4v2W MtLBv036jpi/skqs1OCPBthOO1maWwkjoYG4HB9q7qGJgtUp1yJ7PAhiGWFWTQOjLu8c 6dItgfCvbZaEsI/tfhpIC5FunzyZtT/Z5yiWmU87mwSiTRqpq2lzBbH8fhODMixhcG+0 2Hyg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=uZYgOw4Z/j9CktopyUEvWRNcJ3mmb4mb96NBVpSpoOA=; b=PETqWSyQAANIcgSk3th0Eetj3kJZahIekIO3ol2sPps8IkgkDzbMocWmKKEfZcCbja hUW+CwFW64UeddgiVNBvCFXdlUFzPlIvNMAGfVjoDen88L8SlvZwvl19z1oBAyADndkO hQwAQEf0MQoX0JgVXUkxUhOVkMdCdjhwGFY19su7qMjjWOsAXI2ZZPOdB5mc8V/NyEof OHGiJ7P0s7i9aUDLWufjj8XifJZMCsQ89q76ptoTmiIcH5gzfoS3+WXvPSFn63AyPY86 TgbHMD0sHxKjFu3SZ2mfEc5FWiK3R2dhNp1ExNzVjfYWTGOobatsNPeHBk1IGXrcWBBy QbHQ== X-Gm-Message-State: AKS2vOzGksOzfWME9H9YjjXOFRaS+tMvZqG+eoGKtWzp7EXeCdqUxaBi 3t7SIvbxxK2u6RN2SwnTRTNamWnkx4cf X-Received: by 10.55.40.140 with SMTP id o12mr26591819qko.50.1497877886237; Mon, 19 Jun 2017 06:11:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.57.113 with HTTP; Mon, 19 Jun 2017 06:11:05 -0700 (PDT) In-Reply-To: <3675935b-c09d-8b34-c439-b0c5405a00d5@gmx.net> References: <3675935b-c09d-8b34-c439-b0c5405a00d5@gmx.net> From: Renzo Navas Date: Mon, 19 Jun 2017 15:11:05 +0200 Message-ID: To: "Ace@ietf.org" Cc: Hannes Tschofenig , Kepeng Li , Hannes Tschofenig Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Ace] Potential uses of PoP keys in CBOR Web Tokens (CWTs) X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 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, 19 Jun 2017 13:11:30 -0000 Hello Hannes, Kepeng, ACE I used the PoP key concept, to map on top of it other Authenticated Key Establishment (AKE) exchanges (aside from the default one on OAuth that uses timestamps). This generic use I presented on IETF 95 [1]. More relevant to the current question on ACE, I put this idea more close to reality, I co-authored a paper which we do the actual mapping of one AKE protocol to the ACE-OAuth architecture using CWT, "Nonce-based authenticated key establishment over OAuth 2.0 IoT proof-of-possession architecture" [2]. On this google doc [3] there is more detail about the actual messages that should be sent. This was more than one year ago. So it differs with the current state of the are of ACE WG, and CWT. The high level solution goes as this: the CWT have to be linked to the current run of the AKE protocol. In order to achieve so I chose to extend the COSE_Key object to be able to transport relevant authenticated key establishment information (nonces and entities-id's). So the final CWT will contain (on the "ck") a COSE_Key that will allow the RS to validate the full AKE exchange: hence the CWT is fresh and we have also the key that goes with it. Today I'm not sure if I'll do it the same way (extend the COSE_Key object) , but rather I think a more generic CBOR object can be defined with appropriate security services to transport different information needed by the AKE protocol exchange, that in the end will be also liked to the CWT. Some time ago, we had some talks with Ludwig and G=C3=B6ran to try to put this into practice-IETF, but was indeed a little bit haunting to define a generic framework to run on top of it any AKE protocol linked to a PoP-key/CWT. (So, that's why we went first for a time synchronization solution, to at least enable the current IETF PoP exchange to work) I don't know if there is real need for nonce-based PoP Keys/CWT solutions on industry. My 2 cents, Renzo [1] https://www.ietf.org/proceedings/95/slides/slides-95-ace-3.pdf [2] https://hal.archives-ouvertes.fr/hal-01522039v1 [3] https://docs.google.com/document/d/1xzc3hUJhCEtT6_HoW2gLoBiXfNk-ID57gUs= 6XftlIIc/edit?usp=3Dsharing On Mon, Jun 12, 2017 at 8:19 PM, Hannes Tschofenig wrote: > Hi all, > > RFC 7800 defines how to communicate Proof of Possession (PoP) keys for > JSON Web Tokens (JWTs) [RFC 7519]. The CBOR Web Token (CWT) > draft-ietf-ace-cbor-web-token spec defines the CBOR/COSE equivalent of > the JSON/JOSE JWT spec. > > The ACE working group is planning to also define a CBOR/COSE equivalent > of RFC 7800 and is interested in knowing how you might use CBOR > proof-of-possession keys for CWTs. > > Please drop us a message if you are using CBOR PoP keys for CWTs. We > would like to learn more about your usage. > > Ciao > Hannes & Kepeng > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace From nobody Mon Jun 19 08:29:32 2017 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 2E9B713152B for ; Mon, 19 Jun 2017 08:29:31 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 bIBiyMtVEY-q for ; Mon, 19 Jun 2017 08:29:29 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (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 D05A2128C83 for ; Mon, 19 Jun 2017 08:29:28 -0700 (PDT) Received: from [192.168.91.196] ([88.128.80.105]) by mail.gmx.com (mrgmx002 [212.227.17.190]) with ESMTPSA (Nemesis) id 0Lt1S6-1domFQ28r4-012c5N for ; Mon, 19 Jun 2017 17:29:26 +0200 To: "Ace@ietf.org" From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: Date: Mon, 19 Jun 2017 17:29:26 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:K4RjC5rLoXk4TaJSdce2LE5otqNwolH3ITb7Sqy0f1UQZXvxkmF UNWgBJlR1cbodcnPtMD4ZoNEcRubFvcEauB8c3GbJtDNS0BGetsoHXC82nwNoKagRiEIwCG IxRYMmbbJnJA2hksbbuFJ2UHMAwiMqetj1NeNKirejcjI78U8AFRWyO399gmaK4Yo1EbUzS +niHIX/g4+yoW408G22Sw== X-UI-Out-Filterresults: notjunk:1;V01:K0:FxDPb4iACRY=:xW5G0CRlTDjA07CDF9y+U7 UhEDJqNgporF4pY0H51o21YsHgd7LDnuR8nj9BVgBGBTXEy8rHTz7XpIPqdvp97D9mSVgEtVS u6i2cv9/1R8I70kxG9Fd6z1xYXy4r74ys9TEYS6nG+FJB1u2g6WZ1tagJbimxLRLiB6OCNaDK SmxH39CU/qIEzruDk3MyRpnndaMua2jQWcjVJSqcJeja+F/wtEX50Uy2WetbBkGcFbWd5EGGq NlopZ65Fs+brvT3SaJqD+xvW9myo/7V7L9Jk8yR8WP53S1dWjYja29KtjGnebS5mLVO6g8lYo 67vXcVisy/Z2pF/feYOPOIi4uT3p1Co1MfEJlUGg5rD4SXDv9CrSbRLJGYMLjmGcVb15cNhyy EZB+gRcW8xPFe40CtxRqeWbkeJfX4LMhc4DUv1NrNyxLFuhd0CWG7TpWg/Rz+1GfY5TU3aSwn T3gp0KrEe2a+tyU5Rnz6EIfHYOA4z0D7mjcYdsHljFfx9ZJl539ELWecqaZPiB6nhLeuS0O9A +q4vEmx7srgl137vqrCRrRIOV4+g51oVsD8rAVxcd6DKnuXqg/Azmfm7CUWoY/jkqhF/NctKq h42QIswTJZgjBwj1jUBtzKx/Ajfh9KwtBlNy+YPyRJqLoahkOTVE32pa52pUgy7lObO5GCgtn 0NUNOu4tdQC0szuQhmfwW9MBhAmr2FoAYfJRTmIiU1bz630fz3JUlwsSQ57FebudXJAQXQcUd CsMszIaz+5mL3NXQYGsB8tcF+320/2v/iiquvTS6F/sWJxH6+t0ZOZNj7xfKs7qiCGi+l5wjH mbavOc1 Archived-At: Subject: [Ace] WGLC on the OAuth Device Flow Specification X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 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, 19 Jun 2017 15:29:31 -0000 Hi all, the OAuth device flow document is currently in WGLC in the OAuth working group and I believe it could be of interest to folks in this group. Here is the link to the WGLC announcment email: https://www.ietf.org/mail-archive/web/oauth/current/msg17305.html If you are interested, please take a quick look at it and provide feedback. Ciao Hannes From nobody Wed Jun 21 13:01:30 2017 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 D0869128D2E for ; Wed, 21 Jun 2017 13:01:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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=ve7jtb-com.20150623.gappssmtp.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 RRSemPWcYRl4 for ; Wed, 21 Jun 2017 13:01:20 -0700 (PDT) Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::231]) (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 5409E129412 for ; Wed, 21 Jun 2017 13:01:20 -0700 (PDT) Received: by mail-io0-x231.google.com with SMTP id e63so1632892iod.3 for ; Wed, 21 Jun 2017 13:01:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=QfKQS6rKZlinu0zo4U3mXAcWq8J7RDCcLumoq+jv35I=; b=AHRVl3VK/PUM5Mi+6Zw8rfagKcAujShHyFOu2HwiqinEEsGn8jPfQPYTunypBcsbm5 f7Kpza2DJpNg1O/NDMDlVeymcIgIXT9hdixctIyAB7ezkKReSrZEJzwUCvYBWx4at7W+ wJvMBtFXQ0TRPejTRV2MkS21pkJpGUoiovnhN1frmbKqLroJQdioLoXw1ky7xokHkRsR sr2fu1zppxMsnQlIZFfDes+ws2YLI29iqtW2vPdQVVvTtryI3qtXA3VDLHARMk+0JT9k D/V4i6xL934gI8a4mvaS0dDjKdzJPqkVCY14sLRCNA/ctCitE+/9dtfGfskKz0J5b/hY ca+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=QfKQS6rKZlinu0zo4U3mXAcWq8J7RDCcLumoq+jv35I=; b=BScfZIlNw2+IWQATTHTwZl1eLsPmRK9Z48e5bOWVuGYvRTzGIPN3Jd096DnYgOMey2 Dr3gxLDXMio8tXXBERL8qL8wx0fYH6kB+A5SXojF21VAQQlooOwSLtMYUy/z7GWQyC9W +ZzTxbmyH/eAGs5N3eWKEdP4nEcg/U6PbupPbAYyxo5t8eHbENw90jUw68yxm2cDiVwf IYc6R76yOfCUENyQ5kxkf4XpkKlEeXhjyP60A5XXcbB9inhabO7QQhx/MDeztbdM+a3j gV6LspUZefvTlfNcsU3kG97qtwOWW3bxFf5aGriP99g5fgEEIyyNMwKSUNA6ThLuMKD5 HFjw== X-Gm-Message-State: AKS2vOzs/6UoggSoG0mNjbNILQ3Y89IXZv1H9qRTEuTQIx6kG5JLe/lN 8lJOUBqX1V5DVNmH X-Received: by 10.107.134.91 with SMTP id i88mr34465968iod.53.1498075278103; Wed, 21 Jun 2017 13:01:18 -0700 (PDT) Received: from [10.150.72.61] ([208.59.64.22]) by smtp.gmail.com with ESMTPSA id o197sm1751930ioe.46.2017.06.21.13.01.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 21 Jun 2017 13:01:16 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: John Bradley In-Reply-To: <3675935b-c09d-8b34-c439-b0c5405a00d5@gmx.net> Date: Wed, 21 Jun 2017 15:01:15 -0500 Cc: "Ace@ietf.org" , Hannes Tschofenig , Kepeng Li , IETF OAUTH Message-Id: <5C392517-F427-4B32-8B9C-D42E4A095CC4@ve7jtb.com> References: <3675935b-c09d-8b34-c439-b0c5405a00d5@gmx.net> To: Hannes Tschofenig X-Mailer: Apple Mail (2.3273) Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a113ecd98e514dc05527dd475" Archived-At: Subject: Re: [Ace] Potential uses of PoP keys in CBOR Web Tokens (CWTs) X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 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, 21 Jun 2017 20:01:24 -0000 --001a113ecd98e514dc05527dd475 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I don=E2=80=99t have any deployments yet, but am changing companies in = July and can see some future use cases for POP CWT around Web = Authentication. POP for JWT is taking off and Ping has implementations of that. It would be beneficial if we could maintain the same confirmation = =E2=80=9Ccnf=E2=80=9D semantic between JWT and CWT. I suspect that there are going to be gateways and mixed environments, so = it will reduce confusion. If you are asking about specific confirmation methods you need to give = me a bit of time to swap some of this into my head. The high level semantic of a confirmation element should be the same but = even in JWT there are different methods and information that needs to be = propagated depending on the application eg key hash vs DN vs encrypted = symmetric key. John B. > On Jun 12, 2017, at 1:19 PM, Hannes Tschofenig = wrote: >=20 > Hi all, >=20 > RFC 7800 defines how to communicate Proof of Possession (PoP) keys for > JSON Web Tokens (JWTs) [RFC 7519]. The CBOR Web Token (CWT) > draft-ietf-ace-cbor-web-token spec defines the CBOR/COSE equivalent of > the JSON/JOSE JWT spec. >=20 > The ACE working group is planning to also define a CBOR/COSE = equivalent > of RFC 7800 and is interested in knowing how you might use CBOR > proof-of-possession keys for CWTs. >=20 > Please drop us a message if you are using CBOR PoP keys for CWTs. We > would like to learn more about your usage. >=20 > Ciao > Hannes & Kepeng >=20 > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace --001a113ecd98e514dc05527dd475 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIRGwYJKoZIhvcNAQcCoIIRDDCCEQgCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg gg4rMIIErzCCA5egAwIBAgIRAOAjyxUSg1OJrWFuelRnayEwDQYJKoZIhvcNAQELBQAwbzELMAkG A1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0xNDEy MjIwMDAwMDBaFw0yMDA1MzAxMDQ4MzhaMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRl ciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRl ZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1 cmUgRW1haWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCJsQ3aelMZTnBSHbxW pgYmt7hJ4JbnUavx8FoTSRWjtIwbYLx6UUKneYykIt8XYU6R1XYjChTTSgJ/th0JgG6lBD3ZursW /qGHqS5DUkMWfK8yUMimT1rpCNjPkyWce4joMGTmpPhWgP0qJBQzF5msROVpi6NGBkvCM9TpQJ8G sLGsk0C5tQiTOpwqU6MQ2z0gYTxVA47ZTnYlAiEp+qN8cXZP7uFfgen7VIDbw3s1UreE3iI9LDAt MX9ZvVI3sDNpLUPr+tal8Zd3Z1GM2e4n67ylBzh2jKSpOP/fjPUDrEm+yvdzmToPMquclToTPQ5G Old0YVC+xkA/y+Tin6IhAgMBAAGjggEXMIIBEzAfBgNVHSMEGDAWgBStvZh6NLQm9/rEJlTvA73g JMtUGjAdBgNVHQ4EFgQUkmFrguGioKpP7GfxwqP3tIAAwewwDgYDVR0PAQH/BAQDAgGGMBIGA1Ud EwEB/wQIMAYBAf8CAQAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBEGA1UdIAQKMAgw BgYEVR0gADBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vQWRkVHJ1 c3RFeHRlcm5hbENBUm9vdC5jcmwwNQYIKwYBBQUHAQEEKTAnMCUGCCsGAQUFBzABhhlodHRwOi8v b2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEBCwUAA4IBAQAbKm6sVcE6q4jF2O3NVfOqa2Er wAkQI5kPxWZqb7H1tLV3Xg8CYQDffQX+ErOkgIAA/PsdW2pyAgpBvAW6wVjVJsLq1U2E+/6CmM9Y G+MiY5xS+LsFNqt9WKXeqztj5drVc+/s4Pt74qP/8EIjnMq2jU0+5EsYA7KoLdTYu0JLkGmFENum NzToe+ABEKWcyjrHn0+ING6KZdAairup3MrKNtH0/MJkKTWv1rGncRHSA0Oxjz6a7J4yU/R2ksqG NAe5LMrmHErYmQ3BhuKQkvtaQmojIRDpZcf11bt+6oyFIAJi6tE6ByxZxZkz8jiJ5bbpFnofeRT2 ShAaJvp8ivubMIIENjCCAx6gAwIBAgIBATANBgkqhkiG9w0BAQUFADBvMQswCQYDVQQGEwJTRTEU MBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3 b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290MB4XDTAwMDUzMDEwNDgzOFoX DTIwMDUzMDEwNDgzOFowbzELMAkGA1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYD VQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0 ZXJuYWwgQ0EgUm9vdDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALf3GjPm8gAELTng TlvtH7xsD821+iO2zt6bETOXpClMfZOfvUq8k+0DGuOPz+VtUFrWlymUWoCwSXrbLpX9uMq/Nzgt Hj6RQa1wVsfwTz/oMp50ysiQVOnGXw94nZpAPA6sYapeFI+eh6FqUNzXmk6vBbOmcZSccbNQYArH E504B4YCqOmoaSYYkKtMsE8jqzpPhNjfzp/haW+710LXa0Tkx63ubUFfclpxCDezeWWkWaCUN/cA Lw3CknLa0Dhy2xSoRcRdKn23tNbE7qzNE0S3ySvdQwAl+mG5aWpYIxG3pzOPVnVZ9c0p10a3Citl ttNCbxWyuHv77+ldU9U0WicCAwEAAaOB3DCB2TAdBgNVHQ4EFgQUrb2YejS0Jvf6xCZU7wO94CTL VBowCwYDVR0PBAQDAgEGMA8GA1UdEwEB/wQFMAMBAf8wgZkGA1UdIwSBkTCBjoAUrb2YejS0Jvf6 xCZU7wO94CTLVBqhc6RxMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQG A1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4 dGVybmFsIENBIFJvb3SCAQEwDQYJKoZIhvcNAQEFBQADggEBALCb4IUlwtYj4g+WBpKdQZic2YR5 gdkeWxQHIzZlj7DYd7usQWxHYINRsPkyPef89iYTx4AWpb9a/IfPeHmJIZriTAcKhjW88t5RxNKW t9x+Tu5w/Rw56wwCURQtjr0W4MHfRnXnJK3s9EK0hZNwEGe6nQY1ShjTK3rMUUKhemPR5ruhxSvC Nr4TDea9Y355e6cJDUCrat2PisP29owaQgVR1EX1n6diIWgVIEM8med8vSTYqZEXc4g/VhsxOBi0 cQ+azcgOno4uG+GMmIPLHzHxREzGBHNJdmAPx/i9F4BrLunMTA5amnkPIAou1Z5jJh5VkpTYghda e9C8x49OhgQwggU6MIIEIqADAgECAhEA2TLMtWuXNcB2cbqZ/VgVujANBgkqhkiG9w0BAQsFADCB mzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2Fs Zm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2 IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTE3MDEwOTAwMDAw MFoXDTE4MDEwOTIzNTk1OVowIjEgMB4GCSqGSIb3DQEJARYRdmU3anRiQHZlN2p0Yi5jb20wggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDW2rqobOFQ/XmzH3DG2UK1Dt6jtc+OFZ71KQoB o8IZa/V94Ey12BPjBcoj+cjHNVsLd2QiUpMcf5sZFMX1cmvpR7TiUISgVcHe8zgiUUvN5Jn5tPDM Kb4E34TtDEG2X5FyY35AwCl8NV/loj2D5KLid9BLdVTJjfqokjLQ/4qCQjWBjfTpIdAdr3lXfg5f a5UPyIkphEIplM8/yGfX0W/PBl804XAL0gesLrfEMdgG58UCN1wJMgH4uRKmKU/U2Ap4W9hTpioN M722U8x7N6P1v6MqTAWCUaskdOp+ktNxFGxOlCE7BEo/EIaWbEt5RHwDePctScDLsi56+VI3TysR AgMBAAGjggHvMIIB6zAfBgNVHSMEGDAWgBSSYWuC4aKgqk/sZ/HCo/e0gADB7DAdBgNVHQ4EFgQU Yg3SsFWhMro4Abonbn1IX4JKj5QwDgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0l BBkwFwYIKwYBBQUHAwQGCysGAQQBsjEBAwUCMBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9 MDsGDCsGAQQBsjEBAgEBATArMCkGCCsGAQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0 L0NQUzBdBgNVHR8EVjBUMFKgUKBOhkxodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9TSEEy NTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDBYBggrBgEFBQcwAoZMaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPU0hBMjU2Q2xp ZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDov L29jc3AuY29tb2RvY2EuY29tMBwGA1UdEQQVMBOBEXZlN2p0YkB2ZTdqdGIuY29tMA0GCSqGSIb3 DQEBCwUAA4IBAQCC26y+6/+SJoRQWepca+rB9eSSwaCAb8nNqA+00ZiOHb+6UbbV1xa7Z8wDIuEL 5UKbNtQ2NDArvzF9YI0xNafoV1AEmP/3+ljxQHSEI0U1p2h401sOx+nSjcwtTzACso1lw+I0oJYM JFITOIfZy8HgFpCipBrQAp9jMJ+KSKDX3xu/hzPosfdnXp7sV1KAjkFrAtR3AnQYfJ5W8QrsmC4N BbiAKoYWUSdklqn3v1neTG/+oOhcw7hcGZo+YmPyF9Cdy0gBtwSHPt8hluhg2TlzmqYfi0dVL/mU jCBNUY/BFH+MBqKF7sOIRMv8ALWceVaM/NEcBciKs4eR99A4cw9ZMYICtDCCArACAQEwgbEwgZsx CzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv cmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBD bGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRANkyzLVrlzXAdnG6mf1Y FbowDQYJYIZIAWUDBAIBBQCggdQwLwYJKoZIhvcNAQkEMSIEIAFpQpRlRzSSmJ71yw+U5VfMibul Q3GKbs0VY2vRJE1jMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE3 MDYyMTIwMDExOVowaQYJKoZIhvcNAQkPMVwwWjALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAsG CWCGSAFlAwQBAjAKBggqhkiG9w0DBzALBgkqhkiG9w0BAQowCwYJKoZIhvcNAQEHMAsGCWCGSAFl AwQCATANBgkqhkiG9w0BAQEFAASCAQB6OzTqyvYGZUYn4BVgyXQzhFnuLrFuGDfeqCSkIOXZ/NQu k4FwtJNvjqIZskjyW24S3tP1m5ATbKR6lHV1304pDfsVzxSABygbFHBCCrXvu/OUbGyDZpETCsIT KugtIq+gSGTN98hY24JD85OJT+njNuL6cNUF+Lac/2oA1zxRa+wv9cO0dkqYOmsIwamvWjehSXVI 1Xwk+J08W/SaNH72GswX0RrCApka6OxMUtXDa6FeLITgx/wv69T5COlGhoTy635Pt2qR6moV2Y3f SB0mMx83IN5GRI1Y/b2rhVx8roWGRFgDP6/kBNcaAh5u9tfEy1kjsNqsgTE0WLzPVR2I --001a113ecd98e514dc05527dd475-- From nobody Wed Jun 21 18:42:45 2017 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 35D841293F4; Wed, 21 Jun 2017 18:42:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.41 X-Spam-Level: X-Spam-Status: No, score=-0.41 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_03_06=1.592, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=augustcellars.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 3OKruvfVqW-R; Wed, 21 Jun 2017 18:42:43 -0700 (PDT) Received: from mail4.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 3E4E9129434; Wed, 21 Jun 2017 18:42:42 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1498095753; h=from:subject:to:date:message-id; bh=2qGaMvlS13vH9MnZmuIFsDLPk5k8i0gEiQQgmhJW1E0=; b=Wk5zWfjgYTWKpIB9764Uqaug3ZJPxIv/jvTyX9FY7IDWFgJLGZG6leZ0QD+qSTwsLm8t6SoPbrL PDloeA5ThpkDa4lOPkaWtZ7HH5y+eR2zLhzTYzNlF/wZ2QONE+S3Gj67P9WMDqvGKo132GF2OhZKT m1n0IQeXMZu7gstW+M/Gyx5AGgaW+kj2TJc8s0gLzdYruX8nQ0hTXuGH8d6QuT7V5Ekpf0WSWYZfa dp4ZyJI+UQtJUwE2/UaSnaecBDnbrfRxZBVM6AXwmuSoMFFeWHlQZGNufhMGGWs2kHSwtLwxUV/BW vs72YPGMTQeEiMcJCvXnNQxFeOvBmH6bUsEw== Received: from mail2.augustcellars.com (192.168.1.201) by mail4.augustcellars.com (192.168.1.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 21 Jun 2017 18:42:32 -0700 Received: from Hebrews (24.21.96.37) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 21 Jun 2017 14:05:13 -0700 From: Jim Schaad To: CC: Date: Wed, 21 Jun 2017 14:05:13 -0700 Message-ID: <009701d2ead2$15024df0$3f06e9d0$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdLqRj2/XmE1ZmT4SdWQ68oQlcxMxA== X-Originating-IP: [24.21.96.37] Archived-At: Subject: [Ace] Review on draft-ietf-ace-dtls-authorize-00 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 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, 22 Jun 2017 01:42:44 -0000 I have some comments on this draft that I have gotten from implementation attempts. Major Issues: Section 2 talks about looking things up in the resource directory, but it does not say what one would be looking for. Is this material which should be in the generic document? Section 2 - I see a potential interop problem w/ the MAY about transferring the access token or PSK. Does a client try it and if it does not work do it the other way or is it always going to post unless it has some external indicator that it can take the "shortcut" method? Section 2.1 - I do not understand why this is not in the mail document rather than in this profile. Section 2.1 - The list of three items seems to be overly restrictive on what is allowed. I believe that you are missing the case of no token because no token is needed (which would apply to /authz-info as well). You have previously stated that going to /.well-known/core may be something that is desirable - either that or I completely miss understood what was being said above. Section 2.2 - I do not see the AS_Info map defined anyplace. Am I missing something? Section 2.1 - I am not sure - is the case of no valid access token supposed to cover cases where the token has expired? Are there other cases that one needs to think about here? Would it not be better to close the DTLS connection in the event that the last valid token expires? Section 2.1 - You do not state if an AS_Info map should be returned for all three cases of failures. I assume that it should be, but at the current level of information it might not be totally useful. Section 2.2 - You might want to differentiate on the setoff AS_info fields that would be returned in an unsecured vs secured channel. That is, if I have a DTLS connection and try to do an operation that fails - then more info could be returned as it is not generally available. Section 2.2. - I have no idea how to use this nonce value so that it ends up in the access token. Section 2.3 - I have no idea what item #3 is supposed to be saying. How can an RS determine if it is the destination under normal circumstances? Section 3 - I am not sure that the Note text really makes any sense. If the client implements Edwards rather than classic EC curves this makes no sense to offer. Section 4.1 - the psk_identity field in TLS is a binary field - why do the base64 encoding - need to justify this. Also the current text means that I suddenly have three different things that can be in this field. This is not the type of thing hat would make me happy. Where you want me to do this is not the easiest place to suddenly do the processing needed to validate a new access token. Section 4.1 - I don't understand what the text around COSE_Encrypt is supposed to be doing. It makes little sense to me but I have not tried to think about it deeply. Section 4.2 - I don't know that a reference to 5746 is going to be any good long term. Section 4.2 - need to distinguish between cases where the permissions are update vs where the key is updated. The former SHOULD NOT require a new session to be established. Section 5.1 - I am not sure what this means. I assume that this text should say that a client should only deal with an AS for which it has a security relationship. Note that it might be an idea to be able to copy the AS from the RS into the AS request in the event that they do not match so that four corner authorization can be supported. Minor Issues: * I would stop the PSK and RPK paragraphs in the introduction so that they are in the same order as in sections 3 and 4. * In the introduction - clean up the last two paragraphs. The reference # is off as is the extra line in the Note * Remove the mention of OSCOAP in section 4 - If you want to say another profile exists, do it in the introduction. Jim From nobody Thu Jun 22 01:40:11 2017 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 04C5D1279EB for ; Thu, 22 Jun 2017 01:40:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 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_LOW=-0.7] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=erdtman-se.20150623.gappssmtp.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 Uk40oiWZufhT for ; Thu, 22 Jun 2017 01:40:06 -0700 (PDT) Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::234]) (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 183D31242F7 for ; Thu, 22 Jun 2017 01:40:05 -0700 (PDT) Received: by mail-oi0-x234.google.com with SMTP id p66so5109448oia.0 for ; Thu, 22 Jun 2017 01:40:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=erdtman-se.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=fuYqvexDexTDsEHbufZZHcWlGLygQLuVtdX0IRwnrrM=; b=Q5Om1FVN2orsMc2FB9B2fv5eEi0c14jRn+Oi0zwnngXsmRQ9YYXYE78hrmVPyPK85X cf0+YJoNcXHdd4Y7xyl8dBkLVpDKKD45OqqDYmXAkjatVjZczNoV10KIgAhZJ7DpU+Yn Y52UNQe2PKelT21jkjVLSLmrVNEjv34L4BINzY2MJq42JPCniPjxLu0U6sjvdiEPnmcg YTEZjO/4kDYxU7ogNEEK6AVzfEfW+ttinBG6ZFdIHOJV5VYJ2xkzd4p5imhILuAGMtfB AaqKF8wQPFvi6JWKVCrIpVk1egQYKcKDLoQs+6eHOtwLAj9k/QmNh83daqupa4h9lDfF 2YUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=fuYqvexDexTDsEHbufZZHcWlGLygQLuVtdX0IRwnrrM=; b=YC2n3dtqZQm6PNML8yQ6TA3YZIyaOq3CcrS9GtQXCXvbwcZfI4i4ca8yIj7VTtdD2B tcUuXvjKLayOO+6IM4x4cIohxNSJZom1ugnuzQPhi7F6SRrU0pcyCRBDHLk6jhbLqOV6 IQcEQ63pnKeMVx5owNezGisj7LRrl2LI2Y2gKRfAjlZ0jwJYNFGWpgOS8F1+us010AJP 70xX1VjW+8j94ihMNcJA/9paZM7j/k/qFSCqaRr7LHnab6DHUd+svtSI6BfJNqKcUMJg LzU0DtgS+jSmOEOdqY1SLdx8Y75WsMYzu64bHes1XAwsem1XmzXxqaz74nPxlmTIQS4N Asgw== X-Gm-Message-State: AKS2vOw+TVESJB3NNhdgyu6RwNN8nnf2EdkCCI7IJPUSgSibcBLJ5Jko mCJZa+lwPZQzKfrOwaEM1GOovk3X5j5M X-Received: by 10.202.90.131 with SMTP id o125mr598184oib.3.1498120805113; Thu, 22 Jun 2017 01:40:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.70.33 with HTTP; Thu, 22 Jun 2017 01:40:04 -0700 (PDT) In-Reply-To: <006101d2e868$17c8e3d0$475aab70$@augustcellars.com> References: <149671239411.3941.12998153965739248286@ietfa.amsl.com> <006101d2e868$17c8e3d0$475aab70$@augustcellars.com> From: Samuel Erdtman Date: Thu, 22 Jun 2017 10:40:04 +0200 Message-ID: To: Jim Schaad Cc: draft-ietf-ace-cbor-web-token@ietf.org, ace Content-Type: multipart/alternative; boundary="001a113d5a926b76900552886e6b" Archived-At: Subject: Re: [Ace] I-D Action: draft-ietf-ace-cbor-web-token-05.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 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, 22 Jun 2017 08:40:10 -0000 --001a113d5a926b76900552886e6b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks Jim! Se comments inline On Sun, Jun 18, 2017 at 9:21 PM, Jim Schaad wrote: > Comments on this version of the draft. > > Section 7 - Step 6 & 7 - I do not know if it is legal to have a CWT CBOR > tag at this point > In section 7.1 step 6 describes how one can add the CWT CBOR Tag to the full CWT if transport layer cannot indicate that this is a CWT. In this case you would want first the COSE tag and then the CWT tag this is described in section 6. We asked Carsten about this before we added the text so it should be okay. In section 7.2 step 6 and 7 CWT CBOR tag is not mentioned as far as I can tell. > > Section 7 - In Step 7 - it must be a valid CBOR map not just a valid CBOR > object. > Good catch I=C2=B4ll fix, Issue create for now. > > Appendix A.3 - I was unable to reproduce the example. I assume that this > means that a deterministic signature algorithm is not being used. While = a > verifier cannot tell if one is being used, the COSE document does strongl= y > suggest that one be used. Additionally, it helps in testing if one is us= ed > so that a signature creator can be more easily tested. > Correct I have not used a deterministic signing algorithm. I have used COSE-JAVA to create the examples, is it possible to configure that implementation to generate deterministic ECDSA signatures? When working with my JS implementation I have noticed that support for deterministic ECDSA implementations are hard to find. > > Appendix A.5 - I was unable to reproduce the example. Specially the tag > value does not match with the one that I compute. > That is bad. but apart from the tag it looks good? > > Appendix A.6 - I did not try to reproduce given that a) I would not > generate the same signature and b) the example A.5 failed. > See comments above. > > > Minor: > > In section 1.1 s/In COSE/In CBOR/ - this is a comment on CBOR not on COSE > Good catch. However I think it should be s/In COSE/In CWT/, I have created an issue to fix this. > > In section 2: s/CBOR encoded claim key/CBOR claim key/ > * I am unsure why you would think that encoded is needed here. > * Should this be CWT rather than CBOR? > * Why is section 3.1 "Claim Names" rather than "Claim Keys" > I have created an issue to address this. I think the name of section 3.1 is legacy from JWT where the equivalent section is called "Registered Claim Names" I would like to change the name to just "Registered Claims" since it is not just he names or the key that is registered also value type. > > In section 2: Is there a reason not to define CWT claim value in this > section > Sorry I=C2=B4m not following, could you please explain a bit more`? > In section 3.1.1 and on - the following might be considered cleaner > s/except that the format MUST be a/except that the value MUST be of type/ > I have created an issue for this to be considered > > Section 9.1.2 - I would suggest assigning a name to the reserved entry > I have created an issue for this to be considered > > -----Original Message----- > From: Ace [mailto:ace-bounces@ietf.org] On Behalf Of > internet-drafts@ietf.org > Sent: Monday, June 5, 2017 6:27 PM > To: i-d-announce@ietf.org > Cc: ace@ietf.org > Subject: [Ace] I-D Action: draft-ietf-ace-cbor-web-token-05.txt > > > 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 of the IETF. > > Title : CBOR Web Token (CWT) > Authors : Michael B. Jones > Erik Wahlstr=C3=B6m > Samuel Erdtman > Hannes Tschofenig > Filename : draft-ietf-ace-cbor-web-token-05.txt > Pages : 23 > Date : 2017-06-05 > > Abstract: > CBOR Web Token (CWT) is a compact means of representing claims to be > transferred between two parties. The claims in a CWT are encoded in > the Concise Binary Object Representation (CBOR) and CBOR Object > Signing and Encryption (COSE) is used for added application layer > security protection. A claim is a piece of information asserted > about a subject and is represented as a name/value pair consisting of > a claim name and a claim value. CWT is derived from JSON Web Token > (JWT), but uses CBOR rather than JSON. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-ace-cbor-web-token/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-ace-cbor-web-token-05 > https://datatracker.ietf.org/doc/html/draft-ietf-ace-cbor-web-token-05 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ace-cbor-web-token-05 > > > 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/ > > _______________________________________________ > 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 > --001a113d5a926b76900552886e6b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Jim!

Se comments inline

On Sun, Jun 18, 2017 a= t 9:21 PM, Jim Schaad <ietf@augustcellars.com> wrote:
Comments on this versio= n of the draft.

Section 7 - Step 6 & 7 - I do not know if it is legal to have a CWT CBO= R tag at this point

In section 7.1 step= 6 describes how one can add the CWT CBOR Tag to the full CWT if transport = layer cannot indicate that this is a CWT. In this case you would want first= the COSE tag and then the CWT tag this is described in section 6. We asked= Carsten about this before we added the text so it should be okay.

<= /div>
In section 7.2 step 6 and 7 CWT CBOR tag is not mentioned as far = as I can tell.
=C2=A0

Section 7 - In Step 7 - it must be a valid CBOR map not just a valid CBOR o= bject.

Good catch I=C2=B4ll fix, Issue = create for now.
=C2=A0

Appendix A.3 - I was unable to reproduce the example.=C2=A0 I assume that t= his means that a deterministic signature algorithm is not being used.=C2=A0= While a verifier cannot tell if one is being used, the COSE document does = strongly suggest that one be used.=C2=A0 Additionally, it helps in testing = if one is used so that a signature creator can be more easily tested.

Correct I have not used a deterministic sign= ing algorithm. I have used COSE-JAVA to create the examples, is it possible= to configure that implementation to generate deterministic ECDSA signature= s?
When working with my JS implementation I have noticed that support f= or deterministic ECDSA implementations are hard to find.

=
=C2=A0

Appendix A.5 - I was unable to reproduce the example.=C2=A0 Specially the t= ag value does not match with the one that I compute.
<= br>
That is bad. but apart from the tag it looks good?
<= div>=C2=A0

Appendix A.6 - I did not try to reproduce given that a) I would not generat= e the same signature and b) the example A.5 failed.
See comments above.
=C2=A0


Minor:

In section 1.1 s/In COSE/In CBOR/ - this is a comment on CBOR not on COSE

Good catch. However I think it should be= s/In COSE/In CWT/, I have created an issue to fix this.
=C2= =A0

In section 2:=C2=A0 s/CBOR encoded claim key/CBOR claim key/
=C2=A0 =C2=A0 =C2=A0 =C2=A0 * I am unsure why you would think that encoded = is needed here.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 * Should this be CWT rather than CBOR?
=C2=A0 =C2=A0 =C2=A0 =C2=A0 * Why is section 3.1 "Claim Names" ra= ther than "Claim Keys"

I have= created an issue to address this.
I think the name of sectio= n 3.1 is legacy from JWT where the equivalent section is called "Regis= tered Claim Names" I would like to change the name to just "Regis= tered Claims" since it is not just he names or the key that is registe= red also value type.
=C2=A0

In section 2:=C2=A0 Is there a reason not to define CWT claim value in this= section

Sorry I=C2=B4m not following, = could you please explain a bit more`?


In section 3.1.1 and on - the following might be considered cleaner s/excep= t that the format MUST be a/except that the value MUST be of type/

I have created an issue for this to be consider= ed
=C2=A0

Section 9.1.2 - I would suggest assigning a name to the reserved entry
<= /blockquote>

I have created an issue for this to be considered
= =C2=A0

-----Original Message-----
From: Ace [mailto:ace-bounces@ietf.= org] On Behalf Of internet-= drafts@ietf.org
Sent: Monday, June 5, 2017 6:27 PM
To: i-d-announce@ietf.org
Cc: ace@ietf.org
Subject: [Ace] I-D Action: draft-ietf-ace-cbor-web-token-05.txt


A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the Authentication and Authorization for Const= rained Environments of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= CBOR Web Token (CWT)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Mich= ael B. Jones
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Erik Wahlstr=C3=B6m
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Samuel Erdtman
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Hannes Tschofenig
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-ace-cbor-web-token-05.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 23
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2017-06-05

Abstract:
=C2=A0 =C2=A0CBOR Web Token (CWT) is a compact means of representing claims= to be
=C2=A0 =C2=A0transferred between two parties.=C2=A0 The claims in a CWT are= encoded in
=C2=A0 =C2=A0the Concise Binary Object Representation (CBOR) and CBOR Objec= t
=C2=A0 =C2=A0Signing and Encryption (COSE) is used for added application la= yer
=C2=A0 =C2=A0security protection.=C2=A0 A claim is a piece of information a= sserted
=C2=A0 =C2=A0about a subject and is represented as a name/value pair consis= ting of
=C2=A0 =C2=A0a claim name and a claim value.=C2=A0 CWT is derived from JSON= Web Token
=C2=A0 =C2=A0(JWT), but uses CBOR rather than JSON.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc= /draft-ietf-ace-cbor-web-token/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-i= etf-ace-cbor-web-token-05
https://datatracker.ietf.org/<= wbr>doc/html/draft-ietf-ace-cbor-web-token-05

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ace-cbor-web-token-05


Please note that it may take a couple of minutes from the time of submissio= n 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/

_______________________________________________
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

--001a113d5a926b76900552886e6b-- From nobody Thu Jun 22 15:08:59 2017 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 2F8B8128954; Thu, 22 Jun 2017 15:08:58 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=augustcellars.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 kr1PveHUc_zv; Thu, 22 Jun 2017 15:08:55 -0700 (PDT) Received: from mail4.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 AD4CD129470; Thu, 22 Jun 2017 15:08:55 -0700 (PDT) Content-Type: multipart/alternative; boundary="----=_NextPart_000_01EA_01D2EB69.739ABD60" Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1498169331; h=from:subject:to:date:message-id; bh=jA0y4ntM0CHuvHj2UslqORYIlPrXpzOP+Q9FP0NHiOw=; b=C+J4+Sxdtpa246CDdfyaePuFP7JvDuhGrR6bx1lv1y25RC/PTfkhwlsOJuhEzvSj4SP9jKD/y18 xGW4t2XD7/dmt6tAVtcWtQfKi2GREE732+StWlbTxAVCdswxsMO+BdPaegtFnM7NvZ3fSlpcupfLg v0z3wYDaFI7twwvfvylrSKw0fT1CxztDTNDUOL3KZVGB0JxZhUmYnGRxT1FQl3HC5WfxXX3Xx463H JkK9jWtaAItZlF7QPfyBG1Kb9qu0rPzxorRfC84xBJr+vjK9zoU/YM25gYBW4mGP2sYthHU36KSze T/w3gav1+UyjQA+oHebFhMWpiKLFCJPpJXPg== Received: from mail2.augustcellars.com (192.168.1.201) by mail4.augustcellars.com (192.168.1.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 22 Jun 2017 15:08:50 -0700 Received: from Hebrews (24.21.96.37) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 22 Jun 2017 15:08:46 -0700 From: Jim Schaad To: 'Samuel Erdtman' CC: , 'ace' References: <149671239411.3941.12998153965739248286@ietfa.amsl.com> <006101d2e868$17c8e3d0$475aab70$@augustcellars.com> In-Reply-To: Date: Thu, 22 Jun 2017 15:08:45 -0700 Message-ID: <01e901d2eba4$1ff2b790$5fd826b0$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQIaEBRr5jC1xCcXZVQxVO5bX+OccgFGRkJgAjNmAeChhzAzYA== X-Originating-IP: [24.21.96.37] Archived-At: Subject: Re: [Ace] I-D Action: draft-ietf-ace-cbor-web-token-05.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 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, 22 Jun 2017 22:08:58 -0000 ------=_NextPart_000_01EA_01D2EB69.739ABD60 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable See below. =20 Jim =20 From: Samuel Erdtman [mailto:samuel@erdtman.se]=20 Sent: Thursday, June 22, 2017 1:40 AM To: Jim Schaad Cc: draft-ietf-ace-cbor-web-token@ietf.org; ace Subject: Re: [Ace] I-D Action: draft-ietf-ace-cbor-web-token-05.txt =20 Thanks Jim!=20 Se comments inline =20 On Sun, Jun 18, 2017 at 9:21 PM, Jim Schaad > wrote: Comments on this version of the draft. Section 7 - Step 6 & 7 - I do not know if it is legal to have a CWT CBOR = tag at this point =20 In section 7.1 step 6 describes how one can add the CWT CBOR Tag to the = full CWT if transport layer cannot indicate that this is a CWT. In this = case you would want first the COSE tag and then the CWT tag this is = described in section 6. We asked Carsten about this before we added the = text so it should be okay. In section 7.2 step 6 and 7 CWT CBOR tag is not mentioned as far as I = can tell. =20 [JLS] So if an intermediary adds a layer of wrapping (i.e. encrypts it = to the end point) but the original entity who signed it put the CWT tag = on it, it will be and invalid CWT if the tag was not removed?=20 =20 Appendix A.3 - I was unable to reproduce the example. I assume that = this means that a deterministic signature algorithm is not being used. = While a verifier cannot tell if one is being used, the COSE document = does strongly suggest that one be used. Additionally, it helps in = testing if one is used so that a signature creator can be more easily = tested. =20 Correct I have not used a deterministic signing algorithm. I have used = COSE-JAVA to create the examples, is it possible to configure that = implementation to generate deterministic ECDSA signatures?=20 When working with my JS implementation I have noticed that support for = deterministic ECDSA implementations are hard to find. =20 [JLS] With COSE-JAVA, if you are using anything remotely recent is = deterministic, so that should not be a problem. I put this change into = the sources about 8 months ago. The problem may be the same issue as = for A.5 where something is different in the data to be signed. =20 =20 =20 Appendix A.5 - I was unable to reproduce the example. Specially the tag = value does not match with the one that I compute. =20 That is bad. but apart from the tag it looks good? =20 [JLS] Yes apart from the tag I matched everything =E2=80=93 including = the encryption. This bothers me if you are using the COSE-JAVA to = produce the examples. I routinely run regression tests on both language = libraries so they should produce the same output given the same inputs. = This triggers in my mind that you might have done something odd with the = external data and thus we are generating different tags. It would be = something that is being done for signing and for encryption but not mac. =20 Minor: In section 2: Is there a reason not to define CWT claim value in this = section =20 Sorry I=C2=B4m not following, could you please explain a bit more`?=20 =20 [JLS] You thought it was reasonable to define a =E2=80=9CCWT encoded = claim key=E2=80=9D in the terms. I was just thinking that it would be = symmetric to have the values have defined here at the same time. =20 =20 -----Original Message----- From: Ace [mailto:ace-bounces@ietf.org ] = On Behalf Of internet-drafts@ietf.org =20 Sent: Monday, June 5, 2017 6:27 PM To: i-d-announce@ietf.org =20 Cc: ace@ietf.org =20 Subject: [Ace] I-D Action: draft-ietf-ace-cbor-web-token-05.txt 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 of the IETF. Title : CBOR Web Token (CWT) Authors : Michael B. Jones Erik Wahlstr=C3=B6m Samuel Erdtman Hannes Tschofenig Filename : draft-ietf-ace-cbor-web-token-05.txt Pages : 23 Date : 2017-06-05 Abstract: CBOR Web Token (CWT) is a compact means of representing claims to be transferred between two parties. The claims in a CWT are encoded in the Concise Binary Object Representation (CBOR) and CBOR Object Signing and Encryption (COSE) is used for added application layer security protection. A claim is a piece of information asserted about a subject and is represented as a name/value pair consisting of a claim name and a claim value. CWT is derived from JSON Web Token (JWT), but uses CBOR rather than JSON. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ace-cbor-web-token/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ace-cbor-web-token-05 https://datatracker.ietf.org/doc/html/draft-ietf-ace-cbor-web-token-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ace-cbor-web-token-05 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/ _______________________________________________ Ace mailing list Ace@ietf.org =20 https://www.ietf.org/mailman/listinfo/ace _______________________________________________ Ace mailing list Ace@ietf.org =20 https://www.ietf.org/mailman/listinfo/ace =20 ------=_NextPart_000_01EA_01D2EB69.739ABD60 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

See = below.

 

Jim

 

From: = Samuel Erdtman [mailto:samuel@erdtman.se]
Sent: Thursday, = June 22, 2017 1:40 AM
To: Jim Schaad = <ietf@augustcellars.com>
Cc: = draft-ietf-ace-cbor-web-token@ietf.org; ace = <ace@ietf.org>
Subject: Re: [Ace] I-D Action: = draft-ietf-ace-cbor-web-token-05.txt

 

Thanks Jim!

Se comments inline

 

On Sun, = Jun 18, 2017 at 9:21 PM, Jim Schaad <ietf@augustcellars.com> = wrote:

Comments = on this version of the draft.

Section 7 - Step 6 & 7 - I do = not know if it is legal to have a CWT CBOR tag at this = point

 

In section 7.1 step 6 describes how one = can add the CWT CBOR Tag to the full CWT if transport layer cannot = indicate that this is a CWT. In this case you would want first the COSE = tag and then the CWT tag this is described in section 6. We asked = Carsten about this before we added the text so it should be = okay.

In section 7.2 step = 6 and 7 CWT CBOR tag is not mentioned as far as I can tell.

 

[JLS]=C2=A0 So if an intermediary adds a layer = of wrapping (i.e. encrypts it to the end point) but the original entity = who signed it put the CWT tag on it, it will be and invalid CWT if the = tag was not removed?

 


Appendix A.3 - I was unable to reproduce the = example.  I assume that this means that a deterministic signature = algorithm is not being used.  While a verifier cannot tell if one = is being used, the COSE document does strongly suggest that one be = used.  Additionally, it helps in testing if one is used so that a = signature creator can be more easily = tested.

 

Correct I have not used a deterministic signing = algorithm. I have used COSE-JAVA to create the examples, is it possible = to configure that implementation to generate deterministic ECDSA = signatures?
When working with my JS implementation I have noticed = that support for deterministic ECDSA implementations are hard to = find.

 

[JLS] With COSE-JAVA, if = you are using anything remotely recent is deterministic, so that should = not be a problem.=C2=A0 I put this change into the sources about 8 = months ago.=C2=A0 The problem may be the same issue as for A.5 where = something is different in the data to be signed.=C2=A0 =

 

 


Appendix A.5 - I was unable to reproduce the = example.  Specially the tag value does not match with the one that = I compute.

 

That is bad. but apart from the tag it looks = good?

 

[JLS] Yes apart from the = tag I matched everything =E2=80=93 including the encryption.=C2=A0 This = bothers me if you are using the COSE-JAVA to produce the examples. = =C2=A0I routinely run regression tests on both language libraries so = they should produce the same output given the same inputs. =C2=A0This = triggers in my mind that you might have done something odd with the = external data and thus we are generating different tags.=C2=A0 =C2=A0It = would be something that is being done for signing and for encryption but = not mac.

 



Minor:


In section 2:  Is there a reason not to define = CWT claim value in this section

 

Sorry I=C2=B4m not following, could you please explain = a bit more`?

 

[JLS] You thought it was = reasonable to define a =E2=80=9CCWT encoded claim key=E2=80=9D in the = terms.=C2=A0 I was just thinking that it would be symmetric to have the = values have defined here at the same = time.

 

 


-----Original Message-----
From: Ace [mailto:ace-bounces@ietf.org] On Behalf = Of internet-drafts@ietf.org
= Sent: Monday, June 5, 2017 6:27 PM
To: i-d-announce@ietf.org
Cc: = ace@ietf.org
Subject: [Ace] I-D = Action: draft-ietf-ace-cbor-web-token-05.txt


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 of the IETF.

  =       Title           : = CBOR Web Token (CWT)
        Authors    =      : Michael B. Jones
        =                   Erik = Wahlstr=C3=B6m
              =             Samuel Erdtman
  =                     =     Hannes Tschofenig
        = Filename        : = draft-ietf-ace-cbor-web-token-05.txt
        = Pages           : 23
    =     Date            : = 2017-06-05

Abstract:
   CBOR Web Token (CWT) is a = compact means of representing claims to be
   transferred = between two parties.  The claims in a CWT are encoded in
  =  the Concise Binary Object Representation (CBOR) and CBOR = Object
   Signing and Encryption (COSE) is used for added = application layer
   security protection.  A claim is = a piece of information asserted
   about a subject and is = represented as a name/value pair consisting of
   a claim = name and a claim value.  CWT is derived from JSON Web = Token
   (JWT), but uses CBOR rather than = JSON.


The IETF datatracker status page for this draft = is:
https://datatracker.ietf.org/doc/draft-ietf-ace-cbor-we= b-token/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-ace-cbor-web-tok= en-05
https://datatracker.ietf.org/doc/html/draft-ietf-ace-cb= or-web-token-05

A diff from the previous version is available = at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ace-cbor= -web-token-05


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/

________= _______________________________________
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

 

------=_NextPart_000_01EA_01D2EB69.739ABD60-- From nobody Fri Jun 23 17:01:10 2017 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 E1D28129B07; Fri, 23 Jun 2017 17:01:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=augustcellars.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 DR20o02WdKSG; Fri, 23 Jun 2017 17:01:07 -0700 (PDT) Received: from mail4.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 1D60C124B0A; Fri, 23 Jun 2017 17:01:06 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1498262459; h=from:subject:to:date:message-id; bh=V0WIGMoGm3i4TlCcKJ9mJr08vymsY0hB0mOueNOT8pc=; b=Jp2t1rb3V3K1kmpuTLj3RaAJbJfNTFezlwCL3dMYVbT9mv8asjoBANLTAgYKND2TClTpz3C1i2t 9TQpDTl+/fbLw0SE/Frf/b/YknFmtVId1V7HqgYn7z8WCZuiY4qN4h0Zd+FlArajR4g0AN05A4E5z 5DVe7VVe8YMG92A8W7dolb1+htDRuk4mskqPwDXm81eYCXBEvVDYU2aI2Cvt9Tdqb682SeiHFFov5 2ZAL6Ztz3wrAO/2FzBdYDLnEpXHUTvXZ0fKCeCkEJcTviCQOpRFwGhjeuobzoAvcKLpCt/6tSbHOm 9mVfFCbNVGCLSv4aP+Jap6kJ/aQy2HqADvCw== Received: from mail2.augustcellars.com (192.168.1.201) by mail4.augustcellars.com (192.168.1.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 23 Jun 2017 17:00:58 -0700 Received: from Hebrews (24.21.96.37) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 23 Jun 2017 17:00:58 -0700 From: Jim Schaad To: CC: Date: Fri, 23 Jun 2017 17:00:59 -0700 Message-ID: <027601d2ec7c$f74cefc0$e5e6cf40$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdLpMebPezshfWjcSlG6DcdM+RTFYw== X-Originating-IP: [24.21.96.37] Archived-At: Subject: [Ace] Comments on draft-ietf-ace-oauth-authz X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 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: Sat, 24 Jun 2017 00:01:09 -0000 * Figure 7 makes no sense. This appears to be mapping a string to a keyed object. I think however, that the error here is used as a value not a key. * Is there a recommendation for behavior if a new item is posted to the authz-info endpoint which has the same key id as a previous one? I can think of three answers, none of which I link --- Just accept it - this leans to a problem because for DTLS the key ids are single shot tries, that is one cannot try the first key and then the second key. --- Replace it - this means that the client associated with the current key will suddenly be unable to access resources but knows only that the key no longer works --- Reject it - this may be the best option as it leaks only that the key id is already in use, but if the key id is assigned by an AS then it may be hard to get a different one assigned by the AS. * We communicate the profile to be used to the client, however it is not currently being communicated to the server. If the server wants to keep the OSCOAP and DTLS keys separate, this needs to be done. Does it makes sense to put this in the 'cnf' field? * the dtls draft has the concept of a nonce in the AS information payload. How is this propagated through the request (to the AS) and token back to the RS? * Per comments from other drafts. How many of these points are supposed to be under the .well-known arch? * In section 5.7.1 - why is there a requirement that a created rather than a changed response be returned. I was not intending to create a new resource in response to this POST operation. If the 2.01 (created) response is required. Should the token be accessible using the location path in the response? --- Same questions apply to the Client--AS interaction. Jim From nobody Fri Jun 23 17:14:43 2017 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 7ECB112EB57; Fri, 23 Jun 2017 17:07:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: Kathleen.Moriarty.ietf@gmail.com, ace@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149826283451.7840.16596904868417453077.idtracker@ietfa.amsl.com> Date: Fri, 23 Jun 2017 17:07:14 -0700 Archived-At: Subject: [Ace] ace - Requested session has been scheduled for IETF 99 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jun 2017 00:07:15 -0000 Dear Kepeng Li, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. ace Session 1 (2:30:00) Monday, Morning Session I 0930-1200 Room Name: Congress Hall I size: 250 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: Authentication and Authorization for Constrained Environments Area Name: Security Area Session Requester: Kepeng Li Number of Sessions: 1 Length of Session(s): 2.5 Hours Number of Attendees: 100 Conflicts to Avoid: First Priority: core oauth saag lwig tokbind tls People who must be present: Kathleen Moriarty Hannes Tschofenig Kepeng Li Resources Requested: Special Requests: Avoid entire SEC areas. Please avoid a session on Friday! --------------------------------------------------------- From nobody Sat Jun 24 01:58:28 2017 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 9EA86129413; Sat, 24 Jun 2017 01:58:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 rCkuqw2dVVni; Sat, 24 Jun 2017 01:58:18 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (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 76C331242F5; Sat, 24 Jun 2017 01:58:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v5O8wFiL024355; Sat, 24 Jun 2017 10:58:15 +0200 (CEST) Received: from [192.168.217.124] (p5DC7F3A7.dip0.t-ipconnect.de [93.199.243.167]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3wvq3V5hTTz3Z2D; Sat, 24 Jun 2017 10:58:14 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carsten Bormann In-Reply-To: <2DB0474F-900D-42FD-B2C5-F61F396B751C@tzi.org> Date: Sat, 24 Jun 2017 10:58:14 +0200 X-Mao-Original-Outgoing-Id: 519987494.231328-86f3961023977340577980ee6f18d1af Content-Transfer-Encoding: quoted-printable Message-Id: <26509597-910C-48F9-B004-86322AD123F3@tzi.org> References: <2DB0474F-900D-42FD-B2C5-F61F396B751C@tzi.org> To: ace , core , cose , cbor@ietf.org, t2trg@irtf.org X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [Ace] Constrained Node/Network Cluster @ IETF99: "FINAL" AGENDA X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 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: Sat, 24 Jun 2017 08:58:21 -0000 Here is my usual eclectic condensed agenda, now based on the "FINAL" AGENDA for IETF99. Compared to the last week's draft agenda, dnssd and acme were moved. (It is likely that there still will be some more changes after this "FINAL" agenda.) ACE people are going to miss DISPATCH (ARTAREA) again -- not sure if there would have been be any discussions relevant to Constrained Nodes/Networks in ARTAREA, but it doesn't make sense with this scheduling. CORE people will miss both ANIMA and (in-week) ICNRG. ROLL people will miss SAAG, ouch. And LPWAN is on the second half of QUIC. All no disasters, AFAICS, but not pain-free. All times are CEST (UTC+0200). (You can get pure UTC times on https://datatracker.ietf.org/meeting/agenda-utc, for those who want to listen from remote.) SATURDAY, July 15, 2017 0900-1700 ACM, IRTF & ISOC Applied Networking Research Workshop 2017 = (Registration Required) - Athens/Barcelona 0900-1800 T2TRG Interim Meeting - Berlin/Brussels 0900-2100 IETF Hackathon - Chez Louis SUNDAY, July 16, 2017 0900-1600 T2TRG Interim Meeting - Berlin/Brussels 0900-1600 IETF Hackathon - Chez Louis 1345-1445 IEEE 802.1 Time-Sensitive Networking - Congress Hall III 1345-1445 IRTF Overview - Congress Hall I 1345-1445 TEEP Tutorial - Karlin I/II 1600-1700 Newcomers' Meet and Greet (open to Newcomers, WG chairs and = Mentors only) - Garden Terrace 1700-1900 Welcome Reception - Grand Hilton Ballroom & Foyer MONDAY, July 17, 2017 0930-1200 Morning Session I Congress H III ART dispatch Dispatch WG - 09:30-11:30 Grand Hilton BR INT 6man IPv6 Maintenance WG Congress H I SEC *** ace Authentication and Authorization for = Constrained Environments WG Congress H III SEC curdle CURves, Deprecating and a Little more = Encryption WG - 11:30-12:00 1330-1530 Afternoon Session I Karlin I/II INT *** 6tisch IPv6 over the TSCH mode of IEEE = 802.15.4e WG Grand Hilton BR INT homenet Home Networking WG 1550-1720 Afternoon Session II Karlin I/II ART *** cbor Concise Binary Object Representation = Maintenance and Extensions WG Berlin/Brussels SEC tokbind Token Binding WG 1740-1840 Afternoon Session III Athens/Barcel. RTG babel Babel routing protocol WG Grand Hilton BR TSV tsvarea Transport Area Open Meeting TUESDAY, July 18, 2017 0930-1200 Morning Session I Congress H II OPS v6ops IPv6 Operations WG Congress H I TSV taps Transport Services WG 1330-1530 Afternoon Session I Grand Hilton BR IRTF*** t2trg Thing-to-Thing Berlin/Brussels SEC oauth Web Authorization Protocol WG Congress H I TSV tsvwg Transport Area Working Group WG 1550-1750 Afternoon Session II Karlin I/II INT *** 6lo IPv6 over Networks of = Resource-constrained Nodes WG Congress H I IRTF cfrg Crypto Forum WEDNESDAY, July 19, 2017 0930-1200 Morning Session I Congress H I ART *** core Constrained RESTful Environments WG Karlin I/II IRTF icnrg Information-Centric Networking Congress H III OPS anima Autonomic Networking Integrated Model = and Approach WG Congress H II RTG rtgarea Routing Area Open Meeting Grand Hilton BR SEC tls Transport Layer Security WG Karlin III TSV rmcat RTP Media Congestion Avoidance = Techniques WG 1330-1500 Afternoon Session I Grand Hilton BR ART httpbis Hypertext Transfer Protocol WG Congress H III IRTF panrg Proposed Path Aware Networking Congress H II RTG ideas IDentity Enabled Networks BOF 1520-1650 Afternoon Session II Grand Hilton BR ART httpbis Hypertext Transfer Protocol WG Athens/Barcel. INT dnssd Extensions for Scalable DNS Service = Discovery WG THURSDAY, July 20, 2017 0930-1200 Morning Session I Grand Hilton BR INT intarea Internet Area Working Group WG Congress H II IRTF maprg Measurement and Analysis for Protocols Congress H I RTG detnet Deterministic Networking WG 1330-1530 Afternoon Session I Berlin/Brussels ART ice Interactive Connectivity Establishment = WG Grand Hilton BR OPS v6ops IPv6 Operations WG Karlin I/II RTG *** roll Routing Over Low power and Lossy = networks WG Congress H III SEC saag Security Area Open Meeting 1550-1750 Afternoon Session II Athens/Barcel. INT ipwave IP Wireless Access in Vehicular = Environments WG Grand Hilton BR TSV quic QUIC WG 1810-1910 Afternoon Session III Berlin/Brussels ART uta Using TLS in Applications WG Athens/Barcel. INT *** lwig Light-Weight Implementation Guidance WG Karlin I/II RTG bier Bit Indexed Explicit Replication WG Congress H III TSV tsvwg Transport Area Working Group WG FRIDAY, July 21, 2017 0930-1130 Morning Session I Karlin I/II INT *** lpwan IPv6 over Low Power Wide-Area Networks = WG Athens/Barcel. SEC acme Automated Certificate Management = Environment WG Karlin III SEC oauth Web Authorization Protocol WG Grand Hilton BR TSV quic QUIC WG 1150-1320 Afternoon Session II Congress H III ART *** core Constrained RESTful Environments WG From nobody Sun Jun 25 23:57:42 2017 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 66FFB120046; Sun, 25 Jun 2017 23:57:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.004 X-Spam-Level: * X-Spam-Status: No, score=1.004 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, LOCALPART_IN_SUBJECT=1.107, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=augustcellars.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 16KyQE_3V-cV; Sun, 25 Jun 2017 23:57:39 -0700 (PDT) Received: from mail4.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 1801A1242EA; Sun, 25 Jun 2017 23:57:39 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1498460253; h=from:subject:to:date:message-id; bh=5kn3NXRk16jBLwVfGMY0RfH5jUwAXkYMo9YW1R+nNeE=; b=QpgX9XrOqV8ml4VXGZMxwu34GIqiAmPHhKwGyv6HohcQSiue47G1+pbNU659VITI0hzhbMU12ov CpmYduXt3VpwT313AuPInIdJRZ78H/oOfo6fzoTovsNqcBjlSohTuePmFc2DulZisgwXaiXXh51i9 7w4jdcgEcMZAWpswd921aLRjxDqvtvT1P/GvH9jxClmPISlJuEVifoPSl8cUHj/1eg5OH3ow1E9in 6CIakg/BixWUsuSmSgtNoy/3+d7gzVD9URR022hqOcKnsRrt1zbgKD2qglwoh3bx2HM2qySscGAKs ShoyRj8lxCOgb6kLAm1UlyqMw2nkFPRGNK4A== Received: from mail2.augustcellars.com (192.168.1.201) by mail4.augustcellars.com (192.168.1.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Sun, 25 Jun 2017 23:57:32 -0700 Received: from Hebrews (24.21.96.37) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Sun, 25 Jun 2017 23:57:27 -0700 From: Jim Schaad To: CC: Date: Sun, 25 Jun 2017 23:57:29 -0700 Message-ID: <032e01d2ee49$7b9102d0$72b30870$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdLuSUIA9jg9fX0PRLqxOCY4T4hzZg== X-Originating-IP: [24.21.96.37] Archived-At: Subject: [Ace] draft-ietf-ace-cbor-web-token X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 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, 26 Jun 2017 06:57:40 -0000 Are the authors planning to do anything with the external data option that is part of the COSE specification? I realize that this is not part of JWT and thus including it would lead to a difference between the specifications, but as I was working to try and get my CWT implementation the question came up. The question also arose from my attempt to reproduce the examples in the document. Jim From nobody Mon Jun 26 02:41:12 2017 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 B4FD8129AB2 for ; Mon, 26 Jun 2017 02:41:10 -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, 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=spotify.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 HujHOgZyiNPH for ; Mon, 26 Jun 2017 02:41:08 -0700 (PDT) Received: from mail-ua0-x22a.google.com (mail-ua0-x22a.google.com [IPv6:2607:f8b0:400c:c08::22a]) (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 C88B5129A97 for ; Mon, 26 Jun 2017 02:41:08 -0700 (PDT) Received: by mail-ua0-x22a.google.com with SMTP id g40so64220341uaa.3 for ; Mon, 26 Jun 2017 02:41:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=spotify.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=gb8GtE8kEa/hNk/Nf7bo2gjlpgkuve8pOfh2E0uJu/o=; b=fws7e4Uhf1qUK/CX9ECygxy6uuwcLqu6AKmK3suXEUJtG2wVYq/JPVaox96tpB7IBr Bqv5YOrIc/dEz0cuOyTC/Ed9qJ11tYPHwR47AdwrAoevGTfuQ8pDOCPN83DFB6gTRZAc HMUV+boN1cccG4k8PttaowMefv3oM3a7B3lKE= 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=gb8GtE8kEa/hNk/Nf7bo2gjlpgkuve8pOfh2E0uJu/o=; b=NHYUC2GNF4SAQe26NQG6DKV+KNFs2Q+FjYBXnF7mwysvKIJnxA2GTDtPdwbEI8pY5V CkpEwp5XxTaQvVg6jSbh0eYCtyMFXDnwZN7v3S0zcPh+sE8FAXFGF+Abwh3L5+3fBAsk CFyXdYKqB2wSLfv3yS2Mr33v3seACVv1WhwxOVVGCu4qfG2aq4ktv3NuvPf6hdIPDPFB 2cY4I2eoRvITGmzyMxtveaysg1ZbS5N/8UUxL29zpTsax/Hvk8wqIewlHj5ZK971AG2+ BIjpzR/LMWvF+NMNvce7Zq+zTj85m6nana4TqY0hLuVwREvTod7rZ0ExblgIxWt7j5CM qV+A== X-Gm-Message-State: AKS2vOxzqolN1gwEZ3eaj6xUD/q2eE1z+lGOjjmvjBLt8QEedDH+IzXr Kly+jW2TwV0pHwq4qHjO/gxlOtmud0t3 X-Received: by 10.176.74.8 with SMTP id q8mr13587509uae.2.1498470067917; Mon, 26 Jun 2017 02:41:07 -0700 (PDT) MIME-Version: 1.0 References: <032e01d2ee49$7b9102d0$72b30870$@augustcellars.com> In-Reply-To: <032e01d2ee49$7b9102d0$72b30870$@augustcellars.com> From: Samuel Erdtman Date: Mon, 26 Jun 2017 09:40:57 +0000 Message-ID: To: Jim Schaad , draft-ietf-ace-cbor-web-token@ietf.org Cc: ace@ietf.org Content-Type: multipart/alternative; boundary="f403045f6d641af3e50552d9c091" Archived-At: Subject: Re: [Ace] draft-ietf-ace-cbor-web-token X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 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, 26 Jun 2017 09:41:11 -0000 --f403045f6d641af3e50552d9c091 Content-Type: text/plain; charset="UTF-8" We have no plans to use external data in CWT. As you pointed out it would move us further form JWT something that we have actively tried to avoid. On Mon, Jun 26, 2017 at 8:57 AM Jim Schaad wrote: > Are the authors planning to do anything with the external data option that > is part of the COSE specification? I realize that this is not part of JWT > and thus including it would lead to a difference between the > specifications, > but as I was working to try and get my CWT implementation the question came > up. The question also arose from my attempt to reproduce the examples in > the document. > > Jim > > > --f403045f6d641af3e50552d9c091 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
We have no plans to use=C2=A0exter= nal data in CWT. As you pointed out it would move us further form JWT somet= hing that we have actively=C2=A0tried to avoid.

On Mon, Jun 26, 2017 at 8:57 AM Jim Schaa= d <ietf@augustcellars.com&= gt; wrote:
Are the authors planning= to do anything with the external data option that
is part of the COSE specification?=C2=A0 I realize that this is not part of= JWT
and thus including it would lead to a difference between the specifications= ,
but as I was working to try and get my CWT implementation the question came=
up.=C2=A0 The question also arose from my attempt to reproduce the examples= in
the document.

Jim


--f403045f6d641af3e50552d9c091-- From nobody Tue Jun 27 00:50:34 2017 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 1E88C12EC00; Tue, 27 Jun 2017 00:50:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=augustcellars.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 w-ZKlGDQHfSc; Tue, 27 Jun 2017 00:50:31 -0700 (PDT) Received: from mail4.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 534A212EBFF; Tue, 27 Jun 2017 00:50:28 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1498549823; h=from:subject:to:date:message-id; bh=eYJGi067gSmIrEsrEriU/VJE+Qh1Xgwrsu/U0HmYMok=; b=XpoMRxqUyaO+nzuDWdKgI4x7u3kiT4fQtwevl9mQ45sqVT7hRVsUe7I842iojWWZUdVtJZzwp40 qLryhMK3PN8dSQGcwQBTuYAdree5VlqZ38EYwlzAIub5I7Lxp9pe5Uz0H+WRk5TyYzHj/UdBd090z 9IHJ8ym+OsjxpPEkhQqa+MBSg7jiWhFC79+usrQuZisG4s3DkSXuQTAVkAV4bNhzKlyoOx7v2Yjz0 Q/516fcADslg+ZjAC9G5AeCcSXCtYLBE2eASdQ6xpP58INA4SLkOVnq2cmwAcNCzmRKSRgg5fWB63 nF9QsAX37BtBs0haGz5izGGZDuHM6atoWLxg== Received: from mail2.augustcellars.com (192.168.1.201) by mail4.augustcellars.com (192.168.1.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 27 Jun 2017 00:50:22 -0700 Received: from Hebrews (24.21.96.37) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 27 Jun 2017 00:50:17 -0700 From: Jim Schaad To: CC: Date: Tue, 27 Jun 2017 00:50:19 -0700 Message-ID: <003701d2ef1a$07b13d90$1713b8b0$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdLu/J6lZrWV1b3ERWqpqeX4U+jwQA== X-Originating-IP: [24.21.96.37] Archived-At: Subject: [Ace] Review of draft-jones-ace-cwt-proof-of-possession-00 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 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, 27 Jun 2017 07:50:33 -0000 Abstract - I am unclear how this is a profile of RFC 7800 rather than a restatement of that document. In what way does this qualify as a profile? Introduction - I do not understand the second half of the first sentence in the introduction. It claims that the document is going to show how proof of possession is done, however this seems to be explicitly declared as out of scope in section 3.5. Section 2 - Since this document is currently planned to come from the ACE working group, I would suggest that it would be reasonable to provide the equivalent terminology to what is in this document. -- see actors Section 3 - para 1 - missed a s/JSON/CBOR/ Section 3 - para 2 - I am not sure of the following: - Why this is included here and not a separate section - Why the concept of an anonymous POP is not supported - Why the concept of the issuer being inferred from the authentication key on the CWT is not supported - I will note that draft-ietf-ace-oauth-authz does not require either of these fields to be present. Section 3.1 - The first two sentences seems to be slightly contradictory - the first says the cnf claim is used to identify the POP key. The second states that it may have something other than a POP key in it. Section 3.1 - I am not a fan of MUST ignore statements at this level. It should be profile statement if anything. Section 3.1 - last paragraph - Does this mean that only one claim can be in the cnf claim - or are some values of different levels? For example -can I have a COSE_Key and an Kid? This might be considered to be multiple POP keys. Section 3.2 - Profiles can require that additional elements can be required in the COSE_Key element - and example would be to require that the algorithm identifier be present. Section 3.2 - I do not understand why this paragraph is doing in this section give the section title. Why is it not in section 3.3 or in a separate section. I think it makes mores sense at the end of the next section. Section 3.3 - Why is title not symmetric with section 3.2 and the word encrypted be absent? Section 3.4 - This section just makes me uncomfortable. Use a value that was potentially chosen for collisions does not seem to be a good idea. I think this really needs some additional guidance about using. Section 4 - Is there any reason to suppose that the use of asymmetric secrets are immune from replay attacks? Section 3.1 - para 1 -sentence #2 - I do not understand the implication that the POP key implies the authenticity of the token. That statement makes no sense to me. This would look like a self-signed certificate as the authentication point. Jim From nobody Thu Jun 29 18:00:39 2017 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 AD68F1200F3; Thu, 29 Jun 2017 18:00:37 -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.55.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149878443767.4674.4797415641493496745@ietfa.amsl.com> Date: Thu, 29 Jun 2017 18:00:37 -0700 Archived-At: Subject: [Ace] I-D Action: draft-ietf-ace-cbor-web-token-06.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jun 2017 01:00:38 -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 of the IETF. Title : CBOR Web Token (CWT) Authors : Michael B. Jones Erik Wahlstr枚m Samuel Erdtman Hannes Tschofenig Filename : draft-ietf-ace-cbor-web-token-06.txt Pages : 24 Date : 2017-06-29 Abstract: CBOR Web Token (CWT) is a compact means of representing claims to be transferred between two parties. The claims in a CWT are encoded in the Concise Binary Object Representation (CBOR) and CBOR Object Signing and Encryption (COSE) is used for added application layer security protection. A claim is a piece of information asserted about a subject and is represented as a name/value pair consisting of a claim name and a claim value. CWT is derived from JSON Web Token (JWT), but uses CBOR rather than JSON. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ace-cbor-web-token/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ace-cbor-web-token-06 https://datatracker.ietf.org/doc/html/draft-ietf-ace-cbor-web-token-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-cbor-web-token-06 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 Thu Jun 29 18:05:52 2017 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 DB88F124D85 for ; Thu, 29 Jun 2017 18:05:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.801 X-Spam-Level: X-Spam-Status: No, score=-4.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 uZCOWpw7Rn5o for ; Thu, 29 Jun 2017 18:05:48 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0127.outbound.protection.outlook.com [104.47.32.127]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B6B01200F3 for ; Thu, 29 Jun 2017 18:05:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=vtJrbWbmev+buyQaeA9r1ZzpObQLAd+oUD6ZqDpEY54=; b=Elax9OKLAni0sWZgrL2aua3/qT+D5xLQD23jL8boKHcLHjmIW1L6s4njzD+IcSdnd9CUH/EktS7icID7dOOZ4tUwtk/6QssCgZOWYDylJFTiLjWfqlL+iQDT+v5tH2sOHK6gtiCTnHOM2feqbm95gyANvaz+rHjGcFF+bk27lBU= Received: from DM5PR21MB0505.namprd21.prod.outlook.com (10.172.91.139) by DM5PR21MB0121.namprd21.prod.outlook.com (10.173.173.8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1240.4; Fri, 30 Jun 2017 01:05:46 +0000 Received: from DM5PR21MB0505.namprd21.prod.outlook.com ([10.172.91.139]) by DM5PR21MB0505.namprd21.prod.outlook.com ([10.172.91.139]) with mapi id 15.01.1240.005; Fri, 30 Jun 2017 01:05:46 +0000 From: Mike Jones To: "ace@ietf.org" Thread-Topic: CBOR Web Token (CWT) specification addressing editorial comments Thread-Index: AdLxO16J6T5X7ZENRNyd2/kSBrL4Vg== Date: Fri, 30 Jun 2017 01:05:46 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Ref=https://api.informationprotection.azure.com/api/72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=mbj@microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2017-06-29T18:05:45.3522972-07:00; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic; Sensitivity=General authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:4898:80e8:4::36] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR21MB0121; 7:pxCZ/DLdkvSJ8eDi3BSPXa+QUG5inWdRIjFp6cu8w05YGpFHs0d3P1/IqnrN1IeXg4zZDGY+TK9KzC2GTb0fO5/Pk5d7PP2sE8FCog0XL/lp/fPn2o+zOdIU90hFuNZ4FR2DS/0jwaqLZGXNK1qrLuOLbnBJJ+DYy0gLXFayNx41qZSwBY+oaiCZwBBhb4pXlHZngb5tXd2Dm8gq3pk2fAddR5RX2pxTTP9rC0myoW+Lwexs1wcNAVBWcXf9wSG21hYbJDuUcPboof+nKnWrHbcl1p0Sk0ConXDOytjGcJjrgyPVqRz7JvEasn2mfYr3zcUr0TLs8QF8H4dHgsxhTpu9kyzZr3C1+n3bUvgcFep6vj6acRW2ZmR4D64OpyDHMzXNOQRd4msrRnWqp7/A8RhuKpCYBrj5PHGyNENCWG2AK0qKSoXpbgKHaYMS+TDAK2ICKG0L1ldGLFUaDrpVNn1HmMbUfx8ZkPpQp95Q7mEcODjjFlZY6IzSH1MfMdyhtFxaJngCc0zMD4NA8R2pGTjKtVI2pwl3nFNEIUpKQsnf6gTqACCm70kBoydiIwHm8hZT6DSuWrooUJKB4m3/egomXYcy31F7U3gnoWuPYNfMAhd/8bKYLy43DI9kNp+2q8B/MAqWw6+d+4+ZI8XRdSt3gROIOatxNd7WdluYKd0MeBelwijOgK2T8LYowYB3bmLL1x8LXC2zxcPQ0yA8wjnm8eI3+BT9YnxnvqX91sIjOKhMFn2DfpFua/9qMaGkKRQBgUQq3hOFJgov70MhN14kuHTjSv91V1x1VqmKSbS9dnw387HaGkLMqnMZAMp3 x-ms-office365-filtering-correlation-id: c3843505-5f75-4bdd-f3e2-08d4bf5423f0 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(48565401081)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:DM5PR21MB0121; x-ms-traffictypediagnostic: DM5PR21MB0121: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(151999592597050)(26388249023172)(236129657087228)(31418570063057)(148574349560750)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(601004)(2401047)(8121501046)(5005006)(2017060910019)(100000703101)(100105400095)(93006095)(93001095)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123555025)(20161123560025)(20161123562025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM5PR21MB0121; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM5PR21MB0121; x-forefront-prvs: 0354B4BED2 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39450400003)(39410400002)(39400400002)(39850400002)(39860400002)(39840400002)(209900001)(2351001)(33656002)(2501003)(2906002)(6506006)(5640700003)(3280700002)(6436002)(3660700001)(25786009)(7736002)(6116002)(189998001)(790700001)(102836003)(5660300001)(74316002)(77096006)(966005)(72206003)(14454004)(7696004)(478600001)(53936002)(6916009)(10290500003)(99286003)(55016002)(54896002)(6306002)(236005)(9686003)(110136004)(53376002)(38730400002)(5630700001)(5005710100001)(10090500001)(1730700003)(8990500004)(8676002)(81156014)(81166006)(8936002)(86612001)(2900100001)(86362001)(606006)(54356999)(50986999)(6606295002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR21MB0121; H:DM5PR21MB0505.namprd21.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR21MB0505E30B1990C095378C4464F5D30DM5PR21MB0505namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Jun 2017 01:05:46.6140 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR21MB0121 Archived-At: Subject: [Ace] CBOR Web Token (CWT) specification addressing editorial comments X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 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, 30 Jun 2017 01:05:51 -0000 --_000_DM5PR21MB0505E30B1990C095378C4464F5D30DM5PR21MB0505namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable A new CBOR Web Token (CWT) draft has been published that addresses editoria= l comments made by Carsten Bormann and Jim Schaad. All changes were editor= ial in nature. The specification is available at: * https://tools.ietf.org/html/draft-ietf-ace-cbor-web-token-06 An HTML-formatted version is also available at: * http://self-issued.info/docs/draft-ietf-ace-cbor-web-token-06.html -- Mike P.S. This notice was also posted at http://self-issued.info/?p=3D1707 and = as @selfissued. --_000_DM5PR21MB0505E30B1990C095378C4464F5D30DM5PR21MB0505namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

A new CBOR Web Token (CWT) draft has been published = that addresses editorial comments made by Carsten Bormann and Jim Schaad.&n= bsp; All changes were editorial in nature.

 

The specification is available at:

 

An HTML-formatted version is also available at:=

 

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;     -- Mike

 

P.S.  This notice was also posted at http://self-issued.info/?p=3D1707 and as @selfissued.

--_000_DM5PR21MB0505E30B1990C095378C4464F5D30DM5PR21MB0505namp_-- From nobody Thu Jun 29 19:03:16 2017 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 95D36129C1E for ; Thu, 29 Jun 2017 19:03:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 cUme39PDBDlO for ; Thu, 29 Jun 2017 19:03:12 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0128.outbound.protection.outlook.com [104.47.36.128]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38608124D68 for ; Thu, 29 Jun 2017 19:03:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=VEL6nmacQEm4XNmIa7cg3ok0qU7mZoXRp/7j2Tdr/JY=; b=fqLQnoGQ1UTrV4HjkyGWGL1JToW5mmp20ZWFBwvNnpqIaFKge07RsqFdblv+uAsdBV67ZpsEwbN4NIzI1XOro60SrkmJBpExn/lCv9zIf1xaaIfvV5Vwo8ANE5hEatAD5arj6mL5yU4MAkYtXsZq5t9d9rPyhf8d8V93Bbb6H2I= Received: from CY4PR21MB0504.namprd21.prod.outlook.com (10.172.122.14) by CY4PR21MB0134.namprd21.prod.outlook.com (10.173.189.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1240.3; Fri, 30 Jun 2017 02:03:10 +0000 Received: from CY4PR21MB0504.namprd21.prod.outlook.com ([10.172.122.14]) by CY4PR21MB0504.namprd21.prod.outlook.com ([10.172.122.14]) with mapi id 15.01.1240.007; Fri, 30 Jun 2017 02:03:09 +0000 From: Mike Jones To: Michael Richardson CC: "ace@ietf.org" Thread-Topic: [Ace] Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs) Thread-Index: AdK6Bb2+fFzDaH8tQi+ibomgYAgxlwZIdZqAB4cwfRA= Date: Fri, 30 Jun 2017 02:03:09 +0000 Message-ID: References: <10297.1495477009@obiwan.sandelman.ca> In-Reply-To: <10297.1495477009@obiwan.sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Ref=https://api.informationprotection.azure.com/api/72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=mbj@microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2017-06-29T19:03:08.1902884-07:00; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic; Sensitivity=General authentication-results: sandelman.ca; dkim=none (message not signed) header.d=none; sandelman.ca; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:4898:80e8:1::36] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR21MB0134; 7:GYsUTGy6RA057mn55CVrZoX4hl8LQf3UJn3KESztqXl4dNK4h2AdVoNGdbOStR1tOK/Y4I8IetVxaRb0ZOjv+psL1opHud2gz6fttG7zcE+3wKo1P6Ddn1UgA+lhmGs7Smmvdp0XqqHrYdwNWLOWIfaJtlR9cQD9RCt3ZlE1DxbsKpXvEHUXcbPWqtnBHfZZHEn0WtpNsCFDZFvL2uwIgxm3lbZLPsYBYvwyjkbNxzmOfwWZbfJq3HJFe7gn0QF8OYZ/vy0QFCg1spFFfYjaWdOwt17TMxZEvTNBbosLDNWpR2XO2IQvYkUlMxrDD4vZhamw/7sC2M81+zAqWwAUUZP3svEV12NsQJ7bOOYbyfh0shyR8NF/IvJiFyHeZma0F//PEFmVwIqYqzhxtOkGG6oos7uoz36t3IN2ll2Tlv0wCFHnmd4ys5J/8fSA35zmJK/egNWtp1bcxsWWYC/PwSQhzVkGt4iPXELjQ9JTwepHzDYccaVNHqCduAtKaW703RCQblOeOfCh4QrRBdXmOMReH4iEVsmudtH0tt1pJO7I/hk57z0k3Nm8a6NXvop1b8ppBqy5iBvmVN/BaQO0aVRp0iLLT6zKIu2jEQDQgT8A+nGT+3954YO9hWFEFIPKsGYRRmrXrWUvV3RIV31xzv1YPruHyQHP9DnZsrySbFflB49AqYiifEACHOhqKn80B0e9vAOcVVXqo2MsPOcv8IoYy5GqjjPsmXe7Pp+oyPKxQSEq3EOJwIqHE1ld8MK8852/lUg/Pto6OGZ9pLWEvJFv5Cjlka4Oj/nYGNmIHaIWEdIvpQcgg0posxtFmCn1 x-ms-office365-filtering-correlation-id: 7dcdccd4-a539-42b4-88a1-08d4bf5c282f x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(48565401081)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:CY4PR21MB0134; x-ms-traffictypediagnostic: CY4PR21MB0134: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(278178393323532)(278428928389397)(236129657087228)(148574349560750); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(601004)(2401047)(8121501046)(5005006)(2017060910019)(10201501046)(93006095)(93001095)(100000703101)(100105400095)(3002001)(6055026)(61426038)(61427038)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123564025)(20161123558100)(20161123562025)(20161123560025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR21MB0134; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR21MB0134; x-forefront-prvs: 0354B4BED2 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39410400002)(39840400002)(39860400002)(39450400003)(39850400002)(39400400002)(51444003)(13464003)(377454003)(478600001)(189998001)(6116002)(102836003)(76176999)(54356999)(50986999)(8936002)(8676002)(81166006)(2900100001)(3660700001)(2906002)(230783001)(3280700002)(86362001)(53936002)(6246003)(8990500004)(5005710100001)(6436002)(10090500001)(6506006)(9686003)(55016002)(2950100002)(110136004)(5660300001)(38730400002)(77096006)(7696004)(99286003)(25786009)(14454004)(7736002)(86612001)(305945005)(4326008)(74316002)(10290500003)(72206003)(33656002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0134; H:CY4PR21MB0504.namprd21.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Jun 2017 02:03:09.6620 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0134 Archived-At: Subject: Re: [Ace] Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs) X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 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, 30 Jun 2017 02:03:14 -0000 Thanks, Michael. My editors draft now corrects the JSON -> CBOR issue. Jim Schaad also commented on the second paragraph. The editors draft relax= es its requirements to give profiles or applications full flexibility on ho= w to identify the presenter. After giving the editors of draft-ietf-ace-oauth-authz a chance to have a l= ook at the new draft, I plan to publish it in a day or so. I'd be glad to talk with you in person in Prague about the needs of the new= work you mention below and how to meet them. Best wishes, -- Mike -----Original Message----- From: Ace [mailto:ace-bounces@ietf.org] On Behalf Of Michael Richardson Sent: Monday, May 22, 2017 11:17 AM To: Mike Jones Cc: ace@ietf.org Subject: Re: [Ace] Proof-of-Possession Key Semantics for CBOR Web Tokens (C= WTs) Come to the discussion late, cleaning my inbox. section 3 says: "The value of the cnf claim is a JSON object and the members of that o= bject identify the proof-of-possession key." And somehow, I think that the claim ought to be a CBOR object? Same for the paragraph of 3.4. I found the next paragraph about whether the sub or iss is the presenter to= be obtuse. Maybe it is lacking some ACE RS/C/AS terminology? I am trying to figure out if the nonce-full mechanism that we describe in d= raft-ietf-anima-bootstrapping-keyinfra or anima-voucher, and later to be re= -interpreted as CWT in draft-ietf-6tisch-dtsecurity-secure-join should refe= rence RFC 7800 and this document instead. -- Michael Richardson , Sandelman Software Works -=3D = IPv6 IoT consulting =3D- From nobody Thu Jun 29 19:21:27 2017 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 8007A12EB03; Thu, 29 Jun 2017 19:21:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 nBe8RhHw10za; Thu, 29 Jun 2017 19:21:23 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0128.outbound.protection.outlook.com [104.47.38.128]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0896F129B74; Thu, 29 Jun 2017 19:21:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=iRiDXz2QxZt8d1lqJOSXe38CCfKbyP6Ft5ub6whzsAE=; b=Dwwn6uwkMwj+vN5+XucobOAazhPZHaus+F27FgYbbwo0nJ8Dq++uDjubKSZP4SJhT8KAkSVoNtmA3O2BsIgpLciyWVHxOMtjrT7QORkt20B+BXtZpUDyFKceqokAJJl62SbL5cH7Jr7Qso8Xz7iDS8qVz5Dui+tiAcJnv/SJrKg= Received: from CY4PR21MB0504.namprd21.prod.outlook.com (10.172.122.14) by CY4PR21MB0133.namprd21.prod.outlook.com (10.173.189.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1240.3; Fri, 30 Jun 2017 02:21:21 +0000 Received: from CY4PR21MB0504.namprd21.prod.outlook.com ([10.172.122.14]) by CY4PR21MB0504.namprd21.prod.outlook.com ([10.172.122.14]) with mapi id 15.01.1240.007; Fri, 30 Jun 2017 02:21:20 +0000 From: Mike Jones To: Jim Schaad , "draft-jones-ace-cwt-proof-of-possession@ietf.org" CC: "ace@ietf.org" Thread-Topic: Review of draft-jones-ace-cwt-proof-of-possession-00 Thread-Index: AdLu/J6lZrWV1b3ERWqpqeX4U+jwQACSHobQ Date: Fri, 30 Jun 2017 02:21:20 +0000 Message-ID: References: <003701d2ef1a$07b13d90$1713b8b0$@augustcellars.com> In-Reply-To: <003701d2ef1a$07b13d90$1713b8b0$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Ref=https://api.informationprotection.azure.com/api/72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=mbj@microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2017-06-29T19:21:19.0068059-07:00; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic; Sensitivity=General authentication-results: augustcellars.com; dkim=none (message not signed) header.d=none;augustcellars.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:4898:80e8:1::36] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR21MB0133; 7:MikNBGt0vkDnUG/ReQvhyCTusHZHWsg2AeXdqBIzVm8KpOHgBP4lOTpmXq14qym3GRs/Tmid7dq4L6+hqv0yz1Nq0kZR1aOFwI+nzUuMlwtlRcdG9KWYwhHM5GCDfgYxEk1ZqmAnbau61t+97FJaFHruOkugx701BDhy7F22zgge7GLu9ix7GEm7SSvIOtI7JY89oCwfUE0vtc9gFqa4kjW6UedDmcEsV/ovTkA1242VSqgDn2ZRHoJ5fIQUEHFu35xDJgtwDqbE2rTy9HqOuK8GijkqtX48pC9D83dsXJslR63j94Ip831oawuggK7ULvHRVqugR7gvSmJcmMW1eQnXoIty+z6hoN7Jp3E6+26LaYZUr+uSrPd9U03q6lF3aunP5QC9T0K14pVgLBNqimBEwaufMhG18tfM9zO4js0d6OPZd/VKfaGrKqs0SW8j4qN0zZ9vX3YfLvACOjEWa5rROeATm7XVAIzxTfQxbv6qBG5UchbliTTeiOu/h1doEjP4gCWAU2SFwtH0XlWE+AXBjpRBlNaK5eJumDjNygz1+Mpifcp8iQ4spBe9H+izjsrcuopJ4dSFlRTNVDoKcBgc+az4/pe8io2Ity+nepyyTtSr24gfga9LfMjerwk8/WMT2KPLu3qUF6LQV7G47RupoV+v1ogx40Q2AlxHaGEuVJZIrwmeIF/9WQBy118wPMVu5NG3suUxvCXN/Hm3gAoDBlfc2oKy7XbXZOICEiuXYbZSi0dLXTH6EVWzK33CdEoUsaJBtVWUtJfBJNqJzfp/IhziiEzECLhffQMNFigJnVveOK1s0/qEiTx+rPp7 x-ms-office365-filtering-correlation-id: 1bcca759-af37-45fa-3f1a-08d4bf5eb290 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(48565401081)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:CY4PR21MB0133; x-ms-traffictypediagnostic: CY4PR21MB0133: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(151999592597050)(278178393323532)(26388249023172)(236129657087228)(192374486261705)(131327999870524)(48057245064654)(148574349560750)(21748063052155)(247924648384137); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(601004)(2401047)(8121501046)(2017060910020)(5005006)(3002001)(10201501046)(100000703101)(100105400095)(93006095)(93001095)(6055026)(61426038)(61427038)(6041248)(20161123560025)(20161123555025)(20161123564025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR21MB0133; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR21MB0133; x-forefront-prvs: 0354B4BED2 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39410400002)(39850400002)(39400400002)(39840400002)(39860400002)(39450400003)(377454003)(13464003)(43784003)(6506006)(2906002)(3660700001)(6436002)(3280700002)(99286003)(10090500001)(4326008)(54896002)(6306002)(72206003)(86612001)(2950100002)(9686003)(55016002)(7696004)(25786009)(53936002)(76176999)(790700001)(54356999)(5660300001)(8990500004)(86362001)(6116002)(2900100001)(2501003)(50986999)(74316002)(38730400002)(6246003)(189998001)(102836003)(5005710100001)(7736002)(478600001)(8676002)(33656002)(14454004)(8936002)(77096006)(81166006)(10290500003)(230783001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0133; H:CY4PR21MB0504.namprd21.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR21MB0504EE43C72886D487CA2A11F5D30CY4PR21MB0504namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Jun 2017 02:21:20.8148 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0133 Archived-At: Subject: Re: [Ace] Review of draft-jones-ace-cwt-proof-of-possession-00 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 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, 30 Jun 2017 02:21:26 -0000 --_000_CY4PR21MB0504EE43C72886D487CA2A11F5D30CY4PR21MB0504namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks for your useful review, Jim. Replies are inline below... -----Original Message----- From: Jim Schaad [mailto:ietf@augustcellars.com] Sent: Tuesday, June 27, 2017 12:50 AM To: draft-jones-ace-cwt-proof-of-possession@ietf.org Cc: ace@ietf.org Subject: Review of draft-jones-ace-cwt-proof-of-possession-00 Abstract - I am unclear how this is a profile of RFC 7800 rather than a restatement of that document. In what way does this qualify as a profile? The draft now says that it provides equivalent functionality to RFC 7800 ra= ther than being a profile of it. Introduction - I do not understand the second half of the first sentence in= the introduction. It claims that the document is going to show how proof = of possession is done, however this seems to be explicitly declared as out = of scope in section 3.5. You're right. I have deleted the second half. Section 2 - Since this document is currently planned to come from the ACE w= orking group, I would suggest that it would be reasonable to provide the e= quivalent terminology to what is in this document. -- see actors Maybe we can talk about specific proposed edits in Prague. Section 3 - para 1 - missed a s/JSON/CBOR/ Fixed Section 3 - para 2 - I am not sure of the following: - Why this is included here and not a separate section It was here in RFC 7800. It could be moved and given its own section but w= anted to start out with a completely parallel document. - Why the concept of an anonymous POP is not supported I assume you're talking about a situation in which the identity of the pres= enter is not known or revealed? I assume this is related to your next comm= ent? - Why the concept of the issuer being inferred from the authentication key = on the CWT is not supported If this is done in practice, particularly within ACE, this could be explici= tly mentioned in the future. - I will note that draft-ietf-ace-oauth-authz does not require either of th= ese fields to be present. Thanks for pointing this out. I've removed this requirement to give profil= es full freedom of how to identify the presenter. Section 3.1 - The first two sentences seems to be slightly contradictory - = the first says the cnf claim is used to identify the POP key. The second s= tates that it may have something other than a POP key in it. It's really about saying that "confirmation" is broader than "confirmation-= by-PoP". This draft covers the latter, but defines the "cnf" claim to enab= le the broader uses, as in SAML 2.0. I'll think about how to word this mor= e clearly. Section 3.1 - I am not a fan of MUST ignore statements at this level. It s= hould be profile statement if anything. The "MUST be ignored" is essential for future extensibility. Otherwise, an= ything new added breaks everything already deployed. Section 3.1 - last paragraph - Does this mean that only one claim can be in= the cnf claim - or are some values of different levels? For example -can = I have a COSE_Key and an Kid? This might be considered to be multiple POP = keys. As long as the "kid" refers to the same key, you're golden. I think it alr= eady says that somewhere, but I'll look into it further. Section 3.2 - Profiles can require that additional elements can be required= in the COSE_Key element - and example would be to require that the algorit= hm identifier be present. That's fine. The spec already says that other key elements can be included= . Section 3.2 - I do not understand why this paragraph is doing in this secti= on give the section title. Why is it not in section 3.3 or in a separate s= ection. I think it makes mores sense at the end of the next section. Public keys are represented in the clear. That's different than the symmet= ric keys in 3.3, which have to be encrypted to prevent them from being reve= aled. Section 3.3 - Why is title not symmetric with section 3.2 and the word encr= ypted be absent? See the previous reply Section 3.4 - This section just makes me uncomfortable. Use a value that w= as potentially chosen for collisions does not seem to be a good idea. I th= ink this really needs some additional guidance about using. If both parties already have the key, using a Key ID rather than transmitti= ng the key is an optimization that is used in practice. What else would yo= u like us to say about this? Section 4 - Is there any reason to suppose that the use of asymmetric secre= ts are immune from replay attacks? Is there particular Security Considerations text that you'd like to see inc= luded about this? Section 3.1 - para 1 -sentence #2 - I do not understand the implication t= hat the POP key implies the authenticity of the token. That statement make= s no sense to me. This would look like a self-signed certificate as the a= uthentication point. See the SAML 2.0 comment earlier. Jim I plan to publish an updated version in the next day or so, after giving th= e authors of draft-ietf-ace-oauth-authz a chance to look it over. Thanks agai= n, -- Mike --_000_CY4PR21MB0504EE43C72886D487CA2A11F5D30CY4PR21MB0504namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks for your use= ful review, Jim.  Replies are inline below...

 

-----Original Message-----
From: Jim Schaad [mailto:ietf@augustcellars.com]
Sent: Tuesday, June 27, 2017 12:50 AM
To: draft-jones-ace-cwt-proof-of-possession@ietf.org
Cc: ace@ietf.org
Subject: Review of draft-jones-ace-cwt-proof-of-possession-00

 

Abstract - I am unclear how this is a profile of = RFC 7800 rather than a

restatement of that document.   In what= way does this qualify as a profile?

 

The draft now says = that it provides equivalent functionality to RFC 7800 rather than being a p= rofile of it.

 

Introduction - I do not understand the second hal= f of the first sentence in the introduction.  It claims that the docum= ent is going to show how proof of possession is done, however this seems to= be explicitly declared as out of scope in section 3.5.

 

You’re right.=   I have deleted the second half.

 

Section 2 - Since this document is currently plan= ned to come from the ACE working group,  I would suggest that it would= be reasonable to provide the equivalent terminology to what is in this doc= ument. -- see actors

 

Maybe we can talk a= bout specific proposed edits in Prague.

 

Section 3 - para 1 - missed  a s/JSON/CBOR/<= o:p>

 

Fixed

 

Section 3 - para 2 - I am not sure of the followi= ng:

- Why this is included here and not a separate se= ction

 

It was here in RFC = 7800.  It could be moved and given its own section but wanted to start= out with a completely parallel document.

 

- Why the concept of an anonymous POP is not supp= orted

 

I assume you’= re talking about a situation in which the identity of the presenter is not = known or revealed?  I assume this is related to your next comment?

 

- Why the concept of the issuer being inferred fr= om the authentication key on the CWT is not supported

 

If this is done in = practice, particularly within ACE, this could be explicitly mentioned in th= e future.

 

- I will note that draft-ietf-ace-oauth-authz doe= s not require either of these fields to be present.

 

Thanks for pointing= this out.  I’ve removed this requirement to give profiles full = freedom of how to identify the presenter.

 

Section 3.1 - The first two sentences seems to be= slightly contradictory - the first says the cnf claim is used to identify = the POP key.  The second states that it may have something other than = a POP key in it.

 

It’s really a= bout saying that “confirmation” is broader than “confirma= tion-by-PoP”.  This draft covers the latter, but defines the = 220;cnf” claim to enable the broader uses, as in SAML 2.0.  I= 217;ll think about how to word this more clearly.

 

Section 3.1 - I am not a fan of MUST ignore state= ments at this level.  It should be  profile statement if anything= .

 

The “MUST be = ignored” is essential for future extensibility.  Otherwise, anyt= hing new added breaks everything already deployed.

 

Section 3.1 - last paragraph - Does this mean tha= t only one claim can be in the cnf claim - or are some values of different = levels?  For example -can I have a COSE_Key and an Kid?  This mig= ht be considered to be multiple POP keys.

 

As long as the R= 20;kid” refers to the same key, you’re golden.  I think it= already says that somewhere, but I’ll look into it further.

 

Section 3.2 - Profiles can require that additiona= l elements can be required in the COSE_Key element - and example would be t= o require that the algorithm identifier be present.

 

That’s fine.&= nbsp; The spec already says that other key elements can be included.=

 

Section 3.2 - I do not understand why this paragr= aph is doing in this section give the section title.  Why is it not in= section 3.3 or in a separate section.  I think it makes mores sense a= t the end of the next section.

 

Public keys are rep= resented in the clear.  That’s different than the symmetric keys= in 3.3, which have to be encrypted to prevent them from being revealed.

 

Section 3.3 - Why is title not symmetric with sec= tion 3.2 and the word encrypted be absent?

 

See the previous re= ply

 

Section 3.4 - This section just makes me uncomfor= table.  Use a value that was potentially chosen for collisions does no= t seem to be a good idea.  I think this really needs some additional g= uidance about using.

 

If both parties alr= eady have the key, using a Key ID rather than transmitting the key is an op= timization that is used in practice.  What else would you like us to s= ay about this?

 

Section 4 - Is there any reason to suppose that t= he use of asymmetric secrets are immune from replay attacks?

 

Is there particular= Security Considerations text that you’d like to see included about t= his?

 

Section 3.1 - para 1 -sentence #2  -  I= do not understand the implication that the POP key implies the authenticit= y of the token.  That statement makes no sense to me.  This would= look  like a self-signed certificate as the authentication point.

 

See the SAML 2.0 co= mment earlier.

 

Jim

 

I plan to publish a= n updated version in the next day or so, after giving the authors of draft-= ietf-ace-oauth-authz a chance to look it over.

 

   &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;          Thanks again,

   &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;          -- Mike

 

--_000_CY4PR21MB0504EE43C72886D487CA2A11F5D30CY4PR21MB0504namp_-- From nobody Fri Jun 30 15:17:53 2017 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 64BAE127977; Fri, 30 Jun 2017 15:17:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-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 ykqtOS7a7B-2; Fri, 30 Jun 2017 15:17:48 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 87432126E3A; Fri, 30 Jun 2017 15:17:45 -0700 (PDT) Received: from thinny.local (69-12-173-8.static.dsltransport.net [69.12.173.8]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by colo.trepanning.net (Postfix) with ESMTPSA id 07B38102241C4; Fri, 30 Jun 2017 15:17:25 -0700 (PDT) To: draft-selander-ace-cose-ecdhe.all@ietf.org From: Dan Harkins Cc: ace@ietf.org Message-ID: <81bbd539-7389-af94-7c95-7b6226619632@lounge.org> Date: Fri, 30 Jun 2017 15:17:19 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Ace] review of ace-cose-ecdhe X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 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, 30 Jun 2017 22:17:50 -0000 Hello, I reviewed the latest version of this draft from https://ericssonresearch.githum.io/EDHOC. I hope it's not too late to get these in before the cut-off, if too late then please consider them as comments on -07. My comments are as follows: -- Technical o Consider the ability to use a deterministic AEAD The definition of Enc() in section 2 makes it look deterministic but the mandatory algorithm (CCM) is not. I know that cose doesn't define how to use SIV (RFC 5297) but perhaps this draft should. I hope you don't consider this as a mere request for a vanity cipher. SIV does not need additional randomness, counters, or tweaks. It is, in that sense, misuse resistant and ideal for use in a key management protocol like EDHOC because it removes the possibility of a security critical error being accidentally performed. If you choose to accept this comment you'll need to not just add SIV to your IANA Considerations, you'll need to make reference in section 3.2 the fact that an IV is not needed for deterministic AEAD algorithms. A related comment, in section 3 it says "The application data may e.g. be protected using the negotiated AEAD algorithm". The "e.g" is superfluous but what if one desires to not do that, how is the cipher for the application data negotiated with EDHOC? o Use compact representation per RFC 6090 The draft says, in section 3.1, that for EC2 curves to use point compression. There is contention regarding IP on point compression. (draft-ietf-cose-msg says in 13.1.1, this "encoding has not been recommended in the IETF due to potential IPR issues.")Better to specify the use of "compact representation" and "compact output" per RFC 6090. Since this draft is just doing ECDH there is no need for any indication of which y-coordinate should be used, it doesn't matter if it's y or -y. And it saves a whole byte! :-) o Validate received points when doing EC2 curves When using EC2 curves, the ephemeral keys in the first two messages need to be validated as points on the curve. If you use "compact representation" per RFC 6090 then it's a matter of checking whether there is a solution to the curve definition for the given x. If you choose not to use "compact representation" per RFC 6090 then you'll need to make sure that received points (once uncompressed) are valid points on the curve. This needs reference among the other verification checks in 4.2.3 and 4.3.3 (for asymmetric EDHOC), and 5.2.3 and 5.3.3 (for symmetric EDHOC) which result in an error message if they fail. -- Editorial o Section 2, seconded bulleted paragraph, it is "full-fledged" with a "d". o In 4.3.3 last paragraph, Party U should send the error message back, right? Not Party V. This is a very well-written draft and I am happy to see SIGMA being applied to every layer of the stack. regards, Dan. From nobody Fri Jun 30 19:06:22 2017 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 3C80E131503 for ; Fri, 30 Jun 2017 19:06:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, 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=microsoft.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 UaEktCCPuNP2 for ; Fri, 30 Jun 2017 19:06:20 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0134.outbound.protection.outlook.com [104.47.32.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31E4F131511 for ; Fri, 30 Jun 2017 19:06:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=UCk25aEDcirIEvy9Aah0Ii9mSPjKADjbUJPqxoIjzQ0=; b=THmcNg8CY/jcAaOBTG91i6fVSbR63KU00w13aNcGuxMnfKp/OAFgebJiU62tobq2MG/+LFImv7yTyPPoz/UYjsfo1q3gispyxZtuNFryQpTjiG5ycreiOW2RcODqHaqmYnSgP9pDoSHqLgGItQ3dQFDLJeILOEZn8zceOyIn8Sg= Received: from BN6PR21MB0500.namprd21.prod.outlook.com (10.172.112.10) by BN6PR21MB0628.namprd21.prod.outlook.com (10.175.131.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1240.4; Sat, 1 Jul 2017 02:06:15 +0000 Received: from BN6PR21MB0500.namprd21.prod.outlook.com ([10.172.112.10]) by BN6PR21MB0500.namprd21.prod.outlook.com ([10.172.112.10]) with mapi id 15.01.1240.006; Sat, 1 Jul 2017 02:06:15 +0000 From: Mike Jones To: "ace@ietf.org" Thread-Topic: Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs) spec addressing review comments Thread-Index: AdLyCpPQiHCGZlkCQ/+P8qcd/FvqXw== Date: Sat, 1 Jul 2017 02:06:15 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Ref=https://api.informationprotection.azure.com/api/72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=mbj@microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2017-06-30T19:06:13.1439987-07:00; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic; Sensitivity=General authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [50.47.93.167] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN6PR21MB0628; 7:0/qnAvP2EOMwlFc0l5f9J1D9VYJaPl7ioCWfYPT3nDCOcDrQLMCyRgo4AMMVlceBA5praA4luCQLgBh0w2J3d29m6CR0fgZAl6nPkG3mHnHIW/wLx6G8IdW/ol8b/nnOMVUKAyi8Njvt+4JcU8MiEAYdX4cIWvKbuTgaPe2VDjNoKRBIhY4+cF0rmUbv7LfA44XzWEhuMmYRxAdw4h8vO2GaKLgcosknoQ7Ufu9U9F+Sjzua+5kqw5gGG4pvFl5ojdM5m8tCcinufzpoBvJUev82VHPQJFcYpxVaoBcbAGp0aQ95M9oW90S1uD5BnlTz88GvdxMEo5NR/GIOk0hRpmcDCfTdXcZmWyjlp4y/eSGs+SRKJevzEFvZo++VLOsSuDeh37Gde98yeaIu+qFpwGvnwbYT7szekhUr/Pg5IzBJf6O7FYHRw3Mzfyr8yYGIVTEdvI9PVsaTBpU7hSFFW8knwfOzNuyfek7kq21rFLhSBkV2TZ1KbLYN43Z8SBrIOZez7BYs9b03xVVLMwANRIfupH9kghaji7XhEwyvtbWsVC9O/+edeXDsouYBb2lA7N2LMBrYJzsFkGdYXWz1uPjw3yzDtyJydlyxf78CQbWTZhQ6t1SMom8PQVZk8bdJ2aP59etGLC3spAfjd9xW+/BG0RKIZ5xx9YCJ7xTe/bQZ6wjS9sPxVPzSKAjKwO9gxhESjqlTKFjBFgH8RksgPKPY9Y2Sazc8kiKf/HtqqCe941i5BOq4mLksnyN43ANRmTyVXAPuChPbvTW5p+d2S1KARZQ7BAeU+ixl5v99phoozo42FNgWDcgR0uPPt7tF x-ms-office365-filtering-correlation-id: 9dc27ec4-c68d-4695-5da3-08d4c025c13c x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(48565401081)(2017052603031)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BN6PR21MB0628; x-ms-traffictypediagnostic: BN6PR21MB0628: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(151999592597050)(26388249023172)(236129657087228)(31418570063057)(148574349560750)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(601004)(2401047)(8121501046)(2017060910020)(5005006)(3002001)(10201501046)(93006095)(93001095)(100000703101)(100105400095)(6055026)(61426038)(61427038)(6041248)(20161123560025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123558100)(20161123564025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN6PR21MB0628; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN6PR21MB0628; x-forefront-prvs: 0355F3A3AE x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39840400002)(39860400002)(39400400002)(39850400002)(39410400002)(39450400003)(209900001)(51914003)(5660300001)(189998001)(2351001)(54356999)(5640700003)(99286003)(1730700003)(10290500003)(66066001)(236005)(10090500001)(3280700002)(6916009)(790700001)(3846002)(110136004)(38730400002)(7696004)(53936002)(54896002)(53376002)(50986999)(6306002)(606006)(2906002)(55016002)(8676002)(3660700001)(9686003)(81166006)(86362001)(7736002)(86612001)(6116002)(2501003)(5005710100001)(72206003)(6506006)(478600001)(966005)(8936002)(5630700001)(6436002)(77096006)(8990500004)(230783001)(14454004)(33656002)(74316002)(102836003)(25786009)(2900100001)(6606295002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR21MB0628; H:BN6PR21MB0500.namprd21.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN6PR21MB0500DF608C2B6635B34650E2F5D00BN6PR21MB0500namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Jul 2017 02:06:15.2489 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR21MB0628 Archived-At: Subject: [Ace] Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs) spec addressing review comments X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 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: Sat, 01 Jul 2017 02:06:22 -0000 --_000_BN6PR21MB0500DF608C2B6635B34650E2F5D00BN6PR21MB0500namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs) specificat= ion has been updated to address comments received since its initial publica= tion. Changes were: * Tracked CBOR Web Token (CWT) Claims Registry updates. * Addressed review comments by Michael Richardson and Jim Schaad. * Added co-authors Ludwig Seitz, G=F6ran Selander, Erik Wahlstr=F6m, Sa= muel Erdtman, and Hannes Tschofenig. Thanks for the feedback received to date! The specification is available at: * https://tools.ietf.org/html/draft-jones-ace-cwt-proof-of-possession-0= 1 An HTML-formatted version is also available at: * http://self-issued.info/docs/draft-jones-ace-cwt-proof-of-possession-= 01.html -- Mike P.S. This notice was also posted at http://self-issued.info/?p=3D1711 and = as @selfissued. --_000_BN6PR21MB0500DF608C2B6635B34650E2F5D00BN6PR21MB0500namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

The Proof-of-Possession Key Semantics for CBOR Web T= okens (CWTs) specification has been updated to address comments received si= nce its initial publication.  Changes were:

  • Tracked CBOR Web Token (CWT) Claims Registry updates.
    • =
  • Addressed review comments by Michael Richardson and Jim Schaad.<= /o:p>
  • Added co-authors Ludwig Seitz, G=F6ran Selander, Erik Wahls= tr=F6m, Samuel Erdtman, and Hannes Tschofenig.

 

Thanks for the feedback received to date!=

 

The specification is available at:

 

An HTML-formatted version is also available at:=

 

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;        -- Mike

 

P.S.  This notice was also posted at http://self-issued.info/?p=3D1711 and as @selfissued.

--_000_BN6PR21MB0500DF608C2B6635B34650E2F5D00BN6PR21MB0500namp_--