From nobody Tue Oct 1 01:50: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 6A9CE120125; Tue, 1 Oct 2019 01:50:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 gkMXdn_wvXD2; Tue, 1 Oct 2019 01:50:28 -0700 (PDT) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60078.outbound.protection.outlook.com [40.107.6.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9136120118; Tue, 1 Oct 2019 01:50:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=W7IN4o4FaI3laUhEYXqmlR2sKANCUu7rgpwCDU9mRuwOZyUjHLpW9FjWj2grOQxWH9Mez+9szc8nodqPFGWEb5lhPKT0VoIl5B4XHA8JYz0z0ceVEg2Ei/rvpdkBLZyhUsdrJvAQ/Dl7DVAobZB8iy+QCJsDytV3vcOcT4jXZYH6FZIR/eKSu2YELO/XiE308oeXwShzQTVWiM3vKNaAB6T37uqnH44zGrmq0uHijMZYPkuaOu+DtH7xISa5RW5i3APlTrJWrG3NA6D3G4+d3ioKyvsmra/5B2kDLFs7rSmxCDKEAJBXKFKsaLtcum9/DkPcpbIPskIFXjiMnM1JFg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=8LlxAE/x11Bd5jtEH82hVeSKoFuK0Ojrv1yB0OZgr4o=; b=cbNldm4OVB9V/Iyehzm9fu3XJm89Lm6jqX8rpBB5Lis5vyrBp0ISRQZL5phIyC1Vd0qFS0lWhEIaspx3PAoqtdClY7CUIjl2FNnsvOH7CZho1uMihaJmjUq9JsJrqkvMpxQPw7YC6j/mOuEkpWMqPu4LkCwXAfQvYOJ77aukfsDY5BmBBfUmzDPv2MzZnIse7RW1prqxEZtJKHwD29E+dzSKBrUPezUBJbKkkZBQ9Ctqm8YkwZkjRzRt3ufDNzd5mLdmgacUoTxlPNw5eyNS0VZPH49ua9PLHvcuOhO1yU5fvj1l84Pe9ggv1riYIpx9QEofaRiKa+XWpXdBD6Q1IQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 194.218.146.197) smtp.rcpttodomain=ietf.org smtp.mailfrom=ri.se; dmarc=pass (p=none sp=none pct=100) action=none header.from=ri.se; dkim=none (message not signed); arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=RISEcloud.onmicrosoft.com; s=selector2-RISEcloud-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=8LlxAE/x11Bd5jtEH82hVeSKoFuK0Ojrv1yB0OZgr4o=; b=Qcqi67RW5HC0IbgjXagmJxNvhig3Qkjw/WmM4EquaDIs255z0Wxyn7VBgQDVyOBB1dcKhK1aRukwKPBLwYxkPUBnciPjTo+8w+K9t8BqDcVSqdwTinYYE9cW3kL1pIpBYYPVHw/+EXv5n9MfpiiLTCNubo2ZEoiQ4cHGewakaDg= Received: from AM5P189CA0003.EURP189.PROD.OUTLOOK.COM (2603:10a6:206:15::16) by HE1P18901MB0201.EURP189.PROD.OUTLOOK.COM (2603:10a6:3:95::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2305.17; Tue, 1 Oct 2019 08:50:23 +0000 Received: from HE1EUR02FT031.eop-EUR02.prod.protection.outlook.com (2a01:111:f400:7e05::200) by AM5P189CA0003.outlook.office365.com (2603:10a6:206:15::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.2305.20 via Frontend Transport; Tue, 1 Oct 2019 08:50:23 +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=pass 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 HE1EUR02FT031.mail.protection.outlook.com (10.152.10.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.20.2305.15 via Frontend Transport; Tue, 1 Oct 2019 08:50: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.1779.2; Tue, 1 Oct 2019 10:50:22 +0200 To: Benjamin Kaduk , Jim Schaad CC: , References: <20190927015154.GY6424@kduck.mit.edu> <026401d5751d$8325c690$897153b0$@augustcellars.com> <20191001031340.GG6424@kduck.mit.edu> From: Ludwig Seitz Message-ID: Date: Tue, 1 Oct 2019 10:50:22 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <20191001031340.GG6424@kduck.mit.edu> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms020208010900090102070803" X-Originating-IP: [10.100.0.158] X-ClientProxiedBy: sp-mail-2.sp.se (10.100.0.162) To sp-mail-2.sp.se (10.100.0.162) X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:194.218.146.197; IPV:NLI; CTRY:SE; EFV:NLI; SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(396003)(346002)(136003)(376002)(199004)(189003)(13464003)(53754006)(26005)(8676002)(40036005)(44832011)(65806001)(16526019)(126002)(11346002)(2616005)(2906002)(486006)(476003)(446003)(186003)(36756003)(70586007)(22746008)(65956001)(33964004)(86362001)(70206006)(31696002)(76176011)(386003)(305945005)(356004)(336012)(53546011)(7736002)(6246003)(568964002)(235185007)(5024004)(229853002)(54906003)(22756006)(4326008)(71190400001)(316002)(6306002)(2171002)(478600001)(31686004)(14444005)(106002)(3846002)(16576012)(966005)(8936002)(110136005)(16586007)(81156014)(58126008)(81166006)(6116002)(5660300002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1P18901MB0201; H:mail.ri.se; FPR:; SPF:Pass; LANG:en; PTR:InfoDomainNonexistent; A:1; MX:1; X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 10b9d2ff-e8ad-4a68-ddc1-08d7464c65c5 X-MS-TrafficTypeDiagnostic: HE1P18901MB0201: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:5236; X-Forefront-PRVS: 0177904E6B X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: D/b18RiZgXbTqDqXhixC4c6YDIJhNicvT/AdyMLAB/j+oQe9fbOZCxVSAE+n53WMsjOAxObHujnXsK1qMSK4uUHbD6xc7Z+CRC3U/fCkTWJhTCOF8UpPDSep/ipRKQU2QYOlzG8TROPfBzxgQswthzumihyIfG0gOAaMxX/dz3HIwERbX8vVO+5IlLmOwCbHerYQgY4Fer3T1UKAbYxZGNIrb86F7dRG27Ootf6kl/jPFGpMwL+Po2YLcz5lv6PyjE+93g9JZKL+n1FRCcjQkiaP6YUl/royzx+XSoMcZmxNvqvTLeAqZo9DD8WQCJnATzgTAoXtn6P0PeBIwrVUQcKJDMB611byz8p5NMwrfepWME9Gm27nQME20O0/bVBcpphvPP0RPqhHH+1mJagALP02Fojnq5osmbU781dnBfM= X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Oct 2019 08:50:23.4549 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 10b9d2ff-e8ad-4a68-ddc1-08d7464c65c5 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: HE1P18901MB0201 Archived-At: Subject: Re: [Ace] AD review of draft-ietf-ace-oauth-authz-24 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, 01 Oct 2019 08:50:31 -0000 --------------ms020208010900090102070803 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 01/10/2019 05:13, Benjamin Kaduk wrote: > On Fri, Sep 27, 2019 at 03:22:45AM -0700, Jim Schaad wrote: >>=20 >>=20 >> -----Original Message----- From: Ludwig Seitz =20 >> Sent: Friday, September 27, 2019 12:03 AM To: Benjamin Kaduk >> ; draft-ietf-ace-oauth-authz.all@ietf.org Cc: >> ace@ietf.org Subject: Re: AD review of >> draft-ietf-ace-oauth-authz-24 >>=20 >> On 27/09/2019 03:51, Benjamin Kaduk wrote: >>> Hi all, >>>=20 >>> The length of this review notwithstanding, this document is >>> generally in good shape -- there's a bunch of localized items to >>> tighten up, and we can flesh out the security considerations some >>> more, but nothing too drastic should be needed. Perhaps the most >>> far-reaching changes needed will be to rename the "profile" >>> claim, since that has already been allocated to OIDC Core for a >>> very different usage. I also made a pull request with a bunch of >>> trivial editorial stuff that's easier to fix than describe how to >>> fix, up at https://github.com/ace-wg/ace-oauth/pull/175 . >>>=20 >>=20 >> I have a non-trivial comment on your pull request: In appendix B >> we summarize the steps taken by an RS to process a freshly received >> access token. You changed the suggested sequence from: >=20 > First off, thank you for spotting it and bringing the discussion > here! I'm sorry that you had to do so; I wasn't trying to sneak it > in :) >=20 I didn't think so. >> * Verify the token is from a recognized AS. * Verify that the token >> applies to this RS. * Check that the token has not expired (if the >> token provides expiration information). * Check the token's >> integrity. * Store the token so that it can be retrieved in the >> context of a matching request. >>=20 >> To >>=20 >> * Verify the token is from a recognized AS. * Check the token's >> integrity. * Verify that the token applies to this RS. * Check that >> the token has not expired (if the token provides expiration=20 >> information). * Store the token so that it can be retrieved in the >> context of a matching request. >>=20 >>=20 >> I don't think this is a big deal, but I put the integrity check >> later for a good reason (or so I believe): The integrity check is >> a potentially expensive cryptographic operation. Checking that the >> token applies to the RS is a matter of checking the audience claim, >> and checking that the token is not expired is a matter of comparing >> two timestamps, I consider both to be computationally much lighter >> and therefore quicker to execute. A failure of any of those two may >> make it unnecessary to verify the token integrity. >>=20 >> BUT! My suggested sequence only works if the token is signed or >> MACed and not if it is encrypted. If the token is encrypted the >> AEAD integrity check (and decryption) is necessarily the first >> processing step. >>=20 >> Any ideas how to resolve this gracefully (i.e. without adding a >> large amount of text) are most welcome. >>=20 >> [JLS] I normally get out of this type of problem by saying "The >> order of the steps is not normative, any process which produces an >> equivalent result can be used." And then you can add a comment >> about switching the two steps for signed items. >=20 > That seems like a reasonable approach. FWIW, my thinking was that=20 > signature validation is a great way to toss out a bunch of malformed > input, and we tend to do it first in non-constrained environments, > but I can see the tradeoff running the other way in some cases. >=20 > -Ben >=20 I'll formulate some text to capture this. It's an appendix that is not=20 supposed to be normative anyways, rather it's intention was to serve a=20 guideline to help implementers. /Ludwig --=20 Ludwig Seitz, PhD Security Lab, RISE Phone +46(0)70-349 92 51 --------------ms020208010900090102070803 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DT0wggYWMIID/qADAgECAg8BaKlzCTJTye3phLaz/cIwDQYJKoZIhvcNAQELBQAwRzELMAkG A1UEBhMCU0UxFDASBgNVBAoMC1RlbGlhU29uZXJhMSIwIAYDVQQDDBlUZWxpYVNvbmVyYSBD bGFzcyAyIENBIHYyMB4XDTE5MDIwMTE0MjUxNVoXDTIxMDIwMTE0MjUxNFowgYsxCzAJBgNV BAYTAlNFMS4wLAYDVQQKDCVSSVNFIFJlc2VhcmNoIEluc3RpdHV0ZXMgb2YgU3dlZGVuIEFC MRUwEwYDVQQDDAxMdWR3aWcgU2VpdHoxEjAQBgNVBAUTCUx1ZHdpZ1NlaTEhMB8GCSqGSIb3 DQEJARYSbHVkd2lnLnNlaXR6QHJpLnNlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAlJNmRfcsto5I/yXrBIi9QroZtfAMttc1Eznv5iPCK++eFUArODhITO7k9rtlQX5D8vYF v4vzZex58YWZhvGMzDj9FdpD/PHKOxL/frlrreChuissPWo5M88DmL3V1oyGzvgeRqaafpEi 0/2+gezMFlABm/BXj3/0Fiw5Sxub7essE27EtDK05nAbUB69kfLHBEytbTAuuSb11hC1dpTf itMZkzSFwsBCyPtIv3GRt9xgnOPK4RRpHidv1GLYXNQQ7xEGhFy4qbZ2NSfM+56SSRswvW9P 5n81ZmZ4FWkiJouUIYtZ2ifncBJL4DC2chjsywDEz5No7kYrGxc5oOm1YQIDAQABo4IBuDCC AbQwHwYDVR0jBBgwFoAUnhn/5Q06/gCXFT9p8dxaPKoMlIMwHQYDVR0OBBYEFKZHZ8MZNNP5 tXMPjeFiw01pUWbtMA4GA1UdDwEB/wQEAwIFoDBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEB DDA6MDgGCCsGAQUFBwIBFixodHRwczovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEu Y29tL0NQUzAdBgNVHREEFjAUgRJsdWR3aWcuc2VpdHpAcmkuc2UwTQYDVR0fBEYwRDBCoECg PoY8aHR0cDovL2NybC0yLnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYWNsYXNz MmNhdjIuY3JsMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjB+BggrBgEFBQcBAQRy MHAwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnRydXN0LnRlbGlhLmNvbTBFBggrBgEFBQcw AoY5aHR0cDovL2NhLnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYWNsYXNzMmNh djIuY2VyMA0GCSqGSIb3DQEBCwUAA4ICAQCk0GOalOCjEJObuBeMg0QREtBP/2ona16npn+T v5R3Vjk5UsQdOaOosgVjADX68C83dyfPiWR4UfNJoTBcM8JLpEXIm+xC4BiDPTPHYvgkhgXt 9VWCRWXOMfT/UPXjiGsbPuNWja1LQzF5KOmM826kHVZItHuDY6kJLE4OZ+apFvVKtSLQJJLA 4MlDVwp5+XsZi4cftcX5HdgLdChodUPKq3XVfALfXM/p81XEFBTYOHNplr3cQytDQjsnCZnS Ic4UpsxrArNxDO9+AKu/s1Fbq494AhHj4oHcg4DIjhHUzbPCLP19Gqp4dflr/V7Ulg3d+4Zh bmSAn1cffrzvvkjVrqMgQOoHQTl2QyO9n/oJ/9CSYRmhFsQMPun9LM/p5l58dTZp53B3LgA6 FFrxnntlZnTPh3bvsMJvUQ+AoiXyQwnkdxUrhoM+gUz36t3JSA8g48h7BhPsnwQ/YrarAhJ8 ifuzykTQmDseWLjJKyFflddy/azAlPQjgSMMWOZCo2s+l+WwPISf33nls2Aec/vvG5auYHS6 pwWuVKuwZTPgJfHanZTNpBM5y0jVBz6tr8AHZypnCONgyUYA4uec3v5oWz4FvLEnlKnMGoK3 OeFGvfHG0tbP25HbdN3AJYP0EUo56wfkBOYsnmn4mEYdk2GHkJNfaQRBJljH0T7TOcmcDjCC Bx8wggUHoAMCAQICEGN8C9eFpb8p2mAtfE16cLEwDQYJKoZIhvcNAQELBQAwNzEUMBIGA1UE CgwLVGVsaWFTb25lcmExHzAdBgNVBAMMFlRlbGlhU29uZXJhIFJvb3QgQ0EgdjEwHhcNMTQx MDE2MDgzOTMwWhcNMzIxMDE2MDUwNDAwWjBHMQswCQYDVQQGEwJTRTEUMBIGA1UECgwLVGVs aWFTb25lcmExIjAgBgNVBAMMGVRlbGlhU29uZXJhIENsYXNzIDIgQ0EgdjIwggIiMA0GCSqG SIb3DQEBAQUAA4ICDwAwggIKAoICAQC0PpW2qcWGnStqfa5DjrUi79Kz2SySUlJ1kiEQ1Pd/ LWbnsEwFYPqOJwAf6ZtEDtQ/9Z1VkVNQ6MkD++keqk7648x0YANgMyiJsWrbd0TKOObtlXdJ pb5qesJ5nOAdVeL3z6lgrkZx+fsUfTV+lLRGRh2+RWzZTjPAvKotY3nAwXCHtwI5v3FKuR10 aJ9+CEOka02KSUzGjcGZwMk2io0DxLELf1gPRvqE9xmn4ioXLqpluozb4Fo9ewydufTLQc3/ I63uPQh8BlLPPIGzWb4iBDq2zbWlbx0KlH/UlUZ7fjzp6N6cAqZ2NnDaCOnnIRfUYeNXFG8/ aiBeFOpEeEpclr5QUwr9HLKL1QiyQtc/wW8acQFoKuGi8myiAch7k7S0rmU5gT05je+OTzWh Oaw7gmDdndYY1mjkPkzpQ+hxyfnwUsAitUq9j0imFOLxKWLH4QNbyuDIMvDyezzJWzMy3XPB LiLSH9CBLVQHRoQ+WW8xD4rnmvQtoGZM72og2iNf4/JCHL1AJYhQtaRjYgm3rhvAP0HhSVAB Z5aHM52ylJHC3JwUyuFm8S9A2ffY9rUTffMLWmDCnX0QAP9bKr6+ACogm4DBUj3ftYodI2TD 6F8+VjSFuCzGDPuCjK+fQ2c3wqziwFl+NgoGI9Vgc6x5+0ocKkiQAIYFaQ3SyGmI6QIDAQAB o4ICFTCCAhEwgYoGCCsGAQUFBwEBBH4wfDAtBggrBgEFBQcwAYYhaHR0cDovL29jc3AudHJ1 c3QudGVsaWFzb25lcmEuY29tMEsGCCsGAQUFBzAChj9odHRwOi8vcmVwb3NpdG9yeS50cnVz dC50ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5jZXIwEgYDVR0TAQH/BAgw BgEB/wIBADBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEBAjA6MDgGCCsGAQUFBwIBFixodHRw czovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQUzAOBgNVHQ8BAf8EBAMC AQYwgcYGA1UdHwSBvjCBuzBAoD6gPIY6aHR0cDovL2NybC0zLnRydXN0LnRlbGlhc29uZXJh LmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNybDB3oHWgc4ZxbGRhcDovL2NybC0xLnRydXN0 LnRlbGlhc29uZXJhLmNvbS9jbj1UZWxpYVNvbmVyYSUyMFJvb3QlMjBDQSUyMHYxLG89VGVs aWFTb25lcmE/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnkwHQYDVR0OBBYEFJ4Z /+UNOv4AlxU/afHcWjyqDJSDMB8GA1UdIwQYMBaAFPCPWTgAs/WPmpYM1ev6e6oX6BMSMA0G CSqGSIb3DQEBCwUAA4ICAQB5wuZFNXR5ko9cu7PcpIyH8xaoGfpimP2GTg7qVuL92D/idIlj pqMm93WC9mgL/Uy6DExoF8xSLurLaiajoU+VG6ZWg0F7P1AXARNt0RpWI5SphxBQYM2751S8 vC/22k8Vi+qpQVIREqQPVXCIEH7U6eCY9gEVzdq9l1yPoI8n0D2a8V6GCv0RVkmIpa16rNYD tTw4j3Ha56/Ua33C3qeZh1dIfkaU2h4CGHd2Em3v5LLMsEh8dqUeG9yIcCU+8RUgDahNxWMe MGxzrhwk8WBV6xeoQp20p7cSHbSbyHJURC1n+nVrgdh8hbw6WOgFhNA5tCPDZ0oSF+uHfj+b ioZE3AlYdcEqHJA9A9sO58F4/Qg/yp9oYuT0ZpKb4hmzeqDXvk5KRFNfHlhTt35i+qmas9wB 11MXbYd5WwqEhZH6HWO5H7XKJP7olxmEC0W3OKlpKafq1iPsBN5ycRfUrXFss0Ax6vpCq0XA 3LYePpQ44hOU+qrkR1M0a7Eo3++3TpP4cV+FZiO4aZYZ3yZftSRHwWpGiDBdWOdTKR2GJi7Z z/OxacrmwmM1Z+WcigldbG8f3IMnOLK4X0uXjhVeAHrhuttQuM8i+4TNXgsZbmfEKNDQIQPO /lbacsGHWFB/U2y6SXVEkZs2xIciRA0iZNTv7mbIL8SZmf5wpbjDCYHiCjGCAzgwggM0AgEB MFowRzELMAkGA1UEBhMCU0UxFDASBgNVBAoMC1RlbGlhU29uZXJhMSIwIAYDVQQDDBlUZWxp YVNvbmVyYSBDbGFzcyAyIENBIHYyAg8BaKlzCTJTye3phLaz/cIwDQYJYIZIAWUDBAIBBQCg ggGvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE5MTAwMTA4 NTAyMlowLwYJKoZIhvcNAQkEMSIEIFWBzLfrxSe5APHXa8LbKIDbYMJGIbL0ggSQ63OFFZKx MGkGCSsGAQQBgjcQBDFcMFowRzELMAkGA1UEBhMCU0UxFDASBgNVBAoMC1RlbGlhU29uZXJh MSIwIAYDVQQDDBlUZWxpYVNvbmVyYSBDbGFzcyAyIENBIHYyAg8BaKlzCTJTye3phLaz/cIw awYLKoZIhvcNAQkQAgsxXKBaMEcxCzAJBgNVBAYTAlNFMRQwEgYDVQQKDAtUZWxpYVNvbmVy YTEiMCAGA1UEAwwZVGVsaWFTb25lcmEgQ2xhc3MgMiBDQSB2MgIPAWipcwkyU8nt6YS2s/3C MGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0D BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwIC ASgwDQYJKoZIhvcNAQEBBQAEggEAOOpWjOJhJDZXkhJinIGngMRxGYeQiDuBExUrDcoD1fpY 2o1vELi/rk/e/fBhvLzgPdBFBGdKVyM+nxRKjFMgv1BuiioNHJiwHcIUK9ARjx9QwWl10Ory 9lEuE5P5oTCgJf996nVPmmaaiZyAi0bI/wcMp6txkIrvcBJvlBOjw1I7OlkDHbcfqgvUl7uR kjrdcEyU0HsppB5rvj5ITqs8q4YLT3mXJ9BCRkndL0RpCFGdMFo+rb4mqi5yxu2dujPOCG+U uuUXKdR3Tllmo6S9if03ldXX8wves1nD7VupZOTbNWnqebJiZKSw3FPNoYEg1YwHTpbucWwF q7nnqI9IjQAAAAAAAA== --------------ms020208010900090102070803-- From nobody Tue Oct 1 08:16:53 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 12DFC1208E4; Tue, 1 Oct 2019 08:16:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ace@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.103.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ace@ietf.org Message-ID: <156994301193.23520.6251549566074022596@ietfa.amsl.com> Date: Tue, 01 Oct 2019 08:16:52 -0700 Archived-At: Subject: [Ace] I-D Action: draft-ietf-ace-coap-est-15.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, 01 Oct 2019 15:16:52 -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-15.txt Pages : 50 Date : 2019-10-01 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-15 https://datatracker.ietf.org/doc/html/draft-ietf-ace-coap-est-15 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-coap-est-15 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 Oct 1 08:32: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 4B58F12091D; Tue, 1 Oct 2019 08:32:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 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_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 header.b=dl4s38nQ; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=Rc61m2/f 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 JGjh_nyr8KZE; Tue, 1 Oct 2019 08:32:17 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E66431209BF; Tue, 1 Oct 2019 08:32:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2347; q=dns/txt; s=iport; t=1569943937; x=1571153537; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=aGfJdAIXe2rZtwCNBn8JHxYWIzHGGoQDXtsLvZL8Djw=; b=dl4s38nQQ0ltCmeHtCJRkmQUokFf84zI06t6ZzGrlH9D3lkQam6tk17V CRj0+eEnd0Ad7bD5AKDbT/0cku4NGfrz1MF3UQb0mygjbHlC7XprCE069 pl2c8A7GYnkaPfw1xIwoxJgctrzXBJCWmlkElHdy3VuIsXrLkvWMn8866 c=; IronPort-PHdr: =?us-ascii?q?9a23=3AwZ2X+xNawiGtRRORklYl6mtXPHoupqn0MwgJ65?= =?us-ascii?q?Eul7NJdOG58o//OFDEu6w/l0fHCIPc7f8My/HbtaztQyQh2d6AqzhDFf4ETB?= =?us-ascii?q?oZkYMTlg0kDtSCDBjjL/fvdyU8FexJVURu+DewNk0GUMs=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DtAAA+cZNd/49dJa1mHAEBAQQBAQw?= =?us-ascii?q?EAQGBVQUBAQsBgUpQA21WIAQLKodpA4pfTYIPl3eBLoEkA1QJAQEBDAEBGAs?= =?us-ascii?q?KAgEBhEACgi8jNgcOAgMJAQEEAQEBAgEFBG2FLQyFSwEBAQEDAQEQKAYBASw?= =?us-ascii?q?GBgsEAgEIEQQBAR8QJwsdCAIEARIIGoMBgWoDHQECDKQxAoE4iGGCJ4J9AQE?= =?us-ascii?q?FgTgCDkGCfhiCFwmBNAGFFYZ4GIFAP4FXgkw+gmEBAQIBARaBSYM9giatKQq?= =?us-ascii?q?CIoYiZI4mgjhyhlyPM44jiByRDQIEAgQFAg4BAQWBWQYsgVhwFRohgmwJRxA?= =?us-ascii?q?UgU+Dc4UUhT90gSmQRAEB?= X-IronPort-AV: E=Sophos;i="5.64,571,1559520000"; d="scan'208";a="342590209" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 01 Oct 2019 15:31:54 +0000 Received: from XCH-ALN-013.cisco.com (xch-aln-013.cisco.com [173.36.7.23]) by rcdn-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id x91FVsVR005105 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 1 Oct 2019 15:31:54 GMT Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-ALN-013.cisco.com (173.36.7.23) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 1 Oct 2019 10:31:53 -0500 Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 1 Oct 2019 11:31:53 -0400 Received: from NAM01-SN1-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 1 Oct 2019 11:31:53 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=A6K3yDGnA0kX4oedewLJplvQg9cL/8mS5R8s1jxdBjSJlpwiEfgKRXIDJuVBYjeYqRcZKRL+81WLQTo+nrykFGvIEgqH+zu5rOMXiU3XxF4A4Q4obBSvMzcMC1W21A1pMOh+N2GrN7P+USrpJm3400sVR5N+pUYvmcgPMXwsKtYxH5g7G4owSGiNFhXIc+Hef0xN6aoibKQ8yEPdSPhFIlb1weJGuQmeC1QeHKy/wUTaEajHEwOqzk0eHMlk1Z09eEYUhFxY+KnXCcfNIdZDpebEZOPieEKeVsc03MdWG90oLQ/VwWc+FKH0yEm9TCWeo7NBJXe5sC+EkWwK/7mWyA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=02q052pruXoAX6uSYp6Rb+oye8zBWogeqANjQuDdXJI=; b=WGMO64SjpEcVaTMOec+B8KrrwpIeou+2CYDlpGfTIcVWd1Vbl8P6+FyVCmGDJWmaWvQNlKOKRGBKQT3kaghMW95xUFkPhvVJFs75UU1GpEphMUWacm58rFnmYRYhH25MKkhza+oLnBNOmXZ2zgJ/+KdeEN/YhoWBZYOEmlgMHknFXpIdVPC6Rtjg7WLSCexWflH745CEVZWZpVrROe6cx3ZQsnvee67GxbBzE0pq19ywJ1oeMom9it6vgu7da981w9/OKDqFvUQ8HNqfaF4934Xe9nutgo+Ei8lTocOb0Y3JkI1/wolXHTZvZNciRPhc0Bb3wQdW5lh+VfYVhRq5Og== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=02q052pruXoAX6uSYp6Rb+oye8zBWogeqANjQuDdXJI=; b=Rc61m2/fQfzq8H+T8uLzRsIXGhV9tVDeu3lwVKAbfPabgXWDNfPQyX9BABxLE8F22lNvjmlg7q+Sm7MB4BumsXY7u5/kcYv1IEoTVsuuatzr0ogsrYVWrpWFgWmJLFdu6/I2IS3/OcwphL3FYyJmKTJMt+fJ/1knSa7xxMo5rUw= Received: from BN7PR11MB2547.namprd11.prod.outlook.com (52.135.255.146) by BN7PR11MB2804.namprd11.prod.outlook.com (52.135.254.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2305.15; Tue, 1 Oct 2019 15:31:51 +0000 Received: from BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::20df:b3df:537d:fd20]) by BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::20df:b3df:537d:fd20%7]) with mapi id 15.20.2305.022; Tue, 1 Oct 2019 15:31:51 +0000 From: "Panos Kampanakis (pkampana)" To: "ace@ietf.org" , "i-d-announce@ietf.org" Thread-Topic: [Ace] I-D Action: draft-ietf-ace-coap-est-15.txt Thread-Index: AQHVeGtaWoHFXfxTIE6isck77sNcFqdF5tdA Date: Tue, 1 Oct 2019 15:31:51 +0000 Message-ID: References: <156994301193.23520.6251549566074022596@ietfa.amsl.com> In-Reply-To: <156994301193.23520.6251549566074022596@ietfa.amsl.com> 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=pkampana@cisco.com; x-originating-ip: [2001:420:c0c4:1006::151] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 6d710b8b-d357-4388-9f90-08d746847b5c x-ms-traffictypediagnostic: BN7PR11MB2804: x-ms-exchange-purlcount: 5 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-forefront-prvs: 0177904E6B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(376002)(366004)(136003)(346002)(39860400002)(189003)(199004)(13464003)(60444003)(7736002)(305945005)(76116006)(7696005)(71200400001)(66946007)(66476007)(8936002)(486006)(6246003)(186003)(450100002)(25786009)(71190400001)(74316002)(66446008)(64756008)(66556008)(102836004)(6506007)(53546011)(478600001)(81166006)(2501003)(81156014)(76176011)(52536014)(99286004)(5660300002)(66574012)(256004)(316002)(110136005)(6116002)(14454004)(46003)(966005)(86362001)(229853002)(6436002)(476003)(8676002)(11346002)(33656002)(446003)(6306002)(55016002)(9686003)(2906002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN7PR11MB2804; H:BN7PR11MB2547.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 17nb/Jc9kQJPKg+72ZS1s7bpoB6ALEuc5d3iu0rXzHCPHSaarWM2erPaA89xjNrb3cMLZa+Z4Hy/QcTTWElh7I/mi5i0yLyby+YLdo/TCfzXv7vBFZ8GzfvoX6xFhn42lwZZoL9u2/EqcQLLgYtpK+mxXE7ywWhOHNwBp/WoLi2cwlFyCMkzLv0S6NBBb0Jg/j6MP0WldM4pPyMOPh1Ga2ptPjbeppBECZF2DJ/8dYXFLgUsateO/6q9pfxhkQ2Y8ZbWOttgCAKUogca8m1HuHCUi8LnJniqXdAtM418VJt2rT8kbZ38rbb7Anows4BdO3RkZUwhq6DJsBKqlhElYYE1UEr7G5/gHw4y0+PQ1npoAr6VUThDY7DMpm1enXl1/pRK7Pl7p8Jv415Z7zHcELB6ThCqwhOh3et9eRiQMWuaxzb7dw/93pSZF+jI6AewIE43+9ubP5SkX7T6cswFKw== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 6d710b8b-d357-4388-9f90-08d746847b5c X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Oct 2019 15:31:51.4320 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: gJk++2iQDv+W7B1fRsRhdMut0XP3SUoVrPkg2Z/tdO22zl97CsC4S4YJauhX2wWXJTmm3VyS2RIv8AhJYLFjow== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR11MB2804 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.23, xch-aln-013.cisco.com X-Outbound-Node: rcdn-core-7.cisco.com Archived-At: Subject: Re: [Ace] I-D Action: draft-ietf-ace-coap-est-15.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, 01 Oct 2019 15:32:19 -0000 Hello,=20 The v15 iteration addresses Ben K.'s latest feedback in response to the fix= es that went in after his AD review. Thank you for the detailed feedback Be= n.=20 The diff from v14 is here https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ac= e-coap-est-15=20 I think it could move to the next stage now.=20 Thanks, Panos -----Original Message----- From: Ace On Behalf Of internet-drafts@ietf.org Sent: Tuesday, October 01, 2019 11:17 AM To: i-d-announce@ietf.org Cc: ace@ietf.org Subject: [Ace] I-D Action: draft-ietf-ace-coap-est-15.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-15.txt Pages : 50 Date : 2019-10-01 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-15 https://datatracker.ietf.org/doc/html/draft-ietf-ace-coap-est-15 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ace-coap-est-15 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 Tue Oct 1 17:45:40 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 978B112011E; Tue, 1 Oct 2019 17:45:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: internet-drafts@ietf.org To: Cc: ace@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.104.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ace@ietf.org Message-ID: <156997713858.26339.11509507938538341071@ietfa.amsl.com> Date: Tue, 01 Oct 2019 17:45:38 -0700 Archived-At: Subject: [Ace] I-D Action: draft-ietf-ace-cwt-proof-of-possession-08.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Oct 2019 00:45:39 -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 : Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs) Authors : Michael B. Jones Ludwig Seitz Göran Selander Samuel Erdtman Hannes Tschofenig Filename : draft-ietf-ace-cwt-proof-of-possession-08.txt Pages : 16 Date : 2019-10-01 Abstract: This specification describes how to declare in a CBOR Web Token (CWT) that the presenter of the CWT possesses a particular proof-of- possession key. Being able to prove possession of a key is also sometimes described as being the holder-of-key. This specification provides equivalent functionality to "Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)" (RFC 7800) but using CBOR and CWTs rather than JSON and JWTs. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ace-cwt-proof-of-possession/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ace-cwt-proof-of-possession-08 https://datatracker.ietf.org/doc/html/draft-ietf-ace-cwt-proof-of-possession-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-cwt-proof-of-possession-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Oct 1 18:11: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 E528812009E for ; Tue, 1 Oct 2019 18:11:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=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 NvG_2AU8MpOo for ; Tue, 1 Oct 2019 18:11:39 -0700 (PDT) Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650133.outbound.protection.outlook.com [40.107.65.133]) (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 A2E8B120073 for ; Tue, 1 Oct 2019 18:11:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=V+T4VFRFoCtwlu5zWSfcJj0Kcql/08pL1WHwD61Yf3b0oUJgXt36UFMLtPEjXqHa6w7p6AuYtwQBXZElCYaaGmV/KUG9P/fwwrp0FPfHtV7MNIB6BRMsqRJu7YPVY734V11SpGg7OjEaSI99m57t8fyKUDMvRv+X305OrY/DK7giJP6YPh8BXpMbziG6o4Seozwh5GuU1+w6aeLiduvx8o8XMQni27PvEXsNqdo1o97xn6OtgJqKOuk0WINkZmixyWY/5MXlcBOGpDsLPtjzwN4hmqUK0zzfHtXR1yEZf09XBQFZiAlMxtsxGlzqV7+3fUkrccVnoHc+PyTpUvF9Jw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=e9GBDHYgoxG2j3R6TD5udbQ6rm7Y8/DY2ebl5OG3o+o=; b=mEpMHX4AtsT1MlGpzRfb9GFQfeu2F64aYnm5wpwqTS7FFu8Y0GfaeantkgBh6cpA1dQaJ6igAG9hUU/xbu/UWNPDfV4eVBCpSRFL+cYacdxQl1QSrt/8g+DzRrByLRwHnK5p8TXmJofrhIqoiISmgoD9J/4vAJ4+ksz6s2kWKOue/KsCIaVfO5Ibk/Xabvm+oJmIfIgKUoCzaQF4chG8QAix6VgqU9P26APNDU5M+vQFT45Mr24zAaqLZq21gced10YbUZMcrsSfLprf3g6elWBAgFAzjpeo4xXCfQttNl0wRUKt6tmr9LrB4EF6s3PblpMMa7DdEJ2cLAyxeucveQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=e9GBDHYgoxG2j3R6TD5udbQ6rm7Y8/DY2ebl5OG3o+o=; b=bmjP+pjTnTpFsGSOnRmja8HcDfuQM0bU39g5OH3KC2BT2WRC3Oz6FhyVHhZehEO8xBxA/6g+RqNYi0mw1L+nohXFARLPsNXw9HeNU6reAKt6CnrB6SEYaXY2gkejM3D//6t+f9+Qu3eeAB/29tXp5YEi8PQr3cqiqqxNSv21HYk= Received: from BYAPR00MB0565.namprd00.prod.outlook.com (20.179.56.23) by BYAPR00MB0616.namprd00.prod.outlook.com (20.179.56.206) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2360.0; Wed, 2 Oct 2019 01:11:12 +0000 Received: from BYAPR00MB0565.namprd00.prod.outlook.com ([fe80::18bf:ced0:453a:2fd1]) by BYAPR00MB0565.namprd00.prod.outlook.com ([fe80::18bf:ced0:453a:2fd1%7]) with mapi id 15.20.2360.000; Wed, 2 Oct 2019 01:11:12 +0000 From: Mike Jones To: "ace@ietf.org" CC: Ludwig Seitz Thread-Topic: Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs) spec addressing remaining Area Director comments Thread-Index: AdV4vTTVhH+XldsnSQ2lkvuYL4D1eQ== Date: Wed, 2 Oct 2019 01:11:12 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=4b2867f2-d0c0-463a-a6f2-00002487fcc3; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2019-10-02T01:03:27Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [67.207.105.98] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 514dfc1a-0e66-4c9f-c95b-08d746d56a8c x-ms-office365-filtering-ht: Tenant x-ms-traffictypediagnostic: BYAPR00MB0616: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 0178184651 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(376002)(366004)(136003)(346002)(396003)(39860400002)(209900001)(199004)(189003)(14454004)(22452003)(606006)(316002)(6436002)(4744005)(5660300002)(5640700003)(66066001)(55016002)(54896002)(9686003)(236005)(10290500003)(6306002)(52536014)(86362001)(478600001)(966005)(21615005)(256004)(71200400001)(71190400001)(25786009)(486006)(2906002)(33656002)(6916009)(102836004)(476003)(26005)(81166006)(8990500004)(66946007)(4326008)(8676002)(1730700003)(81156014)(66556008)(64756008)(66446008)(66476007)(76116006)(3846002)(10090500001)(2501003)(99286004)(7696005)(790700001)(6116002)(7736002)(6506007)(8936002)(74316002)(2351001)(186003)(6606295002); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR00MB0616; H:BYAPR00MB0565.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: BCL:0; x-microsoft-antispam-message-info: ynWKFkzcsIp2sHELGyzYCdG9YS7/oSKKHcWA6l5PlnCy/zD+IzkeSLi6b9FIgTg3KHuIrIN2c2ngjz+8w4HiOdEsB6zb0RbCBi2TK8lPwixsp6uBS/kGQkOIqVqiPsDrW16wydgNPdDixkKCVF4aLjCXTpNIq5dSIMiKdiVT1o6UsIVCVM+8aQgdNQLYS5yDBgxx3eCAWiTB4xelWQrQPJYRQXIKR816WwC5XVpFZXZ5UGwe4L2FsBsS64P431kv6sZi3hi0Thx9Kvl4mKWAD0XXMih+nVgO/HDdg7nr2yHC3Gr//vj5eN8I2Q+gZTtPTd8GMbzLmOPOkvrj4NqfCb39GymO+o7Z4IychlFKgeg2BAIZDEVsrg7pN7NrxHQKcRa4Cbzs0m7rALoUlYWr8EqbRfzUy5+TAzOOg/N6KmQ= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BYAPR00MB0565619FA74654D9A11F14FDF59C0BYAPR00MB0565namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 514dfc1a-0e66-4c9f-c95b-08d746d56a8c X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Oct 2019 01:11:12.3695 (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-CrossTenant-userprincipalname: poq8HTxRCMpahybNPn9JZt7CxsCPYDXD9cXgxx1WR0zbD6IblhqUp/z19WSKrrYMVxqIjcWIMyefv2zqf8KDVQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR00MB0616 Archived-At: Subject: [Ace] Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs) spec addressing remaining Area Director comments 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, 02 Oct 2019 01:11:41 -0000 --_000_BYAPR00MB0565619FA74654D9A11F14FDF59C0BYAPR00MB0565namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable A new version of the Proof-of-Possession Key Semantics for CBOR Web Tokens = (CWTs) specification has been published to address the remaining Area Direc= tor review comments by Benjamin Kaduk. Thanks to Ludwig Seitz for doing the= bulk of the editing for this version. The specification is available at: * https://tools.ietf.org/html/draft-ietf-ace-cwt-proof-of-possession-08 An HTML-formatted version is also available at: * http://self-issued.info/docs/draft-ietf-ace-cwt-proof-of-possession-0= 8.html -- Mike P.S. This note was also posted at http://self-issued.info/?p=3D2010 and @s= elfissued. --_000_BYAPR00MB0565619FA74654D9A11F14FDF59C0BYAPR00MB0565namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

A new version of the Proof-of-Possession Key Semanti= cs for CBOR Web Tokens (CWTs) specification has been published to address t= he remaining Area Director review comments by Benjamin Kaduk. Thanks to Lud= wig Seitz for doing the bulk of the editing for this version.

 

The specification is available at:

 

An HTML-formatted version is also available at:=

 

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

 

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

--_000_BYAPR00MB0565619FA74654D9A11F14FDF59C0BYAPR00MB0565namp_-- From nobody Wed Oct 2 05:00:50 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 1F1E1120046 for ; Wed, 2 Oct 2019 05:00:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 CjQamVW-CLGQ for ; Wed, 2 Oct 2019 05:00:44 -0700 (PDT) Received: from mail-qt1-x844.google.com (mail-qt1-x844.google.com [IPv6:2607:f8b0:4864:20::844]) (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 61A8C12000F for ; Wed, 2 Oct 2019 05:00:44 -0700 (PDT) Received: by mail-qt1-x844.google.com with SMTP id l3so25940131qtr.4 for ; Wed, 02 Oct 2019 05:00:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=HauOcKmEoU3HDFol/eCUVXwQv8hh6njuVfvchM1ih64=; b=H/zh5R9cl0VYHQ244ey8mVr9lbHS5cm8RpwSf860xxpYVKLRS1wXvEOuA6fMoxoTNj dkcFrhkjPv5EtLwmzK4nvk3nB71apCBtD6Xs+U2ClxkAL3jYSErTUE0o7a/JieaTYDu3 D2g73pXuT3KtolN/gWdsytXvANEk3+ovUkldWhQbAWW8dwQbAP5JdUMzDFx6dAitmXZh nf0VZqMw3QqlXMLu3dnMwCtlQlf7abxPK+nwHXdc9J64FLwDhuR8TmuWxOcZ+Qn5+uTG Qv9cODonnnB1r/g7YQMMdhQ3HPpb5W++oUdP5N7dH4Wmsqeik3BAtj4GYzBQ/KVV/mfh Fpmw== 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=HauOcKmEoU3HDFol/eCUVXwQv8hh6njuVfvchM1ih64=; b=rZOKlMBt45UXVrhoPVWZWkQ80NAoj0SlK9f7fy/laF/34OBEKseK+S11ixSBtSCR9Q jIiXJ2wGEiQHWL0i6OltwCpirex+p5FT9TuQcQGn8+/af4fNtJXV4cqXSKLv4xLJyqRc faJPviZG5BzB/egoxC6RGSW9ROy5l7MkRyB2NQeVseltwj8RMnycXlvoWBE1+04wuJ4v /Am5LdLb9m7ypGsD1GEHfoWpQcISDpc2ow9znQ1ByWdbzYvMpSYav5NgpvYNdlvFOHuK hzLDgg7wTNcIxcLZWAicqW8J53eHkrfhKdoItySgm8gZNLfMzih9DfC88AP8nIqk3T8g kiug== X-Gm-Message-State: APjAAAXqzX1lMMeAwO/WErnV9+gnioONAOW/Z+zWn2lbnccjBdv9Zyhk 43h8o6BiiVG/nacyIp+Z5o3CGzIxSpWXPT7VGBo= X-Google-Smtp-Source: APXvYqzgS5OWLkay6TPAAfjZ2kuQCP1j8KnhVHchc68+cW6FUCv1qEfhXpS7bC9UCZ5CJT8DJETT7GyJEkp+uU5L8cA= X-Received: by 2002:ac8:36b0:: with SMTP id a45mr3545459qtc.105.1570017642833; Wed, 02 Oct 2019 05:00:42 -0700 (PDT) MIME-Version: 1.0 References: <000201d51814$34a85fc0$9df91f40$@augustcellars.com> <9a0bbcd4-6055-729c-7ca8-205d0a1fd681@ri.se> <010901d51b04$92788a10$b7699e30$@augustcellars.com> In-Reply-To: From: Cigdem Sengul Date: Wed, 2 Oct 2019 13:00:31 +0100 Message-ID: To: Jim Schaad Cc: Ludwig Seitz , ace@ietf.org Content-Type: multipart/alternative; boundary="000000000000e47bd60593ec3766" Archived-At: Subject: Re: [Ace] Transporting different types of cnf objects - CBOR vs JSON 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, 02 Oct 2019 12:00:47 -0000 --000000000000e47bd60593ec3766 Content-Type: text/plain; charset="UTF-8" Hello all, I am trying to implement this discussion in the draft. A point is raised about COSE keys in JSON messages. Could it be possible to go with: (1) HTTPS - application/ace+json - jwt - jose - PoP for JWT or (2) CoAP - application/ace+cbor - cwt - cose - PoP for CWT without mixing anything? (1) we thought to describe by default in the document, and (2) we said MAY be supported. Is there a problem with this approach? Thanks, --Cigdem On Tue, Jun 4, 2019 at 9:29 PM Cigdem Sengul wrote: > Hello, > Yes, we thought supporting JSON option would be good, though indeed there > is no issue with transporting CBOR. > If there are no other concerns, we can define the new media type in the > MQTT draft. > Will add the issue to GitHub repo. > > --Cigdem > > On Tue, Jun 4, 2019 at 7:37 PM Jim Schaad wrote: > >> >> >> > -----Original Message----- >> > From: Ace On Behalf Of Ludwig Seitz >> > Sent: Monday, June 3, 2019 11:51 PM >> > To: ace@ietf.org >> > Subject: Re: [Ace] Transporting different types of cnf objects - CBOR >> vs JSON >> > >> > On 01/06/2019 02:51, Jim Schaad wrote: >> > > Ludwig, >> > > >> > > I have been doing some adaptions of my codebase for dealing with the >> > > MQTT specification. In the process of this, I have identified the >> > > following items that I think needs some discussion. They may not need >> > > changes in any documents and maybe should get a new document. >> > > >> > > 1. The MQTT document is using the content type "application/json" >> > > over HTTPS for transporting messages. Does there need to be an >> > > "application/ace+json" defined as a media type, but not necessarily a >> > > CBOR media type? I think the answer may be yes, but it could be a new >> > document. >> > > >> > I would argue that the first draft using such a media type would be the >> right >> > place to specify it. However I'm not sure using JSON is the right >> approach for >> > an ACE specification at all, aren't we supposed to cater for the >> constrained >> > world? >> > What is there to prevent us from transporting CBOR over HTTP? >> >> There would be no reason that one cannot transport CBOR over HTTP. >> During the discussions for these drafts Hannes was very explicit that he >> wanted to be able to use JSON rather than CBOR with the protocol that was >> defined by ACE. This would mean that there needs to be an ability to use >> JSON with the ACE framework document. >> >> I would have no problems with the statement that the MQTT document would >> be a good place to define the new media type. >> >> > >> > > 2. If I use a "COSE_Key" confirmation method inside of an >> > > application/ace+json message, there is a potential problem and it >> > > could be dealt with in a number of different ways. >> > > * The JWT confirmation method is identified as "jwk". The COSE key >> > > must be translated into JOSE even if there is no equivalent key in >> > > JOSE. I.e. that is a fatal error >> > > * This does not make sense and the confirmation method should be >> > > changed to "cwk" so that either key format could be used in either >> > encoding. >> > > >> > >> > If we use JSON messages mixing in COSE becomes awkward. If the use case >> > calls for JSON, I'd argue it should also use RFC7800 instead of >> draft-ietf-ace- >> > cwt-proof-of-possession. >> >> I would not have a problem with this, it was one of the options above. I >> was just expanding my code to allow for JSON to be used and ran into this. >> I just wanted to get a clear group decision on this before I put things >> into stone. >> >> Jim >> >> > >> > > 3. If the confirmation is changed, you would need to convert the COSE >> > > key to a binary string, base64 encoded it and pass as a string when >> > > occurring in a JSON encoding. There is not any other valid way to do >> > > this (except see above of just converting the key format). However, >> > > the opposite of putting a JOSE key into a COSE confirmation has three >> > > different options that could be used. >> > > * Encode the JOSE key to a string and pass as a string >> > > * Encode the JOSE key top level map as CBOR but leave all of the >> > > elements alone. >> > > * Encode the JOSE key in CBOR including conversion of base64 strings >> > > to binary data. >> > > (My first preference is probably the second option, but either of the >> > > first two make sense.) >> > > >> > > Jim >> > > >> > >> > I'm still unsure that there is a good use case for transporting JOSE >> keys in >> > CBOR, but if such a case turns up, I would agree that touching the >> encoding >> > as little as possible is a good idea (=option 1 or 2). >> > >> > /Ludwig >> > >> > -- >> > Ludwig Seitz, PhD >> > Security Lab, RISE >> > Phone +46(0)70-349 92 51 >> >> >> _______________________________________________ >> Ace mailing list >> Ace@ietf.org >> https://www.ietf.org/mailman/listinfo/ace >> > --000000000000e47bd60593ec3766 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello all,=C2=A0

I am trying to impleme= nt this discussion in the draft.=C2=A0 A point is raised about COSE keys in= JSON messages.=C2=A0
Could it be possible to go with:
= (1) HTTPS - application/ace+json - jwt - jose - PoP for JWT
or
(2) CoAP - application/ace+cbor - cwt - cose - PoP for CWT
without mixing anything?

(1) we thought to descr= ibe by default in the document, and (2) we said MAY be supported.=C2=A0
Is there a problem with this approach?

Than= ks,
--Cigdem=C2=A0


On Tue, Jun 4, 2019 at 9:2= 9 PM Cigdem Sengul <cigdem.se= ngul@gmail.com> wrote:
Hello,
Yes, we thought supporting JSON o= ption would be good, though indeed there is no issue with transporting CBOR= .=C2=A0
If there are no other concerns, we can define the new med= ia type in the MQTT draft.=C2=A0
Will add the issue to GitHub rep= o.

--Cigdem=C2=A0

On Tue, Jun 4, 2019 at 7:37= PM Jim Schaad <ietf@augustcellars.com> wrote:


> -----Original Message-----
> From: Ace <ace-bounces@ietf.org> On Behalf Of Ludwig Seitz
> Sent: Monday, June 3, 2019 11:51 PM
> To: ace@ietf.org=
> Subject: Re: [Ace] Transporting different types of cnf objects - CBOR = vs JSON
>
> On 01/06/2019 02:51, Jim Schaad wrote:
> > Ludwig,
> >
> > I have been doing some adaptions of my codebase for dealing with = the
> > MQTT specification.=C2=A0 In the process of this, I have identifi= ed the
> > following items that I think needs some discussion.=C2=A0 They ma= y not need
> > changes in any documents and maybe should get a new document.
> >
> > 1.=C2=A0 The MQTT document is using the content type "applic= ation/json"
> > over HTTPS for transporting messages.=C2=A0 Does there need to be= an
> > "application/ace+json" defined as a media type, but not= necessarily a
> > CBOR media type?=C2=A0 I think the answer may be yes, but it coul= d be a new
> document.
> >
> I would argue that the first draft using such a media type would be th= e right
> place to specify it. However I'm not sure using JSON is the right = approach for
> an ACE specification at all, aren't we supposed to cater for the c= onstrained
> world?
> What is there to prevent us from transporting CBOR over HTTP?

There would be no reason that one cannot transport CBOR over HTTP.=C2=A0 Du= ring the discussions for these drafts Hannes was very explicit that he want= ed to be able to use JSON rather than CBOR with the protocol that was defin= ed by ACE.=C2=A0 This would mean that there needs to be an ability to use J= SON with the ACE framework document.

I would have no problems with the statement that the MQTT document would be= a good place to define the new media type.

>
> > 2.=C2=A0 If I use a "COSE_Key" confirmation method insi= de of an
> > application/ace+json message, there is a potential problem and it=
> > could be dealt with in a number of different ways.
> > *=C2=A0 The JWT confirmation method is identified as "jwk&qu= ot;.=C2=A0 The COSE key
> > must be translated into JOSE even if there is no equivalent key i= n
> > JOSE.=C2=A0 I.e. that is a fatal error
> > *=C2=A0 This does not make sense and the confirmation method shou= ld be
> > changed to "cwk" so that either key format could be use= d in either
> encoding.
> >
>
> If we use JSON messages mixing in COSE becomes awkward. If the use cas= e
> calls for JSON, I'd argue it should also use RFC7800 instead of dr= aft-ietf-ace-
> cwt-proof-of-possession.

I would not have a problem with this, it was one of the options above.=C2= =A0 I was just expanding my code to allow for JSON to be used and ran into = this.=C2=A0 I just wanted to get a clear group decision on this before I pu= t things into stone.

Jim

>
> > 3.=C2=A0 If the confirmation is changed, you would need to conver= t the COSE
> > key to a binary string, base64 encoded it and pass as a string wh= en
> > occurring in a JSON encoding.=C2=A0 There is not any other valid = way to do
> > this (except see above of just converting the key format).=C2=A0 = However,
> > the opposite of putting a JOSE key into a COSE confirmation has t= hree
> > different options that could be used.
> > *=C2=A0 Encode the JOSE key to a string and pass as a string
> > *=C2=A0 Encode the JOSE key top level map as CBOR but leave all o= f the
> > elements alone.
> > *=C2=A0 Encode the JOSE key in CBOR including conversion of base6= 4 strings
> > to binary data.
> > (My first preference is probably the second option, but either of= the
> > first two make sense.)
> >
> > Jim
> >
>
> I'm still unsure that there is a good use case for transporting JO= SE keys in
> CBOR, but if such a case turns up, I would agree that touching the enc= oding
> as little as possible is a good idea (=3Doption 1 or 2).
>
> /Ludwig
>
> --
> Ludwig Seitz, PhD
> Security Lab, RISE
> Phone +46(0)70-349 92 51


_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
--000000000000e47bd60593ec3766-- From nobody Wed Oct 2 06:05: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 E4DDC120019 for ; Wed, 2 Oct 2019 06:05:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=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 VUj0tKDJTQIH for ; Wed, 2 Oct 2019 06:04:59 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49E1712000F for ; Wed, 2 Oct 2019 06:04:59 -0700 (PDT) Received: from [10.159.97.60] (ewa_guest_internet_sthlm_nat2.ericsson.net [192.176.1.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 46jxF52qRZzycT; Wed, 2 Oct 2019 15:04:57 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: Date: Wed, 2 Oct 2019 15:04:56 +0200 Cc: Jim Schaad , Ludwig Seitz , ace@ietf.org X-Mao-Original-Outgoing-Id: 591714294.919346-2f44c50a1ebcd12956fb22dba089bda3 Content-Transfer-Encoding: quoted-printable Message-Id: <586CDF5F-F0E4-4514-8AB7-AAA383CA23FB@tzi.org> References: <000201d51814$34a85fc0$9df91f40$@augustcellars.com> <9a0bbcd4-6055-729c-7ca8-205d0a1fd681@ri.se> <010901d51b04$92788a10$b7699e30$@augustcellars.com> To: Cigdem Sengul X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Ace] Transporting different types of cnf objects - CBOR vs JSON 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, 02 Oct 2019 13:05:02 -0000 There is no strong interdependency between Web transfer protocol = (HTTPS/CoAPS) and data format. COSE works great over HTTPS, and if it must be, you can ship JOSE over = CoAPS. Gr=C3=BC=C3=9Fe, Carsten > On Oct 2, 2019, at 14:00, Cigdem Sengul = wrote: >=20 > Hello all,=20 >=20 > I am trying to implement this discussion in the draft. A point is = raised about COSE keys in JSON messages.=20 > Could it be possible to go with: > (1) HTTPS - application/ace+json - jwt - jose - PoP for JWT > or > (2) CoAP - application/ace+cbor - cwt - cose - PoP for CWT > without mixing anything? >=20 > (1) we thought to describe by default in the document, and (2) we said = MAY be supported.=20 > Is there a problem with this approach? >=20 > Thanks, > --Cigdem=20 >=20 >=20 > On Tue, Jun 4, 2019 at 9:29 PM Cigdem Sengul = wrote: > Hello, > Yes, we thought supporting JSON option would be good, though indeed = there is no issue with transporting CBOR..=20 > If there are no other concerns, we can define the new media type in = the MQTT draft.=20 > Will add the issue to GitHub repo. >=20 > --Cigdem=20 >=20 > On Tue, Jun 4, 2019 at 7:37 PM Jim Schaad = wrote: >=20 >=20 > > -----Original Message----- > > From: Ace On Behalf Of Ludwig Seitz > > Sent: Monday, June 3, 2019 11:51 PM > > To: ace@ietf.org > > Subject: Re: [Ace] Transporting different types of cnf objects - = CBOR vs JSON > >=20 > > On 01/06/2019 02:51, Jim Schaad wrote: > > > Ludwig, > > > > > > I have been doing some adaptions of my codebase for dealing with = the > > > MQTT specification. In the process of this, I have identified the > > > following items that I think needs some discussion. They may not = need > > > changes in any documents and maybe should get a new document. > > > > > > 1. The MQTT document is using the content type "application/json" > > > over HTTPS for transporting messages. Does there need to be an > > > "application/ace+json" defined as a media type, but not = necessarily a > > > CBOR media type? I think the answer may be yes, but it could be a = new > > document. > > > > > I would argue that the first draft using such a media type would be = the right > > place to specify it. However I'm not sure using JSON is the right = approach for > > an ACE specification at all, aren't we supposed to cater for the = constrained > > world? > > What is there to prevent us from transporting CBOR over HTTP? >=20 > There would be no reason that one cannot transport CBOR over HTTP. = During the discussions for these drafts Hannes was very explicit that he = wanted to be able to use JSON rather than CBOR with the protocol that = was defined by ACE. This would mean that there needs to be an ability = to use JSON with the ACE framework document. >=20 > I would have no problems with the statement that the MQTT document = would be a good place to define the new media type. >=20 > >=20 > > > 2. If I use a "COSE_Key" confirmation method inside of an > > > application/ace+json message, there is a potential problem and it > > > could be dealt with in a number of different ways. > > > * The JWT confirmation method is identified as "jwk". The COSE = key > > > must be translated into JOSE even if there is no equivalent key in > > > JOSE. I.e. that is a fatal error > > > * This does not make sense and the confirmation method should be > > > changed to "cwk" so that either key format could be used in either > > encoding. > > > > >=20 > > If we use JSON messages mixing in COSE becomes awkward. If the use = case > > calls for JSON, I'd argue it should also use RFC7800 instead of = draft-ietf-ace- > > cwt-proof-of-possession. >=20 > I would not have a problem with this, it was one of the options above. = I was just expanding my code to allow for JSON to be used and ran into = this. I just wanted to get a clear group decision on this before I put = things into stone. >=20 > Jim >=20 > >=20 > > > 3. If the confirmation is changed, you would need to convert the = COSE > > > key to a binary string, base64 encoded it and pass as a string = when > > > occurring in a JSON encoding. There is not any other valid way to = do > > > this (except see above of just converting the key format). = However, > > > the opposite of putting a JOSE key into a COSE confirmation has = three > > > different options that could be used. > > > * Encode the JOSE key to a string and pass as a string > > > * Encode the JOSE key top level map as CBOR but leave all of the > > > elements alone. > > > * Encode the JOSE key in CBOR including conversion of base64 = strings > > > to binary data. > > > (My first preference is probably the second option, but either of = the > > > first two make sense.) > > > > > > Jim > > > > >=20 > > I'm still unsure that there is a good use case for transporting JOSE = keys in > > CBOR, but if such a case turns up, I would agree that touching the = encoding > > as little as possible is a good idea (=3Doption 1 or 2). > >=20 > > /Ludwig > >=20 > > -- > > Ludwig Seitz, PhD > > Security Lab, RISE > > Phone +46(0)70-349 92 51 >=20 >=20 > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace From nobody Wed Oct 2 23:42: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 E37D712088C for ; Wed, 2 Oct 2019 23:42:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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=armh.onmicrosoft.com header.b=laAqgs1H; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=armh.onmicrosoft.com header.b=fTCGpzGX 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 ymxQ9NdtK00D for ; Wed, 2 Oct 2019 23:42:50 -0700 (PDT) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40055.outbound.protection.outlook.com [40.107.4.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5799A12086D for ; Wed, 2 Oct 2019 23:42:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=P1qDGbbI1uS5evjBZImi61Lcg9kjRp0FjxEdXJmuACc=; b=laAqgs1H1r7pmu78gFWZFH7g+yyybyqKefMlRaMd5xu/wyuM8VOW03mk51cC8KxKwCsQXtg3BaAU5WLk88DcMo47oyCgZP7KUOaMRZp919B09WyCcCCaN3zlvz4Hq4prICxGPVrek/0D+en4glRTbIzptPxWAEDpZB9y1K54CoY= Received: from VI1PR08CA0125.eurprd08.prod.outlook.com (2603:10a6:800:d4::27) by AM6PR08MB4517.eurprd08.prod.outlook.com (2603:10a6:20b:73::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2305.20; Thu, 3 Oct 2019 06:42:47 +0000 Received: from AM5EUR03FT039.eop-EUR03.prod.protection.outlook.com (2a01:111:f400:7e08::207) by VI1PR08CA0125.outlook.office365.com (2603:10a6:800:d4::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.2305.15 via Frontend Transport; Thu, 3 Oct 2019 06:42:47 +0000 Authentication-Results: spf=temperror (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; ietf.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;ietf.org; dmarc=none action=none header.from=arm.com; Received-SPF: TempError (protection.outlook.com: error in processing during lookup of arm.com: DNS Timeout) Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by AM5EUR03FT039.mail.protection.outlook.com (10.152.17.185) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.2305.15 via Frontend Transport; Thu, 3 Oct 2019 06:42:45 +0000 Received: ("Tessian outbound 6481c7fa5a3c:v33"); Thu, 03 Oct 2019 06:42:41 +0000 X-CR-MTA-TID: 64aa7808 Received: from 5f36ba469861.1 (ip-172-16-0-2.eu-west-1.compute.internal [104.47.10.55]) by 64aa7808-outbound-1.mta.getcheckrecipient.com id B5447031-C2D9-4DF7-B9D6-E81C5A174FA2.1; Thu, 03 Oct 2019 06:42:36 +0000 Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-db5eur03lp2055.outbound.protection.outlook.com [104.47.10.55]) by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 5f36ba469861.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384); Thu, 03 Oct 2019 06:42:36 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Ob9BLpPDhY/hXY4vCd4eMuZd+8duZ5o6FM83Lb0t0c/UVlCp8DD3ruAw5cdWOn538SZLWYIZlG13MtAZtU14Siie5Tl0YfkYZl6Q7hHA+kngzg0Mfwy6Lvp0zCNiNCaZkhQ7zDhEaxvDjorJf6aFf/KEr/vSJvS1pNVdgGG0Pup0DynGQP9FQaXxQFP7qmjfpSzoytW6eHExne7Z8YfuIrBEpYsxOw8+5LoysKhWASCSjWrm5jk2yYLEyq/AGlc0fTcD2/eSfcc//+hWSe2vEmrzbs1R38lvro+F3R8DBsFC5bLk4QGyTQXTmgV3peXgGCcUjt++tMU1LivwtLWBMw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=yMk4W7VI4JAhQgEAvmRE/XdbNsObe9ctGkAppq8to/A=; b=M6XcOKHXZo+mc+fuQTbzyqpFo54OK61tTjEwCgrVOVym2EcpXrmwKM7aMKROX9c/EtA+Dci3PEwFI8P6XD4ivJjgau7zU2XLuNFDdW4KrO6aUsBD5UU0J7HnS5Z/C/LzPfqgqQtMjmR8s77vqB1PHqODIIrUJs/nUyly/Zo9wesdRILDPevI0BS7eT9LGnzeCJ+s+Z+G+cSsb3vSiknvW9/JpiKg/AaZ2MRUiT6881g0H3MEe7Ik2gcuugd61TNcUG5fpWVWfTipT5tbb76ZAnq3E9kSe0NB3iGYLUBJ901i2U3aHnDhEb+nHFgA90YwqbhbOkjSdHsqRj+eAja/6g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=yMk4W7VI4JAhQgEAvmRE/XdbNsObe9ctGkAppq8to/A=; b=fTCGpzGXF2/xiJEspSpIxxHcTXG8f6RygVTppEOuHVU1+3pSPc8MTiMHH0nFIyNfyEysFwJye7cb9DPsi2QqmYTK62spmmO2b5M38d/9xDf8YSr+n1/YK7PC11xxVoRSB6HDE1usaqFWUaLdbTUfdbrRw7DuhwmUEE0aH3g9tfY= Received: from VI1PR08MB5360.eurprd08.prod.outlook.com (52.133.245.74) by VI1PR08MB3902.eurprd08.prod.outlook.com (20.178.81.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2305.20; Thu, 3 Oct 2019 06:42:33 +0000 Received: from VI1PR08MB5360.eurprd08.prod.outlook.com ([fe80::b003:8767:35c7:e31]) by VI1PR08MB5360.eurprd08.prod.outlook.com ([fe80::b003:8767:35c7:e31%2]) with mapi id 15.20.2305.023; Thu, 3 Oct 2019 06:42:33 +0000 From: Hannes Tschofenig To: Carsten Bormann , Cigdem Sengul CC: Jim Schaad , Ludwig Seitz , "ace@ietf.org" Thread-Topic: [Ace] Transporting different types of cnf objects - CBOR vs JSON Thread-Index: AQHVeRkOjvoJjd1FkE+gdnIwpWcdiKdHUccAgAEmc4A= Date: Thu, 3 Oct 2019 06:42:33 +0000 Message-ID: References: <000201d51814$34a85fc0$9df91f40$@augustcellars.com> <9a0bbcd4-6055-729c-7ca8-205d0a1fd681@ri.se> <010901d51b04$92788a10$b7699e30$@augustcellars.com> <586CDF5F-F0E4-4514-8AB7-AAA383CA23FB@tzi.org> In-Reply-To: <586CDF5F-F0E4-4514-8AB7-AAA383CA23FB@tzi.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ts-tracking-id: 3c4789fb-6203-44b1-9758-08eac2b0cb2f.1 x-checkrecipientchecked: true Authentication-Results-Original: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [195.149.223.101] x-ms-publictraffictype: Email X-MS-Office365-Filtering-Correlation-Id: dbdfabba-9225-41e9-fa48-08d747cce63d X-MS-Office365-Filtering-HT: Tenant X-MS-TrafficTypeDiagnostic: VI1PR08MB3902:|AM6PR08MB4517: X-MS-Exchange-PUrlCount: 1 X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true x-ms-oob-tlc-oobclassifiers: OLM:10000;OLM:10000; x-forefront-prvs: 01792087B6 X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009020)(4636009)(366004)(39860400002)(376002)(136003)(396003)(346002)(13464003)(189003)(199004)(53754006)(102836004)(7736002)(186003)(52536014)(305945005)(99286004)(7696005)(6246003)(26005)(53546011)(6506007)(76176011)(74316002)(316002)(54906003)(110136005)(33656002)(8676002)(81156014)(8936002)(81166006)(4326008)(66476007)(66066001)(66946007)(71190400001)(2906002)(66446008)(64756008)(66556008)(71200400001)(55016002)(486006)(25786009)(86362001)(5660300002)(966005)(6436002)(229853002)(14454004)(76116006)(3846002)(478600001)(6116002)(256004)(14444005)(6306002)(446003)(9686003)(11346002)(476003); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR08MB3902; H:VI1PR08MB5360.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-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: vDv2NjRCar0uLPhwCNLUOlomiyC4mPT/ju+vpbIQsMLeBHZVOcfWIff54RKtWThF7f65a6XmePyI4zAG/C0EEJG4+kup8qwxoMioj5h9nt2FH/oFNggexZLh8THZUx6+ippdbav02L+oQkkkGm91AAwZy+54DJ0qDi5ugcDzMXKQ019Nr9EBj9fsYKk5RMsIdfWz2hzWainYAZXHqH2RZlz9mtdOp6K1vw6ELQcfrB3bvfloamhkqv9hQytXuZxRP/YHkS67vjbVz5LfHQyFM6SxbnCNTCNEIXuMQWk6YicI/bQ+lE8N+cL52RRHMyom5BX6x1JAXVmjY/8705LxbeOGAEEDIb1t3jB/mA+e1myl2gdOeMg0I4nqrviB4imdKRADrt+tlTjx071UBHYP4EXjSraau1eNusfxVLZMVheH4tnidl3XA1g4egG3OyLoPdTMKqMyAehcOYBiAf534A== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR08MB3902 Original-Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: AM5EUR03FT039.eop-EUR03.prod.protection.outlook.com X-Forefront-Antispam-Report: CIP:63.35.35.123; IPV:CAL; SCL:-1; CTRY:IE; EFV:NLI; SFV:NSPM; SFS:(10009020)(4636009)(396003)(39860400002)(376002)(346002)(136003)(40434004)(13464003)(189003)(199004)(53754006)(99286004)(50466002)(126002)(476003)(486006)(33656002)(66066001)(4326008)(6246003)(47776003)(26826003)(478600001)(74316002)(336012)(26005)(55016002)(6306002)(186003)(305945005)(7736002)(81156014)(8676002)(81166006)(8936002)(25786009)(9686003)(5660300002)(63350400001)(436003)(23676004)(446003)(2486003)(229853002)(52536014)(11346002)(7696005)(53546011)(6506007)(102836004)(86362001)(356004)(76176011)(54906003)(6116002)(22756006)(3846002)(110136005)(14454004)(316002)(36906005)(966005)(70206006)(70586007)(2906002)(76130400001)(5024004)(14444005); DIR:OUT; SFP:1101; SCL:1; SRVR:AM6PR08MB4517; H:64aa7808-outbound-1.mta.getcheckrecipient.com; FPR:; SPF:TempError; LANG:en; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; MX:1; A:1; X-MS-Office365-Filtering-Correlation-Id-Prvs: bdf07ca9-24fa-47a5-7ac8-08d747ccdf21 X-Forefront-PRVS: 01792087B6 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: Wx1MJYHJx81wDQiHIFDeo+GihIPVOJC5ScDS1MEGzZHMclJbureaD31YU7rHsG6428zLNEiv9auldRCsWtLKO1UX0pKN+pWMj9m7UKQlf/h1x2+KeR7v1tJ4Eb1sjHmAN+nfJnDIVc4mM9pOfPMPbr0mkPhzCOBNQukVB6YjPyrR7bae+A4qV4MuEV2t+LzGkD56GCOWeAS/0Acs5o8/VNwRV5VIw08y/UW57flzRwBAXvEvJP71zvcBZXP2GrZNlHOE0yNZSSZEWJ0MvXXg/pdy7yVmU76uTM2jz0qZpUrCXyJm0v1MgCZ/vkrnOO+Ti0bO/NuZ5eztP0JdKC9EEGrAK070+tCxLyVLw1JKG4wgSuOoniaeSmdy9TsNqnqz9CnPNDHaGKQzLnruxcKENuTGfkAMxQ66I+pYox6enlbJ41WsGdxAp6j+8MUxR7nxlaBioMkXhNYRqc68XmfyWg== X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Oct 2019 06:42:45.6705 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: dbdfabba-9225-41e9-fa48-08d747cce63d X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB4517 Archived-At: Subject: Re: [Ace] Transporting different types of cnf objects - CBOR vs JSON 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 Oct 2019 06:42:54 -0000 VGhlcmUgaXMgdW5mb3J0dW5hdGVseSBhIHByb2JsZW0uDQoNCldpdGggcHJvb2Ytb2YtcG9zc2Vz c2lvbiBrZXlzIHRoZXJlIGlzIG1vcmUgdGhhbiBqdXN0IGNvbnZleWluZyB0aGUgQ1dUL0pXVCBv dmVyIGFub3RoZXIgdHJhbnNwb3J0Lg0KSW4gdGhlIFBLLWNhc2UsIHRoZSBjbGllbnQgaGFzIHRv IHByb3ZpZGUgdGhlIHB1YmxpYyBrZXkgdG8gdGhlIHNlcnZlciBhbmQgZ2V0IGl0IGJvdW5kIHRv IHRoZSBQb1AgdG9rZW4uDQpJbiB0aGUgc3ltbWV0cmljIGtleSBjYXNlLCB0aGUgc2VydmVyIGhh cyB0byBwcm92aWRlIHRoZSB0b2tlbiBhbG9uZyB3aXRoIHRoZSBzeW1tZXRyaWMga2V5IHRoYXQg aXMgYWxzbyBpbmNsdWRlZCBhbHRob3VnaCBlbmNyeXB0ZWQpIGluIHRoZSBQb1AgdG9rZW4uDQoN CldlIGhhdmUgc3RhbmRhcmRpemVkIHRoZSB0cmFuc3BvcnQgb2YgdGhpcyBhZGRpdGlvbmFsIGlu Zm9ybWF0aW9uIGluIEFDRSBmb3IgdXNlIHdpdGggQ29BUCBidXQgZm9yIEhUVFAgd2UgZGVjaWRl ZCB0byBkbyB0aGUgd29yayBvbiBPQXV0aCwgd2hlcmUgaXQgZ290IHN0dWNrIGJlY2F1c2UgdGhl IElvVC1pbnRlcmVzdGVkIHBlb3BsZSBhcmUgbm90IHRoZXJlIGFuZCB0aGUgV2ViIGZvbGtzIHdh bnQgc29tZXRoaW5nIGVsc2UuDQoNCkNpYW8NCkhhbm5lcw0KDQotLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KRnJvbTogQWNlIDxhY2UtYm91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIENh cnN0ZW4gQm9ybWFubg0KU2VudDogTWl0dHdvY2gsIDIuIE9rdG9iZXIgMjAxOSAxNTowNQ0KVG86 IENpZ2RlbSBTZW5ndWwgPGNpZ2RlbS5zZW5ndWxAZ21haWwuY29tPg0KQ2M6IEppbSBTY2hhYWQg PGlldGZAYXVndXN0Y2VsbGFycy5jb20+OyBMdWR3aWcgU2VpdHogPGx1ZHdpZy5zZWl0ekByaS5z ZT47IGFjZUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtBY2VdIFRyYW5zcG9ydGluZyBkaWZmZXJl bnQgdHlwZXMgb2YgY25mIG9iamVjdHMgLSBDQk9SIHZzIEpTT04NCg0KVGhlcmUgaXMgbm8gc3Ry b25nIGludGVyZGVwZW5kZW5jeSBiZXR3ZWVuIFdlYiB0cmFuc2ZlciBwcm90b2NvbCAoSFRUUFMv Q29BUFMpIGFuZCBkYXRhIGZvcm1hdC4NCkNPU0Ugd29ya3MgZ3JlYXQgb3ZlciBIVFRQUywgYW5k IGlmIGl0IG11c3QgYmUsIHlvdSBjYW4gc2hpcCBKT1NFIG92ZXIgQ29BUFMuDQoNCkdyw7zDn2Us IENhcnN0ZW4NCg0KDQo+IE9uIE9jdCAyLCAyMDE5LCBhdCAxNDowMCwgQ2lnZGVtIFNlbmd1bCA8 Y2lnZGVtLnNlbmd1bEBnbWFpbC5jb20+IHdyb3RlOg0KPg0KPiBIZWxsbyBhbGwsDQo+DQo+IEkg YW0gdHJ5aW5nIHRvIGltcGxlbWVudCB0aGlzIGRpc2N1c3Npb24gaW4gdGhlIGRyYWZ0LiAgQSBw b2ludCBpcyByYWlzZWQgYWJvdXQgQ09TRSBrZXlzIGluIEpTT04gbWVzc2FnZXMuDQo+IENvdWxk IGl0IGJlIHBvc3NpYmxlIHRvIGdvIHdpdGg6DQo+ICgxKSBIVFRQUyAtIGFwcGxpY2F0aW9uL2Fj ZStqc29uIC0gand0IC0gam9zZSAtIFBvUCBmb3IgSldUIG9yDQo+ICgyKSBDb0FQIC0gYXBwbGlj YXRpb24vYWNlK2Nib3IgLSBjd3QgLSBjb3NlIC0gUG9QIGZvciBDV1Qgd2l0aG91dA0KPiBtaXhp bmcgYW55dGhpbmc/DQo+DQo+ICgxKSB3ZSB0aG91Z2h0IHRvIGRlc2NyaWJlIGJ5IGRlZmF1bHQg aW4gdGhlIGRvY3VtZW50LCBhbmQgKDIpIHdlIHNhaWQgTUFZIGJlIHN1cHBvcnRlZC4NCj4gSXMg dGhlcmUgYSBwcm9ibGVtIHdpdGggdGhpcyBhcHByb2FjaD8NCj4NCj4gVGhhbmtzLA0KPiAtLUNp Z2RlbQ0KPg0KPg0KPiBPbiBUdWUsIEp1biA0LCAyMDE5IGF0IDk6MjkgUE0gQ2lnZGVtIFNlbmd1 bCA8Y2lnZGVtLnNlbmd1bEBnbWFpbC5jb20+IHdyb3RlOg0KPiBIZWxsbywNCj4gWWVzLCB3ZSB0 aG91Z2h0IHN1cHBvcnRpbmcgSlNPTiBvcHRpb24gd291bGQgYmUgZ29vZCwgdGhvdWdoIGluZGVl ZCB0aGVyZSBpcyBubyBpc3N1ZSB3aXRoIHRyYW5zcG9ydGluZyBDQk9SLi4NCj4gSWYgdGhlcmUg YXJlIG5vIG90aGVyIGNvbmNlcm5zLCB3ZSBjYW4gZGVmaW5lIHRoZSBuZXcgbWVkaWEgdHlwZSBp biB0aGUgTVFUVCBkcmFmdC4NCj4gV2lsbCBhZGQgdGhlIGlzc3VlIHRvIEdpdEh1YiByZXBvLg0K Pg0KPiAtLUNpZ2RlbQ0KPg0KPiBPbiBUdWUsIEp1biA0LCAyMDE5IGF0IDc6MzcgUE0gSmltIFNj aGFhZCA8aWV0ZkBhdWd1c3RjZWxsYXJzLmNvbT4gd3JvdGU6DQo+DQo+DQo+ID4gLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCj4gPiBGcm9tOiBBY2UgPGFjZS1ib3VuY2VzQGlldGYub3JnPiBP biBCZWhhbGYgT2YgTHVkd2lnIFNlaXR6DQo+ID4gU2VudDogTW9uZGF5LCBKdW5lIDMsIDIwMTkg MTE6NTEgUE0NCj4gPiBUbzogYWNlQGlldGYub3JnDQo+ID4gU3ViamVjdDogUmU6IFtBY2VdIFRy YW5zcG9ydGluZyBkaWZmZXJlbnQgdHlwZXMgb2YgY25mIG9iamVjdHMgLQ0KPiA+IENCT1IgdnMg SlNPTg0KPiA+DQo+ID4gT24gMDEvMDYvMjAxOSAwMjo1MSwgSmltIFNjaGFhZCB3cm90ZToNCj4g PiA+IEx1ZHdpZywNCj4gPiA+DQo+ID4gPiBJIGhhdmUgYmVlbiBkb2luZyBzb21lIGFkYXB0aW9u cyBvZiBteSBjb2RlYmFzZSBmb3IgZGVhbGluZyB3aXRoDQo+ID4gPiB0aGUgTVFUVCBzcGVjaWZp Y2F0aW9uLiAgSW4gdGhlIHByb2Nlc3Mgb2YgdGhpcywgSSBoYXZlIGlkZW50aWZpZWQNCj4gPiA+ IHRoZSBmb2xsb3dpbmcgaXRlbXMgdGhhdCBJIHRoaW5rIG5lZWRzIHNvbWUgZGlzY3Vzc2lvbi4g IFRoZXkgbWF5DQo+ID4gPiBub3QgbmVlZCBjaGFuZ2VzIGluIGFueSBkb2N1bWVudHMgYW5kIG1h eWJlIHNob3VsZCBnZXQgYSBuZXcgZG9jdW1lbnQuDQo+ID4gPg0KPiA+ID4gMS4gIFRoZSBNUVRU IGRvY3VtZW50IGlzIHVzaW5nIHRoZSBjb250ZW50IHR5cGUgImFwcGxpY2F0aW9uL2pzb24iDQo+ ID4gPiBvdmVyIEhUVFBTIGZvciB0cmFuc3BvcnRpbmcgbWVzc2FnZXMuICBEb2VzIHRoZXJlIG5l ZWQgdG8gYmUgYW4NCj4gPiA+ICJhcHBsaWNhdGlvbi9hY2UranNvbiIgZGVmaW5lZCBhcyBhIG1l ZGlhIHR5cGUsIGJ1dCBub3QNCj4gPiA+IG5lY2Vzc2FyaWx5IGEgQ0JPUiBtZWRpYSB0eXBlPyAg SSB0aGluayB0aGUgYW5zd2VyIG1heSBiZSB5ZXMsIGJ1dA0KPiA+ID4gaXQgY291bGQgYmUgYSBu ZXcNCj4gPiBkb2N1bWVudC4NCj4gPiA+DQo+ID4gSSB3b3VsZCBhcmd1ZSB0aGF0IHRoZSBmaXJz dCBkcmFmdCB1c2luZyBzdWNoIGEgbWVkaWEgdHlwZSB3b3VsZCBiZQ0KPiA+IHRoZSByaWdodCBw bGFjZSB0byBzcGVjaWZ5IGl0LiBIb3dldmVyIEknbSBub3Qgc3VyZSB1c2luZyBKU09OIGlzDQo+ ID4gdGhlIHJpZ2h0IGFwcHJvYWNoIGZvciBhbiBBQ0Ugc3BlY2lmaWNhdGlvbiBhdCBhbGwsIGFy ZW4ndCB3ZQ0KPiA+IHN1cHBvc2VkIHRvIGNhdGVyIGZvciB0aGUgY29uc3RyYWluZWQgd29ybGQ/ DQo+ID4gV2hhdCBpcyB0aGVyZSB0byBwcmV2ZW50IHVzIGZyb20gdHJhbnNwb3J0aW5nIENCT1Ig b3ZlciBIVFRQPw0KPg0KPiBUaGVyZSB3b3VsZCBiZSBubyByZWFzb24gdGhhdCBvbmUgY2Fubm90 IHRyYW5zcG9ydCBDQk9SIG92ZXIgSFRUUC4gIER1cmluZyB0aGUgZGlzY3Vzc2lvbnMgZm9yIHRo ZXNlIGRyYWZ0cyBIYW5uZXMgd2FzIHZlcnkgZXhwbGljaXQgdGhhdCBoZSB3YW50ZWQgdG8gYmUg YWJsZSB0byB1c2UgSlNPTiByYXRoZXIgdGhhbiBDQk9SIHdpdGggdGhlIHByb3RvY29sIHRoYXQg d2FzIGRlZmluZWQgYnkgQUNFLiAgVGhpcyB3b3VsZCBtZWFuIHRoYXQgdGhlcmUgbmVlZHMgdG8g YmUgYW4gYWJpbGl0eSB0byB1c2UgSlNPTiB3aXRoIHRoZSBBQ0UgZnJhbWV3b3JrIGRvY3VtZW50 Lg0KPg0KPiBJIHdvdWxkIGhhdmUgbm8gcHJvYmxlbXMgd2l0aCB0aGUgc3RhdGVtZW50IHRoYXQg dGhlIE1RVFQgZG9jdW1lbnQgd291bGQgYmUgYSBnb29kIHBsYWNlIHRvIGRlZmluZSB0aGUgbmV3 IG1lZGlhIHR5cGUuDQo+DQo+ID4NCj4gPiA+IDIuICBJZiBJIHVzZSBhICJDT1NFX0tleSIgY29u ZmlybWF0aW9uIG1ldGhvZCBpbnNpZGUgb2YgYW4NCj4gPiA+IGFwcGxpY2F0aW9uL2FjZStqc29u IG1lc3NhZ2UsIHRoZXJlIGlzIGEgcG90ZW50aWFsIHByb2JsZW0gYW5kIGl0DQo+ID4gPiBjb3Vs ZCBiZSBkZWFsdCB3aXRoIGluIGEgbnVtYmVyIG9mIGRpZmZlcmVudCB3YXlzLg0KPiA+ID4gKiAg VGhlIEpXVCBjb25maXJtYXRpb24gbWV0aG9kIGlzIGlkZW50aWZpZWQgYXMgImp3ayIuICBUaGUg Q09TRQ0KPiA+ID4ga2V5IG11c3QgYmUgdHJhbnNsYXRlZCBpbnRvIEpPU0UgZXZlbiBpZiB0aGVy ZSBpcyBubyBlcXVpdmFsZW50DQo+ID4gPiBrZXkgaW4gSk9TRS4gIEkuZS4gdGhhdCBpcyBhIGZh dGFsIGVycm9yDQo+ID4gPiAqICBUaGlzIGRvZXMgbm90IG1ha2Ugc2Vuc2UgYW5kIHRoZSBjb25m aXJtYXRpb24gbWV0aG9kIHNob3VsZCBiZQ0KPiA+ID4gY2hhbmdlZCB0byAiY3drIiBzbyB0aGF0 IGVpdGhlciBrZXkgZm9ybWF0IGNvdWxkIGJlIHVzZWQgaW4gZWl0aGVyDQo+ID4gZW5jb2Rpbmcu DQo+ID4gPg0KPiA+DQo+ID4gSWYgd2UgdXNlIEpTT04gbWVzc2FnZXMgbWl4aW5nIGluIENPU0Ug YmVjb21lcyBhd2t3YXJkLiBJZiB0aGUgdXNlDQo+ID4gY2FzZSBjYWxscyBmb3IgSlNPTiwgSSdk IGFyZ3VlIGl0IHNob3VsZCBhbHNvIHVzZSBSRkM3ODAwIGluc3RlYWQgb2YNCj4gPiBkcmFmdC1p ZXRmLWFjZS0gY3d0LXByb29mLW9mLXBvc3Nlc3Npb24uDQo+DQo+IEkgd291bGQgbm90IGhhdmUg YSBwcm9ibGVtIHdpdGggdGhpcywgaXQgd2FzIG9uZSBvZiB0aGUgb3B0aW9ucyBhYm92ZS4gIEkg d2FzIGp1c3QgZXhwYW5kaW5nIG15IGNvZGUgdG8gYWxsb3cgZm9yIEpTT04gdG8gYmUgdXNlZCBh bmQgcmFuIGludG8gdGhpcy4gIEkganVzdCB3YW50ZWQgdG8gZ2V0IGEgY2xlYXIgZ3JvdXAgZGVj aXNpb24gb24gdGhpcyBiZWZvcmUgSSBwdXQgdGhpbmdzIGludG8gc3RvbmUuDQo+DQo+IEppbQ0K Pg0KPiA+DQo+ID4gPiAzLiAgSWYgdGhlIGNvbmZpcm1hdGlvbiBpcyBjaGFuZ2VkLCB5b3Ugd291 bGQgbmVlZCB0byBjb252ZXJ0IHRoZQ0KPiA+ID4gQ09TRSBrZXkgdG8gYSBiaW5hcnkgc3RyaW5n LCBiYXNlNjQgZW5jb2RlZCBpdCBhbmQgcGFzcyBhcyBhDQo+ID4gPiBzdHJpbmcgd2hlbiBvY2N1 cnJpbmcgaW4gYSBKU09OIGVuY29kaW5nLiAgVGhlcmUgaXMgbm90IGFueSBvdGhlcg0KPiA+ID4g dmFsaWQgd2F5IHRvIGRvIHRoaXMgKGV4Y2VwdCBzZWUgYWJvdmUgb2YganVzdCBjb252ZXJ0aW5n IHRoZSBrZXkNCj4gPiA+IGZvcm1hdCkuICBIb3dldmVyLCB0aGUgb3Bwb3NpdGUgb2YgcHV0dGlu ZyBhIEpPU0Uga2V5IGludG8gYSBDT1NFDQo+ID4gPiBjb25maXJtYXRpb24gaGFzIHRocmVlIGRp ZmZlcmVudCBvcHRpb25zIHRoYXQgY291bGQgYmUgdXNlZC4NCj4gPiA+ICogIEVuY29kZSB0aGUg Sk9TRSBrZXkgdG8gYSBzdHJpbmcgYW5kIHBhc3MgYXMgYSBzdHJpbmcNCj4gPiA+ICogIEVuY29k ZSB0aGUgSk9TRSBrZXkgdG9wIGxldmVsIG1hcCBhcyBDQk9SIGJ1dCBsZWF2ZSBhbGwgb2YgdGhl DQo+ID4gPiBlbGVtZW50cyBhbG9uZS4NCj4gPiA+ICogIEVuY29kZSB0aGUgSk9TRSBrZXkgaW4g Q0JPUiBpbmNsdWRpbmcgY29udmVyc2lvbiBvZiBiYXNlNjQNCj4gPiA+IHN0cmluZ3MgdG8gYmlu YXJ5IGRhdGEuDQo+ID4gPiAoTXkgZmlyc3QgcHJlZmVyZW5jZSBpcyBwcm9iYWJseSB0aGUgc2Vj b25kIG9wdGlvbiwgYnV0IGVpdGhlciBvZg0KPiA+ID4gdGhlIGZpcnN0IHR3byBtYWtlIHNlbnNl LikNCj4gPiA+DQo+ID4gPiBKaW0NCj4gPiA+DQo+ID4NCj4gPiBJJ20gc3RpbGwgdW5zdXJlIHRo YXQgdGhlcmUgaXMgYSBnb29kIHVzZSBjYXNlIGZvciB0cmFuc3BvcnRpbmcgSk9TRQ0KPiA+IGtl eXMgaW4gQ0JPUiwgYnV0IGlmIHN1Y2ggYSBjYXNlIHR1cm5zIHVwLCBJIHdvdWxkIGFncmVlIHRo YXQNCj4gPiB0b3VjaGluZyB0aGUgZW5jb2RpbmcgYXMgbGl0dGxlIGFzIHBvc3NpYmxlIGlzIGEg Z29vZCBpZGVhICg9b3B0aW9uIDEgb3IgMikuDQo+ID4NCj4gPiAvTHVkd2lnDQo+ID4NCj4gPiAt LQ0KPiA+IEx1ZHdpZyBTZWl0eiwgUGhEDQo+ID4gU2VjdXJpdHkgTGFiLCBSSVNFDQo+ID4gUGhv bmUgKzQ2KDApNzAtMzQ5IDkyIDUxDQo+DQo+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+IEFjZSBtYWlsaW5nIGxpc3QNCj4gQWNlQGlldGYub3Jn DQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYWNlDQo+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IEFjZSBtYWlsaW5nIGxp c3QNCj4gQWNlQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vYWNlDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQpBY2UgbWFpbGluZyBsaXN0DQpBY2VAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vYWNlDQpJTVBPUlRBTlQgTk9USUNFOiBUaGUgY29udGVudHMgb2YgdGhp cyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBjb25maWRlbnRpYWwgYW5kIG1heSBhbHNv IGJlIHByaXZpbGVnZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBs ZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBhbmQgZG8gbm90IGRpc2Nsb3NlIHRo ZSBjb250ZW50cyB0byBhbnkgb3RoZXIgcGVyc29uLCB1c2UgaXQgZm9yIGFueSBwdXJwb3NlLCBv ciBzdG9yZSBvciBjb3B5IHRoZSBpbmZvcm1hdGlvbiBpbiBhbnkgbWVkaXVtLiBUaGFuayB5b3Uu DQo= From nobody Thu Oct 3 03:37:24 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 37A38120091 for ; Thu, 3 Oct 2019 03:37:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 hTojvaH0_mig for ; Thu, 3 Oct 2019 03:37:19 -0700 (PDT) Received: from mail-qt1-x82c.google.com (mail-qt1-x82c.google.com [IPv6:2607:f8b0:4864:20::82c]) (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 BD5CA12011A for ; Thu, 3 Oct 2019 03:37:18 -0700 (PDT) Received: by mail-qt1-x82c.google.com with SMTP id c3so2807674qtv.10 for ; Thu, 03 Oct 2019 03:37:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=bnhhtotB02HFwB96dGuxSLl3adp8jk0br/nf73Yxd5I=; b=e1QZ0SI+3grKonUpPyImA813JgjJeYHSKqKcuTo3Je2J5ANqLHpTkKZBDKDChaXwBs mUvkX3GbVkPp6UrWZoT4kmDTqw7hmZTxtQX3tloTqqqkvxSck/LGmp9bN6vnU6VdUkRx BfNRCAzs8p7rC+2yEkCad6bVsZvjwE4lh7HdhZU6cO1d35W/GEH3stImYf1W3eGhyaNp SZaEVdwWvqPaAm3JyvdUS2nqICwGyyJ8YLaHg3kghOJ48XumyDbX9kYPkEED7OqnvjM/ Bf+w3wiAt8UagkhX+lgw9/qZT3Tq6rWBuhbp2CF1ai2J4G/DqZjRZFVVyfknpLuxuBfo BaUA== 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=bnhhtotB02HFwB96dGuxSLl3adp8jk0br/nf73Yxd5I=; b=tcyKk2yP8AEJahnHKEWDh1lqO6r06ZDrVmBnBfqp/+LIryjTnWlCABi5IRsmVzj7zM 6p+4MYTzpyHuajpl7Kqy/UbfaAHKZvWFRoYJIccKcjnNj4QOyX/VPZESc/BphjZgwaJ7 x89hmW5O61/YfsEQ1BpcPEQoKTq3Tz8HEeu0LBWntCL43RAl3iWf30cP0uTDRga2QiYs vTSpOx2jJ23OFSe1jmSyrV/wUClA4gUBpUSJfJcZDYtWuh+xbAXTbWyopKTqFGO4YPif 0hjpkMJusxxTFaMlRMpaecfxdRm90DhTNIzpwvd+J5iHqJ2YcksOrXi+aZLiCgiCihJ+ ksrQ== X-Gm-Message-State: APjAAAVnG8XzeC/WdTxkfEl3JBWHMcZNuBLA+jP66wzdxAHyxoUThAfI XlUOKHk2L4lmXD7sD1mOd4UTjNLyRxuKqKPpryY= X-Google-Smtp-Source: APXvYqwRIesgWBrtgciz6DLz2ndCFOjhWeduES6a0kNw3M/Ipiq3jua5Ah/MmIUNLgrwaNosN88sQ3vBTai/4gb2HHs= X-Received: by 2002:ac8:2af8:: with SMTP id c53mr9438791qta.344.1570099037721; Thu, 03 Oct 2019 03:37:17 -0700 (PDT) MIME-Version: 1.0 References: <000201d51814$34a85fc0$9df91f40$@augustcellars.com> <9a0bbcd4-6055-729c-7ca8-205d0a1fd681@ri.se> <010901d51b04$92788a10$b7699e30$@augustcellars.com> <586CDF5F-F0E4-4514-8AB7-AAA383CA23FB@tzi.org> In-Reply-To: From: Cigdem Sengul Date: Thu, 3 Oct 2019 11:37:06 +0100 Message-ID: To: Hannes Tschofenig Cc: Carsten Bormann , Jim Schaad , Ludwig Seitz , "ace@ietf.org" Content-Type: multipart/alternative; boundary="00000000000067d8ae0593ff2b22" Archived-At: Subject: Re: [Ace] Transporting different types of cnf objects - CBOR vs JSON 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 Oct 2019 10:37:23 -0000 --00000000000067d8ae0593ff2b22 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello, Thank you for your responses. Until this issue is resolved, is it OK just to point to RFC 7800, which says the client provides the symmetric PoP key? For MQTT draft, would like to explain that C-RS is MQTT - MQTT may carry JSON/CBOR encoding for the Data fields in the packets. C-AS and RS-AS can be HTTPS/CoAP/MQTT - what we describe in the draft it is HTTPS; MQTT support needs more thought for request-response style communication. For HTTPS/CoAP, application/ace+json or application/ace+cbor content formats. Since this info is a bit muddled in the current draft, I would like to ensure there is a clear paragraph, which the workgroup would be fine with. Thank you for your help. Sincerely, --Cigdem On Thu, Oct 3, 2019 at 7:42 AM Hannes Tschofenig wrote: > There is unfortunately a problem. > > With proof-of-possession keys there is more than just conveying the > CWT/JWT over another transport. > In the PK-case, the client has to provide the public key to the server an= d > get it bound to the PoP token. > In the symmetric key case, the server has to provide the token along with > the symmetric key that is also included although encrypted) in the PoP > token. > > We have standardized the transport of this additional information in ACE > for use with CoAP but for HTTP we decided to do the work on OAuth, where = it > got stuck because the IoT-interested people are not there and the Web fol= ks > want something else. > > Ciao > Hannes > > -----Original Message----- > From: Ace On Behalf Of Carsten Bormann > Sent: Mittwoch, 2. Oktober 2019 15:05 > To: Cigdem Sengul > Cc: Jim Schaad ; Ludwig Seitz ; > ace@ietf.org > Subject: Re: [Ace] Transporting different types of cnf objects - CBOR vs > JSON > > There is no strong interdependency between Web transfer protocol > (HTTPS/CoAPS) and data format. > COSE works great over HTTPS, and if it must be, you can ship JOSE over > CoAPS. > > Gr=C3=BC=C3=9Fe, Carsten > > > > On Oct 2, 2019, at 14:00, Cigdem Sengul wrote= : > > > > Hello all, > > > > I am trying to implement this discussion in the draft. A point is > raised about COSE keys in JSON messages. > > Could it be possible to go with: > > (1) HTTPS - application/ace+json - jwt - jose - PoP for JWT or > > (2) CoAP - application/ace+cbor - cwt - cose - PoP for CWT without > > mixing anything? > > > > (1) we thought to describe by default in the document, and (2) we said > MAY be supported. > > Is there a problem with this approach? > > > > Thanks, > > --Cigdem > > > > > > On Tue, Jun 4, 2019 at 9:29 PM Cigdem Sengul > wrote: > > Hello, > > Yes, we thought supporting JSON option would be good, though indeed > there is no issue with transporting CBOR.. > > If there are no other concerns, we can define the new media type in the > MQTT draft. > > Will add the issue to GitHub repo. > > > > --Cigdem > > > > On Tue, Jun 4, 2019 at 7:37 PM Jim Schaad > wrote: > > > > > > > -----Original Message----- > > > From: Ace On Behalf Of Ludwig Seitz > > > Sent: Monday, June 3, 2019 11:51 PM > > > To: ace@ietf.org > > > Subject: Re: [Ace] Transporting different types of cnf objects - > > > CBOR vs JSON > > > > > > On 01/06/2019 02:51, Jim Schaad wrote: > > > > Ludwig, > > > > > > > > I have been doing some adaptions of my codebase for dealing with > > > > the MQTT specification. In the process of this, I have identified > > > > the following items that I think needs some discussion. They may > > > > not need changes in any documents and maybe should get a new > document. > > > > > > > > 1. The MQTT document is using the content type "application/json" > > > > over HTTPS for transporting messages. Does there need to be an > > > > "application/ace+json" defined as a media type, but not > > > > necessarily a CBOR media type? I think the answer may be yes, but > > > > it could be a new > > > document. > > > > > > > I would argue that the first draft using such a media type would be > > > the right place to specify it. However I'm not sure using JSON is > > > the right approach for an ACE specification at all, aren't we > > > supposed to cater for the constrained world? > > > What is there to prevent us from transporting CBOR over HTTP? > > > > There would be no reason that one cannot transport CBOR over HTTP. > During the discussions for these drafts Hannes was very explicit that he > wanted to be able to use JSON rather than CBOR with the protocol that was > defined by ACE. This would mean that there needs to be an ability to use > JSON with the ACE framework document. > > > > I would have no problems with the statement that the MQTT document woul= d > be a good place to define the new media type. > > > > > > > > > 2. If I use a "COSE_Key" confirmation method inside of an > > > > application/ace+json message, there is a potential problem and it > > > > could be dealt with in a number of different ways. > > > > * The JWT confirmation method is identified as "jwk". The COSE > > > > key must be translated into JOSE even if there is no equivalent > > > > key in JOSE. I.e. that is a fatal error > > > > * This does not make sense and the confirmation method should be > > > > changed to "cwk" so that either key format could be used in either > > > encoding. > > > > > > > > > > If we use JSON messages mixing in COSE becomes awkward. If the use > > > case calls for JSON, I'd argue it should also use RFC7800 instead of > > > draft-ietf-ace- cwt-proof-of-possession. > > > > I would not have a problem with this, it was one of the options above. > I was just expanding my code to allow for JSON to be used and ran into > this. I just wanted to get a clear group decision on this before I put > things into stone. > > > > Jim > > > > > > > > > 3. If the confirmation is changed, you would need to convert the > > > > COSE key to a binary string, base64 encoded it and pass as a > > > > string when occurring in a JSON encoding. There is not any other > > > > valid way to do this (except see above of just converting the key > > > > format). However, the opposite of putting a JOSE key into a COSE > > > > confirmation has three different options that could be used. > > > > * Encode the JOSE key to a string and pass as a string > > > > * Encode the JOSE key top level map as CBOR but leave all of the > > > > elements alone. > > > > * Encode the JOSE key in CBOR including conversion of base64 > > > > strings to binary data. > > > > (My first preference is probably the second option, but either of > > > > the first two make sense.) > > > > > > > > Jim > > > > > > > > > > I'm still unsure that there is a good use case for transporting JOSE > > > keys in CBOR, but if such a case turns up, I would agree that > > > touching the encoding as little as possible is a good idea (=3Doption= 1 > or 2). > > > > > > /Ludwig > > > > > > -- > > > Ludwig Seitz, PhD > > > Security Lab, RISE > > > Phone +46(0)70-349 92 51 > > > > > > _______________________________________________ > > Ace mailing list > > Ace@ietf.org > > https://www.ietf.org/mailman/listinfo/ace > > _______________________________________________ > > Ace mailing list > > Ace@ietf.org > > https://www.ietf.org/mailman/listinfo/ace > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy th= e > information in any medium. Thank you. > --00000000000067d8ae0593ff2b22 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,

Thank you for your responses.=C2= =A0

Until this issue is resolved, is it OK just to= point to RFC 7800, which says the client provides the symmetric PoP key?

For MQTT draft,=C2=A0 would like to explain that C-= RS is MQTT - MQTT may carry JSON/CBOR encoding for the Data fields in the p= ackets.

C-AS and RS-AS can be HTTPS/CoAP/MQTT - wh= at we describe in the draft it is HTTPS; MQTT support needs more thought fo= r request-response style communication.=C2=A0
For HTTPS/CoAP, app= lication/ace+json or application/ace+cbor content formats.=C2=A0
=
Since this info is a bit muddled in the current draft, I wou= ld like to ensure there is a clear paragraph, which=C2=A0the workgroup woul= d be fine with.=C2=A0

Thank you for your help.=C2= =A0
Sincerely,
--Cigdem=C2=A0

=



On Thu, Oct 3, 2019 at 7:42 AM Hann= es Tschofenig <Hannes.Tscho= fenig@arm.com> wrote:
There is unfortunately a problem.

With proof-of-possession keys there is more than just conveying the CWT/JWT= over another transport.
In the PK-case, the client has to provide the public key to the server and = get it bound to the PoP token.
In the symmetric key case, the server has to provide the token along with t= he symmetric key that is also included although encrypted) in the PoP token= .

We have standardized the transport of this additional information in ACE fo= r use with CoAP but for HTTP we decided to do the work on OAuth, where it g= ot stuck because the IoT-interested people are not there and the Web folks = want something else.

Ciao
Hannes

-----Original Message-----
From: Ace <ace= -bounces@ietf.org> On Behalf Of Carsten Bormann
Sent: Mittwoch, 2. Oktober 2019 15:05
To: Cigdem Sengul <cigdem.sengul@gmail.com>
Cc: Jim Schaad <ietf@augustcellars.com>; Ludwig Seitz <ludwig.seitz@ri.se>; ace@ietf.org
Subject: Re: [Ace] Transporting different types of cnf objects - CBOR vs JS= ON

There is no strong interdependency between Web transfer protocol (HTTPS/CoA= PS) and data format.
COSE works great over HTTPS, and if it must be, you can ship JOSE over CoAP= S.

Gr=C3=BC=C3=9Fe, Carsten


> On Oct 2, 2019, at 14:00, Cigdem Sengul <cigdem.sengul@gmail.com> wrote: >
> Hello all,
>
> I am trying to implement this discussion in the draft.=C2=A0 A point i= s raised about COSE keys in JSON messages.
> Could it be possible to go with:
> (1) HTTPS - application/ace+json - jwt - jose - PoP for JWT or
> (2) CoAP - application/ace+cbor - cwt - cose - PoP for CWT without
> mixing anything?
>
> (1) we thought to describe by default in the document, and (2) we said= MAY be supported.
> Is there a problem with this approach?
>
> Thanks,
> --Cigdem
>
>
> On Tue, Jun 4, 2019 at 9:29 PM Cigdem Sengul <cigdem.sengul@gmail.com> wro= te:
> Hello,
> Yes, we thought supporting JSON option would be good, though indeed th= ere is no issue with transporting CBOR..
> If there are no other concerns, we can define the new media type in th= e MQTT draft.
> Will add the issue to GitHub repo.
>
> --Cigdem
>
> On Tue, Jun 4, 2019 at 7:37 PM Jim Schaad <ietf@augustcellars.com> wrote: >
>
> > -----Original Message-----
> > From: Ace <ace-bounces@ietf.org> On Behalf Of Ludwig Seitz
> > Sent: Monday, June 3, 2019 11:51 PM
> > To: ace@ietf.or= g
> > Subject: Re: [Ace] Transporting different types of cnf objects -<= br> > > CBOR vs JSON
> >
> > On 01/06/2019 02:51, Jim Schaad wrote:
> > > Ludwig,
> > >
> > > I have been doing some adaptions of my codebase for dealing = with
> > > the MQTT specification.=C2=A0 In the process of this, I have= identified
> > > the following items that I think needs some discussion.=C2= =A0 They may
> > > not need changes in any documents and maybe should get a new= document.
> > >
> > > 1.=C2=A0 The MQTT document is using the content type "a= pplication/json"
> > > over HTTPS for transporting messages.=C2=A0 Does there need = to be an
> > > "application/ace+json" defined as a media type, bu= t not
> > > necessarily a CBOR media type?=C2=A0 I think the answer may = be yes, but
> > > it could be a new
> > document.
> > >
> > I would argue that the first draft using such a media type would = be
> > the right place to specify it. However I'm not sure using JSO= N is
> > the right approach for an ACE specification at all, aren't we=
> > supposed to cater for the constrained world?
> > What is there to prevent us from transporting CBOR over HTTP?
>
> There would be no reason that one cannot transport CBOR over HTTP.=C2= =A0 During the discussions for these drafts Hannes was very explicit that h= e wanted to be able to use JSON rather than CBOR with the protocol that was= defined by ACE.=C2=A0 This would mean that there needs to be an ability to= use JSON with the ACE framework document.
>
> I would have no problems with the statement that the MQTT document wou= ld be a good place to define the new media type.
>
> >
> > > 2.=C2=A0 If I use a "COSE_Key" confirmation method= inside of an
> > > application/ace+json message, there is a potential problem a= nd it
> > > could be dealt with in a number of different ways.
> > > *=C2=A0 The JWT confirmation method is identified as "j= wk".=C2=A0 The COSE
> > > key must be translated into JOSE even if there is no equival= ent
> > > key in JOSE.=C2=A0 I.e. that is a fatal error
> > > *=C2=A0 This does not make sense and the confirmation method= should be
> > > changed to "cwk" so that either key format could b= e used in either
> > encoding.
> > >
> >
> > If we use JSON messages mixing in COSE becomes awkward. If the us= e
> > case calls for JSON, I'd argue it should also use RFC7800 ins= tead of
> > draft-ietf-ace- cwt-proof-of-possession.
>
> I would not have a problem with this, it was one of the options above.= =C2=A0 I was just expanding my code to allow for JSON to be used and ran in= to this.=C2=A0 I just wanted to get a clear group decision on this before I= put things into stone.
>
> Jim
>
> >
> > > 3.=C2=A0 If the confirmation is changed, you would need to c= onvert the
> > > COSE key to a binary string, base64 encoded it and pass as a=
> > > string when occurring in a JSON encoding.=C2=A0 There is not= any other
> > > valid way to do this (except see above of just converting th= e key
> > > format).=C2=A0 However, the opposite of putting a JOSE key i= nto a COSE
> > > confirmation has three different options that could be used.=
> > > *=C2=A0 Encode the JOSE key to a string and pass as a string=
> > > *=C2=A0 Encode the JOSE key top level map as CBOR but leave = all of the
> > > elements alone.
> > > *=C2=A0 Encode the JOSE key in CBOR including conversion of = base64
> > > strings to binary data.
> > > (My first preference is probably the second option, but eith= er of
> > > the first two make sense.)
> > >
> > > Jim
> > >
> >
> > I'm still unsure that there is a good use case for transporti= ng JOSE
> > keys in CBOR, but if such a case turns up, I would agree that
> > touching the encoding as little as possible is a good idea (=3Dop= tion 1 or 2).
> >
> > /Ludwig
> >
> > --
> > Ludwig Seitz, PhD
> > Security Lab, RISE
> > Phone +46(0)70-349 92 51
>
>
> _______________________________________________
> Ace mailing list
> Ace@ietf.org
> https://www.ietf.org/mailman/listinfo/ace
> _______________________________________________
> Ace mailing list
> Ace@ietf.org
> https://www.ietf.org/mailman/listinfo/ace

_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
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.
--00000000000067d8ae0593ff2b22-- From nobody Thu Oct 3 03:42:23 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 ED4AB12011C for ; Thu, 3 Oct 2019 03:42:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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=armh.onmicrosoft.com header.b=pSPv3Io/; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=armh.onmicrosoft.com header.b=Yug8caDN 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 MrjeJ7P245y0 for ; Thu, 3 Oct 2019 03:42:17 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-eopbgr150051.outbound.protection.outlook.com [40.107.15.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D130612011A for ; Thu, 3 Oct 2019 03:42:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=WIjAmqei2LsBJjjeSC/YMjaJw4LnQctwsrEmu1mjHvQ=; b=pSPv3Io/diNe6l7vxuCZ53LUDD3SpD6LCF4i5S97xSaNfTM6lZ3erAwBbE1cKb9J/P39f2h3oF0UKCMaMxKXvKNyzuHu4Du9ZblS71buGbhtQNW+3tL7MTqg/iO5BZykjLCARsOb6SS26Dv1sT1r1118+CdFh7aITqp9jFewblg= Received: from VI1PR08CA0183.eurprd08.prod.outlook.com (2603:10a6:800:d2::13) by AM0PR08MB3329.eurprd08.prod.outlook.com (2603:10a6:208:57::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2305.17; Thu, 3 Oct 2019 10:42:12 +0000 Received: from VE1EUR03FT036.eop-EUR03.prod.protection.outlook.com (2a01:111:f400:7e09::205) by VI1PR08CA0183.outlook.office365.com (2603:10a6:800:d2::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.2305.15 via Frontend Transport; Thu, 3 Oct 2019 10:42:12 +0000 Authentication-Results: spf=fail (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; ietf.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;ietf.org; dmarc=none action=none header.from=arm.com; Received-SPF: Fail (protection.outlook.com: domain of arm.com does not designate 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by VE1EUR03FT036.mail.protection.outlook.com (10.152.19.204) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.2305.15 via Frontend Transport; Thu, 3 Oct 2019 10:42:12 +0000 Received: ("Tessian outbound 6481c7fa5a3c:v33"); Thu, 03 Oct 2019 10:42:09 +0000 X-CR-MTA-TID: 64aa7808 Received: from 6dd5d17de1ab.1 (ip-172-16-0-2.eu-west-1.compute.internal [104.47.12.57]) by 64aa7808-outbound-1.mta.getcheckrecipient.com id 40A83501-5A4D-43AF-9E01-C3C0FC09BA92.1; Thu, 03 Oct 2019 10:42:04 +0000 Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-db3eur04lp2057.outbound.protection.outlook.com [104.47.12.57]) by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 6dd5d17de1ab.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Thu, 03 Oct 2019 10:42:04 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=D4Mb+kUinyv/i4Fe2l+Hp2+ALBoA7RqhRYAxQf4yNPBGOz1gQ6wQSlAatyBn+Ufz62USXDD0w6lKCmXQM+SpdZjvHwPpikWITs8Bo5nFpK/4Aj8Ruoakby2Aft2RKVjvt4nV8snISctLiS+4NNOaqImmWDRKR3QYHvTdLL9SoNijyqhtZQJtSfEus77QNEEFcXC5gwp0cIYAkVsi0aBNaS8SygLGvD1rIRRhjNW7BvjFUUI8gda7OwMod/hmtrWbcUJQE22GLifh+Nut1dQsOparImaVOqP2+pBXmYMsudQkE10+wBPWg+O4wWy3nGcaEO5yOrfAC9vgyjQnrSbMnw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9ntaVopMxAeGlRR/HrXrLrxYsRia77mM6GRPLy+B0AY=; b=Pw2T3HySUeq5K56+rLENESm6VW6d0ndnITcamc29pm/C1sBl+kgXWmXUjSx1dHhPsUUHWLOSFPk1rgmAolfPjiRujLoL7ahNbyegtUd6jaat0ucE+8CNGSKU7gQayeR8OsHWp0DejUf9sHyCfN9JcEumkOcaUEMfz4F60hrl1JB+5FMaUw2mQuZHu57STO53uh10iF0hplg2aR1lwsxp/yXSWvK3bOJq8w+xZzMBSj7KlQAb/Qy79lwryTLbvzl9hDl64GRofNBB+MRdubtseuWHrzGZ6xnfjCYkErGWRaUipg3F5+QxGvNT2l+B+PEd3hSaZdPlbnTiLDr6Qff1Hg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9ntaVopMxAeGlRR/HrXrLrxYsRia77mM6GRPLy+B0AY=; b=Yug8caDNh00Olzt8eH8gUyRyAW7+ob0dvHrmSSbnfaGSD0teyLE6wNcp8T0vNV2aya9geJpflGDsK4pbTyYFWbFigmef7sxgO4TMiEg91A0/Ovt34XYZ4M0ImGhlumq2FCm5ObwSPIQViU7z8tTVgzoAC/0ymdq+1phy+qG5Wjo= Received: from VI1PR08MB5360.eurprd08.prod.outlook.com (52.133.245.74) by VI1PR08MB2878.eurprd08.prod.outlook.com (10.170.236.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2305.23; Thu, 3 Oct 2019 10:42:02 +0000 Received: from VI1PR08MB5360.eurprd08.prod.outlook.com ([fe80::b003:8767:35c7:e31]) by VI1PR08MB5360.eurprd08.prod.outlook.com ([fe80::b003:8767:35c7:e31%2]) with mapi id 15.20.2305.023; Thu, 3 Oct 2019 10:42:02 +0000 From: Hannes Tschofenig To: Cigdem Sengul CC: Carsten Bormann , Jim Schaad , Ludwig Seitz , "ace@ietf.org" Thread-Topic: [Ace] Transporting different types of cnf objects - CBOR vs JSON Thread-Index: AQHVeRkOjvoJjd1FkE+gdnIwpWcdiKdHUccAgAEmc4CAAEKUAIAAAM6w Date: Thu, 3 Oct 2019 10:42:02 +0000 Message-ID: References: <000201d51814$34a85fc0$9df91f40$@augustcellars.com> <9a0bbcd4-6055-729c-7ca8-205d0a1fd681@ri.se> <010901d51b04$92788a10$b7699e30$@augustcellars.com> <586CDF5F-F0E4-4514-8AB7-AAA383CA23FB@tzi.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ts-tracking-id: 7423d637-c7d1-4796-9368-6573aa646b8e.1 x-checkrecipientchecked: true Authentication-Results-Original: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [195.149.223.101] x-ms-publictraffictype: Email X-MS-Office365-Filtering-Correlation-Id: 76be5c67-5100-4760-8c7d-08d747ee59ac X-MS-Office365-Filtering-HT: Tenant X-MS-TrafficTypeDiagnostic: VI1PR08MB2878:|AM0PR08MB3329: X-MS-Exchange-PUrlCount: 1 X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true x-ms-oob-tlc-oobclassifiers: OLM:10000;OLM:10000; x-forefront-prvs: 01792087B6 X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009020)(4636009)(346002)(376002)(396003)(366004)(136003)(39860400002)(40434004)(189003)(199004)(40764003)(13464003)(53754006)(14444005)(7736002)(476003)(5024004)(6306002)(256004)(8676002)(81166006)(7696005)(6246003)(478600001)(8936002)(76176011)(966005)(102836004)(26005)(14454004)(4326008)(186003)(6506007)(53546011)(2906002)(54896002)(71200400001)(71190400001)(74316002)(81156014)(52536014)(6116002)(3846002)(790700001)(66066001)(316002)(86362001)(99286004)(6916009)(54906003)(606006)(64756008)(66476007)(33656002)(66946007)(6436002)(229853002)(5660300002)(25786009)(76116006)(66446008)(66556008)(9686003)(236005)(11346002)(446003)(486006)(55016002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR08MB2878; H:VI1PR08MB5360.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-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: sZxezc5MpmJ13AIwlqGaP3U0wi0IpX7aL+NOG+zxyJ1nIIh9fsIqzTYlx6ulqt4C40dmiFVxQg7mtZtRsuMFakYRFlt+HlyKwqd7jfxAht95SWE54ZdQZHrdN93QtMcf1kdDnkdwu6y6QXTCn+bPSd3zLwIh4Cf64cFInHVo83NY+MRsyv25Zc6JRKVmyJR6KIZTGr5QehSfVfonCttxykMRoTD8KonRq+nqt81cvVU4Akl+5aqQH0phn6uXLP99iAnjEIMnVi7QPZaVHtD7RQkeUPVhiRdT2yKijI1kBxxF5+f2pNVOSBo04hgB3IJicF/X5GnTzqF7qxKxc7l2/CLoZUJjDZvVKM2EkR0i6XnZ8bdHbCQe8Ie2oAuU88zX6VuhmjVI1qcykHcEfkDtAZR2oIETqwJs4ZhOEHkhxS2/gW1v/Pn1SDR3cdZe6+b7Op9jr2TUCZK5TsYZiiZ93A== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_VI1PR08MB5360351588B0569244A75FF3FA9F0VI1PR08MB5360eurp_" MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR08MB2878 Original-Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: VE1EUR03FT036.eop-EUR03.prod.protection.outlook.com X-Forefront-Antispam-Report: CIP:63.35.35.123; IPV:CAL; SCL:-1; CTRY:IE; EFV:NLI; SFV:NSPM; SFS:(10009020)(4636009)(39850400004)(396003)(376002)(346002)(136003)(1110001)(339900001)(189003)(199004)(40434004)(13464003)(53754006)(40764003)(2906002)(52536014)(336012)(7736002)(446003)(74316002)(11346002)(26005)(186003)(5660300002)(102836004)(790700001)(126002)(606006)(33964004)(99286004)(30864003)(486006)(476003)(71190400001)(53546011)(6506007)(6116002)(3846002)(6306002)(55016002)(14444005)(5024004)(6246003)(236005)(9686003)(6862004)(54896002)(4326008)(966005)(22756006)(14454004)(229853002)(356004)(316002)(54906003)(66066001)(26826003)(25786009)(478600001)(86362001)(81156014)(36906005)(76176011)(7696005)(81166006)(8676002)(8936002)(33656002)(70206006)(70586007)(76130400001)(16586007); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR08MB3329; H:64aa7808-outbound-1.mta.getcheckrecipient.com; FPR:; SPF:Fail; LANG:en; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; MX:1; A:1; X-MS-Office365-Filtering-Correlation-Id-Prvs: 3a39b7a2-c5ac-4671-1ff8-08d747ee53a2 X-Forefront-PRVS: 01792087B6 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: lQYc68bGCdxypskqoxdzEMzMSDNP55aX5AI3kFJ8VLoUxEdbr6ofcGu7a6AawLH+JRJdPUMYpd5QVcWIWd843YR3g8DJ2bGDUO3Mo4zWrgE3a6lFX0HcoxdzXn7AD/8uSWQclt/mjSh/nJxB0mW0BqpakXvPgILTPirX9lNFGC5TNmCKS5Ui82wCsJT/T7JCeL7BGcvDhKrWfgVTvBkVHZf1RXkdgk9/sV5r2O2dkeIIvHZVu7kAOhwPYfUL++ifJJLV6PqmvBF6F0X4XngHJuk4D3/jvb0Gzmecl+PnGmLxiAhlz2bhR7EbEtuQaL28OhXMYOeoyOkEF0OfDpCwuBxzG7/DsTWabzoVgih2TQNfw9NiWZahMIVHUOFkGKx+sV+kgwo0eGN1flCjCwrUQUqGxU/LhpTaVn3RKmndEqABovWwZVVBq+v24GLO/XItKWRp5G+VSfRxkHe9599P/w== X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Oct 2019 10:42:12.7112 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 76be5c67-5100-4760-8c7d-08d747ee59ac X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR08MB3329 Archived-At: Subject: Re: [Ace] Transporting different types of cnf objects - CBOR vs JSON 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 Oct 2019 10:42:21 -0000 --_000_VI1PR08MB5360351588B0569244A75FF3FA9F0VI1PR08MB5360eurp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBiZWxpZXZlIHRoZSBjdXJyZW50IGFwcHJvYWNoIGlzIGZvciB0aGUgc2VydmVyIHRvIHByb3Zp ZGUgdGhlIHN5bW1ldHJpYyBrZXkgKHJhdGhlciB0aGFuIHRoZSBjbGllbnQpLg0KDQpJIGhhdmUg bm8gaWRlYSB3aGVuIHRoaXMgdG9waWMgZ2V0cyByZXNvbHZlZCBiZWNhdXNlIGZvbGtzIGtlZXAg Y2hhbmdpbmcgdGhlaXIgbWluZCBzbyBxdWlja2x5Lg0KDQpGcm9tOiBDaWdkZW0gU2VuZ3VsIDxj aWdkZW0uc2VuZ3VsQGdtYWlsLmNvbT4NClNlbnQ6IERvbm5lcnN0YWcsIDMuIE9rdG9iZXIgMjAx OSAxMjozNw0KVG86IEhhbm5lcyBUc2Nob2ZlbmlnIDxIYW5uZXMuVHNjaG9mZW5pZ0Bhcm0uY29t Pg0KQ2M6IENhcnN0ZW4gQm9ybWFubiA8Y2Fib0B0emkub3JnPjsgSmltIFNjaGFhZCA8aWV0ZkBh dWd1c3RjZWxsYXJzLmNvbT47IEx1ZHdpZyBTZWl0eiA8bHVkd2lnLnNlaXR6QHJpLnNlPjsgYWNl QGlldGYub3JnDQpTdWJqZWN0OiBSZTogW0FjZV0gVHJhbnNwb3J0aW5nIGRpZmZlcmVudCB0eXBl cyBvZiBjbmYgb2JqZWN0cyAtIENCT1IgdnMgSlNPTg0KDQpIZWxsbywNCg0KVGhhbmsgeW91IGZv ciB5b3VyIHJlc3BvbnNlcy4NCg0KVW50aWwgdGhpcyBpc3N1ZSBpcyByZXNvbHZlZCwgaXMgaXQg T0sganVzdCB0byBwb2ludCB0byBSRkMgNzgwMCwgd2hpY2ggc2F5cyB0aGUgY2xpZW50IHByb3Zp ZGVzIHRoZSBzeW1tZXRyaWMgUG9QIGtleT8NCg0KRm9yIE1RVFQgZHJhZnQsICB3b3VsZCBsaWtl IHRvIGV4cGxhaW4gdGhhdCBDLVJTIGlzIE1RVFQgLSBNUVRUIG1heSBjYXJyeSBKU09OL0NCT1Ig ZW5jb2RpbmcgZm9yIHRoZSBEYXRhIGZpZWxkcyBpbiB0aGUgcGFja2V0cy4NCg0KQy1BUyBhbmQg UlMtQVMgY2FuIGJlIEhUVFBTL0NvQVAvTVFUVCAtIHdoYXQgd2UgZGVzY3JpYmUgaW4gdGhlIGRy YWZ0IGl0IGlzIEhUVFBTOyBNUVRUIHN1cHBvcnQgbmVlZHMgbW9yZSB0aG91Z2h0IGZvciByZXF1 ZXN0LXJlc3BvbnNlIHN0eWxlIGNvbW11bmljYXRpb24uDQpGb3IgSFRUUFMvQ29BUCwgYXBwbGlj YXRpb24vYWNlK2pzb24gb3IgYXBwbGljYXRpb24vYWNlK2Nib3IgY29udGVudCBmb3JtYXRzLg0K DQpTaW5jZSB0aGlzIGluZm8gaXMgYSBiaXQgbXVkZGxlZCBpbiB0aGUgY3VycmVudCBkcmFmdCwg SSB3b3VsZCBsaWtlIHRvIGVuc3VyZSB0aGVyZSBpcyBhIGNsZWFyIHBhcmFncmFwaCwgd2hpY2gg dGhlIHdvcmtncm91cCB3b3VsZCBiZSBmaW5lIHdpdGguDQoNClRoYW5rIHlvdSBmb3IgeW91ciBo ZWxwLg0KU2luY2VyZWx5LA0KLS1DaWdkZW0NCg0KDQoNCg0KDQpPbiBUaHUsIE9jdCAzLCAyMDE5 IGF0IDc6NDIgQU0gSGFubmVzIFRzY2hvZmVuaWcgPEhhbm5lcy5Uc2Nob2ZlbmlnQGFybS5jb208 bWFpbHRvOkhhbm5lcy5Uc2Nob2ZlbmlnQGFybS5jb20+PiB3cm90ZToNClRoZXJlIGlzIHVuZm9y dHVuYXRlbHkgYSBwcm9ibGVtLg0KDQpXaXRoIHByb29mLW9mLXBvc3Nlc3Npb24ga2V5cyB0aGVy ZSBpcyBtb3JlIHRoYW4ganVzdCBjb252ZXlpbmcgdGhlIENXVC9KV1Qgb3ZlciBhbm90aGVyIHRy YW5zcG9ydC4NCkluIHRoZSBQSy1jYXNlLCB0aGUgY2xpZW50IGhhcyB0byBwcm92aWRlIHRoZSBw dWJsaWMga2V5IHRvIHRoZSBzZXJ2ZXIgYW5kIGdldCBpdCBib3VuZCB0byB0aGUgUG9QIHRva2Vu Lg0KSW4gdGhlIHN5bW1ldHJpYyBrZXkgY2FzZSwgdGhlIHNlcnZlciBoYXMgdG8gcHJvdmlkZSB0 aGUgdG9rZW4gYWxvbmcgd2l0aCB0aGUgc3ltbWV0cmljIGtleSB0aGF0IGlzIGFsc28gaW5jbHVk ZWQgYWx0aG91Z2ggZW5jcnlwdGVkKSBpbiB0aGUgUG9QIHRva2VuLg0KDQpXZSBoYXZlIHN0YW5k YXJkaXplZCB0aGUgdHJhbnNwb3J0IG9mIHRoaXMgYWRkaXRpb25hbCBpbmZvcm1hdGlvbiBpbiBB Q0UgZm9yIHVzZSB3aXRoIENvQVAgYnV0IGZvciBIVFRQIHdlIGRlY2lkZWQgdG8gZG8gdGhlIHdv cmsgb24gT0F1dGgsIHdoZXJlIGl0IGdvdCBzdHVjayBiZWNhdXNlIHRoZSBJb1QtaW50ZXJlc3Rl ZCBwZW9wbGUgYXJlIG5vdCB0aGVyZSBhbmQgdGhlIFdlYiBmb2xrcyB3YW50IHNvbWV0aGluZyBl bHNlLg0KDQpDaWFvDQpIYW5uZXMNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206 IEFjZSA8YWNlLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmFjZS1ib3VuY2VzQGlldGYub3JnPj4g T24gQmVoYWxmIE9mIENhcnN0ZW4gQm9ybWFubg0KU2VudDogTWl0dHdvY2gsIDIuIE9rdG9iZXIg MjAxOSAxNTowNQ0KVG86IENpZ2RlbSBTZW5ndWwgPGNpZ2RlbS5zZW5ndWxAZ21haWwuY29tPG1h aWx0bzpjaWdkZW0uc2VuZ3VsQGdtYWlsLmNvbT4+DQpDYzogSmltIFNjaGFhZCA8aWV0ZkBhdWd1 c3RjZWxsYXJzLmNvbTxtYWlsdG86aWV0ZkBhdWd1c3RjZWxsYXJzLmNvbT4+OyBMdWR3aWcgU2Vp dHogPGx1ZHdpZy5zZWl0ekByaS5zZTxtYWlsdG86bHVkd2lnLnNlaXR6QHJpLnNlPj47IGFjZUBp ZXRmLm9yZzxtYWlsdG86YWNlQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtBY2VdIFRyYW5zcG9y dGluZyBkaWZmZXJlbnQgdHlwZXMgb2YgY25mIG9iamVjdHMgLSBDQk9SIHZzIEpTT04NCg0KVGhl cmUgaXMgbm8gc3Ryb25nIGludGVyZGVwZW5kZW5jeSBiZXR3ZWVuIFdlYiB0cmFuc2ZlciBwcm90 b2NvbCAoSFRUUFMvQ29BUFMpIGFuZCBkYXRhIGZvcm1hdC4NCkNPU0Ugd29ya3MgZ3JlYXQgb3Zl ciBIVFRQUywgYW5kIGlmIGl0IG11c3QgYmUsIHlvdSBjYW4gc2hpcCBKT1NFIG92ZXIgQ29BUFMu DQoNCkdyw7zDn2UsIENhcnN0ZW4NCg0KDQo+IE9uIE9jdCAyLCAyMDE5LCBhdCAxNDowMCwgQ2ln ZGVtIFNlbmd1bCA8Y2lnZGVtLnNlbmd1bEBnbWFpbC5jb208bWFpbHRvOmNpZ2RlbS5zZW5ndWxA Z21haWwuY29tPj4gd3JvdGU6DQo+DQo+IEhlbGxvIGFsbCwNCj4NCj4gSSBhbSB0cnlpbmcgdG8g aW1wbGVtZW50IHRoaXMgZGlzY3Vzc2lvbiBpbiB0aGUgZHJhZnQuICBBIHBvaW50IGlzIHJhaXNl ZCBhYm91dCBDT1NFIGtleXMgaW4gSlNPTiBtZXNzYWdlcy4NCj4gQ291bGQgaXQgYmUgcG9zc2li bGUgdG8gZ28gd2l0aDoNCj4gKDEpIEhUVFBTIC0gYXBwbGljYXRpb24vYWNlK2pzb24gLSBqd3Qg LSBqb3NlIC0gUG9QIGZvciBKV1Qgb3INCj4gKDIpIENvQVAgLSBhcHBsaWNhdGlvbi9hY2UrY2Jv ciAtIGN3dCAtIGNvc2UgLSBQb1AgZm9yIENXVCB3aXRob3V0DQo+IG1peGluZyBhbnl0aGluZz8N Cj4NCj4gKDEpIHdlIHRob3VnaHQgdG8gZGVzY3JpYmUgYnkgZGVmYXVsdCBpbiB0aGUgZG9jdW1l bnQsIGFuZCAoMikgd2Ugc2FpZCBNQVkgYmUgc3VwcG9ydGVkLg0KPiBJcyB0aGVyZSBhIHByb2Js ZW0gd2l0aCB0aGlzIGFwcHJvYWNoPw0KPg0KPiBUaGFua3MsDQo+IC0tQ2lnZGVtDQo+DQo+DQo+ IE9uIFR1ZSwgSnVuIDQsIDIwMTkgYXQgOToyOSBQTSBDaWdkZW0gU2VuZ3VsIDxjaWdkZW0uc2Vu Z3VsQGdtYWlsLmNvbTxtYWlsdG86Y2lnZGVtLnNlbmd1bEBnbWFpbC5jb20+PiB3cm90ZToNCj4g SGVsbG8sDQo+IFllcywgd2UgdGhvdWdodCBzdXBwb3J0aW5nIEpTT04gb3B0aW9uIHdvdWxkIGJl IGdvb2QsIHRob3VnaCBpbmRlZWQgdGhlcmUgaXMgbm8gaXNzdWUgd2l0aCB0cmFuc3BvcnRpbmcg Q0JPUi4uDQo+IElmIHRoZXJlIGFyZSBubyBvdGhlciBjb25jZXJucywgd2UgY2FuIGRlZmluZSB0 aGUgbmV3IG1lZGlhIHR5cGUgaW4gdGhlIE1RVFQgZHJhZnQuDQo+IFdpbGwgYWRkIHRoZSBpc3N1 ZSB0byBHaXRIdWIgcmVwby4NCj4NCj4gLS1DaWdkZW0NCj4NCj4gT24gVHVlLCBKdW4gNCwgMjAx OSBhdCA3OjM3IFBNIEppbSBTY2hhYWQgPGlldGZAYXVndXN0Y2VsbGFycy5jb208bWFpbHRvOmll dGZAYXVndXN0Y2VsbGFycy5jb20+PiB3cm90ZToNCj4NCj4NCj4gPiAtLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KPiA+IEZyb206IEFjZSA8YWNlLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmFj ZS1ib3VuY2VzQGlldGYub3JnPj4gT24gQmVoYWxmIE9mIEx1ZHdpZyBTZWl0eg0KPiA+IFNlbnQ6 IE1vbmRheSwgSnVuZSAzLCAyMDE5IDExOjUxIFBNDQo+ID4gVG86IGFjZUBpZXRmLm9yZzxtYWls dG86YWNlQGlldGYub3JnPg0KPiA+IFN1YmplY3Q6IFJlOiBbQWNlXSBUcmFuc3BvcnRpbmcgZGlm ZmVyZW50IHR5cGVzIG9mIGNuZiBvYmplY3RzIC0NCj4gPiBDQk9SIHZzIEpTT04NCj4gPg0KPiA+ IE9uIDAxLzA2LzIwMTkgMDI6NTEsIEppbSBTY2hhYWQgd3JvdGU6DQo+ID4gPiBMdWR3aWcsDQo+ ID4gPg0KPiA+ID4gSSBoYXZlIGJlZW4gZG9pbmcgc29tZSBhZGFwdGlvbnMgb2YgbXkgY29kZWJh c2UgZm9yIGRlYWxpbmcgd2l0aA0KPiA+ID4gdGhlIE1RVFQgc3BlY2lmaWNhdGlvbi4gIEluIHRo ZSBwcm9jZXNzIG9mIHRoaXMsIEkgaGF2ZSBpZGVudGlmaWVkDQo+ID4gPiB0aGUgZm9sbG93aW5n IGl0ZW1zIHRoYXQgSSB0aGluayBuZWVkcyBzb21lIGRpc2N1c3Npb24uICBUaGV5IG1heQ0KPiA+ ID4gbm90IG5lZWQgY2hhbmdlcyBpbiBhbnkgZG9jdW1lbnRzIGFuZCBtYXliZSBzaG91bGQgZ2V0 IGEgbmV3IGRvY3VtZW50Lg0KPiA+ID4NCj4gPiA+IDEuICBUaGUgTVFUVCBkb2N1bWVudCBpcyB1 c2luZyB0aGUgY29udGVudCB0eXBlICJhcHBsaWNhdGlvbi9qc29uIg0KPiA+ID4gb3ZlciBIVFRQ UyBmb3IgdHJhbnNwb3J0aW5nIG1lc3NhZ2VzLiAgRG9lcyB0aGVyZSBuZWVkIHRvIGJlIGFuDQo+ ID4gPiAiYXBwbGljYXRpb24vYWNlK2pzb24iIGRlZmluZWQgYXMgYSBtZWRpYSB0eXBlLCBidXQg bm90DQo+ID4gPiBuZWNlc3NhcmlseSBhIENCT1IgbWVkaWEgdHlwZT8gIEkgdGhpbmsgdGhlIGFu c3dlciBtYXkgYmUgeWVzLCBidXQNCj4gPiA+IGl0IGNvdWxkIGJlIGEgbmV3DQo+ID4gZG9jdW1l bnQuDQo+ID4gPg0KPiA+IEkgd291bGQgYXJndWUgdGhhdCB0aGUgZmlyc3QgZHJhZnQgdXNpbmcg c3VjaCBhIG1lZGlhIHR5cGUgd291bGQgYmUNCj4gPiB0aGUgcmlnaHQgcGxhY2UgdG8gc3BlY2lm eSBpdC4gSG93ZXZlciBJJ20gbm90IHN1cmUgdXNpbmcgSlNPTiBpcw0KPiA+IHRoZSByaWdodCBh cHByb2FjaCBmb3IgYW4gQUNFIHNwZWNpZmljYXRpb24gYXQgYWxsLCBhcmVuJ3Qgd2UNCj4gPiBz dXBwb3NlZCB0byBjYXRlciBmb3IgdGhlIGNvbnN0cmFpbmVkIHdvcmxkPw0KPiA+IFdoYXQgaXMg dGhlcmUgdG8gcHJldmVudCB1cyBmcm9tIHRyYW5zcG9ydGluZyBDQk9SIG92ZXIgSFRUUD8NCj4N Cj4gVGhlcmUgd291bGQgYmUgbm8gcmVhc29uIHRoYXQgb25lIGNhbm5vdCB0cmFuc3BvcnQgQ0JP UiBvdmVyIEhUVFAuICBEdXJpbmcgdGhlIGRpc2N1c3Npb25zIGZvciB0aGVzZSBkcmFmdHMgSGFu bmVzIHdhcyB2ZXJ5IGV4cGxpY2l0IHRoYXQgaGUgd2FudGVkIHRvIGJlIGFibGUgdG8gdXNlIEpT T04gcmF0aGVyIHRoYW4gQ0JPUiB3aXRoIHRoZSBwcm90b2NvbCB0aGF0IHdhcyBkZWZpbmVkIGJ5 IEFDRS4gIFRoaXMgd291bGQgbWVhbiB0aGF0IHRoZXJlIG5lZWRzIHRvIGJlIGFuIGFiaWxpdHkg dG8gdXNlIEpTT04gd2l0aCB0aGUgQUNFIGZyYW1ld29yayBkb2N1bWVudC4NCj4NCj4gSSB3b3Vs ZCBoYXZlIG5vIHByb2JsZW1zIHdpdGggdGhlIHN0YXRlbWVudCB0aGF0IHRoZSBNUVRUIGRvY3Vt ZW50IHdvdWxkIGJlIGEgZ29vZCBwbGFjZSB0byBkZWZpbmUgdGhlIG5ldyBtZWRpYSB0eXBlLg0K Pg0KPiA+DQo+ID4gPiAyLiAgSWYgSSB1c2UgYSAiQ09TRV9LZXkiIGNvbmZpcm1hdGlvbiBtZXRo b2QgaW5zaWRlIG9mIGFuDQo+ID4gPiBhcHBsaWNhdGlvbi9hY2UranNvbiBtZXNzYWdlLCB0aGVy ZSBpcyBhIHBvdGVudGlhbCBwcm9ibGVtIGFuZCBpdA0KPiA+ID4gY291bGQgYmUgZGVhbHQgd2l0 aCBpbiBhIG51bWJlciBvZiBkaWZmZXJlbnQgd2F5cy4NCj4gPiA+ICogIFRoZSBKV1QgY29uZmly bWF0aW9uIG1ldGhvZCBpcyBpZGVudGlmaWVkIGFzICJqd2siLiAgVGhlIENPU0UNCj4gPiA+IGtl eSBtdXN0IGJlIHRyYW5zbGF0ZWQgaW50byBKT1NFIGV2ZW4gaWYgdGhlcmUgaXMgbm8gZXF1aXZh bGVudA0KPiA+ID4ga2V5IGluIEpPU0UuICBJLmUuIHRoYXQgaXMgYSBmYXRhbCBlcnJvcg0KPiA+ ID4gKiAgVGhpcyBkb2VzIG5vdCBtYWtlIHNlbnNlIGFuZCB0aGUgY29uZmlybWF0aW9uIG1ldGhv ZCBzaG91bGQgYmUNCj4gPiA+IGNoYW5nZWQgdG8gImN3ayIgc28gdGhhdCBlaXRoZXIga2V5IGZv cm1hdCBjb3VsZCBiZSB1c2VkIGluIGVpdGhlcg0KPiA+IGVuY29kaW5nLg0KPiA+ID4NCj4gPg0K PiA+IElmIHdlIHVzZSBKU09OIG1lc3NhZ2VzIG1peGluZyBpbiBDT1NFIGJlY29tZXMgYXdrd2Fy ZC4gSWYgdGhlIHVzZQ0KPiA+IGNhc2UgY2FsbHMgZm9yIEpTT04sIEknZCBhcmd1ZSBpdCBzaG91 bGQgYWxzbyB1c2UgUkZDNzgwMCBpbnN0ZWFkIG9mDQo+ID4gZHJhZnQtaWV0Zi1hY2UtIGN3dC1w cm9vZi1vZi1wb3NzZXNzaW9uLg0KPg0KPiBJIHdvdWxkIG5vdCBoYXZlIGEgcHJvYmxlbSB3aXRo IHRoaXMsIGl0IHdhcyBvbmUgb2YgdGhlIG9wdGlvbnMgYWJvdmUuICBJIHdhcyBqdXN0IGV4cGFu ZGluZyBteSBjb2RlIHRvIGFsbG93IGZvciBKU09OIHRvIGJlIHVzZWQgYW5kIHJhbiBpbnRvIHRo aXMuICBJIGp1c3Qgd2FudGVkIHRvIGdldCBhIGNsZWFyIGdyb3VwIGRlY2lzaW9uIG9uIHRoaXMg YmVmb3JlIEkgcHV0IHRoaW5ncyBpbnRvIHN0b25lLg0KPg0KPiBKaW0NCj4NCj4gPg0KPiA+ID4g My4gIElmIHRoZSBjb25maXJtYXRpb24gaXMgY2hhbmdlZCwgeW91IHdvdWxkIG5lZWQgdG8gY29u dmVydCB0aGUNCj4gPiA+IENPU0Uga2V5IHRvIGEgYmluYXJ5IHN0cmluZywgYmFzZTY0IGVuY29k ZWQgaXQgYW5kIHBhc3MgYXMgYQ0KPiA+ID4gc3RyaW5nIHdoZW4gb2NjdXJyaW5nIGluIGEgSlNP TiBlbmNvZGluZy4gIFRoZXJlIGlzIG5vdCBhbnkgb3RoZXINCj4gPiA+IHZhbGlkIHdheSB0byBk byB0aGlzIChleGNlcHQgc2VlIGFib3ZlIG9mIGp1c3QgY29udmVydGluZyB0aGUga2V5DQo+ID4g PiBmb3JtYXQpLiAgSG93ZXZlciwgdGhlIG9wcG9zaXRlIG9mIHB1dHRpbmcgYSBKT1NFIGtleSBp bnRvIGEgQ09TRQ0KPiA+ID4gY29uZmlybWF0aW9uIGhhcyB0aHJlZSBkaWZmZXJlbnQgb3B0aW9u cyB0aGF0IGNvdWxkIGJlIHVzZWQuDQo+ID4gPiAqICBFbmNvZGUgdGhlIEpPU0Uga2V5IHRvIGEg c3RyaW5nIGFuZCBwYXNzIGFzIGEgc3RyaW5nDQo+ID4gPiAqICBFbmNvZGUgdGhlIEpPU0Uga2V5 IHRvcCBsZXZlbCBtYXAgYXMgQ0JPUiBidXQgbGVhdmUgYWxsIG9mIHRoZQ0KPiA+ID4gZWxlbWVu dHMgYWxvbmUuDQo+ID4gPiAqICBFbmNvZGUgdGhlIEpPU0Uga2V5IGluIENCT1IgaW5jbHVkaW5n IGNvbnZlcnNpb24gb2YgYmFzZTY0DQo+ID4gPiBzdHJpbmdzIHRvIGJpbmFyeSBkYXRhLg0KPiA+ ID4gKE15IGZpcnN0IHByZWZlcmVuY2UgaXMgcHJvYmFibHkgdGhlIHNlY29uZCBvcHRpb24sIGJ1 dCBlaXRoZXIgb2YNCj4gPiA+IHRoZSBmaXJzdCB0d28gbWFrZSBzZW5zZS4pDQo+ID4gPg0KPiA+ ID4gSmltDQo+ID4gPg0KPiA+DQo+ID4gSSdtIHN0aWxsIHVuc3VyZSB0aGF0IHRoZXJlIGlzIGEg Z29vZCB1c2UgY2FzZSBmb3IgdHJhbnNwb3J0aW5nIEpPU0UNCj4gPiBrZXlzIGluIENCT1IsIGJ1 dCBpZiBzdWNoIGEgY2FzZSB0dXJucyB1cCwgSSB3b3VsZCBhZ3JlZSB0aGF0DQo+ID4gdG91Y2hp bmcgdGhlIGVuY29kaW5nIGFzIGxpdHRsZSBhcyBwb3NzaWJsZSBpcyBhIGdvb2QgaWRlYSAoPW9w dGlvbiAxIG9yIDIpLg0KPiA+DQo+ID4gL0x1ZHdpZw0KPiA+DQo+ID4gLS0NCj4gPiBMdWR3aWcg U2VpdHosIFBoRA0KPiA+IFNlY3VyaXR5IExhYiwgUklTRQ0KPiA+IFBob25lICs0NigwKTcwLTM0 OSA5MiA1MQ0KPg0KPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPiBBY2UgbWFpbGluZyBsaXN0DQo+IEFjZUBpZXRmLm9yZzxtYWlsdG86QWNlQGll dGYub3JnPg0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FjZQ0KPiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBBY2UgbWFp bGluZyBsaXN0DQo+IEFjZUBpZXRmLm9yZzxtYWlsdG86QWNlQGlldGYub3JnPg0KPiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FjZQ0KDQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KQWNlIG1haWxpbmcgbGlzdA0KQWNlQGlldGYu b3JnPG1haWx0bzpBY2VAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2FjZQ0KSU1QT1JUQU5UIE5PVElDRTogVGhlIGNvbnRlbnRzIG9mIHRoaXMgZW1haWwg YW5kIGFueSBhdHRhY2htZW50cyBhcmUgY29uZmlkZW50aWFsIGFuZCBtYXkgYWxzbyBiZSBwcml2 aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2Ugbm90 aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIGRvIG5vdCBkaXNjbG9zZSB0aGUgY29udGVu dHMgdG8gYW55IG90aGVyIHBlcnNvbiwgdXNlIGl0IGZvciBhbnkgcHVycG9zZSwgb3Igc3RvcmUg b3IgY29weSB0aGUgaW5mb3JtYXRpb24gaW4gYW55IG1lZGl1bS4gVGhhbmsgeW91Lg0KSU1QT1JU QU5UIE5PVElDRTogVGhlIGNvbnRlbnRzIG9mIHRoaXMgZW1haWwgYW5kIGFueSBhdHRhY2htZW50 cyBhcmUgY29uZmlkZW50aWFsIGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJl IG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1t ZWRpYXRlbHkgYW5kIGRvIG5vdCBkaXNjbG9zZSB0aGUgY29udGVudHMgdG8gYW55IG90aGVyIHBl cnNvbiwgdXNlIGl0IGZvciBhbnkgcHVycG9zZSwgb3Igc3RvcmUgb3IgY29weSB0aGUgaW5mb3Jt YXRpb24gaW4gYW55IG1lZGl1bS4gVGhhbmsgeW91Lg0K --_000_VI1PR08MB5360351588B0569244A75FF3FA9F0VI1PR08MB5360eurp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkRlbmdYaWFuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAx IDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUg NSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxARGVuZ1hpYW4i Ow0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMg Ki8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBj bTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21z by1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJn aW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0 OjBjbTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7 fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1z aXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7 DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24x DQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94 bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2 OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFw ZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLUdCIiBs aW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGJlbGlldmUgdGhlIGN1cnJlbnQgYXBwcm9hY2ggaXMgZm9y IHRoZSBzZXJ2ZXIgdG8gcHJvdmlkZSB0aGUgc3ltbWV0cmljIGtleSAocmF0aGVyIHRoYW4gdGhl IGNsaWVudCkuDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBoYXZlIG5vIGlkZWEgd2hlbiB0 aGlzIHRvcGljIGdldHMgcmVzb2x2ZWQgYmVjYXVzZSBmb2xrcyBrZWVwIGNoYW5naW5nIHRoZWly IG1pbmQgc28gcXVpY2tseS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0i RU4tVVMiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+IENpZ2RlbSBTZW5ndWwg Jmx0O2NpZ2RlbS5zZW5ndWxAZ21haWwuY29tJmd0Ow0KPGJyPg0KPGI+U2VudDo8L2I+IERvbm5l cnN0YWcsIDMuIE9rdG9iZXIgMjAxOSAxMjozNzxicj4NCjxiPlRvOjwvYj4gSGFubmVzIFRzY2hv ZmVuaWcgJmx0O0hhbm5lcy5Uc2Nob2ZlbmlnQGFybS5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBD YXJzdGVuIEJvcm1hbm4gJmx0O2NhYm9AdHppLm9yZyZndDs7IEppbSBTY2hhYWQgJmx0O2lldGZA YXVndXN0Y2VsbGFycy5jb20mZ3Q7OyBMdWR3aWcgU2VpdHogJmx0O2x1ZHdpZy5zZWl0ekByaS5z ZSZndDs7IGFjZUBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW0FjZV0gVHJhbnNw b3J0aW5nIGRpZmZlcmVudCB0eXBlcyBvZiBjbmYgb2JqZWN0cyAtIENCT1IgdnMgSlNPTjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhlbGxvLDxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmsgeW91IGZvciB5b3VyIHJlc3BvbnNl cy4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+VW50aWwgdGhpcyBpc3N1ZSBpcyByZXNvbHZlZCwgaXMgaXQgT0sganVzdCB0byBwb2lu dCB0byBSRkMgNzgwMCwgd2hpY2ggc2F5cyB0aGUgY2xpZW50IHByb3ZpZGVzIHRoZSBzeW1tZXRy aWMgUG9QIGtleT88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Rm9yIE1RVFQgZHJhZnQsJm5ic3A7IHdvdWxkIGxpa2UgdG8gZXhwbGFpbiB0aGF0 IEMtUlMgaXMgTVFUVCAtIE1RVFQgbWF5IGNhcnJ5IEpTT04vQ0JPUiBlbmNvZGluZyBmb3IgdGhl IERhdGEgZmllbGRzIGluIHRoZSBwYWNrZXRzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5DLUFTIGFuZCBSUy1BUyBjYW4gYmUgSFRUUFMvQ29B UC9NUVRUIC0gd2hhdCB3ZSBkZXNjcmliZSBpbiB0aGUgZHJhZnQgaXQgaXMgSFRUUFM7IE1RVFQg c3VwcG9ydCBuZWVkcyBtb3JlIHRob3VnaHQgZm9yIHJlcXVlc3QtcmVzcG9uc2Ugc3R5bGUgY29t bXVuaWNhdGlvbi4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkZvciBIVFRQUy9Db0FQLCBhcHBsaWNhdGlvbi9hY2UmIzQzO2pzb24gb3Ig YXBwbGljYXRpb24vYWNlJiM0MztjYm9yIGNvbnRlbnQgZm9ybWF0cy4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U2luY2UgdGhpcyBp bmZvIGlzIGEgYml0IG11ZGRsZWQgaW4gdGhlIGN1cnJlbnQgZHJhZnQsIEkgd291bGQgbGlrZSB0 byBlbnN1cmUgdGhlcmUgaXMgYSBjbGVhciBwYXJhZ3JhcGgsIHdoaWNoJm5ic3A7dGhlIHdvcmtn cm91cCB3b3VsZCBiZSBmaW5lIHdpdGguJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rIHlvdSBmb3IgeW91ciBoZWxwLiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U2lu Y2VyZWx5LDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+LS1DaWdkZW0mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUaHUsIE9jdCAzLCAyMDE5IGF0IDc6NDIgQU0gSGFu bmVzIFRzY2hvZmVuaWcgJmx0OzxhIGhyZWY9Im1haWx0bzpIYW5uZXMuVHNjaG9mZW5pZ0Bhcm0u Y29tIj5IYW5uZXMuVHNjaG9mZW5pZ0Bhcm0uY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpz b2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6 NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206NS4w cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlcmUgaXMgdW5mb3J0dW5hdGVseSBhIHByb2Js ZW0uPGJyPg0KPGJyPg0KV2l0aCBwcm9vZi1vZi1wb3NzZXNzaW9uIGtleXMgdGhlcmUgaXMgbW9y ZSB0aGFuIGp1c3QgY29udmV5aW5nIHRoZSBDV1QvSldUIG92ZXIgYW5vdGhlciB0cmFuc3BvcnQu PGJyPg0KSW4gdGhlIFBLLWNhc2UsIHRoZSBjbGllbnQgaGFzIHRvIHByb3ZpZGUgdGhlIHB1Ymxp YyBrZXkgdG8gdGhlIHNlcnZlciBhbmQgZ2V0IGl0IGJvdW5kIHRvIHRoZSBQb1AgdG9rZW4uPGJy Pg0KSW4gdGhlIHN5bW1ldHJpYyBrZXkgY2FzZSwgdGhlIHNlcnZlciBoYXMgdG8gcHJvdmlkZSB0 aGUgdG9rZW4gYWxvbmcgd2l0aCB0aGUgc3ltbWV0cmljIGtleSB0aGF0IGlzIGFsc28gaW5jbHVk ZWQgYWx0aG91Z2ggZW5jcnlwdGVkKSBpbiB0aGUgUG9QIHRva2VuLjxicj4NCjxicj4NCldlIGhh dmUgc3RhbmRhcmRpemVkIHRoZSB0cmFuc3BvcnQgb2YgdGhpcyBhZGRpdGlvbmFsIGluZm9ybWF0 aW9uIGluIEFDRSBmb3IgdXNlIHdpdGggQ29BUCBidXQgZm9yIEhUVFAgd2UgZGVjaWRlZCB0byBk byB0aGUgd29yayBvbiBPQXV0aCwgd2hlcmUgaXQgZ290IHN0dWNrIGJlY2F1c2UgdGhlIElvVC1p bnRlcmVzdGVkIHBlb3BsZSBhcmUgbm90IHRoZXJlIGFuZCB0aGUgV2ViIGZvbGtzIHdhbnQgc29t ZXRoaW5nIGVsc2UuPGJyPg0KPGJyPg0KQ2lhbzxicj4NCkhhbm5lczxicj4NCjxicj4NCi0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KRnJvbTogQWNlICZsdDs8YSBocmVmPSJtYWlsdG86 YWNlLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5hY2UtYm91bmNlc0BpZXRmLm9y ZzwvYT4mZ3Q7IE9uIEJlaGFsZiBPZiBDYXJzdGVuIEJvcm1hbm48YnI+DQpTZW50OiBNaXR0d29j aCwgMi4gT2t0b2JlciAyMDE5IDE1OjA1PGJyPg0KVG86IENpZ2RlbSBTZW5ndWwgJmx0OzxhIGhy ZWY9Im1haWx0bzpjaWdkZW0uc2VuZ3VsQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmNpZ2Rl bS5zZW5ndWxAZ21haWwuY29tPC9hPiZndDs8YnI+DQpDYzogSmltIFNjaGFhZCAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmlldGZAYXVndXN0Y2VsbGFycy5jb20iIHRhcmdldD0iX2JsYW5rIj5pZXRmQGF1 Z3VzdGNlbGxhcnMuY29tPC9hPiZndDs7IEx1ZHdpZyBTZWl0eiAmbHQ7PGEgaHJlZj0ibWFpbHRv Omx1ZHdpZy5zZWl0ekByaS5zZSIgdGFyZ2V0PSJfYmxhbmsiPmx1ZHdpZy5zZWl0ekByaS5zZTwv YT4mZ3Q7Ow0KPGEgaHJlZj0ibWFpbHRvOmFjZUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmFj ZUBpZXRmLm9yZzwvYT48YnI+DQpTdWJqZWN0OiBSZTogW0FjZV0gVHJhbnNwb3J0aW5nIGRpZmZl cmVudCB0eXBlcyBvZiBjbmYgb2JqZWN0cyAtIENCT1IgdnMgSlNPTjxicj4NCjxicj4NClRoZXJl IGlzIG5vIHN0cm9uZyBpbnRlcmRlcGVuZGVuY3kgYmV0d2VlbiBXZWIgdHJhbnNmZXIgcHJvdG9j b2wgKEhUVFBTL0NvQVBTKSBhbmQgZGF0YSBmb3JtYXQuPGJyPg0KQ09TRSB3b3JrcyBncmVhdCBv dmVyIEhUVFBTLCBhbmQgaWYgaXQgbXVzdCBiZSwgeW91IGNhbiBzaGlwIEpPU0Ugb3ZlciBDb0FQ Uy48YnI+DQo8YnI+DQpHcsO8w59lLCBDYXJzdGVuPGJyPg0KPGJyPg0KPGJyPg0KJmd0OyBPbiBP Y3QgMiwgMjAxOSwgYXQgMTQ6MDAsIENpZ2RlbSBTZW5ndWwgJmx0OzxhIGhyZWY9Im1haWx0bzpj aWdkZW0uc2VuZ3VsQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmNpZ2RlbS5zZW5ndWxAZ21h aWwuY29tPC9hPiZndDsgd3JvdGU6PGJyPg0KJmd0Ozxicj4NCiZndDsgSGVsbG8gYWxsLDxicj4N CiZndDs8YnI+DQomZ3Q7IEkgYW0gdHJ5aW5nIHRvIGltcGxlbWVudCB0aGlzIGRpc2N1c3Npb24g aW4gdGhlIGRyYWZ0LiZuYnNwOyBBIHBvaW50IGlzIHJhaXNlZCBhYm91dCBDT1NFIGtleXMgaW4g SlNPTiBtZXNzYWdlcy48YnI+DQomZ3Q7IENvdWxkIGl0IGJlIHBvc3NpYmxlIHRvIGdvIHdpdGg6 PGJyPg0KJmd0OyAoMSkgSFRUUFMgLSBhcHBsaWNhdGlvbi9hY2UmIzQzO2pzb24gLSBqd3QgLSBq b3NlIC0gUG9QIGZvciBKV1Qgb3I8YnI+DQomZ3Q7ICgyKSBDb0FQIC0gYXBwbGljYXRpb24vYWNl JiM0MztjYm9yIC0gY3d0IC0gY29zZSAtIFBvUCBmb3IgQ1dUIHdpdGhvdXQ8YnI+DQomZ3Q7IG1p eGluZyBhbnl0aGluZz88YnI+DQomZ3Q7PGJyPg0KJmd0OyAoMSkgd2UgdGhvdWdodCB0byBkZXNj cmliZSBieSBkZWZhdWx0IGluIHRoZSBkb2N1bWVudCwgYW5kICgyKSB3ZSBzYWlkIE1BWSBiZSBz dXBwb3J0ZWQuPGJyPg0KJmd0OyBJcyB0aGVyZSBhIHByb2JsZW0gd2l0aCB0aGlzIGFwcHJvYWNo Pzxicj4NCiZndDs8YnI+DQomZ3Q7IFRoYW5rcyw8YnI+DQomZ3Q7IC0tQ2lnZGVtPGJyPg0KJmd0 Ozxicj4NCiZndDs8YnI+DQomZ3Q7IE9uIFR1ZSwgSnVuIDQsIDIwMTkgYXQgOToyOSBQTSBDaWdk ZW0gU2VuZ3VsICZsdDs8YSBocmVmPSJtYWlsdG86Y2lnZGVtLnNlbmd1bEBnbWFpbC5jb20iIHRh cmdldD0iX2JsYW5rIj5jaWdkZW0uc2VuZ3VsQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4N CiZndDsgSGVsbG8sPGJyPg0KJmd0OyBZZXMsIHdlIHRob3VnaHQgc3VwcG9ydGluZyBKU09OIG9w dGlvbiB3b3VsZCBiZSBnb29kLCB0aG91Z2ggaW5kZWVkIHRoZXJlIGlzIG5vIGlzc3VlIHdpdGgg dHJhbnNwb3J0aW5nIENCT1IuLjxicj4NCiZndDsgSWYgdGhlcmUgYXJlIG5vIG90aGVyIGNvbmNl cm5zLCB3ZSBjYW4gZGVmaW5lIHRoZSBuZXcgbWVkaWEgdHlwZSBpbiB0aGUgTVFUVCBkcmFmdC48 YnI+DQomZ3Q7IFdpbGwgYWRkIHRoZSBpc3N1ZSB0byBHaXRIdWIgcmVwby48YnI+DQomZ3Q7PGJy Pg0KJmd0OyAtLUNpZ2RlbTxicj4NCiZndDs8YnI+DQomZ3Q7IE9uIFR1ZSwgSnVuIDQsIDIwMTkg YXQgNzozNyBQTSBKaW0gU2NoYWFkICZsdDs8YSBocmVmPSJtYWlsdG86aWV0ZkBhdWd1c3RjZWxs YXJzLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmlldGZAYXVndXN0Y2VsbGFycy5jb208L2E+Jmd0OyB3 cm90ZTo8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgJmd0OyAtLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLTxicj4NCiZndDsgJmd0OyBGcm9tOiBBY2UgJmx0OzxhIGhyZWY9Im1haWx0bzph Y2UtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmFjZS1ib3VuY2VzQGlldGYub3Jn PC9hPiZndDsgT24gQmVoYWxmIE9mIEx1ZHdpZyBTZWl0ejxicj4NCiZndDsgJmd0OyBTZW50OiBN b25kYXksIEp1bmUgMywgMjAxOSAxMTo1MSBQTTxicj4NCiZndDsgJmd0OyBUbzogPGEgaHJlZj0i bWFpbHRvOmFjZUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmFjZUBpZXRmLm9yZzwvYT48YnI+ DQomZ3Q7ICZndDsgU3ViamVjdDogUmU6IFtBY2VdIFRyYW5zcG9ydGluZyBkaWZmZXJlbnQgdHlw ZXMgb2YgY25mIG9iamVjdHMgLTxicj4NCiZndDsgJmd0OyBDQk9SIHZzIEpTT048YnI+DQomZ3Q7 ICZndDs8YnI+DQomZ3Q7ICZndDsgT24gMDEvMDYvMjAxOSAwMjo1MSwgSmltIFNjaGFhZCB3cm90 ZTo8YnI+DQomZ3Q7ICZndDsgJmd0OyBMdWR3aWcsPGJyPg0KJmd0OyAmZ3Q7ICZndDs8YnI+DQom Z3Q7ICZndDsgJmd0OyBJIGhhdmUgYmVlbiBkb2luZyBzb21lIGFkYXB0aW9ucyBvZiBteSBjb2Rl YmFzZSBmb3IgZGVhbGluZyB3aXRoPGJyPg0KJmd0OyAmZ3Q7ICZndDsgdGhlIE1RVFQgc3BlY2lm aWNhdGlvbi4mbmJzcDsgSW4gdGhlIHByb2Nlc3Mgb2YgdGhpcywgSSBoYXZlIGlkZW50aWZpZWQ8 YnI+DQomZ3Q7ICZndDsgJmd0OyB0aGUgZm9sbG93aW5nIGl0ZW1zIHRoYXQgSSB0aGluayBuZWVk cyBzb21lIGRpc2N1c3Npb24uJm5ic3A7IFRoZXkgbWF5PGJyPg0KJmd0OyAmZ3Q7ICZndDsgbm90 IG5lZWQgY2hhbmdlcyBpbiBhbnkgZG9jdW1lbnRzIGFuZCBtYXliZSBzaG91bGQgZ2V0IGEgbmV3 IGRvY3VtZW50Ljxicj4NCiZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgMS4mbmJz cDsgVGhlIE1RVFQgZG9jdW1lbnQgaXMgdXNpbmcgdGhlIGNvbnRlbnQgdHlwZSAmcXVvdDthcHBs aWNhdGlvbi9qc29uJnF1b3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgb3ZlciBIVFRQUyBmb3IgdHJh bnNwb3J0aW5nIG1lc3NhZ2VzLiZuYnNwOyBEb2VzIHRoZXJlIG5lZWQgdG8gYmUgYW48YnI+DQom Z3Q7ICZndDsgJmd0OyAmcXVvdDthcHBsaWNhdGlvbi9hY2UmIzQzO2pzb24mcXVvdDsgZGVmaW5l ZCBhcyBhIG1lZGlhIHR5cGUsIGJ1dCBub3Q8YnI+DQomZ3Q7ICZndDsgJmd0OyBuZWNlc3Nhcmls eSBhIENCT1IgbWVkaWEgdHlwZT8mbmJzcDsgSSB0aGluayB0aGUgYW5zd2VyIG1heSBiZSB5ZXMs IGJ1dDxicj4NCiZndDsgJmd0OyAmZ3Q7IGl0IGNvdWxkIGJlIGEgbmV3PGJyPg0KJmd0OyAmZ3Q7 IGRvY3VtZW50Ljxicj4NCiZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IEkgd291bGQgYXJn dWUgdGhhdCB0aGUgZmlyc3QgZHJhZnQgdXNpbmcgc3VjaCBhIG1lZGlhIHR5cGUgd291bGQgYmU8 YnI+DQomZ3Q7ICZndDsgdGhlIHJpZ2h0IHBsYWNlIHRvIHNwZWNpZnkgaXQuIEhvd2V2ZXIgSSdt IG5vdCBzdXJlIHVzaW5nIEpTT04gaXM8YnI+DQomZ3Q7ICZndDsgdGhlIHJpZ2h0IGFwcHJvYWNo IGZvciBhbiBBQ0Ugc3BlY2lmaWNhdGlvbiBhdCBhbGwsIGFyZW4ndCB3ZTxicj4NCiZndDsgJmd0 OyBzdXBwb3NlZCB0byBjYXRlciBmb3IgdGhlIGNvbnN0cmFpbmVkIHdvcmxkPzxicj4NCiZndDsg Jmd0OyBXaGF0IGlzIHRoZXJlIHRvIHByZXZlbnQgdXMgZnJvbSB0cmFuc3BvcnRpbmcgQ0JPUiBv dmVyIEhUVFA/PGJyPg0KJmd0Ozxicj4NCiZndDsgVGhlcmUgd291bGQgYmUgbm8gcmVhc29uIHRo YXQgb25lIGNhbm5vdCB0cmFuc3BvcnQgQ0JPUiBvdmVyIEhUVFAuJm5ic3A7IER1cmluZyB0aGUg ZGlzY3Vzc2lvbnMgZm9yIHRoZXNlIGRyYWZ0cyBIYW5uZXMgd2FzIHZlcnkgZXhwbGljaXQgdGhh dCBoZSB3YW50ZWQgdG8gYmUgYWJsZSB0byB1c2UgSlNPTiByYXRoZXIgdGhhbiBDQk9SIHdpdGgg dGhlIHByb3RvY29sIHRoYXQgd2FzIGRlZmluZWQgYnkgQUNFLiZuYnNwOyBUaGlzIHdvdWxkIG1l YW4gdGhhdCB0aGVyZQ0KIG5lZWRzIHRvIGJlIGFuIGFiaWxpdHkgdG8gdXNlIEpTT04gd2l0aCB0 aGUgQUNFIGZyYW1ld29yayBkb2N1bWVudC48YnI+DQomZ3Q7PGJyPg0KJmd0OyBJIHdvdWxkIGhh dmUgbm8gcHJvYmxlbXMgd2l0aCB0aGUgc3RhdGVtZW50IHRoYXQgdGhlIE1RVFQgZG9jdW1lbnQg d291bGQgYmUgYSBnb29kIHBsYWNlIHRvIGRlZmluZSB0aGUgbmV3IG1lZGlhIHR5cGUuPGJyPg0K Jmd0Ozxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7IDIuJm5ic3A7IElmIEkgdXNl IGEgJnF1b3Q7Q09TRV9LZXkmcXVvdDsgY29uZmlybWF0aW9uIG1ldGhvZCBpbnNpZGUgb2YgYW48 YnI+DQomZ3Q7ICZndDsgJmd0OyBhcHBsaWNhdGlvbi9hY2UmIzQzO2pzb24gbWVzc2FnZSwgdGhl cmUgaXMgYSBwb3RlbnRpYWwgcHJvYmxlbSBhbmQgaXQ8YnI+DQomZ3Q7ICZndDsgJmd0OyBjb3Vs ZCBiZSBkZWFsdCB3aXRoIGluIGEgbnVtYmVyIG9mIGRpZmZlcmVudCB3YXlzLjxicj4NCiZndDsg Jmd0OyAmZ3Q7ICombmJzcDsgVGhlIEpXVCBjb25maXJtYXRpb24gbWV0aG9kIGlzIGlkZW50aWZp ZWQgYXMgJnF1b3Q7andrJnF1b3Q7LiZuYnNwOyBUaGUgQ09TRTxicj4NCiZndDsgJmd0OyAmZ3Q7 IGtleSBtdXN0IGJlIHRyYW5zbGF0ZWQgaW50byBKT1NFIGV2ZW4gaWYgdGhlcmUgaXMgbm8gZXF1 aXZhbGVudDxicj4NCiZndDsgJmd0OyAmZ3Q7IGtleSBpbiBKT1NFLiZuYnNwOyBJLmUuIHRoYXQg aXMgYSBmYXRhbCBlcnJvcjxicj4NCiZndDsgJmd0OyAmZ3Q7ICombmJzcDsgVGhpcyBkb2VzIG5v dCBtYWtlIHNlbnNlIGFuZCB0aGUgY29uZmlybWF0aW9uIG1ldGhvZCBzaG91bGQgYmU8YnI+DQom Z3Q7ICZndDsgJmd0OyBjaGFuZ2VkIHRvICZxdW90O2N3ayZxdW90OyBzbyB0aGF0IGVpdGhlciBr ZXkgZm9ybWF0IGNvdWxkIGJlIHVzZWQgaW4gZWl0aGVyPGJyPg0KJmd0OyAmZ3Q7IGVuY29kaW5n Ljxicj4NCiZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IElmIHdl IHVzZSBKU09OIG1lc3NhZ2VzIG1peGluZyBpbiBDT1NFIGJlY29tZXMgYXdrd2FyZC4gSWYgdGhl IHVzZTxicj4NCiZndDsgJmd0OyBjYXNlIGNhbGxzIGZvciBKU09OLCBJJ2QgYXJndWUgaXQgc2hv dWxkIGFsc28gdXNlIFJGQzc4MDAgaW5zdGVhZCBvZjxicj4NCiZndDsgJmd0OyBkcmFmdC1pZXRm LWFjZS0gY3d0LXByb29mLW9mLXBvc3Nlc3Npb24uPGJyPg0KJmd0Ozxicj4NCiZndDsgSSB3b3Vs ZCBub3QgaGF2ZSBhIHByb2JsZW0gd2l0aCB0aGlzLCBpdCB3YXMgb25lIG9mIHRoZSBvcHRpb25z IGFib3ZlLiZuYnNwOyBJIHdhcyBqdXN0IGV4cGFuZGluZyBteSBjb2RlIHRvIGFsbG93IGZvciBK U09OIHRvIGJlIHVzZWQgYW5kIHJhbiBpbnRvIHRoaXMuJm5ic3A7IEkganVzdCB3YW50ZWQgdG8g Z2V0IGEgY2xlYXIgZ3JvdXAgZGVjaXNpb24gb24gdGhpcyBiZWZvcmUgSSBwdXQgdGhpbmdzIGlu dG8gc3RvbmUuPGJyPg0KJmd0Ozxicj4NCiZndDsgSmltPGJyPg0KJmd0Ozxicj4NCiZndDsgJmd0 Ozxicj4NCiZndDsgJmd0OyAmZ3Q7IDMuJm5ic3A7IElmIHRoZSBjb25maXJtYXRpb24gaXMgY2hh bmdlZCwgeW91IHdvdWxkIG5lZWQgdG8gY29udmVydCB0aGU8YnI+DQomZ3Q7ICZndDsgJmd0OyBD T1NFIGtleSB0byBhIGJpbmFyeSBzdHJpbmcsIGJhc2U2NCBlbmNvZGVkIGl0IGFuZCBwYXNzIGFz IGE8YnI+DQomZ3Q7ICZndDsgJmd0OyBzdHJpbmcgd2hlbiBvY2N1cnJpbmcgaW4gYSBKU09OIGVu Y29kaW5nLiZuYnNwOyBUaGVyZSBpcyBub3QgYW55IG90aGVyPGJyPg0KJmd0OyAmZ3Q7ICZndDsg dmFsaWQgd2F5IHRvIGRvIHRoaXMgKGV4Y2VwdCBzZWUgYWJvdmUgb2YganVzdCBjb252ZXJ0aW5n IHRoZSBrZXk8YnI+DQomZ3Q7ICZndDsgJmd0OyBmb3JtYXQpLiZuYnNwOyBIb3dldmVyLCB0aGUg b3Bwb3NpdGUgb2YgcHV0dGluZyBhIEpPU0Uga2V5IGludG8gYSBDT1NFPGJyPg0KJmd0OyAmZ3Q7 ICZndDsgY29uZmlybWF0aW9uIGhhcyB0aHJlZSBkaWZmZXJlbnQgb3B0aW9ucyB0aGF0IGNvdWxk IGJlIHVzZWQuPGJyPg0KJmd0OyAmZ3Q7ICZndDsgKiZuYnNwOyBFbmNvZGUgdGhlIEpPU0Uga2V5 IHRvIGEgc3RyaW5nIGFuZCBwYXNzIGFzIGEgc3RyaW5nPGJyPg0KJmd0OyAmZ3Q7ICZndDsgKiZu YnNwOyBFbmNvZGUgdGhlIEpPU0Uga2V5IHRvcCBsZXZlbCBtYXAgYXMgQ0JPUiBidXQgbGVhdmUg YWxsIG9mIHRoZTxicj4NCiZndDsgJmd0OyAmZ3Q7IGVsZW1lbnRzIGFsb25lLjxicj4NCiZndDsg Jmd0OyAmZ3Q7ICombmJzcDsgRW5jb2RlIHRoZSBKT1NFIGtleSBpbiBDQk9SIGluY2x1ZGluZyBj b252ZXJzaW9uIG9mIGJhc2U2NDxicj4NCiZndDsgJmd0OyAmZ3Q7IHN0cmluZ3MgdG8gYmluYXJ5 IGRhdGEuPGJyPg0KJmd0OyAmZ3Q7ICZndDsgKE15IGZpcnN0IHByZWZlcmVuY2UgaXMgcHJvYmFi bHkgdGhlIHNlY29uZCBvcHRpb24sIGJ1dCBlaXRoZXIgb2Y8YnI+DQomZ3Q7ICZndDsgJmd0OyB0 aGUgZmlyc3QgdHdvIG1ha2Ugc2Vuc2UuKTxicj4NCiZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAm Z3Q7ICZndDsgSmltPGJyPg0KJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7 ICZndDsgSSdtIHN0aWxsIHVuc3VyZSB0aGF0IHRoZXJlIGlzIGEgZ29vZCB1c2UgY2FzZSBmb3Ig dHJhbnNwb3J0aW5nIEpPU0U8YnI+DQomZ3Q7ICZndDsga2V5cyBpbiBDQk9SLCBidXQgaWYgc3Vj aCBhIGNhc2UgdHVybnMgdXAsIEkgd291bGQgYWdyZWUgdGhhdDxicj4NCiZndDsgJmd0OyB0b3Vj aGluZyB0aGUgZW5jb2RpbmcgYXMgbGl0dGxlIGFzIHBvc3NpYmxlIGlzIGEgZ29vZCBpZGVhICg9 b3B0aW9uIDEgb3IgMikuPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IC9MdWR3aWc8YnI+ DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgLS08YnI+DQomZ3Q7ICZndDsgTHVkd2lnIFNlaXR6 LCBQaEQ8YnI+DQomZ3Q7ICZndDsgU2VjdXJpdHkgTGFiLCBSSVNFPGJyPg0KJmd0OyAmZ3Q7IFBo b25lICYjNDM7NDYoMCk3MC0zNDkgOTIgNTE8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsg X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7 IEFjZSBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7IDxhIGhyZWY9Im1haWx0bzpBY2VAaWV0Zi5vcmci IHRhcmdldD0iX2JsYW5rIj5BY2VAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyA8YSBocmVmPSJodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FjZSIgdGFyZ2V0PSJfYmxhbmsiPmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYWNlPC9hPjxicj4NCiZndDsgX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7IEFj ZSBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7IDxhIGhyZWY9Im1haWx0bzpBY2VAaWV0Zi5vcmciIHRh cmdldD0iX2JsYW5rIj5BY2VAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyA8YSBocmVmPSJodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FjZSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYWNlPC9hPjxicj4NCjxicj4NCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KQWNlIG1haWxp bmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpBY2VAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5r Ij5BY2VAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9hY2UiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2FjZTwvYT48YnI+DQpJTVBPUlRBTlQgTk9USUNFOiBUaGUgY29udGVu dHMgb2YgdGhpcyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBjb25maWRlbnRpYWwgYW5k IG1heSBhbHNvIGJlIHByaXZpbGVnZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNp cGllbnQsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBhbmQgZG8gbm90IGRp c2Nsb3NlIHRoZSBjb250ZW50cyB0byBhbnkgb3RoZXIgcGVyc29uLCB1c2UgaXQgZm9yIGFueSBw dXJwb3NlLA0KIG9yIHN0b3JlIG9yIGNvcHkgdGhlIGluZm9ybWF0aW9uIGluIGFueSBtZWRpdW0u IFRoYW5rIHlvdS48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+ DQpJTVBPUlRBTlQgTk9USUNFOiBUaGUgY29udGVudHMgb2YgdGhpcyBlbWFpbCBhbmQgYW55IGF0 dGFjaG1lbnRzIGFyZSBjb25maWRlbnRpYWwgYW5kIG1heSBhbHNvIGJlIHByaXZpbGVnZWQuIElm IHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBub3RpZnkgdGhlIHNl bmRlciBpbW1lZGlhdGVseSBhbmQgZG8gbm90IGRpc2Nsb3NlIHRoZSBjb250ZW50cyB0byBhbnkg b3RoZXIgcGVyc29uLCB1c2UgaXQgZm9yIGFueSBwdXJwb3NlLA0KIG9yIHN0b3JlIG9yIGNvcHkg dGhlIGluZm9ybWF0aW9uIGluIGFueSBtZWRpdW0uIFRoYW5rIHlvdS4NCjwvYm9keT4NCjwvaHRt bD4NCg== --_000_VI1PR08MB5360351588B0569244A75FF3FA9F0VI1PR08MB5360eurp_-- From nobody Thu Oct 3 04:25: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 4532612011C for ; Thu, 3 Oct 2019 04:25:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=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 PgI0FQ_BxG1Z for ; Thu, 3 Oct 2019 04:25:14 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B06E12011A for ; Thu, 3 Oct 2019 04:25:14 -0700 (PDT) Received: from [10.159.97.60] (ewa_guest_internet_sthlm_nat2.ericsson.net [192.176.1.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 46kVzX3WcGz10mQ; Thu, 3 Oct 2019 13:25:12 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: Date: Thu, 3 Oct 2019 13:25:12 +0200 Cc: Cigdem Sengul , Jim Schaad , Ludwig Seitz , "ace@ietf.org" X-Mao-Original-Outgoing-Id: 591794710.3982821-ace45cb2c47b0ab58ca2605aead3b220 Content-Transfer-Encoding: quoted-printable Message-Id: <55C2AFB2-4247-4752-92A7-310A13460674@tzi.org> References: <000201d51814$34a85fc0$9df91f40$@augustcellars.com> <9a0bbcd4-6055-729c-7ca8-205d0a1fd681@ri.se> <010901d51b04$92788a10$b7699e30$@augustcellars.com> <586CDF5F-F0E4-4514-8AB7-AAA383CA23FB@tzi.org> To: Hannes Tschofenig X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Ace] Transporting different types of cnf objects - CBOR vs JSON 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 Oct 2019 11:25:17 -0000 On Oct 3, 2019, at 08:42, Hannes Tschofenig = wrote: >=20 > but for HTTP we decided to do the work on OAuth, where it got stuck = because the IoT-interested people are not there and the Web folks want = something else. =E2=80=A6so should we organize a mass-walkin of the ACE people at the = OAuth meeting in Bangkok? Is there a good way to find out what the Web people want and why? Gr=C3=BC=C3=9Fe, Carsten From nobody Fri Oct 4 06:53:52 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 7BD9A12004C; Fri, 4 Oct 2019 06:53:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.104.0 Auto-Submitted: auto-generated Precedence: bulk Sender: CC: ace-chairs@ietf.org, ietf@augustcellars.com, Jim Schaad , kaduk@mit.edu, ace@ietf.org, draft-ietf-ace-coap-est@ietf.org Content-Transfer-Encoding: 7bit Reply-To: ietf@ietf.org Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Message-ID: <157019722449.1364.14019135485461085741.idtracker@ietfa.amsl.com> Date: Fri, 04 Oct 2019 06:53:44 -0700 Archived-At: Subject: [Ace] Last Call: (EST over secure CoAP (EST-coaps)) to Proposed Standard X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Oct 2019 13:53:45 -0000 The IESG has received a request from the Authentication and Authorization for Constrained Environments WG (ace) to consider the following document: - 'EST over secure CoAP (EST-coaps)' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2019-10-18. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. 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 file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-ace-coap-est/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-ace-coap-est/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Fri Oct 4 10:44:30 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 4C28D12011F; Fri, 4 Oct 2019 10:44:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Christer Holmberg via Datatracker To: Cc: draft-ietf-ace-cwt-proof-of-possession.all@ietf.org, ietf@ietf.org, ace@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.104.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Christer Holmberg Message-ID: <157021105722.1446.14439223392992273252@ietfa.amsl.com> Date: Fri, 04 Oct 2019 10:44:17 -0700 Archived-At: Subject: [Ace] Genart last call review of draft-ietf-ace-cwt-proof-of-possession-08 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Oct 2019 17:44:17 -0000 Reviewer: Christer Holmberg Review result: Ready with Issues I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-ace-cwt-proof-of-possession-08 Reviewer: Christer Holmberg Review Date: 2019-10-04 IETF LC End Date: 2019-10-09 IESG Telechat date: Not scheduled for a telechat Summary: For most part the document is ready, but I have a few editorial comments and an issue. Major issues: N/A Minor issues: The text says in the Security Considerations that one must ensure that the might not understand the "cnf" claim, and that applications must ensure that receivers support it. Q1: How are you going to ensure that, and why do you have to ensure that? RFC 8392 doesn't even seem to require that one must ensure that the receivers support CWT. Q2: For receivers that do support CWT, RFC 8392 says that unsupported claims must be discarded. If that can't be applied for "cnf" I think you need to explain why. Nits/editorial comments: Q_ED_1: Please use [RFC8392] instead of [CWT] when referencing to RFC 8392. Q_ED_2: Shall CBOR be enhanced on first occurrence (in the Abstract or Introduction), or is it on the list of well-known abbreviations? Q_ED_3: Add a reference for CBOR map on first occurrence. (I was looking in RFC 7049, and while it mentions maps in many places I could not find a proper definition for "CBOR map") From nobody Fri Oct 4 17:04:39 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 96C9E120052; Fri, 4 Oct 2019 17:04:37 -0700 (PDT) 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.104.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <157023387757.1400.12782195346769784272.idtracker@ietfa.amsl.com> Date: Fri, 04 Oct 2019 17:04:37 -0700 Archived-At: Subject: [Ace] ace - New Meeting Session Request for IETF 106 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: Sat, 05 Oct 2019 00:04:38 -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): 1.5 Hours Number of Attendees: 50 Conflicts to Avoid: Chair Conflict: ipsecme saag tls secdispatch cbor core lamps cose Technology Overlap: teep homenet cfrg lwig emu t2trg suit oauth Key Participant Conflict: anima 6tisch gendispatch People who must be present: Daniel Migault Jim Schaad Benjamin Kaduk Resources Requested: Special Requests: --------------------------------------------------------- From nobody Sat Oct 5 14:29:50 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 1CE66120104; Sat, 5 Oct 2019 14:29:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ace@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.104.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ace@ietf.org Message-ID: <157031098898.16747.5560925080942702881@ietfa.amsl.com> Date: Sat, 05 Oct 2019 14:29:49 -0700 Archived-At: Subject: [Ace] I-D Action: draft-ietf-ace-mqtt-tls-profile-01.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: Sat, 05 Oct 2019 21:29:49 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Authentication and Authorization for Constrained Environments WG of the IETF. Title : MQTT-TLS profile of ACE Authors : Cigdem Sengul Anthony Kirby Paul Fremantle Filename : draft-ietf-ace-mqtt-tls-profile-01.txt Pages : 23 Date : 2019-10-05 Abstract: This document specifies a profile for the ACE (Authentication and Authorization for Constrained Environments) to enable authorization in an MQTT-based publish-subscribe messaging system. Proof-of- possession keys, bound to OAuth2.0 access tokens, are used to authenticate and authorize MQTT Clients. The protocol relies on TLS for confidentiality and server authentication. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ace-mqtt-tls-profile/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ace-mqtt-tls-profile-01 https://datatracker.ietf.org/doc/html/draft-ietf-ace-mqtt-tls-profile-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-mqtt-tls-profile-01 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 Sat Oct 5 14:37:24 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 9F55C120104 for ; Sat, 5 Oct 2019 14:37:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 d2rEYSFbqZVF for ; Sat, 5 Oct 2019 14:37:20 -0700 (PDT) Received: from mail-qt1-x832.google.com (mail-qt1-x832.google.com [IPv6:2607:f8b0:4864:20::832]) (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 C357A1200D8 for ; Sat, 5 Oct 2019 14:37:19 -0700 (PDT) Received: by mail-qt1-x832.google.com with SMTP id n7so13766517qtb.6 for ; Sat, 05 Oct 2019 14:37:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=n8mtN4tMLUOPbrxXE6fwi5IBX6JrXP07e0Iy0/j66IY=; b=QbTh0Cmbel4Uu+BhxhvWj9nkaSxDMkkPXu27yib3o6Br7VzulPIm3NkYExiPQ6E+JI +glQBG8zcIfqwMzb9ONKeWXA0ArsH7zbFqHn76+ge440ZP20CftHnINiD6xKSkqBd40v qXoUxLUZjB4H7CYTbFszbHz0vXFV1H5WJuatpjpr6q9tdp3PInaW2bHBpkaikK8mIHzU tGg88jqZpfdPBDMCGV/4k54XvdLQvTWLNvUXW0wMBapkosWWVEcKTM+ExXSOnKzXXZgc g5dFGqzsjMWShvajNrbq/DWEM4ayj8fE9GcysoLXehDn18dQ1R8cRdAcl+pDX37T3OUh iiaQ== 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; bh=n8mtN4tMLUOPbrxXE6fwi5IBX6JrXP07e0Iy0/j66IY=; b=PfJTtTLW9GXYIutJLilOE/BRXIxuESDFEPtsyIRt97aLZZ4fOcHg6QfpPMDVFlWXeu ysx1cYd+ZRNwgPboNJlcBcegKLq02yf/LpWMb8NDmgs3Nnbq4dPO+UYzVhN6WEC4Wag3 IWZEPpvi5gUJVGJkJCRfB49cB2DOYQsGb6TCd6pHNlk+y4LfuT5obOW6c6HvYOjNN4ea pPgrPTD4IX4iT9GfTZXbUK25J3XEVPkDQ3YDhHMFXMUCkDlClqal1cBl26rM7YEIrtnB GKYTulPickTCWDJ8ut7guHsWInYDydiMyUUJB4BORqyUe7cuaGpzd07sUEr4GohTE28V rZxA== X-Gm-Message-State: APjAAAUIS+a3YRP0DY19qRzMIcwaze7x+klJ7Iw2G/i7lLQ4xlZpRd17 tVXC6uKlNLrQB/lZbH3PiwFIlb2FB6GZ6d1IEJNgPm+HQ7g= X-Google-Smtp-Source: APXvYqz0YDk6FmJsCr1IcdmLqM6dHt70oK3R8HsPop0+gDKPZ/bmp4sC5ir/MAV1ODgTPet4CGcPzwvXcv/dXYNY2Og= X-Received: by 2002:a05:6214:1226:: with SMTP id p6mr20836319qvv.167.1570311438669; Sat, 05 Oct 2019 14:37:18 -0700 (PDT) MIME-Version: 1.0 References: <157031098923.16747.18166699949039239234.idtracker@ietfa.amsl.com> <74516AC9-AF63-48D1-95A2-9A19394F4C58@nominet.uk> In-Reply-To: <74516AC9-AF63-48D1-95A2-9A19394F4C58@nominet.uk> From: Cigdem Sengul Date: Sat, 5 Oct 2019 22:37:07 +0100 Message-ID: To: ace@ietf.org Content-Type: multipart/alternative; boundary="0000000000007d1fc00594309fd4" Archived-At: Subject: [Ace] Fwd:New Version Notification for draft-ietf-ace-mqtt-tls-profile-01.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Oct 2019 21:37:22 -0000 --0000000000007d1fc00594309fd4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello, We have uploaded a new version of the MQTT-TLS profile. Thank you very much for the feedback and responses - Jim, Daniel, Ludwig, Carsten and Hannes. We have done the following changes. However, even though we tried to keep a clear language around the HTTPS/CoAP, JSON/CBOR, JWT/CWT, we are aware that more work needs to be done; and these are also tied to OAuth WG. Version 00 to 01: o Presented the MQTTv5 as the RECOMMENDED version, and MQTT v3.1.1 for backward compatibility. o Clarified Will message. o Improved consistency in the use of terminology, and upper/lower case. o Defined Broker and MQTTS. o Clarified HTTPS use for C-AS and RS-AS communication. Removed reference to actors document, and clarified the use of client authorization server. o Clarified the Connect message payload and Client Identifier. o Presented different methods for passing the token, and PoP. o Added new figures for AUTH methods, updated CONNECT message figure. Thank you very much for your help. --Cigdem =EF=BB=BFOn 05/10/2019, 22:29, "internet-drafts@ietf.org" wrote: A new version of I-D, draft-ietf-ace-mqtt-tls-profile-01.txt has been successfully submitted by Cigdem Sengul and posted to the IETF repository. Name: draft-ietf-ace-mqtt-tls-profile Revision: 01 Title: MQTT-TLS profile of ACE Document date: 2019-10-05 Group: ace Pages: 23 URL: https://www.ietf.org/internet-drafts/draft-ietf-ace-mqtt-tls-profile-01.txt Status: https://datatracker.ietf.org/doc/draft-ietf-ace-mqtt-tls-profile/ Htmlized: https://tools.ietf.org/html/draft-ietf-ace-mqtt-tls-profile-01 Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-ace-mqtt-tls-profile Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ace-mqtt-tls-profile-01 Abstract: This document specifies a profile for the ACE (Authentication and Authorization for Constrained Environments) to enable authorization in an MQTT-based publish-subscribe messaging system. Proof-of- possession keys, bound to OAuth2.0 access tokens, are used to authenticate and authorize MQTT Clients. The protocol relies on TLS for confidentiality and server authentication. 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 --0000000000007d1fc00594309fd4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,

We have uploaded a new version o= f the MQTT-TLS profile.=C2=A0
Thank you very much for the feedbac= k and responses=C2=A0 - Jim, Daniel, Ludwig, Carsten and Hannes.=C2=A0

We have done the following changes. However, even thou= gh we tried to keep a clear language around the HTTPS/CoAP, JSON/CBOR, JWT/= CWT, we are aware that more work needs to be done; and these are also tied = to OAuth WG.=C2=A0

Version 00 to 01:


=C2=A0=C2=A0 o=C2=A0 Presented the MQTTv5 as the RECOMMENDED version, and MQTT = v3.1.1 for=C2=A0backward compatibility.


=C2=A0=C2=A0 o=C2=A0 Clarified Will message.


=C2=A0=C2=A0 o=C2=A0 Improved consistency in the use of terminology, and upper/= lower

=C2=A0 =C2=A0 =C2=A0 case.


=C2=A0=C2=A0 o=C2=A0 Defined Broker and MQTTS.


=C2=A0=C2=A0 o=C2=A0 Clarified HTTPS use for C-AS and RS-AS communication.=C2=A0 Removed

=C2=A0 =C2=A0 =C2=A0 reference to actors document, and = clarified the use of client

=C2=A0 =C2=A0 =C2=A0 authorization server.


=C2=A0=C2=A0 o=C2=A0 Clarified the Connect message payload and Client Identifie= r.


=C2=A0=C2=A0 o=C2=A0 Presented different methods for passing the token, and PoP= .


=C2=A0=C2=A0 o=C2=A0 Added new figures for AUTH methods, updated CONNECT messag= e

=C2=A0 =C2=A0 =C2=A0 figure.



Thank you very much for your help.
--Cigdem=

=EF=BB=BFOn 05/10/2019, 22:29, "internet-drafts@ietf.org" <internet-drafts@ietf.org<= /a>> wrote:


=C2=A0 =C2=A0 A new version of I-D, draft-ietf-ace-mqtt-tls-profile-01.txt<= br> =C2=A0 =C2=A0 has been successfully submitted by Cigdem Sengul and posted t= o the
=C2=A0 =C2=A0 IETF repository.

=C2=A0 =C2=A0 Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0d= raft-ietf-ace-mqtt-tls-profile
=C2=A0 =C2=A0 Revision:=C2=A0 =C2=A001
=C2=A0 =C2=A0 Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 MQTT-T= LS profile of ACE
=C2=A0 =C2=A0 Document date:=C2=A0 =C2=A0 =C2=A0 2019-10-05
=C2=A0 =C2=A0 Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ace =C2=A0 =C2=A0 Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 23
=C2=A0 =C2=A0 URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/dra= ft-ietf-ace-mqtt-tls-profile-01.txt
=C2=A0 =C2=A0 Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-ietf-ace-mqtt-tl= s-profile/
=C2=A0 =C2=A0 Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-ietf-ace-mqtt-tls-profile-01<= /a>
=C2=A0 =C2=A0 Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-ietf-ace-mqt= t-tls-profile
=C2=A0 =C2=A0 Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-iet= f-ace-mqtt-tls-profile-01

=C2=A0 =C2=A0 Abstract:
=C2=A0 =C2=A0 =C2=A0 =C2=A0This document specifies a profile for the ACE (A= uthentication and
=C2=A0 =C2=A0 =C2=A0 =C2=A0Authorization for Constrained Environments) to e= nable authorization
=C2=A0 =C2=A0 =C2=A0 =C2=A0in an MQTT-based publish-subscribe messaging sys= tem.=C2=A0 Proof-of-
=C2=A0 =C2=A0 =C2=A0 =C2=A0possession keys, bound to OAuth2.0 access tokens= , are used to
=C2=A0 =C2=A0 =C2=A0 =C2=A0authenticate and authorize MQTT Clients.=C2=A0 T= he protocol relies on TLS
=C2=A0 =C2=A0 =C2=A0 =C2=A0for confidentiality and server authentication.



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

=C2=A0 =C2=A0 The IETF Secretariat



--0000000000007d1fc00594309fd4-- From nobody Sat Oct 5 21:49:31 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 3C2DC1201CE; Sat, 5 Oct 2019 21:49:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: David Schinazi via Datatracker To: Cc: draft-ietf-ace-coap-est.all@ietf.org, ietf@ietf.org, ace@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.104.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: David Schinazi Message-ID: <157033736912.16707.14556141146758239410@ietfa.amsl.com> Date: Sat, 05 Oct 2019 21:49:29 -0700 Archived-At: Subject: [Ace] Genart last call review of draft-ietf-ace-coap-est-15 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: Sun, 06 Oct 2019 04:49:29 -0000 Reviewer: David Schinazi Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-ace-coap-est-?? Reviewer: David Schinazi Review Date: 2019-10-05 IETF LC End Date: 2019-10-18 IESG Telechat date: Not scheduled for a telechat Summary: Document is clear and well-written. Major issues: None. Minor issues: None. Nits/editorial comments: I believe references to RFC7525 should instead refer to it as BCP195 to point to future revisions. From nobody Sun Oct 6 11:51:39 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 D85561200DF; Sun, 6 Oct 2019 11:51:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Yoav Nir via Datatracker To: Cc: draft-ietf-ace-cwt-proof-of-possession.all@ietf.org, ietf@ietf.org, ace@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.104.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Yoav Nir Message-ID: <157038789080.6563.18028321376777169887@ietfa.amsl.com> Date: Sun, 06 Oct 2019 11:51:30 -0700 Archived-At: Subject: [Ace] Secdir last call review of draft-ietf-ace-cwt-proof-of-possession-08 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: Sun, 06 Oct 2019 18:51:31 -0000 Reviewer: Yoav Nir Review result: Has Nits I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. I think the document shows that security aspects have been considered and handled well. However, the document has issues with clarity and readability: For starters, the Abstract and Introduction are nearly identical. The Introduction could instead be used to explain the domain, who the "players" are and what they are trying to accomplish. Instead, section 2 introduces the terms Issuer, Presenter and Recipient with definitions that sound like the CA, the End Entity and the Relying Party from PKI, with a little OAuth terminology mixed in. There is no explanation about who this issuer is, and what the trust model is. The Security Considerations section also has some problems. Quoting the second paragraph: Applications utilizing proof of possession SHOULD also utilize audience restriction, as described in Section 3.1.3 of [CWT], as it provides additional protections. Audience restriction can be used by recipients to reject messages intended for different recipients. Why? Why is the aud claim needed with a cnf claim (but not in other cases)? Neither this document nor RFC 8392 provides insight as to when aud is appropriate. That they allow recipients to reject messages not intended for them does not sound like a security feature. Paragraph 3 says: "A recipient might not understand the "cnf" claim." This re-affirms that we need an explanation of who the parties to this protocol are. We generally don't send messages to recipients that don't understand them. Is this a closed system with known entities, or is this a protocol where the parties contact random other parties on the Internet? I'd also lose some of the Introduction to Crypto in the second-to-last paragraph. From nobody Tue Oct 8 11:37: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 0C4651200B9; Tue, 8 Oct 2019 11:37:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 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_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 header.b=VzCB7oXQ; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=cvV7N303 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 bR8J-unfiws1; Tue, 8 Oct 2019 11:37:30 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F088B120071; Tue, 8 Oct 2019 11:37:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1374; q=dns/txt; s=iport; t=1570559850; x=1571769450; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=yRbGmfjWBUvIo3bnktdMXqTtzU0jH1GuYJGkmEBLbcg=; b=VzCB7oXQ4KpGQ9FYKzfLTtE8/GimJCzW5FvSzPq1DGo52wyxzp3e0/KH fK0JwO8T840v6Wq1OYx4tBMm960AePj6U4ppd2/wAE2d+HAlsBIkhDRpZ RpnY9umSFYMimXrNa4ROn9q2LBNMIFGZtZTGlXR33iYy9BxKNedmL0fUi 4=; IronPort-PHdr: =?us-ascii?q?9a23=3A9XD3HxM/f8Dec7OEOtcl6mtXPHoupqn0MwgJ65?= =?us-ascii?q?Eul7NJdOG58o//OFDEu6w/l0fHCIPc7f8My/HbtaztQyQh2d6AqzhDFf4ETB?= =?us-ascii?q?oZkYMTlg0kDtSCDBjjL/fvdyU8FexJVURu+DewNk0GUMs=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ANAACc1pxd/5JdJa1mGgEBAQEBAQE?= =?us-ascii?q?BAQMBAQEBEQEBAQICAQEBAYFoBAEBAQELAYFKUANtViAECyqHagOKSoJcl32?= =?us-ascii?q?BLoEkA1QJAQEBDAEBGAsKAgEBhEACgkUjNQgOAgMJAQEEAQEBAgEFBG2FLQy?= =?us-ascii?q?FSwEBAQEDAQEQKAYBASwLAQsEAgEIDgMDAQEBHxAnCx0IAgQBDQUIGoMBgWo?= =?us-ascii?q?DHQECDKNmAoE4iGGCJ4J9AQEFhQgYghcDBoE0AYwNGIFAP4ERRoIeLj6CYQE?= =?us-ascii?q?BgWODPoImjTagEQqCIocIjiyCOodOjziOLYgikRQCBAIEBQIOAQEFgVQBNoF?= =?us-ascii?q?YcBU7gmxQEBSBT4NzhRSFP3SBKY9rAQE?= X-IronPort-AV: E=Sophos;i="5.67,272,1566864000"; d="scan'208";a="346227190" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 08 Oct 2019 18:37:28 +0000 Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by rcdn-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id x98IbSVF016258 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 8 Oct 2019 18:37:28 GMT Received: from xhs-aln-003.cisco.com (173.37.135.120) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 8 Oct 2019 13:37:28 -0500 Received: from xhs-aln-002.cisco.com (173.37.135.119) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 8 Oct 2019 13:37:27 -0500 Received: from NAM05-DM3-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 8 Oct 2019 13:37:27 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=QBUNUXo5k6Mii2op5dvz7NyQM6CITwtEeIPL13S61Z3XxvnJ+YG438pUmOYUqqQxsVveia3BThDfHmHAuOE3l4Hu++F81vM3HlnFYp+MpIRs7JE4P/fJ7skd2fOf2hsH9PR0gFoiSvZsJeNzA0TTsxVvIXWgBbLAseSMupwesBFgTgzGCIdd69qj3ZH4t6NuQ68j/ZSihGn8L3USoHvuXlwj52LNjBUXQdnFFcUxrda16dyhNiXrIwUmm4jjqxJXasWia8Q0FkZmucqdwOWiRqnt9d0gifqeVmZ2K2vscszOnruQJEq5roSWWi//gzb69pLjv8mSjJrPspRagofo6g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=yzmlafhQl7GgVvPi3KiBFHsEtnqCstMP4yamarETOlQ=; b=G2MCyadz9Tip0xRQ97dpwBn6VYMX4Yp7ASbPIaBr5QhkUQo6JVBJjICw7m4ObenWdYez5srmFIQr2e/l+ZNtxXJOTgkNu7g1EcAykXblCTjI4ev/7NM+kNLvQp53f6KmDod0X/W3CBPQ1UgcQ808P5lNGvAogAsDxEQn8CUbIVmq0BoWj+7Maf8HWNQez1yyguchP/TxkRRctNh4j/Ty7QE5cv/CJQKp9l/DV63M1Qe9pQ/PdlpXCQMR7hpbSfyUkf7qUngfgnTUSOBfXp/51dS2l7lcjqcRiMmjzr8hy7oQk7zK0aiFkYzlWuGXekoRqVe5uiQzHubpRWndwNFUrQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=yzmlafhQl7GgVvPi3KiBFHsEtnqCstMP4yamarETOlQ=; b=cvV7N303gLPIjz2Gq9yMnoPWti7DmNUAsB9+c6NPmdiadhJYOroPfP7PKgKBgTFTLpuyva081E+uPyjIG2nAHMl+UTjV4ZuWguJlGAwFTMAPmA+tDv1L9GxdXIZXJbFuJW7Stz0i2bpTjiLTdOGIxYlOf8LvvUfPgK5QmD92jkI= Received: from BN7PR11MB2547.namprd11.prod.outlook.com (52.135.255.146) by BN7PR11MB2852.namprd11.prod.outlook.com (52.135.252.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2327.24; Tue, 8 Oct 2019 18:37:26 +0000 Received: from BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::5082:c814:2836:9e2a]) by BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::5082:c814:2836:9e2a%7]) with mapi id 15.20.2327.026; Tue, 8 Oct 2019 18:37:25 +0000 From: "Panos Kampanakis (pkampana)" To: David Schinazi , "gen-art@ietf.org" CC: "draft-ietf-ace-coap-est.all@ietf.org" , "ietf@ietf.org" , "ace@ietf.org" Thread-Topic: [Ace] Genart last call review of draft-ietf-ace-coap-est-15 Thread-Index: AQHVfAGGjxci8gPurUCVy7vnTyBGu6dREWAQ Date: Tue, 8 Oct 2019 18:37:25 +0000 Message-ID: References: <157033736912.16707.14556141146758239410@ietfa.amsl.com> In-Reply-To: <157033736912.16707.14556141146758239410@ietfa.amsl.com> 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=pkampana@cisco.com; x-originating-ip: [2001:420:2090:1009:93d:757f:712d:3e62] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 135bc790-ff21-4b0c-0976-08d74c1e9098 x-ms-traffictypediagnostic: BN7PR11MB2852: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7219; x-forefront-prvs: 01842C458A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(346002)(136003)(376002)(366004)(39860400002)(13464003)(189003)(199004)(486006)(478600001)(9686003)(6246003)(256004)(55016002)(6306002)(81166006)(8936002)(81156014)(8676002)(71200400001)(71190400001)(33656002)(46003)(11346002)(446003)(476003)(99286004)(2501003)(4326008)(966005)(14454004)(4001150100001)(186003)(74316002)(305945005)(7736002)(66946007)(66446008)(66556008)(64756008)(7696005)(76116006)(66476007)(76176011)(110136005)(54906003)(6436002)(229853002)(102836004)(316002)(6116002)(52536014)(25786009)(2906002)(86362001)(6506007)(53546011)(5660300002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN7PR11MB2852; H:BN7PR11MB2547.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: VRzybNkfSIAVFDfFwBjzcxm0nZZi/JxGIIM+MTzC8pN1UrBK1XWT4lin78zZWYo7t3Ear4oUyLdsToSPGnbLyIrY65V6GiPDJffdLi8nnoxCdtkkq0OdthrycnDwh/WEq+AYb+scn0MbDG0CyuJ32poufAtjskS3+8SSP6OAPZ2gGEoPF2BXlLTaPPP2DgMbl41hA5drlgU/N4lPY34GfIXg1r5TytUnYlyZlNvyPHfVofq41GwI4xZY6f9z4H4yq5zLsWxqiM6ZfR6GwL/SJg8UfQDTEBB3n/EVzIn4hAih0uu9w4UET8rxz57fqujJhGrmY3LFpuVSE9P3/dl6EwTJ/id16W5D4+nLvGUtPQfuGVNKm1RcW7bYRZqSCnfALQegCXyCFgGxIkQuVXfQkSp9yllpS3XBLIksekg8TcEKwQIXv08xv34Cm6AsiD4c/wUKJ/Ty65KYwre+90SSCw== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 135bc790-ff21-4b0c-0976-08d74c1e9098 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Oct 2019 18:37:25.3158 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: cHMlNRGYvTcpFSIPgBQndcldAFAnwlkeloi0TzbA5FdAN83Cd/H4nr6gVZ8Yej8Wue1i4wH0ZnfM4nS2pZxJrg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR11MB2852 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.11, xch-rcd-001.cisco.com X-Outbound-Node: rcdn-core-10.cisco.com Archived-At: Subject: Re: [Ace] Genart last call review of draft-ietf-ace-coap-est-15 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 Oct 2019 18:37:32 -0000 Thanks David. Done. I replaced the RFC7525 references with BCP195.=20 Should I upload or will there be more Gen-ART reviews? -----Original Message----- From: Ace On Behalf Of David Schinazi via Datatracke= r Sent: Sunday, October 06, 2019 12:49 AM To: gen-art@ietf.org Cc: draft-ietf-ace-coap-est.all@ietf.org; ietf@ietf.org; ace@ietf.org Subject: [Ace] Genart last call review of draft-ietf-ace-coap-est-15 Reviewer: David Schinazi Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review = Team (Gen-ART) reviews all IETF documents being processed by the IESG for t= he IETF Chair. Please treat these comments just like any other last call c= omments. For more information, please see the FAQ at . Document: draft-ietf-ace-coap-est-?? Reviewer: David Schinazi Review Date: 2019-10-05 IETF LC End Date: 2019-10-18 IESG Telechat date: Not scheduled for a telechat Summary: Document is clear and well-written. Major issues: None. Minor issues: None. Nits/editorial comments: I believe references to RFC7525 should instead ref= er to it as BCP195 to point to future revisions. _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace From nobody Thu Oct 10 13:09:39 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91B861200EF; Thu, 10 Oct 2019 13:09:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R1zkauQaMJIt; Thu, 10 Oct 2019 13:09:36 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFF33120089; Thu, 10 Oct 2019 13:09:35 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x9AK9SRk010597 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 10 Oct 2019 16:09:30 -0400 Date: Thu, 10 Oct 2019 13:09:28 -0700 From: Benjamin Kaduk To: "Panos Kampanakis (pkampana)" Cc: David Schinazi , "draft-ietf-ace-coap-est.all@ietf.org" , "ace@ietf.org" Message-ID: <20191010200928.GL76545@kduck.mit.edu> References: <157033736912.16707.14556141146758239410@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [Ace] Genart last call review of draft-ietf-ace-coap-est-15 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, 10 Oct 2019 20:09:38 -0000 There will hopefully be a secdir review as well before the document goes into IESG evaluation; given this is a pretty small change, I'd say hold off on uploading for now. Thanks for asking, and thanks David for the review, Ben On Tue, Oct 08, 2019 at 06:37:25PM +0000, Panos Kampanakis (pkampana) wrote: > Thanks David. Done. I replaced the RFC7525 references with BCP195. > > Should I upload or will there be more Gen-ART reviews? > > > -----Original Message----- > From: Ace On Behalf Of David Schinazi via Datatracker > Sent: Sunday, October 06, 2019 12:49 AM > To: gen-art@ietf.org > Cc: draft-ietf-ace-coap-est.all@ietf.org; ietf@ietf.org; ace@ietf.org > Subject: [Ace] Genart last call review of draft-ietf-ace-coap-est-15 > > Reviewer: David Schinazi > Review result: Ready with Nits > > I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. > > For more information, please see the FAQ at > > . > > Document: draft-ietf-ace-coap-est-?? > Reviewer: David Schinazi > Review Date: 2019-10-05 > IETF LC End Date: 2019-10-18 > IESG Telechat date: Not scheduled for a telechat > > Summary: Document is clear and well-written. > > Major issues: None. > > Minor issues: None. > > Nits/editorial comments: I believe references to RFC7525 should instead refer to it as BCP195 to point to future revisions. > > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace From nobody Sun Oct 13 06:02:05 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 7F931120044; Sun, 13 Oct 2019 06:02:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Yaron Sheffer via Datatracker To: Cc: draft-ietf-ace-coap-est.all@ietf.org, ietf@ietf.org, ace@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.105.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Yaron Sheffer Message-ID: <157097172245.20767.1326966836276837764@ietfa.amsl.com> Date: Sun, 13 Oct 2019 06:02:02 -0700 Archived-At: Subject: [Ace] Secdir last call review of draft-ietf-ace-coap-est-15 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: Sun, 13 Oct 2019 13:02:03 -0000 Reviewer: Yaron Sheffer Review result: Has Issues This document defines a new profile for EST (simple certificate enrollment) for restricted devices, to be run on top of CoAP and DTLS, instead of the usual HTTP and TLS. Overall, I tend to be suspicious of "restricted" profiles, and this is a case in point. An implementation of DTLS is no simpler than TLS and most would probably support both protocols. And basically anything supports HTTP. So why would it make sense to define a whole new profile just to avoid using TCP very rarely (say, for daily certificate enrollment), when this profile even needs to include its own fragmentation/buffering mechanisms because the ASN.1 payloads are too long? In other words, we are introducing new and additional complexity with little or no performance gain. - 2. Only certificate-based client authentication is supported. Hopefully some time soon we'll be able to use PAKE here, to bootstrap the PKI. - 4. "Crypto agility is important" - this statement is somewhat meaningless: do we require more than one cipher suite, which would ensure some level of agility? - Also, when we say "Sec. 4.4 of RFC 7925" do we mean *only* Sec. 4.4 or also the subsections: 4.4.1 etc. - "in DTLS 1.3 the Supported Elliptic Curves extension has been renamed to Supported Groups". This is probably true for an older version of the draft, I couldn't find anything to support it in -32. - "the Finished message must be computed" - this whole paragraph is unclear. Are we changing the Finished/MAC computation in DTLS (if so, this must be pointed out very clearly)? Or are we explaining a point about channel binding (if we are, this doesn't come across). - Similarly for the following paragraph: is this a performance optimization, or a change to DTLS? And by the way, why are standard session resumption mechanisms not used? - I don't see value in the short EST URI paths given that most of the "weight" is in ASN.1 data, and the paths are negligible in comparison. Moreover, if the paths are different, shouldn't this document formally UPDATE RFC 7030? I think it is no longer a profile. - Non-default server port: the examples include an IPv6 address in addition to the port number. Is there a way to use relative URIs (omitting the IP address) but include a port number? The server may not know its own IP address (IPv4 with NAT) or the address may be dynamic. - The server MUST support the default /.well-known/est root resource, but then in the next sentence we discuss non-default URIs. In the case of the server having multiple "identities" (the main purpose of the "arbitrary label", AFAIU), the root resource is confusing - which identity is it associated with? And then how is discovery managed for each identity, and is there a way to discover the identities? - There is nowhere in this document a full formal definition of content type TBD287 (a single cert). - Content type negotiation: I can see how it works for enrollment. But in the case of /cacerts, if the server has a list of certs in its explicit TA store (e.g. to support rollover), how can TBD287 (a single cert) make sense? - It is mighty confusing to denote "content format" by "ct" (presumably, this stands for "content type"). - "ASN.1 encoded in binary format" - I think this should be, "DER-encoded ASN.1, in its native binary form". - Please don't use "he" and "she" for the server and the client. Both are merely "it". - "The Registrar MUST authenticate and optionally authorize the client requests" - this statement is too weak. The Registrar must also ensure that clients only send CSRs that pertain to their authenticated identity (channel binding), even when POP-linking is not used. I think this is worthy of its own subsection, describing the validation required for each particular EST flow. - The following paragraph is not clear: is PoP-linking useful/recommended/mandated in this scenario? IMO there should be some 2119 word regarding server-side validation of the tls-unique. - "Table 1 contains the URI mappings between EST-coaps and EST that the Registrar MUST adhere to." But the immediately preceding paragraph describes a case where a server-side generation on the EST-coaps side is mapped to client-side generation on the EST-HTTPS side, which is not a Table 1 mapping! - "the encrypted CMS EnvelopedData blob MUST be converted at the Registrar" - can this be done without decrypting the blob, IOW must the Registrar be privy to the key wrapping key? - The Registrar must support resource discovery: does it mean that resource discovery messages are simply proxied upstream, or that the Registrar presents a simpler resource structure (maybe with no discovery) to its clients while performing discovery upstream? - Security Considerations: there's a long discussion about replacing the implicit TAs with explicit ones. If we (rightly) mandate that the client re-verify the server's cert after getting the /certs response, we are losing most of the minor performance gain that keeping the DTLS connection open might have given us. So why not unambiguously mandate the simpler "MUST close the connection after /certs" instead? Besides, /cacerts is a very rare operation. Why optimise it at all? - "Improper CSR requests" - what are they? What's the server supposed to do? Please give a reference. - A.3, response: I may be missing something, but the binary blob "3081...9fd9" does not parse as PKCS#8 to me. From nobody Sun Oct 13 18:47: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 E857612001A; Sun, 13 Oct 2019 18:47:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8DqtdREilIml; Sun, 13 Oct 2019 18:47:39 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A836F12006D; Sun, 13 Oct 2019 18:47:38 -0700 (PDT) Received: from Jude (192.168.1.159) by mail2.augustcellars.com (192.168.1.201) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Sun, 13 Oct 2019 18:47:32 -0700 From: Jim Schaad To: CC: Date: Sun, 13 Oct 2019 18:47:29 -0700 Message-ID: <013d01d58231$5831ba40$08952ec0$@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: AdWBIa5YFyMZWJuuRUegEgOIDsi3LQ== Content-Language: en-us X-Originating-IP: [192.168.1.159] Archived-At: Subject: [Ace] test planning? 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 Oct 2019 01:47:41 -0000 I was going through the document and trying to figure out what a test plan might look like. I was also trying to make sure I understood all of the information flows. 1. Post the token to the server before starting: a. Yes b. No 2. Establish the connection to the server: a. Use the token as the PSK ID b. Use the token ID (or key ID) as the PSK ID (Requires 1.a) c. Use RPK for server & client authentication (Requires 1.a) d. Use RPK for the server but anonymous client (Could be X.509 cert for the server) e. Anonymous for both client and server authentication (Does not seem to be usable as none of the methods in 3 provide for server authentication.) 3. Send MQTT Connect message a. Use underlying TLS session for authentication - No additional POP is required on the CONNECT event. Permissions are inferred from the token used for client authentication to TLS (2.a, 2.b, 2.c). (Works with all versions of MQTT.) b. Use POP as a password over client ID + nonce. (Not clear where the nonce is carried for MQTT 3.1.1) This replaces the TLS client authentication (2.d). Requires use of JWT as binary not allowed. c. Use the POP via challenge/response. Replaces the TLS client authentication (2.d). (Requires MQTT 5.x) 4. Update token within an open session. If the server closes the session or sends a DISCONNECT then this is moot. a. Post token to the server. (Only thing that would work for MQTT 3.1.1) b. Respond with an AUTH packet and re-run the POP via challenge/response. 5. Update token after a session is closed. Start with step 1 above and create a new session. Based on this, there are a couple of things that need to be clarified in the document: 1. What requirements are there for validating the TLS client/server identities. 2. Is the option in 3.a planned to be a legal option or not? If so then it needs to be documented as such. 3. Does it make any sense to allow for the publication of a new token to the server via a publish to a fixed name. One would not allow for it to be subscribed to. This would allow for an authenticated post rather than the unauthenticated post and would also allow an update method for option 3.a. If not, doe the option of 4.a make sense and should it be documented as such. I will still do a full review of the document. Jim From nobody Tue Oct 15 02:36: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 3F3EE1200B3; Tue, 15 Oct 2019 02:36:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 d10Q-Qnnbje5; Tue, 15 Oct 2019 02:36:53 -0700 (PDT) Received: from mail-qt1-x832.google.com (mail-qt1-x832.google.com [IPv6:2607:f8b0:4864:20::832]) (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 A5B981200B2; Tue, 15 Oct 2019 02:36:53 -0700 (PDT) Received: by mail-qt1-x832.google.com with SMTP id u22so29571955qtq.13; Tue, 15 Oct 2019 02:36:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=meGLYsNXLWBliEqDU41OxnWxiDk7TdeK01QnKPDiMQs=; b=gl8W424ZbzVTcVraKZn+PxvZZJKxzZ1f6ecSHJdZ6jlQCbUOJJ68LM5nuVJTw1FeUD UkWrwkT9I8RP7No2bo9vJmHViPhiiT5vl2OTjnkRPK7fhU5nTOwvi5T7andMrHM+ojFD aA2JZzBBdfmCMUSn9pOL67m1QlAUIs1hlZRgXFN0wYp8QPGf32jR155zUy5BAwSBQ5Lp A9AFIKTGdsgj0Jc6enSUYuAJZY4TcI7rxETBv/iJLtfJEgMiUgBCng6shhlSoqs9FC6y up8kpAzlY06Km/9w/2rf4WE3atAbWpA8Mpr2p8wAPlbHmXVS3xVUQu/j5O72Pf65NL7X OhZw== 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=meGLYsNXLWBliEqDU41OxnWxiDk7TdeK01QnKPDiMQs=; b=lUyXqhQst8LpNnxFsCH9eTAlhDpckoJ6j540JGpxvnBp8gOowhjviJyeOieKUor4co gvf8cTldvUxmbiE/Rrg/mVqYC0VyrYPLk1RGycWW88NJraTZMwUwRIBjADeItw8Krf11 asB71W2tKKt/qI7Wmjhez3edQhIUQLYtkrpg4Fyrv8DDhxUbgd68yfzyU6Wkk+yGurMT f4spBWF8fcGiXN4HqPgEtkUIvP5t45z3Obua1aGrpEWEPDYwT/JsNWEW+ki+xfUfRXmE HhNQRrclu3fbG+40Jqh4ah7X7Wv+l5lPTGVLXT1frOtvZ5K+ueLcOekHCsGwmiSmD74Q Z/kw== X-Gm-Message-State: APjAAAUTVczdAB2q9d3YT8UMWUKVXp0o+heeMv5RcSlh1QfH7f30TrnN phRd0yBT8ICS9hxACYtIR+HpKXpSRj/Vm974G2adTmpZ X-Google-Smtp-Source: APXvYqx+rrdGjMh8mGqhi//O3mOhrRB3a93xP5U6iUK+uk9ZczcSqX1YrG9Eq+WDCOqZhDOkuykUT6YKoyP0kTK7b/o= X-Received: by 2002:ac8:1903:: with SMTP id t3mr38671620qtj.344.1571132212544; Tue, 15 Oct 2019 02:36:52 -0700 (PDT) MIME-Version: 1.0 References: <013d01d58231$5831ba40$08952ec0$@augustcellars.com> In-Reply-To: <013d01d58231$5831ba40$08952ec0$@augustcellars.com> From: Cigdem Sengul Date: Tue, 15 Oct 2019 10:36:41 +0100 Message-ID: To: Jim Schaad Cc: draft-ietf-ace-mqtt-tls-profile@ietf.org, ace@ietf.org Content-Type: multipart/alternative; boundary="0000000000006c881c0594efb903" Archived-At: Subject: Re: [Ace] test planning? 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 Oct 2019 09:36:56 -0000 --0000000000006c881c0594efb903 Content-Type: text/plain; charset="UTF-8" Hello, Thank you, Jim, for this plan. Responses are inline. On Mon, Oct 14, 2019 at 2:47 AM Jim Schaad wrote: > I was going through the document and trying to figure out what a test plan > might look like. I was also trying to make sure I understood all of the > information flows. > > 1. Post the token to the server before starting: > a. Yes > b. No > Both options are supported but 1b is explained in the main document. 1a is explained as supporting an unprotected subscribe-only "authz-info" topic in Appendix B. We considered this as a MAY in section 2.1.2: "To this end, the Broker MAY support /authz-info endpoint via the "authz-info" topic. Then, to transport the token, Clients publish to "authz-info" topic unauthorized. " Should this Appendix B come to the main document as some flows in section 2 require it? Should we explicitly say 1b is RECOMMENDED? Any opinions? > 2. Establish the connection to the server: > a. Use the token as the PSK ID > b. Use the token ID (or key ID) as the PSK ID (Requires 1.a) > c. Use RPK for server & client authentication (Requires 1.a) > d. Use RPK for the server but anonymous client (Could be X.509 cert > for the server) > e. Anonymous for both client and server authentication (Does not > seem to be usable as none of the methods in 3 provide for server > authentication.) > All except 2.e - we did not plan to support it. > 3. Send MQTT Connect message > a. Use underlying TLS session for authentication - No additional > POP is required on the CONNECT event. Permissions are inferred from the > token used for client authentication to TLS (2.a, 2.b, 2.c). (Works with > all versions of MQTT.) > b. Use POP as a password over client ID + nonce. (Not clear where > the nonce is carried for MQTT 3.1.1) This replaces the TLS client > authentication (2.d). Requires use of JWT as binary not allowed. > c. Use the POP via challenge/response. Replaces the TLS client > authentication (2.d). (Requires MQTT 5.x) > True for 3.b -> We need to clarify that the nonce needs to be part of the data that is passed. Since we overload password/username for this, we may need to provide this in a structure in the username. Will define. > 4. Update token within an open session. If the server closes the session > or > sends a DISCONNECT then this is moot. > a. Post token to the server. (Only thing that would work for MQTT > 3.1.1) > b. Respond with an AUTH packet and re-run the POP via > challenge/response. > > 4a. True - here post token to the server means start everything over with CONNECT or "authz-info". If the client knows this is not due to token expiration somewhat (hard to know in MQTT 3.1, then it may skip authz-info). > 5. Update token after a session is closed. Start with step 1 above and > create a new session. > > > Based on this, there are a couple of things that need to be clarified in > the > document: > > 1. What requirements are there for validating the TLS client/server > identities. > Do you mean apart from TLS certificate verification, whether the TLS client checks server identity against a preconfigured reference identity? > 2. Is the option in 3.a planned to be a legal option or not? If so then > it > needs to be documented as such. > We added them as options with MAY statements. How should we change the document to signal this more strongly? > 3. Does it make any sense to allow for the publication of a new token to > the server via a publish to a fixed name. One would not allow for it to be > subscribed to. This would allow for an authenticated post rather than the > unauthenticated post and would also allow an update method for option 3.a. > If not, doe the option of 4.a make sense and should it be documented as > such. > > This is described in Appendix B - as a means of implementing "authz-info". I think this suggests we should move authz-info to the main document. > I will still do a full review of the document. > > Jim > > Thanks for this. I hope I was able to clarify some of the issues. Sincerely, --Cigdem > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > --0000000000006c881c0594efb903 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,

Thank you, Jim, for t= his plan.
Responses are inline.=C2=A0

On Mon, Oct 14, 2019 at 2:47= AM Jim Schaad <ietf@augustcel= lars.com> wrote:
I was going through the document and trying to figure out what a te= st plan
might look like.=C2=A0 I was also trying to make sure I understood all of t= he
information flows.

1.=C2=A0 Post the token to the server before starting:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 a.=C2=A0 Yes
=C2=A0 =C2=A0 =C2=A0 =C2=A0 b. No

Both = options are supported but 1b is explained in the main document.=C2=A0
=
1a is explained as supporting an unprotected subscribe-only "auth= z-info" topic in Appendix B.=C2=A0
We considered this as a M= AY in section 2.1.2:=C2=A0 "To this end, the Broker MAY support /authz= -info
=C2=A0 =C2=A0endpoint via the "authz-info" topic.=C2= =A0 Then, to transport the token, Clients publish to "authz-info"= topic unauthorized. "

Should this Appendix B come = to the main document as some flows in section 2 require it? Should we expli= citly say 1b is RECOMMENDED? Any opinions?


2.=C2=A0 Establish the connection to the server:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 a. Use the token as the PSK ID
=C2=A0 =C2=A0 =C2=A0 =C2=A0 b. Use the token ID (or key ID) as the PSK ID (= Requires 1.a)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 c. Use RPK for server & client authenticati= on (Requires 1.a)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 d. Use RPK for the server but anonymous client = (Could be X.509 cert
for the server)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 e. Anonymous for both client and server authent= ication (Does not
seem to be usable as none of the methods in 3 provide for server
authentication.)

All except 2.e - we di= d not plan to support it.=C2=A0


3. Send MQTT Connect message
=C2=A0 =C2=A0 =C2=A0 =C2=A0 a.=C2=A0 Use underlying TLS session for authent= ication - No additional
POP is required on the CONNECT event.=C2=A0 Permissions are inferred from t= he
token used for client authentication to TLS (2.a, 2.b, 2.c).=C2=A0 (Works w= ith
all versions of MQTT.)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 b.=C2=A0 Use POP as a password over client ID += nonce.=C2=A0 (Not clear where
the nonce is carried for MQTT 3.1.1) This replaces the TLS client
authentication (2.d).=C2=A0 =C2=A0Requires use of JWT as binary not allowed= .
=C2=A0 =C2=A0 =C2=A0 =C2=A0 c. Use the POP via challenge/response.=C2=A0 Re= places the TLS client
authentication (2.d).=C2=A0 (Requires MQTT 5.x)

True for 3.b -> We need to clarify that the nonce needs to be p= art of the data that is passed. Since we overload password/username for thi= s, we may need
to provide this in a structure in the username. Wi= ll define.=C2=A0

=C2=A0
4. Update token within an open session.=C2=A0 If the server closes the sess= ion or
sends a DISCONNECT then this is moot.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 a. Post token to the server.=C2=A0 (Only thing = that would work for MQTT
3.1.1)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 b.=C2=A0 Respond with an AUTH packet and re-run= the POP via
challenge/response.


4a. True - here post token to the serv= er means start everything over with CONNECT or "authz-info". If t= he client knows this is not due to token expiration somewhat (hard to know = in MQTT 3.1, then it may skip
authz-info).=C2=A0

=C2=A0
5.=C2=A0 Update token after a session is closed.=C2=A0 Start with step 1 ab= ove and
create a new session.


Based on this, there are a couple of things that need to be clarified in th= e
document:

1.=C2=A0 What requirements are there for validating the TLS client/server identities.=C2=A0

Do you mean apart fr= om TLS certificate verification, whether the TLS client checks server ident= ity against a preconfigured reference identity?

= =C2=A0
2.=C2=A0 Is the option in 3.a planned to be a legal option or not?=C2=A0 If= so then it
needs to be documented as such.

We adde= d them as options with MAY statements.=C2=A0
How should we change= the document to signal this more strongly?

=C2=A0=
3.=C2=A0 Does it make any sense to allow for the publication of a new token= to
the server via a publish to a fixed name.=C2=A0 One would not allow for it = to be
subscribed to.=C2=A0 =C2=A0This would allow for an authenticated post rathe= r than the
unauthenticated post and would also allow an update method for option 3.a.<= br> If not, doe the option of 4.a make sense and should it be documented as
such.


This is described in Appendix B - as a= means of implementing "authz-info".=C2=A0
I think this= suggests we should move authz-info to the main document.=C2=A0
= =C2=A0
I will still do a full review of the document.

Jim


Thanks for this. I hope I was able to = clarify some of the issues.=C2=A0

Sincerely,
=
--Cigdem
=C2=A0

_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
--0000000000006c881c0594efb903-- From nobody Tue Oct 15 07:08:19 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AAB4120119; Tue, 15 Oct 2019 07:08:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=risecloud.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eiI0CfN8QmjX; Tue, 15 Oct 2019 07:08:09 -0700 (PDT) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00079.outbound.protection.outlook.com [40.107.0.79]) (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 EF86C120043; Tue, 15 Oct 2019 07:08:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=lgxW77urSa7dHYJ1OFABmCTr4Y9gYyZAp2KdXmfUr/C+XRam0gWuLLdoH4NFI1au0xYslJMMpVEPw3uOSbBXX+WJBBNjxO7ugfP/p1jVk/y84LbYi80gkYXvUGGKX1PfyZw+YbVLsMBnOzZjFFHF3cKnQ4c69G3RbZ0cMHzizsTH1Ri7BoTK+VVXzBUNGkmTeFhGhNAWLyWsll91IIVjge+AtW4eflqIJRlBL1rJBgbcoBeWFodH5VhTWTjzUTx6hJTI58USzCAWdHdwcQ8hUmZZIxvBkpWYvPaQKcqbraa5zA/pJSsXfd8ESlkM8CH1nfQKzMFXBFmK1BhJ79r6/Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=6LYghyapujPABybxlxvqjqSpfOlPbzFWBBM0gasay0A=; b=IHPOeKQA4/62UNZhgRNMHJyAJIwxpo+ofCVIcDJN6PJLLaK2jSYc3HXcgLDy0qFsd6+GzOViLsXSN2rYn+EXGmTFmMNp9e6V2gpTyTZCUWAtusPpQ77HSJWjXe4tKFHolTL40oznjhA2pmXAsSewqNZFYmp4bam5kc+351A+wGKMxVtgBmDmqPex3ZiaUkqOOe7b4VBbMVG5AKMDw3g5oldgYeMHlSc2lxPFtVWYo/LNL0CxzRcf8DyLx8/64q3aCYbbSiWvAuInUnFFcyI8BHQNID32njrUseOfs4xHrgDcgJLMeBl7MMzZ3x36fyVtgG3OXYIA/a630RXX2TyFEw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 194.218.146.197) smtp.rcpttodomain=ietf.org smtp.mailfrom=ri.se; dmarc=pass (p=none sp=none pct=100) action=none header.from=ri.se; dkim=none (message not signed); arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=RISEcloud.onmicrosoft.com; s=selector2-RISEcloud-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=6LYghyapujPABybxlxvqjqSpfOlPbzFWBBM0gasay0A=; b=gWbHyzQC6CK3hanT6Cb/I5jd2lXdPiec1d7KIo8AVAkawhLY2fMHCYk0QcP/WZeKpjLhVMHW44vZQ4zY9B4RdKv9PfmvQsF0cot4iyl1HXQAsyJTC+iykOlM2CKASGcO6Zm/1wc4ZSDuZ70kYPi4pR5cQYDrH4iYeluMXz/yLLQ= Received: from HE1P18901CA0019.EURP189.PROD.OUTLOOK.COM (2603:10a6:3:8b::29) by VI1P18901MB0030.EURP189.PROD.OUTLOOK.COM (2603:10a6:801:d::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2347.16; Tue, 15 Oct 2019 14:08:05 +0000 Received: from VE1EUR02FT050.eop-EUR02.prod.protection.outlook.com (2a01:111:f400:7e06::209) by HE1P18901CA0019.outlook.office365.com (2603:10a6:3:8b::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2347.17 via Frontend Transport; Tue, 15 Oct 2019 14:08:04 +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=pass 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 VE1EUR02FT050.mail.protection.outlook.com (10.152.13.198) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.20.2347.16 via Frontend Transport; Tue, 15 Oct 2019 14:07: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.1779.2; Tue, 15 Oct 2019 16:07:48 +0200 To: Benjamin Kaduk , CC: References: <20190927015154.GY6424@kduck.mit.edu> From: Ludwig Seitz Message-ID: <696c7ee4-75f9-48ec-8837-ea171137e9f8@ri.se> Date: Tue, 15 Oct 2019 16:07:48 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <20190927015154.GY6424@kduck.mit.edu> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms070503090608000002070107" X-Originating-IP: [10.100.0.158] X-ClientProxiedBy: sp-mail-2.sp.se (10.100.0.162) To sp-mail-2.sp.se (10.100.0.162) X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:194.218.146.197; IPV:NLI; CTRY:SE; EFV:NLI; SFV:NSPM; SFS:(10009020)(4636009)(136003)(396003)(376002)(346002)(39860400002)(189003)(199004)(53754006)(37524003)(51444003)(126002)(476003)(16586007)(446003)(2616005)(11346002)(229853002)(486006)(305945005)(44832011)(316002)(6306002)(336012)(65956001)(65806001)(110136005)(3846002)(966005)(2171002)(2906002)(7736002)(6246003)(6116002)(58126008)(8936002)(16576012)(81156014)(81166006)(33964004)(386003)(76176011)(356004)(5024004)(14444005)(70206006)(186003)(26005)(8676002)(31686004)(70586007)(4326008)(71190400001)(5660300002)(36756003)(22746008)(106002)(30864003)(235185007)(40036005)(22756006)(31696002)(86362001)(478600001)(568964002)(16526019)(569006); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1P18901MB0030; H:mail.ri.se; FPR:; SPF:Pass; LANG:en; PTR:InfoDomainNonexistent; MX:1; A:1; X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: b2e9cbcd-3440-4755-dcd6-08d751791623 X-MS-TrafficTypeDiagnostic: VI1P18901MB0030: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:9508; X-Forefront-PRVS: 01917B1794 X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: M7XF+BRmIanSFxQvJ3SyXIB9L6EDEl7gWHXp7SuJ0GMwsSu7F5bwS+m+DPTOd0Wsid9AisJGDqd/cw+RtINyZN7iU7R6K9LTTn2dZVztKWBNcNgd5MP26rX4xv1+qTgy8OTUM1LQq1zapWRAE64uRZkupYOImrCSfX92a6USmO3s8zg2qGDztQFgIqOmSjJWS0c3c/L9ut66GAlH+/AFYHFZsWSbm3IVAD0U3LTMR4T9yJewaWDfGnUOm06J6IrEAKcC2K3yS0EJwHr26u+s5tYAdosfISfg5js94UAu8nXbbdeFvjNC/Uj5JYknzpawOC6Z2Ud+ZMhfN/imsPiODcmLhu1hjPJlKFTVTaU3x7mIt0kbFVEPfy1A31mdO59KClrY6pSF9Mt+kn1K/OJFOKe8X5+7IQl9C2YA7TwI47k= X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Oct 2019 14:07:58.6745 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: b2e9cbcd-3440-4755-dcd6-08d751791623 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: VI1P18901MB0030 Archived-At: Subject: Re: [Ace] AD review of draft-ietf-ace-oauth-authz-24 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 Oct 2019 14:08:18 -0000 --------------ms070503090608000002070107 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable Hello Ben, thank you for your thorough review. I have taken the liberty to add numbers to your comments in order to=20 refer to them in a easier way. I have fixed 93 your 113 and there are 20 left where I am asking for=20 clarifications. These are: 6.), 12.), 16.), 19.), 34.), 39.), 41.), 45.), 52.), 57.), 58.), 65.), = 66.), 68.), 76.), 78.), 79.), 88.), 99.), 111.) Note that 39.) Requires input from OAuth experts. Hannes? If you whish to inspect the changes made on other review issues, please=20 consult the commits here: https://github.com/ace-wg/ace-oauth/commits/master Detailed comments below. /Ludwig >=20 > Hi all, >=20 > The length of this review notwithstanding, this document is generally i= n > good shape -- there's a bunch of localized items to tighten up, and we > can flesh out the security considerations some more, but nothing too > drastic should be needed. >=20 > 1.) > Perhaps the most far-reaching changes needed > will be to rename the "profile" claim, since that has already been > allocated to OIDC Core for a very different usage. [LS] FIXED. I renamed the "profile" claim and parameters to "ace_profile"= Note that this will require changes in all of the profile drafts as well.= > 2.) > I also made a pull > request with a bunch of trivial editorial stuff that's easier to fix > than describe how to fix, up at > https://github.com/ace-wg/ace-oauth/pull/175 . [LS] Merged. > 3.) > One general note before getting into the section-by-section comments: >=20 > There's a bunch of places where we talk about parameters that "MUST be > mapped to CBOR types as specified in Figure N"; we may want to point to= > the IANA registry as authoritative and just give the figure reference > for description. [LS] FIXED. >=20 > 4.) > Abstract >=20 > 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 >=20 > nit: It's easy to (mis)read this text as saying that just amalgamating > OAuth 2.0 and CoAP magically makes for a solution that is well-known an= d > widely used. I'd suggest rewording slightly, perhaps "thus transformin= g > a well-known and widely used authorization solution into a form suitabl= e > for IoT devices". [LS] FIXED. > 5.) > specifications are used where possible, but where the constraints of= > IoT devices require it, extensions are added and profiles are > defined. >=20 > nit: from a rhetorical point of view, it's probably better to reiterate= > why the extensions are added and profiles defined ("to better serve the= > IoT case") than to just stop with a flat declaration of what is done. [LS] FIXED. > 6.) > Section 1 >=20 > Authorization is the process for granting approval to an entity to > access a resource [RFC4949]. The authorization task itself can best= > be described as granting access to a requesting client, for a > resource hosted on a device, the resource server (RS). This exchang= e >=20 > I had to pause for a while after reading this and ponder whether I > agreed with it. I think that my reticence stems from some friction > between the most generic abstract definition of "resource" and a more > specific one used in the web/HTTP world and, to a lesser extent, the > world of URIs and URNs in general. The resources we are discussing her= e > are not always specific named resources, but can also refer to > attributes or capabilities mediated by a RS; similarly, we may be > creating/modifying named resources as part of the resource access > performed by a client in the OAuth model. I don't think it's wise to > diverge from the RFC 4949 definition just yet, but am still considering= > whether adding some additional clarifying text here is worthwhile. [LS] I would argue that this specification is applicable even to the wide= r definition of "resource" that you are thinking of. Since OAuth 2.0 leaves= the definition of "scope" up to the specific applications, and the ACE framework does not change this, we can deal with both web/HTTP/CoAP=20 resources (named by URIs or URNs) and any other type of resources where the=20 application can map the resource in question to a set of scopes. I am therefore inclined to say that this section is fine, but I'd be glad= to hear the result of your considerations on that matter. > 7.) > Section 3 >=20 > It's probably worth adding (informative) references for HTTP/2, MQTT, > BLE, and QUIC. [LS] FIXED. >=20 > 8.) > A fourth building block is the compact CBOR-based secure message >=20 > "compact CBOR" has the "PIN number" nature and is probably redundant. [LS] FIXED. > 9.) > format COSE [RFC8152], which enables application layer security as a= n > alternative or complement to transport layer security (DTLS [RFC6347= ] >=20 > I'm undecided whether it's better to think of this as "application laye= r > security" or "object-level security". [LS] FIXED. Now that you mention it, I find that "object security" descri= bes COSE better than "application layer security". I have made the=20 appropriate change. >=20 > 10.) > or TLS [RFC8446]). COSE is used to secure self-contained tokens suc= h > as proof-of-possession (PoP) tokens, which is an extension to the > OAuth tokens. The default token format is defined in CBOR web token= >=20 > nit: I think there's a singular/plural mismatch in "is an extension", > which currently seems to be talking about the PoP tokens themselves. [LS] FIXED. > 11.) > Section 3.1 >=20 > Refresh Tokens: > Refresh tokens are credentials used to obtain access tokens. > Refresh tokens are issued to the client by the authorization > server and are used to obtain a new access token when the current= > access token becomes invalid or expires, or to obtain additional > access tokens with identical or narrower scope (access tokens may= > have a shorter lifetime and fewer permissions than authorized by > the resource owner). Issuing a refresh token is optional at the >=20 > nit: I'd suggest "such access tokens" in the parenthetical. [LS] FIXED. > 12.) > A refresh token in OAuth 2.0 is a string representing the > authorization granted to the client by the resource owner. The > string is usually opaque to the client. The token denotes an >=20 > Apparently I'd forgotten that this couldn't be binary. [LS] From RFC 6749, section 1.5: "A refresh token is a string ..." No qualifiers such as "binary" so I interpret this to mean a text-string.= Do you want us to add some clarification? > 13.) > Proof of Possession Tokens: > An access token may be bound to a cryptographic key, which is the= n >=20 > Can refresh tokens not be PoP? [LS] FIXED. I see no problem with refresh tokens using PoP as well. Howev= er note that we have not focused on refresh tokens very much, as we have mos= tly been considering M2M communication, leading to the client credentials gra= nt flow, which in turn makes refresh tokens seem rather superfluous. >=20 > 14.) > The proof-of-possession (PoP) security concept assumes that the A= S > acts as a trusted third party that binds keys to access tokens. >=20 > nit: I think we're describing the PoP model used by ace, not the generi= c > PoP concept. [LS] FIXED: I expanded that paragraph to: "... concept used here ...". > 15.) > Scopes and Permissions: > In OAuth 2.0, the client specifies the type of permissions it is > seeking to obtain (via the scope parameter) in the access token > request. In turn, the AS may use the scope response parameter to= > inform the client of the scope of the access token issued. As th= e > client could be a constrained device as well, this specification > defines the use of CBOR encoding as data format, see Section 5, t= o > request scopes and to be informed what scopes the access token > actually authorizes. >=20 > nit: I think there's a word missing in "the use of CBOR encoding as dat= a > format". [LS] FIXED: "... the use of CBOR encoding, see Section 5, for such reques= ts and responses." > 16.) > Section 3.2 >=20 > One application of COSE is OSCORE [I-D.ietf-core-object-security], > which provides end-to-end confidentiality, integrity and replay > protection, and a secure binding between CoAP request and response > messages. In OSCORE, the CoAP messages are wrapped in COSE objects > and sent using CoAP. >=20 > This framework RECOMMENDS the use of CoAP as replacement for HTTP fo= r > use in constrained environments. >=20 > Do we have a reason to mention OSCORE if we're not going to make a > recommendation about its use? [LS] We also mention DTLS and TLS without making any recommendation about= which to use. I would suggest to either remove all of it or to add a=20 sentence noting that this is an enumeration of some security options, and the choi= ce depends on the specific application scenario. > 17.) > Section 4 >=20 > If the description for step (C) is going to refer to the "profile (see > step B)", then we need to mention the profile as an example of the > Access Information in step (B). [LS] FIXED. > 18.) > The RS > verifies that the token is integrity protected by the AS and > compares the claims contained in the access token with the > resource request. [...] >=20 > I note that this verification of "integrity protected by the AS" > implicitly also includes verification of the source authentication > (i.e., signature or keyed MAC in key known only to AS and RS, in the > non-introspection case); do we want to make that more explicit in the > text? [LS] FIXED. Yes. >=20 > 19.) > Section 5 >=20 > Credential Provisioning > For IoT, it cannot be assumed that the client and RS are part of = a > common key infrastructure, so the AS provisions credentials or > associated information to allow mutual authentication. These > credentials need to be provided to the parties before or during > the authentication protocol is executed, and may be re-used for > subsequent token requests. >=20 > nit: either "before or during the execution of the authentication > protocol" or "before or during the authentication protocol's execution"= =2E > And just to double-check that we mean the authentication protocol of > provisioning in the last sentence, not the authorization protocol that > occurs between the client and RS. [LS] The whole last sentence was a bit off. I would suggest: "The resulting security association between client and RS may then be=20 re-used by binding these credentials to additional access tokens." Does that sound better? > 20.) > OAuth 2.0 requires the use of TLS both to protect the communication > between AS and client when requesting an access token; between clien= t > and RS when accessing a resource and between AS and RS if > introspection is used. In constrained settings TLS is not always > feasible, or desirable. Nevertheless it is REQUIRED that the data > exchanged with the AS is encrypted, integrity protected and protecte= d > against message replay. It is also REQUIRED that the AS and the > endpoint communicating with it (client or RS) perform mutual > authentication. [...] >=20 > This seems to leave open the possibility that client/RS interactions ar= e > not encrypted, integrity protected, and/or replay protected; is that > intentional? (We do require later on that all resource access gets the= > "usual protections" other than the authz-info endpoint, so this is > mostly just an editorial remark.) [LS] FIXED. No this was not intentional. Except for the authz-info endpoi= nt, the same requirements should be applied to C-RS communication. >=20 > 21.) > In OAuth 2.0 the communication with the Token and the Introspection > endpoints at the AS is assumed to be via HTTP and may use Uri-query > parameters. When profiles of this framework use CoAP instead, this > framework REQUIRES the use of the following alternative instead of >=20 > nit: REQUIRES is not an RFC 2119 keyword (just REQUIRED). [LS] FIXED. > 22.) > Uri-query parameters: The sender (client or RS) encodes the > parameters of its request as a CBOR map and submits that map as the > payload of the POST request. Profiles that use CBOR encoding of > protocol message parameters MUST use the media format 'application/ > ace+cbor', unless the protocol message is wrapped in another Content= - > Format (e.g. object security). [...] >=20 > Is the bit starting at "Profiles that use CBOR" directly tied to the > CBOR-map submission to the AS, or a more general requirement on all > protocol flows (that would better be split off in its own paragraph)? [LS] FIXED. I split the scond part off into its own paragraph. > 23.) > Also, some IESG members have not liked the "MUST [...], unless [...]" > construction, as it makes the MUST "no longer a MUST". So perhaps we > could rephrase this as a positive statement, such as "CBOR-encoded > protocol messages that appeare at the outermost encoding layer MUST use= the > media type "application/ace+cbor or, for CoAP, the corresponding > Content-Format's short ID of 19". [LS] FIXED. > 24.) > Section 5.1 >=20 > Instead of the initial Unauthorized Resource Request message, other > discovery methods may be used, or the client may be pre-provisioned > with the address of the AS. >=20 > nit: I suggest "pre-provisioned with an RS-to-AS mapping" so that we > don't have the "the AS" construct that implies there is only a single > AS. [LS] FIXED. > 25.) > Section 5.1.1 >=20 > Note: These conditions ensure that RS can handle requests > autonomously once access was granted and a secure channel has been > established between C and RS. The authz-info endpoint MUST NOT be > protected as specified above, in order to allow clients to upload > access tokens to RS (cf. Section 5.8.1). >=20 > I have some editorial suggestions here that I'll put into a pull reques= te. [LS] merged. > 26.) > Section 5.1.2 >=20 > It may not be worth having an attempt at a printable version of the > cnonce in the comments in Figure 4. [LS] FIXED. >=20 > 27.) > Section 5.1.2.1 >=20 > o A RS sending a "cnonce" parameter in an an AS Request Creation > Hints message MUST store information to validate that a given > cnonce is fresh. How this is implemented internally is out of > scope for this specification. Expiration of client-nonces should= > be based roughly on the time it would take a client to obtain an > access token after receiving the AS Request Creation Hints > message. >=20 > nit: I suggest to add something like "with some allowance for slop". [LS] FIXED. > 28.) > Section 5.2 >=20 > The grant type is selected depending on the use case. In cases wher= e > the client acts on behalf of the resource owner, authorization code > grant is recommended. If the client acts on behalf of the resource > owner, but does not have any display or very limited interaction > possibilities it is recommended to use the device code grant defined= > in [I-D.ietf-oauth-device-flow]. In cases where the client does not= > acts autonomously the client credentials grant is recommended. >=20 > The context seems to suggest that this last sentence was intended as > "cases where the client acts autonomously"; is that correct? [LS] FIXED. Indeed that was a typo. > 29.) > Section 5.5 >=20 > well. Non-constrained clients interacting with constrained resource= > servers can use the specifications in section 3.1 of [RFC6749] and o= f > section 4.2 of [RFC6819]. >=20 > nit: Section 4.2 of RFC 6819 isn't exactly a "specification" per se; we= > might want to reword this. [LS] FIXED. > 30.) > Section 5.6 >=20 > For the AS to be able to issue a token, the client MUST be > authenticated and present a valid grant for the scopes requested. > Profiles of this framework MUST specify how the AS authenticates the= > client and how the communication between client and AS is protected.= >=20 > We should probably list what attributes this protection entails -- > confidentiality+integrity, of course, and we already mentioned both > sides of the mutual authentiation; do we need anything else like replay= > protection? [LS] FIXED. The requirements made in the heading of section 5 apply specifically here (confidentiality, integrity, mutual AuthN, replay-protection, request/response binding). I changed the text to=20 point that out. > 31.) > The default name of this endpoint in an url-path is '/token', howeve= r > implementations are not required to use this name and can define > their own instead. >=20 > We may get questions about the relationship between this "default" and > BCP 190; unfortunately, I haven't had a time to internalize the changes= > proposed for draft-nottingham-rfc7320bis yet to see whether they would > affect us. (To be clear, "leave it as-is for now and see if we get > complaints from the experts" is the right thing to do.) [LS] Noted. > 32.) > Section 5.6.1 >=20 > The client sends a POST request to the token endpoint at the AS. Th= e > profile MUST specify how the communication is protected. The conten= t >=20 > In the previous section we said that maybe even other transports than > coaps or https would be possible; are we limited to those that have POS= T > verbs? > Also, a similar comment as above about what attributes the protection > entails seems to apply. [LS] This will need a major rephrasing of the text. I see two options here: 1.) We rewrite all parts to use a neutral language in general and specify= POST/GET etc. for transports that have these verbs. 2.) We state in the beginning that transports that do not use RESTful ver= bs should use the best equivalent. Option 1. would get a bit cluncky, while option 2. might be a bit confusi= ng Do you have a specific preference? > 33.) > o The "scope" parameter MAY be encoded as a byte string instead of > the string encoding specified in section 3.3 of [RFC6749], in > order allow compact encoding of complex scopes. >=20 > "scope" is a space-separated list (in the string encoding); is 0x20 > still the list separator in the binary encoding? [LS] FIXED. I added a clarification that the syntax of a binary encoding = is up to profiles or applications and that it does not necessarily use 0x20 = as scope-token delimiter (see e.g. draft-bormann-core-ace-aif). > 34.) > o A client MUST be able to use the parameters from > [I-D.ietf-ace-oauth-params] in an access token request to the > token endpoint and the AS MUST be able to process these additiona= l > parameters. >=20 > [we might get someone complaining that if support for these is mandator= y > they might as well be in the core document. I don't mind the split, bu= t > be forewarned.] [LS] The split came to pass since some parameters were expected to become= obsolete with some ongoing OAuth work and we wanted to have a document th= at was independent from the core that could be overridden. I'm not sure this still applies, since the main culprit was the "resource= " parameter defined in OAuth-resource-indicators. The remaining "req_cnf" parameter for requesting specific confirmation claims might become=20 obsolete if the OAuth WG takes up their PoP work again. > 35.) > Figure 5: Example request for an access token bound to a symmetric > key. >=20 > I wouldn't be surprised is some reviewers asked for more text to clarif= y > that the AS-generated symmetric key is the default, so we don't need an= y > extra parameters to indicate that's what's being requested. [LS] Point taken. I will add some text to clarify that this is the defaul= t behaviour. > 36.) > I'm a little surprised that OSCORE didn't provide some more scrutable > diagnostic notation for the OSCORE CoAP option. To check: h is set, n = is 1, > k is not set, the (1-byte) partial IV is 0x05, s is 5, and the rest of > the option is the kid context? [LS] FIXED. I added a decoded version in paratheses for the reader's convenience and make a note about it. Note that I took the opportunity to= simplify the OSCORE option somewhat since the original example was somewh= at intricate. > 37.) >=20 > Figure 7 shows a request for a token where a previously communicated= > proof-of-possession key is only referenced. Note that the client > performs a password based authentication in this example by > submitting its client_secret (see Section 2.3.1 of [RFC6749]). Note= >=20 > RFC 6749 says about the bare "client_secret" that "[i]ncluding the > client credentials in the request-body using the two parameters is NOT > RECOMMENDED and SHOULD be limited to clients unable to directly utilize= > the HTTP Basic authentication scheme (or other password-based HTTP > authentication schemes)." I know this is "just an example", so our > obligations are somewhat weak, but I still think we should note that > this is not recommended by 6749 (but since there is no CoAP analogue of= > HTTP Basic, it's the only plain-password scheme available). [LS] My take is to modify this example and remove the client_secret part.= It feels wrong to use NOT RECOMMENDED stuff, even if it only is an exampl= e. > 38.) >=20 > that this example uses the "req_cnf" parameter from > [I-D.ietf-ace-oauth-params]. >=20 > Er, the "req_cnf" parameter is exactly how the previously communicated > key is being referenced. So we should not have a separate "Note" that > doesn't link back to the point of the example. [LS] FIXED. > 39.) > Refresh tokens are typically not stored as securely as proof-of- > possession keys in requesting clients. Proof-of-possession based > refresh token requests MUST NOT request different proof-of-possessio= n > keys or different audiences in token requests. Refresh token > requests can only use to request access tokens bound to the same > proof-of-possession key and the same audience as access tokens issue= d > in the initial token request. >=20 > This is perhaps something of a philosophical question, but if a refresh= > token is only usable at the token endpoint, in some sense its audience > is definitionally the AS. So there's a little bit of a mismatch in > treating it as having the audience value that the access tokens issued > from it will have. I don't know the background for audience-restriced > refresh tokens in regular OAuth 2.0, though, so hopefully someone can > educate me. [LS] I'm equally confused. I suggest that Hannes or one of the other OAut= h experts give us a hint on that one. > 40.) > Section 5.6.2 >=20 > Note that the AS decides which token type and profile to use when > issuing a successful response. It is assumed that the AS has prior >=20 > Would it be useful to note that this can be shaped by the "req_cnf" > contents? [LS] I don't think token type would be affected by the requested=20 confirmation key format. The selected profile however may well be. A note to this=20 effect has been added. >=20 > 41.) > token_type: > This parameter is OPTIONAL, as opposed to 'required' in [RFC6749]= =2E > By default implementations of this framework SHOULD assume that > the token_type is "pop". If a specific use case requires another= > token_type (e.g., "Bearer") to be used then this parameter is > REQUIRED. >=20 > When we are "weakening" the formal requirements of the parent spec like= > this, we should be careful about what happens when someone is trying to= > use the ACE stuff but ends up needing to go over HTTPS like traditional= > OAuth -- do they have to fall back to the OAuth required behavior in > that case or are we trying to preempt that as well? [LS] The use case here is a constrained connection between client and AS (e.g. due to a constrained client), where we try to save the bytes for sending a token_type by defining a default. I would guess that a HTTPS ba= sed connection would not have such constraints and would therefore be able=20 to send the token_type =3D "pop" as required by RFC6749. Should we explain this=20 somewhere and describe the cases where RFC6749 behaviour is warranted? >=20 > 42.) > Given that we're requiring support for them, I think including the > parameters from draft-ietf-ace-oauth-params in Figure 8 (and removing > the note above it) would be helpful to the reader. We probably also > want to leave some room for future extensions when we talk about it > ("summarizes the parameters that may be part of the Access Information"= > could maybe be read as restrictive, though it's clearly not meant to > be). [LS] FIXED > 43.) > "cnf" : { > "COSE_Key" : { > "kty" : "Symmetric", > "kid" : b64'39Gqlw', > "k" : b64'hJtXhkV8FJG+Onbc6mxCcQh' > } > } > } >=20 > Figure 9: Example AS response with an access token bound to a > symmetric key. >=20 > In light of the related discussion on cwt-proof-of-possession (resultin= g > in the removal of a bunch of text), do we want to say anything about th= e > scope of the 'kid' (that is, which participants are expecting to receiv= e > and understand that value)? [LS] FIXED > 44.) > Section 5.6.3 >=20 > The error responses for CoAP-based interactions with the AS are > equivalent to the ones for HTTP-based interactions as defined in > Section 5.2 of [RFC6749], with the following differences: >=20 > "equivalent [...] with the following differences" is going to get > complaints from the IESG. I suggest "generally equivalent". [LS] FIXED > 45.) > o A response code equivalent to the CoAP code 4.00 (Bad Request) > MUST be used for all error responses, except for invalid_client > where a response code equivalent to the CoAP code 4.01 > (Unauthorized) MAY be used under the same conditions as specified= > in Section 5.2 of [RFC6749]. >=20 > 6749 has a case where 401 MUST be used, but I think it does not apply t= o > us (since WWW-Authenticate would have to have been used). I'm not sure= > whether it makes sense to note that or not, though. [LS] The 401 in 6749 is the invalid_client case. For CoAP a 4.01 is also allowed (MAY) instead of 4.00 if this is warranted. I do not believe furt= her action is warranted at this point. Do you agree? > 46.) > Section 5.6.4.3 >=20 > responses. Furthermore profiles MUST define proof-of-possession > methods, if they support proof-of-possession tokens. >=20 > nit: define the *methods* or the *list* of allowed ones? [LS] FIXED. The latter. > 47.) > A profile MUST specify an identifier that MUST be used to uniquely > identify itself in the "profile" parameter. The textual > representation of the profile identifier is just intended for human > readability and MUST NOT be used in parameters and claims. >=20 > This seems like an opportunity for a registry...just like we have in > Section 8.7. I'd suggest mentioning that registry here. [LS] FIXED. > 48.) > Section 5.6.5 >=20 > Perhaps the title of Figure 12 should include both requests and > responses? [LS] FIXED. > 49.) > Section 5.7.1 >=20 > map with a "token" entry containing either the access token or a > reference to the token (e.g., the cti). Further optional parameters= > [...] > The same parameters are required and optional as in Section 2.1 of > [RFC7662]. >=20 > This seems somewhat problematic, in that 7662 is pretty clear that the > "token" value is, well, the actual token. So if we want to be able to > use "cti" instead, then we need to have some text saying that we're > deviating from 7662 and the specification for how "cti" is used there. [LS] FIXED. Actually the phrasing here was simply bad, what I tried to=20 express was that there are token types that are simply a reference to claims held= by the AS (i.e. not self-contained). I have changed the text to be correct. > 50.) > { > "token" : b64'7gj0dXJQ43U', > "token_type_hint" : "pop" > } >=20 > Figure 14: Decoded token. >=20 > nit: I think this is a decoded payload, not a decoded token. [LS] FIXED > 51.) > Section 5.7.2 >=20 > cnonce OPTIONAL. A client-nonce previously provided to the AS by > the RS via the client. See Section 5.6.4.4. >=20 > I think this statement is only true after the token in question has bee= n > properly validated at the RS. Before that, all we can say is that it i= s > the client-nonce provided to the AS by the client, since there is > nothing to enforce that the client actually provided the same value tha= t > was generated by the RS. [LS] FIXED. I've added some clarification text. > 52.) > Section 5.7.4 >=20 > "scope" is showing up with the key 9 a lot; I have mixed feelings about= > having the CBOR map key value be aliased across different contexts (but= > it's probably too late to change without disruption anyway). [LS] Scope is used in 4 places: I. AS Request Creation Hints II. /token request and response parameter III. CWT claim IV. /introspection response parameter I claim that in all 4 cases we expect the same content with the same formatting and semantics: I. tells the client what to put into II. which in turn informs the AS about the requested claim value in III. and IV. is supposed to reflect that claim value. I therefore don't feel hesitant to use the same abbreviation for all four cases. Is that acceptable or do you whish us to perform any action on this? > 53.) > Section 5.8 >=20 > In order to facilitate offline processing of access tokens, this > document uses the "cnf" claim from > [I-D.ietf-ace-cwt-proof-of-possession] and specifies the "scope" > claim for JWT- and CWT-encoded tokens. >=20 > [looks like draft-ietf-oauth-token-exchange is going to beat us for the= > JWT version of "scope": > https://www.iana.org/assignments/jwt/jwt.xhtml#claims ] [LS] Agree, I will change the whole document to refer to this registratio= n instead. Life punishes those who come too late. > 54.) > The "scope" claim explicitly encodes the scope of a given access > token. This claim follows the same encoding rules as defined in > Section 3.3 of [RFC6749], but in addition implementers MAY use byte > strings as scope values, to achieve compact encoding of large scope > elements. The meaning of a specific scope value is application > specific and expected to be known to the RS running that application= =2E >=20 > I think I commented above about the use of 0x20 as the list separator; > whatever we do there should be applied here as well (or the text > otherwise consolidated to only need to say it once). [LS] FIXED. This got removed, as we no longer specify the scope claim. I added text though to specify that even the scope claim could be binary.= > 55.) > Section 5.8.1 >=20 > The access token, containing authorization information and > information about the key used by the client, needs to be transporte= d > to the RS so that the RS can authenticate and authorize the client > request. >=20 > nit(?): do we want to talk about the "confirmation method" rather than > the "key", out of some sense of remaining generic? [LS] I agree. FIXED. > 56.) > This specification RECOMMENDS that an RS stores only one token per > proof-of-possession key, meaning that an additional token linked to > the same key will overwrite any existing token at the RS. >=20 > I might consider mentioning that this greatly simplifies implementation= , > as not only is there not a need for the extra storage, but when a > request comes in using a given key, there's no need to resolve which > token to use with that request (and whether there would be different > access decisions made depending on which token was used), since the key= > can be used directly for dispatch (e.g., with DTLS raw public key). [LS] FIXED. Comment added > 57.) > If the payload sent to the authz-info endpoint does not parse to a > token, the RS MUST respond with a response code equivalent to the > CoAP code 4.00 (Bad Request). >=20 > Do we want this to specifically be about "parse to a token" with no nee= d > to be a valid token? (What error do we return for a syntactically vali= d > but semantically invalid token?) [LS] This is intentional. Syntactically valid but semantically invalid=20 tokens are dealt with in section 5.8.1.1 including detailed instructions on the = error messages to be returned. >=20 > 58.) > Profiles MUST specify whether the authz-info endpoint is protected, > including whether error responses from this endpoint are protected. > Note that since the token contains information that allow the client= > and the RS to establish a security context in the first place, mutua= l > authentication may not be possible at this point. >=20 > We'll need some careful reasoning about this for the security > considerations, since the authz-info transaction can impact what profil= e > the RS thinks is in use. E.g., whether a network attacker could > cause the client to think that a different (vulnerable) profile is in > use than the one the RS expects to use. [LS] Noted. Do you think the reasoning in section 6.5 needs to be extende= d? > 59.) > The RS MAY make an introspection request to validate the token befor= e > responding to the POST request to the authz-info endpoint. > [...] > A RS MAY use introspection on a token received through the authz-inf= o > endpoint, e.g. if the token is an opaque reference. Some transport >=20 > We should probably deduplicate the "MAY use introspection"s. [LS] FIXED. > 60.) > Section 5.8.1.1 >=20 > I think we whould make an explicit note at the end of the list of claim= s > that we specify processing for, that additional processing is done (in = a > profile-specific manner?) for other claims in the token. [LS] FIXED. > 61.) > If the access token contains any other claims that the RS cannot > process the RS MUST discard the token. If this was an interaction >=20 > Just to double-check: this is overriding the JWT/CWT default so that al= l > token claims are comprehension-mandatory? It might be worth making thi= s > deviation from the core [JC]WT more explicitly a deviation. [LS] FIXED. That was not intentional. I removed that part. > 62.) > Section 5.8.2 >=20 > If an RS receives a request from a client, and the target resource > requires authorization, the RS MUST first verify that it has an > access token that authorizes this request, and that the client has > performed the proof-of-possession for that token. >=20 > As written, this sounds like it's okay to only do proof-of-possession > when posting tokens to the authz-info endpoint and not bind the > proof/key to the current request. Is that intended? [LS] FIXED. No, I've added some clarification >=20 > 63.) > The response code MUST be 4.01 (Unauthorized) in case the client has= > not performed the proof-of-possession, or if RS has no valid access > token for the client. If RS has an access token for the client but > not for the resource that was requested, RS MUST reject the request >=20 > nit: I suggest "but the token does not authorize access for". [LS] FIXED. > 64.) > Section 5.8.3 >=20 > o The RS verifies the validity of the token by performing an > introspection request as specified in Section 5.7. This requires= > the RS to have a reliable network connection to the AS and to be > able to handle two secure sessions in parallel (C to RS and AS to= > RS). >=20 > nit: isn't the second one RS to AS, not AS to RS? [LS] FIXED. >=20 > 65.) > specification defines the following approach: The claim "exi" > ("expires in") can be used, to provide the RS with the lifetime o= f > the token in seconds from the time the RS first receives the > token. This approach is of course vulnerable to malicious client= s > holding back tokens they do not want to expire. Such an attack >=20 > It also has suboptimal behavior if the RS loses state (e.g., by > rebooting), and possibly requires the RS to store indefinitely all > tokens with an "exi" value. I have mixed feelings about specifying it > at all, though I concede it probably does have some value. Regardless,= > I think a dedicated subsection in the security considerations is in > order. [LS] We wanted to provide some solution for expiring tokens for RSes=20 that have no connectivity and no synchronized clocks. Using the "exp" claim in=20 such cases would have pretty unpredictable results. I have extended section 6.3 in the security considerations to go into=20 the detail of "exi", please have a look if this covers the necessary issues. > 66.) > Section 5.8.4 >=20 > The AS provides the client with key material that the RS uses. 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 no >=20 > Can you walk me through how a symmetric PoP key would be used for mutua= l > authentication (i.e., authentication of RS to client)? It's easy/commo= n > to do the PoP the other way, making the client prove it knows the key > associated with the token, but the other direction is not always > possible, depending on the protocol. [LS] The reasoning is that if both client and RS perform a=20 proof-of-possession of the symmetric PoP key to each other, they can be considered to be mutuall= y authenticated, under the provision that no other parties (except for the = AS) have access to said key. My understanding is that e.g. DTLS-PSK provides=20 this kind of guarantee. Do you want us to clarify this reasoning in the document? > 67.) > o The client knows a default validity period for all tokens it is > using. This information could be provisioned to the client when > it is registered at the AS, or published by the AS in a way that > the client can query. >=20 > Just to double-check: this validity period is time since issuance? I'm= > not sure whether this is sufficiently obvious that it goes without > saying (but it might be). [LS] FIXED. Yes time since issuance is what is meant. I have added some clarification. > 68.) > o The client performs an introspection of the token. Although this= > is not explicitly forbidden, how exactly a client does > introspection is not currently specified for OAuth. >=20 > I'm pretty sure this is overtaken by events (sorry for my part in > that!). E.g., draft-ietf-oauth-jwt-introspection-response discusses > clients doing introspection, and even RFC 7662 itself discusses using a= > client secret to authenticate to the introspection endpoint. I think > there's another document between those two that's also relevant, but > can't find it right now [LS] I am not so sure. When reading the fine print in both RFC 7662 and draft-ietf-oauth-jwt-introspection-response, I find that when they mentio= n the term "client", they refer to the protected resource / RS as being a=20 client of the AS introspection endpoint. A client holding an access token and=20 performing introspection is never explicitly mentioned in both=20 documents, to my best knowledge. > 69.) > Section 6 >=20 > There could perhaps be some security considerations relating to > discovery of RSes/resources thereon, but since we don't really talk > about that much to begin with, it's probably okay to skip the security > considerations discussion as well. [LS] Noted. I opt to skip this for the time being. If it comes up in the = IESG review we can revisit this issue. > 70.) > Both the client and the RS need to have their own respective long-term > credentials with the AS; we should talk about protecting those > credentials, what is risked/lost if the credentials are compromised, > how to recover from compromise, and the general key management > lifecycle (per BCP 107). [LS] FIXED. I added a subsection and also restructured the body of sectio= n 6 into several additional subsections (the current structure had some=20 seemingly arbitrary material in the body of section and other material in=20 subsections). > 71.) > We should probably mention revocation in some fashion (even if only to > say that it's unlikely in practice) -- right now we just have one > passing mention as an optional responsibility of the AS, in Appendix B.= [LS] FIXED. I have added a paragraph in the section on token protection, with a reference to RFC 7009.Most revocation scenarios are neither=20 covered in OAuth and in ACE though. >=20 > 72.) > A large range of threats can be mitigated by protecting the contents= > of the access token by using a digital signature or a keyed message > digest (MAC) or an Authenticated Encryption with Associated Data >=20 > I won't be surprised if someone asks for examples of that "large range > of threats", so be prepared to answer... [LS] Noted. I take it that no action is required here at this point. > 73.) > (AEAD) algorithm. Consequently, the token integrity protection MUST= > be applied to prevent the token from being modified, particularly > since it contains a reference to the symmetric key or the asymmetric= > key. [...] >=20 > nit: "key used for proof of possession" (though my previous remark abou= t > limiting to keys may apply as well). [LS] FIXED. > 74.) > key. If the access token contains the symmetric key, this symmetric= > key MUST be encrypted by the authorization server so that only the > resource server can decrypt it. Note that using an AEAD algorithm i= s > preferable over using a MAC unless the message needs to be publicly > readable. >=20 > nit(?) is "the message" here still "the token" like it was for the rest= > of the paragraph? [LS] FIXED. Indeed in this context "the token" is what is meant. > 75.) > If the token is intended for multiple recipients (i.e. an audience > that is a group), integrity protection of the token with a symmetric= > key is not sufficient, since any of the recipients could modify the > token undetected by the other recipients. Therefore a token with a >=20 > I can't decide whether we should clarify that this is "integrity > protection of the token with a symmetric key shared by the AS and RS" > (as opposed to a symmetric PoP key). [LS] FIXED. I added a clarification. > 76.) > It is important for the authorization server to include the identity= > of the intended recipient (the audience), typically a single resourc= e > server (or a list of resource servers), in the token. Using a singl= e > shared secret with multiple resource servers to simplify key > management is NOT RECOMMENDED since the benefit from using the proof= - > of-possession concept is significantly reduced. >=20 > I think we should word this more clearly with respect to "single shared= > secret" -- is this the credential used by the RS to authenticate itself= > to the client? I'm not even sure if this text is intended to be > describing a workflow using symmetric or asymmetric keys. [LS] I added some clarification. Can you double-check that this makes more sense? > 77.) > Profiles MUST specify how confidentiality protection is > provided, and additional protection can be applied by encrypting the= > token, for example encryption of CWTs is specified in Section 5.1 of= > [RFC8392]. >=20 > We should probably be a little more precise about what the additional > protection is -- it's not exactly protection for the PoP key, since > that's transmitted alongside the token in the authorization info (i.e.,= > outside the token contents), but it does provide protection when the > token is subsequently used. > also, nit: comma splice [LS] FIXED. > 78.) > Section 6.1 >=20 > I think we should have a little bit more discussion about what attacks > are possible even when a client hard-codes a list of trustworthy ASes, > e.g., when a device in one AS's purview is compromised and tries to get= > the client to use a different (possibly also compromised, or maybe just= > buggy) AS than the one that's supposed to be responsible for the device= > in question. In short, yes, spoofing is only possible within that set > of trusted ASes, but spoofing can still cause problems. [LS] I have added some text in section 6.FIXME Please have a look if this= covers what you were aiming at. > 79.) > Are there any AS parameters other than URI that might be useful for an > out-of-band-configured list of valid values? [LS] One might want to include the public key or certificate of the AS. Do you want us to expand this section to include such parameters? > 80.) > Section 6.2 >=20 > client MUST be able to determine whether an AS has the authority > to issue access tokens for a certain RS. This can be done throug= h > pre-configured lists, or through an online lookup mechanism that > in turn also must be secured. >=20 > nit: I suggest "for example" to preempt anyone complaining about this > being needlessly prescriptive. [LS] FIXED > 81.) > Section 6.4 >=20 > There may be use cases were different profiles of this framework are= > combined. For example, an MQTT-TLS profile is used between the > client and the RS in combination with a CoAP-DTLS profile for > interactions between the client and the AS. Ideally, profiles shoul= d > be designed in a way that the security of system should not depend o= n > the specific security mechanisms used in individual protocol > interactions. >=20 > I think the IESG is going to pounce on this "ideally" -- what can we do= > to ensure this is the case and/or warn when it isn't? Can we just > say that profiles MUST NOT make assume that the same profile is used fo= r > the different types of interactions? [LS] FIXED. I used this phrasing: "The security of a profile MUST NOT depend on the assumption that the=20 profile is used for all the different types of interactions in this framework. >=20 > 82.) > Section 6.6 >=20 > inadvertently communicating with the wrong RS. The correct values > for "audience" can either be provisioned to the client as part of it= s > configuration, or provided by the RS as part of the "AS Request > Creation Hints" Section 5.1.2 or dynamically looked up by the client= >=20 > I'm not sure that the AS Request Creation Hints are a big help here, > since they are untrusted input and it seems like bogus hints could caus= e > the client to obtain a token for a "wrong" RS. [LS] FIXED > 83.) > Section 6.7 >=20 > First an attacker could perform a denial of service attack against > the introspection endpoint at the AS in order to prevent validation > of access tokens. To mitigate this attack, an RS that is configured= > to use introspection MUST NOT allow access based on a token for whic= h > it couldn't reach the introspection endpoint. >=20 > I'm not sure that "mitigate" is quite right, as the attack (denial of > service) succeeds! Probably we want something like "To maintain the > security of the system" instead. > nit: comma after First (and Second, in the next paragraph). [LS] FIXED > 84.) > an introspection call. RS can mitigate such attacks by implementing= > a rate limit on how many introspection requests they perform in a > given time interval and rejecting incoming requests to authz-info fo= r > a certain amount of time, when that rate limit has been reached. >=20 > I think the rate limit can be partially per client IP address (but a > global limit will probably still be necessary, too). [LS] FIXED > 85.) > Section 7 >=20 > Introspection could potentially output a lot of information from a give= n > token; some of the claims that might be found in a JWT or CWT can have > privacy considerations. Though for constrained usage, it is likely tha= t > the claims set will be pretty stripped down, so that might be more of a= n > exceptional case. (When signed-only CWT/JWT are used, similar > considerations apply to the same claims, which is mostly covered alread= y > under the "if access tokens are only integrity protected" part. [LS] FIXED. I added a section stressing the possible privacy concerns of = token claims in general, whether they are obtained by processing the payload of= a self-contained token or by introspection. >=20 > 86.) > information as possible in an unencrypted response. Means of > encrypting communication between C and RS already exist, more > detailed information may be included with an error response to > provide C with sufficient information to react on that particular > error. >=20 > nit: I think the sentence is supposed to start with "When" or "If". [LS] FIXED >=20 > 87.) > Section 8.X >=20 > I might consider adding a sentence to the toplevel Section 8 that notes= > "this document creates several registries with a registration policy of= > Expert Review; guidelines to the experts are given in Section 8.16" so > that we have a heads-up that these guidelines exist while we're reading= > through the rest of the sections. Though, perhaps most people aren't > reading it straight through like I am... [LS] FIXED >=20 > 88.) > Section 8.3 >=20 > Name The OAuth Error Code name, refers to the name in Section 5.2. > of [RFC6749], e.g., "invalid_request". >=20 > We should refer to the OAuth registry as the authority on names, not th= e > immutable RFC. (Similarly for the other mappings registries; I won't > repeat it each time, though for the later ones we're already doing the > right thing.) [LS] This is interesting. The referenced section (5.2 of RFC6749) is not mirrored in any IANA registry. I have put the question to the OAuth WG. > 89.) > Section 8.5 >=20 > We should check what capitalization we want for the token type name, as= > it's used all-lowercase elsewhere in the document but appears here as > "PoP". [LS] FIXED. I'll align with the use in RFC 7800 which is PoP. > 90.) > Section 8.9 >=20 > Note that the mappings of parameters corresponding to claim names > intentionally coincide with the CWT claim name mappings from > [RFC8392]. >=20 > I tried to spot-check this but couldn't find any that match up; am I > looking in the wrong place? [LS] FIXED. This used to be the case for "aud", "scope" and "cnf" but ha= s since then intentionally been discontinued when the "aud" /token=20 parameter was replaced by the "audience" parameter. "scope" and "cnf" are still aligned= =2E I have removed this comment altogether instead of some convoluted=20 explanation. > 91.) > Section 8.11 >=20 > Reference This contains a pointer to the public specification of th= e > grant type abbreviation, if one exists. >=20 > Do we have some copy/paste issue with the "grant type abbreviation" > going on here (and elsewhere)? [LS] FIXED. How embarrassing. > 92.) > Section 8.12 >=20 > "scope" is already registered by draft-ietf-oauth-token-exchange (for > the same meaning). > "profile" is already registered by OIDC Core, for a "profile page URL".= > So we will probably have to change to (e.g.) "ace_profile" everywhere. [LS] DUPLICATE. Scope was fixed as part of comment 53. and profile as=20 part of comment 1. > 93.) > Section 8.13 >=20 > The entry for "scope" should maybe also point to the oauth draft that > defined it for JWT. >=20 > (We can't get "profile" here, either.) [LS] DUPLICATE. Scope was fixed as part of comment 53. Profile as part of= 1. > 94.) > Section 8.14 >=20 > I think for the media type we still want to use the IESG as the contact= =2E >=20 [LS] FIXED. I was just unsure here and used the CoAP RFC as a template. > 95.) > Section 8.16 >=20 > o Specifications are required for the standards track range of poin= t > assignment. Specifications should exist for specification > required ranges, but early assignment before a specification is > available is considered to be permissible. Specifications are >=20 > This seems to be attempting to re-explain things already in RFC 8126, > but introduces some divergence along the way (which is bad). I do note= > that RFC 7120 covers early allocations, but specifically excludes doing= > so from Expert Review registries. I think technically that would > exclude using the early allocation procedure even for the "standards > action" or "specification required" ranges, though the experts would > still have leeway to make allocations under essentially the same > circumstances. [LS] FIXED. I removed that bullet. (note: RFC 8152 has the same text, which is entirely coincidental ahem...) >=20 > 96.) > document cannot have points assigned outside of that range. The > length of the encoded value should be weighed against how many > code points of that length are left, the size of device it will b= e > used on, and the number of code points left that encode to that > size. >=20 > seems to duplicate "number of code points of that length that are left"= =2E [LS] FIXED. Note that this error appears in RFC 8152 as well (for some reason ;-) ). > 97.) > Section 10.1 >=20 > We may get some debate about whether IANA registries are properly > Normative of Informative references, but we can wait for that to happen= > -- no need to do anything now. [LS] Noted. Does the AD have a position on this? > 98.) > Section 10.2 >=20 > If we're using RFC 4949 for terminology definitions, I think that makes= > it a normative reference. >=20 > If we REQUIRE CBOR when used with CoAP, that also feels like a normativ= e > reference. >=20 > I also think 7519 needs to be normative, since we mandate some of its > processing rules. [LS] RFC 4949 is informational, so it cannot be normative. I would argue that we are just using it to clarify the meaning of our terminology. I agree with the other two and have FIXED that. > 99.) > Appendix A >=20 > Proof-of-Possession: >=20 > This framework makes use of proof-of-possession tokens, using the= > "cnf" claim [I-D.ietf-ace-cwt-proof-of-possession]. A > semantically and syntactically identical request and response > parameter is defined for the token endpoint, to allow requesting > and stating confirmation keys. This aims at making token theft >=20 > nit: the wording here is a little weird in terms of specifying what is > identical. I'm not sure I have a great suggestion for improvement, > though; what I'm coming up with is a lot more words. [LS] How about: A request parameter "cnf" and a Response parameter "cnf", both having a value space semantically and syntactically identical to the "cnf" claim, are defined for the token endpoint, to allow requesting and stating confirmation keys. > 100.) > Appendix C >=20 > Skimming through the main text, a couple more items we may want to list= > here: >=20 > - optional procedures for client discovery of RS/resources/permissions > (Section 4) > - optionally define new grant types (Section 5.2) > - optional use of client certificate as client credentials (Section 5.3= ) [LS] FIXED > 101.) > o Specify the security protocol the client and RS must use to > protect their communication (e.g., OSCORE or DTLS over CoAP). >=20 > IIRC both DTLS over CoAP and CoAP over DTLS are defined; do we need > specifically one of them? [LS] no. FIXED. >=20 > 102.) > Appendix D >=20 > o The symmetric key shared between client or RS and AS (if any). >=20 > I suggest splitting this into separate bullet points for client/AS and > RS/AS, to avoid chance of confusion. [LS] FIXED. > 103.) > Appendix E.1 >=20 > the Access Information contains the public key of the RS. For > communication security this example uses DTLS RawPublicKey betwee= n > the client and the RS. The issued token will have a short > validity time, i.e., "exp" close to "iat", to protect the RS from= > replay attacks. The token includes the claim such as "scope" wit= h >=20 > With DTLS RPK I don't think replay is a huge concern; the short lifetim= e > seems more of a bound on how soon the authorization might be > invalidated. [LS] Agree. FIXED. > 104.) > In Figure 18 and the other example request payloads, let's use a > higher-entropy client_secret than "qwerty" (or "ytrewq"), so as to not > give anyone bad ideas. [LS] This issue disappeared with an update removing the rather insecure client authentication method using the client_secret parameter. > 105.) > I'm not 100% sure, but the << "access_token" : b64'SlAV32hkKG ...', >> > snippet doesn't seem to decode to the start of the expanded token > contents shown in Figure 19. [LS] FIXED. It is now a COSE_Encrypt0 based CWT. > 106.) > Do we want to update the times in the tokens/etc. to be closer to "now"= ? [LS] FIXED. > 107.) > Messages C and F are shown in Figure 20 - Figure 21. >=20 > C: The client then sends the PoP access token to the authz-info > endpoint at the RS. This is a plain CoAP request, i.e., no > transport or application layer security is used between client an= d > RS since the token is integrity protected between the AS and RS. > The RS verifies that the PoP access token was created by a known > and trusted AS, is valid, and has been issued to the client. The= >=20 > How can the RS check that the token "has been issued to the client"? > (How does it identify the client at this point to do so?) [LS] FIXED. The last part of the sentence didn't belong here. > 108.) > The client sends the CoAP request GET to /temperature on RS over > DTLS. The RS verifies that the request is authorized, based on > previously established security context. > F: The RS responds with a resource representation over DTLS. >=20 > nit: we should probably be consistent about whether we mention the CoAP= > layer in the request+response. [LS] FIXED: Updated all examples to a consistent use of CoAP. > 109.) > Appendix E.2 >=20 > Note: In this example the client does not know the exact door it wil= l > be used to access since the token request is not send at the time of= > access. So the scope and audience parameters are set quite wide to > start with and new values different form the original once can be > returned from introspection later on. > =20 > Maybe add "and tailored to the RS performing introspection"? [LS] FIXED: I added a slightly different phrasing to the same effect,=20 since the original one didn't sound very elegant to me anymore. >=20 > 110.) > A: The client sends the request using POST to the token endpoint > at AS. The request contains the Audience parameter set to > "PACS1337" (PACS, Physical Access System), a value the that the > online door in question identifies itself with. The AS generates= >=20 > Didn't we just say that the client doesn't know the exact door it is > going to be talking to? [LS] FIXED: Good catch. This is of course meant to restrict the audience = to the underlying physical access control system, controlling multiple=20 doors,some of which the client might get access to. I have updated the=20 text accordingly. > 111.) > an access token as an opaque string, which it can match to the > specific client, a targeted audience and a symmetric key. The >=20 > So we're handing out a symmetric PoP key for a long-lived token that ma= y > be used at multiple resources? Isn't that the example we gave earlier > that lets RSes impersonate the client to each other? [LS] Since the doors (RSs) are all part of the same system we assume=20 that this is not a issue here. I added some explanatory text to clarify = these assumptions. Do you deem this acceptable? Side note: If we used asymmetric pop keys instead, we would either have=20 to provision all the doors' keys to the client up-front, or define a whol= e new protocol (which we initially tried with the "clientToken" concept,=20 but later dropped) that provides the client with the RS's public key=20 during the token POST or access attempt. > 112.) > In Figure 22, should we show the communications security layer between > client and AS? [LS] FIXED > 113.) > The introspection response in Figure 25 only has a 'kid' element for th= e > confirmation claim (that corresponds to a symmetric key); how is the RS= > supposed to know/learn the corresponding key so as to be able to verify= > the client's proof of possession? [LS] FIXED --=20 Ludwig Seitz, PhD Security Lab, RISE Phone +46(0)70-349 92 51 --------------ms070503090608000002070107 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DT0wggYWMIID/qADAgECAg8BaKlzCTJTye3phLaz/cIwDQYJKoZIhvcNAQELBQAwRzELMAkG A1UEBhMCU0UxFDASBgNVBAoMC1RlbGlhU29uZXJhMSIwIAYDVQQDDBlUZWxpYVNvbmVyYSBD bGFzcyAyIENBIHYyMB4XDTE5MDIwMTE0MjUxNVoXDTIxMDIwMTE0MjUxNFowgYsxCzAJBgNV BAYTAlNFMS4wLAYDVQQKDCVSSVNFIFJlc2VhcmNoIEluc3RpdHV0ZXMgb2YgU3dlZGVuIEFC MRUwEwYDVQQDDAxMdWR3aWcgU2VpdHoxEjAQBgNVBAUTCUx1ZHdpZ1NlaTEhMB8GCSqGSIb3 DQEJARYSbHVkd2lnLnNlaXR6QHJpLnNlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAlJNmRfcsto5I/yXrBIi9QroZtfAMttc1Eznv5iPCK++eFUArODhITO7k9rtlQX5D8vYF v4vzZex58YWZhvGMzDj9FdpD/PHKOxL/frlrreChuissPWo5M88DmL3V1oyGzvgeRqaafpEi 0/2+gezMFlABm/BXj3/0Fiw5Sxub7essE27EtDK05nAbUB69kfLHBEytbTAuuSb11hC1dpTf itMZkzSFwsBCyPtIv3GRt9xgnOPK4RRpHidv1GLYXNQQ7xEGhFy4qbZ2NSfM+56SSRswvW9P 5n81ZmZ4FWkiJouUIYtZ2ifncBJL4DC2chjsywDEz5No7kYrGxc5oOm1YQIDAQABo4IBuDCC AbQwHwYDVR0jBBgwFoAUnhn/5Q06/gCXFT9p8dxaPKoMlIMwHQYDVR0OBBYEFKZHZ8MZNNP5 tXMPjeFiw01pUWbtMA4GA1UdDwEB/wQEAwIFoDBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEB DDA6MDgGCCsGAQUFBwIBFixodHRwczovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEu Y29tL0NQUzAdBgNVHREEFjAUgRJsdWR3aWcuc2VpdHpAcmkuc2UwTQYDVR0fBEYwRDBCoECg PoY8aHR0cDovL2NybC0yLnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYWNsYXNz MmNhdjIuY3JsMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjB+BggrBgEFBQcBAQRy MHAwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnRydXN0LnRlbGlhLmNvbTBFBggrBgEFBQcw AoY5aHR0cDovL2NhLnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYWNsYXNzMmNh djIuY2VyMA0GCSqGSIb3DQEBCwUAA4ICAQCk0GOalOCjEJObuBeMg0QREtBP/2ona16npn+T v5R3Vjk5UsQdOaOosgVjADX68C83dyfPiWR4UfNJoTBcM8JLpEXIm+xC4BiDPTPHYvgkhgXt 9VWCRWXOMfT/UPXjiGsbPuNWja1LQzF5KOmM826kHVZItHuDY6kJLE4OZ+apFvVKtSLQJJLA 4MlDVwp5+XsZi4cftcX5HdgLdChodUPKq3XVfALfXM/p81XEFBTYOHNplr3cQytDQjsnCZnS Ic4UpsxrArNxDO9+AKu/s1Fbq494AhHj4oHcg4DIjhHUzbPCLP19Gqp4dflr/V7Ulg3d+4Zh bmSAn1cffrzvvkjVrqMgQOoHQTl2QyO9n/oJ/9CSYRmhFsQMPun9LM/p5l58dTZp53B3LgA6 FFrxnntlZnTPh3bvsMJvUQ+AoiXyQwnkdxUrhoM+gUz36t3JSA8g48h7BhPsnwQ/YrarAhJ8 ifuzykTQmDseWLjJKyFflddy/azAlPQjgSMMWOZCo2s+l+WwPISf33nls2Aec/vvG5auYHS6 pwWuVKuwZTPgJfHanZTNpBM5y0jVBz6tr8AHZypnCONgyUYA4uec3v5oWz4FvLEnlKnMGoK3 OeFGvfHG0tbP25HbdN3AJYP0EUo56wfkBOYsnmn4mEYdk2GHkJNfaQRBJljH0T7TOcmcDjCC Bx8wggUHoAMCAQICEGN8C9eFpb8p2mAtfE16cLEwDQYJKoZIhvcNAQELBQAwNzEUMBIGA1UE CgwLVGVsaWFTb25lcmExHzAdBgNVBAMMFlRlbGlhU29uZXJhIFJvb3QgQ0EgdjEwHhcNMTQx MDE2MDgzOTMwWhcNMzIxMDE2MDUwNDAwWjBHMQswCQYDVQQGEwJTRTEUMBIGA1UECgwLVGVs aWFTb25lcmExIjAgBgNVBAMMGVRlbGlhU29uZXJhIENsYXNzIDIgQ0EgdjIwggIiMA0GCSqG SIb3DQEBAQUAA4ICDwAwggIKAoICAQC0PpW2qcWGnStqfa5DjrUi79Kz2SySUlJ1kiEQ1Pd/ LWbnsEwFYPqOJwAf6ZtEDtQ/9Z1VkVNQ6MkD++keqk7648x0YANgMyiJsWrbd0TKOObtlXdJ pb5qesJ5nOAdVeL3z6lgrkZx+fsUfTV+lLRGRh2+RWzZTjPAvKotY3nAwXCHtwI5v3FKuR10 aJ9+CEOka02KSUzGjcGZwMk2io0DxLELf1gPRvqE9xmn4ioXLqpluozb4Fo9ewydufTLQc3/ I63uPQh8BlLPPIGzWb4iBDq2zbWlbx0KlH/UlUZ7fjzp6N6cAqZ2NnDaCOnnIRfUYeNXFG8/ aiBeFOpEeEpclr5QUwr9HLKL1QiyQtc/wW8acQFoKuGi8myiAch7k7S0rmU5gT05je+OTzWh Oaw7gmDdndYY1mjkPkzpQ+hxyfnwUsAitUq9j0imFOLxKWLH4QNbyuDIMvDyezzJWzMy3XPB LiLSH9CBLVQHRoQ+WW8xD4rnmvQtoGZM72og2iNf4/JCHL1AJYhQtaRjYgm3rhvAP0HhSVAB Z5aHM52ylJHC3JwUyuFm8S9A2ffY9rUTffMLWmDCnX0QAP9bKr6+ACogm4DBUj3ftYodI2TD 6F8+VjSFuCzGDPuCjK+fQ2c3wqziwFl+NgoGI9Vgc6x5+0ocKkiQAIYFaQ3SyGmI6QIDAQAB o4ICFTCCAhEwgYoGCCsGAQUFBwEBBH4wfDAtBggrBgEFBQcwAYYhaHR0cDovL29jc3AudHJ1 c3QudGVsaWFzb25lcmEuY29tMEsGCCsGAQUFBzAChj9odHRwOi8vcmVwb3NpdG9yeS50cnVz dC50ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5jZXIwEgYDVR0TAQH/BAgw BgEB/wIBADBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEBAjA6MDgGCCsGAQUFBwIBFixodHRw czovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQUzAOBgNVHQ8BAf8EBAMC AQYwgcYGA1UdHwSBvjCBuzBAoD6gPIY6aHR0cDovL2NybC0zLnRydXN0LnRlbGlhc29uZXJh LmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNybDB3oHWgc4ZxbGRhcDovL2NybC0xLnRydXN0 LnRlbGlhc29uZXJhLmNvbS9jbj1UZWxpYVNvbmVyYSUyMFJvb3QlMjBDQSUyMHYxLG89VGVs aWFTb25lcmE/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnkwHQYDVR0OBBYEFJ4Z /+UNOv4AlxU/afHcWjyqDJSDMB8GA1UdIwQYMBaAFPCPWTgAs/WPmpYM1ev6e6oX6BMSMA0G CSqGSIb3DQEBCwUAA4ICAQB5wuZFNXR5ko9cu7PcpIyH8xaoGfpimP2GTg7qVuL92D/idIlj pqMm93WC9mgL/Uy6DExoF8xSLurLaiajoU+VG6ZWg0F7P1AXARNt0RpWI5SphxBQYM2751S8 vC/22k8Vi+qpQVIREqQPVXCIEH7U6eCY9gEVzdq9l1yPoI8n0D2a8V6GCv0RVkmIpa16rNYD tTw4j3Ha56/Ua33C3qeZh1dIfkaU2h4CGHd2Em3v5LLMsEh8dqUeG9yIcCU+8RUgDahNxWMe MGxzrhwk8WBV6xeoQp20p7cSHbSbyHJURC1n+nVrgdh8hbw6WOgFhNA5tCPDZ0oSF+uHfj+b ioZE3AlYdcEqHJA9A9sO58F4/Qg/yp9oYuT0ZpKb4hmzeqDXvk5KRFNfHlhTt35i+qmas9wB 11MXbYd5WwqEhZH6HWO5H7XKJP7olxmEC0W3OKlpKafq1iPsBN5ycRfUrXFss0Ax6vpCq0XA 3LYePpQ44hOU+qrkR1M0a7Eo3++3TpP4cV+FZiO4aZYZ3yZftSRHwWpGiDBdWOdTKR2GJi7Z z/OxacrmwmM1Z+WcigldbG8f3IMnOLK4X0uXjhVeAHrhuttQuM8i+4TNXgsZbmfEKNDQIQPO /lbacsGHWFB/U2y6SXVEkZs2xIciRA0iZNTv7mbIL8SZmf5wpbjDCYHiCjGCAzgwggM0AgEB MFowRzELMAkGA1UEBhMCU0UxFDASBgNVBAoMC1RlbGlhU29uZXJhMSIwIAYDVQQDDBlUZWxp YVNvbmVyYSBDbGFzcyAyIENBIHYyAg8BaKlzCTJTye3phLaz/cIwDQYJYIZIAWUDBAIBBQCg ggGvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE5MTAxNTE0 MDc0OFowLwYJKoZIhvcNAQkEMSIEIMia+Q4ZMkIR6zCxil/Lha+HZc4v/BFxEY0NlCRuaR9F MGkGCSsGAQQBgjcQBDFcMFowRzELMAkGA1UEBhMCU0UxFDASBgNVBAoMC1RlbGlhU29uZXJh MSIwIAYDVQQDDBlUZWxpYVNvbmVyYSBDbGFzcyAyIENBIHYyAg8BaKlzCTJTye3phLaz/cIw awYLKoZIhvcNAQkQAgsxXKBaMEcxCzAJBgNVBAYTAlNFMRQwEgYDVQQKDAtUZWxpYVNvbmVy YTEiMCAGA1UEAwwZVGVsaWFTb25lcmEgQ2xhc3MgMiBDQSB2MgIPAWipcwkyU8nt6YS2s/3C MGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0D BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwIC ASgwDQYJKoZIhvcNAQEBBQAEggEAiu54QVotW3r25hdS/Qm2q+WDV6EidAJcjDVEvnCSuiAQ uLEkxv7a3Pq41cpGtg91GInWLhD4pZKnuHQyF+V3+o1qMdKYdyCXb+xIsBavToi0rS33woyt 6lAxLdJxfIEwz8iKHhDMc88abfjd1A/mwAiyjkE0pV7Om9jxJNn5CjIcKkyndPBS1XIPbgn5 htks7kDyzDXSaRnx02YHSVv7okMQYYErZKB04Eim5FX8RKo5kVFKpTrjw5Id02bOH/z8W8/9 PyFlemQqgND3WWrWjhawELD4gEwVCROwjakaIfYtVb1ij2NBwVhTj/2TdSQLsSCZFgywloxn LT8ndlwd6QAAAAAAAA== --------------ms070503090608000002070107-- From nobody Tue Oct 15 07:14: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 939C6120123; Tue, 15 Oct 2019 07:14:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=risecloud.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HCkazbyiSsUg; Tue, 15 Oct 2019 07:14:52 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-eopbgr130077.outbound.protection.outlook.com [40.107.13.77]) (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 39EF6120119; Tue, 15 Oct 2019 07:14:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=OCXP7x4mWtsMA170Cpwl8wLShcEA0R2tLt20twAu27UrJpMrRiuZKTl7X8g4nGGat/VgXMjShceOgIa/W6wlTI9TrHGKy1dVhtW+M2twp0hJ4NVQbcXcHlmHFzMgsjoQ20Q1ugNZ1AAWMwmx+TEbPkdt1+UQyzUI/W4ernFZkPmzdHxwl+bOcvVsAVAmD22zzOCgOp/I5WoInBRll7mgtdtEx7gGbDCwFqw1qlMI8gjoXFSSNXOEZznTawXvoxC5CFrW5cRJqpFWSr78h7pDBLw279jEZOy84RnvkIZzUvMVczqSJkPD1MRievMUVIuLCh0RhVTAl12TNYpDUihMbA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=C3UGaBFDMxBvqIzfJ+d+brdInr4yJzf5T6MaRVyKjiA=; b=HLcXJq6IWjH94i0zVtzWisEFibCb3Yk9H5Iojl5eVqfmMDjBT0PRcPgTiZdT+hpRiBn2TdjQMb/Y3xKqjIKW3+OM7tQHgK0BOtTynGUVGC/Vn0DJVwSbcmtfSP1gfFG0sL2bykgUJS4P5uyKKPqt5kIvRlKF4AV7YwPbaSaHNsraKrfXiPYu+uJCePJeb8AJpaUvJAI3aeDxTG9oOkeX9kfczfMgy0znawsbIvixBXQNeYoubDs02CNOEl9+X79w4XFulAaODID6lX7mlZH3U8ZMj3l0v1TVhz0IoibwrvuLXwA5W4bhzq2k9d4Ybm/0AqkyLLZ4oPqGKKgNEXSltw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 194.218.146.197) smtp.rcpttodomain=ietf.org smtp.mailfrom=ri.se; dmarc=pass (p=none sp=none pct=100) action=none header.from=ri.se; dkim=none (message not signed); arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=RISEcloud.onmicrosoft.com; s=selector2-RISEcloud-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=C3UGaBFDMxBvqIzfJ+d+brdInr4yJzf5T6MaRVyKjiA=; b=Xohemx/Px2FjtfEIsc2YrFdcJUi5lwXbWbcbmuzTjBAswABYJaZgVXQHilEjkAAVeFtxBTufngR8hEXBUCCVdFdlCy6oQPK0YzsY8tNZv2TAl9xp0gIG+Scul7aptCrkp1WvWVQrJnKzcUQnW1wV8wVT0z8pMzTyHgyNjJUW+nI= Received: from VI1P189CA0003.EURP189.PROD.OUTLOOK.COM (2603:10a6:802:2a::16) by AM5P189MB0561.EURP189.PROD.OUTLOOK.COM (2603:10a6:206:22::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2347.18; Tue, 15 Oct 2019 14:14:49 +0000 Received: from VE1EUR02FT063.eop-EUR02.prod.protection.outlook.com (2a01:111:f400:7e06::207) by VI1P189CA0003.outlook.office365.com (2603:10a6:802:2a::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2347.16 via Frontend Transport; Tue, 15 Oct 2019 14:14:49 +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=pass 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 VE1EUR02FT063.mail.protection.outlook.com (10.152.13.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.20.2347.16 via Frontend Transport; Tue, 15 Oct 2019 14:14:49 +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.1779.2; Tue, 15 Oct 2019 16:14:48 +0200 From: Ludwig Seitz To: Benjamin Kaduk , CC: References: <20190927015154.GY6424@kduck.mit.edu> <696c7ee4-75f9-48ec-8837-ea171137e9f8@ri.se> Message-ID: Date: Tue, 15 Oct 2019 16:14:48 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <696c7ee4-75f9-48ec-8837-ea171137e9f8@ri.se> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms050004060805080807060205" X-Originating-IP: [10.100.0.158] X-ClientProxiedBy: sp-mail-2.sp.se (10.100.0.162) To sp-mail-2.sp.se (10.100.0.162) X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:194.218.146.197; IPV:NLI; CTRY:SE; EFV:NLI; SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(136003)(396003)(376002)(346002)(199004)(189003)(126002)(16586007)(2616005)(229853002)(6246003)(486006)(58126008)(478600001)(81166006)(81156014)(106002)(71190400001)(8676002)(316002)(2171002)(31686004)(16576012)(476003)(31696002)(110136005)(22756006)(70586007)(336012)(40036005)(16526019)(26005)(6116002)(70206006)(3846002)(86362001)(186003)(44832011)(305945005)(446003)(53546011)(11346002)(568964002)(33964004)(76176011)(7736002)(386003)(5024004)(2906002)(14444005)(65956001)(65806001)(4326008)(356004)(22746008)(8936002)(36756003)(5660300002)(235185007)(5000100001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM5P189MB0561; H:mail.ri.se; FPR:; SPF:Pass; LANG:en; PTR:InfoDomainNonexistent; A:1; MX:1; X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: b798f29d-945f-4c9d-147b-08d7517a0a06 X-MS-TrafficTypeDiagnostic: AM5P189MB0561: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:9508; X-Forefront-PRVS: 01917B1794 X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: eL7QrKrCa56lE7+n9AhOpQtrdm3DqbZg5Hp6SQMV5zv1n1S6RLtBlmlBZBauAf2wnrYdIMs9ZBe4BbRgQEjuhuPcqVz2by7ecDiF6OCR00/owMOI4N5WJZiCy2uoLP244AkVb+L29gGH2tK57BdgMkJUs9zKgPPC7/82kc8u6oxCYUjAZMqwvmZ97NIK9cOq931gx55aO/OIjDHprhVMi1pxSoRPch1KVKIWZ5Sv3u8DdunJNUxSfd4X81MGGJHqyPX0P57NkcamZ78TteQliKwbgv0WEIdgdKbjWmcbRDg99aWuWvzk87nxZ7014sHABRFIHVLPdgv7vOdIavv1tPse/OjrLr9zs0L+MnddcU49hwIk9FEDLXvKCzD1eb+VJ0uKCq0nrLoEjTZWJpWmVaSAfJ7dODYOi1SNb5Ai9kU= X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Oct 2019 14:14:49.1224 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: b798f29d-945f-4c9d-147b-08d7517a0a06 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: AM5P189MB0561 Archived-At: Subject: Re: [Ace] AD review of draft-ietf-ace-oauth-authz-24 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 Oct 2019 14:14:56 -0000 --------------ms050004060805080807060205 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 15/10/2019 16:07, Ludwig Seitz wrote: >> 78.) >> Section 6.1 >> >> I think we should have a little bit more discussion about what attacks= >> are possible even when a client hard-codes a list of trustworthy ASes,= >> e.g., when a device in one AS's purview is compromised and tries to ge= t >> the client to use a different (possibly also compromised, or maybe jus= t >> buggy) AS than the one that's supposed to be responsible for the devic= e >> in question.=C2=A0 In short, yes, spoofing is only possible within tha= t set >> of trusted ASes, but spoofing can still cause problems. >=20 > [LS] I have added some text in section 6.FIXME Please have a look if th= is > covers what you were aiming at. >=20 A little typo snuck in here. "6.FIXME" should be "6.4" /Ludwig --=20 Ludwig Seitz, PhD Security Lab, RISE Phone +46(0)70-349 92 51 --------------ms050004060805080807060205 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DT0wggYWMIID/qADAgECAg8BaKlzCTJTye3phLaz/cIwDQYJKoZIhvcNAQELBQAwRzELMAkG A1UEBhMCU0UxFDASBgNVBAoMC1RlbGlhU29uZXJhMSIwIAYDVQQDDBlUZWxpYVNvbmVyYSBD bGFzcyAyIENBIHYyMB4XDTE5MDIwMTE0MjUxNVoXDTIxMDIwMTE0MjUxNFowgYsxCzAJBgNV BAYTAlNFMS4wLAYDVQQKDCVSSVNFIFJlc2VhcmNoIEluc3RpdHV0ZXMgb2YgU3dlZGVuIEFC MRUwEwYDVQQDDAxMdWR3aWcgU2VpdHoxEjAQBgNVBAUTCUx1ZHdpZ1NlaTEhMB8GCSqGSIb3 DQEJARYSbHVkd2lnLnNlaXR6QHJpLnNlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAlJNmRfcsto5I/yXrBIi9QroZtfAMttc1Eznv5iPCK++eFUArODhITO7k9rtlQX5D8vYF v4vzZex58YWZhvGMzDj9FdpD/PHKOxL/frlrreChuissPWo5M88DmL3V1oyGzvgeRqaafpEi 0/2+gezMFlABm/BXj3/0Fiw5Sxub7essE27EtDK05nAbUB69kfLHBEytbTAuuSb11hC1dpTf itMZkzSFwsBCyPtIv3GRt9xgnOPK4RRpHidv1GLYXNQQ7xEGhFy4qbZ2NSfM+56SSRswvW9P 5n81ZmZ4FWkiJouUIYtZ2ifncBJL4DC2chjsywDEz5No7kYrGxc5oOm1YQIDAQABo4IBuDCC AbQwHwYDVR0jBBgwFoAUnhn/5Q06/gCXFT9p8dxaPKoMlIMwHQYDVR0OBBYEFKZHZ8MZNNP5 tXMPjeFiw01pUWbtMA4GA1UdDwEB/wQEAwIFoDBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEB DDA6MDgGCCsGAQUFBwIBFixodHRwczovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEu Y29tL0NQUzAdBgNVHREEFjAUgRJsdWR3aWcuc2VpdHpAcmkuc2UwTQYDVR0fBEYwRDBCoECg PoY8aHR0cDovL2NybC0yLnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYWNsYXNz MmNhdjIuY3JsMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjB+BggrBgEFBQcBAQRy MHAwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnRydXN0LnRlbGlhLmNvbTBFBggrBgEFBQcw AoY5aHR0cDovL2NhLnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYWNsYXNzMmNh djIuY2VyMA0GCSqGSIb3DQEBCwUAA4ICAQCk0GOalOCjEJObuBeMg0QREtBP/2ona16npn+T v5R3Vjk5UsQdOaOosgVjADX68C83dyfPiWR4UfNJoTBcM8JLpEXIm+xC4BiDPTPHYvgkhgXt 9VWCRWXOMfT/UPXjiGsbPuNWja1LQzF5KOmM826kHVZItHuDY6kJLE4OZ+apFvVKtSLQJJLA 4MlDVwp5+XsZi4cftcX5HdgLdChodUPKq3XVfALfXM/p81XEFBTYOHNplr3cQytDQjsnCZnS Ic4UpsxrArNxDO9+AKu/s1Fbq494AhHj4oHcg4DIjhHUzbPCLP19Gqp4dflr/V7Ulg3d+4Zh bmSAn1cffrzvvkjVrqMgQOoHQTl2QyO9n/oJ/9CSYRmhFsQMPun9LM/p5l58dTZp53B3LgA6 FFrxnntlZnTPh3bvsMJvUQ+AoiXyQwnkdxUrhoM+gUz36t3JSA8g48h7BhPsnwQ/YrarAhJ8 ifuzykTQmDseWLjJKyFflddy/azAlPQjgSMMWOZCo2s+l+WwPISf33nls2Aec/vvG5auYHS6 pwWuVKuwZTPgJfHanZTNpBM5y0jVBz6tr8AHZypnCONgyUYA4uec3v5oWz4FvLEnlKnMGoK3 OeFGvfHG0tbP25HbdN3AJYP0EUo56wfkBOYsnmn4mEYdk2GHkJNfaQRBJljH0T7TOcmcDjCC Bx8wggUHoAMCAQICEGN8C9eFpb8p2mAtfE16cLEwDQYJKoZIhvcNAQELBQAwNzEUMBIGA1UE CgwLVGVsaWFTb25lcmExHzAdBgNVBAMMFlRlbGlhU29uZXJhIFJvb3QgQ0EgdjEwHhcNMTQx MDE2MDgzOTMwWhcNMzIxMDE2MDUwNDAwWjBHMQswCQYDVQQGEwJTRTEUMBIGA1UECgwLVGVs aWFTb25lcmExIjAgBgNVBAMMGVRlbGlhU29uZXJhIENsYXNzIDIgQ0EgdjIwggIiMA0GCSqG SIb3DQEBAQUAA4ICDwAwggIKAoICAQC0PpW2qcWGnStqfa5DjrUi79Kz2SySUlJ1kiEQ1Pd/ LWbnsEwFYPqOJwAf6ZtEDtQ/9Z1VkVNQ6MkD++keqk7648x0YANgMyiJsWrbd0TKOObtlXdJ pb5qesJ5nOAdVeL3z6lgrkZx+fsUfTV+lLRGRh2+RWzZTjPAvKotY3nAwXCHtwI5v3FKuR10 aJ9+CEOka02KSUzGjcGZwMk2io0DxLELf1gPRvqE9xmn4ioXLqpluozb4Fo9ewydufTLQc3/ I63uPQh8BlLPPIGzWb4iBDq2zbWlbx0KlH/UlUZ7fjzp6N6cAqZ2NnDaCOnnIRfUYeNXFG8/ aiBeFOpEeEpclr5QUwr9HLKL1QiyQtc/wW8acQFoKuGi8myiAch7k7S0rmU5gT05je+OTzWh Oaw7gmDdndYY1mjkPkzpQ+hxyfnwUsAitUq9j0imFOLxKWLH4QNbyuDIMvDyezzJWzMy3XPB LiLSH9CBLVQHRoQ+WW8xD4rnmvQtoGZM72og2iNf4/JCHL1AJYhQtaRjYgm3rhvAP0HhSVAB Z5aHM52ylJHC3JwUyuFm8S9A2ffY9rUTffMLWmDCnX0QAP9bKr6+ACogm4DBUj3ftYodI2TD 6F8+VjSFuCzGDPuCjK+fQ2c3wqziwFl+NgoGI9Vgc6x5+0ocKkiQAIYFaQ3SyGmI6QIDAQAB o4ICFTCCAhEwgYoGCCsGAQUFBwEBBH4wfDAtBggrBgEFBQcwAYYhaHR0cDovL29jc3AudHJ1 c3QudGVsaWFzb25lcmEuY29tMEsGCCsGAQUFBzAChj9odHRwOi8vcmVwb3NpdG9yeS50cnVz dC50ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5jZXIwEgYDVR0TAQH/BAgw BgEB/wIBADBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEBAjA6MDgGCCsGAQUFBwIBFixodHRw czovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQUzAOBgNVHQ8BAf8EBAMC AQYwgcYGA1UdHwSBvjCBuzBAoD6gPIY6aHR0cDovL2NybC0zLnRydXN0LnRlbGlhc29uZXJh LmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNybDB3oHWgc4ZxbGRhcDovL2NybC0xLnRydXN0 LnRlbGlhc29uZXJhLmNvbS9jbj1UZWxpYVNvbmVyYSUyMFJvb3QlMjBDQSUyMHYxLG89VGVs aWFTb25lcmE/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnkwHQYDVR0OBBYEFJ4Z /+UNOv4AlxU/afHcWjyqDJSDMB8GA1UdIwQYMBaAFPCPWTgAs/WPmpYM1ev6e6oX6BMSMA0G CSqGSIb3DQEBCwUAA4ICAQB5wuZFNXR5ko9cu7PcpIyH8xaoGfpimP2GTg7qVuL92D/idIlj pqMm93WC9mgL/Uy6DExoF8xSLurLaiajoU+VG6ZWg0F7P1AXARNt0RpWI5SphxBQYM2751S8 vC/22k8Vi+qpQVIREqQPVXCIEH7U6eCY9gEVzdq9l1yPoI8n0D2a8V6GCv0RVkmIpa16rNYD tTw4j3Ha56/Ua33C3qeZh1dIfkaU2h4CGHd2Em3v5LLMsEh8dqUeG9yIcCU+8RUgDahNxWMe MGxzrhwk8WBV6xeoQp20p7cSHbSbyHJURC1n+nVrgdh8hbw6WOgFhNA5tCPDZ0oSF+uHfj+b ioZE3AlYdcEqHJA9A9sO58F4/Qg/yp9oYuT0ZpKb4hmzeqDXvk5KRFNfHlhTt35i+qmas9wB 11MXbYd5WwqEhZH6HWO5H7XKJP7olxmEC0W3OKlpKafq1iPsBN5ycRfUrXFss0Ax6vpCq0XA 3LYePpQ44hOU+qrkR1M0a7Eo3++3TpP4cV+FZiO4aZYZ3yZftSRHwWpGiDBdWOdTKR2GJi7Z z/OxacrmwmM1Z+WcigldbG8f3IMnOLK4X0uXjhVeAHrhuttQuM8i+4TNXgsZbmfEKNDQIQPO /lbacsGHWFB/U2y6SXVEkZs2xIciRA0iZNTv7mbIL8SZmf5wpbjDCYHiCjGCAzgwggM0AgEB MFowRzELMAkGA1UEBhMCU0UxFDASBgNVBAoMC1RlbGlhU29uZXJhMSIwIAYDVQQDDBlUZWxp YVNvbmVyYSBDbGFzcyAyIENBIHYyAg8BaKlzCTJTye3phLaz/cIwDQYJYIZIAWUDBAIBBQCg ggGvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE5MTAxNTE0 MTQ0OFowLwYJKoZIhvcNAQkEMSIEIFqjWSFyfyQletTDkULt7s40AmqSj6MxxAIXPUIzOz9V MGkGCSsGAQQBgjcQBDFcMFowRzELMAkGA1UEBhMCU0UxFDASBgNVBAoMC1RlbGlhU29uZXJh MSIwIAYDVQQDDBlUZWxpYVNvbmVyYSBDbGFzcyAyIENBIHYyAg8BaKlzCTJTye3phLaz/cIw awYLKoZIhvcNAQkQAgsxXKBaMEcxCzAJBgNVBAYTAlNFMRQwEgYDVQQKDAtUZWxpYVNvbmVy YTEiMCAGA1UEAwwZVGVsaWFTb25lcmEgQ2xhc3MgMiBDQSB2MgIPAWipcwkyU8nt6YS2s/3C MGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0D BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwIC ASgwDQYJKoZIhvcNAQEBBQAEggEAMlt9uN/RMMQhSmlDwxR9AYX7FdONbEieDno39XOCvTL1 v9CfBInxTvDjExDYqMzKLD8gH/xW0pPbK0wzXqF5A8FKVNDzW4CIWRcdbkDf9Q0wAyhzdCR/ OltnIq5Evab94eEfMQbyqVUw8VZxR5fdatYda07sDakjv0bbNd6xSXd4Y32Ackp1jYw3bd2V FZ89sUYyvH25MluG33sEpFofhcuDojmyB/3wAzDNsEeGjuPNI7/TMCBGfy+KoN3k3tLpmkxI uCRQDR0YCogw4aeyT6CEXUp3TczlAlOD91Qk3cIVn8pOa6MDBYjpNV227y20r1H7+5ejZN/1 WmcF+y2pLwAAAAAAAA== --------------ms050004060805080807060205-- From nobody Tue Oct 15 14:09: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 70C67120086; Tue, 15 Oct 2019 14:09:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iBkW7P-RvOm4; Tue, 15 Oct 2019 14:09:34 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22F70120052; Tue, 15 Oct 2019 14:09:33 -0700 (PDT) Received: from Jude (192.168.1.159) by mail2.augustcellars.com (192.168.1.201) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 15 Oct 2019 14:09:28 -0700 From: Jim Schaad To: CC: Date: Tue, 15 Oct 2019 14:09:26 -0700 Message-ID: <021c01d5839c$d53206a0$7f9613e0$@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: AdWCRH8FC2clKULNRpW0/C165SXaxQ== Content-Language: en-us X-Originating-IP: [192.168.1.159] Archived-At: Subject: [Ace] Review for draft-ietf-ace-mqtt-tls-profile-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, 15 Oct 2019 21:09:37 -0000 Some of what is going here is going to duplicate information from my last message. Some of this are not necessarily things that need to be in this document but should be discussed at some point. 1. Are there any specifics about using ACE over HTTP that need to be explicitly stated some place. Some of these things might include: a) Must be HTTPS even if encrypted requests/responses are provided. b) What types of validation are permitted/required: anon-anon, server validation, server & client validation. The latter corresponds to current DTLS statements. c) Are we looking for using the normal HTTP/HTTPS ports or should we be using different ports? 2. Section 2.1.2: Somehow I missed on the first reading that you were suggesting the use of a topic /authz-info inside of the MQTT server for posting. I think that this needs to have a more detailed set of instructions. I assume but don't know that initially this would mean an anonymous connect, publish, disconnect, validated connect. This however is not clear from the text. It is also not clear that this should be over a TLS wrapped session for the publish. 3. Section 2.1.2: The correct reference is I-D.ietf-ace-dtls-authorize and not I-D.gerdes-ace-dtls-authorize. 4. Section 2.1.2: It is not clear from the document is a Broker is going to also have the possibility of doing a post of the token via HTTPS. Currently I would think not, but given that this is documented in OAuth 2.0 as an option I am not clear. 5. It might make sense to break up section 2.1.2 more and cover the different methods either in continuous paragraphs or in subsections. 6. As noted before, you need to have a section on TLS requirements. This should cover what levels/types of authentication are permitted. Some type of statement on TLS 1.3 vs prior versions. Part of what needs to be placed here is the fact that while there is client authentication in MQTT, there is no method of doing server authentication other than the surrounding TLS protocol. Also should cover how the certificate(?) or RPK would be validated. Use the existing rs_cnf? 7. In Figure 2, I think the use of Client Identifier is somewhat confusing. I think this is supposed to be the token as the Client Identifier is a different thing in MQTT. Either that or you need to do a better job of describing the property block. 8. If the value of Clean Start or Expiry Interval are not set correct is the server to fail the connect? 9. Should do a pass through the document and make sure that terms like "AUTH (Authentication Exchange) method" are not used. I think you meant to use 'packet' rather than method in this location. You need to be clear on the difference between methods and packets in the document. 10. Section 2.1.2.1 - I am having a problem computing the MAC over the payload of the CONNECT message. The password where the value is placed is included in the payload and I am not clear if it should be computed up to that value or if a fixed value should be used for the computation. 11. I am worried about the text on the Client Identifier in this section. It is not clear to me that having the client generate a random value for this field is good just in terms of the possibility of collisions occurring on the server. The text in the MQTT 5.0 document appears to say that this is more interesting for the situation of getting back state that was left on the server after a disconnect and not so much for a clean session. 12. I don't know where the nonce in this section is coming from. Discussion on where it comes from and where it is passed in the protocol is needed. 13. Is there someplace that authentication methods need to be registered? I was unable to see any such registry setup with OASIS from the v5 specification. Should we suggest to the MQTT group that this is something that should be done? 14. It would be useful to re-iterate that the authentication method for 2.1.2.3 is still set to 'ace'. 15. Section 2.1.3 - Please include a sentence that the signature algorithm of "none" is explicitly not permitted for tokens. 16. You might want to point to the updated text in the ACE Framework document for token validation procedures as they were rewritten and contain more or less the same content? 17. It is not clear to me, how in the scope string is the ability to have a "will" indicated? 18. Section 2.1.4 - I am unsure what the implications of discarding tokens on the end of a connection are going to be. How do you publish the token before doing the connection or is that only for an updated token? 19. Section 2.4 In the second paragraph, it appears you are saying that a client could send an AUTH packet after receiving a DISCONNECT message. I don't believe that is true. 20. I am not sure what the benefits of doing the check on a PINGREQUEST is going to be. Like the relay of a PUBLISH message this is just going to produce a DISCONNECT and a closed channel. If this is really allowed, then you should potentially also say that the Broker could do a check based on clock time elapsing. (I.e. do the check every hour.) 21. Section 2.5 - The last sentence in the first paragraph could be state more clearly. Specifically there would appear to be some ambiguity on who the associated tokens are attached to. "messages as long as the publisher token for that message remains valid." Might be better. 22. Not sure if this goes here or in the connect documentation. There needs to be a check that the will topic is a topic that the client is going to be permitted to publish on. Corner case, if the ability to publish a will in the event that this permission is lost. Does this kill the session or the will message? I.e. should the permission for the will message be rechecked before sending it allowing for the time based expiration of the token. Jim From nobody Tue Oct 15 18:21: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 3F50D12086C; Tue, 15 Oct 2019 18:21:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RxRusdnYKw3f; Tue, 15 Oct 2019 18:21:00 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B1CA12085D; Tue, 15 Oct 2019 18:20:59 -0700 (PDT) Received: from Jude (192.168.1.159) by mail2.augustcellars.com (192.168.1.201) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 15 Oct 2019 18:20:52 -0700 From: Jim Schaad To: 'Ludwig Seitz' , 'Benjamin Kaduk' , CC: References: <20190927015154.GY6424@kduck.mit.edu> <696c7ee4-75f9-48ec-8837-ea171137e9f8@ri.se> In-Reply-To: <696c7ee4-75f9-48ec-8837-ea171137e9f8@ri.se> Date: Tue, 15 Oct 2019 18:20:51 -0700 Message-ID: <024201d583bf$f4a146e0$dde3d4a0$@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: AQKDo/Tanj2ifMnW0FgPFAFSeXQMwwIUoCgepe+AizA= Content-Language: en-us X-Originating-IP: [192.168.1.159] Archived-At: Subject: Re: [Ace] AD review of draft-ietf-ace-oauth-authz-24 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 Oct 2019 01:21:13 -0000 I have trimmed down to the issues that I wanted to respond to. Jim -----Original Message----- From: Ludwig Seitz =20 Sent: Tuesday, October 15, 2019 7:08 AM To: Benjamin Kaduk ; = draft-ietf-ace-oauth-authz.all@ietf.org Cc: ace@ietf.org Subject: Re: AD review of draft-ietf-ace-oauth-authz-24 Hello Ben, thank you for your thorough review. I have taken the liberty to add numbers to your comments in order to=20 refer to them in a easier way. I have fixed 93 your 113 and there are 20 left where I am asking for=20 clarifications. These are: 6.), 12.), 16.), 19.), 34.), 39.), 41.), 45.), 52.), 57.), 58.), 65.), = 66.), 68.), 76.), 78.), 79.), 88.), 99.), 111.) Note that 39.) Requires input from OAuth experts. Hannes? If you whish to inspect the changes made on other review issues, please=20 consult the commits here: https://github.com/ace-wg/ace-oauth/commits/master Detailed comments below. /Ludwig >=20 > Hi all, >=20 > The length of this review notwithstanding, this document is generally = in > good shape -- there's a bunch of localized items to tighten up, and we > can flesh out the security considerations some more, but nothing too > drastic should be needed. >=20 > 12.) > A refresh token in OAuth 2.0 is a string representing the > authorization granted to the client by the resource owner. The > string is usually opaque to the client. The token denotes an >=20 > Apparently I'd forgotten that this couldn't be binary. [LS] From RFC 6749, section 1.5: "A refresh token is a string ..." No qualifiers such as "binary" so I interpret this to mean a = text-string. Do you want us to add some clarification? [JLS] I think we may want to change this at some point in the future, = but I don't know how much people are going to use refresh tokens so I = don't think I would worry about it. > 32.) > Section 5.6.1 >=20 > The client sends a POST request to the token endpoint at the AS. = The > profile MUST specify how the communication is protected. The = content >=20 > In the previous section we said that maybe even other transports than > coaps or https would be possible; are we limited to those that have = POST > verbs? > Also, a similar comment as above about what attributes the protection > entails seems to apply. [LS] This will need a major rephrasing of the text. I see two options here: 1.) We rewrite all parts to use a neutral language in general and = specify POST/GET etc. for transports that have these verbs. 2.) We state in the beginning that transports that do not use RESTful = verbs should use the best equivalent. Option 1. would get a bit cluncky, while option 2. might be a bit = confusing Do you have a specific preference? [JLS] I would suggest that this could fall under the punt to the new = transport that does not have the same as these verbs in it to explain = how they would map. =20 > 39.) > Refresh tokens are typically not stored as securely as proof-of- > possession keys in requesting clients. Proof-of-possession based > refresh token requests MUST NOT request different = proof-of-possession > keys or different audiences in token requests. Refresh token > requests can only use to request access tokens bound to the same > proof-of-possession key and the same audience as access tokens = issued > in the initial token request. >=20 > This is perhaps something of a philosophical question, but if a = refresh > token is only usable at the token endpoint, in some sense its audience > is definitionally the AS. So there's a little bit of a mismatch in > treating it as having the audience value that the access tokens issued > from it will have. I don't know the background for audience-restriced > refresh tokens in regular OAuth 2.0, though, so hopefully someone can > educate me. [LS] I'm equally confused. I suggest that Hannes or one of the other = OAuth experts give us a hint on that one. [JLS] My understanding is that the refresh token is completely opaque = to anybody but the AS so how it is stored is not as critical. The = client then does a normal request with that as a parameter. The refresh = token allows for the AS to avoid doing some of the authorization steps = and potentially re-use the same key for the new token. As such, the = newly requested token needs to headed to the same audience as the = original POP token. This is the reason for needing to keep audience = with it on the client. =20 > 41.) > token_type: > This parameter is OPTIONAL, as opposed to 'required' in = [RFC6749]. > By default implementations of this framework SHOULD assume that > the token_type is "pop". If a specific use case requires = another > token_type (e.g., "Bearer") to be used then this parameter is > REQUIRED. >=20 > When we are "weakening" the formal requirements of the parent spec = like > this, we should be careful about what happens when someone is trying = to > use the ACE stuff but ends up needing to go over HTTPS like = traditional > OAuth -- do they have to fall back to the OAuth required behavior in > that case or are we trying to preempt that as well? [LS] The use case here is a constrained connection between client and AS (e.g. due to a constrained client), where we try to save the bytes for sending a token_type by defining a default. I would guess that a HTTPS = based connection would not have such constraints and would therefore be able=20 to send the token_type =3D "pop" as required by RFC6749. Should we explain this=20 somewhere and describe the cases where RFC6749 behaviour is warranted? [JLS] Given that it would be identified as being application/ace+json, I = don't think there is a problem with having the default value. The fact = that this is ACE is identifiable from the media-type of the message sent = over HTTPS. > 52.) > Section 5.7.4 >=20 > "scope" is showing up with the key 9 a lot; I have mixed feelings = about > having the CBOR map key value be aliased across different contexts = (but > it's probably too late to change without disruption anyway). [LS] Scope is used in 4 places: I. AS Request Creation Hints II. /token request and response parameter III. CWT claim IV. /introspection response parameter I claim that in all 4 cases we expect the same content with the same formatting and semantics: I. tells the client what to put into II. which in turn informs the AS about the requested claim value in III. and IV. is supposed to reflect that claim value. I therefore don't feel hesitant to use the same abbreviation for all four cases. Is that acceptable or do you whish us to perform any action on this? [JLS] I could have wished you said something sooner. I kept trying to = argue that there was no need to be consistent on the mapping, but that = is how it is. I will note that sections 8.6, 8.9, 8.11 as well as 8.13 = are all separate registries for doing the mapping. This means that = while today there is consistency across all of the registries, there is = no guarantee that this will be true going forward. --=20 Ludwig Seitz, PhD Security Lab, RISE Phone +46(0)70-349 92 51 From nobody Wed Oct 16 08:06: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 60F63120074; Wed, 16 Oct 2019 08:06:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 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_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 header.b=XEZ5sZk8; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=pcgvqaj8 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 J2xkr2kZnveZ; Wed, 16 Oct 2019 08:06:14 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7785012002E; Wed, 16 Oct 2019 08:06:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6840; q=dns/txt; s=iport; t=1571238365; x=1572447965; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=JzgZq/ItXyxQMIlmDR8vV8WdeKFR2R0nH1Sjt8ZAk6Y=; b=XEZ5sZk8Ef/WRrJ3aUD5UdnZRcHmwoPjLg8EZ+2re9Cg21Y8mihdS52O 9xhkZCyKvBRkk5xd1T06s7+VyyEunK3DNoDrY/GI+zd2xvCoF2QxYL5c3 MF+XYaGtEyh2jeXhvBiqpHRR/8alaezx9o2gA8fzsj62AEIfhGu/NaeUd U=; IronPort-PHdr: =?us-ascii?q?9a23=3ASzL0DhJygCABLyj3N9mcpTVXNCE6p7X5OBIU4Z?= =?us-ascii?q?M7irVIN76u5InmIFeBvKd2lFGcW4Ld5roEkOfQv636EU04qZea+DFnEtRXUg?= =?us-ascii?q?Mdz8AfngguGsmAXFX4JfvyZiozNM9DT1RiuXq8NBsdFQ=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B/AABnMadd/4QNJK1dCRkBAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAREBAQEBAQEBAQEBAYF7gUtQBWxXIAQLKgqHYgOKUIJcl36?= =?us-ascii?q?BQoEQA1QJAQEBDAEBGA0IAgEBhEACgnskOBMCAwkBAQQBAQECAQUEbYUtDIV?= =?us-ascii?q?LAQEBAQMBARAoBgEBKgIIAwELBAIBCBEEAQEfECcLHQgCBAENBQgagwGCRgM?= =?us-ascii?q?uAQIMoz0CgTiIYYIngn0BAQWBNAGDVhiCFwMGgTSKS4EmHRiBQD+BEUaCHi4?= =?us-ascii?q?+gmEBAYEuAQgKAQkEFIM+giyMaaBoCoIihwqOLII6h0+NWoFfjjCBP4ZlkRg?= =?us-ascii?q?CBAIEBQIOAQEFgWkiLDtxcBU7gmxQEBSBT4NzhRSFP3QKNWqNTw0XB4EEAYE?= =?us-ascii?q?iAQE?= X-IronPort-AV: E=Sophos;i="5.67,304,1566864000"; d="scan'208";a="351416068" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 16 Oct 2019 15:06:04 +0000 Received: from XCH-RCD-006.cisco.com (xch-rcd-006.cisco.com [173.37.102.16]) by alln-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id x9GF64Yi027823 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 16 Oct 2019 15:06:04 GMT Received: from xhs-rcd-001.cisco.com (173.37.227.246) by XCH-RCD-006.cisco.com (173.37.102.16) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 16 Oct 2019 10:06:03 -0500 Received: from xhs-aln-002.cisco.com (173.37.135.119) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 16 Oct 2019 10:06:02 -0500 Received: from NAM02-SN1-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Wed, 16 Oct 2019 10:06:02 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=AgqBhqTC6nQ9gpefnni4FxkxVZyJ1hkL5xtiJhBP048s67bBupGKwgpF2KOr8vY5lP6U7NnxcBrKJHHT7D7S4jqd2xJqqPqVW3gR4rU46Uk2Mbo5+0bPN7SR5FuiM6dpXZjV6VEercDNdHZpmhwIcc80rKOp7V7BZ68AZg2z2lItj3I3dCzRQtATAUzSRpfh/YlNpR32gD5lB4qYaUjFxPnYjh88BEuWAYM/0qk6hv2odUMgerUmX8OVJmC1nPimTUhiF/jCXK7MnUutON5h2qbPtqdgmk4Y1HXqF7SHKAKh3E2msB8hKDQzbofoeX+ftUPNi6cMSAB3C1bQmyJx8g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=OpSZITP6jvKb24mQXvrKbDZs3jL4A8+zp4q/Hlnj0us=; b=dmbyUws3eU7OVi0BkGvGhxeRN2SK+DlkezvbMN9ESwfVywglygT2c3jHqzC9IRyKGl2NsNavPDDPGKMBlv2ekIlwZPzooGPh0bIZxkNae/+nNig011BBzx752Zp6BG9Kc6+ATHPx6neTq1qjBMNX9V/t0zlzcWfWZLS4UTV834umndqLKWipYMz3QyuLHfhAlTqrKVRHJNJjRUlH2FibiYj5+EcYdjl3eUKcLNlWGcMjZjXpDmcMj7WVP/0wSqZN8t4FmR7TEOijTdF2mgW6V6TH7tWg6/uBlnj7JUrpWlznnp80bF/jY8gdjQXXCNNgO/XHxDGvheY0uw6cHSSiQA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=OpSZITP6jvKb24mQXvrKbDZs3jL4A8+zp4q/Hlnj0us=; b=pcgvqaj8Ym6VE2hHYm+21y+k16SP0+z8eeXw1fPH+hcEj6NrjbJiAEbHxeDq0Es4SnxferUOZxjlMzAid9m0gUTw4hOnOyXiYViskPD3wlCOujSSj0hi7yclo9/GZKUdNdAzTEAi4Al5Ch4F3qr1vOYekwBNoNFUOwx75QTilAs= Received: from BN7PR11MB2547.namprd11.prod.outlook.com (52.135.255.146) by BN7PR11MB2707.namprd11.prod.outlook.com (52.135.245.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2347.18; Wed, 16 Oct 2019 15:06:01 +0000 Received: from BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::5082:c814:2836:9e2a]) by BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::5082:c814:2836:9e2a%7]) with mapi id 15.20.2347.023; Wed, 16 Oct 2019 15:06:01 +0000 From: "Panos Kampanakis (pkampana)" To: Yaron Sheffer , "secdir@ietf.org" CC: "draft-ietf-ace-coap-est.all@ietf.org" , "ietf@ietf.org" , "ace@ietf.org" Thread-Topic: [Ace] Secdir last call review of draft-ietf-ace-coap-est-15 Thread-Index: AQHVgcaC5NivFu6vxkuLEqSa/tiqS6ddYSVA Date: Wed, 16 Oct 2019 15:06:01 +0000 Message-ID: References: <157097172245.20767.1326966836276837764@ietfa.amsl.com> In-Reply-To: <157097172245.20767.1326966836276837764@ietfa.amsl.com> 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=pkampana@cisco.com; x-originating-ip: [64.102.57.123] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 87a6c454-5671-4a52-f94e-08d7524a5bd5 x-ms-traffictypediagnostic: BN7PR11MB2707: x-ms-exchange-purlcount: 3 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0192E812EC x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(979002)(4636009)(376002)(366004)(396003)(39860400002)(136003)(346002)(52084003)(13464003)(199004)(189003)(86362001)(76116006)(186003)(446003)(66446008)(66066001)(66946007)(11346002)(74316002)(71190400001)(71200400001)(66476007)(7736002)(8676002)(81166006)(8936002)(476003)(81156014)(486006)(102836004)(26005)(2906002)(33656002)(64756008)(66556008)(305945005)(54906003)(110136005)(99286004)(316002)(53546011)(76176011)(6116002)(3846002)(478600001)(14454004)(6506007)(256004)(7696005)(14444005)(5660300002)(2501003)(229853002)(9686003)(25786009)(6306002)(55016002)(52536014)(4326008)(6436002)(966005)(6246003)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:BN7PR11MB2707; H:BN7PR11MB2547.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: fQTyIKKry5j9v9V0ssNjC3iQxs8FT9/oIuwQXJbYLwQ9rHd8jmnAZq8E2K07mowzmuyj79A55ULRJSZrQjTJrS24rer6IqbpP/3c6EsKkq0j2kX0EC0SuB2H2nNb7Md6+X/9PiBZs/kccyqm0nTAef8Oin4Y3Y96c5r99USd2YAnN3y502nq9DyuVofgeV3Wfl4nkczk9oxHEKBOS7/rtKu/zl9vKe3plGFbk+IHhZ5hTX9PmPIHz5AWdTlPxzt026O57LzbvlaAZdIZyM61Evhtroj2jj3NR+d34WlrLhyMo2aK27d0RtrIu2SMKuMHSBpqZI4otB4pWmTKB0cDdFaydZebSRISMoTfXxVXxjYgKYBYETTSgFQmBCoLl5WaLz1qUORcFAogRMu9n6OfefSUKHp34XnRhEZs/ZzKk9AUMJ3M0swusUWNVqA3JgSJrX5De+lFXlEQEO3s/nSSuA== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 87a6c454-5671-4a52-f94e-08d7524a5bd5 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Oct 2019 15:06:01.5832 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: CaereYFx9fKola1c4biBt4CVHaZnvdhsNQM2b59WXAq8Peh5p+4KugvcJ4goh5pgpCIqdEi71wVMgIsVNXNQng== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR11MB2707 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.16, xch-rcd-006.cisco.com X-Outbound-Node: alln-core-10.cisco.com Archived-At: Subject: Re: [Ace] Secdir last call review of draft-ietf-ace-coap-est-15 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 Oct 2019 15:06:19 -0000 Hi Yaron, Thank you for the thorough review and feedback.=20 To make sure I don't miss any of your comments over an email thread, I trac= k all your feedback in git issue 152 https://github.com/SanKumar2015/EST-co= aps/issues/152 There I tried to address all your comments and question and = clarify some points.=20 I also pushed minor changes to fix a few of the issues you brought up. The = diff of the changes pushed is here https://github.com/SanKumar2015/EST-coap= s/commit/86d785f2122596f28674fe8e403d30467c98abfb=20 Please review the git issue and let us know if there are pending concerns. = Otherwise I am planning to reupload a new iteration next week.=20 Rgs,=20 Panos -----Original Message----- From: Ace On Behalf Of Yaron Sheffer via Datatracker Sent: Sunday, October 13, 2019 9:02 AM To: secdir@ietf.org Cc: draft-ietf-ace-coap-est.all@ietf.org; ietf@ietf.org; ace@ietf.org Subject: [Ace] Secdir last call review of draft-ietf-ace-coap-est-15 Reviewer: Yaron Sheffer Review result: Has Issues This document defines a new profile for EST (simple certificate enrollment)= for restricted devices, to be run on top of CoAP and DTLS, instead of the = usual HTTP and TLS. Overall, I tend to be suspicious of "restricted" profiles, and this is a ca= se in point. An implementation of DTLS is no simpler than TLS and most woul= d probably support both protocols. And basically anything supports HTTP. So= why would it make sense to define a whole new profile just to avoid using = TCP very rarely (say, for daily certificate enrollment), when this profile = even needs to include its own fragmentation/buffering mechanisms because th= e ASN.1 payloads are too long? In other words, we are introducing new and a= dditional complexity with little or no performance gain. - 2. Only certificate-based client authentication is supported. Hopefully s= ome time soon we'll be able to use PAKE here, to bootstrap the PKI. - 4. "Crypto agility is important" - this statement is somewhat meaningless= : do we require more than one cipher suite, which would ensure some level o= f agility? - Also, when we say "Sec. 4.4 of RFC 7925" do we mean *only* Sec. 4.4 or al= so the subsections: 4.4.1 etc. - "in DTLS 1.3 the Supported Elliptic Curves extension has been renamed to = Supported Groups". This is probably true for an older version of the draft,= I couldn't find anything to support it in -32. - "the Finished message must be computed" - this whole paragraph is unclear= . Are we changing the Finished/MAC computation in DTLS (if so, this must be p= ointed out very clearly)? Or are we explaining a point about channel bindin= g (if we are, this doesn't come across). - Similarly for the following paragraph: is this a performance optimizatio= n, or a change to DTLS? And by the way, why are standard session resumption= mechanisms not used? - I don't see value in the short EST URI paths given that most of the "weig= ht" is in ASN.1 data, and the paths are negligible in comparison. Moreover, if = the paths are different, shouldn't this document formally UPDATE RFC 7030? = I think it is no longer a profile. - Non-default server port: the examples include an IPv6 address in addition= to the port number. Is there a way to use relative URIs (omitting the IP a= ddress) but include a port number? The server may not know its own IP addre= ss (IPv4 with NAT) or the address may be dynamic. - The server MUST support the default /.well-known/est root resource, but t= hen in the next sentence we discuss non-default URIs. In the case of the se= rver having multiple "identities" (the main purpose of the "arbitrary label", AF= AIU), the root resource is confusing - which identity is it associated with= ? And then how is discovery managed for each identity, and is there a way to = discover the identities? - There is nowhere in this document a full formal definition of content typ= e TBD287 (a single cert). - Content type negotiation: I can see how it works for enrollment. But in t= he case of /cacerts, if the server has a list of certs in its explicit TA s= tore (e.g. to support rollover), how can TBD287 (a single cert) make sense? - It is mighty confusing to denote "content format" by "ct" (presumably, th= is stands for "content type"). - "ASN.1 encoded in binary format" - I think this should be, "DER-encoded A= SN.1, in its native binary form". - Please don't use "he" and "she" for the server and the client. Both are m= erely "it". - "The Registrar MUST authenticate and optionally authorize the client requ= ests" - this statement is too weak. The Registrar must also ensure that cli= ents only send CSRs that pertain to their authenticated identity (channel b= inding), even when POP-linking is not used. I think this is worthy of its o= wn subsection, describing the validation required for each particular EST f= low. - The following paragraph is not clear: is PoP-linking useful/recommended/m= andated in this scenario? IMO there should be some 2119 word regarding serv= er-side validation of the tls-unique. - "Table 1 contains the URI mappings between EST-coaps and EST that the Reg= istrar MUST adhere to." But the immediately preceding paragraph describes a= case where a server-side generation on the EST-coaps side is mapped to cli= ent-side generation on the EST-HTTPS side, which is not a Table 1 mapping! - "the encrypted CMS EnvelopedData blob MUST be converted at the Registrar"= - can this be done without decrypting the blob, IOW must the Registrar be = privy to the key wrapping key? - The Registrar must support resource discovery: does it mean that resource= discovery messages are simply proxied upstream, or that the Registrar pres= ents a simpler resource structure (maybe with no discovery) to its clients = while performing discovery upstream? - Security Considerations: there's a long discussion about replacing the im= plicit TAs with explicit ones. If we (rightly) mandate that the client re-v= erify the server's cert after getting the /certs response, we are losing mo= st of the minor performance gain that keeping the DTLS connection open migh= t have given us. So why not unambiguously mandate the simpler "MUST close t= he connection after /certs" instead? Besides, /cacerts is a very rare opera= tion. Why optimise it at all? - "Improper CSR requests" - what are they? What's the server supposed to do= ? Please give a reference. - A.3, response: I may be missing something, but the binary blob "3081...9f= d9" does not parse as PKCS#8 to me. _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace From nobody Wed Oct 16 12:39: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 E27041200FA; Wed, 16 Oct 2019 12:39:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.99 X-Spam-Level: X-Spam-Status: No, score=-1.99 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, 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=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 0AUe2gWuy-Ju; Wed, 16 Oct 2019 12:39:45 -0700 (PDT) Received: from NAM06-DM3-obe.outbound.protection.outlook.com (mail-eopbgr640136.outbound.protection.outlook.com [40.107.64.136]) (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 35108120105; Wed, 16 Oct 2019 12:39:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=hbk415qLwdrYrrjcRL7Bj7Y0XmNCCMl8kLnTDnKuvzu/86Iu5LzcKfDQ2W4tvMwKIf7iXlB5w+MlBRPqgiavG/JlBtctXsFrpXaZx+f4399rB43gzdThFDvSbGoU81jmeOAOPSwY/h62OKIRqP3jAZKnWMxPWdKs5Eb65AgQJOWcGcDOzPXGFjiAE1hGEf+Y1UApsjJqN4myjbcKNosbvqHB/bmLcwkfJRJzdJhQI5dZt2TzDMjhcNrMj5Vk5d5qrytqIHOye6BtTldt0Kp2xQyBW3b5IBZ+4jzRzyN5UKIS7LmXk6+MXnNBdUIjYUDYSVSR3qSj6plqBkslbI+NqQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=q9YjQIv7kmVFCigYG5YppcS+zM76OitH5OEko6/9cZA=; b=HbwzhkyQMzzCZnPySgfKMnW66VHPqNYdIJJZWbo+OBbNJLh2Ahi45G5vnL4o5yJ9PmZlMhK4D2xQq6lyE6X6syPrGEqlDVFUw3Amf+YdiEDFKPRi2yqpjnXNdguBW9TaEWnEjfCwXW8ol/mvb27f2aG+gcGOHdVLpKaltGQNrSnCj7diknZauMYYaQqOGBDXA57rCtCnx4blLRukKM1Ljj5bXenxajlQttni70yiZfsiYYaoZ9o1e2HC1y7E/Kvdt25z7DE0Sxbzo0I0cgeQ6KoIqA4SqBGIphdROfndJvThWI/ymA+C0kRmJj+f9teTqDY+HLkjTvJRjrTrQq8l/g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=q9YjQIv7kmVFCigYG5YppcS+zM76OitH5OEko6/9cZA=; b=V0vNhBQfe/zwaGqVjJO5jt2H+LiUMn2KB4FofW3Y/p4i+LcntJaK3xRPo2w7Pag9paGiVQ+FmIWd87u4RnrBHL94FxA2wAjVuLFzl7eB3bNfaYGQ0SWP4IFFb7NESB7Knn3jXdIeQUuOI+bjbLxbC2j5dqgfPH0g6zVQkxCp5JQ= Received: from DM6PR00MB0569.namprd00.prod.outlook.com (20.179.51.12) by DM6PR00MB0618.namprd00.prod.outlook.com (20.179.49.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2401.0; Wed, 16 Oct 2019 19:39:42 +0000 Received: from DM6PR00MB0569.namprd00.prod.outlook.com ([fe80::9196:77fa:83c0:9418]) by DM6PR00MB0569.namprd00.prod.outlook.com ([fe80::9196:77fa:83c0:9418%7]) with mapi id 15.20.2405.000; Wed, 16 Oct 2019 19:39:42 +0000 From: Mike Jones To: Christer Holmberg , "gen-art@ietf.org" CC: "draft-ietf-ace-cwt-proof-of-possession.all@ietf.org" , "ietf@ietf.org" , "ace@ietf.org" Thread-Topic: Genart last call review of draft-ietf-ace-cwt-proof-of-possession-08 Thread-Index: AQHVettbQ32ECifdD0O+TX7Aa2ifMadduf7w Date: Wed, 16 Oct 2019 19:39:42 +0000 Message-ID: References: <157021105722.1446.14439223392992273252@ietfa.amsl.com> In-Reply-To: <157021105722.1446.14439223392992273252@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=92595862-c8a0-449e-9d88-0000d093eac5; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2019-10-16T19:28:15Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [2001:4898:80e8:f:98d9:5a0a:3425:3ebe] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b45c6728-65d3-4e0b-032d-08d752709789 x-ms-office365-filtering-ht: Tenant x-ms-traffictypediagnostic: DM6PR00MB0618: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0192E812EC x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(366004)(13464003)(189003)(199004)(22452003)(66446008)(6116002)(71200400001)(8936002)(81166006)(81156014)(606006)(8676002)(229853002)(4326008)(10290500003)(66556008)(66946007)(66476007)(71190400001)(54906003)(14454004)(86362001)(110136005)(64756008)(76116006)(25786009)(498600001)(790700001)(33656002)(2906002)(10090500001)(6506007)(53546011)(9686003)(11346002)(102836004)(186003)(55016002)(52536014)(54896002)(236005)(8990500004)(6246003)(2501003)(6306002)(76176011)(7736002)(7696005)(99286004)(256004)(486006)(6436002)(5660300002)(446003)(476003)(46003)(74316002)(14444005); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR00MB0618; H:DM6PR00MB0569.namprd00.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 2jIA4XcFf9n0fZ9NtfuPe7Zc6V/1INTrj9maGQOWmUyFKi8mwiPBAFqam+Zuqwi6ev0uEGWjctc3qRCZ1rv36JkSqX6odnffBYJArFoifNozNBk21fOZhX05tkRFmcVCOh4DB5Z/u0R3jo4T81Q8e0Xx/7TLNvSyPtcBNJzH9jd/T1ra6J2Zy04fU2TiPSlsxYL/4+1Psbv0xwjt8E1g7IhDqodGMWxu7PUQGtzDaj8PAnjEqQHv/EEd08t3GmmK4iv1oM1VuyRQqhAijSN8ymNUgwWYpH+W1tBXMtD9O7v1UqI2RwaYc7JgtfcokEhqMvEgMjWY35LD8JtQ3OdMw8tdDkXCe2jEadCPo/Bd5lqK/kl8on+uVwLkEpnMvzTWByXG5I4/Syd7BKCUCv9GKp01sz0WQiRHnkRC6gtLcZE= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DM6PR00MB0569B15A50D4CA0EEA4B4DECF5920DM6PR00MB0569namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: b45c6728-65d3-4e0b-032d-08d752709789 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Oct 2019 19:39:42.7008 (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-CrossTenant-userprincipalname: /bIj0BJsp5QUP0sYQzVEx7uPyQWcEiU0sukwwgvkdMAk1ymUD1V/BayqgoWt+UtJzktCc5COqu5PYTH2bpcHlg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR00MB0618 Archived-At: Subject: Re: [Ace] Genart last call review of draft-ietf-ace-cwt-proof-of-possession-08 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 Oct 2019 19:39:48 -0000 --_000_DM6PR00MB0569B15A50D4CA0EEA4B4DECF5920DM6PR00MB0569namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIGZvciB5b3VyIHJldmlldywgQ2hyaXN0ZXIuICBSZXBsaWVzIGFyZSBpbmxpbmUsIHBy ZWZpeGVkIGJ5ICJNaWtlPiLigKYNCg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpG cm9tOiBDaHJpc3RlciBIb2xtYmVyZyB2aWEgRGF0YXRyYWNrZXIgPG5vcmVwbHlAaWV0Zi5vcmc+ DQpTZW50OiBGcmlkYXksIE9jdG9iZXIgNCwgMjAxOSAxMDo0NCBBTQ0KVG86IGdlbi1hcnRAaWV0 Zi5vcmcNCkNjOiBkcmFmdC1pZXRmLWFjZS1jd3QtcHJvb2Ytb2YtcG9zc2Vzc2lvbi5hbGxAaWV0 Zi5vcmc7IGlldGZAaWV0Zi5vcmc7IGFjZUBpZXRmLm9yZw0KU3ViamVjdDogR2VuYXJ0IGxhc3Qg Y2FsbCByZXZpZXcgb2YgZHJhZnQtaWV0Zi1hY2UtY3d0LXByb29mLW9mLXBvc3Nlc3Npb24tMDgN Cg0KDQoNClJldmlld2VyOiBDaHJpc3RlciBIb2xtYmVyZw0KDQpSZXZpZXcgcmVzdWx0OiBSZWFk eSB3aXRoIElzc3Vlcw0KDQoNCg0KSSBhbSB0aGUgYXNzaWduZWQgR2VuLUFSVCByZXZpZXdlciBm b3IgdGhpcyBkcmFmdC4gVGhlIEdlbmVyYWwgQXJlYSBSZXZpZXcgVGVhbSAoR2VuLUFSVCkgcmV2 aWV3cyBhbGwgSUVURiBkb2N1bWVudHMgYmVpbmcgcHJvY2Vzc2VkIGJ5IHRoZSBJRVNHIGZvciB0 aGUgSUVURiBDaGFpci4gIFBsZWFzZSB0cmVhdCB0aGVzZSBjb21tZW50cyBqdXN0IGxpa2UgYW55 IG90aGVyIGxhc3QgY2FsbCBjb21tZW50cy4NCg0KDQoNCkZvciBtb3JlIGluZm9ybWF0aW9uLCBw bGVhc2Ugc2VlIHRoZSBGQVEgYXQNCg0KDQoNCjxodHRwczovL25hbTA2LnNhZmVsaW5rcy5wcm90 ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ0cmFjLmlldGYub3JnJTJGdHJh YyUyRmdlbiUyRndpa2klMkZHZW5BcnRmYXEmYW1wO2RhdGE9MDIlN0MwMSU3Q01pY2hhZWwuSm9u ZXMlNDBtaWNyb3NvZnQuY29tJTdDNGZmYzEzNmQyZTAxNGJjOTk1ZGIwOGQ3NDhmMjdiNzklN0M3 MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0MxJTdDNjM3MDU4MDc4NjA3NzM5 ODEwJmFtcDtzZGF0YT1MdXNxa2JnMjc2QUtpSSUyRmQ1TU5FTUdZS0xjUDN5JTJGZnJIUDVMMXU2 VXFZdyUzRCZhbXA7cmVzZXJ2ZWQ9MD4uDQoNCg0KDQpEb2N1bWVudDogZHJhZnQtaWV0Zi1hY2Ut Y3d0LXByb29mLW9mLXBvc3Nlc3Npb24tMDgNCg0KUmV2aWV3ZXI6IENocmlzdGVyIEhvbG1iZXJn DQoNClJldmlldyBEYXRlOiAyMDE5LTEwLTA0DQoNCklFVEYgTEMgRW5kIERhdGU6IDIwMTktMTAt MDkNCg0KSUVTRyBUZWxlY2hhdCBkYXRlOiBOb3Qgc2NoZWR1bGVkIGZvciBhIHRlbGVjaGF0DQoN Cg0KDQpTdW1tYXJ5OiBGb3IgbW9zdCBwYXJ0IHRoZSBkb2N1bWVudCBpcyByZWFkeSwgYnV0IEkg aGF2ZSBhIGZldyBlZGl0b3JpYWwgY29tbWVudHMgYW5kIGFuIGlzc3VlLg0KDQoNCg0KTWFqb3Ig aXNzdWVzOiBOL0ENCg0KDQoNCk1pbm9yIGlzc3VlczoNCg0KDQoNClRoZSB0ZXh0IHNheXMgaW4g dGhlIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIHRoYXQgb25lIG11c3QgZW5zdXJlIHRoYXQgdGhl IG1pZ2h0IG5vdCB1bmRlcnN0YW5kIHRoZSAiY25mIiBjbGFpbSwgYW5kIHRoYXQgYXBwbGljYXRp b25zIG11c3QgZW5zdXJlIHRoYXQgcmVjZWl2ZXJzIHN1cHBvcnQgaXQuDQoNCg0KDQpRMTogSG93 IGFyZSB5b3UgZ29pbmcgdG8gZW5zdXJlIHRoYXQsIGFuZCB3aHkgZG8geW91IGhhdmUgdG8gZW5z dXJlIHRoYXQ/IFJGQw0KDQo4MzkyIGRvZXNuJ3QgZXZlbiBzZWVtIHRvIHJlcXVpcmUgdGhhdCBv bmUgbXVzdCBlbnN1cmUgdGhhdCB0aGUgcmVjZWl2ZXJzIHN1cHBvcnQgQ1dULg0KDQoNCg0KTWlr ZT4gSSBhZ3JlZSB0aGF0IHRoaXMgdGV4dCBpc24ndCBhY3R1YWxseSBhY3Rpb25hYmxlLiAgSSBw cm9wb3NlIHRoYXQgd2Ugc2ltcGx5IGRlbGV0ZSBpdC4NCg0KDQoNClEyOiBGb3IgcmVjZWl2ZXJz IHRoYXQgZG8gc3VwcG9ydCBDV1QsIFJGQyA4MzkyIHNheXMgdGhhdCB1bnN1cHBvcnRlZCBjbGFp bXMgbXVzdCBiZSBkaXNjYXJkZWQuIElmIHRoYXQgY2FuJ3QgYmUgYXBwbGllZCBmb3IgImNuZiIg SSB0aGluayB5b3UgbmVlZCB0byBleHBsYWluIHdoeS4NCg0KDQoNCk1pa2U+IFRoZSBSRkMgODM5 MiByZXF1aXJlbWVudCBkb2VzIGFwcGx5LiAgVGhpcyBpcyBhbHNvIGFsaWduZWQgd2l0aCB0aGUg dGV4dCBpbiAzLjEsIHNvIEkgZG9uJ3QgdGhpbmsgdGhlcmUgYXJlIGFueSBjaGFuZ2VzIG5lZWRl ZCB0byB0aGUgc3BlYyBmb3IgdGhpcy4NCg0KDQoNCk5pdHMvZWRpdG9yaWFsIGNvbW1lbnRzOg0K DQoNCg0KUV9FRF8xOiBQbGVhc2UgdXNlIFtSRkM4MzkyXSBpbnN0ZWFkIG9mIFtDV1RdIHdoZW4g cmVmZXJlbmNpbmcgdG8gUkZDIDgzOTIuDQoNCg0KDQpNaWtlPiBPSyDigJMgd2lsbCBkby4NCg0K DQoNClFfRURfMjogU2hhbGwgQ0JPUiBiZSBlbmhhbmNlZCBvbiBmaXJzdCBvY2N1cnJlbmNlIChp biB0aGUgQWJzdHJhY3Qgb3IgSW50cm9kdWN0aW9uKSwgb3IgaXMgaXQgb24gdGhlIGxpc3Qgb2Yg d2VsbC1rbm93biBhYmJyZXZpYXRpb25zPw0KDQoNCg0KTWlrZT4gSeKAmWQgYmUgZ2xhZCB0byBl eHBhbmQgaXQgdG8gZW5oYW5jZSByZWFkYWJpbGl0eS4NCg0KDQoNClFfRURfMzogQWRkIGEgcmVm ZXJlbmNlIGZvciBDQk9SIG1hcCBvbiBmaXJzdCBvY2N1cnJlbmNlLg0KDQoNCg0KKEkgd2FzIGxv b2tpbmcgaW4gUkZDIDcwNDksIGFuZCB3aGlsZSBpdCBtZW50aW9ucyBtYXBzIGluIG1hbnkgcGxh Y2VzIEkgY291bGQgbm90IGZpbmQgYSBwcm9wZXIgZGVmaW5pdGlvbiBmb3IgIkNCT1IgbWFwIikN Cg0KDQoNCk1pa2U+IFN1cmUuICBJIGNhbiBhZGQgYSByZWZlcmVuY2UgdG8gU2VjdGlvbiAyLjEg b2YgUkZDIDcwNDkuDQoNCg0K --_000_DM6PR00MB0569B15A50D4CA0EEA4B4DECF5920DM6PR00MB0569namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjoj OTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29QbGFpblRleHQsIGxp Lk1zb1BsYWluVGV4dCwgZGl2Lk1zb1BsYWluVGV4dA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsc2Fucy1zZXJpZjt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29u b3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0K CW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIixzYW5zLXNlcmlmO30NCnNwYW4uUGxhaW5UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToi UGxhaW4gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxp bms6IlBsYWluIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNw YW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLWNvbXBvc2U7fQ0KLk1z b0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEw LjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2Vj dGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEu MGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHls ZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQi IHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0 IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFk Pg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxk aXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5UaGFua3Mg Zm9yIHlvdXIgcmV2aWV3LCBDaHJpc3Rlci4mbmJzcDsgUmVwbGllcyBhcmUgaW5saW5lLCBwcmVm aXhlZCBieSAmcXVvdDs8c3BhbiBzdHlsZT0iY29sb3I6IzAwQjA1MCI+TWlrZSZndDs8L3NwYW4+ JnF1b3Q74oCmPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPi0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tPGJyPg0KRnJvbTogQ2hyaXN0ZXIgSG9sbWJlcmcgdmlhIERhdGF0cmFja2VyICZs dDtub3JlcGx5QGlldGYub3JnJmd0OyA8YnI+DQpTZW50OiBGcmlkYXksIE9jdG9iZXIgNCwgMjAx OSAxMDo0NCBBTTxicj4NClRvOiBnZW4tYXJ0QGlldGYub3JnPGJyPg0KQ2M6IGRyYWZ0LWlldGYt YWNlLWN3dC1wcm9vZi1vZi1wb3NzZXNzaW9uLmFsbEBpZXRmLm9yZzsgaWV0ZkBpZXRmLm9yZzsg YWNlQGlldGYub3JnPGJyPg0KU3ViamVjdDogR2VuYXJ0IGxhc3QgY2FsbCByZXZpZXcgb2YgZHJh ZnQtaWV0Zi1hY2UtY3d0LXByb29mLW9mLXBvc3Nlc3Npb24tMDg8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+UmV2aWV3ZXI6IENocmlzdGVyIEhvbG1iZXJnPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5SZXZpZXcgcmVzdWx0OiBSZWFkeSB3aXRoIElzc3Vlczxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5JIGFtIHRoZSBhc3NpZ25lZCBHZW4tQVJUIHJl dmlld2VyIGZvciB0aGlzIGRyYWZ0LiBUaGUgR2VuZXJhbCBBcmVhIFJldmlldyBUZWFtIChHZW4t QVJUKSByZXZpZXdzIGFsbCBJRVRGIGRvY3VtZW50cyBiZWluZyBwcm9jZXNzZWQgYnkgdGhlIElF U0cgZm9yIHRoZSBJRVRGIENoYWlyLiZuYnNwOyBQbGVhc2UgdHJlYXQgdGhlc2UgY29tbWVudHMg anVzdCBsaWtlIGFueSBvdGhlciBsYXN0IGNhbGwgY29tbWVudHMuPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPkZvciBtb3JlIGluZm9ybWF0aW9uLCBwbGVhc2Ugc2VlIHRoZSBGQVEgYXQ8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmx0OzxhIGhyZWY9Imh0dHBzOi8vbmFtMDYu c2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRnRyYWMu aWV0Zi5vcmclMkZ0cmFjJTJGZ2VuJTJGd2lraSUyRkdlbkFydGZhcSZhbXA7YW1wO2RhdGE9MDIl N0MwMSU3Q01pY2hhZWwuSm9uZXMlNDBtaWNyb3NvZnQuY29tJTdDNGZmYzEzNmQyZTAxNGJjOTk1 ZGIwOGQ3NDhmMjdiNzklN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0Mx JTdDNjM3MDU4MDc4NjA3NzM5ODEwJmFtcDthbXA7c2RhdGE9THVzcWtiZzI3NkFLaUklMkZkNU1O RU1HWUtMY1AzeSUyRmZySFA1TDF1NlVxWXclM0QmYW1wO2FtcDtyZXNlcnZlZD0wIj48c3BhbiBz dHlsZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+aHR0cHM6Ly9uYW0w Ni5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGdHJh Yy5pZXRmLm9yZyUyRnRyYWMlMkZnZW4lMkZ3aWtpJTJGR2VuQXJ0ZmFxJmFtcDthbXA7ZGF0YT0w MiU3QzAxJTdDTWljaGFlbC5Kb25lcyU0MG1pY3Jvc29mdC5jb20lN0M0ZmZjMTM2ZDJlMDE0YmM5 OTVkYjA4ZDc0OGYyN2I3OSU3QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3 QzElN0M2MzcwNTgwNzg2MDc3Mzk4MTAmYW1wO2FtcDtzZGF0YT1MdXNxa2JnMjc2QUtpSSUyRmQ1 TU5FTUdZS0xjUDN5JTJGZnJIUDVMMXU2VXFZdyUzRCZhbXA7YW1wO3Jlc2VydmVkPTA8L3NwYW4+ PC9hPiZndDsuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkRvY3VtZW50OiBkcmFmdC1p ZXRmLWFjZS1jd3QtcHJvb2Ytb2YtcG9zc2Vzc2lvbi0wODxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+UmV2aWV3ZXI6IENocmlzdGVyIEhvbG1iZXJnPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5SZXZpZXcgRGF0ZTogMjAxOS0xMC0wNDxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+SUVURiBMQyBFbmQgRGF0ZTogMjAx OS0xMC0wOTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+SUVTRyBUZWxl Y2hhdCBkYXRlOiBOb3Qgc2NoZWR1bGVkIGZvciBhIHRlbGVjaGF0PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPlN1bW1hcnk6IEZvciBtb3N0IHBhcnQgdGhlIGRvY3VtZW50IGlzIHJlYWR5 LCBidXQgSSBoYXZlIGEgZmV3IGVkaXRvcmlhbCBjb21tZW50cyBhbmQgYW4gaXNzdWUuPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPk1ham9yIGlzc3VlczogTi9BPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPk1pbm9yIGlzc3Vlczo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+VGhlIHRleHQgc2F5cyBpbiB0aGUgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgdGhhdCBvbmUg bXVzdCBlbnN1cmUgdGhhdCB0aGUgbWlnaHQgbm90IHVuZGVyc3RhbmQgdGhlICZxdW90O2NuZiZx dW90OyBjbGFpbSwgYW5kIHRoYXQgYXBwbGljYXRpb25zIG11c3QgZW5zdXJlIHRoYXQgcmVjZWl2 ZXJzIHN1cHBvcnQgaXQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlExOiBIb3cgYXJl IHlvdSBnb2luZyB0byBlbnN1cmUgdGhhdCwgYW5kIHdoeSBkbyB5b3UgaGF2ZSB0byBlbnN1cmUg dGhhdD8gUkZDPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij44MzkyIGRv ZXNuJ3QgZXZlbiBzZWVtIHRvIHJlcXVpcmUgdGhhdCBvbmUgbXVzdCBlbnN1cmUgdGhhdCB0aGUg cmVjZWl2ZXJzIHN1cHBvcnQgQ1dULjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3Bh biBzdHlsZT0iY29sb3I6IzAwQjA1MCI+TWlrZSZndDsgSSBhZ3JlZSB0aGF0IHRoaXMgdGV4dCBp c24ndCBhY3R1YWxseSBhY3Rpb25hYmxlLiZuYnNwOyBJIHByb3Bvc2UgdGhhdCB3ZSBzaW1wbHkg ZGVsZXRlIGl0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+UTI6IEZvciByZWNlaXZlcnMgdGhhdCBkbyBzdXBwb3J0 IENXVCwgUkZDIDgzOTIgc2F5cyB0aGF0IHVuc3VwcG9ydGVkIGNsYWltcyBtdXN0IGJlIGRpc2Nh cmRlZC4gSWYgdGhhdCBjYW4ndCBiZSBhcHBsaWVkIGZvciAmcXVvdDtjbmYmcXVvdDsgSSB0aGlu ayB5b3UgbmVlZCB0byBleHBsYWluIHdoeS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ PHNwYW4gc3R5bGU9ImNvbG9yOiMwMEIwNTAiPk1pa2UmZ3Q7IFRoZSBSRkMgODM5MiByZXF1aXJl bWVudCBkb2VzIGFwcGx5LiZuYnNwOyBUaGlzIGlzIGFsc28gYWxpZ25lZCB3aXRoIHRoZSB0ZXh0 IGluIDMuMSwgc28gSSBkb24ndCB0aGluayB0aGVyZSBhcmUgYW55IGNoYW5nZXMgbmVlZGVkIHRv IHRoZSBzcGVjIGZvciB0aGlzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Tml0cy9lZGl0b3JpYWwgY29tbWVudHM6 PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlFfRURfMTogUGxlYXNlIHVzZSBbUkZDODM5 Ml0gaW5zdGVhZCBvZiBbQ1dUXSB3aGVuIHJlZmVyZW5jaW5nIHRvIFJGQyA4MzkyLjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzAwQjA1MCI+TWlrZSZn dDsgT0sg4oCTIHdpbGwgZG8uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5RX0VEXzI6IFNoYWxsIENCT1IgYmUgZW5o YW5jZWQgb24gZmlyc3Qgb2NjdXJyZW5jZSAoaW4gdGhlIEFic3RyYWN0IG9yIEludHJvZHVjdGlv biksIG9yIGlzIGl0IG9uIHRoZSBsaXN0IG9mIHdlbGwta25vd24gYWJicmV2aWF0aW9ucz88bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMEIwNTAiPk1p a2UmZ3Q7IEnigJlkIGJlIGdsYWQgdG8gZXhwYW5kIGl0IHRvIGVuaGFuY2UgcmVhZGFiaWxpdHku PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5RX0VEXzM6IEFkZCBhIHJlZmVy ZW5jZSBmb3IgQ0JPUiBtYXAgb24gZmlyc3Qgb2NjdXJyZW5jZS48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+KEkgd2FzIGxvb2tpbmcgaW4gUkZDIDcwNDksIGFuZCB3aGlsZSBpdCBtZW50 aW9ucyBtYXBzIGluIG1hbnkgcGxhY2VzIEkgY291bGQgbm90IGZpbmQgYSBwcm9wZXIgZGVmaW5p dGlvbiBmb3IgJnF1b3Q7Q0JPUiBtYXAmcXVvdDspPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDBCMDUwIj5NaWtlJmd0OyBTdXJlLiZuYnNwOyBJIGNh biBhZGQgYSByZWZlcmVuY2UgdG8gU2VjdGlvbiAyLjEgb2YgUkZDIDcwNDkuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_DM6PR00MB0569B15A50D4CA0EEA4B4DECF5920DM6PR00MB0569namp_-- From nobody Wed Oct 16 13:21: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 0FA9A120122; Wed, 16 Oct 2019 13:21:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 Ht6VAtQPmpT3; Wed, 16 Oct 2019 13:21:05 -0700 (PDT) Received: from NAM06-DM3-obe.outbound.protection.outlook.com (mail-eopbgr640130.outbound.protection.outlook.com [40.107.64.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 163DC12008B; Wed, 16 Oct 2019 13:21:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=N/63RD9PCAwqUYdVNOptetaKpdwbuoxjGw/6W/JR6qsOFZboIo/++FcBIZXCZo4BmcTU5GgcIoysPdUUJjSE4ZWWeaU4kNfWDShgtXm1wNRicnGxLJaR8rTUGhP+QBDog9G+xV+UT5JL2NxGbaM44G6niW9a9053el9vQ4p0YNOqIeijhhE2pjL+IYTrtWHBHRKlOeloGnrQE4HsnxDGvEOMJgChuNY5nUSJmqOwqtalG9/VQZZ9Y1smJrt0LQz929QGxuwifPsT4HGfLviWCftM5r1xU5bRRodXkLoKmz4Q9YjIvV6ZLJ5qG3JHkafq+jIcAe6rt1T8AzJ0EuuN+w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Fl1M/dG6eRogy5EUVDGHn2fro4NROIpc0VTWJ426QOg=; b=B8IjtI00GlyxxRpjI546sNVW2tjXw8UsWjWA0nXAB+H1B4T2gg5IpNNzyLs04rcfG4+4MInfJb+XnhDh+OM2rejjZZVkSL1NqGTzM6lml7SreuFySB4iNoRF/tFh/E/9UPVoSQDjduPW01vy1NUMJ3tWSDW7oYdlz2DSZylZfO6I67TcZGzJ9HVszJ3HNPFqn11FmTIM+reqaVHII7ogRo43m54+oIRROa+yQcpvGI/QXbZSklVgpwH60TEoUi51QQlXRT72rzhJDCli6c1g0Ob7YixuY3EYn1dA88yoUUJlshMoFUsc5CaT2l8raIkRKZxeysjhSi2vPnU+N5MCkQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Fl1M/dG6eRogy5EUVDGHn2fro4NROIpc0VTWJ426QOg=; b=gs8Sks0KFMfcD4OQeUsbuA9S1WdeEvU/u3kBnyovKeURIriFv/ccXnCuvtBtlMnZJ7uQ90PtfwJWhW6unv2nmlLiCYzc+w/eVEag9wbbiAYIJAqptQeN+QRpOp0oegMPY0PBLxitUI+lFXDaf5x295Y65s0lylvi+skcPUL6hVI= Received: from DM6PR00MB0569.namprd00.prod.outlook.com (20.179.51.12) by DM6PR00MB0459.namprd00.prod.outlook.com (20.178.29.88) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2403.0; Wed, 16 Oct 2019 20:21:03 +0000 Received: from DM6PR00MB0569.namprd00.prod.outlook.com ([fe80::9196:77fa:83c0:9418]) by DM6PR00MB0569.namprd00.prod.outlook.com ([fe80::9196:77fa:83c0:9418%7]) with mapi id 15.20.2405.000; Wed, 16 Oct 2019 20:21:03 +0000 From: Mike Jones To: Yoav Nir , "secdir@ietf.org" CC: "draft-ietf-ace-cwt-proof-of-possession.all@ietf.org" , "ietf@ietf.org" , "ace@ietf.org" Thread-Topic: Secdir last call review of draft-ietf-ace-cwt-proof-of-possession-08 Thread-Index: AQHVfHcUHTxGfXrAZEKn6Qqm5R9W5adduhGQ Date: Wed, 16 Oct 2019 20:21:03 +0000 Message-ID: References: <157038789080.6563.18028321376777169887@ietfa.amsl.com> In-Reply-To: <157038789080.6563.18028321376777169887@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=5f10aac0-f5c3-403a-912c-000003962139; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2019-10-16T19:40:01Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [2001:4898:80e8:f:98d9:5a0a:3425:3ebe] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 7276c913-113a-4919-4045-08d752765e02 x-ms-office365-filtering-ht: Tenant x-ms-traffictypediagnostic: DM6PR00MB0459: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0192E812EC x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(136003)(396003)(376002)(366004)(346002)(39860400002)(189003)(199004)(13464003)(2501003)(14444005)(52536014)(76116006)(66574012)(54896002)(8990500004)(66946007)(66476007)(66556008)(64756008)(66446008)(4326008)(10090500001)(9686003)(71190400001)(6436002)(71200400001)(55016002)(6306002)(256004)(316002)(10290500003)(2906002)(33656002)(486006)(7736002)(186003)(478600001)(99286004)(110136005)(46003)(81166006)(76176011)(446003)(6506007)(74316002)(54906003)(53546011)(81156014)(790700001)(7696005)(25786009)(6246003)(8936002)(476003)(22452003)(6116002)(14454004)(102836004)(8676002)(229853002)(5660300002)(11346002)(86362001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR00MB0459; H:DM6PR00MB0569.namprd00.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: ULlkuBz3t+fk0O9QfDrTA/BblOv+A3zrvDDn22nRo5k/XpKuLh0lY7aj7DTjCi2aQo22hsCrSCiR0bk3HQvx5z79JT0v5Av48P/5sTwcfUizdYFTQMuhqoUiOB9TrdNOI+mjEvphMLSXoBCHgD+0fkD8kUxdW4jzLm4QHKtOC91FCkk0kNrBBJvcuXs9m6qfayP96AbypIIfdAppXj3wHz1i6TUREuNyZgMuh0Hkvnaq5r8Px9vg3Nvm3RaWjLj03OUV94rj5OxqsUgo5uUUoK4NCX/NXnBJFgtaNOnP93k0SfSPpxqNH2FCP8fqoWITzgmMPG6pMjZBJWkmJI3qaj+sZbRozFYNGkiUmeKdMOgSOZ/34mOzVPSwjN4gRvNnGknP4JnIm0XPaISvjEO/tYKRDZTuiy01hzeOESJ/uEQ= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DM6PR00MB05695230578007608306AFBCF5920DM6PR00MB0569namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 7276c913-113a-4919-4045-08d752765e02 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Oct 2019 20:21:03.2119 (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-CrossTenant-userprincipalname: ZpkapY9CfMi2RapJOpZZ71eRrxCrQu/yES9IutBz6cSZEnixdlqvqZVAPXGI0jGx/lFjnTFaA2P6GXGp5aJWLA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR00MB0459 Archived-At: Subject: Re: [Ace] Secdir last call review of draft-ietf-ace-cwt-proof-of-possession-08 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 Oct 2019 20:21:08 -0000 --_000_DM6PR00MB05695230578007608306AFBCF5920DM6PR00MB0569namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIGEgbG90IGZvciB5b3VyIHJldmlldywgWW9hdi4gIFJlcGxpZXMgYXJlIGlubGluZSwg cHJlZml4ZWQgYnkg4oCcTWlrZT7igJ3igKYNCg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQpGcm9tOiBZb2F2IE5pciB2aWEgRGF0YXRyYWNrZXIgPG5vcmVwbHlAaWV0Zi5vcmc+DQpT ZW50OiBTdW5kYXksIE9jdG9iZXIgNiwgMjAxOSAxMTo1MiBBTQ0KVG86IHNlY2RpckBpZXRmLm9y Zw0KQ2M6IGRyYWZ0LWlldGYtYWNlLWN3dC1wcm9vZi1vZi1wb3NzZXNzaW9uLmFsbEBpZXRmLm9y ZzsgaWV0ZkBpZXRmLm9yZzsgYWNlQGlldGYub3JnDQpTdWJqZWN0OiBTZWNkaXIgbGFzdCBjYWxs IHJldmlldyBvZiBkcmFmdC1pZXRmLWFjZS1jd3QtcHJvb2Ytb2YtcG9zc2Vzc2lvbi0wOA0KDQoN Cg0KUmV2aWV3ZXI6IFlvYXYgTmlyDQoNClJldmlldyByZXN1bHQ6IEhhcyBOaXRzDQoNCg0KDQpJ IGhhdmUgcmV2aWV3ZWQgdGhpcyBkb2N1bWVudCBhcyBwYXJ0IG9mIHRoZSBzZWN1cml0eSBkaXJl Y3RvcmF0ZSdzIG9uZ29pbmcgZWZmb3J0IHRvIHJldmlldyBhbGwgSUVURiBkb2N1bWVudHMgYmVp bmcgcHJvY2Vzc2VkIGJ5IHRoZSBJRVNHLiAgVGhlc2UgY29tbWVudHMgd2VyZSB3cml0dGVuIHBy aW1hcmlseSBmb3IgdGhlIGJlbmVmaXQgb2YgdGhlIHNlY3VyaXR5IGFyZWEgZGlyZWN0b3JzLg0K DQpEb2N1bWVudCBlZGl0b3JzIGFuZCBXRyBjaGFpcnMgc2hvdWxkIHRyZWF0IHRoZXNlIGNvbW1l bnRzIGp1c3QgbGlrZSBhbnkgb3RoZXIgbGFzdCBjYWxsIGNvbW1lbnRzLg0KDQoNCg0KSSB0aGlu ayB0aGUgZG9jdW1lbnQgc2hvd3MgdGhhdCBzZWN1cml0eSBhc3BlY3RzIGhhdmUgYmVlbiBjb25z aWRlcmVkIGFuZCBoYW5kbGVkIHdlbGwuIEhvd2V2ZXIsIHRoZSBkb2N1bWVudCBoYXMgaXNzdWVz IHdpdGggY2xhcml0eSBhbmQgcmVhZGFiaWxpdHk6DQoNCg0KDQpGb3Igc3RhcnRlcnMsIHRoZSBB YnN0cmFjdCBhbmQgSW50cm9kdWN0aW9uIGFyZSBuZWFybHkgaWRlbnRpY2FsLiBUaGUgSW50cm9k dWN0aW9uIGNvdWxkIGluc3RlYWQgYmUgdXNlZCB0byBleHBsYWluIHRoZSBkb21haW4sIHdobyB0 aGUgInBsYXllcnMiIGFyZSBhbmQgd2hhdCB0aGV5IGFyZSB0cnlpbmcgdG8gYWNjb21wbGlzaC4g SW5zdGVhZCwgc2VjdGlvbiAyIGludHJvZHVjZXMgdGhlIHRlcm1zIElzc3VlciwgUHJlc2VudGVy IGFuZCBSZWNpcGllbnQgd2l0aCBkZWZpbml0aW9ucyB0aGF0IHNvdW5kIGxpa2UgdGhlIENBLCB0 aGUgRW5kIEVudGl0eSBhbmQgdGhlIFJlbHlpbmcgUGFydHkgZnJvbSBQS0ksIHdpdGggYSBsaXR0 bGUgT0F1dGggdGVybWlub2xvZ3kgbWl4ZWQgaW4uIFRoZXJlIGlzIG5vIGV4cGxhbmF0aW9uIGFi b3V0IHdobyB0aGlzIGlzc3VlciBpcywgYW5kIHdoYXQgdGhlIHRydXN0IG1vZGVsIGlzLg0KDQoN Cg0KTWlrZT4gVGhpcyBkb2N1bWVudCBzdHJ1Y3R1cmUgaXMgaW50ZW50aW9uYWxseSBwYXJhbGxl bCB0byBSRkMgNzgwMC4gIEluIHBhcnRpY3VsYXIsIHRoZSBUZXJtaW5vbG9neSBzZWN0aW9uIGlz IHRoZXJlIHNwZWNpZmljYWxseSB0byBpbnRyb2R1Y2UgdGhlIHBsYXllcnMuICBZZXMsIGVkaXRv cmlhbGx5LCB0aGlzIGNvdWxkIGhhdmUgYmVlbiBkb25lIGluIHRoZSBJbnRyb2R1Y3Rpb24sIGJ1 dCB0aGlzIGlzIHRoZSBzdHlsZSB0eXBpY2FsbHkgdXNlZCBieSBPQXV0aCwgSk9TRSwgQ09TRSwg YW5kIEFDRSBzcGVjaWZpY2F0aW9ucy4gIEnigJltIHJlbHVjdGFudCB0byBkZXZpYXRlIGZyb20g aXQgaW4gdGhpcyBwYXJ0aWN1bGFyIHNwZWNpZmljYXRpb24gdW5sZXNzIHRoZXJl4oCZcyBhIGNv bXBlbGxpbmcgcmVhc29uIHRvIGRvIHNvLg0KDQoNCg0KTWlrZT4gV2hvIHRoZSBpc3N1ZXIgaXMg aXMgZGlzY3Vzc2VkIGluIHRoZSBsYXN0IHBhcmFncmFwaCBvZiBTZWN0aW9uIDMuICBUaGUgdHJ1 c3QgbW9kZWwgaXMgZGVzY3JpYmVkIGluIHRoZSBsYXN0IHBhcmFncmFwaCBvZiBTZWN0aW9uIDQg KFNlY3VyaXR5IENvbnNpZGVyYXRpb25zKS4NCg0KDQoNCk1pa2U+IFRoZXJlZm9yZSwgdW5sZXNz IHRoZXJlIGlzIGEgc3BlY2lmaWMgY2hhbmdlIHRoYXQgeW91IHdhbnQgdG8gc3VnZ2VzdCwgSSBw cm9wb3NlIHRvIGxlYXZlIHRoZSBJbnRyb2R1Y3Rpb24gYW5kIFRlcm1pbm9sb2d5IHNlY3Rpb25z IGFzIGlzLg0KDQoNCg0KVGhlIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIHNlY3Rpb24gYWxzbyBo YXMgc29tZSBwcm9ibGVtcy4gIFF1b3RpbmcgdGhlIHNlY29uZA0KDQpwYXJhZ3JhcGg6DQoNCiAg IEFwcGxpY2F0aW9ucyB1dGlsaXppbmcgcHJvb2Ygb2YgcG9zc2Vzc2lvbiBTSE9VTEQgYWxzbyB1 dGlsaXplDQoNCiAgIGF1ZGllbmNlIHJlc3RyaWN0aW9uLCBhcyBkZXNjcmliZWQgaW4gU2VjdGlv biAzLjEuMyBvZiBbQ1dUXSwgYXMgaXQNCg0KICAgcHJvdmlkZXMgYWRkaXRpb25hbCBwcm90ZWN0 aW9ucy4gIEF1ZGllbmNlIHJlc3RyaWN0aW9uIGNhbiBiZSB1c2VkIGJ5DQoNCiAgIHJlY2lwaWVu dHMgdG8gcmVqZWN0IG1lc3NhZ2VzIGludGVuZGVkIGZvciBkaWZmZXJlbnQgcmVjaXBpZW50cy4N Cg0KDQoNCldoeT8gV2h5IGlzIHRoZSBhdWQgY2xhaW0gbmVlZGVkIHdpdGggYSBjbmYgY2xhaW0g KGJ1dCBub3QgaW4gb3RoZXIgY2FzZXMpPw0KDQpOZWl0aGVyIHRoaXMgZG9jdW1lbnQgbm9yIFJG QyA4MzkyIHByb3ZpZGVzIGluc2lnaHQgYXMgdG8gd2hlbiBhdWQgaXMgYXBwcm9wcmlhdGUuIFRo YXQgdGhleSBhbGxvdyByZWNpcGllbnRzIHRvIHJlamVjdCBtZXNzYWdlcyBub3QgaW50ZW5kZWQg Zm9yIHRoZW0gZG9lcyBub3Qgc291bmQgbGlrZSBhIHNlY3VyaXR5IGZlYXR1cmUuDQoNCg0KDQpN aWtlPiBIYXZpbmcgYW4gYXVkaWVuY2UgaW4gYSB0b2tlbiBpcyBhIHNlY3VyaXR5IGZlYXR1cmUs IGFzIGl0IHByZXZlbnRzIGEgbGVnaXRpbWF0ZSB0b2tlbiBpbnRlbmRlZCBmb3Igb25lIHJlY2lw aWVudCBmcm9tIGJlaW5nIHJlcGxheWVkIHRvIGdhaW4gYWNjZXNzIGF0IGEgZGlmZmVyZW50IHJl Y2lwaWVudC4gIFlvdeKAmXJlIHJpZ2h0IHRoYXQgdGhpcyBpcyB1c2VmdWwvcmVxdWlyZWQgaW4g bWFueSBzaXR1YXRpb25zIGV2ZW4gd2hlbiDigJxjbmbigJ0gaXNu4oCZdCBiZWluZyB1c2VkLiAg SG93ZXZlciwgcmV2aWV3ZXJzIG9mIGRyYWZ0cyBvZiB3aGF0IGJlY2FtZSBSRkMgNzgwMCB3YW50 ZWQgdGhpcyB0ZXh0IGFkZGVkIHRvIHJlbWluZCBwZW9wbGUgdGhhdCBhdWRpZW5jZSByZXN0cmlj dGlvbiBpcyBvZnRlbiB1c2VmdWwgZXZlbiB3aGVuIHlvdSBoYXZlIHByb29mIG9mIHBvc3Nlc3Np b24sIGFzIGl0IGRlZmVuZHMgYWdhaW5zdCBkaWZmZXJlbnQgdGhyZWF0cy4NCg0KDQoNCk1pa2U+ IFRvIG1ha2UgdGhpcyBjbGVhcmVyLCBJIHByb3Bvc2UgdG8gYWRkIHRoaXMgcGFyZW50aGV0aWNh bCByZW1hcmsgYXQgdGhlIGVuZCBvZiB0aGlzIHBhcmFncmFwaDog4oCcKE9mIGNvdXJzZSwgYXBw bGljYXRpb25zIG5vdCB1c2luZyBwcm9vZiBvZiBwb3NzZXNzaW9uIGNhbiBhbHNvIGJlbmVmaXQg ZnJvbSB1c2luZyBhdWRpZW5jZSByZXN0cmljdGlvbiB0byByZWplY3QgbWVzc2FnZXMgaW50ZW5k ZWQgZm9yIGRpZmZlcmVudCByZWNpcGllbnRzLinigJ0gIElmIHlvdeKAmWQgcHJlZmVyIGRpZmZl cmVudCB3b3JkaW5nLCBwbGVhc2UgbGV0IG1lIGtub3cgd2hhdCBpdCBpcy4NCg0KDQoNClBhcmFn cmFwaCAzIHNheXM6ICJBIHJlY2lwaWVudCBtaWdodCBub3QgdW5kZXJzdGFuZCB0aGUgImNuZiIg Y2xhaW0uIiAgIFRoaXMNCg0KcmUtYWZmaXJtcyB0aGF0IHdlIG5lZWQgYW4gZXhwbGFuYXRpb24g b2Ygd2hvIHRoZSBwYXJ0aWVzIHRvIHRoaXMgcHJvdG9jb2wgYXJlLg0KDQpXZSBnZW5lcmFsbHkg ZG9uJ3Qgc2VuZCBtZXNzYWdlcyB0byByZWNpcGllbnRzIHRoYXQgZG9uJ3QgdW5kZXJzdGFuZCB0 aGVtLiBJcyB0aGlzIGEgY2xvc2VkIHN5c3RlbSB3aXRoIGtub3duIGVudGl0aWVzLCBvciBpcyB0 aGlzIGEgcHJvdG9jb2wgd2hlcmUgdGhlIHBhcnRpZXMgY29udGFjdCByYW5kb20gb3RoZXIgcGFy dGllcyBvbiB0aGUgSW50ZXJuZXQ/DQoNCg0KDQpNaWtlPiBQZXIgbXkgcmVzcG9uc2UgdG8gdGhl IEdlbmFydCByZXZpZXcsIHdl4oCZcmUgYWxyZWFkeSBwcm9wb3NpbmcgdG8gZGVsZXRlIHRoaXMg cGFyYWdyYXBoLCBhcyBpdOKAmXMgbm90IGFjdGlvbmFibGUuICBOb3RlIHRoYXQgdGhlIHJlcXVp cmVtZW50IHRvIGlnbm9yZSBub3QtdW5kZXJzdG9vZCBjbGFpbXMgY29tZXMgZnJvbSBTZWN0aW9u IDMgb2YgUkZDIDgzOTIgKHdoaWNoIGFsc28gd2FzIGluaGVyaXRlZCBmcm9tIFJGQyA3NTE5KSwg YW5kIHNvIGlzIG5vdCB1bmlxdWUgdG8gdGhpcyBzcGVjaWZpY2F0aW9uLg0KDQoNCg0KTWlrZT4g VGhlIGV4YWN0IHBhcnRpZXMgdG8gdGhlIHByb3RvY29sIGFyZSBkZXBlbmRlbnQgdXBvbiB0aGUg YXBwbGljYXRpb24sIGFzIGRpc2N1c3NlZCBpbiB0aGUgbGFzdCBwYXJhZ3JhcGggb2YgU2VjdGlv biA0LiAgVGhpcyBzcGVjaWZpY2F0aW9uIGlzIGRlZmluaW5nIFBvUCBrZXkgcmVwcmVzZW50YXRp b25zLiAgSXTigJlzIGludGVudGlvbmFsbHkgbGVhdmluZyB0aGUgbWVzc2FnZXMgY29udmV5aW5n IENXVHMgd2l0aCDigJxjbmbigJ0gY2xhaW1zIHVwIHRvIHRoZSBhcHBsaWNhdGlvbnMgdXNpbmcg dGhlbS4gIEFnYWluLCB0aGlzIGlzIGludGVudGlvbmFsbHkgZXhhY3RseSBwYXJhbGxlbCB0byBS RkMgNzgwMC4NCg0KDQoNCkknZCBhbHNvIGxvc2Ugc29tZSBvZiB0aGUgSW50cm9kdWN0aW9uIHRv IENyeXB0byBpbiB0aGUgc2Vjb25kLXRvLWxhc3QgcGFyYWdyYXBoLg0KDQoNCg0KTWlrZT4gSSBh Z3JlZSB0aGF0IHRoaXMgaXMgb3Zlcmx5IHBlZGFudGljLiAgSSBwcm9wb3NlIHRvIGRlbGV0ZSB0 aGUgcGFyZW50aGV0aWNhbCDigJxlLmcu4oCdIGNsYXVzZSBhdCB0aGUgZW5kLCB3aGljaCB3aWxs IG1ha2UgaXQgb25jZSBhZ2FpbiBleGFjdGx5IHBhcmFsbGVsIHRvIHRoZSBjb3JyZXNwb25kaW5n IHRleHQgaW4gUkZDIDc4MDAuICBMZXQgbWUga25vdyBpZiB5b3XigJlkIGEgc3BlY2lmaWMgZnVy dGhlciBjaGFuZ2UgdG8gdGhpcyBwYXJhZ3JhcGguDQoNCg0KDQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgVGhhbmtzLA0KDQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgLS0gTWlrZQ0KDQoNCg== --_000_DM6PR00MB05695230578007608306AFBCF5920DM6PR00MB0569namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjoj OTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29QbGFpblRleHQsIGxp Lk1zb1BsYWluVGV4dCwgZGl2Lk1zb1BsYWluVGV4dA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsc2Fucy1zZXJpZjt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29u b3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0K CW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIixzYW5zLXNlcmlmO30NCnNwYW4uUGxhaW5UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToi UGxhaW4gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxp bms6IlBsYWluIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNw YW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLWNvbXBvc2U7fQ0KLk1z b0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEw LjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2Vj dGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEu MGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHls ZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQi IHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0 IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFk Pg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxk aXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5UaGFua3Mg YSBsb3QgZm9yIHlvdXIgcmV2aWV3LCBZb2F2LiZuYnNwOyBSZXBsaWVzIGFyZSBpbmxpbmUsIHBy ZWZpeGVkIGJ5IOKAnDxzcGFuIHN0eWxlPSJjb2xvcjojMDBCMDUwIj5NaWtlJmd0Ozwvc3Bhbj7i gJ3igKY8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+LS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS08YnI+DQpGcm9tOiBZb2F2IE5pciB2aWEgRGF0YXRyYWNrZXIgJmx0O25vcmVwbHlAaWV0 Zi5vcmcmZ3Q7IDxicj4NClNlbnQ6IFN1bmRheSwgT2N0b2JlciA2LCAyMDE5IDExOjUyIEFNPGJy Pg0KVG86IHNlY2RpckBpZXRmLm9yZzxicj4NCkNjOiBkcmFmdC1pZXRmLWFjZS1jd3QtcHJvb2Yt b2YtcG9zc2Vzc2lvbi5hbGxAaWV0Zi5vcmc7IGlldGZAaWV0Zi5vcmc7IGFjZUBpZXRmLm9yZzxi cj4NClN1YmplY3Q6IFNlY2RpciBsYXN0IGNhbGwgcmV2aWV3IG9mIGRyYWZ0LWlldGYtYWNlLWN3 dC1wcm9vZi1vZi1wb3NzZXNzaW9uLTA4PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlJl dmlld2VyOiBZb2F2IE5pcjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ UmV2aWV3IHJlc3VsdDogSGFzIE5pdHM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+SSBo YXZlIHJldmlld2VkIHRoaXMgZG9jdW1lbnQgYXMgcGFydCBvZiB0aGUgc2VjdXJpdHkgZGlyZWN0 b3JhdGUncyBvbmdvaW5nIGVmZm9ydCB0byByZXZpZXcgYWxsIElFVEYgZG9jdW1lbnRzIGJlaW5n IHByb2Nlc3NlZCBieSB0aGUgSUVTRy4mbmJzcDsgVGhlc2UgY29tbWVudHMgd2VyZSB3cml0dGVu IHByaW1hcmlseSBmb3IgdGhlIGJlbmVmaXQgb2YgdGhlIHNlY3VyaXR5IGFyZWEgZGlyZWN0b3Jz LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+RG9jdW1lbnQgZWRpdG9y cyBhbmQgV0cgY2hhaXJzIHNob3VsZCB0cmVhdCB0aGVzZSBjb21tZW50cyBqdXN0IGxpa2UgYW55 IG90aGVyIGxhc3QgY2FsbCBjb21tZW50cy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ SSB0aGluayB0aGUgZG9jdW1lbnQgc2hvd3MgdGhhdCBzZWN1cml0eSBhc3BlY3RzIGhhdmUgYmVl biBjb25zaWRlcmVkIGFuZCBoYW5kbGVkIHdlbGwuIEhvd2V2ZXIsIHRoZSBkb2N1bWVudCBoYXMg aXNzdWVzIHdpdGggY2xhcml0eSBhbmQgcmVhZGFiaWxpdHk6PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPkZvciBzdGFydGVycywgdGhlIEFic3RyYWN0IGFuZCBJbnRyb2R1Y3Rpb24gYXJl IG5lYXJseSBpZGVudGljYWwuIFRoZSBJbnRyb2R1Y3Rpb24gY291bGQgaW5zdGVhZCBiZSB1c2Vk IHRvIGV4cGxhaW4gdGhlIGRvbWFpbiwgd2hvIHRoZSAmcXVvdDtwbGF5ZXJzJnF1b3Q7IGFyZSBh bmQgd2hhdCB0aGV5IGFyZSB0cnlpbmcgdG8gYWNjb21wbGlzaC4gSW5zdGVhZCwgc2VjdGlvbiAy IGludHJvZHVjZXMgdGhlIHRlcm1zIElzc3VlciwNCiBQcmVzZW50ZXIgYW5kIFJlY2lwaWVudCB3 aXRoIGRlZmluaXRpb25zIHRoYXQgc291bmQgbGlrZSB0aGUgQ0EsIHRoZSBFbmQgRW50aXR5IGFu ZCB0aGUgUmVseWluZyBQYXJ0eSBmcm9tIFBLSSwgd2l0aCBhIGxpdHRsZSBPQXV0aCB0ZXJtaW5v bG9neSBtaXhlZCBpbi4gVGhlcmUgaXMgbm8gZXhwbGFuYXRpb24gYWJvdXQgd2hvIHRoaXMgaXNz dWVyIGlzLCBhbmQgd2hhdCB0aGUgdHJ1c3QgbW9kZWwgaXMuPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDBCMDUwIj5NaWtlJmd0OyBUaGlzIGRvY3Vt ZW50IHN0cnVjdHVyZSBpcyBpbnRlbnRpb25hbGx5IHBhcmFsbGVsIHRvIFJGQyA3ODAwLiZuYnNw OyBJbiBwYXJ0aWN1bGFyLCB0aGUgVGVybWlub2xvZ3kgc2VjdGlvbiBpcyB0aGVyZSBzcGVjaWZp Y2FsbHkgdG8gaW50cm9kdWNlIHRoZSBwbGF5ZXJzLiZuYnNwOyBZZXMsIGVkaXRvcmlhbGx5LCB0 aGlzIGNvdWxkIGhhdmUgYmVlbiBkb25lIGluDQogdGhlIEludHJvZHVjdGlvbiwgYnV0IHRoaXMg aXMgdGhlIHN0eWxlIHR5cGljYWxseSB1c2VkIGJ5IE9BdXRoLCBKT1NFLCBDT1NFLCBhbmQgQUNF IHNwZWNpZmljYXRpb25zLiZuYnNwOyBJ4oCZbSByZWx1Y3RhbnQgdG8gZGV2aWF0ZSBmcm9tIGl0 IGluIHRoaXMgcGFydGljdWxhciBzcGVjaWZpY2F0aW9uIHVubGVzcyB0aGVyZeKAmXMgYSBjb21w ZWxsaW5nIHJlYXNvbiB0byBkbyBzby48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzAwQjA1MCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9y OiMwMEIwNTAiPk1pa2UmZ3Q7IFdobyB0aGUgaXNzdWVyIGlzIGlzIGRpc2N1c3NlZCBpbiB0aGUg bGFzdCBwYXJhZ3JhcGggb2YgU2VjdGlvbiAzLiZuYnNwOyBUaGUgdHJ1c3QgbW9kZWwgaXMgZGVz Y3JpYmVkIGluIHRoZSBsYXN0IHBhcmFncmFwaCBvZiBTZWN0aW9uIDQgKFNlY3VyaXR5IENvbnNp ZGVyYXRpb25zKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij48c3BhbiBzdHlsZT0iY29sb3I6IzAwQjA1MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMEIwNTAiPk1p a2UmZ3Q7IFRoZXJlZm9yZSwgdW5sZXNzIHRoZXJlIGlzIGEgc3BlY2lmaWMgY2hhbmdlIHRoYXQg eW91IHdhbnQgdG8gc3VnZ2VzdCwgSSBwcm9wb3NlIHRvIGxlYXZlIHRoZSBJbnRyb2R1Y3Rpb24g YW5kIFRlcm1pbm9sb2d5IHNlY3Rpb25zIGFzIGlzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+VGhlIFNlY3VyaXR5 IENvbnNpZGVyYXRpb25zIHNlY3Rpb24gYWxzbyBoYXMgc29tZSBwcm9ibGVtcy4mbmJzcDsgUXVv dGluZyB0aGUgc2Vjb25kPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5w YXJhZ3JhcGg6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsm bmJzcDsgQXBwbGljYXRpb25zIHV0aWxpemluZyBwcm9vZiBvZiBwb3NzZXNzaW9uIFNIT1VMRCBh bHNvIHV0aWxpemU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNw OyZuYnNwOyBhdWRpZW5jZSByZXN0cmljdGlvbiwgYXMgZGVzY3JpYmVkIGluIFNlY3Rpb24gMy4x LjMgb2YgW0NXVF0sIGFzIGl0PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mbmJzcDsmbmJzcDsgcHJvdmlkZXMgYWRkaXRpb25hbCBwcm90ZWN0aW9ucy4mbmJzcDsgQXVk aWVuY2UgcmVzdHJpY3Rpb24gY2FuIGJlIHVzZWQgYnk8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZuYnNwOyAmbmJzcDtyZWNpcGllbnRzIHRvIHJlamVjdCBtZXNzYWdl cyBpbnRlbmRlZCBmb3IgZGlmZmVyZW50IHJlY2lwaWVudHMuPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPldoeT8gV2h5IGlzIHRoZSBhdWQgY2xhaW0gbmVlZGVkIHdpdGggYSBjbmYgY2xh aW0gKGJ1dCBub3QgaW4gb3RoZXIgY2FzZXMpPw0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij5OZWl0aGVyIHRoaXMgZG9jdW1lbnQgbm9yIFJGQyA4MzkyIHByb3ZpZGVz IGluc2lnaHQgYXMgdG8gd2hlbiBhdWQgaXMgYXBwcm9wcmlhdGUuIFRoYXQgdGhleSBhbGxvdyBy ZWNpcGllbnRzIHRvIHJlamVjdCBtZXNzYWdlcyBub3QgaW50ZW5kZWQgZm9yIHRoZW0gZG9lcyBu b3Qgc291bmQgbGlrZSBhIHNlY3VyaXR5IGZlYXR1cmUuPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDBCMDUwIj5NaWtlJmd0OyBIYXZpbmcgYW4gYXVk aWVuY2UgaW4gYSB0b2tlbiBpcyBhIHNlY3VyaXR5IGZlYXR1cmUsIGFzIGl0IHByZXZlbnRzIGEg bGVnaXRpbWF0ZSB0b2tlbiBpbnRlbmRlZCBmb3Igb25lIHJlY2lwaWVudCBmcm9tIGJlaW5nIHJl cGxheWVkIHRvIGdhaW4gYWNjZXNzIGF0IGEgZGlmZmVyZW50IHJlY2lwaWVudC4mbmJzcDsgWW91 4oCZcmUgcmlnaHQgdGhhdCB0aGlzDQogaXMgdXNlZnVsL3JlcXVpcmVkIGluIG1hbnkgc2l0dWF0 aW9ucyBldmVuIHdoZW4g4oCcY25m4oCdIGlzbuKAmXQgYmVpbmcgdXNlZC4mbmJzcDsgSG93ZXZl ciwgcmV2aWV3ZXJzIG9mIGRyYWZ0cyBvZiB3aGF0IGJlY2FtZSBSRkMgNzgwMCB3YW50ZWQgdGhp cyB0ZXh0IGFkZGVkIHRvIHJlbWluZCBwZW9wbGUgdGhhdCBhdWRpZW5jZSByZXN0cmljdGlvbiBp cyBvZnRlbiB1c2VmdWwgZXZlbiB3aGVuIHlvdSBoYXZlIHByb29mIG9mIHBvc3Nlc3Npb24sIGFz IGl0IGRlZmVuZHMNCiBhZ2FpbnN0IGRpZmZlcmVudCB0aHJlYXRzLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDBCMDUw Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48 c3BhbiBzdHlsZT0iY29sb3I6IzAwQjA1MCI+TWlrZSZndDsgVG8gbWFrZSB0aGlzIGNsZWFyZXIs IEkgcHJvcG9zZSB0byBhZGQgdGhpcyBwYXJlbnRoZXRpY2FsIHJlbWFyayBhdCB0aGUgZW5kIG9m IHRoaXMgcGFyYWdyYXBoOiDigJwoT2YgY291cnNlLCBhcHBsaWNhdGlvbnMgbm90IHVzaW5nIHBy b29mIG9mIHBvc3Nlc3Npb24gY2FuIGFsc28gYmVuZWZpdCBmcm9tIHVzaW5nIGF1ZGllbmNlIHJl c3RyaWN0aW9uDQogdG8gcmVqZWN0IG1lc3NhZ2VzIGludGVuZGVkIGZvciBkaWZmZXJlbnQgcmVj aXBpZW50cy4p4oCdJm5ic3A7IElmIHlvdeKAmWQgcHJlZmVyIGRpZmZlcmVudCB3b3JkaW5nLCBw bGVhc2UgbGV0IG1lIGtub3cgd2hhdCBpdCBpcy48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPlBhcmFncmFwaCAzIHNheXM6ICZxdW90O0EgcmVjaXBpZW50IG1pZ2h0IG5vdCB1 bmRlcnN0YW5kIHRoZSAmcXVvdDtjbmYmcXVvdDsgY2xhaW0uJnF1b3Q7Jm5ic3A7Jm5ic3A7IFRo aXM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPnJlLWFmZmlybXMgdGhh dCB3ZSBuZWVkIGFuIGV4cGxhbmF0aW9uIG9mIHdobyB0aGUgcGFydGllcyB0byB0aGlzIHByb3Rv Y29sIGFyZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPldlIGdlbmVy YWxseSBkb24ndCBzZW5kIG1lc3NhZ2VzIHRvIHJlY2lwaWVudHMgdGhhdCBkb24ndCB1bmRlcnN0 YW5kIHRoZW0uIElzIHRoaXMgYSBjbG9zZWQgc3lzdGVtIHdpdGgga25vd24gZW50aXRpZXMsIG9y IGlzIHRoaXMgYSBwcm90b2NvbCB3aGVyZSB0aGUgcGFydGllcyBjb250YWN0IHJhbmRvbSBvdGhl ciBwYXJ0aWVzIG9uIHRoZSBJbnRlcm5ldD88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDBCMDUwIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzAw QjA1MCI+TWlrZSZndDsgUGVyIG15IHJlc3BvbnNlIHRvIHRoZSBHZW5hcnQgcmV2aWV3LCB3ZeKA mXJlIGFscmVhZHkgcHJvcG9zaW5nIHRvIGRlbGV0ZSB0aGlzIHBhcmFncmFwaCwgYXMgaXTigJlz IG5vdCBhY3Rpb25hYmxlLiZuYnNwOyBOb3RlIHRoYXQgdGhlIHJlcXVpcmVtZW50IHRvIGlnbm9y ZSBub3QtdW5kZXJzdG9vZCBjbGFpbXMgY29tZXMgZnJvbSBTZWN0aW9uIDMgb2YgUkZDDQogODM5 MiAod2hpY2ggYWxzbyB3YXMgaW5oZXJpdGVkIGZyb20gUkZDIDc1MTkpLCBhbmQgc28gaXMgbm90 IHVuaXF1ZSB0byB0aGlzIHNwZWNpZmljYXRpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMEIwNTAiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxl PSJjb2xvcjojMDBCMDUwIj5NaWtlJmd0OyBUaGUgZXhhY3QgcGFydGllcyB0byB0aGUgcHJvdG9j b2wgYXJlIGRlcGVuZGVudCB1cG9uIHRoZSBhcHBsaWNhdGlvbiwgYXMgZGlzY3Vzc2VkIGluIHRo ZSBsYXN0IHBhcmFncmFwaCBvZiBTZWN0aW9uIDQuJm5ic3A7IFRoaXMgc3BlY2lmaWNhdGlvbiBp cyBkZWZpbmluZyBQb1Aga2V5IHJlcHJlc2VudGF0aW9ucy4mbmJzcDsgSXTigJlzIGludGVudGlv bmFsbHkgbGVhdmluZw0KIHRoZSBtZXNzYWdlcyBjb252ZXlpbmcgQ1dUcyB3aXRoIOKAnGNuZuKA nSBjbGFpbXMgdXAgdG8gdGhlIGFwcGxpY2F0aW9ucyB1c2luZyB0aGVtLiZuYnNwOyBBZ2Fpbiwg dGhpcyBpcyBpbnRlbnRpb25hbGx5IGV4YWN0bHkgcGFyYWxsZWwgdG8gUkZDIDc4MDAuPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5JJ2QgYWxzbyBsb3NlIHNvbWUgb2YgdGhl IEludHJvZHVjdGlvbiB0byBDcnlwdG8gaW4gdGhlIHNlY29uZC10by1sYXN0IHBhcmFncmFwaC48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMEIwNTAi Pk1pa2UmZ3Q7IEkgYWdyZWUgdGhhdCB0aGlzIGlzIG92ZXJseSBwZWRhbnRpYy4mbmJzcDsgSSBw cm9wb3NlIHRvIGRlbGV0ZSB0aGUgcGFyZW50aGV0aWNhbCDigJxlLmcu4oCdIGNsYXVzZSBhdCB0 aGUgZW5kLCB3aGljaCB3aWxsIG1ha2UgaXQgb25jZSBhZ2FpbiBleGFjdGx5IHBhcmFsbGVsIHRv IHRoZSBjb3JyZXNwb25kaW5nIHRleHQgaW4gUkZDIDc4MDAuJm5ic3A7IExldCBtZSBrbm93DQog aWYgeW914oCZZCBhIHNwZWNpZmljIGZ1cnRoZXIgY2hhbmdlIHRvIHRoaXMgcGFyYWdyYXBoLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxl PSJjb2xvcjojMDBCMDUwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzAwQjA1MCI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRoYW5rcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzAwQjA1MCI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzAwQjA1MCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_DM6PR00MB05695230578007608306AFBCF5920DM6PR00MB0569namp_-- From nobody Thu Oct 17 04:12: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 AFD72120071; Thu, 17 Oct 2019 04:12:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 41nvE2ApMM0G; Thu, 17 Oct 2019 04:12:49 -0700 (PDT) Received: from mail-qt1-x829.google.com (mail-qt1-x829.google.com [IPv6:2607:f8b0:4864:20::829]) (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 C1CC6120025; Thu, 17 Oct 2019 04:12:48 -0700 (PDT) Received: by mail-qt1-x829.google.com with SMTP id v52so2915087qtb.8; Thu, 17 Oct 2019 04:12:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5PjjCRn/KhHMYMqxeessshx1+TxyY0DaZXsLzO9wTwc=; b=mVEgm/CdqiUn6h2WzzFp3VpDkwY+omsz0jIMQ0i0bvAcNNeURyFJywDFlCGOx9W+3c TolQ4PbsaruzAh05MDXKDiwY6NLawVTh5JXEnlAwAIwLUlmsSzqfYh+x7qxOyDd5jPoF oMX884Jbg/5rO8qIgqSudLjP7sch4SFWs9sBq9LSJA19pzMYnkOdTpNVdObD6GdKPMJQ FbujeiAPZG7feWdZdoRTklloD0oCIOZgN38iVDayfOlejfWtcQjQK3ZKuq2jwcQ/nn4F B5wNDsWx6RYgYpKI/seVcZ2DG59nkrt/Ren2o8+TfgekpkdDB/YyiPdB+JiBcshhP0Ov pTMQ== 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=5PjjCRn/KhHMYMqxeessshx1+TxyY0DaZXsLzO9wTwc=; b=J7TljeFJn/3bA4gb2BVg77QywBdhfpumgpiFCvlia7Sk6BBnZFPC6ifhvUglwa7qSZ v63dDtisFppEC6XOG78QYiD0R4yDcC57oBXSPurCckk5Jx5X0YB7zfcz5p8iWl5CZM// PdEULv39fZTGaJBf7HMXYVtAzuqVTLGFLoY0SKSIhs3yQzeRJaDdX+V6orJjBGOOp/bO 4aX9Vol3z2I2ORanELuyzbzevL3yJAxSwAWBs4XULDPiJHymhtGi+AzjRSqlpH83Smda Guf0OX0PrYsR1qgXzb/NmmREeFYxFN4Y8AH331UXXa4EY2SRoPXkPt+xn8zNXXjihY8T mcPQ== X-Gm-Message-State: APjAAAXNLd5uxusEFI3KC9B99+roqKFY8qifjcF4CeAQ67BNl+UZzGVl fwVH3I8qhIFjZsS697n9SBKnoO9BYVQiooGtrThvuo5P X-Google-Smtp-Source: APXvYqwlmftskYVssmQVMsoD00OAXs853BJXSVLa3S3lrkhx4wovg36ZWpZP2YPy3Ts3NWIN3phmOIcRyQhLLbyiMFo= X-Received: by 2002:a05:6214:801:: with SMTP id df1mr3222025qvb.54.1571310767598; Thu, 17 Oct 2019 04:12:47 -0700 (PDT) MIME-Version: 1.0 References: <021c01d5839c$d53206a0$7f9613e0$@augustcellars.com> In-Reply-To: <021c01d5839c$d53206a0$7f9613e0$@augustcellars.com> From: Cigdem Sengul Date: Thu, 17 Oct 2019 12:12:36 +0100 Message-ID: To: Jim Schaad Cc: draft-ietf-ace-mqtt-tls-profile@ietf.org, ace@ietf.org Content-Type: multipart/alternative; boundary="000000000000226f0e0595194c92" Archived-At: Subject: Re: [Ace] Review for draft-ietf-ace-mqtt-tls-profile-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: Thu, 17 Oct 2019 11:12:53 -0000 --000000000000226f0e0595194c92 Content-Type: text/plain; charset="UTF-8" Hello Jim, Thanks for this review. I have responded inline. > > > 1. Are there any specifics about using ACE over HTTP that need to be > explicitly stated some place. Some of these things might include: > a) Must be HTTPS even if encrypted requests/responses are > provided. > b) What types of validation are permitted/required: anon-anon, > server validation, server & client validation. The latter corresponds to > current DTLS statements. > c) Are we looking for using the normal HTTP/HTTPS ports or should > we > be using different ports? > > >> Agreed. Need to specify that it is HTTPS. Mutual authentication and server validation Required. Was thinking it would be normal HTTPS ports. Should we consider different? What scenarios should permit anon-anon; anon clients? > 2. Section 2.1.2: Somehow I missed on the first reading that you were > suggesting the use of a topic /authz-info inside of the MQTT server for > posting. I think that this needs to have a more detailed set of > instructions. I assume but don't know that initially this would mean an > anonymous connect, publish, disconnect, validated connect. This however is > not clear from the text. It is also not clear that this should be over a > TLS wrapped session for the publish. > >> OK. this was described in the Appendix. I will bring this forward in the document, as an optional flow. 3. Section 2.1.2: The correct reference is I-D.ietf-ace-dtls-authorize and > not I-D.gerdes-ace-dtls-authorize. > >> Will fix. > > 4. Section 2.1.2: It is not clear from the document is a Broker is going > to > also have the possibility of doing a post of the token via HTTPS. > Currently > I would think not, but given that this is documented in OAuth 2.0 as an > option I am not clear. > > >> Do you mean for introspection? Yes, this is a MAY as in the core document, and so in this one too. And if there is an RS-AS interaction, we expect that to be on HTTPS. I will try to see where I should clarify in the text. 5. It might make sense to break up section 2.1.2 more and cover the > different methods either in continuous paragraphs or in subsections. > >> Sure. That would increase readability. It became rather long with the new additions. > > 6. As noted before, you need to have a section on TLS requirements. This > should cover what levels/types of authentication are permitted. Some type > of statement on TLS 1.3 vs prior versions. Part of what needs to be placed > here is the fact that while there is client authentication in MQTT, there > is > no method of doing server authentication other than the surrounding TLS > protocol. Also should cover how the certificate(?) or RPK would be > validated. Use the existing rs_cnf? > >> OK. Will add that. > > 7. In Figure 2, I think the use of Client Identifier is somewhat > confusing. I think this is supposed to be the token as the Client > Identifier is a different thing in MQTT. Either that or you need to do a > better job of describing the property block. > OK. I think I should explain MQTT packets better. A connect packet has three parts: 1) Fixed header 2) Variable Header and 3) Payload. The variable header may have several properties, and Authentication Method and Authentication Data are two of these properties. According to MQTT Specification: The ClientID MUST be present and is the first field in the CONNECT packet Payload. The ClientID MUST be a UTF-8 Encoded String A Server MAY allow a Client to supply a ClientID that has a length of zero bytes, however, if it does so the Server MUST treat this as a special case. And this is what is done in the case of a collision: If the ClientID represents a Client already connected to the Server, the Server sends a DISCONNECT packet to the existing Client with Reason Code of 0x8E (Session taken over) Is this more clear? If yes, I will try to clarify in text. > 8. If the value of Clean Start or Expiry Interval are not set correct is > the server to fail the connect? > >> Agreed. This should be specified. Two options: 1) Do not accept connection or 2) accept the connection but then never create sessions, and then server MUST set Session Present to 0 in the CONNACK packet, indicating no session is present. This basically makes Clean Start flag meaningless. If this is better than client MUST be setting those parameters correctly, then we can go this way. Any thoughts? > 9. Should do a pass through the document and make sure that terms like > "AUTH (Authentication Exchange) method" are not used. I think you meant to > use 'packet' rather than method in this location. You need to be clear on > the difference between methods and packets in the document. > >>I think I should clarify this piece as well as it is MQTT terminology. I will add these to the terminology in the beginning. AUTH (Authentication Exchange): AUTH packet sent from Client to Server or Server to Client as part of an extended authentication exchange. Authentication method: String containing the name of the authentication method Authentication data: Binary Data containing authentication data. This is how these terms are defined in MQTT. Will check where the terminology is mixed up and will try to assure consistency. Could you flag particular instances where this was particularly confusing? > 10. Section 2.1.2.1 - I am having a problem computing the MAC over the > payload of the CONNECT message. The password where the value is placed is > included in the payload and I am not clear if it should be computed up to > that value or if a fixed value should be used for the computation. > > >>OK. I think it got muddled because I was trying to find a solution for a scenario where the ClientId is used across sessions, and hence, not random. Two cases. 1) Client ID uniquely random across each Client connection attempt to Broker: MAC over Payload - Payload begins with ClientID and MAY include Will Properties if Client indicated that it will have a will. 2) Client ID NOT uniquely random: MAC over Authentication Data. It may be best to choose one method and just say MUST always have a nonce in Authentication Data, and MAC is computed over that? > 11. I am worried about the text on the Client Identifier in this section. > It is not clear to me that having the client generate a random value for > this field is good just in terms of the possibility of collisions occurring > on the server. The text in the MQTT 5.0 document appears to say that this > is more interesting for the situation of getting back state that was left > on > the server after a disconnect and not so much for a clean session. > >> Yes, but as I explained for comment 7, in MQTT, the typical case is the client provides its id. However, to cater to all requirements and all implementation possibilities, maybe it is best to just use a nonce as explained for comment 10 and not tie anything to client id. Previously, when we were writing the draft for MQTT v3.1.1 we wanted to provide a solution that uses the available fields in the CONNECT packet as much as possible; without introducing any new fields. This was because of the constraints of the MQTT v3.1.1. MQTT v5 gives us more options to implement this better. For backward compatibility, we would need to think if we create a special data structure to be used in the password so that it holds both the MAC/signature and the nonce. As the use of ClientId seems to create confusion, I am leaning towards this solution. Any thoughts? > > 12. I don't know where the nonce in this section is coming from. > Discussion on where it comes from and where it is passed in the protocol is > needed. > >> As explained in 10. Will clarify in text. > 13. Is there someplace that authentication methods need to be registered? > I > was unable to see any such registry setup with OASIS from the v5 > specification. Should we suggest to the MQTT group that this is something > that should be done? > > >> This is an interesting thought. The draft was indeed discussed in the OASIS MQTT WG. But, the WG may consider this out of scope, as they have on their charter page: Transport level security is assumed and no mandatory security features will be added. The MQTT v5 draft says: The Authentication Method is commonly a SASL mechanism, and using such a registered name aids interchange. However, the Authentication Method is not constrained to using registered SASL mechanisms. 14. It would be useful to re-iterate that the authentication method for > 2.1.2.3 is still set to 'ace'. > >> Will do. > > 15. Section 2.1.3 - Please include a sentence that the signature algorithm > of "none" is explicitly not permitted for tokens. > > >> Will do. > 16. You might want to point to the updated text in the ACE Framework > document for token validation procedures as they were rewritten and contain > more or less the same content? > >> Will do and remove the repetitious text. > 17. It is not clear to me, how in the scope string is the ability to have > a > "will" indicated? > > >> If the Will Flag is set to 1, the Will Topic follows the Client ID and Will Properties in the Payload. This is where the broker learns the Will Topic. Then the scope would be publish_. And subscribes would need to subscribe_ to receive this message. Will clarify in text. 18. Section 2.1.4 - I am unsure what the implications of discarding tokens > on the end of a connection are going to be. How do you publish the token > before doing the connection or is that only for an updated token? > > >> Tokens are discarded at the end of disconnection because no previous session state is kept. And a token is expected in the new CONNECT request (otherwise, it is AS discovery) Before the connection, a token may be transported via "authz-info" topic described in Appendix B. During the connection, a new token may be transported via the AUTH packet - which enables reauthentication. > 19. Section 2.4 In the second paragraph, it appears you are saying that a > client could send an AUTH packet after receiving a DISCONNECT message. I > don't believe that is true. > >>That's a mistake indeed. I should remove DISCONNECT from that list. DISCONNECT is the last message of the session indeed. > > 20. I am not sure what the benefits of doing the check on a PINGREQUEST is > going to be. Like the relay of a PUBLISH message this is just going to > produce a DISCONNECT and a closed channel. If this is really allowed, then > you should potentially also say that the Broker could do a check based on > clock time elapsing. (I.e. do the check every hour.) > >> This was suggested by one of the reviewers that provide MQTT services (his e-mail regarding this was sent to the ace list). It was suggested as an optimization for detecting token expirations and disconnecting early. (i.e., if you are already receiving PINGREQUESTs, use these as a trigger to check the token). I think time-based checks may also help and be added as an option. > > 21. Section 2.5 - The last sentence in the first paragraph could be state > more clearly. Specifically there would appear to be some ambiguity on who > the associated tokens are attached to. "messages as long as the publisher > token for that message remains valid." Might be better. > >> Will change. > > 22. Not sure if this goes here or in the connect documentation. There > needs > to be a check that the will topic is a topic that the client is going to be > permitted to publish on. Corner case, if the ability to publish a will in > the event that this permission is lost. Does this kill the session or the > will message? I.e. should the permission for the will message be rechecked > before sending it allowing for the time based expiration of the token. > >> We have been thinking about this. If the disconnect is due to a token expiration, and hence, also includes the will topic as well, you have to decide between: 1) publish the will 2) do not publish the will. At the moment, it's written like we publish the will - but on second consideration, it seems safer to say "Publish the Will on Server Disconnect or unusual disconnect if the token (the will permission) has not expired". Thanks again for these comments, will create the necessary github issues and start revising the text. Best, > > Jim > > > > > > > > > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > --000000000000226f0e0595194c92 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Jim,
Thanks for this review. I have r= esponded inline.=C2=A0


1.=C2=A0 Are there any specifics about using ACE over HTTP that need to be<= br> explicitly stated some place.=C2=A0 Some of these things might include:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 a) Must be HTTPS even if encrypted requests/res= ponses are provided.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 b) What types of validation are permitted/requi= red: anon-anon,
server validation, server & client validation. The latter corresponds t= o
current DTLS statements.=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 c) Are we looking for using the normal HTTP/HTT= PS ports or should we
be using different ports?=C2=A0


>> Agreed. Need to specify that = it is HTTPS.
Mutual authentication and server validation Required= .
Was thinking it would be normal HTTPS ports. Should we con= sider different?
What scenarios should permit anon-anon; anon cli= ents?=C2=A0

=C2=A0
2.=C2=A0 Section 2.1.2: Somehow I missed on the first reading that you were=
suggesting the use of a topic /authz-info inside of the MQTT server for
posting.=C2=A0 =C2=A0I think that this needs to have a more detailed set of=
instructions.=C2=A0 I assume but don't know that initially this would m= ean an
anonymous connect, publish, disconnect, validated connect.=C2=A0 This howev= er is
not clear from the text.=C2=A0 It is also not clear that this should be ove= r a
TLS wrapped session for the publish.

&g= t;> OK. this was described in the Appendix. I will bring this forward in= the document, as an optional flow.=C2=A0

3.=C2=A0 Section 2.1.2: The correct reference is I-D.ietf-ace-dtls-authoriz= e and
not I-D.gerdes-ace-dtls-authorize.

>= >=C2=A0 Will fix.
=C2=A0

4.=C2=A0 Section 2.1.2: It is not clear from the document is a Broker is go= ing to
also have the possibility of doing a post of the token via HTTPS.=C2=A0 Cur= rently
I would think not, but given that this is documented in OAuth 2.0 as an
option I am not clear.

>> Do you mean for introspection? Yes, this is = a MAY as in the core document, and so in this one too.=C2=A0
And = if there is an RS-AS interaction, we expect that to be on HTTPS.=C2=A0
I will try to see where I should clarify in the text.=C2=A0

5.=C2=A0 It might make sense to break up section 2.1.2 more and cover the different methods either in continuous paragraphs or in subsections.

>> Sure. That would increase readabilit= y. It became rather long with the new additions.=C2=A0

6.=C2=A0 As noted before, you need to have a section on TLS requirements.= =C2=A0 This
should cover what levels/types of authentication are permitted.=C2=A0 Some = type
of statement on TLS 1.3 vs prior versions.=C2=A0 Part of what needs to be p= laced
here is the fact that while there is client authentication in MQTT, there i= s
no method of doing server authentication other than the surrounding TLS
protocol.=C2=A0 Also should cover how the certificate(?) or RPK would be validated.=C2=A0 Use the existing rs_cnf?

>> OK. Will add that.=C2=A0
=C2=A0

7.=C2=A0 =C2=A0In Figure 2, I think the use of Client Identifier is somewha= t
confusing.=C2=A0 I think this is supposed to be the token as the Client
Identifier is a different thing in MQTT.=C2=A0 Either that or you need to d= o a
better job of describing the property block.

OK. I think I should explain MQTT packets better.=C2=A0
A c= onnect packet has three parts: 1) Fixed header 2) Variable Header and 3) Pa= yload.
The variable header may have several properties, and Authe= ntication Method and Authentication Data are two of these properties.=C2=A0=
According to MQTT Specification:
<= div>The ClientID MUST be a UTF-8 Encoded String
And this is what is done in the cas= e of a collision:
=C2=A0
Is this more clear? If yes, I will try to c= larify in text.=C2=A0


8.=C2=A0 If the value of Clean Start or Expiry Interval are not set correct= is
the server to fail the connect?

>>= ; Agreed. This should be specified.=C2=A0
Two options: 1) Do not = accept connection or 2) accept the connection but then never create session= s, and then server=C2=A0=C2=A0MUST s= et Session Present to 0 in the CONNACK packet, indicating=C2=A0
no session is present.=C2=A0

This basically makes Clean Start flag meanin= gless.=C2=A0
If this is better than client MUST be setting those = parameters correctly, then we can go this way.=C2=A0
Any thoughts= ?


9.=C2=A0 Should do a pass through the document and make sure that terms lik= e
"AUTH (Authentication Exchange) method" are not used.=C2=A0 I thi= nk you meant to
use 'packet' rather than method in this location.=C2=A0 You need to= be clear on
the difference between methods and packets in the document.

>>I think I should clarify this piece as well as= it is MQTT terminology. I will add these to the terminology in the beginni= ng.=C2=A0

AUTH (Authentication Exchange):=C2=A0AUTH packet sent from Client to Server or Server to Client as part of a= n extended authentication exchange.=C2=A0
Authentic= ation method:=C2=A0String containing the name of the authenti= cation method
Authentication data:=C2=A0Binary Data containing authentication data.

=
This is how these terms are defined in MQTT. Will = check where the terminology is mixed up and will try to assure consistency.= Could you flag particular instances where this was particularly confusing?=


10. Section 2.1.2.1 - I am having a problem computing the MAC over the
payload of the CONNECT message.=C2=A0 The password where the value is place= d is
included in the payload and I am not clear if it should be computed up to that value or if a fixed value should be used for the computation.


>>OK. I think it got muddled bec= ause I was trying to find a solution for a scenario where the ClientId is u= sed across sessions, and hence, not random.=C2=A0

= Two cases.
1) Client ID uniquely random across each Client connec= tion attempt to Broker: MAC over Payload - Payload begins with ClientID and= MAY include Will Properties if Client indicated that it will have a will.= =C2=A0
2) Client ID NOT uniquely random: MAC over Authentication = Data.=C2=A0

It may be best to choose one method an= d just say MUST always have a nonce in Authentication Data, and MAC is comp= uted over that?

=C2=A0
11. I am worried about the text on the Client Identifier in this section. It is not clear to me that having the client generate a random value for this field is good just in terms of the possibility of collisions occurring=
on the server.=C2=A0 The text in the MQTT 5.0 document appears to say that = this
is more interesting for the situation of getting back state that was left o= n
the server after a disconnect and not so much for a clean session.

>> Yes, but as I explained for comment 7,= in MQTT, the typical case is the client provides its id.=C2=A0
H= owever, to cater to all requirements and all implementation possibilities, = maybe it is best to just use a nonce as explained for comment 10 and not ti= e anything to client id.

Previously, when we were = writing the draft for MQTT v3.1.1 we wanted to provide a solution that uses= the available fields in the CONNECT packet as much as possible; without
introducing any new fields. This was because of the constraints of = the MQTT v3.1.1. MQTT v5 gives us more options to implement this better.

For backward compatibility, we would need to think i= f we create a special data structure to be used in the password so that it = holds both the MAC/signature and the nonce.=C2=A0 =C2=A0

As the use of ClientId seems to create confusion, I am leaning towar= ds this solution. Any thoughts?
=C2=A0

12.=C2=A0 I don't know where the nonce in this section is coming from.<= br> Discussion on where it comes from and where it is passed in the protocol is=
needed.

=C2=A0>> As explained in 10. Will cl= arify in text.=C2=A0

=C2=A0
13. Is there someplace that authentication methods need to be registered?= =C2=A0 I
was unable to see any such registry setup with OASIS from the v5
specification.=C2=A0 Should we suggest to the MQTT group that this is somet= hing
that should be done?


>> This is an interesting though= t. The draft was indeed discussed in the OASIS MQTT WG.=C2=A0
But, the WG may consider this out of scope, as they have on the= ir charter page:
=C2=A0Transpo= rt level security is assumed and no mandatory security features will be add= ed.
The MQTT v5 draft says:
The Authentication= Method is commonly a SASL mechanism, and using such a registered name aids= interchange. However, the Authentication Method is not constrained to usin= g registered SASL mechanisms.
=C2=A0=C2=A0
<= div>
14.=C2=A0 It would be useful to re-iterate that the authentication method f= or
2.1.2.3 is still set to 'ace'.

= >> Will do.=C2=A0
=C2=A0

15. Section 2.1.3 - Please include a sentence that the signature algorithm<= br> of "none" is explicitly not permitted for tokens.


>> Will do.=C2=A0
=C2= =A0
16. You might want to point to the updated text in the ACE Framework
document for token validation procedures as they were rewritten and contain=
more or less the same content?

>>= Will do and remove the repetitious text.=C2=A0
=C2=A0
17.=C2=A0 It is not clear to me, how in the scope string is the ability to = have a
"will" indicated?

>>=C2=A0If the Will Flag is set to 1, th= e Will Topic follows the Client ID and Will Properties in the Payload.
This is where the broker learns the Will Topic.=C2=A0
Then the scope would be publish_<will topic&= gt;.=C2=A0
And subscribes would need to= subscribe_<will topic> to receive this message.=C2=A0<= /div>
Will clarify in text.

18.=C2=A0 Section 2.1.4 - I am unsure what the implications of discarding t= okens
on the end of a connection are going to be.=C2=A0 How do you publish the to= ken
before doing the connection or is that only for an updated token?


>> Tokens are discarded at the e= nd of disconnection because no previous session state is kept.
An= d a token is expected in the new CONNECT request (otherwise, it is AS disco= very)

Before the connection, a token may be transp= orted via=C2=A0 "authz-info" topic described in Appendix B.=C2=A0=
During the connection, a new token may be transported via the AU= TH packet - which enables reauthentication.=C2=A0
=C2=A0
19. Section 2.4=C2=A0 In the second paragraph, it appears you are saying th= at a
client could send an AUTH packet after receiving a DISCONNECT message.=C2= =A0 I
don't believe that is true.

>>= ;That's a mistake indeed. I should remove DISCONNECT from that list.=C2= =A0
DISCONNECT is the last message of the session indeed.=C2=A0= =C2=A0

20.=C2=A0 I am not sure what the benefits of doing the check on a PINGREQUE= ST is
going to be.=C2=A0 Like the relay of a PUBLISH message this is just going t= o
produce a DISCONNECT and a closed channel.=C2=A0 If this is really allowed,= then
you should potentially also say that the Broker could do a check based on clock time elapsing.=C2=A0 (I.e. do the check every hour.)
=

>> This was suggested by one of the reviewers tha= t provide MQTT services (his e-mail regarding this was sent to the ace list= ).=C2=A0
It was suggested as an optimization for detecting token = expirations and disconnecting early.=C2=A0
(i.e., if you are alre= ady receiving PINGREQUESTs, use these as a trigger to check the token).=C2= =A0
I think time-based checks may also help and be added as an op= tion.=C2=A0

21.=C2=A0 Section 2.5 - The last sentence in the first paragraph could be s= tate
more clearly.=C2=A0 Specifically there would appear to be some ambiguity on= who
the associated tokens are attached to.=C2=A0 "messages as long as the = publisher
token for that message remains valid." Might be better.

>> Will change.=C2=A0
=C2=A0

22. Not sure if this goes here or in the connect documentation.=C2=A0 There= needs
to be a check that the will topic is a topic that the client is going to be=
permitted to publish on.=C2=A0 =C2=A0Corner case, if the ability to publish= a will in
the event that this permission is lost.=C2=A0 Does this kill the session or= the
will message?=C2=A0 I.e. should the permission for the will message be rech= ecked
before sending it allowing for the time based expiration of the token.
<= /blockquote>

>> We have been thinking about this.= =C2=A0
If the disconnect is due to a token expiration, and hence,= also includes the will topic as well, you have to decide between:
1) publish the will
2) do not publish the will.=C2=A0
At the moment, it's written like we publish the will - but on second c= onsideration,=C2=A0
it seems safer to say "Publish the Will = on Server Disconnect or unusual disconnect if the token (the will permissio= n) has not expired".=C2=A0

Thanks again for t= hese comments, will create the necessary github issues and start revising t= he text.=C2=A0

Best,=C2=A0
=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
Jim









_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
--000000000000226f0e0595194c92-- From nobody Thu Oct 17 11:47: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 E8919120BF7; Thu, 17 Oct 2019 11:47:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oBxQNnNmCV8x; Thu, 17 Oct 2019 11:47:02 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4823A120BF6; Thu, 17 Oct 2019 11:46:37 -0700 (PDT) Received: from Jude (192.168.1.159) by mail2.augustcellars.com (192.168.1.201) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 17 Oct 2019 11:46:29 -0700 From: Jim Schaad To: 'Cigdem Sengul' CC: , References: <021c01d5839c$d53206a0$7f9613e0$@augustcellars.com> In-Reply-To: Date: Thu, 17 Oct 2019 11:46:27 -0700 Message-ID: <033101d5851b$30a41ad0$91ec5070$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0332_01D584E0.8447B3D0" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHeJBV4idO7pcqKU2roj2JuYf+CkgKdQ7UQpzjuY1A= Content-Language: en-us X-Originating-IP: [192.168.1.159] Archived-At: Subject: Re: [Ace] Review for draft-ietf-ace-mqtt-tls-profile-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: Thu, 17 Oct 2019 18:47:08 -0000 ------=_NextPart_000_0332_01D584E0.8447B3D0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable =20 =20 From: Cigdem Sengul =20 Sent: Thursday, October 17, 2019 4:13 AM To: Jim Schaad Cc: draft-ietf-ace-mqtt-tls-profile@ietf.org; ace@ietf.org Subject: Re: [Ace] Review for draft-ietf-ace-mqtt-tls-profile-01 =20 Hello Jim, Thanks for this review. I have responded inline.=20 1. Are there any specifics about using ACE over HTTP that need to be explicitly stated some place. Some of these things might include: a) Must be HTTPS even if encrypted requests/responses are = provided.=20 b) What types of validation are permitted/required: anon-anon, server validation, server & client validation. The latter corresponds to current DTLS statements. =20 c) Are we looking for using the normal HTTP/HTTPS ports or = should we be using different ports? =20 =20 >> Agreed. Need to specify that it is HTTPS. Mutual authentication and server validation Required.=20 Was thinking it would be normal HTTPS ports. Should we consider = different? What scenarios should permit anon-anon; anon clients?=20 =20 [JLS] If you look at my last email I went through this. Anon-anon is = going to be a bad idea because the server is never validated, however = client anon is fine since you are going to validate the client in the = MQTT protocol.=20 =20 =20 4. Section 2.1.2: It is not clear from the document is a Broker is = going to also have the possibility of doing a post of the token via HTTPS. = Currently I would think not, but given that this is documented in OAuth 2.0 as an option I am not clear. >> Do you mean for introspection? Yes, this is a MAY as in the core = document, and so in this one too.=20 And if there is an RS-AS interaction, we expect that to be on HTTPS.=20 I will try to see where I should clarify in the text.=20 =20 [JLS] No, I was originally looking at doing an HTTPS post of the token = from the client to the RS. This was before I figured out that you have = an alternative method of doing this in the MQTT protocol and so it = should not be needed. Being clear on the fact that this would not be = expected is probably a good idea. =20 7. In Figure 2, I think the use of Client Identifier is somewhat confusing. I think this is supposed to be the token as the Client Identifier is a different thing in MQTT. Either that or you need to do = a better job of describing the property block. =20 OK. I think I should explain MQTT packets better.=20 A connect packet has three parts: 1) Fixed header 2) Variable Header and = 3) Payload. The variable header may have several properties, and Authentication = Method and Authentication Data are two of these properties.=20 According to MQTT Specification: The ClientID MUST be present and is the first field in the CONNECT = packet Payload.=20 The ClientID MUST be a UTF-8 Encoded String A Server MAY allow a Client to supply a ClientID that has a length of = zero bytes, however, if it does so the Server MUST treat this as a = special case. =20 And this is what is done in the case of a collision: If the ClientID represents a Client already connected to the Server, the = Server sends a DISCONNECT packet to the existing Client with Reason Code = of 0x8E (Session taken over)=20 =20 Is this more clear? If yes, I will try to clarify in text.=20 =20 [JLS] That is not where I was having a problem. I was getting confused = by the figure itself. Labeling the figure better might help. = =E2=80=9CMQTT V5.0 CONNECT control message with =E2=80=98ace=E2=80=99 = authentication method=E2=80=9D. I would rather not have all of the = abbreviations in the title, but I can live with it. =20 8. If the value of Clean Start or Expiry Interval are not set correct = is the server to fail the connect? =20 >> Agreed. This should be specified.=20 Two options: 1) Do not accept connection or 2) accept the connection but = then never create sessions, and then server MUST set Session Present to = 0 in the CONNACK packet, indicating=20 no session is present.=20 =20 This basically makes Clean Start flag meaningless.=20 If this is better than client MUST be setting those parameters = correctly, then we can go this way.=20 Any thoughts? =20 [JLS] I don=E2=80=99t really care one way or the other. Given that = there is the return value in the CONNACK, I think that a simple = statement that the flag is set to 0 regardless of the value coming in. =20 =20 10. Section 2.1.2.1 - I am having a problem computing the MAC over the payload of the CONNECT message. The password where the value is placed = is included in the payload and I am not clear if it should be computed up = to that value or if a fixed value should be used for the computation. =20 >>OK. I think it got muddled because I was trying to find a solution for = a scenario where the ClientId is used across sessions, and hence, not = random.=20 =20 Two cases. 1) Client ID uniquely random across each Client connection attempt to = Broker: MAC over Payload - Payload begins with ClientID and MAY include = Will Properties if Client indicated that it will have a will.=20 2) Client ID NOT uniquely random: MAC over Authentication Data.=20 =20 It may be best to choose one method and just say MUST always have a = nonce in Authentication Data, and MAC is computed over that? =20 [JLS] Lets step back and look at the problem I think you are trying to = solve. =20 * If you are trying to make sure that there is not a replay of the = signature, then this would require that the server keep track of the = list of nonce values that the client has provided.=20 * If you are trying to make sure that the signature is = =E2=80=9Cfresh=E2=80=9D then the server would need to be able to provide = some type of data as part of the value being signed. As I think I have = said before the latter can be satisfied by getting your nonce value from = the TLS session using a tls-exporter. =20 If neither of these problems is trying to be solved, then there is no = need for the nonce at all. =20 =20 11. I am worried about the text on the Client Identifier in this = section. It is not clear to me that having the client generate a random value for this field is good just in terms of the possibility of collisions = occurring on the server. The text in the MQTT 5.0 document appears to say that = this is more interesting for the situation of getting back state that was = left on the server after a disconnect and not so much for a clean session. =20 >> Yes, but as I explained for comment 7, in MQTT, the typical case is = the client provides its id.=20 However, to cater to all requirements and all implementation = possibilities, maybe it is best to just use a nonce as explained for = comment 10 and not tie anything to client id. =20 Previously, when we were writing the draft for MQTT v3.1.1 we wanted to = provide a solution that uses the available fields in the CONNECT packet = as much as possible; without introducing any new fields. This was because of the constraints of the = MQTT v3.1.1. MQTT v5 gives us more options to implement this better. =20 For backward compatibility, we would need to think if we create a = special data structure to be used in the password so that it holds both = the MAC/signature and the nonce. =20 =20 As the use of ClientId seems to create confusion, I am leaning towards = this solution. Any thoughts? =20 [JLS] Look at the previous answer and the re-ask the question. =20 =20 13. Is there someplace that authentication methods need to be = registered? I was unable to see any such registry setup with OASIS from the v5 specification. Should we suggest to the MQTT group that this is = something that should be done? =20 >> This is an interesting thought. The draft was indeed discussed in the = OASIS MQTT WG.=20 =20 But, the WG may consider this out of scope, as they have on their = charter page: Transport level security is assumed and no mandatory security features = will be added. The MQTT v5 draft says: The Authentication Method is commonly a SASL mechanism, and using such a = registered name aids interchange. However, the Authentication Method is = not constrained to using registered SASL mechanisms. =20 [JLS] I think that the lack of a registry should be identified someplace = in the document. This is probably a security consideration that there = might be a different authentication method which re-uses the same = authentication method name. =20 =20 17. It is not clear to me, how in the scope string is the ability to = have a "will" indicated?=20 >> If the Will Flag is set to 1, the Will Topic follows the Client ID = and Will Properties in the Payload. This is where the broker learns the Will Topic.=20 Then the scope would be publish_.=20 And subscribes would need to subscribe_ to receive this = message.=20 Will clarify in text. =20 [JLS] publish makes sense to me. I was just being overly complicated. =20 18. Section 2.1.4 - I am unsure what the implications of discarding = tokens on the end of a connection are going to be. How do you publish the = token before doing the connection or is that only for an updated token? =20 >> Tokens are discarded at the end of disconnection because no previous = session state is kept. And a token is expected in the new CONNECT request (otherwise, it is AS = discovery) =20 Before the connection, a token may be transported via "authz-info" = topic described in Appendix B.=20 During the connection, a new token may be transported via the AUTH = packet - which enables reauthentication.=20 =20 [JLS] This is still not clear to me. Is the transport of the token via = =E2=80=9Cauth-info=E2=80=9D topic not considered to be part of the = session? If you say that you look at just the last value published, = then is there not going to be a race condition between two different = clients trying to publish and connect? =20 =20 20. I am not sure what the benefits of doing the check on a PINGREQUEST = is going to be. Like the relay of a PUBLISH message this is just going to produce a DISCONNECT and a closed channel. If this is really allowed, = then you should potentially also say that the Broker could do a check based = on clock time elapsing. (I.e. do the check every hour.) =20 >> This was suggested by one of the reviewers that provide MQTT services = (his e-mail regarding this was sent to the ace list).=20 It was suggested as an optimization for detecting token expirations and = disconnecting early.=20 (i.e., if you are already receiving PINGREQUESTs, use these as a trigger = to check the token).=20 I think time-based checks may also help and be added as an option. =20 [JLS] Ok =20 22. Not sure if this goes here or in the connect documentation. There = needs to be a check that the will topic is a topic that the client is going to = be permitted to publish on. Corner case, if the ability to publish a will = in the event that this permission is lost. Does this kill the session or = the will message? I.e. should the permission for the will message be = rechecked before sending it allowing for the time based expiration of the token. =20 >> We have been thinking about this.=20 If the disconnect is due to a token expiration, and hence, also includes = the will topic as well, you have to decide between: 1) publish the will 2) do not publish the will.=20 At the moment, it's written like we publish the will - but on second = consideration,=20 it seems safer to say "Publish the Will on Server Disconnect or unusual = disconnect if the token (the will permission) has not expired".=20 =20 [JLS] I would be fine with either position, after all at the time the = =E2=80=9Cpublish=E2=80=9D event occurred the token was valid, this is = just deferring relaying it to subscribers. =20 =20 Jim =20 =20 Thanks again for these comments, will create the necessary github issues = and start revising the text.=20 =20 Best,=20 =20 Jim _______________________________________________ Ace mailing list Ace@ietf.org =20 https://www.ietf.org/mailman/listinfo/ace ------=_NextPart_000_0332_01D584E0.8447B3D0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

 

 

From: = Cigdem Sengul <cigdem.sengul@gmail.com>
Sent: Thursday, = October 17, 2019 4:13 AM
To: Jim Schaad = <ietf@augustcellars.com>
Cc: = draft-ietf-ace-mqtt-tls-profile@ietf.org; = ace@ietf.org
Subject: Re: [Ace] Review for = draft-ietf-ace-mqtt-tls-profile-01

 

Hello Jim,

Thanks for this review. I have responded = inline. 



1.  Are there any specifics = about using ACE over HTTP that need to be
explicitly stated some = place.  Some of these things might include:
      =   a) Must be HTTPS even if encrypted requests/responses are = provided.
        b) What types of validation = are permitted/required: anon-anon,
server validation, server & = client validation. The latter corresponds to
current DTLS = statements. 
        c) Are we looking for = using the normal HTTP/HTTPS ports or should we
be using different = ports? 

 

>> Agreed. Need to specify that it is = HTTPS.

Mutual = authentication and server validation Required. =

Was thinking it would be = normal HTTPS ports. Should we consider = different?

What scenarios = should permit anon-anon; anon clients? 

 

[JLS] If you = look at my last email I went through this.=C2=A0 Anon-anon is going to = be a bad idea because the server is never validated, however client anon = is fine since you are going to validate the client in the MQTT protocol. =

 

 


4.  Section 2.1.2: It is not = clear from the document is a Broker is going to
also have the = possibility of doing a post of the token via HTTPS.  Currently
I = would think not, but given that this is documented in OAuth 2.0 as = an
option I am not clear.

>> Do you mean for introspection? Yes, this is a = MAY as in the core document, and so in this one = too. 

And if there is = an RS-AS interaction, we expect that to be on = HTTPS. 

I will try to = see where I should clarify in the text. 

 

[JLS] No, I = was originally looking at doing an HTTPS post of the token from the = client to the RS.=C2=A0 This was before I figured out that you have an = alternative method of doing this in the MQTT protocol and so it should = not be needed.=C2=A0 =C2=A0Being clear on the fact that this would not = be expected is probably a good idea.

 


7.   In Figure 2, I think the use of = Client Identifier is somewhat
confusing.  I think this is = supposed to be the token as the Client
Identifier is a different = thing in MQTT.  Either that or you need to do a
better job of = describing the property block.

 

OK. I think I should explain MQTT packets = better. 

A connect = packet has three parts: 1) Fixed header 2) Variable Header and 3) = Payload.

The variable = header may have several properties, and Authentication Method and = Authentication Data are two of these = properties. 

According to MQTT = Specification:

The ClientID MUST be a UTF-8 Encoded = String

A Server MAY allow a Client to supply a ClientID that has = a length of zero bytes, however, if it does so the Server MUST = treat this as a special case.

 

And= this is what is done in the case of a = collision:

If the ClientID represents a Client already connected to = the Server, the Server sends a DISCONNECT packet to the existing Client = with Reason Code of 0x8E (Session taken = over) 

 

Is this more clear? If yes, I will try to clarify in = text. 

 

[JLS] That is not where I was having a problem.=C2=A0 = I was getting confused by the figure itself.=C2=A0 Labeling the figure = better might help.=C2=A0 =E2=80=9CMQTT V5.0 CONNECT control message with = =E2=80=98ace=E2=80=99 authentication method=E2=80=9D.=C2=A0 I would = rather not have all of the abbreviations in the title, but I can live = with it.

 


8.  If the value of Clean Start or Expiry = Interval are not set correct is
the server to fail the = connect?

 

>> Agreed. This should be = specified. 

Two = options: 1) Do not accept connection or 2) accept the connection but = then never create sessions, and then server  MUST set Session Present to 0 in the CONNACK = packet, indicating 

no session is = present. 

 

This basically makes Clean Start flag = meaningless. 

If this = is better than client MUST be setting those parameters correctly, then = we can go this way. 

Any thoughts?

 

[JLS] I = don=E2=80=99t really care one way or the other.=C2=A0 Given that there = is the return value in the CONNACK, I think that a simple statement that = the flag is set to 0 regardless of the value coming in.=C2=A0 =

 


10. Section 2.1.2.1 - I am having a = problem computing the MAC over the
payload of the CONNECT = message.  The password where the value is placed is
included in = the payload and I am not clear if it should be computed up to
that = value or if a fixed value should be used for the = computation.

 

>>OK. I think it got muddled because I was = trying to find a solution for a scenario where the ClientId is used = across sessions, and hence, not = random. 

 

Two cases.

1) Client ID uniquely random across each Client = connection attempt to Broker: MAC over Payload - Payload begins with = ClientID and MAY include Will Properties if Client indicated that it = will have a will. 

2) = Client ID NOT uniquely random: MAC over Authentication = Data. 

 

It may be best to choose one method and just say MUST = always have a nonce in Authentication Data, and MAC is computed over = that?

 

[JLS] Lets step back and look at the problem I think = you are trying to solve.=C2=A0 =C2=A0=C2=A0

  • If you are trying to = make sure that there is not a replay of the signature, then this would = require that the server keep track of the list of nonce values that the = client has provided.
  • =C2=A0If you are = trying to make sure that the signature is =E2=80=9Cfresh=E2=80=9D then = the server would need to be able to provide some type of data as part of = the value being signed.=C2=A0 As I think I have said before the latter = can be satisfied by getting your nonce value from the TLS session using = a tls-exporter.

 

If neither = of these problems is trying to be solved, then there is no need for the = nonce at all.

 

 

11. I am = worried about the text on the Client Identifier in this section.
It = is not clear to me that having the client generate a random value = for
this field is good just in terms of the possibility of collisions = occurring
on the server.  The text in the MQTT 5.0 document = appears to say that this
is more interesting for the situation of = getting back state that was left on
the server after a disconnect and = not so much for a clean session.

 

>> Yes, but as I explained for comment 7, in = MQTT, the typical case is the client provides its = id. 

However, to = cater to all requirements and all implementation possibilities, maybe it = is best to just use a nonce as explained for comment 10 and not tie = anything to client id.

 

Previously, when we were writing the draft for MQTT = v3.1.1 we wanted to provide a solution that uses the available fields in = the CONNECT packet as much as possible; = without

introducing any = new fields. This was because of the constraints of the MQTT v3.1.1. MQTT = v5 gives us more options to implement this = better.

 

For backward compatibility, we would need to think if = we create a special data structure to be used in the password so that it = holds both the MAC/signature and the nonce.  =  

 

As the use of ClientId seems to create confusion, I am = leaning towards this solution. Any thoughts?

 

[JLS] Look = at the previous answer and the re-ask the = question.

 

 

13. Is there someplace that = authentication methods need to be registered?  I
was unable to = see any such registry setup with OASIS from the = v5
specification.  Should we suggest to the MQTT group that this = is something
that should be done?

 

>> This is an interesting thought. The draft was = indeed discussed in the OASIS MQTT WG. 

 

But, the WG may consider this out of scope, as they = have on their charter page:

 Tr= ansport level security is assumed and no mandatory security features = will be added.

The = MQTT v5 draft says:

The= Authentication Method is commonly a SASL mechanism, and using such a = registered name aids interchange. However, the Authentication Method is = not constrained to using registered SASL = mechanisms.

&nb= sp;

[JLS] I think that the lack of a registry = should be identified someplace in the document.=C2=A0 This is probably a = security consideration that there might be a different authentication = method which re-uses the same authentication method = name.

 

 

17.  It is not clear to me, how in = the scope string is the ability to have a
"will" indicated? =

>> If = the Will Flag is set to 1, the Will Topic follows the Client ID and Will = Properties in the Payload.

Thi= s is where the broker learns the Will = Topic. 

The= n the scope would be publish_<will = topic>. 

And= subscribes would need to subscribe_<will topic> to receive this = message. 

Wil= l clarify in text.

 

[JLS] publish makes sense to me.=C2=A0 I was just = being overly complicated.

 

18.  Section 2.1.4 - I am unsure = what the implications of discarding tokens
on the end of a connection = are going to be.  How do you publish the token
before doing the = connection or is that only for an updated = token?

 

>> Tokens are discarded at the end of = disconnection because no previous session state is = kept.

And a token is = expected in the new CONNECT request (otherwise, it is AS = discovery)

 

Before the connection, a token may be transported = via  "authz-info" topic described in Appendix = B. 

During the = connection, a new token may be transported via the AUTH packet - which = enables reauthentication. 

 

[JLS] This = is still not clear to me.=C2=A0 Is the transport of the token via = =E2=80=9Cauth-info=E2=80=9D topic not considered to be part of the = session?=C2=A0 If you say that you look at just the last value = published, then is there not going to be a race condition between two = different clients trying to publish and connect?=C2=A0

 


20.  I am not sure what the benefits of doing = the check on a PINGREQUEST is
going to be.  Like the relay of a = PUBLISH message this is just going to
produce a DISCONNECT and a = closed channel.  If this is really allowed, then
you should = potentially also say that the Broker could do a check based on
clock = time elapsing.  (I.e. do the check every = hour.)

 

>> This was suggested by one of the reviewers = that provide MQTT services (his e-mail regarding this was sent to the = ace list). 

It was = suggested as an optimization for detecting token expirations and = disconnecting early. 

(i.e., if you are already receiving PINGREQUESTs, use = these as a trigger to check the = token). 

I think = time-based checks may also help and be added as an = option.

 

[JLS] Ok

 


22. = Not sure if this goes here or in the connect documentation.  There = needs
to be a check that the will topic is a topic that the client is = going to be
permitted to publish on.   Corner case, if the = ability to publish a will in
the event that this permission is = lost.  Does this kill the session or the
will message?  = I.e. should the permission for the will message be rechecked
before = sending it allowing for the time based expiration of the = token.

 

>> We have been thinking about = this. 

If the = disconnect is due to a token expiration, and hence, also includes the = will topic as well, you have to decide = between:

1) publish the = will

2) do not publish the = will. 

At the moment, = it's written like we publish the will - but on second = consideration, 

it = seems safer to say "Publish the Will on Server Disconnect or = unusual disconnect if the token (the will permission) has not = expired". 

 

[JLS] I = would be fine with either position, after all at the time the = =E2=80=9Cpublish=E2=80=9D event occurred the token was valid, this is = just deferring relaying it to subscribers.=C2=A0

 

Jim

 

 

Thanks again for these comments, will create the = necessary github issues and start revising the = text. 

 

Best, 

 


Jim









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

------=_NextPart_000_0332_01D584E0.8447B3D0-- From nobody Thu Oct 17 13:06: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 D2E39120974; Thu, 17 Oct 2019 13:05:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 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_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 header.b=XF69q9zE; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=A8id5G8s 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 d4DaP8WFVxUN; Thu, 17 Oct 2019 13:05:55 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D47C120241; Thu, 17 Oct 2019 13:05:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7577; q=dns/txt; s=iport; t=1571342755; x=1572552355; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=mqpORR8+Ys7aGa7LTdPcHQ1AVlglc+/sTmISs9VJEJk=; b=XF69q9zEknARG/nRDR3BnENg2piM8CjIn9xPlarngmeTPSiCpCH9r23/ j5T48POHr1Gw1saC03nz/PJVZujIllkThGDFKn90VcNjwn4Okmw940bie 9P4w3A4ym15BHHvzsM9Xznd9Va3MJ7d6hGfN7lrzeZH0/7m5lI6Ehy8DC g=; IronPort-PHdr: =?us-ascii?q?9a23=3ABlcPshzgoA6YmvnXCy+N+z0EezQntrPoPwUc9p?= =?us-ascii?q?sgjfdUf7+++4j5YhWN/u1j2VnOW4iTq+lJjebbqejBYSQB+t7A1RJKa5lQT1?= =?us-ascii?q?kAgMQSkRYnBZudCkT+NPfsZgQxHd9JUxlu+HToeUU=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AUAADyyKhd/4cNJK1cCRoBAQEBAQE?= =?us-ascii?q?BAQEDAQEBAREBAQECAgEBAQGBaQMBAQEBCwGBSlAFbFcgBAsqh2wDilCCXIl?= =?us-ascii?q?rjhSBLhSBEANUCQEBAQwBARgNCAIBAYRAAoMGJDYHDgIDCQEBBAEBAQIBBQR?= =?us-ascii?q?thS0MhUsBAQEEAQEQKAYBASoCCAMBCwQCAQgRBAEBHxAhBgsdCAIEAQ0FCBq?= =?us-ascii?q?DAYJGAy4BAgykdgKBOIhhgieCfQEBBYE0AYNWDQuCFwMGgTQBikqBJh0YgUA?= =?us-ascii?q?/gRFGgh4uPoIaRwEBAoEsAQgKAQkEFIM+giyMa6ApQQqCIocMigqEJoI6h1G?= =?us-ascii?q?NXYFfjjCBP4ZlghCMUYI6AgQCBAUCDgEBBYFZATEsO3FwFTuCbBM9EBSBUIN?= =?us-ascii?q?zhRSFP3QKNWqNCQ0XB4InAQE?= X-IronPort-AV: E=Sophos;i="5.67,308,1566864000"; d="scan'208";a="345487769" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 17 Oct 2019 20:05:53 +0000 Received: from XCH-RCD-014.cisco.com (xch-rcd-014.cisco.com [173.37.102.24]) by alln-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id x9HK5rXT004786 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 17 Oct 2019 20:05:53 GMT Received: from xhs-rcd-001.cisco.com (173.37.227.246) by XCH-RCD-014.cisco.com (173.37.102.24) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 17 Oct 2019 15:05:52 -0500 Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 17 Oct 2019 15:05:52 -0500 Received: from NAM01-SN1-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Thu, 17 Oct 2019 16:05:51 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=KvOnz040zSIWc6Lyrrxff6bMPeTchmusXCNgotPC20QCXurMAUGvLNhWAFhcEswwk3HjFTiFah1cP3aadcVZngvd+9QEUHVlEZnBQ+bQuVDBGMBK2xJ8C9i9e7O+0HTRv27uK48JRh+jk1nuxonWt7wnlK5o0Vg6R1inAfhgoAYisrQgnoose1j6FyxNhSGTjxj0Tkq7nAXyjlSQD0+LM52tOemKNfLPwNP0p1Encq7G6qmOzpZ0yFdVI0HEMOIlwNIxy7IB0gE6mTROeIAowZyIEk/U2BNTURneofl3LWG31QWrLFBKuC7TWSS5iU8g2nCYGi81SoXJLtfAZWga8Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=VBy1V7EppHlpTH81kDSTtvBnYyv2AdAJHQCgdLNMZ7w=; b=R4Wm2fwim3ythKPCBrqveRC5Mnu2UhQz1yAOm/Exrc9SHT8WMzeD+AxelRU7oqBHNqRBwe6lKAifaNrHTpnZpDCNHuf0ZqCGlg2wycnv/AY7RmvuYcIa7W8gAcRSfNQFsW3ChJoaEUvjRMzqXCUQ0IGXeX/Xi2V5wEDQHbIAiZB68GDXgnHOdsfQKmn5MlcU9euufro1DbStrEWD2wbMZROGrrHsgb87uKuMYo5SdxMqnh15X7LR3BsGsXbIoAekc04/PkVns4D+ouG3zRSC0yoETgidpHpt48ArisfEjxZf8qI32zgHYXqs7Sjf/4iP6cyYrIaJkBg536IQYqcl+w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=VBy1V7EppHlpTH81kDSTtvBnYyv2AdAJHQCgdLNMZ7w=; b=A8id5G8sFqucys1LGS7qHhALMAETfHe3KKtxmH/sT6+hXyFXpEtOCXwcuzdTtQmXBHAsjMSigfYlKG/f5AvnV6ouZDIWzNXHAeFhAHRZrYbGvsd6WIuPgoWgUpWs77kwVxfhRFrYIwNbEo8Fz+0ddrDUxOAiFW0wKb8hoMf6eV4= Received: from BN7PR11MB2547.namprd11.prod.outlook.com (52.135.255.146) by BN7PR11MB2803.namprd11.prod.outlook.com (52.135.246.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2347.16; Thu, 17 Oct 2019 20:05:50 +0000 Received: from BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::5082:c814:2836:9e2a]) by BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::5082:c814:2836:9e2a%7]) with mapi id 15.20.2347.024; Thu, 17 Oct 2019 20:05:50 +0000 From: "Panos Kampanakis (pkampana)" To: Yaron Sheffer , "secdir@ietf.org" CC: "draft-ietf-ace-coap-est.all@ietf.org" , "ietf@ietf.org" , "ace@ietf.org" Thread-Topic: [Ace] Secdir last call review of draft-ietf-ace-coap-est-15 Thread-Index: AQHVgcaC5NivFu6vxkuLEqSa/tiqS6ddYSVAgAHm+LA= Date: Thu, 17 Oct 2019 20:05:50 +0000 Message-ID: References: <157097172245.20767.1326966836276837764@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pkampana@cisco.com; x-originating-ip: [2001:420:2090:1009:838:76da:e180:2a19] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 300cd109-7421-408e-a07d-08d7533d6854 x-ms-traffictypediagnostic: BN7PR11MB2803: x-ms-exchange-purlcount: 4 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 01930B2BA8 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(376002)(136003)(396003)(366004)(39860400002)(346002)(199004)(189003)(52084003)(13464003)(476003)(6246003)(186003)(6306002)(4326008)(5660300002)(55016002)(9686003)(81156014)(81166006)(8676002)(76116006)(66476007)(64756008)(8936002)(66946007)(66446008)(86362001)(66556008)(52536014)(76176011)(7696005)(53546011)(2501003)(6506007)(102836004)(33656002)(316002)(966005)(11346002)(7736002)(305945005)(14444005)(256004)(446003)(2906002)(54906003)(99286004)(110136005)(486006)(229853002)(6436002)(46003)(14454004)(6116002)(25786009)(71190400001)(74316002)(71200400001)(478600001); DIR:OUT; SFP:1101; SCL:1; SRVR:BN7PR11MB2803; H:BN7PR11MB2547.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: HkcfHpbta6pUBpAG/FowYDoUFyCHfnBTQXzF/3ReOjPRCLu4yyk+VYxTqI0AdQFWnWGWGhYlUFQWQBy6QUgFnrUoy9DKn+xn67c9iMdOzJ0KtP5tg/mLNTc5eOziN+My+jhveckOTi1IwHXVXs9Df/IDKszW/rXsQb3cLeSAs7vC52k9jjhQAWt7GqDw0sIDzLE+IfphKEmsHJ7E+eLGib1vER3ngjspEvgCZgSZ6YSwk8VURAAZhGpuTlfDu+/ocHej75pxii0WERIu/B4KzRXCq1a9Y86lD2kN5wLJUTfnMOYJUCUq/XnlhC06nnBbJRbtzp/kqoejPaIKkq1zmXD9fKfmRvTG25H5aaIXUZddYr94IBo48RZ6S3WZT5vkZZMi+jM0phFVH97FRzFkopOUhdGTI/0oN+GLjgu+SjgdKOCP+zncw1XmoXVHVJ+kwutkM1vBIvoufuHH9nCwyg== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 300cd109-7421-408e-a07d-08d7533d6854 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Oct 2019 20:05:50.3392 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: ERho8cwrooHKQteWL8MUrZVXWr2sEeaixdGbj6iOtaOwuPMoj/2DY8JxkRuG7rRCs9dKkT3j+Up0aj6CjcDwMQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR11MB2803 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.24, xch-rcd-014.cisco.com X-Outbound-Node: alln-core-2.cisco.com Archived-At: Subject: Re: [Ace] Secdir last call review of draft-ietf-ace-coap-est-15 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 Oct 2019 20:05:59 -0000 Hi Yaron, I addressed the remaining issues from your responses in the git issue https= ://github.com/SanKumar2015/EST-coaps/issues/152#issuecomment-543315662=20 Please check them out and let me know if you have more comments.=20 Rgs,=20 Panos -----Original Message----- From: Ace On Behalf Of Panos Kampanakis (pkampana) Sent: Wednesday, October 16, 2019 11:06 AM To: Yaron Sheffer ; secdir@ietf.org Cc: draft-ietf-ace-coap-est.all@ietf.org; ietf@ietf.org; ace@ietf.org Subject: Re: [Ace] Secdir last call review of draft-ietf-ace-coap-est-15 Hi Yaron, Thank you for the thorough review and feedback.=20 To make sure I don't miss any of your comments over an email thread, I trac= k all your feedback in git issue 152 https://github.com/SanKumar2015/EST-co= aps/issues/152 There I tried to address all your comments and question and = clarify some points.=20 I also pushed minor changes to fix a few of the issues you brought up. The = diff of the changes pushed is here https://github.com/SanKumar2015/EST-coap= s/commit/86d785f2122596f28674fe8e403d30467c98abfb=20 Please review the git issue and let us know if there are pending concerns. = Otherwise I am planning to reupload a new iteration next week.=20 Rgs,=20 Panos -----Original Message----- From: Ace On Behalf Of Yaron Sheffer via Datatracker Sent: Sunday, October 13, 2019 9:02 AM To: secdir@ietf.org Cc: draft-ietf-ace-coap-est.all@ietf.org; ietf@ietf.org; ace@ietf.org Subject: [Ace] Secdir last call review of draft-ietf-ace-coap-est-15 Reviewer: Yaron Sheffer Review result: Has Issues This document defines a new profile for EST (simple certificate enrollment)= for restricted devices, to be run on top of CoAP and DTLS, instead of the = usual HTTP and TLS. Overall, I tend to be suspicious of "restricted" profiles, and this is a ca= se in point. An implementation of DTLS is no simpler than TLS and most woul= d probably support both protocols. And basically anything supports HTTP. So= why would it make sense to define a whole new profile just to avoid using = TCP very rarely (say, for daily certificate enrollment), when this profile = even needs to include its own fragmentation/buffering mechanisms because th= e ASN.1 payloads are too long? In other words, we are introducing new and a= dditional complexity with little or no performance gain. - 2. Only certificate-based client authentication is supported. Hopefully s= ome time soon we'll be able to use PAKE here, to bootstrap the PKI. - 4. "Crypto agility is important" - this statement is somewhat meaningless= : do we require more than one cipher suite, which would ensure some level o= f agility? - Also, when we say "Sec. 4.4 of RFC 7925" do we mean *only* Sec. 4.4 or al= so the subsections: 4.4.1 etc. - "in DTLS 1.3 the Supported Elliptic Curves extension has been renamed to = Supported Groups". This is probably true for an older version of the draft,= I couldn't find anything to support it in -32. - "the Finished message must be computed" - this whole paragraph is unclear= . Are we changing the Finished/MAC computation in DTLS (if so, this must be p= ointed out very clearly)? Or are we explaining a point about channel bindin= g (if we are, this doesn't come across). - Similarly for the following paragraph: is this a performance optimizatio= n, or a change to DTLS? And by the way, why are standard session resumption= mechanisms not used? - I don't see value in the short EST URI paths given that most of the "weig= ht" is in ASN.1 data, and the paths are negligible in comparison. Moreover, if = the paths are different, shouldn't this document formally UPDATE RFC 7030? = I think it is no longer a profile. - Non-default server port: the examples include an IPv6 address in addition= to the port number. Is there a way to use relative URIs (omitting the IP a= ddress) but include a port number? The server may not know its own IP addre= ss (IPv4 with NAT) or the address may be dynamic. - The server MUST support the default /.well-known/est root resource, but t= hen in the next sentence we discuss non-default URIs. In the case of the se= rver having multiple "identities" (the main purpose of the "arbitrary label", AF= AIU), the root resource is confusing - which identity is it associated with= ? And then how is discovery managed for each identity, and is there a way to = discover the identities? - There is nowhere in this document a full formal definition of content typ= e TBD287 (a single cert). - Content type negotiation: I can see how it works for enrollment. But in t= he case of /cacerts, if the server has a list of certs in its explicit TA s= tore (e.g. to support rollover), how can TBD287 (a single cert) make sense? - It is mighty confusing to denote "content format" by "ct" (presumably, th= is stands for "content type"). - "ASN.1 encoded in binary format" - I think this should be, "DER-encoded A= SN.1, in its native binary form". - Please don't use "he" and "she" for the server and the client. Both are m= erely "it". - "The Registrar MUST authenticate and optionally authorize the client requ= ests" - this statement is too weak. The Registrar must also ensure that cli= ents only send CSRs that pertain to their authenticated identity (channel b= inding), even when POP-linking is not used. I think this is worthy of its o= wn subsection, describing the validation required for each particular EST f= low. - The following paragraph is not clear: is PoP-linking useful/recommended/m= andated in this scenario? IMO there should be some 2119 word regarding serv= er-side validation of the tls-unique. - "Table 1 contains the URI mappings between EST-coaps and EST that the Reg= istrar MUST adhere to." But the immediately preceding paragraph describes a= case where a server-side generation on the EST-coaps side is mapped to cli= ent-side generation on the EST-HTTPS side, which is not a Table 1 mapping! - "the encrypted CMS EnvelopedData blob MUST be converted at the Registrar"= - can this be done without decrypting the blob, IOW must the Registrar be = privy to the key wrapping key? - The Registrar must support resource discovery: does it mean that resource= discovery messages are simply proxied upstream, or that the Registrar pres= ents a simpler resource structure (maybe with no discovery) to its clients = while performing discovery upstream? - Security Considerations: there's a long discussion about replacing the im= plicit TAs with explicit ones. If we (rightly) mandate that the client re-v= erify the server's cert after getting the /certs response, we are losing mo= st of the minor performance gain that keeping the DTLS connection open migh= t have given us. So why not unambiguously mandate the simpler "MUST close t= he connection after /certs" instead? Besides, /cacerts is a very rare opera= tion. Why optimise it at all? - "Improper CSR requests" - what are they? What's the server supposed to do= ? Please give a reference. - A.3, response: I may be missing something, but the binary blob "3081...9f= d9" does not parse as PKCS#8 to me. _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace From nobody Fri Oct 18 15:50:50 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 25BDD12085C; Fri, 18 Oct 2019 15:50:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: internet-drafts@ietf.org To: Cc: ace@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.106.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ace@ietf.org Message-ID: <157143903999.3815.7365735405912743833@ietfa.amsl.com> Date: Fri, 18 Oct 2019 15:50:40 -0700 Archived-At: Subject: [Ace] I-D Action: draft-ietf-ace-cwt-proof-of-possession-09.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2019 22:50:45 -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 : Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs) Authors : Michael B. Jones Ludwig Seitz Göran Selander Samuel Erdtman Hannes Tschofenig Filename : draft-ietf-ace-cwt-proof-of-possession-09.txt Pages : 16 Date : 2019-10-18 Abstract: This specification describes how to declare in a CBOR Web Token (CWT) (which is defined by RFC 8392) that the presenter of the CWT possesses a particular proof-of-possession key. Being able to prove possession of a key is also sometimes described as being the holder- of-key. This specification provides equivalent functionality to "Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)" (RFC 7800) but using Concise Binary Object Representation (CBOR) and CWTs rather than JavaScript Object Notation (JSON) and JSON Web Tokens (JWTs). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ace-cwt-proof-of-possession/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ace-cwt-proof-of-possession-09 https://datatracker.ietf.org/doc/html/draft-ietf-ace-cwt-proof-of-possession-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-cwt-proof-of-possession-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Oct 18 15:57: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 B2031120046; Fri, 18 Oct 2019 15:57:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, 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=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 n5hDE2nQNR1h; Fri, 18 Oct 2019 15:57:09 -0700 (PDT) Received: from NAM06-DM3-obe.outbound.protection.outlook.com (mail-eopbgr640139.outbound.protection.outlook.com [40.107.64.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3B3312002E; Fri, 18 Oct 2019 15:57:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kXtJSWQToWxlHhloq3qJLVOCUTclkiNOAv3RTYCHpvepKtCYGhh64rvKHydC+qp3hy1N/IvBTHLPazbpbHwLaDmNX5KtmZi+DO7/lui1leIOBF2h7c+TxFYzaBQt6SL9kcyWiqwAiMeSF7Af1QSRJnXAK4ZAmfBAIfAGxiBaXuI15gS10ilp5dk3lGaxC+dv02IAJ3/dGD9oZFMkb1hyMZyF/NpZN8uLoMhFzPaBZnvXNgKri9OHkOGfF4rOiGCHtBGmF6z0nuu4bq7creQ4ut9VYbftYYDmtOwCF+/Fmu1TbhUT84sDtLrmuLbK7vXqdfzI53Dtvp7IkO6LAZ5QUQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=0zxSUOs9pgfdqVAR6yZw1aXiwtJ1tMW79BI1ZqUJiQM=; b=gNe7H/V96efW7JAgaShfBvpzA/ULrYdw/yg//J0jGsQ7/JFMBJp3zokYkHl8k93N7znJJG6fchWu83dpoaF3K9JPWk5g5yWAwUOL1D05PkG5kDxSzCo6huuEuZ7r9B9OsQiFRDtWVCgzeWlv0p+yv4Rq9u+ldoSaX/yXY6yPaFllQBUBaIF/IBza1Ne09iqFX5B9CUga5+AO+hinILXadgRdtys3SEL/MGvLjTVdH+QTp7pNI58WUb3vrlS9y+EmYRNHR4jTkCWuhSDlicO+dzToj8Wb5euL4N18bQ0zyS+5L+MWwZKR4yMeExo+KsTYCm380aJz8xrH/mekmL6EpA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=0zxSUOs9pgfdqVAR6yZw1aXiwtJ1tMW79BI1ZqUJiQM=; b=A41ksEY/0nBZRiA9jVfQ7g9pV6qvUuKGJAAX5vJqSTsoXam3tjPMmFzEGIiHqvsVDQkw3hslXwU8JmeyasrMm2njAzNCx/rtC/tLfAxw38yKhogKlvF0zOSVk6veFukTTLBdmbch0nmEwbLhwWW9vIo1xLVdTCDwAjLXddjS/fo= Received: from BYAPR00MB0565.namprd00.prod.outlook.com (20.179.56.23) by BYAPR00MB0565.namprd00.prod.outlook.com (20.179.56.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2403.0; Fri, 18 Oct 2019 22:57:06 +0000 Received: from BYAPR00MB0565.namprd00.prod.outlook.com ([fe80::4d8f:c1b3:70d4:2de4]) by BYAPR00MB0565.namprd00.prod.outlook.com ([fe80::4d8f:c1b3:70d4:2de4%5]) with mapi id 15.20.2403.000; Fri, 18 Oct 2019 22:57:06 +0000 From: Mike Jones To: Christer Holmberg , "gen-art@ietf.org" CC: "draft-ietf-ace-cwt-proof-of-possession.all@ietf.org" , "ietf@ietf.org" , "ace@ietf.org" Thread-Topic: Genart last call review of draft-ietf-ace-cwt-proof-of-possession-08 Thread-Index: AQHVettbQ32ECifdD0O+TX7Aa2ifMadduf7wgANeELA= Date: Fri, 18 Oct 2019 22:57:06 +0000 Message-ID: References: <157021105722.1446.14439223392992273252@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=92595862-c8a0-449e-9d88-0000d093eac5; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2019-10-16T19:28:15Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [50.47.93.218] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c4c9918e-fe71-4dd0-4934-08d7541e7fea x-ms-office365-filtering-ht: Tenant x-ms-traffictypediagnostic: BYAPR00MB0565: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 01949FE337 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(376002)(366004)(136003)(346002)(396003)(39860400002)(199004)(189003)(13464003)(64756008)(10290500003)(11346002)(14454004)(66946007)(316002)(54896002)(66556008)(2501003)(55016002)(71190400001)(6246003)(6436002)(71200400001)(10090500001)(606006)(476003)(76116006)(4326008)(446003)(99286004)(22452003)(110136005)(478600001)(66476007)(54906003)(6306002)(9686003)(966005)(236005)(66446008)(8990500004)(486006)(5660300002)(256004)(8936002)(26005)(66066001)(52536014)(229853002)(14444005)(76176011)(74316002)(2906002)(7736002)(53546011)(6116002)(790700001)(3846002)(7696005)(33656002)(6506007)(81156014)(81166006)(8676002)(186003)(102836004)(86362001)(25786009); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR00MB0565; H:BYAPR00MB0565.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: BCL:0; x-microsoft-antispam-message-info: 2XJKOoqMknPILxO6yUA/gdmUApD64Y8WOv9u5ezg9N1jbXagU8MO4oCHqjK2KPZSo4jzsS8twotS3kxHYXdwRk+GouBiyomz8RdvRXiMFMMJkC/Iv7wt+2A1dvkxb72CV4dK+bOQexOJUYKvEMUCZ2XLiJUyt1aGnuHqP7VmKCCzcnBIrdDr1jS1VQK/l9p/DSIQNBBvAtzFsUAX3x+nI0I814lm4XVgy+OiFFFUA4U6WLburuMavDza0r0V2mKwKCH7b8vln3Sb4jDW2QjxXrJGTW2v4n+wUI2n8OfzYNvHSHaXwiJse4B1NPkNADPbkhpDrW/Zo4vokVHj0dCq78A8efwDyJO62HsQaMQnhtYwz4OMWER8et6uYYdEns7ZFQmIJW7uCwHMnLd2ZZMlr37Ogyb5U/CBtjoLyZuVnZE= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BYAPR00MB0565E923C1482C57AFDAF0C5F56C0BYAPR00MB0565namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: c4c9918e-fe71-4dd0-4934-08d7541e7fea X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Oct 2019 22:57:06.7187 (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-CrossTenant-userprincipalname: ZUY03MUi3IfRZwM6n6mxwaErczD5EUv74a1kGu/wRjSoi3B5O9BEoEdvlPnrQgFnF1JH2VwhEvViwZzXMjH3sg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR00MB0565 Archived-At: Subject: Re: [Ace] Genart last call review of draft-ietf-ace-cwt-proof-of-possession-08 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 Oct 2019 22:57:13 -0000 --_000_BYAPR00MB0565E923C1482C57AFDAF0C5F56C0BYAPR00MB0565namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQ2hyaXN0ZXIsDQoNCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWFj ZS1jd3QtcHJvb2Ytb2YtcG9zc2Vzc2lvbi0wOSBoYXMgYmVlbiBwdWJsaXNoZWQsIHdoaWNoIGFk ZHJlc3NlcyB5b3VyIHJldmlldyBjb21tZW50cyBpbiB0aGUgd2F5cyBwcm9wb3NlZCBiZWxvdy4g IFRoYW5rcyBhZ2FpbiBmb3IgeW91ciByZXZpZXchDQoNCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBNaWtlDQoNCkZyb206IE1pa2UgSm9u ZXMNClNlbnQ6IFdlZG5lc2RheSwgT2N0b2JlciAxNiwgMjAxOSAxMjo0MCBQTQ0KVG86IENocmlz dGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+OyBnZW4tYXJ0QGll dGYub3JnDQpDYzogZHJhZnQtaWV0Zi1hY2UtY3d0LXByb29mLW9mLXBvc3Nlc3Npb24uYWxsQGll dGYub3JnOyBpZXRmQGlldGYub3JnOyBhY2VAaWV0Zi5vcmcNClN1YmplY3Q6IFJFOiBHZW5hcnQg bGFzdCBjYWxsIHJldmlldyBvZiBkcmFmdC1pZXRmLWFjZS1jd3QtcHJvb2Ytb2YtcG9zc2Vzc2lv bi0wOA0KDQoNClRoYW5rcyBmb3IgeW91ciByZXZpZXcsIENocmlzdGVyLiAgUmVwbGllcyBhcmUg aW5saW5lLCBwcmVmaXhlZCBieSAiTWlrZT4i4oCmDQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KRnJvbTogQ2hyaXN0ZXIgSG9sbWJlcmcgdmlhIERhdGF0cmFja2VyIDxub3JlcGx5 QGlldGYub3JnPG1haWx0bzpub3JlcGx5QGlldGYub3JnPj4NClNlbnQ6IEZyaWRheSwgT2N0b2Jl ciA0LCAyMDE5IDEwOjQ0IEFNDQpUbzogZ2VuLWFydEBpZXRmLm9yZzxtYWlsdG86Z2VuLWFydEBp ZXRmLm9yZz4NCkNjOiBkcmFmdC1pZXRmLWFjZS1jd3QtcHJvb2Ytb2YtcG9zc2Vzc2lvbi5hbGxA aWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LWlldGYtYWNlLWN3dC1wcm9vZi1vZi1wb3NzZXNzaW9uLmFs bEBpZXRmLm9yZz47IGlldGZAaWV0Zi5vcmc8bWFpbHRvOmlldGZAaWV0Zi5vcmc+OyBhY2VAaWV0 Zi5vcmc8bWFpbHRvOmFjZUBpZXRmLm9yZz4NClN1YmplY3Q6IEdlbmFydCBsYXN0IGNhbGwgcmV2 aWV3IG9mIGRyYWZ0LWlldGYtYWNlLWN3dC1wcm9vZi1vZi1wb3NzZXNzaW9uLTA4DQoNCg0KDQpS ZXZpZXdlcjogQ2hyaXN0ZXIgSG9sbWJlcmcNCg0KUmV2aWV3IHJlc3VsdDogUmVhZHkgd2l0aCBJ c3N1ZXMNCg0KDQoNCkkgYW0gdGhlIGFzc2lnbmVkIEdlbi1BUlQgcmV2aWV3ZXIgZm9yIHRoaXMg ZHJhZnQuIFRoZSBHZW5lcmFsIEFyZWEgUmV2aWV3IFRlYW0gKEdlbi1BUlQpIHJldmlld3MgYWxs IElFVEYgZG9jdW1lbnRzIGJlaW5nIHByb2Nlc3NlZCBieSB0aGUgSUVTRyBmb3IgdGhlIElFVEYg Q2hhaXIuICBQbGVhc2UgdHJlYXQgdGhlc2UgY29tbWVudHMganVzdCBsaWtlIGFueSBvdGhlciBs YXN0IGNhbGwgY29tbWVudHMuDQoNCg0KDQpGb3IgbW9yZSBpbmZvcm1hdGlvbiwgcGxlYXNlIHNl ZSB0aGUgRkFRIGF0DQoNCg0KDQo8aHR0cHM6Ly9uYW0wNi5zYWZlbGlua3MucHJvdGVjdGlvbi5v dXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGdHJhYy5pZXRmLm9yZyUyRnRyYWMlMkZnZW4l MkZ3aWtpJTJGR2VuQXJ0ZmFxJmFtcDtkYXRhPTAyJTdDMDElN0NNaWNoYWVsLkpvbmVzJTQwbWlj cm9zb2Z0LmNvbSU3QzRmZmMxMzZkMmUwMTRiYzk5NWRiMDhkNzQ4ZjI3Yjc5JTdDNzJmOTg4YmY4 NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN0MxJTdDMSU3QzYzNzA1ODA3ODYwNzczOTgxMCZhbXA7 c2RhdGE9THVzcWtiZzI3NkFLaUklMkZkNU1ORU1HWUtMY1AzeSUyRmZySFA1TDF1NlVxWXclM0Qm YW1wO3Jlc2VydmVkPTA+Lg0KDQoNCg0KRG9jdW1lbnQ6IGRyYWZ0LWlldGYtYWNlLWN3dC1wcm9v Zi1vZi1wb3NzZXNzaW9uLTA4DQoNClJldmlld2VyOiBDaHJpc3RlciBIb2xtYmVyZw0KDQpSZXZp ZXcgRGF0ZTogMjAxOS0xMC0wNA0KDQpJRVRGIExDIEVuZCBEYXRlOiAyMDE5LTEwLTA5DQoNCklF U0cgVGVsZWNoYXQgZGF0ZTogTm90IHNjaGVkdWxlZCBmb3IgYSB0ZWxlY2hhdA0KDQoNCg0KU3Vt bWFyeTogRm9yIG1vc3QgcGFydCB0aGUgZG9jdW1lbnQgaXMgcmVhZHksIGJ1dCBJIGhhdmUgYSBm ZXcgZWRpdG9yaWFsIGNvbW1lbnRzIGFuZCBhbiBpc3N1ZS4NCg0KDQoNCk1ham9yIGlzc3Vlczog Ti9BDQoNCg0KDQpNaW5vciBpc3N1ZXM6DQoNCg0KDQpUaGUgdGV4dCBzYXlzIGluIHRoZSBTZWN1 cml0eSBDb25zaWRlcmF0aW9ucyB0aGF0IG9uZSBtdXN0IGVuc3VyZSB0aGF0IHRoZSBtaWdodCBu b3QgdW5kZXJzdGFuZCB0aGUgImNuZiIgY2xhaW0sIGFuZCB0aGF0IGFwcGxpY2F0aW9ucyBtdXN0 IGVuc3VyZSB0aGF0IHJlY2VpdmVycyBzdXBwb3J0IGl0Lg0KDQoNCg0KUTE6IEhvdyBhcmUgeW91 IGdvaW5nIHRvIGVuc3VyZSB0aGF0LCBhbmQgd2h5IGRvIHlvdSBoYXZlIHRvIGVuc3VyZSB0aGF0 PyBSRkMNCg0KODM5MiBkb2Vzbid0IGV2ZW4gc2VlbSB0byByZXF1aXJlIHRoYXQgb25lIG11c3Qg ZW5zdXJlIHRoYXQgdGhlIHJlY2VpdmVycyBzdXBwb3J0IENXVC4NCg0KDQoNCk1pa2U+IEkgYWdy ZWUgdGhhdCB0aGlzIHRleHQgaXNuJ3QgYWN0dWFsbHkgYWN0aW9uYWJsZS4gIEkgcHJvcG9zZSB0 aGF0IHdlIHNpbXBseSBkZWxldGUgaXQuDQoNCg0KDQpRMjogRm9yIHJlY2VpdmVycyB0aGF0IGRv IHN1cHBvcnQgQ1dULCBSRkMgODM5MiBzYXlzIHRoYXQgdW5zdXBwb3J0ZWQgY2xhaW1zIG11c3Qg YmUgZGlzY2FyZGVkLiBJZiB0aGF0IGNhbid0IGJlIGFwcGxpZWQgZm9yICJjbmYiIEkgdGhpbmsg eW91IG5lZWQgdG8gZXhwbGFpbiB3aHkuDQoNCg0KDQpNaWtlPiBUaGUgUkZDIDgzOTIgcmVxdWly ZW1lbnQgZG9lcyBhcHBseS4gIFRoaXMgaXMgYWxzbyBhbGlnbmVkIHdpdGggdGhlIHRleHQgaW4g My4xLCBzbyBJIGRvbid0IHRoaW5rIHRoZXJlIGFyZSBhbnkgY2hhbmdlcyBuZWVkZWQgdG8gdGhl IHNwZWMgZm9yIHRoaXMuDQoNCg0KDQpOaXRzL2VkaXRvcmlhbCBjb21tZW50czoNCg0KDQoNClFf RURfMTogUGxlYXNlIHVzZSBbUkZDODM5Ml0gaW5zdGVhZCBvZiBbQ1dUXSB3aGVuIHJlZmVyZW5j aW5nIHRvIFJGQyA4MzkyLg0KDQoNCg0KTWlrZT4gT0sg4oCTIHdpbGwgZG8uDQoNCg0KDQpRX0VE XzI6IFNoYWxsIENCT1IgYmUgZW5oYW5jZWQgb24gZmlyc3Qgb2NjdXJyZW5jZSAoaW4gdGhlIEFi c3RyYWN0IG9yIEludHJvZHVjdGlvbiksIG9yIGlzIGl0IG9uIHRoZSBsaXN0IG9mIHdlbGwta25v d24gYWJicmV2aWF0aW9ucz8NCg0KDQoNCk1pa2U+IEnigJlkIGJlIGdsYWQgdG8gZXhwYW5kIGl0 IHRvIGVuaGFuY2UgcmVhZGFiaWxpdHkuDQoNCg0KDQpRX0VEXzM6IEFkZCBhIHJlZmVyZW5jZSBm b3IgQ0JPUiBtYXAgb24gZmlyc3Qgb2NjdXJyZW5jZS4NCg0KDQoNCihJIHdhcyBsb29raW5nIGlu IFJGQyA3MDQ5LCBhbmQgd2hpbGUgaXQgbWVudGlvbnMgbWFwcyBpbiBtYW55IHBsYWNlcyBJIGNv dWxkIG5vdCBmaW5kIGEgcHJvcGVyIGRlZmluaXRpb24gZm9yICJDQk9SIG1hcCIpDQoNCg0KDQpN aWtlPiBTdXJlLiAgSSBjYW4gYWRkIGEgcmVmZXJlbmNlIHRvIFNlY3Rpb24gMi4xIG9mIFJGQyA3 MDQ5Lg0KDQoNCg== --_000_BYAPR00MB0565E923C1482C57AFDAF0C5F56C0BYAPR00MB0565namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjoj OTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29QbGFpblRleHQsIGxp Lk1zb1BsYWluVGV4dCwgZGl2Lk1zb1BsYWluVGV4dA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsc2Fucy1zZXJpZjt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29u b3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0K CW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIixzYW5zLXNlcmlmO30NCnNwYW4uUGxhaW5UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToi UGxhaW4gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxp bms6IlBsYWluIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNw YW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsO30NCnNwYW4uRW1haWxT dHlsZTIyDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMwMDIwNjA7fQ0KLk1zb0NocERlZmF1bHQNCgl7 bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBX b3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEu MGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+ PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9 ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBt c28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0 PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0K PC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0Rjcy Ij4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBD aHJpc3RlcjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj4sPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJjb2xvcjojMDAyMDYwIj48YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtaWV0Zi1hY2UtY3d0LXByb29mLW9mLXBvc3Nlc3Npb24tMDkiPmh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWFjZS1jd3QtcHJvb2Ytb2YtcG9zc2Vzc2lvbi0wOTwvYT4g aGFzIGJlZW4gcHVibGlzaGVkLCB3aGljaCBhZGRyZXNzZXMgeW91ciByZXZpZXcgY29tbWVudHMN CiBpbiB0aGUgd2F5cyBwcm9wb3NlZCBiZWxvdy4mbmJzcDsgVGhhbmtzIGFnYWluIGZvciB5b3Vy IHJldmlldyE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iY29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtLSBNaWtlPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gTWlrZSBKb25lcyA8YnI+DQo8Yj5T ZW50OjwvYj4gV2VkbmVzZGF5LCBPY3RvYmVyIDE2LCAyMDE5IDEyOjQwIFBNPGJyPg0KPGI+VG86 PC9iPiBDaHJpc3RlciBIb2xtYmVyZyAmbHQ7Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29t Jmd0OzsgZ2VuLWFydEBpZXRmLm9yZzxicj4NCjxiPkNjOjwvYj4gZHJhZnQtaWV0Zi1hY2UtY3d0 LXByb29mLW9mLXBvc3Nlc3Npb24uYWxsQGlldGYub3JnOyBpZXRmQGlldGYub3JnOyBhY2VAaWV0 Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IEdlbmFydCBsYXN0IGNhbGwgcmV2aWV3IG9m IGRyYWZ0LWlldGYtYWNlLWN3dC1wcm9vZi1vZi1wb3NzZXNzaW9uLTA4PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5UaGFua3MgZm9yIHlvdXIgcmV2aWV3LCBDaHJp c3Rlci4mbmJzcDsgUmVwbGllcyBhcmUgaW5saW5lLCBwcmVmaXhlZCBieSAmcXVvdDs8c3BhbiBz dHlsZT0iY29sb3I6IzAwQjA1MCI+TWlrZSZndDs8L3NwYW4+JnF1b3Q74oCmPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KRnJvbTog Q2hyaXN0ZXIgSG9sbWJlcmcgdmlhIERhdGF0cmFja2VyICZsdDs8YSBocmVmPSJtYWlsdG86bm9y ZXBseUBpZXRmLm9yZyI+bm9yZXBseUBpZXRmLm9yZzwvYT4mZ3Q7DQo8YnI+DQpTZW50OiBGcmlk YXksIE9jdG9iZXIgNCwgMjAxOSAxMDo0NCBBTTxicj4NClRvOiA8YSBocmVmPSJtYWlsdG86Z2Vu LWFydEBpZXRmLm9yZyI+Z2VuLWFydEBpZXRmLm9yZzwvYT48YnI+DQpDYzogPGEgaHJlZj0ibWFp bHRvOmRyYWZ0LWlldGYtYWNlLWN3dC1wcm9vZi1vZi1wb3NzZXNzaW9uLmFsbEBpZXRmLm9yZyI+ ZHJhZnQtaWV0Zi1hY2UtY3d0LXByb29mLW9mLXBvc3Nlc3Npb24uYWxsQGlldGYub3JnPC9hPjsN CjxhIGhyZWY9Im1haWx0bzppZXRmQGlldGYub3JnIj5pZXRmQGlldGYub3JnPC9hPjsgPGEgaHJl Zj0ibWFpbHRvOmFjZUBpZXRmLm9yZyI+YWNlQGlldGYub3JnPC9hPjxicj4NClN1YmplY3Q6IEdl bmFydCBsYXN0IGNhbGwgcmV2aWV3IG9mIGRyYWZ0LWlldGYtYWNlLWN3dC1wcm9vZi1vZi1wb3Nz ZXNzaW9uLTA4PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlJldmlld2VyOiBDaHJpc3Rl ciBIb2xtYmVyZzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+UmV2aWV3 IHJlc3VsdDogUmVhZHkgd2l0aCBJc3N1ZXM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ SSBhbSB0aGUgYXNzaWduZWQgR2VuLUFSVCByZXZpZXdlciBmb3IgdGhpcyBkcmFmdC4gVGhlIEdl bmVyYWwgQXJlYSBSZXZpZXcgVGVhbSAoR2VuLUFSVCkgcmV2aWV3cyBhbGwgSUVURiBkb2N1bWVu dHMgYmVpbmcgcHJvY2Vzc2VkIGJ5IHRoZSBJRVNHIGZvciB0aGUgSUVURiBDaGFpci4mbmJzcDsg UGxlYXNlIHRyZWF0IHRoZXNlIGNvbW1lbnRzIGp1c3QgbGlrZSBhbnkgb3RoZXIgbGFzdCBjYWxs IGNvbW1lbnRzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5Gb3IgbW9yZSBpbmZvcm1h dGlvbiwgcGxlYXNlIHNlZSB0aGUgRkFRIGF0PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PiZsdDs8YSBocmVmPSJodHRwczovL25hbTA2LnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2su Y29tLz91cmw9aHR0cHMlM0ElMkYlMkZ0cmFjLmlldGYub3JnJTJGdHJhYyUyRmdlbiUyRndpa2kl MkZHZW5BcnRmYXEmYW1wO2FtcDtkYXRhPTAyJTdDMDElN0NNaWNoYWVsLkpvbmVzJTQwbWljcm9z b2Z0LmNvbSU3QzRmZmMxMzZkMmUwMTRiYzk5NWRiMDhkNzQ4ZjI3Yjc5JTdDNzJmOTg4YmY4NmYx NDFhZjkxYWIyZDdjZDAxMWRiNDclN0MxJTdDMSU3QzYzNzA1ODA3ODYwNzczOTgxMCZhbXA7YW1w O3NkYXRhPUx1c3FrYmcyNzZBS2lJJTJGZDVNTkVNR1lLTGNQM3klMkZmckhQNUwxdTZVcVl3JTNE JmFtcDthbXA7cmVzZXJ2ZWQ9MCI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1k ZWNvcmF0aW9uOm5vbmUiPmh0dHBzOi8vbmFtMDYuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9v ay5jb20vP3VybD1odHRwcyUzQSUyRiUyRnRyYWMuaWV0Zi5vcmclMkZ0cmFjJTJGZ2VuJTJGd2lr aSUyRkdlbkFydGZhcSZhbXA7YW1wO2RhdGE9MDIlN0MwMSU3Q01pY2hhZWwuSm9uZXMlNDBtaWNy b3NvZnQuY29tJTdDNGZmYzEzNmQyZTAxNGJjOTk1ZGIwOGQ3NDhmMjdiNzklN0M3MmY5ODhiZjg2 ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0MxJTdDNjM3MDU4MDc4NjA3NzM5ODEwJmFtcDth bXA7c2RhdGE9THVzcWtiZzI3NkFLaUklMkZkNU1ORU1HWUtMY1AzeSUyRmZySFA1TDF1NlVxWXcl M0QmYW1wO2FtcDtyZXNlcnZlZD0wPC9zcGFuPjwvYT4mZ3Q7LjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij5Eb2N1bWVudDogZHJhZnQtaWV0Zi1hY2UtY3d0LXByb29mLW9mLXBvc3Nlc3Np b24tMDg8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlJldmlld2VyOiBD aHJpc3RlciBIb2xtYmVyZzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ UmV2aWV3IERhdGU6IDIwMTktMTAtMDQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPklFVEYgTEMgRW5kIERhdGU6IDIwMTktMTAtMDk8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPklFU0cgVGVsZWNoYXQgZGF0ZTogTm90IHNjaGVkdWxlZCBmb3Ig YSB0ZWxlY2hhdDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5TdW1tYXJ5OiBGb3IgbW9z dCBwYXJ0IHRoZSBkb2N1bWVudCBpcyByZWFkeSwgYnV0IEkgaGF2ZSBhIGZldyBlZGl0b3JpYWwg Y29tbWVudHMgYW5kIGFuIGlzc3VlLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5NYWpv ciBpc3N1ZXM6IE4vQTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5NaW5vciBpc3N1ZXM6 PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlRoZSB0ZXh0IHNheXMgaW4gdGhlIFNlY3Vy aXR5IENvbnNpZGVyYXRpb25zIHRoYXQgb25lIG11c3QgZW5zdXJlIHRoYXQgdGhlIG1pZ2h0IG5v dCB1bmRlcnN0YW5kIHRoZSAmcXVvdDtjbmYmcXVvdDsgY2xhaW0sIGFuZCB0aGF0IGFwcGxpY2F0 aW9ucyBtdXN0IGVuc3VyZSB0aGF0IHJlY2VpdmVycyBzdXBwb3J0IGl0LjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij5RMTogSG93IGFyZSB5b3UgZ29pbmcgdG8gZW5zdXJlIHRoYXQsIGFu ZCB3aHkgZG8geW91IGhhdmUgdG8gZW5zdXJlIHRoYXQ/IFJGQzxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+ODM5MiBkb2Vzbid0IGV2ZW4gc2VlbSB0byByZXF1aXJlIHRo YXQgb25lIG11c3QgZW5zdXJlIHRoYXQgdGhlIHJlY2VpdmVycyBzdXBwb3J0IENXVC48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMEIwNTAiPk1pa2Um Z3Q7IEkgYWdyZWUgdGhhdCB0aGlzIHRleHQgaXNuJ3QgYWN0dWFsbHkgYWN0aW9uYWJsZS4mbmJz cDsgSSBwcm9wb3NlIHRoYXQgd2Ugc2ltcGx5IGRlbGV0ZSBpdC48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlEyOiBG b3IgcmVjZWl2ZXJzIHRoYXQgZG8gc3VwcG9ydCBDV1QsIFJGQyA4MzkyIHNheXMgdGhhdCB1bnN1 cHBvcnRlZCBjbGFpbXMgbXVzdCBiZSBkaXNjYXJkZWQuIElmIHRoYXQgY2FuJ3QgYmUgYXBwbGll ZCBmb3IgJnF1b3Q7Y25mJnF1b3Q7IEkgdGhpbmsgeW91IG5lZWQgdG8gZXhwbGFpbiB3aHkuPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDBCMDUwIj5N aWtlJmd0OyBUaGUgUkZDIDgzOTIgcmVxdWlyZW1lbnQgZG9lcyBhcHBseS4mbmJzcDsgVGhpcyBp cyBhbHNvIGFsaWduZWQgd2l0aCB0aGUgdGV4dCBpbiAzLjEsIHNvIEkgZG9uJ3QgdGhpbmsgdGhl cmUgYXJlIGFueSBjaGFuZ2VzIG5lZWRlZCB0byB0aGUgc3BlYyBmb3IgdGhpcy48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPk5pdHMvZWRpdG9yaWFsIGNvbW1lbnRzOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij5RX0VEXzE6IFBsZWFzZSB1c2UgW1JGQzgzOTJdIGluc3RlYWQgb2YgW0NXVF0gd2hlbiByZWZl cmVuY2luZyB0byBSRkMgODM5Mi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4g c3R5bGU9ImNvbG9yOiMwMEIwNTAiPk1pa2UmZ3Q7IE9LIOKAkyB3aWxsIGRvLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+UV9FRF8yOiBTaGFsbCBDQk9SIGJlIGVuaGFuY2VkIG9uIGZpcnN0IG9jY3VycmVuY2UgKGlu IHRoZSBBYnN0cmFjdCBvciBJbnRyb2R1Y3Rpb24pLCBvciBpcyBpdCBvbiB0aGUgbGlzdCBvZiB3 ZWxsLWtub3duIGFiYnJldmlhdGlvbnM/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxz cGFuIHN0eWxlPSJjb2xvcjojMDBCMDUwIj5NaWtlJmd0OyBJ4oCZZCBiZSBnbGFkIHRvIGV4cGFu ZCBpdCB0byBlbmhhbmNlIHJlYWRhYmlsaXR5Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+UV9FRF8zOiBBZGQgYSByZWZlcmVuY2UgZm9yIENCT1IgbWFwIG9uIGZpcnN0IG9j Y3VycmVuY2UuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPihJIHdhcyBsb29raW5nIGlu IFJGQyA3MDQ5LCBhbmQgd2hpbGUgaXQgbWVudGlvbnMgbWFwcyBpbiBtYW55IHBsYWNlcyBJIGNv dWxkIG5vdCBmaW5kIGEgcHJvcGVyIGRlZmluaXRpb24gZm9yICZxdW90O0NCT1IgbWFwJnF1b3Q7 KTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzAwQjA1 MCI+TWlrZSZndDsgU3VyZS4mbmJzcDsgSSBjYW4gYWRkIGEgcmVmZXJlbmNlIHRvIFNlY3Rpb24g Mi4xIG9mIFJGQyA3MDQ5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_BYAPR00MB0565E923C1482C57AFDAF0C5F56C0BYAPR00MB0565namp_-- From nobody Fri Oct 18 15:57: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 459571209C0; Fri, 18 Oct 2019 15:57:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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 TocsZbXy17ws; Fri, 18 Oct 2019 15:57:40 -0700 (PDT) Received: from NAM06-DM3-obe.outbound.protection.outlook.com (mail-dm3nam06on0705.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe56::705]) (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 E0A9B120979; Fri, 18 Oct 2019 15:57:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ScIc5yGX7lvGAAR4TZNSXq2ATV8aSQg5TL/yVFw1tMohliKECVtIfgViw8p3pLmZzBkgbbLqV5nJ9NI37Nol2kUY6yxqBh/gAyL8C1UlR2Nm2bnbUR6vOAWFI3vnKDtS8Lr2/+g8pjQQ+ZtAALPiQrt9z119J6EAudnZkQYkJFdSp/KfJrSMWg5NCsIGbJVQu1EVIz6V4Hru6Ychna5BVL80p97roLwsOojZl+d6LWvP3qBOrU3N3fiZax2yhihs11SWpJUlQzWOEo823wiC1W5yInPO+T2QLXmLGJNUuCIsJ92Bdl1a7806xwblNhzG+MLfA1h5IPGR11M5MtqiRA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=GHiIrx7YCp8ifNnsC1qHyALcebOkMXvV31Aqb01WRJg=; b=JhefbyljEyU4AB4lGP/gn2uiNVSTNub60uwTvusz/rqZInMvrfspvLukWeDtVI3FCWLnbOo/Qbfi9m806TNGWUgc1YGyKTOhNm3cQI6oHyNESiLcIBN5eDwDSCM8tI4DeMRHcZ+CNIT0FQFnunh7fB5SnyXQfjTUmZAJyjw2KyPUmB+Mlm6ejtlvzcfNqQlqcUGvDJ9KINIAQmlKlIakY5Us1+B6wacN1iGCBiPSufEGHpcPVMoJ0gMQaDBAnrWcoO1lDVyS7wS+HH8v64BUjo9kujkFxnJstaQqke5vnM4gt36l7JPyg/LAs0jzgsiVjCYbNvzBfbhBgjSM9G6tbw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=GHiIrx7YCp8ifNnsC1qHyALcebOkMXvV31Aqb01WRJg=; b=jwxtJory/lAgU3B/nE+y6WUBEnxztr479u/vcMw3jpRBt6EsjyG3iW3AxaTmyQqB+anzDzv2ZSvQT8o3KEGNZmmYtKX98uroPuvIXSIo2YqKtX94AmiBLTWwa208luTo73ebCeZrPazhec2MxS9rsOCBUuz8Gpn184+JQ0oeulE= Received: from BYAPR00MB0565.namprd00.prod.outlook.com (20.179.56.23) by BYAPR00MB0565.namprd00.prod.outlook.com (20.179.56.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2403.0; Fri, 18 Oct 2019 22:57:37 +0000 Received: from BYAPR00MB0565.namprd00.prod.outlook.com ([fe80::4d8f:c1b3:70d4:2de4]) by BYAPR00MB0565.namprd00.prod.outlook.com ([fe80::4d8f:c1b3:70d4:2de4%5]) with mapi id 15.20.2403.000; Fri, 18 Oct 2019 22:57:36 +0000 From: Mike Jones To: Yoav Nir , "secdir@ietf.org" CC: "draft-ietf-ace-cwt-proof-of-possession.all@ietf.org" , "ietf@ietf.org" , "ace@ietf.org" Thread-Topic: Secdir last call review of draft-ietf-ace-cwt-proof-of-possession-08 Thread-Index: AQHVfHcUHTxGfXrAZEKn6Qqm5R9W5adduhGQgANbx6A= Date: Fri, 18 Oct 2019 22:57:36 +0000 Message-ID: References: <157038789080.6563.18028321376777169887@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=5f10aac0-f5c3-403a-912c-000003962139; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2019-10-16T19:40:01Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [50.47.93.218] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: e0ebe8fd-481e-431d-dda0-08d7541e91d8 x-ms-office365-filtering-ht: Tenant x-ms-traffictypediagnostic: BYAPR00MB0565: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 01949FE337 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(376002)(366004)(136003)(346002)(396003)(39860400002)(199004)(189003)(13464003)(64756008)(10290500003)(11346002)(14454004)(66946007)(316002)(54896002)(66556008)(2501003)(55016002)(71190400001)(6246003)(6436002)(71200400001)(10090500001)(606006)(476003)(76116006)(4326008)(446003)(99286004)(22452003)(110136005)(66574012)(478600001)(66476007)(54906003)(6306002)(9686003)(966005)(236005)(66446008)(8990500004)(486006)(5660300002)(256004)(8936002)(26005)(66066001)(52536014)(229853002)(14444005)(76176011)(74316002)(2906002)(7736002)(53546011)(6116002)(790700001)(3846002)(7696005)(33656002)(6506007)(81156014)(81166006)(8676002)(186003)(102836004)(86362001)(25786009); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR00MB0565; H:BYAPR00MB0565.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: BCL:0; x-microsoft-antispam-message-info: woe/DUDM5R6j/7kpdGak3uJqdF2OQeJwiQXluHqd95ltNQx5s+TeB0oQWhaXJr2RFL9iPuPnzB3zMD6jaEdH4xQWWhRnS+WA1PXl3ny68J6eHR2SORXOSpOrNIuif2ueXy9Kxo89zauJyRv7p8bvdtb00ZKL/ejiDA0PG3kmM1NgnuKMHtEDTBRmGiUC3MqtH74PPls9YwadnIN9UztfR2TTTXStr6MgmU4EZ96gSNXPyAi//+FSqxSCi9QBPPzZSPjvWma4Bti1+koiEgVMvpWM5rPE84E7Zp/E2O+PF+VuNsYX9u1GHmZjw0147BVWPOEvy34gl6sSz79kd4TgVf0NWgd3ENw8lTig6tKMfeUQPHFFuPksOepPaqidIXxxLvPVTlkDvA9QD/vK8oOlKSqbhuaogyHMiLgA3kVRvjo= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BYAPR00MB0565A4BCE00C1799451135A8F56C0BYAPR00MB0565namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: e0ebe8fd-481e-431d-dda0-08d7541e91d8 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Oct 2019 22:57:36.7356 (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-CrossTenant-userprincipalname: YtiJcnZHdphkIe8SDfuCxkNr16JVsQmSt5R7liGBa+yqtnm5IJodkMxK5Hu3eNYYMfPXW1ogFch8TAOc2ZnHvA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR00MB0565 Archived-At: Subject: Re: [Ace] Secdir last call review of draft-ietf-ace-cwt-proof-of-possession-08 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 Oct 2019 22:57:48 -0000 --_000_BYAPR00MB0565A4BCE00C1799451135A8F56C0BYAPR00MB0565namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgWW9hdiwNCg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtYWNlLWN3 dC1wcm9vZi1vZi1wb3NzZXNzaW9uLTA5IGhhcyBiZWVuIHB1Ymxpc2hlZCwgd2hpY2ggYWRkcmVz c2VzIHlvdXIgcmV2aWV3IGNvbW1lbnRzIGluIHRoZSB3YXlzIHByb3Bvc2VkIGJlbG93LiAgVGhh bmtzIGFnYWluIGZvciB5b3VyIHJldmlldyENCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tIE1pa2UNCg0KRnJvbTogTWlrZSBKb25lcw0K U2VudDogV2VkbmVzZGF5LCBPY3RvYmVyIDE2LCAyMDE5IDE6MjEgUE0NClRvOiBZb2F2IE5pciA8 eW5pci5pZXRmQGdtYWlsLmNvbT47IHNlY2RpckBpZXRmLm9yZw0KQ2M6IGRyYWZ0LWlldGYtYWNl LWN3dC1wcm9vZi1vZi1wb3NzZXNzaW9uLmFsbEBpZXRmLm9yZzsgaWV0ZkBpZXRmLm9yZzsgYWNl QGlldGYub3JnDQpTdWJqZWN0OiBSRTogU2VjZGlyIGxhc3QgY2FsbCByZXZpZXcgb2YgZHJhZnQt aWV0Zi1hY2UtY3d0LXByb29mLW9mLXBvc3Nlc3Npb24tMDgNCg0KDQpUaGFua3MgYSBsb3QgZm9y IHlvdXIgcmV2aWV3LCBZb2F2LiAgUmVwbGllcyBhcmUgaW5saW5lLCBwcmVmaXhlZCBieSDigJxN aWtlPuKAneKApg0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFlvYXYg TmlyIHZpYSBEYXRhdHJhY2tlciA8bm9yZXBseUBpZXRmLm9yZzxtYWlsdG86bm9yZXBseUBpZXRm Lm9yZz4+DQpTZW50OiBTdW5kYXksIE9jdG9iZXIgNiwgMjAxOSAxMTo1MiBBTQ0KVG86IHNlY2Rp ckBpZXRmLm9yZzxtYWlsdG86c2VjZGlyQGlldGYub3JnPg0KQ2M6IGRyYWZ0LWlldGYtYWNlLWN3 dC1wcm9vZi1vZi1wb3NzZXNzaW9uLmFsbEBpZXRmLm9yZzxtYWlsdG86ZHJhZnQtaWV0Zi1hY2Ut Y3d0LXByb29mLW9mLXBvc3Nlc3Npb24uYWxsQGlldGYub3JnPjsgaWV0ZkBpZXRmLm9yZzxtYWls dG86aWV0ZkBpZXRmLm9yZz47IGFjZUBpZXRmLm9yZzxtYWlsdG86YWNlQGlldGYub3JnPg0KU3Vi amVjdDogU2VjZGlyIGxhc3QgY2FsbCByZXZpZXcgb2YgZHJhZnQtaWV0Zi1hY2UtY3d0LXByb29m LW9mLXBvc3Nlc3Npb24tMDgNCg0KDQoNClJldmlld2VyOiBZb2F2IE5pcg0KDQpSZXZpZXcgcmVz dWx0OiBIYXMgTml0cw0KDQoNCg0KSSBoYXZlIHJldmlld2VkIHRoaXMgZG9jdW1lbnQgYXMgcGFy dCBvZiB0aGUgc2VjdXJpdHkgZGlyZWN0b3JhdGUncyBvbmdvaW5nIGVmZm9ydCB0byByZXZpZXcg YWxsIElFVEYgZG9jdW1lbnRzIGJlaW5nIHByb2Nlc3NlZCBieSB0aGUgSUVTRy4gIFRoZXNlIGNv bW1lbnRzIHdlcmUgd3JpdHRlbiBwcmltYXJpbHkgZm9yIHRoZSBiZW5lZml0IG9mIHRoZSBzZWN1 cml0eSBhcmVhIGRpcmVjdG9ycy4NCg0KRG9jdW1lbnQgZWRpdG9ycyBhbmQgV0cgY2hhaXJzIHNo b3VsZCB0cmVhdCB0aGVzZSBjb21tZW50cyBqdXN0IGxpa2UgYW55IG90aGVyIGxhc3QgY2FsbCBj b21tZW50cy4NCg0KDQoNCkkgdGhpbmsgdGhlIGRvY3VtZW50IHNob3dzIHRoYXQgc2VjdXJpdHkg YXNwZWN0cyBoYXZlIGJlZW4gY29uc2lkZXJlZCBhbmQgaGFuZGxlZCB3ZWxsLiBIb3dldmVyLCB0 aGUgZG9jdW1lbnQgaGFzIGlzc3VlcyB3aXRoIGNsYXJpdHkgYW5kIHJlYWRhYmlsaXR5Og0KDQoN Cg0KRm9yIHN0YXJ0ZXJzLCB0aGUgQWJzdHJhY3QgYW5kIEludHJvZHVjdGlvbiBhcmUgbmVhcmx5 IGlkZW50aWNhbC4gVGhlIEludHJvZHVjdGlvbiBjb3VsZCBpbnN0ZWFkIGJlIHVzZWQgdG8gZXhw bGFpbiB0aGUgZG9tYWluLCB3aG8gdGhlICJwbGF5ZXJzIiBhcmUgYW5kIHdoYXQgdGhleSBhcmUg dHJ5aW5nIHRvIGFjY29tcGxpc2guIEluc3RlYWQsIHNlY3Rpb24gMiBpbnRyb2R1Y2VzIHRoZSB0 ZXJtcyBJc3N1ZXIsIFByZXNlbnRlciBhbmQgUmVjaXBpZW50IHdpdGggZGVmaW5pdGlvbnMgdGhh dCBzb3VuZCBsaWtlIHRoZSBDQSwgdGhlIEVuZCBFbnRpdHkgYW5kIHRoZSBSZWx5aW5nIFBhcnR5 IGZyb20gUEtJLCB3aXRoIGEgbGl0dGxlIE9BdXRoIHRlcm1pbm9sb2d5IG1peGVkIGluLiBUaGVy ZSBpcyBubyBleHBsYW5hdGlvbiBhYm91dCB3aG8gdGhpcyBpc3N1ZXIgaXMsIGFuZCB3aGF0IHRo ZSB0cnVzdCBtb2RlbCBpcy4NCg0KDQoNCk1pa2U+IFRoaXMgZG9jdW1lbnQgc3RydWN0dXJlIGlz IGludGVudGlvbmFsbHkgcGFyYWxsZWwgdG8gUkZDIDc4MDAuICBJbiBwYXJ0aWN1bGFyLCB0aGUg VGVybWlub2xvZ3kgc2VjdGlvbiBpcyB0aGVyZSBzcGVjaWZpY2FsbHkgdG8gaW50cm9kdWNlIHRo ZSBwbGF5ZXJzLiAgWWVzLCBlZGl0b3JpYWxseSwgdGhpcyBjb3VsZCBoYXZlIGJlZW4gZG9uZSBp biB0aGUgSW50cm9kdWN0aW9uLCBidXQgdGhpcyBpcyB0aGUgc3R5bGUgdHlwaWNhbGx5IHVzZWQg YnkgT0F1dGgsIEpPU0UsIENPU0UsIGFuZCBBQ0Ugc3BlY2lmaWNhdGlvbnMuICBJ4oCZbSByZWx1 Y3RhbnQgdG8gZGV2aWF0ZSBmcm9tIGl0IGluIHRoaXMgcGFydGljdWxhciBzcGVjaWZpY2F0aW9u IHVubGVzcyB0aGVyZeKAmXMgYSBjb21wZWxsaW5nIHJlYXNvbiB0byBkbyBzby4NCg0KDQoNCk1p a2U+IFdobyB0aGUgaXNzdWVyIGlzIGlzIGRpc2N1c3NlZCBpbiB0aGUgbGFzdCBwYXJhZ3JhcGgg b2YgU2VjdGlvbiAzLiAgVGhlIHRydXN0IG1vZGVsIGlzIGRlc2NyaWJlZCBpbiB0aGUgbGFzdCBw YXJhZ3JhcGggb2YgU2VjdGlvbiA0IChTZWN1cml0eSBDb25zaWRlcmF0aW9ucykuDQoNCg0KDQpN aWtlPiBUaGVyZWZvcmUsIHVubGVzcyB0aGVyZSBpcyBhIHNwZWNpZmljIGNoYW5nZSB0aGF0IHlv dSB3YW50IHRvIHN1Z2dlc3QsIEkgcHJvcG9zZSB0byBsZWF2ZSB0aGUgSW50cm9kdWN0aW9uIGFu ZCBUZXJtaW5vbG9neSBzZWN0aW9ucyBhcyBpcy4NCg0KDQoNClRoZSBTZWN1cml0eSBDb25zaWRl cmF0aW9ucyBzZWN0aW9uIGFsc28gaGFzIHNvbWUgcHJvYmxlbXMuICBRdW90aW5nIHRoZSBzZWNv bmQNCg0KcGFyYWdyYXBoOg0KDQogICBBcHBsaWNhdGlvbnMgdXRpbGl6aW5nIHByb29mIG9mIHBv c3Nlc3Npb24gU0hPVUxEIGFsc28gdXRpbGl6ZQ0KDQogICBhdWRpZW5jZSByZXN0cmljdGlvbiwg YXMgZGVzY3JpYmVkIGluIFNlY3Rpb24gMy4xLjMgb2YgW0NXVF0sIGFzIGl0DQoNCiAgIHByb3Zp ZGVzIGFkZGl0aW9uYWwgcHJvdGVjdGlvbnMuICBBdWRpZW5jZSByZXN0cmljdGlvbiBjYW4gYmUg dXNlZCBieQ0KDQogICByZWNpcGllbnRzIHRvIHJlamVjdCBtZXNzYWdlcyBpbnRlbmRlZCBmb3Ig ZGlmZmVyZW50IHJlY2lwaWVudHMuDQoNCg0KDQpXaHk/IFdoeSBpcyB0aGUgYXVkIGNsYWltIG5l ZWRlZCB3aXRoIGEgY25mIGNsYWltIChidXQgbm90IGluIG90aGVyIGNhc2VzKT8NCg0KTmVpdGhl ciB0aGlzIGRvY3VtZW50IG5vciBSRkMgODM5MiBwcm92aWRlcyBpbnNpZ2h0IGFzIHRvIHdoZW4g YXVkIGlzIGFwcHJvcHJpYXRlLiBUaGF0IHRoZXkgYWxsb3cgcmVjaXBpZW50cyB0byByZWplY3Qg bWVzc2FnZXMgbm90IGludGVuZGVkIGZvciB0aGVtIGRvZXMgbm90IHNvdW5kIGxpa2UgYSBzZWN1 cml0eSBmZWF0dXJlLg0KDQoNCg0KTWlrZT4gSGF2aW5nIGFuIGF1ZGllbmNlIGluIGEgdG9rZW4g aXMgYSBzZWN1cml0eSBmZWF0dXJlLCBhcyBpdCBwcmV2ZW50cyBhIGxlZ2l0aW1hdGUgdG9rZW4g aW50ZW5kZWQgZm9yIG9uZSByZWNpcGllbnQgZnJvbSBiZWluZyByZXBsYXllZCB0byBnYWluIGFj Y2VzcyBhdCBhIGRpZmZlcmVudCByZWNpcGllbnQuICBZb3XigJlyZSByaWdodCB0aGF0IHRoaXMg aXMgdXNlZnVsL3JlcXVpcmVkIGluIG1hbnkgc2l0dWF0aW9ucyBldmVuIHdoZW4g4oCcY25m4oCd IGlzbuKAmXQgYmVpbmcgdXNlZC4gIEhvd2V2ZXIsIHJldmlld2VycyBvZiBkcmFmdHMgb2Ygd2hh dCBiZWNhbWUgUkZDIDc4MDAgd2FudGVkIHRoaXMgdGV4dCBhZGRlZCB0byByZW1pbmQgcGVvcGxl IHRoYXQgYXVkaWVuY2UgcmVzdHJpY3Rpb24gaXMgb2Z0ZW4gdXNlZnVsIGV2ZW4gd2hlbiB5b3Ug aGF2ZSBwcm9vZiBvZiBwb3NzZXNzaW9uLCBhcyBpdCBkZWZlbmRzIGFnYWluc3QgZGlmZmVyZW50 IHRocmVhdHMuDQoNCg0KDQpNaWtlPiBUbyBtYWtlIHRoaXMgY2xlYXJlciwgSSBwcm9wb3NlIHRv IGFkZCB0aGlzIHBhcmVudGhldGljYWwgcmVtYXJrIGF0IHRoZSBlbmQgb2YgdGhpcyBwYXJhZ3Jh cGg6IOKAnChPZiBjb3Vyc2UsIGFwcGxpY2F0aW9ucyBub3QgdXNpbmcgcHJvb2Ygb2YgcG9zc2Vz c2lvbiBjYW4gYWxzbyBiZW5lZml0IGZyb20gdXNpbmcgYXVkaWVuY2UgcmVzdHJpY3Rpb24gdG8g cmVqZWN0IG1lc3NhZ2VzIGludGVuZGVkIGZvciBkaWZmZXJlbnQgcmVjaXBpZW50cy4p4oCdICBJ ZiB5b3XigJlkIHByZWZlciBkaWZmZXJlbnQgd29yZGluZywgcGxlYXNlIGxldCBtZSBrbm93IHdo YXQgaXQgaXMuDQoNCg0KDQpQYXJhZ3JhcGggMyBzYXlzOiAiQSByZWNpcGllbnQgbWlnaHQgbm90 IHVuZGVyc3RhbmQgdGhlICJjbmYiIGNsYWltLiIgICBUaGlzDQoNCnJlLWFmZmlybXMgdGhhdCB3 ZSBuZWVkIGFuIGV4cGxhbmF0aW9uIG9mIHdobyB0aGUgcGFydGllcyB0byB0aGlzIHByb3RvY29s IGFyZS4NCg0KV2UgZ2VuZXJhbGx5IGRvbid0IHNlbmQgbWVzc2FnZXMgdG8gcmVjaXBpZW50cyB0 aGF0IGRvbid0IHVuZGVyc3RhbmQgdGhlbS4gSXMgdGhpcyBhIGNsb3NlZCBzeXN0ZW0gd2l0aCBr bm93biBlbnRpdGllcywgb3IgaXMgdGhpcyBhIHByb3RvY29sIHdoZXJlIHRoZSBwYXJ0aWVzIGNv bnRhY3QgcmFuZG9tIG90aGVyIHBhcnRpZXMgb24gdGhlIEludGVybmV0Pw0KDQoNCg0KTWlrZT4g UGVyIG15IHJlc3BvbnNlIHRvIHRoZSBHZW5hcnQgcmV2aWV3LCB3ZeKAmXJlIGFscmVhZHkgcHJv cG9zaW5nIHRvIGRlbGV0ZSB0aGlzIHBhcmFncmFwaCwgYXMgaXTigJlzIG5vdCBhY3Rpb25hYmxl LiAgTm90ZSB0aGF0IHRoZSByZXF1aXJlbWVudCB0byBpZ25vcmUgbm90LXVuZGVyc3Rvb2QgY2xh aW1zIGNvbWVzIGZyb20gU2VjdGlvbiAzIG9mIFJGQyA4MzkyICh3aGljaCBhbHNvIHdhcyBpbmhl cml0ZWQgZnJvbSBSRkMgNzUxOSksIGFuZCBzbyBpcyBub3QgdW5pcXVlIHRvIHRoaXMgc3BlY2lm aWNhdGlvbi4NCg0KDQoNCk1pa2U+IFRoZSBleGFjdCBwYXJ0aWVzIHRvIHRoZSBwcm90b2NvbCBh cmUgZGVwZW5kZW50IHVwb24gdGhlIGFwcGxpY2F0aW9uLCBhcyBkaXNjdXNzZWQgaW4gdGhlIGxh c3QgcGFyYWdyYXBoIG9mIFNlY3Rpb24gNC4gIFRoaXMgc3BlY2lmaWNhdGlvbiBpcyBkZWZpbmlu ZyBQb1Aga2V5IHJlcHJlc2VudGF0aW9ucy4gIEl04oCZcyBpbnRlbnRpb25hbGx5IGxlYXZpbmcg dGhlIG1lc3NhZ2VzIGNvbnZleWluZyBDV1RzIHdpdGgg4oCcY25m4oCdIGNsYWltcyB1cCB0byB0 aGUgYXBwbGljYXRpb25zIHVzaW5nIHRoZW0uICBBZ2FpbiwgdGhpcyBpcyBpbnRlbnRpb25hbGx5 IGV4YWN0bHkgcGFyYWxsZWwgdG8gUkZDIDc4MDAuDQoNCg0KDQpJJ2QgYWxzbyBsb3NlIHNvbWUg b2YgdGhlIEludHJvZHVjdGlvbiB0byBDcnlwdG8gaW4gdGhlIHNlY29uZC10by1sYXN0IHBhcmFn cmFwaC4NCg0KDQoNCk1pa2U+IEkgYWdyZWUgdGhhdCB0aGlzIGlzIG92ZXJseSBwZWRhbnRpYy4g IEkgcHJvcG9zZSB0byBkZWxldGUgdGhlIHBhcmVudGhldGljYWwg4oCcZS5nLuKAnSBjbGF1c2Ug YXQgdGhlIGVuZCwgd2hpY2ggd2lsbCBtYWtlIGl0IG9uY2UgYWdhaW4gZXhhY3RseSBwYXJhbGxl bCB0byB0aGUgY29ycmVzcG9uZGluZyB0ZXh0IGluIFJGQyA3ODAwLiAgTGV0IG1lIGtub3cgaWYg eW914oCZZCBhIHNwZWNpZmljIGZ1cnRoZXIgY2hhbmdlIHRvIHRoaXMgcGFyYWdyYXBoLg0KDQoN Cg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIFRoYW5rcywNCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tIE1pa2UNCg0KDQo= --_000_BYAPR00MB0565A4BCE00C1799451135A8F56C0BYAPR00MB0565namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjoj OTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29QbGFpblRleHQsIGxp Lk1zb1BsYWluVGV4dCwgZGl2Lk1zb1BsYWluVGV4dA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsc2Fucy1zZXJpZjt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29u b3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0K CW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIixzYW5zLXNlcmlmO30NCnNwYW4uUGxhaW5UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToi UGxhaW4gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxp bms6IlBsYWluIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNw YW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsO30NCnNwYW4uRW1haWxT dHlsZTIyDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMwMDIwNjA7fQ0KLk1zb0NocERlZmF1bHQNCgl7 bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBX b3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEu MGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+ PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9 ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBt c28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0 PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0K PC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0Rjcy Ij4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBZ b2F2PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPiw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNv bG9yOiMwMDIwNjAiPjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1p ZXRmLWFjZS1jd3QtcHJvb2Ytb2YtcG9zc2Vzc2lvbi0wOSI+aHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LWlldGYtYWNlLWN3dC1wcm9vZi1vZi1wb3NzZXNzaW9uLTA5PC9hPiBoYXMg YmVlbiBwdWJsaXNoZWQsIHdoaWNoIGFkZHJlc3NlcyB5b3VyIHJldmlldyBjb21tZW50cw0KIGlu IHRoZSB3YXlzIHByb3Bvc2VkIGJlbG93LiZuYnNwOyBUaGFua3MgYWdhaW4gZm9yIHlvdXIgcmV2 aWV3ITxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJjb2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiBNaWtlIEpvbmVzIDxicj4NCjxiPlNlbnQ6 PC9iPiBXZWRuZXNkYXksIE9jdG9iZXIgMTYsIDIwMTkgMToyMSBQTTxicj4NCjxiPlRvOjwvYj4g WW9hdiBOaXIgJmx0O3luaXIuaWV0ZkBnbWFpbC5jb20mZ3Q7OyBzZWNkaXJAaWV0Zi5vcmc8YnI+ DQo8Yj5DYzo8L2I+IGRyYWZ0LWlldGYtYWNlLWN3dC1wcm9vZi1vZi1wb3NzZXNzaW9uLmFsbEBp ZXRmLm9yZzsgaWV0ZkBpZXRmLm9yZzsgYWNlQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+ IFJFOiBTZWNkaXIgbGFzdCBjYWxsIHJldmlldyBvZiBkcmFmdC1pZXRmLWFjZS1jd3QtcHJvb2Yt b2YtcG9zc2Vzc2lvbi0wODxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+VGhhbmtzIGEgbG90IGZvciB5b3VyIHJldmlldywgWW9hdi4mbmJzcDsgUmVwbGllcyBhcmUg aW5saW5lLCBwcmVmaXhlZCBieSDigJw8c3BhbiBzdHlsZT0iY29sb3I6IzAwQjA1MCI+TWlrZSZn dDs8L3NwYW4+4oCd4oCmPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPi0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tPGJyPg0KRnJvbTogWW9hdiBOaXIgdmlhIERhdGF0cmFja2VyICZsdDs8 YSBocmVmPSJtYWlsdG86bm9yZXBseUBpZXRmLm9yZyI+bm9yZXBseUBpZXRmLm9yZzwvYT4mZ3Q7 DQo8YnI+DQpTZW50OiBTdW5kYXksIE9jdG9iZXIgNiwgMjAxOSAxMTo1MiBBTTxicj4NClRvOiA8 YSBocmVmPSJtYWlsdG86c2VjZGlyQGlldGYub3JnIj5zZWNkaXJAaWV0Zi5vcmc8L2E+PGJyPg0K Q2M6IDxhIGhyZWY9Im1haWx0bzpkcmFmdC1pZXRmLWFjZS1jd3QtcHJvb2Ytb2YtcG9zc2Vzc2lv bi5hbGxAaWV0Zi5vcmciPmRyYWZ0LWlldGYtYWNlLWN3dC1wcm9vZi1vZi1wb3NzZXNzaW9uLmFs bEBpZXRmLm9yZzwvYT47DQo8YSBocmVmPSJtYWlsdG86aWV0ZkBpZXRmLm9yZyI+aWV0ZkBpZXRm Lm9yZzwvYT47IDxhIGhyZWY9Im1haWx0bzphY2VAaWV0Zi5vcmciPmFjZUBpZXRmLm9yZzwvYT48 YnI+DQpTdWJqZWN0OiBTZWNkaXIgbGFzdCBjYWxsIHJldmlldyBvZiBkcmFmdC1pZXRmLWFjZS1j d3QtcHJvb2Ytb2YtcG9zc2Vzc2lvbi0wODxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5S ZXZpZXdlcjogWW9hdiBOaXI8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PlJldmlldyByZXN1bHQ6IEhhcyBOaXRzPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkkg aGF2ZSByZXZpZXdlZCB0aGlzIGRvY3VtZW50IGFzIHBhcnQgb2YgdGhlIHNlY3VyaXR5IGRpcmVj dG9yYXRlJ3Mgb25nb2luZyBlZmZvcnQgdG8gcmV2aWV3IGFsbCBJRVRGIGRvY3VtZW50cyBiZWlu ZyBwcm9jZXNzZWQgYnkgdGhlIElFU0cuJm5ic3A7IFRoZXNlIGNvbW1lbnRzIHdlcmUgd3JpdHRl biBwcmltYXJpbHkgZm9yIHRoZSBiZW5lZml0IG9mIHRoZSBzZWN1cml0eSBhcmVhIGRpcmVjdG9y cy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkRvY3VtZW50IGVkaXRv cnMgYW5kIFdHIGNoYWlycyBzaG91bGQgdHJlYXQgdGhlc2UgY29tbWVudHMganVzdCBsaWtlIGFu eSBvdGhlciBsYXN0IGNhbGwgY29tbWVudHMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PkkgdGhpbmsgdGhlIGRvY3VtZW50IHNob3dzIHRoYXQgc2VjdXJpdHkgYXNwZWN0cyBoYXZlIGJl ZW4gY29uc2lkZXJlZCBhbmQgaGFuZGxlZCB3ZWxsLiBIb3dldmVyLCB0aGUgZG9jdW1lbnQgaGFz IGlzc3VlcyB3aXRoIGNsYXJpdHkgYW5kIHJlYWRhYmlsaXR5OjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij5Gb3Igc3RhcnRlcnMsIHRoZSBBYnN0cmFjdCBhbmQgSW50cm9kdWN0aW9uIGFy ZSBuZWFybHkgaWRlbnRpY2FsLiBUaGUgSW50cm9kdWN0aW9uIGNvdWxkIGluc3RlYWQgYmUgdXNl ZCB0byBleHBsYWluIHRoZSBkb21haW4sIHdobyB0aGUgJnF1b3Q7cGxheWVycyZxdW90OyBhcmUg YW5kIHdoYXQgdGhleSBhcmUgdHJ5aW5nIHRvIGFjY29tcGxpc2guIEluc3RlYWQsIHNlY3Rpb24g MiBpbnRyb2R1Y2VzIHRoZSB0ZXJtcyBJc3N1ZXIsDQogUHJlc2VudGVyIGFuZCBSZWNpcGllbnQg d2l0aCBkZWZpbml0aW9ucyB0aGF0IHNvdW5kIGxpa2UgdGhlIENBLCB0aGUgRW5kIEVudGl0eSBh bmQgdGhlIFJlbHlpbmcgUGFydHkgZnJvbSBQS0ksIHdpdGggYSBsaXR0bGUgT0F1dGggdGVybWlu b2xvZ3kgbWl4ZWQgaW4uIFRoZXJlIGlzIG5vIGV4cGxhbmF0aW9uIGFib3V0IHdobyB0aGlzIGlz c3VlciBpcywgYW5kIHdoYXQgdGhlIHRydXN0IG1vZGVsIGlzLjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzAwQjA1MCI+TWlrZSZndDsgVGhpcyBkb2N1 bWVudCBzdHJ1Y3R1cmUgaXMgaW50ZW50aW9uYWxseSBwYXJhbGxlbCB0byBSRkMgNzgwMC4mbmJz cDsgSW4gcGFydGljdWxhciwgdGhlIFRlcm1pbm9sb2d5IHNlY3Rpb24gaXMgdGhlcmUgc3BlY2lm aWNhbGx5IHRvIGludHJvZHVjZSB0aGUgcGxheWVycy4mbmJzcDsgWWVzLCBlZGl0b3JpYWxseSwg dGhpcyBjb3VsZCBoYXZlIGJlZW4gZG9uZSBpbg0KIHRoZSBJbnRyb2R1Y3Rpb24sIGJ1dCB0aGlz IGlzIHRoZSBzdHlsZSB0eXBpY2FsbHkgdXNlZCBieSBPQXV0aCwgSk9TRSwgQ09TRSwgYW5kIEFD RSBzcGVjaWZpY2F0aW9ucy4mbmJzcDsgSeKAmW0gcmVsdWN0YW50IHRvIGRldmlhdGUgZnJvbSBp dCBpbiB0aGlzIHBhcnRpY3VsYXIgc3BlY2lmaWNhdGlvbiB1bmxlc3MgdGhlcmXigJlzIGEgY29t cGVsbGluZyByZWFzb24gdG8gZG8gc28uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMEIwNTAiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xv cjojMDBCMDUwIj5NaWtlJmd0OyBXaG8gdGhlIGlzc3VlciBpcyBpcyBkaXNjdXNzZWQgaW4gdGhl IGxhc3QgcGFyYWdyYXBoIG9mIFNlY3Rpb24gMy4mbmJzcDsgVGhlIHRydXN0IG1vZGVsIGlzIGRl c2NyaWJlZCBpbiB0aGUgbGFzdCBwYXJhZ3JhcGggb2YgU2VjdGlvbiA0IChTZWN1cml0eSBDb25z aWRlcmF0aW9ucykuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMEIwNTAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDBCMDUwIj5N aWtlJmd0OyBUaGVyZWZvcmUsIHVubGVzcyB0aGVyZSBpcyBhIHNwZWNpZmljIGNoYW5nZSB0aGF0 IHlvdSB3YW50IHRvIHN1Z2dlc3QsIEkgcHJvcG9zZSB0byBsZWF2ZSB0aGUgSW50cm9kdWN0aW9u IGFuZCBUZXJtaW5vbG9neSBzZWN0aW9ucyBhcyBpcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlRoZSBTZWN1cml0 eSBDb25zaWRlcmF0aW9ucyBzZWN0aW9uIGFsc28gaGFzIHNvbWUgcHJvYmxlbXMuJm5ic3A7IFF1 b3RpbmcgdGhlIHNlY29uZDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ cGFyYWdyYXBoOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7 Jm5ic3A7IEFwcGxpY2F0aW9ucyB1dGlsaXppbmcgcHJvb2Ygb2YgcG9zc2Vzc2lvbiBTSE9VTEQg YWxzbyB1dGlsaXplPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJz cDsmbmJzcDsgYXVkaWVuY2UgcmVzdHJpY3Rpb24sIGFzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDMu MS4zIG9mIFtDV1RdLCBhcyBpdDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jm5ic3A7Jm5ic3A7IHByb3ZpZGVzIGFkZGl0aW9uYWwgcHJvdGVjdGlvbnMuJm5ic3A7IEF1 ZGllbmNlIHJlc3RyaWN0aW9uIGNhbiBiZSB1c2VkIGJ5PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsgJm5ic3A7cmVjaXBpZW50cyB0byByZWplY3QgbWVzc2Fn ZXMgaW50ZW5kZWQgZm9yIGRpZmZlcmVudCByZWNpcGllbnRzLjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij5XaHk/IFdoeSBpcyB0aGUgYXVkIGNsYWltIG5lZWRlZCB3aXRoIGEgY25mIGNs YWltIChidXQgbm90IGluIG90aGVyIGNhc2VzKT8NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+TmVpdGhlciB0aGlzIGRvY3VtZW50IG5vciBSRkMgODM5MiBwcm92aWRl cyBpbnNpZ2h0IGFzIHRvIHdoZW4gYXVkIGlzIGFwcHJvcHJpYXRlLiBUaGF0IHRoZXkgYWxsb3cg cmVjaXBpZW50cyB0byByZWplY3QgbWVzc2FnZXMgbm90IGludGVuZGVkIGZvciB0aGVtIGRvZXMg bm90IHNvdW5kIGxpa2UgYSBzZWN1cml0eSBmZWF0dXJlLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzAwQjA1MCI+TWlrZSZndDsgSGF2aW5nIGFuIGF1 ZGllbmNlIGluIGEgdG9rZW4gaXMgYSBzZWN1cml0eSBmZWF0dXJlLCBhcyBpdCBwcmV2ZW50cyBh IGxlZ2l0aW1hdGUgdG9rZW4gaW50ZW5kZWQgZm9yIG9uZSByZWNpcGllbnQgZnJvbSBiZWluZyBy ZXBsYXllZCB0byBnYWluIGFjY2VzcyBhdCBhIGRpZmZlcmVudCByZWNpcGllbnQuJm5ic3A7IFlv deKAmXJlIHJpZ2h0IHRoYXQgdGhpcw0KIGlzIHVzZWZ1bC9yZXF1aXJlZCBpbiBtYW55IHNpdHVh dGlvbnMgZXZlbiB3aGVuIOKAnGNuZuKAnSBpc27igJl0IGJlaW5nIHVzZWQuJm5ic3A7IEhvd2V2 ZXIsIHJldmlld2VycyBvZiBkcmFmdHMgb2Ygd2hhdCBiZWNhbWUgUkZDIDc4MDAgd2FudGVkIHRo aXMgdGV4dCBhZGRlZCB0byByZW1pbmQgcGVvcGxlIHRoYXQgYXVkaWVuY2UgcmVzdHJpY3Rpb24g aXMgb2Z0ZW4gdXNlZnVsIGV2ZW4gd2hlbiB5b3UgaGF2ZSBwcm9vZiBvZiBwb3NzZXNzaW9uLCBh cyBpdCBkZWZlbmRzDQogYWdhaW5zdCBkaWZmZXJlbnQgdGhyZWF0cy48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzAwQjA1 MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ PHNwYW4gc3R5bGU9ImNvbG9yOiMwMEIwNTAiPk1pa2UmZ3Q7IFRvIG1ha2UgdGhpcyBjbGVhcmVy LCBJIHByb3Bvc2UgdG8gYWRkIHRoaXMgcGFyZW50aGV0aWNhbCByZW1hcmsgYXQgdGhlIGVuZCBv ZiB0aGlzIHBhcmFncmFwaDog4oCcKE9mIGNvdXJzZSwgYXBwbGljYXRpb25zIG5vdCB1c2luZyBw cm9vZiBvZiBwb3NzZXNzaW9uIGNhbiBhbHNvIGJlbmVmaXQgZnJvbSB1c2luZyBhdWRpZW5jZSBy ZXN0cmljdGlvbg0KIHRvIHJlamVjdCBtZXNzYWdlcyBpbnRlbmRlZCBmb3IgZGlmZmVyZW50IHJl Y2lwaWVudHMuKeKAnSZuYnNwOyBJZiB5b3XigJlkIHByZWZlciBkaWZmZXJlbnQgd29yZGluZywg cGxlYXNlIGxldCBtZSBrbm93IHdoYXQgaXQgaXMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij5QYXJhZ3JhcGggMyBzYXlzOiAmcXVvdDtBIHJlY2lwaWVudCBtaWdodCBub3Qg dW5kZXJzdGFuZCB0aGUgJnF1b3Q7Y25mJnF1b3Q7IGNsYWltLiZxdW90OyZuYnNwOyZuYnNwOyBU aGlzPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5yZS1hZmZpcm1zIHRo YXQgd2UgbmVlZCBhbiBleHBsYW5hdGlvbiBvZiB3aG8gdGhlIHBhcnRpZXMgdG8gdGhpcyBwcm90 b2NvbCBhcmUuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5XZSBnZW5l cmFsbHkgZG9uJ3Qgc2VuZCBtZXNzYWdlcyB0byByZWNpcGllbnRzIHRoYXQgZG9uJ3QgdW5kZXJz dGFuZCB0aGVtLiBJcyB0aGlzIGEgY2xvc2VkIHN5c3RlbSB3aXRoIGtub3duIGVudGl0aWVzLCBv ciBpcyB0aGlzIGEgcHJvdG9jb2wgd2hlcmUgdGhlIHBhcnRpZXMgY29udGFjdCByYW5kb20gb3Ro ZXIgcGFydGllcyBvbiB0aGUgSW50ZXJuZXQ/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzAwQjA1MCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMw MEIwNTAiPk1pa2UmZ3Q7IFBlciBteSByZXNwb25zZSB0byB0aGUgR2VuYXJ0IHJldmlldywgd2Xi gJlyZSBhbHJlYWR5IHByb3Bvc2luZyB0byBkZWxldGUgdGhpcyBwYXJhZ3JhcGgsIGFzIGl04oCZ cyBub3QgYWN0aW9uYWJsZS4mbmJzcDsgTm90ZSB0aGF0IHRoZSByZXF1aXJlbWVudCB0byBpZ25v cmUgbm90LXVuZGVyc3Rvb2QgY2xhaW1zIGNvbWVzIGZyb20gU2VjdGlvbiAzIG9mIFJGQw0KIDgz OTIgKHdoaWNoIGFsc28gd2FzIGluaGVyaXRlZCBmcm9tIFJGQyA3NTE5KSwgYW5kIHNvIGlzIG5v dCB1bmlxdWUgdG8gdGhpcyBzcGVjaWZpY2F0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDBCMDUwIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHls ZT0iY29sb3I6IzAwQjA1MCI+TWlrZSZndDsgVGhlIGV4YWN0IHBhcnRpZXMgdG8gdGhlIHByb3Rv Y29sIGFyZSBkZXBlbmRlbnQgdXBvbiB0aGUgYXBwbGljYXRpb24sIGFzIGRpc2N1c3NlZCBpbiB0 aGUgbGFzdCBwYXJhZ3JhcGggb2YgU2VjdGlvbiA0LiZuYnNwOyBUaGlzIHNwZWNpZmljYXRpb24g aXMgZGVmaW5pbmcgUG9QIGtleSByZXByZXNlbnRhdGlvbnMuJm5ic3A7IEl04oCZcyBpbnRlbnRp b25hbGx5IGxlYXZpbmcNCiB0aGUgbWVzc2FnZXMgY29udmV5aW5nIENXVHMgd2l0aCDigJxjbmbi gJ0gY2xhaW1zIHVwIHRvIHRoZSBhcHBsaWNhdGlvbnMgdXNpbmcgdGhlbS4mbmJzcDsgQWdhaW4s IHRoaXMgaXMgaW50ZW50aW9uYWxseSBleGFjdGx5IHBhcmFsbGVsIHRvIFJGQyA3ODAwLjwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+SSdkIGFsc28gbG9zZSBzb21lIG9mIHRo ZSBJbnRyb2R1Y3Rpb24gdG8gQ3J5cHRvIGluIHRoZSBzZWNvbmQtdG8tbGFzdCBwYXJhZ3JhcGgu PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDBCMDUw Ij5NaWtlJmd0OyBJIGFncmVlIHRoYXQgdGhpcyBpcyBvdmVybHkgcGVkYW50aWMuJm5ic3A7IEkg cHJvcG9zZSB0byBkZWxldGUgdGhlIHBhcmVudGhldGljYWwg4oCcZS5nLuKAnSBjbGF1c2UgYXQg dGhlIGVuZCwgd2hpY2ggd2lsbCBtYWtlIGl0IG9uY2UgYWdhaW4gZXhhY3RseSBwYXJhbGxlbCB0 byB0aGUgY29ycmVzcG9uZGluZyB0ZXh0IGluIFJGQyA3ODAwLiZuYnNwOyBMZXQgbWUga25vdw0K IGlmIHlvdeKAmWQgYSBzcGVjaWZpYyBmdXJ0aGVyIGNoYW5nZSB0byB0aGlzIHBhcmFncmFwaC48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHls ZT0iY29sb3I6IzAwQjA1MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMEIwNTAiPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBUaGFua3MsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMEIwNTAiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtLSBNaWtlPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMEIwNTAiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_BYAPR00MB0565A4BCE00C1799451135A8F56C0BYAPR00MB0565namp_-- From nobody Sun Oct 20 02:46: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 2AB041200B9; Sun, 20 Oct 2019 02:45:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bRT3i_dpv6Pq; Sun, 20 Oct 2019 02:45:52 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A52251200A4; Sun, 20 Oct 2019 02:45:51 -0700 (PDT) Received: from pptp-218-1.informatik.uni-bremen.de (pptp-218-1.informatik.uni-bremen.de [134.102.218.240]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 46wvyz2chrz10Ct; Sun, 20 Oct 2019 11:45:45 +0200 (CEST) From: Carsten Bormann Content-Type: text/plain; charset=utf-8 X-Mao-Original-Outgoing-Id: 593257539.733766-d395d753ad3a587fd75d4cba39dda151 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Sun, 20 Oct 2019 11:45:42 +0200 Message-Id: To: Ace Wg , core , cose , cbor@ietf.org, t2trg@irtf.org X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: [Ace] Constrained Node/Network Cluster @ IETF106: DRAFT AGENDA X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Oct 2019 09:45:56 -0000 Here is my usual eclectic condensed agenda based on the DRAFT AGENDA for IETF106. Remember that there is still quite some potential for changes. Conflicts that meet the eye: LAKE/SUIT (already noted by Russ), BOF on top (thing security): TMRID. ACE/RATS are also both security technologies that impact IoT. COSE is a technology that might be relevant for WPACK. All times are SGT (Singapore Time) =3D=3D UTC + 8 hours (=3D=3D China = time). Singapore doesn't obey the daylight savings myth. (Pure UTC times at https://datatracker.ietf.org/meeting/agenda-utc are useful for those who want to listen from remote.) Gr=C3=BC=C3=9Fe, Carsten FRIDAY, November 15, 2019 -- T2TRG/W3C WoT Workshop @ NUSS (https://is.gd/XWSfi8) SATURDAY, November 16, 2019 0830-2200 IETF Hackathon - Moor/Morrison SUNDAY, November 17, 2019 0830-1600 IETF Hackathon - Moor/Morrison 1700-1900 Welcome Reception - Fairmont Ballroom Foyer 1800-2000 Hot RFC Lightning Talks -- Padang MONDAY, November 18, 2019 1000-1200 Morning Session I Collyer ART dispatch Dispatch WG - Joint with ARTAREA Sophia IRTF icnrg Information-Centric Networking VIP A SEC *** rats Remote ATtestation ProcedureS WG 1330-1530 Afternoon Session I VIP A INT dnssd Extensions for Scalable DNS Service = Discovery WG - Joint with HOMENET VIP A INT homenet Home Networking WG - Joint with DNSSD Hullet INT *** lpwan IPv6 over Low Power Wide-Area Networks = WG Olivia IRTF*** dinrg Decentralized Internet Infrastructure Canning IRTF pearg Privacy Enhancements and Assessments = Research Group Padang SEC txauth Transactional Authorization and = Delegation BOF Sophia TSV tsvwg Transport Area Working Group WG 1550-1750 Afternoon Session II Collyer ART abcd Application Behavior Considering DNS BOF Padang IRTF irtfopen IRTF Open Meeting Sophia OPS v6ops IPv6 Operations WG Orchard RTG *** roll Routing Over Low power and Lossy = networks WG Canning SEC mls Messaging Layer Security WG 1810-1910 Afternoon Session III Canning INT *** lwig Light-Weight Implementation Guidance WG Olivia TSV rmcat RTP Media Congestion Avoidance = Techniques WG TUESDAY, November 19, 2019 1000-1200 Morning Session I Hullet RTG *** roll Routing Over Low power and Lossy = networks WG Olivia SEC *** teep Trusted Execution Environment = Provisioning WG Padang TSV quic QUIC WG 1330-1500 Afternoon Session I VIP A INT tmrid Trustworthy Multipurpose Remote ID BOF Padang IRTF maprg Measurement and Analysis for Protocols Canning SEC *** lake Lightweight Authenticated Key Exchange = WG Olivia SEC *** suit Software Updates for Internet of Things = WG 1520-1650 Afternoon Session II Canning INT intarea Internet Area Working Group WG Olivia SEC *** ace Authentication and Authorization for = Constrained Environments WG VIP A SEC *** rats Remote ATtestation ProcedureS WG Hullet TSV taps Transport Services WG 1710-1840 Afternoon Session III Hullet IRTF qirg Quantum Internet Proposed Research Group Sophia OPS anima Autonomic Networking Integrated Model = and Approach WG Orchard RTG babel Babel routing protocol WG Padang SEC secdispatch Security Dispatch WG WEDNESDAY, November 20, 2019 1000-1200 Morning Session I Collyer RTG raw Reliable and Available Wireless BOF Sophia SEC *** teep Trusted Execution Environment = Provisioning WG Padang TSV quic QUIC WG 1330-1500 Afternoon Session I Canning ART webtrans WebTransport BOF Sophia INT *** 6lo IPv6 over Networks of = Resource-constrained Nodes WG Collyer IRTF cfrg Crypto Forum Olivia SEC oauth Web Authorization Protocol WG 1520-1650 Afternoon Session II Orchard ART *** core Constrained RESTful Environments WG Hullet OPS anima Autonomic Networking Integrated Model = and Approach WG Collyer SEC tls Transport Layer Security WG Sophia TSV tsvarea Transport Area Open Meeting THURSDAY, November 21, 2019 1000-1200 Morning Session I Sophia IRTF*** t2trg Thing-to-Thing VIP A RTG bier Bit Indexed Explicit Replication WG Padang SEC tls Transport Layer Security WG Collyer TSV tsvwg Transport Area Working Group WG 1330-1530 Afternoon Session I Collyer ART httpbis Hypertext Transfer Protocol WG Sophia INT 6man IPv6 Maintenance WG Olivia RTG rift Routing In Fat Trees WG Canning SEC saag Security Area Open Meeting 1550-1720 Afternoon Session II Padang ART wpack Web Packaging BOF Canning RTG detnet Deterministic Networking WG Sophia SEC *** cose CBOR Object Signing and Encryption WG Hullet SEC oauth Web Authorization Protocol WG 1740-1840 Afternoon Session III Olivia ART *** cbor Concise Binary Object Representation = Maintenance and Extensions WG Sophia GEN git GitHub Integration and Tooling WG Padang INT 6man IPv6 Maintenance WG Canning RTG detnet Deterministic Networking WG FRIDAY, November 22, 2019 1000-1200 Morning Session I Collyer ART httpbis Hypertext Transfer Protocol WG Hullet INT *** 6tisch IPv6 over the TSCH mode of IEEE = 802.15.4e WG Sophia IRTF coinrg Computing in the Network Proposed = Research Group Olivia SEC mathmesh MatheMatical Mesh BOF 1220-1350 Morning Session II Hullet ART *** core Constrained RESTful Environments WG Sophia IRTF panrg Path Aware Networking RG Olivia SEC acme Automated Certificate Management = Environment WG From nobody Mon Oct 21 13:04: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 4015A120947 for ; Mon, 21 Oct 2019 13:04:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=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 VNEygle6sQaw for ; Mon, 21 Oct 2019 13:04:05 -0700 (PDT) Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650095.outbound.protection.outlook.com [40.107.65.95]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD434120936 for ; Mon, 21 Oct 2019 13:03:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=IvKrBpK2vpSl+vVhGQXAEzcJp+kFfp1inHwtQeBHN9F5N/peuQiSLF7jVyjxthXTL3ySgrdafEIMiM9F+YkK75cF5bv/WHw8DBTivUx7YKHiswGd5/tlIbLSaRaPZjCQ5WNjPXUIl9JvMYzIr3/LaFVqqiP7ltGXm5YMdhygD5NixtOKta611btGbZD6Jdvuc7gl2V9hTrnHFGxNo7dBSGv9Em1NYzZ5w5C3IjLTm8OPXt7mxPkEmh7yXYbFG2FrQ0bdw3JlY4ahPUQDg3qHyK5P2zVIY6bJEXEVDd1DkdeKHyppMF5OwPL1XhkzoQjBUxBSuOx9LpJM6omBBcfjNw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ydWl1fQxY9zxdUsmMrCyhTprl/7naH6yltvuBHvLxHA=; b=HcVJtMvV6JcXPsWjxpncXKt1duEoXWnklgHNyGirMtXMOMExY3rzdg3WqDfzdlTihQvDCH2nTMNcv6URonRcDu1hHczAoQxMXoq6Mc6Q/MyxqCRt/IdQsQU+ZfpZHAhtg/oSmJsqQDeLgMw0YdeIaMG76n9NVE40seW3uM8cP0Zux3xIJeQ233sSppA+PIaHeaA8k+Eq/OK5/wfU601Qsw/RrypsU/g/1K3lCdxNt/FrWdMCiy1O++Nu/b/FNpAbk61BcCZS3Tsi1hED1CD1a1YjmU5XuD8eUZ5mT4OaaQVXdfh5uqmsoH3Pawkl9D1QwB8aQeMhCNoMScCb1KRMKg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ydWl1fQxY9zxdUsmMrCyhTprl/7naH6yltvuBHvLxHA=; b=UIFaKXcwAWGOhFGDNZb9nbBLtFdC45RgL5hkkptcE0JPw4u3orVm/t+F2PrkcX6nztMGMrWgFX/A1cnQKveGAHLn40MxWAmAzZAQOMWlWOhzXmbHsRaF8mv9RpnMzsmrLonCUxPkyDhXKfxyhRaV4gNP4j7fgIFPl7HvJUlOHcw= Received: from BN8PR00MB0563.namprd00.prod.outlook.com (20.179.72.150) by BN8PR00MB0546.namprd00.prod.outlook.com (20.179.72.85) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2422.0; Mon, 21 Oct 2019 20:03:56 +0000 Received: from BN8PR00MB0563.namprd00.prod.outlook.com ([fe80::e17f:be07:82a2:12db]) by BN8PR00MB0563.namprd00.prod.outlook.com ([fe80::e17f:be07:82a2:12db%9]) with mapi id 15.20.2421.000; Mon, 21 Oct 2019 20:03:56 +0000 From: Mike Jones To: "ace@ietf.org" CC: Christer Holmberg , Yoav Nir Thread-Topic: Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs) spec addressing Gen-ART and SecDir reviews Thread-Index: AdWISUzizf75y3DXQE6viU8tMCuYDw== Date: Mon, 21 Oct 2019 20:03:55 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=47cf3cea-cd42-4024-9fe9-0000441aabaa; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2019-10-21T19:54:04Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [24.18.207.73] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 6aa9da19-992a-46c7-a665-08d75661cde7 x-ms-office365-filtering-ht: Tenant x-ms-traffictypediagnostic: BN8PR00MB0546: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 0197AFBD92 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(376002)(346002)(136003)(366004)(39860400002)(396003)(209900001)(199004)(189003)(74316002)(7696005)(7736002)(236005)(5640700003)(102836004)(86362001)(54896002)(66946007)(66446008)(66556008)(66476007)(64756008)(6436002)(76116006)(6306002)(9686003)(71190400001)(6506007)(25786009)(22452003)(54906003)(99286004)(6916009)(55016002)(6116002)(3846002)(790700001)(966005)(4744005)(14454004)(2906002)(316002)(26005)(71200400001)(66066001)(5660300002)(4326008)(33656002)(2351001)(10290500003)(186003)(256004)(81156014)(1730700003)(8676002)(606006)(81166006)(52536014)(8936002)(2501003)(486006)(10090500001)(476003)(478600001)(21615005)(8990500004)(6606295002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN8PR00MB0546; H:BN8PR00MB0563.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: BCL:0; x-microsoft-antispam-message-info: 40XRpuLTJuHUhd406aKaKBZfLCDfCSalvhfdS+QFexU7/6GNmRD1fc50o8QewYPxnSZgM9jTgWYQ9rUwv6wkvdKPuLkendPjDUWdpKsMhshHjw2eAIf1R3MANFjy1zG5xuY15Ps33vcYLc2ROsFYJkOqRMqo9Rw6NIZcjh9jFT6RZthAmqcjJnmUEatNRvZJRoBS95YHKMmcE4t3MOZm4ddkkc1IsrDgvkbhDHDFXHQMG4O5Yb8SGckdLUvgzdz7fKQcIQsKMy3G16A2/j+2hFVKmduJRb4gC0EiX5KVOELktgzrUL4ZDlFdVpO1E4yTvxnu87uicM2zuPn7tmvAdT9uTYg5dcY984uGTal7E7ZZDuVyIkcV9olC2tx6wPspzJrMMEfJfArLSH9t8HEY5M9F2tvI8TGl/60spDES/gvNZPUYjgVTOsMQIrIYyTJG x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BN8PR00MB0563CAB85436F68CB24A12A9F5690BN8PR00MB0563namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6aa9da19-992a-46c7-a665-08d75661cde7 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Oct 2019 20:03:56.0143 (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-CrossTenant-userprincipalname: gjQRu9F6maZbdS1gY/q/0CUHLljEg9dT4YsYBUNJGxKULc6GUa+iMph6qSs5MJcHCsiPrVbN1wv0wW21m/rjkg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN8PR00MB0546 Archived-At: Subject: [Ace] Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs) spec addressing Gen-ART and SecDir reviews 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 Oct 2019 20:04:07 -0000 --_000_BN8PR00MB0563CAB85436F68CB24A12A9F5690BN8PR00MB0563namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable A new version of the Proof-of-Possession Key Semantics for CBOR Web Tokens = (CWTs) specification has been published addressing the Gen-ART and SecDir r= eview comments. Thanks to Christer Holmberg and Yoav Nir, respectively, fo= r these useful reviews. The specification is available at: * https://tools.ietf.org/html/draft-ietf-ace-cwt-proof-of-possession-09 An HTML-formatted version is also available at: * http://self-issued.info/docs/draft-ietf-ace-cwt-proof-of-possession-0= 9.html -- Mike P.S. This note was also posted at http://self-issued.info/?p=3D2016 and as= @selfissued. --_000_BN8PR00MB0563CAB85436F68CB24A12A9F5690BN8PR00MB0563namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

A new version of the Proof-of-Possession Key Semanti= cs for CBOR Web Tokens (CWTs) specification has been published addressing t= he Gen-ART and SecDir review comments.  Thanks to Christer Holmberg an= d Yoav Nir, respectively, for these useful reviews.

 

The specification is available at:

 

An HTML-formatted version is also available at:=

 

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

 

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

 

--_000_BN8PR00MB0563CAB85436F68CB24A12A9F5690BN8PR00MB0563namp_-- From nobody Mon Oct 21 14:56: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 DED111209F9; Mon, 21 Oct 2019 14:56:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XljANE2eqq0k; Mon, 21 Oct 2019 14:56:52 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D17F1209C9; Mon, 21 Oct 2019 14:56:52 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x9LLuiTU003275 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 21 Oct 2019 17:56:47 -0400 Date: Mon, 21 Oct 2019 14:56:44 -0700 From: Benjamin Kaduk To: Mike Jones Cc: Christer Holmberg , "gen-art@ietf.org" , "draft-ietf-ace-cwt-proof-of-possession.all@ietf.org" , "ietf@ietf.org" , "ace@ietf.org" Message-ID: <20191021215644.GF69013@kduck.mit.edu> References: <157021105722.1446.14439223392992273252@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [Ace] Genart last call review of draft-ietf-ace-cwt-proof-of-possession-08 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 Oct 2019 21:56:55 -0000 Thanks for the update, Mike. I will go ahead and get this in front of the whole IESG, but one comment below... On Fri, Oct 18, 2019 at 10:57:06PM +0000, Mike Jones wrote: > Hi Christer, > > https://tools.ietf.org/html/draft-ietf-ace-cwt-proof-of-possession-09 has been published, which addresses your review comments in the ways proposed below. Thanks again for your review! > > -- Mike > > From: Mike Jones > Sent: Wednesday, October 16, 2019 12:40 PM > To: Christer Holmberg ; gen-art@ietf.org > Cc: draft-ietf-ace-cwt-proof-of-possession.all@ietf.org; ietf@ietf.org; ace@ietf.org > Subject: RE: Genart last call review of draft-ietf-ace-cwt-proof-of-possession-08 > > > Thanks for your review, Christer. Replies are inline, prefixed by "Mike>"… > > > > -----Original Message----- > From: Christer Holmberg via Datatracker > > Sent: Friday, October 4, 2019 10:44 AM > To: gen-art@ietf.org > Cc: draft-ietf-ace-cwt-proof-of-possession.all@ietf.org; ietf@ietf.org; ace@ietf.org > Subject: Genart last call review of draft-ietf-ace-cwt-proof-of-possession-08 > > > > Reviewer: Christer Holmberg > > Review result: Ready with Issues > > > > I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. > > > > For more information, please see the FAQ at > > > > . > > > > Document: draft-ietf-ace-cwt-proof-of-possession-08 > > Reviewer: Christer Holmberg > > Review Date: 2019-10-04 > > IETF LC End Date: 2019-10-09 > > IESG Telechat date: Not scheduled for a telechat > > > > Summary: For most part the document is ready, but I have a few editorial comments and an issue. > > > > Major issues: N/A > > > > Minor issues: > > > > The text says in the Security Considerations that one must ensure that the might not understand the "cnf" claim, and that applications must ensure that receivers support it. > > > > Q1: How are you going to ensure that, and why do you have to ensure that? RFC > > 8392 doesn't even seem to require that one must ensure that the receivers support CWT. > > > > Mike> I agree that this text isn't actually actionable. I propose that we simply delete it. > > > > Q2: For receivers that do support CWT, RFC 8392 says that unsupported claims must be discarded. If that can't be applied for "cnf" I think you need to explain why. > > > > Mike> The RFC 8392 requirement does apply. This is also aligned with the text in 3.1, so I don't think there are any changes needed to the spec for this. I don't think there's anything else we can reasonably do/say here, but it does seem potentially surprising that we could get into a state where client and AS both think that the token is a PoP token but the RS interprets it as a bearer token. I expect that in most cases where PoP CWTs are used in an application context, either the client would be able to detect this (e.g., by the RS not asking for a confirmation message) or the client would send a confirmation message and the RS would treat it as malformed, so the scope for practical impact seems limited, but it's hard to confidently make sweeping statements. -Ben From nobody Tue Oct 22 19:12:30 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 377AC12080E; Tue, 22 Oct 2019 19:12:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ace@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.107.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ace@ietf.org Message-ID: <157179674918.24848.16483665952274145804@ietfa.amsl.com> Date: Tue, 22 Oct 2019 19:12:29 -0700 Archived-At: Subject: [Ace] I-D Action: draft-ietf-ace-coap-est-16.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, 23 Oct 2019 02:12:29 -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-16.txt Pages : 50 Date : 2019-10-22 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-16 https://datatracker.ietf.org/doc/html/draft-ietf-ace-coap-est-16 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-coap-est-16 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 Oct 22 19:28: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 611901207FC for ; Tue, 22 Oct 2019 19:28:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 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_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 header.b=FdUOOERo; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=NSrP2q7s 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 7_DFnNRRhFHo for ; Tue, 22 Oct 2019 19:28:08 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9524A120048 for ; Tue, 22 Oct 2019 19:28:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2314; q=dns/txt; s=iport; t=1571797688; x=1573007288; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=Gbi6f7wT8Y00YN+ou3qhrS/hfDy0NGa4dY5c4W7BbuE=; b=FdUOOERoAjKIK2vi7a3MxH/Hr519XwM0jS2tVsGOJ9+N+M3C3iqwCsu0 Wd8vaS7Hzq1xh7gtzKV7+HVIPPJj1zZDZtx4jeuDFhXQk9K1tmVNC55IT KyRkgX4rhjXtLfyOwzOfys066kKfenuOs8w2rsZbZ6CDsbuW+cdKjewv8 E=; IronPort-PHdr: =?us-ascii?q?9a23=3ACtn+mRFM67x0rysXq/VL+J1GYnJ96bzpIg4Y7I?= =?us-ascii?q?YmgLtSc6Oluo7vJ1Hb+e4z1Q3SRYuO7fVChqKWqK3mVWEaqbe5+HEZON0pNV?= =?us-ascii?q?cejNkO2QkpAcqLE0r+eebpZikiFcJLfFRk5Hq8d0NSHZW2ag=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AmAgANuq9d/4ENJK1lHAEBAQEBBwE?= =?us-ascii?q?BEQEEBAEBgWoEAQELAYFKUAVsVyAECyqHbQOKWE2CD5gCglIDVAkBAQEMAQE?= =?us-ascii?q?YCwoCAQGEQAKDKiQ3Bg4CAwkBAQQBAQECAQUEbYU3AQuFSwEBAQQBARAoBgE?= =?us-ascii?q?BLAwLBAIBCBEEAQEeARAnCx0IAgQTCBqDAYJGAy4BAgynFwKBOIhhgieCfgE?= =?us-ascii?q?BBYE0AQMCDkGDAhiCFwmBNgGMDhiBQD+BV4JMPoJiAQECAQEWgUmDQIIsrWI?= =?us-ascii?q?KgiSHDo4zgjtyhmGPQI42iCeRIAIEAgQFAg4BAQWBaCMqgS5wFRohgmwJRxA?= =?us-ascii?q?UgwaDc4UUhT90AYEojnkBAQ?= X-IronPort-AV: E=Sophos;i="5.68,219,1569283200"; d="scan'208";a="649874532" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 23 Oct 2019 02:28:07 +0000 Received: from XCH-RCD-013.cisco.com (xch-rcd-013.cisco.com [173.37.102.23]) by alln-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id x9N2S7lV017999 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for ; Wed, 23 Oct 2019 02:28:07 GMT Received: from xhs-aln-002.cisco.com (173.37.135.119) by XCH-RCD-013.cisco.com (173.37.102.23) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 22 Oct 2019 21:28:07 -0500 Received: from xhs-rcd-001.cisco.com (173.37.227.246) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 22 Oct 2019 21:28:06 -0500 Received: from NAM01-SN1-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 22 Oct 2019 21:28:06 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=PCVLZIpa8dj/nleI0xzk1y2u0v56KOeI5QgyZJZ4wWaz5Z7dbgwGfm5f8fVKQUBS9HEc7QQY4qPhOrGjqvebarosQhbQB+G+WQ05k1vrbCPvJQUYufQNJYt4j3EVRUo/w3WDOX/kK4R34XC1qh6fsfjw5G7LPxb0b7DGmG5y1/i/oiwPbX80ttx3C0Ow8kNcmjY6Q8zl+nnxFovR2SInNRBWzQCMU/7XTa6cSUPUfdg2Ivsy6tMm7TwmP0dFbwkk2Dj+mwmYVMEf7DE7eFnSo3WpLFnN3nLWur5DqMUv4MnSIYRJwIdVlAZGXsh5ACp06ZH6GB/AnJBnzfv0f0OYVw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=D8mZdIJzFGOWnMUiPfdlKNb/hosy5msvknh51s3kwBU=; b=BDy0iGpPEfU+H/Ia1IKqc+dFSAP9SrohezG2qRioLW6oSWvFuvDhY5hhnty9mgj/wHTzo8dUZn+Nkc5+mQHdJ54jRXpw9ywMq2JuzDpxvAf9n2BYTzBH08U4oVecQmhw2JuaVjko7bUeN+Mf6VpIrEL0/k7lJZ6pMV+f/Nx7ay1M6kkMUz92hDZlICbk4mo6DRawQ+59bUtNUZq/RSwCulkLFH3Rdd6cF9AWm3QWAnBZOLsMqJ2NwT884Gb9VHXESZpxQO7cB+T57Ktd/kUd/oxNopkUWh09nEzJexoZS7cQO3YRkbZu3ofZHDdIknfVX8RJrANQB+gnw+D147XXsg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=D8mZdIJzFGOWnMUiPfdlKNb/hosy5msvknh51s3kwBU=; b=NSrP2q7s1QmPpm36IkBWlUv/REVx4kAfy7gbwzS+XaeWOZJOiPIgqRfyD28it6Y1x94BEjASyvgN1Bn0BXm8n+yZ7WqibI718lZDwU0T67qR/Hop8wJ/43YFOFgBoXzD87BNWwvra0Cep4lJYSc5xMCBLg4q/RmCZSrFFMv1V4s= Received: from BN7PR11MB2547.namprd11.prod.outlook.com (52.135.255.146) by BN7PR11MB2660.namprd11.prod.outlook.com (52.135.245.27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2367.24; Wed, 23 Oct 2019 02:28:05 +0000 Received: from BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::5082:c814:2836:9e2a]) by BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::5082:c814:2836:9e2a%7]) with mapi id 15.20.2347.029; Wed, 23 Oct 2019 02:28:05 +0000 From: "Panos Kampanakis (pkampana)" To: "ace@ietf.org" Thread-Topic: [Ace] I-D Action: draft-ietf-ace-coap-est-16.txt Thread-Index: AQHViUdYqZfSD26dyUW5DDbScEn1hadnf8kg Date: Wed, 23 Oct 2019 02:28:05 +0000 Message-ID: References: <157179674918.24848.16483665952274145804@ietfa.amsl.com> In-Reply-To: <157179674918.24848.16483665952274145804@ietfa.amsl.com> 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=pkampana@cisco.com; x-originating-ip: [2001:420:c0c4:1008::398] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 353bc3fe-b00c-472b-3908-08d75760a2b9 x-ms-traffictypediagnostic: BN7PR11MB2660: x-ms-exchange-purlcount: 7 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 019919A9E4 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(346002)(396003)(39860400002)(366004)(376002)(136003)(13464003)(199004)(189003)(33656002)(316002)(66574012)(966005)(186003)(256004)(86362001)(2351001)(478600001)(8676002)(6246003)(2906002)(14454004)(102836004)(6506007)(53546011)(4001150100001)(7696005)(76116006)(66556008)(66476007)(66446008)(64756008)(66946007)(99286004)(76176011)(25786009)(46003)(6116002)(5640700003)(6436002)(486006)(5660300002)(305945005)(7736002)(229853002)(1730700003)(81166006)(81156014)(11346002)(74316002)(446003)(52536014)(2501003)(476003)(8936002)(55016002)(6916009)(6306002)(71200400001)(71190400001)(9686003); DIR:OUT; SFP:1101; SCL:1; SRVR:BN7PR11MB2660; H:BN7PR11MB2547.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: F9zyK+Wi8VUBhCSFAFPom/6T4w3QiTFOR8HaolE/Q72veJvKT156dXlpTz+D57WGWPsQcvZk7LcsbSIEc5NMXWzwfTLroL9UE0FkWUFiR1bejBapeui9tdmZEWa0sLJGC4kx7kFLTRR48L6kGyGymqJAs8/RQb+rOUiYkHk6ugCDqmP+LDWo3lUSeJNMmK/irdKG66f1TjQvvF5cehNKMXkqJxhJ+rG0tcKelCI5RWCZyNeJqTbE7o3mcHiMDbgFb5nI5gmgQsSTO53UbJObVNJBAVaeaeZuGRzcCAaKxYhH9iFsDZ/xzUbzhubDzWmiSjVnWsnGPt66rDHeyhChmM4izLfQ7X7/fzjWSJZcaxJSXgLuoK5JJLZV6HAB7zB0DDryW87+J24j+vH2/eMlEKaRNHgSTNJrs4sfaE2kNq473ZlgwubVYjowWPNi55aT4TsWPXZe26smedUGwpIKdkqRqJ4s+iE7OXz/FIG1gKs= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 353bc3fe-b00c-472b-3908-08d75760a2b9 X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Oct 2019 02:28:05.0821 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: gnqvAmtc07Iz3yevW8WXSxt/aATnGSts1kNEcFjwkKRcn25i33Zz5jc+jOAqom32xqkKXPc5j1kmg79K5vtgxg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR11MB2660 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.23, xch-rcd-013.cisco.com X-Outbound-Node: alln-core-9.cisco.com Archived-At: Subject: Re: [Ace] I-D Action: draft-ietf-ace-coap-est-16.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, 23 Oct 2019 02:28:10 -0000 Hi, This iteration addresses Yaron's secdir review. Thank you for the thorough = feedback Yaron.=20 The summary of the fixes is here https://github.com/SanKumar2015/EST-coaps/= issues/152 =20 The diff is here https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-ace-coap-= est-16.txt=20 Rgs,=20 Panos -----Original Message----- From: Ace On Behalf Of internet-drafts@ietf.org Sent: Tuesday, October 22, 2019 10:12 PM To: i-d-announce@ietf.org Cc: ace@ietf.org Subject: [Ace] I-D Action: draft-ietf-ace-coap-est-16.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-16.txt Pages : 50 Date : 2019-10-22 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-16 https://datatracker.ietf.org/doc/html/draft-ietf-ace-coap-est-16 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ace-coap-est-16 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 Oct 23 18:50:26 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A80E1200E7; Wed, 23 Oct 2019 18:50:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.423 X-Spam-Level: X-Spam-Status: No, score=-1.423 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.226, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UrIpi8ORkOhO; Wed, 23 Oct 2019 18:50:18 -0700 (PDT) Received: from mail-vs1-f41.google.com (mail-vs1-f41.google.com [209.85.217.41]) (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 0637F12011E; Wed, 23 Oct 2019 18:50:18 -0700 (PDT) Received: by mail-vs1-f41.google.com with SMTP id d3so15169279vsr.1; Wed, 23 Oct 2019 18:50:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=3/DDgqjHqsM5FgJelCTQNqEMwOitxtst9u2TrVCA+gs=; b=Q/Z4diim42pvYvKedRjXO15b52B3007sYzkD49uObuQP8+fRxnBRkFWypRT25WJcf4 LLcTXNeMmMsc0HV335cNZeyUUcX3nomGs9JG7DuqdF//zuznymOAnM+Tk38VwtE5rp0c jfOtwjouq6DDt5xbQtEYDij07KfZAtVfkJJeOT/uPPGV/jALaYsTiV00i4l1x66bSjhz FOXZLagXORco77mJaKpMU6teg+CjWXiFKnBDmrEmEQ45aNjerPDQxFq5gwALOfTaH1gi gGdIWGgFAc2yvtSuYBF4aIXIrGESLtFty3zlT5e2cUPHKaWxQrrBVZ5x7lRwOhKJA3Tb sfrQ== X-Gm-Message-State: APjAAAXKbOdqtjasAkB5bxh475xPib2tn+KACUYHLodXKcXdwbvImiiu HsTbHooPOPziUPGqRDbtN7XhtR9NJVGSqA6ArZ0= X-Google-Smtp-Source: APXvYqxkcYraHphhyHrtDuWISScX+sJNHZLwg1OX1pCE0xKrFN6t+wNqXPpYkOIG1y4qdvaUkWzAdsA0fVg6FSSCiNo= X-Received: by 2002:a67:e88b:: with SMTP id x11mr7368329vsn.180.1571881816469; Wed, 23 Oct 2019 18:50:16 -0700 (PDT) MIME-Version: 1.0 References: <021c01d5839c$d53206a0$7f9613e0$@augustcellars.com> <033101d5851b$30a41ad0$91ec5070$@augustcellars.com> In-Reply-To: <033101d5851b$30a41ad0$91ec5070$@augustcellars.com> From: Daniel Migault Date: Wed, 23 Oct 2019 21:50:05 -0400 Message-ID: To: Jim Schaad Cc: Cigdem Sengul , draft-ietf-ace-mqtt-tls-profile@ietf.org, ace@ietf.org Content-Type: multipart/alternative; boundary="0000000000004cb4ad05959e4188" Archived-At: Subject: Re: [Ace] Review for draft-ietf-ace-mqtt-tls-profile-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: Thu, 24 Oct 2019 01:50:24 -0000 --0000000000004cb4ad05959e4188 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable HI, Thanks for sending an update. Please find my comments of the draft. Regards, Daniel 1. Introduction In this document, message topics are treated as resources. Clients use an access token, bound to a key (the proof-of-possession key) to authorize with the MQTT Broker their connection and publish/subscribe permissions to topics. In the context of this ACE profile, the MQTT Broker acts as the Resource Server (RS). In the rest of the document RS and Broker are used interchangeably. To provide communication confidentiality and Resource Server authentication, TLS is used. This document makes the same assumptions as the Section 4 of the ACE framework [I-D.ietf-ace-oauth-authz] regarding Client and RS registration with the AS and establishing of keying material. The document seems mostly focuses on the latest version of MQTT, I am wondering if we could encourage similarly the use of the latest version of TLS that is 1.3 at the time of writing. It seems AS as not been defined previously, so maybe it should be expanded there. MQTTS Secured transport profile of MQTT. MQTTS runs over TLS. The Server in MQTT and acts as an intermediary between Clients that publish Application Messages, and the Clients that made Subscriptions. The Broker acts as the Resource Server for the Clients. publishes Subscription A subscription comprises a Topic Filter and a maximum Quality of Service (QoS). Maybe that would be clearer to specify QoS level as well. PINGREQ A ping request sent from a Client to the Broker. It signals to the Broker that the Client is alive, and is used to confirm that the Broker is still alive. It may look a bit strange to have PINGREQ without PINGRESP. You might also indicate the keep alive period is provided in the CONNECT Will An application message published by the Server after the network connection is closed in cases where the network connection is not closed normally. If the Will Flag is set, then the payload of the CONNECT message has information about the Will. The Will consists of the Will Properties, Will Topic, and Will Payload fields in the CONNECT message. The first sentence seems to be related to the Will message while the intent, I suppose of teh definition was to define the generic conpet of Will. It might be clearer to expose the principle of the wil, that is a server sends a given message in case a client is disconnected improperly. It might be clearer to mention explicitly there is a Will "concept" that is implemented a WillFlag WillQoS, WillRetain in the CONNECT header as well as other Will Properties and Will Messages. This mostly consists in the last sentence being moved up. 2. Protocol Interactions This section describes the following exchanges between Clients, the Broker, and the Authorization Server according to the MQTT v5.0. Though english is not my first language, I have the impression the text can be interpreted as MQTT enables clients to establish session which does not seems correct to me. The text that follows clarifies this as well. 2.1. Authorizing Connection Establishment If the Client is resource-constrained, a Client Authorisation Server may I have the impression an AS would be sufficient. carry out the token request on behalf of the Client, and later, onboard the Client with the token. Also, these interfaces may be implemented using other protocols, e.g., CoAP or MQTT. While the introduction and the figure mentions that HTTPS is used as a transport, it might be worth mentioning that HTTPS is being used. I propose to add "...other protocols than HTTPS, e.g ... 2.1.1. Client Token Request to the Authorization Server (AS) The first step in the protocol flow (Figure 1 (A)) is the token acquisition by the Client from the AS. When requesting an access token from the AS, the Client MAY include parameters in its request as defined in Section 5.6.1 of the ACE framework [I-D.ietf-ace-oauth-authz]. The media format is 'application/ ace+json'. The profile parameter MUST be set to 'mqtt_tls'. The OAuth 2.0 AS uses a JSON structure in the payload of its responses both to client and RS. I understand that some parameters are mandatory while other are not. I believe it might be clearer to start with the mandatory parameters (MUST) and then mention that other parameters are optional (MAY). That said, it might be simpler, if that is correct to mention that the token request is as described in Section 5.6.1 of the ACE framewor= k [I-D.ietf-ace-oauth-authz] with the profile set to "mqtt". In the case of an error, the AS returns error responses for HTTP- based interactions as ASCII codes in JSON content, as defined in Section 5.2 of RFC 6749 [RFC6749]. Error messages are handled by OAuth2.0 instead of the ACE framework in order to keep JSON format. I am wondering why do we have the requirement to use ace+cbor only for error message ? It seems to me a bit strange to have error handling defined in another document. 2.1.2. Client Connection Request to the Broker (C) This section describes how the Client transports the token to the Broker (RS) via the CONNECT control message after the TLS handshake. If the TLS handshake has already been performed, it would be good to mention which credentials have been used. Obviously, if the token is provided by the CONNECT message, I expect other credentials to be involved. This is similar to an earlier proposal by Fremantle et al. [fremantle14]. Alternatively, the token may be used for the TLS session establishment as described in the DTLS profile for ACE [I-D.gerdes-ace-dtls-authorize]. In this case, both the TLS PSK and RPK handshakes MAY be supported. It would be good to expand Raw Public Keys (RPK). My reading is that this section does not provide a single mechanism for the Client to be authenticated by the Broker, but instead two different ways. I would thus recommend to state it clearly in the introduction of the section. Currently, the section mentions: """ This section describes how the Client transports the token to the Broker (RS) via the CONNECT control message after the TLS handshake. """ An then we have a relatively detailed description on how this is performed using TLS. It might be better to say something around the following lines: """ This section describes how the Client transports the token to the Broker (RS). This can be achieved during the TLS KEX or during the MQTT session establishment via the CONNECT control message after the TLS handshake. """ I am not sure that MAY is appropriated here. I suspect that if none are supported, this method will not work. As a result, if seems to me that it woudl be more accurate to say that TLS Client and TLS server MUST support the PSK authentication as well as the raw public key. One issue I have with I-D.gerdes-ace-dtls-authorize that is now draft-ietf-ace-dtls-authorize is that it seems to only consider TLS 1.2. With TLS 1.3 PSK and RPK are supported. My interpretation is that PSK provides mutual authentication, but in our case RPK will only authenticate the client. If that is correct, there might be a new to specify how the RS is authenticated by the Client. This option is described in more detail in Appendix B. see my comment in annex B. After the token acquisition, the Client connects to the RS (Broker) using the CONNECT message of MQTT over TLS. For server authentication, the client MAY either have the ability to receive and validate a certificate or a raw public key from the Broker. I might have missed something, but I thought that PSK/RPK were used to authenticate the Client. While in this case the RPK is used to authenticate the RS, is that the same RPK provided by the AS or another one? For token transport, the RS SHOULD support AUTH (Authentication Exchange) method. The RS MAY support token transport via username and password, which is described in Section 3 for MQTT v3.1.1. The rest of this section describes the AUTH method, for which the username and password flags MUST be set to 0. Maybe the reference should be for MQTTv5 instead of MQTTv3. I believe it would be good to specify how setting the password flag interacts with the Authentication method. 2.1.2.1. Proof-of-Possession over Predefined Field For this option, the Authentication Data MUST contain the token and the keyed message digest (MAC) or the Client signature. To calculate the keyed message digest (MAC) or the Client signature, the Client SHOULD apply the PoP key to the CONNECT payload. I have the impression the latest sentence indicates that the Authenticated Data is include din the CONNECT payload. I have however the impression that Authenticated Data is part of the properties which are include din the variable header and not the payload. The CONNECT payload has at least a Client Identifier, and if the Will Flag is set to 1, may contain Will-related information. The Client Identifier is a MUST be a UTF-8 Encoded String (i.e., is prefixed with a two-byte integer length field that gives the number of bytes in a UTF-8 encoded string itself). The Client Identifier may be 1-23 UTF-8 encoded bytes, and contain only the characters "0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ". For my information I would like to understand the mention of UTF8 while only ascii characters are permitted. It seems that teh server MUST accept these and MAY accept others as well as a longer client id. Am I correct ? The nonce coded this way has a randomness of 62**23 =3D2**138 =3D 17 bytes 2.1.4. The Broker's Response to Client Connection Request If the RS accepts the connection, it MUST store the token until the end of connection. On Client or RS disconnection, the token is discarded, and the Client MUST provide a token inside each CONNECT message. The latest sentence is unclear to me. I think that disconnection can be interpreted in two way: 1) the disconnection of the will or a DISCONNECT. I believe both are considered. If the token is not self-contained and the Broker uses token introspection, it MAY cache the validation result to authorize the subsequent PUBLISH and SUBSCRIBE messages. PUBLISH and SUBSCRIBE messages, which are sent after a connection set-up, do not contain access tokens. If the introspection result is not cached, then the RS needs to introspect the saved token for each request. The Broker SHOULD use a cache time out to introspect tokens regularly. The latest sentence seems to indicate that result provided as via introspection do not necessarily have a Time to Live which could be interpreted as a commitment from the AS to authorize during that period. If that is possible, it would be appropriated this time out is provided by the AS. I am also wondering why the token expiration cannot be considered as well. Appendix B. The Authorization Information Endpoint The main document described a method for transporting tokens inside MQTT CONNECT messages. In this section, we describe an alternative method to transport an access token. The method consists of the MQTT Broker accepting PUBLISH messages to a public "authz-info" topic. A Client using this method MUST first connect to the Broker, and publish the access token using the "authz- info" topic. The Broker must verify the validity of the token (i.e., through local validation or introspection). After publishing the token, the Client disconnects from the Broker and is expected to try reconnecting over TLS. I understand this as an open channel for CONNECT and sending PUBLISHING message. This potentially open the door for DoSing the RS either by openning too many MQTT sessions or by sending too many tokens. I expect this to be mentioned in the security consideration section as well as potential mechanisms to limit these risks. On Thu, Oct 17, 2019 at 2:47 PM Jim Schaad wrote: > > > > > *From:* Cigdem Sengul > *Sent:* Thursday, October 17, 2019 4:13 AM > *To:* Jim Schaad > *Cc:* draft-ietf-ace-mqtt-tls-profile@ietf.org; ace@ietf.org > *Subject:* Re: [Ace] Review for draft-ietf-ace-mqtt-tls-profile-01 > > > > Hello Jim, > > Thanks for this review. I have responded inline. > > > > 1. Are there any specifics about using ACE over HTTP that need to be > explicitly stated some place. Some of these things might include: > a) Must be HTTPS even if encrypted requests/responses are > provided. > b) What types of validation are permitted/required: anon-anon, > server validation, server & client validation. The latter corresponds to > current DTLS statements. > c) Are we looking for using the normal HTTP/HTTPS ports or should > we > be using different ports? > > > > >> Agreed. Need to specify that it is HTTPS. > > Mutual authentication and server validation Required. > > Was thinking it would be normal HTTPS ports. Should we consider different= ? > > What scenarios should permit anon-anon; anon clients? > > > > [JLS] If you look at my last email I went through this. Anon-anon is > going to be a bad idea because the server is never validated, however > client anon is fine since you are going to validate the client in the MQT= T > protocol. > > > > > > > 4. Section 2.1.2: It is not clear from the document is a Broker is going > to > also have the possibility of doing a post of the token via HTTPS. > Currently > I would think not, but given that this is documented in OAuth 2.0 as an > option I am not clear. > > >> Do you mean for introspection? Yes, this is a MAY as in the core > document, and so in this one too. > > And if there is an RS-AS interaction, we expect that to be on HTTPS. > > I will try to see where I should clarify in the text. > > > > [JLS] No, I was originally looking at doing an HTTPS post of the token > from the client to the RS. This was before I figured out that you have a= n > alternative method of doing this in the MQTT protocol and so it should no= t > be needed. Being clear on the fact that this would not be expected is > probably a good idea. > > > > > 7. In Figure 2, I think the use of Client Identifier is somewhat > confusing. I think this is supposed to be the token as the Client > Identifier is a different thing in MQTT. Either that or you need to do a > better job of describing the property block. > > > > OK. I think I should explain MQTT packets better. > > A connect packet has three parts: 1) Fixed header 2) Variable Header and > 3) Payload. > > The variable header may have several properties, and Authentication Metho= d > and Authentication Data are two of these properties. > > According to MQTT Specification: > > The ClientID MUST be present and is the first field in the CONNECT packet > Payload. > > The ClientID MUST be a UTF-8 Encoded String > > A Server MAY allow a Client to supply a ClientID that has a length of zer= o > bytes, however, if it does so the Server MUST treat this as a special cas= e. > > > > And this is what is done in the case of a collision: > > If the ClientID represents a Client already connected to the Server, the > Server sends a DISCONNECT packet to the existing Client with Reason Code = of > 0x8E (Session taken over) > > > > Is this more clear? If yes, I will try to clarify in text. > > > > [JLS] That is not where I was having a problem. I was getting confused b= y > the figure itself. Labeling the figure better might help. =E2=80=9CMQTT= V5.0 > CONNECT control message with =E2=80=98ace=E2=80=99 authentication method= =E2=80=9D. I would rather > not have all of the abbreviations in the title, but I can live with it. > > > > > 8. If the value of Clean Start or Expiry Interval are not set correct is > the server to fail the connect? > > > > >> Agreed. This should be specified. > > Two options: 1) Do not accept connection or 2) accept the connection but > then never create sessions, and then server MUST set Session Present to > 0 in the CONNACK packet, indicating > > no session is present. > > > > This basically makes Clean Start flag meaningless. > > If this is better than client MUST be setting those parameters correctly, > then we can go this way. > > Any thoughts? > > > > [JLS] I don=E2=80=99t really care one way or the other. Given that there= is the > return value in the CONNACK, I think that a simple statement that the fla= g > is set to 0 regardless of the value coming in. > > > > > 10. Section 2.1.2.1 - I am having a problem computing the MAC over the > payload of the CONNECT message. The password where the value is placed i= s > included in the payload and I am not clear if it should be computed up to > that value or if a fixed value should be used for the computation. > > > > >>OK. I think it got muddled because I was trying to find a solution for = a > scenario where the ClientId is used across sessions, and hence, not rando= m. > > > > Two cases. > > 1) Client ID uniquely random across each Client connection attempt to > Broker: MAC over Payload - Payload begins with ClientID and MAY include > Will Properties if Client indicated that it will have a will. > > 2) Client ID NOT uniquely random: MAC over Authentication Data. > > > > It may be best to choose one method and just say MUST always have a nonce > in Authentication Data, and MAC is computed over that? > > > > [JLS] Lets step back and look at the problem I think you are trying to > solve. > > - If you are trying to make sure that there is not a replay of the > signature, then this would require that the server keep track of the l= ist > of nonce values that the client has provided. > - If you are trying to make sure that the signature is =E2=80=9Cfresh= =E2=80=9D then > the server would need to be able to provide some type of data as part = of > the value being signed. As I think I have said before the latter can = be > satisfied by getting your nonce value from the TLS session using a > tls-exporter. > > > > If neither of these problems is trying to be solved, then there is no nee= d > for the nonce at all. > > > > > > 11. I am worried about the text on the Client Identifier in this section. > It is not clear to me that having the client generate a random value for > this field is good just in terms of the possibility of collisions occurri= ng > on the server. The text in the MQTT 5.0 document appears to say that thi= s > is more interesting for the situation of getting back state that was left > on > the server after a disconnect and not so much for a clean session. > > > > >> Yes, but as I explained for comment 7, in MQTT, the typical case is th= e > client provides its id. > > However, to cater to all requirements and all implementation > possibilities, maybe it is best to just use a nonce as explained for > comment 10 and not tie anything to client id. > > > > Previously, when we were writing the draft for MQTT v3.1.1 we wanted to > provide a solution that uses the available fields in the CONNECT packet a= s > much as possible; without > > introducing any new fields. This was because of the constraints of the > MQTT v3.1.1. MQTT v5 gives us more options to implement this better. > > > > For backward compatibility, we would need to think if we create a special > data structure to be used in the password so that it holds both the > MAC/signature and the nonce. > > > > As the use of ClientId seems to create confusion, I am leaning towards > this solution. Any thoughts? > > > > [JLS] Look at the previous answer and the re-ask the question. > > > > > > 13. Is there someplace that authentication methods need to be registered? > I > was unable to see any such registry setup with OASIS from the v5 > specification. Should we suggest to the MQTT group that this is somethin= g > that should be done? > > > > >> This is an interesting thought. The draft was indeed discussed in the > OASIS MQTT WG. > > > > But, the WG may consider this out of scope, as they have on their charter > page: > > Transport level security is assumed and no mandatory security features > will be added. > > The MQTT v5 draft says: > > The Authentication Method is commonly a SASL mechanism, and using such a > registered name aids interchange. However, the Authentication Method is n= ot > constrained to using registered SASL mechanisms. > > > > [JLS] I think that the lack of a registry should be identified someplace > in the document. This is probably a security consideration that there > might be a different authentication method which re-uses the same > authentication method name. > > > > > > 17. It is not clear to me, how in the scope string is the ability to hav= e > a > "will" indicated? > > >> If the Will Flag is set to 1, the Will Topic follows the Client ID and > Will Properties in the Payload. > > This is where the broker learns the Will Topic. > > Then the scope would be publish_. > > And subscribes would need to subscribe_ to receive this > message. > > Will clarify in text. > > > > [JLS] publish makes sense to me. I was just being overly complicated. > > > > 18. Section 2.1.4 - I am unsure what the implications of discarding toke= ns > on the end of a connection are going to be. How do you publish the token > before doing the connection or is that only for an updated token? > > > > >> Tokens are discarded at the end of disconnection because no previous > session state is kept. > > And a token is expected in the new CONNECT request (otherwise, it is AS > discovery) > > > > Before the connection, a token may be transported via "authz-info" topic > described in Appendix B. > > During the connection, a new token may be transported via the AUTH packet > - which enables reauthentication. > > > > [JLS] This is still not clear to me. Is the transport of the token via > =E2=80=9Cauth-info=E2=80=9D topic not considered to be part of the sessio= n? If you say > that you look at just the last value published, then is there not going t= o > be a race condition between two different clients trying to publish and > connect? > > > > > 20. I am not sure what the benefits of doing the check on a PINGREQUEST = is > going to be. Like the relay of a PUBLISH message this is just going to > produce a DISCONNECT and a closed channel. If this is really allowed, th= en > you should potentially also say that the Broker could do a check based on > clock time elapsing. (I.e. do the check every hour.) > > > > >> This was suggested by one of the reviewers that provide MQTT services > (his e-mail regarding this was sent to the ace list). > > It was suggested as an optimization for detecting token expirations and > disconnecting early. > > (i.e., if you are already receiving PINGREQUESTs, use these as a trigger > to check the token). > > I think time-based checks may also help and be added as an option. > > > > [JLS] Ok > > > > > 22. Not sure if this goes here or in the connect documentation. There > needs > to be a check that the will topic is a topic that the client is going to = be > permitted to publish on. Corner case, if the ability to publish a will = in > the event that this permission is lost. Does this kill the session or th= e > will message? I.e. should the permission for the will message be recheck= ed > before sending it allowing for the time based expiration of the token. > > > > >> We have been thinking about this. > > If the disconnect is due to a token expiration, and hence, also includes > the will topic as well, you have to decide between: > > 1) publish the will > > 2) do not publish the will. > > At the moment, it's written like we publish the will - but on second > consideration, > > it seems safer to say "Publish the Will on Server Disconnect or unusual > disconnect if the token (the will permission) has not expired". > > > > [JLS] I would be fine with either position, after all at the time the > =E2=80=9Cpublish=E2=80=9D event occurred the token was valid, this is jus= t deferring > relaying it to subscribers. > > > > Jim > > > > > > Thanks again for these comments, will create the necessary github issues > and start revising the text. > > > > Best, > > > > > Jim > > > > > > > > > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > --0000000000004cb4ad05959e4188 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
HI,=C2=A0
=
Thanks for sending an update. Please find my comments of the= draft.=C2=A0

Regards,=C2=A0

<= div>Daniel

1.=C2=A0 Introduction

=C2=A0 =C2=A0In this document, message topics are treated a= s resources.=C2=A0 Clients
=C2=A0 =C2=A0use an access token, bound to a = key (the proof-of-possession key) to
=C2=A0 =C2=A0authorize with the MQT= T Broker their connection and publish/subscribe
=C2=A0 =C2=A0permissions= to topics.=C2=A0 In the context of this ACE profile, the MQTT
=C2=A0 = =C2=A0Broker acts as the Resource Server (RS).=C2=A0 In the rest of the doc= ument
=C2=A0 =C2=A0RS and Broker are used interchangeably.=C2=A0 To prov= ide communication
=C2=A0 =C2=A0confidentiality and Resource Server authe= ntication, TLS is used.
=C2=A0 =C2=A0This document makes the same assump= tions as the Section 4 of the ACE
=C2=A0 =C2=A0framework [I-D.ietf-ace-o= auth-authz] regarding Client and RS
=C2=A0 =C2=A0registration with the A= S and establishing of keying material.

<mglt> The document see= ms mostly focuses on the latest version of MQTT,
I am wondering if we co= uld encourage similarly the use of the latest
version of TLS that is 1.3= at the time of writing.

It seems AS as not been defined previously,= so maybe it should be
expanded there.
</mglt>=C2=A0
=


=C2=A0 =C2=A0MQTTS
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0Secured transport profile of MQTT.=C2=A0 MQTTS runs= over TLS.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The Server in MQTT a= nd acts as an intermediary between
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0Clients that publish Application Messages, and the Clients
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0that made Subscriptions.=C2=A0 The Broker= acts as the Resource
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Server fo= r the Clients.

<mglt>publishes</mglt>

=
=C2=A0 =C2=A0Subscription
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0A subscription comprises a Topic Filter and a maximum Quality
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0of Service (QoS).

<mglt>= Maybe that would be clearer to specify QoS level as well.</mglt>
<= /div>

=C2=A0 =C2=A0PINGREQ
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0A ping request sent from a Client to the Broker.=C2=A0 It = signals
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0to the Broker that the = Client is alive, and is used to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0confirm that the Broker is still alive.

<mglt>It may look a= bit strange to have PINGREQ without PINGRESP. You
might also indicate t= he keep alive period is provided in the CONNECT</mglt>

=C2=A0 = =C2=A0Will
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0An application messa= ge published by the Server after the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0network connection is closed in cases where the network
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0connection is not closed normally.=C2=A0 If = the Will Flag is set,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0then the = payload of the CONNECT message has information about
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0the Will.=C2=A0 The Will consists of the Will Prope= rties, Will
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Topic, and Will Pay= load fields in the CONNECT message.

<mglt>
The first senten= ce seems to be related to the Will message while the
intent, I suppose o= f teh definition was to define the generic conpet of
Will. It might be c= learer to expose the principle of the wil, that is a
server sends a give= n message in case a client is disconnected
improperly. =C2=A0 It might b= e clearer to mention explicitly there is a Will
"concept" that= is implemented a WillFlag WillQoS, WillRetain in the
CONNECT header as = well as other Will Properties and Will Messages. This
mostly consists in= the last sentence being moved up. =C2=A0
</mglt>
2.=C2=A0 Protocol Interactions

=C2=A0 =C2=A0This sectio= n describes the following exchanges between Clients, the
=C2=A0 =C2=A0Br= oker, and the Authorization Server according to the MQTT v5.0.

<m= glt> Though english is not my first language, I have the impression the<= br>text can be interpreted as MQTT enables clients to establish session
= which does not seems correct to me. The text that follows clarifies thisas well. =C2=A0
</mglt>

2.1.=C2=A0 A= uthorizing Connection Establishment

If the
= =C2=A0 =C2=A0Client is resource-constrained, a Client Authorisation Server = may

<mglt>I have the impression an AS would be sufficient.<= /mglt>

=C2=A0 =C2=A0carry out the token request on behalf of the = Client, and later,
=C2=A0 =C2=A0onboard the Client with the token.=C2=A0= Also, these interfaces may be
=C2=A0 =C2=A0implemented using other prot= ocols, e.g., CoAP or MQTT.
<mglt>While the introduction and the f= igure mentions that HTTPS is used
as a transport, it might be worth ment= ioning that HTTPS is being used. I
propose to add "...other protoco= ls than HTTPS, e.g ...
</mglt>

2.1.1.= =C2=A0 Client Token Request to the Authorization Server (AS)

=C2=A0 = =C2=A0The first step in the protocol flow (Figure 1 (A)) is the token
= =C2=A0 =C2=A0acquisition by the Client from the AS.=C2=A0 When requesting a= n access
=C2=A0 =C2=A0token from the AS, the Client MAY include paramete= rs in its request
=C2=A0 =C2=A0as defined in Section 5.6.1 of the ACE fr= amework
=C2=A0 =C2=A0[I-D.ietf-ace-oauth-authz].=C2=A0 The media format = is 'application/
=C2=A0 =C2=A0ace+json'.=C2=A0 The profile param= eter MUST be set to 'mqtt_tls'.=C2=A0 The
=C2=A0 =C2=A0OAuth 2.0= AS uses a JSON structure in the payload of its responses
=C2=A0 =C2=A0b= oth to client and RS.

<mglt> I understand that some parameters= are mandatory while other are
not. I believe it might be clearer to sta= rt with the mandatory
parameters (MUST) and then mention that other para= meters are optional
(MAY). That said, it might be simpler, if that is co= rrect to mention
that the token request is as described in Section 5.6.1= of the ACE framework
=C2=A0 =C2=A0[I-D.ietf-ace-oauth-authz] with the p= rofile set to "mqtt".
</mglt>

<= div>
=C2=A0 =C2=A0In the case of an error, the AS returns error response= s for HTTP-
=C2=A0 =C2=A0based interactions as ASCII codes in JSON conte= nt, as defined in
=C2=A0 =C2=A0Section 5.2 of RFC 6749 [RFC6749].
<mglt>Error messages are handled by OAuth2.0 instead of the ACE
f= ramework in order to keep JSON format. I am wondering why do we have
the= requirement to use ace+cbor only for error message ? It seems to me
a b= it strange to have error handling defined in another document.
</mglt= >


2.1.2.=C2=A0 Client Connection Request to the Br= oker (C)

=C2=A0 =C2=A0This section describes how the Client transpor= ts the token to the
=C2=A0 =C2=A0Broker (RS) via the CONNECT control mes= sage after the TLS handshake.

<mglt>If the TLS handshake has a= lready been performed, it would be good
to mention which credentials hav= e been used. Obviously, if the token is
provided by the CONNECT message,= I expect other credentials to be
involved. </mglt>

=C2=A0 = =C2=A0This is similar to an earlier proposal by Fremantle et al.
=C2=A0 = =C2=A0[fremantle14].=C2=A0 Alternatively, the token may be used for the TLS=
=C2=A0 =C2=A0session establishment as described in the DTLS profile for= ACE
=C2=A0 =C2=A0[I-D.gerdes-ace-dtls-authorize].=C2=A0 In this case, b= oth the TLS PSK and
=C2=A0 =C2=A0RPK handshakes MAY be supported.
&l= t;mglt>
It would be good to expand Raw Public Keys (RPK). My reading = is that
this section does not provide a single mechanism for the Client = to be
authenticated by the Broker, but instead two different ways. I wou= ld
thus recommend to state it clearly in the introduction of the section= .
Currently, the section mentions:
"""
This section= describes how the Client transports the token to the
=C2=A0 =C2=A0Broke= r (RS) via the CONNECT control message after the TLS handshake.
"&q= uot;"

An then we have a relatively detailed description on how = this is
performed using TLS. It might be better to say something around = the
following lines:
"""
This section describes how= the Client transports the token to the
=C2=A0 =C2=A0Broker (RS). This c= an be achieved during the TLS KEX or during the
MQTT session establishme= nt via the CONNECT control message after the TLS handshake.
""= "

I am not sure that MAY is appropriated here. I suspect that i= f none are
supported, this method will not work. As a result, if seems t= o me that
it woudl be more accurate to say that TLS Client and TLS serve= r MUST
support the PSK authentication as well as the raw public key.
One issue I have with I-D.gerdes-ace-dtls-authorize that is now
dra= ft-ietf-ace-dtls-authorize is that it seems to only consider TLS 1.2.
Wi= th TLS 1.3 PSK and RPK are supported.

My interpretation is that PSK= provides mutual authentication, but in our
case RPK will only authentic= ate the client. If that is correct, there
might be a new to specify how = the RS is authenticated by the Client.

</mglt>
=

=C2=A0This option is described in more
=C2= =A0 =C2=A0detail in Appendix B.

<mglt>see my comment in annex = B.</mglt>



=C2= =A0 =C2=A0After the token acquisition, the Client connects to the RS (Broke= r)
=C2=A0 =C2=A0using the CONNECT message of MQTT over TLS.=C2=A0 For se= rver
=C2=A0 =C2=A0authentication, the client MAY either have the ability= to receive and
=C2=A0 =C2=A0validate a certificate or a raw public key = from the Broker. =C2=A0

<mglt>I might have missed something, b= ut I thought that PSK/RPK were
used to authenticate the Client. While in= this case the RPK is used to
authenticate the RS, is that the same RPK = provided by the AS or another
one? </mglt>

=C2=A0 =C2=A0For token transport, the RS SHOULD support AUTH (Authent= ication
=C2=A0 =C2=A0Exchange) method.=C2=A0 The RS MAY support token tr= ansport via username
=C2=A0 =C2=A0and password, which is described in Se= ction 3 for MQTT v3.1.1.=C2=A0 The
=C2=A0 =C2=A0rest of this section des= cribes the AUTH method, for which the
=C2=A0 =C2=A0username and password= flags MUST be set to 0.

<mglt>
Maybe the reference should = be for MQTTv5 instead of MQTTv3.
I believe it would be good to specify = how setting the password flag
interacts with the Authentication method. =
</mglt>


2.1.2.1.=C2=A0 Proof-of-= Possession over Predefined Field

=C2=A0 =C2=A0For this option, the A= uthentication Data MUST contain the token and
=C2=A0 =C2=A0the keyed mes= sage digest (MAC) or the Client signature.=C2=A0 To calculate
=C2=A0 =C2= =A0the keyed message digest (MAC) or the Client signature, the Client
= =C2=A0 =C2=A0SHOULD apply the PoP key to the CONNECT payload.

=C2= =A0 <mglt> I have the impression the latest sentence indicates that t= he
Authenticated Data is include din the CONNECT payload. I have however=
the impression that Authenticated Data is part of the properties which<= br>are include din the variable header and not the payload. </mglt> <= br>
The CONNECT payload
=C2=A0 =C2=A0has at least a Client Identifier= , and if the Will Flag is set to 1,
=C2=A0 =C2=A0may contain Will-relate= d information.=C2=A0 The Client Identifier is a
=C2=A0 =C2=A0MUST be a U= TF-8 Encoded String (i.e., is prefixed with a two-byte
=C2=A0 =C2=A0inte= ger length field that gives the number of bytes in a UTF-8
=C2=A0 =C2=A0= encoded string itself).=C2=A0 The Client Identifier may be 1-23 UTF-8
= =C2=A0 =C2=A0encoded bytes, and contain only the characters
=C2=A0 =C2= =A0"0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ&quo= t;.

<mglt>
For my information I would like to understand th= e mention of UTF8
while only ascii characters are permitted. It seems th= at teh server MUST
accept these and MAY accept others as well as a longe= r client id. Am I
correct ?

The nonce coded this way has a rando= mness of 62**23 =3D2**138 =3D 17 bytes
</mglt>

<= /div>
2.1.4.=C2=A0 The Broker's Response to Client Connection Reque= st

=C2=A0 =C2=A0If the RS accepts the connection, it MUST store the = token until the
=C2=A0 =C2=A0end of connection.=C2=A0 On Client or RS di= sconnection, the token is
=C2=A0 =C2=A0discarded, and the Client MUST pr= ovide a token inside each CONNECT
=C2=A0 =C2=A0message.

<mglt&= gt; The latest sentence is unclear to me. I think that disconnection
can= be interpreted in two way: 1) the disconnection of the will or a
DISCON= NECT. I believe both are considered. </mglt>

=
=C2=A0 =C2=A0If the token is not self-contained and the Broker uses to= ken
=C2=A0 =C2=A0introspection, it MAY cache the validation result to au= thorize the
=C2=A0 =C2=A0subsequent PUBLISH and SUBSCRIBE messages.=C2= =A0 PUBLISH and SUBSCRIBE
=C2=A0 =C2=A0messages, which are sent after a = connection set-up, do not contain
=C2=A0 =C2=A0access tokens.=C2=A0 If t= he introspection result is not cached, then the
=C2=A0 =C2=A0RS needs to= introspect the saved token for each request.=C2=A0 The Broker
=C2=A0 = =C2=A0SHOULD use a cache time out to introspect tokens regularly.

&l= t;mglt>The latest sentence seems to indicate that result provided as
= via introspection do not necessarily have a Time to Live which could be
= interpreted as a commitment from the AS to authorize during that
period.= If that is possible, it would be appropriated this time out is
provided= by the AS.
I am also wondering why the token expiration cannot be consi= dered as
well.
</mglt>

Appendix B.= =C2=A0 The Authorization Information Endpoint

=C2=A0 =C2=A0The main = document described a method for transporting tokens inside
=C2=A0 =C2=A0= MQTT CONNECT messages.=C2=A0 In this section, we describe an alternative=C2=A0 =C2=A0method to transport an access token.
=C2=A0 =C2=A0The meth= od consists of the MQTT Broker accepting PUBLISH messages to
=C2=A0 =C2= =A0a public "authz-info" topic.=C2=A0 A Client using this method = MUST first
=C2=A0 =C2=A0connect to the Broker, and publish the access to= ken using the "authz-
=C2=A0 =C2=A0info" topic.=C2=A0 The Brok= er must verify the validity of the token (i.e.,
=C2=A0 =C2=A0through loc= al validation or introspection).=C2=A0 After publishing the
=C2=A0 =C2= =A0token, the Client disconnects from the Broker and is expected to try
= =C2=A0 =C2=A0reconnecting over TLS.

<mglt>I understand this as= an open channel for CONNECT and sending
PUBLISHING message. This potent= ially open the door for DoSing the RS
either by openning too many MQTT s= essions or by sending too many tokens.
I expect this to be mentioned in = the security consideration section as
well as potential mechanisms to li= mit these risks.
</mglt>


On Thu, Oct 17, 2019= at 2:47 PM Jim Schaad <ietf@a= ugustcellars.com> wrote:

=C2= =A0

=C2=A0

From: Cigdem Sengul <cigdem.sengul@gmail.com>
Sent: = Thursday, October 17, 2019 4:13 AM
To: Jim Schaad <ietf@augustcellars.com= >
Cc: draft-ietf-ace-mqtt-tls-profile@ietf.org; ace@ietf.org
Subject:<= /b> Re: [Ace] Review for draft-ietf-ace-mqtt-tls-profile-01

=C2=A0

Hello Jim,

Thanks= for this review. I have responded inline.=C2=A0



1.=C2=A0 Are there any specifics about using ACE over HTTP that n= eed to be
explicitly stated some place.=C2=A0 Some of these things might= include:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 a) Must be HTTPS even if encrypted= requests/responses are provided.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 b) What t= ypes of validation are permitted/required: anon-anon,
server validation,= server & client validation. The latter corresponds to
current DTLS = statements.=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 c) Are we looking for usi= ng the normal HTTP/HTTPS ports or should we
be using different ports?=C2= =A0

=C2= =A0

>> Agreed. Need to sp= ecify that it is HTTPS.

= Mutual authentication and server validation Required.

Was thinking it would be normal HTTPS ports.= Should we consider different?

What scenarios should permit anon-anon; anon clients?=C2=A0

=C2=A0

[JLS] If you look at my last email I went through this.=C2=A0 Anon-anon= is going to be a bad idea because the server is never validated, however c= lient anon is fine since you are going to validate the client in the MQTT p= rotocol.

=C2=A0<= u>

=C2=A0

<= blockquote style=3D"border-top:none;border-right:none;border-bottom:none;bo= rder-left:1pt solid rgb(204,204,204);padding:0in 0in 0in 6pt;margin-left:4.= 8pt;margin-right:0in">

<= br>4.=C2=A0 Section 2.1.2: It is not clear from the document is a Broker is= going to
also have the possibility of doing a post of the token via HTT= PS.=C2=A0 Currently
I would think not, but given that this is documented= in OAuth 2.0 as an
option I am not clear.

>> Do you mean for introspection? Yes, t= his is a MAY as in the core document, and so in this one too.=C2=A0<= u>

And if there is an RS-AS intera= ction, we expect that to be on HTTPS.=C2=A0

I will try to see where I should clarify in the text.= =C2=A0

=C2=A0

[JLS] No, I was originally looking at doing an HTTPS pos= t of the token from the client to the RS.=C2=A0 This was before I figured o= ut that you have an alternative method of doing this in the MQTT protocol a= nd so it should not be needed.=C2=A0 =C2=A0Being clear on the fact that thi= s would not be expected is probably a good idea.

=C2=A0


7.=C2=A0 =C2=A0In Figure 2, I think the use o= f Client Identifier is somewhat
confusing.=C2=A0 I think this is suppose= d to be the token as the Client
Identifier is a different thing in MQTT.= =C2=A0 Either that or you need to do a
better job of describing the prop= erty block.

=C2=A0

OK. I think I should e= xplain MQTT packets better.=C2=A0

A connect packet has three parts: 1) Fixed header 2) Variable Hea= der and 3) Payload.

The = variable header may have several properties, and Authentication Method and = Authentication Data are two of these properties.=C2=A0

According to MQTT Specification:

The ClientID MUST be present and is the first f= ield in the CONNECT packet Payload.=C2=A0

The ClientID MUST be a UT= F-8 Encoded String

A Server MAY allow a Client to supply a Clien= tID that has a length of zero bytes,=C2=A0however, if it does so the Server= MUST treat this as a special case.

=C2=A0

<= p class=3D"MsoNormal">And this is what is done in the case of a collis= ion:

If the ClientID represents a Client already connected to th= e Server, the Server sends a DISCONNECT packet to the existing Client with = Reason Code of 0x8E (Session taken over)=C2=A0<= /p>

=C2=A0

Is this more clear? If yes, I will try to clarify in te= xt.=C2=A0

=C2=A0

<= p class=3D"MsoNormal">[JLS] That is not where I was having a problem.=C2=A0= I was getting confused by the figure itself.=C2=A0 Labeling the figure bet= ter might help.=C2=A0 =E2=80=9CMQTT V5.0 CONNECT control message with =E2= =80=98ace=E2=80=99 authentication method=E2=80=9D.=C2=A0 I would rather not= have all of the abbreviations in the title, but I can live with it.=

=C2=A0

=


8.=C2=A0 If the value of = Clean Start or Expiry Interval are not set correct is
the server to fail= the connect?

= =C2=A0

>> Agreed. Thi= s should be specified.=C2=A0

Two options: 1) Do not accept connection or 2) accept the connection b= ut then never create sessions, and then server=C2=A0=C2=A0MU= ST set Session Present to 0 in the CONNACK packet, indicating=C2=A0<= u>

no sessio= n is present.=C2=A0

=C2=A0

This basically= makes Clean Start flag meaningless.=C2=A0

If this is better than client MUST be setting those para= meters correctly, then we can go this way.=C2=A0

Any thoughts?

=C2=A0

[JLS] I don=E2=80=99t re= ally care one way or the other.=C2=A0 Given that there is the return value = in the CONNACK, I think that a simple statement that the flag is set to 0 r= egardless of the value coming in.=C2=A0

=C2=A0


10. Section 2.1.2.1 - I = am having a problem computing the MAC over the
payload of the CONNECT me= ssage.=C2=A0 The password where the value is placed is
included in the p= ayload and I am not clear if it should be computed up to
that value or i= f a fixed value should be used for the computation.

=C2=A0

>>OK. I think it got muddled because I was trying t= o find a solution for a scenario where the ClientId is used across sessions= , and hence, not random.=C2=A0

=C2=A0

Two cases.=

1) Client ID uniquely r= andom across each Client connection attempt to Broker: MAC over Payload - P= ayload begins with ClientID and MAY include Will Properties if Client indic= ated that it will have a will.=C2=A0

2) Client ID NOT uniquely random: MAC over Authentication Da= ta.=C2=A0

=C2=A0<= u>

It may be best to choose one me= thod and just say MUST always have a nonce in Authentication Data, and MAC = is computed over that?

=C2= =A0

[JLS] Lets step back and look at the p= roblem I think you are trying to solve.=C2=A0 =C2=A0=C2=A0

  • I= f you are trying to make sure that there is not a replay of the signature, = then this would require that the server keep track of the list of nonce val= ues that the client has provided.
  • =C2=A0If you are trying to make sure that the signature is =E2=80= =9Cfresh=E2=80=9D then the server would need to be able to provide some typ= e of data as part of the value being signed.=C2=A0 As I think I have said b= efore the latter can be satisfied by getting your nonce value from the TLS = session using a tls-exporter.

=C2=A0

If neither of th= ese problems is trying to be solved, then there is no need for the nonce at= all.

=C2=A0

=C2=A0

11. I am worried about the text on the Client= Identifier in this section.
It is not clear to me that having the clien= t generate a random value for
this field is good just in terms of the po= ssibility of collisions occurring
on the server.=C2=A0 The text in the M= QTT 5.0 document appears to say that this
is more interesting for the si= tuation of getting back state that was left on
the server after a discon= nect and not so much for a clean session.

=C2=A0

>> Yes, but as I explained for comment 7, in MQTT, the typica= l case is the client provides its id.=C2=A0

However, to cater to all requirements and all implement= ation possibilities, maybe it is best to just use a nonce as explained for = comment 10 and not tie anything to client id.

<= p class=3D"MsoNormal">=C2=A0

Previously, when we were writing the draft for MQTT v3.1.1 we wanted t= o provide a solution that uses the available fields in the CONNECT packet a= s much as possible; without

introducing any new fields. This was because of the constraints of the = MQTT v3.1.1. MQTT v5 gives us more options to implement this better.=

=C2=A0

=

For backward compatibility, we would need to th= ink if we create a special data structure to be used in the password so tha= t it holds both the MAC/signature and the nonce.=C2=A0 =C2=A0=

=C2=A0

As the use of ClientId seems to create confusion, I am= leaning towards this solution. Any thoughts?

=C2=A0

[JLS] Look at the= previous answer and the re-ask the question.

<= p class=3D"MsoNormal">=C2=A0

=C2=A0

13. Is there someplace that authenticati= on methods need to be registered?=C2=A0 I
was unable to see any such reg= istry setup with OASIS from the v5
specification.=C2=A0 Should we sugges= t to the MQTT group that this is something
that should be done?

=C2=A0

<= /div>

>> This is an interesting thought. T= he draft was indeed discussed in the OASIS MQTT WG.=C2=A0

=

=C2=A0

But, the WG may consider this out of scope, as they have o= n their charter page:

= =C2=A0Transport level security is assumed and no mandatory security features = will be added.

Th= e MQTT v5 draft says:

The A= uthentication Method is commonly a SASL mechanism, and using such a registe= red name aids interchange. However, the Authentication Method is not constr= ained to using registered SASL mechanisms.

=C2=A0

[JLS] = I think that the lack of a registry should be identified someplace in the d= ocument.=C2=A0 This is probably a security consideration that there might b= e a different authentication method which re-uses the same authentication m= ethod name.

=C2=A0

=C2=A0

17.=C2=A0 = It is not clear to me, how in the scope string is the ability to have a
= "will" indicated?

>>=C2=A0If the Will Flag is set to 1, the Will Topic follows= the Client ID and Will Properties in the Payload.

=

This is where the broker learns the Will Top= ic.=C2=A0

Then the s= cope would be publish_<will topic>.=C2=A0

And subscribes would need to subscribe_<will= topic> to receive this message.=C2=A0

Will clarify in text.

=C2=A0

[JLS] publish makes = sense to me.=C2=A0 I was just being overly complicated.

=C2=A0

18.=C2=A0 Sec= tion 2.1.4 - I am unsure what the implications of discarding tokens
on t= he end of a connection are going to be.=C2=A0 How do you publish the token<= br>before doing the connection or is that only for an updated token?=

=C2=A0

>> Tokens are discarded at the end= of disconnection because no previous session state is kept.<= /p>

And a token is expected in the new CON= NECT request (otherwise, it is AS discovery)

=C2=A0

Before the connection, a token may be transported via=C2=A0 "authz= -info" topic described in Appendix B.=C2=A0

During the connection, a new token may be transpor= ted via the AUTH packet - which enables reauthentication.=C2=A0

=C2=A0

[JLS] This is still not clear to me.=C2=A0 Is the transport of the token v= ia =E2=80=9Cauth-info=E2=80=9D topic not considered to be part of the sessi= on?=C2=A0 If you say that you look at just the last value published, then i= s there not going to be a race condition between two different clients tryi= ng to publish and connect?=C2=A0

<= u>=C2=A0

=
20.=C2=A0 I am not sure what the benefits of doing the check on a PINGR= EQUEST is
going to be.=C2=A0 Like the relay of a PUBLISH message this is= just going to
produce a DISCONNECT and a closed channel.=C2=A0 If this = is really allowed, then
you should potentially also say that the Broker = could do a check based on
clock time elapsing.=C2=A0 (I.e. do the check = every hour.)

<= /u>=C2=A0

>> This was sug= gested by one of the reviewers that provide MQTT services (his e-mail regar= ding this was sent to the ace list).=C2=A0

It was suggested as an optimization for detecting token = expirations and disconnecting early.=C2=A0

(i.e., if you are already receiving PINGREQUESTs, use th= ese as a trigger to check the token).=C2=A0

I think time-based checks may also help and be added as= an option.

=C2=A0

[JLS] Ok

=C2=A0


22. Not sure if this goes here or in the connect documentatio= n.=C2=A0 There needs
to be a check that the will topic is a topic that t= he client is going to be
permitted to publish on.=C2=A0 =C2=A0Corner cas= e, if the ability to publish a will in
the event that this permission is= lost.=C2=A0 Does this kill the session or the
will message?=C2=A0 I.e. = should the permission for the will message be rechecked
before sending i= t allowing for the time based expiration of the token.

=C2=A0

>> We have been thinking about this.=C2=A0

If the disconnect is due to a= token expiration, and hence, also includes the will topic as well, you hav= e to decide between:

1) = publish the will

2) do n= ot publish the will.=C2=A0

At the moment, it's written like we publish the will - but on second= consideration,=C2=A0

it= seems safer to say "Publish the Will on Server Disconnect or unusual = disconnect if the token (the will permission) has not expired".=C2=A0<= u>

=C2=A0

[JLS] I would be fine with either position, after all at the ti= me the =E2=80=9Cpublish=E2=80=9D event occurred the token was valid, this i= s just deferring relaying it to subscribers.=C2=A0

=C2=A0

Jim<= u>

=C2=A0

=C2=A0

T= hanks again for these comments, will create the necessary github issues and= start revising the text.=C2=A0

=C2=A0

Best,=C2= =A0

=C2=A0=


Jim


=






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

__________________________________= _____________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
--0000000000004cb4ad05959e4188-- From nobody Fri Oct 25 09:01:03 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 096D212094B; Fri, 25 Oct 2019 09:01:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind_via_Datatracker?= To: "The IESG" Cc: draft-ietf-ace-cwt-proof-of-possession@ietf.org, ace-chairs@ietf.org, rdd@cert.org, ace@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.108.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?q?Mirja_K=C3=BChlewind?= Message-ID: <157201926102.4337.10953843577545450235.idtracker@ietfa.amsl.com> Date: Fri, 25 Oct 2019 09:01:01 -0700 Archived-At: Subject: [Ace] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-ace-cwt-proof-of-possession-09=3A_=28with_COMMENT=29?= X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2019 16:01:01 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-ace-cwt-proof-of-possession-09: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ace-cwt-proof-of-possession/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I would like to discuss one point with the IESG, however, not raising my ballot to "discuss" as I believe we can conclude quickly and this is not a major problem anyway. So it seems to become more common to not only have expert review but also post a registration request on a public list and wait for a couple of weeks for comments. While I myself am uncertain if that is a good or bad practice (maybe also depends on the protocol), I would like to discuss this part in the IANA section: Registration requests sent to the mailing list for review should use an appropriate subject (e.g., "Request to Register CWT Confirmation Method: example"). Registration requests that are undetermined for a period longer than 21 days can be brought to the IESG's attention (using the iesg@ietf.org mailing list) for resolution. I would think that, no matter what, registration request should be directed at IANA (and they would then post or forward to a mailing list and/or experts; or alternatively the experts can post than on the mailing list). I guess IANA would need to provide feedback here on what they prefer. However, for raising problems, of course everybody can always bring any problem to the IESG, but I think the first point of contact should also be IANA here. And then if no resolution can be find quickly for whatever reason, I would think that it's rather IANA that will bring this to the IESG (than the requesters directly). From nobody Fri Oct 25 09:31: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 EAA1D1208EA; Fri, 25 Oct 2019 09:31:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tsPjQaIGW9Az; Fri, 25 Oct 2019 09:31:54 -0700 (PDT) Received: from mail-il1-f173.google.com (mail-il1-f173.google.com [209.85.166.173]) (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 92C411201C6; Fri, 25 Oct 2019 09:31:54 -0700 (PDT) Received: by mail-il1-f173.google.com with SMTP id o16so2360138ilq.9; Fri, 25 Oct 2019 09:31:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=WATzs06QtEKufJr+P6EYED5tii+1ergROrh5I2gHi8U=; b=RfcZ7Ow6R1m00DSvswY8ozCX/3Gx3++aBjB6suqrIWHliU/YayhBToK4+k37sxbYCK 4XtojCa7p7NGbMqLB+GtSxkuioACJ0vmhgB1z+OeP7+Y6nsVZmwg5KLKyD+W35mmvXUi Q/8a9ISQjURAAIhyFGFdpPFf/OsbVE16cWa4Z1Jo/blq/Bto5dtC0+Pp4qxzunlh61fG 78YI6KARV+iv67X/18hSeZdofz0i4kKLcOse1DFBQvC2rt1vSC3Kx44Jr7WlVpRs4fX5 oGlLC6ec68e3v4JPkrDC/Vy2eCom8FXYh5Ia0GK5ueZ4WVl2/Rfe17V414pwvEs8+Cyu tgwA== X-Gm-Message-State: APjAAAUurpgVFmUm9iovD7tBeuGb/VtSrQ3DYYgs3UFFMSU2VY9FmaBN JAaxo/gewQUk9BMmhB7oVbPa36w9UNWhHAFCn2M= X-Google-Smtp-Source: APXvYqzIU7Hdg1C2dIy9M5K5SiSdHl75B6u1UX0+okFVWV/F8MlKJDB+y0lfjQqhXNXarUJLU8wToVrcHnd1gzcSmKI= X-Received: by 2002:a92:8408:: with SMTP id l8mr5325443ild.107.1572021113371; Fri, 25 Oct 2019 09:31:53 -0700 (PDT) MIME-Version: 1.0 References: <157201926102.4337.10953843577545450235.idtracker@ietfa.amsl.com> In-Reply-To: <157201926102.4337.10953843577545450235.idtracker@ietfa.amsl.com> From: Barry Leiba Date: Fri, 25 Oct 2019 12:31:42 -0400 Message-ID: To: =?UTF-8?Q?Mirja_K=C3=BChlewind?= Cc: The IESG , draft-ietf-ace-cwt-proof-of-possession@ietf.org, "Roman D. Danyliw" , ace-chairs@ietf.org, ace@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Ace] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-ace-cwt-proof-of-possession-09=3A_=28with_COMMENT=29?= 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 Oct 2019 16:31:56 -0000 Yeh, it's very common for authors to try to tell IANA how to handle registrations, and I often push back on that as inappropriate. There are certainly special conditions that IANA should be told about, but this is standard work-flow management stuff that ought to be left to IANA. I do think it should be changed before this is published, probably just removing that last sentence. b On Fri, Oct 25, 2019 at 12:01 PM Mirja K=C3=BChlewind via Datatracker wrote: > > Mirja K=C3=BChlewind has entered the following ballot position for > draft-ietf-ace-cwt-proof-of-possession-09: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-ace-cwt-proof-of-possession/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I would like to discuss one point with the IESG, however, not raising my = ballot > to "discuss" as I believe we can conclude quickly and this is not a major > problem anyway. > > So it seems to become more common to not only have expert review but also= post > a registration request on a public list and wait for a couple of weeks fo= r > comments. While I myself am uncertain if that is a good or bad practice (= maybe > also depends on the protocol), I would like to discuss this part in the I= ANA > section: > > Registration requests sent to the mailing list for review should use > an appropriate subject (e.g., "Request to Register CWT Confirmation > Method: example"). Registration requests that are undetermined for a > period longer than 21 days can be brought to the IESG's attention > (using the iesg@ietf.org mailing list) for resolution. > > I would think that, no matter what, registration request should be direct= ed at > IANA (and they would then post or forward to a mailing list and/or expert= s; or > alternatively the experts can post than on the mailing list). I guess IAN= A > would need to provide feedback here on what they prefer. However, for rai= sing > problems, of course everybody can always bring any problem to the IESG, b= ut I > think the first point of contact should also be IANA here. And then if no > resolution can be find quickly for whatever reason, I would think that it= 's > rather IANA that will bring this to the IESG (than the requesters directl= y). > > From nobody Fri Oct 25 10:00:46 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 D2AEF120870; Fri, 25 Oct 2019 10:00:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Christer Holmberg via Datatracker To: Cc: last-call@ietf.org, ace@ietf.org, draft-ietf-ace-cwt-proof-of-possession.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.108.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Christer Holmberg Message-ID: <157202283277.4219.10184234491533744147@ietfa.amsl.com> Date: Fri, 25 Oct 2019 10:00:32 -0700 Archived-At: Subject: [Ace] Genart telechat review of draft-ietf-ace-cwt-proof-of-possession-09 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2019 17:00:33 -0000 Reviewer: Christer Holmberg Review result: Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please wait for direction from your document shepherd or AD before posting a new version of the draft. For more information, please see the FAQ at . Document: draft-ietf-ace-cwt-proof-of-possession-09 Reviewer: Christer Holmberg Review Date: 2019-10-25 IETF LC End Date: None IESG Telechat date: 2019-10-31 Summary: My comments on the previous version have been addressed, and the document is now ready for publication. Major issues: N/A Minor issues: N/A Nits/editorial comments: N/A From nobody Fri Oct 25 14:20:25 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 CF5681209D2; Fri, 25 Oct 2019 14:12:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: kaduk@mit.edu, ace@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.108.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <157203793684.2724.3227595647367376701.idtracker@ietfa.amsl.com> Date: Fri, 25 Oct 2019 14:12:16 -0700 Archived-At: Subject: [Ace] ace - Requested session has been scheduled for IETF 106 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2019 21:14:09 -0000 Dear Jim Schaad, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. ace Session 1 (1:30 requested) Tuesday, 19 November 2019, Afternoon Session II 1520-1650 Room Name: Olivia size: 150 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/106/sessions/ace.ics Request Information: --------------------------------------------------------- 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): 1.5 Hours Number of Attendees: 50 Conflicts to Avoid: Chair Conflict: ipsecme saag tls secdispatch cbor core lamps cose Technology Overlap: teep homenet cfrg lwig emu t2trg suit oauth Key Participant Conflict: anima 6tisch gendispatch People who must be present: Daniel Migault Jim Schaad Benjamin Kaduk Resources Requested: Special Requests: --------------------------------------------------------- From nobody Fri Oct 25 14:39:12 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 23B2812008F; Fri, 25 Oct 2019 14:39:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rc5mlMtssYzY; Fri, 25 Oct 2019 14:39:02 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27CC912004A; Fri, 25 Oct 2019 14:39:02 -0700 (PDT) Received: from [192.168.217.110] (p5089AE1C.dip0.t-ipconnect.de [80.137.174.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 470HYc0qPczyY2; Fri, 25 Oct 2019 23:39:00 +0200 (CEST) From: Carsten Bormann Content-Type: text/plain; charset=utf-8 X-Mao-Original-Outgoing-Id: 593732337.7825429-22303503c08916d892453144e1d146d6 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Fri, 25 Oct 2019 23:38:59 +0200 Message-Id: To: ace@ietf.org, core@ietf.org, cose@ietf.org, cbor@ietf.org, t2trg@irtf.org X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: [Ace] Constrained Node/Network Cluster @ IETF106: FINAL AGENDA X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2019 21:39:05 -0000 Here is my usual eclectic condensed agenda based on the FINAL AGENDA for IETF106. Remember that, occasionally, futher agenda changes do happen. Quite a bit has been moved around from the draft agenda. LAKE no longer conflicts with SUIT, TMRID is now on top of ROLL and TEEP which is maybe a bit less of a problem for most. ACE/RATS still conflict (and the other RATS meeting has moved from Monday to Friday on top of COINRG, but you can do this RATS thing without me, can you?). WPACK no longer conflicts with COSE (but now does with LAKE, which again probably just is a personal problem), LAKE/ANIMA is a technology and a potential user again. All times are SGT (Singapore Time) =3D=3D UTC + 8 hours (=3D=3D China = time). Singapore doesn't obey the daylight savings myth. (Pure UTC times at https://datatracker.ietf.org/meeting/agenda-utc are useful for those who want to listen from remote.) Gr=C3=BC=C3=9Fe, Carsten FRIDAY, November 15, 2019 -- T2TRG/W3C WoT Workshop @ NUSS (https://is.gd/XWSfi8) SATURDAY, November 16, 2019 0830-2200 IETF Hackathon - Moor/Morrison SUNDAY, November 17, 2019 0830-1600 IETF Hackathon - Moor/Morrison 1700-1900 Welcome Reception - Fairmont Ballroom Foyer 1800-2000 Hot RFC Lightning Talks -- Padang MONDAY, November 18, 2019 1000-1200 Morning Session I Sophia ART dispatch Dispatch WG - Joint with ARTAREA Olivia IRTF icnrg Information-Centric Networking Collyer SEC mathmesh MatheMatical Mesh BOF 1330-1530 Afternoon Session I VIP A INT dnssd Extensions for Scalable DNS Service = Discovery WG - Joint with HOMENET VIP A INT homenet Home Networking WG - Joint with DNSSD Olivia IRTF*** dinrg Decentralized Internet Infrastructure Canning IRTF pearg Privacy Enhancements and Assessments = Research Group Padang SEC txauth Transactional Authorization and = Delegation BOF Sophia TSV tsvwg Transport Area Working Group WG 1550-1750 Afternoon Session II Canning ART httpbis Hypertext Transfer Protocol WG Padang IRTF irtfopen IRTF Open Meeting Collyer OPS v6ops IPv6 Operations WG Orchard RTG *** roll Routing Over Low power and Lossy = networks WG 1810-1910 Afternoon Session III Olivia INT *** lwig Light-Weight Implementation Guidance WG Padang IRTF maprg Measurement and Analysis for Protocols TUESDAY, November 19, 2019 1000-1200 Morning Session I VIP A INT tmrid Trustworthy Multipurpose Remote ID BOF Olivia RTG *** roll Routing Over Low power and Lossy = networks WG Sophia SEC *** teep Trusted Execution Environment = Provisioning WG Padang TSV quic QUIC WG 1330-1500 Afternoon Session I Padang ART abcd Application Behavior Considering DNS BOF VIP A RTG babel Babel routing protocol WG Sophia SEC *** suit Software Updates for Internet of Things = WG Hullet TSV rmcat RTP Media Congestion Avoidance = Techniques WG 1520-1650 Afternoon Session II Sophia GEN git GitHub Integration and Tooling WG Collyer INT *** lpwan IPv6 over Low Power Wide-Area Networks = WG Olivia SEC *** ace Authentication and Authorization for = Constrained Environments WG VIP A SEC *** rats Remote ATtestation ProcedureS WG Hullet TSV taps Transport Services WG 1710-1840 Afternoon Session III Hullet IRTF qirg Quantum Internet Proposed Research Group Sophia OPS anima Autonomic Networking Integrated Model = and Approach WG Padang SEC secdispatch Security Dispatch WG WEDNESDAY, November 20, 2019 1000-1200 Morning Session I Sophia ART *** core Constrained RESTful Environments WG Canning RTG raw Reliable and Available Wireless BOF Olivia SEC *** teep Trusted Execution Environment = Provisioning WG Padang TSV quic QUIC WG 1330-1500 Afternoon Session I Collyer ART webtrans WebTransport BOF Sophia INT *** 6lo IPv6 over Networks of = Resource-constrained Nodes WG Canning IRTF cfrg Crypto Forum Olivia SEC oauth Web Authorization Protocol WG 1520-1650 Afternoon Session II Collyer ART wpack Web Packaging BOF Hullet OPS anima Autonomic Networking Integrated Model = and Approach WG Sophia SEC *** lake Lightweight Authenticated Key Exchange = WG 1710-1940 IETF Plenary - Canning/Padang THURSDAY, November 21, 2019 1000-1200 Morning Session I Sophia IRTF*** t2trg Thing-to-Thing Orchard RTG bier Bit Indexed Explicit Replication WG Padang SEC tls Transport Layer Security WG Canning TSV tsvwg Transport Area Working Group WG 1330-1530 Afternoon Session I Collyer ART httpbis Hypertext Transfer Protocol WG Sophia INT 6man IPv6 Maintenance WG Olivia RTG rift Routing In Fat Trees WG Canning SEC saag Security Area Open Meeting 1550-1720 Afternoon Session II Padang INT intarea Internet Area Working Group WG Collyer RTG detnet Deterministic Networking WG Sophia SEC *** cose CBOR Object Signing and Encryption WG Hullet SEC oauth Web Authorization Protocol WG 1740-1840 Afternoon Session III Hullet ART *** cbor Concise Binary Object Representation = Maintenance and Extensions WG Sophia INT 6man IPv6 Maintenance WG Collyer RTG detnet Deterministic Networking WG Canning SEC tls Transport Layer Security WG Padang TSV tsvarea Transport Area Open Meeting FRIDAY, November 22, 2019 1000-1200 Morning Session I Hullet INT *** 6tisch IPv6 over the TSCH mode of IEEE = 802.15.4e WG Sophia IRTF coinrg Computing in the Network Proposed = Research Group Canning SEC mls Messaging Layer Security WG Orchard SEC *** rats Remote ATtestation ProcedureS WG 1220-1350 Morning Session II Hullet ART *** core Constrained RESTful Environments WG Sophia IRTF panrg Path Aware Networking RG Olivia SEC acme Automated Certificate Management = Environment WG From nobody Mon Oct 28 08:32: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 E788A1208DF; Mon, 28 Oct 2019 08:32:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tuwQXpP9dS4U; Mon, 28 Oct 2019 08:32:00 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3141A1208D8; Mon, 28 Oct 2019 08:32:00 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x9SFVoGo017379 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 28 Oct 2019 11:31:53 -0400 Date: Mon, 28 Oct 2019 08:31:50 -0700 From: Benjamin Kaduk To: Barry Leiba Cc: Mirja =?iso-8859-1?Q?K=FChlewind?= , draft-ietf-ace-cwt-proof-of-possession@ietf.org, "Roman D. Danyliw" , ace-chairs@ietf.org, The IESG , ace@ietf.org Message-ID: <20191028153150.GY69013@kduck.mit.edu> References: <157201926102.4337.10953843577545450235.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [Ace] =?iso-8859-1?q?Mirja_K=FChlewind=27s_No_Objection_on_draft?= =?iso-8859-1?q?-ietf-ace-cwt-proof-of-possession-09=3A_=28with_COMMENT=29?= 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 Oct 2019 15:32:02 -0000 On Fri, Oct 25, 2019 at 12:31:42PM -0400, Barry Leiba wrote: > Yeh, it's very common for authors to try to tell IANA how to handle > registrations, and I often push back on that as inappropriate. There > are certainly special conditions that IANA should be told about, but > this is standard work-flow management stuff that ought to be left to > IANA. I do think it should be changed before this is published, > probably just removing that last sentence. While I'm not opposed to normalizing on a default procedure, I think the authors were just trying to follow existing examples. RFC 7519: Values are registered on a Specification Required [RFC5226] basis after a three-week review period on the jwt-reg-review@ietf.org mailing list, on the advice of one or more Designated Experts. However, to allow for the allocation of values prior to publication, the Designated Experts may approve registration once they are satisfied that such a specification will be published. Registration requests sent to the mailing list for review should use an appropriate subject (e.g., "Request to register claim: example"). Within the review period, the Designated Experts will either approve or deny the registration request, communicating this decision to the review list and IANA. Denials should include an explanation and, if applicable, suggestions as to how to make the request successful. Registration requests that are undetermined for a period longer than 21 days can be brought to the IESG's attention (using the iesg@ietf.org mailing list) for resolution. RFC 8414: Values are registered on a Specification Required [RFC8126] basis after a two-week review period on the oauth-ext-review@ietf.org mailing list, on the advice of one or more Designated Experts. However, to allow for the allocation of values prior to publication, the Designated Experts may approve registration once they are satisfied that such a specification will be published. Registration requests sent to the mailing list for review should use an appropriate subject (e.g., "Request to register OAuth Authorization Server Metadata: example"). Within the review period, the Designated Experts will either approve or deny the registration request, communicating this decision to the review list and IANA. Denials should include an explanation and, if applicable, suggestions as to how to make the request successful. Registration requests that are undetermined for a period longer than 21 days can be brought to the IESG's attention (using the iesg@ietf.org mailing list) for resolution. RFC 8447: Specification Required [RFC8126] registry requests are registered after a three-week review period on the mailing list, on the advice of one or more designated experts. However, to allow for the allocation of values prior to publication, the designated experts may approve registration once they are satisfied that such a specification will be published. Registration requests sent to the mailing list for review SHOULD use an appropriate subject (e.g., "Request to register value in TLS bar registry"). Within the review period, the designated experts will either approve or deny the registration request, communicating this decision to the review list and IANA. Denials SHOULD include an explanation and, if applicable, suggestions as to how to make the request successful. Registration requests that are undetermined for a period longer than 21 days can be brought to the IESG's attention (using the mailing list) for resolution. [I stopped looking here] So if we're going to change things around, maybe we should issue an IESG statement. -Ben From nobody Mon Oct 28 08:54: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 E5E241200A3; Mon, 28 Oct 2019 08:54:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 8Fk1tHO1tfW0; Mon, 28 Oct 2019 08:54:28 -0700 (PDT) Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (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 A6429120098; Mon, 28 Oct 2019 08:54:28 -0700 (PDT) Received: from 200116b82cf86d0079e292451e40657f.dip.versatel-1u1.de ([2001:16b8:2cf8:6d00:79e2:9245:1e40:657f]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1iP7LU-0005ag-EB; Mon, 28 Oct 2019 16:54:16 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Mirja Kuehlewind In-Reply-To: <20191028153150.GY69013@kduck.mit.edu> Date: Mon, 28 Oct 2019 16:54:15 +0100 Cc: Barry Leiba , "Roman D. Danyliw" , ace-chairs@ietf.org, The IESG , ace@ietf.org, draft-ietf-ace-cwt-proof-of-possession@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <4F15E6F7-2DA0-4C90-B891-DDA65917D1A7@kuehlewind.net> References: <157201926102.4337.10953843577545450235.idtracker@ietfa.amsl.com> <20191028153150.GY69013@kduck.mit.edu> To: Benjamin Kaduk X-Mailer: Apple Mail (2.3445.104.11) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1572278068;9d8fcfed; X-HE-SMSGID: 1iP7LU-0005ag-EB Archived-At: Subject: Re: [Ace] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-ace-cwt-proof-of-possession-09=3A_=28with_COMMENT=29?= 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 Oct 2019 15:54:31 -0000 These are all quite recents examples, so maybe the procedures are = changing at the moment. I guess we as the IESG should be aware and = figure out what the right procedure actually should be here. > On 28. Oct 2019, at 16:31, Benjamin Kaduk wrote: >=20 > On Fri, Oct 25, 2019 at 12:31:42PM -0400, Barry Leiba wrote: >> Yeh, it's very common for authors to try to tell IANA how to handle >> registrations, and I often push back on that as inappropriate. There >> are certainly special conditions that IANA should be told about, but >> this is standard work-flow management stuff that ought to be left to >> IANA. I do think it should be changed before this is published, >> probably just removing that last sentence. >=20 > While I'm not opposed to normalizing on a default procedure, I think = the > authors were just trying to follow existing examples. >=20 > RFC 7519: >=20 > Values are registered on a Specification Required [RFC5226] basis > after a three-week review period on the jwt-reg-review@ietf.org > mailing list, on the advice of one or more Designated Experts. > However, to allow for the allocation of values prior to publication, > the Designated Experts may approve registration once they are > satisfied that such a specification will be published. >=20 > Registration requests sent to the mailing list for review should use > an appropriate subject (e.g., "Request to register claim: example"). >=20 > Within the review period, the Designated Experts will either approve > or deny the registration request, communicating this decision to the > review list and IANA. Denials should include an explanation and, if > applicable, suggestions as to how to make the request successful. > Registration requests that are undetermined for a period longer than > 21 days can be brought to the IESG's attention (using the > iesg@ietf.org mailing list) for resolution. >=20 > RFC 8414: >=20 > Values are registered on a Specification Required [RFC8126] basis > after a two-week review period on the oauth-ext-review@ietf.org > mailing list, on the advice of one or more Designated Experts. > However, to allow for the allocation of values prior to publication, > the Designated Experts may approve registration once they are > satisfied that such a specification will be published. >=20 > Registration requests sent to the mailing list for review should use > an appropriate subject (e.g., "Request to register OAuth > Authorization Server Metadata: example"). >=20 > Within the review period, the Designated Experts will either approve > or deny the registration request, communicating this decision to the > review list and IANA. Denials should include an explanation and, if > applicable, suggestions as to how to make the request successful. > Registration requests that are undetermined for a period longer than > 21 days can be brought to the IESG's attention (using the > iesg@ietf.org mailing list) for resolution. >=20 > RFC 8447: >=20 > Specification Required [RFC8126] registry requests are registered > after a three-week review period on the > mailing list, on the advice of one or more designated experts. > However, to allow for the allocation of values prior to publication, > the designated experts may approve registration once they are > satisfied that such a specification will be published. >=20 > Registration requests sent to the mailing list for review SHOULD use > an appropriate subject (e.g., "Request to register value in TLS bar > registry"). >=20 > Within the review period, the designated experts will either approve > or deny the registration request, communicating this decision to the > review list and IANA. Denials SHOULD include an explanation and, if > applicable, suggestions as to how to make the request successful. > Registration requests that are undetermined for a period longer than > 21 days can be brought to the IESG's attention (using the > mailing list) for resolution. >=20 > [I stopped looking here] >=20 > So if we're going to change things around, maybe we should issue an = IESG > statement. >=20 > -Ben >=20 >=20 From nobody Mon Oct 28 09:19: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 B16B112009C; Mon, 28 Oct 2019 09:19:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] 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 AMKmC45BznFl; Mon, 28 Oct 2019 09:19:10 -0700 (PDT) Received: from NAM06-DM3-obe.outbound.protection.outlook.com (mail-eopbgr640091.outbound.protection.outlook.com [40.107.64.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 78EA8120098; Mon, 28 Oct 2019 09:19:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ij5sXyJFHY8hp/+m7NJ4CXxURPfSIKQYbfXivxFhia/N1hOLXfoYftgqOTn+uiXbbVU5nNI9iqBkrvGRQOuKtOJoCxANOH0Ho9TQsKijJGS7JtFhg5hmSJyxNnKg/m8W46bmhjzs9Y352pbsXQSID+1J9DM1oOF4Q18FUV6OrMWYvsi6yNN0CmnIMPg0vf3C4nyXtXUBxohOM4yPxTrlUl9JcLW761vnzy7pOCHUHlUjyLsz7firfm2cVgWtG73BuwtjDyxMxxc1uJNePyi6TbyEk2nF7ny0qnUbKdMUsNSMRztYpsE3nr9CuK5KieGNuUn8y11mvRSR6HCr3qlGCQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=cSVuDPIzquJp9aeFUE3QehVUMvURxJyO4kIxY0mLGJA=; b=FgwII/9ePE2Ho6VxkUxj/SeEHl/biWDGS9IvGFU7jzPkpDGMnRk4jA0mZDDPuAPr9IoyN3ihxwEeb5/bNRqDMC3AuXp6Y1bg9AuNKaqWAondBYSx55WnEwDxJyXqb0GR+nTSgASBzPZppuV4QWODggBxNUWhkcvyhr/bWqcyLNFHdaDGIB2QInXXooSylovsutTxb/9sdqYmUA9Alu8G8QQ+tWrIiENTCwPGvWDOv294d6DFgidiyKgbXUkjkbTsPSkIoWLis+RXoBdzKiNayNvwF3PtT+g7ncq19WvUvG3qf28NzT7j6c9m+9JZ2ZCptVsAGQ1Ov9W4EZMGmMwizg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=cSVuDPIzquJp9aeFUE3QehVUMvURxJyO4kIxY0mLGJA=; b=EYp0881xPTSE9P0MSxfeH3v/txrEtC5oqO/Bmp6I33v7LKbO51d7FWVmrXjNljB0+P9xiWzk7rsELRiMeHpMEvfpMuf/ltq8kYbTMZbQeGDlX76qQO14H5zEBod9pOhdPGuDwRcW02lMLN60sj1zoXGju90xkc43oPnI1Nt2L+4= Received: from BYAPR00MB0567.namprd00.prod.outlook.com (20.179.56.25) by BYAPR00MB0534.namprd00.prod.outlook.com (20.178.53.223) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2434.0; Mon, 28 Oct 2019 16:19:05 +0000 Received: from BYAPR00MB0567.namprd00.prod.outlook.com ([fe80::88e8:5b6d:4227:2b30]) by BYAPR00MB0567.namprd00.prod.outlook.com ([fe80::88e8:5b6d:4227:2b30%3]) with mapi id 15.20.2441.000; Mon, 28 Oct 2019 16:19:05 +0000 From: Mike Jones To: Mirja Kuehlewind , Benjamin Kaduk CC: Barry Leiba , "Roman D. Danyliw" , "ace-chairs@ietf.org" , The IESG , "ace@ietf.org" , "draft-ietf-ace-cwt-proof-of-possession@ietf.org" Thread-Topic: =?iso-8859-1?Q?[Ace]_Mirja_K=FChlewind's_No_Objection_on_draft-ietf-ace-c?= =?iso-8859-1?Q?wt-proof-of-possession-09:_(with_COMMENT)?= Thread-Index: AQHVjaTaf28MZ9kKEUmdwFvS0aZ7rqdwNJuAgAAGEbA= Date: Mon, 28 Oct 2019 16:19:05 +0000 Message-ID: References: <157201926102.4337.10953843577545450235.idtracker@ietfa.amsl.com> <20191028153150.GY69013@kduck.mit.edu> <4F15E6F7-2DA0-4C90-B891-DDA65917D1A7@kuehlewind.net> In-Reply-To: <4F15E6F7-2DA0-4C90-B891-DDA65917D1A7@kuehlewind.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=d43c9af0-0d5d-447f-9fa0-000049ed41b5; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2019-10-28T16:15:57Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [50.47.93.218] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: f217f2b9-7714-46e7-ac3a-08d75bc28d91 x-ms-traffictypediagnostic: BYAPR00MB0534: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 0204F0BDE2 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(376002)(396003)(39860400002)(366004)(346002)(13464003)(189003)(199004)(66574012)(256004)(186003)(26005)(8936002)(76176011)(110136005)(71190400001)(71200400001)(224303003)(6506007)(66066001)(74316002)(55016002)(2171002)(6246003)(53546011)(305945005)(229853002)(33656002)(7736002)(14444005)(102836004)(7696005)(99286004)(6306002)(10090500001)(6436002)(3846002)(476003)(4326008)(6116002)(52536014)(81156014)(5660300002)(81166006)(9686003)(86362001)(2906002)(486006)(22452003)(8990500004)(64756008)(66556008)(66476007)(66946007)(66446008)(14454004)(966005)(316002)(25786009)(446003)(54906003)(76116006)(11346002)(10290500003)(478600001); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR00MB0534; H:BYAPR00MB0567.namprd00.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: FFCMgB/5p+oowApExIJ4PdDFQwpXNNM5Al2bx6/0oS6ShT4AccYoxbXX0Dtwl9sGZq8MPcsi0me+V8QTBaXVyooV+MRxjI09qSzPe91UHrtAAmQbAr4BToqHMdLX/gh74wB4jApvCPAPOWDgvS325l/fdzrqAg5vR/4FwmMJSGF6dUza17/qYSf81rep6OcifzCeZ+DEfCbwRl+Zmwoc0t85IkLE4s6cGfLssv52m8QPiDb5fLvhNwTx5o1jB7qmJXCAL3NcJePpVkXBQ7GKL48quV/L3e1Cz/bKKknXmWoXUZL88G2KEv0dEEyNVpAvCX4tIcjb7IALp0BL6pSIKyvMuKoJZR0u0IRYwocgUsKtqrewzzGrJg7m/UXX1zujjtq9KlCnifuywhTEA1yFRnQf1gPyUz26QeKsbSJYIhxOFHg2Z80M6D/7Unl20C3F x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: f217f2b9-7714-46e7-ac3a-08d75bc28d91 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Oct 2019 16:19:05.0833 (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-CrossTenant-userprincipalname: d8lMWFlw4RAbNc7cmY1M8VltA8UcJ0ElGP95ZQgF941yuDuMwhn3NeVtu3sKOsGzsg7Xf9Ob/WbkEtwCLkhG4w== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR00MB0534 Archived-At: Subject: Re: [Ace] =?iso-8859-1?q?Mirja_K=FChlewind=27s_No_Objection_on_draft?= =?iso-8859-1?q?-ietf-ace-cwt-proof-of-possession-09=3A_=28with_COMMENT=29?= 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 Oct 2019 16:19:14 -0000 The practice of using a mailing list for registration requests to enable pu= blic visibility of them goes back at least to .well-known URI registrations= https://tools.ietf.org/html/rfc5785 by Mark Nottingham in April 2010. OAu= th 2.0 followed this practice in RFC 6749, as did the JOSE specs and JWT in= RFCs 7515-19. The rest is history, as they say. -- Mike -----Original Message----- From: Mirja Kuehlewind =20 Sent: Monday, October 28, 2019 8:54 AM To: Benjamin Kaduk Cc: Barry Leiba ; Roman D. Danyliw ;= ace-chairs@ietf.org; The IESG ; ace@ietf.org; draft-ietf-ac= e-cwt-proof-of-possession@ietf.org Subject: Re: [Ace] Mirja K=FChlewind's No Objection on draft-ietf-ace-cwt-p= roof-of-possession-09: (with COMMENT) These are all quite recents examples, so maybe the procedures are changing = at the moment. I guess we as the IESG should be aware and figure out what t= he right procedure actually should be here. > On 28. Oct 2019, at 16:31, Benjamin Kaduk wrote: >=20 > On Fri, Oct 25, 2019 at 12:31:42PM -0400, Barry Leiba wrote: >> Yeh, it's very common for authors to try to tell IANA how to handle=20 >> registrations, and I often push back on that as inappropriate. There=20 >> are certainly special conditions that IANA should be told about, but=20 >> this is standard work-flow management stuff that ought to be left to=20 >> IANA. I do think it should be changed before this is published,=20 >> probably just removing that last sentence. >=20 > While I'm not opposed to normalizing on a default procedure, I think=20 > the authors were just trying to follow existing examples. >=20 > RFC 7519: >=20 > Values are registered on a Specification Required [RFC5226] basis > after a three-week review period on the jwt-reg-review@ietf.org > mailing list, on the advice of one or more Designated Experts. > However, to allow for the allocation of values prior to publication, > the Designated Experts may approve registration once they are > satisfied that such a specification will be published. >=20 > Registration requests sent to the mailing list for review should use > an appropriate subject (e.g., "Request to register claim: example"). >=20 > Within the review period, the Designated Experts will either approve > or deny the registration request, communicating this decision to the > review list and IANA. Denials should include an explanation and, if > applicable, suggestions as to how to make the request successful. > Registration requests that are undetermined for a period longer than > 21 days can be brought to the IESG's attention (using the > iesg@ietf.org mailing list) for resolution. >=20 > RFC 8414: >=20 > Values are registered on a Specification Required [RFC8126] basis > after a two-week review period on the oauth-ext-review@ietf.org > mailing list, on the advice of one or more Designated Experts. > However, to allow for the allocation of values prior to publication, > the Designated Experts may approve registration once they are > satisfied that such a specification will be published. >=20 > Registration requests sent to the mailing list for review should use > an appropriate subject (e.g., "Request to register OAuth > Authorization Server Metadata: example"). >=20 > Within the review period, the Designated Experts will either approve > or deny the registration request, communicating this decision to the > review list and IANA. Denials should include an explanation and, if > applicable, suggestions as to how to make the request successful. > Registration requests that are undetermined for a period longer than > 21 days can be brought to the IESG's attention (using the > iesg@ietf.org mailing list) for resolution. >=20 > RFC 8447: >=20 > Specification Required [RFC8126] registry requests are registered > after a three-week review period on the > mailing list, on the advice of one or more designated experts. > However, to allow for the allocation of values prior to publication, > the designated experts may approve registration once they are > satisfied that such a specification will be published. >=20 > Registration requests sent to the mailing list for review SHOULD use > an appropriate subject (e.g., "Request to register value in TLS bar > registry"). >=20 > Within the review period, the designated experts will either approve > or deny the registration request, communicating this decision to the > review list and IANA. Denials SHOULD include an explanation and, if > applicable, suggestions as to how to make the request successful. > Registration requests that are undetermined for a period longer than > 21 days can be brought to the IESG's attention (using the > mailing list) for resolution. >=20 > [I stopped looking here] >=20 > So if we're going to change things around, maybe we should issue an=20 > IESG statement. >=20 > -Ben >=20 >=20 From nobody Mon Oct 28 14:00: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 B8199120091; Mon, 28 Oct 2019 14:00:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eLpT1xCnTgUq; Mon, 28 Oct 2019 14:00:39 -0700 (PDT) Received: from mail-il1-f175.google.com (mail-il1-f175.google.com [209.85.166.175]) (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 E29AF120072; Mon, 28 Oct 2019 14:00:38 -0700 (PDT) Received: by mail-il1-f175.google.com with SMTP id p8so9454506ilp.2; Mon, 28 Oct 2019 14:00:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=ypRGvt7veI2HYho733aR0GlHkWJYzL3yB6pE2rVs21A=; b=L+/QaE5GJuJkVNzWIBMDmOXU8f4ClgDRaIQxmy3YbXJjFAr8iWVkGId8O3rWwDT1l3 8RE2DY2gHog0aZy0QQ3pZa7V0THdEqNB44EsbJM+OYJlvKZH8CVo92I0vqaarnLQLB/i hl7UMHhtiEahZ33nbxrif6BjZwdzz5RezIX8u6ilpoLdgOSY75/p+tEW49b3yfelQPv2 gcH5L5coIsuNo9raW5xSG59zZgvFwxIrkd0GbhiTpRHTD5XzLwGV1SHavYAgIN2dB4tJ zGPvanjXcgo1AthBjBdd/EQW+BE8U+prWs7BMdj5CTDVVzG3E20Wsmj8m5jdYB0yYga5 nN/w== X-Gm-Message-State: APjAAAV/WSebnyaPQg6Dbzpp+8HkpC8KGt9ylxVPN1hOSvxraNZZIJub 5cCt4SHIuIXAI0nn7lr27qfSnA8SROdyT6D6b8s= X-Google-Smtp-Source: APXvYqzz0i/kRBXwZEOeWiZ7ZgZjsjv4QcMhg85D4C5F/xgrPFlqD0gVP576BPINhaYDzNFUr7QB3UMQr3e4VjOaJF0= X-Received: by 2002:a92:350a:: with SMTP id c10mr5104034ila.140.1572296437799; Mon, 28 Oct 2019 14:00:37 -0700 (PDT) MIME-Version: 1.0 References: <157201926102.4337.10953843577545450235.idtracker@ietfa.amsl.com> <20191028153150.GY69013@kduck.mit.edu> <4F15E6F7-2DA0-4C90-B891-DDA65917D1A7@kuehlewind.net> In-Reply-To: From: Barry Leiba Date: Mon, 28 Oct 2019 17:00:26 -0400 Message-ID: To: Mike Jones Cc: Mirja Kuehlewind , Benjamin Kaduk , "Roman D. Danyliw" , "ace-chairs@ietf.org" , The IESG , "ace@ietf.org" , "draft-ietf-ace-cwt-proof-of-possession@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Ace] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-ace-cwt-proof-of-possession-09=3A_=28with_COMMENT=29?= 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 Oct 2019 21:00:41 -0000 The issue isn't using a mailing list. The issue is the instructions to IANA about how to do management and tracking, stuff that they do just fine without working groups trying -- will all good intentions -- to tell them how. The fact that there are a lot of RFCs that do it just says that working groups do this frequently, and most ADs don't notice or don't care. And the reality is that IANA will manage the registration process how they do it, accommodating reasonable special instructions when they can. The point is that documents shouldn't be giving special instructions unless there really is something special needed for a particular reason. Barry On Mon, Oct 28, 2019 at 12:19 PM Mike Jones w= rote: > > The practice of using a mailing list for registration requests to enable = public visibility of them goes back at least to .well-known URI registratio= ns https://tools.ietf.org/html/rfc5785 by Mark Nottingham in April 2010. O= Auth 2.0 followed this practice in RFC 6749, as did the JOSE specs and JWT = in RFCs 7515-19. The rest is history, as they say. > > -- Mike > > -----Original Message----- > From: Mirja Kuehlewind > Sent: Monday, October 28, 2019 8:54 AM > To: Benjamin Kaduk > Cc: Barry Leiba ; Roman D. Danyliw ; ace-chairs@ietf.org; The IESG ; ace@ietf.org; draft-ietf-= ace-cwt-proof-of-possession@ietf.org > Subject: Re: [Ace] Mirja K=C3=BChlewind's No Objection on draft-ietf-ace-= cwt-proof-of-possession-09: (with COMMENT) > > These are all quite recents examples, so maybe the procedures are changin= g at the moment. I guess we as the IESG should be aware and figure out what= the right procedure actually should be here. > > > On 28. Oct 2019, at 16:31, Benjamin Kaduk wrote: > > > > On Fri, Oct 25, 2019 at 12:31:42PM -0400, Barry Leiba wrote: > >> Yeh, it's very common for authors to try to tell IANA how to handle > >> registrations, and I often push back on that as inappropriate. There > >> are certainly special conditions that IANA should be told about, but > >> this is standard work-flow management stuff that ought to be left to > >> IANA. I do think it should be changed before this is published, > >> probably just removing that last sentence. > > > > While I'm not opposed to normalizing on a default procedure, I think > > the authors were just trying to follow existing examples. > > > > RFC 7519: > > > > Values are registered on a Specification Required [RFC5226] basis > > after a three-week review period on the jwt-reg-review@ietf.org > > mailing list, on the advice of one or more Designated Experts. > > However, to allow for the allocation of values prior to publication, > > the Designated Experts may approve registration once they are > > satisfied that such a specification will be published. > > > > Registration requests sent to the mailing list for review should use > > an appropriate subject (e.g., "Request to register claim: example"). > > > > Within the review period, the Designated Experts will either approve > > or deny the registration request, communicating this decision to the > > review list and IANA. Denials should include an explanation and, if > > applicable, suggestions as to how to make the request successful. > > Registration requests that are undetermined for a period longer than > > 21 days can be brought to the IESG's attention (using the > > iesg@ietf.org mailing list) for resolution. > > > > RFC 8414: > > > > Values are registered on a Specification Required [RFC8126] basis > > after a two-week review period on the oauth-ext-review@ietf.org > > mailing list, on the advice of one or more Designated Experts. > > However, to allow for the allocation of values prior to publication, > > the Designated Experts may approve registration once they are > > satisfied that such a specification will be published. > > > > Registration requests sent to the mailing list for review should use > > an appropriate subject (e.g., "Request to register OAuth > > Authorization Server Metadata: example"). > > > > Within the review period, the Designated Experts will either approve > > or deny the registration request, communicating this decision to the > > review list and IANA. Denials should include an explanation and, if > > applicable, suggestions as to how to make the request successful. > > Registration requests that are undetermined for a period longer than > > 21 days can be brought to the IESG's attention (using the > > iesg@ietf.org mailing list) for resolution. > > > > RFC 8447: > > > > Specification Required [RFC8126] registry requests are registered > > after a three-week review period on the > > mailing list, on the advice of one or more designated experts. > > However, to allow for the allocation of values prior to publication, > > the designated experts may approve registration once they are > > satisfied that such a specification will be published. > > > > Registration requests sent to the mailing list for review SHOULD use > > an appropriate subject (e.g., "Request to register value in TLS bar > > registry"). > > > > Within the review period, the designated experts will either approve > > or deny the registration request, communicating this decision to the > > review list and IANA. Denials SHOULD include an explanation and, if > > applicable, suggestions as to how to make the request successful. > > Registration requests that are undetermined for a period longer than > > 21 days can be brought to the IESG's attention (using the > > mailing list) for resolution. > > > > [I stopped looking here] > > > > So if we're going to change things around, maybe we should issue an > > IESG statement. > > > > -Ben > > > > > From nobody Mon Oct 28 14:06:19 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D29FF120086; Mon, 28 Oct 2019 14:06:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lak_QtmzVhwr; Mon, 28 Oct 2019 14:06:16 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C3CE120072; Mon, 28 Oct 2019 14:06:16 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x9SL67hW011849 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 28 Oct 2019 17:06:10 -0400 Date: Mon, 28 Oct 2019 14:06:07 -0700 From: Benjamin Kaduk To: Jim Schaad Cc: "'Ludwig Seitz'" , draft-ietf-ace-oauth-authz.all@ietf.org, ace@ietf.org Message-ID: <20191028210607.GI69013@kduck.mit.edu> References: <20190927015154.GY6424@kduck.mit.edu> <696c7ee4-75f9-48ec-8837-ea171137e9f8@ri.se> <024201d583bf$f4a146e0$dde3d4a0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <024201d583bf$f4a146e0$dde3d4a0$@augustcellars.com> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [Ace] AD review of draft-ietf-ace-oauth-authz-24 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 Oct 2019 21:06:19 -0000 I guess I'll be responding to the thread in backwards order, to try and catch any topics that have received later updates... On Tue, Oct 15, 2019 at 06:20:51PM -0700, Jim Schaad wrote: > I have trimmed down to the issues that I wanted to respond to. > > Jim > > > -----Original Message----- > From: Ludwig Seitz > Sent: Tuesday, October 15, 2019 7:08 AM > To: Benjamin Kaduk ; draft-ietf-ace-oauth-authz.all@ietf.org > Cc: ace@ietf.org > Subject: Re: AD review of draft-ietf-ace-oauth-authz-24 > > Hello Ben, > > thank you for your thorough review. > > I have taken the liberty to add numbers to your comments in order to > refer to them in a easier way. > > I have fixed 93 your 113 and there are 20 left where I am asking for > clarifications. These are: > > 6.), 12.), 16.), 19.), 34.), 39.), 41.), 45.), 52.), 57.), 58.), 65.), > 66.), 68.), 76.), 78.), 79.), 88.), 99.), 111.) > > Note that 39.) Requires input from OAuth experts. Hannes? > > If you whish to inspect the changes made on other review issues, please > consult the commits here: > https://github.com/ace-wg/ace-oauth/commits/master > > > Detailed comments below. > > /Ludwig > > > > > Hi all, > > > > The length of this review notwithstanding, this document is generally in > > good shape -- there's a bunch of localized items to tighten up, and we > > can flesh out the security considerations some more, but nothing too > > drastic should be needed. > > > > > > 12.) > > A refresh token in OAuth 2.0 is a string representing the > > authorization granted to the client by the resource owner. The > > string is usually opaque to the client. The token denotes an > > > > Apparently I'd forgotten that this couldn't be binary. > > [LS] From RFC 6749, section 1.5: "A refresh token is a string ..." > No qualifiers such as "binary" so I interpret this to mean a text-string. > Do you want us to add some clarification? > > [JLS] I think we may want to change this at some point in the future, but I don't know how much people are going to use refresh tokens so I don't think I would worry about it. I don't think we need to do anything right now. > > 32.) > > Section 5.6.1 > > > > The client sends a POST request to the token endpoint at the AS. The > > profile MUST specify how the communication is protected. The content > > > > In the previous section we said that maybe even other transports than > > coaps or https would be possible; are we limited to those that have POST > > verbs? > > Also, a similar comment as above about what attributes the protection > > entails seems to apply. > > [LS] This will need a major rephrasing of the text. > I see two options here: > > 1.) We rewrite all parts to use a neutral language in general and specify > POST/GET etc. for transports that have these verbs. > > 2.) We state in the beginning that transports that do not use RESTful verbs > should use the best equivalent. > > Option 1. would get a bit cluncky, while option 2. might be a bit confusing > Do you have a specific preference? > > [JLS] I would suggest that this could fall under the punt to the new transport that does not have the same as these verbs in it to explain how they would map. I agree that (1) is more effort than it's likely to be worth. If we can finagle a single-sentence disclaimer like "transports that do not use these verbs will need to specify the requisite behavior" that would be great; if not, then we can consider whether to just ignore it or do something more complicated. > > 39.) > > Refresh tokens are typically not stored as securely as proof-of- > > possession keys in requesting clients. Proof-of-possession based > > refresh token requests MUST NOT request different proof-of-possession > > keys or different audiences in token requests. Refresh token > > requests can only use to request access tokens bound to the same > > proof-of-possession key and the same audience as access tokens issued > > in the initial token request. > > > > This is perhaps something of a philosophical question, but if a refresh > > token is only usable at the token endpoint, in some sense its audience > > is definitionally the AS. So there's a little bit of a mismatch in > > treating it as having the audience value that the access tokens issued > > from it will have. I don't know the background for audience-restriced > > refresh tokens in regular OAuth 2.0, though, so hopefully someone can > > educate me. > > [LS] I'm equally confused. I suggest that Hannes or one of the other OAuth > experts give us a hint on that one. > > [JLS] My understanding is that the refresh token is completely opaque to anybody but the AS so how it is stored is not as critical. The client then does a normal request with that as a parameter. The refresh token allows for the AS to avoid doing some of the authorization steps and potentially re-use the same key for the new token. As such, the newly requested token needs to headed to the same audience as the original POP token. This is the reason for needing to keep audience with it on the client. I agree with the behavior, yes. It's just interesting/surprising to have something associated with the refresh token that uses the term "audience" but that does not apply to the actual usage of the refresh token. We probably don't need any text changes here, on second look (I note that the text is "same audience as *access* tokens issued in the initial token request). > > 41.) > > token_type: > > This parameter is OPTIONAL, as opposed to 'required' in [RFC6749]. > > By default implementations of this framework SHOULD assume that > > the token_type is "pop". If a specific use case requires another > > token_type (e.g., "Bearer") to be used then this parameter is > > REQUIRED. > > > > When we are "weakening" the formal requirements of the parent spec like > > this, we should be careful about what happens when someone is trying to > > use the ACE stuff but ends up needing to go over HTTPS like traditional > > OAuth -- do they have to fall back to the OAuth required behavior in > > that case or are we trying to preempt that as well? > > [LS] The use case here is a constrained connection between client and AS > (e.g. due to a constrained client), where we try to save the bytes for > sending a token_type by defining a default. I would guess that a HTTPS based > connection would not have such constraints and would therefore be able > to send > the token_type = "pop" as required by RFC6749. Should we explain this > somewhere > and describe the cases where RFC6749 behaviour is warranted? > > [JLS] Given that it would be identified as being application/ace+json, I don't think there is a problem with having the default value. The fact that this is ACE is identifiable from the media-type of the message sent over HTTPS. Okay, you convinced me. > > 52.) > > Section 5.7.4 > > > > "scope" is showing up with the key 9 a lot; I have mixed feelings about > > having the CBOR map key value be aliased across different contexts (but > > it's probably too late to change without disruption anyway). > > [LS] Scope is used in 4 places: > > I. AS Request Creation Hints > II. /token request and response parameter > III. CWT claim > IV. /introspection response parameter > > I claim that in all 4 cases we expect the same content with the same > formatting and semantics: I. tells the client what to put into II. > which in turn informs the AS about the requested claim value in III. > and IV. is supposed to reflect that claim value. I therefore don't feel > hesitant to use the same abbreviation for all four cases. > Is that acceptable or do you whish us to perform any action on this? > > [JLS] I could have wished you said something sooner. I kept trying to argue that there was no need to be consistent on the mapping, but that is how it is. I will note that sections 8.6, 8.9, 8.11 as well as 8.13 are all separate registries for doing the mapping. This means that while today there is consistency across all of the registries, there is no guarantee that this will be true going forward. Sorry for being slow, and agreed on all the rest. It seems unlikely that any gain from changing things now will be worth the pain of churn. -Ben From nobody Mon Oct 28 15:23:26 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 603A912094C; Mon, 28 Oct 2019 15:23:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a6r03Rqx9LZ7; Mon, 28 Oct 2019 15:23:19 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87318120954; Mon, 28 Oct 2019 15:23:18 -0700 (PDT) Received: from Jude (192.168.0.11) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 28 Oct 2019 15:23:10 -0700 From: Jim Schaad To: 'Benjamin Kaduk' , 'Barry Leiba' CC: "'Roman D. Danyliw'" , , =?iso-8859-1?Q?'Mirja_K=FChlewind'?= , 'The IESG' , , References: <157201926102.4337.10953843577545450235.idtracker@ietfa.amsl.com> <20191028153150.GY69013@kduck.mit.edu> In-Reply-To: <20191028153150.GY69013@kduck.mit.edu> Date: Mon, 28 Oct 2019 15:23:08 -0700 Message-ID: <03c101d58dde$48ca6ee0$da5f4ca0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHSr3aKjjHo5bxNQispkJ+fL0GyYgLO31EFAcgbol2nUaVocA== Content-Language: en-us X-Originating-IP: [192.168.0.11] Archived-At: Subject: Re: [Ace] =?iso-8859-1?q?Mirja_K=FChlewind=27s_No_Objection_on_draft?= =?iso-8859-1?q?-ietf-ace-cwt-proof-of-possession-09=3A_=28with_COMMENT=29?= 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 Oct 2019 22:23:25 -0000 Given that the author is the same for RFC 7519, RFC 8414 and this = document, I don't know that this says much. I believe that in part people are = trying to duplicate the behavior of registering media types and perhaps not = doing a good job. Jim -----Original Message----- From: Ace On Behalf Of Benjamin Kaduk Sent: Monday, October 28, 2019 8:32 AM To: Barry Leiba Cc: Roman D. Danyliw ; ace-chairs@ietf.org; Mirja = K=FChlewind ; The IESG ; ace@ietf.org; draft-ietf-ace-cwt-proof-of-possession@ietf.org Subject: Re: [Ace] Mirja K=FChlewind's No Objection on draft-ietf-ace-cwt-proof-of-possession-09: (with COMMENT) On Fri, Oct 25, 2019 at 12:31:42PM -0400, Barry Leiba wrote: > Yeh, it's very common for authors to try to tell IANA how to handle=20 > registrations, and I often push back on that as inappropriate. There=20 > are certainly special conditions that IANA should be told about, but=20 > this is standard work-flow management stuff that ought to be left to=20 > IANA. I do think it should be changed before this is published,=20 > probably just removing that last sentence. While I'm not opposed to normalizing on a default procedure, I think the authors were just trying to follow existing examples. RFC 7519: Values are registered on a Specification Required [RFC5226] basis after a three-week review period on the jwt-reg-review@ietf.org mailing list, on the advice of one or more Designated Experts. However, to allow for the allocation of values prior to publication, the Designated Experts may approve registration once they are satisfied that such a specification will be published. Registration requests sent to the mailing list for review should use an appropriate subject (e.g., "Request to register claim: example"). Within the review period, the Designated Experts will either approve or deny the registration request, communicating this decision to the review list and IANA. Denials should include an explanation and, if applicable, suggestions as to how to make the request successful. Registration requests that are undetermined for a period longer than 21 days can be brought to the IESG's attention (using the iesg@ietf.org mailing list) for resolution. RFC 8414: Values are registered on a Specification Required [RFC8126] basis after a two-week review period on the oauth-ext-review@ietf.org mailing list, on the advice of one or more Designated Experts. However, to allow for the allocation of values prior to publication, the Designated Experts may approve registration once they are satisfied that such a specification will be published. Registration requests sent to the mailing list for review should use an appropriate subject (e.g., "Request to register OAuth Authorization Server Metadata: example"). Within the review period, the Designated Experts will either approve or deny the registration request, communicating this decision to the review list and IANA. Denials should include an explanation and, if applicable, suggestions as to how to make the request successful. Registration requests that are undetermined for a period longer than 21 days can be brought to the IESG's attention (using the iesg@ietf.org mailing list) for resolution. RFC 8447: Specification Required [RFC8126] registry requests are registered after a three-week review period on the mailing list, on the advice of one or more designated experts. However, to allow for the allocation of values prior to publication, the designated experts may approve registration once they are satisfied that such a specification will be published. Registration requests sent to the mailing list for review SHOULD use an appropriate subject (e.g., "Request to register value in TLS bar registry"). Within the review period, the designated experts will either approve or deny the registration request, communicating this decision to the review list and IANA. Denials SHOULD include an explanation and, if applicable, suggestions as to how to make the request successful. Registration requests that are undetermined for a period longer than 21 days can be brought to the IESG's attention (using the mailing list) for resolution. [I stopped looking here] So if we're going to change things around, maybe we should issue an IESG statement. -Ben _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace From nobody Mon Oct 28 23:07:21 2019 Return-Path: X-Original-To: ace@ietf.org Delivered-To: ace@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E12301200B6; Mon, 28 Oct 2019 23:07:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Adam Roach via Datatracker To: "The IESG" Cc: draft-ietf-ace-cwt-proof-of-possession@ietf.org, ace-chairs@ietf.org, rdd@cert.org, ace@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.108.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Adam Roach Message-ID: <157232923891.16185.1675206642162092837.idtracker@ietfa.amsl.com> Date: Mon, 28 Oct 2019 23:07:18 -0700 Archived-At: Subject: [Ace] Adam Roach's No Objection on draft-ietf-ace-cwt-proof-of-possession-09: (with COMMENT) 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 Oct 2019 06:07:19 -0000 Adam Roach has entered the following ballot position for draft-ietf-ace-cwt-proof-of-possession-09: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ace-cwt-proof-of-possession/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for the work everyone put into defining this mechanism. I have one very minor comment that the authors may wish to take into account. §3.3: > /alg/ 3 : /HMAC256//256/ 5, This use of "//" seems problematic, given RFC 8610's vague reservation of this sequence for some kind of "comment to end of line" designation: (There are currently no end-of-line comments. If we want to add them, "//" sounds like a reasonable delimiter given that we already use slashes for comments, but we could also go, for example, for "#".) Given the potential ambiguity introduced by RFC 8610, perhaps consider some other syntax here instead of "//". From nobody Wed Oct 30 05:51: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 07E8C120886; Wed, 30 Oct 2019 05:51:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.635 X-Spam-Level: X-Spam-Status: No, score=0.635 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_LOW=-0.7, RCVD_IN_SBL_CSS=3.335, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=YqiVyDDk; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=SWhRXsAJ 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 OHUm7tpc1GHz; Wed, 30 Oct 2019 05:51:00 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE845120145; Wed, 30 Oct 2019 05:51:00 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id D8C6F21F6D; Wed, 30 Oct 2019 08:50:59 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Wed, 30 Oct 2019 08:50:59 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm1; bh=T 3RQjIV26vpil1s/n/7v43bCBdMCsgSs/E2Tbd5hNzE=; b=YqiVyDDkvNsfagsFO nyxK6VL+T208scTnkcTJv/I6Y9LfnrDFfogqu2oU7hHGILLvkwX8HCIPO/3fFy7V BuzVi0Y0GoBYlwFfZQXr481rbzdQ76HPwi6gHmphh7Ins2hl7OSQca1IdvqxmPIU /3q6Fqg+DsVlz0emLjVNjmtEop2xxTZX/6UA8IYspJLrGq6NHwMSQ6RR9o9AkyoZ 9BIPUgHsDd/NoDYOacUecviLJIwZ7KnJfw88djNjstqOJ63hWglqIGFYlINSsFEP sbEVqeBlV7PnRKgCBRT0Jk9qxIJ9PkJ/0aEpI9zoFjiLR61JLHMA+KHpLd4bGLln e78mA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=T3RQjIV26vpil1s/n/7v43bCBdMCsgSs/E2Tbd5hN zE=; b=SWhRXsAJvqTtPrOH4hIuQ0Qch+ZvxtbfAg9X6pWfQgAaHJUfXFZOlXcq7 TcgKDHVvKjJ8MdmFS9zICIM1QTFn8MTjVjyuFhh7ZZONqTXuNtj9c4J1ddLmN4UA OZ/Tjxl/M9cJM/uCB62KGMcGa0m4J4vCN+X88Ax8MqBFEWp0jNPaxn+lgrMN1J4b fkjdcOHCMZ+zUMeDh3zLEPuokXHWiX1mnLHEjcksfSOxS0Jg/Y0nHFSszd+QppKV rFKDFMYVSD3EHjokCqfbZlfxymBHdve7Kn6PYWPK4jsNvltA4nTENBWFkMR++M+X TPlz5j6MPvojoUWhHkDtW7PXgtT9Q== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedruddtfedggeehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtvdenucfhrhhomheptehlihhs shgrucevohhophgvrhcuoegrlhhishhsrgestghoohhpvghrfidrihhnqeenucffohhmrg hinhepihgvthhfrdhorhhgnecukfhppeduvddrvdehvddrjedrvddvieenucfrrghrrghm pehmrghilhhfrhhomheprghlihhsshgrsegtohhophgvrhifrdhinhenucevlhhushhtvg hrufhiiigvpedt X-ME-Proxy: Received: from [100.68.211.48] (unknown [12.252.7.226]) by mail.messagingengine.com (Postfix) with ESMTPA id EC28180061; Wed, 30 Oct 2019 08:50:58 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Alissa Cooper In-Reply-To: <157202283277.4219.10184234491533744147@ietfa.amsl.com> Date: Wed, 30 Oct 2019 07:50:58 -0500 Cc: gen-art@ietf.org, draft-ietf-ace-cwt-proof-of-possession.all@ietf.org, last-call@ietf.org, ace@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <157202283277.4219.10184234491533744147@ietfa.amsl.com> To: Christer Holmberg X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Ace] [Gen-art] Genart telechat review of draft-ietf-ace-cwt-proof-of-possession-09 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 Oct 2019 12:51:02 -0000 Christer, thanks for your reviews. Mike, thanks for your responses. I = entered a No Objection ballot. Alissa > On Oct 25, 2019, at 12:00 PM, Christer Holmberg via Datatracker = wrote: >=20 > Reviewer: Christer Holmberg > Review result: Ready >=20 > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please wait for direction from your > document shepherd or AD before posting a new version of the draft. >=20 > For more information, please see the FAQ at >=20 > . >=20 > Document: draft-ietf-ace-cwt-proof-of-possession-09 > Reviewer: Christer Holmberg > Review Date: 2019-10-25 > IETF LC End Date: None > IESG Telechat date: 2019-10-31 >=20 > Summary: My comments on the previous version have been addressed, and = the > document is now ready for publication. >=20 > Major issues: N/A >=20 > Minor issues: N/A >=20 > Nits/editorial comments: N/A >=20 >=20 > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art From nobody Wed Oct 30 05:57:39 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45E9512081F; Wed, 30 Oct 2019 05:57:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=risecloud.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SY490PDNLylV; Wed, 30 Oct 2019 05:57:34 -0700 (PDT) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-ve1eur02on0625.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe06::625]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24CD1120812; Wed, 30 Oct 2019 05:57:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=arOE3rHKH0XTwiqO9nr5h08qn8okX8NU3B4e6JXr770PM+/C+v11RStlTvlm46sn3z/f0B/mb3dJu9zLmpySUtuvREC7ArAJoMMEc3R82mSMUyVYHYMvx8vfidoSeqbQekx044Q9JqJ5rNzhSbMrfkz8q2kyz2bH7SYAfV47oNvBOdlx+/3dQgto/K1aLrlLSbfyZ1eNpSxc0qBW5zUDU286Rqm2oUoEFEACQZLNWtkVkAU/GXhhz6t6iWzaq28zwuVe42yesB926kptI2M/n6H5si2EO+VCd0zUQYgxG4cLFGPb8zjwClgrpNwEjeGX3UQ5i4+8ySUEhv7LaMFWhw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=uzlYhk8FzNgFFVTjIQjORjQiYXZRseCbeRbp29sShZY=; b=cqcls//lw4ZXuoCIyillmGvea3FvsZBiXv5BDsXohi4BkB5ioRgkiQE6hJ12ILG6PS/ScJ3hPtKg7M1K0ZF+XmwVItTBtSvCkQDTCVCUnR62vnet2dW/GT651kznlG6JCW/f2y+tlYDpPjKyMWxhos0fd6FsafegkWd5Jxi/bg59WmzMCIZokBZ8Gc/aTYEUZmZ0h6GMA3OaX+L3qQ5BKQE4NqD5ON5zDh+Ag5CYb71BJueLCiT2BhIhLqGGkDWRfRg8kqC4aTZefxt6q1c+a7h+NdveY/CHKbk4d9I/g2DmG1xySWt//OjkVdTaxXAo+VYjzSg+mnUTboLoMNOO0Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 194.218.146.197) smtp.rcpttodomain=ietf.org smtp.mailfrom=ri.se; dmarc=pass (p=none sp=none pct=100) action=none header.from=ri.se; dkim=none (message not signed); arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=RISEcloud.onmicrosoft.com; s=selector1-RISEcloud-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=uzlYhk8FzNgFFVTjIQjORjQiYXZRseCbeRbp29sShZY=; b=KqPtIGArdM8Q07peEDADMxVNI4uYMMG9W8NPerpHWY943QZjbIR1ev8cr/nrNOi+kunXVnUiN5hvFX8cm9XsM+w76l8IGv5AYyhX54VlPhO1ebjKeCOOufHrTEQBlFa3BRiY+IeeXJzZQWCNi1qx9OlmFxgyBBHcSSICIenwmRo= Received: from DB6P18901CA0003.EURP189.PROD.OUTLOOK.COM (2603:10a6:4:16::13) by AM5P189MB0419.EURP189.PROD.OUTLOOK.COM (2603:10a6:206:22::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2387.22; Wed, 30 Oct 2019 12:57:31 +0000 Received: from HE1EUR02FT043.eop-EUR02.prod.protection.outlook.com (2a01:111:f400:7e05::201) by DB6P18901CA0003.outlook.office365.com (2603:10a6:4:16::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2408.18 via Frontend Transport; Wed, 30 Oct 2019 12:57:31 +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=pass 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 HE1EUR02FT043.mail.protection.outlook.com (10.152.11.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.20.2387.20 via Frontend Transport; Wed, 30 Oct 2019 12:57:30 +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.1779.2; Wed, 30 Oct 2019 13:57:30 +0100 To: Benjamin Kaduk , Jim Schaad CC: , References: <20190927015154.GY6424@kduck.mit.edu> <696c7ee4-75f9-48ec-8837-ea171137e9f8@ri.se> <024201d583bf$f4a146e0$dde3d4a0$@augustcellars.com> <20191028210607.GI69013@kduck.mit.edu> From: Ludwig Seitz Message-ID: Date: Wed, 30 Oct 2019 13:57:29 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <20191028210607.GI69013@kduck.mit.edu> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms030702010909010408050902" X-Originating-IP: [10.100.0.158] X-ClientProxiedBy: sp-mail-3.sp.se (10.100.0.163) To sp-mail-2.sp.se (10.100.0.162) X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:194.218.146.197; IPV:NLI; CTRY:SE; EFV:NLI; SFV:NSPM; SFS:(10009020)(4636009)(396003)(376002)(346002)(39860400002)(136003)(189003)(199004)(22756006)(8676002)(22746008)(65806001)(5660300002)(33964004)(476003)(26005)(110136005)(58126008)(486006)(235185007)(86362001)(54906003)(53546011)(568964002)(386003)(81156014)(81166006)(356004)(2906002)(65956001)(40036005)(3846002)(31696002)(8936002)(70586007)(70206006)(229853002)(5024004)(14444005)(446003)(11346002)(336012)(126002)(71190400001)(4326008)(106002)(2616005)(7736002)(316002)(305945005)(6116002)(36756003)(478600001)(16576012)(186003)(16526019)(31686004)(76176011)(16586007)(44832011)(2171002)(6246003); DIR:OUT; SFP:1101; SCL:1; SRVR:AM5P189MB0419; H:mail.ri.se; FPR:; SPF:Pass; LANG:en; PTR:InfoDomainNonexistent; MX:1; A:1; X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 8cff0a1f-1285-4aa2-9301-08d75d38b9a4 X-MS-TrafficTypeDiagnostic: AM5P189MB0419: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:9508; X-Forefront-PRVS: 02065A9E77 X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: Eo4LxvqZFzqrhnxQfwXnXPauQtQ4wOnDWGv7Xhma95mmcCEBLTknYhbbpBY1ja9Yv/ytqxG7Ywqh/8CgQ9vp9vuC2NKcph10xDuey94ADWv7c1fV8BolTwJFiIwxD/4k2X+csrmFZuorX1SZkF1aCAg+Mu7Fsa1fJuvibFg5qxklY76my1fDvFmtyv9MDqE4N62yVxkqqlFvh3TOVszPGsjrICoAlUlMxT285+We6J3/sOEMdkKQdAgXCpo4MmC/E72ybmYdYBuWhk4Rmtlt2dKT8GeM8IJL5CPDsRBffx7GhtBqFuKuKoOah23KXks4VpKEEU+6s83U4nMi0K7sby6CurWmdm9VF5Y25PDF9ZcU53dtz6D7mMf0btAiMbd+VnhlY2whUyu0GElnETrWz/wB4sZbprHXFyVPzDo1U69WlIjFIOlpuBh6Gsmwlu5a X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Oct 2019 12:57:30.9786 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 8cff0a1f-1285-4aa2-9301-08d75d38b9a4 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: AM5P189MB0419 Archived-At: Subject: Re: [Ace] AD review of draft-ietf-ace-oauth-authz-24 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 Oct 2019 12:57:37 -0000 --------------ms030702010909010408050902 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 28/10/2019 22:06, Benjamin Kaduk wrote: >>> 32.) >>> Section 5.6.1 >>> >>> The client sends a POST request to the token endpoint at the AS. = The >>> profile MUST specify how the communication is protected. The con= tent >>> >>> In the previous section we said that maybe even other transports than= >>> coaps or https would be possible; are we limited to those that have P= OST >>> verbs? >>> Also, a similar comment as above about what attributes the protection= >>> entails seems to apply. >> >> [LS] This will need a major rephrasing of the text. >> I see two options here: >> >> 1.) We rewrite all parts to use a neutral language in general and spec= ify >> POST/GET etc. for transports that have these verbs. >> >> 2.) We state in the beginning that transports that do not use RESTful = verbs >> should use the best equivalent. >> >> Option 1. would get a bit cluncky, while option 2. might be a bit conf= using >> Do you have a specific preference? >> >> [JLS] I would suggest that this could fall under the punt to the new t= ransport that does not have the same as these verbs in it to explain how = they would map. >=20 > I agree that (1) is more effort than it's likely to be worth. If we ca= n > finagle a single-sentence disclaimer like "transports that do not use t= hese > verbs will need to specify the requisite behavior" that would be great;= if > not, then we can consider whether to just ignore it or do something mor= e > complicated. I'll go for this: " Note that this document specifies protocol exchanges in terms of RESTful commands such as GET and POST. Future profiles using protocols that do not support these verbs MUST specify how the corresponding protocol messages are transmitted instea= d. " In the Overview section where we mention alternate transport protocols. /Ludwig --=20 Ludwig Seitz, PhD Security Lab, RISE Phone +46(0)70-349 92 51 --------------ms030702010909010408050902 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DT0wggYWMIID/qADAgECAg8BaKlzCTJTye3phLaz/cIwDQYJKoZIhvcNAQELBQAwRzELMAkG A1UEBhMCU0UxFDASBgNVBAoMC1RlbGlhU29uZXJhMSIwIAYDVQQDDBlUZWxpYVNvbmVyYSBD bGFzcyAyIENBIHYyMB4XDTE5MDIwMTE0MjUxNVoXDTIxMDIwMTE0MjUxNFowgYsxCzAJBgNV BAYTAlNFMS4wLAYDVQQKDCVSSVNFIFJlc2VhcmNoIEluc3RpdHV0ZXMgb2YgU3dlZGVuIEFC MRUwEwYDVQQDDAxMdWR3aWcgU2VpdHoxEjAQBgNVBAUTCUx1ZHdpZ1NlaTEhMB8GCSqGSIb3 DQEJARYSbHVkd2lnLnNlaXR6QHJpLnNlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAlJNmRfcsto5I/yXrBIi9QroZtfAMttc1Eznv5iPCK++eFUArODhITO7k9rtlQX5D8vYF v4vzZex58YWZhvGMzDj9FdpD/PHKOxL/frlrreChuissPWo5M88DmL3V1oyGzvgeRqaafpEi 0/2+gezMFlABm/BXj3/0Fiw5Sxub7essE27EtDK05nAbUB69kfLHBEytbTAuuSb11hC1dpTf itMZkzSFwsBCyPtIv3GRt9xgnOPK4RRpHidv1GLYXNQQ7xEGhFy4qbZ2NSfM+56SSRswvW9P 5n81ZmZ4FWkiJouUIYtZ2ifncBJL4DC2chjsywDEz5No7kYrGxc5oOm1YQIDAQABo4IBuDCC AbQwHwYDVR0jBBgwFoAUnhn/5Q06/gCXFT9p8dxaPKoMlIMwHQYDVR0OBBYEFKZHZ8MZNNP5 tXMPjeFiw01pUWbtMA4GA1UdDwEB/wQEAwIFoDBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEB DDA6MDgGCCsGAQUFBwIBFixodHRwczovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEu Y29tL0NQUzAdBgNVHREEFjAUgRJsdWR3aWcuc2VpdHpAcmkuc2UwTQYDVR0fBEYwRDBCoECg PoY8aHR0cDovL2NybC0yLnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYWNsYXNz MmNhdjIuY3JsMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjB+BggrBgEFBQcBAQRy MHAwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnRydXN0LnRlbGlhLmNvbTBFBggrBgEFBQcw AoY5aHR0cDovL2NhLnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYWNsYXNzMmNh djIuY2VyMA0GCSqGSIb3DQEBCwUAA4ICAQCk0GOalOCjEJObuBeMg0QREtBP/2ona16npn+T v5R3Vjk5UsQdOaOosgVjADX68C83dyfPiWR4UfNJoTBcM8JLpEXIm+xC4BiDPTPHYvgkhgXt 9VWCRWXOMfT/UPXjiGsbPuNWja1LQzF5KOmM826kHVZItHuDY6kJLE4OZ+apFvVKtSLQJJLA 4MlDVwp5+XsZi4cftcX5HdgLdChodUPKq3XVfALfXM/p81XEFBTYOHNplr3cQytDQjsnCZnS Ic4UpsxrArNxDO9+AKu/s1Fbq494AhHj4oHcg4DIjhHUzbPCLP19Gqp4dflr/V7Ulg3d+4Zh bmSAn1cffrzvvkjVrqMgQOoHQTl2QyO9n/oJ/9CSYRmhFsQMPun9LM/p5l58dTZp53B3LgA6 FFrxnntlZnTPh3bvsMJvUQ+AoiXyQwnkdxUrhoM+gUz36t3JSA8g48h7BhPsnwQ/YrarAhJ8 ifuzykTQmDseWLjJKyFflddy/azAlPQjgSMMWOZCo2s+l+WwPISf33nls2Aec/vvG5auYHS6 pwWuVKuwZTPgJfHanZTNpBM5y0jVBz6tr8AHZypnCONgyUYA4uec3v5oWz4FvLEnlKnMGoK3 OeFGvfHG0tbP25HbdN3AJYP0EUo56wfkBOYsnmn4mEYdk2GHkJNfaQRBJljH0T7TOcmcDjCC Bx8wggUHoAMCAQICEGN8C9eFpb8p2mAtfE16cLEwDQYJKoZIhvcNAQELBQAwNzEUMBIGA1UE CgwLVGVsaWFTb25lcmExHzAdBgNVBAMMFlRlbGlhU29uZXJhIFJvb3QgQ0EgdjEwHhcNMTQx MDE2MDgzOTMwWhcNMzIxMDE2MDUwNDAwWjBHMQswCQYDVQQGEwJTRTEUMBIGA1UECgwLVGVs aWFTb25lcmExIjAgBgNVBAMMGVRlbGlhU29uZXJhIENsYXNzIDIgQ0EgdjIwggIiMA0GCSqG SIb3DQEBAQUAA4ICDwAwggIKAoICAQC0PpW2qcWGnStqfa5DjrUi79Kz2SySUlJ1kiEQ1Pd/ LWbnsEwFYPqOJwAf6ZtEDtQ/9Z1VkVNQ6MkD++keqk7648x0YANgMyiJsWrbd0TKOObtlXdJ pb5qesJ5nOAdVeL3z6lgrkZx+fsUfTV+lLRGRh2+RWzZTjPAvKotY3nAwXCHtwI5v3FKuR10 aJ9+CEOka02KSUzGjcGZwMk2io0DxLELf1gPRvqE9xmn4ioXLqpluozb4Fo9ewydufTLQc3/ I63uPQh8BlLPPIGzWb4iBDq2zbWlbx0KlH/UlUZ7fjzp6N6cAqZ2NnDaCOnnIRfUYeNXFG8/ aiBeFOpEeEpclr5QUwr9HLKL1QiyQtc/wW8acQFoKuGi8myiAch7k7S0rmU5gT05je+OTzWh Oaw7gmDdndYY1mjkPkzpQ+hxyfnwUsAitUq9j0imFOLxKWLH4QNbyuDIMvDyezzJWzMy3XPB LiLSH9CBLVQHRoQ+WW8xD4rnmvQtoGZM72og2iNf4/JCHL1AJYhQtaRjYgm3rhvAP0HhSVAB Z5aHM52ylJHC3JwUyuFm8S9A2ffY9rUTffMLWmDCnX0QAP9bKr6+ACogm4DBUj3ftYodI2TD 6F8+VjSFuCzGDPuCjK+fQ2c3wqziwFl+NgoGI9Vgc6x5+0ocKkiQAIYFaQ3SyGmI6QIDAQAB o4ICFTCCAhEwgYoGCCsGAQUFBwEBBH4wfDAtBggrBgEFBQcwAYYhaHR0cDovL29jc3AudHJ1 c3QudGVsaWFzb25lcmEuY29tMEsGCCsGAQUFBzAChj9odHRwOi8vcmVwb3NpdG9yeS50cnVz dC50ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5jZXIwEgYDVR0TAQH/BAgw BgEB/wIBADBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEBAjA6MDgGCCsGAQUFBwIBFixodHRw czovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQUzAOBgNVHQ8BAf8EBAMC AQYwgcYGA1UdHwSBvjCBuzBAoD6gPIY6aHR0cDovL2NybC0zLnRydXN0LnRlbGlhc29uZXJh LmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNybDB3oHWgc4ZxbGRhcDovL2NybC0xLnRydXN0 LnRlbGlhc29uZXJhLmNvbS9jbj1UZWxpYVNvbmVyYSUyMFJvb3QlMjBDQSUyMHYxLG89VGVs aWFTb25lcmE/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnkwHQYDVR0OBBYEFJ4Z /+UNOv4AlxU/afHcWjyqDJSDMB8GA1UdIwQYMBaAFPCPWTgAs/WPmpYM1ev6e6oX6BMSMA0G CSqGSIb3DQEBCwUAA4ICAQB5wuZFNXR5ko9cu7PcpIyH8xaoGfpimP2GTg7qVuL92D/idIlj pqMm93WC9mgL/Uy6DExoF8xSLurLaiajoU+VG6ZWg0F7P1AXARNt0RpWI5SphxBQYM2751S8 vC/22k8Vi+qpQVIREqQPVXCIEH7U6eCY9gEVzdq9l1yPoI8n0D2a8V6GCv0RVkmIpa16rNYD tTw4j3Ha56/Ua33C3qeZh1dIfkaU2h4CGHd2Em3v5LLMsEh8dqUeG9yIcCU+8RUgDahNxWMe MGxzrhwk8WBV6xeoQp20p7cSHbSbyHJURC1n+nVrgdh8hbw6WOgFhNA5tCPDZ0oSF+uHfj+b ioZE3AlYdcEqHJA9A9sO58F4/Qg/yp9oYuT0ZpKb4hmzeqDXvk5KRFNfHlhTt35i+qmas9wB 11MXbYd5WwqEhZH6HWO5H7XKJP7olxmEC0W3OKlpKafq1iPsBN5ycRfUrXFss0Ax6vpCq0XA 3LYePpQ44hOU+qrkR1M0a7Eo3++3TpP4cV+FZiO4aZYZ3yZftSRHwWpGiDBdWOdTKR2GJi7Z z/OxacrmwmM1Z+WcigldbG8f3IMnOLK4X0uXjhVeAHrhuttQuM8i+4TNXgsZbmfEKNDQIQPO /lbacsGHWFB/U2y6SXVEkZs2xIciRA0iZNTv7mbIL8SZmf5wpbjDCYHiCjGCAzgwggM0AgEB MFowRzELMAkGA1UEBhMCU0UxFDASBgNVBAoMC1RlbGlhU29uZXJhMSIwIAYDVQQDDBlUZWxp YVNvbmVyYSBDbGFzcyAyIENBIHYyAg8BaKlzCTJTye3phLaz/cIwDQYJYIZIAWUDBAIBBQCg ggGvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE5MTAzMDEy NTczMFowLwYJKoZIhvcNAQkEMSIEIHjMZYFz7CXx9FTFJ2yL70fuCWRznPE56ANGtvMAtXD3 MGkGCSsGAQQBgjcQBDFcMFowRzELMAkGA1UEBhMCU0UxFDASBgNVBAoMC1RlbGlhU29uZXJh MSIwIAYDVQQDDBlUZWxpYVNvbmVyYSBDbGFzcyAyIENBIHYyAg8BaKlzCTJTye3phLaz/cIw awYLKoZIhvcNAQkQAgsxXKBaMEcxCzAJBgNVBAYTAlNFMRQwEgYDVQQKDAtUZWxpYVNvbmVy YTEiMCAGA1UEAwwZVGVsaWFTb25lcmEgQ2xhc3MgMiBDQSB2MgIPAWipcwkyU8nt6YS2s/3C MGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0D BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwIC ASgwDQYJKoZIhvcNAQEBBQAEggEAGQLAU5fSEj2zNdHLohm4+xkMzfpcj7vzHp3uv+Ke1J9O KzMKmuo3xGfiPI9GKI7StX4iLGQj28YJW+BjmaIdW9DbbbCqBiJSP++zCwE0ZU7uPcyAmMES ibboKffZWu1BWlylPIKbGpKb8leKb46C/ISubStB1bETgX3oUjXHHs4G36Fba/9Vp+hKPdXD 8SO2mbrBGt3wrdi1q6lAAKWs5W0itewS7jRe5mDwPZHzlb/a8xIMxaGPXpOLNl7VKO9hyYEw rAU9RbBVwaz1h5ucVLU6vdrphsy+wFOPJYPPM2zUllbbU3YL9qhGliCDo6/SgHpK8q3eUDr4 CWJkuLUEiQAAAAAAAA== --------------ms030702010909010408050902-- From nobody Wed Oct 30 06:15:18 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 3A2DA120A19; Wed, 30 Oct 2019 06:15:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ace@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.108.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ace@ietf.org Message-ID: <157244131013.32490.2136229818339803581@ietfa.amsl.com> Date: Wed, 30 Oct 2019 06:15:10 -0700 Archived-At: Subject: [Ace] I-D Action: draft-ietf-ace-oauth-authz-25.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 Oct 2019 13:15:16 -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-25.txt Pages : 86 Date : 2019-10-30 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 transforming a well-known and widely used authorization solution into a form suitable for IoT devices. Existing specifications are used where possible, but extensions are added and profiles are defined to better serve the IoT use cases. 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-25 https://datatracker.ietf.org/doc/html/draft-ietf-ace-oauth-authz-25 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-oauth-authz-25 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 Oct 30 06:17:29 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 742B112013C for ; Wed, 30 Oct 2019 06:17:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 VQ2jRxTwET7D for ; Wed, 30 Oct 2019 06:17:25 -0700 (PDT) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70047.outbound.protection.outlook.com [40.107.7.47]) (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 0F12512006F for ; Wed, 30 Oct 2019 06:17:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=cEZyM4XDLeFPI9v9oNivbahxlEqeianiQTwPAtoZ/Rn/E+NBF51f6NSBMleht2l28qIjUAItAXuhGtw1PEs4snQoj8tAr2K1E2Ls2X8W8MGJdhboSgOLDa8KoTR+xclrGkP7WSgYyk0cWknblVar60TpOsNKdabk5u6/twtUR+YE/Q30MUULFW77oCfEx7idl8Wt0Fuf3uwLmfqjkyV7eR/6+ptdnQDrf5N3bGj13HyeDP37xB8KMTmHCfaasrxdzyEeVJOlMkPt5WpFxT7HjuObA/fcyEyKMyDENnMalE4itoFO2T6pzWoTBZxwxCGomL8o6mi83LAeqIT/wW6Uvw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Mat9MuTYhwjWI7onAd2DuaDRHshtuw+2G7OgWASCL3w=; b=S9+6+GHro/LKE6CAnbifnKFhn9s9Gzqi1puBsiyeBA7A7rFpBiHWa3+Hk9QSV8Pz70b4S9Bx22fNQjmAnti1oWEFeQzqNZCDpenFHR8TKM90ri3i6sLxMcbr6SuFBCuLgy8F12HeqKTQzdtKdK2adIc1ElQvBMPpgVqMLmfNUFUDPCVO6wOOjSEpeSWkydjGcyJM6wa28LatyJsYfvLGztvdpqG0efv3X09dEja/0IJDMD8GD9ArDE15qEamy/JvrkqabU+d2jnfLT417+BACxNhMuWMS62oH5iJ7H+JycApeH3UccZ/YdUVC8waYF9wey1sVab2jDVJYhEbCtG+Nw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 194.218.146.197) smtp.rcpttodomain=ietf.org smtp.mailfrom=ri.se; dmarc=pass (p=none sp=none pct=100) action=none header.from=ri.se; dkim=none (message not signed); arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=RISEcloud.onmicrosoft.com; s=selector1-RISEcloud-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Mat9MuTYhwjWI7onAd2DuaDRHshtuw+2G7OgWASCL3w=; b=RMIIryzEWwwjZ+8WVTDQJi5MENTy8zTSSvCdpWwMvBuRh8M1fCt2IGUitpRsQ4yqte4L7nK0xWaQ/zimfGUZtFZpNAOdWgYRyH8bmiK3VVDYICVzrqVz+f8TuesCau7XXTYu8M21La9a3rcsMi08kQ9ymUrTX54DLkhxVhZzSHk= Received: from VI1P18901CA0012.EURP189.PROD.OUTLOOK.COM (2603:10a6:801::22) by VI1P18901MB0128.EURP189.PROD.OUTLOOK.COM (2603:10a6:801:f::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2387.24; Wed, 30 Oct 2019 13:17:21 +0000 Received: from AM5EUR02FT038.eop-EUR02.prod.protection.outlook.com (2a01:111:f400:7e1e::206) by VI1P18901CA0012.outlook.office365.com (2603:10a6:801::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.2387.22 via Frontend Transport; Wed, 30 Oct 2019 13:17:21 +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=pass 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 AM5EUR02FT038.mail.protection.outlook.com (10.152.9.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.20.2387.20 via Frontend Transport; Wed, 30 Oct 2019 13:17:21 +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.1779.2; Wed, 30 Oct 2019 14:17:20 +0100 References: <157244131047.32490.15340406368597565792.idtracker@ietfa.amsl.com> To: "ace@ietf.org" From: Ludwig Seitz X-Forwarded-Message-Id: <157244131047.32490.15340406368597565792.idtracker@ietfa.amsl.com> Message-ID: <2a52a924-cb14-1899-7b5a-8b85b2cf00b0@ri.se> Date: Wed, 30 Oct 2019 14:17:20 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <157244131047.32490.15340406368597565792.idtracker@ietfa.amsl.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms060808060902020807090004" X-Originating-IP: [10.100.0.158] X-ClientProxiedBy: sp-mail-3.sp.se (10.100.0.163) To sp-mail-2.sp.se (10.100.0.162) X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:194.218.146.197; IPV:NLI; CTRY:SE; EFV:NLI; SFV:NSPM; SFS:(10009020)(4636009)(199004)(189003)(498600001)(58126008)(16586007)(2351001)(6116002)(71190400001)(5640700003)(16576012)(2501003)(229853002)(2906002)(568964002)(106002)(3846002)(44832011)(22756006)(70586007)(70206006)(40036005)(356004)(966005)(4001150100001)(15650500001)(26005)(6916009)(11346002)(81156014)(1730700003)(336012)(386003)(186003)(2616005)(65956001)(65806001)(8676002)(81166006)(31696002)(33964004)(14444005)(7736002)(5024004)(305945005)(126002)(31686004)(76176011)(8936002)(476003)(446003)(5660300002)(235185007)(2473003)(86362001)(486006)(6306002)(36756003)(22746008)(66574012)(16526019); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1P18901MB0128; H:mail.ri.se; FPR:; SPF:Pass; LANG:en; PTR:InfoDomainNonexistent; A:1; MX:1; X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: a25881cc-e298-4ca2-0375-08d75d3b7f20 X-MS-TrafficTypeDiagnostic: VI1P18901MB0128: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:8273; X-Forefront-PRVS: 02065A9E77 X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: NwvQhCLWoAYCGujBv2IKpbTpozzbasqad2tC3T06nOrUTlOd6zJLxMllmvcfG7LwNHJ1TIvbS2HEQrr1V1ikLrAuck6fUIReK+xAUoQ8cbEZkjentAS343+bbs4IDzgXJyelp+RHEpIiJH8eMktGMM2Zv5+kL0zV8sFSBMSbp4Cd1DM2rXzD8+LBIGnmgYFa4d3qIk7TllmiemAEPmI0YPCWDSRgKhiAdV1aFZG76IsL5X613GfHCjDMxVqoTdrvPfJpIRPt+UehoANVdL51fPZONnaGbbiv1MrkEghMwXYaHUBm4QzcCucVoM3QHRc1+MTkx0R+LBFFJZmPYsT29QAp09EO1PZereCs0bfkhHV8OFEkUUOys3piD27Khs358QdZcC6IYLZQ49lmFjIaJCNzLGdnKelR3taSljkwGHO4EsM9/LJfxLdmaSYayfpu X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Oct 2019 13:17:21.2752 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: a25881cc-e298-4ca2-0375-08d75d3b7f20 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: VI1P18901MB0128 Archived-At: Subject: [Ace] Fwd: New Version Notification for draft-ietf-ace-oauth-authz-25.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, 30 Oct 2019 13:17:27 -0000 --------------ms060808060902020807090004 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable Hello ACE, this update of draft-ietf-ace-oauth-authz addresses the review comments=20 made by Ben Kaduk. Regards, Ludwig -------- Forwarded Message -------- Subject: New Version Notification for draft-ietf-ace-oauth-authz-25.txt Date: Wed, 30 Oct 2019 06:15:10 -0700 From: internet-drafts@ietf.org To: Ludwig Seitz , Hannes Tschofenig=20 , Goeran Selander=20 , Samuel Erdtman ,=20 Erik Wahlstroem A new version of I-D, draft-ietf-ace-oauth-authz-25.txt has been successfully submitted by Ludwig Seitz and posted to the IETF repository. Name: draft-ietf-ace-oauth-authz Revision: 25 Title: Authentication and Authorization for Constrained Environments=20 (ACE) using the OAuth 2.0 Framework (ACE-OAuth) Document date: 2019-10-30 Group: ace Pages: 86 URL:=20 https://www.ietf.org/internet-drafts/draft-ietf-ace-oauth-authz-25.txt Status: https://datatracker.ietf.org/doc/draft-ietf-ace-oauth-aut= hz/ Htmlized: https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-25= Htmlized:=20 https://datatracker.ietf.org/doc/html/draft-ietf-ace-oauth-authz Diff:=20 https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ace-oauth-authz-25 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 transforming a well-known and widely used authorization solution into a form suitable for IoT devices. Existing specifications are used where possible, but extensions are added and profiles are defined to better serve the IoT use cases. =20 Please note that it may take a couple of minutes from the time of submiss= ion until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --------------ms060808060902020807090004 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DT0wggYWMIID/qADAgECAg8BaKlzCTJTye3phLaz/cIwDQYJKoZIhvcNAQELBQAwRzELMAkG A1UEBhMCU0UxFDASBgNVBAoMC1RlbGlhU29uZXJhMSIwIAYDVQQDDBlUZWxpYVNvbmVyYSBD bGFzcyAyIENBIHYyMB4XDTE5MDIwMTE0MjUxNVoXDTIxMDIwMTE0MjUxNFowgYsxCzAJBgNV BAYTAlNFMS4wLAYDVQQKDCVSSVNFIFJlc2VhcmNoIEluc3RpdHV0ZXMgb2YgU3dlZGVuIEFC MRUwEwYDVQQDDAxMdWR3aWcgU2VpdHoxEjAQBgNVBAUTCUx1ZHdpZ1NlaTEhMB8GCSqGSIb3 DQEJARYSbHVkd2lnLnNlaXR6QHJpLnNlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAlJNmRfcsto5I/yXrBIi9QroZtfAMttc1Eznv5iPCK++eFUArODhITO7k9rtlQX5D8vYF v4vzZex58YWZhvGMzDj9FdpD/PHKOxL/frlrreChuissPWo5M88DmL3V1oyGzvgeRqaafpEi 0/2+gezMFlABm/BXj3/0Fiw5Sxub7essE27EtDK05nAbUB69kfLHBEytbTAuuSb11hC1dpTf itMZkzSFwsBCyPtIv3GRt9xgnOPK4RRpHidv1GLYXNQQ7xEGhFy4qbZ2NSfM+56SSRswvW9P 5n81ZmZ4FWkiJouUIYtZ2ifncBJL4DC2chjsywDEz5No7kYrGxc5oOm1YQIDAQABo4IBuDCC AbQwHwYDVR0jBBgwFoAUnhn/5Q06/gCXFT9p8dxaPKoMlIMwHQYDVR0OBBYEFKZHZ8MZNNP5 tXMPjeFiw01pUWbtMA4GA1UdDwEB/wQEAwIFoDBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEB DDA6MDgGCCsGAQUFBwIBFixodHRwczovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEu Y29tL0NQUzAdBgNVHREEFjAUgRJsdWR3aWcuc2VpdHpAcmkuc2UwTQYDVR0fBEYwRDBCoECg PoY8aHR0cDovL2NybC0yLnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYWNsYXNz MmNhdjIuY3JsMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjB+BggrBgEFBQcBAQRy MHAwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnRydXN0LnRlbGlhLmNvbTBFBggrBgEFBQcw AoY5aHR0cDovL2NhLnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYWNsYXNzMmNh djIuY2VyMA0GCSqGSIb3DQEBCwUAA4ICAQCk0GOalOCjEJObuBeMg0QREtBP/2ona16npn+T v5R3Vjk5UsQdOaOosgVjADX68C83dyfPiWR4UfNJoTBcM8JLpEXIm+xC4BiDPTPHYvgkhgXt 9VWCRWXOMfT/UPXjiGsbPuNWja1LQzF5KOmM826kHVZItHuDY6kJLE4OZ+apFvVKtSLQJJLA 4MlDVwp5+XsZi4cftcX5HdgLdChodUPKq3XVfALfXM/p81XEFBTYOHNplr3cQytDQjsnCZnS Ic4UpsxrArNxDO9+AKu/s1Fbq494AhHj4oHcg4DIjhHUzbPCLP19Gqp4dflr/V7Ulg3d+4Zh bmSAn1cffrzvvkjVrqMgQOoHQTl2QyO9n/oJ/9CSYRmhFsQMPun9LM/p5l58dTZp53B3LgA6 FFrxnntlZnTPh3bvsMJvUQ+AoiXyQwnkdxUrhoM+gUz36t3JSA8g48h7BhPsnwQ/YrarAhJ8 ifuzykTQmDseWLjJKyFflddy/azAlPQjgSMMWOZCo2s+l+WwPISf33nls2Aec/vvG5auYHS6 pwWuVKuwZTPgJfHanZTNpBM5y0jVBz6tr8AHZypnCONgyUYA4uec3v5oWz4FvLEnlKnMGoK3 OeFGvfHG0tbP25HbdN3AJYP0EUo56wfkBOYsnmn4mEYdk2GHkJNfaQRBJljH0T7TOcmcDjCC Bx8wggUHoAMCAQICEGN8C9eFpb8p2mAtfE16cLEwDQYJKoZIhvcNAQELBQAwNzEUMBIGA1UE CgwLVGVsaWFTb25lcmExHzAdBgNVBAMMFlRlbGlhU29uZXJhIFJvb3QgQ0EgdjEwHhcNMTQx MDE2MDgzOTMwWhcNMzIxMDE2MDUwNDAwWjBHMQswCQYDVQQGEwJTRTEUMBIGA1UECgwLVGVs aWFTb25lcmExIjAgBgNVBAMMGVRlbGlhU29uZXJhIENsYXNzIDIgQ0EgdjIwggIiMA0GCSqG SIb3DQEBAQUAA4ICDwAwggIKAoICAQC0PpW2qcWGnStqfa5DjrUi79Kz2SySUlJ1kiEQ1Pd/ LWbnsEwFYPqOJwAf6ZtEDtQ/9Z1VkVNQ6MkD++keqk7648x0YANgMyiJsWrbd0TKOObtlXdJ pb5qesJ5nOAdVeL3z6lgrkZx+fsUfTV+lLRGRh2+RWzZTjPAvKotY3nAwXCHtwI5v3FKuR10 aJ9+CEOka02KSUzGjcGZwMk2io0DxLELf1gPRvqE9xmn4ioXLqpluozb4Fo9ewydufTLQc3/ I63uPQh8BlLPPIGzWb4iBDq2zbWlbx0KlH/UlUZ7fjzp6N6cAqZ2NnDaCOnnIRfUYeNXFG8/ aiBeFOpEeEpclr5QUwr9HLKL1QiyQtc/wW8acQFoKuGi8myiAch7k7S0rmU5gT05je+OTzWh Oaw7gmDdndYY1mjkPkzpQ+hxyfnwUsAitUq9j0imFOLxKWLH4QNbyuDIMvDyezzJWzMy3XPB LiLSH9CBLVQHRoQ+WW8xD4rnmvQtoGZM72og2iNf4/JCHL1AJYhQtaRjYgm3rhvAP0HhSVAB Z5aHM52ylJHC3JwUyuFm8S9A2ffY9rUTffMLWmDCnX0QAP9bKr6+ACogm4DBUj3ftYodI2TD 6F8+VjSFuCzGDPuCjK+fQ2c3wqziwFl+NgoGI9Vgc6x5+0ocKkiQAIYFaQ3SyGmI6QIDAQAB o4ICFTCCAhEwgYoGCCsGAQUFBwEBBH4wfDAtBggrBgEFBQcwAYYhaHR0cDovL29jc3AudHJ1 c3QudGVsaWFzb25lcmEuY29tMEsGCCsGAQUFBzAChj9odHRwOi8vcmVwb3NpdG9yeS50cnVz dC50ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5jZXIwEgYDVR0TAQH/BAgw BgEB/wIBADBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEBAjA6MDgGCCsGAQUFBwIBFixodHRw czovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQUzAOBgNVHQ8BAf8EBAMC AQYwgcYGA1UdHwSBvjCBuzBAoD6gPIY6aHR0cDovL2NybC0zLnRydXN0LnRlbGlhc29uZXJh LmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNybDB3oHWgc4ZxbGRhcDovL2NybC0xLnRydXN0 LnRlbGlhc29uZXJhLmNvbS9jbj1UZWxpYVNvbmVyYSUyMFJvb3QlMjBDQSUyMHYxLG89VGVs aWFTb25lcmE/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnkwHQYDVR0OBBYEFJ4Z /+UNOv4AlxU/afHcWjyqDJSDMB8GA1UdIwQYMBaAFPCPWTgAs/WPmpYM1ev6e6oX6BMSMA0G CSqGSIb3DQEBCwUAA4ICAQB5wuZFNXR5ko9cu7PcpIyH8xaoGfpimP2GTg7qVuL92D/idIlj pqMm93WC9mgL/Uy6DExoF8xSLurLaiajoU+VG6ZWg0F7P1AXARNt0RpWI5SphxBQYM2751S8 vC/22k8Vi+qpQVIREqQPVXCIEH7U6eCY9gEVzdq9l1yPoI8n0D2a8V6GCv0RVkmIpa16rNYD tTw4j3Ha56/Ua33C3qeZh1dIfkaU2h4CGHd2Em3v5LLMsEh8dqUeG9yIcCU+8RUgDahNxWMe MGxzrhwk8WBV6xeoQp20p7cSHbSbyHJURC1n+nVrgdh8hbw6WOgFhNA5tCPDZ0oSF+uHfj+b ioZE3AlYdcEqHJA9A9sO58F4/Qg/yp9oYuT0ZpKb4hmzeqDXvk5KRFNfHlhTt35i+qmas9wB 11MXbYd5WwqEhZH6HWO5H7XKJP7olxmEC0W3OKlpKafq1iPsBN5ycRfUrXFss0Ax6vpCq0XA 3LYePpQ44hOU+qrkR1M0a7Eo3++3TpP4cV+FZiO4aZYZ3yZftSRHwWpGiDBdWOdTKR2GJi7Z z/OxacrmwmM1Z+WcigldbG8f3IMnOLK4X0uXjhVeAHrhuttQuM8i+4TNXgsZbmfEKNDQIQPO /lbacsGHWFB/U2y6SXVEkZs2xIciRA0iZNTv7mbIL8SZmf5wpbjDCYHiCjGCAzgwggM0AgEB MFowRzELMAkGA1UEBhMCU0UxFDASBgNVBAoMC1RlbGlhU29uZXJhMSIwIAYDVQQDDBlUZWxp YVNvbmVyYSBDbGFzcyAyIENBIHYyAg8BaKlzCTJTye3phLaz/cIwDQYJYIZIAWUDBAIBBQCg ggGvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE5MTAzMDEz MTcyMFowLwYJKoZIhvcNAQkEMSIEINl8oKyf/zMGzfdEfjI//Xeg+NuqXi4yk0ygb6POuWYd MGkGCSsGAQQBgjcQBDFcMFowRzELMAkGA1UEBhMCU0UxFDASBgNVBAoMC1RlbGlhU29uZXJh MSIwIAYDVQQDDBlUZWxpYVNvbmVyYSBDbGFzcyAyIENBIHYyAg8BaKlzCTJTye3phLaz/cIw awYLKoZIhvcNAQkQAgsxXKBaMEcxCzAJBgNVBAYTAlNFMRQwEgYDVQQKDAtUZWxpYVNvbmVy YTEiMCAGA1UEAwwZVGVsaWFTb25lcmEgQ2xhc3MgMiBDQSB2MgIPAWipcwkyU8nt6YS2s/3C MGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0D BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwIC ASgwDQYJKoZIhvcNAQEBBQAEggEAZq7pNIlzaXtJqOuruPlaxGw3uH+Iu7lsursuW0pznyoo ooF6iS1GZQTJ0gemGkgQYCb1AKDB1272kBjwBsdYb/zGoZx9Bh2kRVY7pziDGYY5esXAgpnI UIYz6p1iuMCmcV1pZFrY8TqADcTbzw5RKPvu/+G4IFAcu11z3/NThqSqUelaS1g/QXSVRR7x aV+o+8pXUFq7qPpf9AdwkEZ5MuPzBRnKaKiR2/AS+Ui8bsr6cjh/9gHCZqJajwcVOiDYdhJc 94LTvXzmg6qhCOioEBkjGzgzK7nHgECeKU3yHSpJgJQIdbg40oCj+LUSp34MN4gj6zSRaqh+ aRjAt4R8UAAAAAAAAA== --------------ms060808060902020807090004-- From nobody Wed Oct 30 06:45:35 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 E8FDC12020A; Wed, 30 Oct 2019 06:45:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?=C3=89ric_Vyncke_via_Datatracker?= To: "The IESG" Cc: draft-ietf-ace-cwt-proof-of-possession@ietf.org, ace-chairs@ietf.org, rdd@cert.org, ace@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.108.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?q?=C3=89ric_Vyncke?= Message-ID: <157244313194.32588.3480851326666905977.idtracker@ietfa.amsl.com> Date: Wed, 30 Oct 2019 06:45:31 -0700 Archived-At: Subject: [Ace] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-ietf-?= =?utf-8?q?ace-cwt-proof-of-possession-09=3A_=28with_COMMENT=29?= 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 Oct 2019 13:45:32 -0000 Éric Vyncke has entered the following ballot position for draft-ietf-ace-cwt-proof-of-possession-09: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ace-cwt-proof-of-possession/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for the work put into this document. The document is easy to read. I only one nit in section 3 and feel free to ignore all of it: While "sub" is explained as being the "subject", nothing is written about "iss" claim on the first time this term is used, it is only explained the 2nd time. For my IESG colleagues, I second Mirja's comment about adding a IANA registry entry based on email. Regards, -éric From nobody Wed Oct 30 09:13: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 6A9B3120947; Wed, 30 Oct 2019 09:13:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 d6k1KcfRDxQx; Wed, 30 Oct 2019 09:13:24 -0700 (PDT) Received: from mail-qk1-x732.google.com (mail-qk1-x732.google.com [IPv6:2607:f8b0:4864:20::732]) (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 CBAFE120972; Wed, 30 Oct 2019 09:13:12 -0700 (PDT) Received: by mail-qk1-x732.google.com with SMTP id 205so1986757qkk.1; Wed, 30 Oct 2019 09:13:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=SbhZFawaa90JfRQef7g5QYCRkhQGKqNO3/v6/27WBGs=; b=nTsn1D1aWZfFGDVAlKz1Xk7cLdPBBCALCd7MOx7/OIxiWRM2emQpu9XqMsUd0itfQi BgYSeWviuzVUk/P5goQnoj3p394jBYX/JAByNcVwdU6RqHplBav/SWgsZBNAnAKJY6Kc TR/5H8Bcl/qoULHkozxnzYGNX2TRsYzCN7/hSmK5MZjj9j6nBmm4VGbFWeAmL/guh+l/ QRQEuWSsl4851aioTSOvI+v5Jq8kc/6jAOqL+quGFB+TNc2jJl9tOg6KjGe7vJ8SIx6S 7Nm2PZypFpNncPMkgzlNBEBOSmE23mobElyf5C0pzK+onjWFWkd7V5ZAYXe75ndew7ER r8vw== 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=SbhZFawaa90JfRQef7g5QYCRkhQGKqNO3/v6/27WBGs=; b=ZoZqZSof3vdFhOrUKVaAaLEjhJC2AFUDzX6TxcPaXLcW5Xnr0QPH74n0TAVMsOzZxE kE6Pim4tShrWZpLtg18IYblDod+a+xrK4u7xtonjONKp615dULL3tel3Po42j7TaVm1V EzpYYKDxUhs0dyFcfJGJty81mfU7NCbXmGd/aTlC+IWhrgw5Qdih/9uXRWlVqwSTzu2p WitEiz8r+hDu6EMJd7of54VXACZ3q5w+XOLrCwllC3LP8gznS43CVeR/hjdJzXuZ06GL 6VRWxJVd2nrYW47aWDXi2CA5SqBtJYIIlUffl0ngVE3ZQZpYny4k6JKnTlDZjjWWJCC/ vRHw== X-Gm-Message-State: APjAAAVgmqgrjMBcpdHy73SGU7A1D8uiaum5TuwcBXxeG9js9uTNmswl d5u65WhzYA/SujIB8OErCzWjzjncP5KtgzckiTA= X-Google-Smtp-Source: APXvYqxbHHCDMWJjfrA7WiBkmIDsk7v4Osztd33nuJ5/Oasgr7t1O2GYK7HaXvdE5/RXtxKjtSKn/9oUwTRv4kiujXc= X-Received: by 2002:a37:8244:: with SMTP id e65mr694784qkd.233.1572451991564; Wed, 30 Oct 2019 09:13:11 -0700 (PDT) MIME-Version: 1.0 References: <021c01d5839c$d53206a0$7f9613e0$@augustcellars.com> <033101d5851b$30a41ad0$91ec5070$@augustcellars.com> In-Reply-To: From: Cigdem Sengul Date: Wed, 30 Oct 2019 16:12:59 +0000 Message-ID: To: Daniel Migault Cc: Jim Schaad , ace@ietf.org, draft-ietf-ace-mqtt-tls-profile@ietf.org Content-Type: multipart/alternative; boundary="00000000000062352f05962302a4" Archived-At: Subject: Re: [Ace] Review for draft-ietf-ace-mqtt-tls-profile-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: Wed, 30 Oct 2019 16:13:30 -0000 --00000000000062352f05962302a4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thank you for your comments Daniel (prefixed [CS]) My comments are inside. I've also created the -v-02-WIP branch for the work in progress based on your and Jim's comments. On Thu, Oct 24, 2019 at 2:50 AM Daniel Migault wrote: > HI, > > Thanks for sending an update. Please find my comments of the draft. > > This document makes the same assumptions as the Section 4 of the ACE > framework [I-D.ietf-ace-oauth-authz] regarding Client and RS > registration with the AS and establishing of keying material. > > The document seems mostly focuses on the latest version of MQTT, > I am wondering if we could encourage similarly the use of the latest > version of TLS that is 1.3 at the time of writing. > > It seems AS as not been defined previously, so maybe it should be > expanded there. > > [CS] Can add a similar recommendation for TLS 1.3. AS is expanded. > > MQTTS > Secured transport profile of MQTT. MQTTS runs over TLS. > The Server in MQTT acts as an intermediary between > Clients that publishes Application Messages, and the Clients > that made Subscriptions. The Broker acts as the Resource > Server for the Clients. > > publishes > [CS] Fixed. > > Subscription > A subscription comprises a Topic Filter and a maximum Quality > of Service (QoS). > > Maybe that would be clearer to specify QoS level as well. > [CS] Added. > PINGREQ > A ping request sent from a Client to the Broker. It signals > to the Broker that the Client is alive, and is used to > confirm that the Broker is still alive. > > It may look a bit strange to have PINGREQ without PINGRESP. You > might also indicate the keep alive period is provided in the CONNECT > [CS] Added PINGRESP, clarified the Keep Alive period is set in the CONNECT in the definition of PINGREQ. > > Will > An application message published by the Server after the > network connection is closed in cases where the network > connection is not closed normally. If the Will Flag is set, > then the payload of the CONNECT message has information about > the Will. The Will consists of the Will Properties, Will > Topic, and Will Payload fields in the CONNECT message. > > > The first sentence seems to be related to the Will message while the > intent, I suppose of teh definition was to define the generic conpet of > Will. It might be clearer to expose the principle of the wil, that is a > server sends a given message in case a client is disconnected > improperly. It might be clearer to mention explicitly there is a Will > "concept" that is implemented a WillFlag WillQoS, WillRetain in the > CONNECT header as well as other Will Properties and Will Messages. This > mostly consists in the last sentence being moved up. > > [CS] I reworded it - let me know if it is more clear. > > 2. Protocol Interactions > > This section describes the following exchanges between Clients, the > Broker, and the Authorization Server according to the MQTT v5.0. > > Though english is not my first language, I have the impression the > text can be interpreted as MQTT enables clients to establish session > which does not seems correct to me. The text that follows clarifies this > as well. > > [CS] Neither mine, I reworded that as: "Authorizing connection requests from the Clients to the Broker" Actually, I also went through the text to reword "establishment" to set-up which is simpler. > > 2.1. Authorizing Connection Establishment > > If the > Client is resource-constrained, a Client Authorisation Server may > > I have the impression an AS would be sufficient. > [CS] Client Authorization Server was the terminology used in the Actors draft - I've removed all other references but wanted to distinguish that this is separate than the AS granting access tokens. Can just say client's AS? > > carry out the token request on behalf of the Client, and later, > onboard the Client with the token. Also, these interfaces may be > implemented using other protocols, e.g., CoAP or MQTT. > While the introduction and the figure mentions that HTTPS is used > as a transport, it might be worth mentioning that HTTPS is being used. I > propose to add "...other protocols than HTTPS, e.g ... > > [CS] Added. > 2.1.1. Client Token Request to the Authorization Server (AS) > > The first step in the protocol flow (Figure 1 (A)) is the token > acquisition by the Client from the AS. When requesting an access > token from the AS, the Client MAY include parameters in its request > as defined in Section 5.6.1 of the ACE framework > [I-D.ietf-ace-oauth-authz]. The media format is 'application/ > ace+json'. The profile parameter MUST be set to 'mqtt_tls'. The > OAuth 2.0 AS uses a JSON structure in the payload of its responses > both to client and RS. > > I understand that some parameters are mandatory while other are > not. I believe it might be clearer to start with the mandatory > parameters (MUST) and then mention that other parameters are optional > (MAY). That said, it might be simpler, if that is correct to mention > that the token request is as described in Section 5.6.1 of the ACE > framework > [I-D.ietf-ace-oauth-authz] with the profile set to "mqtt". > > [CS] When requesting an access token from the AS, the Client follows the token request as is described in Section 5.6.1 of the ACE framework, however, it MUST set the profile parameter to 'mqtt_tls'. > > > In the case of an error, the AS returns error responses for HTTP- > based interactions as ASCII codes in JSON content, as defined in > Section 5.2 of RFC 6749 [RFC6749]. > > Error messages are handled by OAuth2.0 instead of the ACE > framework in order to keep JSON format. I am wondering why do we have > the requirement to use ace+cbor only for error message ? It seems to me > a bit strange to have error handling defined in another document. > > > [CS] Should keep as-is for the time being? > > 2.1.2. Client Connection Request to the Broker (C) > > This section describes how the Client transports the token to the > Broker (RS) via the CONNECT control message after the TLS handshake. > > If the TLS handshake has already been performed, it would be good > to mention which credentials have been used. Obviously, if the token is > provided by the CONNECT message, I expect other credentials to be > involved. > [CS] TLS handshake uses only server-side certificate or RPK. I think this is in the text. That said there is a Github issue #16 https://github.com/ace-wg/mqtt-tls-profile/issues/16 around this, and will provide other clarifications as Jim asked. > > This is similar to an earlier proposal by Fremantle et al. > [fremantle14]. Alternatively, the token may be used for the TLS > session establishment as described in the DTLS profile for ACE > [I-D.gerdes-ace-dtls-authorize]. In this case, both the TLS PSK and > RPK handshakes MAY be supported. > > It would be good to expand Raw Public Keys (RPK). My reading is that > this section does not provide a single mechanism for the Client to be > authenticated by the Broker, but instead two different ways. I would > thus recommend to state it clearly in the introduction of the section.. > Currently, the section mentions: > """ > This section describes how the Client transports the token to the > Broker (RS) via the CONNECT control message after the TLS handshake. > """ > > An then we have a relatively detailed description on how this is > performed using TLS. It might be better to say something around the > following lines: > """ > This section describes how the Client transports the token to the > Broker (RS). This can be achieved during the TLS KEX or during the > MQTT session establishment via the CONNECT control message after the TLS > handshake. > """ > > I am not sure that MAY is appropriated here. I suspect that if none are > supported, this method will not work. As a result, if seems to me that > it woudl be more accurate to say that TLS Client and TLS server MUST > support the PSK authentication as well as the raw public key. > > One issue I have with I-D.gerdes-ace-dtls-authorize that is now > draft-ietf-ace-dtls-authorize is that it seems to only consider TLS 1.2. > With TLS 1.3 PSK and RPK are supported. > > My interpretation is that PSK provides mutual authentication, but in our > case RPK will only authenticate the client. If that is correct, there > might be a new to specify how the RS is authenticated by the Client. > > > [CS] I will actually reorganize this section, and hence, this will be more clear. Added your comment to issue #29, acknowledge that it is linked to #16 as well. I was trying to say the following, but I see that the text is not clear on that: - MUST: TLS with server validation + token in MQTT CONNECT (will clarify server-side certificate/RPK) - MAY: TLS with server/client validation with RPK -> token pushed to "authz-info" - MAY: TLS with server/client validation with PSK -> token in psk_identity > This option is described in more > detail in Appendix B. > > see my comment in annex B. > > [CS] OK. > After the token acquisition, the Client connects to the RS (Broker) > using the CONNECT message of MQTT over TLS. For server > authentication, the client MAY either have the ability to receive and > validate a certificate or a raw public key from the Broker. > > I might have missed something, but I thought that PSK/RPK were > used to authenticate the Client. While in this case the RPK is used to > authenticate the RS, is that the same RPK provided by the AS or another > one? > [CS] No the RPK was suggested for the RS/Broker authentication. As in the core ACE document, we assumed that the client learned either the RS's public key from the AS. However, I haven't seen in the core document an example of how AS returns this information to the client. For token transport, the RS SHOULD support AUTH (Authentication > Exchange) method. The RS MAY support token transport via username > and password, which is described in Section 3 for MQTT v3.1.1. The > rest of this section describes the AUTH method, for which the > username and password flags MUST be set to 0. > > > Maybe the reference should be for MQTTv5 instead of MQTTv3. > I believe it would be good to specify how setting the password flag > interacts with the Authentication method. > > > > [CS] Do you suggest that if AUTH method is used, MQTTv5 ignores password/username? > 2.1.2.1. Proof-of-Possession over Predefined Field > > For this option, the Authentication Data MUST contain the token and > the keyed message digest (MAC) or the Client signature. To calculate > the keyed message digest (MAC) or the Client signature, the Client > SHOULD apply the PoP key to the CONNECT payload. > > I have the impression the latest sentence indicates that the > Authenticated Data is include din the CONNECT payload. I have however > the impression that Authenticated Data is part of the properties which > are include din the variable header and not the payload. > [CS] No, the CONNECT payload only includes Client Identifier, Will Properties, Will Topic, Will Payload, User Name, Password. AUTH data is variable header part of the CONNECT message. Anyway, based on also Jim's input, using payload to do the PoP will be dropped. Jim suggested we use a nonce from the tls_exporter, and apply PoP to that. We believe that is the better approach as well. These are related to issues #15 ( https://github.com/ace-wg/mqtt-tls-profile/issues/15) and #19 ( https://github.com/ace-wg/mqtt-tls-profile/issues/19). The CONNECT payload > has at least a Client Identifier, and if the Will Flag is set to 1, > may contain Will-related information. The Client Identifier is a > MUST be a UTF-8 Encoded String (i.e., is prefixed with a two-byte > integer length field that gives the number of bytes in a UTF-8 > encoded string itself). The Client Identifier may be 1-23 UTF-8 > encoded bytes, and contain only the characters > "0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ". > > > For my information I would like to understand the mention of UTF8 > while only ascii characters are permitted. It seems that teh server MUST > accept these and MAY accept others as well as a longer client id. Am I > correct ? > > The nonce coded this way has a randomness of 62**23 =3D2**138 =3D 17 byte= s > > [CS] This section will be changed anyway... However, need to familiarize to specify how to use Exporter Labels. (Server can accept other characters.) 2.1.4. The Broker's Response to Client Connection Request > > If the RS accepts the connection, it MUST store the token until the > end of connection. On Client or RS disconnection, the token is > discarded, and the Client MUST provide a token inside each CONNECT > message. > > The latest sentence is unclear to me. I think that disconnection > can be interpreted in two way: 1) the disconnection of the will or a > DISCONNECT. I believe both are considered. > > [CS] Either Client or Server may initiate a disconnection. In either case= , the token is discarded. The will may be sent if the client set up a will in case of unexpected disconnection. Though it needs to be clarified for instance, if there are retained messages, these are sent as long as the token is valid. Since the introspection results are cached, this can be still done but should clarify unless it gets confusing. To avoid any confusion, and not to have to discuss these things in that section, I reworded as: On Client or RS disconnection, the Client is expected to provide a token again inside the next CONNECT message. > If the token is not self-contained and the Broker uses token > introspection, it MAY cache the validation result to authorize the > subsequent PUBLISH and SUBSCRIBE messages. PUBLISH and SUBSCRIBE > messages, which are sent after a connection set-up, do not contain > access tokens. If the introspection result is not cached, then the > RS needs to introspect the saved token for each request. The Broker > SHOULD use a cache time out to introspect tokens regularly. > > The latest sentence seems to indicate that result provided as > via introspection do not necessarily have a Time to Live which could be > interpreted as a commitment from the AS to authorize during that > period. If that is possible, it would be appropriated this time out is > provided by the AS. > I am also wondering why the token expiration cannot be considered as > well. > > [CS] This is to handle the situation where the resource owner changes the permissions of the Client, which would revoke the token. And hence the token exp field would not help. If the RS does not check the token introspection results, it will use the token until its expiration time. I've considered this more appropriate to be set by the RS as its RS risk management. > > Appendix B. The Authorization Information Endpoint > > The main document described a method for transporting tokens inside > MQTT CONNECT messages. In this section, we describe an alternative > method to transport an access token. > The method consists of the MQTT Broker accepting PUBLISH messages to > a public "authz-info" topic. A Client using this method MUST first > connect to the Broker, and publish the access token using the "authz- > info" topic. The Broker must verify the validity of the token (i.e., > through local validation or introspection). After publishing the > token, the Client disconnects from the Broker and is expected to try > reconnecting over TLS. > > I understand this as an open channel for CONNECT and sending > PUBLISHING message. This potentially open the door for DoSing the RS > either by openning too many MQTT sessions or by sending too many tokens. > I expect this to be mentioned in the security consideration section as > well as potential mechanisms to limit these risks. > > [CS] It is indeed mentioned in this paragraph in the security consideration section. "The RS may monitor Client behaviour to detect potential security problems, especially those affecting availability. These include repeated token transfer attempts to the public "authz-info" topic, repeated connection attempts, abnormal terminations, and Clients that connect but do not send any data. If the RS supports the public "authz-info" topic, described in Appendix B, then this may be vulnerable to a DDoS attack, where many Clients use the "authz-info" public topic to transport fictitious tokens, which RS may need to store indefinitely." Thank you for your comments. And will try to address Jim's shortly to be able to push another version before the deadline. Kind regards, --Cigdem > > > On Thu, Oct 17, 2019 at 2:47 PM Jim Schaad wrote= : > >> >> >> >> >> *From:* Cigdem Sengul >> *Sent:* Thursday, October 17, 2019 4:13 AM >> *To:* Jim Schaad >> *Cc:* draft-ietf-ace-mqtt-tls-profile@ietf.org; ace@ietf.org >> *Subject:* Re: [Ace] Review for draft-ietf-ace-mqtt-tls-profile-01 >> >> >> >> Hello Jim, >> >> Thanks for this review. I have responded inline. >> >> >> >> 1. Are there any specifics about using ACE over HTTP that need to be >> explicitly stated some place. Some of these things might include: >> a) Must be HTTPS even if encrypted requests/responses are >> provided. >> b) What types of validation are permitted/required: anon-anon, >> server validation, server & client validation. The latter corresponds to >> current DTLS statements. >> c) Are we looking for using the normal HTTP/HTTPS ports or shoul= d >> we >> be using different ports? >> >> >> >> >> Agreed. Need to specify that it is HTTPS. >> >> Mutual authentication and server validation Required. >> >> Was thinking it would be normal HTTPS ports. Should we consider differen= t? >> >> What scenarios should permit anon-anon; anon clients? >> >> >> >> [JLS] If you look at my last email I went through this. Anon-anon is >> going to be a bad idea because the server is never validated, however >> client anon is fine since you are going to validate the client in the MQ= TT >> protocol. >> >> >> >> >> >> >> 4. Section 2.1.2: It is not clear from the document is a Broker is goin= g >> to >> also have the possibility of doing a post of the token via HTTPS. >> Currently >> I would think not, but given that this is documented in OAuth 2.0 as an >> option I am not clear. >> >> >> Do you mean for introspection? Yes, this is a MAY as in the core >> document, and so in this one too. >> >> And if there is an RS-AS interaction, we expect that to be on HTTPS. >> >> I will try to see where I should clarify in the text. >> >> >> >> [JLS] No, I was originally looking at doing an HTTPS post of the token >> from the client to the RS. This was before I figured out that you have = an >> alternative method of doing this in the MQTT protocol and so it should n= ot >> be needed. Being clear on the fact that this would not be expected is >> probably a good idea. >> >> >> >> >> 7. In Figure 2, I think the use of Client Identifier is somewhat >> confusing. I think this is supposed to be the token as the Client >> Identifier is a different thing in MQTT. Either that or you need to do = a >> better job of describing the property block. >> >> >> >> OK. I think I should explain MQTT packets better. >> >> A connect packet has three parts: 1) Fixed header 2) Variable Header and >> 3) Payload. >> >> The variable header may have several properties, and Authentication >> Method and Authentication Data are two of these properties. >> >> According to MQTT Specification: >> >> The ClientID MUST be present and is the first field in the CONNECT packe= t >> Payload. >> >> The ClientID MUST be a UTF-8 Encoded String >> >> A Server MAY allow a Client to supply a ClientID that has a length of >> zero bytes, however, if it does so the Server MUST treat this as a speci= al >> case. >> >> >> >> And this is what is done in the case of a collision: >> >> If the ClientID represents a Client already connected to the Server, the >> Server sends a DISCONNECT packet to the existing Client with Reason Code= of >> 0x8E (Session taken over) >> >> >> >> Is this more clear? If yes, I will try to clarify in text. >> >> >> >> [JLS] That is not where I was having a problem. I was getting confused >> by the figure itself. Labeling the figure better might help. =E2=80=9C= MQTT V5.0 >> CONNECT control message with =E2=80=98ace=E2=80=99 authentication method= =E2=80=9D. I would rather >> not have all of the abbreviations in the title, but I can live with it. >> >> >> >> >> 8. If the value of Clean Start or Expiry Interval are not set correct i= s >> the server to fail the connect? >> >> >> >> >> Agreed. This should be specified. >> >> Two options: 1) Do not accept connection or 2) accept the connection but >> then never create sessions, and then server MUST set Session Present to >> 0 in the CONNACK packet, indicating >> >> no session is present. >> >> >> >> This basically makes Clean Start flag meaningless. >> >> If this is better than client MUST be setting those parameters correctly= , >> then we can go this way. >> >> Any thoughts? >> >> >> >> [JLS] I don=E2=80=99t really care one way or the other. Given that ther= e is the >> return value in the CONNACK, I think that a simple statement that the fl= ag >> is set to 0 regardless of the value coming in. >> >> >> >> >> 10. Section 2.1.2.1 - I am having a problem computing the MAC over the >> payload of the CONNECT message. The password where the value is placed = is >> included in the payload and I am not clear if it should be computed up t= o >> that value or if a fixed value should be used for the computation. >> >> >> >> >>OK. I think it got muddled because I was trying to find a solution for >> a scenario where the ClientId is used across sessions, and hence, not >> random. >> >> >> >> Two cases. >> >> 1) Client ID uniquely random across each Client connection attempt to >> Broker: MAC over Payload - Payload begins with ClientID and MAY include >> Will Properties if Client indicated that it will have a will. >> >> 2) Client ID NOT uniquely random: MAC over Authentication Data. >> >> >> >> It may be best to choose one method and just say MUST always have a nonc= e >> in Authentication Data, and MAC is computed over that? >> >> >> >> [JLS] Lets step back and look at the problem I think you are trying to >> solve. >> >> - If you are trying to make sure that there is not a replay of the >> signature, then this would require that the server keep track of the = list >> of nonce values that the client has provided. >> - If you are trying to make sure that the signature is =E2=80=9Cfres= h=E2=80=9D then >> the server would need to be able to provide some type of data as part= of >> the value being signed. As I think I have said before the latter can= be >> satisfied by getting your nonce value from the TLS session using a >> tls-exporter. >> >> >> >> If neither of these problems is trying to be solved, then there is no >> need for the nonce at all. >> >> >> >> >> >> 11. I am worried about the text on the Client Identifier in this section= . >> It is not clear to me that having the client generate a random value for >> this field is good just in terms of the possibility of collisions >> occurring >> on the server. The text in the MQTT 5.0 document appears to say that th= is >> is more interesting for the situation of getting back state that was lef= t >> on >> the server after a disconnect and not so much for a clean session. >> >> >> >> >> Yes, but as I explained for comment 7, in MQTT, the typical case is >> the client provides its id. >> >> However, to cater to all requirements and all implementation >> possibilities, maybe it is best to just use a nonce as explained for >> comment 10 and not tie anything to client id. >> >> >> >> Previously, when we were writing the draft for MQTT v3.1.1 we wanted to >> provide a solution that uses the available fields in the CONNECT packet = as >> much as possible; without >> >> introducing any new fields. This was because of the constraints of the >> MQTT v3.1.1. MQTT v5 gives us more options to implement this better. >> >> >> >> For backward compatibility, we would need to think if we create a specia= l >> data structure to be used in the password so that it holds both the >> MAC/signature and the nonce. >> >> >> >> As the use of ClientId seems to create confusion, I am leaning towards >> this solution. Any thoughts? >> >> >> >> [JLS] Look at the previous answer and the re-ask the question. >> >> >> >> >> >> 13. Is there someplace that authentication methods need to be >> registered? I >> was unable to see any such registry setup with OASIS from the v5 >> specification. Should we suggest to the MQTT group that this is somethi= ng >> that should be done? >> >> >> >> >> This is an interesting thought. The draft was indeed discussed in the >> OASIS MQTT WG. >> >> >> >> But, the WG may consider this out of scope, as they have on their charte= r >> page: >> >> Transport level security is assumed and no mandatory security features >> will be added. >> >> The MQTT v5 draft says: >> >> The Authentication Method is commonly a SASL mechanism, and using such a >> registered name aids interchange. However, the Authentication Method is = not >> constrained to using registered SASL mechanisms. >> >> >> >> [JLS] I think that the lack of a registry should be identified someplace >> in the document. This is probably a security consideration that there >> might be a different authentication method which re-uses the same >> authentication method name. >> >> >> >> >> >> 17. It is not clear to me, how in the scope string is the ability to >> have a >> "will" indicated? >> >> >> If the Will Flag is set to 1, the Will Topic follows the Client ID >> and Will Properties in the Payload. >> >> This is where the broker learns the Will Topic. >> >> Then the scope would be publish_. >> >> And subscribes would need to subscribe_ to receive this >> message. >> >> Will clarify in text. >> >> >> >> [JLS] publish makes sense to me. I was just being overly complicated. >> >> >> >> 18. Section 2.1.4 - I am unsure what the implications of discarding >> tokens >> on the end of a connection are going to be. How do you publish the toke= n >> before doing the connection or is that only for an updated token? >> >> >> >> >> Tokens are discarded at the end of disconnection because no previous >> session state is kept. >> >> And a token is expected in the new CONNECT request (otherwise, it is AS >> discovery) >> >> >> >> Before the connection, a token may be transported via "authz-info" topi= c >> described in Appendix B. >> >> During the connection, a new token may be transported via the AUTH packe= t >> - which enables reauthentication. >> >> >> >> [JLS] This is still not clear to me. Is the transport of the token via >> =E2=80=9Cauth-info=E2=80=9D topic not considered to be part of the sessi= on? If you say >> that you look at just the last value published, then is there not going = to >> be a race condition between two different clients trying to publish and >> connect? >> >> >> >> >> 20. I am not sure what the benefits of doing the check on a PINGREQUEST >> is >> going to be. Like the relay of a PUBLISH message this is just going to >> produce a DISCONNECT and a closed channel. If this is really allowed, >> then >> you should potentially also say that the Broker could do a check based o= n >> clock time elapsing. (I.e. do the check every hour.) >> >> >> >> >> This was suggested by one of the reviewers that provide MQTT services >> (his e-mail regarding this was sent to the ace list). >> >> It was suggested as an optimization for detecting token expirations and >> disconnecting early. >> >> (i.e., if you are already receiving PINGREQUESTs, use these as a trigger >> to check the token). >> >> I think time-based checks may also help and be added as an option. >> >> >> >> [JLS] Ok >> >> >> >> >> 22. Not sure if this goes here or in the connect documentation. There >> needs >> to be a check that the will topic is a topic that the client is going to >> be >> permitted to publish on. Corner case, if the ability to publish a will >> in >> the event that this permission is lost. Does this kill the session or t= he >> will message? I.e. should the permission for the will message be >> rechecked >> before sending it allowing for the time based expiration of the token. >> >> >> >> >> We have been thinking about this. >> >> If the disconnect is due to a token expiration, and hence, also includes >> the will topic as well, you have to decide between: >> >> 1) publish the will >> >> 2) do not publish the will. >> >> At the moment, it's written like we publish the will - but on second >> consideration, >> >> it seems safer to say "Publish the Will on Server Disconnect or unusual >> disconnect if the token (the will permission) has not expired". >> >> >> >> [JLS] I would be fine with either position, after all at the time the >> =E2=80=9Cpublish=E2=80=9D event occurred the token was valid, this is ju= st deferring >> relaying it to subscribers. >> >> >> >> Jim >> >> >> >> >> >> Thanks again for these comments, will create the necessary github issues >> and start revising the text. >> >> >> >> Best, >> >> >> >> >> Jim >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> Ace mailing list >> Ace@ietf.org >> https://www.ietf.org/mailman/listinfo/ace >> >> _______________________________________________ >> Ace mailing list >> Ace@ietf.org >> https://www.ietf.org/mailman/listinfo/ace >> > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > --00000000000062352f05962302a4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thank you for your comments Daniel (prefi= xed [CS])
My comments are inside. I've also created the -v-02-WIP b= ranch for the work in progress based on your and Jim's comments.=C2=A0<= /div>

On Thu, Oct 24, 2019 at 2:50 AM Daniel Migault <daniel.migault=3D40ericsson.com@dmarc.ietf.or= g> wrote:
HI,=C2=A0

Thanks for sending an update. Please find my comments of th= e draft.=C2=A0

=C2=A0 =C2=A0This document makes th= e same assumptions as the Section 4 of the ACE
=C2=A0 =C2=A0framework [I= -D.ietf-ace-oauth-authz] regarding Client and RS
=C2=A0 =C2=A0registrati= on with the AS and establishing of keying material.

<mglt> The= document seems mostly focuses on the latest version of MQTT,
I am wonde= ring if we could encourage similarly the use of the latest
version of TL= S that is 1.3 at the time of writing.

It seems AS as not been define= d previously, so maybe it should be
expanded there.
</mglt>=C2= =A0

[CS] Can add a si= milar recommendation for TLS 1.3.=C2=A0
AS is expanded.=C2=A0

=C2=A0

=C2=A0 =C2= =A0MQTTS
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Secured transport prof= ile of MQTT.=C2=A0 MQTTS runs over TLS.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0The Server in MQTT acts as an intermediary between
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Clients that publishes Application Messages,= and the Clients
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0that made Subs= criptions.=C2=A0 The Broker acts as the Resource
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0Server for the Clients.

<mglt>publishes<= ;/mglt>
[CS] Fixed.
=C2=A0
<= div dir=3D"ltr">

=C2=A0 =C2= =A0Subscription
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0A subscription = comprises a Topic Filter and a maximum Quality
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0of Service (QoS).

<mglt>Maybe that would be c= learer to specify QoS level as well.</mglt>

[CS] Added.=C2=A0

=C2= =A0
=C2=A0 =C2=A0PINGREQ
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0A ping request sent from a Client to the Broker.=C2=A0 It sign= als
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0to the Broker that the Clie= nt is alive, and is used to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0con= firm that the Broker is still alive.

<mglt>It may look a bit s= trange to have PINGREQ without PINGRESP. You
might also indicate the kee= p alive period is provided in the CONNECT</mglt>

[CS] Added PINGRESP, clarified the Keep A= live period is set in the CONNECT in the definition of PINGREQ.=C2=A0
=
=C2=A0

=C2=A0 =C2=A0Will
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0An application message published by the Server afte= r the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0network connection is clo= sed in cases where the network
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= connection is not closed normally.=C2=A0 If the Will Flag is set,
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0then the payload of the CONNECT message = has information about
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the Will.= =C2=A0 The Will consists of the Will Properties, Will
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0Topic, and Will Payload fields in the CONNECT messa= ge.

<mglt>
The first sentence seems to be related to the Wi= ll message while the
intent, I suppose of teh definition was to define t= he generic conpet of
Will. It might be clearer to expose the principle o= f the wil, that is a
server sends a given message in case a client is di= sconnected
improperly. =C2=A0 It might be clearer to mention explicitly = there is a Will
"concept" that is implemented a WillFlag WillQ= oS, WillRetain in the
CONNECT header as well as other Will Properties an= d Will Messages. This
mostly consists in the last sentence being moved u= p. =C2=A0
</mglt>

[CS] I reworded it - let me know if it is more clear.=C2=A0

2.=C2=A0 Protocol Interactions

= =C2=A0 =C2=A0This section describes the following exchanges between Clients= , the
=C2=A0 =C2=A0Broker, and the Authorization Server according to the= MQTT v5.0.

<mglt> Though english is not my first language, I = have the impression the
text can be interpreted as MQTT enables clients = to establish session
which does not seems correct to me. The text that f= ollows clarifies this
as well. =C2=A0
</mglt>

[CS] Neither mine, I reworded that as:= "Authorizing connection requests from the Clients to the Broker"=
Actually, I also went through the text to reword "establish= ment" to set-up which is simpler.=C2=A0
=C2=A0

2.1.=C2=A0 Authorizing Connection Establish= ment

If the
=C2=A0 =C2=A0Client is resource= -constrained, a Client Authorisation Server may

<mglt>I have t= he impression an AS would be sufficient.</mglt>
=

[CS] Client Authorization Server was the t= erminology used in the Actors draft - I've removed all other references= but wanted to distinguish that this is separate than the AS granting acces= s tokens.=C2=A0
Can just say client's AS?=C2=A0

=C2=A0 =C2=A0carry out the token request on behalf of the Client,= and later,
=C2=A0 =C2=A0onboard the Client with the token.=C2=A0 Also, = these interfaces may be
=C2=A0 =C2=A0implemented using other protocols, = e.g., CoAP or MQTT.
<mglt>While the introduction and the figure m= entions that HTTPS is used
as a transport, it might be worth mentioning = that HTTPS is being used. I
propose to add "...other protocols than= HTTPS, e.g ...
</mglt>
[CS] Added.=C2=A0

=
2.1.1.=C2=A0 Client Token Request to the Authorization Serve= r (AS)

=C2=A0 =C2=A0The first step in the protocol flow (Figure 1 (A= )) is the token
=C2=A0 =C2=A0acquisition by the Client from the AS.=C2= =A0 When requesting an access
=C2=A0 =C2=A0token from the AS, the Client= MAY include parameters in its request
=C2=A0 =C2=A0as defined in Sectio= n 5.6.1 of the ACE framework
=C2=A0 =C2=A0[I-D.ietf-ace-oauth-authz].=C2= =A0 The media format is 'application/
=C2=A0 =C2=A0ace+json'.=C2= =A0 The profile parameter MUST be set to 'mqtt_tls'.=C2=A0 The
= =C2=A0 =C2=A0OAuth 2.0 AS uses a JSON structure in the payload of its respo= nses
=C2=A0 =C2=A0both to client and RS.

<mglt> I understan= d that some parameters are mandatory while other are
not. I believe it m= ight be clearer to start with the mandatory
parameters (MUST) and then m= ention that other parameters are optional
(MAY). That said, it might be = simpler, if that is correct to mention
that the token request is as desc= ribed in Section 5.6.1 of the ACE framework
=C2=A0 =C2=A0[I-D.ietf-ace-o= auth-authz] with the profile set to "mqtt".
</mglt>
=

[CS]=C2=A0
Whe= n requesting an access token from the AS, the Client follows the token requ= est as is
described in Section 5.6.1 of the ACE framework, however, it M= UST set the profile parameter to 'mqtt_tls'.=C2=A0
= =C2=A0


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

<mglt>Error messa= ges are handled by OAuth2.0 instead of the ACE
framework in order to kee= p JSON format. I am wondering why do we have
the requirement to use ace+= cbor only for error message ? It seems to me
a bit strange to have error= handling defined in another document.
</mglt>

=
[CS] Should keep as-is for the time being?=C2=A0
=C2=A0

2.1.2.=C2=A0 Client Connec= tion Request to the Broker (C)

=C2=A0 =C2=A0This section describes h= ow the Client transports the token to the
=C2=A0 =C2=A0Broker (RS) via t= he CONNECT control message after the TLS handshake.

<mglt>If t= he TLS handshake has already been performed, it would be good
to mention= which credentials have been used. Obviously, if the token is
provided b= y the CONNECT message, I expect other credentials to be
involved. </m= glt>

[CS] TLS hand= shake uses only server-side certificate or RPK. I think this is in the text= .=C2=A0
That said there is a Github issue #16=C2=A0https://github.com/ace-w= g/mqtt-tls-profile/issues/16
around this, and will provide ot= her clarifications as Jim asked.=C2=A0

=C2=A0 =C2=A0= This is similar to an earlier proposal by Fremantle et al.
=C2=A0 =C2=A0= [fremantle14].=C2=A0 Alternatively, the token may be used for the TLS
= =C2=A0 =C2=A0session establishment as described in the DTLS profile for ACE=
=C2=A0 =C2=A0[I-D.gerdes-ace-dtls-authorize].=C2=A0 In this case, both = the TLS PSK and
=C2=A0 =C2=A0RPK handshakes MAY be supported.
<mg= lt>
It would be good to expand Raw Public Keys (RPK). My reading is t= hat
this section does not provide a single mechanism for the Client to b= e
authenticated by the Broker, but instead two different ways. I wouldthus recommend to state it clearly in the introduction of the section..Currently, the section mentions:
"""
This section de= scribes how the Client transports the token to the
=C2=A0 =C2=A0Broker (= RS) via the CONNECT control message after the TLS handshake.
""= ;"

An then we have a relatively detailed description on how thi= s is
performed using TLS. It might be better to say something around the=
following lines:
"""
This section describes how th= e Client transports the token to the
=C2=A0 =C2=A0Broker (RS). This can = be achieved during the TLS KEX or during the
MQTT session establishment = via the CONNECT control message after the TLS handshake.
""&qu= ot;

I am not sure that MAY is appropriated here. I suspect that if n= one are
supported, this method will not work. As a result, if seems to m= e that
it woudl be more accurate to say that TLS Client and TLS server M= UST
support the PSK authentication as well as the raw public key.
One issue I have with I-D.gerdes-ace-dtls-authorize that is now
draft-= ietf-ace-dtls-authorize is that it seems to only consider TLS 1.2.
With = TLS 1.3 PSK and RPK are supported.

My interpretation is that PSK pr= ovides mutual authentication, but in our
case RPK will only authenticate= the client. If that is correct, there
might be a new to specify how the= RS is authenticated by the Client.

</mglt>

[CS] I will actually reorganize this s= ection, and hence, this will be more clear.=C2=A0
Added your comm= ent to issue #29, acknowledge that it is linked to #16 as well.=C2=A0
=

I was trying to say the following, but I see that the t= ext is not clear on that:
- MUST: TLS with server validation=C2= =A0+ token in MQTT CONNECT (will clarify server-side certificate/RPK)
=
- MAY: TLS with server/client validation with RPK -> token pushed t= o "authz-info"
- MAY: TLS with server/client validation= with PSK -> token in=C2=A0=C2=A0psk_identity
=C2=A0
= =C2=A0This option is described in more
=C2=A0 =C2=A0detail in Appendix B= .

<mglt>see my comment in annex B.</mglt>


[CS] OK.=C2=A0
=


=C2=A0 =C2=A0After the token acquisition, the = Client connects to the RS (Broker)
=C2=A0 =C2=A0using the CONNECT messag= e of MQTT over TLS.=C2=A0 For server
=C2=A0 =C2=A0authentication, the cl= ient MAY either have the ability to receive and
=C2=A0 =C2=A0validate a = certificate or a raw public key from the Broker. =C2=A0

<mglt>= I might have missed something, but I thought that PSK/RPK were
used to a= uthenticate the Client. While in this case the RPK is used to
authentica= te the RS, is that the same RPK provided by the AS or another
one? </= mglt>

[CS] No the RPK wa= s suggested for the RS/Broker authentication.=C2=A0
As in the cor= e ACE document, we assumed that the=C2=A0client learned either the RS's public key<= /div>
from the = AS. However, I haven't seen in the core document an example of how AS= =C2=A0
returns this information to the client.=C2=A0


<= br>
=C2=A0 =C2=A0For token transport, the RS SHOULD support AUTH (Authent= ication
=C2=A0 =C2=A0Exchange) method.=C2=A0 The RS MAY support token tr= ansport via username
=C2=A0 =C2=A0and password, which is described in Se= ction 3 for MQTT v3.1.1.=C2=A0 The
=C2=A0 =C2=A0rest of this section des= cribes the AUTH method, for which the
=C2=A0 =C2=A0username and password= flags MUST be set to 0.

<mglt>
Maybe the reference should = be for MQTTv5 instead of MQTTv3.
I believe it would be good to specify = how setting the password flag
interacts with the Authentication method. =
</mglt>


[CS] Do you suggest that if AUTH method is used, MQTTv5 ignores passw= ord/username?


=C2=A0
2.1.2.1.=C2= =A0 Proof-of-Possession over Predefined Field

=C2=A0 =C2=A0For this = option, the Authentication Data MUST contain the token and
=C2=A0 =C2=A0= the keyed message digest (MAC) or the Client signature.=C2=A0 To calculate<= br>=C2=A0 =C2=A0the keyed message digest (MAC) or the Client signature, the= Client
=C2=A0 =C2=A0SHOULD apply the PoP key to the CONNECT payload.
=C2=A0 <mglt> I have the impression the latest sentence indicat= es that the
Authenticated Data is include din the CONNECT payload. I hav= e however
the impression that Authenticated Data is part of the properti= es which
are include din the variable header and not the payload. </m= glt>


[CS= ]=C2=A0
No, the CONNECT payload only includes=C2=A0Client Identif= ier, Will Properties, Will Topic, Will Payload, User Name, Password.
<= div>AUTH data is variable header part of the CONNECT message.=C2=A0
Anyway, based on also Jim's input, using payload to do the PoP will = be dropped.=C2=A0
Jim suggested we use a nonce from the tls_e= xporter, and apply PoP to that.=C2=A0
We believe that is the bett= er approach as well. These are related to issues #15 (=C2=A0https://github.com/ace-wg= /mqtt-tls-profile/issues/15) and #19 (https://github.com/ace-wg/mqtt-tls-profile/= issues/19).=C2=A0


The CONNECT payload<= br>=C2=A0 =C2=A0has at least a Client Identifier, and if the Will Flag is s= et to 1,
=C2=A0 =C2=A0may contain Will-related information.=C2=A0 The Cl= ient Identifier is a
=C2=A0 =C2=A0MUST be a UTF-8 Encoded String (i.e., = is prefixed with a two-byte
=C2=A0 =C2=A0integer length field that gives= the number of bytes in a UTF-8
=C2=A0 =C2=A0encoded string itself).=C2= =A0 The Client Identifier may be 1-23 UTF-8
=C2=A0 =C2=A0encoded bytes, = and contain only the characters
=C2=A0 =C2=A0"0123456789abcdefghijk= lmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ".

<mglt>
For= my information I would like to understand the mention of UTF8
while onl= y ascii characters are permitted. It seems that teh server MUST
accept t= hese and MAY accept others as well as a longer client id. Am I
correct ?=

The nonce coded this way has a randomness of 62**23 =3D2**138 =3D = 17 bytes
</mglt>

[= CS] This section will be changed anyway... However, need to familiarize to = specify how to use Exporter Labels.=C2=A0=C2=A0
(Server can accep= t other characters.)

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

=C2=A0 =C2=A0If the RS accepts the co= nnection, it MUST store the token until the
=C2=A0 =C2=A0end of connecti= on.=C2=A0 On Client or RS disconnection, the token is
=C2=A0 =C2=A0disca= rded, and the Client MUST provide a token inside each CONNECT
=C2=A0 =C2= =A0message.

<mglt> The latest sentence is unclear to me. I thi= nk that disconnection
can be interpreted in two way: 1) the disconnectio= n of the will or a
DISCONNECT. I believe both are considered. </mglt&= gt;

[CS] Either Client or S= erver may initiate a disconnection. In either case, the token is discarded.=
The will may be sent if the client set up a will in case of unex= pected disconnection.
=C2=A0
Though it needs to be clar= ified for instance, if there are retained messages, these are sent as long = as the token is valid.=C2=A0
Since the introspection results are = cached, this can be still done but should clarify unless it gets confusing.= =C2=A0

To avoid any confusion, and not to have to = discuss these things in that section, I reworded as:=C2=A0
On Cli= ent or RS disconnection, the Client is expected to provide a token again in= side the next CONNECT message.

=C2=A0
=
=C2=A0 =C2=A0If the token is not self-contained and the Broker uses to= ken
=C2=A0 =C2=A0introspection, it MAY cache the validation result to au= thorize the
=C2=A0 =C2=A0subsequent PUBLISH and SUBSCRIBE messages.=C2= =A0 PUBLISH and SUBSCRIBE
=C2=A0 =C2=A0messages, which are sent after a = connection set-up, do not contain
=C2=A0 =C2=A0access tokens.=C2=A0 If t= he introspection result is not cached, then the
=C2=A0 =C2=A0RS needs to= introspect the saved token for each request.=C2=A0 The Broker
=C2=A0 = =C2=A0SHOULD use a cache time out to introspect tokens regularly.

&l= t;mglt>The latest sentence seems to indicate that result provided as
= via introspection do not necessarily have a Time to Live which could be
= interpreted as a commitment from the AS to authorize during that
period.= If that is possible, it would be appropriated this time out is
provided= by the AS.
I am also wondering why the token expiration cannot be consi= dered as
well.
</mglt>


[CS] This is to handle the situation where the resou= rce owner changes the permissions of the Client, which would revoke the tok= en.
And hence the token exp field would not help.
=C2= =A0If the RS does not check the token introspection results, it=C2=A0
=
will use the token until its expiration time.=C2=A0
I've= considered this more appropriate to be set by the RS as its RS risk manage= ment.=C2=A0
=C2=A0

Appendix B.=C2= =A0 The Authorization Information Endpoint

=C2=A0 =C2=A0The main doc= ument described a method for transporting tokens inside
=C2=A0 =C2=A0MQT= T CONNECT messages.=C2=A0 In this section, we describe an alternative
= =C2=A0 =C2=A0method to transport an access token.
=C2=A0 =C2=A0The metho= d consists of the MQTT Broker accepting PUBLISH messages to
=C2=A0 =C2= =A0a public "authz-info" topic.=C2=A0 A Client using this method = MUST first
=C2=A0 =C2=A0connect to the Broker, and publish the access to= ken using the "authz-
=C2=A0 =C2=A0info" topic.=C2=A0 The Brok= er must verify the validity of the token (i.e.,
=C2=A0 =C2=A0through loc= al validation or introspection).=C2=A0 After publishing the
=C2=A0 =C2= =A0token, the Client disconnects from the Broker and is expected to try
= =C2=A0 =C2=A0reconnecting over TLS.

<mglt>I understand this as= an open channel for CONNECT and sending
PUBLISHING message. This potent= ially open the door for DoSing the RS
either by openning too many MQTT s= essions or by sending too many tokens.
I expect this to be mentioned in = the security consideration section as
well as potential mechanisms to li= mit these risks.
</mglt>

[CS] It is indeed mentioned in this paragraph in the security consi= deration section.=C2=A0
"The RS may monitor Client behaviour= to detect potential security problems, especially those affecting availabi= lity.
=C2=A0These include repeated token transfer attempts to the pu= blic "authz-info" topic, repeated connection attempts,
=C2= =A0abnormal terminations, and Clients that connect but do not send any data= .
=C2=A0If the RS supports the public "authz-info" topic, de= scribed in Appendix B,
=C2=A0then this may be vulnerable to a DDoS att= ack, where many Clients use the "authz-info" public topic
=C2= =A0 =C2=A0 =C2=A0 =C2=A0to transport fictitious tokens, which RS may need t= o store indefinitely."


Thank you for yo= ur comments. And will try to address Jim's shortly to be able to push a= nother version before the deadline.=C2=A0
<= br>
Kind regards,=C2=A0
--Cigdem=C2=A0
=C2=A0
=


On Thu, Oct 17, 2019 at 2:47 PM Jim Schaad <ietf@augustcellars.com> = wrote:

=C2=A0

=C2=A0

From: Cigd= em Sengul <= cigdem.sengul@gmail.com>
Sent: Thursday, October 17, 2019= 4:13 AM
To: Jim Schaad <ietf@augustcellars.com>
Cc: draf= t-ietf-ace-mqtt-tls-profile@ietf.org; ace@ietf.org
Subject: Re: [Ace] Review for d= raft-ietf-ace-mqtt-tls-profile-01

<= u>=C2=A0

Hello Jim,

Thanks for this review. I have r= esponded inline.=C2=A0

<= p class=3D"MsoNormal" style=3D"margin-bottom:12pt">

1.=C2=A0 Are the= re any specifics about using ACE over HTTP that need to be
explicitly st= ated some place.=C2=A0 Some of these things might include:
=C2=A0 =C2=A0= =C2=A0 =C2=A0 a) Must be HTTPS even if encrypted requests/responses are pr= ovided.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 b) What types of validation are per= mitted/required: anon-anon,
server validation, server & client valid= ation. The latter corresponds to
current DTLS statements.=C2=A0
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 c) Are we looking for using the normal HTTP/HTTPS = ports or should we
be using different ports?=C2=A0

=C2=A0

>> Agreed. Need to specify that it is HTTPS.<= /u>

Mutual authentication and s= erver validation Required.

Was thinking it would be normal HTTPS ports. Should we consider differe= nt?

What scenarios shoul= d permit anon-anon; anon clients?=C2=A0

=C2=A0

[JLS] If you look at my= last email I went through this.=C2=A0 Anon-anon is going to be a bad idea = because the server is never validated, however client anon is fine since yo= u are going to validate the client in the MQTT protocol.

=

=C2=A0

=C2=A0


4.=C2=A0 Section 2.1.2: = It is not clear from the document is a Broker is going to
also have the = possibility of doing a post of the token via HTTPS.=C2=A0 Currently
I wo= uld think not, but given that this is documented in OAuth 2.0 as an
opti= on I am not clear.

>> Do you mean for introspection? Yes, this is a MAY as in the core= document, and so in this one too.=C2=A0

And if there is an RS-AS interaction, we expect that to be= on HTTPS.=C2=A0

I will = try to see where I should clarify in the text.=C2=A0

=C2=A0

[JLS] No, = I was originally looking at doing an HTTPS post of the token from the clien= t to the RS.=C2=A0 This was before I figured out that you have an alternati= ve method of doing this in the MQTT protocol and so it should not be needed= .=C2=A0 =C2=A0Being clear on the fact that this would not be expected is pr= obably a good idea.

=C2= =A0

7.=C2=A0 =C2=A0In Figure 2, I think the use of Client Identifier is somew= hat
confusing.=C2=A0 I think this is supposed to be the token as the Cli= ent
Identifier is a different thing in MQTT.=C2=A0 Either that or you ne= ed to do a
better job of describing the property block.

=C2=A0

OK. I think I should explain MQTT packets better.= =C2=A0

A connect packet = has three parts: 1) Fixed header 2) Variable Header and 3) Payload.<= u>

The variable header may have se= veral properties, and Authentication Method and Authentication Data are two= of these properties.=C2=A0

According to MQTT Specification:

<= div>

The ClientID MUST be a UTF-= 8 Encoded String

A Server MAY allow a Client to supply a ClientI= D that has a length of zero bytes,=C2=A0however, if it does so the Server M= UST treat this as a special case.

=C2=A0

And this is what is done in the case of a collisio= n:

<= span style=3D"font-size:10pt;font-family:Arial,sans-serif;color:black;backg= round:yellow">If the ClientID represents a Client already connected to the = Server, the Server sends a DISCONNECT packet to the existing Client with Re= ason Code of 0x8E (Session taken over)=C2=A0

=C2=A0

Is this more clear? If yes, I will try to clarify in text= .=C2=A0

=C2=A0

[JLS] That is not where I was having a problem.=C2=A0 I= was getting confused by the figure itself.=C2=A0 Labeling the figure bette= r might help.=C2=A0 =E2=80=9CMQTT V5.0 CONNECT control message with =E2=80= =98ace=E2=80=99 authentication method=E2=80=9D.=C2=A0 I would rather not ha= ve all of the abbreviations in the title, but I can live with it.=

=C2=A0


8.=C2=A0 If the value of Clean Start or= Expiry Interval are not set correct is
the server to fail the connect?<= u>

=C2=A0<= /u>

>> Agreed. This should be sp= ecified.=C2=A0

Two optio= ns: 1) Do not accept connection or 2) accept the connection but then never = create sessions, and then server=C2=A0=C2=A0MUST set Session= Present to 0 in the CONNACK packet, indicating=C2=A0<= /p>

no session is present.= =C2=A0

=C2= =A0

This basically makes Clean = Start flag meaningless.=C2=A0

If this is better than client MUST be setting those parameters correc= tly, then we can go this way.=C2=A0

Any thoughts?

= =C2=A0

[JLS] I don=E2=80=99t really care o= ne way or the other.=C2=A0 Given that there is the return value in the CONN= ACK, I think that a simple statement that the flag is set to 0 regardless o= f the value coming in.=C2=A0

=C2=A0


10. Section 2.1.2.1 - I am having a= problem computing the MAC over the
payload of the CONNECT message.=C2= =A0 The password where the value is placed is
included in the payload an= d I am not clear if it should be computed up to
that value or if a fixed= value should be used for the computation.

=C2=A0

>>OK. I think it got muddled because I was trying to find a = solution for a scenario where the ClientId is used across sessions, and hen= ce, not random.=C2=A0

=C2=A0

Two cases.

1) Client ID uniquely random acr= oss each Client connection attempt to Broker: MAC over Payload - Payload be= gins with ClientID and MAY include Will Properties if Client indicated that= it will have a will.=C2=A0

2) Client ID NOT uniquely random: MAC over Authentication Data.=C2=A0

=C2=A0

<= /div>

It may be best to choose one method and ju= st say MUST always have a nonce in Authentication Data, and MAC is computed= over that?

=C2=A0

[JLS] Lets step back and look at the problem I thin= k you are trying to solve.=C2=A0 =C2=A0=C2=A0

  • If you are try= ing to make sure that there is not a replay of the signature, then this wou= ld require that the server keep track of the list of nonce values that the = client has provided.
  • =C2= =A0If you are trying to make sure that the signature is =E2=80=9Cfresh=E2= =80=9D then the server would need to be able to provide some type of data a= s part of the value being signed.=C2=A0 As I think I have said before the l= atter can be satisfied by getting your nonce value from the TLS session usi= ng a tls-exporter.

=C2=A0

If neither of these problem= s is trying to be solved, then there is no need for the nonce at all.

=C2=A0

=C2=A0

11. I am worried about the text on the Client Identifier= in this section.
It is not clear to me that having the client generate = a random value for
this field is good just in terms of the possibility o= f collisions occurring
on the server.=C2=A0 The text in the MQTT 5.0 doc= ument appears to say that this
is more interesting for the situation of = getting back state that was left on
the server after a disconnect and no= t so much for a clean session.

=C2=A0

&g= t;> Yes, but as I explained for comment 7, in MQTT, the typical case is = the client provides its id.=C2=A0

However, to cater to all requirements and all implementation poss= ibilities, maybe it is best to just use a nonce as explained for comment 10= and not tie anything to client id.

=C2=A0

Previ= ously, when we were writing the draft for MQTT v3.1.1 we wanted to provide = a solution that uses the available fields in the CONNECT packet as much as = possible; without

introd= ucing any new fields. This was because of the constraints of the MQTT v3.1.= 1. MQTT v5 gives us more options to implement this better.

=C2=A0

For backward compatibility, we would need to think if we = create a special data structure to be used in the password so that it holds= both the MAC/signature and the nonce.=C2=A0 =C2=A0

=

=C2=A0

As the use of ClientId seems to create confusion, I am leaning t= owards this solution. Any thoughts?

=C2=A0

[JLS] Look at the previous = answer and the re-ask the question.

=C2=A0

=C2=A0

13. Is there someplace that authentication methods= need to be registered?=C2=A0 I
was unable to see any such registry setu= p with OASIS from the v5
specification.=C2=A0 Should we suggest to the M= QTT group that this is something
that should be done?

<= /blockquote>

=C2=A0

=

>> This is an interesting thought. The draft w= as indeed discussed in the OASIS MQTT WG.=C2=A0

=C2=A0

But, the WG may consider this out of scope, as they have on their ch= arter page:

=C2=A0Transpor= t level security is assumed and no mandatory security features will be adde= d.

The MQTT v5 dr= aft says:

The Authenticatio= n Method is commonly a SASL mechanism, and using such a registered name aid= s interchange. However, the Authentication Method is not constrained to usi= ng registered SASL mechanisms.

=C2=A0

[JLS] I think tha= t the lack of a registry should be identified someplace in the document.=C2= =A0 This is probably a security consideration that there might be a differe= nt authentication method which re-uses the same authentication method name.=

=C2=A0

=C2=A0

17.=C2=A0 It is not c= lear to me, how in the scope string is the ability to have a
"will&= quot; indicated?

>>=C2=A0If the Will Flag is set to 1, the Will Topic follows the Client= ID and Will Properties in the Payload.

=

This is where the broker learns the Will Topic.=C2=A0

Then the scope would = be publish_<will topic>.=C2=A0

And subscribes would need to subscribe_<will topic> = to receive this message.=C2=A0

Will clarify in text.

=C2=A0

[JLS] publish makes sense to m= e.=C2=A0 I was just being overly complicated.

<= p class=3D"MsoNormal">=C2=A0

=

18.=C2=A0 Section 2.1.4= - I am unsure what the implications of discarding tokens
on the end of = a connection are going to be.=C2=A0 How do you publish the token
before = doing the connection or is that only for an updated token?

=C2=A0

>> Tokens are discarded at the end of discon= nection because no previous session state is kept.

<= div>

And a token is expected in the new CONNECT reque= st (otherwise, it is AS discovery)

=C2=A0

Before= the connection, a token may be transported via=C2=A0 "authz-info"= ; topic described in Appendix B.=C2=A0

During the connection, a new token may be transported via th= e AUTH packet - which enables reauthentication.=C2=A0

=C2=A0

[JLS] Thi= s is still not clear to me.=C2=A0 Is the transport of the token via =E2=80= =9Cauth-info=E2=80=9D topic not considered to be part of the session?=C2=A0= If you say that you look at just the last value published, then is there n= ot going to be a race condition between two different clients trying to pub= lish and connect?=C2=A0

=C2= =A0


20.= =C2=A0 I am not sure what the benefits of doing the check on a PINGREQUEST = is
going to be.=C2=A0 Like the relay of a PUBLISH message this is just g= oing to
produce a DISCONNECT and a closed channel.=C2=A0 If this is real= ly allowed, then
you should potentially also say that the Broker could d= o a check based on
clock time elapsing.=C2=A0 (I.e. do the check every h= our.)

=C2= =A0

>> This was suggested= by one of the reviewers that provide MQTT services (his e-mail regarding t= his was sent to the ace list).=C2=A0

It was suggested as an optimization for detecting token expi= rations and disconnecting early.=C2=A0

(i.e., if you are already receiving PINGREQUESTs, use these = as a trigger to check the token).=C2=A0

I think time-based checks may also help and be added as an = option.

=C2=A0

[JLS] Ok

=C2=A0


22. Not sure if this goes here or in the connect documentation.= =C2=A0 There needs
to be a check that the will topic is a topic that the= client is going to be
permitted to publish on.=C2=A0 =C2=A0Corner case,= if the ability to publish a will in
the event that this permission is l= ost.=C2=A0 Does this kill the session or the
will message?=C2=A0 I.e. sh= ould the permission for the will message be rechecked
before sending it = allowing for the time based expiration of the token.

=C2=A0

>> We have been thinking about this.=C2=A0<= u>

If the disconnect is due to a t= oken expiration, and hence, also includes the will topic as well, you have = to decide between:

1) pu= blish the will

2) do not= publish the will.=C2=A0

At the moment, it's written like we publish the will - but on second c= onsideration,=C2=A0

it s= eems safer to say "Publish the Will on Server Disconnect or unusual di= sconnect if the token (the will permission) has not expired".=C2=A0=

=C2=A0

[JLS] I would be fine with either position, after all at the time= the =E2=80=9Cpublish=E2=80=9D event occurred the token was valid, this is = just deferring relaying it to subscribers.=C2=A0

=C2=A0

Jim=

=C2=A0

=C2=A0

Th= anks again for these comments, will create the necessary github issues and = start revising the text.=C2=A0

=C2=A0

Best,=C2= =A0

=C2=A0=


Jim


=






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

__________________________________= _____________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
--00000000000062352f05962302a4-- From nobody Wed Oct 30 09:21: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 4830512080D; Wed, 30 Oct 2019 09:21:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bjr8KOQ4OaKS; Wed, 30 Oct 2019 09:21:49 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78AB51202DD; Wed, 30 Oct 2019 09:21:46 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 30 Oct 2019 09:21:36 -0700 From: Jim Schaad To: 'Cigdem Sengul' , 'Daniel Migault' CC: , References: <021c01d5839c$d53206a0$7f9613e0$@augustcellars.com> <033101d5851b$30a41ad0$91ec5070$@augustcellars.com> In-Reply-To: Date: Wed, 30 Oct 2019 09:21:34 -0700 Message-ID: <001f01d58f3e$1b067510$51135f30$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0020_01D58F03.6EAC7F10" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHeJBV4idO7pcqKU2roj2JuYf+CkgKdQ7UQAZHW23kCdkW7xQGdierupyAcTAA= Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Ace] Review for draft-ietf-ace-mqtt-tls-profile-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: Wed, 30 Oct 2019 16:21:56 -0000 ------=_NextPart_000_0020_01D58F03.6EAC7F10 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Just one quick comment below =20 From: Cigdem Sengul =20 Sent: Wednesday, October 30, 2019 9:13 AM To: Daniel Migault Cc: Jim Schaad ; ace@ietf.org; = draft-ietf-ace-mqtt-tls-profile@ietf.org Subject: Re: [Ace] Review for draft-ietf-ace-mqtt-tls-profile-01 =20 Thank you for your comments Daniel (prefixed [CS]) My comments are inside. I've also created the -v-02-WIP branch for the = work in progress based on your and Jim's comments.=20 =20 On Thu, Oct 24, 2019 at 2:50 AM Daniel Migault = > wrote: HI,=20 =20 Thanks for sending an update. Please find my comments of the draft.=20 =20 This document makes the same assumptions as the Section 4 of the ACE framework [I-D.ietf-ace-oauth-authz] regarding Client and RS registration with the AS and establishing of keying material. The document seems mostly focuses on the latest version of MQTT, I am wondering if we could encourage similarly the use of the latest version of TLS that is 1.3 at the time of writing. It seems AS as not been defined previously, so maybe it should be expanded there.=20 =20 =20 [CS] Can add a similar recommendation for TLS 1.3.=20 AS is expanded.=20 =20 =20 =20 MQTTS Secured transport profile of MQTT. MQTTS runs over TLS. The Server in MQTT acts as an intermediary between Clients that publishes Application Messages, and the Clients that made Subscriptions. The Broker acts as the Resource Server for the Clients. publishes [CS] Fixed. =20 =20 =20 Subscription A subscription comprises a Topic Filter and a maximum Quality of Service (QoS). Maybe that would be clearer to specify QoS level as well. =20 [CS] Added.=20 =20 =20 PINGREQ A ping request sent from a Client to the Broker. It signals to the Broker that the Client is alive, and is used to confirm that the Broker is still alive. It may look a bit strange to have PINGREQ without PINGRESP. You might also indicate the keep alive period is provided in the = CONNECT =20 [CS] Added PINGRESP, clarified the Keep Alive period is set in the = CONNECT in the definition of PINGREQ.=20 =20 Will An application message published by the Server after the network connection is closed in cases where the network connection is not closed normally. If the Will Flag is set, then the payload of the CONNECT message has information about the Will. The Will consists of the Will Properties, Will Topic, and Will Payload fields in the CONNECT message. The first sentence seems to be related to the Will message while the intent, I suppose of teh definition was to define the generic conpet of Will. It might be clearer to expose the principle of the wil, that is a server sends a given message in case a client is disconnected improperly. It might be clearer to mention explicitly there is a Will "concept" that is implemented a WillFlag WillQoS, WillRetain in the CONNECT header as well as other Will Properties and Will Messages. This mostly consists in the last sentence being moved up. =20 =20 [CS] I reworded it - let me know if it is more clear.=20 =20 2. Protocol Interactions This section describes the following exchanges between Clients, the Broker, and the Authorization Server according to the MQTT v5.0. Though english is not my first language, I have the impression = the text can be interpreted as MQTT enables clients to establish session which does not seems correct to me. The text that follows clarifies this as well. =20 =20 [CS] Neither mine, I reworded that as: "Authorizing connection requests = from the Clients to the Broker" Actually, I also went through the text to reword "establishment" to = set-up which is simpler.=20 =20 =20 2.1. Authorizing Connection Establishment =20 If the Client is resource-constrained, a Client Authorisation Server may I have the impression an AS would be sufficient. =20 [CS] Client Authorization Server was the terminology used in the Actors = draft - I've removed all other references but wanted to distinguish that = this is separate than the AS granting access tokens.=20 Can just say client's AS?=20 carry out the token request on behalf of the Client, and later, onboard the Client with the token. Also, these interfaces may be implemented using other protocols, e.g., CoAP or MQTT.=20 While the introduction and the figure mentions that HTTPS is used as a transport, it might be worth mentioning that HTTPS is being used. I propose to add "...other protocols than HTTPS, e.g ... =20 [CS] Added.=20 =20 =20 2.1.1. Client Token Request to the Authorization Server (AS) The first step in the protocol flow (Figure 1 (A)) is the token acquisition by the Client from the AS. When requesting an access token from the AS, the Client MAY include parameters in its request as defined in Section 5.6.1 of the ACE framework [I-D.ietf-ace-oauth-authz]. The media format is 'application/ ace+json'. The profile parameter MUST be set to 'mqtt_tls'. The OAuth 2.0 AS uses a JSON structure in the payload of its responses both to client and RS. I understand that some parameters are mandatory while other are not. I believe it might be clearer to start with the mandatory parameters (MUST) and then mention that other parameters are optional (MAY). That said, it might be simpler, if that is correct to mention that the token request is as described in Section 5.6.1 of the ACE = framework [I-D.ietf-ace-oauth-authz] with the profile set to "mqtt".=20 =20 [CS]=20 When requesting an access token from the AS, the Client follows the = token request as is described in Section 5.6.1 of the ACE framework, however, it MUST set = the profile parameter to 'mqtt_tls'.=20 =20 =20 In the case of an error, the AS returns error responses for HTTP- based interactions as ASCII codes in JSON content, as defined in Section 5.2 of RFC 6749 [RFC6749]. Error messages are handled by OAuth2.0 instead of the ACE framework in order to keep JSON format. I am wondering why do we have the requirement to use ace+cbor only for error message ? It seems to me a bit strange to have error handling defined in another document. [CS] Should keep as-is for the time being?=20 =20 2.1.2. Client Connection Request to the Broker (C) This section describes how the Client transports the token to the Broker (RS) via the CONNECT control message after the TLS handshake. If the TLS handshake has already been performed, it would be good to mention which credentials have been used. Obviously, if the token is provided by the CONNECT message, I expect other credentials to be involved. =20 [CS] TLS handshake uses only server-side certificate or RPK. I think = this is in the text.=20 That said there is a Github issue #16 = https://github.com/ace-wg/mqtt-tls-profile/issues/16 around this, and will provide other clarifications as Jim asked.=20 This is similar to an earlier proposal by Fremantle et al. [fremantle14]. Alternatively, the token may be used for the TLS session establishment as described in the DTLS profile for ACE [I-D.gerdes-ace-dtls-authorize]. In this case, both the TLS PSK and RPK handshakes MAY be supported.=20 It would be good to expand Raw Public Keys (RPK). My reading is that this section does not provide a single mechanism for the Client to be authenticated by the Broker, but instead two different ways. I would thus recommend to state it clearly in the introduction of the section.. Currently, the section mentions: """ This section describes how the Client transports the token to the Broker (RS) via the CONNECT control message after the TLS handshake. """ An then we have a relatively detailed description on how this is performed using TLS. It might be better to say something around the following lines: """ This section describes how the Client transports the token to the Broker (RS). This can be achieved during the TLS KEX or during the MQTT session establishment via the CONNECT control message after the TLS = handshake. """ I am not sure that MAY is appropriated here. I suspect that if none are supported, this method will not work. As a result, if seems to me that it woudl be more accurate to say that TLS Client and TLS server MUST support the PSK authentication as well as the raw public key.=20 One issue I have with I-D.gerdes-ace-dtls-authorize that is now draft-ietf-ace-dtls-authorize is that it seems to only consider TLS 1.2. With TLS 1.3 PSK and RPK are supported.=20 My interpretation is that PSK provides mutual authentication, but in our case RPK will only authenticate the client. If that is correct, there might be a new to specify how the RS is authenticated by the Client.=20 =20 [CS] I will actually reorganize this section, and hence, this will be = more clear.=20 Added your comment to issue #29, acknowledge that it is linked to #16 as = well.=20 =20 I was trying to say the following, but I see that the text is not clear = on that: - MUST: TLS with server validation + token in MQTT CONNECT (will clarify = server-side certificate/RPK) - MAY: TLS with server/client validation with RPK -> token pushed to = "authz-info" - MAY: TLS with server/client validation with PSK -> token in = psk_identity =20 This option is described in more detail in Appendix B. see my comment in annex B. =20 =20 [CS] OK.=20 =20 After the token acquisition, the Client connects to the RS (Broker) using the CONNECT message of MQTT over TLS. For server authentication, the client MAY either have the ability to receive and validate a certificate or a raw public key from the Broker. =20 I might have missed something, but I thought that PSK/RPK were used to authenticate the Client. While in this case the RPK is used to authenticate the RS, is that the same RPK provided by the AS or another one? =20 [CS] No the RPK was suggested for the RS/Broker authentication.=20 As in the core ACE document, we assumed that the client learned either = the RS's public key from the AS. However, I haven't seen in the core document an example of = how AS=20 returns this information to the client.=20 =20 [JLS] This is done using the =E2=80=98rs_cnf=E2=80=99 field =20 =20 =20 For token transport, the RS SHOULD support AUTH (Authentication Exchange) method. The RS MAY support token transport via username and password, which is described in Section 3 for MQTT v3.1.1. The rest of this section describes the AUTH method, for which the username and password flags MUST be set to 0. Maybe the reference should be for MQTTv5 instead of MQTTv3.=20 I believe it would be good to specify how setting the password flag interacts with the Authentication method.=20 =20 =20 [CS] Do you suggest that if AUTH method is used, MQTTv5 ignores = password/username? =20 =20 =20 2.1.2.1. Proof-of-Possession over Predefined Field For this option, the Authentication Data MUST contain the token and the keyed message digest (MAC) or the Client signature. To calculate the keyed message digest (MAC) or the Client signature, the Client SHOULD apply the PoP key to the CONNECT payload.=20 I have the impression the latest sentence indicates that the Authenticated Data is include din the CONNECT payload. I have however the impression that Authenticated Data is part of the properties which are include din the variable header and not the payload. =20 =20 =20 [CS]=20 No, the CONNECT payload only includes Client Identifier, Will = Properties, Will Topic, Will Payload, User Name, Password. AUTH data is variable header part of the CONNECT message.=20 Anyway, based on also Jim's input, using payload to do the PoP will be = dropped.=20 Jim suggested we use a nonce from the tls_exporter, and apply PoP to = that.=20 We believe that is the better approach as well. These are related to = issues #15 ( https://github.com/ace-wg/mqtt-tls-profile/issues/15) and = #19 (https://github.com/ace-wg/mqtt-tls-profile/issues/19).=20 =20 =20 The CONNECT payload has at least a Client Identifier, and if the Will Flag is set to 1, may contain Will-related information. The Client Identifier is a MUST be a UTF-8 Encoded String (i.e., is prefixed with a two-byte integer length field that gives the number of bytes in a UTF-8 encoded string itself). The Client Identifier may be 1-23 UTF-8 encoded bytes, and contain only the characters "0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ". For my information I would like to understand the mention of UTF8 while only ascii characters are permitted. It seems that teh server MUST accept these and MAY accept others as well as a longer client id. Am I correct ?=20 The nonce coded this way has a randomness of 62**23 =3D2**138 =3D 17 = bytes =20 [CS] This section will be changed anyway... However, need to familiarize = to specify how to use Exporter Labels. =20 (Server can accept other characters.) =20 2.1.4. The Broker's Response to Client Connection Request If the RS accepts the connection, it MUST store the token until the end of connection. On Client or RS disconnection, the token is discarded, and the Client MUST provide a token inside each CONNECT message. The latest sentence is unclear to me. I think that disconnection can be interpreted in two way: 1) the disconnection of the will or a DISCONNECT. I believe both are considered. =20 [CS] Either Client or Server may initiate a disconnection. In either = case, the token is discarded. The will may be sent if the client set up a will in case of unexpected = disconnection. =20 Though it needs to be clarified for instance, if there are retained = messages, these are sent as long as the token is valid.=20 Since the introspection results are cached, this can be still done but = should clarify unless it gets confusing.=20 =20 To avoid any confusion, and not to have to discuss these things in that = section, I reworded as:=20 On Client or RS disconnection, the Client is expected to provide a token = again inside the next CONNECT message. =20 =20 If the token is not self-contained and the Broker uses token introspection, it MAY cache the validation result to authorize the subsequent PUBLISH and SUBSCRIBE messages. PUBLISH and SUBSCRIBE messages, which are sent after a connection set-up, do not contain access tokens. If the introspection result is not cached, then the RS needs to introspect the saved token for each request. The Broker SHOULD use a cache time out to introspect tokens regularly. The latest sentence seems to indicate that result provided as via introspection do not necessarily have a Time to Live which could be interpreted as a commitment from the AS to authorize during that period. If that is possible, it would be appropriated this time out is provided by the AS. I am also wondering why the token expiration cannot be considered as well. =20 =20 [CS] This is to handle the situation where the resource owner changes = the permissions of the Client, which would revoke the token. And hence the token exp field would not help. If the RS does not check the token introspection results, it=20 will use the token until its expiration time.=20 I've considered this more appropriate to be set by the RS as its RS risk = management.=20 =20 =20 Appendix B. The Authorization Information Endpoint The main document described a method for transporting tokens inside MQTT CONNECT messages. In this section, we describe an alternative method to transport an access token. The method consists of the MQTT Broker accepting PUBLISH messages to a public "authz-info" topic. A Client using this method MUST first connect to the Broker, and publish the access token using the "authz- info" topic. The Broker must verify the validity of the token (i.e., through local validation or introspection). After publishing the token, the Client disconnects from the Broker and is expected to try reconnecting over TLS. I understand this as an open channel for CONNECT and sending PUBLISHING message. This potentially open the door for DoSing the RS either by openning too many MQTT sessions or by sending too many tokens. I expect this to be mentioned in the security consideration section as well as potential mechanisms to limit these risks.=20 =20 [CS] It is indeed mentioned in this paragraph in the security = consideration section.=20 "The RS may monitor Client behaviour to detect potential security = problems, especially those affecting availability. These include repeated token transfer attempts to the public = "authz-info" topic, repeated connection attempts, abnormal terminations, and Clients that connect but do not send any = data. If the RS supports the public "authz-info" topic, described in Appendix = B, then this may be vulnerable to a DDoS attack, where many Clients use = the "authz-info" public topic to transport fictitious tokens, which RS may need to store = indefinitely." =20 =20 Thank you for your comments. And will try to address Jim's shortly to be = able to push another version before the deadline.=20 =20 Kind regards,=20 --Cigdem=20 =20 =20 =20 On Thu, Oct 17, 2019 at 2:47 PM Jim Schaad > wrote: =20 =20 From: Cigdem Sengul >=20 Sent: Thursday, October 17, 2019 4:13 AM To: Jim Schaad > Cc: draft-ietf-ace-mqtt-tls-profile@ietf.org = ; ace@ietf.org = =20 Subject: Re: [Ace] Review for draft-ietf-ace-mqtt-tls-profile-01 =20 Hello Jim, Thanks for this review. I have responded inline.=20 1. Are there any specifics about using ACE over HTTP that need to be explicitly stated some place. Some of these things might include: a) Must be HTTPS even if encrypted requests/responses are = provided.=20 b) What types of validation are permitted/required: anon-anon, server validation, server & client validation. The latter corresponds to current DTLS statements. =20 c) Are we looking for using the normal HTTP/HTTPS ports or = should we be using different ports? =20 =20 >> Agreed. Need to specify that it is HTTPS. Mutual authentication and server validation Required.=20 Was thinking it would be normal HTTPS ports. Should we consider = different? What scenarios should permit anon-anon; anon clients?=20 =20 [JLS] If you look at my last email I went through this. Anon-anon is = going to be a bad idea because the server is never validated, however = client anon is fine since you are going to validate the client in the = MQTT protocol.=20 =20 =20 4. Section 2.1.2: It is not clear from the document is a Broker is = going to also have the possibility of doing a post of the token via HTTPS. = Currently I would think not, but given that this is documented in OAuth 2.0 as an option I am not clear. >> Do you mean for introspection? Yes, this is a MAY as in the core = document, and so in this one too.=20 And if there is an RS-AS interaction, we expect that to be on HTTPS.=20 I will try to see where I should clarify in the text.=20 =20 [JLS] No, I was originally looking at doing an HTTPS post of the token = from the client to the RS. This was before I figured out that you have = an alternative method of doing this in the MQTT protocol and so it = should not be needed. Being clear on the fact that this would not be = expected is probably a good idea. =20 7. In Figure 2, I think the use of Client Identifier is somewhat confusing. I think this is supposed to be the token as the Client Identifier is a different thing in MQTT. Either that or you need to do = a better job of describing the property block. =20 OK. I think I should explain MQTT packets better.=20 A connect packet has three parts: 1) Fixed header 2) Variable Header and = 3) Payload. The variable header may have several properties, and Authentication = Method and Authentication Data are two of these properties.=20 According to MQTT Specification: The ClientID MUST be present and is the first field in the CONNECT = packet Payload.=20 The ClientID MUST be a UTF-8 Encoded String A Server MAY allow a Client to supply a ClientID that has a length of = zero bytes, however, if it does so the Server MUST treat this as a = special case. =20 And this is what is done in the case of a collision: If the ClientID represents a Client already connected to the Server, the = Server sends a DISCONNECT packet to the existing Client with Reason Code = of 0x8E (Session taken over)=20 =20 Is this more clear? If yes, I will try to clarify in text.=20 =20 [JLS] That is not where I was having a problem. I was getting confused = by the figure itself. Labeling the figure better might help. = =E2=80=9CMQTT V5.0 CONNECT control message with =E2=80=98ace=E2=80=99 = authentication method=E2=80=9D. I would rather not have all of the = abbreviations in the title, but I can live with it. =20 8. If the value of Clean Start or Expiry Interval are not set correct = is the server to fail the connect? =20 >> Agreed. This should be specified.=20 Two options: 1) Do not accept connection or 2) accept the connection but = then never create sessions, and then server MUST set Session Present to = 0 in the CONNACK packet, indicating=20 no session is present.=20 =20 This basically makes Clean Start flag meaningless.=20 If this is better than client MUST be setting those parameters = correctly, then we can go this way.=20 Any thoughts? =20 [JLS] I don=E2=80=99t really care one way or the other. Given that = there is the return value in the CONNACK, I think that a simple = statement that the flag is set to 0 regardless of the value coming in. =20 =20 10. Section 2.1.2.1 - I am having a problem computing the MAC over the payload of the CONNECT message. The password where the value is placed = is included in the payload and I am not clear if it should be computed up = to that value or if a fixed value should be used for the computation. =20 >>OK. I think it got muddled because I was trying to find a solution for = a scenario where the ClientId is used across sessions, and hence, not = random.=20 =20 Two cases. 1) Client ID uniquely random across each Client connection attempt to = Broker: MAC over Payload - Payload begins with ClientID and MAY include = Will Properties if Client indicated that it will have a will.=20 2) Client ID NOT uniquely random: MAC over Authentication Data.=20 =20 It may be best to choose one method and just say MUST always have a = nonce in Authentication Data, and MAC is computed over that? =20 [JLS] Lets step back and look at the problem I think you are trying to = solve. =20 * If you are trying to make sure that there is not a replay of the = signature, then this would require that the server keep track of the = list of nonce values that the client has provided.=20 * If you are trying to make sure that the signature is = =E2=80=9Cfresh=E2=80=9D then the server would need to be able to provide = some type of data as part of the value being signed. As I think I have = said before the latter can be satisfied by getting your nonce value from = the TLS session using a tls-exporter. =20 If neither of these problems is trying to be solved, then there is no = need for the nonce at all. =20 =20 11. I am worried about the text on the Client Identifier in this = section. It is not clear to me that having the client generate a random value for this field is good just in terms of the possibility of collisions = occurring on the server. The text in the MQTT 5.0 document appears to say that = this is more interesting for the situation of getting back state that was = left on the server after a disconnect and not so much for a clean session. =20 >> Yes, but as I explained for comment 7, in MQTT, the typical case is = the client provides its id.=20 However, to cater to all requirements and all implementation = possibilities, maybe it is best to just use a nonce as explained for = comment 10 and not tie anything to client id. =20 Previously, when we were writing the draft for MQTT v3.1.1 we wanted to = provide a solution that uses the available fields in the CONNECT packet = as much as possible; without introducing any new fields. This was because of the constraints of the = MQTT v3.1.1. MQTT v5 gives us more options to implement this better. =20 For backward compatibility, we would need to think if we create a = special data structure to be used in the password so that it holds both = the MAC/signature and the nonce. =20 =20 As the use of ClientId seems to create confusion, I am leaning towards = this solution. Any thoughts? =20 [JLS] Look at the previous answer and the re-ask the question. =20 =20 13. Is there someplace that authentication methods need to be = registered? I was unable to see any such registry setup with OASIS from the v5 specification. Should we suggest to the MQTT group that this is = something that should be done? =20 >> This is an interesting thought. The draft was indeed discussed in the = OASIS MQTT WG.=20 =20 But, the WG may consider this out of scope, as they have on their = charter page: Transport level security is assumed and no mandatory security features = will be added. The MQTT v5 draft says: The Authentication Method is commonly a SASL mechanism, and using such a = registered name aids interchange. However, the Authentication Method is = not constrained to using registered SASL mechanisms. =20 [JLS] I think that the lack of a registry should be identified someplace = in the document. This is probably a security consideration that there = might be a different authentication method which re-uses the same = authentication method name. =20 =20 17. It is not clear to me, how in the scope string is the ability to = have a "will" indicated?=20 >> If the Will Flag is set to 1, the Will Topic follows the Client ID = and Will Properties in the Payload. This is where the broker learns the Will Topic.=20 Then the scope would be publish_.=20 And subscribes would need to subscribe_ to receive this = message.=20 Will clarify in text. =20 [JLS] publish makes sense to me. I was just being overly complicated. =20 18. Section 2.1.4 - I am unsure what the implications of discarding = tokens on the end of a connection are going to be. How do you publish the = token before doing the connection or is that only for an updated token? =20 >> Tokens are discarded at the end of disconnection because no previous = session state is kept. And a token is expected in the new CONNECT request (otherwise, it is AS = discovery) =20 Before the connection, a token may be transported via "authz-info" = topic described in Appendix B.=20 During the connection, a new token may be transported via the AUTH = packet - which enables reauthentication.=20 =20 [JLS] This is still not clear to me. Is the transport of the token via = =E2=80=9Cauth-info=E2=80=9D topic not considered to be part of the = session? If you say that you look at just the last value published, = then is there not going to be a race condition between two different = clients trying to publish and connect? =20 =20 20. I am not sure what the benefits of doing the check on a PINGREQUEST = is going to be. Like the relay of a PUBLISH message this is just going to produce a DISCONNECT and a closed channel. If this is really allowed, = then you should potentially also say that the Broker could do a check based = on clock time elapsing. (I.e. do the check every hour.) =20 >> This was suggested by one of the reviewers that provide MQTT services = (his e-mail regarding this was sent to the ace list).=20 It was suggested as an optimization for detecting token expirations and = disconnecting early.=20 (i.e., if you are already receiving PINGREQUESTs, use these as a trigger = to check the token).=20 I think time-based checks may also help and be added as an option. =20 [JLS] Ok =20 22. Not sure if this goes here or in the connect documentation. There = needs to be a check that the will topic is a topic that the client is going to = be permitted to publish on. Corner case, if the ability to publish a will = in the event that this permission is lost. Does this kill the session or = the will message? I.e. should the permission for the will message be = rechecked before sending it allowing for the time based expiration of the token. =20 >> We have been thinking about this.=20 If the disconnect is due to a token expiration, and hence, also includes = the will topic as well, you have to decide between: 1) publish the will 2) do not publish the will.=20 At the moment, it's written like we publish the will - but on second = consideration,=20 it seems safer to say "Publish the Will on Server Disconnect or unusual = disconnect if the token (the will permission) has not expired".=20 =20 [JLS] I would be fine with either position, after all at the time the = =E2=80=9Cpublish=E2=80=9D event occurred the token was valid, this is = just deferring relaying it to subscribers. =20 =20 Jim =20 =20 Thanks again for these comments, will create the necessary github issues = and start revising the text.=20 =20 Best,=20 =20 Jim _______________________________________________ Ace mailing list Ace@ietf.org =20 https://www.ietf.org/mailman/listinfo/ace _______________________________________________ Ace mailing list Ace@ietf.org =20 https://www.ietf.org/mailman/listinfo/ace _______________________________________________ Ace mailing list Ace@ietf.org =20 https://www.ietf.org/mailman/listinfo/ace ------=_NextPart_000_0020_01D58F03.6EAC7F10 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Just one = quick comment below

 

From: = Cigdem Sengul <cigdem.sengul@gmail.com>
Sent: = Wednesday, October 30, 2019 9:13 AM
To: Daniel Migault = <daniel.migault=3D40ericsson.com@dmarc.ietf.org>
Cc: Jim = Schaad <ietf@augustcellars.com>; ace@ietf.org; = draft-ietf-ace-mqtt-tls-profile@ietf.org
Subject: Re: [Ace] = Review for draft-ietf-ace-mqtt-tls-profile-01

 

Thank you for your comments Daniel (prefixed = [CS])

My comments are inside. = I've also created the -v-02-WIP branch for the work in progress based on = your and Jim's comments. 

 

On = Thu, Oct 24, 2019 at 2:50 AM Daniel Migault <daniel.migault=3D40ericsson.com@dmarc.ietf.o= rg> wrote:

HI, 

 

Thanks for sending an update. Please find my comments = of the draft. 

 

   This document makes the same assumptions = as the Section 4 of the ACE
   framework = [I-D.ietf-ace-oauth-authz] regarding Client and RS
  =  registration with the AS and establishing of keying = material.

<mglt> The document seems mostly focuses on the = latest version of MQTT,
I am wondering if we could encourage = similarly the use of the latest
version of TLS that is 1.3 at the = time of writing.

It seems AS as not been defined previously, so = maybe it should be
expanded there. =
</mglt> 

 

[CS] Can add a similar recommendation for TLS = 1.3. 

AS is = expanded. 

 

 

 

   MQTTS
        =    Secured transport profile of MQTT.  MQTTS runs over = TLS.
           The Server in MQTT acts = as an intermediary between
          =  Clients that publishes Application Messages, and the = Clients
           that made = Subscriptions.  The Broker acts as the Resource
    =        Server for the = Clients.

<mglt>publishes</mglt>

[CS] = Fixed.

 

 

 

   Subscription
      =      A subscription comprises a Topic Filter and a = maximum Quality
           of Service = (QoS).

<mglt>Maybe that would be clearer to specify QoS = level as = well.</mglt>

 

[CS] Added. 

 

 

   PINGREQ
        =    A ping request sent from a Client to the Broker.  It = signals
           to the Broker that = the Client is alive, and is used to
        =    confirm that the Broker is still = alive.

<mglt>It may look a bit strange to have PINGREQ = without PINGRESP. You
might also indicate the keep alive period is = provided in the = CONNECT</mglt>

 

[CS] Added PINGRESP, clarified the Keep Alive period = is set in the CONNECT in the definition of = PINGREQ. 

 


   Will
        =    An application message published by the Server after = the
           network connection is = closed in cases where the network
          =  connection is not closed normally.  If the Will Flag is = set,
           then the payload of the = CONNECT message has information about
        =    the Will.  The Will consists of the Will Properties, = Will
           Topic, and Will Payload = fields in the CONNECT message.

<mglt>
The first sentence = seems to be related to the Will message while the
intent, I suppose = of teh definition was to define the generic conpet of
Will. It might = be clearer to expose the principle of the wil, that is a
server sends = a given message in case a client is disconnected
improperly.   = It might be clearer to mention explicitly there is a = Will
"concept" that is implemented a WillFlag WillQoS, = WillRetain in the
CONNECT header as well as other Will Properties and = Will Messages. This
mostly consists in the last sentence being moved = up. =  
</mglt>

 

[CS] I reworded it - let me know if it is more = clear. 

 

2.  Protocol Interactions

  =  This section describes the following exchanges between Clients, = the
   Broker, and the Authorization Server according to = the MQTT v5.0.

<mglt> Though english is not my first = language, I have the impression the
text can be interpreted as MQTT = enables clients to establish session
which does not seems correct to = me. The text that follows clarifies this
as well. =  
</mglt>

 

[CS] Neither mine, I reworded that as: = "Authorizing connection requests from the Clients to the = Broker"

Actually, I = also went through the text to reword "establishment" to set-up = which is simpler. 

 

 

2.1.  Authorizing Connection = Establishment

 

If the
   Client is resource-constrained, = a Client Authorisation Server may

<mglt>I have the = impression an AS would be = sufficient.</mglt>

 

[CS] Client Authorization Server was the terminology = used in the Actors draft - I've removed all other references but wanted = to distinguish that this is separate than the AS granting access = tokens. 

Can just say = client's AS? 


   carry out the token request on behalf = of the Client, and later,
   onboard the Client with the = token.  Also, these interfaces may be
   implemented = using other protocols, e.g., CoAP or MQTT.
<mglt>While the = introduction and the figure mentions that HTTPS is used
as a = transport, it might be worth mentioning that HTTPS is being used. = I
propose to add "...other protocols than HTTPS, e.g = ...
</mglt>

 

[CS] Added. 

 

 

2.1.1.  Client Token Request to the Authorization = Server (AS)

   The first step in the protocol flow = (Figure 1 (A)) is the token
   acquisition by the Client = from the AS.  When requesting an access
   token from = the AS, the Client MAY include parameters in its request
  =  as defined in Section 5.6.1 of the ACE framework
  =  [I-D.ietf-ace-oauth-authz].  The media format is = 'application/
   ace+json'.  The profile parameter = MUST be set to 'mqtt_tls'.  The
   OAuth 2.0 AS uses a = JSON structure in the payload of its responses
   both to = client and RS.

<mglt> I understand that some parameters are = mandatory while other are
not. I believe it might be clearer to start = with the mandatory
parameters (MUST) and then mention that other = parameters are optional
(MAY). That said, it might be simpler, if = that is correct to mention
that the token request is as described in = Section 5.6.1 of the ACE framework
  =  [I-D.ietf-ace-oauth-authz] with the profile set to = "mqtt". =
</mglt>

 

[CS] 

When requesting an access token from the AS, the = Client follows the token request as is
described in Section 5.6.1 of = the ACE framework, however, it MUST set the profile parameter to = 'mqtt_tls'. 

 

 


   In the case of an error, = the AS returns error responses for HTTP-
   based = interactions as ASCII codes in JSON content, as defined in
  =  Section 5.2 of RFC 6749 [RFC6749].

<mglt>Error = messages are handled by OAuth2.0 instead of the ACE
framework in = order to keep JSON format. I am wondering why do we have
the = requirement to use ace+cbor only for error message ? It seems to me
a = bit strange to have error handling defined in another = document.
</mglt>

<= div>

[CS] Should keep as-is for the time = being? 

 


2.1.2.  Client Connection Request to the = Broker (C)

   This section describes how the Client = transports the token to the
   Broker (RS) via the CONNECT = control message after the TLS handshake.

<mglt>If the TLS = handshake has already been performed, it would be good
to mention = which credentials have been used. Obviously, if the token is
provided = by the CONNECT message, I expect other credentials to be
involved. = </mglt>

 

[CS] TLS handshake uses only server-side certificate = or RPK. I think this is in the text. 

That said there is a Github issue #16 https://git= hub.com/ace-wg/mqtt-tls-profile/issues/16

around this, and will provide other clarifications as = Jim asked. 


   This is similar to an earlier = proposal by Fremantle et al.
   [fremantle14].  = Alternatively, the token may be used for the TLS
   session = establishment as described in the DTLS profile for ACE
  =  [I-D.gerdes-ace-dtls-authorize].  In this case, both the TLS = PSK and
   RPK handshakes MAY be supported. =
<mglt>
It would be good to expand Raw Public Keys (RPK). My = reading is that
this section does not provide a single mechanism for = the Client to be
authenticated by the Broker, but instead two = different ways. I would
thus recommend to state it clearly in the = introduction of the section..
Currently, the section = mentions:
"""
This section describes how the Client = transports the token to the
   Broker (RS) via the CONNECT = control message after the TLS handshake.
"""

An = then we have a relatively detailed description on how this = is
performed using TLS. It might be better to say something around = the
following lines:
"""
This section describes = how the Client transports the token to the
   Broker (RS). = This can be achieved during the TLS KEX or during the
MQTT session = establishment via the CONNECT control message after the TLS = handshake.
"""

I am not sure that MAY is = appropriated here. I suspect that if none are
supported, this method = will not work. As a result, if seems to me that
it woudl be more = accurate to say that TLS Client and TLS server MUST
support the PSK = authentication as well as the raw public key.

One issue I have = with I-D.gerdes-ace-dtls-authorize that is = now
draft-ietf-ace-dtls-authorize is that it seems to only consider = TLS 1.2.
With TLS 1.3 PSK and RPK are supported.

My = interpretation is that PSK provides mutual authentication, but in = our
case RPK will only authenticate the client. If that is correct, = there
might be a new to specify how the RS is authenticated by the = Client. =

</mglt>

<= p class=3DMsoNormal> 

[CS] I will actually reorganize this section, and = hence, this will be more clear. 

Added your comment to issue #29, acknowledge that it = is linked to #16 as well. 

 

I = was trying to say the following, but I see that the text is not clear on = that:

- MUST: TLS with = server validation + token in MQTT CONNECT (will clarify server-side = certificate/RPK)

- MAY: = TLS with server/client validation with RPK -> token pushed to = "authz-info"

- = MAY: TLS with server/client validation with PSK -> token = in  psk_identity

 

 This option is described in more
  =  detail in Appendix B.

<mglt>see my comment in annex = B.</mglt>

 

 

[CS] OK. 

 


   After the token acquisition, the = Client connects to the RS (Broker)
   using the CONNECT = message of MQTT over TLS.  For server
  =  authentication, the client MAY either have the ability to receive = and
   validate a certificate or a raw public key from the = Broker.  

<mglt>I might have missed something, but I = thought that PSK/RPK were
used to authenticate the Client. While in = this case the RPK is used to
authenticate the RS, is that the same = RPK provided by the AS or another
one? = </mglt>

 

[CS] No the RPK was suggested for the RS/Broker = authentication. 

As = in the core ACE document, we assumed that the client learned either the = RS's public key

from the AS. However, I haven't = seen in the core document an example of how = AS 

returns this information to the = client. 

 

[JLS] This is done using the =
=E2=80=98rs_cnf=E2=80=99 field

 

 

 

   For token transport, the RS SHOULD = support AUTH (Authentication
   Exchange) method.  The = RS MAY support token transport via username
   and = password, which is described in Section 3 for MQTT v3.1.1.  = The
   rest of this section describes the AUTH method, for = which the
   username and password flags MUST be set to = 0.

<mglt>
Maybe the reference should be for MQTTv5 = instead of MQTTv3.
I believe it would be good to specify how setting = the password flag
interacts with the Authentication method. =
</mglt>

 

 

[CS] Do you suggest that if AUTH method is used, = MQTTv5 ignores password/username?

 

 

 

2.1.2.1.  Proof-of-Possession over Predefined = Field

   For this option, the Authentication Data MUST = contain the token and
   the keyed message digest (MAC) or = the Client signature.  To calculate
   the keyed = message digest (MAC) or the Client signature, the Client
  =  SHOULD apply the PoP key to the CONNECT payload.

  = <mglt> I have the impression the latest sentence indicates that = the
Authenticated Data is include din the CONNECT payload. I have = however
the impression that Authenticated Data is part of the = properties which
are include din the variable header and not the = payload. </mglt>

 

 

[CS] 

No, the CONNECT payload only includes Client = Identifier, Will Properties, Will Topic, Will Payload, User Name, = Password.

AUTH data is = variable header part of the CONNECT = message. 

Anyway, = based on also Jim's input, using payload to do the PoP will be = dropped. 

Jim = suggested we use a nonce from the tls_exporter, and apply PoP to = that. 

We believe = that is the better approach as well. These are related to issues #15 = ( https://git= hub.com/ace-wg/mqtt-tls-profile/issues/15) and #19 (https://git= hub.com/ace-wg/mqtt-tls-profile/issues/19). 

 

 

The CONNECT payload
   has at least a = Client Identifier, and if the Will Flag is set to 1,
   may = contain Will-related information.  The Client Identifier is = a
   MUST be a UTF-8 Encoded String (i.e., is prefixed with = a two-byte
   integer length field that gives the number of = bytes in a UTF-8
   encoded string itself).  The = Client Identifier may be 1-23 UTF-8
   encoded bytes, and = contain only the characters
  =  "0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXY= Z".

<mglt>
For my information I would like to = understand the mention of UTF8
while only ascii characters are = permitted. It seems that teh server MUST
accept these and MAY accept = others as well as a longer client id. Am I
correct ?

The = nonce coded this way has a randomness of 62**23 =3D2**138 =3D 17 = bytes
</mglt>

 

[CS] This section will be changed anyway... However, = need to familiarize to specify how to use Exporter = Labels.  

(Server can accept other = characters.)

 

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

   If the RS accepts the connection, = it MUST store the token until the
   end of = connection.  On Client or RS disconnection, the token is
  =  discarded, and the Client MUST provide a token inside each = CONNECT
   message.

<mglt> The latest sentence = is unclear to me. I think that disconnection
can be interpreted in = two way: 1) the disconnection of the will or a
DISCONNECT. I believe = both are considered. </mglt>

 

[CS] Either Client or Server may initiate a = disconnection. In either case, the token is = discarded.

The will may be = sent if the client set up a will in case of unexpected = disconnection.

 

Though it needs to be clarified for instance, if there = are retained messages, these are sent as long as the token is = valid. 

Since the = introspection results are cached, this can be still done but should = clarify unless it gets confusing. 

 

To avoid any confusion, and not to have to discuss = these things in that section, I reworded = as: 

On Client or RS = disconnection, the Client is expected to provide a token again inside = the next CONNECT message.

 

 

   If the token is not self-contained and = the Broker uses token
   introspection, it MAY cache the = validation result to authorize the
   subsequent PUBLISH = and SUBSCRIBE messages.  PUBLISH and SUBSCRIBE
  =  messages, which are sent after a connection set-up, do not = contain
   access tokens.  If the introspection result = is not cached, then the
   RS needs to introspect the saved = token for each request.  The Broker
   SHOULD use a = cache time out to introspect tokens regularly.

<mglt>The = latest sentence seems to indicate that result provided as
via = introspection do not necessarily have a Time to Live which could = be
interpreted as a commitment from the AS to authorize during = that
period. If that is possible, it would be appropriated this time = out is
provided by the AS.
I am also wondering why the token = expiration cannot be considered = as
well.
</mglt>

=

 

 

[CS] This is to handle the situation where the = resource owner changes the permissions of the Client, which would revoke = the token.

And hence the = token exp field would not help.

 If the RS does not check the token introspection = results, it 

will use = the token until its expiration time. 

I've considered this more appropriate to be set by the = RS as its RS risk management. 

 

 

Appendix B.  The Authorization Information = Endpoint

   The main document described a method for = transporting tokens inside
   MQTT CONNECT messages.  = In this section, we describe an alternative
   method to = transport an access token.
   The method consists of the = MQTT Broker accepting PUBLISH messages to
   a public = "authz-info" topic.  A Client using this method MUST = first
   connect to the Broker, and publish the access = token using the "authz-
   info" topic.  The = Broker must verify the validity of the token (i.e.,
  =  through local validation or introspection).  After publishing = the
   token, the Client disconnects from the Broker and is = expected to try
   reconnecting over = TLS.

<mglt>I understand this as an open channel for CONNECT = and sending
PUBLISHING message. This potentially open the door for = DoSing the RS
either by openning too many MQTT sessions or by sending = too many tokens.
I expect this to be mentioned in the security = consideration section as
well as potential mechanisms to limit these = risks.
</mglt>

 

[CS] It is indeed mentioned in this paragraph in the = security consideration section. 

"The RS may monitor Client behaviour to detect = potential security problems, especially those affecting = availability.

 These = include repeated token transfer attempts to the public = "authz-info" topic, repeated connection = attempts,
 abnormal terminations, and Clients that connect but = do not send any data.
 If the RS supports the public = "authz-info" topic, described in Appendix B,
 then = this may be vulnerable to a DDoS attack, where many Clients use the = "authz-info" public topic
       to = transport fictitious tokens, which RS may need to store = indefinitely."

 

 

Thank you for your comments. And will try to address = Jim's shortly to be able to push another version before the = deadline. 

 

Kind = regards, 

--Cigdem 

 

 

 

On = Thu, Oct 17, 2019 at 2:47 PM Jim Schaad <ietf@augustcellars.com> = wrote:

 <= /o:p>

 <= /o:p>

From:= Cigdem Sengul <cigdem.sengul@gmail.com>
Sent: = Thursday, October 17, 2019 4:13 AM
To: Jim Schaad <ietf@augustcellars.com>
Cc: draft-ietf-ace-mqtt-tls-profile@ietf.org; ace@ietf.org
Subject: Re: [Ace] Review = for draft-ietf-ace-mqtt-tls-profile-01

 <= /o:p>

Hello = Jim,

Thanks for = this review. I have responded = inline. 



1.  = Are there any specifics about using ACE over HTTP that need to = be
explicitly stated some place.  Some of these things might = include:
        a) Must be HTTPS even if = encrypted requests/responses are provided.
      =   b) What types of validation are permitted/required: = anon-anon,
server validation, server & client validation. The = latter corresponds to
current DTLS statements. 
  =       c) Are we looking for using the normal HTTP/HTTPS = ports or should we
be using different ports?  =

 <= /o:p>

>> = Agreed. Need to specify that it is HTTPS.

Mutual = authentication and server validation Required. =

Was = thinking it would be normal HTTPS ports. Should we consider = different?

What = scenarios should permit anon-anon; anon clients? 

 <= /o:p>

[JLS] If = you look at my last email I went through this.  Anon-anon is going = to be a bad idea because the server is never validated, however client = anon is fine since you are going to validate the client in the MQTT = protocol.

 <= /o:p>

 <= /o:p>


4.  = Section 2.1.2: It is not clear from the document is a Broker is going = to
also have the possibility of doing a post of the token via = HTTPS.  Currently
I would think not, but given that this is = documented in OAuth 2.0 as an
option I am not = clear.

>> Do = you mean for introspection? Yes, this is a MAY as in the core document, = and so in this one too. 

And if = there is an RS-AS interaction, we expect that to be on = HTTPS. 

I will try = to see where I should clarify in the text. 

 <= /o:p>

[JLS] No, I = was originally looking at doing an HTTPS post of the token from the = client to the RS.  This was before I figured out that you have an = alternative method of doing this in the MQTT protocol and so it should = not be needed.   Being clear on the fact that this would not = be expected is probably a good idea.

 <= /o:p>


7. =  In Figure 2, I think the use of Client Identifier is = somewhat
confusing.  I think this is supposed to be the token as = the Client
Identifier is a different thing in MQTT.  Either that = or you need to do a
better job of describing the property = block.

 <= /o:p>

OK. I think = I should explain MQTT packets better. 

A connect = packet has three parts: 1) Fixed header 2) Variable Header and 3) = Payload.

The = variable header may have several properties, and Authentication Method = and Authentication Data are two of these = properties. 

According = to MQTT Specification:

The ClientID MUST be a UTF-8 Encoded = String

A Server MAY allow a Client to supply a ClientID that has = a length of zero bytes, however, if it does so the Server MUST = treat this as a special case.

 <= /o:p>

And= this is what is done in the case of a = collision:

If the ClientID represents a Client already connected to = the Server, the Server sends a DISCONNECT packet to the existing Client = with Reason Code of 0x8E (Session taken = over) 

 <= /o:p>

Is this = more clear? If yes, I will try to clarify in = text. 

 <= /o:p>

[JLS] That = is not where I was having a problem.  I was getting confused by the = figure itself.  Labeling the figure better might help.  = =E2=80=9CMQTT V5.0 CONNECT control message with =E2=80=98ace=E2=80=99 = authentication method=E2=80=9D.  I would rather not have all of the = abbreviations in the title, but I can live with = it.

 <= /o:p>


8. = If the value of Clean Start or Expiry Interval are not set correct = is
the server to fail the connect?

 <= /o:p>

>> = Agreed. This should be specified. 

Two = options: 1) Do not accept connection or 2) accept the connection but = then never create sessions, and then server  MUST set Session Present to 0 in the CONNACK = packet, indicating 

no session is = present. 

 <= /o:p>

This = basically makes Clean Start flag = meaningless. 

If this is = better than client MUST be setting those parameters correctly, then we = can go this way. 

Any = thoughts?

 <= /o:p>

[JLS] I = don=E2=80=99t really care one way or the other.  Given that there = is the return value in the CONNACK, I think that a simple statement that = the flag is set to 0 regardless of the value coming in.  =

 <= /o:p>


10. Section = 2.1.2.1 - I am having a problem computing the MAC over the
payload of = the CONNECT message.  The password where the value is placed = is
included in the payload and I am not clear if it should be = computed up to
that value or if a fixed value should be used for the = computation.

 <= /o:p>

>>OK. = I think it got muddled because I was trying to find a solution for a = scenario where the ClientId is used across sessions, and hence, not = random. 

 <= /o:p>

Two = cases.

1) Client = ID uniquely random across each Client connection attempt to Broker: MAC = over Payload - Payload begins with ClientID and MAY include Will = Properties if Client indicated that it will have a = will. 

2) Client = ID NOT uniquely random: MAC over Authentication = Data. 

 <= /o:p>

It may be = best to choose one method and just say MUST always have a nonce in = Authentication Data, and MAC is computed over that?

 <= /o:p>

[JLS] Lets = step back and look at the problem I think you are trying to solve.  =   

  • If you are trying to make sure that there is not a replay = of the signature, then this would require that the server keep track of = the list of nonce values that the client has provided. =
  •  If you are trying to make sure that the signature is = =E2=80=9Cfresh=E2=80=9D then the server would need to be able to provide = some type of data as part of the value being signed.  As I think I = have said before the latter can be satisfied by getting your nonce value = from the TLS session using a = tls-exporter.

 <= /o:p>

If neither = of these problems is trying to be solved, then there is no need for the = nonce at all.

 <= /o:p>

 <= /o:p>

11. I am = worried about the text on the Client Identifier in this section.
It = is not clear to me that having the client generate a random value = for
this field is good just in terms of the possibility of collisions = occurring
on the server.  The text in the MQTT 5.0 document = appears to say that this
is more interesting for the situation of = getting back state that was left on
the server after a disconnect and = not so much for a clean session.

 <= /o:p>

>> = Yes, but as I explained for comment 7, in MQTT, the typical case is the = client provides its id. 

However, to = cater to all requirements and all implementation possibilities, maybe it = is best to just use a nonce as explained for comment 10 and not tie = anything to client id.

 <= /o:p>

Previously, = when we were writing the draft for MQTT v3.1.1 we wanted to provide a = solution that uses the available fields in the CONNECT packet as much as = possible; without

introducing = any new fields. This was because of the constraints of the MQTT v3.1.1. = MQTT v5 gives us more options to implement this = better.

 <= /o:p>

For = backward compatibility, we would need to think if we create a special = data structure to be used in the password so that it holds both the = MAC/signature and the nonce.   

 <= /o:p>

As the use = of ClientId seems to create confusion, I am leaning towards this = solution. Any thoughts?

 <= /o:p>

[JLS] Look = at the previous answer and the re-ask the = question.

 <= /o:p>

 <= /o:p>

13. Is there = someplace that authentication methods need to be registered?  = I
was unable to see any such registry setup with OASIS from the = v5
specification.  Should we suggest to the MQTT group that this = is something
that should be done?

 <= /o:p>

>> = This is an interesting thought. The draft was indeed discussed in the = OASIS MQTT WG. 

 <= /o:p>

But, the WG = may consider this out of scope, as they have on their charter = page:

 Tr= ansport level security is assumed and no mandatory security features = will be added.

The MQTT v5 = draft says:

The= Authentication Method is commonly a SASL mechanism, and using such a = registered name aids interchange. However, the Authentication Method is = not constrained to using registered SASL = mechanisms.

&nb= sp;

[JLS] I = think that the lack of a registry should be identified someplace in the = document.  This is probably a security consideration that there = might be a different authentication method which re-uses the same = authentication method name.

 <= /o:p>

 <= /o:p>

17.  It is = not clear to me, how in the scope string is the ability to have = a
"will" indicated?

>>&nbs= p;If = the Will Flag is set to 1, the Will Topic follows the Client ID and Will = Properties in the Payload.

Thi= s is where the broker learns the Will = Topic. 

The= n the scope would be publish_<will = topic>. 

And= subscribes would need to subscribe_<will topic> to receive this = message. 

Wil= l clarify in text.

 <= /o:p>

[JLS] = publish makes sense to me.  I was just being overly = complicated.

 <= /o:p>

18.  Section = 2.1.4 - I am unsure what the implications of discarding tokens
on the = end of a connection are going to be.  How do you publish the = token
before doing the connection or is that only for an updated = token?

 <= /o:p>

>> = Tokens are discarded at the end of disconnection because no previous = session state is kept.

And a token = is expected in the new CONNECT request (otherwise, it is AS = discovery)

 <= /o:p>

Before the = connection, a token may be transported via  "authz-info" = topic described in Appendix B. 

During the = connection, a new token may be transported via the AUTH packet - which = enables reauthentication. 

 <= /o:p>

[JLS] This = is still not clear to me.  Is the transport of the token via = =E2=80=9Cauth-info=E2=80=9D topic not considered to be part of the = session?  If you say that you look at just the last value = published, then is there not going to be a race condition between two = different clients trying to publish and connect? 

 <= /o:p>


20. = ; I am not sure what the benefits of doing the check on a PINGREQUEST = is
going to be.  Like the relay of a PUBLISH message this is = just going to
produce a DISCONNECT and a closed channel.  If = this is really allowed, then
you should potentially also say that the = Broker could do a check based on
clock time elapsing.  (I.e. do = the check every hour.)

 <= /o:p>

>> = This was suggested by one of the reviewers that provide MQTT services = (his e-mail regarding this was sent to the ace = list). 

It was = suggested as an optimization for detecting token expirations and = disconnecting early. 

(i.e., if = you are already receiving PINGREQUESTs, use these as a trigger to check = the token). 

I think = time-based checks may also help and be added as an = option.

 <= /o:p>

[JLS] = Ok

 <= /o:p>


22. Not = sure if this goes here or in the connect documentation.  There = needs
to be a check that the will topic is a topic that the client is = going to be
permitted to publish on.   Corner case, if the = ability to publish a will in
the event that this permission is = lost.  Does this kill the session or the
will message?  = I.e. should the permission for the will message be rechecked
before = sending it allowing for the time based expiration of the = token.

 <= /o:p>

>> We = have been thinking about this. 

If the = disconnect is due to a token expiration, and hence, also includes the = will topic as well, you have to decide = between:

1) publish = the will

2) do not = publish the will. 

At the = moment, it's written like we publish the will - but on second = consideration, 

it seems = safer to say "Publish the Will on Server Disconnect or unusual = disconnect if the token (the will permission) has not = expired". 

 <= /o:p>

[JLS] I = would be fine with either position, after all at the time the = =E2=80=9Cpublish=E2=80=9D event occurred the token was valid, this is = just deferring relaying it to subscribers. 

 <= /o:p>

Jim

 <= /o:p>

 <= /o:p>

Thanks = again for these comments, will create the necessary github issues and = start revising the text. 

 <= /o:p>

Best, <= o:p>

 <= /o:p>


Jim
<= br>







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

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

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

------=_NextPart_000_0020_01D58F03.6EAC7F10-- From nobody Wed Oct 30 09:34: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 1CF55120116; Wed, 30 Oct 2019 09:34:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 FwsCSloJeGNI; Wed, 30 Oct 2019 09:34:26 -0700 (PDT) Received: from mail-qt1-x835.google.com (mail-qt1-x835.google.com [IPv6:2607:f8b0:4864:20::835]) (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 64297120227; Wed, 30 Oct 2019 09:34:23 -0700 (PDT) Received: by mail-qt1-x835.google.com with SMTP id l3so4084534qtp.2; Wed, 30 Oct 2019 09:34:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6mpfgGX8LuiUPQBX4VkyN2ATYXqKlwZbvbCrg8UOd90=; b=RQPOvOymylHmP55fF1Z93yTUi8vV4IY/GsXOi0LYgFdeLrKx2CSQJng1PsSjE6jaPD s3uBzjiz3oxbCyhuy40OB6ONPX0d/Wp3XRE/4dx0EJ6KzJYnh+ds+QTQhb36vqJXXkk9 5zQL7Nr/0SYy2rWlW9SjoUfZ53QzicoCE+S6P7meAfz0Yw+fShifHZOZqw1YyFuQ2OeX 4v0FEqGzv5H4SdBv40S+LcBHo23Y1pXXJcjTLw+3XA7VIo7UV7U5ELytpJjExIrG15YF zzzuM7mpwTE6GwcIcJncCd9RtfUr0AXk3s2OFF2AMqsPo8oNCm9tmvF/H2XmiIxZouyf YpPg== 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=6mpfgGX8LuiUPQBX4VkyN2ATYXqKlwZbvbCrg8UOd90=; b=rIS6NVSfEM1hefLZZG0K4H7eiK2/aDX1a2mA7l3qF2HaVpfgIjiQLpR//3/q1rsyBW un4ek01rMG/XdNdvtMcF1zEM4yx2unB8sB2egXqMXQJ9IBWm3iG4NVB3tEPl40hNLVxZ 0pma/I4yypGnW5+Z28QROKu/NN7yA5YCL+ARfuhoKR9iOUfxeJuJTilui8AcTCf1B5H6 +RhyYlbnVThoU3lQA8d7lkWSFcXg9VMxC/rSnIQ6aPD6taE3EgWOE7df/jzV3KhmfCEJ BjJvtYSSuJpH6oAPVyJ8H7lV9+U0UyfguhngOWVHWrK4ShhoF0q+l6bZviA8DBZl7NhI I58Q== X-Gm-Message-State: APjAAAXNCwmvL6AYGczGV7Vm4T6k8Pjwb4GVjDxyyF7TAnEhuKGQU2tL VuSOekN+/WHQb6Bb5gmwVS+nFPCN0qJnZfYZ7/0= X-Google-Smtp-Source: APXvYqzNpPbCqhD2CLglqGwahTsbYqkD3/N3suuGMofsH6baf4/uh9/+AgGUbrqu7h2Ud7iOuAgiI9uivScqYB8S6ek= X-Received: by 2002:ac8:3475:: with SMTP id v50mr1002038qtb.105.1572453262203; Wed, 30 Oct 2019 09:34:22 -0700 (PDT) MIME-Version: 1.0 References: <021c01d5839c$d53206a0$7f9613e0$@augustcellars.com> <033101d5851b$30a41ad0$91ec5070$@augustcellars.com> <001f01d58f3e$1b067510$51135f30$@augustcellars.com> In-Reply-To: <001f01d58f3e$1b067510$51135f30$@augustcellars.com> From: Cigdem Sengul Date: Wed, 30 Oct 2019 16:34:07 +0000 Message-ID: To: Jim Schaad Cc: Daniel Migault , ace@ietf.org, draft-ietf-ace-mqtt-tls-profile@ietf.org Content-Type: multipart/alternative; boundary="0000000000001ea1cf0596234ef0" Archived-At: Subject: Re: [Ace] Review for draft-ietf-ace-mqtt-tls-profile-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: Wed, 30 Oct 2019 16:34:34 -0000 --0000000000001ea1cf0596234ef0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Just saw it in the core document as well. Thanks, Jim. --Cigdem On Wed, Oct 30, 2019 at 4:21 PM Jim Schaad wrote: > Just one quick comment below > > > > *From:* Cigdem Sengul > *Sent:* Wednesday, October 30, 2019 9:13 AM > *To:* Daniel Migault > *Cc:* Jim Schaad ; ace@ietf.org; > draft-ietf-ace-mqtt-tls-profile@ietf.org > *Subject:* Re: [Ace] Review for draft-ietf-ace-mqtt-tls-profile-01 > > > > Thank you for your comments Daniel (prefixed [CS]) > > My comments are inside. I've also created the -v-02-WIP branch for the > work in progress based on your and Jim's comments. > > > > On Thu, Oct 24, 2019 at 2:50 AM Daniel Migault 40ericsson.com@dmarc.ietf.org> wrote: > > HI, > > > > Thanks for sending an update. Please find my comments of the draft. > > > > This document makes the same assumptions as the Section 4 of the ACE > framework [I-D.ietf-ace-oauth-authz] regarding Client and RS > registration with the AS and establishing of keying material. > > The document seems mostly focuses on the latest version of MQTT, > I am wondering if we could encourage similarly the use of the latest > version of TLS that is 1.3 at the time of writing. > > It seems AS as not been defined previously, so maybe it should be > expanded there. > > > > > [CS] Can add a similar recommendation for TLS 1.3. > > AS is expanded. > > > > > > > > MQTTS > Secured transport profile of MQTT. MQTTS runs over TLS. > The Server in MQTT acts as an intermediary between > Clients that publishes Application Messages, and the Clients > that made Subscriptions. The Broker acts as the Resource > Server for the Clients. > > publishes > > [CS] Fixed. > > > > > > > > Subscription > A subscription comprises a Topic Filter and a maximum Quality > of Service (QoS). > > Maybe that would be clearer to specify QoS level as well. > > > > [CS] Added. > > > > > > PINGREQ > A ping request sent from a Client to the Broker. It signals > to the Broker that the Client is alive, and is used to > confirm that the Broker is still alive. > > It may look a bit strange to have PINGREQ without PINGRESP. You > might also indicate the keep alive period is provided in the CONNECT > > > > [CS] Added PINGRESP, clarified the Keep Alive period is set in the CONNEC= T > in the definition of PINGREQ. > > > > > Will > An application message published by the Server after the > network connection is closed in cases where the network > connection is not closed normally. If the Will Flag is set, > then the payload of the CONNECT message has information about > the Will. The Will consists of the Will Properties, Will > Topic, and Will Payload fields in the CONNECT message. > > > The first sentence seems to be related to the Will message while the > intent, I suppose of teh definition was to define the generic conpet of > Will. It might be clearer to expose the principle of the wil, that is a > server sends a given message in case a client is disconnected > improperly. It might be clearer to mention explicitly there is a Will > "concept" that is implemented a WillFlag WillQoS, WillRetain in the > CONNECT header as well as other Will Properties and Will Messages. This > mostly consists in the last sentence being moved up. > > > > > [CS] I reworded it - let me know if it is more clear. > > > > 2. Protocol Interactions > > This section describes the following exchanges between Clients, the > Broker, and the Authorization Server according to the MQTT v5.0. > > Though english is not my first language, I have the impression the > text can be interpreted as MQTT enables clients to establish session > which does not seems correct to me. The text that follows clarifies this > as well. > > > > > [CS] Neither mine, I reworded that as: "Authorizing connection requests > from the Clients to the Broker" > > Actually, I also went through the text to reword "establishment" to set-u= p > which is simpler. > > > > > > 2.1. Authorizing Connection Establishment > > > > If the > Client is resource-constrained, a Client Authorisation Server may > > I have the impression an AS would be sufficient. > > > > [CS] Client Authorization Server was the terminology used in the Actors > draft - I've removed all other references but wanted to distinguish that > this is separate than the AS granting access tokens. > > Can just say client's AS? > > > carry out the token request on behalf of the Client, and later, > onboard the Client with the token. Also, these interfaces may be > implemented using other protocols, e.g., CoAP or MQTT. > While the introduction and the figure mentions that HTTPS is used > as a transport, it might be worth mentioning that HTTPS is being used. I > propose to add "...other protocols than HTTPS, e.g ... > > > > > [CS] Added. > > > > > > 2.1.1. Client Token Request to the Authorization Server (AS) > > The first step in the protocol flow (Figure 1 (A)) is the token > acquisition by the Client from the AS. When requesting an access > token from the AS, the Client MAY include parameters in its request > as defined in Section 5.6.1 of the ACE framework > [I-D.ietf-ace-oauth-authz]. The media format is 'application/ > ace+json'. The profile parameter MUST be set to 'mqtt_tls'. The > OAuth 2.0 AS uses a JSON structure in the payload of its responses > both to client and RS. > > I understand that some parameters are mandatory while other are > not. I believe it might be clearer to start with the mandatory > parameters (MUST) and then mention that other parameters are optional > (MAY). That said, it might be simpler, if that is correct to mention > that the token request is as described in Section 5.6.1 of the ACE > framework > [I-D.ietf-ace-oauth-authz] with the profile set to "mqtt". > > > > > [CS] > > When requesting an access token from the AS, the Client follows the token > request as is > described in Section 5.6.1 of the ACE framework, however, it MUST set the > profile parameter to 'mqtt_tls'. > > > > > > > In the case of an error, the AS returns error responses for HTTP- > based interactions as ASCII codes in JSON content, as defined in > Section 5.2 of RFC 6749 [RFC6749]. > > Error messages are handled by OAuth2.0 instead of the ACE > framework in order to keep JSON format. I am wondering why do we have > the requirement to use ace+cbor only for error message ? It seems to me > a bit strange to have error handling defined in another document. > > > [CS] Should keep as-is for the time being? > > > > > 2.1.2. Client Connection Request to the Broker (C) > > This section describes how the Client transports the token to the > Broker (RS) via the CONNECT control message after the TLS handshake. > > If the TLS handshake has already been performed, it would be good > to mention which credentials have been used. Obviously, if the token is > provided by the CONNECT message, I expect other credentials to be > involved. > > > > [CS] TLS handshake uses only server-side certificate or RPK. I think this > is in the text. > > That said there is a Github issue #16 > https://github.com/ace-wg/mqtt-tls-profile/issues/16 > > around this, and will provide other clarifications as Jim asked. > > > This is similar to an earlier proposal by Fremantle et al. > [fremantle14]. Alternatively, the token may be used for the TLS > session establishment as described in the DTLS profile for ACE > [I-D.gerdes-ace-dtls-authorize]. In this case, both the TLS PSK and > RPK handshakes MAY be supported. > > It would be good to expand Raw Public Keys (RPK). My reading is that > this section does not provide a single mechanism for the Client to be > authenticated by the Broker, but instead two different ways. I would > thus recommend to state it clearly in the introduction of the section.. > Currently, the section mentions: > """ > This section describes how the Client transports the token to the > Broker (RS) via the CONNECT control message after the TLS handshake. > """ > > An then we have a relatively detailed description on how this is > performed using TLS. It might be better to say something around the > following lines: > """ > This section describes how the Client transports the token to the > Broker (RS). This can be achieved during the TLS KEX or during the > MQTT session establishment via the CONNECT control message after the TLS > handshake. > """ > > I am not sure that MAY is appropriated here. I suspect that if none are > supported, this method will not work. As a result, if seems to me that > it woudl be more accurate to say that TLS Client and TLS server MUST > support the PSK authentication as well as the raw public key. > > One issue I have with I-D.gerdes-ace-dtls-authorize that is now > draft-ietf-ace-dtls-authorize is that it seems to only consider TLS 1.2. > With TLS 1.3 PSK and RPK are supported. > > My interpretation is that PSK provides mutual authentication, but in our > case RPK will only authenticate the client. If that is correct, there > might be a new to specify how the RS is authenticated by the Client. > > > > > > [CS] I will actually reorganize this section, and hence, this will be mor= e > clear. > > Added your comment to issue #29, acknowledge that it is linked to #16 as > well. > > > > I was trying to say the following, but I see that the text is not clear o= n > that: > > - MUST: TLS with server validation + token in MQTT CONNECT (will clarify > server-side certificate/RPK) > > - MAY: TLS with server/client validation with RPK -> token pushed to > "authz-info" > > - MAY: TLS with server/client validation with PSK -> token in > psk_identity > > > > This option is described in more > detail in Appendix B. > > see my comment in annex B. > > > > > > [CS] OK. > > > > > After the token acquisition, the Client connects to the RS (Broker) > using the CONNECT message of MQTT over TLS. For server > authentication, the client MAY either have the ability to receive and > validate a certificate or a raw public key from the Broker. > > I might have missed something, but I thought that PSK/RPK were > used to authenticate the Client. While in this case the RPK is used to > authenticate the RS, is that the same RPK provided by the AS or another > one? > > > > [CS] No the RPK was suggested for the RS/Broker authentication. > > As in the core ACE document, we assumed that the client learned either > the RS's public key > > from the AS. However, I haven't seen in the core document an example of > how AS > > returns this information to the client. > > > > [JLS] This is done using the =E2=80=98rs_cnf=E2=80=99 field > > > > > > > > For token transport, the RS SHOULD support AUTH (Authentication > Exchange) method. The RS MAY support token transport via username > and password, which is described in Section 3 for MQTT v3.1.1. The > rest of this section describes the AUTH method, for which the > username and password flags MUST be set to 0. > > > Maybe the reference should be for MQTTv5 instead of MQTTv3. > I believe it would be good to specify how setting the password flag > interacts with the Authentication method. > > > > > > > [CS] Do you suggest that if AUTH method is used, MQTTv5 ignores > password/username? > > > > > > > > 2.1.2.1. Proof-of-Possession over Predefined Field > > For this option, the Authentication Data MUST contain the token and > the keyed message digest (MAC) or the Client signature. To calculate > the keyed message digest (MAC) or the Client signature, the Client > SHOULD apply the PoP key to the CONNECT payload. > > I have the impression the latest sentence indicates that the > Authenticated Data is include din the CONNECT payload. I have however > the impression that Authenticated Data is part of the properties which > are include din the variable header and not the payload. > > > > > > [CS] > > No, the CONNECT payload only includes Client Identifier, Will Properties, > Will Topic, Will Payload, User Name, Password. > > AUTH data is variable header part of the CONNECT message. > > Anyway, based on also Jim's input, using payload to do the PoP will be > dropped. > > Jim suggested we use a nonce from the tls_exporter, and apply PoP to that= . > > We believe that is the better approach as well. These are related to > issues #15 ( https://github.com/ace-wg/mqtt-tls-profile/issues/15) and > #19 (https://github.com/ace-wg/mqtt-tls-profile/issues/19). > > > > > > The CONNECT payload > has at least a Client Identifier, and if the Will Flag is set to 1, > may contain Will-related information. The Client Identifier is a > MUST be a UTF-8 Encoded String (i.e., is prefixed with a two-byte > integer length field that gives the number of bytes in a UTF-8 > encoded string itself). The Client Identifier may be 1-23 UTF-8 > encoded bytes, and contain only the characters > "0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ". > > > For my information I would like to understand the mention of UTF8 > while only ascii characters are permitted. It seems that teh server MUST > accept these and MAY accept others as well as a longer client id. Am I > correct ? > > The nonce coded this way has a randomness of 62**23 =3D2**138 =3D 17 byte= s > > > > > [CS] This section will be changed anyway... However, need to familiarize > to specify how to use Exporter Labels. > > (Server can accept other characters.) > > > > 2.1.4. The Broker's Response to Client Connection Request > > If the RS accepts the connection, it MUST store the token until the > end of connection. On Client or RS disconnection, the token is > discarded, and the Client MUST provide a token inside each CONNECT > message. > > The latest sentence is unclear to me. I think that disconnection > can be interpreted in two way: 1) the disconnection of the will or a > DISCONNECT. I believe both are considered. > > > > [CS] Either Client or Server may initiate a disconnection. In either case= , > the token is discarded. > > The will may be sent if the client set up a will in case of unexpected > disconnection. > > > > Though it needs to be clarified for instance, if there are retained > messages, these are sent as long as the token is valid. > > Since the introspection results are cached, this can be still done but > should clarify unless it gets confusing. > > > > To avoid any confusion, and not to have to discuss these things in that > section, I reworded as: > > On Client or RS disconnection, the Client is expected to provide a token > again inside the next CONNECT message. > > > > > > If the token is not self-contained and the Broker uses token > introspection, it MAY cache the validation result to authorize the > subsequent PUBLISH and SUBSCRIBE messages. PUBLISH and SUBSCRIBE > messages, which are sent after a connection set-up, do not contain > access tokens. If the introspection result is not cached, then the > RS needs to introspect the saved token for each request. The Broker > SHOULD use a cache time out to introspect tokens regularly. > > The latest sentence seems to indicate that result provided as > via introspection do not necessarily have a Time to Live which could be > interpreted as a commitment from the AS to authorize during that > period. If that is possible, it would be appropriated this time out is > provided by the AS. > I am also wondering why the token expiration cannot be considered as > well. > > > > > > > [CS] This is to handle the situation where the resource owner changes the > permissions of the Client, which would revoke the token. > > And hence the token exp field would not help. > > If the RS does not check the token introspection results, it > > will use the token until its expiration time. > > I've considered this more appropriate to be set by the RS as its RS risk > management. > > > > > > Appendix B. The Authorization Information Endpoint > > The main document described a method for transporting tokens inside > MQTT CONNECT messages. In this section, we describe an alternative > method to transport an access token. > The method consists of the MQTT Broker accepting PUBLISH messages to > a public "authz-info" topic. A Client using this method MUST first > connect to the Broker, and publish the access token using the "authz- > info" topic. The Broker must verify the validity of the token (i.e., > through local validation or introspection). After publishing the > token, the Client disconnects from the Broker and is expected to try > reconnecting over TLS. > > I understand this as an open channel for CONNECT and sending > PUBLISHING message. This potentially open the door for DoSing the RS > either by openning too many MQTT sessions or by sending too many tokens. > I expect this to be mentioned in the security consideration section as > well as potential mechanisms to limit these risks. > > > > > [CS] It is indeed mentioned in this paragraph in the security > consideration section. > > "The RS may monitor Client behaviour to detect potential security > problems, especially those affecting availability. > > These include repeated token transfer attempts to the public "authz-info= " > topic, repeated connection attempts, > abnormal terminations, and Clients that connect but do not send any data= . > If the RS supports the public "authz-info" topic, described in Appendix = B, > then this may be vulnerable to a DDoS attack, where many Clients use the > "authz-info" public topic > to transport fictitious tokens, which RS may need to store > indefinitely." > > > > > > Thank you for your comments. And will try to address Jim's shortly to be > able to push another version before the deadline. > > > > Kind regards, > > --Cigdem > > > > > > > > On Thu, Oct 17, 2019 at 2:47 PM Jim Schaad wrote= : > > > > > > *From:* Cigdem Sengul > *Sent:* Thursday, October 17, 2019 4:13 AM > *To:* Jim Schaad > *Cc:* draft-ietf-ace-mqtt-tls-profile@ietf.org; ace@ietf.org > *Subject:* Re: [Ace] Review for draft-ietf-ace-mqtt-tls-profile-01 > > > > Hello Jim, > > Thanks for this review. I have responded inline. > > > > 1. Are there any specifics about using ACE over HTTP that need to be > explicitly stated some place. Some of these things might include: > a) Must be HTTPS even if encrypted requests/responses are > provided. > b) What types of validation are permitted/required: anon-anon, > server validation, server & client validation. The latter corresponds to > current DTLS statements. > c) Are we looking for using the normal HTTP/HTTPS ports or should > we > be using different ports? > > > > >> Agreed. Need to specify that it is HTTPS. > > Mutual authentication and server validation Required. > > Was thinking it would be normal HTTPS ports. Should we consider different= ? > > What scenarios should permit anon-anon; anon clients? > > > > [JLS] If you look at my last email I went through this. Anon-anon is > going to be a bad idea because the server is never validated, however > client anon is fine since you are going to validate the client in the MQT= T > protocol. > > > > > > > 4. Section 2.1.2: It is not clear from the document is a Broker is going > to > also have the possibility of doing a post of the token via HTTPS. > Currently > I would think not, but given that this is documented in OAuth 2.0 as an > option I am not clear. > > >> Do you mean for introspection? Yes, this is a MAY as in the core > document, and so in this one too. > > And if there is an RS-AS interaction, we expect that to be on HTTPS. > > I will try to see where I should clarify in the text. > > > > [JLS] No, I was originally looking at doing an HTTPS post of the token > from the client to the RS. This was before I figured out that you have a= n > alternative method of doing this in the MQTT protocol and so it should no= t > be needed. Being clear on the fact that this would not be expected is > probably a good idea. > > > > > 7. In Figure 2, I think the use of Client Identifier is somewhat > confusing. I think this is supposed to be the token as the Client > Identifier is a different thing in MQTT. Either that or you need to do a > better job of describing the property block. > > > > OK. I think I should explain MQTT packets better. > > A connect packet has three parts: 1) Fixed header 2) Variable Header and > 3) Payload. > > The variable header may have several properties, and Authentication Metho= d > and Authentication Data are two of these properties. > > According to MQTT Specification: > > The ClientID MUST be present and is the first field in the CONNECT packet > Payload. > > The ClientID MUST be a UTF-8 Encoded String > > A Server MAY allow a Client to supply a ClientID that has a length of zer= o > bytes, however, if it does so the Server MUST treat this as a special cas= e. > > > > And this is what is done in the case of a collision: > > If the ClientID represents a Client already connected to the Server, the > Server sends a DISCONNECT packet to the existing Client with Reason Code = of > 0x8E (Session taken over) > > > > Is this more clear? If yes, I will try to clarify in text. > > > > [JLS] That is not where I was having a problem. I was getting confused b= y > the figure itself. Labeling the figure better might help. =E2=80=9CMQTT= V5.0 > CONNECT control message with =E2=80=98ace=E2=80=99 authentication method= =E2=80=9D. I would rather > not have all of the abbreviations in the title, but I can live with it. > > > > > 8. If the value of Clean Start or Expiry Interval are not set correct is > the server to fail the connect? > > > > >> Agreed. This should be specified. > > Two options: 1) Do not accept connection or 2) accept the connection but > then never create sessions, and then server MUST set Session Present to > 0 in the CONNACK packet, indicating > > no session is present. > > > > This basically makes Clean Start flag meaningless. > > If this is better than client MUST be setting those parameters correctly, > then we can go this way. > > Any thoughts? > > > > [JLS] I don=E2=80=99t really care one way or the other. Given that there= is the > return value in the CONNACK, I think that a simple statement that the fla= g > is set to 0 regardless of the value coming in. > > > > > 10. Section 2.1.2.1 - I am having a problem computing the MAC over the > payload of the CONNECT message. The password where the value is placed i= s > included in the payload and I am not clear if it should be computed up to > that value or if a fixed value should be used for the computation. > > > > >>OK. I think it got muddled because I was trying to find a solution for = a > scenario where the ClientId is used across sessions, and hence, not rando= m. > > > > Two cases. > > 1) Client ID uniquely random across each Client connection attempt to > Broker: MAC over Payload - Payload begins with ClientID and MAY include > Will Properties if Client indicated that it will have a will. > > 2) Client ID NOT uniquely random: MAC over Authentication Data. > > > > It may be best to choose one method and just say MUST always have a nonce > in Authentication Data, and MAC is computed over that? > > > > [JLS] Lets step back and look at the problem I think you are trying to > solve. > > - If you are trying to make sure that there is not a replay of the > signature, then this would require that the server keep track of the l= ist > of nonce values that the client has provided. > - If you are trying to make sure that the signature is =E2=80=9Cfresh= =E2=80=9D then > the server would need to be able to provide some type of data as part = of > the value being signed. As I think I have said before the latter can = be > satisfied by getting your nonce value from the TLS session using a > tls-exporter. > > > > If neither of these problems is trying to be solved, then there is no nee= d > for the nonce at all. > > > > > > 11. I am worried about the text on the Client Identifier in this section. > It is not clear to me that having the client generate a random value for > this field is good just in terms of the possibility of collisions occurri= ng > on the server. The text in the MQTT 5.0 document appears to say that thi= s > is more interesting for the situation of getting back state that was left > on > the server after a disconnect and not so much for a clean session. > > > > >> Yes, but as I explained for comment 7, in MQTT, the typical case is th= e > client provides its id. > > However, to cater to all requirements and all implementation > possibilities, maybe it is best to just use a nonce as explained for > comment 10 and not tie anything to client id. > > > > Previously, when we were writing the draft for MQTT v3.1.1 we wanted to > provide a solution that uses the available fields in the CONNECT packet a= s > much as possible; without > > introducing any new fields. This was because of the constraints of the > MQTT v3.1.1. MQTT v5 gives us more options to implement this better. > > > > For backward compatibility, we would need to think if we create a special > data structure to be used in the password so that it holds both the > MAC/signature and the nonce. > > > > As the use of ClientId seems to create confusion, I am leaning towards > this solution. Any thoughts? > > > > [JLS] Look at the previous answer and the re-ask the question. > > > > > > 13. Is there someplace that authentication methods need to be registered? > I > was unable to see any such registry setup with OASIS from the v5 > specification. Should we suggest to the MQTT group that this is somethin= g > that should be done? > > > > >> This is an interesting thought. The draft was indeed discussed in the > OASIS MQTT WG. > > > > But, the WG may consider this out of scope, as they have on their charter > page: > > Transport level security is assumed and no mandatory security features > will be added. > > The MQTT v5 draft says: > > The Authentication Method is commonly a SASL mechanism, and using such a > registered name aids interchange. However, the Authentication Method is n= ot > constrained to using registered SASL mechanisms. > > > > [JLS] I think that the lack of a registry should be identified someplace > in the document. This is probably a security consideration that there > might be a different authentication method which re-uses the same > authentication method name. > > > > > > 17. It is not clear to me, how in the scope string is the ability to hav= e > a > "will" indicated? > > >> If the Will Flag is set to 1, the Will Topic follows the Client ID and > Will Properties in the Payload. > > This is where the broker learns the Will Topic. > > Then the scope would be publish_. > > And subscribes would need to subscribe_ to receive this > message. > > Will clarify in text. > > > > [JLS] publish makes sense to me. I was just being overly complicated. > > > > 18. Section 2.1.4 - I am unsure what the implications of discarding toke= ns > on the end of a connection are going to be. How do you publish the token > before doing the connection or is that only for an updated token? > > > > >> Tokens are discarded at the end of disconnection because no previous > session state is kept. > > And a token is expected in the new CONNECT request (otherwise, it is AS > discovery) > > > > Before the connection, a token may be transported via "authz-info" topic > described in Appendix B. > > During the connection, a new token may be transported via the AUTH packet > - which enables reauthentication. > > > > [JLS] This is still not clear to me. Is the transport of the token via > =E2=80=9Cauth-info=E2=80=9D topic not considered to be part of the sessio= n? If you say > that you look at just the last value published, then is there not going t= o > be a race condition between two different clients trying to publish and > connect? > > > > > 20. I am not sure what the benefits of doing the check on a PINGREQUEST = is > going to be. Like the relay of a PUBLISH message this is just going to > produce a DISCONNECT and a closed channel. If this is really allowed, th= en > you should potentially also say that the Broker could do a check based on > clock time elapsing. (I.e. do the check every hour.) > > > > >> This was suggested by one of the reviewers that provide MQTT services > (his e-mail regarding this was sent to the ace list). > > It was suggested as an optimization for detecting token expirations and > disconnecting early. > > (i.e., if you are already receiving PINGREQUESTs, use these as a trigger > to check the token). > > I think time-based checks may also help and be added as an option. > > > > [JLS] Ok > > > > > 22. Not sure if this goes here or in the connect documentation. There > needs > to be a check that the will topic is a topic that the client is going to = be > permitted to publish on. Corner case, if the ability to publish a will = in > the event that this permission is lost. Does this kill the session or th= e > will message? I.e. should the permission for the will message be recheck= ed > before sending it allowing for the time based expiration of the token. > > > > >> We have been thinking about this. > > If the disconnect is due to a token expiration, and hence, also includes > the will topic as well, you have to decide between: > > 1) publish the will > > 2) do not publish the will. > > At the moment, it's written like we publish the will - but on second > consideration, > > it seems safer to say "Publish the Will on Server Disconnect or unusual > disconnect if the token (the will permission) has not expired". > > > > [JLS] I would be fine with either position, after all at the time the > =E2=80=9Cpublish=E2=80=9D event occurred the token was valid, this is jus= t deferring > relaying it to subscribers. > > > > Jim > > > > > > Thanks again for these comments, will create the necessary github issues > and start revising the text. > > > > Best, > > > > > Jim > > > > > > > > > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > > --0000000000001ea1cf0596234ef0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Just saw it in the core document as well. Thanks, Jim.=C2= =A0

--Cigdem=C2=A0

On Wed, Oct 30, 2019 at 4:21 PM = Jim Schaad <ietf@augustcellars= .com> wrote:

Just one quick comment below

<= p class=3D"MsoNormal">=C2=A0

Fro= m: Cigdem Sengul <cigdem.sengul@gmail.com>
Sent: Wednesday, Oct= ober 30, 2019 9:13 AM
To: Daniel Migault <daniel.migault=3D40ericsson.= com@dmarc.ietf.org>
Cc: Jim Schaad <ietf@augustcellars.com>; ace@ietf.org; draf= t-ietf-ace-mqtt-tls-profile@ietf.org
Subject: Re: [Ace] Revie= w for draft-ietf-ace-mqtt-tls-profile-01

=C2=A0

Thank you fo= r your comments Daniel (prefixed [CS])

My comments are inside. I've also created the -v-02-WIP branch= for the work in progress based on your and Jim's comments.=C2=A0

=C2=A0

On Thu, Oct 24, 2019 at 2:50 AM Daniel Migault= <daniel.migault=3D40ericsson.com@dmarc.ietf.org> wrote:

HI,=C2=A0=

=C2=A0<= /p>

Thanks for sending an update. Please f= ind my comments of the draft.=C2=A0

=C2=A0

=C2= =A0 =C2=A0This document makes the same assumptions as the Section 4 of the = ACE
=C2=A0 =C2=A0framework [I-D.ietf-ace-oauth-authz] regarding Client a= nd RS
=C2=A0 =C2=A0registration with the AS and establishing of keying m= aterial.

<mglt> The document seems mostly focuses on the lates= t version of MQTT,
I am wondering if we could encourage similarly the us= e of the latest
version of TLS that is 1.3 at the time of writing.
It seems AS as not been defined previously, so maybe it should be
expa= nded there.
</mglt>=C2=A0

=C2=A0

[CS] Can add a similar recommendation for TLS 1.3.=C2= =A0

AS is expanded.=C2= =A0

=C2=A0=

=C2=A0

=C2=A0<= /p>

=C2=A0 =C2=A0MQTTS
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0Secured transport profile of MQTT.=C2=A0 MQTTS r= uns over TLS.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The Server in MQT= T acts as an intermediary between
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0Clients that publishes Application Messages, and the Clients
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0that made Subscriptions.=C2=A0 The Broker= acts as the Resource
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Server fo= r the Clients.

<mglt>publishes</mglt>

<= /div>

[CS] Fixed.

=C2=A0

=C2=A0

=C2=A0

=

=C2=A0 =C2=A0Subscription
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0A subscription comprises a Topic Filter and a maxim= um Quality
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0of Service (QoS).
<mglt>Maybe that would be clearer to specify QoS level as well.&= lt;/mglt>

=C2=A0

[C= S] Added.=C2=A0

= =C2=A0

=C2=A0

=

=C2=A0 = =C2=A0PINGREQ
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0A ping request se= nt from a Client to the Broker.=C2=A0 It signals
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0to the Broker that the Client is alive, and is used to<= br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0confirm that the Broker is stil= l alive.

<mglt>It may look a bit strange to have PINGREQ witho= ut PINGRESP. You
might also indicate the keep alive period is provided i= n the CONNECT</mglt>

=

=C2=A0

[CS] Added PINGRESP, clarified the Keep Alive period is set in t= he CONNECT in the definition of PINGREQ.=C2=A0

=

=C2=A0


=C2=A0 =C2=A0Will
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0An application message published by the Serv= er after the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0network connection= is closed in cases where the network
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0connection is not closed normally.=C2=A0 If the Will Flag is set,=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0then the payload of the CONNECT m= essage has information about
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0th= e Will.=C2=A0 The Will consists of the Will Properties, Will
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Topic, and Will Payload fields in the CONNEC= T message.

<mglt>
The first sentence seems to be related to= the Will message while the
intent, I suppose of teh definition was to d= efine the generic conpet of
Will. It might be clearer to expose the prin= ciple of the wil, that is a
server sends a given message in case a clien= t is disconnected
improperly. =C2=A0 It might be clearer to mention expl= icitly there is a Will
"concept" that is implemented a WillFla= g WillQoS, WillRetain in the
CONNECT header as well as other Will Proper= ties and Will Messages. This
mostly consists in the last sentence being = moved up. =C2=A0
</mglt>

=C2=A0

[CS] I reworded it - let me know if it is more clear.=C2= =A0

=C2=A0

2.= =C2=A0 Protocol Interactions

=C2=A0 =C2=A0This section describes the= following exchanges between Clients, the
=C2=A0 =C2=A0Broker, and the A= uthorization Server according to the MQTT v5.0.

<mglt> Though = english is not my first language, I have the impression the
text can be = interpreted as MQTT enables clients to establish session
which does not = seems correct to me. The text that follows clarifies this
as well. =C2= =A0
</mglt>

<= p class=3D"MsoNormal">=C2=A0

[CS] Neither mine, I reworded that as: "Authorizing connection re= quests from the Clients to the Broker"

Actually, I also went through the text to reword "= establishment" to set-up which is simpler.=C2=A0

=C2=A0

=C2=A0

2.1.=C2=A0 Authorizing Connection Establishmen= t

=C2=A0

If the
=C2=A0 =C2=A0Client is resour= ce-constrained, a Client Authorisation Server may

<mglt>I have= the impression an AS would be sufficient.</mglt>

=C2=A0

[CS] Client Authorization Server wa= s the terminology used in the Actors draft - I've removed all other ref= erences but wanted to distinguish that this is separate than the AS grantin= g access tokens.=C2=A0

C= an just say client's AS?=C2=A0


=C2=A0 =C2=A0carry out the = token request on behalf of the Client, and later,
=C2=A0 =C2=A0onboard t= he Client with the token.=C2=A0 Also, these interfaces may be
=C2=A0 =C2= =A0implemented using other protocols, e.g., CoAP or MQTT.
<mglt>W= hile the introduction and the figure mentions that HTTPS is used
as a tr= ansport, it might be worth mentioning that HTTPS is being used. I
propos= e to add "...other protocols than HTTPS, e.g ...
</mglt>

= =C2=A0

[CS] Added.=C2=A0=

=C2=A0

=C2= =A0

2.1.1.=C2=A0 Client Token R= equest to the Authorization Server (AS)

=C2=A0 =C2=A0The first step = in the protocol flow (Figure 1 (A)) is the token
=C2=A0 =C2=A0acquisitio= n by the Client from the AS.=C2=A0 When requesting an access
=C2=A0 =C2= =A0token from the AS, the Client MAY include parameters in its request
= =C2=A0 =C2=A0as defined in Section 5.6.1 of the ACE framework
=C2=A0 =C2= =A0[I-D.ietf-ace-oauth-authz].=C2=A0 The media format is 'application/<= br>=C2=A0 =C2=A0ace+json'.=C2=A0 The profile parameter MUST be set to &= #39;mqtt_tls'.=C2=A0 The
=C2=A0 =C2=A0OAuth 2.0 AS uses a JSON struc= ture in the payload of its responses
=C2=A0 =C2=A0both to client and RS.=

<mglt> I understand that some parameters are mandatory while = other are
not. I believe it might be clearer to start with the mandatory=
parameters (MUST) and then mention that other parameters are optional(MAY). That said, it might be simpler, if that is correct to mention
t= hat the token request is as described in Section 5.6.1 of the ACE framework=
=C2=A0 =C2=A0[I-D.ietf-ace-oauth-authz] with the profile set to "m= qtt".
</mglt>

=C2=A0

[CS]=C2=A0

When requesting an access token from the AS, the Client follows the token= request as is
described in Section 5.6.1 of the ACE framework, however,= it MUST set the profile parameter to 'mqtt_tls'.=C2=A0

=C2=A0

=C2=A0


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

<mglt&g= t;Error messages are handled by OAuth2.0 instead of the ACE
framework in= order to keep JSON format. I am wondering why do we have
the requiremen= t to use ace+cbor only for error message ? It seems to me
a bit strange = to have error handling defined in another document.
</mglt>=

[CS] = Should keep as-is for the time being?=C2=A0

=C2=A0


2.1.2.=C2=A0 Client Connection Requ= est to the Broker (C)

=C2=A0 =C2=A0This section describes how the Cl= ient transports the token to the
=C2=A0 =C2=A0Broker (RS) via the CONNEC= T control message after the TLS handshake.

<mglt>If the TLS ha= ndshake has already been performed, it would be good
to mention which cr= edentials have been used. Obviously, if the token is
provided by the CON= NECT message, I expect other credentials to be
involved. </mglt>

= =C2=A0

[CS] TLS handshak= e uses only server-side certificate or RPK. I think this is in the text.=C2= =A0

That said there is a= Github issue #16=C2=A0https://github.com/ace-wg/mqtt-tls-profile/i= ssues/16

around this= , and will provide other clarifications as Jim asked.=C2=A0


= =C2=A0 =C2=A0This is similar to an earlier proposal by Fremantle et al.
= =C2=A0 =C2=A0[fremantle14].=C2=A0 Alternatively, the token may be used for = the TLS
=C2=A0 =C2=A0session establishment as described in the DTLS prof= ile for ACE
=C2=A0 =C2=A0[I-D.gerdes-ace-dtls-authorize].=C2=A0 In this = case, both the TLS PSK and
=C2=A0 =C2=A0RPK handshakes MAY be supported.=
<mglt>
It would be good to expand Raw Public Keys (RPK). My r= eading is that
this section does not provide a single mechanism for the = Client to be
authenticated by the Broker, but instead two different ways= . I would
thus recommend to state it clearly in the introduction of the = section..
Currently, the section mentions:
"""
This= section describes how the Client transports the token to the
=C2=A0 =C2= =A0Broker (RS) via the CONNECT control message after the TLS handshake.
= """

An then we have a relatively detailed description= on how this is
performed using TLS. It might be better to say something= around the
following lines:
"""
This section descr= ibes how the Client transports the token to the
=C2=A0 =C2=A0Broker (RS)= . This can be achieved during the TLS KEX or during the
MQTT session est= ablishment via the CONNECT control message after the TLS handshake.
&quo= t;""

I am not sure that MAY is appropriated here. I suspec= t that if none are
supported, this method will not work. As a result, if= seems to me that
it woudl be more accurate to say that TLS Client and T= LS server MUST
support the PSK authentication as well as the raw public = key.

One issue I have with I-D.gerdes-ace-dtls-authorize that is no= w
draft-ietf-ace-dtls-authorize is that it seems to only consider TLS 1.= 2.
With TLS 1.3 PSK and RPK are supported.

My interpretation is = that PSK provides mutual authentication, but in our
case RPK will only a= uthenticate the client. If that is correct, there
might be a new to spec= ify how the RS is authenticated by the Client.

</mglt>=

=C2=A0

[CS] I will actually r= eorganize this section, and hence, this will be more clear.=C2=A0=

Added your comment to issue #29, = acknowledge that it is linked to #16 as well.=C2=A0

=

=C2=A0

I was trying to say the following, but I see that the text is no= t clear on that:

- MUST:= TLS with server validation=C2=A0+ token in MQTT CONNECT (will clarify serv= er-side certificate/RPK)

- MAY: TLS with server/client validation with RPK -> token pushed to &q= uot;authz-info"

- M= AY: TLS with server/client validation with PSK -> token in=C2=A0=C2=A0psk_identity

=

=C2=A0

=C2=A0This option is described = in more
=C2=A0 =C2=A0detail in Appendix B.

<mglt>see my com= ment in annex B.</mglt>

=C2=A0

=C2=A0

[C= S] OK.=C2=A0

=C2= =A0


=C2=A0 =C2=A0After the token acquisition, the Client connects to the R= S (Broker)
=C2=A0 =C2=A0using the CONNECT message of MQTT over TLS.=C2= =A0 For server
=C2=A0 =C2=A0authentication, the client MAY either have t= he ability to receive and
=C2=A0 =C2=A0validate a certificate or a raw p= ublic key from the Broker. =C2=A0

<mglt>I might have missed so= mething, but I thought that PSK/RPK were
used to authenticate the Client= . While in this case the RPK is used to
authenticate the RS, is that the= same RPK provided by the AS or another
one? </mglt>=

=C2=A0

[CS] No the RPK was suggested for t= he RS/Broker authentication.=C2=A0

As in the core ACE document, we assumed that the=C2=A0client learned either the RS's public key

from the AS. However, I haven't seen in the core document a= n example of how AS=C2=A0

returns this information to the = client.=C2=A0

=C2=A0

[JLS] This is done using the =E2=80=98rs_cnf=E2=80=
=99 field

=C2= =A0

=C2=A0

=C2=A0

=C2=A0 =C2=A0For token transport,= the RS SHOULD support AUTH (Authentication
=C2=A0 =C2=A0Exchange) metho= d.=C2=A0 The RS MAY support token transport via username
=C2=A0 =C2=A0an= d password, which is described in Section 3 for MQTT v3.1.1.=C2=A0 The
= =C2=A0 =C2=A0rest of this section describes the AUTH method, for which the<= br>=C2=A0 =C2=A0username and password flags MUST be set to 0.

<mg= lt>
Maybe the reference should be for MQTTv5 instead of MQTTv3.
I= believe it would be good to specify how setting the password flag
inter= acts with the Authentication method.
</mglt>

=C2=A0

=C2=A0

[CS] Do you suggest that if AUTH method is used, MQTTv5 ig= nores password/username?

=C2=A0

=C2=A0=

=C2=A0

2.1.2.1.=C2=A0 Proof-o= f-Possession over Predefined Field

=C2=A0 =C2=A0For this option, the= Authentication Data MUST contain the token and
=C2=A0 =C2=A0the keyed m= essage digest (MAC) or the Client signature.=C2=A0 To calculate
=C2=A0 = =C2=A0the keyed message digest (MAC) or the Client signature, the Client=C2=A0 =C2=A0SHOULD apply the PoP key to the CONNECT payload.

=C2= =A0 <mglt> I have the impression the latest sentence indicates that t= he
Authenticated Data is include din the CONNECT payload. I have however=
the impression that Authenticated Data is part of the properties which<= br>are include din the variable header and not the payload. </mglt> <= u>

=C2=A0

=C2=A0

[CS]=C2=A0

=

No, the CONNECT payload only includes=C2=A0Client Id= entifier, Will Properties, Will Topic, Will Payload, User Name, Password.

AUTH data is variable hea= der part of the CONNECT message.=C2=A0

Anyway, based on also Jim's input, using payload to do t= he PoP will be dropped.=C2=A0

Jim suggested we use a nonce from the tls_exporter, and apply PoP to = that.=C2=A0

We believe t= hat is the better approach as well. These are related to issues #15 (=C2=A0= https://github.com/ace-wg/mqtt-tls-profile/issues/15) and #19 (= https://github.com/ace-wg/mqtt-tls-profile/issues/19).=C2=A0=

=C2=A0

=C2=A0

The CONNECT payload
=C2=A0 = =C2=A0has at least a Client Identifier, and if the Will Flag is set to 1,=C2=A0 =C2=A0may contain Will-related information.=C2=A0 The Client Ident= ifier is a
=C2=A0 =C2=A0MUST be a UTF-8 Encoded String (i.e., is prefixe= d with a two-byte
=C2=A0 =C2=A0integer length field that gives the numbe= r of bytes in a UTF-8
=C2=A0 =C2=A0encoded string itself).=C2=A0 The Cli= ent Identifier may be 1-23 UTF-8
=C2=A0 =C2=A0encoded bytes, and contain= only the characters
=C2=A0 =C2=A0"0123456789abcdefghijklmnopqrstuv= wxyzABCDEFGHIJKLMNOPQRSTUVWXYZ".

<mglt>
For my informa= tion I would like to understand the mention of UTF8
while only ascii cha= racters are permitted. It seems that teh server MUST
accept these and MA= Y accept others as well as a longer client id. Am I
correct ?

Th= e nonce coded this way has a randomness of 62**23 =3D2**138 =3D 17 bytes</mglt>

=C2=A0

[CS] Th= is section will be changed anyway... However, need to familiarize to specif= y how to use Exporter Labels.=C2=A0=C2=A0

(Server can accept other characters.)

=C2=A0

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

=C2=A0 =C2=A0If the RS accepts t= he connection, it MUST store the token until the
=C2=A0 =C2=A0end of con= nection.=C2=A0 On Client or RS disconnection, the token is
=C2=A0 =C2=A0= discarded, and the Client MUST provide a token inside each CONNECT
=C2= =A0 =C2=A0message.

<mglt> The latest sentence is unclear to me= . I think that disconnection
can be interpreted in two way: 1) the disco= nnection of the will or a
DISCONNECT. I believe both are considered. <= ;/mglt>

=C2=A0=

[CS] Either= Client or Server may initiate a disconnection. In either case, the token i= s discarded.

The will ma= y be sent if the client set up a will in case of unexpected disconnection.<= u>

=C2=A0

=

Though it needs to be clarified for insta= nce, if there are retained messages, these are sent as long as the token is= valid.=C2=A0

Since the = introspection results are cached, this can be still done but should clarify= unless it gets confusing.=C2=A0

=C2=A0

To avoid= any confusion, and not to have to discuss these things in that section, I = reworded as:=C2=A0

On Cl= ient or RS disconnection, the Client is expected to provide a token again i= nside the next CONNECT message.

=C2=A0

=C2=A0=

=C2=A0 =C2=A0If the token is not self-contained and the Broker uses token=
=C2=A0 =C2=A0introspection, it MAY cache the validation result to autho= rize the
=C2=A0 =C2=A0subsequent PUBLISH and SUBSCRIBE messages.=C2=A0 P= UBLISH and SUBSCRIBE
=C2=A0 =C2=A0messages, which are sent after a conne= ction set-up, do not contain
=C2=A0 =C2=A0access tokens.=C2=A0 If the in= trospection result is not cached, then the
=C2=A0 =C2=A0RS needs to intr= ospect the saved token for each request.=C2=A0 The Broker
=C2=A0 =C2=A0S= HOULD use a cache time out to introspect tokens regularly.

<mglt&= gt;The latest sentence seems to indicate that result provided as
via int= rospection do not necessarily have a Time to Live which could be
interpr= eted as a commitment from the AS to authorize during that
period. If tha= t is possible, it would be appropriated this time out is
provided by the= AS.
I am also wondering why the token expiration cannot be considered a= s
well.
</mglt>

=

=C2=A0

=C2=A0

[CS] This i= s to handle the situation where the resource owner changes the permissions = of the Client, which would revoke the token.

And hence the token exp field would not help.

=C2=A0If the RS does not check t= he token introspection results, it=C2=A0

will use the token until its expiration time.=C2=A0=

I've considered this more = appropriate to be set by the RS as its RS risk management.=C2=A0<= /u>

=C2=A0

=C2=A0

Appendix B.=C2=A0 The Authorization Info= rmation Endpoint

=C2=A0 =C2=A0The main document described a method f= or transporting tokens inside
=C2=A0 =C2=A0MQTT CONNECT messages.=C2=A0 = In this section, we describe an alternative
=C2=A0 =C2=A0method to trans= port an access token.
=C2=A0 =C2=A0The method consists of the MQTT Broke= r accepting PUBLISH messages to
=C2=A0 =C2=A0a public "authz-info&q= uot; topic.=C2=A0 A Client using this method MUST first
=C2=A0 =C2=A0con= nect to the Broker, and publish the access token using the "authz-
= =C2=A0 =C2=A0info" topic.=C2=A0 The Broker must verify the validity of= the token (i.e.,
=C2=A0 =C2=A0through local validation or introspection= ).=C2=A0 After publishing the
=C2=A0 =C2=A0token, the Client disconnects= from the Broker and is expected to try
=C2=A0 =C2=A0reconnecting over T= LS.

<mglt>I understand this as an open channel for CONNECT and= sending
PUBLISHING message. This potentially open the door for DoSing t= he RS
either by openning too many MQTT sessions or by sending too many t= okens.
I expect this to be mentioned in the security consideration secti= on as
well as potential mechanisms to limit these risks.
</mglt&g= t;

=C2=A0

[CS] It is indeed m= entioned in this paragraph in the security consideration section.=C2=A0<= /u>

"The RS may monitor Cl= ient behaviour to detect potential security problems, especially those affe= cting availability.

=C2=A0The= se include repeated token transfer attempts to the public "authz-info&= quot; topic, repeated connection attempts,
=C2=A0abnormal terminations, = and Clients that connect but do not send any data.
=C2=A0If the RS suppo= rts the public "authz-info" topic, described in Appendix B,
= =C2=A0then this may be vulnerable to a DDoS attack, where many Clients use = the "authz-info" public topic
=C2=A0 =C2=A0 =C2=A0 =C2=A0to tr= ansport fictitious tokens, which RS may need to store indefinitely."

=C2=A0

<= /div>

=C2=A0

Thank you for your comments. And will try to address Jim= 9;s shortly to be able to push another version before the deadline.=C2=A0

=C2=A0

<= div>

Kind regards,=C2=A0

=

--Cigdem=C2=A0

=C2=A0

=C2=A0

=C2=A0

On Thu, Oct 17= , 2019 at 2:47 PM Jim Schaad <ietf@augustcellars.com> wrote:

=C2=A0

=C2=A0

From: Cigdem Sengul <cigdem.sengul@gmail.com>
Sent: Thurs= day, October 17, 2019 4:13 AM
To: Jim Schaad <ietf@augustcellars.com><= br>Cc: draft-ietf-ace-mqtt-tls-profile@ietf.org; ace@ietf.org
Subject: R= e: [Ace] Review for draft-ietf-ace-mqtt-tls-profile-01

=C2=A0

Hello Jim,

Thanks for = this review. I have responded inline.=C2=A0



1.=C2= =A0 Are there any specifics about using ACE over HTTP that need to be
ex= plicitly stated some place.=C2=A0 Some of these things might include:
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 a) Must be HTTPS even if encrypted requests/res= ponses are provided.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 b) What types of valid= ation are permitted/required: anon-anon,
server validation, server &= client validation. The latter corresponds to
current DTLS statements.= =C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 c) Are we looking for using the norm= al HTTP/HTTPS ports or should we
be using different ports?=C2=A0 =

=C2=A0

>> Agreed. Need to specify that it= is HTTPS.

Mutual authen= tication and server validation Required.

Was thinking it would be normal HTTPS ports. Should we co= nsider different?

What s= cenarios should permit anon-anon; anon clients?=C2=A0

=C2=A0

[JLS] If = you look at my last email I went through this.=C2=A0 Anon-anon is going to = be a bad idea because the server is never validated, however client anon is= fine since you are going to validate the client in the MQTT protocol. <= /u>

=C2=A0

=C2=A0

<= p class=3D"MsoNormal" style=3D"margin-bottom:12pt">
4.=C2=A0 Section 2.1= .2: It is not clear from the document is a Broker is going to
also have = the possibility of doing a post of the token via HTTPS.=C2=A0 Currently
= I would think not, but given that this is documented in OAuth 2.0 as an
= option I am not clear.

>> Do you mean for introspection? Yes, this is a MAY as in the = core document, and so in this one too.=C2=A0

And if there is an RS-AS interaction, we expect that t= o be on HTTPS.=C2=A0

I w= ill try to see where I should clarify in the text.=C2=A0

<= p class=3D"MsoNormal">=C2=A0

[JLS] = No, I was originally looking at doing an HTTPS post of the token from the c= lient to the RS.=C2=A0 This was before I figured out that you have an alter= native method of doing this in the MQTT protocol and so it should not be ne= eded.=C2=A0 =C2=A0Being clear on the fact that this would not be expected i= s probably a good idea.

= =C2=A0


7.=C2= =A0 =C2=A0In Figure 2, I think the use of Client Identifier is somewhat
= confusing.=C2=A0 I think this is supposed to be the token as the Client
= Identifier is a different thing in MQTT.=C2=A0 Either that or you need to d= o a
better job of describing the property block.

=C2=A0

OK. I think I should explain MQTT packets better.=C2=A0

A connect packet has thre= e parts: 1) Fixed header 2) Variable Header and 3) Payload.

The variable header may have several pr= operties, and Authentication Method and Authentication Data are two of thes= e properties.=C2=A0

Acco= rding to MQTT Specification:

<= p class=3D"MsoNormal">The ClientID MUST be a UTF-8 Encoded S= tring

A Server MAY allow a Client to supply a ClientID that has a length of z= ero bytes,=C2=A0however, if it does so the Server MUST treat this as a spec= ial case.

=C2=A0<= u>

And this is what is done = in the case of a collision:

If the ClientID represents a Client already conne= cted to the Server, the Server sends a DISCONNECT packet to the existing Cl= ient with Reason Code of 0x8E (Session taken over)=C2=A0

=C2=A0

=

Is this more clear? If yes, I will try to clarify in= text.=C2=A0

=C2=A0

[JLS] That is not where I was having a problem.=C2= =A0 I was getting confused by the figure itself.=C2=A0 Labeling the figure = better might help.=C2=A0 =E2=80=9CMQTT V5.0 CONNECT control message with = =E2=80=98ace=E2=80=99 authentication method=E2=80=9D.=C2=A0 I would rather = not have all of the abbreviations in the title, but I can live with it.<= /u>

=C2=A0


8.=C2=A0 If the value of Clean Start or Expiry Interval are not s= et correct is
the server to fail the connect?

=C2=A0

>> Agreed. This should be specified.=C2=A0

Two options: 1) Do not accept conne= ction or 2) accept the connection but then never create sessions, and then = server=C2=A0=C2=A0MUST set Session Present to 0 in the CONNA= CK packet, indicating=C2=A0

no session is present.=C2=A0=

=C2=A0

This basically makes Clean Start flag meaningless.=C2= =A0

If this is better th= an client MUST be setting those parameters correctly, then we can go this w= ay.=C2=A0

Any thoughts?<= u>

=C2=A0

[JLS] I don=E2=80=99t really care one way or the other.=C2=A0 G= iven that there is the return value in the CONNACK, I think that a simple s= tatement that the flag is set to 0 regardless of the value coming in.=C2=A0=

=C2=A0

10. Section 2.1.2.1 - I am having a problem computing the MAC over thepayload of the CONNECT message.=C2=A0 The password where the value is plac= ed is
included in the payload and I am not clear if it should be compute= d up to
that value or if a fixed value should be used for the computatio= n.

=C2=A0<= u>

>>OK. I think it got mudd= led because I was trying to find a solution for a scenario where the Client= Id is used across sessions, and hence, not random.=C2=A0

<= /div>

=C2=A0

Two cases.

1) Client ID uniquely random across each Client connection attempt to Br= oker: MAC over Payload - Payload begins with ClientID and MAY include Will = Properties if Client indicated that it will have a will.=C2=A0

2) Client ID NOT uniquely random: MA= C over Authentication Data.=C2=A0

=C2=A0

It may = be best to choose one method and just say MUST always have a nonce in Authe= ntication Data, and MAC is computed over that?

=C2=A0

[JLS] Lets step = back and look at the problem I think you are trying to solve.=C2=A0 =C2=A0= =C2=A0

  • If you ar= e trying to make sure that there is not a replay of the signature, then thi= s would require that the server keep track of the list of nonce values that= the client has provided.
  • =C2=A0= If you are trying to make sure that the signature is =E2=80=9Cfresh=E2=80= =9D then the server would need to be able to provide some type of data as p= art of the value being signed.=C2=A0 As I think I have said before the latt= er can be satisfied by getting your nonce value from the TLS session using = a tls-exporter.

= =C2=A0

If neither of these problems= is trying to be solved, then there is no need for the nonce at all.=

=C2=A0

=C2=A0

11. I am worried about the text on the Client Identifier in this se= ction.
It is not clear to me that having the client generate a random va= lue for
this field is good just in terms of the possibility of collision= s occurring
on the server.=C2=A0 The text in the MQTT 5.0 document appea= rs to say that this
is more interesting for the situation of getting bac= k state that was left on
the server after a disconnect and not so much f= or a clean session.

=C2=A0

>> Yes, = but as I explained for comment 7, in MQTT, the typical case is the client p= rovides its id.=C2=A0

Ho= wever, to cater to all requirements and all implementation possibilities, m= aybe it is best to just use a nonce as explained for comment 10 and not tie= anything to client id.

= =C2=A0

Previously, when = we were writing the draft for MQTT v3.1.1 we wanted to provide a solution t= hat uses the available fields in the CONNECT packet as much as possible; wi= thout

introducing any ne= w fields. This was because of the constraints of the MQTT v3.1.1. MQTT v5 g= ives us more options to implement this better.

=

=C2=A0

For backward compatibility, we would need to think if we create a spe= cial data structure to be used in the password so that it holds both the MA= C/signature and the nonce.=C2=A0 =C2=A0

=C2=A0

A= s the use of ClientId seems to create confusion, I am leaning towards this = solution. Any thoughts?

=C2=A0

[JLS] Look at the previous answer and t= he re-ask the question.

= =C2=A0

=C2=A0<= /u>

13. Is there someplace that authentication methods need to be registered= ?=C2=A0 I
was unable to see any such registry setup with OASIS from the = v5
specification.=C2=A0 Should we suggest to the MQTT group that this is= something
that should be done?

=C2=A0

>> This is an interesting thought. The draft was indeed discussed in= the OASIS MQTT WG.=C2=A0

=C2=A0

But, the WG may= consider this out of scope, as they have on their charter page:<= /u>

=C2=A0Transport level security is as= sumed and no mandatory security features will be added.

The MQTT v5 draft says:

The Authentication Method is commonly a= SASL mechanism, and using such a registered name aids interchange. However= , the Authentication Method is not constrained to using registered SASL mec= hanisms.

=C2=A0

[JLS] I think that the lack of a= registry should be identified someplace in the document.=C2=A0 This is pro= bably a security consideration that there might be a different authenticati= on method which re-uses the same authentication method name.<= /p>

=C2=A0

=C2=A0

17.=C2=A0 It is not clear to me, how in the sc= ope string is the ability to have a
"will" indicated? <= u>

>>=C2=A0If the Will F= lag is set to 1, the Will Topic follows the Client ID and Will Properties i= n the Payload.

This = is where the broker learns the Will Topic.=C2=A0

Then the scope would be publish_<will topic= >.=C2=A0

And subs= cribes would need to subscribe_<will topic> to receive this message.= =C2=A0

Will clarify = in text.

=C2=A0

[JLS] publish makes sense to me.=C2=A0 I was ju= st being overly complicated.

=C2=A0

18.=C2=A0 Section 2.1.4 - I am unsure what the imp= lications of discarding tokens
on the end of a connection are going to b= e.=C2=A0 How do you publish the token
before doing the connection or is = that only for an updated token?

=C2=A0

&g= t;> Tokens are discarded at the end of disconnection because no previous= session state is kept.

= And a token is expected in the new CONNECT request (otherwise, it is AS dis= covery)

=C2=A0=

Before the connection, a token ma= y be transported via=C2=A0 "authz-info" topic described in Append= ix B.=C2=A0

During the c= onnection, a new token may be transported via the AUTH packet - which enabl= es reauthentication.=C2=A0

=C2=A0

[JLS] This is still not clear to me.= =C2=A0 Is the transport of the token via =E2=80=9Cauth-info=E2=80=9D topic = not considered to be part of the session?=C2=A0 If you say that you look at= just the last value published, then is there not going to be a race condit= ion between two different clients trying to publish and connect?=C2=A0 <= /u>

=C2=A0


20.=C2=A0 I am not sure what the benefits o= f doing the check on a PINGREQUEST is
going to be.=C2=A0 Like the relay = of a PUBLISH message this is just going to
produce a DISCONNECT and a cl= osed channel.=C2=A0 If this is really allowed, then
you should potential= ly also say that the Broker could do a check based on
clock time elapsin= g.=C2=A0 (I.e. do the check every hour.)

=C2=A0

>> This was suggested by one of the reviewers that provide MQT= T services (his e-mail regarding this was sent to the ace list).=C2=A0

It was suggested as an optim= ization for detecting token expirations and disconnecting early.=C2=A0

(i.e., if you are already re= ceiving PINGREQUESTs, use these as a trigger to check the token).=C2=A0<= /u>

I think time-based checks m= ay also help and be added as an option.

=C2=A0

[JLS] Ok<= /p>

=C2=A0


22. Not sure if this goes here or in the co= nnect documentation.=C2=A0 There needs
to be a check that the will topic= is a topic that the client is going to be
permitted to publish on.=C2= =A0 =C2=A0Corner case, if the ability to publish a will in
the event tha= t this permission is lost.=C2=A0 Does this kill the session or the
will = message?=C2=A0 I.e. should the permission for the will message be rechecked=
before sending it allowing for the time based expiration of the token.<= u>

=C2=A0<= /u>

>> We have been thinking abo= ut this.=C2=A0

If the di= sconnect is due to a token expiration, and hence, also includes the will to= pic as well, you have to decide between:

1) publish the will

2) do not publish the will.=C2=A0

At the moment, it's written like we publish th= e will - but on second consideration,=C2=A0

it seems safer to say "Publish the Will on Server = Disconnect or unusual disconnect if the token (the will permission) has not= expired".=C2=A0

=C2=A0=

[JLS] I would be fine with either positio= n, after all at the time the =E2=80=9Cpublish=E2=80=9D event occurred the t= oken was valid, this is just deferring relaying it to subscribers.=C2=A0

=C2=A0

Jim

=C2=A0=

=C2=A0

Thanks again for these comments, will create the neces= sary github issues and start revising the text.=C2=A0

=C2=A0

Best,=C2=A0

=C2=A0


Ji= m









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

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

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

--0000000000001ea1cf0596234ef0-- From nobody Wed Oct 30 10:07:05 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62FFE120888; Wed, 30 Oct 2019 10:07:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gwdCtgAIpB8g; Wed, 30 Oct 2019 10:06:58 -0700 (PDT) Received: from mail-vs1-f47.google.com (mail-vs1-f47.google.com [209.85.217.47]) (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 221031208A9; Wed, 30 Oct 2019 10:06:55 -0700 (PDT) Received: by mail-vs1-f47.google.com with SMTP id w25so2155941vso.4; Wed, 30 Oct 2019 10:06:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=j23HXhvFO4/uhqs7HjCkLsLtpqpNhZbluFDfp2bh0SI=; b=avFXWLWZLlXvkYjSkJ96lhls+xdyCTQ/7FYrXlB4HQ7AWJxnkIq0JsT/n1W0FabmzL QCYuVLZH8taZKSltXK5XtTJdb6UUVRXEDEWXv7Z4vCrY26hkaWEc/dA55iJw0CRUqSTn VkqCbVHp27MLyZDE5sPmND45UmJPp/NpJH/YSJtbT7+L8ua/oWyXSYWvoJ0TCXhAyAq6 pm5Q1b1GLRBt2RzVs+ZtQPOv97anAb+hZ8e5AXW1w5dcUuhkJmELG3V6UVKZZgkMZrL+ 5bQfILBLtaCjCenfn2BCr8MJIqsgd8gX1gb6TTlKYpzYTRzF2iE/dNAbSUdsJBCqR9ie PHIA== X-Gm-Message-State: APjAAAVYXU7cCfA5H+28WtKkHQrhvsVwBpKpHaM0Daz0DxzLKKnDr8zZ HIzQZyCQ34+TmEPkcgAwHdccMmqyVuIdN6gvvBw= X-Google-Smtp-Source: APXvYqyQgkr/l8iviNOtwA/jisC+8WzDK5jkHig79InwAuk5+HVqtxBfbnFFXCSflrTe2PJEf50hbzHhfXbF60two14= X-Received: by 2002:a05:6102:1178:: with SMTP id k24mr270846vsg.97.1572455213779; Wed, 30 Oct 2019 10:06:53 -0700 (PDT) MIME-Version: 1.0 References: <021c01d5839c$d53206a0$7f9613e0$@augustcellars.com> <033101d5851b$30a41ad0$91ec5070$@augustcellars.com> In-Reply-To: From: Daniel Migault Date: Wed, 30 Oct 2019 13:06:42 -0400 Message-ID: To: Cigdem Sengul Cc: Daniel Migault , draft-ietf-ace-mqtt-tls-profile@ietf.org, Jim Schaad , ace@ietf.org Content-Type: multipart/alternative; boundary="000000000000714ec0059623c27d" Archived-At: Subject: Re: [Ace] Review for draft-ietf-ace-mqtt-tls-profile-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: Wed, 30 Oct 2019 17:07:03 -0000 --000000000000714ec0059623c27d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thank you for the response. Feel free to publish the updated version. Please see my comments inline. Yours, Daniel On Wed, Oct 30, 2019 at 12:13 PM Cigdem Sengul wrote: > Thank you for your comments Daniel (prefixed [CS]) > My comments are inside. I've also created the -v-02-WIP branch for the > work in progress based on your and Jim's comments. > > On Thu, Oct 24, 2019 at 2:50 AM Daniel Migault 40ericsson.com@dmarc.ietf.org> wrote: > >> HI, >> >> Thanks for sending an update. Please find my comments of the draft. >> >> This document makes the same assumptions as the Section 4 of the ACE >> framework [I-D.ietf-ace-oauth-authz] regarding Client and RS >> registration with the AS and establishing of keying material. >> >> The document seems mostly focuses on the latest version of MQTT, >> I am wondering if we could encourage similarly the use of the latest >> version of TLS that is 1.3 at the time of writing. >> >> It seems AS as not been defined previously, so maybe it should be >> expanded there. >> >> > > [CS] Can add a similar recommendation for TLS 1.3. > AS is expanded. > > > >> >> MQTTS >> Secured transport profile of MQTT. MQTTS runs over TLS. >> The Server in MQTT acts as an intermediary between >> Clients that publishes Application Messages, and the Clients >> that made Subscriptions. The Broker acts as the Resource >> Server for the Clients. >> >> publishes >> > [CS] Fixed. > > > >> >> Subscription >> A subscription comprises a Topic Filter and a maximum Quality >> of Service (QoS). >> >> Maybe that would be clearer to specify QoS level as well. >> > > [CS] Added. > > > >> PINGREQ >> A ping request sent from a Client to the Broker. It signals >> to the Broker that the Client is alive, and is used to >> confirm that the Broker is still alive. >> >> It may look a bit strange to have PINGREQ without PINGRESP. You >> might also indicate the keep alive period is provided in the >> CONNECT >> > > [CS] Added PINGRESP, clarified the Keep Alive period is set in the CONNEC= T > in the definition of PINGREQ. > > >> >> Will >> An application message published by the Server after the >> network connection is closed in cases where the network >> connection is not closed normally. If the Will Flag is set, >> then the payload of the CONNECT message has information about >> the Will. The Will consists of the Will Properties, Will >> Topic, and Will Payload fields in the CONNECT message. >> >> >> The first sentence seems to be related to the Will message while the >> intent, I suppose of teh definition was to define the generic conpet of >> Will. It might be clearer to expose the principle of the wil, that is a >> server sends a given message in case a client is disconnected >> improperly. It might be clearer to mention explicitly there is a Will >> "concept" that is implemented a WillFlag WillQoS, WillRetain in the >> CONNECT header as well as other Will Properties and Will Messages. This >> mostly consists in the last sentence being moved up. >> >> > > [CS] I reworded it - let me know if it is more clear. > will have a look. > >> 2. Protocol Interactions >> >> This section describes the following exchanges between Clients, the >> Broker, and the Authorization Server according to the MQTT v5.0. >> >> Though english is not my first language, I have the impression th= e >> text can be interpreted as MQTT enables clients to establish session >> which does not seems correct to me. The text that follows clarifies this >> as well. >> >> > > [CS] Neither mine, I reworded that as: "Authorizing connection requests > from the Clients to the Broker" > Actually, I also went through the text to reword "establishment" to set-u= p > which is simpler. > ok > > >> >> 2.1. Authorizing Connection Establishment >> >> If the >> Client is resource-constrained, a Client Authorisation Server may >> >> I have the impression an AS would be sufficient. >> > > [CS] Client Authorization Server was the terminology used in the Actors > draft - I've removed all other references but wanted to distinguish that > this is separate than the AS granting access tokens. > Can just say client's AS? > Maybe just explicitly saying it is different would be clearer. I will have to re-read it. > >> carry out the token request on behalf of the Client, and later, >> onboard the Client with the token. Also, these interfaces may be >> implemented using other protocols, e.g., CoAP or MQTT. >> While the introduction and the figure mentions that HTTPS is used >> as a transport, it might be worth mentioning that HTTPS is being used. I >> propose to add "...other protocols than HTTPS, e.g ... >> >> > > [CS] Added. > > >> 2.1.1. Client Token Request to the Authorization Server (AS) >> >> The first step in the protocol flow (Figure 1 (A)) is the token >> acquisition by the Client from the AS. When requesting an access >> token from the AS, the Client MAY include parameters in its request >> as defined in Section 5.6.1 of the ACE framework >> [I-D.ietf-ace-oauth-authz]. The media format is 'application/ >> ace+json'. The profile parameter MUST be set to 'mqtt_tls'. The >> OAuth 2.0 AS uses a JSON structure in the payload of its responses >> both to client and RS. >> >> I understand that some parameters are mandatory while other are >> not. I believe it might be clearer to start with the mandatory >> parameters (MUST) and then mention that other parameters are optional >> (MAY). That said, it might be simpler, if that is correct to mention >> that the token request is as described in Section 5.6.1 of the ACE >> framework >> [I-D.ietf-ace-oauth-authz] with the profile set to "mqtt". >> >> > > [CS] > When requesting an access token from the AS, the Client follows the token > request as is > described in Section 5.6.1 of the ACE framework, however, it MUST set the > profile parameter to 'mqtt_tls'. > > >> >> >> In the case of an error, the AS returns error responses for HTTP- >> based interactions as ASCII codes in JSON content, as defined in >> Section 5.2 of RFC 6749 [RFC6749]. >> >> Error messages are handled by OAuth2.0 instead of the ACE >> framework in order to keep JSON format. I am wondering why do we have >> the requirement to use ace+cbor only for error message ? It seems to me >> a bit strange to have error handling defined in another document. >> >> >> [CS] Should keep as-is for the time being? > That was just a comment. I do not believe you could address this. So yes let's keep it this way. > > >> >> 2.1.2. Client Connection Request to the Broker (C) >> >> This section describes how the Client transports the token to the >> Broker (RS) via the CONNECT control message after the TLS handshake. >> >> If the TLS handshake has already been performed, it would be good >> to mention which credentials have been used. Obviously, if the token is >> provided by the CONNECT message, I expect other credentials to be >> involved. >> > > [CS] TLS handshake uses only server-side certificate or RPK. I think this > is in the text.. > That said there is a Github issue #16 > https://github.com/ace-wg/mqtt-tls-profile/issues/16 > around this, and will provide other clarifications as Jim asked. > great! > >> This is similar to an earlier proposal by Fremantle et al. >> [fremantle14]. Alternatively, the token may be used for the TLS >> session establishment as described in the DTLS profile for ACE >> [I-D.gerdes-ace-dtls-authorize]. In this case, both the TLS PSK and >> RPK handshakes MAY be supported. >> >> It would be good to expand Raw Public Keys (RPK). My reading is that >> this section does not provide a single mechanism for the Client to be >> authenticated by the Broker, but instead two different ways. I would >> thus recommend to state it clearly in the introduction of the section.. >> Currently, the section mentions: >> """ >> This section describes how the Client transports the token to the >> Broker (RS) via the CONNECT control message after the TLS handshake. >> """ >> >> An then we have a relatively detailed description on how this is >> performed using TLS. It might be better to say something around the >> following lines: >> """ >> This section describes how the Client transports the token to the >> Broker (RS). This can be achieved during the TLS KEX or during the >> MQTT session establishment via the CONNECT control message after the TLS >> handshake. >> """ >> >> I am not sure that MAY is appropriated here. I suspect that if none are >> supported, this method will not work. As a result, if seems to me that >> it woudl be more accurate to say that TLS Client and TLS server MUST >> support the PSK authentication as well as the raw public key. >> >> One issue I have with I-D.gerdes-ace-dtls-authorize that is now >> draft-ietf-ace-dtls-authorize is that it seems to only consider TLS 1.2. >> With TLS 1.3 PSK and RPK are supported. >> >> My interpretation is that PSK provides mutual authentication, but in our >> case RPK will only authenticate the client. If that is correct, there >> might be a new to specify how the RS is authenticated by the Client. >> >> >> > > [CS] I will actually reorganize this section, and hence, this will be mor= e > clear. > Added your comment to issue #29, acknowledge that it is linked to #16 as > well. > > I was trying to say the following, but I see that the text is not clear o= n > that: > - MUST: TLS with server validation + token in MQTT CONNECT (will clarify > server-side certificate/RPK) > - MAY: TLS with server/client validation with RPK -> token pushed to > "authz-info" > - MAY: TLS with server/client validation with PSK -> token in > psk_identity > ok, it is also good to clarify which layer performs the authentication. Will have a look at the text when the new version is published. > > >> This option is described in more >> detail in Appendix B.. >> >> see my comment in annex B. >> >> > [CS] OK. > > >> After the token acquisition, the Client connects to the RS (Broker) >> using the CONNECT message of MQTT over TLS. For server >> authentication, the client MAY either have the ability to receive and >> validate a certificate or a raw public key from the Broker. >> >> I might have missed something, but I thought that PSK/RPK were >> used to authenticate the Client. While in this case the RPK is used to >> authenticate the RS, is that the same RPK provided by the AS or another >> one? >> > > [CS] No the RPK was suggested for the RS/Broker authentication. > As in the core ACE document, we assumed that the client learned either > the RS's public key > from the AS. However, I haven't seen in the core document an example of > how AS > returns this information to the client. > Ok, this might need to be clarified even if that seems outside your document. > > > > For token transport, the RS SHOULD support AUTH (Authentication >> Exchange) method. The RS MAY support token transport via username >> and password, which is described in Section 3 for MQTT v3.1.1. The >> rest of this section describes the AUTH method, for which the >> username and password flags MUST be set to 0. >> >> >> Maybe the reference should be for MQTTv5 instead of MQTTv3. >> I believe it would be good to specify how setting the password flag >> interacts with the Authentication method. >> >> >> >> [CS] Do you suggest that if AUTH method is used, MQTTv5 ignores > password/username? > I think I was wondering why MQTT v3 was mentioned rather than v5. It seems to me that there is no difference in our case - the only change being that v5 permit password only. > > > > >> 2.1.2.1. Proof-of-Possession over Predefined Field >> >> For this option, the Authentication Data MUST contain the token and >> the keyed message digest (MAC) or the Client signature. To calculate >> the keyed message digest (MAC) or the Client signature, the Client >> SHOULD apply the PoP key to the CONNECT payload. >> >> I have the impression the latest sentence indicates that the >> Authenticated Data is include din the CONNECT payload. I have however >> the impression that Authenticated Data is part of the properties which >> are include din the variable header and not the payload. >> > > > [CS] > No, the CONNECT payload only includes Client Identifier, Will Properties, > Will Topic, Will Payload, User Name, Password. > AUTH data is variable header part of the CONNECT message. > Anyway, based on also Jim's input, using payload to do the PoP will be > dropped. > Jim suggested we use a nonce from the tls_exporter, and apply PoP to that= . > We believe that is the better approach as well. These are related to > issues #15 ( https://github.com/ace-wg/mqtt-tls-profile/issues/15) and > #19 (https://github.com/ace-wg/mqtt-tls-profile/issues/19). > > That is probably better to bind with the TLS. Please also clarify how it could work with early_exporters, if that works. > > The CONNECT payload >> has at least a Client Identifier, and if the Will Flag is set to 1, >> may contain Will-related information. The Client Identifier is a >> MUST be a UTF-8 Encoded String (i.e., is prefixed with a two-byte >> integer length field that gives the number of bytes in a UTF-8 >> encoded string itself). The Client Identifier may be 1-23 UTF-8 >> encoded bytes, and contain only the characters >> "0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ". >> >> >> For my information I would like to understand the mention of UTF8 >> while only ascii characters are permitted. It seems that teh server MUST >> accept these and MAY accept others as well as a longer client id. Am I >> correct ? >> >> The nonce coded this way has a randomness of 62**23 =3D2**138 =3D 17 byt= es >> >> > > [CS] This section will be changed anyway... However, need to familiarize > to specify how to use Exporter Labels. > (Server can accept other characters.) > > 2.1.4. The Broker's Response to Client Connection Request >> >> If the RS accepts the connection, it MUST store the token until the >> end of connection. On Client or RS disconnection, the token is >> discarded, and the Client MUST provide a token inside each CONNECT >> message. >> >> The latest sentence is unclear to me. I think that disconnection >> can be interpreted in two way: 1) the disconnection of the will or a >> DISCONNECT. I believe both are considered. >> >> [CS] Either Client or Server may initiate a disconnection. In either > case, the token is discarded. > The will may be sent if the client set up a will in case of unexpected > disconnection. > > Though it needs to be clarified for instance, if there are retained > messages, these are sent as long as the token is valid. > Since the introspection results are cached, this can be still done but > should clarify unless it gets confusing. > > To avoid any confusion, and not to have to discuss these things in that > section, I reworded as: > On Client or RS disconnection, the Client is expected to provide a token > again inside the next CONNECT message. > > seems fine > > >> If the token is not self-contained and the Broker uses token >> introspection, it MAY cache the validation result to authorize the >> subsequent PUBLISH and SUBSCRIBE messages. PUBLISH and SUBSCRIBE >> messages, which are sent after a connection set-up, do not contain >> access tokens. If the introspection result is not cached, then the >> RS needs to introspect the saved token for each request. The Broker >> SHOULD use a cache time out to introspect tokens regularly. >> >> The latest sentence seems to indicate that result provided as >> via introspection do not necessarily have a Time to Live which could be >> interpreted as a commitment from the AS to authorize during that >> period. If that is possible, it would be appropriated this time out is >> provided by the AS. >> I am also wondering why the token expiration cannot be considered as >> well. >> >> > > > [CS] This is to handle the situation where the resource owner changes the > permissions of the Client, which would revoke the token. > And hence the token exp field would not help. > If the RS does not check the token introspection results, it > will use the token until its expiration time. > I've considered this more appropriate to be set by the RS as its RS risk > management. > I do understand but I am questioning whether this is necessary or useful. > > >> >> Appendix B. The Authorization Information Endpoint >> >> The main document described a method for transporting tokens inside >> MQTT CONNECT messages. In this section, we describe an alternative >> method to transport an access token. >> The method consists of the MQTT Broker accepting PUBLISH messages to >> a public "authz-info" topic. A Client using this method MUST first >> connect to the Broker, and publish the access token using the "authz- >> info" topic. The Broker must verify the validity of the token (i.e., >> through local validation or introspection). After publishing the >> token, the Client disconnects from the Broker and is expected to try >> reconnecting over TLS. >> >> I understand this as an open channel for CONNECT and sending >> PUBLISHING message. This potentially open the door for DoSing the RS >> either by openning too many MQTT sessions or by sending too many tokens. >> I expect this to be mentioned in the security consideration section as >> well as potential mechanisms to limit these risks. >> >> > > [CS] It is indeed mentioned in this paragraph in the security > consideration section. > "The RS may monitor Client behaviour to detect potential security > problems, especially those affecting availability. > These include repeated token transfer attempts to the public "authz-info= " > topic, repeated connection attempts, > abnormal terminations, and Clients that connect but do not send any data= .. > If the RS supports the public "authz-info" topic, described in Appendix = B, > then this may be vulnerable to a DDoS attack, where many Clients use the > "authz-info" public topic > to transport fictitious tokens, which RS may need to store > indefinitely." > > > Thank you for your comments. And will try to address Jim's shortly to be > able to push another version before the deadline. > perfect, the dead line is monday I think. > > Kind regards, > --Cigdem > > >> >> >> On Thu, Oct 17, 2019 at 2:47 PM Jim Schaad >> wrote: >> >>> >>> >>> >>> >>> *From:* Cigdem Sengul >>> *Sent:* Thursday, October 17, 2019 4:13 AM >>> *To:* Jim Schaad >>> *Cc:* draft-ietf-ace-mqtt-tls-profile@ietf.org; ace@ietf.org >>> *Subject:* Re: [Ace] Review for draft-ietf-ace-mqtt-tls-profile-01 >>> >>> >>> >>> Hello Jim, >>> >>> Thanks for this review. I have responded inline. >>> >>> >>> >>> 1. Are there any specifics about using ACE over HTTP that need to be >>> explicitly stated some place. Some of these things might include: >>> a) Must be HTTPS even if encrypted requests/responses are >>> provided. >>> b) What types of validation are permitted/required: anon-anon, >>> server validation, server & client validation. The latter corresponds t= o >>> current DTLS statements. >>> c) Are we looking for using the normal HTTP/HTTPS ports or >>> should we >>> be using different ports? >>> >>> >>> >>> >> Agreed. Need to specify that it is HTTPS. >>> >>> Mutual authentication and server validation Required. >>> >>> Was thinking it would be normal HTTPS ports. Should we consider >>> different? >>> >>> What scenarios should permit anon-anon; anon clients? >>> >>> >>> >>> [JLS] If you look at my last email I went through this. Anon-anon is >>> going to be a bad idea because the server is never validated, however >>> client anon is fine since you are going to validate the client in the M= QTT >>> protocol. >>> >>> >>> >>> >>> >>> >>> 4. Section 2.1.2: It is not clear from the document is a Broker is >>> going to >>> also have the possibility of doing a post of the token via HTTPS. >>> Currently >>> I would think not, but given that this is documented in OAuth 2.0 as an >>> option I am not clear. >>> >>> >> Do you mean for introspection? Yes, this is a MAY as in the core >>> document, and so in this one too. >>> >>> And if there is an RS-AS interaction, we expect that to be on HTTPS. >>> >>> I will try to see where I should clarify in the text. >>> >>> >>> >>> [JLS] No, I was originally looking at doing an HTTPS post of the token >>> from the client to the RS. This was before I figured out that you have= an >>> alternative method of doing this in the MQTT protocol and so it should = not >>> be needed.. Being clear on the fact that this would not be expected i= s >>> probably a good idea. >>> >>> >>> >>> >>> 7. In Figure 2, I think the use of Client Identifier is somewhat >>> confusing. I think this is supposed to be the token as the Client >>> Identifier is a different thing in MQTT. Either that or you need to do= a >>> better job of describing the property block. >>> >>> >>> >>> OK. I think I should explain MQTT packets better. >>> >>> A connect packet has three parts: 1) Fixed header 2) Variable Header an= d >>> 3) Payload. >>> >>> The variable header may have several properties, and Authentication >>> Method and Authentication Data are two of these properties. >>> >>> According to MQTT Specification: >>> >>> The ClientID MUST be present and is the first field in the CONNECT >>> packet Payload. >>> >>> The ClientID MUST be a UTF-8 Encoded String >>> >>> A Server MAY allow a Client to supply a ClientID that has a length of >>> zero bytes, however, if it does so the Server MUST treat this as a spec= ial >>> case. >>> >>> >>> >>> And this is what is done in the case of a collision: >>> >>> If the ClientID represents a Client already connected to the Server, th= e >>> Server sends a DISCONNECT packet to the existing Client with Reason Cod= e of >>> 0x8E (Session taken over) >>> >>> >>> >>> Is this more clear? If yes, I will try to clarify in text.. >>> >>> >>> >>> [JLS] That is not where I was having a problem. I was getting confused >>> by the figure itself. Labeling the figure better might help. =E2=80= =9CMQTT V5.0 >>> CONNECT control message with =E2=80=98ace=E2=80=99 authentication metho= d=E2=80=9D. I would rather >>> not have all of the abbreviations in the title, but I can live with it. >>> >>> >>> >>> >>> 8. If the value of Clean Start or Expiry Interval are not set correct = is >>> the server to fail the connect? >>> >>> >>> >>> >> Agreed. This should be specified. >>> >>> Two options: 1) Do not accept connection or 2) accept the connection bu= t >>> then never create sessions, and then server MUST set Session Present >>> to 0 in the CONNACK packet, indicating >>> >>> no session is present. >>> >>> >>> >>> This basically makes Clean Start flag meaningless. >>> >>> If this is better than client MUST be setting those parameters >>> correctly, then we can go this way. >>> >>> Any thoughts? >>> >>> >>> >>> [JLS] I don=E2=80=99t really care one way or the other. Given that the= re is the >>> return value in the CONNACK, I think that a simple statement that the f= lag >>> is set to 0 regardless of the value coming in. >>> >>> >>> >>> >>> 10. Section 2.1.2.1 - I am having a problem computing the MAC over the >>> payload of the CONNECT message. The password where the value is placed >>> is >>> included in the payload and I am not clear if it should be computed up = to >>> that value or if a fixed value should be used for the computation. >>> >>> >>> >>> >>OK. I think it got muddled because I was trying to find a solution fo= r >>> a scenario where the ClientId is used across sessions, and hence, not >>> random. >>> >>> >>> >>> Two cases. >>> >>> 1) Client ID uniquely random across each Client connection attempt to >>> Broker: MAC over Payload - Payload begins with ClientID and MAY include >>> Will Properties if Client indicated that it will have a will. >>> >>> 2) Client ID NOT uniquely random: MAC over Authentication Data. >>> >>> >>> >>> It may be best to choose one method and just say MUST always have a >>> nonce in Authentication Data, and MAC is computed over that? >>> >>> >>> >>> [JLS] Lets step back and look at the problem I think you are trying to >>> solve. >>> >>> - If you are trying to make sure that there is not a replay of the >>> signature, then this would require that the server keep track of the= list >>> of nonce values that the client has provided. >>> - If you are trying to make sure that the signature is =E2=80=9Cfre= sh=E2=80=9D then >>> the server would need to be able to provide some type of data as par= t of >>> the value being signed. As I think I have said before the latter ca= n be >>> satisfied by getting your nonce value from the TLS session using a >>> tls-exporter. >>> >>> >>> >>> If neither of these problems is trying to be solved, then there is no >>> need for the nonce at all. >>> >>> >>> >>> >>> >>> 11. I am worried about the text on the Client Identifier in this sectio= n. >>> It is not clear to me that having the client generate a random value fo= r >>> this field is good just in terms of the possibility of collisions >>> occurring >>> on the server. The text in the MQTT 5.0 document appears to say that >>> this >>> is more interesting for the situation of getting back state that was >>> left on >>> the server after a disconnect and not so much for a clean session. >>> >>> >>> >>> >> Yes, but as I explained for comment 7, in MQTT, the typical case is >>> the client provides its id. >>> >>> However, to cater to all requirements and all implementation >>> possibilities, maybe it is best to just use a nonce as explained for >>> comment 10 and not tie anything to client id. >>> >>> >>> >>> Previously, when we were writing the draft for MQTT v3.1.1 we wanted to >>> provide a solution that uses the available fields in the CONNECT packet= as >>> much as possible; without >>> >>> introducing any new fields. This was because of the constraints of the >>> MQTT v3.1.1. MQTT v5 gives us more options to implement this better. >>> >>> >>> >>> For backward compatibility, we would need to think if we create a >>> special data structure to be used in the password so that it holds both= the >>> MAC/signature and the nonce. >>> >>> >>> >>> As the use of ClientId seems to create confusion, I am leaning towards >>> this solution. Any thoughts? >>> >>> >>> >>> [JLS] Look at the previous answer and the re-ask the question. >>> >>> >>> >>> >>> >>> 13. Is there someplace that authentication methods need to be >>> registered? I >>> was unable to see any such registry setup with OASIS from the v5 >>> specification. Should we suggest to the MQTT group that this is >>> something >>> that should be done? >>> >>> >>> >>> >> This is an interesting thought. The draft was indeed discussed in th= e >>> OASIS MQTT WG. >>> >>> >>> >>> But, the WG may consider this out of scope, as they have on their >>> charter page: >>> >>> Transport level security is assumed and no mandatory security features >>> will be added. >>> >>> The MQTT v5 draft says: >>> >>> The Authentication Method is commonly a SASL mechanism, and using such = a >>> registered name aids interchange. However, the Authentication Method is= not >>> constrained to using registered SASL mechanisms. >>> >>> >>> >>> [JLS] I think that the lack of a registry should be identified someplac= e >>> in the document. This is probably a security consideration that there >>> might be a different authentication method which re-uses the same >>> authentication method name. >>> >>> >>> >>> >>> >>> 17. It is not clear to me, how in the scope string is the ability to >>> have a >>> "will" indicated? >>> >>> >> If the Will Flag is set to 1, the Will Topic follows the Client ID >>> and Will Properties in the Payload. >>> >>> This is where the broker learns the Will Topic. >>> >>> Then the scope would be publish_. >>> >>> And subscribes would need to subscribe_ to receive this >>> message. >>> >>> Will clarify in text. >>> >>> >>> >>> [JLS] publish makes sense to me. I was just being overly complicated. >>> >>> >>> >>> 18. Section 2.1.4 - I am unsure what the implications of discarding >>> tokens >>> on the end of a connection are going to be. How do you publish the tok= en >>> before doing the connection or is that only for an updated token? >>> >>> >>> >>> >> Tokens are discarded at the end of disconnection because no previous >>> session state is kept. >>> >>> And a token is expected in the new CONNECT request (otherwise, it is AS >>> discovery) >>> >>> >>> >>> Before the connection, a token may be transported via "authz-info" >>> topic described in Appendix B. >>> >>> During the connection, a new token may be transported via the AUTH >>> packet - which enables reauthentication. >>> >>> >>> >>> [JLS] This is still not clear to me. Is the transport of the token via >>> =E2=80=9Cauth-info=E2=80=9D topic not considered to be part of the sess= ion? If you say >>> that you look at just the last value published, then is there not going= to >>> be a race condition between two different clients trying to publish and >>> connect? >>> >>> >>> >>> >>> 20. I am not sure what the benefits of doing the check on a PINGREQUES= T >>> is >>> going to be. Like the relay of a PUBLISH message this is just going to >>> produce a DISCONNECT and a closed channel. If this is really allowed, >>> then >>> you should potentially also say that the Broker could do a check based = on >>> clock time elapsing. (I.e. do the check every hour.) >>> >>> >>> >>> >> This was suggested by one of the reviewers that provide MQTT service= s >>> (his e-mail regarding this was sent to the ace list). >>> >>> It was suggested as an optimization for detecting token expirations and >>> disconnecting early. >>> >>> (i.e., if you are already receiving PINGREQUESTs, use these as a trigge= r >>> to check the token). >>> >>> I think time-based checks may also help and be added as an option. >>> >>> >>> >>> [JLS] Ok >>> >>> >>> >>> >>> 22. Not sure if this goes here or in the connect documentation. There >>> needs >>> to be a check that the will topic is a topic that the client is going t= o >>> be >>> permitted to publish on. Corner case, if the ability to publish a wil= l >>> in >>> the event that this permission is lost. Does this kill the session or >>> the >>> will message? I.e. should the permission for the will message be >>> rechecked >>> before sending it allowing for the time based expiration of the token. >>> >>> >>> >>> >> We have been thinking about this. >>> >>> If the disconnect is due to a token expiration, and hence, also include= s >>> the will topic as well, you have to decide between: >>> >>> 1) publish the will >>> >>> 2) do not publish the will. >>> >>> At the moment, it's written like we publish the will - but on second >>> consideration, >>> >>> it seems safer to say "Publish the Will on Server Disconnect or unusual >>> disconnect if the token (the will permission) has not expired". >>> >>> >>> >>> [JLS] I would be fine with either position, after all at the time the >>> =E2=80=9Cpublish=E2=80=9D event occurred the token was valid, this is j= ust deferring >>> relaying it to subscribers. >>> >>> >>> >>> Jim >>> >>> >>> >>> >>> >>> Thanks again for these comments, will create the necessary github issue= s >>> and start revising the text. >>> >>> >>> >>> Best, >>> >>> >>> >>> >>> Jim >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Ace mailing list >>> Ace@ietf.org >>> https://www.ietf.org/mailman/listinfo/ace >>> >>> _______________________________________________ >>> Ace mailing list >>> Ace@ietf.org >>> https://www.ietf.org/mailman/listinfo/ace >>> >> _______________________________________________ >> Ace mailing list >> Ace@ietf.org >> https://www.ietf.org/mailman/listinfo/ace >> > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > --000000000000714ec0059623c27d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thank you for the response. Feel free to publish the = updated version. Please see my comments inline.=C2=A0
Yours,=C2= =A0
Daniel

On Wed, Oct 30, 2019 at 12:13 PM Cigdem Sengul <cigdem.sengul@gmail.com> wrot= e:
Thank you for your comments Daniel (prefixed [CS])My comments are inside. I've also created the -v-02-WIP branch for the= work in progress based on your and Jim's comments.=C2=A0
On Thu, = Oct 24, 2019 at 2:50 AM Daniel Migault <daniel.migault=3D40ericsson.com@dmarc.ie= tf.org> wrote:
HI,=C2=A0

Thanks for sending an update. Please find my comments = of the draft.=C2=A0

=C2=A0 =C2=A0This document mak= es the same assumptions as the Section 4 of the ACE
=C2=A0 =C2=A0framewo= rk [I-D.ietf-ace-oauth-authz] regarding Client and RS
=C2=A0 =C2=A0regis= tration with the AS and establishing of keying material.

<mglt>= ; The document seems mostly focuses on the latest version of MQTT,
I am = wondering if we could encourage similarly the use of the latest
version = of TLS that is 1.3 at the time of writing.

It seems AS as not been d= efined previously, so maybe it should be
expanded there.
</mglt&g= t;=C2=A0

[CS] Can add= a similar recommendation for TLS 1.3.=C2=A0
AS is expanded.=C2= =A0

=C2=A0

=C2= =A0 =C2=A0MQTTS
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Secured transpo= rt profile of MQTT.=C2=A0 MQTTS runs over TLS.
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0The Server in MQTT acts as an intermediary between
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Clients that publishes Application Me= ssages, and the Clients
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0that ma= de Subscriptions.=C2=A0 The Broker acts as the Resource
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0Server for the Clients.

<mglt>publi= shes</mglt>
[CS] Fixed.
<= div>
=C2=A0

=C2= =A0 =C2=A0Subscription
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0A subscr= iption comprises a Topic Filter and a maximum Quality
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0of Service (QoS).

<mglt>Maybe that wou= ld be clearer to specify QoS level as well.</mglt>

[CS] Added.=C2=A0

<= div>=C2=A0
=C2=A0 =C2=A0PINGREQ
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0A ping request sent from a Client to the Broker.=C2=A0= It signals
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0to the Broker that = the Client is alive, and is used to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0confirm that the Broker is still alive.

<mglt>It may loo= k a bit strange to have PINGREQ without PINGRESP. You
might also indicat= e the keep alive period is provided in the CONNECT</mglt>

[CS] Added PINGRESP, clarified t= he Keep Alive period is set in the CONNECT in the definition of PINGREQ.=C2= =A0
=C2=A0

=C2=A0 =C2=A0Will
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0An application message published by the Serv= er after the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0network connection= is closed in cases where the network
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0connection is not closed normally.=C2=A0 If the Will Flag is set,=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0then the payload of the CONNECT m= essage has information about
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0th= e Will.=C2=A0 The Will consists of the Will Properties, Will
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Topic, and Will Payload fields in the CONNEC= T message.

<mglt>
The first sentence seems to be related to= the Will message while the
intent, I suppose of teh definition was to d= efine the generic conpet of
Will. It might be clearer to expose the prin= ciple of the wil, that is a
server sends a given message in case a clien= t is disconnected
improperly. =C2=A0 It might be clearer to mention expl= icitly there is a Will
"concept" that is implemented a WillFla= g WillQoS, WillRetain in the
CONNECT header as well as other Will Proper= ties and Will Messages. This
mostly consists in the last sentence being = moved up. =C2=A0
</mglt>
[CS] I reworded it - let me know if it is more clear.=C2=A0
will have a look.=C2=A0=C2=A0

2.=C2=A0 Protocol Inter= actions

=C2=A0 =C2=A0This section describes the following exchanges = between Clients, the
=C2=A0 =C2=A0Broker, and the Authorization Server a= ccording to the MQTT v5.0.

<mglt> Though english is not my fir= st language, I have the impression the
text can be interpreted as MQTT e= nables clients to establish session
which does not seems correct to me. = The text that follows clarifies this
as well. =C2=A0
</mglt>

[CS] Neither mine, I re= worded that as: "Authorizing connection requests from the Clients to t= he Broker"
Actually, I also went through the text to reword = "establishment" to set-up which is simpler.=C2=A0
ok=C2=A0
=C2=A0

2.1.=C2=A0 Authorizing Connection Esta= blishment

If the
=C2=A0 =C2=A0Client is res= ource-constrained, a Client Authorisation Server may

<mglt>I h= ave the impression an AS would be sufficient.</mglt>
<= /div>

[CS] Client Authorization Server was = the terminology used in the Actors draft - I've removed all other refer= ences but wanted to distinguish that this is separate than the AS granting = access tokens.=C2=A0
Can just say client's AS?=C2=A0
Maybe just explicitly saying it is different wou= ld be clearer. I will have to re-read it.=C2=A0

=C2=A0 =C2=A0carry out the token request on behalf of the Cl= ient, and later,
=C2=A0 =C2=A0onboard the Client with the token.=C2=A0 A= lso, these interfaces may be
=C2=A0 =C2=A0implemented using other protoc= ols, e.g., CoAP or MQTT.
<mglt>While the introduction and the fig= ure mentions that HTTPS is used
as a transport, it might be worth mentio= ning that HTTPS is being used. I
propose to add "...other protocols= than HTTPS, e.g ...
</mglt>

[CS] Added.=C2=A0

=

2.1.1.=C2=A0 Client Token Request to the Authorization = Server (AS)

=C2=A0 =C2=A0The first step in the protocol flow (Figure= 1 (A)) is the token
=C2=A0 =C2=A0acquisition by the Client from the AS.= =C2=A0 When requesting an access
=C2=A0 =C2=A0token from the AS, the Cli= ent MAY include parameters in its request
=C2=A0 =C2=A0as defined in Sec= tion 5.6.1 of the ACE framework
=C2=A0 =C2=A0[I-D.ietf-ace-oauth-authz].= =C2=A0 The media format is 'application/
=C2=A0 =C2=A0ace+json'.= =C2=A0 The profile parameter MUST be set to 'mqtt_tls'.=C2=A0 The=C2=A0 =C2=A0OAuth 2.0 AS uses a JSON structure in the payload of its res= ponses
=C2=A0 =C2=A0both to client and RS.

<mglt> I underst= and that some parameters are mandatory while other are
not. I believe it= might be clearer to start with the mandatory
parameters (MUST) and then= mention that other parameters are optional
(MAY). That said, it might b= e simpler, if that is correct to mention
that the token request is as de= scribed in Section 5.6.1 of the ACE framework
=C2=A0 =C2=A0[I-D.ietf-ace= -oauth-authz] with the profile set to "mqtt".
</mglt>

[CS]=C2=A0
W= hen requesting an access token from the AS, the Client follows the token re= quest as is
described in Section 5.6.1 of the ACE framework, however, it= MUST set the profile parameter to 'mqtt_tls'.=C2=A0
= =C2=A0


=C2=A0 =C2=A0In the case of an erro= r, the AS returns error responses for HTTP-
=C2=A0 =C2=A0based interacti= ons as ASCII codes in JSON content, as defined in
=C2=A0 =C2=A0Section 5= .2 of RFC 6749 [RFC6749].

<mglt>Error messages are handled by = OAuth2.0 instead of the ACE
framework in order to keep JSON format. I am= wondering why do we have
the requirement to use ace+cbor only for error= message ? It seems to me
a bit strange to have error handling defined i= n another document.
</mglt>

=
[CS] Should keep as-is for the time being?=C2=A0
That was just a comment. I do not believe you could address t= his. So yes let's keep it this way.=C2=A0 =C2=A0
=C2=A0

2.1.2.=C2=A0 Client Connect= ion Request to the Broker (C)

=C2=A0 =C2=A0This section describes ho= w the Client transports the token to the
=C2=A0 =C2=A0Broker (RS) via th= e CONNECT control message after the TLS handshake.

<mglt>If th= e TLS handshake has already been performed, it would be good
to mention = which credentials have been used. Obviously, if the token is
provided by= the CONNECT message, I expect other credentials to be
involved. </mg= lt>

[CS] TLS hands= hake uses only server-side certificate or RPK. I think this is in the text.= .=C2=A0
That said there is a Github issue #16=C2=A0https:= //github.com/ace-wg/mqtt-tls-profile/issues/16
around this, a= nd will provide other clarifications as Jim asked.=C2=A0
<= /blockquote>

great!=C2=A0

=C2=A0 =C2=A0This is similar to an earlier proposal by Fremantl= e et al.
=C2=A0 =C2=A0[fremantle14].=C2=A0 Alternatively, the token may = be used for the TLS
=C2=A0 =C2=A0session establishment as described in t= he DTLS profile for ACE
=C2=A0 =C2=A0[I-D.gerdes-ace-dtls-authorize].=C2= =A0 In this case, both the TLS PSK and
=C2=A0 =C2=A0RPK handshakes MAY b= e supported.
<mglt>
It would be good to expand Raw Public Keys= (RPK). My reading is that
this section does not provide a single mechan= ism for the Client to be
authenticated by the Broker, but instead two di= fferent ways. I would
thus recommend to state it clearly in the introduc= tion of the section..
Currently, the section mentions:
""&q= uot;
This section describes how the Client transports the token to the=C2=A0 =C2=A0Broker (RS) via the CONNECT control message after the TLS ha= ndshake.
"""

An then we have a relatively detailed= description on how this is
performed using TLS. It might be better to s= ay something around the
following lines:
"""
This s= ection describes how the Client transports the token to the
=C2=A0 =C2= =A0Broker (RS). This can be achieved during the TLS KEX or during the
MQ= TT session establishment via the CONNECT control message after the TLS hand= shake.
"""

I am not sure that MAY is appropriated = here. I suspect that if none are
supported, this method will not work. A= s a result, if seems to me that
it woudl be more accurate to say that TL= S Client and TLS server MUST
support the PSK authentication as well as t= he raw public key.

One issue I have with I-D.gerdes-ace-dtls-author= ize that is now
draft-ietf-ace-dtls-authorize is that it seems to only c= onsider TLS 1.2.
With TLS 1.3 PSK and RPK are supported.

My inte= rpretation is that PSK provides mutual authentication, but in our
case R= PK will only authenticate the client. If that is correct, there
might be= a new to specify how the RS is authenticated by the Client.

</m= glt>

[CS] I will a= ctually reorganize this section, and hence, this will be more clear.=C2=A0<= /div>
Added your comment to issue #29, acknowledge that it is linked to= #16 as well.=C2=A0

I was trying to say the follow= ing, but I see that the text is not clear on that:
- MUST: TLS wi= th server validation=C2=A0+ token in MQTT CONNECT (will clarify server-side= certificate/RPK)
- MAY: TLS with server/client validation with R= PK -> token pushed to "authz-info"=C2=A0
- MAY: TLS = with server/client validation with PSK -> token in=C2=A0=C2=A0psk_identity

ok, it is also good to clarify whi= ch layer performs the authentication. Will have a look at the text when the= new version is published.=C2=A0=C2=A0
=C2=A0<= /div>
=C2=A0This option is described in more
=C2=A0 =C2=A0d= etail in Appendix B..

<mglt>see my comment in annex B.</mgl= t>


= [CS] OK.=C2=A0


=C2=A0 =C2=A0After the toke= n acquisition, the Client connects to the RS (Broker)
=C2=A0 =C2=A0using= the CONNECT message of MQTT over TLS.=C2=A0 For server
=C2=A0 =C2=A0aut= hentication, the client MAY either have the ability to receive and
=C2= =A0 =C2=A0validate a certificate or a raw public key from the Broker. =C2= =A0

<mglt>I might have missed something, but I thought that PS= K/RPK were
used to authenticate the Client. While in this case the RPK i= s used to
authenticate the RS, is that the same RPK provided by the AS o= r another
one? </mglt>

=
[CS] No the RPK was suggested for the RS/Broker authentication.=C2=A0<= /div>
As in the core ACE document, we assumed that the=C2=A0client learned either the RS&#= 39;s public key
from the AS. However, I haven't seen in the core document= an example of how AS=C2=A0
returns this information to the client.=C2=A0

Ok, this might need t= o be clarified even if that seems outside your document.=C2=A0=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">



=C2=A0 =C2=A0For token transport, the R= S SHOULD support AUTH (Authentication
=C2=A0 =C2=A0Exchange) method.=C2= =A0 The RS MAY support token transport via username
=C2=A0 =C2=A0and pas= sword, which is described in Section 3 for MQTT v3.1.1.=C2=A0 The
=C2=A0= =C2=A0rest of this section describes the AUTH method, for which the
=C2= =A0 =C2=A0username and password flags MUST be set to 0.

<mglt>=
Maybe the reference should be for MQTTv5 instead of MQTTv3.
I belie= ve it would be good to specify how setting the password flag
interacts w= ith the Authentication method.
</mglt>


[CS] Do you suggest that if AUTH metho= d is used, MQTTv5 ignores password/username?
=
I think I was wondering why MQTT v3 was mentioned rather than v5. It s= eems to me that there is no difference in our case - the only change being = that v5 permit password only.=C2=A0=C2=A0

=

=C2=A0
2.1.2.1.=C2=A0 Proof-of-Possession over = Predefined Field

=C2=A0 =C2=A0For this option, the Authentication Da= ta MUST contain the token and
=C2=A0 =C2=A0the keyed message digest (MAC= ) or the Client signature.=C2=A0 To calculate
=C2=A0 =C2=A0the keyed mes= sage digest (MAC) or the Client signature, the Client
=C2=A0 =C2=A0SHOUL= D apply the PoP key to the CONNECT payload.

=C2=A0 <mglt> I h= ave the impression the latest sentence indicates that the
Authenticated = Data is include din the CONNECT payload. I have however
the impression t= hat Authenticated Data is part of the properties which
are include din t= he variable header and not the payload. </mglt>


[CS]=C2=A0
No, the CON= NECT payload only includes=C2=A0Client Identifier, Will Properties, Will To= pic, Will Payload, User Name, Password.
AUTH data is variable hea= der part of the CONNECT message.=C2=A0
Anyway, based on also Jim&= #39;s input, using payload to do the PoP will be dropped.=C2=A0
Jim suggested we use a nonce from the tls_exporter, and apply PoP to tha= t.=C2=A0
We believe that is the better approach as well. These ar= e related to issues #15 (=C2=A0https://github.com/ace-wg/mqtt-tls-p= rofile/issues/15) and #19 (https://github.com/ace-wg/mqtt-tls-p= rofile/issues/19).=C2=A0

<= div>That is probably better to bind with the TLS. Please also clarify how i= t could work with early_exporters, if that works.=C2=A0

The CONNECT payload
=C2=A0 =C2=A0has at leas= t a Client Identifier, and if the Will Flag is set to 1,
=C2=A0 =C2=A0ma= y contain Will-related information.=C2=A0 The Client Identifier is a
=C2= =A0 =C2=A0MUST be a UTF-8 Encoded String (i.e., is prefixed with a two-byte=
=C2=A0 =C2=A0integer length field that gives the number of bytes in a U= TF-8
=C2=A0 =C2=A0encoded string itself).=C2=A0 The Client Identifier ma= y be 1-23 UTF-8
=C2=A0 =C2=A0encoded bytes, and contain only the charact= ers
=C2=A0 =C2=A0"0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLM= NOPQRSTUVWXYZ".

<mglt>
For my information I would like= to understand the mention of UTF8
while only ascii characters are permi= tted. It seems that teh server MUST
accept these and MAY accept others a= s well as a longer client id. Am I
correct ?

The nonce coded thi= s way has a randomness of 62**23 =3D2**138 =3D 17 bytes
</mglt>

[CS] This section will be cha= nged anyway... However, need to familiarize to specify how to use Exporter = Labels.=C2=A0=C2=A0
(Server can accept other characters.)

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

=C2=A0 =C2=A0If the RS accepts the connection, it MUST store the = token until the
=C2=A0 =C2=A0end of connection.=C2=A0 On Client or RS di= sconnection, the token is
=C2=A0 =C2=A0discarded, and the Client MUST pr= ovide a token inside each CONNECT
=C2=A0 =C2=A0message.

<mglt&= gt; The latest sentence is unclear to me. I think that disconnection
can= be interpreted in two way: 1) the disconnection of the will or a
DISCON= NECT. I believe both are considered. </mglt>

=
[CS] Either Client or Server may initiate a disconn= ection. In either case, the token is discarded.
The will may be s= ent if the client set up a will in case of unexpected disconnection.
<= div>=C2=A0
Though it needs to be clarified for instance, if there= are retained messages, these are sent as long as the token is valid.=C2=A0=
Since the introspection results are cached, this can be still do= ne but should clarify unless it gets confusing.=C2=A0

<= div>To avoid any confusion, and not to have to discuss these things in that= section, I reworded as:=C2=A0
On Client or RS disconnection, the= Client is expected to provide a token again inside the next CONNECT messag= e.

seems fine=C2=A0
=C2=A0
=C2=A0 =C2=A0If = the token is not self-contained and the Broker uses token
=C2=A0 =C2=A0i= ntrospection, it MAY cache the validation result to authorize the
=C2=A0= =C2=A0subsequent PUBLISH and SUBSCRIBE messages.=C2=A0 PUBLISH and SUBSCRI= BE
=C2=A0 =C2=A0messages, which are sent after a connection set-up, do n= ot contain
=C2=A0 =C2=A0access tokens.=C2=A0 If the introspection result= is not cached, then the
=C2=A0 =C2=A0RS needs to introspect the saved t= oken for each request.=C2=A0 The Broker
=C2=A0 =C2=A0SHOULD use a cache = time out to introspect tokens regularly.

<mglt>The latest sent= ence seems to indicate that result provided as
via introspection do not = necessarily have a Time to Live which could be
interpreted as a commitme= nt from the AS to authorize during that
period. If that is possible, it = would be appropriated this time out is
provided by the AS.
I am also = wondering why the token expiration cannot be considered as
well.
<= /mglt>


[C= S] This is to handle the situation where the resource owner changes the per= missions of the Client, which would revoke the token.
And hence t= he token exp field would not help.
=C2=A0If the RS does not check= the token introspection results, it=C2=A0
will use the token unt= il its expiration time.=C2=A0
I've considered this more appro= priate to be set by the RS as its RS risk management.=C2=A0

I do understand but I am questioning whe= ther this is necessary or useful.=C2=A0=C2=A0
= =C2=A0

Appendix B.=C2=A0 The Authorization Info= rmation Endpoint

=C2=A0 =C2=A0The main document described a method f= or transporting tokens inside
=C2=A0 =C2=A0MQTT CONNECT messages.=C2=A0 = In this section, we describe an alternative
=C2=A0 =C2=A0method to trans= port an access token.
=C2=A0 =C2=A0The method consists of the MQTT Broke= r accepting PUBLISH messages to
=C2=A0 =C2=A0a public "authz-info&q= uot; topic.=C2=A0 A Client using this method MUST first
=C2=A0 =C2=A0con= nect to the Broker, and publish the access token using the "authz-
= =C2=A0 =C2=A0info" topic.=C2=A0 The Broker must verify the validity of= the token (i.e.,
=C2=A0 =C2=A0through local validation or introspection= ).=C2=A0 After publishing the
=C2=A0 =C2=A0token, the Client disconnects= from the Broker and is expected to try
=C2=A0 =C2=A0reconnecting over T= LS.

<mglt>I understand this as an open channel for CONNECT and= sending
PUBLISHING message. This potentially open the door for DoSing t= he RS
either by openning too many MQTT sessions or by sending too many t= okens.
I expect this to be mentioned in the security consideration secti= on as
well as potential mechanisms to limit these risks.
</mglt&g= t;

[CS] It is indeed mentio= ned in this paragraph in the security consideration section.=C2=A0
"The RS may monitor Client behaviour to detect potential security pr= oblems, especially those affecting availability.
=C2=A0These include= repeated token transfer attempts to the public "authz-info" topi= c, repeated connection attempts,
=C2=A0abnormal terminations, and Clie= nts that connect but do not send any data..
=C2=A0If the RS supports t= he public "authz-info" topic, described in Appendix B,
=C2= =A0then this may be vulnerable to a DDoS attack, where many Clients use the= "authz-info" public topic
=C2=A0 =C2=A0 =C2=A0 =C2=A0to trans= port fictitious tokens, which RS may need to store indefinitely."


=
Thank you for your comments. And will try to add= ress Jim's shortly to be able to push another version before the deadli= ne.=C2=A0

perfect, the dead lin= e is monday I think.=C2=A0=C2=A0

Kind rega= rds,=C2=A0
--Cigdem=C2=A0
=C2=A0


On Th= u, Oct 17, 2019 at 2:47 PM Jim Schaad <ietf@augustcellars.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
<= p class=3D"MsoNormal">=C2=A0

=C2=A0

From: Cigdem Sengul <cigdem.sengul@gma= il.com>
Sent: Thursday, October 17, 2019 4:13 AM
To= : Jim Schaad <ietf@augustcellars.com>
Cc: draft-ietf-ace-mqtt-t= ls-profile@ietf.org; = ace@ietf.org
Subject: Re: [Ace] Review for draft-ietf-ace-mqt= t-tls-profile-01

=C2=A0

Hello Jim,

Thanks for this review. I have responded inline.= =C2=A0



1.=C2=A0 Are there any specifics= about using ACE over HTTP that need to be
explicitly stated some place.= =C2=A0 Some of these things might include:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 a= ) Must be HTTPS even if encrypted requests/responses are provided.
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 b) What types of validation are permitted/required= : anon-anon,
server validation, server & client validation. The latt= er corresponds to
current DTLS statements.=C2=A0
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 c) Are we looking for using the normal HTTP/HTTPS ports or shoul= d we
be using different ports?=C2=A0

=C2=A0

>> Agreed. Need to specify that it is HTTPS.

=

Mutual authentication and server validati= on Required.

Was thinki= ng it would be normal HTTPS ports. Should we consider different?<= /u>

What scenarios should permit anon-= anon; anon clients?=C2=A0

= =C2=A0

[JLS] If you look at my last email = I went through this.=C2=A0 Anon-anon is going to be a bad idea because the = server is never validated, however client anon is fine since you are going = to validate the client in the MQTT protocol.

<= p class=3D"MsoNormal">=C2=A0

=C2=A0


4.=C2=A0 Section 2.1.2: It is not cl= ear from the document is a Broker is going to
also have the possibility = of doing a post of the token via HTTPS.=C2=A0 Currently
I would think no= t, but given that this is documented in OAuth 2.0 as an
option I am not = clear.

>> D= o you mean for introspection? Yes, this is a MAY as in the core document, a= nd so in this one too.=C2=A0

And if there is an RS-AS interaction, we expect that to be on HTTPS.= =C2=A0

I will try to see= where I should clarify in the text.=C2=A0

=C2=A0

[JLS] No, I was orig= inally looking at doing an HTTPS post of the token from the client to the R= S.=C2=A0 This was before I figured out that you have an alternative method = of doing this in the MQTT protocol and so it should not be needed..=C2=A0 = =C2=A0Being clear on the fact that this would not be expected is probably a= good idea.

=C2=A0


7.=C2= =A0 =C2=A0In Figure 2, I think the use of Client Identifier is somewhat
= confusing.=C2=A0 I think this is supposed to be the token as the Client
= Identifier is a different thing in MQTT.=C2=A0 Either that or you need to d= o a
better job of describing the property block.

=C2=A0

OK. I think I should explain MQTT packets better.=C2=A0

A connect packet has thre= e parts: 1) Fixed header 2) Variable Header and 3) Payload.

The variable header may have several pr= operties, and Authentication Method and Authentication Data are two of thes= e properties.=C2=A0

Acco= rding to MQTT Specification:

=C2=A0

=C2=A0


8.=C2=A0 If the value of Cl= ean Start or Expiry Interval are not set correct is
the server to fail t= he connect?


10. Section 2.1.2.1 - I am= having a problem computing the MAC over the
payload of the CONNECT mess= age.=C2=A0 The password where the value is placed is
included in the pay= load and I am not clear if it should be computed up to
that value or if = a fixed value should be used for the computation.

=

11. I am worried about the text on the Client Identi= fier in this section.
It is not clear to me that having the client gener= ate a random value for
this field is good just in terms of the possibili= ty of collisions occurring
on the server.=C2=A0 The text in the MQTT 5.0= document appears to say that this
is more interesting for the situation= of getting back state that was left on
the server after a disconnect an= d not so much for a clean session.

=

For backward compatibility, we would need to think i= f we create a special data structure to be used in the password so that it = holds both the MAC/signature and the nonce.=C2=A0 =C2=A0

<= /div>

=C2=A0

As the use of ClientId seems to create confusion, I am lean= ing towards this solution. Any thoughts?

=C2=A0

[JLS] Look at the prev= ious answer and the re-ask the question.

=C2=A0

= =C2=A0

13. Is there someplace that authentication me= thods need to be registered?=C2=A0 I
was unable to see any such registry= setup with OASIS from the v5
specification.=C2=A0 Should we suggest to = the MQTT group that this is something
that should be done?=

=C2=A0

=

>> This is an interesting thought. The dr= aft was indeed discussed in the OASIS MQTT WG.=C2=A0

=C2=A0

But, the WG may consider this out of scope, as they have on the= ir charter page:

=C2=A0<= span style=3D"font-size:9pt;font-family:Verdana,sans-serif;color:black">Tra= nsport level security is assumed and no mandatory security features will be= added.

The MQTT = v5 draft says:

The Authenti= cation Method is commonly a SASL mechanism, and using such a registered nam= e aids interchange. However, the Authentication Method is not constrained t= o using registered SASL mechanisms.

=C2=A0

[JLS] I think= that the lack of a registry should be identified someplace in the document= .=C2=A0 This is probably a security consideration that there might be a dif= ferent authentication method which re-uses the same authentication method n= ame.

=C2=A0

=

=C2=A0

17.=C2=A0 It is n= ot clear to me, how in the scope string is the ability to have a
"w= ill" indicated?

>>=C2=A0If the Will Flag is set to 1, the Will Topic follows the Cl= ient ID and Will Properties in the Payload.

<= div>

This is where the broker learns the Will Topic.=C2= =A0

Then the scope= would be publish_<will topic>.=C2=A0

<= div>

And subscribes would need to subscribe_<will top= ic> to receive this message.=C2=A0

=

=C2=A0

18.=C2=A0 Section= 2.1.4 - I am unsure what the implications of discarding tokens
on the e= nd of a connection are going to be.=C2=A0 How do you publish the token
b= efore doing the connection or is that only for an updated token?<= /u>

=C2=A0

>> Tokens are discarded at the end of = disconnection because no previous session state is kept.

<= /div>

And a token is expected in the new CONNECT= request (otherwise, it is AS discovery)

=C2=A0

= Before the connection, a token may be transported via=C2=A0 "authz-inf= o" topic described in Appendix B.=C2=A0

During the connection, a new token may be transported = via the AUTH packet - which enables reauthentication.=C2=A0

=C2=A0

[JL= S] This is still not clear to me.=C2=A0 Is the transport of the token via = =E2=80=9Cauth-info=E2=80=9D topic not considered to be part of the session?= =C2=A0 If you say that you look at just the last value published, then is t= here not going to be a race condition between two different clients trying = to publish and connect?=C2=A0

<= /u>=C2=A0

20.=C2=A0 I am not sure what the benefits of doing the check on a PINGREQU= EST is
going to be.=C2=A0 Like the relay of a PUBLISH message this is ju= st going to
produce a DISCONNECT and a closed channel.=C2=A0 If this is = really allowed, then
you should potentially also say that the Broker cou= ld do a check based on
clock time elapsing.=C2=A0 (I.e. do the check eve= ry hour.)

= =C2=A0

>> This was sugges= ted by one of the reviewers that provide MQTT services (his e-mail regardin= g this was sent to the ace list).=C2=A0

It was suggested as an optimization for detecting token exp= irations and disconnecting early.=C2=A0

(i.e., if you are already receiving PINGREQUESTs, use these= as a trigger to check the token).=C2=A0

I think time-based checks may also help and be added as an= option.

=C2=A0

[JLS] Ok

=C2=A0


22. Not sure if this goes here or in the connect documentation.= =C2=A0 There needs
to be a check that the will topic is a topic that the= client is going to be
permitted to publish on.=C2=A0 =C2=A0Corner case,= if the ability to publish a will in
the event that this permission is l= ost.=C2=A0 Does this kill the session or the
will message?=C2=A0 I.e. sh= ould the permission for the will message be rechecked
before sending it = allowing for the time based expiration of the token.

=C2=A0

>> We have been thinking about this.=C2=A0<= u>

If the disconnect is due to a t= oken expiration, and hence, also includes the will topic as well, you have = to decide between:

1) pu= blish the will

2) do not= publish the will.=C2=A0

At the moment, it's written like we publish the will - but on second c= onsideration,=C2=A0

it s= eems safer to say "Publish the Will on Server Disconnect or unusual di= sconnect if the token (the will permission) has not expired".=C2=A0=

=C2=A0

[JLS] I would be fine with either position, after all at the time= the =E2=80=9Cpublish=E2=80=9D event occurred the token was valid, this is = just deferring relaying it to subscribers.=C2=A0

=C2=A0

Jim=

=C2=A0

=C2=A0

Th= anks again for these comments, will create the necessary github issues and = start revising the text.=C2=A0

=C2=A0

Best,=C2= =A0

=C2=A0=


Jim


=






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

__________________________________= _____________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
--000000000000714ec0059623c27d-- From nobody Wed Oct 30 17:14:12 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 13108120233; Wed, 30 Oct 2019 17:14:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 SldXk_S2Lkzf; Wed, 30 Oct 2019 17:14:02 -0700 (PDT) Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650094.outbound.protection.outlook.com [40.107.65.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B838412006D; Wed, 30 Oct 2019 17:14:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=L7vCHjFNVAiJA4UWmNDHulnY9M+OkippWnplP6O8W5i6JY+7F4Ec7CS1H59O69xgJI67szmoegkhvGWhpBUF+DdSSXCWEAS4HjviSrY6WvCUYGxcA5FuBTYvkikuWwaIWcjtUAx4ugEqFtnjpBqXhG6N3bRVTMz+xO7ENVfQ1fpJrGwptqVbxrcXYBVntMk97D1yf0nIIRrVZxXYzeYtePDK4+UEy6n23ufBEJj08JuFNpMawpVb06Ac1q+d7Dzxtg4H9wA7oGO83R5zv+kzD4r23/plQtHJFBX6f36RfFSGyNdPexlVVibsmaB++F5npCQXu8ntWp8QI1jnHSuruw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=80Kp3oM0r52fbJcdPpSplGpUauXMr7BvlbMzindIpR8=; b=LoRQuxGx25JLwBm7QrKMkyCEpf1dXMSvt7c+ZYJ/zbj/kZk0xWV04R7Jz4MH0mpQVhFVpilzS3+qieuAVqzuKnGjopLDKO2k2DjhLzT9mwRN8PdcpS2A+R5jGGMYJNzChJ78paus6rPqycb8gFGOaUbt2I0Vb9j2a/QiqRFOjE+R2wbT0uSiQ6Dz7N7gwu7noY6NPSa9rkLea2yXnt1Cd3dh+1q9sNQ+bloT5LTuu5OEjZfffSWu8LPqkiY91o3GZ5avSexNkRn6gAUgepWeAgH2R5VlJTv1VWz7aYnH85qsn8NcjIgxCBMF7IDUqW3OXug7QH9QOZFm7d+alk9PHA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=80Kp3oM0r52fbJcdPpSplGpUauXMr7BvlbMzindIpR8=; b=bk98lBLyTfhawRa2c38jBdEXr8A/lTU6utj1mraNYgcCHXUvqebEUk8UXTgHROZZ29KOyu6Q657vsV3MrHDgetfR8sphvmvKDVQ6kByedGVs6lAAK5lkBsbtI+kg2Vlfmpyxk6RK7QlXkLJmhWFEQQ6AWpGFkbwOGUd1brt2uxA= Received: from DM6PR00MB0572.namprd00.prod.outlook.com (20.179.51.15) by DM6PR00MB0666.namprd00.prod.outlook.com (10.141.8.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2408.0; Thu, 31 Oct 2019 00:13:58 +0000 Received: from DM6PR00MB0572.namprd00.prod.outlook.com ([fe80::e495:1666:382f:4785]) by DM6PR00MB0572.namprd00.prod.outlook.com ([fe80::e495:1666:382f:4785%4]) with mapi id 15.20.2448.000; Thu, 31 Oct 2019 00:13:58 +0000 From: Mike Jones To: Barry Leiba , Mirja Kuehlewind CC: Benjamin Kaduk , "Roman D. Danyliw" , "ace-chairs@ietf.org" , The IESG , "ace@ietf.org" , "draft-ietf-ace-cwt-proof-of-possession@ietf.org" Thread-Topic: =?utf-8?B?W0FjZV0gTWlyamEgS8O8aGxld2luZCdzIE5vIE9iamVjdGlvbiBvbiBkcmFm?= =?utf-8?B?dC1pZXRmLWFjZS1jd3QtcHJvb2Ytb2YtcG9zc2Vzc2lvbi0wOTogKHdpdGgg?= =?utf-8?Q?COMMENT)?= Thread-Index: AQHVjaTaf28MZ9kKEUmdwFvS0aZ7rqdwNJuAgAAGEbCAAE97AIADWAzA Date: Thu, 31 Oct 2019 00:13:58 +0000 Message-ID: References: <157201926102.4337.10953843577545450235.idtracker@ietfa.amsl.com> <20191028153150.GY69013@kduck.mit.edu> <4F15E6F7-2DA0-4C90-B891-DDA65917D1A7@kuehlewind.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=db71e82c-579c-41be-8380-0000c4e637ca; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2019-10-31T00:04:20Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [2001:4898:80e8:9:5a15:4e20:1624:50c8] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: fffe6184-7a3c-422a-3d14-08d75d9739be x-ms-traffictypediagnostic: DM6PR00MB0666: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 02070414A1 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(346002)(366004)(39860400002)(396003)(136003)(13464003)(189003)(199004)(76116006)(102836004)(22452003)(7736002)(305945005)(66476007)(11346002)(476003)(74316002)(256004)(14444005)(10090500001)(7696005)(486006)(76176011)(186003)(71190400001)(110136005)(54906003)(53546011)(71200400001)(446003)(316002)(6506007)(99286004)(8936002)(66946007)(66556008)(64756008)(66446008)(6436002)(9686003)(6306002)(55016002)(81156014)(46003)(81166006)(5660300002)(4326008)(6116002)(25786009)(33656002)(66574012)(14454004)(478600001)(229853002)(10290500003)(52536014)(8990500004)(86362001)(2906002)(966005)(6246003)(224303003); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR00MB0666; H:DM6PR00MB0572.namprd00.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 6ZdjgLD5O3QXzcObHEE/4UNQ4xnr1hKNuY/9TUw693xv21XMTcPeZaVNk7vE16t7Mf+/9AqizUzKTYrdC3IFB9PpRwVRuSQ/ZE5PAjSD46eTwG5w5ixmqxBOsnMESDqoWoG4dBv95Yo+0Us+PQ99te6eUXbCWn1m2hPCo4btr7s498y5zI1T9Q4N8Z32lfmEJg7Jn2XqPZ7PNRu8VXi1mdWWMiIajYudj/7/qsFf6724p0pSxCqI2+pNA8lHZdSHTPbAFM/4vRgtN9CcybJYvr1tBQimGik4tTEyY7bINMuVeCy+lTHq34sn4W4kQNzhI4dliXfYLehJDUir8S9nrVych/m0jc9DjZLuq85QLx6DnrUGwaQ0M9LWN63wjEu1GunvjR5ycCjJlZNKjZ7U4JdTdYxIB6DCJtUdnQelTKpSh0ffTna0aixoT6soyG/b x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: fffe6184-7a3c-422a-3d14-08d75d9739be X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Oct 2019 00:13:58.5888 (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-CrossTenant-userprincipalname: f0P8V2axYijwCvjaSF9wFA3Qo2b92s/pQ6s/p1UPxb26vivwht5SCi07IDmnjQ87KGAuGkUD+eNsk+L4ZnwU5A== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR00MB0666 Archived-At: Subject: Re: [Ace] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-ace-cwt-proof-of-possession-09=3A_=28with_COMMENT=29?= 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 Oct 2019 00:14:05 -0000 SSdtIGluIHRoZSBwcm9jZXNzIG9mIGNyZWF0aW5nIC0xMCwgd2hpY2ggYWRkcmVzc2VzIHRoZSBJ RVNHIGNvbW1lbnRzIG90aGVyIHRoYW4gTWlyamEncy4gIEknbSByZWx1Y3RhbnQgdG8gY2hhbmdl IHRoZSByZWdpc3RyYXRpb24gaW5zdHJ1Y3Rpb25zLCBhcyB0aGV5IGFyZSBjdXJyZW50bHkgaWRl bnRpY2FsIHRvIHRob3NlIGZvciBDV1RzIChhbmQgbWFueSBvdGhlciBzcGVjaWZpY2F0aW9ucyBn b2luZyBiYWNrIHRvIGF0IGxlYXN0IFJGQyA2NzQ5LCBtb2R1bG8gdGhlIG5hbWUgb2YgdGhlIG1h aWxpbmcgbGlzdCkuICBUaGF0IHNhaWQsIGlmIHRoZSBJRVNHICpyZWFsbHkqIHdhbnRzIHRvIGNo YW5nZSB0aGUgcGFydHkgdG8gYXBwZWFsIHRvIGluIHRoZSBjYXNlIG9mIG5vbi1hY3Rpb24gZnJv bSB0aGUgRGVzaWduYXRlZCBFeHBlcnRzIGZyb20gdGhlIElFU0cgdG8gSUFOQSwgSSdtIGFtZW5h YmxlIHRvIGFsc28gbWFraW5nIHRoYXQgY2hhbmdlIHRvbW9ycm93LCBpbW1lZGlhdGVseSBmb2xs b3dpbmcgdGhlIHRlbGVjaGF0LCBzbyB3ZSBjYW4gc2VuZCB0aGUgc3BlYyBvbiB0byB0aGUgUkZD IEVkaXRvci4gIExldCBtZSBrbm93IHdoYXQgeW91IGRlY2lkZS4NCg0KCQkJCVRoYW5rcyBhZ2Fp biwNCgkJCQktLSBNaWtlDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBCYXJy eSBMZWliYSA8YmFycnlsZWliYUBjb21wdXRlci5vcmc+IA0KU2VudDogTW9uZGF5LCBPY3RvYmVy IDI4LCAyMDE5IDI6MDAgUE0NClRvOiBNaWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVzQG1pY3Jvc29m dC5jb20+DQpDYzogTWlyamEgS3VlaGxld2luZCA8aWV0ZkBrdWVobGV3aW5kLm5ldD47IEJlbmph bWluIEthZHVrIDxrYWR1a0BtaXQuZWR1PjsgUm9tYW4gRC4gRGFueWxpdyA8cmRkQGNlcnQub3Jn PjsgYWNlLWNoYWlyc0BpZXRmLm9yZzsgVGhlIElFU0cgPGllc2dAaWV0Zi5vcmc+OyBhY2VAaWV0 Zi5vcmc7IGRyYWZ0LWlldGYtYWNlLWN3dC1wcm9vZi1vZi1wb3NzZXNzaW9uQGlldGYub3JnDQpT dWJqZWN0OiBSZTogW0FjZV0gTWlyamEgS8O8aGxld2luZCdzIE5vIE9iamVjdGlvbiBvbiBkcmFm dC1pZXRmLWFjZS1jd3QtcHJvb2Ytb2YtcG9zc2Vzc2lvbi0wOTogKHdpdGggQ09NTUVOVCkNCg0K VGhlIGlzc3VlIGlzbid0IHVzaW5nIGEgbWFpbGluZyBsaXN0LiAgVGhlIGlzc3VlIGlzIHRoZSBp bnN0cnVjdGlvbnMgdG8gSUFOQSBhYm91dCBob3cgdG8gZG8gbWFuYWdlbWVudCBhbmQgdHJhY2tp bmcsIHN0dWZmIHRoYXQgdGhleSBkbyBqdXN0IGZpbmUgd2l0aG91dCB3b3JraW5nIGdyb3VwcyB0 cnlpbmcgLS0gd2lsbCBhbGwgZ29vZCBpbnRlbnRpb25zIC0tIHRvIHRlbGwgdGhlbSBob3cuDQoN ClRoZSBmYWN0IHRoYXQgdGhlcmUgYXJlIGEgbG90IG9mIFJGQ3MgdGhhdCBkbyBpdCBqdXN0IHNh eXMgdGhhdCB3b3JraW5nIGdyb3VwcyBkbyB0aGlzIGZyZXF1ZW50bHksIGFuZCBtb3N0IEFEcyBk b24ndCBub3RpY2Ugb3IgZG9uJ3QgY2FyZS4gIEFuZCB0aGUgcmVhbGl0eSBpcyB0aGF0IElBTkEg d2lsbCBtYW5hZ2UgdGhlIHJlZ2lzdHJhdGlvbiBwcm9jZXNzIGhvdyB0aGV5IGRvIGl0LCBhY2Nv bW1vZGF0aW5nIHJlYXNvbmFibGUgc3BlY2lhbCBpbnN0cnVjdGlvbnMgd2hlbiB0aGV5IGNhbi4g IFRoZSBwb2ludCBpcyB0aGF0IGRvY3VtZW50cyBzaG91bGRuJ3QgYmUgZ2l2aW5nIHNwZWNpYWwg aW5zdHJ1Y3Rpb25zIHVubGVzcyB0aGVyZSByZWFsbHkgaXMgc29tZXRoaW5nIHNwZWNpYWwgbmVl ZGVkIGZvciBhIHBhcnRpY3VsYXIgcmVhc29uLg0KDQpCYXJyeQ0KDQpPbiBNb24sIE9jdCAyOCwg MjAxOSBhdCAxMjoxOSBQTSBNaWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+ IHdyb3RlOg0KPg0KPiBUaGUgcHJhY3RpY2Ugb2YgdXNpbmcgYSBtYWlsaW5nIGxpc3QgZm9yIHJl Z2lzdHJhdGlvbiByZXF1ZXN0cyB0byBlbmFibGUgcHVibGljIHZpc2liaWxpdHkgb2YgdGhlbSBn b2VzIGJhY2sgYXQgbGVhc3QgdG8gLndlbGwta25vd24gVVJJIHJlZ2lzdHJhdGlvbnMgaHR0cHM6 Ly9uYW0wNi5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJG JTJGdG9vbHMuaWV0Zi5vcmclMkZodG1sJTJGcmZjNTc4NSZhbXA7ZGF0YT0wMiU3QzAxJTdDTWlj aGFlbC5Kb25lcyU0MG1pY3Jvc29mdC5jb20lN0MwODUyNzA5MTRhMGI0MmU1MDA3OTA4ZDc1YmU5 ZTJlYSU3QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3QzAlN0M2MzcwNzg5 MzI0MjI5MzA1MzImYW1wO3NkYXRhPWJ3Z2xuZzlBN0E4T0dhVjR2aWN2TEFBY2QlMkZxY0s3USUy RnY5Y255d244ZkRvJTNEJmFtcDtyZXNlcnZlZD0wIGJ5IE1hcmsgTm90dGluZ2hhbSBpbiBBcHJp bCAyMDEwLiAgT0F1dGggMi4wIGZvbGxvd2VkIHRoaXMgcHJhY3RpY2UgaW4gUkZDIDY3NDksIGFz IGRpZCB0aGUgSk9TRSBzcGVjcyBhbmQgSldUIGluIFJGQ3MgNzUxNS0xOS4gIFRoZSByZXN0IGlz IGhpc3RvcnksIGFzIHRoZXkgc2F5Lg0KPg0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIC0tIE1pa2UNCj4NCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogTWly amEgS3VlaGxld2luZCA8aWV0ZkBrdWVobGV3aW5kLm5ldD4NCj4gU2VudDogTW9uZGF5LCBPY3Rv YmVyIDI4LCAyMDE5IDg6NTQgQU0NCj4gVG86IEJlbmphbWluIEthZHVrIDxrYWR1a0BtaXQuZWR1 Pg0KPiBDYzogQmFycnkgTGVpYmEgPGJhcnJ5bGVpYmFAY29tcHV0ZXIub3JnPjsgUm9tYW4gRC4g RGFueWxpdyANCj4gPHJkZEBjZXJ0Lm9yZz47IGFjZS1jaGFpcnNAaWV0Zi5vcmc7IFRoZSBJRVNH IDxpZXNnQGlldGYub3JnPjsgDQo+IGFjZUBpZXRmLm9yZzsgZHJhZnQtaWV0Zi1hY2UtY3d0LXBy b29mLW9mLXBvc3Nlc3Npb25AaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtBY2VdIE1pcmphIEvD vGhsZXdpbmQncyBObyBPYmplY3Rpb24gb24gDQo+IGRyYWZ0LWlldGYtYWNlLWN3dC1wcm9vZi1v Zi1wb3NzZXNzaW9uLTA5OiAod2l0aCBDT01NRU5UKQ0KPg0KPiBUaGVzZSBhcmUgYWxsIHF1aXRl IHJlY2VudHMgZXhhbXBsZXMsIHNvIG1heWJlIHRoZSBwcm9jZWR1cmVzIGFyZSBjaGFuZ2luZyBh dCB0aGUgbW9tZW50LiBJIGd1ZXNzIHdlIGFzIHRoZSBJRVNHIHNob3VsZCBiZSBhd2FyZSBhbmQg ZmlndXJlIG91dCB3aGF0IHRoZSByaWdodCBwcm9jZWR1cmUgYWN0dWFsbHkgc2hvdWxkIGJlIGhl cmUuDQo+DQo+ID4gT24gMjguIE9jdCAyMDE5LCBhdCAxNjozMSwgQmVuamFtaW4gS2FkdWsgPGth ZHVrQG1pdC5lZHU+IHdyb3RlOg0KPiA+DQo+ID4gT24gRnJpLCBPY3QgMjUsIDIwMTkgYXQgMTI6 MzE6NDJQTSAtMDQwMCwgQmFycnkgTGVpYmEgd3JvdGU6DQo+ID4+IFllaCwgaXQncyB2ZXJ5IGNv bW1vbiBmb3IgYXV0aG9ycyB0byB0cnkgdG8gdGVsbCBJQU5BIGhvdyB0byBoYW5kbGUgDQo+ID4+ IHJlZ2lzdHJhdGlvbnMsIGFuZCBJIG9mdGVuIHB1c2ggYmFjayBvbiB0aGF0IGFzIGluYXBwcm9w cmlhdGUuICANCj4gPj4gVGhlcmUgYXJlIGNlcnRhaW5seSBzcGVjaWFsIGNvbmRpdGlvbnMgdGhh dCBJQU5BIHNob3VsZCBiZSB0b2xkIA0KPiA+PiBhYm91dCwgYnV0IHRoaXMgaXMgc3RhbmRhcmQg d29yay1mbG93IG1hbmFnZW1lbnQgc3R1ZmYgdGhhdCBvdWdodCANCj4gPj4gdG8gYmUgbGVmdCB0 byBJQU5BLiAgSSBkbyB0aGluayBpdCBzaG91bGQgYmUgY2hhbmdlZCBiZWZvcmUgdGhpcyBpcyAN Cj4gPj4gcHVibGlzaGVkLCBwcm9iYWJseSBqdXN0IHJlbW92aW5nIHRoYXQgbGFzdCBzZW50ZW5j ZS4NCj4gPg0KPiA+IFdoaWxlIEknbSBub3Qgb3Bwb3NlZCB0byBub3JtYWxpemluZyBvbiBhIGRl ZmF1bHQgcHJvY2VkdXJlLCBJIHRoaW5rIA0KPiA+IHRoZSBhdXRob3JzIHdlcmUganVzdCB0cnlp bmcgdG8gZm9sbG93IGV4aXN0aW5nIGV4YW1wbGVzLg0KPiA+DQo+ID4gUkZDIDc1MTk6DQo+ID4N Cj4gPiAgIFZhbHVlcyBhcmUgcmVnaXN0ZXJlZCBvbiBhIFNwZWNpZmljYXRpb24gUmVxdWlyZWQg W1JGQzUyMjZdIGJhc2lzDQo+ID4gICBhZnRlciBhIHRocmVlLXdlZWsgcmV2aWV3IHBlcmlvZCBv biB0aGUgand0LXJlZy1yZXZpZXdAaWV0Zi5vcmcNCj4gPiAgIG1haWxpbmcgbGlzdCwgb24gdGhl IGFkdmljZSBvZiBvbmUgb3IgbW9yZSBEZXNpZ25hdGVkIEV4cGVydHMuDQo+ID4gICBIb3dldmVy LCB0byBhbGxvdyBmb3IgdGhlIGFsbG9jYXRpb24gb2YgdmFsdWVzIHByaW9yIHRvIHB1YmxpY2F0 aW9uLA0KPiA+ICAgdGhlIERlc2lnbmF0ZWQgRXhwZXJ0cyBtYXkgYXBwcm92ZSByZWdpc3RyYXRp b24gb25jZSB0aGV5IGFyZQ0KPiA+ICAgc2F0aXNmaWVkIHRoYXQgc3VjaCBhIHNwZWNpZmljYXRp b24gd2lsbCBiZSBwdWJsaXNoZWQuDQo+ID4NCj4gPiAgIFJlZ2lzdHJhdGlvbiByZXF1ZXN0cyBz ZW50IHRvIHRoZSBtYWlsaW5nIGxpc3QgZm9yIHJldmlldyBzaG91bGQgdXNlDQo+ID4gICBhbiBh cHByb3ByaWF0ZSBzdWJqZWN0IChlLmcuLCAiUmVxdWVzdCB0byByZWdpc3RlciBjbGFpbTogZXhh bXBsZSIpLg0KPiA+DQo+ID4gICBXaXRoaW4gdGhlIHJldmlldyBwZXJpb2QsIHRoZSBEZXNpZ25h dGVkIEV4cGVydHMgd2lsbCBlaXRoZXIgYXBwcm92ZQ0KPiA+ICAgb3IgZGVueSB0aGUgcmVnaXN0 cmF0aW9uIHJlcXVlc3QsIGNvbW11bmljYXRpbmcgdGhpcyBkZWNpc2lvbiB0byB0aGUNCj4gPiAg IHJldmlldyBsaXN0IGFuZCBJQU5BLiAgRGVuaWFscyBzaG91bGQgaW5jbHVkZSBhbiBleHBsYW5h dGlvbiBhbmQsIGlmDQo+ID4gICBhcHBsaWNhYmxlLCBzdWdnZXN0aW9ucyBhcyB0byBob3cgdG8g bWFrZSB0aGUgcmVxdWVzdCBzdWNjZXNzZnVsLg0KPiA+ICAgUmVnaXN0cmF0aW9uIHJlcXVlc3Rz IHRoYXQgYXJlIHVuZGV0ZXJtaW5lZCBmb3IgYSBwZXJpb2QgbG9uZ2VyIHRoYW4NCj4gPiAgIDIx IGRheXMgY2FuIGJlIGJyb3VnaHQgdG8gdGhlIElFU0cncyBhdHRlbnRpb24gKHVzaW5nIHRoZQ0K PiA+ICAgaWVzZ0BpZXRmLm9yZyBtYWlsaW5nIGxpc3QpIGZvciByZXNvbHV0aW9uLg0KPiA+DQo+ ID4gUkZDIDg0MTQ6DQo+ID4NCj4gPiAgIFZhbHVlcyBhcmUgcmVnaXN0ZXJlZCBvbiBhIFNwZWNp ZmljYXRpb24gUmVxdWlyZWQgW1JGQzgxMjZdIGJhc2lzDQo+ID4gICBhZnRlciBhIHR3by13ZWVr IHJldmlldyBwZXJpb2Qgb24gdGhlIG9hdXRoLWV4dC1yZXZpZXdAaWV0Zi5vcmcNCj4gPiAgIG1h aWxpbmcgbGlzdCwgb24gdGhlIGFkdmljZSBvZiBvbmUgb3IgbW9yZSBEZXNpZ25hdGVkIEV4cGVy dHMuDQo+ID4gICBIb3dldmVyLCB0byBhbGxvdyBmb3IgdGhlIGFsbG9jYXRpb24gb2YgdmFsdWVz IHByaW9yIHRvIHB1YmxpY2F0aW9uLA0KPiA+ICAgdGhlIERlc2lnbmF0ZWQgRXhwZXJ0cyBtYXkg YXBwcm92ZSByZWdpc3RyYXRpb24gb25jZSB0aGV5IGFyZQ0KPiA+ICAgc2F0aXNmaWVkIHRoYXQg c3VjaCBhIHNwZWNpZmljYXRpb24gd2lsbCBiZSBwdWJsaXNoZWQuDQo+ID4NCj4gPiAgIFJlZ2lz dHJhdGlvbiByZXF1ZXN0cyBzZW50IHRvIHRoZSBtYWlsaW5nIGxpc3QgZm9yIHJldmlldyBzaG91 bGQgdXNlDQo+ID4gICBhbiBhcHByb3ByaWF0ZSBzdWJqZWN0IChlLmcuLCAiUmVxdWVzdCB0byBy ZWdpc3RlciBPQXV0aA0KPiA+ICAgQXV0aG9yaXphdGlvbiBTZXJ2ZXIgTWV0YWRhdGE6IGV4YW1w bGUiKS4NCj4gPg0KPiA+ICAgV2l0aGluIHRoZSByZXZpZXcgcGVyaW9kLCB0aGUgRGVzaWduYXRl ZCBFeHBlcnRzIHdpbGwgZWl0aGVyIGFwcHJvdmUNCj4gPiAgIG9yIGRlbnkgdGhlIHJlZ2lzdHJh dGlvbiByZXF1ZXN0LCBjb21tdW5pY2F0aW5nIHRoaXMgZGVjaXNpb24gdG8gdGhlDQo+ID4gICBy ZXZpZXcgbGlzdCBhbmQgSUFOQS4gIERlbmlhbHMgc2hvdWxkIGluY2x1ZGUgYW4gZXhwbGFuYXRp b24gYW5kLCBpZg0KPiA+ICAgYXBwbGljYWJsZSwgc3VnZ2VzdGlvbnMgYXMgdG8gaG93IHRvIG1h a2UgdGhlIHJlcXVlc3Qgc3VjY2Vzc2Z1bC4NCj4gPiAgIFJlZ2lzdHJhdGlvbiByZXF1ZXN0cyB0 aGF0IGFyZSB1bmRldGVybWluZWQgZm9yIGEgcGVyaW9kIGxvbmdlciB0aGFuDQo+ID4gICAyMSBk YXlzIGNhbiBiZSBicm91Z2h0IHRvIHRoZSBJRVNHJ3MgYXR0ZW50aW9uICh1c2luZyB0aGUNCj4g PiAgIGllc2dAaWV0Zi5vcmcgbWFpbGluZyBsaXN0KSBmb3IgcmVzb2x1dGlvbi4NCj4gPg0KPiA+ IFJGQyA4NDQ3Og0KPiA+DQo+ID4gICBTcGVjaWZpY2F0aW9uIFJlcXVpcmVkIFtSRkM4MTI2XSBy ZWdpc3RyeSByZXF1ZXN0cyBhcmUgcmVnaXN0ZXJlZA0KPiA+ICAgYWZ0ZXIgYSB0aHJlZS13ZWVr IHJldmlldyBwZXJpb2Qgb24gdGhlIDx0bHMtcmVnLXJldmlld0BpZXRmLm9yZz4NCj4gPiAgIG1h aWxpbmcgbGlzdCwgb24gdGhlIGFkdmljZSBvZiBvbmUgb3IgbW9yZSBkZXNpZ25hdGVkIGV4cGVy dHMuDQo+ID4gICBIb3dldmVyLCB0byBhbGxvdyBmb3IgdGhlIGFsbG9jYXRpb24gb2YgdmFsdWVz IHByaW9yIHRvIHB1YmxpY2F0aW9uLA0KPiA+ICAgdGhlIGRlc2lnbmF0ZWQgZXhwZXJ0cyBtYXkg YXBwcm92ZSByZWdpc3RyYXRpb24gb25jZSB0aGV5IGFyZQ0KPiA+ICAgc2F0aXNmaWVkIHRoYXQg c3VjaCBhIHNwZWNpZmljYXRpb24gd2lsbCBiZSBwdWJsaXNoZWQuDQo+ID4NCj4gPiAgIFJlZ2lz dHJhdGlvbiByZXF1ZXN0cyBzZW50IHRvIHRoZSBtYWlsaW5nIGxpc3QgZm9yIHJldmlldyBTSE9V TEQgdXNlDQo+ID4gICBhbiBhcHByb3ByaWF0ZSBzdWJqZWN0IChlLmcuLCAiUmVxdWVzdCB0byBy ZWdpc3RlciB2YWx1ZSBpbiBUTFMgYmFyDQo+ID4gICByZWdpc3RyeSIpLg0KPiA+DQo+ID4gICBX aXRoaW4gdGhlIHJldmlldyBwZXJpb2QsIHRoZSBkZXNpZ25hdGVkIGV4cGVydHMgd2lsbCBlaXRo ZXIgYXBwcm92ZQ0KPiA+ICAgb3IgZGVueSB0aGUgcmVnaXN0cmF0aW9uIHJlcXVlc3QsIGNvbW11 bmljYXRpbmcgdGhpcyBkZWNpc2lvbiB0byB0aGUNCj4gPiAgIHJldmlldyBsaXN0IGFuZCBJQU5B LiAgRGVuaWFscyBTSE9VTEQgaW5jbHVkZSBhbiBleHBsYW5hdGlvbiBhbmQsIGlmDQo+ID4gICBh cHBsaWNhYmxlLCBzdWdnZXN0aW9ucyBhcyB0byBob3cgdG8gbWFrZSB0aGUgcmVxdWVzdCBzdWNj ZXNzZnVsLg0KPiA+ICAgUmVnaXN0cmF0aW9uIHJlcXVlc3RzIHRoYXQgYXJlIHVuZGV0ZXJtaW5l ZCBmb3IgYSBwZXJpb2QgbG9uZ2VyIHRoYW4NCj4gPiAgIDIxIGRheXMgY2FuIGJlIGJyb3VnaHQg dG8gdGhlIElFU0cncyBhdHRlbnRpb24gKHVzaW5nIHRoZQ0KPiA+ICAgPGllc2dAaWV0Zi5vcmc+ IG1haWxpbmcgbGlzdCkgZm9yIHJlc29sdXRpb24uDQo+ID4NCj4gPiBbSSBzdG9wcGVkIGxvb2tp bmcgaGVyZV0NCj4gPg0KPiA+IFNvIGlmIHdlJ3JlIGdvaW5nIHRvIGNoYW5nZSB0aGluZ3MgYXJv dW5kLCBtYXliZSB3ZSBzaG91bGQgaXNzdWUgYW4gDQo+ID4gSUVTRyBzdGF0ZW1lbnQuDQo+ID4N Cj4gPiAtQmVuDQo+ID4NCj4gPg0KPg0K From nobody Wed Oct 30 17:29:12 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 B576C12022C; Wed, 30 Oct 2019 17:29:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iiuKVxv9pza6; Wed, 30 Oct 2019 17:29:07 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB190120018; Wed, 30 Oct 2019 17:29:06 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x9V0StC1031409 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 30 Oct 2019 20:28:57 -0400 Date: Wed, 30 Oct 2019 17:28:55 -0700 From: Benjamin Kaduk To: Mike Jones Cc: Barry Leiba , Mirja Kuehlewind , "Roman D. Danyliw" , "ace-chairs@ietf.org" , The IESG , "ace@ietf.org" , "draft-ietf-ace-cwt-proof-of-possession@ietf.org" Message-ID: <20191031002855.GC88302@kduck.mit.edu> References: <157201926102.4337.10953843577545450235.idtracker@ietfa.amsl.com> <20191028153150.GY69013@kduck.mit.edu> <4F15E6F7-2DA0-4C90-B891-DDA65917D1A7@kuehlewind.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [Ace] =?iso-8859-1?q?Mirja_K=FChlewind=27s_No_Objection_on_draft?= =?iso-8859-1?q?-ietf-ace-cwt-proof-of-possession-09=3A_=28with_COMMENT=29?= 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 Oct 2019 00:29:10 -0000 Just to be clear, IANA raising the issue to the IESG is described in Section 5.3 of RFC 8126, which would be the default expectations if an individual document/registry did not give other instructions. -Ben On Thu, Oct 31, 2019 at 12:13:58AM +0000, Mike Jones wrote: > I'm in the process of creating -10, which addresses the IESG comments other than Mirja's. I'm reluctant to change the registration instructions, as they are currently identical to those for CWTs (and many other specifications going back to at least RFC 6749, modulo the name of the mailing list). That said, if the IESG *really* wants to change the party to appeal to in the case of non-action from the Designated Experts from the IESG to IANA, I'm amenable to also making that change tomorrow, immediately following the telechat, so we can send the spec on to the RFC Editor. Let me know what you decide. > > Thanks again, > -- Mike > > -----Original Message----- > From: Barry Leiba > Sent: Monday, October 28, 2019 2:00 PM > To: Mike Jones > Cc: Mirja Kuehlewind ; Benjamin Kaduk ; Roman D. Danyliw ; ace-chairs@ietf.org; The IESG ; ace@ietf.org; draft-ietf-ace-cwt-proof-of-possession@ietf.org > Subject: Re: [Ace] Mirja Kühlewind's No Objection on draft-ietf-ace-cwt-proof-of-possession-09: (with COMMENT) > > The issue isn't using a mailing list. The issue is the instructions to IANA about how to do management and tracking, stuff that they do just fine without working groups trying -- will all good intentions -- to tell them how. > > The fact that there are a lot of RFCs that do it just says that working groups do this frequently, and most ADs don't notice or don't care. And the reality is that IANA will manage the registration process how they do it, accommodating reasonable special instructions when they can. The point is that documents shouldn't be giving special instructions unless there really is something special needed for a particular reason. > > Barry > > On Mon, Oct 28, 2019 at 12:19 PM Mike Jones wrote: > > > > The practice of using a mailing list for registration requests to enable public visibility of them goes back at least to .well-known URI registrations https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc5785&data=02%7C01%7CMichael.Jones%40microsoft.com%7C085270914a0b42e5007908d75be9e2ea%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637078932422930532&sdata=bwglng9A7A8OGaV4vicvLAAcd%2FqcK7Q%2Fv9cnywn8fDo%3D&reserved=0 by Mark Nottingham in April 2010. OAuth 2.0 followed this practice in RFC 6749, as did the JOSE specs and JWT in RFCs 7515-19. The rest is history, as they say. > > > > -- Mike > > > > -----Original Message----- > > From: Mirja Kuehlewind > > Sent: Monday, October 28, 2019 8:54 AM > > To: Benjamin Kaduk > > Cc: Barry Leiba ; Roman D. Danyliw > > ; ace-chairs@ietf.org; The IESG ; > > ace@ietf.org; draft-ietf-ace-cwt-proof-of-possession@ietf.org > > Subject: Re: [Ace] Mirja Kühlewind's No Objection on > > draft-ietf-ace-cwt-proof-of-possession-09: (with COMMENT) > > > > These are all quite recents examples, so maybe the procedures are changing at the moment. I guess we as the IESG should be aware and figure out what the right procedure actually should be here. > > > > > On 28. Oct 2019, at 16:31, Benjamin Kaduk wrote: > > > > > > On Fri, Oct 25, 2019 at 12:31:42PM -0400, Barry Leiba wrote: > > >> Yeh, it's very common for authors to try to tell IANA how to handle > > >> registrations, and I often push back on that as inappropriate. > > >> There are certainly special conditions that IANA should be told > > >> about, but this is standard work-flow management stuff that ought > > >> to be left to IANA. I do think it should be changed before this is > > >> published, probably just removing that last sentence. > > > > > > While I'm not opposed to normalizing on a default procedure, I think > > > the authors were just trying to follow existing examples. > > > > > > RFC 7519: > > > > > > Values are registered on a Specification Required [RFC5226] basis > > > after a three-week review period on the jwt-reg-review@ietf.org > > > mailing list, on the advice of one or more Designated Experts. > > > However, to allow for the allocation of values prior to publication, > > > the Designated Experts may approve registration once they are > > > satisfied that such a specification will be published. > > > > > > Registration requests sent to the mailing list for review should use > > > an appropriate subject (e.g., "Request to register claim: example"). > > > > > > Within the review period, the Designated Experts will either approve > > > or deny the registration request, communicating this decision to the > > > review list and IANA. Denials should include an explanation and, if > > > applicable, suggestions as to how to make the request successful. > > > Registration requests that are undetermined for a period longer than > > > 21 days can be brought to the IESG's attention (using the > > > iesg@ietf.org mailing list) for resolution. > > > > > > RFC 8414: > > > > > > Values are registered on a Specification Required [RFC8126] basis > > > after a two-week review period on the oauth-ext-review@ietf.org > > > mailing list, on the advice of one or more Designated Experts. > > > However, to allow for the allocation of values prior to publication, > > > the Designated Experts may approve registration once they are > > > satisfied that such a specification will be published. > > > > > > Registration requests sent to the mailing list for review should use > > > an appropriate subject (e.g., "Request to register OAuth > > > Authorization Server Metadata: example"). > > > > > > Within the review period, the Designated Experts will either approve > > > or deny the registration request, communicating this decision to the > > > review list and IANA. Denials should include an explanation and, if > > > applicable, suggestions as to how to make the request successful. > > > Registration requests that are undetermined for a period longer than > > > 21 days can be brought to the IESG's attention (using the > > > iesg@ietf.org mailing list) for resolution. > > > > > > RFC 8447: > > > > > > Specification Required [RFC8126] registry requests are registered > > > after a three-week review period on the > > > mailing list, on the advice of one or more designated experts. > > > However, to allow for the allocation of values prior to publication, > > > the designated experts may approve registration once they are > > > satisfied that such a specification will be published. > > > > > > Registration requests sent to the mailing list for review SHOULD use > > > an appropriate subject (e.g., "Request to register value in TLS bar > > > registry"). > > > > > > Within the review period, the designated experts will either approve > > > or deny the registration request, communicating this decision to the > > > review list and IANA. Denials SHOULD include an explanation and, if > > > applicable, suggestions as to how to make the request successful. > > > Registration requests that are undetermined for a period longer than > > > 21 days can be brought to the IESG's attention (using the > > > mailing list) for resolution. > > > > > > [I stopped looking here] > > > > > > So if we're going to change things around, maybe we should issue an > > > IESG statement. > > > > > > -Ben > > > > > > > > From nobody Wed Oct 30 17:32:40 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 4717D12022C; Wed, 30 Oct 2019 17:32:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: internet-drafts@ietf.org To: Cc: ace@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.108.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ace@ietf.org Message-ID: <157248195825.32490.14170581190430072021@ietfa.amsl.com> Date: Wed, 30 Oct 2019 17:32:38 -0700 Archived-At: Subject: [Ace] I-D Action: draft-ietf-ace-cwt-proof-of-possession-10.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 Oct 2019 00:32:38 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Authentication and Authorization for Constrained Environments WG of the IETF. Title : Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs) Authors : Michael B. Jones Ludwig Seitz Göran Selander Samuel Erdtman Hannes Tschofenig Filename : draft-ietf-ace-cwt-proof-of-possession-10.txt Pages : 16 Date : 2019-10-30 Abstract: This specification describes how to declare in a CBOR Web Token (CWT) (which is defined by RFC 8392) that the presenter of the CWT possesses a particular proof-of-possession key. Being able to prove possession of a key is also sometimes described as being the holder- of-key. This specification provides equivalent functionality to "Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)" (RFC 7800) but using Concise Binary Object Representation (CBOR) and CWTs rather than JavaScript Object Notation (JSON) and JSON Web Tokens (JWTs). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ace-cwt-proof-of-possession/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ace-cwt-proof-of-possession-10 https://datatracker.ietf.org/doc/html/draft-ietf-ace-cwt-proof-of-possession-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-cwt-proof-of-possession-10 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 Oct 30 17:41: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 F30FA120168; Wed, 30 Oct 2019 17:41:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 c1apsM7W4lrN; Wed, 30 Oct 2019 17:41:04 -0700 (PDT) Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650131.outbound.protection.outlook.com [40.107.65.131]) (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 3F4AA12011A; Wed, 30 Oct 2019 17:41:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=oUdAvJVyMbmXx0IENiFZg/Jo8OUpPtAnXfbHhlBpef+J1he/aGBOH/Vawk1HX7ITCf8dPsyj79P2ufppBBW4I6/ElaFykwYoz6YSshAof++/gLIchFcBJSFX08uIfCbefU55iy6EltTdDLBtzlhlMpnqm9PcnZJEJE1H6ABxzia0BSVenZB6rQoHVXphJI3zk3YrFW9P40qyHKX3Vt3bdbhfuFMcveSuZboDvqCOG0bF9KJkp+wIkF3WoQsd2JAgq5AzquRaBlI6nF9ggNhGiBaNxf35oHv/fM4hz4fHfrMwcS6hozK0teWBF0Ve3ndo4hqT9jQsW5rCZHWsaAbrQQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=TQ6QLfdb+R9qR4dM3OhuJc/vPY5TQzoBOOJ4qYXpA4I=; b=feX1Yh7MZi+SZejobYx66A4PcEKULpttYRzm/4wuViGw8M+UFq95upmy82jBeAaG2ENHKt7dMlu2kGU0kwUo9EKBoEkP92Cco8IeVVLPVu53QE9oakVwjQ03kGkkwsb4efJVOcYTZGpuN72KkGjJ6xkrDYZmhMUWBqy0v66M4jzgYxRTAAZ7NTsEOibhLx3gGX+1oEXfim0Rftf+wCUtambBDgp5A8kLPfhEajsDwQbdIC7DR5USFMSit94cDAS1W0bBdx79PBaP9Ri3KOI0gIREPiVCkQZ1VOe4WAi4UAjnmfstXGdP/p/ZmKNkasvMUs/GYVWsOH/EhpHseCC+Ww== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=TQ6QLfdb+R9qR4dM3OhuJc/vPY5TQzoBOOJ4qYXpA4I=; b=QJ7Ko6oopnMr204Ua4ELB+Ts+5dXnXAx1J5jE8ePvwfaQY1dtCeUUasjUIU6LqzZxdCPVDWP2HAa0RpYoPacYv8AgaKn/KcQBKSP9bBPr2ccq4k+OD9GYxan2tUdvZQprl2Y420Dp3cUiaCuLOUnWCSulAjiXYGS96TKEKcacj0= Received: from MN2PR00MB0574.namprd00.prod.outlook.com (20.178.255.147) by MN2PR00MB0478.namprd00.prod.outlook.com (20.178.241.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2442.0; Thu, 31 Oct 2019 00:41:01 +0000 Received: from MN2PR00MB0574.namprd00.prod.outlook.com ([fe80::adbb:7ec8:334:2f7]) by MN2PR00MB0574.namprd00.prod.outlook.com ([fe80::adbb:7ec8:334:2f7%9]) with mapi id 15.20.2448.000; Thu, 31 Oct 2019 00:41:01 +0000 From: Mike Jones To: Adam Roach , The IESG CC: "draft-ietf-ace-cwt-proof-of-possession@ietf.org" , "ace-chairs@ietf.org" , "rdd@cert.org" , "ace@ietf.org" Thread-Topic: Adam Roach's No Objection on draft-ietf-ace-cwt-proof-of-possession-09: (with COMMENT) Thread-Index: AQHVjh8iuBIwh7C9DUuSsaSDMfSiAqdz6mcw Date: Thu, 31 Oct 2019 00:41:00 +0000 Message-ID: References: <157232923891.16185.1675206642162092837.idtracker@ietfa.amsl.com> In-Reply-To: <157232923891.16185.1675206642162092837.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=bf85945f-1413-4bfd-915b-0000c5527111; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2019-10-31T00:37:07Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [2001:4898:80e8:a:5a14:4e20:1624:50c8] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: e2a04d78-2d9a-4961-4c31-08d75d9b00da x-ms-traffictypediagnostic: MN2PR00MB0478: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 02070414A1 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(366004)(346002)(376002)(396003)(39860400002)(189003)(13464003)(199004)(51914003)(74316002)(186003)(5660300002)(66476007)(486006)(6436002)(11346002)(446003)(14444005)(46003)(64756008)(66556008)(81166006)(4326008)(476003)(9686003)(76176011)(305945005)(6306002)(71200400001)(7696005)(6116002)(256004)(66946007)(8676002)(99286004)(81156014)(14454004)(7736002)(86362001)(478600001)(55016002)(76116006)(6506007)(53546011)(102836004)(8990500004)(71190400001)(66446008)(2906002)(10290500003)(966005)(229853002)(6246003)(25786009)(54906003)(110136005)(316002)(22452003)(52536014)(33656002)(8936002)(10090500001); DIR:OUT; SFP:1102; SCL:1; SRVR:MN2PR00MB0478; H:MN2PR00MB0574.namprd00.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 4UnMN1KDSzKOaIZtPDCpD+k0M0h9jZgXHSvfPMaPiWs0oC8u9/zYLnCYNQ1uJRGo6xyQcSOhGXcrMKAXSyteZUd0CoUxz6ggA9fh+ni35mQYbT/mkMEM10a9EjwQABiZYmS/4p/wulovL/HYq2b4nIMj41LMYSiCwMsVIPu7SNOZl5GAuf6iqGEQT4zKu1cEMFThoBiEBz5XoZ8FGNRUBXKCvM2HD+f3Z8ovwzBwK3cDBxos+IcHV7s+j7xqRte/tH2Gocs2sUPgECTbSaAbrbDiUtZLEX4ksxCEbBBgRSSCvWjHxDxyd6WokeB3iU0FECY2gEOa0hDt4idWQAzbUADK04RQ3BYWUywXfcj1aM5ITFaOcaWW2VQkjcYq/8+Kyo8GM0/HyqETMSowX1SdDhJG0V9EhfTVdCfcQZ6duCRwVo0afaAiA+WS8ySIOrky x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: e2a04d78-2d9a-4961-4c31-08d75d9b00da X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Oct 2019 00:41:01.0055 (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-CrossTenant-userprincipalname: e0cujuW9ZRe081rqrjVEUH222VLEwzbz0JCLJCgmWa5IsHzjeP+4nNnIuEQZFAEQ7oewckJRqo8jYx4VwxJlVQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR00MB0478 Archived-At: Subject: Re: [Ace] Adam Roach's No Objection on draft-ietf-ace-cwt-proof-of-possession-09: (with COMMENT) 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 Oct 2019 00:41:07 -0000 VGhhbmtzIGZvciB5b3VyIHJldmlldywgQWRhbS4gIFRoZSBxdWVzdGlvbmFibGUgY29tbWVudCBz eW50YXggdGhhdCB5b3UgcG9pbnRlZCBvdXQgaGFzIGJlZW4gY2hhbmdlZCB0byB0aGUgdW5zdXJw cmlzaW5nIHJlcHJlc2VudGF0aW9uIC9ITUFDIDI1Ni0yNTYvIGluIGh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWFjZS1jd3QtcHJvb2Ytb2YtcG9zc2Vzc2lvbi0xMCNzZWN0 aW9uLTMuMy4NCg0KCQkJCUJlc3Qgd2lzaGVzLA0KCQkJCS0tIE1pa2UNCg0KLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCkZyb206IEFkYW0gUm9hY2ggdmlhIERhdGF0cmFja2VyIDxub3JlcGx5 QGlldGYub3JnPiANClNlbnQ6IE1vbmRheSwgT2N0b2JlciAyOCwgMjAxOSAxMTowNyBQTQ0KVG86 IFRoZSBJRVNHIDxpZXNnQGlldGYub3JnPg0KQ2M6IGRyYWZ0LWlldGYtYWNlLWN3dC1wcm9vZi1v Zi1wb3NzZXNzaW9uQGlldGYub3JnOyBhY2UtY2hhaXJzQGlldGYub3JnOyByZGRAY2VydC5vcmc7 IGFjZUBpZXRmLm9yZw0KU3ViamVjdDogQWRhbSBSb2FjaCdzIE5vIE9iamVjdGlvbiBvbiBkcmFm dC1pZXRmLWFjZS1jd3QtcHJvb2Ytb2YtcG9zc2Vzc2lvbi0wOTogKHdpdGggQ09NTUVOVCkNCg0K QWRhbSBSb2FjaCBoYXMgZW50ZXJlZCB0aGUgZm9sbG93aW5nIGJhbGxvdCBwb3NpdGlvbiBmb3IN CmRyYWZ0LWlldGYtYWNlLWN3dC1wcm9vZi1vZi1wb3NzZXNzaW9uLTA5OiBObyBPYmplY3Rpb24N Cg0KV2hlbiByZXNwb25kaW5nLCBwbGVhc2Uga2VlcCB0aGUgc3ViamVjdCBsaW5lIGludGFjdCBh bmQgcmVwbHkgdG8gYWxsIGVtYWlsIGFkZHJlc3NlcyBpbmNsdWRlZCBpbiB0aGUgVG8gYW5kIEND IGxpbmVzLiAoRmVlbCBmcmVlIHRvIGN1dCB0aGlzIGludHJvZHVjdG9yeSBwYXJhZ3JhcGgsIGhv d2V2ZXIuKQ0KDQoNClBsZWFzZSByZWZlciB0byBodHRwczovL25hbTA2LnNhZmVsaW5rcy5wcm90 ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ3d3cuaWV0Zi5vcmclMkZpZXNn JTJGc3RhdGVtZW50JTJGZGlzY3Vzcy1jcml0ZXJpYS5odG1sJmFtcDtkYXRhPTAyJTdDMDElN0NN aWNoYWVsLkpvbmVzJTQwbWljcm9zb2Z0LmNvbSU3QzFjOWMxMjgwNWQ3YzRiN2VkNmY0MDhkNzVj MzY0MWZmJTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN0MxJTdDMCU3QzYzNzA3 OTI2MDQzMjEyMzY0NyZhbXA7c2RhdGE9eVY0Z2VKbXFIczZuRTJLRXoxSHhYZjU1eFJSbEdRSmRM Z0hFZUtrenh1cyUzRCZhbXA7cmVzZXJ2ZWQ9MA0KZm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQg SUVTRyBESVNDVVNTIGFuZCBDT01NRU5UIHBvc2l0aW9ucy4NCg0KDQpUaGUgZG9jdW1lbnQsIGFs b25nIHdpdGggb3RoZXIgYmFsbG90IHBvc2l0aW9ucywgY2FuIGJlIGZvdW5kIGhlcmU6DQpodHRw czovL25hbTA2LnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0El MkYlMkZkYXRhdHJhY2tlci5pZXRmLm9yZyUyRmRvYyUyRmRyYWZ0LWlldGYtYWNlLWN3dC1wcm9v Zi1vZi1wb3NzZXNzaW9uJTJGJmFtcDtkYXRhPTAyJTdDMDElN0NNaWNoYWVsLkpvbmVzJTQwbWlj cm9zb2Z0LmNvbSU3QzFjOWMxMjgwNWQ3YzRiN2VkNmY0MDhkNzVjMzY0MWZmJTdDNzJmOTg4YmY4 NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN0MxJTdDMCU3QzYzNzA3OTI2MDQzMjEyMzY0NyZhbXA7 c2RhdGE9aU9RcEVjb2o0MiUyRnJXOHFOOGMzOGw5MzFFR0glMkJUTTBxTmdMMWFDOWFNM0UlM0Qm YW1wO3Jlc2VydmVkPTANCg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCkNPTU1FTlQ6DQotLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tDQoNCg0KVGhhbmtzIGZvciB0aGUgd29yayBldmVyeW9uZSBwdXQgaW50byBkZWZpbmluZyB0 aGlzIG1lY2hhbmlzbS4gSSBoYXZlIG9uZSB2ZXJ5IG1pbm9yIGNvbW1lbnQgdGhhdCB0aGUgYXV0 aG9ycyBtYXkgd2lzaCB0byB0YWtlIGludG8gYWNjb3VudC4NCg0KwqczLjM6DQoNCj4gICAgIC9h bGcvIDMgOiAvSE1BQzI1Ni8vMjU2LyA1LA0KDQpUaGlzIHVzZSBvZiAiLy8iIHNlZW1zIHByb2Js ZW1hdGljLCBnaXZlbiBSRkMgODYxMCdzIHZhZ3VlIHJlc2VydmF0aW9uIG9mIHRoaXMgc2VxdWVu Y2UgZm9yIHNvbWUga2luZCBvZiAiY29tbWVudCB0byBlbmQgb2YgbGluZSIgZGVzaWduYXRpb246 DQoNCiAgIChUaGVyZSBhcmUgY3VycmVudGx5IG5vIGVuZC1vZi1saW5lIGNvbW1lbnRzLiAgSWYg d2Ugd2FudCB0byBhZGQNCiAgIHRoZW0sICIvLyIgc291bmRzIGxpa2UgYSByZWFzb25hYmxlIGRl bGltaXRlciBnaXZlbiB0aGF0IHdlIGFscmVhZHkNCiAgIHVzZSBzbGFzaGVzIGZvciBjb21tZW50 cywgYnV0IHdlIGNvdWxkIGFsc28gZ28sIGZvciBleGFtcGxlLA0KICAgZm9yICIjIi4pDQoNCkdp dmVuIHRoZSBwb3RlbnRpYWwgYW1iaWd1aXR5IGludHJvZHVjZWQgYnkgUkZDIDg2MTAsIHBlcmhh cHMgY29uc2lkZXIgc29tZSBvdGhlciBzeW50YXggaGVyZSBpbnN0ZWFkIG9mICIvLyIuDQoNCg0K From nobody Wed Oct 30 17:42: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 B4B5712011A; Wed, 30 Oct 2019 17:42:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 8hAfEbNIVdLn; Wed, 30 Oct 2019 17:42:53 -0700 (PDT) Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650134.outbound.protection.outlook.com [40.107.65.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1102120018; Wed, 30 Oct 2019 17:42:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Cua0jB+vvXpoHfKQ7c1RbrgpRBdyhKp4FZY4exwWDLLy67nsIyLTAIDi5f+d5lizzFQab5Fie/LTPyqIgjDfWZ7evS6Km4Bvafw+RPo1S4Z4hpfZ3As/EdyP+4tHV+pIZHSYhhzGhdJl50sxeKATC6bFzyOY5/FDlIelgjluGDUEH8ScJQKbzSgoiDOR/LvqeOGZ7BT4KYrUOQUdCimw1J7hTMQEMOKXkfW5Vf4ecyL5lg4HcieLf0x6pPpJTySMJ5REWiDGjwF+6rB8iHrQCdJuTogKufCM4nKelwKEwI9S+mDY1ZhRlqT2jrb0/LLxCo6hO/47WnDWQtKbTyWqLw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Gg8c6Y7qvuH4TK92icdAeZ7MVmqJAUjWyBm81tOvh5I=; b=lTwkjdzTI280vsHSiU0vO+Xpbkq0VuIBTMy+5hAlD2aylmfOKJjDdkO0a6vDIPdCCkZePYGtGvwMJ671F3r07ErzrT15qu+Iq2xAYbLToerYbS/c4uDsc0731Web4WXr6MMVWDR1QB9Zs2ACb6uawgr2gwJ/oQFSUWJl0DZOne+4G3Bi1Cs2nrGPOkpxwPjFW1oZ6ISstDyrzR/fEgAnVnHhRpQHToPA0233Wz+JYznXM4oLQy+bUrPR5J/jVc06554FPTdBaDAlMGgGailP+4Y3I3zCEztR6F4T8aR9CH9k6vtaE26ZPXK1wDN7ybZmwC+8wwcUYYuNs8Qv/Ehq8g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Gg8c6Y7qvuH4TK92icdAeZ7MVmqJAUjWyBm81tOvh5I=; b=NpTekijkc7+xvcHeyLReJ6ZL9GVOppZGlkdyQBFChF54lB+qWKKs4qfUeK885PpE8MtKAnbe7kHzN6mqdVThVFOYr5f8L/XyKa6xOps6Ty+wzRH+vBOPkqXuY0PS3Vi+a+mNZ7Q1ITrBcDFNw9F9fBIxrKr8yn/TIza/PvYgfto= Received: from MN2PR00MB0574.namprd00.prod.outlook.com (20.178.255.147) by MN2PR00MB0478.namprd00.prod.outlook.com (20.178.241.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2442.0; Thu, 31 Oct 2019 00:42:50 +0000 Received: from MN2PR00MB0574.namprd00.prod.outlook.com ([fe80::adbb:7ec8:334:2f7]) by MN2PR00MB0574.namprd00.prod.outlook.com ([fe80::adbb:7ec8:334:2f7%9]) with mapi id 15.20.2448.000; Thu, 31 Oct 2019 00:42:50 +0000 From: Mike Jones To: =?utf-8?B?w4lyaWMgVnluY2tl?= , The IESG CC: "draft-ietf-ace-cwt-proof-of-possession@ietf.org" , "ace-chairs@ietf.org" , "rdd@cert.org" , "ace@ietf.org" Thread-Topic: =?utf-8?B?w4lyaWMgVnluY2tlJ3MgTm8gT2JqZWN0aW9uIG9uIGRyYWZ0LWlldGYtYWNl?= =?utf-8?Q?-cwt-proof-of-possession-09:_(with_COMMENT)?= Thread-Index: AQHVjyhPiyunrDN3zkSmci3gXRRODqdz6X3g Date: Thu, 31 Oct 2019 00:42:49 +0000 Message-ID: References: <157244313194.32588.3480851326666905977.idtracker@ietfa.amsl.com> In-Reply-To: <157244313194.32588.3480851326666905977.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=88d2d0da-af9c-4c94-ba03-0000e4464e87; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2019-10-31T00:41:16Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [2001:4898:80e8:a:5a14:4e20:1624:50c8] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: a017f14a-0fe9-460d-40d0-08d75d9b41e1 x-ms-traffictypediagnostic: MN2PR00MB0478: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 02070414A1 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(366004)(346002)(376002)(396003)(39860400002)(189003)(13464003)(199004)(74316002)(186003)(5660300002)(66476007)(486006)(6436002)(11346002)(446003)(46003)(64756008)(66556008)(81166006)(4326008)(476003)(9686003)(76176011)(305945005)(6306002)(71200400001)(7696005)(6116002)(256004)(66946007)(99286004)(81156014)(14454004)(7736002)(86362001)(478600001)(55016002)(76116006)(6506007)(53546011)(102836004)(8990500004)(71190400001)(66446008)(2906002)(10290500003)(966005)(229853002)(6246003)(25786009)(54906003)(110136005)(316002)(22452003)(52536014)(33656002)(8936002)(224303003)(10090500001); DIR:OUT; SFP:1102; SCL:1; SRVR:MN2PR00MB0478; H:MN2PR00MB0574.namprd00.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 3lcMRCGytFcHYaIL7OxcctdfvzlB71m3IrEguo5PJ8cwZXK2XS8XC5Gd37+7TrIjtBO/PAyK+gh8bleCiITX26FyWoO5kNdhJSKkifokElqBvg0yRa+pid+W96nagkOoV+CgwWgGv3BhiolDQMH7XsOZT2KS3fKwr5pOlTRq8Ec0qtJHjVnbrNel1mNTCUrraRO+419E2r4eB8hXbGuKfUqbfst85mWqMBvllNuAe3d3LDsoZBT7rY6bynD86fNvyWILr5aBTn/EG/cnZeYZMNVSmJivd9gapH2C5QBj0oVKQf+Xxjl/gCWDMUpOWoHfHUp62kPXdW6mF4KNPmCIYquV7J4abf3VWoZORW8+mdP9Gx4sjsJSLUkRMWJr0yIybYwfIUXuCrdoqUGj4dQCowvZJ3hmEJkA6+vKubnE+E9Bs0+x2UvzC3qIZckL0ad4 x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: a017f14a-0fe9-460d-40d0-08d75d9b41e1 X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Oct 2019 00:42:49.8672 (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-CrossTenant-userprincipalname: q6GROxZBGJqYHw4yR3Aff9PF1Y+lPWHBykXPnzo7ydwesHzBH+tibz/aRu6W/2VLnsl2sLQdYhcyQ1BdjV9k/w== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR00MB0478 Archived-At: Subject: Re: [Ace] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-ietf-?= =?utf-8?q?ace-cwt-proof-of-possession-09=3A_=28with_COMMENT=29?= 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 Oct 2019 00:42:57 -0000 VGhhbmtzIGZvciB5b3VyIHJldmlldywgw4lyaWMuICBUaGUgImlzcyIgY2xhaW0gaXMgbm93IGV4 cGxhaW5lZCBvbiBmaXJzdCB1c2UgYXQgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LWlldGYtYWNlLWN3dC1wcm9vZi1vZi1wb3NzZXNzaW9uLTEwI3NlY3Rpb24tMyAocGFyYWxsZWxp bmcgdGhlIHRyZWF0bWVudCBvZiB0aGUgZmlyc3QgdXNlIG9mIHRoZSAic3ViIiBjbGFpbSkuDQoN CgkJCQlUaGFua3MgYWdhaW4sDQoJCQkJLS0gTWlrZQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KRnJvbTogw4lyaWMgVnluY2tlIHZpYSBEYXRhdHJhY2tlciA8bm9yZXBseUBpZXRmLm9y Zz4gDQpTZW50OiBXZWRuZXNkYXksIE9jdG9iZXIgMzAsIDIwMTkgNjo0NiBBTQ0KVG86IFRoZSBJ RVNHIDxpZXNnQGlldGYub3JnPg0KQ2M6IGRyYWZ0LWlldGYtYWNlLWN3dC1wcm9vZi1vZi1wb3Nz ZXNzaW9uQGlldGYub3JnOyBhY2UtY2hhaXJzQGlldGYub3JnOyByZGRAY2VydC5vcmc7IGFjZUBp ZXRmLm9yZw0KU3ViamVjdDogw4lyaWMgVnluY2tlJ3MgTm8gT2JqZWN0aW9uIG9uIGRyYWZ0LWll dGYtYWNlLWN3dC1wcm9vZi1vZi1wb3NzZXNzaW9uLTA5OiAod2l0aCBDT01NRU5UKQ0KDQrDiXJp YyBWeW5ja2UgaGFzIGVudGVyZWQgdGhlIGZvbGxvd2luZyBiYWxsb3QgcG9zaXRpb24gZm9yDQpk cmFmdC1pZXRmLWFjZS1jd3QtcHJvb2Ytb2YtcG9zc2Vzc2lvbi0wOTogTm8gT2JqZWN0aW9uDQoN CldoZW4gcmVzcG9uZGluZywgcGxlYXNlIGtlZXAgdGhlIHN1YmplY3QgbGluZSBpbnRhY3QgYW5k IHJlcGx5IHRvIGFsbCBlbWFpbCBhZGRyZXNzZXMgaW5jbHVkZWQgaW4gdGhlIFRvIGFuZCBDQyBs aW5lcy4gKEZlZWwgZnJlZSB0byBjdXQgdGhpcyBpbnRyb2R1Y3RvcnkgcGFyYWdyYXBoLCBob3dl dmVyLikNCg0KDQpQbGVhc2UgcmVmZXIgdG8gaHR0cHM6Ly9uYW0wNi5zYWZlbGlua3MucHJvdGVj dGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGd3d3LmlldGYub3JnJTJGaWVzZyUy RnN0YXRlbWVudCUyRmRpc2N1c3MtY3JpdGVyaWEuaHRtbCZhbXA7ZGF0YT0wMiU3QzAxJTdDTWlj aGFlbC5Kb25lcyU0MG1pY3Jvc29mdC5jb20lN0NhYzk5N2Q0NTJhN2I0ZTc4YTEwNDA4ZDc1ZDNm NmY3YSU3QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3QzAlN0M2MzcwODAz OTkzNjM0NTIwOTEmYW1wO3NkYXRhPWpFWG5pdnVHS1Z3YWEwWXElMkZ4RHhGNFBGNGhRR1JpVTk2 ckElMkJ2NWpmQU1FJTNEJmFtcDtyZXNlcnZlZD0wDQpmb3IgbW9yZSBpbmZvcm1hdGlvbiBhYm91 dCBJRVNHIERJU0NVU1MgYW5kIENPTU1FTlQgcG9zaXRpb25zLg0KDQoNClRoZSBkb2N1bWVudCwg YWxvbmcgd2l0aCBvdGhlciBiYWxsb3QgcG9zaXRpb25zLCBjYW4gYmUgZm91bmQgaGVyZToNCmh0 dHBzOi8vbmFtMDYuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUz QSUyRiUyRmRhdGF0cmFja2VyLmlldGYub3JnJTJGZG9jJTJGZHJhZnQtaWV0Zi1hY2UtY3d0LXBy b29mLW9mLXBvc3Nlc3Npb24lMkYmYW1wO2RhdGE9MDIlN0MwMSU3Q01pY2hhZWwuSm9uZXMlNDBt aWNyb3NvZnQuY29tJTdDYWM5OTdkNDUyYTdiNGU3OGExMDQwOGQ3NWQzZjZmN2ElN0M3MmY5ODhi Zjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0MwJTdDNjM3MDgwMzk5MzYzNDUyMDkxJmFt cDtzZGF0YT1WZUZGayUyQmNxeWtMS25zeW5ORldRZ1M5RVJEMjhnR0QlMkJhN2NodFJoMENZbyUz RCZhbXA7cmVzZXJ2ZWQ9MA0KDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KQ09NTUVOVDoNCi0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0NCg0KVGhhbmsgeW91IGZvciB0aGUgd29yayBwdXQgaW50byB0aGlzIGRvY3VtZW50LiBU aGUgZG9jdW1lbnQgaXMgZWFzeSB0byByZWFkLiBJIG9ubHkgb25lIG5pdCBpbiBzZWN0aW9uIDMg YW5kIGZlZWwgZnJlZSB0byBpZ25vcmUgYWxsIG9mIGl0OiBXaGlsZSAic3ViIiBpcyBleHBsYWlu ZWQgYXMgYmVpbmcgdGhlICJzdWJqZWN0Iiwgbm90aGluZyBpcyB3cml0dGVuIGFib3V0ICJpc3Mi IGNsYWltIG9uIHRoZSBmaXJzdCB0aW1lIHRoaXMgdGVybSBpcyB1c2VkLCBpdCBpcyBvbmx5IGV4 cGxhaW5lZCB0aGUgMm5kIHRpbWUuDQoNCkZvciBteSBJRVNHIGNvbGxlYWd1ZXMsIEkgc2Vjb25k IE1pcmphJ3MgY29tbWVudCBhYm91dCBhZGRpbmcgYSBJQU5BIHJlZ2lzdHJ5IGVudHJ5IGJhc2Vk IG9uIGVtYWlsLg0KDQpSZWdhcmRzLA0KDQotw6lyaWMNCg0KDQo= From nobody Wed Oct 30 17:48: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 72716120233; Wed, 30 Oct 2019 17:48:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 Z2cymG5SbDtg; Wed, 30 Oct 2019 17:48:01 -0700 (PDT) Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650121.outbound.protection.outlook.com [40.107.65.121]) (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 8B9A412011A; Wed, 30 Oct 2019 17:48:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=dF/6WnRRL98gfCrnaY9yqcMil9xvvwGmLkHIx4G7DfNDP3TxosRzuDhdgsUY1/2I5O5I3flF/ZZP9XtB1CcLsKESgO5Gk4UFiIuQVaW3SfAjfLFhYriPfgPx0SN9xkm5jN4zd9doBkEXUws6d5sEjoGiokRl0ueBxzZ8/wEoU5janbpSzupK6D9t0dizF0xugplvXopF91Y29O2HGI6T/5i4tciQrqYFmrD3JeG5Z3D2F2HmccIEufcFyoXVBnVQ7BDSuQBKvcUzU2v1wkjYqMAGT1zCMlpLcO147pUrMQCMzR5nQbHerzftl2ZWeCqO4AKppfp5y6HWtOXjoSQvBg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=x9KrCwWN9n4iR1JVqRvm3+Cxvx8xUxCLCpZdneEpQVU=; b=BNrqwg5ySD66ndBu/EqBmdM+jnZz88W7Vq3MUo1NGJHd5tQwQ6d9njEj9CniM72lSEkgaCTXMaFaOxJBVYoQJjxJD8aYE3FmeCJ3FxnNxq3xEjvRI80IT60zGP4f8ulcrcpTBiB9hxwyFf8mCHdUHtZgBUxczlnCUZ3HyFp3zsf3pBx6Z4IFYo6H8yTZvt9Gkb0CuXJQY06ZEX8IRPPnGgraTANNYKRteJbiEIeyt/cWldWOcx7z7F5dNXSGmGVuWy6pxJ1uYZNaS5NzV87fVJU7QPhR1j3iED0mQmyMaU4mn7EyBbG8QJooXo1cwzQ009MlrdQ5DqBwYZ5mZ9Qjxg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=x9KrCwWN9n4iR1JVqRvm3+Cxvx8xUxCLCpZdneEpQVU=; b=ftRiFJt1WvTRaPbF5W0fsJ/9+m/Yfyn5/1ms0ggux9m5Kw6IxPHZL4HqKBb/5rVgH13kdUQsghj0EneZbefPELycpn+h+QyEDxsm+bIOE9n1t5bANeHH+DDNYzXx9IvHB0vOBO359fCS79JFwSxWTIVxQ+UryHXgolwxE1f2cp4= Received: from MN2PR00MB0574.namprd00.prod.outlook.com (20.178.255.147) by MN2PR00MB0511.namprd00.prod.outlook.com (20.178.243.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2415.0; Thu, 31 Oct 2019 00:47:58 +0000 Received: from MN2PR00MB0574.namprd00.prod.outlook.com ([fe80::adbb:7ec8:334:2f7]) by MN2PR00MB0574.namprd00.prod.outlook.com ([fe80::adbb:7ec8:334:2f7%9]) with mapi id 15.20.2448.000; Thu, 31 Oct 2019 00:47:58 +0000 From: Mike Jones To: Benjamin Kaduk CC: "Roman D. Danyliw" , "ace-chairs@ietf.org" , Mirja Kuehlewind , The IESG , "ace@ietf.org" , "draft-ietf-ace-cwt-proof-of-possession@ietf.org" , Barry Leiba Thread-Topic: =?iso-8859-1?Q?[Ace]__Mirja_K=FChlewind's_No_Objection_on_draft-ietf-ace-?= =?iso-8859-1?Q?cwt-proof-of-possession-09:_(with_COMMENT)?= Thread-Index: AQHVj4I83tyN1TOmrUmAhnUNA0Lq0qdz6adg Date: Thu, 31 Oct 2019 00:47:57 +0000 Message-ID: References: <157201926102.4337.10953843577545450235.idtracker@ietfa.amsl.com> <20191028153150.GY69013@kduck.mit.edu> <4F15E6F7-2DA0-4C90-B891-DDA65917D1A7@kuehlewind.net> <20191031002855.GC88302@kduck.mit.edu> In-Reply-To: <20191031002855.GC88302@kduck.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=30dfe3e6-4594-47ba-b9e7-0000f28564ab; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2019-10-31T00:44:22Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [2001:4898:80e8:a:5a14:4e20:1624:50c8] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 32e4faa5-190c-49b7-c1bf-08d75d9bf94b x-ms-traffictypediagnostic: MN2PR00MB0511: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 02070414A1 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(366004)(396003)(346002)(136003)(39860400002)(199004)(189003)(51914003)(13464003)(966005)(81166006)(316002)(478600001)(81156014)(229853002)(14444005)(256004)(10290500003)(446003)(66574012)(52536014)(224303003)(25786009)(6116002)(22452003)(8936002)(54906003)(5660300002)(11346002)(46003)(6916009)(486006)(8990500004)(74316002)(7736002)(53546011)(305945005)(71200400001)(2906002)(10090500001)(33656002)(6306002)(7696005)(476003)(76176011)(86362001)(55016002)(66946007)(6246003)(64756008)(6436002)(71190400001)(66556008)(66476007)(14454004)(76116006)(9686003)(102836004)(186003)(4326008)(99286004)(66446008)(6506007)(2171002); DIR:OUT; SFP:1102; SCL:1; SRVR:MN2PR00MB0511; H:MN2PR00MB0574.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: BCL:0; x-microsoft-antispam-message-info: g93vz5swZIJzAZIVG9Epuw1UqPVfMSgRM1oqlFhvXPm+5hJYjqhCK1AihDa0MDaJJ+FerjdiRihtKyfgomJPZZmYM9grV0P1chScxiOkv5I35X4VteuG0nFdUOhpX0Y0E2Wd7ycJFbpvK0EBYAy+1qZdB/sZ5hlrxNeQqn9OC4ENOKW45IP9x/x6dUPaPqjr41dudcC6liJZlqRgSDEX/H5p2Q4by1r9Ri4A9/usoK0CdoL33coRZgxQVsjPRKXPnLmwybqTOK+cW1pq4F4fXYQ3wZt2op6wCBNpRRRjLA8JDVmfVJgWi1svH2NhP8AemZNPYZbuIaP7wcwNUL9MMbJEmeT87EzI74L2X2W5d1ygzfordnwYPP7UDBx8jGJWxzUTKXc9dnxLW96styDgjso02sBVi0qgtG+SlKvds3DtWa9TO4Ie1FdiFkCBNrU3 x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 32e4faa5-190c-49b7-c1bf-08d75d9bf94b X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Oct 2019 00:47:57.8201 (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-CrossTenant-userprincipalname: QtB/e6JdKRsU5FCe7lHKKBjMXyB6YlzIYIYkiIiFl2xB5wKpvYy2VZcbzQolI/3dL5y7jK2y1bdnpdsV5hj5EQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR00MB0511 Archived-At: Subject: Re: [Ace] =?iso-8859-1?q?Mirja_K=FChlewind=27s_No_Objection_on_draft?= =?iso-8859-1?q?-ietf-ace-cwt-proof-of-possession-09=3A_=28with_COMMENT=29?= 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 Oct 2019 00:48:06 -0000 Thanks for the clarification, Ben. I'm fine with this going either way (ap= peal to IESG or appeal to IANA). Just drop me a note after the issue is di= scussed on the telechat and I'll turn around a new draft right away tomorro= w, if requested. Later, -- Mike -----Original Message----- From: Ace On Behalf Of Benjamin Kaduk Sent: Wednesday, October 30, 2019 5:29 PM To: Mike Jones Cc: Roman D. Danyliw ; ace-chairs@ietf.org; Mirja Kuehlewind = ; The IESG ; ace@ietf.org; draft-ietf-a= ce-cwt-proof-of-possession@ietf.org; Barry Leiba Subject: Re: [Ace] Mirja K=FChlewind's No Objection on draft-ietf-ace-cwt-p= roof-of-possession-09: (with COMMENT) Just to be clear, IANA raising the issue to the IESG is described in Sectio= n 5.3 of RFC 8126, which would be the default expectations if an individual= document/registry did not give other instructions. -Ben On Thu, Oct 31, 2019 at 12:13:58AM +0000, Mike Jones wrote: > I'm in the process of creating -10, which addresses the IESG comments oth= er than Mirja's. I'm reluctant to change the registration instructions, as= they are currently identical to those for CWTs (and many other specificati= ons going back to at least RFC 6749, modulo the name of the mailing list). = That said, if the IESG *really* wants to change the party to appeal to in = the case of non-action from the Designated Experts from the IESG to IANA, I= 'm amenable to also making that change tomorrow, immediately following the = telechat, so we can send the spec on to the RFC Editor. Let me know what y= ou decide. >=20 > Thanks again, > -- Mike >=20 > -----Original Message----- > From: Barry Leiba > Sent: Monday, October 28, 2019 2:00 PM > To: Mike Jones > Cc: Mirja Kuehlewind ; Benjamin Kaduk=20 > ; Roman D. Danyliw ; ace-chairs@ietf.org;=20 > The IESG ; ace@ietf.org;=20 > draft-ietf-ace-cwt-proof-of-possession@ietf.org > Subject: Re: [Ace] Mirja K=FChlewind's No Objection on=20 > draft-ietf-ace-cwt-proof-of-possession-09: (with COMMENT) >=20 > The issue isn't using a mailing list. The issue is the instructions to I= ANA about how to do management and tracking, stuff that they do just fine w= ithout working groups trying -- will all good intentions -- to tell them ho= w. >=20 > The fact that there are a lot of RFCs that do it just says that working g= roups do this frequently, and most ADs don't notice or don't care. And the= reality is that IANA will manage the registration process how they do it, = accommodating reasonable special instructions when they can. The point is = that documents shouldn't be giving special instructions unless there really= is something special needed for a particular reason. >=20 > Barry >=20 > On Mon, Oct 28, 2019 at 12:19 PM Mike Jones = wrote: > > > > The practice of using a mailing list for registration requests to enabl= e public visibility of them goes back at least to .well-known URI registrat= ions https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fto= ols.ietf.org%2Fhtml%2Frfc5785&data=3D02%7C01%7CMichael.Jones%40microsof= t.com%7C0b217822fdab454c213408d75d995cec%7C72f988bf86f141af91ab2d7cd011db47= %7C1%7C0%7C637080785592172015&sdata=3DdvBR4fRzp1xSMcqXyaSa68Px7AJs3alww= TPJVH4YyMA%3D&reserved=3D0 by Mark Nottingham in April 2010. OAuth 2.0= followed this practice in RFC 6749, as did the JOSE specs and JWT in RFCs = 7515-19. The rest is history, as they say. > > > > -- Mike > > > > -----Original Message----- > > From: Mirja Kuehlewind > > Sent: Monday, October 28, 2019 8:54 AM > > To: Benjamin Kaduk > > Cc: Barry Leiba ; Roman D. Danyliw=20 > > ; ace-chairs@ietf.org; The IESG ;=20 > > ace@ietf.org; draft-ietf-ace-cwt-proof-of-possession@ietf.org > > Subject: Re: [Ace] Mirja K=FChlewind's No Objection on > > draft-ietf-ace-cwt-proof-of-possession-09: (with COMMENT) > > > > These are all quite recents examples, so maybe the procedures are chang= ing at the moment. I guess we as the IESG should be aware and figure out wh= at the right procedure actually should be here. > > > > > On 28. Oct 2019, at 16:31, Benjamin Kaduk wrote: > > > > > > On Fri, Oct 25, 2019 at 12:31:42PM -0400, Barry Leiba wrote: > > >> Yeh, it's very common for authors to try to tell IANA how to=20 > > >> handle registrations, and I often push back on that as inappropriate= . > > >> There are certainly special conditions that IANA should be told=20 > > >> about, but this is standard work-flow management stuff that ought=20 > > >> to be left to IANA. I do think it should be changed before this=20 > > >> is published, probably just removing that last sentence. > > > > > > While I'm not opposed to normalizing on a default procedure, I=20 > > > think the authors were just trying to follow existing examples. > > > > > > RFC 7519: > > > > > > Values are registered on a Specification Required [RFC5226] basis > > > after a three-week review period on the jwt-reg-review@ietf.org > > > mailing list, on the advice of one or more Designated Experts. > > > However, to allow for the allocation of values prior to publication= , > > > the Designated Experts may approve registration once they are > > > satisfied that such a specification will be published. > > > > > > Registration requests sent to the mailing list for review should us= e > > > an appropriate subject (e.g., "Request to register claim: example")= . > > > > > > Within the review period, the Designated Experts will either approv= e > > > or deny the registration request, communicating this decision to th= e > > > review list and IANA. Denials should include an explanation and, i= f > > > applicable, suggestions as to how to make the request successful. > > > Registration requests that are undetermined for a period longer tha= n > > > 21 days can be brought to the IESG's attention (using the > > > iesg@ietf.org mailing list) for resolution. > > > > > > RFC 8414: > > > > > > Values are registered on a Specification Required [RFC8126] basis > > > after a two-week review period on the oauth-ext-review@ietf.org > > > mailing list, on the advice of one or more Designated Experts. > > > However, to allow for the allocation of values prior to publication= , > > > the Designated Experts may approve registration once they are > > > satisfied that such a specification will be published. > > > > > > Registration requests sent to the mailing list for review should us= e > > > an appropriate subject (e.g., "Request to register OAuth > > > Authorization Server Metadata: example"). > > > > > > Within the review period, the Designated Experts will either approv= e > > > or deny the registration request, communicating this decision to th= e > > > review list and IANA. Denials should include an explanation and, i= f > > > applicable, suggestions as to how to make the request successful. > > > Registration requests that are undetermined for a period longer tha= n > > > 21 days can be brought to the IESG's attention (using the > > > iesg@ietf.org mailing list) for resolution. > > > > > > RFC 8447: > > > > > > Specification Required [RFC8126] registry requests are registered > > > after a three-week review period on the > > > mailing list, on the advice of one or more designated experts. > > > However, to allow for the allocation of values prior to publication= , > > > the designated experts may approve registration once they are > > > satisfied that such a specification will be published. > > > > > > Registration requests sent to the mailing list for review SHOULD us= e > > > an appropriate subject (e.g., "Request to register value in TLS bar > > > registry"). > > > > > > Within the review period, the designated experts will either approv= e > > > or deny the registration request, communicating this decision to th= e > > > review list and IANA. Denials SHOULD include an explanation and, i= f > > > applicable, suggestions as to how to make the request successful. > > > Registration requests that are undetermined for a period longer tha= n > > > 21 days can be brought to the IESG's attention (using the > > > mailing list) for resolution. > > > > > > [I stopped looking here] > > > > > > So if we're going to change things around, maybe we should issue=20 > > > an IESG statement. > > > > > > -Ben > > > > > > > > _______________________________________________ Ace mailing list Ace@ietf.org https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.iet= f.org%2Fmailman%2Flistinfo%2Face&data=3D02%7C01%7CMichael.Jones%40micro= soft.com%7C0b217822fdab454c213408d75d995cec%7C72f988bf86f141af91ab2d7cd011d= b47%7C1%7C0%7C637080785592182009&sdata=3D8VdwDB36GMdeSsrXWDUK0DZ8%2Bvjc= QJKcV5I95588UQo%3D&reserved=3D0 From nobody Wed Oct 30 17:53: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 08896120086; Wed, 30 Oct 2019 17:53:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 Z7SSWPEFpPoz; Wed, 30 Oct 2019 17:53:10 -0700 (PDT) Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650107.outbound.protection.outlook.com [40.107.65.107]) (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 8B9FD12006B; Wed, 30 Oct 2019 17:53:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=E2BzKE2wCacrnP9HI5TUVrZGEd8dP+ELpInfhDujVHL7oM2t9+Y7H5wZRm6GRRlUZOPaaFNuG25vJp5W4aKezZbyucAhpD/hqbQGIdRzX30kwvlsRt0Dhl8zse5u1gm2+qTePLHBBm2D1QIOkyNuG8gq4q/rVdaeyOAP78JW7KNlD6FucuZy9h2Jo3YgbdQ2ItFmVrYNdZ8v8Xv6bW4Jpz+der63QzLzUeVi+Ac4V/qrUPuwabjnwDz3A4IWzhapgl7soNDxNnhQJXm/Zp8fpruPr6CNKuiLrnR3M+2Iyd2LAdJJ3oMuTJTXikZnlhrYpHGSuQqXwmEsQw1Eqt3lLw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=U5rKWpOp/GWrVxkzKDUAGaPGZFTyu0Krq06KjX4FwGE=; b=Cqfv51xXRyjFjcl4fKXMA2j+B3GbBJKTxUgvHmxCbj6JCIGLUOHUW4bylK1QZkJMoh2pSsydHDliI8zsntjqqNnfCS7wPd7QG4Q+8Cn0EvQl0Dft3palh4LaReMj0FNw3EzH879eXcD1+01Mt8dwr3Mg+wHFHX491J/4hwxhnVSAWSn8wdmPamctQy3smbNukNlscIbCW1LCdWZyUHKMIyvvfNN8FWnSueNg0o1obIBV6ze+cRFfCtRFEp/goJUF2LBivaiUgECldF5MRl8KpyhHzorH/rEGedSF9n6wCW1AA9RwuOltAeYAuuf75gqaY8YTjwUbNMAc+wqhutnIHQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=U5rKWpOp/GWrVxkzKDUAGaPGZFTyu0Krq06KjX4FwGE=; b=g8oqpul1t3EO5xmphJ9jX/yyOXY7M0HhSerf23HwYeVYqNzo3/iVOlLRHSqPj0g95hbODUmd3ca7P8hrqBMz2z6Yx25Z1ZkobZ80WmA59EsLWaAxlA7egSajfNeQcTIfRqkl+ohGxXfUCfEZo4hJVu+pqxXU6EdblyqjwFFLVcs= Received: from MN2PR00MB0574.namprd00.prod.outlook.com (20.178.255.147) by MN2PR00MB0511.namprd00.prod.outlook.com (20.178.243.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2415.0; Thu, 31 Oct 2019 00:53:06 +0000 Received: from MN2PR00MB0574.namprd00.prod.outlook.com ([fe80::adbb:7ec8:334:2f7]) by MN2PR00MB0574.namprd00.prod.outlook.com ([fe80::adbb:7ec8:334:2f7%9]) with mapi id 15.20.2448.000; Thu, 31 Oct 2019 00:53:06 +0000 From: Mike Jones To: "ace@ietf.org" , "i-d-announce@ietf.org" CC: Adam Roach , =?utf-8?B?w4lyaWMgVnluY2tl?= Thread-Topic: [Ace] I-D Action: draft-ietf-ace-cwt-proof-of-possession-10.txt Thread-Index: AQHVj4K4T2ydyJbjM0S0a89MIygWj6dz61CA Date: Thu, 31 Oct 2019 00:53:06 +0000 Message-ID: References: <157248195825.32490.14170581190430072021@ietfa.amsl.com> In-Reply-To: <157248195825.32490.14170581190430072021@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=6f3ab3f2-4b92-48d5-a3ee-00006bc92835; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2019-10-31T00:50:19Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [2001:4898:80e8:a:5a14:4e20:1624:50c8] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: bca35d9e-0555-497b-7af1-08d75d9cb12c x-ms-traffictypediagnostic: MN2PR00MB0511: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-forefront-prvs: 02070414A1 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(366004)(396003)(346002)(136003)(39860400002)(199004)(189003)(13464003)(966005)(81166006)(8676002)(316002)(478600001)(81156014)(229853002)(256004)(10290500003)(446003)(66574012)(52536014)(4001150100001)(25786009)(6116002)(22452003)(8936002)(54906003)(110136005)(5660300002)(11346002)(46003)(486006)(8990500004)(74316002)(7736002)(53546011)(305945005)(71200400001)(2906002)(10090500001)(33656002)(6306002)(7696005)(476003)(76176011)(86362001)(55016002)(66946007)(6246003)(64756008)(6436002)(71190400001)(66556008)(66476007)(14454004)(2501003)(76116006)(9686003)(102836004)(186003)(4326008)(99286004)(66446008)(6506007); DIR:OUT; SFP:1102; SCL:1; SRVR:MN2PR00MB0511; H:MN2PR00MB0574.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: BCL:0; x-microsoft-antispam-message-info: 5ThkFgKeV57FYyuVSE5Ko5syeyxXmaAJSCnoQPe+ayExr+wbrSHGB/XAiD8NxeVCFi4DVQOJ7YB8t3CvkWW2KFlOVyKpUjdnwwCY1eSnANqghJDT9dPOrJRXFDFjvzhFsVG+YWciOqAu0g85CXdUYACco7fBvF12fNMUNU6wtB7ySTwpIDQ2ZFi4TULohxxKdFVQGqEu4HVokWhyH1Y1H7dZB70FVs/PZ5DWlBFrjGJzRAJpJnC3sltxt48KNJntMPy3Y1mvOFpZ5TqbjCqN9Ng8Sh8ZqUqqahrIcrWgjrGwoHU8QBZntL9KPjbkC4wdZjNq9W2Kv/ox96GvAmoqgk6848P7vedE3q9YF6ATw9y85HH714YR8Mm8llJovzLknJfvdC6tMad2lSFhyfn8dV5X4gyqFY8PHHIRebxMGiLP11lZYj9s1xS+I8foYeEI x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: bca35d9e-0555-497b-7af1-08d75d9cb12c X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Oct 2019 00:53:06.3159 (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-CrossTenant-userprincipalname: zrMWHsS0sWaQjGxBC7iArmxUtyFLalT2d07kb4R7HRXwtJtSEPlXKx5aCs8wN41qXs0jiajzMNlQWD6MwN6aCw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR00MB0511 Archived-At: Subject: Re: [Ace] I-D Action: draft-ietf-ace-cwt-proof-of-possession-10.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 Oct 2019 00:53:13 -0000 VGhpcyB2ZXJzaW9uIGFkZHJlc3NlcyBJRVNHIGNvbW1lbnRzIGZyb20gQWRhbSBSb2FjaCBhbmQg w4lyaWMgVnluY2tlLCBib3RoIG9mIHdoaWNoIHJlc3VsdGVkIGluIGxvY2FsIGVkaXRvcmlhbCBp bXByb3ZlbWVudHMgdG8gdGhlIGRvY3VtZW50Lg0KDQoJCQkJLS0gTWlrZQ0KDQotLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogQWNlIDxhY2UtYm91bmNlc0BpZXRmLm9yZz4gT24gQmVo YWxmIE9mIGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZw0KU2VudDogV2VkbmVzZGF5LCBPY3RvYmVy IDMwLCAyMDE5IDU6MzMgUE0NClRvOiBpLWQtYW5ub3VuY2VAaWV0Zi5vcmcNCkNjOiBhY2VAaWV0 Zi5vcmcNClN1YmplY3Q6IFtBY2VdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtYWNlLWN3dC1wcm9v Zi1vZi1wb3NzZXNzaW9uLTEwLnR4dA0KDQoNCkEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWls YWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cyBkaXJlY3Rvcmllcy4NClRoaXMg ZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlIEF1dGhlbnRpY2F0aW9uIGFuZCBBdXRob3JpemF0 aW9uIGZvciBDb25zdHJhaW5lZCBFbnZpcm9ubWVudHMgV0cgb2YgdGhlIElFVEYuDQoNCiAgICAg ICAgVGl0bGUgICAgICAgICAgIDogUHJvb2Ytb2YtUG9zc2Vzc2lvbiBLZXkgU2VtYW50aWNzIGZv ciBDQk9SIFdlYiBUb2tlbnMgKENXVHMpDQogICAgICAgIEF1dGhvcnMgICAgICAgICA6IE1pY2hh ZWwgQi4gSm9uZXMNCiAgICAgICAgICAgICAgICAgICAgICAgICAgTHVkd2lnIFNlaXR6DQogICAg ICAgICAgICAgICAgICAgICAgICAgIEfDtnJhbiBTZWxhbmRlcg0KICAgICAgICAgICAgICAgICAg ICAgICAgICBTYW11ZWwgRXJkdG1hbg0KICAgICAgICAgICAgICAgICAgICAgICAgICBIYW5uZXMg VHNjaG9mZW5pZw0KCUZpbGVuYW1lICAgICAgICA6IGRyYWZ0LWlldGYtYWNlLWN3dC1wcm9vZi1v Zi1wb3NzZXNzaW9uLTEwLnR4dA0KCVBhZ2VzICAgICAgICAgICA6IDE2DQoJRGF0ZSAgICAgICAg ICAgIDogMjAxOS0xMC0zMA0KDQpBYnN0cmFjdDoNCiAgIFRoaXMgc3BlY2lmaWNhdGlvbiBkZXNj cmliZXMgaG93IHRvIGRlY2xhcmUgaW4gYSBDQk9SIFdlYiBUb2tlbiAoQ1dUKQ0KICAgKHdoaWNo IGlzIGRlZmluZWQgYnkgUkZDIDgzOTIpIHRoYXQgdGhlIHByZXNlbnRlciBvZiB0aGUgQ1dUDQog ICBwb3NzZXNzZXMgYSBwYXJ0aWN1bGFyIHByb29mLW9mLXBvc3Nlc3Npb24ga2V5LiAgQmVpbmcg YWJsZSB0byBwcm92ZQ0KICAgcG9zc2Vzc2lvbiBvZiBhIGtleSBpcyBhbHNvIHNvbWV0aW1lcyBk ZXNjcmliZWQgYXMgYmVpbmcgdGhlIGhvbGRlci0NCiAgIG9mLWtleS4gIFRoaXMgc3BlY2lmaWNh dGlvbiBwcm92aWRlcyBlcXVpdmFsZW50IGZ1bmN0aW9uYWxpdHkgdG8NCiAgICJQcm9vZi1vZi1Q b3NzZXNzaW9uIEtleSBTZW1hbnRpY3MgZm9yIEpTT04gV2ViIFRva2VucyAoSldUcykiIChSRkMN CiAgIDc4MDApIGJ1dCB1c2luZyBDb25jaXNlIEJpbmFyeSBPYmplY3QgUmVwcmVzZW50YXRpb24g KENCT1IpIGFuZCBDV1RzDQogICByYXRoZXIgdGhhbiBKYXZhU2NyaXB0IE9iamVjdCBOb3RhdGlv biAoSlNPTikgYW5kIEpTT04gV2ViIFRva2Vucw0KICAgKEpXVHMpLg0KDQoNClRoZSBJRVRGIGRh dGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOg0KaHR0cHM6Ly9uYW0wNi5z YWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGZGF0YXRy YWNrZXIuaWV0Zi5vcmclMkZkb2MlMkZkcmFmdC1pZXRmLWFjZS1jd3QtcHJvb2Ytb2YtcG9zc2Vz c2lvbiUyRiZhbXA7ZGF0YT0wMiU3QzAxJTdDTWljaGFlbC5Kb25lcyU0MG1pY3Jvc29mdC5jb20l N0M4ZjhmYmQwNTU0YTU0YTQyNWVhYzA4ZDc1ZDk5ZDgxNCU3QzcyZjk4OGJmODZmMTQxYWY5MWFi MmQ3Y2QwMTFkYjQ3JTdDMSU3QzAlN0M2MzcwODA3ODc2NzE3NzA3NTAmYW1wO3NkYXRhPTFETUto dmwlMkJaclRkZXJacVFPMWRQTVd4R3ZQcFVCSDBRYWtXWjduaFQlMkJ3JTNEJmFtcDtyZXNlcnZl ZD0wDQoNClRoZXJlIGFyZSBhbHNvIGh0bWxpemVkIHZlcnNpb25zIGF2YWlsYWJsZSBhdDoNCmh0 dHBzOi8vbmFtMDYuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUz QSUyRiUyRnRvb2xzLmlldGYub3JnJTJGaHRtbCUyRmRyYWZ0LWlldGYtYWNlLWN3dC1wcm9vZi1v Zi1wb3NzZXNzaW9uLTEwJmFtcDtkYXRhPTAyJTdDMDElN0NNaWNoYWVsLkpvbmVzJTQwbWljcm9z b2Z0LmNvbSU3QzhmOGZiZDA1NTRhNTRhNDI1ZWFjMDhkNzVkOTlkODE0JTdDNzJmOTg4YmY4NmYx NDFhZjkxYWIyZDdjZDAxMWRiNDclN0MxJTdDMCU3QzYzNzA4MDc4NzY3MTc3MDc1MCZhbXA7c2Rh dGE9SSUyQkwzQTg2czV1dWZQcDh2UmZLMzFHTkpidEpyREMzdW1PaHhIN3o1ckNJJTNEJmFtcDty ZXNlcnZlZD0wDQpodHRwczovL25hbTA2LnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29t Lz91cmw9aHR0cHMlM0ElMkYlMkZkYXRhdHJhY2tlci5pZXRmLm9yZyUyRmRvYyUyRmh0bWwlMkZk cmFmdC1pZXRmLWFjZS1jd3QtcHJvb2Ytb2YtcG9zc2Vzc2lvbi0xMCZhbXA7ZGF0YT0wMiU3QzAx JTdDTWljaGFlbC5Kb25lcyU0MG1pY3Jvc29mdC5jb20lN0M4ZjhmYmQwNTU0YTU0YTQyNWVhYzA4 ZDc1ZDk5ZDgxNCU3QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3QzAlN0M2 MzcwODA3ODc2NzE3NzA3NTAmYW1wO3NkYXRhPXVsRm9kcFlPcGZtZ3dycXp1WCUyRno2bVRpTlNM MHZyalMzcm5HWDVtTXVVMCUzRCZhbXA7cmVzZXJ2ZWQ9MA0KDQpBIGRpZmYgZnJvbSB0aGUgcHJl dmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6DQpodHRwczovL25hbTA2LnNhZmVsaW5rcy5w cm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ3d3cuaWV0Zi5vcmclMkZy ZmNkaWZmJTNGdXJsMiUzRGRyYWZ0LWlldGYtYWNlLWN3dC1wcm9vZi1vZi1wb3NzZXNzaW9uLTEw JmFtcDtkYXRhPTAyJTdDMDElN0NNaWNoYWVsLkpvbmVzJTQwbWljcm9zb2Z0LmNvbSU3QzhmOGZi ZDA1NTRhNTRhNDI1ZWFjMDhkNzVkOTlkODE0JTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAx MWRiNDclN0MxJTdDMCU3QzYzNzA4MDc4NzY3MTc3MDc1MCZhbXA7c2RhdGE9Y2NoUHF1UEI1WlND RkpmTHA5MUJwMmF6ZEZ6N0hodHRTTmswVyUyQnZJUGljJTNEJmFtcDtyZXNlcnZlZD0wDQoNCg0K UGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhl IHRpbWUgb2Ygc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBh cmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KDQpJbnRlcm5ldC1EcmFmdHMgYXJlIGFs c28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6DQpmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50 ZXJuZXQtZHJhZnRzLw0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KQWNlIG1haWxpbmcgbGlzdA0KQWNlQGlldGYub3JnDQpodHRwczovL25hbTA2LnNh ZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ3d3cuaWV0 Zi5vcmclMkZtYWlsbWFuJTJGbGlzdGluZm8lMkZhY2UmYW1wO2RhdGE9MDIlN0MwMSU3Q01pY2hh ZWwuSm9uZXMlNDBtaWNyb3NvZnQuY29tJTdDOGY4ZmJkMDU1NGE1NGE0MjVlYWMwOGQ3NWQ5OWQ4 MTQlN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0MwJTdDNjM3MDgwNzg3 NjcxNzcwNzUwJmFtcDtzZGF0YT1UYUtiSEVLRkdJWERVZE1ySm9jZVl6U080d3NXRENWaXNNZFdx UUhaZlVBJTNEJmFtcDtyZXNlcnZlZD0wDQo= From nobody Wed Oct 30 18:15: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 1917912006D; Wed, 30 Oct 2019 18:15:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.679 X-Spam-Level: X-Spam-Status: No, score=-1.679 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.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 VAaGaKnHdWCv; Wed, 30 Oct 2019 18:15:04 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 BED4712006B; Wed, 30 Oct 2019 18:15:04 -0700 (PDT) Received: from Svantevit.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x9V1Et7R006892 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 30 Oct 2019 20:14:58 -0500 (CDT) (envelope-from adam@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1572484501; bh=DFrdzLl2w6qPc9Erw235IdX1OYNd+nc4fwgHhG0rvsQ=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=OfMEYB78+haGZA1jWylTW6m19G6O+X+Xx+dKVt1z90JMuToPaoAF4tL8d45XLtNM+ MLAE6TAiZHRi62nHrvXIFN6GqtcAP8kehEvwj1GGPyEKcUyATuBMfzhGHtQgb+2/Ma LfriczTX0331DZOsYgwjfibUaEhbEs/5fB7UZeNA= X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Svantevit.local To: Mike Jones , The IESG Cc: "draft-ietf-ace-cwt-proof-of-possession@ietf.org" , "ace-chairs@ietf.org" , "rdd@cert.org" , "ace@ietf.org" References: <157232923891.16185.1675206642162092837.idtracker@ietfa.amsl.com> From: Adam Roach Message-ID: <58b3c920-2358-b0ce-8945-c3f72822649a@nostrum.com> Date: Wed, 30 Oct 2019 20:14:50 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Ace] Adam Roach's No Objection on draft-ietf-ace-cwt-proof-of-possession-09: (with COMMENT) 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 Oct 2019 01:15:06 -0000 Thanks! Looks good to me. /a On 10/30/19 7:41 PM, Mike Jones wrote: > Thanks for your review, Adam. The questionable comment syntax that you pointed out has been changed to the unsurprising representation /HMAC 256-256/ in https://tools.ietf.org/html/draft-ietf-ace-cwt-proof-of-possession-10#section-3.3. > > Best wishes, > -- Mike > > -----Original Message----- > From: Adam Roach via Datatracker > Sent: Monday, October 28, 2019 11:07 PM > To: The IESG > Cc: draft-ietf-ace-cwt-proof-of-possession@ietf.org; ace-chairs@ietf.org; rdd@cert.org; ace@ietf.org > Subject: Adam Roach's No Objection on draft-ietf-ace-cwt-proof-of-possession-09: (with COMMENT) > > Adam Roach has entered the following ballot position for > draft-ietf-ace-cwt-proof-of-possession-09: No Objection > > When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) > > > Please refer to https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fiesg%2Fstatement%2Fdiscuss-criteria.html&data=02%7C01%7CMichael.Jones%40microsoft.com%7C1c9c12805d7c4b7ed6f408d75c3641ff%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637079260432123647&sdata=yV4geJmqHs6nE2KEz1HxXf55xRRlGQJdLgHEeKkzxus%3D&reserved=0 > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-ace-cwt-proof-of-possession%2F&data=02%7C01%7CMichael.Jones%40microsoft.com%7C1c9c12805d7c4b7ed6f408d75c3641ff%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637079260432123647&sdata=iOQpEcoj42%2FrW8qN8c38l931EGH%2BTM0qNgL1aC9aM3E%3D&reserved=0 > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > > Thanks for the work everyone put into defining this mechanism. I have one very minor comment that the authors may wish to take into account. > > §3.3: > >> /alg/ 3 : /HMAC256//256/ 5, > This use of "//" seems problematic, given RFC 8610's vague reservation of this sequence for some kind of "comment to end of line" designation: > > (There are currently no end-of-line comments. If we want to add > them, "//" sounds like a reasonable delimiter given that we already > use slashes for comments, but we could also go, for example, > for "#".) > > Given the potential ambiguity introduced by RFC 8610, perhaps consider some other syntax here instead of "//". > > From nobody Thu Oct 31 07:43:37 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 C37D91200B8; Thu, 31 Oct 2019 07:43:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: internet-drafts@ietf.org To: Cc: ace@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.108.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ace@ietf.org Message-ID: <157253301472.30380.9313695597907874615@ietfa.amsl.com> Date: Thu, 31 Oct 2019 07:43:34 -0700 Archived-At: Subject: [Ace] I-D Action: draft-ietf-ace-cwt-proof-of-possession-11.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 Oct 2019 14:43:35 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Authentication and Authorization for Constrained Environments WG of the IETF. Title : Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs) Authors : Michael B. Jones Ludwig Seitz Göran Selander Samuel Erdtman Hannes Tschofenig Filename : draft-ietf-ace-cwt-proof-of-possession-11.txt Pages : 16 Date : 2019-10-31 Abstract: This specification describes how to declare in a CBOR Web Token (CWT) (which is defined by RFC 8392) that the presenter of the CWT possesses a particular proof-of-possession key. Being able to prove possession of a key is also sometimes described as being the holder- of-key. This specification provides equivalent functionality to "Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)" (RFC 7800) but using Concise Binary Object Representation (CBOR) and CWTs rather than JavaScript Object Notation (JSON) and JSON Web Tokens (JWTs). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ace-cwt-proof-of-possession/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ace-cwt-proof-of-possession-11 https://datatracker.ietf.org/doc/html/draft-ietf-ace-cwt-proof-of-possession-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-cwt-proof-of-possession-11 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 Oct 31 07:49: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 9BB17120809; Thu, 31 Oct 2019 07:49:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 obh_5n9S3bti; Thu, 31 Oct 2019 07:49:10 -0700 (PDT) Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650105.outbound.protection.outlook.com [40.107.65.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3692E1207FE; Thu, 31 Oct 2019 07:49:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=eeLljbnfoVz6c/cBAHawVA1m0O3n08ol22d0Oywi8F5GwYqz+qV1HA4W6D0tSGYm4f/i1lThEdo2d9RLSvnZY75FJoEXUjHi0p3FGnERRQkmK8l/WiKUUg8puy6vK245cL6l8c+k2AGKck5eL8pYcJOJyjiDTahEnr5Rwu69vNOX4/1nsHE4kFw1yvt0bLu1taPFmaO1HHTxT2xkR4tiEsggQqbXnmdq6o4I82LQLY8pzKp49wCoqlRv7N7ZasMx3Y4WQyZchSHi800KHmRzL+9QypE2NgZn2F+QHWxw0MtnJVptTDJNZ4rsDhP5TAKDYjqRogiexOgvLeUaMayi8g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Tl54HIz/IhM+rvbapuo+BZD86+BCPaKBzj5VJ6faRmc=; b=gjw7A4Pvsv8ac9l55G08xstuJsNdOTgTpd4aEveS7TS1A36nK/caFxvKqnODkEhXHC8aU03OTvbqAl2L7HyChnDGUCVKxNrWpCjxgKXIl18W2om5voZVJDo33mpJ5nuVwMgz811VJxcXv1/30T9MO7r/Hh6TWqMry/6H/B9ZnMxA4/Y3lbsGNGJluT+MVyN5SBKIba+rF3MEMut8EEWBGPEWWAs4//BoutjvWfd6vk0cBtcZb+wHTMUFQCboH3esnR184cFodsa+8L+SXlY86qOS5tF5qNQEEnexRoV6xdFCZocdC08XNo3BukODYXcHbCOIYUq8K2O6uD09fqqsAw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Tl54HIz/IhM+rvbapuo+BZD86+BCPaKBzj5VJ6faRmc=; b=URYqFMJGTlMjzL4KXox2b8BhmiBH+AgGcw/iun5STAniy4MuA7NJHj++PTsPehdlS7kYnkEm2dd6ijrU/N2ywdZABozMPay8cWmfMKCKAiRNURu73JQv5PtVjsNU4Eogv5eZQhFL9q1A+qCCoBSPwbevqGTqKnioJ/jwgFUEY4A= Received: from DM6PR00MB0569.namprd00.prod.outlook.com (20.179.51.12) by DM6PR00MB0507.namprd00.prod.outlook.com (20.178.30.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2420.0; Thu, 31 Oct 2019 14:49:06 +0000 Received: from DM6PR00MB0569.namprd00.prod.outlook.com ([fe80::49:30:b130:e9b3]) by DM6PR00MB0569.namprd00.prod.outlook.com ([fe80::49:30:b130:e9b3%7]) with mapi id 15.20.2450.000; Thu, 31 Oct 2019 14:49:06 +0000 From: Mike Jones To: Benjamin Kaduk , Mirja Kuehlewind CC: "Roman D. Danyliw" , "ace-chairs@ietf.org" , The IESG , "ace@ietf.org" , "draft-ietf-ace-cwt-proof-of-possession@ietf.org" , Barry Leiba Thread-Topic: =?iso-8859-1?Q?[Ace]__Mirja_K=FChlewind's_No_Objection_on_draft-ietf-ace-?= =?iso-8859-1?Q?cwt-proof-of-possession-09:_(with_COMMENT)?= Thread-Index: AQHVj4I83tyN1TOmrUmAhnUNA0Lq0qdz6adggADrhPA= Date: Thu, 31 Oct 2019 14:49:06 +0000 Message-ID: References: <157201926102.4337.10953843577545450235.idtracker@ietfa.amsl.com> <20191028153150.GY69013@kduck.mit.edu> <4F15E6F7-2DA0-4C90-B891-DDA65917D1A7@kuehlewind.net> <20191031002855.GC88302@kduck.mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=30dfe3e6-4594-47ba-b9e7-0000f28564ab; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2019-10-31T00:44:22Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [50.47.93.218] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: f90b4422-a710-4aac-c927-08d75e117acf x-ms-traffictypediagnostic: DM6PR00MB0507: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 02070414A1 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(136003)(366004)(396003)(39860400002)(376002)(51914003)(13464003)(199004)(189003)(6306002)(305945005)(74316002)(25786009)(2906002)(476003)(26005)(66574012)(10090500001)(53546011)(3846002)(71200400001)(102836004)(55016002)(6506007)(7696005)(9686003)(486006)(81166006)(229853002)(256004)(8990500004)(4326008)(99286004)(186003)(76176011)(86362001)(6436002)(6246003)(6116002)(11346002)(14444005)(446003)(81156014)(224303003)(7736002)(2171002)(33656002)(71190400001)(14454004)(66066001)(10290500003)(8936002)(22452003)(64756008)(66556008)(478600001)(66446008)(66476007)(966005)(52536014)(5660300002)(66946007)(316002)(76116006)(110136005)(54906003); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR00MB0507; H:DM6PR00MB0569.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: BCL:0; x-microsoft-antispam-message-info: 5EEeIjKO5ngbC1YhxigYKe1yPRWN3P3S08gxY2z5vk3Fo4AvIb284QgSY399jYwUvqu/EO2oGMD6NJ1E7zLRjqI9+nwdZCxRvZ9zfiQXNhj/8gIYZWjYwV/h1LogORIieHr2qWrL0Sq8tEOe96V9kGadDAQBWLJDcBD2gr9bA7R+O/vDmylY4yPWxNrFICVcL5nCXnhojczbtJAoxgishPKH+8KH0paXOqwRKLx91qpTvOjk9EPpD/Trjw8CoT1HSW+liStaCpsryw6zeEeCzlk0tHZ5xBT5g9sy5bjJbjqCOq/YXSXlu0mKiK7IC37P1ejzAMJwF0fweIARswxObtPa20wRNvHG8+kNoNIg8ykbSuXNm9AvaXhszjXzShVfDhjQ9Nn0a+pvSFPatw4AJlD4DftMmd85cfM0nV8adFwunfQaoKDdtvIY7lojRLb/ x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: f90b4422-a710-4aac-c927-08d75e117acf X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Oct 2019 14:49:06.2348 (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-CrossTenant-userprincipalname: Gl1ZvaFWuDuJIS0qIdQrtUNFIU67ZXV5T0Tve29BAQ3pGa8qg9xANqYaCy8AxeaEoHfxoMVvoon6rpAizKh+xg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR00MB0507 Archived-At: Subject: Re: [Ace] =?iso-8859-1?q?Mirja_K=FChlewind=27s_No_Objection_on_draft?= =?iso-8859-1?q?-ietf-ace-cwt-proof-of-possession-09=3A_=28with_COMMENT=29?= 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 Oct 2019 14:49:14 -0000 Per the decision on the telechat, I have published -11, which removes the I= ESG appeal language in favor of direct appeal to the IESG. See https://too= ls.ietf.org/html/draft-ietf-ace-cwt-proof-of-possession-11#section-7. Please update the document status accordingly. Thank you, -- Mike -----Original Message----- From: Mike Jones=20 Sent: Wednesday, October 30, 2019 5:48 PM To: Benjamin Kaduk Cc: Roman D. Danyliw ; ace-chairs@ietf.org; Mirja Kuehlewind = ; The IESG ; ace@ietf.org; draft-ietf-a= ce-cwt-proof-of-possession@ietf.org; Barry Leiba Subject: RE: [Ace] Mirja K=FChlewind's No Objection on draft-ietf-ace-cwt-p= roof-of-possession-09: (with COMMENT) Thanks for the clarification, Ben. I'm fine with this going either way (ap= peal to IESG or appeal to IANA). Just drop me a note after the issue is di= scussed on the telechat and I'll turn around a new draft right away tomorro= w, if requested. Later, -- Mike -----Original Message----- From: Ace On Behalf Of Benjamin Kaduk Sent: Wednesday, October 30, 2019 5:29 PM To: Mike Jones Cc: Roman D. Danyliw ; ace-chairs@ietf.org; Mirja Kuehlewind = ; The IESG ; ace@ietf.org; draft-ietf-a= ce-cwt-proof-of-possession@ietf.org; Barry Leiba Subject: Re: [Ace] Mirja K=FChlewind's No Objection on draft-ietf-ace-cwt-p= roof-of-possession-09: (with COMMENT) Just to be clear, IANA raising the issue to the IESG is described in Sectio= n 5.3 of RFC 8126, which would be the default expectations if an individual= document/registry did not give other instructions. -Ben On Thu, Oct 31, 2019 at 12:13:58AM +0000, Mike Jones wrote: > I'm in the process of creating -10, which addresses the IESG comments oth= er than Mirja's. I'm reluctant to change the registration instructions, as= they are currently identical to those for CWTs (and many other specificati= ons going back to at least RFC 6749, modulo the name of the mailing list). = That said, if the IESG *really* wants to change the party to appeal to in = the case of non-action from the Designated Experts from the IESG to IANA, I= 'm amenable to also making that change tomorrow, immediately following the = telechat, so we can send the spec on to the RFC Editor. Let me know what y= ou decide. >=20 > Thanks again, > -- Mike >=20 > -----Original Message----- > From: Barry Leiba > Sent: Monday, October 28, 2019 2:00 PM > To: Mike Jones > Cc: Mirja Kuehlewind ; Benjamin Kaduk=20 > ; Roman D. Danyliw ; ace-chairs@ietf.org;=20 > The IESG ; ace@ietf.org;=20 > draft-ietf-ace-cwt-proof-of-possession@ietf.org > Subject: Re: [Ace] Mirja K=FChlewind's No Objection on > draft-ietf-ace-cwt-proof-of-possession-09: (with COMMENT) >=20 > The issue isn't using a mailing list. The issue is the instructions to I= ANA about how to do management and tracking, stuff that they do just fine w= ithout working groups trying -- will all good intentions -- to tell them ho= w. >=20 > The fact that there are a lot of RFCs that do it just says that working g= roups do this frequently, and most ADs don't notice or don't care. And the= reality is that IANA will manage the registration process how they do it, = accommodating reasonable special instructions when they can. The point is = that documents shouldn't be giving special instructions unless there really= is something special needed for a particular reason. >=20 > Barry >=20 > On Mon, Oct 28, 2019 at 12:19 PM Mike Jones = wrote: > > > > The practice of using a mailing list for registration requests to enabl= e public visibility of them goes back at least to .well-known URI registrat= ions https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fto= ols.ietf.org%2Fhtml%2Frfc5785&data=3D02%7C01%7CMichael.Jones%40microsof= t.com%7C0b217822fdab454c213408d75d995cec%7C72f988bf86f141af91ab2d7cd011db47= %7C1%7C0%7C637080785592172015&sdata=3DdvBR4fRzp1xSMcqXyaSa68Px7AJs3alww= TPJVH4YyMA%3D&reserved=3D0 by Mark Nottingham in April 2010. OAuth 2.0= followed this practice in RFC 6749, as did the JOSE specs and JWT in RFCs = 7515-19. The rest is history, as they say. > > > > -- Mike > > > > -----Original Message----- > > From: Mirja Kuehlewind > > Sent: Monday, October 28, 2019 8:54 AM > > To: Benjamin Kaduk > > Cc: Barry Leiba ; Roman D. Danyliw=20 > > ; ace-chairs@ietf.org; The IESG ;=20 > > ace@ietf.org; draft-ietf-ace-cwt-proof-of-possession@ietf.org > > Subject: Re: [Ace] Mirja K=FChlewind's No Objection on > > draft-ietf-ace-cwt-proof-of-possession-09: (with COMMENT) > > > > These are all quite recents examples, so maybe the procedures are chang= ing at the moment. I guess we as the IESG should be aware and figure out wh= at the right procedure actually should be here. > > > > > On 28. Oct 2019, at 16:31, Benjamin Kaduk wrote: > > > > > > On Fri, Oct 25, 2019 at 12:31:42PM -0400, Barry Leiba wrote: > > >> Yeh, it's very common for authors to try to tell IANA how to=20 > > >> handle registrations, and I often push back on that as inappropriate= . > > >> There are certainly special conditions that IANA should be told=20 > > >> about, but this is standard work-flow management stuff that ought=20 > > >> to be left to IANA. I do think it should be changed before this=20 > > >> is published, probably just removing that last sentence. > > > > > > While I'm not opposed to normalizing on a default procedure, I=20 > > > think the authors were just trying to follow existing examples. > > > > > > RFC 7519: > > > > > > Values are registered on a Specification Required [RFC5226] basis > > > after a three-week review period on the jwt-reg-review@ietf.org > > > mailing list, on the advice of one or more Designated Experts. > > > However, to allow for the allocation of values prior to publication= , > > > the Designated Experts may approve registration once they are > > > satisfied that such a specification will be published. > > > > > > Registration requests sent to the mailing list for review should us= e > > > an appropriate subject (e.g., "Request to register claim: example")= . > > > > > > Within the review period, the Designated Experts will either approv= e > > > or deny the registration request, communicating this decision to th= e > > > review list and IANA. Denials should include an explanation and, i= f > > > applicable, suggestions as to how to make the request successful. > > > Registration requests that are undetermined for a period longer tha= n > > > 21 days can be brought to the IESG's attention (using the > > > iesg@ietf.org mailing list) for resolution. > > > > > > RFC 8414: > > > > > > Values are registered on a Specification Required [RFC8126] basis > > > after a two-week review period on the oauth-ext-review@ietf.org > > > mailing list, on the advice of one or more Designated Experts. > > > However, to allow for the allocation of values prior to publication= , > > > the Designated Experts may approve registration once they are > > > satisfied that such a specification will be published. > > > > > > Registration requests sent to the mailing list for review should us= e > > > an appropriate subject (e.g., "Request to register OAuth > > > Authorization Server Metadata: example"). > > > > > > Within the review period, the Designated Experts will either approv= e > > > or deny the registration request, communicating this decision to th= e > > > review list and IANA. Denials should include an explanation and, i= f > > > applicable, suggestions as to how to make the request successful. > > > Registration requests that are undetermined for a period longer tha= n > > > 21 days can be brought to the IESG's attention (using the > > > iesg@ietf.org mailing list) for resolution. > > > > > > RFC 8447: > > > > > > Specification Required [RFC8126] registry requests are registered > > > after a three-week review period on the > > > mailing list, on the advice of one or more designated experts. > > > However, to allow for the allocation of values prior to publication= , > > > the designated experts may approve registration once they are > > > satisfied that such a specification will be published. > > > > > > Registration requests sent to the mailing list for review SHOULD us= e > > > an appropriate subject (e.g., "Request to register value in TLS bar > > > registry"). > > > > > > Within the review period, the designated experts will either approv= e > > > or deny the registration request, communicating this decision to th= e > > > review list and IANA. Denials SHOULD include an explanation and, i= f > > > applicable, suggestions as to how to make the request successful. > > > Registration requests that are undetermined for a period longer tha= n > > > 21 days can be brought to the IESG's attention (using the > > > mailing list) for resolution. > > > > > > [I stopped looking here] > > > > > > So if we're going to change things around, maybe we should issue=20 > > > an IESG statement. > > > > > > -Ben > > > > > > > > _______________________________________________ Ace mailing list Ace@ietf.org https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.iet= f.org%2Fmailman%2Flistinfo%2Face&data=3D02%7C01%7CMichael.Jones%40micro= soft.com%7C0b217822fdab454c213408d75d995cec%7C72f988bf86f141af91ab2d7cd011d= b47%7C1%7C0%7C637080785592182009&sdata=3D8VdwDB36GMdeSsrXWDUK0DZ8%2Bvjc= QJKcV5I95588UQo%3D&reserved=3D0 From nobody Thu Oct 31 07:52: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 E3469120809; Thu, 31 Oct 2019 07:52:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 8p6jIPzaLKPF; Thu, 31 Oct 2019 07:52:16 -0700 (PDT) Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-bl2nam06on0704.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe55::704]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8D5F1207FE; Thu, 31 Oct 2019 07:52:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jfiMyB13oSQEKmHunbTseLkJL8NJ1FkGDVBiqhk+DM8zZqfvinAlvAnruGjC/xHb70GNfPMFqfs8LtXEaeXU16ZiT4B1/rvA37LVsv7WFuEUEfCcc6DP+eDPEBUTLUj8Sf2WMSNehYIIsCMjqqSE53PG30j/QFHRdIYQWrYUM+vrJ3CFvxYDbl0xBe/j0AS4qjE3/pqEt50EwKrPFBafAAKt6WvkJONNEtVVBBrL47gJ73ypjnMSAbfwanxSWLNoVO8JL1izjwybKdqx8lJNrWQT7Ls6xXjpZFHD9lHHaWMG+pIPCAKiguFyNxeBrrTHR7VaIL56nFHEvawZ9j9cZw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=2+ODgplPrMjQB3Pq50QkBXxbyg+KAFvM/CE9cwjSCAE=; b=QQ77wRqbyHHZqYhYIocJKgcnYH7zPA6G7zILDuF8RdnFEEXMrzn9B/wa/+ceH/yEDOgklFnsC1iY67QXCRXW2potbK68tkHDZla5Dh3Q+4oL1ChDSrl057xAJ/svv3/MRaOZZFKk4daCOle7Q9y/N4QmtwrIaiD3KgLsso1yzQKgCyYyh6eUkIbd/qHSI96QoSfHHIrEaswLpPWK+E/pK2JOlJ3soeAfIUCGTa2cCd0evHlTZ9pGIbDAfXCHhD1xqHUJklPzxY142zRupz9KCkCdgR+jnpoy6Cfs7WmfcKZGGJoGFU28Wqyc7iuKhni8Mn36fcXeRo8PvCx1AfFuxw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=2+ODgplPrMjQB3Pq50QkBXxbyg+KAFvM/CE9cwjSCAE=; b=cy0Hhcl7ciGzkvCgbezzB53DcPoLSt6R5G/lXrkx80YH9GwCiIjGuCbRz90vVFQs6YcvaVFmN5d1Or9oun4dyBxjqiKFofdy9QkANU1gBSU7juLS4GH5joQofzDZ6htl0uKxJRLLabPP2WPtdok4XLEJN17770Ad8QFtHHmhlpo= Received: from DM6PR00MB0569.namprd00.prod.outlook.com (20.179.51.12) by DM6PR00MB0570.namprd00.prod.outlook.com (20.179.51.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2450.0; Thu, 31 Oct 2019 14:52:11 +0000 Received: from DM6PR00MB0569.namprd00.prod.outlook.com ([fe80::49:30:b130:e9b3]) by DM6PR00MB0569.namprd00.prod.outlook.com ([fe80::49:30:b130:e9b3%7]) with mapi id 15.20.2450.000; Thu, 31 Oct 2019 14:52:11 +0000 From: Mike Jones To: "ace@ietf.org" , "i-d-announce@ietf.org" CC: =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= , Benjamin Kaduk Thread-Topic: [Ace] I-D Action: draft-ietf-ace-cwt-proof-of-possession-11.txt Thread-Index: AQHVj/mZz4Ishz7OLEqk1Rhswf20vKd01PnQ Date: Thu, 31 Oct 2019 14:52:11 +0000 Message-ID: References: <157253301472.30380.9313695597907874615@ietfa.amsl.com> In-Reply-To: <157253301472.30380.9313695597907874615@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=24157e70-b9af-4ee5-8deb-00006262cfbd; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2019-10-31T14:49:57Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [50.47.93.218] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 54684e0f-1439-4093-9cbc-08d75e11e95e x-ms-traffictypediagnostic: DM6PR00MB0570: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6108; x-forefront-prvs: 02070414A1 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(136003)(396003)(346002)(39860400002)(376002)(189003)(199004)(13464003)(2501003)(74316002)(305945005)(86362001)(256004)(10090500001)(33656002)(52536014)(446003)(7696005)(9686003)(55016002)(478600001)(5660300002)(966005)(10290500003)(25786009)(8990500004)(14454004)(6306002)(4001150100001)(66574012)(7736002)(71200400001)(71190400001)(3846002)(6116002)(76116006)(186003)(8676002)(64756008)(66556008)(81156014)(6246003)(6436002)(4326008)(76176011)(81166006)(66476007)(229853002)(66946007)(66446008)(110136005)(99286004)(26005)(316002)(11346002)(486006)(54906003)(6506007)(53546011)(2906002)(66066001)(22452003)(8936002)(102836004)(476003); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR00MB0570; H:DM6PR00MB0569.namprd00.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: OmIHUZKGuEnTs7IlLj0rw8l1rm6aCsSZ+BdYOsNw3P2E+M7NvdQStbJfc3tY2I3qjEDorNW0Rp2NUfDr0PzJ8zIfwKqjElfJ9vTYoHOiYLaaGYBdhUiMF7suVk7rF+KbT/iDK4lm7tkOFwW9X2HG7I3h5enhNT3gV7sA2nFOzPUotqVL6m5zxYDWSBtA/IBZkUnLPDl3nckAqG3Jery3J/WR2tZdpgZm+aXAiq0YyR8hOvUv99rYytF00/gib3vn6Oelopauk2HiRgN1ONrhWc/y6PPocgX637utUuFzBBxLMBGNzX9fmozi7Ah+8quH3fp7VKVlWggcfGtb4j59rS6xzRL082Vd81bORcN8NCnRcs1Joq7Yq90XaUaGUog0XZ/Nc4M+UiSsSKi1zo/shGT2/u3PrpBeR+xUTce53RwyCUR5vojbcQrlLv8JVNKd x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 54684e0f-1439-4093-9cbc-08d75e11e95e X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Oct 2019 14:52:11.7861 (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-CrossTenant-userprincipalname: RKHJkQVRIgIZWmVHq38vNqZ1j5c1jZ44lbXZEMu7ycYsnjgaZExjAvQEuyijIHifUTXh178pl3gvJUGT+TdyLg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR00MB0570 Archived-At: Subject: Re: [Ace] I-D Action: draft-ietf-ace-cwt-proof-of-possession-11.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 Oct 2019 14:52:19 -0000 VGhpcyB2ZXJzaW9uIGFkZHJlc3NlcyB0aGUgcmVtYWluaW5nIElFU0cgcmV2aWV3IGNvbW1lbnQg YnkgTWlyamEgS8O8aGxld2luZCwgd2hpY2ggcmVtb3ZlcyB0aGUgbGFuZ3VhZ2UgYWJvdXQgY29u dGFjdGluZyB0aGUgSUVTRyBzaG91bGQgdGhlIERlc2lnbmF0ZWQgRXhwZXJ0cyBub3QgYWN0IG9u IElBTkEgcmVnaXN0cmF0aW9ucyBpbiBhIHRpbWVseSB3YXksIHBlciBhIGRlY2lzaW9uIGJ5IHRo ZSBJRVNHIG9uIHRvZGF5J3MgdGVsZWNoYXQuDQoNCgkJCQktLSBNaWtlDQoNCi0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBBY2UgPGFjZS1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhh bGYgT2YgaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnDQpTZW50OiBUaHVyc2RheSwgT2N0b2JlciAz MSwgMjAxOSA3OjQ0IEFNDQpUbzogaS1kLWFubm91bmNlQGlldGYub3JnDQpDYzogYWNlQGlldGYu b3JnDQpTdWJqZWN0OiBbQWNlXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWFjZS1jd3QtcHJvb2Yt b2YtcG9zc2Vzc2lvbi0xMS50eHQNCg0KDQpBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFi bGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMuDQpUaGlzIGRy YWZ0IGlzIGEgd29yayBpdGVtIG9mIHRoZSBBdXRoZW50aWNhdGlvbiBhbmQgQXV0aG9yaXphdGlv biBmb3IgQ29uc3RyYWluZWQgRW52aXJvbm1lbnRzIFdHIG9mIHRoZSBJRVRGLg0KDQogICAgICAg IFRpdGxlICAgICAgICAgICA6IFByb29mLW9mLVBvc3Nlc3Npb24gS2V5IFNlbWFudGljcyBmb3Ig Q0JPUiBXZWIgVG9rZW5zIChDV1RzKQ0KICAgICAgICBBdXRob3JzICAgICAgICAgOiBNaWNoYWVs IEIuIEpvbmVzDQogICAgICAgICAgICAgICAgICAgICAgICAgIEx1ZHdpZyBTZWl0eg0KICAgICAg ICAgICAgICAgICAgICAgICAgICBHw7ZyYW4gU2VsYW5kZXINCiAgICAgICAgICAgICAgICAgICAg ICAgICAgU2FtdWVsIEVyZHRtYW4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgSGFubmVzIFRz Y2hvZmVuaWcNCglGaWxlbmFtZSAgICAgICAgOiBkcmFmdC1pZXRmLWFjZS1jd3QtcHJvb2Ytb2Yt cG9zc2Vzc2lvbi0xMS50eHQNCglQYWdlcyAgICAgICAgICAgOiAxNg0KCURhdGUgICAgICAgICAg ICA6IDIwMTktMTAtMzENCg0KQWJzdHJhY3Q6DQogICBUaGlzIHNwZWNpZmljYXRpb24gZGVzY3Jp YmVzIGhvdyB0byBkZWNsYXJlIGluIGEgQ0JPUiBXZWIgVG9rZW4gKENXVCkNCiAgICh3aGljaCBp cyBkZWZpbmVkIGJ5IFJGQyA4MzkyKSB0aGF0IHRoZSBwcmVzZW50ZXIgb2YgdGhlIENXVA0KICAg cG9zc2Vzc2VzIGEgcGFydGljdWxhciBwcm9vZi1vZi1wb3NzZXNzaW9uIGtleS4gIEJlaW5nIGFi bGUgdG8gcHJvdmUNCiAgIHBvc3Nlc3Npb24gb2YgYSBrZXkgaXMgYWxzbyBzb21ldGltZXMgZGVz Y3JpYmVkIGFzIGJlaW5nIHRoZSBob2xkZXItDQogICBvZi1rZXkuICBUaGlzIHNwZWNpZmljYXRp b24gcHJvdmlkZXMgZXF1aXZhbGVudCBmdW5jdGlvbmFsaXR5IHRvDQogICAiUHJvb2Ytb2YtUG9z c2Vzc2lvbiBLZXkgU2VtYW50aWNzIGZvciBKU09OIFdlYiBUb2tlbnMgKEpXVHMpIiAoUkZDDQog ICA3ODAwKSBidXQgdXNpbmcgQ29uY2lzZSBCaW5hcnkgT2JqZWN0IFJlcHJlc2VudGF0aW9uIChD Qk9SKSBhbmQgQ1dUcw0KICAgcmF0aGVyIHRoYW4gSmF2YVNjcmlwdCBPYmplY3QgTm90YXRpb24g KEpTT04pIGFuZCBKU09OIFdlYiBUb2tlbnMNCiAgIChKV1RzKS4NCg0KDQpUaGUgSUVURiBkYXRh dHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBpczoNCmh0dHBzOi8vbmFtMDYuc2Fm ZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRmRhdGF0cmFj a2VyLmlldGYub3JnJTJGZG9jJTJGZHJhZnQtaWV0Zi1hY2UtY3d0LXByb29mLW9mLXBvc3Nlc3Np b24lMkYmYW1wO2RhdGE9MDIlN0MwMSU3Q01pY2hhZWwuSm9uZXMlNDBtaWNyb3NvZnQuY29tJTdD NmZlNTY2NDQ5YzFiNDgwNWNlZTcwOGQ3NWUxMGJhMGIlN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJk N2NkMDExZGI0NyU3QzElN0MwJTdDNjM3MDgxMjk4MjQ4Mzg2OTI5JmFtcDtzZGF0YT1jRWxNdXVP TmZRaVlzUnFNakpzNHdNSFV0c3ZhbnB5NiUyRjFoV0d2WTdGTjAlM0QmYW1wO3Jlc2VydmVkPTAN Cg0KVGhlcmUgYXJlIGFsc28gaHRtbGl6ZWQgdmVyc2lvbnMgYXZhaWxhYmxlIGF0Og0KaHR0cHM6 Ly9uYW0wNi5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJG JTJGdG9vbHMuaWV0Zi5vcmclMkZodG1sJTJGZHJhZnQtaWV0Zi1hY2UtY3d0LXByb29mLW9mLXBv c3Nlc3Npb24tMTEmYW1wO2RhdGE9MDIlN0MwMSU3Q01pY2hhZWwuSm9uZXMlNDBtaWNyb3NvZnQu Y29tJTdDNmZlNTY2NDQ5YzFiNDgwNWNlZTcwOGQ3NWUxMGJhMGIlN0M3MmY5ODhiZjg2ZjE0MWFm OTFhYjJkN2NkMDExZGI0NyU3QzElN0MwJTdDNjM3MDgxMjk4MjQ4Mzg2OTI5JmFtcDtzZGF0YT04 MjUzbyUyQkRaVERWZjRIZXVvWXUlMkJicEhSOTFDUXJzd25WJTJGc0NmR1E5NUVzJTNEJmFtcDty ZXNlcnZlZD0wDQpodHRwczovL25hbTA2LnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29t Lz91cmw9aHR0cHMlM0ElMkYlMkZkYXRhdHJhY2tlci5pZXRmLm9yZyUyRmRvYyUyRmh0bWwlMkZk cmFmdC1pZXRmLWFjZS1jd3QtcHJvb2Ytb2YtcG9zc2Vzc2lvbi0xMSZhbXA7ZGF0YT0wMiU3QzAx JTdDTWljaGFlbC5Kb25lcyU0MG1pY3Jvc29mdC5jb20lN0M2ZmU1NjY0NDljMWI0ODA1Y2VlNzA4 ZDc1ZTEwYmEwYiU3QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3QzAlN0M2 MzcwODEyOTgyNDgzODY5MjkmYW1wO3NkYXRhPWNKJTJCN3FBaFU3OFZyMXNYcmNUelFOU0VvalRv OFZiWlMlMkZpbXVOeVgyQ0NzJTNEJmFtcDtyZXNlcnZlZD0wDQoNCkEgZGlmZiBmcm9tIHRoZSBw cmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDoNCmh0dHBzOi8vbmFtMDYuc2FmZWxpbmtz LnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRnd3dy5pZXRmLm9yZyUy RnJmY2RpZmYlM0Z1cmwyJTNEZHJhZnQtaWV0Zi1hY2UtY3d0LXByb29mLW9mLXBvc3Nlc3Npb24t MTEmYW1wO2RhdGE9MDIlN0MwMSU3Q01pY2hhZWwuSm9uZXMlNDBtaWNyb3NvZnQuY29tJTdDNmZl NTY2NDQ5YzFiNDgwNWNlZTcwOGQ3NWUxMGJhMGIlN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2Nk MDExZGI0NyU3QzElN0MwJTdDNjM3MDgxMjk4MjQ4Mzg2OTI5JmFtcDtzZGF0YT1NJTJCa1M5Yngl MkJJZ3N3WUlEd2lMbzMxZWxXY2FrRktHOVduaTJWcktWeVZVQSUzRCZhbXA7cmVzZXJ2ZWQ9MA0K DQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9t IHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRp ZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCg0KSW50ZXJuZXQtRHJhZnRzIGFy ZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0KZnRwOi8vZnRwLmlldGYub3Jn L2ludGVybmV0LWRyYWZ0cy8NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCkFjZSBtYWlsaW5nIGxpc3QNCkFjZUBpZXRmLm9yZw0KaHR0cHM6Ly9uYW0w Ni5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGd3d3 LmlldGYub3JnJTJGbWFpbG1hbiUyRmxpc3RpbmZvJTJGYWNlJmFtcDtkYXRhPTAyJTdDMDElN0NN aWNoYWVsLkpvbmVzJTQwbWljcm9zb2Z0LmNvbSU3QzZmZTU2NjQ0OWMxYjQ4MDVjZWU3MDhkNzVl MTBiYTBiJTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN0MxJTdDMCU3QzYzNzA4 MTI5ODI0ODM4NjkyOSZhbXA7c2RhdGE9Y1ZLNFJPYnVONzdhcmYwU3l2QzZ0aHJEZHByamdSZUhp clNGeDJwd01zbyUzRCZhbXA7cmVzZXJ2ZWQ9MA0K From nobody Thu Oct 31 11:26:59 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 003301209CD for ; Thu, 31 Oct 2019 11:26:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IUFkJcL_VWgG for ; Thu, 31 Oct 2019 11:26:53 -0700 (PDT) Received: from NAM04-CO1-obe.outbound.protection.outlook.com (mail-eopbgr690065.outbound.protection.outlook.com [40.107.69.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 A27291209B0 for ; Thu, 31 Oct 2019 11:26:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=DsGr8+sh4ZANvlfRRKmibMJLSCecqH4G2aUQ1fMc11O7ilxYsikotdarOLS1caSnUXKunWKNIjnExVbiI9eFvKUiBZfU/IChVYTJ/H1hTEwhXqdMRHArKhkbrRGsHuKTi5Vba5vcV2lTcGW6iNSmJDQoUDj2bzN7vKA7NAufkVUuHtXUvVq9xvEmjdNDaZ8GSJaAhvXtz9d8WSOcQI+sByV21YNlCiF1hCGFlfB7LKEiPYJrrR+TROnu6USPkcpATUTyxIMCgSoMMmm9fvjkU5mgucr0UD55Vnz+EwJt6Iq1tdFqYBmo8aDBM7qu5E6pi/TTpYP+H07Ae2ub2/dDnA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=IQ+Kld2Q9tj68pk2mCTQDKTbKrTUXgevpUuhmXdpgUQ=; b=n9wGTDP5OWunHbZmTyTSq8ShfczAA/jtNwDq3bjdgKMj8WbnfaAvde7yUeQOr9LNEJ0Q9MM08JAYriNfmrnSHlPFN18IRyoi3rLpdIkmh5FvNnX00GQSJTc3cG6z9Ps94ykoTZESSGpmn0D1VEloFkDqb7uiGSZi0+TPv9eqgZ0212sbRQXgdf331c/dRjG75AQaUgdv5PClalRG4BwK9ekn+E29httP4mtUBSqRkeQb6igJ1RUXVTQH4iaBp9WgV8vRLSFKwL+T3/bUyWnR45uDz67iXtC6x8h0nJpXluREhhyFlZN5/PpUo+eFlwyQ6DnJFBR/OYJO8Iw9DJZ+sg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=IQ+Kld2Q9tj68pk2mCTQDKTbKrTUXgevpUuhmXdpgUQ=; b=KyfMiVpky+VYSrz+w0Ore83Cl3TQmxycbQsUKlhsqnF2fcOT4a7QXXMawvPTT9HDkmhaoQxavJDraHl0ezDsBBNaaINKB1nWcZgE0TbETEGwKRlphBvo77KcqoOQNL0rv4dhE0c0ON4viBhL+RzeJUVAx2HPqUI7Rt2BjszkcO0= Received: from DM6PR15MB3531.namprd15.prod.outlook.com (10.141.164.29) by DM6PR15MB3611.namprd15.prod.outlook.com (10.141.165.97) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2408.17; Thu, 31 Oct 2019 18:26:50 +0000 Received: from DM6PR15MB3531.namprd15.prod.outlook.com ([fe80::8d51:92d5:45a8:173b]) by DM6PR15MB3531.namprd15.prod.outlook.com ([fe80::8d51:92d5:45a8:173b%4]) with mapi id 15.20.2408.016; Thu, 31 Oct 2019 18:26:50 +0000 From: Daniel Migault To: Ace Wg Thread-Topic: ACE@IETF106 - agenda items and presentations Thread-Index: AdWQGMJ3Gb/LqHncSJGCsrwsE1w84Q== Date: Thu, 31 Oct 2019 18:26:50 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=daniel.migault@ericsson.com; x-originating-ip: [192.75.88.130] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: cf16f240-5aed-4cab-e0b9-08d75e2fe5d1 x-ms-traffictypediagnostic: DM6PR15MB3611: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 02070414A1 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(346002)(396003)(136003)(376002)(366004)(39860400002)(189003)(199004)(99286004)(26005)(5660300002)(790700001)(486006)(4744005)(8936002)(52536014)(476003)(3846002)(6436002)(86362001)(44832011)(25786009)(6116002)(6506007)(102836004)(7696005)(71190400001)(71200400001)(2906002)(186003)(66556008)(64756008)(66476007)(256004)(14444005)(66946007)(33656002)(316002)(74316002)(966005)(14454004)(6306002)(66446008)(9686003)(55016002)(66066001)(7736002)(478600001)(54896002)(76116006)(9326002)(81156014)(8676002)(6916009)(81166006); DIR:OUT; SFP:1101; SCL:1; SRVR:DM6PR15MB3611; H:DM6PR15MB3531.namprd15.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: BCL:0; x-microsoft-antispam-message-info: z/2yWCwqERFtbQwnh0iYIicCGRYdlvFGPIW/zUV5pDBkzx0oVnrpIOs11EHuiyMAaNuRi0/tTdNa800ler2GXug7gUwpCHvSwqUqIpwzzMtW3DadNEBagSnEp8SqDnJ6k77M+uQqL7XinPQm5E5Gj+HAES/6qPPdBdjQBb8KFDK6eLdwee4nk+FDFQ0mN4mAIuVidPHtA0BANgENYP9s1o6HjL/Wyl6AglMM7ON733qQ7zLsESv8gy0Mbim9ClyftqlQwkthmm7gyKmYjwcoY9YpkuSPwSQRVG1epzJ/FKMGADBxaNaI1qQSMRHrlLJeg8ipDZ9sFqNub4lkCcBcs5b1GdxXCu1sBnw0C5QhcriKhOc3xpskdqXDiDKasBKtkcSMTYOWOEnJmi3/urMNo9NaeeMj7KaBcAcEaHGrAYnNwjvJ71Y2fFt3pQ4RNl84 x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DM6PR15MB353184666241AECC2239490EE3630DM6PR15MB3531namp_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: cf16f240-5aed-4cab-e0b9-08d75e2fe5d1 X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Oct 2019 18:26:50.7306 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: qz4PSDvme4+KpBAKc1KUiE9W+VUiU0qS3ccN9BxdRVZer92bNbUm+bzdakedmzWLGS7jYqPiwPLkQ2c68QIwoB4LdhOAd8b0hGurcbRQK0E= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR15MB3611 Archived-At: Subject: [Ace] ACE@IETF106 - agenda items and presentations 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 Oct 2019 18:26:57 -0000 --_000_DM6PR15MB353184666241AECC2239490EE3630DM6PR15MB3531namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, The ACE WG is meeting at the IETF 106 Tuesday November 19 15:20-16:50 . Ple= ase let us know if there are topic you would like to present by Wednesday N= ovember 6. Slides are expected to be uploaded by Sunday November 17. Please remember the draft deadline is Monday November 4 https://datatracker.ietf.org/meeting/106/important-dates/ Yours, Jim and Daniel --_000_DM6PR15MB353184666241AECC2239490EE3630DM6PR15MB3531namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

The ACE WG is meeting at the IETF 106 Tuesday Novemb= er 19 15:20-16:50 . Please let us know if there are topic you would like to= present by Wednesday November 6. Slides are expected to be uploaded by &nb= sp;Sunday November 17.

 

Please remember the draft deadline is Monday Novembe= r 4

https://datatracker.ietf.org/meeting/106/important-d= ates/

 

Yours,

Jim and Daniel

 

--_000_DM6PR15MB353184666241AECC2239490EE3630DM6PR15MB3531namp_--