From nobody Sun Oct 1 02:35:19 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F273B13471B for ; Sun, 1 Oct 2017 02:35:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5, 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 cB6iW7YAcZvJ for ; Sun, 1 Oct 2017 02:35:15 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0865213471D for ; Sun, 1 Oct 2017 02:35:13 -0700 (PDT) Received: from [192.168.91.203] ([80.92.122.248]) by mail.gmx.com (mrgmx001 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MFcg9-1e4JHx0MvF-00EhqG for ; Sun, 01 Oct 2017 11:35:12 +0200 To: "Ace@ietf.org" From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <55ac5e55-2570-6126-2211-a6c1b65c3006@gmx.net> Date: Sun, 1 Oct 2017 11:35:11 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:KBnVDx6o6ytBIp0q+wvqBCF1NRHZSZIwmrfLtU23PJmN6zm4gOD SyVK5ginGSeKMLQ/Ktf24PpV72SFs2l/uP+MMT7jx4/KkfY+KlwqO2FYousdkHHsEUjosXK ZsoZ/t9NpMcOlQdDKuT+H1XcPsOODwVyE2cXuU9nfnkl2m4j80+2+TU+PmXlvuBZjhUTXGL 2nkXrK1LGlq+ECuD/eF+g== X-UI-Out-Filterresults: notjunk:1;V01:K0:H7exc/7yz+k=:LXiAZwRGDzQrcDzcqkQKe8 3yfM+uXpB/+Mnhtr2NxhDEnE4gPz/YEnSLw2r2dxIspgr6TGPOkqiG4NLaHW0diJ21WdQQA9A SMCToGlS8qgosbGpP7Lv17zp6p/J8hezNkOicdeSFxH/3lGLLrHxDaDMclL1xfVkjE+QrnapW rAy/yV1x1U2LmgMFzTbx0Hu/DiuQut/PF9yU24GJz7R2g7kwyrapie6+JEfiWC4bKmRYBv+Y+ lcMbtmBNXYY+7runAKv0pLHMGi3QiCgMXmV8Sbqs0QaKiNeZoXi0gosj8ky7EcOcvv89SoPR7 vGn0Fe6FTZRM1CLJUSpcZknAYCmdCZ/p8FOSCEJD4wpedRuzp/yvShMCPJFaLb/xcSK70Rqg4 MavoUgssVbvfVd3MLNh+G5UcF51crxBJEOgcbhf29J28PRGveMMGFt2Twd+sBAr9E4bafoKox USDnjm3UUw8fqiH7C8slwiFNdNhc2JtRrqD3ZTNas+Qwbw+yLZ2SoASNth6h3KMa1sU+EjKI/ dV302u0BfSKGKvX1EtukxwatnhN/Ma5qXJeVmo+4nPnAqHcXfpgpv4zB7SjfhxGSlJO2ZD1s5 3mw/vojfRrmGqD7cBuIXXelG+VEWh0b/1CVvbb5sX+ztZHCbyIOdN6kSjJBUdPygLivWXeEnv 7b9+Z5TJeUTuKC8nHit1lbvytyaMfvE8eb/nB2mZL9+qYbrseX8l5NWiIbg1qQnY2Mgt5wRDq uEBcSfIhFUNFtkfVIb+6p6uh6bYuk+505kwP1UeavtHaEUx5ifTtl1k4jJ9Io7yxH9L6agivx /IiBGFuNknyePrsCNTdaCQE4YRsjNkoMyD2OufzLNoWiFqNryU= Archived-At: Subject: [Ace] draft-ietf-ace-dtls-authorize-01 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, 01 Oct 2017 09:35:17 -0000 [chair hat off] Hi all, I took a look at the draft and noticed a few minor things: - The document should talk about "profiles" rather than "profile" since it specifies at least two profiles, namely the RPK and the PSK profiles with DTLS. I suspect an implementation is only expected to implement one of them rather than both. - Editorial comment: most of the articles are missing, which makes the document harder to read. - AS discovery: Wouldn't the client need to know the AS upfront when using RPK and PSK (since it has to share a PSK with the AS or, in case of the RPK, has to have the RPK with the server exchanged out of band)? - There are two options provided for conveying the access token to the RS, either either a dedicated endpoint or inband within the DTLS exchange. There are pros and cons regarding the usage of both; is the idea to settle with one approach in the end or do you envision both options to be available in the final version of the specification. - Regarding the dynamic update of authorization information. Since the access token is a PoP token I believe you will have to demonstrate the possession of the key every time you change the access token. (Section 2.4 gives me a different impression.) - When the access token is conveyed inband in DTLS as part of the PSK_identity then the text on page 12 is applicable. The description in CDDL format confuses me. Normally, it should be quite simple: either you transmit a psk_identity field or you convey the access token. The server would figure it out. Is this just a complicated way to express this semantic or do you have something else in mind? (Btw, my understanding is that the server does not need to send a illegal_parameter alert when it the psk_identity does not lead to a successful authentication. Is this your suggestion or is this taken from TLS PSK?) - What is the reasoning behind this statement: "This specification mandates that at least the key derivation algorithm "HKDF SHA-256" as defined in [I-D.ietf-cose-msg] MUST be supported." I would have assumed at the session key provided by the AS to the client and the key embedded in the access token is used directly within TLS as a PSK. - Could you explain this statement: " If the security association with RS still exists and RS has indicated support for session renegotiation according to [RFC5746], the new Access Token MAY be used to renegotiate the existing DTLS session. In this case, the Access Token is used as "psk_identity" as defined in Section 4.1. The Client MAY also perform a new DTLS handshake according to Section 4.1 that replaces the existing DTLS session. " What are you trying to accomplish? Do you expect authorization information to change frequently? What security association are you talking about in the paragraph above? Ciao Hannes From nobody Sun Oct 1 02:35:24 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CADE813471B for ; Sun, 1 Oct 2017 02:35:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.501 X-Spam-Level: X-Spam-Status: No, score=-3.501 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fESoFkzxrLgg for ; Sun, 1 Oct 2017 02:35:18 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (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 4FC8F13471A for ; Sun, 1 Oct 2017 02:35:18 -0700 (PDT) Received: from [192.168.91.203] ([80.92.122.248]) by mail.gmx.com (mrgmx003 [212.227.17.190]) with ESMTPSA (Nemesis) id 0M9JYE-1eBCuo1ZmA-00CiDg for ; Sun, 01 Oct 2017 11:35:16 +0200 To: "Ace@ietf.org" From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <1f975851-9f8d-783d-07ea-e4d88309eacd@gmx.net> Date: Sun, 1 Oct 2017 11:35:15 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:HiPqFscbwXiAN9TgFoPYK0QWtLCbTQphfgoaILv1sEwhe/G3yGo x3aiiofD8H5kM7VV1IsAiq9ishYOmW1c9Zbz2YxegCWLz5E3WYHdMdZfPtHsTRWVii4a1Hp WrQF7nBbBiNw/WdhlXCJd2CMWtjwkB5XDYPyBvImmJmuFWzUMayIsMs48AXiEVSkNoBnMZ6 exuX2h7I9N1qXSd7jaX+A== X-UI-Out-Filterresults: notjunk:1;V01:K0:ZbP2nnywRWU=:8yMZu1Bfc7Oy3Xd03yfm8u 9m+UOdaLCrffpD/lYTrFRThrOkAUjPjxgVs5YPk6HekgmIS70mnUkmHLn7vKvhtrQ5InbTTpl S+ArdBUhg0+vcwP3Pa3NWtY+M8uy/YgMWkeMCVSlHJKffTQCem67HXqK1xEFmvrokB0nqW/gk Zc+PdsvcDI2rmEMRwiWiF3G2wkQPHDoJ4PPb7cju7HDtN90NNWpeqJRbCbPHzhB/mnZVZwnQp gUBTeJlV3oNR7G7tSdjQiFz9WS7UEJuUnNbfMASmaAx8cA1wbsm0WdwI24rWbGfUgxJkqDxcl 9bLnk+mOgyl24NzfziNSfqlE5LJasclIUoIc11nLVN0yAzUQrkdSCl4PUh3mBjTNOkAk5aVDv tgfAjyLN9OXCgkKLCTZQ4T3R47AKiNkQaJz45WipSDql5uEQeusMzU6D2i0/Z4AoXBS2rIWZa iQ64LErN0VFxzMImgHqstsXV0DlI1FexiO4YeoWPUrcZRTBXqbjJQIqg8E7sg9dNN9p+z9piX vcNgDdrJZaAtAFt5Vf87H5HD31c2aodaSyPdPjZPdHJh723kheAQzSUJBVNXWrfpL2PdfGklE EvWqc7VTgyQ2qYaFI/U6v+ciORb4SJFIHTO2FLcj8WKjoqHAnnQuFP0uxex0M9ucT8JdbCU9J 61idqlzDbUB3+gcBqBjQbn8y54BCCbME0qacKZTwQ6O7zjzWN7WuKIUR8YFNtU8TLXuNYlhrU 2qS+nY2etwS51+c5HhjRCtNEyWYkDsZc5VhIddRNSE7+4ZHHGvHnBb1wl+xxcXbfTRgivQzSp /D5DCKFmuzntH7KsWaZDe/GF4juODC+BYdPBgCGnBeZptrlF30= Archived-At: Subject: [Ace] draft-ietf-ace-oauth-authz X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Oct 2017 09:35:20 -0000 [chair hat off] Hi all, I believe there are a few changes necessary for draft-ietf-ace-oauth-authz in order to complete it and I am wondering what the rest of the group thinks. 1) We have seen various contributions that want to use the ACE framework for protocols other than CoAP. Still, the framework document focuses on CoAP. I believe we should make it more generic by saying that there are profiles using CoAP and others that don't. There shouldn't be anything wrong with it. 2) There are various references to OSCOAP in the document and I believe they are misleading since the framework does not depend on nor even use OSCOAP. 3) The "Client Token" is somewhat experimental and not on par with the rest of the document in terms of maturity and alignment with OAuth. I would prefer this functionality to be covered in a separate document, if someone still cares about it. While OAuth has seen a lot of formal analysis this feature obviously hasn't. It should be clear from the description that it is underspecified and currently insecure. For example, it is not clear how the AS determines freshness of the authentication request. Thoughts? Ciao Hannes From nobody Sun Oct 1 02:40:05 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 237AA134707 for ; Sun, 1 Oct 2017 02:40:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.701 X-Spam-Level: X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, FREEMAIL_FROM=0.001, 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 yCPzVRxLfiSF for ; Sun, 1 Oct 2017 02:40:02 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (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 99177134706 for ; Sun, 1 Oct 2017 02:40:01 -0700 (PDT) Received: from [192.168.91.203] ([80.92.122.248]) by mail.gmx.com (mrgmx001 [212.227.17.190]) with ESMTPSA (Nemesis) id 0LZzKf-1dbbAQ2FET-00loou for ; Sun, 01 Oct 2017 11:39:59 +0200 To: "Ace@ietf.org" From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: Date: Sun, 1 Oct 2017 11:39:58 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:ltrBMxObrZvVJ1821YLmKb6aRg2tagCMjPXw4F/9AtM9kcLBq6E U2V6txjN9sg6qoizYlE47XSKt0VYqZpW9m/Z7H0EK/zrpyVyVJUhv5U/V9Nutx1NYiksnir LpXVcmbICZu8FvbolMlM8l/F+QLpeij7KGcNW1fFVczQalDkbS/VC8D/pe2CkeOQ5eLW5Z3 u60sYnI7sKNqG6nT6D+jA== X-UI-Out-Filterresults: notjunk:1;V01:K0:xeIidVxBYaw=:8Kst+ouhwXYQUTPAsItd9o 8HnF3UG4IafhWvg9P6fJlwe41e1m3R7MZOOXopLzU0owSq7kBDNBK4vJ10AdGAzn8dOCYFkOE wZUXMfGME06coJe20b9NYaCVXXelr+aDW6/hOO7LzW2Il0YeFilxSk6d1dYbN7ADusZDgnYGA S/vuphVUIlC1zOO8ZbUIVNFpRJ6Fz5/4BG0qJSsryTjPIvVi4UYrSkCv44vYEsol0HVyOFo5/ u2X4MkgEvKNwV31MuTbGS4aalWtfSJaiw90o4DUfTiCTpl5rOih9ZhP5R20qR8zPNKwezwuqk Peo8OsRc+vFq8hG1FZMHEI3nBqG3X0tANaEyN0ot2dJZHiFzMI8BJEX3YyurDPYn5kHaTlrRh FiXiOkDwofdwUxlXogq6e2ISrmT5CzJNjVxQYMoeY2fcFLd1T2bT7MFhYBNEf3xBieI32DeJ+ jnWEcVdy0YGVJ9aWIHO2eHDp5dFSwmCsKAEl5Pw1wrzKWF+kRXxbflhGz4gnI0F4LS550+K6n QxQKY8tkI/knE7UK5NOmXBX5QXy6ZM98Lm05gl/viTqpRb983IU4/sMfwg7l3VVZ9FE11qp0j pjC1tVRRgC5IKgTqoJAgO88Orpv53kz42T+k7/cppOCxVvC0FuivEYd322hKK+a8Wz+ao5pOi n8e9gWXf5ohhrK+gI8Gf4qjmcKEeFkue4+4FvhiDcqfVIkxA1+XhCq4Rtq9gnhxDnShOc2NIX jwOPrdGAbqNegi8odZwOX4AbhnEpXKNfqadwL+Z7ebz8P7ox/G3npyAG/lHEr6eYCDejOeVRD OxSmUFcJPPyA8US19msKPRlP2Km6qiWXv5F349zbAKn4CrtMwo= Archived-At: Subject: [Ace] draft-ietf-ace-cbor-web-token-08 / 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: Sun, 01 Oct 2017 09:40:03 -0000 [Chair hat off] Hi all, after reading draft-ietf-ace-dtls-authorize I was wondering how the RS determines what key to use to decrypt noticed that none of the examples in draft-ietf-ace-cbor-web-token-08 and in draft-ietf-ace-cwt-proof-of-possession use some form of key id to allow finding the appropriate key. Maybe I overlooked it or was this intentional? Ciao Hannes From nobody Sun Oct 1 02:47:08 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AADD13474C for ; Sun, 1 Oct 2017 02:47:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lEasV8ZNnFQr for ; Sun, 1 Oct 2017 02:47:04 -0700 (PDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0133.outbound.protection.outlook.com [104.47.33.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC062134726 for ; Sun, 1 Oct 2017 02:47:04 -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=wFcbE+qMdCMfjoqpYdGo+V6P+3Uax3uS6Nq1w6Vrd0g=; b=V/4I5eiqZwBXuyQq3ZYNA4LtZUucUlHlZOwwI7yHCdikoRYbG06D9dvSzZ8IH6nvacXhvYkL8EwyuFbUCtMi/Ax798NDFoxnwR9zko3+XbjIP/mwdVQVoYW48VpoUin+xwgeNwBnhiqdKAYQjtfhAxhW4GEPCekxuAMJoT5/NVU= Received: from BN6PR21MB0500.namprd21.prod.outlook.com (10.172.112.10) by BN6PR21MB0131.namprd21.prod.outlook.com (10.173.199.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.122.0; Sun, 1 Oct 2017 09:46:59 +0000 Received: from BN6PR21MB0500.namprd21.prod.outlook.com ([10.172.112.10]) by BN6PR21MB0500.namprd21.prod.outlook.com ([10.172.112.10]) with mapi id 15.20.0122.000; Sun, 1 Oct 2017 09:46:58 +0000 From: Mike Jones To: Hannes Tschofenig , "Ace@ietf.org" Thread-Topic: [Ace] draft-ietf-ace-cbor-web-token-08 / draft-ietf-ace-cwt-proof-of-possession Thread-Index: AQHTOplG2xEGxTnRSUihGtaGaAfmDaLOvcug Date: Sun, 1 Oct 2017 09:46: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-originating-ip: [121.7.33.159] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN6PR21MB0131; 6:7kdZ/aQ073TQGnwxWqn6GO9BmxKIcocW0D56VBYvW6gzLrBr0Ms34W0i+5cpq1f99RD1Eu3cq+DC/MBWV3g0pU1sIKQcShNrSUMdor+O14jI4ETKzWdj9oighW63NwESMmxnpaNnPFtWkpMWhe02fmQJtEBe5hBVomH9yb0VqHaPv8+5wBEV+CJn+RfUykHEMk4v38CIH9CNKj3BT7Gmu2OhseXuIbEDjF5VY2r90e2yFkouL2atCYN13w07hovJ2RFtifvLYjBoAktnfk1BDii0guVmxo49XwUrIlsGvrj8zPih2m9vVb08VsYI394773uiLCYuOs7YjG24V2+X9w==; 5:lcf1UV6/hJ+oGFhic4dFrGxdCe7v51ABorqQ1taHKQuqc6npf3fuxasgEeoNPP96NPuCmsrBNGvhJh7rDxz/zMliRrYecC5MiToLU7kbdaVzUca49T7RRUrUv3FmxJCR6qkGCGPChRRG/2pF3Xhjkg==; 24:Oonkh3KYfOOvZHsPHd4ZbOvgo4Hhl7c5NStlQ1E0WiUh75CQa5mToyBz73uzctTmfZcvAtmPbLf1RSHJNMuwJhUNoQET5wvEQojByjS/eYA=; 7:vuzFx1vLkSc8uYdmTalqC+ya50+Oph+wGs2ZbJcN68DEOh+v70PBZIQa5jSxmI58te3JkcRSOC68L2mA5DIOpX9xIjwImXrZNPRtNeFRITI/94dtDWbzDapNf6K/ESusdTIt5Y0DuDXOyf3lv5G6fbZOB6W5t6Yelx//EyMFSADPrGWtM8lN3aOR8gg8ph5Ew85HtR8rXSGw4NFoQ4TPOgAazTWi8DnOlDjKe4ouvug= x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 685f9119-ed7a-41c2-f778-08d508b15c11 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(48565401081)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:BN6PR21MB0131; x-ms-traffictypediagnostic: BN6PR21MB0131: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-exchange-antispam-report-test: UriScan:; x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(2401047)(5005006)(8121501046)(12181511122)(10201501046)(3002001)(100000703101)(100105400095)(93006095)(93001095)(6055026)(61426038)(61427038)(6041248)(20161123555025)(20161123560025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN6PR21MB0131; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN6PR21MB0131; x-forefront-prvs: 0447DB1C71 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(376002)(346002)(47760400005)(199003)(53754006)(13464003)(189002)(377454003)(5660300001)(189998001)(3846002)(86362001)(9686003)(2906002)(99286003)(55016002)(110136005)(53936002)(68736007)(66066001)(14454004)(8990500004)(2501003)(316002)(10090500001)(2950100002)(2900100001)(22452003)(101416001)(7736002)(97736004)(6246003)(6306002)(53546010)(305945005)(33656002)(72206003)(54356999)(76176999)(74316002)(86612001)(966005)(6116002)(25786009)(50986999)(230783001)(478600001)(102836003)(6436002)(77096006)(8936002)(106356001)(105586002)(229853002)(3660700001)(6506006)(3280700002)(7696004)(8676002)(10290500003)(81166006)(81156014); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR21MB0131; H:BN6PR21MB0500.namprd21.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 685f9119-ed7a-41c2-f778-08d508b15c11 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Oct 2017 09:46:58.8770 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR21MB0131 Archived-At: Subject: Re: [Ace] draft-ietf-ace-cbor-web-token-08 / 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: Sun, 01 Oct 2017 09:47:07 -0000 Section 3.4 of https://tools.ietf.org/html/draft-ietf-ace-cwt-proof-of-poss= ession-00 defines how to use a key ID to select the PoP key. Section 3.1 o= f https://tools.ietf.org/html/rfc8152 defines using a key ID to select keys= for the COSE operations. CWT doesn't need to talk about key IDs because t= hey inherit this functionality from COSE. A key ID example could be added to https://tools.ietf.org/html/draft-ietf-a= ce-cwt-proof-of-possession if people want one. But the functionality is al= ready there. Thanks for reviewing these specs! -- Mike -----Original Message----- From: Ace [mailto:ace-bounces@ietf.org] On Behalf Of Hannes Tschofenig Sent: Sunday, October 1, 2017 2:40 AM To: Ace@ietf.org Subject: [Ace] draft-ietf-ace-cbor-web-token-08 / draft-ietf-ace-cwt-proof-= of-possession [Chair hat off] Hi all, after reading draft-ietf-ace-dtls-authorize I was wondering how the RS dete= rmines what key to use to decrypt noticed that none of the examples in dra= ft-ietf-ace-cbor-web-token-08 and in draft-ietf-ace-cwt-proof-of-possession= use some form of key id to allow finding the appropriate key. Maybe I overlooked it or was this intentional? Ciao Hannes _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace From nobody Mon Oct 2 01:40:33 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A539A1344F9 for ; Mon, 2 Oct 2017 01:40:32 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 ngp6i0htK5C7 for ; Mon, 2 Oct 2017 01:40:30 -0700 (PDT) Received: from mail-pg0-x22c.google.com (mail-pg0-x22c.google.com [IPv6:2607:f8b0:400e:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BCF71344EE for ; Mon, 2 Oct 2017 01:40:30 -0700 (PDT) Received: by mail-pg0-x22c.google.com with SMTP id s184so993083pgc.0 for ; Mon, 02 Oct 2017 01:40:30 -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=uP6rP/D4+WSQu4ZYS0fCf7PzWVrDT6A4DukUxR2v9uo=; b=sLBRS3J1n7RgaYe7RLwx4Tk1Mmrw33BbzjjOdCiiJ8ylLYzgiQofady66d7n4h+mcI sj2pLoX5zN3nBY8kDuSgr1xDlL2nKA6LtXbPIWSI35fwVEiqQ3sMT3gha7KibFkbN7dC ZWqxmU24crOTR3ZZbAZQELGs+7fAexDmGc0Io1xu0O5CPp5JOcRZpB57QrwTz/IL8h/K vp8Apl/3N8ohoaW7hOTfcSBJQ1mhRf0knJQudsC//PTivRhk7W6tZkOPcnACfryHbwLq 1Yv2Klo7r0QefVFD8tfiqHpd7HYZGU77yVpMCYy1GJjU9qz5QDXJvXqM+YEdt8UQOBp7 0kEg== 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=uP6rP/D4+WSQu4ZYS0fCf7PzWVrDT6A4DukUxR2v9uo=; b=ZkBgORrzE7Q0eBjfEZYmpp9AWS8GnzZLET+IO+7/V9ZkRCeJpYDMPCS0B0DRlsy7Hi ptYOlETuyCG5JUoc/1gIIb8TGnTsFNPSWO2xduZbNE0mza80/5b9je4p7s2/uqvbkqCG M2H8UHxGpGCikdIKP8nh12pY7yPYIQWqPt+D5/rMkrNrn4f1DpZvAYSmXyoV7boM40DU 4ZCnnJZXSO1qOIHLVOaDIRDwTOdHyvILNcIVxo4Zt302HOZ2t3+fayVB46AY3xWTjK96 rpXxJKC5JmJLMYsScSv4QZGHEYCLi6ea1vT/n3IGE9h2NFmOq3+eYf9G7Uagwkn94tDe 3Tvw== X-Gm-Message-State: AMCzsaX3BIbv8uGOxgCHLXKFGCjkL9IAvkYsHFKgsmEffKh7qz/AgsRc 6GpFQQGKPkyGB7ww0C5fqdrlqN8OEtFVQ92fOzbq/lZ7sgk= X-Google-Smtp-Source: AOwi7QB9x1/kMwHnVla8d6ooEDbtv/JAoPTVOBHkqq5U5DHLHOXqcCBHevWUy96Nxrqgj31oFPO3rNZCheSyCL65ci4= X-Received: by 10.98.202.194 with SMTP id y63mr2279445pfk.325.1506933629599; Mon, 02 Oct 2017 01:40:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.143.170 with HTTP; Mon, 2 Oct 2017 01:40:29 -0700 (PDT) In-Reply-To: References: From: Samuel Erdtman Date: Mon, 2 Oct 2017 10:40:29 +0200 Message-ID: To: Hannes Tschofenig Cc: "Ace@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c0a4354b1845c055a8c530b" Archived-At: Subject: Re: [Ace] draft-ietf-ace-cbor-web-token-08 / 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, 02 Oct 2017 08:40:32 -0000 --94eb2c0a4354b1845c055a8c530b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Hannes, This is how I think it should be done. There are two keys that needs to be identified, the key to verify the CWT and the key to use for the DTLS handshake. When it comes to verifying the CWT, it is the AS key that should be used. I don=C2=B4t think it is unreasonable to assume that the AS uses the key that= it agreed on with the RS on during device configuration, i.e. the RS only have one key for verifying that the token was issued by the trusted AS. If RS has multiple keys associated with an AS or trusts multiple ASs then it would be recommendable to use the COSE kid ( https://tools.ietf.org/html/rfc8152#section-3.1). It is unfortunate that we don=C2=B4t have such example in the CWT draft. I can add it if others agree= . The second key is the one bound to the token to be used in the DTLS handshake. This is what draft-ietf-ace-cwt-proof-of-possession is all about. There are three different options to bind a key to the CWT, the COSE_key, the encrypted COSE key and the raw kid. In the cases where COSE key is used I expect the kid field in that object to be used. Regarding the examples they are still in an early stage, and this is good input. Hope this gave some clarity. //Samuel On Sun, Oct 1, 2017 at 11:39 AM, Hannes Tschofenig < hannes.tschofenig@gmx.net> wrote: > [Chair hat off] > > Hi all, > > after reading draft-ietf-ace-dtls-authorize I was wondering how the RS > determines what key to use to decrypt noticed that none of the examples > in draft-ietf-ace-cbor-web-token-08 and in > draft-ietf-ace-cwt-proof-of-possession use some form of key id to allow > finding the appropriate key. > > Maybe I overlooked it or was this intentional? > > Ciao > Hannes > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > --94eb2c0a4354b1845c055a8c530b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Hannes,

This is h= ow I think it should be done.

There are two keys that needs to be id= entified, the key to verify the CWT and the key to use for the DTLS handsha= ke.

When it comes to verifying the CWT, it is the AS key that = should be used. I don=C2=B4t think it is unreasonable to assume that the AS= uses the key that it agreed=C2=A0 on with the RS on during device configur= ation, i.e. the RS only have one key for verifying that the token was issue= d by the trusted AS. If RS has multiple keys associated with an AS or trust= s multiple ASs then it would be recommendable to use the COSE kid (https://tools.ietf.org= /html/rfc8152#section-3.1). It is unfortunate that we don=C2=B4t have s= uch example in the CWT draft. I can add it if others agree.

Th= e second key is the one bound to the token to be used in the DTLS handshake= . This is what draft-ietf-ace-cwt-proof-of-possession is all about. There a= re three different options to bind a key to the CWT, the COSE_key, the encr= ypted COSE key and the raw kid. In the cases where COSE key is used I expec= t the kid field in that object to be used. Regarding the examples they are = still in an early stage, and this is good input.

Hope this gav= e some clarity.
//Samuel





On Sun, Oct 1, 2017 at 11:39 AM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:
[Chair hat off]

Hi all,

after reading draft-ietf-ace-dtls-authorize I was wondering how the RS
determines what key to use to decrypt noticed that none of the examples
in=C2=A0 draft-ietf-ace-cbor-web-token-08 and in
draft-ietf-ace-cwt-proof-of-possession use some form of key id to allo= w
finding the appropriate key.

Maybe I overlooked it or was this intentional?

Ciao
Hannes

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

--94eb2c0a4354b1845c055a8c530b-- From nobody Mon Oct 2 01:47:34 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5873C134504 for ; Mon, 2 Oct 2017 01:47:33 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 7MwJrPPa5RaC for ; Mon, 2 Oct 2017 01:47:31 -0700 (PDT) Received: from mail-pf0-x236.google.com (mail-pf0-x236.google.com [IPv6:2607:f8b0:400e:c00::236]) (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 50B57134509 for ; Mon, 2 Oct 2017 01:47:31 -0700 (PDT) Received: by mail-pf0-x236.google.com with SMTP id l188so2598426pfc.6 for ; Mon, 02 Oct 2017 01:47:31 -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=7YYcQyh0dhmxg6RGtV4xTrfC+DPldeWZ422NR1/diM4=; b=ghaU0JcuLAkLqMI5MQQoGdYZIeoLIcv5Bc4DyDfWRQx0to5hPLUyo8DkOzCXCMR2No vp7TpJDPG/6yLCYjKIELCzx6sckMPH3yFAo2eh8oZxs/IHO6ltVakixUsHcvQs15s5R0 9oOlExAl5db4ayhElS5dNo6XOLRulJ73rUQcjo9C62ycAASRjUpQf9R88dXuwO7gXJhh qmmq/+BWek9XWoVWKnWxrBdEY3r6f1vujKOvc4vy01bX1Ekalr4VEmJdf/TrMO6b92ms SSvJ+LpWm8jHaErHBYKXhxnWI4wRKOg3Hap1TWG+KZJN2cE1pZPbkad9V3+Z47TSUL7Z zftQ== 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=7YYcQyh0dhmxg6RGtV4xTrfC+DPldeWZ422NR1/diM4=; b=OcFfSOeQe6/7HJC4e3AtFGmBdLikWAU58wtEUuvb7Wwh7aKCob2p89EagoDc1u47vc eJSZ3NuhVIOr+FgUoSag99nlwrhgjuK2LiHI3h4wP+NVSjQSoBebJUtiN5KJiCiwu2W6 OYFK+FxwKWj9q6mo9REws8F5vfYvcXT38bh8cDypKz7cbg6gmtN2dPA2JOpnPq6DXvWg C9aWDV6X+PpEdYipQ1d56D+o5r01JuuOhYkPeeyNnsdY6f4JJMyRsr+iANz/zyq2FVxM Z2iwJVpeAo8JJYo8qzgBnK3tYU57Otz9kJcHKxyQ/GxrTf+wSBBUSIRQ1yBNIyKuY0E9 gUww== X-Gm-Message-State: AHPjjUhRkVuLrg/rWANieoYs01oQ06+RIM9WK2PXGrF/HUmHSTC87tfB UXjhQfoXKZn7YstJSfEUa5VPc1+jEGTmss7wjWuCPQ== X-Google-Smtp-Source: AOwi7QDeZcoOKmuCntGsIiLTEaaYrCgxapFRpy7OB85+xa27d+KNOzEANqTi6IMteOR6tjkue9iCD/y4TzW1Rp6dUMA= X-Received: by 10.84.233.69 with SMTP id k5mr13808007plt.260.1506934050878; Mon, 02 Oct 2017 01:47:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.143.170 with HTTP; Mon, 2 Oct 2017 01:47:30 -0700 (PDT) In-Reply-To: <1f975851-9f8d-783d-07ea-e4d88309eacd@gmx.net> References: <1f975851-9f8d-783d-07ea-e4d88309eacd@gmx.net> From: Samuel Erdtman Date: Mon, 2 Oct 2017 10:47:30 +0200 Message-ID: To: Hannes Tschofenig Cc: "Ace@ietf.org" Content-Type: multipart/alternative; boundary="089e08213d0ccd85c4055a8c6c6c" Archived-At: Subject: Re: [Ace] draft-ietf-ace-oauth-authz X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Oct 2017 08:47:33 -0000 --089e08213d0ccd85c4055a8c6c6c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable My thoughts inline On Sun, Oct 1, 2017 at 11:35 AM, Hannes Tschofenig < hannes.tschofenig@gmx.net> wrote: > [chair hat off] > > Hi all, > > I believe there are a few changes necessary for > draft-ietf-ace-oauth-authz in order to complete it and I am wondering > what the rest of the group thinks. > > 1) We have seen various contributions that want to use the ACE framework > for protocols other than CoAP. Still, the framework document focuses on > CoAP. I believe we should make it more generic by saying that there are > profiles using CoAP and others that don't. There shouldn't be anything > wrong with it. > Agree, but I think it is good if we can have examples in some way and CoAP is a well known option that people are familiar with. > > 2) There are various references to OSCOAP in the document and I believe > they are misleading since the framework does not depend on nor even use > OSCOAP. > The references (I can find two) to OSCOAP are informal and uses OSCOAP as an object security example. I don=C2=B4t think this is a big issue but I=C2= =B4m okay with removing these references too. However I do think examples improves readability. > > 3) The "Client Token" is somewhat experimental and not on par with the > rest of the document in terms of maturity and alignment with OAuth. I > would prefer this functionality to be covered in a separate document, if > someone still cares about it. While OAuth has seen a lot of formal > analysis this feature obviously hasn't. It should be clear from the > description that it is underspecified and currently insecure. For > example, it is not clear how the AS determines freshness of the > authentication request. > Agree, I think client token should be split out to a separate document so that the framework can proceed. > > Thoughts? > > Ciao > Hannes > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > --089e08213d0ccd85c4055a8c6c6c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
My thoughts inline

On Sun, Oct 1, 2017 at 11:35 AM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:
[chair hat off]

Hi all,

I believe there are a few changes necessary for
draft-ietf-ace-oauth-authz in order to complete it and I am wondering
what the rest of the group thinks.

1) We have seen various contributions that want to use the ACE framework for protocols other than CoAP. Still, the framework document focuses on
CoAP. I believe we should make it more generic by saying that there are
profiles using CoAP and others that don't. There shouldn't be anyth= ing
wrong with it.

Agree, but I think it is= good if we can have examples in some way and CoAP is a well known option t= hat people are familiar with.
=C2=A0

2) There are various references to OSCOAP in the document and I believe
they are misleading since the framework does not depend on nor even use
OSCOAP.

The references (I can find two)= to OSCOAP are informal and uses OSCOAP as an object security example. I do= n=C2=B4t think this is a big issue but I=C2=B4m okay with removing these re= ferences too. However I do think examples improves readability.
=C2=A0

3) The "Client Token" is somewhat experimental and not on par wit= h the
rest of the document in terms of maturity and alignment with OAuth. I
would prefer this functionality to be covered in a separate document, if someone still cares about it. While OAuth has seen a lot of formal
analysis this feature obviously hasn't. It should be clear from the
description that it is underspecified and currently insecure. For
example, it is not clear how the AS determines freshness of the
authentication request.

Agree, I think = client token should be split out to a separate document so that the framewo= rk can proceed.
=C2=A0

Thoughts?

Ciao
Hannes

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

--089e08213d0ccd85c4055a8c6c6c-- From nobody Mon Oct 2 02:12:09 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAAAA134517 for ; Mon, 2 Oct 2017 02:12:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.019 X-Spam-Level: X-Spam-Status: No, score=-2.019 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D_-nVCg15_BM for ; Mon, 2 Oct 2017 02:12:01 -0700 (PDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0130.outbound.protection.outlook.com [104.47.33.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99EAC13448C for ; Mon, 2 Oct 2017 02:12:00 -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=v7vt8cbDbRn5+pKMNql7ejk62cmzV8HKqLVOyMTAscA=; b=QlgWwhIep2UT8XQHEVkTwuQa+EFwNF3wb/QkeOoM0QShFUGV4Qas4R0uZZpY3E1M81pbti1FKSqyQ2pdagBngLMcfo+cWLxxAdW9cWRniJSFMDPNk+Dl7TUNQnrx27RVoUPZrj1gwCHcU2bd06vVZTRUNJjvOFoaakO2Z02Q7EA= Received: from CY4PR21MB0504.namprd21.prod.outlook.com (10.172.122.14) by CY4PR21MB0854.namprd21.prod.outlook.com (10.173.192.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.98.3; Mon, 2 Oct 2017 09:11:57 +0000 Received: from CY4PR21MB0504.namprd21.prod.outlook.com ([10.172.122.14]) by CY4PR21MB0504.namprd21.prod.outlook.com ([10.172.122.14]) with mapi id 15.20.0122.000; Mon, 2 Oct 2017 09:11:58 +0000 From: Mike Jones To: "ace@ietf.org" CC: Ludwig Seitz , =?iso-8859-1?Q?G=F6ran_Selander?= , =?iso-8859-1?Q?Erik_Wahlstr=F6m?= , Samuel Erdtman , "Hannes Tschofenig" Thread-Topic: Review of draft-ietf-ace-oauth-authz-07 by Mike Jones Thread-Index: AdM7W6CQJNWkaDadRS6XI7KhPAdRmQ== Date: Mon, 2 Oct 2017 09:11:57 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [121.7.33.159] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR21MB0854; 6:nSZiNEDM9YbKKy8MXA3Syg8j9G5Vh+hXCQC8pB1tYtaPdYfO5ejNfeApKUi74gZ78Tm5XYZCMd0RX7v1JhQsdm/ZGIzBxYaEdAWErbsCUjs/0aMlz6p+HF9dk4oJCoM+VBbijmG02NX0YG2qEVwoUe73K6N6c3MKC9s3qyq1omfRaGilRJftq8VglnfLjWdi6QWgsbzd27w350guTD+7VKLrNXyk9ykFgSdJEX9XvD56AIrPV4EF1mTesFrIfmG+AEo8WFa4dLXCGXy3jtvxyswoyeuLAZdcQJOsIOMMYTVTvXDfhl9ZyqUGYNLHlXgdzyaGUXVwN30hgLivQiQPTw==; 5:ZiAToy0L7y0klAU3gx84XUgEeiP/Q924vAWfSslCC0E03Boh6MP5i2qahFhBYMnfdnPAu2i8fLrx20JsRNUP+Mx16Wftu4dgQd4kOMJwgMB0HnXVZlqIRKVJOfj4ombSaxN/KxjJT0KnAMfTr+uqINoK4cQ/mrQ8/X5yNBiy6E0=; 24:KktavfhRBt0RbFxeue+gHHaTQm1G91d+syKjo1EdpGb49UAzkoX5WnxfVWvqUm6987XMhhfwhxRFVZlnnMsAXYz7U9ygTjOTNqB+uPLluuw=; 7:ORmmxf8VCyl13ZCI3W1bJlcOBA34sW+dTEbFKDWONssA0IEldQfupqxUd7enX0x/aOqbk/5C1/lggLi03D6GQRka8KdsL87g4UHWgoqDvlhZXz0oTie7Z2vsXJfzMBQd+lbZuCMJwvXqUkdrB+m7zglsOfgICCuusW/LAU+2KeVN3Bm8Pn+Gi69lPPj2MWBbro5ce6UOQzQVmGvNXz/5q1FMyNjN+6J2G2tiIsDZGxI= x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: d402634b-d49b-40d6-ae7c-08d50975a242 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(48565401081)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:CY4PR21MB0854; x-ms-traffictypediagnostic: CY4PR21MB0854: x-ld-processed: 72f988bf-86f1-41af-91ab-2d7cd011db47,ExtAddr x-exchange-antispam-report-test: UriScan:(158342451672863)(166708455590820)(192374486261705)(788757137089)(21748063052155)(21532816269658)(1591387915157); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(100000703101)(100105400095)(12181511122)(10201501046)(3002001)(6055026)(61426038)(61427038)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123558100)(20161123555025)(20161123560025)(20161123562025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR21MB0854; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR21MB0854; x-forefront-prvs: 0448A97BF2 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(376002)(39860400002)(47760400005)(189002)(199003)(6306002)(102836003)(230783001)(99286003)(55016002)(4326008)(66066001)(53946003)(2900100001)(53936002)(81166006)(8676002)(790700001)(3846002)(54906003)(14454004)(7696004)(3660700001)(54356999)(6916009)(54896002)(8936002)(236005)(1730700003)(10090500001)(9686003)(22452003)(50986999)(2906002)(316002)(68736007)(5660300001)(189998001)(86362001)(105586002)(3280700002)(86612001)(106356001)(2351001)(8990500004)(81156014)(6116002)(74316002)(7736002)(97736004)(33656002)(101416001)(6506006)(966005)(5640700003)(77096006)(10290500003)(2501003)(25786009)(6436002)(5630700001)(606006)(478600001)(72206003); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0854; H:CY4PR21MB0504.namprd21.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; 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; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR21MB0504D057E5B47ED166F35083F57D0CY4PR21MB0504namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Oct 2017 09:11:57.9645 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0854 Archived-At: Subject: [Ace] Review of draft-ietf-ace-oauth-authz-07 by Mike Jones 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, 02 Oct 2017 09:12:08 -0000 --_000_CY4PR21MB0504D057E5B47ED166F35083F57D0CY4PR21MB0504namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Having read the spec cover-to-cover, it surprised me how different this is = from OAuth, despite the statements that it is based on OAuth. My highest-p= riority request is to make all the extensions to OAuth defined in this docu= ment optional, so that profiles could use actual OAuth, which currently doe= sn't seem to be possible. Much of this draft written in a way that huge OA= uth extensions are obliquely assumed when describing other features, withou= t any clear definitions or justifications for them when they are introduced= in passing. These things need to be teased apart, with references to sect= ions actually defining and justifying each extension, rather than assuming = that many of them exist in passing in other sections. Detailed substantive comments on specific document text follow. Editorial = nits are communicated in the accompanying pull request https://github.com/L= udwigSeitz/ace-oauth/pull/112. Title The current title "Authentication and Authorization for Constrained Environ= ments (ACE)" doesn't match the scope of what's in the spec, as the spec is = only about resource authorization but not authentication. Please change th= e title to "Resource Authorization Framework for Constrained Environments" = or something similar. (Authentication would require defining the equivalen= t of an OpenID Connect ID Token to convey authentication information, but t= his is entirely absent from the specification.) 1. Introduction The introduction defines what it means by "authorization" by doesn't say wh= at it is referring to by "authentication". This provides more evidence tha= t "authentication" does not belong in the title or abstract. Please remove= the passing references to the underspecified concept "authentication" from= the introduction and the abstract. (Note that while "OAuth client authent= ication" is a limited form of authentication, its use as a mechanism in the= spec does not justify saying that the spec is defining authentication for = its use cases in any general sense of the term.) 2. Terminology The "/" syntax for endpoint names, such as "/token" is misleading, as it se= ems to imply that these endpoints use particular pathnames. Please replace= all uses of "/endpoint-name" with just "endpoint-name". 2. Terminology References are needed for the first uses of many of the terms and abbreviat= ions used. For instance, you're using abbreviations like "AS", "RS", and "= IoT" without saying what they refer to. 2. Terminology Please change all uses of the word "introspect" to "introspection" when ref= erring to the introspection endpoint. 2. Terminology You introduce an "authz-info" endpoint in the terminology section, when thi= s isn't commonly understood. You need a section reference following the fi= rst use of this concept. 3.1 OAuth 2.0 - token and introspect endpoints This section is the first of many places in which the text is written in a = way that assumes that introspection will be implemented and used. This nee= ds to be corrected throughout the document, appropriately qualifying descri= ptions of introspection saying that some profiles may use it and others wil= l not. For instance, the draft says "The token introspection endpoint, /in= trospect, is used by the RS when requesting additional information regardin= g a received access token." Please change this so something more like "In = some profiles, a token introspection endpoint may be present and used by th= e RS to request additional information about a received access token." You= should also clearly state that introspection is unnecessary and adds overh= ead that can be avoided when the resource server understands the access tok= en format, such as when it is a CWT. 3.1 OAuth 2.0 - Proof of Possession Tokens The draft uses the term "proof of possession token" to denote an access tok= en supporting proof of possession. Note however, that there are many other= kinds of proof of possession tokens other than just access tokens. Please= change all uses of the term "proof of possession token" to "proof of posse= ssion access token" or "access token supporting proof of possession". Simi= larly, change all uses of the term "PoP token" to "PoP access token". 3.1 OAuth 2.0 - Scopes and Permissions This section contains another example of an extension to OAuth being assume= d, when for many profiles it won't be necessary. The draft says "In turn, = the AS may use the scope response parameter to inform the client of the sco= pe of the access token issued." This assumes that a "scope" response will = be added to all participating OAuth implementations, without justifying thi= s addition to the standard. At most, this section should refer to another = section which defines an optional "scope" response parameter and describes = the circumstances in which profiles would and would not need it. 3.1 OAuth 2.0 - Scopes and Permissions Likewise, the draft says "As the client could be a constrained device as we= ll, this specification uses CBOR encoded messages for CoAP". This is one o= f many places in the draft that it's assumed that CBOR and COAP will be use= d rather than JSON and HTTP. The framework draft should explicitly leave t= hese choices up to profiles. 4. Protocol Interactions Please do not in any way endorse using the Client Credentials grant - which= defeats the purpose of even having OAuth. The client should never have th= e user's credentials! At most, you should say that while the Client Creden= tials grant may be used for some scenarios, it has known security and priva= cy flaws and its use is deprecated. 4. Protocol Interactions The sentence "In such a case the resource owner or another person on his or= her behalf have arranged with the authorization server out-of-band, which = is often accomplished using a commissioning tool." needs clarification. Wh= at has been arranged? Figure 1: Basic Protocol Flow This is yet another place where a major OAuth extension is assumed, without= clear justification. The diagram adds "+ RS Information" to the authoriza= tion server response to the client, when this isn't a normal part of OAuth = and not defined. At least, please indicate that this is optional and refer= to a section that defines and justifies this optional extension, rather th= an assuming in passing that it's been added. Figure 1: Basic Protocol Flow Please rework this diagram to illustrate that introspection is optional (an= d wastes resources by performing unnecessary communication). 4. Protocol Interactions - Access Token Response This also assumes the existence of "RS Information". At least, say that "S= ome profiles may choose to return information about the resource servers" a= nd reference a section describing this optional feature, rather than write = the text in a way that assumes its existence. 4. Protocol Interactions - Access Token Response This also assumes the existence of profile information in the response. Th= is would normally be implicit. Again, please do not write the draft in a w= ay that assumes the presence of extensions that are often not needed. 4. Protocol Interactions - Resource Request The two-part request described in the third paragraph is not OAuth, nor is = there any justification for adding additional steps. Likewise, the languag= e in paragraph 4 about "comparing the claims in the access token with the r= esource request" is a highly specific extension that is not normal OAuth. = Please refactor this description to clearly delineate what's OAuth and what= are optional extensions - referencing specific sections that define these = extensions. 4. Protocol Interactions - Token Introspection Request Please rework this section to describe that introspection is optional (and = wastes resources by performing unnecessary communication). Describe how th= ings are simpler and more efficient when the resource directly understands = the contents of the access token. 4. Protocol Interactions - Token Introspection Response This section adds yet another OAuth extension on the fly - the "client toke= n" - again with no justification or clear definition. Please remove the ob= lique "client token" reference here. 5. Framework - Proof-of-Possession After "The binding is provided by the "cnf" claim" add references to [RFC 7= 800] and [draft-ietf-ace-cwt-proof-of-possession]. 5. Framework - Proof-of-Possession The text currently includes "update a token". Shouldn't this actually be "= get a new token", since an existing access token can't be updated? 5.1 Authorization Grants This section includes the phrase "client credentials grant is recommended".= Because of the security and privacy problems with the client credentials = grant, please rework this section to ensure that implementers and profile w= riters understand that the use of client credentials grant is never recomme= nded, including describing why that is the case. 5.1 Authorization Grants Reference [RFC 6749] after you say "see the OAuth 2.0 framework". 5.2 Client Credentials After you say that "the OAuth framework defines one client credential type"= , you should also describe that RFC 7522 and RFC 7523 define additional kin= ds of client credentials that may be used. 5.4 The Authorize Endpoint Change all occurrences of "authorize endpoint" to "authorization endpoint". 5.5 The Token Endpoint Rather than saying that "this framework extends", say that the framework de= fines optional extensions and reference their definitions and justification= s. 5.5 The Token Endpoint Change "this framework defines encodings using CoAP and CBOR, as a substitu= te for HTTP and JSON" in a way that allows profiles to make either choice. 5.5.1 Client-to-AS Request This section is another place in which this specification is making assumpt= ions about choices that rightfully belong to profiles. It starts with "The= client sends a CoAP POST request". Profiles may choose to use CoAP or the= y may choose to use HTTP. Please reword this so that it says something mor= e like "The client sends a CoAP or HTTP POST request, depending upon the pr= ofile". Please likewise generalize the description of the framework so tha= t it's clear that the choice between CoAP or HTTP is up to the profile. He= ck, Bluetooth Smart is another transport that's possible, which this spec s= houldn't preclude! 5.5.1 Client-to-AS Request This is again written in such a way that it assumes that the additional par= ameters will be implemented and used, which won't be necessary for some pro= files. It starts "In addition to these parameters, this framework defines = the following parameters". Qualify this by saying that some profiles may c= hoose to implement and use the following OAuth extension parameters. 5.5.1 Client-to-AS Request - aud The OAuth Token Exchange spec uses the "audience" parameter for this functi= onality. See https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-0= 9#section-2.1. Please reference this spec and use the same parameter name. 5.5.1 Client-to-AS Request - aud The spec says that "If a client submits a request for an access token witho= ut specifying an "aud" parameter, and the AS does not have a default "aud" = value for this client, then the AS MUST respond with an error message". Th= is violates the OAuth principle that implementations must ignore parameters= that they do not understand. https://tools.ietf.org/html/rfc6749#section-= 3.1 says "The authorization server MUST ignore unrecognized request paramet= ers". Rework this to say that it's perfectly legitimate for participants t= o ignore the "aud" parameter when they don't implement or understand it. 5.5.2 AS-to-Client Response Once again, extensions to OAuth are implicitly required - in this case the = "profile" and "cnf" parameters. Reword to make these choices available to = profiles. 5.5.2 AS-to-Client Response - profile This certainly shouldn't be required, as the profile knowledge will be impl= icit in most OAuth deployments. Very rare indeed will the cases in which p= articipants will support multiple profiles. 5.5.2 AS-to-Client Response The spec says that "Figure 5 summarizes the parameters that may be part of = the RS Information". However the term "RS information" is undefined. Inst= ead, change this sentence to say "Figure 5 summarizes the parameters that = may be part of the token response". 5.5.2 AS-to-Client Response - Figure 6 I suggest removing "profile" from the example, as this is unnecessary proto= col bloat. 5.5.3 Error Response The spec says "The error codes MAY be abbreviated using the codes specified= in table Figure 7". Again, whether to do this is a profile choice. Makin= g it optional only makes all implementations bigger because they have to su= pport both choices. Reword to say that profiles will specify whether error= codes are abbreviated in this manner or not. 5.5.3 Error Response - Figure 7 These values should be in a registry - possibly called something like "OAut= h error code CBOR value mappings". This registry should reference the valu= es registered in the OAuth Extensions Error Registry at https://www.iana.or= g/assignments/oauth-parameters/oauth-parameters.xhtml#extensions-error. 5.5.4.1 Audience Reference the audience parameter in https://tools.ietf.org/html/draft-ietf-= oauth-token-exchange-09#section-2.1 and indicate that whether it is used a = profile-specific choice. 5.5.4.1 Audience The spec says that "It should be encoded as CBOR text string". Again, rewo= rd this to say that it's a profile choice whether to use CBOR or standard O= Auth. 5.5.4.2 Grant Type Rather than saying "MAY", say that the profile specifies the representation= that it used. 5.5.4.2 Figure 8 These values should be in a registry - possibly called something like "OAut= h grant type CBOR value mappings". This registry should reference the sect= ions defining these values in RFC 6749 and the grant type values defined by= RFC 7522 and RFC 7523. 5.5.4.3 Token Type Reference draft-ietf-oauth-pop-key-distribution for the definition of the "= pop" token_type. 5.5.4.3 Token Type When you say that "The values in the 'token_type' parameter MUST be CBOR te= xt strings", you're again implicitly making choices that belong to profiles= . Please generalize this description. 5.5.4.4 Profile Whether "profile" is even needed is up to the profile. Typically it will b= e implicit, since implementations will use a single profile. Please revise= accordingly. 5.5.4.5 Confirmation Please replace the definition of "cnf" for CBOR here with references to RFC= 7800 and draft-ietf-ace-cwt-proof-of-possession. 5.5.5 Mapping parameters to CBOR It looks to me like these values are intended to align with those registere= d 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 s= o, the spec should make this relationship explicit. However, it would be i= nappropriate to use the rare single-byte CBOR integer values for applicatio= n-specific claim keys. I would suggest that the claim identifiers for clie= nt_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" wi= ll already be registered by draft-ietf-ace-cwt-proof-of-possession.) 5.6 The Introspect Endpoint First, change introspect to introspection. And like other places, state th= at it is up to the profile whether to use introspection at all, and if so, = whether to use standard introspection syntax or the CoAP/CBOR version. 5.6.2 AS-to-RS Response - Figure 15 Remove profile and client_token from this example, since both are pretty es= oteric and not likely to be used in the common case. 5.6.4 Client Token I agree with Hannes' review of this feature: "The "Client Token" is somewha= t experimental and not on par with the rest of the document in terms of mat= urity and alignment with OAuth. I would prefer this functionality to be cov= ered in a separate document, if someone still cares about it. While OAuth h= as seen a lot of formal analysis this feature obviously hasn't." Please re= move this from the specification and if you still believe in it, place it i= n a separate document for independent consideration by the working group. 5.6.4 Client Token The spec says "The client is pre-configured with a generic, long-term acces= s token when it is commissioned." This hardly seems secure - especially si= nce secrets can often be extracted from deployed software. 5.6.4 Client Token The spec says "The RS then performs token introspection to learn what acces= s this token grants." Again, this is unnecessary if the resource understan= ds the claims in the access token. 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 int= ended to align with those registered in the CBOR Web Token (CWT) Claims reg= istry initially populated by https://tools.ietf.org/html/draft-ietf-ace-cbo= r-web-token-08#section-9.1.2. If so, the spec should make this relationshi= p 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-a= ce-cwt-proof-of-possession.) 5.7 The Access Token Reference [RFC 7800] and [draft-ietf-ace-cwt-proof-of-possession] when desc= ribing the use of "cnf". 5.7.1 The Authorization Information Endpoint Please describe the relationship between this endpoint and the resource end= point used by RFC 6750. 5.7.1 The Authorization Information Endpoint Again, please clarify that support for this OAuth extension, the use of CoA= P, and the use of introspection are all choices up to particular profiles. 5.7.1 The Authorization Information Endpoint The spec says "The RS MUST be prepared to store more than one token for eac= h client, and MUST apply the combined permissions granted by all applicable= , valid tokens to client requests." This seems really overly specific for = a framework spec. Simple systems will likely only have one token per clien= t, let alone not supporting complex permission combination logic! Please r= emove this statement. 5.7.2 Token Expiration Rather than saying "CWT/JWT" expand this to "CWT or JWT" for readability. 6. Security Considerations Add a reference upon first use of the term "AEAD". 7. Privacy Considerations The spec says "The latter may reveal the client's identity." What is meant= by the client's identity? What kinds of information does this entail and = what are the privacy risks associated with it? How does the client's ident= ity relate to the identities of people who may be associated with the syste= m in some way? 8.1 OAuth Introspection Response Parameter Registration Every place an IANA registration currently says "this document", please cha= nge it to "Section x.y.z of this document" (using the appropriate tag for the section that defines the value. 8.1 OAuth Introspection Response Parameter Registration "aud" is already registered at https://www.iana.org/assignments/oauth-param= eters/oauth-parameters.xhtml#token-introspection-response. 8.4 Token Type Mappings The name "Token Type Mappings" registry is too generic. Please change it t= o "OAuth Token Type CBOR Mappings" or something similar. 8.4.1 Registration Template As was pointed out in comments on earlier versions of the CWT spec, the ran= ge 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 v= alue ranges). Do this consistently every place that "1 to 65536" occurs in= the spec. 8.5 CBOR Web Token Claims Consider using the "scp" claim defined at https://tools.ietf.org/html/draft= -ietf-oauth-token-exchange-09#section-4.2 rather than "scope". If you don'= t, at least say why you are introducing a different claim to convey the sam= e information. 8.5 CBOR Web Token Claims "cnf" is already being registered by draft-ietf-ace-cwt-proof-of-possession= . 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. 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. 8.7.2 Initial Registry Contents Per my earlier comments, these values should actually reference the CWT Cla= ims registry and application-specific values such as "client_id", etc. shou= ld not use the scarce single-byte value range. 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/o= auth-parameters/oauth-parameters.xhtml#token-introspection-response. 8.10 CWT Confirmation Methods Registry Delete this section, as it has been moved to draft-ietf-ace-cwt-proof-of-po= ssession. Appendix A. Design Justification - Communication Constraints Add that power saving may be another reason for communication constraints. Appendix B. Roles and Responsibilities - Authorization Server Add that enabling discovery of the AS's capabilities via metadata is likely= in scope. Reference draft-ietf-oauth-discovery. Appendix B. Roles and Responsibilities - Client What do the parenthetical letters such as "(A)" refer to? Why are "(D)" an= d "(E)" missing? Appendix C. Requirements on Profiles You should be much more clear in this section that choices of JSON vs. CBOR= , JWT vs. CWT, HTTP versus COaP, PoP versus Token Binding, Introspection or= not, authz-info endpoint or not, etc. must be made by profiles. Appendix E. Deployment Examples - Figure 20 Use the "scp" claim defined at https://tools.ietf.org/html/draft-ietf-oauth= -token-exchange-09#section-4.2 rather than "scope". Appendix E.2 Introspection Aided Token Validation It makes no sense to assume that the client is not able to access the AS at= the time of the access request but can access the introspection endpoint, = since the introspection endpoint is part of the AS. Please remove this sec= tion or revise accordingly. Appendix E.2 Introspection Aided Token Validation - Figure 23 Please revise the example to not use Client Credentials, because of the sec= urity and privacy problems associated with this grant type. Surprising Omission of Token Binding! The specification should describe the ability to use Token Bound access tok= ens, rather than PoP access tokens, as this will be substantially simpler f= or most implementations. Please reference draft-ietf-oauth-token-binding a= nd describe how to apply it to this specification. Best wishes, -- Mike --_000_CY4PR21MB0504D057E5B47ED166F35083F57D0CY4PR21MB0504namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Having read the spec cover-to-cover, it surprised me= how different this is from OAuth, despite the statements that it is based = on OAuth.  My highest-priority request is to make all the extensions t= o OAuth defined in this document optional, so that profiles could use actual OAuth, which currently doesn’t see= m to be possible.  Much of this draft written in a way that huge OAuth= extensions are obliquely assumed when describing other features, without a= ny clear definitions or justifications for them when they are introduced in passing.  These things need to be te= ased apart, with references to sections actually defining and justifying ea= ch extension, rather than assuming that many of them exist in passing in ot= her sections.

 

Detailed substantive comments on specific document t= ext follow.  Editorial nits are communicated in the accompanying pull = request https://githu= b.com/LudwigSeitz/ace-oauth/pull/112.

 

Title

The current title “Authentication and Authoriz= ation for Constrained Environments (ACE)” doesn’t match the sco= pe of what’s in the spec, as the spec is only about resource authoriz= ation but not authentication.  Please change the title to “Resource Authorization Framework for Constrained Environments”= ; or something similar.  (Authentication would require defining the eq= uivalent of an OpenID Connect ID Token to convey authentication information= , but this is entirely absent from the specification.)

 

1.  Introduction

The introduction defines what it means by “aut= horization” by doesn’t say what it is referring to by “au= thentication”.  This provides more evidence that “authenti= cation” does not belong in the title or abstract.  Please remove= the passing references to the underspecified concept “authentication” from= the introduction and the abstract.  (Note that while “OAuth cli= ent authentication” is a limited form of authentication, its use as a= mechanism in the spec does not justify saying that the spec is defining authentication for its use cases in any general sense of the t= erm.)

 

2.  Terminology

The “/” syntax for endpoint names, such = as “/token” is misleading, as it seems to imply that these endp= oints use particular pathnames.  Please replace all uses of “/en= dpoint-name” with just “endpoint-name”.

 

2.  Terminology

References are needed for the first uses of many of = the terms and abbreviations used.  For instance, you’re using ab= breviations like “AS”, “RS”, and “IoT” = without saying what they refer to.

 

2.  Terminology

Please change all uses of the word “introspect= ” to “introspection” when referring to the introspection = endpoint.

 

2.  Terminology

You introduce an “authz-info” endpoint i= n the terminology section, when this isn’t commonly understood. = You need a section reference following the first use of this concept.=

 

3.1 OAuth 2.0 – token and introspect endpoints=

This section is the first of many places in which th= e text is written in a way that assumes that introspection will be implemen= ted and used.  This needs to be corrected throughout the document, app= ropriately qualifying descriptions of introspection saying that some profiles may use it and others will not.  For instan= ce, the draft says “The token introspection endpoint, /introspect, is= used by the RS when requesting additional information regarding a received= access token.”  Please change this so something more like “In some profiles, a token introspection endpoint may be p= resent and used by the RS to request additional information about a receive= d access token.”  You should also clearly state that introspecti= on is unnecessary and adds overhead that can be avoided when the resource server understands the access token format, such as when= it is a CWT.

 

3.1 OAuth 2.0 – Proof of Possession Tokens

The draft uses the term “proof of possession t= oken” to denote an access token supporting proof of possession. = Note however, that there are many other kinds of proof of possession token= s other than just access tokens.  Please change all uses of the term “proof of possession token” to “proof o= f possession access token” or “access token supporting proof of= possession”.  Similarly, change all uses of the term “PoP= token” to “PoP access token”.

 

3.1 OAuth 2.0 – Scopes and Permissions

This section contains another example of an extensio= n to OAuth being assumed, when for many profiles it won’t be necessar= y.  The draft says “In turn, the AS may use the scope response p= arameter to inform the client of the scope of the access token issued.”  This assumes that a “scope” respons= e will be added to all participating OAuth implementations, without justify= ing this addition to the standard.  At most, this section should refer= to another section which defines an optional “scope” response parameter and describes the circumstances in which profiles would and woul= d not need it.

 

3.1 OAuth 2.0 – Scopes and Permissions

Likewise, the draft says “As the client could = be a constrained device as well, this specification uses CBOR encoded messa= ges for CoAP”.  This is one of many places in the draft that it&= #8217;s assumed that CBOR and COAP will be used rather than JSON and HTTP.  The framework draft should explicitly leave these cho= ices up to profiles.

 

4. Protocol Interactions

Please do not in any way endorse using the Client Cr= edentials grant – which defeats the purpose of even having OAuth.&nbs= p; The client should never have the user’s credentials!  At most= , you should say that while the Client Credentials grant may be used for some scenarios, it has known security and privacy flaws an= d its use is deprecated.

 

4. Protocol Interactions

The sentence “In such a case the resource owne= r or another person on his or her behalf have arranged with the authorizati= on server out-of-band, which is often accomplished using a commissioning to= ol.” needs clarification.  What has been arranged?

 

Figure 1: Basic Protocol Flow

This is yet another place where a major OAuth extens= ion is assumed, without clear justification.  The diagram adds “= + RS Information” to the authorization server response to the cli= ent, when this isn’t a normal part of OAuth and not defined.  At least, please indicate that this is optional and refer to a section tha= t defines and justifies this optional extension, rather than assuming in pa= ssing that it’s been added.

 

Figure 1: Basic Protocol Flow

Please rework this diagram to illustrate that intros= pection is optional (and wastes resources by performing unnecessary communi= cation).

 

4. Protocol Interactions – Access Token Respon= se

This also assumes the existence of “RS Informa= tion”.  At least, say that “Some profiles may choose to re= turn information about the resource servers” and reference a section = describing this optional feature, rather than write the text in a way that assumes its existence.

 

4. Protocol Interactions – Access Token Respon= se

This also assumes the existence of profile informati= on in the response.  This would normally be implicit.  Again, ple= ase do not write the draft in a way that assumes the presence of extensions= that are often not needed.

 

4. Protocol Interactions – Resource Request

The two-part request described in the third paragrap= h is not OAuth, nor is there any justification for adding additional steps.=   Likewise, the language in paragraph 4 about “comparing the cla= ims in the access token with the resource request” is a highly specific extension that is not normal OAuth.  Please refa= ctor this description to clearly delineate what’s OAuth and what are = optional extensions – referencing specific sections that define these= extensions.

 

4. Protocol Interactions – Token Introspection= Request

Please rework this section to describe that introspe= ction is optional (and wastes resources by performing unnecessary communica= tion).  Describe how things are simpler and more efficient when the re= source directly understands the contents of the access token.

 

4. Protocol Interactions – Token Introspection= Response

This section adds yet another OAuth extension on the= fly – the “client token” – again with no justifica= tion or clear definition.  Please remove the oblique “client tok= en” reference here.

 

5. Framework – Proof-of-Possession<= /p>

After “The binding is provided by the "cn= f" claim” add references to [RFC 7800] and [draft-ietf-ace-cwt-p= roof-of-possession].

 

5. Framework – Proof-of-Possession<= /p>

The text currently includes “update a token= 221;.  Shouldn’t this actually be “get a new token”,= since an existing access token can’t be updated?

 

5.1 Authorization Grants

This section includes the phrase “client crede= ntials grant is recommended”.  Because of the security and priva= cy problems with the client credentials grant, please rework this section t= o ensure that implementers and profile writers understand that the use of client credentials grant is never recommended, including d= escribing why that is the case.

 

5.1 Authorization Grants

Reference [RFC 6749] after you say “see the OA= uth 2.0 framework”.

 

5.2 Client Credentials

After you say that “the OAuth framework define= s one client credential type”, you should also describe that RFC 7522= and RFC 7523 define additional kinds of client credentials that may be use= d.

 

5.4 The Authorize Endpoint

Change all occurrences of “authorize endpoint&= #8221; to “authorization endpoint”.

 

5.5 The Token Endpoint

Rather than saying that “this framework extend= s”, say that the framework defines optional extensions and reference = their definitions and justifications.

 

5.5 The Token Endpoint

Change “this framework defines encodings using= CoAP and CBOR, as a substitute for HTTP and JSON” in a way that allo= ws profiles to make either choice.

 

5.5.1 Client-to-AS Request

This section is another place in which this specific= ation is making assumptions about choices that rightfully belong to profile= s.  It starts with “The client sends a CoAP POST request”.=   Profiles may choose to use CoAP or they may choose to use HTTP.  Please reword this so that it says something more like = “The client sends a CoAP or HTTP POST request, depending upon the pro= file”.  Please likewise generalize the description of the framew= ork so that it’s clear that the choice between CoAP or HTTP is up to the profile.  Heck, Bluetooth Smart is another transpor= t that’s possible, which this spec shouldn’t preclude!

 

5.5.1 Client-to-AS Request

This is again written in such a way that it assumes = that the additional parameters will be implemented and used, which won̵= 7;t be necessary for some profiles.  It starts “In addition to t= hese parameters, this framework defines the following parameters”.  Qualify this by saying that some profiles may cho= ose to implement and use the following OAuth extension parameters.

 

5.5.1 Client-to-AS Request – aud

The OAuth Token Exchange spec uses the “audien= ce” parameter for this functionality.  See https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-09#section-2.1<= /a>.  Please reference this spec and use the same parameter name.=

 

5.5.1 Client-to-AS Request – aud

The spec says that “If a client submits a requ= est for an access token without specifying an "aud" parameter, an= d the AS does not have a default "aud" value for this client, the= n the AS MUST respond with an error message”.  This violates the OAuth principle that implementations must ignore parameters that they = do not understand.  https://tools.i= etf.org/html/rfc6749#section-3.1 says “The authorization server M= UST ignore unrecognized request parameters”.  Rework this to say= that it’s perfectly legitimate for participants to ignore the “aud” parameter when they don’t implement or = understand it.

 

5.5.2 AS-to-Client Response

Once again, extensions to OAuth are implicitly requi= red – in this case the “profile” and “cnf” pa= rameters.  Reword to make these choices available to profiles.

 

5.5.2 AS-to-Client Response – profile

This certainly shouldn’t be required, as the p= rofile knowledge will be implicit in most OAuth deployments.  Very rar= e indeed will the cases in which participants will support multiple profile= s.

 

5.5.2 AS-to-Client Response

The spec says that “Figure 5 summarizes the pa= rameters that may be part of the RS Information”.  However the t= erm “RS information” is undefined.  Instead, change this s= entence to say  “Figure 5 summarizes the parameters that may be = part of the token response”.

 

5.5.2 AS-to-Client Response – Figure 6

I suggest removing “profile” from the ex= ample, as this is unnecessary protocol bloat.

 

5.5.3 Error Response

The spec says “The error codes MAY be abbrevia= ted using the codes specified in table Figure 7”.  Again, whethe= r to do this is a profile choice.  Making it optional only makes all i= mplementations bigger because they have to support both choices.  Reword to say that profiles will specify whether error code= s are abbreviated in this manner or not.

 

5.5.3 Error Response – Figure 7

These values should be in a registry – possibl= y called something like “OAuth error code CBOR value mappings”.=   This registry should reference the values registered in the OAuth Ex= tensions Error Registry at https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#ex= tensions-error.

 

5.5.4.1 Audience

Reference the audience parameter in https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-09#section-2.1<= /a> and indicate that whether it is used a profile-specific choice.

 

5.5.4.1 Audience

The spec says that “It should be encoded as CB= OR text string”.  Again, reword this to say that it’s a pr= ofile choice whether to use CBOR or standard OAuth.

 

5.5.4.2 Grant Type

Rather than saying “MAY”, say that the p= rofile specifies the representation that it used.

 

5.5.4.2 Figure 8

These values should be in a registry – possibl= y called something like “OAuth grant type CBOR value mappings”.=   This registry should reference the sections defining these values in= RFC 6749 and the grant type values defined by RFC 7522 and RFC 7523.

 

5.5.4.3 Token Type

Reference draft-ietf-oauth-pop-key-distribution for = the definition of the “pop” token_type.

 

5.5.4.3 Token Type

When you say that “The values in the ‘to= ken_type’ parameter MUST be CBOR text strings”, you’re ag= ain implicitly making choices that belong to profiles.  Please general= ize this description.

 

5.5.4.4 Profile

Whether “profile” is even needed is up t= o the profile.  Typically it will be implicit, since implementations w= ill use a single profile.  Please revise accordingly.

 

5.5.4.5 Confirmation

Please replace the definition of “cnf” f= or CBOR here with references to RFC 7800 and draft-ietf-ace-cwt-proof-of-po= ssession.

 

5.5.5 Mapping parameters to CBOR

It looks to me like these values are intended to ali= gn with those registered in the CBOR Web Token (CWT) Claims registry initia= lly populated by https://tools.ietf.org/html/draft-ietf-ace-cbor-web-token-08#section-9.1.2<= /a>.  If so, the spec should make this relationship explicit.  Ho= wever, it would be inappropriate to use the rare single-byte CBOR integer v= alues for application-specific claim keys.  I would suggest that the claim identifiers for client_id through refresh_t= oken 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-iet= f-ace-cwt-proof-of-possession.)

 

5.6 The Introspect Endpoint

First, change introspect to introspection.  And= like other places, state that it is up to the profile whether to use intro= spection at all, and if so, whether to use standard introspection syntax or= the CoAP/CBOR version.

 

5.6.2 AS-to-RS Response – Figure 15=

Remove profile and client_token from this example, s= ince both are pretty esoteric and not likely to be used in the common case.=

 

5.6.4 Client Token

I agree with Hannes’ review of this feature: &= #8220;The "Client Token" is somewhat experimental and not on p= ar with the rest of the document in terms of maturity and alignment with OA= uth. I would prefer this functionality to be covered in a separate document, if someone still cares about it. While OAuth has seen= a lot of formal analysis this feature obviously hasn't.”  P= lease remove this from the specification and if you still believe in it, pl= ace it in a separate document for independent consideration by the working group.

 

5.6.4 Client Token

The spec says “The client is pre-configured wi= th a generic, long-term access token when it is commissioned.”  = This hardly seems secure – especially since secrets can often be extr= acted from deployed software.

 

5.6.4 Client Token

The spec says “The RS then performs token intr= ospection to learn what access this token grants.”  Again, this = is unnecessary if the resource understands the claims in the access token.<= o:p>

 

5.6.5 Mapping Introspection Parameters to CBOR<= /o:p>

As in my related comment on 5.5.5, it looks to me li= ke 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<= /a>.  If so, the spec should make this relationship explicit.  Ho= wever, it would be inappropriate to use the rare single-byte CBOR integer v= alues for application-specific claim keys.  I would suggest that the claim identifiers for client_id through refresh_t= oken 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-iet= f-ace-cwt-proof-of-possession.)

 

5.7 The Access Token

Reference [RFC 7800] and [draft-ietf-ace-cwt-proof-o= f-possession] when describing the use of “cnf”.

 

5.7.1 The Authorization Information Endpoint

Please describe the relationship between this endpoi= nt and the resource endpoint used by RFC 6750.

 

5.7.1 The Authorization Information Endpoint

Again, please clarify that support for this OAuth ex= tension, the use of CoAP, and the use of introspection are all choices up t= o particular profiles.

 

5.7.1 The Authorization Information Endpoint

The spec says “The RS MUST be prepared to stor= e more than one token for each client, and MUST apply the combined permissi= ons granted by all applicable, valid tokens to client requests.” = ; This seems really overly specific for a framework spec.  Simple systems will likely only have one token per client, let= alone not supporting complex permission combination logic!  Please re= move this statement.

 

5.7.2 Token Expiration

Rather than saying “CWT/JWT” expand this= to “CWT or JWT” for readability.

 

6. Security Considerations

Add a reference upon first use of the term “AE= AD”.

 

7. Privacy Considerations

The spec says “The latter may reveal the clien= t's identity.”  What is meant by the client’s identity?&nb= sp; What kinds of information does this entail and what are the privacy ris= ks associated with it?  How does the client’s identity relate to the identities of people who may be associated with the system in some = way?

 

8.1 OAuth Introspection Response Parameter Registrat= ion

Every place an IANA registration currently says R= 20;this document”, please change it to “Section x.y.z of this d= ocument” (using the appropriate <ref target=3D”x.y.z”/= > tag for the section that defines the value.

 

8.1 OAuth Introspection Response Parameter Registrat= ion

“aud” is already registered at https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#to= ken-introspection-response.

 

8.4 Token Type Mappings

The name “Token Type Mappings” registry = is too generic.  Please change it to “OAuth Token Type CBOR Mapp= ings” or something similar.

 

8.4.1  Registration Template

As was pointed out in comments on earlier versions o= f 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 deri= ved from the COSE usage of value ranges).  Do this consistently every place that “1 to 65536” occurs in t= he spec.

 

8.5 CBOR Web Token Claims

Consider using the “scp” claim defined a= t https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-09#section-4.2<= /a> rather than “scope”.  If you don’t, at least say= why you are introducing a different claim to convey the same information.<= o:p>

 

8.5 CBOR Web Token Claims

“cnf” is already being registered by dra= ft-ietf-ace-cwt-proof-of-possession.

 

8.6 ACE Profile Registry

The name “ACE Profile Registry” registry= is too generic.  Please change it to “ACE OAuth Profile Registr= y” or something similar.

 

8.7 OAuth Parameter Mappings Registry

The name “OAuth Parameter Mappings” regi= stry is too generic.  Please change it to “OAuth CBOR Parameter = Mappings” or something similar.

 

8.7.2 Initial Registry Contents

Per my earlier comments, these values should actuall= y reference the CWT Claims registry and application-specific values such as= “client_id”, etc. should not use the scarce single-byte value = range.

 

8.8.1 Registration Template

Registrations for the Introspection Endpoint CBOR Ma= ppings registry should contain a field that lists the corresponding value r= egistered in the OAuth Token Introspection Response registry at https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#to= ken-introspection-response.

 

8.10 CWT Confirmation Methods Registry

Delete this section, as it has been moved to draft-i= etf-ace-cwt-proof-of-possession.

 

Appendix A. Design Justification – Communicati= on Constraints

Add that power saving may be another reason for comm= unication constraints.

 

Appendix B. Roles and Responsibilities – Autho= rization Server

Add that enabling discovery of the AS’s capabi= lities via metadata is likely in scope.  Reference draft-ietf-oauth-di= scovery.

 

Appendix B. Roles and Responsibilities – Clien= t

What do the parenthetical letters such as “(A)= ” refer to?  Why are “(D)” and “(E)” mis= sing?

 

Appendix C. Requirements on Profiles

You should be much more clear in this section that c= hoices of JSON vs. CBOR, JWT vs. CWT, HTTP versus COaP, PoP versus Token Bi= nding, Introspection or not, authz-info endpoint or not, etc. must be made = by profiles.

 

Appendix E. Deployment Examples – Figure 20

Use the “scp” claim defined at https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-09#section-4.2<= /a> rather than “scope”. 

 

Appendix E.2 Introspection Aided Token Validation

It makes no sense to assume that the client is not a= ble to access the AS at the time of the access request but can access the i= ntrospection endpoint, since the introspection endpoint is part of the AS.&= nbsp; Please remove this section or revise accordingly.

 

Appendix E.2 Introspection Aided Token Validation &#= 8211; Figure 23

Please revise the example to not use Client Credenti= als, because of the security and privacy problems associated with this gran= t type.

 

Surprising Omission of Token Binding!<= /b>

The specification should describe the ability to use= Token Bound access tokens, rather than PoP access tokens, as this will be = substantially simpler for most implementations.  Please reference draf= t-ietf-oauth-token-binding and describe how to apply it to this specification.

 

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;        Best wishes,

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

 

--_000_CY4PR21MB0504D057E5B47ED166F35083F57D0CY4PR21MB0504namp_-- From nobody Mon Oct 2 03:39:44 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D764D1320BD for ; Mon, 2 Oct 2017 03:39:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KLmnxgRSzG6F for ; Mon, 2 Oct 2017 03:39:40 -0700 (PDT) Received: from se-out1.mx-wecloud.net (se-out1.mx-wecloud.net [89.221.255.93]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47F891344B5 for ; Mon, 2 Oct 2017 03:39:40 -0700 (PDT) Received: from sp-mail-2.sp.se (unknown [194.218.146.197]) by se-out1.mx-wecloud.net (Postfix) with ESMTPS id 23184201B01; Mon, 2 Oct 2017 10:39:36 +0000 (UTC) Received: from [192.168.0.166] (10.116.0.226) by sp-mail-2.sp.se (10.100.0.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.669.32; Mon, 2 Oct 2017 12:39:37 +0200 To: , Hannes Tschofenig References: <55ac5e55-2570-6126-2211-a6c1b65c3006@gmx.net> From: Ludwig Seitz Message-ID: Date: Mon, 2 Oct 2017 12:39:36 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <55ac5e55-2570-6126-2211-a6c1b65c3006@gmx.net> 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-CMAE-Score: 0 X-CMAE-Analysis: v=2.2 cv=cdiiljLM c=1 sm=1 tr=0 a=L5DDne6A+dD0FbDkt2Fblw==:117 a=L5DDne6A+dD0FbDkt2Fblw==:17 a=sZ8rJzgPlrQA:10 a=IkcTkHD0fZMA:10 a=02M-m0pO-4AA:10 a=hK2iBajCOQr9EHEsNk8A:9 a=QEXdDO2ut3YA:10 X-Virus-Scanned: clamav-milter 0.99.2 at MailSecurity X-Virus-Status: Clean X-MailSecurity-Status: 0 X-Scanned-By: WeCloud MailSecurity X-MailSecurity-Score: 0 Archived-At: Subject: Re: [Ace] draft-ietf-ace-dtls-authorize-01 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, 02 Oct 2017 10:39:43 -0000 On 2017-10-01 11:35, Hannes Tschofenig wrote: > [chair hat off] > > Hi all, Hello Hannes, thank you for your comments. Replies inline. /Ludwig > > I took a look at the draft and noticed a few minor things: > > - The document should talk about "profiles" rather than "profile" since > it specifies at least two profiles, namely the RPK and the PSK profiles > with DTLS. I suspect an implementation is only expected to implement one > of them rather than both. I would have said that PSK vs RPK are just options within the DTLS profile, but I have no strong opinion about this. You have a point that constrained implementations are likely to only support one option. > > - Editorial comment: most of the articles are missing, which makes the > document harder to read. > Will fix. > - AS discovery: Wouldn't the client need to know the AS upfront when > using RPK and PSK (since it has to share a PSK with the AS or, in case > of the RPK, has to have the RPK with the server exchanged out of band)? There are two scenarios how this could work: 1.) The client doesn't know the AS upfront, but after getting the discovery message it can register at the AS through some out-of-scope method in order to establish the PSK or RPK needed for communication with the token endpoint. 2.) The discovery hint just helps the client to select an AS from a set of previously known ASs. > - There are two options provided for conveying the access token to the > RS, either either a dedicated endpoint or inband within the DTLS > exchange. There are pros and cons regarding the usage of both; is the > idea to settle with one approach in the end or do you envision both > options to be available in the final version of the specification. Note that the inband version only works for PSK, so the authz-info endpoint is at least needed for RPK. I would guess that constrained implementations would settle for just one option. Maybe we should specify some signaling for that. > > - Regarding the dynamic update of authorization information. Since the > access token is a PoP token I believe you will have to demonstrate the > possession of the key every time you change the access token. (Section > 2.4 gives me a different impression.) > Not necessarily. Since you still have the session open, you only need to have the AS to link the new token to the same pop key (for which you already proved possession). The framework (in conjunction with the cnf draft) have mechanisms for this). > - When the access token is conveyed inband in DTLS as part of the > PSK_identity then the text on page 12 is applicable. The description in > CDDL format confuses me. Normally, it should be quite simple: either you > transmit a psk_identity field or you convey the access token. The server > would figure it out. Is this just a complicated way to express this > semantic or do you have something else in mind? The actual functionality that is specified is this: psk_identity = {kid : } | {access_token : } does that make more sense to you? I'm not entirely happy with that solution, since we now have the weird situation where a client oblivious of the profile might use the psk_identity as intended, thus we actually have: psk_identity = {kid : } | {access_token : } | kid and my code needs to handle all 3 cases. I agree this needs to be discussed. > (Btw, my understanding is that the server does not need to send a > illegal_parameter alert when it the psk_identity does not lead to a > successful authentication. Is this your suggestion or is this taken from > TLS PSK?) > > - What is the reasoning behind this statement: > > "This specification mandates that at least the key derivation > algorithm "HKDF SHA-256" as defined in [I-D.ietf-cose-msg] MUST be > supported." > > I would have assumed at the session key provided by the AS to the client > and the key embedded in the access token is used directly within TLS as > a PSK. > I'm not sure about this, Olaf, Steffi? > - Could you explain this statement: > " > If the security association with RS still exists and RS has indicated > support for session renegotiation according to [RFC5746], the new > Access Token MAY be used to renegotiate the existing DTLS session. > In this case, the Access Token is used as "psk_identity" as defined > in Section 4.1. The Client MAY also perform a new DTLS handshake > according to Section 4.1 that replaces the existing DTLS session. > " > > What are you trying to accomplish? Do you expect authorization > information to change frequently? What security association are you > talking about in the paragraph above? > The idea is to be able to handle changing authorization information, without having to redo the full DTLS handshake. The scenario would be that a client gains access to a resource, starts performing a series of operations, and at some point gets a "permission denied". The client would then go back to the token endpoint at the AS and request a new access token with a wider scope, that it would submit to the RS. The security association would be the DTLS session. -- Ludwig Seitz, PhD Security Lab, RISE SICS Phone +46(0)70-349 92 51 From nobody Mon Oct 2 12:46:04 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29D631347F5 for ; Mon, 2 Oct 2017 12:46:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.455 X-Spam-Level: X-Spam-Status: No, score=-0.455 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_06_12=1.543, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=alibaba-inc.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rJVOf8COZplj for ; Mon, 2 Oct 2017 12:46:01 -0700 (PDT) Received: from out0-211.mail.aliyun.com (out0-211.mail.aliyun.com [140.205.0.211]) (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 82BD8133321 for ; Mon, 2 Oct 2017 12:45:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1506973556; h=Date:Subject:From:To:Message-ID:Mime-version:Content-type; bh=8KarlNy3TZO2HafQ0873j8ooGdLKF8ieemOTChg49Nk=; b=K2NtbOP+pOkEHDGwMui3fTq6EJITElx0E0bHggiCE9VuD2HLf8aAZ2MaeOWBTri9oixxpVsuqM5CBb8ey3xIT2fshR9bwUR1lpyPEtCDBTv+3ZE9RcTeHSdWG4E0OTCoOX6doC9EpNUXOzMLP92nOE22m1KteYX9/cbSi7oMWiE= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R111e4; FP=0|-1|-1|-1|0|-1|-1|-1; HT=e02c03289; MF=kepeng.lkp@alibaba-inc.com; NM=1; PH=DS; RN=3; SR=0; TI=SMTPD_---.91grkbK_1506973544; Received: from 30.56.152.144(mailfrom:kepeng.lkp@alibaba-inc.com ip:121.0.29.205) by smtp.aliyun-inc.com(127.0.0.1); Tue, 03 Oct 2017 03:45:51 +0800 User-Agent: Microsoft-MacOutlook/14.6.8.160830 Date: Mon, 02 Oct 2017 21:45:43 +0800 From: "Kepeng Li" To: ace CC: Hannes Tschofenig , Kathleen Moriarty Message-ID: Thread-Topic: [Ace] Two ACE virtual interim meetings in Oct Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: [Ace] Two ACE virtual interim meetings in Oct 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, 02 Oct 2017 19:46:02 -0000 Hello all, According to our doodle poll result, here are the arrangements for our two ACE virtual interim meetings in Oct: Our first call will be on 18th Oct, Wednesday, GMT 13:00 ~ 14:00, and it will be used to discuss ACE roadmap, the output from the Wiki activity. Our second call will be on 19th Oct, Thursday, GMT 13:00 ~ 14:00, and it will be used to discuss certificate enrolment in constrained environments. We will send out the WebEx information soon. Thanks, Kind Regards Kepeng & Hannes =E5=9C=A8 28/09/2017, 9:14 AM=EF=BC=8C "Ace on behalf of Kepeng Li" =E5=86=99=E5=85=A5: >OK.=20 > >So we will pick up two dates according to the doodle poll result. > >The first one will be used to discuss ACE roadmap, the output from the >Wiki activity. > >The second one will be used to discuss certificate enrolment in >constrained environments. > >Please fill out the doodle poll before next Monday, 2nd Oct. >https://beta.doodle.com/poll/ig3bhr7tfb2xh4u4 > > >Thanks, > >Kind Regards >Kepeng > >=E5=9C=A8 28/09/2017, 1:32 AM=EF=BC=8C "Hannes Tschofenig" = =E5=86=99 >=E5=85=A5: > >>Yes, good point. We need to make progress with our chartered items first. >> >>On 09/27/2017 07:29 PM, Kathleen Moriarty wrote: >>> Goran has a good point here. >>>=20 >>> Kathleen >>>=20 >>> On Wed, Sep 27, 2017 at 1:04 PM, G=C3=B6ran Selander >>> wrote: >>>> >>>> As I mentioned in a previous mail, I=E2=80=99m completely against giving >>>>priority >>>> to non-charter items. Therefore the first interim meeting should be >>>> focused on the ACE roadmap - the output from the Wiki activity. If we >>>>have >>>> time to discuss certificate enrolment, that is fine. If we want a >>>>later >>>> interim for the certificate enrolment discussion that is fine too, as >>>>long >>>> as there is sufficient time is given to decide on the ongoing work. >>>> >>>> G=C3=B6ran >>>> >>>> >>>> On 2017-09-27 18:34, "Ace on behalf of Hannes Tschofenig" >>>> wrote: >>>> >>>>> Fair enough. >>>>> >>>>> We either need to make it longer or pick two dates. I prefer the >>>>>latter. >>>>> >>>>> On 09/27/2017 06:23 PM, Kathleen Moriarty wrote: >>>>>> Sure, my response was to make it clear the wiki was to be discussed >>>>>> though. Will this all be on one call or two? The announcement >>>>>>wasn't >>>>>> clear and I'd like ot make sure the WG is ready for the profiles >>>>>> discussion. >>>>>> >>>>>> Best, >>>>>> Kathleen >>>>>> >>>>>> On Wed, Sep 27, 2017 at 12:09 PM, Hannes Tschofenig >>>>>> wrote: >>>>>>> I agree with Kepeng that we also wanted to discuss the certificate >>>>>>> enrollment in addition to the Wiki. >>>>>>> >>>>>>> On 09/27/2017 05:23 PM, Kathleen Moriarty wrote: >>>>>>>> Hello Kepeng, >>>>>>>> >>>>>>>> The interim should also be to discuss the profiles as that was a >>>>>>>> priority from the WG session in Prague. Goran pulled together the >>>>>>>> wiki, now it's up to the WG participants to check the wiki and >>>>>>>>amend >>>>>>>> as needed to allow for a productive session. Or did you plan on >>>>>>>>two >>>>>>>> interims? Timing is tight for that though. >>>>>>>> >>>>>>>> Best regards, >>>>>>>> Kathleen >>>>>>>> >>>>>>>> On Tue, Sep 26, 2017 at 9:44 PM, Kepeng Li >>>>>>>> wrote: >>>>>>>>> Hi all, >>>>>>>>> >>>>>>>>> According to our IETF 99 meeting minutes, we will hold an interim >>>>>>>>> meeting on >>>>>>>>> certificate enrolment in constrained environments. >>>>>>>>> https://datatracker.ietf.org/meeting/99/materials/minutes-99-ace/ >>>>>>>>> >>>>>>>>> We proposed three options for the meeting time: >>>>>>>>> 1. 17th Oct, Tuesday, GMT 13:00 ~ 14:00. >>>>>>>>> 2. 18th Oct, Wednesday, GMT 13:00 ~ 14:00. >>>>>>>>> 3. 19th Oct, Thursday, GMT 13:00 ~ 14:00. >>>>>>>>> >>>>>>>>> Please indicate your available time from the doodle poll: >>>>>>>>> https://doodle.com/poll/ig3bhr7tfb2xh4u4 >>>>>>>>> >>>>>>>>> Hannes and I will prepare the agenda and send out later. We may >>>>>>>>>add >>>>>>>>> other >>>>>>>>> topics to the agenda. >>>>>>>>> >>>>>>>>> Thanks. >>>>>>>>> >>>>>>>>> Kind Regards >>>>>>>>> Kepeng & Hannes >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> Ace mailing list >>>>> Ace@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ace >>>> >>>=20 >>>=20 >>>=20 > > >_______________________________________________ >Ace mailing list >Ace@ietf.org >https://www.ietf.org/mailman/listinfo/ace From nobody Mon Oct 2 13:38:55 2017 Return-Path: X-Original-To: ace@ietf.org Delivered-To: ace@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 64B2113487E; Mon, 2 Oct 2017 13:38:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: ace@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.63.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150697672715.28679.5882413121610901208@ietfa.amsl.com> Date: Mon, 02 Oct 2017 13:38:47 -0700 Archived-At: Subject: [Ace] Authentication and Authorization for Constrained Environments (ace) WG Virtual Meeting: 2017-10-18 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, 02 Oct 2017 20:38:47 -0000 The Authentication and Authorization for Constrained Environments (ace) Working Group will hold a virtual interim meeting on 2017-10-18 from 13:00 to 14:00 UTC. Agenda: ACE roadmap, the output from the Wiki activity Information about remote participation: Remote participation information will be obtained at the time of approval. From nobody Mon Oct 2 13:39:12 2017 Return-Path: X-Original-To: ace@ietf.org Delivered-To: ace@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D4B31348A4; Mon, 2 Oct 2017 13:39:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: ace@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.63.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150697675155.28776.8956148779550358244@ietfa.amsl.com> Date: Mon, 02 Oct 2017 13:39:11 -0700 Archived-At: Subject: [Ace] Authentication and Authorization for Constrained Environments (ace) WG Virtual Meeting: 2017-10-19 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, 02 Oct 2017 20:39:11 -0000 The Authentication and Authorization for Constrained Environments (ace) Working Group will hold a virtual interim meeting on 2017-10-19 from 13:00 to 14:00 UTC. Agenda: Discuss certificate enrolment in constrained environments. Information about remote participation: Remote participation information will be obtained at the time of approval From nobody Wed Oct 4 07:47:46 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B40A124B17 for ; Wed, 4 Oct 2017 07:47:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.799 X-Spam-Level: X-Spam-Status: No, score=-2.799 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 lfo7ULBwzPcW for ; Wed, 4 Oct 2017 07:47:38 -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 041B81321DF for ; Wed, 4 Oct 2017 07:47:37 -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 v94ElYv7004422; Wed, 4 Oct 2017 16:47:34 +0200 (CEST) Received: from wangari.tzi.org (p508A448A.dip0.t-ipconnect.de [80.138.68.138]) (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 3y6dzT72mfzDLBB; Wed, 4 Oct 2017 16:47:33 +0200 (CEST) From: Olaf Bergmann To: Hannes Tschofenig Cc: , Ludwig Seitz References: <55ac5e55-2570-6126-2211-a6c1b65c3006@gmx.net> Date: Wed, 04 Oct 2017 16:47:33 +0200 In-Reply-To: (Ludwig Seitz's message of "Mon, 2 Oct 2017 12:39:36 +0200") Message-ID: <87infvhsvu.fsf@tzi.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Ace] draft-ietf-ace-dtls-authorize-01 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, 04 Oct 2017 14:47:41 -0000 Hello Hannes, Thank you very much for your comments. I am replying to the comment that Ludwig did not yet address: Ludwig Seitz writes: > On 2017-10-01 11:35, Hannes Tschofenig wrote: >> - What is the reasoning behind this statement: >> >> "This specification mandates that at least the key derivation >> algorithm "HKDF SHA-256" as defined in [I-D.ietf-cose-msg] MUST be >> supported." >> >> I would have assumed at the session key provided by the AS to the client >> and the key embedded in the access token is used directly within TLS as >> a PSK. Yes, you could embed the session key in the access token. But then, you would always have to encrypt the access token and ensure that is never decrypted by unauthorized parties. Key derivation allows you to transfer the access token unencrypted (as long as the privacy objectives are met, of course). This could even save some bytes in the token as the encrypted session key does not have to be transferred. This mechanism has previously been discussed in section 6 of [1] but now has been adjusted from the simple ad-hoc syntax in DCAF to the more flexible COSE method. [1] https://tools.ietf.org/html/draft-gerdes-ace-dcaf-authorize-04#section-6 Gr=C3=BC=C3=9Fe Olaf From nobody Wed Oct 4 14:06:36 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09088134499 for ; Wed, 4 Oct 2017 14:06:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.454 X-Spam-Level: X-Spam-Status: No, score=-0.454 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_06_12=1.543, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=alibaba-inc.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eSvbkV05RrEd for ; Wed, 4 Oct 2017 14:06:33 -0700 (PDT) Received: from out0-236.mail.aliyun.com (out0-236.mail.aliyun.com [140.205.0.236]) (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 DBA02133052 for ; Wed, 4 Oct 2017 14:06:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1507151189; h=Date:Subject:From:To:Message-ID:Mime-version:Content-type; bh=jeFmh37h4b/n96RCfNHbyJ5aDDEjDEylMSc3xZpXSo4=; b=tk85iaDv47xucvkfExlHWNqwcasrxH1Ow+dF3VckmDNAqU4J7fny1x3WiyIo5un4pc0OPXPIeO7mY760k2nHKI70u4y+sFCATngFlksVoo8IsAI+ArdHa+B51hkoFjfgheCjjuif06LetzRylY9qx6pIxyg54sbUERidqwob2sU= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R141e4; FP=0|-1|-1|-1|0|-1|-1|-1; HT=e02c03312; MF=kepeng.lkp@alibaba-inc.com; NM=1; PH=DS; RN=3; SR=0; TI=SMTPD_---.92aQS02_1507151178; Received: from 30.56.242.91(mailfrom:kepeng.lkp@alibaba-inc.com ip:121.0.29.204) by smtp.aliyun-inc.com(127.0.0.1); Thu, 05 Oct 2017 05:06:23 +0800 User-Agent: Microsoft-MacOutlook/14.6.8.160830 Date: Wed, 04 Oct 2017 23:06:16 +0800 From: "Kepeng Li" To: ace CC: Hannes Tschofenig , Kathleen Moriarty Message-ID: Thread-Topic: ACE virtual interim meeting on 18th Oct to discuss ACE roadmap Mime-version: 1.0 Content-type: multipart/mixed; boundary="B_3590003183_4629925" Archived-At: Subject: [Ace] ACE virtual interim meeting on 18th Oct to discuss ACE roadmap 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, 04 Oct 2017 21:06:35 -0000 > ´ËÓʼþʹÓà MIME ¸ñʽ¡£ÓÉÓÚÓʼþÔĶÁ³ÌÐò²»ÄÜʶ±ð ´Ë¸ñʽ£¬Òò´Ë£¬¿ÉÄÜÎÞ·¨Ê¶±ð¸ÃÓʼþµÄ·Ö²¿»ò²¿·ÖÄÚÈÝ¡£ --B_3590003183_4629925 Content-type: multipart/alternative; boundary="B_3590003183_4631147" --B_3590003183_4631147 Content-type: text/plain; charset="GB2312" Content-transfer-encoding: 7bit Hello all, Please find the attached WebEx meeting information, and save it to your calendar. It can be also found below: Time: 18th Oct, GMT 13:00 ~ 14:00. Agenda item: ACE roadmap, the output from the Wiki activity. Link: https://trac.ietf.org/trac/ace/wiki/WikiStart JOIN WEBEX MEETING https://ietf.webex.com/ietf/j.php?MTID=m81fae81e933f9aaedf62bdadf1e6f441 Meeting number (access code): 313 154 691 Host key: 710338 Meeting password: 22JqEbFK JOIN BY PHONE 1-877-668-4493 Call-in toll free number (US/Canada) 1-650-479-3208 Call-in toll number (US/Canada) Toll-free dialing restrictions: https://www.webex.com/pdf/tollfree_restrictions.pdf 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. Kind Regards Kepeng & Hannes --B_3590003183_4631147 Content-type: text/html; charset="GB2312" Content-transfer-encoding: quoted-printable
Hello all,

Please find the attached WebEx meeting inf= ormation, and save it to your calendar.

It can be also found below:

Time: 18th O= ct, GMT 13:00 ~ 14:00.
https://ietf.webex.com/ietf/j.php?MTID=3Dm81fae81e933f9aaedf62bd= adf1e6f441
Meeting number (acc= ess code): 313 154 691
Host ke= y: 710338
Meeting password: 22= JqEbFK

JOIN BY PHONE
1-877-668-4493 Call-in toll free number (US/Canada) =
1-650-479-3208 Call-in toll number (= US/Canada)

<= /div>
Toll-free dialing restrictions: =
https://www.webex.com/pdf/tollfree_r= estrictions.pdf

Can't join the meeting? Contact support= here:
https://ietf.webex.com/= ietf/mc

IMPORTANT NOTICE: Please note that this WebEx s= ervice allows audio and other information sent during the session to be reco= rded, which may be discoverable in a legal matter. You should inform all mee= ting attendees prior to recording if you intend to record the meeting.

Kind Regards
Kepeng & Hannes

--B_3590003183_4631147-- --B_3590003183_4629925 Content-type: text/calendar; name="WebEx_Meeting.ics" Content-disposition: attachment; filename="WebEx_Meeting.ics" Content-transfer-encoding: base64 QkVHSU46VkNBTEVOREFSClBST0RJRDotLy9NaWNyb3NvZnQgQ29ycG9yYXRpb24vL091dGxv b2sgMTAuMCBNSU1FRElSLy9FTgpWRVJTSU9OOjIuMApNRVRIT0Q6UkVRVUVTVApCRUdJTjpW VElNRVpPTkUKVFpJRDpHcmVlbndpY2ggVGltZQpCRUdJTjpTVEFOREFSRApEVFNUQVJUOjIw MTUwMTAxVDAwMDAwMApUWk9GRlNFVEZST006KzAwMDAKVFpPRkZTRVRUTzorMDAwMApUWk5B TUU6U3RhbmRhcmQgVGltZQpFTkQ6U1RBTkRBUkQKRU5EOlZUSU1FWk9ORQpCRUdJTjpWRVZF TlQKQVRURU5ERUU7Q049IkFDRSBXb3JraW5nIEdyb3VwIjtST0xFPVJFUS1QQVJUSUNJUEFO VDtSU1ZQPUZBTFNFOk1BSUxUTzphY2UtY2hhaXJzQGlldGYub3JnCk9SR0FOSVpFUjtDTj0i d2ViZXgiOk1BSUxUTzptZXNzZW5nZXJAd2ViZXguY29tCkRUU1RBUlQ7VFpJRD0iR3JlZW53 aWNoIFRpbWUiOjIwMTcxMDE4VDEzMDAwMApEVEVORDtUWklEPSJHcmVlbndpY2ggVGltZSI6 MjAxNzEwMThUMTQwMDAwCkxPQ0FUSU9OOmh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0ZgpU UkFOU1A6T1BBUVVFClNFUVVFTkNFOjE1MDcxNDg2NDcKVUlEOmJmN2NiODIyLWQzZWYtNDUy My1hZTkwLTUwYjg2ZmIxNGRkZgpEVFNUQU1QOjIwMTcxMDE4VDEzMDAwMFoKREVTQ1JJUFRJ T046XG5cbkpPSU4gV0VCRVggTUVFVElOR1xuaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRm L2oucGhwP01USUQ9bTgxZmFlODFlOTMzZjlhYWVkZjYyYmRhZGYxZTZmNDQxXG5NZWV0aW5n IG51bWJlciAoYWNjZXNzIGNvZGUpOiAzMTMgMTU0IDY5MVxuSG9zdCBrZXk6IDcxMDMzOFxu TWVldGluZyBwYXNzd29yZDogMjJKcUViRktcblxuXG5cbkpPSU4gQlkgUEhPTkVcbjEtODc3 LTY2OC00NDkzIENhbGwtaW4gdG9sbCBmcmVlIG51bWJlciAoVVMvQ2FuYWRhKSBcbjEtNjUw LTQ3OS0zMjA4IENhbGwtaW4gdG9sbCBudW1iZXIgKFVTL0NhbmFkYSlcblxuVG9sbC1mcmVl IGRpYWxpbmcgcmVzdHJpY3Rpb25zOiBcbmh0dHBzOi8vd3d3LndlYmV4LmNvbS9wZGYvdG9s bGZyZWVfcmVzdHJpY3Rpb25zLnBkZlxuXG5cblxuQ2FuJ3Qgam9pbiB0aGUgbWVldGluZz8g Q29udGFjdCBzdXBwb3J0IGhlcmU6XG5odHRwczovL2lldGYud2ViZXguY29tL2lldGYvbWNc blxuXG5JTVBPUlRBTlQgTk9USUNFOiBQbGVhc2Ugbm90ZSB0aGF0IHRoaXMgV2ViRXggc2Vy dmljZSBhbGxvd3MgYXVkaW8gYW5kIG90aGVyIGluZm9ybWF0aW9uIHNlbnQgZHVyaW5nIHRo ZSBzZXNzaW9uIHRvIGJlIHJlY29yZGVkLCB3aGljaCBtYXkgYmUgZGlzY292ZXJhYmxlIGlu IGEgbGVnYWwgbWF0dGVyLiBZb3Ugc2hvdWxkIGluZm9ybSBhbGwgbWVldGluZyBhdHRlbmRl ZXMgcHJpb3IgdG8gcmVjb3JkaW5nIGlmIHlvdSBpbnRlbmQgdG8gcmVjb3JkIHRoZSBtZWV0 aW5nLlxuClgtQUxULURFU0M7Rk1UVFlQRT10ZXh0L2h0bWw6CTxGT05UIFNJWkU9IjEiIEZB Q0U9IkFSSUFMIj48Rk9OVCBTSVpFPSI0IiBGQUNFPSJBUklBTCI+CQk8YSBocmVmPSJodHRw czovL2lldGYud2ViZXguY29tL2lldGYvai5waHA/TVRJRD1tODFmYWU4MWU5MzNmOWFhZWRm NjJiZGFkZjFlNmY0NDEiPjxGT05UIFNJWkU9IjMiIENPTE9SPSIjMDBBRkY5IiBGQUNFPSJB cmlhbCI+Sm9pbiBXZWJFeCBtZWV0aW5nPC9GT05UPjwvYT4JCQk8dGFibGU+CQkJCTx0cj4J CQkJCTx0ZD4JCQkJCQk8Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJp YWwiPk1lZXRpbmcgbnVtYmVyIChhY2Nlc3MgY29kZSk6IDMxMyAxNTQgNjkxPC9GT05UPgkJ CQkJPC90ZD4JCQkJPC90cj4JCQk8L3RhYmxlPgkJCTx0YWJsZT4JCQkJPHRyPgkJCQkJPHRk PgkJCQkJCTxGT05UIFNJWkU9IjIiIENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+SG9z dCBrZXk6IDcxMDMzODwvRk9OVD4JCQkJCTwvdGQ+CQkJCTwvdHI+CQkJPC90YWJsZT4JCQk8 dGFibGU+PHRyPjx0ZD48Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJp YWwiPk1lZXRpbmcgcGFzc3dvcmQ6PC9GT05UPjwvdGQ+PHRkPjxGT05UIFNJWkU9IjIiICBD T0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPjIySnFFYkZLPC9GT05UPjwvdGQ+PC90cj48 L3RhYmxlPgkJPC9GT05UPjxicj48Rk9OVCBzaXplPSIyIiBDT0xPUj0iI0ZGMDAwMCI+PC9G T05UPjxicj48Rk9OVCBTSVpFPSIxIiBGQUNFPSJBUklBTCI+Jm5ic3A7PEJSPiZuYnNwOzxC Uj48L0ZPTlQ+PEZPTlQgU0laRT0iNCIgRkFDRT0iQVJJQUwiPjxGT05UIFNJWkU9IjMiIENP TE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+Sm9pbiBieSBwaG9uZTwvRk9OVD4mbmJzcDsg PEJSPjxGT05UIFNJWkU9IjIiIENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+PHN0cm9u Zz4xLTg3Ny02NjgtNDQ5Mzwvc3Ryb25nPiZuYnNwO0NhbGwtaW4gdG9sbCBmcmVlIG51bWJl ciAoVVMvQ2FuYWRhKTwvRk9OVD4mbmJzcDsgPEJSPjxGT05UIFNJWkU9IjIiIENPTE9SPSIj NjY2NjY2IiBGQUNFPSJhcmlhbCI+PHN0cm9uZz4xLTY1MC00NzktMzIwODwvc3Ryb25nPiZu YnNwO0NhbGwtaW4gdG9sbCBudW1iZXIgKFVTL0NhbmFkYSk8L0ZPTlQ+Jm5ic3A7IDxCUj48 YSBocmVmPSJodHRwczovL3d3dy53ZWJleC5jb20vcGRmL3RvbGxmcmVlX3Jlc3RyaWN0aW9u cy5wZGYiPjxGT05UIFNJWkU9IjEiIENPTE9SPSIjMDBBRkY5IiBGQUNFPSJhcmlhbCI+VG9s bC1mcmVlIGNhbGxpbmcgcmVzdHJpY3Rpb25zPC9GT05UPjwvYT4gJm5ic3A7IDxCUj48L0ZP TlQ+PEJSPjxCUj4JJm5ic3A7PEJSPgk8Rk9OVCBTSVpFPSIxIiBDT0xPUj0iIzY2NjY2NiIg RkFDRT0iYXJpYWwiPgkJCQlDYW4ndCBqb2luIHRoZSBtZWV0aW5nPzwvRk9OVD4JPGEgaHJl Zj0iaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL21jIj4JPEZPTlQgU0laRT0iMSIgQ09M T1I9IiMwMEFGRjkiIEZBQ0U9IkFyaWFsIj5Db250YWN0IHN1cHBvcnQuPC9GT05UPjwvYT4J Jm5ic3A7PEJSPiZuYnNwOzxCUj48Rk9OVCBDT0xPUj0iI0EwQTBBMCIgc2l6ZT0iMSIgRkFD RT0iYXJpYWwiPklNUE9SVEFOVCBOT1RJQ0U6IFBsZWFzZSBub3RlIHRoYXQgdGhpcyBXZWJF eCBzZXJ2aWNlIGFsbG93cyBhdWRpbyBhbmQgb3RoZXIgaW5mb3JtYXRpb24gc2VudCBkdXJp bmcgdGhlIHNlc3Npb24gdG8gYmUgcmVjb3JkZWQsIHdoaWNoIG1heSBiZSBkaXNjb3ZlcmFi bGUgaW4gYSBsZWdhbCBtYXR0ZXIuIFlvdSBzaG91bGQgaW5mb3JtIGFsbCBtZWV0aW5nIGF0 dGVuZGVlcyBwcmlvciB0byByZWNvcmRpbmcgaWYgeW91IGludGVuZCB0byByZWNvcmQgdGhl IG1lZXRpbmcuPC9GT05UPjwvRk9OVD4KU1VNTUFSWTpBQ0UgaW50ZXJpbSBtZWV0aW5nIHRv IGRpc2N1c3MgQUNFIHJvYWRtYXAKUFJJT1JJVFk6NQpDTEFTUzpQVUJMSUMKQkVHSU46VkFM QVJNClRSSUdHRVI6LVBUNU0KQUNUSU9OOkRJU1BMQVkKREVTQ1JJUFRJT046UmVtaW5kZXIK RU5EOlZBTEFSTQpFTkQ6VkVWRU5UCkVORDpWQ0FMRU5EQVIK --B_3590003183_4629925-- From nobody Wed Oct 4 14:23:25 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE872132D54 for ; Wed, 4 Oct 2017 14:23:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.454 X-Spam-Level: X-Spam-Status: No, score=-0.454 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_06_12=1.543, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=alibaba-inc.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bKamK2v8WuxV for ; Wed, 4 Oct 2017 14:23:22 -0700 (PDT) Received: from out0-229.mail.aliyun.com (out0-229.mail.aliyun.com [140.205.0.229]) (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 283EC1344C9 for ; Wed, 4 Oct 2017 14:23:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1507152199; h=Date:Subject:From:To:Message-ID:Mime-version:Content-type; bh=xfi0NtbHZYm9XkLYue2PKd7jAEQr9XPwvzdvrEy+FB8=; b=DI6mHfKnKj0UYO1QM49eJquzasJmja176AOk+4I+qJy73FQUnJNWAc/LbgcnEipqnToJ/kROHJiPNkZX2W2//Ohp4x/F0wKg1aSukJ7Eb/KINHG2OeGHmHU7GDmExUtrwujNThOx8nYFBm276yQRYVwhHIRJEkBu1RmPrpFeiAI= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R171e4; FP=0|-1|-1|-1|0|-1|-1|-1; HT=e02c03297; MF=kepeng.lkp@alibaba-inc.com; NM=1; PH=DS; RN=3; SR=0; TI=SMTPD_---.92aQSXi_1507152187; Received: from 30.56.242.91(mailfrom:kepeng.lkp@alibaba-inc.com ip:121.0.29.204) by smtp.aliyun-inc.com(127.0.0.1); Thu, 05 Oct 2017 05:23:13 +0800 User-Agent: Microsoft-MacOutlook/14.6.8.160830 Date: Wed, 04 Oct 2017 23:23:04 +0800 From: "Kepeng Li" To: ace CC: Hannes Tschofenig , Kathleen Moriarty Message-ID: Thread-Topic: ACE virtual interim meeting on 19th Oct to discuss certificate enrollment Mime-version: 1.0 Content-type: multipart/mixed; boundary="B_3590004193_4698965" Archived-At: Subject: [Ace] ACE virtual interim meeting on 19th Oct to discuss certificate enrollment 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, 04 Oct 2017 21:23:24 -0000 > ´ËÓʼþʹÓà MIME ¸ñʽ¡£ÓÉÓÚÓʼþÔĶÁ³ÌÐò²»ÄÜʶ±ð ´Ë¸ñʽ£¬Òò´Ë£¬¿ÉÄÜÎÞ·¨Ê¶±ð¸ÃÓʼþµÄ·Ö²¿»ò²¿·ÖÄÚÈÝ¡£ --B_3590004193_4698965 Content-type: multipart/alternative; boundary="B_3590004193_4688235" --B_3590004193_4688235 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit Hello all, Please find the WebEx meeting information for our second call on certificate enrollment. We need to find a volunteer to prepare materials for the discussion. Please contact Hannes and me if you want to do so. ACE virtual interim meeting on 19th Oct to discuss certificate enrollment Thursday, October 19, 2017 1:00 pm | Greenwich Time (Reykjavik, GMT) | 1 hr Meeting number (access code): 317 298 947 Meeting password: EBZNCJjN Add to Calendar When it's time, join the meeting . Join by phone 1-877-668-4493 Call-in toll free number (US/Canada) 1-650-479-3208 Call-in toll number (US/Canada) Toll-free calling restrictions Can't join the meeting? 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. By joining this session, you automatically consent to such recordings. If you do not consent to being recorded, discuss your concerns with the host or do not join the session. --B_3590004193_4688235 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

<= tr>
Hello all,
Please find the WebEx meeting information for our second ca= ll on certificate enrollment.




 We = need to find a volunteer to prepare materials for the discussion. Please con= tact Hannes and me if you want to do so. 

ACE virtual interim meeting on 19th Oct to discuss certificate = enrollment
Thursday, October 19, 2017
1:00 pm  |  Greenwich Time (Reykjavik, GMT)=   |  1 hr
Meeting number (access code): 317 298 947
Meeting password: EBZNCJjN


&nbs= p;
Add to Calendar
When it's time, join the meeting.
&nbs= p;
Join by phone
1-877-668-4493 Call-in toll free num= ber (US/Canada)
1-650-479-3208&nb= sp;Call-in toll number (US/Canada)
Toll-free calling restrictions
 
Can't join the meeting?
 
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. By joining this session, you automatically c= onsent to such recordings. If you do not consent to being recorded, discuss = your concerns with the host or do not join the session.
--B_3590004193_4688235-- --B_3590004193_4698965 Content-type: application/octet-stream; name="WebEx_Meeting.ics"; x-mac-creator="4F50494D"; x-mac-type="49637320" Content-disposition: attachment; filename="WebEx_Meeting.ics" Content-transfer-encoding: base64 QkVHSU46VkNBTEVOREFSClBST0RJRDotLy9NaWNyb3NvZnQgQ29ycG9yYXRpb24vL091dGxv b2sgMTAuMCBNSU1FRElSLy9FTgpWRVJTSU9OOjIuMApNRVRIT0Q6UkVRVUVTVApCRUdJTjpW VElNRVpPTkUKVFpJRDpHcmVlbndpY2ggVGltZQpCRUdJTjpTVEFOREFSRApEVFNUQVJUOjIw MTUwMTAxVDAwMDAwMApUWk9GRlNFVEZST006KzAwMDAKVFpPRkZTRVRUTzorMDAwMApUWk5B TUU6U3RhbmRhcmQgVGltZQpFTkQ6U1RBTkRBUkQKRU5EOlZUSU1FWk9ORQpCRUdJTjpWRVZF TlQKQVRURU5ERUU7Q049IiI7Uk9MRT1SRVEtUEFSVElDSVBBTlQ7UlNWUD1UUlVFOk1BSUxU TzprZXBlbmcubGtwQGFsaWJhYmEtaW5jLmNvbQpPUkdBTklaRVI7Q049IkFDRSBXb3JraW5n IEdyb3VwIjpNQUlMVE86YWNlLWNoYWlyc0BpZXRmLm9yZwpEVFNUQVJUO1RaSUQ9IkdyZWVu d2ljaCBUaW1lIjoyMDE3MTAxOVQxMzAwMDAKRFRFTkQ7VFpJRD0iR3JlZW53aWNoIFRpbWUi OjIwMTcxMDE5VDE0MDAwMApMT0NBVElPTjpodHRwczovL2lldGYud2ViZXguY29tL2lldGYK VFJBTlNQOk9QQVFVRQpTRVFVRU5DRToxNTA3MTUxNDY0ClVJRDphYTExN2QxZi03ZDgzLTRm ZDctYjcyZS1hMGZjMjVjNGI3MzMKRFRTVEFNUDoyMDE3MTAxOVQxMzAwMDBaCkRFU0NSSVBU SU9OOlxuXG5cblxuSk9JTiBXRUJFWCBNRUVUSU5HXG5odHRwczovL2lldGYud2ViZXguY29t L2lldGYvai5waHA/TVRJRD1tMmRiYTk4ZWI1NjMxM2U3ZGExOTgwODRjY2I4M2YwNmJcbk1l ZXRpbmcgbnVtYmVyIChhY2Nlc3MgY29kZSk6IDMxNyAyOTggOTQ3XG5NZWV0aW5nIHBhc3N3 b3JkOiBFQlpOQ0pqTlxuXG5cblxuSk9JTiBCWSBQSE9ORVxuMS04NzctNjY4LTQ0OTMgQ2Fs bC1pbiB0b2xsIGZyZWUgbnVtYmVyIChVUy9DYW5hZGEpIFxuMS02NTAtNDc5LTMyMDggQ2Fs bC1pbiB0b2xsIG51bWJlciAoVVMvQ2FuYWRhKVxuXG5Ub2xsLWZyZWUgZGlhbGluZyByZXN0 cmljdGlvbnM6IFxuaHR0cHM6Ly93d3cud2ViZXguY29tL3BkZi90b2xsZnJlZV9yZXN0cmlj dGlvbnMucGRmXG5cblxuXG5DYW4ndCBqb2luIHRoZSBtZWV0aW5nP1xuaHR0cHM6Ly9oZWxw LndlYmV4LmNvbS9kb2NzL0RPQy01NDEyXG5cblxuSU1QT1JUQU5UIE5PVElDRTogUGxlYXNl IG5vdGUgdGhhdCB0aGlzIFdlYkV4IHNlcnZpY2UgYWxsb3dzIGF1ZGlvIGFuZCBvdGhlciBp bmZvcm1hdGlvbiBzZW50IGR1cmluZyB0aGUgc2Vzc2lvbiB0byBiZSByZWNvcmRlZCwgd2hp Y2ggbWF5IGJlIGRpc2NvdmVyYWJsZSBpbiBhIGxlZ2FsIG1hdHRlci4gQnkgam9pbmluZyB0 aGlzIHNlc3Npb24sIHlvdSBhdXRvbWF0aWNhbGx5IGNvbnNlbnQgdG8gc3VjaCByZWNvcmRp bmdzLiBJZiB5b3UgZG8gbm90IGNvbnNlbnQgdG8gYmVpbmcgcmVjb3JkZWQsIGRpc2N1c3Mg eW91ciBjb25jZXJucyB3aXRoIHRoZSBob3N0IG9yIGRvIG5vdCBqb2luIHRoZSBzZXNzaW9u LlxuClgtQUxULURFU0M7Rk1UVFlQRT10ZXh0L2h0bWw6CTxGT05UIFNJWkU9IjEiIEZBQ0U9 IkFSSUFMIj4mbmJzcDs8QlI+Jm5ic3A7PEJSPiZuYnNwOzxCUj48Rk9OVCBTSVpFPSI0IiBG QUNFPSJBUklBTCI+CQk8YSBocmVmPSJodHRwczovL2lldGYud2ViZXguY29tL2lldGYvai5w aHA/TVRJRD1tMmRiYTk4ZWI1NjMxM2U3ZGExOTgwODRjY2I4M2YwNmIiPjxGT05UIFNJWkU9 IjMiIENPTE9SPSIjMDBBRkY5IiBGQUNFPSJBcmlhbCI+Sm9pbiBXZWJFeCBtZWV0aW5nPC9G T05UPjwvYT4JCQk8dGFibGU+CQkJCTx0cj4JCQkJCTx0ZD4JCQkJCQk8Rk9OVCBTSVpFPSIy IiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPk1lZXRpbmcgbnVtYmVyIChhY2Nlc3Mg Y29kZSk6IDMxNyAyOTggOTQ3PC9GT05UPgkJCQkJPC90ZD4JCQkJPC90cj4JCQk8L3RhYmxl PgkJCQkJCTx0YWJsZT48dHI+PHRkPjxGT05UIFNJWkU9IjIiIENPTE9SPSIjNjY2NjY2IiBG QUNFPSJhcmlhbCI+TWVldGluZyBwYXNzd29yZDo8L0ZPTlQ+PC90ZD48dGQ+PEZPTlQgU0la RT0iMiIgIENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+RUJaTkNKak48L0ZPTlQ+PC90 ZD48L3RyPjwvdGFibGU+CQk8L0ZPTlQ+PGJyPjxGT05UIHNpemU9IjIiIENPTE9SPSIjRkYw MDAwIj48L0ZPTlQ+PGJyPjxGT05UIFNJWkU9IjEiIEZBQ0U9IkFSSUFMIj4mbmJzcDs8QlI+ Jm5ic3A7PEJSPjwvRk9OVD48Rk9OVCBTSVpFPSI0IiBGQUNFPSJBUklBTCI+PEZPTlQgU0la RT0iMyIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj5Kb2luIGJ5IHBob25lPC9GT05U PiZuYnNwOyA8QlI+PEZPTlQgU0laRT0iMiIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFs Ij48c3Ryb25nPjEtODc3LTY2OC00NDkzPC9zdHJvbmc+Jm5ic3A7Q2FsbC1pbiB0b2xsIGZy ZWUgbnVtYmVyIChVUy9DYW5hZGEpPC9GT05UPiZuYnNwOyA8QlI+PEZPTlQgU0laRT0iMiIg Q09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj48c3Ryb25nPjEtNjUwLTQ3OS0zMjA4PC9z dHJvbmc+Jm5ic3A7Q2FsbC1pbiB0b2xsIG51bWJlciAoVVMvQ2FuYWRhKTwvRk9OVD4mbmJz cDsgPEJSPjxhIGhyZWY9Imh0dHBzOi8vd3d3LndlYmV4LmNvbS9wZGYvdG9sbGZyZWVfcmVz dHJpY3Rpb25zLnBkZiI+PEZPTlQgU0laRT0iMSIgQ09MT1I9IiMwMEFGRjkiIEZBQ0U9ImFy aWFsIj5Ub2xsLWZyZWUgY2FsbGluZyByZXN0cmljdGlvbnM8L0ZPTlQ+PC9hPiAmbmJzcDsg PEJSPjwvRk9OVD48QlI+PEJSPgkmbmJzcDs8QlI+CTxhIGhyZWY9Imh0dHBzOi8vaGVscC53 ZWJleC5jb20vZG9jcy9ET0MtNTQxMiI+CTxGT05UIFNJWkU9IjEiIENPTE9SPSIjMDBBRkY5 IiBGQUNFPSJBcmlhbCI+Q2FuJ3Qgam9pbiB0aGUgbWVldGluZz88L0ZPTlQ+PC9hPgkmbmJz cDs8QlI+Jm5ic3A7PEJSPjxGT05UIENPTE9SPSIjQTBBMEEwIiBzaXplPSIxIiBGQUNFPSJh cmlhbCI+SU1QT1JUQU5UIE5PVElDRTogUGxlYXNlIG5vdGUgdGhhdCB0aGlzIFdlYkV4IHNl cnZpY2UgYWxsb3dzIGF1ZGlvIGFuZCBvdGhlciBpbmZvcm1hdGlvbiBzZW50IGR1cmluZyB0 aGUgc2Vzc2lvbiB0byBiZSByZWNvcmRlZCwgd2hpY2ggbWF5IGJlIGRpc2NvdmVyYWJsZSBp biBhIGxlZ2FsIG1hdHRlci4gQnkgam9pbmluZyB0aGlzIHNlc3Npb24sIHlvdSBhdXRvbWF0 aWNhbGx5IGNvbnNlbnQgdG8gc3VjaCByZWNvcmRpbmdzLiBJZiB5b3UgZG8gbm90IGNvbnNl bnQgdG8gYmVpbmcgcmVjb3JkZWQsIGRpc2N1c3MgeW91ciBjb25jZXJucyB3aXRoIHRoZSBo b3N0IG9yIGRvIG5vdCBqb2luIHRoZSBzZXNzaW9uLjwvRk9OVD48L0ZPTlQ+ClNVTU1BUlk6 QUNFIHZpcnR1YWwgaW50ZXJpbSBtZWV0aW5nIG9uIDE5dGggT2N0IHRvIGRpc2N1c3MgY2Vy dGlmaWNhdGUgZW5yb2xtZW50ClBSSU9SSVRZOjUKQ0xBU1M6UFVCTElDCkJFR0lOOlZBTEFS TQpUUklHR0VSOi1QVDVNCkFDVElPTjpESVNQTEFZCkRFU0NSSVBUSU9OOlJlbWluZGVyCkVO RDpWQUxBUk0KRU5EOlZFVkVOVApFTkQ6VkNBTEVOREFSCg== --B_3590004193_4698965-- From nobody Mon Oct 9 04:48:01 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2945134517 for ; Mon, 9 Oct 2017 04:47:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.401 X-Spam-Level: X-Spam-Status: No, score=-5.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 60hx-h-R3x0u for ; Mon, 9 Oct 2017 04:47:55 -0700 (PDT) Received: from se-out2.mx-wecloud.net (se-out2.mx-wecloud.net [89.221.255.177]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22741134518 for ; Mon, 9 Oct 2017 04:47:47 -0700 (PDT) Received: from sp-mail-2.sp.se (unknown [194.218.146.197]) by se-out2.mx-wecloud.net (Postfix) with ESMTPS id 95081221234; Mon, 9 Oct 2017 11:47:45 +0000 (UTC) Received: from [192.168.0.166] (10.116.0.226) by sp-mail-2.sp.se (10.100.0.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.669.32; Mon, 9 Oct 2017 13:47:45 +0200 To: Mike Jones , "ace@ietf.org" References: From: Ludwig Seitz Message-ID: <70d9981f-3e4d-7389-5281-938618f1d3c1@ri.se> Date: Mon, 9 Oct 2017 13:47:44 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [10.116.0.226] X-ClientProxiedBy: sp-mail-2.sp.se (10.100.0.162) To sp-mail-2.sp.se (10.100.0.162) X-CMAE-Score: 0 X-CMAE-Analysis: v=2.2 cv=KqQ94SeN c=1 sm=1 tr=0 a=L5DDne6A+dD0FbDkt2Fblw==:117 a=L5DDne6A+dD0FbDkt2Fblw==:17 a=sZ8rJzgPlrQA:10 a=N659UExz7-8A:10 a=02M-m0pO-4AA:10 a=48vgC7mUAAAA:8 a=NEAV23lmAAAA:8 a=I0CVDw5ZAAAA:8 a=TXYz5_4QjbeewaRuK0gA:9 a=U0PlRQbKV-T0Kf_F:21 a=LUaYOS0AC8H4-iiq:21 a=pILNOxqGKmIA:10 a=w1C3t2QeGrPiZgrLijVG:22 a=YdXdGVBxRxTCRzIkH2Jn:22 X-Virus-Scanned: clamav-milter 0.99.2 at MailSecurity X-Virus-Status: Clean X-MailSecurity-Status: 0 X-Scanned-By: WeCloud MailSecurity X-MailSecurity-Score: 0 Archived-At: Subject: Re: [Ace] Review of draft-ietf-ace-oauth-authz-07 by Mike Jones 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, 09 Oct 2017 11:48:00 -0000 Hello Mike, thank you very much for your detailed review. There are two general points I'd like to address here to avoid repeating myself in the detailed comments below. 1.) You strongly recommend against using the client credentials grant. I get the feeling we have fundamentally different understandings of how that grant is used. For example I'm puzzled by your statement: "The client should never have the user’s credentials". This sounds more like the "Resource Owner Password Credentials" grant. I was under the impression that with the client credentials grant the client would be issued (or not issued) an access token solely based on its own credentials, thus it would _not_ have access to the user's credentials. This was exactly the reason I chose this grant type over those involving user generated grants. Machine-to-machine communication is probably the most common scenario for ACE, and I don't quite see how the manual user interactions for providing grants fit well into such a setting. The text in the OAuth spec seems to support my point of view: "Client credentials are used as an authorization grant typically when the client [...] is requesting access to protected resources based on an authorization previously arranged with the authorization server." ( see https://tools.ietf.org/html/rfc6749#section-1.3.4 ) 2.) Your main criticism is that we have made extensions to OAuth mandatory and implicit. I fully agree with the second part of your criticism, the parts of the ACE framework that are extensions to OAuth should be more clearly marked as such, and I will update the draft accordingly. I will also update Appendix A to give more concrete design justifications for each of these extensions. However I strongly disagree with your suggestion to make all these extensions optional. ACE is intended to make OAuth "constrained friendly", if we don't make any requirements, how is this supposed to work? Any implementation of plain OAuth could then just claim conformance with the ACE framework, which is definitely wrong! My suggestion would be to make the use of CBOR as data format mandatory, as well as the use of the abbreviated request/response parameters, claim names, and error codes. I however agree with your suggestion to make the use of CoAP optional (since you correctly commented that there are many other communication protocols that may use ACE). I would still use it as the baseline example in the framework, and leave it to the profiles that do not use CoAP to define mappings of e.g. the RESTful method, response and error codes. Please find detailed comments inline. /Ludwig On 2017-10-02 11:11, Mike Jones wrote: > Having read the spec cover-to-cover, it surprised me how different this > is from OAuth, despite the statements that it is based on OAuth.  My > highest-priority request is to make all the extensions to OAuth defined > in this document optional, so that profiles could use actual OAuth, > which currently doesn’t seem to be possible.  Much of this draft written > in a way that huge OAuth extensions are obliquely assumed when > describing other features, without any clear definitions or > justifications for them when they are introduced in passing.  These > things need to be teased apart, with references to sections actually > defining and justifying each extension, rather than assuming that many > of them exist in passing in other sections. > See above > Detailed substantive comments on specific document text follow. > Editorial nits are communicated in the accompanying pull request > https://github.com/LudwigSeitz/ace-oauth/pull/112. > Done > Title > > The current title “Authentication and Authorization for Constrained > Environments (ACE)” doesn’t match the scope of what’s in the spec, as > the spec is only about resource authorization but not authentication. > Please change the title to “Resource Authorization Framework for > Constrained Environments” or something similar.  (Authentication would > require defining the equivalent of an OpenID Connect ID Token to convey > authentication information, but this is entirely absent from the > specification.) > > 1.  Introduction > > The introduction defines what it means by “authorization” by doesn’t say > what it is referring to by “authentication”.  This provides more > evidence that “authentication” does not belong in the title or > abstract.  Please remove the passing references to the underspecified > concept “authentication” from the introduction and the abstract.  (Note > that while “OAuth client authentication” is a limited form of > authentication, its use as a mechanism in the spec does not justify > saying that the spec is defining authentication for its use cases in any > general sense of the term.) > When I included 'Authentication' in the title I was thinking about device authentication, and the fact that the AS facilitates establishing authentication credentials between C and RS in this draft. I take it from your comments that you don't think that this is authentication enough. > 2.  Terminology > > The “/” syntax for endpoint names, such as “/token” is misleading, as it > seems to imply that these endpoints use particular pathnames.  Please > replace all uses of “/endpoint-name” with just “endpoint-name”. >Already done in the editor's copy > 2.  Terminology > > References are needed for the first uses of many of the terms and > abbreviations used.  For instance, you’re using abbreviations like “AS”, > “RS”, and “IoT” without saying what they refer to. > I will re-check the terminology section for missing abbreviations. > 2.  Terminology > > Please change all uses of the word “introspect” to “introspection” when > referring to the introspection endpoint. > Done. > 2.  Terminology > > You introduce an “authz-info” endpoint in the terminology section, when > this isn’t commonly understood.  You need a section reference following > the first use of this concept. > Ok, will do. > 3.1 OAuth 2.0 – token and introspect endpoints > > This section is the first of many places in which the text is written in > a way that assumes that introspection will be implemented and used. > This needs to be corrected throughout the document, appropriately > qualifying descriptions of introspection saying that some profiles may > use it and others will not.  For instance, the draft says “The token > introspection endpoint, /introspect, is used by the RS when requesting > additional information regarding a received access token.”  Please > change this so something more like “In some profiles, a token > introspection endpoint may be present and used by the RS to request > additional information about a received access token.”  You should also > clearly state that introspection is unnecessary and adds overhead that > can be avoided when the resource server understands the access token > format, such as when it is a CWT. > Agree, I will change the text to clarify that introspection is always optional. > > 3.1 OAuth 2.0 – Proof of Possession Tokens > > The draft uses the term “proof of possession token” to denote an access > token supporting proof of possession.  Note however, that there are many > other kinds of proof of possession tokens other than just access > tokens.  Please change all uses of the term “proof of possession token” > to “proof of possession access token” or “access token supporting proof > of possession”.  Similarly, change all uses of the term “PoP token” to > “PoP access token”. I was hoping to avoid such Wagnerian word monsters, but I see your point. Unless someone has a good suggestion to make the name of these things shorter and still convey the meaning, I will implement that change. > > 3.1 OAuth 2.0 – Scopes and Permissions > > This section contains another example of an extension to OAuth being > assumed, when for many profiles it won’t be necessary.  The draft says > “In turn, the AS may use the scope response parameter to inform the > client of the scope of the access token issued.”  This assumes that a > “scope” response will be added to all participating OAuth > implementations, without justifying this addition to the standard.  At > most, this section should refer to another section which defines an > optional “scope” response parameter and describes the circumstances in > which profiles would and would not need it. I don't quite see what you mean here. Scope is used in the same way it is used in the OAuth 2.0 spec, i.e. it is optional, as the words "may use the scope response parameter" indicate. > > 3.1 OAuth 2.0 – Scopes and Permissions > > Likewise, the draft says “As the client could be a constrained device as > well, this specification uses CBOR encoded messages for CoAP”.  This is > one of many places in the draft that it’s assumed that CBOR and COAP > will be used rather than JSON and HTTP.  The framework draft should > explicitly leave these choices up to profiles. > See general answer. > 4. Protocol Interactions > > Please do not in any way endorse using the Client Credentials grant – > which defeats the purpose of even having OAuth.  The client should never > have the user’s credentials!  At most, you should say that while the > Client Credentials grant may be used for some scenarios, it has known > security and privacy flaws and its use is deprecated. > See general answer. > 4. Protocol Interactions > > The sentence “In such a case the resource owner or another person on his > or her behalf have arranged with the authorization server out-of-band, > which is often accomplished using a commissioning tool.” needs > clarification.  What has been arranged? > Right, that sentence has been mangled. Will fix. > Figure 1: Basic Protocol Flow > > This is yet another place where a major OAuth extension is assumed, > without clear justification.  The diagram adds “+ RS Information” to the > authorization server response to the client, when this isn’t a normal > part of OAuth and not defined. At least, please indicate that this is > optional and refer to a section that defines and justifies this optional > extension, rather than assuming in passing that it’s been added. >This wouldn't qualify as a "major extension" in my world, the protocol is just returning a few additional parameters to enable proof-of-possession and the use of different communication/communication-security profiles. Note that e.g. draft-ietf-oauth-pop-key-distribution also returns additional parameters ('key') together with the access token response. We just gave those additional parameters a name to be able to refer to them collectively. > Figure 1: Basic Protocol Flow > > Please rework this diagram to illustrate that introspection is optional > (and wastes resources by performing unnecessary communication). > Agreed. > 4. Protocol Interactions – Access Token Response > > This also assumes the existence of “RS Information”.  At least, say that > “Some profiles may choose to return information about the resource > servers” and reference a section describing this optional feature, > rather than write the text in a way that assumes its existence. > See above. > 4. Protocol Interactions – Access Token Response > > This also assumes the existence of profile information in the response. > This would normally be implicit.  Again, please do not write the draft > in a way that assumes the presence of extensions that are often not needed. > Indeed it makes sense to make the profile information an optional element in cases where it is implicitly known. I will modify the text to clarify this. > 4. Protocol Interactions – Resource Request > > The two-part request described in the third paragraph is not OAuth, nor > is there any justification for adding additional steps.  Likewise, the > language in paragraph 4 about “comparing the claims in the access token > with the resource request” is a highly specific extension that is not > normal OAuth.  Please refactor this description to clearly delineate > what’s OAuth and what are optional extensions – referencing specific > sections that define these extensions. > The justification for this was discussed at the interim meeting between IETF 94 and 95 (https://datatracker.ietf.org/meeting/interim-2016-ace-01/materials/slides-interim-2016-ace-1-2/), I will provide a summary in Appendix A to clarify why this was designed that way. > 4. Protocol Interactions – Token Introspection Request > > Please rework this section to describe that introspection is optional > (and wastes resources by performing unnecessary communication). > Describe how things are simpler and more efficient when the resource > directly understands the contents of the access token. > See comment above. > 4. Protocol Interactions – Token Introspection Response > > This section adds yet another OAuth extension on the fly – the “client > token” – again with no justification or clear definition.  Please remove > the oblique “client token” reference here. > We designed the client token in order to solve use cases where the client is constrained and has no direct means to communicate with the AS at the time of the resource access. If you have a better suggestion on how to solve this, that is more in line with OAuth, I'd be grateful to hear about it. > 5. Framework – Proof-of-Possession > > After “The binding is provided by the "cnf" claim” add references to > [RFC 7800] and [draft-ietf-ace-cwt-proof-of-possession]. > Ok > 5. Framework – Proof-of-Possession > > The text currently includes “update a token”.  Shouldn’t this actually > be “get a new token”, since an existing access token can’t be updated? > Right. Will clarify the text. > 5.1 Authorization Grants > > This section includes the phrase “client credentials grant is > recommended”.  Because of the security and privacy problems with the > client credentials grant, please rework this section to ensure that > implementers and profile writers understand that the use of client > credentials grant is never recommended, including describing why that is > the case. > See general comment. > 5.1 Authorization Grants > > Reference [RFC 6749] after you say “see the OAuth 2.0 framework”. > Ok > 5.2 Client Credentials > > After you say that “the OAuth framework defines one client credential > type”, you should also describe that RFC 7522 and RFC 7523 define > additional kinds of client credentials that may be used. > I'm not sure how relevant these credential types are for constrained environments. For example RFC 7522 refers to SAML, which generally is way too verbose for constrained environments. I guess we could refer to RFC 7523 but with the caveat that CBOR/CWT is the preferred/mandatory format in ACE. > 5.4 The Authorize Endpoint > > Change all occurrences of “authorize endpoint” to “authorization endpoint”. > Ok > 5.5 The Token Endpoint > > Rather than saying that “this framework extends”, say that the framework > defines optional extensions and reference their definitions and > justifications. > See general discussion. I'm OK with providing more concrete design justifications in Appendix A. > 5.5 The Token Endpoint > > Change “this framework defines encodings using CoAP and CBOR, as a > substitute for HTTP and JSON” in a way that allows profiles to make > either choice. See general comment. > > 5.5.1 Client-to-AS Request > > This section is another place in which this specification is making > assumptions about choices that rightfully belong to profiles.  It starts > with “The client sends a CoAP POST request”.  Profiles may choose to use > CoAP or they may choose to use HTTP.  Please reword this so that it says > something more like “The client sends a CoAP or HTTP POST request, > depending upon the profile”.  Please likewise generalize the description > of the framework so that it’s clear that the choice between CoAP or HTTP > is up to the profile.  Heck, Bluetooth Smart is another transport that’s > possible, which this spec shouldn’t preclude! > I'm Ok with some language that allows profiles to specify other transport protocols (like Bluetooth low energy), but I'd like to keep CoAP as the baseline, to be able to specify request and response codes in some meaningful way. It would then be up to the profile that uses another transport protocol to define mappings. > 5.5.1 Client-to-AS Request > > This is again written in such a way that it assumes that the additional > parameters will be implemented and used, which won’t be necessary for > some profiles.  It starts “In addition to these parameters, this > framework defines the following parameters”.  Qualify this by saying > that some profiles may choose to implement and use the following OAuth > extension parameters. > These parameters (aud and cnf) are already optional, I don't quite understand what more you are suggesting, could you clarify? > 5.5.1 Client-to-AS Request – aud > > The OAuth Token Exchange spec uses the “audience” parameter for this > functionality.  See > https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-09#section-2.1. > Please reference this spec and use the same parameter name. > Is there a difference between the semantics of the 'aud' claim from JWT and the 'audience' parameter from this draft? I'd rather use semantics that are defined in a stable RFC, than referring to work in progress. > 5.5.1 Client-to-AS Request – aud > > The spec says that “If a client submits a request for an access token > without specifying an "aud" parameter, and the AS does not have a > default "aud" value for this client, then the AS MUST respond with an > error message”.  This violates the OAuth principle that implementations > must ignore parameters that they do not understand. > https://tools.ietf.org/html/rfc6749#section-3.1 says “The authorization > server MUST ignore unrecognized request parameters”.  Rework this to say > that it’s perfectly legitimate for participants to ignore the “aud” > parameter when they don’t implement or understand it. > How would a regular OAuth 2.0 AS react to an access token request for which it doesn't know which audience it is supposed to address? I think that this must be either implicit or given by the 'aud' parameter as suggested in https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-03#section-3. > 5.5.2 AS-to-Client Response > > Once again, extensions to OAuth are implicitly required – in this case > the “profile” and “cnf” parameters.  Reword to make these choices > available to profiles. I see your point for the profile parameter, given that it could be implicit. I have my doubts though that 'cnf' could ever be implicit, do you have any case in mind (that uses proof-of-possession) where that would be the case? > > 5.5.2 AS-to-Client Response – profile > > This certainly shouldn’t be required, as the profile knowledge will be > implicit in most OAuth deployments.  Very rare indeed will the cases in > which participants will support multiple profiles. > Ok > 5.5.2 AS-to-Client Response > > The spec says that “Figure 5 summarizes the parameters that may be part > of the RS Information”.  However the term “RS information” is > undefined.  Instead, change this sentence to say  “Figure 5 summarizes > the parameters that may be part of the token response”. > The term "RS Information" is defined in section 4, bullet point B. Since that is obviously too well hidden. I will move that definition to the terminology section. > 5.5.2 AS-to-Client Response – Figure 6 > > I suggest removing “profile” from the example, as this is unnecessary > protocol bloat. If we remove it, we should add some explanatory text that states that the profile is implicit in that case. > > 5.5.3 Error Response > > The spec says “The error codes MAY be abbreviated using the codes > specified in table Figure 7”.  Again, whether to do this is a profile > choice.  Making it optional only makes all implementations bigger > because they have to support both choices.  Reword to say that profiles > will specify whether error codes are abbreviated in this manner or not. > See general comment. > 5.5.3 Error Response – Figure 7 > > These values should be in a registry – possibly called something like > “OAuth error code CBOR value mappings”.  This registry should reference > the values registered in the OAuth Extensions Error Registry at > https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#extensions-error. > Correct. Will fix. > 5.5.4.1 Audience > > Reference the audience parameter in > https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-09#section-2.1 > and indicate that whether it is used a profile-specific choice. > See discussion above (5.5.1 Client-to-AS Request – aud) > 5.5.4.1 Audience > > The spec says that “It should be encoded as CBOR text string”.  Again, > reword this to say that it’s a profile choice whether to use CBOR or > standard OAuth. > See general comment. > 5.5.4.2 Grant Type > > Rather than saying “MAY”, say that the profile specifies the > representation that it used. > I would actually rather make the abbreviated representations mandatory for the reasons given in my general comment. > 5.5.4.2 Figure 8 > > These values should be in a registry – possibly called something like > “OAuth grant type CBOR value mappings”.  This registry should reference > the sections defining these values in RFC 6749 and the grant type values > defined by RFC 7522 and RFC 7523. > Correct. Will fix. > 5.5.4.3 Token Type > > Reference draft-ietf-oauth-pop-key-distribution for the definition of > the “pop” token_type. > I was under the impression that this draft was dead. Is it really acceptable to reference this type of work in a normative way? I've given that draft a paragraph in the Acknowledgment section. > 5.5.4.3 Token Type > > When you say that “The values in the ‘token_type’ parameter MUST be CBOR > text strings”, you’re again implicitly making choices that belong to > profiles.  Please generalize this description. > > See general comment. > 5.5.4.4 Profile > > Whether “profile” is even needed is up to the profile.  Typically it > will be implicit, since implementations will use a single profile. > Please revise accordingly. > Agree. > 5.5.4.5 Confirmation > > Please replace the definition of “cnf” for CBOR here with references to > RFC 7800 and draft-ietf-ace-cwt-proof-of-possession. > Note that we use "cnf" here as a request and response parameter. I do refer to draft-ietf-ace-cwt-proof-of-possession, but that draft only defines "cnf" as a CWT claim, so I still feel the need to specify its semantically equivalent use as a req/resp parameter. > 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. Correct > If so, the spec should make this relationship explicit. Will do. > 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.) > Why would we want to artificially increase the size of the framework parameters coming from OAuth? (like e.g. code, access_token etc) This feels counter-productive, they are by no means application-specific, these are used in basic OAuth 2.0. We should do a case-by-case evaluation. Also as for registering those into the CWT claims registry, I feel that would not be a good fit, since we are using those as request/response parameters in the different OAuth/ACE protocol messages, while CWT registers claim values. I see a mismatch here don't you? > 5.6 The Introspect Endpoint > > First, change introspect to introspection.  And like other places, state > that it is up to the profile whether to use introspection at all, and if > so, whether to use standard introspection syntax or the CoAP/CBOR version. > Agree with the first part, disagree with allowing other encodings than CBOR. > 5.6.2 AS-to-RS Response – Figure 15 > > Remove profile and client_token from this example, since both are pretty > esoteric and not likely to be used in the common case. > As to whether the example should include optional parameters, I have no strong opinion, although their absence in examples makes it harder to understand their intended use. > 5.6.4 Client Token > > I agree with Hannes’ review of this feature: “/The "Client Token" is > somewhat experimental and not on par with the rest of the document in > terms of maturity and alignment with OAuth. I would prefer this > functionality to be covered in a separate document, if someone still > cares about it. While OAuth has seen a lot of formal analysis this > feature obviously hasn't./”  Please remove this from the specification > and if you still believe in it, place it in a separate document for > independent consideration by the working group. > See comment above (4. Protocol Interactions – Token Introspection Response) > 5.6.4 Client Token > > The spec says “The client is pre-configured with a generic, long-term > access token when it is commissioned.”  This hardly seems secure – > especially since secrets can often be extracted from deployed software. > I don't see how this is less secure than a client that doesn't have a long-term token, but instead the credentials/grants that allow it to retrieve fresh tokens from the AS. These credentials can just as easily be extracted and misused if the client is stolen. > 5.6.4 Client Token > > The spec says “The RS then performs token introspection to learn what > access this token grants.”  Again, this is unnecessary if the resource > understands the claims in the access token. The text is probably not well written in that section. The token is intended to just be a reference, not a full CWT. Thus it would not contain any claims that the RS can process independently. I will try to clarify this. > > 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.) > Same comments as before apply (5.5.5 Mapping parameters to CBOR) > 5.7 The Access Token > > Reference [RFC 7800] and [draft-ietf-ace-cwt-proof-of-possession] when > describing the use of “cnf”. > The text does reference RFC 7800, I failed to update this section after we moved the 'cnf' specification to draft-ietf-ace-cwt-proof-of-possession. Will fix. > 5.7.1 The Authorization Information Endpoint > > Please describe the relationship between this endpoint and the resource > endpoint used by RFC 6750. > I can't find a reference to a resource endpoint in RFC 6750. Are you sure this is the right reference? > 5.7.1 The Authorization Information Endpoint > > Again, please clarify that support for this OAuth extension, the use of > CoAP, and the use of introspection are all choices up to particular > profiles. > This will just yield us a lot of incompatibility. Note that profiles are free to define additional methods of token transfer. > 5.7.1 The Authorization Information Endpoint > > The spec says “The RS MUST be prepared to store more than one token for > each client, and MUST apply the combined permissions granted by all > applicable, valid tokens to client requests.”  This seems really overly > specific for a framework spec.  Simple systems will likely only have one > token per client, let alone not supporting complex permission > combination logic!  Please remove this statement. > Ok > 5.7.2 Token Expiration > > Rather than saying “CWT/JWT” expand this to “CWT or JWT” for readability. > I'm actually considering to remove JWT entirely instead. See general discussion. > 6. Security Considerations > > Add a reference upon first use of the term “AEAD”. Ok > > 7. Privacy Considerations > > The spec says “The latter may reveal the client's identity.”  What is > meant by the client’s identity? The identity of the specific device running the client application. > What kinds of information does this > entail and what are the privacy risks associated with it?  How does the > client’s identity relate to the identities of people who may be > associated with the system in some way? The user owning that device might be linkable to the device identity. Therefore that user's privacy might be at stake. It seems this paragraph needs clarification. > > 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. > Ok > 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. > Right, will remove. > 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. > Ok > 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. > Ok > 8.5 CBOR Web Token Claims > > Consider using the “scp” claim defined at > https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-09#section-4.2 > rather than “scope”.  If you don’t, at least say why you are introducing > a different claim to convey the same information. > It is my understanding that "scp" is defined as an array of scopes, which in turn are a space delimited list of strings. I thus felt that "scp" was unnecessarily introducing a doubly nested list of scope-tokens, which is the reason why I choose not to use it. > 8.5 CBOR Web Token Claims > > “cnf” is already being registered by draft-ietf-ace-cwt-proof-of-possession. > Correct, this should already be removed in the editor's draft. > 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. > Ok > 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. > Ok > 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 previous comments (5.5.5 Mapping parameters to CBOR). > 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. > Ok > 8.10 CWT Confirmation Methods Registry > > Delete this section, as it has been moved to > draft-ietf-ace-cwt-proof-of-possession. > Ok > Appendix A. Design Justification – Communication Constraints > > Add that power saving may be another reason for communication constraints. > I plan to completely rewrite that section to provide detailed justifications for the different changes to OAuth 2.0 we made. I will make sure to include some text on power consumption. > Appendix B. Roles and Responsibilities – Authorization Server > > Add that enabling discovery of the AS’s capabilities via metadata is > likely in scope.  Reference draft-ietf-oauth-discovery. > Ok > Appendix B. Roles and Responsibilities – Client > > What do the parenthetical letters such as “(A)” refer to?  Why are “(D)” > and “(E)” missing? > They refer the steps in figure 1. I will add some text to clarify this. > Appendix C. Requirements on Profiles > > You should be much more clear in this section that choices of JSON vs. > CBOR, JWT vs. CWT, HTTP versus COaP, PoP versus Token Binding, > Introspection or not, authz-info endpoint or not, etc. must be made by > profiles. See general comments. > Appendix E. Deployment Examples – Figure 20 > > Use the “scp” claim defined at > https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-09#section-4.2 > rather than “scope”. > See previous comment on "scp" vs "scope" (8.5 CBOR Web Token Claims) > Appendix E.2 Introspection Aided Token Validation > > It makes no sense to assume that the client is not able to access the AS > at the time of the access request but can access the introspection > endpoint, since the introspection endpoint is part of the AS.  Please > remove this section or revise accordingly. > The text here seems to be prone to misunderstandings. It is the RS not the client that is capable of making introspection requests in this scenario. I will clarify the text. > Appendix E.2 Introspection Aided Token Validation – Figure 23 > > Please revise the example to not use Client Credentials, because of the > security and privacy problems associated with this grant type. > See general comments. > *Surprising Omission of Token Binding!* > > The specification should describe the ability to use Token Bound access > tokens, rather than PoP access tokens, as this will be substantially > simpler for most implementations.  Please reference > draft-ietf-oauth-token-binding and describe how to apply it to this > specification. My cursory examination of the relevant drafts seems to indicate that token binding follows the same general principles as proof of possession access tokens (i.e. embedding some binding information into the token, which is equivalent to the 'cnf' claim defined by RFC 7800). Can you explain the advantages that token binding would have over proof-of-possession? -- Ludwig Seitz, PhD Security Lab, RISE SICS Phone +46(0)70-349 92 51 From nobody Mon Oct 9 18:09:23 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86E0513239C; Mon, 9 Oct 2017 18:09:21 -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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=augustcellars.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0CC33zxFjeeI; Mon, 9 Oct 2017 18:09:20 -0700 (PDT) Received: from mail4.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18AA0134323; Mon, 9 Oct 2017 18:09:16 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1507597703; h=from:subject:to:date:message-id; bh=m1MxWZetgeDFV4UXCNnp5Sy8Jx3x9CtmbG0/ec9yksE=; b=FClSzHj0952isZEJWh2FKvg0ZCttJHUFrLVnnoCSaIQPaPOCbZwmmGrhSqelJ2JFLbiAXlEgJq3 RAXvKjW4SU1yiRwhlqoLiyVJbAW7XGjg0hKC4Llvb5qnVL9PBqjos0XyyMoVozS+ozUxEFPK7VYnp 2Cz86T1JPY1rLh6oc7pO2WyWUO1g5aygwnIrr5vGNgCGc0t6eqQDfG3H6H52xT37terGQx0nddna1 4dA4mo39j53BSeCtLQ3uzlpafms9oTzYFem8aG4+jMdEX9YuWX2SoTNM9zitI7Ymft4Ztcswz5W/g p+Ezm8aSFi4/zDc4uzWReQjTGSjMcBGxNUCg== Received: from mail2.augustcellars.com (192.168.1.201) by mail4.augustcellars.com (192.168.1.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 9 Oct 2017 18:08:22 -0700 Received: from Hebrews (192.168.1.162) by mail2.augustcellars.com (192.168.1.201) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 9 Oct 2017 18:07:57 -0700 From: Jim Schaad To: CC: Date: Mon, 9 Oct 2017 18:08:45 -0700 Message-ID: <009701d34164$540c8cc0$fc25a640$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdNBTA87mF1mAa3DTgyCd00ylmVtSQ== X-Originating-IP: [192.168.1.162] Archived-At: Subject: [Ace] Review of draft-palombini-ace-coap-pubsub-profile-01 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, 10 Oct 2017 01:09:21 -0000 Here are some comments on this draft. 1. I find it difficult to call this a profile of the Oauth document in one way. This looks to me more of a "This is how you use the Oauth" document. This echoes a comment that I made on the ACE base Oauth document. 2. Introduction: I think you should give a (very) brief introduction into the pub sub system here rather than assuming that people are going to read the pub/sub draft first. 3. Overview: I have a slight problem with the title of this section. To me I would expect an "Overview" and an "Introduction" to be the same section. Think about combining the sections together or rename this section to be more specific. 4. Overview: this is a nit - I think that you want a different term than scenario here. 5. Overview: You need to expand and define RS and AS on first usage. 6. Overview: One of the things that I am not currently happy with is that you are looking at AS1 and AS2 as being independent appliers of access control logic without any communication between them. I think that AS1 needs the ability to give policy to AS2 on a topic after it has been created and before any subscribers get keys. In the case they are co-resident this is trivial, in other cases it may not be. 7. Overview: It is not clear to me that your allocation of roles to AS1 and AS2 I correct. If you have a second publisher, does it need to talk to both AS1 and AS2 or just to AS2? Is this really an AS1 controls creation of topics and AS2 controls publishing and subscribing to topics? If the publisher loses its membership in the group for any reason, should it be able to publish willy-nilly anyway? I.e. should AS2 be able to "revoke" the publishers right to publish? 8. Overview: I don't think the picture is correct at the bottom of the section. You have a Publisher-Subscriber client/client association 9. Overview: Is there any expectation that the broker should be notified on a "revocation" of a publisher's right to publish? (As opposed to the right just expiring.) There is no need to enforce subscribers right to subscribe since a key roll over means that they are getting gibberish. 10. Section 3 - I would remove 'D' from the picture as it gets a confusion between updating the tokens and publishing content. It is covered just fine by the core document. If you are using it as a 'publish' operation, then it does not belong in the first bullet point. It could also be the difference between pushing the token and getting a session. Again I don't think these need to be separate, that is clear from the core document and you are not doing anything different. 11. Section 3.1 - I don't' think that the returned info on the first request is going to be the same for publishers and subscribers. Not sure what this should really look like. 12. Section 3.1 - I am unsure what you believe is going to be accomplished by doing a RD lookup. You can get the name of the resource, but it would not necessarily return the AS1, AS2 strings. 13. Section 3.1 - On the unauthorized response, I think you want to be returning different responses to subscriber vs the broker. A subscriber does not need to know about AS1. Also I think you should be using the same tag as the base profile for at least one of them - probably the first one you would contact. 14. Section 3.1 - I am not sure that it makes any sense to set an audience. If the scope is the topic then all information exists. The audience really the subscriber. 15. Section 3.1 - You state that the algorithm must be a CE algorithm, but I think you mean a signing algorithm. 16. Section 3.1 - why not use the cnf return value for the key? Also there is no reason to make it a bstr rather than a map. 17. Section 3.1 - need to define a signers_keys element which returns all of the signing keys. Defined as an array of keys. Return other signers for multiple publishers. 18. Section 3.2 - see above about strings to be returned here. 19. Section 5 - Need to talk about how to deal with multiple publishers - are you assigning different keys or are you using different IV sections? Need to ensure that you don't have an error from using the same key/iv pair. 20. Section 5 - Are you containing a coap payload or a complete coap message in the payload. 21. Section 5. Do you want to talk about coordination of the observer number and the iv of a message? From nobody Tue Oct 10 10:30:14 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D376D1342E8 for ; Tue, 10 Oct 2017 10:30:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.8 X-Spam-Level: X-Spam-Status: No, score=-4.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XvUfhDIauMPO for ; Tue, 10 Oct 2017 10:30:04 -0700 (PDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0113.outbound.protection.outlook.com [104.47.42.113]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80B4C132930 for ; Tue, 10 Oct 2017 10:30:04 -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=AMKEshMguuWuy5N36FKs3uu1P5+aoasdNoSTwf7jlcs=; b=Ytxs2CZkjhuSSrQGyed4kb/WMHR1Hh3zlu8FAtzj7Po+i5CeL397Tsvxd7jCa2D4GLh0u/25gl6YA5EW2HGAaXKJKWUmkiFr7xWs89U3CI9fYKVIZwQUgq0la62lTAFQD+jbcFC+KnfImVHbpZl5741Gqmfwyqqce8He5iCQ2bg= Received: from SN2PR00MB0094.namprd00.prod.outlook.com (10.167.20.141) by SN2PR00MB0175.namprd00.prod.outlook.com (10.167.18.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.172.0; Tue, 10 Oct 2017 17:30:02 +0000 Received: from SN2PR00MB0094.namprd00.prod.outlook.com ([fe80::fd02:964:a152:d3aa]) by SN2PR00MB0094.namprd00.prod.outlook.com ([fe80::fd02:964:a152:d3aa%7]) with mapi id 15.20.0172.000; Tue, 10 Oct 2017 17:30:01 +0000 From: Anthony Nadalin To: Ludwig Seitz , Mike Jones , "ace@ietf.org" Thread-Topic: [Ace] Review of draft-ietf-ace-oauth-authz-07 by Mike Jones Thread-Index: AdM7W6CQJNWkaDadRS6XI7KhPAdRmQFmMq4AADoe9HA= Date: Tue, 10 Oct 2017 17:30:01 +0000 Message-ID: References: <70d9981f-3e4d-7389-5281-938618f1d3c1@ri.se> In-Reply-To: <70d9981f-3e4d-7389-5281-938618f1d3c1@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=tonynad@microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2017-10-10T08:34:24.9441736-07:00; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic; Sensitivity=General x-originating-ip: [64.134.49.48] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; SN2PR00MB0175; 6:HJYWO+VEbR1nxlINz1XKavq1e7+KXNbTg9Dg1BD0VcB8iiHKKccrJ9v/gQOsbQzcROiqwSK2G2xUbxE7dLaauwc+ftFEcyRmiju608yFNSDptpT5+QQDnRsRtACP6BEaPqjBbEAn6kJ9jSeVQhsd97S75sXTXRqHwaiJILw1jRV2XFsohs8rMGtHzCDCpaQmnYiCJ7qkNf3dSE1p08Tdzb9gdJS4BS4rp19atIxHy8mELMGLq9l1XQLEitc7Yb87E9uYX60LLNC4som8H19am70ooOziieEjp3AMxE/aU3wgKAuQzjHswNpdnQ8semLw15I54HD16GowaC4OjATyAQV6IxSpsmYqpMj9Y83kr98=; 5:nGAMTyXakN8UN9ZLYkHnIOlWO99ulmjxc92W0+uyoS+vkOGJ5tDcm5W9nfUhx2fisVMWCFZfRb98/HC5fpfm7gW8C/vn+fh1cw+6BJdT6k/slg4biPpAgmqJ0Ws/goxDz9K/QcULwKcVY7YllrEuT1ZpBRer/4hJnT8fvnUzbjE=; 24:JK3C9e7LyL4gtYd/oFVryAAbLPdf0W2ZC7aquHHLS0J8TH9PL4+WT48ocwHmEWB9uBHyKQRIVAr1vvWyc47ica1q6YNzBiI7szJM3ySy27A=; 7:16ug7ubykGEpIWfOE40X7bvjakoEsfqkf7cr/Cojo9yItZsIYfhQht+xrysLMXKmhKPZ4QGnuvKAyJg99i5MfXQqtOx+c5hB9xPrvdH+p7seBNNziXYCNvRQUndF5NerwrSGWCU/Fk2FyvMVFF0c/uNsp4mWRv5yn58NOrnMGOILsoPNZyyhx82yauTsXEjxZpKMkwQkCGp5iSqjZTvvXttXONJq4/dPXrz4X4kOe+hZAzDUDAUwtq87DdqUKSg3 x-ms-exchange-antispam-srfa-diagnostics: SSOS;SSOR; x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10019020)(979002)(6009001)(39860400002)(376002)(346002)(47760400005)(199003)(45984002)(189002)(377454003)(51444003)(13464003)(24454002)(377424004)(2421001)(74316002)(105586002)(81156014)(81166006)(25786009)(66066001)(8676002)(478600001)(76176999)(54356999)(50986999)(33656002)(10290500003)(8936002)(106356001)(2906002)(10090500001)(229853002)(189998001)(966005)(3846002)(3280700002)(102836003)(6116002)(22452003)(101416001)(1511001)(230783001)(53546010)(3660700001)(6246003)(6436002)(97736004)(14454004)(2561002)(2501003)(55016002)(6506006)(53946003)(16200700003)(53936002)(5250100002)(99286003)(110136005)(6306002)(9686003)(7696004)(2950100002)(2900100001)(8990500004)(86612001)(551544002)(5660300001)(7736002)(575784001)(86362001)(305945005)(316002)(68736007)(42262002)(959014)(559001)(579004)(569006); DIR:OUT; SFP:1102; SCL:1; SRVR:SN2PR00MB0175; H:SN2PR00MB0094.namprd00.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; x-ms-office365-filtering-correlation-id: bc0c931f-35df-4691-a0dc-08d510048990 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(48565401081)(2017052603204)(201703131423075)(201703031133081)(201702281549075); SRVR:SN2PR00MB0175; x-ms-traffictypediagnostic: SN2PR00MB0175: authentication-results: spf=none (sender IP is ) smtp.mailfrom=tonynad@microsoft.com; x-exchange-antispam-report-test: UriScan:(158342451672863)(89211679590171)(192374486261705)(189930954265078)(788757137089)(219752817060721)(21532816269658); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93001095)(3002001)(100000703101)(100105400095)(6055026)(61426038)(61427038)(6041248)(20161123555025)(20161123560025)(20161123564025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:SN2PR00MB0175; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:SN2PR00MB0175; x-forefront-prvs: 04569283F9 received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: bc0c931f-35df-4691-a0dc-08d510048990 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Oct 2017 17:30:01.4271 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR00MB0175 Archived-At: Subject: Re: [Ace] Review of draft-ietf-ace-oauth-authz-07 by Mike Jones 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, 10 Oct 2017 17:30:11 -0000 The point here about the optional extensions is that not all devices are co= nstrained the same, so some devices may actually be able to support Oauth y= et you prohibit that from happening with the mandatory extensions=20 -----Original Message----- From: Ace [mailto:ace-bounces@ietf.org] On Behalf Of Ludwig Seitz Sent: Monday, October 9, 2017 4:48 AM To: Mike Jones ; ace@ietf.org Subject: Re: [Ace] Review of draft-ietf-ace-oauth-authz-07 by Mike Jones Hello Mike, thank you very much for your detailed review. There are two general points I'd like to address here to avoid repeating my= self in the detailed comments below. 1.) You strongly recommend against using the client credentials grant. I ge= t the feeling we have fundamentally different understandings of how that gr= ant is used. For example I'm puzzled by your statement: "The client should never have th= e user's credentials". This sounds more like the "Resource Owner Password C= redentials" grant. I was under the impression that with the client credentials grant the clien= t would be issued (or not issued) an access token solely based on its own c= redentials, thus it would _not_ have access to the user's credentials. This= was exactly the reason I chose this grant type over those involving user g= enerated grants. Machine-to-machine communication is probably the most comm= on scenario for ACE, and I don't quite see how the manual user interactions= for providing grants fit well into such a setting. The text in the OAuth spec seems to support my point of view: "Client cred= entials are used as an authorization grant typically when the client [...] = is requesting access to protected resources based on an authorization previ= ously arranged with the authorization server." ( see https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fto= ols.ietf.org%2Fhtml%2Frfc6749%23section-1.3.4&data=3D02%7C01%7Ctonynad%40mi= crosoft.com%7C3b7c083b93894b41ea0d08d50f0b995f%7C72f988bf86f141af91ab2d7cd0= 11db47%7C1%7C0%7C636431464860393300&sdata=3D%2FF5tdnhDDdxajVnG4DknXJsox3jfJ= tvvjGQJL3fBA%2Fk%3D&reserved=3D0 ) 2.) Your main criticism is that we have made extensions to OAuth mandatory = and implicit. I fully agree with the second part of your criticism, the parts of the ACE = framework that are extensions to OAuth should be more clearly marked as suc= h, and I will update the draft accordingly. I will also update Appendix A t= o give more concrete design justifications for each of these extensions. Ho= wever I strongly disagree with your suggestion to make all these extensions= optional. ACE is intended to make OAuth "constrained friendly", if we don't make any = requirements, how is this supposed to work? Any implementation of plain OAuth could then just claim conformance with th= e ACE framework, which is definitely wrong! My suggestion would be to make the use of CBOR as data format mandatory, as= well as the use of the abbreviated request/response parameters, claim name= s, and error codes. I however agree with your suggestion to make the use of= CoAP optional (since you correctly commented that there are many other com= munication protocols that may use ACE). I would still use it as the baselin= e example in the framework, and leave it to the profiles that do not use Co= AP to define mappings of e.g. the RESTful method, response and error codes. Please find detailed comments inline. /Ludwig On 2017-10-02 11:11, Mike Jones wrote: > Having read the spec cover-to-cover, it surprised me how different=20 > this is from OAuth, despite the statements that it is based on OAuth.=A0= =20 > My highest-priority request is to make all the extensions to OAuth=20 > defined in this document optional, so that profiles could use actual=20 > OAuth, which currently doesn't seem to be possible.=A0 Much of this=20 > draft written in a way that huge OAuth extensions are obliquely=20 > assumed when describing other features, without any clear definitions=20 > or justifications for them when they are introduced in passing.=A0 These= =20 > things need to be teased apart, with references to sections actually=20 > defining and justifying each extension, rather than assuming that many=20 > of them exist in passing in other sections. >=20 See above > Detailed substantive comments on specific document text follow. =20 > Editorial nits are communicated in the accompanying pull request=20 > https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fgithub= .com%2FLudwigSeitz%2Face-oauth%2Fpull%2F112&data=3D02%7C01%7Ctonynad%40micr= osoft.com%7C3b7c083b93894b41ea0d08d50f0b995f%7C72f988bf86f141af91ab2d7cd011= db47%7C1%7C0%7C636431464860393300&sdata=3D7IjGF2tWtse0sChdQQssppOYgesDpCHJJ= f5T6DdOUlw%3D&reserved=3D0. >=20 Done > Title >=20 > The current title "Authentication and Authorization for Constrained=20 > Environments (ACE)" doesn't match the scope of what's in the spec, as=20 > the spec is only about resource authorization but not authentication. > Please change the title to "Resource Authorization Framework for=20 > Constrained Environments" or something similar.=A0 (Authentication would= =20 > require defining the equivalent of an OpenID Connect ID Token to=20 > convey authentication information, but this is entirely absent from=20 > the > specification.) >=20 > 1.=A0 Introduction >=20 > The introduction defines what it means by "authorization" by doesn't=20 > say what it is referring to by "authentication".=A0 This provides more=20 > evidence that "authentication" does not belong in the title or=20 > abstract.=A0 Please remove the passing references to the underspecified=20 > concept "authentication" from the introduction and the abstract.=A0=20 > (Note that while "OAuth client authentication" is a limited form of=20 > authentication, its use as a mechanism in the spec does not justify=20 > saying that the spec is defining authentication for its use cases in=20 > any general sense of the term.) > When I included 'Authentication' in the title I was thinking about device a= uthentication, and the fact that the AS facilitates establishing authentica= tion credentials between C and RS in this draft. I take it from your comments that you don't think that this is authenticati= on enough. > 2.=A0 Terminology >=20 > The "/" syntax for endpoint names, such as "/token" is misleading, as=20 >it seems to imply that these endpoints use particular pathnames.=A0=20 >Please replace all uses of "/endpoint-name" with just "endpoint-name". >Already done in the editor's copy > 2.=A0 Terminology >=20 > References are needed for the first uses of many of the terms and=20 > abbreviations used.=A0 For instance, you're using abbreviations like=20 > "AS", "RS", and "IoT" without saying what they refer to. >=20 I will re-check the terminology section for missing abbreviations. > 2.=A0 Terminology >=20 > Please change all uses of the word "introspect" to "introspection"=20 > when referring to the introspection endpoint. >=20 Done. > 2.=A0 Terminology >=20 > You introduce an "authz-info" endpoint in the terminology section,=20 > when this isn't commonly understood.=A0 You need a section reference=20 > following the first use of this concept. > Ok, will do. > 3.1 OAuth 2.0 - token and introspect endpoints >=20 > This section is the first of many places in which the text is written=20 > in a way that assumes that introspection will be implemented and used. > This needs to be corrected throughout the document, appropriately=20 > qualifying descriptions of introspection saying that some profiles may=20 > use it and others will not.=A0 For instance, the draft says "The token=20 > introspection endpoint, /introspect, is used by the RS when requesting=20 > additional information regarding a received access token."=A0 Please=20 > change this so something more like "In some profiles, a token=20 > introspection endpoint may be present and used by the RS to request=20 > additional information about a received access token."=A0 You should=20 > also clearly state that introspection is unnecessary and adds overhead=20 > that can be avoided when the resource server understands the access=20 > token format, such as when it is a CWT. > Agree, I will change the text to clarify that introspection is always op= tional. >=20 > 3.1 OAuth 2.0 - Proof of Possession Tokens >=20 > The draft uses the term "proof of possession token" to denote an=20 > access token supporting proof of possession.=A0 Note however, that there= =20 > are many other kinds of proof of possession tokens other than just=20 > access tokens.=A0 Please change all uses of the term "proof of possession= token" > to "proof of possession access token" or "access token supporting=20 > proof of possession".=A0 Similarly, change all uses of the term "PoP=20 > token" to "PoP access token". I was hoping to avoid such Wagnerian word monsters, but I see your point. U= nless someone has a good suggestion to make the name of these things shorte= r and still convey the meaning, I will implement that change. >=20 > 3.1 OAuth 2.0 - Scopes and Permissions >=20 > This section contains another example of an extension to OAuth being=20 > assumed, when for many profiles it won't be necessary.=A0 The draft says= =20 > "In turn, the AS may use the scope response parameter to inform the=20 > client of the scope of the access token issued."=A0 This assumes that a=20 > "scope" response will be added to all participating OAuth=20 > implementations, without justifying this addition to the standard.=A0 At= =20 > most, this section should refer to another section which defines an=20 > optional "scope" response parameter and describes the circumstances in=20 > which profiles would and would not need it. I don't quite see what you mean here. Scope is used in the same way it is u= sed in the OAuth 2.0 spec, i.e. it is optional, as the words "may use the s= cope response parameter" indicate. >=20 > 3.1 OAuth 2.0 - Scopes and Permissions >=20 > Likewise, the draft says "As the client could be a constrained device=20 > as well, this specification uses CBOR encoded messages for CoAP".=A0=20 > This is one of many places in the draft that it's assumed that CBOR=20 > and COAP will be used rather than JSON and HTTP.=A0 The framework draft=20 > should explicitly leave these choices up to profiles. > See general answer. > 4. Protocol Interactions >=20 > Please do not in any way endorse using the Client Credentials grant -=20 > which defeats the purpose of even having OAuth.=A0 The client should=20 > never have the user's credentials!=A0 At most, you should say that while= =20 > the Client Credentials grant may be used for some scenarios, it has=20 > known security and privacy flaws and its use is deprecated. >=20 See general answer. > 4. Protocol Interactions >=20 > The sentence "In such a case the resource owner or another person on=20 > his or her behalf have arranged with the authorization server=20 > out-of-band, which is often accomplished using a commissioning tool."=20 > needs clarification.=A0 What has been arranged? > Right, that sentence has been mangled. Will fix. > Figure 1: Basic Protocol Flow >=20 > This is yet another place where a major OAuth extension is assumed, =20 >without clear justification.=A0 The diagram adds "+ RS Information" to=20 >the authorization server response to the client, when this isn't a=20 >normal part of OAuth and not defined. At least, please indicate that=20 >this is optional and refer to a section that defines and justifies=20 >this optional extension, rather than assuming in passing that it's been a= dded. >This wouldn't qualify as a "major extension" in my world, the protocol is just returning a few additional parameters to enable proof-of-possession= and the use of different communication/communication-security profiles. Note that e.g. draft-ietf-oauth-pop-key-distribution also returns additiona= l parameters ('key') together with the access token response.=20 We just gave those additional parameters a name to be able to refer to them= collectively. > Figure 1: Basic Protocol Flow >=20 > Please rework this diagram to illustrate that introspection is=20 > optional (and wastes resources by performing unnecessary communication). >=20 Agreed. > 4. Protocol Interactions - Access Token Response >=20 > This also assumes the existence of "RS Information".=A0 At least, say=20 > that "Some profiles may choose to return information about the=20 > resource servers" and reference a section describing this optional=20 > feature, rather than write the text in a way that assumes its existence. >=20 See above. > 4. Protocol Interactions - Access Token Response >=20 > This also assumes the existence of profile information in the response. = =20 > This would normally be implicit.=A0 Again, please do not write the draft= =20 > in a way that assumes the presence of extensions that are often not neede= d. >=20 Indeed it makes sense to make the profile information an optional element i= n cases where it is implicitly known. I will modify the text to clarify thi= s. > 4. Protocol Interactions - Resource Request >=20 > The two-part request described in the third paragraph is not OAuth,=20 > nor is there any justification for adding additional steps.=A0 Likewise,= =20 > the language in paragraph 4 about "comparing the claims in the access=20 > token with the resource request" is a highly specific extension that=20 > is not normal OAuth.=A0 Please refactor this description to clearly=20 > delineate what's OAuth and what are optional extensions - referencing=20 > specific sections that define these extensions. > The justification for this was discussed at the interim meeting between IET= F 94 and 95 (https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%= 2F%2Fdatatracker.ietf.org%2Fmeeting%2Finterim-2016-ace-01%2Fmaterials%2Fsli= des-interim-2016-ace-1-2%2F&data=3D02%7C01%7Ctonynad%40microsoft.com%7C3b7c= 083b93894b41ea0d08d50f0b995f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6= 36431464860393300&sdata=3DN3gTefuts86QXFniftt8p1Cft%2Bjt3U5F8mrD20k4f%2Bo%3= D&reserved=3D0), I will provide a summary in Appendix A to clarify why this was designed that way. > 4. Protocol Interactions - Token Introspection Request >=20 > Please rework this section to describe that introspection is optional=20 > (and wastes resources by performing unnecessary communication). > Describe how things are simpler and more efficient when the resource=20 > directly understands the contents of the access token. > See comment above. > 4. Protocol Interactions - Token Introspection Response >=20 > This section adds yet another OAuth extension on the fly - the "client=20 > token" - again with no justification or clear definition. =A0Please=20 > remove the oblique "client token" reference here. >=20 We designed the client token in order to solve use cases where the client i= s constrained and has no direct means to communicate with the AS at the tim= e of the resource access. If you have a better suggestion on how to solve t= his, that is more in line with OAuth, I'd be grateful to hear about it. > 5. Framework - Proof-of-Possession >=20 > After "The binding is provided by the "cnf" claim" add references to=20 > [RFC 7800] and [draft-ietf-ace-cwt-proof-of-possession]. >=20 Ok > 5. Framework - Proof-of-Possession >=20 > The text currently includes "update a token".=A0 Shouldn't this actually= =20 > be "get a new token", since an existing access token can't be updated? >=20 Right. Will clarify the text. > 5.1 Authorization Grants >=20 > This section includes the phrase "client credentials grant is=20 > recommended".=A0 Because of the security and privacy problems with the=20 > client credentials grant, please rework this section to ensure that=20 > implementers and profile writers understand that the use of client=20 > credentials grant is never recommended, including describing why that=20 > is the case. > See general comment. > 5.1 Authorization Grants >=20 > Reference [RFC 6749] after you say "see the OAuth 2.0 framework". > Ok > 5.2 Client Credentials >=20 > After you say that "the OAuth framework defines one client credential=20 > type", you should also describe that RFC 7522 and RFC 7523 define=20 > additional kinds of client credentials that may be used. > I'm not sure how relevant these credential types are for constrained enviro= nments. For example RFC 7522 refers to SAML, which generally is way too ver= bose for constrained environments. I guess we could refer to RFC 7523 but with the caveat that CBOR/CWT is the= preferred/mandatory format in ACE. > 5.4 The Authorize Endpoint >=20 > Change all occurrences of "authorize endpoint" to "authorization endpoint= ". > Ok > 5.5 The Token Endpoint >=20 > Rather than saying that "this framework extends", say that the=20 > framework defines optional extensions and reference their definitions=20 > and justifications. >=20 See general discussion. I'm OK with providing more concrete design justific= ations in Appendix A. > 5.5 The Token Endpoint >=20 > Change "this framework defines encodings using CoAP and CBOR, as a=20 > substitute for HTTP and JSON" in a way that allows profiles to make=20 > either choice. See general comment. >=20 > 5.5.1 Client-to-AS Request >=20 > This section is another place in which this specification is making=20 > assumptions about choices that rightfully belong to profiles.=A0 It start= s=20 > with "The client sends a CoAP POST request".=A0 Profiles may choose to us= e=20 > CoAP or they may choose to use HTTP.=A0 Please reword this so that it say= s=20 > something more like "The client sends a CoAP or HTTP POST request,=20 > depending upon the profile".=A0 Please likewise generalize the descriptio= n=20 > of the framework so that it's clear that the choice between CoAP or HTTP= =20 > is up to the profile.=A0 Heck, Bluetooth Smart is another transport that'= s=20 > possible, which this spec shouldn't preclude! >=20 I'm Ok with some language that allows profiles to specify other=20 transport protocols (like Bluetooth low energy), but I'd like to keep=20 CoAP as the baseline, to be able to specify request and response codes=20 in some meaningful way. It would then be up to the profile that uses=20 another transport protocol to define mappings. > 5.5.1 Client-to-AS Request >=20 > This is again written in such a way that it assumes that the additional=20 > parameters will be implemented and used, which won't be necessary for=20 > some profiles.=A0 It starts "In addition to these parameters, this=20 > framework defines the following parameters".=A0 Qualify this by saying=20 > that some profiles may choose to implement and use the following OAuth=20 > extension parameters. >=20 These parameters (aud and cnf) are already optional, I don't quite=20 understand what more you are suggesting, could you clarify? > 5.5.1 Client-to-AS Request - aud >=20 > The OAuth Token Exchange spec uses the "audience" parameter for this=20 > functionality.=A0 See=20 > https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Ftools.= ietf.org%2Fhtml%2Fdraft-ietf-oauth-token-exchange-09%23section-2.1&data=3D0= 2%7C01%7Ctonynad%40microsoft.com%7C3b7c083b93894b41ea0d08d50f0b995f%7C72f98= 8bf86f141af91ab2d7cd011db47%7C1%7C0%7C636431464860403304&sdata=3DwG%2Bb%2Bh= ks0n84KgOu0YljKpQVsBcvwBN2J0Bea8tJ2o0%3D&reserved=3D0. =20 > Please reference this spec and use the same parameter name. >=20 Is there a difference between the semantics of the 'aud' claim from JWT=20 and the 'audience' parameter from this draft? I'd rather use semantics that are defined in a stable RFC, than=20 referring to work in progress. > 5.5.1 Client-to-AS Request - aud >=20 > The spec says that "If a client submits a request for an access token=20 > without specifying an "aud" parameter, and the AS does not have a=20 > default "aud" value for this client, then the AS MUST respond with an=20 > error message".=A0 This violates the OAuth principle that implementations= =20 > must ignore parameters that they do not understand.=20 > https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Ftools.= ietf.org%2Fhtml%2Frfc6749%23section-3.1&data=3D02%7C01%7Ctonynad%40microsof= t.com%7C3b7c083b93894b41ea0d08d50f0b995f%7C72f988bf86f141af91ab2d7cd011db47= %7C1%7C0%7C636431464860403304&sdata=3DkxXtrzd4wooR9TP7Uu2P9b40OhhJ22Ou0fo1%= 2BZxuHSQ%3D&reserved=3D0 says "The authorization=20 > server MUST ignore unrecognized request parameters".=A0 Rework this to sa= y=20 > that it's perfectly legitimate for participants to ignore the "aud"=20 > parameter when they don't implement or understand it. >=20 How would a regular OAuth 2.0 AS react to an access token request for=20 which it doesn't know which audience it is supposed to address? I think=20 that this must be either implicit or given by the 'aud' parameter as=20 suggested in=20 https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Ftools.ie= tf.org%2Fhtml%2Fdraft-ietf-oauth-pop-key-distribution-03%23section-3&data= =3D02%7C01%7Ctonynad%40microsoft.com%7C3b7c083b93894b41ea0d08d50f0b995f%7C7= 2f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636431464860403304&sdata=3DbL6oPm= iG9tzCNwg3pvlID5FhC6iXyt4iRlOuw1OgMwQ%3D&reserved=3D0. > 5.5.2 AS-to-Client Response >=20 > Once again, extensions to OAuth are implicitly required - in this case=20 > the "profile" and "cnf" parameters.=A0 Reword to make these choices=20 > available to profiles. I see your point for the profile parameter, given that it could be=20 implicit. I have my doubts though that 'cnf' could ever be implicit, do=20 you have any case in mind (that uses proof-of-possession) where that=20 would be the case? >=20 > 5.5.2 AS-to-Client Response - profile >=20 > This certainly shouldn't be required, as the profile knowledge will be=20 > implicit in most OAuth deployments.=A0 Very rare indeed will the cases in= =20 > which participants will support multiple profiles. >=20 Ok > 5.5.2 AS-to-Client Response >=20 > The spec says that "Figure 5 summarizes the parameters that may be part=20 > of the RS Information".=A0 However the term "RS information" is=20 > undefined.=A0 Instead, change this sentence to say =A0"Figure 5 summarize= s=20 > the parameters that may be part of the token response". > The term "RS Information" is defined in section 4, bullet point B. Since=20 that is obviously too well hidden. I will move that definition to the=20 terminology section. > 5.5.2 AS-to-Client Response - Figure 6 >=20 > I suggest removing "profile" from the example, as this is unnecessary=20 > protocol bloat. If we remove it, we should add some explanatory text that states that=20 the profile is implicit in that case. >=20 > 5.5.3 Error Response >=20 > The spec says "The error codes MAY be abbreviated using the codes=20 > specified in table Figure 7".=A0 Again, whether to do this is a profile=20 > choice.=A0 Making it optional only makes all implementations bigger=20 > because they have to support both choices.=A0 Reword to say that profiles= =20 > will specify whether error codes are abbreviated in this manner or not. > See general comment. > 5.5.3 Error Response - Figure 7 >=20 > These values should be in a registry - possibly called something like=20 > "OAuth error code CBOR value mappings".=A0 This registry should reference= =20 > the values registered in the OAuth Extensions Error Registry at=20 > https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.ia= na.org%2Fassignments%2Foauth-parameters%2Foauth-parameters.xhtml%23extensio= ns-error&data=3D02%7C01%7Ctonynad%40microsoft.com%7C3b7c083b93894b41ea0d08d= 50f0b995f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636431464860403304&s= data=3DY%2B9eAi9hWgPSRfNlv%2FNXk4ykiTjFKfoy9u55Sk4%2FfpI%3D&reserved=3D0. > Correct. Will fix. > 5.5.4.1 Audience >=20 > Reference the audience parameter in=20 > https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Ftools.= ietf.org%2Fhtml%2Fdraft-ietf-oauth-token-exchange-09%23section-2.1&data=3D0= 2%7C01%7Ctonynad%40microsoft.com%7C3b7c083b93894b41ea0d08d50f0b995f%7C72f98= 8bf86f141af91ab2d7cd011db47%7C1%7C0%7C636431464860403304&sdata=3DwG%2Bb%2Bh= ks0n84KgOu0YljKpQVsBcvwBN2J0Bea8tJ2o0%3D&reserved=3D0=20 > and indicate that whether it is used a profile-specific choice. > See discussion above (5.5.1 Client-to-AS Request - aud) > 5.5.4.1 Audience >=20 > The spec says that "It should be encoded as CBOR text string".=A0 Again,= =20 > reword this to say that it's a profile choice whether to use CBOR or=20 > standard OAuth. > See general comment. > 5.5.4.2 Grant Type >=20 > Rather than saying "MAY", say that the profile specifies the=20 > representation that it used. >=20 I would actually rather make the abbreviated representations mandatory=20 for the reasons given in my general comment. > 5.5.4.2 Figure 8 >=20 > These values should be in a registry - possibly called something like=20 > "OAuth grant type CBOR value mappings".=A0 This registry should reference= =20 > the sections defining these values in RFC 6749 and the grant type values= =20 > defined by RFC 7522 and RFC 7523. >=20 Correct. Will fix. > 5.5.4.3 Token Type >=20 > Reference draft-ietf-oauth-pop-key-distribution for the definition of=20 > the "pop" token_type. > I was under the impression that this draft was dead. Is it really=20 acceptable to reference this type of work in a normative way? I've given=20 that draft a paragraph in the Acknowledgment section. > 5.5.4.3 Token Type >=20 > When you say that "The values in the 'token_type' parameter MUST be CBOR= =20 > text strings", you're again implicitly making choices that belong to=20 > profiles.=A0 Please generalize this description. >=20 > See general comment. > 5.5.4.4 Profile >=20 > Whether "profile" is even needed is up to the profile.=A0 Typically it=20 > will be implicit, since implementations will use a single profile. =20 > Please revise accordingly. > Agree. > 5.5.4.5 Confirmation >=20 > Please replace the definition of "cnf" for CBOR here with references to=20 > RFC 7800 and draft-ietf-ace-cwt-proof-of-possession. > Note that we use "cnf" here as a request and response parameter. I do=20 refer to draft-ietf-ace-cwt-proof-of-possession, but that draft only=20 defines "cnf" as a CWT claim, so I still feel the need to specify its=20 semantically equivalent use as a req/resp parameter. > 5.5.5 Mapping parameters to CBOR >=20 > It looks to me like these values are intended to align with those=20 > registered in the CBOR Web Token (CWT) Claims registry initially=20 > populated by=20 > https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Ftools.= ietf.org%2Fhtml%2Fdraft-ietf-ace-cbor-web-token-08%23section-9.1.2&data=3D0= 2%7C01%7Ctonynad%40microsoft.com%7C3b7c083b93894b41ea0d08d50f0b995f%7C72f98= 8bf86f141af91ab2d7cd011db47%7C1%7C0%7C636431464860403304&sdata=3Dw2lt7FcEyl= 68wH0XLBOsorq2knawuHmUX7aO3TnXVoU%3D&reserved=3D0. =20 Correct > If so, the spec should make this relationship explicit.=20 Will do. > However, it=20 > would be inappropriate to use the rare single-byte CBOR integer values=20 > for application-specific claim keys. I would suggest that the claim=20 > identifiers for client_id through refresh_token and profile start at 256= =20 > (a two-byte CBOR value) and go up from there.=A0 In that case, I suspect= =20 > they could be successfully registered in the CWT Claims registry - which= =20 > I think you want.=A0 ("cnf" will already be registered by=20 > draft-ietf-ace-cwt-proof-of-possession.) >=20 Why would we want to artificially increase the size of the framework=20 parameters coming from OAuth? (like e.g. code, access_token etc) This feels counter-productive, they are by no means=20 application-specific, these are used in basic OAuth 2.0. We should do a=20 case-by-case evaluation. Also as for registering those into the CWT claims registry, I feel that=20 would not be a good fit, since we are using those as request/response=20 parameters in the different OAuth/ACE protocol messages, while CWT=20 registers claim values. I see a mismatch here don't you? > 5.6 The Introspect Endpoint >=20 > First, change introspect to introspection.=A0 And like other places, stat= e=20 > that it is up to the profile whether to use introspection at all, and if= =20 > so, whether to use standard introspection syntax or the CoAP/CBOR version= . >=20 Agree with the first part, disagree with allowing other encodings than=20 CBOR. > 5.6.2 AS-to-RS Response - Figure 15 >=20 > Remove profile and client_token from this example, since both are pretty= =20 > esoteric and not likely to be used in the common case. >=20 As to whether the example should include optional parameters, I have no=20 strong opinion, although their absence in examples makes it harder to=20 understand their intended use. > 5.6.4 Client Token >=20 > I agree with Hannes' review of this feature: "/The "Client Token" is=20 > somewhat experimental and not on par with the rest of the document in=20 > terms of maturity and alignment with OAuth. I would prefer this=20 > functionality to be covered in a separate document, if someone still=20 > cares about it. While OAuth has seen a lot of formal analysis this=20 > feature obviously hasn't./"=A0 Please remove this from the specification= =20 > and if you still believe in it, place it in a separate document for=20 > independent consideration by the working group. > See comment above (4. Protocol Interactions - Token Introspection Response) > 5.6.4 Client Token >=20 > The spec says "The client is pre-configured with a generic, long-term=20 > access token when it is commissioned."=A0 This hardly seems secure -=20 > especially since secrets can often be extracted from deployed software. >=20 I don't see how this is less secure than a client that doesn't have a=20 long-term token, but instead the credentials/grants that allow it to=20 retrieve fresh tokens from the AS. These credentials can just as easily=20 be extracted and misused if the client is stolen. > 5.6.4 Client Token >=20 > The spec says "The RS then performs token introspection to learn what=20 > access this token grants."=A0 Again, this is unnecessary if the resource= =20 > understands the claims in the access token. The text is probably not well written in that section. The token is=20 intended to just be a reference, not a full CWT. Thus it would not=20 contain any claims that the RS can process independently. I will try to=20 clarify this. >=20 > 5.6.5 Mapping Introspection Parameters to CBOR >=20 > As in my related comment on 5.5.5, it looks to me like these values are=20 > intended to align with those registered in the CBOR Web Token (CWT)=20 > Claims registry initially populated by=20 > https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Ftools.= ietf.org%2Fhtml%2Fdraft-ietf-ace-cbor-web-token-08%23section-9.1.2&data=3D0= 2%7C01%7Ctonynad%40microsoft.com%7C3b7c083b93894b41ea0d08d50f0b995f%7C72f98= 8bf86f141af91ab2d7cd011db47%7C1%7C0%7C636431464860403304&sdata=3Dw2lt7FcEyl= 68wH0XLBOsorq2knawuHmUX7aO3TnXVoU%3D&reserved=3D0. =20 > If so, the spec should make this relationship explicit.=A0 However, it=20 > would be inappropriate to use the rare single-byte CBOR integer values=20 > for application-specific claim keys. I would suggest that the claim=20 > identifiers for client_id through refresh_token and profile start at 256= =20 > (a two-byte CBOR value) and go up from there.=A0 In that case, I suspect= =20 > they could be successfully registered in the CWT Claims registry - which= =20 > I think you want.=A0 ("cnf" will already be registered by=20 > draft-ietf-ace-cwt-proof-of-possession.) > Same comments as before apply (5.5.5 Mapping parameters to CBOR) > 5.7 The Access Token >=20 > Reference [RFC 7800] and [draft-ietf-ace-cwt-proof-of-possession] when=20 > describing the use of "cnf". >=20 The text does reference RFC 7800, I failed to update this section after=20 we moved the 'cnf' specification to=20 draft-ietf-ace-cwt-proof-of-possession. Will fix. > 5.7.1 The Authorization Information Endpoint >=20 > Please describe the relationship between this endpoint and the resource=20 > endpoint used by RFC 6750. >=20 I can't find a reference to a resource endpoint in RFC 6750. Are you=20 sure this is the right reference? > 5.7.1 The Authorization Information Endpoint >=20 > Again, please clarify that support for this OAuth extension, the use of=20 > CoAP, and the use of introspection are all choices up to particular=20 > profiles. >=20 This will just yield us a lot of incompatibility. Note that profiles are free to define additional methods of token transfer. > 5.7.1 The Authorization Information Endpoint >=20 > The spec says "The RS MUST be prepared to store more than one token for=20 > each client, and MUST apply the combined permissions granted by all=20 > applicable, valid tokens to client requests."=A0 This seems really overly= =20 > specific for a framework spec.=A0 Simple systems will likely only have on= e=20 > token per client, let alone not supporting complex permission=20 > combination logic!=A0 Please remove this statement. >=20 Ok > 5.7.2 Token Expiration >=20 > Rather than saying "CWT/JWT" expand this to "CWT or JWT" for readability. >=20 I'm actually considering to remove JWT entirely instead. See general=20 discussion. > 6. Security Considerations >=20 > Add a reference upon first use of the term "AEAD". Ok >=20 > 7. Privacy Considerations >=20 > The spec says "The latter may reveal the client's identity."=A0 What is=20 > meant by the client's identity?=20 The identity of the specific device running the client application. > What kinds of information does this=20 > entail and what are the privacy risks associated with it?=A0 How does the= =20 > client's identity relate to the identities of people who may be=20 > associated with the system in some way? The user owning that device might be linkable to the device identity.=20 Therefore that user's privacy might be at stake. It seems this paragraph=20 needs clarification. >=20 > 8.1 OAuth Introspection Response Parameter Registration >=20 > Every place an IANA registration currently says "this document", please=20 > change it to "Section x.y.z of this document" (using the appropriate=20 > tag for the section that defines the value. >=20 Ok > 8.1 OAuth Introspection Response Parameter Registration >=20 > "aud" is already registered at=20 > https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.ia= na.org%2Fassignments%2Foauth-parameters%2Foauth-parameters.xhtml%23token-in= trospection-response&data=3D02%7C01%7Ctonynad%40microsoft.com%7C3b7c083b938= 94b41ea0d08d50f0b995f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63643146= 4860403304&sdata=3D1P%2BqZ9nSbpZjzYsxC4%2FvMiY4xafg8pzXiyeZzMDZbxE%3D&reser= ved=3D0. >=20 Right, will remove. > 8.4 Token Type Mappings >=20 > The name "Token Type Mappings" registry is too generic.=A0 Please change= =20 > it to "OAuth Token Type CBOR Mappings" or something similar. > Ok > 8.4.1=A0 Registration Template >=20 > As was pointed out in comments on earlier versions of the CWT spec, the=20 > range 1 to 65536 makes no sense.=A0 Please consider using the same=20 > treatment of value ranges as CWT does (which themselves derived from the= =20 > COSE usage of value ranges). Do this consistently every place that "1 to= =20 > 65536" occurs in the spec. > Ok > 8.5 CBOR Web Token Claims >=20 > Consider using the "scp" claim defined at=20 > https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Ftools.= ietf.org%2Fhtml%2Fdraft-ietf-oauth-token-exchange-09%23section-4.2&data=3D0= 2%7C01%7Ctonynad%40microsoft.com%7C3b7c083b93894b41ea0d08d50f0b995f%7C72f98= 8bf86f141af91ab2d7cd011db47%7C1%7C0%7C636431464860403304&sdata=3DlsrmKUe1oc= pxof%2BDCLAUjlHXY0HvNV56OQ2LFuK3Wfc%3D&reserved=3D0=20 > rather than "scope".=A0 If you don't, at least say why you are introducin= g=20 > a different claim to convey the same information. >=20 It is my understanding that "scp" is defined as an array of scopes,=20 which in turn are a space delimited list of strings. I thus felt that=20 "scp" was unnecessarily introducing a doubly nested list of=20 scope-tokens, which is the reason why I choose not to use it. > 8.5 CBOR Web Token Claims >=20 > "cnf" is already being registered by draft-ietf-ace-cwt-proof-of-possessi= on. > Correct, this should already be removed in the editor's draft. > 8.6 ACE Profile Registry >=20 > The name "ACE Profile Registry" registry is too generic.=A0 Please change= =20 > it to "ACE OAuth Profile Registry" or something similar. >=20 Ok > 8.7 OAuth Parameter Mappings Registry >=20 > The name "OAuth Parameter Mappings" registry is too generic.=A0 Please=20 > change it to "OAuth CBOR Parameter Mappings" or something similar. > Ok > 8.7.2 Initial Registry Contents >=20 > Per my earlier comments, these values should actually reference the CWT=20 > Claims registry and application-specific values such as "client_id",=20 > etc. should not use the scarce single-byte value range. > See previous comments (5.5.5 Mapping parameters to CBOR). > 8.8.1 Registration Template >=20 > Registrations for the Introspection Endpoint CBOR Mappings registry=20 > should contain a field that lists the corresponding value registered in=20 > the OAuth Token Introspection Response registry at=20 > https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.ia= na.org%2Fassignments%2Foauth-parameters%2Foauth-parameters.xhtml%23token-in= trospection-response&data=3D02%7C01%7Ctonynad%40microsoft.com%7C3b7c083b938= 94b41ea0d08d50f0b995f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63643146= 4860403304&sdata=3D1P%2BqZ9nSbpZjzYsxC4%2FvMiY4xafg8pzXiyeZzMDZbxE%3D&reser= ved=3D0. >=20 Ok > 8.10 CWT Confirmation Methods Registry >=20 > Delete this section, as it has been moved to=20 > draft-ietf-ace-cwt-proof-of-possession. > Ok > Appendix A. Design Justification - Communication Constraints >=20 > Add that power saving may be another reason for communication constraints= . > I plan to completely rewrite that section to provide detailed=20 justifications for the different changes to OAuth 2.0 we made. I will=20 make sure to include some text on power consumption. > Appendix B. Roles and Responsibilities - Authorization Server >=20 > Add that enabling discovery of the AS's capabilities via metadata is=20 > likely in scope.=A0 Reference draft-ietf-oauth-discovery. > Ok > Appendix B. Roles and Responsibilities - Client >=20 > What do the parenthetical letters such as "(A)" refer to?=A0 Why are "(D)= "=20 > and "(E)" missing? > They refer the steps in figure 1. I will add some text to clarify this. > Appendix C. Requirements on Profiles >=20 > You should be much more clear in this section that choices of JSON vs.=20 > CBOR, JWT vs. CWT, HTTP versus COaP, PoP versus Token Binding,=20 > Introspection or not, authz-info endpoint or not, etc. must be made by=20 > profiles. See general comments. > Appendix E. Deployment Examples - Figure 20 >=20 > Use the "scp" claim defined at=20 > https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Ftools.= ietf.org%2Fhtml%2Fdraft-ietf-oauth-token-exchange-09%23section-4.2&data=3D0= 2%7C01%7Ctonynad%40microsoft.com%7C3b7c083b93894b41ea0d08d50f0b995f%7C72f98= 8bf86f141af91ab2d7cd011db47%7C1%7C0%7C636431464860403304&sdata=3DlsrmKUe1oc= pxof%2BDCLAUjlHXY0HvNV56OQ2LFuK3Wfc%3D&reserved=3D0=20 > rather than "scope". >=20 See previous comment on "scp" vs "scope" (8.5 CBOR Web Token Claims) > Appendix E.2 Introspection Aided Token Validation >=20 > It makes no sense to assume that the client is not able to access the AS= =20 > at the time of the access request but can access the introspection=20 > endpoint, since the introspection endpoint is part of the AS.=A0 Please=20 > remove this section or revise accordingly. > The text here seems to be prone to misunderstandings. It is the RS not=20 the client that is capable of making introspection requests in this=20 scenario. I will clarify the text. > Appendix E.2 Introspection Aided Token Validation - Figure 23 >=20 > Please revise the example to not use Client Credentials, because of the=20 > security and privacy problems associated with this grant type. >=20 See general comments. > *Surprising Omission of Token Binding!* >=20 > The specification should describe the ability to use Token Bound access=20 > tokens, rather than PoP access tokens, as this will be substantially=20 > simpler for most implementations.=A0 Please reference=20 > draft-ietf-oauth-token-binding and describe how to apply it to this=20 > specification. My cursory examination of the relevant drafts seems to indicate that=20 token binding follows the same general principles as proof of possession=20 access tokens (i.e. embedding some binding information into the token,=20 which is equivalent to the 'cnf' claim defined by RFC 7800). Can you explain the advantages that token binding would have over=20 proof-of-possession? --=20 Ludwig Seitz, PhD Security Lab, RISE SICS Phone +46(0)70-349 92 51 _______________________________________________ Ace mailing list Ace@ietf.org https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.ietf= .org%2Fmailman%2Flistinfo%2Face&data=3D02%7C01%7Ctonynad%40microsoft.com%7C= 3b7c083b93894b41ea0d08d50f0b995f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0= %7C636431464860403304&sdata=3D0%2F2bOCph7u5Mv4V7QLwTbCe2JV2%2FCDus72eF6xfVM= HE%3D&reserved=3D0 From nobody Wed Oct 11 00:59:34 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42B0E13219B for ; Wed, 11 Oct 2017 00:59:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.401 X-Spam-Level: X-Spam-Status: No, score=-5.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nfJu2634cTVj for ; Wed, 11 Oct 2017 00:59:30 -0700 (PDT) Received: from se-out2.mx-wecloud.net (se-out2.mx-wecloud.net [89.221.255.177]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F8C313202D for ; Wed, 11 Oct 2017 00:59:30 -0700 (PDT) Received: from sp-mail-2.sp.se (unknown [194.218.146.197]) by se-out2.mx-wecloud.net (Postfix) with ESMTPS id BF898223B04; Wed, 11 Oct 2017 07:59:27 +0000 (UTC) Received: from [192.168.0.166] (10.116.0.226) by sp-mail-2.sp.se (10.100.0.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.669.32; Wed, 11 Oct 2017 09:59:27 +0200 To: Anthony Nadalin , Mike Jones , "ace@ietf.org" References: <70d9981f-3e4d-7389-5281-938618f1d3c1@ri.se> From: Ludwig Seitz Message-ID: <760bd132-3996-2242-3b1c-111034094e0d@ri.se> Date: Wed, 11 Oct 2017 09:59:14 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.116.0.226] X-ClientProxiedBy: sp-mail-3.sp.se (10.100.0.163) To sp-mail-2.sp.se (10.100.0.162) X-CMAE-Score: 0 X-CMAE-Analysis: v=2.2 cv=KqQ94SeN c=1 sm=1 tr=0 a=L5DDne6A+dD0FbDkt2Fblw==:117 a=L5DDne6A+dD0FbDkt2Fblw==:17 a=sZ8rJzgPlrQA:10 a=IkcTkHD0fZMA:10 a=02M-m0pO-4AA:10 a=Srg91UCDZRYOU3zLZEoA:9 a=QEXdDO2ut3YA:10 X-Virus-Scanned: clamav-milter 0.99.2 at MailSecurity X-Virus-Status: Clean X-MailSecurity-Status: 0 X-Scanned-By: WeCloud MailSecurity X-MailSecurity-Score: 0 Archived-At: Subject: Re: [Ace] Review of draft-ietf-ace-oauth-authz-07 by Mike Jones 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, 11 Oct 2017 07:59:32 -0000 On 2017-10-10 19:30, Anthony Nadalin wrote: > The point here about the optional extensions is that not all devices > are constrained the same, so some devices may actually be able to > support Oauth yet you prohibit that from happening with the mandatory > extensions I'm assuming that you are considering a scenario where some devices are less constrained while others are constrained, otherwise using ACE makes no sense in the first place (you could just use OAuth). The main requirement that precludes mixing plain OAuth with ACE-OAuth is that protocol parameters need to be encoded in CBOR instead of JSON. If we made this optional, a client could make a request to the token endpoint using plain OAuth (i.e. unabbreviated parameters). I see the following undesirable outcomes from such a solution: a.) The AS has to support both abbreviations and full parameter names (more code complexity at AS). b.) We need some protocol mechanics to tell the AS whether the client is using regular OAuth or ACE-OAuth (more code complexity at both client and AS, more protocol complexity, possibility of mixup errors). c.) RS that need to do introspection need the same protocol mechanics as in b.) I don't believe this is a good trade-off. Note that nothing precludes you from using regular OAuth, as long as the client and AS support it and the RS can process the resulting access token. /Ludwig -- Ludwig Seitz, PhD Security Lab, RISE SICS Phone +46(0)70-349 92 51 From nobody Wed Oct 11 07:59:19 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8306C1331F2 for ; Wed, 11 Oct 2017 07:59:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wL4KtBUI__K1 for ; Wed, 11 Oct 2017 07:59:09 -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 44EBF132331 for ; Wed, 11 Oct 2017 07:59:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3574; q=dns/txt; s=iport; t=1507733949; x=1508943549; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=61beYO2hwc3BzBrhycw+7P+h5u1SCwTVDADL396vQy8=; b=GPG8Poy4/n+9/6z5bN3Y0q+Vt4aIIwucBSa7JMjAZvE8Uo0X41gXrvJ1 KzL09bIgZdxYJmkvHGrtTT5RhoLEA3rmG21Ay3LFmZ6LrlFZ1C6GmSeTn 6bkoZilIAQwFHpBrmGxMFMxqSaZAzjx59ubgEi5Dg4tA8vN5nXKFcDjxx M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C5AAAQMd5Z/4oNJK1UCRkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYMuLWRuJweOEo8tgXaWL4ISChgPhEVPAoRfPxgBAgEBAQEBAQF?= =?us-ascii?q?rKIUdAQEBAQMBATg0FwQCAQgRBAEBHwkHJwsUCQgCBAESCBIBigkQrBOLMwEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBARgFgy2CB4FRgWqDKoRbhh4FiDWZCAKHXINiiSC?= =?us-ascii?q?TGJU2AhEZAYE4AR84gQ54FUmHHXYBiTmBEQEBAQ?= X-IronPort-AV: E=Sophos;i="5.43,361,1503360000"; d="scan'208";a="309493820" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 11 Oct 2017 14:58:58 +0000 Received: from XCH-ALN-010.cisco.com (xch-aln-010.cisco.com [173.36.7.20]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id v9BEwwgW010480 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 11 Oct 2017 14:58:58 GMT Received: from xch-aln-010.cisco.com (173.36.7.20) by XCH-ALN-010.cisco.com (173.36.7.20) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 11 Oct 2017 09:58:57 -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; Wed, 11 Oct 2017 09:58:57 -0500 From: "Panos Kampanakis (pkampana)" To: Hannes Tschofenig , "Ace@ietf.org" Thread-Topic: [Ace] draft-selander-ace-eals vs. draft-vanderstok-ace-coap-est Thread-Index: AQHTLKb26Oagi29XQ0+/G4UGVDQnCqLe1tTQ Date: Wed, 11 Oct 2017 14:58:57 +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.5] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Ace] draft-selander-ace-eals vs. draft-vanderstok-ace-coap-est 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, 11 Oct 2017 14:59:18 -0000 Sorry for responding to this late.=20 Full disclosure, I am also one of the authors of draft-vanderstok-ace-coap-= est.=20 draft-vanderstok-ace-coap-est uses well established DTLS to secure the COAP= channel at the transport layer in order to carry the cert provisioning mes= sages of EST. EST is a protocol that has certain advantages and has been se= eing adoption for some time now. Some examples include Digicert https://www= .digicert.com/news/2017-02-06-digicert-launches-auto-provisioning-for-iot-d= evices , Entrust https://www.entrustdatacard.com/blog/2017/may/certificate-= management-to-client-or-not-to-client , Java Bouncy Castle https://www.boun= cycastle.org/ , EJBCA https://sourceforge.net/p/ejbca/discussion/132019/thr= ead/1d749923 , Cisco https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/sec_= conn_pki/configuration/xe-3s/sec-pki-xe-3s-book/sec-est-client-supp-pki.htm= l , Samsung https://www.samsungknox.com/en/article/est-cmc-change-notes Of = course DTLS, COAP are also well adopted and implemented. We have seen a few= vendors asking EST run over COAP over DTLS specifically in lighting and Io= T verticals in order to be bootstrapped and provisioned an identity. EALS o= n the other hand uses CMC messages over COAP by defining new URIs and new u= ses OSCOAP/EDHOC to secure the messages at the application layer. The CMC m= essages are similar to EST's and thus I don't see these as competing, but t= he new eals APIs are replicating functionality already existing in EST. Tho= ugh, securing the messages at the application layer is a significant differ= ence. There might be certain usecases for application layer security with O= SCOAP like code size, but as already brought up in an earlier meeting the O= SCOAP protections replicate the protections in DTLS at the transport layer.= In other words, draft-vanderstok-ace-coap-est is based on established and = trusted protocols that are already implemented and we have seen demand in t= he industry for this solution, thus the draft. EALS introduces newer protec= tion mechanisms that could well have some usecases in the industry.=20 I see the two drafts as defining two separate secure channels of securing t= he same COAP messages. I would suggest that the new protection mechanism of= fered in EALS could be a separate draft of protecting the EST-coap messages= instead of DTLS, in order to reap the fruits of oscoap, but I would like t= o see the EST-coap message bindings be common without separate CMC messages= . That way the BRSKI messages do not need to be redefined for bootstrapping= over COAP either.=20 I think these will be discussed in one of the upcoming interims, but I want= ed to bring the points to prepare the discussion.=20 Rgs, Panos -----Original Message----- From: Ace [mailto:ace-bounces@ietf.org] On Behalf Of Hannes Tschofenig Sent: Wednesday, September 13, 2017 11:43 AM To: Ace@ietf.org Subject: [Ace] draft-selander-ace-eals vs. draft-vanderstok-ace-coap-est Hi all, in previous IETF meetings we had presentations on these two documents and i= t appears that there is an overlap. So far we haven't had a lot of discussi= ons on these proposals on the list but since there seems to be interest fro= m the folks attending the IETF meetings I am recommending to have a discuss= ion about the direction we should go with this work. Any thoughts? Ciao Hannes _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace From nobody Fri Oct 13 06:22:21 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE304132F7D; Fri, 13 Oct 2017 06:22:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 gmhiFgCnKLNe; Fri, 13 Oct 2017 06:22:10 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E40E13304E; Fri, 13 Oct 2017 06:22:09 -0700 (PDT) X-AuditID: c1b4fb30-ef1ff70000001b7f-25-59e0bdffd60e Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.183.60]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 1F.C4.07039.FFDB0E95; Fri, 13 Oct 2017 15:22:07 +0200 (CEST) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.60) with Microsoft SMTP Server (TLS) id 14.3.352.0; Fri, 13 Oct 2017 15:22:07 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=4T5BPoRI4HkohWT5eL7cIwy45W6gduUqsUaZwTTuloU=; b=AatkyPfTybZjyF9e46WQfSDLjo7iC8XitbYlN2EmMTlRVJGIjwAPCYou7tOw9zRX1CuwuCTzhAuxdqWgAQTzF/Hp/onTPhFQaDNCqrQQglIv3gWWSXPGg/vNXoIl8Igrbo/DFktD2nddY1ariBnpEtTdOQmvn7gfcNZGMGu8UrM= Received: from HE1PR07MB1529.eurprd07.prod.outlook.com (10.169.122.151) by HE1PR07MB1530.eurprd07.prod.outlook.com (10.169.122.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.5; Fri, 13 Oct 2017 13:22:05 +0000 Received: from HE1PR07MB1529.eurprd07.prod.outlook.com ([fe80::11af:c0a0:4d0d:d5f1]) by HE1PR07MB1529.eurprd07.prod.outlook.com ([fe80::11af:c0a0:4d0d:d5f1%13]) with mapi id 15.20.0077.019; Fri, 13 Oct 2017 13:22:05 +0000 From: Francesca Palombini To: Jim Schaad , "draft-palombini-ace-coap-pubsub-profile@ietf.org" CC: "ace@ietf.org" Thread-Topic: Review of draft-palombini-ace-coap-pubsub-profile-01 Thread-Index: AdNBTA87mF1mAa3DTgyCd00ylmVtSQC1urYQ Date: Fri, 13 Oct 2017 13:22:05 +0000 Message-ID: References: <009701d34164$540c8cc0$fc25a640$@augustcellars.com> In-Reply-To: <009701d34164$540c8cc0$fc25a640$@augustcellars.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=francesca.palombini@ericsson.com; x-originating-ip: [80.216.69.172] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HE1PR07MB1530; 6:O+FP7KhDy/m+ZTro8bYtFybLrPcviF50mfm14MdfCRHgQV2J7kohJRknjkgox5ErllGzOq91ZVDdiRyVcwf9DUTHdDaEs9UEa8CBLk4kgWQPyshLI38irmGgCwBLjlIaabwAUPZppTneEfqxbHL7M3TsrNdA5Te1//CMFchiF+yaoZwFBYxs/n0fzMyj0CyLeAfrmWJ8qVQmV9TVqd5StOGEdWUrhMiYzYNAwarTDeRUvhmcL00Oj3zc4WOMZhCMZF2ftFrTIIZtO7T6MdZBwtAtaX3j1nfG7Cp0sZoecWH7TZ7YYKeQ8mWjsKIJFhnbqF0zG4I1pO3gZfbZks0+KA==; 5:dWKq9STMo5MCaQNCGcBbXeD9/U/g8LBb+6neDt3NrUhwPq2OdCAXWUkRpRApGAVTrDgCXH1DNRXP+8jUbGF89h4CgRLVjAReQVh9kAP3+GaKDv13iHL5R8d/ld2v7up/td+C/kAFzj3pFatxxzqozw==; 24:YJS5B2WQ0B2qoHO28bfFogDkBCxC656jC+EmxOrVgU2uWK/d6tW5oAS9sFUO8uUhriYVvwwa60XzletpLVE485w1KjM8JGnkwpNyOKX/5wA=; 7:ItHERgY0Qa5QDl2NUHxFQ30Eapa/yzPqvZ0Gp7E8Wfn6/oBIpSsBlQVHx4OMPoW0p0SZiQmKBNyekZfhRBTgKM/LUGUKnY2CgHZ9fRKNQuOtiWK/VTjciKZO31X61cPlCP0s+mQDpMBzLlFHH+clVv11fgOfUhTU42AVabLeonBVm1KSJfXGV3Lt+VyRiqtOS/kxoazjBdEDQhpo4jcV8w41obP+Bm9jgs7+gYc6EZs= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: be4022d0-efb0-4581-6bc1-08d5123d65f1 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:HE1PR07MB1530; x-ms-traffictypediagnostic: HE1PR07MB1530: x-exchange-antispam-report-test: UriScan:(158342451672863)(166708455590820); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3002001)(100000703101)(100105400095)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123558100)(20161123564025)(20161123555025)(20161123562025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:HE1PR07MB1530; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:HE1PR07MB1530; x-forefront-prvs: 04599F3534 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39860400002)(376002)(346002)(51444003)(189002)(199003)(13464003)(68736007)(110136005)(2950100002)(5660300001)(7696004)(229853002)(5250100002)(6506006)(3280700002)(8936002)(86362001)(230783001)(2501003)(8676002)(81156014)(81166006)(189998001)(54356999)(76176999)(50986999)(4326008)(97736004)(316002)(2900100001)(2906002)(6246003)(25786009)(99286003)(101416001)(55016002)(3660700001)(53936002)(66066001)(33656002)(305945005)(6436002)(7736002)(14454004)(6116002)(3846002)(102836003)(9686003)(105586002)(106356001)(53546010)(6306002)(478600001)(74316002)(966005); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB1530; H:HE1PR07MB1529.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Oct 2017 13:22:05.4793 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB1530 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02SbUhTYRTHee7LvA4vPC7FgyboKApLU0kYMUz7EIIVQgVTKpt6U1Gn7Jql H0QLrXzD1E2t1dQNk9kMxVmkFr5kpY1EpaRFmq5EKrKRihXVtrugb7/z/5/zP+eBhyElVXQg k60q5NQqZa5UJKZaFffl4X+GF5MjZ7ZiZJsbNaTsbr+JkHU3b4riyIReXbMowWjcIpKIFLE8 g8vNLuLU+2LPirOWF97RBQuxFx3Vb4kyNBZVhbwZwPvBemkSuViCxxHcbDlThcROfoZgvddK uwoK15Jg1fWJBKeZgLGBD7RQLCOYtE2450VYDtPvv7oNP9yAYKRmiXYZJA6FHl0d4eJtOB6m ahvcA374EKzYmpyxjJOjoVercMkU3glNc/fcMotPgWGdFM47CGvtXe4UbxwH5teVbh3hYPhe 3k0KmwLgjV1PCE/DYBx6SQrsD6vLv2mhPx3mbHVegh4Ki5p1kcDBMKOvRq7zAVd6wZ1WByUY EWC5/gUJfBQaWx2E0HQbwdTSrKcpDOwvLJ7UI2DXaj2bc6D6o9mTOkWDZkHjGdgOm5pXqB6F 3/jvcoH3QtugQyTwHuhs/0S6mMW+8LzVTrUhyoT8eY5Py8uMjo7g1NnpPJ+vilBxhX3I+UNG +n9GPkCrK/GjCDNI6sP2mBeTJbSyiC/OG0XAkFI/1mvAKbEZyuISTp2fqj6fy/GjKIihpAFs /KNphQRnKgu5HI4r4NT/XILxDixDMp/5lhNXki4PD5H1U9pZOvVh461fRaUhF+ICkrYSy3M5 WaLFGwo2Yh+XhB5OMwWlGqgKTUfImngi5vQGE3stUa9jnqR89v0hDznGzrO7pKbj1tUB7EeZ T2qvKs6l7sgbbEgw29rGI7sMxS27v6UrOyydhoqMUk2NMU9/4KmU4rOUUWGkmlf+BRCPc8Ud AwAA Archived-At: Subject: Re: [Ace] Review of draft-palombini-ace-coap-pubsub-profile-01 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, 13 Oct 2017 13:22:19 -0000 Hi Jim, Thanks for a thoroughly review!=20 I agree with many of your comments, and I modified the draft accordingly. I= have included your comments (and my answers) in the source of the draft, n= ext to what I thought was the right text for them, if you want to track it:= https://github.com/EricssonResearch/coap-pubsub-profile/blob/master/draft-= palombini-ace-coap-pubsub-profile.md=20 I report below the comments (and answers) which I think require more discus= sion. Thanks, Francesca > -----Original Message----- > From: Jim Schaad [mailto:ietf@augustcellars.com] > Sent: den 10 oktober 2017 03:09 > To: draft-palombini-ace-coap-pubsub-profile@ietf.org > Cc: ace@ietf.org > Subject: Review of draft-palombini-ace-coap-pubsub-profile-01 >=20 > Here are some comments on this draft. >=20 > 1. I find it difficult to call this a profile of the Oauth document in o= ne way. > This looks to me more of a "This is how you use the Oauth" document. > This echoes a comment that I made on the ACE base Oauth document. >=20 We should probably follow up on this comment on the ACE framework document. > 6. Overview: One of the things that I am not currently happy with is th= at you > are looking at AS1 and AS2 as being independent appliers of access contro= l > logic without any communication between them. I think that AS1 needs the > ability to give policy to AS2 on a topic after it has been created and be= fore > any subscribers get keys. In the case they are co-resident this is trivi= al, in > other cases it may not be. AS1 and AS2 have in my mind clearly separated functions. There is some coor= dination involved of course (to gain knowledge of the policies), but I thin= k that how this is dealt with is application specific. For example, there c= ould be some node distributing those (they do not need to talk to each othe= r directly). It may be good to add some generic considerations, do you thin= k that would be enough? >=20 > 7. Overview: It is not clear to me that your allocation of roles to AS1 = and > AS2 I correct. If you have a second publisher, does it need to talk to b= oth > AS1 and AS2 or just to AS2? Is this really an AS1 controls creation of t= opics > and AS2 controls publishing and subscribing to topics? If the publisher = loses > its membership in the group for any reason, should it be able to publish > willy-nilly anyway? I.e. should AS2 be able to "revoke" the publishers r= ight to > publish? > A second publisher would need to talk to both AS1 and AS2. As I intended, A= S1 controls who can publish to (or create) a topic on a broker, AS2 more ge= nerally controls who can decrypt the content of the publication. "Losing the membership" can mean "not being able to access (read or write) = the content of the publication", in which case AS2 should revoke the node's= rights or it can mean "not allowed to publish on the broker" (maybe it is = still allowed to subscribe to the topic), in which case AS1 should revoke t= he node's right. Both revocations are not specified for now. > 8. Overview: I don't think the picture is correct at the bottom of the = section. > You have a Publisher-Subscriber client/client association >=20 Both publisher and subscriber are CoAP client, as specified in the pub-sub = doc > 9. Overview: Is there any expectation that the broker should be notifi= ed > on a "revocation" of a publisher's right to publish? (As opposed to the = right > just expiring.) There is no need to enforce subscribers right to subscri= be > since a key roll over means that they are getting gibberish. Yes, the broker should be notified of revocation. This is not specified her= e, and I think this is a general topic that the framework should address: n= o profile deals with revocations so far, as far as I can tell. > 11. Section 3.1 - I don't' think that the returned info on the first req= uest is > going to be the same for publishers and subscribers. Not sure what this > should really look like. >=20 The broker _may_ send this info to both pub and sub, and then the subscribe= r could just discard the AS it does not need (AS1). Or the sub could know w= hat AS to contact from a different exchange. > 12. Section 3.1 - I am unsure what you believe is going to be accomplishe= d by > doing a RD lookup. You can get the name of the resource, but it would no= t > necessarily return the AS1, AS2 strings. >=20 Ok, I guess the same comment applies to https://tools.ietf.org/html/draft-i= etf-ace-dtls-authorize-01#section-2 (4th paragraph) ? Otherwise I might ha= ve misunderstood that. > 13. Section 3.1 - On the unauthorized response, I think you want to be > returning different responses to subscriber vs the broker. A subscriber = does > not need to know about AS1. Also I think you should be using the same ta= g > as the base profile for at least one of them - probably the first one you= would > contact. > I assume this was in this section (3.2) and not 3.1? Did you mean "publishe= r" instead of "broker"? As I mentioned in another comment, a subscriber may= just drop the AS1 info. I do use the same tag as the DTLS profile. Do you = think that it should anyway be stated somewhere? > 14. Section 3.1 - I am not sure that it makes any sense to set an audien= ce. > If the scope is the topic then all information exists. The audience real= ly the > subscriber. >=20 That's right. I removed the scope, since the example states that the audien= ce parameter contains the resource on the server (see https://tools.ietf.or= g/html/draft-seitz-ace-oauth-authz-00#section-6.5 , bullet A) > 15. Section 3.1 - You state that the algorithm must be a CE algorithm, bu= t I > think you mean a signing algorithm. >=20 Right, in COSE_Key. Also, I removed it from the last bullet because I could= not find it in the ACE framework doc anymore (https://tools.ietf.org/html/= draft-ietf-ace-oauth-authz-07#section-5.5.1) > 16. Section 3.1 - why not use the cnf return value for the key? Also th= ere is > no reason to make it a bstr rather than a map. >=20 I did not use the cnf because of the following reasoning: the key is not us= ed to authenticate the client (pub or sub) to the rs (broker), it is not a = pop-key related to a token (no token). For subs, there are both cnf and key= parameter (see {{fig-resp2-as2}}). Also, see the example on https://tools.= ietf.org/html/draft-seitz-ace-oauth-authz-00#section-6.5 (token-less excha= nge). OK, Changed to map. > 17. Section 3.1 - need to define a signers_keys element which returns al= l of > the signing keys. Defined as an array of keys. Return other signers for > multiple publishers. >=20 Are you sure this comment should be in this section? To a subscriber, yes, = the set of all signers keys are returned (see {{subs-profile}} section: "Th= e AS2 response contains a "cnf" parameter whose value is set to a COSE Key = Set, (Section 7 of {{RFC8152}}) i.e. an array of COSE Keys, which contains = the public keys of all authorized Publishers..."). If you did mean it for p= ublishers, I don't see why. > 19. Section 5 - Need to talk about how to deal with multiple publishers = - are > you assigning different keys or are you using different IV sections? > Need to ensure that you don't have an error from using the same key/iv pa= ir. Right, the key is the same ("key" in previous sections), but the IV is diff= erent. Added Base IV in the COSE_Key in previous section, and partial IV in= the COSE_Key. Added TODO for sending Partial IV range for each publisher. >=20 > 20. Section 5 - Are you containing a coap payload or a complete coap > message in the payload. CoAP payload. >=20 > 21. Section 5. Do you want to talk about coordination of the observer > number and the iv of a message? >=20 What do you mean by "observer number"? From nobody Fri Oct 13 09:18:09 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 371C7126E64 for ; Fri, 13 Oct 2017 09:18:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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=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 XLINemW1Ph9V for ; Fri, 13 Oct 2017 09:18:05 -0700 (PDT) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::236]) (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 50C01132076 for ; Fri, 13 Oct 2017 09:18:05 -0700 (PDT) Received: by mail-oi0-x236.google.com with SMTP id f66so15101454oib.2 for ; Fri, 13 Oct 2017 09:18:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=BnCde0NLyu4IeOSauiAqv+nGZPT4/hsyHGThCoAMBes=; b=SZRNrXuJRzjYJI/7DCcGxsbI3eIJ+8G7MPvLV2W3YFmG99LrOXuO32CYAqiKUbPU/y PhpkiqxVE5rvDqYDziRVbnE4hPMlcLxAw8gJX1691p11XXbl2ilxxeBBX3cTGCK71o7e MqHI75pclTH/H65uUV574Z+CbFJF6MBxconvTHL6YpZz+Lo+LHf8G40qsjbeiONNT9pY KLErknNNX6CNXT6Q+rgRMScpJYgyruXhZDVfPbjq1aOa5oXYqE9/sEJTTkJN4ct36KLI jM1QtNo2LXJ9Bc2I3IgTmqcbD1HuX9HkVWgUo3CJ394xjQKY/yPT0IECugYbAKhjuZQw DLiQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=BnCde0NLyu4IeOSauiAqv+nGZPT4/hsyHGThCoAMBes=; b=s78ZRLFFVXHbRlMkS/SS+7xaMW5bDlQv5QJZhtYRBuERz7gt024DYZzU8p8fWZxEIc 2HSL4O80tyMFv4oaXg6WC6w3AcItwdPz7P540TIvqmWLuQ8eWEllNgAnSZW5XZ4PWKFv NyHr03MrZX4K3rAvMkMx2RizC7c4EVOUk7yHO5jn9FrrAf/LcAP7g49LXmmnd2f0V6kT 343rzxBgkc71+f0+7/TeOS2AfUbAT/HZZNOiMDVGG5i+VO2u37r6hzwRUtOGPYgGMtnX juME3Lf0J58Q4zw+PLa5OgVlrGN0olZwEWq4Qo1ttIWewbUjAc+yuGYmOsup/pqqn62T grZg== X-Gm-Message-State: AMCzsaWloobXePBvD8qW8r/V2SBrjPCF/rZImq5fGJpNUTyMPzeK5ZYs m/1C2a3HFIsiAJKmKGUmMyFU21NUYViIg+hUOj2VFg== X-Google-Smtp-Source: ABhQp+S+gPVmQ6LPrR4CCOw7AFYkPMYmq9Z6LkCuS3zEoY/yEybdw+vbn3RBgI8Ma191yT4gj97PSipuU9kaaBzyuVE= X-Received: by 10.157.39.120 with SMTP id r111mr1222054ota.402.1507911484287; Fri, 13 Oct 2017 09:18:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.42.80 with HTTP; Fri, 13 Oct 2017 09:18:03 -0700 (PDT) From: Cigdem Sengul Date: Fri, 13 Oct 2017 17:18:03 +0100 Message-ID: To: ace@ietf.org Content-Type: multipart/alternative; boundary="001a113d193c5fafe5055b700005" Archived-At: Subject: [Ace] New version of draft-sengul-ace-mqtt-tls-profile 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, 13 Oct 2017 16:18:08 -0000 --001a113d193c5fafe5055b700005 Content-Type: text/plain; charset="UTF-8" Hello, As a preparation for the virtual interim meeting, we uploaded a new version for mqtt_tls profile. In this version, we have cleaned up the document and added a new section explaining how to improve token transport and error reporting with the new version of MQTT (MQTT v5). Looking forward to your comments. --Cigdem A new version of I-D, draft-sengul-ace-mqtt-tls-profile-01.txt has been successfully submitted by Cigdem Sengul and posted to the IETF repository. Name: draft-sengul-ace-mqtt-tls-profile Revision: 01 Title: MQTT-TLS profile of ACE Document date: 2017-10-12 Group: Individual Submission Pages: 20 URL: https://www.ietf.org/internet-drafts/draft-sengul-ace-mqtt-tls-profile-01.txt Status: https://datatracker.ietf.org/doc/draft-sengul-ace-mqtt-tls-profile/ Htmlized: https://tools.ietf.org/html/draft-sengul-ace-mqtt-tls-profile-01 Htmlized: https://datatracker.ietf.org/doc/html/draft-sengul-ace-mqtt-tls-profile-01 Diff: https://www.ietf.org/rfcdiff?url2=draft-sengul-ace-mqtt-tls-profile-01 Abstract: This document specifies a profile for the ACE (Authentication and Authorization for Constrained Environments) to enable authorization in an MQTT-based publish-subscribe messaging system. Proof-of- possession keys, bound to OAuth2.0 access tokens, are used to authenticate and authorize publishing and subscribing clients. The protocol relies on TLS for confidentiality and server authentication. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --001a113d193c5fafe5055b700005 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,

As = a preparation for the virtual interim meeting, we uploaded a new version fo= r mqtt_tls profile.=C2=A0
In this version, we have cleaned up the document and added= a new section explaining how to improve token transport and error reportin= g with the new version of MQTT (MQTT v5).

Looking forward to your comments. =C2=A0
=
--Cigdem
=


A new version of I-D, = draft-sengul-ace-mqtt-tls-profile-01.txt
has been successfully submitted by Cigdem S= engul and posted to the
IETF repository.

Name: draft-sengul-ace-mqtt-tls-profile
Revision: 01
Title: MQTT-TLS profile of ACE
Document date: 2017-10-12
Group: Individual S= ubmission
Pages: 2= 0
URL:=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0https://www.ietf.org/internet-drafts/draft-sengul-ace-mqtt-tls-pro= file-01.txt
Status:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0ht= tps://datatracker.ietf.org/doc/draft-sengul-ace-mqtt-tls-profile/
=
Htmlized:=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0https://tools.ietf.org/html/draft-= sengul-ace-mqtt-tls-profile-01
Htmlized:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0https://datatracker.ietf.org/doc/html/draft-sengul-ace-mqtt-= tls-profile-01
Diff:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-sengul-ace-mqtt-t= ls-profile-01

Abstract:
=C2=A0=C2=A0 This document specifies a profile for the ACE (Authentic= ation and
=C2=A0=C2=A0 Authorization for Constrained Environments) to enable authori= zation
= =C2=A0=C2=A0 in an MQTT-based publish-subscribe messaging system.=C2=A0=C2= =A0Proof-of-
=C2=A0=C2=A0 possession keys, bound to OAuth2.0 access tokens, are used= to
=C2= =A0=C2=A0 authenticate and authorize publishing and subscribing clients.=C2= =A0=C2=A0The
=C2=A0=C2=A0 protocol relies on TLS for confidentiality and server auth= entication.

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

The IETF Secretariat
--001a113d193c5fafe5055b700005-- From nobody Sat Oct 14 02:25:37 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49BCC13235C; Sat, 14 Oct 2017 02:25:08 -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 Ujvxbpq98_Ci; Sat, 14 Oct 2017 02:25:06 -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 F377E133049; Sat, 14 Oct 2017 02:25:02 -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 v9E9Ox8h004393; Sat, 14 Oct 2017 11:24:59 +0200 (CEST) Received: from [192.168.217.119] (p5DC7FC78.dip0.t-ipconnect.de [93.199.252.120]) (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 3yDfLg0x85zDMBr; Sat, 14 Oct 2017 11:24:59 +0200 (CEST) From: Carsten Bormann Content-Type: text/plain; charset=utf-8 X-Mao-Original-Outgoing-Id: 529665898.341332-7b72f59c77b8f11dd7ec6cdf17e94c6b Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Sat, 14 Oct 2017 11:24:58 +0200 Message-Id: <6241D667-C2A1-41EF-83CB-D264BF9DFD3F@tzi.org> To: ace , "core@ietf.org WG" , cose , cbor@ietf.org, t2trg@irtf.org X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [Ace] Constrained Node/Network Cluster @ IETF100: DRAFT AGENDA X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Oct 2017 09:25:08 -0000 Here is my usual eclectic condensed agenda based on the DRAFT AGENDA for IETF100. Remember that there is still quite some potential for changes. The CBOR/SUIT conflict needs to be fixed. Also, maybe CORE and 6TISCH are going to swap so we have more time between the two CORE meetings. All times are SGT (UTC+0800). (You can get pure UTC times on https://datatracker.ietf.org/meeting/agenda-utc, for those who want to listen from remote.) Gr=C3=BC=C3=9Fe, Carsten FRIDAY, November 10, 2017 -- Joint meeting of OCF and T2TRG @ OCF meeting venue SATURDAY/SUNDAY -- Hackathon (including various interops) MONDAY, November 13, 2017 0930-1200 Morning Session I Collyer ART dispatch Dispatch WG - 0930-1100 Joint = with ARTAREA Collyer ART httpbis Hypertext Transfer Protocol WG - = 1100-1200 Olivia INT *** lpwan IPv6 over Low Power Wide-Area Networks = WG Sophia OPS anima Autonomic Networking Integrated Model = and Approach WG 1330-1530 Afternoon Session I Olivia ART *** core Constrained RESTful Environments WG Padang OPS v6ops IPv6 Operations WG 1550-1720 Afternoon Session II Bras Basah ART *** cbor Concise Binary Object Representation = Maintenance and Extensions WG Collyer INT homenet Home Networking WG Padang IRTF maprg Measurement and Analysis for Protocols Canning SEC *** suit Software Updates for Internet of Things = WG 1740-1840 Afternoon Session III Padang SEC tls Transport Layer Security WG Canning TSV tsvwg Transport Area Working Group WG TUESDAY, November 14, 2017 0930-1200 Morning Session I Collyer SEC *** ace Authentication and Authorization for = Constrained Environments WG Sophia TSV taps Transport Services WG 1330-1530 Afternoon Session I Olivia ART *** core Constrained RESTful Environments WG Canning OPS v6ops IPv6 Operations WG Bras Basah SEC tokbind Token Binding WG Padang TSV quic QUIC WG 1550-1750 Afternoon Session II Padang IRTF*** t2trg Thing-to-Thing Olivia RTG bier Bit Indexed Explicit Replication WG Sophia SEC oauth Web Authorization Protocol WG WEDNESDAY, November 15, 2017 0930-1200 Morning Session I Sophia INT dnssd Extensions for Scalable DNS Service = Discovery WG Collyer INT ipwave IP Wireless Access in Vehicular = Environments WG - 0930-1030 Collyer INT *** lwig Light-Weight Implementation Guidance WG = - 1100-1200 Bras Basah IRTF icnrg Information-Centric Networking Canning TSV quic QUIC WG 1330-1500 Afternoon Session I Bras Basah ART uta Using TLS in Applications WG Collyer SEC *** teep A Protocol for Dynamic Trusted Execution = Environment Enablement BOF Orchard TSV rmcat RTP Media Congestion Avoidance = Techniques WG 1520-1650 Afternoon Session II Collyer INT intarea Internet Area Working Group WG Orchard SEC oauth Web Authorization Protocol WG THURSDAY, November 16, 2017 0930-1200 Morning Session I Collyer INT 6man IPv6 Maintenance WG Padang IRTF irtfopen IRTF Open Meeting Sophia RTG detnet Deterministic Networking WG Canning SEC tls Transport Layer Security WG 1330-1530 Afternoon Session I Sophia INT *** 6lo IPv6 over Networks of = Resource-constrained Nodes WG Collyer IRTF panrg Path Aware Networking Proposed RG Padang SEC saag Security Area Open Meeting 1550-1750 Afternoon Session II Sophia INT *** 6tisch IPv6 over the TSCH mode of IEEE = 802.15.4e WG Canning RTG rtgarea Routing Area Open Meeting 1810-1910 Afternoon Session III Orchard SEC curdle CURves, Deprecating and a Little more = Encryption WG Padang TSV tsvarea Transport Area Open Meeting FRIDAY, November 17, 2017 0930-1130 Morning Session I Canning ART httpbis Hypertext Transfer Protocol WG Orchard RTG babel Babel routing protocol WG Collyer TSV tsvwg Transport Area Working Group WG 1150-1320 Afternoon Session I Olivia SEC acme Automated Certificate Management = Environment WG From nobody Sat Oct 14 02:57:21 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A89C1323B4; Sat, 14 Oct 2017 02:56:35 -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 r2FHkt4ggfUC; Sat, 14 Oct 2017 02:56:27 -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 0E5EE13307F; Sat, 14 Oct 2017 02:56:22 -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 v9E9uJYD028675; Sat, 14 Oct 2017 11:56:19 +0200 (CEST) Received: from [192.168.217.119] (p5DC7FC78.dip0.t-ipconnect.de [93.199.252.120]) (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 3yDg2q2lbCzDMC7; Sat, 14 Oct 2017 11:56:19 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carsten Bormann In-Reply-To: <6241D667-C2A1-41EF-83CB-D264BF9DFD3F@tzi.org> Date: Sat, 14 Oct 2017 11:56:18 +0200 X-Mao-Original-Outgoing-Id: 529667778.821235-c9d7eaa3be613be80ad8719f41133613 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6241D667-C2A1-41EF-83CB-D264BF9DFD3F@tzi.org> To: ace , "core@ietf.org WG" , cose , cbor@ietf.org, t2trg@irtf.org X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [Ace] FIXED: Constrained Node/Network Cluster @ IETF100: DRAFT AGENDA X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Oct 2017 09:56:36 -0000 (Sorry for the resend; the previous version missed out on all meetings in the room "VIP A", and I didn't see those conflicts either.) Here is my usual eclectic condensed agenda based on the DRAFT AGENDA for IETF100. Remember that there is still quite some potential for changes. The CBOR/SUIT conflict needs to be fixed. Also, maybe CORE and 6TISCH are going to swap so we have more time between the two CORE meetings. ROLL vs. TEEP is a bit unfortunate, as is DINRG vs. LPWAN vs. DISPATCH. All times are SGT (UTC+0800). (You can get pure UTC times on https://datatracker.ietf.org/meeting/agenda-utc, for those who want to listen from remote.) Gr=C3=BC=C3=9Fe, Carsten MONDAY, November 13, 2017 0930-1200 Morning Session I Collyer ART dispatch Dispatch WG - 0930-1100 Joint = with ARTAREA Collyer ART httpbis Hypertext Transfer Protocol WG - = 1100-1200 Olivia INT *** lpwan IPv6 over Low Power Wide-Area Networks = WG VIP A IRTF*** dinrg Decentralized Internet Infrastructure = Proposed RG Sophia OPS anima Autonomic Networking Integrated Model = and Approach WG 1330-1530 Afternoon Session I Olivia ART *** core Constrained RESTful Environments WG Padang OPS v6ops IPv6 Operations WG 1550-1720 Afternoon Session II Bras Basah ART *** cbor Concise Binary Object Representation = Maintenance and Extensions WG Collyer INT homenet Home Networking WG Padang IRTF maprg Measurement and Analysis for Protocols Canning SEC *** suit Software Updates for Internet of Things = WG 1740-1840 Afternoon Session III Padang SEC tls Transport Layer Security WG Canning TSV tsvwg Transport Area Working Group WG TUESDAY, November 14, 2017 0930-1200 Morning Session I Collyer SEC *** ace Authentication and Authorization for = Constrained Environments WG Sophia TSV taps Transport Services WG 1330-1530 Afternoon Session I Olivia ART *** core Constrained RESTful Environments WG Canning OPS v6ops IPv6 Operations WG Bras Basah SEC tokbind Token Binding WG Padang TSV quic QUIC WG 1550-1750 Afternoon Session II Padang IRTF*** t2trg Thing-to-Thing Olivia RTG bier Bit Indexed Explicit Replication WG Sophia SEC oauth Web Authorization Protocol WG WEDNESDAY, November 15, 2017 0930-1200 Morning Session I Sophia INT dnssd Extensions for Scalable DNS Service = Discovery WG Collyer INT ipwave IP Wireless Access in Vehicular = Environments WG - 0930-1030 Collyer INT *** lwig Light-Weight Implementation Guidance WG = - 1100-1200 Bras Basah IRTF icnrg Information-Centric Networking Canning TSV quic QUIC WG 1330-1500 Afternoon Session I Bras Basah ART uta Using TLS in Applications WG VIP A RTG *** roll Routing Over Low power and Lossy = networks WG Collyer SEC *** teep A Protocol for Dynamic Trusted Execution = Environment Enablement BOF Orchard TSV rmcat RTP Media Congestion Avoidance = Techniques WG 1520-1650 Afternoon Session II Collyer INT intarea Internet Area Working Group WG VIP A IRTF cfrg Crypto Forum Orchard SEC oauth Web Authorization Protocol WG THURSDAY, November 16, 2017 0930-1200 Morning Session I Collyer INT 6man IPv6 Maintenance WG Padang IRTF irtfopen IRTF Open Meeting Sophia RTG detnet Deterministic Networking WG Canning SEC tls Transport Layer Security WG 1330-1530 Afternoon Session I Sophia INT *** 6lo IPv6 over Networks of = Resource-constrained Nodes WG Collyer IRTF panrg Path Aware Networking Proposed RG Padang SEC saag Security Area Open Meeting 1550-1750 Afternoon Session II VIP A ART ice Interactive Connectivity Establishment = WG - 1550-1650 Sophia INT *** 6tisch IPv6 over the TSCH mode of IEEE = 802.15.4e WG Canning RTG rtgarea Routing Area Open Meeting 1810-1910 Afternoon Session III Orchard SEC curdle CURves, Deprecating and a Little more = Encryption WG Padang TSV tsvarea Transport Area Open Meeting FRIDAY, November 17, 2017 0930-1130 Morning Session I Canning ART httpbis Hypertext Transfer Protocol WG Orchard RTG babel Babel routing protocol WG Collyer TSV tsvwg Transport Area Working Group WG 1150-1320 Afternoon Session I Olivia SEC acme Automated Certificate Management = Environment WG From nobody Sun Oct 15 09:06:23 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D4B71321C9; Sun, 15 Oct 2017 09:06:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.821 X-Spam-Level: X-Spam-Status: No, score=-2.821 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i3biifU9ohd6; Sun, 15 Oct 2017 09:06:20 -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 CF3771320D8; Sun, 15 Oct 2017 09:06:19 -0700 (PDT) X-AuditID: c1b4fb3a-dffff70000006897-0e-59e3877954f3 Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.183.81]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 2E.39.26775.97783E95; Sun, 15 Oct 2017 18:06:18 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.191]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.03.0352.000; Sun, 15 Oct 2017 18:06:17 +0200 From: =?iso-8859-1?Q?Ari_Ker=E4nen?= To: "ace@ietf.org" , "draft-palombini-ace-coap-pubsub-profile@ietf.org" Thread-Topic: draft-palombini-ace-coap-pubsub-profile-01 review Thread-Index: AQHTRc+IBOSSxhiEyUWpB37lN5BNhg== Date: Sun, 15 Oct 2017 16:06:17 +0000 Message-ID: <17005C60-8778-4C9C-9824-F08411EE0552@ericsson.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <491D1838E7B8234B9ED22481D9B0CCFF@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpikeLIzCtJLcpLzFFi42KZGbE9ULeq/XGkwe3j3Bbfv/UwW6zZsorJ gcljyZKfTAGMUVw2Kak5mWWpRfp2CVwZLZ17WAt+sVYs3TKFrYHxAksXIyeHhICJxMd7z9m6 GLk4hASOMEo0v1rICpIQEljCKHH+kDuIzSZgLzF5zUdGkCIRgR5GiS+fOphBEsICVhITe88z dTFyACXsJT59LwEJiwjoSTzd/IERxGYRUJVYvnMGWDkvUMm+0xuYQcqFBBIk/u01AwlzCiRK 3PyxCuweRgExie+n1jCB2MwC4hK3nsxngrhTQGLJnvPMELaoxMvH/1ghbCWJxiVPWCHq9SRu TJ3CBmFbS5x50gA1R1ti2cLXUCcISpyc+YRlAqPoLCQrZiFpn4WkfRaS9llI2hcwsq5iFC1O LS7OTTcy0kstykwuLs7P08tLLdnECIyZg1t+W+1gPPjc8RCjAAejEg/vr5zHkUKsiWXFlbmH GCU4mJVEeOc0AIV4UxIrq1KL8uOLSnNSiw8xSnOwKInzOuy7ECEkkJ5YkpqdmlqQWgSTZeLg lGpg9PYw3t/kfDwz9fqxB7OLZRh3yW+dLFi7xt8q/1z4R+utMh+V9j/t26j005V5x/bja21E VtSzKm1crblitpNM6dFbr29lXrr/OEBQ4hpzbUpz5PvLLiI7Vtx3E70dzTdl1xoe5+i7sVPC KhuyS7dd3SV5IsVjnfa/p259r0q/XWKO+jn1jPjBU0osxRmJhlrMRcWJAC60paWVAgAA Archived-At: Subject: [Ace] draft-palombini-ace-coap-pubsub-profile-01 review 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, 15 Oct 2017 16:06:21 -0000 Hi, I had a look at the CoAP pub/sub profile draft and overall it looked good t= o me. This mechanism is essential for e2e security with the CoAP pub/sub br= oker, so I'm happy to see this going forward. Couple of comments below; I'll send nits separately off-list. Section 2: Good to mention early enough that AS1 and AS2 can be (and commonly are?) th= e same host. Sec 5: > The (G) message is the subscription of the > Subscriber, which is unprotected. Can't G be protected with regular DTLS? I think the considerations about symmetric crypto could be worth lifting fr= om security considerations to a separate section. That would be interesting= to explore more; unless we want to keep that out of scope. Cheers, Ari= From nobody Sun Oct 15 17:27:04 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C70D21332CA; Sun, 15 Oct 2017 17:27:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.806 X-Spam-Level: * X-Spam-Status: No, score=1.806 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, LOCALPART_IN_SUBJECT=1.107, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=augustcellars.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id af6_Y_0qPxec; Sun, 15 Oct 2017 17:27:01 -0700 (PDT) Received: from mail4.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 659501321A4; Sun, 15 Oct 2017 17:27:01 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1508113613; h=from:subject:to:date:message-id; bh=PJqmh0dkrtXr6rh1sF48siWDnnTeknGfadKNI7d5xEI=; b=BAL8hPQOhwyNi24HE8t94xvb5T0wqYwcBRIQL7FFr8S7lgXy9xR2EagmiMcmWZ8AYdOQ376FaGT IE7C5SS2gAlo19KQEr4EV8bd/PI8YIN9PK4ZJDBdr7DvBzhhWN0auyQmss6PNu3ZvW6RSD8/IJF91 LJ/Srr8IlqdfR9SIof5k78m35rqzpxwTi2TN2wI66R7SBxz1mDOMpjZL5eztM6XQDYqqfOPr0ctRJ imRIG6mJANsTRMPHNrQtIGIBQ4PloJpBPRL7Qiu9HyPAUybyKKnscfT+/uyYmo7nj6CsojRc5MxFV NYNz3NbxcdrvwaQaE9CYQanIy/DM5rWDCCzw== Received: from mail2.augustcellars.com (192.168.1.201) by mail4.augustcellars.com (192.168.1.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Sun, 15 Oct 2017 17:26:53 -0700 Received: from Hebrews (192.168.1.162) by mail2.augustcellars.com (192.168.1.201) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Sun, 15 Oct 2017 17:26:00 -0700 From: Jim Schaad To: CC: Date: Sun, 15 Oct 2017 17:26:49 -0700 Message-ID: <002d01d34615$76d4c730$647e5590$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdNGFVF7wHEYWKO9RYCjxbRkbcRzvQ== X-Originating-IP: [192.168.1.162] Archived-At: Subject: [Ace] draft-palombini-ace-coap-pubsub-profile 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, 16 Oct 2017 00:27:03 -0000 After doing some reading elsewhere, I think it would be reasonable to outline the version of security when the pub/sub agent can be trusted. This makes a contrast with this model that people should understand. Jim From nobody Mon Oct 16 01:48:50 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECC2E134493 for ; Mon, 16 Oct 2017 01:48:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CT7t52MdCSAw for ; Mon, 16 Oct 2017 01:48:47 -0700 (PDT) Received: from se-out2.mx-wecloud.net (se-out2.mx-wecloud.net [89.221.255.177]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C843134474 for ; Mon, 16 Oct 2017 01:48:46 -0700 (PDT) Received: from sp-mail-2.sp.se (unknown [194.218.146.197]) by se-out2.mx-wecloud.net (Postfix) with ESMTPS id 29A4F223800; Mon, 16 Oct 2017 08:48:43 +0000 (UTC) Received: from [192.168.0.166] (10.116.0.226) by sp-mail-2.sp.se (10.100.0.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1261.35; Mon, 16 Oct 2017 10:48:43 +0200 To: Kepeng Li , "ace@ietf.org" References: From: Ludwig Seitz Message-ID: Date: Mon, 16 Oct 2017 10:48:43 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="gbk"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.116.0.226] X-ClientProxiedBy: sp-mail-1.sp.se (10.100.0.161) To sp-mail-2.sp.se (10.100.0.162) X-CMAE-Score: 0 X-CMAE-Analysis: v=2.2 cv=KqQ94SeN c=1 sm=1 tr=0 a=L5DDne6A+dD0FbDkt2Fblw==:117 a=L5DDne6A+dD0FbDkt2Fblw==:17 a=sZ8rJzgPlrQA:10 a=Zu_UBlEkk2cA:10 a=02M-m0pO-4AA:10 a=QLPfpYkryAO4RqcpiSkA:9 a=AWzbc7it75AA:10 a=V2CapFxqm0gA:10 a=ePWGEMN2vnwA:10 X-Virus-Scanned: clamav-milter 0.99.2 at MailSecurity X-Virus-Status: Clean X-MailSecurity-Status: 0 X-Scanned-By: WeCloud MailSecurity X-MailSecurity-Score: 0 Archived-At: Subject: Re: [Ace] ACE virtual interim meeting on 18th Oct to discuss ACE roadmap 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, 16 Oct 2017 08:48:49 -0000 Hello Kepeng, short agenda request: I'd like 5 minutes to discuss draft-erdtman-ace-rpcc. I'm hoping this will be a very short discussion. /Ludwig -- Ludwig Seitz, PhD Security Lab, RISE SICS Phone +46(0)70-349 92 51 From nobody Mon Oct 16 23:52:59 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A54131332D5; Mon, 16 Oct 2017 23:52:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 D4cfjYWxIELA; Mon, 16 Oct 2017 23:52:57 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88E2C1332E3; Mon, 16 Oct 2017 23:52:56 -0700 (PDT) X-AuditID: c1b4fb25-dd3ff70000000c94-ed-59e5a8c6c22f Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.183.63]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 31.0A.03220.6C8A5E95; Tue, 17 Oct 2017 08:52:54 +0200 (CEST) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.63) with Microsoft SMTP Server (TLS) id 14.3.352.0; Tue, 17 Oct 2017 08:52:54 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=oMdjk8EmYkS/ekgY4pX+pgQu61e1taXu1A44RqBZkow=; b=FUCUJyF3WcXQtVXakZ5AOSdz4bOnjp+yzN+SLIqaEn3NgHKn7a30s+bjbRyLBV6PL1g859kGkcTOqgL3hCENekjKcm+nr6IJpK+dGrJKLctw3YYJx/G79vCZpvO3Ic2qYdzLTigPeqfbLrAidtcgFJw58uvONlHQDqdhTVbLynU= Received: from HE1PR07MB1529.eurprd07.prod.outlook.com (10.169.122.151) by HE1PR07MB1529.eurprd07.prod.outlook.com (10.169.122.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.5; Tue, 17 Oct 2017 06:52:52 +0000 Received: from HE1PR07MB1529.eurprd07.prod.outlook.com ([fe80::11af:c0a0:4d0d:d5f1]) by HE1PR07MB1529.eurprd07.prod.outlook.com ([fe80::11af:c0a0:4d0d:d5f1%13]) with mapi id 15.20.0077.019; Tue, 17 Oct 2017 06:52:52 +0000 From: Francesca Palombini To: =?iso-8859-1?Q?Ari_Ker=E4nen?= , "ace@ietf.org" , "draft-palombini-ace-coap-pubsub-profile@ietf.org" Thread-Topic: draft-palombini-ace-coap-pubsub-profile-01 review Thread-Index: AQHTRc+UGYuSNuX9F0KeTs849x3yuaLnmmsw Date: Tue, 17 Oct 2017 06:52:52 +0000 Message-ID: References: <17005C60-8778-4C9C-9824-F08411EE0552@ericsson.com> In-Reply-To: <17005C60-8778-4C9C-9824-F08411EE0552@ericsson.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=francesca.palombini@ericsson.com; x-originating-ip: [192.176.1.84] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HE1PR07MB1529; 6:zyqdglt3H6mLeAZn5WpBp/WpG+d2qeBFETs5AXd8siX9SI9mod+GzzIs0OuCiaBRBBkv26UwhsQXr6Ih5eE1JqoBtwmeNyt38HWUXjJul0sD/h6UptqmuCZFioqWvxTQDBohSBmIs2D4qDcG7WA2I68aghyPS/saZDUWsvc3tXEz4OWbYmC+X+kWTL/QTBJMIiTgdcIZy+LufrR5rrgbcDlXx3Erj8qI8+k8E4wKabenSGYXoN6qri+hVR8u7WSpkr05DUOjx8wF3kfyUq4MWynDsK7A0zrPySkc/EWIuKWvb4nM4VTAPY5QqgKbGtDSS6vY7oNbDWRK7N7Hh+pHOg==; 5:mazExCDU1HFqMPOhpC4ArkyfHsqhQXvdUHk6boeOnPJGxU+IW7/Z1JeeCzYMsequkNNiKpRCNcQM0jTLpgWJ6F2O5bS4YEwxmiGfEBTuXQrIzttN18sEzr/Yw7sX8f+e7IUYIhPU3euNNoIqMl3tZjbYCYCh8dk03REcS3hIJUM=; 24:7hS4/f15sEMzvYJ4QVBVPG174M8efodOMNB9v3jqk3OvST+qBtPhcCDLrUUPsSoqADDqwEFcQftFB8x4vhTQqgEgnCECoCPbBhpfB7fQh2w=; 7:R7oVXPhSsbr9lhI8f/0XzfDLmBs24P8Gn4wAHtlpHs0qVO+c0gJ64zU91BC3KGuHK7jDpIwbrHo16vqFZ6qEnZ12zVwKHjEYVPAjMuasYeAVx8ML6D0225LHY62ueygvQIaMzoldkVp1Ye3uBUE2gl/z6Mla2ln3Z9kg59PXZOxdpD0b6vCJ6mLClqdCutWnDIiDB8SGHS5f4sn66mRBlN1iL9YpTDzqDdfRNgaZGHs= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 94bf5e20-140d-4600-3546-08d5152bb050 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:HE1PR07MB1529; x-ms-traffictypediagnostic: HE1PR07MB1529: x-exchange-antispam-report-test: UriScan:(192374486261705); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(100000703101)(100105400095)(10201501046)(3002001)(6041248)(20161123562025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123564025)(20161123555025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:HE1PR07MB1529; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:HE1PR07MB1529; x-forefront-prvs: 04631F8F77 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39860400002)(376002)(346002)(13464003)(199003)(189002)(9686003)(74316002)(966005)(6246003)(68736007)(5660300001)(6436002)(2201001)(105586002)(2950100002)(33656002)(99286003)(189998001)(53936002)(97736004)(6506006)(55016002)(3846002)(6306002)(6116002)(7696004)(102836003)(316002)(66066001)(2900100001)(50986999)(76176999)(8936002)(5250100002)(2501003)(14454004)(54356999)(110136005)(230783001)(229853002)(7736002)(8676002)(86362001)(3280700002)(3660700001)(2906002)(450100002)(305945005)(25786009)(101416001)(81156014)(53546010)(81166006)(478600001)(106356001); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB1529; H:HE1PR07MB1529.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Oct 2017 06:52:52.7835 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB1529 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmleLIzCtJLcpLzFFi42KZGbHdXvfYiqeRBpNnmVl8/9bDbLFmyyom ByaPJUt+MgUwRnHZpKTmZJalFunbJXBlzDj3laXgG3/F+ct32BoYX/B0MXJySAiYSHxv7WYD sYUEjjBKNDzM62LkArJPMEocu7afFcRhEehllpj6dgU7RGY6k0TrhyOsEM5jRonjbd/YQfrZ BGwkLjx8D5YQETjOKNE2pZURJCEsYCcx/c4bIJsDKGEv8el7CUhYRMBIYtq8SWAlLAKqEu07 /4DN4RWIkZh+aQHUtmmMEgs7/4IdyCngIHFsxWawIkYBWYkvjauZQWxmAXGJW0/mM0E8JCCx ZM95ZghbVOLl43+sEPXJEldu97FDxBUkXnU3sEHYshKX5nczgiyTEJjFLvFw0UKohJ7E1olv GSFsX4nzj2awQRTNA7po4T2oDVoSi/9vh5pqLfHy3G5WCDtb4vKmvVBTT7NKzF13GmqqjMSC 76/ZIRKfWSU2H5vANoFRZxaSNyBsPYkbU6ewQdjaEssWvmaeBQ4bQYmTM5+wLGBkWcUoWpxa nJSbbmSsl1qUmVxcnJ+nl5dasokRmDQObvmtuoPx8hvHQ4wCHIxKPLypM59GCrEmlhVX5h5i lOBgVhLhXTcJKMSbklhZlVqUH19UmpNafIhRmoNFSZzXcd+FCCGB9MSS1OzU1ILUIpgsEwen VAMjC28sv8XTItG1p+yyPeOUDatufFU5F7x9s2nK/AfSJ2brXXo6e9ZFxQt+K3X7BOw3Tn3C e+zjI8a6s+eeSGvz3hI78lHaj93ROHz+0QXX7xyuP+MW8XSiskudWV3JLeV9CZyzuZZwebXb WS08eqGlYoLi7rxlTifWeh3TSlBJkjvn9ueY26nVSizFGYmGWsxFxYkAtif2IBYDAAA= Archived-At: Subject: Re: [Ace] draft-palombini-ace-coap-pubsub-profile-01 review 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, 17 Oct 2017 06:52:59 -0000 Thanks a lot Ari for the review! Answers inline. Francesca > -----Original Message----- > From: Ace [mailto:ace-bounces@ietf.org] On Behalf Of Ari Ker=E4nen > Sent: den 15 oktober 2017 18:06 > To: ace@ietf.org; draft-palombini-ace-coap-pubsub-profile@ietf.org > Subject: [Ace] draft-palombini-ace-coap-pubsub-profile-01 review >=20 > Hi, >=20 > I had a look at the CoAP pub/sub profile draft and overall it looked good= to > me. This mechanism is essential for e2e security with the CoAP pub/sub > broker, so I'm happy to see this going forward. >=20 > Couple of comments below; I'll send nits separately off-list. >=20 >=20 > Section 2: >=20 > Good to mention early enough that AS1 and AS2 can be (and commonly are?) > the same host. >=20 Ok, will add. > Sec 5: > > The (G) message is the subscription of the > > Subscriber, which is unprotected. >=20 > Can't G be protected with regular DTLS? >=20 Yes it could, but currently the model does not require a security associati= on between Subscriber and Broker, since I did not consider critical for the= broker to only accept subscription from subscribers that are authorized (a= n unauthorized subscriber would not be able to read the encrypted content o= f the notifications anyway). The protection of subscription could be easily= added, making it similar to publications, which are protected with regular= DTLS (or alternatives); the overhead would be that each subscriber should = access the AS and get all the information to start a secure exchange with t= he broker. I will add some considerations about that in the draft. > I think the considerations about symmetric crypto could be worth lifting = from > security considerations to a separate section. That would be interesting = to > explore more; unless we want to keep that out of scope. >=20 Ok. >=20 > Cheers, > Ari > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace From nobody Tue Oct 17 00:28:24 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 167EB133068; Tue, 17 Oct 2017 00:28:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fga5R23fa4Oc; Tue, 17 Oct 2017 00:28:21 -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 5FA57126CB6; Tue, 17 Oct 2017 00:28:21 -0700 (PDT) X-AuditID: c1b4fb3a-de7ff70000006897-ae-59e5b11308a8 Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.183.39]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 9E.13.26775.311B5E95; Tue, 17 Oct 2017 09:28:19 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.191]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.03.0352.000; Tue, 17 Oct 2017 09:28:18 +0200 From: =?iso-8859-1?Q?Ari_Ker=E4nen?= To: Francesca Palombini CC: "ace@ietf.org" , "draft-palombini-ace-coap-pubsub-profile@ietf.org" Thread-Topic: draft-palombini-ace-coap-pubsub-profile-01 review Thread-Index: AQHTRc+IKD3EUXpYF0m+gej98+IRk6Lne/QAgAAJ6QA= Date: Tue, 17 Oct 2017 07:28:18 +0000 Message-ID: <84E44882-4EEF-42A1-9C5B-C3C687A1AA22@ericsson.com> References: <17005C60-8778-4C9C-9824-F08411EE0552@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnkeLIzCtJLcpLzFFi42KZGbFdXVd449NIg9+PJC2+f+thtlizZRWT A5PHkiU/mQIYo7hsUlJzMstSi/TtErgyWqetZCu4x1Hx5/pH9gbGdvYuRk4OCQETidYHOxhB bCGBI4wSS6d5QdhLGCVWzYkBsdkE7CUmr/kIViMiYCXRdeoLaxcjFwezQA+jxKk5r1hBEsIC dhLTzj9m6WLkACqyl/j0vQSmfv7yFWC7WARUJZb9mMQMYvMClbx9uZ4RZI6QwEtGiWOrf4Et 4BSIlWiYug/MZhQQk/h+ag0TiM0sIC5x68l8JoijBSSW7DnPDGGLSrx8/I8VwlaSWHT7M1S9 nsSNqVPYIGxriYuNEA8zC2hLLFv4GuoIQYmTM5+wTGAUm4VkxSwk7bOQtM9C0j4LSfsCRtZV jKLFqcXFuelGRnqpRZnJxcX5eXp5qSWbGIHRdHDLb6sdjAefOx5iFOBgVOLh9Zv5NFKINbGs uDL3EKMEB7OSCO+6SUAh3pTEyqrUovz4otKc1OJDjNIcLErivA77LkQICaQnlqRmp6YWpBbB ZJk4OKUaGGNC6zodK/7/3+01fXldxLl7ycaN+f0L5H6vtXutEvP2pk7zIRFvrvbJicxbBH/w MBmEsjcq+e9859J6fBV3te1Zj+ipOx+WnDD8tPqyRG79hO6LOxzKemKKF+y5GFDhI5R3cJEs 4yL3j5fndO91WSShYfNz44cjzFenzitg+yui/Dmj/ljQbSWW4oxEQy3mouJEAJzm4yuiAgAA Archived-At: Subject: Re: [Ace] draft-palombini-ace-coap-pubsub-profile-01 review 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, 17 Oct 2017 07:28:23 -0000 > On 17 Oct 2017, at 9.52, Francesca Palombini wrote: [...] >=20 >> Sec 5: >>> The (G) message is the subscription of the >>> Subscriber, which is unprotected. >>=20 >> Can't G be protected with regular DTLS? >>=20 >=20 > Yes it could, but currently the model does not require a security associa= tion between Subscriber and Broker, since I did not consider critical for t= he broker to only accept subscription from subscribers that are authorized = (an unauthorized subscriber would not be able to read the encrypted content= of the notifications anyway). The protection of subscription could be easi= ly added, making it similar to publications, which are protected with regul= ar DTLS (or alternatives); the overhead would be that each subscriber shoul= d access the AS and get all the information to start a secure exchange with= the broker. I will add some considerations about that in the draft. Sounds good. While not critical, I think that's a very useful feature and g= ood to make clear how it can be achieved where needed. Cheers, Ari= From nobody Tue Oct 17 00:33:53 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20C20132A05 for ; Tue, 17 Oct 2017 00:33:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 rk4Edw04DAC6 for ; Tue, 17 Oct 2017 00:33:50 -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 E7D27133068 for ; Tue, 17 Oct 2017 00:33:49 -0700 (PDT) X-AuditID: c1b4fb2d-bddff7000000268d-ea-59e5b25bc363 Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.183.63]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 60.7F.09869.B52B5E95; Tue, 17 Oct 2017 09:33:47 +0200 (CEST) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.63) with Microsoft SMTP Server (TLS) id 14.3.352.0; Tue, 17 Oct 2017 09:33:47 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=4Qjpy+W49QrtUgGqNfZ/iP5wT4uy7MkqC/FSp7BMBGo=; b=icxqhbxJET4fDLiCAjfWdySkQ9nrz+NkxcBzgEZcylaKVHjDnu4rM5s/68EaQ2S4OnhQNiDfJ0TvuzJ2tlIMpMZUIrF3yo4IJJX68P7LYOF3OgXgmOcgH+dqeqkBeUF1KvpJnM+IwrglM5nkOHxIz9ZKFThl572Ka7vaWVhKyeM= Received: from HE1PR07MB1529.eurprd07.prod.outlook.com (10.169.122.151) by HE1PR07MB1531.eurprd07.prod.outlook.com (10.169.122.153) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.5; Tue, 17 Oct 2017 07:33:42 +0000 Received: from HE1PR07MB1529.eurprd07.prod.outlook.com ([fe80::11af:c0a0:4d0d:d5f1]) by HE1PR07MB1529.eurprd07.prod.outlook.com ([fe80::11af:c0a0:4d0d:d5f1%13]) with mapi id 15.20.0077.019; Tue, 17 Oct 2017 07:33:42 +0000 From: Francesca Palombini To: "ace@ietf.org" Thread-Topic: New Version Notification for draft-seitz-ace-oscoap-profile-05.txt Thread-Index: AQHTRnnYZ+kuPMrhPUquPKpkBa8R26LnpVFg Date: Tue, 17 Oct 2017 07:33:42 +0000 Message-ID: References: <150815669168.315.17398409846590519511.idtracker@ietfa.amsl.com> In-Reply-To: <150815669168.315.17398409846590519511.idtracker@ietfa.amsl.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.176.1.84] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HE1PR07MB1531; 6:/+7rFM53xjKbpcKJGUlZVV2LGQVALlyDIk848j2bKiGYq2GKvHO/IQmqQ8MDpEycB1PIcGyNvpvHFvu0Z5I7FqA7PRdKMyxeRFSC9IVYllYXEZzGaRnkCyG5B+bTat7hax0EjS44BWtuCF+faDahURm9YKNYBz+78nFfMsXpb4DG5pkZY7zGkwTkSPwDDE3Kj3wJ0hztxfja4dkl4X/kjOCOQ0Yuza5NZSaJPRnIjRD+pyR+y47qJPJFbjLcRBRh6E8gGKHbByMwme84Eu7uZHtNcrF6ci2s2jLkJntwQ5hegRiqqzrp1YKitFyTU3jX5V1l3g8RiRCEEgRtchMlxA==; 5:rjxWcmVCWDQEVtWiUEKcNzWnp+0EJnEWP4bKYe7a5lAuGRy0eMGkYtzSy6SPzV17MNNDbzoZuWKsrjQHgQ1BA6tkLg5tShf1wG5B+0zZEee8FNaK/FJ1N9J6B0smw2FO99+VVeAEyVoOkjuEB14T8+HI5QZ5bv94X5uN3MWT9Ak=; 24:3EcAM22/rGVfzGRd5KDSeku49sXIjXuTRfAoxfGw7mZy0CFkDEGIhJ32SO3JYb8oUyfZBQdiZPOwq0XyTEQZKz4WBkD9QO9uU/uvFAK/7z0=; 7:AtM+yarFJlC7pi1q0hP/vt32MWuWL+fTfir96ubxpTYVObjUJKX2BsIS0q9TjOzLet2ZJxfF9vvMH6PcF5Ejy1B4dclwwA+zlf40zharFE8tVdDXpupjLkgxViHyHATjPbb62D23upDm2IiSavLoeVb0/h0SXVdNylygCuS4AFoTm/wNiK4zWJXOMI1DnIe6aPXck1+AikqIlj3Fk3PDwrwy+z3ESxm2WGf7ZLD0tr4= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 38260601-abb5-48cf-38cd-08d515316460 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(2017052603219)(201703131423075)(201703031133081)(201702281549075); SRVR:HE1PR07MB1531; x-ms-traffictypediagnostic: HE1PR07MB1531: x-exchange-antispam-report-test: UriScan:(37575265505322)(158342451672863)(120809045254105)(192374486261705); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(3002001)(10201501046)(93006095)(93001095)(6041248)(20161123564025)(20161123560025)(20161123558100)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:HE1PR07MB1531; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:HE1PR07MB1531; x-forefront-prvs: 04631F8F77 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(346002)(39860400002)(376002)(377424004)(199003)(189002)(13464003)(53754006)(97736004)(229853002)(33656002)(6506006)(5250100002)(53546010)(53936002)(68736007)(74316002)(2501003)(966005)(2950100002)(305945005)(14454004)(2351001)(230783001)(7736002)(4001150100001)(66066001)(478600001)(6916009)(106356001)(102836003)(6116002)(3846002)(8936002)(101416001)(316002)(81156014)(5660300001)(6436002)(3280700002)(2473003)(54356999)(15650500001)(7696004)(1730700003)(25786009)(3660700001)(86362001)(76176999)(55016002)(2900100001)(5640700003)(189998001)(50986999)(2906002)(6306002)(8676002)(9686003)(81166006)(99286003)(105586002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB1531; H:HE1PR07MB1529.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=francesca.palombini@ericsson.com; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Oct 2017 07:33:42.2839 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB1531 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02SbUhTYRTHeXbvtrvR6GlteDCNHEgl6cpCC8Ts5UNRlvqhfKO85kVNnXLv lOzTQnpBM80Ec5SaWZrDtLVS1hKbffAlVCoJFRF1Gr6kvcxMLc27u6Bvv/M75znwPzwUoVwm PalUnZ5hdXS6RiIny6ObD/rHmSdidi9PBu1f/HmTCEPHamqWRBEoVh6SxKSn5jCsNjRBnmJr N5NZ19SXRrtfSQ2oTZWPZBTgfVA6WSjJR3JKid8iGKp2IqHoQPBrYIzkCxIXEvDS/pwUOmUi aFobIIRiHIHl4QLil0lwCPSNzovzEUWpsA98GqN5vRlHQnOeVSToKGiu1/JahQOh2jLsekli X2gxf5fyrMDxYKhwurwSn4SZZ19dXobDofh3q4hnhL3BecVE8ExgDxh0VIqEOBhqbL2EwGqY Gl8VC7wNpgsMEoG94X1lgSslYKMUbA2t7qEAeHH7CxI4HIqc/FJ+qAKBo+ePe8gPHt+acHMG PLi+6n6QBiWrd9y+WwydSzKBvaBqcUYqLGqUwJDT6o7GQG3DVVSMdhn/S2FcPxKBd0KjVSto HygtGJUaXYfZBJ3lDrIKkfVIzTEcl5EcuDeAYVMvcFymLkDH6M1o/Ue8saz4tyDTzCE7whTS bFCsGSdilGI6h8vNsCOgCI1K8bRkXSmS6NzLDJt5ns1OZzg72kKRGg9FWGtftBIn03omjWGy GPZfV0TJPA1I67M4r08r78o0vT6SeKbX5HeuLtLx7vCjnqDQ+CdsSHcg9SF0eKR/obn/xtxs 8I7Z2un5TeapvKL2s6ccEluU74kh493gH/fFxGhT9tbwhESatlR9bJurM9/r8vqWvPTZf2RQ bqk6fnQ74XSwVgu1EhtBlxy4uLHDVnY6zitQrSG5FHqPH8Fy9F/bJxhIDQMAAA== Archived-At: Subject: [Ace] FW: New Version Notification for draft-seitz-ace-oscoap-profile-05.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Oct 2017 07:33:52 -0000 SGkgYWxsLA0KDQpXZSBoYXZlIHN1Ym1pdHRlZCBhbiB1cGRhdGUgd2l0aCBzaW1wbGlmaWNhdGlv bnMgdG8gdGhlIE9TQ09BUCBwcm9maWxlLg0KDQogQ29tbWVudHMgYXJlIHdlbGNvbWUhDQoNCmh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1zZWl0ei1hY2Utb3Njb2FwLXByb2ZpbGUt MDUgDQoNCkZyYW5jZXNjYQ0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206 IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9y Z10NCj4gU2VudDogZGVuIDE2IG9rdG9iZXIgMjAxNyAxNDoyNQ0KPiBUbzogTHVkd2lnIFNlaXR6 IDxsdWR3aWcuc2VpdHpAcmkuc2U+OyBNYXJ0aW4gR3VubmFyc3Nvbg0KPiA8bWFydGluLmd1bm5h cnNzb25Acmkuc2U+OyBGcmFuY2VzY2EgUGFsb21iaW5pDQo+IDxmcmFuY2VzY2EucGFsb21iaW5p QGVyaWNzc29uLmNvbT4NCj4gU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBk cmFmdC1zZWl0ei1hY2Utb3Njb2FwLXByb2ZpbGUtMDUudHh0DQo+IA0KPiANCj4gQSBuZXcgdmVy c2lvbiBvZiBJLUQsIGRyYWZ0LXNlaXR6LWFjZS1vc2NvYXAtcHJvZmlsZS0wNS50eHQNCj4gaGFz IGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBGcmFuY2VzY2EgUGFsb21iaW5pIGFuZCBw b3N0ZWQgdG8gdGhlDQo+IElFVEYgcmVwb3NpdG9yeS4NCj4gDQo+IE5hbWU6CQlkcmFmdC1zZWl0 ei1hY2Utb3Njb2FwLXByb2ZpbGUNCj4gUmV2aXNpb246CTA1DQo+IFRpdGxlOgkJT1NDT0FQIHBy b2ZpbGUgb2YgdGhlIEF1dGhlbnRpY2F0aW9uIGFuZCBBdXRob3JpemF0aW9uIGZvcg0KPiBDb25z dHJhaW5lZCBFbnZpcm9ubWVudHMgRnJhbWV3b3JrDQo+IERvY3VtZW50IGRhdGU6CTIwMTctMTAt MTUNCj4gR3JvdXA6CQlJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCj4gUGFnZXM6CQkxNg0KPiBVUkw6 ICAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXNl aXR6LWFjZS1vc2NvYXAtDQo+IHByb2ZpbGUtMDUudHh0DQo+IFN0YXR1czogICAgICAgICBodHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1zZWl0ei1hY2Utb3Njb2FwLXByb2Zp bGUvDQo+IEh0bWxpemVkOiAgICAgICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt c2VpdHotYWNlLW9zY29hcC1wcm9maWxlLTA1DQo+IEh0bWxpemVkOiAgICAgICBodHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LXNlaXR6LWFjZS1vc2NvYXAtDQo+IHBy b2ZpbGUtMDUNCj4gRGlmZjogICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/ dXJsMj1kcmFmdC1zZWl0ei1hY2Utb3Njb2FwLXByb2ZpbGUtMDUNCj4gDQo+IEFic3RyYWN0Og0K PiAgICBUaGlzIG1lbW8gc3BlY2lmaWVzIGEgcHJvZmlsZSBmb3IgdGhlIEF1dGhlbnRpY2F0aW9u IGFuZA0KPiAgICBBdXRob3JpemF0aW9uIGZvciBDb25zdHJhaW5lZCBFbnZpcm9ubWVudHMgKEFD RSkgZnJhbWV3b3JrLiAgSXQNCj4gICAgdXRpbGl6ZXMgT2JqZWN0IFNlY3VyaXR5IG9mIENvQVAg KE9TQ09BUCkgdG8gcHJvdmlkZSBjb21tdW5pY2F0aW9uDQo+ICAgIHNlY3VyaXR5LCBzZXJ2ZXIg YXV0aGVudGljYXRpb24sIGFuZCBwcm9vZi1vZi1wb3NzZXNzaW9uIGZvciBhIGtleQ0KPiAgICBv d25lZCBieSB0aGUgY2xpZW50IGFuZCBib3VuZCB0byBhbiBPQXV0aCAyLjAgYWNjZXNzIHRva2Vu Lg0KPiANCj4gDQo+IA0KPiANCj4gUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBs ZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbg0KPiB1bnRpbCB0aGUgaHRt bGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0K PiANCj4gVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0K From nobody Wed Oct 18 23:01:50 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 645D1133052 for ; Wed, 18 Oct 2017 23:01:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.69 X-Spam-Level: X-Spam-Status: No, score=-4.69 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, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001, 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=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 aERALLnMRAdO for ; Wed, 18 Oct 2017 23:01:46 -0700 (PDT) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10043.outbound.protection.outlook.com [40.107.1.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0C14124239 for ; Wed, 18 Oct 2017 23:01:45 -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=TqCfAIhdKv9zQmxOq+L4bQ8WLsv3SCpESBzyhrZmGV8=; b=HYVLNVhaAsHdQo9VAEqKIIsuxFHhCes2/iHphxF8QTRGwzATbWai16clUQsiYHM6YYndECrdWtDDgr7zelLWxTc6Z/WjKjsPpGSKPeUD8mgUAQOhvyWDQgFeBM720vIjkUFCYlTxTkNG8qOJw2v/BMwyOURIWwxXnTC158bUuWU= Received: from AM4PR0801MB2706.eurprd08.prod.outlook.com (10.167.90.148) by AM4PR0801MB2705.eurprd08.prod.outlook.com (10.167.90.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.7; Thu, 19 Oct 2017 06:01:43 +0000 Received: from AM4PR0801MB2706.eurprd08.prod.outlook.com ([fe80::6027:3e1:2bf7:68ed]) by AM4PR0801MB2706.eurprd08.prod.outlook.com ([fe80::6027:3e1:2bf7:68ed%14]) with mapi id 15.20.0077.022; Thu, 19 Oct 2017 06:01:43 +0000 From: Hannes Tschofenig To: "ace@ietf.org" Thread-Topic: multicast Thread-Index: AdNIng8OaAKxM8piQaWt4FllrU9xPQ== Date: Thu, 19 Oct 2017 06:01:43 +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: [92.67.4.57] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM4PR0801MB2705; 6:oBjMQ+k95C292h9K8KEy49vDuwKIbgiyDN/w5GpwNZn13PzoWfNDx2kDcUwEb1FvJGWwSHijK6+poCnXivi5qAznP0qSqXRcnn3Oye1bTmY/DPBdO5qQOERE3gY3gyYydQ1Txbn7sB3XeVrAMCwDqtH0EpKeBtB3M0x77ZOMgZs4i9hpmuYEsBuxqAzpHv4Jd99wxniLcclK33dirGFi1V6iaDOMZGD9zCDCqMq1CjvQraSsS8konVmC8JP7F+eFppCBGxH0cWUz48MbK86psDSQJZ65yCrokVIR0SF1lNxOb6tqIcyizwrJJUnnOFcpjQY8QqYfnJtGzkCrSQY1VQ==; 5:ReAMy4rz0xji2/vbMHdu1rdeW/MEdRtkGEg+nTxOyQnm+BR/Mo7QES9qTohMnau958td7DladSsnooiQ7hH7dSoJ2SO8aF2bLEGbC6+UbV7taWSjmCfnzOSQleusF8nVedOKeXt/0OtlLoJqcVazcw==; 24:tTZ+6HE5e1pcUiKgnB3uac6vc3G2pKV/KnaSVNaZsnxoAh0s8cS7bDuDD69KZOloMbmlM494CpK4QBxOG1t96Ra8pJKwrM1ewFHYkE4DMpA=; 7:zBQbJ1/juGqNsBq6gc+Z4fYPJqZq/UoCz3F3TIn/QQ1QNLIuUX252YOuCX5qDxuGfp5+mZkdPxhWpxx7oV4AJstnZGyY6h05ZsAxKRZ33gwHj5obfEVdWiCEBTWEynOA9BH6rg15HNopEYprvOViu1PzY9ilLCRA0iS/ApAF4A7R3CIXHXjwaKiMzCvbrTVp7UQXDOD46BNswIWtFXcFdP61lVgFFdqAGlYJFVYfp6w= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 4e86a017-99f3-45cd-71d1-08d516b6df6e x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(48565401081)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:AM4PR0801MB2705; x-ms-traffictypediagnostic: AM4PR0801MB2705: x-exchange-antispam-report-test: UriScan:(21748063052155); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(3002001)(6055026)(6041248)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123560025)(20161123555025)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM4PR0801MB2705; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM4PR0801MB2705; x-forefront-prvs: 0465429B7F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(346002)(376002)(40434004)(53754006)(189002)(199003)(3846002)(102836003)(316002)(6506006)(790700001)(5640700003)(6916009)(8936002)(3480700004)(6116002)(33656002)(105586002)(1730700003)(189998001)(81166006)(106356001)(81156014)(9686003)(8676002)(6436002)(2351001)(53936002)(99286003)(3660700001)(25786009)(86362001)(14454004)(2900100001)(3280700002)(606006)(2906002)(97736004)(72206003)(7736002)(2501003)(221733001)(7696004)(66066001)(5630700001)(54896002)(54356999)(101416001)(5890100001)(5250100002)(6306002)(74316002)(478600001)(7116003)(50986999)(55016002)(5660300001)(236005)(68736007)(166393002)(220243001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR0801MB2705; H:AM4PR0801MB2706.eurprd08.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AM4PR0801MB2706A17C5668DA0B2B1D9834FA420AM4PR0801MB2706_" MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Oct 2017 06:01:43.0428 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR0801MB2705 Archived-At: Subject: [Ace] multicast 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, 19 Oct 2017 06:01:48 -0000 --_000_AM4PR0801MB2706A17C5668DA0B2B1D9834FA420AM4PR0801MB2706_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, During the ACE conference call we had a few new participants, namely Stevie= , Piotr and Marius, from the lighting consortium Fairhair attending. Great = to see new participants "on-board". Stevie explained that he needs a document that contains a solution using as= ymmetric and symmetric cryptography, that they intend to use the asymmetric= solution whenever there is no low latency requirement (and for unicast com= munication), and only use the symmetric key approach when the low latency r= equirements demand it. Is this a correct summary? Ciao Hannes PS: Stevie also mentioned that he likes draft-tiloca-ace-oscoap-joining-00.= txt but not draft-somaraju-ace-multicast. This was rather surprising since draft-somaraju-ac= e-multicastwas wr= itten by the lighting community (in the OpenAIS project) specifically addre= ssing the low latency requirements of that community. Stevie, could you exp= lain? 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_AM4PR0801MB2706A17C5668DA0B2B1D9834FA420AM4PR0801MB2706_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

During the ACE conference call we had a few new part= icipants, namely Stevie, Piotr and Marius, from the lighting consortium Fai= rhair attending. Great to see new participants “on-board”.

 

Stevie explained that he needs a document that conta= ins a solution using asymmetric and symmetric cryptography, that they inten= d to use the asymmetric solution whenever there is no low latency requireme= nt (and for unicast communication), and only use the symmetric key approach when the low latency requirements = demand it.

 

Is this a correct summary?

 

Ciao

Hannes

 

PS: Stevie also mentioned that he likes draft-tiloca= -ace-oscoap-joining-00.txt but not draft-somaraju-ace-multicas= t. This was rather surprising since draft-somaraju-ace-multicas= twas written by the lighting community (in the OpenAIS project) = specifically addressing the low latency requirements of that community. Stevie, could you explain?

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_AM4PR0801MB2706A17C5668DA0B2B1D9834FA420AM4PR0801MB2706_-- From nobody Wed Oct 18 23:52:28 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07D23120724 for ; Wed, 18 Oct 2017 23:52:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=alibaba-inc.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gLicnnMEyndY for ; Wed, 18 Oct 2017 23:52:24 -0700 (PDT) Received: from out0-212.mail.aliyun.com (out0-212.mail.aliyun.com [140.205.0.212]) (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 344F3126DD9 for ; Wed, 18 Oct 2017 23:52:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1508395941; h=Date:Subject:From:To:Message-ID:Mime-version:Content-type; bh=nYcLvfutoc+HsegjcUgO02zulXzmHLNTcNxqQyWSnRE=; b=Tf9kEMmvdi+XSGKzjqJqg4mQCOl1o5BZGxZxDHXLnihVqDI9Nw0zn9ZOjP2kf/UuL3izlL9CczlEGXDmD+U8T7NSvhRxxi2tQXb+LmpB7hX6w51LKp9AZv8zQEH8+8AcVrv7VMV6BkO+bPlAKy7tCHq/ol2EqOIS8P9BafBNLyU= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R131e4; FP=0|-1|-1|-1|0|-1|-1|-1; HT=e02c03291; MF=kepeng.lkp@alibaba-inc.com; NM=1; PH=DS; RN=3; SR=0; TI=SMTPD_---.9B-DwgU_1508395932; Received: from 30.39.34.62(mailfrom:kepeng.lkp@alibaba-inc.com ip:121.0.29.165) by smtp.aliyun-inc.com(127.0.0.1); Thu, 19 Oct 2017 14:52:16 +0800 User-Agent: Microsoft-MacOutlook/14.6.8.160830 Date: Thu, 19 Oct 2017 14:52:13 +0800 From: "Kepeng Li" To: ace CC: Kathleen Moriarty , Hannes Tschofenig Message-ID: Thread-Topic: [Ace] Minutes of ACE virtual interim meeting on 18th Oct about ACE roadmap Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3591269538_6738284" Archived-At: Subject: [Ace] Minutes of ACE virtual interim meeting on 18th Oct about ACE roadmap 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, 19 Oct 2017 06:52:27 -0000 > ´ËÓʼþʹÓà MIME ¸ñʽ¡£ÓÉÓÚÓʼþÔĶÁ³ÌÐò²»ÄÜʶ±ð ´Ë¸ñʽ£¬Òò´Ë£¬¿ÉÄÜÎÞ·¨Ê¶±ð¸ÃÓʼþµÄ·Ö²¿»ò²¿·ÖÄÚÈÝ¡£ --B_3591269538_6738284 Content-type: text/plain; charset="GB2312" Content-transfer-encoding: quoted-printable Hello all, Please find the initial minutes from the link below: https://datatracker.ietf.org/meeting/interim-2017-ace-02/materials/minutes-= i nterim-2017-ace-02-201710181300/ Please take a look and let me know if you have any corrections. Thanks, Kind Regards Kepeng =B7=A2=BC=FE=C8=CB: Ace on behalf of Li Kepeng =C8=D5=C6=DA: Wednesday, 4 October 2017 at 11:06 PM =D6=C1: ace =B3=AD=CB=CD: Kathleen Moriarty , Hannes Tschofenig =D6=F7=CC=E2: [Ace] ACE virtual interim meeting on 18th Oct to discuss ACE roadmap Hello all, Please find the attached WebEx meeting information, and save it to your calendar. It can be also found below: Time: 18th Oct, GMT 13:00 ~ 14:00. Agenda item: ACE roadmap, the output from the Wiki activity. Link: https://trac.ietf.org/trac/ace/wiki/WikiStart =20 JOIN WEBEX MEETING https://ietf.webex.com/ietf/j.php?MTID=3Dm81fae81e933f9aaedf62bdadf1e6f441 Meeting number (access code): 313 154 691 Host key: 710338 Meeting password: 22JqEbFK JOIN BY PHONE 1-877-668-4493 Call-in toll free number (US/Canada) 1-650-479-3208 Call-in toll number (US/Canada) Toll-free dialing restrictions: https://www.webex.com/pdf/tollfree_restrictions.pdf 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 othe= r 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. Kind Regards Kepeng & Hannes _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace --B_3591269538_6738284 Content-type: text/html; charset="GB2312" Content-transfer-encoding: quoted-printable
Hello all,

<= div>Please find the initial minutes from the link below:
=

Please take a look and let me know if you have any corre= ctions.

Thanks,
Kind Regards
Ke= peng

=B7=A2=BC=FE=C8=CB: Ace <= ;ace-bounces@ietf.org> on behal= f of Li Kepeng <kepeng.lkp@al= ibaba-inc.com>
=C8=D5=C6=DA: Wednes= day, 4 October 2017 at 11:06 PM
=D6=C1: ace <ace@ietf.org>
=B3=AD=CB=CD: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>, Hanne= s Tschofenig <hannes.tschofeni= g@gmx.net>
=D6=F7=CC=E2: [Ace] ACE = virtual interim meeting on 18th Oct to discuss ACE roadmap
Hello a= ll,

Please find the attached WebEx meeting information,= and save it to your calendar.

It can be also found below:

Time: 18th Oct, GMT 1= 3:00 ~ 14:00.
Agenda item: ACE= roadmap, the output from the Wiki activity.
 
JOIN WEBEX MEETING
Meeting number (a= ccess code): 313 154 691
Host = key: 710338
Meeting password: = 22JqEbFK

JOIN BY PHONE
1-877-668-4493 Call-in toll free number (US/Canada) 
1-650-479-3208 Call-in toll number= (US/Canada)

Toll-free dialing restrictions: 

Can't join the meeting? Contact support here:

IMPORTANT = NOTICE: Please note that this WebEx service allows audio and other informati= on sent during the session to be recorded, which may be discoverable in a le= gal matter. You should inform all meeting attendees prior to recording if yo= u intend to record the meeting.

Kind Regards
Kepeng & Hannes<= /div>

_______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/ma= ilman/listinfo/ace --B_3591269538_6738284-- From nobody Thu Oct 19 01:23:57 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D31C91346B1 for ; Thu, 19 Oct 2017 01:23:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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=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 u7rJ18pGXaTi for ; Thu, 19 Oct 2017 01:23:54 -0700 (PDT) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9D0713467F for ; Thu, 19 Oct 2017 01:23:53 -0700 (PDT) Received: by mail-qk0-x234.google.com with SMTP id 17so9378003qkq.8 for ; Thu, 19 Oct 2017 01:23:53 -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=bNhDnZdz4HuGQZ0r4ZiNUGgYwvceKTfAPnrCvaG3Jk8=; b=XUJcDAApChwzcc7jF5nJcEcDz9niQKo5VDZ5IgPKfpbYMkfDWFWOPuIO2ez7W03+E9 uJw2XDBFzP187xByirt76YMmhj0yfi4Jl20L7/VBE8/35ige7XsYIk++/pENNDwYzxUx t0+tDNBzRjYv8cTWO79RvZWf0VYqdZ/PiG4ayGFgoVgMYwV5HQnwMZ0XAoXUnP4qVhv2 CqNznzD4vkExwEOpcocNUM+VAjRqaTSZV0yshmYi/Fzmk7KWe2o4f4UVvGcIwYWWQTBG G29mm5S2Z4o3IgvLfClg3dMeTPDCLkC/VBPRl3km8crf7KdTxLjPDAr7IjYUPRkqfRPz Osog== 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=bNhDnZdz4HuGQZ0r4ZiNUGgYwvceKTfAPnrCvaG3Jk8=; b=brtn6zXh0O9Xdjt21IVfr3TlJBts+broRIMoTav7NdL28/T1rhnJ0tQE03SDTCZBkY JvwzPeu/cB3kqNsGIIdHvZ6jRnNpkRtk+Gy2D2ZPutsuLu81zMhsnjT74RwWVakz4WVo Ok/49mX5IGktX3UYOUx8amPI0mgIuYNTRe07mryTMe8tmbEsPZkM0bbP2DQH4NQnxDbj F/N9SaIhRZQ7WN7jIW5esoQEUyy3TUGcwSufJpWmKooX8mCEYYsU8TpmJL00uO52W31a aL68O+AbyCRYXVI58JKZxCG25hRK471LK9kl4Kk8jjMVXQjxFfNU3ZqiI2q221VVSY8z 1MSw== X-Gm-Message-State: AMCzsaVQaG+dyscXJMr+f4uKyvjAQLTPsGlIaAeTFj471UAmLUry4k27 t2uMkrJFeqsqBkxINNv4uvzovezcnXS2Vgs18/k= X-Google-Smtp-Source: ABhQp+QdlAEpNZJCM2jAUEqTw74HQVO229aR/qicpgmkXBHGEQzo0wJjjoKavPhK8OTppLYavTFzRN2e1ZdB8HEGktU= X-Received: by 10.55.133.65 with SMTP id h62mr929635qkd.130.1508401432861; Thu, 19 Oct 2017 01:23:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.4.148 with HTTP; Thu, 19 Oct 2017 01:23:32 -0700 (PDT) In-Reply-To: References: From: Renzo Navas Date: Thu, 19 Oct 2017 10:23:32 +0200 Message-ID: To: Kepeng Li Cc: ace , Kathleen Moriarty , Hannes Tschofenig Content-Type: multipart/alternative; boundary="94eb2c07d42495a641055be21313" Archived-At: Subject: Re: [Ace] Minutes of ACE virtual interim meeting on 18th Oct about ACE roadmap 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, 19 Oct 2017 08:23:56 -0000 --94eb2c07d42495a641055be21313 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Kepeng, all thank you for the resum=C3=A9. I don't see my votes recorder, (neither Ludwig's); I strongly support OSCOAP; then pub/sub and Multicast OSCOAP. In any case, I agree with the conclusions 1 , 2. I don't know if the consensus was that MQTT is mid priority (and pub/sub relegated to low), just that mqtt is rather new draft and we should discuss it more. Regards! Renzo On Thu, Oct 19, 2017 at 8:52 AM, Kepeng Li wrote: > Hello all, > > Please find the initial minutes from the link below: > https://datatracker.ietf.org/meeting/interim-2017-ace-02/ > materials/minutes-interim-2017-ace-02-201710181300/ > > Please take a look and let me know if you have any corrections. > > Thanks, > Kind Regards > Kepeng > > =E5=8F=91=E4=BB=B6=E4=BA=BA: Ace on behalf of Li K= epeng < > kepeng.lkp@alibaba-inc.com> > =E6=97=A5=E6=9C=9F: Wednesday, 4 October 2017 at 11:06 PM > =E8=87=B3: ace > =E6=8A=84=E9=80=81: Kathleen Moriarty ,= Hannes > Tschofenig > =E4=B8=BB=E9=A2=98: [Ace] ACE virtual interim meeting on 18th Oct to disc= uss ACE roadmap > > Hello all, > > Please find the attached WebEx meeting information, and save it to your > calendar. > > It can be also found below: > > Time: 18th Oct, GMT 13:00 ~ 14:00. > Agenda item: ACE roadmap, the output from the Wiki activity. > Link: https://trac.ietf.org/trac/ace/wiki/WikiStart > > JOIN WEBEX MEETING > https://ietf.webex.com/ietf/j.php?MTID=3Dm81fae81e933f9aaedf62bdadf1e6f44= 1 > Meeting number (access code): 313 154 691 > Host key: 710338 > Meeting password: 22JqEbFK > > JOIN BY PHONE > 1-877-668-4493 Call-in toll free number (US/Canada) > 1-650-479-3208 Call-in toll number (US/Canada) > > Toll-free dialing restrictions: > https://www.webex.com/pdf/tollfree_restrictions.pdf > > 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. > > Kind Regards > Kepeng & Hannes > > _______________________________________________ Ace mailing list > Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > > --94eb2c07d42495a641055be21313 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Kepeng, all

thank you for the resum= =C3=A9.
I don't see my votes recorder, (neither Ludwig's);
<= /div>

I strongly support=C2=A0OSCOAP; then pub/sub and M= ulticast OSCOAP.

In any case, I agree with the=C2= =A0 conclusions 1 , 2.


I don&= #39;t know if the consensus was that MQTT is mid priority (and pub/sub rele= gated to low), just that mqtt is rather new draft and we should discuss it = more.

Regards!

Renzo

On Thu, Oc= t 19, 2017 at 8:52 AM, Kepeng Li <kepeng.lkp@alibaba-inc.com&= gt; wrote:
Hello all,

Please find the initia= l minutes from the link below:

Please take a look and let me know if you = have any corrections.

Thanks,
Kind Regar= ds
Kepeng

=E5=8F=91=E4=BB=B6=E4=BA=BA: Ace <ace-bounces@ietf.org> on behalf of = Li Kepeng <kepeng.lkp@alibaba-inc.com>
= =E6=97=A5=E6=9C=9F: Wednesday, 4 October 2017 at 11:06 PM
=E8=87=B3: ace <ace@ietf.org>
=E6=8A=84=E9=80=81: Kathleen Moriarty <kathleen.moriarty.i= etf@gmail.com>, Hannes Tschofenig <hannes.tschofenig@gmx.net>
= =E4=B8=BB=E9=A2=98: [Ace] ACE virt= ual interim meeting on 18th Oct to discuss ACE roadmap

Hello all,

=
Please find the attached WebEx meeting info= rmation, and save it to your calendar.

It can be also found below:

Time: 18t= h Oct, GMT 13:00 ~ 14:00.
Agen= da item: ACE roadmap,=C2=A0the output from the Wiki activity.=
=C2=A0
JOIN WEBEX MEETING<= /font>
Meeting num= ber (access code): 313 154 691
Host key: 710338
Meeting pass= word: 22JqEbFK

JOIN BY PHONE
1-877-668-4493 Call-in toll free number (US/Canada)=C2= =A0
1-650-479-3208 Call-in tol= l number (US/Canada)

Toll-free dialing restrictions:= =C2=A0

Can't= join the meeting? Contact support here:

= IMPORTANT NOTICE: Ple= ase note that this WebEx service allows audio and other information sent du= ring the session to be recorded, which may be discoverable in a legal matte= r. You should inform all meeting attendees prior to recording if you intend= to record the meeting.
=
Kind Regards
Kepeng & Hannes

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

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


--94eb2c07d42495a641055be21313-- From nobody Thu Oct 19 01:27:22 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B4561346F0 for ; Thu, 19 Oct 2017 01:27:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.91 X-Spam-Level: X-Spam-Status: No, score=-2.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, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DlTLeKF3xAPk for ; Thu, 19 Oct 2017 01:27:19 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0065.outbound.protection.outlook.com [104.47.2.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8E4B1346B8 for ; Thu, 19 Oct 2017 01:27:17 -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=aoG1lN5qDD3UptunimPX8VV3XrO+7Tmo/zu2MianM8k=; b=FK4bc+E3GR3RlE+F6LgSfQMKdLdr2yApPM6JKqv3HI6SflZTo41rhNdbI4S3yqgY6F4DjniFJ3qVoCGyW+Kd/Ocon15ogjk9FKLQBpHvUf42VBvxQb9cjIOnsrwZMJ7dJLtO9NIGMdWjCOK/xQev6M7wR9HC16W76MYOJ8FnfwY= Received: from AM4PR0801MB2706.eurprd08.prod.outlook.com (10.167.90.148) by AM4PR0801MB2708.eurprd08.prod.outlook.com (10.167.90.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.7; Thu, 19 Oct 2017 08:27:15 +0000 Received: from AM4PR0801MB2706.eurprd08.prod.outlook.com ([fe80::6027:3e1:2bf7:68ed]) by AM4PR0801MB2706.eurprd08.prod.outlook.com ([fe80::6027:3e1:2bf7:68ed%14]) with mapi id 15.20.0077.022; Thu, 19 Oct 2017 08:27:15 +0000 From: Hannes Tschofenig To: Renzo Navas , Kepeng Li CC: Kathleen Moriarty , Hannes Tschofenig , ace Thread-Topic: [Ace] Minutes of ACE virtual interim meeting on 18th Oct about ACE roadmap Thread-Index: AQHTSKbW/XMYZenAakmJxsBC3txI06Lq1csAgAAAcuA= Date: Thu, 19 Oct 2017 08:27:15 +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: [91.205.194.85] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM4PR0801MB2708; 6:ahioKFOFhT9ZI9aOf2AVe+D9kNwDPDEUo7/qFyOwRKNhpC0gdOf90WWxDQ9zHyYFOEpGX6nMfqirImvC8+b3njpIKKHSzhuRNVE1Zi4yz5cDsa/Eh7YFBkuSW8frdWbGrtUKF8ABRPrvmM0lSYzG3bmzzFUKNETtD1p5PlgSe9iEwTjO16GZiN1b11bky3rI5Dag1oBTISVdxtve/qGmQmLFHJMBzr35c9zf3dLoZoYNzUm1PcSg3yRkXROR+jmvgKGMETowEaYi9yMgDBDaKxRKuC6aINpZf4cKVz28dXgrpEVxoIrR/fe36wEeq47LHQpHLbQs/bp5+2MF5dgIuw==; 5:MhYcNQ9NpDz+CxmB+CrfhVW03J3nxPOqjDsLWB7URogasprPMMZkBTt7JBLWpjb/boMobh9G/vBOVvH9SO+CcYFKmBrnlk0XKYZsrkCFDKvHv0MatOLcF3cYEJYLYWDUMAm1iKjReM4KHuqQ6czTow==; 24:8HQ2jpP8rLF79r6p1mJzVFfQmhOF2dclrFoMORypfCyLQLdYuirlLsm+S34t3PCBilZICbkvAjj99zzfbzBFgF49HztrGzkXrVqu3ajvcEQ=; 7:1jyKLffMBsqdojwtNwIlpf69jNGU37EX/fyp2I8LDCLVK33hvJeJKRjvwRzDhM2LfyHIlXiAlnCJSty6TH5DSEzzhLPd5CsG/06e3GUnFXsitGE9lZ5toAutEnipP6MuoFJ1gHagvEbFwzYwLiS7A/cfPM4N8t7HLcV8yHpoGqTt1jj8rQxn7165+oT/YQ8mFJ9k0d6LNu37SHdmTw3g6gP4YHQdKB63XxXm9LJsay4= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: dcf90821-ba6a-4337-0317-08d516cb342d x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(48565401081)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:AM4PR0801MB2708; x-ms-traffictypediagnostic: AM4PR0801MB2708: x-exchange-antispam-report-test: UriScan:(100405760836317)(21748063052155); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(100000703101)(100105400095)(10201501046)(3002001)(93006095)(93001095)(6055026)(6041248)(20161123560025)(20161123564025)(20161123562025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM4PR0801MB2708; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM4PR0801MB2708; x-forefront-prvs: 0465429B7F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(346002)(39860400002)(376002)(189002)(40434004)(199003)(790700001)(3846002)(55016002)(5890100001)(5660300001)(54896002)(478600001)(72206003)(6306002)(9686003)(189998001)(101416001)(86362001)(53936002)(54356999)(7696004)(6116002)(102836003)(66066001)(76176999)(50986999)(25786009)(99286003)(2950100002)(14454004)(4326008)(110136005)(8936002)(2900100001)(2906002)(6246003)(3660700001)(39060400002)(33656002)(3280700002)(8676002)(316002)(97736004)(6506006)(81156014)(5250100002)(229853002)(81166006)(74316002)(7736002)(6436002)(54906003)(106356001)(68736007)(105586002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR0801MB2708; H:AM4PR0801MB2706.eurprd08.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AM4PR0801MB2706DE73A7CB4F9C67FAA671FA420AM4PR0801MB2706_" MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Oct 2017 08:27:15.1549 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR0801MB2708 Archived-At: Subject: Re: [Ace] Minutes of ACE virtual interim meeting on 18th Oct about ACE roadmap 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, 19 Oct 2017 08:27:21 -0000 --_000_AM4PR0801MB2706DE73A7CB4F9C67FAA671FA420AM4PR0801MB2706_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 w5ggIEkgZG9uJ3Qgc2VlIG15IHZvdGVzIHJlY29yZGVyLCAobmVpdGhlciBMdWR3aWcncyk7DQoN CldlIGNvcGllZCB3aGF0IHdhcyBpbiB0aGUgY2hhdCBXaW5kb3cNCg0KDQoNCsOYICBJIGRvbid0 IGtub3cgaWYgdGhlIGNvbnNlbnN1cyB3YXMgdGhhdCBNUVRUIGlzIG1pZCBwcmlvcml0eSAoYW5k IHB1Yi9zdWIgcmVsZWdhdGVkIHRvIGxvdyksIGp1c3QgdGhhdCBtcXR0IGlzIHJhdGhlciBuZXcg ZHJhZnQgYW5kIHdlIHNob3VsZCBkaXNjdXNzIGl0IG1vcmUuDQoNCkkgcHJlZmVyIHRvIHNheSB0 aGF0IHRoZXJlIGFyZSBoaWdoIHByaW9yaXR5IGl0ZW1zIGFuZCB0aGVuIHRoZXJlIGlzIHRoZSBy ZXN0LCB3aGljaCByZXF1aXJlcyBmdXJ0aGVyIHRob3VnaHRzLg0KDQpDaWFvDQpIYW5uZXMNCklN UE9SVEFOVCBOT1RJQ0U6IFRoZSBjb250ZW50cyBvZiB0aGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNo bWVudHMgYXJlIGNvbmZpZGVudGlhbCBhbmQgbWF5IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYgeW91 IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVy IGltbWVkaWF0ZWx5IGFuZCBkbyBub3QgZGlzY2xvc2UgdGhlIGNvbnRlbnRzIHRvIGFueSBvdGhl ciBwZXJzb24sIHVzZSBpdCBmb3IgYW55IHB1cnBvc2UsIG9yIHN0b3JlIG9yIGNvcHkgdGhlIGlu Zm9ybWF0aW9uIGluIGFueSBtZWRpdW0uIFRoYW5rIHlvdS4NCg== --_000_AM4PR0801MB2706DE73A7CB4F9C67FAA671FA420AM4PR0801MB2706_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o dG1sNDAiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9 InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRl bnQ9Ik1pY3Jvc29mdCBXb3JkIDE0IChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQov KiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OldpbmdkaW5n czsNCglwYW5vc2UtMTo1IDAgMCAwIDAgMCAwIDAgMCAwO30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEg NiA0IDMgNSA0IDQgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwg bGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRv bTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBS b21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0K YTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1z b0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1hcmdpbjow Y207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZh bWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29M aXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6 MzQ7DQoJbWFyZ2luLXRvcDowY207DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltYXJnaW4tYm90dG9t OjBjbTsNCgltYXJnaW4tbGVmdDozNi4wcHQ7DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZv bnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9 DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENo YXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBU ZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7DQoJbXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6RU4tR0I7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVy c29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xv cjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJbXNvLWZhcmVhc3QtbGFu Z3VhZ2U6RU4tVVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0 Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9u MQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBs MA0KCXttc28tbGlzdC1pZDoxMTYxNzAyOTk1Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1z by1saXN0LXRlbXBsYXRlLWlkczotMTkyMzQ3NDY0NiAtNzU4NzQ0OTk4IDEzNDgwNzU1NSAxMzQ4 MDc1NTcgMTM0ODA3NTUzIDEzNDgwNzU1NSAxMzQ4MDc1NTcgMTM0ODA3NTUzIDEzNDgwNzU1NSAx MzQ4MDc1NTc7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1zdGFydC1hdDo5Ow0KCW1z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvg5g7DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250 LWZhbWlseTpXaW5nZGluZ3M7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBS b21hbiI7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6VGFob21hOw0KCWNvbG9yOiMxRjQ5N0Q7DQoJ bXNvLWFuc2ktZm9udC13ZWlnaHQ6Ym9sZDt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZl bDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C pzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0K QGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6 U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250 LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6 bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5l dyI7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1m YW1pbHk6V2luZ2RpbmdzO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGNtO30NCnVsDQoJe21hcmdp bi1ib3R0b206MGNtO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz aGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5k aWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRp dCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48 L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLUdCIiBsaW5rPSJibHVl IiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8ZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50 Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OldpbmdkaW5ncztjb2xvcjoj MUY0OTdEIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7DmDxzcGFuIHN0eWxlPSJmb250 OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7DQo8L3NwYW4+PC9zcGFu Pjwvc3Bhbj48IVtlbmRpZl0+SSBkb24ndCBzZWUgbXkgdm90ZXMgcmVjb3JkZXIsIChuZWl0aGVy IEx1ZHdpZydzKTs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+V2UgY29waWVkIHdoYXQgd2FzIGluIHRoZSBjaGF0IFdpbmRvdzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxl PSJ0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwwIGxldmVsMSBsZm8xIj48IVtpZiAhc3Vw cG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpXaW5n ZGluZ3M7Y29sb3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+w5g8c3Bh biBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOw0K PC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPkkgZG9uJ3Qga25vdyBpZiB0aGUgY29uc2Vu c3VzIHdhcyB0aGF0IE1RVFQgaXMgbWlkIHByaW9yaXR5IChhbmQgcHViL3N1YiByZWxlZ2F0ZWQg dG8gbG93KSwganVzdCB0aGF0IG1xdHQgaXMgcmF0aGVyIG5ldyBkcmFmdCBhbmQgd2Ugc2hvdWxk IGRpc2N1c3MgaXQgbW9yZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIHByZWZlciB0byBz YXkgdGhhdCB0aGVyZSBhcmUgaGlnaCBwcmlvcml0eSBpdGVtcyBhbmQgdGhlbiB0aGVyZSBpcyB0 aGUgcmVzdCwgd2hpY2ggcmVxdWlyZXMgZnVydGhlciB0aG91Z2h0cy4NCjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Q2lh bzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IYW5uZXM8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KSU1QT1JUQU5UIE5PVElDRTogVGhlIGNvbnRlbnRzIG9mIHRo aXMgZW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBhcmUgY29uZmlkZW50aWFsIGFuZCBtYXkgYWxz byBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBw bGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIGRvIG5vdCBkaXNjbG9zZSB0 aGUgY29udGVudHMgdG8gYW55IG90aGVyIHBlcnNvbiwgdXNlIGl0IGZvciBhbnkgcHVycG9zZSwN CiBvciBzdG9yZSBvciBjb3B5IHRoZSBpbmZvcm1hdGlvbiBpbiBhbnkgbWVkaXVtLiBUaGFuayB5 b3UuDQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_AM4PR0801MB2706DE73A7CB4F9C67FAA671FA420AM4PR0801MB2706_-- From nobody Thu Oct 19 01:34:06 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88E8E13473E for ; Thu, 19 Oct 2017 01:34:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hY058_hbeQTt for ; Thu, 19 Oct 2017 01:34:04 -0700 (PDT) Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::22e]) (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 22E20134732 for ; Thu, 19 Oct 2017 01:34:04 -0700 (PDT) Received: by mail-qt0-x22e.google.com with SMTP id 31so13469585qtz.9 for ; Thu, 19 Oct 2017 01:34:04 -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=2s+EjLUYRj/DK+r5kZAj7/hAgs7l2+1i8jO//FNSoxk=; b=JRT4xrNQQbqCUA63T1LOV2qkCwPeSJh3L9eFBEEBMrHmegZGad+rQfcsRS7Iy8dSMo 6Oq31hJtX2jXgJv2iLl1z/+rNytBrbKvRCEV6XOmL9nXdES6aIfqDNJ56Wrpqva1CgLg nJmHYoaSalJ4NBpJg5cqU0m/jbVYertdK9AZCQ3b2WaEFY4o3Tz9AR0aUoyM2f1Vk5TF 2pPk701Mo/EgPCix+kYUmeztrMJ7lU79xCY1j8o3vVWbPeRWvwyQtwm78hkdYu3yD9aI OvQtB/DZvukBULxP5fIk+IZx8tJ018lL8EyVfykCTIfM5vb15cUHb7A8aEJFNMkmfm1Q 7CUg== 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=2s+EjLUYRj/DK+r5kZAj7/hAgs7l2+1i8jO//FNSoxk=; b=VDe6uJlYfjZyJ65gvtd0ntIgBf4jY+ZLBrMk1rJ7UeyM91MaMvJepmdGbG2R5xp0iL VIw/V3rqKyaX/Lf6EoSA9PewValGG/usWguaIQLQuPwZy/LtSkgtvZEvfK/caiaJb2i0 1dFkOKC/iyORjMQ2L2J+ir1/MWz1dax9+edg+DjL8i6XmLIuGXL/orPBY+2mdIBUd0cL NTJWDUy6h0k6mFzbtp+79Ehb+fzvDXeqGBfqDx2fAPZMOsvJg8jwea0iMns486EcpVIM tvzBDY4/Wwlalp7XkL8il4bnUFz0cZAfEpcQ0P0sgQbmzLw1j4nQejBNQamTA131CfYE sofQ== X-Gm-Message-State: AMCzsaX/4ea2rkrMglNWT2lxzwkwr2L0RAsZVt8Brrot7/Fjm+crM4ia 9YtRaR1rkqOcdvDvVGnFfODRSV5Iec1hoEOZrgo= X-Google-Smtp-Source: ABhQp+STF1VnuhwN6M450Tfnp8hB0Isk19hTMnBkmAVohB2Ukxi1b0nksjGZwq2E76RWPXel3R+3jIFKXq1+90naZog= X-Received: by 10.200.3.205 with SMTP id z13mr1070661qtg.25.1508402043302; Thu, 19 Oct 2017 01:34:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.4.148 with HTTP; Thu, 19 Oct 2017 01:33:42 -0700 (PDT) In-Reply-To: References: From: Renzo Navas Date: Thu, 19 Oct 2017 10:33:42 +0200 Message-ID: To: Hannes Tschofenig Cc: Kepeng Li , Kathleen Moriarty , Hannes Tschofenig , ace Content-Type: multipart/alternative; boundary="f4030435b594f838f8055be23730" Archived-At: Subject: Re: [Ace] Minutes of ACE virtual interim meeting on 18th Oct about ACE roadmap 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, 19 Oct 2017 08:34:05 -0000 --f4030435b594f838f8055be23730 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Oct 19, 2017 at 10:27 AM, Hannes Tschofenig < Hannes.Tschofenig@arm.com> wrote: > =C3=98 I don't see my votes recorder, (neither Ludwig's); > > > > We copied what was in the chat Window > > > Ok then probably was a comparibilitty issue? I was on Linux HTML version of Webex, and Ludwig too -by his comments-. I sent my chat/votes (I could see them) , and I could also see (If I recall properly... now Im in doubt) Ludwig's voties too. In any case the conclusions reflect the consensus anyway. > > =C3=98 I don't know if the consensus was that MQTT is mid priority (and > pub/sub relegated to low), just that mqtt is rather new draft and we shou= ld > discuss it more. > > > > I prefer to say that there are high priority items and then there is the > rest, which requires further thoughts. > I agree! Saludos, Renzo --f4030435b594f838f8055be23730 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

= On Thu, Oct 19, 2017 at 10:27 AM, Hannes Tschofenig <<= a href=3D"mailto:Hannes.Tschofenig@arm.com" target=3D"_blank">Hannes.Tschof= enig@arm.com> wrote:

= =C3=98=C2=A0 I don't see my votes recorder, (neither Lud= wig's);

=C2=A0

We copied what was in the= chat Window

=C2=A0

<= /div>

Ok then proba= bly was a comparibilitty issue? I was on Linux HTML version of=C2=A0 Webex,= and Ludwig too -by his comments-. I sent my chat/votes (I could see them) = , and I could also see (If I recall properly... now Im in doubt) Ludwig'= ;s voties too.
In any case the conclusions reflect the consensus = anyway.
=C2=A0

=C2=A0

= =C3=98=C2=A0 I don't know if the consensus was that MQTT= is mid priority (and pub/sub relegated to low), just that mqtt is rather n= ew draft and we should discuss it more.

=C2=A0

I prefer to say that ther= e are high priority items and then there is the rest, which requires furthe= r thoughts.


I agree!
=C2=A0

Saludos,

Renzo

--f4030435b594f838f8055be23730-- From nobody Thu Oct 19 03:56:25 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A483713321C for ; Thu, 19 Oct 2017 03:56:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=osram.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 aMHQCnbuIkng for ; Thu, 19 Oct 2017 03:56:19 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0089.outbound.protection.outlook.com [104.47.2.89]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C45B133221 for ; Thu, 19 Oct 2017 03:56:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Osram.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=bQA89W4iauMTiyLqqU518rMeM5mT9Ut7LwghU1BZQl0=; b=CZDzpC0TONbMJXB4tg8+zwVJ9w25FKqaRCWsNEpbJ7IMxcQP6JVSxP8g88pBwpsGx4md1M0rbnpAbbuvme/XiD4PSm3iQVjOQGp4z2LeA2sjpBSdu0tbgYzbZUWvm2/JvSbr6bKaTynoT2VGThnu63kcHZuaDnxwbktbmNq6HJs= Received: from VI1PR07MB3328.eurprd07.prod.outlook.com (10.175.244.10) by VI1PR07MB3328.eurprd07.prod.outlook.com (10.175.244.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.5; Thu, 19 Oct 2017 10:56:17 +0000 Received: from VI1PR07MB3328.eurprd07.prod.outlook.com ([fe80::5d7d:2995:baf9:4567]) by VI1PR07MB3328.eurprd07.prod.outlook.com ([fe80::5d7d:2995:baf9:4567%13]) with mapi id 15.20.0077.023; Thu, 19 Oct 2017 10:56:16 +0000 From: "Beck, Stefan" To: Hannes Tschofenig , "ace@ietf.org" Thread-Topic: multicast Thread-Index: AdNIng8OaAKxM8piQaWt4FllrU9xPQAJf8iA Date: Thu, 19 Oct 2017 10:56:16 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [32.66.115.40] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR07MB3328; 6:vH195O2xBdgRdvA7Gj4z1Uu/NHmivtcNvfj5ikyN8a0RJlChBIG+DmHrr2bdgpi8jWqHxU0P/4FdfNmpU1cwjsqHeine79Emgzfhia1Kn+GJnX2ufs2ysVXdZ7AGD7t9SIhzsrhhdNUhUAAR9jZ2HVnzMrH2uAcfcSWCl+QmFUToEsdT0dK9JUtlAGjhc0HAxNJmY5VxbQihJzb1rUxnPlncuWuZk0P3Hhpf95u7ZPGwzdsuxMR/WwguR8H328M4++tKhJ2cH30ze4UzBn2D1oTx+f0uIAMEc0QNxQA7/AX71vhtR+wwFPrGe2OQBDIogUxHGP/vbWrWWxsKOiFSbw==; 5:45IBTwVVzBbMbZFjhwCKR13pp9ep3QazyBceEPTLnlVqRxL92vwNlclQU7+38lVsqGwhRGDXCwglneH/nibmS9hg/JX1nupPnVVKh4L0tgXRW2Jy2F13GLhTM5rc3jAxz2mn8fH8pQzAkZZbeMs0cw==; 24:uh3gINCuWjnbQYRCFYcU68zqXpbeClNQNEPjA9TBFVB0z5ahGrrk1/Zwgz0rTIhcVqViNBYYAzxa+WpWw4fv6D+6DEJmo51zNm3yEY/SCNk=; 7:ag4fPctUDHW0zDRC6fbhW3MWMlVR752y5YDuyPLvCzi3bu1bidfzN4TO1wXhLH7CSU+ZUSg6aa5zmbl85bXVoqf1udrnYM0snAT+KQIg2q26T78icEifVU/ahG2VSVH9zRsGaVAY+4TLdPqga2ZPOa4G4GAz61Ze/9DkZGuvHfuOyU4FU4tYcGXbBzMTWpFrA14zpurBaS0y5sVfsqcym5J8XVi8SoNE9puCfslQl74= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: e164df82-b0e2-490f-320f-08d516e005cf x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254163)(4534011)(4602075)(4627075)(201703031133081)(201702281549075)(2017052603229)(49563074)(201703131423086); SRVR:VI1PR07MB3328; x-ms-traffictypediagnostic: VI1PR07MB3328: x-exchange-antispam-report-test: UriScan:(192374486261705); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(102415395)(6040450)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(10201501046)(93006095)(93001095)(3002001)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123560025)(20161123558100)(20161123564025)(20161123562025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:VI1PR07MB3328; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:VI1PR07MB3328; x-forefront-prvs: 0465429B7F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(346002)(376002)(39860400002)(377454003)(53754006)(51914003)(189002)(199003)(6506006)(99286003)(99936001)(54356999)(53546010)(68736007)(25786009)(110136005)(7696004)(50986999)(6436002)(5660300001)(8936002)(76176999)(7116003)(7736002)(229853002)(305945005)(66066001)(55016002)(221733001)(101416001)(8676002)(3660700001)(6246003)(189998001)(72206003)(97736004)(2950100002)(33656002)(3280700002)(3480700004)(966005)(105586002)(81156014)(3846002)(14454004)(2900100001)(2906002)(74316002)(478600001)(86362001)(81166006)(2501003)(6306002)(9686003)(53936002)(316002)(106356001)(6116002)(5250100002)(102836003); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR07MB3328; H:VI1PR07MB3328.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: osram.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=S.Beck@osram.com; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0406_01D348D9.A55FABD0" MIME-Version: 1.0 X-OriginatorOrg: Osram.com X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Oct 2017 10:56:16.7180 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: ec1ca250-c234-4d56-a76b-7dfb9eee0c46 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB3328 Archived-At: Subject: Re: [Ace] multicast 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, 19 Oct 2017 10:56:24 -0000 ------=_NextPart_000_0406_01D348D9.A55FABD0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Hannes, Thanks for the warm welcome! See inline my comments... Stevie > From: Ace [mailto:ace-bounces@ietf.org] On Behalf Of Hannes Tschofenig > Sent: Thursday, October 19, 2017 8:02 AM > To: ace@ietf.org > Subject: [Ace] multicast > > Hi all, > > During the ACE conference call we had a few new participants, namely Stevie, > Piotr and Marius, from the lighting consortium Fairhair attending. > Great to see new participants "on-board". > > Stevie explained that he needs a document that contains a solution using > asymmetric and symmetric cryptography, that they intend to use the > asymmetric solution whenever there is no low latency requirement > (and for unicast communication), and only use the symmetric key approach > when the low latency requirements demand it. > > Is this a correct summary? [Stevie] Well, slightly different. First, my interest is to separate unicast from multicast communication completely. (Use of DTLS, for all unicast communication) For multicast, my focus is on using asymmetric encryption for authentication & integrity, and using symmetric encryption for confidentiality. I see high chances for reasonable options to achieve this with the given drafts [1] / [2] / [3], even supporting the "low-latency" requirements we need, also considering the main ideas from [4]. Note this is still mostly a "gut feeling" today - as I am still not familiar enough with all potentially relevant details. Let me (better: us) give some more days to elaborate on that before starting broader discussion... [1] https://tools.ietf.org/html/draft-ietf-ace-dtls-authorize-01 [2] https://tools.ietf.org/html/draft-tiloca-core-multicast-oscoap-03 [3] https://tools.ietf.org/html/draft-tiloca-ace-oscoap-joining-00 [4] https://tools.ietf.org/html/draft-somaraju-ace-multicast-02 > > Ciao > Hannes > > PS: Stevie also mentioned that he likes draft-tiloca-ace-oscoap-joining-00.txt > but not draft-somaraju-ace-multicast. This was rather surprising since > draft-somaraju-ace-multicastwas written by the lighting community (in the > OpenAIS project) specifically addressing the low latency requirements of that > community. Stevie, could you explain? [Stevie] I did (and still do) support draft-somaraju-ace-multicast, see also my email to the list in March [5]. I just think that there should not be two competing drafts, where there is chance to combine them (especially when there's a chance to improve the security aspects within that common approach). I cannot speak for the OpenAIS project, but at least in the Fairhair Alliance there is currently common sense to focus on one approach (i.e. not attempting to "revive" draft-somaraju-ace-multicast) [5] https://mailarchive.ietf.org/arch/search/?email_list=ace&q=stevie ------=_NextPart_000_0406_01D348D9.A55FABD0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITQDCCBZcw ggN/oAMCAQICEH2N5rAAeSCGTQvIxSt6cDswDQYJKoZIhvcNAQELBQAwZDETMBEGCgmSJomT8ixk ARkWA2NvbTEbMBkGCgmSJomT8ixkARkWC29zcmFtLWxpZ2h0MRMwEQYKCZImiZPyLGQBGRYDaW50 MRswGQYDVQQDDBJPU1JBTSBSb290IENBIDIwMTUwHhcNMTUwOTE3MDk0NzMyWhcNNDAwOTE3MDk1 NzI2WjBkMRMwEQYKCZImiZPyLGQBGRYDY29tMRswGQYKCZImiZPyLGQBGRYLb3NyYW0tbGlnaHQx EzARBgoJkiaJk/IsZAEZFgNpbnQxGzAZBgNVBAMMEk9TUkFNIFJvb3QgQ0EgMjAxNTCCAiIwDQYJ KoZIhvcNAQEBBQADggIPADCCAgoCggIBAMPOLdsM1I8Fll2DJ5A01Y53Cbq88OH6/ZocCMhm+9Ro Ce4RHnIB+WKi8+4fTUYU3DjwgXiI3tH6YG9j9o3ahkepcaRx1arkNJCfGs8UKbHQnxVM9n5Sv3lp Qm/OyE+qwl8sA77nVvrmAiYDIXdlJajITmqMBiSS5TfS7YO7knMLOv5bzd4ihUizsNGgVIvPyowz NpsA/yYzIJJhSYCdSc9Aji5MDF4fscYaffpdaM3VoZ4gdZiVgcYrnUVR4oFsNkoja6MV3Vk9o5py 8I6ff5Dhc6ZStrjYG1Q9iIIawvvi4e4A6ISRmxw3QBUZtlvBiC8Z2g/XVJnwz91RKIT1lQPbb2Cw 88E1nRVfF1txiVbQXw+TjNnyIVcxZS/p34yHXS9/gmPVXBUx3SYqAMI9vk/mqvkDGPAkIrpILTQT XcxkJVwQukR7mSpRw4bx0bg4mxH1x6tr4HqZe5hFtQTs+VckNiXLF5xFbOjFuck5UBRbW8J3ENCA ohtR/OdOAKFrS7Y5uPLA5ENMt+Ee2LeaEmwUIIioYZuToXngaimCg6m9aIGv9ytMUgnF3+9CRsKr drVw6Er2eKnGOXyBaMOkR14loeFISsA9UL85Ib80MHLZd8t0rkIpThZSKMMS/eKpGyZMv9HLYrVZ 1TssyD8pvu4yzrHGtrtehXu2JfRm+gzdAgMBAAGjRTBDMA4GA1UdDwEB/wQEAwIBBjASBgNVHRMB Af8ECDAGAQH/AgECMB0GA1UdDgQWBBRBffSxSuh0TnMOw0EPaZQm3UsWYTANBgkqhkiG9w0BAQsF AAOCAgEAoHwKO+Sh72eofY0BSZ+h+ajR9K7PJnwrLV557s4Id1EIvfMU8geELns5FsKOcAg9ipnv PPt0EVFFGulfyKRa0OPLvz7ofpEF0Bs8LVdAbqtImf9YGAmFtf7zIEdKmtDhGdKNabwt0QbVKOEs IzbQCeKXdFQ6/s0c+aSO/I1wLOekihbY1PY0IzNzDBfIbzDdFgcQfVc+kSlV2sSKjrqpG9qGvvwL VCWSCGFC/nAkb4g4PXhmOEIfo04vaibNHYFyl4ltZiWph/mism4MM1bAvPtZM8fFc1J6Sgkir7vD XQOCpQrxFYAKTqOIhAGn0hY/AY7198X5Jeh/tCUjatDz7AHuhdBTPC+XeGMyzvj7fkVwTv3TazEo u6jpmn6b2QY+0GdVytR4R0KFFIjGvxmOH4gg7pfOwplpjzE3K11CHGsEXQwAZNPnhj/EXEqSdx3g dUX77plIcnE8TwXxoY+aa9p1JfAmKVLT3vZbT8YDm83RkN7vcyGW/NBDq2OyihORutQxuy9PpYaM Txnzp9M620XFwKJbU3D0vYvHOgYFKQy71hgn/AX3KnQ+MXgiRCy5phiSTOTc8SZzuijBV2X30hX+ NAd3M4dQq4/VnK/Zop0LYornrFK79re2RLDqm1NP/k9yAOCc0WR7lQOhFW3R0JgFSmRSMsR4PWGg afjpMSgwggZ1MIIEXaADAgECAhMYAADE1BvnBAMoNJsjAAAAAMTUMA0GCSqGSIb3DQEBCwUAMGcx EzARBgoJkiaJk/IsZAEZFgNjb20xGzAZBgoJkiaJk/IsZAEZFgtvc3JhbS1saWdodDETMBEGCgmS JomT8ixkARkWA2ludDEeMBwGA1UEAwwVT1NSQU0gSXNzdWluZyBDQSAyMDE1MB4XDTE2MTEwMzE1 NTYxMVoXDTIxMTEwMjE1NTYxMVowcjELMAkGA1UEBhMCREUxDjAMBgNVBAoMBU9TUkFNMRwwGgYD VQQLDBNPU1JBTSBHbWJILCBHZXJtYW55MRQwEgYDVQQDDAtTdGVmYW4gQmVjazEfMB0GCSqGSIb3 DQEJARYQUy5CZWNrQG9zcmFtLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKht x104jKLZgCEyi4IKs7QjFm+csCMA3g4nYkhYmv5yK4Jtw6pixicOV4KUypkejZhbWmU+vyD3iY/0 aZ+uvwyNl90CA8fWmKdC1sF7xs7MtYvaQOycf47BTkqAdlOep9iTKxKpEW9B9LchU2iBUdhdQUsy jYrvq3MzPGw5ERW9dSwsXf4M5l3pDmlfPgCAYmEdRop4eUshqh87cr8AfzTm4XEcR7pG6lOgTkFa kZAltl6U3+VHQ2PQj6pw5VRHuaqPunZVFJL8e8kNErDgPkRnY2t12qNIbvxiSri3gSDHlOJJ/kND HHzI2+yOEA70nFfFG0tY6DcXwm8qWmT6uMECAwEAAaOCAg0wggIJMAsGA1UdDwQEAwIF4DA9Bgkr BgEEAYI3FQcEMDAuBiYrBgEEAYI3FQiCuLoUhdG3QIS5iTOG7K5ahOeweYENxscDgoHuRQIBZAIB CDBEBgkqhkiG9w0BCQ8ENzA1MA4GCCqGSIb3DQMCAgIAgDAOBggqhkiG9w0DBAICAIAwBwYFKw4D AgcwCgYIKoZIhvcNAwcwHQYDVR0OBBYEFKLokmPgby7PzMPWwS913WLd8w7yMB8GA1UdIwQYMBaA FAd1EUQRun6PdD2R16jhaq0s694uMF8GA1UdHwRYMFYwVKBSoFCGTmh0dHA6Ly9wa2kub3NyYW0t bGlnaHQuY29tL09TUkFNLUlTU1VJTkctQ0EtMjAxNS9DUkwvT1NSQU0tSVNTVUlORy1DQS0yMDE1 LmNybDBrBggrBgEFBQcBAQRfMF0wWwYIKwYBBQUHMAKGT2h0dHA6Ly9wa2kub3NyYW0tbGlnaHQu Y29tL09TUkFNLUlTU1VJTkctQ0EtMjAxNS9DZXJ0L09TUkFNLUlTU1VJTkctQ0EtMjAxNS5jcnQw HwYDVR0lBBgwFgYIKwYBBQUHAwQGCisGAQQBgjcKAwQwKQYJKwYBBAGCNxUKBBwwGjAKBggrBgEF BQcDBDAMBgorBgEEAYI3CgMEMBsGA1UdEQQUMBKBEFMuQmVja0Bvc3JhbS5jb20wDQYJKoZIhvcN AQELBQADggIBAAeoZQyM9u1NEpKRRDYMydLJ1wa1Y1m7rDfp5CPp0uni4qS5iXReWgIEzkhNCV5E oC0DosSOqnh2BkAkX+khNPuhLjjM/ApbFIqnnY+RD+xz3fxjx584TFmBugWHvKycYyD5NWhtD6Ej mWv6tUsxjYCv652LruxCdGJDbsaaEKP28te5dwMLD9wqSrBVU6ftbuzb9rL7IatpcBPCDkuCXSSQ lnAefbP2Y73wm1/+tbP/FxgyQjZUFR5qbXl2fMyynsrqLr3c6K7VxZs8+psbd+PiOlQnXcfGGCWR cZxr0cUZP/O861rFlE8s1OpxN5XI2pQIAzJx2toIsmHdk6hOY7t/2lYaMtqQLl2+cd2RoUMijM+1 Yi+v2WwuErdZzmgjTKht8rinng7GAuiSIQB489J4FgOEBWYne8zrl7jyuU9RYcYN9Nc5IZhK2Nfg 0xDh4tWeMWIuCg8f9ubeHOekdrg01cazDavxjaftQ25+2J5EwAWxc4ZPivOD9bkiYknSfg2iih2Y iRxUXqVq0q+qCfVDeys+MSFcu/WetN2ibvouzr+q4Aw+71j6M7FaWWpRz5FFKz40O/wAzoR2WB7u gGuT4RlAb7Yr8zM8TRpHKmrOSi19o/5qbGrPOX3u/B9UjK3LvR0n7TO6J9q0qxKveWlu6cofPQRd 2UVQoaNLB90mMIIHKDCCBRCgAwIBAgITWAAAAAXTK7hm1i4tGAAAAAAABTANBgkqhkiG9w0BAQsF ADBkMRMwEQYKCZImiZPyLGQBGRYDY29tMRswGQYKCZImiZPyLGQBGRYLb3NyYW0tbGlnaHQxEzAR BgoJkiaJk/IsZAEZFgNpbnQxGzAZBgNVBAMMEk9TUkFNIFJvb3QgQ0EgMjAxNTAeFw0xNTA5MzAx MjM2MTdaFw0yNzA5MzAxMjQ2MTdaMGcxEzARBgoJkiaJk/IsZAEZFgNjb20xGzAZBgoJkiaJk/Is ZAEZFgtvc3JhbS1saWdodDETMBEGCgmSJomT8ixkARkWA2ludDEeMBwGA1UEAwwVT1NSQU0gSXNz dWluZyBDQSAyMDE1MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAvbRnffh0KvDggawO /LfHMVmHl1fTbjzZQRjbbdUG6aKwTGeIpg7M4RXUIObssQ7sbSxuu77Vz2OFdSf5vk1fVZn8DFD8 dVB2AsYKPWZmBO+CYOvb2NCNqyLnt2/Mlk74gwTXdBgJsNjDbxs6yIfwn+rdGNt3gDwPeTiX+0Rn Ccj1NclFef00nW4kKFr2kkf+tVXMQx3pS7BQAjyuL+coQmOD5vIM+qU4dGy9ndYExTMTOPbDQaAO lx/vPXUSS1FvMJtKz//ODt/yew5RL55ZKuh6Mi7TvGTYcSH989NlXjYIYGQ0/5zfukj6CcscjInX 9W4U6NFvZL8YoVR6RLQkOTtfYa36t/iw16diSlBVeM7wq471fRXpytuGjLVtOl+oGGA7uM1QJ2OH OaXKzb6S28h8/W2urmHWMnSsBioznyio28I1PzyiwQeSe1NuMRobL0wSOTL/wljsxEkapvn4u3oW +SQCNyvXyigIYh+OaKNWFj62GclxPzoWkeT6FD6a6GS6geNyAF04N8fA/P1G/sSSCUcNdLodeEQz 17uSvIxKIFb0t7TgM40vgfwW929cv8hSoEfYQykeuPWPRc8nYkb9y6FSqpWxkXCFZRcVr826I7HY 3c2cfjFytMx4eyE5NzLV8n8jbEG0oM8c1SO1ojT4eQUgJgR2dE0OM6iJi6cCAwEAAaOCAc4wggHK MAsGA1UdDwQEAwIBhjAdBgNVHQ4EFgQUB3URRBG6fo90PZHXqOFqrSzr3i4wgaQGA1UdIASBnDCB mTCBlgYdKwYBBAGCNxUIgri6FIXRt0CEuYkzhuyuWoTnsHkwdTA8BggrBgEFBQcCAjAwHi4ATABl AGcAYQBsACAAcABvAGwAaQBjAHkAIABzAHQAYQB0AGUAbQBlAG4AdAAuMDUGCCsGAQUFBwIBFilo dHRwOi8vcGtpLm9zcmFtLWxpZ2h0LmNvbS9DUFMvaW5kZXguaHRtADASBgNVHRMBAf8ECDAGAQH/ AgEBMB8GA1UdIwQYMBaAFEF99LFK6HROcw7DQQ9plCbdSxZhMFkGA1UdHwRSMFAwTqBMoEqGSGh0 dHA6Ly9wa2kub3NyYW0tbGlnaHQuY29tL09TUkFNLVJvb3QtQ0EtMjAxNS9DUkwvT1NSQU0tUm9v dC1DQS0yMDE1LmNybDBlBggrBgEFBQcBAQRZMFcwVQYIKwYBBQUHMAKGSWh0dHA6Ly9wa2kub3Ny YW0tbGlnaHQuY29tL09TUkFNLVJvb3QtQ0EtMjAxNS9DZXJ0L09TUkFNLVJvb3QtQ0EtMjAxNS5j cnQwDQYJKoZIhvcNAQELBQADggIBACnQrysmPX41U+j/Q33kIHIGxFU0aYS0qrBmzGGGGNamqD8H 2SGy8LdCVcGeecE3XlKzZe+AnTTa1ejhHvhMJc8tHCgMLyvdSxKjJ69Rp75AaknxX15AwuFMkqLQ O+itE0PV6f3QHVdYevo2asZ3UgaQGOBFEo782qiNBDHawzuuXpXUTo4gWntTieXICIXWEenOgin1 901aoM0qzHTd8CXHdN8W7UNOE/6eCH02LofORiL2OzOAaz6aduK76KIEn3Fb2fbFAwKVIgTbvflA 9AWliukXYOSTGg9NXOyUVAE+ti4s720bYAJNrHTSbxbVpkDaWyZOhL/MsDAl3Q5/tMBbykhIy1pA 0zg5Q0QVr7B57x2Yo62nbduruNAnA0t+Q6DOrIRudaboAEeIXsQzVuUKd11o9mDOcVuetRxoS7lN 33zC3IHQajDFs8UHt4z6Cjj3EGttiS+ApUyDztgThD8bq7JSiAcFuXXD7zKmWN4TR6hKqTr9YGqA qhx/Dh7yYGUIOGAQi/EM0X1Ak73R45BopSyUm6oVj9i+w3SVvW66GxHbSUHqj8hA5Mokb9/ZC4Hn r/8CTC6MyfFJgksnMLEnhQOpCCaOzKtJ7UMnSeJHYHQUiDksIY5d3Y2T7QWDww7U95fMtGfPhqbA cF1qh4o9RYzuFWS6puXo7eRS2O1lMYIDwDCCA7wCAQEwfjBnMRMwEQYKCZImiZPyLGQBGRYDY29t MRswGQYKCZImiZPyLGQBGRYLb3NyYW0tbGlnaHQxEzARBgoJkiaJk/IsZAEZFgNpbnQxHjAcBgNV BAMMFU9TUkFNIElzc3VpbmcgQ0EgMjAxNQITGAAAxNQb5wQDKDSbIwAAAADE1DAJBgUrDgMCGgUA oIICFzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzEwMTkxMDU2 MTRaMCMGCSqGSIb3DQEJBDEWBBQEVoZvKx+Z1JEBKTVT+hnyl2sgdzCBjgYJKwYBBAGCNxAEMYGA MH4wZzETMBEGCgmSJomT8ixkARkWA2NvbTEbMBkGCgmSJomT8ixkARkWC29zcmFtLWxpZ2h0MRMw EQYKCZImiZPyLGQBGRYDaW50MR4wHAYDVQQDDBVPU1JBTSBJc3N1aW5nIENBIDIwMTUCExgAAMTU G+cEAyg0myMAAAAAxNQwgZAGCyqGSIb3DQEJEAILMYGAoH4wZzETMBEGCgmSJomT8ixkARkWA2Nv bTEbMBkGCgmSJomT8ixkARkWC29zcmFtLWxpZ2h0MRMwEQYKCZImiZPyLGQBGRYDaW50MR4wHAYD VQQDDBVPU1JBTSBJc3N1aW5nIENBIDIwMTUCExgAAMTUG+cEAyg0myMAAAAAxNQwgZMGCSqGSIb3 DQEJDzGBhTCBgjALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAoGCCqGSIb3DQMHMAsGCWCGSAFl AwQBAjAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAhowCwYJYIZIAWUDBAID MAsGCWCGSAFlAwQCAjALBglghkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAGYVjaqsWiigYrHxQ ujyxdaAj5BB0T0CSlb7yleYY+1fUG/rf60LGGjRwN6giNbm0BjXQYK9249LgzPMmnCCSwx9gx/Xd HzCzKiCoDx1jAzUk58rwbUOJcTOrnqW8ZBsFbeH8W3nVcq7mzwZHMnONc5MNCP2tpGliUIHPn5Dz BLDJWwmaWAZAHUfvIrnT+/fgB71I+WgfKe5VuP5G2jh7k5HhBsk7+9Pte6NzcxUpuVXQcWq7zxYE c46Yujglm6u1ATJizpW0cAB3igiIGuJ4Vj+yx16u2TtEhfcBDcdmF9xdmme+s+YbQoo4GgY2y5NX 7YLzT6QuexH6BQZFsRGilAAAAAAAAA== ------=_NextPart_000_0406_01D348D9.A55FABD0-- From nobody Thu Oct 19 04:26:07 2017 Return-Path: X-Original-To: ace@ietf.org Delivered-To: ace@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C686413461F; Thu, 19 Oct 2017 04:26:05 -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.63.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150841236576.18674.2983507711672429651@ietfa.amsl.com> Date: Thu, 19 Oct 2017 04:26:05 -0700 Archived-At: Subject: [Ace] I-D Action: draft-ietf-ace-oauth-authz-08.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Oct 2017 11:26:06 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Authentication and Authorization for Constrained Environments WG of the IETF. Title : Authentication and Authorization for Constrained Environments (ACE) Authors : Ludwig Seitz Goeran Selander Erik Wahlstroem Samuel Erdtman Hannes Tschofenig Filename : draft-ietf-ace-oauth-authz-08.txt Pages : 70 Date : 2017-10-19 Abstract: This specification defines a framework for authentication and authorization in Internet of Things (IoT) environments. 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-08 https://datatracker.ietf.org/doc/html/draft-ietf-ace-oauth-authz-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-oauth-authz-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Oct 19 04:33:46 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31AA613461F for ; Thu, 19 Oct 2017 04:33:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eNC0CnlZmHeB for ; Thu, 19 Oct 2017 04:33:43 -0700 (PDT) Received: from se-out1.mx-wecloud.net (se-out1.mx-wecloud.net [89.221.255.93]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A11CD13337F for ; Thu, 19 Oct 2017 04:33:42 -0700 (PDT) Received: from sp-mail-2.sp.se (unknown [194.218.146.197]) by se-out1.mx-wecloud.net (Postfix) with ESMTPS id 1BB45204FBF for ; Thu, 19 Oct 2017 11:33:38 +0000 (UTC) Received: from [192.168.0.166] (10.116.0.226) by sp-mail-2.sp.se (10.100.0.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1261.35; Thu, 19 Oct 2017 13:33:39 +0200 References: <150841236576.18674.2983507711672429651@ietfa.amsl.com> From: Ludwig Seitz To: "ace@ietf.org" X-Forwarded-Message-Id: <150841236576.18674.2983507711672429651@ietfa.amsl.com> Message-ID: <4c0a3f31-cd3c-e441-32a1-02af1cc232f0@ri.se> Date: Thu, 19 Oct 2017 13:33:39 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <150841236576.18674.2983507711672429651@ietfa.amsl.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.116.0.226] X-ClientProxiedBy: sp-mail-3.sp.se (10.100.0.163) To sp-mail-2.sp.se (10.100.0.162) X-CMAE-Score: 0 X-CMAE-Analysis: v=2.2 cv=cdiiljLM c=1 sm=1 tr=0 a=L5DDne6A+dD0FbDkt2Fblw==:117 a=L5DDne6A+dD0FbDkt2Fblw==:17 a=sZ8rJzgPlrQA:10 a=N659UExz7-8A:10 a=02M-m0pO-4AA:10 a=48vgC7mUAAAA:8 a=FwQTZsfUSQaClScTq_gA:9 a=pILNOxqGKmIA:10 a=w1C3t2QeGrPiZgrLijVG:22 X-Virus-Scanned: clamav-milter 0.99.2 at MailSecurity X-Virus-Status: Clean X-MailSecurity-Status: 0 X-Scanned-By: WeCloud MailSecurity X-MailSecurity-Score: 0 Archived-At: Subject: [Ace] Fwd: I-D Action: draft-ietf-ace-oauth-authz-08.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Oct 2017 11:33:45 -0000 Hello, as per the discussion at the interim telco yesterday I have submitted a new version of the framework draft. This addresses most of Jim Schaad's review comments and parts of Mike Jones's review comments. Both reviews are hereby gratefully acknowledged. Please find a list of major changes in Appendix https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-08#appendix-F (also note a small error has slipped my vigilance, and the changelog refers to changes from Version 08 to 09 which of course should have been 07 to 08 (and merged with the current "07 to 08" section). /Ludwig -------- Forwarded Message -------- Subject: [Ace] I-D Action: draft-ietf-ace-oauth-authz-08.txt Date: Thu, 19 Oct 2017 04:26:05 -0700 From: internet-drafts@ietf.org To: i-d-announce@ietf.org CC: ace@ietf.org 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) Authors : Ludwig Seitz Goeran Selander Erik Wahlstroem Samuel Erdtman Hannes Tschofenig Filename : draft-ietf-ace-oauth-authz-08.txt Pages : 70 Date : 2017-10-19 Abstract: This specification defines a framework for authentication and authorization in Internet of Things (IoT) environments. 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-08 https://datatracker.ietf.org/doc/html/draft-ietf-ace-oauth-authz-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-oauth-authz-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace From nobody Thu Oct 19 05:51:51 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2CC5132697 for ; Thu, 19 Oct 2017 05:51:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rcgXx2NrArcf for ; Thu, 19 Oct 2017 05:51:48 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0064.outbound.protection.outlook.com [104.47.0.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C57371241F3 for ; Thu, 19 Oct 2017 05:51:47 -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=i9n86a3EcoJFDxwT9UmvEIKsMII/F8GssJ7g0Sgni0g=; b=InKfoav5X3sei2Vz2clhgNZSzofAUXLRHeTrPD1jy1YET2i2GpSoHffdVlPbUjVUX+0j7CTBpr+AavN3Zi7BfZ42df4xuM9SNt26eRunuC8ILboLmSVbHogF2GlNkC1OWKAkPrzJ/I41SvuuGCpkuFYh512l2PHI6BEiyOG9gW0= Received: from AM4PR0801MB2706.eurprd08.prod.outlook.com (10.167.90.148) by AM4PR0801MB2708.eurprd08.prod.outlook.com (10.167.90.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.7; Thu, 19 Oct 2017 12:51:44 +0000 Received: from AM4PR0801MB2706.eurprd08.prod.outlook.com ([fe80::6027:3e1:2bf7:68ed]) by AM4PR0801MB2706.eurprd08.prod.outlook.com ([fe80::6027:3e1:2bf7:68ed%14]) with mapi id 15.20.0077.022; Thu, 19 Oct 2017 12:51:44 +0000 From: Hannes Tschofenig To: "Beck, Stefan" , "ace@ietf.org" Thread-Topic: multicast Thread-Index: AdNIng8OaAKxM8piQaWt4FllrU9xPQAJf8iAAAMwwFA= Date: Thu, 19 Oct 2017 12:51:44 +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: [91.205.194.85] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM4PR0801MB2708; 6:/IPYYbuhoBmWXaDHf/hTEFYBh8vAwFXvZIhNzZB7d3lz76RygxfG5C+olP8iXBhI75zqcw61MRkVyl+fIbA5gRF5PuP2HDSkoWnbGBP+wVa7eKlzVy5SnA8827tKIuh5+GCGMzwqpymnPm2SwMlkp14dWJFuxHaRBS+yeRuGh71qUImvhXMM8Z+qg5yXfg8fiL0fXMo/VxmMjtcdk6vx5wjBWAKoak/srPYhHIMTFWpoQkl9c+zj8WT3X3HOxip3R8bG5Esx2c4F8wfU3oDWMolyccixTg7XYTnCZHkbyAnJTEMzoqZzddcZ79kPmSpZfcs3hZ8Irv5nvKg6UucV2g==; 5:l6K+u/bK8P+L9gmK0zrCrds58tk7SrMfGqxS9GvBsUrsvPhlsLYsZytMDTeHe4ZURTODUV4wmarNhg7XTenwud2SxyKtu80MSG3Rl0ex5TQ6yPvbvcafRUWq1KwncopnPRYa12tAGFz3DlgHFCXFKg==; 24:lioUSkSXRAO1Lit9m/rBFt8eXtMq/fXPoIKEQwr9ozEOhYZJmn+I/xD/U1UM6Y28k9ZcZ/Ptraq9R/6YUbO/LsIn6KpapEzvxsxIiVf8lrU=; 7:jQHxLrbVSZa+dHb8qkvuFyU6QrcTyfA1ZbrWMBkVz2qbQ0RMNo1t9rxQyC64oTHfPLGNBw+k2BfOdXv3kUJOq1+UaCpjj6xGZumsXE8qS9/ldj9j6ZhEmsJy70hy2G9ydHUjMjgjCbXtV4BK2mmQkrmSTY7RfxNkwYigumMrrj8+aALmQyZFg2O7W62KVubTYknjv3Bg2RltAnAPYSD20cfCVd62HV2jgNoiTeIxubU= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 7812a5c5-c9eb-4edc-32dd-08d516f02703 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(48565401081)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:AM4PR0801MB2708; x-ms-traffictypediagnostic: AM4PR0801MB2708: x-exchange-antispam-report-test: UriScan:; x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(100000703101)(100105400095)(10201501046)(3002001)(93006095)(93001095)(6055026)(6041248)(20161123560025)(20161123564025)(20161123562025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM4PR0801MB2708; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM4PR0801MB2708; x-forefront-prvs: 0465429B7F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39860400002)(376002)(346002)(40434004)(199003)(189002)(2906002)(2900100001)(33656002)(6246003)(3660700001)(14454004)(8936002)(110136005)(106356001)(6436002)(3280700002)(105586002)(3480700004)(68736007)(97736004)(81156014)(6506006)(305945005)(229853002)(5250100002)(8676002)(316002)(7736002)(81166006)(74316002)(7116003)(2501003)(5660300001)(55016002)(5890100001)(3846002)(72206003)(9686003)(189998001)(478600001)(6116002)(102836003)(221733001)(99286003)(50986999)(2950100002)(25786009)(76176999)(66066001)(101416001)(53936002)(7696004)(54356999)(86362001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR0801MB2708; H:AM4PR0801MB2706.eurprd08.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Oct 2017 12:51:44.4963 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR0801MB2708 Archived-At: Subject: Re: [Ace] multicast 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, 19 Oct 2017 12:51:50 -0000 Hi Stefan, I am trying to understand your ideas. ~snip ~ > For multicast, my focus is on using asymmetric encryption for authentication & integrity, and using symmetric encryption for confidentiality. In your view, you are sending a multicast message that will contain a digit= al signature and is also encrypted using symmetric key crypto? Is this correct? 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 Oct 19 06:20:41 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C68D132D18 for ; Thu, 19 Oct 2017 06:20:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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=osram.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 vVQqXHk7boqK for ; Thu, 19 Oct 2017 06:20:36 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0085.outbound.protection.outlook.com [104.47.0.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3753F1321A0 for ; Thu, 19 Oct 2017 06:20:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Osram.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=1uaTefrwsZhRczlY7P68JUwuIQiNGxO3zXwOJXP5d2s=; b=pVXnfs1FDYoDyfxLcxwLy8X+SlHeX+0TxtivHQg4heEXHwm1nGwHRQocOxYtrmS5g1mpuk4P4J/VTvsvaLkg1MiruAO9cfDp08w3HAsPEOck5nA/yd3Ns7QxThJdsoJAgFOQzHA/5/FMbPAH59SXF56QnmYdFaNX0hPzj19/4xQ= Received: from VI1PR07MB3328.eurprd07.prod.outlook.com (10.175.244.10) by VI1PR07MB3326.eurprd07.prod.outlook.com (10.175.243.160) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.5; Thu, 19 Oct 2017 13:20:33 +0000 Received: from VI1PR07MB3328.eurprd07.prod.outlook.com ([fe80::5d7d:2995:baf9:4567]) by VI1PR07MB3328.eurprd07.prod.outlook.com ([fe80::5d7d:2995:baf9:4567%13]) with mapi id 15.20.0077.023; Thu, 19 Oct 2017 13:20:33 +0000 From: "Beck, Stefan" To: Hannes Tschofenig , "ace@ietf.org" Thread-Topic: multicast Thread-Index: AdNIng8OaAKxM8piQaWt4FllrU9xPQAJf8iAAAMwwFAAAwsVkA== Date: Thu, 19 Oct 2017 13:20:33 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=S.Beck@osram.com; x-originating-ip: [32.66.115.40] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR07MB3326; 6:1LRXguckcsBnJ0QanBR4GYXQVEXLPcqutZq8NngQmfUDwTKFDVcXeSEjIyhiVBEEDXaK1RVIe8Xy+ZKvS3/PLG9WGY5LuGSOpZikKrqQs/ZNrDeA9s9ixVvLQZ8JnxKBCV+VUImxyCMQGABcw87ZprWTDF0M/9B3WCftA8caL8wN7MjXpJruwGuBqw+/fqEOfMVjqTHl+nlxKprVCaKX64IrbcPD46h+LAJ1yjPyvtJ3J/uc7+tP1pGQqYpQ9ND8ATF9Awpg297/MGHEojw/SAppg2GjgaFyygoqDADldyMlm9UE3P9oRjFuc9hiB047qqT1nwd8tZK5+Iq1prkM6Q==; 5:NB833g9GVwV3FWHM8e5uufbkNAC/By/mpLsrGBga+7uAbgqnaimShGKp8RPnr1HQPyp8ZoRa034N3te6UXgFsbvvaku0raVSrwaoBlHrWCbfeia6VXQusMTClYGNk+f2wohjTfnC+Muss1XKMf3PfQ==; 24:wk+d1pIZgk9fqc2ZKX/Jcs39hLbPBnbnE2S6TBx4rE5QWXS9aA8rsTBKBHh6iDVsRfzkdmwSoEo7oGzdJcUjLc/HybnUm2DRIv5k/k16k+g=; 7:1CXOT2vQMx+fzJjiUW2HZK1GeT9k0WHWo9gVXH1suJ1R+HtOGGkWrMpWqI0F1aA9NF0OXFgxLKi6Y2WHxDsUiBPaFpPZ/z4utiU4R8vDTx8T1IE/m/oqDm/p1qCyQkoq6wNUF4T8qtInfegsYAoFNokQ43NOdEco68zbUxi6r03OTtq/DtW/OZZM6oDyyL5HSryid8LInnLuwIfI5BnkNELbVuh2kxbrwZWWeyeBTAA= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 538ca32a-117d-4907-1004-08d516f42d6b x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(2017052603199)(49563074)(201703131423075)(201703031133081)(201702281549075); SRVR:VI1PR07MB3326; x-ms-traffictypediagnostic: VI1PR07MB3326: x-exchange-antispam-report-test: UriScan:(180628864354917); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(102415395)(6040450)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93001095)(3002001)(100000703101)(100105400095)(6041248)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123560025)(20161123555025)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:VI1PR07MB3326; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:VI1PR07MB3326; x-forefront-prvs: 0465429B7F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(376002)(346002)(39860400002)(13464003)(377454003)(199003)(189002)(189998001)(7116003)(5660300001)(6246003)(478600001)(55016002)(316002)(9686003)(110136005)(99286003)(72206003)(221733001)(229853002)(53546010)(2900100001)(97736004)(14454004)(2950100002)(7696004)(53936002)(6436002)(6506006)(2906002)(50986999)(81166006)(81156014)(25786009)(106356001)(54356999)(76176999)(5250100002)(8936002)(33656002)(5890100001)(101416001)(99936001)(8676002)(105586002)(3280700002)(3660700001)(66066001)(6116002)(7736002)(102836003)(86362001)(68736007)(74316002)(3846002)(3480700004)(305945005)(2501003); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR07MB3326; H:VI1PR07MB3328.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: osram.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0469_01D348ED.CB5B6590" MIME-Version: 1.0 X-OriginatorOrg: Osram.com X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Oct 2017 13:20:33.1374 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: ec1ca250-c234-4d56-a76b-7dfb9eee0c46 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB3326 Archived-At: Subject: Re: [Ace] multicast 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, 19 Oct 2017 13:20:40 -0000 ------=_NextPart_000_0469_01D348ED.CB5B6590 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Yes, correct. Stevie > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@arm.com] > Sent: Thursday, October 19, 2017 2:52 PM > To: Beck, Stefan ; ace@ietf.org > Subject: RE: multicast > > Hi Stefan, > > I am trying to understand your ideas. > > ~snip ~ > > > For multicast, my focus is on using asymmetric encryption for > authentication & integrity, and using symmetric encryption for confidentiality. > > In your view, you are sending a multicast message that will contain a digital > signature and is also encrypted using symmetric key crypto? > > Is this correct? > > 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. ------=_NextPart_000_0469_01D348ED.CB5B6590 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITQDCCBZcw ggN/oAMCAQICEH2N5rAAeSCGTQvIxSt6cDswDQYJKoZIhvcNAQELBQAwZDETMBEGCgmSJomT8ixk ARkWA2NvbTEbMBkGCgmSJomT8ixkARkWC29zcmFtLWxpZ2h0MRMwEQYKCZImiZPyLGQBGRYDaW50 MRswGQYDVQQDDBJPU1JBTSBSb290IENBIDIwMTUwHhcNMTUwOTE3MDk0NzMyWhcNNDAwOTE3MDk1 NzI2WjBkMRMwEQYKCZImiZPyLGQBGRYDY29tMRswGQYKCZImiZPyLGQBGRYLb3NyYW0tbGlnaHQx EzARBgoJkiaJk/IsZAEZFgNpbnQxGzAZBgNVBAMMEk9TUkFNIFJvb3QgQ0EgMjAxNTCCAiIwDQYJ KoZIhvcNAQEBBQADggIPADCCAgoCggIBAMPOLdsM1I8Fll2DJ5A01Y53Cbq88OH6/ZocCMhm+9Ro Ce4RHnIB+WKi8+4fTUYU3DjwgXiI3tH6YG9j9o3ahkepcaRx1arkNJCfGs8UKbHQnxVM9n5Sv3lp Qm/OyE+qwl8sA77nVvrmAiYDIXdlJajITmqMBiSS5TfS7YO7knMLOv5bzd4ihUizsNGgVIvPyowz NpsA/yYzIJJhSYCdSc9Aji5MDF4fscYaffpdaM3VoZ4gdZiVgcYrnUVR4oFsNkoja6MV3Vk9o5py 8I6ff5Dhc6ZStrjYG1Q9iIIawvvi4e4A6ISRmxw3QBUZtlvBiC8Z2g/XVJnwz91RKIT1lQPbb2Cw 88E1nRVfF1txiVbQXw+TjNnyIVcxZS/p34yHXS9/gmPVXBUx3SYqAMI9vk/mqvkDGPAkIrpILTQT XcxkJVwQukR7mSpRw4bx0bg4mxH1x6tr4HqZe5hFtQTs+VckNiXLF5xFbOjFuck5UBRbW8J3ENCA ohtR/OdOAKFrS7Y5uPLA5ENMt+Ee2LeaEmwUIIioYZuToXngaimCg6m9aIGv9ytMUgnF3+9CRsKr drVw6Er2eKnGOXyBaMOkR14loeFISsA9UL85Ib80MHLZd8t0rkIpThZSKMMS/eKpGyZMv9HLYrVZ 1TssyD8pvu4yzrHGtrtehXu2JfRm+gzdAgMBAAGjRTBDMA4GA1UdDwEB/wQEAwIBBjASBgNVHRMB Af8ECDAGAQH/AgECMB0GA1UdDgQWBBRBffSxSuh0TnMOw0EPaZQm3UsWYTANBgkqhkiG9w0BAQsF AAOCAgEAoHwKO+Sh72eofY0BSZ+h+ajR9K7PJnwrLV557s4Id1EIvfMU8geELns5FsKOcAg9ipnv PPt0EVFFGulfyKRa0OPLvz7ofpEF0Bs8LVdAbqtImf9YGAmFtf7zIEdKmtDhGdKNabwt0QbVKOEs IzbQCeKXdFQ6/s0c+aSO/I1wLOekihbY1PY0IzNzDBfIbzDdFgcQfVc+kSlV2sSKjrqpG9qGvvwL VCWSCGFC/nAkb4g4PXhmOEIfo04vaibNHYFyl4ltZiWph/mism4MM1bAvPtZM8fFc1J6Sgkir7vD XQOCpQrxFYAKTqOIhAGn0hY/AY7198X5Jeh/tCUjatDz7AHuhdBTPC+XeGMyzvj7fkVwTv3TazEo u6jpmn6b2QY+0GdVytR4R0KFFIjGvxmOH4gg7pfOwplpjzE3K11CHGsEXQwAZNPnhj/EXEqSdx3g dUX77plIcnE8TwXxoY+aa9p1JfAmKVLT3vZbT8YDm83RkN7vcyGW/NBDq2OyihORutQxuy9PpYaM Txnzp9M620XFwKJbU3D0vYvHOgYFKQy71hgn/AX3KnQ+MXgiRCy5phiSTOTc8SZzuijBV2X30hX+ NAd3M4dQq4/VnK/Zop0LYornrFK79re2RLDqm1NP/k9yAOCc0WR7lQOhFW3R0JgFSmRSMsR4PWGg afjpMSgwggZ1MIIEXaADAgECAhMYAADE1BvnBAMoNJsjAAAAAMTUMA0GCSqGSIb3DQEBCwUAMGcx EzARBgoJkiaJk/IsZAEZFgNjb20xGzAZBgoJkiaJk/IsZAEZFgtvc3JhbS1saWdodDETMBEGCgmS JomT8ixkARkWA2ludDEeMBwGA1UEAwwVT1NSQU0gSXNzdWluZyBDQSAyMDE1MB4XDTE2MTEwMzE1 NTYxMVoXDTIxMTEwMjE1NTYxMVowcjELMAkGA1UEBhMCREUxDjAMBgNVBAoMBU9TUkFNMRwwGgYD VQQLDBNPU1JBTSBHbWJILCBHZXJtYW55MRQwEgYDVQQDDAtTdGVmYW4gQmVjazEfMB0GCSqGSIb3 DQEJARYQUy5CZWNrQG9zcmFtLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKht x104jKLZgCEyi4IKs7QjFm+csCMA3g4nYkhYmv5yK4Jtw6pixicOV4KUypkejZhbWmU+vyD3iY/0 aZ+uvwyNl90CA8fWmKdC1sF7xs7MtYvaQOycf47BTkqAdlOep9iTKxKpEW9B9LchU2iBUdhdQUsy jYrvq3MzPGw5ERW9dSwsXf4M5l3pDmlfPgCAYmEdRop4eUshqh87cr8AfzTm4XEcR7pG6lOgTkFa kZAltl6U3+VHQ2PQj6pw5VRHuaqPunZVFJL8e8kNErDgPkRnY2t12qNIbvxiSri3gSDHlOJJ/kND HHzI2+yOEA70nFfFG0tY6DcXwm8qWmT6uMECAwEAAaOCAg0wggIJMAsGA1UdDwQEAwIF4DA9Bgkr BgEEAYI3FQcEMDAuBiYrBgEEAYI3FQiCuLoUhdG3QIS5iTOG7K5ahOeweYENxscDgoHuRQIBZAIB CDBEBgkqhkiG9w0BCQ8ENzA1MA4GCCqGSIb3DQMCAgIAgDAOBggqhkiG9w0DBAICAIAwBwYFKw4D AgcwCgYIKoZIhvcNAwcwHQYDVR0OBBYEFKLokmPgby7PzMPWwS913WLd8w7yMB8GA1UdIwQYMBaA FAd1EUQRun6PdD2R16jhaq0s694uMF8GA1UdHwRYMFYwVKBSoFCGTmh0dHA6Ly9wa2kub3NyYW0t bGlnaHQuY29tL09TUkFNLUlTU1VJTkctQ0EtMjAxNS9DUkwvT1NSQU0tSVNTVUlORy1DQS0yMDE1 LmNybDBrBggrBgEFBQcBAQRfMF0wWwYIKwYBBQUHMAKGT2h0dHA6Ly9wa2kub3NyYW0tbGlnaHQu Y29tL09TUkFNLUlTU1VJTkctQ0EtMjAxNS9DZXJ0L09TUkFNLUlTU1VJTkctQ0EtMjAxNS5jcnQw HwYDVR0lBBgwFgYIKwYBBQUHAwQGCisGAQQBgjcKAwQwKQYJKwYBBAGCNxUKBBwwGjAKBggrBgEF BQcDBDAMBgorBgEEAYI3CgMEMBsGA1UdEQQUMBKBEFMuQmVja0Bvc3JhbS5jb20wDQYJKoZIhvcN AQELBQADggIBAAeoZQyM9u1NEpKRRDYMydLJ1wa1Y1m7rDfp5CPp0uni4qS5iXReWgIEzkhNCV5E oC0DosSOqnh2BkAkX+khNPuhLjjM/ApbFIqnnY+RD+xz3fxjx584TFmBugWHvKycYyD5NWhtD6Ej mWv6tUsxjYCv652LruxCdGJDbsaaEKP28te5dwMLD9wqSrBVU6ftbuzb9rL7IatpcBPCDkuCXSSQ lnAefbP2Y73wm1/+tbP/FxgyQjZUFR5qbXl2fMyynsrqLr3c6K7VxZs8+psbd+PiOlQnXcfGGCWR cZxr0cUZP/O861rFlE8s1OpxN5XI2pQIAzJx2toIsmHdk6hOY7t/2lYaMtqQLl2+cd2RoUMijM+1 Yi+v2WwuErdZzmgjTKht8rinng7GAuiSIQB489J4FgOEBWYne8zrl7jyuU9RYcYN9Nc5IZhK2Nfg 0xDh4tWeMWIuCg8f9ubeHOekdrg01cazDavxjaftQ25+2J5EwAWxc4ZPivOD9bkiYknSfg2iih2Y iRxUXqVq0q+qCfVDeys+MSFcu/WetN2ibvouzr+q4Aw+71j6M7FaWWpRz5FFKz40O/wAzoR2WB7u gGuT4RlAb7Yr8zM8TRpHKmrOSi19o/5qbGrPOX3u/B9UjK3LvR0n7TO6J9q0qxKveWlu6cofPQRd 2UVQoaNLB90mMIIHKDCCBRCgAwIBAgITWAAAAAXTK7hm1i4tGAAAAAAABTANBgkqhkiG9w0BAQsF ADBkMRMwEQYKCZImiZPyLGQBGRYDY29tMRswGQYKCZImiZPyLGQBGRYLb3NyYW0tbGlnaHQxEzAR BgoJkiaJk/IsZAEZFgNpbnQxGzAZBgNVBAMMEk9TUkFNIFJvb3QgQ0EgMjAxNTAeFw0xNTA5MzAx MjM2MTdaFw0yNzA5MzAxMjQ2MTdaMGcxEzARBgoJkiaJk/IsZAEZFgNjb20xGzAZBgoJkiaJk/Is ZAEZFgtvc3JhbS1saWdodDETMBEGCgmSJomT8ixkARkWA2ludDEeMBwGA1UEAwwVT1NSQU0gSXNz dWluZyBDQSAyMDE1MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAvbRnffh0KvDggawO /LfHMVmHl1fTbjzZQRjbbdUG6aKwTGeIpg7M4RXUIObssQ7sbSxuu77Vz2OFdSf5vk1fVZn8DFD8 dVB2AsYKPWZmBO+CYOvb2NCNqyLnt2/Mlk74gwTXdBgJsNjDbxs6yIfwn+rdGNt3gDwPeTiX+0Rn Ccj1NclFef00nW4kKFr2kkf+tVXMQx3pS7BQAjyuL+coQmOD5vIM+qU4dGy9ndYExTMTOPbDQaAO lx/vPXUSS1FvMJtKz//ODt/yew5RL55ZKuh6Mi7TvGTYcSH989NlXjYIYGQ0/5zfukj6CcscjInX 9W4U6NFvZL8YoVR6RLQkOTtfYa36t/iw16diSlBVeM7wq471fRXpytuGjLVtOl+oGGA7uM1QJ2OH OaXKzb6S28h8/W2urmHWMnSsBioznyio28I1PzyiwQeSe1NuMRobL0wSOTL/wljsxEkapvn4u3oW +SQCNyvXyigIYh+OaKNWFj62GclxPzoWkeT6FD6a6GS6geNyAF04N8fA/P1G/sSSCUcNdLodeEQz 17uSvIxKIFb0t7TgM40vgfwW929cv8hSoEfYQykeuPWPRc8nYkb9y6FSqpWxkXCFZRcVr826I7HY 3c2cfjFytMx4eyE5NzLV8n8jbEG0oM8c1SO1ojT4eQUgJgR2dE0OM6iJi6cCAwEAAaOCAc4wggHK MAsGA1UdDwQEAwIBhjAdBgNVHQ4EFgQUB3URRBG6fo90PZHXqOFqrSzr3i4wgaQGA1UdIASBnDCB mTCBlgYdKwYBBAGCNxUIgri6FIXRt0CEuYkzhuyuWoTnsHkwdTA8BggrBgEFBQcCAjAwHi4ATABl AGcAYQBsACAAcABvAGwAaQBjAHkAIABzAHQAYQB0AGUAbQBlAG4AdAAuMDUGCCsGAQUFBwIBFilo dHRwOi8vcGtpLm9zcmFtLWxpZ2h0LmNvbS9DUFMvaW5kZXguaHRtADASBgNVHRMBAf8ECDAGAQH/ AgEBMB8GA1UdIwQYMBaAFEF99LFK6HROcw7DQQ9plCbdSxZhMFkGA1UdHwRSMFAwTqBMoEqGSGh0 dHA6Ly9wa2kub3NyYW0tbGlnaHQuY29tL09TUkFNLVJvb3QtQ0EtMjAxNS9DUkwvT1NSQU0tUm9v dC1DQS0yMDE1LmNybDBlBggrBgEFBQcBAQRZMFcwVQYIKwYBBQUHMAKGSWh0dHA6Ly9wa2kub3Ny YW0tbGlnaHQuY29tL09TUkFNLVJvb3QtQ0EtMjAxNS9DZXJ0L09TUkFNLVJvb3QtQ0EtMjAxNS5j cnQwDQYJKoZIhvcNAQELBQADggIBACnQrysmPX41U+j/Q33kIHIGxFU0aYS0qrBmzGGGGNamqD8H 2SGy8LdCVcGeecE3XlKzZe+AnTTa1ejhHvhMJc8tHCgMLyvdSxKjJ69Rp75AaknxX15AwuFMkqLQ O+itE0PV6f3QHVdYevo2asZ3UgaQGOBFEo782qiNBDHawzuuXpXUTo4gWntTieXICIXWEenOgin1 901aoM0qzHTd8CXHdN8W7UNOE/6eCH02LofORiL2OzOAaz6aduK76KIEn3Fb2fbFAwKVIgTbvflA 9AWliukXYOSTGg9NXOyUVAE+ti4s720bYAJNrHTSbxbVpkDaWyZOhL/MsDAl3Q5/tMBbykhIy1pA 0zg5Q0QVr7B57x2Yo62nbduruNAnA0t+Q6DOrIRudaboAEeIXsQzVuUKd11o9mDOcVuetRxoS7lN 33zC3IHQajDFs8UHt4z6Cjj3EGttiS+ApUyDztgThD8bq7JSiAcFuXXD7zKmWN4TR6hKqTr9YGqA qhx/Dh7yYGUIOGAQi/EM0X1Ak73R45BopSyUm6oVj9i+w3SVvW66GxHbSUHqj8hA5Mokb9/ZC4Hn r/8CTC6MyfFJgksnMLEnhQOpCCaOzKtJ7UMnSeJHYHQUiDksIY5d3Y2T7QWDww7U95fMtGfPhqbA cF1qh4o9RYzuFWS6puXo7eRS2O1lMYIDwDCCA7wCAQEwfjBnMRMwEQYKCZImiZPyLGQBGRYDY29t MRswGQYKCZImiZPyLGQBGRYLb3NyYW0tbGlnaHQxEzARBgoJkiaJk/IsZAEZFgNpbnQxHjAcBgNV BAMMFU9TUkFNIElzc3VpbmcgQ0EgMjAxNQITGAAAxNQb5wQDKDSbIwAAAADE1DAJBgUrDgMCGgUA oIICFzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzEwMTkxMzIw MjhaMCMGCSqGSIb3DQEJBDEWBBSvWVR8fpBUbiNKF7I7MXYq5GnF3TCBjgYJKwYBBAGCNxAEMYGA MH4wZzETMBEGCgmSJomT8ixkARkWA2NvbTEbMBkGCgmSJomT8ixkARkWC29zcmFtLWxpZ2h0MRMw EQYKCZImiZPyLGQBGRYDaW50MR4wHAYDVQQDDBVPU1JBTSBJc3N1aW5nIENBIDIwMTUCExgAAMTU G+cEAyg0myMAAAAAxNQwgZAGCyqGSIb3DQEJEAILMYGAoH4wZzETMBEGCgmSJomT8ixkARkWA2Nv bTEbMBkGCgmSJomT8ixkARkWC29zcmFtLWxpZ2h0MRMwEQYKCZImiZPyLGQBGRYDaW50MR4wHAYD VQQDDBVPU1JBTSBJc3N1aW5nIENBIDIwMTUCExgAAMTUG+cEAyg0myMAAAAAxNQwgZMGCSqGSIb3 DQEJDzGBhTCBgjALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAoGCCqGSIb3DQMHMAsGCWCGSAFl AwQBAjAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAhowCwYJYIZIAWUDBAID MAsGCWCGSAFlAwQCAjALBglghkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAVOmvSt4FolGiF2Xk fOXZFzq62yAy0EJz+zKV7+27zDcIXA5AR4ezWsy8/j3EMsAaeplRR/XfVePwDlOpZ++5AjQO2S5K RMjN95JJKvfND8Qnd/cHi3NwiAfcayqR1GzZAOKTP8CUUIgZEMlGy9aTME2CZkvL9J3TE4RAKhT+ pT7lZztGVZUKX5utHi2YIPgz4oJPTrx8/LTKxuFIf3Yqol9NLg+EgwqoZ7BpOvVfrgOA+xBRrN2J JesUnAGt0FL1DlspzHgCSIY4164nPGjjQEGJdVGa+U7UI5qQx5Ko3pmcawd38aOtc3kviXW367R9 mUKwSQ4HH5ucqt/EhLjEeQAAAAAAAA== ------=_NextPart_000_0469_01D348ED.CB5B6590-- From nobody Thu Oct 19 06:51:48 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52D5A134215 for ; Thu, 19 Oct 2017 06:51:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.091 X-Spam-Level: X-Spam-Status: No, score=-0.091 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ihtfp.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 3AgjriOqaKgT for ; Thu, 19 Oct 2017 06:51:44 -0700 (PDT) Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B72B12421A for ; Thu, 19 Oct 2017 06:51:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 0C573E2064; Thu, 19 Oct 2017 09:51:13 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 14990-09; Thu, 19 Oct 2017 09:51:11 -0400 (EDT) Received: from securerf.ihtfp.org (unknown [IPv6:fe80::530:248d:f760:bb62]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail2.ihtfp.org (Postfix) with ESMTPS id 4017AE2048; Thu, 19 Oct 2017 09:51:11 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1508421071; bh=NodmxVzwEOCUHC/YGCsQqeTgU5vnVD7IvabpkmzmgdU=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=KeKXrSI44JA7hd1/vxbovjgasI4TUFFTCb3zU+rlsC6wwuSDiPJ5shTA5MFyuAJ2a iXmyww89z2JrarKbO/6mxkwIek7mtaN58pNGkRP4afXR2sIz9Ru0fQWlvCwhZiIpmL lMt1sTtkxvDdWdXqA1fuPgPzFInxGC0HXWb6nN+c= Received: (from warlord@localhost) by securerf.ihtfp.org (8.15.2/8.15.2/Submit) id v9JDpA1P015709; Thu, 19 Oct 2017 09:51:10 -0400 From: Derek Atkins To: "Beck\, Stefan" Cc: Hannes Tschofenig , "ace\@ietf.org" References: Date: Thu, 19 Oct 2017 09:51:10 -0400 In-Reply-To: (Stefan Beck's message of "Thu, 19 Oct 2017 10:56:16 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Subject: Re: [Ace] multicast 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, 19 Oct 2017 13:51:46 -0000 Hi, "Beck, Stefan" writes: [snip] > even supporting the "low-latency" requirements we need, also considering the [snip] Could you provide some more concrete numbers for your definition of "low-latency" requirements? Thanks, -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Thu Oct 19 07:13:21 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7EAD1320D9 for ; Thu, 19 Oct 2017 07:13:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.8 X-Spam-Level: X-Spam-Status: No, score=-2.8 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 lH5bk30CtyOe for ; Thu, 19 Oct 2017 07:13:18 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75B091342E1 for ; Thu, 19 Oct 2017 07:13:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v9JEDAfD020402 for ; Thu, 19 Oct 2017 16:13:10 +0200 (CEST) Received: from [192.168.217.119] (p5DC7FC78.dip0.t-ipconnect.de [93.199.252.120]) (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 3yHrVt5k6czDXbg; Thu, 19 Oct 2017 16:13:10 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carsten Bormann In-Reply-To: Date: Thu, 19 Oct 2017 16:13:10 +0200 X-Mao-Original-Outgoing-Id: 530115190.101961-c43c902048c86036006347a9e0239950 Content-Transfer-Encoding: quoted-printable Message-Id: <1C14ED3A-CF03-4FD7-B1CC-8C8B43C0BABA@tzi.org> References: To: ace X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Ace] ACE virtual interim meeting on 19th Oct to discuss certificate enrollment 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, 19 Oct 2017 14:13:20 -0000 Wow, the conferencing tool really was getting in the way today. =E2=80=94 chat messages to Everyone not being seen by everyone. = Seriously? =E2=80=94 > 30 dB difference in voice levels, with people frantically = adjusting their volume for each change in speaker. (I don=E2=80=99t = really care, as I know how to send WebEx through a dynamics compressor, = but it is amazing that a tool that has been on the market for so long = can=E2=80=99t get that simple thing right.) At least Kathleen was = audible better than yesterday. Fortunately, we did make good progress despite those obstacles. Gr=C3=BC=C3=9Fe, Carsten From nobody Thu Oct 19 07:59:24 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D16E9124B17 for ; Thu, 19 Oct 2017 07:59:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0vZg2WX9siQN for ; Thu, 19 Oct 2017 07:59:21 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0049.outbound.protection.outlook.com [104.47.2.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA13B12421A for ; Thu, 19 Oct 2017 07:59:20 -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=zL125s5drCSs+gCttVLxMKsewBvy3PwNQTINDuAZgZU=; b=YSmPgGdQrAxi9bDkCNanb6N0uguSBYbZonmr+ZzQm+d6XPlLumb2vTKcGj2rHnIRihTS+3Ydf9QEINFYUocIaqjolwYJgiP1NVUPs5OccZq7Wc+snRKH56RcezebAElHqwhInBuKny3iGwQYG5EPSH1VKzY9kGkvRGI9fK2/d7U= Received: from AM4PR0801MB2706.eurprd08.prod.outlook.com (10.167.90.148) by AM4PR0801MB2705.eurprd08.prod.outlook.com (10.167.90.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.7; Thu, 19 Oct 2017 14:59:17 +0000 Received: from AM4PR0801MB2706.eurprd08.prod.outlook.com ([fe80::6027:3e1:2bf7:68ed]) by AM4PR0801MB2706.eurprd08.prod.outlook.com ([fe80::6027:3e1:2bf7:68ed%14]) with mapi id 15.20.0077.022; Thu, 19 Oct 2017 14:59:18 +0000 From: Hannes Tschofenig To: "Beck, Stefan" , "ace@ietf.org" Thread-Topic: multicast Thread-Index: AdNIng8OaAKxM8piQaWt4FllrU9xPQAJf8iAAAMwwFAAAwsVkAABon7Q Date: Thu, 19 Oct 2017 14:59:16 +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: [91.205.194.85] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM4PR0801MB2705; 6:f/uz+1PoYqtwPW41zxdNAnL0FHCxDBOxFIHCrgz04vHooMLTP3dMYblSJYg6sKW/TjsjAyvFtZ9HdYohWCX4o1fG5FbMr+gy56jaunrPEb/FLEGZAZfwygDk0xzmluwO6N0yHY/Pq7on4miUFJ2/YeJfHEOjj2VXmhrdsRMp5xXSljTr6WrmMewvWcZXkR3D1T5sQzD91tTAA5rxgv0Bz/t4Sp8jbstggebgwoVZqojohITPysIMb8mDKkf4R+DNYzkM9jVHXhczv5EOX5BFTbyBRngxw8i7DfH/QErla7l1LXXJNsoMvYxOTyqdAH3pEkAXLUzL6sLzQTcV88WNvw==; 5:UnlmdCIX0OE8ifEvctmuVLh3yg0RDBLiUKyyJovX56ruW7pWJV+EOPA4vXufGn/Ir/t1AYmAa38XMPM+nsVtp7520UrwCCfQNodIFl45OcSeMxaZxdGYBKxLDibYBRjSqNxfQkyOYdoXoVPwrLy6tg==; 24:eWbXK+3TDVn61qXp0QyExhm40duMRfVaU1MXeiC0ptgZq56ZhQIOgrEZey/41Xq/GgjeS89Lxh0aabzYH7CcjIFojr+kvusJA28A5xHE2QY=; 7:S8UhEAXL//H9o921E0RMVKjF8ENv+8X2OiQnZoCTocUlk/nF+wIPF+kP3Ph8Vtg7Q5MSAR8BnsCOKvFRRHwkRhNhz6IQ1GpE0m79V5+IlnBeO8o1FuTgR0BBZwcUSF+l8rwWUymiOvcNXtzKyD/Lam5MCKTKTiWt95gi6f2z7ipEyBa9yel/WLWI5zuCYePSMdfTSfRMIIGGXrYfavGAlaWfsqgSIqmxxqZY+2d9LyA= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 0c21c23b-e6b7-4de3-26c9-08d51701f8e8 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(48565401081)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:AM4PR0801MB2705; x-ms-traffictypediagnostic: AM4PR0801MB2705: x-exchange-antispam-report-test: UriScan:(180628864354917); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(3002001)(6055026)(6041248)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123560025)(20161123555025)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM4PR0801MB2705; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM4PR0801MB2705; x-forefront-prvs: 0465429B7F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39860400002)(346002)(376002)(13464003)(40434004)(189002)(199003)(229853002)(102836003)(3846002)(6506006)(316002)(93886005)(8936002)(3480700004)(6116002)(33656002)(81166006)(106356001)(105586002)(189998001)(9686003)(81156014)(53546010)(8676002)(6436002)(2950100002)(110136005)(53936002)(3660700001)(25786009)(99286003)(86362001)(14454004)(2906002)(2900100001)(3280700002)(7696004)(97736004)(72206003)(7736002)(221733001)(2501003)(66066001)(101416001)(305945005)(6246003)(5890100001)(54356999)(5250100002)(478600001)(50986999)(7116003)(74316002)(68736007)(76176999)(55016002)(5660300001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR0801MB2705; H:AM4PR0801MB2706.eurprd08.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Oct 2017 14:59:16.7725 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR0801MB2705 Archived-At: Subject: Re: [Ace] multicast 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, 19 Oct 2017 14:59:23 -0000 I suspect the idea is the following: 1) First, you would decrypt the packet and validate the mac (assuming that = it is an AEAD cipher) 2) You execute the operation to meet the latency requirements. 3) Then, you can take time to verify the digital signature (outside the lat= ency requirements) Is that the idea? -----Original Message----- From: Beck, Stefan [mailto:S.Beck@osram.com] Sent: 19 October 2017 15:21 To: Hannes Tschofenig; ace@ietf.org Subject: RE: multicast Yes, correct. Stevie > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@arm.com] > Sent: Thursday, October 19, 2017 2:52 PM > To: Beck, Stefan ; ace@ietf.org > Subject: RE: multicast > > Hi Stefan, > > I am trying to understand your ideas. > > ~snip ~ > > > For multicast, my focus is on using asymmetric encryption for > authentication & integrity, and using symmetric encryption for confidentiality. > > In your view, you are sending a multicast message that will contain a digital > signature and is also encrypted using symmetric key crypto? > > Is this correct? > > 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. 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 Oct 19 08:43:15 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AD0F132153 for ; Thu, 19 Oct 2017 08:43:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=osram.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 0EXbpXZXLoE0 for ; Thu, 19 Oct 2017 08:43:11 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0069.outbound.protection.outlook.com [104.47.0.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A22BF12421A for ; Thu, 19 Oct 2017 08:43:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Osram.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=KN+0bvUwS0lKyIcAOMdt1VxgjGtRwKsq811wlS4xKKk=; b=V/weAihYtVdlc1Gh81FfSGgg0QiqUvMp3OTqkkBwlYuNyqGIy0Dxd6UbtZ28pCXC2zZ3V5TVSUyUCP34UduxY7vuXLrS021ZrsIEOOdUJVU0lANjkVSEmy2YcMZehy6ASQi2RbiJDmk2/Bu/qVXRdiVVx0Br4v+tcyMJk2rhEGg= Received: from VI1PR07MB3328.eurprd07.prod.outlook.com (10.175.244.10) by VI1PR07MB3325.eurprd07.prod.outlook.com (10.175.243.159) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.5; Thu, 19 Oct 2017 15:43:07 +0000 Received: from VI1PR07MB3328.eurprd07.prod.outlook.com ([fe80::5d7d:2995:baf9:4567]) by VI1PR07MB3328.eurprd07.prod.outlook.com ([fe80::5d7d:2995:baf9:4567%13]) with mapi id 15.20.0077.023; Thu, 19 Oct 2017 15:43:07 +0000 From: "Beck, Stefan" To: Derek Atkins CC: Hannes Tschofenig , "ace@ietf.org" Thread-Topic: [Ace] multicast Thread-Index: AdNIng8OaAKxM8piQaWt4FllrU9xPQAJf8iAAAdSH48AA6j9cA== Date: Thu, 19 Oct 2017 15:43:07 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=S.Beck@osram.com; x-originating-ip: [32.66.115.40] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR07MB3325; 6:Y+4gYCGY+LtMae9qzJqUUIlpZEwmO12rzyhngTwHtlbeKeI2WfJjKVg8nMFxF6ik9cAt6zVhYsv5PJpL1Eu9qxjhatZNGOzLM8KabpokdggCNyLQoDkoWCwouQfo8+xPPAfMndEm5RRqIlJdnK3EBe3RNfiF9kNoFEi/IZywNVnDTx/3kEbx2on4KnzRo+WiKMOuaBsDGW8Ep9vu/jyFqmtM4Oh0RGnk8dfxCv0yMYxTLgOg1UfIcfBZEsSKM9mzQQ8ZL8WdB4pROncRKw9jnK/fGuLm5d0tVFA5pEp3A3ctJS9A724OaPTQ+Sog2GCkx8M96B6EsQnDL6p7v1/6EQ==; 5:eWD99Ypr4M7sySyfALYUCYaOmLWaVhxHuslrYf0NoYlp8kJG2Obl80C2f5hif6UcvH3qAVZ4c23rvuHTka3e5gcm1WAbByVixaXVna/QW91t9ySuFPmUG4t57qzWZL3m2IYazQON5HchCI+jUew9Cw==; 24:k/eh+WMG37kbiCikC3SITUAMIVLeAM1eSl3BxN7uVDG0dVK75S4Wvi1TLLd2tDSaZwGhd4jHVh2iklf6qd6DD/BMQyOhpGEkJWTAd0KxCxU=; 7:0jXOxB+jUGsMXtS92YwstXKBZvyegbZL8L84Wld3nl2hAMfOirU7bR+GXNcgTkkgFC5a/pYoO1CMk8smK62OWjB6ktogAgql8053+IaX/bugRjvzWu7+spOWL8fL1k+pmeveMBmto06f4G4jCzwIyqfD3Flty6QspHFClMMC0/Zz/IeXyMBhvQg8ANJ7LCdUTCi9PbTw0bPYVbl+itME+TnJeTrk0oHUuVSOsHnK+UY= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: cce19b13-fdca-4cdf-b329-08d5170817fc x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(2017052603199)(49563074)(201703131423075)(201703031133081)(201702281549075); SRVR:VI1PR07MB3325; x-ms-traffictypediagnostic: VI1PR07MB3325: x-exchange-antispam-report-test: UriScan:(180628864354917)(192374486261705)(189930954265078)(45079756050767); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(102415395)(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3002001)(100000703101)(100105400095)(6041248)(20161123555025)(20161123562025)(20161123564025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:VI1PR07MB3325; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:VI1PR07MB3325; x-forefront-prvs: 0465429B7F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39860400002)(346002)(376002)(189002)(199003)(13464003)(316002)(8936002)(7696004)(97736004)(189998001)(575784001)(54906003)(86362001)(68736007)(76176999)(50986999)(5660300001)(54356999)(99936001)(6506006)(45080400002)(81166006)(7736002)(8676002)(81156014)(72206003)(966005)(478600001)(6436002)(101416001)(106356001)(102836003)(3846002)(105586002)(74316002)(5250100002)(25786009)(33656002)(2950100002)(4326008)(6916009)(305945005)(229853002)(3280700002)(9686003)(14454004)(2900100001)(6306002)(66066001)(3660700001)(99286003)(55016002)(2906002)(6246003)(53546010)(6116002)(53936002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR07MB3325; H:VI1PR07MB3328.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: osram.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0488_01D34901.B7B65090" MIME-Version: 1.0 X-OriginatorOrg: Osram.com X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Oct 2017 15:43:07.1626 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: ec1ca250-c234-4d56-a76b-7dfb9eee0c46 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB3325 Archived-At: Subject: Re: [Ace] multicast 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, 19 Oct 2017 15:43:13 -0000 ------=_NextPart_000_0488_01D34901.B7B65090 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Derek, The requirement roughly is: Assume a few light switches as multicasters and many luminaires as listeners - turning lights on / off via multicast The end-2-end processing (multicaster to encrypt&sign the message, the network to transmit the message, and the listeners to validate&decrypt the message) should not exceed ~200 ms. Stevie > -----Original Message----- > From: Derek Atkins [mailto:derek@ihtfp.com] > Sent: Thursday, October 19, 2017 3:51 PM > To: Beck, Stefan > Cc: Hannes Tschofenig ; ace@ietf.org > Subject: Re: [Ace] multicast > > Hi, > > "Beck, Stefan" writes: > > [snip] > > even supporting the "low-latency" requirements we need, also > > considering the > [snip] > > Could you provide some more concrete numbers for your definition of "low- > latency" requirements? > > Thanks, > > -derek > > -- > Derek Atkins 617-623-3745 > derek@ihtfp.com > https://emea01.safelinks.protection.outlook.com/?url=www.ihtfp.com&data=0 > 2%7C01%7C%7C015cc4c4b8da4534720808d516f87712%7Cec1ca250c2344d56a > 76b7dfb9eee0c46%7C0%7C0%7C636440178780250813&sdata=C3WzL%2FAdUd > wWhHz3aaAg0V4TZgBCWIkYqqH%2FF3tMjDw%3D&reserved=0 > Computer and Internet Security Consultant ------=_NextPart_000_0488_01D34901.B7B65090 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITQDCCBZcw ggN/oAMCAQICEH2N5rAAeSCGTQvIxSt6cDswDQYJKoZIhvcNAQELBQAwZDETMBEGCgmSJomT8ixk ARkWA2NvbTEbMBkGCgmSJomT8ixkARkWC29zcmFtLWxpZ2h0MRMwEQYKCZImiZPyLGQBGRYDaW50 MRswGQYDVQQDDBJPU1JBTSBSb290IENBIDIwMTUwHhcNMTUwOTE3MDk0NzMyWhcNNDAwOTE3MDk1 NzI2WjBkMRMwEQYKCZImiZPyLGQBGRYDY29tMRswGQYKCZImiZPyLGQBGRYLb3NyYW0tbGlnaHQx EzARBgoJkiaJk/IsZAEZFgNpbnQxGzAZBgNVBAMMEk9TUkFNIFJvb3QgQ0EgMjAxNTCCAiIwDQYJ KoZIhvcNAQEBBQADggIPADCCAgoCggIBAMPOLdsM1I8Fll2DJ5A01Y53Cbq88OH6/ZocCMhm+9Ro Ce4RHnIB+WKi8+4fTUYU3DjwgXiI3tH6YG9j9o3ahkepcaRx1arkNJCfGs8UKbHQnxVM9n5Sv3lp Qm/OyE+qwl8sA77nVvrmAiYDIXdlJajITmqMBiSS5TfS7YO7knMLOv5bzd4ihUizsNGgVIvPyowz NpsA/yYzIJJhSYCdSc9Aji5MDF4fscYaffpdaM3VoZ4gdZiVgcYrnUVR4oFsNkoja6MV3Vk9o5py 8I6ff5Dhc6ZStrjYG1Q9iIIawvvi4e4A6ISRmxw3QBUZtlvBiC8Z2g/XVJnwz91RKIT1lQPbb2Cw 88E1nRVfF1txiVbQXw+TjNnyIVcxZS/p34yHXS9/gmPVXBUx3SYqAMI9vk/mqvkDGPAkIrpILTQT XcxkJVwQukR7mSpRw4bx0bg4mxH1x6tr4HqZe5hFtQTs+VckNiXLF5xFbOjFuck5UBRbW8J3ENCA ohtR/OdOAKFrS7Y5uPLA5ENMt+Ee2LeaEmwUIIioYZuToXngaimCg6m9aIGv9ytMUgnF3+9CRsKr drVw6Er2eKnGOXyBaMOkR14loeFISsA9UL85Ib80MHLZd8t0rkIpThZSKMMS/eKpGyZMv9HLYrVZ 1TssyD8pvu4yzrHGtrtehXu2JfRm+gzdAgMBAAGjRTBDMA4GA1UdDwEB/wQEAwIBBjASBgNVHRMB Af8ECDAGAQH/AgECMB0GA1UdDgQWBBRBffSxSuh0TnMOw0EPaZQm3UsWYTANBgkqhkiG9w0BAQsF AAOCAgEAoHwKO+Sh72eofY0BSZ+h+ajR9K7PJnwrLV557s4Id1EIvfMU8geELns5FsKOcAg9ipnv PPt0EVFFGulfyKRa0OPLvz7ofpEF0Bs8LVdAbqtImf9YGAmFtf7zIEdKmtDhGdKNabwt0QbVKOEs IzbQCeKXdFQ6/s0c+aSO/I1wLOekihbY1PY0IzNzDBfIbzDdFgcQfVc+kSlV2sSKjrqpG9qGvvwL VCWSCGFC/nAkb4g4PXhmOEIfo04vaibNHYFyl4ltZiWph/mism4MM1bAvPtZM8fFc1J6Sgkir7vD XQOCpQrxFYAKTqOIhAGn0hY/AY7198X5Jeh/tCUjatDz7AHuhdBTPC+XeGMyzvj7fkVwTv3TazEo u6jpmn6b2QY+0GdVytR4R0KFFIjGvxmOH4gg7pfOwplpjzE3K11CHGsEXQwAZNPnhj/EXEqSdx3g dUX77plIcnE8TwXxoY+aa9p1JfAmKVLT3vZbT8YDm83RkN7vcyGW/NBDq2OyihORutQxuy9PpYaM Txnzp9M620XFwKJbU3D0vYvHOgYFKQy71hgn/AX3KnQ+MXgiRCy5phiSTOTc8SZzuijBV2X30hX+ NAd3M4dQq4/VnK/Zop0LYornrFK79re2RLDqm1NP/k9yAOCc0WR7lQOhFW3R0JgFSmRSMsR4PWGg afjpMSgwggZ1MIIEXaADAgECAhMYAADE1BvnBAMoNJsjAAAAAMTUMA0GCSqGSIb3DQEBCwUAMGcx EzARBgoJkiaJk/IsZAEZFgNjb20xGzAZBgoJkiaJk/IsZAEZFgtvc3JhbS1saWdodDETMBEGCgmS JomT8ixkARkWA2ludDEeMBwGA1UEAwwVT1NSQU0gSXNzdWluZyBDQSAyMDE1MB4XDTE2MTEwMzE1 NTYxMVoXDTIxMTEwMjE1NTYxMVowcjELMAkGA1UEBhMCREUxDjAMBgNVBAoMBU9TUkFNMRwwGgYD VQQLDBNPU1JBTSBHbWJILCBHZXJtYW55MRQwEgYDVQQDDAtTdGVmYW4gQmVjazEfMB0GCSqGSIb3 DQEJARYQUy5CZWNrQG9zcmFtLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKht x104jKLZgCEyi4IKs7QjFm+csCMA3g4nYkhYmv5yK4Jtw6pixicOV4KUypkejZhbWmU+vyD3iY/0 aZ+uvwyNl90CA8fWmKdC1sF7xs7MtYvaQOycf47BTkqAdlOep9iTKxKpEW9B9LchU2iBUdhdQUsy jYrvq3MzPGw5ERW9dSwsXf4M5l3pDmlfPgCAYmEdRop4eUshqh87cr8AfzTm4XEcR7pG6lOgTkFa kZAltl6U3+VHQ2PQj6pw5VRHuaqPunZVFJL8e8kNErDgPkRnY2t12qNIbvxiSri3gSDHlOJJ/kND HHzI2+yOEA70nFfFG0tY6DcXwm8qWmT6uMECAwEAAaOCAg0wggIJMAsGA1UdDwQEAwIF4DA9Bgkr BgEEAYI3FQcEMDAuBiYrBgEEAYI3FQiCuLoUhdG3QIS5iTOG7K5ahOeweYENxscDgoHuRQIBZAIB CDBEBgkqhkiG9w0BCQ8ENzA1MA4GCCqGSIb3DQMCAgIAgDAOBggqhkiG9w0DBAICAIAwBwYFKw4D AgcwCgYIKoZIhvcNAwcwHQYDVR0OBBYEFKLokmPgby7PzMPWwS913WLd8w7yMB8GA1UdIwQYMBaA FAd1EUQRun6PdD2R16jhaq0s694uMF8GA1UdHwRYMFYwVKBSoFCGTmh0dHA6Ly9wa2kub3NyYW0t bGlnaHQuY29tL09TUkFNLUlTU1VJTkctQ0EtMjAxNS9DUkwvT1NSQU0tSVNTVUlORy1DQS0yMDE1 LmNybDBrBggrBgEFBQcBAQRfMF0wWwYIKwYBBQUHMAKGT2h0dHA6Ly9wa2kub3NyYW0tbGlnaHQu Y29tL09TUkFNLUlTU1VJTkctQ0EtMjAxNS9DZXJ0L09TUkFNLUlTU1VJTkctQ0EtMjAxNS5jcnQw HwYDVR0lBBgwFgYIKwYBBQUHAwQGCisGAQQBgjcKAwQwKQYJKwYBBAGCNxUKBBwwGjAKBggrBgEF BQcDBDAMBgorBgEEAYI3CgMEMBsGA1UdEQQUMBKBEFMuQmVja0Bvc3JhbS5jb20wDQYJKoZIhvcN AQELBQADggIBAAeoZQyM9u1NEpKRRDYMydLJ1wa1Y1m7rDfp5CPp0uni4qS5iXReWgIEzkhNCV5E oC0DosSOqnh2BkAkX+khNPuhLjjM/ApbFIqnnY+RD+xz3fxjx584TFmBugWHvKycYyD5NWhtD6Ej mWv6tUsxjYCv652LruxCdGJDbsaaEKP28te5dwMLD9wqSrBVU6ftbuzb9rL7IatpcBPCDkuCXSSQ lnAefbP2Y73wm1/+tbP/FxgyQjZUFR5qbXl2fMyynsrqLr3c6K7VxZs8+psbd+PiOlQnXcfGGCWR cZxr0cUZP/O861rFlE8s1OpxN5XI2pQIAzJx2toIsmHdk6hOY7t/2lYaMtqQLl2+cd2RoUMijM+1 Yi+v2WwuErdZzmgjTKht8rinng7GAuiSIQB489J4FgOEBWYne8zrl7jyuU9RYcYN9Nc5IZhK2Nfg 0xDh4tWeMWIuCg8f9ubeHOekdrg01cazDavxjaftQ25+2J5EwAWxc4ZPivOD9bkiYknSfg2iih2Y iRxUXqVq0q+qCfVDeys+MSFcu/WetN2ibvouzr+q4Aw+71j6M7FaWWpRz5FFKz40O/wAzoR2WB7u gGuT4RlAb7Yr8zM8TRpHKmrOSi19o/5qbGrPOX3u/B9UjK3LvR0n7TO6J9q0qxKveWlu6cofPQRd 2UVQoaNLB90mMIIHKDCCBRCgAwIBAgITWAAAAAXTK7hm1i4tGAAAAAAABTANBgkqhkiG9w0BAQsF ADBkMRMwEQYKCZImiZPyLGQBGRYDY29tMRswGQYKCZImiZPyLGQBGRYLb3NyYW0tbGlnaHQxEzAR BgoJkiaJk/IsZAEZFgNpbnQxGzAZBgNVBAMMEk9TUkFNIFJvb3QgQ0EgMjAxNTAeFw0xNTA5MzAx MjM2MTdaFw0yNzA5MzAxMjQ2MTdaMGcxEzARBgoJkiaJk/IsZAEZFgNjb20xGzAZBgoJkiaJk/Is ZAEZFgtvc3JhbS1saWdodDETMBEGCgmSJomT8ixkARkWA2ludDEeMBwGA1UEAwwVT1NSQU0gSXNz dWluZyBDQSAyMDE1MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAvbRnffh0KvDggawO /LfHMVmHl1fTbjzZQRjbbdUG6aKwTGeIpg7M4RXUIObssQ7sbSxuu77Vz2OFdSf5vk1fVZn8DFD8 dVB2AsYKPWZmBO+CYOvb2NCNqyLnt2/Mlk74gwTXdBgJsNjDbxs6yIfwn+rdGNt3gDwPeTiX+0Rn Ccj1NclFef00nW4kKFr2kkf+tVXMQx3pS7BQAjyuL+coQmOD5vIM+qU4dGy9ndYExTMTOPbDQaAO lx/vPXUSS1FvMJtKz//ODt/yew5RL55ZKuh6Mi7TvGTYcSH989NlXjYIYGQ0/5zfukj6CcscjInX 9W4U6NFvZL8YoVR6RLQkOTtfYa36t/iw16diSlBVeM7wq471fRXpytuGjLVtOl+oGGA7uM1QJ2OH OaXKzb6S28h8/W2urmHWMnSsBioznyio28I1PzyiwQeSe1NuMRobL0wSOTL/wljsxEkapvn4u3oW +SQCNyvXyigIYh+OaKNWFj62GclxPzoWkeT6FD6a6GS6geNyAF04N8fA/P1G/sSSCUcNdLodeEQz 17uSvIxKIFb0t7TgM40vgfwW929cv8hSoEfYQykeuPWPRc8nYkb9y6FSqpWxkXCFZRcVr826I7HY 3c2cfjFytMx4eyE5NzLV8n8jbEG0oM8c1SO1ojT4eQUgJgR2dE0OM6iJi6cCAwEAAaOCAc4wggHK MAsGA1UdDwQEAwIBhjAdBgNVHQ4EFgQUB3URRBG6fo90PZHXqOFqrSzr3i4wgaQGA1UdIASBnDCB mTCBlgYdKwYBBAGCNxUIgri6FIXRt0CEuYkzhuyuWoTnsHkwdTA8BggrBgEFBQcCAjAwHi4ATABl AGcAYQBsACAAcABvAGwAaQBjAHkAIABzAHQAYQB0AGUAbQBlAG4AdAAuMDUGCCsGAQUFBwIBFilo dHRwOi8vcGtpLm9zcmFtLWxpZ2h0LmNvbS9DUFMvaW5kZXguaHRtADASBgNVHRMBAf8ECDAGAQH/ AgEBMB8GA1UdIwQYMBaAFEF99LFK6HROcw7DQQ9plCbdSxZhMFkGA1UdHwRSMFAwTqBMoEqGSGh0 dHA6Ly9wa2kub3NyYW0tbGlnaHQuY29tL09TUkFNLVJvb3QtQ0EtMjAxNS9DUkwvT1NSQU0tUm9v dC1DQS0yMDE1LmNybDBlBggrBgEFBQcBAQRZMFcwVQYIKwYBBQUHMAKGSWh0dHA6Ly9wa2kub3Ny YW0tbGlnaHQuY29tL09TUkFNLVJvb3QtQ0EtMjAxNS9DZXJ0L09TUkFNLVJvb3QtQ0EtMjAxNS5j cnQwDQYJKoZIhvcNAQELBQADggIBACnQrysmPX41U+j/Q33kIHIGxFU0aYS0qrBmzGGGGNamqD8H 2SGy8LdCVcGeecE3XlKzZe+AnTTa1ejhHvhMJc8tHCgMLyvdSxKjJ69Rp75AaknxX15AwuFMkqLQ O+itE0PV6f3QHVdYevo2asZ3UgaQGOBFEo782qiNBDHawzuuXpXUTo4gWntTieXICIXWEenOgin1 901aoM0qzHTd8CXHdN8W7UNOE/6eCH02LofORiL2OzOAaz6aduK76KIEn3Fb2fbFAwKVIgTbvflA 9AWliukXYOSTGg9NXOyUVAE+ti4s720bYAJNrHTSbxbVpkDaWyZOhL/MsDAl3Q5/tMBbykhIy1pA 0zg5Q0QVr7B57x2Yo62nbduruNAnA0t+Q6DOrIRudaboAEeIXsQzVuUKd11o9mDOcVuetRxoS7lN 33zC3IHQajDFs8UHt4z6Cjj3EGttiS+ApUyDztgThD8bq7JSiAcFuXXD7zKmWN4TR6hKqTr9YGqA qhx/Dh7yYGUIOGAQi/EM0X1Ak73R45BopSyUm6oVj9i+w3SVvW66GxHbSUHqj8hA5Mokb9/ZC4Hn r/8CTC6MyfFJgksnMLEnhQOpCCaOzKtJ7UMnSeJHYHQUiDksIY5d3Y2T7QWDww7U95fMtGfPhqbA cF1qh4o9RYzuFWS6puXo7eRS2O1lMYIDwDCCA7wCAQEwfjBnMRMwEQYKCZImiZPyLGQBGRYDY29t MRswGQYKCZImiZPyLGQBGRYLb3NyYW0tbGlnaHQxEzARBgoJkiaJk/IsZAEZFgNpbnQxHjAcBgNV BAMMFU9TUkFNIElzc3VpbmcgQ0EgMjAxNQITGAAAxNQb5wQDKDSbIwAAAADE1DAJBgUrDgMCGgUA oIICFzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzEwMTkxNTQz MDRaMCMGCSqGSIb3DQEJBDEWBBRuJJCvLFuAtjsKPihGKNlBmmBOazCBjgYJKwYBBAGCNxAEMYGA MH4wZzETMBEGCgmSJomT8ixkARkWA2NvbTEbMBkGCgmSJomT8ixkARkWC29zcmFtLWxpZ2h0MRMw EQYKCZImiZPyLGQBGRYDaW50MR4wHAYDVQQDDBVPU1JBTSBJc3N1aW5nIENBIDIwMTUCExgAAMTU G+cEAyg0myMAAAAAxNQwgZAGCyqGSIb3DQEJEAILMYGAoH4wZzETMBEGCgmSJomT8ixkARkWA2Nv bTEbMBkGCgmSJomT8ixkARkWC29zcmFtLWxpZ2h0MRMwEQYKCZImiZPyLGQBGRYDaW50MR4wHAYD VQQDDBVPU1JBTSBJc3N1aW5nIENBIDIwMTUCExgAAMTUG+cEAyg0myMAAAAAxNQwgZMGCSqGSIb3 DQEJDzGBhTCBgjALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAoGCCqGSIb3DQMHMAsGCWCGSAFl AwQBAjAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAhowCwYJYIZIAWUDBAID MAsGCWCGSAFlAwQCAjALBglghkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAnudLZJKe2FSWxVlo uc4e7jUbotyjDR1GVb0Qqg1HQZzmj1wtOpctNSXtUfjbE1p8rwjZudXU4A8PpsgDdOrZQxaGK1cI 0YqXCzXaI9irSYT+CFxomHZlmmN/xQPNtKLkGhNOwaM48yGNQJ4W4yZ484zrmVmSKAI9uj/9MRfC Wh2Z7n1yYVa2bf261V6x/nIiOlvDWiNHIrWcF/yKq9jqUbbda5w06O5/wniwaGXuH62uFuxotJ6e YQYbiwi4gM/IVa77R3KaveFmQ3UG8uZ6A/INgM1mEKsvvpqCLwkFpomvU6mWZdmdkQvlRTeg/DIL ELBY07Jiey6fx0ZY6J9EcAAAAAAAAA== ------=_NextPart_000_0488_01D34901.B7B65090-- From nobody Thu Oct 19 08:56:02 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94B5413263F for ; Thu, 19 Oct 2017 08:56:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20WJH1pC6XfO for ; Thu, 19 Oct 2017 08:55:58 -0700 (PDT) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50053.outbound.protection.outlook.com [40.107.5.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 42ADB132D67 for ; Thu, 19 Oct 2017 08:55:57 -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=cFoLAlIKR8jZUKV134SMLCHmDvwq0BeDtMvj0e3AzD0=; b=r/imrX5mUUTQc1Vx3+s0clbCSVyA1jaAqYyFGnu5CtD8gpCzQR+3ntbgpnGm0PUfJ36ZUqZ1idw962+/i1WQ3ahZYVLCqoed/LezNGE6Z6MWdz0A1Rgr/s2Qo2grU+0Xf/0CWmW4+8KG4j0WKh0ArDnY6M/8HzKSYOzDTV/MAL4= Received: from AM4PR0801MB2706.eurprd08.prod.outlook.com (10.167.90.148) by AM4PR0801MB2706.eurprd08.prod.outlook.com (10.167.90.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.7; Thu, 19 Oct 2017 15:55:55 +0000 Received: from AM4PR0801MB2706.eurprd08.prod.outlook.com ([fe80::6027:3e1:2bf7:68ed]) by AM4PR0801MB2706.eurprd08.prod.outlook.com ([fe80::6027:3e1:2bf7:68ed%14]) with mapi id 15.20.0077.022; Thu, 19 Oct 2017 15:55:55 +0000 From: Hannes Tschofenig To: "ace@ietf.org" Thread-Topic: draft-ietf-ace-cbor-web-token-08 - CWT CBOR Tag Thread-Index: AdNI8Zy0N4S3uIvORKmAfwXOEGgdYw== Date: Thu, 19 Oct 2017 15:55:55 +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: [91.205.194.85] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM4PR0801MB2706; 6:su+Kb/QeToZX2940RSQrVc/iH6QiMQcA8836B+JRtycCp06LMxi1MzJhXgZN87OOpTgVhFOP2CidIXSVJgyvsfmdQbPx6reVc/l7u76+G06rURekIwf4n77OQ6PUEQhcG31z1VWVyuaP58/PotiHhI/nDpLzsSjF/fV/eSkyjrksYiWgqADpHVsOyuL3V+t1xjaYHWNPTOf4ugd5p7G9UNbkHT4y7BVvmTO/hdgH9LWNvf3LbRsU3DNptPNW/yilMLKOOws06I1Gs3mTfGEXjuBmSQstNPv4ssUCUIssbUJDC25ycuC+j9a8mRGXLo0eeuKh7ZuxgyxWpEWZrU1vOQ==; 5:7QHIVqQYCSbA3W7q/XtNR3oWOxvhRXqJtWZTATD1zhGr1N72DK1l14QJPZrv4Wyvuv1ZbvQi36EF0ZdEDIZTPrHZW/govCkhy73qsopt27CxvypbznATyin3c9jg4/1bZBS2bTF1xG2V3WWBPu771g==; 24:4FAOxybg58EM6Ol8Q05BHOQJLFIdvGBtFjpi+5ZIkHCuEqtCESq40QxFZKBcpBvBC4Ozta+YDP/revrb/TlBnyBeeUbdYTSrxZXe0o+C37Q=; 7:+X8ICSBzXDbhKUti2ale//Nk6CIfjNvrgBxKJ4KAjYDDB4S5RB2hcivGu5DrMqSORo624CM4b2dGOhgNal7oqMcZ8UVE6ZPBhyzPyy9npF4UihKamRUAw5Wu5nGNRZ7E+mJV8rv2G0nJ5sfnANpCTcr8fcQHOuw5w0VLz6uwpCz3IlUMROle0Do80XSVRKIXc39zVgiOMxniJejoQ8Yoc2t0FpmVcS8Kx+QdTK7Abso= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: dc1c94f3-4136-4bb7-64a3-08d51709e1d5 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(48565401081)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:AM4PR0801MB2706; x-ms-traffictypediagnostic: AM4PR0801MB2706: x-exchange-antispam-report-test: UriScan:(21748063052155); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(100000703101)(100105400095)(10201501046)(3002001)(93006095)(93001095)(6055026)(6041248)(20161123560025)(20161123564025)(20161123562025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM4PR0801MB2706; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM4PR0801MB2706; x-forefront-prvs: 0465429B7F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(376002)(39860400002)(346002)(40434004)(199003)(189002)(53754006)(86362001)(7696004)(5630700001)(25786009)(2351001)(68736007)(5250100002)(6916009)(6436002)(2900100001)(66066001)(6506006)(5890100001)(2501003)(97736004)(33656002)(74316002)(8676002)(81156014)(3660700001)(316002)(8936002)(81166006)(72206003)(9686003)(478600001)(50986999)(99286003)(230783001)(3846002)(790700001)(102836003)(189998001)(5640700003)(1730700003)(54356999)(6306002)(54896002)(55016002)(53936002)(2906002)(106356001)(105586002)(5660300001)(7736002)(14454004)(3280700002)(101416001)(6116002)(217873001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR0801MB2706; H:AM4PR0801MB2706.eurprd08.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AM4PR0801MB2706913DEA4FB35D62F4AB10FA420AM4PR0801MB2706_" MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Oct 2017 15:55:55.2858 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR0801MB2706 Archived-At: Subject: [Ace] draft-ietf-ace-cbor-web-token-08 - CWT CBOR Tag 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, 19 Oct 2017 15:56:01 -0000 --_000_AM4PR0801MB2706913DEA4FB35D62F4AB10FA420AM4PR0801MB2706_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, In Section 6 of draft-ietf-ace-cbor-web-token-08 we describe two ways to de= termine whether the CBOR data structure is a CWT. I wonder whether it is better to settle on one approach only. Do folks have practical experience with this feature? 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_AM4PR0801MB2706913DEA4FB35D62F4AB10FA420AM4PR0801MB2706_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

In Section 6 of draft-ietf-ace-cbor-web-token-08 we = describe two ways to determine whether the CBOR data structure is a CWT.

I wonder whether it is better to settle on one appro= ach only.

 

Do folks have practical experience with this feature= ?

 

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_AM4PR0801MB2706913DEA4FB35D62F4AB10FA420AM4PR0801MB2706_-- From nobody Thu Oct 19 09:38:05 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3A57132D8A for ; Thu, 19 Oct 2017 09:38:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.801 X-Spam-Level: X-Spam-Status: No, score=-0.801 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 caFjteeAaYAe for ; Thu, 19 Oct 2017 09:38:02 -0700 (PDT) Received: from resqmta-ch2-08v.sys.comcast.net (resqmta-ch2-08v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:40]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B33913263F for ; Thu, 19 Oct 2017 09:38:02 -0700 (PDT) Received: from resomta-ch2-02v.sys.comcast.net ([69.252.207.98]) by resqmta-ch2-08v.sys.comcast.net with ESMTP id 5Dp3ejy5qeNrg5DpZePRP8; Thu, 19 Oct 2017 16:38:01 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1508431081; bh=O2pmqE1vjnbc8EWZfn2v4Tqhcik5YFceB13ZXcdkf/E=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=M/NRmV7QrU/Qo3ZiPyREYl2qIML/ikG4LCDB3k/006KsO/Jq31Yp7NtuDTh/NEYar 63R+G/gHT/WF2uw3/JVL8obOY3aB3oRcBwHZvKMmIzh0cz/ejNvk0ePZo7QOUj7y+D H+qA49XGSky3xdcDtOu+Flmu1nlyvWHRjjsCigom3n4AA/UyFmjyU1k0kbxDgwepK1 CuYr3unR/hOuGEcM/ONYexf+vstFYNALJwqIFYxvCanioeZ8xZftBOieiRgABR/Cln NC+9SfQ2BE3eeQA5s6/O4QTVbjU8+y2/d4yO1jPJk4y9lr4NsJjcekpllUgfxEDdFA yPiONvhpKXmRQ== Received: from [192.168.1.112] ([69.140.114.191]) by resomta-ch2-02v.sys.comcast.net with SMTP id 5DpZeWnwPN5w45DpZebbbB; Thu, 19 Oct 2017 16:38:01 +0000 To: ace@ietf.org References: From: Michael StJohns Message-ID: Date: Thu, 19 Oct 2017 12:37:59 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.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: MS4wfIUpv9Rl7Uf2l/AKJ/0neakiaqtc8l32aZB6j5W1YdAQGOq9joRcXdMgzQfS+SfeCJOPj3gOCi7zsqdaX1PjbpHaTm95I/vJnBuv9CyXX8JLMbofy+Wk U9uTKdIZK2lUcWow7ElTQkBPO4DfGQ7bnW0cMzuaQkQgmXdJdLpI+Lzd Archived-At: Subject: Re: [Ace] multicast 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, 19 Oct 2017 16:38:04 -0000 On 10/19/2017 10:59 AM, Hannes Tschofenig wrote: > I suspect the idea is the following: > > 1) First, you would decrypt the packet and validate the mac (assuming that it is an AEAD cipher) > 2) You execute the operation to meet the latency requirements. > 3) Then, you can take time to verify the digital signature (outside the latency requirements) > > Is that the idea? > It can't possibly be.   What do you do if the digital signature doesn't verify?  Reverse the operation?   Flicker the lights?  Go back to the original levels?  Flash "OOPS" in morse code? You need to verify the signature in advance of doing an operation authenticated and authorized by that signature.... Mike From nobody Thu Oct 19 09:41:30 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 693D1132F6C for ; Thu, 19 Oct 2017 09:41:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=augustcellars.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jWGUlRnTcr7g for ; Thu, 19 Oct 2017 09:41:27 -0700 (PDT) Received: from mail4.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F528132D96 for ; Thu, 19 Oct 2017 09:41:27 -0700 (PDT) Content-Type: multipart/alternative; boundary="----=_NextPart_000_008B_01D348BE.6B41D920" Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1508431280; h=from:subject:to:date:message-id; bh=GU6zNdCLGTYWF9XLROzXB4lW5yOezCXWgalq+AeCI7Y=; b=KyYXfEKO9F4uZq7yMio5d1iw1NS5PJktOUWpcG+qucPxg1LNp/Pec3bSh2iUXDbT/N1EQ9zn4Bj rz6i1vhX/eiUja4u49W29t7n6g5Haqx7+hlAJ0sKo9Tk5p3ZRIomZ4OUqVexDQCQ6kfMleNj2uabJ arp1H/2Q+ma9NWJGdYultR2Xqw62OhJa/jpFJkb1iHi8JImPlorCh9q8cSf9o/v4FX0hr3ZjrcA2u PQTTiikmm9PTkmONQORLGN9hnEsT0ver23iq3nxWE4g0MVKsrg3AoTRmRkYBF6sFwrcOH6xyOXJPW SOxsGiUw+X4sZ9CMMG19tVKraXEGmmvojubw== Received: from mail2.augustcellars.com (192.168.1.201) by mail4.augustcellars.com (192.168.1.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 19 Oct 2017 09:41:20 -0700 Received: from Hebrews (192.168.1.162) by mail2.augustcellars.com (192.168.1.201) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 19 Oct 2017 09:40:26 -0700 From: Jim Schaad To: 'Hannes Tschofenig' , References: In-Reply-To: Date: Thu, 19 Oct 2017 09:41:17 -0700 Message-ID: <008a01d348f9$179a96a0$46cfc3e0$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQGLsOqKFomdfT9ZLF1VPxn9X86wS6N6j8rw X-Originating-IP: [192.168.1.162] Archived-At: Subject: Re: [Ace] draft-ietf-ace-cbor-web-token-08 - CWT CBOR Tag 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, 19 Oct 2017 16:41:29 -0000 ------=_NextPart_000_008B_01D348BE.6B41D920 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I don't have any problems with what is here. It boils down to 1. I already know that this is going to be a CWT so I save a byte. 2. I don't know so I waste a tag byte in that case. Most of the time it is going to be the first case, but my code is agnostic about this and will remove the tag if it is the correct value. In either case it then makes sure that what follows is a map. Jim From: Ace [mailto:ace-bounces@ietf.org] On Behalf Of Hannes Tschofenig Sent: Thursday, October 19, 2017 8:56 AM To: ace@ietf.org Subject: [Ace] draft-ietf-ace-cbor-web-token-08 - CWT CBOR Tag Hi all, In Section 6 of draft-ietf-ace-cbor-web-token-08 we describe two ways to determine whether the CBOR data structure is a CWT. I wonder whether it is better to settle on one approach only. Do folks have practical experience with this feature? 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. ------=_NextPart_000_008B_01D348BE.6B41D920 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I = don’t have any problems with what is here.  It boils down to =

 

  1. I already know that = this is going to be a CWT so I save a byte.
  2. I don’t know so I waste a tag byte in that = case.

 

Most of the time it is going to be the first case, but = my code is agnostic about this and will remove the tag if it is the = correct value.  In either case it then makes sure that what follows = is a map.

 

Jim

 

 

From: Ace = [mailto:ace-bounces@ietf.org] On Behalf Of Hannes = Tschofenig
Sent: Thursday, October 19, 2017 8:56 = AM
To: ace@ietf.org
Subject: [Ace] = draft-ietf-ace-cbor-web-token-08 - CWT CBOR = Tag

 

Hi all,

 

In Section 6 of draft-ietf-ace-cbor-web-token-08 we = describe two ways to determine whether the CBOR data structure is a CWT. =

I wonder = whether it is better to settle on one approach only. =

 

Do folks have practical experience with this feature? =

 

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. =

------=_NextPart_000_008B_01D348BE.6B41D920-- From nobody Thu Oct 19 10:05:22 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A48E132320 for ; Thu, 19 Oct 2017 10:05:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XVmxOMRoRAZe for ; Thu, 19 Oct 2017 10:05: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 6E8DF134222 for ; Thu, 19 Oct 2017 10:05: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 v9JH54FU009157; Thu, 19 Oct 2017 19:05:04 +0200 (CEST) Received: from [192.168.217.119] (p5DC7FC78.dip0.t-ipconnect.de [93.199.252.120]) (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 3yHwKD36ZbzDXdm; Thu, 19 Oct 2017 19:05:04 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carsten Bormann In-Reply-To: <008a01d348f9$179a96a0$46cfc3e0$@augustcellars.com> Date: Thu, 19 Oct 2017 19:05:03 +0200 Cc: Hannes Tschofenig , ace@ietf.org X-Mao-Original-Outgoing-Id: 530125503.669838-806d1c5dcbcbfb1eeabaa7b92b38b889 Content-Transfer-Encoding: quoted-printable Message-Id: References: <008a01d348f9$179a96a0$46cfc3e0$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Ace] draft-ietf-ace-cbor-web-token-08 - CWT CBOR Tag 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, 19 Oct 2017 17:05:21 -0000 On Oct 19, 2017, at 18:41, Jim Schaad wrote: >=20 > =E2=80=A2 I already know that this is going to be a CWT so I = save a byte. > =E2=80=A2 I don=E2=80=99t know so I waste a tag byte in that = case. Right. In REST protocols, we usually have a media type, so we don=E2=80=99= t need the CBOR Tag. Within some other data structures, or in legacy protocols such as MQTT, = we may not have that, so a tag is a good single standard way to indicate = this. (Does the latter case need to be a single byte [which is then preceded = by 0xd8, by the way]? Maybe that would not have been necessary(*), but = then CWTs are going to be rather common. =20 And 61 is a =E2=80=9C=3D=E2=80=9C, which is cool for our hexdump reading = population :-) Gr=C3=BC=C3=9Fe, Carsten (*) The number is already assigned, BTW. From nobody Thu Oct 19 12:29:03 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05433132D89 for ; Thu, 19 Oct 2017 12:29:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kd-u17GpMsN5 for ; Thu, 19 Oct 2017 12:28:59 -0700 (PDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0126.outbound.protection.outlook.com [104.47.40.126]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B425913207A for ; Thu, 19 Oct 2017 12:28:59 -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=KzffyK1VsNUJBZ4nq/Ff46jP3kSpoRZPhu7HBLARCX8=; b=mFRxlU5b9Hr+ibznbZO441vr2AaorUhESfm/kwqFyRpjAeOPS6YzWmJLaWmOzFlOXuE5r6cV0Hai14n6En5OQ2V0hcnbAShesIR0kx4zSY0juAWxkPHstO5Vjx21MyRBwWgzpN22hECe+AUjkhM1QmepDTAiJnmwzWWopA3iiyc= Received: from CY4PR21MB0504.namprd21.prod.outlook.com (10.172.122.14) by CY4PR21MB0790.namprd21.prod.outlook.com (10.175.121.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.178.1; Thu, 19 Oct 2017 19:28:57 +0000 Received: from CY4PR21MB0504.namprd21.prod.outlook.com ([10.172.122.14]) by CY4PR21MB0504.namprd21.prod.outlook.com ([10.172.122.14]) with mapi id 15.20.0178.002; Thu, 19 Oct 2017 19:28:57 +0000 From: Mike Jones To: Carsten Bormann , Jim Schaad CC: Hannes Tschofenig , "ace@ietf.org" Thread-Topic: [Ace] draft-ietf-ace-cbor-web-token-08 - CWT CBOR Tag Thread-Index: AdNI8Zy0N4S3uIvORKmAfwXOEGgdYwAB3jiAAADUfYAABPnwkA== Date: Thu, 19 Oct 2017 19:28:57 +0000 Message-ID: References: <008a01d348f9$179a96a0$46cfc3e0$@augustcellars.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.71.18.60] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR21MB0790; 6:u+K9uPl6Kk4fDnbv+S9fR6JMGDRQ83J+qGDIOSkSLS4ddmvwgvpW7TSZHVdWycm4Dz32wDOl2z3TzwgTXyjZ4a0ieSv88wTCfJsZwoJvj2bsqLXJS1Nn7twe6Ql9t9pODELsJLu1FlzZ55ufe/vy4aVS4vSlx1CREUPtJIOzv9jDU6BYCaSYJ4ddIe4HX4uG7OTDwuFpYi77CGoFYme2hNcIOsxzIRGiVZKtBaD4UcTszyPPOCxq2pMXp8MplXd34ixJG6bXKchkbnwbtT120ZxgIM3NrDXLcvIK+C693gYmvS5Xvh/XTJGhQ9vDmbrBC65bZ1GQAgtFZ0vVMrLd6OEuO/vBP3Y7F/Q2JolY6YQ=; 5:sy3NQVHFkZhn2AkfA6/bVrrYa0D4STVz4UCqJ1EZ+BNPkrjBPH2GVv+6pB8tvC5fwmqpNhkPh01Zgoj8P4YXpN9h2o+agotWIjzKKWD7NSor3XXcRsBUmZzXadANV7xunfijpV9JdZg/VgTnpX16EcohBD30FjHZwripEjCrwJ4=; 24:zBDvuohzrbgg/NG/Zvy6+5RcW0ROCu33Wf3MhbhYAQr2Xm7VBC1XJCrdA06Cbcesx4+6SqTmIGSCPmm9KP/SjphnJ83Coq95H+Gt4eLnFjQ=; 7:cnLrTCLFfOW+EaLYC0TfxoTmPrcH76yGS8nlqRRYAhJfOaU+MC+DOjLsEO1EatlGbblO1ar1vFq/zFKa14VJOg7h1t5YFHmBBAHEi0igVV8BN0eUKd+Sg+ldnznBJiz7lCr/ldkWMZ6+CgB3OAFVFyYn24iFGvyXXQqROlONPLoiCRw/pD6fPOrzTnxJx6QRvKMnrD7OQftjnUwy5yiyO/LjZr5NAkf2Lo0qpybKCDbxu0tHh80j4sHrWp6+eVTO x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 9301f46d-f854-4ed6-6c80-08d51727a4cb x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254172)(48565401081)(4534020)(4602075)(4627075)(201703031133081)(201702281549075)(2017052603229)(201703131423095); SRVR:CY4PR21MB0790; x-ms-traffictypediagnostic: CY4PR21MB0790: x-ld-processed: 72f988bf-86f1-41af-91ab-2d7cd011db47,ExtAddr x-exchange-antispam-report-test: UriScan:(180628864354917); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(2401047)(5005006)(8121501046)(93006095)(93001095)(3002001)(100000703101)(100105400095)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123555025)(20161123558100)(20161123564025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR21MB0790; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR21MB0790; x-forefront-prvs: 0465429B7F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(376002)(39860400002)(346002)(47760400005)(189002)(199003)(13464003)(24454002)(33656002)(54356999)(25786009)(53546010)(50986999)(76176999)(101416001)(2950100002)(5660300001)(7696004)(66066001)(4326008)(14454004)(6116002)(3846002)(3280700002)(229853002)(2906002)(77096006)(8990500004)(6436002)(6506006)(68736007)(6246003)(53936002)(102836003)(81166006)(54906003)(99286003)(105586002)(189998001)(86362001)(6306002)(55016002)(10090500001)(106356001)(9686003)(110136005)(72206003)(316002)(8676002)(478600001)(22452003)(86612001)(966005)(7736002)(10290500003)(230783001)(8936002)(305945005)(81156014)(74316002)(2900100001)(3660700001)(97736004)(217873001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0790; H:CY4PR21MB0504.namprd21.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; 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; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 9301f46d-f854-4ed6-6c80-08d51727a4cb X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Oct 2017 19:28:57.7480 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0790 Archived-At: Subject: Re: [Ace] draft-ietf-ace-cbor-web-token-08 - CWT CBOR Tag 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, 19 Oct 2017 19:29:02 -0000 SSBhbHNvIGFncmVlIHRoYXQgdGhlIHNwZWMgYWxyZWFkeSBoYXMgdGhpcyByaWdodC4gIFR5cGlj YWxseSBubyB0YWcgd2lsbCBiZSBuZWVkZWQgYmVjYXVzZSB0aGUgYXBwbGljYXRpb24ga25vd3Mg dGhlIGRhdGEgc3RydWN0dXJlIGlzIGEgQ1dUIGZyb20gY29udGV4dC4gIFRoZSB0YWcgaXMgYXZh aWxhYmxlIGZvciBhbnkgdXNlIGNhc2VzIHdoZXJlIGl0J3MgbmVlZGVkIHRvIHJlc29sdmUgYW1i aWd1aXR5IHRoYXQgbWlnaHQgb3RoZXJ3aXNlIGJlIHByZXNlbnQuDQoNCgkJCQktLSBNaWtlDQoN Ci0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBBY2UgW21haWx0bzphY2UtYm91bmNl c0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIENhcnN0ZW4gQm9ybWFubg0KU2VudDogVGh1cnNkYXks IE9jdG9iZXIgMTksIDIwMTcgMTA6MDUgQU0NClRvOiBKaW0gU2NoYWFkIDxpZXRmQGF1Z3VzdGNl bGxhcnMuY29tPg0KQ2M6IEhhbm5lcyBUc2Nob2ZlbmlnIDxIYW5uZXMuVHNjaG9mZW5pZ0Bhcm0u Y29tPjsgYWNlQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW0FjZV0gZHJhZnQtaWV0Zi1hY2UtY2Jv ci13ZWItdG9rZW4tMDggLSBDV1QgQ0JPUiBUYWcNCg0KT24gT2N0IDE5LCAyMDE3LCBhdCAxODo0 MSwgSmltIFNjaGFhZCA8aWV0ZkBhdWd1c3RjZWxsYXJzLmNvbT4gd3JvdGU6DQo+IA0KPiAJ4oCi IEkgYWxyZWFkeSBrbm93IHRoYXQgdGhpcyBpcyBnb2luZyB0byBiZSBhIENXVCBzbyBJIHNhdmUg YSBieXRlLg0KPiAJ4oCiIEkgZG9u4oCZdCBrbm93IHNvIEkgd2FzdGUgYSB0YWcgYnl0ZSBpbiB0 aGF0IGNhc2UuDQoNClJpZ2h0LiAgSW4gUkVTVCBwcm90b2NvbHMsIHdlIHVzdWFsbHkgaGF2ZSBh IG1lZGlhIHR5cGUsIHNvIHdlIGRvbuKAmXQgbmVlZCB0aGUgQ0JPUiBUYWcuDQpXaXRoaW4gc29t ZSBvdGhlciBkYXRhIHN0cnVjdHVyZXMsIG9yIGluIGxlZ2FjeSBwcm90b2NvbHMgc3VjaCBhcyBN UVRULCB3ZSBtYXkgbm90IGhhdmUgdGhhdCwgc28gYSB0YWcgaXMgYSBnb29kIHNpbmdsZSBzdGFu ZGFyZCB3YXkgdG8gaW5kaWNhdGUgdGhpcy4NCg0KKERvZXMgdGhlIGxhdHRlciBjYXNlIG5lZWQg dG8gYmUgYSBzaW5nbGUgYnl0ZSBbd2hpY2ggaXMgdGhlbiBwcmVjZWRlZCBieSAweGQ4LCBieSB0 aGUgd2F5XT8gIE1heWJlIHRoYXQgd291bGQgbm90IGhhdmUgYmVlbiBuZWNlc3NhcnkoKiksIGJ1 dCB0aGVuIENXVHMgYXJlIGdvaW5nIHRvIGJlIHJhdGhlciBjb21tb24uICANCkFuZCA2MSBpcyBh IOKAnD3igJwsIHdoaWNoIGlzIGNvb2wgZm9yIG91ciBoZXhkdW1wIHJlYWRpbmcgcG9wdWxhdGlv biA6LSkNCg0KR3LDvMOfZSwgQ2Fyc3Rlbg0KDQooKikgVGhlIG51bWJlciBpcyBhbHJlYWR5IGFz c2lnbmVkLCBCVFcuDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQpBY2UgbWFpbGluZyBsaXN0DQpBY2VAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vYWNlDQo= From nobody Thu Oct 19 12:30:16 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E73113207A for ; Thu, 19 Oct 2017 12:30:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.911 X-Spam-Level: X-Spam-Status: No, score=-2.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, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hNaTCaYs2e_S for ; Thu, 19 Oct 2017 12:30:13 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0088.outbound.protection.outlook.com [104.47.0.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C56EC1321C7 for ; Thu, 19 Oct 2017 12:30: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=Ep/rjix33txBUxBUmW5MkiBSiN4MvbQbk2u3KCwHJdc=; b=pbz4B2NrreQA7naznrhFuE9vZ6i6JCGfgQmQ61c/hVT3yn8SIPtBqoCVUt5VQbiIsh/zzybtoiwnYXNtAkzwEZT/Pus33cNyA+IHtxWTh5gAxqRRmI1UBNKpd/wjWSAgNpSBIRA/FC48+iJr0TL05XeapvJksb+ga0zEmDukNww= Received: from AM4PR0801MB2706.eurprd08.prod.outlook.com (10.167.90.148) by AM4PR0801MB2708.eurprd08.prod.outlook.com (10.167.90.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.7; Thu, 19 Oct 2017 19:30:09 +0000 Received: from AM4PR0801MB2706.eurprd08.prod.outlook.com ([fe80::6027:3e1:2bf7:68ed]) by AM4PR0801MB2706.eurprd08.prod.outlook.com ([fe80::6027:3e1:2bf7:68ed%14]) with mapi id 15.20.0077.022; Thu, 19 Oct 2017 19:30:09 +0000 From: Hannes Tschofenig To: Mike Jones , Carsten Bormann , Jim Schaad CC: "ace@ietf.org" Thread-Topic: [Ace] draft-ietf-ace-cbor-web-token-08 - CWT CBOR Tag Thread-Index: AdNI8Zy0N4S3uIvORKmAfwXOEGgdYwAB3jiAAADUfYAABPnwkAAAEbQg Date: Thu, 19 Oct 2017 19:30:09 +0000 Message-ID: References: <008a01d348f9$179a96a0$46cfc3e0$@augustcellars.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [92.67.4.57] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM4PR0801MB2708; 6:vdSOMjP4X4GM9M3aYr5TSBF4/pLRM4SFlyX8nDBAy8tPSk9VdhZCP2QijM1CEueLy8SA8aBKTgEr1TJI0RuCi4U0+1TlYJdC8hb6fmwHdrGJQX4stjyFALMf/FsdZC2W9ETILcHK7u3GDSwdpgChMoiVm2HuImjq4CsqpON2IrPm4udJGytR+gcKgbFGbiYc3LQCXbA9d9sA/bqo7CnpqKB/je3QdbXuRSIZYkd/X+FVcLe20SGNZNQmVqzjd1eDfMRUxNJdwPUwuFYFnig03FumWE6m7SA+Dd/3QU9n/2qMi3X6EFYjP31CcLtV9jLaO/k6zJtpSzrEO6MX0V/gOg==; 5:rs4ANrP1AjBQ/NXKU6dntZshTB0LJ+Ur2Ae0+5OhgHNZCpfJVEIq7tpyrxIwJhTEzUBDm7DKwuOOJAkw/U/ihcJ4kKTuKY8mesvdr4NEw0ns8OJt9E1+jPC9s2+0Gt7TdnZ9W15agykEV0Ui/SMXbQ==; 24:ZB/6b/GrGXMLOmXYc36MBolUJgTGbUVO4CXvx5+DJON7dQGW35x38vP5sGPVNJAXNBNWiuN7G8P0IxsrZdR/PBKcZukQR2c3ePIKFwsuySY=; 7:QNKC6Q491sCJlTdG3B/WOLNBc1bheCQ4ZAoNsaNkw5D+SttKk78rwN5S9rP80U07EG1zf6uvWiQSL+PQpcOvgACTlEXdavTB2p5nbGoNsCmPxRcaVgmOetRQXu9N+d8vr0VyTscnxhXLPVPgltzvoBwIrSBq9GkwvDYiR5Oec5REqTcz8qmB8evgvpZp8Wp+Wmi4yEFuemWnjugW87q6QiXzImQCBY63koj/ZtNaL8Q= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: a0355181-1d6f-441b-78bb-08d51727cf85 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254172)(48565401081)(4534020)(4602075)(4627075)(201703031133081)(201702281549075)(2017052603199)(201703131423095); SRVR:AM4PR0801MB2708; x-ms-traffictypediagnostic: AM4PR0801MB2708: x-exchange-antispam-report-test: UriScan:(180628864354917); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(3002001)(93006095)(93001095)(10201501046)(100000703101)(100105400095)(6055026)(6041248)(20161123555025)(20161123564025)(20161123560025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM4PR0801MB2708; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM4PR0801MB2708; x-forefront-prvs: 0465429B7F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39860400002)(376002)(346002)(189002)(13464003)(40434004)(24454002)(199003)(3846002)(5890100001)(55016002)(5660300001)(478600001)(45080400002)(6306002)(9686003)(966005)(72206003)(189998001)(230783001)(54356999)(2950100002)(101416001)(53936002)(86362001)(7696004)(1511001)(6116002)(102836003)(66066001)(8666007)(76176999)(25786009)(99286003)(50986999)(14454004)(110136005)(4326008)(2421001)(8936002)(3660700001)(2906002)(2900100001)(2561002)(6246003)(33656002)(8676002)(316002)(93886005)(6506006)(229853002)(81156014)(53546010)(305945005)(5250100002)(97736004)(81166006)(74316002)(7736002)(106356001)(6436002)(68736007)(3280700002)(105586002)(217873001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR0801MB2708; H:AM4PR0801MB2706.eurprd08.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Oct 2017 19:30:09.4806 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR0801MB2708 Archived-At: Subject: Re: [Ace] draft-ietf-ace-cbor-web-token-08 - CWT CBOR Tag 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, 19 Oct 2017 19:30:15 -0000 Rm9yIHRoZSBjb3N0ICBzYXZpbmcgb2Ygb25lIGJ5dGUgd2UgYXJlIGVzc2VudGlhbGx5IGludHJv ZHVjdGlvbiBvcHRpb25zIGhlcmUuIEkgYW0gd29uZGVyaW5nIHdoZXRoZXIgdGhpcyBieXRlIGlz IHdvcnRoIGl0Lg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogTWlrZSBKb25l cyBbbWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbV0NClNlbnQ6IDE5IE9jdG9iZXIg MjAxNyAyMToyOQ0KVG86IENhcnN0ZW4gQm9ybWFubjsgSmltIFNjaGFhZA0KQ2M6IEhhbm5lcyBU c2Nob2ZlbmlnOyBhY2VAaWV0Zi5vcmcNClN1YmplY3Q6IFJFOiBbQWNlXSBkcmFmdC1pZXRmLWFj ZS1jYm9yLXdlYi10b2tlbi0wOCAtIENXVCBDQk9SIFRhZw0KDQpJIGFsc28gYWdyZWUgdGhhdCB0 aGUgc3BlYyBhbHJlYWR5IGhhcyB0aGlzIHJpZ2h0LiAgVHlwaWNhbGx5IG5vIHRhZyB3aWxsIGJl IG5lZWRlZCBiZWNhdXNlIHRoZSBhcHBsaWNhdGlvbiBrbm93cyB0aGUgZGF0YSBzdHJ1Y3R1cmUg aXMgYSBDV1QgZnJvbSBjb250ZXh0LiAgVGhlIHRhZyBpcyBhdmFpbGFibGUgZm9yIGFueSB1c2Ug Y2FzZXMgd2hlcmUgaXQncyBuZWVkZWQgdG8gcmVzb2x2ZSBhbWJpZ3VpdHkgdGhhdCBtaWdodCBv dGhlcndpc2UgYmUgcHJlc2VudC4NCg0KLS0gTWlrZQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KRnJvbTogQWNlIFttYWlsdG86YWNlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBP ZiBDYXJzdGVuIEJvcm1hbm4NClNlbnQ6IFRodXJzZGF5LCBPY3RvYmVyIDE5LCAyMDE3IDEwOjA1 IEFNDQpUbzogSmltIFNjaGFhZCA8aWV0ZkBhdWd1c3RjZWxsYXJzLmNvbT4NCkNjOiBIYW5uZXMg VHNjaG9mZW5pZyA8SGFubmVzLlRzY2hvZmVuaWdAYXJtLmNvbT47IGFjZUBpZXRmLm9yZw0KU3Vi amVjdDogUmU6IFtBY2VdIGRyYWZ0LWlldGYtYWNlLWNib3Itd2ViLXRva2VuLTA4IC0gQ1dUIENC T1IgVGFnDQoNCk9uIE9jdCAxOSwgMjAxNywgYXQgMTg6NDEsIEppbSBTY2hhYWQgPGlldGZAYXVn dXN0Y2VsbGFycy5jb20+IHdyb3RlOg0KPg0KPiDigKIgSSBhbHJlYWR5IGtub3cgdGhhdCB0aGlz IGlzIGdvaW5nIHRvIGJlIGEgQ1dUIHNvIEkgc2F2ZSBhIGJ5dGUuDQo+IOKAoiBJIGRvbuKAmXQg a25vdyBzbyBJIHdhc3RlIGEgdGFnIGJ5dGUgaW4gdGhhdCBjYXNlLg0KDQpSaWdodC4gIEluIFJF U1QgcHJvdG9jb2xzLCB3ZSB1c3VhbGx5IGhhdmUgYSBtZWRpYSB0eXBlLCBzbyB3ZSBkb27igJl0 IG5lZWQgdGhlIENCT1IgVGFnLg0KV2l0aGluIHNvbWUgb3RoZXIgZGF0YSBzdHJ1Y3R1cmVzLCBv ciBpbiBsZWdhY3kgcHJvdG9jb2xzIHN1Y2ggYXMgTVFUVCwgd2UgbWF5IG5vdCBoYXZlIHRoYXQs IHNvIGEgdGFnIGlzIGEgZ29vZCBzaW5nbGUgc3RhbmRhcmQgd2F5IHRvIGluZGljYXRlIHRoaXMu DQoNCihEb2VzIHRoZSBsYXR0ZXIgY2FzZSBuZWVkIHRvIGJlIGEgc2luZ2xlIGJ5dGUgW3doaWNo IGlzIHRoZW4gcHJlY2VkZWQgYnkgMHhkOCwgYnkgdGhlIHdheV0/ICBNYXliZSB0aGF0IHdvdWxk IG5vdCBoYXZlIGJlZW4gbmVjZXNzYXJ5KCopLCBidXQgdGhlbiBDV1RzIGFyZSBnb2luZyB0byBi ZSByYXRoZXIgY29tbW9uLg0KQW5kIDYxIGlzIGEg4oCcPeKAnCwgd2hpY2ggaXMgY29vbCBmb3Ig b3VyIGhleGR1bXAgcmVhZGluZyBwb3B1bGF0aW9uIDotKQ0KDQpHcsO8w59lLCBDYXJzdGVuDQoN CigqKSBUaGUgbnVtYmVyIGlzIGFscmVhZHkgYXNzaWduZWQsIEJUVy4NCg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkFjZSBtYWlsaW5nIGxpc3QNCkFj ZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hY2UNCklN UE9SVEFOVCBOT1RJQ0U6IFRoZSBjb250ZW50cyBvZiB0aGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNo bWVudHMgYXJlIGNvbmZpZGVudGlhbCBhbmQgbWF5IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYgeW91 IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVy IGltbWVkaWF0ZWx5IGFuZCBkbyBub3QgZGlzY2xvc2UgdGhlIGNvbnRlbnRzIHRvIGFueSBvdGhl ciBwZXJzb24sIHVzZSBpdCBmb3IgYW55IHB1cnBvc2UsIG9yIHN0b3JlIG9yIGNvcHkgdGhlIGlu Zm9ybWF0aW9uIGluIGFueSBtZWRpdW0uIFRoYW5rIHlvdS4NCg== From nobody Thu Oct 19 12:59:37 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC0F6133061 for ; Thu, 19 Oct 2017 12:59:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=osram.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 KOYQREaqLvDh for ; Thu, 19 Oct 2017 12:59:32 -0700 (PDT) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10062.outbound.protection.outlook.com [40.107.1.62]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D1961270AB for ; Thu, 19 Oct 2017 12:59:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Osram.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=40uOGDYza5r6bv2wFk5TdezI0D0MCfiC7+Ns644HvvI=; b=fom3iiTCy64jU3FhldOhLojGNSXQ8sOa6fS/1ngrfuqpLVFMfnKyyvXOGWLLs6vf7aG4o0NkgBWvuuUXO7LUAykZgn4OdRt96KkrZTzMMReaIxIQC2Ss/WJe0iaVmiG4paK7TqGUOq0LjXWJuloV6RNmykE6+nsSXykchI/m5uQ= Received: from VI1PR07MB3328.eurprd07.prod.outlook.com (10.175.244.10) by VI1PR07MB3327.eurprd07.prod.outlook.com (10.175.243.161) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.5; Thu, 19 Oct 2017 19:59:28 +0000 Received: from VI1PR07MB3328.eurprd07.prod.outlook.com ([fe80::5d7d:2995:baf9:4567]) by VI1PR07MB3328.eurprd07.prod.outlook.com ([fe80::5d7d:2995:baf9:4567%13]) with mapi id 15.20.0077.023; Thu, 19 Oct 2017 19:59:28 +0000 From: "Beck, Stefan" To: "ace@ietf.org" Thread-Topic: [Ace] multicast Thread-Index: AdNIng8OaAKxM8piQaWt4FllrU9xPQAJf8iAAAMwwFAAAwsVkAABon7QAAVGBYAABpYTwA== Date: Thu, 19 Oct 2017 19:59:28 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=S.Beck@osram.com; x-originating-ip: [2001:a61:32c4:8e01:9868:1a1c:2dac:17ee] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR07MB3327; 6:Ie+LnG4kiLZ26FqJcBb/nV8VNY+gOUYLhmcXX22M3mlAvlK/b3FlqhCfgIdy/kIwx1Zog9z3d6XWeWtsuFp58sOSa+nnS6VjrtwtvghVm815kd7hdOO8YY4a83prW9OPI4Xgl2jNRk2ckclgh/kjg6ZMhLi0FyyZSYco3I+UBXbn2EaP4EYHHKd7QktTKz8itKUzkVh3N9Va7w6hkuXoSZabuMbv+IxrCVuvgxbAiwuRajXHHnWmuxw7f7QI4tI1HmTHg8SFQNRRpW83UIyX8umip5JNO+yJKxEOhzepEQEY55Hakh5mbracW2aAFG5l/g+y3o9qbLLstRL6493UHw==; 5:05jTAHxI9PebkzqZdwbbje9d7zV45/tc+mNI2gdbZ8YViAzk8ki29tIRPiEuocqRV7f2X92nJ7VD4ugsOCM5DWrLk+ztrBbSYnVlPnyLZEXq6YFPUNRUY1rU9AZ9HoQAgt4CG9DHKqJpN2KTD4YhUg==; 24:4vsW4IoiNKjm6QL+va1IS25N1R9qKSMj80z8V3/jUX4esrMXMKPl5jcX7rwD5dYI0AbqwvtZf27dXpbhzOfTz39gGqkAQBZnQQV/7AERCdM=; 7:5AeeyA/+DFftLTNhDTpBz6w0rBkPulyYIDz9iY03FTR/qz6bkAWHcJLNsHNwSiet+1fMMxQ74cvgFKrd0DVe7G2l0CUiK+5oA3Rjb3Ko8aXL2wrj+TWoLB1llPzbpRWFkcc/Q/jme7ULOseBQjO4sQ9V1A2DRrHih23eGMNRTJ0LR2kEjJKrP760nYsjYdDjpOniyPh+GgLLCUT523hp5c+kfyVghJS6DHwMscLTypI= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: d1e62d71-5740-4e36-d7f9-08d5172be7da x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254172)(4534020)(4602075)(4627075)(201703031133081)(201702281549075)(2017052603199)(49563074)(201703131423095); SRVR:VI1PR07MB3327; x-ms-traffictypediagnostic: VI1PR07MB3327: x-exchange-antispam-report-test: UriScan:(189930954265078)(45079756050767); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(102415395)(6040450)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(10201501046)(3002001)(93006095)(93001095)(6041248)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123558100)(20161123564025)(20161123562025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:VI1PR07MB3327; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:VI1PR07MB3327; x-forefront-prvs: 0465429B7F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39860400002)(346002)(376002)(13464003)(189002)(199003)(24454002)(106356001)(229853002)(76176999)(105586002)(54356999)(5660300001)(50986999)(3280700002)(8676002)(86362001)(575784001)(81156014)(1730700003)(8936002)(81166006)(33656002)(7736002)(6506006)(3660700001)(2351001)(7696004)(93886005)(99936001)(14454004)(305945005)(68736007)(6436002)(6916009)(102836003)(6116002)(2950100002)(74316002)(53936002)(2900100001)(45080400002)(25786009)(6246003)(9686003)(189998001)(316002)(99286003)(101416001)(55016002)(6306002)(5640700003)(5250100002)(966005)(72206003)(2501003)(53546010)(478600001)(2906002)(97736004); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR07MB3327; H:VI1PR07MB3328.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: osram.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0491_01D34925.873F5A50" MIME-Version: 1.0 X-OriginatorOrg: Osram.com X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Oct 2017 19:59:28.2923 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: ec1ca250-c234-4d56-a76b-7dfb9eee0c46 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB3327 Archived-At: Subject: Re: [Ace] multicast 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, 19 Oct 2017 19:59:35 -0000 ------=_NextPart_000_0491_01D34925.873F5A50 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit I totally agree with Mike. BTW, Hannes, this was "part a." of Idea #1 - the only added value I've seen was that the device could raise an alarm - so there is awareness of an attack at least "after the fact". However, it adds complexity to the constrained device - and alternatively, one could just use one separate listener to the multicast group, that just does this job. It's multicast, so a single listener is sufficient to handle such type of alarms. "Part b." would even be more important to me: the multicasters (not the listeners) are the constrained devices that are unable to sign their messages in time. (Think of battery-powered low cost wall switches). In that case they would need to pre-compile their multicast message (or set of messages- eg. one or more for turn off / turn on / dim level x events), so they just fire them when the event happens. Again, this adds a lot of complexity, and may even not be feasible at all (in case you have timing constraints in the crypto operations) Stevie > -----Original Message----- > From: Ace [mailto:ace-bounces@ietf.org] On Behalf Of Michael StJohns > Sent: Thursday, October 19, 2017 6:38 PM > To: ace@ietf.org > Subject: Re: [Ace] multicast > > On 10/19/2017 10:59 AM, Hannes Tschofenig wrote: > > I suspect the idea is the following: > > > > 1) First, you would decrypt the packet and validate the mac (assuming > > that it is an AEAD cipher) > > 2) You execute the operation to meet the latency requirements. > > 3) Then, you can take time to verify the digital signature (outside > > the latency requirements) > > > > Is that the idea? > > > > It can't possibly be. What do you do if the digital signature doesn't > verify? Reverse the operation? Flicker the lights? Go back to the > original > levels? Flash "OOPS" in morse code? > > You need to verify the signature in advance of doing an operation > authenticated > and authorized by that signature.... > > Mike > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.i > etf.org%2Fmailman%2Flistinfo%2Face&data=02%7C01%7C%7Cd6a2b032140a4 > 8082e1908d5170fc763%7Cec1ca250c2344d56a76b7dfb9eee0c46%7C0%7C0%7 > C636440278895347864&sdata=fpqgRpYFEvJxQUc4l2zlHM%2BUc7VaYLcp217q3 > 2kHgLQ%3D&reserved=0 ------=_NextPart_000_0491_01D34925.873F5A50 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITQDCCBZcw ggN/oAMCAQICEH2N5rAAeSCGTQvIxSt6cDswDQYJKoZIhvcNAQELBQAwZDETMBEGCgmSJomT8ixk ARkWA2NvbTEbMBkGCgmSJomT8ixkARkWC29zcmFtLWxpZ2h0MRMwEQYKCZImiZPyLGQBGRYDaW50 MRswGQYDVQQDDBJPU1JBTSBSb290IENBIDIwMTUwHhcNMTUwOTE3MDk0NzMyWhcNNDAwOTE3MDk1 NzI2WjBkMRMwEQYKCZImiZPyLGQBGRYDY29tMRswGQYKCZImiZPyLGQBGRYLb3NyYW0tbGlnaHQx EzARBgoJkiaJk/IsZAEZFgNpbnQxGzAZBgNVBAMMEk9TUkFNIFJvb3QgQ0EgMjAxNTCCAiIwDQYJ KoZIhvcNAQEBBQADggIPADCCAgoCggIBAMPOLdsM1I8Fll2DJ5A01Y53Cbq88OH6/ZocCMhm+9Ro Ce4RHnIB+WKi8+4fTUYU3DjwgXiI3tH6YG9j9o3ahkepcaRx1arkNJCfGs8UKbHQnxVM9n5Sv3lp Qm/OyE+qwl8sA77nVvrmAiYDIXdlJajITmqMBiSS5TfS7YO7knMLOv5bzd4ihUizsNGgVIvPyowz NpsA/yYzIJJhSYCdSc9Aji5MDF4fscYaffpdaM3VoZ4gdZiVgcYrnUVR4oFsNkoja6MV3Vk9o5py 8I6ff5Dhc6ZStrjYG1Q9iIIawvvi4e4A6ISRmxw3QBUZtlvBiC8Z2g/XVJnwz91RKIT1lQPbb2Cw 88E1nRVfF1txiVbQXw+TjNnyIVcxZS/p34yHXS9/gmPVXBUx3SYqAMI9vk/mqvkDGPAkIrpILTQT XcxkJVwQukR7mSpRw4bx0bg4mxH1x6tr4HqZe5hFtQTs+VckNiXLF5xFbOjFuck5UBRbW8J3ENCA ohtR/OdOAKFrS7Y5uPLA5ENMt+Ee2LeaEmwUIIioYZuToXngaimCg6m9aIGv9ytMUgnF3+9CRsKr drVw6Er2eKnGOXyBaMOkR14loeFISsA9UL85Ib80MHLZd8t0rkIpThZSKMMS/eKpGyZMv9HLYrVZ 1TssyD8pvu4yzrHGtrtehXu2JfRm+gzdAgMBAAGjRTBDMA4GA1UdDwEB/wQEAwIBBjASBgNVHRMB Af8ECDAGAQH/AgECMB0GA1UdDgQWBBRBffSxSuh0TnMOw0EPaZQm3UsWYTANBgkqhkiG9w0BAQsF AAOCAgEAoHwKO+Sh72eofY0BSZ+h+ajR9K7PJnwrLV557s4Id1EIvfMU8geELns5FsKOcAg9ipnv PPt0EVFFGulfyKRa0OPLvz7ofpEF0Bs8LVdAbqtImf9YGAmFtf7zIEdKmtDhGdKNabwt0QbVKOEs IzbQCeKXdFQ6/s0c+aSO/I1wLOekihbY1PY0IzNzDBfIbzDdFgcQfVc+kSlV2sSKjrqpG9qGvvwL VCWSCGFC/nAkb4g4PXhmOEIfo04vaibNHYFyl4ltZiWph/mism4MM1bAvPtZM8fFc1J6Sgkir7vD XQOCpQrxFYAKTqOIhAGn0hY/AY7198X5Jeh/tCUjatDz7AHuhdBTPC+XeGMyzvj7fkVwTv3TazEo u6jpmn6b2QY+0GdVytR4R0KFFIjGvxmOH4gg7pfOwplpjzE3K11CHGsEXQwAZNPnhj/EXEqSdx3g dUX77plIcnE8TwXxoY+aa9p1JfAmKVLT3vZbT8YDm83RkN7vcyGW/NBDq2OyihORutQxuy9PpYaM Txnzp9M620XFwKJbU3D0vYvHOgYFKQy71hgn/AX3KnQ+MXgiRCy5phiSTOTc8SZzuijBV2X30hX+ NAd3M4dQq4/VnK/Zop0LYornrFK79re2RLDqm1NP/k9yAOCc0WR7lQOhFW3R0JgFSmRSMsR4PWGg afjpMSgwggZ1MIIEXaADAgECAhMYAADE1BvnBAMoNJsjAAAAAMTUMA0GCSqGSIb3DQEBCwUAMGcx EzARBgoJkiaJk/IsZAEZFgNjb20xGzAZBgoJkiaJk/IsZAEZFgtvc3JhbS1saWdodDETMBEGCgmS JomT8ixkARkWA2ludDEeMBwGA1UEAwwVT1NSQU0gSXNzdWluZyBDQSAyMDE1MB4XDTE2MTEwMzE1 NTYxMVoXDTIxMTEwMjE1NTYxMVowcjELMAkGA1UEBhMCREUxDjAMBgNVBAoMBU9TUkFNMRwwGgYD VQQLDBNPU1JBTSBHbWJILCBHZXJtYW55MRQwEgYDVQQDDAtTdGVmYW4gQmVjazEfMB0GCSqGSIb3 DQEJARYQUy5CZWNrQG9zcmFtLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKht x104jKLZgCEyi4IKs7QjFm+csCMA3g4nYkhYmv5yK4Jtw6pixicOV4KUypkejZhbWmU+vyD3iY/0 aZ+uvwyNl90CA8fWmKdC1sF7xs7MtYvaQOycf47BTkqAdlOep9iTKxKpEW9B9LchU2iBUdhdQUsy jYrvq3MzPGw5ERW9dSwsXf4M5l3pDmlfPgCAYmEdRop4eUshqh87cr8AfzTm4XEcR7pG6lOgTkFa kZAltl6U3+VHQ2PQj6pw5VRHuaqPunZVFJL8e8kNErDgPkRnY2t12qNIbvxiSri3gSDHlOJJ/kND HHzI2+yOEA70nFfFG0tY6DcXwm8qWmT6uMECAwEAAaOCAg0wggIJMAsGA1UdDwQEAwIF4DA9Bgkr BgEEAYI3FQcEMDAuBiYrBgEEAYI3FQiCuLoUhdG3QIS5iTOG7K5ahOeweYENxscDgoHuRQIBZAIB CDBEBgkqhkiG9w0BCQ8ENzA1MA4GCCqGSIb3DQMCAgIAgDAOBggqhkiG9w0DBAICAIAwBwYFKw4D AgcwCgYIKoZIhvcNAwcwHQYDVR0OBBYEFKLokmPgby7PzMPWwS913WLd8w7yMB8GA1UdIwQYMBaA FAd1EUQRun6PdD2R16jhaq0s694uMF8GA1UdHwRYMFYwVKBSoFCGTmh0dHA6Ly9wa2kub3NyYW0t bGlnaHQuY29tL09TUkFNLUlTU1VJTkctQ0EtMjAxNS9DUkwvT1NSQU0tSVNTVUlORy1DQS0yMDE1 LmNybDBrBggrBgEFBQcBAQRfMF0wWwYIKwYBBQUHMAKGT2h0dHA6Ly9wa2kub3NyYW0tbGlnaHQu Y29tL09TUkFNLUlTU1VJTkctQ0EtMjAxNS9DZXJ0L09TUkFNLUlTU1VJTkctQ0EtMjAxNS5jcnQw HwYDVR0lBBgwFgYIKwYBBQUHAwQGCisGAQQBgjcKAwQwKQYJKwYBBAGCNxUKBBwwGjAKBggrBgEF BQcDBDAMBgorBgEEAYI3CgMEMBsGA1UdEQQUMBKBEFMuQmVja0Bvc3JhbS5jb20wDQYJKoZIhvcN AQELBQADggIBAAeoZQyM9u1NEpKRRDYMydLJ1wa1Y1m7rDfp5CPp0uni4qS5iXReWgIEzkhNCV5E oC0DosSOqnh2BkAkX+khNPuhLjjM/ApbFIqnnY+RD+xz3fxjx584TFmBugWHvKycYyD5NWhtD6Ej mWv6tUsxjYCv652LruxCdGJDbsaaEKP28te5dwMLD9wqSrBVU6ftbuzb9rL7IatpcBPCDkuCXSSQ lnAefbP2Y73wm1/+tbP/FxgyQjZUFR5qbXl2fMyynsrqLr3c6K7VxZs8+psbd+PiOlQnXcfGGCWR cZxr0cUZP/O861rFlE8s1OpxN5XI2pQIAzJx2toIsmHdk6hOY7t/2lYaMtqQLl2+cd2RoUMijM+1 Yi+v2WwuErdZzmgjTKht8rinng7GAuiSIQB489J4FgOEBWYne8zrl7jyuU9RYcYN9Nc5IZhK2Nfg 0xDh4tWeMWIuCg8f9ubeHOekdrg01cazDavxjaftQ25+2J5EwAWxc4ZPivOD9bkiYknSfg2iih2Y iRxUXqVq0q+qCfVDeys+MSFcu/WetN2ibvouzr+q4Aw+71j6M7FaWWpRz5FFKz40O/wAzoR2WB7u gGuT4RlAb7Yr8zM8TRpHKmrOSi19o/5qbGrPOX3u/B9UjK3LvR0n7TO6J9q0qxKveWlu6cofPQRd 2UVQoaNLB90mMIIHKDCCBRCgAwIBAgITWAAAAAXTK7hm1i4tGAAAAAAABTANBgkqhkiG9w0BAQsF ADBkMRMwEQYKCZImiZPyLGQBGRYDY29tMRswGQYKCZImiZPyLGQBGRYLb3NyYW0tbGlnaHQxEzAR BgoJkiaJk/IsZAEZFgNpbnQxGzAZBgNVBAMMEk9TUkFNIFJvb3QgQ0EgMjAxNTAeFw0xNTA5MzAx MjM2MTdaFw0yNzA5MzAxMjQ2MTdaMGcxEzARBgoJkiaJk/IsZAEZFgNjb20xGzAZBgoJkiaJk/Is ZAEZFgtvc3JhbS1saWdodDETMBEGCgmSJomT8ixkARkWA2ludDEeMBwGA1UEAwwVT1NSQU0gSXNz dWluZyBDQSAyMDE1MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAvbRnffh0KvDggawO /LfHMVmHl1fTbjzZQRjbbdUG6aKwTGeIpg7M4RXUIObssQ7sbSxuu77Vz2OFdSf5vk1fVZn8DFD8 dVB2AsYKPWZmBO+CYOvb2NCNqyLnt2/Mlk74gwTXdBgJsNjDbxs6yIfwn+rdGNt3gDwPeTiX+0Rn Ccj1NclFef00nW4kKFr2kkf+tVXMQx3pS7BQAjyuL+coQmOD5vIM+qU4dGy9ndYExTMTOPbDQaAO lx/vPXUSS1FvMJtKz//ODt/yew5RL55ZKuh6Mi7TvGTYcSH989NlXjYIYGQ0/5zfukj6CcscjInX 9W4U6NFvZL8YoVR6RLQkOTtfYa36t/iw16diSlBVeM7wq471fRXpytuGjLVtOl+oGGA7uM1QJ2OH OaXKzb6S28h8/W2urmHWMnSsBioznyio28I1PzyiwQeSe1NuMRobL0wSOTL/wljsxEkapvn4u3oW +SQCNyvXyigIYh+OaKNWFj62GclxPzoWkeT6FD6a6GS6geNyAF04N8fA/P1G/sSSCUcNdLodeEQz 17uSvIxKIFb0t7TgM40vgfwW929cv8hSoEfYQykeuPWPRc8nYkb9y6FSqpWxkXCFZRcVr826I7HY 3c2cfjFytMx4eyE5NzLV8n8jbEG0oM8c1SO1ojT4eQUgJgR2dE0OM6iJi6cCAwEAAaOCAc4wggHK MAsGA1UdDwQEAwIBhjAdBgNVHQ4EFgQUB3URRBG6fo90PZHXqOFqrSzr3i4wgaQGA1UdIASBnDCB mTCBlgYdKwYBBAGCNxUIgri6FIXRt0CEuYkzhuyuWoTnsHkwdTA8BggrBgEFBQcCAjAwHi4ATABl AGcAYQBsACAAcABvAGwAaQBjAHkAIABzAHQAYQB0AGUAbQBlAG4AdAAuMDUGCCsGAQUFBwIBFilo dHRwOi8vcGtpLm9zcmFtLWxpZ2h0LmNvbS9DUFMvaW5kZXguaHRtADASBgNVHRMBAf8ECDAGAQH/ AgEBMB8GA1UdIwQYMBaAFEF99LFK6HROcw7DQQ9plCbdSxZhMFkGA1UdHwRSMFAwTqBMoEqGSGh0 dHA6Ly9wa2kub3NyYW0tbGlnaHQuY29tL09TUkFNLVJvb3QtQ0EtMjAxNS9DUkwvT1NSQU0tUm9v dC1DQS0yMDE1LmNybDBlBggrBgEFBQcBAQRZMFcwVQYIKwYBBQUHMAKGSWh0dHA6Ly9wa2kub3Ny YW0tbGlnaHQuY29tL09TUkFNLVJvb3QtQ0EtMjAxNS9DZXJ0L09TUkFNLVJvb3QtQ0EtMjAxNS5j cnQwDQYJKoZIhvcNAQELBQADggIBACnQrysmPX41U+j/Q33kIHIGxFU0aYS0qrBmzGGGGNamqD8H 2SGy8LdCVcGeecE3XlKzZe+AnTTa1ejhHvhMJc8tHCgMLyvdSxKjJ69Rp75AaknxX15AwuFMkqLQ O+itE0PV6f3QHVdYevo2asZ3UgaQGOBFEo782qiNBDHawzuuXpXUTo4gWntTieXICIXWEenOgin1 901aoM0qzHTd8CXHdN8W7UNOE/6eCH02LofORiL2OzOAaz6aduK76KIEn3Fb2fbFAwKVIgTbvflA 9AWliukXYOSTGg9NXOyUVAE+ti4s720bYAJNrHTSbxbVpkDaWyZOhL/MsDAl3Q5/tMBbykhIy1pA 0zg5Q0QVr7B57x2Yo62nbduruNAnA0t+Q6DOrIRudaboAEeIXsQzVuUKd11o9mDOcVuetRxoS7lN 33zC3IHQajDFs8UHt4z6Cjj3EGttiS+ApUyDztgThD8bq7JSiAcFuXXD7zKmWN4TR6hKqTr9YGqA qhx/Dh7yYGUIOGAQi/EM0X1Ak73R45BopSyUm6oVj9i+w3SVvW66GxHbSUHqj8hA5Mokb9/ZC4Hn r/8CTC6MyfFJgksnMLEnhQOpCCaOzKtJ7UMnSeJHYHQUiDksIY5d3Y2T7QWDww7U95fMtGfPhqbA cF1qh4o9RYzuFWS6puXo7eRS2O1lMYIDwDCCA7wCAQEwfjBnMRMwEQYKCZImiZPyLGQBGRYDY29t MRswGQYKCZImiZPyLGQBGRYLb3NyYW0tbGlnaHQxEzARBgoJkiaJk/IsZAEZFgNpbnQxHjAcBgNV BAMMFU9TUkFNIElzc3VpbmcgQ0EgMjAxNQITGAAAxNQb5wQDKDSbIwAAAADE1DAJBgUrDgMCGgUA oIICFzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzEwMTkxOTU5 MjVaMCMGCSqGSIb3DQEJBDEWBBTFzV0CkInRZEAeXCvGXQGLVRGEyDCBjgYJKwYBBAGCNxAEMYGA MH4wZzETMBEGCgmSJomT8ixkARkWA2NvbTEbMBkGCgmSJomT8ixkARkWC29zcmFtLWxpZ2h0MRMw EQYKCZImiZPyLGQBGRYDaW50MR4wHAYDVQQDDBVPU1JBTSBJc3N1aW5nIENBIDIwMTUCExgAAMTU G+cEAyg0myMAAAAAxNQwgZAGCyqGSIb3DQEJEAILMYGAoH4wZzETMBEGCgmSJomT8ixkARkWA2Nv bTEbMBkGCgmSJomT8ixkARkWC29zcmFtLWxpZ2h0MRMwEQYKCZImiZPyLGQBGRYDaW50MR4wHAYD VQQDDBVPU1JBTSBJc3N1aW5nIENBIDIwMTUCExgAAMTUG+cEAyg0myMAAAAAxNQwgZMGCSqGSIb3 DQEJDzGBhTCBgjALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAoGCCqGSIb3DQMHMAsGCWCGSAFl AwQBAjAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAhowCwYJYIZIAWUDBAID MAsGCWCGSAFlAwQCAjALBglghkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAlfyy0bGa5yviw+6s wLFTXSGdO/y9p2xGd/PWL4oy3i8+XkfV4nr9pzyWNG5pRWKDASJGXYiPLuGIQ76XwaYeX/UnTGuJ oFx09nJm9q1foBKO9b2bd2bI5E6f3JxH++C5EqW+K75IQWVpizONWGpIlMElCt/9hOuizVCuScmu wAt1gEyeqX0WkikiQ+tT9AWSvDnMke6RxDab5d42buB78ISy5ZZD9KH0GX5Do6Cy9ZW5gXig7PIv xz5GfZPKhglEwIubGQat5iTvfoOs7YlbalpYnt4SMgwNs0YH7iUMsMOWgZ8ttrSYpqY2a2oha33c fsA0B++kOQC73FfbJKjRIwAAAAAAAA== ------=_NextPart_000_0491_01D34925.873F5A50-- From nobody Thu Oct 19 13:02:39 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DF82129A89 for ; Thu, 19 Oct 2017 13:02:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f83mq8xQPriN for ; Thu, 19 Oct 2017 13:02:36 -0700 (PDT) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10061.outbound.protection.outlook.com [40.107.1.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE2FF1270AB for ; Thu, 19 Oct 2017 13:02:35 -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=k0aRhX7ZXxcrKXUB151PAqkknM8DXQ2JST2LA0t1pR8=; b=kvyR9kpLhu8r/GWCM43j0ja2adJbIsMst6Slso6zoWne657L0iVPTq0/nNxwM4xZwHFiJx5xlxhg4iuFZu8QCRp/KhGvUnp+ZMsMdU+FYA+nYpmk3kqe3mMrZa4OjWNxxpbX4irYAvb5DsnyJWyriAM4B4PniLuLxes8anEkdDs= Received: from AM4PR0801MB2706.eurprd08.prod.outlook.com (10.167.90.148) by AM4PR0801MB2706.eurprd08.prod.outlook.com (10.167.90.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.7; Thu, 19 Oct 2017 20:02:32 +0000 Received: from AM4PR0801MB2706.eurprd08.prod.outlook.com ([fe80::6027:3e1:2bf7:68ed]) by AM4PR0801MB2706.eurprd08.prod.outlook.com ([fe80::6027:3e1:2bf7:68ed%14]) with mapi id 15.20.0077.022; Thu, 19 Oct 2017 20:02:32 +0000 From: Hannes Tschofenig To: "Beck, Stefan" , "ace@ietf.org" Thread-Topic: [Ace] multicast Thread-Index: AdNIng8OaAKxM8piQaWt4FllrU9xPQAJf8iAAAMwwFAAAwsVkAABon7QAAVGBYAABpYTwAAAhdvw Date: Thu, 19 Oct 2017 20:02:32 +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: [92.67.4.57] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM4PR0801MB2706; 6:io++ZOYfBfGpWJlJhW8kCI2Zuw40VPcRg0blODu4m3yOMV1w5vsgNQTBN6duKZxvWlw0GXIKQelwDqbYWxdG7a1i3tHCkOnCNrMRppI9EooQBg5SfHvI9I3uauu3Xx5NmZolw4+utYX/LYFIaDvQHmlmHFOZflAb6aBRju70l4P9z1czh10HbwvbXtIGCBE3aTamG4fYuUKD0HBudk59O7gNPNhoocZMBv6nB2fQkRFzkSd8CQgjogR53iEhJci+9LoJb6+X7ttMK6pNmYNw59VChoa5D9ogIpvXDb8BOna1+rlPz4ACKBoQuSN6ryxJkXOb/eazimFIxkoC1zGaoQ==; 5:es5J4rwo1pefnITPy8c6mvg3rsOMtRUVh1arNTYT701MBBqIDg5rR2zwhiVsRMTQunhhXIrSBI7tKwB1tVe8pMlV2eTyFgpUh0AWchX40EiewR8ITGJfXOEQwWm5QTyZ6OTyL8oILcBjungNN8HYAg==; 24:/A2pv21ozm1UxhDM3CRxTu8Swih7F0bbL5YF5v6HQahjbmin6usLbGkWMtjOIQEJNM58ke2BnR9DBbWToxbFhD7HoHJexXDDCm/PUP1ui1Q=; 7:Y4ij0+x1ZHfMW3tbz7pJtVv44DobyepN5z3CFyu/EJoA2dH/OrgfVlgdjFnOajkDO1AQXk+Ho34uUfAD0KpC9Qzqzfpp3Am61vyw0JIrueeAflqxAdmzf5PcwWFjUNLI2JzJTw3bqmFUvQzKoPj9slhYhO1hccVyOOGt3MWU7e8kSYeiqA2vkGzg3DagOPznyOyO+bRZfFUAe8AkzvK1JMYFqsyJG3MBBuYdPyPkb8s= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 9ddae1b9-e15e-497e-2c76-08d5172c559e x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254172)(48565401081)(4534020)(4602075)(4627075)(201703031133081)(201702281549075)(2017052603199)(201703131423095); SRVR:AM4PR0801MB2706; x-ms-traffictypediagnostic: AM4PR0801MB2706: x-exchange-antispam-report-test: UriScan:(189930954265078)(45079756050767); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(3002001)(93006095)(93001095)(10201501046)(100000703101)(100105400095)(6055026)(6041248)(20161123555025)(20161123564025)(20161123560025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM4PR0801MB2706; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM4PR0801MB2706; x-forefront-prvs: 0465429B7F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(346002)(376002)(39860400002)(189002)(199003)(13464003)(24454002)(40434004)(99286003)(50986999)(2906002)(9686003)(6116002)(72206003)(478600001)(102836003)(189998001)(3846002)(81156014)(8676002)(74316002)(966005)(6246003)(33656002)(81166006)(8936002)(3660700001)(316002)(101416001)(14454004)(3280700002)(110136005)(305945005)(53936002)(76176999)(54356999)(53546010)(55016002)(6306002)(93886005)(7736002)(105586002)(5660300001)(106356001)(25786009)(45080400002)(68736007)(7696004)(229853002)(2950100002)(86362001)(6506006)(2900100001)(66066001)(2501003)(97736004)(5890100001)(5250100002)(575784001)(6436002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR0801MB2706; H:AM4PR0801MB2706.eurprd08.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Oct 2017 20:02:32.4284 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR0801MB2706 Archived-At: Subject: Re: [Ace] multicast 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, 19 Oct 2017 20:02:38 -0000 U28sIHdoYXQgYXJlIHlvdSBzdWdnZXN0aW5nPw0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KRnJvbTogQWNlIFttYWlsdG86YWNlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBC ZWNrLCBTdGVmYW4NClNlbnQ6IDE5IE9jdG9iZXIgMjAxNyAyMTo1OQ0KVG86IGFjZUBpZXRmLm9y Zw0KU3ViamVjdDogUmU6IFtBY2VdIG11bHRpY2FzdA0KDQpJIHRvdGFsbHkgYWdyZWUgd2l0aCBN aWtlLg0KQlRXLCBIYW5uZXMsIHRoaXMgd2FzICJwYXJ0IGEuIiBvZiBJZGVhICMxIC0gdGhlIG9u bHkgYWRkZWQgdmFsdWUgSSd2ZSBzZWVuIHdhcyB0aGF0IHRoZSBkZXZpY2UgY291bGQgcmFpc2Ug YW4gYWxhcm0gLSBzbyB0aGVyZSBpcyBhd2FyZW5lc3Mgb2YgYW4gYXR0YWNrIGF0IGxlYXN0ICJh ZnRlciB0aGUgZmFjdCIuIEhvd2V2ZXIsIGl0IGFkZHMgY29tcGxleGl0eSB0byB0aGUgY29uc3Ry YWluZWQgZGV2aWNlIC0gYW5kIGFsdGVybmF0aXZlbHksIG9uZSBjb3VsZCBqdXN0IHVzZSBvbmUg c2VwYXJhdGUgbGlzdGVuZXIgdG8gdGhlIG11bHRpY2FzdCBncm91cCwgdGhhdCBqdXN0IGRvZXMg dGhpcyBqb2IuIEl0J3MgbXVsdGljYXN0LCBzbyBhIHNpbmdsZSBsaXN0ZW5lciBpcyBzdWZmaWNp ZW50IHRvIGhhbmRsZSBzdWNoIHR5cGUgb2YgYWxhcm1zLg0KDQoiUGFydCBiLiIgd291bGQgZXZl biBiZSBtb3JlIGltcG9ydGFudCB0byBtZTogdGhlIG11bHRpY2FzdGVycyAobm90IHRoZQ0KbGlz dGVuZXJzKSBhcmUgdGhlIGNvbnN0cmFpbmVkIGRldmljZXMNCnRoYXQgYXJlIHVuYWJsZSB0byBz aWduIHRoZWlyIG1lc3NhZ2VzIGluIHRpbWUuIChUaGluayBvZiBiYXR0ZXJ5LXBvd2VyZWQgbG93 IGNvc3Qgd2FsbCBzd2l0Y2hlcykuDQpJbiB0aGF0IGNhc2UgdGhleSB3b3VsZCBuZWVkIHRvIHBy ZS1jb21waWxlIHRoZWlyIG11bHRpY2FzdCBtZXNzYWdlIChvciBzZXQgb2YNCm1lc3NhZ2VzLQ0K ZWcuIG9uZSBvciBtb3JlIGZvciB0dXJuIG9mZiAvIHR1cm4gb24gLyBkaW0gbGV2ZWwgeCBldmVu dHMpLCBzbyB0aGV5IGp1c3QgZmlyZSB0aGVtIHdoZW4gdGhlIGV2ZW50IGhhcHBlbnMuDQpBZ2Fp biwgdGhpcyBhZGRzIGEgbG90IG9mIGNvbXBsZXhpdHksIGFuZCBtYXkgZXZlbiBub3QgYmUgZmVh c2libGUgYXQgYWxsIChpbiBjYXNlIHlvdSBoYXZlIHRpbWluZyBjb25zdHJhaW50cyBpbiB0aGUg Y3J5cHRvIG9wZXJhdGlvbnMpDQoNClN0ZXZpZQ0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQo+IEZyb206IEFjZSBbbWFpbHRvOmFjZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYg T2YgTWljaGFlbCBTdEpvaG5zDQo+IFNlbnQ6IFRodXJzZGF5LCBPY3RvYmVyIDE5LCAyMDE3IDY6 MzggUE0NCj4gVG86IGFjZUBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW0FjZV0gbXVsdGljYXN0 DQo+DQo+IE9uIDEwLzE5LzIwMTcgMTA6NTkgQU0sIEhhbm5lcyBUc2Nob2ZlbmlnIHdyb3RlOg0K PiA+IEkgc3VzcGVjdCB0aGUgaWRlYSBpcyB0aGUgZm9sbG93aW5nOg0KPiA+DQo+ID4gMSkgRmly c3QsIHlvdSB3b3VsZCBkZWNyeXB0IHRoZSBwYWNrZXQgYW5kIHZhbGlkYXRlIHRoZSBtYWMNCj4g PiAoYXNzdW1pbmcgdGhhdCBpdCBpcyBhbiBBRUFEIGNpcGhlcikNCj4gPiAyKSBZb3UgZXhlY3V0 ZSB0aGUgb3BlcmF0aW9uIHRvIG1lZXQgdGhlIGxhdGVuY3kgcmVxdWlyZW1lbnRzLg0KPiA+IDMp IFRoZW4sIHlvdSBjYW4gdGFrZSB0aW1lIHRvIHZlcmlmeSB0aGUgZGlnaXRhbCBzaWduYXR1cmUg KG91dHNpZGUNCj4gPiB0aGUgbGF0ZW5jeSByZXF1aXJlbWVudHMpDQo+ID4NCj4gPiBJcyB0aGF0 IHRoZSBpZGVhPw0KPiA+DQo+DQo+IEl0IGNhbid0IHBvc3NpYmx5IGJlLiAgIFdoYXQgZG8geW91 IGRvIGlmIHRoZSBkaWdpdGFsIHNpZ25hdHVyZSBkb2Vzbid0DQo+IHZlcmlmeT8gIFJldmVyc2Ug dGhlIG9wZXJhdGlvbj8gICBGbGlja2VyIHRoZSBsaWdodHM/ICBHbyBiYWNrIHRvIHRoZQ0KPiBv cmlnaW5hbA0KPiBsZXZlbHM/ICBGbGFzaCAiT09QUyIgaW4gbW9yc2UgY29kZT8NCj4NCj4gWW91 IG5lZWQgdG8gdmVyaWZ5IHRoZSBzaWduYXR1cmUgaW4gYWR2YW5jZSBvZiBkb2luZyBhbiBvcGVy YXRpb24NCj4gYXV0aGVudGljYXRlZCBhbmQgYXV0aG9yaXplZCBieSB0aGF0IHNpZ25hdHVyZS4u Li4NCj4NCj4gTWlrZQ0KPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPiBBY2UgbWFpbGluZyBsaXN0DQo+IEFjZUBpZXRmLm9yZw0KPiBodHRwczov L2VtZWEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJG JTJGd3d3DQo+IC5pDQo+IGV0Zi5vcmclMkZtYWlsbWFuJTJGbGlzdGluZm8lMkZhY2UmZGF0YT0w MiU3QzAxJTdDJTdDZDZhMmIwMzIxNDBhNA0KPiA4MDgyZTE5MDhkNTE3MGZjNzYzJTdDZWMxY2Ey NTBjMjM0NGQ1NmE3NmI3ZGZiOWVlZTBjNDYlN0MwJTdDMCU3DQo+IEM2MzY0NDAyNzg4OTUzNDc4 NjQmc2RhdGE9ZnBxZ1JwWUZFdkp4UVVjNGwyemxITSUyQlVjN1ZhWUxjcDIxN3EzDQo+IDJrSGdM USUzRCZyZXNlcnZlZD0wDQpJTVBPUlRBTlQgTk9USUNFOiBUaGUgY29udGVudHMgb2YgdGhpcyBl bWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBjb25maWRlbnRpYWwgYW5kIG1heSBhbHNvIGJl IHByaXZpbGVnZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFz ZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBhbmQgZG8gbm90IGRpc2Nsb3NlIHRoZSBj b250ZW50cyB0byBhbnkgb3RoZXIgcGVyc29uLCB1c2UgaXQgZm9yIGFueSBwdXJwb3NlLCBvciBz dG9yZSBvciBjb3B5IHRoZSBpbmZvcm1hdGlvbiBpbiBhbnkgbWVkaXVtLiBUaGFuayB5b3UuDQo= From nobody Thu Oct 19 13:15:20 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3005C133328 for ; Thu, 19 Oct 2017 13:15:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=osram.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 OSqhgy11DfCQ for ; Thu, 19 Oct 2017 13:15:11 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0085.outbound.protection.outlook.com [104.47.1.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FBFE13307F for ; Thu, 19 Oct 2017 13:15:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Osram.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=LdeLF07rpBNlqmR+naFXW6anDfbZzycEd07aJuB8NLA=; b=GtrZrCt4ELdxb9mPBMXUBvY1rvs6XctB2oVlmozkjC2HhvHwNJ6oiOicvLmjGsF4mb1B2ZpXES8I4AEZgEYJ+t6PCZM62JY1wPUFRapeQatKLAfyhxfnhmcjMPUYI3McX5OAsYwyTsilo5nfw5uIE5WuMx4b60U1ebJf8izCDso= Received: from VI1PR07MB3328.eurprd07.prod.outlook.com (10.175.244.10) by VI1PR07MB3326.eurprd07.prod.outlook.com (10.175.243.160) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.5; Thu, 19 Oct 2017 20:15:08 +0000 Received: from VI1PR07MB3328.eurprd07.prod.outlook.com ([fe80::5d7d:2995:baf9:4567]) by VI1PR07MB3328.eurprd07.prod.outlook.com ([fe80::5d7d:2995:baf9:4567%13]) with mapi id 15.20.0077.023; Thu, 19 Oct 2017 20:15:07 +0000 From: "Beck, Stefan" To: "ace@ietf.org" Thread-Topic: [Ace] multicast Thread-Index: AdNIng8OaAKxM8piQaWt4FllrU9xPQAJf8iAAAMwwFAAAwsVkAABon7QAAVGBYAABpYTwAAAhdvwAAAYQFA= Date: Thu, 19 Oct 2017 20:15:07 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=S.Beck@osram.com; x-originating-ip: [2001:a61:32c4:8e01:9868:1a1c:2dac:17ee] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR07MB3326; 6:qy/wRSvuUnigpv+1wmnpEhRuiGayp6rzetdOE5uNuVyVwuiMAaKmA+Lp3xN9Y5AM6pDzQLRfmUvmBZThyKXU+rmjN7a6wbK7qKruEygQWv78HCNlJUdt9DBjuW+nTLgkezgcbhfN5yPX7Glu19khXuxE2L2JGIYXLxj4SfKGyw15hFPqwqpc6qLZOuwB3/kR+c2iuhYytRpJE52VDY6fJe5BrVwFERNhR5193IWrUCP/wwkCEx+/To9raDPQBdvBt2p3YkGnjCOyE6IOjRiHTJGYm3rk6uUiwM/cUS5IWAaL6ZZfZiRnZwcL5a5rbIMC03uQDAbVp1AkZIDQThT0ig==; 5:aKY9H0alYsDqIVn6nWnlUswLh8xVO+6MO4tQmfCmMHuwtHHs7acHNW/5bJpZswibSbTp+0NosZU55A+o9I8QRYWFqEdFiofZbPd/ItnQrTf3ohG172OfIoQP5hsIEeqbIo9Xj6qMmqO8gLq1rCggZw==; 24:HHydky/nVdE20UpoMq8CQYw7FUDzxEEGMKn3s85TVniw9e+awE+AV/X+d3Ox13w72C0PZh2vcCgRxZXq/MLHbKHV8ocgs9IcHLXVcpfV6tA=; 7:HcMgSKpvpaR72RJZBIS0+5CE37fZHlS1tZN2OZ8BUuRwegJgmzSZFbi0BIHabMjbisEvgOFD3lCkV1tiKba3thu+aigff+J3SXUhkM3j4jZ8nXVycgiH5Vc1r4p4df1HFSD9SUXPHXtDXIH7YPbeWv1DoVPi6t8a+lHy/GDZE5N46rOaw6oGk3UoqnBnJB1HyrXhag2RiaMUyNvkyVulzlZ95yHE5FDzw/a6znozgL0= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 6e9ac0bd-2f8e-40db-a26b-08d5172e17e5 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254172)(4534020)(4602075)(4627075)(201703031133081)(201702281549075)(2017052603199)(49563074)(201703131423095); SRVR:VI1PR07MB3326; x-ms-traffictypediagnostic: VI1PR07MB3326: x-exchange-antispam-report-test: UriScan:(180628864354917)(189930954265078)(45079756050767); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(102415395)(6040450)(2401047)(8121501046)(5005006)(3002001)(93006095)(93001095)(10201501046)(100000703101)(100105400095)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123555025)(20161123560025)(20161123564025)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:VI1PR07MB3326; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:VI1PR07MB3326; x-forefront-prvs: 0465429B7F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(376002)(346002)(39860400002)(189002)(24454002)(199003)(13464003)(33656002)(5250100002)(54356999)(99936001)(105586002)(8676002)(8936002)(101416001)(5890100001)(50986999)(81166006)(1730700003)(2906002)(106356001)(81156014)(25786009)(68736007)(3280700002)(7736002)(102836003)(2351001)(6116002)(575784001)(86362001)(2501003)(76176999)(74316002)(305945005)(5640700003)(3660700001)(561944003)(5660300001)(99286003)(72206003)(6306002)(229853002)(55016002)(189998001)(478600001)(6246003)(9686003)(316002)(45080400002)(14454004)(2950100002)(7696004)(53936002)(6506006)(6436002)(53546010)(6916009)(966005)(93886005)(2900100001)(97736004); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR07MB3326; H:VI1PR07MB3328.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: osram.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0495_01D34927.B6724290" MIME-Version: 1.0 X-OriginatorOrg: Osram.com X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Oct 2017 20:15:07.9027 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: ec1ca250-c234-4d56-a76b-7dfb9eee0c46 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB3326 Archived-At: Subject: Re: [Ace] multicast 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, 19 Oct 2017 20:15:14 -0000 ------=_NextPart_000_0495_01D34927.B6724290 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit As mentioned in yesterday's call: give me/us some more time to work it out more precisely first. We have a meeting on Monday to verify and consolidate the current proposal - I believe I shouldn't speak up before that. (And I don't want to risk a shit-storm in case I get some parts wrong or immature; most of the people on this list are much smarter than me regarding these topics ;-) Stevie > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@arm.com] > Sent: Thursday, October 19, 2017 10:03 PM > To: Beck, Stefan ; ace@ietf.org > Subject: RE: [Ace] multicast > > So, what are you suggesting? > > -----Original Message----- > From: Ace [mailto:ace-bounces@ietf.org] On Behalf Of Beck, Stefan > Sent: 19 October 2017 21:59 > To: ace@ietf.org > Subject: Re: [Ace] multicast > > I totally agree with Mike. > BTW, Hannes, this was "part a." of Idea #1 - the only added value I've seen > was > that the device could raise an alarm - so there is awareness of an attack at > least > "after the fact". However, it adds complexity to the constrained device - > and > alternatively, one could just use one separate listener to the multicast > group, > that just does this job. It's multicast, so a single listener is sufficient > to handle > such type of alarms. > > "Part b." would even be more important to me: the multicasters (not the > listeners) are the constrained devices > that are unable to sign their messages in time. (Think of battery-powered > low > cost wall switches). > In that case they would need to pre-compile their multicast message (or set > of > messages- > eg. one or more for turn off / turn on / dim level x events), so they just > fire them > when the event happens. > Again, this adds a lot of complexity, and may even not be feasible at all > (in case > you have timing constraints in the crypto operations) > > Stevie > > > -----Original Message----- > > From: Ace [mailto:ace-bounces@ietf.org] On Behalf Of Michael StJohns > > Sent: Thursday, October 19, 2017 6:38 PM > > To: ace@ietf.org > > Subject: Re: [Ace] multicast > > > > On 10/19/2017 10:59 AM, Hannes Tschofenig wrote: > > > I suspect the idea is the following: > > > > > > 1) First, you would decrypt the packet and validate the mac > > > (assuming that it is an AEAD cipher) > > > 2) You execute the operation to meet the latency requirements. > > > 3) Then, you can take time to verify the digital signature (outside > > > the latency requirements) > > > > > > Is that the idea? > > > > > > > It can't possibly be. What do you do if the digital signature doesn't > > verify? Reverse the operation? Flicker the lights? Go back to the > > original > > levels? Flash "OOPS" in morse code? > > > > You need to verify the signature in advance of doing an operation > > authenticated and authorized by that signature.... > > > > Mike > > > > _______________________________________________ > > Ace mailing list > > Ace@ietf.org > > https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww > > .i > > > etf.org%2Fmailman%2Flistinfo%2Face&data=02%7C01%7C%7Cd6a2b032140a4 > > > 8082e1908d5170fc763%7Cec1ca250c2344d56a76b7dfb9eee0c46%7C0%7C0%7 > > > C636440278895347864&sdata=fpqgRpYFEvJxQUc4l2zlHM%2BUc7VaYLcp217q3 > > 2kHgLQ%3D&reserved=0 > 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. ------=_NextPart_000_0495_01D34927.B6724290 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITQDCCBZcw ggN/oAMCAQICEH2N5rAAeSCGTQvIxSt6cDswDQYJKoZIhvcNAQELBQAwZDETMBEGCgmSJomT8ixk ARkWA2NvbTEbMBkGCgmSJomT8ixkARkWC29zcmFtLWxpZ2h0MRMwEQYKCZImiZPyLGQBGRYDaW50 MRswGQYDVQQDDBJPU1JBTSBSb290IENBIDIwMTUwHhcNMTUwOTE3MDk0NzMyWhcNNDAwOTE3MDk1 NzI2WjBkMRMwEQYKCZImiZPyLGQBGRYDY29tMRswGQYKCZImiZPyLGQBGRYLb3NyYW0tbGlnaHQx EzARBgoJkiaJk/IsZAEZFgNpbnQxGzAZBgNVBAMMEk9TUkFNIFJvb3QgQ0EgMjAxNTCCAiIwDQYJ KoZIhvcNAQEBBQADggIPADCCAgoCggIBAMPOLdsM1I8Fll2DJ5A01Y53Cbq88OH6/ZocCMhm+9Ro Ce4RHnIB+WKi8+4fTUYU3DjwgXiI3tH6YG9j9o3ahkepcaRx1arkNJCfGs8UKbHQnxVM9n5Sv3lp Qm/OyE+qwl8sA77nVvrmAiYDIXdlJajITmqMBiSS5TfS7YO7knMLOv5bzd4ihUizsNGgVIvPyowz NpsA/yYzIJJhSYCdSc9Aji5MDF4fscYaffpdaM3VoZ4gdZiVgcYrnUVR4oFsNkoja6MV3Vk9o5py 8I6ff5Dhc6ZStrjYG1Q9iIIawvvi4e4A6ISRmxw3QBUZtlvBiC8Z2g/XVJnwz91RKIT1lQPbb2Cw 88E1nRVfF1txiVbQXw+TjNnyIVcxZS/p34yHXS9/gmPVXBUx3SYqAMI9vk/mqvkDGPAkIrpILTQT XcxkJVwQukR7mSpRw4bx0bg4mxH1x6tr4HqZe5hFtQTs+VckNiXLF5xFbOjFuck5UBRbW8J3ENCA ohtR/OdOAKFrS7Y5uPLA5ENMt+Ee2LeaEmwUIIioYZuToXngaimCg6m9aIGv9ytMUgnF3+9CRsKr drVw6Er2eKnGOXyBaMOkR14loeFISsA9UL85Ib80MHLZd8t0rkIpThZSKMMS/eKpGyZMv9HLYrVZ 1TssyD8pvu4yzrHGtrtehXu2JfRm+gzdAgMBAAGjRTBDMA4GA1UdDwEB/wQEAwIBBjASBgNVHRMB Af8ECDAGAQH/AgECMB0GA1UdDgQWBBRBffSxSuh0TnMOw0EPaZQm3UsWYTANBgkqhkiG9w0BAQsF AAOCAgEAoHwKO+Sh72eofY0BSZ+h+ajR9K7PJnwrLV557s4Id1EIvfMU8geELns5FsKOcAg9ipnv PPt0EVFFGulfyKRa0OPLvz7ofpEF0Bs8LVdAbqtImf9YGAmFtf7zIEdKmtDhGdKNabwt0QbVKOEs IzbQCeKXdFQ6/s0c+aSO/I1wLOekihbY1PY0IzNzDBfIbzDdFgcQfVc+kSlV2sSKjrqpG9qGvvwL VCWSCGFC/nAkb4g4PXhmOEIfo04vaibNHYFyl4ltZiWph/mism4MM1bAvPtZM8fFc1J6Sgkir7vD XQOCpQrxFYAKTqOIhAGn0hY/AY7198X5Jeh/tCUjatDz7AHuhdBTPC+XeGMyzvj7fkVwTv3TazEo u6jpmn6b2QY+0GdVytR4R0KFFIjGvxmOH4gg7pfOwplpjzE3K11CHGsEXQwAZNPnhj/EXEqSdx3g dUX77plIcnE8TwXxoY+aa9p1JfAmKVLT3vZbT8YDm83RkN7vcyGW/NBDq2OyihORutQxuy9PpYaM Txnzp9M620XFwKJbU3D0vYvHOgYFKQy71hgn/AX3KnQ+MXgiRCy5phiSTOTc8SZzuijBV2X30hX+ NAd3M4dQq4/VnK/Zop0LYornrFK79re2RLDqm1NP/k9yAOCc0WR7lQOhFW3R0JgFSmRSMsR4PWGg afjpMSgwggZ1MIIEXaADAgECAhMYAADE1BvnBAMoNJsjAAAAAMTUMA0GCSqGSIb3DQEBCwUAMGcx EzARBgoJkiaJk/IsZAEZFgNjb20xGzAZBgoJkiaJk/IsZAEZFgtvc3JhbS1saWdodDETMBEGCgmS JomT8ixkARkWA2ludDEeMBwGA1UEAwwVT1NSQU0gSXNzdWluZyBDQSAyMDE1MB4XDTE2MTEwMzE1 NTYxMVoXDTIxMTEwMjE1NTYxMVowcjELMAkGA1UEBhMCREUxDjAMBgNVBAoMBU9TUkFNMRwwGgYD VQQLDBNPU1JBTSBHbWJILCBHZXJtYW55MRQwEgYDVQQDDAtTdGVmYW4gQmVjazEfMB0GCSqGSIb3 DQEJARYQUy5CZWNrQG9zcmFtLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKht x104jKLZgCEyi4IKs7QjFm+csCMA3g4nYkhYmv5yK4Jtw6pixicOV4KUypkejZhbWmU+vyD3iY/0 aZ+uvwyNl90CA8fWmKdC1sF7xs7MtYvaQOycf47BTkqAdlOep9iTKxKpEW9B9LchU2iBUdhdQUsy jYrvq3MzPGw5ERW9dSwsXf4M5l3pDmlfPgCAYmEdRop4eUshqh87cr8AfzTm4XEcR7pG6lOgTkFa kZAltl6U3+VHQ2PQj6pw5VRHuaqPunZVFJL8e8kNErDgPkRnY2t12qNIbvxiSri3gSDHlOJJ/kND HHzI2+yOEA70nFfFG0tY6DcXwm8qWmT6uMECAwEAAaOCAg0wggIJMAsGA1UdDwQEAwIF4DA9Bgkr BgEEAYI3FQcEMDAuBiYrBgEEAYI3FQiCuLoUhdG3QIS5iTOG7K5ahOeweYENxscDgoHuRQIBZAIB CDBEBgkqhkiG9w0BCQ8ENzA1MA4GCCqGSIb3DQMCAgIAgDAOBggqhkiG9w0DBAICAIAwBwYFKw4D AgcwCgYIKoZIhvcNAwcwHQYDVR0OBBYEFKLokmPgby7PzMPWwS913WLd8w7yMB8GA1UdIwQYMBaA FAd1EUQRun6PdD2R16jhaq0s694uMF8GA1UdHwRYMFYwVKBSoFCGTmh0dHA6Ly9wa2kub3NyYW0t bGlnaHQuY29tL09TUkFNLUlTU1VJTkctQ0EtMjAxNS9DUkwvT1NSQU0tSVNTVUlORy1DQS0yMDE1 LmNybDBrBggrBgEFBQcBAQRfMF0wWwYIKwYBBQUHMAKGT2h0dHA6Ly9wa2kub3NyYW0tbGlnaHQu Y29tL09TUkFNLUlTU1VJTkctQ0EtMjAxNS9DZXJ0L09TUkFNLUlTU1VJTkctQ0EtMjAxNS5jcnQw HwYDVR0lBBgwFgYIKwYBBQUHAwQGCisGAQQBgjcKAwQwKQYJKwYBBAGCNxUKBBwwGjAKBggrBgEF BQcDBDAMBgorBgEEAYI3CgMEMBsGA1UdEQQUMBKBEFMuQmVja0Bvc3JhbS5jb20wDQYJKoZIhvcN AQELBQADggIBAAeoZQyM9u1NEpKRRDYMydLJ1wa1Y1m7rDfp5CPp0uni4qS5iXReWgIEzkhNCV5E oC0DosSOqnh2BkAkX+khNPuhLjjM/ApbFIqnnY+RD+xz3fxjx584TFmBugWHvKycYyD5NWhtD6Ej mWv6tUsxjYCv652LruxCdGJDbsaaEKP28te5dwMLD9wqSrBVU6ftbuzb9rL7IatpcBPCDkuCXSSQ lnAefbP2Y73wm1/+tbP/FxgyQjZUFR5qbXl2fMyynsrqLr3c6K7VxZs8+psbd+PiOlQnXcfGGCWR cZxr0cUZP/O861rFlE8s1OpxN5XI2pQIAzJx2toIsmHdk6hOY7t/2lYaMtqQLl2+cd2RoUMijM+1 Yi+v2WwuErdZzmgjTKht8rinng7GAuiSIQB489J4FgOEBWYne8zrl7jyuU9RYcYN9Nc5IZhK2Nfg 0xDh4tWeMWIuCg8f9ubeHOekdrg01cazDavxjaftQ25+2J5EwAWxc4ZPivOD9bkiYknSfg2iih2Y iRxUXqVq0q+qCfVDeys+MSFcu/WetN2ibvouzr+q4Aw+71j6M7FaWWpRz5FFKz40O/wAzoR2WB7u gGuT4RlAb7Yr8zM8TRpHKmrOSi19o/5qbGrPOX3u/B9UjK3LvR0n7TO6J9q0qxKveWlu6cofPQRd 2UVQoaNLB90mMIIHKDCCBRCgAwIBAgITWAAAAAXTK7hm1i4tGAAAAAAABTANBgkqhkiG9w0BAQsF ADBkMRMwEQYKCZImiZPyLGQBGRYDY29tMRswGQYKCZImiZPyLGQBGRYLb3NyYW0tbGlnaHQxEzAR BgoJkiaJk/IsZAEZFgNpbnQxGzAZBgNVBAMMEk9TUkFNIFJvb3QgQ0EgMjAxNTAeFw0xNTA5MzAx MjM2MTdaFw0yNzA5MzAxMjQ2MTdaMGcxEzARBgoJkiaJk/IsZAEZFgNjb20xGzAZBgoJkiaJk/Is ZAEZFgtvc3JhbS1saWdodDETMBEGCgmSJomT8ixkARkWA2ludDEeMBwGA1UEAwwVT1NSQU0gSXNz dWluZyBDQSAyMDE1MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAvbRnffh0KvDggawO /LfHMVmHl1fTbjzZQRjbbdUG6aKwTGeIpg7M4RXUIObssQ7sbSxuu77Vz2OFdSf5vk1fVZn8DFD8 dVB2AsYKPWZmBO+CYOvb2NCNqyLnt2/Mlk74gwTXdBgJsNjDbxs6yIfwn+rdGNt3gDwPeTiX+0Rn Ccj1NclFef00nW4kKFr2kkf+tVXMQx3pS7BQAjyuL+coQmOD5vIM+qU4dGy9ndYExTMTOPbDQaAO lx/vPXUSS1FvMJtKz//ODt/yew5RL55ZKuh6Mi7TvGTYcSH989NlXjYIYGQ0/5zfukj6CcscjInX 9W4U6NFvZL8YoVR6RLQkOTtfYa36t/iw16diSlBVeM7wq471fRXpytuGjLVtOl+oGGA7uM1QJ2OH OaXKzb6S28h8/W2urmHWMnSsBioznyio28I1PzyiwQeSe1NuMRobL0wSOTL/wljsxEkapvn4u3oW +SQCNyvXyigIYh+OaKNWFj62GclxPzoWkeT6FD6a6GS6geNyAF04N8fA/P1G/sSSCUcNdLodeEQz 17uSvIxKIFb0t7TgM40vgfwW929cv8hSoEfYQykeuPWPRc8nYkb9y6FSqpWxkXCFZRcVr826I7HY 3c2cfjFytMx4eyE5NzLV8n8jbEG0oM8c1SO1ojT4eQUgJgR2dE0OM6iJi6cCAwEAAaOCAc4wggHK MAsGA1UdDwQEAwIBhjAdBgNVHQ4EFgQUB3URRBG6fo90PZHXqOFqrSzr3i4wgaQGA1UdIASBnDCB mTCBlgYdKwYBBAGCNxUIgri6FIXRt0CEuYkzhuyuWoTnsHkwdTA8BggrBgEFBQcCAjAwHi4ATABl AGcAYQBsACAAcABvAGwAaQBjAHkAIABzAHQAYQB0AGUAbQBlAG4AdAAuMDUGCCsGAQUFBwIBFilo dHRwOi8vcGtpLm9zcmFtLWxpZ2h0LmNvbS9DUFMvaW5kZXguaHRtADASBgNVHRMBAf8ECDAGAQH/ AgEBMB8GA1UdIwQYMBaAFEF99LFK6HROcw7DQQ9plCbdSxZhMFkGA1UdHwRSMFAwTqBMoEqGSGh0 dHA6Ly9wa2kub3NyYW0tbGlnaHQuY29tL09TUkFNLVJvb3QtQ0EtMjAxNS9DUkwvT1NSQU0tUm9v dC1DQS0yMDE1LmNybDBlBggrBgEFBQcBAQRZMFcwVQYIKwYBBQUHMAKGSWh0dHA6Ly9wa2kub3Ny YW0tbGlnaHQuY29tL09TUkFNLVJvb3QtQ0EtMjAxNS9DZXJ0L09TUkFNLVJvb3QtQ0EtMjAxNS5j cnQwDQYJKoZIhvcNAQELBQADggIBACnQrysmPX41U+j/Q33kIHIGxFU0aYS0qrBmzGGGGNamqD8H 2SGy8LdCVcGeecE3XlKzZe+AnTTa1ejhHvhMJc8tHCgMLyvdSxKjJ69Rp75AaknxX15AwuFMkqLQ O+itE0PV6f3QHVdYevo2asZ3UgaQGOBFEo782qiNBDHawzuuXpXUTo4gWntTieXICIXWEenOgin1 901aoM0qzHTd8CXHdN8W7UNOE/6eCH02LofORiL2OzOAaz6aduK76KIEn3Fb2fbFAwKVIgTbvflA 9AWliukXYOSTGg9NXOyUVAE+ti4s720bYAJNrHTSbxbVpkDaWyZOhL/MsDAl3Q5/tMBbykhIy1pA 0zg5Q0QVr7B57x2Yo62nbduruNAnA0t+Q6DOrIRudaboAEeIXsQzVuUKd11o9mDOcVuetRxoS7lN 33zC3IHQajDFs8UHt4z6Cjj3EGttiS+ApUyDztgThD8bq7JSiAcFuXXD7zKmWN4TR6hKqTr9YGqA qhx/Dh7yYGUIOGAQi/EM0X1Ak73R45BopSyUm6oVj9i+w3SVvW66GxHbSUHqj8hA5Mokb9/ZC4Hn r/8CTC6MyfFJgksnMLEnhQOpCCaOzKtJ7UMnSeJHYHQUiDksIY5d3Y2T7QWDww7U95fMtGfPhqbA cF1qh4o9RYzuFWS6puXo7eRS2O1lMYIDwDCCA7wCAQEwfjBnMRMwEQYKCZImiZPyLGQBGRYDY29t MRswGQYKCZImiZPyLGQBGRYLb3NyYW0tbGlnaHQxEzARBgoJkiaJk/IsZAEZFgNpbnQxHjAcBgNV BAMMFU9TUkFNIElzc3VpbmcgQ0EgMjAxNQITGAAAxNQb5wQDKDSbIwAAAADE1DAJBgUrDgMCGgUA oIICFzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzEwMTkyMDE1 MDNaMCMGCSqGSIb3DQEJBDEWBBSWJrIXZd9FL1QNxtBCyVtRJiIbejCBjgYJKwYBBAGCNxAEMYGA MH4wZzETMBEGCgmSJomT8ixkARkWA2NvbTEbMBkGCgmSJomT8ixkARkWC29zcmFtLWxpZ2h0MRMw EQYKCZImiZPyLGQBGRYDaW50MR4wHAYDVQQDDBVPU1JBTSBJc3N1aW5nIENBIDIwMTUCExgAAMTU G+cEAyg0myMAAAAAxNQwgZAGCyqGSIb3DQEJEAILMYGAoH4wZzETMBEGCgmSJomT8ixkARkWA2Nv bTEbMBkGCgmSJomT8ixkARkWC29zcmFtLWxpZ2h0MRMwEQYKCZImiZPyLGQBGRYDaW50MR4wHAYD VQQDDBVPU1JBTSBJc3N1aW5nIENBIDIwMTUCExgAAMTUG+cEAyg0myMAAAAAxNQwgZMGCSqGSIb3 DQEJDzGBhTCBgjALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAoGCCqGSIb3DQMHMAsGCWCGSAFl AwQBAjAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAhowCwYJYIZIAWUDBAID MAsGCWCGSAFlAwQCAjALBglghkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAB2hooK/XvRIWP1Gj ABnCNTbZLcnVwn8IMlZB+O1ov9Rv0EuBfn4IrLbc6ZMo7SIeyF06imeDl57P/39b39SF07ZnN9TE EMP6UcBx9I/68hiUk+MpWpEpXCiDybWwATLXMcKmhAwW0hlMRiPb0qouGSkSc5bfcQ6hksDnNzl6 NRgCsFr964ezIeZrtq3nj1fL8VLjXVK2c8/wBn2aMNxbO8rWtakjD19ZIFQW9CCjpcMtBCtpHo4D zkCyutmHlvrw3GKIgBCJ+ewjALOcTVaECY7ulZBUXRDJ2g2Ftv+yXQZ56LhLhoxrI9dQvp4ZypYw oAzN9YvOp6t6/tC/04xv9QAAAAAAAA== ------=_NextPart_000_0495_01D34927.B6724290-- From nobody Thu Oct 19 13:16:25 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9147B1320C9 for ; Thu, 19 Oct 2017 13:16:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.911 X-Spam-Level: X-Spam-Status: No, score=-2.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, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ictoIvVEFTSd for ; Thu, 19 Oct 2017 13:16:21 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0057.outbound.protection.outlook.com [104.47.0.57]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91622129A89 for ; Thu, 19 Oct 2017 13:16:20 -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=0UofL/0qpxoLO879ng6em+HK6JCGu+xKOREGRRNQseA=; b=XqJ3ymC/RxFTa5NpT52hz1JwtommTh6cLJMF+umTpv4P6QRRf3QLLfthI1Xq7u7ej7PQrMZDwkY+YfFstcfBPqta53OmrbzPZgDr3XYoJ1Ssxm/YYtUf5es+iyKrzjaiQZ8cyUkQsXBCS6W91uI3x90F81td/4+biilgPIUSSgc= Received: from AM4PR0801MB2706.eurprd08.prod.outlook.com (10.167.90.148) by AM4PR0801MB2708.eurprd08.prod.outlook.com (10.167.90.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.7; Thu, 19 Oct 2017 20:16:17 +0000 Received: from AM4PR0801MB2706.eurprd08.prod.outlook.com ([fe80::6027:3e1:2bf7:68ed]) by AM4PR0801MB2706.eurprd08.prod.outlook.com ([fe80::6027:3e1:2bf7:68ed%14]) with mapi id 15.20.0077.022; Thu, 19 Oct 2017 20:16:17 +0000 From: Hannes Tschofenig To: "Beck, Stefan" , "ace@ietf.org" Thread-Topic: [Ace] multicast Thread-Index: AdNIng8OaAKxM8piQaWt4FllrU9xPQAJf8iAAAMwwFAAAwsVkAABon7QAAVGBYAABpYTwAAAhdvwAAAYQFAAAGdPoA== Date: Thu, 19 Oct 2017 20:16: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: [92.67.4.57] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM4PR0801MB2708; 6:CERWyOj+8xRMB7LeD0vHnQc9UpTup3aVPzKIg1LG8E0Cm35vsY/h39PFhIuCgaodc8VWBuKcVM+v/q6A6z5sXT36SesUQq/9wrDFeJX4xoY8T2NlE/4Uq7Qi+2TQ6HXnIeUXJGkd/T6hnRiD2m5Y4jc6srsZOaYmpzSNftaE4zRXztsbBbKR2zTAs3kDGKDyf4bQWm5N0RS36LjmqU8PlZ0eZf/mdoyPIEW4iwYck/g7cQMd/6ocKdkPSXldCvMvfyv7B4loEOL73oDFwKN+C9v6C2Z6F3XRnB0jPyVfW79N6NogpGsMlechBMtVvtaxHQqcqbIAxlbz/mJxdJSqQQ==; 5:kIc8gfqAazsN1uMX1vaoFkha7CIPp2nQJEkHIKNvrETybpPEgQHUwXO1WW2HE7wbjLcds/cz67oQ7c+4o3/BL3CwfpJzE1uYvZTJWTXmpKBOHMRK9F+33tXpJrHEMkfFlojGLB1CFws9tVSXIh/9/Q==; 24:Tjyp9wP3RO8lPOZx7rVMaYPBQ1y4sLzPn7XbSk6sJQGr8n6WHzBNEprKrSI2Dq1Rj1J0PES9N6wm72fmna4bdBb71sZ6SuPEzybWz9sLwO0=; 7:gVsQHp4yQIfc8PhaNkUnyye44x+8xd0ED8pVSeNWGdFZRVPf++KyVmhpfI6GKpqIwwogGRI2Ctqpg93si+wt9ZwIUbI1EVk6yfZQDRU/A1E/ieGvzVgg90mfgnrdKH7q0gJx+ttaBKMr18wmI1Ct4Qnn7WMxuBeUxgyMU2vWCcmiYjoQKK3fNkFZG1r75BmeeRugm/YmP2spPSHWhQ3nTeO1rmktqDionAezx3gg2Qk= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: d2daa959-553d-46f0-5365-08d5172e4187 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254172)(48565401081)(4534020)(4602075)(4627075)(201703031133081)(201702281549075)(2017052603199)(201703131423095); SRVR:AM4PR0801MB2708; x-ms-traffictypediagnostic: AM4PR0801MB2708: x-exchange-antispam-report-test: UriScan:(180628864354917)(189930954265078)(45079756050767); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(3002001)(93006095)(93001095)(10201501046)(100000703101)(100105400095)(6055026)(6041248)(20161123555025)(20161123564025)(20161123560025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM4PR0801MB2708; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM4PR0801MB2708; x-forefront-prvs: 0465429B7F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(346002)(376002)(39860400002)(40434004)(24454002)(13464003)(199003)(189002)(2906002)(2900100001)(33656002)(6246003)(110136005)(3660700001)(14454004)(8936002)(6436002)(106356001)(105586002)(3280700002)(68736007)(53546010)(305945005)(229853002)(6506006)(81156014)(5250100002)(97736004)(8676002)(316002)(93886005)(7736002)(561944003)(74316002)(81166006)(2501003)(55016002)(3846002)(45080400002)(5660300001)(6306002)(9686003)(189998001)(966005)(72206003)(478600001)(5890100001)(6116002)(102836003)(50986999)(25786009)(99286003)(575784001)(76176999)(66066001)(2950100002)(54356999)(101416001)(7696004)(53936002)(86362001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR0801MB2708; H:AM4PR0801MB2706.eurprd08.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Oct 2017 20:16:17.7177 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR0801MB2708 Archived-At: Subject: Re: [Ace] multicast 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, 19 Oct 2017 20:16:23 -0000 Tm8gcHJvYmxlbS4gVGFrZSB5b3VyIHRpbWUuDQoNCkNpYW8NCkhhbm5lcw0KDQotLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogQWNlIFttYWlsdG86YWNlLWJvdW5jZXNAaWV0Zi5vcmdd IE9uIEJlaGFsZiBPZiBCZWNrLCBTdGVmYW4NClNlbnQ6IDE5IE9jdG9iZXIgMjAxNyAyMjoxNQ0K VG86IGFjZUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtBY2VdIG11bHRpY2FzdA0KDQpBcyBtZW50 aW9uZWQgaW4geWVzdGVyZGF5J3MgY2FsbDogZ2l2ZSBtZS91cyBzb21lIG1vcmUgdGltZSB0byB3 b3JrIGl0IG91dCBtb3JlIHByZWNpc2VseSBmaXJzdC4NCldlIGhhdmUgYSBtZWV0aW5nIG9uIE1v bmRheSB0byB2ZXJpZnkgYW5kIGNvbnNvbGlkYXRlIHRoZSBjdXJyZW50IHByb3Bvc2FsIC0gSSBi ZWxpZXZlIEkgc2hvdWxkbid0IHNwZWFrIHVwIGJlZm9yZSB0aGF0Lg0KKEFuZCBJIGRvbid0IHdh bnQgdG8gcmlzayBhIHNoaXQtc3Rvcm0gaW4gY2FzZSBJIGdldCBzb21lIHBhcnRzIHdyb25nIG9y IGltbWF0dXJlOyBtb3N0IG9mIHRoZSBwZW9wbGUgb24gdGhpcyBsaXN0IGFyZSBtdWNoIHNtYXJ0 ZXIgdGhhbiBtZSByZWdhcmRpbmcgdGhlc2UgdG9waWNzIDstKQ0KDQpTdGV2aWUNCg0KPiAtLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBIYW5uZXMgVHNjaG9mZW5pZyBbbWFpbHRv Okhhbm5lcy5Uc2Nob2ZlbmlnQGFybS5jb21dDQo+IFNlbnQ6IFRodXJzZGF5LCBPY3RvYmVyIDE5 LCAyMDE3IDEwOjAzIFBNDQo+IFRvOiBCZWNrLCBTdGVmYW4gPFMuQmVja0Bvc3JhbS5jb20+OyBh Y2VAaWV0Zi5vcmcNCj4gU3ViamVjdDogUkU6IFtBY2VdIG11bHRpY2FzdA0KPg0KPiBTbywgd2hh dCBhcmUgeW91IHN1Z2dlc3Rpbmc/DQo+DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ IEZyb206IEFjZSBbbWFpbHRvOmFjZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQmVj aywgU3RlZmFuDQo+IFNlbnQ6IDE5IE9jdG9iZXIgMjAxNyAyMTo1OQ0KPiBUbzogYWNlQGlldGYu b3JnDQo+IFN1YmplY3Q6IFJlOiBbQWNlXSBtdWx0aWNhc3QNCj4NCj4gSSB0b3RhbGx5IGFncmVl IHdpdGggTWlrZS4NCj4gQlRXLCBIYW5uZXMsIHRoaXMgd2FzICJwYXJ0IGEuIiBvZiBJZGVhICMx IC0gdGhlIG9ubHkgYWRkZWQgdmFsdWUgSSd2ZQ0KPiBzZWVuIHdhcyB0aGF0IHRoZSBkZXZpY2Ug Y291bGQgcmFpc2UgYW4gYWxhcm0gLSBzbyB0aGVyZSBpcyBhd2FyZW5lc3MNCj4gb2YgYW4gYXR0 YWNrIGF0IGxlYXN0ICJhZnRlciB0aGUgZmFjdCIuIEhvd2V2ZXIsIGl0IGFkZHMgY29tcGxleGl0 eSB0bw0KPiB0aGUgY29uc3RyYWluZWQgZGV2aWNlIC0gYW5kIGFsdGVybmF0aXZlbHksIG9uZSBj b3VsZCBqdXN0IHVzZSBvbmUNCj4gc2VwYXJhdGUgbGlzdGVuZXIgdG8gdGhlIG11bHRpY2FzdCBn cm91cCwgdGhhdCBqdXN0IGRvZXMgdGhpcyBqb2IuDQo+IEl0J3MgbXVsdGljYXN0LCBzbyBhIHNp bmdsZSBsaXN0ZW5lciBpcyBzdWZmaWNpZW50IHRvIGhhbmRsZSBzdWNoIHR5cGUNCj4gb2YgYWxh cm1zLg0KPg0KPiAiUGFydCBiLiIgd291bGQgZXZlbiBiZSBtb3JlIGltcG9ydGFudCB0byBtZTog dGhlIG11bHRpY2FzdGVycyAobm90DQo+IHRoZQ0KPiBsaXN0ZW5lcnMpIGFyZSB0aGUgY29uc3Ry YWluZWQgZGV2aWNlcyB0aGF0IGFyZSB1bmFibGUgdG8gc2lnbiB0aGVpcg0KPiBtZXNzYWdlcyBp biB0aW1lLiAoVGhpbmsgb2YgYmF0dGVyeS1wb3dlcmVkIGxvdyBjb3N0IHdhbGwgc3dpdGNoZXMp Lg0KPiBJbiB0aGF0IGNhc2UgdGhleSB3b3VsZCBuZWVkIHRvIHByZS1jb21waWxlIHRoZWlyIG11 bHRpY2FzdCBtZXNzYWdlDQo+IChvciBzZXQgb2YNCj4gbWVzc2FnZXMtDQo+IGVnLiBvbmUgb3Ig bW9yZSBmb3IgdHVybiBvZmYgLyB0dXJuIG9uIC8gZGltIGxldmVsIHggZXZlbnRzKSwgc28gdGhl eQ0KPiBqdXN0IGZpcmUgdGhlbSB3aGVuIHRoZSBldmVudCBoYXBwZW5zLg0KPiBBZ2FpbiwgdGhp cyBhZGRzIGEgbG90IG9mIGNvbXBsZXhpdHksIGFuZCBtYXkgZXZlbiBub3QgYmUgZmVhc2libGUg YXQNCj4gYWxsIChpbiBjYXNlIHlvdSBoYXZlIHRpbWluZyBjb25zdHJhaW50cyBpbiB0aGUgY3J5 cHRvIG9wZXJhdGlvbnMpDQo+DQo+IFN0ZXZpZQ0KPg0KPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQo+ID4gRnJvbTogQWNlIFttYWlsdG86YWNlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJl aGFsZiBPZiBNaWNoYWVsIFN0Sm9obnMNCj4gPiBTZW50OiBUaHVyc2RheSwgT2N0b2JlciAxOSwg MjAxNyA2OjM4IFBNDQo+ID4gVG86IGFjZUBpZXRmLm9yZw0KPiA+IFN1YmplY3Q6IFJlOiBbQWNl XSBtdWx0aWNhc3QNCj4gPg0KPiA+IE9uIDEwLzE5LzIwMTcgMTA6NTkgQU0sIEhhbm5lcyBUc2No b2ZlbmlnIHdyb3RlOg0KPiA+ID4gSSBzdXNwZWN0IHRoZSBpZGVhIGlzIHRoZSBmb2xsb3dpbmc6 DQo+ID4gPg0KPiA+ID4gMSkgRmlyc3QsIHlvdSB3b3VsZCBkZWNyeXB0IHRoZSBwYWNrZXQgYW5k IHZhbGlkYXRlIHRoZSBtYWMNCj4gPiA+IChhc3N1bWluZyB0aGF0IGl0IGlzIGFuIEFFQUQgY2lw aGVyKQ0KPiA+ID4gMikgWW91IGV4ZWN1dGUgdGhlIG9wZXJhdGlvbiB0byBtZWV0IHRoZSBsYXRl bmN5IHJlcXVpcmVtZW50cy4NCj4gPiA+IDMpIFRoZW4sIHlvdSBjYW4gdGFrZSB0aW1lIHRvIHZl cmlmeSB0aGUgZGlnaXRhbCBzaWduYXR1cmUNCj4gPiA+IChvdXRzaWRlIHRoZSBsYXRlbmN5IHJl cXVpcmVtZW50cykNCj4gPiA+DQo+ID4gPiBJcyB0aGF0IHRoZSBpZGVhPw0KPiA+ID4NCj4gPg0K PiA+IEl0IGNhbid0IHBvc3NpYmx5IGJlLiAgIFdoYXQgZG8geW91IGRvIGlmIHRoZSBkaWdpdGFs IHNpZ25hdHVyZSBkb2Vzbid0DQo+ID4gdmVyaWZ5PyAgUmV2ZXJzZSB0aGUgb3BlcmF0aW9uPyAg IEZsaWNrZXIgdGhlIGxpZ2h0cz8gIEdvIGJhY2sgdG8gdGhlDQo+ID4gb3JpZ2luYWwNCj4gPiBs ZXZlbHM/ICBGbGFzaCAiT09QUyIgaW4gbW9yc2UgY29kZT8NCj4gPg0KPiA+IFlvdSBuZWVkIHRv IHZlcmlmeSB0aGUgc2lnbmF0dXJlIGluIGFkdmFuY2Ugb2YgZG9pbmcgYW4gb3BlcmF0aW9uDQo+ ID4gYXV0aGVudGljYXRlZCBhbmQgYXV0aG9yaXplZCBieSB0aGF0IHNpZ25hdHVyZS4uLi4NCj4g Pg0KPiA+IE1pa2UNCj4gPg0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+ID4gQWNlIG1haWxpbmcgbGlzdA0KPiA+IEFjZUBpZXRmLm9yZw0KPiA+ IGh0dHBzOi8vZW1lYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0 cHMlM0ElMkYlMkZ3DQo+ID4gd3cNCj4gPiAuaQ0KPiA+DQo+IGV0Zi5vcmclMkZtYWlsbWFuJTJG bGlzdGluZm8lMkZhY2UmZGF0YT0wMiU3QzAxJTdDJTdDZDZhMmIwMzIxNDBhNA0KPiA+DQo+IDgw ODJlMTkwOGQ1MTcwZmM3NjMlN0NlYzFjYTI1MGMyMzQ0ZDU2YTc2YjdkZmI5ZWVlMGM0NiU3QzAl N0MwJTcNCj4gPg0KPiBDNjM2NDQwMjc4ODk1MzQ3ODY0JnNkYXRhPWZwcWdScFlGRXZKeFFVYzRs MnpsSE0lMkJVYzdWYVlMY3AyMTdxMw0KPiA+IDJrSGdMUSUzRCZyZXNlcnZlZD0wDQo+IElNUE9S VEFOVCBOT1RJQ0U6IFRoZSBjb250ZW50cyBvZiB0aGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNobWVu dHMgYXJlDQo+IGNvbmZpZGVudGlhbCBhbmQgbWF5IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYgeW91 IGFyZSBub3QgdGhlIGludGVuZGVkDQo+IHJlY2lwaWVudCwgcGxlYXNlIG5vdGlmeSB0aGUgc2Vu ZGVyIGltbWVkaWF0ZWx5IGFuZCBkbyBub3QgZGlzY2xvc2UNCj4gdGhlIGNvbnRlbnRzIHRvIGFu eSBvdGhlciBwZXJzb24sIHVzZSBpdCBmb3IgYW55IHB1cnBvc2UsIG9yIHN0b3JlIG9yDQo+IGNv cHkgdGhlIGluZm9ybWF0aW9uIGluIGFueSBtZWRpdW0uIFRoYW5rIHlvdS4NCklNUE9SVEFOVCBO T1RJQ0U6IFRoZSBjb250ZW50cyBvZiB0aGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYXJl IGNvbmZpZGVudGlhbCBhbmQgbWF5IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYgeW91IGFyZSBub3Qg dGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0 ZWx5IGFuZCBkbyBub3QgZGlzY2xvc2UgdGhlIGNvbnRlbnRzIHRvIGFueSBvdGhlciBwZXJzb24s IHVzZSBpdCBmb3IgYW55IHB1cnBvc2UsIG9yIHN0b3JlIG9yIGNvcHkgdGhlIGluZm9ybWF0aW9u IGluIGFueSBtZWRpdW0uIFRoYW5rIHlvdS4NCg== From nobody Thu Oct 19 13:32:52 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7ECA13306B for ; Thu, 19 Oct 2017 13:32:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xW_k7vafSQgE for ; Thu, 19 Oct 2017 13:32:48 -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 689281342FE for ; Thu, 19 Oct 2017 13:32:47 -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 v9JKW9tL028189; Thu, 19 Oct 2017 22:32:09 +0200 (CEST) Received: from client-0109.vpn.uni-bremen.de (client-0109.vpn.uni-bremen.de [134.102.107.109]) (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 3yJ0w935FzzDXgP; Thu, 19 Oct 2017 22:32:09 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carsten Bormann In-Reply-To: Date: Thu, 19 Oct 2017 22:32:08 +0200 Cc: Mike Jones , Jim Schaad , "ace@ietf.org" X-Mao-Original-Outgoing-Id: 530137928.772563-ba456d3b0b8cd0db5e1c5bef25b218f8 Content-Transfer-Encoding: quoted-printable Message-Id: References: <008a01d348f9$179a96a0$46cfc3e0$@augustcellars.com> To: Hannes Tschofenig X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Ace] draft-ietf-ace-cbor-web-token-08 - CWT CBOR Tag 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, 19 Oct 2017 20:32:51 -0000 On Oct 19, 2017, at 21:30, Hannes Tschofenig = wrote: >=20 > For the cost saving of one byte we are essentially introduction = options here. I am wondering whether this byte is worth it. Two bytes. It=E2=80=99s not really an option, as in every context there will be a = single right way to do this. But yes, there are naked and tagged CWTs now. (If we only define the tagged version, very quickly there will be specs = that define a =E2=80=9Ccompressed CWT=E2=80=9D that just leaves out = those first two bytes=E2=80=A6) Gr=C3=BC=C3=9Fe, Carsten From nobody Thu Oct 19 14:14:40 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67D8E133011 for ; Thu, 19 Oct 2017 14:14:38 -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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=augustcellars.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fmhAfncfUmJW for ; Thu, 19 Oct 2017 14:14:36 -0700 (PDT) Received: from mail4.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF434132930 for ; Thu, 19 Oct 2017 14:14:36 -0700 (PDT) Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1508447669; h=from:subject:to:date:message-id; bh=D/KPR9wi/2RWEOQJT2hm91ZM3vIWxJMfE66LyR6KPnQ=; b=aYNscgG4MArpBR952+fsvM5Sbn085TwffArIdy3GGDKLPctKXeTzmK4DqCZaQUe4NxqXqCmuHkD NHTdl6xZ1P/Hb7xSNnnrrTaEb9HTPElRW/fqMqEu3oyd8fncgeqX0VjtPOQEDFr0CsvwNJnWzyRfJ ypX2OPLHdckwb25/ILFkhv6bNfbDJNhXC2gCuWRjG3RU5O1gXQFgZl3hPshr4RqlZ2UFyMz+Aw1Q9 5I9fH1URWWIEc76Vnw7D/vTL+8qFQVyx1+JyL8rbMew4iLCg7xcpyffwVXbDqM9cs1JSpxCjX3ruJ 58tU79oxBW6acVJncje29bSRXY7NG3jzyyhQ== Received: from mail2.augustcellars.com (192.168.1.201) by mail4.augustcellars.com (192.168.1.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 19 Oct 2017 14:14:29 -0700 Received: from Hebrews (173.8.216.38) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 19 Oct 2017 14:13:30 -0700 From: Jim Schaad To: 'Carsten Bormann' , 'Hannes Tschofenig' CC: 'Mike Jones' , References: <008a01d348f9$179a96a0$46cfc3e0$@augustcellars.com> In-Reply-To: Date: Thu, 19 Oct 2017 14:14:21 -0700 Message-ID: <00b701d3491f$3de49240$b9adb6c0$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQGLsOqKFomdfT9ZLF1VPxn9X86wSwJ3n3fpAo4Qth4Badn0FAFl8mRuAkaxMcmjKfrcwA== X-Originating-IP: [173.8.216.38] Archived-At: Subject: Re: [Ace] draft-ietf-ace-cbor-web-token-08 - CWT CBOR Tag 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, 19 Oct 2017 21:14:38 -0000 The type of location where it might show up is where one does a value = that is placed in an array where it can be either an A or a B and you = use the tag to distinguish between the two options. This can be very = useful in those cases. =20 > -----Original Message----- > From: Carsten Bormann [mailto:cabo@tzi.org] > Sent: Thursday, October 19, 2017 1:32 PM > To: Hannes Tschofenig > Cc: Mike Jones ; Jim Schaad > ; ace@ietf.org > Subject: Re: [Ace] draft-ietf-ace-cbor-web-token-08 - CWT CBOR Tag >=20 > On Oct 19, 2017, at 21:30, Hannes Tschofenig > wrote: > > > > For the cost saving of one byte we are essentially introduction = options > here. I am wondering whether this byte is worth it. >=20 > Two bytes. >=20 > It=E2=80=99s not really an option, as in every context there will be a = single right way to > do this. > But yes, there are naked and tagged CWTs now. >=20 > (If we only define the tagged version, very quickly there will be = specs that > define a =E2=80=9Ccompressed CWT=E2=80=9D that just leaves out those = first two bytes=E2=80=A6) >=20 > Gr=C3=BC=C3=9Fe, Carsten From nobody Thu Oct 19 21:39:55 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCD78133158 for ; Thu, 19 Oct 2017 21:39:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=alibaba-inc.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S1WHovVjexq9 for ; Thu, 19 Oct 2017 21:39:49 -0700 (PDT) Received: from out0-223.mail.aliyun.com (out0-223.mail.aliyun.com [140.205.0.223]) (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 B734F133075 for ; Thu, 19 Oct 2017 21:39:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1508474385; h=Date:Subject:From:To:Message-ID:Mime-version:Content-type; bh=OupG1WEJqAG67x2cY+L4tQ3AEWxjBw8BgvUmMDWO9EM=; b=G3Dc4sFMPA9wJjY1jv/13bwMMPNZicU9FMXO8H0zABGh0viRqCrbaP5dlr0tmCKz9jy4B0Vth1hrHsOmEsFhGRo5rh16AZejkwOUNUGlM5ltRgj6VhahuyMnuRy35XxzBZKD54getXDfwp/pBdUBcx/EeyhyT6nlPgzoOPV1fgQ= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R151e4; FP=0|-1|-1|-1|0|-1|-1|-1; HT=e02c03300; MF=kepeng.lkp@alibaba-inc.com; NM=1; PH=DS; RN=3; SR=0; TI=SMTPD_---.9BejU2y_1508474374; Received: from 10.65.151.222(mailfrom:kepeng.lkp@alibaba-inc.com ip:42.120.74.170) by smtp.aliyun-inc.com(127.0.0.1); Fri, 20 Oct 2017 12:39:41 +0800 User-Agent: Microsoft-MacOutlook/14.6.8.160830 Date: Fri, 20 Oct 2017 12:39:32 +0800 From: "Kepeng Li" To: ace CC: Kathleen Moriarty , Hannes Tschofenig Message-ID: Thread-Topic: [Ace] Minutes of ACE virtual interim meeting on 19th Oct about certificate enrollment Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3591347981_193859" Archived-At: Subject: [Ace] Minutes of ACE virtual interim meeting on 19th Oct about certificate enrollment 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, 20 Oct 2017 04:39:52 -0000 > ´ËÓʼþʹÓà MIME ¸ñʽ¡£ÓÉÓÚÓʼþÔĶÁ³ÌÐò²»ÄÜʶ±ð ´Ë¸ñʽ£¬Òò´Ë£¬¿ÉÄÜÎÞ·¨Ê¶±ð¸ÃÓʼþµÄ·Ö²¿»ò²¿·ÖÄÚÈÝ¡£ --B_3591347981_193859 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Hello all, Please find the initial minutes from the link below: https://datatracker.ietf.org/meeting/interim-2017-ace-03/materials/minutes-= i nterim-2017-ace-03-201710191300/ Please take a look and let me know if you have any corrections. Thanks, Kind Regards Kepeng =E5=8F=91=E4=BB=B6=E4=BA=BA: Ace on behalf of Li Kepeng =E6=97=A5=E6=9C=9F: Wednesday, 4 October 2017 at 11:23 PM =E8=87=B3: ace =E6=8A=84=E9=80=81: Kathleen Moriarty , Hannes Tschofenig =E4=B8=BB=E9=A2=98: [Ace] ACE virtual interim meeting on 19th Oct to discuss certifica= te enrollment =20 Hello all, =20 Please find the WebEx meeting information for our second call on certificate enrollment. We need to find a volunteer to prepare materials for the discussion. Pleas= e contact Hannes and me if you want to do so. ACE virtual interim meeting on 19th Oct to discuss certificate enrollment Thursday, October 19, 2017 1:00 pm | Greenwich Time (Reykjavik, GMT) | 1 hr Meeting number (access code): 317 298 947 Meeting password: EBZNCJjN =20 Add to Calendar=20 When it's time, join the meeting = . =20 Join by phone 1-877-668-4493 Call-in toll free number (US/Canada) 1-650-479-3208 Call-in toll number (US/Canada) Toll-free calling restrictions =20 Can't join the meeting? =20 IMPORTANT NOTICE: Please note that this WebEx service allows audio and othe= r information sent during the session to be recorded, which may be discoverable in a legal matter. By joining this session, you automatically consent to such recordings. If you do not consent to being recorded, discus= s your concerns with the host or do not join the session. _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace --B_3591347981_193859 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable
Hello all,

=
Please find the initial minutes from the link below:
https://datatracker.ietf.org/meetin= g/interim-2017-ace-03/materials/minutes-interim-2017-ace-03-201710191300/

Please take a look and let me know if you have an= y corrections.

Thanks,
Kind Regards
=
Kepeng

=E5=8F=91=E4=BB=B6=E4=BA=BA:= Ace <ace-bounces@ietf.org<= /a>> on behalf of Li Kepeng <kepeng.lkp@alibaba-inc.com>
=E6=97=A5=E6= =9C=9F: Wednesday, 4 October 2017 at 11:23 PM
=E8=87=B3: ace <ace@ietf.org&= gt;
=E6=8A=84=E9=80=81: Kathleen Moriarty <= kathleen.moriarty.ietf@gma= il.com>, Hannes Tschofenig <hannes.tschofenig@gmx.net>
=E4=B8=BB= =E9=A2=98: [Ace] ACE virtual interim meeting on 19th Oct to discuss certif= icate enrollment


Hello all,
Please find the WebEx meeting information for our second ca= ll on certificate enrollment.




 We = need to find a volunteer to prepare materials for the discussion. Please con= tact Hannes and me if you want to do so. 

ACE virtual interim meeting on 19th Oct to discuss certificate = enrollment
Thursday, October 19, 2017
1:00 pm  |  Greenwich Time (Reykjavik, GMT)=   |  1 hr
Meeting number (access code): 317 298 947
Meeting password: EBZNCJjN


&nbs= p;
Add to Calendar
When it's time, join the meeting.
&nbs= p;
Join by phone
1-877-668-4493 Call-in toll free num= ber (US/Canada)
1-650-479-3208&nb= sp;Call-in toll number (US/Canada)
Toll-free calling restrictions
 
Can't join the meeting?
 
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. By joining this session, you automatically c= onsent to such recordings. If you do not consent to being recorded, discuss = your concerns with the host or do not join the session.
_______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/ma= ilman/listinfo/ace --B_3591347981_193859-- From nobody Thu Oct 19 21:41:34 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E88B133158 for ; Thu, 19 Oct 2017 21:41:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=alibaba-inc.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2y3G4NfF6Vz2 for ; Thu, 19 Oct 2017 21:41:31 -0700 (PDT) Received: from out0-194.mail.aliyun.com (out0-194.mail.aliyun.com [140.205.0.194]) (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 6E880132397 for ; Thu, 19 Oct 2017 21:41:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1508474488; h=Date:Subject:From:To:Message-ID:Mime-version:Content-type; bh=yXYjpXylQhPQuY+twmpkQVISZdAi/NwtSJOnlx94GYw=; b=Alv0mF/BrvFZl3CUMJDK/uMiv0G5SQd3BkpmvsJDPk0lXUU1xp4xKcrW/YmZ72C04ETNBjUwIBf+nDz5wu8CZ31iKLlPEk1aehultqcdFzryZ8gHKLSfjw6od8jVQEYZoei6sty5/uXreARgzo73Y31tPNPMzJ3lpczkvpiay+Y= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R101e4; FP=0|-1|-1|-1|0|-1|-1|-1; HT=e02c03301; MF=kepeng.lkp@alibaba-inc.com; NM=1; PH=DS; RN=5; SR=0; TI=SMTPD_---.9BejU8l_1508474475; Received: from 10.65.151.222(mailfrom:kepeng.lkp@alibaba-inc.com ip:42.120.74.170) by smtp.aliyun-inc.com(127.0.0.1); Fri, 20 Oct 2017 12:41:22 +0800 User-Agent: Microsoft-MacOutlook/14.6.8.160830 Date: Fri, 20 Oct 2017 12:41:14 +0800 From: "Kepeng Li" To: Renzo Navas , Hannes Tschofenig CC: Kathleen Moriarty , Hannes Tschofenig , ace Message-ID: Thread-Topic: [Ace] Minutes of ACE virtual interim meeting on 18th Oct about ACE roadmap References: In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3591348082_217874" Archived-At: Subject: Re: [Ace] Minutes of ACE virtual interim meeting on 18th Oct about ACE roadmap 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, 20 Oct 2017 04:41:33 -0000 > ´ËÓʼþʹÓà MIME ¸ñʽ¡£ÓÉÓÚÓʼþÔĶÁ³ÌÐò²»ÄÜʶ±ð ´Ë¸ñʽ£¬Òò´Ë£¬¿ÉÄÜÎÞ·¨Ê¶±ð¸ÃÓʼþµÄ·Ö²¿»ò²¿·ÖÄÚÈÝ¡£ --B_3591348082_217874 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Thanks for your feedback. Please find the revised minutes here: https://datatracker.ietf.org/meeting/interim-2017-ace-02/materials/minutes-= i nterim-2017-ace-02-201710181300/ Kind Regards Kepeng =E5=8F=91=E4=BB=B6=E4=BA=BA: Renzo Navas =E6=97=A5=E6=9C=9F: Thursday, 19 October 2017 at 4:33 PM =E8=87=B3: Hannes Tschofenig =E6=8A=84=E9=80=81: Li Kepeng , Kathleen Moriarty , Hannes Tschofenig , ace =E4=B8=BB=E9=A2=98: Re: [Ace] Minutes of ACE virtual interim meeting on 18th Oct about ACE roadmap On Thu, Oct 19, 2017 at 10:27 AM, Hannes Tschofenig wrote: > =C3=98 I don't see my votes recorder, (neither Ludwig's); >=20 > =20 > We copied what was in the chat Window > =20 Ok then probably was a comparibilitty issue? I was on Linux HTML version of Webex, and Ludwig too -by his comments-. I sent my chat/votes (I could see them) , and I could also see (If I recall properly... now Im in doubt) Ludwig's voties too. In any case the conclusions reflect the consensus anyway. =20 > =20 >=20 > =C3=98 I don't know if the consensus was that MQTT is mid priority (and pub/s= ub > relegated to low), just that mqtt is rather new draft and we should discu= ss it > more. >=20 > =20 >=20 > I prefer to say that there are high priority items and then there is the = rest, > which requires further thoughts. I agree! =20 Saludos, Renzo --B_3591348082_217874 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable
Thanks for your feedback.

Please find the revised minutes here:
https://datatracker.ietf.org/meeting/int= erim-2017-ace-02/materials/minutes-interim-2017-ace-02-201710181300/

Kind Regards
Kepeng

=E5=8F=91=E4=BB=B6=E4=BA=BA: Renzo Navas <renzoefra@gmail.com>
=E6=97=A5=E6=9C=9F: Thursday, 19 October 2017 at 4:33 PM
=E8=87=B3: Hannes Tschofenig <Hannes.Tschofenig@arm.com>
=E6=8A=84=E9=80=81: Li Kepeng <kepeng.lkp@alibaba-inc.com>, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>, Hannes Tschofenig <hann= es.tschofenig@gmx.net>, ace <ace@iet= f.org>
=E4=B8=BB=E9=A2=98: Re: [Ace] Mi= nutes of ACE virtual interim meeting on 18th Oct about ACE roadmap
=


On Thu, Oct 19, 2017 at 10:27 AM, Hannes Tschofenig = <Hannes.Tschof= enig@arm.com> wrote:

=C3=98  I don't see my votes recorder, (neither Ludwig'= s);

 

We co= pied what was in the chat Window

 


Ok then probably was a comparibilitty issue? I wa= s on Linux HTML version of  Webex, and Ludwig too -by his comments-. I = sent my chat/votes (I could see them) , and I could also see (If I recall pr= operly... now Im in doubt) Ludwig's voties too.
In any case the co= nclusions reflect the consensus anyway.
 

 

=C3=98  I don't know if the consensus was that MQTT is = mid priority (and pub/sub relegated to low), just that mqtt is rather new dr= aft and we should discuss it more.

 

I prefer to say that there are hi= gh priority items and then there is the rest, which requires further thought= s.



I agree!
 

Saludos,
Renzo

--B_3591348082_217874-- From nobody Thu Oct 19 22:41:56 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11EA6126B71; Thu, 19 Oct 2017 22:41:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.601 X-Spam-Level: X-Spam-Status: No, score=-0.601 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=augustcellars.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z2XkvjUxozkh; Thu, 19 Oct 2017 22:41:53 -0700 (PDT) Received: from mail4.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FF1313202D; Thu, 19 Oct 2017 22:41:50 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1508478107; h=from:subject:to:date:message-id; bh=K8kDkIOU7hfqDDbsUY+5dvsNdIOLwuKnKR3+l/upOUI=; b=Y7oL4B/UBBvaIQQl6DRUPQ0nLkLXBTeA7BzFBbQbFQfMOMQHALHXsqJP6xDkUVds8BAtunJy8/K qjPWtsFprFNdGKKqdzLBVNFmBbp5UrdTJ8qGdhYLyviKwJQSiXZtspNiq81TWGXVmCDLEDDnxNB8Y chzsyRi2XmSqi3yw3SDGnaBsINuI7cO7JHEjjiDKbjn13zHHiOfbedF/URImWYU1o8VtCq9u6TI09 /kscmH9/4Uv2MJEgORZT8M5EAPUDxGB1iXQA4PPl82JEHA4uESofd4DfMTeCB91zIMbEd4S6b6B52 lvqIDGOUzY+qK7uR0sESG8tVzl/h+f9jSfyQ== Received: from mail2.augustcellars.com (192.168.1.201) by mail4.augustcellars.com (192.168.1.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 19 Oct 2017 22:41:46 -0700 Received: from Hebrews (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 19 Oct 2017 22:40:49 -0700 From: Jim Schaad To: , CC: Date: Thu, 19 Oct 2017 22:41:40 -0700 Message-ID: <00d401d34966$1c9d0260$55d70720$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdNJYqwwO1HMfVQtQ2OYNKV2BI41ZQ== X-Originating-IP: [73.180.8.170] Archived-At: Subject: [Ace] Comments on draft-tiloca-ace-oscoap-joining 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, 20 Oct 2017 05:41:55 -0000 After the interim meeting, I read this document through in order to produce a review. Instead you are going to get a meta-review. I am having a hard to seeing why this document exists in its current form and it is not some type of simple profile of the pub-sub security draft. While I am not sure that this document is a sub-set of that document, it appears to be about 90-99% a sub set of that document. Consider the following: You have both the publisher and subscriber roles as in the pub-sub draft. You have an entity which is doing key distribution in the system. For the pub-sub draft this is AS2 for you it is the RS, but they are performing the exact same set of tasks. The pub-sub draft as and endpoint which holds the encrypted messages, in its place you are using the multi-cast UDP channel. In both cases they are basically unprotected-untrusted entities to distribute the content message. The only difference is that in the pub-sub model the RS will also provide restricted access to publishing which is not enforceable here. Both of these documents are missing what I would consider to be core pieces. The pub-sub document does initial key distribution, while this document does not. Neither document does any discussion of how subsequent key distribution is done to deal with forward and backward security of messages. This document probably needs to define a new relationship, which might be more generally used, to say - this URL is where you get the security information for this URL which is published in the directory - esp in the case of multi-cast address URLs in the resource directory. You might also find that the correct answer is not to use a separate resource for each channel, but to allow for the use of URI path elements to define the security for a resource. Jim From nobody Thu Oct 19 22:49:11 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4568133075; Thu, 19 Oct 2017 22:49:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BEQ8PbLjjTNE; Thu, 19 Oct 2017 22:49:09 -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 C9BF013202D; Thu, 19 Oct 2017 22:49:08 -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 v9K5mSLn026644; Fri, 20 Oct 2017 07:48:28 +0200 (CEST) Received: from [192.168.217.124] (p5DC7FC78.dip0.t-ipconnect.de [93.199.252.120]) (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 3yJFG40LGkzDXkn; Fri, 20 Oct 2017 07:48:28 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carsten Bormann In-Reply-To: <00d401d34966$1c9d0260$55d70720$@augustcellars.com> Date: Fri, 20 Oct 2017 07:48:26 +0200 Cc: draft-tiloca-ace-oscoap-joining@ietf.org, draft-palombini-ace-coap-pubsub-profile@ietf.org, ace@ietf.org X-Mao-Original-Outgoing-Id: 530171306.62435-4bd39dbb7f25c7a2c2b645852e90929a Content-Transfer-Encoding: quoted-printable Message-Id: References: <00d401d34966$1c9d0260$55d70720$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Ace] Comments on draft-tiloca-ace-oscoap-joining 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, 20 Oct 2017 05:49:11 -0000 On Oct 20, 2017, at 07:41, Jim Schaad wrote: >=20 > The pub-sub document does initial key distribution, while this = document does > not. Neither document does any discussion of how subsequent key > distribution is done to deal with forward and backward security of = messages. By being more explicit that the =E2=80=9Cpubsub=E2=80=9D profile really = is a group communication profile, it would be easier to remember that we = have to solve all the usual problems in securing group communication, = including group membership maintenance. Gr=C3=BC=C3=9Fe, Carsten From nobody Fri Oct 20 01:41:49 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E12DD132026 for ; Fri, 20 Oct 2017 01:41:47 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 OcKLwl2Kehjo for ; Fri, 20 Oct 2017 01:41:45 -0700 (PDT) Received: from mail-pf0-x234.google.com (mail-pf0-x234.google.com [IPv6:2607:f8b0:400e:c00::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C22EF126DFE for ; Fri, 20 Oct 2017 01:41:45 -0700 (PDT) Received: by mail-pf0-x234.google.com with SMTP id t188so10107553pfd.10 for ; Fri, 20 Oct 2017 01:41:45 -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=wYj7AesoW5T6bg2OQNtDgdHpjc6QdsqqJPH+mC/REec=; b=I42aW2F+56r/S7tN+nwnq+C6dzhOQaaR3FQqg0F07ZUYaM4Qqb/kjITty4QACKfFCG CY7nKsDfAcmYv0we4ByIeUP7lLt2Nk/JiMRt7yHXEP+svoLyv8t1t5H7Zn3JbTjRs+nv iXevo86GoHJ3y/kpG0d+yUM4T7Q4h2DRmkhJsjVdAng3nz/8DS+gteAwqwZ76IAAs4Km Qu8VujT1+t9nT7/2CH4oQioOBA6cErS6DTNZ714uE+D3Zf9ipij8vwtpEitIs0Al51mC /4bBeaczEqVKDTKCek0Ntak4xIW7oBbpwgmROz6VUkCA5paGt1j7eBz3xOXzL9e7v/Jz aZRA== 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=wYj7AesoW5T6bg2OQNtDgdHpjc6QdsqqJPH+mC/REec=; b=oder+HwmtXrnoGwHE2NQhWRRuWDPQAL7rXyw4CbwMSy/0cmuI27FNTzCvSYmWTOXrp t0p4v9B1IgvwJxnn2g5y7rtlvUWYV1OE4JRxJ204zaKebSNH0jy3ar+SCYTxz63zf7ze zBvZnzatuQtJxaVJywVMImP0k8O31PDJVTE671ubsygL2uh+NuCywan9RCeABBeNiCYh lKQwDZuEq1gIdZvtr+We0wUzVpFUojEbc6xlcoCK0ONptByoIQ55gibJup2U8NN+8IaW HeOcaXpdv1DvNYx78Wwq4ZjtC91cPGOyyGEhuIItsnbyPI4pYywiTXhmA/lTKLj3atIW WWwA== X-Gm-Message-State: AMCzsaUwERFRML0zwmANVA+TZuITq18mcDohxmyGpp/4FKcr9eWYqfYU +z64r87QFp9TgnZQeY2gPng0ipdq02jRz4x4xyVI8Q== X-Google-Smtp-Source: ABhQp+TyiYQq6BFgpIrIqA8UHK36I51HjX2LUabs8P9WPxIs5Fek55ULaE5a2PL+6aemrYhW2trih+nvQkyqmIKmH7c= X-Received: by 10.98.198.77 with SMTP id m74mr4198848pfg.318.1508488904896; Fri, 20 Oct 2017 01:41:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.186.199 with HTTP; Fri, 20 Oct 2017 01:41:44 -0700 (PDT) In-Reply-To: <00b701d3491f$3de49240$b9adb6c0$@augustcellars.com> References: <008a01d348f9$179a96a0$46cfc3e0$@augustcellars.com> <00b701d3491f$3de49240$b9adb6c0$@augustcellars.com> From: Samuel Erdtman Date: Fri, 20 Oct 2017 10:41:44 +0200 Message-ID: To: Hannes Tschofenig Cc: Carsten Bormann , Mike Jones , ace , Jim Schaad Content-Type: multipart/alternative; boundary="94eb2c0ed820530a5c055bf67173" Archived-At: Subject: Re: [Ace] draft-ietf-ace-cbor-web-token-08 - CWT CBOR Tag 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, 20 Oct 2017 08:41:48 -0000 --94eb2c0ed820530a5c055bf67173 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I think there are cases when it is use full to have the tag (maybe few) and I think the draft is clear enough in discouraging the usage when not needed= . =E2=80=9CIts use is optional, and is intended for use in cases in which thi= s information would not otherwise be known.=E2=80=9D To write code that supports unwrapping the tag is very easy. Finally I personally think it is good to have the tag for completeness. On Thu, Oct 19, 2017 at 11:14 PM, Jim Schaad wrote= : > The type of location where it might show up is where one does a value > that is placed in an array where it can be either an A or a B and you use > the tag to distinguish between the two options. This can be very useful = in > those cases. > > > > > -----Original Message----- > > From: Carsten Bormann [mailto:cabo@tzi.org] > > Sent: Thursday, October 19, 2017 1:32 PM > > To: Hannes Tschofenig > > Cc: Mike Jones ; Jim Schaad > > ; ace@ietf.org > > Subject: Re: [Ace] draft-ietf-ace-cbor-web-token-08 - CWT CBOR Tag > > > > On Oct 19, 2017, at 21:30, Hannes Tschofenig > > wrote: > > > > > > For the cost saving of one byte we are essentially introduction > options > > here. I am wondering whether this byte is worth it. > > > > Two bytes. > > > > It=E2=80=99s not really an option, as in every context there will be a = single > right way to > > do this. > > But yes, there are naked and tagged CWTs now. > > > > (If we only define the tagged version, very quickly there will be specs > that > > define a =E2=80=9Ccompressed CWT=E2=80=9D that just leaves out those fi= rst two bytes=E2=80=A6) > > > > Gr=C3=BC=C3=9Fe, Carsten > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > --94eb2c0ed820530a5c055bf67173 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think there are cases when it is us= e full to have the tag (maybe few) and I think the draft is clear enough in= discouraging the usage when not needed.

=E2=80=9CIts use is optiona= l, and is intended for use in cases in which this information would not oth= erwise be known.=E2=80=9D

To write code that supports unwrappi= ng the tag is very easy.

Finally I personally think it is good= to have the tag for completeness.


On Thu, Oct 19, 2017 at 11:14 PM,= Jim Schaad <ietf@augustcellars.com> wrote:
The type of location where=C2=A0 it might show up is= where one does a value that is placed in an array where it can be either a= n A or a B and you use the tag to distinguish between the two options.=C2= =A0 This can be very useful in those cases.



> -----Original Message-----
> From: Carsten Bormann [mailto:cabo@tzi= .org]
> Sent: Thursday, October 19, 2017 1:32 PM
> To: Hannes Tschofenig <Hannes.Tschofenig@arm.com>
> Cc: Mike Jones <Mich= ael.Jones@microsoft.com>; Jim Schaad
> <ietf@augustcellars.com>; ace@ietf.org
> Subject: Re: [Ace] draft-ietf-ace-cbor-web-token-08 - CWT CBOR Ta= g
>
> On Oct 19, 2017, at 21:= 30, Hannes Tschofenig
> <Hannes.Tschofenig@arm= .com> wrote:
> >
> > For the cost=C2=A0 saving of one byte we are essentially introduc= tion options
> here. I am wondering whether this byte is worth it.
>
> Two bytes.
>
> It=E2=80=99s not really an option, as in every context there will be a= single right way to
> do this.
> But yes, there are naked and tagged CWTs now.
>
> (If we only define the tagged version, very quickly there will be spec= s that
> define a =E2=80=9Ccompressed CWT=E2=80=9D that just leaves out those f= irst two bytes=E2=80=A6)
>
> Gr=C3=BC=C3=9Fe, Carsten

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

--94eb2c0ed820530a5c055bf67173-- From nobody Fri Oct 20 06:20:43 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F2DE132396; Fri, 20 Oct 2017 06:20:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 xdb92_H22WZT; Fri, 20 Oct 2017 06:20:41 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8AC411320D8; Fri, 20 Oct 2017 06:20:40 -0700 (PDT) X-AuditID: c1b4fb30-ef1ff70000001b7f-5b-59e9f826ba0a Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.183.69]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 48.C9.07039.628F9E95; Fri, 20 Oct 2017 15:20:38 +0200 (CEST) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.69) with Microsoft SMTP Server (TLS) id 14.3.352.0; Fri, 20 Oct 2017 15:20:38 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ZYWydHoXhTq7O578qJBJx4nv39O21dTuI51fVENbVA0=; b=RCjy+ugnp8L8Xb4z84/CUaAjaUYXYjCFzqfrFEmp3x/fFUoMp9TtgauDGAXfSBeh79FZlA2GVmVodcen+ip4uxmBa5VsmeURQmGwvtTajsq5Bk817bdJmWr5nyDiFhcOYmD119GN01TLbXuzM1GHY2LmGAkDrQg6sPO1jSD5S0E= Received: from HE1PR07MB1529.eurprd07.prod.outlook.com (10.169.122.151) by HE1PR07MB1532.eurprd07.prod.outlook.com (10.169.122.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.156.4; Fri, 20 Oct 2017 13:20:36 +0000 Received: from HE1PR07MB1529.eurprd07.prod.outlook.com ([fe80::11af:c0a0:4d0d:d5f1]) by HE1PR07MB1529.eurprd07.prod.outlook.com ([fe80::11af:c0a0:4d0d:d5f1%13]) with mapi id 15.20.0077.019; Fri, 20 Oct 2017 13:20:36 +0000 From: Francesca Palombini To: Jim Schaad , "draft-tiloca-ace-oscoap-joining@ietf.org" , "draft-palombini-ace-coap-pubsub-profile@ietf.org" CC: "ace@ietf.org" Thread-Topic: Comments on draft-tiloca-ace-oscoap-joining Thread-Index: AdNJYqwwO1HMfVQtQ2OYNKV2BI41ZQAQZfUg Date: Fri, 20 Oct 2017 13:20:35 +0000 Message-ID: References: <00d401d34966$1c9d0260$55d70720$@augustcellars.com> In-Reply-To: <00d401d34966$1c9d0260$55d70720$@augustcellars.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.176.1.84] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HE1PR07MB1532; 6:YCtbr0iXt4u03THox6Jo5Sa4x4h3Hk7a8INnTHi3z3kD0ODJAiiyTkcPkkaFqbqu8d/KWrqNgU1S1OXg1OOKYtDMNj71qJFcXCTwr9zAONA0a8ABY4n5+9UHXvWYPJACs4Jscr2D/JhEq4QA+rqUGSiZ53v89EYDROxxg/nt/MdnmMala3b4gmKL8ScP07BpDC8w4Ibnh+R7wGkedpVu2HWS8aDiqoeuZQLELp82RuMDkqowjUsZGFd56yI2qLHXlqu2aBoYfWSX83EHI/1QYlhsrmWWapYpF/94RmVUrDtzUaxFOA0xqA/1zda5RMJQX89CMfEwAq4bPAM290OIgg==; 5:fxwIIQTej0LagRuvlq/fuZaxkds+X3xJMI0GdarMccarWOVbsU/OO30BMJzBtCkiA9BJCtLDdEA//IKS8//j4YLR3Kx3+kJFwEPPdiPrHoJwy4yjGRCqt6amEkYkPwAvoiJ1saLXrV87dP0BkRQeaw==; 24:OIZtsW5EVL1EFEjEMnyxNn1NNZNnbvJpUUkCg4BFTw+/yea29Tj4zw6RzHG2bUDLDpMXQR8rFtTPWMU+2lw4vKb2aER2MgyWoMT5DJTg4zE=; 7:j9mjnjOu4Ltl1lXurgz1xKfTnMJbmyw+mIT7hPRKBaFlDHR6HMcOdMbMVi6c4ZfO7p4PlWaqKd7RH1qmkfgWNsx6H93/szB8xw+atzGKQpxYpUl5EZax6/7s+CEN20UNDpRSruHs/ECDCgVdQ0TXBFnRdXUrcAneKpfBBfYssHPaNwNZ+tkCbyxTAIhFG2ao4YAel+YDNwcWODPFMMNFnXXTmw90d3H3s8kSCox1uek= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 0c757129-e5a6-47a7-a2cc-08d517bd597f x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627075)(201703031133081)(201702281549075)(2017052603229); SRVR:HE1PR07MB1532; x-ms-traffictypediagnostic: HE1PR07MB1532: x-exchange-antispam-report-test: UriScan:(192374486261705)(131327999870524); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(3231020)(93006095)(93001095)(10201501046)(3002001)(6041248)(20161123564025)(20161123560025)(20161123555025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:HE1PR07MB1532; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:HE1PR07MB1532; x-forefront-prvs: 0466CA5A45 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(376002)(39860400002)(346002)(189002)(13464003)(199003)(478600001)(229853002)(6506006)(25786009)(66066001)(3846002)(7736002)(68736007)(316002)(4326008)(110136005)(6436002)(102836003)(6116002)(53546010)(2501003)(74316002)(4743002)(6246003)(2201001)(230783001)(5660300001)(86362001)(8936002)(97736004)(106356001)(7696004)(305945005)(105586002)(55016002)(99286003)(101416001)(5250100002)(14454004)(9686003)(8676002)(81166006)(189998001)(3660700001)(54356999)(2950100002)(76176999)(53936002)(33656002)(2900100001)(3280700002)(50986999)(81156014)(2906002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB1532; H:HE1PR07MB1529.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=francesca.palombini@ericsson.com; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 0c757129-e5a6-47a7-a2cc-08d517bd597f X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Oct 2017 13:20:35.9494 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB1532 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02Se0hTURzHOffebdfp6DSn/vBBNdBA84nEEjFHVCJFURSuhJp50+F8cO8U DaEFMUtLDAIfLR9k4SPygWKmJb5Ks8w0lCJXPlCWrES0KeLK613Qf5/f7/s9v+/vHA5NyktE 3rQuw8CwGVq9UiylyhM6jgYHrFs1YdXvA1T233dI1dO2BkJ1e2SPqrHULo6l4lrMpeK42toN 4jRxQRqdzOh1OQwbGnNZmvqgZoXM+uqVO9lWh4xoTV6IXGjAkdBlHqAKkZSW4wEEVZbPzmII QU9R/05B4bskNE9YCEEpI6BudNFZzCH4bv0o5oeJcTSMzfwS8YIC2xDYC9coXiDxPnhmLiZ4 dseHwFI2iHhW4CjYqqkkBI6A3k2HhGcK+8Ps6KyIZxlOhM6K5u0AejvtMNS/28W3XXAsDExv 7lgQ9oPVG42kEOUFX+arCOFyGGq7P5ACe4B1ziESeC/8KDKKBfaD8aoixO8M2CSBkZYepykE 2u/ZkMAnYaGgmBBM5QiaHEvOhECwL004J52Aom82SuA0qBxaFAsHPolgY/2mRBB8YeLltHOq VQTt1rwSFFLx3+YCH4DqrhWxwEHwpGaJrNh5jN0wXD5PVSOqAXlwDJeUnhIREcKwuiscl5kR ksEYWtH2P+lt2wx7jqyL6j6EaaR0k/lYrRq5SJvD5aX3IaBJpUJWuLLdkiVr864xbOYlNlvP cH3Ih6aUXjL1q7EEOU7RGpg0hsli2H8qQbt4G5GENknOqM1tZ00dTPdgwbDDFzumDFOdUQ0T TdcV7kci9cuhufKli+OSU1Kz5+zqw2JVljFSF5x4yz9cE6oJUnrO9s68Rq356sn9C12Aj7H2 Gle3mPj48y9M4/71j5cP2t5Yku7PXeVMb1PzHYaGflfF8Wz2p36r7pzlj/SRkuJSteGBJMtp /wIrTq9ZIwMAAA== Archived-At: Subject: Re: [Ace] Comments on draft-tiloca-ace-oscoap-joining 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, 20 Oct 2017 13:20:42 -0000 Hi Jim, I don't think that your statement is correct: as far as I understood the os= coap-joining document, the RS is the group manager, while in the pubsub doc= ument (even generalizing it and making a group communication profile as Car= sten was suggesting) the entity that does group management is the AS2. I consider these differences a reason to have separate documents, yes, they= could be described in the same draft, but I don't see how that simplifies = the specifications. One more comment inline. Thanks, Francesca > -----Original Message----- > From: Jim Schaad [mailto:ietf@augustcellars.com] > Sent: den 20 oktober 2017 07:42 > To: draft-tiloca-ace-oscoap-joining@ietf.org; draft-palombini-ace-coap- > pubsub-profile@ietf.org > Cc: ace@ietf.org > Subject: Comments on draft-tiloca-ace-oscoap-joining >=20 > After the interim meeting, I read this document through in order to produ= ce > a review. Instead you are going to get a meta-review. >=20 > I am having a hard to seeing why this document exists in its current form= and > it is not some type of simple profile of the pub-sub security draft. > While I am not sure that this document is a sub-set of that document, it > appears to be about 90-99% a sub set of that document. Consider the > following: >=20 > You have both the publisher and subscriber roles as in the pub-sub draft. >=20 > You have an entity which is doing key distribution in the system. For th= e pub- > sub draft this is AS2 for you it is the RS, but they are performing the e= xact > same set of tasks. >=20 Yes, they are performing the same set of tasks on a high level, but they ar= e using the ACE framework differently in practice. For example the publishe= r and subscriber acquire the keys without using the token. > The pub-sub draft as and endpoint which holds the encrypted messages, in > its place you are using the multi-cast UDP channel. In both cases they a= re > basically unprotected-untrusted entities to distribute the content messag= e. > The only difference is that in the pub-sub model the RS will also provide > restricted access to publishing which is not enforceable here. >=20 > Both of these documents are missing what I would consider to be core > pieces. > The pub-sub document does initial key distribution, while this document > does not. Neither document does any discussion of how subsequent key > distribution is done to deal with forward and backward security of messag= es. > >=20 > This document probably needs to define a new relationship, which might be > more generally used, to say - this URL is where you get the security > information for this URL which is published in the directory - esp in the= case > of multi-cast address URLs in the resource directory. You might also fin= d that > the correct answer is not to use a separate resource for each channel, bu= t to > allow for the use of URI path elements to define the security for a resou= rce. >=20 > Jim > From nobody Fri Oct 20 06:30:09 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCB051320D8 for ; Fri, 20 Oct 2017 06:30:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ihtfp.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 iVHE_lFUhi6i for ; Fri, 20 Oct 2017 06:30:05 -0700 (PDT) Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 901F2132C2A for ; Fri, 20 Oct 2017 06:30:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 19D19E2065; Fri, 20 Oct 2017 09:30:04 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 25544-01; Fri, 20 Oct 2017 09:30:01 -0400 (EDT) Received: from securerf.ihtfp.org (unknown [IPv6:fe80::530:248d:f760:bb62]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail2.ihtfp.org (Postfix) with ESMTPS id D7E2FE2048; Fri, 20 Oct 2017 09:30:00 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1508506200; bh=YVa73J6vevom7gRK2U214HQ0oZ3y0P0OUxjEYoSf37U=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=U+C+oiNqppvN76bCkikhwuUqm2yzWevB9I2mnQsv54d8fl4pKURqe7Z0Ye94eRGEu HGWIU7JByX/mYqF1yqtbffA6XF2Ax+PA5TA5uUXz9vDhUEY/oep4mPJwsNx9Qv1NWC LoH5MM3lYut4eydjYtE2X0CXixG3QVvMpLyeKU30= Received: (from warlord@localhost) by securerf.ihtfp.org (8.15.2/8.15.2/Submit) id v9KDU0fa028449; Fri, 20 Oct 2017 09:30:00 -0400 From: Derek Atkins To: "Beck\, Stefan" Cc: Hannes Tschofenig , "ace\@ietf.org" References: Date: Fri, 20 Oct 2017 09:30:00 -0400 In-Reply-To: (Stefan Beck's message of "Thu, 19 Oct 2017 15:43:07 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Subject: Re: [Ace] multicast 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, 20 Oct 2017 13:30:08 -0000 Hi Stevie, "Beck, Stefan" writes: > Hi Derek, > > The requirement roughly is: > Assume a few light switches as multicasters and many luminaires as listeners > - turning lights on / off via multicast > The end-2-end processing (multicaster to encrypt&sign the message, the > network to transmit the message, and the listeners to validate&decrypt the > message) should not exceed ~200 ms. > > Stevie Thanks, that's a good start. A few follow-on questions: What's the realistic transmission speed you can expect? 100kbps? 1mbps? 10kbps? What's the realistic processing power / platform of the switches and liminaires? (base processor / clock speed) I'm asking because I do have access to a lightweight signature scheme where we can validate a 128-bit-security-level signature on an ARM Cortex M3 in 5.7ms (@48MHz). I'll also note that in this scenario encryption is a "nice to have" but does not seem "necessary", whereas integrity protection and source authentication is definitely necessary. I.e., if it's a trade-off between encryption and authentication/integrity I would choose authentication/integrity. Just my $0.02. -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Fri Oct 20 07:13:39 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AD5113339A; Fri, 20 Oct 2017 07:13:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 3NJyf2gC_639; Fri, 20 Oct 2017 07:13:23 -0700 (PDT) Received: from se-out1.mx-wecloud.net (se-out1.mx-wecloud.net [89.221.255.93]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E79E713337F; Fri, 20 Oct 2017 07:13:19 -0700 (PDT) Received: from sp-mail-2.sp.se (unknown [194.218.146.197]) by se-out1.mx-wecloud.net (Postfix) with ESMTPS id 666F22047B8; Fri, 20 Oct 2017 14:13:14 +0000 (UTC) Received: from [193.10.66.141] (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, 20 Oct 2017 16:13:15 +0200 Message-ID: <59EA0476.5090403@ri.se> Date: Fri, 20 Oct 2017 16:13:10 +0200 From: Marco Tiloca User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: Francesca Palombini , Jim Schaad , "draft-tiloca-ace-oscoap-joining@ietf.org" , "draft-palombini-ace-coap-pubsub-profile@ietf.org" CC: "ace@ietf.org" References: <00d401d34966$1c9d0260$55d70720$@augustcellars.com> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="0Ie36sKsVFxe1MphW7q5VNm5vmhSU2lc2" X-Originating-IP: [10.116.0.226] X-ClientProxiedBy: sp-mail-1.sp.se (10.100.0.161) To sp-mail-2.sp.se (10.100.0.162) X-CMAE-Score: 0 X-CMAE-Analysis: v=2.2 cv=cdiiljLM c=1 sm=1 tr=0 a=L5DDne6A+dD0FbDkt2Fblw==:117 a=L5DDne6A+dD0FbDkt2Fblw==:17 a=sZ8rJzgPlrQA:10 a=02M-m0pO-4AA:10 a=VrHXGImtAAAA:8 a=48vgC7mUAAAA:8 a=xPT6tdSuAAAA:8 a=XkYX7XBwUzrsRoDfeSgA:9 a=EkawJCAG25wRoCjN:21 a=uaerPYD_IUvpGIZr:21 a=pILNOxqGKmIA:10 a=_-38nKkDacA3SF9XkmQA:9 a=ONNS8QRKHyMA:10 a=rjybpTLx1R2UrS7S5igv:22 a=w1C3t2QeGrPiZgrLijVG:22 a=80PJfYVSYmV_jLpvUEnt:22 X-Virus-Scanned: clamav-milter 0.99.2 at MailSecurity X-Virus-Status: Clean X-MailSecurity-Status: 0 X-Scanned-By: WeCloud MailSecurity X-MailSecurity-Score: 0 Archived-At: Subject: Re: [Ace] Comments on draft-tiloca-ace-oscoap-joining 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, 20 Oct 2017 14:13:38 -0000 --0Ie36sKsVFxe1MphW7q5VNm5vmhSU2lc2 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Jim, I support Francesca's thoughts on this. Please, find inline a few more comments. Ciao, /Marco On 2017-10-20 15:20, Francesca Palombini wrote: > Hi Jim, > > I don't think that your statement is correct: as far as I understood th= e oscoap-joining document, the RS is the group manager, while in the pubs= ub document (even generalizing it and making a group communication profil= e as Carsten was suggesting) the entity that does group management is the= AS2. > > I consider these differences a reason to have separate documents, yes, = they could be described in the same draft, but I don't see how that simpl= ifies the specifications. > > One more comment inline. > > Thanks, > Francesca > >> -----Original Message----- >> From: Jim Schaad [mailto:ietf@augustcellars.com] >> Sent: den 20 oktober 2017 07:42 >> To: draft-tiloca-ace-oscoap-joining@ietf.org; draft-palombini-ace-coap= - >> pubsub-profile@ietf.org >> Cc: ace@ietf.org >> Subject: Comments on draft-tiloca-ace-oscoap-joining >> >> After the interim meeting, I read this document through in order to pr= oduce >> a review. Instead you are going to get a meta-review. >> >> I am having a hard to seeing why this document exists in its current f= orm and >> it is not some type of simple profile of the pub-sub security draft. >> While I am not sure that this document is a sub-set of that document, = it >> appears to be about 90-99% a sub set of that document. Consider the >> following: >> >> You have both the publisher and subscriber roles as in the pub-sub dra= ft. >> >> You have an entity which is doing key distribution in the system. For= the pub- >> sub draft this is AS2 for you it is the RS, but they are performing th= e exact >> same set of tasks. >> > Yes, they are performing the same set of tasks on a high level, but the= y are using the ACE framework differently in practice. For example the pu= blisher and subscriber acquire the keys without using the token. > >> The pub-sub draft as and endpoint which holds the encrypted messages, = in >> its place you are using the multi-cast UDP channel. In both cases the= y are >> basically unprotected-untrusted entities to distribute the content mes= sage. >> The only difference is that in the pub-sub model the RS will also prov= ide >> restricted access to publishing which is not enforceable here. >> >> Both of these documents are missing what I would consider to be core >> pieces. >> The pub-sub document does initial key distribution, while this documen= t >> does not. Neither document does any discussion of how subsequent key >> distribution is done to deal with forward and backward security of mes= sages. As to the "initial key distribution", I guess you refer to the group keying material that the Group Manager provides to the joining endpoint. =46rom a previous discussion we had on this in Prague, I thought you were= suggesting to specify the actual group OSCOAP key material provisioning on the group OSCOAP draft, rather than in this document. Of course, one of them has to describe such key provisioning. As to the "subsequent key distribution", we were trying to keep the definition of the specific group key revocation/renewal scheme enforced by the Group Manager out of the scope of both the group OSCOAP draft and this joining document. On the other hand, both documents acknowledge the importance of such service and discuss it in the "Security considerations" section. Such considerations cover both backward and forward security in the group OSCOAP draft, while only backward security on this document as related solely to the join process. >> >> This document probably needs to define a new relationship, which might= be >> more generally used, to say - this URL is where you get the security >> information for this URL which is published in the directory - esp in = the case >> of multi-cast address URLs in the resource directory. You might also = find that >> the correct answer is not to use a separate resource for each channel,= but to >> allow for the use of URI path elements to define the security for a re= source. Thanks, we will think more on this. >> >> Jim >> > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace --=20 Marco Tiloca, PhD Research Institutes of Sweden RISE ICT/SICS Isafjordsgatan 22 / Kistag=E5ngen 16 SE-164 40 Kista (Sweden) Phone: +46 (0)70 60 46 501 https://www.sics.se https://www.sics.se/~marco/ The RISE institutes Innventia, SP and Swedish ICT have merged in order to become a stronger research and innovation partner for businesses and society. SICS Swedish ICT AB, has now changed name to RISE SICS AB. --0Ie36sKsVFxe1MphW7q5VNm5vmhSU2lc2 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJZ6gR2AAoJEO4mZLQOWNpDtAwH/35l10rRYWum8S/58FH7Vwdg MQS6f5WYq08NWlcjC6rttWVo4Ztmg7iQmX4tBZOrTA0Sg9NJz7JrsrcoQEJ8mSLe XYszaoxD7kFZI064Q/EKauti8T+j/bQ2Ts+iW89smBVgz4Nf0GabBeIWRHbetzXF MQ7kwbI+N25iJv4HvwdcdApLEs1ocK0pTwnxoXwHrBN4Jn5fBBuVTL3uuDtLkdVv bTab9zW5eOYUbTEkFpD4LICvxtjURXj3LrmkJ3vvc+Kjg+l6fjGKHcu2uPVwLpY6 JQuBuRXYontwMpujyYKvKaOkkUUVXeDe6wjOCU+k4B5rKaQIjyC4ywO+3EbV7ss= =mROI -----END PGP SIGNATURE----- --0Ie36sKsVFxe1MphW7q5VNm5vmhSU2lc2-- From nobody Fri Oct 20 08:11:29 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42D4D133343 for ; Fri, 20 Oct 2017 08:11:28 -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 5zGxP6g6h8TN for ; Fri, 20 Oct 2017 08:11:26 -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 B975E1320D9 for ; Fri, 20 Oct 2017 08:11:26 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 572C3200A5 for ; Fri, 20 Oct 2017 11:11:38 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id CF0D980220 for ; Fri, 20 Oct 2017 11:11:25 -0400 (EDT) From: Michael Richardson To: "ace\@ietf.org" In-Reply-To: References: X-Mailer: MH-E 8.6; nmh 1.7-RC3; 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] multicast 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, 20 Oct 2017 15:11:28 -0000 --=-=-= Content-Type: text/plain Hannes Tschofenig wrote: > Hi Stefan, > I am trying to understand your ideas. > ~snip ~ >> For multicast, my focus is on using asymmetric encryption for > authentication & integrity, and using symmetric encryption for > confidentiality. > In your view, you are sending a multicast message that will contain a > digital signature and is also encrypted using symmetric key crypto? Is the symmetric key for privacy in addition to whatever L2 security there might be? Is it in fact the L2 security? Or does it replace L2 security with L3 (L7?) security? Is the target network 15.4 (like), or 802.11-like? If 802.11-like is it managed or adhoc/mesh? -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlnqEh0ACgkQgItw+93Q 3WXtXQgAgfrALhePHt4qZZm+ZEwDCwVaB9dHM2c+AbPVwsFF6EY64aV28Unzt95b 61WjniHPMjT+Ciy+aXAXnJ7ilALLwvPliZ9zQh6ncvfCU7bcvSzKHtbZatqnx2YV EET6fTZQyK2l4DhTfqhNl+qbJEeepAht+zFo11fZn8zyzPw64glTtpWkkoFG4gAG Hzhw21gvjxC+1Ak+hpUP1bW+ylAPtBJyXLEOTa58E3Ks2EXQFmUT0ouJkNJlKPZz eVqRfuXeskva5QgfJDp1D0nUpoMgkDhjpAZwRP3JOkgEjy/4+yd25Lz/OC+pmED1 XjEMBwbqNFAarDnBPSmtppE/9FKr2w== =lgnE -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Oct 20 09:51:57 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B3C01342F0; Fri, 20 Oct 2017 09:51:55 -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, 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=augustcellars.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vb9qQ5qR5x_9; Fri, 20 Oct 2017 09:51:53 -0700 (PDT) Received: from mail4.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56FD31321BB; Fri, 20 Oct 2017 09:51:53 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1508518309; h=from:subject:to:date:message-id; bh=K/b+9wWUsMOtdOJORYzHd07nBHQoW5xa+eLCtE2Nsi0=; b=UcS361nXDFS8HwLzCkZ7l/KXITZ8qWCfpZg1OuiUtJiynB4G5REMadEV24YGZ2JuV9v7S9U3Loa OBiuiw34Y9H5pC2kAxamOplhFm/jyrgvm6VihHNBYDaxdI9NfjvrCspmtcXfN0CmOJzQl9QJcylc4 VTT3xb9pYBCfhKHVaJTLM+JE86zpHmefPAQL45UtqQcLq3qJucdL9a9pB3hD/VM6b1cEbLvjGOr+x RB7umXr2QxqFYoNos9+OlJ19a4MjHRcpZbxY+8O7+/vJcduWa51W3WRfTx92XzAzhdMNIuYMzTDj2 qW5nBBCIedsZOoHspBQZlYn8A9oTe93ZSKlg== Received: from mail2.augustcellars.com (192.168.1.201) by mail4.augustcellars.com (192.168.1.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 20 Oct 2017 09:51:48 -0700 Received: from Hebrews (192.168.1.162) by mail2.augustcellars.com (192.168.1.201) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 20 Oct 2017 09:50:30 -0700 From: Jim Schaad To: 'Francesca Palombini' , , CC: References: <00d401d34966$1c9d0260$55d70720$@augustcellars.com> In-Reply-To: Date: Fri, 20 Oct 2017 09:51:22 -0700 Message-ID: <010401d349c3$aabe3980$003aac80$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQJPKWYWWFxnPPkEUpBv4LHAZyWK4wMfwMs8odwzB4A= X-Originating-IP: [192.168.1.162] Archived-At: Subject: Re: [Ace] Comments on draft-tiloca-ace-oscoap-joining 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, 20 Oct 2017 16:51:55 -0000 Francesca, My first concern is that the messages being send around to do the group communication setup should be, if not identical, highly coordinated in how they are formatted. I don't really want two different sets of messages. I understand, and indeed noted, that the current model of how they are using the authentication structure is different. However, I believe that I could easily map things so that the structures are going to be the same. Consider the following change of the join picture. Kill the current AS entity from the system as not providing new functionality. Rename the current RS entity to be AS2 mapping to the same current functionality as is provided in the pub-sub draft. Create a new collective RS entity which consists of all of the entities (other than me) which are listening to the multicast address. If you do that then the picture of the multicast and pub-sub systems have a great deal in common. The one thing that gets lost is the ability to ask the current RS where the AS lives, but this is the type of information that Ludwig is saying should be able to be placed in the resource directory (see the oauth-authz document). This is where the question of what the resource types and relationships between different elements in the RD would come into focus. It would also be possible that AS2 in the new module would just have a directory of multicast items which it supports. The pub-sub discovery of resources is currently designed to be done via the resource directory, so there is no reason that the multicast ones should not as well. I think that this means that the structure between the two documents is far closer to the same that either of you realize. Jim > -----Original Message----- > From: Francesca Palombini [mailto:francesca.palombini@ericsson.com] > Sent: Friday, October 20, 2017 6:21 AM > To: Jim Schaad ; draft-tiloca-ace-oscoap- > joining@ietf.org; draft-palombini-ace-coap-pubsub-profile@ietf.org > Cc: ace@ietf.org > Subject: RE: Comments on draft-tiloca-ace-oscoap-joining > > Hi Jim, > > I don't think that your statement is correct: as far as I understood the oscoap- > joining document, the RS is the group manager, while in the pubsub > document (even generalizing it and making a group communication profile as > Carsten was suggesting) the entity that does group management is the AS2. > > I consider these differences a reason to have separate documents, yes, they > could be described in the same draft, but I don't see how that simplifies the > specifications. > > One more comment inline. > > Thanks, > Francesca > > > -----Original Message----- > > From: Jim Schaad [mailto:ietf@augustcellars.com] > > Sent: den 20 oktober 2017 07:42 > > To: draft-tiloca-ace-oscoap-joining@ietf.org; > > draft-palombini-ace-coap- pubsub-profile@ietf.org > > Cc: ace@ietf.org > > Subject: Comments on draft-tiloca-ace-oscoap-joining > > > > After the interim meeting, I read this document through in order to > > produce a review. Instead you are going to get a meta-review. > > > > I am having a hard to seeing why this document exists in its current > > form and it is not some type of simple profile of the pub-sub security draft. > > While I am not sure that this document is a sub-set of that document, > > it appears to be about 90-99% a sub set of that document. Consider > > the > > following: > > > > You have both the publisher and subscriber roles as in the pub-sub draft. > > > > You have an entity which is doing key distribution in the system. For > > the pub- sub draft this is AS2 for you it is the RS, but they are > > performing the exact same set of tasks. > > > > Yes, they are performing the same set of tasks on a high level, but they are > using the ACE framework differently in practice. For example the publisher > and subscriber acquire the keys without using the token. > > > The pub-sub draft as and endpoint which holds the encrypted messages, > > in its place you are using the multi-cast UDP channel. In both cases > > they are basically unprotected-untrusted entities to distribute the content > message. > > The only difference is that in the pub-sub model the RS will also > > provide restricted access to publishing which is not enforceable here. > > > > Both of these documents are missing what I would consider to be core > > pieces. > > The pub-sub document does initial key distribution, while this > > document does not. Neither document does any discussion of how > > subsequent key distribution is done to deal with forward and backward > security of messages. > > > > > > This document probably needs to define a new relationship, which might > > be more generally used, to say - this URL is where you get the > > security information for this URL which is published in the directory > > - esp in the case of multi-cast address URLs in the resource > > directory. You might also find that the correct answer is not to use > > a separate resource for each channel, but to allow for the use of URI path > elements to define the security for a resource. > > > > Jim > > From nobody Fri Oct 20 13:56:38 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36DEC133071 for ; Fri, 20 Oct 2017 13:56:37 -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, 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=augustcellars.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6d0xPwP5nn1n for ; Fri, 20 Oct 2017 13:56:35 -0700 (PDT) Received: from mail4.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FC8E1326F6 for ; Fri, 20 Oct 2017 13:56:35 -0700 (PDT) Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1508532991; h=from:subject:to:date:message-id; bh=kaOPdtc/uUYhiZSHTbrOYflZ9mqxHjPjRJGlBdcX8Jw=; b=hEwFBOv7X+kKDQL1Fe6o/iQRpg6OZvuJdC+i7AV8S7DFC13ko0XFiNcpiMeHYbAWi5MGvJjms6X /CunNWdmDmAr9RCjZVbxO3knJZUE1sfVLnI9yTGOLfMOcM9fAFstuEBncIpacnR8mHL8AUuYIS3+b PspDvzL8jKDx5lRnmE6ol9pcs58ylVCUhmrfPCVOpv5dHdLEgOT8v4qts4QvbLCK/BBlLJ3GueM97 zX0/XjWGQKRG3qdt6Ap51BEavSiwWgj5NzoTowaDccpqCDeG/QYup3AEvc83IkTCQiucRrTD4HHpa 6psbKvAI9GVHpergiuXcM1/6z5u2GpBZGD9g== Received: from mail2.augustcellars.com (192.168.1.201) by mail4.augustcellars.com (192.168.1.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 20 Oct 2017 13:56:30 -0700 Received: from Hebrews (173.8.216.38) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 20 Oct 2017 13:55:13 -0700 From: Jim Schaad To: References: <008a01d348f9$179a96a0$46cfc3e0$@augustcellars.com> <00b701d3491f$3de49240$b9adb6c0$@augustcellars.com> In-Reply-To: <00b701d3491f$3de49240$b9adb6c0$@augustcellars.com> Date: Fri, 20 Oct 2017 13:56:06 -0700 Message-ID: <012001d349e5$da7c6440$8f752cc0$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQGLsOqKFomdfT9ZLF1VPxn9X86wSwJ3n3fpAo4Qth4Badn0FAFl8mRuAkaxMckB8XolGKMb+8Jw X-Originating-IP: [173.8.216.38] Archived-At: Subject: [Ace] FW: draft-ietf-ace-cbor-web-token-08 - CWT CBOR Tag 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, 20 Oct 2017 20:56:37 -0000 Just to highlight this and make it concrete. COSE did the same thing in defining optional tags that can be used. = Looking at the CWT document, the tags are being used because without the = tag one cannot tell what the security operation is that is being used. = However the OAuth-Authz draft is using the COSE_Encrypt object without a = tag because there are other indications (the name in the map) such that = which COSE object is being used is clearly defined.=20 I expect similar usages to occur with CWT in the future. -----Original Message----- From: Ace [mailto:ace-bounces@ietf.org] On Behalf Of Jim Schaad Sent: Thursday, October 19, 2017 2:14 PM To: 'Carsten Bormann' ; 'Hannes Tschofenig' = Cc: 'Mike Jones' ; ace@ietf.org Subject: Re: [Ace] draft-ietf-ace-cbor-web-token-08 - CWT CBOR Tag The type of location where it might show up is where one does a value = that is placed in an array where it can be either an A or a B and you = use the tag to distinguish between the two options. This can be very = useful in those cases. =20 > -----Original Message----- > From: Carsten Bormann [mailto:cabo@tzi.org] > Sent: Thursday, October 19, 2017 1:32 PM > To: Hannes Tschofenig > Cc: Mike Jones ; Jim Schaad=20 > ; ace@ietf.org > Subject: Re: [Ace] draft-ietf-ace-cbor-web-token-08 - CWT CBOR Tag >=20 > On Oct 19, 2017, at 21:30, Hannes Tschofenig=20 > wrote: > > > > For the cost saving of one byte we are essentially introduction=20 > > options > here. I am wondering whether this byte is worth it. >=20 > Two bytes. >=20 > It=E2=80=99s not really an option, as in every context there will be a = single=20 > right way to do this. > But yes, there are naked and tagged CWTs now. >=20 > (If we only define the tagged version, very quickly there will be=20 > specs that define a =E2=80=9Ccompressed CWT=E2=80=9D that just leaves = out those first=20 > two bytes=E2=80=A6) >=20 > Gr=C3=BC=C3=9Fe, Carsten _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace From nobody Fri Oct 20 17:31:15 2017 Return-Path: X-Original-To: ace@ietf.org Delivered-To: ace@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F3E2113457A; Fri, 20 Oct 2017 17:24:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: Kathleen.Moriarty.ietf@gmail.com, ace@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.63.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150854546999.20809.10734499314199213323.idtracker@ietfa.amsl.com> Date: Fri, 20 Oct 2017 17:24:29 -0700 Archived-At: Subject: [Ace] ace - Requested session has been scheduled for IETF 100 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Oct 2017 00:24:30 -0000 Dear Kepeng Li, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. ace Session 1 (2:30:00) Tuesday, Morning Session I 0930-1200 Room Name: Collyer size: 250 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: Authentication and Authorization for Constrained Environments Area Name: Security Area Session Requester: Kepeng Li Number of Sessions: 1 Length of Session(s): 2.5 Hours Number of Attendees: 100 Conflicts to Avoid: First Priority: fud tls tokbind saag oauth core teep lwig People who must be present: Kathleen Moriarty Hannes Tschofenig Kepeng Li Resources Requested: Special Requests: Avoid entire SEC areas. Please avoid a session on Monday since one of our presenters (Mike Jones) does not arrive in time! --------------------------------------------------------- From nobody Sat Oct 21 00:25:06 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D8B4126BF3; Sat, 21 Oct 2017 00:25:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AZhVVvaNtwQx; Sat, 21 Oct 2017 00:25:02 -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 65BD5132C32; Sat, 21 Oct 2017 00:25:02 -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 v9L7Ov0j002362; Sat, 21 Oct 2017 09:24:57 +0200 (CEST) Received: from [192.168.44.182] (vpn27.hotsplots.net [185.46.137.14]) (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 3yJvLp5pDyzDWYW; Sat, 21 Oct 2017 09:24:50 +0200 (CEST) From: Carsten Bormann Content-Type: text/plain; charset=utf-8 X-Mao-Original-Outgoing-Id: 530263478.505612-13ffd0836dba12edc5c52d7ceea636c1 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Sat, 21 Oct 2017 09:24:38 +0200 Message-Id: <1B709418-2990-4B00-9D7E-32AAA5637C7F@tzi.org> To: ace , "core@ietf.org WG" , cose , cbor@ietf.org, t2trg@irtf.org X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [Ace] Constrained Node/Network Cluster @ IETF100: FINAL AGENDA X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Oct 2017 07:25:05 -0000 Here is my usual eclectic condensed agenda based on the "FINAL" AGENDA for IETF100. Remember that "FINAL" means this will be the basis for printed agenda sheets, there is still some potential for changes after that. The CBOR/SUIT conflict has been fixed, but now there is overlap between 6TISCH and SUIT. ROLL vs. TEEP is a bit unfortunate, as is DINRG vs. LPWAN vs. DISPATCH. All times are SGT (UTC+0800). (You can get pure UTC times on https://datatracker.ietf.org/meeting/agenda-utc, for those who want to listen from remote.) Gr=C3=BC=C3=9Fe, Carsten FRIDAY, November 10, 2017 -- Joint meeting of OCF and T2TRG @ OCF meeting venue SATURDAY/SUNDAY -- Hackathon (including various interops) MONDAY, November 13, 2017 0930-1200 Morning Session I Collyer ART dispatch Dispatch WG - 0930-1100 Joint = with ARTAREA Collyer ART httpbis Hypertext Transfer Protocol WG - = 1100-1200 Olivia INT *** lpwan IPv6 over Low Power Wide-Area Networks = WG VIP A IRTF*** dinrg Decentralized Internet Infrastructure = Proposed RG Sophia OPS anima Autonomic Networking Integrated Model = and Approach WG 1330-1530 Afternoon Session I Sophia ART *** core Constrained RESTful Environments WG Padang OPS v6ops IPv6 Operations WG 1550-1720 Afternoon Session II Bras Basah INT *** 6tisch IPv6 over the TSCH mode of IEEE = 802.15.4e WG Collyer INT homenet Home Networking WG Padang IRTF maprg Measurement and Analysis for Protocols Canning SEC *** suit Software Updates for Internet of Things = BOF 1740-1840 Afternoon Session III Sophia INT ipwave IP Wireless Access in Vehicular = Environments WG - 0930-1030 Padang SEC tls Transport Layer Security WG Canning TSV tsvwg Transport Area Working Group WG TUESDAY, November 14, 2017 0930-1200 Morning Session I Collyer SEC *** ace Authentication and Authorization for = Constrained Environments WG Olivia TSV taps Transport Services WG 1330-1530 Afternoon Session I Bras Basah ART *** core Constrained RESTful Environments WG Canning INT 6man IPv6 Maintenance WG VIP A SEC tokbind Token Binding WG Padang TSV quic QUIC WG 1550-1750 Afternoon Session II Padang IRTF*** t2trg Thing-to-Thing Olivia RTG bier Bit Indexed Explicit Replication WG Sophia SEC oauth Web Authorization Protocol WG WEDNESDAY, November 15, 2017 0930-1200 Morning Session I Canning INT dnssd Extensions for Scalable DNS Service = Discovery WG Olivia INT *** lwig Light-Weight Implementation Guidance WG = - 1100-1200 VIP A IRTF icnrg Information-Centric Networking Collyer TSV quic QUIC WG 1330-1500 Afternoon Session I Bras Basah ART uta Using TLS in Applications WG VIP A RTG *** roll Routing Over Low power and Lossy = networks WG Collyer SEC *** teep Trusted Execution Environment = Provisioning BOF Orchard TSV rmcat RTP Media Congestion Avoidance = Techniques WG 1520-1650 Afternoon Session II Collyer INT intarea Internet Area Working Group WG VIP A IRTF cfrg Crypto Forum Orchard SEC oauth Web Authorization Protocol WG THURSDAY, November 16, 2017 0930-1200 Morning Session I Padang IRTF irtfopen IRTF Open Meeting Collyer OPS v6ops IPv6 Operations WG Sophia RTG detnet Deterministic Networking WG Canning SEC tls Transport Layer Security WG 1330-1530 Afternoon Session I Sophia INT *** 6lo IPv6 over Networks of = Resource-constrained Nodes WG Collyer IRTF panrg Path Aware Networking Proposed RG Padang SEC saag Security Area Open Meeting 1550-1750 Afternoon Session II Olivia ART *** cbor Concise Binary Object Representation = Maintenance and Extensions WG VIP A ART ice Interactive Connectivity Establishment = WG - 1550-1650 Canning RTG rtgarea Routing Area Open Meeting Sophia SEC acme Automated Certificate Management = Environment WG 1810-1910 Afternoon Session III VIP A SEC curdle CURves, Deprecating and a Little more = Encryption WG Padang TSV tsvarea Transport Area Open Meeting FRIDAY, November 17, 2017 0930-1130 Morning Session I Canning ART httpbis Hypertext Transfer Protocol WG VIP A RTG babel Babel routing protocol WG Collyer TSV tsvwg Transport Area Working Group WG From nobody Sun Oct 22 17:21:09 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3646B13C331; Sun, 22 Oct 2017 17:21:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.699 X-Spam-Level: X-Spam-Status: No, score=0.699 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=augustcellars.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I3megH2-jT9i; Sun, 22 Oct 2017 17:21:05 -0700 (PDT) Received: from mail4.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F28D13C333; Sun, 22 Oct 2017 17:21:02 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1508718057; h=from:subject:to:date:message-id; bh=xOKynBW4EF1HKlBY5+noGc4nwa5CiwaxghKa+3XfTn0=; b=awCY/OAkdESMUyRIbf6slNQh1F6Gx+1cZxu5yaycKs7sWiBgws2+zZKywa4q56pGj9biyXHbrs9 yzePFQ5vka8/QeAiZoFHBV4k7Gq5v1CQxte9MGAkVp4oBRAYpsa4OJtHJGzgjJ/t8vbyijy0WfR/x mzymFVqfVGZwGu1EXn2jiXEozqmszJuAUTHXtto+ILKbM78N+2LXPsAZ26A6Zjzg95wVj0xuJNMrk Vp7QPfhYFltnceFlrjX806GCV9IX8aFQncbFreb284k0Ehf5+BjwmoaF7l4UHF4B9BfptIJ9M7p/I mJIj0IO3R8y/nn2ezzy2KH0qRU3YlX9PFUIQ== Received: from mail2.augustcellars.com (192.168.1.201) by mail4.augustcellars.com (192.168.1.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Sun, 22 Oct 2017 17:20:56 -0700 Received: from Hebrews (192.168.1.162) by mail2.augustcellars.com (192.168.1.201) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Sun, 22 Oct 2017 17:20:00 -0700 From: Jim Schaad To: CC: Date: Sun, 22 Oct 2017 17:20:53 -0700 Message-ID: <01d001d34b94$cb43d660$61cb8320$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdNK51eJVdMxwVzaR2e/K3pQ6x7sxQ== X-Originating-IP: [192.168.1.162] Archived-At: Subject: [Ace] Review of draft-ietf-ace-cwt-proof-of-possession 00 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Oct 2017 00:21:07 -0000 * I dislike the statement of what the specification claims to do. It will be misread by many people who are not familiar with how you are defining the word "presenter". If I intercept a CWT and present it to a validator, it does not make a claim that I possess a specific POP key. Given what a CWT is supposed to do, I believe that a much clearer statement of functionality would be "This specification describes how to associate a set of claims in a CWT with a particular proof-of-possession key." Among other things, this would allow a third party to "present" a CWT on behalf of another party. (See introspection.) * I dislike the way that the second sentence of the introduction is written. Please remove the text about the presenter, that is not relevant to the holder-of-key assertion. * Section 2 - Issuer " Party that creates the CWT and binds the claims with the POP key" * Section 2 - The definition of "presenter" in this document is odd given that we are looking at ways that a CWT can be transferred by a third part. A better term would be "Holder" or "Holder of Key" * Section 3 paragraph 1 - This paragraph is written with some things taken for granted that I am not user exist. 1) How is the issuer doing the declaration that a presenter possesses a key, is a POP of the key a requirement to issue the CWT that I have not yet seen? 2) Again I don't like the use of presenter as the key usage and transfer are not necessarily done at the same time. * Section 3 paragraph 2 - You need to be clearer about what you mean by identified. My reading would be that the presenter is identified by the POP key. If you want to talk about claims which contain other types of naming material, then you need to be clear that is what you are doing. * Section 3 paragraph 2 - I would skip most of the detail on the meanings of the different claims and just identify the number of claims and refer to the CWT document for details on what they mean. The current text is not clear, and hopefully, the CWT document is much clearer on what these mean. * General - Where are you defining the types and contents of the claims that are being registered in this document? I cannot find it and I expected it to be in section 3.1 * Section 3.1 para 1 - Based on the last sentence, I think that you need to make some type of statement about the purpose of the "cnf" claim that embodies both a POP key and the SAML stuff that you are adding. What are the requirements to be here? What are the relationships between statements? * Section 3.1 para 2 - It is fine to say that what the set of methods that must be present is application dependent, however without the presence of some type of profile identification, how is an application supposed to know if the meanings and relationships are what are expected and not from some other profile? * Section 3.1 para 4 - The thus in the first sentence does not follow from the requirement. There is nothing that says that the same key could not be in both the COSE_Key and Encrypted_COSE_Key fields. * Section 3.1 para 4 - I don't understand the process defined in sentence #2 and why it is done this way. It would make more sense to me to say that it could be a new field with an array of cnf values. Doing the "additional to 'cnf'" would seem to cause potential problems when this CWT is grabbed by somebody which does not understand how these two fields are related. * Change the examples to use CBOR diagnostic notation. * Section 3.2 and 3.3 should be written in terms of the fields COSE_Key and Encrypted_COSE_Key rather than in terms of symmetric and asymmetric keys. Then you can properly talk about public and private keys in each of the sections and it is tied to the structure itself rather than inferred * Section 3.4 - I would consider this to be an unusable item for doing POP key identification in all cases where the kid is not computed in a cryptographic manner and the method of computation is included as part of the kid. * Section 3.5 - Huh? I don't know about typically for the demonstration. It could just as easily be done by doing an encryption/decryption operation or a key derivation operation such as in TLS for PSK. I don't know that this section is providing any useful information. If you think that it is needed then a simple statement that you are not specifying how to do POP is sufficient. * Section 4 paragraph 2 - I can understand a reasoning for doing audience restrictions, but I cannot for the life of me figure out why it would be of greater importance for POP statements than for any other set of claims. * Section 4 para 4 - How does a signed nonce prevent a replay attack with encrypted symmetric secrets? * Section 4 - I am surprised there is no statement about self-signed CWT statements esp. as that is given as an example of how additional naming claims would be understood * Section 5 - Need to make a statement about the correlation information that a CWT issuer would have as well? From nobody Mon Oct 23 06:17:44 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52725138A38 for ; Mon, 23 Oct 2017 06:17:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.702 X-Spam-Level: X-Spam-Status: No, score=0.702 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=alibaba-inc.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c4FY9QWGcF1v for ; Mon, 23 Oct 2017 06:17:41 -0700 (PDT) Received: from out0-201.mail.aliyun.com (out0-201.mail.aliyun.com [140.205.0.201]) (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 76E8D13F6E5 for ; Mon, 23 Oct 2017 06:17:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1508764656; h=Date:Subject:From:To:Message-ID:Mime-version:Content-type; bh=XI7OJkqPnDRAf5tEKcmsFh/XRB1LUYcLeLLkGzQiTTA=; b=XLfEPhhVDx4ziiC2Pokc1UrZoBv0MrvRwjWaiLwzJFnGwgumGv7aAT71wFa10NxZ0ebG+L5RERDFeA5WtrZa+2VUPGk0stMXExCM9tPm7aBNN6BafEnVZBTlmZiiYYqUIa/7Z1gn9uM9eAWi3MAOFuusH1UPdXiYFLlkubHMnaE= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R991e4; FP=0|-1|-1|-1|0|-1|-1|-1; HT=e02c03275; MF=kepeng.lkp@alibaba-inc.com; NM=1; PH=DS; RN=3; SR=0; TI=SMTPD_---.9DQGCoa_1508764645; Received: from 30.39.31.226(mailfrom:kepeng.lkp@alibaba-inc.com ip:121.0.29.163) by smtp.aliyun-inc.com(127.0.0.1); Mon, 23 Oct 2017 21:17:30 +0800 User-Agent: Microsoft-MacOutlook/14.6.8.160830 Date: Mon, 23 Oct 2017 21:17:24 +0800 From: "Kepeng Li" To: CC: Kathleen Moriarty , "Hannes.Tschofenig@gmx.net" Message-ID: Thread-Topic: [Ace] Call for adoption of draft-seitz-ace-oscoap-profile Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3591638250_5147272" Archived-At: Subject: [Ace] Call for adoption of draft-seitz-ace-oscoap-profile 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, 23 Oct 2017 13:17:43 -0000 > ´ËÓʼþʹÓà MIME ¸ñʽ¡£ÓÉÓÚÓʼþÔĶÁ³ÌÐò²»ÄÜʶ±ð ´Ë¸ñʽ£¬Òò´Ë£¬¿ÉÄÜÎÞ·¨Ê¶±ð¸ÃÓʼþµÄ·Ö²¿»ò²¿·ÖÄÚÈÝ¡£ --B_3591638250_5147272 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Hello all, According to our virtual interim meeting minutes[1], we have clear supports to adopt the OSCOAP profile draft [2] during the meeting. This note is asking for confirmation of this tentative adoption decision on the mailing list. Please speak up before 7th Nov, 2017 if you would like to register your opinion on the adoption question. Keep in mind that adoption of a document does not mean the document as-is is ready for publication. It is merely acceptance of the document as a starting point for what will be the final product of the ACE working group. The working group is free to make changes to the document according to the normal consensus process. Please reply on this thread with expressions of support or opposition, preferably with comments, regarding accepting this as a work item. Thanks Kind Regards Kepeng and Hannes (ACE co-chairs) [1] https://datatracker.ietf.org/meeting/interim-2017-ace-02/materials/minutes-i nterim-2017-ace-02-201710181300/ [2] https://datatracker.ietf.org/doc/draft-seitz-ace-oscoap-profile/ --B_3591638250_5147272 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable
Hello all,
=
 

According to our virtual interim meeting minutes[1], we = have clear supports to adopt the OSCOAP profile draft [2] during the me= eting.  

 

This note is asking for confirmation of th= is tentative adoption decision on the mailing list.  Please speak up be= fore 7th Nov, 2017 if you would like to register your opinion on the adoptio= n question.


<= div>
Keep in mind that adoption of a document does not mean the document as-is =
is ready for publication. It is merely acceptance of the document as a start=
ing point for what will be the final product of the ACE working group. The w=
orking group is free to make changes to the document according to the normal=
 consensus process.
 
<=
font>Please reply on this thread with expressions of support or opposition, =
preferably with comments, regarding accepting this as a work item.

&= nbsp;

Thanks
 
Kind Regards=

Kepeng and Hannes (ACE co-chairs)


 --B_3591638250_5147272-- From nobody Mon Oct 23 06:39:00 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C02913899A for ; Mon, 23 Oct 2017 06:38:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.001 X-Spam-Level: X-Spam-Status: No, score=-4.001 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KLxfQKnFX5LW for ; Mon, 23 Oct 2017 06:38:58 -0700 (PDT) Received: from se-out2.mx-wecloud.net (se-out2.mx-wecloud.net [89.221.255.177]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D980B138999 for ; Mon, 23 Oct 2017 06:38:57 -0700 (PDT) Received: from sp-mail-2.sp.se (unknown [194.218.146.197]) by se-out2.mx-wecloud.net (Postfix) with ESMTPS id 36B9A22209E for ; Mon, 23 Oct 2017 13:38:56 +0000 (UTC) Received: from [192.168.0.166] (10.116.0.226) by sp-mail-2.sp.se (10.100.0.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1261.35; Mon, 23 Oct 2017 15:38:56 +0200 To: "ace@ietf.org" From: Ludwig Seitz Message-ID: Date: Mon, 23 Oct 2017 15:38:55 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.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-CMAE-Score: 0 X-CMAE-Analysis: v=2.2 cv=KqQ94SeN c=1 sm=1 tr=0 a=L5DDne6A+dD0FbDkt2Fblw==:117 a=L5DDne6A+dD0FbDkt2Fblw==:17 a=sZ8rJzgPlrQA:10 a=IkcTkHD0fZMA:10 a=02M-m0pO-4AA:10 a=NEAV23lmAAAA:8 a=48vgC7mUAAAA:8 a=GCwk7IgCd9swKIUO5rwA:9 a=dE1qIU0_0EedtyT5:21 a=7a2_MdIk2DrHQejC:21 a=QEXdDO2ut3YA:10 a=w1C3t2QeGrPiZgrLijVG:22 X-Virus-Scanned: clamav-milter 0.99.2 at MailSecurity X-Virus-Status: Clean X-MailSecurity-Status: 0 X-Scanned-By: WeCloud MailSecurity X-MailSecurity-Score: 0 Archived-At: Subject: [Ace] Question about the response to an unauthorized request 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, 23 Oct 2017 13:38:59 -0000 Hello ACE, Jim Schaad has brought up an interesting question [1] on draft-ietf-ace-oauth-authz [2]: Currently when a client makes an unauthorized request to a resource server, it gets back the address of the authorization server and optionally a nonce (to prevent replay attacks). Jim is suggesting to add hints to the audience and scope the resource server expects for accessing this resource. I'm not sure whether that would not reveal too much information to a potential attacker. What does the group think of this issue? /Ludwig [1] https://github.com/ace-wg/ace-oauth/issues/124 [2] https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-08#section-5.1.2 -- Ludwig Seitz, PhD Security Lab, RISE SICS Phone +46(0)70-349 92 51 From nobody Wed Oct 25 07:27:36 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47922138726 for ; Wed, 25 Oct 2017 07:27:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JQG2fHxL8I0P for ; Wed, 25 Oct 2017 07:27:32 -0700 (PDT) Received: from mail-ua0-x236.google.com (mail-ua0-x236.google.com [IPv6:2607:f8b0:400c:c08::236]) (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 D423B1384B2 for ; Wed, 25 Oct 2017 07:27:32 -0700 (PDT) Received: by mail-ua0-x236.google.com with SMTP id n38so120975uai.11 for ; Wed, 25 Oct 2017 07:27:32 -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=lDNHPOe+498H2cdfLdRIxyZc1OX/Y51UGj2pF7cTfRA=; b=tvFlFPOmtEAt5oYpTXKUuNeqAuMGtfkZt/G0NY+IOv7QhrNwnwCCiPmeebxQ4ernCH SxvyDEmkEaQIPtkH44hBe1aDp7Cd1jYJKt6j/VDDq6X757iCXPJR8OIFVQcxn6bfX7Me PyTe5nfk/1tmFnxs1Tf5ivwjFTjgZGMKVkUVuXnHA1C6JdgVaMjc+q5pex8+S9gsKDwj XgPBob16GLTDpSQP8NC0p22u3f844Lo9StfGT4rWEJBKsjiF1LhQ+ZwkpDFBYNJBBAAK Xkb0AN+hcqTYmCURSnIxXLDYHQSlVsqOxNKQY4vEVPaq5MUbCeaYf4EnPuVRbJlQgfW7 SCIQ== 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=lDNHPOe+498H2cdfLdRIxyZc1OX/Y51UGj2pF7cTfRA=; b=Y44HH/kp4X0JbawPc6DzaMJv7ZBXGTTcPkqa07AmeN/19yh58cp9X9myyD805Ig+v+ e0g+dgrmKohaLtby2ohphyXK8FnHr3ellJGCybvTVLQzYQNWMg1MatiD11VqP87NV9ic iEIoCPdq1hpuJMvPAvsZyr07VUNx7qSU+ScbF0GX4yJf1unfHwYRTGVLf88UdwVTbYnY eR2Wu/nxzIp/OBVV+VRgIGR15FTx/hiBO5JZfyt2oA1qMlSgNoXvflBaHD/TDaxcabQN memQoXK/W/3RQpsNj6Eay4sm8cjeG5TX0ykkKSDVeGW8hEIygDrz7hqW/NCNOR5wuzYo ZIDw== X-Gm-Message-State: AMCzsaUOAh7u5CnnkpM/E8lkdsQJ6ZlWJjdkdJY2GiyUplkUFFuQHfvH x8YSPjdcM4NKqyAjXlKyBtl8gDXPx5ldV/mdceQ= X-Google-Smtp-Source: ABhQp+SZY0tueVc9S5sDWAoVM1ZHhvOuErSXrOa2ZjOUIPJ+PiZiLEW9ETzCELSTwQURPpzWiiMm2VI2DnejaVzDglE= X-Received: by 10.176.28.75 with SMTP id o11mr2008309uaj.89.1508941651775; Wed, 25 Oct 2017 07:27:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.16.209 with HTTP; Wed, 25 Oct 2017 07:27:31 -0700 (PDT) In-Reply-To: References: From: Cigdem Sengul Date: Wed, 25 Oct 2017 15:27:31 +0100 Message-ID: To: Ludwig Seitz Cc: "ace@ietf.org" Content-Type: multipart/alternative; boundary="f403043e827424162d055c5fdb0f" Archived-At: Subject: Re: [Ace] Question about the response to an unauthorized request 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, 25 Oct 2017 14:27:35 -0000 --f403043e827424162d055c5fdb0f Content-Type: text/plain; charset="UTF-8" Hello, To bring a different view, I wanted to mention Kantara UMA (User Managed Access) approach to this problem. (I participated in the UMA v2.0 development this year, so had the chance to be more familiar with the new drafts.) In UMA, the resource server must respond to a client's tokenless (unauthorized) access attempt by obtaining a permission ticket from the authorization server. If RS is able to obtain a permission ticket from the AS, RS returns this ticket to the client also with the AS uri to aid AS discovery. UMA handles resources (resource sets, permissions etc.) differently but the permission requests (from RS to AS) can be considered as signaling to the AS what audience/scope RS expects. In ACE, there are limitations of course - i.e., RS may not always reach AS etc. Nevertheless, it may be useful to think how other groups approach similar problems. Best, --Cigdem On Mon, Oct 23, 2017 at 2:38 PM, Ludwig Seitz wrote: > Hello ACE, > > Jim Schaad has brought up an interesting question [1] on > draft-ietf-ace-oauth-authz [2]: > > Currently when a client makes an unauthorized request to a resource > server, it gets back the address of the authorization server and optionally > a nonce (to prevent replay attacks). > > Jim is suggesting to add hints to the audience and scope the resource > server expects for accessing this resource. > > I'm not sure whether that would not reveal too much information to a > potential attacker. > > What does the group think of this issue? > > /Ludwig > > > [1] https://github.com/ace-wg/ace-oauth/issues/124 > [2] https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-08#se > ction-5.1.2 > -- > 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 > --f403043e827424162d055c5fdb0f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,

To bring a different view, = I wanted to mention Kantara UMA (User Managed Access) approach to this prob= lem. (I participated in the UMA v2.0 development this year, so had the chan= ce to be more familiar with the new drafts.)
=C2=A0
In = UMA,=C2=A0 the resource server must respond to a client's tokenless (un= authorized) access attempt by obtaining a permission ticket from the author= ization server.
If RS is able to obtain a permission ticket from = the AS, RS returns this ticket to the client also with=C2=A0 the AS uri to = aid AS discovery.=C2=A0

UMA handles resources (res= ource sets, permissions etc.) differently but the permission requests (from= RS to AS)=C2=A0 can be considered as signaling to the AS what audience/sco= pe RS expects.

In ACE, there are limitations of co= urse - i.e., RS may not always reach AS etc.=C2=A0 Nevertheless, it may be = useful to think how other groups approach similar problems.=C2=A0

Best,=C2=A0
--Cigdem=C2=A0


On Mon,= Oct 23, 2017 at 2:38 PM, Ludwig Seitz <ludwig.seitz@ri.se>= wrote:
Hello ACE,

Jim Schaad has brought up an interesting question [1] on draft-ietf-ace-oau= th-authz [2]:

Currently when a client makes an unauthorized request to a resource server,= it gets back the address of the authorization server and optionally a nonc= e (to prevent replay attacks).

Jim is suggesting to add hints to the audience and scope the resource serve= r expects for accessing this resource.

I'm not sure whether that would not reveal too much information to a po= tential attacker.

What does the group think of this issue?

/Ludwig


[1] https://github.com/ace-wg/ace-oauth/issues/12= 4
[2] https://tools.ietf.org/ht= ml/draft-ietf-ace-oauth-authz-08#section-5.1.2
--
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

--f403043e827424162d055c5fdb0f-- From nobody Wed Oct 25 08:26:10 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B65C31389AB for ; Wed, 25 Oct 2017 08:26:08 -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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sei.cmu.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g1kgg99XL61i for ; Wed, 25 Oct 2017 08:26:06 -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 285B81389B7 for ; Wed, 25 Oct 2017 08:26:06 -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 v9PFQ4uf037096; Wed, 25 Oct 2017 11:26:04 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 veto.sei.cmu.edu v9PFQ4uf037096 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sei.cmu.edu; s=t52kn2igOmwp; t=1508945164; bh=M5Xvt+zs8ZTjgbVL3GFUYoYh81jIevG2Kbh22jQcHQs=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=J9QVF2ww21hCEVvw9fLYrGeZbdi6xuCcvHN8Yh1bZhT9rqGqXOxoFVQsEuvTZUf9z sOq8NeHFviEdxXtsMKZVsxHnqYwDS/Qo6OV+95GKhcilisYWfMEhjfPsvc7Xt8apc8 2mzPjT88lSKcQwNO4GiOOfWeD4M4XpMDoegZkxJU= 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 v9PFQ1ul044800; Wed, 25 Oct 2017 11:26:01 -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.0361.001; Wed, 25 Oct 2017 11:26:01 -0400 From: Grace Lewis To: Cigdem Sengul , Ludwig Seitz CC: "ace@ietf.org" Thread-Topic: [Ace] Question about the response to an unauthorized request Thread-Index: AQHTTARNbR9fanMNbUGTL4uvQ7kdCaL05c2AgAAQW4A= Date: Wed, 25 Oct 2017 15:26:00 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.27.0.171010 x-originating-ip: [10.64.96.253] Content-Type: multipart/alternative; boundary="_000_B07169DE6D3647E4A36DB49D750D0187seicmuedu_" MIME-Version: 1.0 Archived-At: Subject: Re: [Ace] Question about the response to an unauthorized request 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, 25 Oct 2017 15:26:09 -0000 --_000_B07169DE6D3647E4A36DB49D750D0187seicmuedu_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 THVkd2lnLA0KDQpJIGRvIGJlbGlldmUgdGhhdCB0aGlzIHdvdWxkIHJldmVhbCB0b28gbXVjaCBp bmZvcm1hdGlvbiB0byBhbiBhdHRhY2tlciwgZXNwZWNpYWxseSBpZiBJb1QgZGV2aWNlcyBhcmUg YmVpbmcgZGVwbG95ZWQgaW4g4oCcaG9zdGlsZSBlbnZpcm9ubWVudHMu4oCdIFdoaWxlIHRoaXMg bWF5IGJlIGFwcHJvcHJpYXRlIGluIGEgaG9tZSBhbmQgcG90ZW50aWFsbHkgaW5kdXN0cnkgc2V0 dGluZywgaXQgaXMgY2VydGFpbmx5IG5vdCBhcHByb3ByaWF0ZSBpbiBhIG1vcmUgY29udGVzdGVk IHNldHRpbmcuDQoNClRoZSBVTUEgYXBwcm9hY2ggcHJlc2VudGVkIGJ5IENpZ2RlbSBpcyBhbiBv cHRpb24sIGdpdmVuIHRoYXQgdGhlIFJTIGlzIGFibGUgdG8gdmVyaWZ5IHdpdGggdGhlIEFTIHRo YXQgdGhlIHJlcXVlc3QgY29tZXMgZnJvbSBhIGNsaWVudCB0aGF0IGlzIGN1cnJlbnRseSBwYWly ZWQgdG8gdGhlIEFTLiBIb3dldmVyLCBJIGRvIGFncmVlIHRoYXQgcmVhY2hhYmlsaXR5IHRvIHRo ZSBBUyBtYXkgbm90IGFsd2F5cyBiZSBwb3NzaWJsZS4NCg0KSWYgdGhpcyBpcyBpbmNsdWRlZCBh cyBhbiBvcHRpb24sIHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyB3b3VsZCBuZWVkIHRvIGJl IGNsZWFybHkgbm90ZWQuDQoNCg0KICAqICAgR3JhY2UNCg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KR3JhY2UgQS4gTGV3aXMsIFBoLkQuDQpQcmluY2lw YWwgUmVzZWFyY2hlcg0KQ2FybmVnaWUgTWVsbG9uIFNvZnR3YXJlIEVuZ2luZWVyaW5nIEluc3Rp dHV0ZQ0KU29mdHdhcmUgU29sdXRpb25zIERpdmlzaW9uIChTU0QpDQpUYWN0aWNhbCBUZWNobm9s b2dpZXMgR3JvdXAgKFRURykNCg0KNDUwMCBGaWZ0aCBBdmUuDQpQaXR0c2J1cmdoLCBQQSAxNTIx Mw0KUGhvbmU6ICg0MTIpIDI2OC01ODUxDQpodHRwOi8vd3d3LnNlaS5jbXUuZWR1L3N0YWZmL2ds ZXdpcw0KDQpGcm9tOiBBY2UgPGFjZS1ib3VuY2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2YgQ2ln ZGVtIFNlbmd1bCA8Y2lnZGVtLnNlbmd1bEBnbWFpbC5jb20+DQpEYXRlOiBXZWRuZXNkYXksIE9j dG9iZXIgMjUsIDIwMTcgYXQgMTA6MjcgQU0NClRvOiBMdWR3aWcgU2VpdHogPGx1ZHdpZy5zZWl0 ekByaS5zZT4NCkNjOiAiYWNlQGlldGYub3JnIiA8YWNlQGlldGYub3JnPg0KU3ViamVjdDogUmU6 IFtBY2VdIFF1ZXN0aW9uIGFib3V0IHRoZSByZXNwb25zZSB0byBhbiB1bmF1dGhvcml6ZWQgcmVx dWVzdA0KDQpIZWxsbywNCg0KVG8gYnJpbmcgYSBkaWZmZXJlbnQgdmlldywgSSB3YW50ZWQgdG8g bWVudGlvbiBLYW50YXJhIFVNQSAoVXNlciBNYW5hZ2VkIEFjY2VzcykgYXBwcm9hY2ggdG8gdGhp cyBwcm9ibGVtLiAoSSBwYXJ0aWNpcGF0ZWQgaW4gdGhlIFVNQSB2Mi4wIGRldmVsb3BtZW50IHRo aXMgeWVhciwgc28gaGFkIHRoZSBjaGFuY2UgdG8gYmUgbW9yZSBmYW1pbGlhciB3aXRoIHRoZSBu ZXcgZHJhZnRzLikNCg0KSW4gVU1BLCAgdGhlIHJlc291cmNlIHNlcnZlciBtdXN0IHJlc3BvbmQg dG8gYSBjbGllbnQncyB0b2tlbmxlc3MgKHVuYXV0aG9yaXplZCkgYWNjZXNzIGF0dGVtcHQgYnkg b2J0YWluaW5nIGEgcGVybWlzc2lvbiB0aWNrZXQgZnJvbSB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2 ZXIuDQpJZiBSUyBpcyBhYmxlIHRvIG9idGFpbiBhIHBlcm1pc3Npb24gdGlja2V0IGZyb20gdGhl IEFTLCBSUyByZXR1cm5zIHRoaXMgdGlja2V0IHRvIHRoZSBjbGllbnQgYWxzbyB3aXRoICB0aGUg QVMgdXJpIHRvIGFpZCBBUyBkaXNjb3ZlcnkuDQoNClVNQSBoYW5kbGVzIHJlc291cmNlcyAocmVz b3VyY2Ugc2V0cywgcGVybWlzc2lvbnMgZXRjLikgZGlmZmVyZW50bHkgYnV0IHRoZSBwZXJtaXNz aW9uIHJlcXVlc3RzIChmcm9tIFJTIHRvIEFTKSAgY2FuIGJlIGNvbnNpZGVyZWQgYXMgc2lnbmFs aW5nIHRvIHRoZSBBUyB3aGF0IGF1ZGllbmNlL3Njb3BlIFJTIGV4cGVjdHMuDQoNCkluIEFDRSwg dGhlcmUgYXJlIGxpbWl0YXRpb25zIG9mIGNvdXJzZSAtIGkuZS4sIFJTIG1heSBub3QgYWx3YXlz IHJlYWNoIEFTIGV0Yy4gIE5ldmVydGhlbGVzcywgaXQgbWF5IGJlIHVzZWZ1bCB0byB0aGluayBo b3cgb3RoZXIgZ3JvdXBzIGFwcHJvYWNoIHNpbWlsYXIgcHJvYmxlbXMuDQoNCkJlc3QsDQotLUNp Z2RlbQ0KDQoNCk9uIE1vbiwgT2N0IDIzLCAyMDE3IGF0IDI6MzggUE0sIEx1ZHdpZyBTZWl0eiA8 bHVkd2lnLnNlaXR6QHJpLnNlPG1haWx0bzpsdWR3aWcuc2VpdHpAcmkuc2U+PiB3cm90ZToNCkhl bGxvIEFDRSwNCg0KSmltIFNjaGFhZCBoYXMgYnJvdWdodCB1cCBhbiBpbnRlcmVzdGluZyBxdWVz dGlvbiBbMV0gb24gZHJhZnQtaWV0Zi1hY2Utb2F1dGgtYXV0aHogWzJdOg0KDQpDdXJyZW50bHkg d2hlbiBhIGNsaWVudCBtYWtlcyBhbiB1bmF1dGhvcml6ZWQgcmVxdWVzdCB0byBhIHJlc291cmNl IHNlcnZlciwgaXQgZ2V0cyBiYWNrIHRoZSBhZGRyZXNzIG9mIHRoZSBhdXRob3JpemF0aW9uIHNl cnZlciBhbmQgb3B0aW9uYWxseSBhIG5vbmNlICh0byBwcmV2ZW50IHJlcGxheSBhdHRhY2tzKS4N Cg0KSmltIGlzIHN1Z2dlc3RpbmcgdG8gYWRkIGhpbnRzIHRvIHRoZSBhdWRpZW5jZSBhbmQgc2Nv cGUgdGhlIHJlc291cmNlIHNlcnZlciBleHBlY3RzIGZvciBhY2Nlc3NpbmcgdGhpcyByZXNvdXJj ZS4NCg0KSSdtIG5vdCBzdXJlIHdoZXRoZXIgdGhhdCB3b3VsZCBub3QgcmV2ZWFsIHRvbyBtdWNo IGluZm9ybWF0aW9uIHRvIGEgcG90ZW50aWFsIGF0dGFja2VyLg0KDQpXaGF0IGRvZXMgdGhlIGdy b3VwIHRoaW5rIG9mIHRoaXMgaXNzdWU/DQoNCi9MdWR3aWcNCg0KDQpbMV0gaHR0cHM6Ly9naXRo dWIuY29tL2FjZS13Zy9hY2Utb2F1dGgvaXNzdWVzLzEyNA0KWzJdIGh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWFjZS1vYXV0aC1hdXRoei0wOCNzZWN0aW9uLTUuMS4yDQot LQ0KTHVkd2lnIFNlaXR6LCBQaEQNClNlY3VyaXR5IExhYiwgUklTRSBTSUNTDQpQaG9uZSArNDYo MCk3MC0zNDkgOTIgNTE8dGVsOiUyQjQ2JTI4MCUyOTcwLTM0OSUyMDkyJTIwNTE+DQoNCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpBY2UgbWFpbGluZyBs aXN0DQpBY2VAaWV0Zi5vcmc8bWFpbHRvOkFjZUBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vYWNlDQoNCg== --_000_B07169DE6D3647E4A36DB49D750D0187seicmuedu_ Content-Type: text/html; charset="utf-8" Content-ID: <22A8AF1B3BB9E2409E20CF5C78C47C18@sei.cmu.edu> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCglwYW5vc2UtMToyIDcg MyA5IDIgMiA1IDIgNCA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0K CXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250 LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5Oi13ZWJraXQtc3RhbmRhcmQ7fQ0KQGZv bnQtZmFjZQ0KCXtmb250LWZhbWlseTpPcHRpbWE7DQoJcGFub3NlLTE6MiAwIDUgMyA2IDAgMCAy IDAgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1h bCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsN Cglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30N CmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNv bG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4u TXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1 cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvTGlzdFBhcmFncmFwaCwg bGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXBy aW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2lu LWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7 DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9 DQpzcGFuLmhvZW56Yg0KCXttc28tc3R5bGUtbmFtZTpob2VuemI7fQ0Kc3Bhbi5FbWFpbFN0eWxl MTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLm1zb0lucw0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCgltc28tc3R5bGUtbmFtZToiIjsNCgl0ZXh0LWRlY29y YXRpb246dW5kZXJsaW5lOw0KCWNvbG9yOnRlYWw7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0 eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2Vj dGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEu MGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBE ZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MTgwMTMzNjI1MjsNCgltc28t bGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MTAwMzYzOTYyNiAtMTQ2 NjQ2ODU0IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4 Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtc3Rh cnQtYXQ6MDsNCgltc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ6LTsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJbXNvLWJpZGkt Zm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IixzZXJpZjt9DQpAbGlz dCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5Oldpbmdk aW5nczt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQt ZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cglmb250LWZhbWlseToiQ291cmllciBOZXciLHNlcmlmO30NCkBsaXN0IGwwOmxldmVsNg0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGww OmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30N CkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJD b3VyaWVyIE5ldyIsc2VyaWY7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47 fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5 IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+ DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+THVkd2ln LDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGRvIGJlbGlldmUgdGhhdCB0aGlzIHdvdWxkIHJl dmVhbCB0b28gbXVjaCBpbmZvcm1hdGlvbiB0byBhbiBhdHRhY2tlciwgZXNwZWNpYWxseSBpZiBJ b1QgZGV2aWNlcyBhcmUgYmVpbmcgZGVwbG95ZWQgaW4g4oCcaG9zdGlsZSBlbnZpcm9ubWVudHMu 4oCdIFdoaWxlIHRoaXMgbWF5IGJlIGFwcHJvcHJpYXRlIGluIGEgaG9tZSBhbmQgcG90ZW50aWFs bHkgaW5kdXN0cnkgc2V0dGluZywgaXQgaXMgY2VydGFpbmx5IG5vdA0KIGFwcHJvcHJpYXRlIGlu IGEgbW9yZSBjb250ZXN0ZWQgc2V0dGluZy4gPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBV TUEgYXBwcm9hY2ggcHJlc2VudGVkIGJ5IENpZ2RlbSBpcyBhbiBvcHRpb24sIGdpdmVuIHRoYXQg dGhlIFJTIGlzIGFibGUgdG8gdmVyaWZ5IHdpdGggdGhlIEFTIHRoYXQgdGhlIHJlcXVlc3QgY29t ZXMgZnJvbSBhIGNsaWVudCB0aGF0IGlzIGN1cnJlbnRseSBwYWlyZWQgdG8gdGhlIEFTLiBIb3dl dmVyLCBJIGRvIGFncmVlIHRoYXQgcmVhY2hhYmlsaXR5IHRvIHRoZSBBUyBtYXkgbm90IGFsd2F5 cyBiZQ0KIHBvc3NpYmxlLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JZiB0aGlzIGlzIGluY2x1 ZGVkIGFzIGFuIG9wdGlvbiwgdGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIHdvdWxkIG5lZWQg dG8gYmUgY2xlYXJseSBub3RlZC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHVsIHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIgdHlwZT0i ZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDow aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPkdyYWNlPG86cD48L286cD48L2xpPjwvdWw+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjojMDAwMDdG Ij5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7T3B0aW1hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzAwMDA3RiI+R3JhY2UgQS4gTGV3aXMsIFBoLkQuPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5Oi13ZWJraXQtc3RhbmRhcmQ7Y29sb3I6YmxhY2siPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O09wdGltYSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDAwN0YiPlByaW5jaXBhbCBSZXNlYXJjaGVyJm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5Oi13ZWJraXQtc3RhbmRhcmQ7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O09wdGltYSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMwMDAwN0YiPkNhcm5lZ2llIE1lbGxvbiBTb2Z0d2FyZSBFbmdpbmVlcmluZyBJbnN0 aXR1dGU8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6LXdl YmtpdC1zdGFuZGFyZDtjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7T3B0aW1hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMDA3 RiI+U29mdHdhcmUgU29sdXRpb25zIERpdmlzaW9uJm5ic3A7KFNTRCkmbmJzcDs8L3NwYW4+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6LXdlYmtpdC1zdGFuZGFyZDtj b2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7T3B0aW1hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMDA3RiI+VGFjdGljYWwgVGVj aG5vbG9naWVzIEdyb3VwIChUVEcpPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5Oi13ZWJraXQtc3RhbmRhcmQ7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5Oi13ZWJraXQtc3RhbmRhcmQ7Y29sb3I6Ymxh Y2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O09wdGltYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDAwN0YiPjQ1MDAgRmlmdGggQXZl LiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTot d2Via2l0LXN0YW5kYXJkO2NvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtPcHRpbWEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAw MDdGIj5QaXR0c2J1cmdoLCBQQSAxNTIxMyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTotd2Via2l0LXN0YW5kYXJkO2NvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtPcHRpbWEmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMDAwMDdGIj5QaG9uZTogKDQxMikgMjY4LTU4NTE8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7T3B0aW1hJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzAwMDA3RiI+aHR0cDovL3d3dy5zZWkuY211LmVkdS9zdGFmZi9nbGV3aXM8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAx LjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5Gcm9tOiA8L3NwYW4+ PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5BY2UgJmx0O2Fj ZS1ib3VuY2VzQGlldGYub3JnJmd0OyBvbiBiZWhhbGYgb2YgQ2lnZGVtIFNlbmd1bCAmbHQ7Y2ln ZGVtLnNlbmd1bEBnbWFpbC5jb20mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPldlZG5lc2RheSwgT2N0 b2JlciAyNSwgMjAxNyBhdCAxMDoyNyBBTTxicj4NCjxiPlRvOiA8L2I+THVkd2lnIFNlaXR6ICZs dDtsdWR3aWcuc2VpdHpAcmkuc2UmZ3Q7PGJyPg0KPGI+Q2M6IDwvYj4mcXVvdDthY2VAaWV0Zi5v cmcmcXVvdDsgJmx0O2FjZUBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UmU6IFtB Y2VdIFF1ZXN0aW9uIGFib3V0IHRoZSByZXNwb25zZSB0byBhbiB1bmF1dGhvcml6ZWQgcmVxdWVz dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkhlbGxvLCA8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPlRvIGJyaW5nIGEgZGlmZmVyZW50IHZpZXcsIEkgd2FudGVkIHRvIG1lbnRpb24g S2FudGFyYSBVTUEgKFVzZXIgTWFuYWdlZCBBY2Nlc3MpIGFwcHJvYWNoIHRvIHRoaXMgcHJvYmxl bS4gKEkgcGFydGljaXBhdGVkIGluIHRoZSBVTUEgdjIuMCBkZXZlbG9wbWVudCB0aGlzIHllYXIs IHNvIGhhZCB0aGUgY2hhbmNlIHRvIGJlIG1vcmUgZmFtaWxpYXIgd2l0aCB0aGUgbmV3IGRyYWZ0 cy4pPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkluIFVNQSwmbmJzcDsgdGhlIHJlc291cmNlIHNlcnZlciBtdXN0IHJlc3BvbmQgdG8gYSBjbGll bnQncyB0b2tlbmxlc3MgKHVuYXV0aG9yaXplZCkgYWNjZXNzIGF0dGVtcHQgYnkgb2J0YWluaW5n IGEgcGVybWlzc2lvbiB0aWNrZXQgZnJvbSB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIuPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JZiBSUyBpcyBh YmxlIHRvIG9idGFpbiBhIHBlcm1pc3Npb24gdGlja2V0IGZyb20gdGhlIEFTLCBSUyByZXR1cm5z IHRoaXMgdGlja2V0IHRvIHRoZSBjbGllbnQgYWxzbyB3aXRoJm5ic3A7IHRoZSBBUyB1cmkgdG8g YWlkIEFTIGRpc2NvdmVyeS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+VU1BIGhhbmRsZXMgcmVzb3VyY2VzIChyZXNvdXJjZSBzZXRz LCBwZXJtaXNzaW9ucyBldGMuKSBkaWZmZXJlbnRseSBidXQgdGhlIHBlcm1pc3Npb24gcmVxdWVz dHMgKGZyb20gUlMgdG8gQVMpJm5ic3A7IGNhbiBiZSBjb25zaWRlcmVkIGFzIHNpZ25hbGluZyB0 byB0aGUgQVMgd2hhdCBhdWRpZW5jZS9zY29wZSBSUyBleHBlY3RzLjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JbiBBQ0UsIHRoZXJlIGFyZSBs aW1pdGF0aW9ucyBvZiBjb3Vyc2UgLSBpLmUuLCBSUyBtYXkgbm90IGFsd2F5cyByZWFjaCBBUyBl dGMuJm5ic3A7IE5ldmVydGhlbGVzcywgaXQgbWF5IGJlIHVzZWZ1bCB0byB0aGluayBob3cgb3Ro ZXIgZ3JvdXBzIGFwcHJvYWNoIHNpbWlsYXIgcHJvYmxlbXMuJm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJlc3QsJm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tLUNpZ2RlbSZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+T24gTW9uLCBPY3QgMjMsIDIwMTcgYXQgMjozOCBQTSwgTHVkd2lnIFNlaXR6 ICZsdDs8YSBocmVmPSJtYWlsdG86bHVkd2lnLnNlaXR6QHJpLnNlIiB0YXJnZXQ9Il9ibGFuayI+ bHVkd2lnLnNlaXR6QHJpLnNlPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2tx dW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtw YWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDow aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGVsbG8gQUNFLDxicj4NCjxicj4NCkppbSBTY2hh YWQgaGFzIGJyb3VnaHQgdXAgYW4gaW50ZXJlc3RpbmcgcXVlc3Rpb24gWzFdIG9uIGRyYWZ0LWll dGYtYWNlLW9hdXRoLWF1dGh6IFsyXTo8YnI+DQo8YnI+DQpDdXJyZW50bHkgd2hlbiBhIGNsaWVu dCBtYWtlcyBhbiB1bmF1dGhvcml6ZWQgcmVxdWVzdCB0byBhIHJlc291cmNlIHNlcnZlciwgaXQg Z2V0cyBiYWNrIHRoZSBhZGRyZXNzIG9mIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBhbmQgb3B0 aW9uYWxseSBhIG5vbmNlICh0byBwcmV2ZW50IHJlcGxheSBhdHRhY2tzKS48YnI+DQo8YnI+DQpK aW0gaXMgc3VnZ2VzdGluZyB0byBhZGQgaGludHMgdG8gdGhlIGF1ZGllbmNlIGFuZCBzY29wZSB0 aGUgcmVzb3VyY2Ugc2VydmVyIGV4cGVjdHMgZm9yIGFjY2Vzc2luZyB0aGlzIHJlc291cmNlLjxi cj4NCjxicj4NCkknbSBub3Qgc3VyZSB3aGV0aGVyIHRoYXQgd291bGQgbm90IHJldmVhbCB0b28g bXVjaCBpbmZvcm1hdGlvbiB0byBhIHBvdGVudGlhbCBhdHRhY2tlci48YnI+DQo8YnI+DQpXaGF0 IGRvZXMgdGhlIGdyb3VwIHRoaW5rIG9mIHRoaXMgaXNzdWU/PGJyPg0KPGJyPg0KL0x1ZHdpZzxi cj4NCjxicj4NCjxicj4NClsxXSA8YSBocmVmPSJodHRwczovL2dpdGh1Yi5jb20vYWNlLXdnL2Fj ZS1vYXV0aC9pc3N1ZXMvMTI0IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9naXRodWIuY29tL2Fj ZS13Zy9hY2Utb2F1dGgvaXNzdWVzLzEyNDwvYT48YnI+DQpbMl0gPGEgaHJlZj0iaHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtYWNlLW9hdXRoLWF1dGh6LTA4I3NlY3Rpb24t NS4xLjIiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1pZXRmLWFjZS1vYXV0aC1hdXRoei0wOCNzZWN0aW9uLTUuMS4yPC9hPjxzcGFuIHN0eWxlPSJj b2xvcjojODg4ODg4Ij48YnI+DQo8c3BhbiBjbGFzcz0iaG9lbnpiIj4tLSA8L3NwYW4+PGJyPg0K PHNwYW4gY2xhc3M9ImhvZW56YiI+THVkd2lnIFNlaXR6LCBQaEQ8L3NwYW4+PGJyPg0KPHNwYW4g Y2xhc3M9ImhvZW56YiI+U2VjdXJpdHkgTGFiLCBSSVNFIFNJQ1M8L3NwYW4+PGJyPg0KPHNwYW4g Y2xhc3M9ImhvZW56YiI+UGhvbmUgPGEgaHJlZj0idGVsOiUyQjQ2JTI4MCUyOTcwLTM0OSUyMDky JTIwNTEiIHRhcmdldD0iX2JsYW5rIj4NCiYjNDM7NDYoMCk3MC0zNDkgOTIgNTE8L2E+PC9zcGFu Pjxicj4NCjxicj4NCjxzcGFuIGNsYXNzPSJob2VuemIiPl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fPC9zcGFuPjxicj4NCjxzcGFuIGNsYXNzPSJob2VuemIi PkFjZSBtYWlsaW5nIGxpc3Q8L3NwYW4+PGJyPg0KPHNwYW4gY2xhc3M9ImhvZW56YiI+PGEgaHJl Zj0ibWFpbHRvOkFjZUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPkFjZUBpZXRmLm9yZzwvYT48 L3NwYW4+PGJyPg0KPHNwYW4gY2xhc3M9ImhvZW56YiI+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hY2UiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FjZTwvYT48L3NwYW4+PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_B07169DE6D3647E4A36DB49D750D0187seicmuedu_-- From nobody Wed Oct 25 12:59:40 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2287137ED6 for ; Wed, 25 Oct 2017 12:59:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=augustcellars.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NdQrIO1wBuQz for ; Wed, 25 Oct 2017 12:59:37 -0700 (PDT) Received: from mail4.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A77A61386F3 for ; Wed, 25 Oct 2017 12:59:37 -0700 (PDT) Content-Type: multipart/alternative; boundary="----=_NextPart_000_0180_01D34D91.19765B20" Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1508961519; h=from:subject:to:date:message-id; bh=lfigBVsS+PeGI+bJqQn6fkjswuyvm7PhsDQYDevNGc4=; b=fUmpIlmScpGKodbvwBmXestViShU0ulKEpVEuwLueyLP/twuG3kVaB/jg0Wia7SvNJ1D5mLiRwQ YcbNsaBoxa/xaG280qKTzgXkw7e82oiKZUFleN+n1clS5e0t2mKgdUZR7udk56J6UU4bRAhb3sxjo 3uNsEmPkZB9GaLg2nbadjpgHTOhyZpTjvwnOio0Ssga+HnEwBkjAu7Nq/n2zd3phfS9ovdXhJkLYI WzBuCBRc0ZYI310T08HFpBqn3U5osK/TNrMZiYn4sPp7lY5piO72+YakOPWPXi1UZmkKqbht+ZDZ0 ACI9DRZ0BUn2VwrGlRwFAOetWIEHim0kuBrw== Received: from mail2.augustcellars.com (192.168.1.201) by mail4.augustcellars.com (192.168.1.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 25 Oct 2017 12:58:38 -0700 Received: from Hebrews (192.168.1.162) by mail2.augustcellars.com (192.168.1.201) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 25 Oct 2017 12:58:34 -0700 From: Jim Schaad To: 'Cigdem Sengul' , 'Ludwig Seitz' CC: References: In-Reply-To: Date: Wed, 25 Oct 2017 12:59:28 -0700 Message-ID: <017f01d34dcb$c5d2e930$5178bb90$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQKQ6k+JhKm+1kO/2UsjYTh00eu8vgMKJHhKoWFxmvA= X-Originating-IP: [192.168.1.162] Archived-At: Subject: Re: [Ace] Question about the response to an unauthorized request 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, 25 Oct 2017 19:59:39 -0000 ------=_NextPart_000_0180_01D34D91.19765B20 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable How does the RS make an informed decision about who the client is given = that it is a tokenless access request? =20 =20 =20 From: Ace [mailto:ace-bounces@ietf.org] On Behalf Of Cigdem Sengul Sent: Wednesday, October 25, 2017 7:28 AM To: Ludwig Seitz Cc: ace@ietf.org Subject: Re: [Ace] Question about the response to an unauthorized = request =20 Hello, =20 To bring a different view, I wanted to mention Kantara UMA (User Managed = Access) approach to this problem. (I participated in the UMA v2.0 = development this year, so had the chance to be more familiar with the = new drafts.) =20 In UMA, the resource server must respond to a client's tokenless = (unauthorized) access attempt by obtaining a permission ticket from the = authorization server. If RS is able to obtain a permission ticket from the AS, RS returns this = ticket to the client also with the AS uri to aid AS discovery.=20 =20 UMA handles resources (resource sets, permissions etc.) differently but = the permission requests (from RS to AS) can be considered as signaling = to the AS what audience/scope RS expects. =20 In ACE, there are limitations of course - i.e., RS may not always reach = AS etc. Nevertheless, it may be useful to think how other groups = approach similar problems.=20 =20 Best,=20 --Cigdem=20 =20 =20 On Mon, Oct 23, 2017 at 2:38 PM, Ludwig Seitz > wrote: Hello ACE, Jim Schaad has brought up an interesting question [1] on = draft-ietf-ace-oauth-authz [2]: Currently when a client makes an unauthorized request to a resource = server, it gets back the address of the authorization server and = optionally a nonce (to prevent replay attacks). Jim is suggesting to add hints to the audience and scope the resource = server expects for accessing this resource. I'm not sure whether that would not reveal too much information to a = potential attacker. What does the group think of this issue? /Ludwig [1] https://github.com/ace-wg/ace-oauth/issues/124 [2] = https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-08#section-5.1.2 --=20 Ludwig Seitz, PhD Security Lab, RISE SICS Phone +46(0)70-349 92 51 =20 _______________________________________________ Ace mailing list Ace@ietf.org =20 https://www.ietf.org/mailman/listinfo/ace =20 ------=_NextPart_000_0180_01D34D91.19765B20 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

How does = the RS make an informed decision about who the client is given that it = is a tokenless access request?

 

 

 

From: Ace = [mailto:ace-bounces@ietf.org] On Behalf Of Cigdem = Sengul
Sent: Wednesday, October 25, 2017 7:28 AM
To: = Ludwig Seitz <ludwig.seitz@ri.se>
Cc: = ace@ietf.org
Subject: Re: [Ace] Question about the response to = an unauthorized request

 

Hello,

 

To bring a different view, I wanted to mention Kantara = UMA (User Managed Access) approach to this problem. (I participated in = the UMA v2.0 development this year, so had the chance to be more = familiar with the new drafts.)

 

In UMA,  the resource server must respond to a = client's tokenless (unauthorized) access attempt by obtaining a = permission ticket from the authorization = server.

If RS is able to = obtain a permission ticket from the AS, RS returns this ticket to the = client also with  the AS uri to aid AS = discovery. 

 

UMA handles resources (resource sets, permissions = etc.) differently but the permission requests (from RS to AS)  can = be considered as signaling to the AS what audience/scope RS = expects.

 

In ACE, there are limitations of course - i.e., RS may = not always reach AS etc.  Nevertheless, it may be useful to think = how other groups approach similar = problems. 

 

Best, 

--Cigdem 

 

 

On Mon, = Oct 23, 2017 at 2:38 PM, Ludwig Seitz <ludwig.seitz@ri.se> = wrote:

Hello = ACE,

Jim Schaad has brought up an interesting question [1] on = draft-ietf-ace-oauth-authz [2]:

Currently when a client makes an = unauthorized request to a resource server, it gets back the address of = the authorization server and optionally a nonce (to prevent replay = attacks).

Jim is suggesting to add hints to the audience and = scope the resource server expects for accessing this = resource.

I'm not sure whether that would not reveal too much = information to a potential attacker.

What does the group think of = this issue?

/Ludwig


[1] https://github.com/ace-wg/ace-oauth/issues/124
[= 2] https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-= 08#section-5.1.2
--
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

 

------=_NextPart_000_0180_01D34D91.19765B20-- From nobody Wed Oct 25 13:02:02 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01C9413954E for ; Wed, 25 Oct 2017 13:02:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=augustcellars.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dODC8FEEY-kB for ; Wed, 25 Oct 2017 13:01:58 -0700 (PDT) Received: from mail4.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1376137ED6 for ; Wed, 25 Oct 2017 13:01:58 -0700 (PDT) Content-Type: multipart/alternative; boundary="----=_NextPart_000_0185_01D34D91.6DE6B830" Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1508961660; h=from:subject:to:date:message-id; bh=Lakl51+O7IbYGlWHxzqxIc5uNmWSS9WI3xgcTeYB2X4=; b=LsWJ0cbt+VYzAZxLbTjCT+m8vAImZNAfs6iLWhXQaSarnBfVHsro7pkVpweZy0TCoxvyRT1jkqb lyXTHeklau9dpvTv/p2L8uJrNLRlh/OwoEGHw+3ZSR+8LsdNTIQZ+cH3yiOn8TvTQVCK/Qu1AEqmo IJajBGzalKvjU1lsjhy30DSWDBhB90Nviwzoc7rP0IpsYmjyvJsijaDLKMH6iW5NBC2a1QQRKJaYq PowYIRCzJi9NhlhU+AAJH+CUZ+RcrjahVLzLN6IJ4sRW+58pRXR1UvajDrbvA2SMguiafO/1fgDJY 01hQrK+zTGqgq09zJ6qswLpexixCawidIAow== Received: from mail2.augustcellars.com (192.168.1.201) by mail4.augustcellars.com (192.168.1.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 25 Oct 2017 13:00:59 -0700 Received: from Hebrews (192.168.1.162) by mail2.augustcellars.com (192.168.1.201) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 25 Oct 2017 13:00:56 -0700 From: Jim Schaad To: 'Grace Lewis' , 'Cigdem Sengul' , 'Ludwig Seitz' CC: References: In-Reply-To: Date: Wed, 25 Oct 2017 13:01:50 -0700 Message-ID: <018401d34dcc$1a403900$4ec0ab00$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQKQ6k+JhKm+1kO/2UsjYTh00eu8vgMKJHhKAcph44+hUx7OYA== X-Originating-IP: [192.168.1.162] Archived-At: Subject: Re: [Ace] Question about the response to an unauthorized request 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, 25 Oct 2017 20:02:01 -0000 ------=_NextPart_000_0185_01D34D91.6DE6B830 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I don=E2=80=99t think that this is going to reveal any more information = to an attacker than would be available to an attacker that just asks the = resource server for a resource w/o a token. Currently that is expected = to return the same information. =20 =20 One approach that would be good to note is that it might be reasonable = to hide this information behind a security wall so that it is required = that the client gets secure access to the RD before any additional = information about the resource can be obtained. =20 From: Ace [mailto:ace-bounces@ietf.org] On Behalf Of Grace Lewis Sent: Wednesday, October 25, 2017 8:26 AM To: Cigdem Sengul ; Ludwig Seitz = Cc: ace@ietf.org Subject: Re: [Ace] Question about the response to an unauthorized = request =20 Ludwig, =20 I do believe that this would reveal too much information to an attacker, = especially if IoT devices are being deployed in =E2=80=9Chostile = environments.=E2=80=9D While this may be appropriate in a home and = potentially industry setting, it is certainly not appropriate in a more = contested setting.=20 =20 The UMA approach presented by Cigdem is an option, given that the RS is = able to verify with the AS that the request comes from a client that is = currently paired to the AS. However, I do agree that reachability to the = AS may not always be possible. =20 If this is included as an option, the security considerations would need = to be clearly noted. =20 * Grace =20 ______________________________________________ Grace A. Lewis, Ph.D. Principal Researcher =20 Carnegie Mellon Software Engineering Institute Software Solutions Division (SSD)=20 Tactical Technologies Group (TTG) =20 4500 Fifth Ave.=20 Pittsburgh, PA 15213 =20 Phone: (412) 268-5851 http://www.sei.cmu.edu/staff/glewis =20 From: Ace > on = behalf of Cigdem Sengul > Date: Wednesday, October 25, 2017 at 10:27 AM To: Ludwig Seitz > Cc: "ace@ietf.org " > Subject: Re: [Ace] Question about the response to an unauthorized = request =20 Hello,=20 =20 To bring a different view, I wanted to mention Kantara UMA (User Managed = Access) approach to this problem. (I participated in the UMA v2.0 = development this year, so had the chance to be more familiar with the = new drafts.) =20 In UMA, the resource server must respond to a client's tokenless = (unauthorized) access attempt by obtaining a permission ticket from the = authorization server. If RS is able to obtain a permission ticket from the AS, RS returns this = ticket to the client also with the AS uri to aid AS discovery.=20 =20 UMA handles resources (resource sets, permissions etc.) differently but = the permission requests (from RS to AS) can be considered as signaling = to the AS what audience/scope RS expects. =20 In ACE, there are limitations of course - i.e., RS may not always reach = AS etc. Nevertheless, it may be useful to think how other groups = approach similar problems.=20 =20 Best,=20 --Cigdem=20 =20 =20 On Mon, Oct 23, 2017 at 2:38 PM, Ludwig Seitz > wrote: Hello ACE, Jim Schaad has brought up an interesting question [1] on = draft-ietf-ace-oauth-authz [2]: Currently when a client makes an unauthorized request to a resource = server, it gets back the address of the authorization server and = optionally a nonce (to prevent replay attacks). Jim is suggesting to add hints to the audience and scope the resource = server expects for accessing this resource. I'm not sure whether that would not reveal too much information to a = potential attacker. What does the group think of this issue? /Ludwig [1] https://github.com/ace-wg/ace-oauth/issues/124 [2] = https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-08#section-5.1.2 --=20 Ludwig Seitz, PhD Security Lab, RISE SICS Phone +46(0)70-349 92 51 =20 _______________________________________________ Ace mailing list Ace@ietf.org =20 https://www.ietf.org/mailman/listinfo/ace =20 ------=_NextPart_000_0185_01D34D91.6DE6B830 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

I don=E2=80=99t think that this is going to reveal any = more information to an attacker than would be available to an attacker = that just asks the resource server for a resource w/o a token.=C2=A0 = Currently that is expected to return the same information.=C2=A0 =

 

One approach that would be good to note is that it = might be reasonable to hide this information behind a security wall so = that it is required that the client gets secure access to the RD before = any additional information about the resource can be = obtained.

 

From: Ace = [mailto:ace-bounces@ietf.org] On Behalf Of Grace = Lewis
Sent: Wednesday, October 25, 2017 8:26 AM
To: = Cigdem Sengul <cigdem.sengul@gmail.com>; Ludwig Seitz = <ludwig.seitz@ri.se>
Cc: ace@ietf.org
Subject: = Re: [Ace] Question about the response to an unauthorized = request

 

Ludwig,

 

I do believe = that this would reveal too much information to an attacker, especially = if IoT devices are being deployed in =E2=80=9Chostile = environments.=E2=80=9D While this may be appropriate in a home and = potentially industry setting, it is certainly not appropriate in a more = contested setting.

 

The UMA = approach presented by Cigdem is an option, given that the RS is able to = verify with the AS that the request comes from a client that is = currently paired to the AS. However, I do agree that reachability to the = AS may not always be possible.

 

If this is = included as an option, the security considerations would need to be = clearly noted.

 

  • Grace

 

________________________________= ______________

Grace A. = Lewis, Ph.D.=

Principal = Researcher          &nb= sp;           &nbs= p;            = ;            =      =

Carnegie = Mellon Software Engineering Institute=

Software = Solutions Division (SSD) =

Tactical = Technologies Group (TTG)=

=  

4500 Fifth = Ave. =

Pittsburgh, = PA 15213                   =             =

Phone: (412) = 268-5851

http://www.sei.cmu.edu/staff= /glewis

 

From: Ace <ace-bounces@ietf.org> on = behalf of Cigdem Sengul <cigdem.sengul@gmail.com>Date: Wednesday, October 25, 2017 at 10:27 AM
To: = Ludwig Seitz <ludwig.seitz@ri.se>
Cc: = "ace@ietf.org" <ace@ietf.org>
Subject: Re: = [Ace] Question about the response to an unauthorized = request

 

Hello,

 

To bring a different view, I wanted to mention Kantara = UMA (User Managed Access) approach to this problem. (I participated in = the UMA v2.0 development this year, so had the chance to be more = familiar with the new drafts.)

 

In UMA,  the resource server must respond to a = client's tokenless (unauthorized) access attempt by obtaining a = permission ticket from the authorization = server.

If RS is able to = obtain a permission ticket from the AS, RS returns this ticket to the = client also with  the AS uri to aid AS = discovery. 

 

UMA handles resources (resource sets, permissions = etc.) differently but the permission requests (from RS to AS)  can = be considered as signaling to the AS what audience/scope RS = expects.

 

In ACE, there are limitations of course - i.e., RS may = not always reach AS etc.  Nevertheless, it may be useful to think = how other groups approach similar = problems. 

 

Best, 

--Cigdem 

 

 

On Mon, = Oct 23, 2017 at 2:38 PM, Ludwig Seitz <ludwig.seitz@ri.se> = wrote:

Hello ACE,

Jim Schaad has brought up = an interesting question [1] on draft-ietf-ace-oauth-authz = [2]:

Currently when a client makes an unauthorized request to a = resource server, it gets back the address of the authorization server = and optionally a nonce (to prevent replay attacks).

Jim is = suggesting to add hints to the audience and scope the resource server = expects for accessing this resource.

I'm not sure whether that = would not reveal too much information to a potential = attacker.

What does the group think of this = issue?

/Ludwig


[1] https://github.com/ace-wg/ace-oauth/issues/124
[= 2] https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-= 08#section-5.1.2
--
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

 

------=_NextPart_000_0185_01D34D91.6DE6B830-- From nobody Wed Oct 25 14:19:06 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C36B013F46E for ; Wed, 25 Oct 2017 14:19:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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=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 yjR9bdGPsdXZ for ; Wed, 25 Oct 2017 14:19:02 -0700 (PDT) Received: from mail-vk0-x22d.google.com (mail-vk0-x22d.google.com [IPv6:2607:f8b0:400c:c05::22d]) (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 7884E13F46D for ; Wed, 25 Oct 2017 14:19:02 -0700 (PDT) Received: by mail-vk0-x22d.google.com with SMTP id g69so904539vke.5 for ; Wed, 25 Oct 2017 14:19:02 -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=SvC+0239DnqtWaxTkCFLQ05bXa7CsPvs64O/EAyltyM=; b=TqDCbEp0DVrT26coOn8BBC0X/4CexNuEc52Fyw5pvj7HPCQx6CmX1eU+YhZ6lJ3gI8 tbrZHX6q27SWtioQ6Q2yahNWWzSMM+ZsG2VXD12A+3e3BNXkHAdrsvIGJOfr5vWoAOqc 6aT8KbbrnG/VOXGc5Ulm7+6mbCAEPC9IbJ6V+v+2YBr94JuvKclzGvTZ3kF+Zqu0iztt AMoPzfoQBdRUgf06f8mJpijQGrdzDAWvT5NK5ezEPNIpxjichtsYc5WutrsKtP121SGp dn7Nu/VIxOjvoT9v3mVJ0cXPb6tAQsk3hU4iSPnlX9D4ec4hiQnjruq4LPrpNdeYilP3 BuFw== 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=SvC+0239DnqtWaxTkCFLQ05bXa7CsPvs64O/EAyltyM=; b=hNZWf/ssa9EZT7CM05t0+9DOkkMhy8LjSQ5NT15vfMkQ/0quK6/Wm3edCsPA/9o/j/ zXN9PPTF5VP02grHSooA39MUGmzfYda56vS5mivD4EBIaG7nWdM/GCimnDZwGGElod+0 m7VbrXEMrE6FwI1t1IbewUsOCd0UDCKV+uqBfCBxRDNZHln36byDhXQzjYuaALuK7JuP 2ZcawLcfVGD5qEw+LSehgoHfMpItQLAjTgfG6JmAlqKsNVWQjvwGZ4H1AKQjsfVQALmP pCZvcd4zvK2W8tvTBeqOMtYyqCHH5pxT68wLEKGhfgd1kQyvyH5dkS2LN041SVVEEK5F dKKQ== X-Gm-Message-State: AMCzsaU8S4lkIByjFJxgmrpJ0I3nZTSJUDoPej4S10U8136yFYnEpHeZ PvWH+ttxXEMCPgb5m1ASx6rCfy8brDehFz0QnoQ= X-Google-Smtp-Source: ABhQp+S6Doja06f64CdXEzj9cJcmsUL5KAFviuVHXSWkWrCYu42blXFzae0O3L8rDbjoj9V65ZhmoVV4m15Chmwuo2w= X-Received: by 10.31.201.198 with SMTP id z189mr2505749vkf.145.1508966341496; Wed, 25 Oct 2017 14:19:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.16.209 with HTTP; Wed, 25 Oct 2017 14:19:00 -0700 (PDT) In-Reply-To: <017f01d34dcb$c5d2e930$5178bb90$@augustcellars.com> References: <017f01d34dcb$c5d2e930$5178bb90$@augustcellars.com> From: Cigdem Sengul Date: Wed, 25 Oct 2017 22:19:00 +0100 Message-ID: To: Jim Schaad Cc: Ludwig Seitz , "ace@ietf.org" Content-Type: multipart/alternative; boundary="001a114dc4c6c353c9055c659afe" Archived-At: Subject: Re: [Ace] Question about the response to an unauthorized request 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, 25 Oct 2017 21:19:04 -0000 --001a114dc4c6c353c9055c659afe Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable UMA assumes that resource server knows =E2=80=9Cwhich authorization server= to approach for the permission ticket and on which resource owner's behalf=E2= =80=9D deriving =E2=80=9Cthe necessary information using cues provided by the stru= cture of the API where the resource request was made, rather than by an access token. =E2=80=9C On Wednesday, October 25, 2017, Jim Schaad wrote: > How does the RS make an informed decision about who the client is given > that it is a tokenless access request? > > > > > > > > *From:* Ace [mailto:ace-bounces@ietf.org > ] *On Behalf Of *Ci= gdem > Sengul > *Sent:* Wednesday, October 25, 2017 7:28 AM > *To:* Ludwig Seitz > > *Cc:* ace@ietf.org > *Subject:* Re: [Ace] Question about the response to an unauthorized > request > > > > Hello, > > > > To bring a different view, I wanted to mention Kantara UMA (User Managed > Access) approach to this problem. (I participated in the UMA v2.0 > development this year, so had the chance to be more familiar with the new > drafts.) > > > > In UMA, the resource server must respond to a client's tokenless > (unauthorized) access attempt by obtaining a permission ticket from the > authorization server. > > If RS is able to obtain a permission ticket from the AS, RS returns this > ticket to the client also with the AS uri to aid AS discovery. > > > > UMA handles resources (resource sets, permissions etc.) differently but > the permission requests (from RS to AS) can be considered as signaling t= o > the AS what audience/scope RS expects. > > > > In ACE, there are limitations of course - i.e., RS may not always reach A= S > etc. Nevertheless, it may be useful to think how other groups approach > similar problems. > > > > Best, > > --Cigdem > > > > > > On Mon, Oct 23, 2017 at 2:38 PM, Ludwig Seitz > wrote: > > Hello ACE, > > Jim Schaad has brought up an interesting question [1] on > draft-ietf-ace-oauth-authz [2]: > > Currently when a client makes an unauthorized request to a resource > server, it gets back the address of the authorization server and optional= ly > a nonce (to prevent replay attacks). > > Jim is suggesting to add hints to the audience and scope the resource > server expects for accessing this resource. > > I'm not sure whether that would not reveal too much information to a > potential attacker. > > What does the group think of this issue? > > /Ludwig > > > [1] https://github.com/ace-wg/ace-oauth/issues/124 > [2] https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-08# > section-5.1.2 > -- > 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 > > > --001a114dc4c6c353c9055c659afe Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable UMA assumes that=C2=A0=C2=A0resource server=C2=A0knows=C2=A0=E2=80=9Cwhich authorizat= ion server to approach for the permission ticket and on which resource owne= r's behalf=E2=80=9D deriving =E2=80=9Cthe necessary information using c= ues provided by the structure of the API where the resource request was mad= e, rather than by an access token. =E2=80=9C

On Wednesday, Octob= er 25, 2017, Jim Schaad <ietf@= augustcellars.com> wrote:

How = does the RS make an informed decision about who the client is given that it= is a tokenless access request?

= =C2=A0

=C2=A0

=C2=A0

From: Ace [mailto:ace-bounces@ietf.= org] On Behalf Of Cigdem Sengul
Sent: Wednesday, Octob= er 25, 2017 7:28 AM
To: Ludwig Seitz <lu= dwig.seitz@ri.se>
Cc: ace@ietf.org
= Subject: Re: [Ace] Question about the response to an unauthorized re= quest

=C2=A0<= /u>

Hello,

=C2=A0

= To bring a different view, I wanted to mention Kantara UMA (User Managed Ac= cess) approach to this problem. (I participated in the UMA v2.0 development= this year, so had the chance to be more familiar with the new drafts.)<= /u>

=C2=A0

In UMA,=C2=A0 the resource server must respo= nd to a client's tokenless (unauthorized) access attempt by obtaining a= permission ticket from the authorization server.

If RS is able to obtain a permission ticket from = the AS, RS returns this ticket to the client also with=C2=A0 the AS uri to = aid AS discovery.=C2=A0

= =C2=A0

UMA handles resou= rces (resource sets, permissions etc.) differently but the permission reque= sts (from RS to AS)=C2=A0 can be considered as signaling to the AS what aud= ience/scope RS expects.

= =C2=A0

In ACE, there are= limitations of course - i.e., RS may not always reach AS etc.=C2=A0 Nevert= heless, it may be useful to think how other groups approach similar problem= s.=C2=A0

=C2=A0

Best,=C2=A0

--Cigdem=C2=A0

=

=C2=A0

=C2=A0

On Mon= , Oct 23, 2017 at 2:38 PM, Ludwig Seitz <ludwig.se= itz@ri.se> wrote:

Hello ACE,

Jim Schaad has = brought up an interesting question [1] on draft-ietf-ace-oauth-authz [2]:
Currently when a client makes an unauthorized request to a resource s= erver, it gets back the address of the authorization server and optionally = a nonce (to prevent replay attacks).

Jim is suggesting to add hints = to the audience and scope the resource server expects for accessing this re= source.

I'm not sure whether that would not reveal too much info= rmation to a potential attacker.

What does the group think of this i= ssue?

/Ludwig


[1] https://github.com/ace-wg/ace-oa= uth/issues/124
[2] https://tools.ietf.org= /html/draft-ietf-ace-oauth-authz-08#section-5.1.2
--
Ludwig Seitz, PhDSecurity Lab, RISE SICS
Phone +46(0)70-349 92 51
=
_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace=

=C2=A0

--001a114dc4c6c353c9055c659afe-- From nobody Wed Oct 25 15:13:32 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF905139676 for ; Wed, 25 Oct 2017 15:13:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=augustcellars.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id txL8K6EcJVow for ; Wed, 25 Oct 2017 15:13:28 -0700 (PDT) Received: from mail4.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4080213846C for ; Wed, 25 Oct 2017 15:13:28 -0700 (PDT) Content-Type: multipart/alternative; boundary="----=_NextPart_000_01A9_01D34DA3.C68B9200" Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1508969540; h=from:subject:to:date:message-id; bh=jioPaL8/ygmjGba8ELUj6N69Nwa8lD8miDpIbXzwXfI=; b=SwbSatzDXv9NLh/lwXl3Mxob8Zl7Q83lF/jo1lrzlK0fO6T3tmXgBmsqSniHG1940hGpgKbaEtl WPv2to/WMQ/r9RzgHzyveuSMwipOb765fdDH5E9vHE11VurxBYZIyPGS5dwZUE31HXkmU46IDwVSd Ap+5WIXonm0brDFJKNHSlR3+xUOFXXYi1XDab72gnHy5LEFDqjr1Tp9OERcluhLkFMI58+0rdbd/2 BXHdluv0Hu8o60s5EqFinJ1oRb4QTI0pofBBOazhyEJuUPX7Vrf1SOTM2ZndRwsPN57ogELr4dTFw AYOp+XHBbkqBiBGGpeHEaL0AH7ApYA31zZWw== Received: from mail2.augustcellars.com (192.168.1.201) by mail4.augustcellars.com (192.168.1.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 25 Oct 2017 15:12:19 -0700 Received: from Hebrews (192.168.1.162) by mail2.augustcellars.com (192.168.1.201) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 25 Oct 2017 15:12:16 -0700 From: Jim Schaad To: 'Cigdem Sengul' CC: References: <017f01d34dcb$c5d2e930$5178bb90$@augustcellars.com> In-Reply-To: Date: Wed, 25 Oct 2017 15:13:10 -0700 Message-ID: <01a801d34dde$72e5af10$58b10d30$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQKQ6k+JhKm+1kO/2UsjYTh00eu8vgMKJHhKAf9qOy0BwmAn2aFDiGyQ X-Originating-IP: [192.168.1.162] Archived-At: Subject: Re: [Ace] Question about the response to an unauthorized request 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, 25 Oct 2017 22:13:31 -0000 ------=_NextPart_000_01A9_01D34DA3.C68B9200 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable So you would be doing based on something like the address of the = requestor or the content of the request. I would complete understand = the first half. Is there any way to prevent a rouge requestor from = asking for information =E2=80=93 or are you just relying on a closed = system? =20 From: Cigdem Sengul [mailto:cigdem.sengul@gmail.com]=20 Sent: Wednesday, October 25, 2017 2:19 PM To: Jim Schaad Cc: Ludwig Seitz ; ace@ietf.org Subject: Re: [Ace] Question about the response to an unauthorized = request =20 UMA assumes that resource server knows =E2=80=9Cwhich authorization = server to approach for the permission ticket and on which resource = owner's behalf=E2=80=9D deriving =E2=80=9Cthe necessary information = using cues provided by the structure of the API where the resource = request was made, rather than by an access token. =E2=80=9C On Wednesday, October 25, 2017, Jim Schaad > wrote: How does the RS make an informed decision about who the client is given = that it is a tokenless access request? =20 =20 =20 From: Ace [mailto:ace-bounces@ietf.org = ] On Behalf Of = Cigdem Sengul Sent: Wednesday, October 25, 2017 7:28 AM To: Ludwig Seitz > Cc: ace@ietf.org =20 Subject: Re: [Ace] Question about the response to an unauthorized = request =20 Hello, =20 To bring a different view, I wanted to mention Kantara UMA (User Managed = Access) approach to this problem. (I participated in the UMA v2.0 = development this year, so had the chance to be more familiar with the = new drafts.) =20 In UMA, the resource server must respond to a client's tokenless = (unauthorized) access attempt by obtaining a permission ticket from the = authorization server. If RS is able to obtain a permission ticket from the AS, RS returns this = ticket to the client also with the AS uri to aid AS discovery.=20 =20 UMA handles resources (resource sets, permissions etc.) differently but = the permission requests (from RS to AS) can be considered as signaling = to the AS what audience/scope RS expects. =20 In ACE, there are limitations of course - i.e., RS may not always reach = AS etc. Nevertheless, it may be useful to think how other groups = approach similar problems.=20 =20 Best,=20 --Cigdem=20 =20 =20 On Mon, Oct 23, 2017 at 2:38 PM, Ludwig Seitz > wrote: Hello ACE, Jim Schaad has brought up an interesting question [1] on = draft-ietf-ace-oauth-authz [2]: Currently when a client makes an unauthorized request to a resource = server, it gets back the address of the authorization server and = optionally a nonce (to prevent replay attacks). Jim is suggesting to add hints to the audience and scope the resource = server expects for accessing this resource. I'm not sure whether that would not reveal too much information to a = potential attacker. What does the group think of this issue? /Ludwig [1] https://github.com/ace-wg/ace-oauth/issues/124 [2] = https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-08#section-5.1.2 --=20 Ludwig Seitz, PhD Security Lab, RISE SICS Phone +46(0)70-349 92 51 =20 _______________________________________________ Ace mailing list Ace@ietf.org =20 https://www.ietf.org/mailman/listinfo/ace =20 ------=_NextPart_000_01A9_01D34DA3.C68B9200 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

So you = would be doing based on something like the address of the requestor or = the content of the request.=C2=A0 I would complete understand the first = half.=C2=A0 Is there any way to prevent a rouge requestor from asking = for information =E2=80=93 or are you just relying on a closed = system?

 

From: = Cigdem Sengul [mailto:cigdem.sengul@gmail.com]
Sent: = Wednesday, October 25, 2017 2:19 PM
To: Jim Schaad = <ietf@augustcellars.com>
Cc: Ludwig Seitz = <ludwig.seitz@ri.se>; ace@ietf.org
Subject: Re: [Ace] = Question about the response to an unauthorized = request

 

UMA assumes = that  resource = server knows =E2=80=9Cwhich authorization server to approach = for the permission ticket and on which resource owner's behalf=E2=80=9D = deriving =E2=80=9Cthe necessary information using cues provided by the = structure of the API where the resource request was made, rather than by = an access token. =E2=80=9C

On Wednesday, October 25, 2017, = Jim Schaad <ietf@augustcellars.com> = wrote:

How does = the RS make an informed decision about who the client is given that it = is a tokenless access request?

 <= /o:p>

 <= /o:p>

 <= /o:p>

From:= Ace [mailto:ace-bounces@ietf.org] On Behalf Of Cigdem = Sengul
Sent: Wednesday, October 25, 2017 7:28 AM
To: = Ludwig Seitz <ludwig.seitz@ri.se>
Cc: ace@ietf.org
Subject: Re: [Ace] Question = about the response to an unauthorized = request

 <= /o:p>

Hello,<= /o:p>

 <= /o:p>

To bring a = different view, I wanted to mention Kantara UMA (User Managed Access) = approach to this problem. (I participated in the UMA v2.0 development = this year, so had the chance to be more familiar with the new = drafts.)

 <= /o:p>

In = UMA,  the resource server must respond to a client's tokenless = (unauthorized) access attempt by obtaining a permission ticket from the = authorization server.

If RS is = able to obtain a permission ticket from the AS, RS returns this ticket = to the client also with  the AS uri to aid AS = discovery. 

 <= /o:p>

UMA handles = resources (resource sets, permissions etc.) differently but the = permission requests (from RS to AS)  can be considered as signaling = to the AS what audience/scope RS expects.

 <= /o:p>

In ACE, = there are limitations of course - i.e., RS may not always reach AS = etc.  Nevertheless, it may be useful to think how other groups = approach similar problems. 

 <= /o:p>

Best, <= o:p>

--Cigdem&nbs= p;

 <= /o:p>

 <= /o:p>

On Mon, Oct = 23, 2017 at 2:38 PM, Ludwig Seitz <ludwig.seitz@ri.se> = wrote:

Hello = ACE,

Jim Schaad has brought up an interesting question [1] on = draft-ietf-ace-oauth-authz [2]:

Currently when a client makes an = unauthorized request to a resource server, it gets back the address of = the authorization server and optionally a nonce (to prevent replay = attacks).

Jim is suggesting to add hints to the audience and = scope the resource server expects for accessing this = resource.

I'm not sure whether that would not reveal too much = information to a potential attacker.

What does the group think of = this issue?

/Ludwig


[1] https://github.com/ace-wg/ace-oauth/issues/124
[= 2] https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-= 08#section-5.1.2
--
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

 <= /o:p>

------=_NextPart_000_01A9_01D34DA3.C68B9200-- From nobody Thu Oct 26 20:21:01 2017 Return-Path: X-Original-To: ace@ietf.org Delivered-To: ace@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CA8A138BD8; Thu, 26 Oct 2017 20:21:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: internet-drafts@ietf.org To: Cc: ace@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.63.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150907446020.22131.17380482674630558610@ietfa.amsl.com> Date: Thu, 26 Oct 2017 20:21:00 -0700 Archived-At: Subject: [Ace] I-D Action: draft-ietf-ace-cbor-web-token-09.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2017 03:21:00 -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 : CBOR Web Token (CWT) Authors : Michael B. Jones Erik Wahlström Samuel Erdtman Hannes Tschofenig Filename : draft-ietf-ace-cbor-web-token-09.txt Pages : 24 Date : 2017-10-26 Abstract: CBOR Web Token (CWT) is a compact means of representing claims to be transferred between two parties. The claims in a CWT are encoded in the Concise Binary Object Representation (CBOR) and CBOR Object Signing and Encryption (COSE) is used for added application layer security protection. A claim is a piece of information asserted about a subject and is represented as a name/value pair consisting of a claim name and a claim value. CWT is derived from JSON Web Token (JWT), but uses CBOR rather than JSON. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ace-cbor-web-token/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ace-cbor-web-token-09 https://datatracker.ietf.org/doc/html/draft-ietf-ace-cbor-web-token-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-cbor-web-token-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Oct 26 20:30:15 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4F051391C3 for ; Thu, 26 Oct 2017 20:30:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.8 X-Spam-Level: X-Spam-Status: No, score=-4.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dKFMSLjjRnbd for ; Thu, 26 Oct 2017 20:30:11 -0700 (PDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0109.outbound.protection.outlook.com [104.47.42.109]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A9AA138BD8 for ; Thu, 26 Oct 2017 20:30:11 -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=WstnC3g6j2z7l/GMX9kc2g9a/RoEVmgIN9FFKn7EEdk=; b=RUxh8+HlX/QMuqDDPqFm/xoH9I+Dt5xcrQ01sg1YuP6U/gsX0lEuUek8Ri1IpbLJ6iUuNoMd3ccafruVtBeH1BYwNyVBX1hbkCr6zJZjLPPTDuwK1y0zf5QZR4RUo5gXJFblWmJ3ynuOm7ILSlS96kQh3Ar3pejqBKN/o24osNg= Received: from CY4PR21MB0504.namprd21.prod.outlook.com (10.172.122.14) by CY4PR21MB0630.namprd21.prod.outlook.com (10.175.115.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.197.0; Fri, 27 Oct 2017 03:30:10 +0000 Received: from CY4PR21MB0504.namprd21.prod.outlook.com ([10.172.122.14]) by CY4PR21MB0504.namprd21.prod.outlook.com ([10.172.122.14]) with mapi id 15.20.0197.006; Fri, 27 Oct 2017 03:30:10 +0000 From: Mike Jones To: "ace@ietf.org" CC: Giridhar Mandyam Thread-Topic: CBOR Web Token (CWT) specification adding CBOR_Key values and Key IDs to examples Thread-Index: AdNO0KFbAtgR5kXAR5Ka9ZI+P7HMTA== Date: Fri, 27 Oct 2017 03:30:10 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Ref=https://api.informationprotection.azure.com/api/72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=mbj@microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2017-10-26T20:30:09.1673527-07:00; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic; Sensitivity=General x-originating-ip: [2001:4898:80e8:d::36] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR21MB0630; 6:mLUtQR7lL9y1fswxfrS6mKvPeqI//fu8yFPbYWhRZY+T0V/wUaWFXm/z3EFFEy0cbdGgXHEoS6c7PDDhBM9KnC2+9qyLdWm7O38rtJVMvrtez51lu9lGjFLxTHmSo+sNnahW2bo89QVO9IIeToGvIhZoZrAhx+yWNg3NaqhSTwM53Pto+wq8FiDBbG0zpTAU8/s7z0I9h9l5ojXgi3EFw2MxNVUTVfnshnsleFOngh/G2akuxDUXULD2I93VS4H98OYzFsWnDvJC30l0G0a3Zwa0/RL+YhGIeQ3iu/Y4M4B81hnMRIhC9pVyPYhue9lxptIiphfM2960bEsXqjOoemlsRBx6ad+1kjIRqrMjEc0=; 5:HsE4aC+OAGo4xQ3lc0Z4fUcGUWWBg+sSPTDgKPyCQzPlSnqhLwsnMf3dpzZZjQlV7Woe9cjRPiEGIwcKT2/hWLoBU1jzmFKHa1zPjYoj12l6mbkmPWjFsmQzUqDxLxLWFHFIMcTs/n/8MkV7kOyOwc9qaVFORcKuuR1aFupL6Rw=; 24:nXsdqg/vfsawh1VgWBAedttSuOVF2f5DIg5J0ngbf5OCtKrZFqAnzI5fCi0ZvcgqyiPU61oc4ML0juCebT5rl2cPRzHYj8Mlm1wsKiiK0JM=; 7:HqECiH/W59l9yJAp4mvMsBKb65FQCgGJTwILtQ1xZPt33WBekAADGHuEB/DIyrqLPrxmbMBR+pCnnq0i/W5stIhGwUIUSfpAZxflZr49r/hlRXi0ZVDTGuehkYV49RFaiSnkOAqCNq3pFQ9yE/68/T4YjBzIuaFSaiPu5NCNT5S/14famqqbO4VP2A/u8n2ArdaxIl49Y8ydVwvfvCDa1Apq/MD+SuSwszWzg9LEDGvkvic8CFQ86JF+JVtrytiN x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 7f4c59b7-22f0-4f62-100b-08d51ceb0741 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(48565401081)(2017052603238); SRVR:CY4PR21MB0630; x-ms-traffictypediagnostic: CY4PR21MB0630: x-exchange-antispam-report-test: UriScan:(31418570063057)(21748063052155); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(2401047)(5005006)(8121501046)(3231020)(10201501046)(93006095)(93001095)(3002001)(100000703101)(100105400095)(6055026)(61426038)(61427038)(6041248)(20161123564025)(20161123560025)(20161123562025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR21MB0630; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR21MB0630; x-forefront-prvs: 0473A03F3F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(346002)(376002)(209900001)(47760400005)(199003)(189002)(99286003)(478600001)(5660300001)(54896002)(22452003)(9686003)(74316002)(3660700001)(966005)(4326008)(101416001)(2501003)(55016002)(6916009)(316002)(6436002)(606006)(2351001)(81156014)(81166006)(3280700002)(72206003)(6306002)(2906002)(54356999)(50986999)(236005)(8936002)(53936002)(10290500003)(53376002)(14454004)(189998001)(10090500001)(86362001)(790700001)(77096006)(7736002)(97736004)(8676002)(102836003)(6116002)(6506006)(33656002)(5630700001)(86612001)(25786009)(7696004)(8990500004)(2900100001)(5640700003)(1730700003)(105586002)(106356001)(68736007)(6606295002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0630; H:CY4PR21MB0504.namprd21.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; 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; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR21MB0504C78A140030F5970D8C18F55A0CY4PR21MB0504namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 7f4c59b7-22f0-4f62-100b-08d51ceb0741 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Oct 2017 03:30:10.5818 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0630 Archived-At: Subject: [Ace] CBOR Web Token (CWT) specification adding CBOR_Key values and Key IDs to examples 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, 27 Oct 2017 03:30:14 -0000 --_000_CY4PR21MB0504C78A140030F5970D8C18F55A0CY4PR21MB0504namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable A new CBOR Web Token (CWT) draft has been published that adds CBOR_Key valu= es and Key IDs to examples. Thanks to Samuel Erdtman for working on the ex= amples, as always. Thanks to Giridhar Mandyam for validating the examples! I believe that it's time to request publication, as there remain no known i= ssues with the specification. The specification is available at: * https://tools.ietf.org/html/draft-ietf-ace-cbor-web-token-09 An HTML-formatted version is also available at: * http://self-issued.info/docs/draft-ietf-ace-cbor-web-token-09.html -- Mike P.S. This notice was also posted http://self-issued.info/?p=3D1744 and as = @selfissued. --_000_CY4PR21MB0504C78A140030F5970D8C18F55A0CY4PR21MB0504namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

A new CBOR Web Token (CWT) draft has been published = that adds CBOR_Key values and Key IDs to examples.  Thanks to Samuel E= rdtman for working on the examples, as always.  Thanks to Giridhar Man= dyam for validating the examples!

 

I believe that it’s time to request publicatio= n, as there remain no known issues with the specification.

 

The specification is available at:

 

An HTML-formatted version is also available at:=

--_000_CY4PR21MB0504C78A140030F5970D8C18F55A0CY4PR21MB0504namp_-- From nobody Fri Oct 27 19:42:51 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56DAB13F647; Fri, 27 Oct 2017 19:42:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.8 X-Spam-Level: X-Spam-Status: No, score=-4.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G2sJCFbvllh6; Fri, 27 Oct 2017 19:42:48 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0136.outbound.protection.outlook.com [104.47.36.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07D3F13F61A; Fri, 27 Oct 2017 19:42:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=7qCKYQUVS3JV8uapDrgL05135pWuTWzM5AQT/zXbnEs=; b=FEoN0iA2+DMAplHuZptg7oVVgeuOfDVCXf0qNSks2VVkfE9JKZghldDxr8gHqbuuz81TwJpcnMiPruqNltYhxaUPYArMArVQhckHQRmDBYV0Zo2d2BQ/tBYoEifKso5UMCMPUbLbXwMOwetyn977DhirS+ZwWtYOkswKhiyPE9A= Received: from CY4PR21MB0504.namprd21.prod.outlook.com (10.172.122.14) by CY4PR21MB0776.namprd21.prod.outlook.com (10.173.192.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.197.0; Sat, 28 Oct 2017 02:42:46 +0000 Received: from CY4PR21MB0504.namprd21.prod.outlook.com ([10.172.122.14]) by CY4PR21MB0504.namprd21.prod.outlook.com ([10.172.122.14]) with mapi id 15.20.0197.006; Sat, 28 Oct 2017 02:42:46 +0000 From: Mike Jones To: Jim Schaad , "draft-ietf-ace-cwt-proof-of-possession@ietf.org" CC: "ace@ietf.org" Thread-Topic: Review of draft-ietf-ace-cwt-proof-of-possession 00 Thread-Index: AdNK51eJVdMxwVzaR2e/K3pQ6x7sxQEpUJig Date: Sat, 28 Oct 2017 02:42:46 +0000 Message-ID: References: <01d001d34b94$cb43d660$61cb8320$@augustcellars.com> In-Reply-To: <01d001d34b94$cb43d660$61cb8320$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Ref=https://api.informationprotection.azure.com/api/72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=mbj@microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2017-10-27T19:42:43.9200676-07:00; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic; Sensitivity=General x-originating-ip: [2001:4898:80e8:e::36] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR21MB0776; 6:GVnTAfxa4454TkLBB4FOWyPDhqsM7sfn+cT5iMQgn+tVPSikBHUntlWbtGJ5+NpurtGOTUt8MVtf8BuKxfnYvIpUQ4ztMspvzyiInmu4X0qpf6vTkVEOioFKkQBF+SDqcPolnwAvJRw7lPLNsPWP7To45vIWkS778Qqhm6VB6jEE/yifAahFSbPk+UHzA1Vj4O9awquF49hh5sy8XcVvazmp0Gd/su0ZVEy1A3eWSWXo5iK3ru+utUjn/fmugENyaheRTyvHqcquapUn3DmkmPa3Kcw57lgqXGOAu7Dd8NDgwPj1XtWFz6pJ4EHF39HDGWwhMgOdh0w+qimKZXjSnL9CFTNuE0B1DQOSwzyqhQA=; 5:Y+o9s1AAtJaL3QR5bsCB1Gz1M0eo0hJkrKB8lri/NBTCd1GY4J9jkcGNy/J6plOlyaA1KP5Hg9H9Utn2vwZTI4AqEhByd9A4ffA4ICfIvGa/XCY2jx6pllPy+9i97cMcM0lRmaUMG2h3fmgjn94RkjIydwmzUfa1yJLisCUHWWw=; 24:IQw+HNUkVkdVmvaFXrCWZARe49I17WxTjSvUyIAuYXG0Y94mtBgUZKlnJ87Bet9WPTS/+2ywEthKXq4wKvIOPG9fRBpSv/R2h1T5+0b7Rp4=; 7:sO43qQd3VRtfrQmUUBxFTXw2PrnlvKixuqAI00jhgK1wO9krt8AjofpDYTJcSUmxTrzSX7HFGC0Bd9+tWENHUTjHz7ZSma/bVgad3p4rlW3skCySpDBocCecxEc0/SUL9lK4C6VtNZrnegLEY6YyIyqlko/d6NIl8gXeS3QUGDyLEda3UMuRJWrXiPF5bszmt0edTSccfvQxr4KGkMu5OBAGZctAyFQo7HQS4M7x3YoSoyF2JQL72cg99enqEqvz x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: df8c66b8-d132-40e6-1f20-08d51dad9246 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081)(4534020)(4602075)(2017052603238); SRVR:CY4PR21MB0776; x-ms-traffictypediagnostic: CY4PR21MB0776: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-exchange-antispam-report-test: UriScan:(278428928389397)(192374486261705); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(2401047)(8121501046)(5005006)(10201501046)(100000703101)(100105400095)(3002001)(93006095)(93001095)(3231020)(6055026)(61426038)(61427038)(6041248)(20161123558100)(20161123560025)(20161123562025)(20161123564025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR21MB0776; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR21MB0776; x-forefront-prvs: 04740D25F1 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(346002)(376002)(47760400005)(13464003)(199003)(51914003)(43784003)(189002)(51444003)(8676002)(229853002)(230783001)(6116002)(81166006)(55016002)(99286003)(102836003)(81156014)(101416001)(2950100002)(9686003)(7696004)(5660300001)(33656002)(77096006)(305945005)(6506006)(7736002)(6436002)(74316002)(106356001)(105586002)(2900100001)(14454004)(10090500001)(53546010)(97736004)(110136005)(8990500004)(25786009)(2501003)(316002)(72206003)(478600001)(10290500003)(8936002)(22452003)(189998001)(86612001)(86362001)(76176999)(3660700001)(54356999)(3280700002)(4326008)(6246003)(53936002)(2906002)(50986999)(68736007); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0776; H:CY4PR21MB0504.namprd21.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: df8c66b8-d132-40e6-1f20-08d51dad9246 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Oct 2017 02:42:46.1888 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0776 Archived-At: Subject: Re: [Ace] Review of draft-ietf-ace-cwt-proof-of-possession 00 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Oct 2017 02:42:50 -0000 Thanks for the detailed review, Jim. Replies inline... -----Original Message----- From: Jim Schaad [mailto:ietf@augustcellars.com]=20 Sent: Sunday, October 22, 2017 5:21 PM To: draft-ietf-ace-cwt-proof-of-possession@ietf.org Cc: ace@ietf.org Subject: Review of draft-ietf-ace-cwt-proof-of-possession 00 * I dislike the statement of what the specification claims to do. It will= be misread by many people who are not familiar with how you are defining t= he word "presenter". If I intercept a CWT and present it to a validator, i= t does not make a claim that I possess a specific POP key. Given what a CWT is supposed to do, I believe that a much clearer statement of functionality= would be "This specification describes how to associate a set of claims i= n a CWT with a particular proof-of-possession key." Among other things, th= is would allow a third party to "present" a CWT on behalf of another party. (See introspection.) I'll look at revising this along the lines you suggest. The existing langu= age, of course, is a direct adaptation of that from RFC 7800. * I dislike the way that the second sentence of the introduction is writte= n. Please remove the text about the presenter, that is not relevant to the= holder-of-key assertion. OK * Section 2 - Issuer " Party that creates the CWT and binds the claims wit= h the POP key" The proposed language suggests something that's not true - that the PoP key= is used to sign the CWT, or something like that. It's the signing key tha= t binds the claims. * Section 2 - The definition of "presenter" in this document is odd given t= hat we are looking at ways that a CWT can be transferred by a third part. A better term would be "Holder" or "Holder of Key" I'm reluctant to undergo a wholesale change of terminology when this comes = directly from the already-approved RFC 7800. (I'm of course willing to ent= ertain clarifications.) * Section 3 paragraph 1 - This paragraph is written with some things taken = for granted that I am not user exist. 1) How is the issuer doing the decla= ration that a presenter possesses a key, is a POP of the key a requirement = to issue the CWT that I have not yet seen? 2) Again I don't like the use o= f presenter as the key usage and transfer are not necessarily done at the s= ame time. I'll think about what you're saying, but "presenter" is one of the well-def= ined roles in PoP interactions. You seem to not like the term, but it's th= e one in common use. * Section 3 paragraph 2 - You need to be clearer about what you mean by ide= ntified. My reading would be that the presenter is identified by the POP k= ey. If you want to talk about claims which contain other types of naming m= aterial, then you need to be clear that is what you are doing. OK - I'll give the claims wording suggestion a shot. * Section 3 paragraph 2 - I would skip most of the detail on the meanings o= f the different claims and just identify the number of claims and refer to = the CWT document for details on what they mean. The current text is not cl= ear, and hopefully, the CWT document is much clearer on what these mean. I'll try to strike a balance between incorporating this suggestion for addi= tional clarity and maintaining the spirit of the RFC 7800 language. (If we= deviate very much, people will rightly ask the question "Why does this hav= e a different meaning than the corresponding RFC 7800 text?") * General - Where are you defining the types and contents of the claims tha= t are being registered in this document? I cannot find it and I expected i= t to be in section 3.1 I agree more needs to be done in this regard. The current text relies too = much on things that were implicit in JSON, rather than explicitly defining = the CBOR types. * Section 3.1 para 1 - Based on the last sentence, I think that you need to= make some type of statement about the purpose of the "cnf" claim that embo= dies both a POP key and the SAML stuff that you are adding. What are the r= equirements to be here? What are the relationships between statements? It's not adding SAML stuff. It's making an analogy to a SAML feature. I'l= l try to make this clearer. * Section 3.1 para 2 - It is fine to say that what the set of methods that = must be present is application dependent, however without the presence of s= ome type of profile identification, how is an application supposed to know = if the meanings and relationships are what are expected and not from some o= ther profile? The values are always processed and validated within the context of the app= lication profile. No identifier is needed to tell the application what its= validation rules are. * Section 3.1 para 4 - The thus in the first sentence does not follow from = the requirement. There is nothing that says that the same key could not be= in both the COSE_Key and Encrypted_COSE_Key fields. I suppose that's true but why would an application do or want both unencryp= ted and encrypted representations of the same content? Requiring them to b= e mutually exclusive simplifies applications, it seems to me. * Section 3.1 para 4 - I don't understand the process defined in sentence #= 2 and why it is done this way. It would make more sense to me to say that = it could be a new field with an array of cnf values. Doing the "additional= to 'cnf'" would seem to cause potential problems when this CWT is grabbed = by somebody which does not understand how these two fields are related. OK - I'll try to make this clearer. * Change the examples to use CBOR diagnostic notation. -01 will do that, thanks to Ludwig! * Section 3.2 and 3.3 should be written in terms of the fields COSE_Key and= Encrypted_COSE_Key rather than in terms of symmetric and asymmetric keys. Then you can properly talk about public and private keys in each of the sec= tions and it is tied to the structure itself rather than inferred Again, unless the text is wrong or unclear, we plan to leave most descripti= ons parallel to those in RFC 7800. Your suggestion would be a rewrite. * Section 3.4 - I would consider this to be an unusable item for doing POP = key identification in all cases where the kid is not computed in a cryptogr= aphic manner and the method of computation is included as part of the kid. If the key ID doesn't match, the worst that will happen is the PoP verifica= tion will fail. This is analogous to why it's ok for the Key ID to be in a= n unprotected header in COSE. * Section 3.5 - Huh? I don't know about typically for the demonstration. It could just as easily be done by doing an encryption/decryption operation= or a key derivation operation such as in TLS for PSK. I don't know that t= his section is providing any useful information. If you think that it is n= eeded then a simple statement that you are not specifying how to do POP is = sufficient. If you want to supply some additional text about these other methods, that = would be welcomed. * Section 4 paragraph 2 - I can understand a reasoning for doing audience r= estrictions, but I cannot for the life of me figure out why it would be of = greater importance for POP statements than for any other set of claims. It's not more important, nor does it say that it is. But in the RFC 7800 l= ast call process, several people wanted us to add this security considerati= on. * Section 4 para 4 - How does a signed nonce prevent a replay attack with e= ncrypted symmetric secrets? Because a different nonce would be required to be used for each CWT using t= he PoP key. I'll try to clarify this. * Section 4 - I am surprised there is no statement about self-signed CWT st= atements esp. as that is given as an example of how additional naming claim= s would be understood What would you like the statement to say? * Section 5 - Need to make a statement about the correlation information t= hat a CWT issuer would have as well? The issuer is aware of all the audiences that it is issuing CWTs for. Is t= hat what you were getting after? =3D=3D=3D=3D Thanks again for the thorough review, as always! Stay tuned for -01... -- Mike From nobody Fri Oct 27 20:41:26 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEA5913968C; Fri, 27 Oct 2017 20:41:23 -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, 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=augustcellars.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id banofA_u3OlX; Fri, 27 Oct 2017 20:41:22 -0700 (PDT) Received: from mail4.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DACFB13F5BB; Fri, 27 Oct 2017 20:41:21 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1509162079; h=from:subject:to:date:message-id; bh=RNTGai6yFF128/3M6DurDqPlKshFVCxeDux1cTqFKJg=; b=OFbtT6i+ltfW9DYGnQ8yXRN3C29f6ye9y+OXlFDlHedHAwprPSUrlHwUVek28x4eT1hOmMz/Fh6 cZUcra/LH8w/N7FabW+kCt88v0otQla+GklF2BUua6OwiEgV3ka83N1Z6B9qbXV373YBsFUriR0F3 QDJBbKd/O9ROey1SQIMi+2HizJIDg4oqrXvC1nWYN21fp0+QAHDmEwPQF89bM4VKggYS+GGrvChLy fwDxVZbD5YXC5yQIBAC1YIdV314gob7GTpzrrdXfJGYXP+gXUlX3mSIO2J4+LJlSTYp8pmP0snlVi fKUdn6Sw/+b0adCFw0IxVK7UA5LlZA/R8S9Q== Received: from mail2.augustcellars.com (192.168.1.201) by mail4.augustcellars.com (192.168.1.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 27 Oct 2017 20:41:18 -0700 Received: from Hebrews (192.168.1.162) by mail2.augustcellars.com (192.168.1.201) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 27 Oct 2017 20:40:15 -0700 From: Jim Schaad To: 'Mike Jones' , CC: References: <01d001d34b94$cb43d660$61cb8320$@augustcellars.com> In-Reply-To: Date: Fri, 27 Oct 2017 20:41:11 -0700 Message-ID: <008401d34f9e$9a9094f0$cfb1bed0$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHQOgIHQTq0ey2ZPJpxFumOggl8wwJUguV4ouwiD8A= X-Originating-IP: [192.168.1.162] Archived-At: Subject: Re: [Ace] Review of draft-ietf-ace-cwt-proof-of-possession 00 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Oct 2017 03:41:24 -0000 > -----Original Message----- > From: Mike Jones [mailto:Michael.Jones@microsoft.com] > Sent: Friday, October 27, 2017 7:43 PM > To: Jim Schaad ; draft-ietf-ace-cwt-proof-of- > possession@ietf.org > Cc: ace@ietf.org > Subject: RE: Review of draft-ietf-ace-cwt-proof-of-possession 00 > > Thanks for the detailed review, Jim. Replies inline... > > -----Original Message----- > From: Jim Schaad [mailto:ietf@augustcellars.com] > Sent: Sunday, October 22, 2017 5:21 PM > To: draft-ietf-ace-cwt-proof-of-possession@ietf.org > Cc: ace@ietf.org > Subject: Review of draft-ietf-ace-cwt-proof-of-possession 00 > > > * Section 2 - Issuer " Party that creates the CWT and binds the claims with > the POP key" > > The proposed language suggests something that's not true - that the PoP key > is used to sign the CWT, or something like that. It's the signing key that binds > the claims. You are right - would be better as "bind the claims to the POP Key" > > * Section 2 - The definition of "presenter" in this document is odd given that > we are looking at ways that a CWT can be transferred by a third part. > A better term would be "Holder" or "Holder of Key" > > I'm reluctant to undergo a wholesale change of terminology when this comes > directly from the already-approved RFC 7800. (I'm of course willing to > entertain clarifications.) I'll think about a response. > * Section 3.1 para 4 - The thus in the first sentence does not follow from the > requirement. There is nothing that says that the same key could not be in > both the COSE_Key and Encrypted_COSE_Key fields. > > I suppose that's true but why would an application do or want both > unencrypted and encrypted representations of the same content? Requiring > them to be mutually exclusive simplifies applications, it seems to me. I am not objecting to the mutual exclusivity of the field. The rational needs to be appropriate > > * Section 3.2 and 3.3 should be written in terms of the fields COSE_Key and > Encrypted_COSE_Key rather than in terms of symmetric and asymmetric > keys. > Then you can properly talk about public and private keys in each of the > sections and it is tied to the structure itself rather than inferred > > Again, unless the text is wrong or unclear, we plan to leave most descriptions > parallel to those in RFC 7800. Your suggestion would be a rewrite. In my opinion, it is poorly written and confusing as to what is being accomplished and what the fields are. Reordering in this way would make it clear where currently it is not. Copying unclear text is generally not useful. > > * Section 3.4 - I would consider this to be an unusable item for doing POP key > identification in all cases where the kid is not computed in a cryptographic > manner and the method of computation is included as part of the kid. > > If the key ID doesn't match, the worst that will happen is the PoP verification > will fail. This is analogous to why it's ok for the Key ID to be in an unprotected > header in COSE. In the case of COSE, if you identify the wrong key then it would not validate. In this case if you have two different keys that had been presented to you with the same Key ID value and two different keys, when you get the CWT you do not know which of two keys is the POP key and which is not. The cases are not analogous. > > * Section 3.5 - Huh? I don't know about typically for the demonstration. > It could just as easily be done by doing an encryption/decryption operation > or a key derivation operation such as in TLS for PSK. I don't know that this > section is providing any useful information. If you think that it is needed then > a simple statement that you are not specifying how to do POP is sufficient. > > If you want to supply some additional text about these other methods, that > would be welcomed. I'll try and remember to look at this. If I don't have anything by the F2F remind me. > > * Section 4 paragraph 2 - I can understand a reasoning for doing audience > restrictions, but I cannot for the life of me figure out why it would be of > greater importance for POP statements than for any other set of claims. > > It's not more important, nor does it say that it is. But in the RFC 7800 last call > process, several people wanted us to add this security consideration. I'll re-read. > > * Section 4 - I am surprised there is no statement about self-signed CWT > statements esp. as that is given as an example of how additional naming > claims would be understood > > What would you like the statement to say? Something along the lines of it is only as good as the original trust in that person. Self-asserted statements are always suspect. > > * Section 5 - Need to make a statement about the correlation information > that a CWT issuer would have as well? > > The issuer is aware of all the audiences that it is issuing CWTs for. Is that > what you were getting after? No, I was thinking that a CWT issuer would know all of the audiences/permissions that a client is asking for using the same authentication key to the CWT even if the keys used to the servers are different. > > ==== > > Thanks again for the thorough review, as always! Stay tuned for -01... > > -- Mike > > > From nobody Sat Oct 28 00:46:46 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C88BB13FA75 for ; Sat, 28 Oct 2017 00:46:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.7 X-Spam-Level: X-Spam-Status: No, score=-4.7 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, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 70TuvvNep9xI for ; Sat, 28 Oct 2017 00:46:43 -0700 (PDT) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50087.outbound.protection.outlook.com [40.107.5.87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8862013FA77 for ; Sat, 28 Oct 2017 00:46:42 -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=W4OMHZP+C0CnuK5Z0BY77wUwGcJ+e4AvEbFvL8qWyd8=; b=P3V16ZvudTE9D225vVrzEs5dkXPtyPlZL+0lEcLmGvFSJZlfdSF21aNtV5R3h28oXn32IlC6/ExAqQqYP3wrgU5zCRclAanc02o6Okja4kbllfBG7abHzp5Szr0sgLs4RgvTAylw8ijWKM+yLIe4AL4WcWXpauanouT/+gjbF/0= Received: from AM4PR0801MB2706.eurprd08.prod.outlook.com (10.167.90.148) by AM4PR0801MB2708.eurprd08.prod.outlook.com (10.167.90.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.178.6; Sat, 28 Oct 2017 07:46:39 +0000 Received: from AM4PR0801MB2706.eurprd08.prod.outlook.com ([fe80::403b:850e:c32c:fad6]) by AM4PR0801MB2706.eurprd08.prod.outlook.com ([fe80::403b:850e:c32c:fad6%13]) with mapi id 15.20.0178.007; Sat, 28 Oct 2017 07:46:32 +0000 From: Hannes Tschofenig To: "ace@ietf.org" Thread-Topic: Thanks Thread-Index: AdNPv4VdK7Fq99eDSEm7EWXC0mdUOQ== Date: Sat, 28 Oct 2017 07:46:32 +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: [178.165.128.6] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM4PR0801MB2708; 6:lcMzjh45ZO7rR8B3TwdTQ1e7It3MuvBEwOUp7ZUQ0/3kSHeGy/qP4XNwhfS/B6OlIXcUpZZ2Llw0lCdV+72B8hDqYjoHEPH6c8GdBqG0n+GuamMFXGIcSuPqvQA3y7W4Zq1OR4ZLkaZp9nm6lK8aF2KxP7SP3ROsSRBCxLM63Gv+5CforFC/vFZnXaaTkRMWAyfdt0dHihX2GBLw48bSWoORgTo+v9us7nARQhjcuJsIq0/lERlfgxrVFKDmaH7GYHZvcSxys/DwVs3jJWWIAE8hqKkDQ7V/ptftkhOL5JwBgmK2lBnUcyldcuM4f3FOOPIhI/tvXeWEt+f9XTyXSUeqDFWqFS+By3tni2dPahc=; 5:yGLxnbIWyTc3aHGxast1whvdq2WJWwk5cIex7bmHKj49YbyxPzDcYeCSF9yWDMqCdu7WXFDEVaVsuM/iPkxMUYR18mh+iXfZsrTSkUGaZ347ZM9yPn9eEN73TcQ7naslWHF/Z03A97seyiQFAJYzc9kQlw3jHH7XbEZVXgD4rvE=; 24:CVXM9nQVUOm/wMBM1bLtAjPf466bT7PHARECgoj1qSO3U8lDYWVNbvN7DDj4SQNZxufVJbQ6UdYwpgMBBgybOW1ULaJoUdkJtOB4b5ZUlUo=; 7:RQQBHjebp/WCRQRV6KUr49WhIMbLQSVdWTd7jh2uHiiP/eybcOe8bg1qkv+CsCGB4yTCyywjceyOd/Mf6f/l8iga7FLPNKOWhwBoxACPlaQHmpmm8NKeYNR/f1oE9HkQd413CZQOPN5qBGGtTemQkD+Fs8fzT9+grRzxpeApQ9CRJFDMFIZ7Pgj3pjhZdEJk3bEY9RAo2qro5MHpMFZrS65GN2ygduai2hedsbayL2fTRjg0z7EUdiL+9kUg8oEc x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: d5759f5e-2961-4010-1e4d-08d51dd8020d x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081)(4534020)(4602075)(2017052603199); SRVR:AM4PR0801MB2708; x-ms-traffictypediagnostic: AM4PR0801MB2708: x-exchange-antispam-report-test: UriScan:(21748063052155); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(100000703101)(100105400095)(3231020)(10201501046)(3002001)(6055026)(6041248)(20161123558100)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123555025)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM4PR0801MB2708; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM4PR0801MB2708; x-forefront-prvs: 04740D25F1 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39860400002)(346002)(376002)(53754006)(189002)(40434004)(199003)(54896002)(3480700004)(53936002)(55016002)(6436002)(99286003)(2351001)(86362001)(9686003)(68736007)(221733001)(5630700001)(6506006)(2900100001)(7696004)(6306002)(25786009)(72206003)(5640700003)(7116003)(5660300001)(14454004)(3280700002)(50986999)(7736002)(66066001)(587384001)(790700001)(6116002)(54356999)(106356001)(74316002)(6916009)(189998001)(102836003)(33656002)(478600001)(3846002)(316002)(5890100001)(5250100002)(8676002)(2906002)(2501003)(97736004)(8936002)(101416001)(81166006)(105586002)(81156014)(3660700001)(1730700003); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR0801MB2708; H:AM4PR0801MB2706.eurprd08.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AM4PR0801MB2706A0D2C0590AA8E4FCD0BDFA5B0AM4PR0801MB2706_" MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: d5759f5e-2961-4010-1e4d-08d51dd8020d X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Oct 2017 07:46:32.6098 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR0801MB2708 Archived-At: Subject: [Ace] Thanks X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Oct 2017 07:46:45 -0000 --_000_AM4PR0801MB2706A0D2C0590AA8E4FCD0BDFA5B0AM4PR0801MB2706_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, I would like to inform you all that I would like to resign from my ACE WG c= o-chair role. It has been an interesting experience although various mistakes had been ma= de along the way. I am, however, positive that the group will produce speci= fications that get deployed. 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_AM4PR0801MB2706A0D2C0590AA8E4FCD0BDFA5B0AM4PR0801MB2706_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

I would like to inform you all that I would like to = resign from my ACE WG co-chair role.

 

It has been an interesting experience although vario= us mistakes had been made along the way. I am, however, positive that the g= roup will produce specifications that get  deployed.

 

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_AM4PR0801MB2706A0D2C0590AA8E4FCD0BDFA5B0AM4PR0801MB2706_-- From nobody Sat Oct 28 04:23:29 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EEBF13FA3C for ; Sat, 28 Oct 2017 04:23:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 62SjTHvOk8r3 for ; Sat, 28 Oct 2017 04:23:26 -0700 (PDT) Received: from mail-pg0-x232.google.com (mail-pg0-x232.google.com [IPv6:2607:f8b0:400e:c05::232]) (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 880C213F98D for ; Sat, 28 Oct 2017 04:23:26 -0700 (PDT) Received: by mail-pg0-x232.google.com with SMTP id p9so7282072pgc.8 for ; Sat, 28 Oct 2017 04:23:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=LMgsj2iHtr0DaMaV/HBPU+QRhKx+vg7opS9F+UFQzGM=; b=bejfBQuGpTaQaHjWwpGfibcREYncBD938BF18r3lCVnfJ93ufFXEj9XAdVpRxQjezv Ozkhira7jIMaMESNpZVdKr+vqCkd8jjtaRU/WF2p9ystVtVB09NVEJ/3aTiN3DjmCy2r Ioy44WPZCpK73yYjxO1WI7+PYT8u//bt2o+74Fzdrj/dXiyCAi3dJLMt5pyw4dNlsWTC Mnp0Lt+wP3EKw71m928XvXgIXgXBKTowFmX+n4KXIxVkd26xXFWv0MhqtzzV/uQjER5V bOOCuWAzFIIdIQQzPL5/CfGOhLSQQrqdK8ASbITUwJ1Uk2xNlmkaVsxWYplaowtETA6d 0kzA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=LMgsj2iHtr0DaMaV/HBPU+QRhKx+vg7opS9F+UFQzGM=; b=R6EgiZnwQhm1419V9CSFmevR55Vofc1AclQDTGdojp+Z9TJniPADzHnOrBNq9+79ix lNHO+ndkXcXw9XNPfcyUt6TBk2eqoFdJyllkSF1A3FZfH07f/lK03JuIorH2JPS/mkhn uwLNQKXCbk53/OK3Q8LJW1cLK21nOEyxy/aWIq0Y83vSmBHoN9ZCva4i/EZEfyx8Vsks DmlRL+WPrEer3WHCASnA5gfuS2H8Ces6b+fP+lNSMDvARxDewk4y7vEdDXQhXjonZmqR uc6BaohlXq1TeTHCVPoAMBwKO7oqg3DFqwlR6urNRgmoRGfy+ibLYffr0W6foldDKBkB u/CA== X-Gm-Message-State: AMCzsaUXwBLKvoV0fvLNMaCjZKGQ9IqxNcyUp06+Ifojg9Ht77YJ81Xv C1qC5UWrCfExT1kBH0IzScCmy4i35ozl5o59Lzs= X-Google-Smtp-Source: ABhQp+RuKeWV9/matbQePiRNb7mns1/ptjVfJo4GXS4b7AuyGS1lr30ZZmLVKIYl8bX1Q02y7kkd2MsRiEUFsEW/IeI= X-Received: by 10.99.113.92 with SMTP id b28mr2866115pgn.42.1509189805652; Sat, 28 Oct 2017 04:23:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.186.194 with HTTP; Sat, 28 Oct 2017 04:22:45 -0700 (PDT) From: Kathleen Moriarty Date: Sat, 28 Oct 2017 07:22:45 -0400 Message-ID: To: "ace@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [Ace] Chairs X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Oct 2017 11:23:28 -0000 I would like to thank both Hannes and Kepeng for serving as ACE chairs for the last 3+ years. Kepeng is not able to attend the Singapore meeting, and while is very interested to continue work in the IETF, he doesn't have the support at the moment and thought it was best to resign for now. He does hope to continue to participate in the WG. Hannes is deeply embedded in this space and would like to be a better advocate for his position with more flexibility to author drafts as a participant. A big thanks to both of you for your time and leadership moving the group to solution work! Jim Schaad and Ben Kaduk have volunteered as new chairs. Thank you both in advance for your work and efforts to drive this important working group forward toward meeting it's next set of milestones. -- Best regards, Kathleen From nobody Sat Oct 28 04:50:51 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B50713F4F4 for ; Sat, 28 Oct 2017 04:50:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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=alibaba-inc.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G61m7DLE2iD0 for ; Sat, 28 Oct 2017 04:50:47 -0700 (PDT) Received: from out0-195.mail.aliyun.com (out0-195.mail.aliyun.com [140.205.0.195]) (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 6DC6813F5EF for ; Sat, 28 Oct 2017 04:50:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1509191442; h=Date:Subject:From:To:Message-ID:Mime-version:Content-type; bh=Wj7gQsQiWPhpdNV6FvL9srqe3PQ9Z2HHXh9+IInBE4g=; b=CHt0qaNr13M++MAwgl9W5nHqGxtqfm8aQzeqKE4oMcLIrcedgQoR4HLaqSQ8aRybV/L4SKPngTubSSRbUAa7WF36QOVBxGw5XRrk+ySwe5SkYiXw5aitfIS81L8ftHy5T+1TlQnRoYO9TS0ZWogXcBq+cvkeFavBrtvnJe6Ezak= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R181e4; FP=0|-1|-1|-1|0|-1|-1|-1; HT=e02c03300; MF=kepeng.lkp@alibaba-inc.com; NM=1; PH=DS; RN=2; SR=0; TI=SMTPD_---.9Ft.9R-_1509191427; Received: from 30.39.39.196(mailfrom:kepeng.lkp@alibaba-inc.com ip:121.0.29.163) by smtp.aliyun-inc.com(127.0.0.1); Sat, 28 Oct 2017 19:50:37 +0800 User-Agent: Microsoft-MacOutlook/14.6.8.160830 Date: Sat, 28 Oct 2017 19:50:26 +0800 From: "Kepeng Li" To: Kathleen Moriarty , "ace@ietf.org" Message-ID: Thread-Topic: [Ace] Chairs References: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="GB2312" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [Ace] Chairs X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Oct 2017 11:50:49 -0000 Hello all, I would like to take this opportunity to thank all the participants in ACE WG to support our work. I enjoyed very much with our ACE work, and I learned a lot from the group. I will try my best to assist with a smooth transition with Jim Schaad and Ben Kaduk. I will continue to participate in the mailing list. Thank you all! Kind Regards Kepeng=20 =D4=DA 28/10/2017, 7:22 PM=A3=AC "Ace on behalf of Kathleen Moriarty" =D0=B4=C8=EB: >I would like to thank both Hannes and Kepeng for serving as ACE chairs >for the last 3+ years. Kepeng is not able to attend the Singapore >meeting, and while is very interested to continue work in the IETF, he >doesn't have the support at the moment and thought it was best to >resign for now. He does hope to continue to participate in the WG. > >Hannes is deeply embedded in this space and would like to be a better >advocate for his position with more flexibility to author drafts as a >participant. > >A big thanks to both of you for your time and leadership moving the >group to solution work! > >Jim Schaad and Ben Kaduk have volunteered as new chairs. Thank you >both in advance for your work and efforts to drive this important >working group forward toward meeting it's next set of milestones. > >--=20 > >Best regards, >Kathleen > >_______________________________________________ >Ace mailing list >Ace@ietf.org >https://www.ietf.org/mailman/listinfo/ace From nobody Sat Oct 28 05:15:52 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6EAF13FADD for ; Sat, 28 Oct 2017 05:15:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 aIfOUsopbhwk for ; Sat, 28 Oct 2017 05:15:49 -0700 (PDT) Received: from se-out1.mx-wecloud.net (se-out1.mx-wecloud.net [89.221.255.93]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DFBB13FAD7 for ; Sat, 28 Oct 2017 05:15:48 -0700 (PDT) Received: from sp-mail-2.sp.se (unknown [194.218.146.197]) by se-out1.mx-wecloud.net (Postfix) with ESMTPS id 59B1520476B; Sat, 28 Oct 2017 12:15:44 +0000 (UTC) Received: from [192.168.0.64] (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; Sat, 28 Oct 2017 14:15:45 +0200 To: Kepeng Li , CC: Kathleen Moriarty , "Hannes.Tschofenig@gmx.net" References: From: Marco Tiloca Message-ID: <6317846c-6b1b-5bee-683b-abcc2bedf5c1@ri.se> Date: Sat, 28 Oct 2017 14:15:39 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="oSSaJAnJer2axOvAK37e4bN5lXJM9s1df" X-Originating-IP: [10.116.0.226] X-ClientProxiedBy: sp-mail-1.sp.se (10.100.0.161) To sp-mail-2.sp.se (10.100.0.162) X-CMAE-Score: 0 X-CMAE-Analysis: v=2.2 cv=cdiiljLM c=1 sm=1 tr=0 a=L5DDne6A+dD0FbDkt2Fblw==:117 a=L5DDne6A+dD0FbDkt2Fblw==:17 a=sZ8rJzgPlrQA:10 a=02M-m0pO-4AA:10 a=r77TgQKjGQsHNAKrUKIA:9 a=48vgC7mUAAAA:8 a=xPT6tdSuAAAA:8 a=wkFRFiBuAxUKvAOnoU0A:9 a=faDdQb-8TF1WGc9f:21 a=UF-F8nIjHdBjzSy8:21 a=pILNOxqGKmIA:10 a=V4zo2IF0AAAA:8 a=LU-6zIy1Zp28TnQ8ImUA:9 a=enMN8NTO88o393AL:21 a=nDb15cpqWHJlXo_m:21 a=QpdFXz6CdNS68Hdt:21 a=_W_S_7VecoQA:10 a=RAvyNvpThlYExiLgNXkA:9 a=ONNS8QRKHyMA:10 a=w1C3t2QeGrPiZgrLijVG:22 a=80PJfYVSYmV_jLpvUEnt:22 a=kcQYkljjMzlkGLXDm-6B:22 X-Virus-Scanned: clamav-milter 0.99.2 at MailSecurity X-Virus-Status: Clean X-MailSecurity-Status: 0 X-Scanned-By: WeCloud MailSecurity X-MailSecurity-Score: 0 Archived-At: Subject: Re: [Ace] Call for adoption of draft-seitz-ace-oscoap-profile X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Oct 2017 12:15:51 -0000 --oSSaJAnJer2axOvAK37e4bN5lXJM9s1df Content-Type: multipart/mixed; boundary="1dv6ltOgWGavQSvpo96fWuhM9V7L9SuOI"; protected-headers="v1" From: Marco Tiloca To: Kepeng Li , Ace@ietf.org Cc: Kathleen Moriarty , "Hannes.Tschofenig@gmx.net" Message-ID: <6317846c-6b1b-5bee-683b-abcc2bedf5c1@ri.se> Subject: Re: [Ace] Call for adoption of draft-seitz-ace-oscoap-profile References: In-Reply-To: --1dv6ltOgWGavQSvpo96fWuhM9V7L9SuOI Content-Type: multipart/alternative; boundary="------------1142F06C59C7A0B175E8C6F9" Content-Language: en-US This is a multi-part message in MIME format. --------------1142F06C59C7A0B175E8C6F9 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I support the adoption of the OSCOAP profile of ACE. Best, /Marco On 2017-10-23 15:17, Kepeng Li wrote: > Hello all, > =A0 > > According to our virtual interim meeting minutes[1], we have clear > supports to=A0adopt the OSCOAP profile draft [2] during the meeting. =A0= > > =A0 > > This note is asking for confirmation of this tentative adoption > decision on the mailing list.=A0 Please speak up before 7th Nov, 2017 i= f > you would like to register your opinion on the adoption question. > > > Keep in mind that adoption of a document does not mean the document > as-is is ready for publication. It is merely acceptance of the > document as a starting point for what will be the final product of the > ACE working group. The working group is free to make changes to the > document according to the normal consensus process. > =A0 > Please reply on this thread with expressions of support or opposition, > preferably with comments, regarding accepting this as a work item. > > =A0 > > Thanks > =A0 > Kind Regards > Kepeng and Hannes (ACE co-chairs) > > [1]=A0https://datatracker.ietf.org/meeting/interim-2017-ace-02/material= s/minutes-interim-2017-ace-02-201710181300/ > > [2]=A0https://datatracker.ietf.org/doc/draft-seitz-ace-oscoap-profile/ > > > > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace --=20 Marco Tiloca, PhD Research Institutes of Sweden RISE ICT/SICS Isafjordsgatan 22 / Kistag=E5ngen 16 SE-164 40 Kista (Sweden) Phone: +46 (0)70 60 46 501 https://www.sics.se https://www.sics.se/~marco/ The RISE institutes Innventia, SP and Swedish ICT have merged in order to become a stronger research and innovation partner for businesses and society. SICS Swedish ICT AB, has now changed name to RISE SICS AB. --------------1142F06C59C7A0B175E8C6F9 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I support the adoption of the OSCOAP profile of ACE.

Best,
/Marco

On 2017-10-23 15:17, Kepeng Li wrote:<= br>
Hello all,
= 
=A0

Accor= ding to our virtual interim meeting minutes[1], we have clear supports to=A0adopt the OSCOAP profile draft [2= ] during the meeting. =A0

=A0

This note is asking for confirmation of this tentative adoption decision on the mailing list.=A0 Please spea= k up before 7th Nov, 2017 if you would like to register your opinion on the adoption question.


Keep in mind that adopti=
on of a document does not mean the document as-is is ready for publicatio=
n. It is merely acceptance of the document as a starting point for what w=
ill be the final product of the ACE working group. The working group is f=
ree to make changes to the document according to the normal consensus pro=
cess.
=A0
Please reply on this thr=
ead with expressions of support or opposition, preferably with comments, =
regarding accepting this as a work item.

=A0

Thanks=

=A0
Kind Regards
Kepeng and Hannes (ACE co-chairs)=





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


--=20
Marco Tiloca, PhD
Research Institutes of Sweden
RISE ICT/SICS
Isafjordsgatan 22 / Kistag=E5ngen 16
SE-164 40 Kista (Sweden)
Phone: +46 (0)70 60 46 501
https://w=
ww.sics.se
h=
ttps://www.sics.se/~marco/

The RISE institutes Innventia, SP and Swedish ICT
have merged in order to become a stronger research
and innovation partner for businesses and society.

SICS Swedish ICT AB, has now changed name to RISE SICS AB.
--------------1142F06C59C7A0B175E8C6F9-- --1dv6ltOgWGavQSvpo96fWuhM9V7L9SuOI-- --oSSaJAnJer2axOvAK37e4bN5lXJM9s1df Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZ9HTrAAoJEO4mZLQOWNpDDU8IAJX0T70hubGQbf7nF3NXXdFp 6j9ILa9h9wx3P/pVnKatkzkuHmGa2Th560klbC+aO5im7qWQuSAauksMoVRolWkG 5HNybV0Z729AWl1JRzYuWMs9yKEWcBgVCAP3xWGkOvz95CxCJt4Fl1f3c1kkmIgP m8ZCDw5KkC2cHer5ju4LC1eZZBv5Mjjilgd1MqSYUiXNIlowlmLv1m7/mFzhwct9 6d/gqc20adF4AS28UhT42SdO7UjDjs6eybUxvACsz09HosmZNBlpKCoS/rqahG2/ QhBkxRvIMSqglbrTiqfNBn53Y6JBn9fa5u9KOpK3iGPIZUF/+bgwvEHbMSq+GqE= =u7dZ -----END PGP SIGNATURE----- --oSSaJAnJer2axOvAK37e4bN5lXJM9s1df-- From nobody Mon Oct 30 01:57:19 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6DEC13F8BD for ; Mon, 30 Oct 2017 01:57:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 ctRdq2KS_Zqv for ; Mon, 30 Oct 2017 01:57:16 -0700 (PDT) Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::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 CC7F813F8B0 for ; Mon, 30 Oct 2017 01:57:13 -0700 (PDT) Received: by mail-qt0-x235.google.com with SMTP id 1so15399492qtn.3 for ; Mon, 30 Oct 2017 01:57:13 -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=tyItPYr7Q+E1REYtD4gJ9u2mG5VFnbNsWZeMPqfuo1o=; b=gGj0hSAYBxKICPiZewZDvhj4acE3DmKhu3fNY/rdgFeGKNMnP4JvB0GU3odBH6ljWD N/AvKAwhUc4a9kFrMiTHMFiknkwPqlJmlTAVF3Z7Xc4rpv/z8rz2TqDdO9vstIEpaQ/D 64av6do3404qlLGRDnH99JBNbZCE71tEykJS51Do9bWYQuxZ3MH6llhlNOt84Dt/fUQ7 y8FPPnmJezAkl9fOCw4J8Y5xxGSpyFb7/+n49HUtvK7+qYKjjn4mHA2djmoF0tYuxT2R v2wlPDKmj8lL+6KzBZ1MZefA7iC9gvhYrtf7XnOAkhZuG4j6IA9cx527mU5BM5fBj1Ay rh8g== 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=tyItPYr7Q+E1REYtD4gJ9u2mG5VFnbNsWZeMPqfuo1o=; b=RvqVOaDhh7yHP1gUHSZadNQAaZ6+Lm/tRhUcV1dTRLodWOWDIfi0smDh0VoM/J1Ro4 fmG+SOHOPT9Km6clGIE3Dyt8mfS9a9ugSlc9D5DOH036sE1HbncpCliLT2WM9sKX6xM1 7Q43B1qHKk52VDQEhhWyzSckzu5dTobgI8ro0vBBqtTHakuu6g9CIg69C0a1kqkkKHiu 4OxQ9i5FhcgNSObVmFZ1FwuxWQ/j5DVDq9/qvK3YGON3PprVA+RGOEftaS3/AVlPm4wa WAjdQREcY0Bopnyd8nmpZDBDmCGhrgeK/pAaTnc8I3N0rKJWEP/Yj4Nb+VjWClTqci8M VtFg== X-Gm-Message-State: AMCzsaVfo0AI4is4gleOnNh1lYlUx7o1MalWJ9x6JeUAeayIi/Bpd8bJ DidcsQvwD5jYnIpxJsaSwpqw2co+ZZSpe9s3L/km7g== X-Google-Smtp-Source: ABhQp+S9VmpPKn+RMnOS/GcriVBCwD1MDA6/u0WETj8tY2yo667uhRvn1FmdlGmHjk2eYYLUNczo3scOnBRMynij/IA= X-Received: by 10.200.36.50 with SMTP id c47mr13068810qtc.274.1509353832813; Mon, 30 Oct 2017 01:57:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.4.148 with HTTP; Mon, 30 Oct 2017 01:56:52 -0700 (PDT) In-Reply-To: References: From: Renzo Navas Date: Mon, 30 Oct 2017 09:56:52 +0100 Message-ID: To: "ace@ietf.org" Cc: Kepeng Li Content-Type: multipart/alternative; boundary="001a1141025c0b9a30055cbfd3e1" Archived-At: Subject: Re: [Ace] Chairs 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, 30 Oct 2017 08:57:18 -0000 --001a1141025c0b9a30055cbfd3e1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi All, Thank you very much Kepeng and Hannes for your time and effort! Renzo On Sat, Oct 28, 2017 at 1:50 PM, Kepeng Li wrote: > Hello all, > > I would like to take this opportunity to thank all the participants in AC= E > WG to support our work. > > I enjoyed very much with our ACE work, and I learned a lot from the group= . > > I will try my best to assist with a smooth transition with Jim Schaad and > Ben Kaduk. > > I will continue to participate in the mailing list. > > Thank you all! > > Kind Regards > Kepeng > > =E5=9C=A8 28/10/2017, 7:22 PM=EF=BC=8C "Ace on behalf of Kathleen Moriart= y" > =E5= =86=99=E5=85=A5: > > >I would like to thank both Hannes and Kepeng for serving as ACE chairs > >for the last 3+ years. Kepeng is not able to attend the Singapore > >meeting, and while is very interested to continue work in the IETF, he > >doesn't have the support at the moment and thought it was best to > >resign for now. He does hope to continue to participate in the WG. > > > >Hannes is deeply embedded in this space and would like to be a better > >advocate for his position with more flexibility to author drafts as a > >participant. > > > >A big thanks to both of you for your time and leadership moving the > >group to solution work! > > > >Jim Schaad and Ben Kaduk have volunteered as new chairs. Thank you > >both in advance for your work and efforts to drive this important > >working group forward toward meeting it's next set of milestones. > > > >-- > > > >Best regards, > >Kathleen > > > >_______________________________________________ > >Ace mailing list > >Ace@ietf.org > >https://www.ietf.org/mailman/listinfo/ace > > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > --001a1141025c0b9a30055cbfd3e1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi All,

Thank you very much Kepeng and = Hannes for your time and effort!

Renzo
=

On Sat, Oct 28, 2= 017 at 1:50 PM, Kepeng Li <kepeng.lkp@alibaba-inc.com> wrote:
Hello all,

I would like to take this opportunity to thank all the participants in ACE<= br> WG to support our work.

I enjoyed very much with our ACE work, and I learned a lot from the group.<= br>
I will try my best to assist with a smooth transition with Jim Schaad and Ben Kaduk.

I will continue to participate in the mailing list.

Thank you all!

Kind Regards
Kepeng

=E5=9C=A8 28/10/2017, 7:22 PM=EF=BC=8C "Ace on behalf of Kathleen Mori= arty"
<ace-bounces@ietf.org on beh= alf of kathleen.moriart= y.ietf@gmail.com> =E5=86=99=E5=85=A5:

>I would like to thank both Hannes and Kepeng for serving as ACE chairs<= br> >for the last 3+ years.=C2=A0 Kepeng is not able to attend the Singapore=
>meeting, and while is very interested to continue work in the IETF, he<= br> >doesn't have the support at the moment and thought it was best to >resign for now.=C2=A0 He does hope to continue to participate in the WG= .
>
>Hannes is deeply embedded in this space and would like to be a better >advocate for his position with more flexibility to author drafts as a >participant.
>
>A big thanks to both of you for your time and leadership moving the
>group to solution work!
>
>Jim Schaad and Ben Kaduk have volunteered as new chairs.=C2=A0 Thank yo= u
>both in advance for your work and efforts to drive this important
>working group forward toward meeting it's next set of milestones. >
>--
>
>Best regards,
>Kathleen
>
>_______________________________________________
>Ace mailing list
>Ace@ietf.org
>https://www.ietf.org/mailman/listinfo/ace


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

--001a1141025c0b9a30055cbfd3e1-- From nobody Mon Oct 30 01:59:44 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FC4213F8BF for ; Mon, 30 Oct 2017 01:59:43 -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 UaQy7JvKvjr2 for ; Mon, 30 Oct 2017 01:59:41 -0700 (PDT) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05D8413F8BD for ; Mon, 30 Oct 2017 01:59:41 -0700 (PDT) Received: by mail-qk0-x22a.google.com with SMTP id q83so15179558qke.6 for ; Mon, 30 Oct 2017 01:59:40 -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; bh=67uUmR/0BAwgFNZF3+nn9oBU4mLSxdOqbAObl9ieMq0=; b=MYKaoHrArIpI3uLKVd4OTF+SIdMjH/ISrqXFbGVcmUiLPTiw4/ONHoUwAHPVRyPqBY MW24B3clOaqmr8okpkpR5r0rhr6S/o2h/ItU25n55PYLdV6/22FCPO1S79wsqCxjlJtC 92uFlU+ghAgUdlMm3SEVAcw1LbIjYpMtnLoJ7WFfetXqU6eMhiKRx45JmCdahBCgqAAq P/NDcentBCVVs/Tgg3LWduU4lI96I/vENnI3P4eqvJcKJ6/m0u6+sXUZAkgRxzHk5IML EI3uQVVMA/7HEI4U0+cqoaRTZsyCFM1ePp0wv40T4eMEx2HKtLtAT0gJ9sESYa7KAc4d gG+g== 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; bh=67uUmR/0BAwgFNZF3+nn9oBU4mLSxdOqbAObl9ieMq0=; b=uUKwSz7UX1aISY4S1O+6oYgmrQJcZR7+HXlsng0soqLCJ1Prbgnsrx8nDDsHaT6+6B guzC2/qBN2E6n43bUoJpPFir2fjP9+1DJ2722bM7KSsqQRWH/02vp4TjGe7frp09AvPf k0ro+cNnrgWe8SZSKhoiiu+uXlzz5B8FtQl5rQSdKovjfb1h/ylkG0J8NyTVzod45/V2 DhqChzVPA4fmWIcBbaDdFgf0V6mviIqhg/d6InmLIF+btclagmojShMKugUbn8cJLjZy jHxiIQFlJmwRiD+6KlkrxKFkq8I9Uhv9pqSbQamE4k8+Ax2vca5IU3OKVIIIyZcWuB3Q cEcA== X-Gm-Message-State: AMCzsaXGpqr9m87Eb3xndA3R111+8yiLRDOOUmmO3xJTj9xtMj/kIYfu WjEtLQmmT93/0JBc20VYxUF3HdLwaI2YImEyI6pj8nCJ X-Google-Smtp-Source: ABhQp+QB6cw5vvwBABboQDlIVYcpkk5kUkSvG3PVYPagghl1zQ+6dn9hFUzoNj4FDEQh1tSbJDnKkjnklPvXqu1xEPg= X-Received: by 10.55.152.199 with SMTP id a190mr11764803qke.190.1509353979986; Mon, 30 Oct 2017 01:59:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.4.148 with HTTP; Mon, 30 Oct 2017 01:59:19 -0700 (PDT) In-Reply-To: <6317846c-6b1b-5bee-683b-abcc2bedf5c1@ri.se> References: <6317846c-6b1b-5bee-683b-abcc2bedf5c1@ri.se> From: Renzo Navas Date: Mon, 30 Oct 2017 09:59:19 +0100 Message-ID: To: ace Content-Type: multipart/alternative; boundary="94eb2c07e710d147b2055cbfdbc1" Archived-At: Subject: Re: [Ace] Call for adoption of draft-seitz-ace-oscoap-profile 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, 30 Oct 2017 08:59:43 -0000 --94eb2c07e710d147b2055cbfdbc1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I suport draft-seitz-ace-oscoap-profile for WG adoption saludos, Renzo On Sat, Oct 28, 2017 at 2:15 PM, Marco Tiloca wrote: > I support the adoption of the OSCOAP profile of ACE. > > Best, > /Marco > > > On 2017-10-23 15:17, Kepeng Li wrote: > > Hello all, > > > > According to our virtual interim meeting minutes[1], we have clear > supports to adopt the OSCOAP profile draft [2] during the meeting. > > > > This note is asking for confirmation of this tentative adoption decision > on the mailing list. Please speak up before 7th Nov, 2017 if you would > like to register your opinion on the adoption question. > > Keep in mind that adoption of a document does not mean the document as-is= is ready for publication. It is merely acceptance of the document as a sta= rting point for what will be the final product of the ACE working group. Th= e working group is free to make changes to the document according to the no= rmal consensus process. > > > > Please reply on this thread with expressions of support or opposition, pr= eferably with comments, regarding accepting this as a work item. > > > > Thanks > > > > Kind Regards > > Kepeng and Hannes (ACE co-chairs) > > > [1] https://datatracker.ietf.org/meeting/interim-2017-ace- > 02/materials/minutes-interim-2017-ace-02-201710181300/ > > [2] https://datatracker.ietf.org/doc/draft-seitz-ace-oscoap-profile/ > > > > _______________________________________________ > Ace mailing listAce@ietf.orghttps://www.ietf.org/mailman/listinfo/ace > > > -- > Marco Tiloca, PhD > Research Institutes of Sweden > RISE ICT/SICS > Isafjordsgatan 22 / Kistag=C3=A5ngen 16 > SE-164 40 Kista (Sweden) > Phone: +46 (0)70 60 46 501https://www.sics.sehttps://www.sics.se/~marco/ > > The RISE institutes Innventia, SP and Swedish ICT > have merged in order to become a stronger research > and innovation partner for businesses and society. > > SICS Swedish ICT AB, has now changed name to RISE SICS AB. > > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > > --94eb2c07e710d147b2055cbfdbc1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I suport=C2=A0=C2=A0draft-seitz-ace-oscoap-profile for WG = adoption

saludos,

Renzo

On Sat, Oct 2= 8, 2017 at 2:15 PM, Marco Tiloca <marco.tiloca@ri.se> wrote= :
=20 =20 =20
I support the adoption of the OSCOAP profile of ACE.

Best,
/Marco


On 2017-10-23 15:17= , Kepeng Li wrote:
=20
Hello all,
=C2=A0

According to our virtual interim meeting minutes[1], we have clear supports to=C2=A0adopt the OSCOAP profile draft [= 2] during the meeting. =C2=A0

=C2=A0

This note is asking for confirmation of this tentative adoption decision on the mailing list.=C2=A0 Please spe= ak up before 7th Nov, 2017 if you would like to register your opinion on the adoption question.<= /p> 


Keep in mind that adoption of a do=
cument does not mean the document as-is is ready for publication. It is mer=
ely acceptance of the document as a starting point for what will be the fin=
al product of the ACE working group. The working group is free to make chan=
ges to the document according to the normal consensus process.
=C2=A0
Please reply on this thread with e=
xpressions of support or opposition, preferably with comments, regarding ac=
cepting this as a work item.

=C2=A0

Thanks
=C2=A0
Kind Regards
Kepeng and Hannes (ACE co-chairs)
 




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


--=20
Marco Tiloca, PhD
Research Institutes of Sweden
RISE ICT/SICS
Isafjordsgatan 22 / Kistag=C3=A5ngen 16
SE-164 40 Kista (Sweden)
Phone: +46 (0)70 60 46 501
https://www.sics.se
https://www.sics.se/~marco/

The RISE institutes Innventia, SP and Swedish ICT
have merged in order to become a stronger research
and innovation partner for businesses and society.

SICS Swedish ICT AB, has now changed name to RISE SICS AB.

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


--94eb2c07e710d147b2055cbfdbc1-- From nobody Mon Oct 30 02:06:44 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E15D013F8E4 for ; Mon, 30 Oct 2017 02:06:42 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 NqR6nV2ZKI8b for ; Mon, 30 Oct 2017 02:06:40 -0700 (PDT) Received: from mail-pf0-x234.google.com (mail-pf0-x234.google.com [IPv6:2607:f8b0:400e:c00::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD7BB13F8E3 for ; Mon, 30 Oct 2017 02:06:40 -0700 (PDT) Received: by mail-pf0-x234.google.com with SMTP id x7so10501915pfa.1 for ; Mon, 30 Oct 2017 02:06:40 -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=ltWB01ipU2jf6wy28jgXZGRRCL52hRFybN5cFwqJDc8=; b=GqvKCOygUjTj6X/LUCxOYvQTq4S7QO9CoZ44E01ZTQpDsxIwsZuTCoYmBfdlS7XShi sjpZAhCqSyLyEFBZM8GGXe5OJQdUOB+26F8EDs4YVTE6tDfSIjgSGh0QWirbWeay5/Nv GrPeBFjFrE5hq58tHSsIPE3Wg0OU6U9lsZDwzU03QXqwlHnM/9lq6z7/ADYNxi9/xwsK giLlDHYcaBmx5AuAD2wGDPm0DXSPzIhaANTb76WcRhnLLEw2BvLX3rtrPTab3VU5NN1O 25ioWXZ1pZL/qkAJrjUeBbNeqrt2DnSHy2+AeAtPWDOp9qvvNI6PDO2lRX2EAsPDwnrj R+Rw== 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=ltWB01ipU2jf6wy28jgXZGRRCL52hRFybN5cFwqJDc8=; b=pNY5SXsjqXCnKJKg7Tu8vdzqZHh4aHuhulBmOL/kmt0k95on4B4ZPMKsGYYF1/cfD0 tbVApleKCQQlEomEZdUF/v13sRnZbLay3L2IW5ph9QFpr90f8KU0ayuDQNPprdwRvhMm KWZiiQn7ynx5uCQQUS545A8j2U4iy6XGOLzig+zRucAtS5kYvSpgvUrazqc6lK7A3JYZ oVFTWkE0rcbqBC+nBqjtOdK8om6pOYW2xtTZ//L1SnzqvnPC/EKAr0PBNs9f2DzyiHf2 Sa8o7wEXX9SepDxS3blZNUfYL9eLLHxFBk79qXx403GfdSjTR6GgcLoB6H+qDuhNlVz+ JJPA== X-Gm-Message-State: AMCzsaW00wUqJPWFgKc9qetm6eUU19lF+ZVy2T4WL7ONLJEOI9ZORpj8 RWTmQR9T4oQCXRaUL/816SiJes9jCLReqoqBH9CVtwEB X-Google-Smtp-Source: ABhQp+Q1nVdvnpbwmsjRrE2hEk9IzemODShsBJIaih58dlOUVCwlsg7i9Q13+Ibhqk84LH9QuxuUdvLKa9EibvQk1fg= X-Received: by 10.98.86.81 with SMTP id k78mr8075966pfb.58.1509354400225; Mon, 30 Oct 2017 02:06:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.186.199 with HTTP; Mon, 30 Oct 2017 02:06:39 -0700 (PDT) In-Reply-To: References: From: Samuel Erdtman Date: Mon, 30 Oct 2017 10:06:39 +0100 Message-ID: To: Kepeng Li Cc: ace , Kathleen Moriarty , "Hannes.Tschofenig@gmx.net" Content-Type: multipart/alternative; boundary="001a1147e1b4ddb2e2055cbff43b" Archived-At: Subject: Re: [Ace] Call for adoption of draft-seitz-ace-oscoap-profile 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, 30 Oct 2017 09:06:43 -0000 --001a1147e1b4ddb2e2055cbff43b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I support adoption. On Mon, Oct 23, 2017 at 3:17 PM, Kepeng Li wrote: > Hello all, > > > > According to our virtual interim meeting minutes[1], we have clear > supports to adopt the OSCOAP profile draft [2] during the meeting. > > > > This note is asking for confirmation of this tentative adoption decision > on the mailing list. Please speak up before 7th Nov, 2017 if you would > like to register your opinion on the adoption question. > > Keep in mind that adoption of a document does not mean the document as-is= is ready for publication. It is merely acceptance of the document as a sta= rting point for what will be the final product of the ACE working group. Th= e working group is free to make changes to the document according to the no= rmal consensus process. > > > > Please reply on this thread with expressions of support or opposition, pr= eferably with comments, regarding accepting this as a work item. > > > > Thanks > > > > Kind Regards > > Kepeng and Hannes (ACE co-chairs) > > > [1] https://datatracker.ietf.org/meeting/interim-2017-ace- > 02/materials/minutes-interim-2017-ace-02-201710181300/ > > [2] https://datatracker.ietf.org/doc/draft-seitz-ace-oscoap-profile/ > > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > > --001a1147e1b4ddb2e2055cbff43b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I support adoption.
On Mon, Oct 23, 2017 at 3:17 PM, Kepeng Li <kepeng.lkp@alibaba-inc.com> wrote:
<= font style=3D"font-size:16px" face=3D"Courier">Hello all,
= 
=C2=A0

According to our virtual= interim meeting minutes[1], we have clear supports to=C2=A0adopt the OSCOA= P profile draft [2] during the meeting. =C2=A0

=C2=A0

This note is asking for confirmation of this tentative adoption decisio= n on the mailing list.=C2=A0 Please speak up before 7th Nov, 2017 if you wo= uld like to register your opinion on the adoption question.


Keep in mind that adoption of a document=
 does not mean the document as-is is ready for publication. It is merely ac=
ceptance of the document as a starting point for what will be the final pro=
duct of the ACE working group. The working group is free to make changes to=
 the document according to the normal consensus process.
=C2=A0
Please reply on this thread with ex=
pressions of support or opposition, preferably with comments, regarding acc=
epting this as a work item.

=C2=A0

<=
font>Thanks
=C2=A0
Kind Regards
Kepeng and Hannes (ACE co-chairs)



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


--001a1147e1b4ddb2e2055cbff43b-- From nobody Mon Oct 30 03:31:33 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40A3C13F8F6 for ; Mon, 30 Oct 2017 03:31:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vuV6K5DWFeOz for ; Mon, 30 Oct 2017 03:31:30 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0056.outbound.protection.outlook.com [104.47.1.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD78F13F6FC for ; Mon, 30 Oct 2017 03:31:29 -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=FUQZCivTzBBoNOESJ2qhQihf4RKdgq87iNVCz/6CTr0=; b=rlSu37nzi5Z4m6mVMInZKJvZ4Z92zZ/ozWkoaQfWUAaHhUcNDDjOYeLCkszN3kxsp6xhO9knJw5z+sapFoePqBe6n7S1y7jVTk9GGI9i2gvWlMimR7wxLjv1qUbYMTG+L5LtTOJBvTyl16I0CzpoZHE3lxxC0KhzOaT3GHuz48Q= Received: from AM4PR0801MB2706.eurprd08.prod.outlook.com (10.167.90.148) by AM4PR0801MB2708.eurprd08.prod.outlook.com (10.167.90.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.178.6; Mon, 30 Oct 2017 10:31:27 +0000 Received: from AM4PR0801MB2706.eurprd08.prod.outlook.com ([fe80::403b:850e:c32c:fad6]) by AM4PR0801MB2706.eurprd08.prod.outlook.com ([fe80::403b:850e:c32c:fad6%13]) with mapi id 15.20.0178.012; Mon, 30 Oct 2017 10:31:26 +0000 From: Hannes Tschofenig To: Kepeng Li , Kathleen Moriarty , "ace@ietf.org" Thread-Topic: [Ace] Chairs Thread-Index: AQHTT98xSfWVe6blRkCwltIciqhzD6L5JiUAgAHCiAA= Date: Mon, 30 Oct 2017 10:31:26 +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: [81.18.200.28] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM4PR0801MB2708; 6:+XKkPLgh6PHZlYjRfU97ZiViMNlOEtDemrcLni7csdocPVIemjUmOaNxy6FKvZinpjgjdixe1uFgpjPeytU53txMPL4mppnup2ZsFTcT9TWyiF5ch++LMGGyNgCH+3Rhj1xhyhf1Vi1rEQaFfIuk1pnJoshn8lh3WFQkfnu7sfLX+1yTDmiaEd53/dRa1dnKbbgLNPWFKNYJrLZEcIvGjlv0gMK8q/Bq6FA8H++XLKS/yU3iYmbPtqWsIgFY2h3f6t/8LA3oYTwRnbqqboDfcRdUH3SbI+cJ7r3C3D/1v0Q+2y6CudT9PWbT2hlSOomvN3yfJDrpjhTgWX0ANSv+U/tAyVsHxAhJqyQU/K4WTqQ=; 5:1WIXxRowpw3zhc2XY82C9VGxxDSV8aGpRYjgwStDeP6fq6r+hXgllXTyxzlcCIDU+gENGQ9DQ44iufjnJmcY7uqSVkMdiwk9mxiSpsp//+5L+fOMOWcyzuQdYaPcirbFhk8QQlFXpnB7DbQaftfkLJzcvmSKGwidT7Ryb6K3UQE=; 24:CHAZXjzgNZz8zakWMWagJssynYhiD0cxWAM8qUp376RjXJCiBwVv5sgzToIeC2dD6ebYBtpeWpch4UP71oAr+vcmx40+TMJ+R+5maps46m8=; 7:3nusdoevqOFsGX90sfTjHJY5CMJ6mVwwSuynTeF0Xl9q5KKceXThVwEbLOmNVT5gze4qXvuAU+RbpPQPRAwG9HNTlRb+O317f9POiW59qPzswdYhO36pqwv+AnfgCVby17JeL1T6Yf7TrIC5joRBCrTNHO4fZdJ/wr+0b5ODpuCjhP4mEjzrJBtykhNexQOU2eQhIQ+xS0ubmgk/bIzDT3yXS369Zzhkh8Q+EAsmQKiOAhNUdDV5xc0IDSBL+XHW x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: cb678135-cee6-405f-a2db-08d51f81604d x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081)(4534020)(4602075)(2017052603199); SRVR:AM4PR0801MB2708; x-ms-traffictypediagnostic: AM4PR0801MB2708: x-exchange-antispam-report-test: UriScan:; x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(100000703101)(100105400095)(3002001)(3231020)(10201501046)(93006095)(93001095)(6055026)(6041248)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123558100)(20161123555025)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM4PR0801MB2708; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM4PR0801MB2708; x-forefront-prvs: 0476D4AB88 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(346002)(376002)(39860400002)(189002)(40434004)(13464003)(53754006)(199003)(6306002)(5890100001)(316002)(9686003)(305945005)(2906002)(81166006)(14454004)(478600001)(33656002)(3280700002)(966005)(2900100001)(55016002)(99286003)(53936002)(6246003)(54356999)(6116002)(81156014)(102836003)(72206003)(7736002)(68736007)(39060400002)(76176999)(97736004)(50986999)(8676002)(86362001)(53546010)(110136005)(6506006)(25786009)(189998001)(2501003)(3846002)(229853002)(105586002)(6436002)(8936002)(74316002)(5250100002)(106356001)(101416001)(66066001)(3660700001)(5660300001)(7696004)(2950100002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR0801MB2708; H:AM4PR0801MB2706.eurprd08.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: cb678135-cee6-405f-a2db-08d51f81604d X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Oct 2017 10:31:26.8954 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR0801MB2708 Archived-At: Subject: Re: [Ace] Chairs 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, 30 Oct 2017 10:31:32 -0000 It was a pleasure to work with you, Kepeng. Ciao Hannes -----Original Message----- From: Ace [mailto:ace-bounces@ietf.org] On Behalf Of Kepeng Li Sent: 28 October 2017 13:50 To: Kathleen Moriarty; ace@ietf.org Subject: Re: [Ace] Chairs Hello all, I would like to take this opportunity to thank all the participants in ACE = WG to support our work. I enjoyed very much with our ACE work, and I learned a lot from the group. I will try my best to assist with a smooth transition with Jim Schaad and B= en Kaduk. I will continue to participate in the mailing list. Thank you all! Kind Regards Kepeng =1B$B:_=1B(B 28/10/2017, 7:22 PM=1B$B!$=1B(B "Ace on behalf of Kathleen Mor= iarty" =1B$B<= LF~=1B(B: >I would like to thank both Hannes and Kepeng for serving as ACE chairs >for the last 3+ years. Kepeng is not able to attend the Singapore >meeting, and while is very interested to continue work in the IETF, he >doesn't have the support at the moment and thought it was best to >resign for now. He does hope to continue to participate in the WG. > >Hannes is deeply embedded in this space and would like to be a better >advocate for his position with more flexibility to author drafts as a >participant. > >A big thanks to both of you for your time and leadership moving the >group to solution work! > >Jim Schaad and Ben Kaduk have volunteered as new chairs. Thank you >both in advance for your work and efforts to drive this important >working group forward toward meeting it's next set of milestones. > >-- > >Best regards, >Kathleen > >_______________________________________________ >Ace mailing list >Ace@ietf.org >https://www.ietf.org/mailman/listinfo/ace _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. From nobody Mon Oct 30 05:16:36 2017 Return-Path: X-Original-To: ace@ietf.org Delivered-To: ace@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 84B4513F7B6; Mon, 30 Oct 2017 05:16:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: internet-drafts@ietf.org To: Cc: ace@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.63.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150936579552.3519.11764172381950185199@ietfa.amsl.com> Date: Mon, 30 Oct 2017 05:16:35 -0700 Archived-At: Subject: [Ace] I-D Action: draft-ietf-ace-dtls-authorize-02.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, 30 Oct 2017 12:16:35 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Authentication and Authorization for Constrained Environments WG of the IETF. Title : Datagram Transport Layer Security (DTLS) Profiles for Authentication and Authorization for Constrained Environments (ACE) Authors : Stefanie Gerdes Olaf Bergmann Carsten Bormann Göran Selander Ludwig Seitz Filename : draft-ietf-ace-dtls-authorize-02.txt Pages : 17 Date : 2017-10-30 Abstract: This specification defines two profiles for delegating client authentication and authorization in a constrained environment by establishing a Datagram Transport Layer Security (DTLS) channel between resource-constrained nodes. The protocol relies on DTLS for communication security between entities in a constrained network using either raw public keys or pre-shared keys. A resource- constrained node can use this protocol to delegate management of authorization information to a trusted host with less severe limitations regarding processing power and memory. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ace-dtls-authorize/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ace-dtls-authorize-02 https://datatracker.ietf.org/doc/html/draft-ietf-ace-dtls-authorize-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-dtls-authorize-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 30 05:30:00 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AF67139F5C for ; Mon, 30 Oct 2017 05:29:58 -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 LJmQhf51SBVr for ; Mon, 30 Oct 2017 05:29:55 -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 CFDD713AC0D for ; Mon, 30 Oct 2017 05:29:54 -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 v9UCTo9b010420 for ; Mon, 30 Oct 2017 13:29:50 +0100 (CET) Received: from wangari.tzi.org (p508A45B4.dip0.t-ipconnect.de [80.138.69.180]) (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 3yQYhZ4BgYzDXtS for ; Mon, 30 Oct 2017 13:29:50 +0100 (CET) From: Olaf Bergmann To: ace@ietf.org References: <150936579552.3519.11764172381950185199@ietfa.amsl.com> Date: Mon, 30 Oct 2017 13:29:50 +0100 In-Reply-To: <150936579552.3519.11764172381950185199@ietfa.amsl.com> (internet-drafts@ietf.org's message of "Mon, 30 Oct 2017 05:16:35 -0700") Message-ID: <87wp3csts1.fsf@tzi.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Ace] I-D Action: draft-ietf-ace-dtls-authorize-02.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 12:29:58 -0000 Dear all, we have just updated the coap_dtls profile draft, addressing the open issues from the GH issue tracker [1] and (most of) Hannes's review [2]. [1] https://github.com/ace-wg/ace-dtls-profile/issues [2] https://mailarchive.ietf.org/arch/search/?email_list=3Dace&gbt=3D1&inde= x=3DUaXs9ynTiB7hQY8u9BWuZ29LcOI Gr=C3=BC=C3=9Fe Olaf internet-drafts@ietf.org writes: > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Authentication and Authorization for Con= strained Environments WG of the IETF. > > Title : Datagram Transport Layer Security (DTLS) Profil= es for Authentication and Authorization for Constrained Environments (ACE) > Authors : Stefanie Gerdes > Olaf Bergmann > Carsten Bormann > G=C3=B6ran Selander > Ludwig Seitz > Filename : draft-ietf-ace-dtls-authorize-02.txt > Pages : 17 > Date : 2017-10-30 > > Abstract: > This specification defines two profiles for delegating client > authentication and authorization in a constrained environment by > establishing a Datagram Transport Layer Security (DTLS) channel > between resource-constrained nodes. The protocol relies on DTLS for > communication security between entities in a constrained network > using either raw public keys or pre-shared keys. A resource- > constrained node can use this protocol to delegate management of > authorization information to a trusted host with less severe > limitations regarding processing power and memory. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-ace-dtls-authorize/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-ace-dtls-authorize-02 > https://datatracker.ietf.org/doc/html/draft-ietf-ace-dtls-authorize-02 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ace-dtls-authorize-02 > > > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > > From nobody Mon Oct 30 13:02:46 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4420B13FB39 for ; Mon, 30 Oct 2017 13:02:41 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 rZQC2rcfdjUM for ; Mon, 30 Oct 2017 13:02:38 -0700 (PDT) Received: from mail-pg0-x231.google.com (mail-pg0-x231.google.com [IPv6:2607:f8b0:400e:c05::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 A813313FB3C for ; Mon, 30 Oct 2017 13:02:38 -0700 (PDT) Received: by mail-pg0-x231.google.com with SMTP id p9so12576125pgc.8 for ; Mon, 30 Oct 2017 13:02:38 -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; bh=A+9X6cqX9+tpHNO+UxXUhUdvLHHkw3+fOGP3rhk36sY=; b=meZjDqZKpslTV6r6QUJbHikt9ROlEkql6fACUQnKTz0vOr+/wot5nO4RNt9VbsOjxN oMudf5rOJhslOSo9uGuBH5vkZKP4/gZAHeRIuyrKYIcLvJVaCawT6Kfuv/kG6S2yoymj 9ZjA7xjEF8UExZSAcDTiPoG3aqbyxGll+ouXAK5NnYP1qxOAcGpHzDtp74iYS+cFrrtE GTxZFBbWlDVlx11S2IeUuHHob+wuIYrxJFdnY8aJIxi6dQbx539O/m2eDdVwsC1JWz+v s7Phnw9Qu5MMzQES1+P5GPZP9PoUSJ/wGAvlk8b8ZuQbrolFmXdjzZPxsV9UU2ACWXjF lTpA== 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; bh=A+9X6cqX9+tpHNO+UxXUhUdvLHHkw3+fOGP3rhk36sY=; b=XMyp/Fc/mEAFDiwuIL3r/CP6M1Ik3WRYNH39q6WmHJ5IneM7YxOFTl6gcXlce0qmkv jNzVIrIzjqX8sXi9isJKk0+bX6SwZEFcAO9dLPiG1UjKLRE3eDb/cBTjJhBoTY5XVE0R Ys1dnp2Mqk18mhTl10LxOZ7yIDPuN9Q11ALVgKUfHkd4/KiPaUp0NwH5bjdM2GMrR+OR UAPvY1gMHgHS70zQ5JcrFAIOZtmLddtBQ6JnQe4kuhOeu1uURzHwbywmU9Nn2bGz/SZ6 EZJvn2e1B9DuE3/itrdbCKQAeaFpR4m2T9E1omoTet22vjL9odwKtiSU39RZpqI3973w +T+A== X-Gm-Message-State: AMCzsaU+rHO64785rt6Vhk+wKkTwvS3M8Y46Ph71k2y1AzfxGd3YqyBy uj0hf+fqfvn83B6hWrpABO+4hRteJh8BBuGWSsZ2kg== X-Google-Smtp-Source: ABhQp+QcBLYHFjefvU0P33ejUiM3+HjChhkGhyrQhsQQ5gP4YEuP5AqCQJaLgFArckwA2xxibYc0K2r1jxfujAtUhls= X-Received: by 10.159.214.149 with SMTP id n21mr8459206plp.336.1509393757879; Mon, 30 Oct 2017 13:02:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.186.199 with HTTP; Mon, 30 Oct 2017 13:02:37 -0700 (PDT) In-Reply-To: References: <150939333261.7744.6308016285582758380.idtracker@ietfa.amsl.com> From: Samuel Erdtman Date: Mon, 30 Oct 2017 21:02:37 +0100 Message-ID: To: "" , ace Content-Type: multipart/alternative; boundary="94eb2c1dc038c3d62c055cc91ecb" Archived-At: Subject: [Ace] Fwd: New Version Notification for draft-erdtman-ace-rpcc-02.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 20:02:41 -0000 --94eb2c1dc038c3d62c055cc91ecb Content-Type: text/plain; charset="UTF-8" We have published a new version of the draft-erdtman-ace-rpcc * Addresses review comments form Brian Campbell (thank you Brian). * Adds language about dynamic registration. Thoughts, comments? ---------- Forwarded message --------- From: Date: Mon, 30 Oct 2017 at 20:55 Subject: New Version Notification for draft-erdtman-ace-rpcc-02.txt To: Ludwig Seitz , Samuel Erdtman A new version of I-D, draft-erdtman-ace-rpcc-02.txt has been successfully submitted by Samuel Erdtman and posted to the IETF repository. Name: draft-erdtman-ace-rpcc Revision: 02 Title: Raw-Public-Key and Pre-Shared-Key as OAuth client credentials Document date: 2017-10-30 Group: Individual Submission Pages: 7 URL: https://www.ietf.org/internet-drafts/draft-erdtman-ace-rpcc- 02.txt Status: https://datatracker.ietf.org/doc/draft-erdtman-ace-rpcc/ Htmlized: https://tools.ietf.org/html/draft-erdtman-ace-rpcc-02 Htmlized: https://datatracker.ietf.org/doc/html/draft-erdtman-ace- rpcc-02 Diff: https://www.ietf.org/rfcdiff?url2=draft-erdtman-ace-rpcc-02 Abstract: This document describes Transport Layer Security (TLS) authentication using Raw-Public-Key and Pre-Shared-Key as new mechanisms for OAuth client authentication. Although defined for TLS the mechanisms are equally applicable for DTLS. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --94eb2c1dc038c3d62c055cc91ecb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
We have published a new version of the draf= t-erdtman-ace-rpcc

* Addresses review comments form Brian Camp= bell (thank you Brian).
* Adds language about dynamic registration= .

Thoughts, comments?


---------- Forwarded= message ---------
From: <internet-drafts@ietf.org>
Date: Mon, 30 Oct 2= 017 at 20:55
Subject: New Version Notification for draft-erdtman-ace-rpc= c-02.txt
To: Ludwig Seitz <ludwig.seitz@ri.se>, Samuel Erdtman <erdtman@spotify.com>
<= /div>


A new version of I-D, draft-erdtman-ace-rpcc-02.txt
has been successfully submitted by Samuel Erdtman and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-erdtman-ace-rpcc
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A002
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Raw-Public-Key and Pre-Shared-Key = as OAuth client credentials
Document date:=C2=A0 2017-10-30
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 7
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-erdtman-ace-rpc= c-02.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0htt= ps://datatracker.ietf.org/doc/draft-erdtman-ace-rpcc/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://too= ls.ietf.org/html/draft-erdtman-ace-rpcc-02
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0h= ttps://datatracker.ietf.org/doc/html/draft-erdtman-ace-rpcc-02
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-erdtman-ace-rpcc-02

Abstract:
=C2=A0 =C2=A0This document describes Transport Layer Security (TLS) authent= ication
=C2=A0 =C2=A0using Raw-Public-Key and Pre-Shared-Key as new mechanisms for = OAuth
=C2=A0 =C2=A0client authentication.=C2=A0 Although defined for TLS the mech= anisms are
=C2=A0 =C2=A0equally applicable for DTLS.




Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


--94eb2c1dc038c3d62c055cc91ecb-- From nobody Mon Oct 30 16:51:09 2017 Return-Path: X-Original-To: ace@ietf.org Delivered-To: ace@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C19DCD65; Mon, 30 Oct 2017 16:51:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: internet-drafts@ietf.org To: Cc: ace@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.63.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150940746726.28271.14614921944014707717@ietfa.amsl.com> Date: Mon, 30 Oct 2017 16:51:07 -0700 Archived-At: Subject: [Ace] I-D Action: draft-ietf-ace-cwt-proof-of-possession-01.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, 30 Oct 2017 23:51:07 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Authentication and Authorization for Constrained Environments WG of the IETF. Title : Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs) Authors : Michael B. Jones Ludwig Seitz Göran Selander Erik Wahlström Samuel Erdtman Hannes Tschofenig Filename : draft-ietf-ace-cwt-proof-of-possession-01.txt Pages : 14 Date : 2017-10-30 Abstract: This specification describes how to declare in a CBOR Web Token (CWT) that the presenter of the CWT possesses a particular proof-of- possession key. Being able to prove possession of a key is also sometimes described as being the holder-of-key. This specification provides equivalent functionality to "Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)" (RFC 7800), but using CBOR and CWTs rather than JSON and JWTs. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ace-cwt-proof-of-possession/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ace-cwt-proof-of-possession-01 https://datatracker.ietf.org/doc/html/draft-ietf-ace-cwt-proof-of-possession-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-cwt-proof-of-possession-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 30 18:01:40 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ABE513F631 for ; Mon, 30 Oct 2017 18:01:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rl6evKXvCnvN for ; Mon, 30 Oct 2017 18:01:36 -0700 (PDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0134.outbound.protection.outlook.com [104.47.40.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CB3213F476 for ; Mon, 30 Oct 2017 18:01:36 -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=kZAjU+FjNs8avghTptOklA7g5z0ZMUO/GRlVJTEsJFg=; b=keHO8VmZSVY2TI4/ZEYBQcPGlm5yVnc42XpVITjz2m4wphKCgQZhl+cB/ulTNIk85XfAKRDwKjMDOUdl39LOLD9DNLlA+vXJfqET6qEvc4AIFsY9cT85jUaogJxllwIOE6uQeb3rI+YEuFuj2MxpJ6omnt63VPdQJCY6bTjpBgg= Received: from CY4PR21MB0504.namprd21.prod.outlook.com (10.172.122.14) by CY4PR21MB0133.namprd21.prod.outlook.com (10.173.189.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.218.2; Tue, 31 Oct 2017 01:01:34 +0000 Received: from CY4PR21MB0504.namprd21.prod.outlook.com ([10.172.122.14]) by CY4PR21MB0504.namprd21.prod.outlook.com ([10.172.122.14]) with mapi id 15.20.0218.002; Tue, 31 Oct 2017 01:01:34 +0000 From: Mike Jones To: "ace@ietf.org" CC: Ludwig Seitz , Samuel Erdtman , "Jim Schaad" Thread-Topic: Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs) spec using CBOR diagnostic notation Thread-Index: AdNR4CvFaSMdextDRMCYBHD4NxPCtg== Date: Tue, 31 Oct 2017 01:01:34 +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=2017-10-31T01:01:32.6426725Z; 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::36] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR21MB0133; 6:ce+fc2JdV4D4blZJgL8F/n8v+jlb6M/dE5jqKLQx+W75lf9cqVQd7QfqFExX52dppw/X1LBRSjABcTF27csRxPUDeXMCQ0UvH3O4ickGCS1+bfX9fuePiToPHSBj9B46lqBks0b5aOaTNJgJXTdGAa5uK/vyB9AyV843xb/YdCFEfiRxLxrO5xR85tyRLS8w0ntl64EVM5MYxK4h+1fykAvmnZ6eOhxTDuFVzB9abUc4yoqBlsklRpow3BOdpwb+U5NvJmrFWLXxm0Dw807wt6Hfh64ZC+g+ZHW9btIS68K6uSjHtL2sff6bBt5joLeuXHZajGDDIHiyUbRPunHqlsYku7c+xAJskhJic/75gqQ=; 5:Jp+bQI5en7EHGYQjfmqAwUf9mxBifnIQVBnbr5U8jlEfVv0e6d0I0QdnrUWudqmoj52iCWEAQyZUXV8XbBdE7xAC+KHRWo4TBbr/21NQmyGRravQu4AAWDo540VT0E5o8hqHJxU0/oCvTG3Ifyu8D3JGetqdmms9dXrg5mRC4Ys=; 24:by5neLoFRjuAFD75v63o74BDH1Z2WxV3aJJ9GvOBYtjGXSuBzStAUWoDKu4JTBzu1cz92uzuiYmPfv2EWHksI5KKphoi3OL3rQO+PwVWbK4=; 7:MzoeKfuNHN7G7NMUyDsSSpahb7NrMjBn07TLe8RlUaUJbP3JxnUXKYLukcapquDVrsa///6JFbsdtSwv5cydbT2VHvVxSM2kQju9YKcVYbliw2uMYWkc8+JRZn4GOjvPIHTCkHi/Nz05XegmJfgDnfHisTToS6oFnTB0QNr2iGWzaKu0oNblfqFHyAW4uKHl/gIJN8j6Jyf98sXFDcU+6wDYGNoGcM9pT33HoHE4x1REyHBOiWTTcDU+qK2gA6C+ x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: c1dfbbd2-b3fa-4d37-a147-08d51ffaee59 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081)(4534020)(4602075)(2017052603238); SRVR:CY4PR21MB0133; x-ms-traffictypediagnostic: CY4PR21MB0133: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-exchange-antispam-report-test: UriScan:(31418570063057)(21748063052155); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(100000703101)(100105400095)(3231020)(10201501046)(3002001)(6055026)(61426038)(61427038)(6041248)(20161123560025)(20161123558100)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123562025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR21MB0133; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR21MB0133; x-forefront-prvs: 04772EA191 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(346002)(39860400002)(209900001)(47760400005)(189002)(199003)(10290500003)(10090500001)(6306002)(54896002)(790700001)(102836003)(55016002)(53936002)(6116002)(5630700001)(7736002)(2351001)(236005)(33656002)(68736007)(105586002)(81156014)(106356001)(81166006)(8676002)(1730700003)(8936002)(8990500004)(50986999)(54356999)(189998001)(2900100001)(74316002)(316002)(99286003)(9686003)(230783001)(101416001)(22452003)(3660700001)(5660300001)(72206003)(3280700002)(966005)(478600001)(6506006)(5640700003)(77096006)(2906002)(14454004)(97736004)(2501003)(54906003)(4326008)(86612001)(7696004)(6436002)(25786009)(53376002)(86362001)(606006)(6916009)(6606295002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0133; H:CY4PR21MB0504.namprd21.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR21MB0504ECD63EB603A5DAA0AC50F55E0CY4PR21MB0504namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: c1dfbbd2-b3fa-4d37-a147-08d51ffaee59 X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Oct 2017 01:01:34.3148 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0133 Archived-At: Subject: [Ace] Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs) spec using CBOR diagnostic notation 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, 31 Oct 2017 01:01:38 -0000 --_000_CY4PR21MB0504ECD63EB603A5DAA0AC50F55E0CY4PR21MB0504namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Draft -01 of the Proof-of-Possession Key Semantics for CBOR Web Tokens (CWT= s) specification updates the examples to use CBOR diagnostic notation, than= ks to Ludwig Seitz. A table summarizing the "cnf" names, keys, and value t= ypes was added, thanks to Samuel Erdtman. Finally, some of Jim Schaad's fe= edback on -00 was addressed (with more to be addressed by the opening of IE= TF 100 in Singapore). The specification is available at: * https://tools.ietf.org/html/draft-ietf-ace-cwt-proof-of-possession-01 An HTML-formatted version is also available at: * http://self-issued.info/docs/draft-ietf-ace-cwt-proof-of-possession-0= 1.html -- Mike P.S. This notice was also posted at http://self-issued.info/?p=3D1748 and = as @selfissued. --_000_CY4PR21MB0504ECD63EB603A5DAA0AC50F55E0CY4PR21MB0504namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Draft -01 of the Proof-of-Possession Key Semantics f= or CBOR Web Tokens (CWTs) specification updates the examples to use CBOR di= agnostic notation, thanks to Ludwig Seitz.  A table summarizing the &#= 8220;cnf” names, keys, and value types was added, thanks to Samuel Erdtman.  Finally, some of Jim Schaad’s feedba= ck on -00 was addressed (with more to be addressed by the opening of IETF 100 in Singapore).

 

The specification is available at:

 

An HTML-formatted version is also available at:=

 

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

 

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

 

--_000_CY4PR21MB0504ECD63EB603A5DAA0AC50F55E0CY4PR21MB0504namp_-- From nobody Tue Oct 31 02:27:37 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A081113F708 for ; Tue, 31 Oct 2017 02:27:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yM-O651VNMrM for ; Tue, 31 Oct 2017 02:27:32 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0075.outbound.protection.outlook.com [104.47.2.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B80E13F3FE for ; Tue, 31 Oct 2017 02:27:32 -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=bnNiDIIaxnq8QdGqr95ZrEgFzESRzLOZTg5nGasqswE=; b=GS7rFH/sF2cIcR83oifWMneo7ndmX1QQgCsXW0rMniF6CZDK7LHIFSwwZLSN4XUBgCrwJzyegaKscc7q3JHONaQZU5K6mT6Onj5RY1JSSDq9AoFYcNjTT+fuEg+CgS36a1gwi344lNl+dJRzBqFhG41v1sV9hBMxjCoTWkgzXD0= Received: from AM4PR0801MB2706.eurprd08.prod.outlook.com (10.167.90.148) by AM4PR0801MB2707.eurprd08.prod.outlook.com (10.167.90.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.178.6; Tue, 31 Oct 2017 09:27:29 +0000 Received: from AM4PR0801MB2706.eurprd08.prod.outlook.com ([fe80::403b:850e:c32c:fad6]) by AM4PR0801MB2706.eurprd08.prod.outlook.com ([fe80::403b:850e:c32c:fad6%13]) with mapi id 15.20.0178.012; Tue, 31 Oct 2017 09:27:29 +0000 From: Hannes Tschofenig To: "ace@ietf.org" Thread-Topic: CWT - Audience Thread-Index: AdNSKfI2hzHNo17WTjWo9b3jurhMrA== Date: Tue, 31 Oct 2017 09:27:29 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [81.18.200.28] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM4PR0801MB2707; 6:iMhBaj9jHLHGobO9QESWPsmxasCI0zU9suO6peCSJr7V+5eO4m0jHSPRdQa7+xyFzPZENghBFNLi5kUxnCTluZ4tME8Hlppqv7OIdp9OBl0B/wDxQNwk2MPnQPqxDV+gEn1mFLVcJweioqUmXiix/P+Ep/m3/nY60ixSfTrq4KjxWjZQfGVWa72805EUdKWWTBRDd93dhzQFm75szbip8sISyLuNSgsNC5aWd73sl9pwSQDrUIlyL2SH7mYLitmaGDMTQRsXRu2nSaKRP53WAGYUSm8SGRdbL+o+Ay9U814+sI3ADx22atXTkjefJ5T12kLkFSkbmy+ml2/wndTyoznMv3CjTF0ww7obCH6VNNA=; 5:VlIiWft6OJXzwTZgcA13E0lQnED+zELBipf4o69PTi4WlhEN9s1GxiOuqKXRAOh1zWuB8BwSU2IV73ATpr9Ah3ER01BTyBUQPGOPSFF2cFPm/WrjInKZFPtu6R3ops7PCGuaxn0OBvwvSRU57rJAI+F805OLsyR2hEc/SoPtM2o=; 24:i+eg1ue3jmTtsYzvtk3ENN4c0jlVriKSag/9/TawlLRoA6i9zdX2rCqj1G6OfIwE8G/fQy8G15NJl55g8B6WPGyd/TqTAwkCIl15gjDAYoo=; 7:DWjfV305wAaf24oYKKmT28aMtaRryNF8Uwy+XYRV48ZWGFP7oGE7Tu9mmcYt7627bqsE665TSPZbALa8nWrsMfpS9vaYMiDaTl0KOW+05KFSGJp73oZmE+qnJdBRX9BEB6XRMTsKZo2LVcqwL3rcqv33afBc4BKygvHCUKBfBX41GO5OMa4601eVnz1E7aD+lSeeSKk54Zz9osBKCdupi14zSWMfiMgDZcroY1lXe10wDDCD4spZaBaLm6c+fplh x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: b12dc862-83a7-4316-adb3-08d520419b62 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(48565401081)(2017052603238); SRVR:AM4PR0801MB2707; x-ms-traffictypediagnostic: AM4PR0801MB2707: x-exchange-antispam-report-test: UriScan:(120809045254105)(21748063052155); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(10201501046)(3002001)(3231020)(93006095)(93001095)(100000703101)(100105400095)(6055026)(6041248)(20161123555025)(20161123562025)(20161123558100)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM4PR0801MB2707; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM4PR0801MB2707; x-forefront-prvs: 04772EA191 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(376002)(346002)(39860400002)(40434004)(199003)(189002)(53754006)(66066001)(53936002)(97736004)(6436002)(5640700003)(14454004)(5630700001)(74316002)(966005)(2900100001)(86362001)(3280700002)(2906002)(3660700001)(50986999)(68736007)(478600001)(25786009)(54356999)(2501003)(5660300001)(33656002)(7736002)(8936002)(5890100001)(72206003)(55016002)(6306002)(8676002)(101416001)(81156014)(81166006)(1730700003)(54896002)(6916009)(99286003)(9686003)(5250100002)(6506006)(316002)(189998001)(6116002)(2351001)(105586002)(790700001)(102836003)(106356001)(3846002)(7696004); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR0801MB2707; H:AM4PR0801MB2706.eurprd08.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AM4PR0801MB2706839A7EE736044596A855FA5E0AM4PR0801MB2706_" MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: b12dc862-83a7-4316-adb3-08d520419b62 X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Oct 2017 09:27:29.3441 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR0801MB2707 Archived-At: Subject: [Ace] CWT - Audience 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, 31 Oct 2017 09:27:35 -0000 --_000_AM4PR0801MB2706839A7EE736044596A855FA5E0AM4PR0801MB2706_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, in https://datatracker.ietf.org/doc/rfc7519/?include_text=3D1 (section 4.1.= 3), "aud" is defined for JWT as being an array of case-sensitive strings, o= r a single string. In https://datatracker.ietf.org/doc/draft-ietf-ace-cbor-web-token/?include_= text=3D1 (section 3.1.3), "aud" is defined for CWT as being like in JWT, bu= t "the value is of type StringOrURI". I was wondering how we arrived at this point where the CWT and the JWT diff= er in this regard. 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_AM4PR0801MB2706839A7EE736044596A855FA5E0AM4PR0801MB2706_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

in https://datatracker.ietf.org/doc/rfc7519/?include= _text=3D1 (section 4.1.3), “aud” is defined for JWT as being an= array of case-sensitive strings, or a single string.

 

In https://datatracker.ietf.org/doc/draft-ietf-ace-c= bor-web-token/?include_text=3D1 (section 3.1.3), “aud” is defin= ed for CWT as being like in JWT, but “the value is of type StringOrUR= I”.

 

I was wondering how we arrived at this point where t= he CWT and the JWT differ in this regard.

 

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_AM4PR0801MB2706839A7EE736044596A855FA5E0AM4PR0801MB2706_-- From nobody Tue Oct 31 02:28:35 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F97413F3FE for ; Tue, 31 Oct 2017 02:28:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0A3KXOkruUWp for ; Tue, 31 Oct 2017 02:28:31 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0041.outbound.protection.outlook.com [104.47.2.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E28A1395F0 for ; Tue, 31 Oct 2017 02:28: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=1CdzZ76xI1HdHLNV7uFI/AohjjQ1jSusIyfQEQiPVig=; b=eS0IA7FptArewUn0im5DKuqHSpcOSM415DoO26WacmX+8Cc2QLl/tuurpD+KKagEovdFdY2Rg2RwA8Floo6DAX1idwhS58MuXMd6UqzpdD/54C6RDz+ZGJrHyNE6e3se/8mSnXVnUSojPdsPwusrKjKrUX0HBRzVSpN7lQHLpys= Received: from AM4PR0801MB2706.eurprd08.prod.outlook.com (10.167.90.148) by AM4PR0801MB2705.eurprd08.prod.outlook.com (10.167.90.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.178.6; Tue, 31 Oct 2017 09:28:28 +0000 Received: from AM4PR0801MB2706.eurprd08.prod.outlook.com ([fe80::403b:850e:c32c:fad6]) by AM4PR0801MB2706.eurprd08.prod.outlook.com ([fe80::403b:850e:c32c:fad6%13]) with mapi id 15.20.0178.012; Tue, 31 Oct 2017 09:28:28 +0000 From: Hannes Tschofenig To: "ace@ietf.org" Thread-Topic: CWT - Scope Claim Thread-Index: AdNSKjCCGBNCG3i0QYKnEExRCZfMRg== Date: Tue, 31 Oct 2017 09:28:28 +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: [81.18.200.28] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM4PR0801MB2705; 6:CwXDzls1bMCdV/xARUnpQaRZjHESxUqUc/TyvFkmJKufKWpFMfMTg4kp7tMBSgITgvHpMDcEtT+ma58NZuhsEgVENfznNVui71FB7GQ07aTwWUGHiyxAFhMTPhIU0nTFccyGCgg/lBJrOTKzvM0oZse3dXuFkpTXzTQsnTzfdS6eB7eym9I5dwcK+yC/RcpEpZCw65ZX2OrRwuy9DEEg0WODie2ZuqtiRVD6stL8NKyDr97fefXtGeDuAaNOOpf2LdscnT1fjkKFVnlJieJSnq3ekI8yXgeX6EEfyGUdWem+G8e+6/Bj1E0T60eGbpfzeVOvlFOZePUbDJ+OWbD7ulBuX3M+/l0JYLbyDym0YN4=; 5:j/7CMhDCbZVbSb7PlUSzPEHgL2PBMxYI+F9+Cb7YNwHqk7E99uoMrzKIKehvCXHzp2Bfw8BcvkLRHHxzh2+NAtIXf4dsaHRG+UeS59NDnZr8unjlO93EiXXfRia7LdxELIKuMa51vhY7Q8zYwamAePOiqP5dJwbyzaNQhYkT+Ho=; 24:YZi/xd8d8pchRleEu72AlSbtRtSwCLjqp4XRHmR1jkei2dGC3wSknEwisZAiBjyo3DyhjJqhmN7Yx7kTpKnvtwvT5sz+a7y42yf14PX6aks=; 7:SCakX8wDEBF4d1H1Jo6OCBA3hRAWdXRHTQ7EtycfTpdxDby2qnJg8a1oZ1hyJAgaYdJtDQFE9Uab6Ba1hoCDqFL2NDsDzQhKkkFXLMnBKUpK3ebfpkSfw3EpmOeQUDvDHF/0auU5nano570CNXTA1Vpy5jC8837kvhc43zH2B9I8WjVIHukcKurD1lSHvab9HyQq9Ba8C9J891ThVfpi/z33szpxkSzVdG1Dw932Amo5SxopiBidIVam2nlCGxzP x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: ae040124-6869-4fce-564e-08d52041bebd x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081)(4534020)(4602075)(2017052603199); SRVR:AM4PR0801MB2705; x-ms-traffictypediagnostic: AM4PR0801MB2705: x-exchange-antispam-report-test: UriScan:(21748063052155); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(3002001)(93006095)(93001095)(3231020)(10201501046)(100000703101)(100105400095)(6055026)(6041248)(20161123558100)(20161123564025)(20161123560025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM4PR0801MB2705; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM4PR0801MB2705; x-forefront-prvs: 04772EA191 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39860400002)(376002)(346002)(40434004)(199003)(189002)(53754006)(74316002)(7696004)(6916009)(101416001)(72206003)(9686003)(53936002)(25786009)(99286003)(54896002)(55016002)(6306002)(68736007)(3846002)(5630700001)(478600001)(102836003)(790700001)(2906002)(2900100001)(14454004)(105586002)(106356001)(189998001)(6506006)(2351001)(3280700002)(3660700001)(316002)(6116002)(54356999)(50986999)(33656002)(86362001)(5660300001)(81156014)(8936002)(5250100002)(6436002)(8676002)(1730700003)(81166006)(66066001)(5890100001)(97736004)(5640700003)(2501003)(7736002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR0801MB2705; H:AM4PR0801MB2706.eurprd08.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AM4PR0801MB270634AF9F8DA5587DB885CEFA5E0AM4PR0801MB2706_" MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: ae040124-6869-4fce-564e-08d52041bebd X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Oct 2017 09:28:28.5804 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR0801MB2705 Archived-At: Subject: [Ace] CWT - Scope Claim 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, 31 Oct 2017 09:28:33 -0000 --_000_AM4PR0801MB270634AF9F8DA5587DB885CEFA5E0AM4PR0801MB2706_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, I was wondering whether we should define a claim, scope, that captures the = scope that was granted by the authorization server. 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_AM4PR0801MB270634AF9F8DA5587DB885CEFA5E0AM4PR0801MB2706_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

I was wondering whether we should define a claim, sc= ope, that captures the scope that was granted by the authorization server.

 

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_AM4PR0801MB270634AF9F8DA5587DB885CEFA5E0AM4PR0801MB2706_-- From nobody Tue Oct 31 02:42:25 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8F5813F6B7 for ; Tue, 31 Oct 2017 02:42:23 -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] 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 0LEw7ShUpJIT for ; Tue, 31 Oct 2017 02:42:21 -0700 (PDT) Received: from mail-pf0-x22e.google.com (mail-pf0-x22e.google.com [IPv6:2607:f8b0:400e:c00::22e]) (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 B99BA13F650 for ; Tue, 31 Oct 2017 02:42:21 -0700 (PDT) Received: by mail-pf0-x22e.google.com with SMTP id e64so13318963pfk.9 for ; Tue, 31 Oct 2017 02:42:21 -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=LfBZzaB613+EhKFAxbx3tKNiC1Tj8V1AC7ct308Ay9k=; b=kY+rZ1UeF9PJFL/1eJZSC+pr0sjJsDPPHQkkkazUVhk6mwzWbdFQk0MgrkQ6xujO8d yeI9k/YFHD4y5hz94YInnZhEFGdicaFJW3/eJz53bfBOv26IersPws/vwDDItcQUxh5D 0AZJhUedAeXHBSez5V0Zmo+OIm6t9r+A+ifVImgnfkAs2PpUScafw3FuBCCUnSnO8B+b zKTVzmH5KZyh5QGYMP9t5zkgnYxDsvadiVON/Uxlc93hh13oRBVEVK8w1lpOxn5XVgr+ MG0bPDXfOQIDve7Dv0VuNsOaVg3o83ZLkBy1qqmhlx4pUKm3+Q8TzvQP9qxQLt+u0/hi XZsw== 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=LfBZzaB613+EhKFAxbx3tKNiC1Tj8V1AC7ct308Ay9k=; b=lCB9WnMbcXb4ZRm3JzJ2UAg7Zu6N/g/+tgcrSaZdPNkhImREQzeYYDcWfhQDvBOowP ffVdjjhBwl+kcBrxrnRseosGJ66kdHzFhhm1OuUnrNSgXjjebclWW+SqiMHASjn7BjJv I9w2JXdOZ8mKwj5bGj/96U1TZuPatAPhbUEZ2Lnu9mG4yKVbqvBWuUD+iXVMeSk6aWjr CDoVXcAXZNpkZgazLox5IA8oNNvQfgRGYnw4x0iNHLdXZrtIZwx0jd0nMD0pJ1m0YpTT mF1LA/H3T5pWr4Ah9GfYeei3sryAduEdTFiJVs2sBobqPJ6NbFN3P/QPkNru6N3iDIrd RMmg== X-Gm-Message-State: AMCzsaV9I6UVdumFGZaeqrDIA4kjCYJCLmyBDyhUUn2RESzhmTz0+dg0 U357g5Uegb0K3p8/57YlAKhkK8GEEBKfgD7O/rZJ+s74 X-Google-Smtp-Source: ABhQp+RmlTf66Hc1Mdx8/lL0iO1IVYTa4Kju7LheHSOv9EqJykvqjx8l6o22bNQG0REoMfDiEA+wv/zERirwooRe5iU= X-Received: by 10.98.86.81 with SMTP id k78mr1447593pfb.58.1509442941325; Tue, 31 Oct 2017 02:42:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.186.199 with HTTP; Tue, 31 Oct 2017 02:42:20 -0700 (PDT) In-Reply-To: References: From: Samuel Erdtman Date: Tue, 31 Oct 2017 10:42:20 +0100 Message-ID: To: Hannes Tschofenig Cc: "ace@ietf.org" Content-Type: multipart/alternative; boundary="001a1147e1b453a535055cd492c9" Archived-At: Subject: Re: [Ace] CWT - Audience 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, 31 Oct 2017 09:42:24 -0000 --001a1147e1b453a535055cd492c9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable My guess is that this is an early mistake that has not been noticed, it has been like this from the first draft. I think the correct thing would be to change it so that CWT reflects JWT. //Samuel On Tue, Oct 31, 2017 at 10:27 AM, Hannes Tschofenig < Hannes.Tschofenig@arm.com> wrote: > Hi all, > > > > in https://datatracker.ietf.org/doc/rfc7519/?include_text=3D1 (section > 4.1.3), =E2=80=9Caud=E2=80=9D is defined for JWT as being an array of cas= e-sensitive > strings, or a single string. > > > > In https://datatracker.ietf.org/doc/draft-ietf-ace-cbor-web- > token/?include_text=3D1 (section 3.1.3), =E2=80=9Caud=E2=80=9D is defined= for CWT as being > like in JWT, but =E2=80=9Cthe value is of type StringOrURI=E2=80=9D. > > > > I was wondering how we arrived at this point where the CWT and the JWT > differ in this regard. > > > > 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 th= e > information in any medium. Thank you. > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > > --001a1147e1b453a535055cd492c9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
My guess is that this is an early mistake that h= as not been noticed, it has been like this from the first draft.

I think the correct thing would be to change it so that CWT reflects JWT= .

//Samuel

On Tue, Oct 31, 2017 at 10:27 AM, Hannes Tschofenig <Hannes.Tschofenig@arm.com> wrote:

Hi all,

=C2=A0

in https://datatracker.ietf.org/d= oc/rfc7519/?include_text=3D1 (section 4.1.3), =E2=80=9Caud=E2=80=9D is = defined for JWT as being an array of case-sensitive strings, or a single st= ring.

=C2=A0

In https://datat= racker.ietf.org/doc/draft-ietf-ace-cbor-web-token/?include_text= =3D1 (section 3.1.3), =E2=80=9Caud=E2=80=9D is defined for CWT as being= like in JWT, but =E2=80=9Cthe value is of type StringOrURI=E2=80=9D.

=C2=A0

I was wondering how we arrived at this point where t= he CWT and the JWT differ in this regard.

=C2=A0

Ciao

Hannes

=C2=A0

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

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


--001a1147e1b453a535055cd492c9-- From nobody Tue Oct 31 02:46:15 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C0E113F62D for ; Tue, 31 Oct 2017 02:46:14 -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] 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 nS1exfpS2adk for ; Tue, 31 Oct 2017 02:46:13 -0700 (PDT) Received: from mail-pf0-x22d.google.com (mail-pf0-x22d.google.com [IPv6:2607:f8b0:400e:c00::22d]) (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 9974C13F485 for ; Tue, 31 Oct 2017 02:46:12 -0700 (PDT) Received: by mail-pf0-x22d.google.com with SMTP id a8so13349564pfc.0 for ; Tue, 31 Oct 2017 02:46:12 -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=WbP9bOCIFTw+bueMZVmdjnk/4Blt38ruMj5ldptCKa0=; b=JCdLTkXuIXR/25orJwCETDtMrQaFgNKxjgnHerQCzptzjacYV4pdLsnlm6bbRyCBOQ MEAGsUUbmC/udDSc1gzgRGEMQeQCveQzL+7cuClH60e/i+LpctSABIR0tXRk66vzwJMg DZyxDbyMikngKnNPJeXhSNwdwIDIjwPynYCdFSV84BYWX0IMyt6dOlxlfCQdj6eEltyh tNsIZkYVwZr70gPNLwd5kOD5BYSyqB+ESV4QLi5/MtmFVeXWmxKULpCGxnU372A+JLhL 2HPhLWVa5zVki49jJxKhrlU4ONmNcKFd2E56PxOTHjWfWbuF1Kcxw1zo+KXTTrWwrt1s ISbA== 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=WbP9bOCIFTw+bueMZVmdjnk/4Blt38ruMj5ldptCKa0=; b=Vr6P6NKcmRUwfCfHOKYmp1S/QUG2M/oSII7nHKT6VcAHsZTm8El/KaVH24guQI9Enq GXDC/DRzW7UiqlUvz9WdkdNi+yedzZcg6D0Y/zoOwhMoTAXvW/TR2TRsssaVFU/X26UB MFEvyFE46tdU1mMy6gVtgdS5qrDhDdO321v1wC6NjQSfIS0c/v/PHK98YRI3mUKHU4BK xfMpi95aoXVOkRzYWi2G8zE5EkPTbk1niZxfVkiW/YQm0j1+Ax7A+qGNIljVSywvv342 HAderZc9F5mucCUxTCm9rtZ67crj9t9KJfItIuXHbskeIsT3JYPSMp+72xodtbAEMMTt /Oug== X-Gm-Message-State: AMCzsaUJVXDmEpQLpTGRfTUci56aESW+jUWSWZcCLo6cZRdpj61WOhdI Do48J1zRnLSjG/oTv6i4bSgTamFlauKOVv4PJTv3R/Q/Guk= X-Google-Smtp-Source: ABhQp+S64fHbt9T6T/RVsQa9tYXevTzxX3B9WeBtjOvzfeQ66YegNfXh7tC+4IKM92IUHFtv5gYmNVF1SHcdz2XZTRc= X-Received: by 10.84.234.198 with SMTP id i6mr1367270plt.260.1509443172199; Tue, 31 Oct 2017 02:46:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.186.199 with HTTP; Tue, 31 Oct 2017 02:46:11 -0700 (PDT) In-Reply-To: References: From: Samuel Erdtman Date: Tue, 31 Oct 2017 10:46:11 +0100 Message-ID: To: Hannes Tschofenig Cc: "ace@ietf.org" Content-Type: multipart/alternative; boundary="089e0822b9a0168402055cd4a086" Archived-At: Subject: Re: [Ace] CWT - Scope Claim 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, 31 Oct 2017 09:46:14 -0000 --089e0822b9a0168402055cd4a086 Content-Type: text/plain; charset="UTF-8" The framework does register a CWT 'scoop' claim, but I think it has to register it with JWT too to be correct. https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-08#section-8.5 //Samuel On Tue, Oct 31, 2017 at 10:28 AM, Hannes Tschofenig < Hannes.Tschofenig@arm.com> wrote: > Hi all, > > > > I was wondering whether we should define a claim, scope, that captures the > scope that was granted by the authorization server. > > > > 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 > > --089e0822b9a0168402055cd4a086 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The framework does register a CWT 'scoop' claim, b= ut I think it has to register it with JWT too to be correct.

https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-08#section-8.5<= /a>

//Samuel

On Tue, Oct 31, 2017 at 10:28 AM, Hanne= s Tschofenig <Hannes.Tschofenig@arm.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">

Hi all,

=C2=A0

I was wondering whether we should define a claim, sc= ope, that captures the scope that was granted by the authorization server.

=C2=A0

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.

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


--089e0822b9a0168402055cd4a086-- From nobody Tue Oct 31 02:58:02 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E963713B126 for ; Tue, 31 Oct 2017 02:58:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Caznn3GPh4P7 for ; Tue, 31 Oct 2017 02:57:58 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0055.outbound.protection.outlook.com [104.47.0.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 2198013B11B for ; Tue, 31 Oct 2017 02:57: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=zbd2IIOeGIFnpoHr5MBEvOpuq4iIM6sXlr9OUO9qLlo=; b=HTgKQpW5D275cspeLwpKdEUQoOV4IQr/lqu8/7TGyRw+UyWC2qt3r7USiNAyVkTC563bLlemrboZ6UQBFNnOdEnsMN+6sF+njgMHVUZMDDpsPCfU8j/FU3jhiIGd+S6az8VqWU4Q3QP10kNbfiqOHdMH7Ih11+QC/obhQuLtwuk= Received: from AM4PR0801MB2706.eurprd08.prod.outlook.com (10.167.90.148) by AM4PR0801MB2706.eurprd08.prod.outlook.com (10.167.90.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.178.6; Tue, 31 Oct 2017 09:57:55 +0000 Received: from AM4PR0801MB2706.eurprd08.prod.outlook.com ([fe80::403b:850e:c32c:fad6]) by AM4PR0801MB2706.eurprd08.prod.outlook.com ([fe80::403b:850e:c32c:fad6%13]) with mapi id 15.20.0178.012; Tue, 31 Oct 2017 09:57:55 +0000 From: Hannes Tschofenig To: Samuel Erdtman CC: "ace@ietf.org" Thread-Topic: [Ace] CWT - Scope Claim Thread-Index: AdNSKjCCGBNCG3i0QYKnEExRCZfMRgAAuTmAAABY/fA= Date: Tue, 31 Oct 2017 09:57:54 +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: [81.18.200.28] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM4PR0801MB2706; 6:338Xsz8AO4tZdQeJTM3rlzhchuSf9yrlw/cZiboY+hapCcLryAFPs7g0hjak2FidGWYc36RpPDF3cNXaloQI1LDpuDzwJPuC3q9j+ftuOGYW0hG17HoljAImJftLK/yXV1w2PT0srwwJg+TtatTUkr+Z1/VGJWlJ8s6eaAVBA2XGKqoJSEnyhFtMoJ3CfjZvZk2y+m4XMaoNSpvVa/e1jzVtjvqP3+NFso+kNODAy3upgOiKZnIHUUeqVCXl6ZoB05GjW48JRPdx+Q4Z2PfDm/Yf9socale6L/JcWlA4rZpfEZCrsGhG45X5LLjthIp9u4Y3HW4nEdPI0sDObIA8eUFBPs5gMops92NgBwO9UE4=; 5:jpRd9NPYojWVn+P29HOfKKVZpxkWUyhNnZqCQW3cEPT1lFFxmDriIPAdAqaFe8TrnWxdnGPhDoNiI/RdFHiwjK/SNirwbJvXgFIXJi8aUC4jp740HSpWRxXtyUeUsuOiZNzbMpK9tGKRs1ZI3HK038faZtETlpInlCb3lvdfKWY=; 24:0Bqsj7ffZhwiHxWQjiNitTzu94g2OY6NT+FOv/palUqHTfZL7kqk8np4U4hClmFmi0t6SZGSrpQoQ2Vbv1P0Ur/Zo9rGCwgkIpFHn9UKKIY=; 7:UkEoz7VJEeDSwASRouz2f0Kl/fPSqsROlkwC0m8UZaHUaRuM7sML3WGV9rtZz659k0gFyZMVJDJOUE14zIAzoCCqiK4wnp3S3TOT41KfAXEWZbvplKbBqzDoS0CTPY8+UrPuC1w+NnDdOLHC2j1N1W0NQEzHbur+05jOzreIEmfOUTwIarmIHCh0AF6rHOlr4Zf+5Cda+QGJkCY0AKhySCrhoHcmr+UpyN7DE700rjgiUwEt/40VexQUpwqD+MtP x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: e355b2c0-b969-44d3-3cdd-08d52045db7f x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081)(4534020)(4602075)(2017052603199); SRVR:AM4PR0801MB2706; x-ms-traffictypediagnostic: AM4PR0801MB2706: x-exchange-antispam-report-test: UriScan:(180628864354917)(21748063052155); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3231020)(3002001)(100000703101)(100105400095)(6055026)(6041248)(20161123562025)(20161123564025)(20161123555025)(20161123558100)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM4PR0801MB2706; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM4PR0801MB2706; x-forefront-prvs: 04772EA191 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(346002)(376002)(40434004)(24454002)(189002)(53754006)(199003)(86362001)(106356001)(790700001)(5250100002)(8936002)(81166006)(25786009)(81156014)(33656002)(7736002)(74316002)(105586002)(72206003)(97736004)(66066001)(478600001)(68736007)(9326002)(316002)(8676002)(5660300001)(189998001)(99286003)(7696004)(2906002)(3660700001)(54896002)(3280700002)(9686003)(6306002)(14454004)(55016002)(6116002)(236005)(5890100001)(53936002)(6246003)(606006)(53546010)(966005)(3846002)(102836003)(4326008)(2950100002)(101416001)(6916009)(229853002)(2900100001)(6506006)(6436002)(54356999)(76176999)(50986999); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR0801MB2706; H:AM4PR0801MB2706.eurprd08.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AM4PR0801MB2706F7C3D32E0C64BF67370EFA5E0AM4PR0801MB2706_" MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: e355b2c0-b969-44d3-3cdd-08d52045db7f X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Oct 2017 09:57:54.9236 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR0801MB2706 Archived-At: Subject: Re: [Ace] CWT - Scope Claim 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, 31 Oct 2017 09:58:01 -0000 --_000_AM4PR0801MB2706F7C3D32E0C64BF67370EFA5E0AM4PR0801MB2706_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgU2FtdWVsLA0KDQpZb3UgYXJlIGNvcnJlY3QgdGhhdCB3ZSBzaG91bGQgcmVnaXN0ZXIgaXQg YWxzbyB3aXRoIHRoZSBKV1QuDQoNCkFkZGl0aW9uYWxseSwgSSB3b25kZXIgd2hldGhlciB0aGUg c3RyaW5nIHJlcHJlc2VudGF0aW9uIG9mIHRoZSBjbGFpbSBmb3IgdGhlIENXVCBpcyB0aGUgbW9z dCBlZmZpY2llbnQgd2F5IHRvIHJlcHJlc2VudCB0aGUgc2NvcGUuIFNob3VsZG7igJl0IHdlIHJh dGhlciB1c2UgQ0JPUiBjYXBhYmlsaXRpZXMgaGVyZSBzaW5jZSB3ZSBhcmUgdHJ5aW5nIHRvIG9w dGltaXplIDIgYnl0ZXMgaW4gb3RoZXIgYXJlYXM/DQoNCkNpYW8NCkhhbm5lcw0KDQpGcm9tOiBT YW11ZWwgRXJkdG1hbiBbbWFpbHRvOnNhbXVlbEBlcmR0bWFuLnNlXQ0KU2VudDogMzEgT2N0b2Jl ciAyMDE3IDEwOjQ2DQpUbzogSGFubmVzIFRzY2hvZmVuaWcNCkNjOiBhY2VAaWV0Zi5vcmcNClN1 YmplY3Q6IFJlOiBbQWNlXSBDV1QgLSBTY29wZSBDbGFpbQ0KDQpUaGUgZnJhbWV3b3JrIGRvZXMg cmVnaXN0ZXIgYSBDV1QgJ3Njb29wJyBjbGFpbSwgYnV0IEkgdGhpbmsgaXQgaGFzIHRvIHJlZ2lz dGVyIGl0IHdpdGggSldUIHRvbyB0byBiZSBjb3JyZWN0Lg0KDQpodHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtaWV0Zi1hY2Utb2F1dGgtYXV0aHotMDgjc2VjdGlvbi04LjUNCg0KLy9T YW11ZWwNCg0KT24gVHVlLCBPY3QgMzEsIDIwMTcgYXQgMTA6MjggQU0sIEhhbm5lcyBUc2Nob2Zl bmlnIDxIYW5uZXMuVHNjaG9mZW5pZ0Bhcm0uY29tPG1haWx0bzpIYW5uZXMuVHNjaG9mZW5pZ0Bh cm0uY29tPj4gd3JvdGU6DQpIaSBhbGwsDQoNCkkgd2FzIHdvbmRlcmluZyB3aGV0aGVyIHdlIHNo b3VsZCBkZWZpbmUgYSBjbGFpbSwgc2NvcGUsIHRoYXQgY2FwdHVyZXMgdGhlIHNjb3BlIHRoYXQg d2FzIGdyYW50ZWQgYnkgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyLg0KDQpDaWFvDQpIYW5uZXMN CklNUE9SVEFOVCBOT1RJQ0U6IFRoZSBjb250ZW50cyBvZiB0aGlzIGVtYWlsIGFuZCBhbnkgYXR0 YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbCBhbmQgbWF5IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYg eW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIG5vdGlmeSB0aGUgc2Vu ZGVyIGltbWVkaWF0ZWx5IGFuZCBkbyBub3QgZGlzY2xvc2UgdGhlIGNvbnRlbnRzIHRvIGFueSBv dGhlciBwZXJzb24sIHVzZSBpdCBmb3IgYW55IHB1cnBvc2UsIG9yIHN0b3JlIG9yIGNvcHkgdGhl IGluZm9ybWF0aW9uIGluIGFueSBtZWRpdW0uIFRoYW5rIHlvdS4NCg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkFjZSBtYWlsaW5nIGxpc3QNCkFjZUBp ZXRmLm9yZzxtYWlsdG86QWNlQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9hY2UNCg0KSU1QT1JUQU5UIE5PVElDRTogVGhlIGNvbnRlbnRzIG9mIHRoaXMg ZW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBhcmUgY29uZmlkZW50aWFsIGFuZCBtYXkgYWxzbyBi ZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVh c2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIGRvIG5vdCBkaXNjbG9zZSB0aGUg Y29udGVudHMgdG8gYW55IG90aGVyIHBlcnNvbiwgdXNlIGl0IGZvciBhbnkgcHVycG9zZSwgb3Ig c3RvcmUgb3IgY29weSB0aGUgaW5mb3JtYXRpb24gaW4gYW55IG1lZGl1bS4gVGhhbmsgeW91Lg0K --_000_AM4PR0801MB2706F7C3D32E0C64BF67370EFA5E0AM4PR0801MB2706_ 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 Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJ bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6 NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0K ZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1h eD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9 IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9k eSBsYW5nPSJFTi1HQiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJX b3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhpIFNhbXVlbCwNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+WW91IGFyZSBjb3Jy ZWN0IHRoYXQgd2Ugc2hvdWxkIHJlZ2lzdGVyIGl0IGFsc28gd2l0aCB0aGUgSldULg0KPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5BZGRpdGlvbmFsbHksIEkgd29uZGVyIHdoZXRoZXIgdGhlIHN0cmluZyByZXByZXNlbnRh dGlvbiBvZiB0aGUgY2xhaW0gZm9yIHRoZSBDV1QgaXMgdGhlIG1vc3QgZWZmaWNpZW50IHdheSB0 byByZXByZXNlbnQgdGhlIHNjb3BlLiBTaG91bGRu4oCZdCB3ZSByYXRoZXIgdXNlDQogQ0JPUiBj YXBhYmlsaXRpZXMgaGVyZSBzaW5jZSB3ZSBhcmUgdHJ5aW5nIHRvIG9wdGltaXplIDIgYnl0ZXMg aW4gb3RoZXIgYXJlYXM/IDxvOnA+DQo8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5DaWFvPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPkhhbm5lczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxhIG5hbWU9Il9NYWlsRW5kQ29tcG9zZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvYT48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZy b206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBT YW11ZWwgRXJkdG1hbiBbbWFpbHRvOnNhbXVlbEBlcmR0bWFuLnNlXQ0KPGJyPg0KPGI+U2VudDo8 L2I+IDMxIE9jdG9iZXIgMjAxNyAxMDo0Njxicj4NCjxiPlRvOjwvYj4gSGFubmVzIFRzY2hvZmVu aWc8YnI+DQo8Yj5DYzo8L2I+IGFjZUBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTog W0FjZV0gQ1dUIC0gU2NvcGUgQ2xhaW08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5UaGUgZnJhbWV3b3JrIGRvZXMgcmVnaXN0ZXIgYSBDV1QgJ3Njb29wJyBjbGFpbSwgYnV0 IEkgdGhpbmsgaXQgaGFzIHRvIHJlZ2lzdGVyIGl0IHdpdGggSldUIHRvbyB0byBiZSBjb3JyZWN0 LjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxhIGhy ZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWFjZS1vYXV0aC1hdXRo ei0wOCNzZWN0aW9uLTguNSI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYt YWNlLW9hdXRoLWF1dGh6LTA4I3NlY3Rpb24tOC41PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4vL1NhbXVlbDxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUdWUsIE9jdCAzMSwgMjAx NyBhdCAxMDoyOCBBTSwgSGFubmVzIFRzY2hvZmVuaWcgJmx0OzxhIGhyZWY9Im1haWx0bzpIYW5u ZXMuVHNjaG9mZW5pZ0Bhcm0uY29tIiB0YXJnZXQ9Il9ibGFuayI+SGFubmVzLlRzY2hvZmVuaWdA YXJtLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPkhpIGFsbCwNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ SSB3YXMgd29uZGVyaW5nIHdoZXRoZXIgd2Ugc2hvdWxkIGRlZmluZSBhIGNsYWltLCBzY29wZSwg dGhhdCBjYXB0dXJlcyB0aGUgc2NvcGUgdGhhdCB3YXMgZ3JhbnRlZCBieSB0aGUgYXV0aG9yaXph dGlvbiBzZXJ2ZXIuDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkNpYW88bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SGFubmVzPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklNUE9SVEFOVCBOT1RJQ0U6IFRoZSBjb250ZW50cyBv ZiB0aGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbCBhbmQgbWF5 IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVu dCwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBkbyBub3QgZGlzY2xv c2UgdGhlIGNvbnRlbnRzIHRvIGFueSBvdGhlciBwZXJzb24sDQogdXNlIGl0IGZvciBhbnkgcHVy cG9zZSwgb3Igc3RvcmUgb3IgY29weSB0aGUgaW5mb3JtYXRpb24gaW4gYW55IG1lZGl1bS4gVGhh bmsgeW91Lg0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX188YnI+DQpBY2UgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJl Zj0ibWFpbHRvOkFjZUBpZXRmLm9yZyI+QWNlQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYWNlIiB0YXJnZXQ9Il9ibGFuayI+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hY2U8L2E+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCklNUE9SVEFOVCBOT1RJQ0U6IFRoZSBjb250ZW50cyBvZiB0aGlzIGVt YWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbCBhbmQgbWF5IGFsc28gYmUg cHJpdmlsZWdlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNl IG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBkbyBub3QgZGlzY2xvc2UgdGhlIGNv bnRlbnRzIHRvIGFueSBvdGhlciBwZXJzb24sIHVzZSBpdCBmb3IgYW55IHB1cnBvc2UsDQogb3Ig c3RvcmUgb3IgY29weSB0aGUgaW5mb3JtYXRpb24gaW4gYW55IG1lZGl1bS4gVGhhbmsgeW91Lg0K PC9ib2R5Pg0KPC9odG1sPg0K --_000_AM4PR0801MB2706F7C3D32E0C64BF67370EFA5E0AM4PR0801MB2706_-- From nobody Tue Oct 31 02:58:45 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61D8313AE0B for ; Tue, 31 Oct 2017 02:58:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dTXt1D9ZEcOg for ; Tue, 31 Oct 2017 02:58:42 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0067.outbound.protection.outlook.com [104.47.0.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFE0F139428 for ; Tue, 31 Oct 2017 02:58:41 -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=MCvqR2/JRa8G+S8l8NqK/oGWLEphA42DO14cTh2s+7w=; b=oGJJyA6rXrxSmnZp2JbASCFnzHPyjjoiSJCYCI6K4jg8IjJwawz0yY1tUIUUUr8yQVkQhJXKUfTrJKNqxxpzN536n3Sv0Tp2KCbUli29KrYHjaX517OpJ4Tv7a7NL420hnyTKQHReV1VRMvfHAWDzQkHQoCCdImf5+RsViv/dLQ= Received: from AM4PR0801MB2706.eurprd08.prod.outlook.com (10.167.90.148) by AM4PR0801MB2706.eurprd08.prod.outlook.com (10.167.90.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.178.6; Tue, 31 Oct 2017 09:58:39 +0000 Received: from AM4PR0801MB2706.eurprd08.prod.outlook.com ([fe80::403b:850e:c32c:fad6]) by AM4PR0801MB2706.eurprd08.prod.outlook.com ([fe80::403b:850e:c32c:fad6%13]) with mapi id 15.20.0178.012; Tue, 31 Oct 2017 09:58:39 +0000 From: Hannes Tschofenig To: Samuel Erdtman CC: "ace@ietf.org" Thread-Topic: [Ace] CWT - Scope Claim Thread-Index: AdNSKjCCGBNCG3i0QYKnEExRCZfMRgAAuTmAAABoFvA= Date: Tue, 31 Oct 2017 09:58:38 +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: [81.18.200.28] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM4PR0801MB2706; 6:4CNnh56r5Ck2x3og9hZXJU6YiP2zmr/P8izK4oZ+MbqNrC7wlc2RODUmTLD969KdJ699LTWYNfv5+eVyl/zFiVlOAo6MwgwGuGSehPJJ0u/Q4fnHOyAQortVUYzhQLTm4yq0BPESy8gKmuI5YyVRhkVQU+COOvVpEVU2hdSl4Q54FSIyqHER45tJwAXEDY4KWnu1G+ZZGbnISDcxS/6vyPZvyYIXymiO/rP0B5LS5vDNy5LBCFpIU3zkIG+Q8IlmrR4K1qk1vpVuRjxMxlC0NKWUm70h0gzIROI2Kvw5VBakId2ojwzZOqUlssyz+DWtZgP9wKUkrebSjnjauAjrcXQfLnffZlo7vVGUVxaykhA=; 5:+k0CIbTrHekYpw6DL2fkCbBmuuzguBV9yH7fCpBfZ3kqOq5tI26e7GCciaJW+hGlbUNMZ7+RWuEJnQQn2Z2ruWIUiIMQkLLKgpeX57cbzM22fmg3tnj8tUhp7rl9CILK2jGwTP5dCpiOPKHswLZkGBMwnjvW6i6H25AKSnWN3eA=; 24:7XynR4VemU4IixVj7oQqT2ZmOaRxAOpTMuhnfomt8BButYcdfelM76NPxBp+sr9t2xuGg3Olt7g3i0+sNzbcqgJADq0RziJI5FgegcWYvk4=; 7:xB4A5oPLW3ZzxXXNSqGMrNxznXqnKF3+U4+puqMdPWz+lCyXo/YfmXFqguqs1XZelf3iIy/hwIwBiCE6KixqoHEXAZy9x9qPR2yHLjT+Z1zEXXbGFT7tfSz9kDjPkNeHfzlmPWkaAT9BQ3bvfS394jJrxnIMXSkWMIolxRj0KzQblmhEUF9erQNtgpgrcOWbwbEZTPvzSlacpORBWK47mywW3mE59YkE6V2Brxco/j+A7rSXzNaqlHzR3tnpQ/l0 x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: dd2e1da8-4cda-447c-51d3-08d52045f5b9 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081)(4534020)(4602075)(2017052603199); SRVR:AM4PR0801MB2706; x-ms-traffictypediagnostic: AM4PR0801MB2706: x-exchange-antispam-report-test: UriScan:(180628864354917)(21748063052155); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3231020)(3002001)(100000703101)(100105400095)(6055026)(6041248)(20161123562025)(20161123564025)(20161123555025)(20161123558100)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM4PR0801MB2706; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM4PR0801MB2706; x-forefront-prvs: 04772EA191 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(346002)(376002)(40434004)(24454002)(189002)(53754006)(199003)(86362001)(106356001)(790700001)(5250100002)(8936002)(81166006)(25786009)(81156014)(33656002)(7736002)(74316002)(105586002)(72206003)(97736004)(66066001)(478600001)(68736007)(316002)(8676002)(5660300001)(189998001)(99286003)(7696004)(2906002)(3660700001)(54896002)(3280700002)(9686003)(6306002)(14454004)(55016002)(6116002)(236005)(5890100001)(53936002)(6246003)(606006)(53546010)(966005)(3846002)(102836003)(4326008)(2950100002)(101416001)(6916009)(229853002)(2900100001)(6506006)(6436002)(54356999)(76176999)(50986999); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR0801MB2706; H:AM4PR0801MB2706.eurprd08.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AM4PR0801MB2706D4A80E8F1E7C8AF48D87FA5E0AM4PR0801MB2706_" MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: dd2e1da8-4cda-447c-51d3-08d52045f5b9 X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Oct 2017 09:58:38.9094 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR0801MB2706 Archived-At: Subject: Re: [Ace] CWT - Scope Claim 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, 31 Oct 2017 09:58:44 -0000 --_000_AM4PR0801MB2706D4A80E8F1E7C8AF48D87FA5E0AM4PR0801MB2706_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QW4gYWRkaXRpb25hbCB0aG91Z2g6IHdvdWxkIGl0IG1ha2Ugc2Vuc2UgdG8gcHV0IHRoZSBzY29w ZSBjbGFpbSBpbnRvIHRoZSBDV1QgaW5zdGVhZCBvZiBwdXR0aW5nIGl0IGludG8gdGhlIG9hdXRo LWF1dGh6IGZyYW1ld29yaz8NCg0KDQoNCkZyb206IFNhbXVlbCBFcmR0bWFuIFttYWlsdG86c2Ft dWVsQGVyZHRtYW4uc2VdDQpTZW50OiAzMSBPY3RvYmVyIDIwMTcgMTA6NDYNClRvOiBIYW5uZXMg VHNjaG9mZW5pZw0KQ2M6IGFjZUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtBY2VdIENXVCAtIFNj b3BlIENsYWltDQoNClRoZSBmcmFtZXdvcmsgZG9lcyByZWdpc3RlciBhIENXVCAnc2Nvb3AnIGNs YWltLCBidXQgSSB0aGluayBpdCBoYXMgdG8gcmVnaXN0ZXIgaXQgd2l0aCBKV1QgdG9vIHRvIGJl IGNvcnJlY3QuDQoNCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWFjZS1v YXV0aC1hdXRoei0wOCNzZWN0aW9uLTguNQ0KDQovL1NhbXVlbA0KDQpPbiBUdWUsIE9jdCAzMSwg MjAxNyBhdCAxMDoyOCBBTSwgSGFubmVzIFRzY2hvZmVuaWcgPEhhbm5lcy5Uc2Nob2ZlbmlnQGFy bS5jb208bWFpbHRvOkhhbm5lcy5Uc2Nob2ZlbmlnQGFybS5jb20+PiB3cm90ZToNCkhpIGFsbCwN Cg0KSSB3YXMgd29uZGVyaW5nIHdoZXRoZXIgd2Ugc2hvdWxkIGRlZmluZSBhIGNsYWltLCBzY29w ZSwgdGhhdCBjYXB0dXJlcyB0aGUgc2NvcGUgdGhhdCB3YXMgZ3JhbnRlZCBieSB0aGUgYXV0aG9y aXphdGlvbiBzZXJ2ZXIuDQoNCkNpYW8NCkhhbm5lcw0KSU1QT1JUQU5UIE5PVElDRTogVGhlIGNv bnRlbnRzIG9mIHRoaXMgZW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBhcmUgY29uZmlkZW50aWFs IGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQg cmVjaXBpZW50LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIGRvIG5v dCBkaXNjbG9zZSB0aGUgY29udGVudHMgdG8gYW55IG90aGVyIHBlcnNvbiwgdXNlIGl0IGZvciBh bnkgcHVycG9zZSwgb3Igc3RvcmUgb3IgY29weSB0aGUgaW5mb3JtYXRpb24gaW4gYW55IG1lZGl1 bS4gVGhhbmsgeW91Lg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KQWNlIG1haWxpbmcgbGlzdA0KQWNlQGlldGYub3JnPG1haWx0bzpBY2VAaWV0Zi5v cmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FjZQ0KDQpJTVBPUlRB TlQgTk9USUNFOiBUaGUgY29udGVudHMgb2YgdGhpcyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRz IGFyZSBjb25maWRlbnRpYWwgYW5kIG1heSBhbHNvIGJlIHByaXZpbGVnZWQuIElmIHlvdSBhcmUg bm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1l ZGlhdGVseSBhbmQgZG8gbm90IGRpc2Nsb3NlIHRoZSBjb250ZW50cyB0byBhbnkgb3RoZXIgcGVy c29uLCB1c2UgaXQgZm9yIGFueSBwdXJwb3NlLCBvciBzdG9yZSBvciBjb3B5IHRoZSBpbmZvcm1h dGlvbiBpbiBhbnkgbWVkaXVtLiBUaGFuayB5b3UuDQo= --_000_AM4PR0801MB2706D4A80E8F1E7C8AF48D87FA5E0AM4PR0801MB2706_ 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 Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJ bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6 NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0K ZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1h eD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9 IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9k eSBsYW5nPSJFTi1HQiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJX b3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkFuIGFkZGl0aW9uYWwgdGhvdWdoOiB3b3VsZCBpdCBtYWtl IHNlbnNlIHRvIHB1dCB0aGUgc2NvcGUgY2xhaW0gaW50byB0aGUgQ1dUIGluc3RlYWQgb2YgcHV0 dGluZyBpdCBpbnRvIHRoZSBvYXV0aC1hdXRoeiBmcmFtZXdvcms/DQo8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIG5hbWU9Il9N YWlsRW5kQ29tcG9zZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvYT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwv Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBTYW11ZWwgRXJkdG1h biBbbWFpbHRvOnNhbXVlbEBlcmR0bWFuLnNlXQ0KPGJyPg0KPGI+U2VudDo8L2I+IDMxIE9jdG9i ZXIgMjAxNyAxMDo0Njxicj4NCjxiPlRvOjwvYj4gSGFubmVzIFRzY2hvZmVuaWc8YnI+DQo8Yj5D Yzo8L2I+IGFjZUBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW0FjZV0gQ1dUIC0g U2NvcGUgQ2xhaW08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgZnJh bWV3b3JrIGRvZXMgcmVnaXN0ZXIgYSBDV1QgJ3Njb29wJyBjbGFpbSwgYnV0IEkgdGhpbmsgaXQg aGFzIHRvIHJlZ2lzdGVyIGl0IHdpdGggSldUIHRvbyB0byBiZSBjb3JyZWN0LjxvOnA+PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWFjZS1vYXV0aC1hdXRoei0wOCNzZWN0aW9u LTguNSI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtYWNlLW9hdXRoLWF1 dGh6LTA4I3NlY3Rpb24tOC41PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4vL1NhbXVlbDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUdWUsIE9jdCAzMSwgMjAxNyBhdCAxMDoyOCBB TSwgSGFubmVzIFRzY2hvZmVuaWcgJmx0OzxhIGhyZWY9Im1haWx0bzpIYW5uZXMuVHNjaG9mZW5p Z0Bhcm0uY29tIiB0YXJnZXQ9Il9ibGFuayI+SGFubmVzLlRzY2hvZmVuaWdAYXJtLmNvbTwvYT4m Z3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPkhpIGFsbCwNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SSB3YXMgd29uZGVy aW5nIHdoZXRoZXIgd2Ugc2hvdWxkIGRlZmluZSBhIGNsYWltLCBzY29wZSwgdGhhdCBjYXB0dXJl cyB0aGUgc2NvcGUgdGhhdCB3YXMgZ3JhbnRlZCBieSB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIu DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkNpYW88bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+SGFubmVzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPklNUE9SVEFOVCBOT1RJQ0U6IFRoZSBjb250ZW50cyBvZiB0aGlzIGVtYWls IGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbCBhbmQgbWF5IGFsc28gYmUgcHJp dmlsZWdlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIG5v dGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBkbyBub3QgZGlzY2xvc2UgdGhlIGNvbnRl bnRzIHRvIGFueSBvdGhlciBwZXJzb24sDQogdXNlIGl0IGZvciBhbnkgcHVycG9zZSwgb3Igc3Rv cmUgb3IgY29weSB0aGUgaW5mb3JtYXRpb24gaW4gYW55IG1lZGl1bS4gVGhhbmsgeW91Lg0KPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t Ym90dG9tOjEyLjBwdCI+PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX188YnI+DQpBY2UgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOkFj ZUBpZXRmLm9yZyI+QWNlQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vYWNlIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hY2U8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCklNUE9SVEFOVCBOT1RJQ0U6IFRoZSBjb250ZW50cyBvZiB0aGlzIGVtYWlsIGFuZCBhbnkg YXR0YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbCBhbmQgbWF5IGFsc28gYmUgcHJpdmlsZWdlZC4g SWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIG5vdGlmeSB0aGUg c2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBkbyBub3QgZGlzY2xvc2UgdGhlIGNvbnRlbnRzIHRvIGFu eSBvdGhlciBwZXJzb24sIHVzZSBpdCBmb3IgYW55IHB1cnBvc2UsDQogb3Igc3RvcmUgb3IgY29w eSB0aGUgaW5mb3JtYXRpb24gaW4gYW55IG1lZGl1bS4gVGhhbmsgeW91Lg0KPC9ib2R5Pg0KPC9o dG1sPg0K --_000_AM4PR0801MB2706D4A80E8F1E7C8AF48D87FA5E0AM4PR0801MB2706_-- From nobody Tue Oct 31 03:55:42 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F80813F44B for ; Tue, 31 Oct 2017 03:55:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2GdPIIKJmSmu for ; Tue, 31 Oct 2017 03:55:39 -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 02CF513F63A for ; Tue, 31 Oct 2017 03:55:38 -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 v9VAtYrr006245; Tue, 31 Oct 2017 11:55:34 +0100 (CET) Received: from client-0073.vpn.uni-bremen.de (client-0073.vpn.uni-bremen.de [134.102.107.73]) (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 3yR7YK62J0zDWbF; Tue, 31 Oct 2017 11:55:33 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carsten Bormann In-Reply-To: Date: Tue, 31 Oct 2017 11:55:33 +0100 Cc: Hannes Tschofenig , "ace@ietf.org" X-Mao-Original-Outgoing-Id: 531140133.1384-41f7e5f1f19c066eef436b224f258356 Content-Transfer-Encoding: quoted-printable Message-Id: <51079F6A-61C8-42E5-8658-FBC02B35A140@tzi.org> References: To: Samuel Erdtman X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Ace] CWT - Audience 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, 31 Oct 2017 10:55:40 -0000 On Oct 31, 2017, at 10:42, Samuel Erdtman wrote: >=20 > My guess is that this is an early mistake that has not been noticed, = it has been like this from the first draft. I sure noticed the difference, but thought that this was an intended = simplification: simply not allowing audiences with multiple strings. > I think the correct thing would be to change it so that CWT reflects = JWT. So we get a choice between a text string and an array of text strings. Gr=C3=BC=C3=9Fe, Carsten From nobody Tue Oct 31 06:24:24 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC68A139504 for ; Tue, 31 Oct 2017 06:24:23 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dQ5jrtAvqVaV for ; Tue, 31 Oct 2017 06:24:22 -0700 (PDT) Received: from mail-pg0-x234.google.com (mail-pg0-x234.google.com [IPv6:2607:f8b0:400e:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9655139F5C for ; Tue, 31 Oct 2017 06:24:19 -0700 (PDT) Received: by mail-pg0-x234.google.com with SMTP id y5so14646912pgq.7 for ; Tue, 31 Oct 2017 06:24:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=9K0ZFYkH+VgZYnF3kTXqPWeZtDhtsljK+u6sk1b3U48=; b=ZuCVH79Y64M++TzRuMO/BwZB26xV6JbZaGOnlWC8eoogQHof8RxSMC74Qz8VhLBw0+ xPcXF4A0vqdXG+UyR2tVhp2Gz+taHuXvnrmwrB0+f7B0Q10dkGMt+PO3qMaCcHEk9ksV 5XiMhaBuZ+Qktc0BJaxBNjsIl6onmYzBUMRFQZd80tJfyzJKHLWMi+UPVmNeMUKqQWvI d9sVtQW8crWXplSz3XDnaG5g2rtgovg6t1KulYb6fdxiMQZqCGGBkwa2LBuO14XEBsIE fWoImxk3kGaNI/1aIB/nCJ1JYsprJvcurUPkhy3SIMV4UlYpGKX3R/NaKIZywC1+ml+E u+sg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=9K0ZFYkH+VgZYnF3kTXqPWeZtDhtsljK+u6sk1b3U48=; b=MmYNHKjMHQR6RaoYoqqxx9zVhlvwy24Y+5WmzHG/wpoavdVzb083sRhmDe/8zJz5z/ F6fHE0iDe0mMx7U1LkhG1P37/A8OcDcWqMIg2gACWSKMHmPji6jYHN6YvOiwg0Mjode4 hBsU6rc9nPX/f1A6pZr9M0CH5c2Ci+DxbsADLW1dksoUsjv6V09rAFttb1MXdKrktmLf NSfY8fNIM/njB802DcQXq9Gvs4bkTnloLxLQaMYasBebuBxjbpaUZqDGlqMLnZjI+z9a hAdJJ7D4hNCsZ2Aaov9BD7ZBnbQZUmZukrTccFhZt04wyWuXBeUYP07sjWhd7+/IIWC0 ZsiQ== X-Gm-Message-State: AMCzsaVtsZkbVsrmXtcQLGWkG7OtHhAVMkPAB73FImllmcrMQYUycwAq Z78gUE+kjjimH2fmXJd8XMkC9Ku+Vr/evWlyNM4= X-Google-Smtp-Source: ABhQp+QBruX9K3Ui/lMhVznj1QI6HXvytgW9oVC7ZRasYpvO1zwwk54Kzjo0tW3igwt+J3K2rC4M2yWW20FyTnk7zBs= X-Received: by 10.84.128.99 with SMTP id 90mr1867429pla.171.1509456259191; Tue, 31 Oct 2017 06:24:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.186.194 with HTTP; Tue, 31 Oct 2017 06:23:38 -0700 (PDT) In-Reply-To: <51079F6A-61C8-42E5-8658-FBC02B35A140@tzi.org> References: <51079F6A-61C8-42E5-8658-FBC02B35A140@tzi.org> From: Kathleen Moriarty Date: Tue, 31 Oct 2017 09:23:38 -0400 Message-ID: To: Carsten Bormann Cc: Samuel Erdtman , Hannes Tschofenig , "ace@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Ace] CWT - Audience 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, 31 Oct 2017 13:24:24 -0000 On Tue, Oct 31, 2017 at 6:55 AM, Carsten Bormann wrote: > On Oct 31, 2017, at 10:42, Samuel Erdtman wrote: >> >> My guess is that this is an early mistake that has not been noticed, it = has been like this from the first draft. > > I sure noticed the difference, but thought that this was an intended simp= lification: simply not allowing audiences with multiple strings. I believe it was an intentional change, but am sure Jim and others can clar= ify. Best, Kathleen > >> I think the correct thing would be to change it so that CWT reflects JWT= . > > So we get a choice between a text string and an array of text strings. > > Gr=C3=BC=C3=9Fe, Carsten > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace --=20 Best regards, Kathleen From nobody Tue Oct 31 07:32:59 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AD1613F3D7 for ; Tue, 31 Oct 2017 07:32:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=augustcellars.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vwQtT4QVVMfB for ; Tue, 31 Oct 2017 07:32:54 -0700 (PDT) Received: from mail4.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A55313B13B for ; Tue, 31 Oct 2017 07:32:54 -0700 (PDT) Content-Type: multipart/alternative; boundary="----=_NextPart_000_019E_01D3521A.73489400" Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1509460371; h=from:subject:to:date:message-id; bh=IO6SMOFXfWhCFxKyUZVe8KtT37ZPcFp2aVLooGLl4R0=; b=F0Ubdr8/HeLSJBiv6SCuFM498JlXHx7tPvRK/WJn84Nr2wOXjjoBq1Vc/x12WPzF/5RXYGOijam eUj+3uWCD0jePdGSOu3RZFR5wsC3UKLyYIF/8ln4CjWo27/q7AEMjYT4kpYg5plKh6LlU0PnndLLK NfpNBaoENNhDOLBzr6WFkCpMu7z/K8LDQ1lFuqnoTO4wec0Cuao3OO+9BPwT8FOaMUY6epBC7iQmr j5yriJGzW/0n0dBoXAm2a7TsTTyFvnxh2XZuySRy/xEkz1bcnlne6A1M/sI3uo7BKG1gmSUPIjGxQ dgy0ZM08bpMxC3813+K/gKmr7itZqfzX2Bbg== Received: from mail2.augustcellars.com (192.168.1.201) by mail4.augustcellars.com (192.168.1.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 31 Oct 2017 07:32:50 -0700 Received: from Hebrews (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 31 Oct 2017 07:31:48 -0700 From: Jim Schaad To: 'Samuel Erdtman' , 'Hannes Tschofenig' CC: References: In-Reply-To: Date: Tue, 31 Oct 2017 07:32:45 -0700 Message-ID: <019d01d35255$1fa17890$5ee469b0$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQFSevhVPrBfDpSPCIQPjAnsqXg8HwKipS/Mo+qe3zA= X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Ace] CWT - Audience 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, 31 Oct 2017 14:32:57 -0000 ------=_NextPart_000_019E_01D3521A.73489400 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable This was done because, in CBOR, there is a way to distinguish between a = string and a URL. This is lacking in JSON. I believe that the ability = to not have to determine this heuristically is a good thing. =20 Jim =20 =20 From: Ace [mailto:ace-bounces@ietf.org] On Behalf Of Samuel Erdtman Sent: Tuesday, October 31, 2017 2:42 AM To: Hannes Tschofenig Cc: ace@ietf.org Subject: Re: [Ace] CWT - Audience =20 My guess is that this is an early mistake that has not been noticed, it = has been like this from the first draft. I think the correct thing would be to change it so that CWT reflects = JWT. //Samuel =20 On Tue, Oct 31, 2017 at 10:27 AM, Hannes Tschofenig = > wrote: Hi all,=20 =20 in https://datatracker.ietf.org/doc/rfc7519/?include_text=3D1 (section = 4.1.3), =E2=80=9Caud=E2=80=9D is defined for JWT as being an array of = case-sensitive strings, or a single string. =20 In = https://datatracker.ietf.org/doc/draft-ietf-ace-cbor-web-token/?include_t= ext=3D1 (section 3.1.3), =E2=80=9Caud=E2=80=9D is defined for CWT as = being like in JWT, but =E2=80=9Cthe value is of type = StringOrURI=E2=80=9D.=20 =20 I was wondering how we arrived at this point where the CWT and the JWT = differ in this regard.=20 =20 Ciao Hannes =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 _______________________________________________ Ace mailing list Ace@ietf.org =20 https://www.ietf.org/mailman/listinfo/ace =20 ------=_NextPart_000_019E_01D3521A.73489400 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

This was = done because, in CBOR, there is a way to distinguish between a string = and a URL.=C2=A0 This is lacking in JSON.=C2=A0 I believe that the = ability to not have to determine this heuristically is a good = thing.

 

Jim

 

 

From: Ace = [mailto:ace-bounces@ietf.org] On Behalf Of Samuel = Erdtman
Sent: Tuesday, October 31, 2017 2:42 AM
To: = Hannes Tschofenig <Hannes.Tschofenig@arm.com>
Cc: = ace@ietf.org
Subject: Re: [Ace] CWT - = Audience

 

My guess is that this = is an early mistake that has not been noticed, it has been like this = from the first draft.

I think the correct thing would be to = change it so that CWT reflects JWT.

//Samuel

 

On Tue, = Oct 31, 2017 at 10:27 AM, Hannes Tschofenig <Hannes.Tschofenig@arm.com> = wrote:

Hi all,

 

in https://datatracker.ietf.org/doc/rfc7519/?include_text=3D= 1 (section 4.1.3), =E2=80=9Caud=E2=80=9D is defined for JWT as being = an array of case-sensitive strings, or a single = string.

 

In https://datatracker.ietf.org/doc/draft-ietf-ace-cbor-we= b-token/?include_text=3D1 (section 3.1.3), =E2=80=9Caud=E2=80=9D is = defined for CWT as being like in JWT, but =E2=80=9Cthe value is of type = StringOrURI=E2=80=9D.

 

I was wondering how we arrived at this point where the CWT = and the JWT differ in this regard.

 

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

 

------=_NextPart_000_019E_01D3521A.73489400-- From nobody Tue Oct 31 08:07:23 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0F5513F752 for ; Tue, 31 Oct 2017 08:07:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=augustcellars.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TMNBa3WS78Eb for ; Tue, 31 Oct 2017 08:07:09 -0700 (PDT) Received: from mail4.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0AD113F724 for ; Tue, 31 Oct 2017 08:06:15 -0700 (PDT) Content-Type: multipart/alternative; boundary="----=_NextPart_000_01A3_01D3521F.1B28AA30" Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1509462369; h=from:subject:to:date:message-id; bh=sPCQKEVW0337r5gyzV6bga/ngnMWi6Z+vnHxka0Fn3s=; b=f1GkBUaAG0QUYj+aV9Axd3Fk/uq8NQexIxl9WUNmgaoIyDcfiYTuQQkXPzb/XugSKgvlZLl5G1n o4Y/Qc8p2yLG1meBdgrp46WdRbemYgEiY1a/KDFPHJ7TWH5K2GGeUwFernvWhOG62kyv+QVsncyiy u37GFuZ+5AKcEUeZm88lxr6lhQlqm3dmvGtaJ4HZyOzyyK76/GLeX0+WjTHK1r6ahFvSOxVjWgiu3 psqWF0sMUCKtLlUutPgQU4OHKfAYA0VAdt9M8ww4S5wR/fRhDIWGE15+0H3Tkd5OdC79NAcAYA1ku gJsewwd5DTR9hSS9460Aq0raLEbTLQHgZOqg== Received: from mail2.augustcellars.com (192.168.1.201) by mail4.augustcellars.com (192.168.1.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 31 Oct 2017 08:06:09 -0700 Received: from Hebrews (192.168.1.162) by mail2.augustcellars.com (192.168.1.201) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 31 Oct 2017 08:05:08 -0700 From: Jim Schaad To: 'Hannes Tschofenig' , 'Samuel Erdtman' CC: References: In-Reply-To: Date: Tue, 31 Oct 2017 08:06:04 -0700 Message-ID: <01a201d35259$c782ee50$5688caf0$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQJTXYskp+9mg52Dr39FLCg22VrGxQHmAM62AbeTrO2h4QtjUA== X-Originating-IP: [192.168.1.162] Archived-At: Subject: Re: [Ace] CWT - Scope Claim 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, 31 Oct 2017 15:07:16 -0000 ------=_NextPart_000_01A3_01D3521F.1B28AA30 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I have an outstanding comment to the effect that I want a binary scope = value =E2=80=93 specifically to allow for a CBOR encoded object = =E2=80=93 on the framework document. =20 In terms of defining it in this document rather than in the framework, = my first response would be =E2=80=98no=E2=80=99 only because this was = designed to be a direct copy of the JWT document and it was not defined = there. Other than that I would not care one way or the other. =20 Jim =20 =20 From: Ace [mailto:ace-bounces@ietf.org] On Behalf Of Hannes Tschofenig Sent: Tuesday, October 31, 2017 2:58 AM To: Samuel Erdtman Cc: ace@ietf.org Subject: Re: [Ace] CWT - Scope Claim =20 Hi Samuel,=20 =20 You are correct that we should register it also with the JWT.=20 =20 Additionally, I wonder whether the string representation of the claim = for the CWT is the most efficient way to represent the scope. = Shouldn=E2=80=99t we rather use CBOR capabilities here since we are = trying to optimize 2 bytes in other areas?=20 =20 Ciao Hannes =20 From: Samuel Erdtman [mailto:samuel@erdtman.se]=20 Sent: 31 October 2017 10:46 To: Hannes Tschofenig Cc: ace@ietf.org =20 Subject: Re: [Ace] CWT - Scope Claim =20 The framework does register a CWT 'scoop' claim, but I think it has to = register it with JWT too to be correct. https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-08#section-8.5 =20 //Samuel =20 On Tue, Oct 31, 2017 at 10:28 AM, Hannes Tschofenig = > wrote: Hi all,=20 =20 I was wondering whether we should define a claim, scope, that captures = the scope that was granted by the authorization server.=20 =20 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.=20 _______________________________________________ Ace mailing list Ace@ietf.org =20 https://www.ietf.org/mailman/listinfo/ace =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 ------=_NextPart_000_01A3_01D3521F.1B28AA30 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

I have an = outstanding comment to the effect that I want a binary scope value = =E2=80=93 specifically to allow for a CBOR encoded object =E2=80=93 on = the framework document.

 

In terms of = defining it in this document rather than in the framework, my first = response would be =E2=80=98no=E2=80=99 only because this was designed to = be a direct copy of the JWT document and it was not defined there.=C2=A0 = Other than that I would not care one way or the = other.

 

Jim

 

 

From:<= /b> = Ace [mailto:ace-bounces@ietf.org] On Behalf Of Hannes = Tschofenig
Sent: Tuesday, October 31, 2017 2:58 = AM
To: Samuel Erdtman <samuel@erdtman.se>
Cc: = ace@ietf.org
Subject: Re: [Ace] CWT - Scope = Claim

 

Hi Samuel,

 

You are correct that we should register it also with the JWT. =

 

Additionally, I wonder whether the string representation of the claim = for the CWT is the most efficient way to represent the scope. = Shouldn=E2=80=99t we rather use CBOR capabilities here since we are = trying to optimize 2 bytes in other areas?

 

Ciao

Hannes

 

From: = Samuel Erdtman [mailto:samuel@erdtman.se] =
Sent: 31 October 2017 10:46
To: Hannes = Tschofenig
Cc: ace@ietf.org
Subject: Re: = [Ace] CWT - Scope Claim

 

The framework does register a CWT 'scoop' claim, but I = think it has to register it with JWT too to be = correct.

 

//Samuel

 

On Tue, Oct 31, 2017 at 10:28 AM, = Hannes Tschofenig <Hannes.Tschofenig@arm.com> = wrote:

Hi all,

 

I was wondering whether we should define a claim, scope, = that captures the scope that was granted by the authorization server. =

 

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

 

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. =

------=_NextPart_000_01A3_01D3521F.1B28AA30-- From nobody Tue Oct 31 08:50:25 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE40313A8A1 for ; Tue, 31 Oct 2017 08:50:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.911 X-Spam-Level: X-Spam-Status: No, score=-2.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, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WIcHR4Jw938T for ; Tue, 31 Oct 2017 08:50:21 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0051.outbound.protection.outlook.com [104.47.0.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6349613A292 for ; Tue, 31 Oct 2017 08:50:20 -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=K7w4TFiQwuYTjAWnitZEru1Xj83qeK9+S2H6kaTIzlQ=; b=kS50NepxEuzYBakcrJYXqO2few0q7hxVZ9mEiEwHoSHmviHx/XYnBFWTAZM/ZxsJvbgr6w2dFVes/kM0UqQ3DUyQ/HKx+BZAm5qgCVXt6knfmcIyF1/QWgyqJkzviK+k0jHnngY1mpgETjuCigxm1ms5PrKVCV5D/+VqvO9cOFk= Received: from AM4PR0801MB2706.eurprd08.prod.outlook.com (10.167.90.148) by AM4PR0801MB2705.eurprd08.prod.outlook.com (10.167.90.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.178.6; Tue, 31 Oct 2017 15:50:16 +0000 Received: from AM4PR0801MB2706.eurprd08.prod.outlook.com ([fe80::403b:850e:c32c:fad6]) by AM4PR0801MB2706.eurprd08.prod.outlook.com ([fe80::403b:850e:c32c:fad6%13]) with mapi id 15.20.0178.012; Tue, 31 Oct 2017 15:50:16 +0000 From: Hannes Tschofenig To: Kathleen Moriarty , Carsten Bormann CC: Samuel Erdtman , "ace@ietf.org" Thread-Topic: [Ace] CWT - Audience Thread-Index: AdNSKfI2hzHNo17WTjWo9b3jurhMrAAApmAAAAKOnIAABSv3AAAFDhsA Date: Tue, 31 Oct 2017 15:50:16 +0000 Message-ID: References: <51079F6A-61C8-42E5-8658-FBC02B35A140@tzi.org> 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: [81.18.200.28] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM4PR0801MB2705; 6:811auIiz8RLS94s8umwNRPJIWYI75WsWzj1Q9STF9HTIV7+nBXNezM/LEq8zAlDj9xXrRyqIm5trKe7L2drN6hLIzqJ9Avjc9jIwbO6BQuIZIOdMM0MjCZgTh7BnO7pt8Ldbbf4P/7Xhpkq2UeYuRjrh1uXN3rkLjc94RwS41Ui7Afmp8I+N0F9UmT0NQwrtwSfylOggkqCR4nv8CHPUcZx7Yu2aRAylNFASGEFP7VLtoall+ob1ba+gJTukBsx0QWUoevujwNFILmSEpO72r13eagW8o6Q35EyMDTasbJoa0mQYWAJ+PuNfWnLhI9r6F395kfG+iwcJmpehOyuTZ+v+/ywAZOLGbmpXrUcVV3s=; 5:dMrsSMejIwxpiqyJu7afHYtWku564mnyVLjwp7hqts1JDRTRSOvVL+KJ/F20s27USCZs/h3lLhG0hXA3+zX811X7kmh58qUyHlu8hB2y/yYFMlLyXyaGF+wkvi2uk3W+kIylQRn8PJbI8tmH/YFp3a0ayWgRC0JNz8sO5+gU+/k=; 24:wmH0HEGhtLI/7T7sQLWqgEWFxreLN8fRuIKZlsoXJssp1uHQN+FKePDQ7DOyRV3KOMm5CxWOMAbiuIPgXDCZo8Te7Aj7Iq21qe6Ai3FKnUU=; 7:19Q6lu/l9mJE6NJM+7vRpva1xtXpQukvV2M9hOHRbehZxApLM3yi5aHMECYE2SBLTpb2Vl2ltrrO/oEnPBWtAe99e20e4P25Tz7uHWbPgSQQPSJLif9H7dQv8o4G/mjKKUQLlLjbOsk9qNLVgsnM8Kywpi9j44V5mXze7pnyGMDwU/vS9uxZURI9q9MhAPbIWN792niaF7Srf+HQgdTC29QndGWihkIraEq14B+Ts1Y6bxT0xDPkEl8NoBPdwjSh x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: ce8c3a0e-76b0-4918-ad73-08d5207714cf x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081)(4534020)(4602075)(2017052603199); SRVR:AM4PR0801MB2705; x-ms-traffictypediagnostic: AM4PR0801MB2705: x-exchange-antispam-report-test: UriScan:; x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(100000703101)(100105400095)(10201501046)(3002001)(3231020)(93006095)(93001095)(6055026)(6041248)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123560025)(20161123564025)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM4PR0801MB2705; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM4PR0801MB2705; x-forefront-prvs: 04772EA191 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39860400002)(346002)(376002)(40434004)(199003)(189002)(7696004)(74316002)(101416001)(72206003)(9686003)(53936002)(25786009)(99286003)(55016002)(39060400002)(3846002)(105586002)(68736007)(2950100002)(478600001)(4326008)(102836003)(2900100001)(76176999)(2906002)(6246003)(106356001)(6116002)(189998001)(6506006)(3280700002)(3660700001)(316002)(33656002)(54356999)(50986999)(14454004)(86362001)(5660300001)(54906003)(110136005)(81156014)(8936002)(6436002)(8676002)(5250100002)(66066001)(81166006)(229853002)(97736004)(5890100001)(305945005)(7736002)(93886005); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR0801MB2705; H:AM4PR0801MB2706.eurprd08.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: ce8c3a0e-76b0-4918-ad73-08d5207714cf X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Oct 2017 15:50:16.4676 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR0801MB2705 Archived-At: Subject: Re: [Ace] CWT - Audience 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, 31 Oct 2017 15:50:24 -0000 PiA+IEkgc3VyZSBub3RpY2VkIHRoZSBkaWZmZXJlbmNlLCBidXQgdGhvdWdodCB0aGF0IHRoaXMg d2FzIGFuIGludGVuZGVkIHNpbXBsaWZpY2F0aW9uOiBzaW1wbHkgbm90IGFsbG93aW5nIGF1ZGll bmNlcyB3aXRoIG11bHRpcGxlIHN0cmluZ3MuDQo+IEkgYmVsaWV2ZSBpdCB3YXMgYW4gaW50ZW50 aW9uYWwgY2hhbmdlLCBidXQgYW0gc3VyZSBKaW0gYW5kIG90aGVycyBjYW4gY2xhcmlmeS4NCg0K VGhlIGRvd25zaWRlIG9mIHRoYXQgY2hhbmdlIGlzIHRoZSBmb2xsb3dpbmc6DQogKiBNaXNhbGln bm1lbnQgd2l0aCB0aGUgSldULCBhbmQNCiAqIElmIHlvdSB3YW50IHRvIHVzZSB0aGUgQ1dUIHRv a2VuIHdpdGggbXVsdGlwbGUgYXVkaWVuY2VzIHRoZW4geW91IGhhdmUgdG8gcmVxdWVzdCZjcmVh dGUgYSBuZXcgdG9rZW4gZm9yIGVhY2ggYXVkaWVuY2UuDQoNCkNpYW8NCkhhbm5lcw0KDQpJTVBP UlRBTlQgTk9USUNFOiBUaGUgY29udGVudHMgb2YgdGhpcyBlbWFpbCBhbmQgYW55IGF0dGFjaG1l bnRzIGFyZSBjb25maWRlbnRpYWwgYW5kIG1heSBhbHNvIGJlIHByaXZpbGVnZWQuIElmIHlvdSBh cmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBp bW1lZGlhdGVseSBhbmQgZG8gbm90IGRpc2Nsb3NlIHRoZSBjb250ZW50cyB0byBhbnkgb3RoZXIg cGVyc29uLCB1c2UgaXQgZm9yIGFueSBwdXJwb3NlLCBvciBzdG9yZSBvciBjb3B5IHRoZSBpbmZv cm1hdGlvbiBpbiBhbnkgbWVkaXVtLiBUaGFuayB5b3UuDQo= From nobody Tue Oct 31 10:28:22 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED3EB13FA05 for ; Tue, 31 Oct 2017 10:28:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4cdc0ZxlJ3uM for ; Tue, 31 Oct 2017 10:28:19 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0097.outbound.protection.outlook.com [104.47.34.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18EDF13F558 for ; Tue, 31 Oct 2017 10:28: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; bh=iizvOLjwpGb1Ohps5u8vWmYvxJo1E8nvU+nXE2vAy2A=; b=kUN+cp8rAs+mqbezV0pFPd7yL316GC8S06hI7AxMkU1YFbnk1gOFAgAsQP3e5NlLDqpnMQvlxZVoZjDXxWovrpylx/VNKh9UmGipfhHo97afINrLTeDNNHrBsSFwSStbt0ifVgdXjIhEBIHIl1wCOTJyw3HhLoPmYUWT/HLYK3s= Received: from CY4PR21MB0504.namprd21.prod.outlook.com (10.172.122.14) by CY4PR21MB0822.namprd21.prod.outlook.com (10.173.192.8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.218.4; Tue, 31 Oct 2017 17:28:17 +0000 Received: from CY4PR21MB0504.namprd21.prod.outlook.com ([10.172.122.14]) by CY4PR21MB0504.namprd21.prod.outlook.com ([10.172.122.14]) with mapi id 15.20.0218.004; Tue, 31 Oct 2017 17:28:17 +0000 From: Mike Jones To: Hannes Tschofenig , Kathleen Moriarty , Carsten Bormann CC: Samuel Erdtman , "ace@ietf.org" Thread-Topic: [Ace] CWT - Audience Thread-Index: AdNSKfI2hzHNo17WTjWo9b3jurhMrAAApmAAAAKOnIAABSv3AAAFDhsAAANWy+A= Date: Tue, 31 Oct 2017 17:28:16 +0000 Message-ID: References: <51079F6A-61C8-42E5-8658-FBC02B35A140@tzi.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.47.85.199] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR21MB0822; 6:8hFGT5p6XtiwyX6EQPUOv7FRd29XKIOUUN0EzjETpqHY9c7vZAskeVsiduKGS9bMTfT7HNCIEGbcUlOpq/o/C/7vf02Oj1CeVNqpxObPK+EiyZemb21I3qmvzLuhSdoSN+kRI+mAmqm+yGNJeffwvIawlZgY63Eud9ep+P6dSAkpUxfbY3IFKjYupwkZqIgBF+DWF7n/+Bs5Fmv/8iQSXYp+dgsbPSn9a+SJZ+VAoIiP3wlafn3eydkFPQZznYbloSm9PxeEo9Nt7mEoH7/vOwZCFek6dkIl9lijkFWmRrMdLEDwUb55Yy3VcX3fmDZOpo+XQB79Ko0V4mJcc338k2p6oQASh3xsRHBH2S4g9k4=; 5:6sDj+Cb0QjNj59oRQdL4kuvAoKgnTRumvMTOLcSSOqnWxqJtE6yqO4zcA0PSBRmbxkIo/PsU7GSYDmJY/a0USzhTwaac4h8UJRDC8Vxj6nj5LeYLKXhSHYQcoI06fmxLYAVVxlyKuVpT8sHZmgK4ouojdX0lD8PxI5Psj1L4IgA=; 24:ItXQp+zkS/CRlH0duq7x7ItsY6Azk4tAiBrZrj3bstKffMrVLdvLJyCH6VUnV6i6uaYLWI72r0YQzQ8FAY69cF/a4+PFX4TZufYaPGPZLQs=; 7:Aq9PqpjqKl+cE3ybGGZRapoUu027mE8j7JolRJxOLKGG+igf/4+um6z7ILTzhG5/Xcr5bRAtnD/VcV2Zbvfac9RRZ+pEybrnHHGs8jDjetouOV8xyEbs8JtIlJcWuM6d2r9e5iipoQv0oY5MksyZWbb7rSrGmBUuJr9Ss+cQsOKueoFaLRjN7XAd5Bv3IW3GrpYzx9FJbFTHnbJ9rV0VQqEYCufoqK1yku6gGdSaB+ouhcU/NMDLHVRg7oZLMjr1 x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 342a1d74-afc9-44c9-c69d-08d52084c5f3 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081)(4534020)(4602075)(2017052603238); SRVR:CY4PR21MB0822; x-ms-traffictypediagnostic: CY4PR21MB0822: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-ld-processed: 72f988bf-86f1-41af-91ab-2d7cd011db47,ExtAddr x-exchange-antispam-report-test: UriScan:; x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(2401047)(5005006)(8121501046)(10201501046)(3231020)(93006095)(93001095)(100000703101)(100105400095)(3002001)(6055026)(61426038)(61427038)(6041248)(20161123562025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123560025)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR21MB0822; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR21MB0822; x-forefront-prvs: 04772EA191 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(376002)(346002)(47760400005)(189002)(40434004)(13464003)(199003)(50986999)(76176999)(4326008)(229853002)(8990500004)(3846002)(6246003)(102836003)(6116002)(101416001)(66066001)(25786009)(53546010)(3660700001)(14454004)(33656002)(39060400002)(68736007)(53936002)(54356999)(81166006)(2950100002)(81156014)(8676002)(86612001)(5890100001)(9686003)(6306002)(8936002)(966005)(86362001)(10290500003)(3280700002)(99286003)(55016002)(7696004)(2906002)(189998001)(305945005)(54906003)(72206003)(5660300001)(7736002)(97736004)(110136005)(105586002)(106356001)(77096006)(22452003)(478600001)(74316002)(316002)(10090500001)(6436002)(6506006)(2900100001)(93886005); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0822; H:CY4PR21MB0504.namprd21.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 342a1d74-afc9-44c9-c69d-08d52084c5f3 X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Oct 2017 17:28:16.9777 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0822 Archived-At: Subject: Re: [Ace] CWT - Audience 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, 31 Oct 2017 17:28:22 -0000 Not having support for multiple audiences is semantically a non-starter. T= here are some differences in CWT from JWT that are intentional (such as bin= ary key IDs) to better align CWT with COSE, but this particular divergence = is unacceptable. My conclusion is that I will need read CWT line-by-line before Singapore an= d compile a list of such problems that have somehow made it into the spec. = I was (apparently naively) assuming it was aligned, but apparently that's = not the case. Thanks for catching this, Hannes! -- Mike -----Original Message----- From: Ace [mailto:ace-bounces@ietf.org] On Behalf Of Hannes Tschofenig Sent: Tuesday, October 31, 2017 8:50 AM To: Kathleen Moriarty ; Carsten Bormann <= cabo@tzi.org> Cc: Samuel Erdtman ; ace@ietf.org Subject: Re: [Ace] CWT - Audience > > I sure noticed the difference, but thought that this was an intended si= mplification: simply not allowing audiences with multiple strings. > I believe it was an intentional change, but am sure Jim and others can cl= arify. The downside of that change is the following: * Misalignment with the JWT, and * If you want to use the CWT token with multiple audiences then you have t= o request&create a new token for each audience. 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. _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace From nobody Tue Oct 31 13:09:05 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A32713F5F3 for ; Tue, 31 Oct 2017 13:09:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z1PcqwxZ7IKU for ; Tue, 31 Oct 2017 13:09:01 -0700 (PDT) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0122.outbound.protection.outlook.com [104.47.41.122]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C4B013F5D3 for ; Tue, 31 Oct 2017 13:09:01 -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=dRzWKjc7oTYPDBJapA0eAGIuWyss/w6/QjG7fn0pvaw=; b=B1auyhCqP+1lUOOa3s2LmsNdB2ZwiR+eBcjSfYaqg8Wt0QyobHSkQK9WGP6h/LwVNzVqqYbuIe4XftIBnkpUVHEGhdpkOrUI6g85w9s02mEBCgRO38CLNYAzTfs+7YJwy4fXoC4d/wphV1zP02x8GP9NC4a8DZv9ORHRnfmhepk= Received: from CY4PR21MB0504.namprd21.prod.outlook.com (10.172.122.14) by CY4PR21MB0165.namprd21.prod.outlook.com (10.173.192.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.218.2; Tue, 31 Oct 2017 20:08:59 +0000 Received: from CY4PR21MB0504.namprd21.prod.outlook.com ([10.172.122.14]) by CY4PR21MB0504.namprd21.prod.outlook.com ([10.172.122.14]) with mapi id 15.20.0218.004; Tue, 31 Oct 2017 20:08:59 +0000 From: Mike Jones To: Hannes Tschofenig , 'Samuel Erdtman' , Jim Schaad CC: "ace@ietf.org" Thread-Topic: [Ace] CWT - Scope Claim Thread-Index: AdNSKjCCGBNCG3i0QYKnEExRCZfMRgAAuTmAAABY/fAACtL+AAAKlDIG Date: Tue, 31 Oct 2017 20:08:58 +0000 Message-ID: References: , <01a201d35259$c782ee50$5688caf0$@augustcellars.com> In-Reply-To: <01a201d35259$c782ee50$5688caf0$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [104.208.33.187] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR21MB0165; 6:3nniElq9aLa6De7CmQIiwnXipRYQvLW0s0S6hQcD3h1n2kt6NOERfWZxDnIN4zp+cfoDFKRk0MXJXVIgPOQDLW4eT07JLgTnCxHBtysEXUq71l/oG/AINBRQcnr90K9kgrqyDONjoKoxB9QSxMMWnhOv1Mq+GYCZBE5y46ZJxaT68kLWyrQCqKzT93xHPKSRs5Zcm2lD8uwg/FRif6m86d+3N1V416vizBQxmshdJx6cGyuxh1J+ovgeP+a5GDlpKHeEUDyw1NUFgbOM61JvsFn5M9/x7E4gHvjuWKCZbKT7bjEMmkBh+3h211TelhiMMoNriTmhqBgHVt8mlN2vtYhKvgGsn1366BQjBs1F6vU=; 5:WpHsk9CJF5p1/xbinksRb2nRe2ZttBPlhfPiaFy4dDi6umGQlbSoDfmDTU21EfULYGeb/ynqQiS0jKi4tHdOfMQ6zTDfhThVv6WG2CenqvTf0WW+7QRczgGstGymlZC1JDi0RGSJ+3lzrMDYh7IuF6pSIb2830dd468xXcWiB4s=; 24:LhXc2lFAojtV95JefCcmPI8MnT6lcx8H+d1QHBUENmBlL2T7TYZN+KpEoVETmfjESbwu2g3fmbg7pSKUzveOC1Yqlp2m74NP5wXbbXBDSMs=; 7:cTiQbwbqX8Ij9/NKPYW7N5nyf0XpUmMRqffT39hyqjn4SlgWAR12zR+b9fyRLwfVrIyUWFntOCYf7V/m1QZZY9rFIN4bfbpG08QZ4EARWzlqD8tvGtmMo+19Whtxi6eE0FSHcQfWciJ35Uk0Nhb0XrPGQFHujmiIO9+aZhl90aGHRyWH9KSM4IKCC3Ju+jMxVEv3ZbAhAMHJNj+shCGAI06OQhcNq8+zBkS5RKY9E3fS2vtUJ+C7VJ2V2Vw0OYPn x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 2ed1ccb5-a9bc-41e3-57c7-08d5209b3901 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081)(4534020)(4602075)(2017052603238); SRVR:CY4PR21MB0165; x-ms-traffictypediagnostic: CY4PR21MB0165: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-ld-processed: 72f988bf-86f1-41af-91ab-2d7cd011db47,ExtAddr x-exchange-antispam-report-test: UriScan:(180628864354917); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(100000703101)(100105400095)(3002001)(3231020)(6055026)(61426038)(61427038)(6041248)(20161123560025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123558100)(20161123555025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR21MB0165; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR21MB0165; x-forefront-prvs: 04772EA191 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(346002)(376002)(47760400005)(40434004)(53754006)(24454002)(189002)(199003)(6306002)(9686003)(6436002)(6506006)(7736002)(54896002)(236005)(77096006)(74316002)(86612001)(86362001)(55016002)(99286003)(3660700001)(3280700002)(2906002)(10090500001)(93886005)(14454004)(66066001)(68736007)(2900100001)(6116002)(4326008)(102836003)(50986999)(76176999)(229853002)(8936002)(105586002)(54356999)(106356001)(3846002)(6246003)(53936002)(81166006)(8676002)(101416001)(81156014)(10290500003)(5660300001)(189998001)(2950100002)(33656002)(478600001)(7696004)(25786009)(5890100001)(53546010)(110136005)(8990500004)(72206003)(97736004)(22452003)(966005)(316002)(606006); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0165; H:CY4PR21MB0504.namprd21.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR21MB0504F181CE5086810CC36661F55E0CY4PR21MB0504namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2ed1ccb5-a9bc-41e3-57c7-08d5209b3901 X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Oct 2017 20:08:58.9483 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0165 Archived-At: Subject: Re: [Ace] CWT - Scope Claim 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, 31 Oct 2017 20:09:04 -0000 --_000_CY4PR21MB0504F181CE5086810CC36661F55E0CY4PR21MB0504namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I agree that CWT shouldn't define claims beyond those that correspond to th= e JWT claims. Other specs can do that via the registry established for tha= t purpose. -- Mike ________________________________ From: Ace on behalf of Jim Schaad Sent: Tuesday, October 31, 2017 8:06:04 AM To: Hannes Tschofenig; 'Samuel Erdtman' Cc: ace@ietf.org Subject: Re: [Ace] CWT - Scope Claim I have an outstanding comment to the effect that I want a binary scope valu= e =96 specifically to allow for a CBOR encoded object =96 on the framework = document. In terms of defining it in this document rather than in the framework, my f= irst response would be =91no=92 only because this was designed to be a dire= ct copy of the JWT document and it was not defined there. Other than that = I would not care one way or the other. Jim From: Ace [mailto:ace-bounces@ietf.org] On Behalf Of Hannes Tschofenig Sent: Tuesday, October 31, 2017 2:58 AM To: Samuel Erdtman Cc: ace@ietf.org Subject: Re: [Ace] CWT - Scope Claim Hi Samuel, You are correct that we should register it also with the JWT. Additionally, I wonder whether the string representation of the claim for t= he CWT is the most efficient way to represent the scope. Shouldn=92t we rat= her use CBOR capabilities here since we are trying to optimize 2 bytes in o= ther areas? Ciao Hannes From: Samuel Erdtman [mailto:samuel@erdtman.se] Sent: 31 October 2017 10:46 To: Hannes Tschofenig Cc: ace@ietf.org Subject: Re: [Ace] CWT - Scope Claim The framework does register a CWT 'scoop' claim, but I think it has to regi= ster it with JWT too to be correct. https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-08#section-8.5 //Samuel On Tue, Oct 31, 2017 at 10:28 AM, Hannes Tschofenig > wrote: Hi all, I was wondering whether we should define a claim, scope, that captures the = scope that was granted by the authorization server. 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. _______________________________________________ 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_CY4PR21MB0504F181CE5086810CC36661F55E0CY4PR21MB0504namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
I agree that CWT shouldn't define claims beyond those that correspond to th= e JWT claims.  Other specs can do that via the registry established fo= r that purpose.

-- Mike
From: Ace <ace-bounces@i= etf.org> on behalf of Jim Schaad <ietf@augustcellars.com>
Sent: Tuesday, October 31, 2017 8:06:04 AM
To: Hannes Tschofenig; 'Samuel Erdtman'
Cc: ace@ietf.org
Subject: Re: [Ace] CWT - Scope Claim
 

I have an outstanding comment to the effect that I= want a binary scope value =96 specifically to allow for a CBOR encoded obj= ect =96 on the framework document.

 

In terms of defining it in this document rather th= an in the framework, my first response would be =91no=92 only because this = was designed to be a direct copy of the JWT document and it was not defined there.  Other than that I would not care one w= ay or the other.

 

Jim

 

 

From: Ace [mailto:ace-bounces@ietf= .org] On Behalf Of Hannes Tschofenig
Sent: Tuesday, October 31, 2017 2:58 AM
To: Samuel Erdtman <samuel@erdtman.se>
Cc: ace@ietf.org
Subject: Re: [Ace] CWT - Scope Claim

 

Hi Samuel,

 

You are correct that= we should register it also with the JWT.

 

Additionally, I wond= er whether the string representation of the claim for the CWT is the most e= fficient way to represent the scope. Shouldn=92t we rather use CBOR capabilities here since we are trying to optimize 2 bytes = in other areas?

 

Ciao

Hannes

 

From: Samuel Erdtman [mailto:samuel@erdtman.se]
Sent: 31 October 2017 10:46
To: Hannes Tschofenig
Cc: ace@ietf.org
Subject: Re: [Ace] CWT - Scope Claim

 

The framework does register a C= WT 'scoop' claim, but I think it has to register it with JWT too to be corr= ect.

 

//Samuel

 

On Tue, Oct 31, 2017 at 10:28 A= M, Hannes Tschofenig <Hannes.Tschofenig@arm.com> wrote:

Hi all,

 

I was wondering whet= her we should define a claim, scope, that captures the scope that was grant= ed by the authorization server.

 

Ciao

Hannes

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

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

 

IMPORTANT NOTICE: The contents of t= his 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 perso= n, use it for any purpose, or store or copy the information in any medium. = Thank you.

--_000_CY4PR21MB0504F181CE5086810CC36661F55E0CY4PR21MB0504namp_--