From nobody Thu Jan 3 02:35:01 2019 Return-Path: X-Original-To: ace@ietf.org Delivered-To: ace@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EA6F8130DD4; Thu, 3 Jan 2019 02:34:46 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: internet-drafts@ietf.org To: Cc: ace@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.89.2 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ace@ietf.org Message-ID: <154651168691.29677.15465742659192273290@ietfa.amsl.com> Date: Thu, 03 Jan 2019 02:34:46 -0800 Archived-At: Subject: [Ace] I-D Action: draft-ietf-ace-oscore-profile-06.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, 03 Jan 2019 10:34:47 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Authentication and Authorization for Constrained Environments WG of the IETF. Title : OSCORE profile of the Authentication and Authorization for Constrained Environments Framework Authors : Francesca Palombini Ludwig Seitz Göran Selander Martin Gunnarsson Filename : draft-ietf-ace-oscore-profile-06.txt Pages : 26 Date : 2019-01-03 Abstract: This memo specifies a profile for the Authentication and Authorization for Constrained Environments (ACE) framework. It utilizes Object Security for Constrained RESTful Environments (OSCORE) to provide communication security, server authentication, and proof-of-possession for a key owned by the client and bound to an OAuth 2.0 access token. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ace-oscore-profile/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ace-oscore-profile-06 https://datatracker.ietf.org/doc/html/draft-ietf-ace-oscore-profile-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-oscore-profile-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jan 3 02:41:49 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EC9F128D0C for ; Thu, 3 Jan 2019 02:41:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.365 X-Spam-Level: X-Spam-Status: No, score=-4.365 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.065, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=b6tx6Lw1; dkim=pass (1024-bit key) header.d=ericsson.com header.b=YgaMsrrd 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 As_WDcamunDq for ; Thu, 3 Jan 2019 02:41:46 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 BE6BF128BCC for ; Thu, 3 Jan 2019 02:41:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/relaxed; q=dns/txt; i=@ericsson.com; t=1546512103; x=1549104103; 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=nPzNobxl/+E7iLTiIxahvr93ZVf+5/zjBU65frrTJd0=; b=b6tx6Lw1zBm1eHDGKuEJjLeBZEvrtt5DC50zQja049TlYFyopi6CFIXeYqc/Ga4V VSJmSyyqIlsukTRO5R8XS2SoNtUyPUR4MgtX8gVntWdzuMt9XJNW4VGaNGy9Yn6x OVpUhzfFLWIyD3E2c7hHFEVENenuxl3RsoGOROvbszU=; X-AuditID: c1b4fb30-41b3a9e00000355c-82-5c2de6e7295b Received: from ESESBMB503.ericsson.se (Unknown_Domain [153.88.183.116]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id CD.BD.13660.7E6ED2C5; Thu, 3 Jan 2019 11:41:43 +0100 (CET) Received: from ESESSMR504.ericsson.se (153.88.183.126) by ESESBMB503.ericsson.se (153.88.183.170) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Thu, 3 Jan 2019 11:41:34 +0100 Received: from ESESSMB503.ericsson.se (153.88.183.164) by ESESSMR504.ericsson.se (153.88.183.126) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Thu, 3 Jan 2019 11:41:34 +0100 Received: from EUR04-DB3-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; Thu, 3 Jan 2019 11:41:34 +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=nPzNobxl/+E7iLTiIxahvr93ZVf+5/zjBU65frrTJd0=; b=YgaMsrrd+iuryfHouo/oPndzYlytkiQMglnfNK8vPOB+Bk+OHHiv3VwArkBqO/Rv4hisCDaP5kUCQjGZhwQXbYvZ1lJVN4dkDCAfbwtfs1UHm6I5XRvsutcqpaeYpnIsmgobOYBYE9ttRiZtAnRMd/mZkCIjKdx6aOnT24ZUnPU= Received: from HE1PR0701MB2746.eurprd07.prod.outlook.com (10.168.188.140) by HE1PR0701MB3004.eurprd07.prod.outlook.com (10.168.93.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1495.5; Thu, 3 Jan 2019 10:41:33 +0000 Received: from HE1PR0701MB2746.eurprd07.prod.outlook.com ([fe80::1f9:b4c9:ef3d:32c9]) by HE1PR0701MB2746.eurprd07.prod.outlook.com ([fe80::1f9:b4c9:ef3d:32c9%4]) with mapi id 15.20.1516.000; Thu, 3 Jan 2019 10:41:33 +0000 From: Francesca Palombini To: "ace@ietf.org" CC: "ace-chairs@ietf.org" Thread-Topic: [Ace] I-D Action: draft-ietf-ace-oscore-profile-06.txt Thread-Index: AQHUo1Amu6H6z0c4oUu6abYg9EEPdKWda+sA Date: Thu, 3 Jan 2019 10:41:33 +0000 Message-ID: <94D9C44F-558E-4A3D-BFB9-6AA46648F2B6@ericsson.com> References: <154651168691.29677.15465742659192273290@ietfa.amsl.com> In-Reply-To: <154651168691.29677.15465742659192273290@ietfa.amsl.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=francesca.palombini@ericsson.com; x-originating-ip: [158.174.219.143] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HE1PR0701MB3004; 6:6jpUlJPW/1Ejckcoz0D2FckRWjxmu7EMgwTp4lvJZmccg1ybQFX5BOUdMJrvX99jzI8tUw3/whvz/mznI3xIQJNQIE3JHlGY+kb9pb7ZoZxqGc+gMG7ppzXMtInqOrLtyi653Hebg0CIjZyYy519Tz1kOE5D75fctOEiYgkgriiDuBVQOfrCuZGljmN/cHPSpbXhLZpj7yQLLDuN+Z6C5rN4VztNB7dmQwmOc8KvR65Fpws44MSkVkAkvMcXg34Y7n0CMe74+fmPkHjs5HCHrsPOwa/00cXkyp6pvPWai55Xu7T0Wq0YCnHWlCqJBqnGfKVsMiRwYGQt1jzrI8suU/60LL/iVbGysPKR9sDHUyKsvPevIOh8mkyLAH54p/o/54eaVukfFK8rk7fpeCGgAQl+JerUiypDrebAFEjDo2GZSRRi62lxORfK289k0g+q1qXeBd0k/EmCmiuIdL1w7w==; 5:2BXHw727qsCLcWun9azImBXosKo4BSz+5yB+SzPOxNHe7C6OsTzuLp7f+TVz8lHulK0Fy1KIeAv8lqs7hDerHFuBycVvd6SbY9Mv4/fQZ//N3DvrR+ymcynKzl6iszERypku86zrFyh5vSM3xyTvjSDOnk8nMq1ln150OAbzFMLaA97ZOHsdcej+kUrWfKKDA5HZrovBcmGA1foBibPUXA==; 7:BK0/WEYK4dcTP6FX7Ee0XGvvGiAXTsf9StU963sGzC/dAXCH2D3C1w+8cOHYyZGwZh6mD6yp0z1fePF8y7VK7piJ3jA8MJxbhQ3C1jR8rZ0AzyGTsqIMH1jttQxONGwa7b5xVW/WrqtJyW0QUV+DYg== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 66709e8c-02cf-4d60-6cd0-08d671680747 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600109)(711020)(2017052603328)(7153060)(7193020); SRVR:HE1PR0701MB3004; x-ms-traffictypediagnostic: HE1PR0701MB3004: x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(3230021)(908002)(999002)(5005026)(6040522)(8220060)(2401047)(8121501046)(10201501046)(3231475)(944501520)(52105112)(93006095)(93001095)(3002001)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123560045)(20161123558120)(20161123564045)(201708071742011)(7699051)(76991095); SRVR:HE1PR0701MB3004; BCL:0; PCL:0; RULEID:; SRVR:HE1PR0701MB3004; x-forefront-prvs: 0906E83A25 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(366004)(396003)(346002)(136003)(376002)(53754006)(189003)(199004)(316002)(6116002)(3846002)(33656002)(305945005)(7736002)(36756003)(68736007)(99286004)(82746002)(66574012)(86362001)(6916009)(106356001)(2351001)(4326008)(105586002)(450100002)(66066001)(53936002)(6246003)(478600001)(25786009)(2501003)(966005)(14444005)(5660300001)(14454004)(97736004)(5640700003)(6436002)(8936002)(1730700003)(8676002)(2616005)(446003)(476003)(229853002)(11346002)(81156014)(81166006)(26005)(76176011)(186003)(102836004)(256004)(71190400001)(71200400001)(6306002)(6512007)(2906002)(6506007)(486006)(83716004)(6486002)(44832011); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB3004; H:HE1PR0701MB2746.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: ULRfDcwOEYvpl33Qcz4cW/L+l2ndSJs6Mn7wXoYqGt8UilbirnYjd10qrHjTk21rb9dxw24TI8zamF9jTu0kcASAbG22Wh8SKVqbVXpl8/DRP+6bFKQ0TDhtFHtLaeW5HV6maVh/+YlwT2ipb1yPWBzNZaQ787k84QEqv52+kSJIQeowgtMyX5iIC/d6YPHGkDbMKcqt4kn3zu/28gC17BtR7gifkLe8m7erTm2YTQ2uh/wtAsJYcWEzDeJdiXG/xOiCdmAIlN7xp9dxVd4h28WxZjnVqAE3T5TtjJQKgkWI4v7XgIsbI3HTfIp5K2LR 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: 66709e8c-02cf-4d60-6cd0-08d671680747 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Jan 2019 10:41:33.0756 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB3004 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuplleLIzCtJLcpLzFFi42KZGbG9RPf5M90Yg7dbRS2m3f3NavH9Ww+z A5PHkiU/mQIYo7hsUlJzMstSi/TtErgyfr+dxlrwTqJi08/JzA2McyS6GDk5JARMJFa9mMfe xcjFISRwhFFi1rwdjBDOV0aJM8fXMoNUgTkXbnhAJBYzSdxbMoUJxGERmMAsMWPXGlaIzDQm if/th1ggnMeMEtsOXmcD6WcTsJG48PA9UBUHh4iAosT1R4kgYWYBfYlfDVdZQWxhAWeJjTNm MIHYIgIuEicOL2SDsI0kru4/AGazCKhILF38BOwkXgF7iQ3tJ9khznORuDqzAWwOp4CrxIL9 p8FsRgFZiS+Nq5khdolL3HoynwniaQGJJXvOM0PYohIvH/+Dqk+WuHK7jx0irizx/sJpRghb VuLS/G5wuEgItLBLHJo4CyqhK/Fh6lSoQb4S+7bcZ4cousQo8WveCaiEjsSFCQ9YIOx8ibMN L1ggiq4yS3R+uck0gdFoFpILZwEDiVlAU2L9Ln2IsIfE6Z5b7BC2osSU7odgNq+AoMTJmU9Y FjCyrmIULU4tTspNNzLSSy3KTC4uzs/Ty0st2cQITCQHt/w22MH48rnjIUYBDkYlHt4ZN3Vj hFgTy4orcw8xSnAwK4nwihXrxAjxpiRWVqUW5ccXleakFh9ilOZgURLn/SMkGCMkkJ5Ykpqd mlqQWgSTZeLglGpgnGh6/ZLHH0Z7cfn9bze/l8yqXabKumxl2uonXDUXk8M/O31bcND6UTD3 zkdJkceCCi0+bMy8/upa/sUHyvO+6v0V+PJOZJ/tkxeux6a0/+BrNuO7I62n9NuyIOPcTRuN 7pwrXV+c93P6Rr3KvvlkX9bf3PM23tszj4k8WNhy/PeptwEMCxdvVVFiKc5INNRiLipOBABV rEu2IAMAAA== Archived-At: Subject: Re: [Ace] I-D Action: draft-ietf-ace-oscore-profile-06.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, 03 Jan 2019 10:41:48 -0000 SGkgYWxsLA0KDQpBcyBwcm9taXNlZCwgaGVyZSBpcyB0aGUgdXBkYXRlIHdpdGggdGhlIGNoYW5n ZXMgZGVjaWRlZCBhdCBJRVRGMTA0LCBhbmQgYWRkaXRpb25hbCBjb21tZW50cyBmcm9tIEppbS4N ClBsZWFzZSBsZXQgdXMga25vdyBpZiB5b3UgaGF2ZSBhbnkgcmVtYWluaW5nIGNvbW1lbnQgdGhh dCB3ZSBzaG91bGQgYWRkcmVzcy4NCg0KVGhhbmtzLA0KRnJhbmNlc2NhDQoNCu+7v09uIDAzLzAx LzIwMTksIDExOjM2LCAiQWNlIG9uIGJlaGFsZiBvZiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmci IDxhY2UtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgaW50ZXJuZXQtZHJhZnRzQGlldGYu b3JnPiB3cm90ZToNCg0KICAgIA0KICAgIEEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJs ZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cyBkaXJlY3Rvcmllcy4NCiAgICBUaGlz IGRyYWZ0IGlzIGEgd29yayBpdGVtIG9mIHRoZSBBdXRoZW50aWNhdGlvbiBhbmQgQXV0aG9yaXph dGlvbiBmb3IgQ29uc3RyYWluZWQgRW52aXJvbm1lbnRzIFdHIG9mIHRoZSBJRVRGLg0KICAgIA0K ICAgICAgICAgICAgVGl0bGUgICAgICAgICAgIDogT1NDT1JFIHByb2ZpbGUgb2YgdGhlIEF1dGhl bnRpY2F0aW9uIGFuZCBBdXRob3JpemF0aW9uIGZvciBDb25zdHJhaW5lZCBFbnZpcm9ubWVudHMg RnJhbWV3b3JrDQogICAgICAgICAgICBBdXRob3JzICAgICAgICAgOiBGcmFuY2VzY2EgUGFsb21i aW5pDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICBMdWR3aWcgU2VpdHoNCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIEfDtnJhbiBTZWxhbmRlcg0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgTWFydGluIEd1bm5hcnNzb24NCiAgICAJRmlsZW5hbWUgICAgICAgIDogZHJh ZnQtaWV0Zi1hY2Utb3Njb3JlLXByb2ZpbGUtMDYudHh0DQogICAgCVBhZ2VzICAgICAgICAgICA6 IDI2DQogICAgCURhdGUgICAgICAgICAgICA6IDIwMTktMDEtMDMNCiAgICANCiAgICBBYnN0cmFj dDoNCiAgICAgICBUaGlzIG1lbW8gc3BlY2lmaWVzIGEgcHJvZmlsZSBmb3IgdGhlIEF1dGhlbnRp Y2F0aW9uIGFuZA0KICAgICAgIEF1dGhvcml6YXRpb24gZm9yIENvbnN0cmFpbmVkIEVudmlyb25t ZW50cyAoQUNFKSBmcmFtZXdvcmsuICBJdA0KICAgICAgIHV0aWxpemVzIE9iamVjdCBTZWN1cml0 eSBmb3IgQ29uc3RyYWluZWQgUkVTVGZ1bCBFbnZpcm9ubWVudHMNCiAgICAgICAoT1NDT1JFKSB0 byBwcm92aWRlIGNvbW11bmljYXRpb24gc2VjdXJpdHksIHNlcnZlciBhdXRoZW50aWNhdGlvbiwN CiAgICAgICBhbmQgcHJvb2Ytb2YtcG9zc2Vzc2lvbiBmb3IgYSBrZXkgb3duZWQgYnkgdGhlIGNs aWVudCBhbmQgYm91bmQgdG8gYW4NCiAgICAgICBPQXV0aCAyLjAgYWNjZXNzIHRva2VuLg0KICAg IA0KICAgIA0KICAgIFRoZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRy YWZ0IGlzOg0KICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYt YWNlLW9zY29yZS1wcm9maWxlLw0KICAgIA0KICAgIFRoZXJlIGFyZSBhbHNvIGh0bWxpemVkIHZl cnNpb25zIGF2YWlsYWJsZSBhdDoNCiAgICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtaWV0Zi1hY2Utb3Njb3JlLXByb2ZpbGUtMDYNCiAgICBodHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtYWNlLW9zY29yZS1wcm9maWxlLTA2DQogICAgDQog ICAgQSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0Og0KICAg IGh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLWFjZS1vc2NvcmUt cHJvZmlsZS0wNg0KICAgIA0KICAgIA0KICAgIFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2Ug YSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24NCiAgICB1bnRp bCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmll dGYub3JnLg0KICAgIA0KICAgIEludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkg YW5vbnltb3VzIEZUUCBhdDoNCiAgICBmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRz Lw0KICAgIA0KICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQogICAgQWNlIG1haWxpbmcgbGlzdA0KICAgIEFjZUBpZXRmLm9yZw0KICAgIGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYWNlDQogICAgDQoNCg== From nobody Thu Jan 3 22:17:38 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0494130F6D for ; Thu, 3 Jan 2019 22:17:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.387 X-Spam-Level: X-Spam-Status: No, score=-3.387 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.065, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.979, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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=DyMmi90k; dkim=pass (1024-bit key) header.d=ericsson.com header.b=cBwF1TjZ 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 J4VBcDLnreul for ; Thu, 3 Jan 2019 22:17:34 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 E32C5124D68 for ; Thu, 3 Jan 2019 22:17:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/relaxed; q=dns/txt; i=@ericsson.com; t=1546582651; x=1549174651; 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=HA7UZ3cULaJsG1TlCkQhsa7vFCJIk35+Vz5B7OgK+00=; b=DyMmi90k2A2054TFmzE8kDPZqaX0Kia04v+HjFK008YY7oLSDz5PA89ubJNbQ8Mq m3+eSv28ncgRFMnB339qdi3galvysh9Xw5gi6kYrpPaGxrtTmX3Ag5+nyi5Jpl+r ewoF7T8F9fD1sobfMTrgIJIgok/MDIUvSUCWGhdfJZA=; X-AuditID: c1b4fb25-d89ff70000005ff7-4e-5c2efa7bb588 Received: from ESESSMB505.ericsson.se (Unknown_Domain [153.88.183.123]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id E3.62.24567.B7AFE2C5; Fri, 4 Jan 2019 07:17:31 +0100 (CET) Received: from ESESSMR505.ericsson.se (153.88.183.127) by ESESSMB505.ericsson.se (153.88.183.166) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Fri, 4 Jan 2019 07:17:31 +0100 Received: from ESESSMB502.ericsson.se (153.88.183.163) by ESESSMR505.ericsson.se (153.88.183.127) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Fri, 4 Jan 2019 07:17:31 +0100 Received: from EUR02-AM5-obe.outbound.protection.outlook.com (153.88.183.157) 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 via Frontend Transport; Fri, 4 Jan 2019 07:17:30 +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=HA7UZ3cULaJsG1TlCkQhsa7vFCJIk35+Vz5B7OgK+00=; b=cBwF1TjZQAZ6PIHZJYwbVC9/xs/fdmTUpCgtGiJh/CY0doK6EUDcxqUDQD5yaznP2TG9a4Ea2RQasDcGVxbjxOfV/mgUMz5tNJ/UdEUy5zXxdGE1DULhgF3TpthG3PF1IYE6DsL80mGozsDZDDpOpwMbDqUY7tOs3Wl+lQnamvI= Received: from HE1PR07MB4172.eurprd07.prod.outlook.com (20.176.166.25) by HE1PR07MB3242.eurprd07.prod.outlook.com (10.170.246.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1495.5; Fri, 4 Jan 2019 06:17:30 +0000 Received: from HE1PR07MB4172.eurprd07.prod.outlook.com ([fe80::a006:7ef8:2fd:30a]) by HE1PR07MB4172.eurprd07.prod.outlook.com ([fe80::a006:7ef8:2fd:30a%4]) with mapi id 15.20.1495.005; Fri, 4 Jan 2019 06:17:28 +0000 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Kathleen Moriarty , "ace@ietf.org" CC: Francesca Palombini , John Mattsson , "secdispatch@ietf.org" Thread-Topic: [Secdispatch] EDHOC Thread-Index: AQHUou5Zx1xiDx+jgESY4I5hUyszWqWcqBGAgAINKAA= Date: Fri, 4 Jan 2019 06:17:27 +0000 Message-ID: References: <79FD6563-8ADA-4D73-B8D5-C3D70604CD76@gmail.com> In-Reply-To: <79FD6563-8ADA-4D73-B8D5-C3D70604CD76@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.14.0.181208 x-originating-ip: [79.102.183.102] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HE1PR07MB3242; 6:VHZv340PCjT5wOCNoed3szI9KPVAiOl+sDXRRi9O23qVzlaqAT6mWzJpnGXJ+50DJQVo9k2wo5ZQp/YT+Ex8QVL5THItWyXLmcpQvbPD3UOSmo2XO8y9qUojIn6pNXeZSaOSfkYcvVrlvrfIOZF+jhHgtEstRg4S5zu73UcvzqIvL05je7+w2t8tDcIA+hsNlst45PSih+CK8rmHxgosKgD3ot1U7u9kfYyC0jOWgE2A9XZkk/8KqOwG2J6rNIv/ByxlO+zH+PImR9dIAP0YTHmqMSrppHTnWEQYE+lo4XUwipyPxHoWWlU3Ncwxb1//P/URxsEnaOxCRAjf/OQ2eeANDOIbYovyRYp8TnEEs6wJj4lGwIfWP9gguP27iD3obiH6xzT5w4Rk3+320Qazz0Jb9v5+wYN8hs9Q4l8XcsMB/7EmbJRnbEFEPzvZtEj+/w/hmYPtgkA50Zl6kGnbZQ==; 5:VfElAYD3hCsYh8WQqUVcK4Htj1St5BVZ7xp0JcyJjMO20+VIS0LL0bdAwPzzox2dDOdjrYIPxODOT+lKhj2R19izoBR9H3gnmZRDEDwTsc3UwbyIVxh4QYY30ehydHUgJ7qUt8ssWDvXqJX86mVQhtITwOnarhch/v731ueg1S33DJluhwefyYA3jFMZJlPDnwifQiPLyo1Cq0N2yPp2gw==; 7:/A6gyTJtWCbmvb+gjyDTSiQRjSMiskQEVNM6CSfxLJWh5lEZYvcHSsKU/qv1EBCDECkI3f6P2Ktl9N2qvkVashXASAG1EWdXVIDWinxU4ygXys6x8iw/3q3fnH5ouWWhQt4EW9ZmLGoU4NlTSKJ9Bw== x-ms-exchange-antispam-srfa-diagnostics: SOS;SOR; x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10009020)(396003)(376002)(136003)(39860400002)(366004)(346002)(199004)(189003)(53546011)(102836004)(14454004)(476003)(6506007)(36756003)(486006)(7736002)(76176011)(8936002)(6246003)(66066001)(305945005)(81156014)(8676002)(81166006)(53936002)(446003)(25786009)(66574012)(4326008)(6512007)(6306002)(11346002)(2616005)(966005)(86362001)(186003)(2906002)(68736007)(478600001)(26005)(6346003)(39060400002)(97736004)(110136005)(256004)(14444005)(58126008)(54906003)(316002)(2501003)(85182001)(105586002)(85202003)(106356001)(6486002)(6436002)(6116002)(3846002)(5660300001)(229853002)(82746002)(71200400001)(83716004)(33656002)(71190400001)(99286004); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3242; H:HE1PR07MB4172.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; x-ms-office365-filtering-correlation-id: a34f4698-7806-4014-d550-08d6720c4d6f x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600109)(711020)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:HE1PR07MB3242; x-ms-traffictypediagnostic: HE1PR07MB3242: x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(3230021)(908002)(999002)(5005026)(6040522)(8220060)(2401047)(8121501046)(10201501046)(3002001)(3231475)(944501520)(52105112)(93006095)(93001095)(6041310)(20161123560045)(20161123562045)(20161123564045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(201708071742011)(7699051)(76991095); SRVR:HE1PR07MB3242; BCL:0; PCL:0; RULEID:; SRVR:HE1PR07MB3242; x-forefront-prvs: 0907F58A24 received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=goran.selander@ericsson.com; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: FcU/jdBfMF6fHEOZS5/SkBY0xnvQ9sQ2NlRqusrfu+p466mSLu6kONFkS6pn+G5frjirsDDXBXcUwW9bDnysEj/xxZuqEbxnQo/+O/5Qvvm6Wua2zwJD5H3MmiFgZH/eeTwCv0RZ6i4PjVMR5Q9dpnPkn2dJhY2ruSiLYo7/1Vk+Qbp3t5yKxZM6UmIDJ2SzgAvD5sZItGOI736vY5PvtgOMaYV4S3FsOaUevF4sC4VwTN1mLu9gO0Ko4SbwsAmMf5OHcSOWTUh1JEEEarUWY0BKy4Wtc3ruVUA7pNcTuGupy781URsozcOFqhyikd63 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <3ABDC45E3FF0054E9290EA55608C66C9@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: a34f4698-7806-4014-d550-08d6720c4d6f X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Jan 2019 06:17:28.2841 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3242 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA03SbUhTURgHcM7u3e51uDpbvjyogU4NVJyaRiaZGQV+SCiEKBFq5UVF3fTe JS6/rEbFXKQTcymmZX7JJGsJ8y2smZoaWaa9oaY2SckvJrY0sXZ3Lfr2+z/PA885h0MTiipx AJ2n0TGsRl2glEjJ2pP2suiydVVWbPVoVKLrxzUi0dCpTWx99158kEjrrJui0pqb10THRJnS /dlMQV4Jw8YcOCPNHWswUkUfwkur7CkGNBlWjmgacALUXg/iqcDPEZi3lyOpm6sIBpr6yX+h rbuCEMJdEVQuP/AEElcSsHqxRyJ0LCLoXh3eClMIZk0v3WNetAQfhhnDnIi3Dz4FtpoKxA8R 2IpgbKED8Y0dOBhuGOco/iQ+OASm72OBSXBrRsNPkDgM3tjrKd4ynAJ9X00kbwVmock67bEX ToZXjWsS3gj7gWu41bOWwP7wydnoMWAMzT2jhGBfWPyyKebti2Ng5vtTSqgrYbDXJhG8E8Ya zUjwJQpaJrIEx8HgvV7PSwDuk8DAk/GtBekwbq+SCI3XCDr7Jre2RcIjp4sUnA+b3Q5UieLr /jtgnfvOBI6Atq4YoZwGpu4FSnAIVJtnPZZhOQzVOsnbSNyCfDmGO1uYsztexbB55zhOq1Fp GJ0NuX/Ks/Zf4R3o7VKqA2EaKb1lsYuqLIVYXcLpCx0IaELpI8NL7pIsW62/wLDa0+z5AoZz oECaVPrLNhTyLAXOUeuYfIYpYti/XRHtFWBAmoCVO66yhMx2fXGybZ4NJWa9JkbqyYKI0t/x c0fZXYH7oipccoXxm8b14krDZ7s1fePxiDy1eE9IxmDr6Daqf0FrRsHWNuNQuO7qcVOHb6g3 kzGeFDjentxlq4kOswTpY1e6/NDNvZaH5GW83P7xpz7uSKjl0Py6gnSeWFWSXK46LpJgOfUf k9ANmiUDAAA= Archived-At: Subject: Re: [Ace] [Secdispatch] EDHOC 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, 04 Jan 2019 06:17:37 -0000 SGkgS2F0aGxlZW4sDQoNCkdvb2QgcXVlc3Rpb24uIFRoYW5rcyBmb3IgYnJpbmdpbmcgY29udGlu dWl0eSB0byB0aGlzIGFsbW9zdCAyIHllYXJzIGxvbmcgb2ZmbGluZSBkaXNjdXNzaW9uLiBJbmRl ZWQsIGxhY2sgb2YgY29tcGFyaXNvbiB3aXRoIG90aGVyIHByb3RvY29scyBhbmQgZm9ybWFsIHZl cmlmaWNhdGlvbiB3ZXJlIGF0IHRoZSB0aW1lIHRoZSBhcmd1bWVudHMgZm9yIG5vdCBmb2xsb3dp bmcgdXAgdGhlIGluLXJvb20gY29uc2Vuc3VzIHdpdGggYW4gZW1haWwgY29uZmlybWF0aW9uLiBB bmQsIGFzIHlvdSBub3RlZCwgdGhhdCBpcyBub3QgdGhlIGNhc2UgYW55bW9yZS4NCg0KTWVhbndo aWxlIHRoZSBBQ0UgY2hhaXJzIGFuZCBBRCBoYXZlIGNoYW5nZWQuIE15IHVuZGVyc3RhbmRpbmcg aXMgdGhhdCB0aGUgYXJndW1lbnQgbm93IGlzIGFib3V0IGF0dHJhY3RpbmcgbW9yZSBwZW9wbGUg d2l0aCBhIGNlcnRhaW4gc2VjdXJpdHkgY29tcGV0ZW5jZSBmb3Igd2hpY2ggcGVyaGFwcyBhbm90 aGVyIFdHIGNvdWxkIHBvdGVudGlhbGx5IGJlIGJldHRlciwgaGVuY2UgdGhlIHJlcXVlc3QgdG8g U2VjZGlzcGF0Y2guIEJ1dCBJJ2xsIHBhc3MgdGhlIHF1ZXN0aW9uIG9uIGFuZCBpbmNsdWRlIHRo ZSBBQ0UgV0cgZm9yIHRyYW5zcGFyZW5jeS4NCg0KRnJvbSB0aGUgYXV0aG9ycycgaHVtYmxlIHBv aW50IG9mIHZpZXcgd2UgYmVsaWV2ZSB0aGF0IHRoZSBtYWluIG1pc3NpbmcgdGhpbmcgdGhhdCB3 b3VsZCBlbmFibGUgdGhlIHJlcXVpcmVkIGZ1cnRoZXIgZGlzY3Vzc2lvbiBpcyB0aGF0IHRoZSBJ RVRGIGVuZG9yc2VzIHRoaXMgd29yaywgbm8gbWF0dGVyIGhvdywgc28gdGhhdCBwZW9wbGUgZGFy ZSBpbnZlc3QgbW9yZSB0aW1lIGluIGltcGxlbWVudGF0aW9uIGFuZCBhbmFseXNpcy4gDQoNCkJl c3QgcmVnYXJkcywNCkfDtnJhbg0KDQoNCu+7v09uIDIwMTktMDEtMDMsIDAwOjU4LCAiS2F0aGxl ZW4gTW9yaWFydHkiIDxrYXRobGVlbi5tb3JpYXJ0eS5pZXRmQGdtYWlsLmNvbT4gd3JvdGU6DQoN CiAgICBIaSwNCiAgICANCiAgICBJ4oCZdmUgcmVhZCBlYXJsaWVyIHZlcnNpb25zIG9mIHRoaXMg ZHJhZnQgYW5kIGFwcHJlY2lhdGUgYWxsIHRoZSB3b3JrIHlvdSBoYXZlIGRvbmUgd2l0aCB0aGUg c2VjdXJpdHkgcHJvb2YgYW5kIGNvbXBhcmluZyB0byBleGlzdGluZyBzdGFuZGFyZGl6ZWQgcHJv dG9jb2xzLiAgSWYgQUNFIGlzIGludGVyZXN0ZWQsIHdoeSBpcyB0aGlzIGdvaW5nIHRvIFNFQ0Rp c3BhdGNoPyBJdCBtaWdodCBoZWxwIHRvIHVuZGVyc3RhbmQgdGhhdCBiZXR0ZXIuICBJcyBpdCB0 aGF0IGEgcmVjaGFydGVyIHdvdWxkIGJlIG5lZWRlZD8NCiAgICANCiAgICBUaGFuayB5b3UgJiBo YXBweSBuZXcgeWVhciENCiAgICBLYXRobGVlbiANCiAgICANCiAgICBTZW50IGZyb20gbXkgbW9i aWxlIGRldmljZQ0KICAgIA0KICAgID4gT24gSmFuIDIsIDIwMTksIGF0IDU6NTYgUE0sIEfDtnJh biBTZWxhbmRlciA8Z29yYW4uc2VsYW5kZXJAZXJpY3Nzb24uY29tPiB3cm90ZToNCiAgICA+IA0K ICAgID4gRGVhciBTZWNkaXNwYXRjaCwNCiAgICA+IA0KICAgID4gV2UgaGF2ZSBiZWVuIGFkdmlz ZWQgdG8gYXNrIHNlY2Rpc3BhdGNoIHRvIGNvbnNpZGVyIEVESE9DOiBodHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtc2VsYW5kZXItYWNlLWNvc2UtZWNkaGUNCiAgICA+IA0KICAgID4g VGhvc2UgdGhhdCBmb2xsb3cgdGhlIEFDRSBXRyBzaG91bGQgYmUgZmFtaWxpYXIgd2l0aCB0aGlz IGRyYWZ0LiBUaGUgcHJvYmxlbSBzdGF0ZW1lbnQgYW5kIG1vdGl2YXRpb24gZm9yIEVESE9DIGlz IGRlc2NyaWJlZCBpbiBzZWN0aW9uIDEuIEluIGJyaWVmLCB0aGUgdGFyZ2V0IGlzIGEgbGlnaHR3 ZWlnaHQga2V5IGV4Y2hhbmdlIHByb3RvY29sIHN1aXRhYmxlIGZvciBJb1QgYXBwbGljYXRpb25z LCB3aGljaDoNCiAgICA+IGEpIGhhcyBzbWFsbCBtZXNzYWdlIHNpemUgYW5kIHJldXNlcyBleGlz dGluZyBJb1QgcHJpbWl0aXZlcyB0byBlbmFibGUgbG93IG92ZXJoZWFkIGFuZCBzbWFsbCBjb2Rl IGZvb3RwcmludDsgDQogICAgPiBiKSBpcyBub3QgYm91bmQgdG8gYSBwYXJ0aWN1bGFyIHRyYW5z cG9ydCwgdG8gZW5hYmxlIGVuZC10by1lbmQgc2VjdXJpdHkgaW4gSW9UIGRlcGxveW1lbnRzIHdp dGggdmFyeWluZyB1bmRlcmx5aW5nIGxheWVyczsgYW5kDQogICAgPiBjKSBjYW4gYmUgdXNlZCB0 byBrZXkgT1NDT1JFIChkcmFmdC1pZXRmLWNvcmUtb2JqZWN0LXNlY3VyaXR5KSB0aGF0IGlzIGxh Y2tpbmcgYSBoYXJtb25pemluZyBrZXkgZXhjaGFuZ2UgcHJvdG9jb2wuDQogICAgPiANCiAgICA+ IFRoZXNlIHJlcXVpcmVtZW50cyBhcmUgbW90aXZhdGVkIGJ5IGNvbnN0cmFpbmVkIElvVCBkZXZp Y2UgZGVwbG95bWVudHMsIGJ1dCB0aGUgcHJvdG9jb2wgaXMgYXBwbGljYWJsZSB0byBvdGhlciBl bmQtdG8tZW5kIHNlY3VyaXR5IHNldHRpbmdzIHdoZXJlIHRoZSBvdmVyaGVhZCBkdWUgdG8gc2Vj dXJpdHkgbmVlZHMgdG8gYmUgbG93LiBFREhPQyBhZGRyZXNzZXMgdGhlc2UgcmVxdWlyZW1lbnRz IGFuZCBidWlsZHMgb24gdGhlIFNJR01BIGNvbnN0cnVjdGlvbiBmb3IgRGlmZmllLUhlbGxtYW4g a2V5IGV4Y2hhbmdlcy4gRURIT0MsIGxpa2UgT1NDT1JFLCBpcyBidWlsdCBvbiBDQk9SIChSRkMg NzA0OSkgYW5kIENPU0UgKFJGQyA4MTUyKSBhbmQgdGhlIHByb3RvY29sIG1lc3NhZ2VzIG1heSBi ZSB0cmFuc3BvcnRlZCB3aXRoIENvQVAgKFJGQyA3MjUyKS4gIA0KICAgID4gDQogICAgPiBUaGVy ZSBoYXMgYmVlbiBhIG51bWJlciBvZiByZXZpZXdzIG9mIGRpZmZlcmVudCB2ZXJzaW9ucyBvZiB0 aGUgZHJhZnQ7IGJvdGggYnkgcGVvcGxlIHdobyB3YW50IHRvIGRlcGxveSBpdCBhbmQgYnkgcGVv cGxlIGFuYWx5c2luZyB0aGUgc2VjdXJpdHkuIEEgZm9ybWFsIHZlcmlmaWNhdGlvbiB3YXMgcHJl c2VudGVkIGF0IFNTUiAyMDE4LiBUaGVyZSBhcmUgYSBmZXcgaW1wbGVtZW50YXRpb25zIG9mIGRp ZmZlcmVudCB2ZXJzaW9ucyBvZiB0aGUgZHJhZnQuIFRoZSBBQ0UgV0cgaGFzIGV4cHJlc3NlZCBp bnRlcmVzdCBpbiB0aGlzIHdvcmsgaW4gc2V2ZXJhbCBmMmYgbWVldGluZ3MuDQogICAgPiANCiAg ICA+IFBsZWFzZSBsZXQgdXMga25vdyBpZiBzb21lIGluZm9ybWF0aW9uIGlzIG1pc3NpbmcgZm9y IHNlY2Rpc3BhdGNoIHRvIGNvbnNpZGVyIHRoaXMgZHJhZnQsIG9yIGhvdyB3ZSBjYW4gaGVscCBv dXQgaW4gdGhlIHByb2Nlc3MuDQogICAgPiANCiAgICA+IEJlc3QgcmVnYXJkcw0KICAgID4gR8O2 cmFuLCBKb2huLCBGcmFuY2VzY2ENCiAgICA+IA0KICAgID4gDQogICAgPiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgID4gU2VjZGlzcGF0Y2ggbWFp bGluZyBsaXN0DQogICAgPiBTZWNkaXNwYXRjaEBpZXRmLm9yZw0KICAgID4gaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZWNkaXNwYXRjaA0KICAgIA0KDQo= From nobody Tue Jan 8 07:11:04 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2177912894E for ; Tue, 8 Jan 2019 07:11:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.366 X-Spam-Level: X-Spam-Status: No, score=-4.366 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.065, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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=VnFOEwaV; dkim=pass (1024-bit key) header.d=ericsson.com header.b=ZFOuHcmo 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 hfk_ULC16Zx5 for ; Tue, 8 Jan 2019 07:11:00 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 534911277CC for ; Tue, 8 Jan 2019 07:11:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/relaxed; q=dns/txt; i=@ericsson.com; t=1546960258; x=1549552258; 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=/0wUwZxkMyFPkzdmdZAvX94zDE7cQRR0nPMC30pN44g=; b=VnFOEwaVJA/9/Gc0fPD9VihSQlX9FBwoBcn9troGBlbgy1QIAv/8xydpnzPMUAvp ++BWLzENfFfu+wzvFv69Exx8HWinvJvzfCwzLCDD3Xd13cJHjS/haJh6yJd4mXCI y2+I6b4RHzb1b/hhM4Mx4anMie95GiEmVrSIzaup8xM=; X-AuditID: c1b4fb30-f93ff7000000355c-e5-5c34bd82e571 Received: from ESESSMB505.ericsson.se (Unknown_Domain [153.88.183.123]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 2E.33.13660.28DB43C5; Tue, 8 Jan 2019 16:10:58 +0100 (CET) Received: from ESESBMR505.ericsson.se (153.88.183.201) by ESESSMB505.ericsson.se (153.88.183.166) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Tue, 8 Jan 2019 16:10:58 +0100 Received: from ESESBMB505.ericsson.se (153.88.183.172) by ESESBMR505.ericsson.se (153.88.183.201) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Tue, 8 Jan 2019 16:10:58 +0100 Received: from EUR02-VE1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESBMB505.ericsson.se (153.88.183.172) 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; Tue, 8 Jan 2019 16:10:57 +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=/0wUwZxkMyFPkzdmdZAvX94zDE7cQRR0nPMC30pN44g=; b=ZFOuHcmoAiAEHEJUFckC2NkwtfEyhmiUCMMqYw5ok6djTtn/NInE/zQhLXlHI3Zs7Rc4NL+K2+ScZ8xZDUWqdeflOr2NpAS/nrtnCjPDucLeu+v0wR9PzcMRs9ShV2C2IjxlIxgclX245nru6kTxEn5o/aDgxRzkrtk6De1Sumc= Received: from HE1PR0701MB2746.eurprd07.prod.outlook.com (10.168.188.140) by HE1PR0701MB2364.eurprd07.prod.outlook.com (10.168.128.7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1516.10; Tue, 8 Jan 2019 15:10:56 +0000 Received: from HE1PR0701MB2746.eurprd07.prod.outlook.com ([fe80::1f9:b4c9:ef3d:32c9]) by HE1PR0701MB2746.eurprd07.prod.outlook.com ([fe80::1f9:b4c9:ef3d:32c9%4]) with mapi id 15.20.1516.010; Tue, 8 Jan 2019 15:10:56 +0000 From: Francesca Palombini To: "ace@ietf.org" Thread-Topic: draft-ietf-ace-key-groupcomm and draft-ietf-ace-key-groupcomm-oscore status Thread-Index: AQHUp2Rb7L4/KPoOy0yQnqeIkTw/7Q== Date: Tue, 8 Jan 2019 15:10:56 +0000 Message-ID: <7D083833-1C94-49CB-8373-440726AA55DE@ericsson.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=francesca.palombini@ericsson.com; x-originating-ip: [192.176.1.88] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HE1PR0701MB2364; 6:CQZrvptYN8oKjprcH5nNoeEwghTAq5k3S9fEO6kcWTrutkx6xlB8LKDvTTLxT3+nJvVBb1sLDqi6btqBAQmXH2mOiYRI/drjaFbTi+r0T9BkKAl0Sru3tLDx7a8rzRKInQF8TAqNGNAcgJn47rpeDFiQul2HmpKH13ujmnGlNtVcWZeZ8MorXjAnQudSNnz4Yr4ZGmCIKr7f79X/smP+2T/8gSQMJqdtQHjtNaCZwGShIH8TPqgu/agEnkqNb2mbveHdCjTfR1F5PqFUp2cpoEhO3Ar6GZz64Uj5WVMj9SjctRebXPtOyIZsX1tqVkLg0AQ7YJbLG+qyhe0jzmVfl9cJXclh7WJl/JZWd3B4JMbnYiaUbnfDYRD+Ta5w89D/UpCJfekm4QMgnWSjfd8KRJRdpfDMWlQm7a1d27wy+X2PCud0e6t29YsUgipThJbiDB5zIq2NZlitI/K1+NOaAw==; 5:NaESh0hGw2lgOGZ4SBz86CgL/MOG3uoFnPyE/SW4ZuOgQOm6nDYnuj52aDJgRrCZPVYpNn+tA7UnkMp6KoOgNYG1zT2RhocNFw3oYYupI0NW/316hUEp8yevfbHefDwtp+CkpV4EqwgoA9L92KRPpkBDrHuHU/X1qVoQbMaaaiZjNG/I6vazPuljGT59WiW3Z1DJJvfrBEneFJ2R5vPtRQ==; 7:p9ZdTFFoX46086vsNpRSnVQkrGkKcBgIwS3o7vh0MaDbshMpYUeQIIr7IujpYhN6sUrKtAwezjHqE1MT/vfT+Lm13pPhxOP40DwMoREM0bgtylBstDGfcCCAPVO0ogyIOZ1yISarvhT5P4E/aeljFA== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 8c18ef23-3fa1-4dd5-56a8-08d6757b7d9f x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600109)(711020)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:HE1PR0701MB2364; x-ms-traffictypediagnostic: HE1PR0701MB2364: x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(3230021)(908002)(999002)(5005026)(6040522)(8220060)(2401047)(8121501046)(3231475)(944501520)(52105112)(93006095)(93001095)(10201501046)(3002001)(6041310)(20161123558120)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(201708071742011)(7699051)(76991095); SRVR:HE1PR0701MB2364; BCL:0; PCL:0; RULEID:; SRVR:HE1PR0701MB2364; x-forefront-prvs: 0911D5CE78 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(376002)(366004)(136003)(346002)(396003)(189003)(199004)(71200400001)(71190400001)(36756003)(83716004)(2616005)(82746002)(86362001)(6506007)(26005)(186003)(102836004)(476003)(5640700003)(6486002)(6916009)(2351001)(8676002)(68736007)(5660300001)(2906002)(53936002)(6436002)(105586002)(81166006)(1730700003)(81156014)(7736002)(8936002)(6512007)(305945005)(256004)(33656002)(106356001)(25786009)(6306002)(316002)(99286004)(2501003)(6116002)(3846002)(486006)(44832011)(97736004)(478600001)(966005)(14454004)(66066001); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2364; H:HE1PR0701MB2746.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: sQaKTEm7/gNVO87hzCJ8ZHRHVdgD4P7jm5xWbT3SJloUU/8Fn0lnN6Nnbjjn3kRGRXlHW1QPCJnCQYybksgJb4RgmEtEflzyzk315LAIbNNAwm60JEfqzLtMTlZZ8OhB/pTaxEovOlTsRkuk4z6gLA+IBF8k4XNRtYCYODOVNVv1za6ISnT+VcUdEMg0IUp6eXGXZGaFCUGmBLj/8BC7Cjrm414JoJo5HeRd1PQCIYge3s7TKp9f8QC3uTIWEZhz6IlvOgSlmXcvBNfjfAB0x4hd4tSBtcUQrwuJ2EXs5M8QORUyaAB5K/fe9Sr1LGJy spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <20C84B8C1BAF9145A2EAD3B85B6BB49A@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 8c18ef23-3fa1-4dd5-56a8-08d6757b7d9f X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jan 2019 15:10:56.7431 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2364 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02SbUhTURjHObt323U0OK6Jj2+gQ4gkXxqCfdAyekEKQfsQYouc220T5yab k6wPLZtkU8RIZ85MqVWSxkhXjmllJolkKMMSUiLdUkaRZs2X3rfdG/Ttd57//5z/8zwcihBd 4sZSZdoqWq+VayQ8AdleNHgutfZxpixj2hKzZ2O9kchFeXb7FqcAFQuylbSmrJrWp+8tEahf zA8RlUv8MwPrHaQJTfItKIICnAl13h7SggSUCI8haH14MyyIcABB05sCRghyz4c+1nWLA1dc v8IHEjcTUH+xiWCuWDngvq5lXF4Et99ZuSGBh7NhemElyBQlxkkwuygPlbfj4+Cb20AhFuMT 0N9p5zOcBuaAixdiEifDNZs5zEK8D0z+ifCTCCfAtwu94VwCR8NbXxeHmQeDfXiKYDgK/N7f rF8BM3NN7MyJ8LnzJY/hBPB0NaBQz4DNfBhq83IZIRVWW1uJUM+A86H+ajLj8SBo9/vYgF3w 1TrLButgyGrmMKbXBCys3GFN8eBZnGYTJrmw9ukRu2Ea7t6vQ80o3fbfFLZgIIF3gsPNlvPg eccEj+EkaGlY4NvCy4iEiXYf2Y2491CUgTaUVqik0jRaX6YwGHTaNC1d1Y+C3+OZ80eGC/mX 948iTCHJNmGMI1Mm4sqrDTUVowgoQiIWOozBklAprzlL63Wn9EYNbRhFcRQpiRb+FEXKRFgl r6LLabqS1v9TOVRErAnlX5Zpj8nLPzYsK5yHepHTPVarSkxpxOftmpPmo0vu0+MSneZwgbLb sWM4x/K0WBAoHdGJUG4ct27+z2bA9eXJ2vs+1cHetpHCEyUPXIIDq68UMzEbc0rTZpbYXFwo zWr5ri6KN5bcwN1Gz5RxfNDt6is64pQOOOK3ZDlqCWlQy3enEHqD/C9jfkmjGgMAAA== Archived-At: Subject: [Ace] draft-ietf-ace-key-groupcomm and draft-ietf-ace-key-groupcomm-oscore 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: Tue, 08 Jan 2019 15:11:03 -0000 SGksDQoNCkZvbGxvd2luZyB0aGUgYWRvcHRpb24gb2YgYWNlLWtleS1ncm91cGNvbW0gYW5kIGFj ZS1rZXktZ3JvdXBjb21tLW9zY29yZSwgd2UgaGF2ZSBub3cgbWFkZSBzb21lIHVwZGF0ZXMsIHRv IGJlIGNvaGVyZW50IHdpdGggdGhlIHVwZGF0ZXMgdG8gdGhlIE9TQ09SRSBwcm9maWxlLiBZb3Ug Y2FuIHNlZSB0aGUgbGF0ZXN0IHZlcnNpb24gb2YgdGhlIGRyYWZ0LCB0b2dldGhlciB3aXRoIHRo ZSBkaWZmIHRvIGxhdGVzdCBzdWJtaXNzaW9uLCBpbiB0aGUgbmV3IGdpdGh1YiByZXBvc2l0b3Jp ZXM6DQoNCmh0dHBzOi8vZ2l0aHViLmNvbS9hY2Utd2cvYWNlLWtleS1ncm91cGNvbW0gDQoNCmh0 dHBzOi8vZ2l0aHViLmNvbS9hY2Utd2cvYWNlLWtleS1ncm91cGNvbW0tb3Njb3JlIA0KDQpBcyB3 ZSBkb24ndCBmb3Jlc2VlIGFueSBtYWpvciBjaGFuZ2VzLCB3ZSBhdXRob3JzIHRoaW5rIHRoaXMg aXMgYSBnb29kIHRpbWUgZm9yIHRoZSB3ZyB0byByZWFkIGFuZCByZXZpZXcuIFNvbWUgb2YgdGhl IHBvaW50cyBvbiBvdXIgVE9ETyBsaXN0LCBvbiB3aGljaCB3ZSBwbGFuIHRvIGltcHJvdmUgb24s IGFyZTogDQotIEVycm9yIGhhbmRsaW5nDQotIE1lc3NhZ2UgZm9ybWF0IGZvciBncm91cCBsZWF2 aW5nDQotIEZvcm1hdCBvZiAnY2xpZW50X2NyZWQnIGFuZCAnZ3JvdXBfcG9saWNpZXMnIGZpZWxk DQoNCkFueSBmZWVkYmFjayBpcyB3ZWxjb21lIQ0KRnJhbmNlc2NhDQoNCg== From nobody Wed Jan 9 09:05:08 2019 Return-Path: X-Original-To: ace@ietf.org Delivered-To: ace@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C5DFA130ED7; Wed, 9 Jan 2019 09:05:00 -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: <154705350077.5207.6908872829432265710@ietfa.amsl.com> Date: Wed, 09 Jan 2019 09:05:00 -0800 Archived-At: Subject: [Ace] I-D Action: draft-ietf-ace-coap-est-07.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: Wed, 09 Jan 2019 17:05:01 -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 : EST over secure CoAP (EST-coaps) Authors : Peter van der Stok Panos Kampanakis Michael C. Richardson Shahid Raza Filename : draft-ietf-ace-coap-est-07.txt Pages : 46 Date : 2019-01-09 Abstract: Enrollment over Secure Transport (EST) is used as a certificate provisioning protocol over HTTPS. Low-resource devices often use the lightweight Constrained Application Protocol (CoAP) for message exchanges. This document defines how to transport EST payloads over secure CoAP (EST-coaps), which allows constrained devices to use existing EST functionality for provisioning certificates. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ace-coap-est/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ace-coap-est-07 https://datatracker.ietf.org/doc/html/draft-ietf-ace-coap-est-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-coap-est-07 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 Wed Jan 9 09:10:04 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78A9A130F32; Wed, 9 Jan 2019 09:10:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.643 X-Spam-Level: X-Spam-Status: No, score=-14.643 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, 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 C1lnBMGHT18z; Wed, 9 Jan 2019 09:10:00 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38A88130F2B; Wed, 9 Jan 2019 09:10:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2300; q=dns/txt; s=iport; t=1547053800; x=1548263400; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=6mraG4c0sDj5eA1qN3N7rZpXTCEEzUSqJUBsc+rlXpE=; b=lMxGq9fRe4tTUex+VNvcMO0Nph1cjRTiMnjJjb9MS9IAgnzRj+KHLLuM PvNx3Pw9qXV6LTZBCrwf1SSleiJ71Xu2Reg6oUQCvSQLl4xcojhS8V3y1 08VIOMacVb96axeUEsA01W/szM4dJqSgfK6zs/RwRc2FiziTE4TTSIGwu c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAABmKjZc/5BdJa1jGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUQQBAQEBAQsBgVUuZoECJwqMEI15l3KBewsBARgLCYR?= =?us-ascii?q?AAoIfIjQJDQEDAQECAQECbRwMhUoBAQEEAQE4NBcEAgEIEQQBAR8QJwsdCAI?= =?us-ascii?q?EARIIgxuCAQ+tHYQxAg5AhTKMPxeBQD+BEYMSgx4BAQIBARaHJwKhbAkChlV?= =?us-ascii?q?CilwggWRNhFeKb4lshQqLNgIRFIEnHziBVnAVGiGCbAmLFIU/coEoiA8BgR4?= =?us-ascii?q?BAQ?= X-IronPort-AV: E=Sophos;i="5.56,458,1539648000"; d="scan'208";a="285663589" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Jan 2019 17:09:59 +0000 Received: from XCH-ALN-007.cisco.com (xch-aln-007.cisco.com [173.36.7.17]) by rcdn-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id x09H9wCd025735 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 9 Jan 2019 17:09:58 GMT Received: from xch-aln-010.cisco.com (173.36.7.20) by XCH-ALN-007.cisco.com (173.36.7.17) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 9 Jan 2019 11:09:58 -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, 9 Jan 2019 11:09:58 -0600 From: "Panos Kampanakis (pkampana)" To: "ace@ietf.org" , "ace-chairs@ietf.org" Thread-Topic: [Ace] I-D Action: draft-ietf-ace-coap-est-07.txt Thread-Index: AQHUqD2HfvcyQe1jHE2kIjVlPpQmGqWnKt8Q Date: Wed, 9 Jan 2019 17:09:58 +0000 Message-ID: <9b8aa0f10f0e4d8f9337f4b10182f6c2@XCH-ALN-010.cisco.com> References: <154705350077.5207.6908872829432265710@ietfa.amsl.com> In-Reply-To: <154705350077.5207.6908872829432265710@ietfa.amsl.com> 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: [64.102.57.119] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.36.7.17, xch-aln-007.cisco.com X-Outbound-Node: rcdn-core-8.cisco.com Archived-At: Subject: Re: [Ace] I-D Action: draft-ietf-ace-coap-est-07.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, 09 Jan 2019 17:10:03 -0000 Hello,=20 The -07 version of draft-ietf-ace-coap-est addresses all feedback we have r= eceived to date and updates all the examples to include more realistic cons= trained environment EST-coaps message transactions.=20 It is ready for WGLC, as discussed in IETF-103.=20 Rgs, Panos -----Original Message----- From: Ace On Behalf Of internet-drafts@ietf.org Sent: Wednesday, January 09, 2019 12:05 PM To: i-d-announce@ietf.org Cc: ace@ietf.org Subject: [Ace] I-D Action: draft-ietf-ace-coap-est-07.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Authentication and Authorization for Const= rained Environments WG of the IETF. Title : EST over secure CoAP (EST-coaps) Authors : Peter van der Stok Panos Kampanakis Michael C. Richardson Shahid Raza Filename : draft-ietf-ace-coap-est-07.txt Pages : 46 Date : 2019-01-09 Abstract: Enrollment over Secure Transport (EST) is used as a certificate provisioning protocol over HTTPS. Low-resource devices often use the lightweight Constrained Application Protocol (CoAP) for message exchanges. This document defines how to transport EST payloads over secure CoAP (EST-coaps), which allows constrained devices to use existing EST functionality for provisioning certificates. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ace-coap-est/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ace-coap-est-07 https://datatracker.ietf.org/doc/html/draft-ietf-ace-coap-est-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ace-coap-est-07 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace From nobody Wed Jan 9 14:27:34 2019 Return-Path: X-Original-To: ace@ietf.org Delivered-To: ace@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C937124D68; Wed, 9 Jan 2019 14:27:31 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: ietf@augustcellars.com, ace-chairs@ietf.org, kaduk@mit.edu, ace@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.89.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154707285160.5133.16233237677964445083.idtracker@ietfa.amsl.com> Date: Wed, 09 Jan 2019 14:27:31 -0800 Archived-At: Subject: [Ace] ace - New Meeting Session Request for IETF 104 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: Wed, 09 Jan 2019 22:27:31 -0000 A new meeting session request has just been submitted by Jim Schaad, a Chair of the ace working group. --------------------------------------------------------- Working Group Name: Authentication and Authorization for Constrained Environments Area Name: Security Area Session Requester: Jim Schaad Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 100 Conflicts to Avoid: First Priority: saag cbor core tls lamps cfrg secdispatch ace emu dots Second Priority: quic oauth secevent tokbind t2trg lwig anima suit teep mile Third Priority: doh httpbis uta 6tisch homenet curdle People who must be present: Roman Danyliw Jim Schaad Benjamin Kaduk Resources Requested: Special Requests: --------------------------------------------------------- From nobody Fri Jan 11 05:09:34 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB0641228B7 for ; Fri, 11 Jan 2019 05:09:32 -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 w89rqV0r9Fhx for ; Fri, 11 Jan 2019 05:09:29 -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 707A412426E for ; Fri, 11 Jan 2019 05:09:28 -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=ni5/pKTx1J943cqFuVNoQbjHNOIeZoSM/vKAke1zVuA=; b=j2yTSX4tm330S/V9LOBvVHPQfic0cPVN5+uQ/dzCj3ReLZ2FMWqPRy52ZDlJsgNSiK1LFEaQj8v/zsckio4D0t9xovj41jo1q5Stw/OLo6nonIDwmPvx0fXCib+eMjItoL+0vhg2aghBm/1h4TeDHpOqd7fnaT2UAx3dtOfn0ug= Received: from AM5P189CA0035.EURP189.PROD.OUTLOOK.COM (2603:10a6:206:15::48) by VI1P189MB0478.EURP189.PROD.OUTLOOK.COM (2603:10a6:802:36::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1516.18; Fri, 11 Jan 2019 13:09:26 +0000 Received: from AM5EUR02FT030.eop-EUR02.prod.protection.outlook.com (2a01:111:f400:7e1e::206) by AM5P189CA0035.outlook.office365.com (2603:10a6:206:15::48) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1516.13 via Frontend Transport; Fri, 11 Jan 2019 13:09:26 +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 AM5EUR02FT030.mail.protection.outlook.com (10.152.8.180) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.20.1471.13 via Frontend Transport; Fri, 11 Jan 2019 13:09:25 +0000 Received: from [10.112.134.122] (10.100.0.158) by sp-mail-2.sp.se (10.100.0.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1531.3; Fri, 11 Jan 2019 14:09:25 +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> <637abc12-9c8d-be8a-9d27-ee645cd8a290@tzi.de> From: Ludwig Seitz Message-ID: <5b054bc3-10c3-6885-e8df-c7edbcbfac55@ri.se> Date: Fri, 11 Jan 2019 14:09:25 +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: <637abc12-9c8d-be8a-9d27-ee645cd8a290@tzi.de> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [10.100.0.158] X-ClientProxiedBy: sp-mail-3.sp.se (10.100.0.163) To sp-mail-2.sp.se (10.100.0.162) X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:194.218.146.197; IPV:NLI; CTRY:SE; EFV:NLI; SFV:NSPM; SFS:(10009020)(39860400002)(136003)(396003)(346002)(376002)(2980300002)(199004)(189003)(7736002)(93886005)(305945005)(229853002)(47776003)(65956001)(126002)(476003)(106466001)(31696002)(15650500001)(86362001)(356004)(5660300001)(65806001)(65826007)(22756006)(68736007)(104016004)(8676002)(81156014)(81166006)(40036005)(8936002)(478600001)(64126003)(2501003)(69596002)(23746002)(77096007)(486006)(2870700001)(336012)(3846002)(74482002)(44832011)(386003)(53546011)(26005)(186003)(33896004)(16526019)(14444005)(6116002)(50466002)(110136005)(97736004)(58126008)(106002)(76176011)(16576012)(446003)(6246003)(316002)(11346002)(67846002)(2616005)(2906002)(31686004)(53936002)(36756003); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1P189MB0478; H:mail.ri.se; FPR:; SPF:Pass; LANG:en; PTR:InfoDomainNonexistent; A:1; MX:1; X-Microsoft-Exchange-Diagnostics: 1; AM5EUR02FT030; 1:ZcPmhDyrgyxxQnjGTKj4t/M9UlzclVbLHNhyppOSy8xGvp4mVE9DO5IjjnNkq0naJujxZYTusDNPcuDVuZd0pcrJKMaintYAw09IbMs8rJrL3r4cbVYSMGvrKsHTM7Sm X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: ae87c229-9240-44a5-779a-08d677c6031c X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600109)(711020)(4608076)(4709027)(2017052603328)(7153060)(7193020); SRVR:VI1P189MB0478; X-Microsoft-Exchange-Diagnostics: 1; VI1P189MB0478; 3:WLvo4Sk51tnr01UZ/BQxWCfwEhTKRcO9d30Iy9PUb5mq016RCWVLnPlURdWzUQqDa5ZzpDcFFfIshnpbIlP473i7oITtNK4d6Z4JcoPBtNo4GzXpi7BvoJLiJrHAL6xcI26Axb8f+1W6coHYFAHWayBmYaSX9yghyGLm0hokhU4ZSqHPw5ayiv6dlS+57X50Vlfif/WABEXeyx5tpLvvWmX7KJGH6USrLkbDkEAmrKwnlUcSgUB2hEwwhAzkzABeV7XSLccFGUFw8XMdpxki6WEppEdqfUajmKCl6kiTil2B4gJe/VgfVahaq8kaA3qqtEJdEqeFPrDJ3bJFC4pz4RjSVsKFOx2EsyZHjMUkkTYMcdmYBwZBm/FxPtWpku6P; 25:muvflXj23dfbiGROEfso7KeMOlDEsnh4oZgU7jn2mkkDq4eL609uKMfLXtjU5SNuo0gISoPAxEuLRc4ckJY2OxiqHYyzHSUWWX76EraaVV0yPZ66fvwSXyVUr+4XHSa1FTCbghAfg4hCLhTDxqM6WNswD+6FGUlXpFEEdFbEiJg4fTBJ0vBrWKHXiBD6oHJpE6z7gzurok3XHhxO6dtKjzpJ8HrXxMb0/EqBTPFv25Dv9M4q+4jlDvwVeCq0hXbllz5t+/HaIkH8ctA/9B75NAwqVrisS/5CHQfN7Z/UN5BKaCOyZ30rN+o7VlamIYTNeqBV1WP2ibWp85p7h4IThA== X-MS-TrafficTypeDiagnostic: VI1P189MB0478: X-Microsoft-Exchange-Diagnostics: 1; VI1P189MB0478; 31:mgse7ykP7qPlLsC2x/V3kKN7xlSr5XGb9y40Upcc+v0jR2fjMiayBBIZ9m0zQO8kI/L3uhblvK8Mz/agyaSg236WqLJxcs/NAaumDH7auMfs5lOEj/uW8pMO83cXjFFeJJGh0qKKbtOT0Sn/vMz+ezFTF35lPegFBJ/LNXeqLCBOaL4hcTtQuGfNPosckfeIFIS96+n9C5WTmqLqcdgiwqp/LqIevYPGEh9UzIGYMqQ=; 20:TFds2wAA7DNGoaYTTyRSdGAj5pYl2qGN4el7o5C/lBNqXaRhm6kj09B3KqHF6PlZM9KRpmTb4dD29k5CyNnGy2vvxrKZHrtjE5udsZIjUgxcgf1qux86yXESNN/S6Hxv3x8WtOZLPLy/VQ4XtCY18jDOhxA8fNZU/cV1D166/DpRaluJI8Hfr5NEfQBc8Lw8uIGNU9s4OvbJrwIu6TttOBlr8tjw3WMrnbO4cD9nRSQ6ehF7t0E956n9b2Gdp+fT; 4:wIH5Dg683Q18g3dwJ97tb6nXItkD2sUwPkrv84+Gyg7VjFMgl38t+CVUu+drVjhjmbSe5BIB2aV+GfQoxJpVobgGgDrgvd5EQsktK5NKWK+yfzvsL+aJIjF18WXuXF3azYHpcmJaasgB7Q0l9lx1PWJjsuk+16gFLxfimj9Qgmd8fNlR/oxoEXFA3FnyRWY80w4ac1p7nTCX5OF7n43FqnF8Qlm40kqcgyi2xYRF8h/p3yWJoKnokmOanWflVVI/Y2gJWbgJZB8e8NqCnDA8BOdm91/0DBH3yZc1Lct/RuE= X-Microsoft-Antispam-PRVS: X-Forefront-PRVS: 09144DB0F7 X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1; VI1P189MB0478; 23:zSPRtAETApJCPHOHEbdXp7KoX6Q4MC0hx7A3R?= =?Windows-1252?Q?rsQCi11tEdqHwmj1YNi5wxhsRhVfWAyHVR4O80B95ZSCFP2AH6w4FJ7F?= =?Windows-1252?Q?qFCTlmUbVVG8IVXxngy+DY855N7Sbo45BiFJD3ZBPuwskuwBjVDBJLpl?= =?Windows-1252?Q?hFVcezbwcO9VSNajxeMP+hoJbTKV8oALM0xvFOSOITjmfHJA0sWSfaHM?= =?Windows-1252?Q?ncCRDGeNsjVu45N4BIJPhSiyFymuny3CaJ3WPcRdws8PHBhapuD/0nNo?= =?Windows-1252?Q?jljq5o2kr40GmsipDAkYUM+QEEqNgYYgg8ucU1QLMJ5csLo/LaacWCOj?= =?Windows-1252?Q?4S5o46yT/+XQrwFXuPXUSd9uRzBjl8Qrx3XLeFoz9ispIzDmHug01cQl?= =?Windows-1252?Q?a82PA3z6mAgaETnTFvaHMpiFwNmD4YGxgp7gHzcIiQ6GQBViwLCB7cFA?= =?Windows-1252?Q?G26eEwccM0leYkYyocMtMc2xwQjpZiJgc3RcaOnlQFHexlIeWLqnbR/Y?= =?Windows-1252?Q?ezBWwUaUtgCwWiTkcYEBKITjvtOLjIlnGa4fsQ2ugjGIaArv3zMwFg9u?= =?Windows-1252?Q?Z48d5d51IjvGJObeOQIvYGUYD+ekU44cMnC9PN3F9Z+Mxpr+JsnScZ9y?= =?Windows-1252?Q?fWkf92UctxK0AfbAMAqatgoJal35hVpKVCGz25NzqqzUm4dwwdY78N26?= =?Windows-1252?Q?ap8NnaloqCUWOS3W0cd/eRoQhIpeGzo2/ZMMUnC9XPm8wDaA5ybVuuaM?= =?Windows-1252?Q?US8O4zG+kaYByjDpHkIxM8613Ef0uLSL78FmtO9yN7ese7M8SEF/But/?= =?Windows-1252?Q?S+3MNyqe6lXLzF/IaSTQHppuv0c+3MqpbWJtEV8uBiJoC04wfRVva4K8?= =?Windows-1252?Q?VC7+Eg+EG95CAucvt2as7ZFAtcROElMyL7PdzvBqfD7X81BAG4HdSOwb?= =?Windows-1252?Q?5/2WWjBLahlauna+X1nuiqT6e+G4pyzVm+tRJ6LJ9i7ZxHNOGVoGlduy?= =?Windows-1252?Q?LnfT0JBBRY6YocBijDSBKJOhd8preWq8CAkU2E2dlw/bB29QQmFKUeNs?= =?Windows-1252?Q?rhkJq21C6FzfNpFEWu9qDpAuMZRYhHJbBysW05neU9luU26qQH/zKS9O?= =?Windows-1252?Q?q02tCR56dDNSi2eRhgXyEz7IqP7PBHxUAEDYtppQ6R8R9axOoS+QflAJ?= =?Windows-1252?Q?b7xnFQbvm+iPqA8/+0xxGq5P31W042M6qZq5AtfeeFaxwaYiGQIwuZE5?= =?Windows-1252?Q?PFrGXBDoOlpr/f356h/+3hMDRKyxsgy2hBu5+qZiy8wKfRmsejOZTA43?= =?Windows-1252?Q?W4XPKCn3NV3A+7wzkPIDduGxS3kAUCSgF9IgllLS3lGgrLtfh3Eahnbb?= =?Windows-1252?Q?IAWtB0DHRH3MXHXWKd9ddr3uhpF0jbQqf9OG4qSziiWngTz0lQDt2in3?= =?Windows-1252?Q?3AZ+hpJIW/xxVXJDymY9KmJfyHaYcn6jXmEs4iesjwWz0veZWA2FEaZO?= =?Windows-1252?Q?AhUFvp+I+MgMOQTGtydGdS2E8Ij4vlMEE2Tvl2173uMHBFVVUm9Sdxo2?= =?Windows-1252?Q?8cloRnHt9NY2o5zEVrOD3xQOG5fWV3JsXfMgV63WaUIkvkbBFF3BW7xW?= =?Windows-1252?Q?ChA/5ygIu+Pi5b8vc3drAhU+6zzywTCdpiYO1ILJnzH?= X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Message-Info: ekvCFVz7orVDtEUsNQC2X77FNG0ry12AXEW3uI1svGRuPqhtHhwbhjDeSlaFfWzxn8J2gL6fhnlqdAGAgMf2Hi/wtAg/Lw4CSPJkUSKpH6Ng9HjClQoAfxw1BCD7jI88bwuBBKQPApedkuji30t9csihRETZJp02K5zPg8Kq6TSH0MZG3rz/9ekMQaBqEUSEn8GZU0292cHmRnOf+cRZY7uUj7/dTXle5Bhie85+tNVBXg3pkBnYTk77HUCKcTuGSradFsfymifNKNgvkQ+03u/iWWki39jBW69enNEyEE/86ZxM1V4a2EINeyCmhzZs39Eiq54KLOLM1c+v4HEDMY2clYRqLyfYaaLnH8Rmnr+228x0MDCxhhz8wiQWc72UM5eJT6eJAjeUUzS6K1l4QkiqjalV4m6op8zMtJYoOY0= X-Microsoft-Exchange-Diagnostics: 1; VI1P189MB0478; 6:B4HrHnJcxQ1iBiY9lOePbwLxHxzuA/vcTQnXlTJ4YwF89BmXHIHuGfF2tt1yHjM+v8Eu1IO6fQfQizmp9E9lW8hwjsTKrXsWUlukzvSa8sXjmpJLKT99G7QLmB/ZBWg/l0e4BNoLdU03mGB+f8i0ScM+D72v3KGjcxv8CneW8FGGhm+wNxJlWBYJWBBzvBwuRPEEJvdqG13Dxazd8krwVd9WfH17vv1x/YE6XfYWewG9LSYHLI8fC5BW/GIY2qdcDpWiF9K/FlzeUHYoGUK2OFbeqf5GT+FoQ8XM8EFMMUOk9qMeiYWrTL08qrUTSSKEHtttLd37eJtrLukBHnqmXen2BH6G+z7TfYocrMbrqKj84oFJgCOQVlckQICHQq1RsUJzm8HQuwVpLqOUcY5Und48QJiDu3a4TL37fszsKRgJslCf9ZWllwhmnI2mi54J/AgGpfTDmJcjA3mNrhLRBg==; 5:ebPgeZDXMUxVySI2sRPNuqiELpDUciPbo1kYFpS5emFh3tum2nca3quN+O20wA9CAFYXAhQjvzzDjDZ6eKpcMS0L4wej/w+1/rtIgevemzSWGxTODJfwoQliNcGdVpp/HW9wmpUAJLSmhAoM/izdZI3tuK1FV9/SI4ohiw0q72pKIeeC3jJy5NYw1BRVwny9n4AWivTKctdnXlBVsoXyxw==; 7:g8qHEnM2LPR0G5PITfQjXLxvzJhOs2AhlmSEe969qf+SFTk0M1lNQu1wIvJEdlWc2OTYLLcwliGi5Ac5+nqCDSFeaEpajyUMp11GxTLMTz+ieSfTNeIK6d03I87haDckLN13U9fgGdONf2Otycxv0Q== SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Jan 2019 13:09:25.7681 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: ae87c229-9240-44a5-779a-08d677c6031c 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: VI1P189MB0478 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, 11 Jan 2019 13:09:33 -0000 On 18/12/2018 15:48, Stefanie Gerdes wrote: > 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 > Hi, I've merged Hannes' PR, fixed a typo and added a sentence as follows: ===================================================================== For self-contained tokens the RS MUST process the security protection of the token first, as specified by the respective token format. ~snip~ This MUST include a verification that security protection (and thus the token) was generated by an AS that has the right to issue access tokens for this RS. ===================================================================== I have not extended this requirement to tokens passed as a reference, since in that case the RS needs to do introspection at an authorized AS anyways. It would thus not get the claims of a token issued by an unauthorized AS, which would in turn lead to the token being discarded. Does that sound correct to you all? /Ludwig -- Ludwig Seitz, PhD Security Lab, RISE Phone +46(0)70-349 92 51 From nobody Sun Jan 13 20:03:15 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBE9B130EF1 for ; Sun, 13 Jan 2019 20:03:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.501 X-Spam-Level: X-Spam-Status: No, score=-0.501 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 0QI2X7rBxUun for ; Sun, 13 Jan 2019 20:03:12 -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 1F329130EF2 for ; Sun, 13 Jan 2019 20:03:12 -0800 (PST) Received: from Jude (73.96.115.65) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Sun, 13 Jan 2019 20:03:06 -0800 From: Jim Schaad To: Date: Sun, 13 Jan 2019 20:03:02 -0800 Message-ID: <003701d4abbe$0cfab580$26f02080$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AdSrvXSIvNnigqRdTGScym0guMdeAQ== X-Originating-IP: [73.96.115.65] Archived-At: Subject: [Ace] WGLC for draft-ietf-ace-coap-est X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2019 04:03:14 -0000 The chairs believe that the EST over CoAP draft is nearing the point it should be sent to the IESG for publication. We are therefore going to have a Working Group Last Call on this document. WGLC will until 29th of this month. Please review the document and send comments both positive and negative to the list about its state. Jim & Roman From nobody Mon Jan 14 11:16:47 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11766131226 for ; Mon, 14 Jan 2019 11:16:46 -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 ghZqLffFrfpW for ; Mon, 14 Jan 2019 11:16:44 -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 1163913121F for ; Mon, 14 Jan 2019 11:16:44 -0800 (PST) Received: from Jude (73.96.115.1) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 14 Jan 2019 11:16:37 -0800 From: Jim Schaad To: References: In-Reply-To: Date: Mon, 14 Jan 2019 11:16:32 -0800 Message-ID: <011501d4ac3d$ab2b9650$0182c2f0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AdSrtk3M3NcfgQ45QNualt2l/rHBKAAh1EAw X-Originating-IP: [73.96.115.1] Archived-At: Subject: [Ace] FW: WGLC comments draft-ietf-ace-coap-est-07 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2019 19:16:46 -0000 I forgot to include the working group on the to list. -----Original Message----- From: Jim Schaad Sent: Sunday, January 13, 2019 9:51 PM To: 'draft-ietf-ace-coap-est@ietf.org' Subject: WGLC comments draft-ietf-ace-coap-est-07 Section 5.7 - Validate that CBOR array is the correct response type not multipart/cbor Section 6 - Based on earlier mails on the list I expected to see a short description of the purpose of "ArbitraryLabel". Section 6 - The fact that there are multiple ways to get the things and they might not be in the same location. Some guidance for an application on how to decide which method should be used and the choice of an ArbitraryLabel to use would be very helpful. At present I would guess that I would send a request to the well known address, if that does not work then do a discovery but it might be easier to just do the discovery to begin with and not worry about the well-known address. That is one would only do discovery if one was hitting up a resource directory and not the actual machine. On the other hand if things are rooted at /est rather than in well-known it would lead to shorter requests which once one starts doing block wise would be good. Section 7 - I would like to see some discussion of using a tls-exporter rather than tls-unique for this protocol. I am not sure what the required changes would be. I have seen notes that tls-unique is broken for TLS 1.2. Section 7 - I think it makes sense to say that after a successful enrollment the (D)TLS link MUST be torn down and the new certificate used to do authentication in the future. Section 11.1 - When changing from the implicit trust anchor to explicit trust anchors, do you expect that the est server that you are going to be talking to is generally going to change? I think that it should probably be recommended that the DTLS connection NOT be persistent across a change in the trust anchors if they are different. Nits: Section 2 para 1: I would suggest that the last sentence should read along the lines of "EST is defined to transport messages over HTTPS." Section 3 para 2: The phrase 'taken over from' is a bit odd sounding English. They could be 'taken from' or 'imported from'. 'taken over' tends to indicate that you are changing them in some way. (example use - he took over the country). Section 5.5 - SAN needs to be expanded on first use. Section 6 - Please verify that quotes on the content type when multiple values are presented are not needed. Section 8 - This sentence "The EST server can exist outside the constrained network that supports TLS/HTTP." Does not say what I think you meant to say. It is unclear if the constrained network is what supports TLS/HTTP. Section 10.1 - s/registered temporarily/registered provisionally/ s/looke/look/ Examples: * Section A.1 I don't know what the meaning of Max-Age would be for a GET request. You may want to remove this just to avoid confusion. * Section A.2 - I am unclear about the Content-Format note in this example. If you are asking for a specific content then the correct option would be Accept. If you are indicating the content type of the response then you should probably put a header line in to that effect. Jim From nobody Tue Jan 15 07:13:03 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2C8F130E59; Tue, 15 Jan 2019 07:13:01 -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 htMCGx81pgN8; Tue, 15 Jan 2019 07:12:59 -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 76459127B4C; Tue, 15 Jan 2019 07:12:59 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 6E9D03808A; Tue, 15 Jan 2019 10:12:20 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 5CCD0EC9; Tue, 15 Jan 2019 10:12:55 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 5A58DE5D; Tue, 15 Jan 2019 10:12:55 -0500 (EST) From: Michael Richardson To: Jim Schaad cc: draft-ietf-ace-coap-est@ietf.org, ace@ietf.org In-Reply-To: <003b01d4abcd$1e2b0c10$5a812430$@augustcellars.com> References: <003b01d4abcd$1e2b0c10$5a812430$@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] WGLC comments draft-ietf-ace-coap-est-07 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, 15 Jan 2019 15:13:02 -0000 --=-=-= Content-Type: text/plain Jim Schaad wrote: > Section 11.1 - When changing from the implicit trust anchor to explicit > trust anchors, do you expect that the est server that you are going to > be talking to is generally going to change? I think that it should > probably be recommended that the DTLS connection NOT be persistent > across a change in the trust anchors if they are different. I'm trying to understand the question better. To be clear: - implicit trust anchors -- what the device was built with. - explicit trust anchors -- what is returned from /cacerts|/crts So after calling /cacerts, the client now can authenticate an EST server with the domain registrar. Beforehand, it has to use something built-in. I think you are asking about whether or not the server identification (certificate) is different in the two cases? If we could be sure that a different EST server would be used for renewals of the certificate (LDevID), then that EST server could have a locally anchored certificate. I don't think we want to force this change of servers so the we must be prepared for a single EST server to do both initial enrollment and also renewal. @Hannes, it would be good to have your opinion here. This problem can be solved with correct use of SNI extension in DTLS, but it is unclear how much detail we need to be explicit about. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlw9+HcACgkQgItw+93Q 3WXoTQf+Ky2oXOYmarPcPx08Ghuicwg/GAKZnpZ05KXiHJDquRSIyGNoW62SYA12 B81QVniYV51dIEDtwXBKvGtKbW8wPeLbEx0RKkx0J65hrUBBuGGvuC8S9GRipynP hpOocwSuhez2f5yF9y6KjV+Wc2ZzI5E8khLUPVoIBSAVA6rhBM0E7K37PITv34Cs FM4lp5ZJjfP+Dwi4Y1XvkE/+2phTV8OAG/gJAeeDOdjUJhDv/XpzbCGGmTqZFxUY +9MXSrQHaTTzgBOB3hb7kDxGzm6Np80tM8dG+oTq1EWyxCXcRBQR7C/MTGUPXy6L KWJ1TRKP24gHZeRZRmDLkXp4N4/eUQ== =c/M/ -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Jan 15 10:11:01 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACFF7130F2C; Tue, 15 Jan 2019 10:10:50 -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 nxHlBchZLHI0; Tue, 15 Jan 2019 10:10:48 -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 13A7A130F17; Tue, 15 Jan 2019 10:10:47 -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, 15 Jan 2019 10:10:41 -0800 From: Jim Schaad To: 'Michael Richardson' CC: , References: <003b01d4abcd$1e2b0c10$5a812430$@augustcellars.com> <620.1547565175@localhost> In-Reply-To: <620.1547565175@localhost> Date: Tue, 15 Jan 2019 10:10:39 -0800 Message-ID: <026e01d4acfd$a0becff0$e23c6fd0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQJJIhiUbSjnc+/xowD2+hleOkbe2gKyHt8kpLIkitA= X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Ace] WGLC comments draft-ietf-ace-coap-est-07 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, 15 Jan 2019 18:11:00 -0000 > -----Original Message----- > From: Michael Richardson > Sent: Tuesday, January 15, 2019 7:13 AM > To: Jim Schaad > Cc: draft-ietf-ace-coap-est@ietf.org; ace@ietf.org > Subject: Re: WGLC comments draft-ietf-ace-coap-est-07 > > > Jim Schaad wrote: > > Section 11.1 - When changing from the implicit trust anchor to explicit > > trust anchors, do you expect that the est server that you are going to > > be talking to is generally going to change? I think that it should > > probably be recommended that the DTLS connection NOT be persistent > > across a change in the trust anchors if they are different. > > I'm trying to understand the question better. > > To be clear: > - implicit trust anchors -- what the device was built with. > - explicit trust anchors -- what is returned from /cacerts|/crts > > So after calling /cacerts, the client now can authenticate an EST server with > the domain registrar. Beforehand, it has to use something built-in. The question I was asking was more about the original enrollment rather than renewal although it could come into question there as well. - I have the implicit trust anchors and get a EST server URL. - Call /cacerts - I now have the explicit trust anchors but potentially have the same EST server URL. - Given that I have a NEW trust anchor, what do I do with the current DTLS session? - I now do an enrollment with the EST server to get a certificate. One can say it is fine to use the implicit TA for that enrollment, but one could also say that as the certificate chain is now different then the DTLS session should be released and a new one established. Jim > > I think you are asking about whether or not the server identification > (certificate) is different in the two cases? If we could be sure that a different > EST server would be used for renewals of the certificate (LDevID), then that > EST server could have a locally anchored certificate. > > I don't think we want to force this change of servers so the we must be > prepared for a single EST server to do both initial enrollment and also > renewal. > > @Hannes, it would be good to have your opinion here. > > This problem can be solved with correct use of SNI extension in DTLS, but it is > unclear how much detail we need to be explicit about. > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > From nobody Tue Jan 15 12:25:47 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D01C1295D8; Tue, 15 Jan 2019 12:25:46 -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 4AXSmirRqeH5; Tue, 15 Jan 2019 12:25:43 -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 440DF1294D0; Tue, 15 Jan 2019 12:25:43 -0800 (PST) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id 5D1643808A; Tue, 15 Jan 2019 15:25:04 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 98BEB12E3; Tue, 15 Jan 2019 15:25:39 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 9730212DE; Tue, 15 Jan 2019 15:25:39 -0500 (EST) From: Michael Richardson To: Jim Schaad cc: draft-ietf-ace-coap-est@ietf.org, ace@ietf.org In-Reply-To: <026e01d4acfd$a0becff0$e23c6fd0$@augustcellars.com> References: <003b01d4abcd$1e2b0c10$5a812430$@augustcellars.com> <620.1547565175@localhost> <026e01d4acfd$a0becff0$e23c6fd0$@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] WGLC comments draft-ietf-ace-coap-est-07 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, 15 Jan 2019 20:25:47 -0000 --=-=-= Content-Type: text/plain Jim Schaad wrote: > The question I was asking was more about the original enrollment rather > than renewal although it could come into question there as well. > - I have the implicit trust anchors and get a EST server URL. > - Call /cacerts > - I now have the explicit trust anchors but potentially have the same EST > server URL. > - Given that I have a NEW trust anchor, what do I do with the current DTLS > session? > - I now do an enrollment with the EST server to get a certificate. > One can say it is fine to use the implicit TA for that enrollment, but one > could also say that as the certificate chain is now different then the > DTLS session should be released and a new one established. I think that the purpose of calling /cacerts is to get context for living within the network. I think that one continues with enrollment with the same connection. Restarting it might not actually work. The resulting certificate should validate with the set of trust anchors provided, and the anchors should let the client validate other clients. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlw+QcMACgkQgItw+93Q 3WWXBAf/XtkYQJTBxO2r1AWtp0KNtZx76L4We0a23tIWGSbydyMUJxGmTpCWG0Jh 7LSARaMStyaf3LWhwprFIbx5QfuaV44cjYT7zcCO4vLBCOUcMdW+nqgX7SJO+leJ jrYz32vedphVUdGHZy3pEt4E8PJ+xMaUTule5b+0ahR1MhtaF3DuiCUXKRyr21aK tQNcYwmYnFwXHq6DVR9cl1iWGoqGBt6duCWXg2mewLRWUHh34EMbK9AvM1toxYU2 mMh1xjKgxVEX/oDHIulSTL+y+SCAktXDcAEZqbDUzmUqJQMgW+QiFdiedboGY7LO Twb5xkKbEKIurmbCifpmt4L1Zc9jQA== =K4Br -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Jan 16 02:16:07 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C9D8130DF1 for ; Wed, 16 Jan 2019 02:16:05 -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 9TK_0k5KblIe for ; Wed, 16 Jan 2019 02:16:03 -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 54156130DEC for ; Wed, 16 Jan 2019 02:16:03 -0800 (PST) Received: from [192.168.1.109] (p54BDE371.dip0.t-ipconnect.de [84.189.227.113]) (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 E5280203EC; Wed, 16 Jan 2019 11:16:00 +0100 (CET) To: Ludwig Seitz , 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> <637abc12-9c8d-be8a-9d27-ee645cd8a290@tzi.de> <5b054bc3-10c3-6885-e8df-c7edbcbfac55@ri.se> From: Stefanie Gerdes Message-ID: Date: Wed, 16 Jan 2019 11:15:54 +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: <5b054bc3-10c3-6885-e8df-c7edbcbfac55@ri.se> 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: Wed, 16 Jan 2019 10:16:06 -0000 Hi Ludwig, That's better, thanks. Viele Grüße Steffi On 01/11/2019 02:09 PM, Ludwig Seitz wrote: > Hi, > > I've merged Hannes' PR, fixed a typo and added a sentence as follows: > ===================================================================== > For self-contained tokens the RS MUST process the security protection of > the token first, as specified by the respective token format. ~snip~ > This MUST include a verification that security protection (and thus the > token) was generated by an AS that has the right to issue access tokens > for this RS. > ===================================================================== > > I have not extended this requirement to tokens passed as a reference, > since in that case the RS needs to do introspection at an authorized AS > anyways. It would thus not get the claims of a token issued by an > unauthorized AS, which would in turn lead to the token being discarded. > > Does that sound correct to you all? > > /Ludwig > From nobody Thu Jan 17 06:45:57 2019 Return-Path: X-Original-To: ace@ietf.org Delivered-To: ace@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 32A361277CC; Thu, 17 Jan 2019 06:45:56 -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.3 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ace@ietf.org Message-ID: <154773635616.27345.12001754900505365202@ietfa.amsl.com> Date: Thu, 17 Jan 2019 06:45:56 -0800 Archived-At: Subject: [Ace] I-D Action: draft-ietf-ace-oauth-authz-18.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, 17 Jan 2019 14:45:56 -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 : Authentication and Authorization for Constrained Environments (ACE) using the OAuth 2.0 Framework (ACE-OAuth) Authors : Ludwig Seitz Goeran Selander Erik Wahlstroem Samuel Erdtman Hannes Tschofenig Filename : draft-ietf-ace-oauth-authz-18.txt Pages : 75 Date : 2019-01-17 Abstract: This specification defines a framework for authentication and authorization in Internet of Things (IoT) environments called ACE- OAuth. The framework is based on a set of building blocks including OAuth 2.0 and CoAP, thus making a well-known and widely used authorization solution suitable for IoT devices. Existing specifications are used where possible, but where the constraints of IoT devices require it, extensions are added and profiles are defined. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ace-oauth-authz/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-18 https://datatracker.ietf.org/doc/html/draft-ietf-ace-oauth-authz-18 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-oauth-authz-18 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 Jan 17 06:47:46 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 786681277CC for ; Thu, 17 Jan 2019 06:47:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.043 X-Spam-Level: X-Spam-Status: No, score=-2.043 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, 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 mmTDjGY4U0Ia for ; Thu, 17 Jan 2019 06:47:42 -0800 (PST) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50070.outbound.protection.outlook.com [40.107.5.70]) (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 89FD81276D0 for ; Thu, 17 Jan 2019 06:47:41 -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=eVV2T048+/O8C+zmvpQ5uFY63Wr8+2Ps7oN0VQnrpJY=; b=RdMylb71rAv8+xF0zB0AkGFNNW0hZBRK+jDtMLu2m3Mi+WNkiTW6eNnf92bkPBGU3+p5bGK9e5ed2+x6TdnBXYp2PaIPubrord+UP/9QvtwK/yKYDkOLtv/S0RyOcgYNUsiFGkD7ppXHClih0D2JBGkLFcGv9kAImvr0Mh4zVz0= Received: from HE1P189CA0013.EURP189.PROD.OUTLOOK.COM (2603:10a6:7:53::26) by HE1P189MB0330.EURP189.PROD.OUTLOOK.COM (2603:10a6:7:58::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1516.18; Thu, 17 Jan 2019 14:47:38 +0000 Received: from AM5EUR02FT063.eop-EUR02.prod.protection.outlook.com (2a01:111:f400:7e1e::208) by HE1P189CA0013.outlook.office365.com (2603:10a6:7:53::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1537.26 via Frontend Transport; Thu, 17 Jan 2019 14:47:38 +0000 Authentication-Results: spf=pass (sender IP is 194.218.146.197) smtp.mailfrom=ri.se; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=ri.se; Received-SPF: Pass (protection.outlook.com: domain of ri.se designates 194.218.146.197 as permitted sender) receiver=protection.outlook.com; client-ip=194.218.146.197; helo=mail.ri.se; Received: from mail.ri.se (194.218.146.197) by AM5EUR02FT063.mail.protection.outlook.com (10.152.9.234) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.20.1471.13 via Frontend Transport; Thu, 17 Jan 2019 14:47:37 +0000 Received: from [10.112.134.122] (10.100.0.158) by sp-mail-2.sp.se (10.100.0.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1531.3; Thu, 17 Jan 2019 15:47:35 +0100 References: <154773635639.27345.4112977138846687566.idtracker@ietfa.amsl.com> To: "ace@ietf.org" From: Ludwig Seitz X-Forwarded-Message-Id: <154773635639.27345.4112977138846687566.idtracker@ietfa.amsl.com> Message-ID: Date: Thu, 17 Jan 2019 15:47:35 +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: <154773635639.27345.4112977138846687566.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.100.0.158] X-ClientProxiedBy: sp-mail-2.sp.se (10.100.0.162) To sp-mail-2.sp.se (10.100.0.162) X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:194.218.146.197; IPV:NLI; CTRY:SE; EFV:NLI; SFV:NSPM; SFS:(10009020)(39860400002)(396003)(136003)(346002)(376002)(2970300002)(189003)(199004)(67846002)(1730700003)(53936002)(6306002)(14444005)(446003)(11346002)(356004)(68736007)(8936002)(81166006)(7736002)(31696002)(305945005)(966005)(316002)(81156014)(8676002)(15650500001)(106002)(106466001)(16576012)(478600001)(86362001)(2906002)(2351001)(97736004)(3846002)(6116002)(386003)(31686004)(47776003)(65956001)(65806001)(58126008)(69596002)(77096007)(33896004)(76176011)(22746008)(2473003)(5660300001)(74482002)(486006)(66574012)(229853002)(336012)(104016004)(36756003)(40036005)(22756006)(65826007)(50466002)(44832011)(186003)(2501003)(16526019)(2486003)(23676004)(230700001)(64126003)(5640700003)(26005)(2616005)(476003)(126002)(6916009); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1P189MB0330; H:mail.ri.se; FPR:; SPF:Pass; LANG:en; PTR:InfoDomainNonexistent; MX:3; A:1; X-Microsoft-Exchange-Diagnostics: 1; AM5EUR02FT063; 1:WPeVcz0w/wiBZoorWaQEFes+yAUcHaV/7vxnTDloqXqPjKWJ+vhtmMJOe0U+hpT4VdNfTulKOjUq787ynUg1qzgjTMtHpPE5Kr6a1JW91AqBMlhBhtrM678AIxbea44O X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 47e2479c-c3a1-4790-c33a-08d67c8ab996 X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600109)(711020)(4608076)(4709027)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:HE1P189MB0330; X-Microsoft-Exchange-Diagnostics: 1; HE1P189MB0330; 3:w6mWCAGtXvBFLM8+KACSCUhMtPETEtdyzs8YuOgBG5/q1cHSJj8XvydLRuO0z7wTSUotb9ke6W9svLHDencXkyxdtL4yIJhz3ac5oM2RT1S80cHjGZOFKXJCTX0ofPRtTOybrIPTyJhnCO20RjJ2IBQaR89Dkm5ZSLfhPQum/MCmwX984JdHrF6z7jNEd+WG52j81rsTNkux/ehpKx8gQKxassJqQmlyGDVr+pJtnjrq8x3dMFdIT+jE8pbZasfXc74cUON0qrXbxu/3bG1c62DF2PEkFJDT6l1W3aFUr7jO3p+9pWC9qPbAgR+gPUMlaqvsu3T2qliCbdeO29RW4YpM+vDOJJroCtYDpGsZsdhKEwohkyEJ2ce4lvnbgItt; 25:aU8pyRyzExW215WaarTW61J6InFzi195GnLJ1f+LGGdrIO5NjsfWmVWggkyOH46osG+B9vcowfg7Db0H26aAZxIDMdlRQb1eKH2PUB4S70E7qAYE5GGFhe1iq8O6Z5clpI/zkqUu3UQCTN1rfuwyDzmC56jGHHbaygtLhBCo4B3mPsCDNcL5fNHLWVG3+5Dac+js/SRrKZPC8+1YidsUQdeW71aeCXtS6opC3iITTreH8Ole8HKvwziDxzXpKxk5TspwH0odyGGGAFAkB48rLPd7ceuXhJTwEPbuaE27tfBjk/Hy8PslYU8liX2EuRQtPj8EWcc/2jTRENPHmX/G5w== X-MS-TrafficTypeDiagnostic: HE1P189MB0330: X-Microsoft-Exchange-Diagnostics: 1; HE1P189MB0330; 31:OZAjP0245ZSVa3SCGtwvj2pvDRV8H4TNM2Lbo5mO/j+uUF2ocFwhkyTrm6MQ3/hAi11E999TXfn1dtyqiAKpb/q2pxyjoWWUlK4bDMox9EvuBJYYWW6afvrkeuVlz8YcYvga9pemNH4HBTCtUiuLlkpfvYS1Io2b5SJkPTcRCBTM6uOGfpub7+L/Utfgq9rG+vycVF/MKyAgcY56ucs6ldW0Lq0vEVCoHTKkJXHTjBw=; 20:aHv1W9rM+Sqv8sqa6FqTqjVod3k6OJfTLu+aF/8IyS+wAF35wwuS4yjUPzx2TKnqEwWcuoOFACHxH/KyoLr3Kh4QE+NWth120Hw5en+A66MoipKCgAUyKpdK4sjRAoDENG+AXyu3intTPsav8773vTTdwLQ27nG86VvuPqHYYLJ/NgjnjHb/15IlY+Avt5Mfpf+wQKWxhgW0AvuTcgTScJQ3MwxiQKgWG+NQQjliYJ1v0bWdiuYJ1Mowdq1ihHYW; 4:Jx84kF8hFHbkUpkayrTLRPzySDh1m9sOZsPmftY8E89leWAg3Vj0bnJJ+Cf/dcJ60YpxZonpLxcwDMPy07b3RfrGt6PXMm+Z7rF7FN02hHK8QZU5Kb81eGxps7LPZIVemcFCD5ewnjeSYjLA4Gn1FlUjndUqQv0rheYixiYaMBXv1ysIl/q4Aipchyl/VIAXOXfBEUfbpFpMEsHY5hYcA3vlwieq37rPUIV9yt1gZ5mIl+Nrom3ZECVdD9gfI6eXPLA+/KXYr5Na3+NHblJezg5sLh+C5a7ch41wRLn6zgVrE7qAJepspZF3IUmkO83E X-Microsoft-Antispam-PRVS: X-Forefront-PRVS: 0920602B08 X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtIRTFQMTg5TUIwMzMwOzIzOlJtTm1oanZHZlZ2V3ZCUDFHUkRMOGFSRUtP?= =?utf-8?B?UHQwRXI3WGxTOGFEUndyUURiUVBqVWlWWTQzbVNOUnZvdG1tYTAzWnZLVjdD?= =?utf-8?B?bDVBNnhZSENHMHl6VUFNUi82T1Nua3dmSW0vNGZHQTN6cGRnakNKNkg3aWZN?= =?utf-8?B?aTRITGsxWkdZdVRFZDdZN0dZU05aUVdFdW9tQUVIU0ZDdWk3WWh1dWVVOE51?= =?utf-8?B?VmU5Z1hMZER0REc5MTFWTlV6TlV5a2pMMkFpQW82RmlPUlZUdE91dWJ6L1hi?= =?utf-8?B?b01aMFJ1cXkrZ243dEtwUDJZbEUvN1lBL01HdCtLczd2eUx0YVpHNGdvb09t?= =?utf-8?B?UVI0NWFXYVI1VVl1dk1GQmR2LzlwaVhDbmRPMVJjRE9qNVIzblpRUG9mZnNH?= =?utf-8?B?UzMzdy8ybFhzNHc1ZUtkNXplWmNNY3ZHQzh2RVpFS2tZWjNOOUR1MmRwbkp0?= =?utf-8?B?b1hvZXdDMi9LZ1FPcUY4TENKY2NWR3lEMmZaWlphYmFuUUR5SEkzdlFWVE9R?= =?utf-8?B?OGtBR3MyMUR5QzdXbTNENytOTEVYVzdJMFBQUGlHdU9sZkNWK28yTFovSFQw?= =?utf-8?B?SUtzVjNzYytXU2xvVXRSY2d2T2VXKzIrNkFsUDVXTk1pbHFET0FPYUpnTzBy?= =?utf-8?B?L3RjUjdKR1VhQnFuRXlONnFqQngyU1pyTmlhZnpmdVlBcGZ0RndiSE8vMUFK?= =?utf-8?B?Q0ExcmxMd1VPMXdkS2lWVnZvK3p1MkFUNEc3cDJHaEFMZ0FQSFc2RFZmYlFk?= =?utf-8?B?VTg2cUVkM05nbzZqMEZkY1VpVXprV253Wk43RFV4TU5OVjBYQUh6bkxRS1Z1?= =?utf-8?B?UHc4RTBGaFUrT05jcEpxU085dzJKMW92T0MxWkJ0Q0dTMXQ1alZvY0FKbml0?= =?utf-8?B?ODlzMlFkb2RXeVBYVzg4cTJoZWNhM2tuWFM3bE1zanhMQk14WmxoS3p2bjhl?= =?utf-8?B?UWphUDJzMW1LOEhVRnpZdzlpWjZNSVJzaFcwdUxQa0V5V3U1c2oyeFdRUWxj?= =?utf-8?B?NjFLbjd2blA1VUtQQVJFazk4c0d1L1ZNS0F2Q3NucXNtUWliY0FicTVLbzR5?= =?utf-8?B?RjZnODFvekQzSHZ2STl6K1kzVGNrQ1pqdW5FK0R3S2tPSzFWamRlRXlNbXM1?= =?utf-8?B?Z1NjMTJpL05VVGJsR082a1VmRXI3Q3EwSGRSMHNTQTA5WXRueGZmYWt4ZmpV?= =?utf-8?B?Nm4wdlUraFJaU01vS0NWR09RL0ZKb1hKMTB5L1BrbmRnM3ZSYXZXd3lwalpw?= =?utf-8?B?Nkw2dlM2NFVEVkRqenhvREpzQnRUMDZDaFhvZDdXOWdPcUVsTEtra29MSWpX?= =?utf-8?B?NjRGaEdwbW5UeE4raDhXMXk4aU1LbDVMR25meGRtZWZEbzd0czdReWw1K0xO?= =?utf-8?B?bGk2ZXBQZVdFMWFQN05iQnpmUmlRYjhIRkdzOFJQdUY3Qi90bXIrbXBRYTcx?= =?utf-8?B?Y25adHRld0k5MHRWZkwvMnRid3g1bjM4VFZCK3BZWDFwSnN0UnVabW9ESjB6?= =?utf-8?B?OU5JcGV6R2pteHEwRUF0R0ZXZkRlaTV0UWNMU2t2WDJqbjNlZEJEbWhGS1pz?= =?utf-8?B?NFJMcVo4T09UME1WZFRuUEtlV2ZoQVp3RVM0V09ReTFKLy85UUIrcHp1b3lS?= =?utf-8?B?RFpyMFFISS95TGFHTWxEenRwby9OTEV4UEJHZjBOUVFVOUk1dFptWm1nQ09W?= =?utf-8?B?UmphTGFnV3FVU0tPVjFLWWdzVlp3NWFpZFUyOCtNMUdjS0JrdXRnOTFmK2Mz?= =?utf-8?B?NVpHdHlhN1ZrV1hvWEF1MHFkUkQ2V1BaZ0xPUnZZZ3JKTEF3RWhFclo5aGpQ?= =?utf-8?B?MXF3VVFCZnEvRmNqSU5EYlFHSkdmUm9VdDl1czFEQVhSSzJsVzQ5bnVYbDJn?= =?utf-8?B?d0RJSHZOWjJqUHFSSWZoWW5ocWhvdENpWENaaFYrSDZpcDNGR0U1UENNQzcv?= =?utf-8?B?UWhOOVN4ekpwNm9QSnI5OGNvQjI4SnNZQWtVL082RE50elRrT3l4OEk0d09l?= =?utf-8?B?bWVCMTRBSTczcFNJY0RQOThlSXplNHBmMUgwTTcrMFJITUdvR056WnBVOVla?= =?utf-8?B?YjBiUFA5SmVpOHFsNHhxUFlpU09PanpNWVQ1dUMzZFpPSGlKSk54Y3NmOUxK?= =?utf-8?B?V2dmUWkwZzRCb0V4R0Frc2VDcStUamRrcGpFaDdBUFJ5T0NQZEdlekNhSExn?= =?utf-8?Q?gX2N+PvDdR6TBpi197/uLXVNZ840EhRGqQpqmNtzKE=3D?= X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Message-Info: 6zSiygjYi0TrK/Dtii6dLW0NPxAQLCxNL6L/HwQKe97PGeUbY70mMgAlqKRX5fLH2jSv+1cvkJfRzUZCko4cY2nroWFSeJU8xBiyguJqhO0NCptRPf6D0/WrNkpcEYpIZ6Vp4nwxT8xdIuuJUB97URekA7mZTBCRz9ipRwqSrzp7+j/QIBBZzuz8XprdWXalsOGqUPxAC0uVU5SHU/xasGaiFe/hhE+f6H1OdX/Jzi7Rv/J1itvEpMV8drwu+4Eyym98HKYq65liDZflQAbpX6TwteAuG4g9qz9LwpgW7UcsFmxqC41CpvQEk5Pwp5mEm+XEm/9l+vCSdjf2fCyZRAQ7Ovi11EZLcAuxXaG8QOWD99082D6U8hc8gn2wXKRkXc6Hr6SmgLelpfjgbRgMJVfelZkT1ABXVBigV63HnZM= X-Microsoft-Exchange-Diagnostics: 1; HE1P189MB0330; 6:J+orQqakArXCS0gnN32asHv+0J0hVDQTHTzCLcAXBCRhfXe6vpd9E9ZyeckFL3/i3P8E3hB1sc//dyKPXOih084UuNon6G1tnRw9q9A/TLwJl5h5OtKrEhLtREit0EjUUzCxXERaHdt2q6igCoxrDKgW0NNdCzo6byI0APlgVDLRrkLOEeXkqsDbQtQQ8bs2Xr0AzOPRfQCfAirmDnEhuq012bX6RPKhaRnClvxq6roezVo+sZlsQJ1axKbYe8MOola3JeTx7EMvQpXFtFTYQ6iWe+Zv+hAXUttXOSrKgcRJW0ZHbcr9Ns7SrfcabE9T/RRcw3kCm4/bdnVB6wukqgNOMYrm1/XD6w0WerIuxQJZyRKBIDJXuMGmDKeem81SwWzAbcaHzi9Fhh3JzWKifR4mfAZsGIdfM4OqftPClyeYs8O8BykAn5jv1aieKPlhRh8qiSeoyY+jQAVv6bx+sA==; 5:uNnG9L8vmsloQ9TOy9emSZau4EcZ7lLT4R5I7h75cg4m1Y6XzrfYgZPgtf6nriclG5AFuNcrhHYIPDU/vaqD4deKpkmVjxntTbzaw/Q7NMU5Wha2CKKPfoshqNVmrR98err6IKqD1Kaz8odjybzPzcjJXY3z0rWGJ5glyewI/gTiiq4LSJR8qUmbUyohwsgy66PhBN8TPXz76kZmiZ91CA==; 7:4yAko92hXMxzz/pByGu6JVapi9HrYmcbYXBRMxJbvx9eh383xI5bvYANp3TfERWdoA1vI4ib3/GmbRVs3z56Oi0UaOhUEqZcSw2Rvmo73tyxhy8JlL0viICQySl2W87B2NGNHZUh/tY7hgMQHGCM8A== SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Jan 2019 14:47:37.9719 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 47e2479c-c3a1-4790-c33a-08d67c8ab996 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: HE1P189MB0330 Archived-At: Subject: [Ace] Fwd: New Version Notification for draft-ietf-ace-oauth-authz-18.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, 17 Jan 2019 14:47:46 -0000 Hello ACE, I have uploaded a new version of draft-ietf-ace-oauth-authz based on the review by and discussion with Stefanie Gerdes (thank you!). Please check whether there are any issues remaining. /Ludwig -------- Forwarded Message -------- Subject: New Version Notification for draft-ietf-ace-oauth-authz-18.txt Date: Thu, 17 Jan 2019 06:45:56 -0800 From: internet-drafts@ietf.org To: Ludwig Seitz , Hannes Tschofenig , Goeran Selander , Samuel Erdtman , Erik Wahlstroem A new version of I-D, draft-ietf-ace-oauth-authz-18.txt has been successfully submitted by Ludwig Seitz and posted to the IETF repository. Name: draft-ietf-ace-oauth-authz Revision: 18 Title: Authentication and Authorization for Constrained Environments (ACE) using the OAuth 2.0 Framework (ACE-OAuth) Document date: 2019-01-17 Group: ace Pages: 75 URL: https://www.ietf.org/internet-drafts/draft-ietf-ace-oauth-authz-18.txt Status: https://datatracker.ietf.org/doc/draft-ietf-ace-oauth-authz/ Htmlized: https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-18 Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-ace-oauth-authz Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-oauth-authz-18 Abstract: This specification defines a framework for authentication and authorization in Internet of Things (IoT) environments called ACE- OAuth. The framework is based on a set of building blocks including OAuth 2.0 and CoAP, thus making a well-known and widely used authorization solution suitable for IoT devices. Existing specifications are used where possible, but where the constraints of IoT devices require it, extensions are added and profiles are defined. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Fri Jan 18 08:55:09 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDD011311B1 for ; Fri, 18 Jan 2019 08:55:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.041 X-Spam-Level: X-Spam-Status: No, score=-2.041 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8tCgZP_BGgr9 for ; Fri, 18 Jan 2019 08:55:04 -0800 (PST) Received: from mail-yw1-xc2f.google.com (mail-yw1-xc2f.google.com [IPv6:2607:f8b0:4864:20::c2f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 329611311DD for ; Fri, 18 Jan 2019 08:55:04 -0800 (PST) Received: by mail-yw1-xc2f.google.com with SMTP id k188so5478897ywa.6 for ; Fri, 18 Jan 2019 08:55:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=1vmLfsF22ttV/NLEhxehCDgN29VUeEoEeDZESyQB5GA=; b=DffNEqLkKLbxcrtjDML78Vh7uNOVE9CqRM1QdfJSf+cLpGauSf4xUb5H4ZKEa03hhW Qfco7ga6ymbrAJXe5L0svrT5c7Wv4CDXrvuZIbDkIrvCq4C+njTI9jktgtp+K5FhchLQ FaN0HGSbyS4N0tJd1zq3cn3Bqm3/9W1OAsabHnANOUl752iRp9eXjOr328X6b19MzMtN oxvkeYv+16j41P1T3Z9Dq8N1y7oy46R3BjRLtfuUG889ysQtNgaJQjYga9w7ihiYW3jr LBIPNh+S+A0wdaZP6IeQknXBxO2WAdmL8KgqHTuzk1RxxeoGF9ztBO+paYMe5Ct/WmLm 7yTw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=1vmLfsF22ttV/NLEhxehCDgN29VUeEoEeDZESyQB5GA=; b=KbqbPB7WnnjFRrA6bmjS2QAYPxfd7wAdC7q9Nvu8A/gtKtFHB30Hxa6R+ecBMQr1lH UXtxGA0dPvNNjIlehbud7yqVh7BP/hIpdgb+FZB/FE/2oAPoXso6vtvxCMwA1fYjHCzV gD/yIulmNNeZNNl+TlrQKZQf2jUqUhjEvUv8Twd9kFKX0jSk9FI68RpypL/NZVHp1x6y +BQ2drOGVa6urCsajFDsFwVoRSpf7RCUMWsDAJGTykKkadZzDRXie6IaBVAViGRUrYK7 UMu5We1MmuqCZuhiYi8hMV5BCs8vx5HQp74twkMHNPev3tza9Ofudi2ujhF6K/k9kkYo AH+w== X-Gm-Message-State: AJcUukfFiJmpeYDfPtPu0r+s7bVACBh6JmnUWuQ5cgKNMJJZpGIbB3YI r/sF2D807B6tHcLj9RbYNHq/LQ== X-Google-Smtp-Source: ALg8bN7pQlzhF8BwF4FEpZIcthWXIONZKCIc5mnafr8mpSddbp0GMz2x7P3iVDTgYS9gmZsm2wuA4Q== X-Received: by 2002:a81:ec0f:: with SMTP id j15mr18142104ywm.214.1547830503078; Fri, 18 Jan 2019 08:55:03 -0800 (PST) Received: from [10.24.79.55] ([128.107.241.168]) by smtp.gmail.com with ESMTPSA id j12sm1943462ywk.43.2019.01.18.08.55.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 18 Jan 2019 08:55:02 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Richard Barnes In-Reply-To: Date: Fri, 18 Jan 2019 11:54:58 -0500 Cc: Kathleen Moriarty , "ace@ietf.org" , Francesca Palombini , John Mattsson , "secdispatch@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <47F03C99-68C1-4ADB-873D-F01987D66849@ipv.sx> References: <79FD6563-8ADA-4D73-B8D5-C3D70604CD76@gmail.com> To: =?utf-8?Q?G=C3=B6ran_Selander?= X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [Ace] [Secdispatch] EDHOC 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, 18 Jan 2019 16:55:07 -0000 Let me provide some additional context. When the chairs and ADs = discussed this in BKK, it seemed pretty clear that EDHOC is not within = the current charter of ACE =E2=80=94 after all, ACE is targeted at = authentication and authorization, not key exchange. Since ACE would = need to recharter to accept this work in any case, and because EDHOC = overlapped with the interests of other working groups, it seemed to make = sense to have the conversation in a broader venue. G=C3=B6ran: Your email starting this thread seems like an abbreviated = summary of the past discussion of this draft. Since this is a new = audience, it would be helpful if you could start from the underlying = requirements (=E2=80=9Cwe need an AKE with certain constraints=E2=80=9D) = and lay out why new protocol work is needed, vs. profiling existing = protocols (as has been done, e.g., in DICE). If it would be helpful to keep this moving, we could certainly arrange a = virtual interim on this topic. =E2=80=94Richard > On Jan 4, 2019, at 1:17 AM, G=C3=B6ran Selander = wrote: >=20 > Hi Kathleen, >=20 > Good question. Thanks for bringing continuity to this almost 2 years = long offline discussion. Indeed, lack of comparison with other protocols = and formal verification were at the time the arguments for not following = up the in-room consensus with an email confirmation. And, as you noted, = that is not the case anymore. >=20 > Meanwhile the ACE chairs and AD have changed. My understanding is that = the argument now is about attracting more people with a certain security = competence for which perhaps another WG could potentially be better, = hence the request to Secdispatch. But I'll pass the question on and = include the ACE WG for transparency. >=20 > =46rom the authors' humble point of view we believe that the main = missing thing that would enable the required further discussion is that = the IETF endorses this work, no matter how, so that people dare invest = more time in implementation and analysis.=20 >=20 > Best regards, > G=C3=B6ran >=20 >=20 > =EF=BB=BFOn 2019-01-03, 00:58, "Kathleen Moriarty" = wrote: >=20 > Hi, >=20 > I=E2=80=99ve read earlier versions of this draft and appreciate all = the work you have done with the security proof and comparing to existing = standardized protocols. If ACE is interested, why is this going to = SECDispatch? It might help to understand that better. Is it that a = recharter would be needed? >=20 > Thank you & happy new year! > Kathleen=20 >=20 > Sent from my mobile device >=20 >> On Jan 2, 2019, at 5:56 PM, G=C3=B6ran Selander = wrote: >>=20 >> Dear Secdispatch, >>=20 >> We have been advised to ask secdispatch to consider EDHOC: = https://tools.ietf.org/html/draft-selander-ace-cose-ecdhe >>=20 >> Those that follow the ACE WG should be familiar with this draft. The = problem statement and motivation for EDHOC is described in section 1. In = brief, the target is a lightweight key exchange protocol suitable for = IoT applications, which: >> a) has small message size and reuses existing IoT primitives to = enable low overhead and small code footprint;=20 >> b) is not bound to a particular transport, to enable end-to-end = security in IoT deployments with varying underlying layers; and >> c) can be used to key OSCORE (draft-ietf-core-object-security) that = is lacking a harmonizing key exchange protocol. >>=20 >> These requirements are motivated by constrained IoT device = deployments, but the protocol is applicable to other end-to-end security = settings where the overhead due to security needs to be low. EDHOC = addresses these requirements and builds on the SIGMA construction for = Diffie-Hellman key exchanges. EDHOC, like OSCORE, is built on CBOR (RFC = 7049) and COSE (RFC 8152) and the protocol messages may be transported = with CoAP (RFC 7252). =20 >>=20 >> There has been a number of reviews of different versions of the = draft; both by people who want to deploy it and by people analysing the = security. A formal verification was presented at SSR 2018. There are a = few implementations of different versions of the draft. The ACE WG has = expressed interest in this work in several f2f meetings. >>=20 >> Please let us know if some information is missing for secdispatch to = consider this draft, or how we can help out in the process. >>=20 >> Best regards >> G=C3=B6ran, John, Francesca >>=20 >>=20 >> _______________________________________________ >> Secdispatch mailing list >> Secdispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/secdispatch >=20 >=20 From nobody Fri Jan 18 09:06:53 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4321130E92; Fri, 18 Jan 2019 09:06:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Byu5JjOEYNhK; Fri, 18 Jan 2019 09:06:42 -0800 (PST) Received: from mail-qt1-x82d.google.com (mail-qt1-x82d.google.com [IPv6:2607:f8b0:4864:20::82d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DD8C130E8E; Fri, 18 Jan 2019 09:06:42 -0800 (PST) Received: by mail-qt1-x82d.google.com with SMTP id t13so15971964qtn.3; Fri, 18 Jan 2019 09:06:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=DAdbCXSg6FLCtBM3e8kts9UTb1TNt03mfPSjDoKbY3w=; b=Y0POdS0+YFyEE6fH+xoEFD2p/Z+C5MRwRe0oHks7MHDqQyCttFQp+q72JKYZlkEHKZ 8I64sPINN6CE88yt1c6tnTsydBZtLgi6J5GRAglVKYayvlJJbQ/aieVqY3SUbS9aAzJ0 OOFv/rjMSSJGYp0OxblRk3cI2REH/6zs0VgyTRrcdolvf7e4ORwVL7gmjX2ZspvsCCWK 25VJD+/UZw74tRMplygmlJko5w8OCcWuHjvtroKmkrS7jNHVj3Q3hQjjaPS9Z1bh6bak j3ysUqKSJoqNc5Q9GK/e/oQgB6CWWuykmXuH0t87d+BfgSnQqrAQ0E7yYSV7tzMCkyy+ lBUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=DAdbCXSg6FLCtBM3e8kts9UTb1TNt03mfPSjDoKbY3w=; b=isqItkwVCgwunHksdbJxMVwetLmCQv1ecSannLK1gR60tZ/NG2fvBwZhQHaz6c8kUb l3GrPc2macAv3/xioX34+MTzGl7vssMti97cW5XPbSEjNCSPXH9XsDOSGa6BNQSuDM5W 5k2jFPt49LLllG8M3MJLNDQnqULqVMqcXOU2aYTlXAXkHIZaPbDa3oEQp/o3OEI85gmJ /hlti9nkPQLpkymKVw74l6S7i+xKOJScqtCQ5RItf+kQZsvWx6fJbYu+KuduxJoV2hxX 6nH9GvE140XP8aRqqYWR1c+qeonaFewbiXGwYGnHMVsNgT5NCgr9lEihW6x3DXcjj0ld vX8Q== X-Gm-Message-State: AJcUukej3pG5fPNI7EwZTFA6+GsfDO6V48QG7I0RIP818GiO6buSkTpW eJqWNhpV2t7YqrX02kTzMPs= X-Google-Smtp-Source: ALg8bN65SUHLBhIV3DbxTBP//t3bUufXkiKlUbqTruByIRpPq/71pGaX43qlbWAQDpcdzRYLuBh4QQ== X-Received: by 2002:a0c:d40f:: with SMTP id t15mr16589997qvh.117.1547831201359; Fri, 18 Jan 2019 09:06:41 -0800 (PST) Received: from ?IPv6:2600:380:8d54:8c15:d4de:e39b:794d:169a? ([2600:380:8d54:8c15:d4de:e39b:794d:169a]) by smtp.gmail.com with ESMTPSA id f19sm60297596qtf.1.2019.01.18.09.06.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 18 Jan 2019 09:06:40 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Kathleen Moriarty X-Mailer: iPhone Mail (15E216) In-Reply-To: <47F03C99-68C1-4ADB-873D-F01987D66849@ipv.sx> Date: Fri, 18 Jan 2019 12:06:40 -0500 Cc: =?utf-8?Q?G=C3=B6ran_Selander?= , "ace@ietf.org" , Francesca Palombini , John Mattsson , "secdispatch@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <2E8F9AF0-4A06-49DA-B70D-7CBEF0BFA3AF@gmail.com> References: <79FD6563-8ADA-4D73-B8D5-C3D70604CD76@gmail.com> <47F03C99-68C1-4ADB-873D-F01987D66849@ipv.sx> To: Richard Barnes Archived-At: Subject: Re: [Ace] [Secdispatch] EDHOC 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, 18 Jan 2019 17:06:46 -0000 Can that be a public thread? It really should be. Sent from my mobile device > On Jan 18, 2019, at 11:54 AM, Richard Barnes wrote: >=20 > Let me provide some additional context. When the chairs and ADs discussed= this in BKK, it seemed pretty clear that EDHOC is not within the current ch= arter of ACE =E2=80=94 after all, ACE is targeted at authentication and auth= orization, not key exchange. Since ACE would need to recharter to accept th= is work in any case, and because EDHOC overlapped with the interests of othe= r working groups, it seemed to make sense to have the conversation in a broa= der venue. >=20 > G=C3=B6ran: Your email starting this thread seems like an abbreviated summ= ary of the past discussion of this draft. Since this is a new audience, it w= ould be helpful if you could start from the underlying requirements (=E2=80=9C= we need an AKE with certain constraints=E2=80=9D) and lay out why new protoc= ol work is needed, vs. profiling existing protocols (as has been done, e.g.,= in DICE). >=20 > If it would be helpful to keep this moving, we could certainly arrange a v= irtual interim on this topic. >=20 > =E2=80=94Richard >=20 >=20 >> On Jan 4, 2019, at 1:17 AM, G=C3=B6ran Selander wrote: >>=20 >> Hi Kathleen, >>=20 >> Good question. Thanks for bringing continuity to this almost 2 years long= offline discussion. Indeed, lack of comparison with other protocols and for= mal verification were at the time the arguments for not following up the in-= room consensus with an email confirmation. And, as you noted, that is not th= e case anymore. >>=20 >> Meanwhile the ACE chairs and AD have changed. My understanding is that th= e argument now is about attracting more people with a certain security compe= tence for which perhaps another WG could potentially be better, hence the re= quest to Secdispatch. But I'll pass the question on and include the ACE WG f= or transparency. >>=20 >> =46rom the authors' humble point of view we believe that the main missing= thing that would enable the required further discussion is that the IETF en= dorses this work, no matter how, so that people dare invest more time in imp= lementation and analysis.=20 >>=20 >> Best regards, >> G=C3=B6ran >>=20 >>=20 >> =EF=BB=BFOn 2019-01-03, 00:58, "Kathleen Moriarty" wrote: >>=20 >> Hi, >>=20 >> I=E2=80=99ve read earlier versions of this draft and appreciate all the= work you have done with the security proof and comparing to existing standa= rdized protocols. If ACE is interested, why is this going to SECDispatch? I= t might help to understand that better. Is it that a recharter would be nee= ded? >>=20 >> Thank you & happy new year! >> Kathleen=20 >>=20 >> Sent from my mobile device >>=20 >>> On Jan 2, 2019, at 5:56 PM, G=C3=B6ran Selander wrote: >>>=20 >>> Dear Secdispatch, >>>=20 >>> We have been advised to ask secdispatch to consider EDHOC: https://tools= .ietf.org/html/draft-selander-ace-cose-ecdhe >>>=20 >>> Those that follow the ACE WG should be familiar with this draft. The pro= blem statement and motivation for EDHOC is described in section 1. In brief,= the target is a lightweight key exchange protocol suitable for IoT applicat= ions, which: >>> a) has small message size and reuses existing IoT primitives to enable l= ow overhead and small code footprint;=20 >>> b) is not bound to a particular transport, to enable end-to-end security= in IoT deployments with varying underlying layers; and >>> c) can be used to key OSCORE (draft-ietf-core-object-security) that is l= acking a harmonizing key exchange protocol. >>>=20 >>> These requirements are motivated by constrained IoT device deployments, b= ut the protocol is applicable to other end-to-end security settings where th= e overhead due to security needs to be low. EDHOC addresses these requiremen= ts and builds on the SIGMA construction for Diffie-Hellman key exchanges. ED= HOC, like OSCORE, is built on CBOR (RFC 7049) and COSE (RFC 8152) and the pr= otocol messages may be transported with CoAP (RFC 7252). =20 >>>=20 >>> There has been a number of reviews of different versions of the draft; b= oth by people who want to deploy it and by people analysing the security. A f= ormal verification was presented at SSR 2018. There are a few implementation= s of different versions of the draft. The ACE WG has expressed interest in t= his work in several f2f meetings. >>>=20 >>> Please let us know if some information is missing for secdispatch to con= sider this draft, or how we can help out in the process. >>>=20 >>> Best regards >>> G=C3=B6ran, John, Francesca >>>=20 >>>=20 >>> _______________________________________________ >>> Secdispatch mailing list >>> Secdispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/secdispatch >>=20 >>=20 >=20 From nobody Fri Jan 18 09:12:27 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A715D130EAC for ; Fri, 18 Jan 2019 09:12:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.04 X-Spam-Level: X-Spam-Status: No, score=-2.04 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vNlrpkBBPx0g for ; Fri, 18 Jan 2019 09:12:16 -0800 (PST) Received: from mail-ot1-x32c.google.com (mail-ot1-x32c.google.com [IPv6:2607:f8b0:4864:20::32c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AEE7130E8A for ; Fri, 18 Jan 2019 09:12:16 -0800 (PST) Received: by mail-ot1-x32c.google.com with SMTP id f18so14979632otl.11 for ; Fri, 18 Jan 2019 09:12:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3KEjCeMlWqTghvBIHUPsmyNJb5RGWuzSxfKVKvnpHvA=; b=NK7CbcavoJ0okf7LhDyxR8+MbF79XCqF1Ui5F8e1keuGkt0jm364SvyYMwXrZgtWFB 0H0X5lrwEQ/WjoyE7kyjUaTYsn4DyJ2AQtPArhw6xFaasMGqS2mD8hFpu91Xlt9pqpqN /JECKL/Xd9xBES/Y6pZEWhtPxN76hqewmfemC8F8biafxqqG9WsE/awv12LcN5XVX9QD EtYXht35U7F5u2iHzXm/DNWoPv8pD20rniNNzel5s20hdrFb0ZtkbcFc1UNa2zmncz4X /+z/y6EzcN0fY10hJwCDw8uXAEw3IN9kTYrvceYBdi5H3cYL+zI8wCi+tdxkv6iqq9bN k2hg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=3KEjCeMlWqTghvBIHUPsmyNJb5RGWuzSxfKVKvnpHvA=; b=I4ifO9tvIFMAAV+2s9am6qJdVBQ51HDUPwcoxif7yGSTeF+CjhmTeVslWYqHA8LOV/ Q6TV2YL1drU3MU5vJNET0+va3GNA8KwyxRErAo86ptCpmmAZ3AoPKNRYDSI+jjrILfg6 FL8vzkVCeMi41dgqdBDjkfJMuCtRSJ2hk3cCutz9Geu3XjiERiQwv/FSRwSHUBGXy+Hu GURK5A4AsAR7T0YTjfu8XobnsCo4xGxU9ThRhIDXnLZFvtIQ+6PK8KlNA0rsoGIEzbRE 0ky2lHN2GB69u+p2adlF4h5bcv8qnUa5yM0DSXx/ZFCMptgDWRVpWFdrG5iRSs+ssUyO ELtw== X-Gm-Message-State: AJcUukcTsLzJt6Qqm1GQTejKc96LU/mJAuUOZgG7SXVqQftrDR5BL/C4 Y0w9Ujd40wSQi/5ozfOCPrLgmIKwIPY/T57whuazSg== X-Google-Smtp-Source: ALg8bN6hzasix7ezN6+qk++9Sln7HfPaB0v7f291FGIt0a3sd9lXIjDh8BbKmALErBPrwO4IoUtxxyXhewaSgClho8w= X-Received: by 2002:a9d:1b0b:: with SMTP id l11mr12992077otl.162.1547831535257; Fri, 18 Jan 2019 09:12:15 -0800 (PST) MIME-Version: 1.0 References: <79FD6563-8ADA-4D73-B8D5-C3D70604CD76@gmail.com> <47F03C99-68C1-4ADB-873D-F01987D66849@ipv.sx> <2E8F9AF0-4A06-49DA-B70D-7CBEF0BFA3AF@gmail.com> In-Reply-To: <2E8F9AF0-4A06-49DA-B70D-7CBEF0BFA3AF@gmail.com> From: Richard Barnes Date: Fri, 18 Jan 2019 12:12:03 -0500 Message-ID: To: Kathleen Moriarty Cc: =?UTF-8?Q?G=C3=B6ran_Selander?= , "ace@ietf.org" , Francesca Palombini , John Mattsson , "secdispatch@ietf.org" Content-Type: multipart/alternative; boundary="000000000000d4da09057fbe9cf3" Archived-At: Subject: Re: [Ace] [Secdispatch] EDHOC 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, 18 Jan 2019 17:12:20 -0000 --000000000000d4da09057fbe9cf3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Not sure what you mean, Kathleen. This is a public mailing list :) On Fri, Jan 18, 2019 at 12:06 PM Kathleen Moriarty < kathleen.moriarty.ietf@gmail.com> wrote: > Can that be a public thread? It really should be. > > Sent from my mobile device > > > On Jan 18, 2019, at 11:54 AM, Richard Barnes wrote: > > > > Let me provide some additional context. When the chairs and ADs > discussed this in BKK, it seemed pretty clear that EDHOC is not within th= e > current charter of ACE =E2=80=94 after all, ACE is targeted at authentica= tion and > authorization, not key exchange. Since ACE would need to recharter to > accept this work in any case, and because EDHOC overlapped with the > interests of other working groups, it seemed to make sense to have the > conversation in a broader venue. > > > > G=C3=B6ran: Your email starting this thread seems like an abbreviated s= ummary > of the past discussion of this draft. Since this is a new audience, it > would be helpful if you could start from the underlying requirements (=E2= =80=9Cwe > need an AKE with certain constraints=E2=80=9D) and lay out why new protoc= ol work is > needed, vs. profiling existing protocols (as has been done, e.g., in DICE= ). > > > > If it would be helpful to keep this moving, we could certainly arrange = a > virtual interim on this topic. > > > > =E2=80=94Richard > > > > > >> On Jan 4, 2019, at 1:17 AM, G=C3=B6ran Selander > wrote: > >> > >> Hi Kathleen, > >> > >> Good question. Thanks for bringing continuity to this almost 2 years > long offline discussion. Indeed, lack of comparison with other protocols > and formal verification were at the time the arguments for not following = up > the in-room consensus with an email confirmation. And, as you noted, that > is not the case anymore. > >> > >> Meanwhile the ACE chairs and AD have changed. My understanding is that > the argument now is about attracting more people with a certain security > competence for which perhaps another WG could potentially be better, henc= e > the request to Secdispatch. But I'll pass the question on and include the > ACE WG for transparency. > >> > >> From the authors' humble point of view we believe that the main missin= g > thing that would enable the required further discussion is that the IETF > endorses this work, no matter how, so that people dare invest more time i= n > implementation and analysis. > >> > >> Best regards, > >> G=C3=B6ran > >> > >> > >> =EF=BB=BFOn 2019-01-03, 00:58, "Kathleen Moriarty" < > kathleen.moriarty.ietf@gmail.com> wrote: > >> > >> Hi, > >> > >> I=E2=80=99ve read earlier versions of this draft and appreciate all = the work > you have done with the security proof and comparing to existing > standardized protocols. If ACE is interested, why is this going to > SECDispatch? It might help to understand that better. Is it that a > recharter would be needed? > >> > >> Thank you & happy new year! > >> Kathleen > >> > >> Sent from my mobile device > >> > >>> On Jan 2, 2019, at 5:56 PM, G=C3=B6ran Selander < > goran.selander@ericsson.com> wrote: > >>> > >>> Dear Secdispatch, > >>> > >>> We have been advised to ask secdispatch to consider EDHOC: > https://tools.ietf.org/html/draft-selander-ace-cose-ecdhe > >>> > >>> Those that follow the ACE WG should be familiar with this draft. The > problem statement and motivation for EDHOC is described in section 1. In > brief, the target is a lightweight key exchange protocol suitable for IoT > applications, which: > >>> a) has small message size and reuses existing IoT primitives to enabl= e > low overhead and small code footprint; > >>> b) is not bound to a particular transport, to enable end-to-end > security in IoT deployments with varying underlying layers; and > >>> c) can be used to key OSCORE (draft-ietf-core-object-security) that i= s > lacking a harmonizing key exchange protocol. > >>> > >>> These requirements are motivated by constrained IoT device > deployments, but the protocol is applicable to other end-to-end security > settings where the overhead due to security needs to be low. EDHOC > addresses these requirements and builds on the SIGMA construction for > Diffie-Hellman key exchanges. EDHOC, like OSCORE, is built on CBOR (RFC > 7049) and COSE (RFC 8152) and the protocol messages may be transported wi= th > CoAP (RFC 7252). > >>> > >>> There has been a number of reviews of different versions of the draft= ; > both by people who want to deploy it and by people analysing the security= . > A formal verification was presented at SSR 2018. There are a few > implementations of different versions of the draft. The ACE WG has > expressed interest in this work in several f2f meetings. > >>> > >>> Please let us know if some information is missing for secdispatch to > consider this draft, or how we can help out in the process. > >>> > >>> Best regards > >>> G=C3=B6ran, John, Francesca > >>> > >>> > >>> _______________________________________________ > >>> Secdispatch mailing list > >>> Secdispatch@ietf.org > >>> https://www.ietf.org/mailman/listinfo/secdispatch > >> > >> > > > --000000000000d4da09057fbe9cf3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Not sure what you mean, Kathleen.=C2=A0 This is a public m= ailing list :)

On Fri, Jan 18, 2019 at 12:06 PM Kathleen Moriarty <kathleen.moriarty.ietf@gm= ail.com> wrote:
Can that be a public thread?=C2=A0 It really should be.

Sent from my mobile device

> On Jan 18, 2019, at 11:54 AM, Richard Barnes <rlb@ipv.sx> wrote:=
>
> Let me provide some additional context.=C2=A0 When the chairs and ADs = discussed this in BKK, it seemed pretty clear that EDHOC is not within the = current charter of ACE =E2=80=94 after all, ACE is targeted at authenticati= on and authorization, not key exchange.=C2=A0 Since ACE would need to recha= rter to accept this work in any case, and because EDHOC overlapped with the= interests of other working groups, it seemed to make sense to have the con= versation in a broader venue.
>
> G=C3=B6ran: Your email starting this thread seems like an abbreviated = summary of the past discussion of this draft.=C2=A0 Since this is a new aud= ience, it would be helpful if you could start from the underlying requireme= nts (=E2=80=9Cwe need an AKE with certain constraints=E2=80=9D) and lay out= why new protocol work is needed, vs. profiling existing protocols (as has = been done, e.g., in DICE).
>
> If it would be helpful to keep this moving, we could certainly arrange= a virtual interim on this topic.
>
> =E2=80=94Richard
>
>
>> On Jan 4, 2019, at 1:17 AM, G=C3=B6ran Selander <goran.selander@ericsson.= com> wrote:
>>
>> Hi Kathleen,
>>
>> Good question. Thanks for bringing continuity to this almost 2 yea= rs long offline discussion. Indeed, lack of comparison with other protocols= and formal verification were at the time the arguments for not following u= p the in-room consensus with an email confirmation. And, as you noted, that= is not the case anymore.
>>
>> Meanwhile the ACE chairs and AD have changed. My understanding is = that the argument now is about attracting more people with a certain securi= ty competence for which perhaps another WG could potentially be better, hen= ce the request to Secdispatch. But I'll pass the question on and includ= e the ACE WG for transparency.
>>
>> From the authors' humble point of view we believe that the mai= n missing thing that would enable the required further discussion is that t= he IETF endorses this work, no matter how, so that people dare invest more = time in implementation and analysis.
>>
>> Best regards,
>> G=C3=B6ran
>>
>>
>> =EF=BB=BFOn 2019-01-03, 00:58, "Kathleen Moriarty" <<= a href=3D"mailto:kathleen.moriarty.ietf@gmail.com" target=3D"_blank">kathle= en.moriarty.ietf@gmail.com> wrote:
>>
>>=C2=A0 =C2=A0Hi,
>>
>>=C2=A0 =C2=A0I=E2=80=99ve read earlier versions of this draft and a= ppreciate all the work you have done with the security proof and comparing = to existing standardized protocols.=C2=A0 If ACE is interested, why is this= going to SECDispatch? It might help to understand that better.=C2=A0 Is it= that a recharter would be needed?
>>
>>=C2=A0 =C2=A0Thank you & happy new year!
>>=C2=A0 =C2=A0Kathleen
>>
>>=C2=A0 =C2=A0Sent from my mobile device
>>
>>> On Jan 2, 2019, at 5:56 PM, G=C3=B6ran Selander <goran.selander@erics= son.com> wrote:
>>>
>>> Dear Secdispatch,
>>>
>>> We have been advised to ask secdispatch to consider EDHOC: https://tools.ietf.org/html/draft-selander-ace= -cose-ecdhe
>>>
>>> Those that follow the ACE WG should be familiar with this draf= t. The problem statement and motivation for EDHOC is described in section 1= . In brief, the target is a lightweight key exchange protocol suitable for = IoT applications, which:
>>> a) has small message size and reuses existing IoT primitives t= o enable low overhead and small code footprint;
>>> b) is not bound to a particular transport, to enable end-to-en= d security in IoT deployments with varying underlying layers; and
>>> c) can be used to key OSCORE (draft-ietf-core-object-security)= that is lacking a harmonizing key exchange protocol.
>>>
>>> These requirements are motivated by constrained IoT device dep= loyments, but the protocol is applicable to other end-to-end security setti= ngs where the overhead due to security needs to be low. EDHOC addresses the= se requirements and builds on the SIGMA construction for Diffie-Hellman key= exchanges. EDHOC, like OSCORE, is built on CBOR (RFC 7049) and COSE (RFC 8= 152) and the protocol messages may be transported with CoAP (RFC 7252).=C2= =A0
>>>
>>> There has been a number of reviews of different versions of th= e draft; both by people who want to deploy it and by people analysing the s= ecurity. A formal verification was presented at SSR 2018. There are a few i= mplementations of different versions of the draft. The ACE WG has expressed= interest in this work in several f2f meetings.
>>>
>>> Please let us know if some information is missing for secdispa= tch to consider this draft, or how we can help out in the process.
>>>
>>> Best regards
>>> G=C3=B6ran, John, Francesca
>>>
>>>
>>> _______________________________________________
>>> Secdispatch mailing list
>>> Secd= ispatch@ietf.org
>>> https://www.ietf.org/mailman/listinfo/= secdispatch
>>
>>
>
--000000000000d4da09057fbe9cf3-- From nobody Fri Jan 18 09:15:17 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7140F131209; Fri, 18 Jan 2019 09:15:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id whtQwVMpn-Fn; Fri, 18 Jan 2019 09:15:05 -0800 (PST) Received: from mail-qt1-x82a.google.com (mail-qt1-x82a.google.com [IPv6:2607:f8b0:4864:20::82a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48040130EAC; Fri, 18 Jan 2019 09:15:05 -0800 (PST) Received: by mail-qt1-x82a.google.com with SMTP id v11so16046067qtc.2; Fri, 18 Jan 2019 09:15:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=wixZX43TuwB6T/GbzLWwUGBqu3qmEYteW/wQfC/kOtU=; b=FnMtBTARVYBh7lHiYj7QNpOKLPk7grp6CP3uRTm9xW34x7tNIC83Mz2NOGtscT7+r4 LojNraGxu4cSAU9UI6zxO6fcjR4283vw7BhrhWg1qdBKuuoRFrWxQyIWA6gRgRjJ/8yd 7k+kkqSa2DqVnGBXONIUNnTssm6cvX23/4aQSzpjFg+vBpTQR82veEl8kWxBvCkLyoRf AP7XF8kv2JL26bsUdB4fh1C3kkCOpDuyc+Vb9B+/t/X5Ftc+oWBeSN24BYlNxSoDmsoj czY6c4NIGs1hh5IshgVaoBw2qlmB7sM9rZVdq3kCMwosYRipa8hhRBrC6mDCZMLGqwpo E9Hg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=wixZX43TuwB6T/GbzLWwUGBqu3qmEYteW/wQfC/kOtU=; b=Q/WZTQCzHOgxDclEnuQy7ftk7eJYh5DZs2wx5iB6DQRsCJi+sQkbw8lXAgrNCyhBsC zpGje6m7Fuz0YmZYKXX9pM8koYIiyOoHCRRqBCcqO2NITj0/MNJM8qEWMdQaWSOSpdGB pkmnXNey5jVQQ6CoDUWfyrR9q7oK9149O/yBl1WyTBsbpnamum2Kg8Iu0z1POJgTuZWz AqgKcYiCSUSazZpz5zfDzbSlO9yPF94IGFPeEwAD8qqNDMMUa/BRsbNuYdyrOwZE2mnG C7Lgrk+84jELt+vPwz6aq9mKLRqLivvDFB+o+Lt2wlZpi7GckTUWODnWNLBEI5V+sokR 52jQ== X-Gm-Message-State: AJcUukfa/+UxAgizP16HDbVn9QOwag9XgSvDOnW+QY+wI6IpTKVzRGma 9I2WG+rrv4w/2wIVeaKtIeqb9Ssb X-Google-Smtp-Source: ALg8bN73QtGwqYqNzP1RoU87Rb4vpqA6FhNkCc9TOKLlO3lg8QtdaZDOdGUqjFyNYPYEYo1d9cGEGw== X-Received: by 2002:aed:2dc5:: with SMTP id i63mr17175873qtd.173.1547831704458; Fri, 18 Jan 2019 09:15:04 -0800 (PST) Received: from ?IPv6:2600:380:8d54:8c15:d4de:e39b:794d:169a? ([2600:380:8d54:8c15:d4de:e39b:794d:169a]) by smtp.gmail.com with ESMTPSA id c71sm22343796qke.84.2019.01.18.09.15.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 18 Jan 2019 09:15:03 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-D39A2768-A2D3-4A56-B949-0455BEA817F3 Mime-Version: 1.0 (1.0) From: Kathleen Moriarty X-Mailer: iPhone Mail (15E216) In-Reply-To: Date: Fri, 18 Jan 2019 12:15:02 -0500 Cc: =?utf-8?Q?G=C3=B6ran_Selander?= , "ace@ietf.org" , Francesca Palombini , John Mattsson , "secdispatch@ietf.org" Content-Transfer-Encoding: 7bit Message-Id: <1055DC04-EABF-4C68-907C-1321F94F5227@gmail.com> References: <79FD6563-8ADA-4D73-B8D5-C3D70604CD76@gmail.com> <47F03C99-68C1-4ADB-873D-F01987D66849@ipv.sx> <2E8F9AF0-4A06-49DA-B70D-7CBEF0BFA3AF@gmail.com> To: Richard Barnes Archived-At: Subject: Re: [Ace] [Secdispatch] EDHOC 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, 18 Jan 2019 17:15:09 -0000 --Apple-Mail-D39A2768-A2D3-4A56-B949-0455BEA817F3 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Sorry, I thought it was a continuation of a private thread that may also ben= efit from transparency and additional input. Thank you, Kathleen=20 Sent from my mobile device > On Jan 18, 2019, at 12:12 PM, Richard Barnes wrote: >=20 > Not sure what you mean, Kathleen. This is a public mailing list :) >=20 >> On Fri, Jan 18, 2019 at 12:06 PM Kathleen Moriarty wrote: >> Can that be a public thread? It really should be. >>=20 >> Sent from my mobile device >>=20 >> > On Jan 18, 2019, at 11:54 AM, Richard Barnes wrote: >> >=20 >> > Let me provide some additional context. When the chairs and ADs discus= sed this in BKK, it seemed pretty clear that EDHOC is not within the current= charter of ACE =E2=80=94 after all, ACE is targeted at authentication and a= uthorization, not key exchange. Since ACE would need to recharter to accept= this work in any case, and because EDHOC overlapped with the interests of o= ther working groups, it seemed to make sense to have the conversation in a b= roader venue. >> >=20 >> > G=C3=B6ran: Your email starting this thread seems like an abbreviated s= ummary of the past discussion of this draft. Since this is a new audience, i= t would be helpful if you could start from the underlying requirements (=E2=80= =9Cwe need an AKE with certain constraints=E2=80=9D) and lay out why new pro= tocol work is needed, vs. profiling existing protocols (as has been done, e.= g., in DICE). >> >=20 >> > If it would be helpful to keep this moving, we could certainly arrange a= virtual interim on this topic. >> >=20 >> > =E2=80=94Richard >> >=20 >> >=20 >> >> On Jan 4, 2019, at 1:17 AM, G=C3=B6ran Selander wrote: >> >>=20 >> >> Hi Kathleen, >> >>=20 >> >> Good question. Thanks for bringing continuity to this almost 2 years l= ong offline discussion. Indeed, lack of comparison with other protocols and f= ormal verification were at the time the arguments for not following up the i= n-room consensus with an email confirmation. And, as you noted, that is not t= he case anymore. >> >>=20 >> >> Meanwhile the ACE chairs and AD have changed. My understanding is that= the argument now is about attracting more people with a certain security co= mpetence for which perhaps another WG could potentially be better, hence the= request to Secdispatch. But I'll pass the question on and include the ACE W= G for transparency. >> >>=20 >> >> =46rom the authors' humble point of view we believe that the main miss= ing thing that would enable the required further discussion is that the IETF= endorses this work, no matter how, so that people dare invest more time in i= mplementation and analysis.=20 >> >>=20 >> >> Best regards, >> >> G=C3=B6ran >> >>=20 >> >>=20 >> >> =EF=BB=BFOn 2019-01-03, 00:58, "Kathleen Moriarty" wrote: >> >>=20 >> >> Hi, >> >>=20 >> >> I=E2=80=99ve read earlier versions of this draft and appreciate all t= he work you have done with the security proof and comparing to existing stan= dardized protocols. If ACE is interested, why is this going to SECDispatch?= It might help to understand that better. Is it that a recharter would be n= eeded? >> >>=20 >> >> Thank you & happy new year! >> >> Kathleen=20 >> >>=20 >> >> Sent from my mobile device >> >>=20 >> >>> On Jan 2, 2019, at 5:56 PM, G=C3=B6ran Selander wrote: >> >>>=20 >> >>> Dear Secdispatch, >> >>>=20 >> >>> We have been advised to ask secdispatch to consider EDHOC: https://to= ols.ietf.org/html/draft-selander-ace-cose-ecdhe >> >>>=20 >> >>> Those that follow the ACE WG should be familiar with this draft. The p= roblem statement and motivation for EDHOC is described in section 1. In brie= f, the target is a lightweight key exchange protocol suitable for IoT applic= ations, which: >> >>> a) has small message size and reuses existing IoT primitives to enabl= e low overhead and small code footprint;=20 >> >>> b) is not bound to a particular transport, to enable end-to-end secur= ity in IoT deployments with varying underlying layers; and >> >>> c) can be used to key OSCORE (draft-ietf-core-object-security) that i= s lacking a harmonizing key exchange protocol. >> >>>=20 >> >>> These requirements are motivated by constrained IoT device deployment= s, but the protocol is applicable to other end-to-end security settings wher= e the overhead due to security needs to be low. EDHOC addresses these requir= ements and builds on the SIGMA construction for Diffie-Hellman key exchanges= . EDHOC, like OSCORE, is built on CBOR (RFC 7049) and COSE (RFC 8152) and th= e protocol messages may be transported with CoAP (RFC 7252). =20 >> >>>=20 >> >>> There has been a number of reviews of different versions of the draft= ; both by people who want to deploy it and by people analysing the security.= A formal verification was presented at SSR 2018. There are a few implementa= tions of different versions of the draft. The ACE WG has expressed interest i= n this work in several f2f meetings. >> >>>=20 >> >>> Please let us know if some information is missing for secdispatch to c= onsider this draft, or how we can help out in the process. >> >>>=20 >> >>> Best regards >> >>> G=C3=B6ran, John, Francesca >> >>>=20 >> >>>=20 >> >>> _______________________________________________ >> >>> Secdispatch mailing list >> >>> Secdispatch@ietf.org >> >>> https://www.ietf.org/mailman/listinfo/secdispatch >> >>=20 >> >>=20 >> >=20 --Apple-Mail-D39A2768-A2D3-4A56-B949-0455BEA817F3 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Sorry, I thought it was a continuation of a= private thread that may also benefit from transparency and additional input= .

Thank you,
Kathleen 

Sent from my mobile device

On Jan 18, 2019,= at 12:12 PM, Richard Barnes <rlb@ipv.sx> wrote:

No= t sure what you mean, Kathleen.  This is a public mailing list :)

On = Fri, Jan 18, 2019 at 12:06 PM Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:<= br>
Can that be a publ= ic thread?  It really should be.

Sent from my mobile device

> On Jan 18, 2019, at 11:54 AM, Richard Barnes <rlb@ipv.sx> wrote:
>
> Let me provide some additional context.  When the chairs and ADs d= iscussed this in BKK, it seemed pretty clear that EDHOC is not within the cu= rrent charter of ACE =E2=80=94 after all, ACE is targeted at authentication a= nd authorization, not key exchange.  Since ACE would need to recharter t= o accept this work in any case, and because EDHOC overlapped with the intere= sts of other working groups, it seemed to make sense to have the conversatio= n in a broader venue.
>
> G=C3=B6ran: Your email starting this thread seems like an abbreviated s= ummary of the past discussion of this draft.  Since this is a new audie= nce, it would be helpful if you could start from the underlying requirements= (=E2=80=9Cwe need an AKE with certain constraints=E2=80=9D) and lay out why= new protocol work is needed, vs. profiling existing protocols (as has been d= one, e.g., in DICE).
>
> If it would be helpful to keep this moving, we could certainly arrange a= virtual interim on this topic.
>
> =E2=80=94Richard
>
>
>> On Jan 4, 2019, at 1:17 AM, G=C3=B6ran Selander <goran.selander@ericsson.co= m> wrote:
>>
>> Hi Kathleen,
>>
>> Good question. Thanks for bringing continuity to this almost 2 year= s long offline discussion. Indeed, lack of comparison with other protocols a= nd formal verification were at the time the arguments for not following up t= he in-room consensus with an email confirmation. And, as you noted, that is n= ot the case anymore.
>>
>> Meanwhile the ACE chairs and AD have changed. My understanding is t= hat the argument now is about attracting more people with a certain security= competence for which perhaps another WG could potentially be better, hence t= he request to Secdispatch. But I'll pass the question on and include the ACE= WG for transparency.
>>
>> =46rom the authors' humble point of view we believe that the main m= issing thing that would enable the required further discussion is that the I= ETF endorses this work, no matter how, so that people dare invest more time i= n implementation and analysis.
>>
>> Best regards,
>> G=C3=B6ran
>>
>>
>> =EF=BB=BFOn 2019-01-03, 00:58, "Kathleen Moriarty" <kathleen.moriarty.= ietf@gmail.com> wrote:
>>
>>   Hi,
>>
>>   I=E2=80=99ve read earlier versions of this draft and ap= preciate all the work you have done with the security proof and comparing to= existing standardized protocols.  If ACE is interested, why is this go= ing to SECDispatch? It might help to understand that better.  Is it tha= t a recharter would be needed?
>>
>>   Thank you & happy new year!
>>   Kathleen
>>
>>   Sent from my mobile device
>>
>>> On Jan 2, 2019, at 5:56 PM, G=C3=B6ran Selander <goran.selander@ericsso= n.com> wrote:
>>>
>>> Dear Secdispatch,
>>>
>>> We have been advised to ask secdispatch to consider EDHOC: https://tools.ietf.org/html/draft-selander-ace-co= se-ecdhe
>>>
>>> Those that follow the ACE WG should be familiar with this draft= . The problem statement and motivation for EDHOC is described in section 1. I= n brief, the target is a lightweight key exchange protocol suitable for IoT a= pplications, which:
>>> a) has small message size and reuses existing IoT primitives to= enable low overhead and small code footprint;
>>> b) is not bound to a particular transport, to enable end-to-end= security in IoT deployments with varying underlying layers; and
>>> c) can be used to key OSCORE (draft-ietf-core-object-security) t= hat is lacking a harmonizing key exchange protocol.
>>>
>>> These requirements are motivated by constrained IoT device depl= oyments, but the protocol is applicable to other end-to-end security setting= s where the overhead due to security needs to be low. EDHOC addresses these r= equirements and builds on the SIGMA construction for Diffie-Hellman key exch= anges. EDHOC, like OSCORE, is built on CBOR (RFC 7049) and COSE (RFC 8152) a= nd the protocol messages may be transported with CoAP (RFC 7252). 
= >>>
>>> There has been a number of reviews of different versions of the= draft; both by people who want to deploy it and by people analysing the sec= urity. A formal verification was presented at SSR 2018. There are a few impl= ementations of different versions of the draft. The ACE WG has expressed int= erest in this work in several f2f meetings.
>>>
>>> Please let us know if some information is missing for secdispat= ch to consider this draft, or how we can help out in the process.
>>>
>>> Best regards
>>> G=C3=B6ran, John, Francesca
>>>
>>>
>>> _______________________________________________
>>> Secdispatch mailing list
>>> Secdi= spatch@ietf.org
>>> https://www.ietf.org/mailman/listinfo/se= cdispatch
>>
>>
>
= --Apple-Mail-D39A2768-A2D3-4A56-B949-0455BEA817F3-- From nobody Fri Jan 18 09:27:30 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A206A131250; Fri, 18 Jan 2019 09:27:27 -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=mit.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 aKxvv009qbPP; Fri, 18 Jan 2019 09:27:23 -0800 (PST) Received: from NAM04-BN3-obe.outbound.protection.outlook.com (mail-eopbgr680127.outbound.protection.outlook.com [40.107.68.127]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DC171312A1; Fri, 18 Jan 2019 09:27:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=YxZaBgy1cBfsEXP6EUvsIVLJOMxBvm1FjAKA/XmdGdg=; b=fTqpdQ5MVHbjQfy8cq/VswYzxq5JBIqF8rGSB2CRTi/72tQfedK+lBGrTUoipGSkbp1O4lYuH7CvyDlC80A94XVB5LLgk+UBbTBVag41ITNKRbYRS4vLjWh0rwE+ZYNItOU7/L6On3C4oubJFLIcdvxYcUb2uR/cacd88Kmp0Vw= Received: from MWHPR01CA0045.prod.exchangelabs.com (2603:10b6:300:101::31) by BL0PR01MB4804.prod.exchangelabs.com (2603:10b6:208:7c::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1537.24; Fri, 18 Jan 2019 17:27:19 +0000 Received: from BY2NAM03FT053.eop-NAM03.prod.protection.outlook.com (2a01:111:f400:7e4a::209) by MWHPR01CA0045.outlook.office365.com (2603:10b6:300:101::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1537.26 via Frontend Transport; Fri, 18 Jan 2019 17:27:19 +0000 Authentication-Results: spf=pass (sender IP is 18.9.28.11) smtp.mailfrom=mit.edu; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=mit.edu; Received-SPF: Pass (protection.outlook.com: domain of mit.edu designates 18.9.28.11 as permitted sender) receiver=protection.outlook.com; client-ip=18.9.28.11; helo=outgoing.mit.edu; Received: from outgoing.mit.edu (18.9.28.11) by BY2NAM03FT053.mail.protection.outlook.com (10.152.84.186) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1471.13 via Frontend Transport; Fri, 18 Jan 2019 17:27:18 +0000 Received: from kduck.mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x0IHREpB022782 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 18 Jan 2019 12:27:16 -0500 Date: Fri, 18 Jan 2019 11:27:14 -0600 From: Benjamin Kaduk To: Richard Barnes CC: =?iso-8859-1?Q?G=F6ran?= Selander , "secdispatch@ietf.org" , Kathleen Moriarty , John Mattsson , Francesca Palombini , "ace@ietf.org" Message-ID: <20190118172714.GJ81907@kduck.mit.edu> References: <79FD6563-8ADA-4D73-B8D5-C3D70604CD76@gmail.com> <47F03C99-68C1-4ADB-873D-F01987D66849@ipv.sx> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <47F03C99-68C1-4ADB-873D-F01987D66849@ipv.sx> User-Agent: Mutt/1.10.1 (2018-07-13) X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:18.9.28.11; IPV:CAL; SCL:-1; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(346002)(39860400002)(136003)(376002)(396003)(2980300002)(189003)(199004)(104016004)(11346002)(2486003)(956004)(76176011)(229853002)(426003)(4326008)(1076003)(446003)(966005)(478600001)(476003)(66574012)(6916009)(36906005)(7696005)(54906003)(8936002)(23676004)(8676002)(316002)(5660300001)(305945005)(106002)(786003)(486006)(26826003)(58126008)(246002)(93886005)(126002)(14444005)(33656002)(356004)(75432002)(86362001)(106466001)(47776003)(186003)(26005)(6306002)(336012)(6246003)(39060400002)(50466002)(88552002)(2906002)(2870700001)(55016002)(53416004)(18370500001); DIR:OUT; SFP:1102; SCL:1; SRVR:BL0PR01MB4804; H:outgoing.mit.edu; FPR:; SPF:Pass; LANG:en; PTR:outgoing-auth-1.mit.edu; MX:1; A:1; X-Microsoft-Exchange-Diagnostics: 1; BY2NAM03FT053; 1:Mkce/fAipa6qrx50A9JxlGeRNBJzXUYEfouhOm9rDufftZ0T55VIVk9HrgZxqOBUDxnij3iipllIJK+uuE0U3nqTYU0QUZ+c4abAMmZcnf5yyr3RyMY6Bggk8e/CM1Ux X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: f6f14c4b-e062-47f6-f042-08d67d6a3298 X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600109)(711020)(4608076)(4709027)(2017052603328)(7153060); SRVR:BL0PR01MB4804; X-Microsoft-Exchange-Diagnostics: 1; BL0PR01MB4804; 3:evWMfACv0v7TFlUpxZ9td0nDdkapJQrPksMhDMqSjdc4t804dqXKOda2Zls0qNxqJxjqctzA9n7P6jF5EpwliC+NKeixCsAuBWyCM9Z45jjf1pdMN4IPUN2Y3NR8GXlukh8KqYw5HMsOkwMGNqjloiXLONwjclq+lA1RGlel/cj1KmqiOxvMBODpn+33gZNDm1z08FwQD4jyyrYNY7mekRPKTSW4fDF9qMUzh76hYWBoT2BInk39u6hpard6jkBUByevQTm1mzfSLqD8beMIRXSh8z0sjW8d6y+Kme97inuUf3LywkH5KqSqy2tRQRxZlKeDNEDyxYrP8v/W2QldQv5ZvTywCj6ohUy9/DS9xhOAQVufdrToR8VK/UXFEjbP; 25:h7J4dUNk4GZrAQqsc6FQXPIJcFuDZ6mXZNYEesEnO19itPQRV9R0lO/8NbTUqFQWwC+UyzLPGqyhopNi4XAcpjROL0dDWNuWSY7SkKlsF8iUlFBJhW0P/tc2bPbzrbzUDEypWOYtGzb9PD2sApZ16iaRPZoi+mADbMuoEaeepDYuQiZ7JKYkXNM95civNZeWJHE8gt/hAY9qxXWcV4ailzkQobK2YzjYOJJyGkX0sF56vVJa/26k+ZQ2JZ75z0VxtQlWT/DKDtobZhtoXEQgp3GJD3ankXL+pnQEqINuy3cXyolh/w8f2DL1pKjNx2jqvT//rWqkFDLFmOr5igHYXA== X-MS-TrafficTypeDiagnostic: BL0PR01MB4804: X-Microsoft-Exchange-Diagnostics: 1; BL0PR01MB4804; 31:CgBSD1jBfsz22k4XnmPmEjdgZPJKuDBH2Eg87qZbb/OmPXDBnF2SfuLFaz5GkZAciYAkxTCqiAoCsi8mLT28H/5YUVzynRwboinNEIO7CZ1KkDW7vzeB6W86pxIClVh1k8mXBwRVn1rFwS/WhYyCbp5rWKEqNAEfAb8zdLvCFxkpuWuR8jtsu4XEX1UGvRSTbSVDDUHe8i/6c3mB/HjTVdUoCqwsT5cFDUefwaGZBxs=; 20:HqkpouJWpJI0fJB2fa2t53QIORl2oVg7NO0M4ALyQmn7rUO7l4+j/SZ0KoCrDeCnp5YVivoEp5wQacDN+vRTqEiIHB1j4wLR0l+OVS5tTH17HCA2kXbQZpZAc1/K99mNizU+giyU3PGxe0/Mg3xiuDq4PE0JLaGkwP2wKrS5oF1yNAk6R79gOGwNgd/nTz6G25LUg4UCuWJtDoWgnGc/vxFHc3UEpZ72HpjKOQwJ67/C/ZmuzxmsvYjwKmWVk3jF+5JVgxrrR4oUhC26jveoWnx6surszmQWtLeE9Qhdh3fYtpQHrS4HIWUMa8TEdTk7L34gkE8aE1nyCnX729vuE0u+fOcKEtYHb04AC3uGa1oEsA/MXV41z3Oh6TV/RjuD+2fmydn8fJ/MH/fwI62iTt+NVjhjzZHl8JMhDNOebY6NvSugwod4qgXoBnlzPCrf4HSu+Kn7wmf0h7YY93ARonECQLD3nEXxIsVWElo8bfYH8mh50kSzpst7kj1AeJtQaysrtP1XQDY5+oQ6aK1NIdV829blKkv0NRAC7AOLBH9Ok4KiaaajK0nmg1mf3PipSDf5+l89A0DfqwWaQn8TvQL93pUyQriuBnaqug9X6JI= X-Microsoft-Antispam-PRVS: X-Microsoft-Exchange-Diagnostics: 1; BL0PR01MB4804; 4:+9U5ri9M1Upo1pTaNIpCjiSz5MbiuFPzLhd2gcfTV+SKJzGeRRtQqG33oAnnf2BySvpro3CTfMfaDU1WiuUGjgQZqaFeikQ4kkVwyFVcf431a0RJKom0cFicv4qr7pQHZlk3KU53rJUtsO4wFEjdEVqz6S1eFfg9BjsBZibxpMwWNa/rclVRVf5RnheDSdnTI1DRgmwjy0lRmk2gnyeQPEgs8X12+AtWwEzcqff96FF65NjQI4aX33iTUjKBxMFhsDRryTymoUPdG2WRtmQeaGHqJeqDnuRBltxP9GGJaeqhuBOZ8UOYQIeMw5uyjFq2 X-Forefront-PRVS: 0921D55E4F X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtCTDBQUjAxTUI0ODA0OzIzOnVlb1dyYUNQL3dhcTB5c0NzSEt0ek5lbnJK?= =?utf-8?B?ekZneTBZK0tMT3hodHR0RFhtdUlYN2w2Y090T3VSQVpJdWxOMFhjVEVCMWVP?= =?utf-8?B?VHVlcUt5bWdBNjdOSUpqSjErMFFqSFV3SndNdlhoWm1RM1N2RVU3NWlvSGFW?= =?utf-8?B?U0ZYMUVrNzZaKzduZ1BwWnh1cjAxV3FjS1I0dEI1Q3VOb0hPOFpSUU9Sd3Rp?= =?utf-8?B?YnBvblNrdm5CT3g1T2pJcXBvWEV2dEZoWWxiYkVXaU9KSHI3emV1dUd5dTM5?= =?utf-8?B?QzNGd1NiNXdINVJpdGYrVzRlYTZhMDFNVGFNL0tBMWxSL2RiaVlERGY4a3dZ?= =?utf-8?B?S3NlWnI2VUZoZWhmM3c5dUpWMGN6WUN2T0xqQUZVRm1lSEhFZnM2WStydVp4?= =?utf-8?B?dXBHaHkvRnlzTnhLb2p5SXNKTzIwM2FrVCtZT3dvU2JaYzdNMFZXTWM2WDNm?= =?utf-8?B?SnRncEJDZ2JSaElsT0xhOTlOUFIrRmljTENna2YyS2pxbzBGZ1hPZmp3YWQr?= =?utf-8?B?LzF3RDI4SUlYT3E5NnBoT1JraUhiRDNjekVMamVkbVJSOFFORC8wUzJ3NW9n?= =?utf-8?B?M3pCUFZnNVI3M3NkRzRxdXQwZEJkNmg5N2JuOWMyY2RCYjM3SUJFNmRGOHh1?= =?utf-8?B?cFlzRkx6R2VKVUhkSUR4VU0yK2lTU25BNXAyTlNFV2NJMWlNa0VJQzNibGJN?= =?utf-8?B?RnBMcXlOZ2FpQ3BkTEh5azQ5a0V6V21HNWxLSkFaejNiVjNYTkFJVi9zOTNE?= =?utf-8?B?M2MxOXZmWnJ6QkhibHVXRGg1a3pHVkNUbXZScTdJb0l3bkVrZVZ3dVEzZlNU?= =?utf-8?B?U2wycURwc3BtTE0rUll5UldPRVM0TkY5clV6MDZWa0JISWdiUzJmTFpLa0tL?= =?utf-8?B?VWU2Nm5KMjJVS05CNy90Z2NLMHRSZkVVZWdwWm5wci9KamM1Wno4NnZXM3Ja?= =?utf-8?B?NHlWNnRsd1cySVY4VkJDRi9MOFJSUXFCaVpQMDZYV21WcFpRYm5uUUgvdytC?= =?utf-8?B?MGdNUFZLT1lKWTdEWmJJRSs3a0llZHMxK3E3SkNLMjNoWEIvK2ZGbjZHdUYv?= =?utf-8?B?d0VrWnYzak1NTE16cHZNbHd1K3lNRlNWK3FqQ3R1YndSVnRXd2ExUFg4eXJa?= =?utf-8?B?M1dJbE0xemdVK1YrMExyYUp4SkFaNHhPZ1haWFJpOGZha3cxaU1Hb1NsM0FV?= =?utf-8?B?ZHdmaUtKNWFwaHF6KzB5Z2Q5WGNONldlYUU1OVpvRWtqSEpWdXh1YzM2QVdG?= =?utf-8?B?WXNOcjQvMG9HT0Z3ekVJZzQyNlJqcU8vWDFmVStwRThPNFZsd2hVcHRHTzVn?= =?utf-8?B?blQvQ214d3VEcjJEd1Mzb3oxREIwYWVTVnVrVE9qTlY1by9HdTVVQWlRYnU5?= =?utf-8?B?aUk4SU55WStSRHAyMklNZUcxOGdvajlFRGVXaDZMOWFsejVxVWpDREVJU2E4?= =?utf-8?B?L1p6Z3JROStTTm5aUkMvU3RldzF4RExSYXBDeGZQNnpzZFA2cFlHc2MrVUd4?= =?utf-8?B?RjQ0dkdDcVllZksvUDV5VVFEZTJDQllnSUVMOThKRmxEWU9udkk0bjk2VGxy?= =?utf-8?B?aUs3ZWRlYUVkK1lOM1g4L1Y3NERBMU5EM0Y2amFybzgxdllJYTFNMlFOc1RY?= =?utf-8?B?VVBzSzlCTTlDalQ1VmNEdGhZa1NOOXVWcHpBVStPVUFMcnJxS3ZpZkhnWk1h?= =?utf-8?B?YWpEMkNHSUlNbWdDajU4YjNJelJodi9vazRFRVZvaFBheExXN0Z6dWV1d1RP?= =?utf-8?Q?quZ4r8r3+6cV6oQXq1qyqBc/x2WCJnHvbbVsA=3D?= X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Message-Info: +xTwEDD5ZyorEVaUqVtPdJ0gMY7nlLLkHYKwGDc3HBAylW6J9aBn9gT6sEpc9Flkyjdi4I7oUyzSjDOZt31poORDaBQEZoCa2z27dTCFYN6yvNNlHGz0QaxDS0txxuyff0Zr3xUpIb3wwCOnLqX2LZteIBZIiklxtyDrGfU82dH/Y+dJkdQOO2gPPlYW7GUiMU5BCIVjqI+13l6fb5EnkxsvNJ8OLevpb6x9eeMGsRLYnghxrOLF1HBPbcL8peRRmPqAHeyxZ3ED05jJloFDQgz3T5npPqiw6aqtvwnvOz1OuIEgnGhsBHwM3V827Qg0BNpC+m0TkFX0mY60RhmGWt1dUeRtBB4Ek1Mun9kbuJWtQBZo3CbrsdP6N0jsrxsFyLS329iueFEDuX6wguH9nYScTQvH18B2COnCquGO7l4= X-Microsoft-Exchange-Diagnostics: 1; BL0PR01MB4804; 6:3WyA6ntPUpg+hNUevK3KyZLNYin71JRmXMnIue6pczjxQg05f8sdsj5XvCPZA+8AUqXJJ7IIMhLPO6/fM1XFar1gkFG3EgLFEwFrB7smUr8uCmwWMDQGIJz3kV3NQwhhpapFZMySTZrLvHO90IdpB9/UJH99rH9QkN70x01Img1QlalYqR3TW09byRxl54GEN/iyRfRnHeQt5+QGZRqSnSTP7sZIchquyZofsCk1PZkYzZUoDqw9n/ZNrDVYKVkpffApY2kkn1IEeJTHxjyxqmR7ZDzmS7rBtwD5kyTqvUvTNo7iW3lTbi5BCXYKBxcobM7FvKF/ImgvcSL1S/IaykDlTQNUNprDDLFa3MuuUPyPIv74DaMAy0yBFiOBDA83co5zZmcIGRAOXSUoUU+Tk9gyRa0KgmOFCfdr7tXwmd8FRry8NsfMRpraIomY3Mnz2HdgCTFkikAqNddQen85kw==; 5:NP7XtjkpXfvBpP0PTHos6waB1V+E/xPt0kUmzYoReaB8w/gKielNTQH84OpF/uFwc1vEhGk3cuUSSOqmCxAoRJSmVk8UBByDr3tpwnnPlo4NL9Ujn40rcJpB9JWQfrMzaLCCX2a9NcC/rEEACvaRvB0g2btSc/chrzVmaHdruRgN6aZ7S+gLFdHuytSVSX2zeDG84siC3njvhTye2exYqA==; 7:/0P9tOajLArRzrjPo53rqu7WV8TjS5E6wKeXeXdljff1lx6g7teQ4gVrJhtP4YrZ6WenlNmNZhbuGMwPDlU+jb3FGr94iEnhjEQ9aKgCK8TZnKuLE2lhrKffqUlxl1Aj7Ee/NY1m7PsxpReO+0vcFA== SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Jan 2019 17:27:18.4486 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: f6f14c4b-e062-47f6-f042-08d67d6a3298 X-MS-Exchange-CrossTenant-Id: 64afd9ba-0ecf-4acf-bc36-935f6235ba8b X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=64afd9ba-0ecf-4acf-bc36-935f6235ba8b; Ip=[18.9.28.11]; Helo=[outgoing.mit.edu] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR01MB4804 Archived-At: Subject: Re: [Ace] [Secdispatch] EDHOC 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, 18 Jan 2019 17:27:29 -0000 On Fri, Jan 18, 2019 at 11:54:58AM -0500, Richard Barnes wrote: > Let me provide some additional context. When the chairs and ADs discussed this in BKK, it seemed pretty clear that EDHOC is not within the current charter of ACE — after all, ACE is targeted at authentication and authorization, not key exchange. Since ACE would need to recharter to accept this work in any case, and because EDHOC overlapped with the interests of other working groups, it seemed to make sense to have the conversation in a broader venue. ACE's charter is ... messy. More below. > Göran: Your email starting this thread seems like an abbreviated summary of the past discussion of this draft. Since this is a new audience, it would be helpful if you could start from the underlying requirements (“we need an AKE with certain constraints”) and lay out why new protocol work is needed, vs. profiling existing protocols (as has been done, e.g., in DICE). There seem to be several interleaved issues at play, here, and I agree that some clear/consolidated background would be helpful. I particularly call out the security proof that has been presented elsewhere, which I think would be interesting to several readers (but I don't have the link handy). Some thoughts of my own... There is clear demand for a lightweight key-exchange protocol for use in IoT protocols, especially OSCORE. EDHOC has been around for a while, and even discussed in ACE with some frequency. That said, there are several reasons to prefer asking secdispatch to just calling for adoption in ACE directly, including but not limited to: (a) designing secure authenticated key exchange protocols is hard! It takes a lot of energy from smart people to design and analyze a protocol to have confidence that it is secure and fulfils the advertised functions. Starting from well-known/well-analyzed foundations like SIGMA is a great start, but hardly a guarantee of success. Secdispatch gets us some better visibility, and insight into where work can be done that will have sufficient expertise (both within and outside the IETF, as well as what has been done already vs. what remains to be done) to be confident in the result. (b) ACE has a pretty complicated charter, that seems to place restrictions on how it can adopt new protocol work without rechartering. We find things in the charter like "existing authentication and authorization protocols will be evaluated and used where applicable [...]. Some functionality, however, may not be available in existing protocols, in which case the solution may involve new protocol work." This would seem to require a clear criteria for how to determine whether or not existing technology is applicable, plus evidence that existing protocols do not meet the bar. In particular, "make the key exchange messages as small as possible" is not a clear criterion, as that would always argue for a new protocol over an existing one, as we come up with new ways to eke out space. (c) A clear and substantial difference between key exchange/handshake size between EDHOC and even minimized DLTS could be compelling enough for secdispatch to decide that the work is usable, and find an appropriate home, independently of the question of rechartering ACE and meeting the additional barrier described in the previous point. Jim and several others have done some good work looking into tabulating message overheads in various scenarios (e.g., https://www.diva-portal.org/smash/get/diva2:1156483/FULLTEXT01.pdf, https://jimsch.github.io/randomDrafts/draft-schaad-ace-tls-cbor-handshake.html) that will be helpful as we consider this topic. In addition to just comparing the byte count for handshake/key exhchange messages in various methods, it would probably also be good to think about things in terms of the constraints in the current ACE charter. That is, someone could (1) pick a (class of) device(s), (2) show that it has wide deployment/potential thereof, (3) give hard numbers about what it's (not) capable of, and (4) show that DTLS falls on the wrong side of that cutoff, using the handshake numbers we already have. In particular, I don't remember seeing anything touching on (3), previously. An analysis like this would not only give some context for interpreting the gap between EDHOC and DLTS, but could also be compelling in support of the need for the more lightweight solution. > If it would be helpful to keep this moving, we could certainly arrange a virtual > interim on this topic. That seems likely to be useful, though I suppose we should wait to see more indication that people would show up and have a productive discussion. -Ben From nobody Fri Jan 18 12:59:06 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 801C41313E2 for ; Fri, 18 Jan 2019 12:59:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.642 X-Spam-Level: X-Spam-Status: No, score=-14.642 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, 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 8LEn7JsM_1rX for ; Fri, 18 Jan 2019 12:59:03 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8474130FB4 for ; Fri, 18 Jan 2019 12:59:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8958; q=dns/txt; s=iport; t=1547845142; x=1549054742; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=F04E9qJ++okOJCdleN+rBy8xg54xI9pFQkQuq1frh9Y=; b=ZHtVfOERzLtZSAeusIpOm6LGBelosw3pA5TIjNRzh1TTUz6HxeesTi3L lf3txxlvN0xsZ2Fw+bNPiCBbxInNJyWNjrpFdnQQf9RRrcM5qRlkz8YjV fjQDAuANRh6JJJbzNBa4Hue1RefxxMg4w2K1ZPlSU0B6TVD9rVJbMm4T7 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAADEPUJc/40NJK1kGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUQQBAQEBAQsBgVUuZoECJwqMEYtogg2YAYF7CwEBGA2?= =?us-ascii?q?ERwKCXCI0CQ0BAwEBAgEBAm0cDIVKAQEBAQMBATg0FwQCAQgOAwQBAR8QJws?= =?us-ascii?q?dCAEBBAESCIMbggEPrTyBOYJ5AoVzBYl5gkgXgUA/gRGDEoMeAQECGIEgEYV?= =?us-ascii?q?2AolBGZhGCQKHIoNXhxgggWaFLoM4h0iKBIEIhBSLVgIRFIEnHziBVnAVO4J?= =?us-ascii?q?shgmFFIU/QTGHRwIkBAOBAYEfAQE?= X-IronPort-AV: E=Sophos;i="5.56,492,1539648000"; d="scan'208";a="507215202" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Jan 2019 20:59:01 +0000 Received: from XCH-RCD-010.cisco.com (xch-rcd-010.cisco.com [173.37.102.20]) by alln-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id x0IKx0VL032356 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 18 Jan 2019 20:59:01 GMT Received: from xch-aln-010.cisco.com (173.36.7.20) by XCH-RCD-010.cisco.com (173.37.102.20) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 18 Jan 2019 14:58:59 -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; Fri, 18 Jan 2019 14:58:59 -0600 From: "Panos Kampanakis (pkampana)" To: Jim Schaad , "ace@ietf.org" Thread-Topic: [Ace] FW: WGLC comments draft-ietf-ace-coap-est-07 Thread-Index: AdSrtk3M3NcfgQ45QNualt2l/rHBKAAh1EAwAMs/eJA= Date: Fri, 18 Jan 2019 20:58:59 +0000 Message-ID: <82341b1eb21f4eccb00741d78964f853@XCH-ALN-010.cisco.com> References: <011501d4ac3d$ab2b9650$0182c2f0$@augustcellars.com> In-Reply-To: <011501d4ac3d$ab2b9650$0182c2f0$@augustcellars.com> 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.245.247] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.37.102.20, xch-rcd-010.cisco.com X-Outbound-Node: alln-core-8.cisco.com Archived-At: Subject: Re: [Ace] FW: WGLC comments draft-ietf-ace-coap-est-07 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, 18 Jan 2019 20:59:06 -0000 Hi Jim, Again, thank you for your thorough reviews. We addressed all of them. The n= ew version of the draft is at https://github.com/SanKumar2015/EST-coaps/blo= b/master/draft-ietf-ace-coap-est.txt=20 For a more easily consumable content, your latest feedback was tracked and = addressed here https://github.com/SanKumar2015/EST-coaps/issues?utf8=3D%E2%= 9C%93&q=3Dis%3Aissue+draft-ietf-ace-coap-est-07=20 I also lay out the changes below:=20 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - We fixed all the nits.=20 - About the Arbitrary Label, we added=20 "Arbitrary Labels are usually defined and used by EST CAs in order to route= client requests to the appropriate certificate profile." - About guidance when discovery is necessary, we added=20 "Discovery SHOULD NOT be chosen when the client is preconfigured to use the= default /.well known/est server root resource and port 5684. If the defaul= t root resource requests fail, the client SHOULD fall back to doing a resou= rce discovery. Resource discovery SHOULD be employed when non-default URIs = (like /est or /est/ArbitraryLabel) or ports are supported by the server or = when the client is unaware of what EST-coaps resources are available by the= server." - About CBOR in section 5.7 we added=20 "The sever-side key generation response is returned with content format application/multipart-core [I-D.ietf-core-multipart-ct] containing a CBOR array with four items (Section 5.2.1). " - About tlsl-unique and TLS exporters, this was discussed before for TLS 1.= 3 (https://mailarchive.ietf.org/arch/msg/tls/-8rDHLR6hiR7wsLsf6nVLtqCCmU ) = but we can't really mandate using a TLS exporter for tls-unique as this is = not standardized anywhere. If there was an 5929-bis to update the tls-uniqu= e in order to address the risk and use an exporter then this draft would au= tomatically inherit it. Note that the implications of 3SHAKE were significant to TLS because the cl= ients were not checking the server cert after the renegotiation (Step 3 of = the paper). The implication to POP linking that EST-coaps uses though is mi= nimal because it does not expose anything private, it just deems channel bi= nding useless. To address the concern I added text in the Security Considerations " What's more, POP linking uses tls-unique as it is defined in [RFC5929]. T= he 3SHAKE attack [tripleshake] poses a risk by allowing a man-in-the-middle= to leverage session resumption and renegotiation to inject himself between= a client and server even when channel binding is in use. The attack was po= ssible because of certain (D)TLS implementation imperfections. In the conte= xt of this specification, an attacker could invalidate the purpose of the P= OP linking ChallengePassword in the client request by resuming an EST-coaps= connection. Even though the practical risk of such an attack to EST-coaps = is not devastating, we would rather use a more secure channel binding mecha= nism. Such a mechanism could include an updated tls-unique value generation= like the tls-unique-prf defined in [I-D.josefsson-sasl-tls-cb] by using a = TLS exporter [RFC5705] in TLS 1.2 or TLS 1.3's updated exporter (Section 7.= 5 of [RFC8446]). Such mechanism has not been standardized yet. Adopting in = this document a channel binding value generated from an exporter would brea= k backwards compatibility. Thus, in this specification we still depend in t= he tls-unique mechansim defined in [RFC5929], especially since the practica= llity of such an attack would not expose any messages exchanged with EST-co= aps." - About the persistent DTLS connections (Sect 7), the last two paragraphs o= f section 7 explain why in some cases DTLS connections need to stay open fo= r a limited amount of time. They also point to the Section 11.1 about the c= aveats of a persistent connection and the implicit DB. I do not think it is= up to this draft to tell the client that he should use the new cert after = an enrollment. The old cert might still be perfectly valid or the new cert = may be generated for a non DTLS client auth use. So, I don't think we need = to state in this draft that the new cert needs to be used in new DTLS conne= ctions. - About the DTLS connections (Sec 11.1), We have usecases where a client do= es not want to spend the resources, time, performance implications to do 3-= 5 DTLS connections back to back in order to update its trustanchor and do i= ts enrollments for multiple certs. In this cases, explained in section 7 la= st paragraphs will keep a persistent DTLS connection. That is what section = 11.1 is trying to explain. Please keep in mind that in there we state that = it is RECOMMENDED for the client to start using the new explicit DB right a= fter the cacerts request. We just add the MAY keep the authenticated with i= mplicit DB DTLS connection open in some cases, but then he MUST use the new= DB starting for the next DTLS connection.=20 So, I think our language in Sections 7 and 11.1 suffices when talking about= persistent TLS connections. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Let us know if there are more comments.=20 Rgs, Panos -----Original Message----- From: Ace On Behalf Of Jim Schaad Sent: Monday, January 14, 2019 2:17 PM To: ace@ietf.org Subject: [Ace] FW: WGLC comments draft-ietf-ace-coap-est-07 I forgot to include the working group on the to list. -----Original Message----- From: Jim Schaad =20 Sent: Sunday, January 13, 2019 9:51 PM To: 'draft-ietf-ace-coap-est@ietf.org' Subject: WGLC comments draft-ietf-ace-coap-est-07 Section 5.7 - Validate that CBOR array is the correct response type not multipart/cbor Section 6 - Based on earlier mails on the list I expected to see a short description of the purpose of "ArbitraryLabel". =20 Section 6 - The fact that there are multiple ways to get the things and the= y might not be in the same location. Some guidance for an application on how to decide which method should be used and the choice of an ArbitraryLabel t= o use would be very helpful. At present I would guess that I would send a request to the well known address, if that does not work then do a discover= y but it might be easier to just do the discovery to begin with and not worry about the well-known address. That is one would only do discovery if one was hitting up a resource directory and not the actual machine. On the other hand if things are rooted at /est rather than in well-known it would lead to shorter requests which once one starts doing block wise would be good. Section 7 - I would like to see some discussion of using a tls-exporter rather than tls-unique for this protocol. I am not sure what the required changes would be. I have seen notes that tls-unique is broken for TLS 1.2. Section 7 - I think it makes sense to say that after a successful enrollmen= t the (D)TLS link MUST be torn down and the new certificate used to do authentication in the future. Section 11.1 - When changing from the implicit trust anchor to explicit trust anchors, do you expect that the est server that you are going to be talking to is generally going to change? I think that it should probably b= e recommended that the DTLS connection NOT be persistent across a change in the trust anchors if they are different. Nits: Section 2 para 1: I would suggest that the last sentence should read along the lines of "EST is defined to transport messages over HTTPS." Section 3 para 2: The phrase 'taken over from' is a bit odd sounding English. They could be 'taken from' or 'imported from'. 'taken over' tend= s to indicate that you are changing them in some way. (example use - he took over the country). Section 5.5 - SAN needs to be expanded on first use. Section 6 - Please verify that quotes on the content type when multiple values are presented are not needed. Section 8 - This sentence "The EST server can exist outside the constrained network that supports TLS/HTTP." Does not say what I think you meant to say= . It is unclear if the constrained network is what supports TLS/HTTP. Section 10.1 - s/registered temporarily/registered provisionally/ s/looke/look/ Examples: * Section A.1 I don't know what the meaning of Max-Age would be for a GET request. You may want to remove this just to avoid confusion. * Section A.2 - I am unclear about the Content-Format note in this example. If you are asking for a specific content then the correct option would be Accept. If you are indicating the content type of the response then you should probably put a header line in to that effect. Jim _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace From nobody Mon Jan 21 10:35:10 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D96FB130DC8 for ; Mon, 21 Jan 2019 10:35:08 -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=mit.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 deao4XRNfu03 for ; Mon, 21 Jan 2019 10:35:06 -0800 (PST) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-eopbgr780120.outbound.protection.outlook.com [40.107.78.120]) (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 BB5F312894E for ; Mon, 21 Jan 2019 10:35:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=RBFXs8hOK1gpa6UmEdT9pN8+WDlx4dP8JWZgQUYxAhY=; b=fLsv0Rk2oTHFF0hUBTR0OemP+5aRfMH3N0EieYokR6wMxqUGl4zrZpYtAQKgIa6GQzQfjeASKEL1SuRoLNSfWFdBmFMu4gXd0wy4Xtv9XrTF9VEMf8ox/E78LjCf8J1R36rtr2vitIUM4zGTTrSoDezKqMTeITvr+QHnPQFshs8= Received: from CY4PR01CA0016.prod.exchangelabs.com (2603:10b6:903:1f::26) by BYAPR01MB4981.prod.exchangelabs.com (2603:10b6:a03:79::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1537.27; Mon, 21 Jan 2019 18:35:04 +0000 Received: from BY2NAM03FT020.eop-NAM03.prod.protection.outlook.com (2a01:111:f400:7e4a::201) by CY4PR01CA0016.outlook.office365.com (2603:10b6:903:1f::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1537.26 via Frontend Transport; Mon, 21 Jan 2019 18:35:04 +0000 Received-SPF: Pass (protection.outlook.com: domain of mit.edu designates 18.9.28.11 as permitted sender) receiver=protection.outlook.com; client-ip=18.9.28.11; helo=outgoing.mit.edu; Received: from outgoing.mit.edu (18.9.28.11) by BY2NAM03FT020.mail.protection.outlook.com (10.152.84.224) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1558.11 via Frontend Transport; Mon, 21 Jan 2019 18:35:02 +0000 Received: from kduck.mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x0LIYwfq030569 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 21 Jan 2019 13:35:00 -0500 Date: Mon, 21 Jan 2019 12:34:58 -0600 From: Benjamin Kaduk To: Jim Schaad CC: "'Panos Kampanakis (pkampana)'" , Message-ID: <20190121183458.GH81907@kduck.mit.edu> References: <359EC4B99E040048A7131E0F4E113AFC0184C52E29@marathon> <000501d48db9$1c268660$54739320$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <000501d48db9$1c268660$54739320$@augustcellars.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:18.9.28.11; IPV:CAL; SCL:-1; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(376002)(39860400002)(396003)(346002)(136003)(2980300002)(199004)(189003)(336012)(7696005)(6346003)(26005)(478600001)(26826003)(186003)(76176011)(23726003)(126002)(97756001)(33656002)(229853002)(86362001)(956004)(75432002)(476003)(104016004)(106466001)(2906002)(6916009)(88552002)(426003)(446003)(4326008)(47776003)(11346002)(53416004)(58126008)(93886005)(486006)(4744005)(1076003)(6246003)(246002)(8936002)(46406003)(316002)(50466002)(786003)(54906003)(16586007)(55016002)(305945005)(106002)(8676002)(356004)(18370500001); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR01MB4981; H:outgoing.mit.edu; FPR:; SPF:Pass; LANG:en; PTR:outgoing-auth-1.mit.edu; A:1; MX:1; X-Microsoft-Exchange-Diagnostics: 1; BY2NAM03FT020; 1:kVsE5wlfk8A1x+mX1A+sOGKqybiRqIejTgKLZreUflrK0iAhkOgxuLx8PH2cdu7kYU4rqiV+ZxNhbbGJKgw59UoocBR/h6plc8bxsWsgHOzGjyJvj6KS9qAjnwgV4Ew7LCriRUB4UklPkr64MKxm0Ejz4rFT6H7Rx0TqcD+vISk= X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 4b0d1cbc-0feb-44b9-7403-08d67fcf28dd X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600109)(711020)(4608076)(4709027)(2017052603328)(7153060); SRVR:BYAPR01MB4981; X-Microsoft-Exchange-Diagnostics: 1; BYAPR01MB4981; 3:ntqYdVbMy9WL8vAY6F3oZGGKg7YleLEVNBb3D4yvw0a+KMRySbCJRFlGFfiNxihHE06PXUtXQz7QhoLTcySBkQMNZ3i7b5l6lj4ClhYaADDq9yCmzT1GwzxTlNVbEF5Od8NRsGzJK1IZK5H+lOBCpeW2QJ2kTleclAuNsHWIkt0OaJZnQRHJtPREmSyoa5ORtbuCSnczOxUl80WZw8o0lw7mO/PLMZnSxqhihEZGOPLMxLKRPQLDYPagfCy0aHj2BrbmdbR9J+lasWerM3O16hIti7ZryuiNBVHK2fhOqYpufWSrr8h03h563AGMkTH3trTyf7NDcFcwSiNjCOOyN9q24hBoYdLdSKgIBKOKyD1F+eMoe+FCqi7x8/Q4oKSC; 25:dcFnS6ydY6rS8YhSB2fIQTrWrQqFo+1QszmiOeWGTGPsvoVWxMWcVwj1Qux68+auOx1XrfxhIUryKO7MGiOmWDEaY6ZT07TFQ3mj4yN/WoFHzIS6u8RasU899WPHkzv1hbZV+h/j8WRG7vm+EghcwQVz5qX23SS76I7QS0dsjUeFo6D+wzfMZqBdmhO93w28/Z+CLoYRwgpaxD0uzNzq16IHIBGufPQy9j1r6syf+izEi6prWBCKj6qzm+gAV0HRx4l14w6UZDOL7lFN0JAnNrW+G1FDgXev5wEnE4HfSiyjQMruZQLymRzFMlCgiEtqvAolJykc40gTU5r8Wpq6Bw== X-MS-TrafficTypeDiagnostic: BYAPR01MB4981: X-Microsoft-Exchange-Diagnostics: 1; BYAPR01MB4981; 31:KmaPElOF7MrGxfD4dDLHTK6W0xB4g31u3ZwLcrXhTKBgkKQxfna4H52PlNEcquGjrHBkvtrrBcx4UJMt8bdoMS7TOIkDXLGYC3h8OY7URL5pzSraZM30FOHOruMcurs8RauE+MYlcq+feZfUtrswXvnQ+4aIQO+6gCUV5ufGnMv0PhxDd+PG4bgYkQyzNXzmypNC7MUKFfddwP1lxRq6oVXpbsw2Z5sY4StcjQK4pX4=; 20:w0K9cNYaszY9Uhcnb3XrJldlp+iiQUpByYExo2ng723YAK4DKBp1OpYbj5imd7nVfQfb/s4Lw0iR6rAxCRs2xXUw8/ATQDN30nnP72BdO7RXQ3pxazyRyJ4TSPVpbCav3EQOZqzDH/2MUZ3TomaRbC79L1pHNTtLcveA9FEKx51h+ZcrHUkQFds+TxPBUwLh7/oL1ix3PIyt3Ce72BZ+oSCvWCTML4F4rpHr+FtAOCL9scl4v7rPfTsUwdUMUfaMDiWlpdL8Q9JjoI7PdmYwB/pyhyfD2YRoRRQAYKmMXU3VOE3aJ3rF4TMGc6ZCZnAONJsmSeOJzHpeWGBhP+vvo9CtbXUvdinFpVIE4RaxGGnjAtttw0CK/RGzx8RL8lCCYK3FQTomUn+TDEJfM9G5WZPQ8jYdngfa13ZI9DQOba6y8Slg0SZ9jEYDvy/j+ToFmi55eChWCDzq7AK/OjxKDeUzBGm8DC6BQ89KWBxAfUanD3qQNdKPxWNSb70aUVYR50nPdCyY0oxp4u3yfFq7BFRVWOyW/jvp+ZEdMlxtDtjq1A29/KZ5rUU93OyTMqF6cJv+G7zycGfxd7hJkViIIXV1zAcL4lXxjc/hMmEquRY= X-Microsoft-Antispam-PRVS: X-Microsoft-Exchange-Diagnostics: 1; BYAPR01MB4981; 4:dTycMziOPbgpfs6XwZx1LH2L58SUqAJftNdMGTZlpcMBgZ9P2f8FlvM8x9s1z5SQ7GD8AuajV8JQ5rdro7ax1QnAZrwq9bVPIehxLPP+GucYTADQX8jydfgwvijQxsFb+cIdTb7MhxRp4U6cLf+2RVzLiN7TS38d7EXaboK6tRNC0nkLJrH5gHxq0IzdwKP42Mcx7p1RXImgQfEMVDf7Qn/iRUlcKDFeKFKcJ3tl+KeylbHR3t2a3eIpsbNQu76j5HdCl7PSMTVwQLA5Q6kcWRWBL1i2nsZwbr6kR6N6WTBtq4wGSumhMHDnNaqP5XN6 X-Forefront-PRVS: 0924C6A0D5 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BYAPR01MB4981; 23:u5uR/nh5Rp7RyNeQ+CYWWDiPbMsZoxZh+mUH4cemP?= =?us-ascii?Q?IJcg3XyGm7NbLIoR9NJl2HJ1N2U9t/Dm8hDjm4mpjCMBN5cyk1WyWMrdG2Hi?= =?us-ascii?Q?jIeQfcdzj9tHJjAYHtib2mhoOQ6SKckUWzoVTZbSuaO2MISzBkNoLjEhUoDD?= =?us-ascii?Q?5OvZXQ9d6fle8y3bX81krpq0PoYVz7hFd2bEhcgsgZGYFluntFhp0fcHamdN?= =?us-ascii?Q?rrmnhlkzcl0eMh2HLqwzMWnZhtUdCFJuYktYnqCH52MivwJ2C41Syx7ih3xf?= =?us-ascii?Q?5CscB9bmmzBc9tHHm+nYJL8ymtoWA4jXQFePYhhbNBHqDI/YQr+FxyKXv3Tf?= =?us-ascii?Q?5Mdt0Yh5PvR4w9Ft/coqSXSPVyQlq726XlYILpN/D1FG5qvUILjMaUYoK+7E?= =?us-ascii?Q?vHm4BCAJddwfnSBdLXGZcdDITSS150131auDAibcwkZtrAGIiu2vpBOlhW5a?= =?us-ascii?Q?I7zNird8vsaHaHAc4Ia6CuJ5ZWQ/hhpl9xfeHlby5d++Qat21HoQbm1zIPCS?= =?us-ascii?Q?tbeN9+y23PgF/YFFVhPz3+aQ9Z43wj4IeTHRS+dySKWzchH3WBxRhjHnWHTQ?= =?us-ascii?Q?OMPbH97oLOY8RSgnVbpbndzpC95+W7YI3iogrulH0xjE/ufqvbmuMrPds/EC?= =?us-ascii?Q?OWk5i16bU5ftiW1b7JVPV+LNZPIKi0TFG7IXoUN2asFxazUqTPZNgggipC5L?= =?us-ascii?Q?JtacGCRwyW7/nkpUuf6dahpbddOALWN2L29JR5iF2bXB6pdOK+Z6P/fYBuJg?= =?us-ascii?Q?RUvgG0F0mj1yaHSyOT1+NGXDpiGJqQh0iMa0gq6kYx1ueVrkVph4Ref/lxGo?= =?us-ascii?Q?vIFf+d7RcHAicNkDmyLHgVo+4kq62nzV5vCNFeszVGdojQHQG+wXH0Qr8nXG?= =?us-ascii?Q?9+lX9ntGfTczj5YrvGNynPI1eKDU4PlLWQMvroNN/lfyDUihapFpXijPvU43?= =?us-ascii?Q?s82Lzjbs3jD4OmI3wp49Z4rByZw/5N9O6YviKP5oBai00rjdTFpM1dMMDrC6?= =?us-ascii?Q?1VsEjyIspzryREwpRIugiTUWmeZAyIb+8MRrJQ3VCypsboyFy92q5v2T9ka/?= =?us-ascii?Q?0C+HKNnXYKcWfhVbAidQUhOlpKLKRg2mSZMLm3kNGwDeHQopw0iogVCAN2iP?= =?us-ascii?Q?BQowQBVUDqtYOgwErOq5qykKCrcK+Xh/SXR/P8hoPUrkrXrYMt1tg5Bxqgg9?= =?us-ascii?Q?ftmaAS1E3C5q3k8iT1tnOcNxoXCQeEoKJ7uEax0BK1m+PumPB0btl6WBQ=3D?= =?us-ascii?Q?=3D?= X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Message-Info: rYUhB84p4SPIj7XHLgVxyDiUVzWY87o3obT1b4LQlCElvR4QJc5hebed4qLPfWuO2luB2QnpAM6ZwbPByisyhtyNc700ZYt9Msc+uDgnzvk76XPIzDBvmyneQ1cTkFoym/4qp2BriXmzDkvxCOaG+v09ofy//1vwdhWSqukBZI2cmMUCW0eOoCBwyQlq/L25j4RdexpcMo8VGeTvfCwhg1h1qkOn2YOL+wnA81f/+rFKZnrLx/qvx9CRcw8V6+n5gZjPihJnb76YJPLz998zIRYqbhI9wm9w7JUp+A4wGTqbBXPBljWBRQvbZPpg+5INiwYse3ICGEK8/39RL4JqJF6rGVBMTbhRonO45rXF77ZfiqO262VyuOXzuNqEBsxZ8FqNGCFFOUH93iOAbT7v8zN3uNRTlwNRUhrTdapUe0c= X-Microsoft-Exchange-Diagnostics: 1; BYAPR01MB4981; 6:PiDj/PGcIEisVKgpWjAJBT3a5/oi5yNfcrIov/Fjocne1bwkBTYdWBJJtTYmva8Wn0PsaBi9uvOQiTFVDFjCjXw3lmn+nsPfVnln7lpb6OTc9wItylQVTQyMcD1JH6QTRRu48qcqlkiXWI/B1pKuioomPak9lptfhMvTozEjAlTwI3UKJOElkk4Vwq9W+/2Kfk92v2dyxUMJHKUjBymB6TB1e1CWO0vBkfbKGHQo9dPk/H/zzCxEKaMDEIcpQsrHP5vMCp9I/FLAXkrhxLOYrGUaEo+nZkWwPjNsqO2Gfub80KISadhqevTURY0B6HIfzMHuv7K+l/jn+CvsT7uWH2IdsKQ02iQU5KNqTmRdAAFXUiJnkwC5prNVGHSB3V9SnJicL+gj4ue9mMC6vHjgeHU/xR4TtBEV675lfZzdkYeczkdmaWSuzPYcELhQq3L2tdJtmwQAUUoR1nVTuYzKNg==; 5:HsEBO/hbgl+m95Xkq68Q0h3ZCpe5KxfHJlse5ps7UkIIU+F1hxEQM6LPoNkDslqcJ8dRxlkIUjhlw8SW6CIN7qON9pU9NNNxBw4CjFBR2CuTV3SN8CXDAfO6KTg6/Xx5Gt5X+kWxZeh9AVtjBuq9b0Am3XO4EQIgada9XDa8wEUVvZZROUH5ZSh32mreNBRNhaRtiS9HN8PxtQHE89QKfA==; 7:qqU8CA2avjADCKC/HhV5x+0JIzJVSIQg+TN+vXVDF5AKRZz8taHhOpdJLGNoA/UlMrX3JWIutBF2bhqMrMMQzasfkCakx35f8RWWWtC5cCkZKx+pcSh+cxa+ZFAnR/J4wze5jXqhVWcY1AipSxt9gQ== SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Jan 2019 18:35:02.4281 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 4b0d1cbc-0feb-44b9-7403-08d67fcf28dd X-MS-Exchange-CrossTenant-Id: 64afd9ba-0ecf-4acf-bc36-935f6235ba8b X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=64afd9ba-0ecf-4acf-bc36-935f6235ba8b; Ip=[18.9.28.11]; Helo=[outgoing.mit.edu] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR01MB4981 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: Mon, 21 Jan 2019 18:35:09 -0000 On Thu, Dec 06, 2018 at 03:12:04PM -0800, Jim Schaad wrote: > 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. If I am wrong about my assumptions it would be interesting to know. My understanding agrees that the MLS design is not a good fit for the constraints here. -Ben From nobody Tue Jan 22 15:03:28 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFB74131191; Tue, 22 Jan 2019 15:03:21 -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=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 peB3hkT44Pam; Tue, 22 Jan 2019 15:03:20 -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 1295713118E; Tue, 22 Jan 2019 15:03:19 -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 x0MN3FIL030046; Tue, 22 Jan 2019 18:03:15 -0500 DKIM-Filter: OpenDKIM Filter v2.11.0 taper.sei.cmu.edu x0MN3FIL030046 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1548198195; bh=9yHA5+DplmD+8cO7ksYUQwUwdQ+VtSygRZMjdi8vUg8=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=rM/WFgnRl2m7nhufJouVGM/0jbJwBz7aqKlcp1b6kuCpRh0TWJx9VW9uTTvVixQvb HgH3bI3Yi6nyNdX3THey514B1daUOj2KogC7nkjZmUb6B4T15hOD9Ch2KPYjveoGpr 0ivMPl8jLXeIMtDvsN62wETEgv38uOJEWFhzZVGA= 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 x0MN3D92033665; Tue, 22 Jan 2019 18:03:13 -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.0435.000; Tue, 22 Jan 2019 18:03:13 -0500 From: Roman Danyliw To: Benjamin Kaduk , Richard Barnes CC: "secdispatch@ietf.org" , Kathleen Moriarty , "ace@ietf.org" , =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= , "Francesca Palombini" , John Mattsson Thread-Topic: [Ace] [Secdispatch] EDHOC Thread-Index: AQHUou5Zx1xiDx+jgESY4I5hUyszWqWc++KAgAH8Z4CAFrLCAIAACQQAgAZMFFA= Date: Tue, 22 Jan 2019 23:03:12 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC0185795C45@marathon> References: <79FD6563-8ADA-4D73-B8D5-C3D70604CD76@gmail.com> <47F03C99-68C1-4ADB-873D-F01987D66849@ipv.sx> <20190118172714.GJ81907@kduck.mit.edu> In-Reply-To: <20190118172714.GJ81907@kduck.mit.edu> 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] [Secdispatch] EDHOC 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, 22 Jan 2019 23:03:22 -0000 DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEFjZSBbbWFpbHRvOmFjZS1i b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQmVuamFtaW4gS2FkdWsNCj4gU2VudDogRnJp ZGF5LCBKYW51YXJ5IDE4LCAyMDE5IDEyOjI3IFBNDQo+IFRvOiBSaWNoYXJkIEJhcm5lcyA8cmxi QGlwdi5zeD4NCj4gQ2M6IHNlY2Rpc3BhdGNoQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbQWNl XSBbU2VjZGlzcGF0Y2hdIEVESE9DDQo+IA0KPiBPbiBGcmksIEphbiAxOCwgMjAxOSBhdCAxMTo1 NDo1OEFNIC0wNTAwLCBSaWNoYXJkIEJhcm5lcyB3cm90ZToNCj4gPiBJZiBpdCB3b3VsZCBiZSBo ZWxwZnVsIHRvIGtlZXAgdGhpcyBtb3ZpbmcsIHdlIGNvdWxkIGNlcnRhaW5seSBhcnJhbmdlDQo+ ID4gYSB2aXJ0dWFsIGludGVyaW0gb24gdGhpcyB0b3BpYy4NCj4gDQo+IFRoYXQgc2VlbXMgbGlr ZWx5IHRvIGJlIHVzZWZ1bCwgdGhvdWdoIEkgc3VwcG9zZSB3ZSBzaG91bGQgd2FpdCB0byBzZWUg bW9yZQ0KPiBpbmRpY2F0aW9uIHRoYXQgcGVvcGxlIHdvdWxkIHNob3cgdXAgYW5kIGhhdmUgYSBw cm9kdWN0aXZlIGRpc2N1c3Npb24uDQoNCklNTywgdGhlIGNvbW1vbiB0aHJlYWQgYmV0d2VlbiBi b3RoIG9mIHRoZXNlIHByYWN0aWNhbCBzdWdnZXN0aW9ucyBpcyB0aGF0IHRoZSBjb21wbGV4aXR5 IG9mIHRoZSB0b3BpYyBjYW4ndCBlbnRpcmVseSBmaXQgaW50byB0aGUgdGltZSB0aGF0IHdvdWxk IGJlIGFsbG90dGVkIGR1cmluZyBzZWNkaXNwYXRjaCBkdXJpbmcgdGhlIElFVEYgMTA0IG1lZXRp bmcuICBMZXQncyBzdGFydCB0aGlzIGNvbnZlcnNhdGlvbiBvbiBsaXN0IG5vdy4NCg0KUm9tYW4N Cg== From nobody Wed Jan 23 01:48:49 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E94F4128BCC for ; Wed, 23 Jan 2019 01:48:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.032 X-Spam-Level: X-Spam-Status: No, score=-2.032 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, 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 OsdFZX6v936P for ; Wed, 23 Jan 2019 01:48:45 -0800 (PST) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-eopbgr130137.outbound.protection.outlook.com [40.107.13.137]) (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 D7630123FFD for ; Wed, 23 Jan 2019 01:48:44 -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=e40kXCxqU+yfLEdyT7BNUzSErUe+l2JLSP53sv7Z3OA=; b=MY80mAReIb2fXr8ohC8F52L0G57rcezbyLBJ/FXTIWbfTDJ3+R864BUcR7G8y3piOMW6MZ9L5drUd4zizNCFsNHQ9Y74rdGAPi8PW4JO9ugCwtNKLQpLC7nJQvkjrabMZQCjSJBn4pvInTsXVcWzRzcb7+3uGhrmo/868W+cGJU= Received: from DB6P190MB0054.EURP190.PROD.OUTLOOK.COM (10.172.229.12) by DB6P190MB0229.EURP190.PROD.OUTLOOK.COM (10.172.230.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1558.17; Wed, 23 Jan 2019 09:48:40 +0000 Received: from DB6P190MB0054.EURP190.PROD.OUTLOOK.COM ([fe80::2d19:ef79:d153:7627]) by DB6P190MB0054.EURP190.PROD.OUTLOOK.COM ([fe80::2d19:ef79:d153:7627%6]) with mapi id 15.20.1558.016; Wed, 23 Jan 2019 09:48:40 +0000 From: Esko Dijk To: "ace@ietf.org" Thread-Topic: [Ace] WGLC for draft-ietf-ace-coap-est - optimization for embedded devices Thread-Index: AdSzANDF7SgGt3HDRj6nI+AEfU6Y+Q== Date: Wed, 23 Jan 2019 09:48:40 +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:1dc1:ad6e:2d30:44a5] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB6P190MB0229; 6:8vtnBQDeKssKCXCe6YQl6E69qvwtkW2lM1ydnRWTolRVtiN6H++SwYn/YBtzIlk0MWlDnzS4EGmZivghyERBwvTsF2t70naCg+oVcip+s4NQpQasVo7RZF3gpbNXGNaxjGyEnz7kG54eFVPc2eyKmBD/2Azh2jn28hOcp1d1geeSFpOmvQbKoZjSgJzazZmXtqe3csrmdYIBoIMAFCNCwnDsGlt/LEylNfOW5K793jbJq+UECTJzb0qzKO/8yBUs0qiN0SA2litw8Rckd5sV5WzUnoMHRrl9SWZR4KHU0YCJwuASda2kP9uJzINYkoFcpWKso9CMKPNZa4PpR9nJMonZYRB/9SmJOVZ0CNCqCXdoTqtjbebAdfLaSZfzPQtUjW6LLEHcAy8hChBMODan+uSSTUudCT/4aC9E65P6CTLMtGujDJ1LQxVNF3+g9Drfm04rZba5huZ5VYea1Ruf6Q==; 5:WLHfiXVpcL3PCsOYAteXfy+I0hbBXtN1w2rL6TXXtQ0i3BYA1Aa8WxQw376BbpuOhKtMFukzu5GEHfF7lzDN9Apfazt7XN9jDDaghaWDl9wTtk29tBIbZ9LoHPVoaYRmbdbHLmaeYrm8emxOmscXvX6GIYcBB8MjPGQf6RQzB4FLbQe/O/Yqfk7K/aH+HtmnavT68fDKc3W2xNcaOqsuLg==; 7:deMkeFj8E73fK8RxFZJGL1jczEwT274dkLSZoee9fWpeZFoqLdj4sOE58cIYoaNGVv4vKjY7xtSf1o5Av15u0zIzeN1R7/vZnu8Om0b0CCkSndYBCuc5mx1Gnz/i6UIric9hTEH4DRBplmAGnBCHUw== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: b0a32e6f-aa54-43c8-decc-08d68117f467 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(7021145)(8989299)(5600110)(711020)(4605077)(4534185)(7022145)(4603075)(4627221)(201702281549075)(8990200)(7048125)(7024125)(7027125)(7023125)(2017052603328)(7153060)(7193020); SRVR:DB6P190MB0229; x-ms-traffictypediagnostic: DB6P190MB0229: x-microsoft-antispam-prvs: x-forefront-prvs: 0926B0E013 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(39830400003)(366004)(136003)(396003)(346002)(199004)(189003)(13464003)(6916009)(33656002)(86362001)(68736007)(316002)(7696005)(6436002)(5640700003)(99286004)(6116002)(508600001)(229853002)(966005)(106356001)(14454004)(9686003)(55016002)(105586002)(2351001)(6306002)(305945005)(8676002)(7736002)(6246003)(53936002)(1730700003)(46003)(71190400001)(71200400001)(74316002)(97736004)(81156014)(486006)(81166006)(25786009)(44832011)(476003)(14444005)(2906002)(74482002)(186003)(2501003)(256004)(8936002)(6506007)(53546011)(102836004); DIR:OUT; SFP:1102; SCL:1; SRVR:DB6P190MB0229; 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-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: /jx2H6e6tM2/ziELrusBPRDlp4KKiU4iiC+Bn1h4jgz2hh24ZBX/iIL7VVWYTNxQIJ6/g7kSzdmpb1vruVmuJZ75vzzR2pjQXFXVkAsrkSaQbciycvr8jLS7sRxcQHecGCo+7BCtQEdUSX8QcFi+zyCPUVNKMHr2iTuGfh/WhN4AXl5E3+SjP22s1noKVdH0V4J0VQ/mGGiKBg/f87dyh3jD8NqgBiWtqsDy4ma/dZ7qkTTGRsOl5sjy7c6zIQazGizXeJEkde+POftdAQmBzifYQueFmgvyx3Gr/xzbWBkhl051uDnz7QTsN6tO9NPZDQfTi6cXBM8vDdHdLpnh9e+DQkTPYunJS6cmjTWMvJH03hTqMSajkY+a56Jl9LjdA0/Larwii9CjvGgCtZytv5dFZm5M92XS1/kH4o6EIeI= 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: b0a32e6f-aa54-43c8-decc-08d68117f467 X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Jan 2019 09:48:40.2932 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 58bbf628-15d2-46bc-820b-863b6774d44b X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6P190MB0229 Archived-At: Subject: Re: [Ace] WGLC for draft-ietf-ace-coap-est - optimization for embedded devices 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, 23 Jan 2019 09:48:48 -0000 RGVhciBBQ0UgV0cgJiBhdXRob3JzLA0KDQpNeSBtYWluIGNvbW1lbnQgb24gdGhpcyBkcmFmdCBp cyBiYXNlZCBvbiByZWNlbnQgZXhwZXJpZW5jZSB3aXRoIGFuIGVtYmVkZGVkIGltcGxlbWVudGF0 aW9uLiBJbiB0aGUgZHJhZnQsIHRoZSBjb250ZW50IGZvcm1hdCAiYXBwbGljYXRpb24vcGtjczct bWltZTtzbWltZS10eXBlPWNlcnRzLW9ubHkiIGlzIHVzZWQgdG8gdHJhbnNwb3J0IGEgc2luZ2xl IGNlcnRpZmljYXRlIGJhY2sgdG8gdGhlIGNsaWVudC4gSG93ZXZlciwgaW4gdGhlIGVtYmVkZGVk IGltcGxlbWVudGF0aW9uIGNyeXB0byBsaWJyYXJ5IHRoZXJlIGlzIG5vIHN1cHBvcnQgZm9yIHBh cnNpbmcgdGhpcyBmb3JtYXQsIGJ1dCB0aGVyZSBpcyBzdXBwb3J0IGZvciBwYXJzaW5nIFguNTA5 djMgKGFwcGxpY2F0aW9uL3BraXgtY2VydCkuIFNlZSBlLmcuIGh0dHBzOi8vdGxzLm1iZWQub3Jn L2FwaS9ncm91cF9feDUwOV9fbW9kdWxlLmh0bWwgZm9yIGFuIGVtYmVkZGVkIEFQSSB0aGF0IGNh biBwYXJzZSBDU1IgYW5kIGNlcnRzLCBidXQgbm90IFBLQ1MjNy4NCg0KVGhlcmVmb3JlIHRoZSBY LjUwOSBmb3JtYXQgc2VlbXMgYmV0dGVyIHRvIHVzZTsgYWxzbyBnaXZlbiB0aGF0IA0KMSkgdGhl IHNpZ25pbmcgb2YgZGF0YSB0aGF0IHRoZSBQS0NTIzcgUy9NSU1FIGVudmVsb3BlIHByb3ZpZGVz IGlzIHVzZWxlc3MgYmVjYXVzZSB0aGUgRFRMUyBzZXNzaW9uIGlzIGFscmVhZHkgZW5kLXRvLWVu ZCBwcm90ZWN0ZWQgYW5kIHRoZSBjZXJ0aWZpY2F0ZSBpcyBhbHJlYWR5IHNpZ25lZDsgYW5kIA0K MikgUkZDIDcwMzAgcmVxdWlyZXMgdGhhdCBvbmx5IG9uZSBjZXJ0aWZpY2F0ZSwgdGhlICBnZW5l cmF0ZWQgb25lLCBpcyBjYXJyaWVkIGluIHRoZSAvc2ltcGxlKHJlKWVucm9sbCByZXNwb25zZSBz byB0aGF0IGEgY29udGFpbmVyIGZvcm1hdCBmb3IgbXVsdGlwbGUgY2VydGlmaWNhdGVzIGlzIG5v dCByZWFsbHkgbmVlZGVkIGhlcmUuDQoNClNvIHRvIHJlZHVjZSBjb2RlIHNpemUgZm9yIGVtYmVk ZGVkIGltcGxlbWVudGF0aW9ucyBpdCB3b3VsZCBiZSB2ZXJ5IGJlbmVmaWNpYWwgaWYgdGhlIEVT VCBTZXJ2ZXIgd291bGQgc3VwcG9ydCBhbiBhZGRpdGlvbmFsIGNvbnRlbnQgZm9ybWF0Og0KYXBw bGljYXRpb24vcGtpeC1jZXJ0ICAoc2VlIFJGQyA1MjgwKQ0KDQpUaGUgY2xpZW50IGNhbiByZXF1 ZXN0IHRoaXMgZm9ybWF0IHVzaW5nIHRoZSBDb0FQIEFjY2VwdCBPcHRpb247IGJ5IGRlZmF1bHQg aWYgbm8gQWNjZXB0IE9wdGlvbiBnaXZlbiB0aGUgRVNUIHNlcnZlciB3b3VsZCByZXR1cm4gYXBw bGljYXRpb24vcGtjczctbWltZTtzbWltZS10eXBlPWNlcnRzLW9ubHkuDQpXaGF0IGRvIHlvdSB0 aGluayBhYm91dCB0aGlzIGFkZGl0aW9uPyBJIGJlbGlldmUgdGhhdCBhZGRpbmcgdGhpcyB3b3Vs ZCBtYWtlIHRoZSBFU1Qtb3Zlci1Db2FwcyBwcm90b2NvbCBhbiBpZGVhbCBmaXQgdG8gY29tbW9u IGVtYmVkZGVkIFNXIHN0YWNrcy4NCg0KRnVydGhtb3JlIEkgZm91bmQgdGhlc2UgdHdvIGlzc3Vl cyB0aGF0IG5lZWQgdG8gYmUgYWRkcmVzc2VkOg0KDQpTZWN0aW9uIDUuNDogIlRoZSBlcXVpdmFs ZW50IENvQVAgZXJyb3IgY29kZSB0byB1c2UgaW4gYW4gRVNULWNvYXBzIHJlc3BvbnNlcyBhcmUg Mi4wNCAuLi4iIC0+IDIuMDQgaXMgYSBzdWNjZXNzIGNvZGUsIG5vdCBhbiBlcnJvci4NCg0KU2Vj dGlvbiA1LjY6ICJBY2NvcmRpbmcgdG8gc2VjdGlvbiA1LjIuMiBvZiBbUkZDNzI1Ml0sIGEgc2xv dyBzZXJ2ZXIgY2FuIGFja25vd2xlZGdlIHRoZSByZXF1ZXN0IHdpdGggYSAyLjMxIGNvZGUiIC0+ IDIuMzEgaXMgbm90IHNwZWNpZmllZCBpbiBSRkMgNzI1Mi4NCg0KQmVzdCByZWdhcmRzDQpFc2tv IERpamsNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEFjZSA8YWNlLWJvdW5j ZXNAaWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiBKaW0gU2NoYWFkDQpTZW50OiBNb25kYXksIEphbnVh cnkgMTQsIDIwMTkgMDU6MDMNClRvOiBhY2VAaWV0Zi5vcmcNClN1YmplY3Q6IFtBY2VdIFdHTEMg Zm9yIGRyYWZ0LWlldGYtYWNlLWNvYXAtZXN0DQoNClRoZSBjaGFpcnMgYmVsaWV2ZSB0aGF0IHRo ZSBFU1Qgb3ZlciBDb0FQIGRyYWZ0IGlzIG5lYXJpbmcgdGhlIHBvaW50IGl0IHNob3VsZCBiZSBz ZW50IHRvIHRoZSBJRVNHIGZvciBwdWJsaWNhdGlvbi4gIFdlIGFyZSB0aGVyZWZvcmUgZ29pbmcg dG8gaGF2ZSBhIFdvcmtpbmcgR3JvdXAgTGFzdCBDYWxsIG9uIHRoaXMgZG9jdW1lbnQuICBXR0xD IHdpbGwgdW50aWwgMjl0aCBvZiB0aGlzIG1vbnRoLiAgUGxlYXNlIHJldmlldyB0aGUgZG9jdW1l bnQgYW5kIHNlbmQgY29tbWVudHMgYm90aCBwb3NpdGl2ZSBhbmQgbmVnYXRpdmUgdG8gdGhlIGxp c3QgYWJvdXQgaXRzIHN0YXRlLg0KDQpKaW0gJiBSb21hbg0KDQoNCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpBY2UgbWFpbGluZyBsaXN0DQpBY2VAaWV0 Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYWNlDQo= From nobody Wed Jan 23 08:31:51 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF197130E9C for ; Wed, 23 Jan 2019 08:31:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.041 X-Spam-Level: X-Spam-Status: No, score=-2.041 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H4-MalG6FQuF for ; Wed, 23 Jan 2019 08:31:47 -0800 (PST) Received: from mail-ot1-x32f.google.com (mail-ot1-x32f.google.com [IPv6:2607:f8b0:4864:20::32f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29DF1130E9B for ; Wed, 23 Jan 2019 08:31:47 -0800 (PST) Received: by mail-ot1-x32f.google.com with SMTP id s5so2439991oth.7 for ; Wed, 23 Jan 2019 08:31:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8/iAKQsQUxoFrN28jG7KqInj8y0coEhcS8ItEV9X+4A=; b=0KWoYIHaCOZ6GF/PdPHGOa9RP0fAl0mQnEzI2Ijbf6xvaIOMvFUzxozCVvPab6eypl UBuk1df+4VJ8fd7PmSpGpphHOtYNlT11tIEOmi2u+vHaSUrIVLgwhTu4wH0v2xLqUpG9 BivC161Wxdgemhz/wJXmQLn1GIQKzYhe6c11yc2j5HWKXA9lkeIZwZnccLm4HYqG6OCX POfH+XH4X7C3iFcei4R5hYS/caRDhkHGL4RR5s1zCZEo8j340/3FtkkkL5wrVixWGsA0 wUJA0wID6xAiaIimN6q17IgQOmOYDMWmWZa/2/GC4+HWkU+G2I9/TUiLxIK1cqo3Buf5 89bA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=8/iAKQsQUxoFrN28jG7KqInj8y0coEhcS8ItEV9X+4A=; b=G5UqV8VoUTlkdWX8h9tAn7oIgHc5PdMqKQZnbaCD5tntAe+HtvHin4eIsRt9eLznH0 1pgH6dDZhIPe8Qd19gnZJPwld4utgB6IA32Sn5ai91VM7rg8m9hLq5G2Zjqz3rtdZs6t Hfd+p5sx+UCFyPOvRi8hHOgTSJGFLfZeeT/tYH2Gmk7/lSg3QeR6tpawFRAf9LFl0nak gGKhw2c67+Y+55M/ftN880NGl36nZzeJGVaGAxnl22vgZ2iKEF3IGkicFGS/6SxWLUtI B1iirTTK1q2g3HO/eMkUSeKlJ7ZM4qrZG77vsA0AR4GQVTLzGNrpJpA22hyOppDwN7WU yOaQ== X-Gm-Message-State: AJcUukc7AGW1FwGOd47FqRhz7EIqL8ReFPXdN/uZbVAtUXMyDAV3YeU7 kXqsEbP6mxLHLeXe85PJqcS7RQvi+qG8LcNMZxEIgA== X-Google-Smtp-Source: ALg8bN68bFOs/5qEdzm+AM/hjT4wBrapn2C+EUDaCurkXuSqZy/oQ4GwMeu46FMfN6zBInPhTL4y/jKL0ateS25oB48= X-Received: by 2002:a05:6830:1584:: with SMTP id i4mr1745244otr.116.1548261106222; Wed, 23 Jan 2019 08:31:46 -0800 (PST) MIME-Version: 1.0 References: <79FD6563-8ADA-4D73-B8D5-C3D70604CD76@gmail.com> <47F03C99-68C1-4ADB-873D-F01987D66849@ipv.sx> <20190118172714.GJ81907@kduck.mit.edu> <359EC4B99E040048A7131E0F4E113AFC0185795C45@marathon> In-Reply-To: <359EC4B99E040048A7131E0F4E113AFC0185795C45@marathon> From: Richard Barnes Date: Wed, 23 Jan 2019 11:31:34 -0500 Message-ID: To: Roman Danyliw Cc: Benjamin Kaduk , "secdispatch@ietf.org" , Kathleen Moriarty , "ace@ietf.org" , =?UTF-8?Q?G=C3=B6ran_Selander?= , Francesca Palombini , John Mattsson Content-Type: multipart/alternative; boundary="00000000000041a7e4058022a1a5" Archived-At: Subject: Re: [Ace] [Secdispatch] EDHOC 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, 23 Jan 2019 16:31:50 -0000 --00000000000041a7e4058022a1a5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Summing up where I believe the conversation stands now, it seems like what folks are asking for is either: 1. An analysis that shows that EDHOC is equivalent to an existing AKE (e.g., IKE or TLS), or 2. An argument that a new AKE is necessary (vs. a re-encoding of an existing AKE) G=C3=B6ran et al: Do you have thoughts on those points? It seems like it could be a productive use of an hour or two of virtual interim time to help the group understand one of those lines of argument. --Richard On Tue, Jan 22, 2019 at 6:03 PM Roman Danyliw wrote: > > > -----Original Message----- > > From: Ace [mailto:ace-bounces@ietf.org] On Behalf Of Benjamin Kaduk > > Sent: Friday, January 18, 2019 12:27 PM > > To: Richard Barnes > > Cc: secdispatch@ietf.org > > Subject: Re: [Ace] [Secdispatch] EDHOC > > > > On Fri, Jan 18, 2019 at 11:54:58AM -0500, Richard Barnes wrote: > > > If it would be helpful to keep this moving, we could certainly arrang= e > > > a virtual interim on this topic. > > > > That seems likely to be useful, though I suppose we should wait to see > more > > indication that people would show up and have a productive discussion. > > IMO, the common thread between both of these practical suggestions is tha= t > the complexity of the topic can't entirely fit into the time that would b= e > allotted during secdispatch during the IETF 104 meeting. Let's start thi= s > conversation on list now. > > Roman > --00000000000041a7e4058022a1a5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Summing up where I believe the conversation stands no= w, it seems like what folks are asking for is either:

<= div>1. An analysis that shows that EDHOC is equivalent to an existing AKE (= e.g., IKE or TLS), or
2. An argument that a new AKE is necess= ary (vs. a re-encoding of an existing AKE)

G=C3=B6= ran et al: Do you have thoughts on those points?

I= t seems like it could be a productive use of an hour or two of virtual inte= rim time to help the group understand one of those lines of argument.
=

--Richard

On Tue, Jan 22, 2019 at 6:03 PM Roma= n Danyliw <rdd@cert.org> wrote:

> -----Original Message-----
> From: Ace [mailto:ace-bounces@ietf.org] On Behalf Of Benjamin Kaduk
> Sent: Friday, January 18, 2019 12:27 PM
> To: Richard Barnes <rlb@ipv.sx>
> Cc: secdispa= tch@ietf.org
> Subject: Re: [Ace] [Secdispatch] EDHOC
>
> On Fri, Jan 18, 2019 at 11:54:58AM -0500, Richard Barnes wrote:
> > If it would be helpful to keep this moving, we could certainly ar= range
> > a virtual interim on this topic.
>
> That seems likely to be useful, though I suppose we should wait to see= more
> indication that people would show up and have a productive discussion.=

IMO, the common thread between both of these practical suggestions is that = the complexity of the topic can't entirely fit into the time that would= be allotted during secdispatch during the IETF 104 meeting.=C2=A0 Let'= s start this conversation on list now.

Roman
--00000000000041a7e4058022a1a5-- From nobody Wed Jan 23 10:52:03 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FB621311E9 for ; Wed, 23 Jan 2019 10:51:40 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 IVBs8PM_NtOW for ; Wed, 23 Jan 2019 10:51:38 -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 63DF413122E for ; Wed, 23 Jan 2019 10:12:35 -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 x0NICYoV008246 for ; Wed, 23 Jan 2019 13:12:34 -0500 DKIM-Filter: OpenDKIM Filter v2.11.0 taper.sei.cmu.edu x0NICYoV008246 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sei.cmu.edu; s=t52kn2igOmwp; t=1548267154; bh=sQnb542b0rnhn0bFKoiSZAt9GO10rZKvAZUFVD7x+xI=; h=From:To:Subject:Date:From; b=RYljMNQYQfNq6txXrFxxj3j/ktEUafO14xJjf29WInHJNaOyxeCayONVjnhPq3cjj YIT8adh2aC2AfTOCKQvJKDvl2lcr1MX5fUTFuB1fyI8BzyesDgN6YjXbb3XBUBLz1M WM9Kapa7pXDd1Cx4E6E/zKQ4I6qscrJ19b2elheM= Received: from CASCADE.ad.sei.cmu.edu (cascade.ad.sei.cmu.edu [10.64.28.248]) by delp.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x0NICP3X040689 for ; Wed, 23 Jan 2019 13:12:25 -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.0435.000; Wed, 23 Jan 2019 13:12:25 -0500 From: Grace A Lewis To: "ace@ietf.org" Thread-Topic: ACE Implementation for Disadvantaged Environments Thread-Index: AQHUs0cwxz8vJeWIVUGFns83Bt0/6w== Date: Wed, 23 Jan 2019 18:12:23 +0000 Message-ID: <11C08BF5-0060-459C-99DC-EABEA88DF44B@sei.cmu.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.10.6.190114 x-originating-ip: [10.64.200.25] Content-Type: multipart/alternative; boundary="_000_11C08BF50060459C99DCEABEA88DF44Bseicmuedu_" MIME-Version: 1.0 Archived-At: Subject: [Ace] ACE Implementation for Disadvantaged Environments 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, 23 Jan 2019 18:51:46 -0000 --_000_11C08BF50060459C99DCEABEA88DF44Bseicmuedu_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8sDQoNCkkganVzdCB3YW50ZWQgdG8gbWFrZSB0aGUgZ3JvdXAgYXdhcmUgb2Ygb3VyIEFD RSBpbXBsZW1lbnRhdGlvbiAoU0VJLUFDRSksIHdoaWNoIGluY2x1ZGVzIGFuIGltcGxlbWVudGF0 aW9uIGZvciBhIHJlc291cmNlLWNvbnN0cmFpbmVkIHNlcnZlci4NCg0KRGV0YWlscyBhdmFpbGFi bGUgaW4gdGhpcyBuZXdzIGFydGljbGU6IGh0dHBzOi8vd3d3LnNlaS5jbXUuZWR1L25ld3MtZXZl bnRzL25ld3MvYXJ0aWNsZS5jZm0/YXNzZXRpZD01MzkxODQNCg0KQXJ0aWNsZSBpbmNsdWRlcyB0 aGUgbGluayB0byBvdXIgR2l0IHJlcG8uDQoNCkVuam95IQ0KDQotIEdyYWNlIExld2lzDQoNCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkdyYWNlIEEuIExl d2lzLCBQaC5ELg0KUHJpbmNpcGFsIFJlc2VhcmNoZXIgYW5kIFRURyBJbml0aWF0aXZlIExlYWQN CkNhcm5lZ2llIE1lbGxvbiBTb2Z0d2FyZSBFbmdpbmVlcmluZyBJbnN0aXR1dGUNClNvZnR3YXJl IFNvbHV0aW9ucyBEaXZpc2lvbiAoU1NEKQ0KVGFjdGljYWwgVGVjaG5vbG9naWVzIEdyb3VwIChU VEcpDQoNCjQ1MDAgRmlmdGggQXZlLiAjNTQxMg0KUGl0dHNidXJnaCwgUEEgMTUyMTMNClBob25l OiAoNDEyKSAyNjgtNTg1MQ0KaHR0cDovL3d3dy5zZWkuY211LmVkdS9zdGFmZi9nbGV3aXMNCg0K 4oCcQSBjaGFuZ2UgaW4gcGVyc3BlY3RpdmUgaXMgd29ydGggODAgSVEgcG9pbnRz4oCdIC0tLSBB bGFuIEtheQ0K --_000_11C08BF50060459C99DCEABEA88DF44Bseicmuedu_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5Ok9wdGltYTsN CglwYW5vc2UtMToyIDAgNSAzIDYgMCAwIDIgMCA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p bHk6LXdlYmtpdC1zdGFuZGFyZDsNCglwYW5vc2UtMToyIDExIDYgNCAyIDIgMiAyIDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywg c3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYz QzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlw ZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7 DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28t c3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iIzA1NjND MSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5IZWxsbyw8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkkganVzdCB3YW50ZWQgdG8gbWFr ZSB0aGUgZ3JvdXAgYXdhcmUgb2Ygb3VyIEFDRSBpbXBsZW1lbnRhdGlvbiAoU0VJLUFDRSksIHdo aWNoIGluY2x1ZGVzIGFuIGltcGxlbWVudGF0aW9uIGZvciBhIHJlc291cmNlLWNvbnN0cmFpbmVk IHNlcnZlci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkRldGFp bHMgYXZhaWxhYmxlIGluIHRoaXMgbmV3cyBhcnRpY2xlOg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cu c2VpLmNtdS5lZHUvbmV3cy1ldmVudHMvbmV3cy9hcnRpY2xlLmNmbT9hc3NldGlkPTUzOTE4NCI+ aHR0cHM6Ly93d3cuc2VpLmNtdS5lZHUvbmV3cy1ldmVudHMvbmV3cy9hcnRpY2xlLmNmbT9hc3Nl dGlkPTUzOTE4NDwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQi PkFydGljbGUgaW5jbHVkZXMgdGhlIGxpbmsgdG8gb3VyIEdpdCByZXBvLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+RW5qb3khPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0Ij4tIEdyYWNlIExld2lzPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOiMwMDAwN0YiPl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX188L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6T3B0aW1hO2NvbG9yOiMwMDAw N0YiPkdyYWNlIEEuIExld2lzLCBQaC5ELjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTotd2Via2l0LXN0YW5kYXJkO2NvbG9yOmJsYWNrIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTpPcHRpbWE7Y29sb3I6IzAwMDA3RiI+ UHJpbmNpcGFsIFJlc2VhcmNoZXIgYW5kIFRURyBJbml0aWF0aXZlIExlYWQmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6LXdlYmtpdC1zdGFuZGFyZDtjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6T3B0aW1hO2NvbG9yOiMwMDAwN0YiPkNhcm5lZ2llIE1l bGxvbiBTb2Z0d2FyZSBFbmdpbmVlcmluZyBJbnN0aXR1dGU8L3NwYW4+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6LXdlYmtpdC1zdGFuZGFyZDtjb2xvcjpibGFjayI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6T3B0aW1hO2NvbG9y OiMwMDAwN0YiPlNvZnR3YXJlIFNvbHV0aW9ucyBEaXZpc2lvbiZuYnNwOyhTU0QpJm5ic3A7PC9z cGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5Oi13ZWJraXQtc3Rh bmRhcmQ7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5Ok9wdGltYTtjb2xvcjojMDAwMDdGIj5UYWN0aWNhbCBUZWNobm9sb2dpZXMgR3JvdXAg KFRURyk8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6LXdl YmtpdC1zdGFuZGFyZDtjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6LXdlYmtpdC1zdGFuZGFyZDtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6T3B0aW1hO2NvbG9yOiMwMDAw N0YiPjQ1MDAgRmlmdGggQXZlLiZuYnNwOyM1NDEyPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5Oi13ZWJraXQtc3RhbmRhcmQ7Y29sb3I6YmxhY2siPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5Ok9wdGltYTtjb2xvcjojMDAw MDdGIj5QaXR0c2J1cmdoLCBQQSAxNTIxMyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTotd2Via2l0LXN0YW5kYXJkO2NvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTpPcHRpbWE7Y29sb3I6IzAwMDA3RiI+UGhv bmU6ICg0MTIpIDI2OC01ODUxPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6T3B0aW1hO2Nv bG9yOiMwMDAwN0YiPjxhIGhyZWY9Imh0dHA6Ly93d3cuc2VpLmNtdS5lZHUvc3RhZmYvZ2xld2lz Ij48c3BhbiBzdHlsZT0iY29sb3I6IzA1NjNDMSI+aHR0cDovL3d3dy5zZWkuY211LmVkdS9zdGFm Zi9nbGV3aXM8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5Ok9wdGltYTtj b2xvcjojMDAwMDdGIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5Ok9wdGltYTtjb2xvcjojMzg1NzIzIj7igJxBIGNoYW5nZSBpbiBwZXJzcGVjdGl2ZSBpcyB3 b3J0aCA4MCBJUSBwb2ludHPigJ0gLS0tIEFsYW4gS2F5PC9zcGFuPjwvaT48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_11C08BF50060459C99DCEABEA88DF44Bseicmuedu_-- From nobody Wed Jan 23 18:26:54 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDCF4130934 for ; Wed, 23 Jan 2019 18:26: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, 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 poa0HQS8rfZG for ; Wed, 23 Jan 2019 18:26:50 -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 9FDD412F1AC for ; Wed, 23 Jan 2019 18:26:50 -0800 (PST) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id 8F0BB38263; Wed, 23 Jan 2019 21:26:00 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id E33D3E49; Wed, 23 Jan 2019 21:26:47 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id E1CF3C09; Wed, 23 Jan 2019 21:26:47 -0500 (EST) From: Michael Richardson To: Esko Dijk cc: "ace\@ietf.org" 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: Re: [Ace] WGLC for draft-ietf-ace-coap-est - optimization for embedded devices 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, 24 Jan 2019 02:26:53 -0000 --=-=-= Content-Type: text/plain Esko Dijk wrote: > My main comment on this draft is based on recent experience with an > embedded implementation. In the draft, the content format > "application/pkcs7-mime;smime-type=certs-only" is used to transport a > single certificate back to the client. However, in the embedded > implementation crypto library there is no support for parsing this > format, but there is support for parsing X.509v3 > (application/pkix-cert). See > e.g. https://tls.mbed.org/api/group__x509__module.html for an embedded > API that can parse CSR and certs, but not PKCS#7. > Therefore the X.509 format seems better to use; also given that > 1) the signing of data that the PKCS#7 S/MIME envelope provides is useless because the DTLS session is already end-to-end protected and the certificate is already signed; and > 2) RFC 7030 requires that only one certificate, the generated one, is > carried in the /simple(re)enroll response so that a container format > for multiple certificates is not really needed here. > So to reduce code size for embedded implementations it would be very > beneficial if the EST Server would support an additional content > format: > application/pkix-cert (see RFC 5280) I think that this is a reasonable thing to do. The client can easily say what it wants and I think the two formats are relatively easy to swap. What about if we went further, and went to: Concise Identities draft-birkholz-core-coid-01 -- ] 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 [ --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlxJImcACgkQgItw+93Q 3WVZuQf9Ee2+ZsUdOFYeXspkByNYRS0oWh2ZYzsDrdm3+TNYjdcsjYGJdrMb9VNz XTzxgApEyC5uZ+QXKa/I+BwtChazYv+bF0AEyM+SNOzhkJVfhzeLxkaWeD6LR7QQ 6dMybHsxj1bGrEXfqZ5tJRM9hEkwjv06DEWe6WpMcnQ+xK6v2nkB0csbbbIAAxg9 SsP77YxlcIEv0MWofxd/+rTiDzHBK+uHAHHDwfhaVpKYj7tADf0LT05UZIT5V9Lb FZEoSqNR8GyKmIzCq2YWXn8P38SRxN7Hg2zYEYaxz/sy6I1rCbFuWPSCJlzjf/27 KmnCQZ0UOdUsmHlNlKI1BFHWv0uN/g== =dJcI -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Jan 23 21:05:55 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 869B41310CD for ; Wed, 23 Jan 2019 21:05:53 -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 dLeDAaFSS93t for ; Wed, 23 Jan 2019 21:05:51 -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 5569F130E7E for ; Wed, 23 Jan 2019 21:05:51 -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, 23 Jan 2019 21:05:22 -0800 From: Jim Schaad To: 'Michael Richardson' , 'Esko Dijk' CC: References: <15991.1548296807@localhost> In-Reply-To: <15991.1548296807@localhost> Date: Wed, 23 Jan 2019 21:05:19 -0800 Message-ID: <000001d4b3a2$69396530$3bac2f90$@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: AQKPe14W3mTmO1gk9I6z01h4BEwvRAGwJtObpDrLsTA= Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Ace] WGLC for draft-ietf-ace-coap-est - optimization for embedded devices 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, 24 Jan 2019 05:05:53 -0000 > -----Original Message----- > From: Ace On Behalf Of Michael Richardson > Sent: Wednesday, January 23, 2019 6:27 PM > To: Esko Dijk > Cc: ace@ietf.org > Subject: Re: [Ace] WGLC for draft-ietf-ace-coap-est - optimization for > embedded devices > > > Esko Dijk wrote: > > My main comment on this draft is based on recent experience with an > > embedded implementation. In the draft, the content format > > "application/pkcs7-mime;smime-type=certs-only" is used to transport a > > single certificate back to the client. However, in the embedded > > implementation crypto library there is no support for parsing this > > format, but there is support for parsing X.509v3 > > (application/pkix-cert). See > > e.g. https://tls.mbed.org/api/group__x509__module.html for an > embedded > > API that can parse CSR and certs, but not PKCS#7. > > > Therefore the X.509 format seems better to use; also given that > > 1) the signing of data that the PKCS#7 S/MIME envelope provides is > useless because the DTLS session is already end-to-end protected and the > certificate is already signed; and There is no signature for this CMS signed message format. It only contains the certificates and CRLs that are passed back. I would still think that this is a fine idea as long as you are only going to return the leaf certificate and not returning a bag of certificates or any CRLs. > > 2) RFC 7030 requires that only one certificate, the generated one, is > > carried in the /simple(re)enroll response so that a container format > > for multiple certificates is not really needed here. > > > So to reduce code size for embedded implementations it would be very > > beneficial if the EST Server would support an additional content > > format: > > application/pkix-cert (see RFC 5280) > > I think that this is a reasonable thing to do. > The client can easily say what it wants and I think the two formats are > relatively easy to swap. > > What about if we went further, and went to: > Concise Identities > draft-birkholz-core-coid-01 Given that it would be a blocking factor, I would think about this as maybe something in the future. Jim > > -- > ] 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 [ From nobody Thu Jan 24 00:45:16 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8D7D12870E for ; Thu, 24 Jan 2019 00:45:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.031 X-Spam-Level: X-Spam-Status: No, score=-2.031 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 qkQFTx-3TpK9 for ; Thu, 24 Jan 2019 00:45:11 -0800 (PST) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80091.outbound.protection.outlook.com [40.107.8.91]) (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 6C867130E2E for ; Thu, 24 Jan 2019 00:45:11 -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=7VcUn437duclbXMXW3zvqqs5oLcF3Gr3AbIwCu0yWsE=; b=UqTuDEq9+5HwoQXZa1uOdnl80bTULhMjnLS5d5YaEfIj7BebKOBdsPOEVlSPQ3H3BBbBTHpUTZK8lSgwMx3XKrcL2H1DGiwQoXeWTgdQwMa8WmDk2+537oLkrAMjZyfS75XTJGrteElatR/tWun+sjRElmroqxWe4A1pBjvIuI8= Received: from DB6P190MB0054.EURP190.PROD.OUTLOOK.COM (10.172.229.12) by DB6P190MB0263.EURP190.PROD.OUTLOOK.COM (10.175.241.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1537.31; Thu, 24 Jan 2019 08:45:07 +0000 Received: from DB6P190MB0054.EURP190.PROD.OUTLOOK.COM ([fe80::2d19:ef79:d153:7627]) by DB6P190MB0054.EURP190.PROD.OUTLOOK.COM ([fe80::2d19:ef79:d153:7627%6]) with mapi id 15.20.1558.016; Thu, 24 Jan 2019 08:45:07 +0000 From: Esko Dijk To: Jim Schaad , 'Michael Richardson' CC: "ace@ietf.org" Thread-Topic: [Ace] WGLC for draft-ietf-ace-coap-est - optimization for embedded devices Thread-Index: AdSzANDF7SgGt3HDRj6nI+AEfU6Y+QAi3BaAAAWJZoAABvuaAA== Date: Thu, 24 Jan 2019 08:45:06 +0000 Message-ID: References: <15991.1548296807@localhost> <000001d4b3a2$69396530$3bac2f90$@augustcellars.com> In-Reply-To: <000001d4b3a2$69396530$3bac2f90$@augustcellars.com> 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:653b:e57c:bc08:b670] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB6P190MB0263; 6:k1uJJSaX3n1DdT8TVKC3xIXt9CZU2P2jQrVJ1VbrPYKz0U/ZVsTM9DCiuCv1g+SFaXDth7LjBRl6SP7ENyzcvKyI+kxGwThCw0+EqSu272os2WxevagkVC47UyGdEngR3J8+lWWRTzlxMPMQy6OljXn9M2UBU9Lll7iaybVnapdV2ocssMH3/1w1csEWRN8xhPCfx0cAw8eFz2J/72fOq8A89enORPGt1PDah2YlwIS6pVMbXg7R78zaQXRs297fzD+jNI3HSwgVuMJqfldTUKMSKyjBaA25/PkzCExq/KZ1anLyeDx9Ek/tiQP8RiDPKZfmgs1ya1rLtBIcTzRL8hntm2WkPXntreULxqQxi9g1x3KEfR1ygkkcsKvEdoRlu/FvTZ0GxALxFPe8ClK1IUBbyvkQYM5BRf2hRRm23Gb7lYVG6jxNoc01jjzVUZ7TBEQnZioE3T4Y6uvk35Hg6g==; 5:OlmEPl9T+gYp+vz+S0XUq0T5TA+fiu/3khlfKi08yQyt24qfxivHwXHe2N5ZeWUUMwYuPytNq/y4/lOlo2R7xNmbVt8q/qZzmP7DN33J0H7rAQR+pNEDn8P9k83wTVUpO/2xmxPiJP6IxiOayh8pIZAmElxBEWasB1LiEc79/Q5mo2FnB889tvoPHc9b2yqr0cM2h6AhlMWz2d7s/uSb0A==; 7:QZh1PU8jYWA7uFqxtCh5QsyCnhjUeJUViQYlTgfK47k44hezWAWvGqpLdl3d/IWyDpeHCP8anoP6fJ0gxCfceEOz5IvXVWiLnxTIZC05K9YHHYGaHPtB0CA0RxLDEGLsVcV30KHW6CjxyUcdMiN4eA== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 02e5c3db-9029-48d9-1d05-08d681d83dfa x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(7021145)(8989299)(5600110)(711020)(4605077)(4534185)(7022145)(4603075)(4627221)(201702281549075)(8990200)(7048125)(7024125)(7027125)(7023125)(2017052603328)(7153060)(7193020); SRVR:DB6P190MB0263; x-ms-traffictypediagnostic: DB6P190MB0263: x-microsoft-antispam-prvs: x-forefront-prvs: 0927AA37C7 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(346002)(376002)(136003)(39830400003)(366004)(189003)(199004)(51444003)(13464003)(6436002)(6116002)(14444005)(256004)(68736007)(966005)(99286004)(8676002)(71200400001)(71190400001)(229853002)(14454004)(81156014)(8936002)(81166006)(508600001)(7696005)(53546011)(6506007)(33656002)(76176011)(74482002)(97736004)(110136005)(4326008)(106356001)(105586002)(86362001)(53936002)(486006)(2906002)(316002)(476003)(446003)(7736002)(9686003)(102836004)(55016002)(74316002)(25786009)(44832011)(305945005)(46003)(11346002)(186003)(6306002)(6246003); DIR:OUT; SFP:1102; SCL:1; SRVR:DB6P190MB0263; H:DB6P190MB0054.EURP190.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: iotconsultancy.nl does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: AbaScC28Dn3UXdCwwTVb1062NB5jEWuj0uWvNrCR/H3CJhPDF3/CkM1YpHK+sHObNgxXKbDtnzDP3ih3FokYke7ZB0PFrhmOytBF/QTcOy1RB0tgHho3ZJ1I/iNsMyEb30L/nN0VFWERqTsZZL4Yx+OFbtjHXHOEPYcpSJInyNiBlSdT5KSdt7JX0JC7lmeB5/Tn331KBjkY1F2abc5RpgdYjqqARYOxxzCgkgZa5qBNoTSl9eX3AOQ2K6EDr9epo0O43K8F9U0re6NJ97OHZK6yF3L9QS+g7uuwQcQavJMGnB8x4Hx8/solNo8IQhTy6sCnCX66x3jabxHxKZZ0s0T8dneOXRc4f64iD+r8U244eB8gZjkp5kKuJLD3NifTNMzfmuiRjoNEmE3nsat04Hpz/+dA7+CC+245c2t88Fs= 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: 02e5c3db-9029-48d9-1d05-08d681d83dfa X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jan 2019 08:45:07.0036 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 58bbf628-15d2-46bc-820b-863b6774d44b X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6P190MB0263 Archived-At: Subject: Re: [Ace] WGLC for draft-ietf-ace-coap-est - optimization for embedded devices 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, 24 Jan 2019 08:45:16 -0000 PiBUaGVyZSBpcyBubyBzaWduYXR1cmUgZm9yIHRoaXMgQ01TIHNpZ25lZCBtZXNzYWdlIGZvcm1h dC4gIEl0IG9ubHkgY29udGFpbnMgdGhlIGNlcnRpZmljYXRlcyBhbmQgQ1JMcyB0aGF0IGFyZSBw YXNzZWQgYmFjay4gIEkgd291bGQgc3RpbGwgdGhpbmsgdGhhdCB0aGlzIGlzIGEgZmluZSBpZGVh IGFzIGxvbmcgYXMgeW91IGFyZSBvbmx5IGdvaW5nIHRvIHJldHVybiB0aGUgbGVhZiBjZXJ0aWZp Y2F0ZSBhbmQgbm90IHJldHVybmluZyBhIGJhZyBvZiBjZXJ0aWZpY2F0ZXMgb3IgYW55IENSTHMu DQoNClRoYXQncyByaWdodCwgb25seSB0aGUgbGVhZiBjZXJ0aWZpY2F0ZSBpcyByZXR1cm5lZCBh bmQgbm8gQ1JMczsgaW4gdGhpcyBlbWJlZGRlZCBjYXNlLiBBbnkgb3RoZXIgcmVxdWlyZWQgY2Vy dGlmaWNhdGVzIGFyZSBhbHJlYWR5IG9idGFpbmVkIGZyb20gdGhlIHByaW9yIERUTFMgaGFuZHNo YWtlIHByb2Nlc3MuDQpJIGFncmVlIHRoYXQgdXNpbmcgZHJhZnQtYmlya2hvbHotY29yZS1jb2lk LTAxIGNvdWxkIGJlIHVzZWQgaW4gdGhlIGZ1dHVyZSBhcyBhbiBhbHRlcm5hdGl2ZSBmb3JtYXQg aW5zdGVhZCBvZiBhbiBYLjUwOSBjZXJ0aWZpY2F0ZS4gSWRlYWxseSwgaXQgd291bGQgYmVjb21l IGFuIHVwZGF0ZSBvZiBSRkMtRVNULW92ZXItY29hcHMgYW5kIGFuIGVucm9sbGluZyBjbGllbnQg Y2FuIGluZGljYXRlIGl0IHVzZXMgdGhlIG5ldyBmb3JtYXRzIGJ5IHVzaW5nIGUuZy4gQ29BUCBD b250ZW50LUZvcm1hdCBhbmQgQWNjZXB0IE9wdGlvbnMsIG9yIGJ5IGRpZmZlcmVudCBVUkkgcGF0 aHMuIA0KDQpCZXN0IHJlZ2FyZHMNCkVza28NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N CkZyb206IEppbSBTY2hhYWQgPGlldGZAYXVndXN0Y2VsbGFycy5jb20+IA0KU2VudDogVGh1cnNk YXksIEphbnVhcnkgMjQsIDIwMTkgMDY6MDUNClRvOiAnTWljaGFlbCBSaWNoYXJkc29uJyA8bWNy QHNhbmRlbG1hbi5jYT47IEVza28gRGlqayA8ZXNrby5kaWprQGlvdGNvbnN1bHRhbmN5Lm5sPg0K Q2M6IGFjZUBpZXRmLm9yZw0KU3ViamVjdDogUkU6IFtBY2VdIFdHTEMgZm9yIGRyYWZ0LWlldGYt YWNlLWNvYXAtZXN0IC0gb3B0aW1pemF0aW9uIGZvciBlbWJlZGRlZCBkZXZpY2VzDQoNCg0KDQo+ IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEFjZSA8YWNlLWJvdW5jZXNAaWV0 Zi5vcmc+IE9uIEJlaGFsZiBPZiBNaWNoYWVsIFJpY2hhcmRzb24NCj4gU2VudDogV2VkbmVzZGF5 LCBKYW51YXJ5IDIzLCAyMDE5IDY6MjcgUE0NCj4gVG86IEVza28gRGlqayA8ZXNrby5kaWprQGlv dGNvbnN1bHRhbmN5Lm5sPg0KPiBDYzogYWNlQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbQWNl XSBXR0xDIGZvciBkcmFmdC1pZXRmLWFjZS1jb2FwLWVzdCAtIG9wdGltaXphdGlvbiBmb3IgDQo+ IGVtYmVkZGVkIGRldmljZXMNCj4gDQo+IA0KPiBFc2tvIERpamsgPGVza28uZGlqa0Bpb3Rjb25z dWx0YW5jeS5ubD4gd3JvdGU6DQo+ICAgICA+IE15IG1haW4gY29tbWVudCBvbiB0aGlzIGRyYWZ0 IGlzIGJhc2VkIG9uIHJlY2VudCBleHBlcmllbmNlIHdpdGggYW4NCj4gICAgID4gZW1iZWRkZWQg aW1wbGVtZW50YXRpb24uIEluIHRoZSBkcmFmdCwgdGhlIGNvbnRlbnQgZm9ybWF0DQo+ICAgICA+ ICJhcHBsaWNhdGlvbi9wa2NzNy1taW1lO3NtaW1lLXR5cGU9Y2VydHMtb25seSIgaXMgdXNlZCB0 byANCj4gdHJhbnNwb3J0DQphDQo+ICAgICA+IHNpbmdsZSBjZXJ0aWZpY2F0ZSBiYWNrIHRvIHRo ZSBjbGllbnQuIEhvd2V2ZXIsIGluIHRoZSBlbWJlZGRlZA0KPiAgICAgPiBpbXBsZW1lbnRhdGlv biBjcnlwdG8gbGlicmFyeSB0aGVyZSBpcyBubyBzdXBwb3J0IGZvciBwYXJzaW5nIHRoaXMNCj4g ICAgID4gZm9ybWF0LCBidXQgdGhlcmUgaXMgc3VwcG9ydCBmb3IgcGFyc2luZyBYLjUwOXYzDQo+ ICAgICA+IChhcHBsaWNhdGlvbi9wa2l4LWNlcnQpLiBTZWUNCj4gICAgID4gZS5nLiBodHRwczov L3Rscy5tYmVkLm9yZy9hcGkvZ3JvdXBfX3g1MDlfX21vZHVsZS5odG1sIGZvciBhbiANCj4gZW1i ZWRkZWQNCj4gICAgID4gQVBJIHRoYXQgY2FuIHBhcnNlIENTUiBhbmQgY2VydHMsIGJ1dCBub3Qg UEtDUyM3Lg0KPiANCj4gICAgID4gVGhlcmVmb3JlIHRoZSBYLjUwOSBmb3JtYXQgc2VlbXMgYmV0 dGVyIHRvIHVzZTsgYWxzbyBnaXZlbiB0aGF0DQo+ICAgICA+IDEpIHRoZSBzaWduaW5nIG9mIGRh dGEgdGhhdCB0aGUgUEtDUyM3IFMvTUlNRSBlbnZlbG9wZSBwcm92aWRlcyANCj4gaXMgdXNlbGVz cyBiZWNhdXNlIHRoZSBEVExTIHNlc3Npb24gaXMgYWxyZWFkeSBlbmQtdG8tZW5kIHByb3RlY3Rl ZCANCj4gYW5kIHRoZSBjZXJ0aWZpY2F0ZSBpcyBhbHJlYWR5IHNpZ25lZDsgYW5kDQoNClRoZXJl IGlzIG5vIHNpZ25hdHVyZSBmb3IgdGhpcyBDTVMgc2lnbmVkIG1lc3NhZ2UgZm9ybWF0LiAgSXQg b25seSBjb250YWlucyB0aGUgY2VydGlmaWNhdGVzIGFuZCBDUkxzIHRoYXQgYXJlIHBhc3NlZCBi YWNrLiAgSSB3b3VsZCBzdGlsbCB0aGluayB0aGF0IHRoaXMgaXMgYSBmaW5lIGlkZWEgYXMgbG9u ZyBhcyB5b3UgYXJlIG9ubHkgZ29pbmcgdG8gcmV0dXJuIHRoZSBsZWFmIGNlcnRpZmljYXRlIGFu ZCBub3QgcmV0dXJuaW5nIGEgYmFnIG9mIGNlcnRpZmljYXRlcyBvciBhbnkgQ1JMcy4NCg0KPiAg ICAgPiAyKSBSRkMgNzAzMCByZXF1aXJlcyB0aGF0IG9ubHkgb25lIGNlcnRpZmljYXRlLCB0aGUg IGdlbmVyYXRlZCANCj4gb25lLA0KaXMNCj4gICAgID4gY2FycmllZCBpbiB0aGUgL3NpbXBsZShy ZSllbnJvbGwgcmVzcG9uc2Ugc28gdGhhdCBhIGNvbnRhaW5lciBmb3JtYXQNCj4gICAgID4gZm9y IG11bHRpcGxlIGNlcnRpZmljYXRlcyBpcyBub3QgcmVhbGx5IG5lZWRlZCBoZXJlLg0KPiANCj4g ICAgID4gU28gdG8gcmVkdWNlIGNvZGUgc2l6ZSBmb3IgZW1iZWRkZWQgaW1wbGVtZW50YXRpb25z IGl0IHdvdWxkIGJlIHZlcnkNCj4gICAgID4gYmVuZWZpY2lhbCBpZiB0aGUgRVNUIFNlcnZlciB3 b3VsZCBzdXBwb3J0IGFuIGFkZGl0aW9uYWwgY29udGVudA0KPiAgICAgPiBmb3JtYXQ6DQo+ICAg ICA+IGFwcGxpY2F0aW9uL3BraXgtY2VydCAgKHNlZSBSRkMgNTI4MCkNCj4gDQo+IEkgdGhpbmsg dGhhdCB0aGlzIGlzIGEgcmVhc29uYWJsZSB0aGluZyB0byBkby4NCj4gVGhlIGNsaWVudCBjYW4g ZWFzaWx5IHNheSB3aGF0IGl0IHdhbnRzIGFuZCBJIHRoaW5rIHRoZSB0d28gZm9ybWF0cyANCj4g YXJlIHJlbGF0aXZlbHkgZWFzeSB0byBzd2FwLg0KPiANCj4gV2hhdCBhYm91dCBpZiB3ZSB3ZW50 IGZ1cnRoZXIsIGFuZCB3ZW50IHRvOg0KPiAgICAgICAgICAgICAgQ29uY2lzZSBJZGVudGl0aWVz DQo+ICAgICAgICAgICAgICBkcmFmdC1iaXJraG9sei1jb3JlLWNvaWQtMDENCg0KR2l2ZW4gdGhh dCBpdCB3b3VsZCBiZSBhIGJsb2NraW5nIGZhY3RvciwgSSB3b3VsZCB0aGluayBhYm91dCB0aGlz IGFzIG1heWJlIHNvbWV0aGluZyBpbiB0aGUgZnV0dXJlLg0KDQpKaW0NCg0KPiANCj4gLS0NCj4g XSAgICAgICAgICAgICAgIE5ldmVyIHRlbGwgbWUgdGhlIG9kZHMhICAgICAgICAgICAgICAgICB8 IGlwdjYgbWVzaA0KbmV0d29ya3MgWw0KPiBdICAgTWljaGFlbCBSaWNoYXJkc29uLCBTYW5kZWxt YW4gU29mdHdhcmUgV29ya3MgICAgICAgIHwgICAgSW9UIGFyY2hpdGVjdA0KWw0KPiBdICAgICBt Y3JAc2FuZGVsbWFuLmNhICBodHRwOi8vd3d3LnNhbmRlbG1hbi5jYS8gICAgICAgIHwgICBydWJ5 IG9uIHJhaWxzDQpbDQoNCg0K From nobody Thu Jan 24 07:59:17 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DFD7130E7B for ; Thu, 24 Jan 2019 07:59:15 -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 oF8d7_EPttrt for ; Thu, 24 Jan 2019 07:59:13 -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 1B1EB130F05 for ; Thu, 24 Jan 2019 07:59:13 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 2B28E38263; Thu, 24 Jan 2019 10:58:22 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 56D24262D; Thu, 24 Jan 2019 10:59:09 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 5525A23DB; Thu, 24 Jan 2019 10:59:09 -0500 (EST) From: Michael Richardson To: "Panos Kampanakis \(pkampana\)" , ace@ietf.org cc: Jim Schaad , "consultancy\@vanderstok.org" In-Reply-To: <0e5d254ced7242a69b4bd48a1c99442e@XCH-ALN-010.cisco.com> References: <011501d4ac3d$ab2b9650$0182c2f0$@augustcellars.com> <0e5d254ced7242a69b4bd48a1c99442e@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] FW: WGLC comments draft-ietf-ace-coap-est-07 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, 24 Jan 2019 15:59:16 -0000 --=-=-= Content-Type: text/plain https://goo.gl/LT4HYh is a diff from -06 to current. Panos has done a great job updating this according to the issues raised during the WGLC. Thank you I have re-read diffs to catch up, and have these minor author tweaks/questions. > Client authentication via DTLS Client Certificate is mandatory. I wonder if this should go into it's own section so that one can more easily say, "Please see section x.y.z" s/enrolment/enrollment/ <- use American spelling, I guess. We had both. section 6: REQ: GET /.well-known/core?rt=ace.est* I didn't know the trailing "*" was a thing. ; rt="ace.est", I guess I have to re-read the Core Link resource discovery document. Can a server respond with ; ?? it's shorter, and I think would be valid? > If > the default root resource requests fail, the client > SHOULD fall back > to doing a resource discovery. Resource discovery > SHOULD be employed > when non-default URIs (like /est or > /est/ArbitraryLabel) or ports are > supported by the server or when the > client is unaware of what EST- > coaps resources are available by the server. This implies that a server is not required to support /.well-known/est We are not clear about this. I would prefer that the server ALWAYS supports the well-known names, such that the client can skip doing resource discovery if it thinks that the extra bytes in the URL matter less than additional round trip to do discovery. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlxJ4M0ACgkQgItw+93Q 3WWrDAf/ddyZy6uHIR1rdJsK1LNXj6RN4qztTFfcKZ3qU92AlVWekWsYye30q9PT 1B1vMfjb7YnDnSp4oq3wR9vf5Qaln3zOJGtWBy+ZwwBOMyZrm1qqNxyiV4zZhyHS eRoQ79r1vsa0KaQyDRc6ecnFf033OX714TkZajyRNmNzcRJblu5naQQvz7eJ7cYj VAEyuvm37XiAkhEpbI8ybeX1eFDO0y8QLCCIkd6FcL18vicMzR9y6M+t3W9C2ht1 u14K9eBL4tigZFZtolDY0MdUXWaa2Iaxon1P+Fx6KsIGrhLfIOctN3s2QgEYAHZP esgkHqQvmTm/i64B8awVvGQwrSzgWw== =hWvM -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Jan 24 08:01:04 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 905A9130F12 for ; Thu, 24 Jan 2019 08:01:03 -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 T9h2j7hi5euv for ; Thu, 24 Jan 2019 08:01:02 -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 14E8E130F0F for ; Thu, 24 Jan 2019 08:01:02 -0800 (PST) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id 1E4DB38266; Thu, 24 Jan 2019 11:00:13 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 50461262D; Thu, 24 Jan 2019 11:01:01 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 4EDD123DB; Thu, 24 Jan 2019 11:01:01 -0500 (EST) From: Michael Richardson To: Esko Dijk cc: "ace\@ietf.org" 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: Re: [Ace] WGLC for draft-ietf-ace-coap-est - optimization for embedded devices 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, 24 Jan 2019 16:01:03 -0000 --=-=-= Content-Type: text/plain Esko Dijk wrote: > So to reduce code size for embedded implementations it would be very > beneficial if the EST Server would support an additional content > format: > application/pkix-cert (see RFC 5280) So, to implement this in the specification, we need an additional Content-Type value to be allocated. If we have WG Consensus to add this, then we can spin the document and ask for another early allocation. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlxJ4T0ACgkQgItw+93Q 3WUl2ggAo+3K18bDNeXJAvDF8qFU6bRvFgD5Yf5CFIfBK9QVTaadYXs4V6Nc5eCL L8HkIzvHE7l5PEVWnhZ6vfUpPNWb8Zvpx6Lfr7DbRlTr+8d5M5r8Vu3sPG/0fQQ4 qYtGFh2EysI0HlusKtoCkdPcW5+OdUP3WK7AX60F8en1kdeYmzkGWBL8A0OfMzea a5RrbH62n7/WjFljB070QNpo5yoaloF4qJALPIGlg4pgYfimR26+eBTJ78XVAZWd 8YaXCv99pQdI1Uxe5W8wq0xUAVKOdvdwZuZ9+JEl0QObclEVMOYHoeqMw1yxhu96 3Fv1+6QOL4gSRQfyvy+xEu5aoQ9PJw== =FpFM -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Jan 24 08:31:40 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2C91131184 for ; Thu, 24 Jan 2019 08:31:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.873 X-Spam-Level: X-Spam-Status: No, score=-7.873 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, 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=BrVRgUD9; dkim=pass (1024-bit key) header.d=ericsson.com header.b=k2XRH06Q 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 3RAF4J2cCZNd for ; Thu, 24 Jan 2019 08:31:36 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 00DD213117F for ; Thu, 24 Jan 2019 08:31:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/relaxed; q=dns/txt; i=@ericsson.com; t=1548347494; x=1550939494; 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=6XV7Zg6kvvC21J4Mi82luJ3Rw9/Oln3DCnf3iiK3lwA=; b=BrVRgUD914kgexCzHsQmVizybOdYCS6r4TfIlRwlwPeswTQEAx/oRgkNghhUm4Ts vp2Gk+Qq7DyDx18mId4jAJbRKZQncskFhP/y7YQfoN4esEfso8zlj8l2/OKBsKXh 1YwyTMDqe4tVcFjEuutvN/C48BsOjGq7H6q1shw1zTQ=; X-AuditID: c1b4fb30-f93ff7000000355c-6c-5c49e8662ba4 Received: from ESESBMB503.ericsson.se (Unknown_Domain [153.88.183.116]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id CE.EC.13660.668E94C5; Thu, 24 Jan 2019 17:31:34 +0100 (CET) Received: from ESESBMB503.ericsson.se (153.88.183.170) by ESESBMB503.ericsson.se (153.88.183.170) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Thu, 24 Jan 2019 17:31:33 +0100 Received: from EUR01-VE1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESBMB503.ericsson.se (153.88.183.170) 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; Thu, 24 Jan 2019 17:31:33 +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=6XV7Zg6kvvC21J4Mi82luJ3Rw9/Oln3DCnf3iiK3lwA=; b=k2XRH06QbOXUfLpRhicW0flk+ZNSiLsFr+gNAoCcMxioJHsqgHL0AkKBdVJfLclSwausRGsO+E64/9jdMy7xF+PI18F/iU7Ndbvekxyxp8H/BTZTOo2s+tTG7z402ejfMh4vfUe6O1li4zqdJprS5Ms/4OvLeV2Qmb+SIM1EJ1Q= Received: from DB6PR07MB4167.eurprd07.prod.outlook.com (10.168.19.153) by DB6PR07MB3110.eurprd07.prod.outlook.com (10.170.223.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1580.7; Thu, 24 Jan 2019 16:31:32 +0000 Received: from DB6PR07MB4167.eurprd07.prod.outlook.com ([fe80::a10c:961e:8639:85f4]) by DB6PR07MB4167.eurprd07.prod.outlook.com ([fe80::a10c:961e:8639:85f4%4]) with mapi id 15.20.1580.004; Thu, 24 Jan 2019 16:31:28 +0000 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Richard Barnes , Roman Danyliw CC: "secdispatch@ietf.org" , "ace@ietf.org" , Francesca Palombini , "John Mattsson" Thread-Topic: [Ace] [Secdispatch] EDHOC Thread-Index: AQHUou5Zx1xiDx+jgESY4I5hUyszWqWcqBGAgAINKACAFqIAAIAACQQAgAanMgCAASTpAIABoxCA Date: Thu, 24 Jan 2019 16:31:28 +0000 Message-ID: <05C8AB73-EFD1-4AC8-A795-D3624153F4D2@ericsson.com> References: <79FD6563-8ADA-4D73-B8D5-C3D70604CD76@gmail.com> <47F03C99-68C1-4ADB-873D-F01987D66849@ipv.sx> <20190118172714.GJ81907@kduck.mit.edu> <359EC4B99E040048A7131E0F4E113AFC0185795C45@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.15.0.190115 authentication-results: spf=none (sender IP is ) smtp.mailfrom=goran.selander@ericsson.com; x-originating-ip: [192.176.1.89] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB6PR07MB3110; 6:MoYmL+1rJL1Ok5ij6OlexV+V5RQpWTT4a1CTBe60Jz3TFNdnicVa7ikr4PLL0hrB8aQVl+sRTfrYAKdjz7cGMq0z9LZy56x2xZ1KXhfZptDZHn6kppCenVj7oxpGLGE9vDwFYAqF3Fb3oKWgs0zvxS6zZMx3EGWEzbaGf3JVn+4bRyemaANUgbFuHdujSV1ZQjHshKLgM9BESHwCCjpTDBrMp9H5JOQAYx61LzQ+aZt+hRONwVlOyvZS/22cCT1BbiW7T7chnltp1SrLey3Lwt6t7FstO6SgQ3R9z+JCa1yWKxxtSfpbMf7jdBz1sQG/oY/38W/lwvuDh0bqIHJiupq14pkA29Rb5sUJc1QrfZdUqRkMLpMPfYCECGSDXIkOQV0W/i0OFmOnv12FRltAMOLdO1fS2iWHcJQdpew7UFZRznw/V7mmZc95vdPfGCKIe6thLQyVLtrRO1NyGj+aOQ==; 5:y3FuSbH/Uv3Gw0Xe/9b2WQgjJ9/nzUAkvCH871gdm5c+EhuTIHS3OO+VA0ycwV5f7QXuC8tKShnf/R4msfy204LrF1lgzKd7PvxiYgk/+YrTIeE1L/ZnlqVTOLjz89F8FUoUYnQTDZFKnMWf1SM4iwoOm78XnU3608yyLbYuyKIXydUp1p2tPqdDi9UrWb+JrX/0R9HBpJycmmrTbjsR3w==; 7:9kkhmsP+JllkL/iqDXX8u8hXsqCx0kxfvh8Rl5a6Of+qMADOdausHENU4EsipnTMZNWu3JoIIFeUaDtBp/MIDwsFzdIoZZ6+dF1sCplmZ56bVnzdFBktxBWyQqT5U8JvCH8d9Ui7KZccBMFywWg47w== x-ms-exchange-antispam-srfa-diagnostics: SOS;SOR; x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10009020)(346002)(376002)(366004)(396003)(39860400002)(136003)(189003)(199004)(4326008)(102836004)(86362001)(71200400001)(6506007)(54906003)(71190400001)(26005)(478600001)(58126008)(110136005)(99286004)(186003)(476003)(81156014)(81166006)(8676002)(486006)(25786009)(11346002)(83716004)(14454004)(2616005)(446003)(256004)(14444005)(107886003)(66574012)(36756003)(6246003)(76176011)(316002)(53936002)(85182001)(2906002)(33656002)(6486002)(7736002)(66066001)(229853002)(85202003)(68736007)(106356001)(105586002)(6306002)(6512007)(54896002)(93886005)(3846002)(6116002)(97736004)(8936002)(82746002)(6436002); DIR:OUT; SFP:1101; SCL:1; SRVR:DB6PR07MB3110; H:DB6PR07MB4167.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; x-ms-office365-filtering-correlation-id: fa6046f1-fc21-4072-68e7-08d682196466 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605077)(2017052603328)(7153060)(7193020); SRVR:DB6PR07MB3110; x-ms-traffictypediagnostic: DB6PR07MB3110: x-microsoft-antispam-prvs: x-forefront-prvs: 0927AA37C7 received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 9tYvHFDF+eai9d0iaymT3vV8ai3YOwnf1LHlZOz7gcMaoRArHHwuZT/DvjVOYEEMlkWUT1j4PejpOQ7HE4CA2+DB/tfvMdof/zR2xLSALkEsYFae4GjybA8UWiOKRpyhAYhQhMCV0obsKJmc+4a4hlN6csAj7+pmWtSI5pOsXQKOLGizZWu1iBrLyyTRaXYPnCQ93Nl+R8mLEoWjuy12xxhR/Ziab3a4R9B0nNOMfGuKzt743JP8/hqmTfADQa+DT2ArTrG4OuNUSnhkrQW9nz+3ktya+LnkphHA9stQiZCFbW9x6sIuhK2kYNQf1Raf3rfgQlqCKQfqM94ioKjlttW4qCbHHa40L6ApeMQsEI73ZFJNM5DsU56LwYRKrEwZDjckWNdn2ZcOomSkfwQdNEuPOUf3fqsYioopYyT7hDA= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_05C8AB73EFD14AC8A795D3624153F4D2ericssoncom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: fa6046f1-fc21-4072-68e7-08d682196466 X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jan 2019 16:31:28.8139 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR07MB3110 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02Sa0iTURjHOe/7bns3HB2XuodpZQOtpLzRByHtAmVTCiz8ELLKqW9zeN+W lyKamiIqYl5AR6bmKEtNLSExU1NRjMK8lOaNtJmXGQnJtFLJ7V3gt99z/v/n+Z/ncGhS1MeR 0Kp4LaOOV8RKuQKq/Mor7bEbi0Fy797vPL91cz7p9yub61daEOBX/3mMc5qSlTVdkBkMvwlZ cbOeCiHDBP5RTKwqmVF7nQwXRI+3N5GJvflEqslYT+nQ6ywiF/FpwMdh688cykUCWoR7EZjK KnlsYUawNjVoUwwEmGv6KEtB4UIS8rOrSVYpImC1Lt1WzCFIH16iLJO5+Cx81c1ZUxxwANwz LSELk7gNwUvdZQvvxe6QMfqeYj2H4PFKDZflMCjQP7Iyhd2gYcVIWliIT8FUYweHDdOR0Dpf Zw3g40tgvv/JOghhJ1h/V0+wYWKYMFbaVsVgaB8kWXaEpW/bHAs7Yi/IWt/gsL3XIOO5jst6 XKG/9oeN98FwZZ71MQBn8GC4ZZvHCj7Q/7STZAU9F7qaxziscBFWJmoJVviCYKaoziZ4wOCq 3tYdA+mjnagQeet33ZblSCiZKebprWvbw0C5kdIjeuf8CDS2ebGWg1CSN8tj+TBkPaiwsQwW NjqI3Z4qRD9DjhpGExGn9PX1ZNSqSI0mId4zntG+QDu/623LX+9WtLRwphthGknthBWzQXIR R5GsSYvrRkCTUgfhuaFAuUgYpUi7xagTrqtvxjKabuRMU1KxcFNkLxdhpULLxDBMIqP+rxI0 X6JDYmnP4uZyEGWKrpKIzKZccYiz0+ik3bRvQsqTHBwefLU/UNv8UXICzfg0jIxV7gnLpENv 33no0+EkOzrg/ka1vNYuKBCfbwoolfMpZVmK0jV1LSknJLM6yT+4xqXhbtdkj5v3xHTeB+74 T5ekWvGBjtChoeQeZsS4NR/RuH9ESmmiFT4epFqj+AcnNIg8WQMAAA== Archived-At: Subject: Re: [Ace] [Secdispatch] EDHOC 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, 24 Jan 2019 16:31:40 -0000 --_000_05C8AB73EFD14AC8A795D3624153F4D2ericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUmljaGFyZCwgUm9tYW4sIGFsbA0KDQoNClRoYW5rcyBmb3Iga2luZCB3ZWxjb21lIGFuZCBm b3IgcHJvZ3Jlc3NpbmcgdGhlIGRpc2N1c3Npb24uIEFwb2xvZ2llcyBmb3IgYSBsb25nIGVtYWls Lg0KDQpGcm9tOiBSaWNoYXJkIEJhcm5lcyA8cmxiQGlwdi5zeD4NCg0KDQpTdW1taW5nIHVwIHdo ZXJlIEkgYmVsaWV2ZSB0aGUgY29udmVyc2F0aW9uIHN0YW5kcyBub3csIGl0IHNlZW1zIGxpa2Ug d2hhdCBmb2xrcyBhcmUgYXNraW5nIGZvciBpcyBlaXRoZXI6DQoNCg0KICAxLiAgQW4gYW5hbHlz aXMgdGhhdCBzaG93cyB0aGF0IEVESE9DIGlzIGVxdWl2YWxlbnQgdG8gYW4gZXhpc3RpbmcgQUtF IChlLmcuLCBJS0Ugb3IgVExTKSwgb3INCg0KMi4gQW4gYXJndW1lbnQgdGhhdCBhIG5ldyBBS0Ug aXMgbmVjZXNzYXJ5ICh2cy4gYSByZS1lbmNvZGluZyBvZiBhbiBleGlzdGluZyBBS0UpDQoNCkfD tnJhbiBldCBhbDogRG8geW91IGhhdmUgdGhvdWdodHMgb24gdGhvc2UgcG9pbnRzPw0KDQpZZXMu IEnigJlsbCBnZXQgYmFjayB0byB0aGlzIGxhdGVyIGluIHRoaXMgZW1haWwuDQoNCkl0IHNlZW1z IGxpa2UgaXQgY291bGQgYmUgYSBwcm9kdWN0aXZlIHVzZSBvZiBhbiBob3VyIG9yIHR3byBvZiB2 aXJ0dWFsIGludGVyaW0gdGltZSB0byBoZWxwIHRoZSBncm91cCB1bmRlcnN0YW5kIG9uZSBvZiB0 aG9zZSBsaW5lcyBvZiBhcmd1bWVudC4NCg0KQWdyZWUuDQoNCi0tUmljaGFyZA0KDQoNCkFzIHJl cXVlc3RlZCBpbiBhIHByZXZpb3VzIGVtYWlsLCBoZXJlIGlzIGEgYmFja2dyb3VuZC4NCg0KDQoN ClRoZSB3b3JrIG9uIEVESE9DIGlzIG1vdGl2YXRlZCBieSB0aGUgbmVlZCBmb3IgYW4gYXV0aGVu dGljYXRpb24gYW5kIGtleSBleGNoYW5nZSBwcm90b2NvbCBmb3IgT1NDT1JFIChkcmFmdC1pZXRm LWNvcmUtb2JqZWN0LXNlY3VyaXR5KSBvcHRpbWl6ZWQgZm9yIGNvbnN0cmFpbmVkLW5vZGUgbmV0 d29ya3MgKFJGQyA3MjI4KS4gT1NDT1JFIGlzIGFwcGxpZWQgd2l0aGluIHRoZSBJRVRGLCBlLmcu IGluIDZUaVNDSCBtaW5pbWFsIHNlY3VyaXR5IChkcmFmdC1pZXRmLTZ0aXNjaC1taW5pbWFsLXNl Y3VyaXR5KSwgYnV0IGFsc28gcmVxdWVzdGVkIGJ5IG90aGVyIFNET3MgYW5kIGluZHVzdHJ5IGZv cmEgc3VjaCBhcyBPTUEgU3BlY3dvcmtzLCBPcGVuIENvbm5lY3Rpdml0eSBGb3VuZGF0aW9uIGFu ZCBGYWlyaGFpciBBbGxpYW5jZS4gVGhlIHByb3BlcnRpZXMgb2YgT1NDT1JFIG1vdGl2YXRpbmcg aXRzIHVzZSBpbmNsdWRlOiBzdXBwb3J0IGZvciBDb0FQIGZvcndhcmQgcHJveGllcywgc3VwcG9y dCBmb3IgY2hhbmdlIG9mIHVuZGVybHlpbmcgdHJhbnNwb3J0cyBpbmNsdWRpbmcgbm9uLUlQLCBs b3cgb3ZlcmhlYWQsIGxvdyBhZGRpdGlvbmFsIGZvb3RwcmludCBhbmQgbWVtb3J5IHRvIGV4aXN0 aW5nIENvQVAgaW1wbGVtZW50YXRpb25zLCBzdXBwb3J0IGZvciBtdWx0aWNhc3Qgc2VjdXJpdHks IHNlY3VyaXR5IGZvciBlbmQtdG8tZW5kIFJFU1QuDQoNCg0KDQpHaXZlbiB0aGUgbGFyZ2UgaW50 ZXJlc3QgaW4gT1NDT1JFIGFscmVhZHkgYmVmb3JlIGl0IGhhcyBiZWNvbWUgYW4gUkZDIHdlIGFu dGljaXBhdGUgYSB3aWRlIHJhbmdlIG9mIGRlcGxveW1lbnRzLiBGb3IgZXhhbXBsZSwgd2Ugc2Vl IGFuIGludGVyZXN0IGZvciBPU0NPUkUgaW4gQ2VsbHVsYXIgSW9UIHdpdGggdHJhZmZpYyBydW5u aW5nIG92ZXIgdGhlIGNlbGx1bGFyIGFpciBpbnRlcmZhY2UgY29udHJvbCBjaGFubmVsLCB3aGVy ZSB3ZSBjYW4gaGF2ZSBlbmQtdG8tZW5kIENvQVAsIGJ1dCBub3QgbmVjZXNzYXJpbHkgZW5kLXRv LWVuZCBJUCBiZXR3ZWVuIGFuIGFwcGxpY2F0aW9uIHNlcnZlciBhbmQgYSBjZWxsdWxhciBkZXZp Y2UuIE9yIGJldHdlZW4gYW4gYXBwbGljYXRpb24gc2VydmVyIGFuZCBhIGRldmljZSBiZWhpbmQg YSBjZWxsdWxhciBnYXRld2F5LiBDb21wYXJpbmcganVzdCB0aGVzZSB0d28gY2FzZXMsIHRoZSBk aWZmZXJlbmNlIGluIGNhcGFiaWxpdGllcyBvZiB0aGUgZGV2aWNlcyBjYW4gYmUgc2lnbmlmaWNh bnQgd2hpY2ggbWFrZXMgaXQgZGlmZmljdWx0IHRvIHBvaW50IGF0IHNvbWUgc29ydCBvZiDigJxy ZWZlcmVuY2UgZGV2aWNlc+KAnSBmb3IgYmVuY2htYXJraW5nLg0KDQoNCg0KSW4gb3JkZXIgdG8g c3VwcG9ydCB0aGUgbG93IGVuZCB1c2UgY2FzZXMgdGhlIEFLRSBtdXN0IGJlIHBlcmZvcm1hbnQg aW4gbG93IGJhbmR3aWR0aCBkZXBsb3ltZW50cyB3aXRoIGJhdHRlcnkgcG93ZXJlZCBkZXZpY2Vz IHJlc3RyaWN0ZWQgaW4gUkFNIGFuZCBST00uIE1lc3NhZ2Ugc2l6ZXMgYW5kIHJvdW5kIHRyaXBz IGhhdmUgYSBkaXJlY3QgaW1wYWN0IG9uIGxhdGVuY3ksIHBvd2VyIGNvbnN1bXB0aW9uIGFuZCBi YXR0ZXJ5IGxpZmV0aW1lLCBhbmQgY2FuIGJlIGNhbGN1bGF0ZWQgd2hpY2ggaXMgdGhlIHJlYXNv biBmb3IgdGhpcyBiZWluZyBhIGNvbW1vbmx5IHVzZWQgbWV0cmljLiBXaGlsZSBpdCBtYXkgYmUg bW9yZSBkaWZmaWN1bHQgdG8gY29tcGFyZSBtZW1vcnkgYW5kIHN0b3JhZ2UgcmVxdWlyZW1lbnRz LCB0aGUgYWJpbGl0eSB0byByZXVzZSBleGlzdGluZyBjb2RlIGlzIGFuIGltcG9ydGFudCBpbmRp Y2F0aW9uLiBJZiBhIGRldmljZSBjYW4gc3VwcG9ydCBhIENvQVAgc3RhY2sgKGluIHRoZSBzZW5z ZSBvZiBtZW1vcnkgYW5kIGZsYXNoLCBldGMpIGl0IGlzIGV4cGVjdGVkIHRvIGFsc28gYmUgYWJs ZSB0byBzdXBwb3J0IE9TQ09SRS4gU2ltaWxhcmx5LCBpdCBpcyBkZXNpcmFibGUgdGhhdCBhIGRl dmljZSB3aXRoIENvQVAgYW5kIE9TQ09SRSBpbXBsZW1lbnRlZCBzaG91bGQgYmUgYWJsZSB0byBz dXBwb3J0IGFuIGFkZGl0aW9uYWwgQUtFLiBDb25zaWRlcmluZyB0aGF0IEVESE9DIHJldXNlcyBD Qk9SIGFuZCBDT1NFIHByaW1pdGl2ZXMgZnJvbSBPU0NPUkUgdGhlIGFkZGl0aW9uYWwgY29kZSBm b3IgRURIT0MgY2FuIGJlIHZlcnkgbGltaXRlZC4NCg0KDQoNCkZyb20gYSBzZWN1cml0eSBwb2lu dCBvZiB2aWV3IE9TQ09SRSByZXF1aXJlcyB0aGF0IHRoZSBlbmRwb2ludHMgaGF2ZSBhZ3JlZWQg b24gYSBNYXN0ZXIgU2VjcmV0IHdpdGggYSBnb29kIGFtb3VudCBvZiByYW5kb21uZXNzLCBhbmQg ZWFjaCBvdGhlcuKAmXMgU2VuZGVyIElEcywgYW5kIHRob3NlIG11c3QgYmUgZGlmZmVyZW50IGZv ciBhIGdpdmVuIE1hc3RlciBTZWNyZXQuDQoNCg0KDQpOb3cgcmV0dXJuaW5nIHRvIHRoZSBxdWVz dGlvbnMuDQoNCg0KICAxLiAgQW4gYW5hbHlzaXMgdGhhdCBzaG93cyB0aGF0IEVESE9DIGlzIGVx dWl2YWxlbnQgdG8gYW4gZXhpc3RpbmcgQUtFIChlLmcuLCBJS0Ugb3IgVExTKQ0KDQoNCkNvbnNp ZGVyaW5nIEVESE9DIGlzIGEgbmV3IHByb3RvY29sIGl0IHNob3VsZCBiZSB0aG9yb3VnaGx5IGFu YWx5c2VkIGFuZCB2ZXJpZmllZCBhZ2FpbnN0IGFsbCBjdXJyZW50bHkga25vd24gaXNzdWVzIG9m IEFLRXMuIFJvbWFuIHNlbnQgYSBtYWlsIHRvIHRoZSBzZWNkaXNwYXRjaCBsaXN0IHJlZmVyZW5j aW5nIGEgcGFwZXIgcHJlc2VudGVkIGF0IFNTUiAyMDE4IHdoaWNoIGNvdWxkIGJlIHVzZWQgYXMg YSBzdGFydGluZyBwb2ludC4gSG93IGRvIGZvbGtzIHdhbnQgdG8gZGlnZXN0IHRoaXM6IERvIHRo ZXkgd2FudCB0byBzdHVkeSB0aGUgbW9kZWwgdGhlbXNlbHZlcyBvciBzaG91bGQgd2UgYXNrIHRo ZSBhdXRob3JzIGlmIHRoZXkgY291bGQgcHJlc2VudCB0aGVpciB3b3JrIGF0IHRoZSBpbnRlcmlt Pw0KDQoyLiBBbiBhcmd1bWVudCB0aGF0IGEgbmV3IEFLRSBpcyBuZWNlc3NhcnkgKHZzLiBhIHJl LWVuY29kaW5nIG9mIGFuIGV4aXN0aW5nIEFLRSkNCg0KDQoNCldlIGhhdmUgZG9uZSB0aGlzIGNv bXBhcmlzb24gd2l0aCBUTFMvRFRMUyBmb3Igc29tZSB0aW1lIG5vdywgYW5kIHdoYXQgb25jZSBz ZWVtZWQgbGlrZSBhIHJlYXNvbmFibGUgcXVlc3Rpb24gaGFzIHR1cm5lZCBvdXQgdG8gYmUgbmV2 ZXIgZW5kaW5nIGV4ZXJjaXNlLiBJIGRvIG5vdCB3YW50IHRvIGdldCBpbnRvIElFVEYgYXJjaGVv bG9neSBidXQgZm9yIHRob3NlIHdobyBoYXZlIG5vdCBmb2xsb3dlZCB0aGUgZGlzY3Vzc2lvbiBz b21lIGRhdGEgcG9pbnRzIGNvdWxkIGJlIHJlbGV2YW50Lg0KDQoNCg0KTm90IGxvbmcgYWdvLCB0 aGUgZGVzaWduIG9mIHNlY3VyaXR5IHByb3RvY29scyBkaWQgbm90IHRha2UgaW50byBhY2NvdW50 IGNvbnN0cmFpbmVkIElvVCBkZXZpY2VzLiBXaXRoIE9TQ09SRSB3ZSBzaG93ZWQgdGhhdCB0aGUg bWVzc2FnZSBvdmVyaGVhZCBjb3VsZCBiZSByZWR1Y2VkIGJ5IGEgZmFjdG9yIDMgY29tcGFyZWQg dG8gRFRMUyAxLjIgcmVjb3Jkcy4gQmVmb3JlIHRoaXMgY29tcGFyaXNvbiBpdCB3YXMgYmVsaWV2 ZWQgdGhhdCB0aGUgcmVjb3JkIGxheWVyIHdhcyBwZXJmb3JtaW5nIHdlbGwsIHRoZW4gdGhlIGRp ZmZlcmVuY2UgaW4gb3ZlcmhlYWQgd2FzIGNoYXJhY3Rlcml6ZWQgYXMgaW5zaWduaWZpY2FudCwg YW5kIHRoZW4gZmluYWxseSBhIGNvbXBhY3QgZm9ybWF0IHdhcyBkZXNpZ25lZCBmb3IgRFRMUyAx LjMuDQoNCg0KDQpXaXRoIEVESE9DIHdlIHNob3dlZCB0aGF0IHRoZSBtZXNzYWdlIG92ZXJoZWFk IG9mIHRoZSBrZXkgZXhjaGFuZ2UgY2FuIGJlIHJlZHVjZWQgd2l0aCB1cCB0byBhIGZhY3RvciA0 IGNvbXBhcmVkIHRvIHRoZSBjdXJyZW50IHZlcnNpb24gb2YgRFRMUyAxLjMgKHNlZSBBcHBlbmRp eCBFIGluIEVESE9DKS4gQmVmb3JlIHRoaXMgZXhlcmNpc2UgaXQgd2FzIGJlbGlldmVkIHRoYXQg dGhlIFRMUy9EVExTIGhhbmRzaGFrZSB3YXMgcGVyZm9ybWluZyB3ZWxsLCB0aGVuIHRoZSBkaWZm ZXJlbmNlIGluIG92ZXJoZWFkIHdhcyBjaGFyYWN0ZXJpemVkIGFzIGluc2lnbmlmaWNhbnQsIGFu ZCBub3cgdGhlIGRpc2N1c3Npb24gaGFzIHNoaWZ0ZWQgdG8gZG93bnNpemluZyB0aGUgVExTIGhh bmRzaGFrZSBvciBvdGhlciBwcm90b2NvbC4NCg0KDQoNCldlIGFyZSBub3QgYWdhaW5zdCBvcHRp bWl6YXRpb25zIHRvIHRoZSBUTFMgaGFuZHNoYWtlLCBqdXN0IGFzIHdlIHdlbGNvbWUgdGhlIG1v cmUgb3B0aW1hbCBEVExTIDEuMyByZWNvcmRzLiBCdXQgVExTIHdhcyBub3QgZGVzaWduZWQgdG8g YmUgYW4gQUtFIGZvciBPU0NPUkUgb3B0aW1pemVkIGZvciBjb25zdHJhaW5lZCBlbnZpcm9ubWVu dHMuIEFzIEkgcmVtZW1iZXIsIG9wdGltaXppbmcgZm9yIG1lc3NhZ2Ugb3ZlcmhlYWQgd2FzIGFu IGV4cGxpY2l0IG5vbi1yZXF1aXJlbWVudCBvZiBUTFMgMS4zLiBSZXZlcnRpbmcgdGhvc2UgZGVz aWduIGRlY2lzaW9ucyBzZWVtcyBsaWtlIHRoZSB3cm9uZyB3YXkgdG8gZ286IE9uZSByZWFzb24g dG8gdXNlIFRMUyB3b3VsZCBiZSB0byByZXVzZSBhbiBleGlzdGluZyBpbXBsZW1lbnRhdGlvbi4g QnV0IGV4aXN0aW5nIFRMUyBpbXBsZW1lbnRhdGlvbiB3b3VsZCBtb3N0IGxpa2VseSBub3QgY29t cGFyZSBmYXZvcmFibHkgaW4gdGVybXMgb2YgY29kZSBzaXplIGFuZCBSQU0uIEFkZGluZyBjb2Rl IGZvciBjb21wcmVzc2lvbiBvciByZS1lbmNvZGluZyBvZiB0aGUgbWVzc2FnZXMgd291bGQgYWRk IHRvIHRoYXQuIFJlLXNwZWNpZnlpbmcgdGhlIHByb3RvY29sIHdpdGggdGhlIG5ldyBlbmNvZGlu ZyBtYXkgcmVxdWlyZSBhIG5ldyBmb3JtYWwgdmVyaWZpY2F0aW9uLiBUbyBtYWtlIGEgbW9yZSBj b21wYWN0IGNvZGUgYW5kIHByb2Nlc3NpbmcgbWF5IGludm9sdmUgdHdvIGluY29tcGF0aWJsZSBt ZXNzYWdlIGZvcm1hdHMgb2YgVExTIGRlcGVuZGluZyBvbiB3aGF0IGlzIGJlaW5nIHNpZ25lZC4g TmV3IGltcGxlbWVudGF0aW9ucyB3b3VsZCBiZSBuZWVkZWQuDQoNCg0KV2UgdGhpbmsgd2UgaGF2 ZSBkb25lIG91ciBwYXJ0IG9mIHRoZSBjb21wYXJpc29uIGV4ZXJjaXNlIGFuZCB0aGF0IHRoZSBi dXJkZW4gb2YgcHJvb2Ygc2hvdWxkIG5vdyBiZSByZXZlcnNlZC4gQ291bGQgd2UgYXNrIHRob3Nl IHRoYXQgY2xhaW0gdG8gaGF2ZSBhIG1vcmUgcGVyZm9ybWFudCBrZXkgZXhjaGFuZ2UgcHJvdG9j b2wgZm9yIE9TQ09SRSBhbmQgYXJlIHByZXBhcmVkIHRvIGRvIHRoZSB3b3JrIHRvIG1ha2UgdGhh dCBwbGF1c2libGUgYW5kIHByb3ZpZGUgdGhlIG51bWJlcnM/IFRvIGJlIGNsZWFyOiBpZiB0aGVy ZSBpcyBhbm90aGVyIGtleSBleGNoYW5nZSBwcm90b2NvbCBzdWl0YWJsZSBmb3IgT1NDT1JFIHdo aWNoIG91dHBlcmZvcm1zIEVESE9DIGluIGNvbnN0cmFpbmVkIGNoYXJhY3RlcmlzdGljcyBhbmQg dGhlbiB3ZSBhcmUgdmVyeSBpbnRlcmVzdGVkLg0KDQpBbmQgYWdhaW4sIHdpdGggdGhlIHN0YXRl bWVudHMgaW4gdGhpcyBtYWlsIHdlIG5laXRoZXIgd2FudCB0byBiZWxpdHRsZSB0aGUgY29uc2lk ZXJhYmxlIGVmZm9ydCBtYWRlIG9uIGZvcm1hbCB2ZXJpZmljYXRpb24sIG5vciBjbGFpbSB0aGF0 IERUTFMgaXMgbm90IGZpdCBmb3IgSW9UIGRlcGxveW1lbnRzLiBJdCBpcyBhbiBpbXBvcnRhbnQg aGFtbWVyIGluIG91ciBJb1Qgc2VjdXJpdHkgdG9vbGJveCwgYnV0IGF0IHRoZSBtb21lbnQgd2Ug ZG9u4oCZdCBuZWVkIGEgaGFtbWVyLg0KDQoNCg0KDQpHw7ZyYW4NCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQo= --_000_05C8AB73EFD14AC8A795D3624153F4D2ericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <68BC4D2A22B63E41AF9AE8D3E8CC1797@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 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNv TGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgN Cgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGNtOw0KCW1hcmdpbi1yaWdo dDowY207DQoJbWFyZ2luLWJvdHRvbTowY207DQoJbWFyZ2luLWxlZnQ6MzYuMHB0Ow0KCW1hcmdp bi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIixzYW5zLXNlcmlmO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25v cm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDph dXRvOw0KCW1hcmdpbi1yaWdodDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJ bWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLHNhbnMtc2VyaWY7fQ0KcC5wMSwgbGkucDEsIGRpdi5wMQ0KCXttc28tc3R5bGUtbmFtZTpw MTsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglsaW5lLWhlaWdodDox My41cHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjsNCgljb2xvcjpibGFjazt9DQpwLnAyLCBsaS5wMiwgZGl2LnAyDQoJe21zby1zdHlsZS1u YW1lOnAyOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWxpbmUtaGVp Z2h0OjEzLjVwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1zdHls ZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNv bG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5zMQ0KCXttc28tc3R5bGUtbmFtZTpzMTt9DQpzcGFuLmFw cGxlLWNvbnZlcnRlZC1zcGFjZQ0KCXttc28tc3R5bGUtbmFtZTphcHBsZS1jb252ZXJ0ZWQtc3Bh Y2U7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9u dC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4w cHQ7DQoJbWFyZ2luOjcwLjg1cHQgNzAuODVwdCA3MC44NXB0IDcwLjg1cHQ7fQ0KZGl2LldvcmRT ZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpA bGlzdCBsMA0KCXttc28tbGlzdC1pZDozMjYzNjk3NDQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRz OjEyNjczNTQ4NTg7fQ0KQGxpc3QgbDENCgl7bXNvLWxpc3QtaWQ6NTI5Mjk4NDU4Ow0KCW1zby1s aXN0LXRlbXBsYXRlLWlkczotMTc0Mjg1NTkwNDt9DQpAbGlzdCBsMg0KCXttc28tbGlzdC1pZDo2 ODM0MzI5Njc7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRz OjExMTIxODM4NTggNDQxMzQ2MjQ4IDY3Njk4NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEz IDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1O30NCkBsaXN0IGwyOmxldmVsMQ0K CXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJbWFyZ2luLWxlZnQ6NTQuMHB0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3Qg bDI6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCglt YXJnaW4tbGVmdDo5MC4wcHQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMjpsZXZl bDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgltYXJnaW4t bGVmdDoxMjYuMHB0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMjpsZXZlbDQNCgl7 bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCW1hcmdpbi1sZWZ0OjE2Mi4wcHQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBs MjpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1h cmdpbi1sZWZ0OjE5OC4wcHQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMjpsZXZl bDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgltYXJnaW4t bGVmdDoyMzQuMHB0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMjpsZXZlbDcNCgl7 bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCW1hcmdpbi1sZWZ0OjI3MC4wcHQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBs MjpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1h cmdpbi1sZWZ0OjMwNi4wcHQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMjpsZXZl bDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgltYXJnaW4t bGVmdDozNDIuMHB0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMw0KCXttc28tbGlz dC1pZDoxODMzMDU4OTg2Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBs YXRlLWlkczoxMTEyMTgzODU4IDQ0MTM0NjI0OCA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2 NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNTt9DQpAbGlzdCBsMzps ZXZlbDENCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjU0LjBwdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30N CkBsaXN0IGwzOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJbWFyZ2luLWxlZnQ6OTAuMHB0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3Qg bDM6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJ bWFyZ2luLWxlZnQ6MTI2LjBwdDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDM6bGV2 ZWw0DQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgltYXJnaW4tbGVmdDoxNjIuMHB0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0K QGxpc3QgbDM6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgltYXJnaW4tbGVmdDoxOTguMHB0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3Qg bDM6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJ bWFyZ2luLWxlZnQ6MjM0LjBwdDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDM6bGV2 ZWw3DQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgltYXJnaW4tbGVmdDoyNzAuMHB0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0K QGxpc3QgbDM6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgltYXJnaW4tbGVmdDozMDYuMHB0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3Qg bDM6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJ bWFyZ2luLWxlZnQ6MzQyLjBwdDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0Kb2wNCgl7bWFyZ2lu LWJvdHRvbTowY207fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0KLS0+PC9zdHlsZT4NCjwv aGVhZD4NCjxib2R5IGxhbmc9IlNWIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYg Y2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyI+SGkgUmljaGFyZCwgUm9tYW4sIGFsbDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0icDEiPjxzcGFuIGNsYXNzPSJzMSI+PHNwYW4gbGFuZz0iRU4tVVMi PlRoYW5rcyBmb3Iga2luZCB3ZWxjb21lIGFuZCBmb3IgcHJvZ3Jlc3NpbmcgdGhlIGRpc2N1c3Np b24uIEFwb2xvZ2llcyBmb3IgYSBsb25nIGVtYWlsLjwvc3Bhbj48L3NwYW4+PHNwYW4gbGFuZz0i RU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAw Y20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYu MHB0Ij48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6 YmxhY2siPkZyb206DQo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEyLjBwdDtjb2xvcjpibGFjayI+UmljaGFyZCBCYXJuZXMgJmx0O3JsYkBpcHYuc3gmZ3Q7 PGJyPg0KPGJyPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gbGFuZz0iRU4t VVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBsYW5n PSJFTi1VUyI+U3VtbWluZyB1cCB3aGVyZSBJIGJlbGlldmUgdGhlIGNvbnZlcnNhdGlvbiBzdGFu ZHMgbm93LCBpdCBzZWVtcyBsaWtlIHdoYXQgZm9sa3MgYXJlIGFza2luZyBmb3IgaXMgZWl0aGVy OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8b2wgc3R5bGU9Im1hcmdpbi10 b3A6MGNtIiBzdGFydD0iMSIgdHlwZT0iMSI+DQo8bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgi IHN0eWxlPSJtYXJnaW4tbGVmdDoxOC4wcHQ7bXNvLWxpc3Q6bDMgbGV2ZWwxIGxmbzMiPjxzcGFu IGxhbmc9IkVOLVVTIj5BbiBhbmFseXNpcyB0aGF0IHNob3dzIHRoYXQgRURIT0MgaXMgZXF1aXZh bGVudCB0byBhbiBleGlzdGluZyBBS0UgKGUuZy4sIElLRSBvciBUTFMpLCBvcjxvOnA+PC9vOnA+ PC9zcGFuPjwvbGk+PC9vbD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+ Mi4gQW4gYXJndW1lbnQgdGhhdCBhIG5ldyBBS0UgaXMgbmVjZXNzYXJ5ICh2cy4gYSByZS1lbmNv ZGluZyBvZiBhbiBleGlzdGluZyBBS0UpPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5Hw7ZyYW4gZXQgYWw6 IERvIHlvdSBoYXZlIHRob3VnaHRzIG9uIHRob3NlIHBvaW50cz88bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi Plllcy4gSeKAmWxsIGdldCBiYWNrIHRvIHRoaXMgbGF0ZXIgaW4gdGhpcyBlbWFpbC48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPkl0IHNlZW1zIGxpa2UgaXQg Y291bGQgYmUgYSBwcm9kdWN0aXZlIHVzZSBvZiBhbiBob3VyIG9yIHR3byBvZiB2aXJ0dWFsIGlu dGVyaW0gdGltZSB0byBoZWxwIHRoZSBncm91cCB1bmRlcnN0YW5kIG9uZSBvZiB0aG9zZSBsaW5l cyBvZiBhcmd1bWVudC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBsYW5nPSJF Ti1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiPkFncmVlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6MzYuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+LS1SaWNoYXJkPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJwMSI+PHNwYW4gY2xhc3M9InMxIj48c3BhbiBs YW5nPSJFTi1VUyI+QXMgcmVxdWVzdGVkIGluIGEgcHJldmlvdXMgZW1haWwsIGhlcmUgaXMgYSBi YWNrZ3JvdW5kLjwvc3Bhbj48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJwMSI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJwMiI+PHNwYW4gY2xhc3M9InMxIj48c3BhbiBsYW5n PSJFTi1VUyI+VGhlIHdvcmsgb24gRURIT0MgaXMgbW90aXZhdGVkIGJ5IHRoZSBuZWVkIGZvciBh biBhdXRoZW50aWNhdGlvbiBhbmQga2V5IGV4Y2hhbmdlIHByb3RvY29sIGZvciBPU0NPUkUgKGRy YWZ0LWlldGYtY29yZS1vYmplY3Qtc2VjdXJpdHkpIG9wdGltaXplZCBmb3IgY29uc3RyYWluZWQt bm9kZSBuZXR3b3JrcyAoUkZDIDcyMjgpLiBPU0NPUkUgaXMgYXBwbGllZCB3aXRoaW4NCiB0aGUg SUVURiwgZS5nLiBpbiA2VGlTQ0ggbWluaW1hbCBzZWN1cml0eSAoZHJhZnQtaWV0Zi02dGlzY2gt bWluaW1hbC1zZWN1cml0eSksIGJ1dCBhbHNvIHJlcXVlc3RlZCBieSBvdGhlciBTRE9zIGFuZCBp bmR1c3RyeSBmb3JhIHN1Y2ggYXMgT01BIFNwZWN3b3JrcywgT3BlbiBDb25uZWN0aXZpdHkgRm91 bmRhdGlvbiBhbmQgRmFpcmhhaXIgQWxsaWFuY2UuIFRoZSBwcm9wZXJ0aWVzIG9mIE9TQ09SRSBt b3RpdmF0aW5nIGl0cyB1c2UgaW5jbHVkZToNCiBzdXBwb3J0IGZvciBDb0FQIGZvcndhcmQgcHJv eGllcywgc3VwcG9ydCBmb3IgY2hhbmdlIG9mIHVuZGVybHlpbmcgdHJhbnNwb3J0cyBpbmNsdWRp bmcgbm9uLUlQLCBsb3cgb3ZlcmhlYWQsIGxvdyBhZGRpdGlvbmFsIGZvb3RwcmludCBhbmQgbWVt b3J5IHRvIGV4aXN0aW5nIENvQVAgaW1wbGVtZW50YXRpb25zLCBzdXBwb3J0IGZvciBtdWx0aWNh c3Qgc2VjdXJpdHksIHNlY3VyaXR5IGZvciBlbmQtdG8tZW5kIFJFU1QuPC9zcGFuPjwvc3Bhbj48 c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5i c3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9InAxIj48c3BhbiBjbGFzcz0iczEiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPHAgY2xhc3M9InAxIj48c3BhbiBjbGFz cz0iczEiPjxzcGFuIGxhbmc9IkVOLVVTIj5HaXZlbiB0aGUgbGFyZ2UgaW50ZXJlc3QgaW4gT1ND T1JFIGFscmVhZHkgYmVmb3JlIGl0IGhhcyBiZWNvbWUgYW4gUkZDIHdlIGFudGljaXBhdGUgYSB3 aWRlIHJhbmdlIG9mIGRlcGxveW1lbnRzLiBGb3IgZXhhbXBsZSwgd2Ugc2VlIGFuIGludGVyZXN0 IGZvciBPU0NPUkUgaW4gQ2VsbHVsYXIgSW9UIHdpdGggdHJhZmZpYyBydW5uaW5nIG92ZXIgdGhl IGNlbGx1bGFyDQogYWlyIGludGVyZmFjZSBjb250cm9sIGNoYW5uZWwsIHdoZXJlIHdlIGNhbiBo YXZlIGVuZC10by1lbmQgQ29BUCwgYnV0IG5vdCBuZWNlc3NhcmlseSBlbmQtdG8tZW5kIElQIGJl dHdlZW4gYW4gYXBwbGljYXRpb24gc2VydmVyIGFuZCBhIGNlbGx1bGFyIGRldmljZS4gT3IgYmV0 d2VlbiBhbiBhcHBsaWNhdGlvbiBzZXJ2ZXIgYW5kIGEgZGV2aWNlIGJlaGluZCBhIGNlbGx1bGFy IGdhdGV3YXkuIENvbXBhcmluZyBqdXN0IHRoZXNlIHR3byBjYXNlcywNCiB0aGUgZGlmZmVyZW5j ZSBpbiBjYXBhYmlsaXRpZXMgb2YgdGhlIGRldmljZXMgY2FuIGJlIHNpZ25pZmljYW50IHdoaWNo IG1ha2VzIGl0IGRpZmZpY3VsdCB0byBwb2ludCBhdCBzb21lIHNvcnQgb2Yg4oCccmVmZXJlbmNl IGRldmljZXPigJ0gZm9yIGJlbmNobWFya2luZy4NCjwvc3Bhbj48L3NwYW4+PHNwYW4gbGFuZz0i RU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJwMSI+PHNwYW4gbGFuZz0i RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJwMiI+PHNwYW4g Y2xhc3M9InMxIj48c3BhbiBsYW5nPSJFTi1VUyI+SW4gb3JkZXIgdG8gc3VwcG9ydCB0aGUgbG93 IGVuZCB1c2UgY2FzZXMgdGhlIEFLRSBtdXN0IGJlIHBlcmZvcm1hbnQgaW4gbG93IGJhbmR3aWR0 aCBkZXBsb3ltZW50cyB3aXRoIGJhdHRlcnkgcG93ZXJlZCBkZXZpY2VzIHJlc3RyaWN0ZWQgaW4g UkFNIGFuZCBST00uPC9zcGFuPjwvc3Bhbj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNw YWNlIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBjbGFzcz0i czEiPjxzcGFuIGxhbmc9IkVOLVVTIj5NZXNzYWdlDQogc2l6ZXMgYW5kIHJvdW5kIHRyaXBzIGhh dmUgYSBkaXJlY3QgaW1wYWN0IG9uIGxhdGVuY3ksIHBvd2VyIGNvbnN1bXB0aW9uIGFuZCBiYXR0 ZXJ5IGxpZmV0aW1lLCBhbmQgY2FuIGJlIGNhbGN1bGF0ZWQgd2hpY2ggaXMgdGhlIHJlYXNvbiBm b3IgdGhpcyBiZWluZyBhIGNvbW1vbmx5IHVzZWQgbWV0cmljLiBXaGlsZSBpdCBtYXkgYmUgbW9y ZSBkaWZmaWN1bHQgdG8gY29tcGFyZSBtZW1vcnkgYW5kIHN0b3JhZ2UgcmVxdWlyZW1lbnRzLCB0 aGUgYWJpbGl0eQ0KIHRvIHJldXNlIGV4aXN0aW5nIGNvZGUgaXMgYW4gaW1wb3J0YW50IGluZGlj YXRpb24uIElmIGEgZGV2aWNlIGNhbiBzdXBwb3J0IGEgQ29BUCBzdGFjayAoaW4gdGhlIHNlbnNl IG9mIG1lbW9yeSBhbmQgZmxhc2gsIGV0YykgaXQgaXMgZXhwZWN0ZWQgdG8gYWxzbyBiZSBhYmxl IHRvIHN1cHBvcnQgT1NDT1JFLiBTaW1pbGFybHksIGl0IGlzIGRlc2lyYWJsZSB0aGF0IGEgZGV2 aWNlIHdpdGggQ29BUCBhbmQgT1NDT1JFIGltcGxlbWVudGVkIHNob3VsZA0KIGJlIGFibGUgdG8g c3VwcG9ydCBhbiBhZGRpdGlvbmFsIEFLRS4gQ29uc2lkZXJpbmcgdGhhdCBFREhPQyByZXVzZXMg Q0JPUiBhbmQgQ09TRSBwcmltaXRpdmVzIGZyb20gT1NDT1JFIHRoZSBhZGRpdGlvbmFsIGNvZGUg Zm9yIEVESE9DIGNhbiBiZSB2ZXJ5IGxpbWl0ZWQuPC9zcGFuPjwvc3Bhbj48c3BhbiBsYW5nPSJF Ti1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9InAxIj48c3BhbiBsYW5nPSJF Ti1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9InAxIj48c3BhbiBs YW5nPSJFTi1VUyI+RnJvbSBhIHNlY3VyaXR5IHBvaW50IG9mIHZpZXcgT1NDT1JFIHJlcXVpcmVz IHRoYXQgdGhlIGVuZHBvaW50cyBoYXZlIGFncmVlZCBvbiBhIE1hc3RlciBTZWNyZXQgd2l0aCBh IGdvb2QgYW1vdW50IG9mIHJhbmRvbW5lc3MsIGFuZCBlYWNoIG90aGVy4oCZcyBTZW5kZXIgSURz LCBhbmQgdGhvc2UgbXVzdCBiZSBkaWZmZXJlbnQgZm9yIGEgZ2l2ZW4gTWFzdGVyIFNlY3JldC48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0icDEiPjxzcGFuIGxhbmc9IkVOLVVTIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0icDEiPjxzcGFuIGxhbmc9IkVO LVVTIj5Ob3cgcmV0dXJuaW5nIHRvIHRoZSBxdWVzdGlvbnMuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4g bGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxvbCBzdHlsZT0ibWFy Z2luLXRvcDowY20iIHN0YXJ0PSIxIiB0eXBlPSIxIj4NCjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFn cmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjE4LjBwdDttc28tbGlzdDpsMiBsZXZlbDEgbGZvNiI+ PHNwYW4gbGFuZz0iRU4tVVMiPkFuIGFuYWx5c2lzIHRoYXQgc2hvd3MgdGhhdCBFREhPQyBpcyBl cXVpdmFsZW50IHRvIGFuIGV4aXN0aW5nIEFLRSAoZS5nLiwgSUtFIG9yIFRMUyk8bzpwPjwvbzpw Pjwvc3Bhbj48L2xpPjwvb2w+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9InAyIj48c3BhbiBjbGFz cz0iczEiPjxzcGFuIGxhbmc9IkVOLVVTIj5Db25zaWRlcmluZyBFREhPQyBpcyBhIG5ldyBwcm90 b2NvbCBpdCBzaG91bGQgYmUgdGhvcm91Z2hseSBhbmFseXNlZCBhbmQgdmVyaWZpZWQgYWdhaW5z dCBhbGwgY3VycmVudGx5IGtub3duIGlzc3VlcyBvZiBBS0VzLiBSb21hbiBzZW50IGEgbWFpbCB0 byB0aGUgc2VjZGlzcGF0Y2ggbGlzdCByZWZlcmVuY2luZyBhIHBhcGVyIHByZXNlbnRlZCBhdCBT U1IgMjAxOA0KIHdoaWNoIGNvdWxkIGJlIHVzZWQgYXMgYSBzdGFydGluZyBwb2ludC4gSG93IGRv IGZvbGtzIHdhbnQgdG8gZGlnZXN0IHRoaXM6IERvIHRoZXkgd2FudCB0byBzdHVkeSB0aGUgbW9k ZWwgdGhlbXNlbHZlcyBvciBzaG91bGQgd2UgYXNrIHRoZSBhdXRob3JzIGlmIHRoZXkgY291bGQg cHJlc2VudCB0aGVpciB3b3JrIGF0IHRoZSBpbnRlcmltPw0KPC9zcGFuPjwvc3Bhbj48c3BhbiBs YW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVT Ij4yLiBBbiBhcmd1bWVudCB0aGF0IGEgbmV3IEFLRSBpcyBuZWNlc3NhcnkgKHZzLiBhIHJlLWVu Y29kaW5nIG9mIGFuIGV4aXN0aW5nIEFLRSk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0icDEiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0icDEiPjxzcGFuIGxhbmc9IkVOLVVTIj5XZSBoYXZlIGRvbmUgdGhpcyBjb21wYXJp c29uIHdpdGggVExTL0RUTFMgZm9yIHNvbWUgdGltZSBub3csIGFuZCB3aGF0IG9uY2U8c3BhbiBj bGFzcz0iczEiPiBzZWVtZWQgbGlrZSBhIHJlYXNvbmFibGUgcXVlc3Rpb24gaGFzIHR1cm5lZCBv dXQgdG8gYmUgbmV2ZXIgZW5kaW5nIGV4ZXJjaXNlLiBJIGRvIG5vdCB3YW50IHRvIGdldCBpbnRv IElFVEYgYXJjaGVvbG9neSBidXQgZm9yIHRob3NlDQogd2hvIGhhdmUgbm90IGZvbGxvd2VkIHRo ZSBkaXNjdXNzaW9uIHNvbWUgZGF0YSBwb2ludHMgY291bGQgYmUgcmVsZXZhbnQuPG86cD48L286 cD48L3NwYW4+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJwMSI+PHNwYW4gY2xhc3M9InMxIj48c3Bh biBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJwMSI+PHNwYW4gY2xhc3M9InMxIj48c3BhbiBsYW5nPSJFTi1VUyI+Tm90IGxvbmcgYWdv LCB0aGUgZGVzaWduIG9mIHNlY3VyaXR5IHByb3RvY29scyBkaWQgbm90IHRha2UgaW50byBhY2Nv dW50IGNvbnN0cmFpbmVkIElvVCBkZXZpY2VzLiBXaXRoIE9TQ09SRSB3ZSBzaG93ZWQgdGhhdCB0 aGUgbWVzc2FnZSBvdmVyaGVhZCBjb3VsZCBiZSByZWR1Y2VkIGJ5IGEgZmFjdG9yIDMgY29tcGFy ZWQgdG8gRFRMUyAxLjIgcmVjb3Jkcy4NCiBCZWZvcmUgdGhpcyBjb21wYXJpc29uIGl0IHdhcyBi ZWxpZXZlZCB0aGF0IHRoZSByZWNvcmQgbGF5ZXIgd2FzIHBlcmZvcm1pbmcgd2VsbCwgdGhlbiB0 aGUgZGlmZmVyZW5jZSBpbiBvdmVyaGVhZCB3YXMgY2hhcmFjdGVyaXplZCBhcyBpbnNpZ25pZmlj YW50LCBhbmQgdGhlbiBmaW5hbGx5IGEgY29tcGFjdCBmb3JtYXQgd2FzIGRlc2lnbmVkIGZvciBE VExTIDEuMy48bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPHAgY2xhc3M9InAxIj48c3Bh biBjbGFzcz0iczEiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9InAxIj48c3BhbiBjbGFzcz0iczEiPjxzcGFuIGxhbmc9IkVO LVVTIj5XaXRoIEVESE9DIHdlIHNob3dlZCB0aGF0IHRoZSBtZXNzYWdlIG92ZXJoZWFkIG9mIHRo ZSBrZXkgZXhjaGFuZ2UgY2FuIGJlIHJlZHVjZWQgd2l0aCB1cCB0byBhIGZhY3RvciA0IGNvbXBh cmVkIHRvIHRoZSBjdXJyZW50IHZlcnNpb24gb2YgRFRMUyAxLjMgKHNlZSBBcHBlbmRpeCBFIGlu IEVESE9DKS4gQmVmb3JlIHRoaXMgZXhlcmNpc2UgaXQgd2FzIGJlbGlldmVkDQogdGhhdCB0aGUg VExTL0RUTFMgaGFuZHNoYWtlIHdhcyBwZXJmb3JtaW5nIHdlbGwsIHRoZW4gdGhlIGRpZmZlcmVu Y2UgaW4gb3ZlcmhlYWQgd2FzIGNoYXJhY3Rlcml6ZWQgYXMgaW5zaWduaWZpY2FudCwgYW5kIG5v dyB0aGUgZGlzY3Vzc2lvbiBoYXMgc2hpZnRlZCB0byBkb3duc2l6aW5nIHRoZSBUTFMgaGFuZHNo YWtlIG9yIG90aGVyIHByb3RvY29sLjxvOnA+PC9vOnA+PC9zcGFuPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0icDEiPjxzcGFuIGNsYXNzPSJzMSI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0icDEiPjxzcGFuIGNsYXNzPSJzMSI+ PHNwYW4gbGFuZz0iRU4tVVMiPldlIGFyZSBub3QgYWdhaW5zdCBvcHRpbWl6YXRpb25zIHRvIHRo ZSBUTFMgaGFuZHNoYWtlLCBqdXN0IGFzIHdlIHdlbGNvbWUgdGhlIG1vcmUgb3B0aW1hbCBEVExT IDEuMyByZWNvcmRzLiBCdXQgVExTIHdhcyBub3QgZGVzaWduZWQgdG8gYmUgYW4gQUtFIGZvciBP U0NPUkUgb3B0aW1pemVkIGZvciBjb25zdHJhaW5lZCBlbnZpcm9ubWVudHMuIEFzIEkgcmVtZW1i ZXIsDQogb3B0aW1pemluZyBmb3IgbWVzc2FnZSBvdmVyaGVhZCB3YXMgYW4gZXhwbGljaXQgbm9u LXJlcXVpcmVtZW50IG9mIFRMUyAxLjMuIFJldmVydGluZyB0aG9zZSBkZXNpZ24gZGVjaXNpb25z IHNlZW1zIGxpa2UgdGhlIHdyb25nIHdheSB0byBnbzogT25lIHJlYXNvbiB0byB1c2UgVExTIHdv dWxkIGJlIHRvIHJldXNlIGFuIGV4aXN0aW5nIGltcGxlbWVudGF0aW9uLiBCdXQgZXhpc3Rpbmcg VExTIGltcGxlbWVudGF0aW9uIHdvdWxkIG1vc3QgbGlrZWx5DQogbm90IGNvbXBhcmUgZmF2b3Jh Ymx5IGluIHRlcm1zIG9mIGNvZGUgc2l6ZSBhbmQgUkFNLiBBZGRpbmcgY29kZSBmb3IgY29tcHJl c3Npb24gb3IgcmUtZW5jb2Rpbmcgb2YgdGhlIG1lc3NhZ2VzIHdvdWxkIGFkZCB0byB0aGF0LiBS ZS1zcGVjaWZ5aW5nIHRoZSBwcm90b2NvbCB3aXRoIHRoZSBuZXcgZW5jb2RpbmcgbWF5IHJlcXVp cmUgYSBuZXcgZm9ybWFsIHZlcmlmaWNhdGlvbi4gVG8gbWFrZSBhIG1vcmUgY29tcGFjdCBjb2Rl IGFuZCBwcm9jZXNzaW5nDQogbWF5IGludm9sdmUgdHdvIGluY29tcGF0aWJsZSBtZXNzYWdlIGZv cm1hdHMgb2YgVExTIGRlcGVuZGluZyBvbiB3aGF0IGlzIGJlaW5nIHNpZ25lZC4gTmV3IGltcGxl bWVudGF0aW9ucyB3b3VsZCBiZSBuZWVkZWQuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9InAxIj48c3BhbiBjbGFzcz0iczEiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gY2xhc3M9InMxIj48c3BhbiBsYW5nPSJFTi1VUyI+V2UgdGhpbmsgd2UgaGF2ZSBkb25lIG91 ciBwYXJ0IG9mIHRoZSBjb21wYXJpc29uIGV4ZXJjaXNlIGFuZCB0aGF0IHRoZSBidXJkZW4gb2Yg cHJvb2Ygc2hvdWxkIG5vdyBiZSByZXZlcnNlZC4gQ291bGQgd2UgYXNrIHRob3NlIHRoYXQgY2xh aW0gdG8gaGF2ZSBhIG1vcmUgcGVyZm9ybWFudCBrZXkgZXhjaGFuZ2UgcHJvdG9jb2wgZm9yIE9T Q09SRQ0KIGFuZCBhcmUgcHJlcGFyZWQgdG8gZG8gdGhlIHdvcmsgdG8gbWFrZSB0aGF0IHBsYXVz aWJsZSBhbmQgcHJvdmlkZSB0aGUgbnVtYmVycz8gVG8gYmUgY2xlYXI6DQo8L3NwYW4+PC9zcGFu PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPmlmIHRoZXJlIGlzIGFub3Ro ZXIga2V5IGV4Y2hhbmdlIHByb3RvY29sIHN1aXRhYmxlIGZvciBPU0NPUkUgd2hpY2ggb3V0cGVy Zm9ybXMgRURIT0MgaW4gY29uc3RyYWluZWQgY2hhcmFjdGVyaXN0aWNzIGFuZCB0aGVuIHdlIGFy ZSB2ZXJ5IGludGVyZXN0ZWQuDQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPkFuZCBhZ2Fp biwgd2l0aCB0aGUgc3RhdGVtZW50cyBpbiB0aGlzIG1haWwgd2UgbmVpdGhlciB3YW50IHRvIGJl bGl0dGxlIHRoZSBjb25zaWRlcmFibGUgZWZmb3J0IG1hZGUgb24gZm9ybWFsIHZlcmlmaWNhdGlv biwgbm9yIGNsYWltIHRoYXQgRFRMUyBpcyBub3QgZml0IGZvciBJb1QgZGVwbG95bWVudHMuIEl0 IGlzIGFuIGltcG9ydGFudCBoYW1tZXINCiBpbiBvdXIgSW9UIHNlY3VyaXR5IHRvb2xib3gsIGJ1 dCBhdCB0aGUgbW9tZW50IHdlIGRvbuKAmXQgbmVlZCBhIGhhbW1lci48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9InAxIj48c3BhbiBjbGFzcz0iczEiPjxzcGFu IGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPHAgY2xh c3M9InAxIj48c3BhbiBjbGFzcz0iczEiPjxzcGFuIGxhbmc9IkVOLVVTIj5Hw7ZyYW48bzpwPjwv bzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPHAgY2xhc3M9InAxIj48c3BhbiBjbGFzcz0iczEiPjxz cGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9InAxIj48c3BhbiBjbGFzcz0iczEiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPHAgY2xhc3M9InAxIj48c3BhbiBjbGFzcz0iczEi PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0K PHAgY2xhc3M9InAxIj48c3BhbiBjbGFzcz0iczEiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPHAgY2xhc3M9InAxIj48c3BhbiBjbGFzcz0i czEiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9InAxIj48c3BhbiBjbGFzcz0iczEiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPHAgY2xhc3M9InAxIj48c3BhbiBsYW5n PSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9InAxIj48c3Bh biBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9InAx Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0 bWw+DQo= --_000_05C8AB73EFD14AC8A795D3624153F4D2ericssoncom_-- From nobody Thu Jan 24 10:28:34 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 539DB131335 for ; Thu, 24 Jan 2019 10:28:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.874 X-Spam-Level: X-Spam-Status: No, score=-7.874 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.979, 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=cLzlWEpq; dkim=pass (1024-bit key) header.d=ericsson.com header.b=N6nomDtv 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 4mVUZouK_a3u for ; Thu, 24 Jan 2019 10:28:30 -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 1E1E3131331 for ; Thu, 24 Jan 2019 10:28:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/relaxed; q=dns/txt; i=@ericsson.com; t=1548354508; x=1550946508; 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=gh8jsP56XY7BSESAuPuRaqxAri8bXFhPubRuilSIgNI=; b=cLzlWEpq3OZ+4U3hz3nuNUjem/it6hqdwdntq3bROJZduRTWRN97JKLFKZMOi6Fo /8mGs/gsqsT4jP+YmL85GPpZh3BcI0DSXX76iEePUZJXYEyI6N5CYR0ZKTDYG1cW E8KMDpjO25cO5IVDHq9Pfj39pihcFAUaIWixkszzYGU=; X-AuditID: c1b4fb3a-5c9c29e00000672c-cd-5c4a03cc442c Received: from ESESSMB501.ericsson.se (Unknown_Domain [153.88.183.119]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id E0.CC.26412.CC30A4C5; Thu, 24 Jan 2019 19:28:28 +0100 (CET) Received: from ESESBMB501.ericsson.se (153.88.183.168) 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; Thu, 24 Jan 2019 19:28:28 +0100 Received: from EUR02-HE1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESBMB501.ericsson.se (153.88.183.168) 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; Thu, 24 Jan 2019 19:28:27 +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=gh8jsP56XY7BSESAuPuRaqxAri8bXFhPubRuilSIgNI=; b=N6nomDtvPbAwOC32MGOPkt6GhBOHQfGGOOK9pgtUoM2ZROQUOv/kp8lBOdkwGbgVi5VfD93I4bEbAK8Msdn3Mpp6s97lnyjpy5YtMJ1NgSY2scnRKXC50TdKB/FoCSTa0mA4x8qk4gvKMF8QzJ25Cyper8+ed8xipKvAfrDg5Xs= Received: from DB6PR07MB4167.eurprd07.prod.outlook.com (10.168.19.153) by DB6PR07MB3061.eurprd07.prod.outlook.com (10.170.222.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1558.10; Thu, 24 Jan 2019 18:28:27 +0000 Received: from DB6PR07MB4167.eurprd07.prod.outlook.com ([fe80::a10c:961e:8639:85f4]) by DB6PR07MB4167.eurprd07.prod.outlook.com ([fe80::a10c:961e:8639:85f4%4]) with mapi id 15.20.1580.004; Thu, 24 Jan 2019 18:28:12 +0000 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Benjamin Kaduk CC: "secdispatch@ietf.org" , John Mattsson , Francesca Palombini , "ace@ietf.org" Thread-Topic: [Ace] [Secdispatch] EDHOC Thread-Index: AQHUou5Zx1xiDx+jgESY4I5hUyszWqWcqBGAgAINKACAFqIAAIAACQQAgAmPyIA= Date: Thu, 24 Jan 2019 18:28:12 +0000 Message-ID: References: <79FD6563-8ADA-4D73-B8D5-C3D70604CD76@gmail.com> <47F03C99-68C1-4ADB-873D-F01987D66849@ipv.sx> <20190118172714.GJ81907@kduck.mit.edu> In-Reply-To: <20190118172714.GJ81907@kduck.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.15.0.190115 x-originating-ip: [213.89.213.86] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB6PR07MB3061; 6:A/Z8INUXdubj2kIG6Wgh+/CT+a2Hduf50cuCeF29ygn2avct99j8tjZDYI0pFzkvgPF73Zo4zR/q+SCrB/lCCHf7biQy38hbfzkcMRk78v1ycybahKFwOA6fyJ5LrXnGITPYhWukiTKxrdjrW97swTCDZDKAgqDo+b+Z+O3QwZHyg/t4iEGq25f9/4Czstk1+4v1Bf282pUPCkjSH2d+NuB4VaIiwWcGoyrjTOrCXM+YwzNWQYafmhj1aG1Zd5q1RXR4omI+4/gBMhIRhkr9sjA1/YN4Ilj9HuEJCsaBeeRS1sYHc665WRL0wPVuQPU8atEzQhgN58XtMPFGLbwFJp0XBxc/RTnGKuXg47fr8WbaKx9nL769Uiw62zyCgwnoCYqVY0mK7SdMsG5CeS6Vmw/ia//sRA0Gk787caPKmnBTBssljlFZLJ9JxRLpavoFKdFN2GD2mTS7+4gDLQai0w==; 5:jJUDBUp/zwdGVEcU10x6gJOBEPL71BskKW/PXTXYqoWLX99pZ4FlanS0u7ciw4KDXrQY0DjFCbSqK8d3T+EZY9wg9DKkMUDnRZa73sSF6g494v3X8hrudBbaNPq4mPd3zZcXM9kkdo62oRxPQV1SiGMm1ORaZhwsMDTfbM1GJsZJY8jA23WSA2/FN1aw3yzIAfzeHtJ9LJEw+kh7wMPSMw==; 7:2gY7xKQu1oacRx2oxP9h/0jeKZ/2Dv9hVOOleudOOXSSydfROFGm9Yrpw7YBsmUQlHFUSEzs3mYdS6CzMw7IQB0vofsBloz98HuDXCUBVxlWQbrCojRHQfBy+/LjCpHYgTaXvABg9+FYYTFzK4JgwA== x-ms-exchange-antispam-srfa-diagnostics: SOS;SOR; x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10009020)(376002)(39860400002)(136003)(366004)(396003)(346002)(189003)(199004)(68736007)(446003)(71190400001)(2616005)(476003)(11346002)(83716004)(105586002)(2906002)(26005)(6436002)(6246003)(102836004)(106356001)(85202003)(3846002)(6486002)(6116002)(76176011)(6506007)(82746002)(2171002)(33656002)(97736004)(66574012)(186003)(4326008)(36756003)(229853002)(478600001)(486006)(305945005)(8676002)(14454004)(256004)(99286004)(8936002)(53936002)(6512007)(14444005)(85182001)(25786009)(58126008)(316002)(66066001)(81166006)(7736002)(81156014)(93886005)(54906003)(71200400001)(86362001)(6306002)(966005)(6916009); DIR:OUT; SFP:1101; SCL:1; SRVR:DB6PR07MB3061; H:DB6PR07MB4167.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; x-ms-office365-filtering-correlation-id: 99dff6e8-ea6e-4b26-fec3-08d68229b2ca x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605077)(2017052603328)(7153060)(7193020); SRVR:DB6PR07MB3061; x-ms-traffictypediagnostic: DB6PR07MB3061: authentication-results: spf=none (sender IP is ) smtp.mailfrom=goran.selander@ericsson.com; x-microsoft-antispam-prvs: x-forefront-prvs: 0927AA37C7 received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: oxFk5wOgg2+Pyiou9Yo7O6SXeEO6IM96CyjaMIWMks8rm9FRWssp3i8IUMw8LoBe56VAuRj2XfMyZlNf6dYu9tPk57/W9oxFZjzDDc60zkLpeMZiGQdcheWwzElKH+RaA+Tjcbv94xT9LDJqzCLazIysGU1zbkC+cmA27DaPR9W1Oijqo+9lVu3XpkmnVrh/+UBfczNzT4hlQGtyui6qSDpkgpBUzUS2NciU+3miK/Hx/cmk0aZFTOl9AYHTxZjC051ztjCmgctbbeCC/3iGvtCWi0JHRIPEvlOFGwIsaYqtwjOk9TlGR56UugZfwx5uJ3KI5UpHKDjpAOyZr5LytKy6/pEhYJva80MvxWf6KV+8cXls79hWNWsovNTSegQtoLOYNlSdZc2tESPEd8Dt5JkKAfsK0nv+Nkbb3DyaSdw= Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 99dff6e8-ea6e-4b26-fec3-08d68229b2ca X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jan 2019 18:28:12.3210 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR07MB3061 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02SaUhUURSAue+9eT6HJq4vxzlugZMpGmqO/ZBQW8zQzJCk0BjTQR8qrrxn LkE6TZsbamiWIhipWSktKioVqJMiheaSmfnDcqG0lKjMHcmZN0H/vnO+c+8553IZkq2Q2DAJ Kekcn6JJUtJSqjK8PdOtnzyh3l88ae29slxEejc8qyS8m8Y+SA6TgXV1a0Sgrr+XDCXOSX1i uaSEDI738IuWxnct7U7b9M0qXsmnteipTwEyZwAfgPX2SlSApAyLexB8WWglxGAZQYNumBSD OgImrw4aDYVLSZhtr6dFU0bAvaUh2nAZi6cRlMxFG5jGx+CzdpowsCVWQu3AVeMBEncgmHw3 RhnELuwEutF+SixyhvsLtbTIp0Db8N7MwBTeC21b+dtzMIwMH4LbQyFi48sEDDxYQ4Yac+wF 478mjYywFay8aTI2JrECJmZrCHFTDHUvB0mR5TA/syUxsBx7wLWVVYmYd4BpfYmJ7WGkptD4 MoB1ZvCpoosShSf0PewkRVFDw5+en2aiCIGZ3iLT6Y8I1ovOiOwK+vEu03TnQfdYS4v5RNA1 T9ClyKPqv2GrthclsQs8eW5KB8KtlmoksgOUF06ZGViGLeB15Sx1F0keIbnACUJynErlzvEJ MYKQmuKewqU3o+3f0t26cbADdX89okeYQcodst7lIDUr0WQI2cl6BAyptJQFDB9Xs7JYTfZF jk+N4i8kcYIe2TKUUiHbZC3ULI7TpHOJHJfG8f8swZjbaFGkf+Cio7XL77BLzSOrmjxFpxfh 1VIeMevUNlHbo/XjN+behm+GnXTGoTnB1+cDggUXtz3tvFVPdKO2mrCWhgmKGzFHX+yMstxn nzs+5au5aVdUtpA3GjRe3/k901OmdHCMtMtRsGdVS2SNf0TOads7P2YW+7LkqisdufOvvjUq KSFe4+lK8oLmL43yhvEpAwAA Archived-At: Subject: Re: [Ace] [Secdispatch] EDHOC 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, 24 Jan 2019 18:28:32 -0000 SGkgQmVuLA0KDQpJIHJlcGxpZWQgdG8gc29tZSBvZiB5b3VyIGNvbW1lbnRzIGluIG15IHByZXZp b3VzIG1haWwgdG8gdGhlIGxpc3QuIEFkZGl0aW9uYWwgY29tbWVudHMgaW5saW5lLg0KDQrvu79P biAyMDE5LTAxLTE4LCAxODoyNywgIkJlbmphbWluIEthZHVrIiA8a2FkdWtAbWl0LmVkdT4gd3Jv dGU6DQoNCiAgICBPbiBGcmksIEphbiAxOCwgMjAxOSBhdCAxMTo1NDo1OEFNIC0wNTAwLCBSaWNo YXJkIEJhcm5lcyB3cm90ZToNCiAgICA+IExldCBtZSBwcm92aWRlIHNvbWUgYWRkaXRpb25hbCBj b250ZXh0LiAgV2hlbiB0aGUgY2hhaXJzIGFuZCBBRHMgZGlzY3Vzc2VkIHRoaXMgaW4gQktLLCBp dCBzZWVtZWQgcHJldHR5IGNsZWFyIHRoYXQgRURIT0MgaXMgbm90IHdpdGhpbiB0aGUgY3VycmVu dCBjaGFydGVyIG9mIEFDRSDigJQgYWZ0ZXIgYWxsLCBBQ0UgaXMgdGFyZ2V0ZWQgYXQgYXV0aGVu dGljYXRpb24gYW5kIGF1dGhvcml6YXRpb24sIG5vdCBrZXkgZXhjaGFuZ2UuICBTaW5jZSBBQ0Ug d291bGQgbmVlZCB0byByZWNoYXJ0ZXIgdG8gYWNjZXB0IHRoaXMgd29yayBpbiBhbnkgY2FzZSwg YW5kIGJlY2F1c2UgRURIT0Mgb3ZlcmxhcHBlZCB3aXRoIHRoZSBpbnRlcmVzdHMgb2Ygb3RoZXIg d29ya2luZyBncm91cHMsIGl0IHNlZW1lZCB0byBtYWtlIHNlbnNlIHRvIGhhdmUgdGhlIGNvbnZl cnNhdGlvbiBpbiBhIGJyb2FkZXIgdmVudWUuDQogICAgDQogICAgQUNFJ3MgY2hhcnRlciBpcyAu Li4gbWVzc3kuICBNb3JlIGJlbG93Lg0KICAgIA0KICAgID4gR8O2cmFuOiBZb3VyIGVtYWlsIHN0 YXJ0aW5nIHRoaXMgdGhyZWFkIHNlZW1zIGxpa2UgYW4gYWJicmV2aWF0ZWQgc3VtbWFyeSBvZiB0 aGUgcGFzdCBkaXNjdXNzaW9uIG9mIHRoaXMgZHJhZnQuICBTaW5jZSB0aGlzIGlzIGEgbmV3IGF1 ZGllbmNlLCBpdCB3b3VsZCBiZSBoZWxwZnVsIGlmIHlvdSBjb3VsZCBzdGFydCBmcm9tIHRoZSB1 bmRlcmx5aW5nIHJlcXVpcmVtZW50cyAo4oCcd2UgbmVlZCBhbiBBS0Ugd2l0aCBjZXJ0YWluIGNv bnN0cmFpbnRz4oCdKSBhbmQgbGF5IG91dCB3aHkgbmV3IHByb3RvY29sIHdvcmsgaXMgbmVlZGVk LCB2cy4gcHJvZmlsaW5nIGV4aXN0aW5nIHByb3RvY29scyAoYXMgaGFzIGJlZW4gZG9uZSwgZS5n LiwgaW4gRElDRSkuDQogICAgDQogICAgDQogICAgVGhlcmUgc2VlbSB0byBiZSBzZXZlcmFsIGlu dGVybGVhdmVkIGlzc3VlcyBhdCBwbGF5LCBoZXJlLCBhbmQgSSBhZ3JlZSB0aGF0DQogICAgc29t ZSBjbGVhci9jb25zb2xpZGF0ZWQgYmFja2dyb3VuZCB3b3VsZCBiZSBoZWxwZnVsLiAgSSBwYXJ0 aWN1bGFybHkgY2FsbA0KICAgIG91dCB0aGUgc2VjdXJpdHkgcHJvb2YgdGhhdCBoYXMgYmVlbiBw cmVzZW50ZWQgZWxzZXdoZXJlLCB3aGljaCBJIHRoaW5rDQogICAgd291bGQgYmUgaW50ZXJlc3Rp bmcgdG8gc2V2ZXJhbCByZWFkZXJzIChidXQgSSBkb24ndCBoYXZlIHRoZSBsaW5rIGhhbmR5KS4N CiAgICANClJlZmVyZW5jZWQgaW4gUm9tYW4ncyBwcmV2aW91cyBtYWlsIHRvIHNlY2Rpc3BhdGNo LiBJIGFncmVlIHRoYXQgYXNzZXJ0aW5nIHRoZSBmb3JtYWwgc2VjdXJpdHkgcHJvcGVydGllcyBp cyBrZXkuDQoNCiAgICBTb21lIHRob3VnaHRzIG9mIG15IG93bi4uLg0KICAgIA0KICAgIFRoZXJl IGlzIGNsZWFyIGRlbWFuZCBmb3IgYSBsaWdodHdlaWdodCBrZXktZXhjaGFuZ2UgcHJvdG9jb2wg Zm9yIHVzZSBpbg0KICAgIElvVCBwcm90b2NvbHMsIGVzcGVjaWFsbHkgT1NDT1JFLiAgRURIT0Mg aGFzIGJlZW4gYXJvdW5kIGZvciBhIHdoaWxlLCBhbmQNCiAgICBldmVuIGRpc2N1c3NlZCBpbiBB Q0Ugd2l0aCBzb21lIGZyZXF1ZW5jeS4gIFRoYXQgc2FpZCwgdGhlcmUgYXJlIHNldmVyYWwNCiAg ICByZWFzb25zIHRvIHByZWZlciBhc2tpbmcgc2VjZGlzcGF0Y2ggdG8ganVzdCBjYWxsaW5nIGZv ciBhZG9wdGlvbiBpbiBBQ0UNCiAgICBkaXJlY3RseSwgaW5jbHVkaW5nIGJ1dCBub3QgbGltaXRl ZCB0bzoNCiAgICANCiAgICAoYSkgZGVzaWduaW5nIHNlY3VyZSBhdXRoZW50aWNhdGVkIGtleSBl eGNoYW5nZSBwcm90b2NvbHMgaXMgaGFyZCEgIEl0IHRha2VzDQogICAgYSBsb3Qgb2YgZW5lcmd5 IGZyb20gc21hcnQgcGVvcGxlIHRvIGRlc2lnbiBhbmQgYW5hbHl6ZSBhIHByb3RvY29sIHRvIGhh dmUNCiAgICBjb25maWRlbmNlIHRoYXQgaXQgaXMgc2VjdXJlIGFuZCBmdWxmaWxzIHRoZSBhZHZl cnRpc2VkIGZ1bmN0aW9ucy4NCiAgICBTdGFydGluZyBmcm9tIHdlbGwta25vd24vd2VsbC1hbmFs eXplZCBmb3VuZGF0aW9ucyBsaWtlIFNJR01BIGlzIGEgZ3JlYXQNCiAgICBzdGFydCwgYnV0IGhh cmRseSBhIGd1YXJhbnRlZSBvZiBzdWNjZXNzLiAgU2VjZGlzcGF0Y2ggZ2V0cyB1cyBzb21lIGJl dHRlcg0KICAgIHZpc2liaWxpdHksIGFuZCBpbnNpZ2h0IGludG8gd2hlcmUgd29yayBjYW4gYmUg ZG9uZSB0aGF0IHdpbGwgaGF2ZQ0KICAgIHN1ZmZpY2llbnQgZXhwZXJ0aXNlIChib3RoIHdpdGhp biBhbmQgb3V0c2lkZSB0aGUgSUVURiwgYXMgd2VsbCBhcyB3aGF0IGhhcw0KICAgIGJlZW4gZG9u ZSBhbHJlYWR5IHZzLiB3aGF0IHJlbWFpbnMgdG8gYmUgZG9uZSkgdG8gYmUgY29uZmlkZW50IGlu IHRoZQ0KICAgIHJlc3VsdC4NCiAgICANClRoaXMgc291bmRzIGxpa2UgYW4gZXhjZWxsZW50IHN1 cHBvcnQgZnVuY3Rpb24uIFRoYW5rcy4NCg0KICAgIChiKSBBQ0UgaGFzIGEgcHJldHR5IGNvbXBs aWNhdGVkIGNoYXJ0ZXIsIHRoYXQgc2VlbXMgdG8gcGxhY2UgcmVzdHJpY3Rpb25zDQogICAgb24g aG93IGl0IGNhbiBhZG9wdCBuZXcgcHJvdG9jb2wgd29yayB3aXRob3V0IHJlY2hhcnRlcmluZy4g IFdlIGZpbmQgdGhpbmdzDQogICAgaW4gdGhlIGNoYXJ0ZXIgbGlrZSAiZXhpc3RpbmcgYXV0aGVu dGljYXRpb24gYW5kIGF1dGhvcml6YXRpb24gcHJvdG9jb2xzDQogICAgd2lsbCBiZSBldmFsdWF0 ZWQgYW5kIHVzZWQgd2hlcmUgYXBwbGljYWJsZSBbLi4uXS4gIFNvbWUgZnVuY3Rpb25hbGl0eSwN CiAgICBob3dldmVyLCBtYXkgbm90IGJlIGF2YWlsYWJsZSBpbiBleGlzdGluZyBwcm90b2NvbHMs IGluIHdoaWNoIGNhc2UgdGhlDQogICAgc29sdXRpb24gbWF5IGludm9sdmUgbmV3IHByb3RvY29s IHdvcmsuIiAgVGhpcyB3b3VsZCBzZWVtIHRvIHJlcXVpcmUgYQ0KICAgIGNsZWFyIGNyaXRlcmlh IGZvciBob3cgdG8gZGV0ZXJtaW5lIHdoZXRoZXIgb3Igbm90IGV4aXN0aW5nIHRlY2hub2xvZ3kg aXMNCiAgICBhcHBsaWNhYmxlLCBwbHVzIGV2aWRlbmNlIHRoYXQgZXhpc3RpbmcgcHJvdG9jb2xz IGRvIG5vdCBtZWV0IHRoZSBiYXIuICBJbg0KICAgIHBhcnRpY3VsYXIsICJtYWtlIHRoZSBrZXkg ZXhjaGFuZ2UgbWVzc2FnZXMgYXMgc21hbGwgYXMgcG9zc2libGUiIGlzIG5vdCBhDQogICAgY2xl YXIgY3JpdGVyaW9uLCBhcyB0aGF0IHdvdWxkIGFsd2F5cyBhcmd1ZSBmb3IgYSBuZXcgcHJvdG9j b2wgb3ZlciBhbg0KICAgIGV4aXN0aW5nIG9uZSwgYXMgd2UgY29tZSB1cCB3aXRoIG5ldyB3YXlz IHRvIGVrZSBvdXQgc3BhY2UuDQoNCkkgZG9uJ3Qga25vdyBob3cgaW1wb3J0YW50IGl0IGlzIHRv IGZpdCBpbnRvIHRoZSBleGlzdGluZyBBQ0UgY2hhcnRlciBidXQgdGhlIGNvbXBhcmlzb24gYmV0 d2VlbiBFREhPQyBhbmQgVExTL0RUTFMgaGFuZHNoYWtlIHNob3dlZCBhIHJlZHVjdGlvbiBpbiBt ZXNzYWdlIG92ZXJoZWFkIHdpdGggdXAgdG8gNzUlLCB3aGljaCBjYW4gYmUgdHJhbnNsYXRlZCBp bnRvIHBvd2VyIGNvbnN1bXB0aW9uLiBJIHdvdWxkIHNheSB0aGF0ICJwb3dlciBlZmZpY2llbnQg a2V5IGV4Y2hhbmdlIiBpcyBmdW5jdGlvbmFsaXR5IG5vdCBhdmFpbGFibGUgaW4gdGhlIGV4aXN0 aW5nIHByb3RvY29scyB3ZSBsb29rZWQgYXQuDQoNCiAgICAoYykgQSBjbGVhciBhbmQgc3Vic3Rh bnRpYWwgZGlmZmVyZW5jZSBiZXR3ZWVuIGtleSBleGNoYW5nZS9oYW5kc2hha2Ugc2l6ZQ0KICAg IGJldHdlZW4gRURIT0MgYW5kIGV2ZW4gbWluaW1pemVkIERMVFMgY291bGQgYmUgY29tcGVsbGlu ZyBlbm91Z2ggZm9yDQogICAgc2VjZGlzcGF0Y2ggdG8gZGVjaWRlIHRoYXQgdGhlIHdvcmsgaXMg dXNhYmxlLCBhbmQgZmluZCBhbiBhcHByb3ByaWF0ZQ0KICAgIGhvbWUsIGluZGVwZW5kZW50bHkg b2YgdGhlIHF1ZXN0aW9uIG9mIHJlY2hhcnRlcmluZyBBQ0UgYW5kIG1lZXRpbmcgdGhlDQogICAg YWRkaXRpb25hbCBiYXJyaWVyIGRlc2NyaWJlZCBpbiB0aGUgcHJldmlvdXMgcG9pbnQuDQogICAg DQpUaGUgV0cgaXMgbm90IGNydWNpYWwsIGJ1dCBpbnZvbHZlbWVudCBmcm9tIHRoZSB1c2VyIGNv bW11bml0eSBpcyB2YWx1YWJsZSBhcyB3ZWxsIGFzIHRoZSBzZWN1cml0eSBleHBlcnRpc2UuIA0K ICAgIA0KICAgIEppbSBhbmQgc2V2ZXJhbCBvdGhlcnMgaGF2ZSBkb25lIHNvbWUgZ29vZCB3b3Jr IGxvb2tpbmcgaW50byB0YWJ1bGF0aW5nDQogICAgbWVzc2FnZSBvdmVyaGVhZHMgaW4gdmFyaW91 cyBzY2VuYXJpb3MgKGUuZy4sDQogICAgaHR0cHM6Ly93d3cuZGl2YS1wb3J0YWwub3JnL3NtYXNo L2dldC9kaXZhMjoxMTU2NDgzL0ZVTExURVhUMDEucGRmLA0KICAgIGh0dHBzOi8vamltc2NoLmdp dGh1Yi5pby9yYW5kb21EcmFmdHMvZHJhZnQtc2NoYWFkLWFjZS10bHMtY2Jvci1oYW5kc2hha2Uu aHRtbCkNCiAgICB0aGF0IHdpbGwgYmUgaGVscGZ1bCBhcyB3ZSBjb25zaWRlciB0aGlzIHRvcGlj Lg0KICAgIA0KICAgIEluIGFkZGl0aW9uIHRvIGp1c3QgY29tcGFyaW5nIHRoZSBieXRlIGNvdW50 IGZvciBoYW5kc2hha2Uva2V5IGV4aGNoYW5nZQ0KICAgIG1lc3NhZ2VzIGluIHZhcmlvdXMgbWV0 aG9kcywgaXQgd291bGQgcHJvYmFibHkgYWxzbyBiZSBnb29kIHRvIHRoaW5rIGFib3V0DQogICAg dGhpbmdzIGluIHRlcm1zIG9mIHRoZSBjb25zdHJhaW50cyBpbiB0aGUgY3VycmVudCBBQ0UgY2hh cnRlci4gIFRoYXQgaXMsDQogICAgc29tZW9uZSBjb3VsZCAoMSkgcGljayBhIChjbGFzcyBvZikg ZGV2aWNlKHMpLCAoMikgc2hvdyB0aGF0IGl0IGhhcyB3aWRlDQogICAgZGVwbG95bWVudC9wb3Rl bnRpYWwgdGhlcmVvZiwgKDMpIGdpdmUgaGFyZCBudW1iZXJzIGFib3V0IHdoYXQgaXQncyAobm90 KQ0KICAgIGNhcGFibGUgb2YsIGFuZCAoNCkgc2hvdyB0aGF0IERUTFMgZmFsbHMgb24gdGhlIHdy b25nIHNpZGUgb2YgdGhhdCBjdXRvZmYsDQogICAgdXNpbmcgdGhlIGhhbmRzaGFrZSBudW1iZXJz IHdlIGFscmVhZHkgaGF2ZS4gIEluIHBhcnRpY3VsYXIsIEkgZG9uJ3QNCiAgICByZW1lbWJlciBz ZWVpbmcgYW55dGhpbmcgdG91Y2hpbmcgb24gKDMpLCBwcmV2aW91c2x5LiAgQW4gYW5hbHlzaXMg bGlrZQ0KICAgIHRoaXMgd291bGQgbm90IG9ubHkgZ2l2ZSBzb21lIGNvbnRleHQgZm9yIGludGVy cHJldGluZyB0aGUgZ2FwIGJldHdlZW4NCiAgICBFREhPQyBhbmQgRExUUywgYnV0IGNvdWxkIGFs c28gYmUgY29tcGVsbGluZyBpbiBzdXBwb3J0IG9mIHRoZSBuZWVkIGZvciB0aGUNCiAgICBtb3Jl IGxpZ2h0d2VpZ2h0IHNvbHV0aW9uLg0KDQpBcyBtZW50aW9uZWQsIG1lc3NhZ2Ugb3ZlcmhlYWQg ZGlmZmVyZW5jZXMgdHJhbnNsYXRlIGludG8gbWVhc3VyYWJsZSBxdWFudGl0aWVzLiBXaGlsZSBp dCBtYXkgYmUgcG9zc2libGUgdG8gZmluZCBhbiBleGFtcGxlIHdoZXJlIHRoZXJlIGlzIGEgY2xl YXIgY3V0LCBJIHRoaW5rIGZvciBtYW55IHNjZW5hcmlvcyB0aGVyZSB3b3VsZCBiZSBxdWFsaXRh dGl2ZSBkaWZmZXJlbmNlcy4NCg0KR8O2cmFuDQoNCg0KDQoNCg0K From nobody Thu Jan 24 10:40:43 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5373A13130F for ; Thu, 24 Jan 2019 10:40:42 -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 Upe6E7P3KteY for ; Thu, 24 Jan 2019 10:40:39 -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 C2EDE13129F for ; Thu, 24 Jan 2019 10:40:38 -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, 24 Jan 2019 10:40:32 -0800 From: Jim Schaad To: 'Michael Richardson' , "'Panos Kampanakis (pkampana)'" , CC: References: <011501d4ac3d$ab2b9650$0182c2f0$@augustcellars.com> <0e5d254ced7242a69b4bd48a1c99442e@XCH-ALN-010.cisco.com> <22883.1548345549@localhost> In-Reply-To: <22883.1548345549@localhost> Date: Thu, 24 Jan 2019 10:40:30 -0800 Message-ID: <003d01d4b414$49e07760$dda16620$@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: AQF61PvzwzMWmD5ENcCTB9smhJ8GWwIYZsiBAbozeIWmU+hogA== Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Ace] FW: WGLC comments draft-ietf-ace-coap-est-07 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, 24 Jan 2019 18:40:42 -0000 > -----Original Message----- > From: Michael Richardson > Sent: Thursday, January 24, 2019 7:59 AM > To: Panos Kampanakis (pkampana) ; ace@ietf.org > Cc: Jim Schaad ; consultancy@vanderstok.org > Subject: Re: [Ace] FW: WGLC comments draft-ietf-ace-coap-est-07 > > > https://goo.gl/LT4HYh is a diff from -06 to current. > Panos has done a great job updating this according to the issues raised during > the WGLC. Thank you > > I have re-read diffs to catch up, and have these minor author > tweaks/questions. > > > Client authentication via DTLS Client Certificate is mandatory. > > I wonder if this should go into it's own section so that one can more easily > say, "Please see section x.y.z" > > s/enrolment/enrollment/ <- use American spelling, I guess. We had both. > > section 6: > REQ: GET /.well-known/core?rt=ace.est* > > I didn't know the trailing "*" was a thing. > ; rt="ace.est", > > I guess I have to re-read the Core Link resource discovery document. > Can a server respond with ; ?? it's shorter, and I think would be valid? The wild card on the end is defined behavior in RD and elsewhere. It means just what it looks like - return anything that starts with this string, including the string. Yes a server can respond with "" if the resource is at the root. Especially for the wild card not sending back the rt would not be good behavior as you don't know that it is not something else such as ace.est.foo. > > > If > > the default root resource requests fail, the client > > SHOULD fall back > > to doing a resource discovery. Resource discovery > > SHOULD be employed > > when non-default URIs (like /est or > > /est/ArbitraryLabel) or ports are > > supported by the server or when the > > client is unaware of what EST- > > coaps resources are available by the server. > > This implies that a server is not required to support /.well-known/est We are > not clear about this. I would prefer that the server ALWAYS supports the > well-known names, such that the client can skip doing resource discovery if it > thinks that the extra bytes in the URL matter less than additional round trip > to do discovery. If one is doing compressed headers, this may not be a big issue to have the extra links in there. My main issue with the section is it is not clear what an application should do and how it should make the decision. Jim > > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- From nobody Thu Jan 24 11:16:20 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 523371313B9; Thu, 24 Jan 2019 11:16:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eCeyBDcwEuzt; Thu, 24 Jan 2019 11:16:11 -0800 (PST) Received: from mail-ot1-x333.google.com (mail-ot1-x333.google.com [IPv6:2607:f8b0:4864:20::333]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFC2012894E; Thu, 24 Jan 2019 11:16:10 -0800 (PST) Received: by mail-ot1-x333.google.com with SMTP id i20so6304622otl.0; Thu, 24 Jan 2019 11:16:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=cXFtMw57pTxpUjtYQiz6/E6e4It0hZD0pJ/xcVK8w6E=; b=sZtCoBwx23Am1RCGMBaIP9EH0GNU1E6SpKlirORpBNwKSSORK+AOngt5Wts7zORuv4 lIeb3zeWpEGF+poBJqjj6aTLwEYOxWASznUjZZkewhJqlUXSBIVZutOTe4oIcVNpGHAO tXCYX4HUvHmI3o+IpraEpQq32WiwNN7Fkkwz/bjq3Ku0Lg/4+gQ9SPu78O2c4M2VKGoX iaIIo09L1niilxqgH5AAv57XvaexhLBd5nIabuLtDye+HOvRnaw1bfrPPweoCUy0B/CT vNxZ/9Xb4m9cUYw3bGKYRyXpRoq7UZ+W/z77lOhf1pNYUDUpOLL5106kVUw20vfDsCe5 e6yQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=cXFtMw57pTxpUjtYQiz6/E6e4It0hZD0pJ/xcVK8w6E=; b=tcL8q0pCIRrCIqmhKIWX2lYsnHwprq8LgH2wpf0DqIPlitduxZM5yj9xNu6OIsZ0eJ C5pxFHrEMUMHhUc5UjbwHJTI9/5zeVErEm7NlDefmC89s4HJyQt9uX07au4oUxieUPQp aMgQATzJptlD9kDOjJsasHvZNeUUgzrhBDwe/V0ahDn09py7K2GQzvaFgzKOcIlzoIHs Ci57U6B8e1AuPHyhmrkFJZ+L3Nflnq4utCUKe8rZl4ncgDEIITq3Uk+V7qIFMS+jjDrV zBR/0hQ2BMijqddZwkAjiHZB3kVOsL6SyBA/90/gkENIUGDTImYOky70DNsiBnYklRa9 rLKA== X-Gm-Message-State: AJcUukcXNSt+LcVeZUbFQyoOih6cdeaXurtgCmgwyNqPirHNMoaYsE9B QA7h0HHwh8Ix6oeBx8M2zizQL/3Id0x6SFkBIBYbtg== X-Google-Smtp-Source: ALg8bN7tDHO1mslY1okcpvgHpi95V1Qh9dyrGVsDdNIlJCEs0tlRIz6B+pMpmEvH9kg3pCCHPuJ/aJhGufGQIFdibS8= X-Received: by 2002:a9d:1715:: with SMTP id i21mr5201242ota.149.1548357369966; Thu, 24 Jan 2019 11:16:09 -0800 (PST) MIME-Version: 1.0 References: <79FD6563-8ADA-4D73-B8D5-C3D70604CD76@gmail.com> <47F03C99-68C1-4ADB-873D-F01987D66849@ipv.sx> <20190118172714.GJ81907@kduck.mit.edu> <359EC4B99E040048A7131E0F4E113AFC0185795C45@marathon> <05C8AB73-EFD1-4AC8-A795-D3624153F4D2@ericsson.com> In-Reply-To: <05C8AB73-EFD1-4AC8-A795-D3624153F4D2@ericsson.com> From: Kathleen Moriarty Date: Thu, 24 Jan 2019 14:15:33 -0500 Message-ID: To: =?UTF-8?Q?G=C3=B6ran_Selander?= Cc: Richard Barnes , Roman Danyliw , John Mattsson , "secdispatch@ietf.org" , Francesca Palombini , "ace@ietf.org" Content-Type: multipart/alternative; boundary="00000000000005b4580580390b25" Archived-At: Subject: Re: [Ace] [Secdispatch] EDHOC 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, 24 Jan 2019 19:16:14 -0000 --00000000000005b4580580390b25 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for the very helpful message, Goran. A couple of comments inline. On Thu, Jan 24, 2019 at 11:31 AM G=C3=B6ran Selander wrote: > Hi Richard, Roman, all > > > > Thanks for kind welcome and for progressing the discussion. Apologies for > a long email. > > > > *From: *Richard Barnes > > > > Summing up where I believe the conversation stands now, it seems like wha= t > folks are asking for is either: > > > > 1. An analysis that shows that EDHOC is equivalent to an existing AKE > (e.g., IKE or TLS), or > > > > 2. An argument that a new AKE is necessary (vs. a re-encoding of an > existing AKE) > > > > G=C3=B6ran et al: Do you have thoughts on those points? > > > > Yes. I=E2=80=99ll get back to this later in this email. > > > > It seems like it could be a productive use of an hour or two of virtual > interim time to help the group understand one of those lines of argument. > > > > Agree. > Anything to prevent further hold ups on this work would be appreciated. > > > --Richard > > > > As requested in a previous email, here is a background. > > > > The work on EDHOC is motivated by the need for an authentication and key > exchange protocol for OSCORE (draft-ietf-core-object-security) optimized > for constrained-node networks (RFC 7228). OSCORE is applied within the > IETF, e.g. in 6TiSCH minimal security (draft-ietf-6tisch-minimal-security= ), > but also requested by other SDOs and industry fora such as OMA Specworks, > Open Connectivity Foundation and Fairhair Alliance. The properties of > OSCORE motivating its use include: support for CoAP forward proxies, > support for change of underlying transports including non-IP, low overhea= d, > low additional footprint and memory to existing CoAP implementations, > support for multicast security, security for end-to-end REST. > > > > Given the large interest in OSCORE already before it has become an RFC we > anticipate a wide range of deployments. For example, we see an interest f= or > OSCORE in Cellular IoT with traffic running over the cellular air interfa= ce > control channel, where we can have end-to-end CoAP, but not necessarily > end-to-end IP between an application server and a cellular device. Or > between an application server and a device behind a cellular gateway. > Comparing just these two cases, the difference in capabilities of the > devices can be significant which makes it difficult to point at some sort > of =E2=80=9Creference devices=E2=80=9D for benchmarking. > > > > In order to support the low end use cases the AKE must be performant in > low bandwidth deployments with battery powered devices restricted in RAM > and ROM. Message sizes and round trips have a direct impact on latency, > power consumption and battery lifetime, and can be calculated which is th= e > reason for this being a commonly used metric. While it may be more > difficult to compare memory and storage requirements, the ability to reus= e > existing code is an important indication. If a device can support a CoAP > stack (in the sense of memory and flash, etc) it is expected to also be > able to support OSCORE. Similarly, it is desirable that a device with CoA= P > and OSCORE implemented should be able to support an additional AKE. > Considering that EDHOC reuses CBOR and COSE primitives from OSCORE the > additional code for EDHOC can be very limited. > > > > From a security point of view OSCORE requires that the endpoints have > agreed on a Master Secret with a good amount of randomness, and each > other=E2=80=99s Sender IDs, and those must be different for a given Maste= r Secret. > > > > Now returning to the questions. > > > > 1. An analysis that shows that EDHOC is equivalent to an existing AKE > (e.g., IKE or TLS) > > > > Considering EDHOC is a new protocol it should be thoroughly analysed and > verified against all currently known issues of AKEs. Roman sent a mail to > the secdispatch list referencing a paper presented at SSR 2018 which coul= d > be used as a starting point. How do folks want to digest this: Do they wa= nt > to study the model themselves or should we ask the authors if they could > present their work at the interim? > > > > 2. An argument that a new AKE is necessary (vs. a re-encoding of an > existing AKE) > > > > We have done this comparison with TLS/DTLS for some time now, and what on= ce > seemed like a reasonable question has turned out to be never ending > exercise. I do not want to get into IETF archeology but for those who hav= e > not followed the discussion some data points could be relevant. > > > > Not long ago, the design of security protocols did not take into account > constrained IoT devices. With OSCORE we showed that the message overhead > could be reduced by a factor 3 compared to DTLS 1.2 records. Before this > comparison it was believed that the record layer was performing well, the= n > the difference in overhead was characterized as insignificant, and then > finally a compact format was designed for DTLS 1.3. > > > > With EDHOC we showed that the message overhead of the key exchange can be > reduced with up to a factor 4 compared to the current version of DTLS 1.3 > (see Appendix E in EDHOC). Before this exercise it was believed that the > TLS/DTLS handshake was performing well, then the difference in overhead w= as > characterized as insignificant, and now the discussion has shifted to > downsizing the TLS handshake or other protocol. > > > > We are not against optimizations to the TLS handshake, just as we welcome > the more optimal DTLS 1.3 records. But TLS was not designed to be an AKE > for OSCORE optimized for constrained environments. As I remember, > optimizing for message overhead was an explicit non-requirement of TLS 1.= 3. > Reverting those design decisions seems like the wrong way to go: One reas= on > to use TLS would be to reuse an existing implementation. But existing TLS > implementation would most likely not compare favorably in terms of code > size and RAM. Adding code for compression or re-encoding of the messages > would add to that. Re-specifying the protocol with the new encoding may > require a new formal verification. To make a more compact code and > processing may involve two incompatible message formats of TLS depending = on > what is being signed. New implementations would be needed. > > > > We think we have done our part of the comparison exercise and that the > burden of proof should now be reversed. Could we ask those that claim to > have a more performant key exchange protocol for OSCORE and are prepared = to > do the work to make that plausible and provide the numbers? To be clear: = if > there is another key exchange protocol suitable for OSCORE which > outperforms EDHOC in constrained characteristics and then we are very > interested. > I agree with Goran that they have jumped through enough hoops at this point. However, if alternatives come forward, understanding their timelines is also critical as not to hold up this work for any substantial amount of time. > > And again, with the statements in this mail we neither want to belittle > the considerable effort made on formal verification, nor claim that DTLS = is > not fit for IoT deployments. It is an important hammer in our IoT securit= y > toolbox, but at the moment we don=E2=80=99t need a hammer. > The class of IoT device seems to be the critical point here and having one protocol that can meet all needs is a nice goal, but not realistic from the comparison numbers provided and the varying requirements in the IoT space. Best regards, Kathleen > > > > G=C3=B6ran > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > --=20 Best regards, Kathleen --00000000000005b4580580390b25 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for the very helpful message, Gora= n.=C2=A0 A couple of comments inline.

<= div dir=3D"ltr">On Thu, Jan 24, 2019 at 11:31 AM G=C3=B6ran Selander <goran.selander@ericsson.com> wrote:

Hi Richard, Roman, all

=C2=A0

Thanks for kind welcome and for progress= ing the discussion. Apologies for a long email.

=C2=A0

From: Richar= d Barnes <rlb@ipv.sx>

<= /u>=C2=A0

Summ= ing up where I believe the conversation stands now, it seems like what folk= s are asking for is either:

<= /u>=C2=A0

  1. An analysis that shows that EDHOC is equival= ent to an existing AKE (e.g., IKE or TLS), or

    2. =C2=A0

2. A= n argument that a new AKE is necessary (vs. a re-encoding of an existing AK= E)

=C2=A0

G=C3= =B6ran et al: Do you have thoughts on those points?

=C2=A0

Yes. I=E2=80=99ll get back to t= his later in this email.

<= /u>=C2=A0

It s= eems like it could be a productive use of an hour or two of virtual interim= time to help the group understand one of those lines of argument.

<= /u>=C2=A0

Agree.


Anything to prevent further hold= ups on this work would be appreciated.
=C2=A0

=C2=A0

--Ri= chard

=C2=A0

As requested in a previous email, here i= s a background.

=C2= =A0

The work on EDHOC is motivated by the ne= ed for an authentication and key exchange protocol for OSCORE (draft-ietf-c= ore-object-security) optimized for constrained-node networks (RFC 7228). OS= CORE is applied within the IETF, e.g. in 6TiSCH minimal security (draft-ietf-6tisch-minimal-secur= ity), but also requested by other SDOs and industry fora such as OMA Specwo= rks, Open Connectivity Foundation and Fairhair Alliance. The properties of = OSCORE motivating its use include: support for CoAP forward proxies, support for change of underlying transpo= rts including non-IP, low overhead, low additional footprint and memory to = existing CoAP implementations, support for multicast security, security for= end-to-end REST.=C2=A0

=C2=A0

Given the large interest in OSCORE alrea= dy before it has become an RFC we anticipate a wide range of deployments. F= or example, we see an interest for OSCORE in Cellular IoT with traffic runn= ing over the cellular air interface control channel, where we can have end-to-end CoAP, but not = necessarily end-to-end IP between an application server and a cellular devi= ce. Or between an application server and a device behind a cellular gateway= . Comparing just these two cases, the difference in capabilities of the devices can be significant which mak= es it difficult to point at some sort of =E2=80=9Creference devices=E2=80= =9D for benchmarking.

=C2= =A0

In order to support the low end use case= s the AKE must be performant in low bandwidth deployments with battery powe= red devices restricted in RAM and ROM.=C2=A0= Message sizes and round trips have a direct impact on latency, power consumption a= nd battery lifetime, and can be calculated which is the reason for this bei= ng a commonly used metric. While it may be more difficult to compare memory= and storage requirements, the ability to reuse existing code is an important indication. If a device can support= a CoAP stack (in the sense of memory and flash, etc) it is expected to als= o be able to support OSCORE. Similarly, it is desirable that a device with = CoAP and OSCORE implemented should be able to support an additional AKE. Considering that EDHOC reuses CBOR a= nd COSE primitives from OSCORE the additional code for EDHOC can be very li= mited.

=C2= =A0

From a secu= rity point of view OSCORE requires that the endpoints have agreed on a Mast= er Secret with a good amount of randomness, and each other=E2=80=99s Sender= IDs, and those must be different for a given Master Secret.<= /span>

=C2= =A0

Now returni= ng to the questions.

<= /u>=C2=A0

  1. An analysis that shows that EDHOC is equival= ent to an existing AKE (e.g., IKE or TLS)

=C2=A0

Considering EDHOC is a new protocol it s= hould be thoroughly analysed and verified against all currently known issue= s of AKEs. Roman sent a mail to the secdispatch list referencing a paper pr= esented at SSR 2018 which could be used as a starting point. How do folks want to digest this:= Do they want to study the model themselves or should we ask the authors if= they could present their work at the interim?

=C2=A0

2. A= n argument that a new AKE is necessary (vs. a re-encoding of an existing AK= E)

=C2= =A0

We have don= e this comparison with TLS/DTLS for some time now, and what once seemed like a reasonable question has t= urned out to be never ending exercise. I do not want to get into IETF arche= ology but for those who have not followed the discussion some data points could be relevant.

=C2=A0

Not long ago, the design of security pro= tocols did not take into account constrained IoT devices. With OSCORE we sh= owed that the message overhead could be reduced by a factor 3 compared to D= TLS 1.2 records. Before this comparison it was believed that the record layer was performin= g well, then the difference in overhead was characterized as insignificant,= and then finally a compact format was designed for DTLS 1.3.=

=C2=A0

With EDHOC we showed that the message ov= erhead of the key exchange can be reduced with up to a factor 4 compared to= the current version of DTLS 1.3 (see Appendix E in EDHOC). Before this exe= rcise it was believed that the TLS/DTLS handshake was performing well, then the difference in ov= erhead was characterized as insignificant, and now the discussion has shift= ed to downsizing the TLS handshake or other protocol.<= /span>

=C2=A0

We are not against optimizations to the = TLS handshake, just as we welcome the more optimal DTLS 1.3 records. But TL= S was not designed to be an AKE for OSCORE optimized for constrained enviro= nments. As I remember, optimizing for message overhead was an explicit non-requirement of TLS 1.3= . Reverting those design decisions seems like the wrong way to go: One reas= on to use TLS would be to reuse an existing implementation. But existing TL= S implementation would most likely not compare favorably in terms of code size and RAM. Adding code for compr= ession or re-encoding of the messages would add to that. Re-specifying the = protocol with the new encoding may require a new formal verification. To ma= ke a more compact code and processing may involve two incompatible message formats of TLS depending on what is b= eing signed. New implementations would be needed.

=C2=A0

We think we have done our part of the comparison exercise an= d that the burden of proof should now be reversed. Could we ask those that = claim to have a more performant key exchange protocol for OSCORE and are prepared to do the work to make that plausible and provide the num= bers? To be clear: if there is anothe= r key exchange protocol suitable for OSCORE which outperforms EDHOC in cons= trained characteristics and then we are very interested.


I agree with Goran that th= ey have jumped through enough hoops at this point.=C2=A0 However, if altern= atives come forward, understanding their timelines is also critical as not = to hold up this work for any substantial amount of time.=C2=A0
=

= =C2=A0

And again= , with the statements in this mail we neither want to belittle the consider= able effort made on formal verification, nor claim that DTLS is not fit for= IoT deployments. It is an important hammer in our IoT security toolbox, but at the moment we don=E2=80=99t need a ham= mer.


The= class of IoT device seems to be the critical point here and having one pro= tocol that can meet all needs is a nice goal, but not realistic from the co= mparison numbers provided and the varying requirements in the IoT space.

Best regards,
Kathleen

=C2=A0

=C2=A0

G=C3=B6ran

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2= =A0

=C2= =A0

=C2= =A0

=C2=A0

=C2=A0

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


--

Best regards,
Kathleen
--00000000000005b4580580390b25-- From nobody Thu Jan 24 18:32:36 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEDBC128D0C for ; Thu, 24 Jan 2019 18:32:34 -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 NuruW7ljFdxU for ; Thu, 24 Jan 2019 18:32:33 -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 D0AE8128D09 for ; Thu, 24 Jan 2019 18:32:32 -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, 24 Jan 2019 18:32:26 -0800 From: Jim Schaad To: 'Michael Richardson' , 'Esko Dijk' CC: References: <23266.1548345661@localhost> In-Reply-To: <23266.1548345661@localhost> Date: Thu, 24 Jan 2019 18:32:24 -0800 Message-ID: <00a901d4b456$36643130$a32c9390$@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: AQKPe14W3mTmO1gk9I6z01h4BEwvRAHW02qJpDr+wfA= Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Ace] WGLC for draft-ietf-ace-coap-est - optimization for embedded devices 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, 25 Jan 2019 02:32:35 -0000 As ACE co-chair, Of anybody on the mailing list believes that the document should not add a new CoAP content type for "application/pkix-cert" please speak up before next Monday. Jim > -----Original Message----- > From: Ace On Behalf Of Michael Richardson > Sent: Thursday, January 24, 2019 8:01 AM > To: Esko Dijk > Cc: ace@ietf.org > Subject: Re: [Ace] WGLC for draft-ietf-ace-coap-est - optimization for > embedded devices > > > Esko Dijk wrote: > > So to reduce code size for embedded implementations it would be very > > beneficial if the EST Server would support an additional content > > format: > > application/pkix-cert (see RFC 5280) > > So, to implement this in the specification, we need an additional Content- > Type value to be allocated. > > If we have WG Consensus to add this, then we can spin the document and > ask for another early allocation. > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > From nobody Fri Jan 25 04:34:22 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47755130DEA for ; Fri, 25 Jan 2019 04:34:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.032 X-Spam-Level: X-Spam-Status: No, score=-2.032 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, 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 Y--oxsAyQXmm for ; Fri, 25 Jan 2019 04:34:16 -0800 (PST) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-he1eur04on0719.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe0d::719]) (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 66E0712F295 for ; Fri, 25 Jan 2019 04:34:16 -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=kVebRnMpzDkcyzMyDm+Vv55Or4i9MKjUXHdg6hQUSYs=; b=sbfMI82V5+OjkTrWpQNMdkSK5becrcxjqIBDUJIZD8Sw6WzaNJMwUsPJqAKhd9rhTXtnSblzSWazOYqd6U0Ip1//UUJCHnzHxz/l0duPToZBL9eypAkwlRYKdQqxShTKMNa5flK7cZJkj3eHz0KuDQuKPdW5/QiZX6vgVHdDzfE= Received: from DB6P190MB0054.EURP190.PROD.OUTLOOK.COM (10.172.229.12) by DB6P190MB0343.EURP190.PROD.OUTLOOK.COM (10.175.242.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1537.29; Fri, 25 Jan 2019 12:34:12 +0000 Received: from DB6P190MB0054.EURP190.PROD.OUTLOOK.COM ([fe80::2d19:ef79:d153:7627]) by DB6P190MB0054.EURP190.PROD.OUTLOOK.COM ([fe80::2d19:ef79:d153:7627%6]) with mapi id 15.20.1558.016; Fri, 25 Jan 2019 12:34:12 +0000 From: Esko Dijk To: Michael Richardson , "Panos Kampanakis (pkampana)" , "ace@ietf.org" CC: Jim Schaad , "consultancy@vanderstok.org" Thread-Topic: [Ace] FW: WGLC comments draft-ietf-ace-coap-est-07 Thread-Index: AdSrtk3M3NcfgQ45QNualt2l/rHBKAAh1EAwAfAKqrcAKwJX4A== Date: Fri, 25 Jan 2019 12:34:12 +0000 Message-ID: References: <011501d4ac3d$ab2b9650$0182c2f0$@augustcellars.com> <0e5d254ced7242a69b4bd48a1c99442e@XCH-ALN-010.cisco.com> <22883.1548345549@localhost> In-Reply-To: <22883.1548345549@localhost> 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:d85f:76e9:4a30:d070] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB6P190MB0343; 6:No7kNsCndfe9DGKBxsrv+9pW9HhZX0IfeQX85Qvd78l8JJtOich+tgDwYUeFXQOB0mEKVvca3rkxwI4qpqT/5fyaUD4z00POa8gyWSsAfM6OrzYSX9+eFmM6xS+NKdoyAyQjxuDzpQiT+ekJ+MHgE2yoCjsknTNyJhqQxq7HtwrVVdbrmK5SC5TI9PUeSv0p+99AxhspZF1vJ6t4FNL+M1kIDl7MLlUTSRwYfaBdwdziphJVPrfq1kAdPjar3BOSU4W46TJw4L+PvvkuDSwN0/jvhS7orDXZwQzGXAiLFfvK/8ChByDOocONpU5dqIWfNdIY9CX62R9qOule10yuQ8CchjTgehv0uWkSy4skPItVN3LC+bzbddHPJoasi5eN1/IDckWCM/Xww1t/qncl1r9bCu0INaNNAIGLCGo9IeiW2Xc6dT/3MGKjcTv3h/kGOoARo71UnsiFDXM499VZCg==; 5:x8/XrphkYp+8abVtxNhZ6v/2zBkmxo46IuLR25OEF7HG6lgTttfIvt42TaHPxfh9Ifxg8+w9LQIqOf1aNLiEYAcgBYG3dOmmrwiSCRBmJuN8FO+SgfaZS/Qcf/wh0DxxswXnPbz5Bx7Uax0yDs2CFONl9kjcdUOmAfoI2O6wcAV5C14XqH5gz1GdntiFZalJozWDThaMXiXzbU1NfqCjGg==; 7:NdPY7SGAc4EapHZNUYn0l8qTKUgya6r462kBGXXGJhvGXtW+Cahj2fF0HyE7VkJ4cKBx6oq1DJeegcGW9P+KPF/bpT/RF5FBhd3ye3uhvy1kezJyk6Eghgcd8TqXWeYSDyoZy9YQyVuG7zfQWlTxtw== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 283117e3-a556-43a4-4ae8-08d682c16921 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(7021145)(8989299)(4534185)(7022145)(4603075)(4627221)(201702281549075)(8990200)(7048125)(7024125)(7027125)(7023125)(5600110)(711020)(4605077)(2017052603328)(7153060)(7193020); SRVR:DB6P190MB0343; x-ms-traffictypediagnostic: DB6P190MB0343: x-microsoft-antispam-prvs: x-forefront-prvs: 0928072091 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(39830400003)(396003)(366004)(136003)(346002)(13464003)(54094003)(199004)(189003)(54906003)(110136005)(6436002)(316002)(68736007)(2906002)(229853002)(8936002)(99286004)(8676002)(81156014)(81166006)(105586002)(7736002)(106356001)(305945005)(55016002)(25786009)(4326008)(508600001)(966005)(53936002)(6246003)(14454004)(6306002)(9686003)(74482002)(6116002)(33656002)(74316002)(2501003)(97736004)(71190400001)(71200400001)(486006)(44832011)(446003)(86362001)(46003)(11346002)(7696005)(102836004)(476003)(14444005)(256004)(76176011)(186003)(6506007)(53546011); DIR:OUT; SFP:1102; SCL:1; SRVR:DB6P190MB0343; 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-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: /S5JwQkrEYsO5m59zNku0fu6E+4ckEFkc8y3WAKngZZve/TCTNYBmdy8usQ+D4wTwFznV7AIN15zJ6cCsZt6dEhjd4kjbOZ/VIPbONmD1n9hh14WWJ0Ftm1bzv/AvLBFIcNuMY9PmqQPk+dz1Q8b/Fg38FJpQFIgEKqeL5a3Ll/EBj8vGoY41uHG5TJFMh0Mm47jB0cGuqgw6wzPvYLLRUiCq9Nsug5vwrZaRfEphx5xga6yWjCLQLAAorA4P9uyh/n1jDXPiCRsOYQo/cqMDv0OfHSJ6+AO7QT34Nhav//lumpgg6nYPNrzoXmI8ivPwJQYZbHOoVsSHHZchT/Q6ehE4AT8TlaTFYCFCT7BKdBsgf91E/j1/GX3ylIGH0UGvyrMeaYhONjN5VBuMnRzEj9/JByiDFxQYK2l9582UUs= 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: 283117e3-a556-43a4-4ae8-08d682c16921 X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Jan 2019 12:34:12.1404 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 58bbf628-15d2-46bc-820b-863b6774d44b X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6P190MB0343 Archived-At: Subject: Re: [Ace] FW: WGLC comments draft-ietf-ace-coap-est-07 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, 25 Jan 2019 12:34:21 -0000 DQo+IFRoaXMgaW1wbGllcyB0aGF0IGEgc2VydmVyIGlzIG5vdCByZXF1aXJlZCB0byBzdXBwb3J0 IC8ud2VsbC1rbm93bi9lc3QgV2UgYXJlIG5vdCBjbGVhciBhYm91dCB0aGlzLiAgSSB3b3VsZCBw cmVmZXIgdGhhdCB0aGUgc2VydmVyIEFMV0FZUyBzdXBwb3J0cyB0aGUgd2VsbC1rbm93biBuYW1l cywgc3VjaCB0aGF0IHRoZSBjbGllbnQgY2FuIHNraXAgZG9pbmcgcmVzb3VyY2UgZGlzY292ZXJ5 IGlmIGl0IHRoaW5rcyB0aGF0IHRoZSBleHRyYSBieXRlcyBpbiB0aGUgVVJMIG1hdHRlciBsZXNz IHRoYW4gYWRkaXRpb25hbCByb3VuZCB0cmlwIHRvIGRvIGRpc2NvdmVyeS4NCg0KQWdyZWUgdGhh dCB0aGUgc2VydmVyIE1VU1QgYWx3YXlzIHN1cHBvcnQgdGhlIC8ud2VsbC1rbm93bi9lc3QgcmVz b3VyY2UsIHNpbmNlIHRoYXQncyB0aGUgcmVzb3VyY2UgdGhhdCBieSBkZWZpbml0aW9uIGlzIHVz ZWQgZm9yIHVzZSBjYXNlcyB3aGVyZSBkaXNjb3ZlcnkgaXMgbm90IHZpYWJsZS4gIFNvIGlmIGEg ZmFpbHVyZSBvbiB0aGF0IHJlc291cmNlIG91Z2h0IHRvIHRyaWdnZXIgYSBkaXNjb3ZlcnkgYWN0 aW9uLCB0aGF0IHdvdWxkIGNvbnRyYWRpY3QgaXRzIHB1cnBvc2UuDQoNCkJlc3QgcmVnYXJkcw0K RXNrbyBEaWprDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBBY2UgPGFjZS1i b3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgTWljaGFlbCBSaWNoYXJkc29uDQpTZW50OiBU aHVyc2RheSwgSmFudWFyeSAyNCwgMjAxOSAxNjo1OQ0KVG86IFBhbm9zIEthbXBhbmFraXMgKHBr YW1wYW5hKSA8cGthbXBhbmFAY2lzY28uY29tPjsgYWNlQGlldGYub3JnDQpDYzogSmltIFNjaGFh ZCA8aWV0ZkBhdWd1c3RjZWxsYXJzLmNvbT47IGNvbnN1bHRhbmN5QHZhbmRlcnN0b2sub3JnDQpT dWJqZWN0OiBSZTogW0FjZV0gRlc6IFdHTEMgY29tbWVudHMgZHJhZnQtaWV0Zi1hY2UtY29hcC1l c3QtMDcNCg0KDQpodHRwczovL2dvby5nbC9MVDRIWWggIGlzIGEgZGlmZiBmcm9tIC0wNiB0byBj dXJyZW50Lg0KUGFub3MgaGFzIGRvbmUgYSBncmVhdCBqb2IgdXBkYXRpbmcgdGhpcyBhY2NvcmRp bmcgdG8gdGhlIGlzc3VlcyByYWlzZWQgZHVyaW5nIHRoZSBXR0xDLiBUaGFuayB5b3UNCg0KSSBo YXZlIHJlLXJlYWQgZGlmZnMgdG8gY2F0Y2ggdXAsIGFuZCBoYXZlIHRoZXNlIG1pbm9yIGF1dGhv ciB0d2Vha3MvcXVlc3Rpb25zLg0KDQo+IENsaWVudCBhdXRoZW50aWNhdGlvbiB2aWEgRFRMUyBD bGllbnQgQ2VydGlmaWNhdGUgaXMgbWFuZGF0b3J5Lg0KDQpJIHdvbmRlciBpZiB0aGlzIHNob3Vs ZCBnbyBpbnRvIGl0J3Mgb3duIHNlY3Rpb24gc28gdGhhdCBvbmUgY2FuIG1vcmUgZWFzaWx5IHNh eSwgIlBsZWFzZSBzZWUgc2VjdGlvbiB4LnkueiINCg0Kcy9lbnJvbG1lbnQvZW5yb2xsbWVudC8g ICA8LSB1c2UgQW1lcmljYW4gc3BlbGxpbmcsIEkgZ3Vlc3MuIFdlIGhhZCBib3RoLg0KDQpzZWN0 aW9uIDY6DQogICAgICAgIFJFUTogR0VUIC8ud2VsbC1rbm93bi9jb3JlP3J0PWFjZS5lc3QqDQoN CkkgZGlkbid0IGtub3cgdGhlIHRyYWlsaW5nICIqIiB3YXMgYSB0aGluZy4NCiAgPC9lc3Q+OyBy dD0iYWNlLmVzdCIsDQoNCkkgZ3Vlc3MgSSBoYXZlIHRvIHJlLXJlYWQgdGhlIENvcmUgTGluayBy ZXNvdXJjZSBkaXNjb3ZlcnkgZG9jdW1lbnQuDQpDYW4gYSBzZXJ2ZXIgcmVzcG9uZCB3aXRoIDwv PjsgPz8gaXQncyBzaG9ydGVyLCBhbmQgSSB0aGluayB3b3VsZCBiZSB2YWxpZD8NCg0KPiAgSWYN Cj4gICAgICAgICAgICAgICAgICAgICAgICB0aGUgZGVmYXVsdCByb290IHJlc291cmNlIHJlcXVl c3RzIGZhaWwsIHRoZSBjbGllbnQNCj4gICAgICAgICAgICAgIFNIT1VMRCBmYWxsIGJhY2sNCj4g ICAgICAgICAgICAgICAgICAgICAgICB0byBkb2luZyBhIHJlc291cmNlIGRpc2NvdmVyeS4gIFJl c291cmNlIGRpc2NvdmVyeQ0KPiAgICAgICAgICAgICAgU0hPVUxEIGJlIGVtcGxveWVkDQo+ICAg ICAgICAgICAgICAgICAgICAgICAgd2hlbiBub24tZGVmYXVsdCBVUklzIChsaWtlIC9lc3Qgb3IN Cj4gICAgICAgICAgICAgIC9lc3QvQXJiaXRyYXJ5TGFiZWwpIG9yIHBvcnRzIGFyZQ0KPiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc3VwcG9ydGVkIGJ5IHRoZSBzZXJ2ZXIg b3Igd2hlbiB0aGUNCj4gICAgICAgICAgICAgIGNsaWVudCBpcyB1bmF3YXJlIG9mIHdoYXQgRVNU LQ0KPiAgICAgICAgICAgICAgICAgICAgICAgIGNvYXBzIHJlc291cmNlcyBhcmUgYXZhaWxhYmxl IGJ5IHRoZSBzZXJ2ZXIuDQoNClRoaXMgaW1wbGllcyB0aGF0IGEgc2VydmVyIGlzIG5vdCByZXF1 aXJlZCB0byBzdXBwb3J0IC8ud2VsbC1rbm93bi9lc3QgV2UgYXJlIG5vdCBjbGVhciBhYm91dCB0 aGlzLiAgSSB3b3VsZCBwcmVmZXIgdGhhdCB0aGUgc2VydmVyIEFMV0FZUyBzdXBwb3J0cyB0aGUg d2VsbC1rbm93biBuYW1lcywgc3VjaCB0aGF0IHRoZSBjbGllbnQgY2FuIHNraXAgZG9pbmcgcmVz b3VyY2UgZGlzY292ZXJ5IGlmIGl0IHRoaW5rcyB0aGF0IHRoZSBleHRyYSBieXRlcyBpbiB0aGUg VVJMIG1hdHRlciBsZXNzIHRoYW4gYWRkaXRpb25hbCByb3VuZCB0cmlwIHRvIGRvIGRpc2NvdmVy eS4NCg0KDQotLQ0KTWljaGFlbCBSaWNoYXJkc29uIDxtY3IrSUVURkBzYW5kZWxtYW4uY2E+LCBT YW5kZWxtYW4gU29mdHdhcmUgV29ya3MgIC09IElQdjYgSW9UIGNvbnN1bHRpbmcgPS0NCg== From nobody Sat Jan 26 20:40:21 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8517128CE4 for ; Sat, 26 Jan 2019 20:40:19 -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=mit.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 nM_J227TyFSA for ; Sat, 26 Jan 2019 20:40:17 -0800 (PST) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-eopbgr790108.outbound.protection.outlook.com [40.107.79.108]) (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 02B5312896A for ; Sat, 26 Jan 2019 20:40:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=YKJ7B7gPnb0bjr9TBBZUMgjuDouXU/opht6SYli/NzU=; b=pPzEeURng6IWlvqeu4Pyb6NRJFZNuaX6KsLx3ddBZb9PHBAUqkcLBtkgBiYTbrQr3JXgw3enqkWrHoscNEohRk1Q8tL1dU6sKVP7hy5KLd2InpIR9xTo+D6jqlLdBQe5VA8o0nyGED0Hfgv+ayI6yyJh6L66E60cajoYKYn4ESg= Received: from BL0PR0102CA0035.prod.exchangelabs.com (2603:10b6:207:18::48) by BL0PR01MB4484.prod.exchangelabs.com (2603:10b6:208:81::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1558.21; Sun, 27 Jan 2019 04:40:12 +0000 Received: from BY2NAM03FT038.eop-NAM03.prod.protection.outlook.com (2a01:111:f400:7e4a::205) by BL0PR0102CA0035.outlook.office365.com (2603:10b6:207:18::48) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1558.16 via Frontend Transport; Sun, 27 Jan 2019 04:40:12 +0000 Authentication-Results: spf=pass (sender IP is 18.9.28.11) smtp.mailfrom=mit.edu; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=mit.edu; Received-SPF: Pass (protection.outlook.com: domain of mit.edu designates 18.9.28.11 as permitted sender) receiver=protection.outlook.com; client-ip=18.9.28.11; helo=outgoing.mit.edu; Received: from outgoing.mit.edu (18.9.28.11) by BY2NAM03FT038.mail.protection.outlook.com (10.152.84.170) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1580.10 via Frontend Transport; Sun, 27 Jan 2019 04:40:11 +0000 Received: from kduck.mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x0R4e7R4032337 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 26 Jan 2019 23:40:09 -0500 Date: Sat, 26 Jan 2019 22:40:07 -0600 From: Benjamin Kaduk To: Hannes Tschofenig CC: Ludwig Seitz , Jim Schaad , 'Stefanie Gerdes' , "ace@ietf.org" Message-ID: <20190127044007.GL49072@kduck.mit.edu> References: <9f35177f-30d4-817e-dfc3-9a54903ab023@ri.se> <035a01d497d8$941fa920$bc5efb60$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:18.9.28.11; IPV:CAL; SCL:-1; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(376002)(396003)(136003)(346002)(39860400002)(2980300002)(13464003)(189003)(199004)(2906002)(4326008)(478600001)(26826003)(6916009)(53416004)(93886005)(88552002)(6246003)(46406003)(33656002)(75432002)(106466001)(50466002)(47776003)(23726003)(55016002)(229853002)(246002)(305945005)(8676002)(8936002)(316002)(7696005)(36906005)(104016004)(15650500001)(356004)(86362001)(26005)(54906003)(97756001)(426003)(186003)(476003)(1076003)(11346002)(446003)(486006)(956004)(336012)(106002)(126002)(58126008)(16586007)(786003)(14444005)(53546011)(76176011)(18370500001); DIR:OUT; SFP:1102; SCL:1; SRVR:BL0PR01MB4484; H:outgoing.mit.edu; FPR:; SPF:Pass; LANG:en; PTR:outgoing-auth-1.mit.edu; MX:1; A:1; X-Microsoft-Exchange-Diagnostics: 1; BY2NAM03FT038; 1:L6dyoeSCCnlYNM2YNFw0c7xZIdCO3H80l7ZbRKvTBz2ADwLmnsRq3NKNgVMjV9rlewT0SrSbrVRDd25HmTTW+xEdW+1XMctjKG+b3X2enI5z91cv4OesdJPvwuW2kfDjWK0fVKYnVA+2v5Yw9YwSHr29QvbBr2+D8dSOX3FLg+I= X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 7a45a650-54ce-451a-2e90-08d684118625 X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605077)(4608076)(4709027)(2017052603328)(7153060); SRVR:BL0PR01MB4484; X-Microsoft-Exchange-Diagnostics: 1; BL0PR01MB4484; 3:Lrb3UGxL2GYWhQ+eYfHAEcckYLmHniTLbiorVD0kx6UMEuAj9SsqziD/vOnCFIE4IxF9kxSZ48Iny6cIyhh94xGCbC9IAbEIAy75gl4AjyPmpAJtPwcj0afHPIyRXcsTwjO5lEEAidrJZNFR0shfcNSY2lV5YhIcXVyTYhJup3a/xn/FhGqqbRfOsjl6QDRiAufzWT2iXkOVGQgZc69Ozr5N+7z/4MyG+m9V1baVVQcy3JhMKsT8eh8Xspo7BqVmt4FlPViE0AoTOEBlx+2tox5dPEYLjRWJrC2tn31r38Jtu4WWiUgplV6mSiN8/lMD73oIH4DDnYlh98syTLo4qAoYsMO0XGkMrtTwf9xb22/lmB0R2GdLDtkDkjmdTRMy; 25:HEyVQNLuTdFhXdvQY1vlt1gq+XL2l9mpTp4un6IO86AaSmL46QhvmJoJy9mrWQnZr807wv3V/0i6ildI7lCmiGZgsF/pDt5BLZ2v39gTdMbKUEK6qfm96loClwIkMveK9frOcF3V6Ty4DPbaKjbufs/6IzZS+7VY0vegBVj1bTcUirGd73UbLZ99BN2KFMlmHOaxotXoGWhSSRlFfiZasqSrL15ONm3u1USCyduv9h/+jsrr//YWPT/E8suUYHGRhPSNNoZB562ZPMlMD+7KPdxOGN1jdEzVK0fLvTOA6RgXOaMBSQFCoaKasg+YXXaGCRQClucP8B/UsGEUhxRzUw== X-MS-TrafficTypeDiagnostic: BL0PR01MB4484: X-Microsoft-Exchange-Diagnostics: 1; BL0PR01MB4484; 31:4sfgM9ahbjVZco2c+H6avzmUZrs9pyvfKJ77Wm2e7yQdKl7akLy+7lSx5U6HmMqYdio5bLF9nkIBIRnXY8G+aPQS5yDlEAoC0csR3mPr5B0o95Qjso9sQjOFJHnoLQcwRUAztTXrscRqSkaxjJEmHQ6reaM+NTE5nfuiJRnD3UG++tVIFWR7y42Kim+clbNYV0zIZG1tX4xQBrrWNeZbiCBeldfOWoK5QwsU52jAiXQ=; 20:eGZgCTw7V8KyxAssv8fsMhjwVhTCirbLuDUNmFvE7vqp57lNVavoBt+y8OtiB2R6nQjI6o2tH8iWNJCDRzCcLXZTQjj/Vvfe6G3DEHOkLNBZ4VuJanwPZkdS0I2BHCOLNIFwGrC2lvOOSxOyX8Liff9nBPZaQlPmlVKftH42bnzCN6V2S1GU9drhhSx/fqgXqHwp4daCFOu+Qpp2PbOGI+bnmtzZu+He8uNJkL7nCh1KfswimPuekE8GpbibIwuYFY1domme4iQAnsT6nk+V3qNjFLOnzPfXpLDk/OmZAFmmB85k3dk0Jy4ap+pd4f6v0Gc6jEcdRS0k08TgitfyK9zjxWCEcOVoqnwzJRNAxpIv6u+5flEtsAUU1xQtdoCGYw0ziXW/4KV6pRF5XsizMBEbXa1gDBoTGsFPv6RZD0vcv0ZbWKAGJv0kEwOC9ko+r7Um0OrvV7WMo+ilRf1Y4DP2O7lDfSoeEXzfaxfFlL89ALaURaQBYqF4GEWueKzb239IY4M53TtdYCfTU9xIb5N3/mlTN7MihJqGgP/AfV2auuwuLdPDOuFoMaO3hRMF8cZmpoXeoxt5TzJCgTR1SB96zDRMpa+F9poPzh3jrnw= X-Microsoft-Antispam-PRVS: X-Microsoft-Exchange-Diagnostics: 1; BL0PR01MB4484; 4:c+o+Zp94uMW9vunAo5INRM2t5Cti1LxWy1sSBPadsBGX42mP3E3ftEmt00/JxXgLKmfIRA0yJQHRLSNaEKmaQS3JIuysJZtnuUReDx/h/C++SIi7SRmGoegs7XZt5KhD5nLNxNdT9N4szSXNw6Qu99GEEBdo4jPqvbXzyA/S6ZTAQJYlSMU3GQrmH8WZIQX/2DV3LPdzgZWrALCGw+82u05KN5q1Vzg4nbgJlMeIrzwU3ut8gcoDBoavjPEpOKmM97yn7/g6ihkdtpW+QFqoU6fu16bV0oWjKMKoOZ5csGchQ67BoC37tIsc74zPstYc X-Forefront-PRVS: 0930AAFAD9 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BL0PR01MB4484; 23:XnYdo8XSKTwUCenI3aKLESdM4/g9xhi3JgLVGi5Y7?= =?us-ascii?Q?Z69AgBWpQWRl9WCMnnQ+t5TS9hVB3Z8jSyXCnKuFdFwEtKbAylq3CTrS71Tu?= =?us-ascii?Q?yQydyd9h/uMfXaJAQC0fg1lorCmLrwv7taQSNFF/J2O3ipho8GLE/InKbJqb?= =?us-ascii?Q?GaINi9Yq/ALAFEc06pv2o2DnAdw8xgp+3oPLSTSfWDF4Mb3RLzyH6IJqaYeb?= =?us-ascii?Q?h5GzqUXjEc+Hj+ahJgPqRLYdHfkcIRgr6+XShC8McMVcSIN924YIcztemfMU?= =?us-ascii?Q?FTYUU2JNJoNvAasFMmvLq3+6XUsl4I5EtkEAoGEIBBTa/9sfyNClqT4EPwAM?= =?us-ascii?Q?84lPKjk+TmQN+y7jg17CKsgsN+Jew9BStdnU0RygZUYdlkcaNTbZIj/R9Onm?= =?us-ascii?Q?8uyqOhqXZR9PmmC12jd7ynymwSPJE9MuRK/ycILkfI4tme0z74OBXTHGgpaS?= =?us-ascii?Q?rZLKZYhCNbRDRwB6R2FRQO5PH+L4Ups/u1YQoOZKF71n34/YLEi/QhWAfSuX?= =?us-ascii?Q?d5oiCdOwomqJu5M4Mf5Mx/vf3/3oPIZFYyFoXEXdO+FxgUtYHsoKpE1qKY38?= =?us-ascii?Q?g51nVDSGWVn3UVFd9Vz4lC9CJfkTHFehEB56U1OFR6SwoqLx3xTOJhjLKGEX?= =?us-ascii?Q?h1hcV6l0uPrD0YheZmh8m7M+6eT10+BWShYRbYo4Im3oHXe3hSEOP6Yhi031?= =?us-ascii?Q?qkTh5Amr8TKOaLdtk7vfoQ5LU7EIuKOszuLnwY2yXly5I/tugLiI06GsNW6p?= =?us-ascii?Q?aLvm2zT3Cpe36E+IWz10alBIRFRpOkIq8FEoager8PXX8RiSJdOQizBXIQC8?= =?us-ascii?Q?TuF5IEQPHaQQuM8Uc8Ct0oS0Fm1aqf/QrD9YvdSMvchrdsjFc5+IgztbQnKt?= =?us-ascii?Q?DSqIyXYnwjDpttxwzKxx+irjFgS5lvtx9helQNwk15dSKbNqnbubzmW+57jA?= =?us-ascii?Q?FIgc8nkYLpJ2OEhd9a0yX5GKA+2Z7EWlA9K3PYeZ2VqcwvDugcnnviB3/cp+?= =?us-ascii?Q?DwZySCQKM8paaKd3vTpIyxzD/H56mCBRH1BF3xelLi6ra2P1wFJuoxjuIJqm?= =?us-ascii?Q?FZEM1DbzPExe3GExAi++IbuximSWeQ6R1YtvYJu0yPzrLfQ6xcEVzM8kO6/b?= =?us-ascii?Q?JMHtiiLidxCmbSyWrtDJkZLFUJYKvKEBnlEGElXkawIO1MKGTpNwgychJVxd?= =?us-ascii?Q?CjLxyHgT6vUPzt2wbUFYCC/dUhxXr0ZxG27gAAW1dvRG2UVyyTsWpdNBaAiT?= =?us-ascii?Q?a44WimTq7FYojTOaSrqC06DGQkVoCtfwR1Q/Pyxs8U58XUCS3Pg8EDzreN+t?= =?us-ascii?B?UT09?= X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Message-Info: myPOJkGMP9txGucf9Lxb78aPe5/tCEaTA/eC0dAZw4AbJopPQzdxscUS2bzfHNXuDwemtmAuVkOt+Tw575Ioxnq02nfHY4VAQKhkA9/ndAzvEXexcga7GhrIUQG0GNdNbJR441P2MZsrpEuLmq1ErcL+uoP67ye3nBZEEmRU6h+pgGzN+i65ctJp5EwMqDUV5oPD9/3kjE7XLZLglWWq0KUoQadtJO70efAQFs9VF9AuPI5gVfUgHqvDYMcPTHIo83Jal57i4jCaxZkD9lH7+o7GYwpjgUckGqj3nlz4T8pVMnqiVacSNrLllWaTNSLTPbEEeKjn/Tc0j4Xx9bKKmM9wmVukLkLCVv7L2u56hFU6PX/8pUWZnI4EKotOKMLWt9w7iUB6YtroQjXX/Bk8czKMG6cDoYWvVl6YS4ulo3E= X-Microsoft-Exchange-Diagnostics: 1; BL0PR01MB4484; 6:0aEFPM7qJRKA7K3hjtDRGeszwGsc1447gaILZOn76J3Fl/2uuuQ0Q5bnJKa+leIqqUT+8Sstke66s+D3LaDVdDLDQSH+34SMwBeH5ybeM8L7mi/tbPf78nJ9dIi71gYDfKD6PAfPMQJ3Sh6L4CDbjc8CLpBysC+j+18ne9YLWcX+1e1+cL35xJxbOb7yUasKgaxNnIyGkkB4mP9PpdrLUMkvK6h/0znuso3LoNHoxNgX67ttu9zXXHLgquXh85+jLcpnLezFYUgjAJ0gmibwn1C7LXGTD7PW2ud2pLPNd+BXnjqXvKPMaSd7znIPPLU4SasD1SAGeEA4y9U/hbOc1vvZAxgVqb7FYdeKSvz5gYqGWjjLNbJQPE8rBtf1XRUH8XsPaJi0Xz+2VzMQKaxbgVCme6iopxifdhnOwBeR8k6p6WahELC6YDw5pU+8mLyQgoHE/sElZxN4g/83CIG5bQ==; 5:HdjlTedqyt7+FD2+lxY+aKFYVyCwA4umD2MbVfDNveoN7x1miU+zZJObXw0sjNnjWBFPeU98W9tStCt0DN+yMsILTlkdDO5fpGmrotET6f2ihQAec2wnwjgS2LicYoSV4yc2Uo2jXATzAEkHxK6yec5PkEEEYCUZf1Qo1jU2nkCx9LrYMNPq/wHLiMCPADwAQtqs3lZoElXqg8nBE4fAuA==; 7:OZb3l2G0Kq2mnXjMIsM7HySD7zc+u9IUvHxDjgDmAwg0kx/SS1FLjZrbWLo5OMLidtEUT6VLlNBl3Syhht8W/dOQmklem9lnehRRWF3HcNPVR9mrQ4bSfrWaxFR0HlxxJTeqI/W0LDoNHSs9wcG/+w== X-OriginatorOrg: mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Jan 2019 04:40:11.5494 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 7a45a650-54ce-451a-2e90-08d684118625 X-MS-Exchange-CrossTenant-Id: 64afd9ba-0ecf-4acf-bc36-935f6235ba8b X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=64afd9ba-0ecf-4acf-bc36-935f6235ba8b; Ip=[18.9.28.11]; Helo=[outgoing.mit.edu] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR01MB4484 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: Sun, 27 Jan 2019 04:40:20 -0000 On Thu, Dec 20, 2018 at 09:11:24AM +0000, Hannes Tschofenig wrote: > > -----Original Message----- > From: Ludwig Seitz > Sent: Donnerstag, 20. Dezember 2018 08:40 > To: Jim Schaad ; Hannes Tschofenig ; 'Stefanie Gerdes' ; ace@ietf.org > Subject: Re: [Ace] Security of the Communication Between C and RS > > On 19/12/2018 21:22, Jim Schaad wrote: > > > > 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? > > [Hannes] We definitely need some more details about the type of attack we would like to prevent. Maybe it is worthwhile to think about what information the attacker steals from whom at what point in time could be a way to progress the topic. It is perhaps contrived, but one scenario in which the PoP key could be exposed to an attacker or third party is if some sort of post-facto auditing service is in play, where the "previous generation" of key material is released to an auditing service, after expiration or key rollover has occurred. This third party would then be able to audit network traffic (whether for intrusion detection or other purposes) but not modify any live traffic. Such a scheme has been proposed in the context of TLS (though I'm not finding a good reference in the archive; maybe it was just at a mic line?), though not with any great degree of seriousness AFAIK. -Ben From nobody Mon Jan 28 02:05:42 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC7FB130FFB for ; Mon, 28 Jan 2019 02:05:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.041 X-Spam-Level: X-Spam-Status: No, score=-2.041 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 tALTHmTe7TrU for ; Mon, 28 Jan 2019 02:05:38 -0800 (PST) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50066.outbound.protection.outlook.com [40.107.5.66]) (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 27FC4130FF9 for ; Mon, 28 Jan 2019 02:05:37 -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=xthVJ7QUW3nY52CQgW2Ghhm8mmfFhsSz7f+vwHykceI=; b=jISObIirrQ/Fi+4S9ofI5tWLIL1NZzir/uChfhBaZ2FWH4oa5n+RpusziBVJWign5YeP3hIy8Nts52b/RNRBgyKaPyAUTPIl9xgs0DkkWi2iknvwFAOeagbRxxFOmBt66d9cf51BCV2DBkU/m/ExFrVzaTxNF3po8cjLk+dxj3M= Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB1663.eurprd08.prod.outlook.com (10.168.66.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1558.21; Mon, 28 Jan 2019 10:05:35 +0000 Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::3ce6:d8fa:3271:6019]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::3ce6:d8fa:3271:6019%7]) with mapi id 15.20.1558.023; Mon, 28 Jan 2019 10:05:35 +0000 From: Hannes Tschofenig To: Grace A Lewis , "ace@ietf.org" Thread-Topic: ACE Implementation for Disadvantaged Environments Thread-Index: AQHUs0cwxz8vJeWIVUGFns83Bt0/66XEercQ Date: Mon, 28 Jan 2019 10:05:34 +0000 Message-ID: References: <11C08BF5-0060-459C-99DC-EABEA88DF44B@sei.cmu.edu> In-Reply-To: <11C08BF5-0060-459C-99DC-EABEA88DF44B@sei.cmu.edu> 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.119.167] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0801MB1663; 6:g/CLMSDe+iPcpBSpgTl6wlBYtI0IPs/87+q3MNmptBWgGcCLZYrghembQLoAYzN4gx8gZYpYxMovHXReqVD4jurvWd+sDNP9lW0jKLPsEWjLQC5IjIU8qQI/1zFQx5BbJ7nzfRVrov3BCrHEAAu4ZA6u3jpgat48t6r9uTOSnALrC5JGYr9VNWDwkWmvUwZtC1Yb45SdTT9G6AN52f86ub5xkli62bTfOmRzEmIAywAdMJe8jFm84t4FIIyo3a09oM1XehMO3WDJq2rkQv4T0slZ0UIR4oTro6qpvo7z3hNJ4ItOyRueqMJEhtZ5QWJHWE6Bj7JDNHB4JHaDc/hHNNqEj95SmF3qYoYpIeeB3yStlMhgXoNIv7go7UvqxYrsX8q7+kaHf9Hh/NgbhS851dTdJF6ZVPIidy20+2vPoIh92RZm4k1NG2MPDz95P7tWEbzYY2SgTCGZ8DsvqlJsVw==; 5:UPIFC5Xylny9UGBiDvdOp3D50vT9iiVJ6Pz+McJqOC5LpXwO4qwhMm5zTNJ4lNKXh5jG46irosIIMftc8UTH0i9dre3I2ZM9+XBRmtX+j5ENcWg/4pYch6Q3Kit5H5Xy5qpKPd40RSgQ/YSw5xYnggs6e7c/B7HOTNy2tBh/5ioGy2SDgqf+akPYBm9XsGS0/9e1lVXwpVg7X7HVe2xaKQ==; 7:VnnJ2UPeN551x07ZXogGxo6qsuadEXgZj34HB47suq9DURKnFUBrV/6Kndk6qrjT54y7dC7wzXj3VgYZs8WoNS03D/GL+3OmQTkuCAlN+MmLrW4G2edyFahkOyOGXJ78p1mkPbS7NID3SfreHrgxKw== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: c4731f37-68b2-4094-1a67-08d68508253d x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605077)(4618075)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB1663; x-ms-traffictypediagnostic: VI1PR0801MB1663: x-microsoft-antispam-prvs: x-forefront-prvs: 0931CB1479 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(396003)(39850400004)(346002)(376002)(136003)(189003)(199004)(40434004)(81156014)(486006)(7696005)(74316002)(53546011)(186003)(6506007)(102836004)(6436002)(229853002)(6116002)(11346002)(33656002)(476003)(446003)(86362001)(966005)(8936002)(14454004)(99286004)(316002)(8676002)(2906002)(72206003)(81166006)(105586002)(3846002)(26005)(790700001)(76176011)(478600001)(110136005)(7736002)(14444005)(256004)(5024004)(25786009)(9686003)(606006)(68736007)(2501003)(53936002)(2171002)(66066001)(6246003)(236005)(54896002)(55016002)(71190400001)(106356001)(97736004)(71200400001)(6306002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB1663; 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-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: Z0OT2ef0EK5kYN1UDuKntUQ5mioNHq9EBFj/ydVy2Bk0gaKfmYQMIk+ksprwQeIwYE/Tvo1PhFMniNdFsUXTJatqP9dPfPiLWtsswBUi26fYtYNrfNUt+fQqw46psci+4xI4RjMFf0AbOtmHzMDpzG++lrhxhSxHkSYCfnYRMeXgjxh+3NH10jq24lAO+j45haODK3GOQhgSe+jyyhO8d1QS2bQsUSdD2YnZcATpj7G9fH4yPUXM10CtBlEJ/xYkI/5vP+rgaCOONKvdrM5hU/6uZOU9VLqtG5rQx9eLVy9/mW5HPsKsxuN9iTA9bD0muda8/StbFevhQNm5OeyXYQMp8fx9f72zvjl15LhGEkELoGQ1pq4oAvqbeu4jCQSpeM8U/Gqs2MPmFPD5wRNJXiRZ9cZb8g/VqkcCay4MGP8= Content-Type: multipart/alternative; boundary="_000_VI1PR0801MB211293C28BD614D6CD8D7254FA960VI1PR0801MB2112_" MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: c4731f37-68b2-4094-1a67-08d68508253d X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Jan 2019 10:05:34.9716 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1663 Archived-At: Subject: Re: [Ace] ACE Implementation for Disadvantaged Environments X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2019 10:05:41 -0000 --_000_VI1PR0801MB211293C28BD614D6CD8D7254FA960VI1PR0801MB2112_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Q29uZ3JhdHMgdG8gdGhlIHdvcmsuIENvdWxkIHlvdSBzYXkgYSBsaXR0bGUgYml0IHRoZSAoY29u c3RyYWluZWQpIHJlc291cmNlIHNlcnZlciBpbXBsZW1lbnRhdGlvbj8NCg0KQ2lhbw0KSGFubmVz DQoNCkZyb206IEFjZSA8YWNlLWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiBHcmFjZSBB IExld2lzDQpTZW50OiBNaXR0d29jaCwgMjMuIEphbnVhciAyMDE5IDE5OjEyDQpUbzogYWNlQGll dGYub3JnDQpTdWJqZWN0OiBbQWNlXSBBQ0UgSW1wbGVtZW50YXRpb24gZm9yIERpc2FkdmFudGFn ZWQgRW52aXJvbm1lbnRzDQoNCkhlbGxvLA0KDQpJIGp1c3Qgd2FudGVkIHRvIG1ha2UgdGhlIGdy b3VwIGF3YXJlIG9mIG91ciBBQ0UgaW1wbGVtZW50YXRpb24gKFNFSS1BQ0UpLCB3aGljaCBpbmNs dWRlcyBhbiBpbXBsZW1lbnRhdGlvbiBmb3IgYSByZXNvdXJjZS1jb25zdHJhaW5lZCBzZXJ2ZXIu DQoNCkRldGFpbHMgYXZhaWxhYmxlIGluIHRoaXMgbmV3cyBhcnRpY2xlOiBodHRwczovL3d3dy5z ZWkuY211LmVkdS9uZXdzLWV2ZW50cy9uZXdzL2FydGljbGUuY2ZtP2Fzc2V0aWQ9NTM5MTg0DQoN CkFydGljbGUgaW5jbHVkZXMgdGhlIGxpbmsgdG8gb3VyIEdpdCByZXBvLg0KDQpFbmpveSENCg0K LSBHcmFjZSBMZXdpcw0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQpHcmFjZSBBLiBMZXdpcywgUGguRC4NClByaW5jaXBhbCBSZXNlYXJjaGVyIGFuZCBU VEcgSW5pdGlhdGl2ZSBMZWFkDQpDYXJuZWdpZSBNZWxsb24gU29mdHdhcmUgRW5naW5lZXJpbmcg SW5zdGl0dXRlDQpTb2Z0d2FyZSBTb2x1dGlvbnMgRGl2aXNpb24gKFNTRCkNClRhY3RpY2FsIFRl Y2hub2xvZ2llcyBHcm91cCAoVFRHKQ0KDQo0NTAwIEZpZnRoIEF2ZS4gIzU0MTINClBpdHRzYnVy Z2gsIFBBIDE1MjEzDQpQaG9uZTogKDQxMikgMjY4LTU4NTENCmh0dHA6Ly93d3cuc2VpLmNtdS5l ZHUvc3RhZmYvZ2xld2lzDQoNCuKAnEEgY2hhbmdlIGluIHBlcnNwZWN0aXZlIGlzIHdvcnRoIDgw IElRIHBvaW50c+KAnSAtLS0gQWxhbiBLYXkNCklNUE9SVEFOVCBOT1RJQ0U6IFRoZSBjb250ZW50 cyBvZiB0aGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbCBhbmQg bWF5IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lw aWVudCwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBkbyBub3QgZGlz Y2xvc2UgdGhlIGNvbnRlbnRzIHRvIGFueSBvdGhlciBwZXJzb24sIHVzZSBpdCBmb3IgYW55IHB1 cnBvc2UsIG9yIHN0b3JlIG9yIGNvcHkgdGhlIGluZm9ybWF0aW9uIGluIGFueSBtZWRpdW0uIFRo YW5rIHlvdS4NCg== --_000_VI1PR0801MB211293C28BD614D6CD8D7254FA960VI1PR0801MB2112_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkRlbmdYaWFuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAx IDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUg NSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxARGVuZ1hpYW4i Ow0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZh bWlseTotd2Via2l0LXN0YW5kYXJkOw0KCXBhbm9zZS0xOjAgMCAwIDAgMCAwIDAgMCAwIDA7fQ0K QGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpPcHRpbWE7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMg Ki8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBj bTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlv bjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojOTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0K CXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJ bWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4t bGVmdDowY207DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fu cy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUyMA0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25s eTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4w cHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5X b3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0 ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEw MjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo YXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAv Pg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFu Zz0iRU4tR0IiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9Ildv cmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdCI+Q29uZ3JhdHMgdG8gdGhlIHdvcmsuIENvdWxkIHlvdSBzYXkgYSBsaXR0bGUgYml0 IHRoZSAoY29uc3RyYWluZWQpIHJlc291cmNlIHNlcnZlciBpbXBsZW1lbnRhdGlvbj8NCjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Q2lhbzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0Ij5IYW5uZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFF MSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+RnJvbTo8L3Nw YW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+IEFjZSAm bHQ7YWNlLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7DQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkdyYWNlIEEg TGV3aXM8YnI+DQo8Yj5TZW50OjwvYj4gTWl0dHdvY2gsIDIzLiBKYW51YXIgMjAxOSAxOToxMjxi cj4NCjxiPlRvOjwvYj4gYWNlQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFtBY2VdIEFD RSBJbXBsZW1lbnRhdGlvbiBmb3IgRGlzYWR2YW50YWdlZCBFbnZpcm9ubWVudHM8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkhlbGxvLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5JIGp1c3Qgd2FudGVk IHRvIG1ha2UgdGhlIGdyb3VwIGF3YXJlIG9mIG91ciBBQ0UgaW1wbGVtZW50YXRpb24gKFNFSS1B Q0UpLCB3aGljaCBpbmNsdWRlcyBhbiBpbXBsZW1lbnRhdGlvbiBmb3IgYSByZXNvdXJjZS1jb25z dHJhaW5lZCBzZXJ2ZXIuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkRldGFpbHMgYXZhaWxhYmxlIGluIHRoaXMgbmV3 cyBhcnRpY2xlOg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuc2VpLmNtdS5lZHUvbmV3cy1ldmVudHMv bmV3cy9hcnRpY2xlLmNmbT9hc3NldGlkPTUzOTE4NCI+aHR0cHM6Ly93d3cuc2VpLmNtdS5lZHUv bmV3cy1ldmVudHMvbmV3cy9hcnRpY2xlLmNmbT9hc3NldGlkPTUzOTE4NDwvYT48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dCI+QXJ0aWNsZSBpbmNsdWRlcyB0aGUgbGluayB0byBvdXIgR2l0IHJlcG8uPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQi PkVuam95ITxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0Ij4tIEdyYWNlIExld2lzPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6IzAwMDA3 RiI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzwvc3Bhbj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2siPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5Ok9wdGltYTtjb2xvcjojMDAwMDdGIj5HcmFj ZSBBLiBMZXdpcywgUGguRC48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90Oy13ZWJraXQtc3RhbmRhcmQmcXVvdDssc2VyaWY7 Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTpPcHRpbWE7Y29sb3I6IzAwMDA3RiI+UHJpbmNpcGFsIFJlc2VhcmNoZXIg YW5kIFRURyBJbml0aWF0aXZlIExlYWQmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8L3NwYW4+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90Oy13ZWJraXQtc3RhbmRhcmQmcXVvdDssc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTpPcHRpbWE7Y29s b3I6IzAwMDA3RiI+Q2FybmVnaWUgTWVsbG9uIFNvZnR3YXJlIEVuZ2luZWVyaW5nIEluc3RpdHV0 ZTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7LXdlYmtpdC1zdGFuZGFyZCZxdW90OyxzZXJpZjtjb2xvcjpibGFjayI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5Ok9w dGltYTtjb2xvcjojMDAwMDdGIj5Tb2Z0d2FyZSBTb2x1dGlvbnMgRGl2aXNpb24mbmJzcDsoU1NE KSZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7LXdlYmtpdC1zdGFuZGFyZCZxdW90OyxzZXJpZjtjb2xvcjpibGFj ayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5Ok9wdGltYTtjb2xvcjojMDAwMDdGIj5UYWN0aWNhbCBUZWNobm9sb2dpZXMgR3JvdXAgKFRU Ryk8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90Oy13ZWJraXQtc3RhbmRhcmQmcXVvdDssc2VyaWY7Y29sb3I6YmxhY2siPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDstd2Via2l0LXN0YW5kYXJkJnF1b3Q7LHNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6T3B0 aW1hO2NvbG9yOiMwMDAwN0YiPjQ1MDAgRmlmdGggQXZlLiZuYnNwOyM1NDEyPC9zcGFuPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDst d2Via2l0LXN0YW5kYXJkJnF1b3Q7LHNlcmlmO2NvbG9yOiMwMDAwN0YiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTpPcHRpbWE7Y29sb3I6 IzAwMDA3RiI+UGl0dHNidXJnaCwgUEEgMTUyMTMgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsmbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90Oy13ZWJraXQtc3RhbmRhcmQmcXVv dDssc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTpPcHRpbWE7Y29sb3I6IzAwMDA3RiI+UGhvbmU6ICg0MTIp IDI2OC01ODUxPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5Ok9wdGlt YTtjb2xvcjojMDAwMDdGIj48YSBocmVmPSJodHRwOi8vd3d3LnNlaS5jbXUuZWR1L3N0YWZmL2ds ZXdpcyI+aHR0cDovL3d3dy5zZWkuY211LmVkdS9zdGFmZi9nbGV3aXM8L2E+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5Ok9wdGltYTtjb2xvcjojMDAwMDdGIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxp PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTpP cHRpbWE7Y29sb3I6IzM4NTcyMyI+4oCcQSBjaGFuZ2UgaW4gcGVyc3BlY3RpdmUgaXMgd29ydGgg ODAgSVEgcG9pbnRz4oCdIC0tLSBBbGFuIEtheTwvc3Bhbj48L2k+PHNwYW4gbGFuZz0iRU4tVVMi PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KSU1QT1JUQU5UIE5PVElDRTogVGhlIGNv bnRlbnRzIG9mIHRoaXMgZW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBhcmUgY29uZmlkZW50aWFs IGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQg cmVjaXBpZW50LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIGRvIG5v dCBkaXNjbG9zZSB0aGUgY29udGVudHMgdG8gYW55IG90aGVyIHBlcnNvbiwgdXNlIGl0IGZvciBh bnkgcHVycG9zZSwNCiBvciBzdG9yZSBvciBjb3B5IHRoZSBpbmZvcm1hdGlvbiBpbiBhbnkgbWVk aXVtLiBUaGFuayB5b3UuDQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_VI1PR0801MB211293C28BD614D6CD8D7254FA960VI1PR0801MB2112_-- From nobody Mon Jan 28 07:07:16 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E7A3124C04 for ; Mon, 28 Jan 2019 07:07:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 os0Z0A5lqyv5 for ; Mon, 28 Jan 2019 07:07:10 -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 D0827124BE5 for ; Mon, 28 Jan 2019 07:07:09 -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 x0SF76lZ028905; Mon, 28 Jan 2019 10:07:06 -0500 DKIM-Filter: OpenDKIM Filter v2.11.0 taper.sei.cmu.edu x0SF76lZ028905 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sei.cmu.edu; s=t52kn2igOmwp; t=1548688026; bh=9af1K6PTdkr3VKNurV3T0u8MeXKvlEu064xUfdzHVcU=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=pp+sQrWf8ex/UaQyCLRNg9fNpCtUEYmw7lNa6VCVNFIWzvH+18MqtQUy0q8vrtFe4 5EPnrBUjg/po2iwXohighv56VTAXiTXO4tNWi78Id8VoArNB6HKolWd6aLQnWdvzLH fO0RXcaOvh2B4qO+/7homLFwnE7YO9rf4drx6T9k= Received: from CASCADE.ad.sei.cmu.edu (cascade.ad.sei.cmu.edu [10.64.28.248]) by delp.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x0SF60WO040740; Mon, 28 Jan 2019 10:06:26 -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.0435.000; Mon, 28 Jan 2019 10:06:17 -0500 From: Sebastian Echeverria To: "Hannes.Tschofenig@arm.com" CC: Grace A Lewis , "ace@ietf.org" , "Dan Klinedinst" Thread-Topic: ACE Implementation for Disadvantaged Environments Thread-Index: AQHUs0cwxz8vJeWIVUGFns83Bt0/66XEercQgAA76QCAABjZAA== Date: Mon, 28 Jan 2019 15:06:17 +0000 Message-ID: <7387610A-D857-49FE-9964-77D54CDDA2F4@sei.cmu.edu> References: <11C08BF5-0060-459C-99DC-EABEA88DF44B@sei.cmu.edu> <0FCF1038-D6C8-4C25-9B4C-E493EB817592@sei.cmu.edu> In-Reply-To: <0FCF1038-D6C8-4C25-9B4C-E493EB817592@sei.cmu.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.200.90] Content-Type: multipart/alternative; boundary="_000_7387610AD85749FE996477D54CDDA2F4seicmuedu_" MIME-Version: 1.0 Archived-At: Subject: Re: [Ace] ACE Implementation for Disadvantaged Environments X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2019 15:07:13 -0000 --_000_7387610AD85749FE996477D54CDDA2F4seicmuedu_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8sDQoNCkhlcmUgaXMgc29tZSBtb3JlIGluZm9ybWF0aW9uIGFib3V0IGl0Og0KDQoNCiAg KiAgIFdlIHVzZWQgQ29udGlraSBhcyB0aGUgYmFzZS9PUyBmb3IgdGhlIGNvZGUuIE1vcmUgc3Bl Y2lmaWNhbGx5LCB3ZSBmb3JrZWQgZnJvbSB0aGUgNmxiciBwcm9qZWN0IChodHRwczovL2dpdGh1 Yi5jb20vY2V0aWMvNmxiciksIGFzIHRoYXQgdmVyc2lvbiBhbHJlYWR5IGhhZCBzb21lIGNvZGUg Zm9yIGhhbmRsaW5nIERUTFMgY29ubmVjdGlvbnMgYW5kIEFFUyBlbmNyeXB0aW9uIGluIGl0Lg0K ICAqICAgV2UgYXJlIHVzaW5nIHRoZSBUSSBDQzI1MzhkayBib2FyZCBhcyBvdXIgY29uc3RyYWlu ZWQgdGFyZ2V0IHBsYXRmb3JtLg0KICAqICAgVGhlIGltcGxlbWVudGF0aW9uIGhhcyBzdXBwb3J0 IGZvciB0aGUgRFRMUyBwcm9maWxlLCB1c2luZyBwcmUtc2hhcmVkIGtleXMsIGFzIHRoaXMgd2Fz IGVub3VnaCBmb3Igb3VyIHVzZSBjYXNlLg0KICAqICAgVGhlIGltcGxlbWVudGF0aW9uIGhhbmRs ZXMgQ1dUIHRva2Vucy4NCiAgKiAgIFdlIG1vZGlmaWVkIHRoZSBFcmJpdW0gQ29BUCBzZXJ2ZXIg aW4gNmxiciB0byBiZSBhYmxlIHRvIHNpbXVsdGFuZW91c2x5IGxpc3RlbiBmb3IgQ29BUCBhbmQg Q29BUHMgY29ubmVjdGlvbnMgKHVzaW5nIFRpbnlEVExTIHVuZGVybmVhdGgpLg0KICAqICAgVGhl IGltcGxlbWVudGF0aW9uIHVzZXMgdGhlIGNuLWNib3IgbGlicmFyeSBmb3IgZGVjb2RpbmcgQ0JP UiBkYXRhLg0KICAqICAgVGhlIGltcGxlbWVudGF0aW9uIHN1cHBvcnRzIHJlY2VpdmluZyB0b2tl bnMgYXQgdGhlIGF1dGh6LWluZm8gZW5kcG9pbnQsIGFuZCB0aGVuIGdpdmluZyBhY2Nlc3MgdG8g YSBjb3VwbGUgb2Ygc2FtcGxlIHJlc291cmNlcyBiYXNlZCBvbiB0aGUgY2xhaW1zIGZyb20gdGhl IHJlY2VpdmVkIHRva2Vucy4NCiAgKiAgIFRoZSBpbXBsZW1lbnRhdGlvbiBoYXMgc29tZSBhZGRp dGlvbmFsIG9wdGlvbmFsIGZlYXR1cmVzIHJlbGF0ZWQgdG8gb3VyIGRpc2FkdmFudGFnZWQgbmV0 d29yayBlbnZpcm9ubWVudHMsIHN1Y2ggYXMgYm9vdHN0cmFwcGluZyBvZiB0aGUgUFNLIGNyZWRl bnRpYWxzLCBhbmQgZGV0ZWN0aW5nIHJldm9rZWQgdG9rZW5zIHRocm91Z2ggaW50cm9zcGVjdGlv bi4NCiAgKiAgIFRoZSBjdXJyZW50IGJpbmFyeSBpcyBhcm91bmQgMzAwIGtiLCB3aGljaCBpcyBn b29kIGVub3VnaCBmb3IgdGhlIDUxMiBrYiBmbGFzaCBvbiB0aGUgVEkgYm9hcmRzLCB0aG91Z2gg aXQgbWF5IGJlIGEgYml0IHRvbyBsYXJnZSBmb3IgYSBjbGFzcyBJSSBkZXZpY2UuIFdlIGNhbiBw cm9iYWJseSBtYWtlIGl0IGEgYml0IHNtYWxsZXIuIEluIHRlcm1zIG9mIFJBTSwgaXQgZml0cyBp biB0aGUgMzIgS0IgYXZhaWxhYmxlIG9uIHRoZSBUSSBib2FyZHMuDQoNCkJlc3QsDQoNCi0tLQ0K U2ViYXN0aWFuIEVjaGV2ZXJyaWENClRhY3RpY2FsIFRlY2hub2xvZ2llcyBHcm91cCAoVFRHKQ0K U29mdHdhcmUgRW5naW5lZXJpbmcgSW5zdGl0dXRlDQpDYXJuZWdpZSBNZWxsb24gVW5pdmVyc2l0 eQ0KDQoNCg0KRnJvbTogSGFubmVzIFRzY2hvZmVuaWcgPEhhbm5lcy5Uc2Nob2ZlbmlnQGFybS5j b20+DQpEYXRlOiBNb25kYXksIEphbnVhcnkgMjgsIDIwMTkgYXQgNTowNSBBTQ0KVG86IEdyYWNl IExld2lzIDxnbGV3aXNAc2VpLmNtdS5lZHU+LCAiYWNlQGlldGYub3JnIiA8YWNlQGlldGYub3Jn Pg0KU3ViamVjdDogUkU6IEFDRSBJbXBsZW1lbnRhdGlvbiBmb3IgRGlzYWR2YW50YWdlZCBFbnZp cm9ubWVudHMNCg0KQ29uZ3JhdHMgdG8gdGhlIHdvcmsuIENvdWxkIHlvdSBzYXkgYSBsaXR0bGUg Yml0IHRoZSAoY29uc3RyYWluZWQpIHJlc291cmNlIHNlcnZlciBpbXBsZW1lbnRhdGlvbj8NCg0K Q2lhbw0KSGFubmVzDQoNCkZyb206IEFjZSA8YWNlLWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJlaGFs ZiBPZiBHcmFjZSBBIExld2lzDQpTZW50OiBNaXR0d29jaCwgMjMuIEphbnVhciAyMDE5IDE5OjEy DQpUbzogYWNlQGlldGYub3JnDQpTdWJqZWN0OiBbQWNlXSBBQ0UgSW1wbGVtZW50YXRpb24gZm9y IERpc2FkdmFudGFnZWQgRW52aXJvbm1lbnRzDQoNCkhlbGxvLA0KDQpJIGp1c3Qgd2FudGVkIHRv IG1ha2UgdGhlIGdyb3VwIGF3YXJlIG9mIG91ciBBQ0UgaW1wbGVtZW50YXRpb24gKFNFSS1BQ0Up LCB3aGljaCBpbmNsdWRlcyBhbiBpbXBsZW1lbnRhdGlvbiBmb3IgYSByZXNvdXJjZS1jb25zdHJh aW5lZCBzZXJ2ZXIuDQoNCkRldGFpbHMgYXZhaWxhYmxlIGluIHRoaXMgbmV3cyBhcnRpY2xlOiBo dHRwczovL3d3dy5zZWkuY211LmVkdS9uZXdzLWV2ZW50cy9uZXdzL2FydGljbGUuY2ZtP2Fzc2V0 aWQ9NTM5MTg0DQoNCkFydGljbGUgaW5jbHVkZXMgdGhlIGxpbmsgdG8gb3VyIEdpdCByZXBvLg0K DQpFbmpveSENCg0KLSBHcmFjZSBMZXdpcw0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQpHcmFjZSBBLiBMZXdpcywgUGguRC4NClByaW5jaXBhbCBSZXNl YXJjaGVyIGFuZCBUVEcgSW5pdGlhdGl2ZSBMZWFkDQpDYXJuZWdpZSBNZWxsb24gU29mdHdhcmUg RW5naW5lZXJpbmcgSW5zdGl0dXRlDQpTb2Z0d2FyZSBTb2x1dGlvbnMgRGl2aXNpb24gKFNTRCkN ClRhY3RpY2FsIFRlY2hub2xvZ2llcyBHcm91cCAoVFRHKQ0KDQo0NTAwIEZpZnRoIEF2ZS4gIzU0 MTINClBpdHRzYnVyZ2gsIFBBIDE1MjEzDQpQaG9uZTogKDQxMikgMjY4LTU4NTENCmh0dHA6Ly93 d3cuc2VpLmNtdS5lZHUvc3RhZmYvZ2xld2lzDQoNCuKAnEEgY2hhbmdlIGluIHBlcnNwZWN0aXZl IGlzIHdvcnRoIDgwIElRIHBvaW50c+KAnSAtLS0gQWxhbiBLYXkNCklNUE9SVEFOVCBOT1RJQ0U6 IFRoZSBjb250ZW50cyBvZiB0aGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGNvbmZp ZGVudGlhbCBhbmQgbWF5IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYgeW91IGFyZSBub3QgdGhlIGlu dGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFu ZCBkbyBub3QgZGlzY2xvc2UgdGhlIGNvbnRlbnRzIHRvIGFueSBvdGhlciBwZXJzb24sIHVzZSBp dCBmb3IgYW55IHB1cnBvc2UsIG9yIHN0b3JlIG9yIGNvcHkgdGhlIGluZm9ybWF0aW9uIGluIGFu eSBtZWRpdW0uIFRoYW5rIHlvdS4NCg== --_000_7387610AD85749FE996477D54CDDA2F4seicmuedu_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6T3B0aW1hOw0KCXBhbm9zZS0xOjIgMCA1IDMgNiAwIDAgMiAwIDQ7fQ0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTotd2Via2l0LXN0YW5kYXJkOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIg MiAyIDIgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNv Tm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJY29sb3I6IzA1NjNDMTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRl ZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJ Y29sb3I6Izk1NEY3MjsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvTGlzdFBh cmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNv LXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDowaW47 DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fu cy1zZXJpZjt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJ e21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCglt YXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1s ZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJ e21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bh bi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hw RGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0 O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4w aW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0 aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDo0 OTgwMzg0NzM7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRz OjE1OTY3NTczMTIgMTQ2MzY5NzAzMiA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5 MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMDpsZXZlbDEN Cgl7bXNvLWxldmVsLXN0YXJ0LWF0OjA7DQoJbXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Oi07DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseToiVGlt ZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVs NA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3 Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0 IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVy IE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250 LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZl bDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C pzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpv bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48 L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9IiMwNTYzQzEiIHZsaW5r PSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5IZWxsbyw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGVyZSBpcyBzb21lIG1vcmUgaW5m b3JtYXRpb24gYWJvdXQgaXQ6IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8dWwgc3R5bGU9Im1hcmdpbi10b3A6MGluIiB0eXBlPSJk aXNjIj4NCjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBp bjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+V2UgdXNlZCBDb250aWtpIGFzIHRoZSBiYXNlL09T IGZvciB0aGUgY29kZS4gTW9yZSBzcGVjaWZpY2FsbHksIHdlIGZvcmtlZCBmcm9tIHRoZSA2bGJy IHByb2plY3QgKDxhIGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS9jZXRpYy82bGJyIj5odHRwczov L2dpdGh1Yi5jb20vY2V0aWMvNmxicjwvYT4pLCBhcyB0aGF0DQogdmVyc2lvbiBhbHJlYWR5IGhh ZCBzb21lIGNvZGUgZm9yIGhhbmRsaW5nIERUTFMgY29ubmVjdGlvbnMgYW5kIEFFUyBlbmNyeXB0 aW9uIGluIGl0LjxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0 eWxlPSJtYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPldlIGFyZSB1c2lu ZyB0aGUgVEkgQ0MyNTM4ZGsgYm9hcmQgYXMgb3VyIGNvbnN0cmFpbmVkIHRhcmdldCBwbGF0Zm9y bS48bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFy Z2luLWxlZnQ6MGluO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj5UaGUgaW1wbGVtZW50YXRpb24g aGFzIHN1cHBvcnQgZm9yIHRoZSBEVExTIHByb2ZpbGUsIHVzaW5nIHByZS1zaGFyZWQga2V5cywg YXMgdGhpcyB3YXMgZW5vdWdoIGZvciBvdXIgdXNlIGNhc2UuPG86cD48L286cD48L2xpPjxsaSBj bGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDps MCBsZXZlbDEgbGZvMSI+VGhlIGltcGxlbWVudGF0aW9uIGhhbmRsZXMgQ1dUIHRva2Vucy48bzpw PjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6MGluO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj5XZSBtb2RpZmllZCB0aGUgRXJiaXVtIENv QVAgc2VydmVyIGluIDZsYnIgdG8gYmUgYWJsZSB0byBzaW11bHRhbmVvdXNseSBsaXN0ZW4gZm9y IENvQVAgYW5kIENvQVBzIGNvbm5lY3Rpb25zICh1c2luZyBUaW55RFRMUyB1bmRlcm5lYXRoKS48 bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6MGluO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj5UaGUgaW1wbGVtZW50YXRpb24gdXNl cyB0aGUgY24tY2JvciBsaWJyYXJ5IGZvciBkZWNvZGluZyBDQk9SIGRhdGEuPG86cD48L286cD48 L2xpPjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjtt c28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+VGhlIGltcGxlbWVudGF0aW9uIHN1cHBvcnRzIHJlY2Vp dmluZyB0b2tlbnMgYXQgdGhlIGF1dGh6LWluZm8gZW5kcG9pbnQsIGFuZCB0aGVuIGdpdmluZyBh Y2Nlc3MgdG8gYSBjb3VwbGUgb2Ygc2FtcGxlIHJlc291cmNlcyBiYXNlZCBvbiB0aGUgY2xhaW1z IGZyb20gdGhlIHJlY2VpdmVkIHRva2Vucy48bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29M aXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwwIGxldmVsMSBs Zm8xIj5UaGUgaW1wbGVtZW50YXRpb24gaGFzIHNvbWUgYWRkaXRpb25hbCBvcHRpb25hbCBmZWF0 dXJlcyByZWxhdGVkIHRvIG91ciBkaXNhZHZhbnRhZ2VkIG5ldHdvcmsgZW52aXJvbm1lbnRzLCBz dWNoIGFzIGJvb3RzdHJhcHBpbmcgb2YgdGhlIFBTSyBjcmVkZW50aWFscywgYW5kIGRldGVjdGlu ZyByZXZva2VkIHRva2Vucw0KIHRocm91Z2ggaW50cm9zcGVjdGlvbi48bzpwPjwvbzpwPjwvbGk+ PGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21zby1s aXN0OmwwIGxldmVsMSBsZm8xIj5UaGUgY3VycmVudCBiaW5hcnkgaXMgYXJvdW5kIDMwMCBrYiwg d2hpY2ggaXMgZ29vZCBlbm91Z2ggZm9yIHRoZSA1MTIga2IgZmxhc2ggb24gdGhlIFRJIGJvYXJk cywgdGhvdWdoIGl0IG1heSBiZSBhIGJpdCB0b28gbGFyZ2UgZm9yIGEgY2xhc3MgSUkgZGV2aWNl LiBXZSBjYW4gcHJvYmFibHkgbWFrZSBpdCBhIGJpdA0KIHNtYWxsZXIuIEluIHRlcm1zIG9mIFJB TSwgaXQgZml0cyBpbiB0aGUgMzIgS0IgYXZhaWxhYmxlIG9uIHRoZSBUSSBib2FyZHMuPG86cD48 L286cD48L2xpPjwvdWw+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJlc3QsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Y29sb3I6YmxhY2siPi0tLTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOmJsYWNrIj5T ZWJhc3RpYW4gRWNoZXZlcnJpYTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2NvbG9yOmJsYWNrIj5UYWN0aWNh bCBUZWNobm9sb2dpZXMgR3JvdXAgKFRURyk8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2NvbG9yOmJsYWNrIj5Tb2Z0d2Fy ZSBFbmdpbmVlcmluZyBJbnN0aXR1dGU8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2NvbG9yOmJsYWNrIj5DYXJuZWdpZSBN ZWxsb24gVW5pdmVyc2l0eTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xv cjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1 QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+RnJvbTogPC9zcGFuPjwvYj48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPkhhbm5lcyBUc2Nob2ZlbmlnICZsdDtIYW5uZXMuVHNjaG9mZW5p Z0Bhcm0uY29tJmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5Nb25kYXksIEphbnVhcnkgMjgsIDIwMTkg YXQgNTowNSBBTTxicj4NCjxiPlRvOiA8L2I+R3JhY2UgTGV3aXMgJmx0O2dsZXdpc0BzZWkuY211 LmVkdSZndDssICZxdW90O2FjZUBpZXRmLm9yZyZxdW90OyAmbHQ7YWNlQGlldGYub3JnJmd0Ozxi cj4NCjxiPlN1YmplY3Q6IDwvYj5SRTogQUNFIEltcGxlbWVudGF0aW9uIGZvciBEaXNhZHZhbnRh Z2VkIEVudmlyb25tZW50czwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5Db25ncmF0cyB0byB0aGUgd29yay4gQ291bGQgeW91 IHNheSBhIGxpdHRsZSBiaXQgdGhlIChjb25zdHJhaW5lZCkgcmVzb3VyY2Ugc2VydmVyIGltcGxl bWVudGF0aW9uPw0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5D aWFvPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkhhbm5lczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkZyb206 PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+IEFjZSAmbHQ7YWNlLWJv dW5jZXNAaWV0Zi5vcmcmZ3Q7DQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkdyYWNlIEEgTGV3aXM8YnI+ DQo8Yj5TZW50OjwvYj4gTWl0dHdvY2gsIDIzLiBKYW51YXIgMjAxOSAxOToxMjxicj4NCjxiPlRv OjwvYj4gYWNlQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFtBY2VdIEFDRSBJbXBsZW1l bnRhdGlvbiBmb3IgRGlzYWR2YW50YWdlZCBFbnZpcm9ubWVudHM8L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dCI+SGVsbG8sPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5JIGp1 c3Qgd2FudGVkIHRvIG1ha2UgdGhlIGdyb3VwIGF3YXJlIG9mIG91ciBBQ0UgaW1wbGVtZW50YXRp b24gKFNFSS1BQ0UpLCB3aGljaCBpbmNsdWRlcyBhbiBpbXBsZW1lbnRhdGlvbiBmb3IgYSByZXNv dXJjZS1jb25zdHJhaW5lZCBzZXJ2ZXIuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0Ij5EZXRhaWxzIGF2YWlsYWJsZSBpbiB0aGlzIG5ld3MgYXJ0aWNsZToNCjxhIGhy ZWY9Imh0dHBzOi8vd3d3LnNlaS5jbXUuZWR1L25ld3MtZXZlbnRzL25ld3MvYXJ0aWNsZS5jZm0/ YXNzZXRpZD01MzkxODQiPmh0dHBzOi8vd3d3LnNlaS5jbXUuZWR1L25ld3MtZXZlbnRzL25ld3Mv YXJ0aWNsZS5jZm0/YXNzZXRpZD01MzkxODQ8L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0Ij5BcnRpY2xlIGluY2x1ZGVzIHRoZSBsaW5rIHRvIG91ciBHaXQgcmVw by48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkVuam95ITwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+LSBHcmFjZSBMZXdpczwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjojMDAwMDdGIj5fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTpPcHRpbWE7Y29sb3I6IzAwMDA3RiI+R3JhY2UgQS4gTGV3aXMsIFBoLkQuPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6T3B0aW1hO2NvbG9yOiMwMDAwN0Yi PlByaW5jaXBhbCBSZXNlYXJjaGVyIGFuZCBUVEcgSW5pdGlhdGl2ZSBMZWFkJm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6T3B0aW1hO2NvbG9yOiMwMDAwN0YiPkNhcm5lZ2llIE1lbGxvbiBTb2Z0d2FyZSBFbmdpbmVl cmluZyBJbnN0aXR1dGU8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTpPcHRpbWE7Y29sb3I6IzAwMDA3RiI+U29mdHdhcmUgU29sdXRpb25zIERpdmlzaW9uJm5ic3A7 KFNTRCkmbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTpP cHRpbWE7Y29sb3I6IzAwMDA3RiI+VGFjdGljYWwgVGVjaG5vbG9naWVzIEdyb3VwIChUVEcpPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6LXdlYmtpdC1zdGFuZGFy ZDtjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6T3B0aW1hO2NvbG9yOiMwMDAwN0YiPjQ1MDAgRmlmdGggQXZlLiZuYnNwOyM1NDEy PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6T3B0aW1hO2NvbG9y OiMwMDAwN0YiPlBpdHRzYnVyZ2gsIFBBIDE1MjEzICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6T3B0aW1hO2NvbG9yOiMwMDAwN0YiPlBob25lOiAoNDEyKSAyNjgtNTg1 MTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5Ok9wdGltYTtjb2xvcjojMDAwMDdGIj48YSBo cmVmPSJodHRwOi8vd3d3LnNlaS5jbXUuZWR1L3N0YWZmL2dsZXdpcyI+aHR0cDovL3d3dy5zZWku Y211LmVkdS9zdGFmZi9nbGV3aXM8L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6T3B0 aW1hO2NvbG9yOiMwMDAwN0YiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6T3B0aW1hO2NvbG9yOiMzODU3MjMiPuKAnEEgY2hhbmdlIGluIHBlcnNwZWN0aXZl IGlzIHdvcnRoIDgwIElRIHBvaW50c+KAnSAtLS0gQWxhbiBLYXk8L3NwYW4+PC9pPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQiPklNUE9SVEFOVCBOT1RJQ0U6IFRoZSBjb250ZW50cyBvZiB0aGlzIGVtYWlsIGFuZCBhbnkg YXR0YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbCBhbmQgbWF5IGFsc28gYmUgcHJpdmlsZWdlZC4g SWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIG5vdGlmeSB0aGUg c2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBkbyBub3QgZGlzY2xvc2UNCiB0aGUgY29udGVudHMgdG8g YW55IG90aGVyIHBlcnNvbiwgdXNlIGl0IGZvciBhbnkgcHVycG9zZSwgb3Igc3RvcmUgb3IgY29w eSB0aGUgaW5mb3JtYXRpb24gaW4gYW55IG1lZGl1bS4gVGhhbmsgeW91Lg0KPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_7387610AD85749FE996477D54CDDA2F4seicmuedu_-- From nobody Mon Jan 28 07:19:13 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6095C127598 for ; Mon, 28 Jan 2019 07:19:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.041 X-Spam-Level: X-Spam-Status: No, score=-2.041 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 AxWuiDX999Hs for ; Mon, 28 Jan 2019 07:19:04 -0800 (PST) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-he1eur04on0619.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe0d::619]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03F87129A87 for ; Mon, 28 Jan 2019 07:19:03 -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=WGt7TOVJ5bdpsofL4n0SRPjEbN3XJnX/dVUF1YoK60w=; b=V53ThfBoINMwPvh7SPZfn/mVyPsAwAb5w8dHC+57DSJPAQbeLNeqLVFEQitE2lSXdM8CQYs0ZpwNKgY9UaU4CB0NfzwlBvLe8cH8XdilLTZg+2fTDoei8tyQwrpXSLSbGMEwo+duWSmnso/4vyt/j/QmTTqgZuYbLHW8Y+gouaQ= Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB1854.eurprd08.prod.outlook.com (10.168.68.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1558.21; Mon, 28 Jan 2019 15:18:59 +0000 Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::3ce6:d8fa:3271:6019]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::3ce6:d8fa:3271:6019%7]) with mapi id 15.20.1558.023; Mon, 28 Jan 2019 15:18:59 +0000 From: Hannes Tschofenig To: Sebastian Echeverria CC: Grace A Lewis , "ace@ietf.org" , Dan Klinedinst Thread-Topic: ACE Implementation for Disadvantaged Environments Thread-Index: AQHUs0cwxz8vJeWIVUGFns83Bt0/66XEercQgAA76QCAABjZAIAAAtXQ Date: Mon, 28 Jan 2019 15:18:59 +0000 Message-ID: References: <11C08BF5-0060-459C-99DC-EABEA88DF44B@sei.cmu.edu> <0FCF1038-D6C8-4C25-9B4C-E493EB817592@sei.cmu.edu> <7387610A-D857-49FE-9964-77D54CDDA2F4@sei.cmu.edu> In-Reply-To: <7387610A-D857-49FE-9964-77D54CDDA2F4@sei.cmu.edu> 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.119.167] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0801MB1854; 6:OPkbquPStTmYpxCRrKGeHXdatytB8SlRW0H9EUXu1zDyiO5fJSq+G08uuDCoKjCpjfdbdl+dJc5W0abGS96MVSpVK+KVwv+iR0ljkIhc9z5uX3q+olxiVM1HA6ni4VrAAY3Kl+qc07gwOEbnhO3lQSZ7PDcKLeIsFPNtpHiNyRfFAjYZ1bkosTAscxAhJGUHzFWrxL2k+qQnxE+ET65F4EzbhSSXulKQMUK/aG4E+owOlFJWiNgXleJ4P99xfEzRzklJYREXFH65Q27r4mcRxwQvM6vWBigGqnpdPudN7GxBidQQjOnpq6yiUSVF1oBWPFITeStnZQf0vaExBGvlWuWutPE/iURDJuNKV89+IDmcYEHs21AGXqeU3pCd5K6AN8BDQOvZ9ZFqSwXnGotsG6zrk5WL/HlQOtOc5ye+8JOA6dPV62J2fsJ/wf9cgGJfFHNvOBCuow4iFHpybDeHHg==; 5:Gwsqr5Dq9345Hu54OOwpPLTJVQS5wCXNX13XqhpQvFyPJnP16mJ9UDdOKjeO+W1AGuOfnV+vQxGWPewzrMFf1SoGe1+MadVQ3oxInXv0ynifWzunLDT9gvevTuXeFazbYN72tcsCcYC/qqKPMIpTXMtODAr/SPImqdolsz3sB5kGp+hIqIkrBzoj16XcUSUXhoo6ZaEjfjCh1fQpUhRtHw==; 7:/0+d7UxyzmlD/9M5EdjNIUsUUVm/ZEQEbs5K9DSRN2Pgqn5oYkzLbGqfsl66QiGQVmEng9gpPuY4rwtOk7VNpKDzKmoatCSBdQr4GyUoWArLMqStjmGzPA/mOMYyx4uCg20f99N95KqwxufCTtoL4Q== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: f06062ea-4e42-4940-cc1f-08d68533edbc x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605077)(4618075)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB1854; x-ms-traffictypediagnostic: VI1PR0801MB1854: x-microsoft-antispam-prvs: x-forefront-prvs: 0931CB1479 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(376002)(346002)(39860400002)(136003)(396003)(51914003)(189003)(199004)(40434004)(6116002)(229853002)(66066001)(26005)(966005)(97736004)(3846002)(790700001)(6916009)(72206003)(53936002)(6506007)(53546011)(102836004)(2171002)(4326008)(14444005)(2906002)(5024004)(6246003)(6436002)(68736007)(606006)(25786009)(14454004)(55016002)(186003)(478600001)(256004)(9326002)(54896002)(6306002)(236005)(9686003)(8936002)(54906003)(106356001)(105586002)(74316002)(7736002)(86362001)(316002)(8676002)(93886005)(71200400001)(71190400001)(76176011)(7696005)(99286004)(11346002)(446003)(476003)(33656002)(81166006)(486006)(81156014); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB1854; 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-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: cNLe9+OuDrQKcn/PmQMTpFnzjKS5fYbjS99SXQlO/3P3xiA0la4TYCoyHWloV5f/yi6GssEA+3cXoy3V8DgNK+OAenAoeOi3BczvCXK7RiotzJLvqMzwRN/AlYkUI80itwXha2VtUJIpcKoRsa1p+S3ewfavT1Lffd3JI27ai5nQ2TfvMs2VrykSeBB0vbkM+2/gFPi2/HbLodNRms5u7U5aFeaJF0i9zJHXeipbjSBAVPw28HvLP8qkdx6aqV9mzLnVKLa5DmUX4tK5yobOR/yh2SuZ00IVEn6EhOTHk3ZF1Fr4VsysKgVMX8EjHMXNSCHScjj0gZsXJFoIOKtt+9x0G/v6P6eC3Y6TBkzsEu8lYfybTfKw2PPaXpC78h8zFWsdmDHHIpXhyzIVDVbLnrP9v2uIR2cv3PzgNUtGPbI= Content-Type: multipart/alternative; boundary="_000_VI1PR0801MB21120BD915B4E99352EC25F9FA960VI1PR0801MB2112_" MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: f06062ea-4e42-4940-cc1f-08d68533edbc X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Jan 2019 15:18:59.6653 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1854 Archived-At: Subject: Re: [Ace] ACE Implementation for Disadvantaged Environments X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2019 15:19:11 -0000 --_000_VI1PR0801MB21120BD915B4E99352EC25F9FA960VI1PR0801MB2112_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgU2ViYXN0aWFuLA0KDQpUaGFua3MgZm9yIHRoZSBkZXRhaWxzLiBIb3cgZWFzeSBkbyB5b3Ug dGhpbmsgd291bGQgaXQgYmUgdG8gcG9ydCB0aGUgY29kZSB0byBzb21lIG90aGVyIE9TPyAob3Ig aW4gb3RoZXIgd29yZHM6IGhvdyB0aWdodGx5IGhhdmUgeW91IGNvdXBsZWQgaXQgdG8gQ29udGlr aT8pDQoNCklzIHRoZSBDT1NFL0NXVCBwYXJzaW5nIGxpYnJhcnkgc2VwYXJhYmxlIGZyb20gdGhl IHJlc3Q/DQoNCkZvciB0aGUgMzAwIEtiIGZsYXNoOiBkb2VzIHRoaXMgY29udGFpbiB0aGUgZmly bXdhcmUgdXBkYXRlIG1lY2hhbmlzbT8NCg0KQ2lhbw0KSGFubmVzDQoNCkZyb206IFNlYmFzdGlh biBFY2hldmVycmlhIDxzZWNoZXZlcnJpYUBzZWkuY211LmVkdT4NClNlbnQ6IE1vbnRhZywgMjgu IEphbnVhciAyMDE5IDE2OjA2DQpUbzogSGFubmVzIFRzY2hvZmVuaWcgPEhhbm5lcy5Uc2Nob2Zl bmlnQGFybS5jb20+DQpDYzogR3JhY2UgQSBMZXdpcyA8Z2xld2lzQHNlaS5jbXUuZWR1PjsgYWNl QGlldGYub3JnOyBEYW4gS2xpbmVkaW5zdCA8ZGprbGluZWRpbnN0QGNlcnQub3JnPg0KU3ViamVj dDogUmU6IEFDRSBJbXBsZW1lbnRhdGlvbiBmb3IgRGlzYWR2YW50YWdlZCBFbnZpcm9ubWVudHMN Cg0KSGVsbG8sDQoNCkhlcmUgaXMgc29tZSBtb3JlIGluZm9ybWF0aW9uIGFib3V0IGl0Og0KDQoN CiAgKiAgIFdlIHVzZWQgQ29udGlraSBhcyB0aGUgYmFzZS9PUyBmb3IgdGhlIGNvZGUuIE1vcmUg c3BlY2lmaWNhbGx5LCB3ZSBmb3JrZWQgZnJvbSB0aGUgNmxiciBwcm9qZWN0IChodHRwczovL2dp dGh1Yi5jb20vY2V0aWMvNmxiciksIGFzIHRoYXQgdmVyc2lvbiBhbHJlYWR5IGhhZCBzb21lIGNv ZGUgZm9yIGhhbmRsaW5nIERUTFMgY29ubmVjdGlvbnMgYW5kIEFFUyBlbmNyeXB0aW9uIGluIGl0 Lg0KICAqICAgV2UgYXJlIHVzaW5nIHRoZSBUSSBDQzI1MzhkayBib2FyZCBhcyBvdXIgY29uc3Ry YWluZWQgdGFyZ2V0IHBsYXRmb3JtLg0KICAqICAgVGhlIGltcGxlbWVudGF0aW9uIGhhcyBzdXBw b3J0IGZvciB0aGUgRFRMUyBwcm9maWxlLCB1c2luZyBwcmUtc2hhcmVkIGtleXMsIGFzIHRoaXMg d2FzIGVub3VnaCBmb3Igb3VyIHVzZSBjYXNlLg0KICAqICAgVGhlIGltcGxlbWVudGF0aW9uIGhh bmRsZXMgQ1dUIHRva2Vucy4NCiAgKiAgIFdlIG1vZGlmaWVkIHRoZSBFcmJpdW0gQ29BUCBzZXJ2 ZXIgaW4gNmxiciB0byBiZSBhYmxlIHRvIHNpbXVsdGFuZW91c2x5IGxpc3RlbiBmb3IgQ29BUCBh bmQgQ29BUHMgY29ubmVjdGlvbnMgKHVzaW5nIFRpbnlEVExTIHVuZGVybmVhdGgpLg0KICAqICAg VGhlIGltcGxlbWVudGF0aW9uIHVzZXMgdGhlIGNuLWNib3IgbGlicmFyeSBmb3IgZGVjb2Rpbmcg Q0JPUiBkYXRhLg0KICAqICAgVGhlIGltcGxlbWVudGF0aW9uIHN1cHBvcnRzIHJlY2VpdmluZyB0 b2tlbnMgYXQgdGhlIGF1dGh6LWluZm8gZW5kcG9pbnQsIGFuZCB0aGVuIGdpdmluZyBhY2Nlc3Mg dG8gYSBjb3VwbGUgb2Ygc2FtcGxlIHJlc291cmNlcyBiYXNlZCBvbiB0aGUgY2xhaW1zIGZyb20g dGhlIHJlY2VpdmVkIHRva2Vucy4NCiAgKiAgIFRoZSBpbXBsZW1lbnRhdGlvbiBoYXMgc29tZSBh ZGRpdGlvbmFsIG9wdGlvbmFsIGZlYXR1cmVzIHJlbGF0ZWQgdG8gb3VyIGRpc2FkdmFudGFnZWQg bmV0d29yayBlbnZpcm9ubWVudHMsIHN1Y2ggYXMgYm9vdHN0cmFwcGluZyBvZiB0aGUgUFNLIGNy ZWRlbnRpYWxzLCBhbmQgZGV0ZWN0aW5nIHJldm9rZWQgdG9rZW5zIHRocm91Z2ggaW50cm9zcGVj dGlvbi4NCiAgKiAgIFRoZSBjdXJyZW50IGJpbmFyeSBpcyBhcm91bmQgMzAwIGtiLCB3aGljaCBp cyBnb29kIGVub3VnaCBmb3IgdGhlIDUxMiBrYiBmbGFzaCBvbiB0aGUgVEkgYm9hcmRzLCB0aG91 Z2ggaXQgbWF5IGJlIGEgYml0IHRvbyBsYXJnZSBmb3IgYSBjbGFzcyBJSSBkZXZpY2UuIFdlIGNh biBwcm9iYWJseSBtYWtlIGl0IGEgYml0IHNtYWxsZXIuIEluIHRlcm1zIG9mIFJBTSwgaXQgZml0 cyBpbiB0aGUgMzIgS0IgYXZhaWxhYmxlIG9uIHRoZSBUSSBib2FyZHMuDQoNCkJlc3QsDQoNCi0t LQ0KU2ViYXN0aWFuIEVjaGV2ZXJyaWENClRhY3RpY2FsIFRlY2hub2xvZ2llcyBHcm91cCAoVFRH KQ0KU29mdHdhcmUgRW5naW5lZXJpbmcgSW5zdGl0dXRlDQpDYXJuZWdpZSBNZWxsb24gVW5pdmVy c2l0eQ0KDQoNCg0KRnJvbTogSGFubmVzIFRzY2hvZmVuaWcgPEhhbm5lcy5Uc2Nob2ZlbmlnQGFy bS5jb208bWFpbHRvOkhhbm5lcy5Uc2Nob2ZlbmlnQGFybS5jb20+Pg0KRGF0ZTogTW9uZGF5LCBK YW51YXJ5IDI4LCAyMDE5IGF0IDU6MDUgQU0NClRvOiBHcmFjZSBMZXdpcyA8Z2xld2lzQHNlaS5j bXUuZWR1PG1haWx0bzpnbGV3aXNAc2VpLmNtdS5lZHU+PiwgImFjZUBpZXRmLm9yZzxtYWlsdG86 YWNlQGlldGYub3JnPiIgPGFjZUBpZXRmLm9yZzxtYWlsdG86YWNlQGlldGYub3JnPj4NClN1Ympl Y3Q6IFJFOiBBQ0UgSW1wbGVtZW50YXRpb24gZm9yIERpc2FkdmFudGFnZWQgRW52aXJvbm1lbnRz DQoNCkNvbmdyYXRzIHRvIHRoZSB3b3JrLiBDb3VsZCB5b3Ugc2F5IGEgbGl0dGxlIGJpdCB0aGUg KGNvbnN0cmFpbmVkKSByZXNvdXJjZSBzZXJ2ZXIgaW1wbGVtZW50YXRpb24/DQoNCkNpYW8NCkhh bm5lcw0KDQpGcm9tOiBBY2UgPGFjZS1ib3VuY2VzQGlldGYub3JnPG1haWx0bzphY2UtYm91bmNl c0BpZXRmLm9yZz4+IE9uIEJlaGFsZiBPZiBHcmFjZSBBIExld2lzDQpTZW50OiBNaXR0d29jaCwg MjMuIEphbnVhciAyMDE5IDE5OjEyDQpUbzogYWNlQGlldGYub3JnPG1haWx0bzphY2VAaWV0Zi5v cmc+DQpTdWJqZWN0OiBbQWNlXSBBQ0UgSW1wbGVtZW50YXRpb24gZm9yIERpc2FkdmFudGFnZWQg RW52aXJvbm1lbnRzDQoNCkhlbGxvLA0KDQpJIGp1c3Qgd2FudGVkIHRvIG1ha2UgdGhlIGdyb3Vw IGF3YXJlIG9mIG91ciBBQ0UgaW1wbGVtZW50YXRpb24gKFNFSS1BQ0UpLCB3aGljaCBpbmNsdWRl cyBhbiBpbXBsZW1lbnRhdGlvbiBmb3IgYSByZXNvdXJjZS1jb25zdHJhaW5lZCBzZXJ2ZXIuDQoN CkRldGFpbHMgYXZhaWxhYmxlIGluIHRoaXMgbmV3cyBhcnRpY2xlOiBodHRwczovL3d3dy5zZWku Y211LmVkdS9uZXdzLWV2ZW50cy9uZXdzL2FydGljbGUuY2ZtP2Fzc2V0aWQ9NTM5MTg0DQoNCkFy dGljbGUgaW5jbHVkZXMgdGhlIGxpbmsgdG8gb3VyIEdpdCByZXBvLg0KDQpFbmpveSENCg0KLSBH cmFjZSBMZXdpcw0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQpHcmFjZSBBLiBMZXdpcywgUGguRC4NClByaW5jaXBhbCBSZXNlYXJjaGVyIGFuZCBUVEcg SW5pdGlhdGl2ZSBMZWFkDQpDYXJuZWdpZSBNZWxsb24gU29mdHdhcmUgRW5naW5lZXJpbmcgSW5z dGl0dXRlDQpTb2Z0d2FyZSBTb2x1dGlvbnMgRGl2aXNpb24gKFNTRCkNClRhY3RpY2FsIFRlY2hu b2xvZ2llcyBHcm91cCAoVFRHKQ0KDQo0NTAwIEZpZnRoIEF2ZS4gIzU0MTINClBpdHRzYnVyZ2gs IFBBIDE1MjEzDQpQaG9uZTogKDQxMikgMjY4LTU4NTENCmh0dHA6Ly93d3cuc2VpLmNtdS5lZHUv c3RhZmYvZ2xld2lzDQoNCuKAnEEgY2hhbmdlIGluIHBlcnNwZWN0aXZlIGlzIHdvcnRoIDgwIElR IHBvaW50c+KAnSAtLS0gQWxhbiBLYXkNCklNUE9SVEFOVCBOT1RJQ0U6IFRoZSBjb250ZW50cyBv ZiB0aGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbCBhbmQgbWF5 IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVu dCwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBkbyBub3QgZGlzY2xv c2UgdGhlIGNvbnRlbnRzIHRvIGFueSBvdGhlciBwZXJzb24sIHVzZSBpdCBmb3IgYW55IHB1cnBv c2UsIG9yIHN0b3JlIG9yIGNvcHkgdGhlIGluZm9ybWF0aW9uIGluIGFueSBtZWRpdW0uIFRoYW5r IHlvdS4NCklNUE9SVEFOVCBOT1RJQ0U6IFRoZSBjb250ZW50cyBvZiB0aGlzIGVtYWlsIGFuZCBh bnkgYXR0YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbCBhbmQgbWF5IGFsc28gYmUgcHJpdmlsZWdl ZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIG5vdGlmeSB0 aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBkbyBub3QgZGlzY2xvc2UgdGhlIGNvbnRlbnRzIHRv IGFueSBvdGhlciBwZXJzb24sIHVzZSBpdCBmb3IgYW55IHB1cnBvc2UsIG9yIHN0b3JlIG9yIGNv cHkgdGhlIGluZm9ybWF0aW9uIGluIGFueSBtZWRpdW0uIFRoYW5rIHlvdS4NCg== --_000_VI1PR0801MB21120BD915B4E99352EC25F9FA960VI1PR0801MB2112_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6RGVuZ1hpYW47DQoJcGFub3NlLTE6MiAx IDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiXEBEZW5nWGlhbiI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5Oi13ZWJraXQtc3RhbmRhcmQ7DQoJcGFub3NlLTE6MCAwIDAgMCAw IDAgMCAwIDAgMDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5Ok9wdGltYTt9DQovKiBTdHls ZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1h bA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIu MHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5N c29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJ dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5r Rm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4 dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQ YXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsN CgltYXJnaW4tdG9wOjBjbTsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1hcmdpbi1ib3R0b206MGNt Ow0KCW1hcmdpbi1sZWZ0OjM2LjBwdDsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1z aXplOjEyLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpwLm1zb25v cm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1z b25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0K CW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNp emU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1h aWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBl cnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxT dHlsZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTIyDQoJe21zby1zdHlsZS10eXBlOnBlcnNv bmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHls ZTI0DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIixzYW5zLXNlcmlmO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9y dC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6 NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0K ZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRp b25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDo0OTgwMzg0NzM7DQoJbXNvLWxpc3QtdHlw ZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjE1OTY3NTczMTIgMTQ2MzY5NzAzMiA2 NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5 ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLXN0YXJ0LWF0OjA7 DQoJbXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Oi07DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3Qg bDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVy IE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9u dC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot MTguMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDps ZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7 fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1p bHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglm b250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMQ0KCXttc28t bGlzdC1pZDo1NzQwNDU4NjM7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xMjk0NTc2NDIwO30N CkBsaXN0IGwxOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozNi4wcHQ7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2kt Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWwy DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOjcyLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0 Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDMNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6MTA4LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5 OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MTQ0LjBwdDsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsN Cgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlz dCBsMTpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MTgwLjBwdDsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250 LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDYNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6MjE2LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0K CWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6MjUyLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5 bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mjg4LjBwdDsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglt c28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBs MTpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MzI0LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNp emU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBj bTt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBjbTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIg Lz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVs YXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8 L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJF Ti1HQiIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNl Y3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0Ij5IaSBTZWJhc3RpYW4sIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdCI+VGhhbmtzIGZvciB0aGUgZGV0YWlscy4gSG93IGVhc3kgZG8geW91IHRoaW5rIHdvdWxk IGl0IGJlIHRvIHBvcnQgdGhlIGNvZGUgdG8gc29tZSBvdGhlciBPUz8gKG9yIGluIG90aGVyIHdv cmRzOiBob3cgdGlnaHRseSBoYXZlIHlvdSBjb3VwbGVkIGl0IHRvIENvbnRpa2k/KTxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+SXMgdGhlIENPU0UvQ1dUIHBhcnNp bmcgbGlicmFyeSBzZXBhcmFibGUgZnJvbSB0aGUgcmVzdD8NCjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdCI+Rm9yIHRoZSAzMDAgS2IgZmxhc2g6IGRvZXMgdGhpcyBj b250YWluIHRoZSBmaXJtd2FyZSB1cGRhdGUgbWVjaGFuaXNtPzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdCI+Q2lhbzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5IYW5uZXM8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5n OjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+IFNlYmFzdGlhbiBFY2hldmVycmlh ICZsdDtzZWNoZXZlcnJpYUBzZWkuY211LmVkdSZndDsNCjxicj4NCjxiPlNlbnQ6PC9iPiBNb250 YWcsIDI4LiBKYW51YXIgMjAxOSAxNjowNjxicj4NCjxiPlRvOjwvYj4gSGFubmVzIFRzY2hvZmVu aWcgJmx0O0hhbm5lcy5Uc2Nob2ZlbmlnQGFybS5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBHcmFj ZSBBIExld2lzICZsdDtnbGV3aXNAc2VpLmNtdS5lZHUmZ3Q7OyBhY2VAaWV0Zi5vcmc7IERhbiBL bGluZWRpbnN0ICZsdDtkamtsaW5lZGluc3RAY2VydC5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8 L2I+IFJlOiBBQ0UgSW1wbGVtZW50YXRpb24gZm9yIERpc2FkdmFudGFnZWQgRW52aXJvbm1lbnRz PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiPkhlbGxvLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+SGVyZSBpcyBzb21lIG1vcmUgaW5m b3JtYXRpb24gYWJvdXQgaXQ6IDxvOnA+DQo8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N Cjx1bCBzdHlsZT0ibWFyZ2luLXRvcDowY20iIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29M aXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGNtO21zby1saXN0OmwwIGxldmVsMSBs Zm8zIj48c3BhbiBsYW5nPSJFTi1VUyI+V2UgdXNlZCBDb250aWtpIGFzIHRoZSBiYXNlL09TIGZv ciB0aGUgY29kZS4gTW9yZSBzcGVjaWZpY2FsbHksIHdlIGZvcmtlZCBmcm9tIHRoZSA2bGJyIHBy b2plY3QgKDxhIGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS9jZXRpYy82bGJyIj5odHRwczovL2dp dGh1Yi5jb20vY2V0aWMvNmxicjwvYT4pLA0KIGFzIHRoYXQgdmVyc2lvbiBhbHJlYWR5IGhhZCBz b21lIGNvZGUgZm9yIGhhbmRsaW5nIERUTFMgY29ubmVjdGlvbnMgYW5kIEFFUyBlbmNyeXB0aW9u IGluIGl0LjxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBo IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGNtO21zby1saXN0OmwwIGxldmVsMSBsZm8zIj48c3BhbiBs YW5nPSJFTi1VUyI+V2UgYXJlIHVzaW5nIHRoZSBUSSBDQzI1MzhkayBib2FyZCBhcyBvdXIgY29u c3RyYWluZWQgdGFyZ2V0IHBsYXRmb3JtLjxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PGxpIGNsYXNz PSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGNtO21zby1saXN0OmwwIGxl dmVsMSBsZm8zIj48c3BhbiBsYW5nPSJFTi1VUyI+VGhlIGltcGxlbWVudGF0aW9uIGhhcyBzdXBw b3J0IGZvciB0aGUgRFRMUyBwcm9maWxlLCB1c2luZyBwcmUtc2hhcmVkIGtleXMsIGFzIHRoaXMg d2FzIGVub3VnaCBmb3Igb3VyIHVzZSBjYXNlLjxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PGxpIGNs YXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGNtO21zby1saXN0Omww IGxldmVsMSBsZm8zIj48c3BhbiBsYW5nPSJFTi1VUyI+VGhlIGltcGxlbWVudGF0aW9uIGhhbmRs ZXMgQ1dUIHRva2Vucy48bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjxsaSBjbGFzcz0iTXNvTGlzdFBh cmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBjbTttc28tbGlzdDpsMCBsZXZlbDEgbGZvMyI+ PHNwYW4gbGFuZz0iRU4tVVMiPldlIG1vZGlmaWVkIHRoZSBFcmJpdW0gQ29BUCBzZXJ2ZXIgaW4g NmxiciB0byBiZSBhYmxlIHRvIHNpbXVsdGFuZW91c2x5IGxpc3RlbiBmb3IgQ29BUCBhbmQgQ29B UHMgY29ubmVjdGlvbnMgKHVzaW5nIFRpbnlEVExTIHVuZGVybmVhdGgpLjxvOnA+PC9vOnA+PC9z cGFuPjwvbGk+PGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 MGNtO21zby1saXN0OmwwIGxldmVsMSBsZm8zIj48c3BhbiBsYW5nPSJFTi1VUyI+VGhlIGltcGxl bWVudGF0aW9uIHVzZXMgdGhlIGNuLWNib3IgbGlicmFyeSBmb3IgZGVjb2RpbmcgQ0JPUiBkYXRh LjxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHls ZT0ibWFyZ2luLWxlZnQ6MGNtO21zby1saXN0OmwwIGxldmVsMSBsZm8zIj48c3BhbiBsYW5nPSJF Ti1VUyI+VGhlIGltcGxlbWVudGF0aW9uIHN1cHBvcnRzIHJlY2VpdmluZyB0b2tlbnMgYXQgdGhl IGF1dGh6LWluZm8gZW5kcG9pbnQsIGFuZCB0aGVuIGdpdmluZyBhY2Nlc3MgdG8gYSBjb3VwbGUg b2Ygc2FtcGxlIHJlc291cmNlcyBiYXNlZCBvbiB0aGUgY2xhaW1zIGZyb20gdGhlIHJlY2VpdmVk DQogdG9rZW5zLjxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PGxpIGNsYXNzPSJNc29MaXN0UGFyYWdy YXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGNtO21zby1saXN0OmwwIGxldmVsMSBsZm8zIj48c3Bh biBsYW5nPSJFTi1VUyI+VGhlIGltcGxlbWVudGF0aW9uIGhhcyBzb21lIGFkZGl0aW9uYWwgb3B0 aW9uYWwgZmVhdHVyZXMgcmVsYXRlZCB0byBvdXIgZGlzYWR2YW50YWdlZCBuZXR3b3JrIGVudmly b25tZW50cywgc3VjaCBhcyBib290c3RyYXBwaW5nIG9mIHRoZSBQU0sgY3JlZGVudGlhbHMsIGFu ZCBkZXRlY3RpbmcNCiByZXZva2VkIHRva2VucyB0aHJvdWdoIGludHJvc3BlY3Rpb24uPG86cD48 L286cD48L3NwYW4+PC9saT48bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJn aW4tbGVmdDowY207bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzMiPjxzcGFuIGxhbmc9IkVOLVVTIj5U aGUgY3VycmVudCBiaW5hcnkgaXMgYXJvdW5kIDMwMCBrYiwgd2hpY2ggaXMgZ29vZCBlbm91Z2gg Zm9yIHRoZSA1MTIga2IgZmxhc2ggb24gdGhlIFRJIGJvYXJkcywgdGhvdWdoIGl0IG1heSBiZSBh IGJpdCB0b28gbGFyZ2UgZm9yIGEgY2xhc3MgSUkgZGV2aWNlLiBXZSBjYW4gcHJvYmFibHkNCiBt YWtlIGl0IGEgYml0IHNtYWxsZXIuIEluIHRlcm1zIG9mIFJBTSwgaXQgZml0cyBpbiB0aGUgMzIg S0IgYXZhaWxhYmxlIG9uIHRoZSBUSSBib2FyZHMuPG86cD48L286cD48L3NwYW4+PC9saT48L3Vs Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5C ZXN0LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2NvbG9yOmJsYWNrIj4tLS08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Y29sb3I6YmxhY2siPlNlYmFzdGlhbiBFY2hldmVycmlhPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2NvbG9yOmJsYWNrIj5UYWN0aWNhbCBUZWNobm9sb2dpZXMgR3JvdXAgKFRU Ryk8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9y OmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6YmxhY2siPlNvZnR3 YXJlIEVuZ2luZWVyaW5nIEluc3RpdHV0ZTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtjb2xvcjpibGFjayI+Q2FybmVnaWUgTWVsbG9uIFVuaXZlcnNpdHk8L3NwYW4+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOmJsYWNrIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xp ZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+RnJvbTog PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj5IYW5uZXMg VHNjaG9mZW5pZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOkhhbm5lcy5Uc2Nob2ZlbmlnQGFybS5jb20i Pkhhbm5lcy5Uc2Nob2ZlbmlnQGFybS5jb208L2E+Jmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5Nb25k YXksIEphbnVhcnkgMjgsIDIwMTkgYXQgNTowNSBBTTxicj4NCjxiPlRvOiA8L2I+R3JhY2UgTGV3 aXMgJmx0OzxhIGhyZWY9Im1haWx0bzpnbGV3aXNAc2VpLmNtdS5lZHUiPmdsZXdpc0BzZWkuY211 LmVkdTwvYT4mZ3Q7LCAmcXVvdDs8YSBocmVmPSJtYWlsdG86YWNlQGlldGYub3JnIj5hY2VAaWV0 Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86YWNlQGlldGYub3JnIj5hY2VAaWV0 Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5SRTogQUNFIEltcGxlbWVudGF0aW9u IGZvciBEaXNhZHZhbnRhZ2VkIEVudmlyb25tZW50czwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDs8L3Nw YW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0Ij5Db25ncmF0cyB0byB0aGUgd29yay4gQ291bGQgeW91IHNheSBhIGxpdHRsZSBiaXQgdGhl IChjb25zdHJhaW5lZCkgcmVzb3VyY2Ugc2VydmVyIGltcGxlbWVudGF0aW9uPw0KPC9zcGFuPjxz cGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOzwv c3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5D aWFvPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQiPkhhbm5lczwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0Ij4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlk ICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkZy b206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQi PiBBY2UgJmx0OzxhIGhyZWY9Im1haWx0bzphY2UtYm91bmNlc0BpZXRmLm9yZyI+YWNlLWJvdW5j ZXNAaWV0Zi5vcmc8L2E+Jmd0Ow0KPGI+T24gQmVoYWxmIE9mIDwvYj5HcmFjZSBBIExld2lzPGJy Pg0KPGI+U2VudDo8L2I+IE1pdHR3b2NoLCAyMy4gSmFudWFyIDIwMTkgMTk6MTI8YnI+DQo8Yj5U bzo8L2I+IDxhIGhyZWY9Im1haWx0bzphY2VAaWV0Zi5vcmciPmFjZUBpZXRmLm9yZzwvYT48YnI+ DQo8Yj5TdWJqZWN0OjwvYj4gW0FjZV0gQUNFIEltcGxlbWVudGF0aW9uIGZvciBEaXNhZHZhbnRh Z2VkIEVudmlyb25tZW50czwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkhlbGxvLDwvc3Bh bj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJz cDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dCI+SSBqdXN0IHdhbnRlZCB0byBtYWtlIHRoZSBncm91cCBhd2FyZSBvZiBvdXIgQUNFIGltcGxl bWVudGF0aW9uIChTRUktQUNFKSwgd2hpY2ggaW5jbHVkZXMgYW4gaW1wbGVtZW50YXRpb24gZm9y IGEgcmVzb3VyY2UtY29uc3RyYWluZWQgc2VydmVyLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0i RU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+RGV0YWlscyBhdmFpbGFibGUg aW4gdGhpcyBuZXdzIGFydGljbGU6DQo8YSBocmVmPSJodHRwczovL3d3dy5zZWkuY211LmVkdS9u ZXdzLWV2ZW50cy9uZXdzL2FydGljbGUuY2ZtP2Fzc2V0aWQ9NTM5MTg0Ij5odHRwczovL3d3dy5z ZWkuY211LmVkdS9uZXdzLWV2ZW50cy9uZXdzL2FydGljbGUuY2ZtP2Fzc2V0aWQ9NTM5MTg0PC9h Pjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 Ij4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdCI+QXJ0aWNsZSBpbmNsdWRlcyB0aGUgbGluayB0byBvdXIgR2l0IHJlcG8uPC9zcGFu PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNw Ozwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 Ij5FbmpveSE8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQiPi0gR3JhY2UgTGV3aXM8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVO LVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6IzAwMDA3RiI+X19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzwvc3Bhbj48c3BhbiBsYW5n PSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6T3B0aW1hO2NvbG9yOiMw MDAwN0YiPkdyYWNlIEEuIExld2lzLCBQaC5ELjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5Ok9w dGltYTtjb2xvcjojMDAwMDdGIj5QcmluY2lwYWwgUmVzZWFyY2hlciBhbmQgVFRHIEluaXRpYXRp dmUgTGVhZCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1V UyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5Ok9wdGltYTtjb2xvcjojMDAwMDdGIj5DYXJuZWdpZSBNZWxsb24gU29mdHdhcmUgRW5naW5l ZXJpbmcgSW5zdGl0dXRlPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6T3B0aW1hO2NvbG9yOiMw MDAwN0YiPlNvZnR3YXJlIFNvbHV0aW9ucyBEaXZpc2lvbiZuYnNwOyhTU0QpJm5ic3A7PC9zcGFu PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6T3B0aW1hO2NvbG9yOiMwMDAwN0YiPlRhY3RpY2FsIFRlY2hu b2xvZ2llcyBHcm91cCAoVFRHKTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90Oy13ZWJr aXQtc3RhbmRhcmQmcXVvdDssc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48c3BhbiBs YW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5Ok9wdGltYTtjb2xvcjojMDAwMDdGIj40NTAwIEZpZnRoIEF2ZS4mbmJzcDsj NTQxMjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5Ok9wdGltYTtjb2xvcjojMDAwMDdGIj5QaXR0 c2J1cmdoLCBQQSAxNTIxMyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5Ok9wdGltYTtjb2xvcjojMDAw MDdGIj5QaG9uZTogKDQxMikgMjY4LTU4NTE8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTpPcHRpbWE7Y29sb3I6IzAwMDA3 RiI+PGEgaHJlZj0iaHR0cDovL3d3dy5zZWkuY211LmVkdS9zdGFmZi9nbGV3aXMiPmh0dHA6Ly93 d3cuc2VpLmNtdS5lZHUvc3RhZmYvZ2xld2lzPC9hPjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5Ok9wdGltYTtjb2xvcjoj MDAwMDdGIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGk+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5Ok9wdGltYTtjb2xvcjojMzg1NzIz Ij7igJxBIGNoYW5nZSBpbiBwZXJzcGVjdGl2ZSBpcyB3b3J0aCA4MCBJUSBwb2ludHPigJ0gLS0t IEFsYW4gS2F5PC9zcGFuPjwvaT48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0Ij5JTVBPUlRBTlQgTk9USUNFOiBUaGUgY29udGVudHMgb2YgdGhpcyBlbWFp bCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBjb25maWRlbnRpYWwgYW5kIG1heSBhbHNvIGJlIHBy aXZpbGVnZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBu b3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBhbmQgZG8NCiBub3QgZGlzY2xvc2UgdGhlIGNv bnRlbnRzIHRvIGFueSBvdGhlciBwZXJzb24sIHVzZSBpdCBmb3IgYW55IHB1cnBvc2UsIG9yIHN0 b3JlIG9yIGNvcHkgdGhlIGluZm9ybWF0aW9uIGluIGFueSBtZWRpdW0uIFRoYW5rIHlvdS4NCjwv c3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQpJ TVBPUlRBTlQgTk9USUNFOiBUaGUgY29udGVudHMgb2YgdGhpcyBlbWFpbCBhbmQgYW55IGF0dGFj aG1lbnRzIGFyZSBjb25maWRlbnRpYWwgYW5kIG1heSBhbHNvIGJlIHByaXZpbGVnZWQuIElmIHlv dSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRl ciBpbW1lZGlhdGVseSBhbmQgZG8gbm90IGRpc2Nsb3NlIHRoZSBjb250ZW50cyB0byBhbnkgb3Ro ZXIgcGVyc29uLCB1c2UgaXQgZm9yIGFueSBwdXJwb3NlLA0KIG9yIHN0b3JlIG9yIGNvcHkgdGhl IGluZm9ybWF0aW9uIGluIGFueSBtZWRpdW0uIFRoYW5rIHlvdS4NCjwvYm9keT4NCjwvaHRtbD4N Cg== --_000_VI1PR0801MB21120BD915B4E99352EC25F9FA960VI1PR0801MB2112_-- From nobody Mon Jan 28 09:39:11 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F55A1310C2 for ; Mon, 28 Jan 2019 09:39:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.041 X-Spam-Level: X-Spam-Status: No, score=-2.041 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 QijC39p4f6oL for ; Mon, 28 Jan 2019 09:39:07 -0800 (PST) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-he1eur02on0613.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe05::613]) (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 F20471310BF for ; Mon, 28 Jan 2019 09:39:06 -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=16OGOJEbFkZaaHjeGwGZmhZF1nFGpaQL2ZS9AO1umkE=; b=m2sTg8jeLqhc2NGclstb4EQP0IovhROUwpIWRO+G4f7Y+NzpQjcwpiARempWol9Lrt8+UWLSElzUb4sa3rlk2urFCJE0tiN/EoKs4HbsuYs0HJo9pTk/hMbTUWbFn+sY+3rIoPMjk/uMXNyngkDeFkTNuPASAOBz3WqGbHaLC+E= Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB1935.eurprd08.prod.outlook.com (10.173.73.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1558.21; Mon, 28 Jan 2019 17:39:03 +0000 Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::3ce6:d8fa:3271:6019]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::3ce6:d8fa:3271:6019%7]) with mapi id 15.20.1558.023; Mon, 28 Jan 2019 17:39:03 +0000 From: Hannes Tschofenig To: "ace@ietf.org" Thread-Topic: FW: [OAUTH-WG] OAuth Security Workshop Call for Proposals Thread-Index: AdS3L6s4fN4yhjuARguDx5pcJ/wWCA== Date: Mon, 28 Jan 2019 17:39:03 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [80.92.119.167] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0801MB1935; 6:7IJrLDdunMa/4GPpYIE+DU/vJ/iVpNza4rUwYvTUtD2mBBdWl0NHVkJkr7PwzzVIzLf9C3z0uBLdsW+lqQeUoJuRda3qM+UvfOzMyPHEnxayUD+rz7fFnwRb0z49lim6///fLstakQcfcEhrOiJWwj3I7Rqc0hpgs5lTreextoDlrsWsiZoYEjNGPZc5iXcI9FZLO4aSLg4eKxJ9DpQVF7Sv7bwRsHuGqcRyBxeXNpyoKryKMO6Po+p13o0SabPIzI1EDqAWFZcCkL1ER0yTl9Verx0VJcNfITRB5hKdGAJYrLedOrj29DQEOIqCFayD9rSMN5O32+kpX8AyRJnIRQLtRSid4dENZcnGjFKPbsPDAa5GOeZ0EE0zo4qHUNhmaI3+fRNYbY1s6O5/LzJyidMSCbMMaYye6+zZa/3+P8UUwVsYUQAykWvHIxWuLVvfheVpt1JS5S+LBuP+zczppA==; 5:olpNm6jn1TLZQJy37z9o1+ZNzTayfCgAhvE0Xe/4qhBTyp8fDJTeNbUxI3XISy08HwV3UNf5P0jqW7qRECsa5xI0+ov9vLypqQSB3kcw2KBE4j+2Vcv5IWKHBshiDZ/jI2FlJsDpUE3j4JnWStvnmLXj1U1GKD7NWu3dnR8d3Fq6JErrT0595MgUMYGKb2m3izjAhMBHj8o9l2NAIvn3WQ==; 7:Mgk7ZCfVjr5pih+UpFfcomDT1qWekjLwZxBg13qd5OdKNrM0QZntBTDYsbrc/CzoWxqXbTq+yzmx3K33LD7qcu9BfsUkNh0CcC0f3jZoh98EQ9/NQRsu/rdG6+clBT9vtYfIktHwnX0idLGRCNAbKA== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 7f4ef01c-1615-420c-5d84-08d685477ea8 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605077)(4618075)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB1935; x-ms-traffictypediagnostic: VI1PR0801MB1935: x-microsoft-antispam-prvs: x-forefront-prvs: 0931CB1479 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(376002)(136003)(366004)(39860400002)(396003)(189003)(199004)(53754006)(40434004)(74316002)(229853002)(486006)(561944003)(14454004)(6916009)(25786009)(478600001)(966005)(72206003)(10710500007)(7736002)(4744005)(790700001)(6116002)(3846002)(256004)(5024004)(33656002)(2906002)(6436002)(68736007)(7110500001)(53936002)(236005)(99286004)(2501003)(14444005)(2420400007)(15650500001)(97736004)(9686003)(2473003)(6306002)(54896002)(71200400001)(71190400001)(86362001)(2351001)(7696005)(106356001)(26005)(53546011)(476003)(102836004)(105586002)(606006)(186003)(8936002)(1730700003)(8676002)(81156014)(81166006)(316002)(66066001)(55016002)(5640700003)(6506007); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB1935; 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-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: IXSt/d6lot1LMsArhOOM2HSIdu/xGBJ7zwEA8cbuHVywrsUiTuBIRGidfsFVjpwNJKWwljGH2Z0VGlQNdG66R/Iph2hgJtbl1xybHpl2Qkc2AlezMSVCH+DRJ1ZEcL7gvr6txjc3xcgK8ue2ObY1NbZijtDZ/a3hDTEZABa5+0OIdECU2QzskWMlEQ4KEMsyff4tkoWFxlt9mL0tSOVyi4w4WaAhmM4Ajyz5ZRWCKvcVKYuWCjUBMiARnx4ghpeii3SVL0XaGq+04WpTkLaX1evhnkjMkXspE0x6mmtrXoPK5+oddJPpHwk2YDz0i+8E3xgeGxkwIAtWkDYG0FPFbAq2/ohYpCqBRbfpf2IHR8yor1vIRv2KeAYLZjiFZcchFobfHz3sJzSwUy9TtgEx7Fke1ioxSeEm38HOHZjhm74= Content-Type: multipart/alternative; boundary="_000_VI1PR0801MB21127F51B83F45C5150EB801FA960VI1PR0801MB2112_" MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: 7f4ef01c-1615-420c-5d84-08d685477ea8 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Jan 2019 17:39:03.2545 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1935 Archived-At: Subject: [Ace] FW: [OAUTH-WG] OAuth Security Workshop Call for Proposals X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2019 17:39:10 -0000 --_000_VI1PR0801MB21127F51B83F45C5150EB801FA960VI1PR0801MB2112_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This workshop may be of interest to you, particularly if you work on ACE-Oa= uth specification. From: OAuth > On Beha= lf Of Torsten Lodderstedt Sent: Freitag, 11. Januar 2019 21:32 To: oauth@ietf.org Subject: [OAUTH-WG] OAuth Security Workshop Call for Proposals Hi all, the Call for Proposal for the 4th OAuth Security Workshop is out! https://sec.uni-stuttgart.de/events/osw2019 Please propose a session! kind regards, Torsten. 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. --_000_VI1PR0801MB21127F51B83F45C5150EB801FA960VI1PR0801MB2112_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This workshop may be of interes= t to you, particularly if you work on ACE-Oauth specification.

 =

From: OAuth <oauth-bounc= es@ietf.org> On Behalf Of Torsten Lodderstedt
Sent: Freitag, 11. Januar 2019 21:32
To: oauth@ietf.org
Subject: [OAUTH-WG] OAuth Security Workshop Call for Proposals<= /o:p>

 

Hi all,

 

the Call for Proposal for the 4th OAuth Security Wor= kshop is out! 

 

https://sec.uni-stuttgart.de/events/osw2019

 

Please propose a session!

 

kind regards,

Torsten.

 

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. --_000_VI1PR0801MB21127F51B83F45C5150EB801FA960VI1PR0801MB2112_-- From nobody Mon Jan 28 12:20:07 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8A2A1311E0 for ; Mon, 28 Jan 2019 12:20:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 BJpfjFcguR82 for ; Mon, 28 Jan 2019 12:20:02 -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 6B3C81311DF for ; Mon, 28 Jan 2019 12:20:02 -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 x0SKJrxu013664; Mon, 28 Jan 2019 15:19:53 -0500 DKIM-Filter: OpenDKIM Filter v2.11.0 taper.sei.cmu.edu x0SKJrxu013664 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sei.cmu.edu; s=t52kn2igOmwp; t=1548706798; bh=NTxVK/iipavGGtgPqWGh52HqbeGF1RtnqYd97AdjfCA=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=eAlz6tzPzFq3EsCrCSHCdSFgCbofWxmWXvMJCg1srjydNoAbX3e/tRufU1mctz5pl AVbpmc8XVlVchrXOMnjYzc8LGvFI/tJAN4SCiT9WSWPNEgjzgW/TPDQ+GM/bFxolJW zKg/8ZCPF/eka8JpWpBvP64E9P0saIv2xCh5LXUA= 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 x0SKJpWe029517; Mon, 28 Jan 2019 15:19:51 -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.0435.000; Mon, 28 Jan 2019 15:19:51 -0500 From: Sebastian Echeverria To: Hannes Tschofenig CC: Grace A Lewis , "ace@ietf.org" , "Dan Klinedinst" Thread-Topic: ACE Implementation for Disadvantaged Environments Thread-Index: AQHUs0cwxz8vJeWIVUGFns83Bt0/66XEercQgAA76QCAABjZAIAAAtXQgABP35A= Date: Mon, 28 Jan 2019 20:19:50 +0000 Message-ID: <45D237D6DC600143A1C52C1C82BEBD1AAC927B8D@marathon> References: <11C08BF5-0060-459C-99DC-EABEA88DF44B@sei.cmu.edu> <0FCF1038-D6C8-4C25-9B4C-E493EB817592@sei.cmu.edu> <7387610A-D857-49FE-9964-77D54CDDA2F4@sei.cmu.edu> 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: multipart/alternative; boundary="_000_45D237D6DC600143A1C52C1C82BEBD1AAC927B8Dmarathon_" MIME-Version: 1.0 Archived-At: Subject: Re: [Ace] ACE Implementation for Disadvantaged Environments X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2019 20:20:06 -0000 --_000_45D237D6DC600143A1C52C1C82BEBD1AAC927B8Dmarathon_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgSGFubmVzLA0KDQpSZWdhcmRpbmcgeW91ciBxdWVzdGlvbnM6DQoNCjEuIOKAnEhvdyBlYXN5 IGRvIHlvdSB0aGluayB3b3VsZCBpdCBiZSB0byBwb3J0IHRoZSBjb2RlIHRvIHNvbWUgb3RoZXIg T1M/IChvciBpbiBvdGhlciB3b3JkczogaG93IHRpZ2h0bHkgaGF2ZSB5b3UgY291cGxlZCBpdCB0 byBDb250aWtpPynigJ0NCg0KDQotICAgICAgICAgIE1vc3Qgb2YgdGhlIGNvZGUgaXMgY2FsbGVk IGJ5IENvbnRpa2kgcHJvY2Vzc2VzLCBzbyBpdCBpcyBub3QgdGhhdCBjb3VwbGVkLCBhbmQgdGhl IGNuLWNib3IgYW5kIFRpbnlEVExTIGRlcGVuZGVuY2llcyBhcmUgaW5kZXBlbmRlbnQgZnJvbSBD b250aWtpLiBUaGUgY29kZSBkZXBlbmRzIG9uIHR3byBtYWluIHRoaW5ncyBmcm9tIENvbnRpa2k6 IHRoZSBFcmJpdW0gQ29BUCBzZXJ2ZXIsIGFuZCB0aGUgQ0ZTIGZpbGUgc3lzdGVtLiBUaGUgY291 cGxpbmcgd2l0aCBFcmJpdW0gaXMgbm90IHRoYXQgc3Ryb25nLCBidXQgd2hlcmV2ZXIgdGhlIGNv ZGUgaXMgcG9ydGVkLCBpdCB3b3VsZCBuZWVkIGEgQ29BUC9Db0FQcyBzZXJ2ZXIgb24gdGhhdCBP Uywgb3IgdGhlIGFjdHVhbCBwb3J0aW5nIG9mIGEgc3Vic2V0IG9mIEVyYml1bSAod2hpY2ggSSBn dWVzcyBpcyBkb2FibGUsIGJ1dCBpdCBtYXkgYmUgc3Vic3RhbnRpYWwgd29yaykuIFRoZSBkZXBl bmRlbmN5IG9uIHRoZSBDRlMgZmlsZSBzeXN0ZW0gaXMgZm9yIHN0b3Jpbmcga2V5cyBhbmQgdG9r ZW5zLCBhbmQgdGhhdCB3b3VsZCBuZWVkIHRvIGJlIGFkYXB0ZWQgdG8gd2hhdGV2ZXIgYW5vdGhl ciBPUyBvZmZlcnMsIHRob3VnaCB0aGlzIGRlcGVuZGVuY3kgaXMgZmFpcmx5IGNvbnRhaW5lZCBp biBvbmUgbW9kdWxlLCBhbmQgY2hhbmdlcyBzaG91bGQgbm90IGJlIHRoYXQgaGFyZC4NCg0KMi4g 4oCcSXMgdGhlIENPU0UvQ1dUIHBhcnNpbmcgbGlicmFyeSBzZXBhcmFibGUgZnJvbSB0aGUgcmVz dD8g4oCcDQoNCg0KLSAgICAgICAgICBZZXMsIGl0IGlzIGZhaXJseSBzZXBhcmFibGUgZnJvbSB0 aGUgcmVzdCwgb3RoZXIgdGhhbiB0aGUgZmFjdCB0aGF0IGl0IHVzZXMgY24tY2JvciBmb3IgY2Jv ciBwYXJzaW5nLCBhbmQgVGlueURUTFMgZm9yIEFFUyBkZWNyeXB0aW9uLiBIb3dldmVyLCBhdCB0 aGUgbW9tZW50IGl0IGlzIHZlcnkgbGltaXRlZCBpbiB0ZXJtcyBvZiBDT1NFIHBhcnNpbmcsIG9u bHkgc3VwcG9ydGluZyB0aGUgQ09TRSB3cmFwcGVyIGFuZCBjeXBoZXIgc3VpdGVzIHdlIGFyZSBh Y3R1YWxseSB1c2luZy9zdXBwb3J0aW5nIGluIG91ciBpbXBsZW1lbnRhdGlvbi4NCg0KMy4g4oCc Rm9yIHRoZSAzMDAgS2IgZmxhc2g6IGRvZXMgdGhpcyBjb250YWluIHRoZSBmaXJtd2FyZSB1cGRh dGUgbWVjaGFuaXNtP+KAnQ0KDQoNCi0gICAgICAgICAgTm8sIHRoaXMgZG9lcyBub3QgaW5jbHVk ZSB0aGUgZmlybXdhcmUgdXBkYXRlIG1lY2hhbmlzbS4NCg0KQW55IG1vcmUgcXVlc3Rpb25zLCBq dXN0IGxldCBtZSBrbm93Lg0KDQpUaGFua3MsDQoNClNlYmFzdGlhbg0KDQpGcm9tOiBIYW5uZXMg VHNjaG9mZW5pZyBbbWFpbHRvOkhhbm5lcy5Uc2Nob2ZlbmlnQGFybS5jb21dDQpTZW50OiBNb25k YXksIEphbnVhcnkgMjgsIDIwMTkgMTA6MTkgQU0NClRvOiBTZWJhc3RpYW4gRWNoZXZlcnJpYSA8 c2VjaGV2ZXJyaWFAc2VpLmNtdS5lZHU+DQpDYzogR3JhY2UgQSBMZXdpcyA8Z2xld2lzQHNlaS5j bXUuZWR1PjsgYWNlQGlldGYub3JnOyBEYW4gS2xpbmVkaW5zdCA8ZGprbGluZWRpbnN0QGNlcnQu b3JnPg0KU3ViamVjdDogUkU6IEFDRSBJbXBsZW1lbnRhdGlvbiBmb3IgRGlzYWR2YW50YWdlZCBF bnZpcm9ubWVudHMNCg0KSGkgU2ViYXN0aWFuLA0KDQpUaGFua3MgZm9yIHRoZSBkZXRhaWxzLiBI b3cgZWFzeSBkbyB5b3UgdGhpbmsgd291bGQgaXQgYmUgdG8gcG9ydCB0aGUgY29kZSB0byBzb21l IG90aGVyIE9TPyAob3IgaW4gb3RoZXIgd29yZHM6IGhvdyB0aWdodGx5IGhhdmUgeW91IGNvdXBs ZWQgaXQgdG8gQ29udGlraT8pDQoNCklzIHRoZSBDT1NFL0NXVCBwYXJzaW5nIGxpYnJhcnkgc2Vw YXJhYmxlIGZyb20gdGhlIHJlc3Q/DQoNCkZvciB0aGUgMzAwIEtiIGZsYXNoOiBkb2VzIHRoaXMg Y29udGFpbiB0aGUgZmlybXdhcmUgdXBkYXRlIG1lY2hhbmlzbT8NCg0KQ2lhbw0KSGFubmVzDQoN CkZyb206IFNlYmFzdGlhbiBFY2hldmVycmlhIDxzZWNoZXZlcnJpYUBzZWkuY211LmVkdTxtYWls dG86c2VjaGV2ZXJyaWFAc2VpLmNtdS5lZHU+Pg0KU2VudDogTW9udGFnLCAyOC4gSmFudWFyIDIw MTkgMTY6MDYNClRvOiBIYW5uZXMgVHNjaG9mZW5pZyA8SGFubmVzLlRzY2hvZmVuaWdAYXJtLmNv bTxtYWlsdG86SGFubmVzLlRzY2hvZmVuaWdAYXJtLmNvbT4+DQpDYzogR3JhY2UgQSBMZXdpcyA8 Z2xld2lzQHNlaS5jbXUuZWR1PG1haWx0bzpnbGV3aXNAc2VpLmNtdS5lZHU+PjsgYWNlQGlldGYu b3JnPG1haWx0bzphY2VAaWV0Zi5vcmc+OyBEYW4gS2xpbmVkaW5zdCA8ZGprbGluZWRpbnN0QGNl cnQub3JnPG1haWx0bzpkamtsaW5lZGluc3RAY2VydC5vcmc+Pg0KU3ViamVjdDogUmU6IEFDRSBJ bXBsZW1lbnRhdGlvbiBmb3IgRGlzYWR2YW50YWdlZCBFbnZpcm9ubWVudHMNCg0KSGVsbG8sDQoN CkhlcmUgaXMgc29tZSBtb3JlIGluZm9ybWF0aW9uIGFib3V0IGl0Og0KDQotICAgICAgICAgIFdl IHVzZWQgQ29udGlraSBhcyB0aGUgYmFzZS9PUyBmb3IgdGhlIGNvZGUuIE1vcmUgc3BlY2lmaWNh bGx5LCB3ZSBmb3JrZWQgZnJvbSB0aGUgNmxiciBwcm9qZWN0IChodHRwczovL2dpdGh1Yi5jb20v Y2V0aWMvNmxiciksIGFzIHRoYXQgdmVyc2lvbiBhbHJlYWR5IGhhZCBzb21lIGNvZGUgZm9yIGhh bmRsaW5nIERUTFMgY29ubmVjdGlvbnMgYW5kIEFFUyBlbmNyeXB0aW9uIGluIGl0Lg0KLSAgICAg ICAgICBXZSBhcmUgdXNpbmcgdGhlIFRJIENDMjUzOGRrIGJvYXJkIGFzIG91ciBjb25zdHJhaW5l ZCB0YXJnZXQgcGxhdGZvcm0uDQotICAgICAgICAgIFRoZSBpbXBsZW1lbnRhdGlvbiBoYXMgc3Vw cG9ydCBmb3IgdGhlIERUTFMgcHJvZmlsZSwgdXNpbmcgcHJlLXNoYXJlZCBrZXlzLCBhcyB0aGlz IHdhcyBlbm91Z2ggZm9yIG91ciB1c2UgY2FzZS4NCi0gICAgICAgICAgVGhlIGltcGxlbWVudGF0 aW9uIGhhbmRsZXMgQ1dUIHRva2Vucy4NCi0gICAgICAgICAgV2UgbW9kaWZpZWQgdGhlIEVyYml1 bSBDb0FQIHNlcnZlciBpbiA2bGJyIHRvIGJlIGFibGUgdG8gc2ltdWx0YW5lb3VzbHkgbGlzdGVu IGZvciBDb0FQIGFuZCBDb0FQcyBjb25uZWN0aW9ucyAodXNpbmcgVGlueURUTFMgdW5kZXJuZWF0 aCkuDQotICAgICAgICAgIFRoZSBpbXBsZW1lbnRhdGlvbiB1c2VzIHRoZSBjbi1jYm9yIGxpYnJh cnkgZm9yIGRlY29kaW5nIENCT1IgZGF0YS4NCi0gICAgICAgICAgVGhlIGltcGxlbWVudGF0aW9u IHN1cHBvcnRzIHJlY2VpdmluZyB0b2tlbnMgYXQgdGhlIGF1dGh6LWluZm8gZW5kcG9pbnQsIGFu ZCB0aGVuIGdpdmluZyBhY2Nlc3MgdG8gYSBjb3VwbGUgb2Ygc2FtcGxlIHJlc291cmNlcyBiYXNl ZCBvbiB0aGUgY2xhaW1zIGZyb20gdGhlIHJlY2VpdmVkIHRva2Vucy4NCi0gICAgICAgICAgVGhl IGltcGxlbWVudGF0aW9uIGhhcyBzb21lIGFkZGl0aW9uYWwgb3B0aW9uYWwgZmVhdHVyZXMgcmVs YXRlZCB0byBvdXIgZGlzYWR2YW50YWdlZCBuZXR3b3JrIGVudmlyb25tZW50cywgc3VjaCBhcyBi b290c3RyYXBwaW5nIG9mIHRoZSBQU0sgY3JlZGVudGlhbHMsIGFuZCBkZXRlY3RpbmcgcmV2b2tl ZCB0b2tlbnMgdGhyb3VnaCBpbnRyb3NwZWN0aW9uLg0KLSAgICAgICAgICBUaGUgY3VycmVudCBi aW5hcnkgaXMgYXJvdW5kIDMwMCBrYiwgd2hpY2ggaXMgZ29vZCBlbm91Z2ggZm9yIHRoZSA1MTIg a2IgZmxhc2ggb24gdGhlIFRJIGJvYXJkcywgdGhvdWdoIGl0IG1heSBiZSBhIGJpdCB0b28gbGFy Z2UgZm9yIGEgY2xhc3MgSUkgZGV2aWNlLiBXZSBjYW4gcHJvYmFibHkgbWFrZSBpdCBhIGJpdCBz bWFsbGVyLiBJbiB0ZXJtcyBvZiBSQU0sIGl0IGZpdHMgaW4gdGhlIDMyIEtCIGF2YWlsYWJsZSBv biB0aGUgVEkgYm9hcmRzLg0KDQpCZXN0LA0KDQotLS0NClNlYmFzdGlhbiBFY2hldmVycmlhDQpU YWN0aWNhbCBUZWNobm9sb2dpZXMgR3JvdXAgKFRURykNClNvZnR3YXJlIEVuZ2luZWVyaW5nIElu c3RpdHV0ZQ0KQ2FybmVnaWUgTWVsbG9uIFVuaXZlcnNpdHkNCg0KDQoNCkZyb206IEhhbm5lcyBU c2Nob2ZlbmlnIDxIYW5uZXMuVHNjaG9mZW5pZ0Bhcm0uY29tPG1haWx0bzpIYW5uZXMuVHNjaG9m ZW5pZ0Bhcm0uY29tPj4NCkRhdGU6IE1vbmRheSwgSmFudWFyeSAyOCwgMjAxOSBhdCA1OjA1IEFN DQpUbzogR3JhY2UgTGV3aXMgPGdsZXdpc0BzZWkuY211LmVkdTxtYWlsdG86Z2xld2lzQHNlaS5j bXUuZWR1Pj4sICJhY2VAaWV0Zi5vcmc8bWFpbHRvOmFjZUBpZXRmLm9yZz4iIDxhY2VAaWV0Zi5v cmc8bWFpbHRvOmFjZUBpZXRmLm9yZz4+DQpTdWJqZWN0OiBSRTogQUNFIEltcGxlbWVudGF0aW9u IGZvciBEaXNhZHZhbnRhZ2VkIEVudmlyb25tZW50cw0KDQpDb25ncmF0cyB0byB0aGUgd29yay4g Q291bGQgeW91IHNheSBhIGxpdHRsZSBiaXQgdGhlIChjb25zdHJhaW5lZCkgcmVzb3VyY2Ugc2Vy dmVyIGltcGxlbWVudGF0aW9uPw0KDQpDaWFvDQpIYW5uZXMNCg0KRnJvbTogQWNlIDxhY2UtYm91 bmNlc0BpZXRmLm9yZzxtYWlsdG86YWNlLWJvdW5jZXNAaWV0Zi5vcmc+PiBPbiBCZWhhbGYgT2Yg R3JhY2UgQSBMZXdpcw0KU2VudDogTWl0dHdvY2gsIDIzLiBKYW51YXIgMjAxOSAxOToxMg0KVG86 IGFjZUBpZXRmLm9yZzxtYWlsdG86YWNlQGlldGYub3JnPg0KU3ViamVjdDogW0FjZV0gQUNFIElt cGxlbWVudGF0aW9uIGZvciBEaXNhZHZhbnRhZ2VkIEVudmlyb25tZW50cw0KDQpIZWxsbywNCg0K SSBqdXN0IHdhbnRlZCB0byBtYWtlIHRoZSBncm91cCBhd2FyZSBvZiBvdXIgQUNFIGltcGxlbWVu dGF0aW9uIChTRUktQUNFKSwgd2hpY2ggaW5jbHVkZXMgYW4gaW1wbGVtZW50YXRpb24gZm9yIGEg cmVzb3VyY2UtY29uc3RyYWluZWQgc2VydmVyLg0KDQpEZXRhaWxzIGF2YWlsYWJsZSBpbiB0aGlz IG5ld3MgYXJ0aWNsZTogaHR0cHM6Ly93d3cuc2VpLmNtdS5lZHUvbmV3cy1ldmVudHMvbmV3cy9h cnRpY2xlLmNmbT9hc3NldGlkPTUzOTE4NA0KDQpBcnRpY2xlIGluY2x1ZGVzIHRoZSBsaW5rIHRv IG91ciBHaXQgcmVwby4NCg0KRW5qb3khDQoNCi0gR3JhY2UgTGV3aXMNCg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KR3JhY2UgQS4gTGV3aXMsIFBoLkQu DQpQcmluY2lwYWwgUmVzZWFyY2hlciBhbmQgVFRHIEluaXRpYXRpdmUgTGVhZA0KQ2FybmVnaWUg TWVsbG9uIFNvZnR3YXJlIEVuZ2luZWVyaW5nIEluc3RpdHV0ZQ0KU29mdHdhcmUgU29sdXRpb25z IERpdmlzaW9uIChTU0QpDQpUYWN0aWNhbCBUZWNobm9sb2dpZXMgR3JvdXAgKFRURykNCg0KNDUw MCBGaWZ0aCBBdmUuICM1NDEyDQpQaXR0c2J1cmdoLCBQQSAxNTIxMw0KUGhvbmU6ICg0MTIpIDI2 OC01ODUxDQpodHRwOi8vd3d3LnNlaS5jbXUuZWR1L3N0YWZmL2dsZXdpcw0KDQrigJxBIGNoYW5n ZSBpbiBwZXJzcGVjdGl2ZSBpcyB3b3J0aCA4MCBJUSBwb2ludHPigJ0gLS0tIEFsYW4gS2F5DQpJ TVBPUlRBTlQgTk9USUNFOiBUaGUgY29udGVudHMgb2YgdGhpcyBlbWFpbCBhbmQgYW55IGF0dGFj aG1lbnRzIGFyZSBjb25maWRlbnRpYWwgYW5kIG1heSBhbHNvIGJlIHByaXZpbGVnZWQuIElmIHlv dSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRl ciBpbW1lZGlhdGVseSBhbmQgZG8gbm90IGRpc2Nsb3NlIHRoZSBjb250ZW50cyB0byBhbnkgb3Ro ZXIgcGVyc29uLCB1c2UgaXQgZm9yIGFueSBwdXJwb3NlLCBvciBzdG9yZSBvciBjb3B5IHRoZSBp bmZvcm1hdGlvbiBpbiBhbnkgbWVkaXVtLiBUaGFuayB5b3UuDQpJTVBPUlRBTlQgTk9USUNFOiBU aGUgY29udGVudHMgb2YgdGhpcyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBjb25maWRl bnRpYWwgYW5kIG1heSBhbHNvIGJlIHByaXZpbGVnZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRl bmRlZCByZWNpcGllbnQsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBhbmQg ZG8gbm90IGRpc2Nsb3NlIHRoZSBjb250ZW50cyB0byBhbnkgb3RoZXIgcGVyc29uLCB1c2UgaXQg Zm9yIGFueSBwdXJwb3NlLCBvciBzdG9yZSBvciBjb3B5IHRoZSBpbmZvcm1hdGlvbiBpbiBhbnkg bWVkaXVtLiBUaGFuayB5b3UuDQo= --_000_45D237D6DC600143A1C52C1C82BEBD1AAC927B8Dmarathon_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIg MiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpPcHRpbWE7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseTotd2Via2l0LXN0YW5kYXJkO30NCi8qIFN0eWxlIERlZmluaXRp b25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdp bjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGlu aw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6IzA1NjNDMTsNCgl0ZXh0LWRlY29y YXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Izk1NEY3MjsNCgl0ZXh0LWRlY29yYXRp b246dW5kZXJsaW5lO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwg ZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10 b3A6MGluOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2lu LWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpwLm1zb25vcm1hbDAsIGxpLm1z b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJ e21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm O30NCnNwYW4uRW1haWxTdHlsZTIyDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTIzDQoJe21zby1z dHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30N CnNwYW4uRW1haWxTdHlsZTI0DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0No cERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBw dDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEu MGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2Vj dGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6 NDk4MDM4NDczOw0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlk czoxNTk2NzU3MzEyIDE0NjM2OTcwMzIgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2 OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDA6bGV2ZWwx DQoJe21zby1sZXZlbC1zdGFydC1hdDowOw0KCW1zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDotOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6IlRp bWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZl bDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C tzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlz dCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmll ciBOZXciO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9u dC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2 ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv gqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0K QGxpc3QgbDENCgl7bXNvLWxpc3QtaWQ6NzAwMzI3MjUzOw0KCW1zby1saXN0LXRlbXBsYXRlLWlk czotMTQ2MjE4NTUyNjt9DQpAbGlzdCBsMTpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6LjVp bjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBs aXN0IGwxOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsMw0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1z by1sZXZlbC10YWItc3RvcDoxLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9u dC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoy LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30N CkBsaXN0IGwxOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjVpbjsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZv bnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsNg0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0K CW1zby1sZXZlbC10YWItc3RvcDozLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3Rv cDozLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9s O30NCkBsaXN0IGwxOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjBpbjsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNp LWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVs OQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3 Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7 DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyDQoJe21zby1saXN0LWlkOjEyODg5NzEz MjE7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xNzE0 Nzg1NDk2IDE0OTcyMzY2MTggNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2 OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDI6bGV2ZWwxDQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDotOw0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCglt YXJnaW4tbGVmdDoyMC4yNXB0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsc2Fucy1zZXJpZjsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseTpDYWxpYnJpO30N CkBsaXN0IGwyOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6NTYuMjVwdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMjpsZXZlbDMNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJbWFyZ2luLWxlZnQ6OTIuMjVwdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1p bHk6V2luZ2RpbmdzO30NCkBsaXN0IGwyOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDoxMjguMjVw dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwy OmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6MTY0LjI1cHQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDI6bGV2ZWw2DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdp bi1sZWZ0OjIwMC4yNXB0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5n ZGluZ3M7fQ0KQGxpc3QgbDI6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjIzNi4yNXB0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDI6bGV2ZWw4 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgltYXJnaW4tbGVmdDoyNzIuMjVwdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1m YW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMjpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6 MzA4LjI1cHQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9 DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQot LT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4 dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpl eHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+ DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRG NzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0QiPkhpIEhhbm5lcyw8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xv cjojMUY0OTdEIj5SZWdhcmRpbmcgeW91ciBxdWVzdGlvbnM6PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4xLiDigJxI b3cgZWFzeSBkbyB5b3UgdGhpbmsgd291bGQgaXQgYmUgdG8gcG9ydCB0aGUgY29kZSB0byBzb21l IG90aGVyIE9TPyAob3IgaW4gb3RoZXIgd29yZHM6IGhvdyB0aWdodGx5IGhhdmUgeW91IGNvdXBs ZWQgaXQgdG8gQ29udGlraT8p4oCdPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5 bGU9Im1hcmdpbi1sZWZ0OjIwLjI1cHQ7dGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwyIGxl dmVsMSBsZm80Ij4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2NvbG9yOiMxRjQ5N0QiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPi08c3Bh biBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwv c3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9y OiMxRjQ5N0QiPk1vc3Qgb2YgdGhlIGNvZGUgaXMgY2FsbGVkIGJ5IENvbnRpa2kgcHJvY2Vzc2Vz LCBzbyBpdCBpcyBub3QgdGhhdCBjb3VwbGVkLCBhbmQgdGhlIGNuLWNib3IgYW5kIFRpbnlEVExT IGRlcGVuZGVuY2llcyBhcmUgaW5kZXBlbmRlbnQgZnJvbSBDb250aWtpLiBUaGUgY29kZSBkZXBl bmRzIG9uIHR3byBtYWluIHRoaW5ncw0KIGZyb20gQ29udGlraTogdGhlIEVyYml1bSBDb0FQIHNl cnZlciwgYW5kIHRoZSBDRlMgZmlsZSBzeXN0ZW0uIFRoZSBjb3VwbGluZyB3aXRoIEVyYml1bSBp cyBub3QgdGhhdCBzdHJvbmcsIGJ1dCB3aGVyZXZlciB0aGUgY29kZSBpcyBwb3J0ZWQsIGl0IHdv dWxkIG5lZWQgYSBDb0FQL0NvQVBzIHNlcnZlciBvbiB0aGF0IE9TLCBvciB0aGUgYWN0dWFsIHBv cnRpbmcgb2YgYSBzdWJzZXQgb2YgRXJiaXVtICh3aGljaCBJIGd1ZXNzIGlzIGRvYWJsZSwNCiBi dXQgaXQgbWF5IGJlIHN1YnN0YW50aWFsIHdvcmspLiBUaGUgZGVwZW5kZW5jeSBvbiB0aGUgQ0ZT IGZpbGUgc3lzdGVtIGlzIGZvciBzdG9yaW5nIGtleXMgYW5kIHRva2VucywgYW5kIHRoYXQgd291 bGQgbmVlZCB0byBiZSBhZGFwdGVkIHRvIHdoYXRldmVyIGFub3RoZXIgT1Mgb2ZmZXJzLCB0aG91 Z2ggdGhpcyBkZXBlbmRlbmN5IGlzIGZhaXJseSBjb250YWluZWQgaW4gb25lIG1vZHVsZSwgYW5k IGNoYW5nZXMgc2hvdWxkIG5vdCBiZSB0aGF0DQogaGFyZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Mi4g4oCcSXMg dGhlIENPU0UvQ1dUIHBhcnNpbmcgbGlicmFyeSBzZXBhcmFibGUgZnJvbSB0aGUgcmVzdD8g4oCc PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjIwLjI1 cHQ7dGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwyIGxldmVsMSBsZm80Ij4NCjwhW2lmICFz dXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0Qi PjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPi08c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAm cXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZd PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0QiPlllcywgaXQgaXMg ZmFpcmx5IHNlcGFyYWJsZSBmcm9tIHRoZSByZXN0LCBvdGhlciB0aGFuIHRoZSBmYWN0IHRoYXQg aXQgdXNlcyBjbi1jYm9yIGZvciBjYm9yIHBhcnNpbmcsIGFuZCBUaW55RFRMUyBmb3IgQUVTIGRl Y3J5cHRpb24uIEhvd2V2ZXIsIGF0IHRoZSBtb21lbnQgaXQgaXMgdmVyeSBsaW1pdGVkIGluIHRl cm1zDQogb2YgQ09TRSBwYXJzaW5nLCBvbmx5IHN1cHBvcnRpbmcgdGhlIENPU0Ugd3JhcHBlciBh bmQgY3lwaGVyIHN1aXRlcyB3ZSBhcmUgYWN0dWFsbHkgdXNpbmcvc3VwcG9ydGluZyBpbiBvdXIg aW1wbGVtZW50YXRpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1H QiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjMuIOKAnEZvciB0aGUgMzAwIEtiIGZsYXNoOiBk b2VzIHRoaXMgY29udGFpbiB0aGUgZmlybXdhcmUgdXBkYXRlIG1lY2hhbmlzbT/igJ08bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjIwLjI1cHQ7dGV4 dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwyIGxldmVsMSBsZm80Ij4NCjwhW2lmICFzdXBwb3J0 TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0QiPjxzcGFu IHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPi08c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtU aW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0QiPk5vLCB0aGlzIGRvZXMgbm90 IGluY2x1ZGUgdGhlIGZpcm13YXJlIHVwZGF0ZSBtZWNoYW5pc20uPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCI+QW55 IG1vcmUgcXVlc3Rpb25zLCBqdXN0IGxldCBtZSBrbm93LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0QiPlRoYW5rcyw8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtj b2xvcjojMUY0OTdEIj5TZWJhc3RpYW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAw aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+IEhhbm5l cyBUc2Nob2ZlbmlnIFttYWlsdG86SGFubmVzLlRzY2hvZmVuaWdAYXJtLmNvbV0NCjxicj4NCjxi PlNlbnQ6PC9iPiBNb25kYXksIEphbnVhcnkgMjgsIDIwMTkgMTA6MTkgQU08YnI+DQo8Yj5Ubzo8 L2I+IFNlYmFzdGlhbiBFY2hldmVycmlhICZsdDtzZWNoZXZlcnJpYUBzZWkuY211LmVkdSZndDs8 YnI+DQo8Yj5DYzo8L2I+IEdyYWNlIEEgTGV3aXMgJmx0O2dsZXdpc0BzZWkuY211LmVkdSZndDs7 IGFjZUBpZXRmLm9yZzsgRGFuIEtsaW5lZGluc3QgJmx0O2Rqa2xpbmVkaW5zdEBjZXJ0Lm9yZyZn dDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IEFDRSBJbXBsZW1lbnRhdGlvbiBmb3IgRGlzYWR2 YW50YWdlZCBFbnZpcm9ubWVudHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkhp IFNlYmFzdGlhbiwgPG86cD4NCjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdC IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+VGhhbmtzIGZvciB0aGUgZGV0YWlscy4gSG93IGVh c3kgZG8geW91IHRoaW5rIHdvdWxkIGl0IGJlIHRvIHBvcnQgdGhlIGNvZGUgdG8gc29tZSBvdGhl ciBPUz8gKG9yIGluIG90aGVyIHdvcmRzOiBob3cgdGlnaHRseSBoYXZlIHlvdSBjb3VwbGVkIGl0 IHRvIENvbnRpa2k/KTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0Ii IHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5JcyB0aGUgQ09TRS9DV1QgcGFyc2luZyBsaWJyYXJ5 IHNlcGFyYWJsZSBmcm9tIHRoZSByZXN0Pw0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkZvciB0aGUgMzAwIEtiIGZs YXNoOiBkb2VzIHRoaXMgY29udGFpbiB0aGUgZmlybXdhcmUgdXBkYXRlIG1lY2hhbmlzbT88bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1H QiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdCI+Q2lhbzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+SGFubmVzPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0Ii IHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEu MHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdCI+IFNlYmFzdGlhbiBFY2hldmVycmlhICZsdDs8YSBocmVmPSJt YWlsdG86c2VjaGV2ZXJyaWFAc2VpLmNtdS5lZHUiPnNlY2hldmVycmlhQHNlaS5jbXUuZWR1PC9h PiZndDsNCjxicj4NCjxiPlNlbnQ6PC9iPiBNb250YWcsIDI4LiBKYW51YXIgMjAxOSAxNjowNjxi cj4NCjxiPlRvOjwvYj4gSGFubmVzIFRzY2hvZmVuaWcgJmx0OzxhIGhyZWY9Im1haWx0bzpIYW5u ZXMuVHNjaG9mZW5pZ0Bhcm0uY29tIj5IYW5uZXMuVHNjaG9mZW5pZ0Bhcm0uY29tPC9hPiZndDs8 YnI+DQo8Yj5DYzo8L2I+IEdyYWNlIEEgTGV3aXMgJmx0OzxhIGhyZWY9Im1haWx0bzpnbGV3aXNA c2VpLmNtdS5lZHUiPmdsZXdpc0BzZWkuY211LmVkdTwvYT4mZ3Q7Ow0KPGEgaHJlZj0ibWFpbHRv OmFjZUBpZXRmLm9yZyI+YWNlQGlldGYub3JnPC9hPjsgRGFuIEtsaW5lZGluc3QgJmx0OzxhIGhy ZWY9Im1haWx0bzpkamtsaW5lZGluc3RAY2VydC5vcmciPmRqa2xpbmVkaW5zdEBjZXJ0Lm9yZzwv YT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBBQ0UgSW1wbGVtZW50YXRpb24gZm9yIERp c2FkdmFudGFnZWQgRW52aXJvbm1lbnRzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IZWxsbyw8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+SGVyZSBpcyBzb21lIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgaXQ6IDxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbjt0ZXh0LWluZGVu dDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzMiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+ PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+LTxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZx dW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT5XZSB1c2Vk IENvbnRpa2kgYXMgdGhlIGJhc2UvT1MgZm9yIHRoZSBjb2RlLiBNb3JlIHNwZWNpZmljYWxseSwg d2UgZm9ya2VkIGZyb20gdGhlIDZsYnIgcHJvamVjdCAoPGEgaHJlZj0iaHR0cHM6Ly9naXRodWIu Y29tL2NldGljLzZsYnIiPmh0dHBzOi8vZ2l0aHViLmNvbS9jZXRpYy82bGJyPC9hPiksIGFzIHRo YXQgdmVyc2lvbiBhbHJlYWR5IGhhZCBzb21lIGNvZGUgZm9yIGhhbmRsaW5nIERUTFMgY29ubmVj dGlvbnMNCiBhbmQgQUVTIGVuY3J5cHRpb24gaW4gaXQuPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbjt0ZXh0LWluZGVudDotLjI1aW47 bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzMiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5 bGU9Im1zby1saXN0Oklnbm9yZSI+LTxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVz IE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT5XZSBhcmUgdXNpbmcgdGhl IFRJIENDMjUzOGRrIGJvYXJkIGFzIG91ciBjb25zdHJhaW5lZCB0YXJnZXQgcGxhdGZvcm0uPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp bjt0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzMiPg0KPCFbaWYgIXN1 cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+LTxzcGFuIHN0eWxlPSJm b250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwhW2Vu ZGlmXT5UaGUgaW1wbGVtZW50YXRpb24gaGFzIHN1cHBvcnQgZm9yIHRoZSBEVExTIHByb2ZpbGUs IHVzaW5nIHByZS1zaGFyZWQga2V5cywgYXMgdGhpcyB3YXMgZW5vdWdoIGZvciBvdXIgdXNlIGNh c2UuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6LjVpbjt0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzMiPg0KPCFb aWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+LTxzcGFuIHN0 eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFu PjwhW2VuZGlmXT5UaGUgaW1wbGVtZW50YXRpb24gaGFuZGxlcyBDV1QgdG9rZW5zLjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW47dGV4 dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8zIj4NCjwhW2lmICFzdXBwb3J0 TGlzdHNdPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPi08c3BhbiBzdHlsZT0iZm9udDo3 LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+ V2UgbW9kaWZpZWQgdGhlIEVyYml1bSBDb0FQIHNlcnZlciBpbiA2bGJyIHRvIGJlIGFibGUgdG8g c2ltdWx0YW5lb3VzbHkgbGlzdGVuIGZvciBDb0FQIGFuZCBDb0FQcyBjb25uZWN0aW9ucyAodXNp bmcgVGlueURUTFMgdW5kZXJuZWF0aCkuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbjt0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6 bDAgbGV2ZWwxIGxmbzMiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9Im1zby1s aXN0Oklnbm9yZSI+LTxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21h biZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT5UaGUgaW1wbGVtZW50YXRpb24gdXNlcyB0 aGUgY24tY2JvciBsaWJyYXJ5IGZvciBkZWNvZGluZyBDQk9SIGRhdGEuPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbjt0ZXh0LWluZGVu dDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzMiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+ PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+LTxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZx dW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT5UaGUgaW1w bGVtZW50YXRpb24gc3VwcG9ydHMgcmVjZWl2aW5nIHRva2VucyBhdCB0aGUgYXV0aHotaW5mbyBl bmRwb2ludCwgYW5kIHRoZW4gZ2l2aW5nIGFjY2VzcyB0byBhIGNvdXBsZSBvZiBzYW1wbGUgcmVz b3VyY2VzIGJhc2VkIG9uIHRoZSBjbGFpbXMgZnJvbSB0aGUgcmVjZWl2ZWQgdG9rZW5zLjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW47 dGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8zIj4NCjwhW2lmICFzdXBw b3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPi08c3BhbiBzdHlsZT0iZm9u dDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48IVtlbmRp Zl0+VGhlIGltcGxlbWVudGF0aW9uIGhhcyBzb21lIGFkZGl0aW9uYWwgb3B0aW9uYWwgZmVhdHVy ZXMgcmVsYXRlZCB0byBvdXIgZGlzYWR2YW50YWdlZCBuZXR3b3JrIGVudmlyb25tZW50cywgc3Vj aCBhcyBib290c3RyYXBwaW5nIG9mIHRoZSBQU0sgY3JlZGVudGlhbHMsIGFuZCBkZXRlY3Rpbmcg cmV2b2tlZCB0b2tlbnMgdGhyb3VnaCBpbnRyb3NwZWN0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW47dGV4dC1pbmRlbnQ6LS4y NWluO21zby1saXN0OmwwIGxldmVsMSBsZm8zIj4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFu IHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPi08c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtU aW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+VGhlIGN1cnJlbnQg YmluYXJ5IGlzIGFyb3VuZCAzMDAga2IsIHdoaWNoIGlzIGdvb2QgZW5vdWdoIGZvciB0aGUgNTEy IGtiIGZsYXNoIG9uIHRoZSBUSSBib2FyZHMsIHRob3VnaCBpdCBtYXkgYmUgYSBiaXQgdG9vIGxh cmdlIGZvciBhIGNsYXNzIElJIGRldmljZS4gV2UgY2FuIHByb2JhYmx5IG1ha2UgaXQgYSBiaXQg c21hbGxlci4gSW4gdGVybXMgb2YgUkFNLCBpdCBmaXRzIGluIHRoZSAzMiBLQiBhdmFpbGFibGUN CiBvbiB0aGUgVEkgYm9hcmRzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CZXN0LDxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOmJsYWNrIj4tLS08bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtjb2xvcjpibGFjayI+U2ViYXN0aWFuIEVjaGV2ZXJyaWE8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtj b2xvcjpibGFjayI+VGFjdGljYWwgVGVjaG5vbG9naWVzIEdyb3VwIChUVEcpPC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtj b2xvcjpibGFjayI+U29mdHdhcmUgRW5naW5lZXJpbmcgSW5zdGl0dXRlPC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtjb2xv cjpibGFjayI+Q2FybmVnaWUgTWVsbG9uIFVuaXZlcnNpdHk8L3NwYW4+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkZyb206 IDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5IYW5uZXMgVHNjaG9mZW5pZyAm bHQ7PGEgaHJlZj0ibWFpbHRvOkhhbm5lcy5Uc2Nob2ZlbmlnQGFybS5jb20iPkhhbm5lcy5Uc2No b2ZlbmlnQGFybS5jb208L2E+Jmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5Nb25kYXksIEphbnVhcnkg MjgsIDIwMTkgYXQgNTowNSBBTTxicj4NCjxiPlRvOiA8L2I+R3JhY2UgTGV3aXMgJmx0OzxhIGhy ZWY9Im1haWx0bzpnbGV3aXNAc2VpLmNtdS5lZHUiPmdsZXdpc0BzZWkuY211LmVkdTwvYT4mZ3Q7 LCAmcXVvdDs8YSBocmVmPSJtYWlsdG86YWNlQGlldGYub3JnIj5hY2VAaWV0Zi5vcmc8L2E+JnF1 b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86YWNlQGlldGYub3JnIj5hY2VAaWV0Zi5vcmc8L2E+Jmd0 Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5SRTogQUNFIEltcGxlbWVudGF0aW9uIGZvciBEaXNhZHZh bnRhZ2VkIEVudmlyb25tZW50czwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5Db25ncmF0cyB0byB0aGUgd29yay4gQ291bGQg eW91IHNheSBhIGxpdHRsZSBiaXQgdGhlIChjb25zdHJhaW5lZCkgcmVzb3VyY2Ugc2VydmVyIGlt cGxlbWVudGF0aW9uPw0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 Ij5DaWFvPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkhhbm5lczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkZy b206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+IEFjZSAmbHQ7PGEg aHJlZj0ibWFpbHRvOmFjZS1ib3VuY2VzQGlldGYub3JnIj5hY2UtYm91bmNlc0BpZXRmLm9yZzwv YT4mZ3Q7DQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkdyYWNlIEEgTGV3aXM8YnI+DQo8Yj5TZW50Ojwv Yj4gTWl0dHdvY2gsIDIzLiBKYW51YXIgMjAxOSAxOToxMjxicj4NCjxiPlRvOjwvYj4gPGEgaHJl Zj0ibWFpbHRvOmFjZUBpZXRmLm9yZyI+YWNlQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6 PC9iPiBbQWNlXSBBQ0UgSW1wbGVtZW50YXRpb24gZm9yIERpc2FkdmFudGFnZWQgRW52aXJvbm1l bnRzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkhlbGxvLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdCI+SSBqdXN0IHdhbnRlZCB0byBtYWtlIHRoZSBncm91cCBhd2FyZSBv ZiBvdXIgQUNFIGltcGxlbWVudGF0aW9uIChTRUktQUNFKSwgd2hpY2ggaW5jbHVkZXMgYW4gaW1w bGVtZW50YXRpb24gZm9yIGEgcmVzb3VyY2UtY29uc3RyYWluZWQgc2VydmVyLjwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+RGV0YWlscyBhdmFpbGFibGUgaW4gdGhp cyBuZXdzIGFydGljbGU6DQo8YSBocmVmPSJodHRwczovL3d3dy5zZWkuY211LmVkdS9uZXdzLWV2 ZW50cy9uZXdzL2FydGljbGUuY2ZtP2Fzc2V0aWQ9NTM5MTg0Ij5odHRwczovL3d3dy5zZWkuY211 LmVkdS9uZXdzLWV2ZW50cy9uZXdzL2FydGljbGUuY2ZtP2Fzc2V0aWQ9NTM5MTg0PC9hPjwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+QXJ0aWNsZSBpbmNsdWRlcyB0 aGUgbGluayB0byBvdXIgR2l0IHJlcG8uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0Ij5FbmpveSE8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQiPi0gR3JhY2UgTGV3aXM8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Y29sb3I6IzAwMDA3RiI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6T3B0aW1hO2NvbG9yOiMwMDAwN0YiPkdyYWNlIEEu IExld2lzLCBQaC5ELjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 Ok9wdGltYTtjb2xvcjojMDAwMDdGIj5QcmluY2lwYWwgUmVzZWFyY2hlciBhbmQgVFRHIEluaXRp YXRpdmUgTGVhZCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5Ok9wdGltYTtjb2xvcjojMDAwMDdGIj5DYXJuZWdpZSBN ZWxsb24gU29mdHdhcmUgRW5naW5lZXJpbmcgSW5zdGl0dXRlPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6T3B0aW1hO2NvbG9yOiMwMDAwN0YiPlNvZnR3YXJlIFNv bHV0aW9ucyBEaXZpc2lvbiZuYnNwOyhTU0QpJm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6T3B0aW1hO2NvbG9yOiMwMDAwN0YiPlRhY3RpY2FsIFRlY2hu b2xvZ2llcyBHcm91cCAoVFRHKTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5Oi13ZWJraXQtc3RhbmRhcmQ7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5Ok9wdGltYTtjb2xvcjojMDAwMDdGIj40NTAw IEZpZnRoIEF2ZS4mbmJzcDsjNTQxMjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5Ok9wdGltYTtjb2xvcjojMDAwMDdGIj5QaXR0c2J1cmdoLCBQQSAxNTIxMyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5Ok9wdGltYTtjb2xvcjojMDAwMDdG Ij5QaG9uZTogKDQxMikgMjY4LTU4NTE8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTpPcHRp bWE7Y29sb3I6IzAwMDA3RiI+PGEgaHJlZj0iaHR0cDovL3d3dy5zZWkuY211LmVkdS9zdGFmZi9n bGV3aXMiPmh0dHA6Ly93d3cuc2VpLmNtdS5lZHUvc3RhZmYvZ2xld2lzPC9hPjwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5Ok9wdGltYTtjb2xvcjojMDAwMDdGIj4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxpPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5Ok9wdGltYTtjb2xvcjojMzg1NzIzIj7igJxB IGNoYW5nZSBpbiBwZXJzcGVjdGl2ZSBpcyB3b3J0aCA4MCBJUSBwb2ludHPigJ0gLS0tIEFsYW4g S2F5PC9zcGFuPjwvaT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5JTVBPUlRBTlQgTk9USUNFOiBUaGUgY29udGVudHMg b2YgdGhpcyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBjb25maWRlbnRpYWwgYW5kIG1h eSBhbHNvIGJlIHByaXZpbGVnZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGll bnQsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBhbmQgZG8gbm90IGRpc2Ns b3NlDQogdGhlIGNvbnRlbnRzIHRvIGFueSBvdGhlciBwZXJzb24sIHVzZSBpdCBmb3IgYW55IHB1 cnBvc2UsIG9yIHN0b3JlIG9yIGNvcHkgdGhlIGluZm9ybWF0aW9uIGluIGFueSBtZWRpdW0uIFRo YW5rIHlvdS4NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFu JnF1b3Q7LHNlcmlmIj5JTVBPUlRBTlQgTk9USUNFOiBUaGUgY29udGVudHMgb2YgdGhpcyBlbWFp bCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBjb25maWRlbnRpYWwgYW5kIG1heSBhbHNvIGJlIHBy aXZpbGVnZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBu b3RpZnkgdGhlIHNlbmRlcg0KIGltbWVkaWF0ZWx5IGFuZCBkbyBub3QgZGlzY2xvc2UgdGhlIGNv bnRlbnRzIHRvIGFueSBvdGhlciBwZXJzb24sIHVzZSBpdCBmb3IgYW55IHB1cnBvc2UsIG9yIHN0 b3JlIG9yIGNvcHkgdGhlIGluZm9ybWF0aW9uIGluIGFueSBtZWRpdW0uIFRoYW5rIHlvdS4NCjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_45D237D6DC600143A1C52C1C82BEBD1AAC927B8Dmarathon_-- From nobody Mon Jan 28 12:54:56 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EBAD131204 for ; Mon, 28 Jan 2019 12:54:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.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 PNQdzAgCj7vU for ; Mon, 28 Jan 2019 12:54:46 -0800 (PST) Received: from mail-it1-x12f.google.com (mail-it1-x12f.google.com [IPv6:2607:f8b0:4864:20::12f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8949C1311BB for ; Mon, 28 Jan 2019 12:54:45 -0800 (PST) Received: by mail-it1-x12f.google.com with SMTP id a6so673879itl.4 for ; Mon, 28 Jan 2019 12:54:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=axqc8SPM4Lr0OYb7IwijSKuiuKbw41GeAH0kBNdDFkI=; b=Yf5uDPA9n5zW3jIbC5jn/t9qJhW9VJ+LvlW1cj55I3z+QIlOjKiI2ykJGa/hN5vC2a nYTYeCpPC92ToNAtetc3AY+AXvFBEhDhTanv9zMSMvOfutYlHxkizCce+DZhuR73klJ1 +9QjzVnoN8Nfms+wNhjnbndC+9S08M6MCdQnE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=axqc8SPM4Lr0OYb7IwijSKuiuKbw41GeAH0kBNdDFkI=; b=GN9VGJJD+fxEYbrPQ3uBV11BHzapULL5j9BHjhSaRAop1HvMViS5PEsGOkur01TH9J NZyaPTdkYqVguIVsmmvC9T/dyIsHZgt0Qv88Bd9pYM9Q6PRGbvufyOE5x75WPo7LfkSy rGoT9yNgim/dXDatJ2hc0A9y6bEMG6c/xQQEFxFE3u9enuIjNZDD4WwPCjpC52XAQahK rTA+YoSXjopd7U7T6rYLTt+LOkPCO9XR7o3IhX7s5hQPSmdLWgFCMwAL5pUWiLOR/CpW cIj8vkIIqbmauBDxnouXYjCDrxj7XEbdECch6kZg28FJmnvwBWrkOaITCQqVabtqOS2P wU9g== X-Gm-Message-State: AJcUukdi/fuhuDk/FgNuBn0/889llaM6h2eDx/fukA6xUZHzsSGF1N8g 0IRQjmf4rco9fGDHGeib3ZmJte5lAxLo+S19O9p8aywpjJt8yLqX3d2KF8WbHcOalWOSN+mWMjD /IQmDAbKH530= X-Google-Smtp-Source: ALg8bN5wgdEAq0ktvbRhjpMreTuW21z4FUeL0rbZtegOGiudO9xVSkip01aAEOl9Rn/W8F30OK18/J4Nboci4USX1Ig= X-Received: by 2002:a24:6293:: with SMTP id d141mr9538601itc.124.1548708884080; Mon, 28 Jan 2019 12:54:44 -0800 (PST) MIME-Version: 1.0 References: <4eb4ea45-c3f2-7991-9544-612d055809ba@ve7jtb.com> <199fa6bd-8103-b1b3-12a3-08b5e3aad925@aol.com> <55a0362e-e588-bce5-f65f-856a1e21e88e@aol.com> In-Reply-To: From: Brian Campbell Date: Mon, 28 Jan 2019 13:54:16 -0700 Message-ID: To: Mike Jones , ace@ietf.org Cc: "George Fletcher at aol.com" , "oauth@ietf.org" , Vittorio Bertocci Content-Type: multipart/alternative; boundary="000000000000e5896805808ae2c6" Archived-At: Subject: Re: [Ace] [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resource-indicators-01 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2019 20:54:53 -0000 --000000000000e5896805808ae2c6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable [added ace@ietf.org kinda per suggestion from Mike] I don't know that there are concerns about =E2=80=9Creq_aud=E2=80=9D per se= . Admittedly, I did use the word "concerns" but I was more trying to say that referencing it from the draft-ietf-oauth-resource-indicators document wasn't needed to address Vittorio's request. And pointing out that =E2=80=9Creq_aud=E2=80=9D= is defined for the token endpoint while the draft-ietf-oauth-resource-indicators document also deals with the authorization endpoint so such a reference wouldn't really work anyway. I don't know of anyone that just works from the OAuth parameter registration but maybe I'm just out of touch. And I don't think its a stretch at all to observe that ACE OAuth and OAuth 2 are different. On Mon, Jan 28, 2019 at 11:28 AM Mike Jones wrote: > Brian, etc. If you have concerns about =E2=80=9Creq_aud=E2=80=9D, now=E2= =80=99s the time to > provide that feedback to the ACE WG, as they=E2=80=99re trying to complet= e that > draft soon. Please join the ACE WG mailing list and send your feedback > there directly. > > > > You and I may know that ACE OAuth and OAuth 2 are pretty different but > developers later will just see the OAuth parameter registration and won= =E2=80=99t > realize that it=E2=80=99s coming from a different universe. If we can ha= rmonize > things now, we should. > > > > -- Mike > > > > *From:* OAuth *On Behalf Of *George Fletcher > *Sent:* Monday, January 28, 2019 10:05 AM > *To:* Brian Campbell > *Cc:* oauth@ietf.org; Vittorio Bertocci > *Subject:* Re: [OAUTH-WG] Shepherd write-up for > draft-ietf-oauth-resource-indicators-01 > > > > +1 > > I came to a similar conclusion over the weekend. If > https://api.example.com/mail is an allowed location URI, how is it not > also a logical location considering it's possible there are multiple > endpoints "below" https://api.example.com/mail? (e.g. > https://api.example.com/mail/user/mailbox). Also if https://api.example.c= om > is really a load balancer that fronts the " > real" > endpoints, then it's also "logical" in that context and not an exact > location. > > This brings me to the conclusion that all the resource identifiers are > "logical" along a range of specificity. How specific a resource is > identified is really a risk decision and based on the deployment model ca= n > be managed at either the RS or the AS. > > Thanks, > George > > On 1/28/19 9:07 AM, Brian Campbell wrote: > > I plan on joining the meeting today at noon eastern time to discuses this > little ditty. I hope others who have a stake in it can too. > > > > The proposed changes that Vittorio and I put together can be seen in the > diff of this pull request > https://github.com/ietf-oauth-resource-indicators/i-d/pull/1/files and I > even put a xml2rfc'ed text version on > https://github.com/ietf-oauth-resource-indicators/i-d/pull/1 for ease of > reference. I maintain that is the most straightforward way forward with a= ll > this. Yet another new additional parameter could be defined for the logic= al > case but I struggle to see the value in doing so. The 'resource' is URI > that points to the resource. The level of specificity of that pointer is > intentionally a bit fuzzy and application/deployment specific. Is > https://graph.microsoft.com (mentioned in the documentation previously > linked) a location or an abstract identifier or both? The document alread= y > (somewhat awkwardly) describes using a "base URI" for the application or > resource. Is that a a location or an abstract identifier? Or kinda both? > > > > In addition to the concerns others have expressed about "req_aud", I"d > note that draft-ietf-ace-oauth-params defines its use only at the token > endpoint as one of the "additional parameters for requesting an access > token from a token endpoint in the ACE framework". Whereas the > resource-indicators draft scope includes the authorization endpoint too. > Furthermore, while the ACE WG is building on OAuth, for all intents and > purposes ACE and regular OAuth are different worlds and I think a referen= ce > in regular OAuth document like this one to "Additional OAuth Parameters f= or > Authorization in Constrained Environments (ACE)" would be a disservice to > just about everyone. > > > > > > > > > > > > > > On Thu, Jan 24, 2019 at 5:13 PM Rifaat Shekh-Yusef > wrote: > > Hannes sent an update to this meeting here: > > https://mailarchive.ietf.org/arch/msg/oauth/v8sUMEBGMC24AdWLewAymP-X4kU > > > > Regards, > > Rifaat > > > > > > On Thu, Jan 24, 2019 at 6:20 PM Mike Jones > wrote: > > The virtual office hours in my calendar start 1/2 hour before that. If > the time has changed, can you have the meeting organizer update the > calendar entry? > > > > Thanks, > > -- Mike > > > > *From:* Rifaat Shekh-Yusef > *Sent:* Thursday, January 24, 2019 12:46 PM > *To:* George Fletcher > *Cc:* Vittorio Bertocci ; Mike Jones < > Michael.Jones@microsoft.com>; oauth@ietf.org > *Subject:* Re: [OAUTH-WG] Shepherd write-up for > draft-ietf-oauth-resource-indicators-01 > > > > All, > > > > This coming Monday, Jan 28 @ 12:00pm Eastern Time, we have a scheduled > OAuth WG Virtual Office meeting. > > Feel free to attend the meeting to discuss this topic to try to get to a > conclusion on this. > > > > Regards, > > Rifaat > > > > > > On Wed, Jan 23, 2019 at 3:00 PM George Fletcher 40aol.com@dmarc.ietf.org> wrote: > > +1 > > Also, I don't really like the parameter name 'req_aud' :) I'm not 100% > convinced that 'audience' and 'logical resource' are completely overlappi= ng > concepts. We can potentially make them completely overlapping but we need > text to that effect. > > I also believe that we don't have a complete solution for all deployments > using exact locations (see my previous email). > > Thanks, > George > > On 1/23/19 2:50 PM, Vittorio Bertocci wrote: > > As mentioned below, I agree the two can be separated- but I also agree > with George on the need to be clear an easy to reference for developers. > > Just adding a reference to req_aud would just raise the cyclomatic > complexity of the specs, which is already unusably high for mere mortals = in > the OAuth2/OIDC family of specs. > > > > One additional complication is that this specification is reusing a > parameter that is already used in a *very* large number of production > systems (small example here > ), > and whose concrete semantic happens to be prevalently logic identifier. I= f > the parameter you are defining here has a different semantic, at the very > least it would seem good hygiene to rename it to avoid collision and > confusion. > > > > On Wed, Jan 23, 2019 at 11:03 AM Mike Jones 40microsoft.com@dmarc.ietf.org> wrote: > > I agree with John=E2=80=99s logic. The physical resource and logical res= ource > should use different identifiers. Fortunately, we already have =E2=80=9C= resource=E2=80=9D > and =E2=80=9Creq_aud=E2=80=9D for these parameters. I believe we=E2=80= =99re good to go, as-is. > > > > -- Mike > > > > *From:* OAuth *On Behalf Of *John Bradley > *Sent:* Wednesday, January 23, 2019 10:56 AM > *To:* oauth@ietf.org > *Subject:* Re: [OAUTH-WG] Shepherd write-up for > draft-ietf-oauth-resource-indicators-01 > > > > I don't think they are necessarily mutually exclusive, that is why I thin= k > there is value in allowing them to be specified separately. > > As an AS in the distributed OAuth case knowing that a client interacting > with RS https://fire.hhs.com as the resource wants a OAuth token with an > audience of HHS and a scope of read. > > Without proof of possession we need to keep bad RS from asking for tokens > with scopes and audiences of other RS that can be replayed. > > I really like keeping the resource simple and unspoofable, it is the URI > of the RS where you are presenting the AT. > > I prefer to keep that separate from the logical resource that may span > more than one RS endpoint. > > Merging the two and we are probably back at the AS looking into the URI t= o > figure out which one it is. I think that is harder for implementations a= nd > more likely to have security issues down the road. > > John B. > > On 1/23/2019 1:44 PM, Vittorio Bertocci wrote: > > Hi all, > > thanks for you patience. Brian and myself iterated on modifying the text > to cover the logical identifier use case, highlighting the security > implications of going that route. You can find the revised text in > https://github.com/vibronet/i-d/blob/master/draft-ietf-oauth-resource-ind= icators.xml, > see the commits in the history from January 21 for the specific changes. > > Note: I also had a chat with John offline, and he expressed the desire to > split the resource parameter in two distinct parameters to better signal > the intended usage. I am sure he can elaborate. I have nothing against it > in principle, as long as we leave nothing as exercise to the reader and w= e > are very clear on usage (e.g. mutual exclusivity, etc) but didn't have a > chance to speak w Brian about it. If the discussion stretches further, I > would suggest we pause it and let him enjoy his time off for the rest of > the week. > > > > On Mon, Jan 21, 2019 at 5:35 PM Rifaat Shekh-Yusef > wrote: > > Thank you guys! > > > > On Monday, January 21, 2019, Vittorio Bertocci wrote= : > > Hi Rifaat, > > absolutely. Brian and myself already started working on some language, > however this week he is in vacation hence it might take few days before w= e > come back to the list with something. > > Cheers, > > V. > > > > On Mon, Jan 21, 2019 at 9:35 AM Rifaat Shekh-Yusef > wrote: > > Brian, Vittorio, > > > > To move this discussion forward, can you guys suggest some text to make > the logical identifier usage clearer? > > > > Regards, > > Rifaat > > > > > > On Mon, Jan 21, 2019 at 10:32 AM Brian Campbell 40pingidentity.com@dmarc.ietf..org <40pingidentity.com@dmarc.ietf.org>> > wrote: > > As I suggested before, I do think that's within the bounds of the draft's > definition of 'resource' as a URI. And that perhaps all that's needed is > some minor adjustment and/or augmentation of some text to make it more > clear. > > > > On Sun, Jan 20, 2019 at 7:39 PM Vittorio Bertocci > wrote: > > [sent to John only by mistake, resending to the ML] > > > > In Azure AD v1 & ADFS, that's resource.. It could be used for both > network and logical ids, with the concrete usage in the wild I described > earlier. > > In Azure AD v2, the resource as explicit parameter (network, logic or > otherwise) is gone and is expressed as part of the scope string of all th= e > scopes requested for a given resource- but it still exist in practice tho > as it still end up in the resulting aud of the issued token. > > This is 9 months old info hence > > > > On Sun, Jan 20, 2019 at 17:58 John Bradley wrote: > > What is the parameter that Microsoft is using? > > On 1/20/2019 3:59 PM, Vittorio Bertocci wrote: > > First of all, it wasn't my intent to disrupt the established process. In > my former position I wasn't monitoring those discussions hence I didn't > have a chance to offer feedback. When I saw something that gave me the > impression might lead to issues, and given that I worked with actual > deployments and developers using a similar parameter for a long time, I > thought prudent to bring this up. I really appreciate Rifaat's stance on > this. End of preamble. > > > > Ultimately my goal is for developers to have guidance on how to work with > the concept of logical resource in a standard compliant way, hence it > doesn't strictly matter whether the definition of the corresponding > parameter lives in oauth-resource-indicators or elsewhere. > > That said. Reading through the draft, it would appear that most of the > reasons for which the spec was created apply to both the network > addressable and the logical resource types: knowing what keys to use to > encrypt the token, constrain access tokens to the intended audience, > avoiding overloading scopes with resource indicating parts... those all > apply to network addressable and logic identifiers alike. And both > parameters are expected to result in audience restricted tokens. It seems > the only difference comes at token usage time, with the network addressab= le > case giving more guarantees that the token will go to its intended > recipient, but the request and audience restriction syntax seems to be > exactly the same. > > On top of this: in the 99.999% of the scenarios I encountered in the wild > in the last 5 years of using the resource parameter in the MS ecosystem, > the resource identifier was known at design time: the developer discovere= d > it out of band and placed it in the app config at deployment time. Those > aren't fringe cases I occasionally encountered: the resource parameter in > Azure AD v1 and ADFS was mandatory, hence literally every solution i saw = or > touched used it. As Brian suggested, this is a scenario where the securit= y > advantages of the network addressable case aren't as pronounced as in the > case in which the client discovers the resource identifier at runtime. Th= is > isn't just because there is no specification suggesting location should b= e > explicitly indicated, it's because there are many practical advantages at > development and deployment time to be able to use logical identifiers- an= d > if the *concrete *security advantages don't apply to the their case, > people will simply not comply. > > > > In summary: creating two different parameters in two different documents > is better than ignoring he logical identifier case altogether, however I > think that not acknowledging the logical id case > in oauth-resource-indicators is going to create confusion and ultimately > not be as useful to the developer community as it could be. > > > > > > > > On Sat, Jan 19, 2019 at 12:38 Phil Hunt wrote: > > +1 to Mike and John=E2=80=99s comments. > > Phil > > > On Jan 19, 2019, at 12:34 PM, Mike Jones < > Michael.Jones=3D40microsoft.com@dmarc.ietf.org> wrote: > > I also agree that =E2=80=9Cresource=E2=80=9D should be a specific network= -addressable URL > whereas a separate audience parameter (like =E2=80=9Caud=E2=80=9D in JWTs= ) can refer to one > or more logical resources. They are different, if related, things. > > > > Note that the ACE WG is proposing to register a logical audience paramete= r > =E2=80=9Creq_aud=E2=80=9D in https://tools.ietf.org/html/draft-ietf-ace-o= auth-params-01 - > partly based on feedback from OAuth WG members. This is a general OAuth > parameter, which any OAuth deployment will be able to use. > > > > I therefore believe that no changes are needed to > draft-ietf-oauth-resource-indicators, as the logical audience work is > already happening in another draft. > > > > -- Mike > > > > *From:* OAuth *On Behalf Of *John Bradley > *Sent:* Saturday, January 19, 2019 9:01 AM > *To:* Brian Campbell > *Cc:* Vittorio Bertocci ; IETF oau= th > WG > *Subject:* Re: [OAUTH-WG] Shepherd write-up for > draft-ietf-oauth-resource-indicators-01 > > > > We need to decide if we want to make a change. > > > > For security we are location centric. > > > > I prefer to keep resource location separate from logical audience that ca= n > be a scope or other parameter. > > > > If becomes harder for people to use the parameter correctly if we are too > flexible. > > > > I would rather have a separate logical audience parameter if we think we > want one. > > > > John B. > > > > On Sat, Jan 19, 2019, 11:41 AM Brian Campbell wrote: > > No apology needed, Rifaat. And I apologize if what I said came off the > wrong way. I was just trying to make light of the situation.. And I agree > that we should not be hamstrung by the process and there are times when i= t > makes sense to be flexible with things. > > > > On Fri, Jan 18, 2019 at 6:22 PM Rifaat Shekh-Yusef > wrote: > > Sorry Brian, I was not clear with my statement. > > I meant to say that we should not allow the process to prevent the WG fro= m > producing a quality document without issues, assuming there is an issue i= n > the first place. > > Ideally we want to get these identified during the WGLC, but things happe= n > and sometimes the WG misses something. > > > > I hear you and agree that this make things difficult for authors. We will > make sure that this does not become the norm, and we will try to stick to > the process as much as possible. > > > > Regards, > > Rifaat > > > > > > On Fri, Jan 18, 2019 at 5:35 PM Brian Campbell > wrote: > > Thanks Rifaat. Process is as process does, right? I do kinda want to > grumble about WGCL having passed already but that's mostly because replyi= ng > to these kinds of threads is hard for me and I'll just get over it... > > > > As far as I understand things, the security concerns come into play when > the client is being told the by the resource how to identity the resource > like is described in > https://tools.ietf.org/html/draft-ietf-oauth-distributed-01 and using the > actual location in that context ,along with some other checks prescribed = in > that draft, prevents the kind of issues John described earlier in the > thread. > > In cases where the client knows the resource a priori or out-of-band or > configured or whatever, I don't think the same security concerns arise. A= nd > using such a known value, be it an actual location or logical > representation, would be okay. > > The resource-indicators draft is admittedly somewhat location-centric in > how it talks about the value of the 'resource' parameter. But ultimately = it > defines it as an absolute URI that indicates the location of the target > service or resource where access is being requested. A location can be > varying shades of abstract and I'd say that using a URI as 'resource' > parameter value that's a logical identifier that points to some resource = is > well within the bounds of the draft. > > > > So maybe the draft is okay as is? > > > > Or perhaps that's too much to be left as an exerciser to the reader? And > some text should be added and/or adjusted so the resource-indicators draf= t > would be a little more open/clear about the parameter value potentially > being more of a logical or abstract identifier and not necessarily a > network addressable URL? > > > > > > > > On Fri, Jan 18, 2019 at 1:18 PM Rifaat Shekh-Yusef > wrote: > > I wouldn't worry too much about the process. > > If it makes sense to update the document, then feel free to do that. > > > > Regards, > > Rifaat > > > > > > On Fri, Jan 18, 2019 at 3:08 PM John Bradley wrote: > > Yes the logical resource can be provided by "scope" > > > > Some implementations like Ping and Auth0 have been adding another > parameter "aud" to identify the logical resource and then using scopes to > define permissions to the resource. > > > > Fortunately, we are using a different parameter name so not stepping on > that.. > > > > We could go back and try to add text explaining the difference, but we ar= e > quite late in the process. > > > > I agree that a logical resource parameter may be helpful, but perhaps it > should be a separate draft. > > > > John B. > > > > On Fri, Jan 18, 2019 at 4:38 PM Richard Backman, Annabelle < > richanna@amazon.com> wrote: > > Doesn=E2=80=99t the =E2=80=9Cscope=E2=80=9D parameter already provide a m= eans of specifying a > logical identifier? > > > > -- > > Annabelle Richard Backman > > AWS Identity > > > > > > *From: *OAuth on behalf of Vittorio Bertocci > > > *Date: *Friday, January 18, 2019 at 5:47 AM > *To: *John Bradley > *Cc: *IETF oauth WG > *Subject: *Re: [OAUTH-WG] Shepherd write-up for > draft-ietf-oauth-resource-indicators-01 > > > > Thanks John for the background. > > I agree that from the client validation PoV, having an identifier > corresponding to a location makes things more solid. > > That said: the use of logical identifiers is widespread, as it has > significant practical advantages (think of services that assign generated > hosting URLs only at deployment time, or services that are somehow groupe= d > under the same logical audience across regions/environment/deployments). > People won't stop using logical identifiers, because they often have no > alternative (generating new audiences on the fly at the AS every time you > do a deployment and get assigned a new URL can be unfeasible). Leaving a > widely used approach as exercise to the reader seems a disservice to the > community, given that this might lead to vendors (for example Microsoft a= nd > Auth0) keeping their own proprietary parameters, or developers misusing t= he > ones in place; would make it hard for SDK developers to provide libraries > that work out of the box with different ASes; and so on. > > Would it be feasible to add such parameter directly in this spec? That > would eliminate the interop issues, and also gives us a chance to fully > warn people about the security shortcomings of choosing that approach. > > > > > > > > On Thu, Jan 17, 2019 at 4:32 PM John Bradley wrote: > > We have discussed this. > > Audiences can certainly be logical identifiers. > > This however is a more specific location. The AS is free to map the > location into some abstract audience in the AT. > > From a security point of view once the client starts asking for logical > resources it can be tricked into asking for the wrong one as a bad resour= ce > can always lie about what logical resource it is. > > If we were to change it, how a client would validate it becomes > challenging to impossible. > > The AS is free to do whatever mapping of locations to identifiers it need= s > for access tokens. > > Some implementations may want to keep additional parameters like logical > audience, but that should be separate from resource. > > John B. > > On 1/17/2019 9:56 AM, Rifaat Shekh-Yusef wrote: > > Hi Vittorio, > > > > The text you quoted is copied form the abstract of the draft itself. > > > > > > *Authors,* > > > > Should the draft be updated to cover the logical identifier case? > > > > Regards, > > Rifaat > > > > > > On Thu, Jan 17, 2019 at 8:19 AM Vittorio Bertocci > wrote: > > Hi Rifaat, > > one detail. The tech summary says > > > > An extension to the OAuth 2.0 Authorization Framework defining request > > parameters that enable a client to explicitly signal to an authorization = server > > about the *location* of the protected resource(s) to which it is requesti= ng > > access. > > But at least in the Microsoft implementation, the resource identifier > doesn't *have* to be a network addressable URL (and if it is, it doesn't > strictly need to match the actual resource location). It can be a logical > identifier, tho using the actual resource location there has benefits > (domain ownership check, prevention of token forwarding etc). > > Same for Auth0, the audience parameter is a logical identifier rather tha= n > a location. > > > > > > > > On Wed, Jan 16, 2019 at 6:32 PM Rifaat Shekh-Yusef > wrote: > > All, > > > > The following is the first shepherd write-up for > the draft-ietf-oauth-resource-indicators-01 document. > > > https://datatracker.ietf.org/doc/draft-ietf-oauth-resource-indicators/she= pherdwriteup/ > > > > Please, take a look and let me know if I missed anything. > > > > Regards, > > Rifaat > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf..org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited. > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you.* > > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited.= . > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you.* > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly > prohibited... If you have received this communication in error, please > notify the sender immediately by e-mail and delete the message and any fi= le > attachments from your computer. Thank you.* > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf..org/mailman/listinfo/oauth > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited.= . > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you.* > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --000000000000e5896805808ae2c6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
[added ace@ietf.org kinda per suggestion from Mike]<= br>
I don't know that there are concerns about =E2=80=9Creq_aud=E2= =80=9D per se.=C2=A0 Admittedly, I did use the word "concerns" bu= t I was more trying to say that referencing it from the draft-ietf-oauth-re= source-indicators document wasn't needed to address Vittorio's requ= est. And pointing out that =E2=80=9Creq_aud=E2=80=9D=C2=A0 is defined for t= he token endpoint while the draft-ietf-oauth-resource-indicators document a= lso deals with the authorization endpoint so such a reference wouldn't = really work anyway.

I don't k= now of anyone that just works from the OAuth parameter registration but may= be I'm just out of touch. And I don't think its a stretch at all to= observe that ACE OAuth and OAuth 2 are different.



On Mon, Jan= 28, 2019 at 11:28 AM Mike Jones <Michael.Jones@microsoft.com> wrote:

Brian, etc.=C2=A0= If you have concerns about =E2=80=9Creq_aud=E2=80=9D, now=E2=80=99s the ti= me to provide that feedback to the ACE WG, as they=E2=80=99re trying to com= plete that draft soon.=C2=A0 Please join the ACE WG mailing list and send y= our feedback there directly.

=C2=A0<= /u>

You and I may kno= w that ACE OAuth and OAuth 2 are pretty different but developers later will= just see the OAuth parameter registration and won=E2=80=99t realize that i= t=E2=80=99s coming from a different universe.=C2=A0 If we can harmonize things now, we should.

=C2=A0<= /u>

=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 -- Mike

=C2=A0<= /u>

From:= OAuth <oauth-bounces@ietf.org> On Behalf Of George Fletcher
Sent: Monday, January 28, 2019 10:05 AM
To: Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org= >
Cc: oauth@ietf.o= rg; Vittorio Bertocci <vittorio.bertocci@auth0.com>
Subject: Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resou= rce-indicators-01

=C2=A0

+1

I came to a similar conclusion over the weekend. If https://api.example.com/mail is an allowed location URI, how is it not = also a logical location considering it's possible there are multiple en= dpoints "below" https://api.example.com/mail? (e.g. https://api.example.com/mail/user/mail= box). Also if https://api.example.com is really a load balancer that fronts= the "real" endpoints, then it's also "logical"= in that context and not an exact location.

This brings me to the conclusion that all the resource identifiers are &quo= t;logical" along a range of specificity. How specific a resource is id= entified is really a risk decision and based on the deployment model can be= managed at either the RS or the AS.

Thanks,
George

On 1/28/19 9:07 AM, Brian Campbell wrote:<= /u>

I plan on joining the meeting today at noon eastern = time to discuses this little ditty. I hope others who have a stake in it ca= n too.

=C2=A0

The proposed changes that Vittorio and I put togethe= r can be seen in the diff of this pull request https://github.com/ietf-oauth-resource-indicators/i-d/pull/1/files and = I even put a xml2rfc'ed text version on https://github.com/ietf-oauth-resource-indicators/i-d/pull/1 for ease o= f reference. I maintain that is the most straightforward way forward with a= ll this. Yet another new additional parameter could be defined for the logi= cal case but I struggle to see the value in doing so. The 'resource' is URI that points to the resour= ce. The level of specificity of that pointer is intentionally a bit fuzzy a= nd application/deployment specific. Is https://graph.mic= rosoft.com (mentioned in the documentation previously linked) a locatio= n or an abstract identifier or both? The document already (somewhat awkward= ly) describes using a "base URI" for the application or resource. Is that a a location or an abstract identifier? Or kinda both= ?

=C2=A0

In addition to the concerns others have expressed ab= out "req_aud", I"d note that draft-ietf-ace-oauth-params def= ines its use only at the token endpoint as one of the "additional para= meters for requesting an access token from a token endpoint in the ACE framework". Whereas the resource-indicators draft scope in= cludes the authorization endpoint too. Furthermore, while the ACE WG is bui= lding on OAuth, for all intents and purposes ACE and regular OAuth are diff= erent worlds and I think a reference in regular OAuth document like this one to "Additional OAuth Paramete= rs for Authorization in Constrained Environments (ACE)" would be a dis= service to just about everyone.

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

On Thu, Jan 24, 2019 at 5:13 PM Rifaat Shekh-Yusef &= lt;rifaat.ietf@= gmail.com> wrote:

Hannes sent an update to this meeting here: <= u>

=C2=A0

Regards,

=C2=A0Rifaat

=C2=A0

=C2=A0

On Thu, Jan 24, 2019 at 6:20 PM Mike Jones <Michael.Jones@m= icrosoft.com> wrote:

The virtual offic= e hours in my calendar start 1/2 hour before that.=C2=A0 If the time has ch= anged, can you have the meeting organizer update the calendar entry?

=C2=A0<= /u>

=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 Thanks,

=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 -- Mike

=C2=A0<= /u>

From: Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>
Sent: Thursday, January 24, 2019 12:46 PM
To: George Fletcher <gffletch@aol.com>
Cc: Vittorio Bertocci <Vittorio@auth0.com>; Mike Jones <Michael.Jones@microsoft.com<= /a>>; oauth@ietf.org
Subject: Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resou= rce-indicators-01

=C2=A0

All,

=C2=A0

This coming Monday, Jan 28 @ 12:00pm Eastern Time, we have a scheduled= OAuth WG Virtual Office meeting.

Feel free to attend the meeting to discuss this topic to try to get to= a conclusion on this.

=C2=A0

Regards,

=C2=A0Rifaat

=C2=A0

=C2=A0

On Wed, Jan 23, 2019 at 3:00 PM George Fletcher <= gffletch=3D40= aol.com@dmarc.ietf.org> wrote:

+1

Also, I don't really like the parameter name 'req_aud' :) I'= ;m not 100% convinced that 'audience' and 'logical resource'= ; are completely overlapping concepts. We can potentially make them complet= ely overlapping but we need text to that effect.

I also believe that we don't have a complete solution for all deploymen= ts using exact locations (see my previous email).

Thanks,
George

On 1/23/19 2:50 PM, Vittorio Bertocci wrote:<= u>

As mentioned below, I agree the two can be separated= - but I also agree with George on the need to be clear an easy to reference= for developers.

Just adding a reference to req_aud would just raise = the cyclomatic complexity of the specs, which is already unusably high for = mere mortals in the OAuth2/OIDC family of specs.

=C2=A0

One additional complication is that this specificati= on is reusing a parameter that is already used in a very large number of production systems (small example here), and whose concrete semantic happens to be prevalently logic iden= tifier. If the parameter you are defining here has a different semantic, at= the very least it would seem good hygiene to rename it to avoid collision = and confusion.

=C2=A0

On Wed, Jan 23, 2019 at 11:03 AM Mike Jones <Mich= ael.Jones=3D40microsoft.com@dmarc.ietf.org> wrote:

I agree with John= =E2=80=99s logic.=C2=A0 The physical resource and logical resource should u= se different identifiers.=C2=A0 Fortunately, we already have =E2=80=9Cresou= rce=E2=80=9D and =E2=80=9Creq_aud=E2=80=9D for these parameters.=C2=A0 I believe we=E2=80= =99re good to go, as-is.

=C2=A0<= /u>

=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 -- Mike

=C2=A0<= /u>

From: OAuth <oauth-bounces@ietf.org> On Behalf Of John Bradley
Sent: Wednesday, January 23, 2019 10:56 AM
To: oauth@ietf.o= rg
Subject: Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resou= rce-indicators-01

=C2=A0

I don't think they are necessarily mutually exclusive, that is why I= think there is value in allowing them to be specified separately.

As an AS in the distributed OAuth case knowing that a client interacting= with RS https://fire.hhs.com= as the resource wants a OAuth token with an audience of HHS and a scope of= read.

Without proof of possession we need to keep bad RS from asking for token= s with scopes and audiences of other RS that can be replayed.=

I really like keeping the resource simple and unspoofable, it is the URI= of the RS where you are presenting the AT.

I prefer to keep that separate from the logical resource that may span m= ore than one RS endpoint.

Merging the two and we are probably back at the AS looking into the URI = to figure out which one it is.=C2=A0 I think that is harder for implementat= ions and more likely to have security issues down the road.

John B.

On 1/23/2019 1:44 PM, Vittorio Bertocci wrote:

Hi all,

thanks for you patience. Brian and myself iterated o= n modifying the text to cover the logical identifier use case, highlighting= the security implications of going that route. You can find the revised text in=C2=A0= https://github.com/vibronet/i-d/blob/master/draft-ietf-oauth-resource-indic= ators.xml, see the commits in the history from January 21 for the specific changes.

Note: I also had a chat with John offline, and he ex= pressed the desire to split the resource parameter in two distinct paramete= rs to better signal the intended usage. I am sure he can elaborate. I have nothing against it in principle, as long as we le= ave nothing as exercise to the reader and we are very clear on usage (e.g. = mutual exclusivity, etc) but didn't have a chance to speak w Brian abou= t it. If the discussion stretches further, I would suggest we pause it and let him enjoy his time off for the rest of= the week.

=C2=A0

On Mon, Jan 21, 2019 at 5:35 PM Rifaat Shekh-Yusef &= lt;rifaat.ietf@g= mail.com> wrote:

Thank you guys!



On Monday, January 21, 2019, Vittorio Bertocci <Vittorio@auth0.com> wrote:=

Hi Rifaat,

absolutely. Brian and myself already started working= on some language, however this week he is in vacation hence it might take = few days before we come back to the list with something.

Cheers,

V.

=C2=A0

On Mon, Jan 21, 2019 at 9:35 AM Rifaat Shekh-Yusef &= lt;rifaat.ietf@g= mail.com> wrote:

Brian, Vittorio,

=C2=A0

To move this discussion forward, can you guys sugges= t some text to make the logical identifier usage clearer?

=C2=A0

Regards,

=C2=A0Rifaat

=C2=A0

=C2=A0

On Mon, Jan 21, 2019 at 10:32 AM Brian Campbell <= bcampbell=3D40pingidentity.com@dmarc.ietf..org> wrote:

As I suggested before, I do think that's within = the bounds of the draft's definition of 'resource' as a URI. An= d that perhaps all that's needed is some minor adjustment and/or augmen= tation of some text to make it more clear.

=C2=A0

On Sun, Jan 20, 2019 at 7:39 PM Vittorio Bertocci &l= t;Vittorio@auth0.co= m> wrote:

[sent to John only by mistake, r= esending to the ML]

=C2=A0

In Azure AD v1 & ADFS, that&= #39;s=C2=A0resource.. It could be used for both network and logical ids, with the concrete usage in the w= ild I described earlier.

In Azure AD v2, = the resource as explicit parameter (network, logic or otherwise) is gone an= d is expressed as part of the scope string of all the scopes requested for a given resource- but it still exist in practice tho as it s= till end up in the resulting=C2=A0aud=C2=A0of the issued token.

This is 9 months= old info hence

=C2=A0

On Sun, Jan 20, 2019 at 17:58 John Bradley <ve7jtb@ve7jtb.com>= wrote:

What is the parameter that Microsoft is using?

On 1/20/2019 3:59 PM, Vittorio Bertocci wrote:

First of all, it wasn't my intent to disrupt the= established process. In my former position I wasn't monitoring those d= iscussions hence I didn't have a chance to offer feedback. When I saw something that gave me the impression might lead to issues, and= given that I worked with actual deployments and developers using a similar= parameter for a long time, I thought prudent to bring this up. I really ap= preciate Rifaat's stance on this. End of preamble.

=C2=A0

Ultimately my goal is for developers to have guidanc= e on how to work with the concept of logical resource in a standard complia= nt way, hence it doesn't strictly matter whether the definition of the corresponding parameter lives in=C2=A0oauth-resource-ind= icators or elsewhere.

That said. Reading through the draft, it would appea= r that most of the reasons for which the spec was created apply to both the= network addressable and the logical resource types: knowing what keys to use to encrypt the token, constrain access tokens to = the intended audience, avoiding overloading scopes with resource indicating= parts... those all apply to network addressable and logic identifiers alik= e. And both parameters are expected to result in audience restricted tokens. It seems the only difference come= s at token usage time, with the network addressable case giving more guaran= tees that the token will go to its intended recipient, but the request and = audience restriction syntax seems to be exactly the same.=C2=A0

On top of this: in the 99.999% of the scenarios I en= countered in the wild in the last 5 years of using the resource parameter i= n the MS ecosystem, the resource identifier was known at design time: the developer discovered it out of band and placed it in t= he app config at deployment time. Those aren't fringe cases I occasiona= lly encountered: the resource parameter in Azure AD v1 and ADFS was mandato= ry, hence literally every solution i saw or touched used it. As Brian suggested, this is a scenario where the s= ecurity advantages of the network addressable case aren't as pronounced= as in the case in which the client discovers the resource identifier at ru= ntime. This isn't just because there is no specification suggesting location should be explicitly indicated, it= 's because there are many practical advantages at development and deplo= yment time to be able to use logical identifiers- and if the concrete security advantages don't apply to the their case, peop= le will simply not comply.=C2=A0

=C2=A0

In summary: creating two different parameters in two= different documents is better than ignoring he logical identifier case alt= ogether, however I think that not acknowledging the logical id case in=C2=A0oauth-resource-indicators is going to create confu= sion and ultimately not be as useful to the developer community as it could= be.

=C2=A0

=C2=A0

=C2=A0

On Sat, Jan 19, 2019 at 12:38 Phil Hunt <phil.hunt@oracle.com= > wrote:

+1 to Mike and John=E2= =80=99s comments.=C2=A0

Phil


On Jan 19, 2019, at 12:34 PM, Mike Jones <Michael.Jones=3D40mic= rosoft.com@dmarc.ietf.org> wrote:

I also agree that= =E2=80=9Cresource=E2=80=9D should be a specific network-addressable URL wh= ereas a separate audience parameter (like =E2=80=9Caud=E2=80=9D in JWTs) ca= n refer to one or more logical resources.=C2=A0 They are different, if related, things.

=C2=A0<= /u>

Note that the ACE= WG is proposing to register a logical audience parameter =E2=80=9Creq_aud= =E2=80=9D in https://tools.ietf.org/html/draft-ietf-ace-oauth-params-01 - partly bas= ed on feedback from OAuth WG members.=C2=A0 This is a general OAuth paramet= er, which any OAuth deployment will be able to use.

=C2=A0<= /u>

I therefore belie= ve that no changes are needed to draft-ietf-oauth-resource-indicators, as t= he logical audience work is already happening in another draft.

=C2=A0<= /u>

=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 -- Mike

=C2=A0<= /u>

From: OAuth <oauth-bounces@ietf.org> On Behalf Of John Bradley
Sent: Saturday, January 19, 2019 9:01 AM
To: Brian Campbell <bcampbell@pingidentity.com>
Cc: Vittorio Bertocci <Vittorio=3D40auth0.com@dmarc.ietf.org&= gt;; IETF oauth WG <= oauth@ietf.org>
Subject: Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resou= rce-indicators-01

=C2=A0

We need to decide if we want to make a change.=C2=A0= =C2=A0

=C2=A0

For security we are location centric.=C2=A0=C2=A0=

=C2=A0

I prefer to keep resource location separate from log= ical audience that can be a scope or other parameter.=C2=A0=C2=A0=

=C2=A0

If becomes harder for people to use the parameter co= rrectly if we are too flexible.=C2=A0=C2=A0

=C2=A0

I would rather have a separate logical audience para= meter if we think we want one.=C2=A0=C2=A0

=C2=A0

John B.=C2=A0

=C2=A0

On Sat, Jan 19, 2019, 11:41 AM Brian Campbell <bcampbell@pin= gidentity.com wrote:

No apology needed, Rifaat. And I apologize if what I= said came off the wrong way. I was just trying to make light of the situat= ion.. And I agree that we should not be hamstrung by the process and there are times when it makes sense to be flexible with= things.

=C2=A0

On Fri, Jan 18, 2019 at 6:22 PM Rifaat Shekh-Yusef &= lt;rifaat.ietf@g= mail.com> wrote:

Sorry Brian, I was not clear with my statement.

I meant to say that we should not allow the process = to prevent the WG from producing a quality document without issues, assumin= g there is an issue in the first place.

Ideally we want to get these identified during the W= GLC, but things happen and sometimes the WG misses something.=C2=A0<= u>

=C2=A0

I hear you and agree that this make things difficult= for authors. We will make sure that this does not become the norm, and we = will try to stick to the process as much as possible.

=C2=A0

Regards,

=C2=A0Rifaat

=C2=A0

=C2=A0

On Fri, Jan 18, 2019 at 5:35 PM Brian Campbell <<= a href=3D"mailto:bcampbell@pingidentity.com" target=3D"_blank">bcampbell@pi= ngidentity.com> wrote:

Thanks Rifaat. Process is as process does, right? I = do kinda want to grumble about WGCL having passed already but that's mo= stly because replying to these kinds of threads is hard for me and I'll just get over it...

=C2=A0

As far as I understand things, the security concerns= come into play when the client is being told the by the resource how to id= entity the resource like is described in https://tools.ietf.org/html/draft-ietf-oauth-distributed-01 and using t= he actual location in that context ,along with some other checks prescribed= in that draft, prevents the kind of issues John described earlier in the t= hread.

In cases where the client knows the resource a priori or out-of-band or con= figured or whatever, I don't think the same security concerns arise. An= d using such a known value, be it an actual location or logical representat= ion, would be okay.

The resource-indicators draft is admittedly somewhat location-centric in ho= w it talks about the value of the 'resource' parameter. But ultimat= ely it defines it as an absolute URI that indicates the location of the tar= get service or resource where access is being requested. A location can be varying shades of abstract and I'd = say that using a URI as 'resource' parameter value that's a log= ical identifier that points to some resource is well within the bounds of t= he draft.

=C2=A0

So maybe the draft is okay as is?

=C2=A0

Or perhaps that's too much to be left as an exer= ciser to the reader?=C2=A0 And some text should be added and/or adjusted so= the resource-indicators draft would be a little more open/clear about the parameter value potentially being more of a logical or abstract = identifier and not necessarily a network addressable URL?

=C2=A0

=C2=A0

=C2=A0

On Fri, Jan 18, 2019 at 1:18 PM Rifaat Shekh-Yusef &= lt;rifaat.ietf@g= mail.com> wrote:

I wouldn't worry too much about the process.<= /u>

If it makes sense to update the document, then feel = free to do that.

=C2=A0

Regards,

=C2=A0Rifaat

=C2=A0

=C2=A0

On Fri, Jan 18, 2019 at 3:08 PM John Bradley <ve7jtb@ve7jtb.com&g= t; wrote:

Yes the=C2=A0logical resource can be provided by &qu= ot;scope"

=C2=A0

Some implementations like Ping and Auth0 have been a= dding another parameter "aud" to identify the logical resource an= d then using scopes to define permissions to the resource.

=C2=A0

Fortunately, we are using a different=C2=A0parameter= name so not stepping on that..

=C2=A0

We could go back and try to add text explaining the = difference, but we are quite late in the process.=C2=A0

=C2=A0

I agree that a logical resource parameter=C2=A0may b= e helpful, but perhaps it should be a separate draft.

=C2=A0

John B.

=C2=A0

On Fri, Jan 18, 2019 at 4:38 PM Richard Backman, Ann= abelle <richann= a@amazon.com> wrote:

Doesn=E2=80=99t the =E2=80=9Cscope=E2=80=9D paramete= r already provide a means of specifying a logical identifier?=

=C2=A0

--=C2=A0

Annabelle Richard Backman

AWS Identity

=C2=A0

=C2=A0

From: OAuth <oauth-bounces@ietf.org> on beha= lf of Vittorio Bertocci <Vittorio=3D40auth0.com@dmarc.ietf.org>
Date: Friday, January 18, 2019 at 5:47 AM
To: John Bradley <ve7jtb@ve7jtb.com>
Cc: IETF oauth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resou= rce-indicators-01

=C2=A0

Thanks John for the background.

I agree that from the client validation PoV, having = an identifier corresponding to a location makes things more solid.

That said: the use of logical identifiers is widespr= ead, as it has significant practical advantages (think of services that ass= ign generated hosting URLs only at deployment time, or services that are somehow grouped under the same logical audience acros= s regions/environment/deployments). People won't stop using logical ide= ntifiers, because they often have no alternative (generating new audiences = on the fly at the AS every time you do a deployment and get assigned a new URL can be unfeasible). Leaving a w= idely used approach as exercise to the reader seems a disservice to the com= munity, given that this might lead to vendors (for example Microsoft and Au= th0) keeping their own proprietary parameters, or developers misusing the ones in place; would make it hard f= or SDK developers to provide libraries that work out of the box with differ= ent ASes; and so on.

Would it be feasible to add such parameter directly = in this spec? That would eliminate the interop issues, and also gives us a = chance to fully warn people about the security shortcomings of choosing that approach.

=C2=A0

=C2=A0

=C2=A0

On Thu, Jan 17, 2019 at 4:32 PM John Bradley <ve7jtb@ve7jtb.com&g= t; wrote:

We have discussed this.

Audiences can certainly be logical identifiers.=C2=A0=C2=A0

This however is a more specific location.=C2=A0 The AS is free to map th= e location into some abstract audience in the AT.

From a security point of view once the client starts asking for logical = resources it can be tricked into asking for the wrong one as a bad resource= can always lie about what logical resource it is.

If we were to change it, how a client would validate it becomes challeng= ing to impossible.

The AS is free to do whatever mapping of locations to identifiers it nee= ds for access tokens.

Some implementations may want to keep additional parameters like logical= audience, but that should be separate from resource.

John B.

On 1/17/2019 9:56 AM, Rifaat Shekh-Yusef wrote:

Hi Vittorio,

=C2=A0

The text you quoted is copied form the abstract of t= he draft itself.

=C2=A0

=C2=A0

Authors,

=C2=A0

Should the draft be updated to cover the logical ide= ntifier case?

=C2=A0

Regards,

=C2=A0Rifaat

=C2=A0

=C2=A0

On Thu, Jan 17, 2019 at 8:19 AM Vittorio Bertocci &l= t;Vittorio@auth0.co= m> wrote:

Hi Rifaat,

one detail. The tech summary says

=C2=A0

An extension to the OAuth 2.0 Authorization Framework defi=
ning request 
parameters that enable a client to explicitly signal to an=
 authorization server 
about the location of the protected resource(s) to =
which it is requesting 
access.

But at least in the Microsoft implementation, the re= source identifier doesn't have to be a network addressable URL (and if it is, it doesn't s= trictly need to match the actual resource location). It can be a logical id= entifier, tho using the actual resource location there has benefits (domain= ownership check, prevention of token forwarding etc).

Same for Auth0, the audience parameter is a logical = identifier rather than a location.

=C2=A0

=C2=A0

=C2=A0

On Wed, Jan 16, 2019 at 6:32 PM Rifaat Shekh-Yusef &= lt;rifaat.ietf@g= mail.com> wrote:

All,

=C2=A0

The following is the first shepherd write-up for the= =C2=A0draft-ietf-oauth-resource-indicators-01 document.

=C2=A0

Please, take a look and let=C2=A0me know if I missed= anything.

=C2=A0

Regards,

=C2=A0Rifaat

=C2=A0

_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

=C2=A0 

_______________________________________________
OAuth mailing list
OAuth@ietf.org=

https://www.ietf..org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth


CONFIDENTIALITY NOTICE: This email may contain confidential and privi= leged material for the sole use of the intended recipient(s). Any review, u= se, distribution or disclosure by others is strictly prohibited.=C2=A0 If y= ou have received this communication in error, please notify the sender immediately by e-mail and delete the messa= ge and any file attachments from your computer. Thank you.


CONFIDENTIALITY NOTICE: This email may contain confidential and privi= leged material for the sole use of the intended recipient(s). Any review, u= se, distribution or disclosure by others is strictly prohibited..=C2=A0 If = you have received this communication in error, please notify the sender immediately by e-mail and delete the me= ssage and any file attachments from your computer. Thank you.

_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth


CO= NFIDENTIALITY NOTICE: This email may contain confidential and privileged ma= terial for the sole use of the intended recipient(s). Any review, use, dist= ribution or disclosure by others is strictly prohibited...=C2=A0 If you have received this communication in= error, please notify the sender immediately by e-mail and delete the messa= ge and any file attachments from your computer. Thank you.______= _________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

=C2=A0 

_______________________________________________
OAuth mailing list
OAuth@ietf.org=

https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

=C2=A0

_______________________________________________
OAuth mailing list
OAuth@ietf.org=

https://www.ietf..org/mailman/listinfo/oauth

=C2=A0

_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth


CO= NFIDENTIALITY NOTICE: This email may contain confidential and privileged ma= terial for the sole use of the intended recipient(s). Any review, use, dist= ribution or disclosure by others is strictly prohibited..=C2=A0 If you have received this communication in = error, please notify the sender immediately by e-mail and delete the messag= e and any file attachments from your computer. Thank you. 

_______________________________________________
OAuth mailing list
OAuth@ietf.org=

https://www.ietf.org/mailman/listinfo/oauth

=C2=A0


<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --000000000000e5896805808ae2c6-- From nobody Mon Jan 28 13:37:20 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C481131223 for ; Mon, 28 Jan 2019 13:37:13 -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 Ozkkmhx6TFCD for ; Mon, 28 Jan 2019 13:37: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 8F4E8131246 for ; Mon, 28 Jan 2019 13:37:09 -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; Mon, 28 Jan 2019 13:37:03 -0800 From: Jim Schaad To: "'Panos Kampanakis (pkampana)'" , References: <011501d4ac3d$ab2b9650$0182c2f0$@augustcellars.com> <82341b1eb21f4eccb00741d78964f853@XCH-ALN-010.cisco.com> In-Reply-To: <82341b1eb21f4eccb00741d78964f853@XCH-ALN-010.cisco.com> Date: Mon, 28 Jan 2019 13:36:58 -0800 Message-ID: <015e01d4b751$9b0d2170$d1276450$@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: AQF61PvzwzMWmD5ENcCTB9smhJ8GWwKQrXUGpmNcLHA= Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Ace] FW: WGLC comments draft-ietf-ace-coap-est-07 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2019 21:37:18 -0000 Clipping out things which are not issues: > -----Original Message----- > From: Ace On Behalf Of Panos Kampanakis > (pkampana) > Sent: Friday, January 18, 2019 12:59 PM > To: Jim Schaad ; ace@ietf.org > Subject: Re: [Ace] FW: WGLC comments draft-ietf-ace-coap-est-07 > > Hi Jim, > > Again, thank you for your thorough reviews. We addressed all of them. The > new version of the draft is at https://github.com/SanKumar2015/EST- > coaps/blob/master/draft-ietf-ace-coap-est.txt > > For a more easily consumable content, your latest feedback was tracked and > addressed here https://github.com/SanKumar2015/EST- > coaps/issues?utf8=%E2%9C%93&q=is%3Aissue+draft-ietf-ace-coap-est-07 > > I also lay out the changes below: > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > - About the persistent DTLS connections (Sect 7), the last two paragraphs of > section 7 explain why in some cases DTLS connections need to stay open for > a limited amount of time. They also point to the Section 11.1 about the > caveats of a persistent connection and the implicit DB. I do not think it is up to > this draft to tell the client that he should use the new cert after an > enrollment. The old cert might still be perfectly valid or the new cert may be > generated for a non DTLS client auth use. So, I don't think we need to state in > this draft that the new cert needs to be used in new DTLS connections. > > - About the DTLS connections (Sec 11.1), We have usecases where a client > does not want to spend the resources, time, performance implications to do > 3-5 DTLS connections back to back in order to update its trustanchor and do > its enrollments for multiple certs. In this cases, explained in section 7 last > paragraphs will keep a persistent DTLS connection. That is what section 11.1 is > trying to explain. Please keep in mind that in there we state that it is > RECOMMENDED for the client to start using the new explicit DB right after > the cacerts request. We just add the MAY keep the authenticated with > implicit DB DTLS connection open in some cases, but then he MUST use the > new DB starting for the next DTLS connection. > > So, I think our language in Sections 7 and 11.1 suffices when talking about > persistent TLS connections. Any time that the set of trust anchors is changed, you have also changed the set of things that you are going to trust. If you remove the trust anchor for the current connection, or restrict it in some manner, you may no longer have any trust in that connection. This is the worry that I have. I completely agree that doing multiple certificate requests (not sure why) or a query about the csr attributes followed by the certificate request is totally reasonable. You say that the client should use the new explicit trust anchors right after the cacerts request, but if you do not tear down the DTLS connection you are not doing that. You are still using the old implicit trust anchors. The MAY in section 11.1 for me is overridden by the previous SHOULD unless this case is specifically called out in section 7. I cannot understand the logic that says when you get a certificate a year from now the explicit TAs SHOULD be used, but it does not matter when you get the first certificate. * It does not look from the version on github that you made any changes for the examples: Examples: * Section A.1 I don't know what the meaning of Max-Age would be for a GET request. You may want to remove this just to avoid confusion. * Section A.2 - I am unclear about the Content-Format note in this example. If you are asking for a specific content then the correct option would be Accept. If you are indicating the content type of the response then you should probably put a header line in to that effect. In the virtual CoAP WG meeting last week we went through in some explicit detail that both Content-Format and Max-Age have no meaning when appearing on a request and therefore should not be there. From nobody Mon Jan 28 14:12:17 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE1E31311D6 for ; Mon, 28 Jan 2019 14:12:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.987 X-Spam-Level: X-Spam-Status: No, score=-1.987 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aol.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 MX4xLQ2svpOD for ; Mon, 28 Jan 2019 14:12:09 -0800 (PST) Received: from sonic312-21.consmr.mail.bf2.yahoo.com (sonic312-21.consmr.mail.bf2.yahoo.com [74.6.128.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA93A130EE5 for ; Mon, 28 Jan 2019 14:12:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1548713527; bh=vQvhLQcIXJWbVb6tvCRNuVIxiVGA5CbWUmTjOF7XG84=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject; b=qEydn8aeUC61culQ8rpQEhxISgg5+M6M0wbNe70o15Fl3JXYtFTSpIiJkgKODi6Qcg+GFMOZF7M/40IAtTiNExvh5s/lF8wT3nqzk0LYbPGqj2VCr7PEKrfkmXdamGhSWJyZEGRQOGgaRL+mFv3aXNW09IOe1Awx653qB/Q+C6jVSE8BGpJ4FQo1aMzxQKcikNQu+70UsBEJ3hATuS73A7TqHYiXsvPHbq2Ex7EFDj7FVbKNTXCJJI3Jyc+Vs+20PLTXTdMyXmtPSOdNklFeagSe1isRxEgQcrHYZsn/GdDgHoZLktBDHxwNjHQY42S0C8aKVS0XWRmc0jYytmJ/LA== X-YMail-OSG: BqN2C74VM1lcCVEnVsy19KhljNmH.3.BYOJPZFFX5BmUyg06wut0xY5rk9.lwU_ md.ssBgUWO3FyNhiUdekDNGzN40YznhnL7gFFxRhvV58DofFyUA3o4TekdcOyuSQQNLeYdapr1j8 pIRj3yoYPndT84h2elzMnRNrj9mG5.u4hJW5_GKM.gBdxerYNWXljd253j4QNll.6golHrJkBLcd AV7VfOHK2H2X3mN4jPQMbPd0cMYZ1ISxYZFpann51nd0T26eQUTJVxuaOHZIoos5rb8z7YOGTYE7 Zpftvg9OcfUgELgUBsxBV3bPEhfPOw3cjSTXPUaLjS6RBS98AcW5LoW_H042dyYeLPzDgbhbkHki uJOw4.T.yvfMoYwrVDimodCaxbLiIj9k3hAZ60j0V8ZZS2BfeZYeIzabGmE5gKnKjKC_BD.FiOk0 er7OFu.nSicTtDiJaCO4eD3BwBfn.pzyGB_yKn03bt.n5b5FlkHQN7CrJueHU1iEkn89WLCdhPws msVo_BHjQ9porWJKPM_3nSAzD2ZPOenod_AKtaC9SpZ2jtsB_a9f4kkus7xk3v8PPJC9XbGI1_dI NGV4fZ2FKmnUoS5a8oJdCm.oMrNjFrl4QWIbqGnkWG_CNGv_gJrjhkaCAsi5IbQddxmT_aQv5zh3 x9fih822WF8hIDmRQ1qxDChxXBIC_oYln99NG8s4szyaHjJq_AYCdJF2Gl5EF6uRXEbOsgceCubj kh8xowBB50VtdFTkBaEk2g64JsUv8G9nu.tVvWpeccg3uzXHVNJENSIGfr02h7.vNVKOrx7JZnS9 TiLub76A18xHMFUDpd8zO7ATQOkcKGGbSVyhGJBYQpyE786eVkXUP6iTbHCZQJSNe_THi6z_Y5RH QJolchPJjS7hLh.osMknmn6_wMqBnhgv2Shva.neREzGRrpzsHf_jBoR1zP.Ehv2a_YQEgVk0tkq trCPdU3Dx_taD5r2omzGwF8uigXteK.GQaV2Tc1AWlmO3M36.ubw7HwmtBD3UDVgHcYzS2Bd3the prek5OUwN1fTQEqyHrr3_LHGfRmP.Cz79hoS3.WheFryIGZF9NYk1jMkV5bKTF0Xp.w0PpW_nVA- - Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.bf2.yahoo.com with HTTP; Mon, 28 Jan 2019 22:12:07 +0000 Received: from nat-wireless-users3.cfw-a-gci.net.dulles.office.oath (EHLO [172.130.136.180]) ([184.165.3.238]) by smtp417.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID e30a89303b267a154ac0f0d07589e754; Mon, 28 Jan 2019 22:12:03 +0000 (UTC) To: Brian Campbell , Mike Jones , ace@ietf.org Cc: "oauth@ietf.org" , Vittorio Bertocci References: <4eb4ea45-c3f2-7991-9544-612d055809ba@ve7jtb.com> <199fa6bd-8103-b1b3-12a3-08b5e3aad925@aol.com> <55a0362e-e588-bce5-f65f-856a1e21e88e@aol.com> From: George Fletcher Organization: AOL LLC Message-ID: <65a8e83e-c72f-bbf5-77fd-ea8540b7ddc3@aol.com> Date: Mon, 28 Jan 2019 17:12:02 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------1CD0A9136094A3FD1F9AE843" Content-Language: en-US Archived-At: Subject: Re: [Ace] [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resource-indicators-01 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2019 22:12:16 -0000 This is a multi-part message in MIME format. --------------1CD0A9136094A3FD1F9AE843 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit I also don't know that this raises to the level of "concern" but I find the parameter name of "req_aud" odd. Given that the parameter in the resource-indicators spec is 'resource' why not use a parameter name of 'audience'. That said, I have not read the thread on the ACE working group list so there could be very good reasons for the chosen name:) I do think that there is a lot of overlap (in most cases) between 'resource' and 'audience' and having two parameters that cover a lot of the same semantics is going to be confusing for developers. When calling an API at a resource server, the 'audience' and the 'resource' are pretty equivalent. Maybe in other use cases they are distinctly separate? Thanks, George On 1/28/19 3:54 PM, Brian Campbell wrote: > [added ace@ietf.org kinda per suggestion from Mike] > > I don't know that there are concerns about “req_aud” per se.  > Admittedly, I did use the word "concerns" but I was more trying to say > that referencing it from the draft-ietf-oauth-resource-indicators > document wasn't needed to address Vittorio's request. And pointing out > that “req_aud”  is defined for the token endpoint while the > draft-ietf-oauth-resource-indicators document also deals with the > authorization endpoint so such a reference wouldn't really work anyway. > > I don't know of anyone that just works from the OAuth parameter > registration but maybe I'm just out of touch. And I don't think its a > stretch at all to observe that ACE OAuth and OAuth 2 are different. > > > > On Mon, Jan 28, 2019 at 11:28 AM Mike Jones > > wrote: > > Brian, etc.  If you have concerns about “req_aud”, now’s the time > to provide that feedback to the ACE WG, as they’re trying to > complete that draft soon.  Please join the ACE WG mailing list and > send your feedback there directly. > > You and I may know that ACE OAuth and OAuth 2 are pretty different > but developers later will just see the OAuth parameter > registration and won’t realize that it’s coming from a different > universe.  If we can harmonize things now, we should. > > -- Mike > > *From:*OAuth > *On Behalf Of *George Fletcher > *Sent:* Monday, January 28, 2019 10:05 AM > *To:* Brian Campbell > > *Cc:* oauth@ietf.org ; Vittorio Bertocci > > > *Subject:* Re: [OAUTH-WG] Shepherd write-up for > draft-ietf-oauth-resource-indicators-01 > > +1 > > I came to a similar conclusion over the weekend. If > https://api.example.com/mail is an > allowed location URI, how is it not also a logical location > considering it's possible there are multiple endpoints "below" > https://api.example.com/mail? (e.g. > https://api.example.com/mail/user/mailbox). Also if > https://api.example.com is really a load balancer that fronts the > " > real" > endpoints, then it's also "logical" in that context and not an > exact location. > > This brings me to the conclusion that all the resource identifiers > are "logical" along a range of specificity. How specific a > resource is identified is really a risk decision and based on the > deployment model can be managed at either the RS or the AS. > > Thanks, > George > > On 1/28/19 9:07 AM, Brian Campbell wrote: > > I plan on joining the meeting today at noon eastern time to > discuses this little ditty. I hope others who have a stake in > it can too. > > The proposed changes that Vittorio and I put together can be > seen in the diff of this pull request > https://github.com/ietf-oauth-resource-indicators/i-d/pull/1/files > and I even put a xml2rfc'ed text version on > https://github.com/ietf-oauth-resource-indicators/i-d/pull/1 > for ease of reference. I maintain that is the most > straightforward way forward with all this. Yet another new > additional parameter could be defined for the logical case but > I struggle to see the value in doing so. The 'resource' is URI > that points to the resource. The level of specificity of that > pointer is intentionally a bit fuzzy and > application/deployment specific. Is > https://graph.microsoft.com (mentioned in the documentation > previously linked) a location or an abstract identifier or > both? The document already (somewhat awkwardly) describes > using a "base URI" for the application or resource. Is that a > a location or an abstract identifier? Or kinda both? > > In addition to the concerns others have expressed about > "req_aud", I"d note that draft-ietf-ace-oauth-params defines > its use only at the token endpoint as one of the "additional > parameters for requesting an access token from a token > endpoint in the ACE framework". Whereas the > resource-indicators draft scope includes the authorization > endpoint too. Furthermore, while the ACE WG is building on > OAuth, for all intents and purposes ACE and regular OAuth are > different worlds and I think a reference in regular OAuth > document like this one to "Additional OAuth Parameters for > Authorization in Constrained Environments (ACE)" would be a > disservice to just about everyone. > > On Thu, Jan 24, 2019 at 5:13 PM Rifaat Shekh-Yusef > > wrote: > > Hannes sent an update to this meeting here: > > https://mailarchive.ietf.org/arch/msg/oauth/v8sUMEBGMC24AdWLewAymP-X4kU > > Regards, > >  Rifaat > > On Thu, Jan 24, 2019 at 6:20 PM Mike Jones > > wrote: > > The virtual office hours in my calendar start 1/2 hour > before that.  If the time has changed, can you have > the meeting organizer update the calendar entry? > > Thanks, > > -- Mike > > *From:* Rifaat Shekh-Yusef > > *Sent:* Thursday, January 24, 2019 12:46 PM > *To:* George Fletcher > > *Cc:* Vittorio Bertocci >; Mike Jones > >; oauth@ietf.org > > *Subject:* Re: [OAUTH-WG] Shepherd write-up for > draft-ietf-oauth-resource-indicators-01 > > All, > > This coming Monday, Jan 28 @ 12:00pm Eastern Time, we > have a scheduled OAuth WG Virtual Office meeting. > > Feel free to attend the meeting to discuss this topic > to try to get to a conclusion on this. > > Regards, > >  Rifaat > > On Wed, Jan 23, 2019 at 3:00 PM George Fletcher > > wrote: > > +1 > > Also, I don't really like the parameter name > 'req_aud' :) I'm not 100% convinced that > 'audience' and 'logical resource' are completely > overlapping concepts. We can potentially make them > completely overlapping but we need text to that > effect. > > I also believe that we don't have a complete > solution for all deployments using exact locations > (see my previous email). > > Thanks, > George > > On 1/23/19 2:50 PM, Vittorio Bertocci wrote: > > As mentioned below, I agree the two can be > separated- but I also agree with George on the > need to be clear an easy to reference for > developers. > > Just adding a reference to req_aud would just > raise the cyclomatic complexity of the specs, > which is already unusably high for mere > mortals in the OAuth2/OIDC family of specs. > > One additional complication is that this > specification is reusing a parameter that is > already used in a *very* large number of > production systems (small example here > ), > and whose concrete semantic happens to be > prevalently logic identifier. If the parameter > you are defining here has a different > semantic, at the very least it would seem good > hygiene to rename it to avoid collision and > confusion. > > On Wed, Jan 23, 2019 at 11:03 AM Mike Jones > > wrote: > > I agree with John’s logic.  The physical > resource and logical resource should use > different identifiers. Fortunately, we > already have “resource” and “req_aud” for > these parameters.  I believe we’re good to > go, as-is. > > -- Mike > > *From:* OAuth > *On > Behalf Of *John Bradley > *Sent:* Wednesday, January 23, 2019 10:56 AM > *To:* oauth@ietf.org > *Subject:* Re: [OAUTH-WG] Shepherd > write-up for > draft-ietf-oauth-resource-indicators-01 > > I don't think they are necessarily > mutually exclusive, that is why I think > there is value in allowing them to be > specified separately. > > As an AS in the distributed OAuth case > knowing that a client interacting with RS > https://fire.hhs.com as the resource wants > a OAuth token with an audience of HHS and > a scope of read. > > Without proof of possession we need to > keep bad RS from asking for tokens with > scopes and audiences of other RS that can > be replayed. > > I really like keeping the resource simple > and unspoofable, it is the URI of the RS > where you are presenting the AT. > > I prefer to keep that separate from the > logical resource that may span more than > one RS endpoint. > > Merging the two and we are probably back > at the AS looking into the URI to figure > out which one it is.  I think that is > harder for implementations and more likely > to have security issues down the road. > > John B. > > On 1/23/2019 1:44 PM, Vittorio Bertocci wrote: > > Hi all, > > thanks for you patience. Brian and > myself iterated on modifying the text > to cover the logical identifier use > case, highlighting the security > implications of going that route. You > can find the revised text in > https://github.com/vibronet/i-d/blob/master/draft-ietf-oauth-resource-indicators.xml, > see the commits in the history from > January 21 for the specific changes. > > Note: I also had a chat with John > offline, and he expressed the desire > to split the resource parameter in two > distinct parameters to better signal > the intended usage. I am sure he can > elaborate. I have nothing against it > in principle, as long as we leave > nothing as exercise to the reader and > we are very clear on usage (e.g. > mutual exclusivity, etc) but didn't > have a chance to speak w Brian about > it. If the discussion stretches > further, I would suggest we pause it > and let him enjoy his time off for the > rest of the week. > > On Mon, Jan 21, 2019 at 5:35 PM Rifaat > Shekh-Yusef > wrote: > > Thank you guys! > > > > On Monday, January 21, 2019, > Vittorio Bertocci > > wrote: > > Hi Rifaat, > > absolutely. Brian and myself > already started working on > some language, however this > week he is in vacation hence > it might take few days before > we come back to the list with > something. > > Cheers, > > V. > > On Mon, Jan 21, 2019 at 9:35 > AM Rifaat Shekh-Yusef > > > wrote: > > Brian, Vittorio, > > To move this discussion > forward, can you guys > suggest some text to make > the logical identifier > usage clearer? > > Regards, > >  Rifaat > > On Mon, Jan 21, 2019 at > 10:32 AM Brian Campbell > > > wrote: > > As I suggested before, > I do think that's > within the bounds of > the draft's definition > of 'resource' as a > URI. And that perhaps > all that's needed is > some minor adjustment > and/or augmentation of > some text to make it > more clear. > > On Sun, Jan 20, 2019 > at 7:39 PM Vittorio > Bertocci > > > wrote: > > [sent to John only > by mistake, > resending to the ML] > > In Azure AD v1 & > ADFS, that's > resource.. It > could be used for > both network and > logical ids, with > the concrete usage > in the wild I > described earlier. > > In Azure AD v2, > the resource as > explicit parameter > (network, logic or > otherwise) is gone > and is expressed > as part of the > scope string of > all the scopes > requested for a > given resource- > but it still exist > in practice tho as > it still end up in > the resulting > aud of the issued > token. > > This is 9 months > old info hence > > On Sun, Jan 20, > 2019 at 17:58 John > Bradley > > > wrote: > > What is the > parameter that > Microsoft is > using? > > On 1/20/2019 > 3:59 PM, > Vittorio > Bertocci wrote: > > First of > all, it > wasn't my > intent to > disrupt > the > established > process. > In my > former > position I > wasn't > monitoring > those > discussions > hence I > didn't > have a > chance to > offer > feedback. > When I saw > something > that gave > me the > impression > might lead > to issues, > and given > that I > worked > with > actual > deployments > and > developers > using a > similar > parameter > for a long > time, I > thought > prudent to > bring this > up. I > really > appreciate > Rifaat's > stance on > this. End > of preamble. > > Ultimately > my goal is > for > developers > to have > guidance > on how to > work with > the > concept of > logical > resource > in a > standard > compliant > way, hence > it doesn't > strictly > matter > whether > the > definition > of the > corresponding > parameter > lives > in oauth-resource-indicators > or elsewhere. > > That said. > Reading > through > the draft, > it would > appear > that most > of the > reasons > for which > the spec > was > created > apply to > both the > network > addressable > and the > logical > resource > types: > knowing > what keys > to use to > encrypt > the token, > constrain > access > tokens to > the > intended > audience, > avoiding > overloading > scopes > with > resource > indicating > parts... > those all > apply to > network > addressable > and logic > identifiers > alike. And > both > parameters > are > expected > to result > in > audience > restricted > tokens. It > seems the > only > difference > comes at > token > usage > time, with > the > network > addressable > case > giving > more > guarantees > that the > token will > go to its > intended > recipient, > but the > request > and > audience > restriction > syntax > seems to > be exactly > the same. > > On top of > this: in > the > 99.999% of > the > scenarios > I > encountered > in the > wild in > the last 5 > years of > using the > resource > parameter > in the MS > ecosystem, > the > resource > identifier > was known > at design > time: the > developer > discovered > it out of > band and > placed it > in the app > config at > deployment > time. > Those > aren't > fringe > cases I > occasionally > encountered: > the > resource > parameter > in Azure > AD v1 and > ADFS was > mandatory, > hence > literally > every > solution i > saw or > touched > used it. > As Brian > suggested, > this is a > scenario > where the > security > advantages > of the > network > addressable > case > aren't as > pronounced > as in the > case in > which the > client > discovers > the > resource > identifier > at > runtime. > This isn't > just > because > there is > no > specification > suggesting > location > should be > explicitly > indicated, > it's > because > there are > many > practical > advantages > at > development > and > deployment > time to be > able to > use > logical > identifiers- > and if the > /concrete > /security > advantages > don't > apply to > the their > case, > people > will > simply not > comply. > > In > summary: > creating > two > different > parameters > in two > different > documents > is better > than > ignoring > he logical > identifier > case > altogether, > however I > think that > not > acknowledging > the > logical id > case > in oauth-resource-indicators > is going > to create > confusion > and > ultimately > not be as > useful to > the > developer > community > as it > could be. > > On Sat, > Jan 19, > 2019 at > 12:38 Phil > Hunt > > > wrote: > > +1 to > Mike > and > John’s > comments. > > Phil > > > On Jan > 19, > 2019, > at > 12:34 > PM, > Mike > Jones > > > wrote: > > I > also > agree > that > “resource” > should > be > a > specific > network-addressable > URL > whereas > a > separate > audience > parameter > (like > “aud” > in > JWTs) > can > refer > to > one > or > more > logical > resources. > They > are > different, > if > related, > things. > > Note > that > the > ACE > WG > is > proposing > to > register > a > logical > audience > parameter > “req_aud” > in > https://tools.ietf.org/html/draft-ietf-ace-oauth-params-01 > - > partly > based > on > feedback > from > OAuth > WG > members.  > This > is > a > general > OAuth > parameter, > which > any > OAuth > deployment > will > be > able > to > use. > > I > therefore > believe > that > no > changes > are > needed > to > draft-ietf-oauth-resource-indicators, > as > the > logical > audience > work > is > already > happening > in > another > draft. > > -- > Mike > > *From:* > OAuth > > > *On > Behalf > Of > *John > Bradley > *Sent:* > Saturday, > January > 19, > 2019 > 9:01 > AM > *To:* > Brian > Campbell > > > *Cc:* > Vittorio > Bertocci > >; > IETF > oauth > WG > > > *Subject:* > Re: > [OAUTH-WG] > Shepherd > write-up > for > draft-ietf-oauth-resource-indicators-01 > > We > need > to > decide > if > we > want > to > make > a > change. > > > For > security > we > are > location > centric. > > > I > prefer > to > keep > resource > location > separate > from > logical > audience > that > can > be > a > scope > or > other > parameter. > > > If > becomes > harder > for > people > to > use > the > parameter > correctly > if > we > are > too > flexible. > > > I > would > rather > have > a > separate > logical > audience > parameter > if > we > think > we > want > one. > > John > B. > > On > Sat, > Jan > 19, > 2019, > 11:41 > AM > Brian > Campbell > > wrote: > > No > apology > needed, > Rifaat. > And > I > apologize > if > what > I > said > came > off > the > wrong > way. > I > was > just > trying > to > make > light > of > the > situation.. > And > I > agree > that > we > should > not > be > hamstrung > by > the > process > and > there > are > times > when > it > makes > sense > to > be > flexible > with > things. > > > On > Fri, > Jan > 18, > 2019 > at > 6:22 > PM > Rifaat > Shekh-Yusef > > > wrote: > > Sorry > Brian, > I > was > not > clear > with > my > statement. > > I > meant > to > say > that > we > should > not > allow > the > process > to > prevent > the > WG > from > producing > a > quality > document > without > issues, > assuming > there > is > an > issue > in > the > first > place. > > Ideally > we > want > to > get > these > identified > during > the > WGLC, > but > things > happen > and > sometimes > the > WG > misses > something. > > > I > hear > you > and > agree > that > this > make > things > difficult > for > authors. > We > will > make > sure > that > this > does > not > become > the > norm, > and > we > will > try > to > stick > to > the > process > as > much > as > possible. > > Regards, > >  Rifaat > > On > Fri, > Jan > 18, > 2019 > at > 5:35 > PM > Brian > Campbell > > > wrote: > > Thanks > Rifaat. > Process > is > as > process > does, > right? > I > do > kinda > want > to > grumble > about > WGCL > having > passed > already > but > that's > mostly > because > replying > to > these > kinds > of > threads > is > hard > for > me > and > I'll > just > get > over > it... > > > As > far > as > I > understand > things, > the > security > concerns > come > into > play > when > the > client > is > being > told > the > by > the > resource > how > to > identity > the > resource > like > is > described > in > https://tools.ietf.org/html/draft-ietf-oauth-distributed-01 > and > using > the > actual > location > in > that > context > ,along > with > some > other > checks > prescribed > in > that > draft, > prevents > the > kind > of > issues > John > described > earlier > in > the > thread. > > > In > cases > where > the > client > knows > the > resource > a > priori > or > out-of-band > or > configured > or > whatever, > I > don't > think > the > same > security > concerns > arise. > And > using > such > a > known > value, > be > it > an > actual > location > or > logical > representation, > would > be > okay. > > The > resource-indicators > draft > is > admittedly > somewhat > location-centric > in > how > it > talks > about > the > value > of > the > 'resource' > parameter. > But > ultimately > it > defines > it > as > an > absolute > URI > that > indicates > the > location > of > the > target > service > or > resource > where > access > is > being > requested. > A > location > can > be > varying > shades > of > abstract > and > I'd > say > that > using > a > URI > as > 'resource' > parameter > value > that's > a > logical > identifier > that > points > to > some > resource > is > well > within > the > bounds > of > the > draft. > > > So > maybe > the > draft > is > okay > as > is? > > Or > perhaps > that's > too > much > to > be > left > as > an > exerciser > to > the > reader? > And > some > text > should > be > added > and/or > adjusted > so > the > resource-indicators > draft > would > be > a > little > more > open/clear > about > the > parameter > value > potentially > being > more > of > a > logical > or > abstract > identifier > and > not > necessarily > a > network > addressable > URL? > > On > Fri, > Jan > 18, > 2019 > at > 1:18 > PM > Rifaat > Shekh-Yusef > > > wrote: > > I > wouldn't > worry > too > much > about > the > process. > > If > it > makes > sense > to > update > the > document, > then > feel > free > to > do > that. > > Regards, > >  Rifaat > > On > Fri, > Jan > 18, > 2019 > at > 3:08 > PM > John > Bradley > > > wrote: > > Yes > the logical > resource > can > be > provided > by > "scope" > > Some > implementations > like > Ping > and > Auth0 > have > been > adding > another > parameter > "aud" > to > identify > the > logical > resource > and > then > using > scopes > to > define > permissions > to > the > resource. > > Fortunately, > we > are > using > a > different parameter > name > so > not > stepping > on > that.. > > We > could > go > back > and > try > to > add > text > explaining > the > difference, > but > we > are > quite > late > in > the > process. > > > I > agree > that > a > logical > resource > parameter may > be > helpful, > but > perhaps > it > should > be > a > separate > draft. > > John > B. > > On > Fri, > Jan > 18, > 2019 > at > 4:38 > PM > Richard > Backman, > Annabelle > > > wrote: > > Doesn’t > the > “scope” > parameter > already > provide > a > means > of > specifying > a > logical > identifier? > > -- > > > Annabelle > Richard > Backman > > AWS > Identity > > *From: > *OAuth > > > on > behalf > of > Vittorio > Bertocci > > > *Date: > *Friday, > January > 18, > 2019 > at > 5:47 > AM > *To: > *John > Bradley > > > *Cc: > *IETF > oauth > WG > > > *Subject: > *Re: > [OAUTH-WG] > Shepherd > write-up > for > draft-ietf-oauth-resource-indicators-01 > > Thanks > John > for > the > background. > > > I > agree > that > from > the > client > validation > PoV, > having > an > identifier > corresponding > to > a > location > makes > things > more > solid. > > That > said: > the > use > of > logical > identifiers > is > widespread, > as > it > has > significant > practical > advantages > (think > of > services > that > assign > generated > hosting > URLs > only > at > deployment > time, > or > services > that > are > somehow > grouped > under > the > same > logical > audience > across > regions/environment/deployments). > People > won't > stop > using > logical > identifiers, > because > they > often > have > no > alternative > (generating > new > audiences > on > the > fly > at > the > AS > every > time > you > do > a > deployment > and > get > assigned > a > new > URL > can > be > unfeasible). > Leaving > a > widely > used > approach > as > exercise > to > the > reader > seems > a > disservice > to > the > community, > given > that > this > might > lead > to > vendors > (for > example > Microsoft > and > Auth0) > keeping > their > own > proprietary > parameters, > or > developers > misusing > the > ones > in > place; > would > make > it > hard > for > SDK > developers > to > provide > libraries > that > work > out > of > the > box > with > different > ASes; > and > so > on. > > Would > it > be > feasible > to > add > such > parameter > directly > in > this > spec? > That > would > eliminate > the > interop > issues, > and > also > gives > us > a > chance > to > fully > warn > people > about > the > security > shortcomings > of > choosing > that > approach. > > On > Thu, > Jan > 17, > 2019 > at > 4:32 > PM > John > Bradley > > > wrote: > > We > have > discussed > this. > > Audiences > can > certainly > be > logical > identifiers. > > > This > however > is > a > more > specific > location.  > The > AS > is > free > to > map > the > location > into > some > abstract > audience > in > the > AT. > > From > a > security > point > of > view > once > the > client > starts > asking > for > logical > resources > it > can > be > tricked > into > asking > for > the > wrong > one > as > a > bad > resource > can > always > lie > about > what > logical > resource > it > is. > > If > we > were > to > change > it, > how > a > client > would > validate > it > becomes > challenging > to > impossible. > > > The > AS > is > free > to > do > whatever > mapping > of > locations > to > identifiers > it > needs > for > access > tokens. > > Some > implementations > may > want > to > keep > additional > parameters > like > logical > audience, > but > that > should > be > separate > from > resource. > > John > B. > > On > 1/17/2019 > 9:56 > AM, > Rifaat > Shekh-Yusef > wrote: > > Hi > Vittorio, > > > The > text > you > quoted > is > copied > form > the > abstract > of > the > draft > itself. > > *Authors,* > > Should > the > draft > be > updated > to > cover > the > logical > identifier > case? > > Regards, > >  Rifaat > > On > Thu, > Jan > 17, > 2019 > at > 8:19 > AM > Vittorio > Bertocci > > > wrote: > > Hi > Rifaat, > > > one > detail. > The > tech > summary > says > > An > extension > to > the > OAuth > 2.0 > Authorization > Framework > defining > request > > > parameters > that > enable > a > client > to > explicitly > signal > to > an > authorization > server > > > about > the > *location* > of > the > protected > resource(s) > to > which > it > is > requesting > > > access. > > But > at > least > in > the > Microsoft > implementation, > the > resource > identifier > doesn't > /have/ > to > be > a > network > addressable > URL > (and > if > it > is, > it > doesn't > strictly > need > to > match > the > actual > resource > location). > It > can > be > a > logical > identifier, > tho > using > the > actual > resource > location > there > has > benefits > (domain > ownership > check, > prevention > of > token > forwarding > etc). > > Same > for > Auth0, > the > audience > parameter > is > a > logical > identifier > rather > than > a > location. > > On > Wed, > Jan > 16, > 2019 > at > 6:32 > PM > Rifaat > Shekh-Yusef > > > wrote: > > All, > > > The > following > is > the > first > shepherd > write-up > for > the draft-ietf-oauth-resource-indicators-01 > document. > > https://datatracker.ietf.org/doc/draft-ietf-oauth-resource-indicators/shepherdwriteup/ > > Please, > take > a > look > and > let me > know > if > I > missed > anything. > > Regards, > >  Rifaat > > _______________________________________________ > OAuth > mailing > list > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf..org/mailman/listinfo/oauth > > _______________________________________________ > OAuth > mailing > list > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth > mailing > list > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth > mailing > list > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > */CONFIDENTIALITY > NOTICE: > This > email > may > contain > confidential > and > privileged > material > for > the > sole > use > of > the > intended > recipient(s). > Any > review, > use, > distribution > or > disclosure > by > others > is > strictly > prohibited. > If > you > have > received > this > communication > in > error, > please > notify > the > sender > immediately > by > e-mail > and > delete > the > message > and > any > file > attachments > from > your > computer. > Thank > you./* > > > */CONFIDENTIALITY > NOTICE: > This > email > may > contain > confidential > and > privileged > material > for > the > sole > use > of > the > intended > recipient(s). > Any > review, > use, > distribution > or > disclosure > by > others > is > strictly > prohibited.. > If > you > have > received > this > communication > in > error, > please > notify > the > sender > immediately > by > e-mail > and > delete > the > message > and > any > file > attachments > from > your > computer. > Thank > you./* > > _______________________________________________ > OAuth > mailing > list > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > /CONFIDENTIALITY > NOTICE: This email may > contain confidential > and privileged > material for the sole > use of the intended > recipient(s). Any > review, use, > distribution or > disclosure by others > is strictly > prohibited... If you > have received this > communication in > error, please notify > the sender immediately > by e-mail and delete > the message and any > file attachments from > your computer. Thank > you./_______________________________________________ > OAuth mailing list > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf..org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > /CONFIDENTIALITY NOTICE: This email may contain confidential > and privileged material for the sole use of the intended > recipient(s). Any review, use, distribution or disclosure by > others is strictly prohibited..  If you have received this > communication in error, please notify the sender immediately > by e-mail and delete the message and any file attachments from > your computer. Thank you./ > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > /CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly > prohibited.  If you have received this communication in error, please > notify the sender immediately by e-mail and delete the message and any > file attachments from your computer. Thank you./ --------------1CD0A9136094A3FD1F9AE843 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit I also don't know that this raises to the level of "concern" but I find the parameter name of "req_aud" odd. Given that the parameter in the resource-indicators spec is 'resource' why not use a parameter name of 'audience'. That said, I have not read the thread on the ACE working group list so there could be very good reasons for the chosen name:)

I do think that there is a lot of overlap (in most cases) between 'resource' and 'audience' and having two parameters that cover a lot of the same semantics is going to be confusing for developers. When calling an API at a resource server, the 'audience' and the 'resource' are pretty equivalent. Maybe in other use cases they are distinctly separate?

Thanks,
George

On 1/28/19 3:54 PM, Brian Campbell wrote:
[added ace@ietf.org kinda per suggestion from Mike]

I don't know that there are concerns about “req_aud” per se.  Admittedly, I did use the word "concerns" but I was more trying to say that referencing it from the draft-ietf-oauth-resource-indicators document wasn't needed to address Vittorio's request. And pointing out that “req_aud”  is defined for the token endpoint while the draft-ietf-oauth-resource-indicators document also deals with the authorization endpoint so such a reference wouldn't really work anyway.

I don't know of anyone that just works from the OAuth parameter registration but maybe I'm just out of touch. And I don't think its a stretch at all to observe that ACE OAuth and OAuth 2 are different.



On Mon, Jan 28, 2019 at 11:28 AM Mike Jones <Michael.Jones@microsoft.com> wrote:

Brian, etc.  If you have concerns about “req_aud”, now’s the time to provide that feedback to the ACE WG, as they’re trying to complete that draft soon.  Please join the ACE WG mailing list and send your feedback there directly.

 

You and I may know that ACE OAuth and OAuth 2 are pretty different but developers later will just see the OAuth parameter registration and won’t realize that it’s coming from a different universe.  If we can harmonize things now, we should.

 

                                                          -- Mike

 

From: OAuth <oauth-bounces@ietf.org> On Behalf Of George Fletcher
Sent: Monday, January 28, 2019 10:05 AM
To: Brian Campbell <bcampbell=40pingidentity.com@dmarc.ietf.org>
Cc: oauth@ietf.org; Vittorio Bertocci <vittorio.bertocci@auth0.com>
Subject: Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resource-indicators-01

 

+1

I came to a similar conclusion over the weekend. If https://api.example.com/mail is an allowed location URI, how is it not also a logical location considering it's possible there are multiple endpoints "below" https://api.example.com/mail? (e.g. https://api.example.com/mail/user/mailbox). Also if https://api.example.com is really a load balancer that fronts the "real" endpoints, then it's also "logical" in that context and not an exact location.

This brings me to the conclusion that all the resource identifiers are "logical" along a range of specificity. How specific a resource is identified is really a risk decision and based on the deployment model can be managed at either the RS or the AS.

Thanks,
George

On 1/28/19 9:07 AM, Brian Campbell wrote:

I plan on joining the meeting today at noon eastern time to discuses this little ditty. I hope others who have a stake in it can too.

 

The proposed changes that Vittorio and I put together can be seen in the diff of this pull request https://github.com/ietf-oauth-resource-indicators/i-d/pull/1/files and I even put a xml2rfc'ed text version on https://github.com/ietf-oauth-resource-indicators/i-d/pull/1 for ease of reference. I maintain that is the most straightforward way forward with all this. Yet another new additional parameter could be defined for the logical case but I struggle to see the value in doing so. The 'resource' is URI that points to the resource. The level of specificity of that pointer is intentionally a bit fuzzy and application/deployment specific. Is https://graph.microsoft.com (mentioned in the documentation previously linked) a location or an abstract identifier or both? The document already (somewhat awkwardly) describes using a "base URI" for the application or resource. Is that a a location or an abstract identifier? Or kinda both?

 

In addition to the concerns others have expressed about "req_aud", I"d note that draft-ietf-ace-oauth-params defines its use only at the token endpoint as one of the "additional parameters for requesting an access token from a token endpoint in the ACE framework". Whereas the resource-indicators draft scope includes the authorization endpoint too. Furthermore, while the ACE WG is building on OAuth, for all intents and purposes ACE and regular OAuth are different worlds and I think a reference in regular OAuth document like this one to "Additional OAuth Parameters for Authorization in Constrained Environments (ACE)" would be a disservice to just about everyone.

 

 

 

 

 

 

On Thu, Jan 24, 2019 at 5:13 PM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:

Hannes sent an update to this meeting here:

 

Regards,

 Rifaat

 

 

On Thu, Jan 24, 2019 at 6:20 PM Mike Jones <Michael.Jones@microsoft.com> wrote:

The virtual office hours in my calendar start 1/2 hour before that.  If the time has changed, can you have the meeting organizer update the calendar entry?

 

                                                          Thanks,

                                                          -- Mike

 

From: Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>
Sent: Thursday, January 24, 2019 12:46 PM
To: George Fletcher <gffletch@aol.com>
Cc: Vittorio Bertocci <Vittorio@auth0.com>; Mike Jones <Michael.Jones@microsoft.com>; oauth@ietf.org
Subject: Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resource-indicators-01

 

All,

 

This coming Monday, Jan 28 @ 12:00pm Eastern Time, we have a scheduled OAuth WG Virtual Office meeting.

Feel free to attend the meeting to discuss this topic to try to get to a conclusion on this.

 

Regards,

 Rifaat

 

 

On Wed, Jan 23, 2019 at 3:00 PM George Fletcher <gffletch=40aol.com@dmarc.ietf.org> wrote:

+1

Also, I don't really like the parameter name 'req_aud' :) I'm not 100% convinced that 'audience' and 'logical resource' are completely overlapping concepts. We can potentially make them completely overlapping but we need text to that effect.

I also believe that we don't have a complete solution for all deployments using exact locations (see my previous email).

Thanks,
George

On 1/23/19 2:50 PM, Vittorio Bertocci wrote:

As mentioned below, I agree the two can be separated- but I also agree with George on the need to be clear an easy to reference for developers.

Just adding a reference to req_aud would just raise the cyclomatic complexity of the specs, which is already unusably high for mere mortals in the OAuth2/OIDC family of specs.

 

One additional complication is that this specification is reusing a parameter that is already used in a very large number of production systems (small example here), and whose concrete semantic happens to be prevalently logic identifier. If the parameter you are defining here has a different semantic, at the very least it would seem good hygiene to rename it to avoid collision and confusion.

 

On Wed, Jan 23, 2019 at 11:03 AM Mike Jones <Michael.Jones=40microsoft.com@dmarc.ietf.org> wrote:

I agree with John’s logic.  The physical resource and logical resource should use different identifiers.  Fortunately, we already have “resource” and “req_aud” for these parameters.  I believe we’re good to go, as-is.

 

                                                       -- Mike

 

From: OAuth <oauth-bounces@ietf.org> On Behalf Of John Bradley
Sent: Wednesday, January 23, 2019 10:56 AM
To: oauth@ietf.org
Subject: Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resource-indicators-01

 

I don't think they are necessarily mutually exclusive, that is why I think there is value in allowing them to be specified separately.

As an AS in the distributed OAuth case knowing that a client interacting with RS https://fire.hhs.com as the resource wants a OAuth token with an audience of HHS and a scope of read.

Without proof of possession we need to keep bad RS from asking for tokens with scopes and audiences of other RS that can be replayed.

I really like keeping the resource simple and unspoofable, it is the URI of the RS where you are presenting the AT.

I prefer to keep that separate from the logical resource that may span more than one RS endpoint.

Merging the two and we are probably back at the AS looking into the URI to figure out which one it is.  I think that is harder for implementations and more likely to have security issues down the road.

John B.

On 1/23/2019 1:44 PM, Vittorio Bertocci wrote:

Hi all,

thanks for you patience. Brian and myself iterated on modifying the text to cover the logical identifier use case, highlighting the security implications of going that route. You can find the revised text in https://github.com/vibronet/i-d/blob/master/draft-ietf-oauth-resource-indicators.xml, see the commits in the history from January 21 for the specific changes.

Note: I also had a chat with John offline, and he expressed the desire to split the resource parameter in two distinct parameters to better signal the intended usage. I am sure he can elaborate. I have nothing against it in principle, as long as we leave nothing as exercise to the reader and we are very clear on usage (e.g. mutual exclusivity, etc) but didn't have a chance to speak w Brian about it. If the discussion stretches further, I would suggest we pause it and let him enjoy his time off for the rest of the week.

 

On Mon, Jan 21, 2019 at 5:35 PM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:

Thank you guys!



On Monday, January 21, 2019, Vittorio Bertocci <Vittorio@auth0.com> wrote:

Hi Rifaat,

absolutely. Brian and myself already started working on some language, however this week he is in vacation hence it might take few days before we come back to the list with something.

Cheers,

V.

 

On Mon, Jan 21, 2019 at 9:35 AM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:

Brian, Vittorio,

 

To move this discussion forward, can you guys suggest some text to make the logical identifier usage clearer?

 

Regards,

 Rifaat

 

 

On Mon, Jan 21, 2019 at 10:32 AM Brian Campbell <bcampbell=40pingidentity.com@dmarc.ietf..org> wrote:

As I suggested before, I do think that's within the bounds of the draft's definition of 'resource' as a URI. And that perhaps all that's needed is some minor adjustment and/or augmentation of some text to make it more clear.

 

On Sun, Jan 20, 2019 at 7:39 PM Vittorio Bertocci <Vittorio@auth0.com> wrote:

[sent to John only by mistake, resending to the ML]

 

In Azure AD v1 & ADFS, that's resource.. It could be used for both network and logical ids, with the concrete usage in the wild I described earlier.

In Azure AD v2, the resource as explicit parameter (network, logic or otherwise) is gone and is expressed as part of the scope string of all the scopes requested for a given resource- but it still exist in practice tho as it still end up in the resulting aud of the issued token.

This is 9 months old info hence

 

On Sun, Jan 20, 2019 at 17:58 John Bradley <ve7jtb@ve7jtb.com> wrote:

What is the parameter that Microsoft is using?

On 1/20/2019 3:59 PM, Vittorio Bertocci wrote:

First of all, it wasn't my intent to disrupt the established process. In my former position I wasn't monitoring those discussions hence I didn't have a chance to offer feedback. When I saw something that gave me the impression might lead to issues, and given that I worked with actual deployments and developers using a similar parameter for a long time, I thought prudent to bring this up. I really appreciate Rifaat's stance on this. End of preamble.

 

Ultimately my goal is for developers to have guidance on how to work with the concept of logical resource in a standard compliant way, hence it doesn't strictly matter whether the definition of the corresponding parameter lives in oauth-resource-indicators or elsewhere.

That said. Reading through the draft, it would appear that most of the reasons for which the spec was created apply to both the network addressable and the logical resource types: knowing what keys to use to encrypt the token, constrain access tokens to the intended audience, avoiding overloading scopes with resource indicating parts... those all apply to network addressable and logic identifiers alike. And both parameters are expected to result in audience restricted tokens. It seems the only difference comes at token usage time, with the network addressable case giving more guarantees that the token will go to its intended recipient, but the request and audience restriction syntax seems to be exactly the same. 

On top of this: in the 99.999% of the scenarios I encountered in the wild in the last 5 years of using the resource parameter in the MS ecosystem, the resource identifier was known at design time: the developer discovered it out of band and placed it in the app config at deployment time. Those aren't fringe cases I occasionally encountered: the resource parameter in Azure AD v1 and ADFS was mandatory, hence literally every solution i saw or touched used it. As Brian suggested, this is a scenario where the security advantages of the network addressable case aren't as pronounced as in the case in which the client discovers the resource identifier at runtime. This isn't just because there is no specification suggesting location should be explicitly indicated, it's because there are many practical advantages at development and deployment time to be able to use logical identifiers- and if the concrete security advantages don't apply to the their case, people will simply not comply. 

 

In summary: creating two different parameters in two different documents is better than ignoring he logical identifier case altogether, however I think that not acknowledging the logical id case in oauth-resource-indicators is going to create confusion and ultimately not be as useful to the developer community as it could be.

 

 

 

On Sat, Jan 19, 2019 at 12:38 Phil Hunt <phil.hunt@oracle.com> wrote:

+1 to Mike and John’s comments. 

Phil


On Jan 19, 2019, at 12:34 PM, Mike Jones <Michael.Jones=40microsoft.com@dmarc.ietf.org> wrote:

I also agree that “resource” should be a specific network-addressable URL whereas a separate audience parameter (like “aud” in JWTs) can refer to one or more logical resources.  They are different, if related, things.

 

Note that the ACE WG is proposing to register a logical audience parameter “req_aud” in https://tools.ietf.org/html/draft-ietf-ace-oauth-params-01 - partly based on feedback from OAuth WG members.  This is a general OAuth parameter, which any OAuth deployment will be able to use.

 

I therefore believe that no changes are needed to draft-ietf-oauth-resource-indicators, as the logical audience work is already happening in another draft.

 

                                                          -- Mike

 

From: OAuth <oauth-bounces@ietf.org> On Behalf Of John Bradley
Sent: Saturday, January 19, 2019 9:01 AM
To: Brian Campbell <bcampbell@pingidentity.com>
Cc: Vittorio Bertocci <Vittorio=40auth0.com@dmarc.ietf.org>; IETF oauth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resource-indicators-01

 

We need to decide if we want to make a change.  

 

For security we are location centric.  

 

I prefer to keep resource location separate from logical audience that can be a scope or other parameter.  

 

If becomes harder for people to use the parameter correctly if we are too flexible.  

 

I would rather have a separate logical audience parameter if we think we want one.  

 

John B. 

 

On Sat, Jan 19, 2019, 11:41 AM Brian Campbell <bcampbell@pingidentity.com wrote:

No apology needed, Rifaat. And I apologize if what I said came off the wrong way. I was just trying to make light of the situation.. And I agree that we should not be hamstrung by the process and there are times when it makes sense to be flexible with things.

 

On Fri, Jan 18, 2019 at 6:22 PM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:

Sorry Brian, I was not clear with my statement.

I meant to say that we should not allow the process to prevent the WG from producing a quality document without issues, assuming there is an issue in the first place.

Ideally we want to get these identified during the WGLC, but things happen and sometimes the WG misses something. 

 

I hear you and agree that this make things difficult for authors. We will make sure that this does not become the norm, and we will try to stick to the process as much as possible.

 

Regards,

 Rifaat

 

 

On Fri, Jan 18, 2019 at 5:35 PM Brian Campbell <bcampbell@pingidentity.com> wrote:

Thanks Rifaat. Process is as process does, right? I do kinda want to grumble about WGCL having passed already but that's mostly because replying to these kinds of threads is hard for me and I'll just get over it...

 

As far as I understand things, the security concerns come into play when the client is being told the by the resource how to identity the resource like is described in https://tools.ietf.org/html/draft-ietf-oauth-distributed-01 and using the actual location in that context ,along with some other checks prescribed in that draft, prevents the kind of issues John described earlier in the thread.

In cases where the client knows the resource a priori or out-of-band or configured or whatever, I don't think the same security concerns arise. And using such a known value, be it an actual location or logical representation, would be okay.

The resource-indicators draft is admittedly somewhat location-centric in how it talks about the value of the 'resource' parameter. But ultimately it defines it as an absolute URI that indicates the location of the target service or resource where access is being requested. A location can be varying shades of abstract and I'd say that using a URI as 'resource' parameter value that's a logical identifier that points to some resource is well within the bounds of the draft.

 

So maybe the draft is okay as is?

 

Or perhaps that's too much to be left as an exerciser to the reader?  And some text should be added and/or adjusted so the resource-indicators draft would be a little more open/clear about the parameter value potentially being more of a logical or abstract identifier and not necessarily a network addressable URL?

 

 

 

On Fri, Jan 18, 2019 at 1:18 PM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:

I wouldn't worry too much about the process.

If it makes sense to update the document, then feel free to do that.

 

Regards,

 Rifaat

 

 

On Fri, Jan 18, 2019 at 3:08 PM John Bradley <ve7jtb@ve7jtb.com> wrote:

Yes the logical resource can be provided by "scope"

 

Some implementations like Ping and Auth0 have been adding another parameter "aud" to identify the logical resource and then using scopes to define permissions to the resource.

 

Fortunately, we are using a different parameter name so not stepping on that..

 

We could go back and try to add text explaining the difference, but we are quite late in the process. 

 

I agree that a logical resource parameter may be helpful, but perhaps it should be a separate draft.

 

John B.

 

On Fri, Jan 18, 2019 at 4:38 PM Richard Backman, Annabelle <richanna@amazon.com> wrote:

Doesn’t the “scope” parameter already provide a means of specifying a logical identifier?

 

-- 

Annabelle Richard Backman

AWS Identity

 

 

From: OAuth <oauth-bounces@ietf.org> on behalf of Vittorio Bertocci <Vittorio=40auth0.com@dmarc.ietf.org>
Date: Friday, January 18, 2019 at 5:47 AM
To: John Bradley <ve7jtb@ve7jtb.com>
Cc: IETF oauth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resource-indicators-01

 

Thanks John for the background.

I agree that from the client validation PoV, having an identifier corresponding to a location makes things more solid.

That said: the use of logical identifiers is widespread, as it has significant practical advantages (think of services that assign generated hosting URLs only at deployment time, or services that are somehow grouped under the same logical audience across regions/environment/deployments). People won't stop using logical identifiers, because they often have no alternative (generating new audiences on the fly at the AS every time you do a deployment and get assigned a new URL can be unfeasible). Leaving a widely used approach as exercise to the reader seems a disservice to the community, given that this might lead to vendors (for example Microsoft and Auth0) keeping their own proprietary parameters, or developers misusing the ones in place; would make it hard for SDK developers to provide libraries that work out of the box with different ASes; and so on.

Would it be feasible to add such parameter directly in this spec? That would eliminate the interop issues, and also gives us a chance to fully warn people about the security shortcomings of choosing that approach.

 

 

 

On Thu, Jan 17, 2019 at 4:32 PM John Bradley <ve7jtb@ve7jtb.com> wrote:

We have discussed this.

Audiences can certainly be logical identifiers.  

This however is a more specific location.  The AS is free to map the location into some abstract audience in the AT.

From a security point of view once the client starts asking for logical resources it can be tricked into asking for the wrong one as a bad resource can always lie about what logical resource it is.

If we were to change it, how a client would validate it becomes challenging to impossible.

The AS is free to do whatever mapping of locations to identifiers it needs for access tokens.

Some implementations may want to keep additional parameters like logical audience, but that should be separate from resource.

John B.

On 1/17/2019 9:56 AM, Rifaat Shekh-Yusef wrote:

Hi Vittorio,

 

The text you quoted is copied form the abstract of the draft itself.

 

 

Authors,

 

Should the draft be updated to cover the logical identifier case?

 

Regards,

 Rifaat

 

 

On Thu, Jan 17, 2019 at 8:19 AM Vittorio Bertocci <Vittorio@auth0.com> wrote:

Hi Rifaat,

one detail. The tech summary says

 

An extension to the OAuth 2.0 Authorization Framework defining request 
parameters that enable a client to explicitly signal to an authorization server 
about the location of the protected resource(s) to which it is requesting 
access.

But at least in the Microsoft implementation, the resource identifier doesn't have to be a network addressable URL (and if it is, it doesn't strictly need to match the actual resource location). It can be a logical identifier, tho using the actual resource location there has benefits (domain ownership check, prevention of token forwarding etc).

Same for Auth0, the audience parameter is a logical identifier rather than a location.

 

 

 

On Wed, Jan 16, 2019 at 6:32 PM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:

All,

 

The following is the first shepherd write-up for the draft-ietf-oauth-resource-indicators-01 document.

 

Please, take a look and let me know if I missed anything.

 

Regards,

 Rifaat

 

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

 

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf..org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.


CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited...  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you._______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

 

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

 

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf..org/mailman/listinfo/oauth

 

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you. 

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

 


CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.

--------------1CD0A9136094A3FD1F9AE843-- From nobody Mon Jan 28 15:26:37 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36311131142 for ; Mon, 28 Jan 2019 15:26:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.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 VlyiezX4-CE9 for ; Mon, 28 Jan 2019 15:26:22 -0800 (PST) Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF2B11311AC for ; Mon, 28 Jan 2019 15:26:21 -0800 (PST) Received: by mail-io1-xd2d.google.com with SMTP id k7so15014751iob.6 for ; Mon, 28 Jan 2019 15:26:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=BICFn3GCMOrtgaOVX2XbOz3BYEdsgnwVJtN/xr/qJho=; b=ZanF46zoKOqhyrsqdGaX/P6HvpfvtSyWMj0xN0oEgPxT2HWkXTC3N+erCsw6oDAPGh jeoFxDqsojsAnKUFyBs1uUzjxcxnSyRXxpkbhqERYl686uto7feDeUpdabhmXU7HrNDy 2AnTnnPlFS1pPgY/GX27D+kjHaEgYuLuWge30= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=BICFn3GCMOrtgaOVX2XbOz3BYEdsgnwVJtN/xr/qJho=; b=sfXbbr0BM7ItnWavveLoPkGmA3inuuL2/29qATlwh3q5owGO5Oy+VcSq/FxbrlB2sH goJ1n91Y4E7y8fWEKCcrziYz6h54cCjFlCp2ol9gspLQoGW4MCNy4nX7xLeZpiw90b+f 4p90xLAY5qti6kJbCPL5QlOfv4GIviCOvjUJ4NAfIzvzFQleM2vE5wVmragGwJF0PxTx /Bvajdj3NPoH39vvoGY0I7ZHbayZX1OLDlTRjIIE/4p7NV/UzVkVyk3CxE5LBEp0EPtj gcutfvgQglMAYSpM3wPs3rC125+uhKYkm5A0QJtI9P4FCY4C3LPjFfeOhLKFDKI1jbEX Chyw== X-Gm-Message-State: AHQUAubdBQpV7/ihfIcik8TmpxEMWjqN23y57djrV2i8l2OZGhqljoC8 pZAISeLf9+guDKoO22joTNS7hguhSgFOCTIup7jT625UgxY4JoCGLE05PaLifX/ZKO2nMB2pTuL S8zdF6yydMYg= X-Google-Smtp-Source: ALg8bN4vXz4x+cQUzaa1c4jNzSULYdjEp6RElTUubDSvDbzpEgxxqt5bLSkAjlOL407si7BTIzhQ26XrR9RzlcRsQeA= X-Received: by 2002:a6b:b345:: with SMTP id c66mr14067742iof.59.1548717980480; Mon, 28 Jan 2019 15:26:20 -0800 (PST) MIME-Version: 1.0 References: <4eb4ea45-c3f2-7991-9544-612d055809ba@ve7jtb.com> <199fa6bd-8103-b1b3-12a3-08b5e3aad925@aol.com> <55a0362e-e588-bce5-f65f-856a1e21e88e@aol.com> <65a8e83e-c72f-bbf5-77fd-ea8540b7ddc3@aol.com> In-Reply-To: <65a8e83e-c72f-bbf5-77fd-ea8540b7ddc3@aol.com> From: Brian Campbell Date: Mon, 28 Jan 2019 16:25:50 -0700 Message-ID: To: George Fletcher Cc: Mike Jones , ace@ietf.org, "oauth@ietf.org" , Vittorio Bertocci Content-Type: multipart/alternative; boundary="0000000000001599c705808d0199" Archived-At: Subject: Re: [Ace] [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resource-indicators-01 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2019 23:26:29 -0000 --0000000000001599c705808d0199 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Following up on the thread here and the discussion earlier during the "OAuth WG Virtual Office Hours" call, draft-ietf-oauth-resource-indicators-02 has been published with some minor updates to clarify that the value of the "resource" parameter is a URI which can be an abstract identifier for the target resource and doesn't necessarily have to correspond to a network addressable location. On Mon, Jan 28, 2019 at 3:12 PM George Fletcher wrote: > I also don't know that this raises to the level of "concern" but I find > the parameter name of "req_aud" odd. Given that the parameter in the > resource-indicators spec is 'resource' why not use a parameter name of > 'audience'. That said, I have not read the thread on the ACE working grou= p > list so there could be very good reasons for the chosen name:) > > I do think that there is a lot of overlap (in most cases) between > 'resource' and 'audience' and having two parameters that cover a lot of t= he > same semantics is going to be confusing for developers. When calling an A= PI > at a resource server, the 'audience' and the 'resource' are pretty > equivalent. Maybe in other use cases they are distinctly separate? > > Thanks, > George > > On 1/28/19 3:54 PM, Brian Campbell wrote: > > [added ace@ietf.org kinda per suggestion from Mike] > > I don't know that there are concerns about =E2=80=9Creq_aud=E2=80=9D per = se. Admittedly, > I did use the word "concerns" but I was more trying to say that referenci= ng > it from the draft-ietf-oauth-resource-indicators document wasn't needed t= o > address Vittorio's request. And pointing out that =E2=80=9Creq_aud=E2=80= =9D is defined for > the token endpoint while the draft-ietf-oauth-resource-indicators documen= t > also deals with the authorization endpoint so such a reference wouldn't > really work anyway. > > I don't know of anyone that just works from the OAuth parameter > registration but maybe I'm just out of touch. And I don't think its a > stretch at all to observe that ACE OAuth and OAuth 2 are different. > > > > On Mon, Jan 28, 2019 at 11:28 AM Mike Jones > wrote: > >> Brian, etc. If you have concerns about =E2=80=9Creq_aud=E2=80=9D, now= =E2=80=99s the time to >> provide that feedback to the ACE WG, as they=E2=80=99re trying to comple= te that >> draft soon. Please join the ACE WG mailing list and send your feedback >> there directly. >> >> >> >> You and I may know that ACE OAuth and OAuth 2 are pretty different but >> developers later will just see the OAuth parameter registration and won= =E2=80=99t >> realize that it=E2=80=99s coming from a different universe. If we can h= armonize >> things now, we should. >> >> >> >> -- Mike >> >> >> >> *From:* OAuth *On Behalf Of *George Fletcher >> *Sent:* Monday, January 28, 2019 10:05 AM >> *To:* Brian Campbell >> *Cc:* oauth@ietf.org; Vittorio Bertocci >> *Subject:* Re: [OAUTH-WG] Shepherd write-up for >> draft-ietf-oauth-resource-indicators-01 >> >> >> >> +1 >> >> I came to a similar conclusion over the weekend. If >> https://api.example.com/mail is an allowed location URI, how is it not >> also a logical location considering it's possible there are multiple >> endpoints "below" https://api.example.com/mail? (e.g. >> https://api.example.com/mail/user/mailbox). Also if https://api.example.= com >> is really a load balancer that fronts the " >> real" >> endpoints, then it's also "logical" in that context and not an exact >> location. >> >> This brings me to the conclusion that all the resource identifiers are >> "logical" along a range of specificity. How specific a resource is >> identified is really a risk decision and based on the deployment model c= an >> be managed at either the RS or the AS. >> >> Thanks, >> George >> >> On 1/28/19 9:07 AM, Brian Campbell wrote: >> >> I plan on joining the meeting today at noon eastern time to discuses thi= s >> little ditty. I hope others who have a stake in it can too. >> >> >> >> The proposed changes that Vittorio and I put together can be seen in the >> diff of this pull request >> https://github.com/ietf-oauth-resource-indicators/i-d/pull/1/files and I >> even put a xml2rfc'ed text version on >> https://github.com/ietf-oauth-resource-indicators/i-d/pull/1 for ease of >> reference. I maintain that is the most straightforward way forward with = all >> this. Yet another new additional parameter could be defined for the logi= cal >> case but I struggle to see the value in doing so. The 'resource' is URI >> that points to the resource. The level of specificity of that pointer is >> intentionally a bit fuzzy and application/deployment specific. Is >> https://graph.microsoft.com (mentioned in the documentation previously >> linked) a location or an abstract identifier or both? The document alrea= dy >> (somewhat awkwardly) describes using a "base URI" for the application or >> resource. Is that a a location or an abstract identifier? Or kinda both? >> >> >> >> In addition to the concerns others have expressed about "req_aud", I"d >> note that draft-ietf-ace-oauth-params defines its use only at the token >> endpoint as one of the "additional parameters for requesting an access >> token from a token endpoint in the ACE framework". Whereas the >> resource-indicators draft scope includes the authorization endpoint too. >> Furthermore, while the ACE WG is building on OAuth, for all intents and >> purposes ACE and regular OAuth are different worlds and I think a refere= nce >> in regular OAuth document like this one to "Additional OAuth Parameters = for >> Authorization in Constrained Environments (ACE)" would be a disservice t= o >> just about everyone. >> >> >> >> >> >> >> >> >> >> >> >> >> >> On Thu, Jan 24, 2019 at 5:13 PM Rifaat Shekh-Yusef > > wrote: >> >> Hannes sent an update to this meeting here: >> >> https://mailarchive.ietf.org/arch/msg/oauth/v8sUMEBGMC24AdWLewAymP-X4kU >> >> >> >> Regards, >> >> Rifaat >> >> >> >> >> >> On Thu, Jan 24, 2019 at 6:20 PM Mike Jones >> wrote: >> >> The virtual office hours in my calendar start 1/2 hour before that. If >> the time has changed, can you have the meeting organizer update the >> calendar entry? >> >> >> >> Thanks, >> >> -- Mike >> >> >> >> *From:* Rifaat Shekh-Yusef >> *Sent:* Thursday, January 24, 2019 12:46 PM >> *To:* George Fletcher >> *Cc:* Vittorio Bertocci ; Mike Jones < >> Michael.Jones@microsoft.com>; oauth@ietf.org >> *Subject:* Re: [OAUTH-WG] Shepherd write-up for >> draft-ietf-oauth-resource-indicators-01 >> >> >> >> All, >> >> >> >> This coming Monday, Jan 28 @ 12:00pm Eastern Time, we have a scheduled >> OAuth WG Virtual Office meeting. >> >> Feel free to attend the meeting to discuss this topic to try to get to a >> conclusion on this. >> >> >> >> Regards, >> >> Rifaat >> >> >> >> >> >> On Wed, Jan 23, 2019 at 3:00 PM George Fletcher > 40aol.com@dmarc.ietf.org> wrote: >> >> +1 >> >> Also, I don't really like the parameter name 'req_aud' :) I'm not 100% >> convinced that 'audience' and 'logical resource' are completely overlapp= ing >> concepts. We can potentially make them completely overlapping but we nee= d >> text to that effect. >> >> I also believe that we don't have a complete solution for all deployment= s >> using exact locations (see my previous email). >> >> Thanks, >> George >> >> On 1/23/19 2:50 PM, Vittorio Bertocci wrote: >> >> As mentioned below, I agree the two can be separated- but I also agree >> with George on the need to be clear an easy to reference for developers. >> >> Just adding a reference to req_aud would just raise the cyclomatic >> complexity of the specs, which is already unusably high for mere mortals= in >> the OAuth2/OIDC family of specs. >> >> >> >> One additional complication is that this specification is reusing a >> parameter that is already used in a *very* large number of production >> systems (small example here >> ), >> and whose concrete semantic happens to be prevalently logic identifier. = If >> the parameter you are defining here has a different semantic, at the ver= y >> least it would seem good hygiene to rename it to avoid collision and >> confusion. >> >> >> >> On Wed, Jan 23, 2019 at 11:03 AM Mike Jones > 40microsoft.com@dmarc.ietf.org> wrote: >> >> I agree with John=E2=80=99s logic. The physical resource and logical re= source >> should use different identifiers. Fortunately, we already have =E2=80= =9Cresource=E2=80=9D >> and =E2=80=9Creq_aud=E2=80=9D for these parameters. I believe we=E2=80= =99re good to go, as-is. >> >> >> >> -- Mike >> >> >> >> *From:* OAuth *On Behalf Of *John Bradley >> *Sent:* Wednesday, January 23, 2019 10:56 AM >> *To:* oauth@ietf.org >> *Subject:* Re: [OAUTH-WG] Shepherd write-up for >> draft-ietf-oauth-resource-indicators-01 >> >> >> >> I don't think they are necessarily mutually exclusive, that is why I >> think there is value in allowing them to be specified separately. >> >> As an AS in the distributed OAuth case knowing that a client interacting >> with RS https://fire.hhs.com as the resource wants a OAuth token with an >> audience of HHS and a scope of read. >> >> Without proof of possession we need to keep bad RS from asking for token= s >> with scopes and audiences of other RS that can be replayed. >> >> I really like keeping the resource simple and unspoofable, it is the URI >> of the RS where you are presenting the AT. >> >> I prefer to keep that separate from the logical resource that may span >> more than one RS endpoint. >> >> Merging the two and we are probably back at the AS looking into the URI >> to figure out which one it is. I think that is harder for implementatio= ns >> and more likely to have security issues down the road. >> >> John B. >> >> On 1/23/2019 1:44 PM, Vittorio Bertocci wrote: >> >> Hi all, >> >> thanks for you patience. Brian and myself iterated on modifying the text >> to cover the logical identifier use case, highlighting the security >> implications of going that route. You can find the revised text in >> https://github.com/vibronet/i-d/blob/master/draft-ietf-oauth-resource-in= dicators.xml, >> see the commits in the history from January 21 for the specific changes. >> >> Note: I also had a chat with John offline, and he expressed the desire t= o >> split the resource parameter in two distinct parameters to better signal >> the intended usage. I am sure he can elaborate. I have nothing against i= t >> in principle, as long as we leave nothing as exercise to the reader and = we >> are very clear on usage (e.g. mutual exclusivity, etc) but didn't have a >> chance to speak w Brian about it. If the discussion stretches further, I >> would suggest we pause it and let him enjoy his time off for the rest of >> the week. >> >> >> >> On Mon, Jan 21, 2019 at 5:35 PM Rifaat Shekh-Yusef >> wrote: >> >> Thank you guys! >> >> >> >> On Monday, January 21, 2019, Vittorio Bertocci >> wrote: >> >> Hi Rifaat, >> >> absolutely. Brian and myself already started working on some language, >> however this week he is in vacation hence it might take few days before = we >> come back to the list with something. >> >> Cheers, >> >> V. >> >> >> >> On Mon, Jan 21, 2019 at 9:35 AM Rifaat Shekh-Yusef >> wrote: >> >> Brian, Vittorio, >> >> >> >> To move this discussion forward, can you guys suggest some text to make >> the logical identifier usage clearer? >> >> >> >> Regards, >> >> Rifaat >> >> >> >> >> >> On Mon, Jan 21, 2019 at 10:32 AM Brian Campbell > 40pingidentity.com@dmarc.ietf..org <40pingidentity.com@dmarc.ietf.org>> >> wrote: >> >> As I suggested before, I do think that's within the bounds of the draft'= s >> definition of 'resource' as a URI. And that perhaps all that's needed is >> some minor adjustment and/or augmentation of some text to make it more >> clear. >> >> >> >> On Sun, Jan 20, 2019 at 7:39 PM Vittorio Bertocci >> wrote: >> >> [sent to John only by mistake, resending to the ML] >> >> >> >> In Azure AD v1 & ADFS, that's resource.. It could be used for both >> network and logical ids, with the concrete usage in the wild I described >> earlier. >> >> In Azure AD v2, the resource as explicit parameter (network, logic or >> otherwise) is gone and is expressed as part of the scope string of all t= he >> scopes requested for a given resource- but it still exist in practice th= o >> as it still end up in the resulting aud of the issued token. >> >> This is 9 months old info hence >> >> >> >> On Sun, Jan 20, 2019 at 17:58 John Bradley wrote: >> >> What is the parameter that Microsoft is using? >> >> On 1/20/2019 3:59 PM, Vittorio Bertocci wrote: >> >> First of all, it wasn't my intent to disrupt the established process. In >> my former position I wasn't monitoring those discussions hence I didn't >> have a chance to offer feedback. When I saw something that gave me the >> impression might lead to issues, and given that I worked with actual >> deployments and developers using a similar parameter for a long time, I >> thought prudent to bring this up. I really appreciate Rifaat's stance on >> this. End of preamble. >> >> >> >> Ultimately my goal is for developers to have guidance on how to work wit= h >> the concept of logical resource in a standard compliant way, hence it >> doesn't strictly matter whether the definition of the corresponding >> parameter lives in oauth-resource-indicators or elsewhere. >> >> That said. Reading through the draft, it would appear that most of the >> reasons for which the spec was created apply to both the network >> addressable and the logical resource types: knowing what keys to use to >> encrypt the token, constrain access tokens to the intended audience, >> avoiding overloading scopes with resource indicating parts... those all >> apply to network addressable and logic identifiers alike. And both >> parameters are expected to result in audience restricted tokens. It seem= s >> the only difference comes at token usage time, with the network addressa= ble >> case giving more guarantees that the token will go to its intended >> recipient, but the request and audience restriction syntax seems to be >> exactly the same. >> >> On top of this: in the 99.999% of the scenarios I encountered in the wil= d >> in the last 5 years of using the resource parameter in the MS ecosystem, >> the resource identifier was known at design time: the developer discover= ed >> it out of band and placed it in the app config at deployment time. Those >> aren't fringe cases I occasionally encountered: the resource parameter i= n >> Azure AD v1 and ADFS was mandatory, hence literally every solution i saw= or >> touched used it. As Brian suggested, this is a scenario where the securi= ty >> advantages of the network addressable case aren't as pronounced as in th= e >> case in which the client discovers the resource identifier at runtime. T= his >> isn't just because there is no specification suggesting location should = be >> explicitly indicated, it's because there are many practical advantages a= t >> development and deployment time to be able to use logical identifiers- a= nd >> if the *concrete *security advantages don't apply to the their case, >> people will simply not comply. >> >> >> >> In summary: creating two different parameters in two different documents >> is better than ignoring he logical identifier case altogether, however I >> think that not acknowledging the logical id case >> in oauth-resource-indicators is going to create confusion and ultimately >> not be as useful to the developer community as it could be. >> >> >> >> >> >> >> >> On Sat, Jan 19, 2019 at 12:38 Phil Hunt wrote: >> >> +1 to Mike and John=E2=80=99s comments. >> >> Phil >> >> >> On Jan 19, 2019, at 12:34 PM, Mike Jones < >> Michael.Jones=3D40microsoft.com@dmarc.ietf.org> wrote: >> >> I also agree that =E2=80=9Cresource=E2=80=9D should be a specific networ= k-addressable URL >> whereas a separate audience parameter (like =E2=80=9Caud=E2=80=9D in JWT= s) can refer to one >> or more logical resources. They are different, if related, things. >> >> >> >> Note that the ACE WG is proposing to register a logical audience >> parameter =E2=80=9Creq_aud=E2=80=9D in >> https://tools.ietf.org/html/draft-ietf-ace-oauth-params-01 - partly >> based on feedback from OAuth WG members. This is a general OAuth >> parameter, which any OAuth deployment will be able to use. >> >> >> >> I therefore believe that no changes are needed to >> draft-ietf-oauth-resource-indicators, as the logical audience work is >> already happening in another draft. >> >> >> >> -- Mike >> >> >> >> *From:* OAuth *On Behalf Of *John Bradley >> *Sent:* Saturday, January 19, 2019 9:01 AM >> *To:* Brian Campbell >> *Cc:* Vittorio Bertocci ; IETF >> oauth WG >> *Subject:* Re: [OAUTH-WG] Shepherd write-up for >> draft-ietf-oauth-resource-indicators-01 >> >> >> >> We need to decide if we want to make a change. >> >> >> >> For security we are location centric. >> >> >> >> I prefer to keep resource location separate from logical audience that >> can be a scope or other parameter. >> >> >> >> If becomes harder for people to use the parameter correctly if we are to= o >> flexible. >> >> >> >> I would rather have a separate logical audience parameter if we think we >> want one. >> >> >> >> John B. >> >> >> >> On Sat, Jan 19, 2019, 11:41 AM Brian Campbell > wrote: >> >> No apology needed, Rifaat. And I apologize if what I said came off the >> wrong way. I was just trying to make light of the situation.. And I agre= e >> that we should not be hamstrung by the process and there are times when = it >> makes sense to be flexible with things. >> >> >> >> On Fri, Jan 18, 2019 at 6:22 PM Rifaat Shekh-Yusef >> wrote: >> >> Sorry Brian, I was not clear with my statement. >> >> I meant to say that we should not allow the process to prevent the WG >> from producing a quality document without issues, assuming there is an >> issue in the first place. >> >> Ideally we want to get these identified during the WGLC, but things >> happen and sometimes the WG misses something. >> >> >> >> I hear you and agree that this make things difficult for authors. We wil= l >> make sure that this does not become the norm, and we will try to stick t= o >> the process as much as possible. >> >> >> >> Regards, >> >> Rifaat >> >> >> >> >> >> On Fri, Jan 18, 2019 at 5:35 PM Brian Campbell < >> bcampbell@pingidentity.com> wrote: >> >> Thanks Rifaat. Process is as process does, right? I do kinda want to >> grumble about WGCL having passed already but that's mostly because reply= ing >> to these kinds of threads is hard for me and I'll just get over it... >> >> >> >> As far as I understand things, the security concerns come into play when >> the client is being told the by the resource how to identity the resourc= e >> like is described in >> https://tools.ietf.org/html/draft-ietf-oauth-distributed-01 and using >> the actual location in that context ,along with some other checks >> prescribed in that draft, prevents the kind of issues John described >> earlier in the thread. >> >> In cases where the client knows the resource a priori or out-of-band or >> configured or whatever, I don't think the same security concerns arise. = And >> using such a known value, be it an actual location or logical >> representation, would be okay. >> >> The resource-indicators draft is admittedly somewhat location-centric in >> how it talks about the value of the 'resource' parameter. But ultimately= it >> defines it as an absolute URI that indicates the location of the target >> service or resource where access is being requested. A location can be >> varying shades of abstract and I'd say that using a URI as 'resource' >> parameter value that's a logical identifier that points to some resource= is >> well within the bounds of the draft. >> >> >> >> So maybe the draft is okay as is? >> >> >> >> Or perhaps that's too much to be left as an exerciser to the reader? An= d >> some text should be added and/or adjusted so the resource-indicators dra= ft >> would be a little more open/clear about the parameter value potentially >> being more of a logical or abstract identifier and not necessarily a >> network addressable URL? >> >> >> >> >> >> >> >> On Fri, Jan 18, 2019 at 1:18 PM Rifaat Shekh-Yusef >> wrote: >> >> I wouldn't worry too much about the process. >> >> If it makes sense to update the document, then feel free to do that. >> >> >> >> Regards, >> >> Rifaat >> >> >> >> >> >> On Fri, Jan 18, 2019 at 3:08 PM John Bradley wrote: >> >> Yes the logical resource can be provided by "scope" >> >> >> >> Some implementations like Ping and Auth0 have been adding another >> parameter "aud" to identify the logical resource and then using scopes t= o >> define permissions to the resource. >> >> >> >> Fortunately, we are using a different parameter name so not stepping on >> that.. >> >> >> >> We could go back and try to add text explaining the difference, but we >> are quite late in the process. >> >> >> >> I agree that a logical resource parameter may be helpful, but perhaps it >> should be a separate draft. >> >> >> >> John B. >> >> >> >> On Fri, Jan 18, 2019 at 4:38 PM Richard Backman, Annabelle < >> richanna@amazon.com> wrote: >> >> Doesn=E2=80=99t the =E2=80=9Cscope=E2=80=9D parameter already provide a = means of specifying a >> logical identifier? >> >> >> >> -- >> >> Annabelle Richard Backman >> >> AWS Identity >> >> >> >> >> >> *From: *OAuth on behalf of Vittorio Bertocci >> > >> *Date: *Friday, January 18, 2019 at 5:47 AM >> *To: *John Bradley >> *Cc: *IETF oauth WG >> *Subject: *Re: [OAUTH-WG] Shepherd write-up for >> draft-ietf-oauth-resource-indicators-01 >> >> >> >> Thanks John for the background. >> >> I agree that from the client validation PoV, having an identifier >> corresponding to a location makes things more solid. >> >> That said: the use of logical identifiers is widespread, as it has >> significant practical advantages (think of services that assign generate= d >> hosting URLs only at deployment time, or services that are somehow group= ed >> under the same logical audience across regions/environment/deployments). >> People won't stop using logical identifiers, because they often have no >> alternative (generating new audiences on the fly at the AS every time yo= u >> do a deployment and get assigned a new URL can be unfeasible). Leaving a >> widely used approach as exercise to the reader seems a disservice to the >> community, given that this might lead to vendors (for example Microsoft = and >> Auth0) keeping their own proprietary parameters, or developers misusing = the >> ones in place; would make it hard for SDK developers to provide librarie= s >> that work out of the box with different ASes; and so on. >> >> Would it be feasible to add such parameter directly in this spec? That >> would eliminate the interop issues, and also gives us a chance to fully >> warn people about the security shortcomings of choosing that approach. >> >> >> >> >> >> >> >> On Thu, Jan 17, 2019 at 4:32 PM John Bradley wrote: >> >> We have discussed this. >> >> Audiences can certainly be logical identifiers. >> >> This however is a more specific location. The AS is free to map the >> location into some abstract audience in the AT. >> >> From a security point of view once the client starts asking for logical >> resources it can be tricked into asking for the wrong one as a bad resou= rce >> can always lie about what logical resource it is. >> >> If we were to change it, how a client would validate it becomes >> challenging to impossible. >> >> The AS is free to do whatever mapping of locations to identifiers it >> needs for access tokens. >> >> Some implementations may want to keep additional parameters like logical >> audience, but that should be separate from resource. >> >> John B. >> >> On 1/17/2019 9:56 AM, Rifaat Shekh-Yusef wrote: >> >> Hi Vittorio, >> >> >> >> The text you quoted is copied form the abstract of the draft itself. >> >> >> >> >> >> *Authors,* >> >> >> >> Should the draft be updated to cover the logical identifier case? >> >> >> >> Regards, >> >> Rifaat >> >> >> >> >> >> On Thu, Jan 17, 2019 at 8:19 AM Vittorio Bertocci >> wrote: >> >> Hi Rifaat, >> >> one detail. The tech summary says >> >> >> >> An extension to the OAuth 2.0 Authorization Framework defining request >> >> parameters that enable a client to explicitly signal to an authorization= server >> >> about the *location* of the protected resource(s) to which it is request= ing >> >> access. >> >> But at least in the Microsoft implementation, the resource identifier >> doesn't *have* to be a network addressable URL (and if it is, it doesn't >> strictly need to match the actual resource location). It can be a logica= l >> identifier, tho using the actual resource location there has benefits >> (domain ownership check, prevention of token forwarding etc). >> >> Same for Auth0, the audience parameter is a logical identifier rather >> than a location. >> >> >> >> >> >> >> >> On Wed, Jan 16, 2019 at 6:32 PM Rifaat Shekh-Yusef >> wrote: >> >> All, >> >> >> >> The following is the first shepherd write-up for >> the draft-ietf-oauth-resource-indicators-01 document. >> >> >> https://datatracker.ietf.org/doc/draft-ietf-oauth-resource-indicators/sh= epherdwriteup/ >> >> >> >> Please, take a look and let me know if I missed anything. >> >> >> >> Regards, >> >> Rifaat >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> >> _______________________________________________ >> >> OAuth mailing list >> >> OAuth@ietf.org >> >> https://www.ietf..org/mailman/listinfo/oauth >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> *CONFIDENTIALITY NOTICE: This email may contain confidential and >> privileged material for the sole use of the intended recipient(s). Any >> review, use, distribution or disclosure by others is strictly prohibited= . >> If you have received this communication in error, please notify the send= er >> immediately by e-mail and delete the message and any file attachments fr= om >> your computer. Thank you.* >> >> >> *CONFIDENTIALITY NOTICE: This email may contain confidential and >> privileged material for the sole use of the intended recipient(s). Any >> review, use, distribution or disclosure by others is strictly prohibited= .. >> If you have received this communication in error, please notify the send= er >> immediately by e-mail and delete the message and any file attachments fr= om >> your computer. Thank you.* >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> *CONFIDENTIALITY NOTICE: This email may contain confidential and >> privileged material for the sole use of the intended recipient(s). Any >> review, use, distribution or disclosure by others is strictly >> prohibited... If you have received this communication in error, please >> notify the sender immediately by e-mail and delete the message and any f= ile >> attachments from your computer. Thank you.* >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> >> _______________________________________________ >> >> OAuth mailing list >> >> OAuth@ietf.org >> >> https://www.ietf.org/mailman/listinfo/oauth >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> >> _______________________________________________ >> >> OAuth mailing list >> >> OAuth@ietf.org >> >> https://www.ietf..org/mailman/listinfo/oauth >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> *CONFIDENTIALITY NOTICE: This email may contain confidential and >> privileged material for the sole use of the intended recipient(s). Any >> review, use, distribution or disclosure by others is strictly prohibited= .. >> If you have received this communication in error, please notify the send= er >> immediately by e-mail and delete the message and any file attachments fr= om >> your computer. Thank you.* >> >> _______________________________________________ >> >> OAuth mailing list >> >> OAuth@ietf.org >> >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited. > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you.* > > > --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --0000000000001599c705808d0199 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Following up on the thre= ad here and the discussion earlier during the "OAuth WG Virtual Office= Hours" call, draft-ietf-oauth-resource-indicat= ors-02 has been published with some minor updates to clarify that the v= alue of the "resource" parameter is a URI which can be an abstrac= t identifier for the target resource and doesn't necessarily have to co= rrespond to a network addressable location.

On= Mon, Jan 28, 2019 at 3:12 PM George Fletcher <gffletch@aol.com> wrote:
=20 =20 =20
I also don't know that this raises to the level of "concern&qu= ot; but I find the parameter name of "req_aud" odd. Given that the para= meter in the resource-indicators spec is 'resource' why not use a parameter name of 'audience'. That said, I have not read the th= read on the ACE working group list so there could be very good reasons for the chosen name:)

I do think that there is a lot of overlap (in most cases) between 'resource' and 'audience' and having two parameters tha= t cover a lot of the same semantics is going to be confusing for developers. When calling an API at a resource server, the 'audience' and the 'resource' are pretty equivalent. Maybe in other use cases they= are distinctly separate?

Thanks,
George

On 1/28/19 3:54 PM, Brian Campbell wrote:
=20
[added ace@ietf.org kinda per suggestion from Mike]

I don't know that there are concerns about =E2=80= =9Creq_aud=E2=80=9D per se.=C2=A0 Admittedly, I did use the word "conc= erns" but I was more trying to say that referencing it from the draft-ietf-oauth-resource-indicators document wasn't needed to address Vittorio's request. And pointing out that =E2=80=9Creq_aud=E2=80= =9D=C2=A0 is defined for the token endpoint while the draft-ietf-oauth-resource-indicators document also deals with the authorization endpoint so such a reference wouldn't really work anyway.

I don't know of anyone that just works from the OAuth parameter registration but maybe I'm just out of touch. And I don't think its a stretch at all to observe that ACE OAuth and OAuth 2 are different.



On Mon, Jan 28, 2019 at 11:28 AM Mike Jones <Michael.Jones@mic= rosoft.com> wrote:

Brian, etc.=C2=A0 If you have concerns about =E2=80=9Creq_aud=E2= =80=9D, now=E2=80=99s the time to provide that feedback to the ACE WG, as they=E2=80=99re trying to complete= that draft soon.=C2=A0 Please join the ACE WG mailing list and send your feedback there directly.

=C2=A0

You and I may know that ACE OAuth and OAuth 2 are pretty different but developers later will just see the OAuth parameter registration and won=E2=80=99t realize that it=E2=80=99s comin= g from a different universe.=C2=A0 If we can harmonize things now, we should.

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -- Mike

=C2=A0

From: OAuth <<= a href=3D"mailto:oauth-bounces@ietf.org" target=3D"_blank">oauth-bounces@ie= tf.org> On Behalf Of George Fletcher
Sent: Monday, January 28, 2019 10:05 AM
To: Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf= .org>
Cc: oauth@ietf.org; Vittorio Bertocci <vittorio.bertocci@auth0.com>
Subject: Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resource-indicators-01

=C2=A0

+1

I came to a similar conclusion over the weekend. If https://api.example.com/mail is an allowed location URI, how is it not also a logical location considering it's possibl= e there are multiple endpoints "below" https://api.example.com/mail? (e.g. https://api.example.com/mail/user/mailbox). Also if https://api.example.com is really a load balancer that fronts the &quo= t;real" endpoints, then it's also "logical&q= uot; in that context and not an exact location.

This brings me to the conclusion that all the resource identifiers are "logical&qu= ot; along a range of specificity. How specific a resource is identified is really a risk decision and based on the deployment model can be managed at either the RS or the AS.
Thanks,
George

On 1/28/19 9:07 AM, Brian Campbell wrote:

I plan on joining the meeting today at noon eastern time to discuses this little ditty. I hope others who have a stake in it can too.

=C2=A0

The proposed changes that Vittorio and I put together can be seen in the diff of this pull request https://github.com/ietf-oauth-resource-indicators/i-d/pull/1/files and I even put a xml2rfc'ed text version on https://github.com/ietf-oauth-resource-indicators/i-d/pull/1 for ease of reference. I maintain that is the most straightforward way forward with all this. Yet another new additional parameter could be defined for the logical case but I struggle to see the value in doing so. The 'resource' = is URI that points to the resource. The level of specificity of that pointer is intentionally a bit fuzzy and application/deploym= ent specific. Is https://graph.microsoft.com (mentioned in the documentation previously linked) a location or an abstract identifier or both? The document already (somewhat awkwardly) describes using a "base URI&qu= ot; for the application or resource. Is that a a location or an abstract identifier? Or kinda both?

=C2=A0

In addition to the concerns others have expressed about "req_aud= ", I"d note that draft-ietf-ace-oaut= h-params defines its use only at the token endpoint as one of the "additional parameters for requesting an access token from a token endpoint in the ACE framework"= . Whereas the resource-indicators draft scope includes the authorization endpoint too. Furthermore, while the ACE WG is building on OAuth, for all intents and purposes ACE and regular OAuth are different worlds and I think a reference in regular OAuth document like this one to "Additional OAuth Parameters for Authorization in Constrained Environments (ACE)" would b= e a disservice to just about everyone.

=C2=A0

=C2=A0

= =C2=A0

= =C2=A0

=C2=A0

=C2=A0

On Thu, Jan 24, 2019 at 5:13 PM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:

Hannes sent an update to this meeting here:

=C2=A0

Regards,

=C2=A0Rifaat

=C2=A0

=C2=A0

On Thu, Jan 24, 2019 at 6:20 PM Mike Jones <Michael.Jones@mi= crosoft.com> wrote:

The virtual office hours in my calendar start 1/2 hour before that.=C2=A0 If the time has changed, can you have the meeting organizer update the calendar entry?

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Thanks,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -- Mike

=C2=A0

From: Rifaat Shekh-Yusef <rifaat.ietf@gmail.com&= gt;
Sent: Thursday, January 24, 2019 12:46 PM
To: George Fletcher <gffletch@aol.com>
Cc: Vittorio Bertocci <Vittorio@auth0.com>; Mike Jones <Michael.Jones@microsoft.com<= /a>>; oauth@ietf.org
Subject: Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resource-indicat= ors-01

=C2=A0

All,

=C2=A0=

This coming Monday, Jan 28 @ 12:00pm Eastern Time, we have a scheduled OAuth WG Virtual Office meeting.

Feel free to attend the meeting to discuss this topic to try to get to a conclusion on this.

=C2=A0=

Regards,

=C2=A0Rifaat

=C2=A0=

=C2=A0

On Wed, Jan 23, 2019 at 3:00 PM George Fletcher <gffletch=3D40aol.com@dmarc.ietf.org> wrote:

+1

Also, I don't really like the parameter name 'req_aud' :)= I'm not 100% convinced that 'audience' a= nd 'logical resource'= ; are completely overlapping concepts. We can potentially make them completely overlapping but we need text to that effect.

I also believe that we don't have a complete solution for all deployments using exact locations (see my previous email).

Thanks,
George

On 1/23/19 2:50 PM, Vittorio Bertocci wrote:

=C2= =A0

= On Wed, Jan 23, 2019 at 11:03 AM Mike Jones <Michael.Jones=3D<= a href=3D"mailto:40microsoft.com@dmarc.ietf.org" target=3D"_blank">40micros= oft.com@dmarc.ietf.org> wrote:

I agree with John=E2=80=99s logic.= =C2=A0 The physical resource and logical resource should use different identifiers.=C2= =A0 Fortunately, we already have =E2=80=9Cresource= =E2=80=9D and =E2=80=9Creq_aud= =E2=80=9D for these parameters.=C2=A0= I believe we=E2=80= =99re good to go, as-is.

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -- Mike

=C2=A0

From: OAuth <oauth-bounces@ietf.org= > On Behalf Of John Bradley
Sent: Wednesday, January 23, 2019 10:56 AM
To: oauth@ietf.org
Subject: Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-= resource-indicators-01

=C2=A0

I don't thin= k they are necessarily mutually exclusive, that is why I think there is value in allowing them to be specified separately.

As an AS in the distributed OAuth case knowing that a client interacting with RS https://fire.hhs.com as the resource wants a OAuth token with an audience of HHS and a scope of read.

Without proof of possession we need to keep bad RS from asking for tokens with scopes and audiences of other RS that can be replayed.

I really like keeping the resource simple and unspoofable, it is the URI of the RS where you are presenting the AT.

I prefer to keep that separate from the logical resource that may span more than one RS endpoint.

Merging the two and we are probably back at the AS looking into the URI to figure out which one it is.=C2=A0 I think that is harder for implementations and more likely to have security issues down the road.

John B.

On 1/23/2019 1:44 PM, Vittorio Bertocci wrote:

Hi all,

thanks for you patience. Brian and myself iterated on modifying the text to cover the logical identifier use case, highlighting the security implications of going that route. You can find the revised text in=C2=A0https://github.com/vibronet/i-d/blob/maste= r/draft-ietf-oauth-resource-indicators.xml, see the commits in the history from January 21 for the specific changes.

Note: I also had a chat with John offline, and he expressed the desire to split the resource parameter in two distinct parameters to better signal the intended usage. I am sure he can elaborate. I have nothing against it in principle, as long as we leave nothing as exercise to the reader and we are very clear on usage (e.g. mutual exclusivity, etc) but didn't have a chance to speak w Brian about it. If the discussion stretches further, I would suggest we pause it and let him enjoy his time off for the rest of the week.

=C2=A0

On Mon, Jan 21, 2019 at 5:35 PM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:

Thank you guys!



On Monday, January 21, 2019, Vittorio Bertocci <Vittorio@auth0.com&= gt; wrote:

Hi Rifaat,

absolutely. Brian and myself already started working on some language, however this week he is in vacation hence it might take few days before we come back to the list with something.

Cheers,

V.

=C2=A0

On Mon, Jan 21, 2019 at 9:35 AM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:

Brian, Vittorio,

=C2=A0

To move this discussion forward, can you guys suggest some text to make the logical identifier usage clearer?

=C2=A0

Regards,

=C2=A0Rifaat

=C2=A0

=C2=A0

On Mon, Jan 21, 2019 at 10:32 AM Brian Campbell <bcampbell=3D<= a href=3D"mailto:40pingidentity.com@dmarc.ietf.org" target=3D"_blank">40pin= gidentity.com@dmarc.ietf..org> wrote:

As I suggested before, I do think that's within the bounds of the draft's definition of 'resource'= ; as a URI. And that perhaps all that's needed is some minor adjustment and/or augmentation of some text to make it more clear.

=C2=A0

On Sun, Jan 20, 2019 at 7:39 PM Vittorio Bertocci <Vittorio@auth0.com&= gt; wrote:

[sent to John only by mistake, resending to the ML]

=C2=A0

In Azure AD v1 & ADFS, that's=C2=A0<= /span>resource.. It could be used for both network and logical ids, with the concrete usage in the wild I described earlier.

In Azure AD v2, the resource as e= xplicit parameter (network, logic or otherwise) is gone and is expressed as part of the scope string of all the scopes requested for a given resource- but it still exist in practice tho as it still end up in the resulting=C2=A0=C2=A0of the issued token.<= /span>

This is 9 months old info hence

=C2=A0

On Sun, Jan 20, 2019 at 17:58 John Bradley <ve7jtb@ve7jtb.com> wrote:<= /p>

What is the parameter that Microsoft is using?

On 1/20/2019 3:59 PM, Vittorio Bertocci wrote:

First of all, it wasn't my intent to disrupt the established process. In my former position I wasn't monitoring those discussions hence I didn'= t have a chance to offer feedback. When I saw something that gave me the impression might lead to issues, and given that I worked with actual deployments and developers using a similar parameter for a long time, I thought prudent to bring this up. I really appreciate Rifaat's stance on this. End of preamble.

=C2=A0

Ultimately my goal is for developers to have guidance on how to work with the concept of logical resource in a standard compliant way, hence it doesn't strictly matter whether the definition of the corresponding parameter lives in=C2=A0oauth-res= ource-indicators or elsewhere.

That said. Reading through the draft, it would appear that most of the reasons for which the spec was created apply to both the network addressable and the logical resource types: knowing what keys to use to encrypt the token, constrain access tokens to the intended audience, avoiding overloading scopes with resource indicating parts... those all apply to network addressable and logic identifiers alike. And both parameters are expected to result in audience restricted tokens. It seems the only difference comes at token usage time, with the network addressable case giving more guarantees that the token will go to its intended recipient, but the request and audience restriction syntax seems to be exactly the same.=C2=A0

On top of this: in the 99.999% of the scenarios I encountered in the wild in the last 5 years of using the resource parameter in the MS ecosystem, the resource identifier was known at design time: the developer discovered it out of band and placed it in the app config at deployment time. Those aren't fringe cases I occasionally encountered: the resource parameter in Azure AD v1 and ADFS was mandatory, hence literally every solution i saw or touched used it. As Brian suggested, this is a scenario where the security advantages of the network addressable case aren't a= s pronounced as in the case in which the client discovers the resource identifier at runtime. This isn't just because there is no specification suggesting location should be explicitly indicated, it's because there are many practical advantages at development and deployment time to be able to use logical identifiers- and if the concrete s= ecurity advantages don't apply t= o the their case, people will simply not comply.=C2=A0=

=C2=A0

In summary: creating two different parameters in two different documents is better than ignoring he logical identifier case altogether, however I think that not acknowledging the logical id case in=C2=A0oauth-res= ource-indicators is going to create confusion and ultimately not be as useful to the developer community as it could be.

=C2=A0

=C2=A0

=C2=A0

On Sat, Jan 19, 2019 at 12:38 Phil Hunt <phil.hunt@oracle.com= > wrote:

+1 to Mike and John=E2=80=99s comments.= =C2=A0

Phil


On Jan 19, 2019, at 12:34 PM, Mike Jones <Mich= ael.Jones=3D40microsoft.com@dmarc.ietf.org> wrote:

I also agree that =E2=80=9Cresourc= e=E2=80=9D should be a specific network-addressab= le URL whereas a separate audience parameter (like =E2=80=9Cau= d=E2=80=9D in JWTs) can refer to one or more logical resources.=C2=A0 They are different, if related, things.

=C2=A0

Note that the ACE WG is proposing = to register a logical audience parameter =E2=80=9Creq_aud= =E2=80=9D in https://tools.ietf.org/html/draft-ietf-ace-oauth-params-01 - partly based on feedback from OAuth WG members.=C2=A0 Th= is is a general OAuth parameter, which any OAuth deployment will be able to use.

=C2=A0

I therefore believe that no change= s are needed to draft-ietf-oauth-= resource-indicators, as the logical audience work is already happening in another draft.

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 -- Mike

=C2=A0

From: OAuth <oauth-bounces@ietf.org= > On Behalf Of John Bradley
Sent: Saturday, January 19, 2019 9:01 AM
To: Brian Campbell <bcampbell@pingidentity.c= om>
Cc: Vittorio Bertocci <Vitt= orio=3D40auth0.com@dmarc.ietf.org>; IETF oauth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-= resource-indicators-01

=C2=A0

We need to decide if we want to make a change.=C2=A0=C2= =A0

=C2=A0

For security we are location centric.=C2=A0=C2= =A0

=C2=A0

I prefer to keep resource location separate from logical audience that can be a scope or other parameter.=C2=A0= =C2=A0

=C2=A0

If becomes harder for people to use the parameter correctly if we are too flexible.=C2=A0= =C2=A0

=C2=A0

I would rather have a separate logical audience parameter if we think we want one.=C2=A0= =C2=A0

=C2=A0

John B.=C2=A0

=C2=A0

On Sat, Jan 19, 2019, 11:41 AM Brian Campbell <bcampbell@pingidentity.c= om wrote:

No apology needed, Rifaat. And I apologize if what I said came off the wrong way. I was just trying to make light of the situation.. And I agree that we should not be hamstrung by the process and there are times when it makes sense to be flexible with things.

=C2=A0

On Fri, Jan 18, 2019 at 6:22 PM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:

Sorry Brian, I was not clear with my statement.

I meant to say that we should not allow the process to prevent the WG from producing a quality document without issues, assuming there is an issue in the first place.

Ideally we want to get these identified during the WGLC, but things happen and sometimes the WG misses something.=C2=A0<= /p>

=C2=A0

I hear you and agree that this make things difficult for authors. We will make sure that this does not become the norm, and we will try to stick to the process as much as possible.

=C2=A0

Regards,

=C2=A0Rifaat

=C2=A0

=C2=A0

On Fri, Jan 18, 2019 at 5:35 PM Brian Campbell <bcampbell@pingi= dentity.com> wrote:

Thanks Rifaat. Process is as process does, right? I do kinda want to grumble about WGCL having passed already but that's mostly because replying to these kinds of threads is hard for me and I'll just get over it...

=C2=A0

As far as I understand things, the security concerns come into play when the client is being told the by the resource how to identity the resource like is described in https://tools.ietf.org/html/draft-ietf-oauth-distributed-01 and using the actual location in that context ,along with some other checks prescribed in that draft, prevents the kind of issues John described earlier in the thread.

In cases where the client knows the resource a priori or out-of-band or configured or whatever, I don't think the same security concerns arise. And using such a known value, be it an actual location or logical representation, would be okay.
The resource-indicato= rs draft is admittedly somewhat location-centric in how it talks about the value of the 'resource= ' parameter. But ultimately it defines it as an absolute URI that indicates the location of the target service or resource where access is being requested. A location can be varying shades of abstract and I'd say that using a URI as 'resource'= ; parameter value that's = a logical identifier that points to some resource is well within the bounds of the draft.

=C2=A0

So maybe the draft is okay as is?

=C2=A0

Or perhaps that'= s too much to be left as an exerciser to the reader?=C2=A0 And some text should be added and/or adjusted so the resource-indicato= rs draft would be a little more open/clear about the parameter value potentially being more of a logical or abstract identifier and not necessarily a network addressable URL?

=C2=A0

=C2=A0

=C2=A0

On Fri, Jan 18, 2019 at 1:18 PM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:

I wouldn't worr= y too much about the process.

If it makes sense to update the document, then feel free to do that.

=C2=A0

Regards,

=C2=A0Rifaat

=C2=A0

=C2=A0

On Fri, Jan 18, 2019 at 3:08 PM John Bradley <ve7jtb@ve7jtb.com> wrote:

Yes the=C2=A0logical resource can be provided by "scope"=

=C2=A0

Some implementations like Ping and Auth0 have been adding another parameter "aud" t= o identify the logical resource and then using scopes to define permissions to the resource.

=C2=A0

Fortunately, we are using a different=C2=A0parameter name so not stepping on that..

=C2=A0

We could go back and try to add text explaining the difference, but we are quite late in the process.=C2= =A0

=C2=A0

I agree that a logical resource parameter=C2=A0ma= y be helpful, but perhaps it should be a separate draft.

=C2=A0

John B.

=C2=A0

On Fri, Jan 18, 2019 at 4:38 PM Richard Backman, Annabelle <richanna@amazon.com> wrote:

Doesn=E2=80=99t the =E2=80=9Cscop= e=E2=80=9D parameter already provide a means of specifying a logical identifier?

=C2=A0

--=C2=A0

Annabelle Richard Backman

AWS Identity

=C2=A0

=C2=A0

From: OAuth <oauth-bounces@ietf.org> on behalf of Vittorio Bertocci <Vittorio=3D40auth0.com@= dmarc.ietf.org>
Date: Frid= ay, January 18, 2019 at 5:47 AM
To: John Bradley <ve7jtb@ve7jtb.com>=
Cc: IETF oauth WG <oauth@ietf.org>
Subject: R= e: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-= resource-indicators-01

=C2=A0

Thanks John for the background.

I agree that from the client validation PoV, having an identifier corresponding to a location makes things more solid.

That said: the use of logical identifiers is widespread, as it has significant practical advantages (think of services that assign generated hosting URLs only at deployment time, or services that are somehow grouped under the same logical audience across regions/environme= nt/deployments). People won't stop using logical identifiers, because they often have no alternative (generating new audiences on the fly at the AS every time you do a deployment and get assigned a new URL can be unfeasible). Leaving a widely used approach as exercise to the reader seems a disservice to the community, given that this might lead to vendors (for example Microsoft and Auth0) keeping their own proprietary parameters, or developers misusing the ones in place; would make it hard for SDK developers to provide libraries that work out of the box with different ASes; and so on.

Would it be feasible to add such parameter directly in this spec? That would eliminate the interop issues, and also gives us a chance to fully warn people about the security shortcomings of choosing that approach.

=C2=A0

=C2=A0

=C2=A0

On Thu, Jan 17, 2019 at 4:32 PM John Bradley <ve7jtb@ve7jtb.com> wrote:

We have discussed this.

Audiences can certainly be logical identifiers.=C2= =A0=C2=A0

This however is a more specific location.=C2=A0 T= he AS is free to map the location into some abstract audience in the AT.

From a security point of view once the client starts asking for logical resources it can be tricked into asking for the wrong one as a bad resource can always lie about what logical resource it is.

If we were to change it, how a client would validate it becomes challenging to impossible.

The AS is free to do whatever mapping of locations to identifiers it needs for access tokens.

Some implementations may want to keep additional parameters like logical audience, but that should be separate from resource.

John B.

On 1/17/2019 9:56 AM, Rifaat Shekh-Yusef wrote:

Hi Vittorio,

=C2=A0

The text you quoted is copied form the abstract of the draft itself.

=C2=A0

=C2=A0

Authors,

=C2=A0

Should the draft be updated to cover the logical identifier case?

=C2=A0

Regards,

=C2=A0Rifaat

=C2=A0

=C2=A0

On Thu, Jan 17, 2019 at 8:19 AM Vittorio Bertocci <Vittorio@auth0.com&= gt; wrote:

Hi Rifaat,

one detail. The tech summary says

=C2=A0

=
An extension to the OAuth 2.0 Authorization Framework defining request 
=
parameters that enable a client to explicitly signal to an authorization se=
rver 
=
about the location of the protected resource(s) to which it is reque=
sting 
=
access.

But at least in the Microsoft implementation, the resource identifier doesn't have to be a network addressable URL (and if it is, it doesn'= t strictly need to match the actual resource location). It can be a logical identifier, tho using the actual resource location there has benefits (domain ownership check, prevention of token forwarding etc).

Same for Auth0, the audience parameter is a logical identifier rather than a location.

=C2=A0

=C2=A0

=C2=A0

On Wed, Jan 16, 2019 at 6:32 PM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:

All,

=C2=A0

The following is the first shepherd write-up for the=C2=A0draft-ie= tf-oauth-resource-indicators-01 document.

=C2=A0

Please, take a look and let=C2=A0me know if I missed anything.

=C2=A0

Regards,

=C2=A0Rifaat

=C2=A0

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.o= rg/mailman/listinfo/oauth

=C2=A0

____________=
___________________________________
OAuth mailin=
g list
OAuth@ietf.org
https://www.i=
etf..org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.o= rg/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.o= rg/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.o= rg/mailman/listinfo/oauth


CONFIDENTIA= LITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.=C2=A0 If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.


CONFIDENTIA= LITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..=C2= =A0 If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.o= rg/mailman/listinfo/oauth


CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited...=C2= =A0 If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.= _______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.o= rg/mailman/listinfo/oauth

=C2=A0

____________=
___________________________________
OAuth mailin=
g list
OAuth@ietf.org
https://www.i=
etf.org/mailman/listinfo/oauth

= _______________________________________________
OAuth mailing list OAuth@ietf.org
https://www.ietf.org/m= ailman/listinfo/oauth

=C2= =A0

______________________=
_________________________
OAuth mailing list
                                                
OAuth@ietf.org

                                                
https://www.ietf..org/m=
ailman/listinfo/oauth

=C2=A0=

________= _______________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/l= istinfo/oauth

____________________= ___________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oaut= h


CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..=C2=A0 If you hav= e received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you. 

__________________________________________=
_____
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth=

=C2=A0


CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.=C2=A0 If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.


<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --0000000000001599c705808d0199-- From nobody Mon Jan 28 21:07:17 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74B6C128AFB for ; Mon, 28 Jan 2019 21:07:16 -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 KeHVK3gQnD2J for ; Mon, 28 Jan 2019 21:07:14 -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 B840B129B88 for ; Mon, 28 Jan 2019 21:07:13 -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; Mon, 28 Jan 2019 21:07:05 -0800 From: Jim Schaad To: "'Panos Kampanakis (pkampana)'" , References: <011501d4ac3d$ab2b9650$0182c2f0$@augustcellars.com> <82341b1eb21f4eccb00741d78964f853@XCH-ALN-010.cisco.com> <015e01d4b751$9b0d2170$d1276450$@augustcellars.com> In-Reply-To: <015e01d4b751$9b0d2170$d1276450$@augustcellars.com> Date: Mon, 28 Jan 2019 21:07:03 -0800 Message-ID: <017d01d4b790$7abfc9b0$703f5d10$@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: AQF61PvzwzMWmD5ENcCTB9smhJ8GWwKQrXUGAsr28UKmTpmtgA== Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Ace] FW: WGLC comments draft-ietf-ace-coap-est-07 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, 29 Jan 2019 05:07:17 -0000 > -----Original Message----- > From: Ace On Behalf Of Jim Schaad > Sent: Monday, January 28, 2019 1:37 PM > To: 'Panos Kampanakis (pkampana)' ; ace@ietf.org > Subject: Re: [Ace] FW: WGLC comments draft-ietf-ace-coap-est-07 > > Clipping out things which are not issues: > > > > -----Original Message----- > > From: Ace On Behalf Of Panos Kampanakis > > (pkampana) > > Sent: Friday, January 18, 2019 12:59 PM > > To: Jim Schaad ; ace@ietf.org > > Subject: Re: [Ace] FW: WGLC comments draft-ietf-ace-coap-est-07 > > > > Hi Jim, > > > > Again, thank you for your thorough reviews. We addressed all of them. > > The new version of the draft is at > > https://github.com/SanKumar2015/EST- > > coaps/blob/master/draft-ietf-ace-coap-est.txt > > > > For a more easily consumable content, your latest feedback was tracked > > and addressed here https://github.com/SanKumar2015/EST- > > coaps/issues?utf8=%E2%9C%93&q=is%3Aissue+draft-ietf-ace-coap-est-07 > > > > I also lay out the changes below: > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > - About the persistent DTLS connections (Sect 7), the last two > > paragraphs > of > > section 7 explain why in some cases DTLS connections need to stay open > > for a limited amount of time. They also point to the Section 11.1 > > about the caveats of a persistent connection and the implicit DB. I do > > not think it > is up to > > this draft to tell the client that he should use the new cert after an > > enrollment. The old cert might still be perfectly valid or the new > > cert > may be > > generated for a non DTLS client auth use. So, I don't think we need to > state in > > this draft that the new cert needs to be used in new DTLS connections. > > > > - About the DTLS connections (Sec 11.1), We have usecases where a > > client does not want to spend the resources, time, performance > > implications to do > > 3-5 DTLS connections back to back in order to update its trustanchor > > and > do > > its enrollments for multiple certs. In this cases, explained in > > section 7 > last > > paragraphs will keep a persistent DTLS connection. That is what > > section > 11.1 is > > trying to explain. Please keep in mind that in there we state that it > > is RECOMMENDED for the client to start using the new explicit DB right > > after the cacerts request. We just add the MAY keep the authenticated > > with implicit DB DTLS connection open in some cases, but then he MUST > > use the new DB starting for the next DTLS connection. > > > > So, I think our language in Sections 7 and 11.1 suffices when talking > about > > persistent TLS connections. > > Any time that the set of trust anchors is changed, you have also changed the > set of things that you are going to trust. If you remove the trust anchor for > the current connection, or restrict it in some manner, you may no longer > have any trust in that connection. This is the worry that I have. I completely > agree that doing multiple certificate requests (not sure why) or a query > about the csr attributes followed by the certificate request is totally > reasonable. > > You say that the client should use the new explicit trust anchors right after > the cacerts request, but if you do not tear down the DTLS connection you are > not doing that. You are still using the old implicit trust anchors. > The MAY in section 11.1 for me is overridden by the previous SHOULD unless > this case is specifically called out in section 7. I cannot understand the logic > that says when you get a certificate a year from now the explicit TAs SHOULD > be used, but it does not matter when you get the first certificate. > > * It does not look from the version on github that you made any changes for > the examples: > > Examples: > > * Section A.1 I don't know what the meaning of Max-Age would be for a GET > request. You may want to remove this just to avoid confusion. > > * Section A.2 - I am unclear about the Content-Format note in this example. > If you are asking for a specific content then the correct option would be > Accept. If you are indicating the content type of the response then you > should probably put a header line in to that effect. > > In the virtual CoAP WG meeting last week we went through in some explicit > detail that both Content-Format and Max-Age have no meaning when > appearing on a request and therefore should not be there. I may be wrong about content-format, but if there is only one choice I am not sure that it is needed. > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace From nobody Mon Jan 28 21:42:08 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56984130EA4 for ; Mon, 28 Jan 2019 21:42:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -19.054 X-Spam-Level: X-Spam-Status: No, score=-19.054 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, 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 SSLNWgCF2b3B for ; Mon, 28 Jan 2019 21:42:04 -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 D7C0D130EDE for ; Mon, 28 Jan 2019 21:42:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6021; q=dns/txt; s=iport; t=1548740523; x=1549950123; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=8hGHaK8tSjYRu2ilaY5KKwigzZs8yM67A4nR64AfK68=; b=U3pMAfn9pJS0nqY8HFFcuRtSSx2kduJeoiIPqCYzS7aHUJ+jhFr1ptkM q+hFCouZEmXi48jDCCvVzir1/efxuLqC2ryWCMRlLHoHACqBYBEjQriza Ge2469m8JKiLl8p2xs+hVbjJYC6WAet+sHtcBrgsJeoGqgZxSW3IUC7t8 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAABD509c/4YNJK1bCRkBAQEBAQE?= =?us-ascii?q?BAQEBAQEHAQEBAQEBgVEEAQEBAQELAYFVBSlngQMnCowSi3iCDZgJgXsLAQE?= =?us-ascii?q?fhE0CgyYiNAkNAQMBAQIBAQJtHAyFSgEBAQECATpEBwQCAQgOAwQBARoCAxA?= =?us-ascii?q?yHQgBAQQBEgiDG4F5CA+rS4otBYxBF4FAP4ERgxKDHgEBgTcDEXEDhQICiUq?= =?us-ascii?q?YfwkChyyDXoccIIFqhTeLDIoYgQmDZTqLagIRFIEnHziBVnAVgyeDPgEOgjy?= =?us-ascii?q?KU0ExjEKBLoEfAQE?= X-IronPort-AV: E=Sophos;i="5.56,536,1539648000"; d="scan'208";a="513655185" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 Jan 2019 05:42:00 +0000 Received: from XCH-RCD-007.cisco.com (xch-rcd-007.cisco.com [173.37.102.17]) by alln-core-12.cisco.com (8.15.2/8.15.2) with ESMTPS id x0T5g0CF025750 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 29 Jan 2019 05:42:00 GMT Received: from xch-aln-010.cisco.com (173.36.7.20) by XCH-RCD-007.cisco.com (173.37.102.17) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 28 Jan 2019 23:41:59 -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; Mon, 28 Jan 2019 23:41:59 -0600 From: "Panos Kampanakis (pkampana)" To: Jim Schaad , "ace@ietf.org" Thread-Topic: [Ace] FW: WGLC comments draft-ietf-ace-coap-est-07 Thread-Index: AdSrtk3M3NcfgQ45QNualt2l/rHBKAAh1EAwAMs/eJACBlGeAAAKRt0w Date: Tue, 29 Jan 2019 05:41:59 +0000 Message-ID: References: <011501d4ac3d$ab2b9650$0182c2f0$@augustcellars.com> <82341b1eb21f4eccb00741d78964f853@XCH-ALN-010.cisco.com> <015e01d4b751$9b0d2170$d1276450$@augustcellars.com> In-Reply-To: <015e01d4b751$9b0d2170$d1276450$@augustcellars.com> 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.179.164] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.37.102.17, xch-rcd-007.cisco.com X-Outbound-Node: alln-core-12.cisco.com Archived-At: Subject: Re: [Ace] FW: WGLC comments draft-ietf-ace-coap-est-07 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, 29 Jan 2019 05:42:07 -0000 Thanks Jim=20 > You say that the client should use the new explicit trust anchors right a= fter the cacerts request, but if you do not tear down the DTLS connection y= ou are not doing that. You are still using the old implicit trust anchors.= The MAY in section 11.1 for me is overridden by the previous SHOULD unless= this case is specifically called out in section 7. I cannot understand th= e logic that says when you get a certificate a year from now the explicit T= As SHOULD be used, but it does not matter when you get the first certificat= e. In the draft we want to say that when you get the cacerts response start us= ing those as your explicit trust anchor. But we also want to say that if yo= u pipeline EST-coaps messages in the same connection then you MAY keep the = DTLS connection open. That has implications on the trust anchor if one of t= he EST-coaps requests included a cacerts request. I am thinking that in ord= er to make it clearer we can add text to say that "After a cacerts you are = expected to use the new trust anchor. If pipelining is used you MAY keep th= e connection open, but the client SHOULD still authenticate the server iden= tity received during the DTLS handshake against the new trust anchor receiv= e in response to a cacerts in the same connection. " What do you think? I o= pen to other text suggestion to convey the point as well.=20 About the Examples we will address the Max-Age and Content Format in the ex= amples. I created new github issues for those. Panos -----Original Message----- From: Jim Schaad =20 Sent: Monday, January 28, 2019 4:37 PM To: Panos Kampanakis (pkampana) ; ace@ietf.org Subject: RE: [Ace] FW: WGLC comments draft-ietf-ace-coap-est-07 Clipping out things which are not issues: > -----Original Message----- > From: Ace On Behalf Of Panos Kampanakis > (pkampana) > Sent: Friday, January 18, 2019 12:59 PM > To: Jim Schaad ; ace@ietf.org > Subject: Re: [Ace] FW: WGLC comments draft-ietf-ace-coap-est-07 >=20 > Hi Jim, >=20 > Again, thank you for your thorough reviews. We addressed all of them.=20 > The new version of the draft is at=20 > https://github.com/SanKumar2015/EST- > coaps/blob/master/draft-ietf-ace-coap-est.txt >=20 > For a more easily consumable content, your latest feedback was tracked=20 > and addressed here https://github.com/SanKumar2015/EST- > coaps/issues?utf8=3D%E2%9C%93&q=3Dis%3Aissue+draft-ietf-ace-coap-est-07 >=20 > I also lay out the changes below: >=20 > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > - About the persistent DTLS connections (Sect 7), the last two=20 > paragraphs of > section 7 explain why in some cases DTLS connections need to stay open=20 > for a limited amount of time. They also point to the Section 11.1=20 > about the caveats of a persistent connection and the implicit DB. I do=20 > not think it is up to > this draft to tell the client that he should use the new cert after an=20 > enrollment. The old cert might still be perfectly valid or the new=20 > cert may be > generated for a non DTLS client auth use. So, I don't think we need to state in > this draft that the new cert needs to be used in new DTLS connections. >=20 > - About the DTLS connections (Sec 11.1), We have usecases where a=20 > client does not want to spend the resources, time, performance=20 > implications to do > 3-5 DTLS connections back to back in order to update its trustanchor=20 > and do > its enrollments for multiple certs. In this cases, explained in=20 > section 7 last > paragraphs will keep a persistent DTLS connection. That is what=20 > section 11.1 is > trying to explain. Please keep in mind that in there we state that it=20 > is RECOMMENDED for the client to start using the new explicit DB right=20 > after the cacerts request. We just add the MAY keep the authenticated=20 > with implicit DB DTLS connection open in some cases, but then he MUST=20 > use the new DB starting for the next DTLS connection. >=20 > So, I think our language in Sections 7 and 11.1 suffices when talking about > persistent TLS connections. Any time that the set of trust anchors is changed, you have also changed th= e set of things that you are going to trust. If you remove the trust ancho= r for the current connection, or restrict it in some manner, you may no lon= ger have any trust in that connection. This is the worry that I have. I c= ompletely agree that doing multiple certificate requests (not sure why) or = a query about the csr attributes followed by the certificate request is tot= ally reasonable. =20 You say that the client should use the new explicit trust anchors right aft= er the cacerts request, but if you do not tear down the DTLS connection you= are not doing that. You are still using the old implicit trust anchors. The MAY in section 11.1 for me is overridden by the previous SHOULD unless = this case is specifically called out in section 7. I cannot understand the= logic that says when you get a certificate a year from now the explicit TA= s SHOULD be used, but it does not matter when you get the first certificate= . * It does not look from the version on github that you made any changes fo= r the examples: Examples: * Section A.1 I don't know what the meaning of Max-Age would be for a GET = request. You may want to remove this just to avoid confusion. * Section A.2 - I am unclear about the Content-Format note in this example. If you are asking for a specific content then the correct option would be A= ccept. If you are indicating the content type of the response then you sho= uld probably put a header line in to that effect. In the virtual CoAP WG meeting last week we went through in some explicit d= etail that both Content-Format and Max-Age have no meaning when appearing o= n a request and therefore should not be there. From nobody Mon Jan 28 21:57:51 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79157130EF3 for ; Mon, 28 Jan 2019 21:57:50 -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 rGYj8ILHvyk4 for ; Mon, 28 Jan 2019 21:57:48 -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 4AABD130EA4 for ; Mon, 28 Jan 2019 21:57:48 -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; Mon, 28 Jan 2019 21:57:41 -0800 From: Jim Schaad To: "'Panos Kampanakis (pkampana)'" , References: <011501d4ac3d$ab2b9650$0182c2f0$@augustcellars.com> <82341b1eb21f4eccb00741d78964f853@XCH-ALN-010.cisco.com> <015e01d4b751$9b0d2170$d1276450$@augustcellars.com> In-Reply-To: Date: Mon, 28 Jan 2019 21:57:39 -0800 Message-ID: <018101d4b797$8c6e71a0$a54b54e0$@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: AQF61PvzwzMWmD5ENcCTB9smhJ8GWwKQrXUGAsr28UIBp2jRMqZBbJPQ Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Ace] FW: WGLC comments draft-ietf-ace-coap-est-07 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, 29 Jan 2019 05:57:50 -0000 Yes that is the essence of what I am looking for in terms of dealing with a new trust point. Jim > -----Original Message----- > From: Panos Kampanakis (pkampana) > Sent: Monday, January 28, 2019 9:42 PM > To: Jim Schaad ; ace@ietf.org > Subject: RE: [Ace] FW: WGLC comments draft-ietf-ace-coap-est-07 > > Thanks Jim > > > You say that the client should use the new explicit trust anchors right after > the cacerts request, but if you do not tear down the DTLS connection you are > not doing that. You are still using the old implicit trust anchors. The MAY in > section 11.1 for me is overridden by the previous SHOULD unless this case is > specifically called out in section 7. I cannot understand the logic that says > when you get a certificate a year from now the explicit TAs SHOULD be used, > but it does not matter when you get the first certificate. > > In the draft we want to say that when you get the cacerts response start > using those as your explicit trust anchor. But we also want to say that if you > pipeline EST-coaps messages in the same connection then you MAY keep the > DTLS connection open. That has implications on the trust anchor if one of the > EST-coaps requests included a cacerts request. I am thinking that in order to > make it clearer we can add text to say that "After a cacerts you are expected > to use the new trust anchor. If pipelining is used you MAY keep the > connection open, but the client SHOULD still authenticate the server identity > received during the DTLS handshake against the new trust anchor receive in > response to a cacerts in the same connection. " What do you think? I open to > other text suggestion to convey the point as well. > > About the Examples we will address the Max-Age and Content Format in the > examples. I created new github issues for those. > > Panos > > > > -----Original Message----- > From: Jim Schaad > Sent: Monday, January 28, 2019 4:37 PM > To: Panos Kampanakis (pkampana) ; ace@ietf.org > Subject: RE: [Ace] FW: WGLC comments draft-ietf-ace-coap-est-07 > > Clipping out things which are not issues: > > > > -----Original Message----- > > From: Ace On Behalf Of Panos Kampanakis > > (pkampana) > > Sent: Friday, January 18, 2019 12:59 PM > > To: Jim Schaad ; ace@ietf.org > > Subject: Re: [Ace] FW: WGLC comments draft-ietf-ace-coap-est-07 > > > > Hi Jim, > > > > Again, thank you for your thorough reviews. We addressed all of them. > > The new version of the draft is at > > https://github.com/SanKumar2015/EST- > > coaps/blob/master/draft-ietf-ace-coap-est.txt > > > > For a more easily consumable content, your latest feedback was tracked > > and addressed here https://github.com/SanKumar2015/EST- > > coaps/issues?utf8=%E2%9C%93&q=is%3Aissue+draft-ietf-ace-coap-est-07 > > > > I also lay out the changes below: > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > - About the persistent DTLS connections (Sect 7), the last two > > paragraphs > of > > section 7 explain why in some cases DTLS connections need to stay open > > for a limited amount of time. They also point to the Section 11.1 > > about the caveats of a persistent connection and the implicit DB. I do > > not think it > is up to > > this draft to tell the client that he should use the new cert after an > > enrollment. The old cert might still be perfectly valid or the new > > cert > may be > > generated for a non DTLS client auth use. So, I don't think we need to > state in > > this draft that the new cert needs to be used in new DTLS connections. > > > > - About the DTLS connections (Sec 11.1), We have usecases where a > > client does not want to spend the resources, time, performance > > implications to do > > 3-5 DTLS connections back to back in order to update its trustanchor > > and > do > > its enrollments for multiple certs. In this cases, explained in > > section 7 > last > > paragraphs will keep a persistent DTLS connection. That is what > > section > 11.1 is > > trying to explain. Please keep in mind that in there we state that it > > is RECOMMENDED for the client to start using the new explicit DB right > > after the cacerts request. We just add the MAY keep the authenticated > > with implicit DB DTLS connection open in some cases, but then he MUST > > use the new DB starting for the next DTLS connection. > > > > So, I think our language in Sections 7 and 11.1 suffices when talking > about > > persistent TLS connections. > > Any time that the set of trust anchors is changed, you have also changed the > set of things that you are going to trust. If you remove the trust anchor for > the current connection, or restrict it in some manner, you may no longer > have any trust in that connection. This is the worry that I have. I completely > agree that doing multiple certificate requests (not sure why) or a query > about the csr attributes followed by the certificate request is totally > reasonable. > > You say that the client should use the new explicit trust anchors right after > the cacerts request, but if you do not tear down the DTLS connection you are > not doing that. You are still using the old implicit trust anchors. > The MAY in section 11.1 for me is overridden by the previous SHOULD unless > this case is specifically called out in section 7. I cannot understand the logic > that says when you get a certificate a year from now the explicit TAs SHOULD > be used, but it does not matter when you get the first certificate. > > * It does not look from the version on github that you made any changes for > the examples: > > Examples: > > * Section A.1 I don't know what the meaning of Max-Age would be for a GET > request. You may want to remove this just to avoid confusion. > > * Section A.2 - I am unclear about the Content-Format note in this example. > If you are asking for a specific content then the correct option would be > Accept. If you are indicating the content type of the response then you > should probably put a header line in to that effect. > > In the virtual CoAP WG meeting last week we went through in some explicit > detail that both Content-Format and Max-Age have no meaning when > appearing on a request and therefore should not be there. From nobody Mon Jan 28 21:59:17 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E82D130EA4 for ; Mon, 28 Jan 2019 21:59:15 -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 YYJAoXjcqRfz for ; Mon, 28 Jan 2019 21:59:13 -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 4C16C130EF5 for ; Mon, 28 Jan 2019 21:59:13 -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; Mon, 28 Jan 2019 21:59:08 -0800 From: Jim Schaad To: References: <003701d4abbe$0cfab580$26f02080$@augustcellars.com> In-Reply-To: <003701d4abbe$0cfab580$26f02080$@augustcellars.com> Date: Mon, 28 Jan 2019 21:59:06 -0800 Message-ID: <018201d4b797$bfecd120$3fc67360$@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: AQEe4BfBS1If46evJWTJJBMjZisWi6cxbwzQ Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Ace] WGLC for draft-ietf-ace-coap-est 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, 29 Jan 2019 05:59:15 -0000 This message concludes the last call for this document. The authors are requested to create and post a new document addressing the issues that were raised. Jim > -----Original Message----- > From: Ace On Behalf Of Jim Schaad > Sent: Sunday, January 13, 2019 8:03 PM > To: ace@ietf.org > Subject: [Ace] WGLC for draft-ietf-ace-coap-est > > The chairs believe that the EST over CoAP draft is nearing the point it should > be sent to the IESG for publication. We are therefore going to have a > Working Group Last Call on this document. WGLC will until 29th of this > month. Please review the document and send comments both positive and > negative to the list about its state. > > Jim & Roman > > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace From nobody Mon Jan 28 23:56:32 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55477130F29; Mon, 28 Jan 2019 23:56:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.043 X-Spam-Level: X-Spam-Status: No, score=-2.043 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, 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 RO37zxhfISDC; Mon, 28 Jan 2019 23:56:21 -0800 (PST) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40085.outbound.protection.outlook.com [40.107.4.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A583130F26; Mon, 28 Jan 2019 23:56:21 -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=LOXZN/bv5QEEHtF/j7ZEY6i7d2sWoRwJ+HgTEH3flnw=; b=BLDIGLuL+L2dQpBFDoG6B6DdgnglzlPgZ5ObZlI0ia0ZD6cV0fd3zwhDU7bQ7KIELCe799whmrbOGQTC0v5SLM5jy/pQg0PcCkh22RV+/RgidjGD7Do7UgKoegWJEZqZ1XsL9W7oxrP606GHHjmr7VBmglvr0qRGtcq3vS1JuIw= Received: from HE1P189CA0014.EURP189.PROD.OUTLOOK.COM (2603:10a6:7:53::27) by AM5P18901MB0098.EURP189.PROD.OUTLOOK.COM (2603:10a6:203:78::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1558.16; Tue, 29 Jan 2019 07:56:18 +0000 Received: from HE1EUR02FT022.eop-EUR02.prod.protection.outlook.com (2a01:111:f400:7e05::206) by HE1P189CA0014.outlook.office365.com (2603:10a6:7:53::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1580.16 via Frontend Transport; Tue, 29 Jan 2019 07:56:18 +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 HE1EUR02FT022.mail.protection.outlook.com (10.152.10.78) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.20.1580.10 via Frontend Transport; Tue, 29 Jan 2019 07:56:18 +0000 Received: from [10.112.134.122] (10.100.0.158) by sp-mail-2.sp.se (10.100.0.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1531.3; Tue, 29 Jan 2019 08:56:16 +0100 To: , References: <4eb4ea45-c3f2-7991-9544-612d055809ba@ve7jtb.com> <199fa6bd-8103-b1b3-12a3-08b5e3aad925@aol.com> <55a0362e-e588-bce5-f65f-856a1e21e88e@aol.com> <65a8e83e-c72f-bbf5-77fd-ea8540b7ddc3@aol.com> From: Ludwig Seitz Message-ID: <848e0ab3-f95f-2885-d24e-69925ed7ab1c@ri.se> Date: Tue, 29 Jan 2019 08:56:16 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <65a8e83e-c72f-bbf5-77fd-ea8540b7ddc3@aol.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.100.0.158] X-ClientProxiedBy: sp-mail-2.sp.se (10.100.0.162) To sp-mail-2.sp.se (10.100.0.162) X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:194.218.146.197; IPV:NLI; CTRY:SE; EFV:NLI; SFV:NSPM; SFS:(10009020)(376002)(396003)(346002)(136003)(39860400002)(2980300002)(189003)(199004)(230700001)(7736002)(2906002)(65806001)(68736007)(22746008)(50466002)(14444005)(53546011)(386003)(31696002)(8936002)(126002)(47776003)(65826007)(305945005)(476003)(53936002)(65956001)(229853002)(8676002)(81156014)(450100002)(81166006)(356004)(478600001)(6246003)(3846002)(186003)(16526019)(336012)(446003)(64126003)(93886005)(6116002)(2616005)(104016004)(26005)(16576012)(22756006)(316002)(11346002)(69596002)(77096007)(23676004)(2486003)(31686004)(33896004)(58126008)(36756003)(106466001)(74482002)(86362001)(44832011)(110136005)(76176011)(106002)(97736004)(486006)(40036005)(67846002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM5P18901MB0098; H:mail.ri.se; FPR:; SPF:Pass; LANG:en; PTR:InfoDomainNonexistent; MX:1; A:1; X-Microsoft-Exchange-Diagnostics: 1; HE1EUR02FT022; 1:iOWZEkDub4vodtgOVJvTQ28LSIldCerqWWDByBAUq8Njw4OWrdL5AiwiSxD/xRfgKqCTonvKYxo/2XPepnXJKOPpa2RLQQJYuUVJqrg8UbAtfnZ5COpKyAcyBQNvpTYBrcZu3wG/+BmhNI4rgzITsu8Wy/ciCKvGy1z6gSy9Ov8= X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: f5f5c850-bc49-4e23-490f-08d685bf4033 X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605077)(4608076)(4709027)(2017052603328)(7153060)(7193020); SRVR:AM5P18901MB0098; X-Microsoft-Exchange-Diagnostics: 1; AM5P18901MB0098; 3:SNqhRoIZuXiooFmSz9iZqhX2offIfr2YwU6GFDSjOSKtWJQoeQrcU1YGYW34e/BGjelyaiPtY5KdbHO3Y4YlS3whMwW3iwfqYWvj9Jx2Mo8NHelt6qcSTijoWLAXm9fubRRM2Tk7hRVpIzF/z1yv4mYZxzs5bO5S0MiinYVj1Z76gbjvrkbmvVeZfuuH2h89NkXQGYQ4fIv0QVt+vI18+JGZ9ZWlrCqU0GLDUoPaNkiYUNVbmQns7cYuR7QQKuFphSAoLjd8qvDw6q8OjGKDI+0+0poYmqxXsNdhdcvASa+yr/sa0DHDSPeMu4fvy0Uq8andoJO1zXGw//3nl8X96z5KHkwPCxRDCADBiCblMT0DQFVy5yYZnVqk+xlnab+/; 25:A35rd7fGrdiozpIU4M3I8zuGB3CxwrwKxGJOxOFCvRhK8YtRw7koCeWuNjXRM9qT39YPSLZnIdOH+GXnqUJcoeAJvh1MsZzM6K2Q3F0rsgLEydl9QU6Y5qQxz6LIj2m7P70fJJGJR6YUV8Z+v0HHFufg2099S1upfndj8tkSp8xsNn/3iyWoLHNeCkMf34DA+OJWLToTc+M4U4aW8CsuOj/lDZWMJmqjG6ZjBr+V1/hOwCqodfk/A+kLhxGVnho9npKRM12fv+RVc8DAJzuRxuMvvHhvQr2kGtvncmbJEhuB8E3HPiauVoEUnyRStwx3j/15MH0Er8X2QtlWt+wRIg== X-MS-TrafficTypeDiagnostic: AM5P18901MB0098: X-Microsoft-Exchange-Diagnostics: 1; AM5P18901MB0098; 31:bU3k2/jyRh7tKtHLUlZEj+/ApRwUMGzNsKNPc/jABHPR4MB6TPwFfEMOnnG9OqD4Up40rikpgfTTLto3XzzC9lNpY8xKC6+JBXZ9l3XMV/Q0XzZCXSA8UT0ABDhuJt/cYwMJO2JLk33x/vi5pGG0rJ1kHhfJZD27pbhX0Fy1ejIHORiQptlvFGACUkjCHgWzslILyTyXJP76e6Wufl3qBatDzd7VE5iYmYT/dGM+MuM=; 20:HZVbTnK3kZk80XyXOggtAhXvmqxfCwsDsUPXWnLI82TDhN5zKJzaJqQbTdrBZVJTrK8eGGnk7B1LOHYvxhDQpFI77qI9P2xErymFiv+tM2qhzDkjJy37aIGbbzTielfUVnCVoXELxa148jV9AhWSnfXajl23+6wzwG1QtnQysdPkZL6gyB+2ICHltn8hzI5ytYJOHca4WsvEh8p9NU/NJb3Dqmf/F+9OCL80TcQEebcRhhsyv4u0ZKQmc10JvsEl; 4:y9eUTKMLeUNn9gbRo2L7CPMK/zp9U75Czn8mqtvVMao2Z2LdZAmRcO/UHevdTdJCtaCBD8aiFLqxkk3wJVSd156XYiiiPjQ5Vsv08VD7xS8kU9zjFzvsgtpCTde3lmcKZVwg1Qr8hZKMhJHMvqhpbPvWfWxjawUqOULFWK/AmVSleeSbmfTdy18bO07puu3dD3AWiaunf8Heby8TjoVERHTSJAfMidl+N5QJuN4aZbwi1jnMaEOERPOe5Sx1D91z2UbQqM8wRPsJkThk7B/QjhXDnCLSWUDvv8eYpLcGKRs9687wZI4grBz6XlG16o1+ X-Microsoft-Antispam-PRVS: X-Forefront-PRVS: 093290AD39 X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtBTTVQMTg5MDFNQjAwOTg7MjM6TU1OLzFWL3dpUkRiUEF3aDg2RTlKdS9V?= =?utf-8?B?ZWxCRE5pa3U5aEpoT3hpakhmMnQycldVQ2ZTS3NhSW4rQm4ydEQxOUtRTGxj?= =?utf-8?B?NFViZ3l2cGJGQkw0Ukw0SnNMK0paeWsvWlZ6TE9zV2hkSUtKNU4yQi84bnlj?= =?utf-8?B?L3dqMDJzVFV5K0M1SE5lekoyUmJ2S3g0VDQxcXljbTNvL1dGU1FHRVNxQ1Fk?= =?utf-8?B?cTMrV0ZscVdjUXo5SmozOXVJMXZsdzR4MURjcS9lMHJNTVFtb0o5N3A5OWNt?= =?utf-8?B?WEM2NHIvRHJSc2YxcXFFc1RRc25IY0o1VUhsV090N3VhQWl2YnBjcm90cm05?= =?utf-8?B?Z1ZnRGJMUDRZVXczcnNUb2s3ZlJ4N0l2SnZpaGE5Wmp3ZlRFZW85SlhqU21a?= =?utf-8?B?T0tDK0lrbEV5TzBvWVorM2V4TzhUb1Q3MVJ6ai9XQlBmYnlFWVFFdzB6clJV?= =?utf-8?B?NEErdFRnZk5UcXpZMlJmOEhBMXVTK1ZKMDIrUG1vZDZmeWZidDhqWjY1QXYx?= =?utf-8?B?YmRsbGE1ZDRMeFo1ZnpNMzh1bldQM093citYWTBMM3VxbHZ3Y0w0RmN5cWgr?= =?utf-8?B?VkNGcDMyWURiMDFhdnAzV1lPc3BjN043QjMzSVpaOVJFWkwzQXdqQk4xQjkv?= =?utf-8?B?aitCenBBZCtmQ0kybE1JdVN4d2h5VHZzWm5HWlkwT2Q0OGJzRWN1NXIrMGRD?= =?utf-8?B?REl5WC9lK1I0QmV6dmMxa2t1QlZDYVErYldmbndqRWFLRW5KVHh4ZkNwQjVp?= =?utf-8?B?blFCTVBSRS84b1VIbmxOUkFCNW1ON1VCTkVvVEtFQ0p6bVZ2T2lFSUhwdVUy?= =?utf-8?B?WFljSTdZbGNwQTBnaDN6VUpmNWc0NC9PSnNJdG1ud1lqSlVBTWtFdW02TGlC?= =?utf-8?B?bGI4a3kxVFJJOEtvN3dUSjQzQUJSdjJkTVNtdUxSWGVUZ3NjY0FtV1ZOc0lv?= =?utf-8?B?N3ZMbXBlZ1hxMEZEc1NncFdFbHBpODNBT0dycjI5L1FIbVcwK21TdURxc2Y0?= =?utf-8?B?dDJjRGU0UFpJcXJlTklvdzFvZjZncjRYbVloeVFCZTQ0Qjc4bkFabEx3Vjdm?= =?utf-8?B?Mjl5OXJjS0w0Wm9kNWJoLzZyU1l0VkY4SlpsMGNDc0NQN0xlZS9YSUREZFpS?= =?utf-8?B?TGUrcWdhZG5uNkdwU2NtN2J4Y3lzOFVmNHI5WjRBTXBLUHY1eVE1OTlXN29E?= =?utf-8?B?bytTbmVZU2J2UXNMUGFnQnZoNCs5M3lyWnRRUlNkL1E4d29XY3hEQjVEMjhV?= =?utf-8?B?V0w1Tjk4bkU4czNOVUU4ZFFyU3d6elo4NVR0Mzlldnpsb0ZWVG1idTFLd3By?= =?utf-8?B?Sk0rZC80ZnRLeUw3MGlSYk5Sa0pLMVRDcHNFYldwMFNHeGwzazN2OW1iU0Rl?= =?utf-8?B?cmlDaTRJOVRvTUpvRDllNXkvWEFSRFNPY0dkZDJYVHFRTElaRzhsaTIzNnBK?= =?utf-8?B?L3N5ekREMzF2UW95eWVBclMwRGFRNHp5VXRnVjZvZHBVMHRaSXJsV1pueDg2?= =?utf-8?B?dFBQcUhKbE1qTWdwU2RxTVNwNUFZQmZZUldiNm16NmJVWWRCaVB5eXZlRVhs?= =?utf-8?B?Nmw0UzN5Ulowb2dMMXpJTk01WkVLV1ErSFdJS3hHUmpkVXlaUnVIbW5YZGsz?= =?utf-8?B?ZW91L285N1l0NEI3anFMaXlBNWt2c2d2SFZ3OEFYRU42NGRRUTJ4SDBIU2c2?= =?utf-8?B?aTE1V2VPZ3plSXpNcTBoeWlCN1VJcGxacmo2eWUyMldCdGkvVmw4ZXpSd1B1?= =?utf-8?B?Q3oyWDZwOGFieXJUeEtKM1Mrd0NlMTRxQ1BiUnNZK2RYWlBUcjdvUi9SMVNE?= =?utf-8?B?dEd6OWxzeG13ZHoxWk1QcThEcUVXWHBZdFJ0bHlOblFBYUxEaExtT3BScDRO?= =?utf-8?B?Z3RJdUZSQTZ3TFphWkZHV2hmcCs3QzJQQXVwSUFSb3pHektubEFNOWUwZGtU?= =?utf-8?B?Y1hqN20yR0JXZDQ4aGRVbnRkZ1NkeFkrcGlhdkw2MS96aGV1d1RhQUVZOVJO?= =?utf-8?B?bGN0eDQ0enBGb2xldGd3UWF1VXQ4QkZqaXpKeC9vbCtmQ3FqVGovWE1uSmlG?= =?utf-8?Q?c2L3fg=3D?= X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Message-Info: bMtUKpvuYOMjUMZsaAS/xpNL/nt25d8lW2pRhX4cGDL3KJIWnB71yBfOIRrgEzb5nxKQZSygDYJivez7/O13hIjBmXyMDQDU25JQGm2Mf+mmIXoGjb8IofnY5R7rWWab2sveQnZxF6yoJbTKzJrhjrwgGi64jUkPv3hopqxjvKYaj/zG+XCUqM4D8KZDkeWIAlVJfeEoqDHqlm5y8ycP9zBl2uGt0tWCmoO5D89F2+Au2l4Hrvvy6rwCoo0zU3M88P/RFAb1TfUWdQEEJGZaSeqY1hjrNGkuOcdO81vmhecfXlSE4qLXVrCe7wbWFuH89P0oK0ESbEum77SgjXVMcIg9fMeZFifCKtAJTYWPOxkbYcRaHokRpYp/RnDaLc3OiuEnJha5Gq0Yja6oECfMF4utlIM5eWzL66/QCE0KyJY= X-Microsoft-Exchange-Diagnostics: 1; AM5P18901MB0098; 6:UQ7utAAVtRhQGabiRcJiyFsQzaePUH2yE2AYOft8RLMolEIiv3ZVKLGNNZlpt0/mj//Gi8DX6NPxnoQml+ZWBDmDizTtFLydkol+48IsZXvzdXm8VGjVAeXrLGy+Fc4wjwVT24Lii/NnOpLVaZV4QgAE1UP9tvnyIgAD4NF/w7KenMVQJeMAmQw385g/4cMVbhf0k/lnbbtZYL/YeyNsbiqE7MJRfL5fUGpnkRoNRtCtaDwxvzxSjVxjriJcgQfHMXl4ABGoGjkLv1rehg2YenKGzzyn7fL0S4nk3tnEvmr4VbpIH4PmBTp4U+ZqQKfFTVkApjRRgPwkLQFMlkcwGq75KJVmXA0zmsSzLrlzpw8wUSzRB+gP4XXqxcMYyIFlTRJ44R7c87XlbPDozdismOZQnwNY1WX41i/DW3HLXN8x49dImvDeQiKS5TUevmCZCtD5zKVQACzqnthgedH/Aw==; 5:tJ2iMHemLT6ZrYyOQuyo1jPWDtnM21x1BChr7fzjnGmWsFh+adm/rOITPbD7qtLuJMGWSpw2eK5VjEh17/YVO04Zd34qOMTTx8bj8JUPtX8KEcGVXK8/oiAKYN8fg7RexiDi0TfnEwAkNtvkdAjM9pXKRZkmmAWqfToP8hR3YSxQOv4NqgevpMhC7PJaeliwyKIAw8qb6J0ez32pj7/Y6A==; 7:Ogxi7AMmbLxrP+cdZJh87TSuWR4THucFm05moiRSIOJE6w8Dd97kJuoH3K+ZG9MnjQCpgf2ht1asoeWQPjhPMQty+peDY7F/vZF6BVwNNxXWtiI8njsdJCdFfpb2qJumZWB7SXf02iBNKq4BsBnmrg== X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Jan 2019 07:56:18.0653 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: f5f5c850-bc49-4e23-490f-08d685bf4033 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: AM5P18901MB0098 Archived-At: Subject: Re: [Ace] [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resource-indicators-01 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, 29 Jan 2019 07:56:24 -0000 On 28/01/2019 23:12, George Fletcher wrote: > I also don't know that this raises to the level of "concern" but I find > the parameter name of "req_aud" odd. Given that the parameter in the > resource-indicators spec is 'resource' why not use a parameter name of > 'audience'. That said, I have not read the thread on the ACE working > group list so there could be very good reasons for the chosen name:) > > I do think that there is a lot of overlap (in most cases) between > 'resource' and 'audience' and having two parameters that cover a lot of > the same semantics is going to be confusing for developers. When calling > an API at a resource server, the 'audience' and the 'resource' are > pretty equivalent. Maybe in other use cases they are distinctly separate? > To give you all the background of "req_aud" from ACE (sorry for the long text): Originally in ACE we had defined the "aud" parameter for requests to the token endpoint with the semantics that the client was requesting a token for a certain audience (i.e. requesting that the AS copy the "aud" parameter value into the "aud" claim value of the token). We were then told that this collided with a use of "aud" in OAuth, that specifies the intended audience of Authorization Servers (if I remember correctly), so we decided to rename our parameter to "req_aud" for "requested audience". Mike Jones then made us aware of the work on resource indicators, but upon closer examination I found the "resource" parameter to be more limited than the "req_aud", since resource specifically states: "Its value MUST be an absolute URI ... the "resource" parameter URI value is an identifier representing the identity of the resource" My interpretation of this is that "resource" refers to a single resource, which is more constrained than the definition of the "aud" claim from 7519, which uses a StringOrURI value. For example my intent was to use "aud" and "req_aud" for group identifiers ("temperatureSensorGroup4711") and other non-uri strings (hash-of-public-key), which I cannot do with "resource". We therefore decided to keep the "req_aud" parameter in draft-ietf-ace-oauth-params, even though is clearly overlaps with "resource". Any comments and suggestions about that line of reasoning (especially from the OAuth point of view) are very welcome. /Ludwig -- Ludwig Seitz, PhD Security Lab, RISE Phone +46(0)70-349 92 51 From nobody Tue Jan 29 00:59:08 2019 Return-Path: X-Original-To: ace@ietf.org Delivered-To: ace@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 67839130F3C; Tue, 29 Jan 2019 00:59:05 -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.90.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ace@ietf.org Message-ID: <154875234536.7296.15354420648126132765@ietfa.amsl.com> Date: Tue, 29 Jan 2019 00:59:05 -0800 Archived-At: Subject: [Ace] I-D Action: draft-ietf-ace-oauth-params-02.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2019 08:59:06 -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 : Additional OAuth Parameters for Authorization in Constrained Environments (ACE) Author : Ludwig Seitz Filename : draft-ietf-ace-oauth-params-02.txt Pages : 14 Date : 2019-01-29 Abstract: This specification defines new parameters for the OAuth 2.0 token and introspection endpoints when used with the framework for authentication and authorization for constrained environments (ACE). These are used to express the desired audience of a requested access token, the desired proof-of-possession key, the proof-of-possession key that the AS has selected, and the key the RS should use to authenticate to the client. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ace-oauth-params/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ace-oauth-params-02 https://datatracker.ietf.org/doc/html/draft-ietf-ace-oauth-params-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-oauth-params-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jan 29 01:02:25 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7AE0130F44 for ; Tue, 29 Jan 2019 01:02:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.043 X-Spam-Level: X-Spam-Status: No, score=-2.043 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, 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 K-OlvH78fLSU for ; Tue, 29 Jan 2019 01:02:15 -0800 (PST) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10069.outbound.protection.outlook.com [40.107.1.69]) (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 12F38130F3C for ; Tue, 29 Jan 2019 01:02: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=13iLwZ/WyhAprrY7NT9e7kyDCHSD5zN+/Tj3FJhVO6c=; b=Lvhv0jMwzZ/RoEKyOfQO9FuL48npF/iArwxUPEMJE4LddPsSqzVtuKsZQt8llAT4aU9JpnKXikf3804n7C2FrUx+cQMRL5osAmdnwGHZyaA8ewmSsdapfj/d005ZjeNX5qgcwTVyLBYns6oyCwP3RBsVXKU9+8NEYk9iXH0gGuQ= Received: from VI1P18901CA0001.EURP189.PROD.OUTLOOK.COM (2603:10a6:801::11) by VI1P18901MB0112.EURP189.PROD.OUTLOOK.COM (2603:10a6:801:f::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1558.17; Tue, 29 Jan 2019 09:02:12 +0000 Received: from HE1EUR02FT041.eop-EUR02.prod.protection.outlook.com (2a01:111:f400:7e05::201) by VI1P18901CA0001.outlook.office365.com (2603:10a6:801::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1580.16 via Frontend Transport; Tue, 29 Jan 2019 09:02: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 HE1EUR02FT041.mail.protection.outlook.com (10.152.11.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.20.1580.10 via Frontend Transport; Tue, 29 Jan 2019 09:02:12 +0000 Received: from [10.112.134.122] (10.100.0.158) by sp-mail-2.sp.se (10.100.0.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1531.3; Tue, 29 Jan 2019 10:02:12 +0100 References: <154875234561.7296.5731521130320902490.idtracker@ietfa.amsl.com> To: "ace@ietf.org" From: Ludwig Seitz X-Forwarded-Message-Id: <154875234561.7296.5731521130320902490.idtracker@ietfa.amsl.com> Message-ID: Date: Tue, 29 Jan 2019 10:02:11 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <154875234561.7296.5731521130320902490.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.100.0.158] X-ClientProxiedBy: sp-mail-2.sp.se (10.100.0.162) To sp-mail-2.sp.se (10.100.0.162) X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:194.218.146.197; IPV:NLI; CTRY:SE; EFV:NLI; SFV:NSPM; SFS:(10009020)(39860400002)(346002)(376002)(136003)(396003)(2980300002)(189003)(199004)(6306002)(68736007)(22756006)(33896004)(336012)(386003)(230700001)(6116002)(6916009)(64126003)(67846002)(106466001)(69596002)(47776003)(44832011)(446003)(126002)(476003)(2501003)(2486003)(31696002)(76176011)(2616005)(14444005)(65956001)(86362001)(3846002)(65806001)(23676004)(16576012)(486006)(74482002)(316002)(77096007)(26005)(186003)(16526019)(65826007)(106002)(11346002)(58126008)(2351001)(229853002)(5640700003)(2473003)(7736002)(53936002)(305945005)(36756003)(31686004)(15650500001)(22746008)(97736004)(66574012)(81166006)(81156014)(1730700003)(8936002)(2906002)(50466002)(356004)(8676002)(966005)(478600001)(104016004)(40036005); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1P18901MB0112; H:mail.ri.se; FPR:; SPF:Pass; LANG:en; PTR:InfoDomainNonexistent; MX:1; A:1; X-Microsoft-Exchange-Diagnostics: 1; HE1EUR02FT041; 1:86RgzVSiKPAs3FoRhCnKKevlGxWcmq/dwKYzKE4N8l21UMtt5M1alQjC5++Nz61W+xHZagj1ZAjncRr9nUOPU0R5zp00ul4BrwGS6AY4f5WqqHOYMoZG1UKGs/GEuRQWjkPefNwg5AAVobr3SIdhThKiexIAvRsM+utXAj+Joy8= X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 7012ed07-7fa4-4c2c-602f-08d685c8751b X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605077)(4608076)(4709027)(2017052603328)(7153060)(7193020); SRVR:VI1P18901MB0112; X-Microsoft-Exchange-Diagnostics: 1; VI1P18901MB0112; 3:QbrqzeZYjgH3QdNU9ykHGXhA4L7D0S3MV3S7/G2iOSQlk6GXGw4g6JegZFi86zSDIjAluioBH8rbG8Exnc9rua103XrlyUUA5Yx+FpAS0erKsPAZzHEy0Wc+OPPx5aGUquwO1zCU6XF4Iuq/U76sgCVMOEdlgSdsZETIsoA3bYv8AtBWYV0/ahDjp92sRklF9qf+651YxTEDeHj8+wYEONogFfQH+VS7fGnIzfXvFM8KosRXFpTY/eq5wrBDhZEo51S6dTTD5XLMDfa7Nm116FcZYmw7BEDNi6k4BByX9f4kI1O2VvHnjP/LcOQWFGpmh12z3RS69jjJHE28iOlmbGev6E1Qo1WR1UvZVKfKjfFr07S42+3Pyzd0PFXFzlfl; 25:oGzhAGIqRLOCXGKCLWkoQf2Ot862q/9i3cB6UqbuSRcxu75ttMBHxtkyvwJ4uOZBSvmUSqdWQPDvoXKEIaw4zQo8QaiPCq9jDm4nJmwS19qIf3WXuqg4ADmqAtqueflkiBEJyolsbOAgLf9hpM30sU5UhnLmC5X/u7dGUvsNDb1kf9uQvGti2yMVmI6DpcImN7mw2unhcLnIGZlYA8wcSaWQ9bX64mgBlauWvPdleXBt8yRmwhi7TWfdPmOJeqYaBxyDF+Z7BlWJdEkuWV0ArMZi0savdab9GQ9dFAJNkzr2PEtwt5D1q8bi5MAO5MK/Sq+h4RlntjccKqV+fe/bVw== X-MS-TrafficTypeDiagnostic: VI1P18901MB0112: X-Microsoft-Exchange-Diagnostics: 1; VI1P18901MB0112; 31:v9QaCROgfm91+MDFK2hjD2+9FyaPDNZnoEBW9vCustKxfmTn7n4GDAz4h+G1eaScU14tzo8ZYR90dF6oujKrZTNh0BJHCg7x1RNQc7Q4drNYSqf02XF6Vg5Ne4hCQMgnx7rmUoN4BRagUaCgDs+Qb2TLGl0+AHeM46ltWZDQd1xUCcZ06KHzuiKzhVdGax37QCqAlSA0nGELpuElaKGYoomf7lmDHyMuT5FyXm3v19E=; 20:idLFWuLCD7Sl3eD+aS7QAkh2+zCCa5ESqgva6FQPhzG4mnVIR9uHJRPxPEX0gVEd7o6O3HdzntuNteqf87FcPb2/yyVzZucjCrdu21x8vZxPoi10vb5lWAc+AprwG7dXRgUNGOjj5b+cYh8aKw6nUSs4u80qrlucrKcX3D2gB0N2AZaWiQxalSNmf/dt6ZITfRPmy+yT0ObSTHl3Ny6niF0jhg+zVOwgzBl7GjNrTDE3WHWfEXGxjMMvuapJ5Y7k; 4:bL3QcXrVy/KL3W8MBxk6zQjaV2m0Tm2+RW8Cy7BJRYLORzTNB3YvFFwL4NOjMEVKWvAkppdTBTN+nohcnSAuAXG5UlCiOTyYZHAvHhmgRXIOD5zhIHgNLHQKxkNbhsuDvmLJbXIMWlYAJ2Ut7Cj7EpOhUvEjq84OtP6ALELfiJTJI8o7nSTBE7BaFqdQr/cyAyeDUM1Xax09nYopsR4wejFMAVYD4W90MXXdPYVtZyjSflIfs5GXSbhG1Oo5J9AQiTI5tAL4xeX7HCASoSfE7F1A/WGMxNYkuOFKAqCoMD8oCY7DRrA27nIxgK/eoX1s X-Microsoft-Antispam-PRVS: X-Forefront-PRVS: 093290AD39 X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtWSTFQMTg5MDFNQjAxMTI7MjM6S0N6ZlVsZGlobTNaOURTMThsWWFZV0hU?= =?utf-8?B?bytXOTRGdG82V1dOVEpHNnNYZ2RaVWdySmgvMllaczFoV2J5bjlyS0xLTWla?= =?utf-8?B?Zlc5YlpWSVZVbi9tOU1tUnRQNHduZkVTT1Z2L2ExRXFUQTB4QmpyN3NpSDVU?= =?utf-8?B?dzA4alkyWGtKdC9MS3U5MTNSVVJvdmFPNkZuRXpXY1p5d1dueXlqcGxha2xE?= =?utf-8?B?OU1SdHNtVmoyZ3cyTXVFZXlwN1NSK2QxRGc5ZFJxcGdQUEVrWFRESWQrdlZk?= =?utf-8?B?TGJEb0s0UCtHeVE1eTYzSW0wUFFhbGxleTgvS1VkZys5N0Rac1JodEVZVzhI?= =?utf-8?B?bzZtVzBmVVZ5S0lyN2N5Rk5DZ0JqSG5GWTV6d0pxUFZCWnh5MTRUMm1oMHRv?= =?utf-8?B?VGM1cGhHMXl4eUtUOFNud01tM0ErZjVzamRPUVVvVjRQMlR5TXVLVzYyT1Zy?= =?utf-8?B?L0lsVFd2SkxuM1FCQmJZd3o5Y2pNeWdvcEhFV3lZZVJMZ0VjamV6Y29GcjM5?= =?utf-8?B?L3JvZFFtL1lSUlkxREFxb1BEdjBVbHRlOUVzbXl3c2UzL3VKYmFGU1YwVndz?= =?utf-8?B?VDhRME51b3QxdHpHRkdSWlVRMkxmNFVQYnRTeDJ2QVRsVFRUaVo5UWFvZ3BM?= =?utf-8?B?d05BRVRRa09pNjJDcmdFYnBCdmpBd0VEZEJ5V3V1d3NXb0pSZVQycThWTUov?= =?utf-8?B?cXU3UkZlOW1HUFhKaFZCcUNjcjl6UUpTQXR4UldVbTdUVFhmTGRDZTFGeDJE?= =?utf-8?B?TXErenpEQmIyTktBUWViZGh4MzhpMFZNTXpwa0s5NGxWZkdaWk1iU0JWalNy?= =?utf-8?B?UlRsYnZtQmhPVFZINkxxTXdIWTd1SmoxTG1RZFBMbm52L1BvYlpTQ3VKU3do?= =?utf-8?B?UzRYUXEvNUpNazhUSXR1SVpPRTFaQ1hkdnJTdHRWSWVEclEyOWkrRzVJbjdP?= =?utf-8?B?ckFtNTdrTVRLSXhEL3QyYjl3alBRRXhMejVKRnpKb1p4QndaL0N6eUpPb3hP?= =?utf-8?B?aE5FQyt4UWNKa0dJSTVsVVBtN3lIdEp3RjhrdEZDZjFXZzVzeVN6VkZjbHdJ?= =?utf-8?B?enBwZFFVQWMwSTgyK20yK3lnVUw0eG1mcmg1S0N1OGRtQVZWZ2tiQjhRNyt3?= =?utf-8?B?T1pVekF0SDRXNTYrYjYzcElTdWd6NGNjeFNjTmIwc1JGai9LOHNud3hrSjN1?= =?utf-8?B?SXVsdWpFRVVxQ09kQ0VjQkVsdkNSYXMxMVM3OTN6dTVZYWh4eUMwTlNEbmln?= =?utf-8?B?WFgrcWYwRzF5UUdyNFdSLzdEbXBrdmJtUWlYL0k4NEE1UGhFa0JKRm41Uytm?= =?utf-8?B?cm4vK1VadTA0c0QzbklkOWNCQ0wrVnBLMnd3SWUvMHJNRzBHNGl0MnJaN2cr?= =?utf-8?B?KzZSWU0vSENLUGtxNGorSktLYmhoTVVFdS9ETXE0a2tzYXA0ajJTOTVoTGJ2?= =?utf-8?B?N3Fjc2VheDJWSERZSVRZQkI4d09Db2FDYnRJY2hvN3U0NTZxTFFuaGFaME1p?= =?utf-8?B?Wm56L3dBbk1Bck94VFhJbitpOXNNNmdPTFpuaVQvY3lPZ0lKcDMyOHAvaHNK?= =?utf-8?B?aXUwSXkwQWsxMGVEYzFFWlJXclFKNzFmQ0trREMrMVJNVlVhOUdKTW5IRWlG?= =?utf-8?B?bGREdjJnMjFHU0VKbTZuVU4yUFYvOTFKOVhJaTdVR3M2clhobmhZNXRuNlB0?= =?utf-8?B?VHM1elEwUThWUUtqbmVkVEpTdlg5U0pqaWJZNXczZEEwYnpHTFNVUXE3OWlH?= =?utf-8?B?WVA4b2RmNEZ1cDYzZElGQThxRHU5bTJXbENnRVV5VjdhMU5ma2RjeDRoU1No?= =?utf-8?B?ZE9tUDR1bTFUMzZNd0l2T1hzdmxrQmY5dG9QNmREQ0tLQjV5Wk8vaGNTaEJw?= =?utf-8?B?amFYRy9FejZuRFZpTXhoYzd3aVQ5dThTaUZHNDZjNTQxWGZrRzdNYjVCSC9u?= =?utf-8?B?a0FuVGtBZ2lTdmc0UnJ3Nlc4NWFMNmVqMEtnS3IrYTJZd1BFN0s3M0tnb2I5?= =?utf-8?B?U29CQjdLTmNVWlhyRXB5WE1hM1ZjTFZpMDExbDRsT2IxaFFxYjBrK01SdVI2?= =?utf-8?B?RmRMNVJMd0ZkbTNGYzhSUlNvaGdNV0hUK0ZJSzNUKzZoN1hRR0xVajhEVHBG?= =?utf-8?B?dHRnd2JqS0hvWGQ4a1F6TGdRcFp4L2RKRWRYcHpqbHhvWHhkS0pCb3ZQOE55?= =?utf-8?B?NXBxcEYwU0V6eVE1b2lJOGVVeVhWT1E9PQ==?= X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Message-Info: e3mkHDAv+5r9OrahxkH/jvnaWl3EGnsBfJu/biPH7AZbfY2DIJGxdB77LlDN65ara0NUFtOsFS60ZHxD/RCCSQXhSnLNquatzif4dvpzgAuytnXMNcDZ8HSJSCKbBYIHb+mwiFU+bjPwcOctsxI2sZcPqFsKN7eKPP6KOWtVmSFL0YfG3T9ENoHXiVD6MGFiIPmQ2H8hV3a4E9+SluGsTe4YWL/64TyHSy1URAh5EuX0JUagufhNXOPkaeH9PFcqJi/FOtnla3afvGHviunMRtv+4qhuFHPrz5zQVxSkyFV6IPTANgJSfgDSLQVfGbogt5Il2+nHKHGtywHUYYgNrC8i6A8kZa/tKRZphoXMv3L+dzFTbu8aCvPr4T0iYVXzpncXD8q3qeBiBXjV0kPlrBxBKdvPVbYEmE5ly6onSi0= X-Microsoft-Exchange-Diagnostics: 1; VI1P18901MB0112; 6:0ftkHH+DdmEdOOqVgIaomVWLV1/0cju6s4FOoO72T7w3bycatzS7H+1SqOt5WZ83Solwsctv/no3O+qCq2DReUmgUVNvFPq2YVg9se9MvnyqPz4lE8oT0fz+woUK/N+Pa1Tv0+Cx4bJcTDMeOTGgsmVzaEjF6PELNjnjoZ7tZBG6r97/NlbKJekntnc04ir3rMMdCXbR/UWWyqAlNYyag6r48qC6m3aR+dy8/klu27fIiOA+W4BfJX/JemGJqZiF5wMAlp5oiAIwj0xn2pjhq9fNU+wh413NuDMzjNTYJwm5QnNNScfwL1mmQsD4qApEoQmn3s/CfhRaZ3jHNBYT0FRD56wH2pGq+iWo2fOWv88JAg/RWelWr1+e6i98CqjpthjqSellAqXN6UulWTQBE70DAkk0tEuHWlSR8CWmQYI4I9QKfz56nzRpiLGmH8uO0Xia1lNQXPjcBf6CnKTCew==; 5:IrYQfzBkPvFWiE+2K1Hs0Fw6qMiMHK82Oh9JV702PVB/v/RaoqHn6ts3bTz6w/Q8hybEpxvlJ12e6NjO1n5sgP6rMoIHlGH1nZlXOnMhMQnfGIzhZBcQ9VD+CToXG+Jp4IpocakakH1O39m30OEEvKyn2mk6csQ7e9L03aT3J0cYzODHzMR8cYeNShd2dqMYJyxx6ufWZhmoMi/t6adUfw==; 7:VGvhvJQajfvRgwBPx4gC14DueuKJ/deqTPly8val7qva5gmIGg38fNT0QDTqqV2m6rG9uuIBPquCecvdoanGLNPeB64aUQ41s/UUBvCC6kFW5+gdwxi2G9BAPYUAFP1TxclX/ze19Mh3eSoucJM2dQ== X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Jan 2019 09:02:12.3435 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 7012ed07-7fa4-4c2c-602f-08d685c8751b 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: VI1P18901MB0112 Archived-At: Subject: [Ace] Fwd: New Version Notification for draft-ietf-ace-oauth-params-02.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, 29 Jan 2019 09:02:24 -0000 Hello ACE, I have uploaded a new version of draft-ietf-ace-oauth-params, addressing the remaining review comments and fixing some typos. I believe I have addressed all reviews on this document, please double-check if that is indeed the case. Regards, Ludwig -------- Forwarded Message -------- Subject: New Version Notification for draft-ietf-ace-oauth-params-02.txt Date: Tue, 29 Jan 2019 00:59:05 -0800 From: internet-drafts@ietf.org To: Ludwig Seitz A new version of I-D, draft-ietf-ace-oauth-params-02.txt has been successfully submitted by Ludwig Seitz and posted to the IETF repository. Name: draft-ietf-ace-oauth-params Revision: 02 Title: Additional OAuth Parameters for Authorization in Constrained Environments (ACE) Document date: 2019-01-29 Group: ace Pages: 14 URL: https://www.ietf.org/internet-drafts/draft-ietf-ace-oauth-params-02.txt Status: https://datatracker.ietf.org/doc/draft-ietf-ace-oauth-params/ Htmlized: https://tools.ietf.org/html/draft-ietf-ace-oauth-params-02 Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-ace-oauth-params Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-oauth-params-02 Abstract: This specification defines new parameters for the OAuth 2.0 token and introspection endpoints when used with the framework for authentication and authorization for constrained environments (ACE). These are used to express the desired audience of a requested access token, the desired proof-of-possession key, the proof-of-possession key that the AS has selected, and the key the RS should use to authenticate to the client. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Tue Jan 29 05:15:13 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3072130E78 for ; Tue, 29 Jan 2019 05:15:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aol.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 XFzSkX0qBlXM for ; Tue, 29 Jan 2019 05:15:07 -0800 (PST) Received: from sonic317-27.consmr.mail.bf2.yahoo.com (sonic317-27.consmr.mail.bf2.yahoo.com [74.6.129.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A825F12D4E8 for ; Tue, 29 Jan 2019 05:15:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1548767706; bh=/GXDzE4L+riIHn7kpgGnDsn4DlQBaHSZ40+rY3eSyJI=; h=Subject:To:References:From:Date:In-Reply-To:From:Subject; b=Onee/SINUTlfwlrmiakK3vhymOf4/M4D5qWKJ1ZJfUvtdU6yEhqDqIwCB4HjkVWWLplzFyGMp0R2x2ZHI+sTzbgVz0fb7gIiT6nkWjJXce3wr6TD2/PuvbzcuIA98WUNrR/3buaIgc7zY+5qCW5Q+oa1QyTU/Bp58jQyylEA00b2WuP7Yw+nl3oqvx7jQxWKPj4IAiEtaqfTSLhd81dZw6Pk2/dBU5kgobWOMOGMWr7UEyvsiw4jApg9b+L2Y9l05LIWvVU7/e/yrFgYG03sO0Ct9nDH1JhaIrerPS0c8fDJDrOT7JFJBsehht7mjL0czF1R8oehOEAk0f4y+363YA== X-YMail-OSG: _lIGNVkVM1k.iPROOvnnwrIEB4e_XbWGl1.I0T2sikUwsg5dTAo6pK1E0SHqKIV uwmcKlBB05sxspGqe1jhY4DD8ae10p7iiIXgutfD9T2084l8B2Xi1uuKMXlgTwIhOM8bXhQsviqo u5T6_t0K1nRhaDb6aJOWpfjtxEZ.95o8srooznoUA.7StBYClMhNTe.Dyr8Ao3.Mf9YUCZjHE68e 3JWyvTYcwYYwxzxZyexz8ghnrpYdwb1m5Pq.LiC5zlP8ZoCEccYz_1FIP7Qmn1K2BMoAjOyFIwp6 KRtNB3m7wmEwAsg6zAEexL8CsLp6zyxCTBFwEdq6PITwaJ02pCkiiSm2a_QO9rwuepjonqapCXXr TB8OEDrAA5727Twazdn4mHZ9sjeIpaKlVGwaB1CbffmGRlAk0iQCcK1BBFRN86OeJV_QJhYe4RWr L_Kt4mq.dp1dMi0RfLTUFmrMqj.visy7BE1RAORKPpJjaXE2J1sc.ryQeH0hseGp.6AsRPCCyhag iDbN_mgdAJGKHwFpcqwRRcNRZvDvRwDiKDGNdCb09x99ZGmhAc.XaI_4A4yS404U_NZArjEuyU.. 7C_WMykaYesM4Hn72x1ILdxMRCGQ67_B_6FqgcTGrRsCcqsEU.95dCXR.KBtiSAoKuCMwXWo7gCl frTTFnlF27nRKCdqvr_b5drltaesjI.4QDmi6JL29X8PSZfUGaeeExMxp9kObJEVOmAcvtfCstJb btTnOMvCULj88cVD1.BkKJdBv2DMrbzqyMBsiwqedk84OpSEbE7YJrNsGVMQt9GqAN0mKtw.UfX5 d4L1a38v70hSFLRM3iAzpuYiaH9pnmfKcRYq1px1IYyOu.NC0AbUNAV2MVJVwNix9zHLlH6xc.1M jkjI_uMr8XzfoBwx.1ax12mcBffJ7Udli6FejNc8DzjmGVy3L4LdO0HiudZ130ZjWsvUGysX6gQ9 .N8kDcbJ1LEY6YuixkmvZ.qvhVCLemzI7toUO_HrMZNO3oDCwfYavde6OcfsdDxiWyfKSoxG3hZk WlYteZyxVn8.z6X18paMCBjcui7jVQNT.zCCtNvKiguNfDWQ0eGoBBPfOOLh_iVI6vw-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.bf2.yahoo.com with HTTP; Tue, 29 Jan 2019 13:15:06 +0000 Received: from nat-vpn-users2.cfw-a-gci.net.buffalo.office.oath (EHLO [172.135.138.233]) ([184.165.8.97]) by smtp401.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 759dc410db180f06b2e23284340785dc; Tue, 29 Jan 2019 13:15:02 +0000 (UTC) To: Ludwig Seitz , ace@ietf.org, oauth@ietf.org References: <4eb4ea45-c3f2-7991-9544-612d055809ba@ve7jtb.com> <199fa6bd-8103-b1b3-12a3-08b5e3aad925@aol.com> <55a0362e-e588-bce5-f65f-856a1e21e88e@aol.com> <65a8e83e-c72f-bbf5-77fd-ea8540b7ddc3@aol.com> <848e0ab3-f95f-2885-d24e-69925ed7ab1c@ri.se> From: George Fletcher Organization: AOL LLC Message-ID: Date: Tue, 29 Jan 2019 08:15:01 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <848e0ab3-f95f-2885-d24e-69925ed7ab1c@ri.se> Content-Type: multipart/alternative; boundary="------------735FC6F53AF1B8CBF59CD64C" Content-Language: en-US Archived-At: Subject: Re: [Ace] [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resource-indicators-01 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, 29 Jan 2019 13:15:10 -0000 This is a multi-part message in MIME format. --------------735FC6F53AF1B8CBF59CD64C Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Thank you so much for the background! I believe that since the latest draft of the resource indicators spec [1] allows for abstract identifiers, and since a URN is also a URI, you could easily use a URN syntax to accomplish the use case outlined in your email. resource=urn:x-mydevices:temperatureSensorGroup4711 The spec currently outlines examples where the "resource identifier" is not a "single resource" in the context of a fully qualified API endpoint. Another example, for an API like SCIM [RFC7644 ] that has multiple endpoints such as "https://apps.example.com/scim/Users", "https://apps.example.com/scim/Groups", and "https://apps.example.com/scim/Schemas" The client would use "https://apps.example.com/scim/" as the resource so that the issued access token is valid for all the endpoints of the SCIM API. Using "https://apps.example.com/scim" is semantically equivalent to using "temperatureSensorGroup4711", at least to me:) Thanks, George [1] https://tools.ietf.org/html/draft-ietf-oauth-resource-indicators-02 On 1/29/19 2:56 AM, Ludwig Seitz wrote: > On 28/01/2019 23:12, George Fletcher wrote: >> I also don't know that this raises to the level of "concern" but I >> find the parameter name of "req_aud" odd. Given that the parameter in >> the resource-indicators spec is 'resource' why not use a parameter >> name of 'audience'. That said, I have not read the thread on the ACE >> working group list so there could be very good reasons for the chosen >> name:) >> >> I do think that there is a lot of overlap (in most cases) between >> 'resource' and 'audience' and having two parameters that cover a lot >> of the same semantics is going to be confusing for developers. When >> calling an API at a resource server, the 'audience' and the >> 'resource' are pretty equivalent. Maybe in other use cases they are >> distinctly separate? >> > > To give you all the background of "req_aud" from ACE (sorry for the > long text): > > Originally in ACE we had defined the "aud" parameter for requests to > the token endpoint with the semantics that the client was requesting a > token for a certain audience (i.e. requesting that the AS copy the > "aud" parameter value into the "aud" claim value of the token). > We were then told that this collided with a use of "aud" in OAuth, > that specifies the intended audience of Authorization Servers (if I > remember correctly), so we decided to rename our parameter to > "req_aud" for "requested audience". > Mike Jones then made us aware of the work on resource indicators, but > upon closer examination I found the "resource" parameter to be more > limited than the "req_aud", since resource specifically states: > > "Its value MUST be an absolute URI ... the "resource" parameter URI > value is an identifier representing the identity of the resource" > > My interpretation of this is that "resource" refers to a single > resource, which is more constrained than the definition of the "aud" > claim from 7519, which uses a StringOrURI value.  For example my > intent was to use "aud" and "req_aud" for group identifiers > ("temperatureSensorGroup4711") and other non-uri strings > (hash-of-public-key), which I cannot do with "resource". We therefore > decided to keep the "req_aud" parameter in > draft-ietf-ace-oauth-params, even though is clearly overlaps with > "resource". > > Any comments and suggestions about that line of reasoning (especially > from the OAuth point of view) are very welcome. > > /Ludwig > > -- Identity Standards Architect Verizon Media Work: george.fletcher@oath.com Mobile: +1-703-462-3494 Twitter: http://twitter.com/gffletch Office: +1-703-265-2544 Photos: http://georgefletcher.photography --------------735FC6F53AF1B8CBF59CD64C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Thank you so much for the background!

I believe that since the latest draft of the resource indicators spec [1] allows for abstract identifiers, and since a URN is also a URI, you could easily use a URN syntax to accomplish the use case outlined in your email.

resource=urn:x-mydevices:temperatureSensorGroup4711

The spec currently outlines examples where the "resource identifier" is not a "single resource" in the context of a fully qualified API endpoint. 
Another example, for an API like SCIM [RFC7644] that has
   multiple endpoints such as "https://apps.example.com/scim/Users",
   "https://apps.example.com/scim/Groups", and
   "https://apps.example.com/scim/Schemas" The client would use
   "https://apps.example.com/scim/" as the resource so that the issued
   access token is valid for all the endpoints of the SCIM API.
Using "https://apps.example.com/scim" is semantically equivalent to using "temperatureSensorGroup4711", at least to me:)

Thanks,
George

[1] https://tools.ietf.org/html/draft-ietf-oauth-resource-indicators-02

On 1/29/19 2:56 AM, Ludwig Seitz wrote:
On 28/01/2019 23:12, George Fletcher wrote:
I also don't know that this raises to the level of "concern" but I find the parameter name of "req_aud" odd. Given that the parameter in the resource-indicators spec is 'resource' why not use a parameter name of 'audience'. That said, I have not read the thread on the ACE working group list so there could be very good reasons for the chosen name:)

I do think that there is a lot of overlap (in most cases) between 'resource' and 'audience' and having two parameters that cover a lot of the same semantics is going to be confusing for developers. When calling an API at a resource server, the 'audience' and the 'resource' are pretty equivalent. Maybe in other use cases they are distinctly separate?


To give you all the background of "req_aud" from ACE (sorry for the long text):

Originally in ACE we had defined the "aud" parameter for requests to the token endpoint with the semantics that the client was requesting a token for a certain audience (i.e. requesting that the AS copy the "aud" parameter value into the "aud" claim value of the token).
We were then told that this collided with a use of "aud" in OAuth, that specifies the intended audience of Authorization Servers (if I remember correctly), so we decided to rename our parameter to "req_aud" for "requested audience".
Mike Jones then made us aware of the work on resource indicators, but upon closer examination I found the "resource" parameter to be more limited than the "req_aud", since resource specifically states:

"Its value MUST be an absolute URI ... the "resource" parameter URI value is an identifier representing the identity of the resource"

My interpretation of this is that "resource" refers to a single resource, which is more constrained than the definition of the "aud" claim from 7519, which uses a StringOrURI value.  For example my intent was to use "aud" and "req_aud" for group identifiers ("temperatureSensorGroup4711") and other non-uri strings (hash-of-public-key), which I cannot do with "resource".  We therefore decided to keep the "req_aud" parameter in draft-ietf-ace-oauth-params, even though is clearly overlaps with "resource".

Any comments and suggestions about that line of reasoning (especially from the OAuth point of view) are very welcome.

/Ludwig 



-- 
Identity Standards Architect
Verizon Media                     Work: george.fletcher@oath.com
Mobile: +1-703-462-3494           Twitter: http://twitter.com/gffletch
Office: +1-703-265-2544           Photos: http://georgefletcher.photography
--------------735FC6F53AF1B8CBF59CD64C-- From nobody Tue Jan 29 14:09:58 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7260A12E7C1; Tue, 29 Jan 2019 14:09:56 -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 V1A4K1wCrysx; Tue, 29 Jan 2019 14:09:54 -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 7DB60130F86; Tue, 29 Jan 2019 14:09:54 -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, 29 Jan 2019 14:09:47 -0800 From: Jim Schaad To: CC: Date: Tue, 29 Jan 2019 14:09:46 -0800 Message-ID: <01c401d4b81f$5948d7b0$0bda8710$@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: AdS4GbVtPWAAmhTcRcCOixruhBBHNg== Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: [Ace] Shepard review comments on draft-ietf-ace-oauth-params 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, 29 Jan 2019 22:09:57 -0000 1. In section 9.2 - While reviewing the IANA considerations, I was not sure if the JWT Claim Name be set to "rs_cnf". If it is then please update the draft. If not then please explain why. Jim From nobody Tue Jan 29 22:02:02 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 351071311AB; Tue, 29 Jan 2019 22:02:01 -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 a4IibjxEFCzg; Tue, 29 Jan 2019 22:01:59 -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 1D7AB1311AD; Tue, 29 Jan 2019 22:01:59 -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, 29 Jan 2019 22:01:53 -0800 From: Jim Schaad To: CC: Date: Tue, 29 Jan 2019 22:01:52 -0800 Message-ID: <01e801d4b861$4d7d41e0$e877c5a0$@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: AdS4IFhTaN2qYeA7Q3O6kMo5VP3Q4A== Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: [Ace] Shepard review for draft-ietf-ace-oauth-authz 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, 30 Jan 2019 06:02:01 -0000 1. Update the reference from RFC 5246 to RFC 8446 in all locations Items that don't appear to be resolved: * Section 3.1 - Refresh Token - I don't think that refresh tokens are going to be strings because binary is more efficient. Unless you are going to say that this is not OAuth 2.0, then a refresh token is still a text string. * I don't see any text that is addressing this. > On 22/10/2018 21:09, Jim Schaad wrote: > > * Section 5.8.2 - If the RS is going to do introspection, can it send some > > type of "Server Busy - try again in xxx" while it does the introspection > > rather than just doing an ack of the request and possibly waiting a long > > time? > > This is probably transport protocol specific, and we were asked not to > link the framework to a specific protocol, thus I don't know if we can > provide guidance here. I think it would be okay to say something like "some transport protocols may provide a way to indicate that the server is busy and the client should retry after an interval; this type of status update would be appropriate while the server is waiting for an introspection response". Which does provide guidance, but in a non-normative fashion that does not require or prohibit any given transport protocol. * I don't see anything that I think addresses this issue. I would expect it to be a security consideration Comments on protection of CWT/Token: I am wondering if there needs to be any comments on how a CWT is going to be protected. While it is ok to use either a symmetric key or a direct key agreement operation for a single recipient without forcing a signature operation to occur. If the token is going to be targeted a single audience hosted on multiple RSs then a signature operation would be required for the purposes of authentication. ****** IANA Section Issues 1. None of the new registries appear to have any guidance for the DEs to use when approving items. 2. The title of the registry "ACE Authorization Server Information" is not really descriptive of what is in the registry. It makes sense in the text but not as a stand along title. Something along the lines of "ACE Authorization Server Request Creation Hints" seems to be closer to a solid identification. 3. The mapping registries should use the OAuth registry name as a prefix. Thus "OAuth Access Token Types" and "OAuth Access Token Type CBOR Mappings". 4. What is the initial registrations that need to occur for the "ACE Profile" registry. If there are none then this needs to be stated. 5. For the CBOR Web Token Claims - how many of these should have the JWT Claim name filled in? It would seem that all of them should. If not a comment about this is needed. Jim From nobody Tue Jan 29 23:45:16 2019 Return-Path: X-Original-To: ace@ietf.org Delivered-To: ace@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 476D8130F0B; Tue, 29 Jan 2019 23:45:09 -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.90.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ace@ietf.org Message-ID: <154883430920.7839.4561014745135650707@ietfa.amsl.com> Date: Tue, 29 Jan 2019 23:45:09 -0800 Archived-At: Subject: [Ace] I-D Action: draft-ietf-ace-oauth-params-03.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: Wed, 30 Jan 2019 07:45:09 -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 : Additional OAuth Parameters for Authorization in Constrained Environments (ACE) Author : Ludwig Seitz Filename : draft-ietf-ace-oauth-params-03.txt Pages : 14 Date : 2019-01-29 Abstract: This specification defines new parameters for the OAuth 2.0 token and introspection endpoints when used with the framework for authentication and authorization for constrained environments (ACE). These are used to express the desired audience of a requested access token, the desired proof-of-possession key, the proof-of-possession key that the AS has selected, and the key the RS should use to authenticate to the client. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ace-oauth-params/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ace-oauth-params-03 https://datatracker.ietf.org/doc/html/draft-ietf-ace-oauth-params-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-oauth-params-03 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 Tue Jan 29 23:45:49 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B72741311D9; Tue, 29 Jan 2019 23:45:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.043 X-Spam-Level: X-Spam-Status: No, score=-2.043 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, 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 yKbx9GvAbAGt; Tue, 29 Jan 2019 23:45:39 -0800 (PST) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30050.outbound.protection.outlook.com [40.107.3.50]) (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 055B413120E; Tue, 29 Jan 2019 23:45:37 -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=8ThF0uCZKiSo756L261KA0f5W91chw5AoGx3WmIwvHE=; b=Lw7S7G/QcD3ysX4wq8nnEj/7mK8sb+CROhsHzbjJJjC18nSV7rXxO5+DT4z4IELnhiml2qvVWIWK+dVwqqX/gILAawVjwaP7E5Q32WgT/R5c7j1TPQTmkXq03UNR3cLrVMPPS4/e0tGhCENT7DP62poQl+i46F/utwJS/CjBO/4= Received: from DB6P189CA0023.EURP189.PROD.OUTLOOK.COM (2603:10a6:6:2e::36) 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.1558.16; Wed, 30 Jan 2019 07:45:33 +0000 Received: from VE1EUR02FT014.eop-EUR02.prod.protection.outlook.com (2a01:111:f400:7e06::205) by DB6P189CA0023.outlook.office365.com (2603:10a6:6:2e::36) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1580.16 via Frontend Transport; Wed, 30 Jan 2019 07:45:33 +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 VE1EUR02FT014.mail.protection.outlook.com (10.152.12.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.20.1580.10 via Frontend Transport; Wed, 30 Jan 2019 07:45:33 +0000 Received: from [10.112.134.122] (10.100.0.158) by sp-mail-2.sp.se (10.100.0.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1531.3; Wed, 30 Jan 2019 08:45:30 +0100 To: Jim Schaad , CC: References: <01c401d4b81f$5948d7b0$0bda8710$@augustcellars.com> From: Ludwig Seitz Message-ID: Date: Wed, 30 Jan 2019 08:45:30 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <01c401d4b81f$5948d7b0$0bda8710$@augustcellars.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.100.0.158] X-ClientProxiedBy: sp-mail-2.sp.se (10.100.0.162) To sp-mail-2.sp.se (10.100.0.162) X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:194.218.146.197; IPV:NLI; CTRY:SE; EFV:NLI; SFV:NSPM; SFS:(10009020)(376002)(136003)(346002)(396003)(39860400002)(2980300002)(199004)(189003)(97736004)(8676002)(36756003)(305945005)(336012)(2906002)(77096007)(16526019)(186003)(26005)(74482002)(44832011)(81156014)(106466001)(7736002)(64126003)(2486003)(8936002)(53936002)(486006)(6246003)(6116002)(81166006)(58126008)(230700001)(67846002)(31686004)(65826007)(2616005)(110136005)(386003)(33896004)(316002)(53546011)(65806001)(65956001)(4326008)(16576012)(3846002)(478600001)(22756006)(14444005)(23676004)(476003)(106002)(446003)(69596002)(47776003)(4744005)(68736007)(11346002)(22746008)(76176011)(86362001)(50466002)(126002)(104016004)(31696002)(356004)(40036005)(229853002); 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; VE1EUR02FT014; 1:XERnQZhxZIyMqXgwJo1v7riRU7SsA09Xm10r+qnPC8VLC8Yg/2xGJFCJ0Ob6xpnfIHB/aX086swLp0j8XuPR0Fv8wvZMy2N1fUxahYwSHAdJb/vnCgcyp9Q7jJdf96wrqMYlMvOe6Jnlz8wr/IJgfG6xfC3WCln1y+cHcZ4acF0= X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: fa74c0ce-342d-4976-0381-08d68686ea5f X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605077)(4608076)(4709027)(2017052603328)(7153060)(7193020); SRVR:VI1P18901MB0109; X-Microsoft-Exchange-Diagnostics: 1; VI1P18901MB0109; 3:5m38qV9Q5Q+G4DrSVO3gALvZyUJyx5ymqz4e/lDVQ3k2giFFsy5VodXV9jZi7DNi/gKiaCqxfReZoWIW82X90UmvdeFtfvEeuCyQ9i9RnVbG/T6+8cnYBtFIsWgYvPKGSj/AsYQXXAAEw9bQLijRsJXO/ubhqjcwgKwkFPKlYl6vW+kc8EQOSENBtEzSKAK/lFmHM2L2rBhW8kuIPFhvQCdlVo4IoFIbEboDG/zpw8EPdHd9EB+6w7w1FT+0z5GrgZIGBKkP9bc8xJ4dE0H0Aoviv0bf4E1A5oo/+PzR/Kb7xZSua2W17bkQdunZO0niCWNK4aU/PIhCFMUXt1kWNVT6HuEmCmboPD3jXJiVziWzF/ZjQOGwf3+Xh4kOzxUWfA8Ks7kb7a0BG5FfohnRNQ==; 25:jGH1LwnNPqv9T2/ysstIcFkVxmI1Zd8M+71jEjBhxYMN9iUORvcHc6GdfxP5K0cioLy/NecyrTRTYwwYs8uaGIuH94orhvB+hE00/4F1hbb7TTeiVTK+50wkVNFSwjXWkadDB5etdD61Ng52bVhAcDqEmloa3ezLvRzuuIij3sTsQ/hkZJzWPZZFMr3Y2U0A9tVoi+Xa+Q2YPiXLtk+PcD3gh8rIuomhSjSNg7rJs+IigxIcGfYcT3PfiwHG/Eih1DX/IPaMLzAiXBdlQl4ZYDae1ecEh6VdsCM8kg93uobPeLSKpmnFj9RPrtFqDz/eFKKehpWtQd7mbEK9ZOcInA== X-MS-TrafficTypeDiagnostic: VI1P18901MB0109: X-Microsoft-Exchange-Diagnostics: 1; VI1P18901MB0109; 31:Q+3RR7bKUVvY+BgGrJG4iIJnM12uiavk7OjH9ChT/djqOIdWQbEQHenNhOLhuo/dYv+LyVwHY3PWO6liHHaeQweWuQ6k0u4ENW2d5UxatkjH1EeLly/3NxHx0c3TxHXyO2UnLpsCRErYRZnhigZjf7rovD95FhqBEwmQpsjOMUWpoCEaFrAe1rSHBgjuY8k41ZGsDTyjf8Pux3OCyc6x0g9cYeegciDEdQkxoInfoEA=; 20:+gsWXdZ0SfzmljAqazRfow26axUQD2uJVBiHEd97EbxN/vIorkZOmEQuY/xf0XuKLvIjXw+jNVf4JjBQDNXv+Im7GT8OCGlH5EP6NVDXFyiPSVxdki8bfefLjNNgF3YPTY40d0wKsVDZ62JPSiZRZZdrUox0ezgmNTF49av8PKJhLLJJamv5PmDKEd33xfmDCED6Rd/GJuSCc+06ml/58Zgigwtt3BDHJFONj95tqFpTRi3i5zfZ0SukS7OJPjoA; 4:9XxSl2TpRvWfhfgBHFsI6wrgatGv6WFvTNOeuBl+wzekjZ3Crmbk6rEahJ09jfJjLae6DtIJJPXEWij2Orjzt5PvC9aeet0l7pVWJL6NP4eaXBnfFzgufuGnoevBIwFclS+uDIBmlhzhn9/l5urfn97kX6KNGeA4J6b+2Rcu7I2ROCZoNWJbZOBftz67nbtp8Q1V53MlVnNTuli9mR9TLQx2cC4FQ/Frf8b3hOQ7JkoA3M6JLoQQ+pnaCIrwgo2dkGJslcS+vrXT/3eoXt670s2SaPJ9I/4Oib9//r2fgYo= X-Microsoft-Antispam-PRVS: X-Forefront-PRVS: 0933E9FD8D X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtWSTFQMTg5MDFNQjAxMDk7MjM6a0ZNR3dwVWs1MGZDSFJnb3JDd0p0TGdh?= =?utf-8?B?ZklPSUZ4WENuSVYzNyttWTZQWmoxajlDcTU4NlEvLzQ5bVNVdnpzZDU4QmpK?= =?utf-8?B?RXBqWGc4d095WVBCQmtlODQ3N0UyblFxYXdnaFRGTGwwUlRDYjB5eEZ4UHps?= =?utf-8?B?N0dlK1VMUXErdWUvUnp2L0dUQXJ2bGpIb3pXbGZwUnNTdzcwbFRybHF2SHda?= =?utf-8?B?T1l3c0JRNnc3UGVHNUZDcVJFZEF4eXViVklyVlUxdjN3MG1IV3hyYmxTdnlj?= =?utf-8?B?dzR2Yy95OEpyaTcrQ3VwMjlGL0t5c1JmdC9XTCt1cnh0RzJjZXZ1Sm01dHdU?= =?utf-8?B?MW1JYXowVDV4ZFVSQmF6TkJSaUtVZHo0aTdHaW0wZ0Era1VwS3prQ291Szlu?= =?utf-8?B?VmRtTVpNZUNTdjFmY0NnTWpjU1JiZURZTWNKY2NMaVpWZ004bC9WcTYzVkty?= =?utf-8?B?Vmd6eU4wTU4wUU52VVRxSjFzSTMwMW8wY2t1TzFvUzNsQTg4cmRLQkt6c1lz?= =?utf-8?B?S0NrSTI0Z2huU3dEUXpnK25ack1pZVYzL0YwNEJHMVMvMFg5aXQ3ZVJhZUl1?= =?utf-8?B?L3lXNnVrcXBTTHYzODlYMHNTb01NTzRDQ1NLVCtmamRmR3FaL0ljUFFMSVNL?= =?utf-8?B?dE5PZXRxaEl5bGc3Uy91azUyNEl1Z2hhdjRNdGtuV2ZtQ2krUWxycXY2ZzRN?= =?utf-8?B?Unc2a1A5TXBxRjhEQ1dBcXZ5Um5oOW1ORk1JaUpySGdneUc5cDF3d2NHVlE4?= =?utf-8?B?M0FKczhtYmtIemhWbFpqNW81OUZHOUNlcTc5V2JVeG5heU4xblZndkdEaUFI?= =?utf-8?B?YkVnbnZLeTJMWTZnZjhDZ3RWelhMRFhxdjdzaTNwQjE2aEJNdGNNMkszUyt4?= =?utf-8?B?c2sreHRSdEExd09jbGZTdlJQQ3Jvb1JzU2xkaVNSQWNFck9XVTQzQURWZ3RT?= =?utf-8?B?d1YxMnRoZ09Rdko2ZDRzZnBwZUZmOTkvaEhMRmJxbUl6MFQ3MnBzS3E5YTg0?= =?utf-8?B?ODdDNG5YYnhjVE4xS0pzcVdaVHgwcGl1bXBkZGQzUGtvb21XcmRBSTNvTm9L?= =?utf-8?B?U2s0aXdSNko4QVRtdVNwVnUvLzU0bk04L0V2WDAxMXlQNEhBbHFoeU96S1F5?= =?utf-8?B?SUdSQ0VmSk1FS3lEZk1KMWU2aDJvS3I0UUhXNXZqN2x6N1dabExLV0wrQVYr?= =?utf-8?B?alJmMHZRNnk2UWs5dzR6NGdWM3VTOVgzNGtwVkRmaGRCSTlwZW53bEVnMEw5?= =?utf-8?B?ZXlEdE9qRTdZZkl0RDFVVlRDbWRvbWgzOHY2YnRXc2NGcU8zZ0xiTHJlR2hE?= =?utf-8?B?VEd1T1hXWXJ5WG95eEEzT003Y0NtNWs3OFBLUko4VTZXdVRtWXFlM05za1Ur?= =?utf-8?B?UitGaHlrazQwUWgxRnVMYTJKWkFtQlBnbW9PSzlRYlJKdml6UU9JZC9kUHkz?= =?utf-8?B?WElEME1QdkNxYVlVSTVlWklrMUJta2lXSWRvcSs3S2c2WEh0MTRxYzUva1Z3?= =?utf-8?B?TXAzSGpQalVFQVJLbXhUM2krUmZnZ0VPNWE5SXhIWmF3TzVsR1pucEdkTktF?= =?utf-8?B?ajIvQ0x3c2Nxd1h3d2xGTmtQUWdobEY3QzdSdm55VU5FZjd5Mzg2L3crYTlx?= =?utf-8?B?WHZqd3lCdGtUQ01KUFo0YmlkRDBqQk5oWHlxZjQ1VmRuTXM4UjhSUXpXMUpV?= =?utf-8?B?OHMyWVhXNlErVlNOTkk5Ty9tenRPSzhxSlZsSEpMejZ4NVR5YjZ3RWNFdkFQ?= =?utf-8?B?SmVUMUQ4S2ozUjEvRkgyWUFKeUI3UkcyMlhoc3BmNzR3WHdqVXUxSThBQTVQ?= =?utf-8?B?Zm5kcTY5Qy8va0h4NXFTOVIvT3pUNE9iUXdhcTdra1Y1d01aZW9iK0lnb29E?= =?utf-8?B?Z1NMSTdmbnY4WWpxV1JJeW5LeGdJZXJVeEhMckZRV3BTUVFpNFZ4MnBFZUJE?= =?utf-8?B?VEdadVB4OEJxMjB3akMrMmxPcENqbi85dmt3RFMyRXpsanZMRFRwWmU0THd2?= =?utf-8?B?VXhSTXZ3eWlTOWQ5eEYwbS9PMW5GV0I2Vm1uN0lIcXNJVjdvc3BxS2JjQ0Np?= =?utf-8?Q?KFXqE4=3D?= X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Message-Info: O8pJuso3KCbTIVdnkjB81SIS7+HVdmH4XesSdpDJCk8BsJZxdbhO3jmYKlHhPv1WKEUrbJp9s5F0E0sweYkPAM826DS7FKNiXaoMxe9dkYy45NaiVsS4R06W9E/+sw5DzRH1WT+sRjFhjdzQvF77m3JIK/FjWvhnY9EIdUlVxD5p1ZrjHLdEB28XoR11mMGbtsGkc6Kw2XW1OUfJ4wo2mtYgy2mbU6qdlTrjwn1gbdgGQSZzPK5Ycu1MTrD0J+Y2fHGXImnojIJcXnLyu2gDoabn/TIT33ZslhB4lrw5cmPw2OmtUVsLSl4IL2t2fpQm7PavpsIm68/H41YoBX4xGmVHgbZ+G3jfc+hVNqdQV6k1Zz/OH6o/9tIgWlzZKtfaPFXH+dZQJf+IQyD+5jg4j7vtV36Mz5wX3BuMNx/rrzo= X-Microsoft-Exchange-Diagnostics: 1; VI1P18901MB0109; 6:JYP6/tclG+Yhftk/CWXbe8sTlZn9vPnlsUUv0paaL8EyoBHUyasJPotkjQFFnFqk8BKUfGw/hYYRZ4d0fjzyb9ENnJMIkqiLvrkSlgl4LbnjfQRhqPC2XViir7iQobAWmSA2hf71w42EK8UE9JAquVQMqrgRKT1VSBCisS6f7uRWw+YxGpdmcecMEctITfvQQXVzvcgDbvcMjbKZOcbaEACG2KV/u1p2lWzcUa4hoREa0dfg6mbMqUWipnDLg5E4gJrfRHSH/AJ6lc7EwE3HCMiwhoVIsozpOMEfVgYHK3JS4dyS6FJ9erEXaduILhb9Fmf1sRrIgTlWQSReJf6R2HY8c+/isah27EtRBCd8xD0xR5SQpZ0XRVZYCu4+QKx29d0GwxU2WmoLhwwwgNJ748kpGsdkpX9EI+k+7RRyJBMowz/bJdQBeIYvCqf5oqxgVQyHqBPf9ldY8MBIQILo7g==; 5:9CdaaHiNNQyFtmAbEDe3VujFgelar9pWmbOqt1hmJpUfhbToPgnqn/Cg/ohfJBpiD+bKeNcstZVqY4EGyIeVMtAb6peC6Ja4Sw7brftJGZUvDJIBss5xwwWkVE7oKt5fJA9aGqmADSyR051MJEee07oz9l6tAoc8eYITEDTF50jm1d6UcZ9tQeqi8M4JFhs/H+8UF9zeChQrGTbFB1okog==; 7:zNYc1jSJZ3WjH69sL5rNIGmofMqvVlVBTydpkpyeVoAlbPeAO0OMLXKgiu1NE8Zxb5yWbvNBwVibhE5a3OSEGwPeOp+5ZTz++BN4JV3fDEVLow0fMkJ/RoIy18kd5iMHHlvgpctgB3jOMtCnXawhfg== X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Jan 2019 07:45:33.3757 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: fa74c0ce-342d-4976-0381-08d68686ea5f 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] Shepard review comments on draft-ietf-ace-oauth-params 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, 30 Jan 2019 07:45:48 -0000 On 29/01/2019 23:09, Jim Schaad wrote: > 1. In section 9.2 - While reviewing the IANA considerations, I was not sure > if the JWT Claim Name be set to "rs_cnf". If it is then please update the > draft. If not then please explain why. > > Jim > That was an oversight. Fixed now in -03. /Ludwig -- Ludwig Seitz, PhD Security Lab, RISE Phone +46(0)70-349 92 51 From nobody Wed Jan 30 00:37:57 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B671F130F20; Wed, 30 Jan 2019 00:37:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.043 X-Spam-Level: X-Spam-Status: No, score=-2.043 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, 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 TWYD6yDE9oZc; Wed, 30 Jan 2019 00:37:49 -0800 (PST) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00053.outbound.protection.outlook.com [40.107.0.53]) (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 4119C128CB7; Wed, 30 Jan 2019 00:37:49 -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=aYHsHRmV7xBiAeg6ARn2f0KtNiwz3x17Hb7MbphZT0g=; b=Tb9bTMVKkgBspHGdPAXPPYAkZmO/Oga31JDLcC8Gkj632/80tocpqtNn3wxuK6V8/w1KtiEAqGOQ62/tZxNMNxl7KYpJfsoRH4mAe1Qx1eV4axVA+kgRHnv6wGQV2Gh0YVvZtG/6QH6Z/+EDvioShvMFwf2PA1nklje6stfVOOw= Received: from HE1P18901CA0005.EURP189.PROD.OUTLOOK.COM (2603:10a6:3:8b::15) by HE1P189MB0331.EURP189.PROD.OUTLOOK.COM (2603:10a6:7:58::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1558.20; Wed, 30 Jan 2019 08:37:46 +0000 Received: from HE1EUR02FT020.eop-EUR02.prod.protection.outlook.com (2a01:111:f400:7e05::205) by HE1P18901CA0005.outlook.office365.com (2603:10a6:3:8b::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1580.17 via Frontend Transport; Wed, 30 Jan 2019 08:37:46 +0000 Authentication-Results: spf=pass (sender IP is 194.218.146.197) smtp.mailfrom=ri.se; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=ri.se; Received-SPF: Pass (protection.outlook.com: domain of ri.se designates 194.218.146.197 as permitted sender) receiver=protection.outlook.com; client-ip=194.218.146.197; helo=mail.ri.se; Received: from mail.ri.se (194.218.146.197) by HE1EUR02FT020.mail.protection.outlook.com (10.152.10.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.20.1580.10 via Frontend Transport; Wed, 30 Jan 2019 08:37:46 +0000 Received: from [10.112.134.122] (10.100.0.158) by sp-mail-2.sp.se (10.100.0.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1531.3; Wed, 30 Jan 2019 09:37:45 +0100 To: Jim Schaad , CC: References: <01e801d4b861$4d7d41e0$e877c5a0$@augustcellars.com> From: Ludwig Seitz Message-ID: <76f048fa-fa03-4e5b-0b60-c5674a2ddad3@ri.se> Date: Wed, 30 Jan 2019 09:37:45 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <01e801d4b861$4d7d41e0$e877c5a0$@augustcellars.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.100.0.158] X-ClientProxiedBy: sp-mail-2.sp.se (10.100.0.162) To sp-mail-2.sp.se (10.100.0.162) X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:194.218.146.197; IPV:NLI; CTRY:SE; EFV:NLI; SFV:NSPM; SFS:(10009020)(346002)(376002)(136003)(396003)(39860400002)(2980300002)(189003)(199004)(106002)(76176011)(305945005)(336012)(23676004)(106466001)(2486003)(81156014)(2906002)(36756003)(186003)(356004)(77096007)(26005)(16576012)(2616005)(486006)(386003)(86362001)(50466002)(31696002)(69596002)(14444005)(22746008)(58126008)(53546011)(446003)(67846002)(16526019)(4326008)(126002)(44832011)(110136005)(68736007)(33896004)(8936002)(11346002)(476003)(316002)(229853002)(3846002)(6116002)(74482002)(8676002)(6246003)(53936002)(65826007)(230700001)(65956001)(47776003)(81166006)(65806001)(478600001)(104016004)(22756006)(97736004)(31686004)(64126003)(7736002)(40036005)(21314003); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1P189MB0331; H:mail.ri.se; FPR:; SPF:Pass; LANG:en; PTR:InfoDomainNonexistent; MX:1; A:1; X-Microsoft-Exchange-Diagnostics: 1; HE1EUR02FT020; 1:H285NopAn6HZSAU39UqGJntMwpO94YnxTL5d/ehemmyrtN7rjrkHnQwsv0CRAyr7nKr5TqQPMvwhtRLe3MbMvFJc2PHDuqQB1WjHyJ8uyk1hYSTlu8m7/1qRWEA0QyZQKwkXaGfF52ZEI0iqNIumGymOJ15sSF8FzPiEicnZdX0= X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 7c297aa2-65f1-4e92-7932-08d6868e3598 X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605077)(4608076)(4709027)(2017052603328)(7153060)(7193020); SRVR:HE1P189MB0331; X-Microsoft-Exchange-Diagnostics: 1; HE1P189MB0331; 3:qFkDtEzkC95TvhPd199b9RBPLgeY8aTkekTe21xAH/J1L7trMwh9/6Mn/83qFfKMvSQm7UUyta6UyCVRgTzpGiRHYulxn2GxndmQhVbxwNPobxBWM/qIz8qN2VZdVvxydhdGVXDFTOj4jz+71cBV1IGUtKlHTse2FjPEPw/Up7Q8hWnG4yQhTOKppfW1LmAs6/+ROHP1MADno1eFROuyd4+DF3thCCwufnMCyN2/6uz6hgOVbUfdkLayqcS1moHDM0nP3F6sHTQIsXF4St9086spzY1LFJjVxM9EbM/mQxwl0cK9Hw6ZOwA2chm0bCE/PG4Auobl41nt4BwAowaDhaj+I03RKgPUcxX1yNHnaw1O4AZUg320fhdOvUfJYS/OxE8qQgMUEmLZ6yBe6+nIjg==; 25:3hYiI0wKkvjZfvKayzBS8yZCuh1S2s9uWsyNDcEUO/ANSsZS+pXG+4zPsJiIK03hM6tsk5FmX3HGYAw9FajPktMj/N+2Vy1o9OS/tUup1ELxiuu4YO+fSSZU/dC3iALtLXQMOs4MBfUIkbE/5AC2L625HSGfC/Thsqgoks51dmEMoF5ryBnwhWIk8AYj89nK2sUtHb6M49Su1MXtJ6amGueL8KKES5IQbqbeFVo1APj4LzQPIx38mi+vAUxGwx07iz07OxHeH1l7nffGyS02+ZOm4/4hSbqfGMlFI3xPfEGg5xyK57tcikYvGTjjtGBn+FVzFNf/vf8RITW8u1vhBA== X-MS-TrafficTypeDiagnostic: HE1P189MB0331: X-Microsoft-Exchange-Diagnostics: 1; HE1P189MB0331; 31:nX+EjLScIu6J/cFA6tc4IMS7XZWHebIor6XsaYllwJtTayiI3lcRcJl35sAbnA+fHssB3NGXAu9VfbOBb6+4om8/Zn1g0H5c6Le+maQbi5yp2D8wYvJys4jxr2OJiZmV65nKUU4T1JY7COUl9ndGrP6/T188ek6feYfQN1NGymbQqKFNc6bytVH0FXv26ITSxMmgKCE/KSaaW9EQCKUWhnlQ+uUnyi4F623xrwjzRMY=; 20:NmK2Xq7KLnY/RdmyCxlLNULy0BNjzt/ZLJJDmQGGJzit0GQMe+hmqGUpj1cLRELEemSAnc++HNhPhPptlsJcmQ8nVa0WbSGUiHQIB9COKw+sx/BN0dJ+XxgTrBFSr7xXojbf4SAEy6Ve5Gl8XlUbu2I4qAwqf6M0/aSJPscchQxFF2sIrRG3eEBTvq2mp3wXyLhwT0YrbBDAwzOzvoh8TFgBRf1vuhKhS7NSQ+PquqCIu9s5+eh0s+5saOFXd+4p; 4:fXq7keQkYLy3D6drWJuxaXmUKIocbMS/nBsCpF7WT3jOl4b5XTVbjwCHy7oue8Ez+su58kUVpt/7NZpfzsbVZk1WMvkagLcBQJIO162CJJ/A36j3F2KQQeJkt+gAPcIMnXdGfcOsNgy0kE4P0+fMWEsmZMfrupxtNzkq6/70LiFRT/S4dCEWNw/qBolj09JH1/h8QXGOX/0hNIm/p1FBkDwMMiBTiZRCeXEHB6RxjqETC9W4o+Ij1L0q01w6323fPpcKpVFoqe/mmoHtaXJ0umJU40MvtKlGI5OxHkWD1KdWJ/tiwPKSf8gm/MmRG/V0 X-Microsoft-Antispam-PRVS: X-Forefront-PRVS: 0933E9FD8D X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtIRTFQMTg5TUIwMzMxOzIzOk9GQ3JVdU13a25uYzVBTEtNZElyVDJ3MWJO?= =?utf-8?B?dWR4M01heVYveGptTWtUOENEN1VLeTlVWHlXOWwrYUUzakJVa0FIa0xPbGht?= =?utf-8?B?cHlGSURFNG9xREdSN00zOTVTSUZvRHFWUzN6M3EzbFF5c0REZk1UbFpvNmlJ?= =?utf-8?B?UzZBWG9IcmJubHg4WjJYZHpxU1htbTlMaStvdzY2VzBTSDY1SFNIUXlSMExh?= =?utf-8?B?NmhndTltRHdYNzdOY252bzFHUHU4aDI2QlNVS09kc2xxbVAzWXlZdm4xWHZW?= =?utf-8?B?bGtxdHlUMFFnbmt1dGR6VFkvQnA3VFJ2WUR0dzRCK1BEenJYU1FiRldTSXFu?= =?utf-8?B?aDIyNTJrekxjS2d2cG5SQVV0ckl1a3dOZWQxVVRWdDBHekxrNGVQR3BoRUc5?= =?utf-8?B?cTJMbU1FZy9MMWlvZ0xKWENDakwyTlJWeVdveVk5TDZtbFBMb3prT0p3U0xR?= =?utf-8?B?cDIyMU9aOXFIZTh6RXZNUEc5Uk5EUzE0dExaOEpGL3NJdGNGWW1BbG1oSjJD?= =?utf-8?B?Qm01bEJaYUxyenc4SjJLbmJnZkhubi9HNFQxeUZON05qcVpZMGt6QXh1VUZM?= =?utf-8?B?U2ZXZTA0QzJ3NlhqNnF4ZDloWElscEM0Qzl0R3pabVlXK2crTGkvMWZVTkti?= =?utf-8?B?MDBJcDNRdlFjNEFnV3A3TllBcWNzQWpSRVcybkZHd0Zid2xRb2dlK0lWQjVl?= =?utf-8?B?Qm1jQ0tCaFpiLzdiMDJ1NWt4UE0zNHNiZmZjWjQ4S2RUYUNWajFTdk5hMWps?= =?utf-8?B?NEM0bkwwanBJb2ZLZFJQMkNCVGtERnFOdXZ1RHIyT0lIN2FQelh6TkQ5bkYz?= =?utf-8?B?TTVZeVY1RFhtUWw1aG4zZmoxb3V2RkVXS0ZlRnYvaDdBdGluRndiMUVmYTI1?= =?utf-8?B?MUVOU0R1d2NucWJnb2VRbHJoOU1zZWVieTRMbmdPZ04wY3BjbXVFY0dadkFt?= =?utf-8?B?T0VGV2hEeWo5eisrNU5HN3NYeXlzTytPU3Jpa3ZKa1RURERHOHhaeFZhMTFH?= =?utf-8?B?NHdVT0YrS3Q4SVdjQjVqT2o1WVQxZ24ySVJHNktMdWhNK2lwRUpRRnF0SG8z?= =?utf-8?B?aVVjbjdaQ0tlOUJ1TzlIU01PbUhQY1lHdmk2dE1wMEh2UG00RTlIWW8xajBh?= =?utf-8?B?OGt5cGtqMGMwaGVSajMzQk5YTXR3aytMdThNcTQ5bGRWRVcrdkNTdUQwUk9D?= =?utf-8?B?c0IvaS9lSnM5cTJ1dHFONWg5c0N4THoyQUpVRkVWT0Y0ZjFNb29aTFBDK0d2?= =?utf-8?B?VmhjSkQ3TUdpbTJFQ082TFBhYU5xNnpJNUFHQzYyWDJLeU9SbXJiK0g1M0FM?= =?utf-8?B?dW5YRXp1djNGcnhJUlcxaE9DM2VxSTlUVlVySElGUDFUdTVqQUdEQThxUk9R?= =?utf-8?B?Q2RidGF0R0dtd3lsdE84eFNVOU9Zc0RnTUl4UDdHSi9Jc2Y1UkxkVXk1RG5p?= =?utf-8?B?R3ZzQjBWMkNialUybFUzV1RVblpJYld2cTVVN05QNGpyVEVucStiTU94eGd0?= =?utf-8?B?b0ljSHlVZjZENVhPNTdVQVVjYzlkNlkySUkwSUdlNzZTK0NLSkZKZjRVM1g3?= =?utf-8?B?VUhJN240V3h5WWlNZWd4dDVRdmtrL3d5TWVnTzhnWGttcDlTbFBiaEZyQktH?= =?utf-8?B?NnlFUEExYXEyZ2ZhZElqNTVqQ1MyT0R6YmNNVXlxMjRRZ2phNEZEMGZwZjUy?= =?utf-8?B?cmJnRGNUUWlCNzZIeXBIWTIzMXB2bzk2eFlCUXh0SXVLOEN3WjRVN1lOU3Vj?= =?utf-8?B?MHdDY0J4WURmdDNmbHBhR3lMYXpiK080L2dVNXkwSktRUXhQR1A2eWVjTUdx?= =?utf-8?B?WGJmSE1YRkFkdDlybEJVZkRHVjU5TndqUTFseEVDZlJTM0pxczdFOWJ2bXlE?= =?utf-8?B?YmNrcGdTcE1LY1lVQ3RTeG56c3V5M3Y4VEtDLzlvbWF6RHpaUXNnZzR6VmVG?= =?utf-8?B?SXZXTDFteEhSUENuM3BGN3JOcHlnMGh4bnBWbEdod0NlakN5eEFlT1ZMMHNO?= =?utf-8?B?R3E0Q2tPSlJWdHZNSE5RMTNzUktkNzF0cjRLUnJxa2ozMG0vVG02VytvN2RR?= =?utf-8?Q?suEY=3D?= X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Message-Info: YZHztWyt9pmtXQkzWMZxaWl7foF1iwVd22Jlh7jMV+GOAApNT2MdSDSluMQZRAbe211aPQ532SoDjbKKFMncT0tp9lT+FPDtMXYsBHJULutiZozoc+BAXt2R2SBKhWYIOPceI755475Agm7SY5nVPdsTR9kKsiyY2tMu7GcMbwyJiq2EkMOS0RZIlpJBS3JeeLkSJwwrSLEL9cFA/TC5l13x2nGMKhVSq2dMGRFcunsQJP9rEeOE0Wp2PM1YFkjenCslXEBkBNi87mI1vtGF1c0VJ2OxOKF5MiveHUZENKk6zHQ3R9gIvXApR/LfmlSevjcPmJSy8GH4ILeRULOJKvnLAfUeY8nPBtptX6jcd1PayhdQGAn0ovWl5HR697uSPB7dYgQFsZybWiXjxvQTa/y6O2VaqGn2MUxsn6nVXzk= X-Microsoft-Exchange-Diagnostics: 1; HE1P189MB0331; 6:emugWUr+AQHaoeMgB6OApJ4PlsOjbrS670Ogz392s+/EQzlfeLWttJcGU4ZJAcokWOZmK4WDAjgyEQcafB8Nwo7XlbUeQ13ObEJWvkHczYY+9maYhExN+qR7ueePvl3ndxYvWQVvCyvI3ykACv2vvRj3BsuM1+w68jqzWDRklU52hA0v6H5U1GAPWmxSALA4cm4DZnczcVTt+tBRLJ2fG/VZVAjUVOKgMHBTFADc9jdQumFvpKqtA8RlMsXEyeCMoPh5eL7N9QBIROE0MmF9/rUOBnuhM7WlNK1mrrQZROrGIG22bLvas+3WQE//OZ7d1ji9uMM+78nGXIKrrJeUX97S8osfG71//IHme9h3JJorilKcxDP3TPlPuc0tqpCFYlLoWRuLAfW7Z5d5RufEuDxyHzUh+H03BPqVkoDQru2w3XUC1P9iUEjbdCx0JKVE4ld+Y1NCDzXPT53ndhqD5Q==; 5:pNrat1DqDQEwgp8JA1vxZbd67+iWNVYJU6jza7lTqKRKJGpn/MtR6KfWhFA5pGUTvB22sQJuhc8Otbx/MQW+TxtFtOVB0lNwua0E+FhA1kVhqb1nf3lCzt5XLLg7+Q5Evmh0/YU5gRo37ICo/tgBT5WaTOpyomqyRfxNfA4D551kHrm8zTyqm6o2RQaT2HKzCNULix0QamIVF0jJa8u8yg==; 7:PkmV+WF5e9DRl4Q+gVFEh5y2CUVIGXZwzl3b76t0hqLV+o/6RFYGBy2hcEPFBT0hiGaGrNtmzPss89ogwfihnc11FZ5oEfwUYt9w+47vIbsJX2ZqzodPQUO9wluqH+nmFfwVOY2W8NfFVepqV+8F3w== X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Jan 2019 08:37:46.0511 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 7c297aa2-65f1-4e92-7932-08d6868e3598 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: HE1P189MB0331 Archived-At: Subject: Re: [Ace] Shepard review for draft-ietf-ace-oauth-authz 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, 30 Jan 2019 08:37:54 -0000 Thank you Jim, I'll upload a new version as soon as we have resolved my questions below. /Ludwig On 30/01/2019 07:01, Jim Schaad wrote: > 1. Update the reference from RFC 5246 to RFC 8446 in all locations > > > > Items that don't appear to be resolved: > > * Section 3.1 - Refresh Token - I don't think that refresh tokens are going > to be strings because binary is more efficient. > Unless you are going to say that this is not OAuth 2.0, then a > refresh token is still a text string. > > * I don't see any text that is addressing this. That text just describes how it is in OAuth 2.0 (where refresh tokens are strings), since we didn't see the need to specify the use of refresh tokens in ACE, we didn't mention them further. If we had we would certainly have defined them to be binary. > >> On 22/10/2018 21:09, Jim Schaad wrote: >>> * Section 5.8.2 - If the RS is going to do introspection, can it send > some >>> type of "Server Busy - try again in xxx" while it does the introspection >>> rather than just doing an ack of the request and possibly waiting a long >>> time? >> >> This is probably transport protocol specific, and we were asked not to >> link the framework to a specific protocol, thus I don't know if we can >> provide guidance here. > > I think it would be okay to say something like "some transport protocols > may provide a way to indicate that the server is busy and the client should > retry after an interval; this type of status update would be appropriate > while the server is waiting for an introspection response". Which does > provide guidance, but in a non-normative fashion that does not require or > prohibit any given transport protocol. > > * I don't see anything that I think addresses this issue. I would expect > it to be a security consideration There is text in the draft according to the suggestion above in section 5.8.1 "The Authorization Information Endpoint". Should that text be moved to security considerations? > > Comments on protection of CWT/Token: I am wondering if there needs to be > any comments on how a CWT is going to be protected. While it is ok to use > either a symmetric key or a direct key agreement operation for a single > recipient without forcing a signature operation to occur. If the token is > going to be targeted a single audience hosted on multiple RSs then a > signature operation would be required for the purposes of authentication. > Right. I'll add some security considerations on that. > ****** IANA Section Issues > > 1. None of the new registries appear to have any guidance for the DEs to > use when approving items. Is it acceptable to add a single guidance section for all of the new registries, or does it need to be separate for each of them? > > 2. The title of the registry "ACE Authorization Server Information" is not > really descriptive of what is in the registry. It makes sense in the text > but not as a stand along title. Something along the lines of "ACE > Authorization Server Request Creation Hints" seems to be closer to a solid > identification. > Would "ACE Authorization Server Discovery Hints" be better? > 3. The mapping registries should use the OAuth registry name as a prefix. > Thus "OAuth Access Token Types" and "OAuth Access Token Type CBOR Mappings". > Done. Actually quite some changes were required to align all of the mappings sections with the OAuth registry names. > 4. What is the initial registrations that need to occur for the "ACE > Profile" registry. If there are none then this needs to be stated. > It's initially empty, since draft-ieft-ace-oauth-authz doesn't define a profile. However the DTLS and OSCORE profile will provide the two initial entries. I added a sentence to that effect in the IANA section. > 5. For the CBOR Web Token Claims - how many of these should have the JWT > Claim name filled in? It would seem that all of them should. If not a > comment about this is needed. Fixed. /Ludwig -- Ludwig Seitz, PhD Security Lab, RISE Phone +46(0)70-349 92 51 From nobody Wed Jan 30 08:22:07 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE2A313122A; Wed, 30 Jan 2019 08:22:05 -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=mit.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 wrNTpX2wqu-M; Wed, 30 Jan 2019 08:22:03 -0800 (PST) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-eopbgr760110.outbound.protection.outlook.com [40.107.76.110]) (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 029B3131228; Wed, 30 Jan 2019 08:22:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=K8qxsXW5vk2EWg0H6l75rxlxl+K7Xui7r/zfFddCanQ=; b=dPFAov4a6r6Wiasag0bh8Ucoa6BUfiOA5QJuMeAhimOdRNmHN2F5vtlXOz1h8ELFajzqma7pXdxVdxgaqrPrY/71EYXvw8+vs56nA1xLMPHFDQkp7mUpGeRFWqsdcvYMBOGxvbBKfX6C01EIVNXAmtoxB+LXGyOw+wBywQ5b1C0= Received: from SN6PR0102CA0008.prod.exchangelabs.com (2603:10b6:805:1::21) by BL0PR01MB4529.prod.exchangelabs.com (2603:10b6:208:82::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1558.21; Wed, 30 Jan 2019 16:22:01 +0000 Received: from BY2NAM03FT020.eop-NAM03.prod.protection.outlook.com (2a01:111:f400:7e4a::206) by SN6PR0102CA0008.outlook.office365.com (2603:10b6:805:1::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1558.16 via Frontend Transport; Wed, 30 Jan 2019 16:22:00 +0000 Authentication-Results: spf=pass (sender IP is 18.9.28.11) smtp.mailfrom=mit.edu; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=mit.edu; Received-SPF: Pass (protection.outlook.com: domain of mit.edu designates 18.9.28.11 as permitted sender) receiver=protection.outlook.com; client-ip=18.9.28.11; helo=outgoing.mit.edu; Received: from outgoing.mit.edu (18.9.28.11) by BY2NAM03FT020.mail.protection.outlook.com (10.152.84.224) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1580.10 via Frontend Transport; Wed, 30 Jan 2019 16:22:00 +0000 Received: from kduck.mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x0UGLu03001159 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 30 Jan 2019 11:21:58 -0500 Date: Wed, 30 Jan 2019 10:21:56 -0600 From: Benjamin Kaduk To: Ludwig Seitz CC: Jim Schaad , , Message-ID: <20190130162155.GC49072@kduck.mit.edu> References: <01e801d4b861$4d7d41e0$e877c5a0$@augustcellars.com> <76f048fa-fa03-4e5b-0b60-c5674a2ddad3@ri.se> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <76f048fa-fa03-4e5b-0b60-c5674a2ddad3@ri.se> User-Agent: Mutt/1.10.1 (2018-07-13) X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:18.9.28.11; IPV:CAL; SCL:-1; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(376002)(39860400002)(396003)(346002)(136003)(2980300002)(189003)(199004)(476003)(486006)(229853002)(126002)(46406003)(26005)(246002)(53546011)(50466002)(305945005)(956004)(2906002)(47776003)(6246003)(11346002)(356004)(76176011)(1076003)(8936002)(7696005)(88552002)(86362001)(8676002)(106002)(97756001)(16586007)(33656002)(426003)(4744005)(58126008)(186003)(478600001)(104016004)(55016002)(336012)(54906003)(316002)(786003)(4326008)(446003)(75432002)(6916009)(26826003)(23726003)(36906005)(106466001)(53416004)(18370500001); DIR:OUT; SFP:1102; SCL:1; SRVR:BL0PR01MB4529; H:outgoing.mit.edu; FPR:; SPF:Pass; LANG:en; PTR:outgoing-auth-1.mit.edu; MX:1; A:1; X-Microsoft-Exchange-Diagnostics: 1; BY2NAM03FT020; 1:nyaQzW55l61PTZ2UPcbyaXdlWrDTVDjw4WZnfTtTtmjsA6NdJFE1TdIhJk9qM2m/cfWLnIuT/4DC9Rwkyx9WTvKcXewknoMIJV1wgWj4OYB/SLMPH+YAjmMFjilb6Sg3L1rn2BqkD/AZGlaS29nnoGpgwj8UdPGLzmyp6ABrWr8= X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 99af33be-bc40-4a54-eff4-08d686cf0ffd X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605077)(4608076)(4709027)(2017052603328)(7153060); SRVR:BL0PR01MB4529; X-Microsoft-Exchange-Diagnostics: 1; BL0PR01MB4529; 3:4EGr1OAof0pcJTHMMZnzQbyJZJsVJ9aqldJPq9MAZI0eG+yplOh0bjEJN26BafHrWyhO4ersFOOOgzbCF3/nb0oEysYv4oNqfMVvBJULhXSBa4a9A+ClXNPio7Z6UIN/Ol1ZHiXhzTVrTyDYEc80jmbYN4A0wChkdwMLUh57wNAs9xAy8Anm9Jx01b7fD7C85xcatnZAWE3zfygGUnxJXUxxzDvYrSMEP4djiJwKnbbI/pHNgG39uKHNkqmCvZHMb0xREEdiPbtub9KBdeqwDkNIZh+j6J3UAhLivDccImM2Re5qthHmwyJmk8sWrjsBmlksXY77MGCgUvg5Bmz3N3kac7bWoQ07es170f7zQT40gdrcdZ+PZf1m0tD8xO1l; 25:rPIXZP0500jjF3kSG0nCEMOJZzbOpNGWzcCadVtFtWr3Y5W3xb9uTQs8LE5CPdjSD8sP1YRPY1p+ceIajTW4EChCv5A+X5VBBCVBLbyA9Py6bnimf/lv5bZvG2a4B13a+e664Uvf/oyrYmGW+YK3sJivHE04e6nEXpPT3a/xfwm8xyVq6VLyhDxsSBbpbidugkX6wJ0FINPTspJ4xp8NVpJF3w0IVkBhiKH6Cv2zhQF8g/7uHXBczspgya0o6H/jUVKWojRhYZafG5nDBBi4mig8iQLSi/8QKPvQvx1ADyhM7UIooMjSFxOl9bvOgP7Vzys4HUDIs7wjkR0sX5F4kQ== X-MS-TrafficTypeDiagnostic: BL0PR01MB4529: X-Microsoft-Exchange-Diagnostics: 1; BL0PR01MB4529; 31:tUknzjpj7UtVOG9pqt0iRNvXMMPMgtpGrcUE07VL0Q0JgY8mXAUDNqS0RtYrn5jocmx5rdCGmWMfSIprKMhRz1ENU4n8yyIGH+Jv7Hf14zyPwA3oOiG2uAZ8HsTqoANGLXFMC9WBGywiP6akkf3Q12AbbEELuiZBLCn8XjU1RlXLRX2+FYfHeI3hn+Dt9gOtPAfNALSjL/wIwUw9HF1fnm7Nn7aonqlLoqiFPEFj1kQ=; 20:ToGEg88feA3nt2BLdTFymw46vd9zUHfx0s0rep7QMNY1yGSVam3KzEP85YvFBDNUKR3vZaNfLBsknJDe8/jTVxC+PWitkDVDgdA0j0QZzmM+LotvavrGsGJgZP6484jE6QiOrPwAWFXPiWkdPvF/D9yaBzVGtFM0h15thizWd2QvYhgFEQxWqfR8GLhaC2LC6mHxajlN1flk/RVKxSjOXEXCYGXYyKx//ikPXDgzP2ZXGmQn9aGj5gK05FbybIKitLpBUE0KQpCYD30jjXEVlEwT0ZGm6kID5IDIA0BMrG5s6xZfyeYRudVusWvGiCYxamQK3fT12vk/x9FcYj2FXs/meOBlUJlxHkm6rQ0YIJf1pl/iZmRtfhrYskT3mFVhm43m7LlJ11hR3Cp8/mweSGXiVIvy2on5zINIa+fV2mNI+FP1iagyhGoyXVLfWrzE/Qf2EAKXDIZLg+qIJbXJvmdE0906brNE+DpBhCCkv03p0mnyB1LhQDDZoyycjZrDhoJ7hx0AFQGooCa/jnP6dC9zE/kgz1fwA1v6FOUGEro1sVNkUXBWamj54irGCxBXYH+eulbnnuDTHbaLNvHFBTcoMIjstnlQ5of/ymFv0gM= X-Microsoft-Antispam-PRVS: X-Microsoft-Exchange-Diagnostics: 1; BL0PR01MB4529; 4:5R0a/ZH5pJwsi8p34FjIE4hNHbBzgDp6f+0ePI2dZNmR1Zgo8OaVLvTmfjV87h/lnxyMW84ENjjBWAwnlDHet9qejMx3ntkkEy6NfuLjMf5ZOsYqTA8d+nJk30Z1QreiXYMYBM9dsw2toNmpxXjCJGWXSmXFQEAOWw9REOXns2nlwCic27vCIXZArR1EkGtKoVOY5EpJpxESnayg/Z3XNUOC9qBrYoU1of5lrAoHVdWDrgjVUGwKi5QT5X+bfRgQ5Quvbw3F0baPCqiskSWS1i4sQFCfGZBtWO1jaIgpJ5BERT175Bnz8dr9eF8E4f2R X-Forefront-PRVS: 0933E9FD8D X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BL0PR01MB4529; 23:MflhJNxaZjDOIdsQCj23yJ3rt7v2j0L0fLnwNRmzh?= =?us-ascii?Q?JbDZf4QsV2YZ9EkUc/94jBxgQLE89NbBLqWu/k4eiyZYUOMTWSI2SvzYq7P7?= =?us-ascii?Q?MG1wCePCWPLWmIN/SYZabrft9BqoWIeonS+Wmo6hYz2OGNB8xK6ThjxdYsZL?= =?us-ascii?Q?DN8SgeofiobBkdB+PB2Qby00/yERRhohR4UCo7lTixiDGZTNsT2TAmbGi7cc?= =?us-ascii?Q?tNPt65MjClR4/8y4/0fK6JpmLuCKPHpU2MnJipxGmtV0WKMy4IYxUrpbH0Yc?= =?us-ascii?Q?XhQ73D/2AsJ8X8GA74KxunQI10HbCAlHoRER9HrT4SZRDhQRc/74Z4aP2k3+?= =?us-ascii?Q?/uvz1kNQcKBH4I7mPAt6D97nKpVxDBpQwEVFGCk1fgXgu/WUJoExGRLcvG0R?= =?us-ascii?Q?KdWOe10pIBbNsIo3OiNfrRCFy30Nn/WAvkh823MA4RPDRyQLbMyahIvnRypM?= =?us-ascii?Q?6r4aFHUTb7/ZVTP7IaBrYWHv5sdM2aydDckBgyheL4o/1ePrQCxNMFg3rDqj?= =?us-ascii?Q?UxoHazNoNwp5KVQVU5WSqWVU9iFrSWD2tcKSK2kX1YiGZsJN+zYcEiuciXOW?= =?us-ascii?Q?oGYPZY3whr4ajwObCt772F69yS2HBpgxglEyU34boAABXgZAqFvsqqNsBCeH?= =?us-ascii?Q?rqLmCfnz3lxgXenQ72DrszmxeSed/yBlTU8AyraUlMlGysH9XYYm7Ootgjv6?= =?us-ascii?Q?y8YfzQ7DmRvkjFvf/y19k9bNicrUI32mmiciyXintWKAyjMGFTTGjsAGvxJE?= =?us-ascii?Q?Qtl83Sa71Js7Mhs93nJqJPa8dH+9fRhBKmyihZYQBkb6MofBF//8wmvLeyZC?= =?us-ascii?Q?1bMkoTr8ywE+pXG446jcpyDVq8WTF5J+hcCYbssDu5Bt1vLOBeQdKxtYcqoF?= =?us-ascii?Q?f4aM6Twm6+ViCbx86iXvwa67PTz3Z1QJ9LQve2b8OBmwPOJA3svq47YqpWpV?= =?us-ascii?Q?mZMRYWxZBPlsdN36FFAwQKSUoHoh1KVdVBiB/Re19kHVzIEnvDcwZL15FgBx?= =?us-ascii?Q?ltPCmEbo84VLhmjafnO81WBexHS8Ut48BEkpN8KWMd2v43mzKbp81qRh/Y3v?= =?us-ascii?Q?bwVvSSYRxLvWPSBLcmwPGjsXiy273bOOsBZ5Dzytj514t8f2v5f0AigX4H6I?= =?us-ascii?Q?45QtLzYQuBgear65IvpUuW9QyojjmMYVTvPVR6WiqgUF2RXnfN99Dcy8NnSq?= =?us-ascii?Q?lavXFUgkkDadRBYjRTomkzP11fRhHiC1sxt2mi5VP/7Bd6Qs7v/PHRllg=3D?= =?us-ascii?Q?=3D?= X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Message-Info: sbsKatt/wuu8T19V3fJGqswOxjv6fe428Zo2TC3ZLDM92Ih/gJDDQC1XFnyz7mV0XgBtoFk3Hk7QdBjdZGqFW/Xmii3Xq5MaN/Jc/pj4EqZhQF3izybMAQWklDuRcTlJHBDYL199YwuItfm65HV5sJ5RjOyEwF6tP1wBbHBOMaY48GlCXvUIQ1d5Zw2gNk0+oAPlqwPcKDGGqD4rVVj+iUBsEP8iK7VGY8WFA+RRg5g+C5dwCg6RutvndYaLn6jDri1gSPHgesQkcHsLV+2fqKJ4ybdFXvAFouUR1EYCxHZHBUzhDzsllT8v7zwAiFZNtNAhVcIbpMuTI9ENyNKJ/Q/yvOJlZRtYQjgqFlIq8TExUEXFFKQdUNR6v0LJm67D9P/X6DwjM3Uw6ZKBiIqmS3IYNo5kQHuPIfqs3z15Z/k= X-Microsoft-Exchange-Diagnostics: 1; BL0PR01MB4529; 6:EoaayFUoh9gX9ozaAD5tGDUdk0bTb1nyIZkjqp+92oMelWDo6K9cYbrzItPf1JbXqTPbjFegzTeZBtDcjZIiTwp3rvSfEPu/9pEp8/c8gk+qBmPrtfFKy4stI4HcDpAbM+AD6KPWi1jBvLMLyIIGalnhAKJ/10PXVutFQfPrhsK/GyOWiY2gnqrt2UbS6zegdeR3qQr/5Y39xB/NPVH5uHmYxq2h/9HD20HYRJunuu38qYQxeOTR4hCWB78o8HtGof5Ps0onNeQO6JMIdf/rvrimx2MFn1NHqnIlKt7FhALhIpwhSbIoud4Ww1yXr6HSdjjATJWRlDHW97Nyc8IHZVOsawkSCgWm/lqKD/gqaUQCTs/uZ7BSoMi7mQfUpRohycRHqYA05aDvRpeWOs6kxuCD0zzGFL4BBgUyhO8NaBp0jgeb6Hm56YXxGyV1Ue53QIErFxkmoZPVAfDZbIcRTA==; 5:kvR2q1xJAO1qciY3V+bqRdpXc/ykOpvASDT3UcDUEFYQbWiCPZAsKGwor2jY9VlJPfK3/4jZt/GiRgMc8QzThOin4l+1mJi1Hk0WBIfFmkfO+9257emGNVCETH6ilFDh3n950CfXLqhh/xzQctxK5U5M8ZezpIKdz3Cm1RZTJiT65UIEkODB9IeVb0TMVoiRZS0yjk65mBoVlGZ2yLWVSg==; 7:RaUBBofI3V6pl8FqCSOdmrSMw2FOXbsOi+dAVlvtv1etN3MfEcvUc6NFnDrFDxfGEdcgDmVgeMT/0EFOYNpBBbH5Jbak5ER3MszeHOUXGbjkxcFNez1KiP5+qIERXtGeYNHvvawuUde+xYISRT8gcQ== X-OriginatorOrg: mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Jan 2019 16:22:00.1104 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 99af33be-bc40-4a54-eff4-08d686cf0ffd X-MS-Exchange-CrossTenant-Id: 64afd9ba-0ecf-4acf-bc36-935f6235ba8b X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=64afd9ba-0ecf-4acf-bc36-935f6235ba8b; Ip=[18.9.28.11]; Helo=[outgoing.mit.edu] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR01MB4529 Archived-At: Subject: Re: [Ace] Shepard review for draft-ietf-ace-oauth-authz 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, 30 Jan 2019 16:22:06 -0000 On Wed, Jan 30, 2019 at 09:37:45AM +0100, Ludwig Seitz wrote: > > On 30/01/2019 07:01, Jim Schaad wrote: > > ****** IANA Section Issues > > > > 1. None of the new registries appear to have any guidance for the DEs to > > use when approving items. > > Is it acceptable to add a single guidance section for all of the new > registries, or does it need to be separate for each of them? That's fine. -Ben From nobody Wed Jan 30 09:11:16 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B4EF1294D0 for ; Wed, 30 Jan 2019 09:11:14 -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 5JrRilEyJsLe for ; Wed, 30 Jan 2019 09:11:12 -0800 (PST) Received: from veto.sei.cmu.edu (veto.sei.cmu.edu [147.72.252.17]) (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 2F2B7130E93 for ; Wed, 30 Jan 2019 09:11:10 -0800 (PST) Received: from delp.sei.cmu.edu (delp.sei.cmu.edu [10.64.21.31]) by veto.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x0UHB7VR012261; Wed, 30 Jan 2019 12:11:07 -0500 DKIM-Filter: OpenDKIM Filter v2.11.0 veto.sei.cmu.edu x0UHB7VR012261 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sei.cmu.edu; s=t52kn2igOmwp; t=1548868267; bh=0hwL5Q0axYyIoQkp0RI4TPpQAzlukui68U//6HSluf8=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=Fsrw+mHzA3xXen9ytCoT0Lvtx8kciwwtX+rBPBAnoUkY77GCFwePP/DPPSVAS//P2 EhYMvDYrQuVHrP1RIvAMpH+qyNmiTD5F0IRWZaopZFOm+zZ+9BXtbwr71S0YnoqBOt 0easzW9/I2wWi/WkEEwSL53IjZ4yRllud78ubVUA= Received: from CASCADE.ad.sei.cmu.edu (cascade.ad.sei.cmu.edu [10.64.28.248]) by delp.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x0UHB6L1048052; Wed, 30 Jan 2019 12:11: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.0435.000; Wed, 30 Jan 2019 12:11:06 -0500 From: Sebastian Echeverria To: Michael Richardson CC: "ace@ietf.org" , Grace A Lewis , "Dan Klinedinst" Thread-Topic: [Ace] ACE Implementation for Disadvantaged Environments Thread-Index: AQHUs0cwxz8vJeWIVUGFns83Bt0/66XEercQgAA76QCAABjZAIAA4VeAgAJmMoA= Date: Wed, 30 Jan 2019 17:11:05 +0000 Message-ID: <213790F7-BEFE-4A90-A25C-D3A257B559A1@sei.cmu.edu> References: <11C08BF5-0060-459C-99DC-EABEA88DF44B@sei.cmu.edu> <0FCF1038-D6C8-4C25-9B4C-E493EB817592@sei.cmu.edu> <7387610A-D857-49FE-9964-77D54CDDA2F4@sei.cmu.edu> <23315.1548718367@localhost> In-Reply-To: <23315.1548718367@localhost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.200.127] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Ace] ACE Implementation for Disadvantaged Environments 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, 30 Jan 2019 17:11:15 -0000 SGVsbG8gTWljaGFlbCwNCg0KVGhhbmtzISBBbnN3ZXJzIHRvIHlvdXIgcXVlc3Rpb25zIGhlcmU6 DQoNCiAtIFdlIHVzZWQgcGxhaW4gQ29udGlraSwgc2luY2Ugd2UgZm9ya2VkIGZyb20gNmxiciwg d2hpY2ggaXRzZWxmIGZvcmtlZCBmcm9tIHBsYWluIENvbnRpa2kgKHdlIGRpZCB0aGlzIHNpbmNl IDZsYnIgYWxyZWFkeSBoYWQgQ29BUHMgZnVuY3Rpb25hbGl0eSBpbXBsZW1lbnRlZCkuIFdlIGhh dmUgZ2l2ZW4gdGhvdWdodCB0byBtaWdyYXRpbmcgdG8gQ29udGlraS1uZywgc28gdGhhdCBjb3Vs ZCBoYXBwZW4gYXQgc29tZSBwb2ludC4NCg0KLSBCeSBkaXNhZHZhbnRhZ2VkIG5ldHdvcmtzIHdl IGRvIG1lYW4gc29tZXRoaW5nIHNpbWlsYXIgdG8gY29uc3RyYWluZWQgbmV0d29ya3MgYXMgZGVm aW5lZCBpbiBSRkMgNzIyOC4gSW4gdGhlIHBhc3Qgd2UndmUgbW9zdGx5IGZvY3VzZWQgb24gRElM IChEaXNjb25uZWN0ZWQsIGludGVybWl0dGVudCwgYW5kIGxpbWl0ZWQgYmFuZHdpZHRoKSBlbnZp cm9ubWVudHMgbW9zdGx5IGR1ZSB0byB0aGUgbW9iaWxpdHkgb2YgdGhlIGRldmljZXMgaW52b2x2 ZWQgYW5kIHRoZSBlbnZpcm9ubWVudGFsIGNvbmRpdGlvbnMgb2Ygb3VyIHVzZSBjYXNlcy4gQnV0 IG1vc3Qgb2YgdGhlIGNvbnN0cmFpbnRzIGFyZSBzaW1pbGFyLg0KDQogLSBXZSBhcmUgc3RyaXZp bmcgdG8gZ2V0IGl0IGRvd24gdG8gYXJvdW5kIDI1MCBrYiwgYnV0IHdlIGhhdmVuJ3Qgc3BlbnQg dGhhdCBtdWNoIHRpbWUgeWV0IHRyaW1taW5nIGl0IGRvd24uIFdpdGggc29tZSB3b3JrLCB3ZSBz aG91bGQgcHJvYmFibHkgYmUgYWJsZSB0byBnZXQgdGhlcmUuDQoNClRoYW5rcyBmb3IgeW91ciBj b21tZW50cyENCg0KU2ViYXN0aWFuDQoNCu+7v09uIDEvMjgvMTksIDY6NTEgUE0sICJNaWNoYWVs IFJpY2hhcmRzb24iIDxtY3JAc2FuZGVsbWFuLmNhPiB3cm90ZToNCg0KICAgIA0KICAgIFRoYW5r cyBmb3IgdGhlIHJlcG9ydCENCiAgICANCiAgICBTZWJhc3RpYW4gRWNoZXZlcnJpYSA8c2VjaGV2 ZXJyaWFAc2VpLmNtdS5lZHU+IHdyb3RlOg0KICAgICAgICA+ICogV2UgdXNlZCBDb250aWtpIGFz IHRoZSBiYXNlL09TIGZvciB0aGUgY29kZS4gTW9yZSBzcGVjaWZpY2FsbHksIHdlDQogICAgICAg ID4gZm9ya2VkDQogICAgDQogICAgQ29udGlraSwgb3IgY29udGlraS1uZz8NCiAgICANCiAgICAg ICAgPiBmcm9tIHRoZSA2bGJyIHByb2plY3QgKGh0dHBzOi8vZ2l0aHViLmNvbS9jZXRpYy82bGJy KSwgYXMgdGhhdCB2ZXJzaW9uDQogICAgICAgID4gYWxyZWFkeSBoYWQgc29tZSBjb2RlIGZvciBo YW5kbGluZyBEVExTIGNvbm5lY3Rpb25zIGFuZCBBRVMgZW5jcnlwdGlvbiBpbg0KICAgICAgICA+ IGl0Lg0KICAgIA0KICAgIA0KICAgICAgICA+ICogV2UgYXJlIHVzaW5nIHRoZSBUSSBDQzI1Mzhk ayBib2FyZCBhcyBvdXIgY29uc3RyYWluZWQgdGFyZ2V0IHBsYXRmb3JtLg0KICAgIA0KICAgIA0K ICAgICAgICA+ICogVGhlIGltcGxlbWVudGF0aW9uIGhhcyBzdXBwb3J0IGZvciB0aGUgRFRMUyBw cm9maWxlLCB1c2luZyBwcmUtc2hhcmVkIGtleXMsDQogICAgICAgID4gYXMgdGhpcyB3YXMgZW5v dWdoIGZvciBvdXIgdXNlIGNhc2UuDQogICAgDQogICAgWWVzLCBidXQgb2Z0ZW4gbm90IHJlYWxs eSBlbm91Z2ggZm9yIGEgZGVwbG95bWVudCB3aGVyZSB3ZSBuZWVkIGNlcnRpZmljYXRlcw0KICAg IG9yIHJhdyBwdWJsaWMga2V5cywgYW5kIHRoaXMgbWF5IGhhdmUgc2lnbmlmaWNhbnQgYWZmZWN0 cyBvbiBwYWNrZXQgc2l6ZXMgOi0oDQogICAgDQogICAgICAgID4gKiBXZSBtb2RpZmllZCB0aGUg RXJiaXVtIENvQVAgc2VydmVyIGluIDZsYnIgdG8gYmUgYWJsZSB0byBzaW11bHRhbmVvdXNseQ0K ICAgICAgICA+IGxpc3RlbiBmb3IgQ29BUCBhbmQgQ29BUHMgY29ubmVjdGlvbnMgKHVzaW5nIFRp bnlEVExTIHVuZGVybmVhdGgpLg0KICAgIA0KICAgIFRoYXQncyBhbiBpbnRlcmVzdGluZyBhbmQg dXNlZnVsIGNoYW5nZS4NCiAgICANCiAgICAgICAgPiAqIFRoZSBpbXBsZW1lbnRhdGlvbiBoYXMg c29tZSBhZGRpdGlvbmFsIG9wdGlvbmFsIGZlYXR1cmVzIHJlbGF0ZWQgdG8gb3VyDQogICAgICAg ID4gZGlzYWR2YW50YWdlZCBuZXR3b3JrIGVudmlyb25tZW50cywgc3VjaCBhcyBib290c3RyYXBw aW5nIG9mIHRoZSBQU0sNCiAgICAgICAgPiBjcmVkZW50aWFscywgYW5kIGRldGVjdGluZyByZXZv a2VkIHRva2VucyB0aHJvdWdoIGludHJvc3BlY3Rpb24uDQogICAgDQogICAgV2hlbiB5b3Ugc2F5 ICJkaXNhZHZhbnRhZ2VkIiwgSSB0aGluayB0aGF0IHlvdSBtZWFuICJjb25zdHJhaW5lZCIsDQog ICAgYXMgcGVyIFJGQzcyMjg/DQogICAgDQogICAgICAgID4gKiBUaGUgY3VycmVudCBiaW5hcnkg aXMgYXJvdW5kIDMwMCBrYiwgd2hpY2ggaXMgZ29vZCBlbm91Z2ggZm9yIHRoZSA1MTIga2INCiAg ICAgICAgPiBmbGFzaCBvbiB0aGUgVEkgYm9hcmRzLCB0aG91Z2ggaXQgbWF5IGJlIGEgYml0IHRv byBsYXJnZSBmb3IgYSBjbGFzcyBJSQ0KICAgICAgICA+IGRldmljZS4gV2UgY2FuIHByb2JhYmx5 IG1ha2UgaXQgYSBiaXQgc21hbGxlci4gSW4gdGVybXMgb2YgUkFNLCBpdCBmaXRzIGluDQogICAg ICAgID4gdGhlIDMyIEtCIGF2YWlsYWJsZSBvbiB0aGUgVEkgYm9hcmRzLg0KICAgIA0KICAgIFRo ZSBrZXkgbnVtYmVyIGlzIDI1NkssIHNvIHRoYXQgb25lIGNhbiBkb3VibGUgYnVmZmVyIHRoZSBm aXJtd2FyZSBpbWFnZS4NCiAgICANCiAgICAtLQ0KICAgIF0gICAgICAgICAgICAgICBOZXZlciB0 ZWxsIG1lIHRoZSBvZGRzISAgICAgICAgICAgICAgICAgfCBpcHY2IG1lc2ggbmV0d29ya3MgWw0K ICAgIF0gICBNaWNoYWVsIFJpY2hhcmRzb24sIFNhbmRlbG1hbiBTb2Z0d2FyZSBXb3JrcyAgICAg ICAgfCAgICBJb1QgYXJjaGl0ZWN0ICAgWw0KICAgIF0gICAgIG1jckBzYW5kZWxtYW4uY2EgIGh0 dHA6Ly93d3cuc2FuZGVsbWFuLmNhLyAgICAgICAgfCAgIHJ1Ynkgb24gcmFpbHMgICAgWw0KICAg IA0KICAgIA0KDQo= From nobody Wed Jan 30 10:23:42 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7DBB131310; Wed, 30 Jan 2019 10:23:39 -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 iBUAKq1rnU3g; Wed, 30 Jan 2019 10:23:37 -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 F32D4131313; Wed, 30 Jan 2019 10:23:36 -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, 30 Jan 2019 10:23:27 -0800 From: Jim Schaad To: 'Ludwig Seitz' , CC: References: <01e801d4b861$4d7d41e0$e877c5a0$@augustcellars.com> <76f048fa-fa03-4e5b-0b60-c5674a2ddad3@ri.se> In-Reply-To: <76f048fa-fa03-4e5b-0b60-c5674a2ddad3@ri.se> Date: Wed, 30 Jan 2019 10:23:26 -0800 Message-ID: <021c01d4b8c8$e5ee0ba0$b1ca22e0$@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: AQMO0G41vSMoQObT7FZTfu2Mz+Bo2AG5F3Zko0YkrmA= Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Ace] Shepard review for draft-ietf-ace-oauth-authz 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, 30 Jan 2019 18:23:40 -0000 > -----Original Message----- > From: Ludwig Seitz > Sent: Wednesday, January 30, 2019 12:38 AM > To: Jim Schaad ; draft-ietf-ace-oauth- > authz@ietf.org > Cc: ace@ietf.org > Subject: Re: Shepard review for draft-ietf-ace-oauth-authz >=20 > Thank you Jim, >=20 > I'll upload a new version as soon as we have resolved my questions = below. >=20 > /Ludwig >=20 > On 30/01/2019 07:01, Jim Schaad wrote: > > 1. Update the reference from RFC 5246 to RFC 8446 in all locations > > > > > > > > Items that don't appear to be resolved: > > > > * Section 3.1 - Refresh Token - I don't think that refresh tokens = are > > going to be strings because binary is more efficient. > > Unless you are going to say that this is not OAuth 2.0, then a > > refresh token is still a text string. > > > > * I don't see any text that is addressing this. >=20 > That text just describes how it is in OAuth 2.0 (where refresh tokens = are > strings), since we didn't see the need to specify the use of refresh = tokens in > ACE, we didn't mention them further. If we had we would certainly have > defined them to be binary. That would be fine, but you actually do define a CBOR mapping tag for = refresh tokens in the body of the text and define it as binary. >=20 > > > >> On 22/10/2018 21:09, Jim Schaad wrote: > >>> * Section 5.8.2 - If the RS is going to do introspection, can it = send > > some > >>> type of "Server Busy - try again in xxx" while it does the = introspection > >>> rather than just doing an ack of the request and possibly waiting = a long > >>> time? > >> > >> This is probably transport protocol specific, and we were asked not = to > >> link the framework to a specific protocol, thus I don't know if we = can > >> provide guidance here. > > > > I think it would be okay to say something like "some transport = protocols > > may provide a way to indicate that the server is busy and the client = should > > retry after an interval; this type of status update would be = appropriate > > while the server is waiting for an introspection response". Which = does > > provide guidance, but in a non-normative fashion that does not = require or > > prohibit any given transport protocol. > > > > * I don't see anything that I think addresses this issue. I would = expect > > it to be a security consideration >=20 > There is text in the draft according to the suggestion above in = section > 5.8.1 "The Authorization Information Endpoint". Should that text be > moved to security considerations? No, I just missed the text. It just took me three times reading through = to find it. >=20 > > > > Comments on protection of CWT/Token: I am wondering if there needs = to > be > > any comments on how a CWT is going to be protected. While it is ok = to use > > either a symmetric key or a direct key agreement operation for a = single > > recipient without forcing a signature operation to occur. If the = token is > > going to be targeted a single audience hosted on multiple RSs then a > > signature operation would be required for the purposes of = authentication. > > >=20 > Right. I'll add some security considerations on that. >=20 >=20 > > ****** IANA Section Issues > > > > 1. None of the new registries appear to have any guidance for the = DEs to > > use when approving items. >=20 > Is it acceptable to add a single guidance section for all of the new > registries, or does it need to be separate for each of them? As long as the guidance is comment this is fine. That is what I did for = all of the COSE registries >=20 > > > > 2. The title of the registry "ACE Authorization Server Information" = is not > > really descriptive of what is in the registry. It makes sense in = the text > > but not as a stand along title. Something along the lines of "ACE > > Authorization Server Request Creation Hints" seems to be closer to a = solid > > identification. > > > Would "ACE Authorization Server Discovery Hints" be better? I thought about that, but it does not really cover the idea of having = the nonce value there or the possibility of later adding things like - = ok you should use this audience or this scope or some other similar = thing. >=20 > > 3. The mapping registries should use the OAuth registry name as a = prefix. > > Thus "OAuth Access Token Types" and "OAuth Access Token Type CBOR > Mappings". > > > Done. Actually quite some changes were required to align all of the > mappings sections with the OAuth registry names. >=20 > > 4. What is the initial registrations that need to occur for the = "ACE > > Profile" registry. If there are none then this needs to be stated. > > > It's initially empty, since draft-ieft-ace-oauth-authz doesn't define = a > profile. However the DTLS and OSCORE profile will provide the two > initial entries. I added a sentence to that effect in the IANA = section. Yea, I thought that was the case since the registrations are actually = done in the profile documents. I just wanted to make sure that IANA = realized that this was initially going to be an empty registry. Jim >=20 > > 5. For the CBOR Web Token Claims - how many of these should have the > JWT > > Claim name filled in? It would seem that all of them should. If = not a > > comment about this is needed. > Fixed. >=20 > /Ludwig >=20 > -- > Ludwig Seitz, PhD > Security Lab, RISE > Phone +46(0)70-349 92 51 From nobody Wed Jan 30 13:38:46 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 117DF130FF4; Wed, 30 Jan 2019 13:38:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.552 X-Spam-Level: X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KoOynPwW_dKn; Wed, 30 Jan 2019 13:38:43 -0800 (PST) Received: from NAM06-DM3-obe.outbound.protection.outlook.com (mail-eopbgr640122.outbound.protection.outlook.com [40.107.64.122]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7992130EBA; Wed, 30 Jan 2019 13:38:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=eqZKPcZDi5ufv4voM1ufLGKGQkOwRtFjPzf5mx2wN58=; b=k4VGe13bOIFxHv8KSX8FoRdoOHB5SdDUESCrSTOGN0WCgRtgxWz/TlynIzHXK0KjSfqzXo76p81jx2/z4XNfqXPAkT3QlRPm5/vzmCHXWLWSp4TAMLVJWhy5drOqRxAWQM4WfbHIs3mGuQg1/41BZn2QvtEkQauPVsv5MiZRC9Q= Received: from BL0PR00MB0292.namprd00.prod.outlook.com (52.132.19.158) by BL0PR00MB0308.namprd00.prod.outlook.com (52.132.20.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1617.0; Wed, 30 Jan 2019 21:38:26 +0000 Received: from BL0PR00MB0292.namprd00.prod.outlook.com ([fe80::142f:63b7:9c88:3e65]) by BL0PR00MB0292.namprd00.prod.outlook.com ([fe80::142f:63b7:9c88:3e65%6]) with mapi id 15.20.1618.000; Wed, 30 Jan 2019 21:38:26 +0000 From: Mike Jones To: "ace@ietf.org" , "cose@ietf.org" CC: Michael Raer , "Maciej Wolowski (Arvato Direct Services)" Thread-Topic: CWT equivalent of JWT.io Thread-Index: AdS446Vz+eGD1/6eSwmWzB0QjK0wJQ== Date: Wed, 30 Jan 2019 21:38:26 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [198.214.83.44] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BL0PR00MB0308; 6:RELxggneU1u5InzCNbPlLpBhK4HX0dknuPHMm5k6NJK/4bAlGuNouVW4rg5ClffMS5J02x7YoY8gmkqa2yh91yQqtTAkVU9rXoey8L5DKfiS1OdJ8mKo+LgR770Vb6vRscJjfMf9BcRm3Bwa3i9XMbOrBsSOsNRUp2W5gexXsjWaM0WDb0JBqCwdzLUmP1slgbCYjWJkTAt8HNtPJ3VXo30UYSFoI3DnDcMSzkJ1s8zwdYr43hMZ7y9nTLVPJzT3z5u4PwIc/uB6XoH/AbXSDqWpPLxC16NfS0GLIBm3A0MwrQNta/95UlG9Pe1obR7JOpE9WdDErLPCyQtB+iBS8a7a+3yioXwbvAeotkCoUP28IZG6Po2pZlOra0bo6nZfGZZ1es0/RgW3R8i84AFwQ+2a5ghn5xHrVYR2a9WUHeJisAPs8cCzLtHhGjkWiyi69FhhxUEaKQzY0d9ysa2Irg==; 5:82v7KkflB3cCEyhDny82xgfxkWLSg9VHzD2mvapyfJyrs/toDrurG2gvoi51Sv/o7+pWoke4E8uRg2OFcErsa5TCHwLt8GwsJF6l4vXoo2/kpB/5n7mlKDxsPA7yozT4y/V8tiJ1v9//AAKYpqMmdI5y0Mcy2fzIa3waECVr2SYYWcKxDm6CdwKyGW5MJlW+xKG1b89d3pjl5oRfymw8UQ==; 7:lpS4FgCO7qkKFm7yzW7v1nxqQKCKjlGPzrStO4gwXSVqXhpghkUdfiW8z7h+AJ4dl7gJaWVPm+ij9V1DecnLRmFp7oERv2E0Ffkh1xhTe5oKZFN36bhU0vvjfoeYa7UE30zvTd3vU0+xtYOGDF6HOg== x-ms-office365-filtering-correlation-id: d40f6adf-8c74-4a84-dc7d-08d686fb44d3 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600126)(711020)(4605077)(4618075)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:BL0PR00MB0308; x-ms-traffictypediagnostic: BL0PR00MB0308: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-forefront-prvs: 0933E9FD8D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(376002)(396003)(346002)(39860400002)(366004)(199004)(189003)(72206003)(236005)(186003)(55016002)(476003)(107886003)(6116002)(790700001)(3846002)(6306002)(54896002)(14454004)(558084003)(450100002)(486006)(110136005)(9686003)(22452003)(54906003)(26005)(606006)(10290500003)(25786009)(99286004)(7696005)(478600001)(316002)(4326008)(6436002)(33656002)(966005)(71190400001)(71200400001)(68736007)(81166006)(8936002)(53936002)(81156014)(2501003)(97736004)(7736002)(10090500001)(2906002)(8990500004)(106356001)(8676002)(86362001)(102836004)(256004)(86612001)(74316002)(6506007)(66066001)(105586002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL0PR00MB0308; H:BL0PR00MB0292.namprd00.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: +eHVFXxyQu2tigep8/VQ4DQPnuGcfUwWLwL7padfP+vPZKMz3DS5GDNL7Jx55WSgm2IN3XBtCaKJ9l2v/Y4mydmhvkPa76K6wJzSVWrm+X8ETKKlm9vDwbSVZlIK1v9Cp0AkwRHbgYDDfL+NeFuobM/thez7XhOBqUxUNyAQeMqoVX3tbAr5xqtQEjBKBtezisT2CJqoHAYoz43il8p4f2i8e18mlgB/wkDcW6hcyBkwmSGZ6FklGn8H5fjZEJLiq5ievF7PBBVpxps0hiYTQjVMeNBP652yTbRJIe8rVuCft2zXeYnY2xIqqbS8xLyewWVYAsGZi0kk9SzM+CSuaYM7mWuzjb5win5pZS+VSJ3upezd191dhbkVtpBxWDmHN9azPjiVXINYwazfRWrzftC8QoHawNV37CrBnUDmDL0= Content-Type: multipart/alternative; boundary="_000_BL0PR00MB02928FFC64B05D3A2618CC6AF5900BL0PR00MB0292namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: d40f6adf-8c74-4a84-dc7d-08d686fb44d3 X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Jan 2019 21:38:26.6913 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR00MB0308 Archived-At: Subject: [Ace] CWT equivalent of JWT.io 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, 30 Jan 2019 21:38:45 -0000 --_000_BL0PR00MB02928FFC64B05D3A2618CC6AF5900BL0PR00MB0292namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Does anyone know of an online tool that will decode CWTs like https://jwt.i= o/ does for JWTs? Thanks, -- Mike --_000_BL0PR00MB02928FFC64B05D3A2618CC6AF5900BL0PR00MB0292namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Does anyone know of an online tool that will decode = CWTs like https://jwt.io/ does for JWTs?

 

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

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

 

--_000_BL0PR00MB02928FFC64B05D3A2618CC6AF5900BL0PR00MB0292namp_-- From nobody Wed Jan 30 16:34:35 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D19D130ED6; Wed, 30 Jan 2019 16:34:32 -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 HbcJr0urd2jP; Wed, 30 Jan 2019 16:34:30 -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 8D408130EBF; Wed, 30 Jan 2019 16:34:30 -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, 30 Jan 2019 16:34:24 -0800 From: Jim Schaad To: CC: Date: Wed, 30 Jan 2019 16:34:21 -0800 Message-ID: <023901d4b8fc$b72658c0$25730a40$@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: AdS4+whFigFTKC1DQi2kqlxsKsGuhg== Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: [Ace] Shepard comments on draft-ietf-ace-oscore-profile X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2019 00:34:32 -0000 1. Please update the text for MUST/SHOULD/MAY to include the language from RFC 8174. 2. Section 3.2.1 - What to do is clear if a field is not missing. What is the correct behavior if a field is present that the client and/or resource server does not recognize. Is this a fatal error or is it sufficient that they may not behave the same? Jim From nobody Wed Jan 30 22:36:18 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8F22129B88; Wed, 30 Jan 2019 22:36:15 -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 Bo08RdIUgnKm; Wed, 30 Jan 2019 22:36:13 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 848DA128AFB; Wed, 30 Jan 2019 22:36:13 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost2.informatik.uni-bremen.de [134.102.200.7]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id x0V6a0kq019269; Thu, 31 Jan 2019 07:36:07 +0100 (CET) Received: from [192.168.217.106] (p54A6CC50.dip0.t-ipconnect.de [84.166.204.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 43qr8w4BsPz1Br6; Thu, 31 Jan 2019 07:36:00 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: <023901d4b8fc$b72658c0$25730a40$@augustcellars.com> Date: Thu, 31 Jan 2019 07:35:59 +0100 Cc: draft-ietf-ace-oscore-profile@ietf.org, ace@ietf.org X-Mao-Original-Outgoing-Id: 570609357.985154-bbc2374f8a23e801dccc883bdb8cc71f Content-Transfer-Encoding: quoted-printable Message-Id: References: <023901d4b8fc$b72658c0$25730a40$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Ace] Shepard comments on draft-ietf-ace-oscore-profile X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2019 06:36:16 -0000 On Jan 31, 2019, at 01:34, Jim Schaad wrote: >=20 > 1. Please update the text for MUST/SHOULD/MAY to include the language = from > RFC 8174. (Public service announcement: If you use kramdown-rfc, just say {::boilerplate bcp14} and that is taken care of, including the all the references needed.) Gr=C3=BC=C3=9Fe, Carsten From nobody Thu Jan 31 01:20:33 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0A96128D09; Thu, 31 Jan 2019 01:20:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.044 X-Spam-Level: X-Spam-Status: No, score=-2.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 TJIbyZya0Cjh; Thu, 31 Jan 2019 01:20:28 -0800 (PST) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10065.outbound.protection.outlook.com [40.107.1.65]) (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 BC76B128CF3; Thu, 31 Jan 2019 01:20:27 -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=4lZ3Q2jsSi4TfartC6j304U0BpCNnjEe5Z7y5js1is8=; b=YHLxfEtDyWqF0IMsnPcsYkvvreo3Q/+IzkR1SNQtVuBCYLIb1STwNc89YN9/RRk9G8PXw+xj5mqYwAZ2jyjBVfr63oCgvauOMReL9UtIZ+OZdlkE+JTtClKjR/2KvcTEYpKOCFT0hWjkaxMuzMWimBy+TdMoAohj4ygEhXI5BgY= Received: from AM5P189CA0031.EURP189.PROD.OUTLOOK.COM (2603:10a6:206:15::44) by HE1SPR00MB03.EURP189.PROD.OUTLOOK.COM (2603:10a6:3:6e::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1580.16; Thu, 31 Jan 2019 09:20:24 +0000 Received: from HE1EUR02FT022.eop-EUR02.prod.protection.outlook.com (2a01:111:f400:7e05::201) by AM5P189CA0031.outlook.office365.com (2603:10a6:206:15::44) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1580.17 via Frontend Transport; Thu, 31 Jan 2019 09:20:24 +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 HE1EUR02FT022.mail.protection.outlook.com (10.152.10.78) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.20.1580.10 via Frontend Transport; Thu, 31 Jan 2019 09:20:23 +0000 Received: from [10.112.134.122] (10.100.0.158) by sp-mail-2.sp.se (10.100.0.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1531.3; Thu, 31 Jan 2019 10:20:23 +0100 To: Jim Schaad , CC: References: <01e801d4b861$4d7d41e0$e877c5a0$@augustcellars.com> <76f048fa-fa03-4e5b-0b60-c5674a2ddad3@ri.se> <021c01d4b8c8$e5ee0ba0$b1ca22e0$@augustcellars.com> From: Ludwig Seitz Message-ID: Date: Thu, 31 Jan 2019 10:20:23 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <021c01d4b8c8$e5ee0ba0$b1ca22e0$@augustcellars.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.100.0.158] X-ClientProxiedBy: sp-mail-2.sp.se (10.100.0.162) To sp-mail-2.sp.se (10.100.0.162) X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:194.218.146.197; IPV:NLI; CTRY:SE; EFV:NLI; SFV:NSPM; SFS:(10009020)(136003)(376002)(396003)(39860400002)(346002)(2980300002)(199004)(189003)(13464003)(77096007)(81166006)(40036005)(11346002)(8936002)(69596002)(230700001)(53546011)(53936002)(6246003)(386003)(229853002)(4326008)(3846002)(65806001)(47776003)(65956001)(6116002)(104016004)(16526019)(26005)(7736002)(486006)(476003)(336012)(126002)(8676002)(65826007)(446003)(22756006)(356004)(81156014)(44832011)(186003)(2616005)(305945005)(22746008)(106002)(86362001)(23676004)(64126003)(97736004)(31686004)(76176011)(33896004)(67846002)(68736007)(110136005)(106466001)(16576012)(58126008)(2486003)(50466002)(31696002)(36756003)(478600001)(74482002)(316002)(2906002)(14444005); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1SPR00MB03; H:mail.ri.se; FPR:; SPF:Pass; LANG:en; PTR:InfoDomainNonexistent; A:1; MX:1; X-Microsoft-Exchange-Diagnostics: 1; HE1EUR02FT022; 1:SkpTj+mrzjNyq70qaYammLTOeSahwN0s5cKTToSsIxyVs01mmd3sp2OvjPjkMNmWqgXy4hwXUcY5fG1KpdlEAzv4fQK5MP6sDnYJSwFwTYPv/4JvIfWVhKhQeqF6oYNN4abiLOQpY4TubTKJdLz78KP7xjExiPzGgXBY1rYD4MQ= X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 5216ba35-81c3-4295-4895-08d6875d54a1 X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605077)(4608076)(4709027)(2017052603328)(7153060)(7193020); SRVR:HE1SPR00MB03; X-Microsoft-Exchange-Diagnostics: 1; HE1SPR00MB03; 3:sjupoc9rHIy0l3P+hyQpO8mt6TYzw6ZU4BwwFHOXi6ltanDwNUEo5iG7ECzRSliUcOva3QS/eoFbtf1kUQYVwfueRhDoIYXnNV2e7GUC7fkKa1YcxxsY5VypfOWK8cbOVksND4ZPdYCKrh6YlBZ/E1vKYjqg1crYaKuAjKUDQrwmxrdlIPmxGOMJDOS0Qm6ef/NuidKDxjS9CoXi/aRYvoC+geeGIi23YKlzXRkbU/jY4uJllWg40y2zh4kbDeTGSDbQC2w8r9bpfKj9cTSNK8fsQWJhl0hJWKioQZXPyQLxwlzB34k/QXPexzkVdxaV9iNxy76iIzhvWLzvU1LVJqpqG2x+V2eV3vde3hIUOiio0eT+m/5TJbYfuSZp/6+C; 25:W8eByzf0UD4VObutDXUgUFMIYugv+zA5fmE/OcZav0+rwqBr09HSHn5b2HmmorAIr9Ow1ObbmNj7nWovfwY91pyJ6zNZhOo6vVqNOkKXvLbE3PVTIuYdbuglh1IJ9vfrvIpD2f1lmbwYBNpPKltbkkhduEWQ4vqa4aiIqBz70nBXaXOo7WkO4+gt+v4GHq/y7cejBjsTrAszcage3r018haVl3tOveNoX+IzFT3AMmXXRkcfSfSuqrAipSAfwVXnMSFlvu9BppqhVxJt/akrmnT8iDwpCPYlIlDlME9t//UAB16+Ij+eT5h/BCEbTNBnKF+ip9jeMfGUicw39AbiHw== X-MS-TrafficTypeDiagnostic: HE1SPR00MB03: X-Microsoft-Exchange-Diagnostics: 1; HE1SPR00MB03; 31:tGkdSn9t7Z4TeEPkgavSjdIipij6UQ10F+SGPu6oGLyUfS5W8T/ATtfcIT1PuuyOCskuoZsmdMkouOOw10pf7HHIHx7fBg/iOYbDEm3YQVr2/Vdbk4z0wuSTxFlo/0QM5yheKJzrH6lcd6/W4/APriM2xA/rV3plrcCKTpDRmr4xNYy54IXEqvKu/BmTMgT4UO4qiR3wOI662gQfSMXfWR0HTz9OE10uam0WvAJakSs=; 20:KbqNEwPJj2Tjj5SndnKqrsJWURg2uVyAcUbyoPAsIOv3xCUkuV3riRSIPDAqG2TH204gPNdC6OOGJEw83iUY9D5y19TtbBzqXikAwBejdCMmjAKE/v53QSX/vwNXMTrZjiUcq7E8Pjgq1iKdI948RZY6SF57tSs8M7WS6nBry7FjqJoCUBtjQQVt42AGVoYsPbWr17jkVyRGw2PiPhxx3QWX+94CEuVxXxWw/I+k5SYaRsqsB2j2S6ctH0mT8mfo; 4:dIUfb4G6abH7xb2Adpa176UAt9B3yg3/jHNwArK6YqFqnIPXNhNhVNsbt+hjZPxniTqhfP3IxluVTZJmqmYDVwsfDWupFHygtNj17P3obVi6fDxQNjGWs44LztpBL7lv34IS3BO0dsss3ut7UjMNZPDFQHJGlH9Ug4dr7aUbzYeRBt71ZM0qzp82+6WZslzX1fWzILrK7v0JVw+FzYZRhJa685RcIKUc6xvC40u0JlIDOLtNIi3SLdCQ6prjZbgOFJYO84yDj61DxVftQ/qtK59rmMOinUeJgsoIG1oV1k4sSVLd6Trsh8s8aipcEznH X-Microsoft-Antispam-PRVS: X-Forefront-PRVS: 09347618C4 X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtIRTFTUFIwME1CMDM7MjM6aEJUaStpSUJ6K0ZscXZtQ0dqTFdNM0hadUZI?= =?utf-8?B?SENUWDRKcC93dWtpS2FYbUVtbWUwUVR1K21IRzgzWloyUVIrZUhtNUp6bnlK?= =?utf-8?B?RjA0cTdlbUR6c082VTlVaGFSbGNydUlHRXkrRVVGSi80emxCeXFibW0ycDJj?= =?utf-8?B?b0MzRUEwQUlWTE8xcFRLR2o1dHcwd2ZGL1oyenRDdVh4R2ZvVG1ZaDNUa3pY?= =?utf-8?B?N28vRFpxMDhCTkdtQ0xaSmJ1QjY3cm8xV2RWNStTMEtYQllxd2xHRGNzcUNn?= =?utf-8?B?cmJUYzJ0YUhXanJ0ZTkzbkpjT2pyRFdSZkJJTjFMTEk3TElPOFBBVytWM1lp?= =?utf-8?B?aG1PbDhmcGl2UDVOVHBMeXlQNkJOV3hmd0hCdkp0Rm51VG9kSzUvMjFmOFFE?= =?utf-8?B?U2JCMlNVTnJiUHdNT0JtdkxNcVV2Q2hTQndaNURid2YvRTdvbGgvM2VjdFp5?= =?utf-8?B?NnZLRVNNc2UyUzI2SkZ2U2UrV0pTMGt5VFJhU1B3SHBvU2ppVTlVbTBtb1Bx?= =?utf-8?B?WnR5alBoaFZNRTlRdS9SS0FObUZsN2RNdWxhNTM0aUIwc3ExNXpOWUxNcWRI?= =?utf-8?B?b0hvOWhIMG9CVWxUWVdFdGhYTzdYK1dVNkZtTXk5UDE5TUVyeG8wZm5IUnhS?= =?utf-8?B?TkkvNXJiL2lZVTlVa0Q2U2hqTjF1cUU3c2QwVFVsNUlmdXRjdFpWNmlGV1cy?= =?utf-8?B?TkV5TEFlall6ZzVJOEZhUEY5bXJ6OVlvQVZNL2JPMEh2VmFlcWt2cVJzT0M0?= =?utf-8?B?SlN0T0trZkdacWhobjlTc3UzdDI1ZzhsU2ZDVFNMR3lqV3RRRFpnSXAwemxh?= =?utf-8?B?Ty9CVGx6MTJuZ3NUMWpQVlZsKys1eUVBZHorNVFKSXRJS05rc1A1ZDh4UVRi?= =?utf-8?B?NkZUdGtlZzhiRmxZN1hNckVBWkR5bTByc2xib1RBTUQ0YXpMTlJPL2d0d241?= =?utf-8?B?djMwaUxpYTh1Nzg4eXJkR0U2WmtQZUttNUpIQUdLaDRMbVo0YUw1bnRQd1Fr?= =?utf-8?B?MDZmWWd3NXh3RjRMVC9uV2FrMFZEczQ2VmNaM3hkWEVEYUJUK0R5cE1TOEY5?= =?utf-8?B?TDNYSzdtei9xMHh5cGtndXhxcU5XWHB2YzRFWEdCaFlsSmJMOGtsN0RQUFN0?= =?utf-8?B?THBsMS9Uck9kNXF1ZDd5QnNFakVXTmZ4SDh1SVFON0dNUHBveUxEUXVGZm5o?= =?utf-8?B?T2twcXgxbkVIOWE2bVZhV3RpbXRLcmdqeEhES0dXNDZDaEYydjRBeVE5Ukwx?= =?utf-8?B?RzFRRHBWd1E3RGpQb3RIUmdyZ1FyYkRYSHhENEpOck5HbHNOVm9zMkhiNjdN?= =?utf-8?B?dTRtc0pRb2FSSk5mNDhkejZZRmVEUlBsUjk2dEpsR1BiOXloLzFxZzl3bUZa?= =?utf-8?B?a2ZlL01jK0Z4VWFjazlMRVRxSXE5UlYzdmRRVm1IT2RFd2ZEdkJ0ejFWekRa?= =?utf-8?B?WHpIWkVVdGhFd0paSlgyRzFXckU5Y29NUDRKRmVuUTZ3VG4wZ21hOFVkU3h0?= =?utf-8?B?REJBM2hVa3FpRlVjVk9DQWVkZHZqTyt6U29VUHFIQ3RRc0pJZFJxckh3Y2tH?= =?utf-8?B?VkVmakM4QVAvdTZQcWVra0Fha0NhWFM3ZnZrNWJ0N2RMcWZXd0FIRnladlNF?= =?utf-8?B?Y0pRV1ppbFBpam5lY1RXa2haaU9qclA4Nkk1Rk82UFJuMHB2OFdiYm9MeVM4?= =?utf-8?B?SXZsZ1M2R1FSclFOOEgyMDl6WXhPdGptczBXUzVKcUlNN0s2TmY4Myt3VGxM?= =?utf-8?B?bzk4bEFudlM0YWd1Nm9UWXp5ZjcwQTFrUEhnL2lPczlkaVNqK1YwWFN3NXNJ?= =?utf-8?B?SjZWRmc3ZHRRMS8wZDJKeVIvcWNOQ1ZMRDhKQWVQNlh5U0FRNlVIYUw3WUlk?= =?utf-8?B?SGZwbHVYWEJWQkdUbDdJSm55Tk01ZlQ0bXNCWFEyVDBsNU9VMlNnSnZtWG4w?= =?utf-8?B?ek1qN0pWZS8xMXd2VHA0c1Q0OXdJb3hoOUhqQmEwYzkvUHV4bUovNzk2YWZI?= =?utf-8?B?SjBYaUhXWTk1eDF1WW5BMzluVTBPUzdqSmZlSWdaK0JMRDE4eUFQcUF4MmdF?= =?utf-8?Q?xWc=3D?= X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Message-Info: 7RQvN9zvpth2Q7wW3fmuHNZBqhbp1yIZBqwgfPX9z8yywc2Gw58FvKhorOmEFqQdzHAeaXWuzf+5rVSRYAhDtEAmIkmcKghO+i0kX0AzwMeP7cSaTDp+tz02f4l+QkL91cg6u0ivU8Cqjg4xmpA7GMVSkmdDrpKcz8U2QgtjdMO/gapx2ZCvXOFGzJwI7qH7Zp+HmKkSkzRyX3ZgHUncLh8XLVKEIAMMvM9YTiLgdqlxXk1DA/jzUapIRSTUTzaV0muyiUf3zrOII9YrCxP9RBzq1l/DFtFvoxgPcYd0FiVNeT//CzRUod4eE5Q9CRIZsJBJyw9hODgdOTPNHJ0e4/QiaEFarCZNL4xEt20kSOCeqrc29/ydfjh6uh0aDDkVQargvMJ5sGdAo4XCUbCCHEE1/AhbqHGn1GJJH2x0RyA= X-Microsoft-Exchange-Diagnostics: 1; HE1SPR00MB03; 6:OQvlAVANUcXZJW5qk5DlFx69KfpD4oV0fG+g2GvX3mInRNQQVfUak/AXic2jWFI5QLKnsSssEVoRsguv5XzLWcABamZl1+eF5mlKDTITNfmDk+dbggEGVn3NGCRhbr7xc9c3YIy6YvTGMVOeBRYlL5Vc1aDnYUyLbSvKhNLTBmJyJ6juVFXrtRsl7BhML70HOgir3hiifLrSZM8a1FpZHhEK3heCD/bIYugMVyW/bKzjjQPE99Ksh9guKgcbKJLpfnoKGFplHPNmbMgT6mbg02+Bn9E2yHpcag0g1FeCyKIhWW1IPLz9T5P0wbXYS9/B599+tWv74Ab8jn4CDT06/zPbjsYczW5cc7UK4DukFQQpmY/Vjp+h2uLzG0Bx0QvSIn9TZuVWTs14iP9DoSYO06AH/x6i1GTKO6zanuHt5KrEE5cW7YODt9wn/y0oWHkm7w3LpYP+Fk8EW00BVzAv9Q==; 5:3JPDGfYqBiaoDACjPKg0xEwgpxECTju2ANZ794ehBYvjGd4J4rcXcvy9QlxWB4Lecke9deUDQKy8p0/fj3JeBgkUVLUf0jKX1u81LryNrWrGn6CiOzZXQJcfpgB5qrI3H/Vf7JiuVLeu2hG6FJuy8ib91WzLC80qMCTBbVXAM5HLzQhyH3F4jkqTuT2n2NL0RckSHYznG/qhb3uTfYIcGQ==; 7:dbgk9jQmSB2OT0gyq7U9syXg4g53AVPgUP6/HLajFdJjqFVAXebxQ1aRmwXteAduN+JCI1OOHVyyBfxX0+jm+I/wYc+b6RdTbZnP4DPBvkN5PnFtXc+2vJvdMHeP1YxL/hDr/psx5V7WgCWBiaMCYg== X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-OriginalArrivalTime: 31 Jan 2019 09:20:23.9406 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 5216ba35-81c3-4295-4895-08d6875d54a1 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: HE1SPR00MB03 Archived-At: Subject: Re: [Ace] Shepard review for draft-ietf-ace-oauth-authz 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, 31 Jan 2019 09:20:32 -0000 On 30/01/2019 19:23, Jim Schaad wrote: > > >> -----Original Message----- From: Ludwig Seitz >> Sent: Wednesday, January 30, 2019 12:38 AM To: Jim Schaad >> ; draft-ietf-ace-oauth- authz@ietf.org Cc: >> ace@ietf.org Subject: Re: Shepard review for >> draft-ietf-ace-oauth-authz >> >> Thank you Jim, >> >> I'll upload a new version as soon as we have resolved my questions >> below. >> >> /Ludwig >> >> On 30/01/2019 07:01, Jim Schaad wrote: >>> 1. Update the reference from RFC 5246 to RFC 8446 in all >>> locations >>> >>> >>> >>> Items that don't appear to be resolved: >>> >>> * Section 3.1 - Refresh Token - I don't think that refresh tokens >>> are going to be strings because binary is more efficient. Unless >>> you are going to say that this is not OAuth 2.0, then a refresh >>> token is still a text string. >>> >>> * I don't see any text that is addressing this. >> >> That text just describes how it is in OAuth 2.0 (where refresh >> tokens are strings), since we didn't see the need to specify the >> use of refresh tokens in ACE, we didn't mention them further. If we >> had we would certainly have defined them to be binary. > > That would be fine, but you actually do define a CBOR mapping tag for > refresh tokens in the body of the text and define it as binary. > Right, (background: I did define a mapping for all OAuth parameters and re-mapped all that were Strings to binary. That does not necessarily mean the have a use case currently in ACE.) in order to resolve this I will add a sentence in the description of the refresh token, saying that we define them to be binary here. >>> ****** IANA Section Issues >>> >>> 1. None of the new registries appear to have any guidance for >>> the DEs to use when approving items. >> >> Is it acceptable to add a single guidance section for all of the >> new registries, or does it need to be separate for each of them? > > As long as the guidance is comment this is fine. That is what I did > for all of the COSE registries > I'll copy liberally from your example then (and a bit from the CWT RFC). Hope you don't mind. >>> >>> 2. The title of the registry "ACE Authorization Server >>> Information" is not really descriptive of what is in the >>> registry. It makes sense in the text but not as a stand along >>> title. Something along the lines of "ACE Authorization Server >>> Request Creation Hints" seems to be closer to a solid >>> identification. >>> >> Would "ACE Authorization Server Discovery Hints" be better? > > I thought about that, but it does not really cover the idea of having > the nonce value there or the possibility of later adding things like > - ok you should use this audience or this scope or some other similar > thing. > I see. I'll use the somewhat clunky but descriptive "ACE Authorization Server Request Creation Hints". I've also taken the liberty of adding audience (req_aud) and scope as optional parameters in the AS Request Creation Hints message, in order to justify its name. While resolving issues from the DTLS profile the authors have noticed two elements that need to be added to the framework: 1.) A definition of "Authorization Information" "The information an RS uses to determine wether a request is authorized, including the claims of applicable access tokens." 2.) Adding the "kid" parameter to the AS Request Creation Hints, so that a client can request a token with the same pop key when it has an existing security association, but the token has expired. The procedure is currently defined in the DTLS profile, but it applies to any other profile as well and should therefore be in the framework. /Ludwig -- Ludwig Seitz, PhD Security Lab, RISE Phone +46(0)70-349 92 51 From nobody Thu Jan 31 01:41:06 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAEE0128D09; Thu, 31 Jan 2019 01:41:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.043 X-Spam-Level: X-Spam-Status: No, score=-2.043 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, 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 JIXRAxyRzDv2; Thu, 31 Jan 2019 01:41:02 -0800 (PST) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20068.outbound.protection.outlook.com [40.107.2.68]) (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 84EB6126CB6; Thu, 31 Jan 2019 01:41:00 -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=epatKbGcmNxNHIQneuY2ItV/vVSTClL+4hEP6YDWf6U=; b=eyml7VEJNdVIgXNLncqIjXOjE4b5oLdOBcvLFjKAsDWzXBY0O6MIVpy2jHTlvqBQhej1zzf/B/PTrGnQZwFPte9llpyGODck5/Bv8RDiAh0HEVgP29o8KVGYd4O4Z0FyOtRXcwloBg4uLFFEgApU5H3v5COJ+wim7zrLmw5lt/8= Received: from DB6P189CA0016.EURP189.PROD.OUTLOOK.COM (2603:10a6:6:2e::29) by AM5P18901MB0097.EURP189.PROD.OUTLOOK.COM (2603:10a6:203:78::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1558.21; Thu, 31 Jan 2019 09:40:58 +0000 Received: from VE1EUR02FT060.eop-EUR02.prod.protection.outlook.com (2a01:111:f400:7e06::200) by DB6P189CA0016.outlook.office365.com (2603:10a6:6:2e::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1580.16 via Frontend Transport; Thu, 31 Jan 2019 09:40:58 +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 VE1EUR02FT060.mail.protection.outlook.com (10.152.13.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.20.1580.10 via Frontend Transport; Thu, 31 Jan 2019 09:40:58 +0000 Received: from [10.112.134.122] (10.100.0.158) by sp-mail-2.sp.se (10.100.0.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1531.3; Thu, 31 Jan 2019 10:40:57 +0100 To: , References: <01e801d4b861$4d7d41e0$e877c5a0$@augustcellars.com> From: Ludwig Seitz Message-ID: <1ce364d1-2154-3fc3-5589-5be3d7606717@ri.se> Date: Thu, 31 Jan 2019 10:40:57 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <01e801d4b861$4d7d41e0$e877c5a0$@augustcellars.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.100.0.158] X-ClientProxiedBy: sp-mail-2.sp.se (10.100.0.162) To sp-mail-2.sp.se (10.100.0.162) X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:194.218.146.197; IPV:NLI; CTRY:SE; EFV:NLI; SFV:NSPM; SFS:(10009020)(39860400002)(136003)(396003)(346002)(376002)(2980300002)(189003)(199004)(6246003)(110136005)(16526019)(50466002)(65806001)(2906002)(33896004)(64126003)(65956001)(53936002)(229853002)(14444005)(67846002)(65826007)(77096007)(16576012)(26005)(97736004)(6306002)(36756003)(316002)(76176011)(2486003)(23676004)(106002)(47776003)(386003)(186003)(40036005)(22746008)(356004)(11346002)(22756006)(478600001)(7736002)(81156014)(81166006)(8936002)(44832011)(106466001)(58126008)(69596002)(104016004)(8676002)(74482002)(68736007)(31686004)(3846002)(86362001)(966005)(126002)(446003)(336012)(230700001)(476003)(305945005)(6116002)(450100002)(31696002)(2616005)(486006); DIR:OUT; SFP:1101; SCL:1; SRVR:AM5P18901MB0097; H:mail.ri.se; FPR:; SPF:Pass; LANG:en; PTR:InfoDomainNonexistent; MX:1; A:1; X-Microsoft-Exchange-Diagnostics: 1; VE1EUR02FT060; 1:Hec88AiCcyjWDyx3Mrm/1Zh/LHyh4VS/vwXcnz97+tbXxqxWi+xde45+syR5rfEwn8Fm45uxtd/KSBr8gDFaOgjwXUxx2VPSskalS4SOSJdsM3a80Lh5Np4Qtize7GfNBnnDZhtVg2hx+RsjIHClq9ZSIxFGZbaYuzn+pIF/feU= X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 7752df5c-eb63-431a-8f60-08d687603461 X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605077)(4608076)(4709027)(2017052603328)(7153060)(7193020); SRVR:AM5P18901MB0097; X-Microsoft-Exchange-Diagnostics: 1; AM5P18901MB0097; 3:P0u4EnayOs0eDeCBf0Eh848XDRtXZLOphV1eJq09IwmnQNWxjKTrj1lnP0/HG+rjOCxmK3xqxEK1xW+e3aHDV+syNgwq66reFl9LVUm6cLB+J08+54qptP/S1QXYSgGGck1tqCKhiUpkR73o760+M9M2ZSecox8vfnDaMXWkd7itzN2lC4nbgJE5cNRUQF+eXKcxhU2WwvYAgQdF6N/ZwNeFrF0qTxZjojrpd9IiSStTxOjMZ58Gu7Jduu2D2DjjPp6048nzagmPVlCPz6W0WSkP5aCCl9IycJy82Meq4CvbRFKfrt8GuzrsFersD9y95uJeJmjCUwGdNyHK6C7T8/fKqMDEIV05UKT3EbiW4FtvQ6Z+8Xs7mx0PbnBYcEL3; 25:l84gLngiuV2V8WriUOBF530pOviRVanGxD5TJbp9Rb0Rm3juJNI8Mz8shOKDieQC6nqtltsmFaXgtge8peeM3MBl3gUR/PqJ1R/cIwmL+7ODRPHpIM3v0g3eCrcv17C/F55cpyzYN9khB0yVEkmHfG+u/bjUmbultsX1q/W6MDRjirmxEJ0Rwiol8VD5zNPvWZGuEi0J4KE3wJhdJh5qem18UjjhOoAVexYLk7z62GxkuOOd0ff9UTNHhJXkL4NuDwk8cGXCta5YVg/D4EJ+yRVjwzCmWkLYmHKqnla3+LTFOhokzCLf4US9p4JJDJJNBjwD5bBbfe+Im/EJNhLvng== X-MS-TrafficTypeDiagnostic: AM5P18901MB0097: X-Microsoft-Exchange-Diagnostics: 1; AM5P18901MB0097; 31:a2rfHncIm5d/MX5K2XyicQIfidPfaGEegelJK6mJCXK6cOxOTMoV7Og1z4lCILod5rDEAbA4y78RcATsFVUcC0HZt01kY6o5lMRDEQafPRP0a5Ks47SrCZTQYhoGPJRaA1MiYd9LKyDawwJ9Pm/+jYUOcHqAmqXPGXoWHMUrZ6G4jba5rqPUmv2Ek+hS1YNcUtJ1h4kLvpfJuQE2M77LqJe0aVKvKmHNPGEsc/xDaYc=; 20:HPp7H2XgMZvjZjf/mV0nFzDxC+bber6K0kJ9xmBXomQV4bhFnRMkPxcIXC4PXt7HBFxrrT27BXjJU8oiUNTqAmsI6VrbYjOyfpuJ2IcaPqKzHiNHTLwPWQ6CBlxyWeJxxrdj5kWQmA3Ymen99aKbn+NjtyB0zRaYALrr7yg9AVkJsBYUi+q3MuZKgxHuXYC9tlLkEBSjMB1FHToiR6sZ1pNAG7x+L13WvZ8NPOSOI8iYqhiNIsFcL/ukR+8HIlsX; 4:nE9DKBuK8WMuO3CSQMdEEkvy/j7Dzas7BEmPeClTWZI4CWhiZH6EsQdoZJMjvBRUvBjM58OcP3J5teIBgNyN2kKQi0eSMLf32w+thF21DpM43tEzd4/Xr4HY5Rpss0gL4dcioeVZKPrdiToPVzjIzGv2wk6YBPsRcYDyDrLrYoKKHv97mO0v8NseAqJi7hlht+9EGP6KM10QXRlwqp3F9SPnkJg7hR+8P7onMexyADk28SrXSGJ/mm9+As0lhgyMnA8yA5mow2ZtAsww4CfWDUFOhzyKGxc1oMUusTHPpIjDMUV3q/VL6kGSGLPA707l X-Microsoft-Antispam-PRVS: X-Forefront-PRVS: 09347618C4 X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtBTTVQMTg5MDFNQjAwOTc7MjM6VHd3Slc0WkZIR0k1cWV4RWlqOHhWdjkz?= =?utf-8?B?aHU2eCt2Qks0bFNRbjhRdmdaZTMrR3d5N0U3MnRvZ2Y5b1h0MjVLdnJNMVhS?= =?utf-8?B?TFpVZ0tiWmcxcnJwaEFCK2RmcUsvb3FVTnpQUkU3VVRyeG83eExsR0lZcDYw?= =?utf-8?B?MHUwekpIL3RxTVhNUms2VDZKaGZPdEp6bUt4M2tTajZBYkRPNGNTWTF1R0gv?= =?utf-8?B?NXdiWkRML2ppa0Eya0d3OWVZT3cvOXowbU1BWnRlQTlSa3MxK2R0TlFTem1C?= =?utf-8?B?VmpTdU81QThHTElFQlZCVXlERktONGI5d0JrZ2ZHTnJ2WHZOZnFVZm9FVXBq?= =?utf-8?B?WnZsM29RRHFRdkcwYXc5Z2owM0tLblFnWHptbUdPaDdSQi9MR2xlM0gzc0VQ?= =?utf-8?B?ODN6TmpYUTUxeUl5ZzAzNUR2eVM1QWJHQlhmNk1HRzZycjRJZWdNWXk4a01j?= =?utf-8?B?a0pLRGNQNjIwNUJubU1taXJJSFo2Q0RqMFRNTEZGckc2aVVFUEpmVFM0Nzlk?= =?utf-8?B?L2oyQ2ZCVjRUeTZxZmtpa0p2UnlMNVJLM29GU3dubS9nMXNtdW1vQ3RFZjF1?= =?utf-8?B?ZTZKVThzeTF5MUZRNkpHU0VWV1RtNEtOZkpaRGdxTXUxL0hyOSswZExGbTlX?= =?utf-8?B?T2I2Vm1OK3pFZVhlYzNPdmRPeGo2MDgrWlRtZzVSL2t6ZXA2UHV2Q3hUWUdo?= =?utf-8?B?NDB6WTRZWDJkay9OeXVPMFdlTlVFdG9Db0o4cGtUZmI2T3hxTHJIcTgxOEN2?= =?utf-8?B?eFZyUFdhRCtlZWFveEFFUHIzcWYzSmtoZlRxVDdQTEVYV2taZ09ZQkxUUnA2?= =?utf-8?B?OEo2Vjc1a1VlVFM3REs3ZldORHpwQW9YUDVZbWpBL2ZCdDdSM2xVWnJDMWYx?= =?utf-8?B?enZaSXExdXZsTkxzZnNvTG1NWVIwWmhud0NKbCtydzBDQ2UzUjFPK21vV1Av?= =?utf-8?B?Yjl2NzJtdVRmUXZTVGtyODFXRWlvdFEzMWRFdHFIb0tkRndBY2k1eWxXUjZK?= =?utf-8?B?TVQrdjdodGhJSmxmdmdlTWNTOXVPNjRQTXYyelFNdC9pL1FzK3hldllqL2ww?= =?utf-8?B?YlYweGdycmIveXJJK2NhYnFsRjdqcER3YTcwSVp5RGVDM01yRUg2dHFHYldW?= =?utf-8?B?VlpNTWZMRERBQ0FsM3Z1ZFB1WnRWa1YxRlpmaXZwMURCV2RBVHcyVmtDOHVU?= =?utf-8?B?MFpiTXFwaWt4Zld0b2tsd3dDeHAwRlZnN0FLaVpEQjRBbEJWTHkvaTB4b2Zp?= =?utf-8?B?UFQxWlpsL1E2SHBrT3l6VWVLc1lZNnp1VEVBWFdON1F5bTBjdWxLMzc5MkpU?= =?utf-8?B?dzI4VlBYdktYa2tRVnROQmRlUnkvVWdKZFltRUpQbW9CdXVLN3lWYUkyTEpO?= =?utf-8?B?NTVETWZkRytZdzRETlR5MUVJWHBKSEFEbmRtdWdjOERPWlVzS3hYUGd0THYz?= =?utf-8?B?NkFhTGJTc0s5a2hFSWp2dGFrak1Eb1dhSDlTQVQ5clA0M0RNNGcvTjZXTHY2?= =?utf-8?B?aGczUkRzWDZyQTZjck1pRXV5dnZ5aDFKSDJ0RytwS094aWFnSGNiNmNpekY2?= =?utf-8?B?NmxSMDUwMmM0TjcrenlIVk9ZTlZBR0YwMVpsN2YxRnBIWkNsMG9QZnlKSE0z?= =?utf-8?B?ZW1yV2MwRDJWYnRoT0RCL2U2RFU5TnpuZ29MR0Vwa2dZV2FBTWFiVmcyamov?= =?utf-8?B?eHNVNVdBVTNBOEhINkN0ZlFIbm1XQmkxbGEvWlVqUEZDaTRRWks4UG9mMTRT?= =?utf-8?B?ZFhEQ1dMMjBNSFc5eFFRejFmWjlaUkEweUpaNWI5S0NnYTNIY09lU2hKM2x0?= =?utf-8?B?ZGhGalh4Z2dDc2tMRVE1bHRvYy93Z1dkck5SWFI2cW9hTHpnc1p6ajA2a3dP?= =?utf-8?B?WGFCakFWWGZuWldKdVk1eVJHZGE4N3lKZVVMTFppYklrenZYVzI4NDN0UXFD?= =?utf-8?B?UXJuWTByZ2FyNktUNy9SK0Z1TG5icWIzZHNKR1Z5WlpXb2xnMU9xOVpGSVVy?= =?utf-8?B?Rm9UK21JZDNvemo0UHNjdy9wMFVIM0NnMjRoQ3Q1M0VjOG5uS2ZabkQrbmR3?= =?utf-8?Q?AGYiXk=3D?= X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Message-Info: 2hOAZOabRHjpYF6jo2lKLJdD8t2GabaZbBPhRLcRzocK7MxIUDeokVXCnko5vBILcyON+bdOJLoFSrnJ9uFTkRkVMxmoirfr3lg73U1Ww5KwzWsRstKHNJ35mm+y185HU5ATmtVDLeCzA0i+UcYusEIV2slUh2vQ406p8HlXH9tecDXAwGBf++m+AOiRov3Uw8LUNupCZSgQgr+AIyr0FWDxSa5pNWeGUV5KbudIRKrkMLF+HuEqIbU67RvnPITE3Yq3rFi/p6/Vv1E6nSrg8RYoGgQNma/h8Ucj6ek6DyxmnEIlUhvCk2bvoDJKMvwY8AtBoRdC0t32jHSv3Q3n5SOvU9RyREnEQJyEonrOM+pTnGwi4kaB7fJyvdjec3SWjkWIQi5O7ufMJfraCmcRrLGTx4R+xW6Ca6Tu8uuEI6o= X-Microsoft-Exchange-Diagnostics: 1; AM5P18901MB0097; 6:aD2uuu7yT6BInUvYQiRbWLLgHO4jVKzecxh16B1Omy0F/30umuAK3Ez7YBsONvLhgu+2ugLDK8RTusf3JIBt6j1wzrin0akN92K3WPZfDy8a3/u0knzHbA4YgBM/8jK1UJB2RLIeVYqeb7K4mv91pOsXIK5z0jXjVaLLeNfFpq8xdROh8+XI2IMFRgKdudfxqw4+6EsvkEASF0bnt/30T3McRCJa0XnDPmhO7aebbG7btVSb2lKzh1HQv7O0ADUH58hbJHeNPDigydTd6PyJgxghTXfTl9h9P9+j7qv0cIDxNXZycfYbaSwsM7i+ZZeAfDwrd4uEZ2Hzvujsr7SYbvbBl54u/CpzdB3VHpepWSlk5AiWKUGoipKAsNPRtOhLy+RwTEKIHCFOytbNHLHIrH4bKkmvZUh6tIbhSgWj2SrWleVT3kTMAn3chA5HbBTSEBn+QDPwvWRfixwJqt8JcQ==; 5:CnrqY/lLq2fwxOUQMndkI2lQ9E1mitZS6y7r2gLMxb+kPHsOL8DJzb/qqvrrCSkJ1PA2LA1BM0/zPH/Plst1ZdQlO8BU7th4uwvgSgPErmVMyEdmVa4dKrPAUHmSEi7vmFk3C7iVXKaO3PabZpYx09uZUc8N+Wf5UotKtaZTNbviOqFOdBsyA8faUOjCMcSTwrEhu/W3ZqpLkFzyPlH40g==; 7:lJRuNsB4ooGG9RvZUyh8g4WKIqMD3MKe7+rEKx8uJ1VupH9mFU73rP/eKrDIZv8qqNEZQkDGcsm40q+RYPC5FubVUH04Z1oos60xixLNGbs/1RAUTSaplGGHyvw6D4B53QZ98NeJe0gZgxjt9zWDbQ== X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-OriginalArrivalTime: 31 Jan 2019 09:40:58.3822 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 7752df5c-eb63-431a-8f60-08d687603461 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: AM5P18901MB0097 Archived-At: Subject: Re: [Ace] Shepard review for draft-ietf-ace-oauth-authz 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, 31 Jan 2019 09:41:05 -0000 Hello, we have an unresolved review comment by Steffi that got lost in the holiday season: https://mailarchive.ietf.org/arch/msg/ace/CBTkVUBzYrfC55zH3_UJDngiy9U https://mailarchive.ietf.org/arch/msg/ace/NrQWetugoy0TWp9eg3lwtSictc8 The issue is the following (my words): The AS provides the client with key material used by the RS. This can either be a common symmetric pop-key, or an asymmetric key used by the RS to authenticate towards the client. Since there is (currently) no metadata associated to those keys, the client has no way of knowing if these keys are still valid. This may lead to situations where the client sends requests containing sensitive information to the RS using a key that is expired and possibly in the hands of an attacker, or accepts responses from the RS that are no properly protected and could possibly have been forged by an attacker. The options to resolve this that I currently see are this: 1. If the client has no additional data it MUST assume that the key is valid as long as the access token together with which it received that key. Since the access token is opaque to the client, the client MUST now determine how long the token is valid: Option 1.1 The client is provisioned in advance with a default validity time for tokens issued by the AS. This could be done when the client is registered at the AS. Option 1.2 The AS informs the client using the "expires_in" parameter in the Access Information. This means that we need to implement a check whether the client knows a default validity, and if that is not the case reject an access token that does not come together with an "expires_in" parameter. 2. We can define a new parameter that informs the client specifically about the validity of the keys the RS uses, if that differs from the validity of the token. Note that this is a realistic use case, since the RS might use an asymmetric key for authentication that is valid for a significantly longer period than some access token. I would need some feed-back from the group to proceed here. /Ludwig -- Ludwig Seitz, PhD Security Lab, RISE Phone +46(0)70-349 92 51 From nobody Thu Jan 31 04:45:56 2019 Return-Path: X-Original-To: ace@ietf.org Delivered-To: ace@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E82A7130EDE; Thu, 31 Jan 2019 04:45:54 -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.90.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ace@ietf.org Message-ID: <154893875491.10188.17706086301457019037@ietfa.amsl.com> Date: Thu, 31 Jan 2019 04:45:54 -0800 Archived-At: Subject: [Ace] I-D Action: draft-ietf-ace-oauth-authz-19.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, 31 Jan 2019 12:45:55 -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 : Authentication and Authorization for Constrained Environments (ACE) using the OAuth 2.0 Framework (ACE-OAuth) Authors : Ludwig Seitz Goeran Selander Erik Wahlstroem Samuel Erdtman Hannes Tschofenig Filename : draft-ietf-ace-oauth-authz-19.txt Pages : 77 Date : 2019-01-31 Abstract: This specification defines a framework for authentication and authorization in Internet of Things (IoT) environments called ACE- OAuth. The framework is based on a set of building blocks including OAuth 2.0 and CoAP, thus making a well-known and widely used authorization solution suitable for IoT devices. Existing specifications are used where possible, but where the constraints of IoT devices require it, extensions are added and profiles are defined. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ace-oauth-authz/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-19 https://datatracker.ietf.org/doc/html/draft-ietf-ace-oauth-authz-19 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-oauth-authz-19 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 Jan 31 04:48:42 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23C84130EE4 for ; Thu, 31 Jan 2019 04:48:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.043 X-Spam-Level: X-Spam-Status: No, score=-2.043 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, 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 rWcWb3NDxsgA for ; Thu, 31 Jan 2019 04:48:37 -0800 (PST) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-eopbgr140078.outbound.protection.outlook.com [40.107.14.78]) (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 439E3130EDA for ; Thu, 31 Jan 2019 04:48:37 -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=L0+ua34F5eEv4a/epdCvO5u18+OYk30r+fMHhwsXO5M=; b=P+tar3Dumxj5qaVj7lFm3gm9rIX1lt1GA/n93Ko2qlXsYXCtO5+5Dy5calFAyRsBVRTO8u3rwGQ8lcrSWHHkPn2fdVxCp8di5jFdP9GjVcBiDxuRqECfwNKiBAiKyBGbCFmjpL+3upQePHvODv71eYTG7vDf9rj0Z1MbD97yn9Q= Received: from HE1P189CA0001.EURP189.PROD.OUTLOOK.COM (2603:10a6:7:53::14) by VI1P189MB0334.EURP189.PROD.OUTLOOK.COM (2603:10a6:802:35::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1558.21; Thu, 31 Jan 2019 12:48:34 +0000 Received: from HE1EUR02FT035.eop-EUR02.prod.protection.outlook.com (2a01:111:f400:7e05::202) by HE1P189CA0001.outlook.office365.com (2603:10a6:7:53::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1580.16 via Frontend Transport; Thu, 31 Jan 2019 12:48:34 +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 HE1EUR02FT035.mail.protection.outlook.com (10.152.10.127) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.20.1580.10 via Frontend Transport; Thu, 31 Jan 2019 12:48:34 +0000 Received: from [10.112.134.122] (10.100.0.158) by sp-mail-2.sp.se (10.100.0.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1531.3; Thu, 31 Jan 2019 13:48:34 +0100 References: <154893875514.10188.1248010651225954494.idtracker@ietfa.amsl.com> To: "ace@ietf.org" From: Ludwig Seitz X-Forwarded-Message-Id: <154893875514.10188.1248010651225954494.idtracker@ietfa.amsl.com> Message-ID: Date: Thu, 31 Jan 2019 13:48:33 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <154893875514.10188.1248010651225954494.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.100.0.158] X-ClientProxiedBy: sp-mail-3.sp.se (10.100.0.163) To sp-mail-2.sp.se (10.100.0.162) X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:194.218.146.197; IPV:NLI; CTRY:SE; EFV:NLI; SFV:NSPM; SFS:(10009020)(39860400002)(376002)(136003)(346002)(396003)(2980300002)(199004)(189003)(54534003)(2486003)(2351001)(23676004)(26005)(77096007)(106466001)(2616005)(15650500001)(446003)(11346002)(6916009)(86362001)(14444005)(44832011)(50466002)(69596002)(74482002)(67846002)(47776003)(126002)(478600001)(486006)(2906002)(65956001)(104016004)(65826007)(65806001)(476003)(31696002)(22756006)(229853002)(40036005)(53936002)(16526019)(68736007)(186003)(76176011)(386003)(36756003)(5640700003)(33896004)(7736002)(6306002)(58126008)(336012)(2473003)(356004)(22746008)(97736004)(6116002)(16576012)(316002)(2501003)(8936002)(64126003)(966005)(66574012)(106002)(31686004)(8676002)(305945005)(3846002)(230700001)(81166006)(1730700003)(81156014); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1P189MB0334; H:mail.ri.se; FPR:; SPF:Pass; LANG:en; PTR:InfoDomainNonexistent; A:1; MX:1; X-Microsoft-Exchange-Diagnostics: 1; HE1EUR02FT035; 1:Ridji6A6ZcwOxnP6tI1DeBSyYGwOYkoeIeg9A2I9SsYAUFo1jNunEhWMcla8zsAo0deOSYm1QKqd6chP3w1GnIdcibYTid8NVtZAjspPIbW7+SXJAUzx0jAsF2KbMpaRV1hGivSy58DzFhoKnqHJoM8785+MIzn2bj0JvtfXnpY= X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 525c361c-8c33-45cc-c358-08d6877a6988 X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605077)(4608076)(4709027)(2017052603328)(7153060)(7193020); SRVR:VI1P189MB0334; X-Microsoft-Exchange-Diagnostics: 1; VI1P189MB0334; 3://gPWpAJytEwYJX1SyZyWY56JBXr1mSEJ5ivrDK/p3hIzFQ+qsB9asKq2giJZD9LK1OikrE8KKncqSt9eqoYmuLQ3dORDhIRuhazSVELaAtYmYQ7adbXeZ5CuRiFGSIBRsRMn2zSAltgT7I3XbKCQaUZ26hvC3su+OASDOeUdwqIvWFzK1vxBp7HuXaP6Y63zsYdzZAR4QGQ7YYUj/rPVq3mn0ZFHkwW8P26CzPWHk1y1aSI6We5eFBLDt3ZJxCCZCvLuT912D2bqUaGQGUNzPXP9R+3Vij96ifyFv4mluZzVKv7EhEAvyeH10G6pRt90/V0fxdwnN7bYu+uGbQ035bgxxIFsDAtqq9wTc65ZZemM30VMg+/uMKNEDUJ5lbL; 25:poSnYacWwGVQnH1bOjB4PRAvqmso8caT+rHmQKXXwd/twEkzWC8M10xZNfiCOv2lRWRnoCs1qa3q9OlvF6p/bbEelZQyDUocGjUFx7RxrYo6NKe5WkXimsgDdpn6vaqLYGzqpQH74fUYs+JxEEQWOUGFX2fCfT3M/7riKXWZ7Sps1yPK4Ye2SjnYmL1nRVZ4lvsQm/2x55C02v2yNyLFss1SH0lW8pF6xODlKrNfY6Tcv94JFopJg6xa/lijF4Nuk4qBsTYlLXotoCNMn7b/Wj0oMgP+cPg0Th+l71k65MQQVBf2WEQ5BwXkJ13mcFjNHOooa6ncnalVO+49DOsAlw== X-MS-TrafficTypeDiagnostic: VI1P189MB0334: X-Microsoft-Exchange-Diagnostics: 1; VI1P189MB0334; 31:Qvn+303JPeUvIMDq5PkPi5FGVOUpyUjpy587b1aeeduJftxq9KWqxorMKQ6mVV67Upe3XJ1D622Txp3VM7U/yeBFizMsyrkGrmk+SW13UsDM5KA8OWXiTweUg6heILcZhkx8d2KEOh60ppup1XCsjsh55HS+dYb5vusRr0LiI/ATDjGIAyex+aq6gYQ/YYeBJVN/eCnSedyg/fxF1FimkeAN458J0xH1NObzud0OZ98=; 20:7ZZts0sufg2DTPitlSw24c56qXzG3jmXGWRltM1adUP93kHc4ADkMW/K2xh3pKuVdTxCwS0vvYzYpeGpl2nZ2w1y/7aB625JI1XqMaI4Hl7fU4oo6J930WkxWaQBIiBx2uPOfXfG+mswY/lWEB6ZpDj6hQbkoAeU0eq+GMWogHnFsrDfdt8SlesSaoKAHSN0XX5C3Rm7YH7EQxRZM0eqMYyWuG6IBMpA6UVYO5vv9mL6375teYJbo/eiX4ASssF+; 4:ZeFPjbUT1Jl6Jg/Hj4HZASyhJNUF/lHwMUF4bTkXq63VHUGGrCFawwsu4TNQtem0hmwirlM8KHJuNGBN1HCzAQ5CZRU/sKCu51ifHZVFeIJwBwnfcqbICrpdkt6iWIZoE4rW5KFI7NLoNE1/u38ksyw9LzS1uGpZsh5FU/bFmj7OLmhyjeeDp1tu9msZoI5jIsZ0zpcZtiOvbWJgzftwyoRnWERxOijfj3igdJ1WuOiIL/cPWYe/icWIpICvT7SIr5BCzGExrtbyIVC29eTBVLPHpw0CODF72jebaZIBhe8= X-Microsoft-Antispam-PRVS: X-Forefront-PRVS: 09347618C4 X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtWSTFQMTg5TUIwMzM0OzIzOk1ld3JiY0tyaUFCT0lOcng2S3F3c0RZTXpR?= =?utf-8?B?NWlEdmVibU1VbnpFZ3YrQzg5aStHS0J0QWpscEpVUFkybXBsOW00Q2dyNTlR?= =?utf-8?B?Sk5YMFp0UE9zWmlzVWxZbGRZQ1BZUzlPTjJNT2c2cE9iemo1RmtxUEc0eExJ?= =?utf-8?B?cXZsUERjd3dwN0ZLYWdrNkwvUFB3RkhKYmc1dDZYZVY0TEhhNlg2emVPUXJz?= =?utf-8?B?VmRWWUp0RmVOVloyUWRoR3NmazQrQVRxWmhrallHQmxLdVo3R0FqdTBZaEIr?= =?utf-8?B?djBubWptbW82dnFkcGdrOU85NUFMQnNKSGJMZUl6VXBmTUxYdE5rUlU1UzYz?= =?utf-8?B?Z1YxQ2ErWk1UNkoyWXZpK2FkVWlsL3ZVVVRDZE9XaW5ocFRCVWJsQ2YyaVhN?= =?utf-8?B?blc0TVFpdStmb2xDRStjeFZRakhQRWc3TS9BRzRWKy81ZTBQbHBhamFSekZO?= =?utf-8?B?SmtHYU82blhSZlR4QjZheTJJV1VOcXF1QUpScUpVdDlRVzdoRVFPUDNZck1o?= =?utf-8?B?anhQSW9MeEgrVk1ldk5uYXVmeUprTkpuUHdWKzdPYWlvQVRmSGhmRForWDho?= =?utf-8?B?Rkxjd05rVjFQWmk3S2ZoVlNNalNLRVdRUWJ2N1ByNzNPTnBIZk9ESEJ5WG91?= =?utf-8?B?SmhaUDdtWE5oRmEyK3lYNHo2dmFPT3Z6NmNtbE1KUmRETFJRSjNOd2FXTWda?= =?utf-8?B?MXZnRE5saXNpNWdxTGtXeDVma2VHblZQRFF3WW5YdGlveGNudll2dlRjNGtU?= =?utf-8?B?ZjZpc3dXcFVmWXR2TDcrK2Y1NnVnLy9IdlBRUmprdHRKSGU0cERjU01mTVhu?= =?utf-8?B?OXZjTXYweHpvLzBtZ0tuQjRMRTVsSWFnVnRmM0Q4WUxFdG9jOEVCa3M5cHpO?= =?utf-8?B?L3JqT2JiNWsvZFNoQkNoL2xWQnMyV254WnNsN0xYM01rbWxva3EvSnZhNWlr?= =?utf-8?B?SmtuSVpzRHpFZDh3bm85WS9CbElWdkliZDl4QjNoRFBmZ2xPWFMxREJSeXFj?= =?utf-8?B?NDFnZ05odTc0SkJEQWhaMDN1UDZZeGVrLzVDRFhEYkZIZ2hIVDRHZS8yZm1N?= =?utf-8?B?T2RoREhTSmtrbDBucFlFUjhrZ2NhUXNyQTNFSW5UV2dGS1dWWGZHeGtqVkhY?= =?utf-8?B?UUxaQ2g4ZmhoN0x3QUowOVgwS2NXNzJJUzhxK3ZBVGlpZXc5WmRlQXR6WUJJ?= =?utf-8?B?dGsySThBK3JXYnE4aG1NM2xpdUZyYTdmZ3c2ZUFoQUJLa2tZS2tEZDZUL1BB?= =?utf-8?B?eWdtU2tnVVJVRElJUDRaTUZxbVVKbW1IRUJzMXNYUlMrTWVMOE5YRGcvVnZL?= =?utf-8?B?MTNFTHZXTGJ4VEcrdzY3RWZzenh0Qnp3dDZTc3M5TzBpOHpxTWhKUHIrSHVQ?= =?utf-8?B?L0Q5TFl0bFhUY3ROdEh3QkpUM0p3TU5JRGQ1TjVMeG9YWVZYYkp6eEVreVhu?= =?utf-8?B?SnN1ZTFEYWF2MzRoNHR5enFVYnRyWEl3TldrbDZheW04OWprVEQyR0tMS1gr?= =?utf-8?B?RUlPRUd4bXE5OVBJZ3BWTFh4TU0ycU84VFpmNkxFcUxiMGJqbWViZ3VkYUZi?= =?utf-8?B?ZExCM2ZVOUVqWXMxQjRKRzVIZVlob0tmTkMxTllaUnJaMU5MUjlyTXc1Qm81?= =?utf-8?B?aVQxeTdPUnVKVk4vdFEwUWpzVVMyeXIybDdrcGZRZExIcThzcTZVWGUvUjRa?= =?utf-8?B?bWpJaCtEdGNyNlFGOU4ycko5aitjWWNEd1Z6NWl5bWh0bFJxdDJCUWZmSGpp?= =?utf-8?B?NHNDa2F3OXJlUWN5dkc5OTgzaGFkbGcwRjNEelRyMnlQYUowN2tBdWZDNm40?= =?utf-8?B?ZmJQM3VOek52Nitza3BoTXRXQUNvbXJnVzVPNXJ3QXlFZ1BYSU9yNDUxSngx?= =?utf-8?B?eE0xcXpjSEUrdWpyTjhFYjFpUmsvaTNZb3QvZlBuMWJrdmk3ZjlvMjZKWlBv?= =?utf-8?B?MWE3MHlwQ3Q3cDlXRG5LenY2WEI2NDlYWWZhMlIzVkx3eXVsbDhpdWxzVUhN?= =?utf-8?B?bmtTV005NFhBMFVoNTNXdFEya2JsSUhSRGtvb1hpeFVCNTlOSTJmaEtabW0r?= =?utf-8?B?UTFmTDA0YlQvczVVdWt6TXhCYkpTOWkwZGZyOGJxZEdra0FvbDdqamUrUnla?= =?utf-8?B?dnVlY1RERDdlOE5vd21xcHVMSUdoclA1SkVtYlEyRUFIWmNVckJnRmUxN1Ny?= =?utf-8?Q?OHIOl6Y6+4WZKM+YE21WIAQqkaLjeOhBDl3fne5U/A=3D?= X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Message-Info: Pxa3QwIULO6GSi+UNMjMTr1o8BfLF7blumPTnrDIpYyZoT7Tb82j+97Ykn09llTDNTHusym+XydCgvqzR0jFCsAbBTtqi2Loz3YtWf8ZgHfZxemtRLjhf7pHngMhCZS2eTMj1Fpc4MM8/elmcbRxib33bhHbcq/qbb8BaoqerEujuHG+GVrabc9Med6FnNYSusYyokqMFkRmxCzyivaR8qFRyy9bORIK7WKBHnBUh+LihwhKmn/4H1EypvuzKSWGTYvMJB9LPSV97VtcQjQGn8uI+VjwOUwCwhxSNhzhaMVZxsXPmKzZFFwMQ5nwk9QZXIyO2jH+QT4J0Ykqx64MuWjIBgNyTORouSCJbjKA/jc+RteOm7BEudpSBRpAcl7qtuv3bYDE0wsVk9X+yGUFtR0nrUMYcLJga5ZIPpXQ+Do= X-Microsoft-Exchange-Diagnostics: 1; VI1P189MB0334; 6:X5xMK6fQDD0mJKBwQ+hQW8a4EhLOF/qPKeX/Fkw7zZs5jg+iLsBHzLt5gfeB+OwavIewhQubiWf15/iPgmi+0SOc5eaGR4ZdXIl5pml6rjmXqW2iqx8dtmSYtdOwmYib3QPUCeOwxIUIDAJ6h/eJ7L0kvBxKKh1v5Wrd2mqDKY/pEJsaBt9zpOkotozfJa2RuJS7wRCOCp8OOJFIn90HMt+WiX4qROAp4ez5LCSHJZClWpc6sherXIvyzolNKx/8cLHpW5KiAUe0nVpbWpHaj3zga1h1CiZ7Y5SvgA5Rtd+G+fY+fzqXMBoDntNB560Jlz/iWdobYgXTWrIlNeGUYkQsk/DQ6K7n+6UHJDdSoWFpA5kYyttHoMg1J7eBpQ72kMWiRybJpRkb6xrXzvrgPbdlMsKHJ7S7b2vAG9rOxxDlZ4g1ckMiY2h0uQYFtijOPOlDYfICt2k9oOmFg5aLww==; 5:lJEpzH7q8P3Geo0Z0qZqs0dHhTPLLllmXVRJ+JSLyzNws1E9GSSVQWZJhBem6n1zQAwsUMPqSJNfs98NoyLCYfsp6Zi4fEgJWbzwd9EFrcdHy1ZP+QbVo+DCxOPYLflvs+ry2n6Q8koUEjIHdO9M0DGTA7t+B5W4A/EvnU8Neyuel96uFdouCWJ7rpKsegFPfwG82m8lQ7uf4etVcqbR6Q==; 7:fRYc2VkM077+mN/8E/TrIHXOy4Cl5ObLcmKpsvW9UwWB7tUpfSrbPAVw1LXLCmArp3SLBh4MzXYCFG/JLblb4fgcPZ/Zlke5m+K4bnsP9I83kgouxqQ1otk/zo64GfsXWFtOMOwqCunvwN4tU5Nvdw== X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-OriginalArrivalTime: 31 Jan 2019 12:48:34.5093 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 525c361c-8c33-45cc-c358-08d6877a6988 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: VI1P189MB0334 Archived-At: Subject: [Ace] Fwd: New Version Notification for draft-ietf-ace-oauth-authz-19.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, 31 Jan 2019 12:48:41 -0000 Hello ACE, this update takes care of the comments from the shepherd review (thanks Jim) and some further issues. See the changelog for details. The only remaining issue is the one from here: https://mailarchive.ietf.org/arch/msg/ace/GeB6NQbiJpscitlImg_UcJ7Vxj8 /Ludwig -------- Forwarded Message -------- Subject: New Version Notification for draft-ietf-ace-oauth-authz-19.txt Date: Thu, 31 Jan 2019 04:45:55 -0800 From: internet-drafts@ietf.org To: Ludwig Seitz , Hannes Tschofenig , Goeran Selander , Samuel Erdtman , Erik Wahlstroem A new version of I-D, draft-ietf-ace-oauth-authz-19.txt has been successfully submitted by Ludwig Seitz and posted to the IETF repository. Name: draft-ietf-ace-oauth-authz Revision: 19 Title: Authentication and Authorization for Constrained Environments (ACE) using the OAuth 2.0 Framework (ACE-OAuth) Document date: 2019-01-31 Group: ace Pages: 77 URL: https://www.ietf.org/internet-drafts/draft-ietf-ace-oauth-authz-19.txt Status: https://datatracker.ietf.org/doc/draft-ietf-ace-oauth-authz/ Htmlized: https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-19 Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-ace-oauth-authz Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-oauth-authz-19 Abstract: This specification defines a framework for authentication and authorization in Internet of Things (IoT) environments called ACE- OAuth. The framework is based on a set of building blocks including OAuth 2.0 and CoAP, thus making a well-known and widely used authorization solution suitable for IoT devices. Existing specifications are used where possible, but where the constraints of IoT devices require it, extensions are added and profiles are defined. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Thu Jan 31 06:26:14 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB2B4128CB7 for ; Thu, 31 Jan 2019 06:26:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.854 X-Spam-Level: X-Spam-Status: No, score=-8.854 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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=Ob9zOdlD; dkim=pass (1024-bit key) header.d=ericsson.com header.b=I+bXaeLf 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 VTwEx5PfA9RS for ; Thu, 31 Jan 2019 06:26:11 -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 3FAA01286D9 for ; Thu, 31 Jan 2019 06:26:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/relaxed; q=dns/txt; i=@ericsson.com; t=1548944769; x=1551536769; 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=pLWuYBvzCdkZ6+5Yk7fdaOdy7psgFRIlo4WD5g2WpLg=; b=Ob9zOdlDDvFI8dMbq7w8MYbe6axpLVmsrC7qbrpmNR4VSKyszjRpU7nmHtcynMe3 GXJw9sMjwo/4qKfHMC4GTBGVYt4ZnrBcPYyS4UdMV9tRv8/iQOZFzxHDlv5zlcLG z8O+NI6uzKZ7HkuEVMjR+UtJAOGPPWxgJCWTqT73pQM=; X-AuditID: c1b4fb2d-db5ff7000000062f-5d-5c53058180a1 Received: from ESESSMB503.ericsson.se (Unknown_Domain [153.88.183.121]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 31.02.01583.185035C5; Thu, 31 Jan 2019 15:26:09 +0100 (CET) Received: from ESESSMR503.ericsson.se (153.88.183.112) by ESESSMB503.ericsson.se (153.88.183.121) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Thu, 31 Jan 2019 15:26:08 +0100 Received: from ESESSMB502.ericsson.se (153.88.183.163) by ESESSMR503.ericsson.se (153.88.183.112) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Thu, 31 Jan 2019 15:26:09 +0100 Received: from EUR01-DB5-obe.outbound.protection.outlook.com (153.88.183.157) 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 via Frontend Transport; Thu, 31 Jan 2019 15:26:08 +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=pLWuYBvzCdkZ6+5Yk7fdaOdy7psgFRIlo4WD5g2WpLg=; b=I+bXaeLfPHTOFn7gMs1G2VoOY8yqTEg7p8831elpipue8CuzFkvs5abmX7FNSNq18SZ2dw3iYavIe35y6V+FUxfqIx3F1nfLIr34WEKw7O6EB6deQ1Cp0xjPciuacD1Fqt665iWPmKnGb8sHrkLmnsvwq5q5S7p5vTt+dlcjv3g= Received: from HE1PR0701MB2746.eurprd07.prod.outlook.com (10.168.188.140) by HE1PR0701MB2395.eurprd07.prod.outlook.com (10.168.128.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1558.16; Thu, 31 Jan 2019 14:26:07 +0000 Received: from HE1PR0701MB2746.eurprd07.prod.outlook.com ([fe80::1f9:b4c9:ef3d:32c9]) by HE1PR0701MB2746.eurprd07.prod.outlook.com ([fe80::1f9:b4c9:ef3d:32c9%4]) with mapi id 15.20.1580.014; Thu, 31 Jan 2019 14:26:07 +0000 From: Francesca Palombini To: Jim Schaad , "draft-ietf-ace-oscore-profile@ietf.org" CC: "ace@ietf.org" Thread-Topic: Shepard comments on draft-ietf-ace-oscore-profile Thread-Index: AdS4+whFigFTKC1DQi2kqlxsKsGuhgAfkBIA Date: Thu, 31 Jan 2019 14:26:07 +0000 Message-ID: References: <023901d4b8fc$b72658c0$25730a40$@augustcellars.com> In-Reply-To: <023901d4b8fc$b72658c0$25730a40$@augustcellars.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=francesca.palombini@ericsson.com; x-originating-ip: [192.176.1.88] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HE1PR0701MB2395; 6:K4xoehAuugTBLL2tdZLy8WJYCXwncYg9/GwucI5z9hVx6RDyYXjf5euSusdPiE3X0hiSHCLdu4/mOZcmU12vEEr0i+dFzMSjLaF/CeL/n9GD4VqhpEyPDQ24J0KNfzpgLEexu5dU2pllKz7W+jJqf+UI/9b5TUnCOofafO5GS5NCyoqw2EKMeH0uNJHdrfXb+6BzGbPmBUaBFMaIu0YpzU4u7kISE9mDae20qzVcs6AN3T3OordS3Yuyu8FRt9V61pKwUoMXIS2Qxj+TYi0dwumf09wMzrcam7/k9ABzh6Knv6IBD99O7sc/bZH3q0ErXWLMr3f1bpFebCxiRPPG/xWO5RBx4BndkpDmOwy1S5LOouCjmX+O6pabmck0ybPYCP2iQn9oK8qtbbr6/myDYMlhUC3Rdz0lC67cqljP72R6qP3R+IvX+3dtZF6fd00MkSPBqzcrx0exIozZdMKmHA==; 5:4x+v5RIeNwK9J75E+Iw6/tLYjmUgY0X9x58rDB4Z5HDq4zw9EQaHrK4EVfVaDEzwdy0Y1Etx8e9nDW3ttWB7Ka/MybNapFGDtPhcfwYCHNSEabekURcoAaBb7GZ8b4mThsv/RIMLVEUbt/fq9evYXCe7hoA/a4NiI8eoq/v+fyMJj+eRl5uOrO9meOL2yY3nB2qIqwtq7gKNvG9cd9+h9g==; 7:ZXazMdyy0IlmIPuLqS4fWFzcptPs2bFtzy5pEy9h3ecOAy9UbEdx8WJJExqwTQk9Mhq2ijrPPm3OkqtalKUz0/XRJEe6hZyj19RXNWLShk4ZObd5xDh4Ai6RwRiWMDzK4WsVxAMJIF3rVt8yx3+aNw== x-ms-office365-filtering-correlation-id: ff25f58e-2c74-40ca-d960-08d687880a62 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605077)(2017052603328)(7153060)(7193020); SRVR:HE1PR0701MB2395; x-ms-traffictypediagnostic: HE1PR0701MB2395: x-microsoft-antispam-prvs: x-forefront-prvs: 09347618C4 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(39860400002)(136003)(376002)(366004)(396003)(189003)(199004)(7736002)(86362001)(97736004)(76176011)(81166006)(110136005)(99286004)(8676002)(102836004)(81156014)(4743002)(486006)(25786009)(4326008)(66066001)(6436002)(44832011)(6116002)(316002)(106356001)(6486002)(6512007)(3846002)(105586002)(8936002)(14444005)(68736007)(256004)(53936002)(71200400001)(11346002)(6246003)(305945005)(229853002)(36756003)(71190400001)(2501003)(82746002)(446003)(2906002)(83716004)(186003)(2616005)(14454004)(26005)(478600001)(476003)(6506007)(33656002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2395; H:HE1PR0701MB2746.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 1l7RrQtWN22xRDbi2V0f5u3NyDdwL47sCRzaduV0UxeSHEzKZ7T3jS6sV4Y3qkVkBOHNZbKMmmuGyVyNXKmWjeVkYOc6toVI3m9ux1Qn2G8qSpBGQC8W09qQUVYiL/t2lFCMlZ5xS1m2crUHErN5OHrifstuny9JSvuBscd4yE1oyLkhiASZjxjN5N3vV+k0H2zTnPCA9mTr/U8OCEe6NEuypwwoHVp87NyPs00GssN8qeItwS3SeuMT5mOhiKKv6iinQw/1CEuMMpRVRECRMTMjU653CLQy6nuJC8b6mt8o7398SlbRTuuc9nBlo7dZjdimHdwFsYMkNXC1kfLLVeidD1KBCa86PFzQoxPVk2+YYFMw0U2zilMb36jk7CW/8xXyehBHB9CheiDFsNrgtU/HihmuwQNe/VXY1cAhxcA= Content-Type: text/plain; charset="utf-8" Content-ID: <6BA5F6949459A64B9FEAE165840CC3C6@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: ff25f58e-2c74-40ca-d960-08d687880a62 X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Jan 2019 14:26:07.7024 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2395 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprOKsWRmVeSWpSXmKPExsUyM2J7pW4ja3CMwb1eZYvv33qYLZ5u62C2 WD39O5sDs8fGOdPZPJYs+ckUwBTFZZOSmpNZllqkb5fAldF8YQp7wRX+ig2XLrI3MC7g72Lk 5JAQMJFYcWwDYxcjF4eQwBFGiQvPGlghnG+MEsuOz0Jw/u3cwwzSIiSwhEni51E1kASLwARm iWetn6H6ZzBJvOy+xQThPGGU6N16BKyFTcBG4sLD96wgtohAncT995tZQGxmAUWJdXP6mEBs YQF7ideH7rN3MXIA1ThI/NwRB1FuJHHicCcbiM0ioCrx4tgssJG8QOX/b75lhbjIXuLUnU6w kZxArff/NYONZBSQlfjSuJoZYpW4xK0n85kgnhaQWLLnPDOELSrx8vE/Voj6ZIkrt/vYIeIK Eu/mnmaDsGUlLs3vBntSQqCFXeLf4xNQzb4Sn46cZYFI3GaUuP16OtQGHYn5b15BTcqXeHR4 JguELSPR9/Yz1KQ7rBKnv25kmsCoNwvJhbOAAcAsoCmxfpc+RNhD4tPKv0yzoOE1pfsh+yxw AAhKnJz5hGUBI+sqRtHi1OLi3HQjY73Uoszk4uL8PL281JJNjMDkcnDLb90djKtfOx5iFOBg VOLhncIUHCPEmlhWXJl7iFGCg1lJhFfqQVCMEG9KYmVValF+fFFpTmrxIUZpDhYlcd4/QoIx QgLpiSWp2ampBalFMFkmDk6pBkaZnEOyC/Nn1t/dYD7Rpj+C521OReIMDx2TcmXpxb8/BWc/ 536v2eIVvWaSQmDw//svH4leertvXd3/bXejJzo9DAt7qWIYft+RSydifTGn85Ef//ZPufdM 58nRc58dpQr+dmp2qM8J9Oe4fy7w66KqC1J3Ztdd97AKCWXM6znB6Hpv7lZxI1klluKMREMt 5qLiRAAylry7KgMAAA== Archived-At: Subject: Re: [Ace] Shepard comments on draft-ietf-ace-oscore-profile X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2019 14:26:13 -0000 SGkgSmltLA0KDQpJbmxpbmUuDQoNClRoYW5rcywNCkZyYW5jZXNjYQ0KDQrvu79PbiAzMS8wMS8y MDE5LCAwMTozNCwgIkppbSBTY2hhYWQiIDxpZXRmQGF1Z3VzdGNlbGxhcnMuY29tPiB3cm90ZToN Cg0KICAgIA0KICAgIDEuICBQbGVhc2UgdXBkYXRlIHRoZSB0ZXh0IGZvciBNVVNUL1NIT1VMRC9N QVkgdG8gaW5jbHVkZSB0aGUgbGFuZ3VhZ2UgZnJvbQ0KICAgIFJGQyA4MTc0Lg0KDQpGUDogUmln aHQsIHRoYW5rcy4gVXBkYXRlZCBub3cgaW4gdGhlIGdpdGh1Yi4NCiAgICANCiAgICAyLiAgU2Vj dGlvbiAzLjIuMSAtIFdoYXQgdG8gZG8gaXMgY2xlYXIgaWYgYSBmaWVsZCBpcyBub3QgbWlzc2lu Zy4gIFdoYXQgaXMNCiAgICB0aGUgY29ycmVjdCBiZWhhdmlvciBpZiBhIGZpZWxkIGlzIHByZXNl bnQgdGhhdCB0aGUgY2xpZW50IGFuZC9vciByZXNvdXJjZQ0KICAgIHNlcnZlciBkb2VzIG5vdCBy ZWNvZ25pemUuICBJcyB0aGlzIGEgZmF0YWwgZXJyb3Igb3IgaXMgaXQgc3VmZmljaWVudCB0aGF0 DQogICAgdGhleSBtYXkgbm90IGJlaGF2ZSB0aGUgc2FtZT8NCg0KRlA6IEFzc3VtaW5nIHlvdSBh cmUgcmVmZXJyaW5nIHRvIGZpZWxkcyBtaXNzaW5nIGluIHRoZSBPU0NPUkVfU2VjdXJpdHlfQ29u dGV4dCwgKHBsZWFzZSBjb3JyZWN0IG1lIG90aGVyd2lzZSkgdGhpcyBpcyBhIGdvb2QgcG9pbnQu IFdlIGN1cnJlbnRseSBkbyBub3QgZGVmaW5lIHdoYXQgaGFwcGVucyBpZiB0aGUgc2VjdXJpdHkg Y29udGV4dCBoYXMgdW5yZWNvZ25pemVkIHBhcmFtZXRlcnMuIFdlIGRvbid0IGZvcmVzZWUgdGhp cyBoYXBwZW5pbmcsIGFzIHRoZSBBUyBzaG91bGQga25vdyB3aGF0IHRoZSBjbGllbnQgYW5kIFJT IGltcGxlbWVudC4gSG93ZXZlciwgdG8gY292ZXIgdGhpcyBjYXNlIChiYWQgaW1wbGVtZW50YXRp b24gb3Igc29tZXRoaW5nIHdlbnQgd3JvbmcpLCB0byBiZSBvbiB0aGUgc2FmZSBzaWRlLCB3ZSBw cm9wb3NlIHRoYXQgdGhlcmUgaXMgYSBmYXRhbCBlcnJvciBpbiB0aGF0IGNhc2UuIEluIGZhY3Qs IHdlIGRvbid0IGtub3cgd2hhdCBhZGRpdGlvbmFsIHBhcmFtZXRlcnMgbWlnaHQgYmUgcmVnaXN0 ZXJlZCBpbiB0aGUgT1NDT1JFX1NlY3VyaXR5X0NvbnRleHQsIGFuZCBhbHRob3VnaCB0aGV5IGNv dWxkIGJlICJyaXNrLWZyZWUiIChhcyBpbiBvcHRpb25hbCBhZGRpdGlvbmFsIGluZm9ybWF0aW9u IG5vbi1uZWNlc3NhcnkgZm9yIHRoZSBzZWN1cml0eSBjb250ZXh0IGRlcml2YXRpb24pLCB0aGV5 IGNvdWxkIGFsc28gYmUgaW5wdXQgdG8gdGhlIGtleSBkZXJpdmF0aW9uIGZvciBleGFtcGxlLCBp biB3aGljaCBjYXNlIHRoZSBlbmRwb2ludCBub24tcmVjb2duaXppbmcgdGhlbSB3b3VsZCBlbmQg dXAgc3RvcmluZyBhICJ3cm9uZyIgc2VjdXJpdHkgY29udGV4dC4gV2hhdCBkbyB5b3UgdGhpbms/ DQogICAgDQogICAgSmltDQogICAgDQogICAgDQogICAgDQoNCg== From nobody Thu Jan 31 08:44:49 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B35612426E; Thu, 31 Jan 2019 08:44:48 -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 TBjzs8cqguQx; Thu, 31 Jan 2019 08:44: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 2FC4112426A; Thu, 31 Jan 2019 08:44:45 -0800 (PST) Received: from Jude (67.208.104.26) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 31 Jan 2019 08:44:19 -0800 From: Jim Schaad To: 'Ludwig Seitz' , CC: References: <01e801d4b861$4d7d41e0$e877c5a0$@augustcellars.com> <76f048fa-fa03-4e5b-0b60-c5674a2ddad3@ri.se> <021c01d4b8c8$e5ee0ba0$b1ca22e0$@augustcellars.com> In-Reply-To: Date: Thu, 31 Jan 2019 08:44:16 -0800 Message-ID: <026b01d4b984$35f0c460$a1d24d20$@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: AQMO0G41vSMoQObT7FZTfu2Mz+Bo2AG5F3ZkAWTDHEsColIqPaMnZcbA Content-Language: en-us X-Originating-IP: [67.208.104.26] Archived-At: Subject: Re: [Ace] Shepard review for draft-ietf-ace-oauth-authz 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, 31 Jan 2019 16:44:48 -0000 > -----Original Message----- > From: Ludwig Seitz > Sent: Thursday, January 31, 2019 1:20 AM > To: Jim Schaad ; draft-ietf-ace-oauth- > authz@ietf.org > Cc: ace@ietf.org > Subject: Re: Shepard review for draft-ietf-ace-oauth-authz >=20 > On 30/01/2019 19:23, Jim Schaad wrote: > > > > > >> -----Original Message----- From: Ludwig Seitz > >> Sent: Wednesday, January 30, 2019 12:38 AM To: Jim Schaad > >> ; draft-ietf-ace-oauth- authz@ietf.org Cc: > >> ace@ietf.org Subject: Re: Shepard review for > >> draft-ietf-ace-oauth-authz > >> > >> Thank you Jim, > >> > >> I'll upload a new version as soon as we have resolved my questions > >> below. > >> > >> /Ludwig > >> > >> On 30/01/2019 07:01, Jim Schaad wrote: > >>> 1. Update the reference from RFC 5246 to RFC 8446 in all locations > >>> > >>> > >>> > >>> Items that don't appear to be resolved: > >>> > >>> * Section 3.1 - Refresh Token - I don't think that refresh tokens > >>> are going to be strings because binary is more efficient. Unless = you > >>> are going to say that this is not OAuth 2.0, then a refresh token = is > >>> still a text string. > >>> > >>> * I don't see any text that is addressing this. > >> > >> That text just describes how it is in OAuth 2.0 (where refresh = tokens > >> are strings), since we didn't see the need to specify the use of > >> refresh tokens in ACE, we didn't mention them further. If we had we > >> would certainly have defined them to be binary. > > > > That would be fine, but you actually do define a CBOR mapping tag = for > > refresh tokens in the body of the text and define it as binary. > > > Right, > (background: I did define a mapping for all OAuth parameters and re- > mapped all that were Strings to binary. That does not necessarily mean = the > have a use case currently in ACE.) >=20 > in order to resolve this I will add a sentence in the description of = the refresh > token, saying that we define them to be binary here. >=20 >=20 > >>> ****** IANA Section Issues > >>> > >>> 1. None of the new registries appear to have any guidance for > >>> the DEs to use when approving items. > >> > >> Is it acceptable to add a single guidance section for all of the > >> new registries, or does it need to be separate for each of them? > > > > As long as the guidance is comment this is fine. That is what I did > > for all of the COSE registries > > >=20 > I'll copy liberally from your example then (and a bit from the CWT = RFC). > Hope you don't mind. I never really object to copying things that work. Just think for a bit = f anything is missing. I will probably be doing some expanding of them = in the move forward to Full Standard. >=20 >=20 > >>> > >>> 2. The title of the registry "ACE Authorization Server > >>> Information" is not really descriptive of what is in the > >>> registry. It makes sense in the text but not as a stand along > >>> title. Something along the lines of "ACE Authorization Server > >>> Request Creation Hints" seems to be closer to a solid > >>> identification. > >>> > >> Would "ACE Authorization Server Discovery Hints" be better? > > > > I thought about that, but it does not really cover the idea of = having > > the nonce value there or the possibility of later adding things like > > - ok you should use this audience or this scope or some other = similar > > thing. > > >=20 > I see. I'll use the somewhat clunky but descriptive "ACE Authorization > Server Request Creation Hints". >=20 > I've also taken the liberty of adding audience (req_aud) and scope as > optional parameters in the AS Request Creation Hints message, in order > to justify its name. I have always thought that those two items should be there anyway. =20 Jim >=20 >=20 >=20 > While resolving issues from the DTLS profile the authors have noticed > two elements that need to be added to the framework: >=20 > 1.) A definition of "Authorization Information" > "The information an RS uses to determine wether a request is = authorized, > including the claims of applicable access tokens." >=20 > 2.) Adding the "kid" parameter to the AS Request Creation Hints, so = that > a client can request a token with the same pop key when it has an > existing security association, but the token has expired. > The procedure is currently defined in the DTLS profile, but it applies > to any other profile as well and should therefore be in the framework. >=20 >=20 > /Ludwig >=20 > -- > Ludwig Seitz, PhD > Security Lab, RISE > Phone +46(0)70-349 92 51 From nobody Thu Jan 31 08:46:01 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B668126F72; Thu, 31 Jan 2019 08:46:00 -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 kqP24So-1xlJ; Thu, 31 Jan 2019 08:45:57 -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 7B78112426A; Thu, 31 Jan 2019 08:45:57 -0800 (PST) Received: from Jude (67.208.104.26) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 31 Jan 2019 08:45:52 -0800 From: Jim Schaad To: 'Francesca Palombini' , CC: References: <023901d4b8fc$b72658c0$25730a40$@augustcellars.com> In-Reply-To: Date: Thu, 31 Jan 2019 08:45:48 -0800 Message-ID: <026c01d4b984$6d36b330$47a41990$@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: AQFnk/fkaIwMlY1BYB1b9/Cas2b5AwIqf1tZppKMuYA= Content-Language: en-us X-Originating-IP: [67.208.104.26] Archived-At: Subject: Re: [Ace] Shepard comments on draft-ietf-ace-oscore-profile X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2019 16:46:00 -0000 > -----Original Message----- > From: Francesca Palombini > Sent: Thursday, January 31, 2019 6:26 AM > To: Jim Schaad ; draft-ietf-ace-oscore- > profile@ietf.org > Cc: ace@ietf.org > Subject: Re: Shepard comments on draft-ietf-ace-oscore-profile >=20 > Hi Jim, >=20 > Inline. >=20 > Thanks, > Francesca >=20 > =EF=BB=BFOn 31/01/2019, 01:34, "Jim Schaad" = wrote: >=20 >=20 > 1. Please update the text for MUST/SHOULD/MAY to include the = language > from > RFC 8174. >=20 > FP: Right, thanks. Updated now in the github. >=20 > 2. Section 3.2.1 - What to do is clear if a field is not missing. = What is > the correct behavior if a field is present that the client and/or = resource > server does not recognize. Is this a fatal error or is it = sufficient that > they may not behave the same? >=20 > FP: Assuming you are referring to fields missing in the > OSCORE_Security_Context, (please correct me otherwise) this is a good > point. We currently do not define what happens if the security context = has > unrecognized parameters. We don't foresee this happening, as the AS > should know what the client and RS implement. However, to cover this = case > (bad implementation or something went wrong), to be on the safe side, = we > propose that there is a fatal error in that case. In fact, we don't = know what > additional parameters might be registered in the = OSCORE_Security_Context, > and although they could be "risk-free" (as in optional additional = information > non-necessary for the security context derivation), they could also be = input > to the key derivation for example, in which case the endpoint non- > recognizing them would end up storing a "wrong" security context. What = do > you think? Sounds good. I had a vague thought that perhaps some of the group items = might be added in the future but no hard items to add. Jim >=20 > Jim >=20 >=20 >=20