From nobody Wed May 2 06:15:51 2018 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45704127077 for ; Wed, 2 May 2018 06:15:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BuyVNf9oiW6Q for ; Wed, 2 May 2018 06:15:42 -0700 (PDT) Received: from smtp-out10.electric.net (smtp-out10.electric.net [185.38.180.39]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEB45126FDC for ; Wed, 2 May 2018 06:15:41 -0700 (PDT) Received: from 1fDrbf-0002Zb-V9 by out10a.electric.net with emc1-ok (Exim 4.90_1) (envelope-from ) id 1fDrbf-0002aR-Vd for ace@ietf.org; Wed, 02 May 2018 06:15:39 -0700 Received: by emcmailer; Wed, 02 May 2018 06:15:39 -0700 Received: from [194.218.146.197] (helo=sp-mail-2.sp.se) by out10a.electric.net with esmtps (TLSv1.2:ECDHE-RSA-AES128-SHA256:128) (Exim 4.90_1) (envelope-from ) id 1fDrbf-0002Zb-V9 for ace@ietf.org; Wed, 02 May 2018 06:15:39 -0700 Received: from [192.168.0.166] (10.116.0.226) by sp-mail-2.sp.se (10.100.0.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1261.35; Wed, 2 May 2018 15:15:39 +0200 To: "ace@ietf.org" From: Ludwig Seitz Message-ID: Date: Wed, 2 May 2018 15:15:39 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.116.0.226] X-ClientProxiedBy: sp-mail-1.sp.se (10.100.0.161) To sp-mail-2.sp.se (10.100.0.162) X-Outbound-IP: 194.218.146.197 X-Env-From: ludwig.seitz@ri.se X-Proto: esmtps X-Revdns: X-HELO: sp-mail-2.sp.se X-TLS: TLSv1.2:ECDHE-RSA-AES128-SHA256:128 X-Authenticated_ID: X-PolicySMART: 14510320 X-Virus-Status: Scanned by VirusSMART (c) X-Virus-Status: Scanned by VirusSMART (s) Archived-At: Subject: [Ace] Virtual interop of draft-ietf-oauth-authz and profiles X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2018 13:15:49 -0000 Hello group, I would like to suggest that we hold a virtual interop test of implementations of draft-ietf-oauth-authz. I have two questions for you: 1.) Do you have an implementation that you would like to test in such an event? (I know of the following: ARM, TZI, Jim Schaad, RISE SICS, CMU/SEI) 2.) If you have an implementation which date range would suit you? (I'm thinking early June) I will start specifying a test setup description that I will share with the WG, please feel free to contribute (I plan to use the group's github repo for that: https://github.com/ace-wg). /Ludwig -- Ludwig Seitz, PhD Security Lab, RISE SICS Phone +46(0)70-349 92 51 From nobody Mon May 7 09:37:36 2018 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1DF61270A0 for ; Mon, 7 May 2018 09:37:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] 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 QtptY6Fcu4lw for ; Mon, 7 May 2018 09:37:33 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0132.outbound.protection.outlook.com [104.47.36.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC9B3120726 for ; Mon, 7 May 2018 09:37:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=pAILN/Qr3uOjfENQELCC3leGuyyDsVW/PJ4TzDhFOXQ=; b=ApiC6R+Jl80N2wefrcGCH+YgLwM72Nc/mkxaogCqS6FVekSXKIW3kzWLLjFrzGdC1KPe6YXWqgaOt5H2ICPbNsxNxY30AybQgaTxhKDlXJINITQY1q/6/sa5TUpPKoyfJLqL5XrIzazNuECUnYKfDU6kcFIZx2LKtji1z7S5ObY= Received: from BL0PR00MB0292.namprd00.prod.outlook.com (2603:10b6:207:1e::30) by BL0PR00MB0291.namprd00.prod.outlook.com (2603:10b6:207:1e::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.789.0; Mon, 7 May 2018 16:37:24 +0000 Received: from BL0PR00MB0292.namprd00.prod.outlook.com ([fe80::84a0:cb3c:39ec:1b01]) by BL0PR00MB0292.namprd00.prod.outlook.com ([fe80::84a0:cb3c:39ec:1b01%5]) with mapi id 15.20.0788.000; Mon, 7 May 2018 16:37:24 +0000 From: Mike Jones To: Jim Schaad , Roman Danyliw CC: Ludwig Seitz , "goran.selander@ericsson.com" , "erik@wahlstromstekniska.se" , Samuel Erdtman , Hannes Tschofenig , Benjamin Kaduk , "ace@ietf.org" Thread-Topic: WGLC for draft-ietf-ace-cwt-proof-of-possession? Thread-Index: AdPiXgA1LeUMmV1IS8++EEL31dH27QDwySFg Date: Mon, 7 May 2018 16:37:24 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.47.80.188] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BL0PR00MB0291; 7:7kmgNsJHJSq+MTJfjxW/MBUBpX7CDmLfJWzvgrXm2ZfukVtWBHJj8TOhERnPce7O//sZSsXQy/PUL/vbGdx+P4YYCi3T8i9Jh8AhmOaXNWf8fg91cNxJpbcMFrcprRJYUBqEWf5KhSEcbsHB8ApjxlxY7wHQ1fXLIJIG15FK2I9nIUMXjo7XyYxKN3KQPnG7xJdJQaWkAZHNpebiUG94ZtSokKXjKGmD01Q/vRUzZawszMOO6wt+wPCwQMRIm7nU; 20:pvZTzHaKv2NTmqBZsbHkMGLSiGHqX98n+6gDO0yFeNvKce8xNsogMDf7EqwORhbv/ElU0FAzeajIlNuap1H8BnyU+HTCCdhT1BW4E6KtqM9TYq80lERJzGJHGaAgZAV28Hd9C2UUCBhcAQc0LX/MCMPpFwryfwvHlhV9qx43Tmc= x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(48565401081)(2017052603328)(7193020); SRVR:BL0PR00MB0291; x-ms-traffictypediagnostic: BL0PR00MB0291: x-ld-processed: 72f988bf-86f1-41af-91ab-2d7cd011db47,ExtAddr x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(28532068793085)(180628864354917)(120809045254105)(21748063052155)(240460790083961); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(2017102700009)(2017102701064)(6040522)(2401047)(8121501046)(5005006)(2017102702064)(20171027021009)(20171027022009)(20171027023009)(20171027024009)(20171027025009)(20171027026009)(2017102703076)(93006095)(93001095)(3002001)(3231254)(2018427008)(944501410)(52105095)(10201501046)(6055026)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123562045)(20161123564045)(20161123560045)(6072148)(201708071742011); SRVR:BL0PR00MB0291; BCL:0; PCL:0; RULEID:; SRVR:BL0PR00MB0291; x-forefront-prvs: 066517B35B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(396003)(39860400002)(39380400002)(376002)(366004)(199004)(189003)(106356001)(10090500001)(229853002)(68736007)(76176011)(5250100002)(6306002)(86362001)(8990500004)(186003)(606006)(105586002)(74316002)(66066001)(6436002)(14454004)(102836004)(6346003)(3846002)(97736004)(790700001)(22452003)(6116002)(6506007)(55016002)(25786009)(53546011)(3280700002)(52396003)(9686003)(10290500003)(7696005)(4326008)(86612001)(3660700001)(316002)(54896002)(5660300001)(478600001)(236005)(966005)(8676002)(8936002)(33656002)(2900100001)(110136005)(54906003)(11346002)(2906002)(486006)(72206003)(413944005)(476003)(99286004)(26005)(6246003)(81156014)(81166006)(446003)(7736002)(53936002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL0PR00MB0291; H:BL0PR00MB0292.namprd00.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-microsoft-antispam-message-info: LTW5ChTC8RGkeK5H5tPpP9tyrtMDkT69+j+CgOyET/TkAI0ehqVoxLvnT/60W36INmyELHauk3gIoBejw1ryjjbzCH0XyD0NsgSPODVia53KhfE5NJ3aifwjEJwhCf8OP02N7bG+SCNEgSHyIQ9f1FEchDtIPaltsZiiG3eX0QiJQuYfL4KquqmUnqnt7gQN spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BL0PR00MB0292D77AFB4325CF781FE60BF59B0BL0PR00MB0292namp_" MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 5d757f60-3b83-4d86-8c4a-08d5b438d009 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 5d757f60-3b83-4d86-8c4a-08d5b438d009 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 May 2018 16:37:24.1946 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR00MB0291 Archived-At: Subject: Re: [Ace] WGLC for draft-ietf-ace-cwt-proof-of-possession? X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2018 16:37:36 -0000 --_000_BL0PR00MB0292D77AFB4325CF781FE60BF59B0BL0PR00MB0292namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear ACE chairs, I never heard back on this. Given that CWT is in AUTH48 as RFC-to-be 8392,= I believe it's time to start WGLC on draft-ietf-ace-cwt-proof-of-possessio= n. Thanks, -- Mike From: Mike Jones Sent: Wednesday, May 2, 2018 2:45 PM To: Jim Schaad ; Roman Danyliw Cc: Ludwig Seitz ; goran.selander@ericsson.com; erik@wahlst= romstekniska.se; Samuel Erdtman ; Hannes Tschofenig ; Benjamin Kaduk Subject: WGLC for draft-ietf-ace-cwt-proof-of-possession? The ACE minutes from London https://datatracker.ietf.org/meeting/101/materi= als/minutes-101-ace-00 record that the editors thought that draft-ietf-ace-= cwt-proof-of-possession was ready for working group last call. I haven't s= een any further discussion of the draft on the mailing list since then, mak= ing me think that the working group agrees with this conclusion. Especiall= y given that draft-ietf-ace-cbor-web-token is in the RFC Editor Queue (in t= he Edit state), it seems like it's probably time to move CWT PoP along as w= ell. Do the chairs agree, and if so what are the next steps? (For that matter, = if the chairs don't agree, what are the next steps? ;-) ) Thanks all, -- Mike --_000_BL0PR00MB0292D77AFB4325CF781FE60BF59B0BL0PR00MB0292namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear ACE chairs,<= /o:p>

 

I never heard back on = this.  Given that CWT is in AUTH48 as RFC-to-be 8392, I believe itR= 17;s time to start WGLC on draft-ietf-ace-cwt-proof-of-possession.

 

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

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

 

From: Mike Jones
Sent: Wednesday, May 2, 2018 2:45 PM
To: Jim Schaad <ietf@augustcellars.com>; Roman Danyliw <rdd= @cert.org>
Cc: Ludwig Seitz <ludwig@sics.se>; goran.selander@ericsson.com= ; erik@wahlstromstekniska.se; Samuel Erdtman <samuel@erdtman.se>; Han= nes Tschofenig <Hannes.Tschofenig@arm.com>; Benjamin Kaduk <kaduk@= mit.edu>
Subject: WGLC for draft-ietf-ace-cwt-proof-of-possession?=

 

The ACE minutes from London https://datatracker.ietf.org/meeting/101/materials/minutes-101-ace-00 r= ecord that the editors thought that draft-ietf-ace-cwt-proof-of-possession = was ready for working group last call.  I haven’t seen any furth= er discussion of the draft on the mailing list since then, making me think that the working group agrees with this conclu= sion.  Especially given that draft-ietf-ace-cbor-web-token is in the R= FC Editor Queue (in the Edit state), it seems like it’s probably time= to move CWT PoP along as well.

 

Do the chairs agree, and if so what are the next ste= ps?  (For that matter, if the chairs don’t agree, what are the n= ext steps? ;-) )

 

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

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

--_000_BL0PR00MB0292D77AFB4325CF781FE60BF59B0BL0PR00MB0292namp_-- From nobody Mon May 7 09:44:45 2018 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DD281270A0 for ; Mon, 7 May 2018 09:44:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.799 X-Spam-Level: X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8vec0HztEKVv for ; Mon, 7 May 2018 09:44:41 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35D9D120726 for ; Mon, 7 May 2018 09:44:41 -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.1347.2; Mon, 7 May 2018 09:42:02 -0700 From: Jim Schaad To: Date: Mon, 7 May 2018 09:44:34 -0700 Message-ID: <005601d3e622$af427100$0dc75300$@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: AdPmIm8GwlgNR4Z4TAKB3oF5AiJBnQ== Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: [Ace] OAuth-Authz Interop X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2018 16:44:43 -0000 I have been meaning to get this out for a while and have failed. A doodle poll to setup an interop event for this work is at https://doodle.com/poll/k27g9r26bghvnytu If you want to participate and none of the times are good please let me know. Things for testing: 1) DTLS profile w/ shared secret 2) DTLS profile w/ RPK 3) OSCORE profile From nobody Mon May 7 23:57:19 2018 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 891C412704A for ; Mon, 7 May 2018 23:57:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bmfmfq_z0rJg for ; Mon, 7 May 2018 23:57:16 -0700 (PDT) Received: from smtp-out11.electric.net (smtp-out11.electric.net [185.38.181.39]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99E8E126CC7 for ; Mon, 7 May 2018 23:57:15 -0700 (PDT) Received: from 1fFwYj-0003I5-Ud by out11d.electric.net with emc1-ok (Exim 4.90_1) (envelope-from ) id 1fFwYj-0003JA-VT for ace@ietf.org; Mon, 07 May 2018 23:57:13 -0700 Received: by emcmailer; Mon, 07 May 2018 23:57:13 -0700 Received: from [194.218.146.197] (helo=sp-mail-2.sp.se) by out11d.electric.net with esmtps (TLSv1.2:ECDHE-RSA-AES128-SHA256:128) (Exim 4.90_1) (envelope-from ) id 1fFwYj-0003I5-Ud for ace@ietf.org; Mon, 07 May 2018 23:57:13 -0700 Received: from [192.168.0.166] (10.116.0.226) by sp-mail-2.sp.se (10.100.0.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1261.35; Tue, 8 May 2018 08:57:13 +0200 To: References: <005601d3e622$af427100$0dc75300$@augustcellars.com> From: Ludwig Seitz Message-ID: Date: Tue, 8 May 2018 08:57:12 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <005601d3e622$af427100$0dc75300$@augustcellars.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.116.0.226] X-ClientProxiedBy: sp-mail-2.sp.se (10.100.0.162) To sp-mail-2.sp.se (10.100.0.162) X-Outbound-IP: 194.218.146.197 X-Env-From: ludwig.seitz@ri.se X-Proto: esmtps X-Revdns: X-HELO: sp-mail-2.sp.se X-TLS: TLSv1.2:ECDHE-RSA-AES128-SHA256:128 X-Authenticated_ID: X-PolicySMART: 14510320 X-Virus-Status: Scanned by VirusSMART (c) X-Virus-Status: Scanned by VirusSMART (s) Archived-At: Subject: Re: [Ace] OAuth-Authz Interop X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2018 06:57:17 -0000 On 2018-05-07 18:44, Jim Schaad wrote: > I have been meaning to get this out for a while and have failed. A doodle > poll to setup an interop event for this work is at > https://doodle.com/poll/k27g9r26bghvnytu If you want to participate and none > of the times are good please let me know. > > Things for testing: > 1) DTLS profile w/ shared secret > 2) DTLS profile w/ RPK > 3) OSCORE profile > > Note that I'm in the process of writing a test manual, I'll put it up on the WG github as soon as it has some form and structure. Feel free to contribute. I'm hoping to have it online by the end of the day. /Ludwig -- Ludwig Seitz, PhD Security Lab, RISE SICS Phone +46(0)70-349 92 51 From nobody Tue May 8 03:54:02 2018 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5D8A12D88E for ; Tue, 8 May 2018 03:53:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xHUOm9eilkFq for ; Tue, 8 May 2018 03:53:56 -0700 (PDT) Received: from smtp-out10.electric.net (smtp-out10.electric.net [185.38.180.44]) (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 2FE1E12D944 for ; Tue, 8 May 2018 03:53:40 -0700 (PDT) Received: from 1fG0FW-0006qG-To by out10a.electric.net with emc1-ok (Exim 4.90_1) (envelope-from ) id 1fG0FW-0006rn-Ua for ace@ietf.org; Tue, 08 May 2018 03:53:38 -0700 Received: by emcmailer; Tue, 08 May 2018 03:53:38 -0700 Received: from [194.218.146.197] (helo=sp-mail-2.sp.se) by out10a.electric.net with esmtps (TLSv1.2:ECDHE-RSA-AES128-SHA256:128) (Exim 4.90_1) (envelope-from ) id 1fG0FW-0006qG-To for ace@ietf.org; Tue, 08 May 2018 03:53:38 -0700 Received: from [192.168.0.166] (10.116.0.226) by sp-mail-2.sp.se (10.100.0.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1261.35; Tue, 8 May 2018 12:53:38 +0200 To: References: <005601d3e622$af427100$0dc75300$@augustcellars.com> From: Ludwig Seitz Message-ID: <7af7e847-bc7a-82ff-2024-7321575450d8@ri.se> Date: Tue, 8 May 2018 12:53:37 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [10.116.0.226] X-ClientProxiedBy: sp-mail-3.sp.se (10.100.0.163) To sp-mail-2.sp.se (10.100.0.162) X-Outbound-IP: 194.218.146.197 X-Env-From: ludwig.seitz@ri.se X-Proto: esmtps X-Revdns: X-HELO: sp-mail-2.sp.se X-TLS: TLSv1.2:ECDHE-RSA-AES128-SHA256:128 X-Authenticated_ID: X-PolicySMART: 14510320 X-Virus-Status: Scanned by VirusSMART (c) X-Virus-Status: Scanned by VirusSMART (s) Archived-At: Subject: Re: [Ace] OAuth-Authz Interop X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2018 10:53:59 -0000 On 2018-05-08 08:57, Ludwig Seitz wrote: > On 2018-05-07 18:44, Jim Schaad wrote: >> I have been meaning to get this out for a while and have failed.  A >> doodle >> poll to setup an interop event for this work is at >> https://doodle.com/poll/k27g9r26bghvnytu If you want to participate >> and none >> of the times are good please let me know. >> >> Things for testing: >> 1)  DTLS profile w/ shared secret >> 2)  DTLS profile w/ RPK >> 3)  OSCORE profile >> >> > > Note that I'm in the process of writing a test manual, I'll put it up on > the WG github as soon as it has some form and structure. Feel free to > contribute. I'm hoping to have it online by the end of the day. > > /Ludwig > > You can find my first draft of the interop manual here: https://github.com/ace-wg/ace-oauth/blob/master/InteropTestPlan.txt Note that large parts are still work in progress, but the test plan for the token endpoint should give you a hint as to how I was thinking it could work. Feel free to propose changes and improvements. /Ludwig -- Ludwig Seitz, PhD Security Lab, RISE SICS Phone +46(0)70-349 92 51 From nobody Tue May 8 10:40:27 2018 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DC131270A3 for ; Tue, 8 May 2018 10:40:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, 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 jCgKRmQ9jteX for ; Tue, 8 May 2018 10:40:22 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0117.outbound.protection.outlook.com [104.47.32.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61DE21270AE for ; Tue, 8 May 2018 10:40:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=PJjLJQvbW7ast4G4H56IxuM5P4RtZx+Ou5UCKW7duYE=; b=efhBI5tpI/gjts+Y599pL96QE55jQVRNfAwgwhQVnzwBKR+t5WfP0kRFy0XheYM7/p2M72fKW+yRF+Jfdv9HKQhWNSIjwHiSFPl4yH7hMpNaTbpofD31YOzUCfZxizOo1TTvY+VtdmIMIzjZrTxAqdlkikwhrra+GzBSUDAE5B0= Received: from DM5PR00MB0296.namprd00.prod.outlook.com (2603:10b6:4:9e::37) by DM5PR00MB0374.namprd00.prod.outlook.com (2603:10b6:4:a0::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.790.0; Tue, 8 May 2018 17:40:19 +0000 Received: from DM5PR00MB0296.namprd00.prod.outlook.com ([fe80::3181:eda2:16cf:679d]) by DM5PR00MB0296.namprd00.prod.outlook.com ([fe80::3181:eda2:16cf:679d%4]) with mapi id 15.20.0791.000; Tue, 8 May 2018 17:40:19 +0000 From: Mike Jones To: Ludwig Seitz , "ace@ietf.org" Thread-Topic: [Ace] OAuth-Authz Interop Thread-Index: AdPmIm8GwlgNR4Z4TAKB3oF5AiJBnQAd1sgAAAhBu4AADchQsA== Date: Tue, 8 May 2018 17:40:19 +0000 Message-ID: References: <005601d3e622$af427100$0dc75300$@augustcellars.com> <7af7e847-bc7a-82ff-2024-7321575450d8@ri.se> In-Reply-To: <7af7e847-bc7a-82ff-2024-7321575450d8@ri.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=mbj@microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2018-05-08T17:40:18.0973812Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic; Sensitivity=General x-originating-ip: [2001:4898:80e8:8::291] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR00MB0374; 7:FyWnV+wcmU8qUmzQ74gUFjmaISKe8L/D2SyT7I21/tTyDlQWMa3oWrsNRh79UjEad3qLmPePo0Xj42QNp9mmIR0E0S65CJP7Ac47PbP42q1jeOK3lxJbd+og1InUQKrWih2SpqCVv5tGt0jHv6Dsp7P5lGpuHmxnXJIiW0ZAArah4pH1SMISmjxtypPgdOmuw/EEi0GgZfGlCkcvQmFV9DD8p3pVihe+OYG3CAK8i0b9kA9GcSeFhLvwtgjHzSzs; 20:weef15bnxUer43kUEyMdVHiv6CY67AxGKruoPxX/xydkkef8FMPflV2c1wKDX4iUSi0hSSO0q2yLKPZnZi+zUKHKPspkOMtb9kWlRD6nqlpg31WgZK4clUi0bJcrbhZcfWl7XjxB3HjzeXLYt7Iq7QZovflhD3b+gtHtSnuM9Zs= x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(48565401081)(2017052603328)(7193020); SRVR:DM5PR00MB0374; x-ms-traffictypediagnostic: DM5PR00MB0374: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(166708455590820)(209352067349851)(192374486261705)(60409825278598)(21748063052155); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(2017102700009)(2017102701064)(6040522)(2401047)(8121501046)(5005006)(2017102702064)(20171027021009)(20171027022009)(20171027023009)(20171027024009)(20171027025009)(20171027026009)(2017102703076)(3231254)(2018427008)(944501410)(52105095)(10201501046)(93006095)(93001095)(3002001)(6055026)(149027)(150027)(6041310)(20161123560045)(20161123562045)(20161123564045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:DM5PR00MB0374; BCL:0; PCL:0; RULEID:; SRVR:DM5PR00MB0374; x-forefront-prvs: 0666E15D35 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39380400002)(39860400002)(376002)(396003)(366004)(346002)(13464003)(377424004)(199004)(189003)(97736004)(7736002)(105586002)(2501003)(99286004)(21615005)(72206003)(10290500003)(5660300001)(81166006)(8676002)(81156014)(106356001)(966005)(8936002)(59450400001)(6506007)(68736007)(6116002)(790700001)(52396003)(10090500001)(76176011)(53546011)(7696005)(74316002)(14454004)(86362001)(6246003)(8990500004)(6346003)(5250100002)(2900100001)(186003)(102836004)(110136005)(86612001)(316002)(33656002)(229853002)(55016002)(236005)(54896002)(6306002)(9686003)(53936002)(22452003)(46003)(606006)(478600001)(2906002)(446003)(11346002)(25786009)(6436002)(476003)(3280700002)(3660700001)(486006); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR00MB0374; H:DM5PR00MB0296.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) authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-microsoft-antispam-message-info: V8XELL4w8DoIOSwjvzFVsthyZ9FZM6nHMWfkIVF4/7F0nwyImZoowH4DH8jyQHtSRfZNZsRJRp3JXhXDsGB1CHzWSabl01DG31GvjH2kc4urVMt5vL3qaf+wp/unB6vSN/cL7xZw8EL96EN/PU+TIZpF5kjWU5b9I4IimDYyrhusYbGGB/eXimpPA24g2dSN spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR00MB02969CC0E6E488B119028391F59A0DM5PR00MB0296namp_" MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: b59d5b4e-f1e2-4bbd-07bf-08d5b50ac4b2 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: b59d5b4e-f1e2-4bbd-07bf-08d5b50ac4b2 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 May 2018 17:40:19.5724 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR00MB0374 Archived-At: Subject: Re: [Ace] OAuth-Authz Interop X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2018 17:40:25 -0000 --_000_DM5PR00MB02969CC0E6E488B119028391F59A0DM5PR00MB0296namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QmVmb3JlIGFueSBpbnRlcm9wIHdvcmsgaXMgZG9uZSwgSSBzdWdnZXN0IHRoYXQgaXQgd291bGQg YmUgYmV0dGVyIHRvIGZpcnN0IGFkZHJlc3MgdGhlIHNpZ25pZmljYW50IENCT1IgbnVtYmVyIGFz c2lnbm1lbnQgaXNzdWVzIEkgcG9pbnRlZCBvdXQgaW4gbXkgcmV2aWV3IG9uIE9jdG9iZXIgMTAs IDIwMTcgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9hY2UvY3VycmVudC9t c2cwMjM2NC5odG1sLCBzbyB0aGF0IHRoZSBpbnRlcm9wIGlzIG1vcmUgbGlrZWx5IHRvIG9jY3Vy IHVzaW5nIG51bWJlciBhc3NpZ25tZW50cyB0aGF0IGFyZSBsZXNzIGxpa2VseSB0byBjaGFuZ2Uu ICBJJ20gcmVwZWF0aW5nIHRoZSBtb3N0IGltcG9ydGFudCBvZiB0aGVzZSBjb21tZW50cyBiZWxv dywgc2luY2UgaXQgd2FzIGFwcGFyZW50bHkgbm90IGFjdGVkIHVwb24uDQoNCg0KNS41LjUgTWFw cGluZyBwYXJhbWV0ZXJzIHRvIENCT1INCkl0IGxvb2tzIHRvIG1lIGxpa2UgdGhlc2UgdmFsdWVz IGFyZSBpbnRlbmRlZCB0byBhbGlnbiB3aXRoIHRob3NlIHJlZ2lzdGVyZWQgaW4gdGhlIENCT1Ig V2ViIFRva2VuIChDV1QpIENsYWltcyByZWdpc3RyeSBpbml0aWFsbHkgcG9wdWxhdGVkIGJ5IGh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWFjZS1jYm9yLXdlYi10b2tlbi0w OCNzZWN0aW9uLTkuMS4yLiAgSWYgc28sIHRoZSBzcGVjIHNob3VsZCBtYWtlIHRoaXMgcmVsYXRp b25zaGlwIGV4cGxpY2l0LiAgSG93ZXZlciwgaXQgd291bGQgYmUgaW5hcHByb3ByaWF0ZSB0byB1 c2UgdGhlIHJhcmUgc2luZ2xlLWJ5dGUgQ0JPUiBpbnRlZ2VyIHZhbHVlcyBmb3IgYXBwbGljYXRp b24tc3BlY2lmaWMgY2xhaW0ga2V5cy4gIEkgd291bGQgc3VnZ2VzdCB0aGF0IHRoZSBjbGFpbSBp ZGVudGlmaWVycyBmb3IgY2xpZW50X2lkIHRocm91Z2ggcmVmcmVzaF90b2tlbiBhbmQgcHJvZmls ZSBzdGFydCBhdCAyNTYgKGEgdHdvLWJ5dGUgQ0JPUiB2YWx1ZSkgYW5kIGdvIHVwIGZyb20gdGhl cmUuICBJbiB0aGF0IGNhc2UsIEkgc3VzcGVjdCB0aGV5IGNvdWxkIGJlIHN1Y2Nlc3NmdWxseSBy ZWdpc3RlcmVkIGluIHRoZSBDV1QgQ2xhaW1zIHJlZ2lzdHJ5IOKAkyB3aGljaCBJIHRoaW5rIHlv dSB3YW50LiAgKOKAnGNuZuKAnSB3aWxsIGFscmVhZHkgYmUgcmVnaXN0ZXJlZCBieSBkcmFmdC1p ZXRmLWFjZS1jd3QtcHJvb2Ytb2YtcG9zc2Vzc2lvbi4pDQoNCg0KDQpMaWtld2lzZSwgcGxlYXNl IHNlYXJjaCB0aGUgcmV2aWV3IGZvciBhbGwgaW5zdGFuY2VzIG9mIHRoZSB3b3JkcyDigJxyZWdp c3RlcuKAnSBhbmQg4oCccmVnaXN0cnnigJ0gYW5kIHJldmlzZWQgdGhlIHNwZWMgYWNjb3JkaW5n bHkgYmVmb3JlIGFueSBpbnRlcm9wIHdvcmsgaXMgc3RhcnRlZC4NCg0KDQoNCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBN aWtlDQoNCg0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEFjZSA8YWNl LWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiBMdWR3aWcgU2VpdHoNClNlbnQ6IFR1ZXNk YXksIE1heSA4LCAyMDE4IDM6NTQgQU0NClRvOiBhY2VAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBb QWNlXSBPQXV0aC1BdXRoeiBJbnRlcm9wDQoNCg0KDQpPbiAyMDE4LTA1LTA4IDA4OjU3LCBMdWR3 aWcgU2VpdHogd3JvdGU6DQoNCj4gT24gMjAxOC0wNS0wNyAxODo0NCwgSmltIFNjaGFhZCB3cm90 ZToNCg0KPj4gSSBoYXZlIGJlZW4gbWVhbmluZyB0byBnZXQgdGhpcyBvdXQgZm9yIGEgd2hpbGUg YW5kIGhhdmUgZmFpbGVkLiAgQQ0KDQo+PiBkb29kbGUgcG9sbCB0byBzZXR1cCBhbiBpbnRlcm9w IGV2ZW50IGZvciB0aGlzIHdvcmsgaXMgYXQNCg0KPj4gaHR0cHM6Ly9kb29kbGUuY29tL3BvbGwv azI3ZzlyMjZiZ2h2bnl0dSBJZiB5b3Ugd2FudCB0byBwYXJ0aWNpcGF0ZQ0KDQo+PiBhbmQgbm9u ZSBvZiB0aGUgdGltZXMgYXJlIGdvb2QgcGxlYXNlIGxldCBtZSBrbm93Lg0KDQo+Pg0KDQo+PiBU aGluZ3MgZm9yIHRlc3Rpbmc6DQoNCj4+IDEpICBEVExTIHByb2ZpbGUgdy8gc2hhcmVkIHNlY3Jl dA0KDQo+PiAyKSAgRFRMUyBwcm9maWxlIHcvIFJQSw0KDQo+PiAzKSAgT1NDT1JFIHByb2ZpbGUN Cg0KPj4NCg0KPj4NCg0KPg0KDQo+IE5vdGUgdGhhdCBJJ20gaW4gdGhlIHByb2Nlc3Mgb2Ygd3Jp dGluZyBhIHRlc3QgbWFudWFsLCBJJ2xsIHB1dCBpdCB1cA0KDQo+IG9uIHRoZSBXRyBnaXRodWIg YXMgc29vbiBhcyBpdCBoYXMgc29tZSBmb3JtIGFuZCBzdHJ1Y3R1cmUuIEZlZWwgZnJlZQ0KDQo+ IHRvIGNvbnRyaWJ1dGUuIEknbSBob3BpbmcgdG8gaGF2ZSBpdCBvbmxpbmUgYnkgdGhlIGVuZCBv ZiB0aGUgZGF5Lg0KDQo+DQoNCj4gL0x1ZHdpZw0KDQo+DQoNCj4NCg0KDQoNCllvdSBjYW4gZmlu ZCBteSBmaXJzdCBkcmFmdCBvZiB0aGUgaW50ZXJvcCBtYW51YWwgaGVyZToNCg0KDQoNCmh0dHBz Oi8vZ2l0aHViLmNvbS9hY2Utd2cvYWNlLW9hdXRoL2Jsb2IvbWFzdGVyL0ludGVyb3BUZXN0UGxh bi50eHQNCg0KDQoNCk5vdGUgdGhhdCBsYXJnZSBwYXJ0cyBhcmUgc3RpbGwgd29yayBpbiBwcm9n cmVzcywgYnV0IHRoZSB0ZXN0IHBsYW4gZm9yIHRoZSB0b2tlbiBlbmRwb2ludCBzaG91bGQgZ2l2 ZSB5b3UgYSBoaW50IGFzIHRvIGhvdyBJIHdhcyB0aGlua2luZyBpdCBjb3VsZCB3b3JrLg0KDQoN Cg0KRmVlbCBmcmVlIHRvIHByb3Bvc2UgY2hhbmdlcyBhbmQgaW1wcm92ZW1lbnRzLg0KDQoNCg0K DQoNCi9MdWR3aWcNCg0KDQoNCi0tDQoNCkx1ZHdpZyBTZWl0eiwgUGhEDQoNClNlY3VyaXR5IExh YiwgUklTRSBTSUNTDQoNClBob25lICs0NigwKTcwLTM0OSA5MiA1MQ0KDQoNCg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KQWNlIG1haWxpbmcgbGlz dA0KDQpBY2VAaWV0Zi5vcmc8bWFpbHRvOkFjZUBpZXRmLm9yZz4NCg0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hY2UNCg== --_000_DM5PR00MB02969CC0E6E488B119028391F59A0DM5PR00MB0296namp_ 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 aWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLlBsYWluVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6 IlBsYWluIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1s aW5rOiJQbGFpbiBUZXh0IjsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQou TXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVp biAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2Vj dGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+ DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5 b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9v OnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4t VVMiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0 aW9uMSI+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5CZWZvcmUgYW55IGludGVyb3Agd29yayBp cyBkb25lLCBJIHN1Z2dlc3QgdGhhdCBpdCB3b3VsZCBiZSBiZXR0ZXIgdG8gZmlyc3QgYWRkcmVz cyB0aGUgc2lnbmlmaWNhbnQgQ0JPUiBudW1iZXIgYXNzaWdubWVudCBpc3N1ZXMgSSBwb2ludGVk IG91dCBpbiBteSByZXZpZXcgb24gT2N0b2JlciAxMCwgMjAxNw0KPGEgaHJlZj0iaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9hY2UvY3VycmVudC9tc2cwMjM2NC5odG1sIj5o dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2FjZS9jdXJyZW50L21zZzAyMzY0 Lmh0bWw8L2E+LCBzbyB0aGF0IHRoZSBpbnRlcm9wIGlzIG1vcmUgbGlrZWx5IHRvIG9jY3VyIHVz aW5nIG51bWJlciBhc3NpZ25tZW50cyB0aGF0IGFyZSBsZXNzIGxpa2VseSB0byBjaGFuZ2UuJm5i c3A7IEknbSByZXBlYXRpbmcNCiB0aGUgbW9zdCBpbXBvcnRhbnQgb2YgdGhlc2UgY29tbWVudHMg YmVsb3csIHNpbmNlIGl0IHdhcyBhcHBhcmVudGx5IG5vdCBhY3RlZCB1cG9uLjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+NS41LjUgTWFwcGluZyBw YXJhbWV0ZXJzIHRvIENCT1I8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDouNWluIj5JdCBsb29rcyB0byBtZSBsaWtlIHRoZXNlIHZhbHVlcyBh cmUgaW50ZW5kZWQgdG8gYWxpZ24gd2l0aCB0aG9zZSByZWdpc3RlcmVkIGluIHRoZSBDQk9SIFdl YiBUb2tlbiAoQ1dUKSBDbGFpbXMgcmVnaXN0cnkgaW5pdGlhbGx5IHBvcHVsYXRlZCBieQ0KPGEg aHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtYWNlLWNib3Itd2Vi LXRva2VuLTA4I3NlY3Rpb24tOS4xLjIiPg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LWlldGYtYWNlLWNib3Itd2ViLXRva2VuLTA4I3NlY3Rpb24tOS4xLjI8L2E+LiZuYnNwOyBJ ZiBzbywgdGhlIHNwZWMgc2hvdWxkIG1ha2UgdGhpcyByZWxhdGlvbnNoaXAgZXhwbGljaXQuJm5i c3A7IEhvd2V2ZXIsIGl0IHdvdWxkIGJlIGluYXBwcm9wcmlhdGUgdG8gdXNlIHRoZSByYXJlIHNp bmdsZS1ieXRlIENCT1IgaW50ZWdlciB2YWx1ZXMgZm9yIGFwcGxpY2F0aW9uLXNwZWNpZmljIGNs YWltIGtleXMuJm5ic3A7DQogSSB3b3VsZCBzdWdnZXN0IHRoYXQgdGhlIGNsYWltIGlkZW50aWZp ZXJzIGZvciBjbGllbnRfaWQgdGhyb3VnaCByZWZyZXNoX3Rva2VuIGFuZCBwcm9maWxlIHN0YXJ0 IGF0IDI1NiAoYSB0d28tYnl0ZSBDQk9SIHZhbHVlKSBhbmQgZ28gdXAgZnJvbSB0aGVyZS4mbmJz cDsgSW4gdGhhdCBjYXNlLCBJIHN1c3BlY3QgdGhleSBjb3VsZCBiZSBzdWNjZXNzZnVsbHkgcmVn aXN0ZXJlZCBpbiB0aGUgQ1dUIENsYWltcyByZWdpc3RyeSDigJMgd2hpY2ggSSB0aGluaw0KIHlv dSB3YW50LiZuYnNwOyAo4oCcY25m4oCdIHdpbGwgYWxyZWFkeSBiZSByZWdpc3RlcmVkIGJ5IGRy YWZ0LWlldGYtYWNlLWN3dC1wcm9vZi1vZi1wb3NzZXNzaW9uLik8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+TGlrZXdpc2UsIHBsZWFzZSBzZWFyY2ggdGhlIHJldmlldyBmb3IgYWxsIGlu c3RhbmNlcyBvZiB0aGUgd29yZHMg4oCccmVnaXN0ZXLigJ0gYW5kIOKAnHJlZ2lzdHJ54oCdIGFu ZCByZXZpc2VkIHRoZSBzcGVjIGFjY29yZGluZ2x5IGJlZm9yZSBhbnkgaW50ZXJvcCB3b3JrIGlz IHN0YXJ0ZWQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAtLSBNaWtlPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+LS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS08YnI+DQpGcm9tOiBBY2UgJmx0O2FjZS1ib3VuY2VzQGlldGYub3Jn Jmd0OyBPbiBCZWhhbGYgT2YgTHVkd2lnIFNlaXR6PGJyPg0KU2VudDogVHVlc2RheSwgTWF5IDgs IDIwMTggMzo1NCBBTTxicj4NClRvOiBhY2VAaWV0Zi5vcmc8YnI+DQpTdWJqZWN0OiBSZTogW0Fj ZV0gT0F1dGgtQXV0aHogSW50ZXJvcDwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+T24gMjAxOC0wNS0wOCAw ODo1NywgTHVkd2lnIFNlaXR6IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+Jmd0OyBPbiAyMDE4LTA1LTA3IDE4OjQ0LCBKaW0gU2NoYWFkIHdyb3RlOjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsgSSBoYXZlIGJlZW4g bWVhbmluZyB0byBnZXQgdGhpcyBvdXQgZm9yIGEgd2hpbGUgYW5kIGhhdmUgZmFpbGVkLiZuYnNw OyBBDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7IGRv b2RsZSBwb2xsIHRvIHNldHVwIGFuIGludGVyb3AgZXZlbnQgZm9yIHRoaXMgd29yayBpcyBhdA0K PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyA8YSBocmVm PSJodHRwczovL2Rvb2RsZS5jb20vcG9sbC9rMjdnOXIyNmJnaHZueXR1Ij48c3BhbiBzdHlsZT0i Y29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+aHR0cHM6Ly9kb29kbGUuY29t L3BvbGwvazI3ZzlyMjZiZ2h2bnl0dTwvc3Bhbj48L2E+IElmIHlvdSB3YW50IHRvIHBhcnRpY2lw YXRlDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7IGFu ZCBub25lIG9mIHRoZSB0aW1lcyBhcmUgZ29vZCBwbGVhc2UgbGV0IG1lIGtub3cuPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsgVGhpbmdzIGZvciB0ZXN0aW5n OjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsgMSkmbmJz cDsgRFRMUyBwcm9maWxlIHcvIHNoYXJlZCBzZWNyZXQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZndDsmZ3Q7IDIpJm5ic3A7IERUTFMgcHJvZmlsZSB3LyBSUEs8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7IDMpJm5ic3A7IE9T Q09SRSBwcm9maWxlPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7 Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZn dDs8bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IE5vdGUgdGhhdCBJJ20g aW4gdGhlIHByb2Nlc3Mgb2Ygd3JpdGluZyBhIHRlc3QgbWFudWFsLCBJJ2xsIHB1dCBpdCB1cA0K PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IG9uIHRoZSBXRyBn aXRodWIgYXMgc29vbiBhcyBpdCBoYXMgc29tZSBmb3JtIGFuZCBzdHJ1Y3R1cmUuIEZlZWwgZnJl ZQ0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IHRvIGNvbnRy aWJ1dGUuIEknbSBob3BpbmcgdG8gaGF2ZSBpdCBvbmxpbmUgYnkgdGhlIGVuZCBvZiB0aGUgZGF5 LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyA8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgL0x1ZHdpZzxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZndDsgPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPllvdSBj YW4gZmluZCBteSBmaXJzdCBkcmFmdCBvZiB0aGUgaW50ZXJvcCBtYW51YWwgaGVyZTo8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PGEgaHJlZj0iaHR0cHM6Ly9naXRodWIuY29tL2FjZS13 Zy9hY2Utb2F1dGgvYmxvYi9tYXN0ZXIvSW50ZXJvcFRlc3RQbGFuLnR4dCI+PHNwYW4gc3R5bGU9 ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPmh0dHBzOi8vZ2l0aHViLmNv bS9hY2Utd2cvYWNlLW9hdXRoL2Jsb2IvbWFzdGVyL0ludGVyb3BUZXN0UGxhbi50eHQ8L3NwYW4+ PC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5Ob3RlIHRoYXQgbGFyZ2UgcGFydHMg YXJlIHN0aWxsIHdvcmsgaW4gcHJvZ3Jlc3MsIGJ1dCB0aGUgdGVzdCBwbGFuIGZvciB0aGUgdG9r ZW4gZW5kcG9pbnQgc2hvdWxkIGdpdmUgeW91IGEgaGludCBhcyB0byBob3cgSSB3YXMgdGhpbmtp bmcgaXQgY291bGQgd29yay48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+RmVlbCBmcmVl IHRvIHByb3Bvc2UgY2hhbmdlcyBhbmQgaW1wcm92ZW1lbnRzLjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi Pi9MdWR3aWc8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+LS08bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkx1ZHdpZyBTZWl0eiwgUGhEPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5TZWN1cml0eSBMYWIsIFJJU0UgU0lDUzxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+UGhvbmUgJiM0Mzs0NigwKTcwLTM0OSA5 MiA1MTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+QWNlIG1haWxpbmcgbGlzdDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+PGEgaHJlZj0ibWFpbHRvOkFjZUBpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9y OndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPkFjZUBpZXRmLm9yZzwvc3Bhbj48L2E+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48YSBocmVmPSJodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FjZSI+PHNwYW4gc3R5bGU9ImNvbG9yOndp bmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vYWNlPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5 Pg0KPC9odG1sPg0K --_000_DM5PR00MB02969CC0E6E488B119028391F59A0DM5PR00MB0296namp_-- From nobody Tue May 8 15:19:03 2018 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6D3812EB02 for ; Tue, 8 May 2018 15:19:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ay2TKtP7FYr5 for ; Tue, 8 May 2018 15:18:59 -0700 (PDT) Received: from taper.sei.cmu.edu (taper.sei.cmu.edu [147.72.252.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9B2412EAF7 for ; Tue, 8 May 2018 15:18:58 -0700 (PDT) Received: from delp.sei.cmu.edu (delp.sei.cmu.edu [10.64.21.31]) by taper.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id w48MIvYv009275 for ; Tue, 8 May 2018 18:18:57 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 taper.sei.cmu.edu w48MIvYv009275 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1525817937; bh=4K2yA8O4MF3IKd6S2klsH1jsDOtQkLXxpzblEEXYsIU=; h=From:To:Subject:Date:From; b=sEKFxgON1AtRnxcST/QYgoDcV7l+k8Xo6lOIX0ywaAbFBW4h5nS9wIGmFztzKyCfd NmSggkGjyaYhP5CFySwyGOo1Gn9yoTIRi6CFCNco7+2913nfnXbKysUTt6ftDsOQZK 0Bmmo479oybzsT1RqUMvFtEGnxBCY33USbhSGrHc= Received: from CASCADE.ad.sei.cmu.edu (cascade.ad.sei.cmu.edu [10.64.28.248]) by delp.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id w48MIrgV018279 for ; Tue, 8 May 2018 18:18:53 -0400 Received: from MARCHAND.ad.sei.cmu.edu ([10.64.28.251]) by CASCADE.ad.sei.cmu.edu ([10.64.28.248]) with mapi id 14.03.0361.001; Tue, 8 May 2018 18:18:53 -0400 From: Roman Danyliw To: "ace@ietf.org" Thread-Topic: WGLC on draft-ietf-ace-cwt-proof-of-possession-02 Thread-Index: AdPnGgXMYVrDIRKQRwyiq8BLgNVR0w== Date: Tue, 8 May 2018 22:18:52 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC014C3AA67D@marchand> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [Ace] WGLC on draft-ietf-ace-cwt-proof-of-possession-02 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2018 22:19:01 -0000 Hello! Consistent with the feedback from the editor team at the London meeting, we= are starting a working group last call (WGLC) for the "Proof-of-Possession= Key Semantics for CBOR Web Tokens (CWTs)" draft: ** draft-ietf-ace-cwt-proof-of-possession-02 ** https://tools.ietf.org/html/draft-ietf-ace-cwt-proof-of-possession-02 Please send comments to the mailing list -- feedback on issues or needed ch= anges; as well as endorsements that this draft is ready. This WGLC will end on Wednesday, May 23, 2018. Thanks, Roman and Jim From nobody Tue May 8 15:58:33 2018 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB00412D7EC; Tue, 8 May 2018 15:58:30 -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_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 Herh_gjyJmnn; Tue, 8 May 2018 15:58:28 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF875124234; Tue, 8 May 2018 15:58:28 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 9203DB81C2E; Tue, 8 May 2018 15:58:16 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, ace@ietf.org Content-type: text/plain; charset=UTF-8 Message-Id: <20180508225816.9203DB81C2E@rfc-editor.org> Date: Tue, 8 May 2018 15:58:16 -0700 (PDT) Archived-At: Subject: [Ace] =?utf-8?q?RFC_8392_on_CBOR_Web_Token_=28CWT=29?= X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2018 22:58:31 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8392 Title: CBOR Web Token (CWT) Author: M. Jones, E. Wahlstroem, S. Erdtman, H. Tschofenig Status: Standards Track Stream: IETF Date: May 2018 Mailbox: mbj@microsoft.com, erik@wahlstromstekniska.se, erdtman@spotify.com, Hannes.Tschofenig@arm.com Pages: 25 Characters: 46316 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-ace-cbor-web-token-15.txt URL: https://www.rfc-editor.org/info/rfc8392 DOI: 10.17487/RFC8392 CBOR Web Token (CWT) is a compact means of representing claims to be transferred between two parties. The claims in a CWT are encoded in the Concise Binary Object Representation (CBOR), and CBOR Object Signing and Encryption (COSE) is used for added application-layer security protection. A claim is a piece of information asserted about a subject and is represented as a name/value pair consisting of a claim name and a claim value. CWT is derived from JSON Web Token (JWT) but uses CBOR rather than JSON. This document is a product of the Authentication and Authorization for Constrained Environments Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Tue May 8 16:06:17 2018 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A12B1124234 for ; Tue, 8 May 2018 16:06:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.009 X-Spam-Level: X-Spam-Status: No, score=-2.009 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-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 RvKe42LLGcCj for ; Tue, 8 May 2018 16:06:14 -0700 (PDT) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0138.outbound.protection.outlook.com [104.47.41.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26DEF12D7EC for ; Tue, 8 May 2018 16:06:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=TSbclIXxnmvz6al2ImU4jZypU6msxPkPNtxGk1miy80=; b=bzqp9ymzFPJIXMJCcCyU51JYOstJaaSO5ZSY63BOmN4t28BUQMab3b8jwmpEzjPiM5x5mevXTOBBm+xEzOpo2lYZNnR5GWhKwoGdy/5Mr+TKA3VZwcGTgr43AqcOT2Zqm+RdhvDni4yObRWyeL7A/M2z5cbFV+/dsBDHPLrrNBI= Received: from BL0PR00MB0292.namprd00.prod.outlook.com (2603:10b6:207:1e::30) by BL0PR00MB0386.namprd00.prod.outlook.com (2603:10b6:207:1f::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.792.0; Tue, 8 May 2018 23:05:56 +0000 Received: from BL0PR00MB0292.namprd00.prod.outlook.com ([fe80::84a0:cb3c:39ec:1b01]) by BL0PR00MB0292.namprd00.prod.outlook.com ([fe80::84a0:cb3c:39ec:1b01%5]) with mapi id 15.20.0792.000; Tue, 8 May 2018 23:05:56 +0000 From: Mike Jones To: "ace@ietf.org" Thread-Topic: =?Windows-1252?Q?=93CBOR_Web_Token_(CWT)=94_is_now_RFC_8392?= Thread-Index: AdPm+m+37+zcynCXRhyE23ZIy52Dxg== Date: Tue, 8 May 2018 23:05:56 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=mbj@microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2018-05-08T23:05:55.0550431Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic; Sensitivity=General x-originating-ip: [2001:4898:80e8:3::291] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BL0PR00MB0386; 7:JVIe8mmPzzUCDcJpAPE2FOfdfV9g9D0KNqKVyBL1cqCo7tH3XduGeqvpFGGJcpmvGYYoGNxUwzug8CT+M2eaaoH5v7Bv31v2GWvJUKNTQgGKx7xi7wBQxN7X9joVfOUlaSSeQZt9ukAgwEt2Q6DHNEGa8Dv1zp/o75cGY4OTjc6nKAf8HP4ndyA53pPP9dnnhn6xcJX+P8GYwbEPSsrOhmJXr10RHG2M3CHUa6ndA43tU/zLGdkbj2DtKWRuVvnJ; 20:wdIjoe8717K+tun39nqmZNsJaezydBuN+aJDHHURjOnszqDGdbQNQJcZ1TmzqQdzF9xJm/60J3DLDADdHtU3sQpDKk7xXL1lw21ijroDCwS0D5nqrAIY1B5VffME79kHAQ/mX6CKKlDktKYcmPwqxtWygaiTzUvzucYXudTN/f8= x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(48565401081)(2017052603328)(7193020); SRVR:BL0PR00MB0386; x-ms-traffictypediagnostic: BL0PR00MB0386: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(192374486261705)(31418570063057)(21748063052155); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(2017102700009)(2017102701064)(6040522)(2401047)(8121501046)(5005006)(2017102702064)(20171027021009)(20171027022009)(20171027023009)(20171027024009)(20171027025009)(20171027026009)(2017102703076)(3002001)(93006095)(93001095)(10201501046)(3231254)(2018427008)(944501410)(52105095)(6055026)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(20161123562045)(20161123558120)(6072148)(201708071742011); SRVR:BL0PR00MB0386; BCL:0; PCL:0; RULEID:; SRVR:BL0PR00MB0386; x-forefront-prvs: 0666E15D35 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39380400002)(39860400002)(366004)(396003)(346002)(376002)(209900001)(189003)(199004)(86362001)(10290500003)(81156014)(81166006)(86612001)(8990500004)(10090500001)(1730700003)(97736004)(476003)(2906002)(6346003)(74316002)(478600001)(966005)(186003)(3280700002)(3660700001)(2351001)(9686003)(8936002)(5250100002)(99286004)(7736002)(54896002)(53376002)(55016002)(14454004)(236005)(53936002)(6306002)(606006)(52396003)(105586002)(68736007)(316002)(6916009)(790700001)(106356001)(6116002)(2501003)(5630700001)(59450400001)(33656002)(7696005)(6506007)(2900100001)(486006)(5660300001)(102836004)(6436002)(5640700003)(22452003)(72206003)(25786009)(46003)(6606295002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL0PR00MB0386; H:BL0PR00MB0292.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) authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-microsoft-antispam-message-info: Xf7cWh4z0z555VZiQbq+MdfmbNir4yKB0ohWXGn2F2c7WhCD8N1OFvXsG8lNVTzTpJPoEmucm7dDs1ySuSXDxZXEdlT9Ng3Pgk9OHgk5NFcDBmxUe5CuEiOmZWd2kRhPRqUPCFVlImyawTzzqZ+RhVTkiZb+sDJop1u000VLjoWM0VG3iNaa1RhQdaDxlrnW spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BL0PR00MB02922C6F48756589B0EB6AF8F59A0BL0PR00MB0292namp_" MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 34b3d1d3-07db-4137-6bc2-08d5b53841a4 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 34b3d1d3-07db-4137-6bc2-08d5b53841a4 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 May 2018 23:05:56.4582 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR00MB0386 Archived-At: Subject: [Ace] =?windows-1252?q?=93CBOR_Web_Token_=28CWT=29=94_is_now_RFC_?= =?windows-1252?q?8392?= X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2018 23:06:16 -0000 --_000_BL0PR00MB02922C6F48756589B0EB6AF8F59A0BL0PR00MB0292namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable The =93CBOR Web Token (CWT)=94 specification is now RFC 8392 - an IETF standard. The abstract for the spe= cification is: CBOR Web Token (CWT) is a compact means of representing claims to be transf= erred between two parties. The claims in a CWT are encoded in the Concise = Binary Object Representation (CBOR) and CBOR Object Signing and Encryption = (COSE) is used for added application-layer security protection. A claim is= a piece of information asserted about a subject and is represented as a na= me/value pair consisting of a claim name and a claim value. CWT is derived= from JSON Web Token (JWT) but uses CBOR rather than JSON. Special thanks to Erik Wahlstr=F6m for = starting this work and to Samuel Erdtman for = doing most of the heavy lifting involved in creating correct and useful CBO= R and COSE examples. Next up =96 finishing =93Proof-of-Possession Key Semantics for CBOR Web Tok= ens (CWTs)=94, which provides the CWT equivalent of =93Proof-of-Possession Key = Semantics for JSON Web Tokens (JWTs)=94 [RFC 7800]. -- Mike P.S. This notice was also posted at http://self-issued.info/?p=3D1844 and = as @selfissued. --_000_BL0PR00MB02922C6F48756589B0EB6AF8F59A0BL0PR00MB0292namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

The =93CBOR Web Token (CWT)=94 specification is now = RFC 8392 - an IETF standard.  The abstract for the specification i= s:

 

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

 

Special thanks to Erik Wahlstr=F6m for starting this work and to Samuel Erdtman for doing most of the heavy lifting involved in creating= correct and useful CBOR and COSE examples.

 

Next up =96 finishing =93Proof-of-Possession = Key Semantics for CBOR Web Tokens (CWTs)=94, which provides the CWT equ= ivalent of =93Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)=94 [RFC 7800].

 

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

 

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

--_000_BL0PR00MB02922C6F48756589B0EB6AF8F59A0BL0PR00MB0292namp_-- From nobody Tue May 8 21:51:25 2018 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65E1F1270FC; Tue, 8 May 2018 21:51:24 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W8xtXMWm17tZ; Tue, 8 May 2018 21:51:22 -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 D4B4C12D882; Tue, 8 May 2018 21:51:21 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 8 May 2018 21:48:41 -0700 From: Jim Schaad To: CC: References: <359EC4B99E040048A7131E0F4E113AFC014C3AA67D@marchand> In-Reply-To: <359EC4B99E040048A7131E0F4E113AFC014C3AA67D@marchand> Date: Tue, 8 May 2018 21:51:11 -0700 Message-ID: <00ad01d3e751$5c1f03a0$145d0ae0$@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: AQG8BN2SgGQI0s8TRVm0gk+2+YL3P6RWmDVA Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Ace] WGLC on draft-ietf-ace-cwt-proof-of-possession-02 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2018 04:51:24 -0000 I'll pull out the list of comments that I wrote a month ago but didn't start that computer up recently. 1. Are all of the authors necessary? As a chair I need to justify a count of more than 5 to the IESG. 2. Is the last sentence in section 1 necessary? Are you actually defining any strings that could be case-sensitive? 3. Terminology: In the definition of Issuer please make 'its' clearer. It is not clear whose claims are being bound. 4. Terminology: I still think this is 'Presenter' is a very strange term to use for this definition. I would really like to see it be made something that makes sense and then say the term is the same as this in JWT. The term has a model of use with it that I do not believe can be sustained even for the ACE Oauth case but really not in other cases. 5. Terminology: Recipient matches presenter, and it matches the OAuth model and not a trust model world. Relying party or service provider make far more sense to me. 6. Under what circumstances would a 'sub' claim be present and it is not the presenter? I can see that a holder of the key may be implicitly (or anonymously) named, but putting something in the subject field which is not identifying the presenter is something that I would reject without a good presentation of why in the document. 7. I would disagree with the claim that if the 'sub' claim is missing then it would normally be the issuer. For the world of IoT, I would expect that the subject would not be present because there is no need to identify the subject to the recipient. I.e. it is an anonymous subject. 8. It is not clear to me that either of the sub and iss claims would normally be present. They might be present but neither is needed. The subject can be anonymous and the issuer is identified by the key used to validate the security on the CWT. 9. In section 3.1 the first two sentences appear to be contradictory. Members are used to identify the POP key. Other things than a POP key can be used than a POP key. If they are used to identify the POP key- why would they not deal with the POP key? I think that you should do a separation and define the 'cnf' file which can hold any number of confirmation methods and then have a section on defining some POP cnf method field holders. 10. In section 3.1 P1 - I am not sure why you have something here about confirming the authenticity of the token as oppose to confirming the identity of the presenter. Why would that type of information be placed here where it is not useful. 11. In section 3.1 P2 - We are back to the same argument that existed for a CWT in general. Not knowing that a CWT is for a specific application means that it can be used in a different application and checking that the first application would have done is ignored by the second one because it will ignore fields it does not understand. 12. I am unclear why there should be a restriction on the number of POP keys that can be in a 'cnf' object. If there are multiple keys, then any or all of them are of equal value in doing the confirmation. Just like there can be multiple confirmation methods and an application could choose to use any one of them. 13. Not sure which section this belongs in, but the use of an COSE_Encrypt0 would be one way to combat tracking of identities based on the key value being used. Different encrypted values could be sent to different servers and they would not necessarily know about use w/o internal collusion between them. Similar effect by using an encrypted CWT. Potentially requires use of TLS1.3 to protect the RPKs. YMMV 14. I have real problems w/ the use of a KID for POP identification. It may identify the wrong key or, if used for granting access, may have problems w/ identity collisions. These need to be spelt out someplace to help people tracking down questions of why can't I verify w/ this CWT, I know it's right. 15. The content of 'kid' is application specific. Where is an application going to define this such that it will work more generally. The application in the case of the ACE working group boils down to the world (minus a few things). 16. section 4 - Are audience restrictions not done in CWT? 17. section 4 - this implies that POP cannot be replayed via asymmetric keys. Why would this be the case? 18. section 4 - prior to an issuer being able to create a CWT for a client w/ an asymmetric key in it, the issuer MUST go through a POP protocol of some type to validate that the client has possession of the key. Issuers may want to repeat this validation at some interval for re-verification. They should also keep track of the keys and flag where the same public key appears more than one for review. 19. Update IANA considerations w/ input from IANA and the CWT document. 20. Are keys big enough that it should be considered to move kid to the 2 byte range of identifiers? 21. Section 6.2.2 - the value type is not an array for COSE_Encrypt or COSE_Encyrpt0, these are the values. As written I could put in an array which is not one of those two structures and be valid. Ditto for COSE_Key, although w/ slightly less justification. Jim From nobody Wed May 9 00:39:14 2018 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 552A6126C3D for ; Wed, 9 May 2018 00:39:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N6fyTNeTSwgB for ; Wed, 9 May 2018 00:39:09 -0700 (PDT) Received: from smtp-out10.electric.net (smtp-out10.electric.net [185.38.180.34]) (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 30BB012D965 for ; Wed, 9 May 2018 00:39:09 -0700 (PDT) Received: from 1fGJgo-000737-VF by out10d.electric.net with emc1-ok (Exim 4.90_1) (envelope-from ) id 1fGJgo-00074r-WB; Wed, 09 May 2018 00:39:06 -0700 Received: by emcmailer; Wed, 09 May 2018 00:39:06 -0700 Received: from [194.218.146.197] (helo=sp-mail-2.sp.se) by out10d.electric.net with esmtps (TLSv1.2:ECDHE-RSA-AES128-SHA256:128) (Exim 4.90_1) (envelope-from ) id 1fGJgo-000737-VF; Wed, 09 May 2018 00:39:06 -0700 Received: from [192.168.0.166] (10.116.0.226) by sp-mail-2.sp.se (10.100.0.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1261.35; Wed, 9 May 2018 09:39:06 +0200 To: Mike Jones , "ace@ietf.org" References: <005601d3e622$af427100$0dc75300$@augustcellars.com> <7af7e847-bc7a-82ff-2024-7321575450d8@ri.se> From: Ludwig Seitz Message-ID: <94fec27e-e1d9-2ba1-80c6-58ec505e3bff@ri.se> Date: Wed, 9 May 2018 09:38:53 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [10.116.0.226] X-ClientProxiedBy: sp-mail-1.sp.se (10.100.0.161) To sp-mail-2.sp.se (10.100.0.162) X-Outbound-IP: 194.218.146.197 X-Env-From: ludwig.seitz@ri.se X-Proto: esmtps X-Revdns: X-HELO: sp-mail-2.sp.se X-TLS: TLSv1.2:ECDHE-RSA-AES128-SHA256:128 X-Authenticated_ID: X-PolicySMART: 14510320 X-Virus-Status: Scanned by VirusSMART (c) X-Virus-Status: Scanned by VirusSMART (s) Archived-At: Subject: Re: [Ace] OAuth-Authz Interop X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2018 07:39:12 -0000 On 2018-05-08 19:40, Mike Jones wrote: > Before any interop work is done, I suggest that it would be better to > first address the significant CBOR number assignment issues I pointed > out in my review on October 10, 2017 > https://www.ietf.org/mail-archive/web/ace/current/msg02364.html, so > that the interop is more likely to occur using number assignments > that are less likely to change. I'm repeating the most important of > these comments below, since it was apparently not acted upon. I was pretty sure we went over all of your comments and replied to you on list. We might have disagreed on some, but in that case we clearly stated that. Would you please specify which of your comments we have not acted upon, so that we can rectify that? Also I don't think the mapping of a few abbreviations should stop us from performing an interop. Detailed comments below. /Ludwig > 5.5.5 Mapping parameters to CBOR > > It looks to me like these values are intended to align with those > registered in the CBOR Web Token (CWT) Claims registry initially > populated by > https://tools.ietf.org/html/draft-ietf-ace-cbor-web-token-08#section-9.1.2. > > If so, the spec should make this relationship explicit. We did address this comment. See: https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-11#section-5.6.5 https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-11#section-5.7.4 " Note that we have aligned these abbreviations with the claim abbreviations defined in [I-D.ietf-ace-cbor-web-token]." We will update that reference to the RFC in the next iteration. > However, it would be inappropriate to use the rare single-byte CBOR > integer values for application-specific claim keys. I would suggest > that the claim identifiers for client_id through refresh_token and > profile start at 256 (a two-byte CBOR value) and go up from there. > In that case, I suspect they could be successfully registered in the > CWT Claims registry – which I think you want. (“cnf” will already be > registered by draft-ietf-ace-cwt-proof-of-possession.) > Those claims/request parameters are from the core OAuth 2.0 spec. I can buy an argument that they are not relevant for constrained applications, but they are by no means application-specific. Shall we make a case-by case evaluation of these? The ones used in the draft are: aud, scope, error, error_description, error_uri, grant_type, access_token, cnf, profile, rs_cnf. For the Authorization Code Grant (which has been pointed out as relevant) I would think we also need: response_type, client_id, state, code I would be ok with pushing the other parameters/claim keys into the two-byte abbreviation space. > Likewise, please search the review for all instances of the words > “register” and “registry” and revised the spec accordingly before any > interop work is started. I'm pretty sure we did cover all of your comments. Here is what we did (a long while ago), just for your reference: > 5.6.5 Mapping Introspection Parameters to CBOR > > As in my related comment on 5.5.5, it looks to me like these values > are intended to align with those registered in the CBOR Web Token > (CWT) Claims registry initially populated by > https://tools.ietf.org/html/draft-ietf-ace-cbor-web-token-08#section-9.1.2. > > If so, the spec should make this relationship explicit. However, it > would be inappropriate to use the rare single-byte CBOR integer > values for application-specific claim keys. I would suggest that the > claim identifiers for client_id through refresh_token and profile > start at 256 (a two-byte CBOR value) and go up from there. In that > case, I suspect they could be successfully registered in the CWT > Claims registry – which I think you want. (“cnf” will already be > registered by draft-ietf-ace-cwt-proof-of-possession.) > Done, see above > 8.1 OAuth Introspection Response Parameter Registration > > Every place an IANA registration currently says “this document”, > please change it to “Section x.y.z of this document” (using the > appropriate tag for the section that defines > the value. > > We followed the example of other documents that also lacked the specific section references. If you think this is important we can make that change. > > 8.1 OAuth Introspection Response Parameter Registration > > “aud” is already registered at > https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#token-introspection-response. In this draft aud is also used in the authorization token request. The registry entry you point at is from the OAuth Token Introspection Response list we want to have that parameter in the OAuth Parameters list as well. > > 8.4 Token Type Mappings > > The name “Token Type Mappings” registry is too generic. Please > change it to “OAuth Token Type CBOR Mappings” or something similar. Done, this is now 8.5 > 8.4.1 Registration Template > > As was pointed out in comments on earlier versions of the CWT spec, > the range 1 to 65536 makes no sense. Please consider using the same > treatment of value ranges as CWT does (which themselves derived from > the COSE usage of value ranges). Do this consistently every place > that “1 to 65536” occurs in the spec. This seems to have been missed. I will go over that again. > 8.5 CBOR Web Token Claims > > “cnf” is already being registered by > draft-ietf-ace-cwt-proof-of-possession. > It is being registered as a authorization token claim. We are registering it in the OAuth Parameters and OAuth Token Introspection Response. > 8.6 ACE Profile Registry > > The name “ACE Profile Registry” registry is too generic. Please > change it to “ACE OAuth Profile Registry” or something similar. > Done > 8.7 OAuth Parameter Mappings Registry > > The name “OAuth Parameter Mappings” registry is too generic. Please > change it to “OAuth CBOR Parameter Mappings” or something similar. Done > 8.7.2 Initial Registry Contents > > Per my earlier comments, these values should actually reference the > CWT Claims registry and application-specific values such as > “client_id”, etc. should not use the scarce single-byte value range. See discussion above > 8.8.1 Registration Template > > Registrations for the Introspection Endpoint CBOR Mappings registry > should contain a field that lists the corresponding value registered > in the OAuth Token Introspection Response registry at > https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#token-introspection-response. That would be the "Name" field. It currently refers to the OAuth Parameters registry, would you prefer that we refer to the specific section "OAuth Token Introspection Response"? > > 8.10 CWT Confirmation Methods Registry > > Delete this section, as it has been moved to > draft-ietf-ace-cwt-proof-of-possession. > Done -- Ludwig Seitz, PhD Security Lab, RISE SICS Phone +46(0)70-349 92 51 From nobody Thu May 10 11:59:33 2018 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E910112EB86 for ; Thu, 10 May 2018 11:59:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 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 ykB1Np60k3mr for ; Thu, 10 May 2018 11:59:29 -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 9487012EB7E for ; Thu, 10 May 2018 11:59:28 -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.1347.2; Thu, 10 May 2018 11:56:47 -0700 From: Jim Schaad To: 'Mike Jones' , 'Ludwig Seitz' , References: <005601d3e622$af427100$0dc75300$@augustcellars.com> <7af7e847-bc7a-82ff-2024-7321575450d8@ri.se> In-Reply-To: Date: Thu, 10 May 2018 11:59:18 -0700 Message-ID: <00cb01d3e891$0158b8d0$040a2a70$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00CC_01D3E856.54FB8E80" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQIYpAXHW23Avzfol4dRnuBSz27O0gHOnp3KAfwMrbkAwwZ7LqN7akRA Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Ace] OAuth-Authz Interop X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2018 18:59:32 -0000 ------=_NextPart_000_00CC_01D3E856.54FB8E80 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Given that we have already started doing interop work and were = successful needing to address the number assignment issues does not seem = to be a blocking problem. As long as all of the people doing the = interop testing are agreed on what numbers should be there do not seem = to be any issues in testing. The only problem would be if there was a = decision to ship products before the assignments were finalized. =20 =20 In terms of what size of items to use, this is going to be an = interesting argument and one that needs to be finalized at some point. = However, it would be just as easy to remove the sentence as to change = the values so there are multiple ways of solving this issue. I = don=E2=80=99t know that I agree that application-specific claim keys = should be pushed all of the way up to 256, there is always going to be a = trade off at this point in terms of what size of key to use vs how often = it is believed that the key is going to be used. If we believe that a = huge percentage of usage in the IoT world for CWT items is going to be = for this type of authorization and we want to keep alignment to the = extent possible then it still makes sense to use the 1 or 2 byte keys = for this purpose. (Side node, it is normal to include all of the bytes = encoded in the length so 256 would be a 3 byte value). This is a trade = off that needs to be discussed, but is not currently blocking. =20 Jim =20 =20 From: Ace On Behalf Of Mike Jones Sent: Tuesday, May 8, 2018 10:40 AM To: Ludwig Seitz ; ace@ietf.org Subject: Re: [Ace] OAuth-Authz Interop =20 Before any interop work is done, I suggest that it would be better to = first address the significant CBOR number assignment issues I pointed = out in my review on October 10, 2017 = https://www.ietf.org/mail-archive/web/ace/current/msg02364.html, so that = the interop is more likely to occur using number assignments that are = less likely to change. I'm repeating the most important of these = comments below, since it was apparently not acted upon. =20 5.5.5 Mapping parameters to CBOR It looks to me like these values are intended to align with those = registered in the CBOR Web Token (CWT) Claims registry initially = populated by = https://tools.ietf.org/html/draft-ietf-ace-cbor-web-token-08#section-9.1.= 2. If so, the spec should make this relationship explicit. However, it = would be inappropriate to use the rare single-byte CBOR integer values = for application-specific claim keys. I would suggest that the claim = identifiers for client_id through refresh_token and profile start at 256 = (a two-byte CBOR value) and go up from there. In that case, I suspect = they could be successfully registered in the CWT Claims registry = =E2=80=93 which I think you want. (=E2=80=9Ccnf=E2=80=9D will already = be registered by draft-ietf-ace-cwt-proof-of-possession.) =20 Likewise, please search the review for all instances of the words = =E2=80=9Cregister=E2=80=9D and =E2=80=9Cregistry=E2=80=9D and revised = the spec accordingly before any interop work is started. =20 -- Mike =20 =20 -----Original Message----- From: Ace > On = Behalf Of Ludwig Seitz Sent: Tuesday, May 8, 2018 3:54 AM To: ace@ietf.org =20 Subject: Re: [Ace] OAuth-Authz Interop =20 On 2018-05-08 08:57, Ludwig Seitz wrote: > On 2018-05-07 18:44, Jim Schaad wrote: >> I have been meaning to get this out for a while and have failed. A=20 >> doodle poll to setup an interop event for this work is at=20 >> = https://doodle.com/poll/k27g9r26bghvnytu If you want to participate=20 >> and none of the times are good please let me know. >>=20 >> Things for testing: >> 1) DTLS profile w/ shared secret >> 2) DTLS profile w/ RPK >> 3) OSCORE profile >>=20 >>=20 >=20 > Note that I'm in the process of writing a test manual, I'll put it up=20 > on the WG github as soon as it has some form and structure. Feel free=20 > to contribute. I'm hoping to have it online by the end of the day. >=20 > /Ludwig >=20 >=20 =20 You can find my first draft of the interop manual here: =20 = https://github.com/ace-wg/ace-oauth/blob/master/InteropTestPlan.txt =20 Note that large parts are still work in progress, but the test plan for = the token endpoint should give you a hint as to how I was thinking it = could work. =20 Feel free to propose changes and improvements. =20 =20 /Ludwig =20 -- Ludwig Seitz, PhD Security Lab, RISE SICS Phone +46(0)70-349 92 51 =20 _______________________________________________ Ace mailing list Ace@ietf.org = https://www.ietf.org/mailman/listinfo/ace ------=_NextPart_000_00CC_01D3E856.54FB8E80 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Given that we have already started doing interop work = and were successful needing to address the number assignment issues does = not seem to be a blocking problem.=C2=A0 As long as all of the people = doing the interop testing are agreed on what numbers should be there do = not seem to be any issues in testing.=C2=A0 The only problem would be if = there was a decision to ship products before the assignments were = finalized.=C2=A0

 

In terms of = what size of items to use, this is going to be an interesting argument = and one that needs to be finalized at some point.=C2=A0 However, it = would be just as easy to remove the sentence as to change the values so = there are multiple ways of solving this issue.=C2=A0 I don=E2=80=99t = know that I agree that application-specific claim keys should be pushed = all of the way up to 256, there is always going to be a trade off at = this point in terms of what size of key to use vs how often it is = believed that the key is going to be used.=C2=A0 If we believe that a = huge percentage of usage in the IoT world for CWT items is going to be = for this type of authorization and we want to keep alignment to the = extent possible then it still makes sense to use the 1 or 2 byte keys = for this purpose.=C2=A0 (Side node, it is normal to include all of the = bytes encoded in the length so 256 would be a 3 byte value).=C2=A0 This = is a trade off that needs to be discussed, but is not currently = blocking.

 

Jim

 

 

From: Ace = <ace-bounces@ietf.org> On Behalf Of Mike = Jones
Sent: Tuesday, May 8, 2018 10:40 AM
To: Ludwig = Seitz <ludwig.seitz@ri.se>; ace@ietf.org
Subject: Re: = [Ace] OAuth-Authz Interop

 

Before = any interop work is done, I suggest that it would be better to first = address the significant CBOR number assignment issues I pointed out in = my review on October 10, 2017 = https://www.ietf.org/mail-archive/web/ace/current/msg02364.html, so = that the interop is more likely to occur using number assignments that = are less likely to change.  I'm repeating the most important of = these comments below, since it was apparently not acted = upon.

 

5.5.5 Mapping parameters to = CBOR

It = looks to me like these values are intended to align with those = registered in the CBOR Web Token (CWT) Claims registry initially = populated by https://tools.ietf.org/html/draft-ietf-ace-cbor-web-token-08#s= ection-9.1.2.  If so, the spec should make this relationship = explicit.  However, it would be inappropriate to use the rare = single-byte CBOR integer values for application-specific claim = keys.  I would suggest that the claim identifiers for client_id = through refresh_token and profile start at 256 (a two-byte CBOR value) = and go up from there.  In that case, I suspect they could be = successfully registered in the CWT Claims registry =E2=80=93 which I = think you want.  (=E2=80=9Ccnf=E2=80=9D will already be registered = by draft-ietf-ace-cwt-proof-of-possession.)

 

Likewise, please search the review for all = instances of the words =E2=80=9Cregister=E2=80=9D and = =E2=80=9Cregistry=E2=80=9D and revised the spec accordingly before any = interop work is started.

 

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

 

 

-----Original Message-----
From: Ace <ace-bounces@ietf.org> On = Behalf Of Ludwig Seitz
Sent: Tuesday, May 8, 2018 3:54 AM
To: ace@ietf.org
Subject: Re: [Ace] = OAuth-Authz Interop

 

On = 2018-05-08 08:57, Ludwig Seitz wrote:

> On 2018-05-07 18:44, Jim Schaad = wrote:

>> I have been = meaning to get this out for a while and have failed.  A =

>> doodle poll to setup an = interop event for this work is at

>> https://doodle.com/poll/k= 27g9r26bghvnytu If you want to participate

>> and none of the times are good please let = me know.

>> 

>> Things for testing:

>> 1)  DTLS profile w/ shared = secret

>> 2)  DTLS = profile w/ RPK

>> 3)  = OSCORE profile

>> 

>> 

>

> = Note that I'm in the process of writing a test manual, I'll put it up =

> on the WG github as soon as = it has some form and structure. Feel free

> to contribute. I'm hoping to have it online by = the end of the day.

> =

> /Ludwig

>

> =

 

You can find my first draft of the interop manual = here:

 

https://github.com/ace-wg= /ace-oauth/blob/master/InteropTestPlan.txt

 

Note = that large parts are still work in progress, but the test plan for the = token endpoint should give you a hint as to how I was thinking it could = work.

 

Feel free to propose changes and = improvements.

 

 

/Ludwig

 

--

Ludwig = Seitz, PhD

Security Lab, RISE = SICS

Phone +46(0)70-349 92 = 51

 

_______________________________________________=

Ace mailing list

Ace@ietf.org

https://www.ietf.org/mail= man/listinfo/ace

------=_NextPart_000_00CC_01D3E856.54FB8E80-- From nobody Thu May 10 13:00:32 2018 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C71412DA11 for ; Thu, 10 May 2018 13:00:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, 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 LUz_7K8X20ZY for ; Thu, 10 May 2018 13:00:20 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0095.outbound.protection.outlook.com [104.47.37.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 6ADEB127869 for ; Thu, 10 May 2018 13:00:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=lryx762WmkVl9ePqV5e5LHD26qZO1I1yW5BvIJ//xyU=; b=IooE/wwNPu9SPxibpOKAxjUx7PNBREVPhVr2FvgkY0+Cc2eoNwnIXOEJOpcVBhma6NCN9H1p7+MGHPVyOjI4Xz1oycMQTI6HX1HHEdHA7vCN66e5JVeF+gHwMAOhCurIj5atQvCPvbG0ACSOVhFmjY3AD7tbkgksrt9JQpmYuN4= Received: from BL0PR00MB0292.namprd00.prod.outlook.com (2603:10b6:207:1e::30) by BL0PR00MB0340.namprd00.prod.outlook.com (2603:10b6:207:1f::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.793.0; Thu, 10 May 2018 20:00:16 +0000 Received: from BL0PR00MB0292.namprd00.prod.outlook.com ([fe80::84a0:cb3c:39ec:1b01]) by BL0PR00MB0292.namprd00.prod.outlook.com ([fe80::84a0:cb3c:39ec:1b01%5]) with mapi id 15.20.0796.000; Thu, 10 May 2018 20:00:16 +0000 From: Mike Jones To: Jim Schaad , 'Ludwig Seitz' , "ace@ietf.org" Thread-Topic: [Ace] OAuth-Authz Interop Thread-Index: AdPmIm8GwlgNR4Z4TAKB3oF5AiJBnQAd1sgAAAhBu4AADchQsABnwz4AAAHS8+A= Date: Thu, 10 May 2018 20:00:15 +0000 Message-ID: References: <005601d3e622$af427100$0dc75300$@augustcellars.com> <7af7e847-bc7a-82ff-2024-7321575450d8@ri.se> <00cb01d3e891$0158b8d0$040a2a70$@augustcellars.com> In-Reply-To: <00cb01d3e891$0158b8d0$040a2a70$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=mbj@microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2018-05-10T20:00:13.6128017Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic; Sensitivity=General x-originating-ip: [2001:4898:80e8:a::145] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BL0PR00MB0340; 7:z7NVatEwhXnxjM4N6nLCl+0rbd0EgJWLHAClLVqEIzfBonc8xpKydVgW+7OtfebG+S4E9yTjovAgP5Ms5tk41GLTi5Zs0FzH4O55zRQyQ7DH4bItYVOJaS2dzJEyjO1kcUkF29o6I0d9M6C2gUXrJVe3dgRkY6uROUkpNWRyzf/vVJiLL9aqwLEJ7h9kz0Exu8Hyc6+eJnbnBB9AM0WOYT9uv/uQz/8xiBkhFmG1Z6UO4Z0bFamJFLvD5U71JKxx; 20:DNKVCI8SyKyxtAxNrRHwlNpfUSTaiTVZwCNfgvkdAXHxrVffddr9GlGNrSI+hvzkboenxEv87s1hj+iUPsB6iZG56C1AhAvY+YMwwkoM0hejUfhMzVP1xMYCjN9RKy4QjciRt9EvY3iVIiSOb62weJsvBkDHNLhp2iQvEIJ48QQ= x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7193020); SRVR:BL0PR00MB0340; x-ms-traffictypediagnostic: BL0PR00MB0340: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(89211679590171)(166708455590820)(209352067349851)(192374486261705)(60409825278598)(21748063052155); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(2017102700009)(2017102701064)(6040522)(2401047)(8121501046)(5005006)(2017102702064)(20171027021009)(20171027022009)(20171027023009)(20171027024009)(20171027025009)(20171027026009)(2017102703076)(3002001)(93006095)(93001095)(10201501046)(3231254)(2018427008)(944501410)(52105095)(6055026)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(20161123558120)(20161123562045)(6072148)(201708071742011); SRVR:BL0PR00MB0340; BCL:0; PCL:0; RULEID:; SRVR:BL0PR00MB0340; x-forefront-prvs: 066898046A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(39380400002)(39860400002)(346002)(376002)(396003)(69234005)(377424004)(199004)(189003)(13464003)(478600001)(966005)(72206003)(10290500003)(10090500001)(2906002)(229853002)(6436002)(99286004)(25786009)(33656002)(316002)(68736007)(6246003)(53936002)(110136005)(22452003)(86362001)(86612001)(2900100001)(186003)(5660300001)(55016002)(6306002)(8990500004)(74316002)(236005)(9686003)(54896002)(97736004)(21615005)(46003)(3280700002)(486006)(476003)(93886005)(11346002)(446003)(14454004)(2501003)(6506007)(53546011)(102836004)(106356001)(790700001)(6116002)(52396003)(7696005)(76176011)(105586002)(5250100002)(606006)(8936002)(3660700001)(8676002)(81156014)(81166006)(59450400001)(7736002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL0PR00MB0340; H:BL0PR00MB0292.namprd00.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: N8phewkZFliibJ4GdCOughrZr6l+/z8LAKqktoXuML/Q10i2HvIvMNMxPdV3bcWJtHrVd6+UC6UY85v1GdXBhfuCpcNNJzsdU3ioIc/wt9qeInrnGIv+kWX8cyizZM5A6wqXPAq66oPzFDQeEIymMrBRMGneyH0RK3n3e+qXZYA/Y9+94KGbn1r6FaVh2KWV spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BL0PR00MB0292D757C78D626AD8806135F5980BL0PR00MB0292namp_" MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 51bcd786-1bde-416d-ebc0-08d5b6b0a61f X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 51bcd786-1bde-416d-ebc0-08d5b6b0a61f X-MS-Exchange-CrossTenant-originalarrivaltime: 10 May 2018 20:00:16.0082 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR00MB0340 Archived-At: Subject: Re: [Ace] OAuth-Authz Interop X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2018 20:00:28 -0000 --_000_BL0PR00MB0292D757C78D626AD8806135F5980BL0PR00MB0292namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RllJLCBJIGhhdmVu4oCZdCBzZWVuIGFueSBkaXNjdXNzaW9uIG9uIG15IHJldmlldyBjb21tZW50 IHRoYXQgdGhlc2UgdmFsdWVzIHNob3VsZCBiZSByZWdpc3RlcmVkIGFzIENXVCBjbGFpbXMgaWYg Y29udGludWVkIGFsaWdubWVudCBvZiB2YWx1ZXMgaXMgZGVzaXJlZC4gIENlcnRhaW5seSB0aGUg ZHJhZnQgaGFzbuKAmXQgZG9uZSB0aGF0LiAgRG8gcGVvcGxlIHNlZSB0aGlzIGFsaWdubWVudCBh cyB2YWx1YWJsZT8NCg0KV2hhdCB2YWx1ZXMgdG8gcmVxdWVzdCBmb3IgYXBwbGljYXRpb24tc3Bl Y2lmaWMgY2xhaW1zIGlzIGEgcmVsYXRlZCwgYnV0IGRpZmZlcmVudCBpc3N1ZS4gIEkgY291bGQg bGl2ZSB3aXRoIHVzaW5nIHNvbWUgb2YgdGhlIDItYnl0ZSBzcGFjZSDigJMgcG9zc2libHkgcmVx dWVzdGluZyBhbGxvY2F0aW9ucyBmcm9tIDI1NSBkb3duIGZvciB0aG9zZSB0aGF0IGFyZSBleHBl Y3RlZCB0byBiZSBjb21tb25seSB1c2VkIGFuZCBoYXZpbmcgdGhlIHVuY29tbW9uIHZhbHVlcyBi ZSBpbiB0aGUgMy1ieXRlIHNwYWNlLiAgQnV0IHRoZSAxLWJ5dGUgc3BhY2UgY292ZXJpbmcgdGhl IHJhbmdlIDAtMzEgc2hvdWxkIGJlIHJlc2VydmVkIGZvciBjbGFpbXMgdGhhdCBhcmUgb2YgdHJ1 bHkgYnJvYWQgYXBwbGljYWJpbGl0eS4gIENhbiB0aGUgZHJhZnQgY2hhbmdlIHRoZSByZXF1ZXN0 ZWQgYXNzaWdubWVudHMgZm9yIGFwcGxpY2F0aW9uLXNwZWNpZmljIHZhbHVlcyB0byBhdCBsZWFz dCBtb3ZlIHRoZW0gb3V0IG9mIHRoZSBzaW5nbGUtYnl0ZSAwLTMxIHJhbmdlPw0KDQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg VGhhbmtzLA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIC0tIE1pa2UNCg0KRnJvbTogSmltIFNjaGFhZCA8aWV0ZkBhdWd1c3Rj ZWxsYXJzLmNvbT4NClNlbnQ6IFRodXJzZGF5LCBNYXkgMTAsIDIwMTggMTE6NTkgQU0NClRvOiBN aWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+OyAnTHVkd2lnIFNlaXR6JyA8 bHVkd2lnLnNlaXR6QHJpLnNlPjsgYWNlQGlldGYub3JnDQpTdWJqZWN0OiBSRTogW0FjZV0gT0F1 dGgtQXV0aHogSW50ZXJvcA0KDQpHaXZlbiB0aGF0IHdlIGhhdmUgYWxyZWFkeSBzdGFydGVkIGRv aW5nIGludGVyb3Agd29yayBhbmQgd2VyZSBzdWNjZXNzZnVsIG5lZWRpbmcgdG8gYWRkcmVzcyB0 aGUgbnVtYmVyIGFzc2lnbm1lbnQgaXNzdWVzIGRvZXMgbm90IHNlZW0gdG8gYmUgYSBibG9ja2lu ZyBwcm9ibGVtLiAgQXMgbG9uZyBhcyBhbGwgb2YgdGhlIHBlb3BsZSBkb2luZyB0aGUgaW50ZXJv cCB0ZXN0aW5nIGFyZSBhZ3JlZWQgb24gd2hhdCBudW1iZXJzIHNob3VsZCBiZSB0aGVyZSBkbyBu b3Qgc2VlbSB0byBiZSBhbnkgaXNzdWVzIGluIHRlc3RpbmcuICBUaGUgb25seSBwcm9ibGVtIHdv dWxkIGJlIGlmIHRoZXJlIHdhcyBhIGRlY2lzaW9uIHRvIHNoaXAgcHJvZHVjdHMgYmVmb3JlIHRo ZSBhc3NpZ25tZW50cyB3ZXJlIGZpbmFsaXplZC4NCg0KSW4gdGVybXMgb2Ygd2hhdCBzaXplIG9m IGl0ZW1zIHRvIHVzZSwgdGhpcyBpcyBnb2luZyB0byBiZSBhbiBpbnRlcmVzdGluZyBhcmd1bWVu dCBhbmQgb25lIHRoYXQgbmVlZHMgdG8gYmUgZmluYWxpemVkIGF0IHNvbWUgcG9pbnQuICBIb3dl dmVyLCBpdCB3b3VsZCBiZSBqdXN0IGFzIGVhc3kgdG8gcmVtb3ZlIHRoZSBzZW50ZW5jZSBhcyB0 byBjaGFuZ2UgdGhlIHZhbHVlcyBzbyB0aGVyZSBhcmUgbXVsdGlwbGUgd2F5cyBvZiBzb2x2aW5n IHRoaXMgaXNzdWUuICBJIGRvbuKAmXQga25vdyB0aGF0IEkgYWdyZWUgdGhhdCBhcHBsaWNhdGlv bi1zcGVjaWZpYyBjbGFpbSBrZXlzIHNob3VsZCBiZSBwdXNoZWQgYWxsIG9mIHRoZSB3YXkgdXAg dG8gMjU2LCB0aGVyZSBpcyBhbHdheXMgZ29pbmcgdG8gYmUgYSB0cmFkZSBvZmYgYXQgdGhpcyBw b2ludCBpbiB0ZXJtcyBvZiB3aGF0IHNpemUgb2Yga2V5IHRvIHVzZSB2cyBob3cgb2Z0ZW4gaXQg aXMgYmVsaWV2ZWQgdGhhdCB0aGUga2V5IGlzIGdvaW5nIHRvIGJlIHVzZWQuICBJZiB3ZSBiZWxp ZXZlIHRoYXQgYSBodWdlIHBlcmNlbnRhZ2Ugb2YgdXNhZ2UgaW4gdGhlIElvVCB3b3JsZCBmb3Ig Q1dUIGl0ZW1zIGlzIGdvaW5nIHRvIGJlIGZvciB0aGlzIHR5cGUgb2YgYXV0aG9yaXphdGlvbiBh bmQgd2Ugd2FudCB0byBrZWVwIGFsaWdubWVudCB0byB0aGUgZXh0ZW50IHBvc3NpYmxlIHRoZW4g aXQgc3RpbGwgbWFrZXMgc2Vuc2UgdG8gdXNlIHRoZSAxIG9yIDIgYnl0ZSBrZXlzIGZvciB0aGlz IHB1cnBvc2UuICAoU2lkZSBub2RlLCBpdCBpcyBub3JtYWwgdG8gaW5jbHVkZSBhbGwgb2YgdGhl IGJ5dGVzIGVuY29kZWQgaW4gdGhlIGxlbmd0aCBzbyAyNTYgd291bGQgYmUgYSAzIGJ5dGUgdmFs dWUpLiAgVGhpcyBpcyBhIHRyYWRlIG9mZiB0aGF0IG5lZWRzIHRvIGJlIGRpc2N1c3NlZCwgYnV0 IGlzIG5vdCBjdXJyZW50bHkgYmxvY2tpbmcuDQoNCkppbQ0KDQoNCkZyb206IEFjZSA8YWNlLWJv dW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmFjZS1ib3VuY2VzQGlldGYub3JnPj4gT24gQmVoYWxmIE9m IE1pa2UgSm9uZXMNClNlbnQ6IFR1ZXNkYXksIE1heSA4LCAyMDE4IDEwOjQwIEFNDQpUbzogTHVk d2lnIFNlaXR6IDxsdWR3aWcuc2VpdHpAcmkuc2U8bWFpbHRvOmx1ZHdpZy5zZWl0ekByaS5zZT4+ OyBhY2VAaWV0Zi5vcmc8bWFpbHRvOmFjZUBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbQWNlXSBP QXV0aC1BdXRoeiBJbnRlcm9wDQoNCg0KQmVmb3JlIGFueSBpbnRlcm9wIHdvcmsgaXMgZG9uZSwg SSBzdWdnZXN0IHRoYXQgaXQgd291bGQgYmUgYmV0dGVyIHRvIGZpcnN0IGFkZHJlc3MgdGhlIHNp Z25pZmljYW50IENCT1IgbnVtYmVyIGFzc2lnbm1lbnQgaXNzdWVzIEkgcG9pbnRlZCBvdXQgaW4g bXkgcmV2aWV3IG9uIE9jdG9iZXIgMTAsIDIwMTcgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbC1h cmNoaXZlL3dlYi9hY2UvY3VycmVudC9tc2cwMjM2NC5odG1sLCBzbyB0aGF0IHRoZSBpbnRlcm9w IGlzIG1vcmUgbGlrZWx5IHRvIG9jY3VyIHVzaW5nIG51bWJlciBhc3NpZ25tZW50cyB0aGF0IGFy ZSBsZXNzIGxpa2VseSB0byBjaGFuZ2UuICBJJ20gcmVwZWF0aW5nIHRoZSBtb3N0IGltcG9ydGFu dCBvZiB0aGVzZSBjb21tZW50cyBiZWxvdywgc2luY2UgaXQgd2FzIGFwcGFyZW50bHkgbm90IGFj dGVkIHVwb24uDQoNCg0KNS41LjUgTWFwcGluZyBwYXJhbWV0ZXJzIHRvIENCT1INCkl0IGxvb2tz IHRvIG1lIGxpa2UgdGhlc2UgdmFsdWVzIGFyZSBpbnRlbmRlZCB0byBhbGlnbiB3aXRoIHRob3Nl IHJlZ2lzdGVyZWQgaW4gdGhlIENCT1IgV2ViIFRva2VuIChDV1QpIENsYWltcyByZWdpc3RyeSBp bml0aWFsbHkgcG9wdWxhdGVkIGJ5IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1p ZXRmLWFjZS1jYm9yLXdlYi10b2tlbi0wOCNzZWN0aW9uLTkuMS4yLiAgSWYgc28sIHRoZSBzcGVj IHNob3VsZCBtYWtlIHRoaXMgcmVsYXRpb25zaGlwIGV4cGxpY2l0LiAgSG93ZXZlciwgaXQgd291 bGQgYmUgaW5hcHByb3ByaWF0ZSB0byB1c2UgdGhlIHJhcmUgc2luZ2xlLWJ5dGUgQ0JPUiBpbnRl Z2VyIHZhbHVlcyBmb3IgYXBwbGljYXRpb24tc3BlY2lmaWMgY2xhaW0ga2V5cy4gIEkgd291bGQg c3VnZ2VzdCB0aGF0IHRoZSBjbGFpbSBpZGVudGlmaWVycyBmb3IgY2xpZW50X2lkIHRocm91Z2gg cmVmcmVzaF90b2tlbiBhbmQgcHJvZmlsZSBzdGFydCBhdCAyNTYgKGEgdHdvLWJ5dGUgQ0JPUiB2 YWx1ZSkgYW5kIGdvIHVwIGZyb20gdGhlcmUuICBJbiB0aGF0IGNhc2UsIEkgc3VzcGVjdCB0aGV5 IGNvdWxkIGJlIHN1Y2Nlc3NmdWxseSByZWdpc3RlcmVkIGluIHRoZSBDV1QgQ2xhaW1zIHJlZ2lz dHJ5IOKAkyB3aGljaCBJIHRoaW5rIHlvdSB3YW50LiAgKOKAnGNuZuKAnSB3aWxsIGFscmVhZHkg YmUgcmVnaXN0ZXJlZCBieSBkcmFmdC1pZXRmLWFjZS1jd3QtcHJvb2Ytb2YtcG9zc2Vzc2lvbi4p DQoNCg0KDQpMaWtld2lzZSwgcGxlYXNlIHNlYXJjaCB0aGUgcmV2aWV3IGZvciBhbGwgaW5zdGFu Y2VzIG9mIHRoZSB3b3JkcyDigJxyZWdpc3RlcuKAnSBhbmQg4oCccmVnaXN0cnnigJ0gYW5kIHJl dmlzZWQgdGhlIHNwZWMgYWNjb3JkaW5nbHkgYmVmb3JlIGFueSBpbnRlcm9wIHdvcmsgaXMgc3Rh cnRlZC4NCg0KDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAtLSBNaWtlDQoNCg0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCkZyb206IEFjZSA8YWNlLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmFjZS1ib3Vu Y2VzQGlldGYub3JnPj4gT24gQmVoYWxmIE9mIEx1ZHdpZyBTZWl0eg0KU2VudDogVHVlc2RheSwg TWF5IDgsIDIwMTggMzo1NCBBTQ0KVG86IGFjZUBpZXRmLm9yZzxtYWlsdG86YWNlQGlldGYub3Jn Pg0KU3ViamVjdDogUmU6IFtBY2VdIE9BdXRoLUF1dGh6IEludGVyb3ANCg0KDQoNCk9uIDIwMTgt MDUtMDggMDg6NTcsIEx1ZHdpZyBTZWl0eiB3cm90ZToNCg0KPiBPbiAyMDE4LTA1LTA3IDE4OjQ0 LCBKaW0gU2NoYWFkIHdyb3RlOg0KDQo+PiBJIGhhdmUgYmVlbiBtZWFuaW5nIHRvIGdldCB0aGlz IG91dCBmb3IgYSB3aGlsZSBhbmQgaGF2ZSBmYWlsZWQuICBBDQoNCj4+IGRvb2RsZSBwb2xsIHRv IHNldHVwIGFuIGludGVyb3AgZXZlbnQgZm9yIHRoaXMgd29yayBpcyBhdA0KDQo+PiBodHRwczov L2Rvb2RsZS5jb20vcG9sbC9rMjdnOXIyNmJnaHZueXR1IElmIHlvdSB3YW50IHRvIHBhcnRpY2lw YXRlDQoNCj4+IGFuZCBub25lIG9mIHRoZSB0aW1lcyBhcmUgZ29vZCBwbGVhc2UgbGV0IG1lIGtu b3cuDQoNCj4+DQoNCj4+IFRoaW5ncyBmb3IgdGVzdGluZzoNCg0KPj4gMSkgIERUTFMgcHJvZmls ZSB3LyBzaGFyZWQgc2VjcmV0DQoNCj4+IDIpICBEVExTIHByb2ZpbGUgdy8gUlBLDQoNCj4+IDMp ICBPU0NPUkUgcHJvZmlsZQ0KDQo+Pg0KDQo+Pg0KDQo+DQoNCj4gTm90ZSB0aGF0IEknbSBpbiB0 aGUgcHJvY2VzcyBvZiB3cml0aW5nIGEgdGVzdCBtYW51YWwsIEknbGwgcHV0IGl0IHVwDQoNCj4g b24gdGhlIFdHIGdpdGh1YiBhcyBzb29uIGFzIGl0IGhhcyBzb21lIGZvcm0gYW5kIHN0cnVjdHVy ZS4gRmVlbCBmcmVlDQoNCj4gdG8gY29udHJpYnV0ZS4gSSdtIGhvcGluZyB0byBoYXZlIGl0IG9u bGluZSBieSB0aGUgZW5kIG9mIHRoZSBkYXkuDQoNCj4NCg0KPiAvTHVkd2lnDQoNCj4NCg0KPg0K DQoNCg0KWW91IGNhbiBmaW5kIG15IGZpcnN0IGRyYWZ0IG9mIHRoZSBpbnRlcm9wIG1hbnVhbCBo ZXJlOg0KDQoNCg0KaHR0cHM6Ly9naXRodWIuY29tL2FjZS13Zy9hY2Utb2F1dGgvYmxvYi9tYXN0 ZXIvSW50ZXJvcFRlc3RQbGFuLnR4dA0KDQoNCg0KTm90ZSB0aGF0IGxhcmdlIHBhcnRzIGFyZSBz dGlsbCB3b3JrIGluIHByb2dyZXNzLCBidXQgdGhlIHRlc3QgcGxhbiBmb3IgdGhlIHRva2VuIGVu ZHBvaW50IHNob3VsZCBnaXZlIHlvdSBhIGhpbnQgYXMgdG8gaG93IEkgd2FzIHRoaW5raW5nIGl0 IGNvdWxkIHdvcmsuDQoNCg0KDQpGZWVsIGZyZWUgdG8gcHJvcG9zZSBjaGFuZ2VzIGFuZCBpbXBy b3ZlbWVudHMuDQoNCg0KDQoNCg0KL0x1ZHdpZw0KDQoNCg0KLS0NCg0KTHVkd2lnIFNlaXR6LCBQ aEQNCg0KU2VjdXJpdHkgTGFiLCBSSVNFIFNJQ1MNCg0KUGhvbmUgKzQ2KDApNzAtMzQ5IDkyIDUx DQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K DQpBY2UgbWFpbGluZyBsaXN0DQoNCkFjZUBpZXRmLm9yZzxtYWlsdG86QWNlQGlldGYub3JnPg0K DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FjZQ0K --_000_BL0PR00MB0292D757C78D626AD8806135F5980BL0PR00MB0292namp_ 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 YW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0 eWxlMjINCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzAwMjA2MDt9DQouTXNvQ2hwRGVmYXVsdA0KCXtt c28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdv cmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4w aW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48 L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0i ZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9 ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8 L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIi Pg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJjb2xvcjojMDAyMDYwIj5GWUksIEkgaGF2ZW7igJl0IHNlZW4gYW55IGRpc2N1c3Np b24gb24gbXkgcmV2aWV3IGNvbW1lbnQgdGhhdCB0aGVzZSB2YWx1ZXMgc2hvdWxkIGJlIHJlZ2lz dGVyZWQgYXMgQ1dUIGNsYWltcyBpZiBjb250aW51ZWQgYWxpZ25tZW50IG9mIHZhbHVlcyBpcyBk ZXNpcmVkLiZuYnNwOyBDZXJ0YWlubHkgdGhlIGRyYWZ0IGhhc27igJl0IGRvbmUgdGhhdC4mbmJz cDsNCjxiPkRvIHBlb3BsZSBzZWUgdGhpcyBhbGlnbm1lbnQgYXMgdmFsdWFibGU/PC9iPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xv cjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+V2hhdCB2YWx1ZXMgdG8gcmVxdWVzdCBm b3IgYXBwbGljYXRpb24tc3BlY2lmaWMgY2xhaW1zIGlzIGEgcmVsYXRlZCwgYnV0IGRpZmZlcmVu dCBpc3N1ZS4mbmJzcDsgSSBjb3VsZCBsaXZlIHdpdGggdXNpbmcgc29tZSBvZiB0aGUgMi1ieXRl IHNwYWNlIOKAkyBwb3NzaWJseSByZXF1ZXN0aW5nIGFsbG9jYXRpb25zIGZyb20gMjU1IGRvd24g Zm9yIHRob3NlIHRoYXQgYXJlIGV4cGVjdGVkDQogdG8gYmUgY29tbW9ubHkgdXNlZCBhbmQgaGF2 aW5nIHRoZSB1bmNvbW1vbiB2YWx1ZXMgYmUgaW4gdGhlIDMtYnl0ZSBzcGFjZS4mbmJzcDsgQnV0 IHRoZSAxLWJ5dGUgc3BhY2UgY292ZXJpbmcgdGhlIHJhbmdlIDAtMzEgc2hvdWxkIGJlIHJlc2Vy dmVkIGZvciBjbGFpbXMgdGhhdCBhcmUgb2YgdHJ1bHkgYnJvYWQgYXBwbGljYWJpbGl0eS4mbmJz cDsgQ2FuIHRoZSBkcmFmdCBjaGFuZ2UgdGhlIHJlcXVlc3RlZCBhc3NpZ25tZW50cyBmb3IgYXBw bGljYXRpb24tc3BlY2lmaWMNCiB2YWx1ZXMgdG8gYXQgbGVhc3QgbW92ZSB0aGVtIG91dCBvZiB0 aGUgc2luZ2xlLWJ5dGUgMC0zMSByYW5nZT88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMw MDIwNjAiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVGhhbmtzLDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAy MDYwIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2 MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAw aW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiBKaW0gU2NoYWFkICZs dDtpZXRmQGF1Z3VzdGNlbGxhcnMuY29tJmd0OyA8YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXks IE1heSAxMCwgMjAxOCAxMTo1OSBBTTxicj4NCjxiPlRvOjwvYj4gTWlrZSBKb25lcyAmbHQ7TWlj aGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tJmd0OzsgJ0x1ZHdpZyBTZWl0eicgJmx0O2x1ZHdpZy5z ZWl0ekByaS5zZSZndDs7IGFjZUBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogW0Fj ZV0gT0F1dGgtQXV0aHogSW50ZXJvcDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+R2l2ZW4gdGhhdCB3ZSBoYXZlIGFscmVhZHkgc3RhcnRlZCBkb2luZyBpbnRlcm9wIHdv cmsgYW5kIHdlcmUgc3VjY2Vzc2Z1bCBuZWVkaW5nIHRvIGFkZHJlc3MgdGhlIG51bWJlciBhc3Np Z25tZW50IGlzc3VlcyBkb2VzIG5vdCBzZWVtIHRvIGJlIGEgYmxvY2tpbmcgcHJvYmxlbS4mbmJz cDsgQXMgbG9uZyBhcyBhbGwgb2YgdGhlIHBlb3BsZSBkb2luZyB0aGUgaW50ZXJvcCB0ZXN0aW5n IGFyZSBhZ3JlZWQgb24gd2hhdA0KIG51bWJlcnMgc2hvdWxkIGJlIHRoZXJlIGRvIG5vdCBzZWVt IHRvIGJlIGFueSBpc3N1ZXMgaW4gdGVzdGluZy4mbmJzcDsgVGhlIG9ubHkgcHJvYmxlbSB3b3Vs ZCBiZSBpZiB0aGVyZSB3YXMgYSBkZWNpc2lvbiB0byBzaGlwIHByb2R1Y3RzIGJlZm9yZSB0aGUg YXNzaWdubWVudHMgd2VyZSBmaW5hbGl6ZWQuJm5ic3A7DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+SW4gdGVybXMgb2Ygd2hhdCBzaXplIG9mIGl0ZW1zIHRvIHVzZSwgdGhpcyBpcyBnb2luZyB0 byBiZSBhbiBpbnRlcmVzdGluZyBhcmd1bWVudCBhbmQgb25lIHRoYXQgbmVlZHMgdG8gYmUgZmlu YWxpemVkIGF0IHNvbWUgcG9pbnQuJm5ic3A7IEhvd2V2ZXIsIGl0IHdvdWxkIGJlIGp1c3QgYXMg ZWFzeSB0byByZW1vdmUgdGhlIHNlbnRlbmNlIGFzIHRvIGNoYW5nZSB0aGUgdmFsdWVzIHNvIHRo ZXJlIGFyZSBtdWx0aXBsZQ0KIHdheXMgb2Ygc29sdmluZyB0aGlzIGlzc3VlLiZuYnNwOyBJIGRv buKAmXQga25vdyB0aGF0IEkgYWdyZWUgdGhhdCBhcHBsaWNhdGlvbi1zcGVjaWZpYyBjbGFpbSBr ZXlzIHNob3VsZCBiZSBwdXNoZWQgYWxsIG9mIHRoZSB3YXkgdXAgdG8gMjU2LCB0aGVyZSBpcyBh bHdheXMgZ29pbmcgdG8gYmUgYSB0cmFkZSBvZmYgYXQgdGhpcyBwb2ludCBpbiB0ZXJtcyBvZiB3 aGF0IHNpemUgb2Yga2V5IHRvIHVzZSB2cyBob3cgb2Z0ZW4gaXQgaXMgYmVsaWV2ZWQgdGhhdA0K IHRoZSBrZXkgaXMgZ29pbmcgdG8gYmUgdXNlZC4mbmJzcDsgSWYgd2UgYmVsaWV2ZSB0aGF0IGEg aHVnZSBwZXJjZW50YWdlIG9mIHVzYWdlIGluIHRoZSBJb1Qgd29ybGQgZm9yIENXVCBpdGVtcyBp cyBnb2luZyB0byBiZSBmb3IgdGhpcyB0eXBlIG9mIGF1dGhvcml6YXRpb24gYW5kIHdlIHdhbnQg dG8ga2VlcCBhbGlnbm1lbnQgdG8gdGhlIGV4dGVudCBwb3NzaWJsZSB0aGVuIGl0IHN0aWxsIG1h a2VzIHNlbnNlIHRvIHVzZSB0aGUgMSBvciAyIGJ5dGUga2V5cw0KIGZvciB0aGlzIHB1cnBvc2Uu Jm5ic3A7IChTaWRlIG5vZGUsIGl0IGlzIG5vcm1hbCB0byBpbmNsdWRlIGFsbCBvZiB0aGUgYnl0 ZXMgZW5jb2RlZCBpbiB0aGUgbGVuZ3RoIHNvIDI1NiB3b3VsZCBiZSBhIDMgYnl0ZSB2YWx1ZSku Jm5ic3A7IFRoaXMgaXMgYSB0cmFkZSBvZmYgdGhhdCBuZWVkcyB0byBiZSBkaXNjdXNzZWQsIGJ1 dCBpcyBub3QgY3VycmVudGx5IGJsb2NraW5nLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5KaW08 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBp biAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6 c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiBBY2UgJmx0OzxhIGhyZWY9Im1haWx0bzphY2UtYm91 bmNlc0BpZXRmLm9yZyI+YWNlLWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0Ow0KPGI+T24gQmVoYWxm IE9mIDwvYj5NaWtlIEpvbmVzPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIE1heSA4LCAyMDE4 IDEwOjQwIEFNPGJyPg0KPGI+VG86PC9iPiBMdWR3aWcgU2VpdHogJmx0OzxhIGhyZWY9Im1haWx0 bzpsdWR3aWcuc2VpdHpAcmkuc2UiPmx1ZHdpZy5zZWl0ekByaS5zZTwvYT4mZ3Q7Ow0KPGEgaHJl Zj0ibWFpbHRvOmFjZUBpZXRmLm9yZyI+YWNlQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6 PC9iPiBSZTogW0FjZV0gT0F1dGgtQXV0aHogSW50ZXJvcDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+QmVmb3JlIGFueSBpbnRlcm9wIHdvcmsgaXMgZG9uZSwgSSBz dWdnZXN0IHRoYXQgaXQgd291bGQgYmUgYmV0dGVyIHRvIGZpcnN0IGFkZHJlc3MgdGhlIHNpZ25p ZmljYW50IENCT1IgbnVtYmVyIGFzc2lnbm1lbnQgaXNzdWVzIEkgcG9pbnRlZCBvdXQgaW4gbXkg cmV2aWV3IG9uIE9jdG9iZXIgMTAsIDIwMTcNCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3Jn L21haWwtYXJjaGl2ZS93ZWIvYWNlL2N1cnJlbnQvbXNnMDIzNjQuaHRtbCI+aHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9hY2UvY3VycmVudC9tc2cwMjM2NC5odG1sPC9hPiwg c28gdGhhdCB0aGUgaW50ZXJvcCBpcyBtb3JlIGxpa2VseSB0byBvY2N1ciB1c2luZyBudW1iZXIg YXNzaWdubWVudHMgdGhhdCBhcmUgbGVzcyBsaWtlbHkgdG8gY2hhbmdlLiZuYnNwOyBJJ20gcmVw ZWF0aW5nDQogdGhlIG1vc3QgaW1wb3J0YW50IG9mIHRoZXNlIGNvbW1lbnRzIGJlbG93LCBzaW5j ZSBpdCB3YXMgYXBwYXJlbnRseSBub3QgYWN0ZWQgdXBvbi48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjUuNS41IE1hcHBpbmcgcGFyYW1ldGVycyB0 byBDQk9SPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6LjVpbiI+SXQgbG9va3MgdG8gbWUgbGlrZSB0aGVzZSB2YWx1ZXMgYXJlIGludGVuZGVk IHRvIGFsaWduIHdpdGggdGhvc2UgcmVnaXN0ZXJlZCBpbiB0aGUgQ0JPUiBXZWIgVG9rZW4gKENX VCkgQ2xhaW1zIHJlZ2lzdHJ5IGluaXRpYWxseSBwb3B1bGF0ZWQgYnkNCjxhIGhyZWY9Imh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWFjZS1jYm9yLXdlYi10b2tlbi0wOCNz ZWN0aW9uLTkuMS4yIj4NCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWFj ZS1jYm9yLXdlYi10b2tlbi0wOCNzZWN0aW9uLTkuMS4yPC9hPi4mbmJzcDsgSWYgc28sIHRoZSBz cGVjIHNob3VsZCBtYWtlIHRoaXMgcmVsYXRpb25zaGlwIGV4cGxpY2l0LiZuYnNwOyBIb3dldmVy LCBpdCB3b3VsZCBiZSBpbmFwcHJvcHJpYXRlIHRvIHVzZSB0aGUgcmFyZSBzaW5nbGUtYnl0ZSBD Qk9SIGludGVnZXIgdmFsdWVzIGZvciBhcHBsaWNhdGlvbi1zcGVjaWZpYyBjbGFpbSBrZXlzLiZu YnNwOw0KIEkgd291bGQgc3VnZ2VzdCB0aGF0IHRoZSBjbGFpbSBpZGVudGlmaWVycyBmb3IgY2xp ZW50X2lkIHRocm91Z2ggcmVmcmVzaF90b2tlbiBhbmQgcHJvZmlsZSBzdGFydCBhdCAyNTYgKGEg dHdvLWJ5dGUgQ0JPUiB2YWx1ZSkgYW5kIGdvIHVwIGZyb20gdGhlcmUuJm5ic3A7IEluIHRoYXQg Y2FzZSwgSSBzdXNwZWN0IHRoZXkgY291bGQgYmUgc3VjY2Vzc2Z1bGx5IHJlZ2lzdGVyZWQgaW4g dGhlIENXVCBDbGFpbXMgcmVnaXN0cnkg4oCTIHdoaWNoIEkgdGhpbmsNCiB5b3Ugd2FudC4mbmJz cDsgKOKAnGNuZuKAnSB3aWxsIGFscmVhZHkgYmUgcmVnaXN0ZXJlZCBieSBkcmFmdC1pZXRmLWFj ZS1jd3QtcHJvb2Ytb2YtcG9zc2Vzc2lvbi4pPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi Pkxpa2V3aXNlLCBwbGVhc2Ugc2VhcmNoIHRoZSByZXZpZXcgZm9yIGFsbCBpbnN0YW5jZXMgb2Yg dGhlIHdvcmRzIOKAnHJlZ2lzdGVy4oCdIGFuZCDigJxyZWdpc3RyeeKAnSBhbmQgcmV2aXNlZCB0 aGUgc3BlYyBhY2NvcmRpbmdseSBiZWZvcmUgYW55IGludGVyb3Agd29yayBpcyBzdGFydGVkLjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgLS0gTWlrZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPi0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tPGJyPg0KRnJvbTogQWNlICZsdDs8YSBocmVmPSJtYWlsdG86YWNlLWJvdW5jZXNAaWV0 Zi5vcmciPmFjZS1ib3VuY2VzQGlldGYub3JnPC9hPiZndDsgT24gQmVoYWxmIE9mIEx1ZHdpZyBT ZWl0ejxicj4NClNlbnQ6IFR1ZXNkYXksIE1heSA4LCAyMDE4IDM6NTQgQU08YnI+DQpUbzogPGEg aHJlZj0ibWFpbHRvOmFjZUBpZXRmLm9yZyI+YWNlQGlldGYub3JnPC9hPjxicj4NClN1YmplY3Q6 IFJlOiBbQWNlXSBPQXV0aC1BdXRoeiBJbnRlcm9wPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPk9uIDIwMTgtMDUtMDggMDg6NTcsIEx1ZHdpZyBTZWl0eiB3cm90ZTo8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgT24gMjAxOC0wNS0wNyAxODo0NCwgSmlt IFNjaGFhZCB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZn dDsmZ3Q7IEkgaGF2ZSBiZWVuIG1lYW5pbmcgdG8gZ2V0IHRoaXMgb3V0IGZvciBhIHdoaWxlIGFu ZCBoYXZlIGZhaWxlZC4mbmJzcDsgQQ0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mZ3Q7Jmd0OyBkb29kbGUgcG9sbCB0byBzZXR1cCBhbiBpbnRlcm9wIGV2ZW50IGZv ciB0aGlzIHdvcmsgaXMgYXQNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jmd0OyZndDsgPGEgaHJlZj0iaHR0cHM6Ly9kb29kbGUuY29tL3BvbGwvazI3ZzlyMjZiZ2h2 bnl0dSI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUi Pmh0dHBzOi8vZG9vZGxlLmNvbS9wb2xsL2syN2c5cjI2Ymdodm55dHU8L3NwYW4+PC9hPiBJZiB5 b3Ugd2FudCB0byBwYXJ0aWNpcGF0ZQ0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mZ3Q7Jmd0OyBhbmQgbm9uZSBvZiB0aGUgdGltZXMgYXJlIGdvb2QgcGxlYXNlIGxl dCBtZSBrbm93LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZn dDs8bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7 IFRoaW5ncyBmb3IgdGVzdGluZzo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPiZndDsmZ3Q7IDEpJm5ic3A7IERUTFMgcHJvZmlsZSB3LyBzaGFyZWQgc2VjcmV0PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyAyKSZuYnNwOyBEVExT IHByb2ZpbGUgdy8gUlBLPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m Z3Q7Jmd0OyAzKSZuYnNwOyBPU0NPUkUgcHJvZmlsZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDs8bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZndDsmZ3Q7PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mZ3Q7IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ Jmd0OyBOb3RlIHRoYXQgSSdtIGluIHRoZSBwcm9jZXNzIG9mIHdyaXRpbmcgYSB0ZXN0IG1hbnVh bCwgSSdsbCBwdXQgaXQgdXANCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jmd0OyBvbiB0aGUgV0cgZ2l0aHViIGFzIHNvb24gYXMgaXQgaGFzIHNvbWUgZm9ybSBhbmQg c3RydWN0dXJlLiBGZWVsIGZyZWUNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jmd0OyB0byBjb250cmlidXRlLiBJJ20gaG9waW5nIHRvIGhhdmUgaXQgb25saW5lIGJ5 IHRoZSBlbmQgb2YgdGhlIGRheS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPiZndDsgPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IC9M dWR3aWc8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IDxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij5Zb3UgY2FuIGZpbmQgbXkgZmlyc3QgZHJhZnQgb2YgdGhlIGludGVyb3Ag bWFudWFsIGhlcmU6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxhIGhyZWY9Imh0dHBz Oi8vZ2l0aHViLmNvbS9hY2Utd2cvYWNlLW9hdXRoL2Jsb2IvbWFzdGVyL0ludGVyb3BUZXN0UGxh bi50eHQiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25l Ij5odHRwczovL2dpdGh1Yi5jb20vYWNlLXdnL2FjZS1vYXV0aC9ibG9iL21hc3Rlci9JbnRlcm9w VGVzdFBsYW4udHh0PC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Tm90 ZSB0aGF0IGxhcmdlIHBhcnRzIGFyZSBzdGlsbCB3b3JrIGluIHByb2dyZXNzLCBidXQgdGhlIHRl c3QgcGxhbiBmb3IgdGhlIHRva2VuIGVuZHBvaW50IHNob3VsZCBnaXZlIHlvdSBhIGhpbnQgYXMg dG8gaG93IEkgd2FzIHRoaW5raW5nIGl0IGNvdWxkIHdvcmsuPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPkZlZWwgZnJlZSB0byBwcm9wb3NlIGNoYW5nZXMgYW5kIGltcHJvdmVtZW50cy48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4vTHVkd2lnPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi Pi0tPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5MdWR3aWcgU2VpdHos IFBoRDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+U2VjdXJpdHkgTGFi LCBSSVNFIFNJQ1M8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlBob25l ICYjNDM7NDYoMCk3MC0zNDkgOTIgNTE8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+X19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkFjZSBtYWlsaW5nIGxpc3Q8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxhIGhyZWY9Im1haWx0bzpBY2VAaWV0Zi5vcmci PjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5BY2VA aWV0Zi5vcmc8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hY2UiPjxz cGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5odHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FjZTwvc3Bhbj48L2E+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_BL0PR00MB0292D757C78D626AD8806135F5980BL0PR00MB0292namp_-- From nobody Fri May 11 06:06:22 2018 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26A32126B7E for ; Fri, 11 May 2018 06:06:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LckzZJDtoXdf for ; Fri, 11 May 2018 06:06:19 -0700 (PDT) Received: from smtp-out11.electric.net (smtp-out11.electric.net [185.38.181.43]) (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 332C41201F2 for ; Fri, 11 May 2018 06:06:18 -0700 (PDT) Received: from 1fH7kV-0001fq-Vt by out11c.electric.net with emc1-ok (Exim 4.90_1) (envelope-from ) id 1fH7kW-0001hl-Tp; Fri, 11 May 2018 06:06:16 -0700 Received: by emcmailer; Fri, 11 May 2018 06:06:16 -0700 Received: from [194.218.146.197] (helo=sp-mail-2.sp.se) by out11c.electric.net with esmtps (TLSv1.2:ECDHE-RSA-AES128-SHA256:128) (Exim 4.90_1) (envelope-from ) id 1fH7kV-0001fq-Vt; Fri, 11 May 2018 06:06:15 -0700 Received: from [192.168.0.107] (10.116.0.226) by sp-mail-2.sp.se (10.100.0.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1261.35; Fri, 11 May 2018 15:06:15 +0200 To: Mike Jones , Jim Schaad , "ace@ietf.org" References: <005601d3e622$af427100$0dc75300$@augustcellars.com> <7af7e847-bc7a-82ff-2024-7321575450d8@ri.se> <00cb01d3e891$0158b8d0$040a2a70$@augustcellars.com> From: Ludwig Seitz Message-ID: Date: Fri, 11 May 2018 15:06:15 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [10.116.0.226] X-ClientProxiedBy: sp-mail-3.sp.se (10.100.0.163) To sp-mail-2.sp.se (10.100.0.162) X-Outbound-IP: 194.218.146.197 X-Env-From: ludwig.seitz@ri.se X-Proto: esmtps X-Revdns: X-HELO: sp-mail-2.sp.se X-TLS: TLSv1.2:ECDHE-RSA-AES128-SHA256:128 X-Authenticated_ID: X-PolicySMART: 14510320 X-Virus-Status: Scanned by VirusSMART (c) X-Virus-Status: Scanned by VirusSMART (s) Archived-At: Subject: Re: [Ace] OAuth-Authz Interop X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2018 13:06:21 -0000 On 2018-05-10 22:00, Mike Jones wrote: > FYI, I haven’t seen any discussion on my review comment that these > values should be registered as CWT claims if continued alignment of > values is desired.  Certainly the draft hasn’t done that. *Do people see > this alignment as valuable?* > Everything that is used as CWT claim is also registered as such, if it is not already registered. In our case that is just the "scope" claim (we will be adding a "profile" claim in the next iteration). However there are also OAuth token endpoint parameters and OAuth introspection parameters, that partially have the same names as CWT claims (and the same meaning). Those are registered in other respective registries. I have aligned the CBOR abbreviations for both claims and parameters of the same name (we obviously don't want an "aud" parameter in the access token request that abbreviates to 4 and an "aud" claim in a CWT that abbreviates to 5). Do you see any concrete mismatch in the current registrations? The IANA section has grown pretty large and an error might have slipped past our vigilance. /Ludwig -- Ludwig Seitz, PhD Security Lab, RISE SICS Phone +46(0)70-349 92 51 From nobody Mon May 14 02:05:52 2018 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5B5512D87C for ; Mon, 14 May 2018 02:05:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 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, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JTFr1ucQSqa2 for ; Mon, 14 May 2018 02:05:48 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0628.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe1e::628]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9903A12D7F0 for ; Mon, 14 May 2018 02:05:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=EctcV3SYBHprWuVJqeDEs7SWWUiTzqhjxdg678CupEg=; b=F75vY62fOU4SmCfLmj7BO3xrgTFSPmXO93Aib889Usyl7Lf1n5Iut2dFxyyQu3aXebDE3pbbNNt7sraDwAXsoo+/B421e8l5Z+dm3OlKBIk3AhGkMkb9W1SrLNJwzq22QjDxkDPIvGIsFDWRe7MbHyXkLzY0BEph97R7eV6D1dg= Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB2735.eurprd08.prod.outlook.com (10.166.198.28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.755.16; Mon, 14 May 2018 09:05:09 +0000 Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::7c43:c1a5:4f69:5365]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::7c43:c1a5:4f69:5365%17]) with mapi id 15.20.0755.018; Mon, 14 May 2018 09:05:09 +0000 From: Hannes Tschofenig To: "ace@ietf.org" Thread-Topic: EST over CoAP Thread-Index: AdPrYipD0kyce1IOREqwxYCd2nFDSg== Date: Mon, 14 May 2018 09:05:09 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [156.67.194.220] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0801MB2735; 7:zEGDcDum6Z6VWl9lIzr1zB6lWtTKqh+3hD1Y8sa47StA3L/D/auaRp1ExNKjbuXDeX6H7lFB1OA5lWG75nbXBWB5lXh5zM5Cawk585hXLoLB1Fl0NL8z9fZvp5y0VQ0iN8e1G4uqmu+KRBGBYUkQAptl6Mw7SIEp7aSLPttIRMpuZzkys6n3HowGSSvNHIeF+hHVDQbbSFl71Elg8RikXi3wNeFqVR0JsvaCii4aPZZI0q06J6Ok5Y1cuOmM/mXL x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(48565401081)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB2735; x-ms-traffictypediagnostic: VI1PR0801MB2735: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(158342451672863)(120809045254105)(21748063052155); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3231254)(944501410)(52105095)(93006095)(93001095)(3002001)(10201501046)(6055026)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123560045)(20161123562045)(20161123564045)(6072148)(201708071742011); SRVR:VI1PR0801MB2735; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0801MB2735; x-forefront-prvs: 067270ECAF x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(346002)(376002)(396003)(366004)(39380400002)(40434004)(189003)(199004)(53754006)(14454004)(6116002)(68736007)(3280700002)(3480700004)(8936002)(790700001)(8676002)(6916009)(81156014)(7116003)(5630700001)(5660300001)(3660700001)(1730700003)(81166006)(74316002)(2351001)(2906002)(7736002)(316002)(3846002)(99286004)(33656002)(7696005)(25786009)(72206003)(966005)(2900100001)(606006)(236005)(55016002)(53936002)(9686003)(54896002)(6306002)(478600001)(486006)(97736004)(106356001)(59450400001)(6506007)(102836004)(26005)(186003)(105586002)(2501003)(66066001)(476003)(6436002)(5640700003)(86362001)(5250100002)(5890100001); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB2735; H:VI1PR0801MB2112.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: LVdAXUrTMuHdvK3eE7GRiRc1VTMHd7vIMsdxQYdIo3CSn5BrSK+TcAaWvSFMLahy1z2qqDHBEhv8u5KRAajJzwm5p6Oce9SHW77O38bjWRQ27m4ybBBcnCOzIy/BP8AxClXaPxq4ErTQLUr0OtW+M3N+SyM+m7ygYzbJf+Z5W5kA9zWGzlBVF0ZauvxSlCaH spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_VI1PR0801MB21122D93F906F952E5E85C87FA9C0VI1PR0801MB2112_" MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 58eb49c7-919d-444b-13d0-08d5b979cb2b X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: 58eb49c7-919d-444b-13d0-08d5b979cb2b X-MS-Exchange-CrossTenant-originalarrivaltime: 14 May 2018 09:05:09.2166 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB2735 Archived-At: Subject: [Ace] EST over CoAP X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2018 09:05:51 -0000 --_000_VI1PR0801MB21122D93F906F952E5E85C87FA9C0VI1PR0801MB2112_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, At IETF#101 Peter presented a list of open issues with the EST over CoAP dr= aft, see https://datatracker.ietf.org/meeting/101/materials/slides-101-ace-est-over-= secure-coap-00 - Operational parameter values - Server side key generation using simple multipart encoding - Explain trust relations for http/coap proxying I have challenged the usefulness of the server-side key generation during t= he meeting but in general I am curious where we are with the document. It w= ould be great to get it finalized. It appears that we are adding new featur= es and therefore will not be able to complete the work in any reasonable ti= meframe. So, do we have a plan for how to complete the document? Ciao Hannes IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. --_000_VI1PR0801MB21122D93F906F952E5E85C87FA9C0VI1PR0801MB2112_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

At IETF#101 Peter presented a list of open issues wi= th the EST over CoAP draft, see

https://datatracker.ietf.= org/meeting/101/materials/slides-101-ace-est-over-secure-coap-00

 

-     &= nbsp;    Operational parameter values

-     &= nbsp;    Server side key generation using simple multipart e= ncoding

-     &= nbsp;    Explain trust relations for http/coap proxying=

 

I have challenged the usefulness of the server-side = key generation during the meeting but in general I am curious where we are = with the document. It would be great to get it finalized. It appears that w= e are adding new features and therefore will not be able to complete the work in any reasonable timeframe.

 

So, do we have a plan for how to complete the docume= nt?

 

Ciao

Hannes

 

IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in any medium. Thank you. --_000_VI1PR0801MB21122D93F906F952E5E85C87FA9C0VI1PR0801MB2112_-- From nobody Mon May 14 04:39:17 2018 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3888812DA13 for ; Mon, 14 May 2018 04:39:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JxBxg1epLxWC for ; Mon, 14 May 2018 04:39:15 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECEBA12DA2C for ; Mon, 14 May 2018 04:39:14 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 44E6C20090; Mon, 14 May 2018 07:51:21 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 8C1782674; Mon, 14 May 2018 07:38:54 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 889F8264F; Mon, 14 May 2018 07:38:54 -0400 (EDT) From: Michael Richardson To: Hannes Tschofenig cc: "ace\@ietf.org" In-Reply-To: References: X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Ace] EST over CoAP X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2018 11:39:17 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hannes Tschofenig wrote: > At IETF#101 Peter presented a list of open issues with the EST over C= oAP draft, see > https://datatracker.ietf.org/meeting/101/materials/slides-101-ace-est= -over-secure-coap-00 > - Operational parameter values > - Server side key generation using simple multipart encoding > - Explain trust relations for http/coap proxying > I have challenged the usefulness of the server-side key generation > during the meeting but in general I am curious where we are with the > document. It would be great to get it finalized. It appears that we a= re > adding new features and therefore will not be able to complete the wo= rk > in any reasonable timeframe. Server side key generation is not the only way to use this, and I'm not interested in it myself. I don't think we can do http/coap proxying in any meaningful way if we are using TLS/DTLS for the secure transport. I have encouraged my co-authors to either take it out, or realize that they are confusing the EST link (over DTLS) with the Registration Authority<->Certificate Authority link (over HTTPS). > So, do we have a plan for how to complete the document? I am implementing at this time, with CoAP over DTLS using OpenSSL today, and mbedTLS for the pledge side in a week or two. I believe that we can finish this document by the end of the summer. I don't think we'd get to WGLC before IETF102, and as August is a dead zone for IETF work, having a WGLC before September 1 would seem pointless. =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBWvl1S4CLcPvd0N1lAQK6IQf8CVV8kVhHAXOP7zHG/YuDfJ1gWjVRMFZB ltr/jy83TVinshYyZw7P7BvHN0anfTafyAjJoEnAalo3dTbphztzfUyQI4aMgS6O e9QgWCtm7szl+9rr2E1UNbrvTpZDeQ9ORb1oNKfDUr1VKnCnSqtMwVqiEI23hCzs Jp/QMagdgTF4DbLctQzeecMC1eVJM7gKjzDayEZhjkwxPOtvB/xkr9/fRdLi7VNx nQH5HvOOCVzf4ZlpJllkMYXv02q8CWJKy06zSSudwtHjrkea/i6Zli94vl+YMg7P yNHvz45wbXUXFWFb6DjtEe9E1ijxkvtUbljufuR4dzXaHH+cet4gWQ== =PJsx -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon May 14 04:53:42 2018 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 407D012DA13 for ; Mon, 14 May 2018 04:53:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 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, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M0DPWHhjf1C0 for ; Mon, 14 May 2018 04:53:38 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0078.outbound.protection.outlook.com [104.47.2.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 11B6B126D45 for ; Mon, 14 May 2018 04:53:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=/YdGVBIq5MyJT3/sWf7BuDKM5MKs85+m4LYQcJgDN1o=; b=lBShftwrEfjJ7z003ZTc8Jd5ubPJrutiQNXdDpi+iJc9NH8pVR3W9Hn1OBWM3zk3a68va6xsdx96mlaba01y9x+FztsMJgvC4N//UxizSrtddXw/MURlhpjH8ntA3mUYOJvDYMkAlcMiRp+Ehh65YvAOrUWM3DKO+VkinuUPnHs= Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB1869.eurprd08.prod.outlook.com (10.173.73.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.755.16; Mon, 14 May 2018 11:53:35 +0000 Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::7c43:c1a5:4f69:5365]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::7c43:c1a5:4f69:5365%17]) with mapi id 15.20.0755.018; Mon, 14 May 2018 11:53:35 +0000 From: Hannes Tschofenig To: Michael Richardson CC: "ace@ietf.org" Thread-Topic: [Ace] EST over CoAP Thread-Index: AdPrYipD0kyce1IOREqwxYCd2nFDSgAFfjAAAABx6qA= Date: Mon, 14 May 2018 11:53:35 +0000 Message-ID: References: <13072.1526297934@localhost> In-Reply-To: <13072.1526297934@localhost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [156.67.194.220] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0801MB1869; 7:PrIAVz9YHCfzE6Agdy8BtlpGI8abeEfLIyxp/oQCueFoPzIYSTAMlFGFcTLUf3LsFdBEtQgS+MAanlYS/hD8uBg08WUIeFTExgJkOUFYSN45JjVixO2a0zvRzRELArwJ8A9v37FSW5kBQwgMQyBR3PGjYtNIUflTo3MMH365+ieFWuzVPhNkiBXPbBjGjOtKWbKis6z10T1EJv4ONmbXAWM7GDY1rMvxt5JE8oKaCuYdLbFcIN0X+RiJDf+SvLhH x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB1869; x-ms-traffictypediagnostic: VI1PR0801MB1869: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(180628864354917)(120809045254105); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(3002001)(3231254)(944501410)(52105095)(10201501046)(6055026)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123562045)(20161123558120)(20161123560045)(6072148)(201708071742011); SRVR:VI1PR0801MB1869; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0801MB1869; x-forefront-prvs: 067270ECAF x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(346002)(39380400002)(39860400002)(366004)(396003)(40434004)(13464003)(51914003)(189003)(199004)(476003)(25786009)(446003)(11346002)(229853002)(66066001)(6436002)(14454004)(305945005)(486006)(105586002)(106356001)(33656002)(74316002)(7696005)(7736002)(99286004)(8936002)(81156014)(59450400001)(81166006)(3280700002)(76176011)(8676002)(68736007)(3660700001)(316002)(6246003)(5660300001)(97736004)(2906002)(55016002)(53936002)(2900100001)(6306002)(9686003)(3846002)(966005)(5890100001)(72206003)(6116002)(86362001)(6506007)(186003)(4326008)(5250100002)(26005)(53546011)(102836004)(478600001); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB1869; H:VI1PR0801MB2112.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: DGNUxblgvm0V4PXw/YThN+h2edft21cme2ArlVc6bXczlu3we+cvfGNdQw1x/wG0BOyCsikwOZCnPjiq3NLR7ptEBWpRbRIK5UOs9C49OlgiHanugiK1V90YAEf0Ey1TC0YTi9JxLsScS363W47f7QbIGyimKnNG5e8nJwsqJLvxGabH2n5QlWYmasiqphay spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 84e9d6ed-09ab-4b85-a748-08d5b99152e3 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: 84e9d6ed-09ab-4b85-a748-08d5b99152e3 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 May 2018 11:53:35.3903 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1869 Archived-At: Subject: Re: [Ace] EST over CoAP X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2018 11:53:41 -0000 Hi Michael, Thanks for the feedback. Why do you think it takes so long to get this document finished? In the end= , you are just carrying EST over CoAP instead of conveying it over HTTP. Ciao Hannes PS: Regarding the use of DTLS/TLS for the proxy. There are obviously ways t= o get this accomplished but the question for me is whether this functionali= ty should go into this version of the spec or rather a companion document. -----Original Message----- From: Michael Richardson [mailto:mcr+ietf@sandelman.ca] Sent: 14 May 2018 12:39 To: Hannes Tschofenig Cc: ace@ietf.org Subject: Re: [Ace] EST over CoAP Hannes Tschofenig wrote: > At IETF#101 Peter presented a list of open issues with the EST over C= oAP draft, see > https://datatracker.ietf.org/meeting/101/materials/slides-101-ace-est= -over-secure-coap-00 > - Operational parameter values > - Server side key generation using simple multipart encoding > - Explain trust relations for http/coap proxying > I have challenged the usefulness of the server-side key generation > during the meeting but in general I am curious where we are with the > document. It would be great to get it finalized. It appears that we a= re > adding new features and therefore will not be able to complete the wo= rk > in any reasonable timeframe. Server side key generation is not the only way to use this, and I'm not int= erested in it myself. I don't think we can do http/coap proxying in any meaningful way if we are = using TLS/DTLS for the secure transport. I have encouraged my co-authors t= o either take it out, or realize that they are confusing the EST link (over= DTLS) with the Registration Authority<->Certificate Authority link (over H= TTPS). > So, do we have a plan for how to complete the document? I am implementing at this time, with CoAP over DTLS using OpenSSL today, and mbedTLS for the pledge side in a week or two. I believe that we can finish this document by the end of the summer. I don't think we'd get to W= GLC before IETF102, and as August is a dead zone for IETF work, having a WG= LC before September 1 would seem pointless. -- ] Never tell me the odds! | ipv6 mesh network= s [ ] Michael Richardson, Sandelman Software Works | network architect= [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [ IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. From nobody Mon May 14 06:58:32 2018 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F4C5127241 for ; Mon, 14 May 2018 06:58:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3KXnrWswxR_y for ; Mon, 14 May 2018 06:58:28 -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 04D8D1241F3 for ; Mon, 14 May 2018 06:58:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16156; q=dns/txt; s=iport; t=1526306308; x=1527515908; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=Qe/nVXw+6hHQMW1dPryrojU3NIGBsVFwx0EV13b7u/I=; b=K3y21ms6dxs6zLfuBmKk8Dw/0Fro115I1daFPif+8mNrHxPakM79JCBH sNhoT0hGEuR9Xt6aVwXute3vuPtUYXsncoFmTSrZcVaLrXRmoJvNB4hXP IKh5CTizF1+gtBhn1wpq7eK9FjOTBIsIcBIKl9BT3yvghI4VXTDGmRg0P o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DmAAC9lfla/4gNJK1TCRkBAQEBAQE?= =?us-ascii?q?BAQEBAQEHAQEBAQGCTUsrYXsoCotsjG6BeYEPjjuEdxSBZAslhEcCgxEhNBg?= =?us-ascii?q?BAgEBAQEBAQJsHAyFKAEBAQQtQwIXAgEIEQQBASgHMhQJCAEBBAEJCQiDHYE?= =?us-ascii?q?bZA+sT4g9giIFhyh9gVQ/JWqDC4JvIgIDgSEJAQgKAQlMhR4Chx+JaoctCQK?= =?us-ascii?q?FZYU5gymBPhqDS4dUiVWGZwIREwGBJAEcOGFxcBU7gkODMQECh1yFPm8MjiO?= =?us-ascii?q?BH4EYAQE?= X-IronPort-AV: E=Sophos;i="5.49,400,1520899200"; d="scan'208,217";a="114205946" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 May 2018 13:58:23 +0000 Received: from XCH-RCD-008.cisco.com (xch-rcd-008.cisco.com [173.37.102.18]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id w4EDwM3q008469 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 14 May 2018 13:58:22 GMT Received: from xch-aln-010.cisco.com (173.36.7.20) by XCH-RCD-008.cisco.com (173.37.102.18) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Mon, 14 May 2018 08:58:22 -0500 Received: from xch-aln-010.cisco.com ([173.36.7.20]) by XCH-ALN-010.cisco.com ([173.36.7.20]) with mapi id 15.00.1320.000; Mon, 14 May 2018 08:58:22 -0500 From: "Panos Kampanakis (pkampana)" To: Hannes Tschofenig , "ace@ietf.org" Thread-Topic: EST over CoAP Thread-Index: AdPrYipD0kyce1IOREqwxYCd2nFDSgAKCPZw Date: Mon, 14 May 2018 13:58:22 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.219.197] Content-Type: multipart/alternative; boundary="_000_a4d27053f1d2431abee07d2597e14972XCHALN010ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Ace] EST over CoAP X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2018 13:58:30 -0000 --_000_a4d27053f1d2431abee07d2597e14972XCHALN010ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Hannes, To address your question about server-side key gen, below is the explanatio= n we have put in the draft already and will be in the next iteration ~~~~~~~~~~~~~ Constrained devices sometimes do not have the necessary hardware to generate statistically random numbers for private keys and DTLS ephemeral keys. Past experience has shown that cheap endpoints sometimes generate numbers which could allow someone to decrypt the communication or guess the private key and impersonate as the device. Studies have shown that the same keys are generated by the same model devices deployed on-line. Additionally, random number key generation is costly, thus energy draining. Even though the random numbers that constitute the identity/cert do not get generated often, an endpoint may not want to spend time and energy generating keypairs, and just ask for one from the server. In these scenarios, server-side key generation can be used. The client asks for the server or proxy to generate the private key and the certificate which is transferred back to the client in the server-side key generation response. ~~~~~~~~~~~~~ This is a need that we have heard from customers at Cisco. About the proxy-Registrar question, we already have made the change in the = working copy of the draft as well. We no longer call this functionality pro= xying, but instead use the concept of the registrar that terminates the con= nection and establishes the next one. We didn't add any new features in the doc after removing the BRSKI stuff. If you want an early preview to comment on, we can share the repository wit= h you. Panos From: Ace [mailto:ace-bounces@ietf.org] On Behalf Of Hannes Tschofenig Sent: Monday, May 14, 2018 5:05 AM To: ace@ietf.org Subject: [Ace] EST over CoAP Hi all, At IETF#101 Peter presented a list of open issues with the EST over CoAP dr= aft, see https://datatracker.ietf.org/meeting/101/materials/slides-101-ace-est-over-= secure-coap-00 - Operational parameter values - Server side key generation using simple multipart encoding - Explain trust relations for http/coap proxying I have challenged the usefulness of the server-side key generation during t= he meeting but in general I am curious where we are with the document. It w= ould be great to get it finalized. It appears that we are adding new featur= es and therefore will not be able to complete the work in any reasonable ti= meframe. So, do we have a plan for how to complete the document? Ciao Hannes IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. --_000_a4d27053f1d2431abee07d2597e14972XCHALN010ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Hannes, =

 

To address your questi= on about server-side key gen, below is the explanation we have put in the d= raft already and will be in the next iteration
~~~~~~~~~~~~~

&n= bsp;  Constrained devices sometimes do not have the necessary hardware= to

&n= bsp;  generate statistically random numbers for private keys and DTLS<= o:p>

&n= bsp;  ephemeral keys.  Past experience has shown that cheap endpo= ints

&n= bsp;  sometimes generate numbers which could allow someone to decrypt = the

&n= bsp;  communication or guess the private key and impersonate as the de= vice.

&n= bsp;  Studies have shown that the same keys are generated by the same = model

&n= bsp;  devices deployed on-line.

 

&n= bsp;  Additionally, random number key generation is costly, thus energ= y

&n= bsp;  draining.  Even though the random numbers that constitute t= he

&n= bsp;  identity/cert do not get generated often, an endpoint may not wa= nt to

&n= bsp;  spend time and energy generating keypairs, and just ask for one = from

&n= bsp;  the server.

 

&n= bsp;  In these scenarios, server-side key generation can be used. = ; The

&n= bsp;  client asks for the server or proxy to generate the private key = and

&n= bsp;  the certificate which is transferred back to the client in the

&n= bsp;  server-side key generation response.
~~~~~~~~~~~~~=

 

This is a need that we= have heard from customers at Cisco.

 

About the proxy-Regist= rar question, we already have made the change in the working copy of the dr= aft as well. We no longer call this functionality proxying, but instead use= the concept of the registrar that terminates the connection and establishes the next one.

 

We didn’t add an= y new features in the doc after removing the BRSKI stuff.  =

 

If you want an early p= review to comment on, we can share the repository with you.

 

Panos

 

From: Ace [mailto:ace-bounces@ietf.org] On= Behalf Of Hannes Tschofenig
Sent: Monday, May 14, 2018 5:05 AM
To: ace@ietf.org
Subject: [Ace] EST over CoAP

 

Hi all,

 

At IETF#101 Peter presented a l= ist of open issues with the EST over CoAP draft, see

http= s://datatracker.ietf.org/meeting/101/materials/slides-101-ace-est-over-secu= re-coap-00

 

-  =       Operational parameter v= alues

-  =       Server side key generat= ion using simple multipart encoding

-  =       Explain trust relations= for http/coap proxying

 

I have challenged the usefulnes= s of the server-side key generation during the meeting but in general I am = curious where we are with the document. It would be great to get it finaliz= ed. It appears that we are adding new features and therefore will not be able to complete the work in any reason= able timeframe.

 

So, do we have a plan for how t= o complete the document?

 

Ciao

Hannes

 

IMPORTANT NOTICE: The contents of= this email and any attachments are confidential and may also be privileged= . If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any othe= r person, use it for any purpose, or store or copy the information in any m= edium. Thank you.

--_000_a4d27053f1d2431abee07d2597e14972XCHALN010ciscocom_-- From nobody Mon May 14 07:14:36 2018 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B85F12D87D for ; Mon, 14 May 2018 07:14:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 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, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y2-6LRyhf2RY for ; Mon, 14 May 2018 07:14:32 -0700 (PDT) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-am5eur02on0605.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe07::605]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C18F712785F for ; Mon, 14 May 2018 07:14:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=pcYJxcRAkI9hUSX34kdKDzTdoiNqCXHXIpAzBP0d9Vo=; b=cwttJzlyl4ERNj5WqfyBHxdIlK8bE7SQ2pcsK+8Vr3Ii4kf3Ej7s0ClL7Z5xeHy8tNmnmT//XVOovbcjdVGoeuIblSyHqLUGmxrFN7WjqynEN/bkfA1uHhECQlDlN5tl8QPiIAPHtmZCI90DKEMdSJYczYukYmjnMUt02vCP7lA= Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB1853.eurprd08.prod.outlook.com (10.168.68.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.755.16; Mon, 14 May 2018 14:14:29 +0000 Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::7c43:c1a5:4f69:5365]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::7c43:c1a5:4f69:5365%17]) with mapi id 15.20.0755.018; Mon, 14 May 2018 14:14:29 +0000 From: Hannes Tschofenig To: "Panos Kampanakis (pkampana)" , "ace@ietf.org" Thread-Topic: EST over CoAP Thread-Index: AdPrYipD0kyce1IOREqwxYCd2nFDSgAKCPZwAACDJXA= Date: Mon, 14 May 2018 14:14:29 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [156.67.194.220] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0801MB1853; 7:2xZgP0oYcu0a4VD8ZfGrinQZ54sck0B+fHPDGnQByZiUuXUvZxASIqIjX5xkE8GbfHgKwSw8rQ8I1sbtSjEacZNkTk/tdIibbvmPZ4ElgqLOtjkHDv7qLP/r8ubOiIpkeVksYTdZp93hUyEycq2yeR/vMmM8nYBsFbeoL548AZoYaH9SKYToT/ONPTsD9IVVsYuimh1zFZ5QFiPEcoRlLspUhFtnKQPha9N7pjqEiRV+j7DRMR9V62B0C19JEcBN x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(48565401081)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB1853; x-ms-traffictypediagnostic: VI1PR0801MB1853: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(158342451672863)(120809045254105)(192374486261705)(95692535739014)(21748063052155); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3231254)(944501410)(52105095)(93006095)(93001095)(3002001)(10201501046)(6055026)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123562045)(20161123558120)(20161123560045)(6072148)(201708071742011); SRVR:VI1PR0801MB1853; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0801MB1853; x-forefront-prvs: 067270ECAF x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(346002)(376002)(396003)(39860400002)(39380400002)(53754006)(40434004)(189003)(199004)(316002)(6246003)(14454004)(229853002)(186003)(72206003)(236005)(6436002)(7696005)(55016002)(6306002)(99286004)(478600001)(54896002)(106356001)(59450400001)(33656002)(76176011)(53936002)(9686003)(446003)(8936002)(8676002)(7116003)(81166006)(81156014)(3480700004)(3280700002)(5660300001)(606006)(2501003)(26005)(86362001)(11346002)(25786009)(53546011)(102836004)(3660700001)(2900100001)(97736004)(476003)(66066001)(9326002)(966005)(790700001)(6116002)(3846002)(68736007)(7736002)(105586002)(110136005)(486006)(5250100002)(74316002)(6506007)(5890100001)(2906002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB1853; H:VI1PR0801MB2112.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: uwAahYyd9wForczxp0WiGcTn01JxDSANGoOmS3GCt+Zy1sbeueBbxrC5Jq3ODFcX9IoSb868DlL0uAcX9yM+CEfz08hz8xrRbLhKFAMod5jY6EnWC0eZI4O323y4nUqEyoAhW/GI5t9Xy9WK3kecjmkfALHWUe5GWhqP+5sAV+OVTR/y1t0YWRWA6Wp9dKMY spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_VI1PR0801MB21125B520BA3DE027A49AFA6FA9C0VI1PR0801MB2112_" MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 78aa9dea-574f-40e2-ceea-08d5b9a501be X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: 78aa9dea-574f-40e2-ceea-08d5b9a501be X-MS-Exchange-CrossTenant-originalarrivaltime: 14 May 2018 14:14:29.1723 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1853 Archived-At: Subject: Re: [Ace] EST over CoAP X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2018 14:14:35 -0000 --_000_VI1PR0801MB21125B520BA3DE027A49AFA6FA9C0VI1PR0801MB2112_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Panos, Thanks for sharing this info. Regarding the randomness requirement and the energy consumption. We have be= en a bit advocate for adding hardware-based random numbers to devices since= randomness is a basic requirement for most security protocols. You do not only need to have access to random numbers during key generation= but also later when you use nonces, a DH exchange, create session keys, an= d IVs, and potentially even for signature generation. If you use a protocol= that is not based on nonces then you may use one that relies on timestamps= , which may not make the story necessarily easier. Random number key generation is also not necessarily costly either (neither= in terms of energy cost nor in terms of hardware costs). Hence, I think you should consider the server-side key generation very care= fully since you are essentially destroying the benefits of public key crypt= o and introduce a big vulnerability. In a nutshell, I think you are better of recommending OEMs to select the ri= ght hardware for the given task. Ciao Hannes PS: For the proxy work (in context of DTLS/TLS) you might want to reach out= to your co-worker Owen Friel. From: Panos Kampanakis (pkampana) [mailto:pkampana@cisco.com] Sent: 14 May 2018 15:58 To: Hannes Tschofenig; ace@ietf.org Subject: RE: EST over CoAP Hi Hannes, To address your question about server-side key gen, below is the explanatio= n we have put in the draft already and will be in the next iteration ~~~~~~~~~~~~~ Constrained devices sometimes do not have the necessary hardware to generate statistically random numbers for private keys and DTLS ephemeral keys. Past experience has shown that cheap endpoints sometimes generate numbers which could allow someone to decrypt the communication or guess the private key and impersonate as the device. Studies have shown that the same keys are generated by the same model devices deployed on-line. Additionally, random number key generation is costly, thus energy draining. Even though the random numbers that constitute the identity/cert do not get generated often, an endpoint may not want to spend time and energy generating keypairs, and just ask for one from the server. In these scenarios, server-side key generation can be used. The client asks for the server or proxy to generate the private key and the certificate which is transferred back to the client in the server-side key generation response. ~~~~~~~~~~~~~ This is a need that we have heard from customers at Cisco. About the proxy-Registrar question, we already have made the change in the = working copy of the draft as well. We no longer call this functionality pro= xying, but instead use the concept of the registrar that terminates the con= nection and establishes the next one. We didn't add any new features in the doc after removing the BRSKI stuff. If you want an early preview to comment on, we can share the repository wit= h you. Panos From: Ace [mailto:ace-bounces@ietf.org] On Behalf Of Hannes Tschofenig Sent: Monday, May 14, 2018 5:05 AM To: ace@ietf.org Subject: [Ace] EST over CoAP Hi all, At IETF#101 Peter presented a list of open issues with the EST over CoAP dr= aft, see https://datatracker.ietf.org/meeting/101/materials/slides-101-ace-est-over-= secure-coap-00 - Operational parameter values - Server side key generation using simple multipart encoding - Explain trust relations for http/coap proxying I have challenged the usefulness of the server-side key generation during t= he meeting but in general I am curious where we are with the document. It w= ould be great to get it finalized. It appears that we are adding new featur= es and therefore will not be able to complete the work in any reasonable ti= meframe. So, do we have a plan for how to complete the document? Ciao Hannes IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. --_000_VI1PR0801MB21125B520BA3DE027A49AFA6FA9C0VI1PR0801MB2112_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Panos, <= /span>

 

Thanks for sharing thi= s info.

 

Regarding the randomne= ss requirement and the energy consumption. We have been a bit advocate for = adding hardware-based random numbers to devices since randomness is a basic= requirement for most security protocols.

You do not only need t= o have access to random numbers during key generation but also later when y= ou use nonces, a DH exchange, create session keys, and IVs, and potentially= even for signature generation. If you use a protocol that is not based on nonces then you may use one that relie= s on timestamps, which may not make the story necessarily easier.

 

Random number key gene= ration is also not necessarily costly either (neither in terms of energy co= st nor in terms of hardware costs).  

 

Hence, I think you sho= uld consider the server-side key generation very carefully since you are es= sentially destroying the benefits of public key crypto and introduce a big = vulnerability.

 

In a nutshell, I think= you are better of recommending OEMs to select the right hardware for the g= iven task.

 

Ciao=

Hannes

 

PS: For the proxy work= (in context of DTLS/TLS) you might want to reach out to your co-worker Owe= n Friel.

 

From: Panos Kampanakis (pkampana) [mailto:pkampana@cisco.co= m]
Sent: 14 May 2018 15:58
To: Hannes Tschofenig; ace@ietf.org
Subject: RE: EST over CoAP

 

Hi Hann= es,

&n= bsp;

To addr= ess your question about server-side key gen, below is the explanation we ha= ve put in the draft already and will be in the next iteration
~~~~~~~~~~~~~

   Constrained devices sometimes do not have the nec= essary hardware to

   generate statistically random numbers for private= keys and DTLS

   ephemeral keys.  Past experience has shown t= hat cheap endpoints

   sometimes generate numbers which could allow some= one to decrypt the

   communication or guess the private key and impers= onate as the device.

   Studies have shown that the same keys are generat= ed by the same model

   devices deployed on-line.

 

   Additionally, random number key generation is cos= tly, thus energy

   draining.  Even though the random numbers th= at constitute the

   identity/cert do not get generated often, an endp= oint may not want to

   spend time and energy generating keypairs, and ju= st ask for one from

   the server.

 

   In these scenarios, server-side key generation ca= n be used.  The

   client asks for the server or proxy to generate t= he private key and

   the certificate which is transferred back to the = client in the

   server-side key generation response.
~~~~~~~~~~~~~

&n= bsp;

This is= a need that we have heard from customers at Cisco.

&n= bsp;

About t= he proxy-Registrar question, we already have made the change in the working= copy of the draft as well. We no longer call this functionality proxying, = but instead use the concept of the registrar that terminates the connection and establishes the next one.

&n= bsp;

We didn= ’t add any new features in the doc after removing the BRSKI stuff. &n= bsp;

&n= bsp;

If you = want an early preview to comment on, we can share the repository with you.

&n= bsp;

Panos

&n= bsp;

From: Ace [mailto:ace-bounces= @ietf.org] On Behalf Of Hannes Tschofenig
Sent: Monday, May 14, 2018 5:05 AM
To: ace@ietf.org
Subject: [Ace] EST over CoAP

 

Hi all,

 

At IETF#101 Peter presented a list of open issues wi= th the EST over CoAP draft, see

https://datatracker.ietf.= org/meeting/101/materials/slides-101-ace-est-over-secure-coap-00

 

-        Operational parameter values

-        Server side key generation using simple multipart encoding

-        Explain trust relations for http/coap proxying

 

I have challenged the usefulness of the server-side = key generation during the meeting but in general I am curious where we are = with the document. It would be great to get it finalized. It appears that w= e are adding new features and therefore will not be able to complete the work in any reasonable timeframe.

 

So, do we have a plan for how to complete the docume= nt?

 

Ciao

Hannes

 

IMPORTANT NOTICE: The contents of th= is email and any attachments are confidential and may also be privileged. I= f you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, u= se it for any purpose, or store or copy the information in any medium. Than= k you.

IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in any medium. Thank you. --_000_VI1PR0801MB21125B520BA3DE027A49AFA6FA9C0VI1PR0801MB2112_-- From nobody Mon May 14 07:46:23 2018 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF78612E89F for ; Mon, 14 May 2018 07:46:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jv54yOEIeg_J for ; Mon, 14 May 2018 07:46:05 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA11E12E885 for ; Mon, 14 May 2018 07:46:05 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 47A6520090; Mon, 14 May 2018 10:58:12 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 0A4EA2B58; Mon, 14 May 2018 10:45:45 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 069912B47; Mon, 14 May 2018 10:45:45 -0400 (EDT) From: Michael Richardson To: Hannes Tschofenig cc: "ace\@ietf.org" In-Reply-To: References: <13072.1526297934@localhost> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Ace] EST over CoAP X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2018 14:46:11 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hannes Tschofenig wrote: > Thanks for the feedback. > Why do you think it takes so long to get this document finished? In t= he > end, you are just carrying EST over CoAP instead of conveying it over > HTTP. It's not really just us, it's time to get people to do the reviews required= :-) It's also constrained about getting other documents out. RFC8366 spent 4 weeks in AUTH48 due to a small YANG correction discovered at the last minut= e. (And we had to bikeshed the title) > PS: Regarding the use of DTLS/TLS for the proxy. There are obviously > ways to get this accomplished but the question for me is whether this > functionality should go into this version of the spec or rather a > companion document. I don't understand the use case. EST requires a secure transport from requesting entity to Registrar. A DTLS/TLS proxy represents a MITM, and I don't see a way for either party = to trust it. I have been pushing to better detail how people want this to w= ork. =2D-=20 Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBWvmhFoCLcPvd0N1lAQJXsgf+OylIB7knEn+5nemyy8R1wabMUTpVp+Fl eWpAn5uP0rUQAyPqweHhDVtU4MuO6+ZViQz2cx5LLmVnlnuKnHveVlxTw5kOdToE cz64IRk5coTfqTcPTlRbyI/uXf58hkMOR2QTVscUkp2iMXwy8tKOH5MZ86C/lG5a l712jkM++N8U4YjJ9j6eR2vhtJaEktWif4v8m0eYQWmY61LfdTXa7ZGdRG6SXGXe GO7HtBgi2g6lVdKo9Dl6GAzJoq9YwZGVCXkvZdr2MXB1y5b+Gr60P0XfXOjvG9mF MYkronQIPBZ8Yk5h1f4aQx9beLQ/yQJ4FJP/B4zuf/K2AUGXvwvvzQ== =OWbQ -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon May 14 07:51:41 2018 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68C5E12D94C for ; Mon, 14 May 2018 07:51:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 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, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u6UNFEL_Qnti for ; Mon, 14 May 2018 07:51:37 -0700 (PDT) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-am5eur02on0601.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe07::601]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3975C12D87F for ; Mon, 14 May 2018 07:51:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=xKAshjdtEW65awCF7bSIHk0/iXjIlm4zR+ZLzoO+lOY=; b=E9+uUYa3b0l5iM9Bl+ELqQ+C6cvUjUT22H0U1MiRyVmlYrpEJ2NnR8EYq0tIriVq57sKXqAUbiSAq5oVb7HTw9lOASTlTtvTULmwxwkW7A899eAP5fOG0F/g3j49zgZvSRLNkAul7CWXWAEqZRPq0vv2ehacIefLsZ54cArpi14= Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB1917.eurprd08.prod.outlook.com (10.173.73.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.755.16; Mon, 14 May 2018 14:51:34 +0000 Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::7c43:c1a5:4f69:5365]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::7c43:c1a5:4f69:5365%17]) with mapi id 15.20.0755.018; Mon, 14 May 2018 14:51:34 +0000 From: Hannes Tschofenig To: Michael Richardson CC: "ace@ietf.org" Thread-Topic: [Ace] EST over CoAP Thread-Index: AdPrYipD0kyce1IOREqwxYCd2nFDSgAFfjAAAABx6qAABhSogAAAGbcA Date: Mon, 14 May 2018 14:51:34 +0000 Message-ID: References: <13072.1526297934@localhost> <28208.1526309145@localhost> In-Reply-To: <28208.1526309145@localhost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [156.67.194.220] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0801MB1917; 7:JscHkcP00tCHONsZ2T9iaA0D2AWPx0uPTeaPwyCmHK+QylQbgsfrIUnA9p4Gm8EMv8bEDNF4+B81iWffqtiPUR1NRNhEUDYfdf3xDtbKEnhAQJr5lryGww9bq3JQ0ETtjFWEzsRZHUuypwgLYEZ3QebOKDvJGjnFvnRmu/MvhYl6nD43ANsI6js0kdBDJ+o9KPBqT6EqoPodPVJ1dqi3iJR+aGGyIj7H9MAPsPPkW7UW4Qf9VNFZDZ1PTVxO8nAk x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(48565401081)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB1917; x-ms-traffictypediagnostic: VI1PR0801MB1917: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(180628864354917); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3002001)(93006095)(93001095)(3231254)(944501410)(52105095)(10201501046)(6055026)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123562045)(20161123564045)(20161123560045)(6072148)(201708071742011); SRVR:VI1PR0801MB1917; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0801MB1917; x-forefront-prvs: 067270ECAF x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(366004)(39380400002)(396003)(346002)(376002)(13464003)(40434004)(199004)(189003)(51914003)(86362001)(7736002)(3280700002)(93886005)(105586002)(11346002)(53936002)(3846002)(6116002)(2906002)(6246003)(476003)(2900100001)(76176011)(53546011)(59450400001)(6436002)(72206003)(102836004)(106356001)(229853002)(6506007)(305945005)(3660700001)(7696005)(478600001)(5660300001)(26005)(97736004)(81166006)(8676002)(8936002)(25786009)(74316002)(316002)(81156014)(486006)(99286004)(5890100001)(5250100002)(186003)(446003)(66066001)(4326008)(14454004)(9686003)(33656002)(68736007)(55016002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB1917; H:VI1PR0801MB2112.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: iEfJo9ga5S+reALUM23N4wZSrKlWIX9NSYvjfDwrJ74jGhdpQxSaC+3p4alZ72oyuysOu+BifnSVStXU483pjGribHZ2feiafw5mO4/qyEIvHgnpVDNqpnNRq5KTCEfqzYojniQVBMpgYkQ02vpHabqXcYD5SEV6k1z5+4ozqmOzv7f1eUxmXORtOC+ap4b0 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: ddc95515-6662-4f75-4c57-08d5b9aa3017 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: ddc95515-6662-4f75-4c57-08d5b9aa3017 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 May 2018 14:51:34.3799 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1917 Archived-At: Subject: Re: [Ace] EST over CoAP X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2018 14:51:40 -0000 Hi Michael, -----Original Message----- From: Michael Richardson [mailto:mcr+ietf@sandelman.ca] Sent: 14 May 2018 16:46 To: Hannes Tschofenig Cc: ace@ietf.org Subject: Re: [Ace] EST over CoAP Hannes Tschofenig wrote: > Thanks for the feedback. > Why do you think it takes so long to get this document finished? In t= he > end, you are just carrying EST over CoAP instead of conveying it over > HTTP. It's not really just us, it's time to get people to do the reviews required= :-) It's also constrained about getting other documents out. RFC8366 spen= t 4 weeks in AUTH48 due to a small YANG correction discovered at the last m= inute. (And we had to bikeshed the title) [Hannes] Fully understand. I am just advocating that we keep things going a= t a reasonable pace. I have seen documents hanging around waiting for not f= urther defined events. Since we are implementing this functionality I want to make sure we don't s= ee surprises last minute. > PS: Regarding the use of DTLS/TLS for the proxy. There are obviously > ways to get this accomplished but the question for me is whether this > functionality should go into this version of the spec or rather a > companion document. I don't understand the use case. EST requires a secure transport from requesting entity to Registrar. A DTLS/TLS proxy represents a MITM, and I don't see a way for either party = to trust it. I have been pushing to better detail how people want this to w= ork. [Hannes] I guess we will speculate about it when that work gets started in = another document. Ciao Hannes -- Michael Richardson , Sandelman Software Works -=3D = IPv6 IoT consulting =3D- IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. From nobody Mon May 14 07:54:12 2018 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9821C12D94F for ; Mon, 14 May 2018 07:54:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9UiDaiY4urtV for ; Mon, 14 May 2018 07:54:09 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D1DA120227 for ; Mon, 14 May 2018 07:54:09 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 0D75120090 for ; Mon, 14 May 2018 11:06:16 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id C2CC92B58; Mon, 14 May 2018 10:53:48 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id BF3662B47 for ; Mon, 14 May 2018 10:53:48 -0400 (EDT) From: Michael Richardson To: "ace\@ietf.org" In-Reply-To: References: X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Ace] EST over CoAP X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2018 14:54:12 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hannes Tschofenig wrote: > Regarding the randomness requirement and the energy consumption. We > have been a bit advocate for adding hardware-based random numbers to > devices since randomness is a basic requirement for most security > protocols. I think that this is the future, and I very much agree with you. There seems to be a stock of older designs which have gone through other kinds of validation (for instance, think about the engineering review of physical cases and PCB design for electric metering). My impression is that there is a desire to significantly update the security profile of these devices (some of which are in the field already). What was deployed had poor security, or had proprietary protocols and there is a desire to move it up to "par". The other thing I hear is that the crypto libraries involved take some time to get FIPS-140 certified and so the one that the devices were deployed with do RSA only, and there is a desire to update them to ECDSA (or EdDSA), and means new keys. I think that any device with any kind of TPM would rather generate it's own keys. Whether it's a physical TPM, or some kind of TrustZone,etc. version. > In a nutshell, I think you are better of recommending OEMs to select > the right hardware for the given task. I'd like to find some text that acknowledges the past, while setting things up better for the future. > PS: For the proxy work (in context of DTLS/TLS) you might want to rea= ch > out to your co-worker Owen Friel. he's in other loops already, but he seems shy to post to lists. > IMPORTANT NOTICE: The contents of this email and any attachments are I wish your email system would omit this, as it's both meaningless and sometimes harmful. =2D-=20 Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBWvmi+YCLcPvd0N1lAQJFJAgAgMCNZczGtMyASZ8/8wwUAa56C3eAZmji rm4932f8hJnChcOgd/b9V9/qg4VDI2ZuGHKyvZFrfIGcRGI1Pu80JRbROz0of6XL 1FvAcwIEDWQU380CJCI34HPrPRfgU+9uEeNwZyQiWNIMpiCCmwEuh/7sv5F8ANHM BYmfTnurlhdWMjLaAxYZxIMO7p8nKrvvOo6dNT4QWUP6WXZz8YmhbU2ECQ/E4an/ BpmvHnD7QrH6I/QNPtlkyQJMi51SlE66Zc2vdJNe/PqwWqoCkgHXG0j+GN3OJFY3 rMEmOoAkZaqsMKzR4+vC8kACMKtm555UG/foaEDh/TVqBs20/IDhYA== =yvDw -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon May 14 11:49:16 2018 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2781E1276AF for ; Mon, 14 May 2018 11:49:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 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, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uIBRpEAvG-nb for ; Mon, 14 May 2018 11:49:11 -0700 (PDT) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10055.outbound.protection.outlook.com [40.107.1.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 B36921273E2 for ; Mon, 14 May 2018 11:49:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=7ZIHhCjJRsbmOgpe7FIuWi+gGGCUYH+l++KMaCml4+4=; b=WdiRzhMyw4yZA6fecEwO4QYo4PLYv7G7btEH3jN+SGVeugaSpQumhIw+BftjgxfKuLrsKI7ertldP4Ddy/1rBNKeng3RdKDPQ5AIUuT+ZY+AlhiyE/iWzip6OB+dzcXmLl0j33jCFfwNa1jRa9tb5Hmhln9Z4CiI44akHfvj3OE= Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB2127.eurprd08.prod.outlook.com (10.168.68.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.755.16; Mon, 14 May 2018 18:49:05 +0000 Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::7c43:c1a5:4f69:5365]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::7c43:c1a5:4f69:5365%17]) with mapi id 15.20.0755.018; Mon, 14 May 2018 18:49:05 +0000 From: Hannes Tschofenig To: Michael Richardson , "ace@ietf.org" Thread-Topic: [Ace] EST over CoAP Thread-Index: AdPrYipD0kyce1IOREqwxYCd2nFDSgAKCPZwAACDJXAAAcCgAAAAQuHQ Date: Mon, 14 May 2018 18:49:05 +0000 Message-ID: References: <30117.1526309628@localhost> In-Reply-To: <30117.1526309628@localhost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [156.67.194.220] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0801MB2127; 7:NNmiXQTR1T5ZW/OBn2MehjhdMt5RNxky5N422mxDas+KVlccLn/6GZlT9FPEnUO8lTXZdx28ApIC6bqUBzRCef/1DlAb3nVSrsFrC7Zw5SAz98Hy2lCGTeYN+FkFCbPnr/LeP86egnOD72fnMnvZ4wnls5VDKsADfoqop5mUcBf+4WsBDiX2DSLsuAB3FQuScb7vQRiOT92nKUkAi4/2jr57EyBy4SblQIkEGU3wpxHh6tDb9tNHvEnnoQPlZ4dH x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(48565401081)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB2127; x-ms-traffictypediagnostic: VI1PR0801MB2127: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(180628864354917)(192374486261705)(237425016533630); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3002001)(93006095)(93001095)(3231254)(944501410)(52105095)(10201501046)(6055026)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123562045)(20161123564045)(20161123560045)(6072148)(201708071742011); SRVR:VI1PR0801MB2127; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0801MB2127; x-forefront-prvs: 067270ECAF x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(366004)(376002)(39380400002)(396003)(39860400002)(13464003)(51444003)(189003)(199004)(40434004)(76176011)(11346002)(53546011)(53936002)(2501003)(81156014)(81166006)(26005)(99286004)(186003)(74316002)(8676002)(8936002)(7736002)(305945005)(55016002)(86362001)(68736007)(5250100002)(9686003)(6306002)(59450400001)(5890100001)(5660300001)(446003)(476003)(6506007)(7696005)(6246003)(25786009)(486006)(102836004)(93886005)(6116002)(3846002)(2906002)(6436002)(478600001)(2900100001)(33656002)(229853002)(14454004)(316002)(66066001)(110136005)(106356001)(97736004)(966005)(3280700002)(72206003)(3660700001)(105586002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB2127; H:VI1PR0801MB2112.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:3; A:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: kwf+ZcWXN4GvvxhyJ+TrA25uFfKyviHymHule8A9H7iZ+lv7Xb9KJlfiH89z0XSJ41IF2FHFCfT2NABDnb0jTGTx6Tc5RoyK6Uz8BsE3T6lCyaWtC2Jt8zpRTGgJblEE8yhQs853QYlPcIFv2QLU6JDFTcSV2u+2GfhC0lHW9UV+Qgwi4a7ZDCKKzazAczT7 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: baeac7bd-a766-4095-e0f3-08d5b9cb5e58 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: baeac7bd-a766-4095-e0f3-08d5b9cb5e58 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 May 2018 18:49:05.4238 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB2127 Archived-At: Subject: Re: [Ace] EST over CoAP X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2018 18:49:14 -0000 Here is my personal take on this: you have to do your threat assessment to = find out what attacks you care about. This will determine your hardware req= uirements (not the other way around). At a minimum you will have to figure = out how to provide randomness in your design and that can come at a very lo= w cost. For example, if I use ST's MCU finder http://www.st.com/en/developm= ent-tools/st-mcu-finder.html and search for microcontrollers that have TRNG= support then I get 410 results (only for STM MCUs). If you aim for devices that also provide ECC/RSA crypto in hardware + tampe= r-resistant key storage then we will move past the RFC 7228-type of constra= ined IoT device classes. You have can a look of what this means in context = of Arm IP: https://developer.arm.com/products/system-ip/trustzone-security-= ip On a meta-level I have difficulties with the security design decisions made= in IETF IoT-related groups since they swing back and forth between the ext= remes in pretty much no time. At the London IETF meeting I hear people talk= ing about drafting guidelines for the use of new crypto algorithms with IoT= devices since P256r1 and AES128-CCM is not good enough for them. At the sa= me time I am having a hard time convincing people that using an unauthentic= ated identifier is not good for security. Ciao Hannes -----Original Message----- From: Ace [mailto:ace-bounces@ietf.org] On Behalf Of Michael Richardson Sent: 14 May 2018 16:54 To: ace@ietf.org Subject: Re: [Ace] EST over CoAP Hannes Tschofenig wrote: > Regarding the randomness requirement and the energy consumption. We > have been a bit advocate for adding hardware-based random numbers to > devices since randomness is a basic requirement for most security > protocols. I think that this is the future, and I very much agree with you. There seems to be a stock of older designs which have gone through other ki= nds of validation (for instance, think about the engineering review of phys= ical cases and PCB design for electric metering). My impression is that there is a desire to significantly update the securit= y profile of these devices (some of which are in the field already). What = was deployed had poor security, or had proprietary protocols and there is a= desire to move it up to "par". The other thing I hear is that the crypto libraries involved take some time= to get FIPS-140 certified and so the one that the devices were deployed wi= th do RSA only, and there is a desire to update them to ECDSA (or EdDSA), a= nd means new keys. I think that any device with any kind of TPM would rather generate it's own= keys. Whether it's a physical TPM, or some kind of TrustZone,etc. version= . > In a nutshell, I think you are better of recommending OEMs to select > the right hardware for the given task. I'd like to find some text that acknowledges the past, while setting things= up better for the future. > PS: For the proxy work (in context of DTLS/TLS) you might want to rea= ch > out to your co-worker Owen Friel. he's in other loops already, but he seems shy to post to lists. > IMPORTANT NOTICE: The contents of this email and any attachments are I wish your email system would omit this, as it's both meaningless and some= times harmful. -- Michael Richardson , Sandelman Software Works -=3D = IPv6 IoT consulting =3D- IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. From nobody Mon May 14 12:24:22 2018 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C41C128D2E for ; Mon, 14 May 2018 12:24:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3VcHarLXNGJO for ; Mon, 14 May 2018 12:24:17 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E471128896 for ; Mon, 14 May 2018 12:24:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=25954; q=dns/txt; s=iport; t=1526325857; x=1527535457; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=rSBG8I+c4ur5iPPEWOBnFbYsqKt2H7eeGPIJb2Qx5eA=; b=LogcAlEqAats9sJEhl/gzHBgRlNN9YcnvZ4xTR36WEhZhyXaoSp7BmWY PKe2jDYLg6HAzArmY5IIfBsSyanlh426eNmMFu8bSYHwv4TZ20Oc1wc3A hVb/ZkWBdb2qo0jpVhTCAhZNCYSy+z2z+BKBIGXWzWN32vijUvlyq2Smi o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ANBAAW4fla/5ldJa1TCRkBAQEBAQE?= =?us-ascii?q?BAQEBAQEHAQEBAQGCTUsrYXsoCphdgXmBD5MyFIFkCyWERwKDESE1FwECAQE?= =?us-ascii?q?BAQEBAmwcDIUoAQEBAgItQwIXAgEIEQQBASEHBzIUCQgBAQQBCQkIgx2BG2Q?= =?us-ascii?q?PrWKIQoIiBYZyECZ9gVQ/JWqCDH+CbyICAQKBIQkBCAoBCUyFHgKHH4lqhy0?= =?us-ascii?q?JAoVlhTmDKYE+GoNLh1SJVYZnAhETAYEkAR4DM2FxcBU7gkODMQECgkiEWTu?= =?us-ascii?q?FPm8BC44mgR+BGAEB?= X-IronPort-AV: E=Sophos;i="5.49,401,1520899200"; d="scan'208,217";a="395164079" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 May 2018 19:24:15 +0000 Received: from XCH-RCD-006.cisco.com (xch-rcd-006.cisco.com [173.37.102.16]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id w4EJOFsk009475 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 14 May 2018 19:24:15 GMT Received: from xch-aln-010.cisco.com (173.36.7.20) by XCH-RCD-006.cisco.com (173.37.102.16) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Mon, 14 May 2018 14:24:15 -0500 Received: from xch-aln-010.cisco.com ([173.36.7.20]) by XCH-ALN-010.cisco.com ([173.36.7.20]) with mapi id 15.00.1320.000; Mon, 14 May 2018 14:24:15 -0500 From: "Panos Kampanakis (pkampana)" To: Hannes Tschofenig , "ace@ietf.org" Thread-Topic: EST over CoAP Thread-Index: AdPrYipD0kyce1IOREqwxYCd2nFDSgAKCPZwAACDJXAAAGyyQA== Date: Mon, 14 May 2018 19:24:15 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.219.197] Content-Type: multipart/alternative; boundary="_000_b1f75e92b9f34235b5922847e9595ad1XCHALN010ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Ace] EST over CoAP X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2018 19:24:21 -0000 --_000_b1f75e92b9f34235b5922847e9595ad1XCHALN010ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Your recommendation about having the right hardware is valid and what every= one should do as much as possible. What about Class 1 OEMs that cannot add = the hardware you are recommending? Or even the ones that will not comply wi= th the recommendations for their own reasons? We can't forget about those. Is the vulnerability that you were referring to that the RA or CA have to g= enerate the key? Trust of these entities needs to be established or this mo= del falls apart anyway. It is up to the admin to decide if it trusts the Re= gistrar will not store and reveal the private keys or generate insecure key= s on the device itself. I am more concerned about this vulnerability https:= //www.kb.cert.org/vuls/id/566724 where some thousands of devices have the s= ame identity and now they can all impersonate each other in my network as s= hown in https://jhalderm.com/pub/papers/https-imc13.pdf and https://factora= ble.net/paper.html We agree on the other ephemeral keys used in secure communications. Good ha= rdware would solve these issues. Without secure hardware some of these comm= unications could be decrypted assuming the right resources. Even though, de= crypting some data per connection is a concern, I don't think that the risk= is as high as a compromised identity. Also, the former concern does not me= an we should not have an option to eliminate the latter. About the Proxy section 6, I would like to see comments about in in the nex= t iteration, as we have updated to try to address some of these comments. From: Ace [mailto:ace-bounces@ietf.org] On Behalf Of Hannes Tschofenig Sent: Monday, May 14, 2018 10:14 AM To: Panos Kampanakis (pkampana) >; ace@ietf.org Subject: Re: [Ace] EST over CoAP Hi Panos, Thanks for sharing this info. Regarding the randomness requirement and the energy consumption. We have be= en a bit advocate for adding hardware-based random numbers to devices since= randomness is a basic requirement for most security protocols. You do not only need to have access to random numbers during key generation= but also later when you use nonces, a DH exchange, create session keys, an= d IVs, and potentially even for signature generation. If you use a protocol= that is not based on nonces then you may use one that relies on timestamps= , which may not make the story necessarily easier. Random number key generation is also not necessarily costly either (neither= in terms of energy cost nor in terms of hardware costs). Hence, I think you should consider the server-side key generation very care= fully since you are essentially destroying the benefits of public key crypt= o and introduce a big vulnerability. In a nutshell, I think you are better of recommending OEMs to select the ri= ght hardware for the given task. Ciao Hannes PS: For the proxy work (in context of DTLS/TLS) you might want to reach out= to your co-worker Owen Friel. From: Panos Kampanakis (pkampana) [mailto:pkampana@cisco.com] Sent: 14 May 2018 15:58 To: Hannes Tschofenig; ace@ietf.org Subject: RE: EST over CoAP Hi Hannes, To address your question about server-side key gen, below is the explanatio= n we have put in the draft already and will be in the next iteration ~~~~~~~~~~~~~ Constrained devices sometimes do not have the necessary hardware to generate statistically random numbers for private keys and DTLS ephemeral keys. Past experience has shown that cheap endpoints sometimes generate numbers which could allow someone to decrypt the communication or guess the private key and impersonate as the device. Studies have shown that the same keys are generated by the same model devices deployed on-line. Additionally, random number key generation is costly, thus energy draining. Even though the random numbers that constitute the identity/cert do not get generated often, an endpoint may not want to spend time and energy generating keypairs, and just ask for one from the server. In these scenarios, server-side key generation can be used. The client asks for the server or proxy to generate the private key and the certificate which is transferred back to the client in the server-side key generation response. ~~~~~~~~~~~~~ This is a need that we have heard from customers at Cisco. About the proxy-Registrar question, we already have made the change in the = working copy of the draft as well. We no longer call this functionality pro= xying, but instead use the concept of the registrar that terminates the con= nection and establishes the next one. We didn't add any new features in the doc after removing the BRSKI stuff. If you want an early preview to comment on, we can share the repository wit= h you. Panos From: Ace [mailto:ace-bounces@ietf.org] On Behalf Of Hannes Tschofenig Sent: Monday, May 14, 2018 5:05 AM To: ace@ietf.org Subject: [Ace] EST over CoAP Hi all, At IETF#101 Peter presented a list of open issues with the EST over CoAP dr= aft, see https://datatracker.ietf.org/meeting/101/materials/slides-101-ace-est-over-= secure-coap-00 - Operational parameter values - Server side key generation using simple multipart encoding - Explain trust relations for http/coap proxying I have challenged the usefulness of the server-side key generation during t= he meeting but in general I am curious where we are with the document. It w= ould be great to get it finalized. It appears that we are adding new featur= es and therefore will not be able to complete the work in any reasonable ti= meframe. So, do we have a plan for how to complete the document? Ciao Hannes IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. --_000_b1f75e92b9f34235b5922847e9595ad1XCHALN010ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Your recommendation ab= out having the right hardware is valid and what everyone should do as much = as possible. What about Class 1 OEMs that cannot add the hardware you are r= ecommending? Or even the ones that will not comply with the recommendations for their own reasons? We can’t = forget about those.

 

Is the vulnerability t= hat you were referring to that the RA or CA have to generate the key? Trust= of these entities needs to be established or this model falls apart anyway= . It is up to the admin to decide if it trusts the Registrar will not store and reveal the private keys or gene= rate insecure keys on the device itself. I am more concerned about this vul= nerability https://www.kb.cert.org/= vuls/id/566724 where some thousands of devices have the same identity a= nd now they can all impersonate each other in my network as shown in https://jhalder= m.com/pub/papers/https-imc13.pdf and https://factorable.net/paper.= html

 

We agree on the other = ephemeral keys used in secure communications. Good hardware would solve the= se issues. Without secure hardware some of these communications could be de= crypted assuming the right resources. Even though, decrypting some data per connection is a concern, I don’= ;t think that the risk is as high as a compromised identity. Also, the form= er concern does not mean we should not have an option to eliminate the latt= er.

 

About the Proxy sectio= n 6, I would like to see comments about in in the next iteration, as we hav= e updated to try to address some of these comments.

 

From: Ace [mailto:ace-bounces@ietf.org] On Behalf Of Hannes Tschofenig
Sent: Monday, May 14, 2018 10:14 AM
To: Panos Kampanakis (pkampana) <pkampana@cisco.com>; ace@ietf.org
Subject: Re: [Ace] EST over CoAP

 

Hi Pano= s,

&n= bsp;

Thanks = for sharing this info.

&n= bsp;

Regardi= ng the randomness requirement and the energy consumption. We have been a bi= t advocate for adding hardware-based random numbers to devices since random= ness is a basic requirement for most security protocols.

You do = not only need to have access to random numbers during key generation but al= so later when you use nonces, a DH exchange, create session keys, and IVs, = and potentially even for signature generation. If you use a protocol that is not based on nonces then you may use one tha= t relies on timestamps, which may not make the story necessarily easier.

&n= bsp;

Random = number key generation is also not necessarily costly either (neither in ter= ms of energy cost nor in terms of hardware costs).  =

&n= bsp;

Hence, = I think you should consider the server-side key generation very carefully s= ince you are essentially destroying the benefits of public key crypto and i= ntroduce a big vulnerability.

&n= bsp;

In a nu= tshell, I think you are better of recommending OEMs to select the right har= dware for the given task.

&n= bsp;

Ciao

Hannes<= o:p>

&n= bsp;

PS: For= the proxy work (in context of DTLS/TLS) you might want to reach out to you= r co-worker Owen Friel.

&n= bsp;

From: Panos Kampanakis (pkampana) [mailto:pkampana@cisco.com<= /a>]
Sent: 14 May 2018 15:58
To: Hannes Tschofenig; ace@ie= tf.org
Subject: RE: EST over CoAP

 

Hi Hannes, =

 

To address your questi= on about server-side key gen, below is the explanation we have put in the d= raft already and will be in the next iteration
~~~~~~~~~~~~~

&n= bsp;  Constrained devices sometimes do not have the necessary hardware= to

&n= bsp;  generate statistically random numbers for private keys and DTLS<= o:p>

&n= bsp;  ephemeral keys.  Past experience has shown that cheap endpo= ints

&n= bsp;  sometimes generate numbers which could allow someone to decrypt = the

&n= bsp;  communication or guess the private key and impersonate as the de= vice.

&n= bsp;  Studies have shown that the same keys are generated by the same = model

&n= bsp;  devices deployed on-line.

 

&n= bsp;  Additionally, random number key generation is costly, thus energ= y

&n= bsp;  draining.  Even though the random numbers that constitute t= he

&n= bsp;  identity/cert do not get generated often, an endpoint may not wa= nt to

&n= bsp;  spend time and energy generating keypairs, and just ask for one = from

&n= bsp;  the server.

 

&n= bsp;  In these scenarios, server-side key generation can be used. = ; The

&n= bsp;  client asks for the server or proxy to generate the private key = and

&n= bsp;  the certificate which is transferred back to the client in the

&n= bsp;  server-side key generation response.
~~~~~~~~~~~~~=

 

This is a need that we= have heard from customers at Cisco.

 

About the proxy-Regist= rar question, we already have made the change in the working copy of the dr= aft as well. We no longer call this functionality proxying, but instead use= the concept of the registrar that terminates the connection and establishes the next one.

 

We didn’t add an= y new features in the doc after removing the BRSKI stuff.  =

 

If you want an early p= review to comment on, we can share the repository with you.

 

Panos

 

From: Ace [mailto:ace-bounces@ietf.org] On Behalf Of Hannes Tschofenig
Sent: Monday, May 14, 2018 5:05 AM
To: ace@ietf.org
Subject: [Ace] EST over CoAP

 

Hi all,

 

At IETF#101 Peter presented a l= ist of open issues with the EST over CoAP draft, see

http= s://datatracker.ietf.org/meeting/101/materials/slides-101-ace-est-over-secu= re-coap-00

 

-        Operational parameter values<= /p>

-        Server side key generation using simple multipa= rt encoding

-        Explain trust relations for http/coap proxying<= o:p>

 

I have challenged the usefulnes= s of the server-side key generation during the meeting but in general I am = curious where we are with the document. It would be great to get it finaliz= ed. It appears that we are adding new features and therefore will not be able to complete the work in any reason= able timeframe.

 

So, do we have a plan for how t= o complete the document?

 

Ciao

Hannes

 

IMPORTANT NOTICE: The contents of= this email and any attachments are confidential and may also be privileged= . If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any othe= r person, use it for any purpose, or store or copy the information in any m= edium. Thank you.

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 othe= r person, use it for any purpose, or store or copy the information in any m= edium. Thank you.

--_000_b1f75e92b9f34235b5922847e9595ad1XCHALN010ciscocom_-- From nobody Mon May 14 13:50:17 2018 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70B3612D960 for ; Mon, 14 May 2018 13:50:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 6T21PsJRtOK2 for ; Mon, 14 May 2018 13:50:12 -0700 (PDT) Received: from resqmta-ch2-02v.sys.comcast.net (resqmta-ch2-02v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:34]) (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 A0AF012895E for ; Mon, 14 May 2018 13:50:12 -0700 (PDT) Received: from resomta-ch2-07v.sys.comcast.net ([69.252.207.103]) by resqmta-ch2-02v.sys.comcast.net with ESMTP id IJVnfhL5S9RA0IKQ7f3ySJ; Mon, 14 May 2018 20:50:11 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1526331011; bh=KIbrwE2fFUiFU8ndiljMI9uaqgqJ6Jz1jFjQJhqYhBg=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=n8Ya3sPbIaY29yhBkzq8qZ90EcAntMdtJFk7x4TAQkhRGfOn/blDNzZnQyKXnhWsy e5MrDc3XQ914B4rwak/SNm4Pm4GeF/3uHSCZzTpO7d/ExMDugP1SA+OLMzAUu7u+TC MobVT1ay3h1VEJMT3EN49T+DBIVk3GKGByQskqN0CmJy41zwckI+W1A8Qp1oECvKNp Cxdn/1fXgshknfbrzI8T07XFZnvnQkIxX0o3F8Lztml22tbK34OJW1uZE1lmn4AfTb gaZleKJKoA9odBSJ26UTLJ5hYZVetDoLtd3lIaBByn1JoDpjClNQ42lhVse5iLs02a gdozZsr0c8p+w== Received: from [IPv6:2601:152:4400:4013:496d:6089:91f5:b7a8] ([IPv6:2601:152:4400:4013:496d:6089:91f5:b7a8]) by resomta-ch2-07v.sys.comcast.net with ESMTPSA id IKQ6fJSEpaPSLIKQ7fQt7E; Mon, 14 May 2018 20:50:11 +0000 To: ace@ietf.org References: <30117.1526309628@localhost> From: Michael StJohns Message-ID: <53811ca9-0727-414a-4d77-e0f73d8c469a@comcast.net> Date: Mon, 14 May 2018 16:50:03 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.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 X-CMAE-Envelope: MS4wfMa+GxwFCGtVJ5lC2fbUvLG4Vzumngn8sXGokEUPkSc+Lo+HJdws8QnfZGs4fSLJv4oVGbHUDk4E5u3GrA/Rl0mAAKDRVFozvgnuNI2BsqhDfHxthzeE gNyR3vyGoQ9gMS0Zn1wY20lgOcxz5TGO5O99DtID8PQlvyTd+9zJQj6mZthwTTpJSEdPTH3TT5pQyKJ/Ix7tPXftXzYfvDOmaWWCLtenw+Jp2GAnzqqURrPv VNaOrlEiIihQYldKjryK1uVY2AqVycQ7oPRJrx1BM44= Archived-At: Subject: Re: [Ace] EST over CoAP X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2018 20:50:15 -0000 Hi Hannes - Basically, the argument I'm hearing again is that we have to have common protocols that work with the least capable devices in the same way that they work with more capable devices.   Which then is taken to mean that we have to limit the security of said protocols to what's available with those most limited devices. This seems to be a bad argument both for the big guys and for the small guys.  And its really not about the hardware requirements for a specific device that should be the concern of the IETF, but about specifying the protocol requirements - said requirements being reasonable for the specific limited field of use. E.g. The recommendation must be for a "good" RNG - that doesn't necessarily translate to a requirement for a hardware TRNG, but if that's what you need to get to "good", then that's what the builder should spec. I'm wondering if its time to fork the Internet Standards path and create an IOT Standards RFC path that deals with these less capable devices, explains that these are not to be used for larger devices unless talking to the constrained devices, but which still gets the IETF standards process treatment?  RFC 7228 may have done us a disservice by not explaining what the minimum capable security services were for each of the classes. Mike On 5/14/2018 2:49 PM, Hannes Tschofenig wrote: > Here is my personal take on this: you have to do your threat assessment to find out what attacks you care about. This will determine your hardware requirements (not the other way around). At a minimum you will have to figure out how to provide randomness in your design and that can come at a very low cost. For example, if I use ST's MCU finder http://www.st.com/en/development-tools/st-mcu-finder.html and search for microcontrollers that have TRNG support then I get 410 results (only for STM MCUs). > > If you aim for devices that also provide ECC/RSA crypto in hardware + tamper-resistant key storage then we will move past the RFC 7228-type of constrained IoT device classes. You have can a look of what this means in context of Arm IP: https://developer.arm.com/products/system-ip/trustzone-security-ip > > On a meta-level I have difficulties with the security design decisions made in IETF IoT-related groups since they swing back and forth between the extremes in pretty much no time. At the London IETF meeting I hear people talking about drafting guidelines for the use of new crypto algorithms with IoT devices since P256r1 and AES128-CCM is not good enough for them. At the same time I am having a hard time convincing people that using an unauthenticated identifier is not good for security. > > Ciao > Hannes > > -----Original Message----- > From: Ace [mailto:ace-bounces@ietf.org] On Behalf Of Michael Richardson > Sent: 14 May 2018 16:54 > To: ace@ietf.org > Subject: Re: [Ace] EST over CoAP > > > Hannes Tschofenig wrote: > > Regarding the randomness requirement and the energy consumption. We > > have been a bit advocate for adding hardware-based random numbers to > > devices since randomness is a basic requirement for most security > > protocols. > > I think that this is the future, and I very much agree with you. > > There seems to be a stock of older designs which have gone through other kinds of validation (for instance, think about the engineering review of physical cases and PCB design for electric metering). > > My impression is that there is a desire to significantly update the security profile of these devices (some of which are in the field already). What was deployed had poor security, or had proprietary protocols and there is a desire to move it up to "par". > > The other thing I hear is that the crypto libraries involved take some time to get FIPS-140 certified and so the one that the devices were deployed with do RSA only, and there is a desire to update them to ECDSA (or EdDSA), and means new keys. > > I think that any device with any kind of TPM would rather generate it's own keys. Whether it's a physical TPM, or some kind of TrustZone,etc. version. > > > In a nutshell, I think you are better of recommending OEMs to select > > the right hardware for the given task. > > I'd like to find some text that acknowledges the past, while setting things up better for the future. > > > PS: For the proxy work (in context of DTLS/TLS) you might want to reach > > out to your co-worker Owen Friel. > > he's in other loops already, but he seems shy to post to lists. > > > IMPORTANT NOTICE: The contents of this email and any attachments are > > I wish your email system would omit this, as it's both meaningless and sometimes harmful. > > -- > Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- > > > > IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace From nobody Mon May 14 22:37:17 2018 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14F881275F4 for ; Mon, 14 May 2018 22:37:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.309 X-Spam-Level: X-Spam-Status: No, score=-4.309 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-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=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 KRXc5jt6gx1s for ; Mon, 14 May 2018 22:37:13 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31C59120727 for ; Mon, 14 May 2018 22:37:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1526362631; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=5SgxijOsbXU655xrNuiNQ9ntEx0cYtyQfgXFBQMgHSM=; b=ZmaNNrTpbeAMNDlkwxY3SpJQyxq05Pstlc2DJpk33ikP3W9qZuh7FxKfH0+w6+EK PPxENx1KYbFxzUqpgAIv/OwhXuT3RzU5Dtb+TkfCGCrEMAMgRaT5cB+p17poIPCk 9mb6qjQGSN4c6OSi7JI0G4UkXMC3Hf+4l/U3mW17xUk=; X-AuditID: c1b4fb3a-5a4b59c000006a47-39-5afa720743e1 Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.183.90]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id EE.6B.27207.7027AFA5; Tue, 15 May 2018 07:37:11 +0200 (CEST) Received: from nomadiclab.fi.eu.ericsson.se (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.92) with Microsoft SMTP Server id 14.3.382.0; Tue, 15 May 2018 07:37:10 +0200 Received: from nomadiclab.fi.eu.ericsson.se (localhost [127.0.0.1]) by nomadiclab.fi.eu.ericsson.se (Postfix) with ESMTP id B12E84812DD; Tue, 15 May 2018 08:37:10 +0300 (EEST) Received: from [127.0.0.1] (localhost [IPv6:::1]) by nomadiclab.fi.eu.ericsson.se (Postfix) with ESMTP id 59B53480A7D; Tue, 15 May 2018 08:37:10 +0300 (EEST) To: "Panos Kampanakis (pkampana)" , Hannes Tschofenig , "ace@ietf.org" References: From: Mohit Sethi Message-ID: <068f2690-e1a1-b225-463a-4048e06365af@ericsson.com> Date: Tue, 15 May 2018 08:37:10 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------0A747E04D237818445BE20CA" Content-Language: en-US X-AV-Checked: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupkkeLIzCtJLcpLzFFi42KZGbE9Spe96FeUwYqnchbfv/UwW9yccYrJ 4suFVYwOzB5r5q1h9JjyeyOrx5IlP5kCmKO4bFJSczLLUov07RK4Mrb96WYr2NXPWLHkZm0D 48+CLkZODgkBE4lNN76wdTFycQgJHGGUeLDoHyNIQkhgB6PEjHk2EInNjBLH9t1lh3AWMkpM nL+ZDaRKWEBBYlnzf2aQhIhAG6PEj683oapmM0rMe3gPrIpNQE+i89xxZhCbV8BeYvGq32A7 WARUJZZvPQRmiwpESNw7/4kNokZQ4uTMJywgNqeAq8SERzOYQGxmgTCJPfOuQ9niEreezGeC eEJZYkHLIqi71SW2dhxgnMAoNAvJqFlI2mchaZ/FyAFk20s82FoGEZaXaN46mxnC1pe4fuc+ K7L4Akb2VYyixanFxbnpRkZ6qUWZycXF+Xl6eaklmxiBEXRwy2+rHYwHnzseYhTgYFTi4VUv /BUlxJpYVlyZe4hRgoNZSYR3t9HPKCHelMTKqtSi/Pii0pzU4kOM0hwsSuK8TmkWUUIC6Ykl qdmpqQWpRTBZJg5OqQZGtYyi07Nddyg9UePSNi7/llf4lKetan7u7yX3HggvfmXXuMAvYHOe 353ir3UnOZZ6rfl1uTV2/erPyvxflFauXcVieWbtUesolVif+/7Je+4H/jTyKdOc9HdHj758 2/KS1zfbot48X7J7mzXvrlMipluEDnLppL5oLWhrWOfTtiz8sRDPC4YaJZbijERDLeai4kQA qrnDW5wCAAA= Archived-At: Subject: Re: [Ace] EST over CoAP X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2018 05:37:16 -0000 --------------0A747E04D237818445BE20CA Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit Hi Panos, How do you intend to use these server generated keys once they are provisioned onto the device? --Mohit On 05/14/2018 04:58 PM, Panos Kampanakis (pkampana) wrote: > > Hi Hannes, > > To address your question about server-side key gen, below is the > explanation we have put in the draft already and will be in the next > iteration > /~~~~~~~~~~~~~/ > > / Constrained devices sometimes do not have the necessary hardware to/ > > / generate statistically random numbers for private keys and DTLS/ > > / ephemeral keys. Past experience has shown that cheap endpoints/ > > / sometimes generate numbers which could allow someone to decrypt the/ > > / communication or guess the private key and impersonate as the device./ > > / Studies have shown that the same keys are generated by the same model/ > > / devices deployed on-line./ > > // > > / Additionally, random number key generation is costly, thus energy/ > > / draining. Even though the random numbers that constitute the/ > > / identity/cert do not get generated often, an endpoint may not want to/ > > / spend time and energy generating keypairs, and just ask for one from/ > > / the server./ > > // > > / In these scenarios, server-side key generation can be used. The/ > > / client asks for the server or proxy to generate the private key and/ > > / the certificate which is transferred back to the client in the/ > > / server-side key generation response./ > /~~~~~~~~~~~~~/ > > This is a need that we have heard from customers at Cisco. > > About the proxy-Registrar question, we already have made the change in > the working copy of the draft as well. We no longer call this > functionality proxying, but instead use the concept of the registrar > that terminates the connection and establishes the next one. > > We didnt add any new features in the doc after removing the BRSKI stuff. > > If you want an early preview to comment on, we can share the > repository with you. > > Panos > > *From:* Ace [mailto:ace-bounces@ietf.org] *On Behalf Of *Hannes Tschofenig > *Sent:* Monday, May 14, 2018 5:05 AM > *To:* ace@ietf.org > *Subject:* [Ace] EST over CoAP > > Hi all, > > At IETF#101 Peter presented a list of open issues with the EST over > CoAP draft, see > > https://datatracker.ietf.org/meeting/101/materials/slides-101-ace-est-over-secure-coap-00 > > -Operational parameter values > > -Server side key generation using simple multipart encoding > > -Explain trust relations for http/coap proxying > > I have challenged the usefulness of the server-side key generation > during the meeting but in general I am curious where we are with the > document. It would be great to get it finalized. It appears that we > are adding new features and therefore will not be able to complete the > work in any reasonable timeframe. > > So, do we have a plan for how to complete the document? > > Ciao > > Hannes > > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged.. If you are not the intended > recipient, please notify the sender immediately and do not disclose > the contents to any other person, use it for any purpose, or store or > copy the information in any medium. Thank you. > > > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace --------------0A747E04D237818445BE20CA Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: 8bit

Hi Panos,

How do you intend to use these server generated keys once they are provisioned onto the device?

--Mohit


On 05/14/2018 04:58 PM, Panos Kampanakis (pkampana) wrote:

Hi Hannes,

To address your question about server-side key gen, below is the explanation we have put in the draft already and will be in the next iteration
~~~~~~~~~~~~~

Constrained devices sometimes do not have the necessary hardware to

generate statistically random numbers for private keys and DTLS

ephemeral keys. Past experience has shown that cheap endpoints

sometimes generate numbers which could allow someone to decrypt the

communication or guess the private key and impersonate as the device.

Studies have shown that the same keys are generated by the same model

devices deployed on-line.

Additionally, random number key generation is costly, thus energy

draining. Even though the random numbers that constitute the

identity/cert do not get generated often, an endpoint may not want to

spend time and energy generating keypairs, and just ask for one from

the server.

In these scenarios, server-side key generation can be used. The

client asks for the server or proxy to generate the private key and

the certificate which is transferred back to the client in the

server-side key generation response.
~~~~~~~~~~~~~

This is a need that we have heard from customers at Cisco.

About the proxy-Registrar question, we already have made the change in the working copy of the draft as well. We no longer call this functionality proxying, but instead use the concept of the registrar that terminates the connection and establishes the next one.

We didnt add any new features in the doc after removing the BRSKI stuff.

If you want an early preview to comment on, we can share the repository with you.

Panos

From: Ace [mailto:ace-bounces@ietf.org] On Behalf Of Hannes Tschofenig
Sent: Monday, May 14, 2018 5:05 AM
To: ace@ietf.org
Subject: [Ace] EST over CoAP

Hi all,

At IETF#101 Peter presented a list of open issues with the EST over CoAP draft, see

https://datatracker.ietf.org/meeting/101/materials/slides-101-ace-est-over-secure-coap-00

- Operational parameter values

- Server side key generation using simple multipart encoding

- Explain trust relations for http/coap proxying

I have challenged the usefulness of the server-side key generation during the meeting but in general I am curious where we are with the document. It would be great to get it finalized. It appears that we are adding new features and therefore will not be able to complete the work in any reasonable timeframe.

So, do we have a plan for how to complete the document?

Ciao

Hannes

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged.. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. 



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

--------------0A747E04D237818445BE20CA-- From nobody Tue May 15 01:27:28 2018 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0261F12D77A for ; Tue, 15 May 2018 01:27:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 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, T_DKIMWL_WL_MED=-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=armh.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t_zWv1xXYLBi for ; Tue, 15 May 2018 01:27:22 -0700 (PDT) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40048.outbound.protection.outlook.com [40.107.4.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B41491200E5 for ; Tue, 15 May 2018 01:27:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Lx10mw702xudI7zGrrvOH/2mCB83pvQbSk2khhXiJ0Q=; b=mNhq15M+P9V4gLy2rSZxDs35GDiXTS9Z3FhOj5/IKttaojqp3QMWGzXx2lfVg9mH+pNKLL8wEaVCjVyGuueOiwHdntdD7YWPh4qJZ+A4Mpxqah7B7ogK//inD9FDbgw5ucr/lHra6DW696CtJORyg0E4sMx2SniLRhVPvB1ONL4= Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB1424.eurprd08.prod.outlook.com (10.167.198.28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.755.16; Tue, 15 May 2018 08:27:18 +0000 Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::7c43:c1a5:4f69:5365]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::7c43:c1a5:4f69:5365%17]) with mapi id 15.20.0755.018; Tue, 15 May 2018 08:27:17 +0000 From: Hannes Tschofenig To: "Panos Kampanakis (pkampana)" , "ace@ietf.org" Thread-Topic: EST over CoAP Thread-Index: AdPrYipD0kyce1IOREqwxYCd2nFDSgAKCPZwAACDJXAAAGyyQAAlwdwA Date: Tue, 15 May 2018 08:27:17 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [156.67.194.220] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0801MB1424; 7:Td8gr13By9xXp5kvxqBBYA9XJWZ9GLZazWKAM6IPruud9MWtzYeUUAlQ3licUqZxHl8pmY2mbd+xOQWb+S+fpug22QuLkFUk3UTGQG3nD31MgDTe++Fw85NKztAK5Hw4aY9CZ15jirEI7dkm+4MZEI4ZNlrJQLGnYFD5Dl1BZ4PZFilP+NEmLw6yS4ebsUN64Xe63c4o+AUPCtSv+qsSHPe4tX4bbxCoiqtconSdQgM6SB2DqOA9LjepWi8zsP4S x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(48565401081)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB1424; x-ms-traffictypediagnostic: VI1PR0801MB1424: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(158342451672863)(120809045254105)(192374486261705)(95692535739014)(21748063052155)(87864910995729); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006095)(93001095)(3231254)(944501410)(52105095)(6055026)(149027)(150027)(6041310)(20161123560045)(20161123558120)(20161123564045)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:VI1PR0801MB1424; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0801MB1424; x-forefront-prvs: 0673F5BE31 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(39380400002)(346002)(366004)(376002)(396003)(53754006)(40434004)(189003)(199004)(59450400001)(3480700004)(110136005)(106356001)(5890100001)(86362001)(53936002)(81166006)(3280700002)(81156014)(55016002)(105586002)(7736002)(14454004)(6506007)(53546011)(2900100001)(790700001)(8676002)(9326002)(229853002)(6436002)(6116002)(606006)(74316002)(966005)(186003)(72206003)(3846002)(2501003)(478600001)(236005)(5250100002)(316002)(66066001)(93886005)(8936002)(2906002)(476003)(9686003)(33656002)(7696005)(99286004)(6246003)(486006)(3660700001)(76176011)(11346002)(5660300001)(446003)(26005)(7116003)(6306002)(68736007)(25786009)(21615005)(97736004)(102836004)(54896002)(15398625002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB1424; H:VI1PR0801MB2112.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: jyxZudPYeJeDmL2HZhapq6O5ce4n4CwRJQeqGgpLz6cBGYbtuFgfFS+Gv13pPHHkswUs48IgXzYMuMlT5ppVDvok2Mk7LWbIAjyoR60zwdt1OZ3bQZdp06BnkUrAKQIzwjBhlI3HB5nWvPql/MQxhHoojogGLL/qXXG5lrQDke0SplqJZZCPHWedfLIzPIXc spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_VI1PR0801MB2112BB24EA1AD68B1EEA0DB5FA930VI1PR0801MB2112_" MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: b27a4d13-fe9e-4508-b017-08d5ba3dab8a X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: b27a4d13-fe9e-4508-b017-08d5ba3dab8a X-MS-Exchange-CrossTenant-originalarrivaltime: 15 May 2018 08:27:17.4995 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1424 Archived-At: Subject: Re: [Ace] EST over CoAP X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2018 08:27:26 -0000 --_000_VI1PR0801MB2112BB24EA1AD68B1EEA0DB5FA930VI1PR0801MB2112_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Panos, I would say forget class 1 devices when you want to use public key crypto. https://factorable.net/paper.html (and https://jhalderm.com/pub/papers/http= s-imc13.pdf since it revisits the earlier analysis) was a problem with und= erstanding where the entropy comes from. If you take a regular desktop Linu= x and remove keyboard, mouse, disk drive, complex process scheduling etc. t= hen the ordinary entropy sources are suddenly gone. That was the problem id= entified in that paper. I am worried about keys across devices. For this reason we have standardize= d protocols to allow you to provision devices with new keys. Here is a whit= epaper published not too long ago that discusses the issue, see https://www= .omaspecworks.org/wp-content/uploads/2018/03/IPSO-IoT-Credential-Management= _Final.pdf I believe you would agree with me that there is a lot of value in the publi= c key crypto since you don't have to expose the private key. If your design= suddenly still requires this then you are losing some of the good properti= es of public key crypto systems. Ciao Hannes From: Panos Kampanakis (pkampana) [mailto:pkampana@cisco.com] Sent: 14 May 2018 21:24 To: Hannes Tschofenig; ace@ietf.org Subject: RE: EST over CoAP Your recommendation about having the right hardware is valid and what every= one should do as much as possible. What about Class 1 OEMs that cannot add = the hardware you are recommending? Or even the ones that will not comply wi= th the recommendations for their own reasons? We can't forget about those. Is the vulnerability that you were referring to that the RA or CA have to g= enerate the key? Trust of these entities needs to be established or this mo= del falls apart anyway. It is up to the admin to decide if it trusts the Re= gistrar will not store and reveal the private keys or generate insecure key= s on the device itself. I am more concerned about this vulnerability https:= //www.kb.cert.org/vuls/id/566724 where some thousands of devices have the s= ame identity and now they can all impersonate each other in my network as s= hown in https://jhalderm.com/pub/papers/https-imc13.pdf and https://factora= ble.net/paper.html We agree on the other ephemeral keys used in secure communications. Good ha= rdware would solve these issues. Without secure hardware some of these comm= unications could be decrypted assuming the right resources. Even though, de= crypting some data per connection is a concern, I don't think that the risk= is as high as a compromised identity. Also, the former concern does not me= an we should not have an option to eliminate the latter. About the Proxy section 6, I would like to see comments about in in the nex= t iteration, as we have updated to try to address some of these comments. From: Ace [mailto:ace-bounces@ietf.org] On Behalf Of Hannes Tschofenig Sent: Monday, May 14, 2018 10:14 AM To: Panos Kampanakis (pkampana) >; ace@ietf.org Subject: Re: [Ace] EST over CoAP Hi Panos, Thanks for sharing this info. Regarding the randomness requirement and the energy consumption. We have be= en a bit advocate for adding hardware-based random numbers to devices since= randomness is a basic requirement for most security protocols. You do not only need to have access to random numbers during key generation= but also later when you use nonces, a DH exchange, create session keys, an= d IVs, and potentially even for signature generation. If you use a protocol= that is not based on nonces then you may use one that relies on timestamps= , which may not make the story necessarily easier. Random number key generation is also not necessarily costly either (neither= in terms of energy cost nor in terms of hardware costs). Hence, I think you should consider the server-side key generation very care= fully since you are essentially destroying the benefits of public key crypt= o and introduce a big vulnerability. In a nutshell, I think you are better of recommending OEMs to select the ri= ght hardware for the given task. Ciao Hannes PS: For the proxy work (in context of DTLS/TLS) you might want to reach out= to your co-worker Owen Friel. From: Panos Kampanakis (pkampana) [mailto:pkampana@cisco.com] Sent: 14 May 2018 15:58 To: Hannes Tschofenig; ace@ietf.org Subject: RE: EST over CoAP Hi Hannes, To address your question about server-side key gen, below is the explanatio= n we have put in the draft already and will be in the next iteration ~~~~~~~~~~~~~ Constrained devices sometimes do not have the necessary hardware to generate statistically random numbers for private keys and DTLS ephemeral keys. Past experience has shown that cheap endpoints sometimes generate numbers which could allow someone to decrypt the communication or guess the private key and impersonate as the device. Studies have shown that the same keys are generated by the same model devices deployed on-line. Additionally, random number key generation is costly, thus energy draining. Even though the random numbers that constitute the identity/cert do not get generated often, an endpoint may not want to spend time and energy generating keypairs, and just ask for one from the server. In these scenarios, server-side key generation can be used. The client asks for the server or proxy to generate the private key and the certificate which is transferred back to the client in the server-side key generation response. ~~~~~~~~~~~~~ This is a need that we have heard from customers at Cisco. About the proxy-Registrar question, we already have made the change in the = working copy of the draft as well. We no longer call this functionality pro= xying, but instead use the concept of the registrar that terminates the con= nection and establishes the next one. We didn't add any new features in the doc after removing the BRSKI stuff. If you want an early preview to comment on, we can share the repository wit= h you. Panos From: Ace [mailto:ace-bounces@ietf.org] On Behalf Of Hannes Tschofenig Sent: Monday, May 14, 2018 5:05 AM To: ace@ietf.org Subject: [Ace] EST over CoAP Hi all, At IETF#101 Peter presented a list of open issues with the EST over CoAP dr= aft, see https://datatracker.ietf.org/meeting/101/materials/slides-101-ace-est-over-= secure-coap-00 - Operational parameter values - Server side key generation using simple multipart encoding - Explain trust relations for http/coap proxying I have challenged the usefulness of the server-side key generation during t= he meeting but in general I am curious where we are with the document. It w= ould be great to get it finalized. It appears that we are adding new featur= es and therefore will not be able to complete the work in any reasonable ti= meframe. So, do we have a plan for how to complete the document? Ciao Hannes IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. 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. IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. --_000_VI1PR0801MB2112BB24EA1AD68B1EEA0DB5FA930VI1PR0801MB2112_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Panos, <= /span>

 

I would say forget cla= ss 1 devices when you want to use public key crypto.

 

https://factora= ble.net/paper.html (and https://jhalderm.com/pub/papers/h= ttps-imc13.pdf  since it revisits the earlier analysis) was a problem = with understanding where the entropy comes from. If you take a regular desk= top Linux and remove keyboard, mouse, disk drive, complex process scheduling etc. then the ordinary entropy sources a= re suddenly gone. That was the problem identified in that paper.

 

I am worried about key= s across devices. For this reason we have standardized protocols to allow y= ou to provision devices with new keys. Here is a whitepaper published not t= oo long ago that discusses the issue, see https://www.omaspecworks.org/wp-content/uploads/2018/03/IPSO-IoT-Crede= ntial-Management_Final.pdf

 

I believe you would ag= ree with me that there is a lot of value in the public key crypto since you= don’t have to expose the private key. If your design suddenly still = requires this then you are losing some of the good properties of public key crypto systems.

 

Ciao
Hannes

 

From: Panos Kampanakis (pkampana) [mailto:pkampana@cisco.co= m]
Sent: 14 May 2018 21:24
To: Hannes Tschofenig; ace@ietf.org
Subject: RE: EST over CoAP

 

Your re= commendation about having the right hardware is valid and what everyone sho= uld do as much as possible. What about Class 1 OEMs that cannot add the har= dware you are recommending? Or even the ones that will not comply with the recommendations for their own reasons? = We can’t forget about those.

&n= bsp;

Is the = vulnerability that you were referring to that the RA or CA have to generate= the key? Trust of these entities needs to be established or this model fal= ls apart anyway. It is up to the admin to decide if it trusts the Registrar will not store and reveal the private= keys or generate insecure keys on the device itself. I am more concerned a= bout this vulnerability https://www.kb.cert.org/= vuls/id/566724 where some thousands of devices have the same identity a= nd now they can all impersonate each other in my network as shown in https://jhalder= m.com/pub/papers/https-imc13.pdf and https://factorable.net/paper.= html

&n= bsp;

We agre= e on the other ephemeral keys used in secure communications. Good hardware = would solve these issues. Without secure hardware some of these communicati= ons could be decrypted assuming the right resources. Even though, decrypting some data per connection is a concern, = I don’t think that the risk is as high as a compromised identity. Als= o, the former concern does not mean we should not have an option to elimina= te the latter.

&n= bsp;

About t= he Proxy section 6, I would like to see comments about in in the next itera= tion, as we have updated to try to address some of these comments.

&n= bsp;

From: Ace [mailto:ace-bounces= @ietf.org] On Behalf Of Hannes Tschofenig
Sent: Monday, May 14, 2018 10:14 AM
To: Panos Kampanakis (pkampana) <pkampana@cisco.com>; ace@ietf.org
Subject: Re: [Ace] EST over CoAP

 

Hi Panos, <= /span>

 

Thanks for sharing thi= s info.

 

Regarding the randomne= ss requirement and the energy consumption. We have been a bit advocate for = adding hardware-based random numbers to devices since randomness is a basic= requirement for most security protocols.

You do not only need t= o have access to random numbers during key generation but also later when y= ou use nonces, a DH exchange, create session keys, and IVs, and potentially= even for signature generation. If you use a protocol that is not based on nonces then you may use one that relie= s on timestamps, which may not make the story necessarily easier.

 

Random number key gene= ration is also not necessarily costly either (neither in terms of energy co= st nor in terms of hardware costs).  

 

Hence, I think you sho= uld consider the server-side key generation very carefully since you are es= sentially destroying the benefits of public key crypto and introduce a big = vulnerability.

 

In a nutshell, I think= you are better of recommending OEMs to select the right hardware for the g= iven task.

 

Ciao=

Hannes

 

PS: For the proxy work= (in context of DTLS/TLS) you might want to reach out to your co-worker Owe= n Friel.

 

From: Panos Kampanakis (pkampana) [mailto:pkampana@cisco= .com]
Sent: 14 May 2018 15:58
To: Hannes Tschofenig; ace@ietf.org
Subject: RE: EST over CoAP

 

Hi Hann= es,

&n= bsp;

To addr= ess your question about server-side key gen, below is the explanation we ha= ve put in the draft already and will be in the next iteration
~~~~~~~~~~~~~

   Constrained devices sometimes do not have the nec= essary hardware to

   generate statistically random numbers for private= keys and DTLS

   ephemeral keys.  Past experience has shown t= hat cheap endpoints

   sometimes generate numbers which could allow some= one to decrypt the

   communication or guess the private key and impers= onate as the device.

   Studies have shown that the same keys are generat= ed by the same model

   devices deployed on-line.

 

   Additionally, random number key generation is cos= tly, thus energy

   draining.  Even though the random numbers th= at constitute the

   identity/cert do not get generated often, an endp= oint may not want to

   spend time and energy generating keypairs, and ju= st ask for one from

   the server.

 

   In these scenarios, server-side key generation ca= n be used.  The

   client asks for the server or proxy to generate t= he private key and

   the certificate which is transferred back to the = client in the

   server-side key generation response.
~~~~~~~~~~~~~

&n= bsp;

This is= a need that we have heard from customers at Cisco.

&n= bsp;

About t= he proxy-Registrar question, we already have made the change in the working= copy of the draft as well. We no longer call this functionality proxying, = but instead use the concept of the registrar that terminates the connection and establishes the next one.

&n= bsp;

We didn= ’t add any new features in the doc after removing the BRSKI stuff. &n= bsp;

&n= bsp;

If you = want an early preview to comment on, we can share the repository with you.

&n= bsp;

Panos

&n= bsp;

From: Ace [mailto:ace-bounces= @ietf.org] On Behalf Of Hannes Tschofenig
Sent: Monday, May 14, 2018 5:05 AM
To: ace@ietf.org
Subject: [Ace] EST over CoAP

 

Hi all,

 

At IETF#101 Peter presented a list of open issues wi= th the EST over CoAP draft, see

https://datatracker.ietf.org/meeting/101/materials/slides-= 101-ace-est-over-secure-coap-00

 

-        Operational parameter values

-        Server side key generation using simple multipart encoding

-        Explain trust relations for http/coap proxying

 

I have challenged the usefulness of the server-side = key generation during the meeting but in general I am curious where we are = with the document. It would be great to get it finalized. It appears that w= e are adding new features and therefore will not be able to complete the work in any reasonable timeframe.

 

So, do we have a plan for how to complete the docume= nt?

 

Ciao

Hannes

 

IMPORTANT NOTICE: The contents of th= is email and any attachments are confidential and may also be privileged. I= f you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, u= se it for any purpose, or store or copy the information in any medium. Than= k you.

IMPORTANT NOTICE: The contents of th= is email and any attachments are confidential and may also be privileged. I= f you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, u= se it for any purpose, or store or copy the information in any medium. Than= k you.

IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in any medium. Thank you. --_000_VI1PR0801MB2112BB24EA1AD68B1EEA0DB5FA930VI1PR0801MB2112_-- From nobody Tue May 15 01:30:10 2018 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D8A512D77E for ; Tue, 15 May 2018 01:30:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 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, T_DKIMWL_WL_MED=-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=armh.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VN_kuLm7ImxS for ; Tue, 15 May 2018 01:30:05 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0625.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe1f::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 672201200E5 for ; Tue, 15 May 2018 01:30:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=PovEpcc1tKulMuJhBP5q3v5ntMuWqEP02d0Xt7zhzGI=; b=MP9E2ziZ8yifmyyEytxg0ofmg5ZkneieIZ/IWkBjBrNcR0RQ9fXUpomyY+SyJnI9FZgBBAuTZ2bmgd6AobMw1U6z3vdiJz+AX8HiNRJ/v7EJJDWd4x1WIu6jsUJPn0zvBjQGP2BiIOq2sA5BNR3PAxmYtG14D7c8cuJaOC9Dib4= Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB1472.eurprd08.prod.outlook.com (10.167.210.28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.755.16; Tue, 15 May 2018 08:30:02 +0000 Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::7c43:c1a5:4f69:5365]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::7c43:c1a5:4f69:5365%17]) with mapi id 15.20.0755.018; Tue, 15 May 2018 08:30:01 +0000 From: Hannes Tschofenig To: Michael StJohns , "ace@ietf.org" Thread-Topic: [Ace] EST over CoAP Thread-Index: AdPrYipD0kyce1IOREqwxYCd2nFDSgAKCPZwAACDJXAAAcCgAAAAQuHQAAwuPoAAGFpw0A== Date: Tue, 15 May 2018 08:30:01 +0000 Message-ID: References: <30117.1526309628@localhost> <53811ca9-0727-414a-4d77-e0f73d8c469a@comcast.net> In-Reply-To: <53811ca9-0727-414a-4d77-e0f73d8c469a@comcast.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [156.67.194.220] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0801MB1472; 7:g2aafqpQRQXAnp3G7lPln52/QpKS8k9975MROlys3FrC39qa1iJj0KomPn3hTIQdfECuTKFa5x6l3Hm1lZdC6iT2kZH9J7FMu2AQwbxrtpjQ90yg9paOtAmOKBH2dGCz4sOozGTv0Dxy/TcXh8Fq/MfgNqYybZoUvOZ2FjCDzBS7oYi90NfKQxMZ3O7DJwQIs646FfORN4IVvIRy6ci7CPn7mU9BCrHOYhGAU1L3ejQjtnTZ8U905FBjB9a7asLn x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(48565401081)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB1472; x-ms-traffictypediagnostic: VI1PR0801MB1472: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(180628864354917)(192374486261705)(237425016533630); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3231254)(944501410)(52105095)(93006095)(93001095)(3002001)(10201501046)(6055026)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123562045)(20161123558120)(20161123560045)(6072148)(201708071742011); SRVR:VI1PR0801MB1472; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0801MB1472; x-forefront-prvs: 0673F5BE31 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(979002)(39380400002)(39860400002)(366004)(396003)(376002)(346002)(13464003)(51444003)(40434004)(199004)(189003)(102836004)(86362001)(6506007)(6306002)(26005)(9686003)(53936002)(186003)(59450400001)(99286004)(53546011)(5250100002)(6436002)(316002)(8666007)(7696005)(5890100001)(74316002)(2501003)(55016002)(3846002)(6116002)(76176011)(2900100001)(229853002)(6246003)(8936002)(106356001)(305945005)(7736002)(68736007)(25786009)(14454004)(66066001)(97736004)(3280700002)(8676002)(105586002)(5660300001)(486006)(33656002)(81166006)(110136005)(2906002)(478600001)(446003)(93886005)(11346002)(3660700001)(72206003)(476003)(966005)(81156014)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB1472; H:VI1PR0801MB2112.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: u9xu6xHShN0HkVy9Q6JQXcHYcKqE+9ldWZ6A2TsHOxLvxzOcMcK36C88VxSucLQyxeigwmNny2T5wPHJW5irFOHVVEisMEBGINYzRDF3KJGZYCNYEtYh3skFb5IiARwWA5oiy0Nge6UUvkzSxuh1A23TsxFDdg9A+3gA+q3f8wIUC5JsAjcG/aELUqF0P4Oa spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 4242c3a9-902f-4a5a-52fa-08d5ba3e0d33 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4242c3a9-902f-4a5a-52fa-08d5ba3e0d33 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 May 2018 08:30:01.3436 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1472 Archived-At: Subject: Re: [Ace] EST over CoAP X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2018 08:30:08 -0000 SGkgTWlrZSwNCg0KWW91IGFyZSBnZXR0aW5nIHRoZSBzdG9yeSB3cm9uZy4NCg0KRmlyc3QsIHRo ZSBib3VuZGFyeSBiZXR3ZWVuIHdoYXQgaXMgSW9UIGFuZCB3aGF0IGlzbid0IGlzbid0IHRoYXQg Y2xlYXIuIE9uZSBtYW4ncyBJb1QgaXMgYW5vdGhlciBtYW4ncyBkYXRhIGNlbnRlci4NCg0KU2Vj b25kLCBtYW55IG9mIHRoZSBwcm9ibGVtcyB3ZSBydW4gaW50byBhcmUgZnVuZGFtZW50YWwgdG8g Y3J5cHRvIHJhdGhlciB0aGFuIHRoZSBwcm90b2NvbCBkZXNpZ24uIFRoZXJlIGlzIGp1c3Qgbm8g ZnJlZSBsdW5jaCBldmVuIGlmIHdlIHdvdWxkIGxpa2UgaXQgc29vbyBtdWNoLg0KDQpDaWFvDQpI YW5uZXMNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEFjZSBbbWFpbHRvOmFj ZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTWljaGFlbCBTdEpvaG5zDQpTZW50OiAx NCBNYXkgMjAxOCAyMjo1MA0KVG86IGFjZUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtBY2VdIEVT VCBvdmVyIENvQVANCg0KSGkgSGFubmVzIC0NCg0KQmFzaWNhbGx5LCB0aGUgYXJndW1lbnQgSSdt IGhlYXJpbmcgYWdhaW4gaXMgdGhhdCB3ZSBoYXZlIHRvIGhhdmUgY29tbW9uIHByb3RvY29scyB0 aGF0IHdvcmsgd2l0aCB0aGUgbGVhc3QgY2FwYWJsZSBkZXZpY2VzIGluIHRoZSBzYW1lIHdheSB0 aGF0IHRoZXkgd29yayB3aXRoIG1vcmUgY2FwYWJsZSBkZXZpY2VzLiAgIFdoaWNoIHRoZW4gaXMg dGFrZW4gdG8gbWVhbiB0aGF0IHdlIGhhdmUgdG8gbGltaXQgdGhlIHNlY3VyaXR5IG9mIHNhaWQg cHJvdG9jb2xzIHRvIHdoYXQncyBhdmFpbGFibGUgd2l0aCB0aG9zZSBtb3N0IGxpbWl0ZWQgZGV2 aWNlcy4NCg0KVGhpcyBzZWVtcyB0byBiZSBhIGJhZCBhcmd1bWVudCBib3RoIGZvciB0aGUgYmln IGd1eXMgYW5kIGZvciB0aGUgc21hbGwgZ3V5cy4gIEFuZCBpdHMgcmVhbGx5IG5vdCBhYm91dCB0 aGUgaGFyZHdhcmUgcmVxdWlyZW1lbnRzIGZvciBhIHNwZWNpZmljIGRldmljZSB0aGF0IHNob3Vs ZCBiZSB0aGUgY29uY2VybiBvZiB0aGUgSUVURiwgYnV0IGFib3V0IHNwZWNpZnlpbmcgdGhlIHBy b3RvY29sIHJlcXVpcmVtZW50cyAtIHNhaWQgcmVxdWlyZW1lbnRzIGJlaW5nIHJlYXNvbmFibGUg Zm9yIHRoZSBzcGVjaWZpYyBsaW1pdGVkIGZpZWxkIG9mIHVzZS4NCg0KRS5nLiBUaGUgcmVjb21t ZW5kYXRpb24gbXVzdCBiZSBmb3IgYSAiZ29vZCIgUk5HIC0gdGhhdCBkb2Vzbid0IG5lY2Vzc2Fy aWx5IHRyYW5zbGF0ZSB0byBhIHJlcXVpcmVtZW50IGZvciBhIGhhcmR3YXJlIFRSTkcsIGJ1dCBp ZiB0aGF0J3Mgd2hhdCB5b3UgbmVlZCB0byBnZXQgdG8gImdvb2QiLCB0aGVuIHRoYXQncyB3aGF0 IHRoZSBidWlsZGVyIHNob3VsZCBzcGVjLg0KDQpJJ20gd29uZGVyaW5nIGlmIGl0cyB0aW1lIHRv IGZvcmsgdGhlIEludGVybmV0IFN0YW5kYXJkcyBwYXRoIGFuZCBjcmVhdGUgYW4gSU9UIFN0YW5k YXJkcyBSRkMgcGF0aCB0aGF0IGRlYWxzIHdpdGggdGhlc2UgbGVzcyBjYXBhYmxlIGRldmljZXMs IGV4cGxhaW5zIHRoYXQgdGhlc2UgYXJlIG5vdCB0byBiZSB1c2VkIGZvciBsYXJnZXIgZGV2aWNl cyB1bmxlc3MgdGFsa2luZyB0byB0aGUgY29uc3RyYWluZWQgZGV2aWNlcywgYnV0IHdoaWNoIHN0 aWxsIGdldHMgdGhlIElFVEYgc3RhbmRhcmRzIHByb2Nlc3MgdHJlYXRtZW50PyAgUkZDIDcyMjgg bWF5IGhhdmUgZG9uZSB1cyBhIGRpc3NlcnZpY2UgYnkgbm90IGV4cGxhaW5pbmcgd2hhdCB0aGUg bWluaW11bSBjYXBhYmxlIHNlY3VyaXR5IHNlcnZpY2VzIHdlcmUgZm9yIGVhY2ggb2YgdGhlIGNs YXNzZXMuDQoNCk1pa2UNCg0KDQoNCk9uIDUvMTQvMjAxOCAyOjQ5IFBNLCBIYW5uZXMgVHNjaG9m ZW5pZyB3cm90ZToNCj4gSGVyZSBpcyBteSBwZXJzb25hbCB0YWtlIG9uIHRoaXM6IHlvdSBoYXZl IHRvIGRvIHlvdXIgdGhyZWF0IGFzc2Vzc21lbnQgdG8gZmluZCBvdXQgd2hhdCBhdHRhY2tzIHlv dSBjYXJlIGFib3V0LiBUaGlzIHdpbGwgZGV0ZXJtaW5lIHlvdXIgaGFyZHdhcmUgcmVxdWlyZW1l bnRzIChub3QgdGhlIG90aGVyIHdheSBhcm91bmQpLiBBdCBhIG1pbmltdW0geW91IHdpbGwgaGF2 ZSB0byBmaWd1cmUgb3V0IGhvdyB0byBwcm92aWRlIHJhbmRvbW5lc3MgaW4geW91ciBkZXNpZ24g YW5kIHRoYXQgY2FuIGNvbWUgYXQgYSB2ZXJ5IGxvdyBjb3N0LiBGb3IgZXhhbXBsZSwgaWYgSSB1 c2UgU1QncyBNQ1UgZmluZGVyIGh0dHA6Ly93d3cuc3QuY29tL2VuL2RldmVsb3BtZW50LXRvb2xz L3N0LW1jdS1maW5kZXIuaHRtbCBhbmQgc2VhcmNoIGZvciBtaWNyb2NvbnRyb2xsZXJzIHRoYXQg aGF2ZSBUUk5HIHN1cHBvcnQgdGhlbiBJIGdldCA0MTAgcmVzdWx0cyAob25seSBmb3IgU1RNIE1D VXMpLg0KPg0KPiBJZiB5b3UgYWltIGZvciBkZXZpY2VzIHRoYXQgYWxzbyBwcm92aWRlIEVDQy9S U0EgY3J5cHRvIGluIGhhcmR3YXJlICsNCj4gdGFtcGVyLXJlc2lzdGFudCBrZXkgc3RvcmFnZSB0 aGVuIHdlIHdpbGwgbW92ZSBwYXN0IHRoZSBSRkMgNzIyOC10eXBlDQo+IG9mIGNvbnN0cmFpbmVk IElvVCBkZXZpY2UgY2xhc3Nlcy4gWW91IGhhdmUgY2FuIGEgbG9vayBvZiB3aGF0IHRoaXMNCj4g bWVhbnMgaW4gY29udGV4dCBvZiBBcm0gSVA6DQo+IGh0dHBzOi8vZGV2ZWxvcGVyLmFybS5jb20v cHJvZHVjdHMvc3lzdGVtLWlwL3RydXN0em9uZS1zZWN1cml0eS1pcA0KPg0KPiBPbiBhIG1ldGEt bGV2ZWwgSSBoYXZlIGRpZmZpY3VsdGllcyB3aXRoIHRoZSBzZWN1cml0eSBkZXNpZ24gZGVjaXNp b25zIG1hZGUgaW4gSUVURiBJb1QtcmVsYXRlZCBncm91cHMgc2luY2UgdGhleSBzd2luZyBiYWNr IGFuZCBmb3J0aCBiZXR3ZWVuIHRoZSBleHRyZW1lcyBpbiBwcmV0dHkgbXVjaCBubyB0aW1lLiBB dCB0aGUgTG9uZG9uIElFVEYgbWVldGluZyBJIGhlYXIgcGVvcGxlIHRhbGtpbmcgYWJvdXQgZHJh ZnRpbmcgZ3VpZGVsaW5lcyBmb3IgdGhlIHVzZSBvZiBuZXcgY3J5cHRvIGFsZ29yaXRobXMgd2l0 aCBJb1QgZGV2aWNlcyBzaW5jZSBQMjU2cjEgYW5kIEFFUzEyOC1DQ00gaXMgbm90IGdvb2QgZW5v dWdoIGZvciB0aGVtLiBBdCB0aGUgc2FtZSB0aW1lIEkgYW0gaGF2aW5nIGEgaGFyZCB0aW1lIGNv bnZpbmNpbmcgcGVvcGxlIHRoYXQgdXNpbmcgYW4gdW5hdXRoZW50aWNhdGVkIGlkZW50aWZpZXIg aXMgbm90IGdvb2QgZm9yIHNlY3VyaXR5Lg0KPg0KPiBDaWFvDQo+IEhhbm5lcw0KPg0KPiAtLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBBY2UgW21haWx0bzphY2UtYm91bmNlc0Bp ZXRmLm9yZ10gT24gQmVoYWxmIE9mIE1pY2hhZWwNCj4gUmljaGFyZHNvbg0KPiBTZW50OiAxNCBN YXkgMjAxOCAxNjo1NA0KPiBUbzogYWNlQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbQWNlXSBF U1Qgb3ZlciBDb0FQDQo+DQo+DQo+IEhhbm5lcyBUc2Nob2ZlbmlnIDxIYW5uZXMuVHNjaG9mZW5p Z0Bhcm0uY29tPiB3cm90ZToNCj4gICAgICA+IFJlZ2FyZGluZyB0aGUgcmFuZG9tbmVzcyByZXF1 aXJlbWVudCBhbmQgdGhlIGVuZXJneSBjb25zdW1wdGlvbi4gV2UNCj4gICAgICA+IGhhdmUgYmVl biBhIGJpdCBhZHZvY2F0ZSBmb3IgYWRkaW5nIGhhcmR3YXJlLWJhc2VkIHJhbmRvbSBudW1iZXJz IHRvDQo+ICAgICAgPiBkZXZpY2VzIHNpbmNlIHJhbmRvbW5lc3MgaXMgYSBiYXNpYyByZXF1aXJl bWVudCBmb3IgbW9zdCBzZWN1cml0eQ0KPiAgICAgID4gcHJvdG9jb2xzLg0KPg0KPiBJIHRoaW5r IHRoYXQgdGhpcyBpcyB0aGUgZnV0dXJlLCBhbmQgSSB2ZXJ5IG11Y2ggYWdyZWUgd2l0aCB5b3Uu DQo+DQo+IFRoZXJlIHNlZW1zIHRvIGJlIGEgc3RvY2sgb2Ygb2xkZXIgZGVzaWducyB3aGljaCBo YXZlIGdvbmUgdGhyb3VnaCBvdGhlciBraW5kcyBvZiB2YWxpZGF0aW9uIChmb3IgaW5zdGFuY2Us IHRoaW5rIGFib3V0IHRoZSBlbmdpbmVlcmluZyByZXZpZXcgb2YgcGh5c2ljYWwgY2FzZXMgYW5k IFBDQiBkZXNpZ24gZm9yIGVsZWN0cmljIG1ldGVyaW5nKS4NCj4NCj4gTXkgaW1wcmVzc2lvbiBp cyB0aGF0IHRoZXJlIGlzIGEgZGVzaXJlIHRvIHNpZ25pZmljYW50bHkgdXBkYXRlIHRoZSBzZWN1 cml0eSBwcm9maWxlIG9mIHRoZXNlIGRldmljZXMgKHNvbWUgb2Ygd2hpY2ggYXJlIGluIHRoZSBm aWVsZCBhbHJlYWR5KS4gIFdoYXQgd2FzIGRlcGxveWVkIGhhZCBwb29yIHNlY3VyaXR5LCBvciBo YWQgcHJvcHJpZXRhcnkgcHJvdG9jb2xzIGFuZCB0aGVyZSBpcyBhIGRlc2lyZSB0byBtb3ZlIGl0 IHVwIHRvICJwYXIiLg0KPg0KPiBUaGUgb3RoZXIgdGhpbmcgSSBoZWFyIGlzIHRoYXQgdGhlIGNy eXB0byBsaWJyYXJpZXMgaW52b2x2ZWQgdGFrZSBzb21lIHRpbWUgdG8gZ2V0IEZJUFMtMTQwIGNl cnRpZmllZCBhbmQgc28gdGhlIG9uZSB0aGF0IHRoZSBkZXZpY2VzIHdlcmUgZGVwbG95ZWQgd2l0 aCBkbyBSU0Egb25seSwgYW5kIHRoZXJlIGlzIGEgZGVzaXJlIHRvIHVwZGF0ZSB0aGVtIHRvIEVD RFNBIChvciBFZERTQSksIGFuZCBtZWFucyBuZXcga2V5cy4NCj4NCj4gSSB0aGluayB0aGF0IGFu eSBkZXZpY2Ugd2l0aCBhbnkga2luZCBvZiBUUE0gd291bGQgcmF0aGVyIGdlbmVyYXRlIGl0J3Mg b3duIGtleXMuICBXaGV0aGVyIGl0J3MgYSBwaHlzaWNhbCBUUE0sIG9yIHNvbWUga2luZCBvZiBU cnVzdFpvbmUsZXRjLiB2ZXJzaW9uLg0KPg0KPiAgICAgID4gSW4gYSBudXRzaGVsbCwgSSB0aGlu ayB5b3UgYXJlIGJldHRlciBvZiByZWNvbW1lbmRpbmcgT0VNcyB0byBzZWxlY3QNCj4gICAgICA+ IHRoZSByaWdodCBoYXJkd2FyZSBmb3IgdGhlIGdpdmVuIHRhc2suDQo+DQo+IEknZCBsaWtlIHRv IGZpbmQgc29tZSB0ZXh0IHRoYXQgYWNrbm93bGVkZ2VzIHRoZSBwYXN0LCB3aGlsZSBzZXR0aW5n IHRoaW5ncyB1cCBiZXR0ZXIgZm9yIHRoZSBmdXR1cmUuDQo+DQo+ICAgICAgPiBQUzogRm9yIHRo ZSBwcm94eSB3b3JrIChpbiBjb250ZXh0IG9mIERUTFMvVExTKSB5b3UgbWlnaHQgd2FudCB0byBy ZWFjaA0KPiAgICAgID4gb3V0IHRvIHlvdXIgY28td29ya2VyIE93ZW4gRnJpZWwuDQo+DQo+IGhl J3MgaW4gb3RoZXIgbG9vcHMgYWxyZWFkeSwgYnV0IGhlIHNlZW1zIHNoeSB0byBwb3N0IHRvIGxp c3RzLg0KPg0KPiAgICAgID4gSU1QT1JUQU5UIE5PVElDRTogVGhlIGNvbnRlbnRzIG9mIHRoaXMg ZW1haWwgYW5kIGFueQ0KPiBhdHRhY2htZW50cyBhcmUNCj4NCj4gSSB3aXNoIHlvdXIgZW1haWwg c3lzdGVtIHdvdWxkIG9taXQgdGhpcywgYXMgaXQncyBib3RoIG1lYW5pbmdsZXNzIGFuZCBzb21l dGltZXMgaGFybWZ1bC4NCj4NCj4gLS0NCj4gTWljaGFlbCBSaWNoYXJkc29uIDxtY3IrSUVURkBz YW5kZWxtYW4uY2E+LCBTYW5kZWxtYW4gU29mdHdhcmUgV29ya3MNCj4gLT0gSVB2NiBJb1QgY29u c3VsdGluZyA9LQ0KPg0KPg0KPg0KPiBJTVBPUlRBTlQgTk9USUNFOiBUaGUgY29udGVudHMgb2Yg dGhpcyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBjb25maWRlbnRpYWwgYW5kIG1heSBh bHNvIGJlIHByaXZpbGVnZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQs IHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBhbmQgZG8gbm90IGRpc2Nsb3Nl IHRoZSBjb250ZW50cyB0byBhbnkgb3RoZXIgcGVyc29uLCB1c2UgaXQgZm9yIGFueSBwdXJwb3Nl LCBvciBzdG9yZSBvciBjb3B5IHRoZSBpbmZvcm1hdGlvbiBpbiBhbnkgbWVkaXVtLiBUaGFuayB5 b3UuDQo+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+IEFjZSBtYWlsaW5nIGxpc3QNCj4gQWNlQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vYWNlDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCkFjZSBtYWlsaW5nIGxpc3QNCkFjZUBpZXRmLm9yZw0KaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hY2UNCklNUE9SVEFOVCBOT1RJQ0U6 IFRoZSBjb250ZW50cyBvZiB0aGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGNvbmZp ZGVudGlhbCBhbmQgbWF5IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYgeW91IGFyZSBub3QgdGhlIGlu dGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFu ZCBkbyBub3QgZGlzY2xvc2UgdGhlIGNvbnRlbnRzIHRvIGFueSBvdGhlciBwZXJzb24sIHVzZSBp dCBmb3IgYW55IHB1cnBvc2UsIG9yIHN0b3JlIG9yIGNvcHkgdGhlIGluZm9ybWF0aW9uIGluIGFu eSBtZWRpdW0uIFRoYW5rIHlvdS4NCg== From nobody Tue May 15 01:56:29 2018 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 105F3120721 for ; Tue, 15 May 2018 01:56:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 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, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DE5QH3DLS_GF for ; Tue, 15 May 2018 01:56:26 -0700 (PDT) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30050.outbound.protection.outlook.com [40.107.3.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD1DA12D77A for ; Tue, 15 May 2018 01:56:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=2wE6OSlpSg5BFuLvFBD/zuCmQdXEAReFKvcrF5JzOuI=; b=WGWuvu3yc5i5Xv/PnBZB9/1sHRPRl3LM22KlybF+Uoe9Kr+X1zGyGZlFnZq9u5CDADVmC1c8w3tZNbQfcv4VyNimgtIABlg4LwXZacBI29jFmrLpjymaAiI23+2586xQ7ITZ4aJYT5856QMA4XL5vFCtyfCsKq5Do/Zzvk25lz0= Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB1343.eurprd08.prod.outlook.com (10.167.198.7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.755.16; Tue, 15 May 2018 08:56:20 +0000 Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::7c43:c1a5:4f69:5365]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::7c43:c1a5:4f69:5365%17]) with mapi id 15.20.0755.018; Tue, 15 May 2018 08:56:18 +0000 From: Hannes Tschofenig To: "ace@ietf.org" Thread-Topic: Early media-type registration for EST over CoAP Thread-Index: AdPsKhcQ9FbwjekBT1SYYUyoYtG38g== Date: Tue, 15 May 2018 08:56:18 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [156.67.194.220] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0801MB1343; 7:aNmi02Vf4MG44n6L/AcPKx7sxt/qe6cSe0JXR6FESn1IXhKkiGMJ+1Cgt1QOfEYXKNqCInnlDp8l5mCRxLBd45IymzDcQY7tnXZr6i5SwQXZI+6Dg9IzzNZBvLubqkSbLiF54XRtATIkcV62/Ojcvzy8Xn0st1+yWcGt4XAwyjYoAeC7mlWqPBN/P1D85cQyoHDYJSRQeDHQyrTAvc2XKtPT8DA3hVlpIIZFah4uWSRmJ9yINzG3+grWlwGxZFft x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB1343; x-ms-traffictypediagnostic: VI1PR0801MB1343: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006095)(93001095)(3231254)(944501410)(52105095)(6055026)(149027)(150027)(6041310)(20161123560045)(20161123558120)(20161123564045)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:VI1PR0801MB1343; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0801MB1343; x-forefront-prvs: 0673F5BE31 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(376002)(366004)(396003)(39860400002)(39380400002)(40434004)(189003)(199004)(478600001)(3846002)(2906002)(59450400001)(6436002)(6116002)(68736007)(99286004)(33656002)(6916009)(3280700002)(106356001)(74316002)(7696005)(14454004)(316002)(3660700001)(86362001)(486006)(2900100001)(72206003)(102836004)(66066001)(25786009)(6506007)(5660300001)(9686003)(5250100002)(5890100001)(26005)(476003)(97736004)(186003)(81156014)(81166006)(7736002)(53936002)(105586002)(2501003)(5640700003)(305945005)(8936002)(8676002)(55016002)(1730700003)(2351001); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB1343; H:VI1PR0801MB2112.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:3; A:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: OqU5Uqx7SNYs3ABWxZGeGizUiwx1cfq7TQV9VmnX6sBcKaW1XB9aXs6AKOD0Fi9m32r1sTBz29t77GcwWXOROZEmOcRzaXaQOG1B1t/bMfOi+4Bb3R1NHaSYIwVdujouWjKIXXeIPQSHNBWvcvCV3aoWMr7BRfYz2T6DNh+8ltSQA/H+O1GEs79bLMy1E4W8 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: a4c20d10-8f48-497f-f8c7-08d5ba41b960 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: a4c20d10-8f48-497f-f8c7-08d5ba41b960 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 May 2018 08:56:18.7480 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1343 Archived-At: Subject: [Ace] Early media-type registration for EST over CoAP X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2018 08:56:28 -0000 I get the impression that the EST over CoAP spec will not completed as soon= as I had hoped. I am curious whether it would be possible to ask for early media-type regis= tration of at least these two types: - application/pkcs7-mime - application/pkcs10 Ciao Hannes IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. From nobody Tue May 15 02:05:00 2018 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 212B612D7E6 for ; Tue, 15 May 2018 02:04:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QQ9S8oOReBx9 for ; Tue, 15 May 2018 02:04:55 -0700 (PDT) Received: from smtp-out11.electric.net (smtp-out11.electric.net [185.38.181.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 082FA12D77A for ; Tue, 15 May 2018 02:04:55 -0700 (PDT) Received: from 1fIVt6-0004w5-Tn by out11a.electric.net with emc1-ok (Exim 4.90_1) (envelope-from ) id 1fIVt6-0004yN-Ve; Tue, 15 May 2018 02:04:52 -0700 Received: by emcmailer; Tue, 15 May 2018 02:04:52 -0700 Received: from [194.218.146.197] (helo=sp-mail-2.sp.se) by out11a.electric.net with esmtps (TLSv1.2:ECDHE-RSA-AES128-SHA256:128) (Exim 4.90_1) (envelope-from ) id 1fIVt6-0004w5-Tn; Tue, 15 May 2018 02:04:52 -0700 Received: from [192.168.0.166] (10.116.0.226) by sp-mail-2.sp.se (10.100.0.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1261.35; Tue, 15 May 2018 11:04:52 +0200 To: "ace@ietf.org" CC: Cigdem Sengul , Anthony Kirby , From: Ludwig Seitz Message-ID: <99638740-7df6-c646-29bf-a3b295213396@ri.se> Date: Tue, 15 May 2018 11:04:51 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.116.0.226] X-ClientProxiedBy: sp-mail-3.sp.se (10.100.0.163) To sp-mail-2.sp.se (10.100.0.162) X-Outbound-IP: 194.218.146.197 X-Env-From: ludwig.seitz@ri.se X-Proto: esmtps X-Revdns: X-HELO: sp-mail-2.sp.se X-TLS: TLSv1.2:ECDHE-RSA-AES128-SHA256:128 X-Authenticated_ID: X-PolicySMART: 14510320 X-Virus-Status: Scanned by VirusSMART (c) X-Virus-Status: Scanned by VirusSMART (s) Archived-At: Subject: [Ace] Review of draft-sengul-ace-mqtt-tls-profile-02 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2018 09:04:58 -0000 Hello ACE, I've reviewed draft-sengul-ace-mqtt-tls-profile-02. I think this is a very relevant draft, due to the amount of IoT devices that use MQTT. I would encourage the WG to pick this up as the third profile of draft-ietf-ace-oauth-authz Detailed comments below. /Ludwig 1. Introduction " Section 4 of the ACE framework [I-D.ietf-ace-oauth-authz]" If you make that "Section 4 of [I-D.ietf-ace-oauth-authz]" the IETF html-izer will not turn this into a link to section 4 of your draft (I think). See: https://xml2rfc.tools.ietf.org/xml2rfcFAQ.html#anchor18 1.1. Requirements Language There is a new recommendation how this section should be worded: "The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here." 1.2. ACE-Related Terminology "The term "Resource" is used to refer to an MQTT "topic", which is defined in Section 1.2." This references back to the same section, perhaps this was meant to reference to some other part of the draft? 2.1. Authorizing Connection Establishment Figure 1 could clarify that steps E and F are optional. 2.1.1. Client Authorization Server (CAS) and Authorization Server (AS) Interaction "and the client is authorized to obtain a token for the indicated audience (e.g., topics) and scopes (e.g., publish/subscribe permissions)" Note that the audience claim is typically used to identify the RS (so in this case the MQTT broker), while the scope is intended to identify both the resource (=topic) and the actions (=publish, subscribe). See this for how OAuth scopes are typically used: https://www.brandur.org/oauth-scope "This includes a token, which is assumed to be PoP by default." The abbreviation PoP is not defined at this point, I would write it out as in "... assumed to be a Proof-of-Possession (PoP) token ..." 2.1.2. Client connection request to the broker " For the basic operation described in this section, the Username field MUST be set to the token." I think this refers to the access token right? I'd suggest to be more specific, since there is room for confusion (CoAP has also the concept of a token, and then OAuth has different types of tokens, the access token being one of them). "The Password field MUST be set to the keyed message digest (MAC) or signature." Please make it explicit already here that this is the Proof-of-possession mechanism for the key associated to the token. "(The Username field is a UTF-8 encoded string," You need to specify how the (possibly binary) access token is supposed to be converted into an UTF-8 string. Base64 encoding would be obvious, but it needs to be explicitly stated. General comment: An example of how the CONNECT message could look like would be good. 2.1.3. Token validation "The broker MAY cache the introspection result because it will need to decide whether to accept subsequent PUBLISH and SUBSCRIBE messages" This could warrant a section in the security considerations about the trade-off of caching introspection results (freshness vs. connectivity requirements). "If the introspection result is not cached, then the RS needs to introspect the saved token for each request." This is only true if the token is not self-contained. I would rephrase this statement "Note: Scope strings MAY follow ..." Note that a scope is a "space-delimited list strings" (OAuth 2.0 3.3.) so you could include several topics in one scope as in e.g. "connect publish_topic1 publish_topic2 subsrcibe_topic3" The use of 'aud' as described in this paragraph is definitely not the intended use, and I would not recommend this type of use. See https://tools.ietf.org/html/rfc7519#section-4.1.3 for the definition of aud. 2.4. Token expiration "The token validation is done either by checking the 'exp' claim of a CWT/JWT or via performing an introspection request with the Authorization server as described in Section 8.2 of the ACE framework [I-D.ietf-ace-oauth-authz]." The word "token validation" here could be misconstrued to ignoring crypto wrappers, token issuers ect. While it is clear from the context (to me) that you only refer to checking the expiration of a token, the full validation of a token would include the following steps: 1. Check that the issuer of the token (= AS) is acceptable 2. Check the cryptographic wrapper of the token (may be MAC or signature or AEAD encryption) 3. Check that the token contains all expected claims 4. Check that the "exp" and "nbf" claims are fulfilled if present 5. Check that the "aud" claim applies to the recipient if present 3.1. Token Transport via Authentication Exchange (AUTH) "The first option is that Authentication data contains both the token and the keyed message digest (MAC) or signature as described in Section 2.1.2." You need to specify how these two items are encoded. I would suggest a CBOR array since this property expects binary data. An example would also be very helpful here. "... RS responds with a CONNACK reason code '0x87 (Not Authorized)' and includes a User Property set to the address of the AS." You need to specify the format of this user property, in order to mirror the framework's section 5.1.2. I guess you could use either a JSON map or binary data containing a CBOR map for this. 4. IANA Considerations " This memo includes no request to IANA." This should instead register the new profile identifier "mqtt_tls" in the soon-to-be-created IANA registry for ACE profile identifiers. See the DTLS profile for example: https://tools.ietf.org/html/draft-ietf-ace-dtls-authorize-03#section-7 5. Security Considerations You should add some text here about the security implications of the limitations of MQTT v3.1 (client disconnect only). I could imagine that you could perform some attacks on a client that hasn't realized it was disconnected for example. -- Ludwig Seitz, PhD Security Lab, RISE SICS Phone +46(0)70-349 92 51 From nobody Tue May 15 02:34:18 2018 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DE2112D7F9 for ; Tue, 15 May 2018 02:34:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 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, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iA9ph_g1E9PD for ; Tue, 15 May 2018 02:34:13 -0700 (PDT) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40077.outbound.protection.outlook.com [40.107.4.77]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FE1E12DA27 for ; Tue, 15 May 2018 02:34:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=4Z6BY5lzvTLF2QkWMQF4fkUmlMGTyG0Sv6D6d6+clks=; b=JM/20HZj9de3O3nCgMxgrtjeKzD2JZtv/IYQPMzusLK0L8diDB0rCSUhOHS21yACi16QvQlPn8x9Ee23VK62tukfcY2i8n+FzwcY5ibyfVw72icSmvRe82FCBJRA1Yo5q298mX6igiUiDM6PZDpLEiO8M43s/e7PF9fR7vRJfyA= Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB1774.eurprd08.prod.outlook.com (10.168.67.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.755.16; Tue, 15 May 2018 09:34:09 +0000 Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::7c43:c1a5:4f69:5365]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::7c43:c1a5:4f69:5365%17]) with mapi id 15.20.0755.018; Tue, 15 May 2018 09:34:09 +0000 From: Hannes Tschofenig To: "ace@ietf.org" Thread-Topic: EST over CoAP: Introduction Thread-Index: AdPsLs4i7p+ZRhEOTMSeKeo6haRT5Q== Date: Tue, 15 May 2018 09:34:09 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [156.67.194.220] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0801MB1774; 7:gD/sSzj9TP4uAfABLitS/H6egf+O+tpGYIrLKveQkEm/iawIz+tfxUgPAItqapzynHuQXqYAIvMT7JxtbLq1iR2GRN5xdbAJLu41NLxJGccGXvVDtOFiQj5h0TsjpZTSMzp/A5AxpQq2gUy7H/7VtbDe5csBZnknufSAv+CdSgbRPLqucR/gztcm8lbdGG6V1JgKqNA+hTExJccy1IUzF9p77cexzaOPhfuSoAfm3gZ0nCQerEEjl8v/KbhwPx3I x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(48565401081)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB1774; x-ms-traffictypediagnostic: VI1PR0801MB1774: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(788757137089)(21748063052155); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3002001)(93006095)(93001095)(10201501046)(3231254)(944501410)(52105095)(6055026)(149027)(150027)(6041310)(20161123558120)(20161123562045)(20161123560045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:VI1PR0801MB1774; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0801MB1774; x-forefront-prvs: 0673F5BE31 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(39860400002)(346002)(396003)(39380400002)(366004)(189003)(199004)(40434004)(2906002)(5250100002)(6506007)(7736002)(53936002)(9686003)(316002)(7696005)(6916009)(3280700002)(66066001)(81156014)(8676002)(3660700001)(81166006)(1730700003)(8936002)(54896002)(6436002)(2351001)(6306002)(55016002)(59450400001)(5890100001)(74316002)(5640700003)(2501003)(26005)(5660300001)(186003)(102836004)(6116002)(790700001)(99286004)(561944003)(86362001)(33656002)(3846002)(25786009)(68736007)(5630700001)(105586002)(106356001)(486006)(97736004)(476003)(478600001)(2900100001)(14454004)(72206003); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB1774; H:VI1PR0801MB2112.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: OopSCoilt3oJOgPK8kcRiD69Ly84MT0Q9UiwMZIG5PNXeagcc37OeFV5BxzC0C0S9VXGWLM4Au5STSO+7uUFYF7KDAtDhg8piTxKxNRkL975JjXxx4tNdS8Q9IMAAZsU7Wp9laWZoKO/lCED7HpyhpXNu6nDv4rAiBXbx6DURUxJMdxyafk8N+XNlfDVSl1W spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_VI1PR0801MB2112FC1E76250C571880958EFA930VI1PR0801MB2112_" MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 1df032c7-017b-4011-dcfe-08d5ba47029d X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: 1df032c7-017b-4011-dcfe-08d5ba47029d X-MS-Exchange-CrossTenant-originalarrivaltime: 15 May 2018 09:34:09.0887 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1774 Archived-At: Subject: [Ace] EST over CoAP: Introduction X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2018 09:34:16 -0000 --_000_VI1PR0801MB2112FC1E76250C571880958EFA930VI1PR0801MB2112_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Here is a proposal to change the introduction to the relevant parts only an= d to avoid repetition. (The current document still keeps talking about IEEE 802.15.4 when there ar= e so many other radio technologies as well. There is nothing in this spec that makes this 15.4 specific. I understand t= hat some of the authors really like 15.4 but ....) Here is my proposal to replace Section 1 and Section 1.1: ----- 1. Introduction "Classical" Enrollment over Secure Transport (EST) [RFC7030] is used for authenticated/authorized endpoint certificate enrollment (and optionally key provisioning) through a Certificate Authority (CA) or Registration Authority (RA). It uses HTTPS. This specification defines a new transport for EST based on the Constrained Application Protocol (CoAP) since some Internet of Things (I= oT) devices use CoAP instead of HTTP. This specification therefore utilizes = DTLS [RFC6347], CoAP [RFC7252], and UDP instead of TLS [RFC5246], HTTP [RFC7230] and TCP= . This document also profiles EST and only supports certificate-based clie= nt Authentication. The results are: * The EST-coaps client does not support HTTP Basic authentication (as described in Section 3.2.3 of [RFC7030]). * The EST-coaps client does not support authentication at the application layer (as described in Section 3.2.3 of [RFC7030]). EST messages may be relatively large and for this reason this document re-uses CoAP Block-Wise Transfer [RFC7959] to offer a fragmentation mechanism of EST messages at the CoAP layer. ----- Ciao Hannes IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. --_000_VI1PR0801MB2112FC1E76250C571880958EFA930VI1PR0801MB2112_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Here is a proposal to change the introduction to the= relevant parts only and to avoid repetition.

(The current document still keeps talking about IEEE= 802.15.4 when there are so many other radio technologies as well.

There is nothing in this spec that makes this 15.4 s= pecific. I understand that some of the authors really like 15.4 but …= .)

 

Here is my proposal to replace Section 1 and Section= 1.1:

 

-----

 

1.  Introduction

 

   "Classical" Enrollment over S= ecure Transport (EST) [RFC7030] is used for

   authenticated/authorized endpoint certi= ficate enrollment (and

   optionally key provisioning) through a = Certificate Authority (CA) or

   Registration Authority (RA).  It u= ses HTTPS.

 

   This specification defines a new t= ransport for EST based on the

   Constrained Application Protocol (= CoAP) since some Internet of Things (IoT)

   devices use CoAP instead of HTTP. = This specification therefore utilizes DTLS [RFC6347],

   CoAP [RFC7252], and UDP instead of= TLS [RFC5246], HTTP [RFC7230] and TCP.

 

   This document also profiles EST and onl= y supports certificate-based client

   Authentication. The results are: <= o:p>

   

      *  The EST-= coaps client does not support HTTP Basic authentication

         (as= described in Section 3.2.3 of [RFC7030]).

 

      *  The EST-coaps= client does not support authentication at the

         app= lication layer (as described in Section 3.2.3 of [RFC7030]).

  

   EST messages may be relatively lar= ge and for this reason this

   document re-uses CoAP Block-Wise Transf= er [RFC7959] to

   offer a fragmentation mechanism of= EST messages at the CoAP layer.

 

-----

 

Ciao

Hannes

 

IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in any medium. Thank you. --_000_VI1PR0801MB2112FC1E76250C571880958EFA930VI1PR0801MB2112_-- From nobody Tue May 15 02:45:23 2018 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE42112D883; Tue, 15 May 2018 02:45:21 -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, 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 4-P6zgaZkTlx; Tue, 15 May 2018 02:45:19 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A3EA12D7F9; Tue, 15 May 2018 02:45:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w4F9jEqZ028282; Tue, 15 May 2018 11:45:14 +0200 (CEST) Received: from [192.168.217.102] (p5DC7F793.dip0.t-ipconnect.de [93.199.247.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 40lXjk2dVSzDXX1; Tue, 15 May 2018 11:45:14 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Carsten Bormann In-Reply-To: Date: Tue, 15 May 2018 11:45:13 +0200 Cc: "ace@ietf.org" , core X-Mao-Original-Outgoing-Id: 548070311.775547-263e1e3fb306d3ae62df1f2f68b3fd0f Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Hannes Tschofenig X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [Ace] Early media-type registration for EST over CoAP X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2018 09:45:22 -0000 On May 15, 2018, at 10:56, Hannes Tschofenig = wrote: >=20 > I am curious whether it would be possible to ask for early media-type = registration of at least these two types: > - application/pkcs7-mime > - application/pkcs10 There already are registered. I think you are talking about getting Content-Format numbers for these? Do we need any parameters or content-codings with that? Gr=C3=BC=C3=9Fe, Carsten From nobody Tue May 15 06:47:07 2018 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42E8112D954 for ; Tue, 15 May 2018 06:47:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2tGTa4wO2_cV for ; Tue, 15 May 2018 06:47:02 -0700 (PDT) Received: from smtp-out10.electric.net (smtp-out10.electric.net [185.38.180.34]) (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 864B712DA2C for ; Tue, 15 May 2018 06:47:02 -0700 (PDT) Received: from 1fIaI6-0006YQ-U0 by out10c.electric.net with emc1-ok (Exim 4.90_1) (envelope-from ) id 1fIaI6-0006ZS-Un for ace@ietf.org; Tue, 15 May 2018 06:46:58 -0700 Received: by emcmailer; Tue, 15 May 2018 06:46:58 -0700 Received: from [194.218.146.197] (helo=sp-mail-2.sp.se) by out10c.electric.net with esmtps (TLSv1.2:ECDHE-RSA-AES128-SHA256:128) (Exim 4.90_1) (envelope-from ) id 1fIaI6-0006YQ-U0 for ace@ietf.org; Tue, 15 May 2018 06:46:58 -0700 Received: from [192.168.0.166] (10.116.0.226) by sp-mail-2.sp.se (10.100.0.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1261.35; Tue, 15 May 2018 15:46:58 +0200 To: References: <005601d3e622$af427100$0dc75300$@augustcellars.com> From: Ludwig Seitz Message-ID: Date: Tue, 15 May 2018 15:46:52 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <005601d3e622$af427100$0dc75300$@augustcellars.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.116.0.226] X-ClientProxiedBy: sp-mail-2.sp.se (10.100.0.162) To sp-mail-2.sp.se (10.100.0.162) X-Outbound-IP: 194.218.146.197 X-Env-From: ludwig.seitz@ri.se X-Proto: esmtps X-Revdns: X-HELO: sp-mail-2.sp.se X-TLS: TLSv1.2:ECDHE-RSA-AES128-SHA256:128 X-Authenticated_ID: X-PolicySMART: 14510320 X-Virus-Status: Scanned by VirusSMART (c) X-Virus-Status: Scanned by VirusSMART (s) Archived-At: Subject: Re: [Ace] OAuth-Authz Interop X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2018 13:47:06 -0000 On 2018-05-07 18:44, Jim Schaad wrote: > I have been meaning to get this out for a while and have failed. A doodle > poll to setup an interop event for this work is at > https://doodle.com/poll/k27g9r26bghvnytu If you want to participate and none > of the times are good please let me know. > > Things for testing: > 1) DTLS profile w/ shared secret > 2) DTLS profile w/ RPK > 3) OSCORE profile > The dates Jim has proposed in the doodle are quite close already, and the poll is still quite empty. Is there any specific reason why the other implementers won't/cannot commit to this at this point in time? /Ludwig -- Ludwig Seitz, PhD Security Lab, RISE SICS Phone +46(0)70-349 92 51 From nobody Tue May 15 07:01:04 2018 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BC1312DA2C for ; Tue, 15 May 2018 07:01:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.499 X-Spam-Level: X-Spam-Status: No, score=-14.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rIawxb2AoVsQ for ; Tue, 15 May 2018 07:00:57 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6414B12DA28 for ; Tue, 15 May 2018 07:00:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20417; q=dns/txt; s=iport; t=1526392852; x=1527602452; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=6+2ut3fKkoRH6FMCx66GjANPbXVWUcFhxlr8KLrurSc=; b=HKrDhJoGq/NDFlWCbf/kspZpPfqwfyVeiVANQb24zbGb9+0kGaVwarVd LluhUsZQt4LsTQyz3i8Y+iZ+mJQQ+ETWv01HODgi3wppmJPFMFY1XXEm8 bday9uYMXFHb8xIyd9+UmEI1gqNd6FCrdPh7TR5M27T9Zmd9BhMWF+LHN k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AdAQCp5/pa/4sNJK1TCRkBAQEBAQE?= =?us-ascii?q?BAQEBAQEHAQEBAQGCTUsrYXwoCoVJhiWMcoF5gQ+TMhSBZAsYAQyDEIE3AoM?= =?us-ascii?q?YITQYAQIBAQEBAQECbBwMhSgBAQEEAQErQQICFwIBCBEEAQEhBwcnCxQJCAE?= =?us-ascii?q?BBAEJCQiDHYEbZA+tKh+IKoIiBYcofYFUPyVqgwuCbyIBAQOBIQkBCAoBCSQ?= =?us-ascii?q?eCgKFHAKHIIlqhy8JAoVlhTmDKoE+GoNMh1WJV4ZnAhETAYEkARw4YXFwFTu?= =?us-ascii?q?CQ4FwgUEBAodchT5vAQuNB4EfgRgBAQ?= X-IronPort-AV: E=Sophos;i="5.49,403,1520899200"; d="scan'208,217";a="398699920" Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 May 2018 14:00:37 +0000 Received: from XCH-RCD-010.cisco.com (xch-rcd-010.cisco.com [173.37.102.20]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id w4FE0b67016214 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 15 May 2018 14:00:37 GMT Received: from xch-aln-010.cisco.com (173.36.7.20) by XCH-RCD-010.cisco.com (173.37.102.20) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 15 May 2018 09:00:36 -0500 Received: from xch-aln-010.cisco.com ([173.36.7.20]) by XCH-ALN-010.cisco.com ([173.36.7.20]) with mapi id 15.00.1320.000; Tue, 15 May 2018 09:00:36 -0500 From: "Panos Kampanakis (pkampana)" To: Mohit Sethi , "ace@ietf.org" Thread-Topic: [Ace] EST over CoAP Thread-Index: AdPrYipD0kyce1IOREqwxYCd2nFDSgAKCPZwACuX5AAABvG3MA== Date: Tue, 15 May 2018 14:00:36 +0000 Message-ID: References: <068f2690-e1a1-b225-463a-4048e06365af@ericsson.com> In-Reply-To: <068f2690-e1a1-b225-463a-4048e06365af@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.150.34.232] Content-Type: multipart/alternative; boundary="_000_c478ad350e0b416eaffbdd526fd3616eXCHALN010ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Ace] EST over CoAP X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2018 14:01:02 -0000 --_000_c478ad350e0b416eaffbdd526fd3616eXCHALN010ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Mohit, These priv/public keypairs+cert are provisioned and used on the endpoint as= identity for authentication. If tamper-resistance is not supported on the = endpoint, the keypairs could be reprovisioned more often than the tradition= al cert lifetime as the server-side key gen transaction does not incur sign= ificant workload to the endpoint itself. Rgs, Panos From: Mohit Sethi [mailto:mohit.m.sethi@ericsson.com] Sent: Tuesday, May 15, 2018 1:37 AM To: Panos Kampanakis (pkampana) ; Hannes Tschofenig ; ace@ietf.org Subject: Re: [Ace] EST over CoAP Hi Panos, How do you intend to use these server generated keys once they are provisio= ned onto the device? --Mohit On 05/14/2018 04:58 PM, Panos Kampanakis (pkampana) wrote: Hi Hannes, To address your question about server-side key gen, below is the explanatio= n we have put in the draft already and will be in the next iteration ~~~~~~~~~~~~~ Constrained devices sometimes do not have the necessary hardware to generate statistically random numbers for private keys and DTLS ephemeral keys. Past experience has shown that cheap endpoints sometimes generate numbers which could allow someone to decrypt the communication or guess the private key and impersonate as the device. Studies have shown that the same keys are generated by the same model devices deployed on-line. Additionally, random number key generation is costly, thus energy draining. Even though the random numbers that constitute the identity/cert do not get generated often, an endpoint may not want to spend time and energy generating keypairs, and just ask for one from the server. In these scenarios, server-side key generation can be used. The client asks for the server or proxy to generate the private key and the certificate which is transferred back to the client in the server-side key generation response. ~~~~~~~~~~~~~ This is a need that we have heard from customers at Cisco. About the proxy-Registrar question, we already have made the change in the = working copy of the draft as well. We no longer call this functionality pro= xying, but instead use the concept of the registrar that terminates the con= nection and establishes the next one. We didn't add any new features in the doc after removing the BRSKI stuff. If you want an early preview to comment on, we can share the repository wit= h you. Panos From: Ace [mailto:ace-bounces@ietf.org] On Behalf Of Hannes Tschofenig Sent: Monday, May 14, 2018 5:05 AM To: ace@ietf.org Subject: [Ace] EST over CoAP Hi all, At IETF#101 Peter presented a list of open issues with the EST over CoAP dr= aft, see https://datatracker.ietf.org/meeting/101/materials/slides-101-ace-est-over-= secure-coap-00 - Operational parameter values - Server side key generation using simple multipart encoding - Explain trust relations for http/coap proxying I have challenged the usefulness of the server-side key generation during t= he meeting but in general I am curious where we are with the document. It w= ould be great to get it finalized. It appears that we are adding new featur= es and therefore will not be able to complete the work in any reasonable ti= meframe. So, do we have a plan for how to complete the document? Ciao Hannes IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged.. If you are not the intended recipient, = please notify the sender immediately and do not disclose the contents to an= y other person, use it for any purpose, or store or copy the information in= any medium. Thank you. _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace --_000_c478ad350e0b416eaffbdd526fd3616eXCHALN010ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Mohit,

These priv/public keyp= airs+cert are provisioned and used on the endpoint as identity for auth= entication. If tamper-resistance is not supported on the endpoint, the keyp= airs could be reprovisioned more often than the traditional cert lifetime as the server-side key gen transaction does = not incur significant workload to the endpoint itself.

Rgs,=

Panos

 

From:= Mohit Sethi [mailto:mohit.m.sethi@ericsso= n.com]
Sent: Tuesday, May 15, 2018 1:37 AM
To: Panos Kampanakis (pkampana) <pkampana@cisco.com>; Hannes T= schofenig <Hannes.Tschofenig@arm.com>; ace@ietf.org
Subject: Re: [Ace] EST over CoAP

 

Hi Panos,

How do you intend to use these server generated keys once they are provi= sioned onto the device?

--Mohit

 

On 05/14/2018 04:58 PM, Panos Kampanakis (pkampana) = wrote:

Hi Hannes,

 

To address your questi= on about server-side key gen, below is the explanation we have put in the d= raft already and will be in the next iteration
~~~~~~~~~~~~~

&n= bsp;  Constrained devices sometimes do not have the necessary hardware= to

&n= bsp;  generate statistically random numbers for private keys and DTLS<= /span>

&n= bsp;  ephemeral keys.  Past experience has shown that cheap endpo= ints

&n= bsp;  sometimes generate numbers which could allow someone to decrypt = the

&n= bsp;  communication or guess the private key and impersonate as the de= vice.

&n= bsp;  Studies have shown that the same keys are generated by the same = model

&n= bsp;  devices deployed on-line.

&n= bsp;

&n= bsp;  Additionally, random number key generation is costly, thus energ= y

&n= bsp;  draining.  Even though the random numbers that constitute t= he

&n= bsp;  identity/cert do not get generated often, an endpoint may not wa= nt to

&n= bsp;  spend time and energy generating keypairs, and just ask for one = from

&n= bsp;  the server.

&n= bsp;

&n= bsp;  In these scenarios, server-side key generation can be used. = ; The

&n= bsp;  client asks for the server or proxy to generate the private key = and

&n= bsp;  the certificate which is transferred back to the client in the

&n= bsp;  server-side key generation response.
~~~~~~~~~~~~~=

 

This is a need that we= have heard from customers at Cisco.

 

About the proxy-Regist= rar question, we already have made the change in the working copy of the dr= aft as well. We no longer call this functionality proxying, but instead use= the concept of the registrar that terminates the connection and establishes the next one.

 

We didn’t add an= y new features in the doc after removing the BRSKI stuff.  

 

If you want an early p= review to comment on, we can share the repository with you.

 

Panos

 

From: Ace [mailto:ace-bounces@ietf.org] On Behalf Of Hannes Tschofenig
Sent: Monday, May 14, 2018 5:05 AM
To: ace@ietf.org
Subject: [Ace] EST over CoAP

 

Hi all,

 

At IETF#101 Peter presented a l= ist of open issues with the EST over CoAP draft, see

http= s://datatracker.ietf.org/meeting/101/materials/slides-101-ace-est-over-secu= re-coap-00

 

-     &= nbsp;  Operational parameter values

-     &= nbsp;  Server side key generation usi= ng simple multipart encoding

-     &= nbsp;  Explain trust relations for ht= tp/coap proxying

 

I have challenged the usefulnes= s of the server-side key generation during the meeting but in general I am = curious where we are with the document. It would be great to get it finaliz= ed. It appears that we are adding new features and therefore will not be able to complete the work in any reason= able timeframe.

 

So, do we have a plan for how t= o complete the document?

 

Ciao

Hannes

 

IMPORTANT NOTICE: The cont= ents of this email and any attachments are confidential and may also be pri= vileged.. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to a= ny other person, use it for any purpose, or store or copy the information i= n any medium. Thank you. 




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

 

--_000_c478ad350e0b416eaffbdd526fd3616eXCHALN010ciscocom_-- From nobody Tue May 15 07:16:08 2018 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F25D612DA2C for ; Tue, 15 May 2018 07:16:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, 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=armh.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tOFELsF6arhm for ; Tue, 15 May 2018 07:15:59 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0045.outbound.protection.outlook.com [104.47.0.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3ACFA12DA28 for ; Tue, 15 May 2018 07:15:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=WqC6Et1otna1rK3G9MkBZwNPd8gktrUW1KQagycKV4c=; b=MQh+bmoDDqBogNVWHBaAuMx8W3W4n8IUES1gOD4gnoOayxCBxUi+fuyZIcTCmdoQyASWsJAzcjz9oW527FVgT/t7TyIPv6got9ttT+rXs5Zt4VAMp5vjjcQ+IFxKR0wYlIrgtYmqkCUAEc8HmOr5Gm5yXl30oJffwOdF3FM6sPQ= Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB1392.eurprd08.prod.outlook.com (10.167.198.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.755.16; Tue, 15 May 2018 14:15:53 +0000 Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::7c43:c1a5:4f69:5365]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::7c43:c1a5:4f69:5365%17]) with mapi id 15.20.0755.018; Tue, 15 May 2018 14:15:53 +0000 From: Hannes Tschofenig To: "Panos Kampanakis (pkampana)" , Mohit Sethi , "ace@ietf.org" Thread-Topic: [Ace] EST over CoAP Thread-Index: AdPrYipD0kyce1IOREqwxYCd2nFDSgAKCPZwACEdrwAAEZULAAAAeJoQ Date: Tue, 15 May 2018 14:15:53 +0000 Message-ID: References: <068f2690-e1a1-b225-463a-4048e06365af@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [156.67.194.220] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0801MB1392; 7:9TPJvHTEDfptqhycJRFGIrMi6rqFWNDxAvEy2S6eIZJ+M5DoZnjhin5kr9AX64X/i7EBjoRpIOoBF7RglBG1fSp1AtYQEVGl11pBFJvXbN2ncN5Q0bV5s0XGThplDdRNmiX02eTC0uqM7cKQMJYjM2SM4ntY7vy1ePzu7v/f7aPzcQ23IjJuDT/WayJCP+gJKnWFFxocWEqurqz4KBBRORRmHxbBcIFirf+2bXFCbMgDPts6cz1pypuWDj/wnohS x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(48565401081)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB1392; x-ms-traffictypediagnostic: VI1PR0801MB1392: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(28532068793085)(158342451672863)(180628864354917)(120809045254105)(95692535739014)(21748063052155); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006095)(93001095)(3231254)(944501410)(52105095)(6055026)(149027)(150027)(6041310)(20161123560045)(20161123558120)(20161123564045)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:VI1PR0801MB1392; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0801MB1392; x-forefront-prvs: 0673F5BE31 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(396003)(39380400002)(366004)(376002)(39860400002)(40434004)(189003)(199004)(53754006)(86362001)(6246003)(3660700001)(5250100002)(11346002)(446003)(102836004)(476003)(54896002)(606006)(3280700002)(6306002)(55016002)(5890100001)(53546011)(6506007)(316002)(25786009)(486006)(93886005)(2501003)(236005)(478600001)(8676002)(2906002)(72206003)(26005)(66066001)(3846002)(53936002)(5660300001)(74316002)(2900100001)(105586002)(110136005)(59450400001)(8936002)(7736002)(966005)(229853002)(81166006)(99286004)(97736004)(76176011)(186003)(551934003)(6436002)(33656002)(81156014)(68736007)(6116002)(9686003)(14454004)(7696005)(790700001)(106356001); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB1392; H:VI1PR0801MB2112.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: s4pI/SdTrvvcIA0vQ4LgG2ZQ3FZqLMzEYACHb1LrFKLHbs4XuM4+g8IV+KJUgGxBHNBmUHAdro2nMHfcixx0+TGKOHajZgacG46NRNJpv75V2X1hDXQgQScaF4qyN14egMeXa3qZJ+7fQiM5mSuKtUUICjqoArJ6ckeEAXdOQjOiM3VmXeOfA4bl1P32MKuf spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_VI1PR0801MB2112C9B4B7B1C3ABFC475DE9FA930VI1PR0801MB2112_" MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 1f5f94d7-99da-4296-6afd-08d5ba6e5e54 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: 1f5f94d7-99da-4296-6afd-08d5ba6e5e54 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 May 2018 14:15:53.2990 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1392 Archived-At: Subject: Re: [Ace] EST over CoAP X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2018 14:16:07 -0000 --_000_VI1PR0801MB2112C9B4B7B1C3ABFC475DE9FA930VI1PR0801MB2112_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable FWIW I would untangle the tamper resistance property from the lifetime of t= hese keys. You will want to issue new keys periodically anyway. From: Ace [mailto:ace-bounces@ietf.org] On Behalf Of Panos Kampanakis (pkam= pana) Sent: 15 May 2018 16:01 To: Mohit Sethi; ace@ietf.org Subject: Re: [Ace] EST over CoAP Hi Mohit, These priv/public keypairs+cert are provisioned and used on the endpoint as= identity for authentication. If tamper-resistance is not supported on the = endpoint, the keypairs could be reprovisioned more often than the tradition= al cert lifetime as the server-side key gen transaction does not incur sign= ificant workload to the endpoint itself. Rgs, Panos From: Mohit Sethi [mailto:mohit.m.sethi@ericsson.com] Sent: Tuesday, May 15, 2018 1:37 AM To: Panos Kampanakis (pkampana) >; Hannes Tschofenig >; ace@ietf.org Subject: Re: [Ace] EST over CoAP Hi Panos, How do you intend to use these server generated keys once they are provisio= ned onto the device? --Mohit On 05/14/2018 04:58 PM, Panos Kampanakis (pkampana) wrote: Hi Hannes, To address your question about server-side key gen, below is the explanatio= n we have put in the draft already and will be in the next iteration ~~~~~~~~~~~~~ Constrained devices sometimes do not have the necessary hardware to generate statistically random numbers for private keys and DTLS ephemeral keys. Past experience has shown that cheap endpoints sometimes generate numbers which could allow someone to decrypt the communication or guess the private key and impersonate as the device. Studies have shown that the same keys are generated by the same model devices deployed on-line. Additionally, random number key generation is costly, thus energy draining. Even though the random numbers that constitute the identity/cert do not get generated often, an endpoint may not want to spend time and energy generating keypairs, and just ask for one from the server. In these scenarios, server-side key generation can be used. The client asks for the server or proxy to generate the private key and the certificate which is transferred back to the client in the server-side key generation response. ~~~~~~~~~~~~~ This is a need that we have heard from customers at Cisco. About the proxy-Registrar question, we already have made the change in the = working copy of the draft as well. We no longer call this functionality pro= xying, but instead use the concept of the registrar that terminates the con= nection and establishes the next one. We didn't add any new features in the doc after removing the BRSKI stuff. If you want an early preview to comment on, we can share the repository wit= h you. Panos From: Ace [mailto:ace-bounces@ietf.org] On Be= half Of Hannes Tschofenig Sent: Monday, May 14, 2018 5:05 AM To: ace@ietf.org Subject: [Ace] EST over CoAP Hi all, At IETF#101 Peter presented a list of open issues with the EST over CoAP dr= aft, see https://datatracker.ietf.org/meeting/101/materials/slides-101-ace-est-over-= secure-coap-00 - Operational parameter values - Server side key generation using simple multipart encoding - Explain trust relations for http/coap proxying I have challenged the usefulness of the server-side key generation during t= he meeting but in general I am curious where we are with the document. It w= ould be great to get it finalized. It appears that we are adding new featur= es and therefore will not be able to complete the work in any reasonable ti= meframe. So, do we have a plan for how to complete the document? Ciao Hannes IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged.. If you are not the intended recipient, = please notify the sender immediately and do not disclose the contents to an= y other person, use it for any purpose, or store or copy the information in= any medium. Thank you. _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf..org/mailman/listinfo/ace IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. --_000_VI1PR0801MB2112C9B4B7B1C3ABFC475DE9FA930VI1PR0801MB2112_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

FWIW I would untangle = the tamper resistance property from the lifetime of these keys.

You will want to issue= new keys periodically anyway.

 

From:= Ace [mailto:ace-bou= nces@ietf.org] On Behalf Of Panos Kampanakis (pkampana)
Sent: 15 May 2018 16:01
To: Mohit Sethi; ace@ietf.org
Subject: Re: [Ace] EST over CoAP

 

Hi Mohi= t,

These p= riv/public keypairs+cert are provisioned and used on the endpoint as id= entity for authentication. If tamper-resistance is not supported on the end= point, the keypairs could be reprovisioned more often than the traditional cert lifetime as the server-side key gen t= ransaction does not incur significant workload to the endpoint itself.

Rgs,

Panos

&n= bsp;

F= rom: Mohit Sethi= [mailto:mohit.m.sethi@ericss= on.com]
Sent: Tuesday, May 15, 2018 1:37 AM
To: Panos Kampanakis (pkampana) <pkampana@cisco.com>; Hannes Tschofenig <Hannes.Tschofenig@arm.com>; ace@ietf.org
Subject: Re: [Ace] EST over CoAP

 

Hi Panos,

How do you intend to use these server generated key= s once they are provisioned onto the device?

--Mohit

 

On 05/14/2018 04:58 PM, Panos K= ampanakis (pkampana) wrote:

Hi Hann= es,

 <= /span>

To addr= ess your question about server-side key gen, below is the explanation we ha= ve put in the draft already and will be in the next iteration
~~~~~~~~~~~~~

   Constrained devices sometimes do not have the nec= essary hardware to

   generate statistically random numbers for private= keys and DTLS

   ephemeral keys.  Past experience has shown t= hat cheap endpoints

   sometimes generate numbers which could allow some= one to decrypt the

   communication or guess the private key and impers= onate as the device.

   Studies have shown that the same keys are generat= ed by the same model

   devices deployed on-line.

 

   Additionally, random number key generation is cos= tly, thus energy

   draining.  Even though the random numbers th= at constitute the

   identity/cert do not get generated often, an endp= oint may not want to

   spend time and energy generating keypairs, and ju= st ask for one from

   the server.<= /o:p>

 

   In these scenarios, server-side key generation ca= n be used.  The

   client asks for the server or proxy to generate t= he private key and

   the certificate which is transferred back to the = client in the

   server-side key generation response.
~~~~~~~~~~~~~=

 <= /span>

This is= a need that we have heard from customers at Cisco.

 <= /span>

About t= he proxy-Registrar question, we already have made the change in the working= copy of the draft as well. We no longer call this functionality proxying, = but instead use the concept of the registrar that terminates the connection and establishes the next one.

 <= /span>

We didn= ’t add any new features in the doc after removing the BRSKI stuff. &n= bsp;

 <= /span>

If you = want an early preview to comment on, we can share the repository with you.

 <= /span>

Panos

 <= /span>

From: Ace [mailto:ace-bounce= s@ietf.org] On Behalf Of Hannes Tschofenig
Sent: Monday, May 14, 2018 5:05 AM
To: ace@ietf.org
Subject: [Ace] EST over CoAP

 

Hi all,

 

At IETF#101 Peter presented a list of open issues wi= th the EST over CoAP draft, see

https://datatracker.ietf.= org/meeting/101/materials/slides-101-ace-est-over-secure-coap-00

 

-     &= nbsp;  Operational parameter values<= /p>

-     &= nbsp;  Server side key generation using simple multipart encoding

-     &= nbsp;  Explain trust relations for http/coap proxying<= o:p>

 

I have challenged the usefulness of the server-side = key generation during the meeting but in general I am curious where we are = with the document. It would be great to get it finalized. It appears that w= e are adding new features and therefore will not be able to complete the work in any reasonable timeframe.

 

So, do we have a plan for how to complete the docume= nt?

 

Ciao

Hannes

 

IMPORTANT NOTICE: The content= s of this email and any attachments are confidential and may also be privil= eged.. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other perso= n, use it for any purpose, or store or copy the information in any medium. = Thank you. 



_______________________________________________
Ace mailing list
Ace@ietf.org<=
o:p>
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. --_000_VI1PR0801MB2112C9B4B7B1C3ABFC475DE9FA930VI1PR0801MB2112_-- From nobody Tue May 15 10:20:50 2018 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6325812DA6A for ; Tue, 15 May 2018 10:20:48 -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_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 pcs324oFHlmk for ; Tue, 15 May 2018 10:20:46 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19618126D3F for ; Tue, 15 May 2018 10:20:45 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 1EAD120091; Tue, 15 May 2018 13:32:55 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 3FE8E2E1A; Tue, 15 May 2018 13:20:23 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 3B7F82B5F; Tue, 15 May 2018 13:20:23 -0400 (EDT) From: Michael Richardson To: Hannes Tschofenig cc: "ace\@ietf.org" In-Reply-To: References: X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Ace] Early media-type registration for EST over CoAP X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2018 17:20:48 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hannes Tschofenig wrote: > I am curious whether it would be possible to ask for early media-type= registration of at least these two types: > - application/pkcs7-mime > - application/pkcs10 As previously said, these are already defined as MIME-TYPES, but we need to get them CoAP CT=3D bindings. We also need application/csrattrs and application/pkcs8. And we need rt=3Dace.est. All the chairs need to do is ask the AD. Hannes: do you have any opinion about the necessity of going through /.well-known/core to get the short URL, vs just using a /.well-known/est UR= L? (RTT for the lookup vs extra bytes in the URL) =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBWvsWSICLcPvd0N1lAQJmUAf/XO2C9qpvQXknhlLvxY1lxmhGZg2mzDi1 5/KQeFWqa1+o/54d6EjiJgxg4NsmDb8ELf5QgOTrzdxFtw/NEC6wEWrIdRZmlzrG rUL5cl3M5vFwhhFb++ihwpxVygViQdmIGUTf+yvF3X/BukG22L69h1d705YrqtLM eVf/s3rVjsWnw4kIm/2jLnsGWlfic3yPb2eoFO71Cd4aoDxlwyuTWEpHWn81uocY x0S6cZyD1oXu2r6QFYuBPSqKiZWesSHxgeYSRtvzdgAEUDzEv6+RMFlg3K5V3uA/ gWaG5upwXq71gRTnXbIpaPlWplFjpYrX68etEqyF1A5vdtqRpJjHbA== =FRHZ -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue May 15 13:07:52 2018 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97AD412E882 for ; Tue, 15 May 2018 13:07:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.509 X-Spam-Level: X-Spam-Status: No, score=-14.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5dHK9C53nR9h for ; Tue, 15 May 2018 13:07:47 -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 C997612D956 for ; Tue, 15 May 2018 13:07:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=35334; q=dns/txt; s=iport; t=1526414866; x=1527624466; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=66ZNyp0V9rUjBuBJTU+boRlI7ogwJm65pP4prPQgaKk=; b=M653Vj4SbkFW3u1EMayzqkxHv/k8ewcJ5w7fDB3RU1lzp+buW5TDGU9P 9wRSvdVxkPkhER2x4xE4fXUGj0tEt5hyTtb7vfcZlEXiEDeQRbifhDqeY S2TkDmt3ZrZ/Q+dtdH4ltgmZKFmDPDJKXr+ZuFlVqQG3SeRf45vUZ/ntH Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AfDQC9Pfta/5JdJa1TCRkBAQEBAQE?= =?us-ascii?q?BAQEBAQEHAQEBAQGCTUsrYXwoCpg0LoF5gQ+TMhSBZAslhEcCgxghNhYBAgE?= =?us-ascii?q?BAQEBAQJsHAyFKAEBAQICLUMCFwIBCBEEAQEhAQYHMhQJCAEBBAEJCQiDHT9?= =?us-ascii?q?cZA+uD4hJgiIFhnIQJn2BVD8laoIMf4I2OSIBAQECgSEJAQgKAQlMhR4ChyA?= =?us-ascii?q?IiWKHLwkChWWFOYMqgT4ag0yCX4R2iVeGZwIREwGBJAEjAi9hcXAVO4JDgzE?= =?us-ascii?q?BAgqCPoRZO4U+bwELB4x/gR+BGAEB?= X-IronPort-AV: E=Sophos;i="5.49,404,1520899200"; d="scan'208,217";a="114427859" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 May 2018 20:07:45 +0000 Received: from XCH-RCD-009.cisco.com (xch-rcd-009.cisco.com [173.37.102.19]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id w4FK7jl2013205 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 15 May 2018 20:07:45 GMT Received: from xch-aln-010.cisco.com (173.36.7.20) by XCH-RCD-009.cisco.com (173.37.102.19) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 15 May 2018 15:07:44 -0500 Received: from xch-aln-010.cisco.com ([173.36.7.20]) by XCH-ALN-010.cisco.com ([173.36.7.20]) with mapi id 15.00.1320.000; Tue, 15 May 2018 15:07:44 -0500 From: "Panos Kampanakis (pkampana)" To: Hannes Tschofenig , "ace@ietf.org" Thread-Topic: EST over CoAP Thread-Index: AdPrYipD0kyce1IOREqwxYCd2nFDSgAKCPZwAACDJXAAAGyyQAAlwdwAAAwByGA= Date: Tue, 15 May 2018 20:07:44 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.116.108.4] Content-Type: multipart/alternative; boundary="_000_e6e07b2a458e4417a18027d592db0b2bXCHALN010ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Ace] EST over CoAP X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2018 20:07:51 -0000 --_000_e6e07b2a458e4417a18027d592db0b2bXCHALN010ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Agreed. I see your point. I had read your whitepaper sometime back I think.= Indeed ACE-Oath, or LWM2M KDC, or OCF DOXS could provide address the crede= ntial management issue. But I don't think we can tell endpoints that they a= re on their own unless they get the right hardware or they comply with the = ACE-OAuth model, or DOXS. EST server-side key gen is free in a sense does not require new entities. W= e are not introducing a new concept. If your EST-coaps server supports it, = you could use it. But you do not need to even implement the server-side EST= URI unless you want to. And of course server-side key gen does not address= the whole credential issue which includes token, certs, raw public keys. I= t just gets an identity/priv keypair to the device. Your feedback brings up good points, which I think we ought to elaborate on= in the relevant sections and in the Security Considerations. From: Hannes Tschofenig [mailto:Hannes.Tschofenig@arm.com] Sent: Tuesday, May 15, 2018 4:27 AM To: Panos Kampanakis (pkampana) ; ace@ietf.org Subject: RE: EST over CoAP Hi Panos, I would say forget class 1 devices when you want to use public key crypto. https://factorable.net/paper.html (and https://jhalderm.com/pub/papers/http= s-imc13.pdf since it revisits the earlier analysis) was a problem with und= erstanding where the entropy comes from. If you take a regular desktop Linu= x and remove keyboard, mouse, disk drive, complex process scheduling etc. t= hen the ordinary entropy sources are suddenly gone. That was the problem id= entified in that paper. I am worried about keys across devices. For this reason we have standardize= d protocols to allow you to provision devices with new keys. Here is a whit= epaper published not too long ago that discusses the issue, see https://www= .omaspecworks.org/wp-content/uploads/2018/03/IPSO-IoT-Credential-Management= _Final.pdf I believe you would agree with me that there is a lot of value in the publi= c key crypto since you don't have to expose the private key. If your design= suddenly still requires this then you are losing some of the good properti= es of public key crypto systems. Ciao Hannes From: Panos Kampanakis (pkampana) [mailto:pkampana@cisco.com] Sent: 14 May 2018 21:24 To: Hannes Tschofenig; ace@ietf.org Subject: RE: EST over CoAP Your recommendation about having the right hardware is valid and what every= one should do as much as possible. What about Class 1 OEMs that cannot add = the hardware you are recommending? Or even the ones that will not comply wi= th the recommendations for their own reasons? We can't forget about those. Is the vulnerability that you were referring to that the RA or CA have to g= enerate the key? Trust of these entities needs to be established or this mo= del falls apart anyway. It is up to the admin to decide if it trusts the Re= gistrar will not store and reveal the private keys or generate insecure key= s on the device itself. I am more concerned about this vulnerability https:= //www.kb.cert.org/vuls/id/566724 where some thousands of devices have the s= ame identity and now they can all impersonate each other in my network as s= hown in https://jhalderm.com/pub/papers/https-imc13.pdf and https://factora= ble.net/paper.html We agree on the other ephemeral keys used in secure communications. Good ha= rdware would solve these issues. Without secure hardware some of these comm= unications could be decrypted assuming the right resources. Even though, de= crypting some data per connection is a concern, I don't think that the risk= is as high as a compromised identity. Also, the former concern does not me= an we should not have an option to eliminate the latter. About the Proxy section 6, I would like to see comments about in in the nex= t iteration, as we have updated to try to address some of these comments. From: Ace [mailto:ace-bounces@ietf.org] On Behalf Of Hannes Tschofenig Sent: Monday, May 14, 2018 10:14 AM To: Panos Kampanakis (pkampana) >; ace@ietf.org Subject: Re: [Ace] EST over CoAP Hi Panos, Thanks for sharing this info. Regarding the randomness requirement and the energy consumption. We have be= en a bit advocate for adding hardware-based random numbers to devices since= randomness is a basic requirement for most security protocols. You do not only need to have access to random numbers during key generation= but also later when you use nonces, a DH exchange, create session keys, an= d IVs, and potentially even for signature generation. If you use a protocol= that is not based on nonces then you may use one that relies on timestamps= , which may not make the story necessarily easier. Random number key generation is also not necessarily costly either (neither= in terms of energy cost nor in terms of hardware costs). Hence, I think you should consider the server-side key generation very care= fully since you are essentially destroying the benefits of public key crypt= o and introduce a big vulnerability. In a nutshell, I think you are better of recommending OEMs to select the ri= ght hardware for the given task. Ciao Hannes PS: For the proxy work (in context of DTLS/TLS) you might want to reach out= to your co-worker Owen Friel. From: Panos Kampanakis (pkampana) [mailto:pkampana@cisco.com] Sent: 14 May 2018 15:58 To: Hannes Tschofenig; ace@ietf.org Subject: RE: EST over CoAP Hi Hannes, To address your question about server-side key gen, below is the explanatio= n we have put in the draft already and will be in the next iteration ~~~~~~~~~~~~~ Constrained devices sometimes do not have the necessary hardware to generate statistically random numbers for private keys and DTLS ephemeral keys. Past experience has shown that cheap endpoints sometimes generate numbers which could allow someone to decrypt the communication or guess the private key and impersonate as the device. Studies have shown that the same keys are generated by the same model devices deployed on-line. Additionally, random number key generation is costly, thus energy draining. Even though the random numbers that constitute the identity/cert do not get generated often, an endpoint may not want to spend time and energy generating keypairs, and just ask for one from the server. In these scenarios, server-side key generation can be used. The client asks for the server or proxy to generate the private key and the certificate which is transferred back to the client in the server-side key generation response. ~~~~~~~~~~~~~ This is a need that we have heard from customers at Cisco. About the proxy-Registrar question, we already have made the change in the = working copy of the draft as well. We no longer call this functionality pro= xying, but instead use the concept of the registrar that terminates the con= nection and establishes the next one. We didn't add any new features in the doc after removing the BRSKI stuff. If you want an early preview to comment on, we can share the repository wit= h you. Panos From: Ace [mailto:ace-bounces@ietf.org] On Behalf Of Hannes Tschofenig Sent: Monday, May 14, 2018 5:05 AM To: ace@ietf.org Subject: [Ace] EST over CoAP Hi all, At IETF#101 Peter presented a list of open issues with the EST over CoAP dr= aft, see https://datatracker.ietf.org/meeting/101/materials/slides-101-ace-est-over-= secure-coap-00 - Operational parameter values - Server side key generation using simple multipart encoding - Explain trust relations for http/coap proxying I have challenged the usefulness of the server-side key generation during t= he meeting but in general I am curious where we are with the document. It w= ould be great to get it finalized. It appears that we are adding new featur= es and therefore will not be able to complete the work in any reasonable ti= meframe. So, do we have a plan for how to complete the document? Ciao Hannes IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. 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. IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. --_000_e6e07b2a458e4417a18027d592db0b2bXCHALN010ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Agreed. I see your poi= nt. I had read your whitepaper sometime back I think. Indeed ACE-Oath, or L= WM2M KDC, or OCF DOXS could provide address the credential management issue= . But I don’t think we can tell endpoints that they are on their own unless they get the right hardware or they comp= ly with the ACE-OAuth model, or DOXS.

 

EST server-side key ge= n is free in a sense does not require new entities. We are not introducing = a new concept. If your EST-coaps server supports it, you could use it. But = you do not need to even implement the server-side EST URI unless you want to. And of course server-side key gen = does not address the whole credential issue which includes token, certs, ra= w public keys. It just gets an identity/priv keypair to the device.

 

Your feedback brings u= p good points, which I think we ought to elaborate on in the relevant secti= ons and in the Security Considerations.

 

 

 

From: Hannes Tschofenig [mailto:Hannes.Tschof= enig@arm.com]
Sent: Tuesday, May 15, 2018 4:27 AM
To: Panos Kampanakis (pkampana) <pkampana@cisco.com>; ace@ietf= .org
Subject: RE: EST over CoAP

 

Hi Pano= s,

&n= bsp;

I would= say forget class 1 devices when you want to use public key crypto.

&n= bsp;

https://factorable.net/paper.html (and https= ://jhalderm.com/pub/papers/https-imc13.pdf  since it revisits the earlier analysis) was a problem with understanding where the entropy comes= from. If you take a regular desktop Linux and remove keyboard, mouse, disk= drive, complex process scheduling etc. then the ordinary entropy sources a= re suddenly gone. That was the problem identified in that paper.

&n= bsp;

I am wo= rried about keys across devices. For this reason we have standardized proto= cols to allow you to provision devices with new keys. Here is a whitepaper = published not too long ago that discusses the issue, see https://www.omaspecworks.org/wp-content/uploads/2018/03/IPSO-IoT-Credent= ial-Management_Final.pdf

&n= bsp;

I belie= ve you would agree with me that there is a lot of value in the public key c= rypto since you don’t have to expose the private key. If your design = suddenly still requires this then you are losing some of the good properties of public key crypto systems.

&n= bsp;

Ciao Hannes

&n= bsp;

From: Panos Kampanakis (pkampana) [mailto:pkampana@cisco.com<= /a>]
Sent: 14 May 2018 21:24
To: Hannes Tschofenig; ace@ie= tf.org
Subject: RE: EST over CoAP

 

Your recommendation ab= out having the right hardware is valid and what everyone should do as much = as possible. What about Class 1 OEMs that cannot add the hardware you are r= ecommending? Or even the ones that will not comply with the recommendations for their own reasons? We can’t = forget about those.

 

Is the vulnerability t= hat you were referring to that the RA or CA have to generate the key? Trust= of these entities needs to be established or this model falls apart anyway= . It is up to the admin to decide if it trusts the Registrar will not store and reveal the private keys or gene= rate insecure keys on the device itself. I am more concerned about this vul= nerability https://www.kb.ce= rt.org/vuls/id/566724 where some thousand= s of devices have the same identity and now they can all impersonate each o= ther in my network as shown in https://= jhalderm.com/pub/papers/https-imc13.pdf a= nd https://factorable.net= /paper.html

 

We agree on the other = ephemeral keys used in secure communications. Good hardware would solve the= se issues. Without secure hardware some of these communications could be de= crypted assuming the right resources. Even though, decrypting some data per connection is a concern, I don’= ;t think that the risk is as high as a compromised identity. Also, the form= er concern does not mean we should not have an option to eliminate the latt= er.

 

About the Proxy sectio= n 6, I would like to see comments about in in the next iteration, as we hav= e updated to try to address some of these comments.

 

From: Ace [mailto:ace-bounces@ietf.org] On Behalf Of Hannes Tschofenig
Sent: Monday, May 14, 2018 10:14 AM
To: Panos Kampanakis (pkampana) <pkampana@cisco.com>; ace@ietf.org
Subject: Re: [Ace] EST over CoAP

 

Hi Pano= s,

&n= bsp;

Thanks = for sharing this info.

&n= bsp;

Regardi= ng the randomness requirement and the energy consumption. We have been a bi= t advocate for adding hardware-based random numbers to devices since random= ness is a basic requirement for most security protocols.

You do = not only need to have access to random numbers during key generation but al= so later when you use nonces, a DH exchange, create session keys, and IVs, = and potentially even for signature generation. If you use a protocol that is not based on nonces then you may use one tha= t relies on timestamps, which may not make the story necessarily easier.

&n= bsp;

Random = number key generation is also not necessarily costly either (neither in ter= ms of energy cost nor in terms of hardware costs).  =

&n= bsp;

Hence, = I think you should consider the server-side key generation very carefully s= ince you are essentially destroying the benefits of public key crypto and i= ntroduce a big vulnerability.

&n= bsp;

In a nu= tshell, I think you are better of recommending OEMs to select the right har= dware for the given task.

&n= bsp;

Ciao

Hannes<= o:p>

&n= bsp;

PS: For= the proxy work (in context of DTLS/TLS) you might want to reach out to you= r co-worker Owen Friel.

&n= bsp;

From: Panos Kampanakis (pkampana) [mailto:pkampana@cisco.com<= /a>]
Sent: 14 May 2018 15:58
To: Hannes Tschofenig; ace@ie= tf.org
Subject: RE: EST over CoAP

 

Hi Hannes, =

 

To address your questi= on about server-side key gen, below is the explanation we have put in the d= raft already and will be in the next iteration
~~~~~~~~~~~~~

&n= bsp;  Constrained devices sometimes do not have the necessary hardware= to

&n= bsp;  generate statistically random numbers for private keys and DTLS<= o:p>

&n= bsp;  ephemeral keys.  Past experience has shown that cheap endpo= ints

&n= bsp;  sometimes generate numbers which could allow someone to decrypt = the

&n= bsp;  communication or guess the private key and impersonate as the de= vice.

&n= bsp;  Studies have shown that the same keys are generated by the same = model

&n= bsp;  devices deployed on-line.

 

&n= bsp;  Additionally, random number key generation is costly, thus energ= y

&n= bsp;  draining.  Even though the random numbers that constitute t= he

&n= bsp;  identity/cert do not get generated often, an endpoint may not wa= nt to

&n= bsp;  spend time and energy generating keypairs, and just ask for one = from

&n= bsp;  the server.

 

&n= bsp;  In these scenarios, server-side key generation can be used. = ; The

&n= bsp;  client asks for the server or proxy to generate the private key = and

&n= bsp;  the certificate which is transferred back to the client in the

&n= bsp;  server-side key generation response.
~~~~~~~~~~~~~=

 

This is a need that we= have heard from customers at Cisco.

 

About the proxy-Regist= rar question, we already have made the change in the working copy of the dr= aft as well. We no longer call this functionality proxying, but instead use= the concept of the registrar that terminates the connection and establishes the next one.

 

We didn’t add an= y new features in the doc after removing the BRSKI stuff.  =

 

If you want an early p= review to comment on, we can share the repository with you.

 

Panos

 

From: Ace [mailto:ace-bounces@ietf.org] On Behalf Of Hannes Tschofenig
Sent: Monday, May 14, 2018 5:05 AM
To: ace@ietf.org
Subject: [Ace] EST over CoAP

 

Hi all,

 

At IETF#101 Peter presented a l= ist of open issues with the EST over CoAP draft, see

http= s://datatracker.ietf.org/meeting/101/materials/slides-101-ace-est-over-secu= re-coap-00

 

-        Operational parameter values<= /p>

-        Server side key generation using simple multipa= rt encoding

-        Explain trust relations for http/coap proxying<= o:p>

 

I have challenged the usefulnes= s of the server-side key generation during the meeting but in general I am = curious where we are with the document. It would be great to get it finaliz= ed. It appears that we are adding new features and therefore will not be able to complete the work in any reason= able timeframe.

 

So, do we have a plan for how t= o complete the document?

 

Ciao

Hannes

 

IMPORTANT NOTICE: The contents of= this email and any attachments are confidential and may also be privileged= . If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any othe= r person, use it for any purpose, or store or copy the information in any m= edium. Thank you.

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 othe= r person, use it for any purpose, or store or copy the information in any m= edium. Thank you.

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 othe= r person, use it for any purpose, or store or copy the information in any m= edium. Thank you.

--_000_e6e07b2a458e4417a18027d592db0b2bXCHALN010ciscocom_-- From nobody Tue May 15 13:31:30 2018 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3826112E8A1 for ; Tue, 15 May 2018 13:31:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xZSVYgssO994 for ; Tue, 15 May 2018 13:31:26 -0700 (PDT) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA6B912D95D for ; Tue, 15 May 2018 13:31:25 -0700 (PDT) Received: by mail-qk0-x231.google.com with SMTP id c11-v6so1340747qkm.0 for ; Tue, 15 May 2018 13:31:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=j/giFpEE3FEOwPuerAh1Fw7OBDVvGsa9EMB2buu3NtU=; b=jZHGSF2bs9PK3OvDHbNIK9rg5T0rJIuq8+BKxDNY7BYogubghwO4HNIyc9m+rTxums oguFcPwMWu6DLoqLTlrFz7XmaJTbBNFY0fJX66C3hZTXxFc2sOQxRBI7WLaz2S7WbRVr 8hl6lParzy06m3kuBARkjL1IFXdWwDAJro5yKegLVo8C8SR/P7/VjwvIiJW6PlpF3DZS YFzvc7GndQOEQ0KpDP5imMI9hMCnosOi6s6epr58Zyc+6hFwHazVfaexg2V/29vp8zrY ubXirpAkT3KimIb82hE2/qmw2ndkA3ir7Mpo7dl0Ku4ei6Iy0qgdffuHKYHOG8BvvIFC OshA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=j/giFpEE3FEOwPuerAh1Fw7OBDVvGsa9EMB2buu3NtU=; b=LDKLe0ez23BHMy8VHBT4MHkaLC50cJU1l5Di8hmVcnO1kI2w5plz+OVZI4dUn/ebrp 5TJaWid8EDdLN7owMHm0T0ixMuaGbVk2+FptWtG8DJWzMLH+wBLiNcifawZOYXhNM7/S syiWQBO6JiRqa6CVRI8sXPRNxVy/MAME89pLEayapgveVpBIZ9i006GubAAB/2xkzHo6 a215srItYcuKrE0O+Axz+Hlf/XyMeHTF+dymovW35xt9KTFWfOo5GXQne2tPJRiFH2UD OpRfS6wsWW1gJWc+7zq+SMyKYXpbEVqJPVhjldIK8a4VPnv+lnVHLeJECg5mDI8y7UNK mZwQ== X-Gm-Message-State: ALKqPwcc5CbMPJ/cKvJ/yQ6FRCdCS+eIPQ/cXpc3aZp1PuwKNPY8jftD GR1WPz0gqpv+bRvHITLuUV3p1uFEnbXq8XHN7iY= X-Google-Smtp-Source: AB8JxZp0TXLzIzJiF3m1AJ44dNpNTDRKubUC8FPb6yt1+h1jvE8Fs+8jzgPtmfyEITdmkqC/9XGRoCUa6pgWmqfcxzo= X-Received: by 2002:a37:ac12:: with SMTP id e18-v6mr22549qkm.342.1526416284777; Tue, 15 May 2018 13:31:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.57.195 with HTTP; Tue, 15 May 2018 13:31:24 -0700 (PDT) In-Reply-To: <99638740-7df6-c646-29bf-a3b295213396@ri.se> References: <99638740-7df6-c646-29bf-a3b295213396@ri.se> From: Cigdem Sengul Date: Tue, 15 May 2018 21:31:24 +0100 Message-ID: To: Ludwig Seitz Cc: "ace@ietf.org" , Cigdem Sengul , Anthony Kirby , Paul Fremantle Content-Type: multipart/alternative; boundary="0000000000006eff5c056c447c5f" Archived-At: Subject: Re: [Ace] Review of draft-sengul-ace-mqtt-tls-profile-02 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2018 20:31:29 -0000 --0000000000006eff5c056c447c5f Content-Type: text/plain; charset="UTF-8" Hello Ludwig, Thank you for reviewing our draft. We will start working on addressing your comments asap. Thanks, --Cigdem On Tue, May 15, 2018 at 10:04 AM, Ludwig Seitz wrote: > Hello ACE, > > I've reviewed draft-sengul-ace-mqtt-tls-profile-02. I think this is a > very relevant draft, due to the amount of IoT devices that use MQTT. I > would encourage the WG to pick this up as the third profile of > draft-ietf-ace-oauth-authz > > Detailed comments below. > > > /Ludwig > > > > 1. Introduction > > " Section 4 of the ACE framework [I-D.ietf-ace-oauth-authz]" > > If you make that "Section 4 of [I-D.ietf-ace-oauth-authz]" the IETF > html-izer will not turn this into a link to section 4 of your draft (I > think). > See: https://xml2rfc.tools.ietf.org/xml2rfcFAQ.html#anchor18 > > 1.1. Requirements Language > > There is a new recommendation how this section should be worded: > > "The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and > "OPTIONAL" in this document are to be interpreted as described in BCP > 14 [RFC2119] [RFC8174] when, and only when, they appear in all > capitals, as shown here." > > 1.2. ACE-Related Terminology > > "The term "Resource" is used to refer to an MQTT "topic", which is > defined in Section 1.2." > > This references back to the same section, perhaps this was meant to > reference to some other part of the draft? > > 2.1. Authorizing Connection Establishment > > Figure 1 could clarify that steps E and F are optional. > > 2.1.1. Client Authorization Server (CAS) and Authorization Server (AS) > Interaction > > "and the client is authorized to obtain a token for the indicated > audience (e.g., topics) and scopes (e.g., publish/subscribe > permissions)" > > Note that the audience claim is typically used to identify the RS (so in > this case the MQTT broker), while the scope is intended to identify both > the resource (=topic) and the actions (=publish, subscribe). > See this for how OAuth scopes are typically used: > https://www.brandur.org/oauth-scope > > > "This includes a token, which is assumed to be PoP by default." > > The abbreviation PoP is not defined at this point, I would write it out as > in "... assumed to be a Proof-of-Possession (PoP) token ..." > > 2.1.2. Client connection request to the broker > > " For the basic operation described in this section, > the Username field MUST be set to the token." > > I think this refers to the access token right? I'd suggest to be more > specific, since there is room for confusion (CoAP has also the concept of a > token, and then OAuth has different types of tokens, the access token being > one of them). > > "The Password field MUST be set to the keyed message digest (MAC) or > signature." > > Please make it explicit already here that this is the Proof-of-possession > mechanism for the key associated to the token. > > "(The Username field is a UTF-8 encoded string," > > You need to specify how the (possibly binary) access token is supposed to > be converted into an UTF-8 string. Base64 encoding would be obvious, but it > needs to be explicitly stated. > > General comment: > > An example of how the CONNECT message could look like would be good. > > > 2.1.3. Token validation > > "The broker MAY cache the introspection result because it will need to > decide whether to accept subsequent PUBLISH and SUBSCRIBE messages" > > This could warrant a section in the security considerations about the > trade-off of caching introspection results (freshness vs. connectivity > requirements). > > "If the introspection result is not cached, then the RS needs to > introspect the saved token for each request." > > This is only true if the token is not self-contained. I would rephrase > this statement > > "Note: Scope strings MAY follow ..." > > Note that a scope is a "space-delimited list strings" (OAuth 2.0 3.3.) > so you could include several topics in one scope as in e.g. "connect > publish_topic1 publish_topic2 subsrcibe_topic3" > > The use of 'aud' as described in this paragraph is definitely not the > intended use, and I would not recommend this type of use. See > https://tools.ietf.org/html/rfc7519#section-4.1.3 for the definition of > aud. > > > 2.4. Token expiration > > "The token validation is done either by checking the 'exp' claim of a > CWT/JWT or via performing an introspection request with the > Authorization server as described in Section 8.2 of the ACE framework > [I-D.ietf-ace-oauth-authz]." > > The word "token validation" here could be misconstrued to ignoring crypto > wrappers, token issuers ect. While it is clear from the context (to me) > that you only refer to checking the expiration of a token, the full > validation of a token would include the following steps: > > 1. Check that the issuer of the token (= AS) is acceptable > 2. Check the cryptographic wrapper of the token (may be MAC or signature or > AEAD encryption) > 3. Check that the token contains all expected claims > 4. Check that the "exp" and "nbf" claims are fulfilled if present > 5. Check that the "aud" claim applies to the recipient if present > > > 3.1. Token Transport via Authentication Exchange (AUTH) > > "The first option is that Authentication data contains both the token > and the keyed message digest (MAC) or signature as described in > Section 2.1.2." > > You need to specify how these two items are encoded. I would suggest a > CBOR array since this property expects binary data. An example would also > be very helpful here. > > "... RS responds with a CONNACK reason code '0x87 (Not Authorized)' and > includes a User Property set to the address of the AS." > > You need to specify the format of this user property, in order to mirror > the framework's section 5.1.2. I guess you could use either a JSON map > or binary data containing a CBOR map for this. > > > 4. IANA Considerations > > " This memo includes no request to IANA." > > This should instead register the new profile identifier "mqtt_tls" in the > soon-to-be-created IANA registry for ACE profile identifiers. See the DTLS > profile for example: > > https://tools.ietf.org/html/draft-ietf-ace-dtls-authorize-03#section-7 > > > 5. Security Considerations > > You should add some text here about the security implications of the > limitations of MQTT v3.1 (client disconnect only). > I could imagine that you could perform some attacks on a client that > hasn't realized it was disconnected for example. > > > -- > Ludwig Seitz, PhD > Security Lab, RISE SICS > Phone +46(0)70-349 92 51 > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > --0000000000006eff5c056c447c5f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Ludwig,=C2=A0

Thank you for revie= wing our draft. We will start working on addressing your comments asap.=C2= =A0

Thanks,
--Cigdem=C2=A0


On Tue, May 15, 2018 at 10:04 AM, Ludwig Seitz <ludwig.seitz@r= i.se> wrote:
Hello ACE,

I've reviewed draft-sengul-ace-mqtt-tls-profile-02. I think this i= s a very relevant draft, due to the amount of IoT devices that use MQTT. I = would encourage the WG to pick this up as the third profile of draft-ietf-a= ce-oauth-authz

Detailed comments below.


/Ludwig



1. Introduction

" Section 4 of the ACE framework [I-D.ietf-ace-oauth-authz]"

If you make that "Section 4 of [I-D.ietf-ace-oauth-authz]" the IE= TF html-izer will not turn this into a link to section 4 of your draft (I t= hink).
See: https://xml2rfc.tools.ietf.org/xml2= rfcFAQ.html#anchor18

1.1. Requirements Language

There is a new recommendation how this section should be worded:

=C2=A0"The key words "MUST", "MUST NOT", "REQ= UIRED", "SHALL", "SHALL NOT",
=C2=A0 =C2=A0"SHOULD", "SHOULD NOT", "RECOMMENDED&= quot;, "NOT RECOMMENDED", "MAY", and
=C2=A0 =C2=A0"OPTIONAL" in this document are to be interpreted as= described in BCP
=C2=A0 =C2=A014 [RFC2119] [RFC8174] when, and only when, they appear in all=
=C2=A0 =C2=A0capitals, as shown here."

1.2.=C2=A0 ACE-Related Terminology

"The term "Resource" is used to refer to an MQTT "topic= ", which is
=C2=A0 =C2=A0defined in Section 1.2."

This references back to the same section, perhaps this was meant to referen= ce to some other part of the draft?

2.1.=C2=A0 Authorizing Connection Establishment

Figure 1 could clarify that steps E and F are optional.

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

"and the client is authorized to obtain a token for the indicated
=C2=A0 =C2=A0audience (e.g., topics) and scopes (e.g., publish/subscribe =C2=A0 =C2=A0permissions)"

Note that the audience claim is typically used to identify the RS (so in th= is case the MQTT broker), while the scope is intended to identify both the = resource (=3Dtopic) and the actions (=3Dpublish, subscribe).
See this for how OAuth scopes are typically used:
https://www.brandur.org/oauth-scope


"This includes a token, which is assumed to be PoP by default."
The abbreviation PoP is not defined at this point, I would write it out as = in "... assumed to be a Proof-of-Possession (PoP) token ..."

2.1.2.=C2=A0 Client connection request to the broker

" For the basic operation described in this section,
=C2=A0 =C2=A0the Username field MUST be set to the token."

I think this refers to the access token right? I'd suggest to be more s= pecific, since there is room for confusion (CoAP has also the concept of a = token, and then OAuth has different types of tokens, the access token being= one of them).

"The Password field MUST be set to the keyed message digest (MAC) or s= ignature."

Please make it explicit already here that this is the Proof-of-possession m= echanism for the key associated to the token.

"(The Username field is a UTF-8 encoded string,"

You need to specify how the (possibly binary) access token is supposed to b= e converted into an UTF-8 string. Base64 encoding would be obvious, but it = needs to be explicitly stated.

General comment:

An example of how the CONNECT message could look like would be good.


2.1.3.=C2=A0 Token validation

"The broker MAY cache the introspection result because it will need to=
=C2=A0 =C2=A0decide whether to accept subsequent PUBLISH and SUBSCRIBE mess= ages"

This could warrant a section in the security considerations about the trade= -off of caching introspection results (freshness vs. connectivity requireme= nts).

"If the introspection result is not cached, then the RS needs to intro= spect the saved token for each request."

This is only true if the token is not self-contained. I would rephrase this= statement

"Note: Scope strings MAY follow ..."

Note that a scope is a "space-delimited list strings" (OAuth 2.0 = 3.3.)
so you could include several topics in one scope as in e.g. "connect p= ublish_topic1 publish_topic2 subsrcibe_topic3"

The use of 'aud' as described in this paragraph is definitely not t= he intended use, and I would not recommend this type of use. See https://tools.ietf.org/html/rfc7519#section-4.1.3 fo= r the definition of aud.


2.4.=C2=A0 Token expiration

"The token validation is done either by checking the 'exp' cla= im of a
=C2=A0 =C2=A0CWT/JWT or via performing an introspection request with the =C2=A0 =C2=A0Authorization server as described in Section 8.2 of the ACE fr= amework
=C2=A0 =C2=A0[I-D.ietf-ace-oauth-authz]."

The word "token validation" here could be misconstrued to ignorin= g crypto wrappers, token issuers ect. While it is clear from the context (t= o me) that you only refer to checking the expiration of a token, the full v= alidation of a token would include the following steps:

1. Check that the issuer of the token (=3D AS) is acceptable
2. Check the cryptographic wrapper of the token (may be MAC or signature or=
AEAD encryption)
3. Check that the token contains all expected claims
4. Check that the "exp" and "nbf" claims are fulfilled = if present
5. Check that the "aud" claim applies to the recipient if present=


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

"The first option is that Authentication data contains both the token<= br> =C2=A0 =C2=A0and the keyed message digest (MAC) or signature as described i= n
=C2=A0 =C2=A0Section 2.1.2."

You need to specify how these two items are encoded. I would suggest a
CBOR array since this property expects binary data. An example would also be very helpful here.

"... RS responds with a CONNACK reason code '0x87 (Not Authorized)= ' and
=C2=A0 =C2=A0includes a User Property set to the address of the AS."
You need to specify the format of this user property, in order to mirror the framework's section 5.1.2. I guess you could use either a JSON map<= br> or binary data containing a CBOR map for this.


4.=C2=A0 IANA Considerations

"=C2=A0 =C2=A0This memo includes no request to IANA."

This should instead register the new profile identifier "mqtt_tls"= ; in the soon-to-be-created IANA registry for ACE profile identifiers. See = the DTLS profile for example:

https://tools.ietf.org/html/dr= aft-ietf-ace-dtls-authorize-03#section-7


5. Security Considerations

You should add some text here about the security implications of the limita= tions of MQTT v3.1 (client disconnect only).
I could imagine that you could perform some attacks on a client that hasn&#= 39;t realized it was disconnected for example.


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

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

--0000000000006eff5c056c447c5f-- From nobody Wed May 16 01:08:26 2018 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 989AA12D77B for ; Wed, 16 May 2018 01:08:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, T_KAM_HTML_FONT_INVALID=0.01] 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 IOmbR-SDnprt for ; Wed, 16 May 2018 01:08:21 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54FDC1201FA for ; Wed, 16 May 2018 01:08:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1526458099; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=fHdDO9dAhi9GxBtlLOdcbvFrYZtk01NKAmJCkSdEUiw=; b=fJ5istje8/54bXAHeI8Hb0JKCOZQHvHUhVfnLGqufQQmmPfV5LDztfOZFa+yv3CO lCQsMikql7gkidVwPilKYidg92TxeSkWskrjSQU8YropHaT4uGJwWRVzzCJwf19b gPHmKVWFJiwJfl0kDxVqyj8bqOrlvRhuOzcu+9lvZ7M=; X-AuditID: c1b4fb2d-a6b079c00000050d-51-5afbe6f3c5b0 Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.183.48]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 55.C8.01293.3F6EBFA5; Wed, 16 May 2018 10:08:19 +0200 (CEST) Received: from nomadiclab.fi.eu.ericsson.se (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.50) with Microsoft SMTP Server id 14.3.382.0; Wed, 16 May 2018 10:07:47 +0200 Received: from nomadiclab.fi.eu.ericsson.se (localhost [127.0.0.1]) by nomadiclab.fi.eu.ericsson.se (Postfix) with ESMTP id 6F7C148085C; Wed, 16 May 2018 11:07:47 +0300 (EEST) Received: from [127.0.0.1] (localhost [IPv6:::1]) by nomadiclab.fi.eu.ericsson.se (Postfix) with ESMTP id 1B70248070F; Wed, 16 May 2018 11:07:46 +0300 (EEST) To: "Panos Kampanakis (pkampana)" , "ace@ietf.org" References: <068f2690-e1a1-b225-463a-4048e06365af@ericsson.com> From: Mohit Sethi Message-ID: <8f5dc6ee-d6e1-9a9d-0e23-f7056f743229@ericsson.com> Date: Wed, 16 May 2018 11:07:46 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------EDC17B96B51870F67F666F03" Content-Language: en-US X-AV-Checked: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpgkeLIzCtJLcpLzFFi42KZGbHdQPfzs99RBjOPqlh8/9bDbPHlwipG ByaPKb83snosWfKTKYApissmJTUnsyy1SN8ugSujd8YytoK9hxgrDlxfzdTAeG4KYxcjB4eE gIlEy6SYLkYuDiGBI4wSr3/sY4FwdjBKPHr9kh3C2cwosa3jNhuEs5BRYsPkqUBlnBzCAgoS y5r/M4PYIgLhEg0fJzBCFPUwSTw5OZsRJMEmoCfRee44WBGvgL3Ekgu32UFsFgFViYnHz4HZ ogIREvfOf2KDqBGUODnzCdgCTgFXid0vJ7CC2MwCYRLvbh5jh7DFJW49mc8EYksIKEssaFkE tktIQF1ia8cBxgmMQrOQjJqFpH0WkvZZwCBgBjrpwdYyiLC2xLKFr5khbH2J63fus0LY8hLN W2czL2BkX8UoWpxaXJybbmSsl1qUmVxcnJ+nl5dasokRGC8Ht/zW3cG4+rXjIUYBDkYlHl77 J7+jhFgTy4orcw8xSnAwK4nwZvIChXhTEiurUovy44tKc1KLDzFKc7AoifPqrdoTJSSQnliS mp2aWpBaBJNl4uCUamCc9t3o3VTDY3FrbycpOP98xLBeYXE3u0M+1/0Yed1ZzAu3vLD8bn5O 3O560e8PCxvtX83nOOo+obJz2rIb5+y6oi2t1VnMEzp/Wlgyzoj/tV/Y8nLNVNfEmp7MX8v1 T4UkHW7UnbPq2vRV12SPy/s0JV6ctjRr05c/qeeuXDFarum+Kp1zcv0KJZbijERDLeai4kQA KR7mbpMCAAA= Archived-At: Subject: Re: [Ace] EST over CoAP X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2018 08:08:25 -0000 --------------EDC17B96B51870F67F666F03 Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: quoted-printable Hi Panos, I wonder what kind of devices you have in mind? On one hand, the devices = are constrained enough not to have resources for generating=20 cryptographic quality randomness. But they somehow have support for=20 tamper-resistance identity protection? Is it cheaper to have=20 tamper-resistance? And is it somehow more energy-efficient? I understand that generating strong identities and storing them securely = are different issues. But I would be interested to learn about IoT=20 devices that have tamper-resistance storage but no possibility of=20 generating cryptographic quality randomness. Also, what protocols do you = think the devices would use for authenticating these identities? --Mohit On 05/15/2018 05:00 PM, Panos Kampanakis (pkampana) wrote: > > Hi Mohit, > > These priv/public keypairs+cert are provisioned and used on the=20 > endpoint as identity for authentication. If tamper-resistance is not=20 > supported on the endpoint, the keypairs could be reprovisioned more=20 > often than the traditional cert lifetime as the server-side key gen=20 > transaction does not incur significant workload to the endpoint itself.= > > Rgs, > > Panos > > *From:*Mohit Sethi [mailto:mohit.m.sethi@ericsson.com] > *Sent:* Tuesday, May 15, 2018 1:37 AM > *To:* Panos Kampanakis (pkampana) ; Hannes=20 > Tschofenig ; ace@ietf.org > *Subject:* Re: [Ace] EST over CoAP > > Hi Panos, > > How do you intend to use these server generated keys once they are=20 > provisioned onto the device? > > --Mohit > > On 05/14/2018 04:58 PM, Panos Kampanakis (pkampana) wrote: > > Hi Hannes, > > To address your question about server-side key gen, below is the > explanation we have put in the draft already and will be in the > next iteration > /~~~~~~~~~~~~~/ > > /=A0=A0 Constrained devices sometimes do not have the necessary > hardware to/ > > /=A0=A0 generate statistically random numbers for private keys and = DTLS/ > > /=A0=A0 ephemeral keys.=A0 Past experience has shown that cheap end= points/ > > /=A0=A0 sometimes generate numbers which could allow someone to > decrypt the/ > > /=A0=A0 communication or guess the private key and impersonate as t= he > device./ > > /=A0=A0 Studies have shown that the same keys are generated by the > same model/ > > /=A0=A0 devices deployed on-line./ > > // > > /=A0=A0 Additionally, random number key generation is costly, thus = energy/ > > /=A0=A0 draining. Even though the random numbers that constitute th= e/ > > /=A0=A0 identity/cert do not get generated often, an endpoint may n= ot > want to/ > > /=A0=A0 spend time and energy generating keypairs, and just ask for= > one from/ > > /=A0=A0 the server./ > > // > > /=A0=A0 In these scenarios, server-side key generation can be used.= =A0 The/ > > /=A0=A0 client asks for the server or proxy to generate the private= > key and/ > > /=A0=A0 the certificate which is transferred back to the client in = the/ > > /=A0=A0 server-side key generation response./ > /~~~~~~~~~~~~~/ > > This is a need that we have heard from customers at Cisco. > > About the proxy-Registrar question, we already have made the > change in the working copy of the draft as well. We no longer call > this functionality proxying, but instead use the concept of the > registrar that terminates the connection and establishes the next > one. > > We didn=92t add any new features in the doc after removing the BRSK= I > stuff. > > If you want an early preview to comment on, we can share the > repository with you. > > Panos > > *From:* Ace [mailto:ace-bounces@ietf.org] *On Behalf Of *Hannes > Tschofenig > *Sent:* Monday, May 14, 2018 5:05 AM > *To:* ace@ietf.org > *Subject:* [Ace] EST over CoAP > > Hi all, > > At IETF#101 Peter presented a list of open issues with the EST > over CoAP draft, see > > https://datatracker.ietf.org/meeting/101/materials/slides-101-ace-e= st-over-secure-coap-00 > > -Operational parameter values > > -Server side key generation using simple multipart encoding > > -Explain trust relations for http/coap proxying > > I have challenged the usefulness of the server-side key generation > during the meeting but in general I am curious where we are with > the document. It would be great to get it finalized. It appears > that we are adding new features and therefore will not be able to > complete the work in any reasonable timeframe. > > So, do we have a plan for how to complete the document? > > Ciao > > Hannes > > IMPORTANT NOTICE: The contents of this email and any attachments > are confidential and may also be privileged.. If you are not the > intended recipient, please notify the sender immediately and do > not disclose the contents to any other person, use it for any > purpose, or store or copy the information in any medium. Thank you.= > > > > > _______________________________________________ > > Ace mailing list > > Ace@ietf.org > > https://www.ietf.org/mailman/listinfo/ace > --------------EDC17B96B51870F67F666F03 Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: 8bit Hi Panos,

I wonder what kind of devices you have in mind? On one hand, the devices are constrained enough not to have resources for generating cryptographic quality randomness. But they somehow have support for tamper-resistance identity protection? Is it cheaper to have tamper-resistance? And is it somehow more energy-efficient?

I understand that generating strong identities and storing them securely are different issues. But I would be interested to learn about IoT devices that have tamper-resistance storage but no possibility of generating cryptographic quality randomness. Also, what protocols do you think the devices would use for authenticating these identities?

--Mohit

On 05/15/2018 05:00 PM, Panos Kampanakis (pkampana) wrote:

Hi Mohit,

These priv/public keypairs+cert are provisioned and used on the endpoint as identity for authentication. If tamper-resistance is not supported on the endpoint, the keypairs could be reprovisioned more often than the traditional cert lifetime as the server-side key gen transaction does not incur significant workload to the endpoint itself.

Rgs,

Panos

From: Mohit Sethi [mailto:mohit.m.sethi@ericsson.com]
Sent: Tuesday, May 15, 2018 1:37 AM
To: Panos Kampanakis (pkampana) <pkampana@cisco.com>; Hannes Tschofenig <Hannes.Tschofenig@arm.com>; ace@ietf.org
Subject: Re: [Ace] EST over CoAP

Hi Panos,

How do you intend to use these server generated keys once they are provisioned onto the device?

--Mohit

On 05/14/2018 04:58 PM, Panos Kampanakis (pkampana) wrote:

Hi Hannes,

To address your question about server-side key gen, below is the explanation we have put in the draft already and will be in the next iteration
~~~~~~~~~~~~~

Constrained devices sometimes do not have the necessary hardware to

generate statistically random numbers for private keys and DTLS

ephemeral keys. Past experience has shown that cheap endpoints

sometimes generate numbers which could allow someone to decrypt the

communication or guess the private key and impersonate as the device.

Studies have shown that the same keys are generated by the same model

devices deployed on-line.

Additionally, random number key generation is costly, thus energy

draining. Even though the random numbers that constitute the

identity/cert do not get generated often, an endpoint may not want to

spend time and energy generating keypairs, and just ask for one from

the server.

In these scenarios, server-side key generation can be used. The

client asks for the server or proxy to generate the private key and

the certificate which is transferred back to the client in the

server-side key generation response.
~~~~~~~~~~~~~

This is a need that we have heard from customers at Cisco.

About the proxy-Registrar question, we already have made the change in the working copy of the draft as well. We no longer call this functionality proxying, but instead use the concept of the registrar that terminates the connection and establishes the next one.

We didnt add any new features in the doc after removing the BRSKI stuff.

If you want an early preview to comment on, we can share the repository with you.

Panos

From: Ace [mailto:ace-bounces@ietf.org] On Behalf Of Hannes Tschofenig
Sent: Monday, May 14, 2018 5:05 AM
To: ace@ietf.org
Subject: [Ace] EST over CoAP

Hi all,

At IETF#101 Peter presented a list of open issues with the EST over CoAP draft, see

https://datatracker.ietf.org/meeting/101/materials/slides-101-ace-est-over-secure-coap-00

- Operational parameter values

- Server side key generation using simple multipart encoding

- Explain trust relations for http/coap proxying

I have challenged the usefulness of the server-side key generation during the meeting but in general I am curious where we are with the document. It would be great to get it finalized. It appears that we are adding new features and therefore will not be able to complete the work in any reasonable timeframe.

So, do we have a plan for how to complete the document?

Ciao

Hannes

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged.. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. 




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


--------------EDC17B96B51870F67F666F03-- From nobody Wed May 16 02:16:26 2018 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C892A120721 for ; Wed, 16 May 2018 02:16:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.01 X-Spam-Level: X-Spam-Status: No, score=-0.01 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oo2C62G-iegS for ; Wed, 16 May 2018 02:16:22 -0700 (PDT) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50046.outbound.protection.outlook.com [40.107.5.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DDAB1200E5 for ; Wed, 16 May 2018 02:16:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=PMc2sZ3dJdGoy8Q3PivvRDRnl1o54FioNlKjWXrHdxc=; b=G5AReqns2y1cqdyyM9+MpO6b42HQdKUaryvIRxwFV9KYF4TCCbx0n3qmr0UQhcGG/PMfip8OUte6oZH/HBbiYd5VpywpfNjQA+3e5/7shJHa0BgApUEgMGagoe7hO23w61dfKMyHW+EZRSyIIlQfGL9xarDINSfZKjspiTaeYdY= Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB1615.eurprd08.prod.outlook.com (10.167.211.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.755.16; Wed, 16 May 2018 09:16:19 +0000 Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::7c43:c1a5:4f69:5365]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::7c43:c1a5:4f69:5365%17]) with mapi id 15.20.0755.018; Wed, 16 May 2018 09:16:19 +0000 From: Hannes Tschofenig To: "Panos Kampanakis (pkampana)" , "ace@ietf.org" Thread-Topic: EST over CoAP Thread-Index: AdPrYipD0kyce1IOREqwxYCd2nFDSgAKCPZwAACDJXAAAGyyQAAlwdwAAAwByGAAKB+2gA== Date: Wed, 16 May 2018 09:16:19 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [156.67.194.220] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0801MB1615; 7:GPkgdZCHl5DNU8h3x7Jmk/RsSefJ7J0JDYuSeFM8BOiNUZaL2BjVvxUgsTGe90BHhDIcqYU2puvKFofwAP2it9fejYhmZqIo/oyMqHZwS5CcPSn/7JsrgCadKiLtEcTDsmwVgdVIOU/Kpa+S/3Bq409ih4lGHH8x+iUqP6wDYTh2LIEQ8YUOuSc+ZF7PjlgNhOC0uIgeT1jMNPkCqn8DStaVl/7fuBFggb8O8xdK4Z4alo79oirLuMsOjsHMy40t x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(48565401081)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB1615; x-ms-traffictypediagnostic: VI1PR0801MB1615: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(180628864354917)(192374486261705)(21748063052155); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93001095)(3002001)(3231254)(944501410)(52105095)(6055026)(149027)(150027)(6041310)(20161123562045)(20161123560045)(20161123558120)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:VI1PR0801MB1615; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0801MB1615; x-forefront-prvs: 0674DC6DD3 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(376002)(366004)(39380400002)(39860400002)(346002)(40434004)(199004)(189003)(486006)(55016002)(476003)(86362001)(25786009)(8936002)(81156014)(3480700004)(81166006)(14454004)(3660700001)(966005)(606006)(446003)(2900100001)(11346002)(6506007)(72206003)(6436002)(186003)(7696005)(7116003)(66066001)(53936002)(74316002)(26005)(93886005)(5660300001)(106356001)(7736002)(9686003)(102836004)(59450400001)(54896002)(33656002)(478600001)(6306002)(236005)(105586002)(76176011)(6246003)(5250100002)(97736004)(2906002)(229853002)(99286004)(3280700002)(316002)(6116002)(790700001)(110136005)(2501003)(68736007)(5890100001)(8676002)(3846002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB1615; H:VI1PR0801MB2112.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: X7DPgME3DPZmnzzKZkz9rsXfDlX5zPxFRHtQTrRVKTtgNVwsyStUjIq6H6FZ2BguvDOyi+c+xqaH2AerW8aHlK+ncRi9OM752HH4+Q0b9iNytFkd1BkqaPpq6KErZCWvPqc62BxGHgdlQqlMVw9/tGsqhuGPM9wOBs7h9/fz0KC181eLD44I0oWQRKmXDurT spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_VI1PR0801MB2112B889B6CED5687864B311FA920VI1PR0801MB2112_" MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 1e313750-3d85-48e3-dcc9-08d5bb0daf44 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: 1e313750-3d85-48e3-dcc9-08d5bb0daf44 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 May 2018 09:16:19.1037 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1615 Archived-At: Subject: Re: [Ace] EST over CoAP X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2018 09:16:25 -0000 --_000_VI1PR0801MB2112B889B6CED5687864B311FA920VI1PR0801MB2112_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =D8 But I don't think we can tell endpoints that they are on their own unl= ess they get the right hardware or they comply with the ACE-OAuth model, or= DOXS. [This is probably an issue unrelated to EST topic but worthwhile to talk ab= out nevertheless.] How do you expect companies to come up with reasonable IoT security? Our (Arm) thinking was that working on building blocks that are then combin= ed in complete IoT device management solutions (like LwM2M) and supplemente= d with security guidance that includes the implementation (software & hardw= are), as we do it with the Platform Security Architecture (see https://deve= loper.arm.com/products/architecture/platform-security-architecture), is the= only way to improve IoT security. If you just dump ideas and protocols wit= h lots of options to OEMs and let them figure out the security story themse= lves then guess what the outcome will be. Ciao Hannes IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. --_000_VI1PR0801MB2112B889B6CED5687864B311FA920VI1PR0801MB2112_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

=D8  But I don’t think we can tell endpoints that they are on their own u= nless they get the right hardware or they comply with the ACE-OAuth model, = or DOXS.

 

[This is probably an issue unrelated to EST topic but worthwhile = to talk about nevertheless.]

 

How do you expect compani= es to come up with reasonable IoT security?

=  

Our (= Arm) thinking was that working on building blocks that are then combined in= complete IoT device management solutions (like LwM2M) and supplemented wit= h security guidance that includes the implementation (software & hardware), as we do it with the Platform Se= curity Architecture (see https://developer.arm.com/products/architecture/platform-security-architect= ure), is the only way to improve IoT security. If you just dump ideas a= nd protocols with lots of options to OEMs and let them figure out the secur= ity story themselves then guess what the outcome will be.

 

Ciao=

Hannes

 

IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in any medium. Thank you. --_000_VI1PR0801MB2112B889B6CED5687864B311FA920VI1PR0801MB2112_-- From nobody Wed May 16 03:15:42 2018 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7490912D7EA; Wed, 16 May 2018 03:15:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.011 X-Spam-Level: X-Spam-Status: No, score=-0.011 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wtK0wofz5ff7; Wed, 16 May 2018 03:15:38 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0053.outbound.protection.outlook.com [104.47.1.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E09612D7E4; Wed, 16 May 2018 03:15:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=b6K679zP+l856ON20pDQ7PKdbgKYoYknjGZBttwZyks=; b=G6h0ffspg8O8GWGGkRlQ3+exDk7wsWr7XHYXGhe8DBhwa3ALKLQdtKXgdJX0CG8scI8PuHl92ZTVJCgoH9xLzExtctok6j/v1TIHG8dndfS71veQiwE8P0PiTFYxp+0AshMbh3zcLhXYDxm+3WQQ313yUCbMT/JNFua/0MA/qKw= Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB1518.eurprd08.prod.outlook.com (10.167.210.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.755.16; Wed, 16 May 2018 10:15:35 +0000 Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::7c43:c1a5:4f69:5365]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::7c43:c1a5:4f69:5365%17]) with mapi id 15.20.0755.018; Wed, 16 May 2018 10:15:35 +0000 From: Hannes Tschofenig To: Carsten Bormann CC: "ace@ietf.org" , core Thread-Topic: [Ace] Early media-type registration for EST over CoAP Thread-Index: AdPsKhcQ9FbwjekBT1SYYUyoYtG38gAB1S+AAAdDwHA= Date: Wed, 16 May 2018 10:15:35 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [156.67.194.220] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0801MB1518; 7:eJfs75bNpaQ8YojPd7RN/gstR2PcBKcoypdule8vmEL7a/LperTflzkhQftETv84WkoCUZNMMb14AVmbZuqr7n1++LDrBPeYEjQzdmylShhrjkxgo1XHr6OsjwuJLZbGBVjSnYcvw0xn4Gp1yOnTQSfLlzM+z2dhrQvLrsrmk+r9M5XF0izuu/Gu2nwCErFrXz6MqJQsXrfJzoq7sbAq0/2mdb3gOF9FvkHJl5jT+rgi85iwtuwxFmnqUAtrBxb5 x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB1518; x-ms-traffictypediagnostic: VI1PR0801MB1518: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(180628864354917); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3002001)(93006095)(93001095)(10201501046)(3231254)(944501410)(52105095)(6055026)(149027)(150027)(6041310)(20161123558120)(20161123562045)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:VI1PR0801MB1518; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0801MB1518; x-forefront-prvs: 0674DC6DD3 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39380400002)(366004)(39860400002)(396003)(376002)(346002)(13464003)(40434004)(57704003)(199004)(189003)(6506007)(86362001)(2906002)(3280700002)(99286004)(14454004)(478600001)(5660300001)(26005)(102836004)(66066001)(55016002)(486006)(53546011)(6436002)(5250100002)(229853002)(76176011)(3846002)(6116002)(11346002)(7696005)(72206003)(446003)(186003)(5890100001)(476003)(59450400001)(305945005)(68736007)(9686003)(3660700001)(2900100001)(53936002)(8936002)(25786009)(74316002)(6916009)(4326008)(7736002)(105586002)(81156014)(81166006)(106356001)(8676002)(33656002)(6246003)(97736004)(54906003)(316002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB1518; H:VI1PR0801MB2112.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: 99JY6WnH90yI4IslCSRzbtDADvpp/dVDhti94gblUZokFs23qpVFTrHpR54RY9r3mMEWUsbYq+6R3aByTqSxYfjLy1Chi/AvJ+9BRW6C+/wKKB/AUmtWrKQ9vEW1Rfmm5AiooMbbe3/CwW5mbEUatcMqWQDfhqdZQXkMLmgWVQ6Sr5G284roNaUZMuDf5u3A spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 58e5aac0-1e2c-4471-9e18-08d5bb15f6ed X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: 58e5aac0-1e2c-4471-9e18-08d5bb15f6ed X-MS-Exchange-CrossTenant-originalarrivaltime: 16 May 2018 10:15:35.3486 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1518 Archived-At: Subject: Re: [Ace] Early media-type registration for EST over CoAP X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2018 10:15:41 -0000 SGkgQ2Fyc3RlbiwNCg0KWWVzLCBJIGFtIHRhbGtpbmcgYWJvdXQgdGhlIENvbnRlbnQtRm9ybWF0 IG51bWJlcnMgZm9yIHRoZW0uDQpXb3VsZCBydD0iYWNlLmVzdCIgYmUgdGhlIHBhcmFtZXRlciB5 b3UgYXJlIHRhbGtpbmcgYWJvdXQ/DQoNCkNpYW8NCkhhbm5lcw0KDQotLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KRnJvbTogQ2Fyc3RlbiBCb3JtYW5uIFttYWlsdG86Y2Fib0B0emkub3JnXQ0K U2VudDogMTUgTWF5IDIwMTggMTE6NDUNClRvOiBIYW5uZXMgVHNjaG9mZW5pZw0KQ2M6IGFjZUBp ZXRmLm9yZzsgY29yZQ0KU3ViamVjdDogUmU6IFtBY2VdIEVhcmx5IG1lZGlhLXR5cGUgcmVnaXN0 cmF0aW9uIGZvciBFU1Qgb3ZlciBDb0FQDQoNCk9uIE1heSAxNSwgMjAxOCwgYXQgMTA6NTYsIEhh bm5lcyBUc2Nob2ZlbmlnIDxIYW5uZXMuVHNjaG9mZW5pZ0Bhcm0uY29tPiB3cm90ZToNCj4NCj4g SSBhbSBjdXJpb3VzIHdoZXRoZXIgaXQgd291bGQgYmUgcG9zc2libGUgdG8gYXNrIGZvciBlYXJs eSBtZWRpYS10eXBlIHJlZ2lzdHJhdGlvbiBvZiBhdCBsZWFzdCB0aGVzZSB0d28gdHlwZXM6DQo+ IC0gYXBwbGljYXRpb24vcGtjczctbWltZQ0KPiAtIGFwcGxpY2F0aW9uL3BrY3MxMA0KDQpUaGVy ZSBhbHJlYWR5IGFyZSByZWdpc3RlcmVkLg0KDQpJIHRoaW5rIHlvdSBhcmUgdGFsa2luZyBhYm91 dCBnZXR0aW5nIENvbnRlbnQtRm9ybWF0IG51bWJlcnMgZm9yIHRoZXNlPw0KRG8gd2UgbmVlZCBh bnkgcGFyYW1ldGVycyBvciBjb250ZW50LWNvZGluZ3Mgd2l0aCB0aGF0Pw0KDQpHcsO8w59lLCBD YXJzdGVuDQoNCklNUE9SVEFOVCBOT1RJQ0U6IFRoZSBjb250ZW50cyBvZiB0aGlzIGVtYWlsIGFu ZCBhbnkgYXR0YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbCBhbmQgbWF5IGFsc28gYmUgcHJpdmls ZWdlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIG5vdGlm eSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBkbyBub3QgZGlzY2xvc2UgdGhlIGNvbnRlbnRz IHRvIGFueSBvdGhlciBwZXJzb24sIHVzZSBpdCBmb3IgYW55IHB1cnBvc2UsIG9yIHN0b3JlIG9y IGNvcHkgdGhlIGluZm9ybWF0aW9uIGluIGFueSBtZWRpdW0uIFRoYW5rIHlvdS4NCg== From nobody Wed May 16 03:26:54 2018 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8274212D7F1; Wed, 16 May 2018 03:26:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8t0iAC0Q3oAk; Wed, 16 May 2018 03:26:46 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34F1D12D7EA; Wed, 16 May 2018 03:26:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w4GAQfcF006666; Wed, 16 May 2018 12:26:41 +0200 (CEST) Received: from [100.75.214.40] (ip-109-41-67-168.web.vodafone.de [109.41.67.168]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 40m9b52ZqDzDXlC; Wed, 16 May 2018 12:26:41 +0200 (CEST) Content-Type: multipart/alternative; boundary=Apple-Mail-EA3C581A-0CEB-415E-8ED0-9D97B4CAF75E Mime-Version: 1.0 (1.0) From: Carsten Bormann X-Mailer: iPhone Mail (15E302) In-Reply-To: Date: Wed, 16 May 2018 12:26:40 +0200 Cc: "ace@ietf.org" , core Content-Transfer-Encoding: 7bit Message-Id: <0158C0A6-C8D5-4F19-9C12-23BDC8A7768A@tzi.org> References: To: Hannes Tschofenig Archived-At: Subject: Re: [Ace] Early media-type registration for EST over CoAP X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2018 10:26:49 -0000 --Apple-Mail-EA3C581A-0CEB-415E-8ED0-9D97B4CAF75E Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I was thinking about media type parameters such as charset=3D"utf-8". The RT= value need to be registered separately, but we can be a bit lazy about that= .=20 Sent from mobile > On 16. May 2018, at 12:15, Hannes Tschofenig w= rote: >=20 > Hi Carsten, >=20 > Yes, I am talking about the Content-Format numbers for them. > Would rt=3D"ace.est" be the parameter you are talking about? >=20 > Ciao > Hannes >=20 > -----Original Message----- > From: Carsten Bormann [mailto:cabo@tzi.org] > Sent: 15 May 2018 11:45 > To: Hannes Tschofenig > Cc: ace@ietf.org; core > Subject: Re: [Ace] Early media-type registration for EST over CoAP >=20 >> On May 15, 2018, at 10:56, Hannes Tschofenig w= rote: >>=20 >> I am curious whether it would be possible to ask for early media-type reg= istration of at least these two types: >> - application/pkcs7-mime >> - application/pkcs10 >=20 > There already are registered. >=20 > I think you are talking about getting Content-Format numbers for these? > Do we need any parameters or content-codings with that? >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 > IMPORTANT NOTICE: The contents of this email and any attachments are confi= dential 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 o= ther person, use it for any purpose, or store or copy the information in any= medium. Thank you. >=20 >=20 --Apple-Mail-EA3C581A-0CEB-415E-8ED0-9D97B4CAF75E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable I was thinking about media type parameters s= uch as charset=3D"utf-8". The RT value need to be registered separately, but= we can be a bit lazy about that. 

Sent from mobile
On 16. May 2018, at 12:15, Hannes Tschofenig <Hannes.Tschofenig@arm.com> wrote:

Hi Carsten,

Yes, I am talking about the Content-Format numbers for them.
<= span>Would rt=3D"ace.est" be the parameter you are talking about?
=
Ciao
Hannes
-----Original Message-----
From: Carsten Bormann [mailto:cabo@tzi.org]
Sent:= 15 May 2018 11:45
To: Hannes Tschofenig
Cc:= ace@ietf.org; core
Subj= ect: Re: [Ace] Early media-type registration for EST over CoAP

On May 15, 2018, at 10:56, Hannes Tschofenig <Hannes.Tschofenig@arm.com> wrot= e:

I am curious whether it would be possible to ask fo= r early media-type registration of at least these two types:
- application/pkcs7-mime
<= /blockquote>
- application/pkcs10
<= /blockquote>
There already are registered.
<= span>
I think you are talking about getting Content-Format n= umbers for these?
Do we need any parameters or content-codin= gs with that?

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

IMPORTANT NOTICE: The contents of this email an= d any attachments are confidential and may also be privileged. If you are no= t the intended recipient, please notify the sender immediately and do not di= sclose the contents to any other person, use it for any purpose, or store or= copy the information in any medium. Thank you.

<= span>
= --Apple-Mail-EA3C581A-0CEB-415E-8ED0-9D97B4CAF75E-- From nobody Wed May 16 03:29:55 2018 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C87CB12D7F6; Wed, 16 May 2018 03:29:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FdxH7qdrOmsv; Wed, 16 May 2018 03:29:47 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D364A12D7EA; Wed, 16 May 2018 03:29:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w4GATfRY008452; Wed, 16 May 2018 12:29:41 +0200 (CEST) Received: from [100.75.214.40] (ip-109-41-67-168.web.vodafone.de [109.41.67.168]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 40m9fX6yxpzDXlG; Wed, 16 May 2018 12:29:40 +0200 (CEST) Content-Type: multipart/alternative; boundary=Apple-Mail-7EA8625C-9773-4351-9ECF-487B4CEF489D Mime-Version: 1.0 (1.0) From: Carsten Bormann X-Mailer: iPhone Mail (15E302) In-Reply-To: <0158C0A6-C8D5-4F19-9C12-23BDC8A7768A@tzi.org> Date: Wed, 16 May 2018 12:29:40 +0200 Cc: "ace@ietf.org" , core Content-Transfer-Encoding: 7bit Message-Id: <8976A481-6467-4DAD-A5ED-9AE05E9CC62D@tzi.org> References: <0158C0A6-C8D5-4F19-9C12-23BDC8A7768A@tzi.org> To: Hannes Tschofenig Archived-At: Subject: Re: [Ace] Early media-type registration for EST over CoAP X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2018 10:29:49 -0000 --Apple-Mail-7EA8625C-9773-4351-9ECF-487B4CEF489D Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Forgot to add another example: the content-format numbers for COSE have para= meters.=20 Sent from mobile > On 16. May 2018, at 12:26, Carsten Bormann wrote: >=20 > I was thinking about media type parameters such as charset=3D"utf-8". The R= T value need to be registered separately, but we can be a bit lazy about tha= t.=20 >=20 > Sent from mobile >=20 >> On 16. May 2018, at 12:15, Hannes Tschofenig w= rote: >>=20 >> Hi Carsten, >>=20 >> Yes, I am talking about the Content-Format numbers for them. >> Would rt=3D"ace.est" be the parameter you are talking about? >>=20 >> Ciao >> Hannes >>=20 >> -----Original Message----- >> From: Carsten Bormann [mailto:cabo@tzi.org] >> Sent: 15 May 2018 11:45 >> To: Hannes Tschofenig >> Cc: ace@ietf.org; core >> Subject: Re: [Ace] Early media-type registration for EST over CoAP >>=20 >>> On May 15, 2018, at 10:56, Hannes Tschofenig = wrote: >>>=20 >>> I am curious whether it would be possible to ask for early media-type re= gistration of at least these two types: >>> - application/pkcs7-mime >>> - application/pkcs10 >>=20 >> There already are registered. >>=20 >> I think you are talking about getting Content-Format numbers for these? >> Do we need any parameters or content-codings with that? >>=20 >> Gr=C3=BC=C3=9Fe, Carsten >>=20 >> IMPORTANT NOTICE: The contents of this email and any attachments are conf= idential 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 o= ther person, use it for any purpose, or store or copy the information in any= medium. Thank you. >>=20 >>=20 --Apple-Mail-7EA8625C-9773-4351-9ECF-487B4CEF489D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Forgot to add another example: the content-= format numbers for COSE have parameters. 

Sent from mobile
=

On 16. May 2018, at 12:26, Carsten Bormann <cabo@tzi.org> wrote:

I was thinking about media type parameters such as charset=3D"utf-8". T= he RT value need to be registered separately, but we can be a bit lazy about= that. 

Sent from mobile

On 16. May 2018, at 12:15= , Hannes Tschofenig <Hannes.= Tschofenig@arm.com> wrote:

Hi Carsten,

Yes, I am talking about= the Content-Format numbers for them.
Would rt=3D"ace.est" b= e the parameter you are talking about?

Ciao=
Hannes

-----Original Messa= ge-----
From: Carsten Bormann [mailto:cabo@tzi.org]
Sent: 15 May 2018 11:45To: Hannes Tschofenig
Cc: ace@ietf.org; core
Subject: Re: [Ace] Early media-= type registration for EST over CoAP

On May 1= 5, 2018, at 10:56, Hannes Tschofenig <Hannes.Tschofenig@arm.com> wrote:

I a= m curious whether it would be possible to ask for early media-type registrat= ion of at least these two types:
- application/pkcs7-mime
- application/pkcs10
There already are registered.

I thin= k you are talking about getting Content-Format numbers for these?
= Do we need any parameters or content-codings with that?

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

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, pl= ease notify the sender immediately and do not disclose the contents to any o= ther person, use it for any purpose, or store or copy the information in any= medium. Thank you.


= --Apple-Mail-7EA8625C-9773-4351-9ECF-487B4CEF489D-- From nobody Wed May 16 03:39:53 2018 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28C8B12D879 for ; Wed, 16 May 2018 03:39:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.011 X-Spam-Level: X-Spam-Status: No, score=-0.011 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HM45Ihn9MSu8 for ; Wed, 16 May 2018 03:39:50 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0066.outbound.protection.outlook.com [104.47.2.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B96212D864 for ; Wed, 16 May 2018 03:39:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=xAWnrab5CYJMiik/TajeIgIvH3BHSMVOxBemUUi+6K8=; b=CX7S4syImGvuqQO3VeFlTI6Cx416tOV+GAeue9PH4RduL26h82pyoxaaqV266yTG9FoHb2midjMNBP1MEzbk93qWkDAUzngB2zU2zrya9UE2WGR5KIcOtMVxJqskaj06H3soURUCZMVdR/z7uRSqQc8I/jyKy8ieU9zgWlT8S/o= Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB1503.eurprd08.prod.outlook.com (10.167.210.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.755.16; Wed, 16 May 2018 10:39:46 +0000 Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::7c43:c1a5:4f69:5365]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::7c43:c1a5:4f69:5365%17]) with mapi id 15.20.0755.018; Wed, 16 May 2018 10:39:46 +0000 From: Hannes Tschofenig To: Michael Richardson CC: "ace@ietf.org" Thread-Topic: [Ace] Early media-type registration for EST over CoAP Thread-Index: AdPsKhcQ9FbwjekBT1SYYUyoYtG38gARurCAACPFG9A= Date: Wed, 16 May 2018 10:39:46 +0000 Message-ID: References: <30374.1526404823@localhost> In-Reply-To: <30374.1526404823@localhost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [156.67.194.220] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0801MB1503; 7:kfJ8j2n7XH2/Fta7MRsg/4FGAaG7qng2nnwRge29f4sy3p8t2G9CJCnwq2MGss7CXgKS64g4fLYea7WN3tDW2h2p9idgUrH82O+O9xMjYdgZsfJ9jLxhR422ROxXMSOkGHruVEAGJ/kKiS0r871xpBGlznv/5EsrF48asOlpkQ5tOuOo8X8EhaWfH0NwaginJ6bPvBRZqnjQukORQnjzJSwzVHJ7fd7EtOX1fsnF6+lUNbt9TOCrpptKX1w9xSbU x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(48565401081)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB1503; x-ms-traffictypediagnostic: VI1PR0801MB1503: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006095)(93001095)(3231254)(944501410)(52105095)(6055026)(149027)(150027)(6041310)(20161123560045)(20161123558120)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(6072148)(201708071742011); SRVR:VI1PR0801MB1503; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0801MB1503; x-forefront-prvs: 0674DC6DD3 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(39380400002)(376002)(346002)(396003)(366004)(40434004)(189003)(199004)(6506007)(102836004)(86362001)(53936002)(6246003)(486006)(446003)(11346002)(6116002)(3846002)(105586002)(106356001)(68736007)(55016002)(186003)(26005)(59450400001)(3280700002)(2906002)(9686003)(4326008)(5890100001)(3660700001)(25786009)(5250100002)(305945005)(229853002)(14454004)(33656002)(66066001)(76176011)(2900100001)(7696005)(7736002)(74316002)(316002)(97736004)(8936002)(6436002)(99286004)(81156014)(476003)(8676002)(5660300001)(72206003)(478600001)(81166006); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB1503; H:VI1PR0801MB2112.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:3; A:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: 2GEoB4HTb3nQIaUOt28mj2bWcbZB/2qheSSxWtdTemQhIID2YTWmZBmBnaUpBy0/R8AHrgE0fT+sU7gguWj/Wytf4w88egaYPHu/OHwRc2juHtKXvqTIYct4yxpD3W/Z9vI84rKlS+lNbQOFatU4EqN+y78vb/p0MCW8VoINZGsB+Q/kd/D+7j6R6GKCabLE spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: bc6d5cf3-81d3-4a6e-af43-08d5bb1957fa X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: bc6d5cf3-81d3-4a6e-af43-08d5bb1957fa X-MS-Exchange-CrossTenant-originalarrivaltime: 16 May 2018 10:39:46.6166 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1503 Archived-At: Subject: Re: [Ace] Early media-type registration for EST over CoAP X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2018 10:39:52 -0000 > Hannes: do you have any opinion about the necessity of going through /.we= ll-known/core to get the short URL, vs just using a /.well-known/est URL? (RTT for the lookup vs extra bytes in the URL) Are you asking me about these two options: Option #1 - going through /.well-known/core REQ: GET /.well-known/core?rt=3Dace.est RES: 2.05 Content ; rt=3D"ace.est" Option #2 - using a /.well-known/est URL REQ: GET /.well-known/est RES: 2.05 Content ; rt=3D"ace.est" IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. From nobody Wed May 16 05:16:24 2018 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA71C12D872 for ; Wed, 16 May 2018 05:16:22 -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, 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 YZFaeUuOqi4p for ; Wed, 16 May 2018 05:16:20 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD6DD12946D for ; Wed, 16 May 2018 05:16:20 -0700 (PDT) Received: from dooku.sandelman.ca (unknown [75.98.19.134]) by relay.sandelman.ca (Postfix) with ESMTPS id BF16C1F906; Wed, 16 May 2018 12:16:15 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id 09A241145; Wed, 16 May 2018 13:15:52 +0100 (BST) From: Michael Richardson To: Hannes Tschofenig cc: "ace\@ietf.org" In-reply-to: References: <30374.1526404823@localhost> Comments: In-reply-to Hannes Tschofenig message dated "Wed, 16 May 2018 10:39:46 -0000." X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Wed, 16 May 2018 08:15:52 -0400 Message-ID: <29971.1526472952@dooku.sandelman.ca> Archived-At: Subject: Re: [Ace] Early media-type registration for EST over CoAP X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2018 12:16:23 -0000 --=-=-= Content-Type: text/plain Hannes Tschofenig wrote: >> Hannes: do you have any opinion about the necessity of going through >> /.well-known/core to get the short URL, vs just using a >> /.well-known/est URL? Yes, exactly. Is option #1 useful enough to justify the code to parse links? Os is the code impact already paid for in your view? > (RTT for the lookup vs extra bytes in the URL) > Are you asking me about these two options: > Option #1 - going through /.well-known/core > REQ: GET /.well-known/core?rt=ace.est > RES: 2.05 Content ; rt="ace.est" > Option #2 - using a /.well-known/est URL > REQ: GET /.well-known/est > RES: 2.05 Content ; rt="ace.est" -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJa/CD3AAoJEJVM4Vb9/EKQf+QH/iZJn14m+QC3aLd7XMXbxHPh +t08sJqMtvA5SudmvJdWWIwfTZFjyQ6WqVz562dZUlhh46mDrSYXqRf3YYhvLVeC JOvjPx6LDWxc/C/v4SqpSZ6/Bn4ct9mu/lfWTqTF3G/xcnSlpaV53aUz1xspnPfP exBRW4A9dajmbUfYLjyipQfyQdj4Focxz+Gv3OeRvxW5VvhNZGTcvff/CA/0pJTU R0lrOKfU/QHdV883tQ5ybwqy5lb92oU2RfnezlFzk962VnFstmk19OOhOgDrRyq+ Duo1h1blkcqcjHjrA1ZQIPsXm8PrnIWLVp0DATa1Y6y9vfngRn2DDCVpV2iAYfM= =5NAZ -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed May 16 05:49:15 2018 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2559D12946D for ; Wed, 16 May 2018 05:49:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 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, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t4y3wjJ_kRdf for ; Wed, 16 May 2018 05:49:10 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0080.outbound.protection.outlook.com [104.47.0.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA90112706D for ; Wed, 16 May 2018 05:49:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=WAn4fdjHNAxgjbceNwfD8VDaXWJozFRSHUDpv0c790Y=; b=cakcJkBbGT+ToGVhHsjOivaZo2vtUOd2aPgJv4fmJULGLjf4wBQVTBSSc8dqgCb/r1bdrraVYPByJAxzydigtN8c+GDMmJZZquOQQrxl9O/RVv+h8MUpBUOxtqB4HzMDovccyA2zD7d6NYySGqAg9vgD4mewyy7Wuvrra2Eg/dU= Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB2111.eurprd08.prod.outlook.com (10.173.75.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.776.11; Wed, 16 May 2018 12:49:06 +0000 Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::7c43:c1a5:4f69:5365]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::7c43:c1a5:4f69:5365%17]) with mapi id 15.20.0755.018; Wed, 16 May 2018 12:49:06 +0000 From: Hannes Tschofenig To: Michael Richardson CC: "ace@ietf.org" Thread-Topic: [Ace] Early media-type registration for EST over CoAP Thread-Index: AdPsKhcQ9FbwjekBT1SYYUyoYtG38gARurCAACPFG9AAA+LpAAABIS9w Date: Wed, 16 May 2018 12:49:06 +0000 Message-ID: References: <30374.1526404823@localhost> <29971.1526472952@dooku.sandelman.ca> In-Reply-To: <29971.1526472952@dooku.sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [156.67.194.220] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0801MB2111; 7:paq395DYGuqbXeANUDzoK1mdjcSdiPsPSbkKhYmXRS//hVzHK9GZZ4ANPtgvfSxsfc3vkIZQ81df+tWK9PthfXGqrqnAEl/D/sDSUQkDz+FU0UEX8RzbKbeYH57WdLdLySWGyu4ISf9hNK+vUrPtp7QBM5AXy//3zr7ZGeSsP19f6gC3T1Pww6KP0HBp65abW/KT+MxXM6TSEvW5FbsT8OSGYU3tgsFkmRX0FR1C8l+nw07w9Oi4pnNIZ+Y9GVYA x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(48565401081)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB2111; x-ms-traffictypediagnostic: VI1PR0801MB2111: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(180628864354917); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3231254)(944501410)(52105095)(3002001)(93006095)(93001095)(10201501046)(6055026)(149027)(150027)(6041310)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(20161123558120)(6072148)(201708071742011); SRVR:VI1PR0801MB2111; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0801MB2111; x-forefront-prvs: 0674DC6DD3 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(396003)(39380400002)(366004)(39860400002)(346002)(40434004)(189003)(199004)(13464003)(7736002)(486006)(305945005)(55016002)(11346002)(25786009)(476003)(53936002)(6436002)(229853002)(446003)(6306002)(9686003)(6246003)(966005)(4326008)(14454004)(5250100002)(72206003)(5890100001)(186003)(478600001)(26005)(102836004)(2900100001)(53546011)(6506007)(59450400001)(76176011)(66066001)(7696005)(81166006)(99286004)(2906002)(81156014)(8676002)(3280700002)(8936002)(3660700001)(5660300001)(97736004)(105586002)(316002)(93886005)(33656002)(74316002)(3846002)(86362001)(6116002)(106356001)(68736007); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB2111; H:VI1PR0801MB2112.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: DcQv4ZJIRDWmrVVEP0eZpO+k4mzl6cKbQpDUExfNzj/mpgPYguuPJK8kKEOXuI3ms2VgSg6jDvHa5CqI3yHxI+6pNQ998okmed5UA3MyTn2HdEafe7OkzlS9q1lzCdYzxgDWqofV8WRiW4XGgn2g6FxKpZaSqdg4GEpyoWDJR9j0tdmGNSh616DZgSk971+O spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 50866aab-a315-4cf6-bdf2-08d5bb2b6961 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: 50866aab-a315-4cf6-bdf2-08d5bb2b6961 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 May 2018 12:49:06.7700 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB2111 Archived-At: Subject: Re: [Ace] Early media-type registration for EST over CoAP X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2018 12:49:13 -0000 I don't have a strong opinion about option #2 appears to be slightly better= . I guess hard-cording URLs will not work.... -----Original Message----- From: Michael Richardson [mailto:mcr+ietf@sandelman.ca] Sent: 16 May 2018 14:16 To: Hannes Tschofenig Cc: ace@ietf.org Subject: Re: [Ace] Early media-type registration for EST over CoAP Hannes Tschofenig wrote: >> Hannes: do you have any opinion about the necessity of going through >> /.well-known/core to get the short URL, vs just using a >> /.well-known/est URL? Yes, exactly. Is option #1 useful enough to justify the code to parse link= s? Os is the code impact already paid for in your view? > (RTT for the lookup vs extra bytes in the URL) > Are you asking me about these two options: > Option #1 - going through /.well-known/core > REQ: GET /.well-known/core?rt=3Dace.est > RES: 2.05 Content ; rt=3D"ace.est" > Option #2 - using a /.well-known/est URL > REQ: GET /.well-known/est > RES: 2.05 Content ; rt=3D"ace.est" -- ] Never tell me the odds! | ipv6 mesh network= s [ ] Michael Richardson, Sandelman Software Works | network architect= [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [ -- Michael Richardson , Sandelman Software Works -=3D = IPv6 IoT consulting =3D- IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. From nobody Wed May 16 06:18:41 2018 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51A33126B72 for ; Wed, 16 May 2018 06:18:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iyIXaOJgnaE3 for ; Wed, 16 May 2018 06:18:37 -0700 (PDT) Received: from taper.sei.cmu.edu (taper.sei.cmu.edu [147.72.252.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4363B1201FA for ; Wed, 16 May 2018 06:18:36 -0700 (PDT) Received: from delp.sei.cmu.edu (delp.sei.cmu.edu [10.64.21.31]) by taper.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id w4GDIYiI019621 for ; Wed, 16 May 2018 09:18:34 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 taper.sei.cmu.edu w4GDIYiI019621 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1526476714; bh=QRA0Fvw2IjkbbuorarYjdp77O7f8wpibq9NfiI+mgyw=; h=From:To:Subject:Date:From; b=PFpYDENAoCWd+pzvohBanRH9G7sZDH0t4P52nDdDiXhmc5I6YDFRJJGYxDEKjJ+AD jflkCuSQ+RktsvZ+B1PVIrQJ7MBAlDyPKiq3ZD4OfJ+Z+SrprPXSitStbRFGZl0r28 nzGz8qTqa8hw89tRjclS3B7zuRH6KwAZVmxKe1R8= Received: from CASCADE.ad.sei.cmu.edu (cascade.ad.sei.cmu.edu [10.64.28.248]) by delp.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id w4GDIOi4027395 for ; Wed, 16 May 2018 09:18:24 -0400 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASCADE.ad.sei.cmu.edu ([10.64.28.248]) with mapi id 14.03.0399.000; Wed, 16 May 2018 09:18:23 -0400 From: Roman Danyliw To: "ace@ietf.org" Thread-Topic: Reminder -- WGLC on draft-ietf-ace-cwt-proof-of-possession-02 Thread-Index: AdPtGEH4pwi+TQ+ERcWMpVROGZpXzg== Date: Wed, 16 May 2018 13:18:22 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC014C3B7AED@marathon> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [Ace] Reminder -- WGLC on draft-ietf-ace-cwt-proof-of-possession-02 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2018 13:18:39 -0000 Hello! A reminder to the WG, draft-ietf-ace-cwt-proof-of-possession is in WGLC. P= lease send feedback to the mailing list by Wednesday, May 23. Thanks, Roman and Jim > -----Original Message----- > From: Ace [mailto:ace-bounces@ietf.org] On Behalf Of Roman Danyliw > Sent: Tuesday, May 08, 2018 6:19 PM > To: ace@ietf.org > Subject: [Ace] WGLC on draft-ietf-ace-cwt-proof-of-possession-02 >=20 > Hello! >=20 > Consistent with the feedback from the editor team at the London meeting, > we are starting a working group last call (WGLC) for the "Proof-of-Posses= sion > Key Semantics for CBOR Web Tokens (CWTs)" draft: >=20 > ** draft-ietf-ace-cwt-proof-of-possession-02 > ** https://tools.ietf.org/html/draft-ietf-ace-cwt-proof-of-possession-02 >=20 > Please send comments to the mailing list -- feedback on issues or needed > changes; as well as endorsements that this draft is ready. >=20 > This WGLC will end on Wednesday, May 23, 2018. >=20 > Thanks, > Roman and Jim >=20 > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace From nobody Wed May 16 15:51:22 2018 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD51512D95F for ; Wed, 16 May 2018 15:51:20 -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, 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 WiYF7lDed_FN for ; Wed, 16 May 2018 15:51:18 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D406126CBF for ; Wed, 16 May 2018 15:51:18 -0700 (PDT) Received: from dooku.sandelman.ca (unknown [209.171.88.177]) by relay.sandelman.ca (Postfix) with ESMTPS id 546041F906; Wed, 16 May 2018 22:51:13 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id C079B137D; Wed, 16 May 2018 23:50:52 +0100 (BST) From: Michael Richardson To: Michael StJohns cc: ace@ietf.org In-reply-to: <53811ca9-0727-414a-4d77-e0f73d8c469a@comcast.net> References: <30117.1526309628@localhost> <53811ca9-0727-414a-4d77-e0f73d8c469a@comcast.net> Comments: In-reply-to Michael StJohns message dated "Mon, 14 May 2018 16:50:03 -0400." X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Wed, 16 May 2018 18:50:52 -0400 Message-ID: <17239.1526511052@dooku.sandelman.ca> Archived-At: Subject: [Ace] CA generated keys (was Re: EST over CoAP) X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2018 22:51:21 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Michael StJohns wrote: > Basically, the argument I'm hearing again is that we have to have > common protocols that work with the least capable devices in the same > way that they work with more capable devices.=C2=A0=C2=A0 Which then = is taken to > mean that we have to limit the security of said protocols to what's > available with those most limited devices. This is not really what's going on here. The argument is whether device generate private keys should be supported in the constrained version of EST. The RA/CA (RFC5280 terms) side of things in generally assumed not be seriously contrained. (I expect to install a CA on an openwrt based Turris home router, but that's equivalent to a 15 year old laptop, and hardly counts as constrained) There is no reason why a RA/CA(%) can't support server-side key generation according to RFC7030 section 4.4 as well as permitting capable devices to generate their own keys. Having the CA generate keys seemed to be all the rage at some point. I was never clear if this was because desktop OSes couldn't be trusted to do it properly, or because end-users wanted their private key as part of their mobile profile, or because of the implicit escrow that it permitted. (Remember splitting signing and encrypting keys...) Panos' situation is, I understand, that he has customers with an extensive deployment of devices in the field. They currently use a proprietary enrollment and key distribution system. They want to "upgrade" to CoAP-EST, but clearly there are some concerns about local key generation. I don't kn= ow why exactly, but I suspect it has to with the validation (FIPS140) of the libraries available on that platform: perhaps they are not validated to create their own keys...(yet?) But they can be field upgraded in an unattended fashion to use a standard protocol, as long as they don't have to do new crypto tricks *today*. (%)- In smaller/self-contained systems, the Registration Authority (RA) is often co-located (part of, implemented by the same system) with the Certificate Authority. I actually don't know if the RA or CA generates the private key. =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJa/LXMAAoJEJVM4Vb9/EKQ05oH/2TOt7T+i74jn0LCVXbQp6mx OIvbHMg5KJIcqm09oO8bv8k/TY1xGCNi8IRjYs3jLqo/fSAy57tr0OznZ+JkDmLo 3SxK22/cN3MCPTbxWyI1PUV4doOfwGuSyjZbC29ypmtEDsHq11GRZHtf1wCLZcSz P+58/rS6P6U1Q+WdmHyi0jKY3Z71CyyaYg5qQw+NT8OlDQkMWv1d45iquEBxBVqb fNw7TwcHvH+CQauypL2G9xrRoPsPm1ps3Lz+16eRjghjJm1rojiDlWKY086Q0gKa 3aFtC+/QAZKJah8gLgv+kNTA5DjGiPI++YvOfVMwtg98KYeGUXKJfDaO5Hko2zo= =mPVD -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed May 16 18:39:30 2018 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69F3F12E055 for ; Wed, 16 May 2018 18:39:29 -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, 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 FSz7OcC9_u2e for ; Wed, 16 May 2018 18:39:27 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00::f03c:91ff:feae:de77]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C35E91241F5 for ; Wed, 16 May 2018 18:39:27 -0700 (PDT) Received: from dooku.sandelman.ca (unknown [209.171.88.177]) by relay.sandelman.ca (Postfix) with ESMTPS id 569561F906; Thu, 17 May 2018 01:39:25 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id D01CE137D; Thu, 17 May 2018 02:39:03 +0100 (BST) From: Michael Richardson To: Hannes Tschofenig cc: "ace\@ietf.org" In-reply-to: References: <30374.1526404823@localhost> <29971.1526472952@dooku.sandelman.ca> Comments: In-reply-to Hannes Tschofenig message dated "Wed, 16 May 2018 12:49:06 -0000." X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Wed, 16 May 2018 21:39:03 -0400 Message-ID: <31087.1526521143@dooku.sandelman.ca> Archived-At: Subject: Re: [Ace] Early media-type registration for EST over CoAP X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 May 2018 01:39:30 -0000 --=-=-= Content-Type: text/plain Hannes Tschofenig wrote: > I don't have a strong opinion about option #2 appears to be slightly > better. Oh, I misread your options before. Hannes Tschofenig wrote: >> (RTT for the lookup vs extra bytes in the URL) >> Are you asking me about these two options: >> Option #1 - going through /.well-known/core >> REQ: GET /.well-known/core?rt=ace.est >> RES: 2.05 Content ; rt="ace.est" >> Option #2 - using a /.well-known/est URL >> REQ: GET /.well-known/est >> RES: 2.05 Content ; rt="ace.est" Option 2 is not substituting /.well-known/core for /.well-known/est (and doing resource discovery and then learn one uses /est-root/rv, etc.) but rather not doing resource discovery, just go directly to /.well-known/est/rv, which is what we do in RFC7030. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJa/N03AAoJEJVM4Vb9/EKQNnMH/3hGZZ6iiYRc1jn1ZsEiTlpC EXSr4jrd7QIA+bnBozD7g4hxUZq8btrnbpuH6ZjDoCsvK2KcFvnU1DIjqyPXwd6+ LFtAp3GvdDPpRdF2JQa9CdrayuvaAuS/zXNgbL9cG1o/paDw/2N+9C6y0UZB2zmk Im/3ezjTuU9pvZJ3fH7DI+aYqr917kXBO+H29LLIKsIPefQTbV5NG94jvYJIXPQr sYxMWyTqyH3cv+BFPst4yAyJOt3iXZqVT3Xx7cSeWJyared4m5GmQZ+hLUPxcGY/ MbRQ3ZdnOCUkcrppU0nIeC3iVJDpsTU32xLi+P3eLcEq/bQLbDavpmaqSqo/Qng= =Smwv -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri May 18 10:59:46 2018 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EB4512D95D for ; Fri, 18 May 2018 10:59:44 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eq13Foz3CVuM for ; Fri, 18 May 2018 10:59:42 -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 A4BC512D942 for ; Fri, 18 May 2018 10:59:41 -0700 (PDT) Received: from Jude (192.168.1.166) by mail2.augustcellars.com (192.168.1.201) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 18 May 2018 10:56:55 -0700 From: Jim Schaad To: 'Ludwig Seitz' , References: <005601d3e622$af427100$0dc75300$@augustcellars.com> In-Reply-To: Date: Fri, 18 May 2018 10:59:33 -0700 Message-ID: <004c01d3eed1$fc118ae0$f434a0a0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQIYpAXHW23Avzfol4dRnuBSz27O0gFzxbvDo6C84iA= X-Originating-IP: [192.168.1.166] Archived-At: Subject: Re: [Ace] OAuth-Authz Interop X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 May 2018 17:59:44 -0000 We are going to go with May 30 07:00 PDT (14:00 UTC) If there is anyone who has an IPv6 only client, please let me know as I will need to get tunneling setup for my server. (An IPv6 only server is not a problem.) Ludwig, we made some changes to the document at the last F2F meeting. It would be nice to get those changes published. Jim > -----Original Message----- > From: Ace On Behalf Of Ludwig Seitz > Sent: Tuesday, May 15, 2018 6:47 AM > To: ace@ietf.org > Subject: Re: [Ace] OAuth-Authz Interop > > On 2018-05-07 18:44, Jim Schaad wrote: > > I have been meaning to get this out for a while and have failed. A > > doodle poll to setup an interop event for this work is at > > https://doodle.com/poll/k27g9r26bghvnytu If you want to participate > > and none of the times are good please let me know. > > > > Things for testing: > > 1) DTLS profile w/ shared secret > > 2) DTLS profile w/ RPK > > 3) OSCORE profile > > > > The dates Jim has proposed in the doodle are quite close already, and the > poll is still quite empty. Is there any specific reason why the other > implementers won't/cannot commit to this at this point in time? > > /Ludwig > > -- > Ludwig Seitz, PhD > Security Lab, RISE SICS > Phone +46(0)70-349 92 51 > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace From nobody Sun May 20 04:34:25 2018 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CCF71270A0; Sun, 20 May 2018 04:34:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] 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 8LN0ZnLnqE_E; Sun, 20 May 2018 04:34:20 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0135.outbound.protection.outlook.com [104.47.37.135]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0075F12708C; Sun, 20 May 2018 04:34:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=8w+BbrLJ5vJXiLH6CS572/VVo/ZiXFDIfnwUDXXwxI4=; b=Bfv5/dtpSv+UFijRCxkZ4mxhnw7sH1vzpDf+TsL/leNWvCcIaUh1XPR+dGs44HQ4fBpGI2E4P52kPppnChoAsWgh0QTQU3p/0mlakJcvHVjybz+7P9vxCnbP7L5xNMX47OpzVfzTpmCqPqNPfLjeQ2zQnEN9XkRvNmvPriUV8+E= Received: from SN6PR00MB0304.namprd00.prod.outlook.com (52.132.117.158) by SN6PR00MB0398.namprd00.prod.outlook.com (52.132.118.29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.824.0; Sun, 20 May 2018 11:34:13 +0000 Received: from SN6PR00MB0304.namprd00.prod.outlook.com ([fe80::5444:5f2b:6904:5012]) by SN6PR00MB0304.namprd00.prod.outlook.com ([fe80::5444:5f2b:6904:5012%3]) with mapi id 15.20.0828.000; Sun, 20 May 2018 11:34:13 +0000 From: Mike Jones To: Jim Schaad , "draft-ietf-ace-cwt-proof-of-possession@ietf.org" CC: "ace@ietf.org" Thread-Topic: [Ace] WGLC on draft-ietf-ace-cwt-proof-of-possession-02 Thread-Index: AdPnGgXMYVrDIRKQRwyiq8BLgNVR0wAN1QSAAgfdtpA= Date: Sun, 20 May 2018 11:34:13 +0000 Message-ID: References: <359EC4B99E040048A7131E0F4E113AFC014C3AA67D@marchand> <00ad01d3e751$5c1f03a0$145d0ae0$@augustcellars.com> In-Reply-To: <00ad01d3e751$5c1f03a0$145d0ae0$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [62.216.152.74] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; SN6PR00MB0398; 7:Am6JQ4KUsqWUltD8aREAwEJ5vING2Lu7Qy3Vu9Re7KN5EwubWZHCAlDJlCUu56/VvV5HPHUJCCtOUQzEdY6i7Mr7McTEbU37qMSqQQ34avyGsVSHow7qug2EjXWD2cpQMWyvHfpD5N0q6MyiH/ywHax/mJ2+O2SdVNvcdzx17BRoAD7GREC6hnqc3dpIfMiOssnwTJtRbAdq2Xk+VCtEH0M9KzZ6NzFo2/6/U3XyjHlGQTt1BfdmmcqA2EglbeSO; 20:ZlXCkHtqFk0kUtd7YoYWVTVCG4jqhJD11bD8oljExP1k83JEqAjU9tA8+TK/5aYwSpKqQdtxnB0Q1LC0rBPczusdX69abfns68ENljkXDpQOQg5UGoiLHxRdZqFdS6/IdYssL/E98slRuDLdHoQ+uz1JsDgVgJEMn0Qc7zxIm7w= x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(48565401081)(2017052603328)(7193020); SRVR:SN6PR00MB0398; x-ms-traffictypediagnostic: SN6PR00MB0398: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705)(38170694233816)(788757137089); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(2017102700009)(2017102701064)(6040522)(2401047)(5005006)(8121501046)(2017102702064)(20171027021009)(20171027022009)(20171027023009)(20171027024009)(20171027025009)(20171027026009)(2017102703076)(3002001)(93006095)(93001095)(10201501046)(3231254)(2018427008)(944501410)(52105095)(6055026)(149027)(150027)(6041310)(20161123562045)(20161123564045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(6072148)(201708071742011)(7699016); SRVR:SN6PR00MB0398; BCL:0; PCL:0; RULEID:; SRVR:SN6PR00MB0398; x-forefront-prvs: 06780E24F8 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(376002)(39380400002)(39860400002)(346002)(366004)(51444003)(199004)(189003)(13464003)(74316002)(66066001)(229853002)(10290500003)(6436002)(5250100002)(33656002)(14454004)(8990500004)(55016002)(26005)(72206003)(53936002)(478600001)(186003)(10090500001)(2501003)(68736007)(966005)(6306002)(9686003)(102836004)(5660300001)(2900100001)(53376002)(105586002)(86362001)(6246003)(4326008)(8936002)(110136005)(25786009)(81166006)(6506007)(53546011)(8676002)(81156014)(486006)(316002)(7696005)(97736004)(59450400001)(2906002)(6116002)(476003)(3846002)(7736002)(3660700001)(11346002)(305945005)(99286004)(446003)(3280700002)(76176011)(22452003)(86612001)(106356001); DIR:OUT; SFP:1102; SCL:1; SRVR:SN6PR00MB0398; H:SN6PR00MB0304.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-microsoft-antispam-message-info: 0KC4Jg2FPmbuSXZKQseoCD6B2jMImZq01VPsqy2YEobBWnNS35b5QjEqCke/s6P1wlDAwM5y2p6QP9O5Jz4KL1K6nh77WY3g3/ZDS0eRBE9M7NWUsWatSq7lUd6V+y6muiWcYEWJdeWZcqE0hDs3qJMcvwpyUkc5Bup0wY3BxLCRcGf/1zunlXHXqiLHvsYL spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: b2fa485d-5797-4d8b-cde0-08d5be459cae X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: b2fa485d-5797-4d8b-cde0-08d5be459cae X-MS-Exchange-CrossTenant-originalarrivaltime: 20 May 2018 11:34:13.1794 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR00MB0398 Archived-At: Subject: Re: [Ace] WGLC on draft-ietf-ace-cwt-proof-of-possession-02 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 May 2018 11:34:25 -0000 Thanks for your useful comments, Jim. Replies are inline below. -----Original Message----- From: Jim Schaad =20 Sent: Wednesday, May 9, 2018 6:51 AM To: draft-ietf-ace-cwt-proof-of-possession@ietf.org Cc: ace@ietf.org Subject: RE: [Ace] WGLC on draft-ietf-ace-cwt-proof-of-possession-02 I'll pull out the list of comments that I wrote a month ago but didn't star= t that computer up recently. 1. Are all of the authors necessary? As a chair I need to justify a count= of more than 5 to the IESG. The authors are the union of the set of authors of draft-jones-ace-cwt-proo= f-of-possession-00 and draft-ietf-ace-oauth-authz-04, which both contained = independently developed and largely parallel treatments of the CWT PoP conf= irmation subject. Ludwig was the primary author of this text in the second= , so he should definitely be retained as an editor. I'll leave it up to th= e other authors of draft-ietf-ace-oauth-authz-04 to self-identify whether t= hey materially contributed to the CWT PoP confirmation text or not. Maybe = we can delete those who don't self-identify as contributors. 2. Is the last sentence in section 1 necessary? Are you actually defining= any strings that could be case-sensitive? Sure - we can delete the text "Unless otherwise noted, all the protocol par= ameter names and values are case sensitive." It's a holdover from RFC 7800= that doesn't apply here. 3. Terminology: In the definition of Issuer please make 'its' clearer. It= is not clear whose claims are being bound. We can change "its claims" to "the claims in the CWT". 4. Terminology: I still think this is 'Presenter' is a very strange term t= o use for this definition. I would really like to see it be made something= that makes sense and then say the term is the same as this in JWT. The te= rm has a model of use with it that I do not believe can be sustained even f= or the ACE Oauth case but really not in other cases. This is the standard term for this role in the industry. For instance, Sec= tion 1.2 (Terminology) of "SAML V2.0 Holder-of-Key Assertion Profile Versio= n 1.0" http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml2-holder-o= f-key-cd-01.pdf defines "Presenter" with an equivalent meaning. Also, for this reason, this is the same terminology used for this role in R= FC 7800. It is used pervasively throughout both this document and RFC 7800= - including in the diagrams in the introduction of RFC 7800. I believe we= would be doing a disservice to readers and implementers if we were to use = a different term from that in RFC 7800 (and SAML) when the meaning is ident= ical. 5. Terminology: Recipient matches presenter, and it matches the OAuth mode= l and not a trust model world. Relying party or service provider make far more sense to me. Same response as to 4. We owe it to readers and implementers to keep the t= erminology consistent with RFC 7800 and industry practice. 6. Under what circumstances would a 'sub' claim be present and it is not t= he presenter? I can see that a holder of the key may be implicitly (or anonymously) named, but putting something in the subject field which is not= identifying the presenter is something that I would reject without a good = presentation of why in the document. Just as in https://tools.ietf.org/html/draft-ietf-secevent-token-13 (which = is in the hands of the RFC Editor), it's dependent upon the profiling speci= fication how the "sub" claim is used. In some cases the subject and/or pre= senter will be identified with some combination of "iss" and/or "sub". In = other profiles, different representations will be appropriate, such as the = use of the "subject_type" value in the RISC example in https://tools.ietf.o= rg/html/draft-ietf-secevent-token-13#section-2.1.4. Remember that in both JWT and CWT, the inclusion of *all* claims is left up= to the profile. The same is true of RFC 7800 and this spec (other than th= e use of the "cnf" claim). We shouldn't tie the hands of profiles in a way= that prevents them from using the representation of the presenter that is = most natural for their use case. 7. I would disagree with the claim that if the 'sub' claim is missing then= it would normally be the issuer. For the world of IoT, I would expect tha= t the subject would not be present because there is no need to identify the= subject to the recipient. I.e. it is an anonymous subject. I'm fine adding language saying that in some use cases, such IoT use cases,= explicit identification of the presenter may not be necessary because in s= ome cases, the recipient already implicitly has this information. And I ca= n drop the "normally" language about "iss" and instead tone it down to talk= about "in some use cases". 8. It is not clear to me that either of the sub and iss claims would norma= lly be present. They might be present but neither is needed. The subject = can be anonymous and the issuer is identified by the key used to validate t= he security on the CWT. Per my response to 7, I can replace the "normally" language with "in some u= se cases" language, so the spec isn't presuming what "normal" usage is. Th= is should be up to the profiles. 9. In section 3.1 the first two sentences appear to be contradictory. Members are used to identify the POP key. Other things than a POP key can = be used than a POP key. If they are used to identify the POP key- why woul= d they not deal with the POP key? I think that you should do a separation = and define the 'cnf' file which can hold any number of confirmation methods= and then have a section on defining some POP cnf method field holders. Good point. I can revise the text to be clear that confirmation is more ge= neral than confirmation via PoP key and that the conformation members defin= ed and registered by this spec enable confirmation using a PoP key. 10. In section 3.1 P1 - I am not sure why you have something here about co= nfirming the authenticity of the token as oppose to confirming the identity= of the presenter. Why would that type of information be placed here where= it is not useful. In SAML, there are plenty of non-PoP confirmation methods and RFC 7800 (and= this spec) was designed to enable a similar range of conformation methods = to be registered and used. For instance, SAML has an IP Address confirmati= on method. (Yes, I understand that's of dubious value, but it's an easy to= understand example.) I can update the language to say that PoP keys confi= rm the identity of the presenter, whereas other confirmation methods may co= nfirm other properties. 11. In section 3.1 P2 - We are back to the same argument that existed for = a CWT in general. Not knowing that a CWT is for a specific application mea= ns that it can be used in a different application and checking that the fir= st application would have done is ignored by the second one because it will= ignore fields it does not understand. This language is parallel to the language about understanding claims in JWT= , CWT, and RFC 7800, by design. In particular, the "MUST ignore not unders= tood claims" language is the key to non-breaking extensibility. Profiles c= an and will specify claim sets and validation rules for particular CWTs, ju= st as they do for particular JWTs. See the ID Token requirements in http:/= /openid.net/specs/openid-connect-core-1_0.html#IDToken and the correspondin= g validation rules in http://openid.net/specs/openid-connect-core-1_0.html#= IDTokenValidation for an example of such a profile for JWTs. Profiles for = CWT and CWT PoP will be similarly specific. 12. I am unclear why there should be a restriction on the number of POP key= s that can be in a 'cnf' object. If there are multiple keys, then any or a= ll of them are of equal value in doing the confirmation. Just like there c= an be multiple confirmation methods and an application could choose to use = any one of them. You're right that this could have been specified in a way that allows multi= ple keys in a "cnf" object but it is intended to simplify things for implem= enters and increase interoperability to by having just one. Also, note tha= t if multiple kinds of conformation keys are desired by a profile, the seco= nd sentence of paragraph 4 of https://tools.ietf.org/html/draft-ietf-ace-cw= t-proof-of-possession-02#section-3.1 already recommends how to achieve this= . 13. Not sure which section this belongs in, but the use of an COSE_Encrypt= 0 would be one way to combat tracking of identities based on the key value = being used. Different encrypted values could be sent to different servers = and they would not necessarily know about use w/o internal collusion betwee= n them. Similar effect by using an encrypted CWT. Potentially requires us= e of TLS1.3 to protect the RPKs. YMMV I'll try to add something along these lines to the privacy considerations s= ection. 14. I have real problems w/ the use of a KID for POP identification. It m= ay identify the wrong key or, if used for granting access, may have problem= s w/ identity collisions. These need to be spelt out someplace to help peo= ple tracking down questions of why can't I verify w/ this CWT, I know it's = right. The Key ID is a hint to help identify which PoP key to use. Yes, if a Key = ID is sent that doesn't correspond to the right PoP key, failures may occur= . I view that as usage bug - not a protocol problem. If keys aren't consi= stently known and identified by both parties, there are lots of things that= can go wrong, and this is only one such instance. That said, I can try to= say something about the need for keys to be consistently and known by both= parties, if you think that would help. 15. The content of 'kid' is application specific. Where is an application= going to define this such that it will work more generally. The applicati= on in the case of the ACE working group boils down to the world (minus a fe= w things). Sure - its content is application-specific, but per my answer to 14, what m= atters is that keys are consistently identified between both participants. = Provided that's true, then it really doesn't matter whether a Key ID value= is (a binary encoding of) "Jim's Key" or (a binary encoding of) "e762dcc3-= bc8a-4125-844f-e5578695c834". 16. section 4 - Are audience restrictions not done in CWT? https://tools.ietf.org/html/rfc8392#section-3.1.3 defines how to do audienc= e restriction for CWTs. I can change the JWT reference to the equivalent C= WT reference. 17. section 4 - this implies that POP cannot be replayed via asymmetric key= s. Why would this be the case? I'm a little confused by this comment because paragraph 4 explicitly states= that "Proof of possession via encrypted symmetric secrets is subject to re= play attacks". So yes, they can be replayed, so I don't understand what yo= u're commenting about or what additional explanation you'd like to see. 18. section 4 - prior to an issuer being able to create a CWT for a client = w/ an asymmetric key in it, the issuer MUST go through a POP protocol of so= me type to validate that the client has possession of the key. Issuers may= want to repeat this validation at some interval for re-verification. They should also keep track of the keys and flag where the same public key = appears more than one for review. I assume that you're asking that something along the lines of the above be = added to the Security Considerations? I'd be fine doing that. 19. Update IANA considerations w/ input from IANA and the CWT document. Will do. 20. Are keys big enough that it should be considered to move kid to the 2 = byte range of identifiers? I don't see any need to do this because the "cnf" identifier space is disti= nct from the CWT identifier space. I really can't envision a scenario in w= hich there will ever be 64 "cnf" values (32 single-byte positive integers a= nd 32 single-byte negative integers). It's a fair question, but as it see = it, doing so would just add a byte for no practical reason. 21. Section 6.2.2 - the value type is not an array for COSE_Encrypt or COSE= _Encyrpt0, these are the values. As written I could put in an array which is not one of those two structures and be valid. Ditto for COSE_Key= , although w/ slightly less justification. https://tools.ietf.org/html/rfc8152#section-5.2 says that "The COSE_Encrypt= 0 structure is a CBOR array." But I can make the language more precise by = saying that the value is a COSE_Encrypt or COSE_Encrypt0 value with optiona= l matching CBOR tags. Jim Thanks again for your thorough review! -- Mike From nobody Sun May 20 17:35:57 2018 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A399712E035; Sun, 20 May 2018 17:35:56 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GnYDzSnb29LM; Sun, 20 May 2018 17:35:53 -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 5243912DFDB; Sun, 20 May 2018 17:35:53 -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.1347.2; Sun, 20 May 2018 17:33:05 -0700 From: Jim Schaad To: 'Mike Jones' , CC: References: <359EC4B99E040048A7131E0F4E113AFC014C3AA67D@marchand> <00ad01d3e751$5c1f03a0$145d0ae0$@augustcellars.com> In-Reply-To: Date: Sun, 20 May 2018 17:35:45 -0700 Message-ID: <012a01d3f09b$a9eec130$fdcc4390$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQG8BN2SgGQI0s8TRVm0gk+2+YL3PwIWpoMfAVEkdyGkTXljUA== X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Ace] WGLC on draft-ietf-ace-cwt-proof-of-possession-02 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 May 2018 00:35:57 -0000 I have removed items where the proposed solution is probably sufficient. > -----Original Message----- > From: Mike Jones > Sent: Sunday, May 20, 2018 4:34 AM > To: Jim Schaad ; draft-ietf-ace-cwt-proof-of- > possession@ietf.org > Cc: ace@ietf.org > Subject: RE: [Ace] WGLC on draft-ietf-ace-cwt-proof-of-possession-02 > > Thanks for your useful comments, Jim. Replies are inline below. > > -----Original Message----- > From: Jim Schaad > Sent: Wednesday, May 9, 2018 6:51 AM > To: draft-ietf-ace-cwt-proof-of-possession@ietf.org > Cc: ace@ietf.org > Subject: RE: [Ace] WGLC on draft-ietf-ace-cwt-proof-of-possession-02 > > I'll pull out the list of comments that I wrote a month ago but didn't start that > computer up recently. > > 1. Are all of the authors necessary? As a chair I need to justify a count of > more than 5 to the IESG. > > The authors are the union of the set of authors of draft-jones-ace-cwt- > proof-of-possession-00 and draft-ietf-ace-oauth-authz-04, which both > contained independently developed and largely parallel treatments of the > CWT PoP confirmation subject. Ludwig was the primary author of this text in > the second, so he should definitely be retained as an editor. I'll leave it up to > the other authors of draft-ietf-ace-oauth-authz-04 to self-identify whether > they materially contributed to the CWT PoP confirmation text or not. Maybe > we can delete those who don't self-identify as contributors. > > 4. Terminology: I still think this is 'Presenter' is a very strange term to use for > this definition. I would really like to see it be made something that makes > sense and then say the term is the same as this in JWT. The term has a > model of use with it that I do not believe can be sustained even for the ACE > Oauth case but really not in other cases. > > This is the standard term for this role in the industry. For instance, Section > 1.2 (Terminology) of "SAML V2.0 Holder-of-Key Assertion Profile Version 1.0" > http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml2-holder-of-key- > cd-01.pdf defines "Presenter" with an equivalent meaning. > > Also, for this reason, this is the same terminology used for this role in RFC > 7800. It is used pervasively throughout both this document and RFC 7800 - > including in the diagrams in the introduction of RFC 7800. I believe we would > be doing a disservice to readers and implementers if we were to use a > different term from that in RFC 7800 (and SAML) when the meaning is > identical. > > 5. Terminology: Recipient matches presenter, and it matches the OAuth > model > and not a trust model world. Relying party or service provider make far > more sense to me. > > Same response as to 4. We owe it to readers and implementers to keep the > terminology consistent with RFC 7800 and industry practice. > > 6. Under what circumstances would a 'sub' claim be present and it is not the > presenter? I can see that a holder of the key may be implicitly (or > anonymously) named, but putting something in the subject field which is not > identifying the presenter is something that I would reject without a good > presentation of why in the document. > > Just as in https://tools.ietf.org/html/draft-ietf-secevent-token-13 (which is > in the hands of the RFC Editor), it's dependent upon the profiling > specification how the "sub" claim is used. In some cases the subject and/or > presenter will be identified with some combination of "iss" and/or "sub". In > other profiles, different representations will be appropriate, such as the use > of the "subject_type" value in the RISC example in > https://tools.ietf.org/html/draft-ietf-secevent-token-13#section-2.1.4. > > Remember that in both JWT and CWT, the inclusion of *all* claims is left up > to the profile. The same is true of RFC 7800 and this spec (other than the use > of the "cnf" claim). We shouldn't tie the hands of profiles in a way that > prevents them from using the representation of the presenter that is most > natural for their use case. I think you have done a good job of arguing my case that this is something that should be removed. If it is appropriate to a specific profile then that should be stated in that profile and not in the general document. > > 7. I would disagree with the claim that if the 'sub' claim is missing then it > would normally be the issuer. For the world of IoT, I would expect that the > subject would not be present because there is no need to identify the > subject to the recipient. I.e. it is an anonymous subject. > > I'm fine adding language saying that in some use cases, such IoT use cases, > explicit identification of the presenter may not be necessary because in > some cases, the recipient already implicitly has this information. And I can > drop the "normally" language about "iss" and instead tone it down to talk > about "in some use cases". Again - this seems like a statement that should be made in a profile and not in this document. If you have some cases where this is true then it would make sense to at least point to them because this seems to be completely unsupported as a general rule. One also has problems about why self-signed statements should not be very explicitly stated as such given that the type of trust to be placed in this may be significantly different. > > 8. It is not clear to me that either of the sub and iss claims would normally be > present. They might be present but neither is needed. The subject can be > anonymous and the issuer is identified by the key used to validate the > security on the CWT. > > Per my response to 7, I can replace the "normally" language with "in some > use cases" language, so the spec isn't presuming what "normal" usage is. > This should be up to the profiles. While that is better, it makes more sense to me to change this into text which says. If this claim is not present it means X, if it is present it means Y. Making this paragraph be two, one each for iss and sub and then describe what is being explicit and what is being implicit means that it is clear what is being done with each of these. > > 9. In section 3.1 the first two sentences appear to be contradictory. > Members are used to identify the POP key. Other things than a POP key can > be used than a POP key. If they are used to identify the POP key- why would > they not deal with the POP key? I think that you should do a separation and > define the 'cnf' file which can hold any number of confirmation methods and > then have a section on defining some POP cnf method field holders. > > Good point. I can revise the text to be clear that confirmation is more > general than confirmation via PoP key and that the conformation members > defined and registered by this spec enable confirmation using a PoP key. > > 10. In section 3.1 P1 - I am not sure why you have something here about > confirming the authenticity of the token as oppose to confirming the identity > of the presenter. Why would that type of information be placed here where > it is not useful. > > In SAML, there are plenty of non-PoP confirmation methods and RFC 7800 > (and this spec) was designed to enable a similar range of conformation > methods to be registered and used. For instance, SAML has an IP Address > confirmation method. (Yes, I understand that's of dubious value, but it's an > easy to understand example.) I can update the language to say that PoP > keys confirm the identity of the presenter, whereas other confirmation > methods may confirm other properties. So the paragraph should read something along the lines of: The "cnf" claim is used in the CWT to contain the data required to confirm that the CWT is associated to a subject. This document defines a method and set of data that allows for the confirmation to be done by a proof-of-possession key. Other documents may define other methods and the associated data members. The "cnf" claim is analogous to the SAML 2.0 SubjectConformation element where one or more different subject confirmation methods can be placed. > > 11. In section 3.1 P2 - We are back to the same argument that existed for a > CWT in general. Not knowing that a CWT is for a specific application means > that it can be used in a different application and checking that the first > application would have done is ignored by the second one because it will > ignore fields it does not understand. > > This language is parallel to the language about understanding claims in JWT, > CWT, and RFC 7800, by design. In particular, the "MUST ignore not > understood claims" language is the key to non-breaking extensibility. > Profiles can and will specify claim sets and validation rules for particular CWTs, > just as they do for particular JWTs. See the ID Token requirements in > http://openid.net/specs/openid-connect-core-1_0.html#IDToken and the > corresponding validation rules in http://openid.net/specs/openid-connect- > core-1_0.html#IDTokenValidation for an example of such a profile for JWTs. > Profiles for CWT and CWT PoP will be similarly specific. That is great if you want to use OR rules - this token can be used if A or B is true. This does not work at all if you want to use AND rules - this token can only be used if A and B are true. However that is orthogonal to the issue that I have raised. You say that any token which has a sufficient set of fields is good for my application. Not all profiles are designed so that as long as level 1 is fine and a subset of level 2 that a token can be used to authorize at level 1. > > 12. I am unclear why there should be a restriction on the number of POP keys > that can be in a 'cnf' object. If there are multiple keys, then any or all of them > are of equal value in doing the confirmation. Just like there can be multiple > confirmation methods and an application could choose to use any one of > them. > > You're right that this could have been specified in a way that allows multiple > keys in a "cnf" object but it is intended to simplify things for implementers > and increase interoperability to by having just one. Also, note that if multiple > kinds of conformation keys are desired by a profile, the second sentence of > paragraph 4 of https://tools.ietf.org/html/draft-ietf-ace-cwt-proof-of- > possession-02#section-3.1 already recommends how to achieve this. > 14. I have real problems w/ the use of a KID for POP identification. It may > identify the wrong key or, if used for granting access, may have problems w/ > identity collisions. These need to be spelt out someplace to help people > tracking down questions of why can't I verify w/ this CWT, I know it's right. > > The Key ID is a hint to help identify which PoP key to use. Yes, if a Key ID is > sent that doesn't correspond to the right PoP key, failures may occur. I view > that as usage bug - not a protocol problem. If keys aren't consistently known > and identified by both parties, there are lots of things that can go wrong, and > this is only one such instance. That said, I can try to say something about the > need for keys to be consistently and known by both parties, if you think that > would help. My problem is that if there are two different people with the same Key ID, either intentionally or unintentionally, then using the key ID to identify the key may allow the other person to masquerade as the first person. I am unworried about the instance of a failure to get a key based on a key id. That is not the problem you are proposing to address. > > 15. The content of 'kid' is application specific. Where is an application going > to define this such that it will work more generally. The application in the > case of the ACE working group boils down to the world (minus a few things). > > Sure - its content is application-specific, but per my answer to 14, what > matters is that keys are consistently identified between both participants. > Provided that's true, then it really doesn't matter whether a Key ID value is (a > binary encoding of) "Jim's Key" or (a binary encoding of) "e762dcc3-bc8a- > 4125-844f-e5578695c834". No, if the trust is CWT -> KeyID -> Key then there is a step in the middle that has not be trusted. CWT->Key is an atomic trust operation as it is cryptographically validated. > > 17. section 4 - this implies that POP cannot be replayed via asymmetric keys. > Why would this be the case? > > I'm a little confused by this comment because paragraph 4 explicitly states > that "Proof of possession via encrypted symmetric secrets is subject to > replay attacks". So yes, they can be replayed, so I don't understand what > you're commenting about or what additional explanation you'd like to see. > The conclusion that I drew from this is that - you say symmetric keys have replay attacks, but you don't say anything about asymmetric key having the same attacks so they must not. > 20. Are keys big enough that it should be considered to move kid to the 2 > byte range of identifiers? > > I don't see any need to do this because the "cnf" identifier space is distinct > from the CWT identifier space. I really can't envision a scenario in which > there will ever be 64 "cnf" values (32 single-byte positive integers and 32 > single-byte negative integers). It's a fair question, but as it see it, doing so > would just add a byte for no practical reason. I don't know that this is the correct metric to be using. A single confirmation method could register multiple keys to be used. After all POP is registering 3 > > Jim > > Thanks again for your thorough review! > > -- Mike From nobody Mon May 21 02:33:42 2018 Return-Path: X-Original-To: ace@ietf.org Delivered-To: ace@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 519B7126CC7; Mon, 21 May 2018 02:33:35 -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.80.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152689521530.22913.2698697465552528661@ietfa.amsl.com> Date: Mon, 21 May 2018 02:33:35 -0700 Archived-At: Subject: [Ace] I-D Action: draft-ietf-ace-oauth-authz-12.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 May 2018 09:33:36 -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-12.txt Pages : 68 Date : 2018-05-21 Abstract: This specification defines a framework for authentication and authorization in Internet of Things (IoT) environments called ACE- OAuth. The framework is based on a set of building blocks including OAuth 2.0 and CoAP, thus making a well-known and widely used authorization solution suitable for IoT devices. Existing specifications are used where possible, but where the constraints of IoT devices require it, extensions are added and profiles are defined. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ace-oauth-authz/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-12 https://datatracker.ietf.org/doc/html/draft-ietf-ace-oauth-authz-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-oauth-authz-12 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon May 21 02:35:32 2018 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D583A126CD8 for ; Mon, 21 May 2018 02:35:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kaXZhBYCc9cv for ; Mon, 21 May 2018 02:35:27 -0700 (PDT) Received: from smtp-out11.electric.net (smtp-out11.electric.net [185.38.181.43]) (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 36095126CC7 for ; Mon, 21 May 2018 02:35:27 -0700 (PDT) Received: from 1fKhDw-0000ek-Uz by out11a.electric.net with emc1-ok (Exim 4.90_1) (envelope-from ) id 1fKhDw-0000gB-W3; Mon, 21 May 2018 02:35:24 -0700 Received: by emcmailer; Mon, 21 May 2018 02:35:24 -0700 Received: from [194.218.146.197] (helo=sp-mail-2.sp.se) by out11a.electric.net with esmtps (TLSv1.2:ECDHE-RSA-AES128-SHA256:128) (Exim 4.90_1) (envelope-from ) id 1fKhDw-0000ek-Uz; Mon, 21 May 2018 02:35:24 -0700 Received: from [192.168.0.166] (10.116.0.226) by sp-mail-2.sp.se (10.100.0.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Mon, 21 May 2018 11:35:24 +0200 To: Jim Schaad , References: <005601d3e622$af427100$0dc75300$@augustcellars.com> <004c01d3eed1$fc118ae0$f434a0a0$@augustcellars.com> From: Ludwig Seitz Message-ID: <51059706-282f-a77d-937f-7f45c84a3986@ri.se> Date: Mon, 21 May 2018 11:35:18 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <004c01d3eed1$fc118ae0$f434a0a0$@augustcellars.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.116.0.226] X-ClientProxiedBy: sp-mail-1.sp.se (10.100.0.161) To sp-mail-2.sp.se (10.100.0.162) X-Outbound-IP: 194.218.146.197 X-Env-From: ludwig.seitz@ri.se X-Proto: esmtps X-Revdns: X-HELO: sp-mail-2.sp.se X-TLS: TLSv1.2:ECDHE-RSA-AES128-SHA256:128 X-Authenticated_ID: X-PolicySMART: 14510320 X-Virus-Status: Scanned by VirusSMART (c) X-Virus-Status: Scanned by VirusSMART (s) Archived-At: Subject: Re: [Ace] OAuth-Authz Interop X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 May 2018 09:35:30 -0000 On 2018-05-18 19:59, Jim Schaad wrote: > We are going to go with > > May 30 07:00 PDT (14:00 UTC) > > If there is anyone who has an IPv6 only client, please let me know as I will > need to get tunneling setup for my server. (An IPv6 only server is not a > problem.) > > Ludwig, we made some changes to the document at the last F2F meeting. It > would be nice to get those changes published. > Done! Please find draft -12 here: https://datatracker.ietf.org/doc/draft-ietf-ace-oauth-authz/ /Ludwig -- Ludwig Seitz, PhD Security Lab, RISE SICS Phone +46(0)70-349 92 51 From nobody Tue May 22 07:16:36 2018 Return-Path: X-Original-To: ace@ietf.org Delivered-To: ace@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E48E41270A7; Tue, 22 May 2018 07:16:33 -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: rdd@cert.org, ace-chairs@ietf.org, kaduk@mit.edu, ace@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.80.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152699859386.31334.15078592278452533067.idtracker@ietfa.amsl.com> Date: Tue, 22 May 2018 07:16:33 -0700 Archived-At: Subject: [Ace] ace - New Meeting Session Request for IETF 102 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2018 14:16:34 -0000 A new meeting session request has just been submitted by Roman Danyliw, a Chair of the ace working group. --------------------------------------------------------- Working Group Name: Authentication and Authorization for Constrained Environments Area Name: Security Area Session Requester: Roman Danyliw Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 100 Conflicts to Avoid: First Priority: saag cbor core tls lamps cfrg secdispatch ace emu dots Second Priority: quic oauth secevent tokbind t2trg lwig anima suit teep mile Third Priority: doh httpbis uta 6tisch homenet curdle People who must be present: Roman Danyliw Jim Schaad Benjamin Kaduk Resources Requested: Special Requests: A session in the first half of the week (Mon-Wed) would be preferred. --------------------------------------------------------- From nobody Wed May 23 10:40:44 2018 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E2BD12E88B for ; Wed, 23 May 2018 10:40:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o8cXYEhtM9NW for ; Wed, 23 May 2018 10:40:40 -0700 (PDT) Received: from veto.sei.cmu.edu (veto.sei.cmu.edu [147.72.252.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9927712E886 for ; Wed, 23 May 2018 10:40:40 -0700 (PDT) Received: from delp.sei.cmu.edu (delp.sei.cmu.edu [10.64.21.31]) by veto.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id w4NHeaHO023487 for ; Wed, 23 May 2018 13:40:36 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 veto.sei.cmu.edu w4NHeaHO023487 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1527097236; bh=12h77iNO21Kj/GSfiruLxCeoEg066SY7ndSX3br+YS8=; h=From:To:Subject:Date:From; b=Ul7+uCB8QTTnthMRgM01wSMVfi7ifLonGhfzd44KuAXF8pBFKQvFCTk67NERGa6pN 0sGhPSfTnpm4RJnoKMQ5ZUe4OXZx1FWeuoAgE5dhgvZ7tJCtzuLhV7+89qzCxpNMdO pdDUZUxRcPSXUGMnrqCAZtw1cr+I1IKBt6SeNO7c= Received: from CASCADE.ad.sei.cmu.edu (cascade.ad.sei.cmu.edu [10.64.28.248]) by delp.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id w4NHeWUQ021988 for ; Wed, 23 May 2018 13:40:32 -0400 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASCADE.ad.sei.cmu.edu ([10.64.28.248]) with mapi id 14.03.0399.000; Wed, 23 May 2018 13:40:31 -0400 From: Roman Danyliw To: "ace@ietf.org" Thread-Topic: WGLC feedback on draft-ietf-ace-cwt-proof-of-possession-02 Thread-Index: AdPyvMVXIklgjB6pTh+daQsL4hILIw== Date: Wed, 23 May 2018 17:40:30 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC014C3CA77A@marathon> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [Ace] WGLC feedback on draft-ietf-ace-cwt-proof-of-possession-02 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2018 17:40:43 -0000 Hello! (chair hat off) I reviewed draft-ietf-ace-cwt-proof-of-possession-02 in WGLC and have the f= ollowing feedback: (1) (Editorial) Page 3, "The value of the 'cnf' claim is a CBOR map and the= ...". Isn't it more precise to say "The _representation_ of the 'cnf' cla= im is a CBOR map ..."? (2) (Editorial) Page 3, Why is the sentence "(In some applications, the su= bject identifier ..." in parenthesis? (3) (Editorial) Page 4, Section 3.0, I read to the end of this section by w= hich point there has been discussion of "sub" or "iss". I was left wonderi= ng about how to interpret the case where both are present and none are. (4) (Editorial) Page 4, Section 3.1, Per " At most one of the "COSE_Key" an= d "Encrypted_COSE_Key" confirmation values defined below may be present= ." Defined below where specifically? I recommend citing Figure 1 explicit= ly by s/below/in Figure 1/. (5) Page 5, Typo in Section 3.2, s/diagonstic/diagnostic/ (6) (Editorial) Page 5, Section 2.3, Per "If the CWT is not encrypted, the = symmetric key MUST be encrypted as described below." Described where below= ? I recommend citing Section 3.3 by s/below/In Section 3.3/ (7) Page 6, Section 3.3, The sentence "The COSE_Key could, for instance, be= encrypted using a COSE_Encrypt0 representation using the AES-CCM-16-64-128= algorithm" seems out of place. What is this text explaining relative to t= he examples? (8) Page 7, Section 3.4, Per "The proof-of-possession key can also be ident= ified by the use of a Key ID instead of communicating the actual key, provi= ded the recipient is able to obtain the identified key using the Key ID." = How would the sender know whether the recipient can "obtain the key using t= he Key ID"? Additionally, I would recommend adding language that states th= at this retrieval process is out of scope for this draft. (9) (Editorial) Page 7, Section 3.4, Per "In this case, the issuer of a CWT= declares that the presenter possesses a particular key and that the recipi= ent can cryptographically confirm proof of possession of the key by the pr= esenter by including a "cnf" claim in the CWT whose value is a CBOR map wit= h the CBOR map containing a "kid" member identifying the key." I recommend= s/is a CBOR map with the CBOR map/is a CBOR map/ (10) Page 8, Section 4. RFC 2119 capitalizations seem more appropriate in = these sentences: (MUST) "Appropriate means *must* be used to ensure that unintended parties = do not learn private key or symmetric key values." (SHOULD) "Applications utilizing proof of possession *should* also utilize = audience restriction, as described in Section 4.1.3 of [JWT], as it provide= s different protections." (MUST) "Applications that require the proof-of-possession keys communicated= with it to be understood and processed *must* ensure that the parts of thi= s specification that they use are implemented." (11) Page 8, Section 4. Per "Applications utilizing proof of possession s= hould also utilize audience restriction, as described in Section 4.1.3 of [= JWT], as it provides different protections." I recommend s/different/addit= ional/ (12) (Editorial) Page 8, Section 4, Per=20 Applications utilizing proof of possession should also utilize audience restriction, as described in Section 4.1.3 of [JWT], as it provides different protections. Proof of possession can be used by recipients to reject messages from unauthorized senders. Audience restriction can be used by recipients to reject messages intended for different recipients. The flow of this sentence is off for me. Sentence #1 asserts the need for = audience restrictions. Sentence #3 describes the benefit of Sentence #1. = Sentence #2 interjects with something that seems unrelated to this need-ben= efit pairing. (13) Page 8, Section 4, Per "Applications that require the proof-of-possess= ion keys communicated with it to be understood and processed must ensure th= at the parts of this specification that they use are implemented." How = is this being ensured? What happens if the needed parts aren't specified? = Also, it seems like the "must" here should be "MUST". (14) (Editorial) Page 8, Section 4, Per "Replay can also be avoided if a s= ub-key is derived from a shared secret that is specific to the instance of = the PoP demonstration." PoP is spelled out everywhere else in this draft b= ut here. Yes, the acronym is defined, but for readability, I recommend aga= inst it using it and consistently spelling it out here too. (15) Page 8, Section 4, Per "Special care has to be applied when carrying s= ymmetric keys inside the CWT since those not only require integrity protect= ion but also confidentiality protection." What is that care? (16) Page 8, Section 4. Per "Proof-of-possession signatures made with keys= not meeting the application's trust criteria MUST NOT not be relied upon."= , remove the double "not" by s/MUST NOT not/MUST NOT/. Roman From nobody Wed May 23 12:54:54 2018 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6761412D778; Wed, 23 May 2018 12:54:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 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, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tNftdX5eoDiO; Wed, 23 May 2018 12:54:50 -0700 (PDT) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20058.outbound.protection.outlook.com [40.107.2.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4BDB127978; Wed, 23 May 2018 12:54:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=MEG32NFtC9Uegio9UlvWFtOYsZtD++xUUS5K9Vvbz+I=; b=Xo6uH7nPN2t+IJ8C5k5osTt9Z3mD+eoJPtCQSP45XOsFGVNeircQVdwvBtbPEb5ILFlcmS/L3cEAsozWahiERKBEsuuMyn+Q6MOE0Ef3xDb1/OGlkRgpuACXt2+mP80cfMooHFFAfVG7NoOUFP9cINT++x7ydLDB8mHSAqODslE= Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB2064.eurprd08.prod.outlook.com (10.173.74.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.776.11; Wed, 23 May 2018 19:54:46 +0000 Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::8a:25f5:af5d:4db4]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::8a:25f5:af5d:4db4%17]) with mapi id 15.20.0776.015; Wed, 23 May 2018 19:54:46 +0000 From: Hannes Tschofenig To: Jim Schaad , "draft-ietf-ace-cwt-proof-of-possession@ietf.org" CC: "ace@ietf.org" Thread-Topic: [Ace] WGLC on draft-ietf-ace-cwt-proof-of-possession-02 Thread-Index: AdPnGgXMYVrDIRKQRwyiq8BLgNVR0wAN1QSAApWYoLA= Date: Wed, 23 May 2018 19:54:46 +0000 Message-ID: References: <359EC4B99E040048A7131E0F4E113AFC014C3AA67D@marchand> <00ad01d3e751$5c1f03a0$145d0ae0$@augustcellars.com> In-Reply-To: <00ad01d3e751$5c1f03a0$145d0ae0$@augustcellars.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=Hannes.Tschofenig@arm.com; x-originating-ip: [195.149.218.8] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0801MB2064; 7:6yxKk/6mmGK52WTJEw/L367ZH7o2zoTEHb/BNK7MCeHNjc5U5KUMrsowJeMYHE8ownXrLC5HJn1MtZrumJENuXyv5C+bABY302mTWw8NG7reJnTMOGOlEZKZS5BjoOxsvMS/XdLiwwXmOA2JLNdnE2cZyetM2DxKkP5+vkPdVWXXq2VhR/EuzRlsk3CfQLtLFfUPadK+y6Uez/tHvpj4GN0A5vUPV8coDjM1ECSgR8tjcNy52DEKvr8bFgJNq2Up x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB2064; x-ms-traffictypediagnostic: VI1PR0801MB2064: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3231254)(944501410)(52105095)(93006095)(93001095)(10201501046)(3002001)(6055026)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123560045)(20161123564045)(20161123558120)(6072148)(201708071742011)(7699016); SRVR:VI1PR0801MB2064; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0801MB2064; x-forefront-prvs: 06818431B9 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(39380400002)(366004)(396003)(346002)(376002)(40434004)(13464003)(51444003)(199004)(189003)(81166006)(81156014)(4326008)(8936002)(102836004)(5660300001)(966005)(3280700002)(6436002)(316002)(55016002)(6506007)(110136005)(9686003)(14454004)(186003)(53546011)(72206003)(26005)(561944003)(74316002)(8676002)(66066001)(33656002)(105586002)(3660700001)(106356001)(2906002)(229853002)(6306002)(68736007)(6116002)(6246003)(478600001)(3846002)(7696005)(476003)(7736002)(11346002)(53936002)(2900100001)(59450400001)(25786009)(99286004)(86362001)(446003)(76176011)(5890100001)(5250100002)(97736004)(305945005)(2501003)(486006); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB2064; H:VI1PR0801MB2112.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: xebrEgCBx+LxknVelUNCoyQTuvzop5KM7HauozCJcTCiGMOacGJCGbIPUrTpc8WVjkTcczde+23dYbcl64Ed5BkThCgUbvNE2UAc6bU5che0bcCACJadCIhfGkn1IHmNgfEInPvkU3CbGhw7uBf8oCKB17j6iyEZXzL0F1meInSK4x+J02yiZVnkDOaMa12B spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 20e592ee-f9e1-48eb-a30e-08d5c0e70926 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: 20e592ee-f9e1-48eb-a30e-08d5c0e70926 X-MS-Exchange-CrossTenant-originalarrivaltime: 23 May 2018 19:54:46.5204 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB2064 Archived-At: Subject: Re: [Ace] WGLC on draft-ietf-ace-cwt-proof-of-possession-02 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2018 19:54:54 -0000 Hi Jim, A few remarks below. -----Original Message----- From: Jim Schaad [mailto:ietf@augustcellars.com] Sent: 09 May 2018 05:51 To: draft-ietf-ace-cwt-proof-of-possession@ietf.org Cc: ace@ietf.org Subject: RE: [Ace] WGLC on draft-ietf-ace-cwt-proof-of-possession-02 I'll pull out the list of comments that I wrote a month ago but didn't star= t that computer up recently. 1. Are all of the authors necessary? As a chair I need to justify a count= of more than 5 to the IESG. [Hannes] As mentioned by Mike already, this was the result of a draft merge= r. The text initially came from an OAuth document (since this work had its = history in the OAuth WG). 2. Is the last sentence in section 1 necessary? Are you actually defining= any strings that could be case-sensitive? [Hannes] I think we could get rid of that sentence. 3. Terminology: In the definition of Issuer please make 'its' clearer. It= is not clear whose claims are being bound. [Hannes] How about: Issuer Party that creates the CWT and binds the claims to the proof-of- possession key. 4. Terminology: I still think this is 'Presenter' is a very strange term t= o use for this definition. I would really like to see it be made something= that makes sense and then say the term is the same as this in JWT. The te= rm has a model of use with it that I do not believe can be sustained even f= or the ACE Oauth case but really not in other cases. [Hannes] It is a strange term but we used it also in the OAuth JWT PoP docu= ment and hence it wouldn't make sense to change it now. 5. Terminology: Recipient matches presenter, and it matches the OAuth mode= l and not a trust model world. Relying party or service provider make far more sense to me. [Hannes] Same comment as above. I prefer to be in alignment with the OAuth = work here. I am wondering whether we should also copy the figures from Sect= ion 1 of https://tools.ietf.org/html/rfc7800 to make the architecture clear= er. 6. Under what circumstances would a 'sub' claim be present and it is not t= he presenter? I can see that a holder of the key may be implicitly (or anonymously) named, but putting something in the subject field which is not= identifying the presenter is something that I would reject without a good = presentation of why in the document. [Hannes] Mike provided his perspective on this issue already. CWT is simila= r to JWT a somewhat flexible building block. What claims should, must or ma= y be included in a given deployment depends a bit on the use case. Not incl= uding the subject claim may be useful for privacy purposes, for example. In= other cases you definitely want to convey that information. 7. I would disagree with the claim that if the 'sub' claim is missing then= it would normally be the issuer. For the world of IoT, I would expect tha= t the subject would not be present because there is no need to identify the= subject to the recipient. I.e. it is an anonymous subject. [Hannes] I am not sure that this is always the case in an IoT deployment. F= or example, imagine if a technician accesses some industrial device then I = want to have the information about the person accessing those devices in my= audit trail. 8. It is not clear to me that either of the sub and iss claims would norma= lly be present. They might be present but neither is needed. The subject = can be anonymous and the issuer is identified by the key used to validate t= he security on the CWT. [Hannes] In many deployments they may well not be present. That's completel= y fine. Fewer claims can sometimes be better. 9. In section 3.1 the first two sentences appear to be contradictory. Members are used to identify the POP key. Other things than a POP key can = be used than a POP key. If they are used to identify the POP key- why woul= d they not deal with the POP key? I think that you should do a separation = and define the 'cnf' file which can hold any number of confirmation methods= and then have a section on defining some POP cnf method field holders. [Hannes] How does this sound: Section 3.1. Confirmation Claim FROM: The "cnf" claim is used in the JWT to contain members used to identify the proof-of-possession key. Other members of the "cnf" object may be defined because a proof-of-possession key may not be the only means of confirming the authenticity of the token. This is analogous to the SAML 2.0 [OASIS.saml-core-2.0-os] SubjectConfirmation element in which a number of different subject confirmation methods can be included (including proof-of-possession key information). TO: The "cnf" claim in the JWT is used to carry confirmation methods, some of them use proof-of-possession keys while others do not. This design is analogous to the SAML 2.0 [OASIS.saml-core-2.0-os] SubjectConfirmation element in which a number of different subject confirmation methods can be included (including proof-of-possession key information). 10. In section 3.1 P1 - I am not sure why you have something here about co= nfirming the authenticity of the token as oppose to confirming the identity= of the presenter. Why would that type of information be placed here where= it is not useful. [Hannes] I believe this part would be clarified with my wording change to S= ection 3.1 as proposed in #9. 11. In section 3.1 P2 - We are back to the same argument that existed for = a CWT in general. Not knowing that a CWT is for a specific application mea= ns that it can be used in a different application and checking that the fir= st application would have done is ignored by the second one because it will= ignore fields it does not understand. [Hannes] Mike provided a detailed response to this item already. 12. I am unclear why there should be a restriction on the number of POP key= s that can be in a 'cnf' object. If there are multiple keys, then any or a= ll of them are of equal value in doing the confirmation. Just like there c= an be multiple confirmation methods and an application could choose to use = any one of them. [Hannes] I believe we should not place such a restriction in there. A profi= le should place restrictions on the number of allowed "cnf" claims there. C= hanging the names of the claims, as a proposed alternative to get around th= is limit, appears a bit problematic since we have to register them in the I= ANA registry. Hence, my proposal is to change the text FROM: The "cnf" claim value MUST represent only a single proof-of- possession key; thus, at most one of the "jwk", "jwe", and "jku" (JWK Set URL) confirmation values defined below may be present. Note that if an application needs to represent multiple proof-of-possession keys in the same JWT, one way for it to achieve this is to use other claim names, in addition to "cnf", to hold the additional proof-of- possession key information. TO: The "cnf" claim value may contain one or multiple proof-of- possession keys. Hence, more than one "jwk", "jwe", and/or "jku" (JWK Set URL) confirmation values may be present in a CWT. A profile may im= pose further restrictions on the number of PoP keys that are present and also whether all or a only a subset of them needs to be utilized by in a given application domain. ~~~snip ~~~ I will respond to the other questions in a second email; ran out of time. Ciao Hannes IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. From nobody Thu May 24 07:16:03 2018 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2A6812426E; Thu, 24 May 2018 07:16:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 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, T_DKIMWL_WL_MED=-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=armh.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pnlBiLjJx7dK; Thu, 24 May 2018 07:15:59 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0077.outbound.protection.outlook.com [104.47.2.77]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60B051200C5; Thu, 24 May 2018 07:15:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=rqWVpeRVvWIuhUTImDZClMQ+iYCquxvfYbJU/YnCfAQ=; b=gMBh1bQXdNcu3dlnMP+uwmfemlZBB9V6zySwW21nQCJUE5kDJHSywsEaUIns+poaLJb/lMdlqYDUHAwzyvvMHeJuOnLpPvacJoT5S+PageaANyAPkRJodGWKHjtMDOzSSl6SdccJI1iQGI7TM/Yh0kXehzXK+RY2zU89utGws7Q= Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB1310.eurprd08.prod.outlook.com (10.167.197.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.776.11; Thu, 24 May 2018 14:15:54 +0000 Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::8a:25f5:af5d:4db4]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::8a:25f5:af5d:4db4%17]) with mapi id 15.20.0776.015; Thu, 24 May 2018 14:15:54 +0000 From: Hannes Tschofenig To: Carsten Bormann CC: "ace@ietf.org" , core Thread-Topic: [Ace] Early media-type registration for EST over CoAP Thread-Index: AdPsKhcQ9FbwjekBT1SYYUyoYtG38gAB1S+AAAdDwHAALHlyAAAAGtIAAZoVoYA= Date: Thu, 24 May 2018 14:15:54 +0000 Message-ID: References: <0158C0A6-C8D5-4F19-9C12-23BDC8A7768A@tzi.org> <8976A481-6467-4DAD-A5ED-9AE05E9CC62D@tzi.org> In-Reply-To: <8976A481-6467-4DAD-A5ED-9AE05E9CC62D@tzi.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [195.149.218.8] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0801MB1310; 7:h9NkQNMpfjPDsC3o24SFUl82E3piT7LozTQNJYBQFzTPTuz1ItbpCo375z4/R0aPahcelrIbPaMzlfeumD8YRXjqSTXzhFAfq2jVFXBEUT+HqX64lkh2FaEnF3w7JLaoSnT88b/Z3CZ/Z4LwS7NTz94eJ/q7wxIsXdciAzSjhNV1LKwva/kSPi3E9en/FiMwxm4IOtzp3Zwis8a32RHiqiRb+8vKpBk9/YHy6XAsWLZ4278kkmW/UgJ5h4gh7tVG x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB1310; x-ms-traffictypediagnostic: VI1PR0801MB1310: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(180628864354917)(21748063052155); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3231254)(944501410)(52105095)(93006095)(93001095)(3002001)(10201501046)(6055026)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123560045)(20161123564045)(20161123562045)(6072148)(201708071742011)(7699016); SRVR:VI1PR0801MB1310; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0801MB1310; x-forefront-prvs: 0682FC00E8 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(39860400002)(396003)(39380400002)(346002)(376002)(13464003)(40434004)(199004)(57704003)(189003)(53754006)(5890100001)(3280700002)(99286004)(6116002)(105586002)(53936002)(8936002)(72206003)(76176011)(33656002)(6506007)(53546011)(7736002)(3660700001)(7696005)(59450400001)(2906002)(316002)(8676002)(81156014)(14454004)(229853002)(93886005)(54906003)(25786009)(55016002)(97736004)(236005)(5660300001)(106356001)(790700001)(3846002)(6306002)(6436002)(81166006)(54896002)(9686003)(446003)(486006)(66066001)(476003)(11346002)(86362001)(478600001)(6246003)(6916009)(4326008)(102836004)(2900100001)(5250100002)(68736007)(186003)(26005)(74316002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB1310; H:VI1PR0801MB2112.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:3; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: tOvngmOWvhy+IQ31aTh5uSso1tosEttGEs0xycsPbxtTfiMwmpdQQEB1S4RwyONcKLaXg+74pLhTDqWVTck8eTyfSXb8ioD+bK9bj0BkwX1sqSpP5uWH4cPJyw1kiVxq4jWqYwQA2AWGsgMF3LleU+yXe6BGfonInxuo1Jg3pt3VVWvGJAYEilxHfM6Nfv7w spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_VI1PR0801MB21122EB265DF70E45C26BC80FA6A0VI1PR0801MB2112_" MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 4d533754-66c2-4d1a-35bf-08d5c180dc8d X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4d533754-66c2-4d1a-35bf-08d5c180dc8d X-MS-Exchange-CrossTenant-originalarrivaltime: 24 May 2018 14:15:54.1759 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1310 Archived-At: Subject: Re: [Ace] Early media-type registration for EST over CoAP X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2018 14:16:02 -0000 --_000_VI1PR0801MB21122EB265DF70E45C26BC80FA6A0VI1PR0801MB2112_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgYWxsLA0KDQpUcnlpbmcgdG8gZmluYWxpemUgdGhpcyBkaXNjdXNzaW9uOiBDb3VsZCB3ZSBk byBhbiBlYXJseSByZWdpc3RyeSBvZiB0aGUgQ29udGVudC1Gb3JtYXQgbnVtYmVycz8NCg0KRnJv bSB0aGUgZGlzY3Vzc2lvbiBzbyBmYXIgSSBiZWxpZXZlIHdlIGNvbmNsdWRlZCB0aGF0IHRoZSBj aGFyc2V0IGlzIHV0Zi04IGFuZCB0aGF0IHRoZXJlIGFyZSBubyBwYXJhbWV0ZXJzLiBJcyB0aGF0 IGNvcnJlY3Q/DQoNCkNpYW8NCkhhbm5lcw0KDQpGcm9tOiBDYXJzdGVuIEJvcm1hbm4gW21haWx0 bzpjYWJvQHR6aS5vcmddDQpTZW50OiAxNiBNYXkgMjAxOCAxMjozMA0KVG86IEhhbm5lcyBUc2No b2ZlbmlnDQpDYzogYWNlQGlldGYub3JnOyBjb3JlDQpTdWJqZWN0OiBSZTogW0FjZV0gRWFybHkg bWVkaWEtdHlwZSByZWdpc3RyYXRpb24gZm9yIEVTVCBvdmVyIENvQVANCg0KRm9yZ290IHRvIGFk ZCBhbm90aGVyIGV4YW1wbGU6IHRoZSBjb250ZW50LWZvcm1hdCBudW1iZXJzIGZvciBDT1NFIGhh dmUgcGFyYW1ldGVycy4NClNlbnQgZnJvbSBtb2JpbGUNCg0KT24gMTYuIE1heSAyMDE4LCBhdCAx MjoyNiwgQ2Fyc3RlbiBCb3JtYW5uIDxjYWJvQHR6aS5vcmc8bWFpbHRvOmNhYm9AdHppLm9yZz4+ IHdyb3RlOg0KSSB3YXMgdGhpbmtpbmcgYWJvdXQgbWVkaWEgdHlwZSBwYXJhbWV0ZXJzIHN1Y2gg YXMgY2hhcnNldD0idXRmLTgiLiBUaGUgUlQgdmFsdWUgbmVlZCB0byBiZSByZWdpc3RlcmVkIHNl cGFyYXRlbHksIGJ1dCB3ZSBjYW4gYmUgYSBiaXQgbGF6eSBhYm91dCB0aGF0Lg0KU2VudCBmcm9t IG1vYmlsZQ0KDQpPbiAxNi4gTWF5IDIwMTgsIGF0IDEyOjE1LCBIYW5uZXMgVHNjaG9mZW5pZyA8 SGFubmVzLlRzY2hvZmVuaWdAYXJtLmNvbTxtYWlsdG86SGFubmVzLlRzY2hvZmVuaWdAYXJtLmNv bT4+IHdyb3RlOg0KSGkgQ2Fyc3RlbiwNCg0KWWVzLCBJIGFtIHRhbGtpbmcgYWJvdXQgdGhlIENv bnRlbnQtRm9ybWF0IG51bWJlcnMgZm9yIHRoZW0uDQpXb3VsZCBydD0iYWNlLmVzdCIgYmUgdGhl IHBhcmFtZXRlciB5b3UgYXJlIHRhbGtpbmcgYWJvdXQ/DQoNCkNpYW8NCkhhbm5lcw0KDQotLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogQ2Fyc3RlbiBCb3JtYW5uIFttYWlsdG86Y2Fi b0B0emkub3JnXQ0KU2VudDogMTUgTWF5IDIwMTggMTE6NDUNClRvOiBIYW5uZXMgVHNjaG9mZW5p Zw0KQ2M6IGFjZUBpZXRmLm9yZzxtYWlsdG86YWNlQGlldGYub3JnPjsgY29yZQ0KU3ViamVjdDog UmU6IFtBY2VdIEVhcmx5IG1lZGlhLXR5cGUgcmVnaXN0cmF0aW9uIGZvciBFU1Qgb3ZlciBDb0FQ DQoNCk9uIE1heSAxNSwgMjAxOCwgYXQgMTA6NTYsIEhhbm5lcyBUc2Nob2ZlbmlnIDxIYW5uZXMu VHNjaG9mZW5pZ0Bhcm0uY29tPG1haWx0bzpIYW5uZXMuVHNjaG9mZW5pZ0Bhcm0uY29tPj4gd3Jv dGU6DQoNCg0KSSBhbSBjdXJpb3VzIHdoZXRoZXIgaXQgd291bGQgYmUgcG9zc2libGUgdG8gYXNr IGZvciBlYXJseSBtZWRpYS10eXBlIHJlZ2lzdHJhdGlvbiBvZiBhdCBsZWFzdCB0aGVzZSB0d28g dHlwZXM6DQotIGFwcGxpY2F0aW9uL3BrY3M3LW1pbWUNCi0gYXBwbGljYXRpb24vcGtjczEwDQoN ClRoZXJlIGFscmVhZHkgYXJlIHJlZ2lzdGVyZWQuDQoNCkkgdGhpbmsgeW91IGFyZSB0YWxraW5n IGFib3V0IGdldHRpbmcgQ29udGVudC1Gb3JtYXQgbnVtYmVycyBmb3IgdGhlc2U/DQpEbyB3ZSBu ZWVkIGFueSBwYXJhbWV0ZXJzIG9yIGNvbnRlbnQtY29kaW5ncyB3aXRoIHRoYXQ/DQoNCkdyw7zD n2UsIENhcnN0ZW4NCg0KSU1QT1JUQU5UIE5PVElDRTogVGhlIGNvbnRlbnRzIG9mIHRoaXMgZW1h aWwgYW5kIGFueSBhdHRhY2htZW50cyBhcmUgY29uZmlkZW50aWFsIGFuZCBtYXkgYWxzbyBiZSBw cml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2Ug bm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIGRvIG5vdCBkaXNjbG9zZSB0aGUgY29u dGVudHMgdG8gYW55IG90aGVyIHBlcnNvbiwgdXNlIGl0IGZvciBhbnkgcHVycG9zZSwgb3Igc3Rv cmUgb3IgY29weSB0aGUgaW5mb3JtYXRpb24gaW4gYW55IG1lZGl1bS4gVGhhbmsgeW91Lg0KDQpJ TVBPUlRBTlQgTk9USUNFOiBUaGUgY29udGVudHMgb2YgdGhpcyBlbWFpbCBhbmQgYW55IGF0dGFj aG1lbnRzIGFyZSBjb25maWRlbnRpYWwgYW5kIG1heSBhbHNvIGJlIHByaXZpbGVnZWQuIElmIHlv dSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRl ciBpbW1lZGlhdGVseSBhbmQgZG8gbm90IGRpc2Nsb3NlIHRoZSBjb250ZW50cyB0byBhbnkgb3Ro ZXIgcGVyc29uLCB1c2UgaXQgZm9yIGFueSBwdXJwb3NlLCBvciBzdG9yZSBvciBjb3B5IHRoZSBp bmZvcm1hdGlvbiBpbiBhbnkgbWVkaXVtLiBUaGFuayB5b3UuDQo= --_000_VI1PR0801MB21122EB265DF70E45C26BC80FA6A0VI1PR0801MB2112_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0 YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt c2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJl cGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3 RDt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0 IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9v biBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0KLk1zb0NocERl ZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9 DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcy LjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29y ZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZd LS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+ DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3ht bD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLUdCIiBsaW5rPSJibHVlIiB2 bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGkgYWxs LA0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj5UcnlpbmcgdG8gZmluYWxpemUgdGhpcyBkaXNjdXNzaW9uOiBDb3VsZCB3 ZSBkbyBhbiBlYXJseSByZWdpc3RyeSBvZiB0aGUgQ29udGVudC1Gb3JtYXQgbnVtYmVycz88L3Nw YW4+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5Gcm9tIHRoZSBkaXNjdXNzaW9uIHNvIGZhciBJIGJlbGlldmUgd2UgY29uY2x1ZGVkIHRoYXQg dGhlIGNoYXJzZXQgaXMgdXRmLTggYW5kIHRoYXQgdGhlcmUgYXJlIG5vIHBhcmFtZXRlcnMuIElz IHRoYXQgY29ycmVjdD8NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Q2lhbzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5IYW5uZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6 c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ IENhcnN0ZW4gQm9ybWFubiBbbWFpbHRvOmNhYm9AdHppLm9yZ10NCjxicj4NCjxiPlNlbnQ6PC9i PiAxNiBNYXkgMjAxOCAxMjozMDxicj4NCjxiPlRvOjwvYj4gSGFubmVzIFRzY2hvZmVuaWc8YnI+ DQo8Yj5DYzo8L2I+IGFjZUBpZXRmLm9yZzsgY29yZTxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTog W0FjZV0gRWFybHkgbWVkaWEtdHlwZSByZWdpc3RyYXRpb24gZm9yIEVTVCBvdmVyIENvQVA8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWJvdHRvbToxMi4wcHQiPkZvcmdvdCB0byBhZGQgYW5vdGhlciBleGFtcGxlOiB0aGUgY29udGVu dC1mb3JtYXQgbnVtYmVycyBmb3IgQ09TRSBoYXZlIHBhcmFtZXRlcnMuJm5ic3A7PG86cD48L286 cD48L3A+DQo8ZGl2IGlkPSJBcHBsZU1haWxTaWduYXR1cmUiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+U2VudCBmcm9tJm5ic3A7PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMy4wcHQiPm1vYmlsZTwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KT24gMTYuIE1heSAyMDE4LCBhdCAx MjoyNiwgQ2Fyc3RlbiBCb3JtYW5uICZsdDs8YSBocmVmPSJtYWlsdG86Y2Fib0B0emkub3JnIj5j YWJvQHR6aS5vcmc8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2Nr cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5JIHdh cyB0aGlua2luZyBhYm91dCBtZWRpYSB0eXBlIHBhcmFtZXRlcnMgc3VjaCBhcyBjaGFyc2V0PSZx dW90O3V0Zi04JnF1b3Q7LiBUaGUgUlQgdmFsdWUgbmVlZCB0byBiZSByZWdpc3RlcmVkIHNlcGFy YXRlbHksIGJ1dCB3ZSBjYW4gYmUgYSBiaXQgbGF6eSBhYm91dCB0aGF0LiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPGRpdiBpZD0iQXBwbGVNYWlsU2lnbmF0dXJlIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPlNlbnQgZnJvbSZuYnNwOzxzcGFuIHN0eWxlPSJmb250LXNpemU6MTMuMHB0Ij5tb2JpbGU8 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCk9uIDE2LiBNYXkgMjAxOCwgYXQg MTI6MTUsIEhhbm5lcyBUc2Nob2ZlbmlnICZsdDs8YSBocmVmPSJtYWlsdG86SGFubmVzLlRzY2hv ZmVuaWdAYXJtLmNvbSI+SGFubmVzLlRzY2hvZmVuaWdAYXJtLmNvbTwvYT4mZ3Q7IHdyb3RlOjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBD YXJzdGVuLDxicj4NCjxicj4NClllcywgSSBhbSB0YWxraW5nIGFib3V0IHRoZSBDb250ZW50LUZv cm1hdCBudW1iZXJzIGZvciB0aGVtLjxicj4NCldvdWxkIHJ0PSZxdW90O2FjZS5lc3QmcXVvdDsg YmUgdGhlIHBhcmFtZXRlciB5b3UgYXJlIHRhbGtpbmcgYWJvdXQ/PGJyPg0KPGJyPg0KQ2lhbzxi cj4NCkhhbm5lczxicj4NCjxicj4NCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KRnJv bTogQ2Fyc3RlbiBCb3JtYW5uIFs8YSBocmVmPSJtYWlsdG86Y2Fib0B0emkub3JnIj5tYWlsdG86 Y2Fib0B0emkub3JnPC9hPl08YnI+DQpTZW50OiAxNSBNYXkgMjAxOCAxMTo0NTxicj4NClRvOiBI YW5uZXMgVHNjaG9mZW5pZzxicj4NCkNjOiA8YSBocmVmPSJtYWlsdG86YWNlQGlldGYub3JnIj5h Y2VAaWV0Zi5vcmc8L2E+OyBjb3JlPGJyPg0KU3ViamVjdDogUmU6IFtBY2VdIEVhcmx5IG1lZGlh LXR5cGUgcmVnaXN0cmF0aW9uIGZvciBFU1Qgb3ZlciBDb0FQPGJyPg0KPGJyPg0KT24gTWF5IDE1 LCAyMDE4LCBhdCAxMDo1NiwgSGFubmVzIFRzY2hvZmVuaWcgJmx0OzxhIGhyZWY9Im1haWx0bzpI YW5uZXMuVHNjaG9mZW5pZ0Bhcm0uY29tIj5IYW5uZXMuVHNjaG9mZW5pZ0Bhcm0uY29tPC9hPiZn dDsgd3JvdGU6PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBhbSBjdXJp b3VzIHdoZXRoZXIgaXQgd291bGQgYmUgcG9zc2libGUgdG8gYXNrIGZvciBlYXJseSBtZWRpYS10 eXBlIHJlZ2lzdHJhdGlvbiBvZiBhdCBsZWFzdCB0aGVzZSB0d28gdHlwZXM6PG86cD48L286cD48 L3A+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0gYXBwbGljYXRpb24v cGtjczctbWltZTxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4tIGFwcGxpY2F0aW9uL3BrY3MxMDxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3Rl Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+ DQpUaGVyZSBhbHJlYWR5IGFyZSByZWdpc3RlcmVkLjxicj4NCjxicj4NCkkgdGhpbmsgeW91IGFy ZSB0YWxraW5nIGFib3V0IGdldHRpbmcgQ29udGVudC1Gb3JtYXQgbnVtYmVycyBmb3IgdGhlc2U/ PGJyPg0KRG8gd2UgbmVlZCBhbnkgcGFyYW1ldGVycyBvciBjb250ZW50LWNvZGluZ3Mgd2l0aCB0 aGF0Pzxicj4NCjxicj4NCkdyw7zDn2UsIENhcnN0ZW48YnI+DQo8YnI+DQpJTVBPUlRBTlQgTk9U SUNFOiBUaGUgY29udGVudHMgb2YgdGhpcyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBj b25maWRlbnRpYWwgYW5kIG1heSBhbHNvIGJlIHByaXZpbGVnZWQuIElmIHlvdSBhcmUgbm90IHRo ZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVs eSBhbmQgZG8gbm90IGRpc2Nsb3NlIHRoZSBjb250ZW50cyB0byBhbnkgb3RoZXIgcGVyc29uLCB1 c2UgaXQgZm9yIGFueSBwdXJwb3NlLA0KIG9yIHN0b3JlIG9yIGNvcHkgdGhlIGluZm9ybWF0aW9u IGluIGFueSBtZWRpdW0uIFRoYW5rIHlvdS48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCklNUE9S VEFOVCBOT1RJQ0U6IFRoZSBjb250ZW50cyBvZiB0aGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNobWVu dHMgYXJlIGNvbmZpZGVudGlhbCBhbmQgbWF5IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYgeW91IGFy ZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGlt bWVkaWF0ZWx5IGFuZCBkbyBub3QgZGlzY2xvc2UgdGhlIGNvbnRlbnRzIHRvIGFueSBvdGhlciBw ZXJzb24sIHVzZSBpdCBmb3IgYW55IHB1cnBvc2UsDQogb3Igc3RvcmUgb3IgY29weSB0aGUgaW5m b3JtYXRpb24gaW4gYW55IG1lZGl1bS4gVGhhbmsgeW91Lg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_VI1PR0801MB21122EB265DF70E45C26BC80FA6A0VI1PR0801MB2112_-- From nobody Thu May 24 07:37:35 2018 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CC1B12DA6C; Thu, 24 May 2018 07:37:33 -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, 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 7HwBIKzEN6p4; Thu, 24 May 2018 07:37:30 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [134.102.201.18]) (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 7ACD81271DF; Thu, 24 May 2018 07:37:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w4OEbLnZ005770; Thu, 24 May 2018 16:37:21 +0200 (CEST) Received: from [192.168.217.114] (p5DC7E3F3.dip0.t-ipconnect.de [93.199.227.243]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 40sBmc5zryzDXpR; Thu, 24 May 2018 16:37:20 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Carsten Bormann In-Reply-To: Date: Thu, 24 May 2018 16:37:20 +0200 Cc: core , "ace@ietf.org" X-Mao-Original-Outgoing-Id: 548865438.434765-cebc0a28696fff98fb27641412505c1d Content-Transfer-Encoding: quoted-printable Message-Id: <7952F818-15C7-4151-8A98-936A6250F5FB@tzi.org> References: <0158C0A6-C8D5-4F19-9C12-23BDC8A7768A@tzi.org> <8976A481-6467-4DAD-A5ED-9AE05E9CC62D@tzi.org> To: Hannes Tschofenig X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [Ace] Early media-type registration for EST over CoAP X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2018 14:37:34 -0000 On May 24, 2018, at 16:15, Hannes Tschofenig = wrote: >=20 > Hi all, > =20 > Trying to finalize this discussion: Could we do an early registry of = the Content-Format numbers? Yes. =20 > =46rom the discussion so far I believe we concluded that the charset = is utf-8 What charset? I thought we don=E2=80=99t have parameters (see below). > and that there are no parameters. Is that correct? That is my understanding so far, but the point of me asking the question = was to ask the actual experts about these media types. Did we get that = input? Next step: make a proposal and raise this on core-parameters@ietf.org so = we get the needed input from the designated expert. Gr=C3=BC=C3=9Fe, Carsten > =20 > Ciao > Hannes > =20 > From: Carsten Bormann [mailto:cabo@tzi.org]=20 > Sent: 16 May 2018 12:30 > To: Hannes Tschofenig > Cc: ace@ietf.org; core > Subject: Re: [Ace] Early media-type registration for EST over CoAP > =20 > Forgot to add another example: the content-format numbers for COSE = have parameters.=20 >=20 > Sent from mobile >=20 > On 16. May 2018, at 12:26, Carsten Bormann wrote: >=20 > I was thinking about media type parameters such as charset=3D"utf-8". = The RT value need to be registered separately, but we can be a bit lazy = about that.=20 >=20 > Sent from mobile >=20 > On 16. May 2018, at 12:15, Hannes Tschofenig = wrote: >=20 > Hi Carsten, >=20 > Yes, I am talking about the Content-Format numbers for them. > Would rt=3D"ace.est" be the parameter you are talking about? >=20 > Ciao > Hannes >=20 > -----Original Message----- > From: Carsten Bormann [mailto:cabo@tzi.org] > Sent: 15 May 2018 11:45 > To: Hannes Tschofenig > Cc: ace@ietf.org; core > Subject: Re: [Ace] Early media-type registration for EST over CoAP >=20 > On May 15, 2018, at 10:56, Hannes Tschofenig = wrote: >=20 > =20 > I am curious whether it would be possible to ask for early media-type = registration of at least these two types: > - application/pkcs7-mime > - application/pkcs10 >=20 > There already are registered. >=20 > I think you are talking about getting Content-Format numbers for = these? > Do we need any parameters or content-codings with that? >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 > IMPORTANT NOTICE: The contents of this email and any attachments are = confidential and may also be privileged. If you are not the intended = recipient, please notify the sender immediately and do not disclose the = contents to any other person, use it for any purpose, or store or copy = the information in any medium. Thank you. >=20 >=20 > IMPORTANT NOTICE: The contents of this email and any attachments are = confidential and may also be privileged. If you are not the intended = recipient, please notify the sender immediately and do not disclose the = contents to any other person, use it for any purpose, or store or copy = the information in any medium. Thank you. = _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace From nobody Thu May 24 07:54:43 2018 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13F0712708C; Thu, 24 May 2018 07:54:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D_xd_CquMNn5; Thu, 24 May 2018 07:54:38 -0700 (PDT) Received: from lb2-smtp-cloud7.xs4all.net (lb2-smtp-cloud7.xs4all.net [194.109.24.28]) (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 6D0D5126D0C; Thu, 24 May 2018 07:54:38 -0700 (PDT) Received: from webmail.xs4all.nl ([IPv6:2001:888:0:22:194:109:20:207]) by smtp-cloud7.xs4all.net with ESMTPA id LrdSfBu7i8U07LrdSf2ZXM; Thu, 24 May 2018 16:54:36 +0200 Received: from AMontpellier-654-1-155-119.w90-0.abo.wanadoo.fr ([90.0.250.119]) by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Thu, 24 May 2018 16:54:34 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Thu, 24 May 2018 16:54:34 +0200 From: peter van der Stok To: Carsten Bormann Cc: Hannes Tschofenig , core , ace@ietf.org Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <7952F818-15C7-4151-8A98-936A6250F5FB@tzi.org> References: <0158C0A6-C8D5-4F19-9C12-23BDC8A7768A@tzi.org> <8976A481-6467-4DAD-A5ED-9AE05E9CC62D@tzi.org> <7952F818-15C7-4151-8A98-936A6250F5FB@tzi.org> Message-ID: X-Sender: stokcons@xs4all.nl User-Agent: XS4ALL Webmail X-CMAE-Envelope: MS4wfPxeiFleP9FcGeOV2GvOGaiJ0Dnpp+XnVsFYir8uD27DmaZlzpHp+Ky4Mq0jwL4EflwGpv/6GsSYWR9glXJmYb8NyfaRM7blO98ro0cFa26DJ1NLJ49p gMrfbB3VcSAvVA2s9hkGlsF3AHxuM3iIaiWvN6RqmlppTScJRMR5GAheuLua8OlOlX2UUky5z2qnxHIKMRbA90J/IajMsBvfG3S8doGzPJPup3OcriZpQJvr rLsIcPc6IcnMKE3oSaSzmQ914eW0IMXI7ma+9Pjawho= Archived-At: Subject: Re: [Ace] [core] Early media-type registration for EST over CoAP X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2018 14:54:42 -0000 Ok, I will raise the experts to-morrow. Peter Carsten Bormann schreef op 2018-05-24 16:37: > On May 24, 2018, at 16:15, Hannes Tschofenig > wrote: >> >> Hi all, >> >> Trying to finalize this discussion: Could we do an early registry of >> the Content-Format numbers? > > Yes. > >> From the discussion so far I believe we concluded that the charset is >> utf-8 > > What charset? I thought we don’t have parameters (see below). > >> and that there are no parameters. Is that correct? > > That is my understanding so far, but the point of me asking the > question was to ask the actual experts about these media types. Did > we get that input? > > Next step: make a proposal and raise this on core-parameters@ietf.org > so we get the needed input from the designated expert. > > Grüße, Carsten > > >> >> Ciao >> Hannes >> >> From: Carsten Bormann [mailto:cabo@tzi.org] >> Sent: 16 May 2018 12:30 >> To: Hannes Tschofenig >> Cc: ace@ietf.org; core >> Subject: Re: [Ace] Early media-type registration for EST over CoAP >> >> Forgot to add another example: the content-format numbers for COSE >> have parameters. >> >> Sent from mobile >> >> On 16. May 2018, at 12:26, Carsten Bormann wrote: >> >> I was thinking about media type parameters such as charset="utf-8". >> The RT value need to be registered separately, but we can be a bit >> lazy about that. >> >> Sent from mobile >> >> On 16. May 2018, at 12:15, Hannes Tschofenig >> wrote: >> >> Hi Carsten, >> >> Yes, I am talking about the Content-Format numbers for them. >> Would rt="ace.est" be the parameter you are talking about? >> >> Ciao >> Hannes >> >> -----Original Message----- >> From: Carsten Bormann [mailto:cabo@tzi.org] >> Sent: 15 May 2018 11:45 >> To: Hannes Tschofenig >> Cc: ace@ietf.org; core >> Subject: Re: [Ace] Early media-type registration for EST over CoAP >> >> On May 15, 2018, at 10:56, Hannes Tschofenig >> wrote: >> >> >> I am curious whether it would be possible to ask for early media-type >> registration of at least these two types: >> - application/pkcs7-mime >> - application/pkcs10 >> >> There already are registered. >> >> I think you are talking about getting Content-Format numbers for >> these? >> Do we need any parameters or content-codings with that? >> >> Grüße, Carsten >> >> IMPORTANT NOTICE: The contents of this email and any attachments are >> confidential and may also be privileged. If you are not the intended >> recipient, please notify the sender immediately and do not disclose >> the contents to any other person, use it for any purpose, or store or >> copy the information in any medium. Thank you. >> >> >> IMPORTANT NOTICE: The contents of this email and any attachments are >> confidential and may also be privileged. If you are not the intended >> recipient, please notify the sender immediately and do not disclose >> the contents to any other person, use it for any purpose, or store or >> copy the information in any medium. Thank you. >> _______________________________________________ >> Ace mailing list >> Ace@ietf.org >> https://www.ietf.org/mailman/listinfo/ace > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Thu May 24 10:21:19 2018 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0577A1270FC; Thu, 24 May 2018 10:21:18 -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_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 1hrGrbLS4SGc; Thu, 24 May 2018 10:21:14 -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 4722412421A; Thu, 24 May 2018 10:21:14 -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.1347.2; Thu, 24 May 2018 10:18:04 -0700 From: Jim Schaad To: 'Hannes Tschofenig' , CC: References: <359EC4B99E040048A7131E0F4E113AFC014C3AA67D@marchand> <00ad01d3e751$5c1f03a0$145d0ae0$@augustcellars.com> In-Reply-To: Date: Thu, 24 May 2018 10:20:45 -0700 Message-ID: <01b801d3f383$8e9c4e30$abd4ea90$@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: AQG8BN2SgGQI0s8TRVm0gk+2+YL3PwIWpoMfASQo/NWkVSRkEA== Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Ace] WGLC on draft-ietf-ace-cwt-proof-of-possession-02 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2018 17:21:18 -0000 > -----Original Message----- > From: Hannes Tschofenig > Sent: Wednesday, May 23, 2018 12:55 PM > To: Jim Schaad ; draft-ietf-ace-cwt-proof-of- > possession@ietf.org > Cc: ace@ietf.org > Subject: RE: [Ace] WGLC on draft-ietf-ace-cwt-proof-of-possession-02 > > Hi Jim, > > A few remarks below. > > -----Original Message----- > From: Jim Schaad [mailto:ietf@augustcellars.com] > Sent: 09 May 2018 05:51 > To: draft-ietf-ace-cwt-proof-of-possession@ietf.org > Cc: ace@ietf.org > Subject: RE: [Ace] WGLC on draft-ietf-ace-cwt-proof-of-possession-02 > > I'll pull out the list of comments that I wrote a month ago but didn't start that > computer up recently. > > 1. Are all of the authors necessary? As a chair I need to justify a count of > more than 5 to the IESG. > > [Hannes] As mentioned by Mike already, this was the result of a draft > merger. The text initially came from an OAuth document (since this work had > its history in the OAuth WG). > > 2. Is the last sentence in section 1 necessary? Are you actually defining any > strings that could be case-sensitive? > > [Hannes] I think we could get rid of that sentence. > > 3. Terminology: In the definition of Issuer please make 'its' clearer. It is not > clear whose claims are being bound. > > [Hannes] How about: > > Issuer > Party that creates the CWT and binds the claims to the proof-of- > possession key. It's better - 'binds claims about the subject' might be clearer > > > 4. Terminology: I still think this is 'Presenter' is a very strange term to use for > this definition. I would really like to see it be made something that makes > sense and then say the term is the same as this in JWT. The term has a > model of use with it that I do not believe can be sustained even for the ACE > Oauth case but really not in other cases. > > [Hannes] It is a strange term but we used it also in the OAuth JWT PoP > document and hence it wouldn't make sense to change it now. If you really cannot change the term, then it might make sense to add some description of other terminology that others might be familiar with. > > 5. Terminology: Recipient matches presenter, and it matches the OAuth > model > and not a trust model world. Relying party or service provider make far > more sense to me. > > [Hannes] Same comment as above. I prefer to be in alignment with the > OAuth work here. I am wondering whether we should also copy the figures > from Section 1 of https://tools.ietf.org/html/rfc7800 to make the > architecture clearer. > > 6. Under what circumstances would a 'sub' claim be present and it is not the > presenter? I can see that a holder of the key may be implicitly (or > anonymously) named, but putting something in the subject field which is not > identifying the presenter is something that I would reject without a good > presentation of why in the document. > > [Hannes] Mike provided his perspective on this issue already. CWT is similar > to JWT a somewhat flexible building block. What claims should, must or may > be included in a given deployment depends a bit on the use case. Not > including the subject claim may be useful for privacy purposes, for example. > In other cases you definitely want to convey that information. I completely agree with your last sentence. The sub would be omitted because of privacy or not needed. However having the subject be present and the subject not being the presenter seems to be a very strange concept. Here is a token issued by A where the subject is B and the key is held by C. > > 7. I would disagree with the claim that if the 'sub' claim is missing then it > would normally be the issuer. For the world of IoT, I would expect that the > subject would not be present because there is no need to identify the > subject to the recipient. I.e. it is an anonymous subject. > > [Hannes] I am not sure that this is always the case in an IoT deployment. For > example, imagine if a technician accesses some industrial device then I want > to have the information about the person accessing those devices in my > audit trail. I could easily be wrong about the subject claim not being absent more often that not. However that still does not mean it would normally be about the issuer rather than an anonymous subject. > > 8. It is not clear to me that either of the sub and iss claims would normally be > present. They might be present but neither is needed. The subject can be > anonymous and the issuer is identified by the key used to validate the > security on the CWT. > > [Hannes] In many deployments they may well not be present. That's > completely fine. Fewer claims can sometimes be better. > > 9. In section 3.1 the first two sentences appear to be contradictory. > Members are used to identify the POP key. Other things than a POP key can > be used than a POP key. If they are used to identify the POP key- why would > they not deal with the POP key? I think that you should do a separation and > define the 'cnf' file which can hold any number of confirmation methods and > then have a section on defining some POP cnf method field holders. > > [Hannes] How does this sound: > > > Section 3.1. Confirmation Claim > > > FROM: > > The "cnf" claim is used in the JWT to contain members used to > identify the proof-of-possession key. Other members of the "cnf" > object may be defined because a proof-of-possession key may not be > the only means of confirming the authenticity of the token. This is > analogous to the SAML 2.0 [OASIS.saml-core-2.0-os] > SubjectConfirmation element in which a number of different subject > confirmation methods can be included (including proof-of-possession > key information). > > TO: > > The "cnf" claim in the JWT is used to carry confirmation methods, some of > them use proof-of-possession keys while others do not. This design is > analogous to the SAML 2.0 [OASIS.saml-core-2.0-os] SubjectConfirmation > element in which a number of different subject confirmation methods can > be included (including proof-of-possession key information). s/JWT/CWT/ otherwise it looks better. > > > > > 10. In section 3.1 P1 - I am not sure why you have something here about > confirming the authenticity of the token as oppose to confirming the identity > of the presenter. Why would that type of information be placed here where > it is not useful. > > [Hannes] I believe this part would be clarified with my wording change to > Section 3.1 as proposed in #9. I'd want to see an updated version to know if that is true. > > 11. In section 3.1 P2 - We are back to the same argument that existed for a > CWT in general. Not knowing that a CWT is for a specific application means > that it can be used in a different application and checking that the first > application would have done is ignored by the second one because it will > ignore fields it does not understand. > > [Hannes] Mike provided a detailed response to this item already. > > 12. I am unclear why there should be a restriction on the number of POP keys > that can be in a 'cnf' object. If there are multiple keys, then any or all of them > are of equal value in doing the confirmation. Just like there can be multiple > confirmation methods and an application could choose to use any one of > them. > > [Hannes] I believe we should not place such a restriction in there. A profile > should place restrictions on the number of allowed "cnf" claims there. > Changing the names of the claims, as a proposed alternative to get around > this limit, appears a bit problematic since we have to register them in the > IANA registry. > Hence, my proposal is to change the text > > FROM: > > The "cnf" claim value MUST represent only a single proof-of- > possession key; thus, at most one of the "jwk", "jwe", and "jku" (JWK > Set URL) confirmation values defined below may be present. Note that > if an application needs to represent multiple proof-of-possession > keys in the same JWT, one way for it to achieve this is to use other > claim names, in addition to "cnf", to hold the additional proof-of- > possession key information. > > TO: > > The "cnf" claim value may contain one or multiple proof-of- > possession keys. Hence, more than one "jwk", "jwe", and/or "jku" (JWK > Set URL) confirmation values may be present in a CWT. A profile may > impose > further restrictions on the number of PoP keys that are present and > also whether all or a only a subset of them needs to be utilized by in > a given application domain. That would be my preference. I don't know how often it would be used but it seems to be a better idea for some longer term CWTs Jim > > > ~~~snip ~~~ > > I will respond to the other questions in a second email; ran out of time. > > Ciao > Hannes > > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended recipient, > please notify the sender immediately and do not disclose the contents to any > other person, use it for any purpose, or store or copy the information in any > medium. Thank you. From nobody Fri May 25 03:23:27 2018 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C9E0126C0F; Fri, 25 May 2018 03:23:25 -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_FAIL=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 I6tDRGekSEPz; Fri, 25 May 2018 03:23:23 -0700 (PDT) Received: from wp382.webpack.hosteurope.de (wp382.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8597::]) (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 17418124D68; Fri, 25 May 2018 03:23:23 -0700 (PDT) Received: from mail-qk0-f181.google.com ([209.85.220.181]); authenticated by wp382.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) id 1fM9sX-0000mm-7o; Fri, 25 May 2018 12:23:21 +0200 Received: by mail-qk0-f181.google.com with SMTP id c23-v6so3649493qkb.5; Fri, 25 May 2018 03:23:21 -0700 (PDT) X-Gm-Message-State: ALKqPwdNHNyRhFT42UVuESt9fn+vYUO+4vtu0bgA+ouyuo5wfDtpwDzQ we6xt30nlw2v1hshkKeEtamjTP6LpqHVyq3WWH8= X-Google-Smtp-Source: ADUXVKJZpaawXEYFxfiwu+k2NWLaCXkf/Q2ncWvkBOM10I1sOpu5BlLj5o83w7/N9wbKcVyMv0v6WL0LCCw9Drzohd4= X-Received: by 2002:a37:5fc4:: with SMTP id t187-v6mr1453209qkb.62.1527243800241; Fri, 25 May 2018 03:23:20 -0700 (PDT) MIME-Version: 1.0 References: <0158C0A6-C8D5-4F19-9C12-23BDC8A7768A@tzi.org> <8976A481-6467-4DAD-A5ED-9AE05E9CC62D@tzi.org> <7952F818-15C7-4151-8A98-936A6250F5FB@tzi.org> In-Reply-To: <7952F818-15C7-4151-8A98-936A6250F5FB@tzi.org> From: Klaus Hartke Date: Fri, 25 May 2018 12:23:09 +0200 X-Gmail-Original-Message-ID: Message-ID: To: Carsten Bormann Cc: Hannes Tschofenig , "ace@ietf.org" , core Content-Type: multipart/alternative; boundary="00000000000032ee06056d05284c" X-bounce-key: webpack.hosteurope.de; hartke@projectcool.de; 1527243803; 5b1babf7; X-HE-SMSGID: 1fM9sX-0000mm-7o Archived-At: Subject: Re: [Ace] Early media-type registration for EST over CoAP X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2018 10:23:25 -0000 --00000000000032ee06056d05284c Content-Type: text/plain; charset="UTF-8" Carsten Bormann wrote: > Next step: make a proposal and raise this on core-parameters@ietf.org so we get the needed input from the designated expert. Done. https://www.ietf.org/mail-archive/web/core-parameters/current/msg00024.html Klaus --00000000000032ee06056d05284c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Carsten Bormann wrote:
> N= ext step: make a proposal and raise this on core-parameters@ietf.org so we get the n= eeded input from the designated expert.

--00000000000032ee06056d05284c-- From nobody Sat May 26 20:02:04 2018 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A836120047 for ; Sat, 26 May 2018 20:02:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9UWc64PLqLpM for ; Sat, 26 May 2018 20:02:00 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B54D1241F5 for ; Sat, 26 May 2018 20:02:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10694; q=dns/txt; s=iport; t=1527390120; x=1528599720; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=7D6bhygzBbVXVDdZNmqO2nCiZrNn97jbhxx4CKF63G4=; b=BRHhbxle0efamc1+TfmDJI9JjDmr8vH3y/BZFqfBIvJDXQwhyF+e5O0b rtiXJiP7cc4/mM/m1Ac4THhPj4oZq6iqkKqQd8WoBpgu2Q2TbQ3ZJfnVS Vtgi29MJqEaKJs3Y2A6DCVlBWqihvEgxvc2HXNvfHXWdvXnlPfIGjB4iC 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DyAQAhHwpb/49dJa1aGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYJOSytifygKmF2BeYEPjkSEdxSBZAuEbAKCDyE2FgECAQE?= =?us-ascii?q?BAQEBAmwohSgBAQEBAy1DGQIBCBEEAQEoBzIUCQgBAQQBCQkIgxyBG2SnFog?= =?us-ascii?q?/gWiHOX2BVD8laoMNhEABEgFVhR4ChyMIkTcJAospgy2BQxuDVIdckGQCERM?= =?us-ascii?q?BgSQjATFhcXAVgn6DMQECjRpvjgSBH4EZAQE?= X-IronPort-AV: E=Sophos;i="5.49,446,1520899200"; d="scan'208,217";a="120938872" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 May 2018 03:01:59 +0000 Received: from XCH-ALN-007.cisco.com (xch-aln-007.cisco.com [173.36.7.17]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id w4R31xH3026971 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 27 May 2018 03:01:59 GMT Received: from xch-aln-010.cisco.com (173.36.7.20) by XCH-ALN-007.cisco.com (173.36.7.17) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Sat, 26 May 2018 22:01:58 -0500 Received: from xch-aln-010.cisco.com ([173.36.7.20]) by XCH-ALN-010.cisco.com ([173.36.7.20]) with mapi id 15.00.1320.000; Sat, 26 May 2018 22:01:58 -0500 From: "Panos Kampanakis (pkampana)" To: Hannes Tschofenig , "ace@ietf.org" Thread-Topic: EST over CoAP: Introduction Thread-Index: AdPsLs4i7p+ZRhEOTMSeKeo6haRT5QJN1T6g Date: Sun, 27 May 2018 03:01:58 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.211.248] Content-Type: multipart/alternative; boundary="_000_d343f9f443f3474eb543c776fa0bbe0bXCHALN010ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Ace] EST over CoAP: Introduction X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 May 2018 03:02:03 -0000 --_000_d343f9f443f3474eb543c776fa0bbe0bXCHALN010ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Hannes, Thank you for the text. The 15.4 was only serving only as a motivation usec= ase. We revamped the Intro similar to what you suggested. It will be fixed = in the next iteration. Panos From: Ace [mailto:ace-bounces@ietf.org] On Behalf Of Hannes Tschofenig Sent: Tuesday, May 15, 2018 5:34 AM To: ace@ietf.org Subject: [Ace] EST over CoAP: Introduction Here is a proposal to change the introduction to the relevant parts only an= d to avoid repetition. (The current document still keeps talking about IEEE 802.15.4 when there ar= e so many other radio technologies as well. There is nothing in this spec that makes this 15.4 specific. I understand t= hat some of the authors really like 15.4 but .....) Here is my proposal to replace Section 1 and Section 1.1: ----- 1. Introduction "Classical" Enrollment over Secure Transport (EST) [RFC7030] is used for authenticated/authorized endpoint certificate enrollment (and optionally key provisioning) through a Certificate Authority (CA) or Registration Authority (RA). It uses HTTPS. This specification defines a new transport for EST based on the Constrained Application Protocol (CoAP) since some Internet of Things (I= oT) devices use CoAP instead of HTTP. This specification therefore utilizes = DTLS [RFC6347], CoAP [RFC7252], and UDP instead of TLS [RFC5246], HTTP [RFC7230] and TCP= . This document also profiles EST and only supports certificate-based clie= nt Authentication. The results are: * The EST-coaps client does not support HTTP Basic authentication (as described in Section 3.2.3 of [RFC7030]). * The EST-coaps client does not support authentication at the application layer (as described in Section 3.2.3 of [RFC7030]). EST messages may be relatively large and for this reason this document re-uses CoAP Block-Wise Transfer [RFC7959] to offer a fragmentation mechanism of EST messages at the CoAP layer. ----- Ciao Hannes IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. --_000_d343f9f443f3474eb543c776fa0bbe0bXCHALN010ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Hannes,<= /span>

Thank you for the text= . The 15.4 was only serving only as a motivation usecase. We revamped the I= ntro similar to what you suggested. It will be fixed  in the next iter= ation.

Panos

 

 

From: Ace [mailto:ace-bounces@ietf.org] On= Behalf Of Hannes Tschofenig
Sent: Tuesday, May 15, 2018 5:34 AM
To: ace@ietf.org
Subject: [Ace] EST over CoAP: Introduction

 

Here is a proposal to change th= e introduction to the relevant parts only and to avoid repetition.

(The current document still kee= ps talking about IEEE 802.15.4 when there are so many other radio technolog= ies as well.

There is nothing in this spec t= hat makes this 15.4 specific. I understand that some of the authors really = like 15.4 but …..)

 

Here is my proposal to replace = Section 1 and Section 1.1:

 

-----

 

1.  Introduction

 

   "Classical&qu= ot; Enrollment over Secure Transport (EST) [RFC7030] is used for=

   authenticated/auth= orized endpoint certificate enrollment (and

   optionally key pro= visioning) through a Certificate Authority (CA) or

   Registration Autho= rity (RA).  It uses HTTPS.

 

   This specific= ation defines a new transport for EST based on the

   Constrained A= pplication Protocol (CoAP) since some Internet of Things (IoT)

   devices use C= oAP instead of HTTP. This specification therefore utilizes DTLS [RFC6347],

   CoAP [RFC7252= ], and UDP instead of TLS [RFC5246], HTTP [RFC7230] and TCP.

 

   This document also= profiles EST and only supports certificate-based client

   Authenticatio= n. The results are:

   

     &= nbsp;*  The EST-coaps client does not support HTTP Basic authenticatio= n

     &= nbsp;   (as described in Section 3.2.3 of [RFC7030]).<= /span>

 

      = *  The EST-coaps client does not support authentication at the

     &= nbsp;   application layer (as described in Section 3.2.3 of [RFC7= 030]).

   =

   EST messages = may be relatively large and for this reason this

   document re-uses C= oAP Block-Wise Transfer [RFC7959] to

   offer a fragm= entation mechanism of EST messages at the CoAP layer.

 

-----

 

Ciao

Hannes

 

IMPORTANT NOTICE: The contents of= this email and any attachments are confidential and may also be privileged= . If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any othe= r person, use it for any purpose, or store or copy the information in any m= edium. Thank you.

--_000_d343f9f443f3474eb543c776fa0bbe0bXCHALN010ciscocom_-- From nobody Mon May 28 00:42:49 2018 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FE8912426E for ; Mon, 28 May 2018 00:42:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.201 X-Spam-Level: X-Spam-Status: No, score=-1.201 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gWuSSpppiqjC for ; Mon, 28 May 2018 00:42:44 -0700 (PDT) Received: from smtp-out11.electric.net (smtp-out11.electric.net [185.38.181.34]) (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 8A3671200C5 for ; Mon, 28 May 2018 00:42:44 -0700 (PDT) Received: from 1fNCni-00072G-U6 by out11a.electric.net with emc1-ok (Exim 4.90_1) (envelope-from ) id 1fNCni-00072s-Uj for ace@ietf.org; Mon, 28 May 2018 00:42:42 -0700 Received: by emcmailer; Mon, 28 May 2018 00:42:42 -0700 Received: from [194.218.146.197] (helo=sp-mail-2.sp.se) by out11a.electric.net with esmtps (TLSv1.2:ECDHE-RSA-AES128-SHA256:128) (Exim 4.90_1) (envelope-from ) id 1fNCni-00072G-U6 for ace@ietf.org; Mon, 28 May 2018 00:42:42 -0700 Received: from [192.168.0.166] (10.116.0.226) by sp-mail-2.sp.se (10.100.0.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Mon, 28 May 2018 09:42:42 +0200 To: "ace@ietf.org" References: <005601d3e622$af427100$0dc75300$@augustcellars.com> <004c01d3eed1$fc118ae0$f434a0a0$@augustcellars.com> From: Ludwig Seitz Message-ID: <212b8afb-06b7-bc05-5c5c-ee0bf7b2602d@ri.se> Date: Mon, 28 May 2018 09:42:35 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <004c01d3eed1$fc118ae0$f434a0a0$@augustcellars.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.116.0.226] X-ClientProxiedBy: sp-mail-2.sp.se (10.100.0.162) To sp-mail-2.sp.se (10.100.0.162) X-Outbound-IP: 194.218.146.197 X-Env-From: ludwig.seitz@ri.se X-Proto: esmtps X-Revdns: X-HELO: sp-mail-2.sp.se X-TLS: TLSv1.2:ECDHE-RSA-AES128-SHA256:128 X-Authenticated_ID: X-PolicySMART: 14510320 X-Virus-Status: Scanned by VirusSMART (c) X-Virus-Status: Scanned by VirusSMART (s) Archived-At: Subject: Re: [Ace] OAuth-Authz Interop X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 May 2018 07:42:48 -0000 Hello virtual interop participants, I think I have now come to a version of the interop test plan (https://github.com/ace-wg/ace-oauth/blob/master/InteropTestPlan.txt) that implements (most) of Jim's comments and feel relatively usable for the virtual interop. The biggest change is that I reordered the tests so that you only need to run one server at a time for a batch of tests. Sorry for the late changes, I hope we can test something on Wednesday. /Ludwig -- Ludwig Seitz, PhD Security Lab, RISE SICS Phone +46(0)70-349 92 51 From nobody Mon May 28 03:53:16 2018 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0568126BF7 for ; Mon, 28 May 2018 03:53:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 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, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=erdtman-se.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9zSmAwnJk79z for ; Mon, 28 May 2018 03:53:10 -0700 (PDT) Received: from mail-pl0-x235.google.com (mail-pl0-x235.google.com [IPv6:2607:f8b0:400e:c01::235]) (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 79DF2126BF0 for ; Mon, 28 May 2018 03:53:10 -0700 (PDT) Received: by mail-pl0-x235.google.com with SMTP id v24-v6so7020044plo.3 for ; Mon, 28 May 2018 03:53:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=erdtman-se.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=x96fIYh/RX1hSZTn0APa07JwI9kYKa4W/A0d0sbl5r0=; b=o6GL+uQhRUS5/9Zd6Dn9KZ0wk1/47Y215PoTXUPEMx+QeaipUFj1MzxDHY0hlJJUqI T8ybAXs7/65jx8wwUhd4Iy2Tc/a0qYOQzlUVsHNEXlRiT4eojLZ5pxF/l4iBAJtmSibP iWKdyPysd1Dzn8/aTdTpZk4aI5NX8ODgJldQz+3XfqcLrhVpZBjmgWb4IcX6YXSyQwmV LZJBHP/P0IwB1zvv50ip9LzUYOGtT3lhsMBFGofuzJCHflNpT9YFPzYya11VsJZiNb53 G0gLVw/w38J12PV84baAvrp2tPK2f+nQoh0hrZIFgXkJKYtc7rrgl5JnkOa47mPjSH6E mwKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=x96fIYh/RX1hSZTn0APa07JwI9kYKa4W/A0d0sbl5r0=; b=YDb10aTpdITXaLY8VIW+Yt3zOVbQhCZG3OsAUAsozTXGJNQ4oRlq2Wk+4a/bjMYFQt iApCfJ98WUq2hUH2lTrxwe5WrOQqqJgegX7/JC/NjBwFNveQpn6Yb/vcbY27kQtHCrmB gmEK+JYXLD4YFl0QpQS4gAJW/CpnCjtFYWPQV3Q+rZkD/abCGF66hu9WhDlsf37h9hLq /QY/pvc2QPRwqj4fZv2KZMw3A6K7m8XcXYDLGXTzlJO2WeENSwdLvqntIEhJEe46CACj iHHwiPdHhzVw2cS46Lirp44OfrkD3k4zXAtLBya39csmlbB97Sg9GWHoouqBy9nsDxB3 BgfQ== X-Gm-Message-State: ALKqPwc+IvkvAPNKMKp6LVoW+hIhYHA66F8uMnXHYKj7VSLe5+Eh3Yca tG5zTesKnCUXGReviJ3Kb4OilhGfbBaDXhw/uBpkcU0Qlvg= X-Google-Smtp-Source: AB8JxZqTcgMX28Fovgd7iqaThIPhZ2yDaw2CUrPxMr4wvO+jKOsN9m3rrFMQMZdR/Udcde3C1I8bYHKTz+5Jipym8Ps= X-Received: by 2002:a17:902:8486:: with SMTP id c6-v6mr13143860plo.23.1527504789710; Mon, 28 May 2018 03:53:09 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a17:90a:5d05:0:0:0:0 with HTTP; Mon, 28 May 2018 03:53:08 -0700 (PDT) In-Reply-To: <359EC4B99E040048A7131E0F4E113AFC014C3CA77A@marathon> References: <359EC4B99E040048A7131E0F4E113AFC014C3CA77A@marathon> From: Samuel Erdtman Date: Mon, 28 May 2018 12:53:08 +0200 Message-ID: To: Roman Danyliw Cc: "ace@ietf.org" Content-Type: multipart/alternative; boundary="000000000000623d24056d41ec75" Archived-At: Subject: Re: [Ace] WGLC feedback on draft-ietf-ace-cwt-proof-of-possession-02 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 May 2018 10:53:15 -0000 --000000000000623d24056d41ec75 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Se comments inline On Wed, May 23, 2018 at 7:40 PM, Roman Danyliw wrote: > Hello! > (chair hat off) > > I reviewed draft-ietf-ace-cwt-proof-of-possession-02 in WGLC and have the > following feedback: > > (1) (Editorial) Page 3, "The value of the 'cnf' claim is a CBOR map and > the ...". Isn't it more precise to say "The _representation_ of the 'cnf= ' > claim is a CBOR map ..."? > I have no strong opinion here, what does the other authors say? > > (2) (Editorial) Page 3, Why is the sentence "(In some applications, the > subject identifier ..." in parenthesis? > This is copied from RFC7800. > > (3) (Editorial) Page 4, Section 3.0, I read to the end of this section by > which point there has been discussion of "sub" or "iss". I was left > wondering about how to interpret the case where both are present and none > are. > I agree it could be clearer especially with regards to non being present. One case for when both could be present is when the authorization is the issuer signing an access token that is valid for a specific client and subject is used to look up the PoP key at the receiver (I think this case relates to Jims comment about using kid as cnf, by combining kid with subject it would be unique). When non is present the application context would have to enable the receiver to identify the user of the token if needed. one might want anonymity. With that said some additional text is needed, but the text will be looked over based on Jims comment so we should address this too then. > > (4) (Editorial) Page 4, Section 3.1, Per " At most one of the "COSE_Key" > and "Encrypted_COSE_Key" confirmation values defined below may be > present." Defined below where specifically? I recommend citing Figure 1 > explicitly by s/below/in Figure 1/. > I agree (PR submitted) > > (5) Page 5, Typo in Section 3.2, s/diagonstic/diagnostic/ > Thanks (PR submitted) > (6) (Editorial) Page 5, Section 2.3, Per "If the CWT is not encrypted, th= e > symmetric key MUST be encrypted as described below." Described where > below? I recommend citing Section 3.3 by s/below/In Section 3.3/ > I agree (PR submitted) > > (7) Page 6, Section 3.3, The sentence "The COSE_Key could, for instance, > be encrypted using a COSE_Encrypt0 representation using the > AES-CCM-16-64-128 algorithm" seems out of place. What is this text > explaining relative to the examples? > It is a bit unclear, but it more or less says what the example below says. I think the section as a whole could be clearer. (issue created https://github.com/cwt-cnf/i-d/issues/10) > > (8) Page 7, Section 3.4, Per "The proof-of-possession key can also be > identified by the use of a Key ID instead of communicating the actual key= , > provided the recipient is able to obtain the identified key using the Key > ID." How would the sender know whether the recipient can "obtain the key > using the Key ID"? Additionally, I would recommend adding language that > states that this retrieval process is out of scope for this draft. > The sender needs to know from the application context what cnf method to use. I think we should add both this and a comment saying that retrieval process is out of scope > > (9) (Editorial) Page 7, Section 3.4, Per "In this case, the issuer of a > CWT declares that the presenter possesses a particular key and that the > recipient can cryptographically confirm proof of possession of the key b= y > the presenter by including a "cnf" claim in the CWT whose value is a CBOR > map with the CBOR map containing a "kid" member identifying the key." I > recommend s/is a CBOR map with the CBOR map/is a CBOR map/ > I would like to go even further and change "In this case, the issuer of a CWT declares that the presenter possesses a particular key and that the recipient can cryptographically confirm proof of possession of the key by the presenter by including a "cnf" claim in the CWT whose value is a CBOR map with the CBOR map containing a "kid" member identifying the key." to "In this case, the issuer of a CWT declares that the presenter possesses a particular key and that the recipient can cryptographically confirm proof of possession of the key by the presenter by including the "kid" member identifying the key in the "cnf" claim in the CWT. " It is stated earlier that cnf is a CBOR map so i think we could skip it here. > > (10) Page 8, Section 4. RFC 2119 capitalizations seem more appropriate i= n > these sentences: > > (MUST) "Appropriate means *must* be used to ensure that unintended partie= s > do not learn private key or symmetric key values." > I=C2=B4m not sure what is best practice, but since "appropriate means" cou= ld mean different things depending on context I think the upper case MUST would not add value but rather confusion about what is it I MUST do. Opposed to cases when it is clear e.g. value MUST be of type X. > > (SHOULD) "Applications utilizing proof of possession *should* also utiliz= e > audience restriction, as described in Section 4.1.3 of [JWT], as it > provides different protections." > I agree (issue created https://github.com/cwt-cnf/i-d/issues/8) > (MUST) "Applications that require the proof-of-possession keys > communicated with it to be understood and processed *must* ensure that th= e > parts of this specification that they use are implemented." > I agree (issue created https://github.com/cwt-cnf/i-d/issues/8) > > (11) Page 8, Section 4. Per "Applications utilizing proof of possession > should also utilize audience restriction, as described in Section 4.1.3 o= f > [JWT], as it provides different protections." I recommend > s/different/additional/ > I agree (PR submitted) > (12) (Editorial) Page 8, Section 4, Per > > Applications utilizing proof of possession should also utilize > audience restriction, as described in Section 4.1.3 of [JWT], as it > provides different protections. Proof of possession can be used by > recipients to reject messages from unauthorized senders. Audience > restriction can be used by recipients to reject messages intended for > different recipients. > > The flow of this sentence is off for me. Sentence #1 asserts the need fo= r > audience restrictions. Sentence #3 describes the benefit of Sentence #1. > Sentence #2 interjects with something that seems unrelated to this > need-benefit pairing. > I agree (Issue create https://github.com/cwt-cnf/i-d/issues/9) > (13) Page 8, Section 4, Per "Applications that require the > proof-of-possession keys communicated with it to be understood and > processed must ensure that the parts of this specification that they u= se > are implemented." How is this being ensured? What happens if the needed > parts aren't specified? Also, it seems like the "must" here should be > "MUST". > > > (14) (Editorial) Page 8, Section 4, Per "Replay can also be avoided if a > sub-key is derived from a shared secret that is specific to the instance = of > the PoP demonstration." PoP is spelled out everywhere else in this draft > but here. Yes, the acronym is defined, but for readability, I recommend > against it using it and consistently spelling it out here too. > I could go either way, changing all other place or this one, but for simplicity lets change this one place for now. (PR submitted) > > (15) Page 8, Section 4, Per "Special care has to be applied when carrying > symmetric keys inside the CWT since those not only require integrity > protection but also confidentiality protection." What is that care? > I would say that "care" in this case comes down to either having an signed and encrypted CWT or a signed CWT with an encrypted cnf key > > (16) Page 8, Section 4. Per "Proof-of-possession signatures made with > keys not meeting the application's trust criteria MUST NOT not be relied > upon.", remove the double "not" by s/MUST NOT not/MUST NOT/. > Thanks (PR submitted) > > Roman > > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > --000000000000623d24056d41ec75 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Se comments inline

On Wed, May 23, 2018 at 7:40 PM, Roman Danyliw <rdd@cert.= org> wrote:
Hello!
(chair hat off)

I reviewed draft-ietf-ace-cwt-proof-of-possession-02 in WGLC and have = the following feedback:

(1) (Editorial) Page 3, "The value of the 'cnf' claim is a CBO= R map and the ...".=C2=A0 Isn't it more precise to say "The _= representation_ of the 'cnf' claim is a CBOR map ..."?

I have no strong opinion here, what does the o= ther authors say?
=C2=A0

(2) (Editorial) Page 3,=C2=A0 Why is the sentence "(In some applicatio= ns, the subject identifier ..." in parenthesis?
<= br>
This is copied from RFC7800.
=C2=A0

(3) (Editorial) Page 4, Section 3.0, I read to the end of this section by w= hich point there has been discussion of "sub" or "iss".= =C2=A0 I was left wondering about how to interpret the case where both are = present and none are.

I agree it could = be clearer especially with regards to non being present.
One case= for when both could be present is when the authorization is the issuer sig= ning an access token that is valid for a specific client and subject is use= d to look up the PoP key at the receiver (I think this case relates to Jims= comment about using kid as cnf, by combining kid with subject it would be = unique).
When non is present the application context would have t= o enable the receiver to identify the user of the token if needed. one migh= t want anonymity.
With that said some additional text is needed, = but the text will be looked over based on Jims comment so we should address= this too then.

=C2=A0

(4) (Editorial) Page 4, Section 3.1, Per " At most one of the "CO= SE_Key" and=C2=A0 =C2=A0 "Encrypted_COSE_Key" confirmation v= alues defined below may be=C2=A0 present."=C2=A0 Defined below where s= pecifically?=C2=A0 I recommend citing Figure 1 explicitly by s/below/in Fig= ure 1/.

I agree (PR submitted)
=C2=A0

(5) Page 5, Typo in Section 3.2, s/diagonstic/diagnostic/
<= div>
Thanks (PR submitted)


(6) (Editorial) Page 5, Section 2.3, Per "If the CWT is not encrypted,= the symmetric key MUST be encrypted as described below."=C2=A0 Descri= bed where below?=C2=A0 I recommend citing Section 3.3 by s/below/In Section= 3.3/

I agree (PR submitted)
<= div>=C2=A0

(7) Page 6, Section 3.3, The sentence "The COSE_Key could, for instanc= e, be encrypted using a COSE_Encrypt0 representation using the AES-CCM-16-6= 4-128 algorithm" seems out of place.=C2=A0 What is this text explainin= g relative to the examples?

It is a bit= unclear, but it more or less says what the example below says. I think the= section as a whole could be clearer. (issue created https://github.com/cwt-cnf/i-d/issues/10= )
=C2=A0

(8) Page 7, Section 3.4, Per "The proof-of-possession key can also be = identified by the use of a Key ID instead of communicating the actual key, = provided the recipient is able to obtain the identified key using the Key I= D."=C2=A0 How would the sender know whether the recipient can "ob= tain the key using the Key ID"?=C2=A0 Additionally, I would recommend = adding language that states that this retrieval process is out of scope for= this draft.

The sender needs to know f= rom the application context what cnf method to use. I think we should add b= oth this and a comment saying that retrieval process is out of scope
=C2=A0

(9) (Editorial) Page 7, Section 3.4, Per "In this case, the issuer of = a CWT declares that the presenter possesses a particular key and that the r= ecipient can cryptographically=C2=A0 confirm proof of possession of the key= by the presenter by including a "cnf" claim in the CWT whose val= ue is a CBOR map with the CBOR map containing a "kid" member iden= tifying the key."=C2=A0 I recommend s/is a CBOR map with the CBOR map/= is a CBOR map/

I would like to go even = further and change=C2=A0
"In this case, the issuer of a CWT = declares that the presenter possesses a particular key and that the recipient can cryptographically=C2=A0 confirm= =20 proof of possession of the key by the presenter by including a "cnf&qu= ot;=20 claim in the CWT whose value is a CBOR map with the CBOR map containing a "kid" member identifying the key."
to
&= quot;In this case, the issuer of a CWT declares that the presenter possesse= s a particular key and that the recipient can cryptographically confirm=20 proof of possession of the key by the presenter by including the "kid&= quot; member identifying the key in the "cnf"=20 claim in the CWT. "

It is stated earlier = that cnf is a CBOR map so i think we could skip it here.

=
=C2=A0

(10) Page 8, Section 4.=C2=A0 RFC 2119 capitalizations seem more appropriat= e in these sentences:

(MUST) "Appropriate means *must* be used to ensure that unintended par= ties do not learn private key or symmetric key values."

I=C2=B4m not sure what is best practice, but since=C2= =A0 "appropriate means" could mean different things depending on = context I think the upper case MUST would not add value but rather confusio= n about what is it I MUST do. Opposed to cases when it is clear e.g. value = MUST be of type X.
=C2=A0

(SHOULD) "Applications utilizing proof of possession *should* also uti= lize audience restriction, as described in Section 4.1.3 of [JWT], as it pr= ovides different protections."



(MUST) "Applications that require the proof-of-possession keys communi= cated with it to be understood and processed *must* ensure that the parts o= f this specification that they use are implemented."
<= div>
=C2=A0

(11) Page 8, Section 4. Per=C2=A0 =C2=A0"Applications utilizing proof = of possession should also utilize audience restriction, as described in Sec= tion 4.1.3 of [JWT], as it provides different protections."=C2=A0 I re= commend s/different/additional/

I agree= (PR submitted)


(12) (Editorial) Page 8, Section 4, Per

=C2=A0 =C2=A0Applications utilizing proof of possession should also utilize=
=C2=A0 =C2=A0audience restriction, as described in Section 4.1.3 of [JWT], = as it
=C2=A0 =C2=A0provides different protections.=C2=A0 Proof of possession can = be used by
=C2=A0 =C2=A0recipients to reject messages from unauthorized senders.=C2=A0= Audience
=C2=A0 =C2=A0restriction can be used by recipients to reject messages inten= ded for
=C2=A0 =C2=A0different recipients.

The flow of this sentence is off for me.=C2=A0 Sentence #1 asserts the need= for audience restrictions.=C2=A0 Sentence #3 describes the benefit of Sent= ence #1.=C2=A0 Sentence #2 interjects with something that seems unrelated t= o this need-benefit pairing.



(13) Page 8, Section 4, Per "Applications that require the proof-of-po= ssession keys communicated with it to be understood and processed must ensu= re that the parts of this=C2=A0 =C2=A0 specification that they use are impl= emented."=C2=A0 How is this being ensured?=C2=A0 What happens if the n= eeded parts aren't specified?=C2=A0 Also, it seems like the "must&= quot; here should be "MUST".

=

=C2=A0

(14) (Editorial)=C2=A0 Page 8, Section 4, Per "Replay can also be avoi= ded if a sub-key is derived from a shared secret that is specific to the in= stance of the PoP demonstration."=C2=A0 PoP is spelled out everywhere = else in this draft but here.=C2=A0 Yes, the acronym is defined, but for rea= dability, I recommend against it using it and consistently spelling it out = here too.

I could go either way, changi= ng all other place or this one, but for=20 simplicity lets change this one place for now. (PR submitted)
=C2=A0

(15) Page 8, Section 4, Per "Special care has to be applied when carry= ing symmetric keys inside the CWT since those not only require integrity pr= otection but also=C2=A0 confidentiality protection."=C2=A0 What is tha= t care?

I would say that "care&quo= t; in this case comes down to either having an signed and encrypted CWT or = a signed CWT with an encrypted cnf key
=C2=A0

(16) Page 8, Section 4.=C2=A0 Per "Proof-of-possession signatures made= with keys not meeting the application's trust criteria MUST NOT not be= relied upon.", remove the double "not" by s/MUST NOT not/MU= ST NOT/.

Thanks (PR submitted)
=C2=A0

Roman


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

--000000000000623d24056d41ec75-- From nobody Tue May 29 11:08:33 2018 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33A0A12DA07 for ; Tue, 29 May 2018 11:08:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RFh59rIt-arE for ; Tue, 29 May 2018 11:08:29 -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 B01DB127078 for ; Tue, 29 May 2018 11:08:28 -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.1347.2; Tue, 29 May 2018 11:05:37 -0700 From: Jim Schaad To: Date: Tue, 29 May 2018 11:08:19 -0700 Message-ID: <01f701d3f778$0783ca10$168b5e30$@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: AdP3d+8Ou7m98lwaSjeL4riy1VXFwA== Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: [Ace] Contact Info for ACE Interop Event tomorrow X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 May 2018 18:08:31 -0000 We will go ahead and use a webex meeting for the interop event tomorrow JOIN WEBEX MEETING https://ietf.webex.com/ietf/j.php?MTID=m1e4d4e3b7a8f81354335d9be30dc3687 Meeting number (access code): 640 485 375 Host key: 770328 Meeting password: DEGrDby3 JOIN BY PHONE 1-650-479-3208 Call-in toll number (US/Canada) Can't join the meeting? Contact support here: https://ietf.webex.com/ietf/mc IMPORTANT NOTICE: Please note that this WebEx service allows audio and other information sent during the session to be recorded, which may be discoverable in a legal matter. You should inform all meeting attendees prior to recording if you intend to record the meeting.