Re: [Ace] AD review of draft-ietf-ace-cwt-proof-of-possession-06
Mike Jones <Michael.Jones@microsoft.com> Mon, 26 August 2019 19:32 UTC
Return-Path: <Michael.Jones@microsoft.com>
X-Original-To: ace@ietfa.amsl.com
Delivered-To: ace@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CE52120D4C; Mon, 26 Aug 2019 12:32:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level:
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 0ZXEJ33h0Gm4; Mon, 26 Aug 2019 12:32:54 -0700 (PDT)
Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-bl2nam06on070c.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe55::70c]) (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 877C2120CAA; Mon, 26 Aug 2019 12:32:54 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jjKVnPdwuGmJY1/d1Y3525moeaQ37NkNP2jr/8DXtWkrirmA/Qx/OwIGy0sfckaX6o8/qY+fY7bgLIRZgZtQAkquh3rTU98edDZqTwwngoJj0N9IKwy52Q28qE5cfkR1o1UiG1T0qpsLBEKG7tEIleHXu19i5r99XFGY2HZG3WwfT0tbmHWUkW5Aj9xZtQO9/1fPzFNcJhsByMc1fFexiiGGXwZ9GgubW4AftkkH1DPsV7nggT7UwuCk8FCZ/6KdiJHKtU5eoFhctexrIc0j0jIApi5f33FyaNngxAHMOLh6MpYZHbhf3IUpFAdPqVxJCKE0YLEWqwhjcNsUy3Hldw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9gQZZ08CKvo2wPion08khP7gH73D3geIvApfotkzEak=; b=hrzjdVnsZffW4wanV2cBkgObXPxZnHRira2q2Uykozxj+aYVkF/IBi5fndGCz49UQODhXjDX1DYvZ9X7UfUylRtNisOsHKwD3C9kws1DBgmuVNSHo3ccu92RVCcdgQUnZtajWmeRv5ma4ocp7UUqaWhG5xPo8uwtfvliIbg4FFg+TkscI/Q378Fdrvaa+6AD1qZU/67Dnx6Ip0yglqhn7iMg9lnn9inMqf/+mNxg+5x3e5we1gqJ3SK92hLTqU4M2VZBaPBS9/tIcoznLSUvYRS3D5heU17D2uKTA8F3G7Yh4vkes4go5vftfTL0ivb2iXK4CARpVuS/30ZqAh+Jew==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9gQZZ08CKvo2wPion08khP7gH73D3geIvApfotkzEak=; b=Vh92hiDTo/Z1K1DAiqKEbnfLRZ2GVlFhsToIZ2xDJIeS5iCJmRFdnMhhBaKFFQI/zBKav8HpFnxvDMzh2TfvVKoFoZ01memvZlNIFYP1r4TdEa56mGiBcb60Fe21tvGKh7kMbrhaPngZcdq9bs0mHbosam7GW2CyKHqU5V8Slas=
Received: from MN2PR00MB0576.namprd00.prod.outlook.com (20.178.255.149) by MN2PR00MB0591.namprd00.prod.outlook.com (20.178.255.214) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2247.0; Mon, 26 Aug 2019 19:32:51 +0000
Received: from MN2PR00MB0576.namprd00.prod.outlook.com ([fe80::a528:2b96:5985:afa5]) by MN2PR00MB0576.namprd00.prod.outlook.com ([fe80::a528:2b96:5985:afa5%2]) with mapi id 15.20.2252.000; Mon, 26 Aug 2019 19:32:51 +0000
From: Mike Jones <Michael.Jones@microsoft.com>
To: Ludwig Seitz <ludwig.seitz@ri.se>, Benjamin Kaduk <kaduk@mit.edu>
CC: "draft-ietf-ace-cwt-proof-of-possession.all@ietf.org" <draft-ietf-ace-cwt-proof-of-possession.all@ietf.org>, "ace@ietf.org" <ace@ietf.org>
Thread-Topic: AD review of draft-ietf-ace-cwt-proof-of-possession-06
Thread-Index: AQHVW9kaB1+XuR4ZckeQMuWF4nKDoKcN0lBw
Date: Mon, 26 Aug 2019 19:32:50 +0000
Message-ID: <MN2PR00MB0576CF49F06A74D5FCBA79FBF5A10@MN2PR00MB0576.namprd00.prod.outlook.com>
References: <20190730155605.GM47715@kduck.mit.edu> <92fc4816-3447-62e3-e2fa-e6d92ea772e3@ri.se> <20190812231518.GF88236@kduck.mit.edu> <caa055a8-cc1a-7341-3f5c-5c988056de45@ri.se>
In-Reply-To: <caa055a8-cc1a-7341-3f5c-5c988056de45@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_ActionId=90250857-2a8b-4684-bddf-0000d6de693b; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2019-08-26T19:32:33Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47;
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com;
x-originating-ip: [50.47.93.218]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 507c3b4c-3544-4fc8-919e-08d72a5c2f0c
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600166)(711020)(4605104)(1401327)(4618075)(2017052603328)(7193020); SRVR:MN2PR00MB0591;
x-ms-traffictypediagnostic: MN2PR00MB0591:
x-ms-exchange-purlcount: 8
x-microsoft-antispam-prvs: <MN2PR00MB05913A10AECB3F4E4C13F768F5A10@MN2PR00MB0591.namprd00.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 01415BB535
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(366004)(376002)(136003)(396003)(39860400002)(346002)(13464003)(199004)(189003)(22452003)(8936002)(66066001)(71200400001)(71190400001)(316002)(256004)(81156014)(8676002)(14444005)(81166006)(8990500004)(486006)(11346002)(446003)(33656002)(7696005)(76176011)(99286004)(86362001)(186003)(6506007)(476003)(102836004)(26005)(53546011)(66574012)(2906002)(9686003)(6306002)(55016002)(229853002)(6436002)(74316002)(10290500003)(5660300002)(966005)(478600001)(14454004)(52536014)(66946007)(4326008)(66446008)(305945005)(66476007)(66556008)(64756008)(6116002)(3846002)(7736002)(76116006)(25786009)(2171002)(10090500001)(6246003)(54906003)(110136005)(53936002); DIR:OUT; SFP:1102; SCL:1; SRVR:MN2PR00MB0591; H:MN2PR00MB0576.namprd00.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: UIYvqoafpXMBGvaAIzXxig2BvaYOZomEwVykyNOHiGHdXVy90Hu0PcLdtoljjsG4TrUzn6GZwx+VVJ2SAEnm/x9l7PAnABqmMP4MM/b6TIkNskYf9EBA4di6tAOR0K/t6p2tUpcJsDRMYO5j5PCbPQNzW03O+SmKu3BEQHYJaCBdIbVzo4pHibyxWLzcZzMUtKaRUs9o6180CxM2Vzq4K8QbF5ziFol5NKOgdFn6IJuw4Pe2haGo7C9Eq5jkROt+GFuECiM8EOBx0rG7lbhfcFK2gnphdXARz1GvhlFa6/GnBldRb8JICas/7Ljs2+K4jai1CVz/Y22LzbN1tsddPeGXJzTMG0B0wqyd5zP4cvgUvk2U/ETixi9PyWEp8KBI4fgZKOHL3BRU499xEN0h8jmZPlvOazt4VcP+I3Q4Sk0=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 507c3b4c-3544-4fc8-919e-08d72a5c2f0c
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Aug 2019 19:32:50.8546 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: EI6sUYaYnChiF5sShHp6dWJjYhuxYeOsPwDClM1qg/3j9DiMuaWLmgev116XaChjj4ZSI2tBLO7ogp9PZtW0Ng==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR00MB0591
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/2DvElISLLFBgiJdJIbeUvePRdGo>
Subject: Re: [Ace] AD review of draft-ietf-ace-cwt-proof-of-possession-06
X-BeenThere: ace@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" <ace.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ace>, <mailto:ace-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ace/>
List-Post: <mailto:ace@ietf.org>
List-Help: <mailto:ace-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ace>, <mailto:ace-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 26 Aug 2019 19:32:58 -0000
Please see my review of the PR, Ludwig. -----Original Message----- From: Ludwig Seitz <ludwig.seitz@ri.se> Sent: Sunday, August 25, 2019 11:40 PM To: Benjamin Kaduk <kaduk@mit.edu> Cc: draft-ietf-ace-cwt-proof-of-possession.all@ietf.org; ace@ietf.org Subject: Re: AD review of draft-ietf-ace-cwt-proof-of-possession-06 Hi Ben, fixed more of your comments here: https://github.com/cwt-cnf/i-d/pull/24 (waiting for Mike to double-check and merge them). As for those that are still open, comments are inline. /Ludwig On 13/08/2019 01:15, Benjamin Kaduk wrote: >>> The "COSE_Key" member MAY also be used for a COSE_Key representing a >>> symmetric key, provided that the CWT is encrypted so that the key is >>> not revealed to unintended parties. The means of encrypting a CWT is >>> explained in [RFC8392]. If the CWT is not encrypted, the symmetric >>> key MUST be encrypted as described in Section 3.3. >>> >>> It's hard for me to escape the conclusion that this paragraph needs to >>> be a dedicated section with a bit more discussion about how exactly this >>> usage is performed and encoded. >>> >> >> This mirrors the corresponding procedure in RFC 7800. Would it be OK to >> just refer to that document >> (https://tools.ietf.org/html/rfc7800#section-3 or actually 3.3)? > > (Section 3.2, it seems -- JWT and CWT cover aysmmetric and symmetric in > the opposite order.) > Well, I still wouldn't like it. But I don't think I have grounds to block > the document from advancing if you just refer back to JWT. > Göran and I have discussed this, and we agree that it is indeed underspecified (e.g. which key is used to encrypt this "inner" COSE_Encrypt0 contained in the cnf element?). Additionally I can personally confirm that this is a headache to implement (and I haven't even touched a constrained implementation). We see two alternatives here: 1.) Remove the possibility to have a separate encrypted cnf element. Instead mandate that the whole CWT should be encrypted if it contains a secret key. + make spec easier (to implement) and doesn't requires a long specification on how to handle this case - breaks direct equivalence with RFC 7800 2.) Add some dedicated section that explains how the key for this inner encrypted cnf element is selected and communicated to the RS. + The draft remains functionally equivalent to RFC 7800 - Increased draft complexity at questionable gain - Possible implementer headaches, especially on constrained devices There is an issue about this here: https://github.com/cwt-cnf/i-d/issues/19 >>> The following example CWT Claims Set of a CWT (using CBOR diagnostic >>> notation, with linebreaks for readability) illustrates the use of an >>> encrypted symmetric key as the "Encrypted_COSE_Key" member value: >>> >>> { >>> /iss/ 1 : "coaps://server.example.com", >>> /sub/ 2 : "24400320", >>> /aud/ 3: "s6BhdRkqt3", >>> /exp/ 4 : 1311281970, >>> /iat/ 5 : 1311280970, >>> /cnf/ 8 : { >>> /COSE_Encrypt0/ 2 : [ >>> >>> Should this be "/Encrypted_COSE_Key/" and not "/COSE_Enrypt0/"? >>> >>> [I did not validate the COSE_Encrypt0 output] >>> >> >> COSE_Encrypt0 is a defined construct of COSE, while Encrypted_COSE_Key >> is not. We'd have to define it or write an explanatory comment. > > Maybe I'm confused about how the diagnostic notation works, but the > top-level CWT map key name ("claim") is "Encrypted_COSE_Key", as matches > iss/sub/aud/etc. in the preceding notation. If the rules are different for > map keys whose corresponding values are themselves structured data types, > then I should just unconfuse myself and we can move on with things... > > Issue created here https://github.com/cwt-cnf/i-d/issues/20 Will fix. >> >>> o A recipient can decide not to use a CWT based on a created Key ID >>> if it does not fit the recipient's requirements. >>> >>> I'm not sure I understand the semantics being described here. Are we >>> saying that the issuer might give a presenter a CWT, and by the time the >>> presenter presents the CWT to the recipient, the recipient says "this is >>> no good" and denies the transaction in question, forcing the presenter >>> to go back to the issuer and try again? (How do we know that the issuer >>> would make any different choices the second time around?) >> >> This risk always exists. In a constrained device world, the recipient >> may already have cleared out the key referenced by the key ID, which >> would force it to reject a CWT using this as proof-of-possession. >> >> I'm not sure how to give good guidance in this case. The error message >> delivered by the recipient rejecting the CWT might be helpful I suppose. >> Do you think this merits some text? > > It's not entirely clear to me that we need to add more text here, but if we > did, it would focus on what "decide not to use" means at a protocol level, > and perhaps how the CWT might not "fit the recipient's requirements" (e.g., > the key id having fallen out of cache as you describe). Issue created here: https://github.com/cwt-cnf/i-d/issues/21 Will fix. >> >>> from changing any elements conveyed within the CWT payload. Special >>> care has to be applied when carrying symmetric keys inside the CWT >>> since those not only require integrity protection but also >>> confidentiality protection. >>> >>> Do we want to reiterate the common mechanisms for providing >>> confidentiality protection here, or just leave the existing text earlier >>> in the document to cover it? >>> >> Doesn't it say a few sentences before: "it is >> necessary to apply data origin authentication and integrity >> protection (via a keyed message digest or a digital signature)." ? >> >> I would consider this to be enough. > > That doesn't cover the *confidentiality* protection, specifically. (So it > seems the answer to my original question is still unclear, at least to me.) > Issue created here: https://github.com/cwt-cnf/i-d/issues/22 Will fix. > >>> Section 6 >>> >>> ensure correct processing. The recipient needs to be able to use >>> credentials to verify the authenticity, integrity, and potentially >>> the confidentiality of the CWT and its content. This requires the >>> >>> Just from a rhetorical point of view, can you help me understand how >>> credentials would be used to verify the confidentiality of a CWT? It >>> seems like this depends on either (or both of) how the CWT is >>> transmitted or how it is prepared, and I am not sure how the recipient's >>> credentials come into play. >>> >> >> This text is referring to the issuer's credentials (e.g. the >> Authorization Server issuing the CWT), that the recipient needs to >> verify the CWT. Do you want us to clarify this sentence? > > Note that I was specifically asking about "potentially the > confidentiality"; I don't understand the intended workflow for verification > of confidentiality (and thus which credentials are involved). I don't > really see how a credential held solely by the issuer could proide > confidentiality protection when it needs to be understood by some other > protocol participant. Issue created here: https://github.com/cwt-cnf/i-d/issues/23 Will fix. >>> Section 7 >>> >>> Criteria that should be applied by the Designated Experts include >>> determining whether the proposed registration duplicates existing >>> functionality, determining whether it is likely to be of general >>> applicability or whether it is useful only for a single application, >>> and evaluating the security properties of the item being registered >>> and whether the registration makes sense. >>> >>> I know we've been using (variations of) this text for a while, but it >>> seems to me that it could be more clear than it currently is -- is >>> duplication of functionality grounds for denial of registration? What >>> about general vs. specific applicability? The latter seems more clearly >>> applicable for determining which range from which to allocate, since >>> that has impact on the encoding size. Can the experts insist on updates >>> to the security considerations text of a specification prior to granting >>> approval, or are they limited to denying registration of values with >>> poor security properties or insufficient documentation thereof? >>> >> >> I'm too unfamiliar with the designated expert system to provide a good >> answer on this one. Can one of my co-authors chip in here? >> Issue created here: https://github.com/cwt-cnf/i-d/issues/25 Will fix. -- Ludwig Seitz, PhD Security Lab, RISE Phone +46(0)70-349 92 51
- [Ace] AD review of draft-ietf-ace-cwt-proof-of-po… Benjamin Kaduk
- Re: [Ace] AD review of draft-ietf-ace-cwt-proof-o… Jim Schaad
- Re: [Ace] AD review of draft-ietf-ace-cwt-proof-o… Carsten Bormann
- Re: [Ace] AD review of draft-ietf-ace-cwt-proof-o… Benjamin Kaduk
- Re: [Ace] AD review of draft-ietf-ace-cwt-proof-o… Jim Schaad
- Re: [Ace] AD review of draft-ietf-ace-cwt-proof-o… Ludwig Seitz
- Re: [Ace] AD review of draft-ietf-ace-cwt-proof-o… Carsten Bormann
- Re: [Ace] AD review of draft-ietf-ace-cwt-proof-o… Benjamin Kaduk
- Re: [Ace] AD review of draft-ietf-ace-cwt-proof-o… Ludwig Seitz
- Re: [Ace] AD review of draft-ietf-ace-cwt-proof-o… Ludwig Seitz
- Re: [Ace] AD review of draft-ietf-ace-cwt-proof-o… Jim Schaad
- Re: [Ace] AD review of draft-ietf-ace-cwt-proof-o… Mike Jones
- Re: [Ace] AD review of draft-ietf-ace-cwt-proof-o… Ludwig Seitz