From nobody Thu Dec 6 01:38:53 2018 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 C5867131126 for ; Thu, 6 Dec 2018 01:38:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 st2qV6i4VUHa for ; Thu, 6 Dec 2018 01:38:49 -0800 (PST) Received: from smtprelay.hostedemail.com (smtprelay0108.hostedemail.com [216.40.44.108]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEA3213111D for ; Thu, 6 Dec 2018 01:38:48 -0800 (PST) Received: from filter.hostedemail.com (clb03-v110.bra.tucows.net [216.40.38.60]) by smtprelay02.hostedemail.com (Postfix) with ESMTP id B78E42C68; Thu, 6 Dec 2018 09:38:47 +0000 (UTC) X-Session-Marker: 73746F6B636F6E73406262686D61696C2E6E6C X-Spam-Summary: 2, -10, 0, , d41d8cd98f00b204, stokcons@bbhmail.nl, :::, RULES_HIT:41:72:152:355:379:582:599:800:962:967:973:983:988:989:1152:1189:1208:1212:1221:1260:1313:1314:1345:1431:1436:1437:1516:1517:1518:1534:1541:1575:1588:1589:1592:1594:1711:1730:1777:1792:2068:2069:2198:2199:2525:2528:2553:2559:2566:2570:2682:2685:2691:2693:2703:2859:2911:2933:2937:2939:2942:2945:2947:2951:2954:3022:3352:3865:3866:3867:3868:3871:3872:3873:3874:3934:3936:3938:3941:3944:3947:3950:3953:3956:3959:4250:4321:4361:4425:4470:4860:5007:6117:6261:7875:7903:8568:8603:8660:9010:9025:9040:9177:10004:10400:11658:12379:12740:13139:13148:13230, 0, RBL:216.40.42.5:@bbhmail.nl:.lbl8.mailshell.net-62.8.55.100 66.201.201.201, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF:not bulk, SPF:fn, MSBL:0, DNSBL:neutral, Custom_rules:0:0:0, LFtime:27, LUA_SUMMARY:none X-HE-Tag: list82_1287c9ca3e05d X-Filterd-Recvd-Size: 3974 Received: from mail.bbhmail.nl (imap-ext [216.40.42.5]) (Authenticated sender: webmail@stokcons@bbhmail.nl) by omf01.hostedemail.com (Postfix) with ESMTPA; Thu, 6 Dec 2018 09:38:47 +0000 (UTC) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_9f13b5716f1a4f1be5e7f1ed2206e2f3" Date: Thu, 06 Dec 2018 10:38:46 +0100 From: Peter van der Stok To: Roman Danyliw Cc: ace@ietf.org Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <359EC4B99E040048A7131E0F4E113AFC0184C52E29@marathon> References: <359EC4B99E040048A7131E0F4E113AFC0184C52E29@marathon> Message-ID: X-Sender: stokcons@bbhmail.nl User-Agent: Roundcube Webmail/1.2.7 X-Originating-IP: [5.206.216.229] Archived-At: Subject: Re: [Ace] Call for adoption of draft-palombini-ace-key-groupcomm X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2018 09:38:52 -0000 --=_9f13b5716f1a4f1be5e7f1ed2206e2f3 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII I support the adoption of this draft. It is the right solution to our secure group communication wishes. Peter Roman Danyliw schreef op 2018-11-30 22:58: > Hello! > > This is the start of a two week call for input on the WG adoption of the document: > > draft-palombini-ace-key-groupcomm > https://tools.ietf.org/html/draft-palombini-ace-key-groupcomm-02 > > The document has been presented and discussed at the last few meetings; and revisions have been made based on WG feedback. At the IETF 103 meeting, there was support for adoption; and volunteers to review and implement the draft. > > Please provide feedback to the list/chairs if you believe that this document should be adopted as a WG document. The adoption call will end on December 14 2018. > > Regards, > Roman and Jim > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace --=_9f13b5716f1a4f1be5e7f1ed2206e2f3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8 I support the adoption of this draft.
It is the right solution to our = secure group communication wishes.

Peter

Roman Danyliw schreef op 2018-11-30 22:58:

= Hello!

This is the start of a two week call for input on the WG= adoption of the document:

draft-palombini-ace-key-groupcommhttps://tools.ietf.org/html/draft= -palombini-ace-key-groupcomm-02

The document has been prese= nted and discussed at the last few meetings; and revisions have been made b= ased on WG feedback.  At the IETF 103 meeting, there was support for a= doption; and volunteers to review and implement the draft.

Ple= ase provide feedback to the list/chairs if you believe that this document s= hould be adopted as a WG document.    The adoption call will= end on December 14 2018.

Regards,
Roman and Jim
_______________________________________________
Ace mailing list<= br />Ace@ietf.orghttps://www.ietf.org/mailman/listinfo/ace
--=_9f13b5716f1a4f1be5e7f1ed2206e2f3-- From nobody Thu Dec 6 01:40:04 2018 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 A058A131127 for ; Thu, 6 Dec 2018 01:40:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 11NoZW7ZE7Qr for ; Thu, 6 Dec 2018 01:40:02 -0800 (PST) Received: from smtprelay.hostedemail.com (smtprelay0156.hostedemail.com [216.40.44.156]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECE60131123 for ; Thu, 6 Dec 2018 01:40:01 -0800 (PST) Received: from filter.hostedemail.com (clb03-v110.bra.tucows.net [216.40.38.60]) by smtprelay04.hostedemail.com (Postfix) with ESMTP id 16C0D180A8873; Thu, 6 Dec 2018 09:40:01 +0000 (UTC) X-Session-Marker: 73746F6B636F6E73406262686D61696C2E6E6C X-Spam-Summary: 2, -10, 0, , d41d8cd98f00b204, stokcons@bbhmail.nl, :::, RULES_HIT:41:72:152:355:379:582:599:800:962:967:973:983:988:989:1152:1189:1208:1212:1221:1260:1313:1314:1345:1431:1436:1437:1516:1517:1518:1534:1541:1575:1588:1589:1592:1594:1711:1730:1777:1792:2068:2069:2198:2199:2525:2528:2553:2559:2566:2570:2682:2685:2691:2693:2703:2859:2911:2933:2937:2939:2942:2945:2947:2951:2954:3022:3352:3865:3866:3867:3868:3871:3872:3873:3874:3934:3936:3938:3941:3944:3947:3950:3953:3956:3959:4250:4321:4361:4425:4860:5007:6117:6261:7875:7903:8603:8660:9010:9025:9040:9177:10004:10400:11658:12379:12740:13139:13148:13230, 0, RBL:216.40.42.5:@bbhmail.nl:.lbl8.mailshell.net-62.8.55.100 66.201.201.201, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF:not bulk, SPF:fn, MSBL:0, DNSBL:neutral, Custom_rules:0:0:0, LFtime:29, LUA_SUMMARY:none X-HE-Tag: soda84_1d36586cc3651 X-Filterd-Recvd-Size: 3930 Received: from mail.bbhmail.nl (imap-ext [216.40.42.5]) (Authenticated sender: webmail@stokcons@bbhmail.nl) by omf06.hostedemail.com (Postfix) with ESMTPA; Thu, 6 Dec 2018 09:40:00 +0000 (UTC) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_9290fce2d338e0a5623945032513a018" Date: Thu, 06 Dec 2018 10:40:00 +0100 From: Peter van der Stok To: Roman Danyliw Cc: ace@ietf.org Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <359EC4B99E040048A7131E0F4E113AFC0184C52E21@marathon> References: <359EC4B99E040048A7131E0F4E113AFC0184C52E21@marathon> Message-ID: <13c3fef46ddf1a160eead1619aefaeb5@bbhmail.nl> X-Sender: stokcons@bbhmail.nl User-Agent: Roundcube Webmail/1.2.7 X-Originating-IP: [5.206.216.229] Archived-At: Subject: Re: [Ace] Call for adoption of draft-tiloca-ace-oscoap-joining X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2018 09:40:04 -0000 --=_9290fce2d338e0a5623945032513a018 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII I support the adoption of this draft. It is fulfils our group commuication requirements. Peter Roman Danyliw schreef op 2018-11-30 22:58: > Hello! > > This is the start of a two week call for input on the WG adoption of the document: > > draft-tiloca-ace-oscoap-joining > https://tools.ietf.org/html/draft-tiloca-ace-oscoap-joining-05 > > The document has been presented and discussed at the last few meetings; and revisions have been made based on WG feedback. At the IETF 103 meeting, there was support for adoption; and volunteers to review and implement the draft. > > Please provide feedback to the list/chairs if you believe that this document should be adopted as a WG document. The adoption call will end on December 14 2018. > > Regards, > Roman and Jim > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace --=_9290fce2d338e0a5623945032513a018 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8 I support the adoption of this draft.
It is fulfils our group commuica= tion requirements.

Peter

Roman Danyliw schreef op 2018-11-30 22:58:

= Hello!

This is the start of a two week call for input on the WG= adoption of the document:

draft-tiloca-ace-oscoap-joining
https://tools.ietf.org/html/draft-til= oca-ace-oscoap-joining-05

The document has been presented a= nd discussed at the last few meetings; and revisions have been made based o= n WG feedback.  At the IETF 103 meeting, there was support for adoptio= n; and volunteers to review and implement the draft.

Please pr= ovide feedback to the list/chairs if you believe that this document should = be adopted as a WG document.    The adoption call will end o= n December 14 2018.

Regards,
Roman and Jim

__= _____________________________________________
Ace mailing list
<= a href=3D"mailto:Ace@ietf.org" rel=3D"noreferrer">Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
--=_9290fce2d338e0a5623945032513a018-- From nobody Thu Dec 6 13:19:35 2018 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 570431311ED for ; Thu, 6 Dec 2018 13:19:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.958 X-Spam-Level: X-Spam-Status: No, score=-15.958 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 kQGsi70iVRoy for ; Thu, 6 Dec 2018 13:19:24 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 424CB1311CA for ; Thu, 6 Dec 2018 13:19:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11018; q=dns/txt; s=iport; t=1544131164; x=1545340764; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=DdIRN1I0LAn9ei3SJmpgglTjc39jyBFdXvv7rRua1XI=; b=SQlHjlLzRV+QDrse8+LzWTBinfOGcKBwyvQxXvx4qyLtX3ek8IBjM6mA Ds/eCivvkNqIjHaCap/KtnKuZ8b/Ip0HyHG9Az4B4Q1q5tEHPeENYahE5 WxGHxiSHQrBEmzGYwScRQtPhlE/bh+ONpJjq6KtEcLNuJjddwVbNfqbbv o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AEAAAJkQlc/4QNJK1jGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBUQUBAQEBCwGBDXZmgQInCoNwiBmMD4INkXiFVhSBZgsBARg?= =?us-ascii?q?BCoRJAheCfiI0CQ0BAwEBAgEBAm0cDIU8AQEBBAEBGwYKQQsQAgEIDgMEAQE?= =?us-ascii?q?oAwICAiULFAkIAQEEDgUIE4MHgR1kD6YxgS+EMQIOQIUkBYwfF4FAP4Qjgx4?= =?us-ascii?q?BAQMBgSFTH4JOglcCiT6FYYZNinMJAoZAQoo6IIFchRWKRY16imsCERSBJx8?= =?us-ascii?q?4gVVwFTuCbIschT9BMYoigR8BAQ?= X-IronPort-AV: E=Sophos;i="5.56,323,1539648000"; d="scan'208,217";a="492509622" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Dec 2018 21:19:23 +0000 Received: from XCH-RCD-008.cisco.com (xch-rcd-008.cisco.com [173.37.102.18]) by alln-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id wB6LJNQc028894 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 6 Dec 2018 21:19:23 GMT Received: from xch-aln-010.cisco.com (173.36.7.20) by XCH-RCD-008.cisco.com (173.37.102.18) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 6 Dec 2018 15:19:22 -0600 Received: from xch-aln-010.cisco.com ([173.36.7.20]) by XCH-ALN-010.cisco.com ([173.36.7.20]) with mapi id 15.00.1395.000; Thu, 6 Dec 2018 15:19:22 -0600 From: "Panos Kampanakis (pkampana)" To: Roman Danyliw CC: "ace@ietf.org" Thread-Topic: [Ace] Call for adoption of draft-palombini-ace-key-groupcomm Thread-Index: AdSI8aalNXFev0zyRSiL4RjyZD+fmQEiB/EAAAtsJwA= Date: Thu, 6 Dec 2018 21:19:22 +0000 Message-ID: References: <359EC4B99E040048A7131E0F4E113AFC0184C52E29@marathon> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.180.46] Content-Type: multipart/alternative; boundary="_000_ec88e41e364b4cafb416b276875bb92dXCHALN010ciscocom_" MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.37.102.18, xch-rcd-008.cisco.com X-Outbound-Node: alln-core-10.cisco.com Archived-At: Subject: Re: [Ace] Call for adoption of draft-palombini-ace-key-groupcomm X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2018 21:19:33 -0000 --_000_ec88e41e364b4cafb416b276875bb92dXCHALN010ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 KzEuIEkgdGhpbmsgdGhpcyBpcyBhIHByb2JsZW0gdGhhdCBuZWVkcyB0byBiZSBzb2x2ZWQuDQoN CkJ1dCBJIGRvIHRoaW5rIHRoYXQgdGhlIE9BdXRoIG9yIFB1YlN1YiByZXF1aXJlbWVudCBpcyBh IHN0cm9uZyBvbmUuIEkgd291bGQgbGlrZSB0byBzZWUgaWYgdGhlIE1MUyB3b3JrIGNvdWxkIGJl IHVzZWQgaW4gdGhlc2UgZW52aXJvbm1lbnRzIHRvbyBodHRwczovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9kcmFmdC1pZXRmLW1scy1wcm90b2NvbC8gVXNpbmcgdGhlIE9BdXRoIGRyYWZ0IG9y IHRoZSBQdWJTdWIgb25lIGZvciBhdXRob3JpemF0aW9uIGFuZCBncm91cCBqb2luIGlzIGZpbmUs IGJ1dCB0aGVyZSB3aWxsIGJlIGVudmlyb25tZW50cyB3aGVyZSB0aGF0IHdpbGwgbm90IGJlIHBv c3NpYmxlLCBzbyBJIHdhcyB3b25kZXJpbmcgaWYgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LWlldGYtbWxzLXByb3RvY29sLTAyIGNvdWxkIGJlIGxldmVyYWdlZC4NCg0KUmdzLA0K UGFub3MNCg0KRnJvbTogQWNlIDxhY2UtYm91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIFBl dGVyIHZhbiBkZXIgU3Rvaw0KU2VudDogVGh1cnNkYXksIERlY2VtYmVyIDA2LCAyMDE4IDQ6Mzkg QU0NClRvOiBSb21hbiBEYW55bGl3IDxyZGRAY2VydC5vcmc+DQpDYzogYWNlQGlldGYub3JnDQpT dWJqZWN0OiBSZTogW0FjZV0gQ2FsbCBmb3IgYWRvcHRpb24gb2YgZHJhZnQtcGFsb21iaW5pLWFj ZS1rZXktZ3JvdXBjb21tDQoNCkkgc3VwcG9ydCB0aGUgYWRvcHRpb24gb2YgdGhpcyBkcmFmdC4N Ckl0IGlzIHRoZSByaWdodCBzb2x1dGlvbiB0byBvdXIgc2VjdXJlIGdyb3VwIGNvbW11bmljYXRp b24gd2lzaGVzLg0KDQpQZXRlcg0KDQpSb21hbiBEYW55bGl3IHNjaHJlZWYgb3AgMjAxOC0xMS0z MCAyMjo1ODoNCkhlbGxvIQ0KDQpUaGlzIGlzIHRoZSBzdGFydCBvZiBhIHR3byB3ZWVrIGNhbGwg Zm9yIGlucHV0IG9uIHRoZSBXRyBhZG9wdGlvbiBvZiB0aGUgZG9jdW1lbnQ6DQoNCmRyYWZ0LXBh bG9tYmluaS1hY2Uta2V5LWdyb3VwY29tbQ0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LXBhbG9tYmluaS1hY2Uta2V5LWdyb3VwY29tbS0wMg0KDQpUaGUgZG9jdW1lbnQgaGFzIGJl ZW4gcHJlc2VudGVkIGFuZCBkaXNjdXNzZWQgYXQgdGhlIGxhc3QgZmV3IG1lZXRpbmdzOyBhbmQg cmV2aXNpb25zIGhhdmUgYmVlbiBtYWRlIGJhc2VkIG9uIFdHIGZlZWRiYWNrLiAgQXQgdGhlIElF VEYgMTAzIG1lZXRpbmcsIHRoZXJlIHdhcyBzdXBwb3J0IGZvciBhZG9wdGlvbjsgYW5kIHZvbHVu dGVlcnMgdG8gcmV2aWV3IGFuZCBpbXBsZW1lbnQgdGhlIGRyYWZ0Lg0KDQpQbGVhc2UgcHJvdmlk ZSBmZWVkYmFjayB0byB0aGUgbGlzdC9jaGFpcnMgaWYgeW91IGJlbGlldmUgdGhhdCB0aGlzIGRv Y3VtZW50IHNob3VsZCBiZSBhZG9wdGVkIGFzIGEgV0cgZG9jdW1lbnQuICAgIFRoZSBhZG9wdGlv biBjYWxsIHdpbGwgZW5kIG9uIERlY2VtYmVyIDE0IDIwMTguDQoNClJlZ2FyZHMsDQpSb21hbiBh bmQgSmltDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQpBY2UgbWFpbGluZyBsaXN0DQpBY2VAaWV0Zi5vcmc8bWFpbHRvOkFjZUBpZXRmLm9yZz4NCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYWNlDQo= --_000_ec88e41e364b4cafb416b276875bb92dXCHALN010ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpWZXJkYW5hOw0KCXBhbm9zZS0xOjIgMTEg NiA0IDMgNSA0IDQgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwg bGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRv bTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBS b21hbiIsc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6 dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2lu LXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDow aW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixz ZXJpZjt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21z by1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJn aW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0 OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4i LHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJl cGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7 DQoJZm9udC13ZWlnaHQ6bm9ybWFsOw0KCWZvbnQtc3R5bGU6bm9ybWFsOw0KCXRleHQtZGVjb3Jh dGlvbjpub25lIG5vbmU7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0 LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4 LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3Jk U2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBt c28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYi IC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBl bGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0K PC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0i RU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rp b24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij4mIzQzOzEuIEkgdGhpbmsgdGhpcyBpcyBhIHByb2JsZW0gdGhhdCBuZWVkcyB0byBiZSBzb2x2 ZWQuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkJ1dCBJIGRv IHRoaW5rIHRoYXQgdGhlIE9BdXRoIG9yIFB1YlN1YiByZXF1aXJlbWVudCBpcyBhIHN0cm9uZyBv bmUuIEkgd291bGQgbGlrZSB0byBzZWUgaWYgdGhlIE1MUyB3b3JrIGNvdWxkIGJlIHVzZWQgaW4g dGhlc2UgZW52aXJvbm1lbnRzIHRvbw0KPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvZHJhZnQtaWV0Zi1tbHMtcHJvdG9jb2wvIj5odHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9kcmFmdC1pZXRmLW1scy1wcm90b2NvbC88L2E+IFVzaW5nIHRoZSBPQXV0aCBk cmFmdCBvciB0aGUgUHViU3ViIG9uZSBmb3IgYXV0aG9yaXphdGlvbiBhbmQgZ3JvdXAgam9pbiBp cyBmaW5lLCBidXQgdGhlcmUgd2lsbCBiZSBlbnZpcm9ubWVudHMgd2hlcmUgdGhhdCB3aWxsDQog bm90IGJlIHBvc3NpYmxlLCBzbyBJIHdhcyB3b25kZXJpbmcgaWYgPGEgaHJlZj0iaHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbWxzLXByb3RvY29sLTAyIj4NCmh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW1scy1wcm90b2NvbC0wMjwvYT4gY291bGQg YmUgbGV2ZXJhZ2VkLiA8bzpwPg0KPC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+UmdzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5QYW5vczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj4gQWNlICZsdDthY2UtYm91bmNlc0BpZXRmLm9yZyZndDsNCjxiPk9u IEJlaGFsZiBPZiA8L2I+UGV0ZXIgdmFuIGRlciBTdG9rPGJyPg0KPGI+U2VudDo8L2I+IFRodXJz ZGF5LCBEZWNlbWJlciAwNiwgMjAxOCA0OjM5IEFNPGJyPg0KPGI+VG86PC9iPiBSb21hbiBEYW55 bGl3ICZsdDtyZGRAY2VydC5vcmcmZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBhY2VAaWV0Zi5vcmc8YnI+ DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtBY2VdIENhbGwgZm9yIGFkb3B0aW9uIG9mIGRyYWZ0LXBh bG9tYmluaS1hY2Uta2V5LWdyb3VwY29tbTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZiI+SSBzdXBwb3J0IHRoZSBhZG9wdGlvbiBv ZiB0aGlzIGRyYWZ0Ljxicj4NCkl0IGlzIHRoZSByaWdodCBzb2x1dGlvbiB0byBvdXIgc2VjdXJl IGdyb3VwIGNvbW11bmljYXRpb24gd2lzaGVzLjxicj4NCjxicj4NClBldGVyPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmIj5Sb21hbiBEYW55bGl3IHNjaHJlZWYgb3Ag MjAxOC0xMS0zMCAyMjo1ODo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8YmxvY2txdW90ZSBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgIzEwMTBGRiAxLjVwdDtwYWRkaW5nOjBp biAwaW4gMGluIDUuMHB0O21hcmdpbi1sZWZ0OjBpbjttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+SGVsbG8hPGJyPg0KPGJyPg0KVGhpcyBp cyB0aGUgc3RhcnQgb2YgYSB0d28gd2VlayBjYWxsIGZvciBpbnB1dCBvbiB0aGUgV0cgYWRvcHRp b24gb2YgdGhlIGRvY3VtZW50Ojxicj4NCjxicj4NCmRyYWZ0LXBhbG9tYmluaS1hY2Uta2V5LWdy b3VwY29tbTxicj4NCjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1w YWxvbWJpbmktYWNlLWtleS1ncm91cGNvbW0tMDIiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtcGFsb21iaW5pLWFjZS1rZXktZ3JvdXBjb21tLTAyPC9h Pjxicj4NCjxicj4NClRoZSBkb2N1bWVudCBoYXMgYmVlbiBwcmVzZW50ZWQgYW5kIGRpc2N1c3Nl ZCBhdCB0aGUgbGFzdCBmZXcgbWVldGluZ3M7IGFuZCByZXZpc2lvbnMgaGF2ZSBiZWVuIG1hZGUg YmFzZWQgb24gV0cgZmVlZGJhY2suICZuYnNwO0F0IHRoZSBJRVRGIDEwMyBtZWV0aW5nLCB0aGVy ZSB3YXMgc3VwcG9ydCBmb3IgYWRvcHRpb247IGFuZCB2b2x1bnRlZXJzIHRvIHJldmlldyBhbmQg aW1wbGVtZW50IHRoZSBkcmFmdC4NCjxicj4NCjxicj4NClBsZWFzZSBwcm92aWRlIGZlZWRiYWNr IHRvIHRoZSBsaXN0L2NoYWlycyBpZiB5b3UgYmVsaWV2ZSB0aGF0IHRoaXMgZG9jdW1lbnQgc2hv dWxkIGJlIGFkb3B0ZWQgYXMgYSBXRyBkb2N1bWVudC4gJm5ic3A7Jm5ic3A7Jm5ic3A7VGhlIGFk b3B0aW9uIGNhbGwgd2lsbCBlbmQgb24gRGVjZW1iZXIgMTQgMjAxOC48YnI+DQo8YnI+DQpSZWdh cmRzLDxicj4NClJvbWFuIGFuZCBKaW08YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCkFjZSBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBo cmVmPSJtYWlsdG86QWNlQGlldGYub3JnIj5BY2VAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0i aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hY2UiIHRhcmdldD0iX2JsYW5r Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FjZTwvYT48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9o dG1sPg0K --_000_ec88e41e364b4cafb416b276875bb92dXCHALN010ciscocom_-- From nobody Thu Dec 6 15:12:21 2018 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 E376F131213 for ; Thu, 6 Dec 2018 15:12:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 LemyVX58_0s7 for ; Thu, 6 Dec 2018 15:12:17 -0800 (PST) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31A68131201 for ; Thu, 6 Dec 2018 15:12:16 -0800 (PST) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 6 Dec 2018 15:07:10 -0800 From: Jim Schaad To: "'Panos Kampanakis (pkampana)'" CC: References: <359EC4B99E040048A7131E0F4E113AFC0184C52E29@marathon> In-Reply-To: Date: Thu, 6 Dec 2018 15:12:04 -0800 Message-ID: <000501d48db9$1c268660$54739320$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01D48D76.0E0430C0" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQIuqUJzav8esOPl4D/aDtd6BDGTaAIKoOswARXeGpmkpRldAA== Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Ace] Call for adoption of draft-palombini-ace-key-groupcomm X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2018 23:12:20 -0000 ------=_NextPart_000_0006_01D48D76.0E0430C0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I have not looked in detail at the mls protocol documents, but from what = I remember they have more or less skipped the entire AAA question of = having a central authorizer and made it so that any entity which is = currently active has the ability to add or remove anybody else. =20 That is not currently an authorization model that I think is currently = in scope for ACE. If I am wrong about my assumptions it would be = interesting to know. =20 Jim =20 =20 From: Ace On Behalf Of Panos Kampanakis = (pkampana) Sent: Thursday, December 6, 2018 1:19 PM To: Roman Danyliw Cc: ace@ietf.org Subject: Re: [Ace] Call for adoption of = draft-palombini-ace-key-groupcomm =20 +1. I think this is a problem that needs to be solved.=20 =20 But I do think that the OAuth or PubSub requirement is a strong one. I = would like to see if the MLS work could be used in these environments = too https://datatracker.ietf.org/doc/draft-ietf-mls-protocol/ Using the = OAuth draft or the PubSub one for authorization and group join is fine, = but there will be environments where that will not be possible, so I was = wondering if https://tools.ietf.org/html/draft-ietf-mls-protocol-02 = could be leveraged.=20 =20 Rgs, Panos =20 From: Ace > On = Behalf Of Peter van der Stok Sent: Thursday, December 06, 2018 4:39 AM To: Roman Danyliw > Cc: ace@ietf.org =20 Subject: Re: [Ace] Call for adoption of = draft-palombini-ace-key-groupcomm =20 I support the adoption of this draft. It is the right solution to our secure group communication wishes. Peter Roman Danyliw schreef op 2018-11-30 22:58: Hello! This is the start of a two week call for input on the WG adoption of the = document: draft-palombini-ace-key-groupcomm https://tools.ietf.org/html/draft-palombini-ace-key-groupcomm-02 The document has been presented and discussed at the last few meetings; = and revisions have been made based on WG feedback. At the IETF 103 = meeting, there was support for adoption; and volunteers to review and = implement the draft.=20 Please provide feedback to the list/chairs if you believe that this = document should be adopted as a WG document. The adoption call will = end on December 14 2018. Regards, Roman and Jim _______________________________________________ Ace mailing list Ace@ietf.org =20 https://www.ietf.org/mailman/listinfo/ace ------=_NextPart_000_0006_01D48D76.0E0430C0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

I have not = looked in detail at the mls protocol documents, but from what I remember = they have more or less skipped the entire AAA question of having a = central authorizer and made it so that any entity which is currently = active has the ability to add or remove anybody = else.

 

That is not = currently an authorization model that I think is currently in scope for = ACE.=C2=A0 If I am wrong about my assumptions it would be interesting to = know.

 

Jim

 

 

From:<= /b> = Ace <ace-bounces@ietf.org> On Behalf Of Panos Kampanakis = (pkampana)
Sent: Thursday, December 6, 2018 1:19 = PM
To: Roman Danyliw <rdd@cert.org>
Cc: = ace@ietf.org
Subject: Re: [Ace] Call for adoption of = draft-palombini-ace-key-groupcomm

 

+1. I think this is a problem that needs to be solved. =

 

But I do think that the OAuth or PubSub requirement is a strong one. I = would like to see if the MLS work could be used in these environments = too https:= //datatracker.ietf.org/doc/draft-ietf-mls-protocol/ Using the OAuth = draft or the PubSub one for authorization and group join is fine, but = there will be environments where that will not be possible, so I was = wondering if https://t= ools.ietf.org/html/draft-ietf-mls-protocol-02 could be leveraged. =

 

Rgs,

Panos

 

From:<= /b> = Ace <ace-bounces@ietf.org> On = Behalf Of Peter van der Stok
Sent: Thursday, December 06, = 2018 4:39 AM
To: Roman Danyliw <rdd@cert.org>
Cc: ace@ietf.org
Subject: Re: = [Ace] Call for adoption of = draft-palombini-ace-key-groupcomm

 

I support = the adoption of this draft.
It is the right solution to our secure = group communication wishes.

Peter

Roman = Danyliw schreef op 2018-11-30 22:58:

Hello!

This = is the start of a two week call for input on the WG adoption of the = document:

draft-palombini-ace-key-groupcomm
https://tools.ietf.org/html/draft-palombini-ace-key-gro= upcomm-02

The document has been presented and discussed at = the last few meetings; and revisions have been made based on WG = feedback.  At the IETF 103 meeting, there was support for adoption; = and volunteers to review and implement the draft.

Please provide = feedback to the list/chairs if you believe that this document should be = adopted as a WG document.    The adoption call will end = on December 14 2018.

Regards,
Roman and = Jim

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

------=_NextPart_000_0006_01D48D76.0E0430C0-- From nobody Fri Dec 7 08:37:03 2018 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 94FDD130E83 for ; Fri, 7 Dec 2018 08:37:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.959 X-Spam-Level: X-Spam-Status: No, score=-15.959 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 ypJuvYVBz7_d for ; Fri, 7 Dec 2018 08:37:00 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A79D0130E82 for ; Fri, 7 Dec 2018 08:37:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2981; q=dns/txt; s=iport; t=1544200620; x=1545410220; h=from:to:subject:date:message-id:mime-version; bh=eeil15OEqgYLS666XzI9c7Ltw6KgAcKj7LGf/bNYO4c=; b=NXVWIcX8ff+zHJCo8dtW0lgm7lFHU3v0+2c+ztnXDNTFA8c03x7k+ty2 er0/QMsTBHyLC3C4Yv/fVpvXoPjGBf21RHmAWTJP3L74ngw7H9/o3jBs2 U/TPRxOhEGrxaINd1B6DHmDiOBJCWe+YHizIxyYP7Y8lBwV4HZOyNZgsC 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AnAAANoQpc/5tdJa1jHAEBAQQBAQc?= =?us-ascii?q?EAQGBUQcBAQsBgQ12ZoECMYwJjBGUBYVXgXoLAQEfh2oiNAkNAQMBAQIBAQJ?= =?us-ascii?q?tHAELhWAQXgEMdCYBBBuDGoEdZKcPiikFjCIXgX+OfwKPI5B+RgkChwSKPSC?= =?us-ascii?q?ROIkQhHGBVokdAhEUgScfOCeBLnAVgyiLG4U/QYp+gR8BAQ?= X-IronPort-AV: E=Sophos;i="5.56,326,1539648000"; d="scan'208,217";a="210076933" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Dec 2018 16:36:59 +0000 Received: from XCH-RTP-003.cisco.com (xch-rtp-003.cisco.com [64.101.220.143]) by rcdn-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id wB7GawiO012099 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for ; Fri, 7 Dec 2018 16:36:59 GMT Received: from xch-rtp-005.cisco.com (64.101.220.145) by XCH-RTP-003.cisco.com (64.101.220.143) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 7 Dec 2018 11:36:58 -0500 Received: from xch-rtp-005.cisco.com ([64.101.220.145]) by XCH-RTP-005.cisco.com ([64.101.220.145]) with mapi id 15.00.1395.000; Fri, 7 Dec 2018 11:36:58 -0500 From: "Wouter van der Beek (wovander)" To: "ace@ietf.org" Thread-Topic: [Ace] Call for adoption of draft-palombini-ace-key-groupcomm Thread-Index: AdSOSsWKBWX0W3sSQ527V6YmLpD9Jg== Date: Fri, 7 Dec 2018 16:36:58 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.161.213] Content-Type: multipart/alternative; boundary="_000_aff82622c37a495c8b496cac2f0a2ab6XCHRTP005ciscocom_" MIME-Version: 1.0 X-Outbound-SMTP-Client: 64.101.220.143, xch-rtp-003.cisco.com X-Outbound-Node: rcdn-core-4.cisco.com Archived-At: Subject: [Ace] Call for adoption of draft-palombini-ace-key-groupcomm X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2018 16:37:02 -0000 --_000_aff82622c37a495c8b496cac2f0a2ab6XCHRTP005ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi +1 This is needed to overcome the current industry issue not having a secure m= ulticast mechanism. Kind Regards, Wouter van der Beek Technical Steering Committee Chair Open connectivity foundation https://openconnectivity.org/ --_000_aff82622c37a495c8b496cac2f0a2ab6XCHRTP005ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi

 

+1

This is needed to overcome the current industry issu= e not having a secure multicast mechanism.

 

 

Kind Regards,
Wouter van der Beek

Technical Steering Committee Chair

Open connectivity foundation

https://op= enconnectivity.org/

--_000_aff82622c37a495c8b496cac2f0a2ab6XCHRTP005ciscocom_-- From nobody Fri Dec 7 08:37:53 2018 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 F14E4130E8C for ; Fri, 7 Dec 2018 08:37:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.959 X-Spam-Level: X-Spam-Status: No, score=-15.959 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 uUudnsnh1q15 for ; Fri, 7 Dec 2018 08:37:50 -0800 (PST) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6050130E86 for ; Fri, 7 Dec 2018 08:37:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3029; q=dns/txt; s=iport; t=1544200670; x=1545410270; h=from:to:subject:date:message-id:mime-version; bh=eSMMyJl7J6nnbKC26vSeU6vXdJmViIpMDBFe+12omUk=; b=OGuR4saOQzbjcV1MM18Dmr9jBNW+CW7YRFtLHd2nDRA8HF5tKkmtYhmy kSGLFS/ZJkdf+JVUwsMpUq6dvSxQqj4WJPgShO99yWgBpir4YW4+6chtS 3MXdhCK7lELr5cUmVAl7X/Ua0Oc+oRGF2cMGowc4P93Nbpu2IzvAvwcz/ Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AnAADSoApc/5NdJa1jHAEBAQQBAQc?= =?us-ascii?q?EAQGBUQcBAQsBgQ12ZoECMYwJjBGUBYVXgXoLAQEfh2oiNAkNAQMBAQIBAQJ?= =?us-ascii?q?tHAELhWAQXgEMdCYBBBuDGoEdZKcOiikFjCIXgX+OfwKPI5B+RgkChwSKPSC?= =?us-ascii?q?ROIkQhHGBVokdAhEUgScfOCeBLnAVgyiLG4U/QYp+gR8BAQ?= X-IronPort-AV: E=Sophos;i="5.56,326,1539648000"; d="scan'208,217";a="209224722" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Dec 2018 16:37:49 +0000 Received: from XCH-RTP-005.cisco.com (xch-rtp-005.cisco.com [64.101.220.145]) by rcdn-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id wB7GbnZw032107 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for ; Fri, 7 Dec 2018 16:37:49 GMT Received: from xch-rtp-005.cisco.com (64.101.220.145) by XCH-RTP-005.cisco.com (64.101.220.145) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 7 Dec 2018 11:37:48 -0500 Received: from xch-rtp-005.cisco.com ([64.101.220.145]) by XCH-RTP-005.cisco.com ([64.101.220.145]) with mapi id 15.00.1395.000; Fri, 7 Dec 2018 11:37:48 -0500 From: "Wouter van der Beek (wovander)" To: "ace@ietf.org" Thread-Topic: [Ace] Call for adoption of draft-tiloca-ace-oscoap-joining Thread-Index: AdSOSyoBX9JmO3oaTa+0R8uqGXjjJA== Date: Fri, 7 Dec 2018 16:37:48 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.161.213] Content-Type: multipart/alternative; boundary="_000_c5b2f89748c64143889e47d869b7cad8XCHRTP005ciscocom_" MIME-Version: 1.0 X-Outbound-SMTP-Client: 64.101.220.145, xch-rtp-005.cisco.com X-Outbound-Node: rcdn-core-11.cisco.com Archived-At: Subject: [Ace] Call for adoption of draft-tiloca-ace-oscoap-joining X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2018 16:37:53 -0000 --_000_c5b2f89748c64143889e47d869b7cad8XCHRTP005ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi +1 This is needed to overcome the current industry issue not having a secure m= ulticast mechanism. Kind Regards, Wouter van der Beek Technical Steering Committee Chair Open connectivity foundation https://openconnectivity.org/ --_000_c5b2f89748c64143889e47d869b7cad8XCHRTP005ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi

 

+1

This is needed to overcome the current industry issu= e not having a secure multicast mechanism.

 

 

Kind Regards,
Wouter van der Beek

Technical Steering Committee Chair

Open connectivity foundation

https://op= enconnectivity.org/

 

--_000_c5b2f89748c64143889e47d869b7cad8XCHRTP005ciscocom_-- From nobody Tue Dec 11 04:11:42 2018 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 C65DB130DDB for ; Tue, 11 Dec 2018 04:11:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 ukZY1yr-aMQB for ; Tue, 11 Dec 2018 04:11:38 -0800 (PST) Received: from smtp.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEDB9130DD0 for ; Tue, 11 Dec 2018 04:11:38 -0800 (PST) Received: from [192.168.1.109] (p508A4EFC.dip0.t-ipconnect.de [80.138.78.252]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.uni-bremen.de (Postfix) with ESMTPSA id CCE8B20752; Tue, 11 Dec 2018 13:11:36 +0100 (CET) To: Ludwig Seitz , "ace@ietf.org" References: <154322421294.8323.8505315870685563404.idtracker@ietfa.amsl.com> From: Stefanie Gerdes Message-ID: Date: Tue, 11 Dec 2018 13:11:29 +0100 User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Ace] Fwd: New Version Notification for draft-ietf-ace-oauth-authz-17.txt and draft-ietf-ace-oauth-params-01.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2018 12:11:41 -0000 Hi, I looked through the document again. Many issues have been fixed, but I still have some comments: I still think that Section 5.8.1, in particular 5.8.1.1 should point out that RS must check the integrity of the token und validate that it stems from an authorized AS. Checking the iss field does not help in this case and I don't see much value in this check; cryptographic assurance such as AS' signature or MAC of the token is required to ascertain the authenticity, and in this case the issuer, of the token. 5.8.1. exiting -> existing Section 5.8.1. states that RS must check that the expiration time given in the exp field is in the future. This is difficult if the RS is not time synchronized. Option 3 in section 5.8.3 seems to suggest that this field is not always required. Instead of demanding that the exp field is checked the document should demand that the RS somehow validates that the token is not expired. Checking the exp field may be one example. C may receive keying material for the communication with RS from AS. Unfortunately, the AS does not inform C how long the keying material is valid. C therefore may use outdated keying material for the communication. C cannot rely on RS to reject messages that were sent with outdated keying material because 1. the information in the request sent by C may be confidential and is then compromised and 2. C cannot be sure that it is actually communicating with the intended RS if the keying material is no longer valid. I did not find any indication how the client knows how to choose the correct req_aud for RS. The document must point out that C may communicate with the wrong RS unless C and AS have a common understanding how RS is identified. Viele Grüße Steffi From nobody Tue Dec 11 08:29:40 2018 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 7A39C130E3C; Tue, 11 Dec 2018 08:29:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 Uo8Z0n6hyK8t; Tue, 11 Dec 2018 08:29:32 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5FC4130E44; Tue, 11 Dec 2018 08:29:25 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 27D0020089; Tue, 11 Dec 2018 11:29:18 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id EB30DE1B; Tue, 11 Dec 2018 11:29:23 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id E93A1E15; Tue, 11 Dec 2018 11:29:23 -0500 (EST) From: Michael Richardson To: ace@ietf.org, anima@ietf.org cc: "Panos Kampanakis \(pkampana\)" , Peter van der Stok , max pritikin In-Reply-To: References: X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: [Ace] est-coaps clarification on /att and /crts X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2018 16:29:34 -0000 --=-=-= Content-Type: text/plain A clarification question from an implementor (me) in the context of constrained BRSKI state machine. The /att and /crts requests do not do anything to change the state of client or server. It would seem that it might be safe to permit clients which have not yet authenticated to do this operation. (/att gets CSR attributes, and /crts gets the list of trust anchors) When EST-COAPS is used on its own, there usually needs to be a manufacturer trust anchor installed on the Registrar before any connection will be permitted. When EST-COAPS is used as step 2 of constrained-BRSKI, whether or not the Registrar will accept any (and all) connections depends upon configuration of the operator. Some devices might not be doing BRSKI (not need to, they already trust the operator, but they might still have IDevID only. This might happen during a transition) If the Registrar is "open" to new manufacturers, should the Registrar permit /att and /crts actions to be done by clients that it does not recognize? The /att call on an ANIMA ACP network would reveal to the client the ULA that would be used for that client (and perhaps other interesting things), and the /crts would show the name of the operator. Note that the later info probably is revealed just by doing the TLS handshake. I think that they should be restricted in general, but I'm concerned that there might be some situation I've missed. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlwP5eMACgkQgItw+93Q 3WUc+ggAj/7eT48Il7b89cAe71nakfMGu53IZoFoSmyIZ8dlRaxJch5rpaDei6QY L3ovnBYYCdNs1C92eXjciLcuQLq2prgDUqj36NoE1EywLVKyL3+mXkmTUpzjJVqY HOPrZZlEHNW35PbH0eua3HVPVku74WPL6M5VPjZdiq/QUXe0f+V8ZVFCn6j7E7ik p9ggESmc6vk9Sop5tfADhFtVA7diFXJ6xFoEElF6S/A0Kve+ijcW6m3OUwplqG82 C4uSVvALJNg1pSRwmYpMy6P1ru4+eoiusgNR+ORQiN0XLtOwv14hT6YJ3I5RpZUB QV3clD9Oq9EOXhOA+p6hAIPh4GgPtw== =XhQ8 -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Dec 11 09:50:11 2018 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 AD00A130ED8; Tue, 11 Dec 2018 09:50:10 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 e4VNpQPV75GW; Tue, 11 Dec 2018 09:50:09 -0800 (PST) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4BFC130EC7; Tue, 11 Dec 2018 09:50:08 -0800 (PST) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 11 Dec 2018 09:45:03 -0800 From: Jim Schaad To: 'Michael Richardson' , , CC: 'Peter van der Stok' , 'max pritikin' , "'Panos Kampanakis (pkampana)'" References: <3831.1544545763@localhost> In-Reply-To: <3831.1544545763@localhost> Date: Tue, 11 Dec 2018 09:50:00 -0800 Message-ID: <036301d49179$f2558bf0$d700a3d0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQGPjv7lcqlAiUUAise1VV4kpyPAbQIUVGQwpfMyi5A= Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Ace] est-coaps clarification on /att and /crts X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2018 17:50:11 -0000 Clarification requested - exactly what element is the Registrar? The one item that I can generally think of that might be a problem is that the answers to /att and /crts may differ based on the entity that is asking the question. In this case not having the entity being validated means that the "wrong" answer may be returned or different answers would be returned before and after validation. Jim > -----Original Message----- > From: Ace On Behalf Of Michael Richardson > Sent: Tuesday, December 11, 2018 8:29 AM > To: ace@ietf.org; anima@ietf.org > Cc: Peter van der Stok ; max pritikin > ; Panos Kampanakis (pkampana) > Subject: [Ace] est-coaps clarification on /att and /crts > > > A clarification question from an implementor (me) in the context of > constrained BRSKI state machine. > > The /att and /crts requests do not do anything to change the state of client or > server. It would seem that it might be safe to permit clients which have not yet > authenticated to do this operation. > (/att gets CSR attributes, and /crts gets the list of trust anchors) > > When EST-COAPS is used on its own, there usually needs to be a manufacturer > trust anchor installed on the Registrar before any connection will be permitted. > > When EST-COAPS is used as step 2 of constrained-BRSKI, whether or not the > Registrar will accept any (and all) connections depends upon configuration of > the operator. Some devices might not be doing BRSKI (not need to, they > already trust the operator, but they might still have IDevID only. This might > happen during a transition) > > If the Registrar is "open" to new manufacturers, should the Registrar permit > /att and /crts actions to be done by clients that it does not > recognize? The /att call on an ANIMA ACP network would reveal to the > client the ULA that would be used for that client (and perhaps other interesting > things), and the /crts would show the name of the operator. > Note that the later info probably is revealed just by doing the TLS handshake. > > I think that they should be restricted in general, but I'm concerned that there > might be some situation I've missed. > > -- > Michael Richardson , Sandelman Software Works - > = IPv6 IoT consulting =- > > From nobody Tue Dec 11 09:57:36 2018 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 913F2130ED6; Tue, 11 Dec 2018 09:57:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.961 X-Spam-Level: X-Spam-Status: No, score=-15.961 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.46, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 uVhrIw20vEV9; Tue, 11 Dec 2018 09:57:33 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19899130EC7; Tue, 11 Dec 2018 09:57:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3305; q=dns/txt; s=iport; t=1544551053; x=1545760653; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=SLDjphjuKfzoOT0xIfTPUYK0xiFyZzNKoLj7TFSd2C4=; b=TRSTR8Zq/sX2R4jieZGJz8QOqRsKjTCvr2a4zHPjdoQ+f7b+9fcUnRjJ bbu8mJ4qIE5STg+JoXcIt5/B14kEbaCWVWpU/ovx4Zwt6J1e8NdsyooAM U6K58KOlG/D2U/zTeYAsZ+HvPm7jHPQV1PsAppIWAEWQUS5VItWzoUFDX Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AFAADW+Q9c/4UNJK1kGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBUQUBAQEBCwGCA2aBAicKjAqMEYINl1KBegsBAYF3gnUCgmw?= =?us-ascii?q?iNAkNAQMBAQIBAQJtKIU8AQEBAQM6PwwEAgEIEQQBAR8QMh0IAgQBDQUIgxq?= =?us-ascii?q?CAacoii+Jc4JIF4FAP4ERgxKEa4VxAolRhW6QZ1UJApFHIJFAiSOPaQIRFIE?= =?us-ascii?q?nHziBVnAVO4JskFtBMYpLgR8BAQ?= X-IronPort-AV: E=Sophos;i="5.56,343,1539648000"; d="scan'208";a="497489908" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Dec 2018 17:57:31 +0000 Received: from XCH-ALN-012.cisco.com (xch-aln-012.cisco.com [173.36.7.22]) by alln-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id wBBHvVKO022224 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 11 Dec 2018 17:57:31 GMT Received: from xch-aln-010.cisco.com (173.36.7.20) by XCH-ALN-012.cisco.com (173.36.7.22) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 11 Dec 2018 11:57:31 -0600 Received: from xch-aln-010.cisco.com ([173.36.7.20]) by XCH-ALN-010.cisco.com ([173.36.7.20]) with mapi id 15.00.1395.000; Tue, 11 Dec 2018 11:57:31 -0600 From: "Panos Kampanakis (pkampana)" To: Michael Richardson , "ace@ietf.org" , "anima@ietf.org" CC: Peter van der Stok , "Max Pritikin (pritikin)" Thread-Topic: est-coaps clarification on /att and /crts Thread-Index: AQHUkW6xEQf9wDn5PkCg7PZRmoPArKV5u4Kg Date: Tue, 11 Dec 2018 17:57:30 +0000 Message-ID: <47b9e5cbf7e64fad91a9fc79e83e392c@XCH-ALN-010.cisco.com> References: <3831.1544545763@localhost> In-Reply-To: <3831.1544545763@localhost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.174.56] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.36.7.22, xch-aln-012.cisco.com X-Outbound-Node: alln-core-11.cisco.com Archived-At: Subject: Re: [Ace] est-coaps clarification on /att and /crts X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2018 17:57:36 -0000 Hi Michael, I thought about this for the EST-coaps draft. EST allowed for unauthenticat= ed /cacerts and /csrattrs (/crt and /att in EST-coaps) as you are suggestin= g. It is not as simple in EST-coaps. Two reasons:=20 1) There are constrained networks where an easy amplification attack could = take place. For example the /crt request is very small and the response can= be big (a few KBs in the context of a constrained network is big). If unau= thenticated, then /crts could be an easy amplification attack to saturate a= constrained network. We don't want that to happen. We want all our clients= to be authenticated by DTLS before they start loading up our RF network. 2) Additionally, there is a practical challenge of COAPS. When the DTLS han= dshake is taking place the server does not know what the request will be. I= n EST the server would send an HTTP WWW-Authenticate header to ask the clie= nt to authenticate. Such a mechanism does not exist in COAP, so it would no= t be straightforward unless we introduced a bunch of new things into COAP. I think it is still right to authenticate clients even for /crt and /att in= the EST-coaps context. Maybe that is something to be revisited in Constrai= ned-BRSKI/voucher, but not taken lightly.=20 Rgs, Panos -----Original Message----- From: Michael Richardson =20 Sent: Tuesday, December 11, 2018 11:29 AM To: ace@ietf.org; anima@ietf.org Cc: Panos Kampanakis (pkampana) ; Peter van der Stok ; Max Pritikin (pritikin) Subject: est-coaps clarification on /att and /crts * PGP Signed by an unknown key A clarification question from an implementor (me) in the context of constra= ined BRSKI state machine. The /att and /crts requests do not do anything to change the state of clien= t or server. It would seem that it might be safe to permit clients which h= ave not yet authenticated to do this operation. (/att gets CSR attributes, and /crts gets the list of trust anchors) When EST-COAPS is used on its own, there usually needs to be a manufacturer= trust anchor installed on the Registrar before any connection will be perm= itted. When EST-COAPS is used as step 2 of constrained-BRSKI, whether or not the R= egistrar will accept any (and all) connections depends upon configuration o= f the operator. Some devices might not be doing BRSKI (not need to, they a= lready trust the operator, but they might still have IDevID only. This mig= ht happen during a transition) If the Registrar is "open" to new manufacturers, should the Registrar permi= t /att and /crts actions to be done by clients that it does not recognize? The /att call on an ANIMA ACP network would reveal to the client the ULA that would be used for that client (and perhaps other intere= sting things), and the /crts would show the name of the operator. Note that the later info probably is revealed just by doing the TLS handsha= ke. I think that they should be restricted in general, but I'm concerned that t= here might be some situation I've missed. -- Michael Richardson , Sandelman Software Works -=3D = IPv6 IoT consulting =3D- * Unknown Key * 0xDDD0DD65 From nobody Tue Dec 11 12:38:54 2018 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 7A2E2130F99 for ; Tue, 11 Dec 2018 12:38:44 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 do1eTgeXYGjQ for ; Tue, 11 Dec 2018 12:38:42 -0800 (PST) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9466C130F81 for ; Tue, 11 Dec 2018 12:38:41 -0800 (PST) Received: from Jude (192.168.1.160) by mail2.augustcellars.com (192.168.1.201) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 11 Dec 2018 12:33:35 -0800 From: Jim Schaad To: 'Stefanie Gerdes' , 'Ludwig Seitz' , References: <154322421294.8323.8505315870685563404.idtracker@ietfa.amsl.com> In-Reply-To: Date: Tue, 11 Dec 2018 12:38:32 -0800 Message-ID: <03b601d49191$7d1bb400$77531c00$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQK3+H3pFttPP+s38ebErlDfr5TlzwGwIdvjAojcdAajkWggkA== Content-Language: en-us X-Originating-IP: [192.168.1.160] Archived-At: Subject: Re: [Ace] Fwd: New Version Notification for draft-ietf-ace-oauth-authz-17.txt and draft-ietf-ace-oauth-params-01.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2018 20:38:50 -0000 > -----Original Message----- > From: Ace On Behalf Of Stefanie Gerdes > Sent: Tuesday, December 11, 2018 4:11 AM > To: Ludwig Seitz ; ace@ietf.org > Subject: Re: [Ace] Fwd: New Version Notification for draft-ietf-ace-oauth-authz- > 17.txt and draft-ietf-ace-oauth-params-01.txt >=20 > Hi, >=20 > I looked through the document again. Many issues have been fixed, but = I still > have some comments: >=20 > I still think that Section 5.8.1, in particular 5.8.1.1 should point = out that RS must > check the integrity of the token und validate that it stems from an authorized > AS. Checking the iss field does not help in this case and I don't see = much value > in this check; cryptographic assurance such as AS' signature or MAC of = the > token is required to ascertain the authenticity, and in this case the issuer, of the > token. I would agree with this. I have never been sure why the 'iss' field is going to be useful. The only place that I can see this would be an AS = which is using one key but two identities. I would argue that this is a = situation that is prone to configuration errors and incorrect security. >=20 > 5.8.1. exiting -> existing >=20 > Section 5.8.1. states that RS must check that the expiration time = given in the > exp field is in the future. This is difficult if the RS is not time synchronized. > Option 3 in section 5.8.3 seems to suggest that this field is not = always required. > Instead of demanding that the exp field is checked the document should > demand that the RS somehow validates that the token is not expired. Checking > the exp field may be one example. >=20 > C may receive keying material for the communication with RS from AS. > Unfortunately, the AS does not inform C how long the keying material = is valid. C > therefore may use outdated keying material for the communication. C = cannot > rely on RS to reject messages that were sent with outdated keying = material > because 1. the information in the request sent by C may be = confidential and is > then compromised and 2. C cannot be sure that it is actually = communicating > with the intended RS if the keying material is no longer valid. Would you feel that this would be eased by requiring the expires_in = field to be required as part of the response? It is the expiration of the token, = but I have never understood the difference between the expiration of the = token and the expiration of keying material myself. Keying material never expires, you just cannot use it without a valid token. >=20 > I did not find any indication how the client knows how to choose the correct > req_aud for RS. The document must point out that C may communicate = with > the wrong RS unless C and AS have a common understanding how RS is > identified. Scope is also something that the client does not know how to build. =20 Jim >=20 > Viele Gr=FC=DFe > Steffi >=20 > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace From nobody Tue Dec 11 14:16:57 2018 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 60766130F29; Tue, 11 Dec 2018 14:16:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 NNFHUNgA2osZ; Tue, 11 Dec 2018 14:16:53 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19ADA12E036; Tue, 11 Dec 2018 14:16:53 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id D8DB520089; Tue, 11 Dec 2018 17:16:44 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id ADFAAE1B; Tue, 11 Dec 2018 17:16:50 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id AB8D0E15; Tue, 11 Dec 2018 17:16:50 -0500 (EST) From: Michael Richardson To: Jim Schaad cc: ace@ietf.org, anima@ietf.org, "'Peter van der Stok'" , "'max pritikin'" , "'Panos Kampanakis \(pkampana\)'" In-Reply-To: <036301d49179$f2558bf0$d700a3d0$@augustcellars.com> References: <3831.1544545763@localhost> <036301d49179$f2558bf0$d700a3d0$@augustcellars.com> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Ace] est-coaps clarification on /att and /crts X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2018 22:16:56 -0000 --=-=-= Content-Type: text/plain Jim Schaad wrote: > Clarification requested - exactly what element is the Registrar? It's an EST RFC7030 term, but essentially it's the server that connects to (or is) the CA. > The one item that I can generally think of that might be a problem is that > the answers to /att and /crts may differ based on the entity that is asking > the question. In this case not having the entity being validated means that > the "wrong" answer may be returned or different answers would be returned > before and after validation. Yes, I agree: it should be restricted. I think that it should be restricted. Partly, I'm just not sure where the text should go, or if it needs to be said at all. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlwQN1IACgkQgItw+93Q 3WWqxQf+NFoMxAB/+Uya2GyIlaSiCdVgucwBC0HyhOqtNYpD/I62GNB75pdBAy+X sxloBYNm0xujOH8JneNIecMAYGQpEFugIsF2DlJSZXM6/OkDyksCqwe9qfD0bUF5 eqPQn+CtjpKirEYf6yIPJaoN2QxALhMd2PTv4ijvtsQGjL1iP39xjWRv2X1cOfWy zGwzwhlv8kLerUPYwxP/f0sW3uiTco73ZDPfZmuVTEWcF4fi27BLl8hY3npXXQo4 1PX4GpWWjsso1T1/3EdLXD7yvlo+/OZmOO/DB1CfjM/72ryiqPUUFQhsUxT5+YpO TlVHJ5nClXwMzl0aSZ9jn1oWxoi5Hg== =Zog5 -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Dec 11 14:21:52 2018 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 17E5212E036; Tue, 11 Dec 2018 14:21:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 GAXmGf4HNrLC; Tue, 11 Dec 2018 14:21:48 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 743B91286E7; Tue, 11 Dec 2018 14:21:48 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id B01A720089; Tue, 11 Dec 2018 17:21:41 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 85E69E1B; Tue, 11 Dec 2018 17:21:47 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 83DCCE15; Tue, 11 Dec 2018 17:21:47 -0500 (EST) From: Michael Richardson To: "Panos Kampanakis \(pkampana\)" , "ace\@ietf.org" , "anima\@ietf.org" CC: Peter van der Stok , "Max Pritikin \(pritikin\)" In-Reply-To: <47b9e5cbf7e64fad91a9fc79e83e392c@XCH-ALN-010.cisco.com> References: <3831.1544545763@localhost> <47b9e5cbf7e64fad91a9fc79e83e392c@XCH-ALN-010.cisco.com> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Ace] est-coaps clarification on /att and /crts X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2018 22:21:51 -0000 --=-=-= Content-Type: text/plain Panos Kampanakis (pkampana) wrote: > I thought about this for the EST-coaps draft. EST allowed for > unauthenticated /cacerts and /csrattrs (/crt and /att in EST-coaps) as you > are suggesting. Exactly. > It is not as simple in EST-coaps. Two reasons: > 1) There are constrained networks where an easy amplification attack could > take place. For example the /crt request is very small and the response can > be big (a few KBs in the context of a constrained network is big). If > unauthenticated, then /crts could be an easy amplification attack to > saturate a constrained network. We don't want that to happen. We want all > our clients to be authenticated by DTLS before they start loading up our RF > network. I'm not suggesting that the DTLS be skipped, I'm suggesting that the client certificate presented might be meaningless to the EST server. As for amplication attacks, they usually depend upon forged source addresses, and in that case the DTLS wouldn't have completed. > 2) Additionally, there is a practical challenge of COAPS. When the DTLS > handshake is taking place the server does not know what the request will > be. In EST the server would send an HTTP WWW-Authenticate header to ask the > client to authenticate. Such a mechanism does not exist in COAP, so it > would not be straightforward unless we introduced a bunch of new things > into COAP. AFAIK, we don't support HTTP-level authentication in COAPS, only DTLS level authentication is specified in EST-COAPS. > I think it is still right to authenticate clients even for /crt and /att in > the EST-coaps context. Maybe that is something to be revisited in > Constrained-BRSKI/voucher, but not taken lightly. So I think that we need to say something in EST-COAPS to explain that we do not see a use case for replying to /crts and /att for clients which are not recognized. Is 401 (4.01) or 403 (4.03) more appropriate do you think? -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | IoT architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlwQOHsACgkQgItw+93Q 3WUPkQf/T66QDd+QWBpsJsKMBHcvrMeZkH5FzhwNc7qNaHlvpEm3kp7nUThZFcg3 BqR9T/dP1iue/I8fdbOT28b1OEDNRgBild8ntf4eCPoS3lqy5dBo/GnCOL0ycnoS swDOQrIVnEF3vPWZMW3+uxEpsuZrI3JAS0vWa79qI+s5wpCvu0Gv1mh5b8Srnyk6 pbcxfHyj7kQl1f4cz+cxYcT2xBpccGN1Dqa2xqbnuPogocWFX3+LilnrLNm1DaQC xRPvxket4rhBH2PPsjmnj+YHtvOsICWdnqMNavKgARpyRKqv2S+LKlccrRf+fspX e97AbcZoLH+suJBq4ztaYftHSat8Ug== =jcX7 -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Dec 11 16:52:07 2018 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 67233129C6A; Tue, 11 Dec 2018 16:52:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.959 X-Spam-Level: X-Spam-Status: No, score=-15.959 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.46, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 ih50og4ZTzbg; Tue, 11 Dec 2018 16:52:03 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 381D5127598; Tue, 11 Dec 2018 16:52:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9850; q=dns/txt; s=iport; t=1544575923; x=1545785523; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=TNb0supGxN3wSnMe2Rn4hSzkyIAh+6di0SdaU8MfIFE=; b=QPAn+1NvpZRZl3o76eiNQSlJuZABeYlm2YU3NHqduI6ec2FjviwDJijz Rvqy7wFFcytnAGCOwq1TqDpu+Ji2+XVpnfFyeRzeH7KhFfbBQl2qfkFl8 2WfC+kf1TKFAr82atfjnJKUUC43K1L8MlXrILUNhese0Uw8/sV4Cz7v1c I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAAAlWxBc/5RdJa1lGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUQQBAQEBAQsBgQ12ZoECJwqDcYgZjBKUBoVZgXoLAQE?= =?us-ascii?q?ngVCCdQIXglUiNAkNAQMBAQIBAQJtHAyFPQYjVhACAQg/AwICAjAUEQIEDgW?= =?us-ascii?q?DIQGBHWQPpgSBL4oqBYw7F4F/gTgfgkyDHgEBAgGBSIMaMYImAolRgVqDfJF?= =?us-ascii?q?UCQKHB4pIGJFAjhaKdgIRFIEnHziBVnAVZQGCQYIiBReIXoU/QTEBiR8rgQG?= =?us-ascii?q?BHwEB?= X-IronPort-AV: E=Sophos;i="5.56,343,1539648000"; d="scan'208,217";a="211767364" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Dec 2018 00:52:02 +0000 Received: from XCH-ALN-006.cisco.com (xch-aln-006.cisco.com [173.36.7.16]) by rcdn-core-12.cisco.com (8.15.2/8.15.2) with ESMTPS id wBC0q2nA011229 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 12 Dec 2018 00:52:02 GMT Received: from xch-aln-013.cisco.com (173.36.7.23) by XCH-ALN-006.cisco.com (173.36.7.16) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 11 Dec 2018 18:52:01 -0600 Received: from xch-aln-013.cisco.com ([173.36.7.23]) by XCH-ALN-013.cisco.com ([173.36.7.23]) with mapi id 15.00.1395.000; Tue, 11 Dec 2018 18:52:01 -0600 From: "Max Pritikin (pritikin)" To: Michael Richardson CC: Jim Schaad , "ace@ietf.org" , "anima@ietf.org" , Peter van der Stok , "Panos Kampanakis (pkampana)" Thread-Topic: [Ace] est-coaps clarification on /att and /crts Thread-Index: AQHUkW6wpKPGP7xkTEa+IFO1X4G7f6V6NZcAgABKjQCAACtXgA== Date: Wed, 12 Dec 2018 00:52:01 +0000 Message-ID: References: <3831.1544545763@localhost> <036301d49179$f2558bf0$d700a3d0$@augustcellars.com> <26234.1544566610@localhost> In-Reply-To: <26234.1544566610@localhost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.99.106.3] Content-Type: multipart/alternative; boundary="_000_B4901FFA18C14B858B7A60DD98A8D521ciscocom_" MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.36.7.16, xch-aln-006.cisco.com X-Outbound-Node: rcdn-core-12.cisco.com Archived-At: Subject: Re: [Ace] est-coaps clarification on /att and /crts X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2018 00:52:06 -0000 --_000_B4901FFA18C14B858B7A60DD98A8D521ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQoNCk9uIERlYyAxMSwgMjAxOCwgYXQgMzoxNiBQTSwgTWljaGFlbCBSaWNoYXJkc29uIDxtY3Ir aWV0ZkBzYW5kZWxtYW4uY2E8bWFpbHRvOm1jcitpZXRmQHNhbmRlbG1hbi5jYT4+IHdyb3RlOg0K DQoNCkppbSBTY2hhYWQgPGlldGZAYXVndXN0Y2VsbGFycy5jb208bWFpbHRvOmlldGZAYXVndXN0 Y2VsbGFycy5jb20+PiB3cm90ZToNCkNsYXJpZmljYXRpb24gcmVxdWVzdGVkIC0gZXhhY3RseSB3 aGF0IGVsZW1lbnQgaXMgdGhlIFJlZ2lzdHJhcj8NCg0KSXQncyBhbiBFU1QgUkZDNzAzMCB0ZXJt LCBidXQgZXNzZW50aWFsbHkgaXQncyB0aGUgc2VydmVyIHRoYXQgY29ubmVjdHMgdG8NCihvciBp cykgdGhlIENBLg0KDQpUaGUgUmVnaXN0cmFyIHRlcm1pbm9sb2d5IGlzIGZyb20gdGhlIEFuaW1h IHdvcmtpbmcgZ3JvdXAgYW5kIGlzIGNsb3NlbHkgYW5hbG9nb3VzIHRvIHRoZSDigJxSZWdpc3Ry YXRpb24gQXV0aG9yaXR54oCdIHdlIGtub3cgYW5kIGxvdmUgZnJvbSB0aGUgUEtJIHNwYWNlLg0K DQoNCiAgIEpvaW4gUmVnaXN0cmFyIChhbmQgQ29vcmRpbmF0b3IpOiAgQSByZXByZXNlbnRhdGl2 ZSBvZiB0aGUgZG9tYWluDQogICAgICB0aGF0IGlzIGNvbmZpZ3VyZWQsIHBlcmhhcHMgYXV0b25v bWljYWxseSwgdG8gZGVjaWRlIHdoZXRoZXIgYSBuZXcNCg0KICAgICAgZGV2aWNlIGlzIGFsbG93 ZWQgdG8gam9pbiB0aGUgZG9tYWluLiAgVGhlIGFkbWluaXN0cmF0b3Igb2YgdGhlDQoNCg0KICAg ICAgZG9tYWluIGludGVyZmFjZXMgd2l0aCBhICJqb2luIHJlZ2lzdHJhciAoYW5kIGNvb3JkaW5h dG9yKSIgdG8NCiAgICAgIGNvbnRyb2wgdGhpcyBwcm9jZXNzLiAgVHlwaWNhbGx5IGEgam9pbiBy ZWdpc3RyYXIgaXMgImluc2lkZSIgaXRzDQogICAgICBkb21haW4uICBGb3Igc2ltcGxpY2l0eSB0 aGlzIGRvY3VtZW50IG9mdGVuIHJlZmVycyB0byB0aGlzIGFzIGp1c3QNCiAgICAgICJyZWdpc3Ry YXIiLiAgV2l0aGluIFtJLUQuaWV0Zi1hbmltYS1yZWZlcmVuY2UtbW9kZWw8aHR0cHM6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtYW5pbWEtYm9vdHN0cmFwcGluZy1rZXlpbmZyYS0x NyNyZWYtSS1ELmlldGYtYW5pbWEtcmVmZXJlbmNlLW1vZGVsPl0gdGhpcyBpcw0KICAgICAgcmVm ZXJlZCB0byBhcyB0aGUgImpvaW4gcmVnaXN0cmFyIGF1dG9ub21pYyBzZXJ2aWNlIGFnZW50Ii4N Cg0KSXQgdGVybWluYXRlcyB0aGUgQlJTS0kgcHJvdG9jb2wgZnJvbSB0aGUgbmV3IGRldmljZSBh bmQsIGFmdGVyIHByb2Nlc3NpbmcgYW5kIGRlY2lzaW9ucywgZm9yd2FyZHMgbWVzc2FnZXMgdG8g YSBtYW51ZmFjdHVyZXIgYXV0aG9yaXplZCBzaWduaW5nIGF1dGhvcml0eSB0byBvYnRhaW4gdm91 Y2hlcnMgYW5kIGVuc3VyZSByZWNvcmRzL2F1ZGl0LWxvZ3MgYXJlIGtlcHQuIEl0IGFsc28gcHVs bHMgdGhvc2UgYXVkaXQgbG9ncyB0byBtYWtlIGFkZGl0aW9uYWwgZGVjaXNpb25zLiBJdCBpcyBy ZXNwb25zaWJsZSBmb3IgbWFraW5nIHRoZSBhdXRob3JpemF0aW9uIGRlY2lzaW9uIGNvbmNlcm5p bmcgaWYgdGhlIG5ldyBkZXZpY2Ugc2hvdWxkIGJlIGFsbG93ZWQgdG8gam9pbiB0aGUgbmV0d29y ay4NCg0KSXQgYWxzbyBvcHRpb25hbGx5IGRvdWJsZXMgYXMgYSBlbnJvbGxtZW50IG92ZXIgc2Vj dXJlIHRyYW5zcG9ydCAoUkZDNzAzMCkgcmVnaXN0cmF0aW9uIGF1dGhvcml0eSBpbiB0aGUgbm9y bWFsIFBLSSBzZW5zZS4gVGhpcyBpcyByZWNvbW1lbmRlZCBpbiB0aGF0IEJSU0tJIHJlY29tbWVu ZHMgdGhhdCBkZXZpY2VzIGdvIG9uIHRvIGVucm9sbCBhbmQgb2J0YWluIGEgY2VydGlmaWNhdGUu DQoNCi0gbWF4DQoNCg0KVGhlIG9uZSBpdGVtIHRoYXQgSSBjYW4gZ2VuZXJhbGx5IHRoaW5rIG9m IHRoYXQgbWlnaHQgYmUgYSBwcm9ibGVtIGlzIHRoYXQNCnRoZSBhbnN3ZXJzIHRvIC9hdHQgYW5k IC9jcnRzIG1heSBkaWZmZXIgYmFzZWQgb24gdGhlIGVudGl0eSB0aGF0IGlzIGFza2luZw0KdGhl IHF1ZXN0aW9uLiAgSW4gdGhpcyBjYXNlIG5vdCBoYXZpbmcgdGhlIGVudGl0eSBiZWluZyB2YWxp ZGF0ZWQgbWVhbnMgdGhhdA0KdGhlICJ3cm9uZyIgYW5zd2VyIG1heSBiZSByZXR1cm5lZCBvciBk aWZmZXJlbnQgYW5zd2VycyB3b3VsZCBiZSByZXR1cm5lZA0KYmVmb3JlIGFuZCBhZnRlciB2YWxp ZGF0aW9uLg0KDQpZZXMsIEkgYWdyZWU6IGl0IHNob3VsZCBiZSByZXN0cmljdGVkLg0KDQpJIHRo aW5rIHRoYXQgaXQgc2hvdWxkIGJlIHJlc3RyaWN0ZWQuIFBhcnRseSwgSSdtIGp1c3Qgbm90IHN1 cmUgd2hlcmUgdGhlDQp0ZXh0IHNob3VsZCBnbywgb3IgaWYgaXQgbmVlZHMgdG8gYmUgc2FpZCBh dCBhbGwuDQoNCi0tDQpNaWNoYWVsIFJpY2hhcmRzb24gPG1jcitJRVRGQHNhbmRlbG1hbi5jYTxt YWlsdG86bWNyK0lFVEZAc2FuZGVsbWFuLmNhPj4sIFNhbmRlbG1hbiBTb2Z0d2FyZSBXb3Jrcw0K LT0gSVB2NiBJb1QgY29uc3VsdGluZyA9LQ0KDQo= --_000_B4901FFA18C14B858B7A60DD98A8D521ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxkaXY+PGJyIGNsYXNz PSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPk9u IERlYyAxMSwgMjAxOCwgYXQgMzoxNiBQTSwgTWljaGFlbCBSaWNoYXJkc29uICZsdDs8YSBocmVm PSJtYWlsdG86bWNyJiM0MztpZXRmQHNhbmRlbG1hbi5jYSIgY2xhc3M9IiI+bWNyJiM0MztpZXRm QHNhbmRlbG1hbi5jYTwvYT4mZ3Q7IHdyb3RlOjwvZGl2Pg0KPGJyIGNsYXNzPSJBcHBsZS1pbnRl cmNoYW5nZS1uZXdsaW5lIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFz cz0iIj4NCkppbSBTY2hhYWQgJmx0OzxhIGhyZWY9Im1haWx0bzppZXRmQGF1Z3VzdGNlbGxhcnMu Y29tIiBjbGFzcz0iIj5pZXRmQGF1Z3VzdGNlbGxhcnMuY29tPC9hPiZndDsgd3JvdGU6PGJyIGNs YXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+Q2xhcmlmaWNhdGlvbiBy ZXF1ZXN0ZWQgLSBleGFjdGx5IHdoYXQgZWxlbWVudCBpcyB0aGUgUmVnaXN0cmFyPzxiciBjbGFz cz0iIj4NCjwvYmxvY2txdW90ZT4NCjxiciBjbGFzcz0iIj4NCkl0J3MgYW4gRVNUIFJGQzcwMzAg dGVybSwgYnV0IGVzc2VudGlhbGx5IGl0J3MgdGhlIHNlcnZlciB0aGF0IGNvbm5lY3RzIHRvPGJy IGNsYXNzPSIiPg0KKG9yIGlzKSB0aGUgQ0EuPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2PlRoZSBSZWdp c3RyYXIgdGVybWlub2xvZ3kgaXMgZnJvbSB0aGUgQW5pbWEgd29ya2luZyBncm91cCBhbmQgaXMg Y2xvc2VseSBhbmFsb2dvdXMgdG8gdGhlIOKAnFJlZ2lzdHJhdGlvbiBBdXRob3JpdHnigJ0gd2Ug a25vdyBhbmQgbG92ZSBmcm9tIHRoZSBQS0kgc3BhY2UuJm5ic3A7PC9kaXY+DQo8ZGl2PjxiciBj bGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj4NCjxwcmUgY2xhc3M9Im5ld3BhZ2UiIHN0eWxlPSJmb250 LXNpemU6IDEzLjMzMzNweDsgbWFyZ2luLXRvcDogMHB4OyBtYXJnaW4tYm90dG9tOiAwcHg7IGJy ZWFrLWJlZm9yZTogcGFnZTsgZm9udC12YXJpYW50LWxpZ2F0dXJlczogbm9ybWFsOyBvcnBoYW5z OiAyOyB3aWRvd3M6IDI7Ij4gICBKb2luIFJlZ2lzdHJhciAoYW5kIENvb3JkaW5hdG9yKTogIEEg cmVwcmVzZW50YXRpdmUgb2YgdGhlIGRvbWFpbg0KICAgICAgdGhhdCBpcyBjb25maWd1cmVkLCBw ZXJoYXBzIGF1dG9ub21pY2FsbHksIHRvIGRlY2lkZSB3aGV0aGVyIGEgbmV3PC9wcmU+DQo8cHJl IGNsYXNzPSJuZXdwYWdlIiBzdHlsZT0iZm9udC1zaXplOiAxMy4zMzMzcHg7IG1hcmdpbi10b3A6 IDBweDsgbWFyZ2luLWJvdHRvbTogMHB4OyBicmVhay1iZWZvcmU6IHBhZ2U7IGZvbnQtdmFyaWFu dC1saWdhdHVyZXM6IG5vcm1hbDsgb3JwaGFuczogMjsgd2lkb3dzOiAyOyI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTogMTMuMzMzM3B4OyIgY2xhc3M9IiI+ICAgICAgZGV2aWNlIGlzIGFsbG93ZWQg dG8gam9pbiB0aGUgZG9tYWluLiAgVGhlIGFkbWluaXN0cmF0b3Igb2YgdGhlPC9zcGFuPg0KPC9w cmU+DQo8cHJlIGNsYXNzPSJuZXdwYWdlIiBzdHlsZT0iZm9udC1zaXplOiAxMy4zMzMzcHg7IG1h cmdpbi10b3A6IDBweDsgbWFyZ2luLWJvdHRvbTogMHB4OyBicmVhay1iZWZvcmU6IHBhZ2U7IGZv bnQtdmFyaWFudC1saWdhdHVyZXM6IG5vcm1hbDsgb3JwaGFuczogMjsgd2lkb3dzOiAyOyI+ICAg ICAgZG9tYWluIGludGVyZmFjZXMgd2l0aCBhICZxdW90O2pvaW4gcmVnaXN0cmFyIChhbmQgY29v cmRpbmF0b3IpJnF1b3Q7IHRvDQogICAgICBjb250cm9sIHRoaXMgcHJvY2Vzcy4gIFR5cGljYWxs eSBhIGpvaW4gcmVnaXN0cmFyIGlzICZxdW90O2luc2lkZSZxdW90OyBpdHMNCiAgICAgIGRvbWFp bi4gIEZvciBzaW1wbGljaXR5IHRoaXMgZG9jdW1lbnQgb2Z0ZW4gcmVmZXJzIHRvIHRoaXMgYXMg anVzdA0KICAgICAgJnF1b3Q7cmVnaXN0cmFyJnF1b3Q7LiAgV2l0aGluIFs8YSBocmVmPSJodHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1hbmltYS1ib290c3RyYXBwaW5nLWtl eWluZnJhLTE3I3JlZi1JLUQuaWV0Zi1hbmltYS1yZWZlcmVuY2UtbW9kZWwiIHRpdGxlPSImcXVv dDtBIFJlZmVyZW5jZSBNb2RlbCBmb3IgQXV0b25vbWljIE5ldHdvcmtpbmcmcXVvdDsiIGNsYXNz PSIiPkktRC5pZXRmLWFuaW1hLXJlZmVyZW5jZS1tb2RlbDwvYT5dIHRoaXMgaXMNCiAgICAgIHJl ZmVyZWQgdG8gYXMgdGhlICZxdW90O2pvaW4gcmVnaXN0cmFyIGF1dG9ub21pYyBzZXJ2aWNlIGFn ZW50JnF1b3Q7LiA8L3ByZT4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPkl0IHRlcm1pbmF0ZXMgdGhlIEJSU0tJIHByb3RvY29sIGZyb20gdGhlIG5l dyBkZXZpY2UgYW5kLCBhZnRlciBwcm9jZXNzaW5nIGFuZCBkZWNpc2lvbnMsIGZvcndhcmRzIG1l c3NhZ2VzIHRvIGEgbWFudWZhY3R1cmVyIGF1dGhvcml6ZWQgc2lnbmluZyBhdXRob3JpdHkgdG8g b2J0YWluIHZvdWNoZXJzIGFuZCBlbnN1cmUgcmVjb3Jkcy9hdWRpdC1sb2dzIGFyZSBrZXB0LiBJ dCBhbHNvIHB1bGxzIHRob3NlIGF1ZGl0IGxvZ3MNCiB0byBtYWtlIGFkZGl0aW9uYWwgZGVjaXNp b25zLiBJdCBpcyByZXNwb25zaWJsZSBmb3IgbWFraW5nIHRoZSBhdXRob3JpemF0aW9uIGRlY2lz aW9uIGNvbmNlcm5pbmcgaWYgdGhlIG5ldyBkZXZpY2Ugc2hvdWxkIGJlIGFsbG93ZWQgdG8gam9p biB0aGUgbmV0d29yay4mbmJzcDs8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0K PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkl0IGFsc28gb3B0aW9uYWxseSBkb3VibGVzIGFzIGEgZW5y b2xsbWVudCBvdmVyIHNlY3VyZSB0cmFuc3BvcnQgKFJGQzcwMzApIHJlZ2lzdHJhdGlvbiBhdXRo b3JpdHkgaW4gdGhlIG5vcm1hbCBQS0kgc2Vuc2UuIFRoaXMgaXMgcmVjb21tZW5kZWQgaW4gdGhh dCBCUlNLSSByZWNvbW1lbmRzIHRoYXQgZGV2aWNlcyBnbyBvbiB0byBlbnJvbGwgYW5kIG9idGFp biBhIGNlcnRpZmljYXRlLiZuYnNwOzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+ DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+LSBtYXg8L2Rpdj4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIi Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRp diBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0i Ij5UaGUgb25lIGl0ZW0gdGhhdCBJIGNhbiBnZW5lcmFsbHkgdGhpbmsgb2YgdGhhdCBtaWdodCBi ZSBhIHByb2JsZW0gaXMgdGhhdDxiciBjbGFzcz0iIj4NCnRoZSBhbnN3ZXJzIHRvIC9hdHQgYW5k IC9jcnRzIG1heSBkaWZmZXIgYmFzZWQgb24gdGhlIGVudGl0eSB0aGF0IGlzIGFza2luZzxiciBj bGFzcz0iIj4NCnRoZSBxdWVzdGlvbi4gJm5ic3A7SW4gdGhpcyBjYXNlIG5vdCBoYXZpbmcgdGhl IGVudGl0eSBiZWluZyB2YWxpZGF0ZWQgbWVhbnMgdGhhdDxiciBjbGFzcz0iIj4NCnRoZSAmcXVv dDt3cm9uZyZxdW90OyBhbnN3ZXIgbWF5IGJlIHJldHVybmVkIG9yIGRpZmZlcmVudCBhbnN3ZXJz IHdvdWxkIGJlIHJldHVybmVkPGJyIGNsYXNzPSIiPg0KYmVmb3JlIGFuZCBhZnRlciB2YWxpZGF0 aW9uLjxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCjxiciBjbGFzcz0iIj4NClllcywgSSBh Z3JlZTogaXQgc2hvdWxkIGJlIHJlc3RyaWN0ZWQuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIi Pg0KSSB0aGluayB0aGF0IGl0IHNob3VsZCBiZSByZXN0cmljdGVkLiBQYXJ0bHksIEknbSBqdXN0 IG5vdCBzdXJlIHdoZXJlIHRoZTxiciBjbGFzcz0iIj4NCnRleHQgc2hvdWxkIGdvLCBvciBpZiBp dCBuZWVkcyB0byBiZSBzYWlkIGF0IGFsbC48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQot LTxiciBjbGFzcz0iIj4NCk1pY2hhZWwgUmljaGFyZHNvbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1j ciYjNDM7SUVURkBzYW5kZWxtYW4uY2EiIGNsYXNzPSIiPm1jciYjNDM7SUVURkBzYW5kZWxtYW4u Y2E8L2E+Jmd0OywgU2FuZGVsbWFuIFNvZnR3YXJlIFdvcmtzPGJyIGNsYXNzPSIiPg0KLT0gSVB2 NiBJb1QgY29uc3VsdGluZyA9LTxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2Nr cXVvdGU+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_B4901FFA18C14B858B7A60DD98A8D521ciscocom_-- From nobody Tue Dec 11 18:59:25 2018 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 B07B4131007; Tue, 11 Dec 2018 18:59:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.96 X-Spam-Level: X-Spam-Status: No, score=-15.96 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.46, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 StiwEyB2_lz0; Tue, 11 Dec 2018 18:59:14 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8741C1277D2; Tue, 11 Dec 2018 18:59:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4599; q=dns/txt; s=iport; t=1544583554; x=1545793154; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=LFwOWljz6mrzN4BjrEIickIClcAr5V5xVKDbPkK7o8U=; b=MolTP/HYlUqhAaJ7f+GIYgUYqWArU4LLPbHLByEkt+ybbQzuTn834Eq3 rq0lfH59azmB6xrNxuQwzo46vABI6oEXe6EaJiotdN6oq/DpJLLTl1TdS +cCA2QReLdkZNJub+VpBGYztgisU9bgNwhQWwWyfhtec7H7IjX7RD3I14 k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAACkeBBc/5JdJa1lGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUQQBAQEBAQsBggNmgQInCowKjh+XUoF6CwEBH4FYgnU?= =?us-ascii?q?CgmwiNAkNAQMBAQIBAQJtHAyFPAEBAQECATo/BQcEAgEIEQQBAQEeEDIdCAI?= =?us-ascii?q?EAQ0FCIMagXkIpx+KMIlzgkgXgUA/gRGDEoRrhXEClXaKMFUJApFJIJFCiSO?= =?us-ascii?q?PagIRFIEnHziBVnAVgycJhSuLJ0ExiziBHwEB?= X-IronPort-AV: E=Sophos;i="5.56,343,1539648000"; d="scan'208";a="211803218" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Dec 2018 02:59:13 +0000 Received: from XCH-RCD-014.cisco.com (xch-rcd-014.cisco.com [173.37.102.24]) by rcdn-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id wBC2xDov001154 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 12 Dec 2018 02:59:13 GMT Received: from xch-aln-010.cisco.com (173.36.7.20) by XCH-RCD-014.cisco.com (173.37.102.24) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 11 Dec 2018 20:59:12 -0600 Received: from xch-aln-010.cisco.com ([173.36.7.20]) by XCH-ALN-010.cisco.com ([173.36.7.20]) with mapi id 15.00.1395.000; Tue, 11 Dec 2018 20:59:12 -0600 From: "Panos Kampanakis (pkampana)" To: Michael Richardson , "ace@ietf.org" , "anima@ietf.org" CC: Peter van der Stok , "Max Pritikin (pritikin)" Thread-Topic: est-coaps clarification on /att and /crts Thread-Index: AQHUkW6xEQf9wDn5PkCg7PZRmoPArKV5u4KggADGBID//+UPkA== Date: Wed, 12 Dec 2018 02:59:12 +0000 Message-ID: References: <3831.1544545763@localhost> <47b9e5cbf7e64fad91a9fc79e83e392c@XCH-ALN-010.cisco.com> <27594.1544566907@localhost> In-Reply-To: <27594.1544566907@localhost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.174.56] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.37.102.24, xch-rcd-014.cisco.com X-Outbound-Node: rcdn-core-10.cisco.com Archived-At: Subject: Re: [Ace] est-coaps clarification on /att and /crts X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2018 02:59:17 -0000 Gotcha, so you are describing a provisional DTLS connection at the server.= =20 Just to give a bit more color, in a usecase we are working on right now the= mesh network link rate <100Kbps. That network gets oversubscribed with leg= it cacert responses. I can only imagine how worse it would be if bad guys w= ere allowed to send small /crt requests and trigger big cert responses.=20 Just a 4.01 would not tell the client that he needs to send client certs fo= r auth. In plain EST it would take an HTTP 401 with an=20 WWW-Authenticate =3D "WWW-Authenticate" ":" 1#challenge header in the response. Unless we replicate that a generic 4.01 would not b= e enough for the client to know what to do.=20 Another issue is EST-coaps request pipelining. A cacerts could precede an e= nrollment in the same DTLS connection (for really constrained devices that = don't want to establish two connections). This could be opening room for un= authenticated enrollments when pipelining is used.=20 I think it is a good idea to not repeat the EST behavior in regards to /crt= and /att. Provisional TLS at the server could have value in Constrianed-BR= SKI/voucher though, for some situations though.=20 > So I think that we need to say something in EST-COAPS to explain that we = do not see a use case for replying to /crts and /att for clients which are = not recognized. Is 401 (4.01) or 403 (4.03) more appropriate do you think?= =20 Currently we say that clients need to be authenticated in a DTLS connection= before an EST-coaps request. Do you want to make it more explicit to say t= hat even though EST allowed for it, EST-coaps does not allow unauthenticate= d /crt and /att? We can certainly add that.=20 Rgs, Panos -----Original Message----- From: Michael Richardson =20 Sent: Tuesday, December 11, 2018 5:22 PM To: Panos Kampanakis (pkampana) ; ace@ietf.org; anima@i= etf.org Cc: Peter van der Stok ; Max Pritikin (pritikin) Subject: Re: est-coaps clarification on /att and /crts * PGP Signed by an unknown key Panos Kampanakis (pkampana) wrote: > I thought about this for the EST-coaps draft. EST allowed for=20 > unauthenticated /cacerts and /csrattrs (/crt and /att in EST-coaps) as=20 > you are suggesting. Exactly. > It is not as simple in EST-coaps. Two reasons: > 1) There are constrained networks where an easy amplification attack=20 > could take place. For example the /crt request is very small and the=20 > response can be big (a few KBs in the context of a constrained network=20 > is big). If unauthenticated, then /crts could be an easy amplification=20 > attack to saturate a constrained network. We don't want that to=20 > happen. We want all our clients to be authenticated by DTLS before=20 > they start loading up our RF network. I'm not suggesting that the DTLS be skipped, I'm suggesting that the client= certificate presented might be meaningless to the EST server. As for amplication attacks, they usually depend upon forged source addresse= s, and in that case the DTLS wouldn't have completed. > 2) Additionally, there is a practical challenge of COAPS. When the=20 > DTLS handshake is taking place the server does not know what the=20 > request will be. In EST the server would send an HTTP WWW-Authenticate=20 > header to ask the client to authenticate. Such a mechanism does not=20 > exist in COAP, so it would not be straightforward unless we introduced=20 > a bunch of new things into COAP. AFAIK, we don't support HTTP-level authentication in COAPS, only DTLS level= authentication is specified in EST-COAPS. > I think it is still right to authenticate clients even for /crt and=20 > /att in the EST-coaps context. Maybe that is something to be revisited=20 > in Constrained-BRSKI/voucher, but not taken lightly. So I think that we need to say something in EST-COAPS to explain that we do= not see a use case for replying to /crts and /att for clients which are no= t recognized. Is 401 (4.01) or 403 (4.03) more appropriate do you think? -- ] Never tell me the odds! | ipv6 mesh network= s [ ] Michael Richardson, Sandelman Software Works | IoT architect = [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [ -- Michael Richardson , Sandelman Software Works -=3D = IPv6 IoT consulting =3D- * Unknown Key * 0xDDD0DD65 From nobody Wed Dec 12 01:09:47 2018 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 5356113114B; Wed, 12 Dec 2018 01:09:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 G7k3Le-7QGf1; Wed, 12 Dec 2018 01:09:43 -0800 (PST) Received: from smtp-out11.electric.net (smtp-out11.electric.net [185.38.181.39]) (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 AA59B13114A; Wed, 12 Dec 2018 01:09:43 -0800 (PST) Received: from 1gX0WS-000KB6-UF by out11a.electric.net with emc1-ok (Exim 4.90_1) (envelope-from ) id 1gX0WS-000KDg-Vj; Wed, 12 Dec 2018 01:09:40 -0800 Received: by emcmailer; Wed, 12 Dec 2018 01:09:40 -0800 Received: from [194.218.146.197] (helo=sp-mail-2.sp.se) by out11a.electric.net with esmtps (TLSv1.2:ECDHE-RSA-AES128-SHA256:128) (Exim 4.90_1) (envelope-from ) id 1gX0WS-000KB6-UF; Wed, 12 Dec 2018 01:09:40 -0800 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_128_CBC_SHA256_P256) id 15.1.1531.3; Wed, 12 Dec 2018 10:09:39 +0100 To: Jim Schaad , CC: References: <154322421294.8323.8505315870685563404.idtracker@ietfa.amsl.com> <042a01d4873c$a91bb5a0$fb5320e0$@augustcellars.com> From: Ludwig Seitz Message-ID: Date: Wed, 12 Dec 2018 10:09:39 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <042a01d4873c$a91bb5a0$fb5320e0$@augustcellars.com> 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-Outbound-IP: 194.218.146.197 X-Env-From: ludwig.seitz@ri.se X-Proto: esmtps X-Revdns: X-HELO: sp-mail-2.sp.se X-TLS: TLSv1.2:ECDHE-RSA-AES128-SHA256:128 X-Authenticated_ID: X-Virus-Status: Scanned by VirusSMART (c) X-Virus-Status: Scanned by VirusSMART (s) X-PolicySMART: 14510320 Archived-At: Subject: Re: [Ace] Fwd: New Version Notification for draft-ietf-ace-oauth-authz-17.txt and draft-ietf-ace-oauth-params-01.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2018 09:09:46 -0000 On 28/11/2018 18:06, Jim Schaad wrote: > Ludwig, > > It looks good. A couple of additional things that have occurred to me. > (Always a problem when on reads drafts again and again.) > > 1. I don't really have a problem with figure 6, but I don't know if we want > to more correctly reflect what an OSCORE message would look like in this > location. This would basically be a re-write of the entire example > structure to reflect that you have an outer and an inner CoAP message. It > might be confusing for people who are not fully immersed in the OSCORE > world. As far as the example goes, we would need to add an OSCORE option, I wouldn't want to expand the encrypted payload to reflect the full OSCORE structure, since that is likely going to be more confusing than helpful. > > 2. I have no idea of where this would go and it is perhaps something that > the OAuth people need to think about as well. If an AS receives a request > which has message level security (OSCORE/CWT/JWT) over a session level > security connection (TLS/DTLS/IPSEC) are there any rules/suggestions about > which keys should be used for evaluating the resulting request. While I > assume that message security wins and the session security is ignored, I > have not seen this anyplace. > Good point. I would think that message level security would prevail, but that would need to be specified in a profile. > 3. In section 5.8.1 - It says that for a CWT access token that the > application/cwt content type MUST be used. There are two possible issues > with this. 1) How does the client know what the type of the token is. It > could be a CWT, an introspection token, or something else entirely. 2) Is > it an error if a CWT token is received and the content type is not present? > Right, the token is supposed to be opaque to the client. I will remove that requirement. /Ludwig -- Ludwig Seitz, PhD Security Lab, RISE Phone +46(0)70-349 92 51 From nobody Wed Dec 12 01:27:56 2018 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 6812F130DC5 for ; Wed, 12 Dec 2018 01:27:54 -0800 (PST) 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 f58_iwlTLMhf for ; Wed, 12 Dec 2018 01:27:52 -0800 (PST) Received: from smtp.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBC1C1286E3 for ; Wed, 12 Dec 2018 01:27:51 -0800 (PST) Received: from [192.168.1.109] (p508A4EFC.dip0.t-ipconnect.de [80.138.78.252]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.uni-bremen.de (Postfix) with ESMTPSA id B2AE9204F6; Wed, 12 Dec 2018 10:27:49 +0100 (CET) To: Jim Schaad , 'Ludwig Seitz' , ace@ietf.org References: <154322421294.8323.8505315870685563404.idtracker@ietfa.amsl.com> <03b601d49191$7d1bb400$77531c00$@augustcellars.com> From: Stefanie Gerdes Message-ID: <2778adbc-a453-f9bf-b8b8-2e23bafd5da2@tzi.de> Date: Wed, 12 Dec 2018 10:27:43 +0100 User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <03b601d49191$7d1bb400$77531c00$@augustcellars.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Ace] Fwd: New Version Notification for draft-ietf-ace-oauth-authz-17.txt and draft-ietf-ace-oauth-params-01.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2018 09:27:55 -0000 Hi Jim, thank you for your quick response. On 12/11/2018 09:38 PM, Jim Schaad wrote: >> >> C may receive keying material for the communication with RS from AS. >> Unfortunately, the AS does not inform C how long the keying material is > valid. C >> therefore may use outdated keying material for the communication. C cannot >> rely on RS to reject messages that were sent with outdated keying material >> because 1. the information in the request sent by C may be confidential > and is >> then compromised and 2. C cannot be sure that it is actually communicating >> with the intended RS if the keying material is no longer valid. > > Would you feel that this would be eased by requiring the expires_in field to > be required as part of the response? It is the expiration of the token, but > I have never understood the difference between the expiration of the token > and the expiration of keying material myself. Keying material never > expires, you just cannot use it without a valid token. As long as it is clear that the expires_in field describes the time until the keying material expires, this is at least better than nothing, although it leaves the problem that the client does not know when the token was created and how much time has already passed since then. The ACE framework should also point out that a client must check if its keying material for RS is still valid before it makes a request. BTW, I don't think keying material should be valid forever, especially if there is no useful revocation mechanism. > >> >> I did not find any indication how the client knows how to choose the > correct >> req_aud for RS. The document must point out that C may communicate with >> the wrong RS unless C and AS have a common understanding how RS is >> identified. > > Scope is also something that the client does not know how to build. In the worst case, a wrong scope can only prevent a client from accessing a certain resource. Even if the client does not specify any scope, the AS can still grant it permissions. If they are broad enough, they will likely cover the resource that C wants to access. A wrong req_aud however may cause the client to communicate with the wrong RS. Even worse, C will not be able to notice that it communicates with the wrong RS. This is a serious security risk. Currently, the ACE framework does not even acknowledge that such a risk exists. Viele Grüße Steffi From nobody Wed Dec 12 01:33:53 2018 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 A2446131149 for ; Wed, 12 Dec 2018 01:33:52 -0800 (PST) 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 sOD7PhekL85W for ; Wed, 12 Dec 2018 01:33:51 -0800 (PST) Received: from smtp.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0780131148 for ; Wed, 12 Dec 2018 01:33:50 -0800 (PST) Received: from [192.168.1.109] (p508A4EFC.dip0.t-ipconnect.de [80.138.78.252]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.uni-bremen.de (Postfix) with ESMTPSA id 49D0E20363; Wed, 12 Dec 2018 10:33:49 +0100 (CET) From: Stefanie Gerdes To: Ludwig Seitz , "ace@ietf.org" References: <154322421294.8323.8505315870685563404.idtracker@ietfa.amsl.com> Message-ID: <043bc23f-f566-55d0-7c94-200d72b98341@tzi.de> Date: Wed, 12 Dec 2018 10:33:48 +0100 User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: [Ace] Overwriting Tokens X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2018 09:33:53 -0000 Hi again, I have one additional comment to ace-oauth-17: Section 5.8.1 recommends that RS stores only one token per key and that existing tokens are overwritten by new tokens. I wonder how the RS knows which token is the most recent. I don't think the expiration time helps in this case because it should be possible for the AS to provide a token that expires earlier than the previous token. Viele Grüße Steffi From nobody Wed Dec 12 01:47:30 2018 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 7FB61131148 for ; Wed, 12 Dec 2018 01:47:28 -0800 (PST) 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, RCVD_IN_DNSWL_LOW=-0.7, 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 ljMAqrd7i5d1 for ; Wed, 12 Dec 2018 01:47:26 -0800 (PST) Received: from smtp-out11.electric.net (smtp-out11.electric.net [185.38.181.42]) (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 BD31512777C for ; Wed, 12 Dec 2018 01:47:25 -0800 (PST) Received: from 1gX16u-000R7C-Vk by out11c.electric.net with emc1-ok (Exim 4.90_1) (envelope-from ) id 1gX16v-000RAn-UC; Wed, 12 Dec 2018 01:47:21 -0800 Received: by emcmailer; Wed, 12 Dec 2018 01:47:21 -0800 Received: from [194.218.146.197] (helo=sp-mail-2.sp.se) by out11c.electric.net with esmtps (TLSv1.2:ECDHE-RSA-AES128-SHA256:128) (Exim 4.90_1) (envelope-from ) id 1gX16u-000R7C-Vk; Wed, 12 Dec 2018 01:47:20 -0800 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_128_CBC_SHA256_P256) id 15.1.1531.3; Wed, 12 Dec 2018 10:47:20 +0100 To: Jim Schaad , 'Stefanie Gerdes' , References: <154322421294.8323.8505315870685563404.idtracker@ietfa.amsl.com> <03b601d49191$7d1bb400$77531c00$@augustcellars.com> From: Ludwig Seitz Message-ID: <945fbebe-659f-ac72-3ab6-8e05447e7c92@ri.se> Date: Wed, 12 Dec 2018 10:47:20 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <03b601d49191$7d1bb400$77531c00$@augustcellars.com> 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-Outbound-IP: 194.218.146.197 X-Env-From: ludwig.seitz@ri.se X-Proto: esmtps X-Revdns: X-HELO: sp-mail-2.sp.se X-TLS: TLSv1.2:ECDHE-RSA-AES128-SHA256:128 X-Authenticated_ID: X-PolicySMART: 14510320 X-Virus-Status: Scanned by VirusSMART (c) X-Virus-Status: Scanned by VirusSMART (s) Archived-At: Subject: Re: [Ace] Fwd: New Version Notification for draft-ietf-ace-oauth-authz-17.txt and draft-ietf-ace-oauth-params-01.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2018 09:47:29 -0000 On 11/12/2018 21:38, Jim Schaad wrote: > > >> -----Original Message----- >> From: Ace On Behalf Of Stefanie Gerdes >> Sent: Tuesday, December 11, 2018 4:11 AM >> To: Ludwig Seitz ; ace@ietf.org >> Subject: Re: [Ace] Fwd: New Version Notification for > draft-ietf-ace-oauth-authz- >> 17.txt and draft-ietf-ace-oauth-params-01.txt >> >> Hi, >> >> I looked through the document again. Many issues have been fixed, but I > still >> have some comments: >> >> I still think that Section 5.8.1, in particular 5.8.1.1 should point out > that RS must >> check the integrity of the token und validate that it stems from an > authorized >> AS. Checking the iss field does not help in this case and I don't see much > value >> in this check; cryptographic assurance such as AS' signature or MAC of the >> token is required to ascertain the authenticity, and in this case the > issuer, of the >> token. > > I would agree with this. I have never been sure why the 'iss' field is > going to be useful. The only place that I can see this would be an AS which > is using one key but two identities. I would argue that this is a situation > that is prone to configuration errors and incorrect security. > The value of checking the iss field is indeed limited, but if present I feel it MUST be checked. The text does say that the RS must check the integrity of the token (see 5.8.1.1.) "Since the cryptographic wrapper of the token (e.g. a COSE message) could include encryption, it needs to be verified first, based on shared cryptographic material with recognized AS." This implies that the RS must check that the AS is recognized, I will rephrase this to clarify that "recognized" means that the AS is authorized to issue tokens for the RS. >> 5.8.1. exiting -> existing >> Fixed. >> Section 5.8.1. states that RS must check that the expiration time given in > the >> exp field is in the future. This is difficult if the RS is not time > synchronized. Indeed, but in those cases one wouldn't use the exp claim in the first place. I will add some text to the assumptions on AS knowledge about C and RS to the effect that the AS should know if the RS can manage synchronized time. >> Option 3 in section 5.8.3 seems to suggest that this field is not always > required. Indeed no claim is specifically required in the framework. >> Instead of demanding that the exp field is checked the document should >> demand that the RS somehow validates that the token is not expired. > Checking >> the exp field may be one example. The document demands that exp is checked _if present_. I don't like to normatively require something that is not concrete such as "somehow validate that the token is not expired". If we define other ways than exp and exi, then normative requirements should be placed in the documents that define those. >> >> C may receive keying material for the communication with RS from AS. >> Unfortunately, the AS does not inform C how long the keying material is > valid. C >> therefore may use outdated keying material for the communication. C cannot >> rely on RS to reject messages that were sent with outdated keying material >> because 1. the information in the request sent by C may be confidential > and is >> then compromised and 2. C cannot be sure that it is actually communicating >> with the intended RS if the keying material is no longer valid. > > Would you feel that this would be eased by requiring the expires_in field to > be required as part of the response? It is the expiration of the token, but > I have never understood the difference between the expiration of the token > and the expiration of keying material myself. Keying material never > expires, you just cannot use it without a valid token. > Well you have several cases of keying material here: a.) A symmetric pop-key bound to one or more tokens. That will only be valid as long as there is a valid token. b.) An asymmetric key belonging to either client of RS, which may be bound to a token, or used to authenticate (e.g. in a DTLS-RPK handshake). Those are valid independently of the ACE framework and need to be managed, updated and expired by some other mechanisms. c.) A symmetric key shared between C-AS or RS-AS for authentication purposes. ACE has no mechanisms for managing and updating this kind of keys. Starting to look into this looks lite a rat-hole to me. Does any of you feel we should document this in the framework? I'm currently leaning towards no, but could be convinced otherwise. >> >> I did not find any indication how the client knows how to choose the > correct >> req_aud for RS. The document must point out that C may communicate with >> the wrong RS unless C and AS have a common understanding how RS is >> identified. > > Scope is also something that the client does not know how to build. Learning the correct req_aud and scope is out of scope (no pun intended) for ACE. This would either be part of the configuration of a client, or a client could look it up in some resource directory. I'll add the note about needing to have a common understanding about how RS's are identified. /Ludwig -- Ludwig Seitz, PhD Security Lab, RISE Phone +46(0)70-349 92 51 From nobody Wed Dec 12 02:04:31 2018 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 4BED812F295 for ; Wed, 12 Dec 2018 02:04:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 ldKHEyCfmamM for ; Wed, 12 Dec 2018 02:04:25 -0800 (PST) Received: from smtp-out11.electric.net (smtp-out11.electric.net [185.38.181.38]) (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 B993F12777C for ; Wed, 12 Dec 2018 02:04:25 -0800 (PST) Received: from 1gX1NN-0002uW-TH by out11a.electric.net with emc1-ok (Exim 4.90_1) (envelope-from ) id 1gX1NN-0002w3-Ua; Wed, 12 Dec 2018 02:04:21 -0800 Received: by emcmailer; Wed, 12 Dec 2018 02:04:21 -0800 Received: from [194.218.146.197] (helo=sp-mail-2.sp.se) by out11a.electric.net with esmtps (TLSv1.2:ECDHE-RSA-AES128-SHA256:128) (Exim 4.90_1) (envelope-from ) id 1gX1NN-0002uW-TH; Wed, 12 Dec 2018 02:04:21 -0800 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_128_CBC_SHA256_P256) id 15.1.1531.3; Wed, 12 Dec 2018 11:04:20 +0100 To: Stefanie Gerdes , Jim Schaad , References: <154322421294.8323.8505315870685563404.idtracker@ietfa.amsl.com> <03b601d49191$7d1bb400$77531c00$@augustcellars.com> <2778adbc-a453-f9bf-b8b8-2e23bafd5da2@tzi.de> From: Ludwig Seitz Message-ID: Date: Wed, 12 Dec 2018 11:04:20 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <2778adbc-a453-f9bf-b8b8-2e23bafd5da2@tzi.de> Content-Type: text/plain; charset="windows-1252"; 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-Outbound-IP: 194.218.146.197 X-Env-From: ludwig.seitz@ri.se X-Proto: esmtps X-Revdns: X-HELO: sp-mail-2.sp.se X-TLS: TLSv1.2:ECDHE-RSA-AES128-SHA256:128 X-Authenticated_ID: X-PolicySMART: 14510320 X-Virus-Status: Scanned by VirusSMART (c) X-Virus-Status: Scanned by VirusSMART (s) Archived-At: Subject: Re: [Ace] Fwd: New Version Notification for draft-ietf-ace-oauth-authz-17.txt and draft-ietf-ace-oauth-params-01.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2018 10:04:29 -0000 On 12/12/2018 10:27, Stefanie Gerdes wrote: > Hi Jim, > > thank you for your quick response. > > On 12/11/2018 09:38 PM, Jim Schaad wrote: >>> >>> C may receive keying material for the communication with RS from AS. >>> Unfortunately, the AS does not inform C how long the keying material is >> valid. C >>> therefore may use outdated keying material for the communication. C cannot >>> rely on RS to reject messages that were sent with outdated keying material >>> because 1. the information in the request sent by C may be confidential >> and is >>> then compromised and 2. C cannot be sure that it is actually communicating >>> with the intended RS if the keying material is no longer valid. >> >> Would you feel that this would be eased by requiring the expires_in field to >> be required as part of the response? It is the expiration of the token, but >> I have never understood the difference between the expiration of the token >> and the expiration of keying material myself. Keying material never >> expires, you just cannot use it without a valid token. > > As long as it is clear that the expires_in field describes the time > until the keying material expires, this is at least better than nothing, > although it leaves the problem that the client does not know when the > token was created and how much time has already passed since then. > > The ACE framework should also point out that a client must check if its > keying material for RS is still valid before it makes a request. > > BTW, I don't think keying material should be valid forever, especially > if there is no useful revocation mechanism. > Note that expires_in (exi) is currently defined as "expires in x seconds from the time at which the RS first saw the token". I am aware that this is quite weak since malicious clients can hoard tokens that would be valid indefinitely. I do not currently see any other means of expiration when the RS has no connectivity to the AS and no synchronized clock. I would be open for suggestions if you have better ideas. >>> >>> I did not find any indication how the client knows how to choose the >> correct >>> req_aud for RS. The document must point out that C may communicate with >>> the wrong RS unless C and AS have a common understanding how RS is >>> identified. >> >> Scope is also something that the client does not know how to build. > > In the worst case, a wrong scope can only prevent a client from > accessing a certain resource. Even if the client does not specify any > scope, the AS can still grant it permissions. If they are broad enough, > they will likely cover the resource that C wants to access. > A wrong req_aud however may cause the client to communicate with the > wrong RS. Even worse, C will not be able to notice that it communicates > with the wrong RS. This is a serious security risk. > Currently, the ACE > framework does not even acknowledge that such a risk exists. > We do acknowledge that, in the security considerations of draft-ietf-ace-oauth-params where req_aud is defined. I'll add additional clarification to that text though, since it currently only talks about the needing to RS know which audiences it recognizes. -- Ludwig Seitz, PhD Security Lab, RISE Phone +46(0)70-349 92 51 From nobody Wed Dec 12 02:05:54 2018 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 C887812F295 for ; Wed, 12 Dec 2018 02:05:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 H-qGqpzuXlgb for ; Wed, 12 Dec 2018 02:05:47 -0800 (PST) Received: from smtp-out11.electric.net (smtp-out11.electric.net [185.38.181.35]) (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 025EE130DC6 for ; Wed, 12 Dec 2018 02:05:46 -0800 (PST) Received: from 1gX1Oi-0006GG-Uw by out11a.electric.net with emc1-ok (Exim 4.90_1) (envelope-from ) id 1gX1Oj-0006Gi-T8; Wed, 12 Dec 2018 02:05:45 -0800 Received: by emcmailer; Wed, 12 Dec 2018 02:05:45 -0800 Received: from [194.218.146.197] (helo=sp-mail-2.sp.se) by out11a.electric.net with esmtps (TLSv1.2:ECDHE-RSA-AES128-SHA256:128) (Exim 4.90_1) (envelope-from ) id 1gX1Oi-0006GG-Uw; Wed, 12 Dec 2018 02:05:44 -0800 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_128_CBC_SHA256_P256) id 15.1.1531.3; Wed, 12 Dec 2018 11:05:44 +0100 To: Stefanie Gerdes , "ace@ietf.org" References: <154322421294.8323.8505315870685563404.idtracker@ietfa.amsl.com> <043bc23f-f566-55d0-7c94-200d72b98341@tzi.de> From: Ludwig Seitz Message-ID: Date: Wed, 12 Dec 2018 11:05:43 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <043bc23f-f566-55d0-7c94-200d72b98341@tzi.de> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit 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-Outbound-IP: 194.218.146.197 X-Env-From: ludwig.seitz@ri.se X-Proto: esmtps X-Revdns: X-HELO: sp-mail-2.sp.se X-TLS: TLSv1.2:ECDHE-RSA-AES128-SHA256:128 X-Authenticated_ID: X-Virus-Status: Scanned by VirusSMART (c) X-Virus-Status: Scanned by VirusSMART (s) X-PolicySMART: 14510320 Archived-At: Subject: Re: [Ace] Overwriting Tokens X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2018 10:05:54 -0000 On 12/12/2018 10:33, Stefanie Gerdes wrote: > Hi again, > > I have one additional comment to ace-oauth-17: > > Section 5.8.1 recommends that RS stores only one token per key and that > existing tokens are overwritten by new tokens. I wonder how the RS knows > which token is the most recent. I don't think the expiration time helps > in this case because it should be possible for the AS to > provide a token that expires earlier than the previous token. > > > Viele Grüße > Steffi > "Recent" here is meant as "most recently received". That is something the RS definitely can track. /Ludwig -- Ludwig Seitz, PhD Security Lab, RISE Phone +46(0)70-349 92 51 From nobody Wed Dec 12 02:17:02 2018 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 F2F0C130DC6 for ; Wed, 12 Dec 2018 02:17:00 -0800 (PST) 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 6WgjCustOMpn for ; Wed, 12 Dec 2018 02:16:59 -0800 (PST) Received: from smtp.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16D4A130DBE for ; Wed, 12 Dec 2018 02:16:59 -0800 (PST) Received: from [192.168.1.109] (p508A4EFC.dip0.t-ipconnect.de [80.138.78.252]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.uni-bremen.de (Postfix) with ESMTPSA id 6F7822052D for ; Wed, 12 Dec 2018 11:16:57 +0100 (CET) To: ace@ietf.org References: <154322421294.8323.8505315870685563404.idtracker@ietfa.amsl.com> <043bc23f-f566-55d0-7c94-200d72b98341@tzi.de> From: Stefanie Gerdes Message-ID: Date: Wed, 12 Dec 2018 11:16:57 +0100 User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Ace] Overwriting Tokens X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2018 10:17:01 -0000 Hi Ludwig, On 12/12/2018 11:05 AM, Ludwig Seitz wrote: > On 12/12/2018 10:33, Stefanie Gerdes wrote: >> Hi again, >> >> I have one additional comment to ace-oauth-17: >> >> Section 5.8.1 recommends that RS stores only one token per key and that >> existing tokens are overwritten by new tokens. I wonder how the RS knows >> which token is the most recent. I don't think the expiration time helps >> in this case because it should be possible for the AS to >> provide a token that expires earlier than the previous token. >> >> >> Viele Grüße >> Steffi >> > > "Recent" here is meant as "most recently received". That is something > the RS definitely can track. The token most recently received by RS is not necessarily the newest. A client may (accidentally or not) send the older token later than the newer token. Viele Grüße Steffi From nobody Wed Dec 12 08:01:45 2018 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 3B0AF130E5F; Wed, 12 Dec 2018 08:01:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.36 X-Spam-Level: X-Spam-Status: No, score=-3.36 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f7MRG92Uwz9v; Wed, 12 Dec 2018 08:01:16 -0800 (PST) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40040.outbound.protection.outlook.com [40.107.4.40]) (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 BC097130E78; Wed, 12 Dec 2018 08:01:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=K775lBOs9TkLpemjUhiW2XBLPku/RVrgu30J/iIaXRo=; b=OLjnHrBH4Kkcbie3L8KUESnO5Ru6FhKytg+EXsX/xmgyddMh8jpDcgGGUSK1vKQAmqGK4e+nodpQ146E2bGQA1CPieOX4I8FfceOXWbdHNUB6p3zJC9rs3VnQbioOBTSrFzHge1cIrWBD3mDVcckYZS4rYBo5tfTyZsonKLX9zU= Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB1503.eurprd08.prod.outlook.com (10.167.210.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1404.19; Wed, 12 Dec 2018 16:01:12 +0000 Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::2056:1db1:e01:4670]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::2056:1db1:e01:4670%3]) with mapi id 15.20.1404.026; Wed, 12 Dec 2018 16:01:12 +0000 From: Hannes Tschofenig To: "Panos Kampanakis (pkampana)" , Michael Richardson , "ace@ietf.org" , "anima@ietf.org" CC: Peter van der Stok , "Max Pritikin (pritikin)" Thread-Topic: est-coaps clarification on /att and /crts Thread-Index: AQHUkca4BtLnIlFbhEGGxTZ2pBjVOKV7Q0YQ Date: Wed, 12 Dec 2018 16:01:12 +0000 Message-ID: References: <3831.1544545763@localhost> <47b9e5cbf7e64fad91a9fc79e83e392c@XCH-ALN-010.cisco.com> <27594.1544566907@localhost> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [217.140.106.27] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0801MB1503; 6:qpXhigW1CzCFsOXfdhV01yZk9/ezPSdVXrhy2gg+RpOVds6DnvmTp3xJSI4Cz06yi1TY0qdtDiASmEr0vmFc5p0lsDw1r1g2obRKy23Q2DwKP3/Ec6vB+LquOQO7nDIkOMAV0MDHMmRJdllneOr7A+SZ0wqODe//+CM1/RPnK+1a4P4vCH/RzGxk2FwEaF/7e4KOstOi8aF3kmYEgLTSBbLN39vdegiEdj7M0oiFUXHoRS6Axjw9FK6sex0NsXrbz5iJLQiYUCYNXZLJ1NOt3tCTwQOIu7xoCfS/VvR1EDbtzrhjdoLbJhN8xUL98scHFUv8iKmY6I0vCUjqfR21/djWgIjr7M1ipX2gUf/rlHETB54Plchd0BoC51+OEIwzK2F/Q/l7QLMVUUALakEugH3hMc1G86coSjqsrKILQeitigxxvEBWkBa4//axF49NVxjnVvCDlsnThYeupS/dTQ==; 5:786I35Nixfnwk3HjzyFE/kttq/LYEMIZE6RzArYhtnywt6gsSibufEuuWGlSJ1QqOD9FwpRmp7yq4uBB1qCGu/+UVWdPMo5jBbFBxJBqCvBMwz5P05LIISlOHhJOfnaNtqU3gVdpbkqjWYgwOr1xUNv8wpyWGOpTMUJVI4gmWPs=; 7:9uCnX9KrCAxaWoEFWQ4jte6N5OqUGwbZA3VV8Dw3ybFXEJw6BC7v5bQpQbp4HdD/eJYK8osn1bwnO+Yu3alZCwiztXtKsBzwjOmzBemTlKq5vp/RBcMHT8PTlXE4YdqDsdIjn0qe/xFLZJ8jiADBlg== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 10aa4913-7ec9-4d9c-e63d-08d6604b0a02 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390098)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(4618075)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB1503; x-ms-traffictypediagnostic: VI1PR0801MB1503: x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(3230017)(999002)(6040522)(2401047)(5005006)(8121501046)(10201501046)(3231472)(944501520)(52105112)(3002001)(93006095)(93001095)(6055026)(148016)(149066)(150057)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123560045)(20161123558120)(20161123564045)(201708071742011)(7699051)(76991095); SRVR:VI1PR0801MB1503; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0801MB1503; x-forefront-prvs: 0884AAA693 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(396003)(366004)(39860400002)(136003)(376002)(40434004)(199004)(189003)(8936002)(305945005)(256004)(8676002)(5660300001)(4326008)(11346002)(6436002)(476003)(81166006)(76176011)(229853002)(486006)(25786009)(446003)(71200400001)(86362001)(74316002)(99286004)(93886005)(2906002)(71190400001)(3846002)(7696005)(316002)(68736007)(54906003)(6116002)(14454004)(81156014)(110136005)(106356001)(66066001)(33656002)(105586002)(97736004)(2501003)(5024004)(55016002)(7736002)(9686003)(53936002)(6246003)(72206003)(478600001)(186003)(26005)(6506007)(102836004)(14444005); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB1503; H:VI1PR0801MB2112.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: 3BgQM3S5Cmhwl53aB+Gpe1Y/ZgPUPxNk91sk4BEIBxNzZQGqU2+DvVydAjeI4yb0RoPtP1p4koHqAG5KlQYRtdjo1V2BCwo7ZNM9AdGAQvo8aP5YvNXRM4Y1zl3eJHmb9c4XM2F1ff63gofSjvvwfgpiMLyyt0Gj/vJw/BBTcZQGXgDZz0MC3UwLU2rMNfxc+JSais2LG2NOrGbnX0LVVcAsgy3T0wD0POYrTcoL1dQagOztIPC3BIAtCvBMSfTG9Qhp6gbxwFXQrk3An8Oy7qte5vvhHxuheKfNu5BQHvuL68qmw7Y8zMHsrcvOcUm/ spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: 10aa4913-7ec9-4d9c-e63d-08d6604b0a02 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Dec 2018 16:01:12.4688 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1503 Archived-At: Subject: Re: [Ace] est-coaps clarification on /att and /crts X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2018 16:01:36 -0000 Hi Panos, Hi Michael, > We want all our clients to be authenticated by DTLS before they start loa= ding up our RF network. > I'm not suggesting that the DTLS be skipped, I'm suggesting that the clie= nt certificate presented might be meaningless to the EST server. I am curious what security model you have in mind? If you don't do client a= uthentication then you are essentially issuing certificates to an anonymous= entity. This feels like a very bad idea, particularly since the CA is supp= osed to assert the identifier of the client via the certificate. What am I missing here? Ciao Hannes IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. From nobody Wed Dec 12 11:13:26 2018 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 9912D131261; Wed, 12 Dec 2018 11:13:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.96 X-Spam-Level: X-Spam-Status: No, score=-15.96 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.46, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 WLkkqA68c7Xl; Wed, 12 Dec 2018 11:13:15 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7EBE130F08; Wed, 12 Dec 2018 11:13:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1701; q=dns/txt; s=iport; t=1544641995; x=1545851595; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=2bDVMT/5S4OowiKsOl/doUUuWhaqaBa6tMGPCaLmadU=; b=E/xvRBfNQi70TCl5DOKgDWh23y4uvBmKN33KhwLX36Jc+dz9C2XrmvOZ lEBHShI4AE54iN1sSjcRsxFjVY98u6ak+bk9j+vXk3/nARnbREuyKj6UF XRuVkXXy8m/7ITUFTb15t8+9akjNY6LSZQWq1H35MMvtXOqBjkn2Xyg/0 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAADRXBFc/5RdJa1kGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUQQBAQEBAQsBgVopgWgnCowLjBGCDZdTFIFmCwEBhGw?= =?us-ascii?q?CgnwiNAkNAQMBAQIBAQJtKIU8AQEBAQIBOjYJBQcEAgEIEQQBAR8QMh0IAgQ?= =?us-ascii?q?BDQUIhRMIqBeKKYsfgR0XgUA/JmuDEoROARIBCR0xhSMCiSGXawkCjWiDZSC?= =?us-ascii?q?BXCOEd4pQiSmPbwIRFIEnHzhlcXAVO4Jsgz0BAo0bQTGLSYEfgR8BAQ?= X-IronPort-AV: E=Sophos;i="5.56,345,1539648000"; d="scan'208";a="211545458" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Dec 2018 19:13:14 +0000 Received: from XCH-ALN-012.cisco.com (xch-aln-012.cisco.com [173.36.7.22]) by rcdn-core-12.cisco.com (8.15.2/8.15.2) with ESMTPS id wBCJDEEN010235 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 12 Dec 2018 19:13:14 GMT Received: from xch-aln-010.cisco.com (173.36.7.20) by XCH-ALN-012.cisco.com (173.36.7.22) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 12 Dec 2018 13:13:13 -0600 Received: from xch-aln-010.cisco.com ([173.36.7.20]) by XCH-ALN-010.cisco.com ([173.36.7.20]) with mapi id 15.00.1395.000; Wed, 12 Dec 2018 13:13:13 -0600 From: "Panos Kampanakis (pkampana)" To: Hannes Tschofenig , Michael Richardson , "ace@ietf.org" , "anima@ietf.org" CC: Peter van der Stok , "Max Pritikin (pritikin)" Thread-Topic: est-coaps clarification on /att and /crts Thread-Index: AQHUkW6xEQf9wDn5PkCg7PZRmoPArKV5u4KggADGBID//+UPkIABQvEA///E8MA= Date: Wed, 12 Dec 2018 19:13:13 +0000 Message-ID: References: <3831.1544545763@localhost> <47b9e5cbf7e64fad91a9fc79e83e392c@XCH-ALN-010.cisco.com> <27594.1544566907@localhost> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.150.34.173] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.36.7.22, xch-aln-012.cisco.com X-Outbound-Node: rcdn-core-12.cisco.com Archived-At: Subject: Re: [Ace] est-coaps clarification on /att and /crts X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2018 19:13:19 -0000 Hi Hannes, Michael was only asking if allowing any anonymous entity to get the cacerts= (trusted root cert list) is worth it. RFC7030 allows for this. Of course a= n enrollment would still require authentication/authorization.=20 I was making the case that it is not worth to even allow anonymous get cace= rts.=20 Panos -----Original Message----- From: Hannes Tschofenig =20 Sent: Wednesday, December 12, 2018 11:01 AM To: Panos Kampanakis (pkampana) ; Michael Richardson ; ace@ietf.org; anima@ietf.org Cc: Peter van der Stok ; Max Pritikin (pritikin) Subject: RE: est-coaps clarification on /att and /crts Hi Panos, Hi Michael, > We want all our clients to be authenticated by DTLS before they start loa= ding up our RF network. > I'm not suggesting that the DTLS be skipped, I'm suggesting that the clie= nt certificate presented might be meaningless to the EST server. I am curious what security model you have in mind? If you don't do client a= uthentication then you are essentially issuing certificates to an anonymous= entity. This feels like a very bad idea, particularly since the CA is supp= osed to assert the identifier of the client via the certificate. What am I missing here? Ciao Hannes IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. From nobody Wed Dec 12 11:17:05 2018 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 78061130F1A for ; Wed, 12 Dec 2018 11:17:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 JpuFAdVFRYW1 for ; Wed, 12 Dec 2018 11:17:02 -0800 (PST) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C309130F09 for ; Wed, 12 Dec 2018 11:17:02 -0800 (PST) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 12 Dec 2018 11:11:31 -0800 From: Jim Schaad To: 'Stefanie Gerdes' , References: <154322421294.8323.8505315870685563404.idtracker@ietfa.amsl.com> <043bc23f-f566-55d0-7c94-200d72b98341@tzi.de> In-Reply-To: Date: Wed, 12 Dec 2018 11:16:29 -0800 Message-ID: <04a001d4924f$30e235f0$92a6a1d0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQK3+H3pFttPP+s38ebErlDfr5TlzwGwIdvjAojcdAYBSBXfoQJkucpIAfCVoJKjZfmHUA== Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Ace] Overwriting Tokens X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2018 19:17:04 -0000 > -----Original Message----- > From: Ace On Behalf Of Stefanie Gerdes > Sent: Wednesday, December 12, 2018 2:17 AM > To: ace@ietf.org > Subject: Re: [Ace] Overwriting Tokens >=20 > Hi Ludwig, >=20 > On 12/12/2018 11:05 AM, Ludwig Seitz wrote: > > On 12/12/2018 10:33, Stefanie Gerdes wrote: > >> Hi again, > >> > >> I have one additional comment to ace-oauth-17: > >> > >> Section 5.8.1 recommends that RS stores only one token per key and > >> that existing tokens are overwritten by new tokens. I wonder how = the > >> RS knows which token is the most recent. I don't think the = expiration > >> time helps in this case because it should be possible for the AS to > >> provide a token that expires earlier than the previous token. > >> > >> > >> Viele Gr=FC=DFe > >> Steffi > >> > > > > "Recent" here is meant as "most recently received". That is = something > > the RS definitely can track. >=20 > The token most recently received by RS is not necessarily the newest. > A client may (accidentally or not) send the older token later than the newer > token. And as you stated above, the older token may have a longer expiration = than the newer because of a different set of permissions. I think that = having the RS use the most recently received token is probably the best = strategy for an RS that I only going to keep one token. The client will know = which token is tagged to what original request if it is keeping more than one token itself. If it is must immediately posting tokens as it goes = along, then the AS could provide an older, but still valid, token on the next request. Jim >=20 > Viele Gr=FC=DFe > Steffi >=20 > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace From nobody Wed Dec 12 11:18:06 2018 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 85EBE130F16; Wed, 12 Dec 2018 11:18:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 vvMF7n6opDbK; Wed, 12 Dec 2018 11:18:01 -0800 (PST) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA713130F09; Wed, 12 Dec 2018 11:18:00 -0800 (PST) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 12 Dec 2018 11:12:51 -0800 From: Jim Schaad To: 'Hannes Tschofenig' , "'Panos Kampanakis (pkampana)'" , 'Michael Richardson' , , CC: 'Peter van der Stok' , "'Max Pritikin (pritikin)'" References: <3831.1544545763@localhost> <47b9e5cbf7e64fad91a9fc79e83e392c@XCH-ALN-010.cisco.com> <27594.1544566907@localhost> In-Reply-To: Date: Wed, 12 Dec 2018 11:17:49 -0800 Message-ID: <04a101d4924f$610eab50$232c01f0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQGPjv7lcqlAiUUAise1VV4kpyPAbQIUVGQwAvmGCYUCY0fpRgJQ0QBzAff7TbOlp7ECMA== Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Ace] est-coaps clarification on /att and /crts X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2018 19:18:05 -0000 > -----Original Message----- > From: Ace On Behalf Of Hannes Tschofenig > Sent: Wednesday, December 12, 2018 8:01 AM > To: Panos Kampanakis (pkampana) ; Michael > Richardson ; ace@ietf.org; anima@ietf.org > Cc: Peter van der Stok ; Max Pritikin (pritikin) > > Subject: Re: [Ace] est-coaps clarification on /att and /crts > > Hi Panos, Hi Michael, > > > We want all our clients to be authenticated by DTLS before they start loading > up our RF network. > > I'm not suggesting that the DTLS be skipped, I'm suggesting that the client > certificate presented might be meaningless to the EST server. > > I am curious what security model you have in mind? If you don't do client > authentication then you are essentially issuing certificates to an anonymous > entity. This feels like a very bad idea, particularly since the CA is supposed to > assert the identifier of the client via the certificate. > > What am I missing here? Hannes, What you are missing is that the question is not about issuing the certificate. That is going to require client authentication. What is being looked at is getting the list of trust anchors or the template for a certificate request based on an anonymous client. Jim > > Ciao > Hannes > > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended recipient, > please notify the sender immediately and do not disclose the contents to any > other person, use it for any purpose, or store or copy the information in any > medium. Thank you. > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace From nobody Wed Dec 12 13:45:13 2018 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 DDCEE1312DB; Wed, 12 Dec 2018 13:45:11 -0800 (PST) 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, 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 TLh7wGZXfmam; Wed, 12 Dec 2018 13:45:09 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8872F1312D9; Wed, 12 Dec 2018 13:45:09 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id CA4CB20089; Wed, 12 Dec 2018 16:45:02 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id AF606DF7; Wed, 12 Dec 2018 16:45:08 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id AD55965; Wed, 12 Dec 2018 16:45:08 -0500 (EST) From: Michael Richardson To: "Panos Kampanakis \(pkampana\)" cc: "ace\@ietf.org" , "anima\@ietf.org" , Peter van der Stok , "Max Pritikin \(pritikin\)" In-Reply-To: References: <3831.1544545763@localhost> <47b9e5cbf7e64fad91a9fc79e83e392c@XCH-ALN-010.cisco.com> <27594.1544566907@localhost> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Ace] est-coaps clarification on /att and /crts X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2018 21:45:12 -0000 --=-=-= Content-Type: text/plain Panos Kampanakis (pkampana) wrote: > Gotcha, so you are describing a provisional DTLS connection at the server. I'm thinking about a Registrar that might be serving both provisional connections and ones that are just renewing LDevIDs, and maybe ones that also serve selected factory installed IDevIDs (a use case which est-coaps caters directly to). > Currently we say that clients need to be authenticated in a DTLS connection > before an EST-coaps request. Do you want to make it more explicit to say > that even though EST allowed for it, EST-coaps does not allow > unauthenticated /crt and /att? We can certainly add that. I'd like to add this. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlwRgWQACgkQgItw+93Q 3WWT7ggAsPpX8JEJmKxY8e1BrZRoXWhx88H55/K7iXZJ2IajUL2PfHwag01SCIV5 Gejh8Uwhmfh+35Ayk9dk1gqEpBjyDBetU3mpeAf0D6sQq11bGmfldZ5YUxfP0Cku Be+M1zRroujr300o48LvmdzcXcoP2xarvNXxAGTw6rTpWhJDGI9Vn27YB6hUM2bI xk5MpRXZ4hPWNRixX6Oc6t12/5tgw+eF0vBbKXKTCqmAoHp++7JzSFe9jD1Emn9+ s/vYJmFGMzNx5T5uRti8xm32ZVEk+LgzpEyXjWRqQh8qRCh3KQhDgsDNcMymqeM8 Z02/Rh3S65niqbL4BFhzlKVFEg2D/Q== =uKnf -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Dec 12 13:50:10 2018 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 54DAC130F9D; Wed, 12 Dec 2018 13:50:02 -0800 (PST) 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, 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 vCZ_ceINHpYU; Wed, 12 Dec 2018 13:50:00 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32A7E130F14; Wed, 12 Dec 2018 13:50:00 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 3FF1920089; Wed, 12 Dec 2018 16:49:53 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 25115DF7; Wed, 12 Dec 2018 16:49:59 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 22D0B65; Wed, 12 Dec 2018 16:49:59 -0500 (EST) From: Michael Richardson To: Hannes Tschofenig cc: "Panos Kampanakis \(pkampana\)" , "ace\@ietf.org" , "anima\@ietf.org" , Peter van der Stok , "Max Pritikin \(pritikin\)" In-Reply-To: References: <3831.1544545763@localhost> <47b9e5cbf7e64fad91a9fc79e83e392c@XCH-ALN-010.cisco.com> <27594.1544566907@localhost> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Ace] [Anima] est-coaps clarification on /att and /crts X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2018 21:50:03 -0000 --=-=-= Content-Type: text/plain Hannes Tschofenig wrote: > > We want all our clients to be authenticated by DTLS before they start > > loading up our RF network. > > I'm not suggesting that the DTLS be skipped, I'm suggesting that the > > client certificate presented might be meaningless to the EST server. > I am curious what security model you have in mind? If you don't do client > authentication then you are essentially issuing certificates to an > anonymous entity. This feels like a very bad idea, particularly since the > CA is supposed to assert the identifier of the client via the certificate. Clients which are not **yet** authenticatable. The client shows up, does a DTLS connection. We let the DTLS connection succeed, because we want to record the particulars of the client, so we can ask a human. Much like happens when you ssh to a new host: it stops to ask if you you agree with the key. You don't know, so you hit ^C. So, that's all. We don't intend to issue certificates... yet. I'm also asking if there is some use case where the client might legitimate need the list of trust anchors (/cacerts request) in order so that it can...? (I couldn't think of a use case) -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlwRgoYACgkQgItw+93Q 3WUAywf8DNBaU+Vq663N1NptMYEAeXksSV2LPDVUSzO7j0Z4CY4N3OihMxcexDvM xlPCWojmOZSeO5OSKvQCQYtRVkgAwHNm99QE20iiN4Jyh3kCF6HT9XWnq8DvDgzC nsIUC+iiWZSQU5W33mT4pL0E9dgnrD5r+lofE2/1rXR9nKULpAj3ufk3nfbUSbwQ DBECaSUljTrKj8/spXfW0AYMw/eAsijrz/fNAH01/+w5QjYy/NlEWZ4xLFfEyJdX 8bm5PjLoowa+drLh2HRIt3YLoCXEUfm/5qY1Rl7phTu2BaSDTl/VYL9829MB8hb9 U5lofG3jfEbV8SYAd2Hu3U/rYzo+bw== =KuMr -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Dec 12 13:52:08 2018 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 6CF0B1312DB; Wed, 12 Dec 2018 13:52:06 -0800 (PST) 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, 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 2R2oN6tzjoO2; Wed, 12 Dec 2018 13:52:04 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64160130F9D; Wed, 12 Dec 2018 13:52:04 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id AA56820089; Wed, 12 Dec 2018 16:51:57 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 8F774DF7; Wed, 12 Dec 2018 16:52:03 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 8D82665; Wed, 12 Dec 2018 16:52:03 -0500 (EST) From: Michael Richardson To: "Max Pritikin \(pritikin\)" cc: Jim Schaad , "ace\@ietf.org" , "anima\@ietf.org" , Peter van der Stok , "Panos Kampanakis \(pkampana\)" In-Reply-To: References: <3831.1544545763@localhost> <036301d49179$f2558bf0$d700a3d0$@augustcellars.com> <26234.1544566610@localhost> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Ace] est-coaps clarification on /att and /crts X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2018 21:52:07 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Max Pritikin (pritikin) wrote: > Jim Schaad wrote: > jim> Clarification requested - exactly what element is the Registrar? mcr> It's an EST RFC7030 term, but essentially it's the server that mcr> connects to (or is) the CA. max> The Registrar terminology is from the Anima working group and is close= ly max> analogous to the =E2=80=9CRegistration Authority=E2=80=9D we know and = love from the PKI max> space. Oh, right. I forgot that Registration Authority (RA) is not the same word as "Registrar". I wonder if we should have aligned that more, or aligned it l= ess. =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlwRgwMACgkQgItw+93Q 3WViLAgArKWctVotCxbo/VK+skZUT7x7BtMEXOwZ1Xyn+NfCXYFz2300m402nf19 wZCN5ACTSuD71wEVWSIArKIQOsTBVYOXgKOPV+JTTh3EWSe1Ns2Dy0aUgkikTwNR 8MVSclo1SQMeKobKff/2kbefNWkzqM1L97/nhPWxbdpfpY+fmJo2wBLze7mINR5q zd0ZOGdMrBIuI8234Wumie1lxemPDLu6bYMW1rCksIcbaFhhteMbqWTpOrh4Bo32 Gua06NfN6vSdr/9/o+BvrX7kRKnpa67Gk/g3Fu6JUxfuRsiD5Ug/pJ+0W80Zivf9 X8GWc+kGbGcEdoW5/JgRnK4Sg1BIFA== =eFo2 -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Dec 13 06:42:19 2018 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 3DBF8126F72 for ; Thu, 13 Dec 2018 06:42:17 -0800 (PST) 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 767QYMH8Wcyj for ; Thu, 13 Dec 2018 06:42:14 -0800 (PST) Received: from smtp.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A49E124408 for ; Thu, 13 Dec 2018 06:42:14 -0800 (PST) Received: from [134.102.218.250] (dynamic-218-250.informatik.uni-bremen.de [134.102.218.250]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.uni-bremen.de (Postfix) with ESMTPSA id 2A75C205F3; Thu, 13 Dec 2018 15:42:12 +0100 (CET) From: Stefanie Gerdes To: Ludwig Seitz , Jim Schaad , ace@ietf.org References: <154322421294.8323.8505315870685563404.idtracker@ietfa.amsl.com> <03b601d49191$7d1bb400$77531c00$@augustcellars.com> <945fbebe-659f-ac72-3ab6-8e05447e7c92@ri.se> Message-ID: <1c5b81f3-50ce-be68-bec3-68ce2ff15b43@tzi.de> Date: Thu, 13 Dec 2018 15:42:12 +0100 User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <945fbebe-659f-ac72-3ab6-8e05447e7c92@ri.se> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Ace] Fwd: New Version Notification for draft-ietf-ace-oauth-authz-17.txt and draft-ietf-ace-oauth-params-01.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2018 14:42:18 -0000 Hi Ludwig, On 12/12/2018 10:47 AM, Ludwig Seitz wrote: > The value of checking the iss field is indeed limited, but if present I > feel it MUST be checked. > > The text does say that the RS must check the integrity of the token (see > 5.8.1.1.) > > "Since the cryptographic wrapper of the token (e.g. a COSE message) > could include encryption, it needs to be verified first, based on shared > cryptographic material with recognized AS." > > This implies that the RS must check that the AS is recognized, I will > rephrase this to clarify that "recognized" means that the AS is > authorized to issue tokens for the RS. I cannot find the term "integrity" in section 5.8.1.1. Encryption is not the same as integrity protection. Also, providing a "cryptographic wrapper" for the token seems to be optional, which means that RS does not necessarily check the authenticity of the token. The RS must check that the token stems from an authorized AS, otherwise anyone can issue a token to RS. BTW, "shared cryptographic material with recognized AS" implies that only symmetric solutions can be used between RS and AS. Is that what you intend here? The current text to the iss field implies that this field somehow helps RS to determine the origin of the token, but this is not the case. Anyone can write an authorized issuer into an issuer field. Authenticity can only be achieved with cryptographic measures. > >>> Instead of demanding that the exp field is checked the document should >>> demand that the RS somehow validates that the token is not expired. >> Checking >>> the exp field may be one example. > The document demands that exp is checked _if present_. > I don't like to normatively require something that is not concrete such > as "somehow validate that the token is not expired". If we define other > ways than exp and exi, then normative requirements should be placed in > the documents that define those. So you say that the exp field is optional. And the exi field is optional. If they are missing, the RS does not check if the token is still valid and may use outdated tokens. For the security of the solution it is required that the RS checks if the token is still valid. You should point out this requirement to achieve a secure solution. > > Well you have several cases of keying material here: > > a.) A symmetric pop-key bound to one or more tokens. That will only be > valid as long as there is a valid token. > > b.) An asymmetric key belonging to either client of RS, which may be > bound to a token, or used to authenticate (e.g. in a DTLS-RPK > handshake). Those are valid independently of the ACE framework and need > to be managed, updated and expired by some other mechanisms. > > c.) A symmetric key shared between C-AS or RS-AS for authentication > purposes. ACE has no mechanisms for managing and updating this kind of > keys. Starting to look into this looks lite a rat-hole to me. I am currently only referring to the keying material that AS provides to C, i.e., the symmetric key shared between C and RS or, if asymmetric keys are used, RS's RPK. Since it is clear to you that symmetric keys are only valid as long as the token, you should point that out in the document. C then has at least some clue how long the token is valid. Which is better than nothing. In the RPK case, the AS may be the one that provides C with RS's RPK. RPKs do not contain semantic information. Therefore, C must be able assume that the RPK is valid as long as the access token. As I said, the framework must also state that the client must check if its keying material is still valid each time before it sends a request to the RS. Otherwise the confidentiality of the request data may be breached. Viele Grüße Steffi From nobody Thu Dec 13 08:14:55 2018 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 E20DE1292AD for ; Thu, 13 Dec 2018 08:14:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 VykPtiRoWGIj for ; Thu, 13 Dec 2018 08:14:49 -0800 (PST) Received: from smtp-out11.electric.net (smtp-out11.electric.net [185.38.181.38]) (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 4694E12D4F2 for ; Thu, 13 Dec 2018 08:14:48 -0800 (PST) Received: from 1gXTdN-00029x-Ul by out11a.electric.net with emc1-ok (Exim 4.90_1) (envelope-from ) id 1gXTdO-0002Aq-TQ; Thu, 13 Dec 2018 08:14:46 -0800 Received: by emcmailer; Thu, 13 Dec 2018 08:14:46 -0800 Received: from [194.218.146.197] (helo=sp-mail-2.sp.se) by out11a.electric.net with esmtps (TLSv1.2:ECDHE-RSA-AES128-SHA256:128) (Exim 4.90_1) (envelope-from ) id 1gXTdN-00029x-Ul; Thu, 13 Dec 2018 08:14:45 -0800 Received: from [10.30.4.143] (10.116.0.226) by sp-mail-2.sp.se (10.100.0.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1531.3; Thu, 13 Dec 2018 17:14:45 +0100 From: Ludwig Seitz To: Stefanie Gerdes , Jim Schaad , References: <154322421294.8323.8505315870685563404.idtracker@ietfa.amsl.com> <03b601d49191$7d1bb400$77531c00$@augustcellars.com> <945fbebe-659f-ac72-3ab6-8e05447e7c92@ri.se> <1c5b81f3-50ce-be68-bec3-68ce2ff15b43@tzi.de> Message-ID: <4ae4eccd-68bf-18ef-f909-142f8172eca1@ri.se> Date: Thu, 13 Dec 2018 17:14:30 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <1c5b81f3-50ce-be68-bec3-68ce2ff15b43@tzi.de> 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-3.sp.se (10.100.0.163) To sp-mail-2.sp.se (10.100.0.162) X-Outbound-IP: 194.218.146.197 X-Env-From: ludwig.seitz@ri.se X-Proto: esmtps X-Revdns: X-HELO: sp-mail-2.sp.se X-TLS: TLSv1.2:ECDHE-RSA-AES128-SHA256:128 X-Authenticated_ID: X-Virus-Status: Scanned by VirusSMART (c) X-Virus-Status: Scanned by VirusSMART (s) X-PolicySMART: 14510320 Archived-At: Subject: Re: [Ace] Fwd: New Version Notification for draft-ietf-ace-oauth-authz-17.txt and draft-ietf-ace-oauth-params-01.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2018 16:14:53 -0000 On 13/12/2018 15:42, Stefanie Gerdes wrote: > Hi Ludwig, > > On 12/12/2018 10:47 AM, Ludwig Seitz wrote: > >> The value of checking the iss field is indeed limited, but if present I >> feel it MUST be checked. >> >> The text does say that the RS must check the integrity of the token (see >> 5.8.1.1.) >> >> "Since the cryptographic wrapper of the token (e.g. a COSE message) >> could include encryption, it needs to be verified first, based on shared >> cryptographic material with recognized AS." >> >> This implies that the RS must check that the AS is recognized, I will >> rephrase this to clarify that "recognized" means that the AS is >> authorized to issue tokens for the RS. > > I cannot find the term "integrity" in section 5.8.1.1. Encryption is not > the same as integrity protection. "Cryptograpic wrapper" can include integrity protection. The reason encryption is specifically mentioned here is that you have to process the crypto wrapper first, before doing any checks on the claims, since they could be encrypted. I have tried to rephrase this in the editor's version to clarify. (Side note: Basically you would want to do it the other way around, since it is much less resource consuming to verify the claims compared to verifying the crypto wrapper. Thus if you could discard a token due to some issue with the claims without having to check the crypto you would save some energy and time. Sadly since the token could be encrypted you cannot do it in that order) > Also, providing a "cryptographic > wrapper" for the token seems to be optional, which means that RS does > not necessarily check the authenticity of the token. The RS must check > that the token stems from an authorized AS, otherwise anyone can issue a > token to RS. > In OAuth you have different types of tokens, CWTs and JWTs typically have a cryptographic wrapper (but see section 6 of RFC 7519), but a token could just as well only be a random identifier, that the RS has to perform introspection on to learn the associated claims. Such a "reference token" would not have a cryptographic wrapper. > BTW, "shared cryptographic material with recognized AS" implies that > only symmetric solutions can be used between RS and AS. Is that what you > intend here? Not really, "shared cryptographic material" could be public keys that the AS and RS have shared with each other. > The current text to the iss field implies that this field somehow helps > RS to determine the origin of the token, but this is not the case. > Anyone can write an authorized issuer into an issuer field. Authenticity > can only be achieved with cryptographic measures. > I agree that the iss claim is not really useful to authenticate the issuer, however if it is present in the token the RS should process it. The text I wrote was not intended to imply that it helps with anything: "The issuer claim must identify an AS that has the authority to issue access tokens for the receiving RS. If that is not the case the RS MUST respond with a response code equivalent to the CoAP code 4.01 (Unauthorized)." This text is just instructions on how to process the claim. The authenticity of the issuer would either be verified by the the cryptographic wrapper or by introspection. (Side note: If an RS gets a "reference token" it would implicitly verify the authenticity of the issuer by doing introspection at the AS that is authorized to issue tokens for it). >> >>>> Instead of demanding that the exp field is checked the document should >>>> demand that the RS somehow validates that the token is not expired. >>> Checking >>>> the exp field may be one example. >> The document demands that exp is checked _if present_. >> I don't like to normatively require something that is not concrete such >> as "somehow validate that the token is not expired". If we define other >> ways than exp and exi, then normative requirements should be placed in >> the documents that define those. > > So you say that the exp field is optional. And the exi field is > optional. If they are missing, the RS does not check if the token is > still valid and may use outdated tokens. No if both fields are missing, the token is valid indefinitely, until explicitly revoked. > For the security of the > solution it is required that the RS checks if the token is still valid. > You should point out this requirement to achieve a secure solution. Yes but the RS can only do this based on the claims associated to the token. Certain profiles may require certain sets of claims to be in the token (e.g. aud, scope, exp/exi), but putting such requirements in the framework would be quite a big divergence from OAuth. >> >> Well you have several cases of keying material here: >> >> a.) A symmetric pop-key bound to one or more tokens. That will only be >> valid as long as there is a valid token. >> >> b.) An asymmetric key belonging to either client of RS, which may be >> bound to a token, or used to authenticate (e.g. in a DTLS-RPK >> handshake). Those are valid independently of the ACE framework and need >> to be managed, updated and expired by some other mechanisms. >> >> c.) A symmetric key shared between C-AS or RS-AS for authentication >> purposes. ACE has no mechanisms for managing and updating this kind of >> keys. Starting to look into this looks lite a rat-hole to me. > > I am currently only referring to the keying material that AS provides to > C, i.e., the symmetric key shared between C and RS or, if asymmetric > keys are used, RS's RPK. Since it is clear to you that symmetric keys > are only valid as long as the token, you should point that out in the > document. C then has at least some clue how long the token is valid. > Which is better than nothing. How would that give C a clue? There is no metadata associated to proof-of-possession keys that would tell C how long they are valid. Are you proposing we define such meta-data? If symmetric pop-keys are created for an access token, what point would there be to give them another lifetime than the token? Do you really think we need to write that out. > In the RPK case, the AS may be the one that provides C with RS's RPK. > RPKs do not contain semantic information. Therefore, C must be able > assume that the RPK is valid as long as the access token. > As I said, the framework must also state that the client must check if > its keying material is still valid each time before it sends a request > to the RS. Otherwise the confidentiality of the request data may be > breached. How are you proposing this should be done? There is no metadata associated to pop keys that would enable the client to do this. This would require some mechanisms outside of ACE. /Ludwig -- Ludwig Seitz, PhD Security Lab, RISE Phone +46(0)70-349 92 51 From nobody Fri Dec 14 04:51:50 2018 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 0B6B912F1AC for ; Fri, 14 Dec 2018 04:51:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.781 X-Spam-Level: X-Spam-Status: No, score=-4.781 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.46, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.979, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-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=ericsson.com header.b=Ecs6Fj2Y; dkim=pass (1024-bit key) header.d=ericsson.com header.b=GwUoMW2u 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 Dj4AJEHShQLc for ; Fri, 14 Dec 2018 04:51:45 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 5F5791294D7 for ; Fri, 14 Dec 2018 04:51:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1544791902; x=1547383902; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=bCY91H5TXL1mB+Cko19O7zy7wMcT0zmgf++jJ91vQcQ=; b=Ecs6Fj2Y1ZfZcvc0rJUJiT2kcw0iz9UmkWeM6oeiqkNePS2ra4+e0EaJByVklfb2 RWgSIWJ3GVNldeqoJXmY2WC9DzRTurs55/jB2BsthgG/jMx5ZPDOKTVsxxErhrK1 wHcLg9UUP9bW3bi+aeF4N6B85UBQF4tjq6Rg4ofraGU=; X-AuditID: c1b4fb3a-5c9c29e00000672c-04-5c13a75ea65e Received: from ESESSMB502.ericsson.se (Unknown_Domain [153.88.183.120]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id A5.40.26412.E57A31C5; Fri, 14 Dec 2018 13:51:42 +0100 (CET) Received: from ESESSMB501.ericsson.se (153.88.183.162) by ESESSMB502.ericsson.se (153.88.183.163) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Fri, 14 Dec 2018 13:51:41 +0100 Received: from EUR04-HE1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESSMB501.ericsson.se (153.88.183.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Fri, 14 Dec 2018 13:51:40 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=bCY91H5TXL1mB+Cko19O7zy7wMcT0zmgf++jJ91vQcQ=; b=GwUoMW2uTWauHHgFmzE35wl3kPT+7mvwbQCInEr8Jj4k5iwoNyDVlz975o7PbBospBBgse1WpGY9jX9v971H5b+NRsEr2bePBJC59X/8JYonVkj5ML+KeDDs9OrkVgjHUpgKebrv1iHw2bezeei/S9TDFrmujp6nP7TvaOELTu0= Received: from AM6PR07MB4822.eurprd07.prod.outlook.com (20.177.190.219) by AM6PR07MB4913.eurprd07.prod.outlook.com (20.177.118.218) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1425.8; Fri, 14 Dec 2018 12:51:36 +0000 Received: from AM6PR07MB4822.eurprd07.prod.outlook.com ([fe80::3d6f:cb36:583b:269d]) by AM6PR07MB4822.eurprd07.prod.outlook.com ([fe80::3d6f:cb36:583b:269d%5]) with mapi id 15.20.1446.006; Fri, 14 Dec 2018 12:51:36 +0000 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: "consultancy@vanderstok.org" , Roman Danyliw CC: "ace@ietf.org" Thread-Topic: [Ace] Call for adoption of draft-palombini-ace-key-groupcomm Thread-Index: AdSI8aalNXFev0zyRSiL4RjyZD+fmQEVdUoAAZspVQA= Date: Fri, 14 Dec 2018 12:51:36 +0000 Message-ID: <471BEE0F-827D-4EDB-8A77-B9C595B3AB93@ericsson.com> References: <359EC4B99E040048A7131E0F4E113AFC0184C52E29@marathon> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.13.0.181109 x-originating-ip: [192.176.1.91] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM6PR07MB4913; 6:SkXOFJAU6vlDY/50KkucyCYL5hMpgC+zB4cl4AKHlBehDtUUacQe8Cfm442ZHJdCch7nhyqHLl9jitKfxZdet1l6yC33jdwg3qPTkjYdhZtd+Pw6jxp1D7oDlEiIoQwJ8ii0uRmIgtcI7Anq59z9gYJlvUqv1cfINwV4VUzxaU8W4vLFbgEUNHsEAJhhoq8vFOInTa3vXvi2d5XtoBk4Ojig+glusOaycgoVFCzoLq5O7zhgCgdQ2rbwpCV8FEnfjIDVkhd+tb4RcH/JH50fwGRcRAnrwvYnciW8MD3ZZDk2qwmzOAx+J3LdRmhOYjv/pqJh6OizCof2ekslCiqc5HRthfvKdXB40fwrDoo2bMp1Xgm0dkvGxio38X/HUAfpDvWG0iLxry8fgmDTJK4l679NOqHm34A6TMniU0y5XzMtOZrO4nxdbFIjpNlM+ADVjWOCXRCAjycrr8+REYWItQ==; 5:fRJ+n/rZYiiO/llgTtnffubNRjUuIwlYvrbLEbZEqVPmKth02Q5yJ7HTKONe8CX6tYyB/XPOoRGMGvOSJhRyqegdNHkYZ9lAX0CqEEx8AmDGVBCccHg28aJs9i7coKF20ipVny1JomLpFaewaa2a7YgtX27QdMVcTwCW526G8wo=; 7:tiM5gTCz+QCWU2SHqGcG8SZfRqaMYieU7PIPeWYpKWTepC58uKDPqPazbp4r2Pt1mDy5H4nizh/4Kudxzp5CYgA0OrcvTzHYDiWk1Jbqpz2woMOTOMGh6QNNp9D85Ra2kFlMPwu6ZHTvkXXK2b4IXw== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 9a0893b9-b1eb-40f3-750d-08d661c2e259 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:AM6PR07MB4913; x-ms-traffictypediagnostic: AM6PR07MB4913: authentication-results: spf=none (sender IP is ) smtp.mailfrom=goran.selander@ericsson.com; x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(3230021)(999002)(6040522)(2401047)(8121501046)(5005006)(3002001)(3231475)(944501520)(52105112)(93006095)(93001095)(10201501046)(148016)(149066)(150057)(6041310)(20161123562045)(20161123564045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(201708071742011)(7699051)(76991095); SRVR:AM6PR07MB4913; BCL:0; PCL:0; RULEID:; SRVR:AM6PR07MB4913; x-forefront-prvs: 08864C38AC x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(136003)(376002)(39860400002)(346002)(396003)(189003)(199004)(6306002)(66066001)(54896002)(6506007)(186003)(236005)(6512007)(7736002)(83716004)(606006)(14454004)(33656002)(71200400001)(71190400001)(4001150100001)(97736004)(316002)(966005)(256004)(5660300001)(110136005)(478600001)(58126008)(26005)(68736007)(81156014)(81166006)(8676002)(102836004)(229853002)(4326008)(36756003)(446003)(8936002)(2501003)(6436002)(99286004)(66574011)(2616005)(2906002)(82746002)(25786009)(11346002)(486006)(106356001)(6116002)(86362001)(6486002)(85202003)(85182001)(105586002)(6246003)(3846002)(76176011)(53936002)(476003); DIR:OUT; SFP:1101; SCL:1; SRVR:AM6PR07MB4913; H:AM6PR07MB4822.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: pKCJUeW69SQCzJWpcvWn5/CAw55lnwFH4sm2ae42RaapaGelM2lZvLjbtvVJsTl9HozuKX6AHtQHOq7L8l/J2R0spVpzrs7DAXjwgjDqyfImUDULszhRuoLiErBIl57OxHDFpjsfCSaOZ7UYp8Ins3nTgn6m504M4VrXMwo5/StqOHkUZ6FMtlk2TW7AfOJqSAwuRCDVdQ71mXBZeHWWF+wUmpvIvGXXMw03ZGf4SMaFOhn+DZ5araIIt1gh9aB3133E4pWXAdDfqf5lEeVOwL8ydPrqPNO0MO2BxfhRC2hzmXn20DPQhY8mDITkb8eb spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_471BEE0F827D4EDB8A77B9C595B3AB93ericssoncom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 9a0893b9-b1eb-40f3-750d-08d661c2e259 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Dec 2018 12:51:36.7126 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR07MB4913 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrDKsWRmVeSWpSXmKPExsUyM2J7hW7ccuEYg9N7pC2+f+thtni0fxWb xec2NgdmjxkbfDyWLPnJ5HGiYTt7AHMUl01Kak5mWWqRvl0CV8bdF/2sBWccK/71r2BqYLxv 38XIySEhYCLx6et61i5GLg4hgSOMEhv6r7JDON8YJfYfO80I4Sxhkngw6RwTSAuLwARmiad/ SyASU5gk7rz+wgbhPGKU+NZzgg2kik3AReJBwyOwDhGBWIn+r3dYQWxmAUWJdXP6wOLCAp4S O1+chKrxkjj1bgEbhG0l8enZFUaIbaoSC6bvZQaxeQXsJS5+OA5UwwG0rFBi0TxRkDAnUPnC 17fBxjAKiEl8P7WGCWKVuMStJ/OZIP4UkFiy5zwzhC0q8fLxP7BzRAX0JVpP9bNDxBUkbi8/ zgJhy0pcmt8N9r2EwDU2iU1LW6ASuhIfpk6FGuQr0bD2JVTRBUaJU2cOMkIktCRWtr+AuihO omldAxtEPFvi0O4OqGY5iVW9D1kmMBrMQnIshJ0sMeffStZZYD8LSpyc+YRlFtDPzAKaEut3 6c+CBuOU7ofsELaGROucuVC2h8TxQ1dYkdUsYORYxShanFpcnJtuZKSXWpSZXFycn6eXl1qy iRGYpg5u+W21g/Hgc8dDjAIcjEo8vJenCscIsSaWFVfmHmKU4GBWEuENawUK8aYkVlalFuXH F5XmpBYfYpTmYFES5/0jJBgjJJCeWJKanZpakFoEk2Xi4JRqYNx4UuTN1O9M6kYq+lLR/r7H 7CauOn3LpXDPJI0YSYvm3fJWCjFWwauZFj/6KFbXvvXnj+r+Z2rXvlew/D4b2lv6Y1114TLb A5O8Ovy5m0t/WEywEzbnuq98Mm1n2o+G66varti+d9X6cYNH5NKtu4W7eARz33+UeHZaxMBB wrct5Q/rEm7BhUosxRmJhlrMRcWJALUm1vZPAwAA Archived-At: Subject: Re: [Ace] Call for adoption of draft-palombini-ace-key-groupcomm X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2018 12:51:48 -0000 --_000_471BEE0F827D4EDB8A77B9C595B3AB93ericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBzdXBwb3J0IGFkb3B0aW9uLiBUaGlzIGRyYWZ0IGlzIGEgY29tcG9uZW50IGluIHRoZSBncm91 cCBrZXkgbWFuYWdlbWVudCBzb2x1dGlvbiByZXF1ZXN0ZWQgYnkgZGlmZmVyZW50IGluZHVzdHJ5 IGNvbnNvcnRpYS4NCg0KR8O2cmFuDQoNCkZyb206IEFjZSA8YWNlLWJvdW5jZXNAaWV0Zi5vcmc+ IG9uIGJlaGFsZiBvZiBQZXRlciB2YW4gZGVyIFN0b2sgPHN0b2tjb25zQGJiaG1haWwubmw+DQpP cmdhbml6YXRpb246IHZhbmRlcnN0b2sgY29uc3VsdGFuY3kNClJlcGx5LVRvOiAiY29uc3VsdGFu Y3lAdmFuZGVyc3Rvay5vcmciIDxjb25zdWx0YW5jeUB2YW5kZXJzdG9rLm9yZz4NCkRhdGU6IFRo dXJzZGF5LCA2IERlY2VtYmVyIDIwMTggYXQgMTA6MzkNClRvOiBSb21hbiBEYW55bGl3IDxyZGRA Y2VydC5vcmc+DQpDYzogImFjZUBpZXRmLm9yZyIgPGFjZUBpZXRmLm9yZz4NClN1YmplY3Q6IFJl OiBbQWNlXSBDYWxsIGZvciBhZG9wdGlvbiBvZiBkcmFmdC1wYWxvbWJpbmktYWNlLWtleS1ncm91 cGNvbW0NCg0KSSBzdXBwb3J0IHRoZSBhZG9wdGlvbiBvZiB0aGlzIGRyYWZ0Lg0KSXQgaXMgdGhl IHJpZ2h0IHNvbHV0aW9uIHRvIG91ciBzZWN1cmUgZ3JvdXAgY29tbXVuaWNhdGlvbiB3aXNoZXMu DQoNClBldGVyDQoNClJvbWFuIERhbnlsaXcgc2NocmVlZiBvcCAyMDE4LTExLTMwIDIyOjU4Og0K SGVsbG8hDQoNClRoaXMgaXMgdGhlIHN0YXJ0IG9mIGEgdHdvIHdlZWsgY2FsbCBmb3IgaW5wdXQg b24gdGhlIFdHIGFkb3B0aW9uIG9mIHRoZSBkb2N1bWVudDoNCg0KZHJhZnQtcGFsb21iaW5pLWFj ZS1rZXktZ3JvdXBjb21tDQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtcGFsb21i aW5pLWFjZS1rZXktZ3JvdXBjb21tLTAyDQoNClRoZSBkb2N1bWVudCBoYXMgYmVlbiBwcmVzZW50 ZWQgYW5kIGRpc2N1c3NlZCBhdCB0aGUgbGFzdCBmZXcgbWVldGluZ3M7IGFuZCByZXZpc2lvbnMg aGF2ZSBiZWVuIG1hZGUgYmFzZWQgb24gV0cgZmVlZGJhY2suICBBdCB0aGUgSUVURiAxMDMgbWVl dGluZywgdGhlcmUgd2FzIHN1cHBvcnQgZm9yIGFkb3B0aW9uOyBhbmQgdm9sdW50ZWVycyB0byBy ZXZpZXcgYW5kIGltcGxlbWVudCB0aGUgZHJhZnQuDQoNClBsZWFzZSBwcm92aWRlIGZlZWRiYWNr IHRvIHRoZSBsaXN0L2NoYWlycyBpZiB5b3UgYmVsaWV2ZSB0aGF0IHRoaXMgZG9jdW1lbnQgc2hv dWxkIGJlIGFkb3B0ZWQgYXMgYSBXRyBkb2N1bWVudC4gICAgVGhlIGFkb3B0aW9uIGNhbGwgd2ls bCBlbmQgb24gRGVjZW1iZXIgMTQgMjAxOC4NCg0KUmVnYXJkcywNClJvbWFuIGFuZCBKaW0NCg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkFjZSBtYWls aW5nIGxpc3QNCkFjZUBpZXRmLm9yZzxtYWlsdG86QWNlQGlldGYub3JnPg0KaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hY2UNCg== --_000_471BEE0F827D4EDB8A77B9C595B3AB93ericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <4E845113BA6D2E4583A91389E1268835@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNv bm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6 bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207 DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQt c2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5F bWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5 cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjEN Cgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcwLjg1cHQgNzAuODVwdCA3MC44NXB0 IDcwLjg1cHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48 L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iU1YiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJw bGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIj5JIHN1cHBvcnQgYWRvcHRpb24uIFRoaXMgZHJhZnQgaXMgYSBjb21w b25lbnQgaW4gdGhlIGdyb3VwIGtleSBtYW5hZ2VtZW50IHNvbHV0aW9uIHJlcXVlc3RlZCBieSBk aWZmZXJlbnQgaW5kdXN0cnkgY29uc29ydGlhLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+R8O2cmFuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNt Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5Gcm9tOg0KPC9zcGFuPjwv Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+QWNlICZsdDthY2Ut Ym91bmNlc0BpZXRmLm9yZyZndDsgb24gYmVoYWxmIG9mIFBldGVyIHZhbiBkZXIgU3RvayAmbHQ7 c3Rva2NvbnNAYmJobWFpbC5ubCZndDs8YnI+DQo8Yj5Pcmdhbml6YXRpb246IDwvYj52YW5kZXJz dG9rIGNvbnN1bHRhbmN5PGJyPg0KPGI+UmVwbHktVG86IDwvYj4mcXVvdDtjb25zdWx0YW5jeUB2 YW5kZXJzdG9rLm9yZyZxdW90OyAmbHQ7Y29uc3VsdGFuY3lAdmFuZGVyc3Rvay5vcmcmZ3Q7PGJy Pg0KPGI+RGF0ZTogPC9iPlRodXJzZGF5LCA2IERlY2VtYmVyIDIwMTggYXQgMTA6Mzk8YnI+DQo8 Yj5UbzogPC9iPlJvbWFuIERhbnlsaXcgJmx0O3JkZEBjZXJ0Lm9yZyZndDs8YnI+DQo8Yj5DYzog PC9iPiZxdW90O2FjZUBpZXRmLm9yZyZxdW90OyAmbHQ7YWNlQGlldGYub3JnJmd0Ozxicj4NCjxi PlN1YmplY3Q6IDwvYj5SZTogW0FjZV0gQ2FsbCBmb3IgYWRvcHRpb24gb2YgZHJhZnQtcGFsb21i aW5pLWFjZS1rZXktZ3JvdXBjb21tPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDozNi4wcHQiPkkgc3VwcG9ydCB0aGUgYWRvcHRpb24gb2YgdGhpcyBkcmFmdC48YnI+ DQpJdCBpcyB0aGUgcmlnaHQgc29sdXRpb24gdG8gb3VyIHNlY3VyZSBncm91cCBjb21tdW5pY2F0 aW9uIHdpc2hlcy48YnI+DQo8YnI+DQpQZXRlcjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1h cmdpbi1sZWZ0OjM2LjBwdCI+Um9tYW4gRGFueWxpdyBzY2hyZWVmIG9wIDIwMTgtMTEtMzAgMjI6 NTg6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LWxlZnQ6c29saWQgIzEwMTBGRiAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDUuMHB0O21hcmdp bi1sZWZ0OjBjbTttYXJnaW4tcmlnaHQ6MGNtIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDsiPkhlbGxvITxicj4NCjxicj4NClRoaXMgaXMgdGhlIHN0YXJ0 IG9mIGEgdHdvIHdlZWsgY2FsbCBmb3IgaW5wdXQgb24gdGhlIFdHIGFkb3B0aW9uIG9mIHRoZSBk b2N1bWVudDo8YnI+DQo8YnI+DQpkcmFmdC1wYWxvbWJpbmktYWNlLWtleS1ncm91cGNvbW08YnI+ DQo8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtcGFsb21iaW5pLWFj ZS1rZXktZ3JvdXBjb21tLTAyIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LXBhbG9tYmluaS1hY2Uta2V5LWdyb3VwY29tbS0wMjwvYT48YnI+DQo8YnI+ DQpUaGUgZG9jdW1lbnQgaGFzIGJlZW4gcHJlc2VudGVkIGFuZCBkaXNjdXNzZWQgYXQgdGhlIGxh c3QgZmV3IG1lZXRpbmdzOyBhbmQgcmV2aXNpb25zIGhhdmUgYmVlbiBtYWRlIGJhc2VkIG9uIFdH IGZlZWRiYWNrLiAmbmJzcDtBdCB0aGUgSUVURiAxMDMgbWVldGluZywgdGhlcmUgd2FzIHN1cHBv cnQgZm9yIGFkb3B0aW9uOyBhbmQgdm9sdW50ZWVycyB0byByZXZpZXcgYW5kIGltcGxlbWVudCB0 aGUgZHJhZnQuDQo8YnI+DQo8YnI+DQpQbGVhc2UgcHJvdmlkZSBmZWVkYmFjayB0byB0aGUgbGlz dC9jaGFpcnMgaWYgeW91IGJlbGlldmUgdGhhdCB0aGlzIGRvY3VtZW50IHNob3VsZCBiZSBhZG9w dGVkIGFzIGEgV0cgZG9jdW1lbnQuICZuYnNwOyZuYnNwOyZuYnNwO1RoZSBhZG9wdGlvbiBjYWxs IHdpbGwgZW5kIG9uIERlY2VtYmVyIDE0IDIwMTguPGJyPg0KPGJyPg0KUmVnYXJkcyw8YnI+DQpS b21hbiBhbmQgSmltPGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX188YnI+DQpBY2UgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRv OkFjZUBpZXRmLm9yZyI+QWNlQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYWNlIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hY2U8L2E+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_471BEE0F827D4EDB8A77B9C595B3AB93ericssoncom_-- From nobody Fri Dec 14 04:52:06 2018 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 4238212F1AC for ; Fri, 14 Dec 2018 04:52:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.78 X-Spam-Level: X-Spam-Status: No, score=-4.78 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.46, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.979, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=Ud2q7omI; dkim=pass (1024-bit key) header.d=ericsson.com header.b=LijL7DKR 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 IDe_sDArBPTN for ; Fri, 14 Dec 2018 04:52:02 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A01DF131103 for ; Fri, 14 Dec 2018 04:52:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1544791918; x=1547383918; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=qSKsiIbm2Kgzkbg0YEvoo2rrwb1BIX+tb/1uVNu0kmI=; b=Ud2q7omIN0Vv+h3cPiIIJUbDxGpa1KnQKP4ApB6N3rs1VWPEj2QLrdPx9+61IJBW verRbFGLLBi2SLPjFkshtOOoAAFsddqRmUd3fj5ZNVhT99vIYvtPqi2+EP+fssYP +mX6IOEwHpORzlYYzYdbAsvybasyAQHFq5KKhNEUWkc=; X-AuditID: c1b4fb2d-db5ff7000000062f-94-5c13a76ea997 Received: from ESESBMB504.ericsson.se (Unknown_Domain [153.88.183.117]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id A6.DE.01583.E67A31C5; Fri, 14 Dec 2018 13:51:58 +0100 (CET) Received: from ESESBMB502.ericsson.se (153.88.183.169) by ESESBMB504.ericsson.se (153.88.183.171) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Fri, 14 Dec 2018 13:51:58 +0100 Received: from EUR04-HE1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESBMB502.ericsson.se (153.88.183.169) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Fri, 14 Dec 2018 13:51:58 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=qSKsiIbm2Kgzkbg0YEvoo2rrwb1BIX+tb/1uVNu0kmI=; b=LijL7DKRMguiB4EoJp3JOJfYqqWlAaFmDlBDbADIa5fJSisuZ63U5HfZ5+8pOfmoqAKljRTRHoiYcb2QOvnwNHxLLoEQD+7Q+MvgaqrD5HMLy3FD2i3x0qYoPIbKm6YMEEcJUP9i8YX4FM7x7DEe28kirch4pTDkg+p1+A6n024= Received: from AM6PR07MB4822.eurprd07.prod.outlook.com (20.177.190.219) by AM6PR07MB5223.eurprd07.prod.outlook.com (20.177.198.85) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1446.9; Fri, 14 Dec 2018 12:51:57 +0000 Received: from AM6PR07MB4822.eurprd07.prod.outlook.com ([fe80::3d6f:cb36:583b:269d]) by AM6PR07MB4822.eurprd07.prod.outlook.com ([fe80::3d6f:cb36:583b:269d%5]) with mapi id 15.20.1446.006; Fri, 14 Dec 2018 12:51:57 +0000 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: "ace@ietf.org" Thread-Topic: [Ace] Call for adoption of draft-tiloca-ace-oscoap-joining Thread-Index: AdSOSyoBX9JmO3oaTa+0R8uqGXjjJAFaQOmA Date: Fri, 14 Dec 2018 12:51:57 +0000 Message-ID: <9580B17D-80E8-49BB-9AFC-3921905B2C7E@ericsson.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.13.0.181109 authentication-results: spf=none (sender IP is ) smtp.mailfrom=goran.selander@ericsson.com; x-originating-ip: [192.176.1.91] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM6PR07MB5223; 6:zzDrea6wQCnI8iL+3Il26ozl3fV2iiH0R/5h/lg9YzrfJv8KBBbYpcNtBfkxYYn3AA1l3Cbb54qvET29Qq8H37qit9ZrXYRmP+vjc1xf6OnqGvodDy1kirRqn9V3p0lX/YmhBQRQm1h59eGOL2iXWXeNBCeCotK6WhlRtANMvd9AXFZ34PQTo9uL/6Z+WE1CNY5YK3ECU1y9FHfOE09gg4UAvXsYh9bx3mXrnGW6w5t0XFdlPmT2bhitcOT3yPMXq7PGuBLdbZcNnzTh+ejoYcO/s59tWh+/kXoqulrv/vp/9hIIaHPvswU9HREApMk1lHSKRmr6gp2XmqQSAtpDp8YsFn2rYxtEBmeZjiUWS21gSn9S9waxa8n5OkbnqG53vck9blT+tQ2LE7l+6y7E+dgOKn2i4F5MSh2mNw6nwgrp6Vm79ae8w3Ld/wJQpYWKVshgPAWimtxfh9lefdFS5Q==; 5:xUG0y1SSgG/VUQX56B3qtWe/DWeYy2ORVrCXG5KdBrKGDe9aNPl5eRQUVC+VJHBov2l79Rh0O+Ptt9sNsRDhKYn4yKnR3qQqmgbkofoS5BN2U7sxU/i16cg3P97KT8zJgkb66+B406oBN0z0Ye+DO8UfQzsaZ8OWm5C00EjLcfg=; 7:zcLxhjHOnzpiJKQgABPT+mJ5YM3tImn9ADoLf0c8rac9lY7RIv5MVuFmGP6uHivkWbtzBvm7Ol9U2sElJk9fJjitsEbRuVSFgnlg9s/jcKRMLwoQq3/gajsR0OsEKfMeEVG0qt8DVTAyDo9uE9YSaQ== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: c722d9a5-00ea-4638-aee6-08d661c2eed5 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:AM6PR07MB5223; x-ms-traffictypediagnostic: AM6PR07MB5223: x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(3230021)(999002)(6040522)(2401047)(8121501046)(5005006)(3002001)(3231475)(944501520)(52105112)(93006095)(93001095)(10201501046)(148016)(149066)(150057)(6041310)(20161123564045)(20161123562045)(20161123560045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(201708071742011)(7699051)(76991095); SRVR:AM6PR07MB5223; BCL:0; PCL:0; RULEID:; SRVR:AM6PR07MB5223; x-forefront-prvs: 08864C38AC x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(346002)(39860400002)(366004)(136003)(376002)(199004)(189003)(5660300001)(1730700003)(229853002)(25786009)(71190400001)(81166006)(71200400001)(6246003)(476003)(2351001)(36756003)(256004)(68736007)(66066001)(486006)(5640700003)(478600001)(236005)(8676002)(3846002)(8936002)(6116002)(81156014)(2906002)(83716004)(53936002)(66574011)(11346002)(26005)(2616005)(6306002)(54896002)(14454004)(186003)(86362001)(446003)(966005)(6512007)(6486002)(6436002)(85182001)(6916009)(7736002)(316002)(102836004)(97736004)(76176011)(53546011)(6506007)(105586002)(33656002)(606006)(2501003)(82746002)(85202003)(106356001)(99286004)(58126008); DIR:OUT; SFP:1101; SCL:1; SRVR:AM6PR07MB5223; H:AM6PR07MB4822.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: elPa1IxIVurg4XHC8NVTnVllOU3ANw6cNlNzKTvZLhOhZe/sbSAXAWNLSyJGl21Z3u7dkwxbTE7S/EwFYsYq+UjSo/Jc1gt5gOQF25JQy2uLiv+0+uO7j9Jc2j2r9L3spu+R0lt1ibwr3CNz8tb76Th+98dvVWhi2naGKHjAf+iZjy9lBNYfNqkegOq/q0RRwjt21ON7rr1u7j/OG5eBiuO4nkINLZ9itr+P/TuRMv5zOKk8gfmg0KWQIvoYIzDPRIPJulnN40xM37SIBNL7hD6rXe9/Wrj4ZSpWxxJsfp4BJfK09ax4sdHR6YJwrKP9 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_9580B17D80E849BB9AFC3921905B2C7Eericssoncom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: c722d9a5-00ea-4638-aee6-08d661c2eed5 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Dec 2018 12:51:57.7104 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR07MB5223 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02SbUhTURjHOffebdfh4jg3fVCKNory3ezND2UFpmJYgiURki29qKjTdtXS T6Yp6nwZpYlmGLE0VhZooqjVGko5EG1Yipo4X8jISKwm4kt5d2/gt9/5P7/n8DyHQ5Nyk8iL TtPmMDqtJkMtllINl7tyA7St7gnBr3+EhK46KsnTKMpoXCNi0RXpiWQmIy2P0QWFXZOmVq6V SrJtQbfudE1LClFzYAVyoQEfgQFLi6QCSWk57kewOdxE8gcHgtY1O8lZcmwkoPvPea5AYQMJ S53lBG/dI2B02C7iD7MIKldmxVyLGIfDTOHstkXTCqyCsVkNF7vjSLDdNlMcK3AUWJsMIp5D wKpflHBM4f1wv6/amcvwKeiYXhamCIdPejPi2AWfhakvpU4HYQ9YtT4nOCaxJ0zMNxP8bhiM fcMkz0r4Nrfl9JU4CEqsNRK+9yoUvSgU885emGx9T/G8G2zNesTtBfizGAzF5UIhAJbr6oRL Y6DdbpDw0giCJUe9IPmC6Ve9MEU6lD4xCPkeMFXZKb5hnIQhs4EyoKDGHZM3bj8YiZPgwc+4 RucDuMFgwzzFxz7wskewVVCrt0t4PgglTQ8FjoLSlkpip/MI0SakZBmWzUwJORzI6NKSWDZL G6hlctrR9g9692o9oBs9+37GgjCN1K4yWb17glykyWPzMy0IaFKtkMWXbEeyZE1+AaPLStTl ZjCsBXnTlNpTtiF3S5DjFE0Ok84w2Yzuf5WgXbwKUZmpQvVBlxlI+CkK4tZH/Nm/N75OVHm3 0aEwWDPqGrzsqDW/Wbwgjc1SlsWB/egxj+LJAZ/oFZSpwhHKfZ0dM23Lj8fjl5JUm6nRdSNP WxP7hsI/TvUeuN7z++Iuo3EjpnpM1v42wr9pYa03Ofbm8aKwfv3Jha1ztv2XIv3m7qopNlVz yJfUsZp/B0Ky8j0DAAA= Archived-At: Subject: Re: [Ace] Call for adoption of draft-tiloca-ace-oscoap-joining X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2018 12:52:04 -0000 --_000_9580B17D80E849BB9AFC3921905B2C7Eericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 KzENCg0KR8O2cmFuDQoNCkZyb206IEFjZSA8YWNlLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFs ZiBvZiAiV291dGVyIHZhbiBkZXIgQmVlayAod292YW5kZXIpIiA8d292YW5kZXJAY2lzY28uY29t Pg0KRGF0ZTogRnJpZGF5LCA3IERlY2VtYmVyIDIwMTggYXQgMTc6MzgNClRvOiAiYWNlQGlldGYu b3JnIiA8YWNlQGlldGYub3JnPg0KU3ViamVjdDogW0FjZV0gQ2FsbCBmb3IgYWRvcHRpb24gb2Yg ZHJhZnQtdGlsb2NhLWFjZS1vc2NvYXAtam9pbmluZw0KDQpIaQ0KDQorMQ0KVGhpcyBpcyBuZWVk ZWQgdG8gb3ZlcmNvbWUgdGhlIGN1cnJlbnQgaW5kdXN0cnkgaXNzdWUgbm90IGhhdmluZyBhIHNl Y3VyZSBtdWx0aWNhc3QgbWVjaGFuaXNtLg0KDQoNCktpbmQgUmVnYXJkcywNCldvdXRlciB2YW4g ZGVyIEJlZWsNClRlY2huaWNhbCBTdGVlcmluZyBDb21taXR0ZWUgQ2hhaXINCk9wZW4gY29ubmVj dGl2aXR5IGZvdW5kYXRpb24NCmh0dHBzOi8vb3BlbmNvbm5lY3Rpdml0eS5vcmcvDQoNCg== --_000_9580B17D80E849BB9AFC3921905B2C7Eericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <13E8780506DC0149A26F5B37AB008F17@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpw Lm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1u YW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6 MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglm b250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNw YW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30N Ci5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6 ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0K CW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0K CXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0i U1YiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0 aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+JiM0MzsxPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIj5Hw7ZyYW4gJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRE RiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+RnJvbToNCjwvc3Bhbj48L2I+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5BY2UgJmx0O2Fj ZS1ib3VuY2VzQGlldGYub3JnJmd0OyBvbiBiZWhhbGYgb2YgJnF1b3Q7V291dGVyIHZhbiBkZXIg QmVlayAod292YW5kZXIpJnF1b3Q7ICZsdDt3b3ZhbmRlckBjaXNjby5jb20mZ3Q7PGJyPg0KPGI+ RGF0ZTogPC9iPkZyaWRheSwgNyBEZWNlbWJlciAyMDE4IGF0IDE3OjM4PGJyPg0KPGI+VG86IDwv Yj4mcXVvdDthY2VAaWV0Zi5vcmcmcXVvdDsgJmx0O2FjZUBpZXRmLm9yZyZndDs8YnI+DQo8Yj5T dWJqZWN0OiA8L2I+W0FjZV0gQ2FsbCBmb3IgYWRvcHRpb24gb2YgZHJhZnQtdGlsb2NhLWFjZS1v c2NvYXAtam9pbmluZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIGxhbmc9IkVO LVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPkhpIDxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0 Ij4mIzQzOzE8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDozNi4wcHQiPlRoaXMgaXMgbmVlZGVkIHRvIG92ZXJjb21lIHRoZSBjdXJyZW50IGlu ZHVzdHJ5IGlzc3VlIG5vdCBoYXZpbmcgYSBzZWN1cmUgbXVsdGljYXN0IG1lY2hhbmlzbS48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4w cHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1sZWZ0OjM2LjBwdCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5LaW5kIFJlZ2FyZHMsPGJyPg0KV291dGVy IHZhbiBkZXIgQmVlazxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjM2LjBwdCI+VGVjaG5pY2FsIFN0ZWVyaW5nIENvbW1pdHRlZSBDaGFpcjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2 LjBwdCI+T3BlbiBjb25uZWN0aXZpdHkgZm91bmRhdGlvbiA8bzpwPg0KPC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PGEgaHJlZj0iaHR0 cHM6Ly9vcGVuY29ubmVjdGl2aXR5Lm9yZy8iPmh0dHBzOi8vb3BlbmNvbm5lY3Rpdml0eS5vcmcv PC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0OjM2LjBwdCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRt bD4NCg== --_000_9580B17D80E849BB9AFC3921905B2C7Eericssoncom_-- From nobody Fri Dec 14 07:15:04 2018 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 E3A12130DD0 for ; Fri, 14 Dec 2018 07:15:02 -0800 (PST) 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 pI1GH2jV7mdY for ; Fri, 14 Dec 2018 07:15:00 -0800 (PST) Received: from smtp.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CCA612F1A5 for ; Fri, 14 Dec 2018 07:15:00 -0800 (PST) Received: from [192.168.1.109] (p508A4EFC.dip0.t-ipconnect.de [80.138.78.252]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.uni-bremen.de (Postfix) with ESMTPSA id 42966203E2; Fri, 14 Dec 2018 16:14:58 +0100 (CET) From: Stefanie Gerdes To: Ludwig Seitz , Jim Schaad , ace@ietf.org References: <154322421294.8323.8505315870685563404.idtracker@ietfa.amsl.com> <03b601d49191$7d1bb400$77531c00$@augustcellars.com> <945fbebe-659f-ac72-3ab6-8e05447e7c92@ri.se> <1c5b81f3-50ce-be68-bec3-68ce2ff15b43@tzi.de> <4ae4eccd-68bf-18ef-f909-142f8172eca1@ri.se> Message-ID: Date: Fri, 14 Dec 2018 16:14:43 +0100 User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <4ae4eccd-68bf-18ef-f909-142f8172eca1@ri.se> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: [Ace] Token (In)Security X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2018 15:15:03 -0000 Hi all, as I understand the current proposal of the ACE framework, an attacker can send an access token to the RS that only contains a scope and is not signed or otherwise protected. Section 5.8.1.1 (titled verifying an access token) does not state that RS must check the authenticity of the token, therefore RS can accept it. Since the token does not contain an exp field, it is infinitely valid. The attacker thus gains infinite unconditional access. Is this really what we want from a security framework? I would expect section 5.8.1.1 to provide information if and when RS must check that the token stems from an authorized AS to prevent this scenario. Viele Grüße Steffi From nobody Fri Dec 14 07:16:24 2018 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 BDA42130DD0 for ; Fri, 14 Dec 2018 07:16:22 -0800 (PST) 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 wpgnuhLo8I2i for ; Fri, 14 Dec 2018 07:16:21 -0800 (PST) Received: from smtp.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBABF130DDA for ; Fri, 14 Dec 2018 07:16:20 -0800 (PST) Received: from [192.168.1.109] (p508A4EFC.dip0.t-ipconnect.de [80.138.78.252]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.uni-bremen.de (Postfix) with ESMTPSA id 52BAD203E2; Fri, 14 Dec 2018 16:16:19 +0100 (CET) From: Stefanie Gerdes To: Ludwig Seitz , Jim Schaad , ace@ietf.org References: <154322421294.8323.8505315870685563404.idtracker@ietfa.amsl.com> <03b601d49191$7d1bb400$77531c00$@augustcellars.com> <945fbebe-659f-ac72-3ab6-8e05447e7c92@ri.se> <1c5b81f3-50ce-be68-bec3-68ce2ff15b43@tzi.de> <4ae4eccd-68bf-18ef-f909-142f8172eca1@ri.se> Message-ID: <81ba3ab4-a9ce-a6fd-fbe6-c36a6fbbd9a5@tzi.de> Date: Fri, 14 Dec 2018 16:16:18 +0100 User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <4ae4eccd-68bf-18ef-f909-142f8172eca1@ri.se> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: [Ace] Security of the Communication Between C and RS (was: Re: Fwd: New Version Notification for draft-ietf-ace-oauth-authz-17.txt and draft-ietf-ace-oauth-params-01.txt) X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2018 15:16:23 -0000 Hi Ludwig, >> >> I am currently only referring to the keying material that AS provides to >> C, i.e., the symmetric key shared between C and RS or, if asymmetric >> keys are used, RS's RPK. Since it is clear to you that symmetric keys >> are only valid as long as the token, you should point that out in the >> document. C then has at least some clue how long the token is valid. >> Which is better than nothing. > > How would that give C a clue? There is no metadata associated to > proof-of-possession keys that would tell C how long they are valid. Are > you proposing we define such meta-data? > > If symmetric pop-keys are created for an access token, what point would > there be to give them another lifetime than the token? Do you really > think we need to write that out. I really think you should point out that symmetric keying material that the AS provides to the client is valid as long as the token. I also think that the client must be able to assume that RS' RPK that C receives from AS is also valid as long as the token, unless C has additional information. The access information optionally can contain an expires_in field. It would help to prevent security breaches under the following conditions: 1. the keying material is valid as long as the ticket, 2. the expires_in field is present in the access information that AS sends to C, 3. the client checks the expires_in field when it gets the access information from the AS, and 4. the client checks if the keying material is still valid each time before it sends a request to RS. Without these steps, the confidentiality of the request data that C sends to RS may be breached, and C may communicate with the wrong RS using outdated keying material. Viele Grüße Steffi From nobody Fri Dec 14 07:19:30 2018 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 3CF3F130DF2 for ; Fri, 14 Dec 2018 07:19:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.761 X-Spam-Level: X-Spam-Status: No, score=-5.761 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.46, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-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=ericsson.com header.b=dxZNV78h; dkim=pass (1024-bit key) header.d=ericsson.com header.b=fexySUAu 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 yd8f0dLKe7cg for ; Fri, 14 Dec 2018 07:19:26 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 6330E130DE5 for ; Fri, 14 Dec 2018 07:19:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1544800764; x=1547392764; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=l8nGkCTB9s/7vkblRrLqp9NBDpyzunbJM6r6Yp5mTSg=; b=dxZNV78hLsjw98reWrNPaw9TvUICK5HsLn8DXzrXp8ER/7ASZo7y6AImF4TSTno+ S2DKSgEwtwgoQUWp2L/40LXMGRxky3guQRwK/GasrYEgkbpTpYNHV7cWfLV51SSS 6azU03EGcN5qMmAPJNHCcpz0B2yyP9rV3N7IpfsaigM=; X-AuditID: c1b4fb3a-167ff7000000672c-f5-5c13c9fcb9e0 Received: from ESESSMB503.ericsson.se (Unknown_Domain [153.88.183.121]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 41.22.26412.CF9C31C5; Fri, 14 Dec 2018 16:19:24 +0100 (CET) Received: from ESESSMB503.ericsson.se (153.88.183.164) by ESESSMB503.ericsson.se (153.88.183.164) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Fri, 14 Dec 2018 16:19:24 +0100 Received: from EUR03-VE1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESSMB503.ericsson.se (153.88.183.164) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Fri, 14 Dec 2018 16:19:23 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=l8nGkCTB9s/7vkblRrLqp9NBDpyzunbJM6r6Yp5mTSg=; b=fexySUAuU6a07H5hbYIbOD5sj3k4jD4NBcV80aVZ97XY5ldko3L0gcvKrDkQKAPffCChZd5bpL4aJ7+JCZKGm3txhsnKacRWv3FMxGGFQ7yGGGnZy96M1CzXKc+EjsRpDhlE0E7a1cKxuNAjQjb7x3EpvyplMDWsI0vnOKoaoi0= Received: from HE1PR0701MB2746.eurprd07.prod.outlook.com (10.168.188.140) by HE1PR0701MB2252.eurprd07.prod.outlook.com (10.168.36.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1446.8; Fri, 14 Dec 2018 15:19:22 +0000 Received: from HE1PR0701MB2746.eurprd07.prod.outlook.com ([fe80::cdc3:81b2:e662:2bd9]) by HE1PR0701MB2746.eurprd07.prod.outlook.com ([fe80::cdc3:81b2:e662:2bd9%7]) with mapi id 15.20.1446.010; Fri, 14 Dec 2018 15:19:22 +0000 From: Francesca Palombini To: Roman Danyliw , "ace@ietf.org" Thread-Topic: OSCORE profile status Thread-Index: AQHUk8Bkud6SmrptaEaVpCFkVLZ3wQ== Date: Fri, 14 Dec 2018 15:19:22 +0000 Message-ID: <984F0754-CB2A-486A-B491-793972203BA5@ericsson.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.176.1.88] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HE1PR0701MB2252; 6:3enfQfDoN+IIyc2CRCPGSIC3h8A4aG1nWq5pNXy3YpLicisfiYVwFbz+2sneHnsHD/csb+xx9TT/fxl5Jj/4BSbDaocDGMSSqdN3sxH7GlEwTg4g9CUWRZdp91YJCzWADzjamNS/zMGAGmpNFQozCW/haZvxn6fuJZ0RIy3W3BMqCrIFHB/SU0A0c12O6TSKr9UeFVfuvWEx1SKxq8qpwuQOmWy3WT+TbTnRlcLjSTp65zmvE5pKiAWUU3DMF2GtwjbfMM4eDXPYCT1Jw0DSFrDsy4oz73S5YMlPm3paf9144ZJpCFwwQGqIdqQPAjaGe3V3M80wUs51PCUvxnaMh7pV13HtDVkuOPSWNBRVxw4OAoxRwdBJ1+9uZDgILzWQVkZyZRhE6H5i+wexb1arRW68eg8dIZrRJiZbS1iNttCvCFZW1T9vG0zNJDJWQx33sWv3+0dUqzeXh4SzVBKMFg==; 5:pxm1F0YvSLbiJJF1NcuqTKq3hRzPAfINcznpqX8zqLTb9dlH/HfPbblTP8Z5NNRcZ3Tb2JoMBQhHx+sFQ4cB6JnRfCBP4390JyODiSBM26W+qBhuTZbBz57vcPLzzp6gtXrN5mohL7M8ROpKagpJK/rDWckn3sZSKjZWninEUpI=; 7:riFM2nReaexfJtBmS74+LRvkZLFixC8wElWyfbrJJ1lwoTwaQncjruO7to+GkJmQHN5CoZLzNQGBb5n07jLXjO8JTSinbb/4XDqdBiZIT5X2W421xcuV4N6TbzuYFSI87ULcsM55rJpYTGtYkvOyjQ== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: ea6a0422-90ab-4eb5-be45-08d661d786c8 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600074)(711020)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:HE1PR0701MB2252; x-ms-traffictypediagnostic: HE1PR0701MB2252: x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(3230021)(999002)(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(3002001)(10201501046)(3231475)(944501520)(52105112)(148016)(149066)(150057)(6041310)(20161123562045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123558120)(201708071742011)(7699051)(76991095); SRVR:HE1PR0701MB2252; BCL:0; PCL:0; RULEID:; SRVR:HE1PR0701MB2252; x-forefront-prvs: 08864C38AC x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(366004)(39860400002)(136003)(396003)(376002)(199004)(189003)(99286004)(82746002)(8676002)(305945005)(36756003)(33656002)(6306002)(316002)(6486002)(7736002)(6436002)(66066001)(14444005)(256004)(110136005)(478600001)(25786009)(6512007)(97736004)(8936002)(81166006)(81156014)(44832011)(3846002)(26005)(486006)(68736007)(6506007)(106356001)(71200400001)(476003)(83716004)(86362001)(6116002)(6346003)(7116003)(71190400001)(105586002)(53936002)(2906002)(966005)(2501003)(186003)(5660300001)(14454004)(3480700005)(102836004)(2616005); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2252; H:HE1PR0701MB2746.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=francesca.palombini@ericsson.com; x-microsoft-antispam-message-info: eywr7WWpwDhHjfCXbsJvIRhkAxMMa6L2ROLfKXPbqnKXcZg5f/M7ZZn1rc4OZbx1UzP77xvl6n/J3nDKT+dXoBAmWS+neMccEmai013K8EKvJ6gt73s0lT5bxmxXPKPUeo45gXalw9j+6p0rYCNGLHXY1Ytwc2/Br2EVGD4kg7r/PY44hwaAPulOulfjU1dooiqoilvizVurqsoLCV+VtHQn0+w/yxA+ylt3uYAMGUEP1SNvXfkzMAfGY/fqC2qZ861vQOwA+s3yIcN2J63+uIu+KkjmayrtjY9vLeyVFdYkqQ4FkpYPuXMpuzDy50eN spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: ea6a0422-90ab-4eb5-be45-08d661d786c8 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Dec 2018 15:19:22.4888 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2252 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuplleLIzCtJLcpLzFFi42KZGbG9UvfPSeEYgzt3VSy+f+thtvjcxubA 5DFjg4/HkiU/mQKYorhsUlJzMstSi/TtErgybj14wF5wQqTi/ewJrA2MLSJdjBwcEgImEisv FXQxcnIICRxhlJg92aaLkQvI/sYo0brhETuEs4RJ4nzXIWYQh0VgArNEz6cWVojMdCaJTXN/ MkL0P2OUOLwrAMRmE7CRuPDwPSuILSJgL/Hl4Vk2EFtYQE7i36LlTBBxZYnjC36wQNh6Ep/W vWUGsVkEVCU+HDkBNpMXqPffzi9gNqOArMSXxtVgNcwC4hK3nswHmyMhICCxZM95ZghbVOLl 43+sELaCxLu5p9kgbFmJS/O7GUGOlhC4wSYxYcYzRoiErsSHqVOhmn0lPh2cAFV0iVFi0YZm doiEjsSGQ/OYIQGWL3GnNxgiLCexqvchC0T9HWaJqVuOQtXLSGy8twYqcZVVYtLf/0yQIEqV WL62FeqdZIkrt/vYJzDqzULy0SygHcwCmhLrd+lDmB4SnxYwQVQoSkzpfsg+CxwughInZz5h WcDIuopRtDi1uDg33chIL7UoM7m4OD9PLy+1ZBMjMJEc3PLbagfjweeOhxgFOBiVeHiFDwjH CLEmlhVX5h5ilOBgVhLhDWsFCvGmJFZWpRblxxeV5qQWH2KU5mBREuf9IyQYIySQnliSmp2a WpBaBJNl4uCUamCUcui7/+UZ7zXf14/kmqfHGVRN/BHKfuH/zdQJXEdDavyce0z1Fp2f/3Xl C/3aX7t4vud5Gk5ZUVZtNPHn/b65aSXT9tXe61mwNTZt3rn724LuaJ7buvHFuVCJ0231Jz9X LuB4GrQqX++jhefGzMjPGfeuqTcEtSx+KiN+9JLqk5dbRO0TXoTuVWIpzkg01GIuKk4EAIoH co0gAwAA Archived-At: Subject: [Ace] OSCORE profile status X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2018 15:19:29 -0000 SGkgUm9tYW4sIEFDRSwNCg0KSnVzdCBhIHF1aWNrIHVwZGF0ZSBvbiB0aGUgT1NDT1JFIFByb2Zp bGUsIGFuZCBzb21lIHBvaW50ZXJzLg0KDQpUaGUgZHJhZnQgaGFzIGJlZW4gdXBkYXRlZCBvbiB0 aGUgZ2l0aHViIGFjY29yZGluZyB0byB0aGUgZGVjaXNpb25zIHRha2VuIGF0IElFVEYxMDMuIEEg cmV2aWV3IG9mIHRoaXMgdXBkYXRlIGJ5IEppbSAodGhhbmtzIEppbSEpIGhhcyBicm91Z2h0IG9u IGFkZGl0aW9uYWwgKG1pbm9yKSBjaGFuZ2VzLiBJIGFtIG5vdyBtYWtpbmcgc3VyZSBJIGhhdmUg YW5zd2VyZWQgYWxsIG9mIEppbSdzIGNvbW1lbnRzIGJlZm9yZSBzdWJtaXR0aW5nIHRoZSBuZXh0 IHZlcnNpb24uDQoNCllvdSBjYW4gZm9sbG93IHRoZSB1cGRhdGUgYW5kIHRoZSBkaXNjdXNzaW9u IGhlcmU6IGh0dHBzOi8vZ2l0aHViLmNvbS9hY2Utd2cvYWNlLW9zY29yZS1wcm9maWxlL3B1bGwv MTEgDQoNCkFzIHdlbGwgYXMgdGhlIGxhdGVzdCBlZGl0b3JpYWwgdmVyc2lvbiBoZXJlOiBodHRw czovL2FjZS13Zy5naXRodWIuaW8vYWNlLW9zY29yZS1wcm9maWxlL25vbmNlcy1wcm9wMy9kcmFm dC1pZXRmLWFjZS1vc2NvcmUtcHJvZmlsZS5odG1sIA0KQW5kIGRpZmYgd2l0aCBjdXJyZW50IGRh dGF0cmFja2VyIHZlcnNpb246IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvcmZjZGlmZj91cmwxPWh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaWQvZHJhZnQtaWV0Zi1hY2Utb3Njb3JlLXByb2ZpbGUudHh0 JnVybDI9aHR0cHM6Ly9hY2Utd2cuZ2l0aHViLmlvL2FjZS1vc2NvcmUtcHJvZmlsZS9ub25jZXMt cHJvcDMvZHJhZnQtaWV0Zi1hY2Utb3Njb3JlLXByb2ZpbGUudHh0IA0KDQpJIHdpbGwgYmUgZ29p bmcgb24gdmFjYXRpb24gc29vbiBhbmQgd29uJ3QgcHJvYmFibHkgaGF2ZSB0aW1lIHRvIGNvbmNs dWRlIHRoZSBkaXNjdXNzaW9uIGFuZCBkbyBhbiB1cGxvYWQgYmVmb3JlIHRoZW4uIEkgYW0gcGxh bm5pbmcgdG8gcmVzdW1lIHRoZSB3b3JrIGluIGVhcmx5IEphbnVhcnkuDQoNClRoYW5rcywNCkZy YW5jZXNjYQ0KDQrvu79PbiAyNy8xMS8yMDE4LCAxNTo1MiwgIkFjZSBvbiBiZWhhbGYgb2YgUm9t YW4gRGFueWxpdyIgPGFjZS1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiByZGRAY2VydC5v cmc+IHdyb3RlOg0KDQogICAgSGVsbG8gV0chDQogICAgDQogICAgSXQgZ290IGNhcHR1cmVkIGlu IHRoZSBtZWV0aW5nIG1pbnV0ZXMgWzFdLCBidXQgZm9yIGVhc3kgcmVmZXJlbmNlLCB0aGUgZm9s bG93aW5nIGlzIHRoZSBkcmFmdCB1cGRhdGUgc2NoZWR1bGUgd2UgZGlzY3Vzc2VkIGF0IElFVEYg MTAzOg0KICAgIA0KICAgICoqIGRyYWZ0LWlldGYtYWNlLW9hdXRoLWF1dGh6IC0tIFNlY29uZC1o YWxmIG9mIERlY2VtYmVyIDIwMTgNCiAgICAqKiBkcmFmdC1pZXRmLWFjZS1kdGxzLWF1dGhvcml6 ZSAtLSBEZWNlbWJlciAyMDE4DQogICAgKiogZHJhZnQtaWV0Zi1hY2Utb3Njb3JlLXByb2ZpbGUg LS0gRWFybHkgRGVjZW1iZXIgMjAxOA0KICAgICoqIGRyYWZ0LWlldGYtYWNlLWN3dC1wcm9vZi1v Zi1wb3NzZXNzaW9uIC0tIFdlZWsgb2YgTm92ZW1iZXIgMTIsIDIwMTgNCiAgICAqKiBkcmFmdC1p ZXRmLWFjZS1jb2FwLWVzdCAtLSBFYXJseSBEZWNlbWJlciAyMDE4DQogICAgDQogICAgUmVnYXJk cywNCiAgICBSb21hbiBhbmQgSmltDQogICAgDQogICAgWzFdIGh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvbWVldGluZy8xMDMvbWF0ZXJpYWxzL21pbnV0ZXMtMTAzLWFjZS0wMA0KICAgIA0K ICAgIA0KICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQogICAgQWNlIG1haWxpbmcgbGlzdA0KICAgIEFjZUBpZXRmLm9yZw0KICAgIGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYWNlDQogICAgDQoNCg== From nobody Fri Dec 14 08:18:24 2018 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 A0280128D09 for ; Fri, 14 Dec 2018 08:18:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.359 X-Spam-Level: X-Spam-Status: No, score=-3.359 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hOSftRoTxnEb for ; Fri, 14 Dec 2018 08:18:21 -0800 (PST) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-eopbgr130071.outbound.protection.outlook.com [40.107.13.71]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3E391277BB for ; Fri, 14 Dec 2018 08:18:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vXdTppHkDYV47F8gksBeS9dkQxuafee9hfzNcTzeTLg=; b=ouKzZuEuQih9mSOyG2K7VWFuZrM9VwPBzMSaHCpB73zy9ZeiNoyOnCCYxafDTkjGi74IeZukEpJyRhVxZv9mlSQmJSoAYp6MuDsLzqBYf0DObbLcx+hSIH9IMq2mrNipr3kT6hGqHOg8iDeiyDxfUeV5OQIak533BCCqce4I8Rw= Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB2063.eurprd08.prod.outlook.com (10.173.74.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1425.19; Fri, 14 Dec 2018 16:18:17 +0000 Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::e8de:6a41:cbf4:89d8]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::e8de:6a41:cbf4:89d8%3]) with mapi id 15.20.1425.016; Fri, 14 Dec 2018 16:18:16 +0000 From: Hannes Tschofenig To: Stefanie Gerdes , Ludwig Seitz , Jim Schaad , "ace@ietf.org" Thread-Topic: [Ace] Token (In)Security Thread-Index: AQHUk7/NUFqtp94dNE+cccrNg+vP4aV+aKYA Date: Fri, 14 Dec 2018 16:18:16 +0000 Message-ID: References: <154322421294.8323.8505315870685563404.idtracker@ietfa.amsl.com> <03b601d49191$7d1bb400$77531c00$@augustcellars.com> <945fbebe-659f-ac72-3ab6-8e05447e7c92@ri.se> <1c5b81f3-50ce-be68-bec3-68ce2ff15b43@tzi.de> <4ae4eccd-68bf-18ef-f909-142f8172eca1@ri.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [80.92.115.19] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0801MB2063; 6:LXtMKVl1bEV5Af5OL3DIL41X3vGoLfVtcirMrtPbpkNN2IHklEE1N9hYgsl5fq2yYu3YlZ9Vy9lwxwiUyB2tIZbCCxf/8jPobwlQsXeNsypZczNL45Ohs/dxGmV2+4sdF+ToOXSQAwXMEpF4EhMFDnjczR8EqLF6gXNP9BNNBax4RasWDXvCWMW2uwiu5wbCD8ktsxug7ueMNUCYRNRetdGqkkhJVsKZGy4nj+Usq+cmmDaiLh5WxUcrlHXP7VPGSnbcBCRemTyri/q2ydT/PixZs5FFiZjEVeIj6Be8f0PImATLt0jZtGuaw5etNZzC9A/jxr3lTyQ2w2HmNLwCXlTaYnvi4LkJERx2qUIh/c7w24fEIUGrwNZwU9pOTri3LgtXlzu9Nkb0E4EfFXcvCWXZsqB4LcFWUVlC0PeVGlGiRWT1xqaqHkLAmMuP58kpg8jNg781/8Z0HOZXpAr8jQ==; 5:NFctrUfBC/QESJLycIqdXTqtkALUChtZ+nNY/JgjB4jFaqeLnbKkhij0k2uf23GQXizwDZLwC6kc6e/70IfDZ+TFeylDYtmF7XTdRDehnUunafQh74p8P5JLtAG2Q+inVr/6VwOnERhlbmorQI60CSHS7Y0IzOz4W1VCkd7p/Nc=; 7:9sSBNOXi2lce7Gv89UNYn2bES2egDimBkvg8Zd7hWrLYMJkjNOs9y9e1tlbdkW0GVHOxquqtA7HuxwUbIt60K0xkH3aELcv4ednSbkiAlVlTol+kOOWN+Uigc0ybmguPOPI0OWSzF+6Uc5OKsSN7xw== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 7677fa54-e031-4d16-e501-08d661dfc152 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(4618075)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB2063; x-ms-traffictypediagnostic: VI1PR0801MB2063: x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(3230021)(999002)(6040522)(2401047)(8121501046)(5005006)(3002001)(3231475)(944501520)(52105112)(10201501046)(93006095)(93001095)(6055026)(148016)(149066)(150057)(6041310)(20161123558120)(20161123564045)(20161123560045)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(201708071742011)(7699051)(76991095); SRVR:VI1PR0801MB2063; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0801MB2063; x-forefront-prvs: 08864C38AC x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(346002)(376002)(396003)(39860400002)(366004)(13464003)(189003)(53754006)(199004)(40434004)(2501003)(33656002)(97736004)(5660300001)(966005)(66066001)(6306002)(9686003)(55016002)(71190400001)(53936002)(74316002)(2906002)(6246003)(71200400001)(86362001)(3846002)(6116002)(99286004)(14454004)(72206003)(25786009)(478600001)(305945005)(110136005)(6436002)(256004)(5024004)(14444005)(8936002)(105586002)(106356001)(229853002)(486006)(15650500001)(11346002)(316002)(81166006)(81156014)(8676002)(561944003)(68736007)(93886005)(26005)(102836004)(6506007)(7696005)(446003)(476003)(76176011)(7736002)(53546011)(186003); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB2063; H:VI1PR0801MB2112.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: GLMSEUfVOObdKREfOMzvfuKP/xY7j1o7tWSCfgoqvn8x7jQUBxjHyvwQVYezCoFxZmkk3dYWk6MmNnASd4k5tY6CvfIjqfP9uZI2aqGekbaAyxU1RggbI+etOoYXHTY6rvztdnWorpxo2+wtaMw6aAHPdestyk57QhNkqwlCG/hPgIAD65TmWeuDqbyuKtHOA2pRTw9IFe4gGR8CFE8nD32wrzlFEQ6g3VfmBLwaE8eNE8o3Mi+NRFIV7zRi2E1utaC6LD47wAvM84XwKj+IHz1iBhZCLPYMJSj42/DDiUijk9cfwuUzGeMg41h0NCUH spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: 7677fa54-e031-4d16-e501-08d661dfc152 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Dec 2018 16:18:16.6196 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB2063 Archived-At: Subject: Re: [Ace] Token (In)Security X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2018 16:18:24 -0000 Hi Steffi, I anticipate that the use of tokens with IoT devices works similar to OAuth= deployments today. As such, if you distribute self-contained tokens then y= ou sign or mac them. We have registered the necessary claims already, which includes the expiry.= As such, I expect it to be used as well. If we forgot to mention explicitly that we follow the best current practice= s in OAuth then we should add that reference. I will check the text... Ciao Hannes -----Original Message----- From: Ace On Behalf Of Stefanie Gerdes Sent: Freitag, 14. Dezember 2018 16:15 To: Ludwig Seitz ; Jim Schaad ;= ace@ietf.org Subject: [Ace] Token (In)Security Hi all, as I understand the current proposal of the ACE framework, an attacker can = send an access token to the RS that only contains a scope and is not signed= or otherwise protected. Section 5.8.1.1 (titled verifying an access token)= does not state that RS must check the authenticity of the token, therefore= RS can accept it. Since the token does not contain an exp field, it is inf= initely valid. The attacker thus gains infinite unconditional access. Is th= is really what we want from a security framework? I would expect section 5.8.1.1 to provide information if and when RS must c= heck that the token stems from an authorized AS to prevent this scenario. Viele Gr=FC=DFe Steffi _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. From nobody Sat Dec 15 06:58:27 2018 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 1A546123FFD for ; Sat, 15 Dec 2018 06:58:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.36 X-Spam-Level: X-Spam-Status: No, score=-3.36 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YNhBT22LuoyU for ; Sat, 15 Dec 2018 06:58:23 -0800 (PST) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10078.outbound.protection.outlook.com [40.107.1.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22754124408 for ; Sat, 15 Dec 2018 06:58:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zGcjeD6f2skLWPUHNo7GOSzvODLgHJyvvDzkwV1M+X8=; b=hdwaCYkBVrtyiuHacSszjX+TryTro76ZVKSSW6kiuPEgAEBquJ450gaWakPyoI+XjAi+0rqFnqO3OGx8eZsjMiIbc7cIbHy9c7+y/SquPvti95YyYc9UQ70+i2HohexcJhwftxN89me18pIUMI+O5z/57xQU6++MQH+0CLPQ7kc= Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB2718.eurprd08.prod.outlook.com (10.166.198.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1425.20; Sat, 15 Dec 2018 14:58:19 +0000 Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::e8de:6a41:cbf4:89d8]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::e8de:6a41:cbf4:89d8%3]) with mapi id 15.20.1425.021; Sat, 15 Dec 2018 14:58:18 +0000 From: Hannes Tschofenig To: Hannes Tschofenig , Stefanie Gerdes , Ludwig Seitz , Jim Schaad , "ace@ietf.org" Thread-Topic: [Ace] Token (In)Security Thread-Index: AQHUk7/NUFqtp94dNE+cccrNg+vP4aV+aKYAgAF81rA= Date: Sat, 15 Dec 2018 14:58:18 +0000 Message-ID: References: <154322421294.8323.8505315870685563404.idtracker@ietfa.amsl.com> <03b601d49191$7d1bb400$77531c00$@augustcellars.com> <945fbebe-659f-ac72-3ab6-8e05447e7c92@ri.se> <1c5b81f3-50ce-be68-bec3-68ce2ff15b43@tzi.de> <4ae4eccd-68bf-18ef-f909-142f8172eca1@ri.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [80.92.114.221] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0801MB2718; 6:Nlyv0KP+Xvl/95nOEAUqaVMPD5CNP+RSquyILmcBKvZjyqdQyuykfJ7CZ4gjZDAm8ejAK11AZFXP2tPPLahO+Mrn5RnoLuScyXkRSsUM3At51PTuFKF7oVSgd5BZMQ8pBRO/JBAgEGBNXdVvODuhTvmdhkHXnapuf2wUnOiPBnk0tnhRyPiH/3F+TqW8EavML7hpWphb44lhVj25IMDHn1V/CnhWQ6yt+uBVvKyCn0XhWmqQD1E9W87oruCYPjHHJP38A3aBIv9bcIrSY2fweNrHbwalo7yvfmiJ4KppEMfS42PmFkBn+1leEhU7xhLPrrE7lO3ikkikzGsusGJsMAAS/jLF6ZHM3mNeZhuS3ZvfGffjB8OClTpvXyyAwAXimWEU6s7rwhRf4aRqtIffqNDe4pPc/g095TBuF/b1yftk4qgvQzkCVyYOIxjbxMZFg7q3VyZQ+LYxkPltt1P5Vw==; 5:LaQqnx+HDT5mG1mB1PG0lN2Nr1o3VzndJAmV17lWWJqMIzMlLwABfhuvd54f7R5X8mNSvlB8EJun5IvOevsnix7OG4iADLD1HhnmrM8sQijO44213rRCVo18BFOEo11nmHDc8vihC98iLvgjb5qvhBn/Eb/xIaMkhotfa9io1yY=; 7:QrlyZTu2g3PWXaGvHpwn47KTBXfLYEgOi7QPAhnUGrbmgcmjWJookJwMwJ2iu8PDV68Wa95XOorDceB6poDtEVdyw+FCx+kmOTZxSnZCFM+nkIi3ZUo6ldAMdZV2NYTCh26NJAItHZTvAz6KQvfrsQ== x-ms-exchange-antispam-srfa-diagnostics: SOS;SOR; x-ms-office365-filtering-correlation-id: 385ee452-3098-4d43-876a-08d6629dbfdc x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600074)(711020)(4618075)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB2718; x-ms-traffictypediagnostic: VI1PR0801MB2718: x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(3230021)(999002)(6040522)(2401047)(8121501046)(5005006)(10201501046)(3002001)(3231475)(944501520)(52105112)(93006095)(93001095)(6055026)(148016)(149066)(150057)(6041310)(20161123560045)(20161123564045)(20161123558120)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(201708071742011)(7699051)(76991095); SRVR:VI1PR0801MB2718; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0801MB2718; x-forefront-prvs: 088751B4D4 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(346002)(376002)(39860400002)(136003)(366004)(40434004)(53754006)(189003)(199004)(13464003)(2906002)(14454004)(25786009)(76176011)(74316002)(229853002)(3846002)(55016002)(6116002)(7696005)(7736002)(305945005)(26005)(105586002)(72206003)(15650500001)(102836004)(68736007)(106356001)(8676002)(81166006)(478600001)(6436002)(5660300001)(110136005)(53546011)(97736004)(6506007)(966005)(8936002)(66066001)(186003)(316002)(86362001)(81156014)(71190400001)(71200400001)(446003)(53936002)(476003)(99286004)(11346002)(93886005)(486006)(6306002)(2501003)(14444005)(5024004)(6246003)(9686003)(33656002)(561944003)(256004); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB2718; H:VI1PR0801MB2112.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: wP28G0fOY54dCnEwGxJX5rv1ppgvU8keGdK6Rr5x26DNdEPynuUrj2U5NBWyYELXc2w6VgO5jOXGqdS+s4tEpOtsytioiBIN3qrKNeYtwvkGiRAXLohHH0bF0R4AWzo33hrC1jir7mR8cTfMMu/eJoCvIPB5pXtoRkOE1UUyg05z3o1bsUGNQ57qA6YlV0wYIXvalyr/Q5pZYAa0GPbLVN6FfGQZI33/iY3Tlw76097p0He6kvFDuEeyFhtj7uNYYBWdO6FwqsuGU1XqaUS9N/8Dw+jxMXjgvN3Lryj9zawDDbbWxzr/m6FWTSSPQ08E spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: 385ee452-3098-4d43-876a-08d6629dbfdc X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Dec 2018 14:58:18.6698 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB2718 Archived-At: Subject: Re: [Ace] Token (In)Security X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Dec 2018 14:58:26 -0000 Hi Steffi I checked the text and the text is indeed confusing. I have made an attempt to update it to address your comment. Here is the pu= ll request: https://github.com/ace-wg/ace-oauth/pull/168 Let me know if you think I captured everything properly. Ciao Hannes -----Original Message----- From: Ace On Behalf Of Hannes Tschofenig Sent: Freitag, 14. Dezember 2018 17:18 To: Stefanie Gerdes ; Ludwig Seitz ; Jim= Schaad ; ace@ietf.org Subject: Re: [Ace] Token (In)Security Hi Steffi, I anticipate that the use of tokens with IoT devices works similar to OAuth= deployments today. As such, if you distribute self-contained tokens then y= ou sign or mac them. We have registered the necessary claims already, which includes the expiry.= As such, I expect it to be used as well. If we forgot to mention explicitly that we follow the best current practice= s in OAuth then we should add that reference. I will check the text... Ciao Hannes -----Original Message----- From: Ace On Behalf Of Stefanie Gerdes Sent: Freitag, 14. Dezember 2018 16:15 To: Ludwig Seitz ; Jim Schaad ;= ace@ietf.org Subject: [Ace] Token (In)Security Hi all, as I understand the current proposal of the ACE framework, an attacker can = send an access token to the RS that only contains a scope and is not signed= or otherwise protected. Section 5.8.1.1 (titled verifying an access token)= does not state that RS must check the authenticity of the token, therefore= RS can accept it. Since the token does not contain an exp field, it is inf= initely valid. The attacker thus gains infinite unconditional access. Is th= is really what we want from a security framework? I would expect section 5.8.1.1 to provide information if and when RS must c= heck that the token stems from an authorized AS to prevent this scenario. Viele Gr=FC=DFe Steffi _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. From nobody Sat Dec 15 07:04:22 2018 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 85FCA124C04 for ; Sat, 15 Dec 2018 07:04:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.36 X-Spam-Level: X-Spam-Status: No, score=-3.36 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cvQwvoPIx23k for ; Sat, 15 Dec 2018 07:04:18 -0800 (PST) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60075.outbound.protection.outlook.com [40.107.6.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6DF3123FFD for ; Sat, 15 Dec 2018 07:04:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=LOzCuuIjz00WieiBJlSVMGVOsYME6hHlWsrKo0fAMI0=; b=N6o88DV9BnLVy2i4EyuxkYFi2tcsLSkgOaLXfHjj3jXwMr7AQaq+6qBQ2ER1soo76jnWT4OXZPq6xBrPspRo+EitAL/3wAEpuvaMt7mXdyOynYrOLD3bAQFtxV/fTlypFQfo+sXlstO73pW/PollNHRo7kA23dPk+7JiQlhdr/w= Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB2718.eurprd08.prod.outlook.com (10.166.198.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1425.20; Sat, 15 Dec 2018 15:04:14 +0000 Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::e8de:6a41:cbf4:89d8]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::e8de:6a41:cbf4:89d8%3]) with mapi id 15.20.1425.021; Sat, 15 Dec 2018 15:04:14 +0000 From: Hannes Tschofenig To: Stefanie Gerdes , Ludwig Seitz , Jim Schaad , "ace@ietf.org" Thread-Topic: [Ace] Security of the Communication Between C and RS (was: Re: Fwd: New Version Notification for draft-ietf-ace-oauth-authz-17.txt and draft-ietf-ace-oauth-params-01.txt) Thread-Index: AQHUk7/954+w7Vk94E6zFYcm2/BvZKV/5iVA Date: Sat, 15 Dec 2018 15:04:14 +0000 Message-ID: References: <154322421294.8323.8505315870685563404.idtracker@ietfa.amsl.com> <03b601d49191$7d1bb400$77531c00$@augustcellars.com> <945fbebe-659f-ac72-3ab6-8e05447e7c92@ri.se> <1c5b81f3-50ce-be68-bec3-68ce2ff15b43@tzi.de> <4ae4eccd-68bf-18ef-f909-142f8172eca1@ri.se> <81ba3ab4-a9ce-a6fd-fbe6-c36a6fbbd9a5@tzi.de> In-Reply-To: <81ba3ab4-a9ce-a6fd-fbe6-c36a6fbbd9a5@tzi.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [80.92.114.221] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0801MB2718; 6:IuWaPojaY11PBWVnMqwD9y/Y3+nRwUl5HtrdBLS5RoPSOt9/dWKIcBC5HpY8w0sxnFuJytbsI79RySZyGAPVq6C9oswyz+LChpSLK72d2MVf6p7P7V60VSQ+SBErKy+REggY0WCmn2he5piUqErqH3uVY93GvycF0gGWbtfJZSubsLjJXZGFofOVbjsaR3BWvUFClkQyTTN+Db/iIhCUt+BYhk5xpVSRi2RsVQBTmlODKmr0tvAe2pmcAGzZvV76B5+NFRXSqHyeXVwPNybFqohj0EPe2uJkdq31GfFDWQ9P/V6P/dZctQBm1Wp7LFGTdUvoBKEuQDWY3L97Twt49hDbgLayi194+6NnX7l3htMawSlQJPgfBewVMh+pZOD9bkrOjT+0hOxgRObqp4I/2sU+o8M9xrLS83Fzw+2/+QKymeIcaNCt1TQTjxdlyRrrVUSG3shnLs274oh/KKwbaQ==; 5:T4qma4r/EnkJupNCgQF1Yh5/7XZ0pJm2sbpQto5jdMW1phyiJni/EMi9sHIEoC22MzonnC3n+F6rwTJWKwxRQ+qzokd20E2ScjLS2mS+FZKlWJnAj7pEBItdJLdIZiwpnauA3JF2F1RhGeC2qtuIEuKhUrPfPLcuhok+STGJLpc=; 7:fxmqYhHtrKPD2dQHANvqoe0taDiPcbWb7kpcNlEgHrUaXGAoDqFXjmGhS3ZySqH3nIpw52AIa0mvRgd/JFGj5/0sEtKQ9GS244kaML6QrB4CNqxZoz5cqXw6ue3uhXmPGFQh8TmlEkkg3SZnrGeNsA== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 5381a1aa-a889-4c85-9d19-08d6629e93e1 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600074)(711020)(4618075)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB2718; x-ms-traffictypediagnostic: VI1PR0801MB2718: x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(3230021)(999002)(6040522)(2401047)(8121501046)(5005006)(10201501046)(3002001)(3231475)(944501520)(52105112)(93006095)(93001095)(6055026)(148016)(149066)(150057)(6041310)(20161123560045)(20161123564045)(20161123558120)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(201708071742011)(7699051)(76991095); SRVR:VI1PR0801MB2718; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0801MB2718; x-forefront-prvs: 088751B4D4 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(366004)(39860400002)(376002)(346002)(396003)(40434004)(189003)(199004)(51444003)(316002)(86362001)(71200400001)(81156014)(71190400001)(6506007)(966005)(97736004)(110136005)(186003)(66066001)(8936002)(6246003)(9686003)(33656002)(256004)(99286004)(446003)(53936002)(476003)(14444005)(2501003)(5024004)(11346002)(93886005)(486006)(6306002)(55016002)(3846002)(6116002)(7696005)(7736002)(305945005)(2906002)(14454004)(74316002)(229853002)(25786009)(76176011)(478600001)(8676002)(81166006)(106356001)(5660300001)(6436002)(26005)(105586002)(15650500001)(68736007)(102836004)(72206003); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB2718; H:VI1PR0801MB2112.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: yqsAUXngZgW9Id4iRqnnIUlCpGD7N6MtiYdQpCEkbmuenUB8wdtl5c/sDL/QWH5grobAVaitwp+fdEcm15cZyfdkpHI/YBeincm28zjZva+eCUx5i1Z1oTRV6G2pM0dKz5BcuzfrXIpzxsqCDKu1EhoskcqbQqjA0MXk9uJG533XTuHu+WneSYP6W7TaaRl4M1Bjk3d8LlfvjgZ7GMozXieUEbrfU0+59L0js+V2Kvdk7SDX2QfecO3q/ZOMPC2lZ5Kf42INVzrXiUR6r0tnDOyYMe5jNC1HxqL2Jtd6yX0o1Fq/dAtsWlwEq71Xl/sU spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: 5381a1aa-a889-4c85-9d19-08d6629e93e1 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Dec 2018 15:04:14.3332 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB2718 Archived-At: Subject: Re: [Ace] Security of the Communication Between C and RS (was: Re: Fwd: New Version Notification for draft-ietf-ace-oauth-authz-17.txt and draft-ietf-ace-oauth-params-01.txt) X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Dec 2018 15:04:21 -0000 Hi Steffi, ~snip~ > I really think you should point out that symmetric keying material that t= he AS provides to the client is valid as long as the token. I think that's a useful recommendation. I do, however, believe that we are = not making the same assumption for an asymmetric key bound to the token. > I also think that the client must be able to assume that RS' RPK that C r= eceives from AS is also valid as long as the token, unless C has additional= information. I would think that it is rather unlikely that the RS will change its public= /private key pair so quickly. Right? > The access information optionally can contain an expires_in field. It wou= ld help to prevent security breaches under the following conditions: 1. the keying material is valid as long as the ticket, 2. the expires_in fi= eld is present in the access information that AS sends to C, 3. the client = checks the expires_in field when it gets the access information from the AS= , and 4. the client checks if the keying material is still valid each time = before it sends a request to RS. These checks make sense to me. > Without these steps, the confidentiality of the request data that C sends= to RS may be breached, and C may communicate with the wrong RS using outda= ted keying material. Not sure how you came to this conclusion. Why is the request sent by the C = to the RS revealed to an attacker when the token expires? Ciao Hannes Viele Gr=FC=DFe Steffi _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. From nobody Tue Dec 18 00:21:28 2018 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 336AB127598 for ; Tue, 18 Dec 2018 00:21:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.36 X-Spam-Level: X-Spam-Status: No, score=-3.36 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=risecloud.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6_Z46aROHbWg for ; Tue, 18 Dec 2018 00:21:23 -0800 (PST) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-he1eur02on060f.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe05::60f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2012C128CF2 for ; Tue, 18 Dec 2018 00:21:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=RISEcloud.onmicrosoft.com; s=selector1-ri-se; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=nyRpebReOTdUKaEUKV/EYNdt91g4YzO5YchneaQbxxI=; b=De6VYqWjDs2MGYQgD1edVpe+zCkhE4aHN9OVXNIbesDje8VmkOEyvLHK/bfq2iDAtSY0et1aAOXEpXrbOnC8gXDE6ESanaI9ATyYFJT6b9WMoJd5hgX+q0FKiy2uffEFi07v7yQNpSbNcMxA2ikiLmnb1CADIwcVTNGAAk4OhrE= Received: from DB6P18901CA0006.EURP189.PROD.OUTLOOK.COM (2603:10a6:4:16::16) by AM5P18901MB0099.EURP189.PROD.OUTLOOK.COM (2603:10a6:203:78::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1425.19; Tue, 18 Dec 2018 08:21:20 +0000 Received: from HE1EUR02FT014.eop-EUR02.prod.protection.outlook.com (2a01:111:f400:7e05::202) by DB6P18901CA0006.outlook.office365.com (2603:10a6:4:16::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1446.17 via Frontend Transport; Tue, 18 Dec 2018 08:21:20 +0000 Authentication-Results: spf=pass (sender IP is 194.218.146.197) smtp.mailfrom=ri.se; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=ri.se; Received-SPF: Pass (protection.outlook.com: domain of ri.se designates 194.218.146.197 as permitted sender) receiver=protection.outlook.com; client-ip=194.218.146.197; helo=mail.ri.se; Received: from mail.ri.se (194.218.146.197) by HE1EUR02FT014.mail.protection.outlook.com (10.152.10.118) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.20.1446.11 via Frontend Transport; Tue, 18 Dec 2018 08:21:19 +0000 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_128_CBC_SHA256_P256) id 15.1.1531.3; Tue, 18 Dec 2018 09:21:19 +0100 To: Hannes Tschofenig , Stefanie Gerdes , Jim Schaad , "ace@ietf.org" References: <154322421294.8323.8505315870685563404.idtracker@ietfa.amsl.com> <03b601d49191$7d1bb400$77531c00$@augustcellars.com> <945fbebe-659f-ac72-3ab6-8e05447e7c92@ri.se> <1c5b81f3-50ce-be68-bec3-68ce2ff15b43@tzi.de> <4ae4eccd-68bf-18ef-f909-142f8172eca1@ri.se> From: Ludwig Seitz Message-ID: <5fdf1a4f-4e82-657a-d384-ba34d1a26b7a@ri.se> Date: Tue, 18 Dec 2018 09:21:19 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.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-2.sp.se (10.100.0.162) To sp-mail-2.sp.se (10.100.0.162) X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:194.218.146.197; IPV:NLI; CTRY:SE; EFV:NLI; SFV:NSPM; SFS:(10009020)(396003)(346002)(39860400002)(376002)(136003)(2980300002)(199004)(189003)(508600001)(106002)(36756003)(446003)(110136005)(86362001)(53936002)(11346002)(58126008)(16576012)(31696002)(2486003)(2616005)(486006)(316002)(8936002)(65826007)(6246003)(2501003)(69596002)(33896004)(44832011)(5660300001)(76176011)(966005)(8676002)(81156014)(81166006)(15650500001)(386003)(53546011)(106466001)(50466002)(93886005)(67846002)(97736004)(47776003)(26005)(14444005)(77096007)(31686004)(229853002)(65956001)(65806001)(356004)(230700001)(74482002)(7736002)(22746007)(22756006)(104016004)(64126003)(40036005)(476003)(126002)(68736007)(6306002)(23676004)(2906002)(6116002)(117156002)(3846002)(305945005)(336012)(16526019)(186003); DIR:OUT; SFP:1101; SCL:1; SRVR:AM5P18901MB0099; H:mail.ri.se; FPR:; SPF:Pass; LANG:en; PTR:InfoDomainNonexistent; A:1; MX:1; X-Microsoft-Exchange-Diagnostics: 1; HE1EUR02FT014; 1:RbMmJGVLuz0Doe8jKpOeDTkgr3CsxOlD9SmrGoh3sCd9P7+zJoF8BucpJL3PyBVbLOF8UGZNcUOEDAkGKkcCHSlFTf+A2F5y8BiVnbtboTiEC3NUvtqyVwtdv3QVAGRC X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 0205ad33-1384-41d6-15c8-08d664c1ca09 X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(7021145)(8989299)(5600074)(711020)(4608076)(4534185)(7022145)(4603075)(4627221)(201702281549075)(8990200)(7048125)(7024125)(7027125)(7023125)(2017052603328)(7153060)(7193020); SRVR:AM5P18901MB0099; X-Microsoft-Exchange-Diagnostics: 1; AM5P18901MB0099; 3:8aoLikQGkw45/rXs8hSga1OFLo7w7+3VQo8BnUfUoy9qvRwsJzMIjVGrRaacsKzGmfKX4dpmZw7d46xY9LXWhKPEoVHlCn90Sa5BkS6/HGyH+ysARXbe0C9QUM5uPqCYOZbKUajzKl1BPmezNZFcPp1McLiy+CU62yaWKZuksH+socAmwXmQB/kmCSd3xQcfLYmxcp/gFsP35RiiinzoD1KsNz9/f7tzV+Sl4k8BdFh7iV9qol+LarSpVxniEslVxKa6u6Q/cUCQ7pM2xEcSguJQAtCUrsIjMtt7MqUIb5B+SjFnyTO8wuTTekKchyOVb7mL8trWrJ2bD6iiCJMSvDf6DHHff5xE+ECkkGNjbAI=; 25:pZZCalpvk3LkNbhwcByRv26SNmztsMK8TqCetvYTRRijA1uEEuRRAnoDiDAygvOJPgVhVJZUJocxZng2JhADZo7N6thVZGwKqxB+eMJpQWby9pWFixD08dMbCz1ExIMTII4oVc9mDyHP0AbA+fELUxD/9hLNOrem5IH8E7O/lFQ24t7MryeeQ9ER2NGP6MuvWb1mRAphQo4WXzjpAv27/6oiH7sB0GDcP8RGnpTg7YZ4MsyFyZR8aVCPzeqIGNTsMaBC/nWQNZ9DMobhnuhXfptvld19+8dj/CIPHpaI+0acQ5cKDhfGUf1Yh3x8kG+umyAdn+iDLhaQY+VsZvgEfw== X-MS-TrafficTypeDiagnostic: AM5P18901MB0099: X-Microsoft-Exchange-Diagnostics: 1; AM5P18901MB0099; 31:5GkBHT8kAQ2W1aYoAatmE6DO0IyV5r02tcd7ZZ4mlmJ2wydaxi5F5C8KYb3qW25gowENxslP/SqdGb8x6p/7/iSdz/QS8tGMp230n2+ftey6cbW/pIogsrguVIsZuydjEHZGTNiU7pe4YZ+Zmuiq69FrAdR+6FmKNOUiLrm3+9TmRF35bTsyYQgxwuZRuoWJsr/GJpwheSJm9GYl6NH62ObIRgFiUTdXe3S550APNyc=; 20:cicZSYzMySFrm0wpnMQ5KV96MDFOUbq3Fi8VrgM1KdXay0mZ37VV4VJARoe2nlW5nOyMAdXV5SBNjy6FOWPWz/tthW86bVkqr43Bs00FKRhaV2N7f1c/WOylES28gfqdmQZhxJKrk+hsDQTi+rxsJ14PIF20OLfuL4cT5jYzkt9r4he9nCRofKgJ5a0d+6BEZYZcnodKiNdYkJxQUiTQfu41jpwSv9ISs4LWDdEcubi4LqWN/uufMXpI0pKHJQLI; 4:AymLcZFN8JcbA4u9Cz9/cR4VKuJFhyYDgPZ5oJPQCMBALlEQy+K73z4VK2qAMkFcrM5Baaaioed4znTWX5UyqYLcRNEKdkRJGU7a3acrXNi+Uq+arLLBZ0E3Q+oD+lh1ZRShf5yPcZ2p+5WQmx0dGd+qYmuO02pfQ4kqaPm+rdJYlx9uqCTPuD14uhbV8IN+z5CHfcxo8Iwl1NEjTRENN/QFbGATD1CVD0oc5CgrKbwzX1P54RvSC5+uYyaoZqdnXzALQL2uRHapXJPWlDN/iA== X-Microsoft-Antispam-PRVS: X-MS-Exchange-SenderADCheck: 1 X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(3230021)(999002)(6040522)(2401047)(5005006)(8121501046)(3231475)(944501520)(52105112)(93006095)(93004095)(3002001)(10201501046)(148016)(149066)(150057)(6041310)(20161123558120)(2016111802025)(20161123562045)(20161123560045)(20161123564045)(6043046)(201708071742011)(7699051)(76991095); SRVR:AM5P18901MB0099; BCL:0; PCL:0; RULEID:; SRVR:AM5P18901MB0099; X-Forefront-PRVS: 08902E536D X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtBTTVQMTg5MDFNQjAwOTk7MjM6V3Z0UU9SUFoxUDVJM2lXTUtxbmJjQzA4?= =?utf-8?B?bS9rZDVsUmRQeDdoNG82Si9CSlBNT2lUcE9wY0xSNlQvemMyVXlXQTdndXMr?= =?utf-8?B?bjYrTlU3dlhsa29BakVCaGptZE96NEJXak1UTXdmYVora2NTOTZIUElrMmdD?= =?utf-8?B?bEFUS1F4RVdtMGNLano4c3JtT1FFRE5iVE4xWDJMQnlocko0eDZlWnRoVnZK?= =?utf-8?B?eExYdzBuMnYzbkdqdFI5aGF0K1hOMUxiYlVKeG5QT3kyc2tBVDdHTjRDVmFC?= =?utf-8?B?OHNSOTJZWURCWnowbEZicUVJaVdlcmhWb0d1RTBIWkRDSVUzVEZPb3hQMXRz?= =?utf-8?B?Zjgwall6NzIwb1kvOU1nd0p6YnBCWnBnSlhialUrUGNtRHVSODBQUU1jMG9s?= =?utf-8?B?dWp4UGFjdEh2STZMWE5Fb1NxS0V1ck9TNUNITFUrNHRlc3VrTEQ0Ulo4clEr?= =?utf-8?B?a0JyUW1OYW5QZzRFWHppaVBMWnRmT1RBTW5vazVvNkFWUHM3dk9UQjdxaVA2?= =?utf-8?B?WmUrWFp0Zm1yOGtLSzR0YWIyUEFmMkUvTEZxYmU0QmR6YWpXQXAyUmF0N29h?= =?utf-8?B?cHBuZTRCWmFHYWlJSkMxd1dvT05OVmNPL0ZxcU9qV2o5UEtQdXBGWkxMN3JB?= =?utf-8?B?UUJpd0x0Y2lnRGxoRFpseGZLR3d2WHhFUGNBTkpGS2YvN2ZWeG1MVnhZSVZ2?= =?utf-8?B?S1lmU21STUV4Y0NDY3lrVUhoUGo1MU5yWGdrQWlQalhLNGxjNjhyWVFvRXJO?= =?utf-8?B?Y1NzSGlHSXlEQnIvNHY3Y2ZJb0wyN2dmTkprZXFUSzZlaHowOGthN2tPVVha?= =?utf-8?B?WXJoc25JQzBHQ0tlODFUYThheDFnL2djcTJIbnp0N2VrQWdMSWROc1JuVmxh?= =?utf-8?B?a2dkL3FjMUxYQ3lubEhmQTF6S3FZRk5Kak51VFZqYjlIVkxYZEs0R2xXUDRl?= =?utf-8?B?MWNzOVovMHgzWUNYWldSZWFBeTd2Sm1LZGNRNEdHMWdDTDBHdThJMUFRMlY5?= =?utf-8?B?eGE5ZWhaTkh3WCtjcFh0M2ozQVhuQzNmZkZIaGdCeERqZG15ZDFFRnhySmRn?= =?utf-8?B?NUpNbnRHT2dJWkYxdUduNVRMN2FqVmJhQ05jcmlHOUJPa2NCRUJUTEMwTzFl?= =?utf-8?B?clFxNTZEZDNSSkV0NlVLU2lJSW92Y0xkUnhkc3RZNkpQOGN0NlFXRWdUSk4w?= =?utf-8?B?OGhITExOejA3eHp2eU05bnh5U0NvN1h4TWl0dzVnb0Y1UWRCYkJPbHlReEwr?= =?utf-8?B?TUJPYXBRVmZ6VURhRktsY1VOU255TExHOTdZZzVRQzdFYjJsNlRCandEcm1V?= =?utf-8?B?dmRLVy9MMTdSL290L21KeS9rTXAyUDVjYUpqMW1BT09FbTVYYmlESGd5RTBq?= =?utf-8?B?NXh2eW1rbk1pVUNBcThUa3g5Vm1naFA3NzFjRWZGc2dHUzBtck9zbVRUSkp1?= =?utf-8?B?ckZCbzFxQzd1TlZVN2VjUTI2NC93RzkvUm9hWWxDL3J6d2NIbzgzWjhITVAy?= =?utf-8?B?SHdMTjVJTnBoeTZtaGpJWGF3SUhDMWlWVENramQwd2xxcnNoODV6MThTQWEv?= =?utf-8?B?dmgvZmRkbmJ4SjY3VmkzQ1UxQWJTZXNERWhOWkFibi9xM3R0Mko0MVptL1Fx?= =?utf-8?B?aW5qeDRlazlWYVVnVXJBektWMHkyYWRNRHN1ckE2ZDdXaDY5YTQwUnFuMHFj?= =?utf-8?B?bTlCZzl6TFRMK3pqcm9pRUE4Uzk0RW1Kbm9TaE1MVGdnbnVQdHp4bDdSMTA4?= =?utf-8?B?MHloRHp2aXIydm9lSFh0MHRyNEJzL0FrY0FxYnVYTkd2ZmZDdlIyT1hDckVH?= =?utf-8?B?STZxOXFZMkRaSUw4M0tmVzFUUDR3QldVaVFRcXZtZnREbFVUZjJMYnpzd01E?= =?utf-8?B?NWpqZCs5Y0RIUEFHVUMyc0wvcjlWbW9DRi9YeExoUFNtMXBlSWhoUktnaDNt?= =?utf-8?B?a0RENWRxam1TblNqQlByT0NIdmFueU8rZjY4SllwWXFzcG9BMGVtZVoxL05h?= =?utf-8?B?YW9JZ01LOHVhTTZOSGdqT3h6YzlHUHhxL01XaXFka0hQOHZ3cVdBYTdMa0xF?= =?utf-8?B?WHpGRklCcW5tbzhBaUJTT25JQ2RrZ3JpU0JtU3ZHUWg4Tnh0NUszMTBVUGNI?= =?utf-8?B?NVBvK2s1RGxVOHA3em1yTEdFc2I5U0N2endDRnA4ODVzSUxmZHEwTnhaZnhX?= =?utf-8?B?RXc0TloxeDFOclRBZWdaQ3daSnNRcUE9PQ==?= X-Microsoft-Antispam-Message-Info: rke8gRf0O32cJ0+eXcWXO6A7W2BIIxk1GT/DiAU6xD6xmQX5weF8/cXCmj+i2ky2EjgqiN3kU7meY1XUTmbGUvr1d9pmHaanQ4NqxidPVi6MrbwP4kFqET7b/zpr3uNuedvW24hNyKxGlRAwjP8heWrZapbX2KDfczoCrKG817Bs2wnzMb1p1XvRnDLme1hK5hkWcbWGMkPGQCAZwxGPkraNKTPvUeYC76YZTidIigMZUhL4s3dUrmxor6ZXjzx60H5WbwsPCzS0o47aXZY+rO6sFXkRMdSh66bbeq2yJnJkY6objElnSaqw4xXJeBM0 X-Microsoft-Exchange-Diagnostics: 1; AM5P18901MB0099; 6:oo47mWEqxQ2s31CxyeXVJtinnT1xKpuGLjrxh788wW8HDTcf6YdlHKHwkBPCaPREAuEiDFdXp6ep+lMYPWOqsc5aNnCvtXITu9aGEsqMFomCgUExF1bdyjC4KWH2865tffDMnBSD57MjWuRJjbfYJNfsS1NvLekyBCkMo7P7tPEnMVMjwaNY2ITyAoznRI5nwaWNrgmoVwi6FttHUuIe4Pfrlk0fwLjUhFWMz23+PDJcNswsWpOlkwa9HI81U+fgCdEKwZPs4GgoKH9kqVMwxe1Zcf3fVN261ePyBH8E9JE8mnWtFfjzdS86b9wF1pRPn15BDYmBi/WSNpvRwgHjgNxK06yxebo9FVKLuWIlR4D7JY0U7omuPmpxhfTRIt/PiARndGDsYEwHmBeTPEJzdaFoM5BAN8ID/R/504jBiLpTJlXNFFASMniongfQ5FIriepXobjNpgV8XsfVNrQx+g==; 5:YgWl2frGxnLYJa80CIWOuVlVABbXCfFChMdxHJVE4DSHgPseNyhNkNjiQi4wkPZUIhCvwis0b1iwj6mwkatvbRIDZqs/KCEN6YcE4E/O2A4YpM10YuApOGZxW/s5mzkZjR/T4zfMbpxKZtcwAf7lzvVCr9mhKgzrD9b9QYlRbPU=; 7:jpFibfKXC3CsB8+TaSnVepV8GwtM1CDxaAOVVYNiBiijOXN63o5JGgtXrhL1B6mFQw0x1BsjxGbmktQKF0MgvGRuSLje2Usuj6SNVFGQ+1+dxJZG47saIEnxwBHdhkCvU9Znmn3+dslmyRFL8K3+Sg== SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Dec 2018 08:21:19.8531 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 0205ad33-1384-41d6-15c8-08d664c1ca09 X-MS-Exchange-CrossTenant-Id: 5a9809cf-0bcb-413a-838a-09ecc40cc9e8 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=5a9809cf-0bcb-413a-838a-09ecc40cc9e8; Ip=[194.218.146.197]; Helo=[mail.ri.se] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5P18901MB0099 Archived-At: Subject: Re: [Ace] Token (In)Security X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2018 08:21:27 -0000 On 15/12/2018 15:58, Hannes Tschofenig wrote: > Hi Steffi > > I checked the text and the text is indeed confusing. > > I have made an attempt to update it to address your comment. Here is the pull request: > https://github.com/ace-wg/ace-oauth/pull/168 > > Let me know if you think I captured everything properly. > > Ciao > Hannes > I agree that your text improves the "verification" section. I'm holding off with merging in order to wait for Steffi's confirmation that it addresses her comments. /Ludwig -- Ludwig Seitz, PhD Security Lab, RISE Phone +46(0)70-349 92 51 From nobody Tue Dec 18 00:27:36 2018 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 B5EF1128CF2 for ; Tue, 18 Dec 2018 00:27:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.36 X-Spam-Level: X-Spam-Status: No, score=-3.36 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=risecloud.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JEJDES5R1FAy for ; Tue, 18 Dec 2018 00:27:32 -0800 (PST) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30088.outbound.protection.outlook.com [40.107.3.88]) (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 03F59127598 for ; Tue, 18 Dec 2018 00:27:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=RISEcloud.onmicrosoft.com; s=selector1-ri-se; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=p8RVOlEV5ERekO9Zpk4Kg0Ua6WAhcF3lSBOqVWedCBU=; b=X5dg5zO8v25EiSEUpZ7WIp6oToKBRQkN8w4Deia5MSFBrT02JQNye5I5TZZcjnLW3PMNgQAuOgvwL36mbaemAPUQ5AB0GRWFd5bxCE4bfYJ+sghx07+mCfT2kju4RegW5ReRWo8jA7A3enJFkJwyCuich0ydDSRql+IbQmIjCog= Received: from DB6P189CA0002.EURP189.PROD.OUTLOOK.COM (2603:10a6:6:2e::15) by HE1P189MB0329.EURP189.PROD.OUTLOOK.COM (2603:10a6:7:58::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1425.22; Tue, 18 Dec 2018 08:27:29 +0000 Received: from VE1EUR02FT055.eop-EUR02.prod.protection.outlook.com (2a01:111:f400:7e06::202) by DB6P189CA0002.outlook.office365.com (2603:10a6:6:2e::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1425.22 via Frontend Transport; Tue, 18 Dec 2018 08:27:29 +0000 Authentication-Results: spf=pass (sender IP is 194.218.146.197) smtp.mailfrom=ri.se; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=ri.se; Received-SPF: Pass (protection.outlook.com: domain of ri.se designates 194.218.146.197 as permitted sender) receiver=protection.outlook.com; client-ip=194.218.146.197; helo=mail.ri.se; Received: from mail.ri.se (194.218.146.197) by VE1EUR02FT055.mail.protection.outlook.com (10.152.13.34) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.20.1446.11 via Frontend Transport; Tue, 18 Dec 2018 08:27:28 +0000 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_128_CBC_SHA256_P256) id 15.1.1531.3; Tue, 18 Dec 2018 09:27:28 +0100 To: Hannes Tschofenig , Stefanie Gerdes , Jim Schaad , "ace@ietf.org" References: <154322421294.8323.8505315870685563404.idtracker@ietfa.amsl.com> <03b601d49191$7d1bb400$77531c00$@augustcellars.com> <945fbebe-659f-ac72-3ab6-8e05447e7c92@ri.se> <1c5b81f3-50ce-be68-bec3-68ce2ff15b43@tzi.de> <4ae4eccd-68bf-18ef-f909-142f8172eca1@ri.se> <81ba3ab4-a9ce-a6fd-fbe6-c36a6fbbd9a5@tzi.de> From: Ludwig Seitz Message-ID: Date: Tue, 18 Dec 2018 09:27:27 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.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-2.sp.se (10.100.0.162) To sp-mail-2.sp.se (10.100.0.162) X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:194.218.146.197; IPV:NLI; CTRY:SE; EFV:NLI; SFV:NSPM; SFS:(10009020)(346002)(376002)(136003)(396003)(39860400002)(2980300002)(189003)(199004)(51444003)(40036005)(81156014)(81166006)(97736004)(74482002)(230700001)(117156002)(68736007)(47776003)(229853002)(44832011)(5660300001)(65956001)(356004)(50466002)(508600001)(65826007)(86362001)(31696002)(486006)(53936002)(2501003)(65806001)(14444005)(126002)(476003)(6246003)(305945005)(446003)(77096007)(69596002)(16526019)(3846002)(186003)(64126003)(76176011)(36756003)(67846002)(11346002)(53546011)(386003)(7736002)(8676002)(336012)(22756006)(104016004)(2616005)(2906002)(316002)(31686004)(15650500001)(106002)(93886005)(16576012)(106466001)(33896004)(6116002)(23676004)(2486003)(22746007)(26005)(58126008)(8936002)(110136005); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1P189MB0329; H:mail.ri.se; FPR:; SPF:Pass; LANG:en; PTR:InfoDomainNonexistent; MX:1; A:1; X-Microsoft-Exchange-Diagnostics: 1; VE1EUR02FT055; 1:hYofHqNLrn7VNjF9KHaqNLj93RoFlm3y1WHduyssmCuSusMhhwNJ90wpE0hWpt3v5paKoJFqqfVkHkxAe5SX9rnzTHa+QT5qvdgjr123HdYsDq40JhoakNQYRh8QxMEr X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 7ee047bd-bc51-4b37-f09e-08d664c2a603 X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(7021145)(8989299)(4534185)(7022145)(4603075)(4627221)(201702281549075)(8990200)(7048125)(7024125)(7027125)(7023125)(5600074)(711020)(4608076)(2017052603328)(7153060)(7193020); SRVR:HE1P189MB0329; X-Microsoft-Exchange-Diagnostics: 1; HE1P189MB0329; 3:4WgPSQU7lbsYEY0mCb+jOLwYR0+Uu0g6ic9WlB5IyL9wW9ke61KNGlvuLtsehwRJYknLyu502iW6c16VpjsEXNk9XE5N2eHhF8kpiAT74DoftDckaKTOZC2mmqu/4PzpxY1Mn6mhpEkjK5fB8NY4cD0l88NtN89Bj+ILiuXUelA967t/ppPMLHEwBzZrEgRkR9KU6TLpy727tF2zQ4BOWfP5M6971Gf/ekIeL1GDExlnHFBkNC8Bykf1RtaaoeIrTKqc5oS43uKjwH8l88v5N3XqY5sKLfc/t9qI6Pkt4QeKaB+C5rB+nOghOq1Kg0Ae8i+z/mIrLyXXQQW6d876QkbydYbJCFITehM0X6ls2Us=; 25:zV6uHG8uFcHz0YSccHLekc60iUSlh55nV4kvTG9qfO9UNqkXid7WEMPlyFAWVCa/LWPflQIqtQNvziBmneGbYpewqtRwigufufkXggHqFeDLNAp8u752vVGpApqKayPd2OVrCZbItjpYrJCv4v4+lNtzPpOF+yZuxNyW0kwh0enq+E+1ZYuygyenxFKLw2aQBRW07gGPPhQ3kPmdB4W6GR+ST7YE6OH41Yu6lpl60iPS3Ob3iNLxX9nZVRRCCxJ7Mll4oUjo48vD/B7We+0TlhqCvNseRYSdHNqiQgsBaJmfU4jeyUvrqkFyZgWdy38hXkdAQnFRLVRS0kvlOoji8g== X-MS-TrafficTypeDiagnostic: HE1P189MB0329: X-Microsoft-Exchange-Diagnostics: 1; HE1P189MB0329; 31:GAy0jzJ3u7z/T25dhwXzVndqoWJV4uOqU1qjDfur/vV/pYBA5HwhJc6tGwntpBFZ5Y6vi6zThw32SADRH0TFcJ8wjT7U+VcOmnx8qSrbxdX8pCrG3gZWp+GU+lFTdqDNbaOOiyjR5Y+mKn9+WJ2PhEAqCra/nLQeCCj2bk0S9W1tdmKpHe71NBxBHg6S6eLAaJnNZvbj3iYMvr1jJabUTnJ4R/iTQWaF4nrIG052iqA=; 20:wnG66bY/7at7wkH97J8HMayxMeQZIJHlKha7hh/pDtQyHct2A/LgDgDcQxnhQyIdNqkAFrjPOuWJ4anY+C75sJQuAUwqP1CA/RvyWt6mNBl8hDA62Qg0OMVPe77N2Znhn5C7g/bjl8kFQIWnEWFKTls47mxY7FM1QQP45SFlLI5bmGSSPdaIS94zaUPXCdUyTC6rJiUuMVYa6yKrTRoiE3iMNakpFubT0c2SjMhmWsOiTyaWEL++PGDuoa3OxDpG; 4:rmf0qP/g+byM4iEvhcUgcFR+qI3ArLhJgOROmWU+77ytAMRbN2CrZRmHUt9LI9XOFD40gAPhu00+jWvcqVR0qh9ilGmtnbm9z0SG1a+2om7mIvqVlQwIhwhyCjB1rnt+aBovskr46L0CIXBXaOesww1wcqSjNEEAf/aJ29S1jTzh1RmlpcG1mOi2j48HUxrq72L0MniitYEd8ft+4KmjGmAmplkm2m0P/4Cht8Z6QV0dlO+ZnFxQ1py2atu7/9H9DvlgtzmtJMHxM6llliU10g== X-Microsoft-Antispam-PRVS: X-MS-Exchange-SenderADCheck: 1 X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(3230021)(999002)(6040522)(2401047)(5005006)(8121501046)(93006095)(93004095)(3231475)(944501520)(52105112)(10201501046)(3002001)(148016)(149066)(150057)(6041310)(20161123562045)(20161123558120)(20161123564045)(20161123560045)(2016111802025)(6043046)(201708071742011)(7699051)(76991095); SRVR:HE1P189MB0329; BCL:0; PCL:0; RULEID:; SRVR:HE1P189MB0329; X-Forefront-PRVS: 08902E536D X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtIRTFQMTg5TUIwMzI5OzIzOksxaUtZbmRlRHVUYkxOUHpuUWFpSnRJMGdB?= =?utf-8?B?Z01mQ0NmQVFjNm55MVdiT24rOWVvR1ZsdVZtZnhrMkV1NWQyL3F4M0s4WXFY?= =?utf-8?B?TUMrVkdNVFZneTF4MkpYVzVvZVFVRXFaaEIyeUFaVUYxYlo4MXVZZEtHWUFo?= =?utf-8?B?SG9zcUxlU0ZHZjV5b3M4KzBQdWNMSmlKS1JFdXhTUmJMN2VhYSt2M0VmZXZ6?= =?utf-8?B?L0dnTkViSEU1NFI4YWI0cndIMnpDZXI1aEc1VnBWNmZvZ1hFMlVQdzZQYkVm?= =?utf-8?B?WU9PUUhJdlZ3VnZjVCtRUURYUHE5RXBic1lEd3kwNlQ4Z0tNSFJ0OGNkRnE0?= =?utf-8?B?MDVZV1A5dUduSk54Q3hEWkd1NFJUbkNVWDBsaHpKWW1rYi9iNmpCZ1hQbnR2?= =?utf-8?B?cE9RNFhaRDREWkNnenNXQUp3cUZocURva2xWb0k0R2M4NWlqcnlmWkltbWkr?= =?utf-8?B?MGx2WWxQeUJrN0VCTTNZdjlDR0ZVc1ZYYkpEVDdmNU82d3p5UzJCMldjT2g3?= =?utf-8?B?ek14YXRzbnFOSFEwWTEwUnRvZ0dMSzR0Y05VRE90MUNIRG9QZTNPNmFGVi8y?= =?utf-8?B?V0dvOEsrT2J3aDZXQlVqZ0t1UGpOeTkxUzhmZnQwYkdMMW50S3NNTmdCVVpY?= =?utf-8?B?TmRjV0dBMHJwZ1VCZzE5Y29ZTjAzZGZrSFV2YkNpOXpTSlpKTWp5MXU5RUll?= =?utf-8?B?SmYwVm1kM2NrWU90c1BIZWJvbFZYRDFVQ3V0MWdUVUpodWpOZFQrc1JzenYw?= =?utf-8?B?b0dRWjF6NlFOeUFzNGd1WStvYXFUbnRoR2cvbmRmMnhGQ3FFNnlHNWZ4a3hG?= =?utf-8?B?MkVrdllOdXIxTk9NNy93YWFOQUdTVys5VnA1RkZlRXhVTm5EVHRaM2tLOVNQ?= =?utf-8?B?dldjTStVb1dBSk01MW1nKytBRTM1a1pHdnl3WlhvZXcweWYzT3dPMHlkdkdj?= =?utf-8?B?RjJrVUZ5TWtuRDlObkdRVXd6SXBYVTUydEZsaFcvbGJoRmw2d0wzNEpOYXNX?= =?utf-8?B?bXdncnNFSVl5RUtWNmNVV0ErM3hZQWllSktkTWlhc3NITEFiNFBCMUE5aC9I?= =?utf-8?B?K2t6L0dZa21wYytTcFRuVzhkeHdzSEJ0NHVNcjNESlRGVGFvRi9qNW9DZG83?= =?utf-8?B?dGRzUjlaRWlmR05DdCtDOVZoSEhmY3FFYzEvS0Zpa01UTXd3YUhWUjJCKzlB?= =?utf-8?B?VjU5NDlJZEJvYldkUHRBaTRDcS9vSU44V0JRMmJaZlRSczEzRE43WUJ4R1FF?= =?utf-8?B?SktuSDJQTENRL3RpNzN4aVhNUktDdDk1ZzN0Y0xHOUVtaFowUXFzUXdRc0lB?= =?utf-8?B?K3g2dS8wcmx0Wk9QeXJtRzhEYXQ5ajd5aW04Y3F6Q1d4a2NpdmFYdVhFMWts?= =?utf-8?B?ajdtRmNSb0EwWm9NOVdjSGhxMXc3YkYzTVBZWk5QVXRnMU9VKzk3RE80RDZi?= =?utf-8?B?TUl4OVRPS3NZdjJnQ08zMFBiRkJlTWJXMUxFT0dML2ZEanZXV1ViblNXOGJK?= =?utf-8?B?RWg0NUdXQTAzNXQ0MDlFemVYUjNKZUwzTnQzMEJPR3pLSE56WGJTZDFZSTlj?= =?utf-8?B?UnNJa2ZCNWMrRXFBSzlmRmZ2RVdyckEyVzNMVjNUU2EvcUpnY2k2MEdyMFZC?= =?utf-8?B?Q3UwYWRkU3hhazh6VVZhTmFzMzRadlYyTitXYzVKaG44QWdqNjJQRjFodjhv?= =?utf-8?B?RHd0VlVKa1YydUlaRHdjQXZRUzRtNjJmY1lEcVpMZ1R6bXduc3l2aUx1cDky?= =?utf-8?B?Y1Z3MDJVSFdISW9KYllHM2FIQVVWS3lKV0o3c1BFMzJFNkt4T01xSmE2YUV0?= =?utf-8?B?OTRZU2VGRHJGTkVVRzkvRGtsRzBhcWdlSVpVZk1XbzlSYUJjWStoQnZHY0Nh?= =?utf-8?B?THlyZTUyV1c3RUJ0TFp2N3pMRzRLS2tqRTB4cXltbEN3ZW9KdnZ2Q1g1bS9Q?= =?utf-8?B?MGtCRnNHN2g1NEF1S1pnaFNUTGFHRnVSQTFLK0tnUWFlWkZndzljZ3JGSkFY?= =?utf-8?B?c0NaQllxNG1KZU95cDV2UkZjdGxveVJlWm9HQTAvdUdmbW1lcGEybUlFNnIz?= =?utf-8?B?NHdNWGljd2tTeW8zTFJqKzBEaXN3L0hhR05yT3hod2lEbVg5aTZad0tjcmFJ?= =?utf-8?Q?8XZAgUNKVDGEDRGTsGEGVF7uWVVCX2RZxPMiqah1yfVO?= X-Microsoft-Antispam-Message-Info: fDyGbzegjMpssOD6uLGVNIOBVx05nRUx85ShKobUBlxDSim6irdwe+S4hpxu/KYe0yd9jj1KG2L4EiMqTbKg/N9TydwQPwQXBlz6HR+6hpnvGa/14/RaBFdR8ruc0uNtSp0PKxF+ADU6/IbYttMU2z19Nj/l3blheyLQgUz5Bzdl1osC47jHwX8Tu8ClqZIzQ4juodMkAzzEHNrUL1xzJs6M3pbaoJJk6gTMgCYxiT9mEqoolDviVMy9697hfszbmF74GX9pdqlDrgLwZ86PIMqSwAUPrHXN9sOO0NuSti1gEPCh0PU0QjluZTvdTkYm X-Microsoft-Exchange-Diagnostics: 1; HE1P189MB0329; 6:2w8GVv8XlyThP0g43FicbqzVsYB35X6Gd4AD7AcVx0x4WrLKMgfUHOMUViiNyYvngCmxMW92+8rn8TZdKQeycVY6UVqBwgVmDo2mTx75nab6jESKa8LD8eMidZgqUEneFvhCp2e89HZvZIhLDxI6B6YF/Z7EHhevqXNTy0Zm4dj/O1m285k7pcFneK74i7HXGBDmUI8+hIr5QrlmyHHgjtxEZwPj9j/5hiQhVU7lD4glF/Z74sylNq7WmXhkPj3QUWjy8kQ60gomPcwEYUN4au6LqNMYjqDmnSj3L3tjrvnFqSDeq3wgpvw3yZ9BT8PUA3Fn0SNNkvgapdguuPDnVZe+aBvKGjX5dPUn9CNp6fXofQo78cSIHVR6g2fb5xI9dxlwruVjUDlJHIJrZf46NQemARoE6etZzGHNt2eR2IYm1YlWgXrasNJkMEu5wl+k5bhQrmWSyJuw8I9tzaPXxw==; 5:W/xf4hNm0uQ2u4ZSe7o4352lnyXai6g6sELa4KQXnomfQR1CWu9Gzk3Nh6xIg4519QLPcAsP64dhaDSYfbJ/pg/YePob6eyUGv6tVhsa5cdygI8/76/yncTkLZsCtn1oqEnvvDBM8LA2NkRleeMyurv7aeZD2kpE5jwJDg+Bnp8=; 7:+Ol9cNEij8rZn1cY0UDBDAkExpbYoveEAOhpp3mLdXV8va85LdjVOUddveGYkNBwj8BL7lKr+cEkrDeCdMDR7L/S44rNM9fWnsjAC7yBeeyXgsHtMiT45Re6C5GAztfTNOBvpTWw77uyIHbs91nPRQ== SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Dec 2018 08:27:28.9650 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 7ee047bd-bc51-4b37-f09e-08d664c2a603 X-MS-Exchange-CrossTenant-Id: 5a9809cf-0bcb-413a-838a-09ecc40cc9e8 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=5a9809cf-0bcb-413a-838a-09ecc40cc9e8; Ip=[194.218.146.197]; Helo=[mail.ri.se] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1P189MB0329 Archived-At: Subject: Re: [Ace] Security of the Communication Between C and RS X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2018 08:27:35 -0000 On 15/12/2018 16:04, Hannes Tschofenig wrote: > Hi Steffi, > > ~snip~ > >> I really think you should point out that symmetric keying material >> that the AS provides to the client is valid as long as the token. > > I think that's a useful recommendation. I do, however, believe that > we are not making the same assumption for an asymmetric key bound to > the token. > Ok, I'll add text to the draft that says this. Note that this can be trouble if a client asks the AS to bind an existing symmetric pop-key to another (new) token it is requesting. Which one of the two tokens bound to that key is now steering the expiration of the key? >> I also think that the client must be able to assume that RS' RPK >> that C receives from AS is also valid as long as the token, unless >> C has additional information. > > I would think that it is rather unlikely that the RS will change its > public/private key pair so quickly. Right? > Agree with Hannes here. RPKs wouldn't typically be changed that fast. >> The access information optionally can contain an expires_in field. >> It would help to prevent security breaches under the following >> conditions: > 1. the keying material is valid as long as the ticket, 2. the > expires_in field is present in the access information that AS sends > to C, 3. the client checks the expires_in field when it gets the > access information from the AS, and 4. the client checks if the > keying material is still valid each time before it sends a request to > RS. > > These checks make sense to me. > Are you proposing we make the expires_in field mandatory? If so, why isn't it mandatory already in OAuth (currently only RECOMMENDED)? /Ludwig -- Ludwig Seitz, PhD Security Lab, RISE Phone +46(0)70-349 92 51 From nobody Tue Dec 18 00:47:26 2018 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 AA1F213107D for ; Tue, 18 Dec 2018 00:47:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.359 X-Spam-Level: X-Spam-Status: No, score=-3.359 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hOG8R4fbEpUg for ; Tue, 18 Dec 2018 00:47:21 -0800 (PST) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10057.outbound.protection.outlook.com [40.107.1.57]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2664D127598 for ; Tue, 18 Dec 2018 00:47:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=mk5gok+4vTYmhGZr2dREc3QOdnSPRKSluQcxBUjW9LM=; b=doENgJ8ShYPC2uUVKQUE6eHVA1730FEZ/6bS4DdL26pFHcuCCZF9pVSPWfrcctZPXu3w0HjteKnkzTcudoIVSn3Ydu3eK/hSu3VHTUsFX+/BfMLk2TGiOcWUmTOPyMhABSX+MVKws6HvPJzJc5yumFbc9qOjVUFavPcYcxvGS7Q= Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB1440.eurprd08.prod.outlook.com (10.167.210.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1425.22; Tue, 18 Dec 2018 08:47:17 +0000 Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::e8de:6a41:cbf4:89d8]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::e8de:6a41:cbf4:89d8%3]) with mapi id 15.20.1425.023; Tue, 18 Dec 2018 08:47:17 +0000 From: Hannes Tschofenig To: Ludwig Seitz , Stefanie Gerdes , Jim Schaad , "ace@ietf.org" Thread-Topic: [Ace] Security of the Communication Between C and RS Thread-Index: AQHUlquFKpsKbsbb2kGcq8Jrm430i6WELNAA Date: Tue, 18 Dec 2018 08:47:17 +0000 Message-ID: References: <154322421294.8323.8505315870685563404.idtracker@ietfa.amsl.com> <03b601d49191$7d1bb400$77531c00$@augustcellars.com> <945fbebe-659f-ac72-3ab6-8e05447e7c92@ri.se> <1c5b81f3-50ce-be68-bec3-68ce2ff15b43@tzi.de> <4ae4eccd-68bf-18ef-f909-142f8172eca1@ri.se> <81ba3ab4-a9ce-a6fd-fbe6-c36a6fbbd9a5@tzi.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [80.92.114.221] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0801MB1440; 6:qCRQJ23VqidA4PVfRd7mO2QchxkTO0T6xdIsI6AKwewGG+0aF5XNrQQvrAu/qjXJNNRKg3JM9+LiRixA/DG4G9QKlqiPiUiOR+lrSnHxa6CnC6rDnVaisuCDKff+bVTENPIamsXd3e/mtxv8VC67Sky0OBU6MJ29CeNlus+0kaoEJQsRunV897vC0igq6aZbYqkeiRh+ljsj9dyV90huAzuo3oTGwlt5zMc5Xs6x6iiyE72PsRp9KSuUfZ6wG7nYpljqoIjqGSMYnGGm8qFgBdO2g3uXA6MKcS3NTzZ0q+GYMnGEedYu42itHdSh3GTb5fzZP7bx2qj2HQ6yB9mQgUzmmHxa5QxzOn3wUGLUrS7j/3eSa+95C8kXNOpDC0cN03+joi2VPAY5f+wCPZDdOq3XWSVH8gRhvSNpFlfE209+9oCmfsfHChyq25sjhyd4Kf5aPAFsTbiydW4qINDtEQ==; 5:PDqSgPnadO3JBPf2iw6v6+6mhjAtQOyvG4UgGcfw/7PIr3K9Ssc5kv4hkD+hBSGseycoKzeUgXNwuUnTN4ypVgtipO6QEe5qpQSAubcxybUi8ZG9LwbJBczk2NElynAu7Dtzy1JUzFsVcdszcQqvzbGyx+Ka/wRyhnO8UIxdGJY=; 7:RSk2nSdgKYz4CID+HR6dG/amF5G3i7eTO0qObuvSXOxUBvs3/JvTthEcY5+ZDzd7kz2RwEi73aMrxeu06sXo1c87YAbOP3eNTqu1Mgf/gxCS/oJ3/w+DBCnvGHPt+uqIWEMt3x8VBoho/Q2Y63CdKw== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: c06b09f6-6c5d-4202-94a9-08d664c56a56 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(4618075)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB1440; x-ms-traffictypediagnostic: VI1PR0801MB1440: x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(3230021)(999002)(6040522)(2401047)(5005006)(8121501046)(3002001)(10201501046)(93006095)(93001095)(3231475)(944501520)(52105112)(6055026)(148016)(149066)(150057)(6041310)(20161123560045)(20161123558120)(20161123564045)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(201708071742011)(7699051)(76991095); SRVR:VI1PR0801MB1440; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0801MB1440; x-forefront-prvs: 08902E536D x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(136003)(376002)(39860400002)(396003)(346002)(40434004)(199004)(189003)(51444003)(13464003)(71200400001)(71190400001)(74316002)(229853002)(6116002)(66066001)(316002)(3846002)(93886005)(81166006)(81156014)(55016002)(97736004)(8676002)(106356001)(8936002)(105586002)(33656002)(86362001)(9686003)(99286004)(486006)(26005)(6246003)(186003)(53936002)(2501003)(478600001)(7736002)(14454004)(110136005)(102836004)(6436002)(2906002)(6506007)(53546011)(7696005)(76176011)(68736007)(256004)(14444005)(5024004)(5660300001)(72206003)(11346002)(446003)(476003)(305945005)(15650500001)(25786009); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB1440; H:VI1PR0801MB2112.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: XoKjTpeqlSFujPVPgFVEg/jlbe3SvxubU5PriqTNEup+p6sa501V7DRz4VjJe6cqWxmLTgfY04YtL8fRQvVrI3FyUaySP4FVCYMWvzkWKSisgk86qvfmhrV7VqxHgUAP2s7/fkUqF82qdUgVGu1t94ydh3b41fZfouCgfv9a2l8wgo9Jx4iwmG1sm5lhep69g/7FJm2IU94ZjgozsG85g7RCfbMjVB1kxDTxsncSmCm5Yz9N65/MmWMCbCor3GFEqG7MjNY/sME6K8yS4PYF4ylxjvxCYucTt3NbuVyVW3bdTOVZhAAUDDL1Sb6GQtQi spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: c06b09f6-6c5d-4202-94a9-08d664c56a56 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Dec 2018 08:47:17.3335 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1440 Archived-At: Subject: Re: [Ace] Security of the Communication Between C and RS X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2018 08:47:25 -0000 SGkgTHVkd2lnLA0KDQpBIGZldyByZW1hcmtzIGlubGluZToNCg0KLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCkZyb206IEx1ZHdpZyBTZWl0eiA8bHVkd2lnLnNlaXR6QHJpLnNlPg0KU2VudDog RGllbnN0YWcsIDE4LiBEZXplbWJlciAyMDE4IDA5OjI3DQpUbzogSGFubmVzIFRzY2hvZmVuaWcg PEhhbm5lcy5Uc2Nob2ZlbmlnQGFybS5jb20+OyBTdGVmYW5pZSBHZXJkZXMgPGdlcmRlc0B0emku ZGU+OyBKaW0gU2NoYWFkIDxpZXRmQGF1Z3VzdGNlbGxhcnMuY29tPjsgYWNlQGlldGYub3JnDQpT dWJqZWN0OiBSZTogW0FjZV0gU2VjdXJpdHkgb2YgdGhlIENvbW11bmljYXRpb24gQmV0d2VlbiBD IGFuZCBSUw0KDQpPbiAxNS8xMi8yMDE4IDE2OjA0LCBIYW5uZXMgVHNjaG9mZW5pZyB3cm90ZToN Cj4gSGkgU3RlZmZpLA0KPg0KPiB+c25pcH4NCj4NCj4+IEkgcmVhbGx5IHRoaW5rIHlvdSBzaG91 bGQgcG9pbnQgb3V0IHRoYXQgc3ltbWV0cmljIGtleWluZyBtYXRlcmlhbA0KPj4gdGhhdCB0aGUg QVMgcHJvdmlkZXMgdG8gdGhlIGNsaWVudCBpcyB2YWxpZCBhcyBsb25nIGFzIHRoZSB0b2tlbi4N Cj4NCj4gSSB0aGluayB0aGF0J3MgYSB1c2VmdWwgcmVjb21tZW5kYXRpb24uIEkgZG8sIGhvd2V2 ZXIsIGJlbGlldmUgdGhhdCB3ZQ0KPiBhcmUgbm90IG1ha2luZyB0aGUgc2FtZSBhc3N1bXB0aW9u IGZvciBhbiBhc3ltbWV0cmljIGtleSBib3VuZCB0byB0aGUNCj4gdG9rZW4uDQo+DQoNCk9rLCBJ J2xsIGFkZCB0ZXh0IHRvIHRoZSBkcmFmdCB0aGF0IHNheXMgdGhpcy4NCg0KTm90ZSB0aGF0IHRo aXMgY2FuIGJlIHRyb3VibGUgaWYgYSBjbGllbnQgYXNrcyB0aGUgQVMgdG8gYmluZCBhbiBleGlz dGluZyBzeW1tZXRyaWMgcG9wLWtleSB0byBhbm90aGVyIChuZXcpIHRva2VuIGl0IGlzIHJlcXVl c3RpbmcuDQpXaGljaCBvbmUgb2YgdGhlIHR3byB0b2tlbnMgYm91bmQgdG8gdGhhdCBrZXkgaXMg bm93IHN0ZWVyaW5nIHRoZSBleHBpcmF0aW9uIG9mIHRoZSBrZXk/DQoNCltIYW5uZXNdIE5vcm1h bGx5LCB0aGUgY2xpZW50IHdvdWxkIG9ubHkgcmVxdWVzdCBhIHN5bW1ldHJpYyBQb1AgdG9rZW4g ZnJvbSB0aGUgQVMgYW5kIHRoZSBBUyB3b3VsZCBjcmVhdGUgdGhlIHN5bW1ldHJpYyBrZXkgYW5k IHJldHVybiB0aGUgUG9QIHRva2VuICsgdGhlIHN5bW1ldHJpYyBrZXkuDQpIZW5jZSwgaW4gdGhl IG5vcm1hbCBjYXNlIHRoaXMgc2hvdWxkbid0IGJlIGhhcHBlbi4NCg0KPj4gVGhlIGFjY2VzcyBp bmZvcm1hdGlvbiBvcHRpb25hbGx5IGNhbiBjb250YWluIGFuIGV4cGlyZXNfaW4gZmllbGQuDQo+ PiBJdCB3b3VsZCBoZWxwIHRvIHByZXZlbnQgc2VjdXJpdHkgYnJlYWNoZXMgdW5kZXIgdGhlIGZv bGxvd2luZw0KPj4gY29uZGl0aW9uczoNCj4gMS4gdGhlIGtleWluZyBtYXRlcmlhbCBpcyB2YWxp ZCBhcyBsb25nIGFzIHRoZSB0aWNrZXQsIDIuIHRoZQ0KPiBleHBpcmVzX2luIGZpZWxkIGlzIHBy ZXNlbnQgaW4gdGhlIGFjY2VzcyBpbmZvcm1hdGlvbiB0aGF0IEFTIHNlbmRzIHRvDQo+IEMsIDMu IHRoZSBjbGllbnQgY2hlY2tzIHRoZSBleHBpcmVzX2luIGZpZWxkIHdoZW4gaXQgZ2V0cyB0aGUg YWNjZXNzDQo+IGluZm9ybWF0aW9uIGZyb20gdGhlIEFTLCBhbmQgNC4gdGhlIGNsaWVudCBjaGVj a3MgaWYgdGhlIGtleWluZw0KPiBtYXRlcmlhbCBpcyBzdGlsbCB2YWxpZCBlYWNoIHRpbWUgYmVm b3JlIGl0IHNlbmRzIGEgcmVxdWVzdCB0byBSUy4NCj4NCj4gVGhlc2UgY2hlY2tzIG1ha2Ugc2Vu c2UgdG8gbWUuDQo+DQpBcmUgeW91IHByb3Bvc2luZyB3ZSBtYWtlIHRoZSBleHBpcmVzX2luIGZp ZWxkIG1hbmRhdG9yeT8gSWYgc28sIHdoeSBpc24ndCBpdCBtYW5kYXRvcnkgYWxyZWFkeSBpbiBP QXV0aCAoY3VycmVudGx5IG9ubHkgUkVDT01NRU5ERUQpPw0KDQpbSGFubmVzXSBJIHdvdWxkIGRv IHRoZSBjaGVjayB3aGVuIHRoZSBmaWVsZCBpcyBhY3R1YWxseSB0aGVyZS4gSG93ZXZlciwgaXQg aXMgYSBnb29kIHF1ZXN0aW9uIHdoeSBpdCBpcyBub3QgbWFuZGF0b3J5IGluIE9BdXRoLiBMZXQg bWUgZHJvcCBhIG1haWwgdG8gdGhlIGxpc3QuDQoNCkNpYW8NCkhhbm5lcw0KDQovTHVkd2lnDQoN Cg0KLS0NCkx1ZHdpZyBTZWl0eiwgUGhEDQpTZWN1cml0eSBMYWIsIFJJU0UNClBob25lICs0Nigw KTcwLTM0OSA5MiA1MQ0KSU1QT1JUQU5UIE5PVElDRTogVGhlIGNvbnRlbnRzIG9mIHRoaXMgZW1h aWwgYW5kIGFueSBhdHRhY2htZW50cyBhcmUgY29uZmlkZW50aWFsIGFuZCBtYXkgYWxzbyBiZSBw cml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2Ug bm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIGRvIG5vdCBkaXNjbG9zZSB0aGUgY29u dGVudHMgdG8gYW55IG90aGVyIHBlcnNvbiwgdXNlIGl0IGZvciBhbnkgcHVycG9zZSwgb3Igc3Rv cmUgb3IgY29weSB0aGUgaW5mb3JtYXRpb24gaW4gYW55IG1lZGl1bS4gVGhhbmsgeW91Lg0K From nobody Tue Dec 18 05:51:50 2018 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 02121124BF6 for ; Tue, 18 Dec 2018 05:51:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.36 X-Spam-Level: X-Spam-Status: No, score=-3.36 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9bx2pfDb6gRh for ; Tue, 18 Dec 2018 05:51:47 -0800 (PST) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-eopbgr150055.outbound.protection.outlook.com [40.107.15.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9083C1200B3 for ; Tue, 18 Dec 2018 05:51:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=DdgTWN4Mm9k/mOxbDoc+IQW1MMB1YmD9G3mbpEk8OFs=; b=LC3IWp1m4YuqUIVwzJf6OZaC1EQrE3tjokgvHDLM87KpAPBYWINSaU1AbK7YcpFA/8idkiDvz2/hs9h4aByYQw32E7gfm61Nc2R2trzC5/Gnf/IMAvrQw1T8hTCTVE7LJuKT4eSScVCr0pJwJi2mFlQeaH/WpRnaiFnWxZavIPY= Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB1824.eurprd08.prod.outlook.com (10.168.68.9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1425.19; Tue, 18 Dec 2018 13:51:43 +0000 Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::e8de:6a41:cbf4:89d8]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::e8de:6a41:cbf4:89d8%3]) with mapi id 15.20.1425.023; Tue, 18 Dec 2018 13:51:43 +0000 From: Hannes Tschofenig To: Hannes Tschofenig , Ludwig Seitz , Stefanie Gerdes , Jim Schaad , "ace@ietf.org" Thread-Topic: [Ace] Security of the Communication Between C and RS Thread-Index: AQHUlquFKpsKbsbb2kGcq8Jrm430i6WELNAAgABWsZA= Date: Tue, 18 Dec 2018 13:51:43 +0000 Message-ID: References: <154322421294.8323.8505315870685563404.idtracker@ietfa.amsl.com> <03b601d49191$7d1bb400$77531c00$@augustcellars.com> <945fbebe-659f-ac72-3ab6-8e05447e7c92@ri.se> <1c5b81f3-50ce-be68-bec3-68ce2ff15b43@tzi.de> <4ae4eccd-68bf-18ef-f909-142f8172eca1@ri.se> <81ba3ab4-a9ce-a6fd-fbe6-c36a6fbbd9a5@tzi.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [80.92.114.221] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0801MB1824; 6:zAtfNRiXzY3BfFrD4hL5E9fC7puVcC8gN+zQyT4aKG8rH3mC3QuQR4Cd9/41dfwgwZ2QVbxNDYo+spb69gdlqZ6QmL8tSQgfBKGT+tnNW26ZzAmvJuQSjlqpGQNgiapGSUoSS9eCSUUC1DU4sR504429SE+J4XobbSyMkZEWDcMTDn5FiTAiv73+eYLBxbnoqOzrLG1joP/PhgzU9V7crK7RGaUMQ1LFX/Bk/XoMJkFo0CFhEfIa5//V+zkqPhXo9CmM+AMPF+0smRnFqR3TPMNzvjQJhISfnNxi7frB7rdJIS3dDVjZYjUtEOhZEAag+B5uEdfRBAcvRQbrS4puhyGaBw7Xu6+ZDdr5vVauLGutQb5VEg8nv+YKsC11KXWongqx1m65X6YeNAukixI3/cbDWJiH/rP673Qw9eIRF3R+MQNS9itCO3nfIMSXNAtSvUODA2/FEIxY3pujRAXNjg==; 5:UbFETsKvLjF6QaLCJjOSd3vNC2OFATODWQOJsUePVJJiQUjpM4f4rtx9cwe9cbbVnoijB2tFwiP5HHOTyDW1ggBgDFR16axKHduBknkVzHivg8Kl6PZYmbyQWZtN1PHGxNs1HgK+J0QO4euj6OvlRqKXQUKU7ctErhDtYb3+nws=; 7:gwznly4hRhad+du318g1vDdAPjcwimZGyrAv2LyCx7d55xC86SGCChCGCKZXrZHcIqFesJr5lnDN9KYy9OodEq8+TPf0bi+SWhIUvvSyfVyc+EvKXpjVabSaXrr2v4FsIjLJIhmZlVg8TlV9N5Xlgw== x-ms-exchange-antispam-srfa-diagnostics: SOS;SOR; x-ms-office365-filtering-correlation-id: 807f1ae7-ad45-4946-a8e8-08d664eff1c2 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(4618075)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB1824; x-ms-traffictypediagnostic: VI1PR0801MB1824: x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(3230021)(999002)(6040522)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006095)(93001095)(3231475)(944501520)(52105112)(6055026)(148016)(149066)(150057)(6041310)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123558120)(20161123562045)(201708071742011)(7699051)(76991095); SRVR:VI1PR0801MB1824; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0801MB1824; x-forefront-prvs: 08902E536D x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(346002)(136003)(396003)(39860400002)(376002)(40434004)(199004)(189003)(486006)(6436002)(81166006)(8936002)(81156014)(8676002)(71200400001)(71190400001)(33656002)(66066001)(86362001)(2501003)(106356001)(74316002)(446003)(476003)(11346002)(229853002)(99286004)(93156006)(6116002)(3846002)(7696005)(105586002)(76176011)(15650500001)(2940100002)(7736002)(97736004)(53936002)(305945005)(316002)(6246003)(93886005)(6506007)(55016002)(102836004)(5660300001)(256004)(186003)(14444005)(9686003)(68736007)(110136005)(72206003)(2906002)(478600001)(14454004)(25786009)(5024004)(26005); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB1824; H:VI1PR0801MB2112.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: gbmlasbwomuSpyPQRnJkklkbwZO0VeXiFCOwRCkqaIjyzb+Jicf16o2sF+zUCVW8eac8Lrhm2rflt1jVqjyE7B8O05+wY/UsmovAFhE6Ixq3RxnEtnsZuiWX/gIRHc77HqK0xilolu/0R/Ed19m0H2AdRxBu34HNNrD//82H1RB42+M69y0ULEP1vMi+puc1oJ/lMzeQOAalaQEXWjwiWCblVHqZMDewHpdAzTUGwnFoV/73tvbHHpwfwN5moFtrLWmd14SW59/G4lipCQ/vyIhGDZKxSmirg5I2L6l51RNL9YM7s1ce1kTNdT+9hjqB spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: 807f1ae7-ad45-4946-a8e8-08d664eff1c2 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Dec 2018 13:51:43.4437 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1824 Archived-At: Subject: Re: [Ace] Security of the Communication Between C and RS X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2018 13:51:49 -0000 Hi Steffi, Hi Ludwig, ~snip~ >> The access information optionally can contain an expires_in field. >> It would help to prevent security breaches under the following >> conditions: > 1. the keying material is valid as long as the ticket, 2. the > expires_in field is present in the access information that AS sends to > C, 3. the client checks the expires_in field when it gets the access > information from the AS, and 4. the client checks if the keying > material is still valid each time before it sends a request to RS. > > These checks make sense to me. > Are you proposing we make the expires_in field mandatory? If so, why isn't = it mandatory already in OAuth (currently only RECOMMENDED)? [Hannes] I would do the check when the field is actually there. However, it= is a good question why it is not mandatory in OAuth. Let me drop a mail to= the list. Now that I got a response from the OAuth working group (in the sense that I= was thinking about the claims in the access token rather than the paramete= rs in the response from the AS) I think checking the expires_in field has t= o be optional since * the expires_in parameter is optional, and * it only has an advisory nature. It is useful to send the parameter so that the client can determine when to= request a new access token (for example, via the refresh token) but it is = not absolutely necessary for the protocol operation. Ciao Hannes IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. From nobody Tue Dec 18 06:38:44 2018 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 A3713126CC7 for ; Tue, 18 Dec 2018 06:38:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.36 X-Spam-Level: X-Spam-Status: No, score=-3.36 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=risecloud.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vm7z_foI7JVB for ; Tue, 18 Dec 2018 06:38:39 -0800 (PST) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-he1eur04on0622.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe0d::622]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4B66127AC2 for ; Tue, 18 Dec 2018 06:38:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=RISEcloud.onmicrosoft.com; s=selector1-ri-se; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+FF3+bkQ+bC4Zn1KzYnKsjc+0/P74MsFxX0g90DDHmI=; b=hsWKKo3RxKwbV92uUme1ROzNPR8ABKUxV8nC8m8VjpG2SMBQN8O68mUyg4w9D+0b2kZV1s4BKzPsiOlxHvYAuakFCsfKhFw/GiJKEU4rvqOrFtpxiHZcpFfeFlqtCg35R/vgmXvpXbjm0BKwcQ09gpNFt3rsIfKDbC1FCPWGKj8= Received: from DB6P189CA0026.EURP189.PROD.OUTLOOK.COM (2603:10a6:6:2e::39) by DB6P18901MB0102.EURP189.PROD.OUTLOOK.COM (2603:10a6:4:26::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1446.17; Tue, 18 Dec 2018 14:38:36 +0000 Received: from VE1EUR02FT064.eop-EUR02.prod.protection.outlook.com (2a01:111:f400:7e06::208) by DB6P189CA0026.outlook.office365.com (2603:10a6:6:2e::39) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1425.19 via Frontend Transport; Tue, 18 Dec 2018 14:38:35 +0000 Authentication-Results: spf=pass (sender IP is 194.218.146.197) smtp.mailfrom=ri.se; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=ri.se; Received-SPF: Pass (protection.outlook.com: domain of ri.se designates 194.218.146.197 as permitted sender) receiver=protection.outlook.com; client-ip=194.218.146.197; helo=mail.ri.se; Received: from mail.ri.se (194.218.146.197) by VE1EUR02FT064.mail.protection.outlook.com (10.152.13.199) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.20.1446.11 via Frontend Transport; Tue, 18 Dec 2018 14:38:35 +0000 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_128_CBC_SHA256_P256) id 15.1.1531.3; Tue, 18 Dec 2018 15:38:34 +0100 To: Hannes Tschofenig , Stefanie Gerdes , Jim Schaad , "ace@ietf.org" References: <154322421294.8323.8505315870685563404.idtracker@ietfa.amsl.com> <03b601d49191$7d1bb400$77531c00$@augustcellars.com> <945fbebe-659f-ac72-3ab6-8e05447e7c92@ri.se> <1c5b81f3-50ce-be68-bec3-68ce2ff15b43@tzi.de> <4ae4eccd-68bf-18ef-f909-142f8172eca1@ri.se> <81ba3ab4-a9ce-a6fd-fbe6-c36a6fbbd9a5@tzi.de> From: Ludwig Seitz Message-ID: <6aa8d090-df64-ab97-326e-4511dbe105de@ri.se> Date: Tue, 18 Dec 2018 15:38:34 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.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-2.sp.se (10.100.0.162) To sp-mail-2.sp.se (10.100.0.162) X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:194.218.146.197; IPV:NLI; CTRY:SE; EFV:NLI; SFV:NSPM; SFS:(10009020)(396003)(376002)(39860400002)(346002)(136003)(2980300002)(199004)(189003)(14444005)(508600001)(26005)(64126003)(31686004)(53546011)(386003)(16526019)(11346002)(33896004)(305945005)(77096007)(186003)(7736002)(336012)(76176011)(6246003)(22746007)(22756006)(40036005)(104016004)(74482002)(446003)(2616005)(44832011)(230700001)(476003)(486006)(126002)(117156002)(3846002)(6116002)(2906002)(67846002)(106466001)(5660300001)(65806001)(65956001)(8936002)(229853002)(47776003)(8676002)(81156014)(81166006)(93886005)(65826007)(36756003)(106002)(356004)(69596002)(58126008)(110136005)(16576012)(316002)(68736007)(97736004)(86362001)(31696002)(2501003)(50466002)(15650500001)(53936002)(2486003)(23676004); DIR:OUT; SFP:1101; SCL:1; SRVR:DB6P18901MB0102; H:mail.ri.se; FPR:; SPF:Pass; LANG:en; PTR:InfoDomainNonexistent; A:1; MX:1; X-Microsoft-Exchange-Diagnostics: 1; VE1EUR02FT064; 1:D2jQt5tYI4aRHUly4L/D/5C8XetOAa3zsOq4CTz/Ih/Cvdvq+AaWJziGrrv7K1Z0/RIEdHRe+oUhSlZvbdgH4RHNiaDdhzJR++UQW4e5uOXY50wjOJHSz5B3Qkqlbl7U X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 27c6e4ec-5a75-4bdf-3d53-08d664f67df2 X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(4608076)(2017052603328)(7153060)(7193020); SRVR:DB6P18901MB0102; X-Microsoft-Exchange-Diagnostics: 1; DB6P18901MB0102; 3:MKrpDg4IHvSHSf7zIebOozgSkHTw8P9WJGViwI7Viko5szDMKWYhJWXTZgf8eNsBTOttO3dGi6vG8nW2Q09VU/YmkPO5+dEic/Kvlb0FF8hcqGanX+Gok93qxfA7Y+5o1f6xcIxy4yM5zlvjzSKdOQSDj5VdT9sumRDhQXICtrbsoc09BMozkGW4zZw01QBktB+ivWvnQhc6bo3v+Je565O2GY7HJIsDJVpDD3xD25yNadZisrARVSsU5TUUxneU/7HRY1T9IaDpWuo1UNH0FJfF+1DfLemOGExO51SE/+IfVUM9jibBPdYIAgn672N+OcWQ25v/eqwHlDt92PYBUzy5LWNtYmhkm3Mj8SnE0m8=; 25:8z6MVCnUXjwWRVnBeu19p1iox5mDdOG3/EkNmD8WJh3g0WGhxVFPyemO8DrbDekBT0raUaPEwT85dnZdIk8ALHQ57IrF6C4ZZ1CZ4knGJlObU0CxI8H8QkEAOCY2zRTukQ84RYyWVPqPwXZCMJFXXP09khMSacxtQNtuJYJkzLrAyLkMRtQCBNc2ogshA97LNNf6Qv+xKZGUqDDfruuH1YInS5oIgRkhFqdiD3AhQeXfujYQaeVCYltz+Dsqgx9QfCVzBDuFg4giaPwkAsaT/2cuijBcsGGosNP+NzkBinbQmx1EGiSl3EpnqDpsKYkDwh54OUOH1pMRxy09hVIKuA== X-MS-TrafficTypeDiagnostic: DB6P18901MB0102: X-Microsoft-Exchange-Diagnostics: 1; DB6P18901MB0102; 31:qr8mGTAn6ZddvIW86nf+n5ss56GnJLKHYpnDjiAUak67VyFotgloNNHb2Dx2H+QitlwE0P/RbLaSyTetDWIlQsexUZrPISx/mqEcmGyUQF3hsgCgG2pIXgg2SgQX9hWMa1lJ+7vc+NQZQwwpVnmsktWhKku1dbCAhG+CTSsrXDWTG/XoFCqXFO0ol31YSkLnNalbPQe8pmHJ5yPNkYzs8BwFIK1xKREGtLEFeDQ77Wo=; 20:FrZZMPvxbz2vXlswpCtNF6JZpTrdeFEN2Qw8VShJU9WvYGQzmZnEAKKxbIEiefPUvUOTe+YhgO3kRhNdNRO4gzKvaLnkVHDqstRVn4Yz5meRpbF12o8Xub1rfEZ6sLDuyDmeQTvvDaoc+uFkrlk16OxiIH+gC0veWFvvWovahOz8XHknUBkNyKbW4DxCHUFq7UKb4jBHzJiqe7OERRrRC77isWTK64rFMcpZ4RdhRXlfEgOFEjp5zDa4+bfxTkOD; 4:nkJtoSszsMFq7RYWtEipHXmMmWhESZbTAJIAVihitSQ7zWMIyZEMh9CUO1OUagPvzVgUp2PhSOljaIcT6M0RIL06H0THKyXBPvahQS6WL6kvhM70qM1l1h2mKSGtmxobh4gnbXTfEy6Ucj3ZL87oGDZ2xxt5gXfRwz5EU1ONR+efTayxBaCs9U2azi4MZ6J52iwlcwEWI2DPLSvQLeaHpxCFjth7jErJHsrtPyDjPibf0L3PNJlAHEdRPbZa7c77QJNv9tNM0/tCyoRuFuNB/w== X-Microsoft-Antispam-PRVS: X-MS-Exchange-SenderADCheck: 1 X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(3230021)(999002)(6040522)(2401047)(5005006)(8121501046)(93006095)(93004095)(3231475)(944501520)(52105112)(10201501046)(3002001)(148016)(149066)(150057)(6041310)(20161123562045)(20161123564045)(2016111802025)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(20161123560045)(6043046)(201708071742011)(7699051)(76991095); SRVR:DB6P18901MB0102; BCL:0; PCL:0; RULEID:; SRVR:DB6P18901MB0102; X-Forefront-PRVS: 08902E536D X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtEQjZQMTg5MDFNQjAxMDI7MjM6YkJyTUdxVFM2OFNDWnBadmFrNXBjcHdt?= =?utf-8?B?ejIvOGR2aUR3dm9sQmlxZnVyb09Nc2JZcUNQTUk5Q0pjQ2lCUm0zSmlTS1FE?= =?utf-8?B?b2dSNmViSGlrREVmN1NTSzljVUxIOGtqbHVtWjNLUStNVXhCYy93M0hELy9P?= =?utf-8?B?ODBxNDJETk9Da01TMVBHOEhRN1RFVUkxM1RDUExUaUcwdzNJaDljRnhpOWpi?= =?utf-8?B?MStjbmRpdU9OaFNlbGJHOG5JcnFGWmxNUDhGK0pYcERoUHdlT1NCVTFLdGc4?= =?utf-8?B?dVp5REw4UHNnT29KMDNkWVFWS2JDRjRvaUZ4ZzdscnBvWitKZmYzWkJCeGVG?= =?utf-8?B?dnlvQUtKNkMxdWxObTB1V3R6cWV5YXBkWU5oUGZGai9uL3RteUVZZGNZQ2U1?= =?utf-8?B?UmtFejMxVUpnR1dGT3Aybkc4aVJaTmNDVEZDVzVORkw5dW9jdk45N1k2M1po?= =?utf-8?B?UjNCUHlLdEI1VnFrczNvVU5UMXd6VGJiQmdsV3JOQjR3OE1vYyt3amVyMjNr?= =?utf-8?B?VzRMcWhRNTI5Wkd0V2JNTEdmQTZ1c3NkSUFjNzBuRnVxdGgxTlFBdnRDK0xZ?= =?utf-8?B?WWQvcTdYZC9VY1kzYlJoTzNEVFVjREc3KzhCUUxFU2JOY0hSbDBDZGJCNnpy?= =?utf-8?B?SDZSNjBlMWU4Y1hseXdzZ2MveldxSkdmcS8xK1NyOElXb1dvR1VNOUZGN09i?= =?utf-8?B?WEVQdXpXOUNDeS9WZzNaOWFhcVBYUDNBUTd1YXgxeGVRWThnTWgyakVnMng3?= =?utf-8?B?Yk5yT3BESlJlWG5temhNTmMwc1NmaUUvQXhROWZtaUZ5OEo4bVVUMmVKdGZt?= =?utf-8?B?TEx0anF3Q3U2Vmk1Qkk2VjAyM2dZTFhFek1pajlvd0lVcjgzbVlFOCtTWS9q?= =?utf-8?B?ODhrZmNRakROY29qU3ZqQnVjbG1oY294S3A5L05RUHBMTWZCNit4U3pERmtU?= =?utf-8?B?Tnh2YzdzUXZuQ3JyOVRDVVI3YnhxWmZHNDhrN0h0aHZZQmQvNWtFRmRIYXRO?= =?utf-8?B?UTNhaUQvTGxodStyWXowVWMvVlFhVENIUUxzeTRiWXNZSWVyNmFtK3JTb3NJ?= =?utf-8?B?VjJBT29QK0dSSjhkak5ad1llSXlaanRZWDBPTUNlV3dOelJXclNlcllneFNM?= =?utf-8?B?bEVnWkxKek95R0RneFk1ZzJaZTVKbjU0cGNkWGtNSGwwS2sySG44SmJCcjdu?= =?utf-8?B?QlhVK1VKNnl1SFd0UzJqbWVpWG5kcGdSNEN5Smc0b1grT2xaM2REWlIzV0p0?= =?utf-8?B?NWFJZ21VcnNjUzFiOGxMTW9PVXZzMFBONDJKOXRHcWFPdmpDSEdNMnRKZkJW?= =?utf-8?B?d1FLOHY4aUg4eTZHUGxYMXY1SlRDUXJiUzB1dkxjYzF0K3JnSTJQMVpIQVZR?= =?utf-8?B?U2NCZHFMVkMrVXc2dHRuRUM1b0JVNkwyU3pZdzR0SC9TbHFsM3hFTGxuVTM5?= =?utf-8?B?RlBaRVRBTGk0VjZUKzduWThTdWRiaW1KdFpSWE45VWxSMklSejFqRVQwenFa?= =?utf-8?B?SWZ5enNheWRMcm4zbUpqTEFlcEpDYUFQZEl1c1pJaWx4TWZWUXN3UVZIVTVu?= =?utf-8?B?eFUySGlra1FiVU91RHFwYm5QVXRjR0NoRjhMdHNvaDZJb0FyR2ZlY0Q4eE9T?= =?utf-8?B?MmUrQTJxRSt5b2FSejlHTzFwT210THROcFlFQy9kd0FFTysxV0hLcjk3b2M0?= =?utf-8?B?VjNnKzBIVjVIY0dxdHRhOEFBbUI0MGFtenlGZmdyM2IxcnpCWmxKejhxdUE2?= =?utf-8?B?MTZpUGVGaklGcGNIdTVkSDRidTlvYUs2UDhwSHFGT3J2MEpnaVlITEV2YS8x?= =?utf-8?B?S3UwbDJyaEtYbWg2TVJyOGNsMUlYTlVyN1BCdmpzQlVhT0hORkpsbXZWbmhn?= =?utf-8?B?M0NUYVpJN3RYYjJzOFc3RUhEY0hlTzBwbDFiZDh3L0N6dXNOY21vTHR5M2tB?= =?utf-8?B?Ujc2RmVwODIxaFlncVp4Y1o4NzBGbTdXZmdpMHpLelJzZXNWRFY3aGVPZnEy?= =?utf-8?B?WWEyRHNwODhKM1JyQ0FxeTRuVFdiQkx2bHNDelMzdTcxSVcyd2JFMEVXMWpD?= =?utf-8?B?bzJxQm1yRXpzS2RDLy8vTEM2Z3RtcTUzdEZ0RFU4eUlZWEVSS3JLTTBuNTg2?= =?utf-8?Q?IqNc64WfposbrNVkS5xJ7vdgw=3D?= X-Microsoft-Antispam-Message-Info: Wve0vf/Y3u+/KEMaRe+6mYEktZmgOIok+p/S9N4EUAmF3t9FSwGpqvvt3tUpyTYHe1jJju67dyhUTw0SHZrHiBf48HIHxme9ouCtKnFysg3UfDOwFjCzGI8kaVQBVyQqTZECGiRAarLuiVlcmjYagPv3EOO1kjOCqMqSux4SsHPUjhnYSecOiHwImesLvIwvHSNWuQkZOl0FH2w0melFUIhfdmihnTJY/83sIhSKWVCicX5wSdhVOwJgo81qGZ25HKqQaepKMdbOx5ko9KXMAzoZCSdq6e+K9zW4F/GSQ7UsIwvIwOf0HnYoBr18aKv4 X-Microsoft-Exchange-Diagnostics: 1; DB6P18901MB0102; 6:ZIBwS/AqZKQE9gv5AbaKRuZPgoS8SKW6otFwzLPac0FbsbyX6NPJrL6is4KNZ73Wj2onA0N4Z9p9ZMVcbYxzDw7Vo/8jID5qLWcXEJAaiqw45+q1t7+wKWouoGYe9UFGlo2o5/L7377AP58SzPwHwoyPHNq1CRynisnZt2fHzDMFwHtjHZQFVCBzje4kXEaQx6s0+/aEbGNp5iME8yLLl6A3vnhB24cg/+257QS+msEiFNegmKb+A2Nx13OB7BlKehQEiRzo+FazkhpswOOu4hn+JexxYaLALiKx0ZRzqRstmij7J+NG07yfNO/JGUO9R1PY3U465QaZ6T4wPr2MyLWdvu+FkEDIWMw+OpSsf0FkzyVBrSdHEBzeOosfz691rWJ3HQEq4XWIqkfACHuBA5QYVcFo78h5jmi+63xFq75WO38blOAnEEqrWqRNlNoIM7ggSuij8hdSJi1+SEJZ5A==; 5:Ku4Et/NCw+bpasCP7DAaV4QoKKnioIeVBClNUa5DHutsqqq0OljX1BemO5Mj9NMv1c3VQQSJeB2fHipky1pxlTbpbdFAnTP2jPcXxnTJYRNkoDA+8zIN9Q8yavlhICq1N/4HQhSYhQN1SDcnJ3sa6Vm+lcD6xX0+ajB0gBZkv60=; 7:jEyb/+k07Z0Prbgo+8gjAsR1st2aC9+6TWqx33fUv9JzK2nPI+o09Wc9pa2K6OGOgSu9b//4b5XqrFra2TvLP5bqGhXWe44UD7oR/zLbrYu/sKUKkOanQMQNvgZ6Uc2ZAThDqfj879WFrRBVJ4SP/Q== SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Dec 2018 14:38:35.5701 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 27c6e4ec-5a75-4bdf-3d53-08d664f67df2 X-MS-Exchange-CrossTenant-Id: 5a9809cf-0bcb-413a-838a-09ecc40cc9e8 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=5a9809cf-0bcb-413a-838a-09ecc40cc9e8; Ip=[194.218.146.197]; Helo=[mail.ri.se] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6P18901MB0102 Archived-At: Subject: Re: [Ace] Security of the Communication Between C and RS X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2018 14:38:43 -0000 On 18/12/2018 14:51, Hannes Tschofenig wrote: > Hi Steffi, Hi Ludwig, > > ~snip~ > >>> The access information optionally can contain an expires_in >>> field. It would help to prevent security breaches under the >>> following conditions: >> 1. the keying material is valid as long as the ticket, 2. the >> expires_in field is present in the access information that AS sends >> to C, 3. the client checks the expires_in field when it gets the >> access information from the AS, and 4. the client checks if the >> keying material is still valid each time before it sends a request >> to RS. >> >> These checks make sense to me. >> > Are you proposing we make the expires_in field mandatory? If so, why > isn't it mandatory already in OAuth (currently only RECOMMENDED)? > > [Hannes] I would do the check when the field is actually there. > However, it is a good question why it is not mandatory in OAuth. Let > me drop a mail to the list. > > > Now that I got a response from the OAuth working group (in the sense > that I was thinking about the claims in the access token rather than > the parameters in the response from the AS) I think checking the > expires_in field has to be optional since * the expires_in parameter > is optional, and * it only has an advisory nature. > > It is useful to send the parameter so that the client can determine > when to request a new access token (for example, via the refresh > token) but it is not absolutely necessary for the protocol > operation. > > Ciao Hannes Hannes, Steffi's point was (and remains) that if we don't give the client a way to determine whether the token is not expired (except for client introspection), it might use an expired token and old keys to communicate with the RS. The argument if I understood Steffi correctly is that the client's request may contain sensitive data (think a POST/PUT with some significant payload) and that sending it to an RS with outdated keys might be a risk. My take would be that in cases where this is relevant, one would specify a profile where the expires_in parameter is mandatory. Furthermore we should add text to the security considerations describing the issue. /Ludwig -- Ludwig Seitz, PhD Security Lab, RISE Phone +46(0)70-349 92 51 From nobody Tue Dec 18 06:46:58 2018 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 B613E127AC2 for ; Tue, 18 Dec 2018 06:46:56 -0800 (PST) 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 aAABZnUdO-_x for ; Tue, 18 Dec 2018 06:46:54 -0800 (PST) Received: from smtp.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41B7F126CC7 for ; Tue, 18 Dec 2018 06:46:54 -0800 (PST) Received: from [192.168.1.109] (p508A4EFC.dip0.t-ipconnect.de [80.138.78.252]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.uni-bremen.de (Postfix) with ESMTPSA id 2149B209F0; Tue, 18 Dec 2018 15:46:52 +0100 (CET) To: Hannes Tschofenig , Ludwig Seitz , Jim Schaad , "ace@ietf.org" References: <154322421294.8323.8505315870685563404.idtracker@ietfa.amsl.com> <03b601d49191$7d1bb400$77531c00$@augustcellars.com> <945fbebe-659f-ac72-3ab6-8e05447e7c92@ri.se> <1c5b81f3-50ce-be68-bec3-68ce2ff15b43@tzi.de> <4ae4eccd-68bf-18ef-f909-142f8172eca1@ri.se> <81ba3ab4-a9ce-a6fd-fbe6-c36a6fbbd9a5@tzi.de> From: Stefanie Gerdes Message-ID: Date: Tue, 18 Dec 2018 15:46:39 +0100 User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Ace] Security of the Communication Between C and RS X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2018 14:46:57 -0000 Hi Hannes, On 12/18/2018 02:51 PM, Hannes Tschofenig wrote: > ~snip~ > > > Now that I got a response from the OAuth working group (in the sense that I was thinking about the claims in the access token rather than the parameters in the response from the AS) I think checking the expires_in field has to be optional since > * the expires_in parameter is optional, and > * it only has an advisory nature. > > It is useful to send the parameter so that the client can determine when to request a new access token (for example, via the refresh token) but it is not absolutely necessary for the protocol operation. In OAuth, the expires_in field is usually used to inform the client how long the access token is valid. If the client uses the access token in a request after the token expired, the RS will reject the request, which usually is not a big problem for the client. In ACE, AS provides the client with keying material for the RS, which is a completely different situation. If the client does not know how long the keying material is valid, it may use outdated keying material to communicate with RS. The expires_in field can be used to inform the client how long the keying material for RS is valid, if the keying material is valid as long as the access token. The main reason to change keying material from time to time is to avoid that it is compromised. I therefore think that it is necessary for the security of the solution that C knows how long the keying material is supposed to be valid. Viele Grüße Steffi From nobody Tue Dec 18 06:47:58 2018 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 04C9A126CC7 for ; Tue, 18 Dec 2018 06:47:56 -0800 (PST) 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 ZyY5OP2bgU4K for ; Tue, 18 Dec 2018 06:47:54 -0800 (PST) Received: from smtp.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4896A124B0C for ; Tue, 18 Dec 2018 06:47:54 -0800 (PST) Received: from [192.168.1.109] (p508A4EFC.dip0.t-ipconnect.de [80.138.78.252]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.uni-bremen.de (Postfix) with ESMTPSA id A67A3209F0; Tue, 18 Dec 2018 15:47:52 +0100 (CET) To: Hannes Tschofenig , Ludwig Seitz , Jim Schaad , "ace@ietf.org" References: <154322421294.8323.8505315870685563404.idtracker@ietfa.amsl.com> <03b601d49191$7d1bb400$77531c00$@augustcellars.com> <945fbebe-659f-ac72-3ab6-8e05447e7c92@ri.se> <1c5b81f3-50ce-be68-bec3-68ce2ff15b43@tzi.de> <4ae4eccd-68bf-18ef-f909-142f8172eca1@ri.se> <81ba3ab4-a9ce-a6fd-fbe6-c36a6fbbd9a5@tzi.de> From: Stefanie Gerdes Message-ID: Date: Tue, 18 Dec 2018 15:47:52 +0100 User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Ace] Security of the Communication Between C and RS X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2018 14:47:56 -0000 Hi Hannes, On 12/15/2018 04:04 PM, Hannes Tschofenig wrote: > Hi Steffi, > > ~snip~ > > >> I also think that the client must be able to assume that RS' RPK that C receives from AS is also valid as long as the token, unless C has additional information. > > I would think that it is rather unlikely that the RS will change its public/private key pair so quickly. Right? I don't really know what you mean with "quickly". Access tokens may be valid for a long time, depending on the application scenario. Also, RS may already have its RPK for a while at the time when AS generates the access token. RPKs do not contain semantic information and C may not have additional information about the RPK. Therefore, C must be able to assume that the RS' RPK is valid as long as the access token. > >> The access information optionally can contain an expires_in field. It would help to prevent security breaches under the following conditions: > 1. the keying material is valid as long as the ticket, 2. the expires_in field is present in the access information that AS sends to C, 3. the client checks the expires_in field when it gets the access information from the AS, and 4. the client checks if the keying material is still valid each time before it sends a request to RS. > > These checks make sense to me. > > >> Without these steps, the confidentiality of the request data that C sends to RS may be breached, and C may communicate with the wrong RS using outdated keying material. > > Not sure how you came to this conclusion. Why is the request sent by the C to the RS revealed to an attacker when the token expires? I did not refer to the token, but to the keying material for RS that AS provides to C. If it is outdated, it may have been compromised. Viele Grüße Steffi From nobody Tue Dec 18 06:48:49 2018 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 BC90A126CC7 for ; Tue, 18 Dec 2018 06:48:48 -0800 (PST) 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 DT9IW3hQzrNO for ; Tue, 18 Dec 2018 06:48:47 -0800 (PST) Received: from smtp.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37E2E124B0C for ; Tue, 18 Dec 2018 06:48:47 -0800 (PST) Received: from [192.168.1.109] (p508A4EFC.dip0.t-ipconnect.de [80.138.78.252]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.uni-bremen.de (Postfix) with ESMTPSA id 9CAF4209FF; Tue, 18 Dec 2018 15:48:45 +0100 (CET) From: Stefanie Gerdes To: Hannes Tschofenig , Ludwig Seitz , Jim Schaad , "ace@ietf.org" References: <154322421294.8323.8505315870685563404.idtracker@ietfa.amsl.com> <03b601d49191$7d1bb400$77531c00$@augustcellars.com> <945fbebe-659f-ac72-3ab6-8e05447e7c92@ri.se> <1c5b81f3-50ce-be68-bec3-68ce2ff15b43@tzi.de> <4ae4eccd-68bf-18ef-f909-142f8172eca1@ri.se> Message-ID: <637abc12-9c8d-be8a-9d27-ee645cd8a290@tzi.de> Date: Tue, 18 Dec 2018 15:48:45 +0100 User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Ace] Token (In)Security X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2018 14:48:49 -0000 Hi Hannes, I think the text is much better now. Protecting the integrity of self-contained tokens is not sufficient, however. The RS must not only ascertain that the token is integrity-protected but also validate its authenticity, i.e., that it stems from an authorized AS. Viele Grüße Steffi From nobody Tue Dec 18 07:26:15 2018 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 BC00812D4EB for ; Tue, 18 Dec 2018 07:26:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XJgbM9ydcynv for ; Tue, 18 Dec 2018 07:26:05 -0800 (PST) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00087.outbound.protection.outlook.com [40.107.0.87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 908B4129C6A for ; Tue, 18 Dec 2018 07:26:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=QM1KamI6+PW4KuoSUezRcJ/itLE/i8Tpy0o/91L59tA=; b=ZKEy1XinK+Y7nKhX15G0itPWnq8tdGMnT4MtnjwdgLD4kHQxYmeUYXaoqQMhyCVwMdobID4qbOW45PPKdXJ/spmVy/YzRyznLaDseS4jzA30ICKZy4Dkb/v9vpe+FqsQjzqoXfXRRrxckys5jUPtp/aQ+slxm7bdCVWRbvfz/54= Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB1552.eurprd08.prod.outlook.com (10.167.210.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1425.22; Tue, 18 Dec 2018 15:26:00 +0000 Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::e8de:6a41:cbf4:89d8]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::e8de:6a41:cbf4:89d8%3]) with mapi id 15.20.1425.023; Tue, 18 Dec 2018 15:26:00 +0000 From: Hannes Tschofenig To: Stefanie Gerdes , Ludwig Seitz , Jim Schaad , "ace@ietf.org" Thread-Topic: [Ace] Security of the Communication Between C and RS Thread-Index: AQHUlquFKpsKbsbb2kGcq8Jrm430i6WELNAAgABWsZCAABAfgIAACmOw Date: Tue, 18 Dec 2018 15:26:00 +0000 Message-ID: References: <154322421294.8323.8505315870685563404.idtracker@ietfa.amsl.com> <03b601d49191$7d1bb400$77531c00$@augustcellars.com> <945fbebe-659f-ac72-3ab6-8e05447e7c92@ri.se> <1c5b81f3-50ce-be68-bec3-68ce2ff15b43@tzi.de> <4ae4eccd-68bf-18ef-f909-142f8172eca1@ri.se> <81ba3ab4-a9ce-a6fd-fbe6-c36a6fbbd9a5@tzi.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [80.92.114.221] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0801MB1552; 6:RKFBDp8hoiuE8fg/JSYku4qBlMSdVk0PpdQsDcRpV9YqWM+7x4YkleKjr99yFx1DNUB2pfPCy4+T8VgOcjtfshvZN949o68Nc8s/uF5JY4edMXKl696FlbvAb2rRrWipaYkuGhjxPeO8rgHh8q61uZXktOtcGVafNbb1i+09R6m3N4Lm80j9+z/TNVvD9PcwjQx6BO9Ad001tDEC4NODcyXQ659V4MLmcTcWCkJpUiuF6IFpAPLfvLDTm0BgFDFvpfvUE2B05CQgz5s9VM4T4wv09cY+19GbyK53PNzVhEfOxjYeea3Z7cRejzLFoGYs0m4roJ43EzTn3eDpG0hOtmLovM2QZJNynH6+kDTV/nv149QXxbMGFXP1v8oElprR1N2xvO1SWwcXaUXEEqxowAYxtNmqbPzVQ2IhC+Qs3dSN5b1Rhf6TEaNE86xc7QqpmeqTUoQqoL7VFaRJrMz+xQ==; 5:lU7h0oOLBNuqL0uUZfkhagKMtoLE9aEgPdQ2b4dNarLfJ5APrML74C7J/Bwr2pLIph0AoIPM0+zuuLcdixosnhHz1rFzAqpdAg0K92kzCm6aj8/ZXbFesQ+p4+rwJQaZqGql5ESgWPFzHW/ua10o8CCum1xGZDWaX9IqRg2qE0w=; 7:EnjJyHhqUEtnR0I0jzJ1U3n9Tmwh2BS3foevJpot/LGGm4YJiKrUZtsqbs9wQU9CHBGjXJ5pQ3TYkkiVxJrRDbOX6ssdWXdIBkJzdAawUESTOcpVfYk+14pFV8aiC13895LuzoCS9V2xiCsQUuowKw== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 4a2459f3-90e6-4ab0-ed1d-08d664fd1dc0 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(4618075)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB1552; x-ms-traffictypediagnostic: VI1PR0801MB1552: x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(3230021)(999002)(6040522)(2401047)(8121501046)(5005006)(3231475)(944501520)(52105112)(93006095)(93001095)(3002001)(10201501046)(6055026)(148016)(149066)(150057)(6041310)(20161123560045)(20161123558120)(20161123562045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(201708071742011)(7699051)(76991095); SRVR:VI1PR0801MB1552; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0801MB1552; x-forefront-prvs: 08902E536D x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(39860400002)(376002)(366004)(396003)(136003)(199004)(189003)(40434004)(8936002)(68736007)(6436002)(256004)(86362001)(93886005)(74316002)(106356001)(105586002)(14444005)(2501003)(316002)(5660300001)(8676002)(81166006)(81156014)(486006)(110136005)(97736004)(15650500001)(5024004)(476003)(99286004)(9686003)(11346002)(229853002)(446003)(55016002)(6246003)(71190400001)(26005)(76176011)(14454004)(72206003)(102836004)(53936002)(33656002)(2906002)(6506007)(66066001)(305945005)(6116002)(3846002)(25786009)(478600001)(7736002)(186003)(71200400001)(7696005); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB1552; H:VI1PR0801MB2112.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: XEPyFfw0CmFYBJs98c1B0cXCNDCiscn8cxeWHm3GMnVaslKSCUU9Y6qaaZjbIOVxNRZcr7QnCHS5rUIZ6ohuchZZINDHHic1YQiO84g+0mdGdWsrDWPacS8qJuhhi7XV4VKjQAEk/I51pZgkoEDJ/6bvyS4PN6qegu1TK5+22RSLxtyUTXYgaMIankYz8RbU1P8BBkawjcg2CVin1WrTFiDVVNQV0Zo5i49WwuGJsfwmazcnKbWBlGwoIrbHlZ62VZorZUDU/dzNYKa/rKD+Gm28WthheGLP8LxEGUSJ0IyBBnoBrXg45noClyEV0BuN spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4a2459f3-90e6-4ab0-ed1d-08d664fd1dc0 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Dec 2018 15:26:00.7252 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1552 Archived-At: Subject: Re: [Ace] Security of the Communication Between C and RS X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2018 15:26:13 -0000 Hi Steffi, > In OAuth, the expires_in field is usually used to inform the client how l= ong the access token is valid. If the client uses the access token in a req= uest after the token expired, the RS will reject the request, which usually= is not a big problem for the client. > In ACE, AS provides the client with keying material for the RS, which is = a completely different situation. If the client does not know how long the = keying material is valid, it may use outdated keying material to communicat= e with RS. The expires_in field can be used to inform the client how long t= he keying material for RS is valid, if the keying material is valid as long= as the access token. > The main reason to change keying material from time to time is to avoid t= hat it is compromised. I therefore think that it is necessary for the secur= ity of the solution that C knows how long the keying material is supposed t= o be valid. If a client uses either an old key or an old token then the request will fa= il. I don't see much difference here between OAuth and ACE. Adding a note to recommend the use of the expires_in field appears still us= eful to me. Ciao Hannes IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. From nobody Tue Dec 18 07:32:50 2018 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 6AF64130E6B for ; Tue, 18 Dec 2018 07:32:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i482R4zsvdef for ; Tue, 18 Dec 2018 07:32:46 -0800 (PST) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10060.outbound.protection.outlook.com [40.107.1.60]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49AC9130E6A for ; Tue, 18 Dec 2018 07:32:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=sb4oWw1iD3PKJYGZn7OTvVLpbBhVIAgAtBiPZAUBmKg=; b=kmuJjPnQbcj9WUZc3rCj/YFU52fRubCk3MKaxfoR/Brk4uqrUUOnLpfxu0foxuse8NAdcDyET/7kECX7QX59Vc84YvoHQvnj35nP0ah86IXoZf+8IG0QqEEfhdq9IIjAVqKwvyn/9CVTaBtmX5RKPAWd/iX9Hw4dSLu8AvTs9Is= Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB1805.eurprd08.prod.outlook.com (10.168.67.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1446.17; Tue, 18 Dec 2018 15:32:42 +0000 Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::e8de:6a41:cbf4:89d8]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::e8de:6a41:cbf4:89d8%3]) with mapi id 15.20.1425.023; Tue, 18 Dec 2018 15:32:42 +0000 From: Hannes Tschofenig To: Stefanie Gerdes , Ludwig Seitz , Jim Schaad , "ace@ietf.org" Thread-Topic: [Ace] Security of the Communication Between C and RS Thread-Index: AQHUluCo2rYBZxPox06btKUYOKg3d6WEnlqQ Date: Tue, 18 Dec 2018 15:32:42 +0000 Message-ID: References: <154322421294.8323.8505315870685563404.idtracker@ietfa.amsl.com> <03b601d49191$7d1bb400$77531c00$@augustcellars.com> <945fbebe-659f-ac72-3ab6-8e05447e7c92@ri.se> <1c5b81f3-50ce-be68-bec3-68ce2ff15b43@tzi.de> <4ae4eccd-68bf-18ef-f909-142f8172eca1@ri.se> <81ba3ab4-a9ce-a6fd-fbe6-c36a6fbbd9a5@tzi.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [80.92.114.221] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0801MB1805; 6:rs7aklc73J7TQfkwGXxwLXnysyZN4tqzOhpH/0E+IOSdJwnPVwtrz6CPzSUMvFp4+M/MXUwMAmNbIEZUMRuVHD+h6pvZThgOyG/shKnCkYWrgifpvFrLY7ADzwyiLgRWIAhITjDWNgh1OJerkSLT7r24nZZtI4FpZis+9lOmjz75P7cUmtEgbgmn/s5jLqyLesvrncUWMr4QQ1uXxY8B6yy+Ol3Tg/Dv17nET/p1VPWbvFB07d1Zh3Vm4zJ/X95FzCfMPc+rJVGzJbO7hT9EDf+NoBfXHlYi4qTxtnsd+DeemoZxXelZB5WzgLocKKLhoUQIYX8CNUTSRMOtS5dM2RbuNwC9edlz3q4fdRt0E4LAMgxP5wCmW3yAMUE0VioRSimOOfbesgHJqFKAKVO7Y9dBRtQsUpFJEu+or6eONJlIPYcbjpHq5Sbsbtf+ZZCChdh8WsQhev5l7p3iYs0Mmg==; 5:n11qy7IL3kNYx7iv5pzIvwCBtQfD6PcjcCF0Sewmi4gHc8X7Uk4WzoLDrbIMOqudSOLmEgp+p++AAYvFuIfkvwyAPW8hbNWpp7OmJGbCFzJApv9gBTZ2bmnG2RLvaHS89bK37uNpH5agx+HA/kAuEbeT3pJhcHrdEBkyvRZkMX4=; 7:YWUvAkbzfyLxd3SCd4+h6ACTi9Emc2Qt3Rhh644ANs2f9cVJNj6OScOy0bmSqEIH9YeX6orBL+ZTo4o+UQhXrj1C4NnppcaWhe2++C1Y+8CAq6koz2FJh1eyXt3/2J6OLs6oFV0FIyemddvjWOdR7w== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 6c0561e5-9eba-480d-eed1-08d664fe0d13 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(4618075)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB1805; x-ms-traffictypediagnostic: VI1PR0801MB1805: x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(3230021)(999002)(5005020)(6040522)(2401047)(8121501046)(3231475)(944501520)(52105112)(93006095)(93001095)(10201501046)(3002001)(6055026)(148016)(149066)(150057)(6041310)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123562045)(20161123564045)(201708071742011)(7699051)(76991095); SRVR:VI1PR0801MB1805; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0801MB1805; x-forefront-prvs: 08902E536D x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(346002)(136003)(39860400002)(396003)(376002)(199004)(189003)(40434004)(446003)(8936002)(8676002)(476003)(11346002)(14454004)(2501003)(81156014)(81166006)(26005)(7736002)(33656002)(2906002)(486006)(6436002)(106356001)(105586002)(7696005)(74316002)(25786009)(6506007)(5660300001)(72206003)(86362001)(76176011)(97736004)(478600001)(68736007)(6346003)(305945005)(186003)(15650500001)(71200400001)(102836004)(71190400001)(93886005)(3846002)(6116002)(55016002)(53936002)(9686003)(6246003)(66066001)(229853002)(5024004)(316002)(14444005)(110136005)(99286004)(256004); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB1805; H:VI1PR0801MB2112.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-microsoft-antispam-message-info: yjqQcn+hD8II+J/JZ5OxV6otQetruk8864Qm80jDPfY3vdaDExROeZB7WShiu/xUmfaQ5yTzZUkpo7/aCuiWRkrPAT3zcr4qwo9+0qLStysOuxDwu32nBtl6+5tSeLpBdXJJTbsONS8c3X4zpFVmmvGvs22sAca/+dibGwUmCHPM+wThsgHA714qCNHvXAUx+ULsuhLXsD3EsgvzSQIQ2EtYmyEbH4IykiqvCTKJAQSub8UYQp8m0ijTe/4FfxyzLBLT3/8MHmxqcxHeokwS3KmXaa+EHErXVt/uj+paLJeFDoBZD8/Ex+60Z9A3TSE9 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6c0561e5-9eba-480d-eed1-08d664fe0d13 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Dec 2018 15:32:42.2134 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1805 Archived-At: Subject: Re: [Ace] Security of the Communication Between C and RS X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2018 15:32:48 -0000 Hi Steffi, >> I also think that the client must be able to assume that RS' RPK that C = receives from AS is also valid as long as the token, unless C has additiona= l information. > > I would think that it is rather unlikely that the RS will change its publ= ic/private key pair so quickly. Right? > I don't really know what you mean with "quickly". Access tokens may be va= lid for a long time, depending on the application scenario. Also, RS may al= ready have its RPK for a while at the time when AS generates the access tok= en. RPKs do not contain semantic information and C may not have additional = information about the RPK. Therefore, C must be able to assume that the RS'= RPK is valid as long as the access token. >From an AS point of view it would make sense to make sure they hand out inf= ormation to client that actually works. If the token is still valid while t= he information about the RPK of the RS isn't then there may indeed be a fai= lure case. This isn't too bad since the client will then (hopefully) contact the AS ag= ain to get a new access token. We could nevertheless add a note saying that the operator of the AS needs t= o consider these cases and that the client should contact the AS again in a= n error situation. Ciao Hannes IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. From nobody Wed Dec 19 03:26:28 2018 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 2304E1277D2 for ; Wed, 19 Dec 2018 03:26:27 -0800 (PST) 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 LNtm7loAGGzT for ; Wed, 19 Dec 2018 03:26:25 -0800 (PST) Received: from smtp.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED097124BAA for ; Wed, 19 Dec 2018 03:26:24 -0800 (PST) Received: from [192.168.1.109] (p508A4EFC.dip0.t-ipconnect.de [80.138.78.252]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.uni-bremen.de (Postfix) with ESMTPSA id 9D29F20552; Wed, 19 Dec 2018 12:26:22 +0100 (CET) To: Hannes Tschofenig , Ludwig Seitz , Jim Schaad , "ace@ietf.org" References: <154322421294.8323.8505315870685563404.idtracker@ietfa.amsl.com> <03b601d49191$7d1bb400$77531c00$@augustcellars.com> <945fbebe-659f-ac72-3ab6-8e05447e7c92@ri.se> <1c5b81f3-50ce-be68-bec3-68ce2ff15b43@tzi.de> <4ae4eccd-68bf-18ef-f909-142f8172eca1@ri.se> <81ba3ab4-a9ce-a6fd-fbe6-c36a6fbbd9a5@tzi.de> From: Stefanie Gerdes Message-ID: Date: Wed, 19 Dec 2018 12:26:13 +0100 User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Ace] Security of the Communication Between C and RS X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2018 11:26:27 -0000 Hi Hannes, On 12/18/2018 04:26 PM, Hannes Tschofenig wrote: > Hi Steffi, > >> In OAuth, the expires_in field is usually used to inform the client how long the access token is valid. If the client uses the access token in a request after the token expired, the RS will reject the request, which usually is not a big problem for the client. > >> In ACE, AS provides the client with keying material for the RS, which is a completely different situation. If the client does not know how long the keying material is valid, it may use outdated keying material to communicate with RS. The expires_in field can be used to inform the client how long the keying material for RS is valid, if the keying material is valid as long as the access token. > >> The main reason to change keying material from time to time is to avoid that it is compromised. I therefore think that it is necessary for the security of the solution that C knows how long the keying material is supposed to be valid. > > If a client uses either an old key or an old token then the request will fail. I don't see much difference here between OAuth and ACE. The difference is that C cannot authenticate RS with an outdated key. And even if the correct RS rejects the request, the confidentiality of the request may already have been breached, i.e., the damage is already done. C therefore must know how long the keying material is valid. Viele Grüße Steffi From nobody Wed Dec 19 03:36:20 2018 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 B5FED130DFD for ; Wed, 19 Dec 2018 03:36:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R9L3ytL4R9qg for ; Wed, 19 Dec 2018 03:36:15 -0800 (PST) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-eopbgr150052.outbound.protection.outlook.com [40.107.15.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6B19124BAA for ; Wed, 19 Dec 2018 03:36:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=N/lsWTdNv1btYEeZ+XH2nJmcPIxGKrcOHLxvDNKJnfQ=; b=gHW7BoEiEpo4BZ/o7VuLcwW0gP6B8oLxul0nmBI1N5f5CIKWl4pPLUOsYSbAf1vzucv2RLhgw4UqDyzrYXUrX5JL9jgIq30scAx5F6xiHe2j7At9gGnYzVNqzMY7YMHumJGtaFHlR02/91uk5knf2QRd1bjdnFol/sr6mboqcXY= Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB2096.eurprd08.prod.outlook.com (10.173.75.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1446.19; Wed, 19 Dec 2018 11:36:11 +0000 Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::e8de:6a41:cbf4:89d8]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::e8de:6a41:cbf4:89d8%3]) with mapi id 15.20.1425.023; Wed, 19 Dec 2018 11:36:11 +0000 From: Hannes Tschofenig To: Stefanie Gerdes , Ludwig Seitz , Jim Schaad , "ace@ietf.org" Thread-Topic: [Ace] Security of the Communication Between C and RS Thread-Index: AQHUlquFKpsKbsbb2kGcq8Jrm430i6WELNAAgABWsZCAABAfgIAACmOwgAFP8YCAAAFuwA== Date: Wed, 19 Dec 2018 11:36:11 +0000 Message-ID: References: <154322421294.8323.8505315870685563404.idtracker@ietfa.amsl.com> <03b601d49191$7d1bb400$77531c00$@augustcellars.com> <945fbebe-659f-ac72-3ab6-8e05447e7c92@ri.se> <1c5b81f3-50ce-be68-bec3-68ce2ff15b43@tzi.de> <4ae4eccd-68bf-18ef-f909-142f8172eca1@ri.se> <81ba3ab4-a9ce-a6fd-fbe6-c36a6fbbd9a5@tzi.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [80.92.114.221] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0801MB2096; 6:Q7QJmzfbp5h3HtnQ64Xq578jpUrafY7eg/5yoKdbN9YmEK36TS+r2YsqsjamAdgJELeEXr24JYXuMRH9vfA6LDw8kdEvHfzD/srMIygobtlK/f1DLFv8JjEug6QwYWXTLp/OZOUhhnLeRfllll3hS1oLm/z0tlVhHCpZj0jtTwpRDO9QcdZGXxfaAkZ6VKrSvIqk7kdMU3nCIvQEAnBUdDCh67OCvPiquIqq9KP/jMAZaDac9bEQeQ50dQdOesPILuqWvtou6dZiIeU7p5ogkwOEMvgPG+KHPwaLs7DAmEiFhPetTeNs11iXmqVZiYXG7wk7Rd7//Wqqh3Nf2Yx1j4PsfsUY8QpVPG32xbdDKINs4Gw4TasX5aZK6HzSIB+0x9Dlezj6J1MYC3zFtmZYSl8e+/3nOTJc0sJEw8oLXg4MmLp2+/GjiMy9XKoQ6ukbjePg1Y0mFDAJx/gEXWcdYQ==; 5:XjqB/yvKXJcorn0M/YlInYHtpnEQXNLXTsFnKAHIoMgki8enyZY7XEYN+aiungvsHzLp1eqy9YYsy5cI7fhsU2TJ79fBazTvM5fxcHU7K7caHd37DB+0ReOH2rkuio0nmqUpbahh7X9vVOcnxthCG7NS+PN7SyXbbbSdh0pRsYo=; 7:/NcKxH5g45hRMeYFzWFyjzB/A/+d08OE3/HHM8LYrMGVhOV+yR1G/zCTmILpxUthXWhSvX3By6HmZGYuVZrA+tl4pGkNn2I2bA/UkV6nFg+j08khXKuSDMzMerDDU++CV572cuOI8sqa4Z7Iozbr+g== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: ba1af2b2-3a53-4eb7-0b5b-08d665a62d18 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(4618075)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB2096; x-ms-traffictypediagnostic: VI1PR0801MB2096: x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(3230021)(999002)(5005020)(6040522)(2401047)(8121501046)(3231475)(944501520)(52105112)(3002001)(93006095)(93001095)(10201501046)(6055026)(148016)(149066)(150057)(6041310)(20161123562045)(20161123560045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(201708071742011)(7699051)(76991095); SRVR:VI1PR0801MB2096; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0801MB2096; x-forefront-prvs: 0891BC3F3D x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(346002)(39860400002)(376002)(396003)(366004)(13464003)(199004)(189003)(40434004)(105586002)(106356001)(15650500001)(110136005)(25786009)(97736004)(476003)(11346002)(2501003)(8936002)(316002)(66066001)(9686003)(446003)(55016002)(5024004)(14444005)(2906002)(186003)(256004)(68736007)(486006)(14454004)(71200400001)(71190400001)(6506007)(74316002)(102836004)(53546011)(76176011)(33656002)(7696005)(7736002)(229853002)(72206003)(99286004)(81156014)(81166006)(26005)(6246003)(8676002)(6436002)(53936002)(478600001)(3846002)(86362001)(305945005)(6116002)(5660300001)(93886005); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB2096; H:VI1PR0801MB2112.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: G4tJ+VBmIi6fhqvIY403PFe8bxMfPEwF7ueH9KdfRKW9XaYk2ymMYQLgT7Vx1zFMuOZEDybsUGcx2AJqHlJUzpzEJiZVm6w8/njyDyN1CI5eioLq53zgnwPn8sUTvj+sEZW3xEF2DRRk7hbpnMqCV62U8rjJ+lS6oFk4L80v5Z/E7y73263kqd++BuJoPMiot4BcBkruYb2qGA9lZ/Vz2Ca3sW6HvD5PpvueICiTRhv4tT6sCy/q1/LRxGrGhFOGXmdbBaJNSlL3GQN9lp5zvu3todatJd/pNiSNlDoK4v4fmqj+2SN7c+9OjBZvz7eD spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: ba1af2b2-3a53-4eb7-0b5b-08d665a62d18 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Dec 2018 11:36:11.3937 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB2096 Archived-At: Subject: Re: [Ace] Security of the Communication Between C and RS X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2018 11:36:19 -0000 Hi Steffi, Are you focused on token expiry or the case where a token + symmetric key h= as been leaked? Is the threat you are describing the case where the client uses DTLS/TLS wi= th the RS (potentially long after a token has been presented), or the case = where the client contacts the RS and presents a token? Ciao Hannes -----Original Message----- From: Stefanie Gerdes Sent: Mittwoch, 19. Dezember 2018 12:26 To: Hannes Tschofenig ; Ludwig Seitz ; Jim Schaad ; ace@ietf.org Subject: Re: [Ace] Security of the Communication Between C and RS Hi Hannes, On 12/18/2018 04:26 PM, Hannes Tschofenig wrote: > Hi Steffi, > >> In OAuth, the expires_in field is usually used to inform the client how = long the access token is valid. If the client uses the access token in a re= quest after the token expired, the RS will reject the request, which usuall= y is not a big problem for the client. > >> In ACE, AS provides the client with keying material for the RS, which is= a completely different situation. If the client does not know how long the= keying material is valid, it may use outdated keying material to communica= te with RS. The expires_in field can be used to inform the client how long = the keying material for RS is valid, if the keying material is valid as lon= g as the access token. > >> The main reason to change keying material from time to time is to avoid = that it is compromised. I therefore think that it is necessary for the secu= rity of the solution that C knows how long the keying material is supposed = to be valid. > > If a client uses either an old key or an old token then the request will = fail. I don't see much difference here between OAuth and ACE. The difference is that C cannot authenticate RS with an outdated key. And even if the correct RS rejects the request, the confidentiality of the = request may already have been breached, i.e., the damage is already done. C= therefore must know how long the keying material is valid. Viele Gr=FC=DFe Steffi IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. From nobody Wed Dec 19 03:46:30 2018 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 93E29128CF2 for ; Wed, 19 Dec 2018 03:46:28 -0800 (PST) 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 llMrEdVYDZ7Q for ; Wed, 19 Dec 2018 03:46:27 -0800 (PST) Received: from smtp.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7B9212426E for ; Wed, 19 Dec 2018 03:46:26 -0800 (PST) Received: from [192.168.1.109] (p508A4EFC.dip0.t-ipconnect.de [80.138.78.252]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.uni-bremen.de (Postfix) with ESMTPSA id 5308020545; Wed, 19 Dec 2018 12:46:25 +0100 (CET) To: Hannes Tschofenig , Ludwig Seitz , Jim Schaad , "ace@ietf.org" References: <154322421294.8323.8505315870685563404.idtracker@ietfa.amsl.com> <03b601d49191$7d1bb400$77531c00$@augustcellars.com> <945fbebe-659f-ac72-3ab6-8e05447e7c92@ri.se> <1c5b81f3-50ce-be68-bec3-68ce2ff15b43@tzi.de> <4ae4eccd-68bf-18ef-f909-142f8172eca1@ri.se> <81ba3ab4-a9ce-a6fd-fbe6-c36a6fbbd9a5@tzi.de> From: Stefanie Gerdes Message-ID: Date: Wed, 19 Dec 2018 12:46:24 +0100 User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Ace] Security of the Communication Between C and RS X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2018 11:46:29 -0000 Hi Hannes, On 12/19/2018 12:36 PM, Hannes Tschofenig wrote: > Hi Steffi, > > Are you focused on token expiry or the case where a token + symmetric key has been leaked? I am talking about the expiry of the keying material for RS that AS provides to C. > > Is the threat you are describing the case where the client uses DTLS/TLS with the RS (potentially long after a token has been presented), or the case where the client contacts the RS and presents a token? I am worried about cases where the client communicates securely with RS, e.g., using DTLS/TLS or object security, not about presenting the token to RS. Viele Grüße Steffi From nobody Wed Dec 19 04:21:58 2018 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 D0A70130DFC for ; Wed, 19 Dec 2018 04:21:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.701 X-Spam-Level: X-Spam-Status: No, score=-1.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=risecloud.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p7uE3Af0VY-P for ; Wed, 19 Dec 2018 04:21:53 -0800 (PST) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20052.outbound.protection.outlook.com [40.107.2.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B025130E05 for ; Wed, 19 Dec 2018 04:21:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=RISEcloud.onmicrosoft.com; s=selector1-ri-se; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=OUdYaDUpexC2hQu1SRUmBs17IRExNyEvsaVD+SSlXNs=; b=Gz3TZWhoJzsIkPqg0liOLNhuv14W2/omnTVi4ylTZrE6AIZCiYtSI4sW2GoBXMM0SZycN+SKZ5IpQtJsBK6OXL45DhYdpQ8v0UDiWwwweaTi51FwGY/pwf0CM1S8fwTv7UY5rmdWsbLSoTKUxKa1nLESMItgyHCpYy4mrLjMpbQ= Received: from VI1P18901CA0004.EURP189.PROD.OUTLOOK.COM (2603:10a6:801::14) by AM5P189MB0468.EURP189.PROD.OUTLOOK.COM (2603:10a6:206:21::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1425.22; Wed, 19 Dec 2018 12:21:50 +0000 Received: from VE1EUR02FT017.eop-EUR02.prod.protection.outlook.com (2a01:111:f400:7e06::203) by VI1P18901CA0004.outlook.office365.com (2603:10a6:801::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1446.19 via Frontend Transport; Wed, 19 Dec 2018 12:21:50 +0000 Authentication-Results: spf=pass (sender IP is 194.218.146.197) smtp.mailfrom=ri.se; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=ri.se; Received-SPF: Pass (protection.outlook.com: domain of ri.se designates 194.218.146.197 as permitted sender) receiver=protection.outlook.com; client-ip=194.218.146.197; helo=mail.ri.se; Received: from mail.ri.se (194.218.146.197) by VE1EUR02FT017.mail.protection.outlook.com (10.152.12.98) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.20.1446.11 via Frontend Transport; Wed, 19 Dec 2018 12:21:49 +0000 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_128_CBC_SHA256_P256) id 15.1.1531.3; Wed, 19 Dec 2018 13:21:49 +0100 To: Stefanie Gerdes , Hannes Tschofenig , Jim Schaad , "ace@ietf.org" References: <154322421294.8323.8505315870685563404.idtracker@ietfa.amsl.com> <03b601d49191$7d1bb400$77531c00$@augustcellars.com> <945fbebe-659f-ac72-3ab6-8e05447e7c92@ri.se> <1c5b81f3-50ce-be68-bec3-68ce2ff15b43@tzi.de> <4ae4eccd-68bf-18ef-f909-142f8172eca1@ri.se> <81ba3ab4-a9ce-a6fd-fbe6-c36a6fbbd9a5@tzi.de> From: Ludwig Seitz Message-ID: <9f35177f-30d4-817e-dfc3-9a54903ab023@ri.se> Date: Wed, 19 Dec 2018 13:21:48 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit 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-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:194.218.146.197; IPV:NLI; CTRY:SE; EFV:NLI; SFV:NSPM; SFS:(10009020)(39860400002)(396003)(346002)(136003)(376002)(2980300002)(189003)(199004)(106466001)(31686004)(68736007)(186003)(16526019)(36756003)(77096007)(336012)(50466002)(76176011)(16576012)(22746007)(316002)(26005)(64126003)(8936002)(104016004)(22756006)(74482002)(8676002)(6246003)(2870700001)(386003)(53546011)(33896004)(81156014)(81166006)(69596002)(58126008)(110136005)(65826007)(305945005)(47776003)(5660300001)(7736002)(67846002)(2501003)(93886005)(65806001)(15650500001)(65956001)(117156002)(2906002)(53936002)(106002)(3846002)(229853002)(486006)(2616005)(86362001)(6116002)(44832011)(476003)(31696002)(126002)(11346002)(23746002)(40036005)(97736004)(356004)(508600001)(14444005)(446003); DIR:OUT; SFP:1101; SCL:1; SRVR:AM5P189MB0468; H:mail.ri.se; FPR:; SPF:Pass; LANG:en; PTR:InfoDomainNonexistent; MX:1; A:1; X-Microsoft-Exchange-Diagnostics: 1; VE1EUR02FT017; 1:g3SFT0wyE1D/7/PmesLNWPOQXyS9yqJPA6hfNryFLlSZ3U6RHmgVGchK6NGkUF8zrg2yJcpPcVWDSsouSGMKUoZKDrLZFRUiluSlkR1n9ge3hx42plDm469fdzINpg1/ X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: d132d343-2800-4d55-6b91-08d665ac8d76 X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600074)(711020)(4608076)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:AM5P189MB0468; X-Microsoft-Exchange-Diagnostics: 1; AM5P189MB0468; 3:WlC/VLZaliOWIImOmH96mFfc0ZEvAccN5iU4kinq9rsmW8wvL7oBJ9FAIoSLLDP33S2AJR+uQQewyu9brtBRBGZMN+0+v62r1UPKhmXVwIxk2ntS48za6k+MCjHWIJ5A9lXBKiIMPs8oJPv+LXuquh0a7h54Mkr6BsQStQMiI2MN4JvXFoo47aydOhjDyEn7aROdSVxqRdJzYLbfTSrIE9oWM5/hfiwtjrjKTH8aEIiKl82DfLSX3Z09f+28PtRiXih1v930infmUOYUktc4t6yJis353cO3pOrofIjR9N3BUMdegja5N3Jm6HOsXDPxX3yFI5zKxtzoRu1WIJ0DM6dzTnRFnFNQyaK6tJo8WNw=; 25:zvDfyMlFUavtwC1rUbrKWbdQLioo0PD+nFibTXDDsAQpswikOSIKEcpMhg60WxRCXoakHcLakQIvnB/WxErWnQzLUG51GVZXiH7KPNbRkm5qGqGb6tSvTdWt9H4APviCv3LZx3a4ILSHE79wfdrTZ5+gf65C0TU3s8BwV+pnzNvnvWOokhI+vec78GNbdeRYrLMUKkIgUKjeHVvgeI+3fJCvhjH7/7xxQ7uiXhAglq/72sG/10o9IpDmZFW35AXu078rXsJjllleXimWndRYqpcVL99P32cVGf9VYZOnPL7F1zIAD/rRCvRACB5dSvyB5H9U9rCsSFq+xbUF1J+FsQ== X-MS-TrafficTypeDiagnostic: AM5P189MB0468: X-Microsoft-Exchange-Diagnostics: 1; AM5P189MB0468; 31:DUjUh84edjiro94G/IWhRxXVhiTDENDdJTQGgWN6ut3UpaZxY54jx6gGYpsDz/XsRrUZvSUKk7U6cF7Ypl4tejXfJ6kTgsqeZuMFnKim9ddKVOPwuUH84ChGv7dmdKamWwzanm3QRXIkyt72n/zjKfvoBBsyDlR61xKbJyLH9RzqTjDEX/Yfuk5reOEtKte2syWdlk3/E8jYzd4FjJKD67j/Yop7qdGFQhfN4yFh3CY=; 20:VYSTzGcgj8fc0/vkf03CzL6hb3tSEaTNudVaxORi5Y4fjgK8BbwwsrJUyFem+WRSkTVe4Ws0EgiA4bFFCMLCjMw33ifEhDJ+YcnV9r7P1lEBDVeBXMVmjWIaImj9ZUtcmeBi9ZnXwZSfjtqhcRyJShSciDIGbKRz3H6XBNFTzGdWqwY/JqevGGSIgaD8/taojvi2qUnl5wohR6iJZd03pik5cOk0WpzFn5W8V5qCeJG7tDuC3SWen+N/Je3l88qz; 4:9OVJb4E9W6VtwTyWz8bG0Ozv+rTMNLGDqHAg9hhp8ucmMAy9f9n6O5HLvcdIl1jha7e5Sa6W0fFPN4ADif1uo4ezT0A+Xi3VCMgr7FqYTZe+9p7evHBlJVmuw0aw4spQDWuyJZJS5jfyDUIPlZ88j3m9rgJAN/4bepD9zkce6nj3TVLJ9q3t0eIaXA/rBIqGO4Nh7CYKbmVQzThzvqqMvJxEtxx0BdZ2jCaKYCkWNn0tlgnwsFjB6FX0pikY9w7zOGHF1AmvmTXAnMEifi5O6g== X-Microsoft-Antispam-PRVS: X-MS-Exchange-SenderADCheck: 1 X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(3230021)(999002)(6040522)(2401047)(5005006)(8121501046)(3231475)(944501520)(52105112)(93006095)(93004095)(3002001)(10201501046)(148016)(149066)(150057)(6041310)(20161123562045)(20161123564045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(20161123560045)(201708071742011)(7699051)(76991095); SRVR:AM5P189MB0468; BCL:0; PCL:0; RULEID:; SRVR:AM5P189MB0468; X-Forefront-PRVS: 0891BC3F3D X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1; AM5P189MB0468; 23:FBXgTXMB+r/hovq6jfCi42Bjb1vZYd/VEyf9T?= =?Windows-1252?Q?TDbCLbl0/92wonqoYN7Z1t10Q2V2pmwhlggCa6pw55Dv/4duBA+Eo6YX?= =?Windows-1252?Q?dUb4Z3cxCouuU66L67SZfDzZv1asNa4oog9toQbtDcFnMG60nvH7yLVc?= =?Windows-1252?Q?sfLZji3iTck39anWxVQ4NMD73DjkqNWXIrtYygWHo344TVSjngxphi/n?= =?Windows-1252?Q?Bz68EAT0Qqi4S4PNH7Stkdw2uNOkUh5KJ2lCDOzZijYTOarjplYDMLbN?= =?Windows-1252?Q?/YgKJPRFMb4mzkplVA8OjHIR8ZJrU8dRqOjo4/hecFNtAf4XiMxQbwWs?= =?Windows-1252?Q?HyDyayZhledBmyyFbVGbFqhMYM5LMRkYGavtBOJwddsC471eUmGNTY/n?= =?Windows-1252?Q?3ZWVfdUKJ6B8nFRLH8RX2zyykFTyQxrhZUrFm/OHVDKq3ZViVs3Wqowi?= =?Windows-1252?Q?2At7SFuNGJUS1goTv1qWymBg/Bw+Vxh2TzAPRTfm1QaiB59N5zjfETgA?= =?Windows-1252?Q?+UUI9yZuYODyhzowzJd/5sJeac5UdoLLzatrM8o5Z7iSNK1JF5CIpCtD?= =?Windows-1252?Q?PGt4Z6XxwLPQmP0W21YZldzEvEwRJaanvaIJVG+kD2Z6JVWzY5Wi4UfD?= =?Windows-1252?Q?Jt7N/BgV5eMH79qyieFpuZBSwQxrru5huVzFX2FYLxusI2otTscZqj2W?= =?Windows-1252?Q?DkcYQrTDbm7Q70/9+NBhlcfDlk3Xt8IZiqoGvdSobNoxfBguqfCFSwNp?= =?Windows-1252?Q?0IC6C8auFHld/bhty0GZzDcYEIEv3ORjrrVV0UCgJ+aaRkSqrD9Sk70Z?= =?Windows-1252?Q?3IbizK5SgziKgNz+vdhJhLDnyabvBwvFgcjd/tL+virLWDZy8AdwcadB?= =?Windows-1252?Q?WW24Fc2L9nFyBU9HWJ/PrDupbZF3x86O8sTK/nO42WIX7bmhu5/Auumk?= =?Windows-1252?Q?uvJkDDnzdYcnbSIGX3MpEO94uLZ3quH4NKR0gi31e2AyUBJyNvUZJtZz?= =?Windows-1252?Q?sw1bgoh/l6fyCpMS8P+SwG2sDXkMrTDpODNXSQnj8vpThxX9lywYtJCr?= =?Windows-1252?Q?R5f7SE5RRtGksRbK9m9hA8C5Vxp00b7qykxy/zCgftniERxBS94ehsNC?= =?Windows-1252?Q?PMmATIe+k11W3QdBe//qPyj6rY3lZbHKbwHw9qT9asg0V02Ebqkviorf?= =?Windows-1252?Q?Z79gu6dHJzCiyMG61UQTdflRCj/ttreUs43lNYy+3zBVKaOLVIs6kjma?= =?Windows-1252?Q?75dQUpDZB37LjDW7mRgsMXlFNuArwQJpmiPrzl5b4mA2bkLyYcDmqlmX?= =?Windows-1252?Q?dfiasHOz52BHrNxR26gE356LeNWrQ9QvD5y55gJE1PPaoPaTp7eGF2cZ?= =?Windows-1252?Q?9yO1afvPvayNKEqD3vcpq6gGmmDtlCr7RhDtxKAGTCDENAupNPpB5gFB?= =?Windows-1252?Q?KkEf6m46yWqq8pdBtbMFAggk+4/jYjsZ2gmjHHKQGtrRtY5itEHrR8rW?= =?Windows-1252?Q?EXbcXLBcWxl7deJ8EccRDK3ST/NoToRl7QlOyO+dCZ2jZqwpgS+znNNS?= =?Windows-1252?Q?xwxpYMoOwRpPt+ZanGw5VRdXDCAv7yjy3LJU38sU9hHMd7qfKU9HZiOF?= =?Windows-1252?Q?LeZ8ce+mVSzGlhWY0ROmAEyJ5G+Cz1Gx1QsFiPxy7ZqrbkmdsdM68r9e?= =?Windows-1252?Q?UpANhr8QREQpK2uv37emWSnnnmr8V0=3D?= X-Microsoft-Antispam-Message-Info: ASlkPez61ntIG606m0X6SMQNK16r/8XADfmwW4gBA+RwCv0Ja5cN3KDPl6r7bV/mOFEpjCVCfVAsK93eZitA/eViz/xrL068uxlp0H8kyr9N2VpnOa1GGS9kuEsYuEZ8zc2E81G3BmKMULk/UjZ8xGLa45yMj6Xts7gHeFe+YIcv/qIgskHIM/6bw0t7/w2Zjr+wcqVBUONQBhIgBFcalPFoI8NHls/N3YdkpriVq7S9ftILP95sZyE2i1Mld0OueRx/xqiqzOpGHELrzSoaFnUyUkPivLTjXtOF3+uPAi0Yyf5VEIpwTIiZ+H8d7692 X-Microsoft-Exchange-Diagnostics: 1; AM5P189MB0468; 6:5VKYvhPGb0IDxc5jpxiIS2tnbyMKWX6OBZusPOa8ZwoGdmdwGi8PLqO4gzTw+J0kf7JL8KOhuf8dEW8fvd5WL3cMnYP1ZZyMB0BS8poN1hiL8R6d3nuXiVdEA8b6HB65QOAVm5FLHeEA5nRg+v+L+mzelz23qoQLIkP8TH8dgiXPUJpWJirIn5qivA+hPvItTpLFm+VkN4pxBsi7gyUPuHlXIYz/Xqi04mb0gu/uRgYhs7RJFn5/LhDI6gzR3c0wHK6YZ1P3grNKQ/RxenKTOnA4MVChCGJdMMGbOuWd9OT9JDuPIAX97KTG5HGoto6GMxHs7Y4GQblZZkYWTPRwTy4zJmSqYoZi+YoUG+Ks7ejJ/b2qWQsD3re1ivU9Vk8qXcVI93TGpK4serPzEt1q+zaWiXXVJuYZzTRPWUFGrbyGvrCWcdfbR6eR7YOyyYj+5zUFB5CeKOHRo7+34dZAgQ==; 5:x3GapvUzGmZISz3ifYMMR1qw//+B3+/AJlIUfAk4e0scJ7NVZA+jM2sTJrSypXG37BKnUCFtay0WjP1Dya8fYbLpE1fFQHrLq4WcP9Aacu8MCpVMfNZScgNzLPymKqyEo3S8q8GOk7YUC4UHehESk5VrQ4DcHkpg2WJCjkIhXMc=; 7:e4yjaFYjhteyhyNjMZhZs2OBmoVYLZZEVAtZoUKXPLSKD2wJAqIcwB0p70V3Bjw3DslVSZvtu3oFbGAnUnIncBaY68jkK2TA0APdVFRtzmHlTJLYflQzPdxmrwgUMZMVAAhYk8JvCgqMszHZWtYfWA== SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Dec 2018 12:21:49.9913 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: d132d343-2800-4d55-6b91-08d665ac8d76 X-MS-Exchange-CrossTenant-Id: 5a9809cf-0bcb-413a-838a-09ecc40cc9e8 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=5a9809cf-0bcb-413a-838a-09ecc40cc9e8; Ip=[194.218.146.197]; Helo=[mail.ri.se] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5P189MB0468 Archived-At: Subject: Re: [Ace] Security of the Communication Between C and RS X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2018 12:21:57 -0000 On 19/12/2018 12:46, Stefanie Gerdes wrote: > Hi Hannes, > > On 12/19/2018 12:36 PM, Hannes Tschofenig wrote: >> Hi Steffi, >> >> Are you focused on token expiry or the case where a token + symmetric key has been leaked? > > I am talking about the expiry of the keying material for RS that AS > provides to C. > >> >> Is the threat you are describing the case where the client uses DTLS/TLS with the RS (potentially long after a token has been presented), or the case where the client contacts the RS and presents a token? > > I am worried about cases where the client communicates securely with RS, > e.g., using DTLS/TLS or object security, not about presenting the token > to RS. > > Viele Grüße > Steffi > The scenario Steffi is thinking of is this (if I understood correctly): 1.) C obtains token and pop-key from AS 2.) C transmits token to RS and sets up secure communication (e.g. DTLS-PSK) using the pop-key 3.) C sends secure requests to the RS 4.) token expires, an attacker manages to get hold of the pop-key 5.) C continues to send requests containing sensitive information to the RS , attacker can now read the messages and spoof positive responses from the RS. C never notices that the token is invalid and that it is actually talking to the attacker. A reasonable way to prevent this is to give the client a way to determine whether a token has been revoked or is expired. This former can be done through some form of client introspection, the latter can be achieved with the expires_in parameter. /Ludwig -- Ludwig Seitz, PhD Security Lab, RISE Phone +46(0)70-349 92 51 From nobody Wed Dec 19 04:32:54 2018 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 366E4130E05 for ; Wed, 19 Dec 2018 04:32:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.891 X-Spam-Level: X-Spam-Status: No, score=-1.891 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=iotconsultancynl.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6cbScsn5yDsd for ; Wed, 19 Dec 2018 04:32:49 -0800 (PST) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0708.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe02::708]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDCF1130934 for ; Wed, 19 Dec 2018 04:32:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iotconsultancynl.onmicrosoft.com; s=selector1-iotconsultancy-nl; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=NNNINAV2tm5ymzowT+epYSK25W0IUwSlTBWj6p9PeY0=; b=GVqQqmhcyTqtlpHFRbmHeu68niTUt+R1HZBWvAGZChMyRKXQ4lxydY4c+axGbaCqWA0UF6oU5N3ZUPrKpDlUTl1l5GtsUnYZhfnxH2rnolp5V5ujDNPqzRNfUdQ82YOAodHcOX9i3wC0TqzVEd0g2hK4gj0x9vLxWt2W9vcpVT4= Received: from DB6P190MB0054.EURP190.PROD.OUTLOOK.COM (10.172.229.12) by DB6P190MB0040.EURP190.PROD.OUTLOOK.COM (10.172.229.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1425.22; Wed, 19 Dec 2018 12:32:46 +0000 Received: from DB6P190MB0054.EURP190.PROD.OUTLOOK.COM ([fe80::f038:57aa:1670:ce58]) by DB6P190MB0054.EURP190.PROD.OUTLOOK.COM ([fe80::f038:57aa:1670:ce58%4]) with mapi id 15.20.1446.018; Wed, 19 Dec 2018 12:32:45 +0000 From: Esko Dijk To: "Panos Kampanakis (pkampana)" , "consultancy@vanderstok.org" , 'ace' CC: Jim Schaad Thread-Topic: [Ace] Review draft-ietf-ace-coap-est / Removal of CBOR-wrapped ASN.1 ? Thread-Index: AdSXldpWfG6IR1JpTXSGzgfVoQarBw== Date: Wed, 19 Dec 2018 12:32:45 +0000 Message-ID: Accept-Language: en-US, nl-NL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=esko.dijk@iotconsultancy.nl; x-originating-ip: [2001:1c02:3101:4800:7c25:50ad:1ce8:55a8] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB6P190MB0040; 6:AWrRxsMBEktSSRcC6lkyxIfc1ZarWjJcuym3ehFMwQFU7wWXeJ4v9xgxZk/TVOCEFppw6WsVCLduw7gC3sZeEC231X3yBWvnvrGL/+2aoNSE9fEWeRIURSeFqK4EgT29PruyT8YSl2vBALcVoaM3/RN2YSvavoE3zsPVNU/rOroTL3DrD9IlfunHp4MEqw40BQB5y9p3dE5ECe27FNBZHCHfsSakmPqUvCPVhN2BKoGSIVBK+WCjRqP6c9fCAi6YA4vXbwEcPqDucVHBdSWAsCX+1nLPEnMGgcFjNkVXkTcDQ0Z006gSHBqOrOWhCqmVuFE3gkrTXqPodzy8t4DzpodGeenind+mUDiJnBsOlwCoMI4SZhfeCLnNFPo+ypauanq7x6pEj1NAlVLm1KuX/Gx0u0sDiJtiAk2ox67TwucGkt4/GjpYH/0QtzT75QydfCQ0ByohuqzofcB5SQfWBQ==; 5:LterDomB1bGMZ78Q4imKLdslWXNB3GXhlzkzReKLM1Os9C3Z/DZdgzoGqn1RvNIT+0ldj2jxG4sp/UrtGumIbEBzi7H/DWVCc7u07cPxPcU3H/HLF6wnF2p66c0qsaYwrHkF84PgRTO+UwfLEqFd2L4LmSPte/zVLc6rNKILm9o=; 7:u9SybrWB9c0z6fGXM6fKAWfv374gtKiuPKNZLMsXbhpfKbONd2CNI+eu2oaGz0wHmZP0YAc6I3NZAQzEeZco0yRJn0OBVwkDs9ynsp+trg3EUZQyPIlKIJMMAXFddu8P+uBN4eWGBPE7DO2cErdyEA== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: aff325ec-f7d9-411b-037a-08d665ae145b x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(7021145)(8989299)(5600074)(711020)(4534185)(7022145)(4603075)(4627221)(201702281549075)(8990200)(7048125)(7024125)(7027125)(7023125)(2017052603328)(7153060)(7193020); SRVR:DB6P190MB0040; x-ms-traffictypediagnostic: DB6P190MB0040: x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(3230021)(999002)(5005020)(6040522)(2401047)(8121501046)(93006095)(93001095)(3231475)(944501520)(52105112)(3002001)(10201501046)(148016)(149066)(150057)(6041310)(20161123560045)(20161123558120)(20161123564045)(2016111802025)(20161123562045)(6043046)(201708071742011)(7699051)(76991095); SRVR:DB6P190MB0040; BCL:0; PCL:0; RULEID:; SRVR:DB6P190MB0040; x-forefront-prvs: 0891BC3F3D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(39830400003)(376002)(366004)(396003)(136003)(199004)(189003)(13464003)(51444003)(14454004)(33656002)(256004)(4326008)(74316002)(14444005)(2906002)(99286004)(44832011)(305945005)(966005)(110136005)(316002)(86362001)(7736002)(5660300001)(508600001)(486006)(7696005)(81166006)(71200400001)(6436002)(81156014)(476003)(68736007)(6116002)(8936002)(53546011)(6506007)(25786009)(53936002)(229853002)(186003)(6246003)(105586002)(2501003)(106356001)(102836004)(46003)(345774005)(8676002)(71190400001)(74482002)(55016002)(9686003)(97736004)(6306002); DIR:OUT; SFP:1102; SCL:1; SRVR:DB6P190MB0040; H:DB6P190MB0054.EURP190.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: iotconsultancy.nl does not designate permitted sender hosts) x-microsoft-antispam-message-info: 3LUb61h+jd61WaOFwmgl1irL/D9RQrrGmde/PSOqfYrivLm+HXuUL1rMXnumFtwAhnj72LCcCsFqasg6SPL8hjaNsQ1vcmkgC2pLey7ciUDsk/KhuN0pGYBSKVteWEYpnYvG2NyrJjUPnyOST9Tg9AjB3b1MbJvATFpp6OSCsoMT0/Lw3Pkgi6kT244E7T6KaISpbhDeGU8p831uF+VUSmpPYmVMjHoc20wCxbeBOKSipgyuUNjL3Ke/HSD8rsvvKLBasvZhzPd4e6DJ3FnQhzRd3sbYyRviYyaG9fTYtmYbc7H3E4bEiZp4EQTGmBsN spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: iotconsultancy.nl X-MS-Exchange-CrossTenant-Network-Message-Id: aff325ec-f7d9-411b-037a-08d665ae145b X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Dec 2018 12:32:45.8426 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 58bbf628-15d2-46bc-820b-863b6774d44b X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6P190MB0040 Archived-At: Subject: Re: [Ace] Review draft-ietf-ace-coap-est / Removal of CBOR-wrapped ASN.1 ? X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2018 12:32:52 -0000 RGVhciBQYW5vcyAmIFBldGVyLA0KDQpPbiBKaW0ncyBmaXJzdCBwb2ludCBmb3Igc2VjdGlvbiA0 LjEgYmVsb3cgKGNvbnRlbnQgZW5jb2RpbmcpIC0gd2lsbCB0aGUgQ0JPUi13cmFwcGVkIEFTTi4x IHBheWxvYWQgYmUgY2hhbmdlZCB0byAicHVyZSIgQVNOLjEgcGF5bG9hZCBmb3IgdGhlIG1lZGlh IHR5cGVzIHRoYXQgYXJlIG5vbi1tdWx0aXBhcnQ/DQpJIGFncmVlIHdpdGggSmltIHRoYXQgdGhl IENCT1Igd3JhcHBpbmcgaW4gdGhpcyBjYXNlIGlzIG5vdCBuZWVkZWQgKHNpbmNlIHRoZSBDb0FQ IENvbnRlbnQtRm9ybWF0IC8gbWVkaWEgdHlwZSBpZCB3aWxsIHRlbGwgdGhlIHJlY2VpdmVyIGhv dyBpdCBpcyBlbmNvZGVkIGFueWhvdykuICBBbHNvIGl0IHNlZW1zIGhhcm1mdWwgaW4gdGhpcyBj YXNlLCBzaW5jZSBhbiBleGlzdGluZyBDb0FQIG1lZGlhIHR5cGUtcGx1cy1lbmNvZGluZyBpcyAi b3ZlcmxvYWRlZCIgd2l0aCBhIHNlY29uZCBlbmNvZGluZyBpZiB3ZSBhbGxvdyB0aGUgQ0JPUi13 cmFwcGluZy4gRG9pbmcgdGhpcyB3b3VsZCByZXF1aXJlIHJlZ2lzdGVyaW5nIGEgbmV3IHZhbHVl IGluIHRoZSBDb0FQIENvbnRlbnQtRm9ybWF0cyByZWdpc3RyeSwgZS5nLiBsaWtlICJhcHBsaWNh dGlvbi9jc3JhdHRycytjYm9yIiBhbmQgdGhlbiBpdCB3b3VsZCBiZSBvay4NCg0KSSdtIGFza2lu ZyB0aGlzIGJlY2F1c2UgaW4gaW1wbGVtZW50YXRpb25zIHdlIG5vdyB1c2UgdGhlIENCT1Itd3Jh cHBpbmcgYW5kIGlmIHdlIGRvbid0IG1ha2UgdGhlIGNoYW5nZSBub3cgaXQgd2lsbCBzdGF5IHRo YXQgd2F5IG1vc3QgbGlrZWx5LiBBbmQgdGhlIHByZXNlbnQgIkVEbm90ZSIgaW4gdGhlIHRleHQg aXMgbm90IHNvIGNsZWFyIG9uIHdoYXQgd2lsbCBoYXBwZW4uDQoNCkJlc3QgcmVnYXJkcw0KRXNr byBEaWprDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBBY2UgPGFjZS1ib3Vu Y2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgUGFub3MgS2FtcGFuYWtpcyAocGthbXBhbmEpDQpT ZW50OiBNb25kYXksIFNlcHRlbWJlciAxNywgMjAxOCAxODo1Ng0KVG86IEppbSBTY2hhYWQgPGll dGZAYXVndXN0Y2VsbGFycy5jb20+OyBkcmFmdC1pZXRmLWFjZS1jb2FwLWVzdEBpZXRmLm9yZw0K Q2M6ICdhY2UnIDxhY2VAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW0FjZV0gUmV2aWV3IGRyYWZ0 LWlldGYtYWNlLWNvYXAtZXN0DQoNCkhpIEppbSwNCldlIGhhdmUgbm93IGFkZHJlc3NlZCBhbGwg dGhlIGlzc3VlcyB5b3UgYnJvdWdodCB1cCBpbiBKdWx5LiBUaGUgZml4ZXMgd2lsbCBiZSBpbiB0 aGUgbGFzdCBpdGVyYXRpb24uIA0KV2Ugd2lsbCBzdGlsbCBtYWtlIHNvbWUgY29zbWV0aWMgdXBk YXRlcyBhbmQgcG9zdCBhIG5ldyB2ZXJzaW9uLg0KVGhhbmsgeW91IGZvciB0aGUgdGhvcm91Z2gg cmV2aWV3LiANClJncywNClBhbm9zDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9t OiBBY2UgW21haWx0bzphY2UtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEppbSBTY2hh YWQNClNlbnQ6IFN1bmRheSwgSnVseSAwMSwgMjAxOCA5OjM0IEFNDQpUbzogZHJhZnQtaWV0Zi1h Y2UtY29hcC1lc3RAaWV0Zi5vcmcNCkNjOiAnYWNlJyA8YWNlQGlldGYub3JnPg0KU3ViamVjdDog W0FjZV0gUmV2aWV3IGRyYWZ0LWlldGYtYWNlLWNvYXAtZXN0DQoNCiogSW4gc2VjdGlvbiA0LjEg SSBoYXZlIGEgcXVlc3Rpb24gYWJvdXQgd2hhdCB5b3UgYXJlIHVzaW5nIGZvciBwYXlsb2FkIGNv bnRlbnQgZW5jb2RpbmcuICBQYXJ0IG9mIHRoaXMgbWlnaHQganVzdCBiZSBhIHF1ZXN0aW9uIG9m IGhvdyB5b3UgcGxhbiB0byBtb3ZlIGZyb20gQVNOLjEgdG8gQ0JPUiBhdCBzb21lIHBvaW50IGlu IHRoZSBmdXR1cmUuICBJIHRoaW5rIHRoYXQgaXQgd291bGQgbmVjZXNzaXRhdGUgZG9pbmcgbmV3 IG1lZGlhLXR5cGVzIGluIHRoYXQgZXZlbnQuICBZb3UgYXBwZWFyIHRvIGJlIGRvaW5nIGEgQ0JP UiBic3RyIHdyYXBwaW5nIG9uIHRoZSBBU04uMSBlbmNvZGluZyBwYXlsb2FkLiAgSSBkb24ndCBi ZWxpZXZlIHRoYXQgdGhlcmUgaXMgYW55IHJlYXNvbiBmb3IgZG9pbmcgdGhpcy4gIEkgd291bGQg ZXhwZWN0IHRoYXQgdGhlIHBheWxvYWQgd291bGQgYmUgdGhlIEFTTi4xIHcvbyBhbnkgQVNOLjEu ICBJdCBpcyBoaWdobHkgcG9zc2libGUgdGhhdCBJIGFtIGp1c3QgbWlzLXJlYWRpbmcgd2hhdCB0 aGUgdGV4dCBzYXlzIGFuZCB0aGlzIGlzIHdoYXQgeW91IHNheS4NCg0KKiBJbiBzZWN0aW9uIDUu MCAtIEFzIHdyaXR0ZW4sIHRoZSBleGFtcGxlIG9mIGRvaW5nIGEgcXVlcnkgYWdhaW5zdCAvLndl bGwta25vd24vY29yZSBkb2VzIG5vdCBtYXRjaCBteSB1bmRlcnN0YW5kaW5nIG9mIHdoYXQgd291 bGQgYmUgcmV0dXJuLg0KSXQgc2hvdWxkIG9ubHkgcmV0dXJuIHRob3NlIHJlc291cmNlcyB3aGlj aCBoYXZlIHRoZSBydCBmaWVsZCBzZXQgb24gdGhlbS4NCkkgZG8gbm90IHVuZGVyc3RhbmQgd2h5 IHlvdSBiZWxpZXZlIHRoYXQgdGhlIGZvbGxvd2luZyBsaW5lcyBNQVkgYmUgcmV0dXJuZWQuICBD bGFyaWZpY2F0aW9uIG9mIHdoeSB5b3UgdGhpbmsgdGhpcyBpcyB0cnVlIHdvdWxkIGJlIGFwcHJl Y2lhdGVkLg0KDQoqIFNlY3Rpb24gNiAtIElzIHRoZXJlIGEgbmVlZCB0byBoYXZlIGFsbCBvZiB0 aGlzIGRlc2NyaXB0aW9uIGFyb3VuZCBUTFMtdW5pcXVlPyAgRG8geW91IGhhdmUgYSByZWFzb24g dG8gYmVsaWV2ZSB0aGF0IHBlb3BsZSBhcmUgZ29pbmcgZ2V0IHRoaXMgaW1wbGVtZW50ZWQgd3Jv bmc/DQoNCiogU2VjdGlvbiA3IC0gSSB0aGluayB0aGUgZmlndXJlIGhhcyBhbiBlcnJvciBhc3Nv Y2lhdGVkIHcvIGl0LiAgVGhlIENBIHNob3VsZCBiZSB0aWVkIHRvIHRoZSBFU1QgU2VydmVyIGFu ZCBub3QgdG8gdGhlIFJlZ2lzdHJhcg0KDQoqIFNlY3Rpb24gNyAtIFlvdXIgbGFuZ3VhZ2UgaXMg YSBiaXQgc2xvcHB5IGFyb3VuZCB0aGUgdGVybXMgb2YgUE9QIGFuZCBQT1AgbGlua2luZy4gIFVu bGVzcyBpdCBpcyByZWFsbHkgYmFkbHkgYmVoYXZlZCwgUE9QIHNob3VsZCBuZXZlciBiZSBicm9r ZW4gYnkgYW4gUkEuICBUaGUgUE9QIGlzIHRoZSBzaWduYXR1cmUgb24gdGhlIHJlcXVlc3QgYW5k IG5vdCB0aWVkIHRvIHRoZSBUTFMgY2hhbm5lbC4gIFRoZSBQT1AgbGlua2luZyBpcyB0aWVkIHRv IHRoZSBUTFMgY2hhbm5lbCBhbmQgaXMgYnJva2VuIGJ5IHRoZSBjaGFuZ2luZyBvZiB0aGUgVExT IHNlc3Npb25zIChjbGllbnQgPC0+IFJBLCAgUkEgPC0+IENBKSANCg0KKiBTZWN0aW9uIDcgLSBJ dCBpcyBub3QgY2xlYXIgdG8gbWUgdGhhdCB0aGUgU0hPVUxEIG9uIHJlYXNzZW1ibHkgb2YgZnJh Z21lbnRhdGlvbiBpcyBub3QgYSBNVVNULiAgSSBkb3VidCB0aGF0IGFueSBFU1Qgc2VydmVyIGlz IGdvaW5nIHRvIGJlIGFibGUgdG8gZGVhbCB3aXRoIGdldHRpbmcgZnJhZ21lbnRzIG9mIHJlcXVl c3RzIGZyb20gYSByZWdpc3RyYXIgaW4gc2VwYXJhdGUgbWVzc2FnZXMuICBUaGlzIHdvdWxkIGJl IGNvbXBvdW5kZWQgaWYgdGhlIHByb3h5IGlzIGhhbmRsaW5nIG11bHRpcGxlIHNlc3Npb25zIGF0 IHRoZSBzYW1lIHRpbWUuIA0KDQoqIFNlY3Rpb24gNyAtIEl0IHNob3VsZCBiZSBwb3NzaWJsZSB0 aGF0IHdoZW4gZG9pbmcga2V5IGdlbmVyYXRpb24gZm9yIHRoZSBwcm90ZWN0aW9uIG9mIHRoZSBw cml2YXRlIGtleSB0byBiZSBlbmQtdG8tZW5kIGFuZCBpdCBzaG91bGQgbm90IGJlIG5lY2Vzc2Fy eSBmb3IgdGhlIFByb3h5IHRvIGRlY3J5cHQgYW5kIHRoZW4gcmUtZW5jcnlwdCB0aGUgcHJpdmF0 ZSBrZXkuICBJdCBzaG91bGQgbm90IG1hdHRlciBmb3IgdGhpcyBpZiBvbmUgZG9lcyBlaXRoZXIg c3ltbWV0cmljIG9yIGFzeW1tZXRyaWMgZW5jcnlwdGlvbiBvZiB0aGUgcHJpdmF0ZSBrZXkuDQoN CiogU2VjdGlvbiA3IC0gSXQgaXMgdmVyeSBwb3NzaWJsZSB0aGF0IHRoZSBwcml2YXRlIGtleSBn ZW5lcmF0aW9uIGZ1bmN0aW9uIHdvdWxkIGJlIGhvc3RlZCBvbiB0aGUgcHJveHkgYW5kIG5vdCBh dCB0aGUgQ0EuICBJIHRoaW5rIHRoYXQgeW91IG1pZ2h0IHdhbnQgdG8gZGVzY3JpYmUgdGhpcyBh cyBhIG5vcm1hbCBjb25maWd1cmF0aW9uLiAgKEp1c3Qgc3BvdHRlZCB0aGlzIGluIHRoZSBTZWN1 cml0eSBjb25zaWRlcmF0aW9ucy4gIEkgdGhpbmsgaXQgc2hvdWxkIGJlIGhlcmUgYXMgd2VsbC4p DQoNCiogU2VjdGlvbiA5LjEgLSBhcHBsaWNhdGlvbi9tdWx0aXBhcnQtY29yZSBzaG91bGQgbm90 IGJlIGluIHRoZSB0YWJsZSBvZiBpdGVtcyBmb3IgSUFOQSB0byByZWdpc3Rlci4gIFRoaXMgaXMg YmVpbmcgZG9uZSBpbiBhIGRpZmZlcmVudCBkb2N1bWVudC4gIElmIHlvdSB3YW50IHRoaXMgdGFi bGUgYXMgYSB3aG9sZSB0aGVuIGl0IG5lZWRzIHRvIGJlIG1vdmVkIG91dCBvZiBJQU5BIGNvbnNp ZGVyYXRpb25zLg0KDQoqIFNlY3Rpb24gOS4yIC0gcGxlYXNlIGV4cGFuZCB0aGlzIHRleHQgc29t ZS4gIFlvdSBtaWdodCB3YW50IHRvIGxvb2sgYXQNCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9yZmM3MzkwI3NlY3Rpb24tNi4xIGZvciBhIHRlbXBsYXRlLg0KDQoNCkppbQ0KDQoNCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpBY2UgbWFpbGluZyBs aXN0DQpBY2VAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v YWNlDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpB Y2UgbWFpbGluZyBsaXN0DQpBY2VAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vYWNlDQo= From nobody Wed Dec 19 05:04:59 2018 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 B3CEC128766 for ; Wed, 19 Dec 2018 05:04:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F7gg5xVAkXRg for ; Wed, 19 Dec 2018 05:04:55 -0800 (PST) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50064.outbound.protection.outlook.com [40.107.5.64]) (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 A9910130934 for ; Wed, 19 Dec 2018 05:04:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=02gFrs4M+iLf9zRNvtpYASE0mwJjhqcB0pTtChwwPJ0=; b=rsRYJRpW9F/kWcxaZR3gJ+ImK9znR8a2aBZDig9BBRIQWx4ToSevKvmOo1L+L+BUOB6BipRMtCrptSKB9qAJJ3iTbHp/S+D4W8xDJwSStiDhmat8A0IZcMtmdnpRtYam8L/eJ6u8Q4vkXp2Vf6VpQrjlevXRGzebsERl6iojYxI= Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB1645.eurprd08.prod.outlook.com (10.168.66.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1446.19; Wed, 19 Dec 2018 13:04:51 +0000 Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::e8de:6a41:cbf4:89d8]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::e8de:6a41:cbf4:89d8%3]) with mapi id 15.20.1425.023; Wed, 19 Dec 2018 13:04:51 +0000 From: Hannes Tschofenig To: Ludwig Seitz , Stefanie Gerdes , Jim Schaad , "ace@ietf.org" Thread-Topic: [Ace] Security of the Communication Between C and RS Thread-Index: AQHUlquFKpsKbsbb2kGcq8Jrm430i6WELNAAgABWsZCAABAfgIAACmOwgAFP8YCAAAFuwIAABDYAgAAJ5ACAAAqnwA== Date: Wed, 19 Dec 2018 13:04:51 +0000 Message-ID: References: <154322421294.8323.8505315870685563404.idtracker@ietfa.amsl.com> <03b601d49191$7d1bb400$77531c00$@augustcellars.com> <945fbebe-659f-ac72-3ab6-8e05447e7c92@ri.se> <1c5b81f3-50ce-be68-bec3-68ce2ff15b43@tzi.de> <4ae4eccd-68bf-18ef-f909-142f8172eca1@ri.se> <81ba3ab4-a9ce-a6fd-fbe6-c36a6fbbd9a5@tzi.de> <9f35177f-30d4-817e-dfc3-9a54903ab023@ri.se> In-Reply-To: <9f35177f-30d4-817e-dfc3-9a54903ab023@ri.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [80.92.114.221] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0801MB1645; 6:kqsP8oy2m4EH4+D0lVGOqOr5jHjLKFEqXW87YwvEqWUFDZF2+vF5dRr1xHlFPUXKLKLBRbgMixL0iggK973+aQMnYwHbMeCN+WUVqMZpWm+dhU3HobwMheQnzSBBE+Q+gNIZX/x2CGuiC5acTrLPgViB916nUpT0gIi8pS6qvW3yQDnZKXYUE3zYEdMv73zxQlVk/RbszLaP0k7AWZYOevBxRdg6s9HvmD57xRPCxiWWJtJlQ3Wa96NoBfrgxpKrywe4mZvpbgTrt4bKQF1ufI8u1kVJpVNt+HZjjTq+UKgR1IxjS1ZWCCqLGIwtWmyDvBHABeGajYhcgDD98CIPV0aM21fE9sx9mYJcYkGFwcsXuo57WCI0aa4ZMkCKBePXCp9QmFMYPDOYU9q3CZPytuOejlpGPLAmf9uXDEqA+mJb9jmx/zJQn8nOf7oKJ73dNIY+1MYQYaRvHh1MAoZT5A==; 5:5Xbx0WsXy7hTxJ63//A0ULZDR+2o2wdy0yhzOsAOBNqzKcwvDMnErRB3/skA+uTxWVovdDN8ZbHi/A1HwFHwFeF/RvZThBOt3dKTaaDW76v/HdSAUmV3eirPtFkGWT85kBWSqHHXCUijl/pFccisWD04/vaRZNk34Jx628R++Oo=; 7:F6CFxXijWR0c4Go7bcqO0PVvJCrXe3/Jp1O5kW3Pvl2txyxSa3U49wLbq+21dGpqB/HvhUKkFSVde3fu3n1GLbqkXdFuenkayibcJByahbmbpMke0KIkIl7iLAjqJED4e6cZGGCJIcvjOXjc/v1sSA== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: e40d21f0-27db-46a6-2b0e-08d665b29026 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600074)(711020)(4618075)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB1645; x-ms-traffictypediagnostic: VI1PR0801MB1645: x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(3230021)(999002)(6040522)(2401047)(5005006)(8121501046)(3231475)(944501520)(52105112)(93006095)(93001095)(10201501046)(3002001)(6055026)(148016)(149066)(150057)(6041310)(20161123562045)(20161123560045)(20161123558120)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(201708071742011)(7699051)(76991095); SRVR:VI1PR0801MB1645; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0801MB1645; x-forefront-prvs: 0891BC3F3D x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(346002)(136003)(39860400002)(366004)(376002)(40434004)(199004)(189003)(478600001)(186003)(72206003)(2906002)(93886005)(316002)(25786009)(6116002)(66066001)(3846002)(9686003)(7696005)(6246003)(97736004)(53936002)(55016002)(76176011)(15650500001)(26005)(14454004)(102836004)(6506007)(110136005)(2501003)(68736007)(86362001)(74316002)(305945005)(5024004)(106356001)(14444005)(256004)(81166006)(81156014)(8676002)(476003)(446003)(8936002)(71200400001)(71190400001)(11346002)(486006)(5660300001)(7736002)(99286004)(33656002)(6436002)(229853002)(105586002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB1645; H:VI1PR0801MB2112.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: gSPBo/98H6Akpx4BWSQ9WTzECGRCimWgAUpQ4s7eZQIXg7DkwNN+JCIPBDnt0c2VLnNvg7ZtUzX5ZORZ+FP3gWcy8AqEpjIyzPFkgDMdX3TihucXmkRroEhkChnIqZDAe94aEK0loo5cGdhkXTrOOFmb/6aCNQsqjlgPRq8iBI4BFhiWSLA7dfe8fdh5k1Rw+ard9oo2eB7pp+9Ugh1ORithq/wB/p0tsTewLWokxcZE39wFgwokvVHaKnphxpxsw6MEIkmMJ4vyyNHLS/AQRSQcuKEuFqLT0D/oN96LO5P7dG/b4JLcAc/y3mNjAc1V spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: e40d21f0-27db-46a6-2b0e-08d665b29026 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Dec 2018 13:04:51.5414 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1645 Archived-At: Subject: Re: [Ace] Security of the Communication Between C and RS X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2018 13:04:58 -0000 Thanks, Ludwig. The list of steps below help me to understand the concern. ---- 1.) C obtains token and pop-key from AS 2.) C transmits token to RS and sets up secure communication (e.g. DTLS-PSK) using the pop-key 3.) C sends secure requests to the RS 4.) token expires, an attacker manages to get hold of the pop-key 5.) C continues to send requests containing sensitive information to the RS= , attacker can now read the messages and spoof positive responses from the= RS. C never notices that the token is invalid and that it is actually talk= ing to the attacker. ---- In step (4) you tie the expiry of the token to the attacker getting hold of= the key. What happens if the attacker gets hold of the pop key before the = token expires? Additionally, if you use DTLS/TLS just having the PoP key still requires th= e attacker to run a new DTLS/TLS handshake with the RS. It would also be useful to know where the attacker got the PoP key from and= how you can even detect the compromise. Additionally, there is the question why the RS wouldn't stop communicating = if the token expired since it has that information. Normally, the idea is t= hat the RS has a protected resource and the client wants to access it. That= 's why the RS is asking the client to send a token that gives it access. Ciao Hannes IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. From nobody Wed Dec 19 05:24:10 2018 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 1B276130E4D for ; Wed, 19 Dec 2018 05:23:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=risecloud.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fFoCTtlYI0dl for ; Wed, 19 Dec 2018 05:23:55 -0800 (PST) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0625.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe02::625]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC206130E3A for ; Wed, 19 Dec 2018 05:23:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=RISEcloud.onmicrosoft.com; s=selector1-ri-se; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=RSkuAedyzNqVMioMt6UKk3LH3WE9Mn9MgUy3HPopJZw=; b=CGTRu1AzJND3jqu8jVR28xKdgbi1EbsPQKY2o4QcZXk+TgyrJ9lRwvY8H/O7ZO1G4/5Fl2hgvzzKGEooUo4asnQP9TZoBl7VNjxHzofmH4K4CJyJaCntP0jPJKxEnmmkNClmb/1Mrjn8IV6iUXcsVSGLeyWe9cE65gHjp8hMS0s= Received: from VI1P18901CA0005.EURP189.PROD.OUTLOOK.COM (2603:10a6:801::15) by VI1P18901MB0109.EURP189.PROD.OUTLOOK.COM (2603:10a6:801:f::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1425.22; Wed, 19 Dec 2018 13:23:52 +0000 Received: from VE1EUR02FT054.eop-EUR02.prod.protection.outlook.com (2a01:111:f400:7e06::200) by VI1P18901CA0005.outlook.office365.com (2603:10a6:801::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1446.19 via Frontend Transport; Wed, 19 Dec 2018 13:23:52 +0000 Authentication-Results: spf=pass (sender IP is 194.218.146.197) smtp.mailfrom=ri.se; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=ri.se; Received-SPF: Pass (protection.outlook.com: domain of ri.se designates 194.218.146.197 as permitted sender) receiver=protection.outlook.com; client-ip=194.218.146.197; helo=mail.ri.se; Received: from mail.ri.se (194.218.146.197) by VE1EUR02FT054.mail.protection.outlook.com (10.152.13.218) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.20.1446.11 via Frontend Transport; Wed, 19 Dec 2018 13:23:52 +0000 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_128_CBC_SHA256_P256) id 15.1.1531.3; Wed, 19 Dec 2018 14:23:51 +0100 To: Hannes Tschofenig , Stefanie Gerdes , Jim Schaad , "ace@ietf.org" References: <154322421294.8323.8505315870685563404.idtracker@ietfa.amsl.com> <945fbebe-659f-ac72-3ab6-8e05447e7c92@ri.se> <1c5b81f3-50ce-be68-bec3-68ce2ff15b43@tzi.de> <4ae4eccd-68bf-18ef-f909-142f8172eca1@ri.se> <81ba3ab4-a9ce-a6fd-fbe6-c36a6fbbd9a5@tzi.de> <9f35177f-30d4-817e-dfc3-9a54903ab023@ri.se> From: Ludwig Seitz Message-ID: Date: Wed, 19 Dec 2018 14:23:51 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.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-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:194.218.146.197; IPV:NLI; CTRY:SE; EFV:NLI; SFV:NSPM; SFS:(10009020)(136003)(346002)(39860400002)(396003)(376002)(2980300002)(199004)(189003)(97736004)(93886005)(31686004)(50466002)(22746007)(104016004)(68736007)(14444005)(81166006)(15650500001)(486006)(36756003)(8676002)(44832011)(81156014)(22756006)(2501003)(305945005)(2906002)(5660300001)(64126003)(229853002)(476003)(126002)(69596002)(2616005)(7736002)(65826007)(8936002)(47776003)(23676004)(2486003)(230700001)(33896004)(86362001)(76176011)(65956001)(65806001)(336012)(74482002)(26005)(386003)(53546011)(3846002)(356004)(77096007)(67846002)(117156002)(16526019)(6116002)(186003)(508600001)(106466001)(16576012)(106002)(110136005)(58126008)(53936002)(6246003)(31696002)(316002)(446003)(11346002)(40036005); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1P18901MB0109; H:mail.ri.se; FPR:; SPF:Pass; LANG:en; PTR:InfoDomainNonexistent; A:1; MX:1; X-Microsoft-Exchange-Diagnostics: 1; VE1EUR02FT054; 1:+9m16vF+X3ILPd7qInzs5TmDFifpSUT1lYJ21jiH+x6UOJXhifc1gbG4Xw05+n3cFjx+WyAPASt4hFHwXYYP2jblSM8Cs5MAhRcbeTwYxBT6kUUHr8jcO/gxOlZKw6Su X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: f751fdc5-3ff1-4de7-eda8-08d665b5383d X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(4608076)(2017052603328)(7153060)(7193020); SRVR:VI1P18901MB0109; X-Microsoft-Exchange-Diagnostics: 1; VI1P18901MB0109; 3:pVrGtbXx4o32sOrHA1MW0Xp3xLixX1aQwIyBUxPyCiU2OCGDyAMAWmOsgzf8NzHQFFBDWWJy+tGVMqbA5VyoVoly1lzwp8tnmAS67cYjEv23ODLG78gpZVTATJI5r4zbKTsEZl3SqvYWIJlmPqpIGgS4GZWHScBjDqxyopV5jCaT4EOycU3tuZnxazDuOfRj+v1I8bshgtFGLn3Uzl4Thmk3BOKKOWfkpCTysdtSTUDTd5OlItq0SHULz/8fF1VxxBxRlnqWcjhNW7aSjwalcz/sODM3WMZUucU83ygCK3ebAaMKdL8XB9hsym/jUmYBhb3aOy7Ij80Pqnrp/imbGHxCk8OicVpcIa7MB1Fl37o=; 25:TBXljbwp8stwfGHX+Ch86U9L162Wol+VcOMmSPMiFTdn5cd+VsWciz9v+TQRn7O+fCueUfgqRWPyngP3amMgcILm7XaofiFVSqC555wqAwk5RPvMpoaYaliZ9gR8n2m5shszMZdoInZopmLPcpX2R78lpxRwAnY3CFMyfCAgQEOcGtpHDxRX5b1powcb3yuj3lPI9R6aWx/HRkcJ6axSjXXBeF6kqX3aIF/0uHj66rna8xPH4aMc/WKCtgv9uffpEQENoKPTMm6FgmmctXP7QzMfEV1ha3ebvlz/nsFC9eHm065UEiOyhRkEyjOFyIDChjaE5QwJFH9Xdz8YunRlRA== X-MS-TrafficTypeDiagnostic: VI1P18901MB0109: X-Microsoft-Exchange-Diagnostics: 1; VI1P18901MB0109; 31:kVIsBQay8XWJMR0FJTT/vy8rIzQrIJwz203UlKs5lDjM92k4UIEoxoSf2w43sy0ufI1qjexnV8wwQwCDAlt8lvBADoLOszdg5kej9IzIAf92QL47M3ISA9rBm9A4Nu8S5QMaPA/3VGaKq2xEKuylb9go0L6AkdKArcLHVOLiNjjydbJPjRTBXL0e6TvrBgwIGNvb98GhzuDPPkWx4kOhRVb9XdbGm/rjlxRtzHJ3oaw=; 20:VwLHdFLNlaFLZZ8iz+TYjAkj4UWrPDDF4qke+yztr1gSU5QZJwUzb5NjDsVZETzGBKWEGeO9iNNCp+Z0oaQB2Xg5Xqbx16prEP0EirfdAuzHlWeoHz27UYGuK7UwQgU4RnokWbNgxl9FyL1eOFB/WcNtksuP0qF7fj01GbD55FB1dhHb6Pe58ZX8dtLkXkyajW1/RA6RnV6LWACoxzn6rrqwritQSJFmof3WQ5UE4KpfDKInAb0QUhl/ES3HclMG; 4:ptLbLbqj0LuTRj6xp+nvawVZuwZ+1D5B0IEuTBL/y5mPCsMxRiUeG/MbEKxDGyjoZPx07j6O2l7S9dqaal9KSMeNlOX9KGcy0jM0FjA+p272qnckwgZw0NnE9oFGQkCupce6E6xL8QhoMEyWk9pl0Eifun3ND5CsvnN796d54BBAy2JRrwDRc1xstJJuHaC29Uvw27xipD/EFMLNSZIHTeHmuxTBy7JfmpHKd+iaTzFQoGmx7CtrvVrmbHe80poO0qfwSMU0d6vbEp4SdYCacw== X-Microsoft-Antispam-PRVS: X-MS-Exchange-SenderADCheck: 1 X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(3230021)(999002)(6040522)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006095)(93004095)(3231475)(944501520)(52105112)(148016)(149066)(150057)(6041310)(20161123558120)(20161123560045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(20161123562045)(201708071742011)(7699051)(76991095); SRVR:VI1P18901MB0109; BCL:0; PCL:0; RULEID:; SRVR:VI1P18901MB0109; X-Forefront-PRVS: 0891BC3F3D X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtWSTFQMTg5MDFNQjAxMDk7MjM6c3RJc3RycXFxVmNmcFJNSEd5NWhqTi9R?= =?utf-8?B?b0tkRW1ocUNFV3ZnZTBkd3N3QVpDL1Z4YS80eEJadkE2NGNPRHhmMVloQi83?= =?utf-8?B?UG5RUlhFNzNud2RET0pKcDVLazl4RWEvTzRrL1ZjUUt5SWw3Nk5uaDFhWVVs?= =?utf-8?B?bEhWRGo5bmFGVnlvdWRqOG15cmJId0haV2EzQjFHVS8rRHNwRCtpYjVHKzN1?= =?utf-8?B?ZjlEaFhVQTZlL1k5RUc3ZzdqZ3Q2TWJOZlQ5V09kOTFWQjZHZ3BSWnZHUkNu?= =?utf-8?B?ZWgyMXFNRU5raDBleVRKU1ZDSUZ5U3FEeHRmMkpla0xRajR0eXQxZWRhN3Ju?= =?utf-8?B?eHVRNmJnZmxUaTMxVWdtbFNuaUlxdGRlL3BaYjFTcVpMaTA0d0RCbHIxVUYw?= =?utf-8?B?OTNWR3Z1eS8zZGtLUWtRL3pKYWFoMjNmNTI1OHR0U2hCamRpUTFtZmxGN0FS?= =?utf-8?B?RXVRUWJvM1lZWWdTaTAxWldmZThUUjRoeGwyVUhoTHJoNUdvMjJ1R3VNNklh?= =?utf-8?B?ak1adE1ySWo0dzRLa01UdmFERmdBMFdEMStGcUsyUTNJZXpEdGdYRnZMN3Bi?= =?utf-8?B?NEY5SFpjZTRmVmNPTnFJck1RSjVWZjNXNWxNeGVOaEV5cGdiTE9zWGlaS2d1?= =?utf-8?B?RW5hT3BKOUxrT2IwTlZ2MGQ5bmZCM1NEQlZENFhRNzV2S2dPdHVrV1pLYXNO?= =?utf-8?B?TFl0dWRkeXZJU25SOVprT09KeHNJR3o1encvMDBvQlkzajdSVE5CUkNZaTcw?= =?utf-8?B?NHc5cFdQZXIxUWg0dWQ3a0tPclFkNGhGQWF6cXV1QTdBaHVDckpueUFPQVU2?= =?utf-8?B?TysxMW9MV25RTWU2WVcwdnNKejZRTHJqMjNsRHoyS3ZNQ0YrRTZhRHR4V0s5?= =?utf-8?B?OG91d2g1TTkyT1BTZXJUaVVFdHQwd0hRaUpreHdWVGp0RDAzS2s4Ri8rTFdy?= =?utf-8?B?ajRTam1UbTVRWTF4cjhZNG9vc2F3VkFVYnlpVlpBMS9QL2FNeTlEOEpET21r?= =?utf-8?B?T1Noa2dXQXovWmhaWTh4Y0F0RmJtR2dXL2tUaGxOMzNFVFVsZzFtOUxVMC9L?= =?utf-8?B?YldDQlZ6d1NZcXkyMVBGd0JCYk05MmhDaFBSTFJUUExJb2ZJSDVqQ2dhYWJl?= =?utf-8?B?T0paTzhRQVJrMk5nT0xPYzVpZ1BFOEMrcVVMbm81NUNFaXJqZmd4TVdROTdh?= =?utf-8?B?YUNaRk12c214OUluL3BBVEZ1cXZjMEcrazVYTXdEU1F3cERpclgyQnV3bHBu?= =?utf-8?B?R0NvalNzdmFObGZsczV0RUpQM1VXQmVCWEE1MEdSb3l5S2ZPdjA1d1lYaHRm?= =?utf-8?B?SFZmU25nSUwydEFTSzFQQU5IQTZWcEtzOG1ndjZWaWtwUm43Q1ZCRmsxOEQr?= =?utf-8?B?bHlKK0NXSStqYXFPVXdjYjBtWkt6Nnk4UElYWjhPbUZNT0RXRVlRRWsvMm5i?= =?utf-8?B?RWhva294Tko5Q1I3MzJzZVRZOXdMSE5DQjI2S1hxS3A2WkdLMEEwd3JmbkFP?= =?utf-8?B?ckU4UHlZS3FrR3laMjl5SzVzSWJ6OTJIRW1JcVVxakRWNjBBQjQzQ2JzOGg3?= =?utf-8?B?V0tBcUlkb0hTWUlqUTJ0ZzhCUmdKSy9ZMFZEOGxyNERZUEtpNTRVN0hma1Nz?= =?utf-8?B?WllXWThRQnlpaUNuU0V4VlEvTFN4K3IrM1Nxcm5lWTI0R2hnb2VmR0tjK2pm?= =?utf-8?B?NXRUcEtkSldHYzRqZUFxMlVFOSt6SUhIWkRhV3NxbjlWZWRSeWlhQm1NNEFG?= =?utf-8?B?Qk80alFQMFdnV3YzSDh1cU9iZG5RaEY4WVkvWVNON3E0UEpFdDZhMTJ0NEQy?= =?utf-8?B?OFJxRVY1M2dsTXRUd3o2WEp0cHNENkhoZVpnc3IvdlZFMmZXVkZBcEFtcmlz?= =?utf-8?B?cy9zV0lxbEtscGV1TEtTSFZ1K0wva2ZDUHNZMjJuaytPQlhHeDFaZkVRZHlp?= =?utf-8?B?V3oxYjZMUzRwUTZzT2JDajIydnh0Nng0aXYzZ0EvWGtHSDdkVVBucHVXYlFu?= =?utf-8?B?U3pxOGlndnB6VEViWm45WlpOVUNDNk54Y0pxdUlQdnB3QkNoVjcxVGUrZVNu?= =?utf-8?B?VkY5bGhRS0w2cVp0NVQyRXF4VU9haVVtVmthcGJMQzc5aTJ0eklNeHA3NC9x?= =?utf-8?Q?q3I7xertw9dt5mTARBB+8HkWg=3D?= X-Microsoft-Antispam-Message-Info: bMdMP+q3yIiaorK5D7kDf64b/wR62EiFwp6B9EKesNZOKxp3YYYE4J7XmJUj5+s4+JEnrSDYEDZokyI3/gd3GtzOekSAg/EInVS3K3UK8Xtp5tZVIiWVVJlQ08zmBKfQ/0NWCgMKl3rl1IG+1MI4wr2nA6CU39g45H4by1CrR7JpedXY/v4cOX3b5P+pdBidEcOOQk36qwmfIyWeNh+Z4RHWVZGZnH6HIJz9Nb0SkPcKa8zWC4RWgGyWREKwNmLFxMmSLDRQRfPYHyPGq2wAEKhPFe1P67zitPQZ2BjaBNPQtDFKAyoRX8hVmxY+Zq9U X-Microsoft-Exchange-Diagnostics: 1; VI1P18901MB0109; 6:zlkVKLMZ5fBlm4vtGZah2k9jGmwcm56xzlBtdWwc9RSvvKv94PlHLSVAn5hk8c6sFW1O01uNv8ccEXEldkV7iiAk+H/xewwFMs6OG8OoeWpawVR+L5obD42M6tzcKhfBxrbvUh2KESiH9ra8ijohgGYCIHPvMhuMNq6rRsVZwYfVbuH0Q32psWrLy5PaOtrXgQe+tTW5q9Nnt5qF3YNmc20IvSEJX+5vRridS0O+D+QIpEVo0YJjiwv91fJjf7022gW40hDbZFFZFgWfhveOXVLfV6XInoDAzjf+rVk/9aMBUgsbB/9+ON2YOS9/MUXwF+xOt1K2MVmFTEZ0REn7EsD5CBGaXRJdRa7M3bBuZKdgjUKTVOpx+VxW9VNiSC6xb7RnQWOEFj1GSmE1dU028l/rMW0au6MsQvhBmn0zKwEVOGg1mvbb7okIgYj7aZicIBW5iANhqvaPvlcoFb14wA==; 5:agLY50YNbQo7rirXVypJag9o8evCLU9I0JB6UD+DhnYInuWBX7dMrnd01erXfVmoVutfV6MUp7zv1+w7USbPCLBOsGVcvth6yixQbwT6WtIEaXvMR4xfNGjb56PHzJ5V+Z7E2zWj7qjCkMq3y6ZQKP54g5SXn5mgqPremAKq/kI=; 7:7ThnNg7KBD7xEvfutr4tSXuS0p4VkICEonBWe0MPNKugvj/UkLfG2eIsqw6tjlBZJ2LS+EA/6GBGFhxXYG5IO7xQXMy2uAr0kSc92yeYTUT7t2hbtG8aeV4Jj0g+9qexUxnTDDdKM6oMSY/JiaCC2A== SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Dec 2018 13:23:52.5166 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: f751fdc5-3ff1-4de7-eda8-08d665b5383d X-MS-Exchange-CrossTenant-Id: 5a9809cf-0bcb-413a-838a-09ecc40cc9e8 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=5a9809cf-0bcb-413a-838a-09ecc40cc9e8; Ip=[194.218.146.197]; Helo=[mail.ri.se] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1P18901MB0109 Archived-At: Subject: Re: [Ace] Security of the Communication Between C and RS X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2018 13:24:08 -0000 On 19/12/2018 14:04, Hannes Tschofenig wrote: > Thanks, Ludwig. The list of steps below help me to understand the concern. > > ---- > > > 1.) C obtains token and pop-key from AS > 2.) C transmits token to RS and sets up secure communication (e.g. > DTLS-PSK) using the pop-key > 3.) C sends secure requests to the RS > 4.) token expires, an attacker manages to get hold of the pop-key > 5.) C continues to send requests containing sensitive information to the RS , attacker can now read the messages and spoof positive responses from the RS. C never notices that the token is invalid and that it is actually talking to the attacker. > > ---- > > In step (4) you tie the expiry of the token to the attacker getting > hold of the key. What happens if the attacker gets hold of the pop > key before the token expires? If it is detected the AS would revoke the token. Then the client _could_ use client introspection to get that information. Note that this is what the CMU people are looking at. > Additionally, if you use DTLS/TLS just > having the PoP key still requires the attacker to run a new DTLS/TLS > handshake with the RS. If the pop-key was used as a basis for doing a DTLS-PSK handshake, the attacker should be able to hijack the connection and impersonate either party. > It would also be useful to know where the > attacker got the PoP key from and how you can even detect the > compromise. That is a different story entirely. You could imagine the case of an RS improperly deleting an expired token and the associated pop-key, and then being subject to a physical attack that recovers that information. > > Additionally, there is the question why the RS wouldn't stop > communicating if the token expired since it has that information. The RS would indeed stop, but since the token is opaque to the client, it has no way of knowing that the token has expired, and our clever attacker is using the pop-key to impersonate the RS and maintain the illusion that the connection is still alive an running. > Normally, the idea is that the RS has a protected resource and the > client wants to access it. That's why the RS is asking the client to > send a token that gives it access. > Yes but say e.g. that the RS is a message broker and the client is a publisher, writing sensitive data to the RS. I think Steffi's point definitely warrants text in the security considerations, outlining how a client could detect that a token has expired. /Ludwig -- Ludwig Seitz, PhD Security Lab, RISE Phone +46(0)70-349 92 51 From nobody Wed Dec 19 05:43:59 2018 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 05659126CB6 for ; Wed, 19 Dec 2018 05:43:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] 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 jpw7BZCpEtAS for ; Wed, 19 Dec 2018 05:43:53 -0800 (PST) Received: from smtprelay.hostedemail.com (smtprelay0176.hostedemail.com [216.40.44.176]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56A8B1200B3 for ; Wed, 19 Dec 2018 05:43:53 -0800 (PST) Received: from filter.hostedemail.com (clb03-v110.bra.tucows.net [216.40.38.60]) by smtprelay03.hostedemail.com (Postfix) with ESMTP id E016E8368EE7; Wed, 19 Dec 2018 13:43:51 +0000 (UTC) X-Session-Marker: 73746F6B636F6E73406262686D61696C2E6E6C X-Spam-Summary: 2, -10, 0, , d41d8cd98f00b204, stokcons@bbhmail.nl, :::::::::, RULES_HIT:1:2:41:72:152:355:379:582:599:800:960:962:967:968:969:973:982:983:988:989:1152:1189:1208:1212:1221:1260:1313:1314:1345:1431:1436:1437:1516:1517:1518:1575:1588:1589:1592:1594:1605:1617:1730:1776:1792:2068:2069:2194:2198:2199:2200:2525:2528:2551:2553:2559:2568:2570:2627:2682:2685:2691:2693:2703:2736:2859:2894:2897:2911:2933:2937:2939:2942:2945:2947:2951:2954:3022:3421:3622:3865:3866:3867:3868:3870:3871:3872:3873:3874:3934:3936:3938:3941:3944:3947:3950:3953:3956:3959:4049:4250:4321:4361:4425:4860:5007:6117:6119:6261:7576:7875:7903:8603:9010:9025:9108:9177:9545:10004:11658:12379:12740:13138:13139:13149:13161:13229:13230:13231, 0, RBL:216.40.42.5:@bbhmail.nl:.lbl8.mailshell.net-62.8.55.100 66.201.201.201, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF:not bulk, SPF:fn, MSBL:0, DNSBL:neutral, Custom_rules:0:0:0, LFtime:30, LUA_SUMMARY:none X-HE-Tag: dust32_490751e1d51d X-Filterd-Recvd-Size: 13726 Received: from mail.bbhmail.nl (imap-ext [216.40.42.5]) (Authenticated sender: webmail@stokcons@bbhmail.nl) by omf19.hostedemail.com (Postfix) with ESMTPA; Wed, 19 Dec 2018 13:43:51 +0000 (UTC) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_f6bec0fa26e4ad54851a398fe2b9016e" Date: Wed, 19 Dec 2018 14:43:50 +0100 From: Peter van der Stok To: Esko Dijk Cc: "Panos Kampanakis (pkampana)" , consultancy@vanderstok.org, 'ace' , Jim Schaad Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: References: Message-ID: <548bedfc951bf99738da4bd619291a56@bbhmail.nl> X-Sender: stokcons@bbhmail.nl User-Agent: Roundcube Webmail/1.2.7 X-Originating-IP: [5.206.216.229] Archived-At: Subject: Re: [Ace] Review draft-ietf-ace-coap-est / Removal of CBOR-wrapped ASN.1 ? X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2018 13:43:57 -0000 --=_f6bec0fa26e4ad54851a398fe2b9016e Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Hi esko, apologies for being unclear. The CBOR wrapping is removed. It is only present for response of server key generation /skg Peter Esko Dijk schreef op 2018-12-19 13:32: > Dear Panos & Peter, > > On Jim's first point for section 4.1 below (content encoding) - will the CBOR-wrapped ASN.1 payload be changed to "pure" ASN.1 payload for the media types that are non-multipart? > I agree with Jim that the CBOR wrapping in this case is not needed (since the CoAP Content-Format / media type id will tell the receiver how it is encoded anyhow). Also it seems harmful in this case, since an existing CoAP media type-plus-encoding is "overloaded" with a second encoding if we allow the CBOR-wrapping. Doing this would require registering a new value in the CoAP Content-Formats registry, e.g. like "application/csrattrs+cbor" and then it would be ok. > > I'm asking this because in implementations we now use the CBOR-wrapping and if we don't make the change now it will stay that way most likely. And the present "EDnote" in the text is not so clear on what will happen. > > Best regards > Esko Dijk > > -----Original Message----- > From: Ace On Behalf Of Panos Kampanakis (pkampana) > Sent: Monday, September 17, 2018 18:56 > To: Jim Schaad ; draft-ietf-ace-coap-est@ietf.org > Cc: 'ace' > Subject: Re: [Ace] Review draft-ietf-ace-coap-est > > Hi Jim, > We have now addressed all the issues you brought up in July. The fixes will be in the last iteration. > We will still make some cosmetic updates and post a new version. > Thank you for the thorough review. > Rgs, > Panos > > -----Original Message----- > From: Ace [mailto:ace-bounces@ietf.org] On Behalf Of Jim Schaad > Sent: Sunday, July 01, 2018 9:34 AM > To: draft-ietf-ace-coap-est@ietf.org > Cc: 'ace' > Subject: [Ace] Review draft-ietf-ace-coap-est > > * In section 4.1 I have a question about what you are using for payload content encoding. Part of this might just be a question of how you plan to move from ASN.1 to CBOR at some point in the future. I think that it would necessitate doing new media-types in that event. You appear to be doing a CBOR bstr wrapping on the ASN.1 encoding payload. I don't believe that there is any reason for doing this. I would expect that the payload would be the ASN.1 w/o any ASN.1. It is highly possible that I am just mis-reading what the text says and this is what you say. > > * In section 5.0 - As written, the example of doing a query against /.well-known/core does not match my understanding of what would be return. > It should only return those resources which have the rt field set on them. > I do not understand why you believe that the following lines MAY be returned. Clarification of why you think this is true would be appreciated. > > * Section 6 - Is there a need to have all of this description around TLS-unique? Do you have a reason to believe that people are going get this implemented wrong? > > * Section 7 - I think the figure has an error associated w/ it. The CA should be tied to the EST Server and not to the Registrar > > * Section 7 - Your language is a bit sloppy around the terms of POP and POP linking. Unless it is really badly behaved, POP should never be broken by an RA. The POP is the signature on the request and not tied to the TLS channel. The POP linking is tied to the TLS channel and is broken by the changing of the TLS sessions (client <-> RA, RA <-> CA) > > * Section 7 - It is not clear to me that the SHOULD on reassembly of fragmentation is not a MUST. I doubt that any EST server is going to be able to deal with getting fragments of requests from a registrar in separate messages. This would be compounded if the proxy is handling multiple sessions at the same time. > > * Section 7 - It should be possible that when doing key generation for the protection of the private key to be end-to-end and it should not be necessary for the Proxy to decrypt and then re-encrypt the private key. It should not matter for this if one does either symmetric or asymmetric encryption of the private key. > > * Section 7 - It is very possible that the private key generation function would be hosted on the proxy and not at the CA. I think that you might want to describe this as a normal configuration. (Just spotted this in the Security considerations. I think it should be here as well.) > > * Section 9.1 - application/multipart-core should not be in the table of items for IANA to register. This is being done in a different document. If you want this table as a whole then it needs to be moved out of IANA considerations. > > * Section 9.2 - please expand this text some. You might want to look at > https://tools.ietf.org/html/rfc7390#section-6.1 for a template. > > Jim > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace --=_f6bec0fa26e4ad54851a398fe2b9016e Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8 Hi esko,

apologies for being unclear.
The CBOR wrapping is = removed. It is only present for response of server key generation /skg

Peter

Esko Dijk schreef op 2018-12-19 13:32:

= Dear Panos & Peter,

On Jim's first point for section 4.1 be= low (content encoding) - will the CBOR-wrapped ASN.1 payload be changed to = "pure" ASN.1 payload for the media types that are non-multipart?
I ag= ree with Jim that the CBOR wrapping in this case is not needed (since the C= oAP Content-Format / media type id will tell the receiver how it is encoded= anyhow).  Also it seems harmful in this case, since an existing CoAP = media type-plus-encoding is "overloaded" with a second encoding if we allow= the CBOR-wrapping. Doing this would require registering a new value in the= CoAP Content-Formats registry, e.g. like "application/csrattrs+cbor" and t= hen it would be ok.

I'm asking this because in implementations = we now use the CBOR-wrapping and if we don't make the change now it will st= ay that way most likely. And the present "EDnote" in the text is not so cle= ar on what will happen.

Best regards
Esko Dijk

-----Original Message-----
From: Ace <ace-bounces@ietf.org> On Behalf Of = Panos Kampanakis (pkampana)
Sent: Monday, September 17, 2018 18:56 To: Jim Schaad <ietf@augustcellars.com>; draft-ietf-ace-coap-est@ietf.org Cc: 'ace' <ace@i= etf.org>
Subject: Re: [Ace] Review draft-ietf-ace-coap-est

Hi Jim,
We have now addressed all the issues you brought up = in July. The fixes will be in the last iteration.
We will still make= some cosmetic updates and post a new version.
Thank you for the thor= ough review.
Rgs,
Panos

-----Original Message-----=
From: Ace [mailto:ace-bounces@ietf.org] On Behalf Of Jim Schaad
Sent: Sund= ay, July 01, 2018 9:34 AM
To: draft-ietf-ace-coap-est@ietf.org
= Cc: 'ace' <ace@ietf= =2Eorg>
Subject: [Ace] Review draft-ietf-ace-coap-est
* In section 4.1 I have a question about what you are using for payload= content encoding.  Part of this might just be a question of how you p= lan to move from ASN.1 to CBOR at some point in the future.  I think t= hat it would necessitate doing new media-types in that event.  You app= ear to be doing a CBOR bstr wrapping on the ASN.1 encoding payload.  I= don't believe that there is any reason for doing this.  I would expec= t that the payload would be the ASN.1 w/o any ASN.1.  It is highly pos= sible that I am just mis-reading what the text says and this is what you sa= y.

* In section 5.0 - As written, the example of doing a query = against /.well-known/core does not match my understanding of what would be = return.
It should only return those resources which have the rt field= set on them.
I do not understand why you believe that the following = lines MAY be returned.  Clarification of why you think this is true wo= uld be appreciated.

* Section 6 - Is there a need to have all o= f this description around TLS-unique?  Do you have a reason to believe= that people are going get this implemented wrong?

* Section 7 = - I think the figure has an error associated w/ it.  The CA should be = tied to the EST Server and not to the Registrar

* Section 7 - Y= our language is a bit sloppy around the terms of POP and POP linking.  = ;Unless it is really badly behaved, POP should never be broken by an RA. &n= bsp;The POP is the signature on the request and not tied to the TLS channel= =2E  The POP linking is tied to the TLS channel and is broken by the c= hanging of the TLS sessions (client <-> RA,  RA <-> CA)
* Section 7 - It is not clear to me that the SHOULD on reassembl= y of fragmentation is not a MUST.  I doubt that any EST server is goin= g to be able to deal with getting fragments of requests from a registrar in= separate messages.  This would be compounded if the proxy is handling= multiple sessions at the same time.

* Section 7 - It should b= e possible that when doing key generation for the protection of the private= key to be end-to-end and it should not be necessary for the Proxy to decry= pt and then re-encrypt the private key.  It should not matter for this= if one does either symmetric or asymmetric encryption of the private key= =2E

* Section 7 - It is very possible that the private key gene= ration function would be hosted on the proxy and not at the CA.  I thi= nk that you might want to describe this as a normal configuration.  (J= ust spotted this in the Security considerations.  I think it should be= here as well.)

* Section 9.1 - application/multipart-core shou= ld not be in the table of items for IANA to register.  This is being d= one in a different document.  If you want this table as a whole then i= t needs to be moved out of IANA considerations.

* Section 9.2 -= please expand this text some.  You might want to look at
https://tools.ietf.org/html/rfc7390#section-6.1 for a t= emplate.


Jim


__________________________= _____________________
Ace mailing list
Ace@ietf.org
https://w= ww.ietf.org/mailman/listinfo/ace

__________________________= _____________________
Ace mailing list
Ace@ietf.org
https://w= ww.ietf.org/mailman/listinfo/ace
--=_f6bec0fa26e4ad54851a398fe2b9016e-- From nobody Wed Dec 19 12:22:50 2018 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 A5EEF130ED7 for ; Wed, 19 Dec 2018 12:22:47 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 iCOMUts4IXgS for ; Wed, 19 Dec 2018 12:22:45 -0800 (PST) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14C07130EC9 for ; Wed, 19 Dec 2018 12:22:45 -0800 (PST) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 19 Dec 2018 12:17:32 -0800 From: Jim Schaad To: 'Ludwig Seitz' , 'Hannes Tschofenig' , 'Stefanie Gerdes' , References: <154322421294.8323.8505315870685563404.idtracker@ietfa.amsl.com> <945fbebe-659f-ac72-3ab6-8e05447e7c92@ri.se> <1c5b81f3-50ce-be68-bec3-68ce2ff15b43@tzi.de> <4ae4eccd-68bf-18ef-f909-142f8172eca1@ri.se> <81ba3ab4-a9ce-a6fd-fbe6-c36a6fbbd9a5@tzi.de> <9f35177f-30d4-817e-dfc3-9a54903ab023@ri.se> In-Reply-To: Date: Wed, 19 Dec 2018 12:22:32 -0800 Message-ID: <035a01d497d8$941fa920$bc5efb60$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQK3+H3pFttPP+s38ebErlDfr5TlzwHGtbndAWWZiHUBoal9GAG606RNAr6sEpUBdBg41wIoMkRRAVy26uEBni/SMwLhh1vKAXfJk28ClIb+HQJIod4qAfJwDVsCR+KGWAKnCEv4osAIQ8A= Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Ace] Security of the Communication Between C and RS X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2018 20:22:48 -0000 > -----Original Message----- > From: Ludwig Seitz > Sent: Wednesday, December 19, 2018 5:24 AM > To: Hannes Tschofenig ; Stefanie Gerdes > ; Jim Schaad ; ace@ietf.org > Subject: Re: [Ace] Security of the Communication Between C and RS >=20 > On 19/12/2018 14:04, Hannes Tschofenig wrote: > > Thanks, Ludwig. The list of steps below help me to understand the = concern. > > > > ---- > > > > > > 1.) C obtains token and pop-key from AS > > 2.) C transmits token to RS and sets up secure communication (e.g. > > DTLS-PSK) using the pop-key > > 3.) C sends secure requests to the RS > > 4.) token expires, an attacker manages to get hold of the pop-key > > 5.) C continues to send requests containing sensitive information to = the RS , > attacker can now read the messages and spoof positive responses from = the RS. > C never notices that the token is invalid and that it is actually = talking to the > attacker. > > >=20 > > ---- > > > > In step (4) you tie the expiry of the token to the attacker getting > > hold of the key. What happens if the attacker gets hold of the pop = key > > before the token expires? >=20 > If it is detected the AS would revoke the token. Then the client = _could_ use > client introspection to get that information. Note that this is what = the CMU > people are looking at. I am having a real problem with the idea that we are going to start = adding the idea of revocation to the entire system. I would much = rather make sure that both sides are given an idea of when things are = going to expire and just make things expire relatively quickly. >=20 > > Additionally, if you use DTLS/TLS just having the PoP key still > > requires the attacker to run a new DTLS/TLS handshake with the RS. >=20 > If the pop-key was used as a basis for doing a DTLS-PSK handshake, the = attacker > should be able to hijack the connection and impersonate either party. This depends on the version of PSK that you are doing. If you use = PSK+ECDH then the attacker cannot hijack the connection. >=20 >=20 > > It would also be useful to know where the attacker got the PoP key > > from and how you can even detect the compromise. >=20 > That is a different story entirely. You could imagine the case of an = RS > improperly deleting an expired token and the associated pop-key, and = then > being subject to a physical attack that recovers that information. It would be more reasonable to say that if you are doing a physical = attack, then it would be easy to get an RPK and then you are the RS = until such a time as the AS is told that the key is no longer trusted. = In this case you will just continue getting tokens as a client which are = still valid and none of this is helpful in any event. Jim >=20 > > > > Additionally, there is the question why the RS wouldn't stop > > communicating if the token expired since it has that information. >=20 > The RS would indeed stop, but since the token is opaque to the client, = it has no > way of knowing that the token has expired, and our clever attacker is = using the > pop-key to impersonate the RS and maintain the illusion that the = connection is > still alive an running. >=20 > > Normally, the idea is that the RS has a protected resource and the > > client wants to access it. That's why the RS is asking the client to > > send a token that gives it access. > > >=20 > Yes but say e.g. that the RS is a message broker and the client is a = publisher, > writing sensitive data to the RS. >=20 >=20 > I think Steffi's point definitely warrants text in the security > considerations, outlining how a client could detect that a token has > expired. >=20 > /Ludwig >=20 > -- > Ludwig Seitz, PhD > Security Lab, RISE > Phone +46(0)70-349 92 51 From nobody Wed Dec 19 13:04:20 2018 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 E050B130E86 for ; Wed, 19 Dec 2018 13:04:14 -0800 (PST) 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, 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=cert.org 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 3gbrVIaaq5kz for ; Wed, 19 Dec 2018 13:04:12 -0800 (PST) Received: from taper.sei.cmu.edu (taper.sei.cmu.edu [147.72.252.16]) (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 C005F130EC9 for ; Wed, 19 Dec 2018 13:04:12 -0800 (PST) Received: from delp.sei.cmu.edu (delp.sei.cmu.edu [10.64.21.31]) by taper.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id wBJL482S003470 for ; Wed, 19 Dec 2018 16:04:08 -0500 DKIM-Filter: OpenDKIM Filter v2.11.0 taper.sei.cmu.edu wBJL482S003470 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1545253448; bh=iTFAkhCVo/swZhmFt0gkBB73ar+sF7kajiEk1ewzak0=; h=From:To:Subject:Date:References:In-Reply-To:From; b=N/27vXFLK/9EVuaT6rwdTt0vN3o5zqfbzlOiA0JwPaiQNAbmcN97YUOOGTuOx1awj e7IeWZFJGhcVTDC0SoC1jfyIBDKFkuUhmtfcGRcRNdUEzB+Nzexd7rGzlK1nWFDE6w uMlH5mhmVxZpCscobRNwV0qYG7/E6Xwdu3ylIHrM= Received: from CASSINA.ad.sei.cmu.edu (cassina.ad.sei.cmu.edu [10.64.28.249]) by delp.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id wBJL46wG027935 for ; Wed, 19 Dec 2018 16:04:06 -0500 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASSINA.ad.sei.cmu.edu ([10.64.28.249]) with mapi id 14.03.0415.000; Wed, 19 Dec 2018 16:04:05 -0500 From: Roman Danyliw To: "ace@ietf.org" Thread-Topic: Call for adoption of draft-palombini-ace-key-groupcomm Thread-Index: AdSI8aalNXFev0zyRSiL4RjyZD+fmQO6xo5w Date: Wed, 19 Dec 2018 21:04:04 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC0184C67754@marathon> References: <359EC4B99E040048A7131E0F4E113AFC0184C52E29@marathon> In-Reply-To: <359EC4B99E040048A7131E0F4E113AFC0184C52E29@marathon> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Ace] Call for adoption of draft-palombini-ace-key-groupcomm X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2018 21:04:15 -0000 Hello! Per the IETF 103 face-to-face meeting and the call on the mailing list, the= re is support to adopt this draft (draft-palombini-ace-key-groupcomm). Authors: please submit this draft as a -00 WG document (draft-ietf-ace-key-= groupcomm-00). Regards, Roman and Jim > -----Original Message----- > From: Ace [mailto:ace-bounces@ietf.org] On Behalf Of Roman Danyliw > Sent: Friday, November 30, 2018 4:59 PM > To: ace@ietf.org > Subject: [Ace] Call for adoption of draft-palombini-ace-key-groupcomm >=20 > Hello! >=20 > This is the start of a two week call for input on the WG adoption of the > document: >=20 > draft-palombini-ace-key-groupcomm > https://tools.ietf.org/html/draft-palombini-ace-key-groupcomm-02 >=20 > The document has been presented and discussed at the last few meetings; > and revisions have been made based on WG feedback. At the IETF 103 > meeting, there was support for adoption; and volunteers to review and > implement the draft. >=20 > Please provide feedback to the list/chairs if you believe that this docum= ent > should be adopted as a WG document. The adoption call will end on > December 14 2018. >=20 > Regards, > Roman and Jim >=20 > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace From nobody Wed Dec 19 13:04:27 2018 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 A90BD130EE1 for ; Wed, 19 Dec 2018 13:04:15 -0800 (PST) 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, 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=cert.org 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 g_HBJWerUSMi for ; Wed, 19 Dec 2018 13:04:14 -0800 (PST) Received: from taper.sei.cmu.edu (taper.sei.cmu.edu [147.72.252.16]) (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 C029B130EDA for ; Wed, 19 Dec 2018 13:04:12 -0800 (PST) Received: from korb.sei.cmu.edu (korb.sei.cmu.edu [10.64.21.30]) by taper.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id wBJL4BdX003476 for ; Wed, 19 Dec 2018 16:04:11 -0500 DKIM-Filter: OpenDKIM Filter v2.11.0 taper.sei.cmu.edu wBJL4BdX003476 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1545253451; bh=KEwKnfYMVCeKQ78E3DRo9OckNIf67b3PHM19ldKJBRU=; h=From:To:Subject:Date:References:In-Reply-To:From; b=KPIV5RPX/OzNZWJBWElVs/e/0dudO3Z6NvK8nUp2uVZPcpCbeYQtT3yyXS04deee+ Wh1i/Hz0u2QZSph0+v1OH6UST+5EtpYCJUBOMFp/yRXldZLerAzPox/zE5firM+xQ8 Kr3qcKsSozouR3KOE7UhiZOFyeFmyXZtah4J2e+E= Received: from CASCADE.ad.sei.cmu.edu (cascade.ad.sei.cmu.edu [10.64.28.248]) by korb.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id wBJL47I5028238 for ; Wed, 19 Dec 2018 16:04:07 -0500 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASCADE.ad.sei.cmu.edu ([10.64.28.248]) with mapi id 14.03.0415.000; Wed, 19 Dec 2018 16:04:06 -0500 From: Roman Danyliw To: "ace@ietf.org" Thread-Topic: Call for adoption of draft-tiloca-ace-oscoap-joining Thread-Index: AdSI95yhLiFsDREPRiCJ7cDGtjvMTAO5qH3A Date: Wed, 19 Dec 2018 21:04:05 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC0184C6775C@marathon> References: <359EC4B99E040048A7131E0F4E113AFC0184C52E21@marathon> In-Reply-To: <359EC4B99E040048A7131E0F4E113AFC0184C52E21@marathon> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Ace] Call for adoption of draft-tiloca-ace-oscoap-joining X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2018 21:04:16 -0000 Hello! Per the IETF 103 face-to-face meeting and the call on the mailing list, the= re is support to adopt this draft (draft-tiloca-ace-oscoap-joining). Authors: please submit this draft as a -00 WG document (draft-ietf-ace-osco= ap-joining-00). Regards, Roman and Jim > -----Original Message----- > From: Ace [mailto:ace-bounces@ietf.org] On Behalf Of Roman Danyliw > Sent: Friday, November 30, 2018 4:59 PM > To: ace@ietf.org > Subject: [Ace] Call for adoption of draft-tiloca-ace-oscoap-joining >=20 > Hello! >=20 > This is the start of a two week call for input on the WG adoption of the > document: >=20 > draft-tiloca-ace-oscoap-joining > https://tools.ietf.org/html/draft-tiloca-ace-oscoap-joining-05 >=20 > The document has been presented and discussed at the last few meetings; > and revisions have been made based on WG feedback. At the IETF 103 > meeting, there was support for adoption; and volunteers to review and > implement the draft. >=20 > Please provide feedback to the list/chairs if you believe that this docum= ent > should be adopted as a WG document. The adoption call will end on > December 14 2018. >=20 > Regards, > Roman and Jim >=20 > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace From nobody Wed Dec 19 23:40:20 2018 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 6DB891310BF for ; Wed, 19 Dec 2018 23:40:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=risecloud.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WTG2x_6Pib3H for ; Wed, 19 Dec 2018 23:40:15 -0800 (PST) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-am5eur02on0600.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe07::600]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 626A51310B1 for ; Wed, 19 Dec 2018 23:40:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=RISEcloud.onmicrosoft.com; s=selector1-ri-se; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=EG14pxTaX1x9owyEB6eGHOoGmeUbZxb3mvpg2a3acnc=; b=HVxXcCK+pjyfXZ1JbAxS8COwOYbs+39ymH/Xac2h+ALLbv/62HMh0dUXOaTi2PYxfRNI/wI693QFVr/6tziyNhuXV9ismekQVuHFDBcwq6vcTY68X9qdzBXx/ARQCTBJm2G7vICNYJt5AEJU4C/t4O5mdknGIByRmHPOBr36KjA= Received: from DB6P18901CA0023.EURP189.PROD.OUTLOOK.COM (2603:10a6:4:16::33) by AM5P189MB0322.EURP189.PROD.OUTLOOK.COM (2603:10a6:206:20::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1446.17; Thu, 20 Dec 2018 07:40:12 +0000 Received: from VE1EUR02FT026.eop-EUR02.prod.protection.outlook.com (2a01:111:f400:7e06::209) by DB6P18901CA0023.outlook.office365.com (2603:10a6:4:16::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1446.19 via Frontend Transport; Thu, 20 Dec 2018 07:40:12 +0000 Authentication-Results: spf=pass (sender IP is 194.218.146.197) smtp.mailfrom=ri.se; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=ri.se; Received-SPF: Pass (protection.outlook.com: domain of ri.se designates 194.218.146.197 as permitted sender) receiver=protection.outlook.com; client-ip=194.218.146.197; helo=mail.ri.se; Received: from mail.ri.se (194.218.146.197) by VE1EUR02FT026.mail.protection.outlook.com (10.152.12.77) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.20.1446.11 via Frontend Transport; Thu, 20 Dec 2018 07:40:12 +0000 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_128_CBC_SHA256_P256) id 15.1.1531.3; Thu, 20 Dec 2018 08:40:11 +0100 To: Jim Schaad , 'Hannes Tschofenig' , 'Stefanie Gerdes' , References: <154322421294.8323.8505315870685563404.idtracker@ietfa.amsl.com> <81ba3ab4-a9ce-a6fd-fbe6-c36a6fbbd9a5@tzi.de> <9f35177f-30d4-817e-dfc3-9a54903ab023@ri.se> <035a01d497d8$941fa920$bc5efb60$@augustcellars.com> From: Ludwig Seitz Message-ID: Date: Thu, 20 Dec 2018 08:40:11 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <035a01d497d8$941fa920$bc5efb60$@augustcellars.com> 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-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:194.218.146.197; IPV:NLI; CTRY:SE; EFV:NLI; SFV:NSPM; SFS:(10009020)(39860400002)(136003)(376002)(396003)(346002)(2980300002)(189003)(199004)(8676002)(476003)(81156014)(486006)(110136005)(81166006)(44832011)(126002)(65806001)(356004)(65956001)(76176011)(31686004)(106002)(16576012)(11346002)(2616005)(446003)(316002)(8936002)(77096007)(26005)(58126008)(14444005)(16526019)(186003)(106466001)(23676004)(2486003)(305945005)(7736002)(31696002)(40036005)(64126003)(22746007)(104016004)(22756006)(86362001)(65826007)(93886005)(68736007)(230700001)(5660300001)(67846002)(6116002)(36756003)(69596002)(6246003)(3846002)(2906002)(117156002)(47776003)(97736004)(50466002)(336012)(15650500001)(33896004)(386003)(53546011)(74482002)(229853002)(53936002)(508600001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM5P189MB0322; H:mail.ri.se; FPR:; SPF:Pass; LANG:en; PTR:InfoDomainNonexistent; MX:1; A:1; X-Microsoft-Exchange-Diagnostics: 1; VE1EUR02FT026; 1:OlWjdgMBu4bym2HxtE2Dj/zsE1yrL6ZHKPQ9d90T6XpvXnzuXKNXjRp90Mkv0XZFLwYRqepqkkMs6noPw1ir8OjY/ZG7hsippn+Rwqs5fPLx51COdWG3pJ9O+9C888li X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: de9dce32-fbb3-4a84-2142-08d6664e6004 X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600074)(711020)(4608076)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:AM5P189MB0322; X-Microsoft-Exchange-Diagnostics: 1; AM5P189MB0322; 3:1D78V1/8qVDMFwCUfVYYEijiQHhWdAVdcdQcMNsNQ5wC9DyBTh9UxNw3JIdNEgH2mHcZoiw6l1ZsGmaNt9hGFsvkQzSqEjre4dilMbq3eWDBoeba0om5IexqWa4LVRVQF7CAL0/2Lh8cY1oCk1b+FDSq+2/Pd02H29xCbuzwwzOrJr+hLVrTphrZXOM7+k4nqKK+v6bVUmh5Ti6/hZLs4nLiUMt5fRqTtWvMzJU5QGMRKkCKJHk3ViFAjd7TkVImYF8uFOAOlMdVRd9U9IFsxWe14Y45C2vvfUEc1LjI88oYprURjMxc6tDnwUInCyHhwVhxhMOv2jy6XwboLt/rN1abDM1mpLiz8Ci2vz5SWA8=; 25:oJB2A0PwSvqRyj2l5q9ByLLIE8VVoCYyefmhQWcS6+tV2OPa96DArPDg0VFvkeVhSIVMbWn9ktSBs9LMNBhSA7W2SkZ5a81mhHisUnKhCTgp21RRFKq/8M7TY03J1SWy3Mn1QglicikGZqWovX6LHUxbNXuep12qJU5Sc5JX8kP0ihjcC8ruTxK6mzy/xcHFu1xX8pYOYeZyEeXPmefo/CH5TdYG9w8NSwgwA6dyxMEMzczoNR81ONaH8tu8lVmLTyeRH30rgWDU8fxMbXBfa+zS8lB+25SCdL28YW5F2DkW8YN1y/96j447At8U3GJ1tJIwKVOt0bkVn9GYsnHVMw== X-MS-TrafficTypeDiagnostic: AM5P189MB0322: X-Microsoft-Exchange-Diagnostics: 1; AM5P189MB0322; 31:grG+7JQ/dI5cCoU4wobPybW+8QfZ8Icpodl8Uu5wAKRDg8KbzLgVETuu+D+47Wwyvw/UxbANG5KSmn/kVMGXvZgV4n7Y8vwNQqyi4/NGgEZgxLmyiJ/LeTcptNVm7tF4RlbI91nkPMeeWIIe47KNheAWUR6+eCeAlv8Moajb7ANK/MryZUb1lcv720523tMJeNng8EVt5AdVrN8XrzTk+jGqsU2/RaZtXNF/8E2Sijg=; 20:L3qf3My/En29JgXO+TqlJrdQ6Kgz+eiXa9DBtvGw0GMAm5VFlQ4ezDqFkLgFTXN3372PAkEtHY4s4XO/TXeQDRfme9gh3OKNdF9nHpVvmGof6DgYPpWW3r/Hw8IX1NhOpwGiWjFPLKMnuydKXZSLAipmO+ParUYUjzY5/Ju4BEcta0RCjZzONiX4WAUsTEWeMrktELwdF/CCVDaLhJSBpikobYjHDofMj7axJv8rdpjQenDhcWQwJteZ90mtdMxj; 4:8DSEKa/o6RRUfjFBHQtu7regYhdKWGew7DN2siFy0S+59KP4LW1LzeXRjSU+sHVbn3SF80t7AJogdUqUNOFJ6xww7KTrNZR5Y+/10Fd7YTCR6/x7DBVTvyMAnOv3xoTps7h+CflxrAOz4J297vrQk8G6/xFUuqJOSo6l/fbyBcoO800Sp6sdaJWzOC0PRdcs4v1mSZgdvr46nFTK0WQ1AHMv4cr7sfdphaaBsoNMo9c3mJbVM3lnbbhLBhmeQcOHuMLj3wJMGQ+oMKLpQjVkwg== X-Microsoft-Antispam-PRVS: X-MS-Exchange-SenderADCheck: 1 X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(3230021)(999002)(5005026)(6040522)(2401047)(8121501046)(93006095)(93004095)(3231475)(944501520)(52105112)(3002001)(10201501046)(149066)(150057)(6041310)(20161123560045)(20161123562045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(20161123558120)(201708071742011)(7699051)(76991095); SRVR:AM5P189MB0322; BCL:0; PCL:0; RULEID:; SRVR:AM5P189MB0322; X-Forefront-PRVS: 0892FA9A88 X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtBTTVQMTg5TUIwMzIyOzIzOm5JcHljVmk0UXJpWmgzSDlxVUhSZFY0NDJG?= =?utf-8?B?MzVlMWhzZWNyeTRuNytrM0wzOTZyajBOWlZnQ2h3OHVsdXFUTVRYQnppcG5m?= =?utf-8?B?MWZHbHZTS1pYWHN4QTFqSTgxc2NxN1A1RVVQbTluK3VkQVhoWWNKaUNxaFpa?= =?utf-8?B?dEpGZXMybTJjUGdvRDJhTG4wc1dGSklmVW5XZjIyTmVDZDA3RzcweDVtU3hT?= =?utf-8?B?aDNadHIrVktPSnVLbERMRUh4K09HbUdlYmExQW9qQUFRQWVzZUcweEh0V096?= =?utf-8?B?clhxVlJFd1Q0bWJWQkFqZHkreWl2R1pWTDdXdGRLd0JhUnl3UytjL0dRUUR1?= =?utf-8?B?b3VtMkN1YTI1K2p5WUdZNEJYSUFOTjltR0pNV2RHeUpMeWNNcWh4L3JpMDgy?= =?utf-8?B?L3dseXpLYWI2QmtTMHp2T29aeXRGdUdadFlVRjZPYnpNSEFuRitoZjNkOW9D?= =?utf-8?B?S2w1bmZFSmkxOFFpQzdqTnFBOTRNcFhhNyt4Y3Z2SXpCeXpnc2ZYUFNGdHFM?= =?utf-8?B?eGtWdHpLNUhGMW1jZXd4c2RiNTBhOVhtekdUc3FlSnhndGV5Tm1IQUI1aXF6?= =?utf-8?B?SzdXRlJwSG9kY095NFJ4c0d5N1l4N0w4aFRtQTdZbitKbzF5WGNmL01PcUgr?= =?utf-8?B?M0UraG9FbUVuZnM4dmtIS0xPdnQxSGo4VGpnQm9qSGg2L3lOZU9aaW04cmpr?= =?utf-8?B?dUc0L1E2cW1ETUg3c1FxY3hBNzl6VnRsdVB4M3JRVzVXeWl4MGZxWmM5V0F4?= =?utf-8?B?WUFZL0J6a2l2K2RvOFJIcTd0RlpiKzkzV2l5OWVYS3ZUcENUUDUxakw5QWRn?= =?utf-8?B?OGVYelptTkRBQ2JuTTdPaFlKTDdPZjVYdUMwWC92dnhqcVM5a3FncVZmWGRB?= =?utf-8?B?SlZrZGozQVU3VVBLRU9OTTltNjVmbGdycThidHBKK2UzRkNYaTVHN0x2K0hI?= =?utf-8?B?amlVNndmWWtuZldGd1VEVzdoNHJoTy9wNGVPeHBDU2tubGR6Z3hhSW5pVktI?= =?utf-8?B?WThhb1paTTlnM1BoUFJCeWVldlNBNFA3ZHZveTVTOGxxdi81N3VIdFdFN1VG?= =?utf-8?B?YWVIbndtRjRZV1hhSFZmU1VHQVpKaExILzZvZ0hwcWVVL1RzM3ZmWjFRWXNy?= =?utf-8?B?OG55bEFNTnRPUVh0S0RSbnAzS2tjYjM1RFRGclNaSXE3UERGeEgvZXAyVmE2?= =?utf-8?B?SG1mOUpMWGF6MzdXT2lwOThBTThOYWRwbFk4SnNLSlcyb3VDaC8vOTBTbk1C?= =?utf-8?B?RUsrdmRPZEZYckNnQmJiaU5jZTI4N1ptRGQ5MUl5WStQd25KenBsK2kxYVAz?= =?utf-8?B?c2JoZCtXNFo0NkhRc3p1T29GN204ZStSZW0wTVc2NjFGN0dNMTgrQ0pYc3o5?= =?utf-8?B?RzBVbU51bHA1b3B6cWVVcE1TQ3h0R1RydTU2NVhCdlZqZGt4bGx5WG16a25U?= =?utf-8?B?eGROL0Yrdisra1RZemhlcnVsMzZHbGhtbStHeGZRcVZyVGVmTWt5dmRLK051?= =?utf-8?B?ZnAwK1JZUHlhdDFYdkNPTFM0UklQNWtoQVZ2TVREa1R3N0I4dkVxL0lnaWky?= =?utf-8?B?V0k1WmZzZkJ5NldPUngza05RK09aUi9wdFRuWDEwd2Rzck5jb2J5ZlRpTk14?= =?utf-8?B?aERKYSs1dW11c3k1ZDVJeUJ1Ynp2N01wUWlwYU1qUXVDc29SYVdGcnlNUmpu?= =?utf-8?B?SkZ0K0lTcWViQWlQenVFR1htMmpITTAwSk1FREVsMHZ4UUpNcEk0RVJQSHg1?= =?utf-8?B?T3RMR0hmWlo2WURJbTFza3NjY1o4MnhEWndKM012UnpQVWZ5NzlqTXc1Znkz?= =?utf-8?B?STAyak9JWFo0enNGbVJXYlE3dDAyM3o4dnFSQkR4L3djTzRMWFgwMnU0Ryt1?= =?utf-8?B?VUlyQ1hnTDZOa1J2UkxXbDRPcUhvcm53clNDR2F1NVYwZldTQkVZUCtqYnZJ?= =?utf-8?B?OFpYL3R6WlA3Z01LdWFYbUlSTmVMZTZHRTc0MXlER3JUOWdTUC9NdFIvdkpH?= =?utf-8?B?UkFuV2xIRkxKUGlkOVFGREpEUGFQa0w1T1hkZ3d6TVpmWldJSVd1OEdkMGU0?= =?utf-8?B?YWhsb1FHUFVaODYzMUdEdVE0cE8rb21EclpJNHlqUWFhWFJHSWN4MlNkT2ZZ?= =?utf-8?B?MXc9PQ==?= X-Microsoft-Antispam-Message-Info: abYu3IrCvKH0BNKDsu1bugJPAHcACx5hiMouG+YdY7yfPfln4JhMnYcVJBIwfx3byRk43p0zej5sn31rf3hof+nZ5XhubLIgDINtwoPU0GB2K+ZClrApesZjXL5ccqC5BrBwCNETW1ACW3iT5kqcKJJtO8x/wUlZjrq65GaHy3EqcCjcQzImQ1FOzKQeia2g9Ya86aVcvht6XsJArCzxEiwDJZscsbMFHBQWKEC8jxc5r5aB2hIQLsJfX1mVCzLQ6Qd+8sZWaf6lmk0BJw1GPkO/IXOTf8InIUvescmmuV75VkJvYP96OQRdhCT2RI5C X-Microsoft-Exchange-Diagnostics: 1; AM5P189MB0322; 6:9oAbIdhnI6Tqwk/TUIpYZgk1soVXiV6tXUaZpkYVPYZLknpu8A7F95PppSedR0Qbe7VH8I0EgctzZrN2kcsKYBNxtGJmobNN1ANq02t2nF5KpZzL403NPfBa6F5BtZhSB6D+Zr5sRATkqizRIiLWcKV7CPrP5jGSW6oACs47Rj4GohMV/5FPTS8NmxrcfaUaQWpBiTxpSjcIcD4dnSodrCK1yECq0YUpkoHmbnRfq3+d5y7sMQqRm13BrYGcy0P7eG3r3qP1R/JNsLtWwZq8wwxiAzgJdW6Ik29hwiCxmg8Yj7HEwf15dfvG5Fx2qDr5Sg9wLVLxLY2CxfAnFNncZPvGUvJWD7euhlke4avuVEb9Woh8nRxU/KoGVvZCw9fqEnLbuy5+RGODctD8LPlQs1hY5c5l5CrPbOb8ZmXV72ZoVau+13+xEuWJ5fmw1QAlOEPwPqBM8gaPPpGWKG4sDw==; 5:+uXP0dBuzA6ATH1qyadSSUx0Z0gF9yk31RRZDCyPmQ8nl2tGgWmdAjm/+Agv+B4wxYmodBIcMru570Q9I0PyB24pu031RVldScU/7ueoJIZSvp+3xeFwdXcZ4hqrgLgKCKIA8Rr6dVZFZbD7JTLBBiaXUo6InZjLXYNSoDpKFao=; 7:ppH7DZdZRC6xJPLdXuckjqelu2nRJydcWGz32kxKBDTOWT/WTJb7XKCJxZMeLlJQyFnEHqsLTJyKhvznAuRehgmSGgt5BOyU7qxSTkaGSNje/qmSdWtYuB0Q1+CVjqU6z9oyMAw/5W6wtOSxVTYU4w== SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Dec 2018 07:40:12.2463 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: de9dce32-fbb3-4a84-2142-08d6664e6004 X-MS-Exchange-CrossTenant-Id: 5a9809cf-0bcb-413a-838a-09ecc40cc9e8 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=5a9809cf-0bcb-413a-838a-09ecc40cc9e8; Ip=[194.218.146.197]; Helo=[mail.ri.se] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5P189MB0322 Archived-At: Subject: Re: [Ace] Security of the Communication Between C and RS X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2018 07:40:19 -0000 On 19/12/2018 21:22, Jim Schaad wrote: > >>> In step (4) you tie the expiry of the token to the attacker >>> getting hold of the key. What happens if the attacker gets hold >>> of the pop key before the token expires? >> >> If it is detected the AS would revoke the token. Then the client >> _could_ use client introspection to get that information. Note that >> this is what the CMU people are looking at. > > I am having a real problem with the idea that we are going to start > adding the idea of revocation to the entire system. I would much > rather make sure that both sides are given an idea of when things are > going to expire and just make things expire relatively quickly. > It's quite unlike the revocation in PKI, it's just that an AS can mark a token as invalid, and this information would then be available to those who can do introspection. >> >>> Additionally, if you use DTLS/TLS just having the PoP key still >>> requires the attacker to run a new DTLS/TLS handshake with the >>> RS. >> >> If the pop-key was used as a basis for doing a DTLS-PSK handshake, >> the attacker should be able to hijack the connection and >> impersonate either party. > > This depends on the version of PSK that you are doing. If you use > PSK+ECDH then the attacker cannot hijack the connection. > Right of course. I suspect however that not all constrained devices would implement the PSK+ECDH handshake, or are the other PSK handshakes deprecated? >> >>> It would also be useful to know where the attacker got the PoP >>> key from and how you can even detect the compromise. >> >> That is a different story entirely. You could imagine the case of >> an RS improperly deleting an expired token and the associated >> pop-key, and then being subject to a physical attack that recovers >> that information. > > It would be more reasonable to say that if you are doing a physical > attack, then it would be easy to get an RPK and then you are the RS > until such a time as the AS is told that the key is no longer > trusted. In this case you will just continue getting tokens as a > client which are still valid and none of this is helpful in any > event. Ok my example was perhaps not ideal, since it has an even bigger breach as precondition. So under what conditions would an attacker get access to a pop-key of an expired token? Steffi any ideas? /Ludwig -- Ludwig Seitz, PhD Security Lab, RISE Phone +46(0)70-349 92 51 From nobody Thu Dec 20 01:11:38 2018 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 B44D413110D for ; Thu, 20 Dec 2018 01:11:36 -0800 (PST) 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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dkHPr8ZR7Mgk for ; Thu, 20 Dec 2018 01:11:28 -0800 (PST) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80089.outbound.protection.outlook.com [40.107.8.89]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16556131118 for ; Thu, 20 Dec 2018 01:11:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=/d068ELbbdYOCMrKJ+XVcQ6Bt6P/VCwYgZR5NoU5uns=; b=U4F6l06DlbtSNs8P5qRuADQo9Ev1iWfoNYOlgZnIEc/slL9P471nydrtFLcnM9/NaPACKNQw8tegZDKiOy8EieD7P4foET20EtjI6nPURpvN+e6KwVrH8QOxXbXIKmYyN/Ka/Q2HGPJMtYk0nRHeOkSQBP/tNDEdZjEBoepPWXU= Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB1616.eurprd08.prod.outlook.com (10.167.211.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1446.19; Thu, 20 Dec 2018 09:11:24 +0000 Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::e8de:6a41:cbf4:89d8]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::e8de:6a41:cbf4:89d8%4]) with mapi id 15.20.1446.020; Thu, 20 Dec 2018 09:11:24 +0000 From: Hannes Tschofenig To: Ludwig Seitz , Jim Schaad , 'Stefanie Gerdes' , "ace@ietf.org" Thread-Topic: [Ace] Security of the Communication Between C and RS Thread-Index: AQHUlquFKpsKbsbb2kGcq8Jrm430i6WELNAAgABWsZCAABAfgIAACmOwgAFP8YCAAAFuwIAABDYAgAAJ5ACAAAqnwIAABq+AgAB0+wCAAL1VgIAAFSBg Date: Thu, 20 Dec 2018 09:11:24 +0000 Message-ID: References: <154322421294.8323.8505315870685563404.idtracker@ietfa.amsl.com> <81ba3ab4-a9ce-a6fd-fbe6-c36a6fbbd9a5@tzi.de> <9f35177f-30d4-817e-dfc3-9a54903ab023@ri.se> <035a01d497d8$941fa920$bc5efb60$@augustcellars.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [80.92.114.221] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0801MB1616; 6:ubarc/BB5fOp8iIbxblyzR8TnYnrpGsMqUnMRfEPqXE8wlvpFZ5WELIXUi+fXwDrbFhpqiiDKhu+/rbW9dPBCoiwx2WT9Hpv3Qi1Chv74CQPCIgDFdQAWOnoRhGCy9NSEOBC9Ahm5vdVRa2ZthTWPjiCAs2hfEi7xXuSceSYgGKtqyUyLe7fz1zko0hWlgm7FUBLlobNVv0n3WR3MDF2lHf6yAnoQcQ/v8mtd44Ul81xIiPyiWbX/z5LyZ6Pw//CI6w4/46OVhefobE2DFIil0y0eRizRQsapqRm26COpJ1ghk8KBK9Xr33E27T4nrNo/cENZ1i+K907tdZMfVDL7+lTEau9T5mOIMa9tp8GTW5qBLOsvQkZrDNcmaugeOJtPNPxzk4lxhQR13IhK7Jjo8NVqpIBsJJJdaKcZn6LE0X4ydgehnPETyFr8/pWIDs/1PjR8Aun/dnxi3d5EP6lLw==; 5:bFlqHSrPhEKS1hF3pSYabOaPkys9iI7dUgVUTVlA75UJGpOSKflbNLy65ip36BtmfNru3ISlEdzkNLSE7MuYDu6MnVZZkzw/t909/W59X2vhUMt8hgwIhpu0mXm3I8DpfYTflnlgbooqaYarOfTGQj59IW1E3wzso0Vr2kD6BLk=; 7:+f4NTSpI0hQKF4HvVzzN2X0v20/KwoqU9nzsXDL8WaBHR0TThzsEMvflHdubJb/rwVVdxgSf8MAG5kRYkiD3ZWrjMMcYnGCjBMb2TOtyB3ccnMMlwR4hV/Kna3ZzKnkcOgPMixoj3uwqsDIOZEYO3g== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: d7014df8-87f7-4ad0-1a0f-08d6665b1dc0 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(4618075)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB1616; x-ms-traffictypediagnostic: VI1PR0801MB1616: x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(3230021)(999002)(5005026)(6040522)(2401047)(8121501046)(3002001)(10201501046)(93006095)(93001095)(3231475)(944501520)(52105112)(6055026)(149066)(150057)(6041310)(20161123558120)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(201708071742011)(7699051)(76991095); SRVR:VI1PR0801MB1616; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0801MB1616; x-forefront-prvs: 0892FA9A88 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(346002)(366004)(136003)(396003)(39860400002)(199004)(189003)(13464003)(40434004)(55016002)(76176011)(6506007)(2906002)(53546011)(71190400001)(7696005)(9686003)(71200400001)(110136005)(68736007)(86362001)(6116002)(316002)(6436002)(8676002)(229853002)(99286004)(3846002)(93886005)(8936002)(15650500001)(33656002)(186003)(81166006)(81156014)(74316002)(256004)(446003)(14444005)(102836004)(11346002)(5024004)(7736002)(2501003)(5660300001)(476003)(478600001)(53936002)(66066001)(97736004)(105586002)(25786009)(106356001)(72206003)(486006)(305945005)(14454004)(26005)(6246003); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB1616; H:VI1PR0801MB2112.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: EJVLqMTYwxZGwKNakmB12WHK4xrsugN4W5tkgww/fhNeRVneBjT3YPSGJ/Q0l54s1iw8hc/3nn0fpvuuahR+y26g1I1YSxVdLg4mLUqh155OhMR+6WzwvaMftP7d6z6wCswmkTAYT0cNf2DjUR1dJ9e9NGcpFZxG5FaN8EyRFSeG0tY44Mve0a3oq/cdAuPuFPDOwmHL2nmckV24RcpftgHd6ghLTby6v6FL2tX/3EC7ZuDwxmM3EkuJ2GtvlN9pcWwXKGabUukHOVBJfPwqJ0l16bVzpcp/HjXZZNk7sLDj4NrWuJj4zAhAikt8EA4W spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: d7014df8-87f7-4ad0-1a0f-08d6665b1dc0 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Dec 2018 09:11:24.5608 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1616 Archived-At: Subject: Re: [Ace] Security of the Communication Between C and RS X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2018 09:11:37 -0000 SGkgTHVkd2lnLCBIaSBKaW0NCg0KQSBmZXcgcmVtYXJrcyBiZWxvdzoNCg0KLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCkZyb206IEx1ZHdpZyBTZWl0eiA8bHVkd2lnLnNlaXR6QHJpLnNlPg0K U2VudDogRG9ubmVyc3RhZywgMjAuIERlemVtYmVyIDIwMTggMDg6NDANClRvOiBKaW0gU2NoYWFk IDxpZXRmQGF1Z3VzdGNlbGxhcnMuY29tPjsgSGFubmVzIFRzY2hvZmVuaWcgPEhhbm5lcy5Uc2No b2ZlbmlnQGFybS5jb20+OyAnU3RlZmFuaWUgR2VyZGVzJyA8Z2VyZGVzQHR6aS5kZT47IGFjZUBp ZXRmLm9yZw0KU3ViamVjdDogUmU6IFtBY2VdIFNlY3VyaXR5IG9mIHRoZSBDb21tdW5pY2F0aW9u IEJldHdlZW4gQyBhbmQgUlMNCg0KT24gMTkvMTIvMjAxOCAyMToyMiwgSmltIFNjaGFhZCB3cm90 ZToNCj4NCg0KPj4+IEluIHN0ZXAgKDQpIHlvdSB0aWUgdGhlIGV4cGlyeSBvZiB0aGUgdG9rZW4g dG8gdGhlIGF0dGFja2VyIGdldHRpbmcNCj4+PiBob2xkIG9mIHRoZSBrZXkuIFdoYXQgaGFwcGVu cyBpZiB0aGUgYXR0YWNrZXIgZ2V0cyBob2xkIG9mIHRoZSBwb3ANCj4+PiBrZXkgYmVmb3JlIHRo ZSB0b2tlbiBleHBpcmVzPw0KPj4NCj4+IElmIGl0IGlzIGRldGVjdGVkIHRoZSBBUyB3b3VsZCBy ZXZva2UgdGhlIHRva2VuLiBUaGVuIHRoZSBjbGllbnQNCj4+IF9jb3VsZF8gdXNlIGNsaWVudCBp bnRyb3NwZWN0aW9uIHRvIGdldCB0aGF0IGluZm9ybWF0aW9uLiBOb3RlIHRoYXQNCj4+IHRoaXMg aXMgd2hhdCB0aGUgQ01VIHBlb3BsZSBhcmUgbG9va2luZyBhdC4NCj4NCj4gSSBhbSBoYXZpbmcg YSByZWFsIHByb2JsZW0gd2l0aCB0aGUgaWRlYSB0aGF0IHdlIGFyZSBnb2luZyB0byBzdGFydA0K PiBhZGRpbmcgdGhlIGlkZWEgb2YgcmV2b2NhdGlvbiB0byB0aGUgZW50aXJlIHN5c3RlbS4gICBJ IHdvdWxkIG11Y2gNCj4gcmF0aGVyIG1ha2Ugc3VyZSB0aGF0IGJvdGggc2lkZXMgYXJlIGdpdmVu IGFuIGlkZWEgb2Ygd2hlbiB0aGluZ3MgYXJlDQo+IGdvaW5nIHRvIGV4cGlyZSBhbmQganVzdCBt YWtlIHRoaW5ncyBleHBpcmUgcmVsYXRpdmVseSBxdWlja2x5Lg0KPg0KDQpJdCdzIHF1aXRlIHVu bGlrZSB0aGUgcmV2b2NhdGlvbiBpbiBQS0ksIGl0J3MganVzdCB0aGF0IGFuIEFTIGNhbiBtYXJr IGEgdG9rZW4gYXMgaW52YWxpZCwgYW5kIHRoaXMgaW5mb3JtYXRpb24gd291bGQgdGhlbiBiZSBh dmFpbGFibGUgdG8gdGhvc2Ugd2hvIGNhbiBkbyBpbnRyb3NwZWN0aW9uLg0KDQpbSGFubmVzXSBJ IHNlZSByZXZvY2F0aW9uIGFuZCBleHBpcnkgb2YgY3JlZGVudGlhbHMgYXMgdHdvIHNvbWV3aGF0 IGRpZmZlcmVudCBjb25jZXB0cy4NCkluIE9BdXRoLCB3ZSBoYXZlIGEgc3BlYyB0aGF0IGRlYWxz IHdpdGggYSBsaW1pdGVkIGZvcm0gb2YgcmV2b2NhdGlvbiBidXQgdGhlIGJlc3QgbWl0aWdhdGlv biBJTUhPIGlzIHRvIGlzc3VlICJzaG9ydC1saXZlZCIgdG9rZW5zIChzaG9ydCBsaXZlZCBpbiB0 aGUgY29udGV4dCBvZiB0aGUgZ2l2ZW4gYXBwbGljYXRpb24gZG9tYWluKS4gVGhlIHRva2VuIGlu dHJvc3BlY3Rpb24gaW50ZXJmYWNlIGFsc28gcHJvdmlkZXMgYWRkaXRpb25hbCBjYXBhYmlsaXRp ZXMgZm9yIHJlYWwtdGltZSBjaGVja2luZyB0aGUgc3RhdHVzIG9mIGEgdG9rZW4uIEZpbmFsbHks IGl0IGlzIHdvcnRoIG1lbnRpb25pbmcgdGhlIFNlY0V2ZW50cyB3b3JrIGhlcmUgYXMgd2VsbC4N Cg0KSW4gcHJhY3RpY2UgaXQgaXMgZGlmZmljdWx0IHRvIHJldm9rZSB0b2tlbnMgaW4gYSB0aW1l bHkgZmFzaGlvbiBzaW5jZSB5b3UgaGF2ZSB0byBmaW5kIG91dCB0aGF0IHRoZXJlIGhhcyBiZWVu IGEgbGVha2FnZSBpbiB0aGUgZmlyc3QgcGxhY2UsIHdoaWNoIChhcyBtZWRpYSByZXBvcnRzIGlu ZGljYXRlKSBvZnRlbiB0YWtlcyBtb250aHMgaWYgbm90IHllYXJzIGZvciBjb21wYW5pZXMgdG8g bm90aWNlLg0KDQpSZWdhcmRpbmcgZXhwaXJ5IG9mIHRoZSB0b2tlbiwgd2UgaGF2ZSB0aGUgYWJp bGl0eSBmb3IgdGhlIEFTIHRvIHRlbGwgdGhlIGNsaWVudCBhcyB3ZWxsIGFzIHRoZSBSUyBob3cg bG9uZyB0aGUgdG9rZW4gaXMgdmFsaWQuIERvIHdlIHdhbnQgdG8gbWFuZGF0ZSBpdD8gRXZlbiBp ZiBJIGRvbid0IHNlZSB0aGUgaGFybSBpbiBub3QgcHJvdmlkaW5nIHRoZSBpbmZvIHRvIHRoZSBj bGllbnQgSSBhbSBzYXlpbmcgIndoeSBub3QiLiBJIGFtIGp1c3Qgbm90IHN1cmUgd2hldGhlciBt YW5kYXRvcmlseSBzZW5kaW5nIHRoZSBleHBpcmVkX2luIHBhcmFtZXRlciB0byB0aGUgY2xpZW50 IHdpbGwgaGVscCB0byBwcmV2ZW50IGFueSBhdHRhY2tzLg0KDQo+Pg0KPj4+IEFkZGl0aW9uYWxs eSwgaWYgeW91IHVzZSBEVExTL1RMUyBqdXN0IGhhdmluZyB0aGUgUG9QIGtleSBzdGlsbA0KPj4+ IHJlcXVpcmVzIHRoZSBhdHRhY2tlciB0byBydW4gYSBuZXcgRFRMUy9UTFMgaGFuZHNoYWtlIHdp dGggdGhlIFJTLg0KPj4NCj4+IElmIHRoZSBwb3Ata2V5IHdhcyB1c2VkIGFzIGEgYmFzaXMgZm9y IGRvaW5nIGEgRFRMUy1QU0sgaGFuZHNoYWtlLA0KPj4gdGhlIGF0dGFja2VyIHNob3VsZCBiZSBh YmxlIHRvIGhpamFjayB0aGUgY29ubmVjdGlvbiBhbmQgaW1wZXJzb25hdGUNCj4+IGVpdGhlciBw YXJ0eS4NCj4NCj4gVGhpcyBkZXBlbmRzIG9uIHRoZSB2ZXJzaW9uIG9mIFBTSyB0aGF0IHlvdSBh cmUgZG9pbmcuICBJZiB5b3UgdXNlDQo+IFBTSytFQ0RIIHRoZW4gdGhlIGF0dGFja2VyIGNhbm5v dCBoaWphY2sgdGhlIGNvbm5lY3Rpb24uDQo+DQoNClJpZ2h0IG9mIGNvdXJzZS4gSSBzdXNwZWN0 IGhvd2V2ZXIgdGhhdCBub3QgYWxsIGNvbnN0cmFpbmVkIGRldmljZXMgd291bGQgaW1wbGVtZW50 IHRoZSBQU0srRUNESCBoYW5kc2hha2UsIG9yIGFyZSB0aGUgb3RoZXIgUFNLIGhhbmRzaGFrZXMg ZGVwcmVjYXRlZD8NCg0KW0hhbm5lc10gSXQgcmVhbGx5IGRlcGVuZHMgd2hhdCBhc3N1bXB0aW9u cyB5b3UgbWFrZSBhYm91dCBob3cgdGhlIGF0dGFja2VyIG1hbmFnZWQgdG8gZ2V0IGFjY2VzcyB0 byB0aGUgUG9QIGtleSBpbiB0aGUgZmlyc3QgcGxhY2UsIHdoaWNoIHdlIGhhdmVuJ3QgcmVhbGx5 IGdvbmUgaW50byBhbnkgbGV2ZWwgb2YgZGV0YWlsLg0KRnJvbSBteSBleHBlcmllbmNlIChhcyBJ IG1lbnRpb25lZCB0byBKb2huICBNYXR0c3NvbiBpbiBoaXMgRFRMUy9UTFMgdnMuIE9TQ09SRSBw ZXJmb3JtYW5jZSBhbmFseXNpcykgdXNlIG9mIFBTSytFQ0RIKEUpIGlzIHJhdGhlciB1bmxpa2Vs eSBzaW5jZSB5b3UgYXJlIGVzc2VudGlhbGx5IGR1bXBpbmcgdGhlIHBvc2l0aXZlIGVmZmVjdHMg b2YgdGhlIFBTSy1iYXNlZCBtZWNoYW5pc20gd2hpbGUgbWFpbnRhaW5pbmcgYWxsIHRoZSBuZWdh dGl2ZSBhc3BlY3RzIG9mIHRoZSBsb25nLXRlcm0gUFNLIGNyZWRlbnRpYWwuDQoNCj4+DQo+Pj4g SXQgd291bGQgYWxzbyBiZSB1c2VmdWwgdG8ga25vdyB3aGVyZSB0aGUgYXR0YWNrZXIgZ290IHRo ZSBQb1Aga2V5DQo+Pj4gZnJvbSBhbmQgaG93IHlvdSBjYW4gZXZlbiBkZXRlY3QgdGhlIGNvbXBy b21pc2UuDQo+Pg0KPj4gVGhhdCBpcyBhIGRpZmZlcmVudCBzdG9yeSBlbnRpcmVseS4gWW91IGNv dWxkIGltYWdpbmUgdGhlIGNhc2Ugb2YgYW4NCj4+IFJTIGltcHJvcGVybHkgZGVsZXRpbmcgYW4g ZXhwaXJlZCB0b2tlbiBhbmQgdGhlIGFzc29jaWF0ZWQgcG9wLWtleSwNCj4+IGFuZCB0aGVuIGJl aW5nIHN1YmplY3QgdG8gYSBwaHlzaWNhbCBhdHRhY2sgdGhhdCByZWNvdmVycyB0aGF0DQo+PiBp bmZvcm1hdGlvbi4NCj4NCj4gSXQgd291bGQgYmUgbW9yZSByZWFzb25hYmxlIHRvIHNheSB0aGF0 IGlmIHlvdSBhcmUgZG9pbmcgYSBwaHlzaWNhbA0KPiBhdHRhY2ssIHRoZW4gaXQgd291bGQgYmUg ZWFzeSB0byBnZXQgYW4gUlBLIGFuZCB0aGVuIHlvdSBhcmUgdGhlIFJTDQo+IHVudGlsIHN1Y2gg YSB0aW1lIGFzIHRoZSBBUyBpcyB0b2xkIHRoYXQgdGhlIGtleSBpcyBubyBsb25nZXIgdHJ1c3Rl ZC4NCj4gSW4gdGhpcyBjYXNlIHlvdSB3aWxsIGp1c3QgY29udGludWUgZ2V0dGluZyB0b2tlbnMg YXMgYSBjbGllbnQgd2hpY2gNCj4gYXJlIHN0aWxsIHZhbGlkIGFuZCBub25lIG9mIHRoaXMgaXMg aGVscGZ1bCBpbiBhbnkgZXZlbnQuDQoNCk9rIG15IGV4YW1wbGUgd2FzIHBlcmhhcHMgbm90IGlk ZWFsLCBzaW5jZSBpdCBoYXMgYW4gZXZlbiBiaWdnZXIgYnJlYWNoIGFzIHByZWNvbmRpdGlvbi4g U28gdW5kZXIgd2hhdCBjb25kaXRpb25zIHdvdWxkIGFuIGF0dGFja2VyIGdldCBhY2Nlc3MgdG8g YSBwb3Ata2V5IG9mIGFuIGV4cGlyZWQgdG9rZW4/IFN0ZWZmaSBhbnkgaWRlYXM/DQoNCltIYW5u ZXNdIFdlIGRlZmluaXRlbHkgbmVlZCBzb21lIG1vcmUgZGV0YWlscyBhYm91dCB0aGUgdHlwZSBv ZiBhdHRhY2sgd2Ugd291bGQgbGlrZSB0byBwcmV2ZW50LiBNYXliZSBpdCBpcyB3b3J0aHdoaWxl IHRvIHRoaW5rIGFib3V0IHdoYXQgaW5mb3JtYXRpb24gdGhlIGF0dGFja2VyIHN0ZWFscyBmcm9t IHdob20gYXQgd2hhdCBwb2ludCBpbiB0aW1lIGNvdWxkIGJlIGEgd2F5IHRvIHByb2dyZXNzIHRo ZSB0b3BpYy4NCg0KQ2lhbw0KSGFubmVzDQoNCg0KL0x1ZHdpZw0KDQoNCg0KLS0NCkx1ZHdpZyBT ZWl0eiwgUGhEDQpTZWN1cml0eSBMYWIsIFJJU0UNClBob25lICs0NigwKTcwLTM0OSA5MiA1MQ0K SU1QT1JUQU5UIE5PVElDRTogVGhlIGNvbnRlbnRzIG9mIHRoaXMgZW1haWwgYW5kIGFueSBhdHRh Y2htZW50cyBhcmUgY29uZmlkZW50aWFsIGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5 b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5k ZXIgaW1tZWRpYXRlbHkgYW5kIGRvIG5vdCBkaXNjbG9zZSB0aGUgY29udGVudHMgdG8gYW55IG90 aGVyIHBlcnNvbiwgdXNlIGl0IGZvciBhbnkgcHVycG9zZSwgb3Igc3RvcmUgb3IgY29weSB0aGUg aW5mb3JtYXRpb24gaW4gYW55IG1lZGl1bS4gVGhhbmsgeW91Lg0K From nobody Thu Dec 20 06:27:16 2018 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 6B62812894E for ; Thu, 20 Dec 2018 06:27:15 -0800 (PST) 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, 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=sei.cmu.edu 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 3HSOxM0IwBfj for ; Thu, 20 Dec 2018 06:27:13 -0800 (PST) Received: from taper.sei.cmu.edu (taper.sei.cmu.edu [147.72.252.16]) (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 45C06126CB6 for ; Thu, 20 Dec 2018 06:27:12 -0800 (PST) Received: from delp.sei.cmu.edu (delp.sei.cmu.edu [10.64.21.31]) by taper.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id wBKEQYqC012859; Thu, 20 Dec 2018 09:26:34 -0500 DKIM-Filter: OpenDKIM Filter v2.11.0 taper.sei.cmu.edu wBKEQYqC012859 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sei.cmu.edu; s=t52kn2igOmwp; t=1545315996; bh=mpfFZOA2P3Vc0AIK4KZkU5CLGsYezAwa0nj5gU8M4YI=; h=From:To:Subject:Date:References:In-Reply-To:From; b=kEia/lSo1frV6seExKzaIZXGVkzQCl86oQ3qZK9m4QBlcmc/GSHwmhH04eTo/aAUM cnTsj3kHZbI0rERtNxLBnf/gtGW6mfJDgQJ++KoZgovLijtbXfzjbJWQzT8ZLoUWuf mmR0oIBXcja4URCcIRkhzCpkrZNydt971ifd2z9A= Received: from CASSINA.ad.sei.cmu.edu (cassina.ad.sei.cmu.edu [10.64.28.249]) by delp.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id wBKEQPbM048238; Thu, 20 Dec 2018 09:26:25 -0500 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASSINA.ad.sei.cmu.edu ([10.64.28.249]) with mapi id 14.03.0415.000; Thu, 20 Dec 2018 09:26:25 -0500 From: Sebastian Echeverria To: Ludwig Seitz , Hannes Tschofenig , Stefanie Gerdes , Jim Schaad , "ace@ietf.org" Thread-Topic: [Ace] Security of the Communication Between C and RS Thread-Index: AQHUl54xbWo2xcpeMkGAUWY2S07HVKWHrXNQ Date: Thu, 20 Dec 2018 14:26:24 +0000 Message-ID: <45D237D6DC600143A1C52C1C82BEBD1AABE14CAE@marathon> References: <154322421294.8323.8505315870685563404.idtracker@ietfa.amsl.com> <945fbebe-659f-ac72-3ab6-8e05447e7c92@ri.se> <1c5b81f3-50ce-be68-bec3-68ce2ff15b43@tzi.de> <4ae4eccd-68bf-18ef-f909-142f8172eca1@ri.se> <81ba3ab4-a9ce-a6fd-fbe6-c36a6fbbd9a5@tzi.de> <9f35177f-30d4-817e-dfc3-9a54903ab023@ri.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Ace] Security of the Communication Between C and RS X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2018 14:27:16 -0000 SGVsbG8sDQoNCj4+IElmIGl0IGlzIGRldGVjdGVkIHRoZSBBUyB3b3VsZCByZXZva2UgdGhlIHRv a2VuLiBUaGVuIHRoZSBjbGllbnQgX2NvdWxkXyB1c2UgY2xpZW50IGludHJvc3BlY3Rpb24gdG8g Z2V0IHRoYXQgaW5mb3JtYXRpb24uIE5vdGUgdGhhdCB0aGlzIGlzIHdoYXQgdGhlIENNVSBwZW9w bGUgYXJlIGxvb2tpbmcgYXQuDQoNClllcywgaGFuZGxpbmcgY29tcHJvbWlzZWQgUlNzIGlzIGlu IGZhY3Qgc29tZXRoaW5nIHRoYXQgd2UgaGF2ZSBiZWVuIGxvb2tpbmcgaW50by4gT3VyIG1haW4g Y29uY2VybiBpcyB0aGF0IGluIG91ciBzY2VuYXJpb3MsIHRoZSBlbnZpcm9ubWVudCBpcyBleHBl Y3RlZCB0byBiZSB2ZXJ5IGhvc3RpbGUgYW5kIGNvbm5lY3Rpb24gaXMgbGltaXRlZCBhbmQgaW50 ZXJtaXR0ZW50IChkaXNhZHZhbnRhZ2VkIG9yIERJTCBuZXR3b3JrcykuIFNpbmNlIHdlIHdhbnRl ZCB0byBhZGQgc29tZSBzdXBwb3J0IGZvciByZXZva2luZyB0b2tlbnMsIHdpdGhvdXQgaGF2aW5n IHRvIG1vZGlmeSB0aGUgZnJhbWV3b3JrIHRvIGhhbmRsZSB0b2tlbiByZXZvY2F0aW9uIGV4cGxp Y2l0bHksIHdoYXQgd2UgZW5kZWQgdXAgZG9pbmcgd2FzIHVzaW5nIGNsaWVudCBpbnRyb3NwZWN0 aW9uLCBhbG9uZyB3aXRoIHNvbWUgY2F2ZWF0cyBhbmQgc29tZSBjb25zaWRlcmF0aW9ucywgdG8g YmUgYWJsZSB0byBhZGQgdGhpcyBmdW5jdGlvbmFsaXR5LCBiZXNpZGVzIGFsc28gaGF2aW5nIHdh eXMgdG8gaGFuZGxlIGV4cGlyZWQgdG9rZW5zLiBUaGUgbWFpbiBhZHZhbnRhZ2Ugb2YgdGhpcyBp cywgYWdhaW4sIHRoYXQgd2UgYXJlbid0IHJlYWxseSBtb2RpZnlpbmcgb3IgZXZlbiBleHRlbmRp bmcgdGhlIEFDRSBmcmFtZXdvcmssIGJ1dCBqdXN0IHRha2luZyBhZHZhbnRhZ2Ugb2YgZnVuY3Rp b25hbGl0eSB0aGF0IGlzIGFscmVhZHkgdGhlcmUgdG8gaW1wbGVtZW50IHRoaXMgZnVuY3Rpb25h bGl0eSwgd2hpY2ggbWFrZXMgc2Vuc2UgaW4gb3VyIHVzZSBjYXNlLg0KDQpJbiBmYWN0LCB3ZSB3 ZXJlIGxvb2tpbmcgaW50byB3cml0aW5nIGEgQkNQLWxpa2UgZG9jdW1lbnQgc3VnZ2VzdGluZyB3 YXlzIHRvIGRvIHRoaXMgYmFzZWQgb24gd2hhdCB3ZSBkaWQuIFdlIHdlcmUgZW52aXNpb25pbmcg dGhpcyBhcyBtYXliZSB0aGUgc3RhcnRpbmcgcG9pbnQgb2YgYSBkb2N1bWVudCBjb250YWluaW5n IHByYWN0aWNlcyBvbiBob3cgdG8gYmV0dGVyIGhhbmRsZSBjbGllbnQgY29tbXVuaWNhdGlvbnMg d2l0aCBPQXV0aC9BQ0Ugd2hlbiB3ZSBhcmUgZGVhbGluZyB3aXRoIGRpc2FkdmFudGFnZWQgbmV0 d29ya3MgYW5kIGhvc3RpbGUgZW52aXJvbm1lbnRzLiBJZiB0aGVyZSBpcyBpbnRlcmVzdCBpbiB0 aGUgZ3JvdXAsIHdlIGNvdWxkIHNoYXJlIHRoYXQgZG9jdW1lbnQgaGVyZSwgYW5kIG1heWJlIGRp c2N1c3Mgd2hhdCBvdGhlciBwcmFjdGljZXMgY291bGQgYmUgYWRkZWQgdG8gaXQuDQoNClRoYW5r cywNCg0KLS0tDQpTZWJhc3RpYW4gRWNoZXZlcnJpYQ0KVGFjdGljYWwgVGVjaG5vbG9naWVzIEdy b3VwIChUVEcpDQpTb2Z0d2FyZSBFbmdpbmVlcmluZyBJbnN0aXR1dGUNCkNhcm5lZ2llIE1lbGxv biBVbml2ZXJzaXR5DQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogTHVk d2lnIFNlaXR6IFttYWlsdG86bHVkd2lnLnNlaXR6QHJpLnNlXSANClNlbnQ6IFdlZG5lc2RheSwg RGVjZW1iZXIgMTksIDIwMTggODoyNCBBTQ0KVG86IEhhbm5lcyBUc2Nob2ZlbmlnIDxIYW5uZXMu VHNjaG9mZW5pZ0Bhcm0uY29tPjsgU3RlZmFuaWUgR2VyZGVzIDxnZXJkZXNAdHppLmRlPjsgSmlt IFNjaGFhZCA8aWV0ZkBhdWd1c3RjZWxsYXJzLmNvbT47IGFjZUBpZXRmLm9yZw0KU3ViamVjdDog UmU6IFtBY2VdIFNlY3VyaXR5IG9mIHRoZSBDb21tdW5pY2F0aW9uIEJldHdlZW4gQyBhbmQgUlMN Cg0KT24gMTkvMTIvMjAxOCAxNDowNCwgSGFubmVzIFRzY2hvZmVuaWcgd3JvdGU6DQo+IFRoYW5r cywgTHVkd2lnLiBUaGUgbGlzdCBvZiBzdGVwcyBiZWxvdyBoZWxwIG1lIHRvIHVuZGVyc3RhbmQg dGhlIGNvbmNlcm4uDQo+IA0KPiAtLS0tDQo+IA0KPiANCj4gMS4pIEMgb2J0YWlucyB0b2tlbiBh bmQgcG9wLWtleSBmcm9tIEFTDQo+IDIuKSBDIHRyYW5zbWl0cyB0b2tlbiB0byBSUyBhbmQgc2V0 cyB1cCBzZWN1cmUgY29tbXVuaWNhdGlvbiAoZS5nLg0KPiBEVExTLVBTSykgdXNpbmcgdGhlIHBv cC1rZXkNCj4gMy4pIEMgc2VuZHMgc2VjdXJlIHJlcXVlc3RzIHRvIHRoZSBSUw0KPiA0LikgdG9r ZW4gZXhwaXJlcywgYW4gYXR0YWNrZXIgbWFuYWdlcyB0byBnZXQgaG9sZCBvZiB0aGUgcG9wLWtl eQ0KPiA1LikgQyBjb250aW51ZXMgdG8gc2VuZCByZXF1ZXN0cyBjb250YWluaW5nIHNlbnNpdGl2 ZSBpbmZvcm1hdGlvbiB0byB0aGUgUlMgLCBhdHRhY2tlciBjYW4gbm93IHJlYWQgdGhlIG1lc3Nh Z2VzIGFuZCBzcG9vZiBwb3NpdGl2ZSByZXNwb25zZXMgZnJvbSB0aGUgUlMuIEMgbmV2ZXIgbm90 aWNlcyB0aGF0IHRoZSB0b2tlbiBpcyBpbnZhbGlkIGFuZCB0aGF0IGl0IGlzIGFjdHVhbGx5IHRh bGtpbmcgdG8gdGhlIGF0dGFja2VyLg0KPiANCg0KPiAtLS0tDQo+IA0KPiBJbiBzdGVwICg0KSB5 b3UgdGllIHRoZSBleHBpcnkgb2YgdGhlIHRva2VuIHRvIHRoZSBhdHRhY2tlciBnZXR0aW5nIA0K PiBob2xkIG9mIHRoZSBrZXkuIFdoYXQgaGFwcGVucyBpZiB0aGUgYXR0YWNrZXIgZ2V0cyBob2xk IG9mIHRoZSBwb3Aga2V5IA0KPiBiZWZvcmUgdGhlIHRva2VuIGV4cGlyZXM/DQoNCklmIGl0IGlz IGRldGVjdGVkIHRoZSBBUyB3b3VsZCByZXZva2UgdGhlIHRva2VuLiBUaGVuIHRoZSBjbGllbnQg X2NvdWxkXyB1c2UgY2xpZW50IGludHJvc3BlY3Rpb24gdG8gZ2V0IHRoYXQgaW5mb3JtYXRpb24u IE5vdGUgdGhhdCB0aGlzIGlzIHdoYXQgdGhlIENNVSBwZW9wbGUgYXJlIGxvb2tpbmcgYXQuDQoN Cj4gQWRkaXRpb25hbGx5LCBpZiB5b3UgdXNlIERUTFMvVExTIGp1c3QgaGF2aW5nIHRoZSBQb1Ag a2V5IHN0aWxsIA0KPiByZXF1aXJlcyB0aGUgYXR0YWNrZXIgdG8gcnVuIGEgbmV3IERUTFMvVExT IGhhbmRzaGFrZSB3aXRoIHRoZSBSUy4NCg0KSWYgdGhlIHBvcC1rZXkgd2FzIHVzZWQgYXMgYSBi YXNpcyBmb3IgZG9pbmcgYSBEVExTLVBTSyBoYW5kc2hha2UsIHRoZSBhdHRhY2tlciBzaG91bGQg YmUgYWJsZSB0byBoaWphY2sgdGhlIGNvbm5lY3Rpb24gYW5kIGltcGVyc29uYXRlIGVpdGhlciBw YXJ0eS4NCg0KDQo+IEl0IHdvdWxkIGFsc28gYmUgdXNlZnVsIHRvIGtub3cgd2hlcmUgdGhlIGF0 dGFja2VyIGdvdCB0aGUgUG9QIGtleSANCj4gZnJvbSBhbmQgaG93IHlvdSBjYW4gZXZlbiBkZXRl Y3QgdGhlIGNvbXByb21pc2UuDQoNClRoYXQgaXMgYSBkaWZmZXJlbnQgc3RvcnkgZW50aXJlbHku IFlvdSBjb3VsZCBpbWFnaW5lIHRoZSBjYXNlIG9mIGFuIFJTIGltcHJvcGVybHkgZGVsZXRpbmcg YW4gZXhwaXJlZCB0b2tlbiBhbmQgdGhlIGFzc29jaWF0ZWQgcG9wLWtleSwgYW5kIHRoZW4gYmVp bmcgc3ViamVjdCB0byBhIHBoeXNpY2FsIGF0dGFjayB0aGF0IHJlY292ZXJzIHRoYXQgaW5mb3Jt YXRpb24uDQoNCj4gDQo+IEFkZGl0aW9uYWxseSwgdGhlcmUgaXMgdGhlIHF1ZXN0aW9uIHdoeSB0 aGUgUlMgd291bGRuJ3Qgc3RvcCANCj4gY29tbXVuaWNhdGluZyBpZiB0aGUgdG9rZW4gZXhwaXJl ZCBzaW5jZSBpdCBoYXMgdGhhdCBpbmZvcm1hdGlvbi4NCg0KVGhlIFJTIHdvdWxkIGluZGVlZCBz dG9wLCBidXQgc2luY2UgdGhlIHRva2VuIGlzIG9wYXF1ZSB0byB0aGUgY2xpZW50LCBpdCBoYXMg bm8gd2F5IG9mIGtub3dpbmcgdGhhdCB0aGUgdG9rZW4gaGFzIGV4cGlyZWQsIGFuZCBvdXIgY2xl dmVyIGF0dGFja2VyIGlzIHVzaW5nIHRoZSBwb3Ata2V5IHRvIGltcGVyc29uYXRlIHRoZSBSUyBh bmQgbWFpbnRhaW4gdGhlIGlsbHVzaW9uIHRoYXQgdGhlIGNvbm5lY3Rpb24gaXMgc3RpbGwgYWxp dmUgYW4gcnVubmluZy4NCg0KPiBOb3JtYWxseSwgdGhlIGlkZWEgaXMgdGhhdCB0aGUgUlMgaGFz IGEgcHJvdGVjdGVkIHJlc291cmNlIGFuZCB0aGUgDQo+IGNsaWVudCB3YW50cyB0byBhY2Nlc3Mg aXQuIFRoYXQncyB3aHkgdGhlIFJTIGlzIGFza2luZyB0aGUgY2xpZW50IHRvIA0KPiBzZW5kIGEg dG9rZW4gdGhhdCBnaXZlcyBpdCBhY2Nlc3MuDQo+DQoNClllcyBidXQgc2F5IGUuZy4gdGhhdCB0 aGUgUlMgaXMgYSBtZXNzYWdlIGJyb2tlciBhbmQgdGhlIGNsaWVudCBpcyBhIHB1Ymxpc2hlciwg d3JpdGluZyBzZW5zaXRpdmUgZGF0YSB0byB0aGUgUlMuDQoNCg0KSSB0aGluayBTdGVmZmkncyBw b2ludCBkZWZpbml0ZWx5IHdhcnJhbnRzIHRleHQgaW4gdGhlIHNlY3VyaXR5IA0KY29uc2lkZXJh dGlvbnMsIG91dGxpbmluZyBob3cgYSBjbGllbnQgY291bGQgZGV0ZWN0IHRoYXQgYSB0b2tlbiBo YXMgDQpleHBpcmVkLg0KDQovTHVkd2lnDQoNCi0tIA0KTHVkd2lnIFNlaXR6LCBQaEQNClNlY3Vy aXR5IExhYiwgUklTRQ0KUGhvbmUgKzQ2KDApNzAtMzQ5IDkyIDUxDQoNCg0K From nobody Thu Dec 20 07:19:37 2018 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 5DED5131159; Thu, 20 Dec 2018 07:19:23 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ace@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.89.2 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ace@ietf.org Message-ID: <154531916331.19019.1235256548847548604@ietfa.amsl.com> Date: Thu, 20 Dec 2018 07:19:23 -0800 Archived-At: Subject: [Ace] I-D Action: draft-ietf-ace-key-groupcomm-00.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2018 15:19:35 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Authentication and Authorization for Constrained Environments WG of the IETF. Title : Key Provisioning for Group Communication using ACE Authors : Francesca Palombini Marco Tiloca Filename : draft-ietf-ace-key-groupcomm-00.txt Pages : 17 Date : 2018-12-20 Abstract: This document defines message formats and procedures for requesting and distributing group keying material using the ACE framework, to protect communications between group members. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ace-key-groupcomm/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ace-key-groupcomm-00 https://datatracker.ietf.org/doc/html/draft-ietf-ace-key-groupcomm-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 Dec 20 07:20:33 2018 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 EF8A713112D; Thu, 20 Dec 2018 07:20:23 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ace@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.89.2 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ace@ietf.org Message-ID: <154531922394.19120.12685326537718103885@ietfa.amsl.com> Date: Thu, 20 Dec 2018 07:20:23 -0800 Archived-At: Subject: [Ace] I-D Action: draft-ietf-ace-key-groupcomm-oscore-00.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2018 15:20:30 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Authentication and Authorization for Constrained Environments WG of the IETF. Title : Key Management for OSCORE Groups in ACE Authors : Marco Tiloca Jiye Park Francesca Palombini Filename : draft-ietf-ace-key-groupcomm-oscore-00.txt Pages : 17 Date : 2018-12-20 Abstract: This document describes a method to request and provision keying material in group communication scenarios where communications are based on CoAP and secured with Object Security for Constrained RESTful Environments (OSCORE). The proposed method delegates the authentication and authorization of new client nodes that join an OSCORE group through a Group Manager server. This approach builds on the ACE framework for Authentication and Authorization, and leverages protocol-specific profiles of ACE to achieve communication security, proof-of-possession and server authentication. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ace-key-groupcomm-oscore/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ace-key-groupcomm-oscore-00 https://datatracker.ietf.org/doc/html/draft-ietf-ace-key-groupcomm-oscore-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/