From nobody Sun Aug 4 11:46:41 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5497A120047 for ; Sun, 4 Aug 2019 11:46:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aXG2hM0PPp0U for ; Sun, 4 Aug 2019 11:46:38 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AF55120033 for ; Sun, 4 Aug 2019 11:46:38 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Sun, 4 Aug 2019 11:46:32 -0700 From: Jim Schaad To: Date: Sun, 4 Aug 2019 11:46:29 -0700 Message-ID: <02f401d54af4$ef450050$cdcf00f0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AdVK8Oc4dYRNXiLZStCJZw0G1K4U/Q== X-Originating-IP: [73.180.8.170] Archived-At: Subject: [Ace] When does a KDC need to roll the keys over X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Aug 2019 18:46:40 -0000 I have been writing down some logic to deal with when KDC needs to change epochs. This is in part because I need to figure out what should be constant and what needs to be exposed in the user interface for configuration purposes. Some of the inputs are pretty easy to see such as: If X amount of time has passed then do a key roll over or, Don't roll keys over if less than Y time has passed. Some of the checks can get really weird such as: I have issued you a kid but have not given you key material in the current epoch, so I can just give you the same kid with the new key material. On the other hand if I have given you key material in the current epoch, I should not need to roll over the key material but do need to provide a new kid so that you do not reuse the save IV values. Alternatively, it could be that rolling the key material would be more efficient in terms of traffic on the wire depending on if one things that retrieving key material or retrieving signatures for every entity is going to be smaller. The one case that I have not been able to get a good handle on is as follows: The KDC persists keys and key ids in a database. The KDC at some point crashes and then restarts. Should the KDC roll the epoch and the key material on re-start or should it just load the current key material and continue with it? A client that tries to JOIN would be unable to do so because the KDC does not respond so that would not force a roll over. A client that tries to do a RENEWAL because of IV exhaustion would be unable to do so and would have to go quiet until the KDC because alive and that would not force a roll over. A client that tries to do an LEAVE would not be able to tell the KDC that. This is the one case that having the KDC do the roll over of the keys would make sense. However the KDC would be unable to tell anybody of that decision as all of the observe relationships would have been lost at the point so that in some respects the damage of allowing an entity that left to continue reading messages would continue. Does anybody have an opinion or different analysis that they would be willing to share? Jim From nobody Mon Aug 5 15:52:59 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F1571200C1 for ; Mon, 5 Aug 2019 15:52:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jSH5r0Hpdh84 for ; Mon, 5 Aug 2019 15:52:57 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A544A120025 for ; Mon, 5 Aug 2019 15:52:56 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 5 Aug 2019 15:52:49 -0700 From: Jim Schaad To: Date: Mon, 5 Aug 2019 15:52:47 -0700 Message-ID: <035601d54be0$81e90ff0$85bb2fd0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AdVL4FSEnYq08BA5SGS+8PHvILOeBw== X-Originating-IP: [73.180.8.170] Archived-At: Subject: [Ace] 105 Minutes X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2019 22:52:59 -0000 I have uploaded an edited version of the minutes from Christian (thanks Christian) to the meeting page. If you desire, please take a look at them and make sure that you think they correctly reflect what you said. Send a note to the chairs if you believe there is an error. Jim From nobody Mon Aug 12 14:46:11 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBBB21201DE; Mon, 12 Aug 2019 14:46:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=risecloud.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tH31zOBv3JP4; Mon, 12 Aug 2019 14:46:04 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-eopbgr150054.outbound.protection.outlook.com [40.107.15.54]) (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 2907A12158D; Mon, 12 Aug 2019 05:08:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=je+kYt/KyqFKTGzE3Ryb9sUr4coIyeP5Ku2exqaQE/A/wWXeRQiVAuhLv8X7+fyHuBzX/2X+PPQ5xMI3pyC82a7GoeLP8LfOdNBH5rSuxQlPqiCxKY0H55zIWghJxbHPfF4y/TkQ/uLV0gPLyvd6ibGB1EWg+KTkItqlyR+Vuwi1pvxK4d6vGmqxe9NZxNpcU40H4EyncOp5f6eCyY3Lyq73oQS7BDJo4eEmmofJY000V4ahXhgyC9O9K4V0Ovtsi/bnSjfKaDuf2PQuVyRlkOAp1iizFdsjcq6RhLFGl6k6zNzXzZr+mG+UZCh2QrQOQc4XCqQ3H3E9Jcc0trHCSQ== 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=1UqqwO19iYX1XgtEDP9xxUWF5V3JdZZibPybgS61y9E=; b=ULlufxdxKsDaAL15dOYrVVYaBszTA+nyOhyaJA85+zUWpKCatiQ+5eduoisuc7jVqvbKDxg6++LtAi1weAar7wPWQCnPXqMz9xqDZP2h3lLXquicuK1NQZbF9ozG8Gb66U5rZnnZdHDGbHmvQC+AGGgHIxPzBMF+ohXiK4KpfZQOdXK/ZQZ9dQdIuebUhCvNF3jjAvp0stcGRHYye+yvILIFIffOOFseKJfHE/ATdo/iIdjTNLanS3+K/idifI4DcA1iei+g+dr+nFeDmIyBkPGSI8y+Z8Ti0yhLDgpAvObvUccxblVHGBuEoxyiYP3SHMAc/PVeo/Ol884P8B+HDQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 194.218.146.197) smtp.rcpttodomain=ietf.org smtp.mailfrom=ri.se; dmarc=bestguesspass action=none header.from=ri.se; dkim=none (message not signed); arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=RISEcloud.onmicrosoft.com; s=selector2-RISEcloud-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=1UqqwO19iYX1XgtEDP9xxUWF5V3JdZZibPybgS61y9E=; b=K6E6C3Px2yT3CzjOljLqR8YhRM3D5wnZvmK96CUEyyDNEXtpXPeK4rCH/tQMok4ZURq/GS/+y49iD93eHSEigjnYGQN+kfBswBPhLVHXR1upQEaMv1tF9snKFDdwKKAdnVbvMPKiRJ63L1RwaH2Mv0jjle4NR0YhzEyAYH+heXY= Received: from HE1P18901CA0006.EURP189.PROD.OUTLOOK.COM (2603:10a6:3:8b::16) by DB6P18901MB0213.EURP189.PROD.OUTLOOK.COM (2603:10a6:4:28::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2157.16; Mon, 12 Aug 2019 12:08:14 +0000 Received: from AM5EUR02FT019.eop-EUR02.prod.protection.outlook.com (2a01:111:f400:7e1e::201) by HE1P18901CA0006.outlook.office365.com (2603:10a6:3:8b::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.2157.14 via Frontend Transport; Mon, 12 Aug 2019 12:08:13 +0000 Authentication-Results: spf=pass (sender IP is 194.218.146.197) smtp.mailfrom=ri.se; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=ri.se; Received-SPF: Pass (protection.outlook.com: domain of ri.se designates 194.218.146.197 as permitted sender) receiver=protection.outlook.com; client-ip=194.218.146.197; helo=mail.ri.se; Received: from mail.ri.se (194.218.146.197) by AM5EUR02FT019.mail.protection.outlook.com (10.152.8.169) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.20.2157.15 via Frontend Transport; Mon, 12 Aug 2019 12:08:13 +0000 Received: from [10.112.134.122] (10.100.0.158) by sp-mail-2.sp.se (10.100.0.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Mon, 12 Aug 2019 14:08:12 +0200 To: Benjamin Kaduk , CC: References: <20190730155605.GM47715@kduck.mit.edu> From: Ludwig Seitz Message-ID: <92fc4816-3447-62e3-e2fa-e6d92ea772e3@ri.se> Date: Mon, 12 Aug 2019 14:08:12 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <20190730155605.GM47715@kduck.mit.edu> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms060904080209040408000003" X-Originating-IP: [10.100.0.158] X-ClientProxiedBy: sp-mail-2.sp.se (10.100.0.162) To sp-mail-2.sp.se (10.100.0.162) X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:194.218.146.197; IPV:NLI; CTRY:SE; EFV:NLI; SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(376002)(346002)(396003)(136003)(2980300002)(40224003)(51444003)(199004)(189003)(305945005)(7736002)(16526019)(186003)(76176011)(53936002)(30864003)(2616005)(316002)(65826007)(36756003)(106002)(71190400001)(110136005)(8936002)(26005)(66574012)(229853002)(2171002)(2906002)(86362001)(6116002)(6246003)(3846002)(64126003)(81166006)(81156014)(8676002)(6306002)(336012)(4326008)(31696002)(53546011)(33964004)(356004)(5660300002)(5024004)(568964002)(22746008)(65806001)(65956001)(386003)(446003)(14444005)(16576012)(11346002)(16586007)(70206006)(31686004)(58126008)(44832011)(476003)(70586007)(235185007)(126002)(486006)(40036005)(478600001)(22756006); DIR:OUT; SFP:1101; SCL:1; SRVR:DB6P18901MB0213; H:mail.ri.se; FPR:; SPF:Pass; LANG:en; PTR:InfoDomainNonexistent; A:1; MX:1; X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: f7111030-2e5f-431c-9f3a-08d71f1dc043 X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(4709080)(1401327)(2017052603328)(7193020); SRVR:DB6P18901MB0213; X-MS-TrafficTypeDiagnostic: DB6P18901MB0213: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:9508; X-Forefront-PRVS: 012792EC17 X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Message-Info: Kyogt/rUga5NlZHEgPECV5CGGciP2HngfQlfR8em+f72PAkZryT+ysK2hPDfG27L0H8Kf5fwG5k+s7atF8KFKBGednl5RB948anPr5GiVZBxtCSQQxJtX6XAW+cVPSZw4GWoQiv3qhfExxrNKveOWAhb8ibNdD5P1YiI6rOogIWdKhB2d9460G2tPPOyD6Xz7pcVJkOGmPBUk/5oQ3Ksq6rx4qUT3fwDLwiN53W1pyKINoWIA0JBCemor5v+TOeupDnGeVPp+xy/M3xkDfKkJLnPYtRvYmaMBnpYgy/z9pdCD5xx24jKoSeQgZQrOHvJs2Y2aJsFqx67G3F6UH/Wv9bBB/h3gY9lhz7RyJ9UexJaSudQ4BeUQ6fAG17qgMdyhWNZ1SZ4eHHfprJ5sBABr3gxlDLgeBnRT7/xUvyjzC4= X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Aug 2019 12:08:13.4692 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: f7111030-2e5f-431c-9f3a-08d71f1dc043 X-MS-Exchange-CrossTenant-Id: 5a9809cf-0bcb-413a-838a-09ecc40cc9e8 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=5a9809cf-0bcb-413a-838a-09ecc40cc9e8; Ip=[194.218.146.197]; Helo=[mail.ri.se] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6P18901MB0213 Archived-At: 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2019 21:46:10 -0000 --------------ms060904080209040408000003 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable Hello Ben, thank you for your review. Comments inline. @co-authors: Please check if you agree with my proposed resolutions. /Ludwig On 30/07/2019 17:56, Benjamin Kaduk wrote: > We should be consistent across examples about whether the use of CBOR > diagnostic notation also requires a disclaimer about "with linebreaks > for readability". As far as I gather from the comments (especially from Carsten), we'd=20 solve this by referencing section 6 of RFC 7049. I will consult with my=20 co-authors, but I think this is the right solution. >=20 > Section 2 >=20 > Presenter > Party that proves possession of a private key (for asymmetric ke= y > cryptography) or secret key (for symmetric key cryptography) to = a > recipient. >=20 > nit: it might be worth either capitalizing Recipient to point to the > following item more clearly, or specifying "recipient of a CWT" for > parallelism with Recipient. > (If we do the former we should capitalize Presenter in the following > definition. But since we don't use the capitalized terms throughout th= e > text, it wouldn't be my own preference.) >=20 Ok I'll go for "recipient of a CWT" > Section 3.2 >=20 > This example key expired in 2013. While the example will "always" be > expired for an archival document, it might be worth making it more > timely with respect to the publication date. (This holds for basically= > all time values in the document's examples.) >=20 > Value 2 for 'kty' should have diagnostic notation /EC2/, not /EC/. >=20 > [I did not check that the example x and y coordinates are in fact point= s > on P256.] I agree this should be updated. >=20 > 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 i= s > 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. >=20 > 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 thi= s > usage is performed and encoded. >=20 This mirrors the corresponding procedure in RFC 7800. Would it be OK to=20 just refer to that document=20 (https://tools.ietf.org/html/rfc7800#section-3 or actually 3.3)? > Section 3.3 >=20 > Is the /HMAC256/ the conventional diagnostic notation for alg value 5 > (noting that RFC 8152 calls it both "HMAC256/256" and "HMAC w/ SHA-256"= )? >=20 I agree with Jim's suggestion to use HMAC256/256 > The following example CWT Claims Set of a CWT (using CBOR diagnosti= c > notation, with linebreaks for readability) illustrates the use of a= n > encrypted symmetric key as the "Encrypted_COSE_Key" member value: >=20 > { > /iss/ 1 : "coaps://server.example.com", > /sub/ 2 : "24400320", > /aud/ 3: "s6BhdRkqt3", > /exp/ 4 : 1311281970, > /iat/ 5 : 1311280970, > /cnf/ 8 : { > /COSE_Encrypt0/ 2 : [ >=20 > Should this be "/Encrypted_COSE_Key/" and not "/COSE_Enrypt0/"? >=20 > [I did not validate the COSE_Encrypt0 output] > COSE_Encrypt0 is a defined construct of COSE, while Encrypted_COSE_Key=20 is not. We'd have to define it or write an explanatory comment. > Section 3.4 >=20 > { > /iss/ 1 : "coaps://server.example.com", > /aud/ 3 : "coaps://client.example.org", >=20 > Is it in any way confusing to use client.example.org as opposed to, say= , > resource.example.org as the audience? I agree, and issuer feels like it should be "as.example.com". >=20 > /exp/ 4 : 1361398824, > /cnf/ 8 : { > /kid/ 2 : h'dfd1aa976d8d4575a0fe34b96de2bfad' >=20 > /kid/ in the 'cnf' map has key 3, not 2. >=20 Will fix. > Note that the use of a Key ID to identify a proof-of-possesion key > needs to be carefully circumscribed, as described below and in > Section 6. Where the Key ID is not a cryptographic value derived > from the key or where all of the parties involved are not validatin= g > the cryptographic derivation, it is possible to get into situations= > where the same Key ID is being used for multiple keys. The >=20 > I don't think this quite covers the needed properties, since we also > need some assurance that all parties are interpreting the kid value in > the same way. It may be possible to construct such a scenario via an > attacker replaying a stolen token or even just inadvertent confusion by= > some party (quite plausible when we consider scenarios that involve the= > same key being described by different 'kid' values in messages with > different recipients). In particular, if the situation arises where an= > attacker is able to choose the 'kid' value that will be used, they coul= d > deliberately cause a collision with a legitimate value used by some > other party. >=20 I will go with you suggestion (later in the discussion) to add some text = that implementers should expect kid collisions. > In the world of constrained Internet of Things (IoT) devices, there= > is frequently a restriction on the size of Key IDs, either because = of > table constraints or a desire to keep message sizes small. These > restrictions are going to protocol dependent. For example, DTLS ca= n >=20 > nit: "going to be" or maybe even just "are protocol dependent". Will fix. >=20 > use a Key ID of any size. However, if the key is being used with > COSE encrypted message, then the length of the key needs to be > minimized and may have a limit as small as one byte. >=20 > nit: is this "length of the key" or "length of the key ID"? Length of key ID evidently. Will fix. >=20 > Note that the value of a Key ID is not always the same for differen= t > parties. When sending a COSE encrypted message with a shared key, > the Key ID may be different on both sides of the conversation, with= > the appropriate one being included in the message based on the > recipient of the message. >=20 > While this recipient-dependence is probably unavoidable (as the > requisite namespacing would use more space on the wire than is > reasonable for many applications), it does merit some security > considerations text, noting that such messages are context-dependant an= d > could be misinterpreted if presented in a different context. > Audience restrictions, as mentioned in Section 4, provide substantial > protection in this regard, but are not necessarily a complete solution.= >=20 If I get the gist of your discussion with Jim, the text about=20 non-uniqueness of kid would resolve this. > o A recipient can decide not to use a CWT based on a created Key I= D > if it does not fit the recipient's requirements. >=20 > 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 th= e > presenter presents the CWT to the recipient, the recipient says "this i= s > 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 issue= r > would make any different choices the second time around?) This risk always exists. In a constrained device world, the recipient=20 may already have cleared out the key referenced by the key ID, which=20 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=20 delivered by the recipient rejecting the CWT might be helpful I suppose. Do you think this merits some text? >=20 > o If an issuer is going to use the Key ID confirmation method and = is > not going to guarantee that serial number uniqueness is going to= > be preserved, the recipient needs to have that information > configured into it so that appropriate actions can be taken. >=20 > nit: this is the only place in the document that talks about "serial > number"s. I think that was intended to refer to key ID uniqueness. I'll=20 double-check with Mike. > Do we say what the "appropriate actions" are somewhere else in the > document? I agree this is disturbingly unspecific. I'll try to rephrase this. >=20 > Section 3.5 >=20 > Note that another means of proving possession of the key when it is= a > symmetric key is to encrypt the key to the recipient. The means of= > obtaining a key for the recipient is likewise protocol specific. >=20 > While true, there are some subtleties here, namely that the recipient > needs some way of knowing that it is the presenter (as opposed to some > other party) that has actually performed that encryption. In Kerberos > we perform this key confirmation by using the encrypted (session) key > for subsequent protocol exchanges, and if the presenter fails to proces= s > those exchanges then it is clear the presenter does not actually posses= s > the key. This document does not seem to describe the need for such > subsequent confirmation (or, alternately, the consequences of failing t= o > do so.) >=20 Yes this sounds misleading, there obviously needs to be a recipient=20 nonce in there somewhere. But since the title of this section is=20 "Specifics Intentionally Not Specified" I'm more inclined to rewrite=20 this more non-specifically. How about: "Note that other means of proving possession of a key exist, which could = be used in conjunction with a CWT's confirmation key." ? > Section 4 >=20 > A recipient might not understand the "cnf" claim. Applications tha= t > require the proof-of-possession keys communicated with it to be > understood and processed MUST ensure that the parts of this > specification that they use are implemented. >=20 > nit(?): I'm not sure I'm parsing this sentence correctly: is > "communicated with it" referring to "CWTs that include the 'cnf' claim"= ? >=20 How about rephrasing this to: "Applications that require the use of proof-of-possession in CWTs, using the 'cnf' claim MUST ensure that the parts of this specification that=20 they use are implemented." ? > To avoid replay attacks when the proof-of-possession > tokens are sent to presenters, a security protocol, which uses > mechansims such as nonces or timestamps, has to be utilized. [...]= >=20 > I suspect the RFC Editor will want to reword this sentence to avoid the= > excessive parentheticals and awkward passive-voice construction. I'll > be bold and suggest a more dramatic rewording to preempt that: "Proof o= f > possession only provides the intended security gains when the proof is > known to be current and not subject to replay attacks; security > protocols using mechanisms such as nonces and timestamps can be used to= > avoid this risk of replay when sending proof-of-possession tokens to > [presenters or recipients]". Note that I am not sure if the original > was intended to refer to the transfer of PoP tokens to presenters (as > written) or recipients (where risk of replay is more traditionally > concerned). >=20 I am in favor of adapting/adopting your suggestion. The original=20 sentence sounds strange indeed. > from changing any elements conveyed within the CWT payload. Specia= l > care has to be applied when carrying symmetric keys inside the CWT > since those not only require integrity protection but also > confidentiality protection. >=20 > Do we want to reiterate the common mechanisms for providing > confidentiality protection here, or just leave the existing text earlie= r > 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. > Section 5 >=20 > This sort of correlation can occur even for subsequent connections > between the same two parties if observed by a passive observer (e.g., i= n > the case of a mobile client that changes location). I forget if we hav= e > strong enough guarantees on the use of transport-level encryption that > would prevent such CWTs from being observed in this fashion. >=20 How about rephrasing the sentence to "... can be used as a correlation=20 handle if the same key is used in multiple occasions."? This would be more general and also cover the passive observer case. > Section 6 >=20 > 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 >=20 > 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. >=20 This text is referring to the issuer's credentials (e.g. the=20 Authorization Server issuing the CWT), that the recipient needs to=20 verify the CWT. Do you want us to clarify this sentence? > recipient to know information about the issuer. Likewise, there > needs to be agreement between the issuer and the recipient about th= e > claims being used (which is also true of CWTs in general). >=20 > We briefly discuss the presenter (in the guise of the subject) in the > next paragraph when we talk about key IDs, but are there any other case= s > where there needs to be coordination with the presenter? Would > distributing a symmetric PoP key be considered to fall under this > mantle? Yes indeed, I believe it was left out here because it seems quite=20 evident that the presenter needs to be involved when talking about=20 proof-of-possession. > When an issuer creates a CWT containing a Key ID claim, it needs to= > make sure that it does not issue another CWT containing the same Ke= y > ID with a different content, or for a different subject, within the= > lifetime of the CWTs, unless intentionally desired. Failure to do = so > may allow one party to impersonate another party, with the potentia= l > to gain additional privileges. Likewise, if PoP keys are used for >=20 > nit: "same Key ID with a different content" doesn't seem quite right, a= s > the "content" of a Key ID is surely the key-ID value itself. Perhaps > "referring to" would be more appropriate. What is meant here is different _other_ content, i.e. other claims such=20 as the scope and audience claims. I will try to rephrase this to clarify.= > I think we should probably give the reader some indication of what > semantics might be attributed to the "intentionally desired" case. It > doesn't necessarily need to be a specific example, but we could say wha= t > the relevant properties/attributes that might lead to such a situation > would be. >=20 Ok I'll add an few sentences to describe the example we had in mind,=20 where several CWTs are bound to the same key for the same presenter. > multiple different kinds of CWTs in an application and the PoP keys= > are identified by Key IDs, care must be taken to keep the keys for > the different kinds of CWTs segregated so that an attacker cannot > cause the wrong PoP key to be used by using a valid Key ID for the > wrong kind of CWT. >=20 > Audience restrictions can come into play here, too, right? In that a > restricted audience of all the CWTs in turn limits the scope of > administration in which this care/segregation needs to be enforced. >=20 Correct, we should add a sentence here to suggest this as one strategy=20 to limit this risk. > Section 7 >=20 > 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. >=20 > 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 clearl= y > applicable for determining which range from which to allocate, since > that has impact on the encoding size. Can the experts insist on update= s > to the security considerations text of a specification prior to grantin= g > approval, or are they limited to denying registration of values with > poor security properties or insufficient documentation thereof? >=20 I'm too unfamiliar with the designated expert system to provide a good=20 answer on this one. Can one of my co-authors chip in here? > Section 7.2.1 >=20 > Change Controller: > For Standards Track RFCs, list the "IESG". For others, give the= > name of the responsible party. Other details (e.g., postal > address, email address, home page URI) may also be included. >=20 > In light of the GDPR and similar regulations (and, as is done in RFC 86= 02), we > may not want to keep all of these, especially postal address, given the= lack of > a clear need. >=20 Ok I'll have a look at how it is done in RFC 8602 and adapt this text=20 accordingly. > Specification Document(s): > Reference to the document or documents that specify the paramete= r, > preferably including URIs that can be used to retrieve copies of= >=20 > Is the reference required to be publicly accessible? If not, is it > required that a copy be made available to the experts and IANA? >=20 I think that at least the experts and IANA should be able to inspect a=20 copy, how are they going to do their job otherwise? Do you want us to take any textual action here or was this just a=20 general remark? > Section 7.2.2 >=20 > o Confirmation Method Name: "Encrypted_COSE_Key" > o Confirmation Method Description: Encrypted COSE_Key > o JWT Confirmation Method Name: "jwe" > o Confirmation Key: 2 > o Confirmation Value Type(s): COSE_Encrypt or COSE_Encrypt0 > structure (with an optional corresponding COSE_Encrypt or > COSE_Encrypt0 tag) >=20 > Do we want to say something about how, in the case when the tag is > omitted, the application protocol specification needs to indicate how t= o > determine which one is in use? >=20 As a result of your subsequent discussion with Jim I am inclined to=20 leave this as it is. Is that acceptable for you? > Section 8.2 >=20 > I think [JWT] needs to be normative, as we have a SHOULD-level > requirement for the audience restriction procedures it specifies. >=20 I agree with Jim's assessment that an indirect normative reference via=20 the CWT RFC is sufficient. > I just want to check that it's intentional/desired to mix descriptive > reference tags (e.g., [JWS]) and RFC-number tags (e.g., [RFC7800]) for > the referenced RFCs. >=20 I'm more inclined to have RFC number tags (makes it easier to look them=20 up without going via the bibliography), but it's mostly a matter of=20 taste. Do you think we should use one or the other consistently? > Acknowledgements, Authors >=20 > The datatracker is currently accepting XML v3 format drafts, and the RF= C > Editor's target cutover date for the end of August is quite soon, so > feel free to consider using an XML v3 submission with UTF-8 > representations of names not well represented by the ASCII subset. >=20 It broke some older version of xml2rfc at some earlier point (the=20 default one coming with Ubuntu distros), but since I got that fixed now, = I'm inclined to give G=C3=B6ran his umlaut. /Ludwig --=20 Ludwig Seitz, PhD Security Lab, RISE Phone +46(0)70-349 92 51 --------------ms060904080209040408000003 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DT0wggYWMIID/qADAgECAg8BaKlzCTJTye3phLaz/cIwDQYJKoZIhvcNAQELBQAwRzELMAkG A1UEBhMCU0UxFDASBgNVBAoMC1RlbGlhU29uZXJhMSIwIAYDVQQDDBlUZWxpYVNvbmVyYSBD bGFzcyAyIENBIHYyMB4XDTE5MDIwMTE0MjUxNVoXDTIxMDIwMTE0MjUxNFowgYsxCzAJBgNV BAYTAlNFMS4wLAYDVQQKDCVSSVNFIFJlc2VhcmNoIEluc3RpdHV0ZXMgb2YgU3dlZGVuIEFC MRUwEwYDVQQDDAxMdWR3aWcgU2VpdHoxEjAQBgNVBAUTCUx1ZHdpZ1NlaTEhMB8GCSqGSIb3 DQEJARYSbHVkd2lnLnNlaXR6QHJpLnNlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAlJNmRfcsto5I/yXrBIi9QroZtfAMttc1Eznv5iPCK++eFUArODhITO7k9rtlQX5D8vYF v4vzZex58YWZhvGMzDj9FdpD/PHKOxL/frlrreChuissPWo5M88DmL3V1oyGzvgeRqaafpEi 0/2+gezMFlABm/BXj3/0Fiw5Sxub7essE27EtDK05nAbUB69kfLHBEytbTAuuSb11hC1dpTf itMZkzSFwsBCyPtIv3GRt9xgnOPK4RRpHidv1GLYXNQQ7xEGhFy4qbZ2NSfM+56SSRswvW9P 5n81ZmZ4FWkiJouUIYtZ2ifncBJL4DC2chjsywDEz5No7kYrGxc5oOm1YQIDAQABo4IBuDCC AbQwHwYDVR0jBBgwFoAUnhn/5Q06/gCXFT9p8dxaPKoMlIMwHQYDVR0OBBYEFKZHZ8MZNNP5 tXMPjeFiw01pUWbtMA4GA1UdDwEB/wQEAwIFoDBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEB DDA6MDgGCCsGAQUFBwIBFixodHRwczovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEu Y29tL0NQUzAdBgNVHREEFjAUgRJsdWR3aWcuc2VpdHpAcmkuc2UwTQYDVR0fBEYwRDBCoECg PoY8aHR0cDovL2NybC0yLnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYWNsYXNz MmNhdjIuY3JsMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjB+BggrBgEFBQcBAQRy MHAwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnRydXN0LnRlbGlhLmNvbTBFBggrBgEFBQcw AoY5aHR0cDovL2NhLnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYWNsYXNzMmNh djIuY2VyMA0GCSqGSIb3DQEBCwUAA4ICAQCk0GOalOCjEJObuBeMg0QREtBP/2ona16npn+T v5R3Vjk5UsQdOaOosgVjADX68C83dyfPiWR4UfNJoTBcM8JLpEXIm+xC4BiDPTPHYvgkhgXt 9VWCRWXOMfT/UPXjiGsbPuNWja1LQzF5KOmM826kHVZItHuDY6kJLE4OZ+apFvVKtSLQJJLA 4MlDVwp5+XsZi4cftcX5HdgLdChodUPKq3XVfALfXM/p81XEFBTYOHNplr3cQytDQjsnCZnS Ic4UpsxrArNxDO9+AKu/s1Fbq494AhHj4oHcg4DIjhHUzbPCLP19Gqp4dflr/V7Ulg3d+4Zh bmSAn1cffrzvvkjVrqMgQOoHQTl2QyO9n/oJ/9CSYRmhFsQMPun9LM/p5l58dTZp53B3LgA6 FFrxnntlZnTPh3bvsMJvUQ+AoiXyQwnkdxUrhoM+gUz36t3JSA8g48h7BhPsnwQ/YrarAhJ8 ifuzykTQmDseWLjJKyFflddy/azAlPQjgSMMWOZCo2s+l+WwPISf33nls2Aec/vvG5auYHS6 pwWuVKuwZTPgJfHanZTNpBM5y0jVBz6tr8AHZypnCONgyUYA4uec3v5oWz4FvLEnlKnMGoK3 OeFGvfHG0tbP25HbdN3AJYP0EUo56wfkBOYsnmn4mEYdk2GHkJNfaQRBJljH0T7TOcmcDjCC Bx8wggUHoAMCAQICEGN8C9eFpb8p2mAtfE16cLEwDQYJKoZIhvcNAQELBQAwNzEUMBIGA1UE CgwLVGVsaWFTb25lcmExHzAdBgNVBAMMFlRlbGlhU29uZXJhIFJvb3QgQ0EgdjEwHhcNMTQx MDE2MDgzOTMwWhcNMzIxMDE2MDUwNDAwWjBHMQswCQYDVQQGEwJTRTEUMBIGA1UECgwLVGVs aWFTb25lcmExIjAgBgNVBAMMGVRlbGlhU29uZXJhIENsYXNzIDIgQ0EgdjIwggIiMA0GCSqG SIb3DQEBAQUAA4ICDwAwggIKAoICAQC0PpW2qcWGnStqfa5DjrUi79Kz2SySUlJ1kiEQ1Pd/ LWbnsEwFYPqOJwAf6ZtEDtQ/9Z1VkVNQ6MkD++keqk7648x0YANgMyiJsWrbd0TKOObtlXdJ pb5qesJ5nOAdVeL3z6lgrkZx+fsUfTV+lLRGRh2+RWzZTjPAvKotY3nAwXCHtwI5v3FKuR10 aJ9+CEOka02KSUzGjcGZwMk2io0DxLELf1gPRvqE9xmn4ioXLqpluozb4Fo9ewydufTLQc3/ I63uPQh8BlLPPIGzWb4iBDq2zbWlbx0KlH/UlUZ7fjzp6N6cAqZ2NnDaCOnnIRfUYeNXFG8/ aiBeFOpEeEpclr5QUwr9HLKL1QiyQtc/wW8acQFoKuGi8myiAch7k7S0rmU5gT05je+OTzWh Oaw7gmDdndYY1mjkPkzpQ+hxyfnwUsAitUq9j0imFOLxKWLH4QNbyuDIMvDyezzJWzMy3XPB LiLSH9CBLVQHRoQ+WW8xD4rnmvQtoGZM72og2iNf4/JCHL1AJYhQtaRjYgm3rhvAP0HhSVAB Z5aHM52ylJHC3JwUyuFm8S9A2ffY9rUTffMLWmDCnX0QAP9bKr6+ACogm4DBUj3ftYodI2TD 6F8+VjSFuCzGDPuCjK+fQ2c3wqziwFl+NgoGI9Vgc6x5+0ocKkiQAIYFaQ3SyGmI6QIDAQAB o4ICFTCCAhEwgYoGCCsGAQUFBwEBBH4wfDAtBggrBgEFBQcwAYYhaHR0cDovL29jc3AudHJ1 c3QudGVsaWFzb25lcmEuY29tMEsGCCsGAQUFBzAChj9odHRwOi8vcmVwb3NpdG9yeS50cnVz dC50ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5jZXIwEgYDVR0TAQH/BAgw BgEB/wIBADBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEBAjA6MDgGCCsGAQUFBwIBFixodHRw czovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQUzAOBgNVHQ8BAf8EBAMC AQYwgcYGA1UdHwSBvjCBuzBAoD6gPIY6aHR0cDovL2NybC0zLnRydXN0LnRlbGlhc29uZXJh LmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNybDB3oHWgc4ZxbGRhcDovL2NybC0xLnRydXN0 LnRlbGlhc29uZXJhLmNvbS9jbj1UZWxpYVNvbmVyYSUyMFJvb3QlMjBDQSUyMHYxLG89VGVs aWFTb25lcmE/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnkwHQYDVR0OBBYEFJ4Z /+UNOv4AlxU/afHcWjyqDJSDMB8GA1UdIwQYMBaAFPCPWTgAs/WPmpYM1ev6e6oX6BMSMA0G CSqGSIb3DQEBCwUAA4ICAQB5wuZFNXR5ko9cu7PcpIyH8xaoGfpimP2GTg7qVuL92D/idIlj pqMm93WC9mgL/Uy6DExoF8xSLurLaiajoU+VG6ZWg0F7P1AXARNt0RpWI5SphxBQYM2751S8 vC/22k8Vi+qpQVIREqQPVXCIEH7U6eCY9gEVzdq9l1yPoI8n0D2a8V6GCv0RVkmIpa16rNYD tTw4j3Ha56/Ua33C3qeZh1dIfkaU2h4CGHd2Em3v5LLMsEh8dqUeG9yIcCU+8RUgDahNxWMe MGxzrhwk8WBV6xeoQp20p7cSHbSbyHJURC1n+nVrgdh8hbw6WOgFhNA5tCPDZ0oSF+uHfj+b ioZE3AlYdcEqHJA9A9sO58F4/Qg/yp9oYuT0ZpKb4hmzeqDXvk5KRFNfHlhTt35i+qmas9wB 11MXbYd5WwqEhZH6HWO5H7XKJP7olxmEC0W3OKlpKafq1iPsBN5ycRfUrXFss0Ax6vpCq0XA 3LYePpQ44hOU+qrkR1M0a7Eo3++3TpP4cV+FZiO4aZYZ3yZftSRHwWpGiDBdWOdTKR2GJi7Z z/OxacrmwmM1Z+WcigldbG8f3IMnOLK4X0uXjhVeAHrhuttQuM8i+4TNXgsZbmfEKNDQIQPO /lbacsGHWFB/U2y6SXVEkZs2xIciRA0iZNTv7mbIL8SZmf5wpbjDCYHiCjGCAzgwggM0AgEB MFowRzELMAkGA1UEBhMCU0UxFDASBgNVBAoMC1RlbGlhU29uZXJhMSIwIAYDVQQDDBlUZWxp YVNvbmVyYSBDbGFzcyAyIENBIHYyAg8BaKlzCTJTye3phLaz/cIwDQYJYIZIAWUDBAIBBQCg ggGvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE5MDgxMjEy MDgxMlowLwYJKoZIhvcNAQkEMSIEIHM2WV0LTWRrvZiHyrC8XR1M1tkh8mZ+jjQHdMNfEYi8 MGkGCSsGAQQBgjcQBDFcMFowRzELMAkGA1UEBhMCU0UxFDASBgNVBAoMC1RlbGlhU29uZXJh MSIwIAYDVQQDDBlUZWxpYVNvbmVyYSBDbGFzcyAyIENBIHYyAg8BaKlzCTJTye3phLaz/cIw awYLKoZIhvcNAQkQAgsxXKBaMEcxCzAJBgNVBAYTAlNFMRQwEgYDVQQKDAtUZWxpYVNvbmVy YTEiMCAGA1UEAwwZVGVsaWFTb25lcmEgQ2xhc3MgMiBDQSB2MgIPAWipcwkyU8nt6YS2s/3C MGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0D BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwIC ASgwDQYJKoZIhvcNAQEBBQAEggEAGGj1/a2dZeFK2aFkVUcrvn8PB/HJVn1NivvYiw1OrVEw tjPCn8gR0mpuBeyOGSGn1G1lw87Q4+h2ouQc6n5gEWwV7uUYMV1SzlEs5tXu2XfSbXiJirtG /Tu7Opi7queQLntHXkO5/tW6ZyCMlszMO6/R2ZOjNLgkOt3uVKi8WgcV6YC8RTI8eb1w5J0R 18GK4uiXvwU/4967krjm/3QX7CVwqJOKG43txmehbgz6uZBJ9mryK4z3/SHAjvONnFSAhqwF orkRG7LnEoAk6AL0E69iorzfb+9QNDFLrT5Dx8nvAgg2FO44mgpRYH9lJshqMNIPJWcr3Hn7 GYU01ERwewAAAAAAAA== --------------ms060904080209040408000003-- From nobody Mon Aug 12 15:25:26 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88DBF120AD1; Mon, 12 Aug 2019 15:25:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001, 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 QlDGjLbgACgy; Mon, 12 Aug 2019 15:25:09 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E470E120EFA; Mon, 12 Aug 2019 14:59:34 -0700 (PDT) Received: from [192.168.217.110] (p548DCCB9.dip0.t-ipconnect.de [84.141.204.185]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 466qWT3T9Wz10bj; Mon, 12 Aug 2019 23:59:33 +0200 (CEST) Content-Type: multipart/signed; boundary="Apple-Mail=_73003E5A-779D-414D-A683-8362351A196F"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: <92fc4816-3447-62e3-e2fa-e6d92ea772e3@ri.se> Date: Mon, 12 Aug 2019 23:59:32 +0200 Cc: Benjamin Kaduk , draft-ietf-ace-cwt-proof-of-possession.all@ietf.org, ace@ietf.org X-Mao-Original-Outgoing-Id: 587339971.624738-83ca61fdeae2ce43f1e715f111336313 Message-Id: References: <20190730155605.GM47715@kduck.mit.edu> <92fc4816-3447-62e3-e2fa-e6d92ea772e3@ri.se> To: Ludwig Seitz X-Mailer: Apple Mail (2.3445.9.1) Archived-At: 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2019 22:25:14 -0000 --Apple-Mail=_73003E5A-779D-414D-A683-8362351A196F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Aug 12, 2019, at 14:08, Ludwig Seitz wrote: >=20 > As far as I gather from the comments (especially from Carsten), we'd = solve this by referencing section 6 of RFC 7049. I will consult with my = co-authors, but I think this is the right solution. That is not what I said. Gr=C3=BC=C3=9Fe, Carsten --Apple-Mail=_73003E5A-779D-414D-A683-8362351A196F Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIzBAEBCAAdFiEEcr05t4NZlx5Xee/8VkscnDT509sFAl1R4UMACgkQVkscnDT5 09t59hAAlU4icA7jjRBCzBCzMA3lMutnx2i7v346EseZAmg8PVFYqnuwtdlCIB5f PhYmvqgmExL8qHxNprTeF6QtQsnEdJnBc7kHXWY3T8slt6B/C6O+UVb1MYQB0sZz l2Os1Ol+0yqAR5SLZB47Y5XHYQ/0Y5Gk2SfvsJpblLX0g9OOYosn99cy61+xyvix sj9SiTp6ewPfZ8QzQi7JTMcHBxX5/dk5qap7Edh1dhjn6ktjvf4qC2o4MGHrDSg9 Z+AKT7tupXyF4LLrOb4fYYGeCQLHcSVKRMrZqwuvSshz9fKzX0RXaXx71R/RksH4 Wb38/FvWX887UdL6Kdk7E9pdjZ+oQUYnipfSFbYjm9I6vDcHy/sXV0zsIZdmL3/9 6d68vUdMdV3lzWMCGlp75bs5njgNHb3+JkUNF1kKLfqe8Z9Y76aGTFLGhrOCsgli Iwf/GGdiL395lU+eFYEpYfSQ21YkAdDfrKVCoXVKlY7ZyxzfHoZ7M9Oh725oGduU cHWXKk/RwzhtZfFCzYkiVtajT05l+GP1FHuwurlqtD0ko7gd4MVyXmQWBNbaHnhR Dkj7AVicbq8FqCAdR5OMeLJnVLmQzkhz/mjfTy4ppFdSkcmXac5yWBVFY6yJbCpc ktmJgxM6oHTeyL3AUTEhde98QZZc4KQtVe8G6MWBzMDzVBBB7SA= =p3U7 -----END PGP SIGNATURE----- --Apple-Mail=_73003E5A-779D-414D-A683-8362351A196F-- From nobody Mon Aug 12 16:15:30 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B74A212001B; Mon, 12 Aug 2019 16:15:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.189 X-Spam-Level: X-Spam-Status: No, score=-4.189 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OsD5ffjVPJGp; Mon, 12 Aug 2019 16:15:24 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 426E912000E; Mon, 12 Aug 2019 16:15:23 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x7CNFJZJ029128 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 12 Aug 2019 19:15:21 -0400 Date: Mon, 12 Aug 2019 18:15:18 -0500 From: Benjamin Kaduk To: Ludwig Seitz Cc: draft-ietf-ace-cwt-proof-of-possession.all@ietf.org, ace@ietf.org Message-ID: <20190812231518.GF88236@kduck.mit.edu> References: <20190730155605.GM47715@kduck.mit.edu> <92fc4816-3447-62e3-e2fa-e6d92ea772e3@ri.se> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <92fc4816-3447-62e3-e2fa-e6d92ea772e3@ri.se> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2019 23:15:29 -0000 On Mon, Aug 12, 2019 at 02:08:12PM +0200, Ludwig Seitz wrote: > Hello Ben, > > thank you for your review. Comments inline. > > @co-authors: Please check if you agree with my proposed resolutions. > > /Ludwig > > On 30/07/2019 17:56, Benjamin Kaduk wrote: > > We should be consistent across examples about whether the use of CBOR > > diagnostic notation also requires a disclaimer about "with linebreaks > > for readability". > > As far as I gather from the comments (especially from Carsten), we'd > solve this by referencing section 6 of RFC 7049. I will consult with my > co-authors, but I think this is the right solution. I think Carsten's followup refers to https://mailarchive.ietf.org/arch/msg/ace/y_fPgWe-m8B2OpJChQ1qhoURuPU which says to refer to RFC 8610 (or Appendix G thereof). And to be clear, my original point was just that we cannot have some examples say "with linebreaks for readability" and some not, within the same document, but I did not attempt to propose which variant to unify to. > > > > Section 2 > > > > Presenter > > Party that proves possession of a private key (for asymmetric key > > cryptography) or secret key (for symmetric key cryptography) to a > > recipient. > > > > nit: it might be worth either capitalizing Recipient to point to the > > following item more clearly, or specifying "recipient of a CWT" for > > parallelism with Recipient. > > (If we do the former we should capitalize Presenter in the following > > definition. But since we don't use the capitalized terms throughout the > > text, it wouldn't be my own preference.) > > > Ok I'll go for "recipient of a CWT" > > > Section 3.2 > > > > This example key expired in 2013. While the example will "always" be > > expired for an archival document, it might be worth making it more > > timely with respect to the publication date. (This holds for basically > > all time values in the document's examples.) > > > > Value 2 for 'kty' should have diagnostic notation /EC2/, not /EC/. > > > > [I did not check that the example x and y coordinates are in fact points > > on P256.] > > I agree this should be updated. > > > > > > 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. > > > Section 3.3 > > > > Is the /HMAC256/ the conventional diagnostic notation for alg value 5 > > (noting that RFC 8152 calls it both "HMAC256/256" and "HMAC w/ SHA-256")? > > > > I agree with Jim's suggestion to use HMAC256/256 Works for me. (This was an honest question, as opposed to those other times when I think I know the answer already but want to leave open the possibility of being wrong.) > > > 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... > > > Section 3.4 > > > > { > > /iss/ 1 : "coaps://server.example.com", > > /aud/ 3 : "coaps://client.example.org", > > > > Is it in any way confusing to use client.example.org as opposed to, say, > > resource.example.org as the audience? > > I agree, and issuer feels like it should be "as.example.com". > > > > > /exp/ 4 : 1361398824, > > /cnf/ 8 : { > > /kid/ 2 : h'dfd1aa976d8d4575a0fe34b96de2bfad' > > > > /kid/ in the 'cnf' map has key 3, not 2. > > > Will fix. > > > Note that the use of a Key ID to identify a proof-of-possesion key > > needs to be carefully circumscribed, as described below and in > > Section 6. Where the Key ID is not a cryptographic value derived > > from the key or where all of the parties involved are not validating > > the cryptographic derivation, it is possible to get into situations > > where the same Key ID is being used for multiple keys. The > > > > I don't think this quite covers the needed properties, since we also > > need some assurance that all parties are interpreting the kid value in > > the same way. It may be possible to construct such a scenario via an > > attacker replaying a stolen token or even just inadvertent confusion by > > some party (quite plausible when we consider scenarios that involve the > > same key being described by different 'kid' values in messages with > > different recipients). In particular, if the situation arises where an > > attacker is able to choose the 'kid' value that will be used, they could > > deliberately cause a collision with a legitimate value used by some > > other party. > > > > I will go with you suggestion (later in the discussion) to add some text > that implementers should expect kid collisions. Okay. > > > In the world of constrained Internet of Things (IoT) devices, there > > is frequently a restriction on the size of Key IDs, either because of > > table constraints or a desire to keep message sizes small. These > > restrictions are going to protocol dependent. For example, DTLS can > > > > nit: "going to be" or maybe even just "are protocol dependent". > Will fix. > > > > > use a Key ID of any size. However, if the key is being used with > > COSE encrypted message, then the length of the key needs to be > > minimized and may have a limit as small as one byte. > > > > nit: is this "length of the key" or "length of the key ID"? > Length of key ID evidently. Will fix. > > > > > Note that the value of a Key ID is not always the same for different > > parties. When sending a COSE encrypted message with a shared key, > > the Key ID may be different on both sides of the conversation, with > > the appropriate one being included in the message based on the > > recipient of the message. > > > > While this recipient-dependence is probably unavoidable (as the > > requisite namespacing would use more space on the wire than is > > reasonable for many applications), it does merit some security > > considerations text, noting that such messages are context-dependant and > > could be misinterpreted if presented in a different context. > > Audience restrictions, as mentioned in Section 4, provide substantial > > protection in this regard, but are not necessarily a complete solution. > > > If I get the gist of your discussion with Jim, the text about > non-uniqueness of kid would resolve this. Yup! > > > 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). > > > > o If an issuer is going to use the Key ID confirmation method and is > > not going to guarantee that serial number uniqueness is going to > > be preserved, the recipient needs to have that information > > configured into it so that appropriate actions can be taken. > > > > nit: this is the only place in the document that talks about "serial > > number"s. > > I think that was intended to refer to key ID uniqueness. I'll > double-check with Mike. > > > Do we say what the "appropriate actions" are somewhere else in the > > document? > > I agree this is disturbingly unspecific. I'll try to rephrase this. > > > > > > Section 3.5 > > > > Note that another means of proving possession of the key when it is a > > symmetric key is to encrypt the key to the recipient. The means of > > obtaining a key for the recipient is likewise protocol specific. > > > > While true, there are some subtleties here, namely that the recipient > > needs some way of knowing that it is the presenter (as opposed to some > > other party) that has actually performed that encryption. In Kerberos > > we perform this key confirmation by using the encrypted (session) key > > for subsequent protocol exchanges, and if the presenter fails to process > > those exchanges then it is clear the presenter does not actually possess > > the key. This document does not seem to describe the need for such > > subsequent confirmation (or, alternately, the consequences of failing to > > do so.) > > > > Yes this sounds misleading, there obviously needs to be a recipient > nonce in there somewhere. But since the title of this section is > "Specifics Intentionally Not Specified" I'm more inclined to rewrite > this more non-specifically. How about: > "Note that other means of proving possession of a key exist, which could > be used in conjunction with a CWT's confirmation key." > ? That should be okay. Would we want to also have some text encouraging use of the CWT Confirmation Methods Registry? > > Section 4 > > > > A recipient might not understand the "cnf" claim. Applications that > > require the proof-of-possession keys communicated with it to be > > understood and processed MUST ensure that the parts of this > > specification that they use are implemented. > > > > nit(?): I'm not sure I'm parsing this sentence correctly: is > > "communicated with it" referring to "CWTs that include the 'cnf' claim"? > > > > How about rephrasing this to: > "Applications that require the use of proof-of-possession in CWTs, using > the 'cnf' claim MUST ensure that the parts of this specification that > they use are implemented." > ? Sure, with the addition of a comma after "using the 'cnf' claim". > > > To avoid replay attacks when the proof-of-possession > > tokens are sent to presenters, a security protocol, which uses > > mechansims such as nonces or timestamps, has to be utilized. [...] > > > > I suspect the RFC Editor will want to reword this sentence to avoid the > > excessive parentheticals and awkward passive-voice construction. I'll > > be bold and suggest a more dramatic rewording to preempt that: "Proof of > > possession only provides the intended security gains when the proof is > > known to be current and not subject to replay attacks; security > > protocols using mechanisms such as nonces and timestamps can be used to > > avoid this risk of replay when sending proof-of-possession tokens to > > [presenters or recipients]". Note that I am not sure if the original > > was intended to refer to the transfer of PoP tokens to presenters (as > > written) or recipients (where risk of replay is more traditionally > > concerned). > > > > I am in favor of adapting/adopting your suggestion. The original > sentence sounds strange indeed. > > > > 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.) > > > Section 5 > > > > This sort of correlation can occur even for subsequent connections > > between the same two parties if observed by a passive observer (e.g., in > > the case of a mobile client that changes location). I forget if we have > > strong enough guarantees on the use of transport-level encryption that > > would prevent such CWTs from being observed in this fashion. > > > > How about rephrasing the sentence to "... can be used as a correlation > handle if the same key is used in multiple occasions."? > > This would be more general and also cover the passive observer case. Works for me. > > 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. > > > recipient to know information about the issuer. Likewise, there > > needs to be agreement between the issuer and the recipient about the > > claims being used (which is also true of CWTs in general). > > > > We briefly discuss the presenter (in the guise of the subject) in the > > next paragraph when we talk about key IDs, but are there any other cases > > where there needs to be coordination with the presenter? Would > > distributing a symmetric PoP key be considered to fall under this > > mantle? > > Yes indeed, I believe it was left out here because it seems quite > evident that the presenter needs to be involved when talking about > proof-of-possession. I guess the idea is that the coordination happens "in-band" when the CWT is issued, so I don't see a need for text changes here, given this discussion. > > > When an issuer creates a CWT containing a Key ID claim, it needs to > > make sure that it does not issue another CWT containing the same Key > > ID with a different content, or for a different subject, within the > > lifetime of the CWTs, unless intentionally desired. Failure to do so > > may allow one party to impersonate another party, with the potential > > to gain additional privileges. Likewise, if PoP keys are used for > > > > nit: "same Key ID with a different content" doesn't seem quite right, as > > the "content" of a Key ID is surely the key-ID value itself. Perhaps > > "referring to" would be more appropriate. > > What is meant here is different _other_ content, i.e. other claims such > as the scope and audience claims. I will try to rephrase this to clarify. "adjacent" or "sibling" content might work, brainstorming some ideas. > > I think we should probably give the reader some indication of what > > semantics might be attributed to the "intentionally desired" case. It > > doesn't necessarily need to be a specific example, but we could say what > > the relevant properties/attributes that might lead to such a situation > > would be. > > > Ok I'll add an few sentences to describe the example we had in mind, > where several CWTs are bound to the same key for the same presenter. Thanks. > > > multiple different kinds of CWTs in an application and the PoP keys > > are identified by Key IDs, care must be taken to keep the keys for > > the different kinds of CWTs segregated so that an attacker cannot > > cause the wrong PoP key to be used by using a valid Key ID for the > > wrong kind of CWT. > > > > Audience restrictions can come into play here, too, right? In that a > > restricted audience of all the CWTs in turn limits the scope of > > administration in which this care/segregation needs to be enforced. > > > > Correct, we should add a sentence here to suggest this as one strategy > to limit this risk. > > > 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? > > > Section 7.2.1 > > > > Change Controller: > > For Standards Track RFCs, list the "IESG". For others, give the > > name of the responsible party. Other details (e.g., postal > > address, email address, home page URI) may also be included. > > > > In light of the GDPR and similar regulations (and, as is done in RFC 8602), we > > may not want to keep all of these, especially postal address, given the lack of > > a clear need. > > > > Ok I'll have a look at how it is done in RFC 8602 and adapt this text > accordingly. > > > > Specification Document(s): > > Reference to the document or documents that specify the parameter, > > preferably including URIs that can be used to retrieve copies of > > > > Is the reference required to be publicly accessible? If not, is it > > required that a copy be made available to the experts and IANA? > > > > I think that at least the experts and IANA should be able to inspect a > copy, how are they going to do their job otherwise? > Do you want us to take any textual action here or was this just a > general remark? I think it is good to have some textual action to make that explicit. Then people submitting registration requests are less likely to be surprised... > > Section 7.2.2 > > > > o Confirmation Method Name: "Encrypted_COSE_Key" > > o Confirmation Method Description: Encrypted COSE_Key > > o JWT Confirmation Method Name: "jwe" > > o Confirmation Key: 2 > > o Confirmation Value Type(s): COSE_Encrypt or COSE_Encrypt0 > > structure (with an optional corresponding COSE_Encrypt or > > COSE_Encrypt0 tag) > > > > Do we want to say something about how, in the case when the tag is > > omitted, the application protocol specification needs to indicate how to > > determine which one is in use? > > > As a result of your subsequent discussion with Jim I am inclined to > leave this as it is. Is that acceptable for you? Yes! > > Section 8.2 > > > > I think [JWT] needs to be normative, as we have a SHOULD-level > > requirement for the audience restriction procedures it specifies. > > > I agree with Jim's assessment that an indirect normative reference via > the CWT RFC is sufficient. > > > I just want to check that it's intentional/desired to mix descriptive > > reference tags (e.g., [JWS]) and RFC-number tags (e.g., [RFC7800]) for > > the referenced RFCs. > > > I'm more inclined to have RFC number tags (makes it easier to look them > up without going via the bibliography), but it's mostly a matter of > taste. Do you think we should use one or the other consistently? I don't mind the current status (or all-RFC-number tags, for that matter); I just wanted to check that the "inconsistency" was intentional. > > Acknowledgements, Authors > > > > The datatracker is currently accepting XML v3 format drafts, and the RFC > > Editor's target cutover date for the end of August is quite soon, so > > feel free to consider using an XML v3 submission with UTF-8 > > representations of names not well represented by the ASCII subset. > > > It broke some older version of xml2rfc at some earlier point (the > default one coming with Ubuntu distros), but since I got that fixed now, > I'm inclined to give Göran his umlaut. :) Thanks, Ben From nobody Mon Aug 12 22:50:44 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DA6B120089; Mon, 12 Aug 2019 22:50:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=risecloud.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EFc23-UPjXge; Mon, 12 Aug 2019 22:50:40 -0700 (PDT) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80051.outbound.protection.outlook.com [40.107.8.51]) (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 A75D0120077; Mon, 12 Aug 2019 22:50:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=cDg3HeTAPBKIwD0tnWRAf2qoTdvybyrdfHJF3t/Pj3RnRz4ZbtYezEMZ8a17V3KHg3m2ifcanlAmUzVe2oF1+dPTuI/OLapwYpLH05NiMFLMel2hc6dnth55FGv54OwYHcG4NWy8Nr+/asDp5S+6bg0LkPmftYCgNeX7DXnRTUbSDeUecyHG/Qb73rCqUjMUYGaTPaUrxw1+0ia5cuijw8sATXbDhHvkYxkO0mobkiO7MS8ULzXVjMVI15GL9kJKh+hONMDtl0qwgwD2Ij9gMSjtT8Q6Mnivfl2c02+Z0VDR5mxYYaxeUp1BZcneWGlSAiDB2Wbb+hFTT9A9qi7gdA== 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=0nig//G6/VKx3pQBvEpBzA7O+VYGm7x1rPOvTNa0SrY=; b=oTVD7DXdhFVwY8ypGJ4xwzarnDGZwYO7z5rBABnHMupR0d5aKE27zDc9aaNRL0UshX52/T5hvjDQZKnkNzDJyApY+y2QZ35hIoj39iwBzsJhdjLzcj2mPhp4XUbsOeIcVn+aTuN35lscfx5odGRTKeUh0hxq7XOmCganWZor0OZ1tLPe3sz3xb+q/i/+Bc/+gReLDTeoF8eobP+dSJAyizqz0w7iYmBRKI7YHIy1fzgHmgJkqZc+3olM0ildg/6L8CoWUZ9R4CQyV5nxzYPXJvOKHe9fmBGkyMBEEqQL0XS4N1IsS9SS71OWvnMt860Z/F+wuOKzSLUYWR9ScQPDFQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 194.218.146.197) smtp.rcpttodomain=ietf.org smtp.mailfrom=ri.se; dmarc=bestguesspass action=none header.from=ri.se; dkim=none (message not signed); arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=RISEcloud.onmicrosoft.com; s=selector2-RISEcloud-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=0nig//G6/VKx3pQBvEpBzA7O+VYGm7x1rPOvTNa0SrY=; b=iOQHkRlKRWlf8Ry6QaDx1xOvOY+kPjxqXLGJp2pBH+uCvOIWj5NXs3GfEtJqfPQyysUlktE/Wbyb25epsDKJmyw2n3xwCjfAo0lHlfYNgZS+Ey41japrhug2dPxVXMINKAS+Gl1USYGcZE6HU+cqgwMUMSS5WFfSCJvUJy+Qd9c= Received: from HE1P18901CA0001.EURP189.PROD.OUTLOOK.COM (2603:10a6:3:8b::11) by AM5P18901MB0212.EURP189.PROD.OUTLOOK.COM (2603:10a6:203:7a::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2157.14; Tue, 13 Aug 2019 05:50:36 +0000 Received: from AM5EUR02FT050.eop-EUR02.prod.protection.outlook.com (2a01:111:f400:7e1e::200) by HE1P18901CA0001.outlook.office365.com (2603:10a6:3:8b::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2157.14 via Frontend Transport; Tue, 13 Aug 2019 05:50:35 +0000 Authentication-Results: spf=pass (sender IP is 194.218.146.197) smtp.mailfrom=ri.se; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=ri.se; Received-SPF: Pass (protection.outlook.com: domain of ri.se designates 194.218.146.197 as permitted sender) receiver=protection.outlook.com; client-ip=194.218.146.197; helo=mail.ri.se; Received: from mail.ri.se (194.218.146.197) by AM5EUR02FT050.mail.protection.outlook.com (10.152.9.252) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.20.2157.15 via Frontend Transport; Tue, 13 Aug 2019 05:50:35 +0000 Received: from [10.112.134.122] (10.100.0.158) by sp-mail-2.sp.se (10.100.0.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Tue, 13 Aug 2019 07:50:34 +0200 To: Carsten Bormann CC: Benjamin Kaduk , , References: <20190730155605.GM47715@kduck.mit.edu> <92fc4816-3447-62e3-e2fa-e6d92ea772e3@ri.se> From: Ludwig Seitz Message-ID: <46e6b3ec-8812-fa19-84b4-dde3933cd061@ri.se> Date: Tue, 13 Aug 2019 07:50:24 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms090204000004080407010100" X-Originating-IP: [10.100.0.158] X-ClientProxiedBy: sp-mail-3.sp.se (10.100.0.163) To sp-mail-2.sp.se (10.100.0.162) X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:194.218.146.197; IPV:NLI; CTRY:SE; EFV:NLI; SFV:NSPM; SFS:(10009020)(4636009)(396003)(136003)(346002)(376002)(39860400002)(2980300002)(199004)(189003)(22746008)(6246003)(4326008)(8676002)(2616005)(478600001)(446003)(11346002)(81166006)(81156014)(229853002)(5660300002)(64126003)(65806001)(65956001)(2906002)(106002)(16576012)(235185007)(54906003)(44832011)(486006)(58126008)(31686004)(5000100001)(316002)(8936002)(126002)(70206006)(70586007)(336012)(476003)(6116002)(568964002)(31696002)(386003)(36756003)(53546011)(16586007)(65826007)(6916009)(86362001)(3846002)(22756006)(356004)(16526019)(186003)(53936002)(14444005)(7736002)(71190400001)(5024004)(26005)(76176011)(305945005)(33964004)(40036005)(6666004); DIR:OUT; SFP:1101; SCL:1; SRVR:AM5P18901MB0212; H:mail.ri.se; FPR:; SPF:Pass; LANG:en; PTR:InfoDomainNonexistent; A:1; MX:1; X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: bc868851-b87a-4614-63ce-08d71fb2295a X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600148)(711020)(4605104)(4709080)(1401327)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:AM5P18901MB0212; X-MS-TrafficTypeDiagnostic: AM5P18901MB0212: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:7691; X-Forefront-PRVS: 01283822F8 X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Message-Info: ClyBRBvDAvlKOuAC4wrvZKISXzbWYh4DsWnI1Ww3V4zXu9JinEjRXolrtPQlKdcIaWzPzgOM65z0k+ezToKNFp8MSUsjNNOO6kEgPdwKCZtvdp4wJY8LQd/hRQKgF1aSJvQt8UTk3pcJBUj42R6JUDuMjk8qWP3NsnLYWX/3GhVL1o8lFEurZnhHDezUQ6sCNQ+z2FQIjiWupMAaVvecNqrFc83mYIRyot46tJdy6m0sY2Aafv2eo3d0cPbt1E68G1sZivWmX5Lfnw41+tjEzqegxPN6DjGoSX1bu/kL0wCRtiBqJMXhWw2XVpQ0Vn6ekAEN1+r7Vooqq7QENC0tqx+4q3puwn+sEBTfGq6N51syi1rnY7bJreUntFB2tLdH26xQVU7YQI74qto8OLb7wEYZwJo5VwS7ddiQLB6RkmU= X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Aug 2019 05:50:35.3452 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: bc868851-b87a-4614-63ce-08d71fb2295a X-MS-Exchange-CrossTenant-Id: 5a9809cf-0bcb-413a-838a-09ecc40cc9e8 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=5a9809cf-0bcb-413a-838a-09ecc40cc9e8; Ip=[194.218.146.197]; Helo=[mail.ri.se] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5P18901MB0212 Archived-At: 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2019 05:50:44 -0000 --------------ms090204000004080407010100 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 12/08/2019 23:59, Carsten Bormann wrote: > On Aug 12, 2019, at 14:08, Ludwig Seitz wrote: >> >> As far as I gather from the comments (especially from Carsten), we'd s= olve this by referencing section 6 of RFC 7049. I will consult with my co= -authors, but I think this is the right solution. >=20 > That is not what I said. >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 Sorry, hasty copy-paste of the wrong reference (the right one came later in=20 your email: Appendix G of RFC 8610). I blame Monday morning after the holidays ... /Ludwig --=20 Ludwig Seitz, PhD Security Lab, RISE Phone +46(0)70-349 92 51 --------------ms090204000004080407010100 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DT0wggYWMIID/qADAgECAg8BaKlzCTJTye3phLaz/cIwDQYJKoZIhvcNAQELBQAwRzELMAkG A1UEBhMCU0UxFDASBgNVBAoMC1RlbGlhU29uZXJhMSIwIAYDVQQDDBlUZWxpYVNvbmVyYSBD bGFzcyAyIENBIHYyMB4XDTE5MDIwMTE0MjUxNVoXDTIxMDIwMTE0MjUxNFowgYsxCzAJBgNV BAYTAlNFMS4wLAYDVQQKDCVSSVNFIFJlc2VhcmNoIEluc3RpdHV0ZXMgb2YgU3dlZGVuIEFC MRUwEwYDVQQDDAxMdWR3aWcgU2VpdHoxEjAQBgNVBAUTCUx1ZHdpZ1NlaTEhMB8GCSqGSIb3 DQEJARYSbHVkd2lnLnNlaXR6QHJpLnNlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAlJNmRfcsto5I/yXrBIi9QroZtfAMttc1Eznv5iPCK++eFUArODhITO7k9rtlQX5D8vYF v4vzZex58YWZhvGMzDj9FdpD/PHKOxL/frlrreChuissPWo5M88DmL3V1oyGzvgeRqaafpEi 0/2+gezMFlABm/BXj3/0Fiw5Sxub7essE27EtDK05nAbUB69kfLHBEytbTAuuSb11hC1dpTf itMZkzSFwsBCyPtIv3GRt9xgnOPK4RRpHidv1GLYXNQQ7xEGhFy4qbZ2NSfM+56SSRswvW9P 5n81ZmZ4FWkiJouUIYtZ2ifncBJL4DC2chjsywDEz5No7kYrGxc5oOm1YQIDAQABo4IBuDCC AbQwHwYDVR0jBBgwFoAUnhn/5Q06/gCXFT9p8dxaPKoMlIMwHQYDVR0OBBYEFKZHZ8MZNNP5 tXMPjeFiw01pUWbtMA4GA1UdDwEB/wQEAwIFoDBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEB DDA6MDgGCCsGAQUFBwIBFixodHRwczovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEu Y29tL0NQUzAdBgNVHREEFjAUgRJsdWR3aWcuc2VpdHpAcmkuc2UwTQYDVR0fBEYwRDBCoECg PoY8aHR0cDovL2NybC0yLnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYWNsYXNz MmNhdjIuY3JsMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjB+BggrBgEFBQcBAQRy MHAwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnRydXN0LnRlbGlhLmNvbTBFBggrBgEFBQcw AoY5aHR0cDovL2NhLnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYWNsYXNzMmNh djIuY2VyMA0GCSqGSIb3DQEBCwUAA4ICAQCk0GOalOCjEJObuBeMg0QREtBP/2ona16npn+T v5R3Vjk5UsQdOaOosgVjADX68C83dyfPiWR4UfNJoTBcM8JLpEXIm+xC4BiDPTPHYvgkhgXt 9VWCRWXOMfT/UPXjiGsbPuNWja1LQzF5KOmM826kHVZItHuDY6kJLE4OZ+apFvVKtSLQJJLA 4MlDVwp5+XsZi4cftcX5HdgLdChodUPKq3XVfALfXM/p81XEFBTYOHNplr3cQytDQjsnCZnS Ic4UpsxrArNxDO9+AKu/s1Fbq494AhHj4oHcg4DIjhHUzbPCLP19Gqp4dflr/V7Ulg3d+4Zh bmSAn1cffrzvvkjVrqMgQOoHQTl2QyO9n/oJ/9CSYRmhFsQMPun9LM/p5l58dTZp53B3LgA6 FFrxnntlZnTPh3bvsMJvUQ+AoiXyQwnkdxUrhoM+gUz36t3JSA8g48h7BhPsnwQ/YrarAhJ8 ifuzykTQmDseWLjJKyFflddy/azAlPQjgSMMWOZCo2s+l+WwPISf33nls2Aec/vvG5auYHS6 pwWuVKuwZTPgJfHanZTNpBM5y0jVBz6tr8AHZypnCONgyUYA4uec3v5oWz4FvLEnlKnMGoK3 OeFGvfHG0tbP25HbdN3AJYP0EUo56wfkBOYsnmn4mEYdk2GHkJNfaQRBJljH0T7TOcmcDjCC Bx8wggUHoAMCAQICEGN8C9eFpb8p2mAtfE16cLEwDQYJKoZIhvcNAQELBQAwNzEUMBIGA1UE CgwLVGVsaWFTb25lcmExHzAdBgNVBAMMFlRlbGlhU29uZXJhIFJvb3QgQ0EgdjEwHhcNMTQx MDE2MDgzOTMwWhcNMzIxMDE2MDUwNDAwWjBHMQswCQYDVQQGEwJTRTEUMBIGA1UECgwLVGVs aWFTb25lcmExIjAgBgNVBAMMGVRlbGlhU29uZXJhIENsYXNzIDIgQ0EgdjIwggIiMA0GCSqG SIb3DQEBAQUAA4ICDwAwggIKAoICAQC0PpW2qcWGnStqfa5DjrUi79Kz2SySUlJ1kiEQ1Pd/ LWbnsEwFYPqOJwAf6ZtEDtQ/9Z1VkVNQ6MkD++keqk7648x0YANgMyiJsWrbd0TKOObtlXdJ pb5qesJ5nOAdVeL3z6lgrkZx+fsUfTV+lLRGRh2+RWzZTjPAvKotY3nAwXCHtwI5v3FKuR10 aJ9+CEOka02KSUzGjcGZwMk2io0DxLELf1gPRvqE9xmn4ioXLqpluozb4Fo9ewydufTLQc3/ I63uPQh8BlLPPIGzWb4iBDq2zbWlbx0KlH/UlUZ7fjzp6N6cAqZ2NnDaCOnnIRfUYeNXFG8/ aiBeFOpEeEpclr5QUwr9HLKL1QiyQtc/wW8acQFoKuGi8myiAch7k7S0rmU5gT05je+OTzWh Oaw7gmDdndYY1mjkPkzpQ+hxyfnwUsAitUq9j0imFOLxKWLH4QNbyuDIMvDyezzJWzMy3XPB LiLSH9CBLVQHRoQ+WW8xD4rnmvQtoGZM72og2iNf4/JCHL1AJYhQtaRjYgm3rhvAP0HhSVAB Z5aHM52ylJHC3JwUyuFm8S9A2ffY9rUTffMLWmDCnX0QAP9bKr6+ACogm4DBUj3ftYodI2TD 6F8+VjSFuCzGDPuCjK+fQ2c3wqziwFl+NgoGI9Vgc6x5+0ocKkiQAIYFaQ3SyGmI6QIDAQAB o4ICFTCCAhEwgYoGCCsGAQUFBwEBBH4wfDAtBggrBgEFBQcwAYYhaHR0cDovL29jc3AudHJ1 c3QudGVsaWFzb25lcmEuY29tMEsGCCsGAQUFBzAChj9odHRwOi8vcmVwb3NpdG9yeS50cnVz dC50ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5jZXIwEgYDVR0TAQH/BAgw BgEB/wIBADBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEBAjA6MDgGCCsGAQUFBwIBFixodHRw czovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQUzAOBgNVHQ8BAf8EBAMC AQYwgcYGA1UdHwSBvjCBuzBAoD6gPIY6aHR0cDovL2NybC0zLnRydXN0LnRlbGlhc29uZXJh LmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNybDB3oHWgc4ZxbGRhcDovL2NybC0xLnRydXN0 LnRlbGlhc29uZXJhLmNvbS9jbj1UZWxpYVNvbmVyYSUyMFJvb3QlMjBDQSUyMHYxLG89VGVs aWFTb25lcmE/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnkwHQYDVR0OBBYEFJ4Z /+UNOv4AlxU/afHcWjyqDJSDMB8GA1UdIwQYMBaAFPCPWTgAs/WPmpYM1ev6e6oX6BMSMA0G CSqGSIb3DQEBCwUAA4ICAQB5wuZFNXR5ko9cu7PcpIyH8xaoGfpimP2GTg7qVuL92D/idIlj pqMm93WC9mgL/Uy6DExoF8xSLurLaiajoU+VG6ZWg0F7P1AXARNt0RpWI5SphxBQYM2751S8 vC/22k8Vi+qpQVIREqQPVXCIEH7U6eCY9gEVzdq9l1yPoI8n0D2a8V6GCv0RVkmIpa16rNYD tTw4j3Ha56/Ua33C3qeZh1dIfkaU2h4CGHd2Em3v5LLMsEh8dqUeG9yIcCU+8RUgDahNxWMe MGxzrhwk8WBV6xeoQp20p7cSHbSbyHJURC1n+nVrgdh8hbw6WOgFhNA5tCPDZ0oSF+uHfj+b ioZE3AlYdcEqHJA9A9sO58F4/Qg/yp9oYuT0ZpKb4hmzeqDXvk5KRFNfHlhTt35i+qmas9wB 11MXbYd5WwqEhZH6HWO5H7XKJP7olxmEC0W3OKlpKafq1iPsBN5ycRfUrXFss0Ax6vpCq0XA 3LYePpQ44hOU+qrkR1M0a7Eo3++3TpP4cV+FZiO4aZYZ3yZftSRHwWpGiDBdWOdTKR2GJi7Z z/OxacrmwmM1Z+WcigldbG8f3IMnOLK4X0uXjhVeAHrhuttQuM8i+4TNXgsZbmfEKNDQIQPO /lbacsGHWFB/U2y6SXVEkZs2xIciRA0iZNTv7mbIL8SZmf5wpbjDCYHiCjGCAzgwggM0AgEB MFowRzELMAkGA1UEBhMCU0UxFDASBgNVBAoMC1RlbGlhU29uZXJhMSIwIAYDVQQDDBlUZWxp YVNvbmVyYSBDbGFzcyAyIENBIHYyAg8BaKlzCTJTye3phLaz/cIwDQYJYIZIAWUDBAIBBQCg ggGvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE5MDgxMzA1 NTAyNFowLwYJKoZIhvcNAQkEMSIEIOibATKkVcS/46G/7ckmIOGSzBj/nhbawF4A2eLRiSPB MGkGCSsGAQQBgjcQBDFcMFowRzELMAkGA1UEBhMCU0UxFDASBgNVBAoMC1RlbGlhU29uZXJh MSIwIAYDVQQDDBlUZWxpYVNvbmVyYSBDbGFzcyAyIENBIHYyAg8BaKlzCTJTye3phLaz/cIw awYLKoZIhvcNAQkQAgsxXKBaMEcxCzAJBgNVBAYTAlNFMRQwEgYDVQQKDAtUZWxpYVNvbmVy YTEiMCAGA1UEAwwZVGVsaWFTb25lcmEgQ2xhc3MgMiBDQSB2MgIPAWipcwkyU8nt6YS2s/3C MGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0D BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwIC ASgwDQYJKoZIhvcNAQEBBQAEggEAdDxKIMU2rPXiWVvkpxmqVzpm2K6/Jp07ZQ+r2m9KrTAx Zr6uF35V9PJ3+dGRdD+qhST6Tm2kS3a5BKZsXkXJIfd1S2o3FGfzAke3q0+NOUt8ZQ6KNaEe wfEWbD3CCSZNecQkFSrYfD6fNYMU9t4i4VNFX027Oy5ISQWruOlUHca1F2wDJAM/xVU3NO5Y 1nnYYk3IozQM3UPPGKnaiPDecZHY2R8xYnznfNpG4AgYtSeR1Uol0RulewpNSHdypB6q2jUQ yDE7wHAgR5h92NGPgssL3pFna+D1zOPu46C+B+JlsfUo8DGsejdMAX98rw9F7+AE+1gLoQk5 T0CpA7UekwAAAAAAAA== --------------ms090204000004080407010100-- From nobody Mon Aug 19 13:41:09 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C740812016E for ; Mon, 19 Aug 2019 13:41:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SNzf8GhY21P2 for ; Mon, 19 Aug 2019 13:41:06 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04625120048 for ; Mon, 19 Aug 2019 13:41:06 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 19 Aug 2019 13:41:00 -0700 From: Jim Schaad To: Date: Mon, 19 Aug 2019 13:40:58 -0700 Message-ID: <01fc01d556ce$69f73cc0$3de5b640$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdVWyjz3vcmK8hoCQY6gnIkskr9oiw== Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: [Ace] Keeping the same key identifier for groups X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2019 20:41:08 -0000 As Ludwig pointed out during the F2F, it makes far more sense to try and keep an entity using the same key identifier for as long as possible. This is in part to make sure that signing keys do not need to be retrieved if they can be easily cached. In looking at this deeper during my implementation I ended up with the following question: The way that I have set things up in my implementation it is simple to ensure that the same kid value is going to be used with the same CWT, however it might make more sense to use the signing key as the continuity identifier instead. The issue that arises in this case is that there might be two different active CWT objects that are associated with the same signing key. That is there are two CWTs but the same signing key was used while doing a join operation. I already do some matching between different CWTs by assuming that if the bearer key in the CWT is the same then they are sufficiently equivalent to threat them as the same. This lead to some interesting discussions in Montreal about if this meant just the "secret" or if it meant all of the elements provided by the AS which are used in the key derivation process. (I have gone back and forth on this and currently am sitting on the "just the secret" side of the fence.) Does anyone have any opinions? Jim From nobody Tue Aug 20 02:09:27 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41E7B120072 for ; Tue, 20 Aug 2019 02:09:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=risecloud.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NMc-l4L1zjnX for ; Tue, 20 Aug 2019 02:09:22 -0700 (PDT) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70058.outbound.protection.outlook.com [40.107.7.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D77A2120041 for ; Tue, 20 Aug 2019 02:09:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=WBJJDKZ+9IhGT1vRjmi4i3YNwz2PGRgE9iT3gOE3XK29oRcTg828AakD6/CvqlKjh6JDLNC74T1rzSHU616Jo/nq7EwRmJmhMOSIpcThPCDqO6OqsVi6EHuwLFDcpgNRkGSXZrk/nknd12a1JcbdIejKF5aevRwnbQYmWy616+dsWV17j34SFeXduHdtpSPsN1+wDAuU0xP1G04Mgv3UsjgmYMMoCCT3J+jwE+3Hb/Rh9BkNe7ZTB+Erdp7GiBCqaBLCSxOIUn2X3ZBx2qrRf5SxAC/DAo4zkQotoZbF3VH+PIffPDNNskJTp6to03AbNG3Sxg5gXku7396b/bKpeg== 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=D/Xx5yD7axveKXeMB2xVydlvWjX+IqQRidzZe9QG1IY=; b=Q9ZteDkGZOneycM+Mii+5c6AwhtYSL1ESuUuU7V38n6HlZb0JvdSNoIARn/TlWRlMO0RpCx2Xx6e39hlEmIw31Sct2KzXX+hWHNqkhmTphCpr+enNM9D1saZNNDWT7Osg4etgJI9e+NVODL+Fe1QP9OT2v5QVvj0+zDS5V1XsdqxaBZII8WrcE94UTyKx6yG5j7hGOO9+wtz7RynVkw4ffxg3kEDdmlgrNOvHaQ6NuyL5+pDcobkf2xXkQQi7gnDe/s8KiUESlJrhr/udHzzry0wJE+ExpiZtVbO2YCejXPT1qkfpnefpjIwHZHuHypJLFNxcr+koJE70MO/8Gq72A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 194.218.146.197) smtp.rcpttodomain=ietf.org smtp.mailfrom=ri.se; dmarc=pass (p=none sp=none pct=100) action=none header.from=ri.se; dkim=none (message not signed); arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=RISEcloud.onmicrosoft.com; s=selector2-RISEcloud-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=D/Xx5yD7axveKXeMB2xVydlvWjX+IqQRidzZe9QG1IY=; b=JXqhKQRDWWZFoXhvrOy05LEyS8EQp6keTmBPy7WZjgnoAcD4fZTVaCH7D4jeWbE5frC0kuwVkTbutwg/kKKiMSBj6363Vxv4wUD7a1tf/N6g8NOrcRCgjgM7H6Z/bAoblTXpg1urwkTR/5S7TZrVJ3cS0rml7wG6+tltX45Kb4A= Received: from HE1P18901CA0023.EURP189.PROD.OUTLOOK.COM (2603:10a6:3:8b::33) by AM0P189MB0754.EURP189.PROD.OUTLOOK.COM (2603:10a6:208:1a2::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2178.16; Tue, 20 Aug 2019 09:09:19 +0000 Received: from VE1EUR02FT053.eop-EUR02.prod.protection.outlook.com (2a01:111:f400:7e06::203) by HE1P18901CA0023.outlook.office365.com (2603:10a6:3:8b::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.2178.16 via Frontend Transport; Tue, 20 Aug 2019 09:09:18 +0000 Authentication-Results: spf=pass (sender IP is 194.218.146.197) smtp.mailfrom=ri.se; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=pass action=none header.from=ri.se; Received-SPF: Pass (protection.outlook.com: domain of ri.se designates 194.218.146.197 as permitted sender) receiver=protection.outlook.com; client-ip=194.218.146.197; helo=mail.ri.se; Received: from mail.ri.se (194.218.146.197) by VE1EUR02FT053.mail.protection.outlook.com (10.152.13.137) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.20.2178.16 via Frontend Transport; Tue, 20 Aug 2019 09:09:17 +0000 Received: from [10.112.134.122] (10.100.0.158) by sp-mail-2.sp.se (10.100.0.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Tue, 20 Aug 2019 11:09:16 +0200 To: References: <01fc01d556ce$69f73cc0$3de5b640$@augustcellars.com> From: Ludwig Seitz Message-ID: <01a391d0-8e6d-82cf-8f59-5a3e4d9f5605@ri.se> Date: Tue, 20 Aug 2019 11:09:16 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <01fc01d556ce$69f73cc0$3de5b640$@augustcellars.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms010703070505030004090004" X-Originating-IP: [10.100.0.158] X-ClientProxiedBy: sp-mail-1.sp.se (10.100.0.161) To sp-mail-2.sp.se (10.100.0.162) X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:194.218.146.197; IPV:NLI; CTRY:SE; EFV:NLI; SFV:NSPM; SFS:(10009020)(4636009)(376002)(39860400002)(346002)(136003)(396003)(2980300002)(189003)(199004)(70586007)(16526019)(26005)(186003)(53936002)(386003)(53546011)(126002)(476003)(6246003)(486006)(33964004)(305945005)(76176011)(336012)(446003)(7736002)(11346002)(2616005)(478600001)(6916009)(5660300002)(2351001)(235185007)(65826007)(31686004)(5024004)(36756003)(14444005)(106002)(229853002)(568964002)(16586007)(316002)(2906002)(65956001)(65806001)(81166006)(22756006)(81156014)(40036005)(16576012)(6116002)(8936002)(70206006)(8676002)(356004)(22746008)(58126008)(71190400001)(31696002)(64126003)(44832011)(86362001)(3846002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0P189MB0754; H:mail.ri.se; FPR:; SPF:Pass; LANG:en; PTR:InfoDomainNonexistent; MX:1; A:1; X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: d4ed5141-cd6b-48b7-61e4-08d7254e145d X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(4709080)(1401327)(2017052603328)(7193020); SRVR:AM0P189MB0754; X-MS-TrafficTypeDiagnostic: AM0P189MB0754: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-Forefront-PRVS: 013568035E X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Message-Info: SCnHY2qgnNql+mUURpfiLCtFEJ+f6+VmFnHS+Qbsw0QRRkIRswu/YNOm4ObUwOj50F6ZuDCnJyP7gowxIGtZVaCpNYf8PBjP6pHDjeS2EB+iUuYiRvGenMCsSCefqpA2Yv8Lc+Rsd3iEIiN69FBB6jaZOi1a5MXseIm7x7CUYKA9HDAurqx0Z6LdBkUnNq2QqXBXWdm6zoNljpskCSOGnhwM7QoJZdqfg5bGo047YDawSJGQxmbZOKiskF3Is+t9/Zf+gAx1E74bakJGYILRfEizcE02ET4MN/GtfdblvadOCesN1tF/LPVE3KpYiVqytO2PoMOXMnna2UWV1hq/+D0IyWmDzEuCuulXHi17p0XEyAsBXO1NoCYTyWUmt49neSd4oXCi6iFtpgguVT+1ZhagCrXr+fsHmjh52rjSz5o= X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Aug 2019 09:09:17.4524 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: d4ed5141-cd6b-48b7-61e4-08d7254e145d X-MS-Exchange-CrossTenant-Id: 5a9809cf-0bcb-413a-838a-09ecc40cc9e8 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=5a9809cf-0bcb-413a-838a-09ecc40cc9e8; Ip=[194.218.146.197]; Helo=[mail.ri.se] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0P189MB0754 Archived-At: Subject: Re: [Ace] Keeping the same key identifier for groups X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2019 09:09:25 -0000 --------------ms010703070505030004090004 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 19/08/2019 22:40, Jim Schaad wrote: > As Ludwig pointed out during the F2F, it makes far more sense to try an= d > keep an entity using the same key identifier for as long as possible. = This > is in part to make sure that signing keys do not need to be retrieved i= f > they can be easily cached. In looking at this deeper during my > implementation I ended up with the following question: >=20 > The way that I have set things up in my implementation it is simple to > ensure that the same kid value is going to be used with the same CWT, > however it might make more sense to use the signing key as the continui= ty > identifier instead. The issue that arises in this case is that there m= ight > be two different active CWT objects that are associated with the same > signing key. That is there are two CWTs but the same signing key was u= sed > while doing a join operation. I already do some matching between diff= erent > CWTs by assuming that if the bearer key in the CWT is the same then the= y are > sufficiently equivalent to threat them as the same. This lead to some > interesting discussions in Montreal about if this meant just the "secre= t" or > if it meant all of the elements provided by the AS which are used in th= e key > derivation process. (I have gone back and forth on this and currently = am > sitting on the "just the secret" side of the fence.) >=20 > Does anyone have any opinions? >=20 Could you please expand the explanation of your use case a bit? Are you thinking of a scenario where someone would be using the=20 counter-signature key from group-OSCORE as a proof-of-possession (pop)=20 key in serveral CWTs? What would these CWT authorize? Why would an entity hold several CWTs for the same audience? Side-note: My stance on multiple CWTs linked to the same pop-key and for the same=20 audience is that the latter one should supersede the previous ones. Example: If you have a CWT authorizing A for audience Z and you now also = need authorization B for audience Z, you should request a CWT for A+B=20 for audience Z, that replaces your previous one. /Ludwig --=20 Ludwig Seitz, PhD Security Lab, RISE Phone +46(0)70-349 92 51 --------------ms010703070505030004090004 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DT0wggYWMIID/qADAgECAg8BaKlzCTJTye3phLaz/cIwDQYJKoZIhvcNAQELBQAwRzELMAkG A1UEBhMCU0UxFDASBgNVBAoMC1RlbGlhU29uZXJhMSIwIAYDVQQDDBlUZWxpYVNvbmVyYSBD bGFzcyAyIENBIHYyMB4XDTE5MDIwMTE0MjUxNVoXDTIxMDIwMTE0MjUxNFowgYsxCzAJBgNV BAYTAlNFMS4wLAYDVQQKDCVSSVNFIFJlc2VhcmNoIEluc3RpdHV0ZXMgb2YgU3dlZGVuIEFC MRUwEwYDVQQDDAxMdWR3aWcgU2VpdHoxEjAQBgNVBAUTCUx1ZHdpZ1NlaTEhMB8GCSqGSIb3 DQEJARYSbHVkd2lnLnNlaXR6QHJpLnNlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAlJNmRfcsto5I/yXrBIi9QroZtfAMttc1Eznv5iPCK++eFUArODhITO7k9rtlQX5D8vYF v4vzZex58YWZhvGMzDj9FdpD/PHKOxL/frlrreChuissPWo5M88DmL3V1oyGzvgeRqaafpEi 0/2+gezMFlABm/BXj3/0Fiw5Sxub7essE27EtDK05nAbUB69kfLHBEytbTAuuSb11hC1dpTf itMZkzSFwsBCyPtIv3GRt9xgnOPK4RRpHidv1GLYXNQQ7xEGhFy4qbZ2NSfM+56SSRswvW9P 5n81ZmZ4FWkiJouUIYtZ2ifncBJL4DC2chjsywDEz5No7kYrGxc5oOm1YQIDAQABo4IBuDCC AbQwHwYDVR0jBBgwFoAUnhn/5Q06/gCXFT9p8dxaPKoMlIMwHQYDVR0OBBYEFKZHZ8MZNNP5 tXMPjeFiw01pUWbtMA4GA1UdDwEB/wQEAwIFoDBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEB DDA6MDgGCCsGAQUFBwIBFixodHRwczovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEu Y29tL0NQUzAdBgNVHREEFjAUgRJsdWR3aWcuc2VpdHpAcmkuc2UwTQYDVR0fBEYwRDBCoECg PoY8aHR0cDovL2NybC0yLnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYWNsYXNz MmNhdjIuY3JsMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjB+BggrBgEFBQcBAQRy MHAwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnRydXN0LnRlbGlhLmNvbTBFBggrBgEFBQcw AoY5aHR0cDovL2NhLnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYWNsYXNzMmNh djIuY2VyMA0GCSqGSIb3DQEBCwUAA4ICAQCk0GOalOCjEJObuBeMg0QREtBP/2ona16npn+T v5R3Vjk5UsQdOaOosgVjADX68C83dyfPiWR4UfNJoTBcM8JLpEXIm+xC4BiDPTPHYvgkhgXt 9VWCRWXOMfT/UPXjiGsbPuNWja1LQzF5KOmM826kHVZItHuDY6kJLE4OZ+apFvVKtSLQJJLA 4MlDVwp5+XsZi4cftcX5HdgLdChodUPKq3XVfALfXM/p81XEFBTYOHNplr3cQytDQjsnCZnS Ic4UpsxrArNxDO9+AKu/s1Fbq494AhHj4oHcg4DIjhHUzbPCLP19Gqp4dflr/V7Ulg3d+4Zh bmSAn1cffrzvvkjVrqMgQOoHQTl2QyO9n/oJ/9CSYRmhFsQMPun9LM/p5l58dTZp53B3LgA6 FFrxnntlZnTPh3bvsMJvUQ+AoiXyQwnkdxUrhoM+gUz36t3JSA8g48h7BhPsnwQ/YrarAhJ8 ifuzykTQmDseWLjJKyFflddy/azAlPQjgSMMWOZCo2s+l+WwPISf33nls2Aec/vvG5auYHS6 pwWuVKuwZTPgJfHanZTNpBM5y0jVBz6tr8AHZypnCONgyUYA4uec3v5oWz4FvLEnlKnMGoK3 OeFGvfHG0tbP25HbdN3AJYP0EUo56wfkBOYsnmn4mEYdk2GHkJNfaQRBJljH0T7TOcmcDjCC Bx8wggUHoAMCAQICEGN8C9eFpb8p2mAtfE16cLEwDQYJKoZIhvcNAQELBQAwNzEUMBIGA1UE CgwLVGVsaWFTb25lcmExHzAdBgNVBAMMFlRlbGlhU29uZXJhIFJvb3QgQ0EgdjEwHhcNMTQx MDE2MDgzOTMwWhcNMzIxMDE2MDUwNDAwWjBHMQswCQYDVQQGEwJTRTEUMBIGA1UECgwLVGVs aWFTb25lcmExIjAgBgNVBAMMGVRlbGlhU29uZXJhIENsYXNzIDIgQ0EgdjIwggIiMA0GCSqG SIb3DQEBAQUAA4ICDwAwggIKAoICAQC0PpW2qcWGnStqfa5DjrUi79Kz2SySUlJ1kiEQ1Pd/ LWbnsEwFYPqOJwAf6ZtEDtQ/9Z1VkVNQ6MkD++keqk7648x0YANgMyiJsWrbd0TKOObtlXdJ pb5qesJ5nOAdVeL3z6lgrkZx+fsUfTV+lLRGRh2+RWzZTjPAvKotY3nAwXCHtwI5v3FKuR10 aJ9+CEOka02KSUzGjcGZwMk2io0DxLELf1gPRvqE9xmn4ioXLqpluozb4Fo9ewydufTLQc3/ I63uPQh8BlLPPIGzWb4iBDq2zbWlbx0KlH/UlUZ7fjzp6N6cAqZ2NnDaCOnnIRfUYeNXFG8/ aiBeFOpEeEpclr5QUwr9HLKL1QiyQtc/wW8acQFoKuGi8myiAch7k7S0rmU5gT05je+OTzWh Oaw7gmDdndYY1mjkPkzpQ+hxyfnwUsAitUq9j0imFOLxKWLH4QNbyuDIMvDyezzJWzMy3XPB LiLSH9CBLVQHRoQ+WW8xD4rnmvQtoGZM72og2iNf4/JCHL1AJYhQtaRjYgm3rhvAP0HhSVAB Z5aHM52ylJHC3JwUyuFm8S9A2ffY9rUTffMLWmDCnX0QAP9bKr6+ACogm4DBUj3ftYodI2TD 6F8+VjSFuCzGDPuCjK+fQ2c3wqziwFl+NgoGI9Vgc6x5+0ocKkiQAIYFaQ3SyGmI6QIDAQAB o4ICFTCCAhEwgYoGCCsGAQUFBwEBBH4wfDAtBggrBgEFBQcwAYYhaHR0cDovL29jc3AudHJ1 c3QudGVsaWFzb25lcmEuY29tMEsGCCsGAQUFBzAChj9odHRwOi8vcmVwb3NpdG9yeS50cnVz dC50ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5jZXIwEgYDVR0TAQH/BAgw BgEB/wIBADBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEBAjA6MDgGCCsGAQUFBwIBFixodHRw czovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQUzAOBgNVHQ8BAf8EBAMC AQYwgcYGA1UdHwSBvjCBuzBAoD6gPIY6aHR0cDovL2NybC0zLnRydXN0LnRlbGlhc29uZXJh LmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNybDB3oHWgc4ZxbGRhcDovL2NybC0xLnRydXN0 LnRlbGlhc29uZXJhLmNvbS9jbj1UZWxpYVNvbmVyYSUyMFJvb3QlMjBDQSUyMHYxLG89VGVs aWFTb25lcmE/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnkwHQYDVR0OBBYEFJ4Z /+UNOv4AlxU/afHcWjyqDJSDMB8GA1UdIwQYMBaAFPCPWTgAs/WPmpYM1ev6e6oX6BMSMA0G CSqGSIb3DQEBCwUAA4ICAQB5wuZFNXR5ko9cu7PcpIyH8xaoGfpimP2GTg7qVuL92D/idIlj pqMm93WC9mgL/Uy6DExoF8xSLurLaiajoU+VG6ZWg0F7P1AXARNt0RpWI5SphxBQYM2751S8 vC/22k8Vi+qpQVIREqQPVXCIEH7U6eCY9gEVzdq9l1yPoI8n0D2a8V6GCv0RVkmIpa16rNYD tTw4j3Ha56/Ua33C3qeZh1dIfkaU2h4CGHd2Em3v5LLMsEh8dqUeG9yIcCU+8RUgDahNxWMe MGxzrhwk8WBV6xeoQp20p7cSHbSbyHJURC1n+nVrgdh8hbw6WOgFhNA5tCPDZ0oSF+uHfj+b ioZE3AlYdcEqHJA9A9sO58F4/Qg/yp9oYuT0ZpKb4hmzeqDXvk5KRFNfHlhTt35i+qmas9wB 11MXbYd5WwqEhZH6HWO5H7XKJP7olxmEC0W3OKlpKafq1iPsBN5ycRfUrXFss0Ax6vpCq0XA 3LYePpQ44hOU+qrkR1M0a7Eo3++3TpP4cV+FZiO4aZYZ3yZftSRHwWpGiDBdWOdTKR2GJi7Z z/OxacrmwmM1Z+WcigldbG8f3IMnOLK4X0uXjhVeAHrhuttQuM8i+4TNXgsZbmfEKNDQIQPO /lbacsGHWFB/U2y6SXVEkZs2xIciRA0iZNTv7mbIL8SZmf5wpbjDCYHiCjGCAzgwggM0AgEB MFowRzELMAkGA1UEBhMCU0UxFDASBgNVBAoMC1RlbGlhU29uZXJhMSIwIAYDVQQDDBlUZWxp YVNvbmVyYSBDbGFzcyAyIENBIHYyAg8BaKlzCTJTye3phLaz/cIwDQYJYIZIAWUDBAIBBQCg ggGvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE5MDgyMDA5 MDkxNlowLwYJKoZIhvcNAQkEMSIEIEQe3oaF6m7GmcWjwoXqke5/hkmUApNQRoikuB6jmro/ MGkGCSsGAQQBgjcQBDFcMFowRzELMAkGA1UEBhMCU0UxFDASBgNVBAoMC1RlbGlhU29uZXJh MSIwIAYDVQQDDBlUZWxpYVNvbmVyYSBDbGFzcyAyIENBIHYyAg8BaKlzCTJTye3phLaz/cIw awYLKoZIhvcNAQkQAgsxXKBaMEcxCzAJBgNVBAYTAlNFMRQwEgYDVQQKDAtUZWxpYVNvbmVy YTEiMCAGA1UEAwwZVGVsaWFTb25lcmEgQ2xhc3MgMiBDQSB2MgIPAWipcwkyU8nt6YS2s/3C MGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0D BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwIC ASgwDQYJKoZIhvcNAQEBBQAEggEAR/+rKdq6GXCaq46Yel1bdwIA7B2hKBrW0zeOp5vRX0aw ISjV74PZtu9h1c7fg75VzAv2CwRt/8SRzN5czIhq8lorUo2rvwajsUknF9lbzIvPJddxDdCP oJvO3PJeecTW8NA1cKUoMtrJunjGONYwv03DDxN8+gQpgBmHTN3n4UDmYQVOz2auXTn9Jc7D CVY8UszCMhXKUp0s6COTaMt7++lmfDeBmEUrN2L84FRczW/8Wv6ZFJhMBqFeEYgNa2uYlw2w rkZfZo3GlinV91XcPqMppQYbx7kHhtseCU4r3dnn/Yi3e7aH7MMTcEXWP6PqxKzwHAw2ZohN MZInmpB7rgAAAAAAAA== --------------ms010703070505030004090004-- From nobody Tue Aug 20 02:18:44 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD75012091E for ; Tue, 20 Aug 2019 02:18:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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=bbhmail.nl Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qK2-4Ipg0wtW for ; Tue, 20 Aug 2019 02:18:40 -0700 (PDT) Received: from smtprelay.hostedemail.com (smtprelay0069.hostedemail.com [216.40.44.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30107120024 for ; Tue, 20 Aug 2019 02:18:39 -0700 (PDT) Received: from filter.hostedemail.com (clb03-v110.bra.tucows.net [216.40.38.60]) by smtprelay06.hostedemail.com (Postfix) with ESMTP id 8B9F518225E1D; Tue, 20 Aug 2019 09:18:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bbhmail.nl; h= mime-version:content-type:date:from:to:cc:subject:reply-to :in-reply-to:references:message-id; s=key; bh=0q7OitqPf0pcqWcv7x 5yhJgPSgnjG5j92Rrw2bl2A9E=; b=ibNlO+Eu2DPAAQ+gzI4MHO05nJLmusdAvc xZcXiHUVvZlOyoHitHc9iPNIWltRyeCBUoReRodgTcmpcEyBxPhtgJe2WUi+RjsT r8mM2R5MmNF9GPp+33zGy4f601JeZZ/5LFdPp7EjYDlgGXDdWn3Pt+Sf58nh9iYe OiPt8N14k= X-Session-Marker: 73746F6B636F6E73406262686D61696C2E6E6C X-Spam-Summary: 2, -10, 0, , d41d8cd98f00b204, stokcons@bbhmail.nl, :::, RULES_HIT:1:2:41:72:152:355:379:582:599:800:962:967:973:983:988:989:1152:1189:1208:1212:1221:1260:1313:1314:1345:1359:1431:1436:1437:1516:1517:1518:1575:1588:1589:1592:1594:1730:1777:1792:2068:2069:2198:2199:2525:2527:2528:2559:2564:2682:2685:2692:2859:2903:2933:2937:2939:2942:2945:2947:2951:2954:3022:3138:3139:3140:3141:3142:3355:3865:3866:3867:3868:3870:3871:3872:3873:3874:3934:3936:3938:3941:3944:3947:3950:3953:3956:3959:4049:4250:4321:4860:5007:6117:6119:6261:6657:6659:6678:7875:7903:7904:8603:9010:9025:9036:9177:10004:10848:11232:11658:11914:12043:12291:12379:12438:12679:12683:12740:12895:13139:13439:13846:14095:14096:21080:21324:21433:21451:21627:30041:30054:30060, 0, RBL:216.40.42.5:@bbhmail.nl:.lbl8.mailshell.net-62.8.55.100 66.201.201.201, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF:not bulk, SPF:fn, MSBL:0, DNSBL:neutral, Custom_rules:0:0:0, LFtime:27, LUA_SUMMARY:none X-HE-Tag: scene41_688329d52fc1c X-Filterd-Recvd-Size: 10344 Received: from mail.bbhmail.nl (imap-ext [216.40.42.5]) (Authenticated sender: webmail@stokcons@bbhmail.nl) by omf19.hostedemail.com (Postfix) with ESMTPA; Tue, 20 Aug 2019 09:18:38 +0000 (UTC) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_d7c15ac00c89f4534d4346c4f9570ff1" Date: Tue, 20 Aug 2019 11:18:37 +0200 From: Peter van der Stok To: Ludwig Seitz Cc: ace@ietf.org Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <01a391d0-8e6d-82cf-8f59-5a3e4d9f5605@ri.se> References: <01fc01d556ce$69f73cc0$3de5b640$@augustcellars.com> <01a391d0-8e6d-82cf-8f59-5a3e4d9f5605@ri.se> Message-ID: X-Sender: stokcons@bbhmail.nl User-Agent: Roundcube Webmail/1.2.7 X-Originating-IP: [5.206.216.229] Archived-At: Subject: Re: [Ace] Keeping the same key identifier for groups X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2019 09:18:43 -0000 --=_d7c15ac00c89f4534d4346c4f9570ff1 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Example: If you have a CWT authorizing A for audience Z and you now also need authorization B for audience Z, you should request a CWT for A+B for audience Z, that replaces your previous one. Do I understand? two possibilities: A and B are members of audience Z; no new CWT needed B is a new member of audience Z; then audience Z becomes audience Z-prime and a new CWT seems reasonable. Peter Ludwig Seitz schreef op 2019-08-20 11:09: > On 19/08/2019 22:40, Jim Schaad wrote: > >> As Ludwig pointed out during the F2F, it makes far more sense to try and >> keep an entity using the same key identifier for as long as possible. This >> is in part to make sure that signing keys do not need to be retrieved if >> they can be easily cached. In looking at this deeper during my >> implementation I ended up with the following question: >> >> The way that I have set things up in my implementation it is simple to >> ensure that the same kid value is going to be used with the same CWT, >> however it might make more sense to use the signing key as the continuity >> identifier instead. The issue that arises in this case is that there might >> be two different active CWT objects that are associated with the same >> signing key. That is there are two CWTs but the same signing key was used >> while doing a join operation. I already do some matching between different >> CWTs by assuming that if the bearer key in the CWT is the same then they are >> sufficiently equivalent to threat them as the same. This lead to some >> interesting discussions in Montreal about if this meant just the "secret" or >> if it meant all of the elements provided by the AS which are used in the key >> derivation process. (I have gone back and forth on this and currently am >> sitting on the "just the secret" side of the fence.) >> >> Does anyone have any opinions? > Could you please expand the explanation of your use case a bit? > > Are you thinking of a scenario where someone would be using the counter-signature key from group-OSCORE as a proof-of-possession (pop) key in serveral CWTs? > > What would these CWT authorize? > > Why would an entity hold several CWTs for the same audience? > > Side-note: > My stance on multiple CWTs linked to the same pop-key and for the same audience is that the latter one should supersede the previous ones. > Example: If you have a CWT authorizing A for audience Z and you now also need authorization B for audience Z, you should request a CWT for A+B for audience Z, that replaces your previous one. > > /Ludwig > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace --=_d7c15ac00c89f4534d4346c4f9570ff1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8 Example: If you have a CWT authorizing A for audience Z and you now a= lso need authorization B for audience Z, you should request a CWT for A+B f= or audience Z, that replaces your previous one.

Do I unde= rstand?
two possibilities:
A and B are members of audience Z; no = new CWT needed
B is a new member of audience Z; then audience Z become= s audience Z-prime and a new CWT seems reasonable.

Peter

Ludwig Seitz schreef op 2019-08-20 11:09:

= On 19/08/2019 22:40, Ji= m Schaad wrote:
As Ludwig&nb= sp;pointed out during the F2F, it makes = far more sense to try and
keep an entity using the = ;same key identifier for as long as poss= ible.  This
is&= nbsp;in part to make sure that signing k= eys do not need to be retrieved if
they can be eas= ily cached.  In looking at this deeper&n= bsp;during my
implem= entation I ended up with the following q= uestion:

The = way that I have set things up in my=  implementation it is simple to
ensure that the same ki= d value is going to be used with th= e same CWT,
how= ever it might make more sense to use&nbs= p;the signing key as the continuity
<= span style=3D"white-space: nowrap;">identifier instead.  The=  issue that arises in this case is = that there might
signing key.  That is t= here are two CWTs but the same signing&n= bsp;key was used
CWTs by assuming = ;that if the bearer key in the CWT = is the same then they are
sufficiently equivalent to threat&= nbsp;them as the same.  This lead to&nbs= p;some
interesting d= iscussions in Montreal about if this meant&nb= sp;just the "secret" or
if it meant all of the elements=  provided by the AS which are used = in the key
deri= vation process.  (I have gone back and&n= bsp;forth on this and currently am
sitting on the "just = ;the secret" side of the fence.)

Does anyone have any=  opinions?
Could you please expand=  the explanation of your use case a = ;bit?

Are you thinking of a scenario where someone woul= d be using the counter-signature key from group-OSCORE as a proof-of-posses= sion (pop) key in serveral CWTs?

What would these CWT authorize?
Why would an entit= y hold several CWTs for the same audienc= e?


Side-not= e:
My stance on multiple CWTs linked to the same pop-key and f= or the same audience is that the latter one should supersede the previous o= nes.
Example: If you have a CWT authorizing A for audience Z and you = now also need authorization B for audience Z, you should request a CWT for = A+B for audience Z, that replaces your previous one.

/Ludwig



= _______________________________________________
Ace mailing list
Ace@ietf.org
= https://www.ietf.org/mailman/listinfo/ace
--=_d7c15ac00c89f4534d4346c4f9570ff1-- From nobody Tue Aug 20 03:53:09 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A2ED12001B for ; Tue, 20 Aug 2019 03:53:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=risecloud.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u7OeL5dln2Ab for ; Tue, 20 Aug 2019 03:53:05 -0700 (PDT) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20078.outbound.protection.outlook.com [40.107.2.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AE4D12001A for ; Tue, 20 Aug 2019 03:53:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=KBi6i+UXpQy+5/F+l+JCLtmLOvh9OlqP5g90mSVgK/4CiQU8txGkwGatK3O5a4/pisTr3Jntl8A2zakutXSezUzIibYJR7yGaCzVdlMrB+yVNVfhM2qdRcSBHzvTYTleB64OtTfXEtNiOwBRg7FbSKmB+HB912GtIP4lhEGaaEVhd281ANSdQiHhUBd9J/r0dO3+1nCaIG2ZNSJAmynLsNbXDy0XqxT8E7YSlXRmGgDcbVtJ/XmMEN8GSlCyeHh8yiFQDOvVHLLPrtwIcbGEjJGF4NmWvkq5BZlQd/px2QwMYMM0iYE9SUDROWLLu35vT9XNPXkClYmys32ieeCg9w== 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=MK0DVWL1ksQKVfpuTjYb9sVlfMMh7qvAFP1MtIWurDU=; b=Jou7uuJNJpxhLVt7d4G8HynGhoOeuE4rFKo/aKWDwSrWIynZhCfHs//HM9s5cWpooE8Ez8HRDieD1uA2X1w19nYZPQi32He/ZARsO3fZD4WkL11KazN5ehNbmKduJqCRJ5a+kGsAbw5TM9gS2jf5Rkjc0KgmI2qrAMHzaLoheqwck72gOW+n7o0Phb77M8HBRY6kARtdqrbC84b90mF9WH5wf69Lixgm8OONXa28t4KCEoYvyrq4Kwz2hfvaiQdBnlHCZGVlxhW/mJNabBGoYenVy7dX6QXFSzTe/1lBjUBNc1BZQenUZ1lp1En4Z5vhxxlnKRmV3nj4xVp/57A6TQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 194.218.146.197) smtp.rcpttodomain=ietf.org smtp.mailfrom=ri.se; dmarc=pass (p=none sp=none pct=100) action=none header.from=ri.se; dkim=none (message not signed); arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=RISEcloud.onmicrosoft.com; s=selector2-RISEcloud-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=MK0DVWL1ksQKVfpuTjYb9sVlfMMh7qvAFP1MtIWurDU=; b=kXdgTVLgbv8a9q0bmExVZNcMD0W19ddzy5n33Pw8pSAuySe7BwRp4JkUV9Qy759VCuAA8641cH0ZFKi5gRk8pPP3AlklRYiU3hiZBDdag1B3VLLCfiKsiONp/5P6ZN6+IU6Ol8zSpDUZADhp0b47PNrQaIc61IbhCEZQCd9HhL0= Received: from DB6P189CA0025.EURP189.PROD.OUTLOOK.COM (2603:10a6:6:2e::38) by VI1P18901MB0767.EURP189.PROD.OUTLOOK.COM (2603:10a6:800:123::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2178.16; Tue, 20 Aug 2019 10:53:02 +0000 Received: from VE1EUR02FT040.eop-EUR02.prod.protection.outlook.com (2a01:111:f400:7e06::205) by DB6P189CA0025.outlook.office365.com (2603:10a6:6:2e::38) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.2178.16 via Frontend Transport; Tue, 20 Aug 2019 10:53:01 +0000 Authentication-Results: spf=pass (sender IP is 194.218.146.197) smtp.mailfrom=ri.se; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=pass action=none header.from=ri.se; Received-SPF: Pass (protection.outlook.com: domain of ri.se designates 194.218.146.197 as permitted sender) receiver=protection.outlook.com; client-ip=194.218.146.197; helo=mail.ri.se; Received: from mail.ri.se (194.218.146.197) by VE1EUR02FT040.mail.protection.outlook.com (10.152.13.217) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.20.2178.16 via Frontend Transport; Tue, 20 Aug 2019 10:53:01 +0000 Received: from [10.112.134.122] (10.100.0.158) by sp-mail-2.sp.se (10.100.0.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Tue, 20 Aug 2019 12:53:01 +0200 To: CC: References: <01fc01d556ce$69f73cc0$3de5b640$@augustcellars.com> <01a391d0-8e6d-82cf-8f59-5a3e4d9f5605@ri.se> From: Ludwig Seitz Message-ID: <95cb2283-4e4b-024d-39a5-9a5e7a716034@ri.se> Date: Tue, 20 Aug 2019 12:53:00 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms080208080404010206030902" X-Originating-IP: [10.100.0.158] X-ClientProxiedBy: sp-mail-1.sp.se (10.100.0.161) To sp-mail-2.sp.se (10.100.0.162) X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:194.218.146.197; IPV:NLI; CTRY:SE; EFV:NLI; SFV:NSPM; SFS:(10009020)(4636009)(376002)(396003)(346002)(39860400002)(136003)(2980300002)(199004)(189003)(229853002)(31696002)(65956001)(65806001)(36756003)(305945005)(44832011)(486006)(5000100001)(2351001)(478600001)(8676002)(81156014)(81166006)(316002)(16576012)(14444005)(356004)(71190400001)(86362001)(7736002)(70586007)(70206006)(106002)(58126008)(16586007)(33964004)(76176011)(6916009)(26005)(31686004)(186003)(16526019)(386003)(22756006)(235185007)(5024004)(4326008)(64126003)(40036005)(6246003)(8936002)(53936002)(6116002)(568964002)(126002)(11346002)(446003)(476003)(2616005)(336012)(53546011)(3846002)(22746008)(2906002)(5660300002)(65826007); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1P18901MB0767; H:mail.ri.se; FPR:; SPF:Pass; LANG:en; PTR:InfoDomainNonexistent; A:1; MX:1; X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 612aaef2-c86d-4844-7efa-08d7255c9244 X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(4709080)(1401327)(2017052603328)(7193020); SRVR:VI1P18901MB0767; X-MS-TrafficTypeDiagnostic: VI1P18901MB0767: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:2399; X-Forefront-PRVS: 013568035E X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Message-Info: TrsiVYY4VUctCOqWPmSOAvxJUbtga7IBeA5DgwjzAcm4+rhQfPNqeiINBFXn7DZr5vfwjYwI/PzxaCKcAQm+F++6K2tJZkWV7AO+vTlJgi1K2gYB+O2FRXQ3P+R/aWiBOYL07lWPWdeNQvXgJUO8NSS6HvPukOaF9EXobEdIcS31mgVGZd6Xa23FD1Uv4dzS/IDqV0S/vIvbkbHTw//bCY4dn/1Mm47CBPpwvJgKkSwzy5p24PAWl4c/n+mk2zR45tG+xzHRskcufgKLIkaPyZp50rhV85fstBxd3ertOVlP3ziP38ucp8g/LYvyhEm9RM02dbhszL1VKM/O+C+nv6b3FjDbn2kMKOEzuMGZs9fx9pBXuKjEX7C9NRYbvjAEsD3DoZr0851bp5rk68ZLV/TdfLEoek8UZs/h21viiac= X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Aug 2019 10:53:01.6415 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 612aaef2-c86d-4844-7efa-08d7255c9244 X-MS-Exchange-CrossTenant-Id: 5a9809cf-0bcb-413a-838a-09ecc40cc9e8 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=5a9809cf-0bcb-413a-838a-09ecc40cc9e8; Ip=[194.218.146.197]; Helo=[mail.ri.se] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1P18901MB0767 Archived-At: Subject: Re: [Ace] Keeping the same key identifier for groups X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2019 10:53:08 -0000 --------------ms080208080404010206030902 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 20/08/2019 11:18, Peter van der Stok wrote: > Example: If you have a CWT authorizing A for audience Z and you now als= o=20 > need authorization B for audience Z, you should request a CWT for A+B=20 > for audience Z, that replaces your previous one. >=20 > Do I understand? > two possibilities: > A and B are members of audience Z; no new CWT needed > B is a new member of audience Z; then audience Z becomes audience=20 > Z-prime and a new CWT seems reasonable. >=20 > Peter No Peter, sorry for being unclear. In my example A and B were permissions. Let me=20 clarify: You have a CWT authorizing to "read" (that's my A) traffic in group Z,=20 now you also want authorization to "write" messages to group Z (that's=20 my B). What I'm saying is you should get a new CWT that says "read+write = on Z" (and not a separate one that says "write on Z" to combine with the = first one "read on Z"). /Ludwig --=20 Ludwig Seitz, PhD Security Lab, RISE Phone +46(0)70-349 92 51 --------------ms080208080404010206030902 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DT0wggYWMIID/qADAgECAg8BaKlzCTJTye3phLaz/cIwDQYJKoZIhvcNAQELBQAwRzELMAkG A1UEBhMCU0UxFDASBgNVBAoMC1RlbGlhU29uZXJhMSIwIAYDVQQDDBlUZWxpYVNvbmVyYSBD bGFzcyAyIENBIHYyMB4XDTE5MDIwMTE0MjUxNVoXDTIxMDIwMTE0MjUxNFowgYsxCzAJBgNV BAYTAlNFMS4wLAYDVQQKDCVSSVNFIFJlc2VhcmNoIEluc3RpdHV0ZXMgb2YgU3dlZGVuIEFC MRUwEwYDVQQDDAxMdWR3aWcgU2VpdHoxEjAQBgNVBAUTCUx1ZHdpZ1NlaTEhMB8GCSqGSIb3 DQEJARYSbHVkd2lnLnNlaXR6QHJpLnNlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAlJNmRfcsto5I/yXrBIi9QroZtfAMttc1Eznv5iPCK++eFUArODhITO7k9rtlQX5D8vYF v4vzZex58YWZhvGMzDj9FdpD/PHKOxL/frlrreChuissPWo5M88DmL3V1oyGzvgeRqaafpEi 0/2+gezMFlABm/BXj3/0Fiw5Sxub7essE27EtDK05nAbUB69kfLHBEytbTAuuSb11hC1dpTf itMZkzSFwsBCyPtIv3GRt9xgnOPK4RRpHidv1GLYXNQQ7xEGhFy4qbZ2NSfM+56SSRswvW9P 5n81ZmZ4FWkiJouUIYtZ2ifncBJL4DC2chjsywDEz5No7kYrGxc5oOm1YQIDAQABo4IBuDCC AbQwHwYDVR0jBBgwFoAUnhn/5Q06/gCXFT9p8dxaPKoMlIMwHQYDVR0OBBYEFKZHZ8MZNNP5 tXMPjeFiw01pUWbtMA4GA1UdDwEB/wQEAwIFoDBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEB DDA6MDgGCCsGAQUFBwIBFixodHRwczovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEu Y29tL0NQUzAdBgNVHREEFjAUgRJsdWR3aWcuc2VpdHpAcmkuc2UwTQYDVR0fBEYwRDBCoECg PoY8aHR0cDovL2NybC0yLnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYWNsYXNz MmNhdjIuY3JsMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjB+BggrBgEFBQcBAQRy MHAwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnRydXN0LnRlbGlhLmNvbTBFBggrBgEFBQcw AoY5aHR0cDovL2NhLnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYWNsYXNzMmNh djIuY2VyMA0GCSqGSIb3DQEBCwUAA4ICAQCk0GOalOCjEJObuBeMg0QREtBP/2ona16npn+T v5R3Vjk5UsQdOaOosgVjADX68C83dyfPiWR4UfNJoTBcM8JLpEXIm+xC4BiDPTPHYvgkhgXt 9VWCRWXOMfT/UPXjiGsbPuNWja1LQzF5KOmM826kHVZItHuDY6kJLE4OZ+apFvVKtSLQJJLA 4MlDVwp5+XsZi4cftcX5HdgLdChodUPKq3XVfALfXM/p81XEFBTYOHNplr3cQytDQjsnCZnS Ic4UpsxrArNxDO9+AKu/s1Fbq494AhHj4oHcg4DIjhHUzbPCLP19Gqp4dflr/V7Ulg3d+4Zh bmSAn1cffrzvvkjVrqMgQOoHQTl2QyO9n/oJ/9CSYRmhFsQMPun9LM/p5l58dTZp53B3LgA6 FFrxnntlZnTPh3bvsMJvUQ+AoiXyQwnkdxUrhoM+gUz36t3JSA8g48h7BhPsnwQ/YrarAhJ8 ifuzykTQmDseWLjJKyFflddy/azAlPQjgSMMWOZCo2s+l+WwPISf33nls2Aec/vvG5auYHS6 pwWuVKuwZTPgJfHanZTNpBM5y0jVBz6tr8AHZypnCONgyUYA4uec3v5oWz4FvLEnlKnMGoK3 OeFGvfHG0tbP25HbdN3AJYP0EUo56wfkBOYsnmn4mEYdk2GHkJNfaQRBJljH0T7TOcmcDjCC Bx8wggUHoAMCAQICEGN8C9eFpb8p2mAtfE16cLEwDQYJKoZIhvcNAQELBQAwNzEUMBIGA1UE CgwLVGVsaWFTb25lcmExHzAdBgNVBAMMFlRlbGlhU29uZXJhIFJvb3QgQ0EgdjEwHhcNMTQx MDE2MDgzOTMwWhcNMzIxMDE2MDUwNDAwWjBHMQswCQYDVQQGEwJTRTEUMBIGA1UECgwLVGVs aWFTb25lcmExIjAgBgNVBAMMGVRlbGlhU29uZXJhIENsYXNzIDIgQ0EgdjIwggIiMA0GCSqG SIb3DQEBAQUAA4ICDwAwggIKAoICAQC0PpW2qcWGnStqfa5DjrUi79Kz2SySUlJ1kiEQ1Pd/ LWbnsEwFYPqOJwAf6ZtEDtQ/9Z1VkVNQ6MkD++keqk7648x0YANgMyiJsWrbd0TKOObtlXdJ pb5qesJ5nOAdVeL3z6lgrkZx+fsUfTV+lLRGRh2+RWzZTjPAvKotY3nAwXCHtwI5v3FKuR10 aJ9+CEOka02KSUzGjcGZwMk2io0DxLELf1gPRvqE9xmn4ioXLqpluozb4Fo9ewydufTLQc3/ I63uPQh8BlLPPIGzWb4iBDq2zbWlbx0KlH/UlUZ7fjzp6N6cAqZ2NnDaCOnnIRfUYeNXFG8/ aiBeFOpEeEpclr5QUwr9HLKL1QiyQtc/wW8acQFoKuGi8myiAch7k7S0rmU5gT05je+OTzWh Oaw7gmDdndYY1mjkPkzpQ+hxyfnwUsAitUq9j0imFOLxKWLH4QNbyuDIMvDyezzJWzMy3XPB LiLSH9CBLVQHRoQ+WW8xD4rnmvQtoGZM72og2iNf4/JCHL1AJYhQtaRjYgm3rhvAP0HhSVAB Z5aHM52ylJHC3JwUyuFm8S9A2ffY9rUTffMLWmDCnX0QAP9bKr6+ACogm4DBUj3ftYodI2TD 6F8+VjSFuCzGDPuCjK+fQ2c3wqziwFl+NgoGI9Vgc6x5+0ocKkiQAIYFaQ3SyGmI6QIDAQAB o4ICFTCCAhEwgYoGCCsGAQUFBwEBBH4wfDAtBggrBgEFBQcwAYYhaHR0cDovL29jc3AudHJ1 c3QudGVsaWFzb25lcmEuY29tMEsGCCsGAQUFBzAChj9odHRwOi8vcmVwb3NpdG9yeS50cnVz dC50ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5jZXIwEgYDVR0TAQH/BAgw BgEB/wIBADBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEBAjA6MDgGCCsGAQUFBwIBFixodHRw czovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQUzAOBgNVHQ8BAf8EBAMC AQYwgcYGA1UdHwSBvjCBuzBAoD6gPIY6aHR0cDovL2NybC0zLnRydXN0LnRlbGlhc29uZXJh LmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNybDB3oHWgc4ZxbGRhcDovL2NybC0xLnRydXN0 LnRlbGlhc29uZXJhLmNvbS9jbj1UZWxpYVNvbmVyYSUyMFJvb3QlMjBDQSUyMHYxLG89VGVs aWFTb25lcmE/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnkwHQYDVR0OBBYEFJ4Z /+UNOv4AlxU/afHcWjyqDJSDMB8GA1UdIwQYMBaAFPCPWTgAs/WPmpYM1ev6e6oX6BMSMA0G CSqGSIb3DQEBCwUAA4ICAQB5wuZFNXR5ko9cu7PcpIyH8xaoGfpimP2GTg7qVuL92D/idIlj pqMm93WC9mgL/Uy6DExoF8xSLurLaiajoU+VG6ZWg0F7P1AXARNt0RpWI5SphxBQYM2751S8 vC/22k8Vi+qpQVIREqQPVXCIEH7U6eCY9gEVzdq9l1yPoI8n0D2a8V6GCv0RVkmIpa16rNYD tTw4j3Ha56/Ua33C3qeZh1dIfkaU2h4CGHd2Em3v5LLMsEh8dqUeG9yIcCU+8RUgDahNxWMe MGxzrhwk8WBV6xeoQp20p7cSHbSbyHJURC1n+nVrgdh8hbw6WOgFhNA5tCPDZ0oSF+uHfj+b ioZE3AlYdcEqHJA9A9sO58F4/Qg/yp9oYuT0ZpKb4hmzeqDXvk5KRFNfHlhTt35i+qmas9wB 11MXbYd5WwqEhZH6HWO5H7XKJP7olxmEC0W3OKlpKafq1iPsBN5ycRfUrXFss0Ax6vpCq0XA 3LYePpQ44hOU+qrkR1M0a7Eo3++3TpP4cV+FZiO4aZYZ3yZftSRHwWpGiDBdWOdTKR2GJi7Z z/OxacrmwmM1Z+WcigldbG8f3IMnOLK4X0uXjhVeAHrhuttQuM8i+4TNXgsZbmfEKNDQIQPO /lbacsGHWFB/U2y6SXVEkZs2xIciRA0iZNTv7mbIL8SZmf5wpbjDCYHiCjGCAzgwggM0AgEB MFowRzELMAkGA1UEBhMCU0UxFDASBgNVBAoMC1RlbGlhU29uZXJhMSIwIAYDVQQDDBlUZWxp YVNvbmVyYSBDbGFzcyAyIENBIHYyAg8BaKlzCTJTye3phLaz/cIwDQYJYIZIAWUDBAIBBQCg ggGvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE5MDgyMDEw NTMwMFowLwYJKoZIhvcNAQkEMSIEINSyVbVxMnj/nmXdeoDd7BiGcR7Gp2GzcUWmuF8K5NNx MGkGCSsGAQQBgjcQBDFcMFowRzELMAkGA1UEBhMCU0UxFDASBgNVBAoMC1RlbGlhU29uZXJh MSIwIAYDVQQDDBlUZWxpYVNvbmVyYSBDbGFzcyAyIENBIHYyAg8BaKlzCTJTye3phLaz/cIw awYLKoZIhvcNAQkQAgsxXKBaMEcxCzAJBgNVBAYTAlNFMRQwEgYDVQQKDAtUZWxpYVNvbmVy YTEiMCAGA1UEAwwZVGVsaWFTb25lcmEgQ2xhc3MgMiBDQSB2MgIPAWipcwkyU8nt6YS2s/3C MGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0D BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwIC ASgwDQYJKoZIhvcNAQEBBQAEggEABH/dHVJVoRqhYgpAdHg2Vhyo+g+4uZYxnt/VNQHQiM5R SlwSAtrmdkNJbxMngNdMxtRR5eAYtwQvmohrIzFvcxHIOHT4QR3etrFAEH1rXD7stbgI2ox2 6dsw5GrQXP5MA0oFCBUGMYS8Y1O8f1itGa5Z+elVxBz8CcfUEYp2gvZEwjWh9VbbDwhXzgRu MvQEoMlQIU5eefHXb8bmpmTIhi2zoFyIymzdUtqzFXPOxRyOTiUJgp9JLJ+Ysl75k+Vj3AbO Q01NUflUoe0Ps378kFW402XsnWdlBwLu2svFYamFIgmXTUgIcU3qvXkN5OS7a30QKJfSPzkB B3+BfGzFSgAAAAAAAA== --------------ms080208080404010206030902-- From nobody Tue Aug 20 10:54:10 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8537A120803 for ; Tue, 20 Aug 2019 10:54:08 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bGfpQOSoYi8Q for ; Tue, 20 Aug 2019 10:54:06 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F336112011C for ; Tue, 20 Aug 2019 10:54:05 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 20 Aug 2019 10:54:00 -0700 From: Jim Schaad To: 'Ludwig Seitz' , References: <01fc01d556ce$69f73cc0$3de5b640$@augustcellars.com> <01a391d0-8e6d-82cf-8f59-5a3e4d9f5605@ri.se> In-Reply-To: <01a391d0-8e6d-82cf-8f59-5a3e4d9f5605@ri.se> Date: Tue, 20 Aug 2019 10:53:58 -0700 Message-ID: <026701d55780$3ff4dce0$bfde96a0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQGyiUQdFW2LK/X13TRqHpttk6RLUgHBuBXhpzvUJQA= Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Ace] Keeping the same key identifier for groups X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2019 17:54:08 -0000 -----Original Message----- From: Ace On Behalf Of Ludwig Seitz Sent: Tuesday, August 20, 2019 2:09 AM To: ace@ietf.org Subject: Re: [Ace] Keeping the same key identifier for groups On 19/08/2019 22:40, Jim Schaad wrote: > As Ludwig pointed out during the F2F, it makes far more sense to try=20 > and keep an entity using the same key identifier for as long as=20 > possible. This is in part to make sure that signing keys do not need=20 > to be retrieved if they can be easily cached. In looking at this=20 > deeper during my implementation I ended up with the following = question: >=20 > The way that I have set things up in my implementation it is simple to = > ensure that the same kid value is going to be used with the same CWT,=20 > however it might make more sense to use the signing key as the=20 > continuity identifier instead. The issue that arises in this case is=20 > that there might be two different active CWT objects that are=20 > associated with the same signing key. That is there are two CWTs but = the same signing key was used > while doing a join operation. I already do some matching between = different > CWTs by assuming that if the bearer key in the CWT is the same then=20 > they are sufficiently equivalent to threat them as the same. This=20 > lead to some interesting discussions in Montreal about if this meant=20 > just the "secret" or if it meant all of the elements provided by the=20 > AS which are used in the key derivation process. (I have gone back=20 > and forth on this and currently am sitting on the "just the secret"=20 > side of the fence.) >=20 > Does anyone have any opinions? >=20 Could you please expand the explanation of your use case a bit? Are you thinking of a scenario where someone would be using the = counter-signature key from group-OSCORE as a proof-of-possession (pop) = key in serveral CWTs? What would these CWT authorize? Why would an entity hold several CWTs for the same audience? [JLS] Trying to get a bit more detailed on the situations that I am = thinking about. At the moment I am working on group key manager code = so both of these are going to be couched in those terms and not in = general terms. I have a CWT that says group X is fine for this entity. The CWT expires = or is going to expire soon. The AS does not use the same pop-key in a = newly issued CWT. The CWT is posted to the Group KDC and the entity = performs a join under that new CWT, but with the same signing key for = group messaging. Should this operation preserve the group kid assigned = to that entity based on the signing key or should it be a new group kid = based on the new CWT pop key. That is Entity E1 using CWT1 and public = key S1 received a GK-kid value for group G1. E1 then posts CWT2, with a = different pop-key, does a join request for G1 using the new pop-key and = S1. Does the AS return GK-kid or GK-kid2? This can happen in any number of different situations: Adding or = removing group Y from the token, token renewal, reboot of somebody so = state is lost, key exhaustion or merely a requirement from the AS that = symmetric pop keys be rotated based on duration. Side-note: My stance on multiple CWTs linked to the same pop-key and for the same = audience is that the latter one should supersede the previous ones. Example: If you have a CWT authorizing A for audience Z and you now also = need authorization B for audience Z, you should request a CWT for A+B = for audience Z, that replaces your previous one. [JLS] I agree that this is the preferred way for these things to = happen, that is either the request says use the same pop-key or the AS = just uses the same pop-key because it knows that a similar CWT exists = already. However there are reasons why that cannot be done. Easy = example, my AS does not currently have any memory so it can never issue = a new CWT with the same symmetric pop-key. It can do it with the same = asymmetric pop key. jim [JLS] =20 /Ludwig -- Ludwig Seitz, PhD Security Lab, RISE Phone +46(0)70-349 92 51 From nobody Tue Aug 20 23:53:55 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF54A120142 for ; Tue, 20 Aug 2019 23:53:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=risecloud.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cClr97XSpILp for ; Tue, 20 Aug 2019 23:53:49 -0700 (PDT) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20047.outbound.protection.outlook.com [40.107.2.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9122E120122 for ; Tue, 20 Aug 2019 23:53:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=cQW0oAZJklIWbWw5+Y8Auqt/XB7+O+3YxurGfomfE4nccHUY5bCxAm8fcebJqyRF1QLjs+acbt23grqmiWlkSbzgqDiJEOe7vyeFTLttoS1a5bxLGWstsn/d+brhSedDKu43R/ceBmEHjMR5bDvAIvM6m6Tz1R6lnjNYTC4wSZdZAY0y7HDsLn4EeLJI8/4fl0nGnfQD/d/Xf2TMz9SueBPdS4lD/f05KUQobQvVELdjL3sgh9fsc1uIORkiSCGutl/3d0oCFyJQu55GPNhHhGuGQtzrFnrgRul5vqrps1VhZ7OVm4WDaNlS8XC7YMsy8AhaMtAk5oHab/zT7zZGfA== 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=DOe16YYOcugBvdsG0Usw8/ocLSSh5xHq36hM/3isyTc=; b=UnqzDTf6J0vdhFKMZeYdVrt7Ofa0bAYua96uAYkEh+p03Ao1/r2NIKrSheLADpCBAXSDsGSLLxxKtlp+Qgu+DDewNvpcR4buE6fHUhbqoaZhbEA3nqBf+7z354G9VJvESOISFVPrm6p/sxGnlSfKkmDL/XFvH3QAwJBftxsZm/PbVpEL+4kwl9vtgFB9hN8GJ8PmDQgkiLb/X3lG5EcrpgGJ41I5bDZ4dU8PL3g53/loxfZLiURvGGiHK5bddwjl6DnsL0lk2NJUFMkKCaVpBd18iXxEL9pBsWxt+Y02zWD9Bb9/8gyYjTRBZas0wyv1/iN9OktZR/YzclLBboA7Dw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 194.218.146.197) smtp.rcpttodomain=augustcellars.com smtp.mailfrom=ri.se; dmarc=pass (p=none sp=none pct=100) action=none header.from=ri.se; dkim=none (message not signed); arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=RISEcloud.onmicrosoft.com; s=selector2-RISEcloud-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=DOe16YYOcugBvdsG0Usw8/ocLSSh5xHq36hM/3isyTc=; b=VxAWpHOn6Gt3lr/1ovW53hqjvWnLHBtVL/Ab3b+HWlpSlmF6xOXRrp0y0U+UsoiO6SUO+/gd2DpKMCC4On0r6clJQZ0Ofhrsx74QKq4rIKtkTIQwA0MDwhAENUQv8DYLKW+MA/xUir7KV+bwstH94gEfMwItKqIk0NKNihtHJrQ= Received: from DB6P189CA0026.EURP189.PROD.OUTLOOK.COM (2603:10a6:6:2e::39) by HE1P18901MB0220.EURP189.PROD.OUTLOOK.COM (2603:10a6:3:9d::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2178.16; Wed, 21 Aug 2019 06:53:45 +0000 Received: from AM5EUR02FT006.eop-EUR02.prod.protection.outlook.com (2a01:111:f400:7e1e::201) by DB6P189CA0026.outlook.office365.com (2603:10a6:6:2e::39) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.2178.16 via Frontend Transport; Wed, 21 Aug 2019 06:53:45 +0000 Authentication-Results: spf=pass (sender IP is 194.218.146.197) smtp.mailfrom=ri.se; augustcellars.com; dkim=none (message not signed) header.d=none;augustcellars.com; dmarc=pass action=none header.from=ri.se; Received-SPF: Pass (protection.outlook.com: domain of ri.se designates 194.218.146.197 as permitted sender) receiver=protection.outlook.com; client-ip=194.218.146.197; helo=mail.ri.se; Received: from mail.ri.se (194.218.146.197) by AM5EUR02FT006.mail.protection.outlook.com (10.152.8.77) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.20.2178.16 via Frontend Transport; Wed, 21 Aug 2019 06:53:45 +0000 Received: from [10.8.3.17] (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.1713.5; Wed, 21 Aug 2019 08:53:43 +0200 Date: Wed, 21 Aug 2019 08:53:43 +0200 User-Agent: K-9 Mail for Android In-Reply-To: <026701d55780$3ff4dce0$bfde96a0$@augustcellars.com> References: <01fc01d556ce$69f73cc0$3de5b640$@augustcellars.com> <01a391d0-8e6d-82cf-8f59-5a3e4d9f5605@ri.se> <026701d55780$3ff4dce0$bfde96a0$@augustcellars.com> Autocrypt: addr=marco.tiloca@ri.se; keydata= mQENBFSNeRUBCAC44iazWzj/PE3TiAlBsaWna0JbdIAJFHB8PLrqthI0ZG7GnCLNR8ZhDz6ZaRDP C4FR3UcMhPgZpJIqa6Zi8yWYCqF7A7QhT7E1WdQR1G0+6xUEd0ZD+QBdf29pQadrVZAt0G4CkUnq 5H+Sm05aw2Cpv3JfsATVaemWmujnMTvZ3dFudCGNdsY6kPSVzMRyedX7ArLXyF+0Kh1T4WUW6NHf EWltnzkcqRhn2NcZtADsxWrMBgZXkLE/dP67SnyFjWYpz7aNpxxA+mb5WBT+NrSetJlljT0QOXrX MGh98GLfNnLAl6gJryE6MZazN5oxkJgkAep8SevFXzglj7CAsh4PABEBAAG0Nk1hcmNvIFRpbG9j YSAobWFyY28udGlsb2NhQHJpLnNlKSA8bWFyY28udGlsb2NhQHJpLnNlPokBNwQTAQgAIQUCWkAn kAIbAwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRDuJmS0DljaQwEvCACJKPJIPGH0oGnLJY4G 1I2DgNiyVKt1H4kkc/eT8Bz9OSbAxgZo3Jky382e4DbaayWrQRFen0aLSFuzbU4BX4O/YRSaIqUO 3KwUNO1iTC65OHz0XirGohPUOsc0SEMtpm+4zfYG7G8p35MK0h9gpwgGMG0j0mZX4RDjuywC88i1 VxCwMWGaZRlUrPXkC3nqDDRcPtuEGpncWhAVQt2ZqeyITv9KCUmDntmXLPe6vEXtOfI9Z3HeqeI8 OkGwXpotVobgLa/mVmFj6EALDzj7HC2utfgxECBJddmcDInrvGgTkZtXEVbyLQuiK20lJmYnmPWN 8DXaVVaQ4XP/lXUrzoEzuQENBFSNeRUBCACWmp+k6LkY4/ey7eA7umYVc22iyVqAEXmywDYzEjew YwRcjTrH/Nx1EqwjIDuW+BBEoMLRZOHCgmjo6HRmWIutcYVCt9ieokultkor9BBoQVPiI+Tp51Op 02ifkGcrEQNZi7q3fmOthFZwZ6NJnUbA2bycaKZ8oClvDCQj6AjEydBPnS73UaEoDsqsGVjZwChf OMg5OyFm90QjpIw8m0uDVcCzKKfxq3T/z7tyRgucIUe84EzBuuJBESEjK/hF0nR2LDh1ShD29FWr FZSNVVCVu1UYZLAayf8oKKHHpM+whfjEYO4XsDpV4zQ15A+D15HRiHR6Adf4PDtPM1DCwggjABEB AAGJAR8EGAECAAkFAlSNeRUCGwwACgkQ7iZktA5Y2kPGEwf/WNjTy3z74vLmHycVsFXXoQ8W1+85 8mRyAd0a8JYzY3xB7CVtqI3Hy894Qcw4H6G799A1OL9B1EeA8Yj3aOz0NbUyf5GW+iotr3h8+KIC OYZ34/BQaOLzdvDNmRoGHn+NeTzhF7eSeiPKi2jex+NVodhjOVGXw8EhYGkeZLvynHEboiLM4Tby PbVR9HsdVqKGVTDxKSE3namo3kvtY6syRFIiUz5WzJfYAuqbt6m3TxDEb8sA9pzaLuhmfnJRc12H 5NVZEZmE/EkJFTlkP4wnZyOSf/r2/Vd0iHauBwv57cpY6HFFMe7rvK4s7ME5zctOEly5C6NCu1Za NtdUuqDSPA== MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/signed; boundary="----7UCEJFME0FGZVESE5RFQ76E1E20ETL"; protocol="application/pgp-signature"; micalg=pgp-sha512 To: Jim Schaad , 'Ludwig Seitz' , From: Marco Tiloca Message-ID: 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-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:194.218.146.197; IPV:NLI; CTRY:SE; EFV:NLI; SFV:NSPM; SFS:(10009020)(4636009)(396003)(136003)(39860400002)(346002)(376002)(2980300002)(199004)(189003)(13464003)(53936002)(58126008)(16576012)(316002)(8936002)(106002)(966005)(110136005)(86362001)(478600001)(14444005)(6246003)(356004)(71190400001)(70586007)(33656002)(230700001)(36756003)(70206006)(22746008)(5660300002)(66574012)(30864003)(3846002)(53546011)(336012)(7736002)(6116002)(22756006)(40036005)(476003)(126002)(44832011)(2616005)(2906002)(386003)(486006)(81166006)(16526019)(8676002)(26005)(186003)(446003)(81156014)(11346002)(21480400003)(33964004)(76176011)(236005)(6306002)(606006)(229853002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1P18901MB0220; H:mail.ri.se; FPR:; SPF:Pass; LANG:en; PTR:InfoDomainNonexistent; A:1; MX:1; X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 4f8dffbd-2c4c-4186-97c9-08d726044f7f X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(4709080)(1401327)(2017052603328)(7193020); SRVR:HE1P18901MB0220; X-MS-TrafficTypeDiagnostic: HE1P18901MB0220: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:9508; X-Forefront-PRVS: 0136C1DDA4 X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Message-Info: DyrJM1OQSKMimSFDEfybj9nudh7XOdJHYcHNjjOwp0suPsochMHnto9Cmrmj3jvXBZuzL1J/o8pTtMhlpYlKfS+qDxzUGAxSNXmKzIPJP8i3muGXm/0BVRiQjklur7272/ovjXaTpdRlRi0o6w8Xa2Qjl1Q1RQ27CB2Tl+yJmG/IO4Uv5r4SFuRXW8oW/8o/wpt7Cr0Er0C148BXLNprkWXaG5mpm1HqGl4tllyFKt6aXQVxPt/D+8a8cKWF8ZaNG2Zg2yfLwaMATDsKmMYkffAnqGu0Bc+URG/8A3Df9gVCoR9OeWi7q7Vg3x2L52bduno0OBiHqYFrconUHzUdKTLkrxaReMf8G5XwnARg+zlx5ButkD7cXFHd4oZsBrg+VEXgtfRElOzT2ylcb0VuMlRg4/k5UpR96eyFQce2Rbc= X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Aug 2019 06:53:45.0009 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 4f8dffbd-2c4c-4186-97c9-08d726044f7f X-MS-Exchange-CrossTenant-Id: 5a9809cf-0bcb-413a-838a-09ecc40cc9e8 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=5a9809cf-0bcb-413a-838a-09ecc40cc9e8; Ip=[194.218.146.197]; Helo=[mail.ri.se] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1P18901MB0220 Archived-At: Subject: Re: [Ace] Keeping the same key identifier for groups X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Aug 2019 06:53:53 -0000 ------7UCEJFME0FGZVESE5RFQ76E1E20ETL Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="----YD19WFY63UGXXGQF2MSF7WYXMP2FGP" ------YD19WFY63UGXXGQF2MSF7WYXMP2FGP Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Jim, all, I believe that the KDC should re-assign the same kid (OSCORE Sender ID) to= the joining node, also upon its second join enabled by a CWT conveying a d= ifferent PoP key than the first one=2E This spares other group members from (re-)retrieving the same public key a= gain, and to derive a new corresponding recipient context for the rejoined = node (unless the KDC also performs a full group rekeying upon the node's jo= ining)=2E Note that a group member configured only as "monitor" in Group OSCORE woul= d not provide any public key to the KDC as paired to a signing key for grou= p messages, since it never produces outgoing messages to sign as per its si= ngle role in the group=2E In this case, there may be no public key to use a= s a constant identifier across consequent joinings of a same node to the sa= me group=2E Best, /Marco On August 20, 2019 7:53:58 PM GMT+02:00, Jim Schaad wrote: > > >-----Original Message----- >From: Ace On Behalf Of Ludwig Seitz >Sent: Tuesday, August 20, 2019 2:09 AM >To: ace@ietf=2Eorg >Subject: Re: [Ace] Keeping the same key identifier for groups > >On 19/08/2019 22:40, Jim Schaad wrote: >> As Ludwig pointed out during the F2F, it makes far more sense to try=20 >> and keep an entity using the same key identifier for as long as=20 >> possible=2E This is in part to make sure that signing keys do not need > >> to be retrieved if they can be easily cached=2E In looking at this=20 >> deeper during my implementation I ended up with the following >question: >>=20 >> The way that I have set things up in my implementation it is simple >to=20 >> ensure that the same kid value is going to be used with the same CWT, > >> however it might make more sense to use the signing key as the=20 >> continuity identifier instead=2E The issue that arises in this case is > >> that there might be two different active CWT objects that are=20 >> associated with the same signing key=2E That is there are two CWTs but >the same signing key was used >> while doing a join operation=2E I already do some matching between >different >> CWTs by assuming that if the bearer key in the CWT is the same then=20 >> they are sufficiently equivalent to threat them as the same=2E This=20 >> lead to some interesting discussions in Montreal about if this meant=20 >> just the "secret" or if it meant all of the elements provided by the=20 >> AS which are used in the key derivation process=2E (I have gone back= =20 >> and forth on this and currently am sitting on the "just the secret"=20 >> side of the fence=2E) >>=20 >> Does anyone have any opinions? >>=20 >Could you please expand the explanation of your use case a bit? > >Are you thinking of a scenario where someone would be using the >counter-signature key from group-OSCORE as a proof-of-possession (pop) >key in serveral CWTs? > >What would these CWT authorize? > >Why would an entity hold several CWTs for the same audience? > >[JLS] Trying to get a bit more detailed on the situations that I am >thinking about=2E At the moment I am working on group key manager code >so both of these are going to be couched in those terms and not in >general terms=2E > >I have a CWT that says group X is fine for this entity=2E The CWT >expires or is going to expire soon=2E The AS does not use the same >pop-key in a newly issued CWT=2E The CWT is posted to the Group KDC and >the entity performs a join under that new CWT, but with the same >signing key for group messaging=2E Should this operation preserve the >group kid assigned to that entity based on the signing key or should it >be a new group kid based on the new CWT pop key=2E That is Entity E1 >using CWT1 and public key S1 received a GK-kid value for group G1=2E E1 >then posts CWT2, with a different pop-key, does a join request for G1 >using the new pop-key and S1=2E Does the AS return GK-kid or GK-kid2? > >This can happen in any number of different situations: Adding or >removing group Y from the token, token renewal, reboot of somebody so >state is lost, key exhaustion or merely a requirement from the AS that >symmetric pop keys be rotated based on duration=2E > > > >Side-note: >My stance on multiple CWTs linked to the same pop-key and for the same >audience is that the latter one should supersede the previous ones=2E >Example: If you have a CWT authorizing A for audience Z and you now >also need authorization B for audience Z, you should request a CWT for >A+B for audience Z, that replaces your previous one=2E > >[JLS] I agree that this is the preferred way for these things to >happen, that is either the request says use the same pop-key or the AS >just uses the same pop-key because it knows that a similar CWT exists >already=2E However there are reasons why that cannot be done=2E Easy >example, my AS does not currently have any memory so it can never issue >a new CWT with the same symmetric pop-key=2E It can do it with the same >asymmetric pop key=2E > > >jim > >[JLS] =20 > >/Ludwig > > > > >-- >Ludwig Seitz, PhD >Security Lab, RISE >Phone +46(0)70-349 92 51 > > >_______________________________________________ >Ace mailing list >Ace@ietf=2Eorg >https://www=2Eietf=2Eorg/mailman/listinfo/ace --=20 Marco Tiloca Ph=2ED=2E, Senior Researcher RISE Research Institutes of Sweden Division ICT Isafjordsgatan 22 / Kistag=C3=A5ngen 16 SE-164 40 Kista (Sweden) Phone: +46 (0)70 60 46 501 https://www=2Eri=2Ese ------YD19WFY63UGXXGQF2MSF7WYXMP2FGP Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Jim, all,

I believe that the KDC should = re-assign the same kid (OSCORE Sender ID) to the joining node, also upon it= s second join enabled by a CWT conveying a different PoP key than the first= one=2E

This spares other group members from (re-)retrieving the sam= e public key again, and to derive a new corresponding recipient context for= the rejoined node (unless the KDC also performs a full group rekeying upon= the node's joining)=2E

Note that a group member configured only as = "monitor" in Group OSCORE would not provide any public key to the KDC as pa= ired to a signing key for group messages, since it never produces outgoing = messages to sign as per its single role in the group=2E In this case, there= may be no public key to use as a constant identifier across consequent joi= nings of a same node to the same group=2E

Best,
/Marco

On August 20, 2019 7:53:58 PM GMT+02:00, Jim Sc= haad <ietf@augustcellars=2Ecom> wrote:


-----Original Message-----
From: Ace <=
ace-bounces@ietf=2Eorg> On Behalf Of Ludwig Seitz
Sent: Tuesday, Augu=
st 20, 2019 2:09 AM
To: ace@ietf=2Eorg
Subject: Re: [Ace] Keeping the=
 same key identifier for groups

On 19/08/2019 22:40, Jim Schaad wrot=
e:
As Ludwig pointed ou=
t during the F2F, it makes far more sense to try 
and keep an entity usi=
ng the same key identifier for as long as 
possible=2E  This is in part =
to make sure that signing keys do not need 
to be retrieved if they can =
be easily cached=2E  In looking at this 
deeper during my implementation=
 I ended up with the following question:

The way that I have set thi=
ngs up in my implementation it is simple to 
ensure that the same kid va=
lue is going to be used with the same CWT, 
however it might make more s=
ense to use the signing key as the 
continuity identifier instead=2E  Th=
e issue that arises in this case is 
that there might be two different a=
ctive CWT objects that are 
associated with the same signing key=2E  Tha=
t is there are two CWTs but the same signing key was used
while doing a =
join operation=2E   I already do some matching between different
CWTs by=
 assuming that if the bearer key in the CWT is the same then 
they are s=
ufficiently equivalent to threat them as the same=2E  This 
lead to some=
 interesting discussions in Montreal about if this meant 
just the "secr=
et" or if it meant all of the elements provided by the 
AS which are use=
d in the key derivation process=2E  (I have gone back 
and forth on this=
 and currently am sitting on the "just the secret" 
side of the fence=2E=
)

Does anyone have any opinions?

Could you pleas=
e expand the explanation of your use case a bit?

Are you thinking of=
 a scenario where someone would be using the counter-signature key from gro=
up-OSCORE as a proof-of-possession (pop) key in serveral CWTs?

What =
would these CWT authorize?

Why would an entity hold several CWTs for=
 the same audience?

[JLS]  Trying to get a bit more detailed on the =
situations that I am thinking about=2E   At the moment I am working on grou=
p key manager code so both of these are going to be couched in those terms =
and not in general terms=2E

I have a CWT that says group X is fine f=
or this entity=2E  The CWT expires or is going to expire soon=2E  The AS do=
es not use the same pop-key in a newly issued CWT=2E  The CWT is posted to =
the Group KDC and the entity performs a join under that new CWT, but with t=
he same signing key for group messaging=2E   Should this operation preserve=
 the group kid assigned to that entity based on the signing key or should i=
t be a new group kid based on the new CWT pop key=2E  That is Entity E1 usi=
ng CWT1 and public key S1 received a GK-kid value for group G1=2E  E1 then =
posts CWT2, with a different pop-key, does a join request for G1 using the =
new pop-key and S1=2E  Does the AS return GK-kid or GK-kid2?

This ca=
n happen in any number of different situations:  Adding or removing group Y=
 from the token, token renewal, reboot of somebody so state is lost, key ex=
haustion or merely a requirement from the AS that symmetric pop keys be rot=
ated based on duration=2E



Side-note:
My stance on multipl=
e CWTs linked to the same pop-key and for the same audience is that the lat=
ter one should supersede the previous ones=2E
Example: If you have a CWT=
 authorizing A for audience Z and you now also need authorization B for aud=
ience Z, you should request a CWT for A+B for audience Z, that replaces you=
r previous one=2E

[JLS]  I agree that this is the preferred way for =
these things to happen, that is either the request says use the same pop-ke=
y or the AS just uses the same pop-key because it knows that a similar CWT =
exists already=2E  However there are reasons why that cannot be done=2E  Ea=
sy example, my AS does not currently have any memory so it can never issue =
a new CWT with the same symmetric pop-key=2E  It can do it with the same as=
ymmetric pop key=2E


jim

[JLS]  

/Ludwig



--
Ludwig Seitz, PhD
Security Lab, RISE
Phone +46(0)70-34=
9 92 51
Ace mailing list
Ace@ietf=2Eorg
https://www=2Eietf=2Eorg/mailman/listinfo/a=
ce

--
Marco Tiloca
Ph=2ED=2E, Se= nior Researcher

RISE Research Institutes of Sweden
Division ICTIsafjordsgatan 22 / Kistag=C3=A5ngen 16
SE-164 40 Kista (Sweden)
Phone: +46 (0)70 60 46 501
https://w= ww=2Eri=2Ese
--
Marco Tiloca
Ph=2ED=2E, Senior Researcher
=
RISE Research Institutes of Sweden
Division ICT
Isafjordsgatan 22= / Kistag=C3=A5ngen 16
SE-164 40 Kista (Sweden)

Phone: +46 (0)70 = 60 46 501
https://www=2Eri=2Ese ------YD19WFY63UGXXGQF2MSF7WYXMP2FGP-- ------7UCEJFME0FGZVESE5RFQ76E1E20ETL Content-Type: application/pgp-signature; name="signature.asc" Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- iQFFBAABCgAvKBxNYXJjbyBUaWxvY2EgPG1hcmNvLnRpbG9jYTg0QGdtYWlsLmNv bT4FAl1c6ncACgkQ7iZktA5Y2kOBBwf+JOhg/hDzyBai3BLkua9nzZQJ83qQQ0Xa JwIGuQoJykkW5nF0vm027a00qP40PitvKxCgdJrk4xos2q0L5WEql/h7vUtfVkIT YOd2zsNMiY2EKDRB6JRw2J8S5Ex5R+Zf2mbUyHeDTl11PE3Ut0Lgc8pVlbEFZSJi rOjXWnAMDKWY624CkKxnNHGVMDPqUPT1+SxiNn/tSVACmm6WR722kzVwNFI8V5eO dAgPbk8MOWPKFoIaIyvC9fSoq0PW/Gm65FgY0+7ZYT7Tq3S1yyeMyHvcY6K08I2r 7dMD89/pSKVPGnVguxYGUdT1AfsVVfRS0enty8gvj8bsKITIJWarlA== =clQF -----END PGP SIGNATURE----- ------7UCEJFME0FGZVESE5RFQ76E1E20ETL-- From nobody Wed Aug 21 07:37:24 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5962B1200EC for ; Wed, 21 Aug 2019 07:37:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8VJCtTs_ESBE for ; Wed, 21 Aug 2019 07:37:20 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6342B120020 for ; Wed, 21 Aug 2019 07:37:19 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 21 Aug 2019 07:37:13 -0700 From: Jim Schaad To: 'Marco Tiloca' , 'Ludwig Seitz' , References: <01fc01d556ce$69f73cc0$3de5b640$@augustcellars.com> <01a391d0-8e6d-82cf-8f59-5a3e4d9f5605@ri.se> <026701d55780$3ff4dce0$bfde96a0$@augustcellars.com> In-Reply-To: Date: Wed, 21 Aug 2019 07:37:12 -0700 Message-ID: <02a601d5582d$ecfbdf80$c6f39e80$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_02A7_01D557F3.409DF1E0" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQGyiUQdFW2LK/X13TRqHpttk6RLUgHBuBXhAZOiAHUB3ZnbyqchsXGQ Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Ace] Keeping the same key identifier for groups X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Aug 2019 14:37:22 -0000 ------=_NextPart_000_02A7_01D557F3.409DF1E0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Marco, =20 I was not planning to give a kid to a =E2=80=9Cmonitor=E2=80=9D entity. = Since they are not supposed to be sending any messages, they = don=E2=80=99t need anything to identify the messages they are not = sending and thus don=E2=80=99t need a key id. =20 Jim =20 =20 From: Marco Tiloca =20 Sent: Tuesday, August 20, 2019 11:54 PM To: Jim Schaad ; 'Ludwig Seitz' = ; ace@ietf.org Subject: Re: [Ace] Keeping the same key identifier for groups =20 Hi Jim, all, I believe that the KDC should re-assign the same kid (OSCORE Sender ID) = to the joining node, also upon its second join enabled by a CWT = conveying a different PoP key than the first one. This spares other group members from (re-)retrieving the same public key = again, and to derive a new corresponding recipient context for the = rejoined node (unless the KDC also performs a full group rekeying upon = the node's joining). Note that a group member configured only as "monitor" in Group OSCORE = would not provide any public key to the KDC as paired to a signing key = for group messages, since it never produces outgoing messages to sign as = per its single role in the group. In this case, there may be no public = key to use as a constant identifier across consequent joinings of a same = node to the same group. Best, /Marco On August 20, 2019 7:53:58 PM GMT+02:00, Jim Schaad = > wrote: -----Original Message----- From: Ace > On = Behalf Of Ludwig Seitz Sent: Tuesday, August 20, 2019 2:09 AM To: ace@ietf.org =20 Subject: Re: [Ace] Keeping the same key identifier for groups On 19/08/2019 22:40, Jim Schaad wrote: As Ludwig pointed out during the F2F, it makes far more sense to try=20 and keep an entity using the same key identifier for as long as=20 possible. This is in part to make sure that signing keys do not need=20 to be retrieved if they can be easily cached. In looking at this=20 deeper during my implementation I ended up with the following question: The way that I have set things up in my implementation it is simple to=20 ensure that the same kid value is going to be used with the same CWT,=20 however it might make more sense to use the signing key as the=20 continuity identifier instead. The issue that arises in this case is=20 that there might be two different active CWT objects that are=20 associated with the same signing key. That is there are two CWTs but = the same signing key was used while doing a join operation. I already do some matching between = different CWTs by assuming that if the bearer key in the CWT is the same then=20 they are sufficiently equivalent to threat them as the same. This=20 lead to some interesting discussions in Montreal about if this meant=20 just the "secret" or if it meant all of the elements provided by the=20 AS which are used in the key derivation process. (I have gone back=20 and forth on this and currently am sitting on the "just the secret"=20 side of the fence.) Does anyone have any opinions? Could you please expand the explanation of your use case a bit? Are you thinking of a scenario where someone would be using the = counter-signature key from group-OSCORE as a proof-of-possession (pop) = key in serveral CWTs? What would these CWT authorize? Why would an entity hold several CWTs for the same audience? [JLS] Trying to get a bit more detailed on the situations that I am = thinking about. At the moment I am working on group key manager code = so both of these are going to be couched in those terms and not in = general terms. I have a CWT that says group X is fine for this entity. The CWT expires = or is going to expire soon. The AS does not use the same pop-key in a = newly issued CWT. The CWT is posted to the Group KDC and the entity = performs a join under that new CWT, but with the same signing key for = group messaging. Should this operation preserve the group kid assigned = to that entity based on the signing key or should it be a new group kid = based on the new CWT pop key. That is Entity E1 using CWT1 and public = key S1 received a GK-kid value for group G1. E1 then posts CWT2, with a = different pop-key, does a join request for G1 using the new pop-key and = S1. Does the AS return GK-kid or GK-kid2? This can happen in any number of different situations: Adding or = removing group Y from the token, token renewal, reboot of somebody so = state is lost, key exhaustion or merely a requirement from the AS that = symmetric pop keys be rotated based on duration. Side-note: My stance on multiple CWTs linked to the same pop-key and for the same = audience is that the latter one should supersede the previous ones. Example: If you have a CWT authorizing A for audience Z and you now also = need authorization B for audience Z, you should request a CWT for A+B = for audience Z, that replaces your previous one. [JLS] I agree that this is the preferred way for these things to = happen, that is either the request says use the same pop-key or the AS = just uses the same pop-key because it knows that a similar CWT exists = already. However there are reasons why that cannot be done. Easy = example, my AS does not currently have any memory so it can never issue = a new CWT with the same symmetric pop-key. It can do it with the same = asymmetric pop key. jim [JLS] =20 /Ludwig -- Ludwig Seitz, PhD Security Lab, RISE Phone +46(0)70-349 92 51 _____ =20 Ace mailing list Ace@ietf.org =20 https://www.ietf.org/mailman/listinfo/ace --=20 Marco Tiloca Ph.D., Senior Researcher RISE Research Institutes of Sweden Division ICT Isafjordsgatan 22 / Kistag=C3=A5ngen 16 SE-164 40 Kista (Sweden) Phone: +46 (0)70 60 46 501 https://www.ri.se --=20 Marco Tiloca Ph.D., Senior Researcher RISE Research Institutes of Sweden Division ICT Isafjordsgatan 22 / Kistag=C3=A5ngen 16 SE-164 40 Kista (Sweden) Phone: +46 (0)70 60 46 501 https://www.ri.se ------=_NextPart_000_02A7_01D557F3.409DF1E0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Marco,

 

I was not = planning to give a kid to a =E2=80=9Cmonitor=E2=80=9D entity.=C2=A0 = Since they are not supposed to be sending any messages, they = don=E2=80=99t need anything to identify the messages they are not = sending and thus don=E2=80=99t need a key id.

 

Jim

 

 

From: Marco Tiloca = <marco.tiloca@ri.se>
Sent: Tuesday, August 20, 2019 = 11:54 PM
To: Jim Schaad <ietf@augustcellars.com>; = 'Ludwig Seitz' <ludwig.seitz@ri.se>; = ace@ietf.org
Subject: Re: [Ace] Keeping the same key = identifier for groups

 

Hi Jim, all,

I believe that the = KDC should re-assign the same kid (OSCORE Sender ID) to the joining = node, also upon its second join enabled by a CWT conveying a different = PoP key than the first one.

This spares other group members from = (re-)retrieving the same public key again, and to derive a new = corresponding recipient context for the rejoined node (unless the KDC = also performs a full group rekeying upon the node's = joining).

Note that a group member configured only as = "monitor" in Group OSCORE would not provide any public key to = the KDC as paired to a signing key for group messages, since it never = produces outgoing messages to sign as per its single role in the group. = In this case, there may be no public key to use as a constant identifier = across consequent joinings of a same node to the same = group.

Best,
/Marco

On August 20, 2019 7:53:58 PM GMT+02:00, Jim Schaad = <ietf@augustcellars.com> = wrote:



-----Original =
Message-----
From: Ace <ace-bounces@ietf.org> On =
Behalf Of Ludwig Seitz
Sent: Tuesday, August 20, 2019 2:09 AM
To: =
ace@ietf.org
Subject: Re: [Ace] =
Keeping the same key identifier for groups

On 19/08/2019 22:40, =
Jim Schaad wrote:
As Ludwig pointed out during the F2F, it =
makes far more sense to try 
and keep an entity using the same key =
identifier for as long as 
possible.=C2=A0 This is in part to make =
sure that signing keys do not need 
to be retrieved if they can be =
easily cached.=C2=A0 In looking at this 
deeper during my =
implementation I ended up with the following question:

The way =
that I have set things up in my implementation it is simple to =

ensure that the same kid value is going to be used with the same =
CWT, 
however it might make more sense to use the signing key as the =

continuity identifier instead.=C2=A0 The issue that arises in this =
case is 
that there might be two different active CWT objects that =
are 
associated with the same signing key.=C2=A0 That is there are =
two CWTs but the same signing key was used
while doing a join =
operation.=C2=A0=C2=A0 I already do some matching between =
different
CWTs by assuming that if the bearer key in the CWT is the =
same then 
they are sufficiently equivalent to threat them as the =
same.=C2=A0 This 
lead to some interesting discussions in Montreal =
about if this meant 
just the "secret" or if it meant all =
of the elements provided by the 
AS which are used in the key =
derivation process.=C2=A0 (I have gone back 
and forth on this and =
currently am sitting on the "just the secret" 
side of the =
fence.)

Does anyone have any =
opinions?
Could you please expand the =
explanation of your use case a bit?

Are you thinking of a =
scenario where someone would be using the counter-signature key from =
group-OSCORE as a proof-of-possession (pop) key in serveral =
CWTs?

What would these CWT authorize?

Why would an entity =
hold several CWTs for the same audience?

[JLS]=C2=A0 Trying to =
get a bit more detailed on the situations that I am thinking =
about.=C2=A0=C2=A0 At the moment I am working on group key manager code =
so both of these are going to be couched in those terms and not in =
general terms.

I have a CWT that says group X is fine for this =
entity.=C2=A0 The CWT expires or is going to expire soon.=C2=A0 The AS =
does not use the same pop-key in a newly issued CWT.=C2=A0 The CWT is =
posted to the Group KDC and the entity performs a join under that new =
CWT, but with the same signing key for group messaging.=C2=A0=C2=A0 =
Should this operation preserve the group kid assigned to that entity =
based on the signing key or should it be a new group kid based on the =
new CWT pop key.=C2=A0 That is Entity E1 using CWT1 and public key S1 =
received a GK-kid value for group G1.=C2=A0 E1 then posts CWT2, with a =
different pop-key, does a join request for G1 using the new pop-key and =
S1.=C2=A0 Does the AS return GK-kid or GK-kid2?

This can happen =
in any number of different situations:=C2=A0 Adding or removing group Y =
from the token, token renewal, reboot of somebody so state is lost, key =
exhaustion or merely a requirement from the AS that symmetric pop keys =
be rotated based on duration.



Side-note:
My stance on =
multiple CWTs linked to the same pop-key and for the same audience is =
that the latter one should supersede the previous ones.
Example: If =
you have a CWT authorizing A for audience Z and you now also need =
authorization B for audience Z, you should request a CWT for A+B for =
audience Z, that replaces your previous one.

[JLS]=C2=A0 I agree =
that this is the preferred way for these things to happen, that is =
either the request says use the same pop-key or the AS just uses the =
same pop-key because it knows that a similar CWT exists already.=C2=A0 =
However there are reasons why that cannot be done.=C2=A0 Easy example, =
my AS does not currently have any memory so it can never issue a new CWT =
with the same symmetric pop-key.=C2=A0 It can do it with the same =
asymmetric pop key.


jim

[JLS]=C2=A0 =


/Ludwig




--
Ludwig Seitz, PhD
Security =
Lab, RISE
Phone +46(0)70-349 92 51
Ace mailing list
Ace@ietf.org
https://www.ietf.org/m=
ailman/listinfo/ace


--
Marco Tiloca
Ph.D., Senior = Researcher

RISE Research Institutes of Sweden
Division = ICT
Isafjordsgatan 22 / Kistag=C3=A5ngen 16
SE-164 40 Kista = (Sweden)

Phone: +46 (0)70 60 46 501
https://www.ri.se
--
Marco = Tiloca
Ph.D., Senior Researcher

RISE Research Institutes of = Sweden
Division ICT
Isafjordsgatan 22 / Kistag=C3=A5ngen = 16
SE-164 40 Kista (Sweden)

Phone: +46 (0)70 60 46 501
https://www.ri.se

------=_NextPart_000_02A7_01D557F3.409DF1E0-- From nobody Sun Aug 25 23:40:05 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EDB61200A4; Sun, 25 Aug 2019 23:40:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=risecloud.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FOLs_MfYAgcF; Sun, 25 Aug 2019 23:40:00 -0700 (PDT) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30045.outbound.protection.outlook.com [40.107.3.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 A2A661200D7; Sun, 25 Aug 2019 23:39:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=lYVKgEslSbUP/B1Y2wqkrfz/6fIs1R30RSY2J8z6OsGAgIlGvSNQdqCS0bDO+gMUMB0Hr2pu1iDKkdWjaDCJ/ZrRUmfWe1L4XwZRv+b7aFaLVhtKOJKmtYh53UWohvb4QxJSWnHrtOZriUFADf3Uud6/ENCfzzhKtlbTy3CuuNwcpauMOr2+8cbmmpeoCCfJiwvt9soLf4yryW+iTUmjNmT8HRTKPF6aq6yEaxGuEWZ4N42M3kxoLdmsyDOnAP61x5HDIyPWZeuHU5LmM26tRq2L6LF1mHnXwQVIsZWE1Q5NOzWOyQZ9tO55+EgroT/PWd1rGx7q2gm4PCJnW/d3qw== 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=i5nNWjgDpf+mKEq0nzgfkKuRQNnteSpHLRDe/rWnn7A=; b=SUUr6ZWMNpe87IScVzUNb+F/QFBGDbOHoXNuJetWmB08gFQlZ5PnMci5GFCYgonKox+US0LhfSLt3b0Rr5ozjBQx3STu3bD4LVdWPrX2z/IMFZvDHtuT114FMCuOyv9OLGCWf7rSFt2t19b8L9s2wvkcSoPxe+u61rfmJR00VQBfd1oPawmSyNg3jqzgz5+UMjNLq4vfvZQuJ7lrRwD2jxV7xcqW/NY/Z219PXa4clgSFfEdfuSD1V/XEZPy/koETN1PYLXM4UyZBNxQljZOd45E6vUXdZEsCxBA8RG41c5ri10pZ7floa7cjhfOxq4frqFBiIfRqxVo3hIYh8Dfsw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 194.218.146.197) smtp.rcpttodomain=ietf.org smtp.mailfrom=ri.se; dmarc=pass (p=none sp=none pct=100) action=none header.from=ri.se; dkim=none (message not signed); arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=RISEcloud.onmicrosoft.com; s=selector2-RISEcloud-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=i5nNWjgDpf+mKEq0nzgfkKuRQNnteSpHLRDe/rWnn7A=; b=ewDwxHxKEHO0LzDALbtSqcPF8/5sf5crxFHW4KfvYrVSOE7pqnhKQLtEOUmQltiPi63EzkT4CT5VApPVZ7k2T77UxT7aTblcjn1wxAbYdeNwthf4F7hroxiDTpTHscJ+kGQZBPXM+vCRRTedFfmd6SNQBfzTQQr5uBpNYEf+D14= Received: from HE1P189CA0014.EURP189.PROD.OUTLOOK.COM (2603:10a6:7:53::27) by AM5P18901MB0209.EURP189.PROD.OUTLOOK.COM (2603:10a6:203:6f::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2199.21; Mon, 26 Aug 2019 06:39:56 +0000 Received: from AM5EUR02FT040.eop-EUR02.prod.protection.outlook.com (2a01:111:f400:7e1e::209) by HE1P189CA0014.outlook.office365.com (2603:10a6:7:53::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.2199.14 via Frontend Transport; Mon, 26 Aug 2019 06:39:55 +0000 Authentication-Results: spf=pass (sender IP is 194.218.146.197) smtp.mailfrom=ri.se; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=pass action=none header.from=ri.se; Received-SPF: Pass (protection.outlook.com: domain of ri.se designates 194.218.146.197 as permitted sender) receiver=protection.outlook.com; client-ip=194.218.146.197; helo=mail.ri.se; Received: from mail.ri.se (194.218.146.197) by AM5EUR02FT040.mail.protection.outlook.com (10.152.9.8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.20.2199.13 via Frontend Transport; Mon, 26 Aug 2019 06:39:55 +0000 Received: from [10.112.134.122] (10.100.0.158) by sp-mail-2.sp.se (10.100.0.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Mon, 26 Aug 2019 08:39:55 +0200 To: Benjamin Kaduk CC: , References: <20190730155605.GM47715@kduck.mit.edu> <92fc4816-3447-62e3-e2fa-e6d92ea772e3@ri.se> <20190812231518.GF88236@kduck.mit.edu> From: Ludwig Seitz Message-ID: Date: Mon, 26 Aug 2019 08:39:54 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <20190812231518.GF88236@kduck.mit.edu> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms060608030101070009020000" X-Originating-IP: [10.100.0.158] X-ClientProxiedBy: sp-mail-3.sp.se (10.100.0.163) To sp-mail-2.sp.se (10.100.0.162) X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:194.218.146.197; IPV:NLI; CTRY:SE; EFV:NLI; SFV:NSPM; SFS:(10009020)(4636009)(136003)(346002)(376002)(396003)(39850400004)(2980300002)(189003)(199004)(58126008)(16586007)(2906002)(81156014)(81166006)(40036005)(66574012)(54906003)(6306002)(229853002)(7736002)(36756003)(16576012)(22746008)(106002)(5660300002)(235185007)(31696002)(356004)(305945005)(26005)(16526019)(186003)(70586007)(22756006)(76176011)(53546011)(386003)(11346002)(5024004)(476003)(2616005)(44832011)(486006)(33964004)(65806001)(65956001)(14444005)(126002)(446003)(6116002)(2171002)(6246003)(966005)(336012)(70206006)(31686004)(3846002)(86362001)(6916009)(568964002)(4326008)(8676002)(8936002)(478600001)(71190400001)(53936002)(316002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM5P18901MB0209; H:mail.ri.se; FPR:; SPF:Pass; LANG:en; PTR:InfoDomainNonexistent; MX:1; A:1; X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 9cf06a50-5e6c-469f-225a-08d729f0353d X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600166)(711020)(4605104)(4709080)(1401327)(2017052603328)(7193020); SRVR:AM5P18901MB0209; X-MS-TrafficTypeDiagnostic: AM5P18901MB0209: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-Forefront-PRVS: 01415BB535 X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Message-Info: xVNlCBdHO4wX1OUofNy2BfGJNnwQIsk264kZvIBSO9O8RmVaBslldXqo6cHBrXxbtm1QtcPrSDd1tXqqRwePQ7SDyAY3VgX2+FgCFaNnnJN+lzWHF2jxWX6QuPPEm0PvT8QG0bOPLjW/tw36fbEf7mYtGiTwD9z343zCzkzRZOnZhtX+JfNNuMAFbeZ3rntc1reEdXVV/ar7EgZ3lkCoswQl+yvzmei8Gwej+APcdWF0qsRx1/IUJzbqCk1YInftVekg05nneFnR+lz2LZFWkBxi+H7dO9qqasigv/jSP9gNQcjZS106QiWU9IF/IAb4AQASaAwGBPfpXfckUgFS05gzwguD2ryn4XqTzw90rOEbFG71Gmvh8NCAZDWeHTOxrN2LQPDsL3Uf0EofWAtmXo4HqChxZJsx+nHhI6RwbUY= X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Aug 2019 06:39:55.7412 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 9cf06a50-5e6c-469f-225a-08d729f0353d X-MS-Exchange-CrossTenant-Id: 5a9809cf-0bcb-413a-838a-09ecc40cc9e8 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=5a9809cf-0bcb-413a-838a-09ecc40cc9e8; Ip=[194.218.146.197]; Helo=[mail.ri.se] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5P18901MB0209 Archived-At: 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Aug 2019 06:40:04 -0000 --------------ms060608030101070009020000 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable 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 representi= ng a >>> symmetric key, provided that the CWT is encrypted so that the ke= y is >>> not revealed to unintended parties. The means of encrypting a C= WT is >>> explained in [RFC8392]. If the CWT is not encrypted, the symmet= ric >>> key MUST be encrypted as described in Section 3.3. >>> >>> It's hard for me to escape the conclusion that this paragraph needs t= o >>> be a dedicated section with a bit more discussion about how exactly t= his >>> usage is performed and encoded. >>> >> >> This mirrors the corresponding procedure in RFC 7800. Would it be OK t= o >> just refer to that document >> (https://tools.ietf.org/html/rfc7800#section-3 or actually 3.3)? >=20 > (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 bl= ock > the document from advancing if you just refer back to JWT. > G=C3=B6ran and I have discussed this, and we agree that it is indeed=20 underspecified (e.g. which key is used to encrypt this "inner"=20 COSE_Encrypt0 contained in the cnf element?). Additionally I can=20 personally confirm that this is a headache to implement (and I haven't=20 even touched a constrained implementation). We see two alternatives here: 1.) Remove the possibility to have a separate encrypted cnf element.=20 Instead mandate that the whole CWT should be encrypted if it contains a=20 secret key. + make spec easier (to implement) and doesn't requires a long=20 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=20 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 diagno= stic >>> notation, with linebreaks for readability) illustrates the use o= f 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. >=20 > Maybe I'm confused about how the diagnostic notation works, but the > top-level CWT map key name ("claim") is "Encrypted_COSE_Key", as matche= s > iss/sub/aud/etc. in the preceding notation. If the rules are different= for > map keys whose corresponding values are themselves structured data type= s, > then I should just unconfuse myself and we can move on with things... >=20 > 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 Ke= y 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 presente= r >>> to go back to the issuer and try again? (How do we know that the iss= uer >>> 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 suppos= e. >> Do you think this merits some text? >=20 > It's not entirely clear to me that we need to add more text here, but i= f we > did, it would focus on what "decide not to use" means at a protocol lev= el, > and perhaps how the CWT might not "fit the recipient's requirements" (e= =2Eg., > 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. Spe= cial >>> care has to be applied when carrying symmetric keys inside the C= WT >>> 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 earl= ier >>> 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. >=20 > That doesn't cover the *confidentiality* protection, specifically. (So= it > seems the answer to my original question is still unclear, at least to = me.) >=20 Issue created here: https://github.com/cwt-cnf/i-d/issues/22 Will fix. >=20 >>> Section 6 >>> >>> ensure correct processing. The recipient needs to be able to us= e >>> credentials to verify the authenticity, integrity, and potential= ly >>> the confidentiality of the CWT and its content. This requires t= he >>> >>> 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 recipien= t'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? >=20 > Note that I was specifically asking about "potentially the > confidentiality"; I don't understand the intended workflow for verifica= tion > 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 includ= e >>> determining whether the proposed registration duplicates existin= g >>> functionality, determining whether it is likely to be of general= >>> applicability or whether it is useful only for a single applicat= ion, >>> and evaluating the security properties of the item being registe= red >>> 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? Wha= t >>> about general vs. specific applicability? The latter seems more clea= rly >>> applicable for determining which range from which to allocate, since >>> that has impact on the encoding size. Can the experts insist on upda= tes >>> to the security considerations text of a specification prior to grant= ing >>> 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. --=20 Ludwig Seitz, PhD Security Lab, RISE Phone +46(0)70-349 92 51 --------------ms060608030101070009020000 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DT0wggYWMIID/qADAgECAg8BaKlzCTJTye3phLaz/cIwDQYJKoZIhvcNAQELBQAwRzELMAkG A1UEBhMCU0UxFDASBgNVBAoMC1RlbGlhU29uZXJhMSIwIAYDVQQDDBlUZWxpYVNvbmVyYSBD bGFzcyAyIENBIHYyMB4XDTE5MDIwMTE0MjUxNVoXDTIxMDIwMTE0MjUxNFowgYsxCzAJBgNV BAYTAlNFMS4wLAYDVQQKDCVSSVNFIFJlc2VhcmNoIEluc3RpdHV0ZXMgb2YgU3dlZGVuIEFC MRUwEwYDVQQDDAxMdWR3aWcgU2VpdHoxEjAQBgNVBAUTCUx1ZHdpZ1NlaTEhMB8GCSqGSIb3 DQEJARYSbHVkd2lnLnNlaXR6QHJpLnNlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAlJNmRfcsto5I/yXrBIi9QroZtfAMttc1Eznv5iPCK++eFUArODhITO7k9rtlQX5D8vYF v4vzZex58YWZhvGMzDj9FdpD/PHKOxL/frlrreChuissPWo5M88DmL3V1oyGzvgeRqaafpEi 0/2+gezMFlABm/BXj3/0Fiw5Sxub7essE27EtDK05nAbUB69kfLHBEytbTAuuSb11hC1dpTf itMZkzSFwsBCyPtIv3GRt9xgnOPK4RRpHidv1GLYXNQQ7xEGhFy4qbZ2NSfM+56SSRswvW9P 5n81ZmZ4FWkiJouUIYtZ2ifncBJL4DC2chjsywDEz5No7kYrGxc5oOm1YQIDAQABo4IBuDCC AbQwHwYDVR0jBBgwFoAUnhn/5Q06/gCXFT9p8dxaPKoMlIMwHQYDVR0OBBYEFKZHZ8MZNNP5 tXMPjeFiw01pUWbtMA4GA1UdDwEB/wQEAwIFoDBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEB DDA6MDgGCCsGAQUFBwIBFixodHRwczovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEu Y29tL0NQUzAdBgNVHREEFjAUgRJsdWR3aWcuc2VpdHpAcmkuc2UwTQYDVR0fBEYwRDBCoECg PoY8aHR0cDovL2NybC0yLnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYWNsYXNz MmNhdjIuY3JsMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjB+BggrBgEFBQcBAQRy MHAwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnRydXN0LnRlbGlhLmNvbTBFBggrBgEFBQcw AoY5aHR0cDovL2NhLnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYWNsYXNzMmNh djIuY2VyMA0GCSqGSIb3DQEBCwUAA4ICAQCk0GOalOCjEJObuBeMg0QREtBP/2ona16npn+T v5R3Vjk5UsQdOaOosgVjADX68C83dyfPiWR4UfNJoTBcM8JLpEXIm+xC4BiDPTPHYvgkhgXt 9VWCRWXOMfT/UPXjiGsbPuNWja1LQzF5KOmM826kHVZItHuDY6kJLE4OZ+apFvVKtSLQJJLA 4MlDVwp5+XsZi4cftcX5HdgLdChodUPKq3XVfALfXM/p81XEFBTYOHNplr3cQytDQjsnCZnS Ic4UpsxrArNxDO9+AKu/s1Fbq494AhHj4oHcg4DIjhHUzbPCLP19Gqp4dflr/V7Ulg3d+4Zh bmSAn1cffrzvvkjVrqMgQOoHQTl2QyO9n/oJ/9CSYRmhFsQMPun9LM/p5l58dTZp53B3LgA6 FFrxnntlZnTPh3bvsMJvUQ+AoiXyQwnkdxUrhoM+gUz36t3JSA8g48h7BhPsnwQ/YrarAhJ8 ifuzykTQmDseWLjJKyFflddy/azAlPQjgSMMWOZCo2s+l+WwPISf33nls2Aec/vvG5auYHS6 pwWuVKuwZTPgJfHanZTNpBM5y0jVBz6tr8AHZypnCONgyUYA4uec3v5oWz4FvLEnlKnMGoK3 OeFGvfHG0tbP25HbdN3AJYP0EUo56wfkBOYsnmn4mEYdk2GHkJNfaQRBJljH0T7TOcmcDjCC Bx8wggUHoAMCAQICEGN8C9eFpb8p2mAtfE16cLEwDQYJKoZIhvcNAQELBQAwNzEUMBIGA1UE CgwLVGVsaWFTb25lcmExHzAdBgNVBAMMFlRlbGlhU29uZXJhIFJvb3QgQ0EgdjEwHhcNMTQx MDE2MDgzOTMwWhcNMzIxMDE2MDUwNDAwWjBHMQswCQYDVQQGEwJTRTEUMBIGA1UECgwLVGVs aWFTb25lcmExIjAgBgNVBAMMGVRlbGlhU29uZXJhIENsYXNzIDIgQ0EgdjIwggIiMA0GCSqG SIb3DQEBAQUAA4ICDwAwggIKAoICAQC0PpW2qcWGnStqfa5DjrUi79Kz2SySUlJ1kiEQ1Pd/ LWbnsEwFYPqOJwAf6ZtEDtQ/9Z1VkVNQ6MkD++keqk7648x0YANgMyiJsWrbd0TKOObtlXdJ pb5qesJ5nOAdVeL3z6lgrkZx+fsUfTV+lLRGRh2+RWzZTjPAvKotY3nAwXCHtwI5v3FKuR10 aJ9+CEOka02KSUzGjcGZwMk2io0DxLELf1gPRvqE9xmn4ioXLqpluozb4Fo9ewydufTLQc3/ I63uPQh8BlLPPIGzWb4iBDq2zbWlbx0KlH/UlUZ7fjzp6N6cAqZ2NnDaCOnnIRfUYeNXFG8/ aiBeFOpEeEpclr5QUwr9HLKL1QiyQtc/wW8acQFoKuGi8myiAch7k7S0rmU5gT05je+OTzWh Oaw7gmDdndYY1mjkPkzpQ+hxyfnwUsAitUq9j0imFOLxKWLH4QNbyuDIMvDyezzJWzMy3XPB LiLSH9CBLVQHRoQ+WW8xD4rnmvQtoGZM72og2iNf4/JCHL1AJYhQtaRjYgm3rhvAP0HhSVAB Z5aHM52ylJHC3JwUyuFm8S9A2ffY9rUTffMLWmDCnX0QAP9bKr6+ACogm4DBUj3ftYodI2TD 6F8+VjSFuCzGDPuCjK+fQ2c3wqziwFl+NgoGI9Vgc6x5+0ocKkiQAIYFaQ3SyGmI6QIDAQAB o4ICFTCCAhEwgYoGCCsGAQUFBwEBBH4wfDAtBggrBgEFBQcwAYYhaHR0cDovL29jc3AudHJ1 c3QudGVsaWFzb25lcmEuY29tMEsGCCsGAQUFBzAChj9odHRwOi8vcmVwb3NpdG9yeS50cnVz dC50ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5jZXIwEgYDVR0TAQH/BAgw BgEB/wIBADBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEBAjA6MDgGCCsGAQUFBwIBFixodHRw czovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQUzAOBgNVHQ8BAf8EBAMC AQYwgcYGA1UdHwSBvjCBuzBAoD6gPIY6aHR0cDovL2NybC0zLnRydXN0LnRlbGlhc29uZXJh LmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNybDB3oHWgc4ZxbGRhcDovL2NybC0xLnRydXN0 LnRlbGlhc29uZXJhLmNvbS9jbj1UZWxpYVNvbmVyYSUyMFJvb3QlMjBDQSUyMHYxLG89VGVs aWFTb25lcmE/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnkwHQYDVR0OBBYEFJ4Z /+UNOv4AlxU/afHcWjyqDJSDMB8GA1UdIwQYMBaAFPCPWTgAs/WPmpYM1ev6e6oX6BMSMA0G CSqGSIb3DQEBCwUAA4ICAQB5wuZFNXR5ko9cu7PcpIyH8xaoGfpimP2GTg7qVuL92D/idIlj pqMm93WC9mgL/Uy6DExoF8xSLurLaiajoU+VG6ZWg0F7P1AXARNt0RpWI5SphxBQYM2751S8 vC/22k8Vi+qpQVIREqQPVXCIEH7U6eCY9gEVzdq9l1yPoI8n0D2a8V6GCv0RVkmIpa16rNYD tTw4j3Ha56/Ua33C3qeZh1dIfkaU2h4CGHd2Em3v5LLMsEh8dqUeG9yIcCU+8RUgDahNxWMe MGxzrhwk8WBV6xeoQp20p7cSHbSbyHJURC1n+nVrgdh8hbw6WOgFhNA5tCPDZ0oSF+uHfj+b ioZE3AlYdcEqHJA9A9sO58F4/Qg/yp9oYuT0ZpKb4hmzeqDXvk5KRFNfHlhTt35i+qmas9wB 11MXbYd5WwqEhZH6HWO5H7XKJP7olxmEC0W3OKlpKafq1iPsBN5ycRfUrXFss0Ax6vpCq0XA 3LYePpQ44hOU+qrkR1M0a7Eo3++3TpP4cV+FZiO4aZYZ3yZftSRHwWpGiDBdWOdTKR2GJi7Z z/OxacrmwmM1Z+WcigldbG8f3IMnOLK4X0uXjhVeAHrhuttQuM8i+4TNXgsZbmfEKNDQIQPO /lbacsGHWFB/U2y6SXVEkZs2xIciRA0iZNTv7mbIL8SZmf5wpbjDCYHiCjGCAzgwggM0AgEB MFowRzELMAkGA1UEBhMCU0UxFDASBgNVBAoMC1RlbGlhU29uZXJhMSIwIAYDVQQDDBlUZWxp YVNvbmVyYSBDbGFzcyAyIENBIHYyAg8BaKlzCTJTye3phLaz/cIwDQYJYIZIAWUDBAIBBQCg ggGvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE5MDgyNjA2 Mzk1NFowLwYJKoZIhvcNAQkEMSIEIGOsU/AF2uQb86UWoTd6bCxz9+2PKtQHCVzAZ8LUxiQR MGkGCSsGAQQBgjcQBDFcMFowRzELMAkGA1UEBhMCU0UxFDASBgNVBAoMC1RlbGlhU29uZXJh MSIwIAYDVQQDDBlUZWxpYVNvbmVyYSBDbGFzcyAyIENBIHYyAg8BaKlzCTJTye3phLaz/cIw awYLKoZIhvcNAQkQAgsxXKBaMEcxCzAJBgNVBAYTAlNFMRQwEgYDVQQKDAtUZWxpYVNvbmVy YTEiMCAGA1UEAwwZVGVsaWFTb25lcmEgQ2xhc3MgMiBDQSB2MgIPAWipcwkyU8nt6YS2s/3C MGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0D BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwIC ASgwDQYJKoZIhvcNAQEBBQAEggEAdPokr/VohsTqLsWYUZ7QK4PemwA6yxvlHFXWPxlSQJ+4 iZCu14poBUFPMhcBIPhmj6iyQsGD1otBPCDzFNnPYlF9Mbuovkn0gyncCG6mVpJMpK15BW+1 C9EG0aoZbraMLICCzKiTMyVdVMtk1KLGdKV+rZ7HnkDOTubudEzGBfICzirwAWRKYeyKGVGi K9mq6CYWKij3dNOhgkOFtHkWaxSO9Ic8DJigmhZW/KhjF/8LnAu5iRVXB/kWdwvoxX4We92c phlLWkwSdD16M0+nOse0HsIXUkiZSezFE2QB1LV4xy0G1GcFtCwyLDhApjhmnxWWoWKe6aTE EKkPJ6csBAAAAAAAAA== --------------ms060608030101070009020000-- From nobody Mon Aug 26 09:07:56 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA50312092E; Mon, 26 Aug 2019 09:07:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id puxuODUoz4Fm; Mon, 26 Aug 2019 09:07:52 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6121D120929; Mon, 26 Aug 2019 09:07:52 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 26 Aug 2019 09:07:22 -0700 From: Jim Schaad To: 'Ludwig Seitz' , 'Benjamin Kaduk' CC: , References: <20190730155605.GM47715@kduck.mit.edu> <92fc4816-3447-62e3-e2fa-e6d92ea772e3@ri.se> <20190812231518.GF88236@kduck.mit.edu> In-Reply-To: Date: Mon, 26 Aug 2019 09:07:19 -0700 Message-ID: <00dc01d55c28$5860e510$0922af30$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQGSG8HHJPznl9Uxd4m73YTJRCcQLAIsbVMrAlQNh+ICY0mhj6dc7UHA Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Aug 2019 16:07:55 -0000 -----Original Message----- From: Ludwig Seitz =20 Sent: Sunday, August 25, 2019 11:40 PM To: Benjamin Kaduk 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)? >=20 > (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=C3=B6ran and I have discussed this, and we agree that it is indeed=20 underspecified (e.g. which key is used to encrypt this "inner"=20 COSE_Encrypt0 contained in the cnf element?). Additionally I can=20 personally confirm that this is a headache to implement (and I haven't=20 even touched a constrained implementation). [JLS] I am not sure that I understand why you believe that this is = underspecified. The identification of the key used here has exactly the = same characteristics as the key that would be used to encrypt the CWT = itself. The configuration is going to be "Here is a signing key plus a = key encryption key" as oppose to "Here is a CWT encryption key". I have = not bothered to do an implementation of this only because I do not = believe that it is a useful configuration for a constrained system. The = need to do this only arises if one believes that either a) there is a = need to be able to have a third party examine the token in transit or b) = there is a need to have a higher degree of security for the token, but = not for protecting the symmetric key. Despite the fact that I have not = implemented this, I do not believe that it would be all that problematic = to implement in general, and would be even easier to implement in a = constrained system as only one format of CWT should ever be expected by = a single small device so that the structure can be hard coded. [JLS] There is a potential case for the first of those options, having = different authority servers that are passing things back and forth and a = desire to do validation that the correct permissions exist. That is the = client AS sends a request to the Resource AS which creates a token for = the RS and the client AS wants to double check the permissions granted = to the client. But I have not heard that anybody is planning to do such = an implementation yet. So far everybody is combining the two AS roles = into a single system. If you are ever in the second case, I would argue = that you are better off using asymmetric keys all the way around. We see two alternatives here: 1.) Remove the possibility to have a separate encrypted cnf element.=20 Instead mandate that the whole CWT should be encrypted if it contains a=20 secret key. + make spec easier (to implement) and doesn't requires a long=20 specification on how to handle this case - breaks direct equivalence with RFC 7800 [JLS] Given that we are starting to see people use CWTs in places where = they used to be using JWTs, I would not want to put any additional = problems in the way of this progression. If others want this construct = because of the equivalence to JWT, then let's not break it. 2.) Add some dedicated section that explains how the key for this inner=20 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 [JLS] As I said above, I don't see why this is necessary. It is part = and parcel of putting the keys that the AS is going to use on the RS=20 Jim --=20 Ludwig Seitz, PhD Security Lab, RISE Phone +46(0)70-349 92 51 From nobody Mon Aug 26 12:32:58 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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 To: Ludwig Seitz , Benjamin Kaduk CC: "draft-ietf-ace-cwt-proof-of-possession.all@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: References: <20190730155605.GM47715@kduck.mit.edu> <92fc4816-3447-62e3-e2fa-e6d92ea772e3@ri.se> <20190812231518.GF88236@kduck.mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=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: 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: 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Aug 2019 19:32:58 -0000 UGxlYXNlIHNlZSBteSByZXZpZXcgb2YgdGhlIFBSLCBMdWR3aWcuDQoNCi0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQpGcm9tOiBMdWR3aWcgU2VpdHogPGx1ZHdpZy5zZWl0ekByaS5zZT4gDQpT ZW50OiBTdW5kYXksIEF1Z3VzdCAyNSwgMjAxOSAxMTo0MCBQTQ0KVG86IEJlbmphbWluIEthZHVr IDxrYWR1a0BtaXQuZWR1Pg0KQ2M6IGRyYWZ0LWlldGYtYWNlLWN3dC1wcm9vZi1vZi1wb3NzZXNz aW9uLmFsbEBpZXRmLm9yZzsgYWNlQGlldGYub3JnDQpTdWJqZWN0OiBSZTogQUQgcmV2aWV3IG9m IGRyYWZ0LWlldGYtYWNlLWN3dC1wcm9vZi1vZi1wb3NzZXNzaW9uLTA2DQoNCkhpIEJlbiwNCg0K Zml4ZWQgbW9yZSBvZiB5b3VyIGNvbW1lbnRzIGhlcmU6IGh0dHBzOi8vZ2l0aHViLmNvbS9jd3Qt Y25mL2ktZC9wdWxsLzI0IA0KKHdhaXRpbmcgZm9yIE1pa2UgdG8gZG91YmxlLWNoZWNrIGFuZCBt ZXJnZSB0aGVtKS4NCg0KQXMgZm9yIHRob3NlIHRoYXQgYXJlIHN0aWxsIG9wZW4sIGNvbW1lbnRz IGFyZSBpbmxpbmUuDQoNCi9MdWR3aWcNCg0KT24gMTMvMDgvMjAxOSAwMToxNSwgQmVuamFtaW4g S2FkdWsgd3JvdGU6DQoNCj4+PiAgICAgIFRoZSAiQ09TRV9LZXkiIG1lbWJlciBNQVkgYWxzbyBi ZSB1c2VkIGZvciBhIENPU0VfS2V5IHJlcHJlc2VudGluZyBhDQo+Pj4gICAgICBzeW1tZXRyaWMg a2V5LCBwcm92aWRlZCB0aGF0IHRoZSBDV1QgaXMgZW5jcnlwdGVkIHNvIHRoYXQgdGhlIGtleSBp cw0KPj4+ICAgICAgbm90IHJldmVhbGVkIHRvIHVuaW50ZW5kZWQgcGFydGllcy4gIFRoZSBtZWFu cyBvZiBlbmNyeXB0aW5nIGEgQ1dUIGlzDQo+Pj4gICAgICBleHBsYWluZWQgaW4gW1JGQzgzOTJd LiAgSWYgdGhlIENXVCBpcyBub3QgZW5jcnlwdGVkLCB0aGUgc3ltbWV0cmljDQo+Pj4gICAgICBr ZXkgTVVTVCBiZSBlbmNyeXB0ZWQgYXMgZGVzY3JpYmVkIGluIFNlY3Rpb24gMy4zLg0KPj4+DQo+ Pj4gSXQncyBoYXJkIGZvciBtZSB0byBlc2NhcGUgdGhlIGNvbmNsdXNpb24gdGhhdCB0aGlzIHBh cmFncmFwaCBuZWVkcyB0bw0KPj4+IGJlIGEgZGVkaWNhdGVkIHNlY3Rpb24gd2l0aCBhIGJpdCBt b3JlIGRpc2N1c3Npb24gYWJvdXQgaG93IGV4YWN0bHkgdGhpcw0KPj4+IHVzYWdlIGlzIHBlcmZv cm1lZCBhbmQgZW5jb2RlZC4NCj4+Pg0KPj4NCj4+IFRoaXMgbWlycm9ycyB0aGUgY29ycmVzcG9u ZGluZyBwcm9jZWR1cmUgaW4gUkZDIDc4MDAuIFdvdWxkIGl0IGJlIE9LIHRvDQo+PiBqdXN0IHJl ZmVyIHRvIHRoYXQgZG9jdW1lbnQNCj4+IChodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZj NzgwMCNzZWN0aW9uLTMgb3IgYWN0dWFsbHkgMy4zKT8NCj4gDQo+IChTZWN0aW9uIDMuMiwgaXQg c2VlbXMgLS0gSldUIGFuZCBDV1QgY292ZXIgYXlzbW1ldHJpYyBhbmQgc3ltbWV0cmljIGluDQo+ IHRoZSBvcHBvc2l0ZSBvcmRlci4pDQo+IFdlbGwsIEkgc3RpbGwgd291bGRuJ3QgbGlrZSBpdC4g IEJ1dCBJIGRvbid0IHRoaW5rIEkgaGF2ZSBncm91bmRzIHRvIGJsb2NrDQo+IHRoZSBkb2N1bWVu dCBmcm9tIGFkdmFuY2luZyBpZiB5b3UganVzdCByZWZlciBiYWNrIHRvIEpXVC4NCj4NCg0KR8O2 cmFuIGFuZCBJIGhhdmUgZGlzY3Vzc2VkIHRoaXMsIGFuZCB3ZSBhZ3JlZSB0aGF0IGl0IGlzIGlu ZGVlZCANCnVuZGVyc3BlY2lmaWVkIChlLmcuIHdoaWNoIGtleSBpcyB1c2VkIHRvIGVuY3J5cHQg dGhpcyAiaW5uZXIiIA0KQ09TRV9FbmNyeXB0MCBjb250YWluZWQgaW4gdGhlIGNuZiBlbGVtZW50 PykuIEFkZGl0aW9uYWxseSBJIGNhbiANCnBlcnNvbmFsbHkgY29uZmlybSB0aGF0IHRoaXMgaXMg YSBoZWFkYWNoZSB0byBpbXBsZW1lbnQgKGFuZCBJIGhhdmVuJ3QgDQpldmVuIHRvdWNoZWQgYSBj b25zdHJhaW5lZCBpbXBsZW1lbnRhdGlvbikuDQoNCldlIHNlZSB0d28gYWx0ZXJuYXRpdmVzIGhl cmU6DQoNCjEuKSBSZW1vdmUgdGhlIHBvc3NpYmlsaXR5IHRvIGhhdmUgYSBzZXBhcmF0ZSBlbmNy eXB0ZWQgY25mIGVsZW1lbnQuIA0KSW5zdGVhZCBtYW5kYXRlIHRoYXQgdGhlIHdob2xlIENXVCBz aG91bGQgYmUgZW5jcnlwdGVkIGlmIGl0IGNvbnRhaW5zIGEgDQpzZWNyZXQga2V5Lg0KDQorIG1h a2Ugc3BlYyBlYXNpZXIgKHRvIGltcGxlbWVudCkgYW5kIGRvZXNuJ3QgcmVxdWlyZXMgYSBsb25n IA0Kc3BlY2lmaWNhdGlvbiBvbiBob3cgdG8gaGFuZGxlIHRoaXMgY2FzZQ0KDQotIGJyZWFrcyBk aXJlY3QgZXF1aXZhbGVuY2Ugd2l0aCBSRkMgNzgwMA0KDQoyLikgQWRkIHNvbWUgZGVkaWNhdGVk IHNlY3Rpb24gdGhhdCBleHBsYWlucyBob3cgdGhlIGtleSBmb3IgdGhpcyBpbm5lciANCmVuY3J5 cHRlZCBjbmYgZWxlbWVudCBpcyBzZWxlY3RlZCBhbmQgY29tbXVuaWNhdGVkIHRvIHRoZSBSUy4N Cg0KKyBUaGUgZHJhZnQgcmVtYWlucyBmdW5jdGlvbmFsbHkgZXF1aXZhbGVudCB0byBSRkMgNzgw MA0KDQotIEluY3JlYXNlZCBkcmFmdCBjb21wbGV4aXR5IGF0IHF1ZXN0aW9uYWJsZSBnYWluDQot IFBvc3NpYmxlIGltcGxlbWVudGVyIGhlYWRhY2hlcywgZXNwZWNpYWxseSBvbiBjb25zdHJhaW5l ZCBkZXZpY2VzDQoNClRoZXJlIGlzIGFuIGlzc3VlIGFib3V0IHRoaXMgaGVyZToNCmh0dHBzOi8v Z2l0aHViLmNvbS9jd3QtY25mL2ktZC9pc3N1ZXMvMTkNCg0KDQo+Pj4gICAgICBUaGUgZm9sbG93 aW5nIGV4YW1wbGUgQ1dUIENsYWltcyBTZXQgb2YgYSBDV1QgKHVzaW5nIENCT1IgZGlhZ25vc3Rp Yw0KPj4+ICAgICAgbm90YXRpb24sIHdpdGggbGluZWJyZWFrcyBmb3IgcmVhZGFiaWxpdHkpIGls bHVzdHJhdGVzIHRoZSB1c2Ugb2YgYW4NCj4+PiAgICAgIGVuY3J5cHRlZCBzeW1tZXRyaWMga2V5 IGFzIHRoZSAiRW5jcnlwdGVkX0NPU0VfS2V5IiBtZW1iZXIgdmFsdWU6DQo+Pj4NCj4+PiAgICAg ew0KPj4+ICAgICAgL2lzcy8gMSA6ICJjb2FwczovL3NlcnZlci5leGFtcGxlLmNvbSIsDQo+Pj4g ICAgICAvc3ViLyAyIDogIjI0NDAwMzIwIiwNCj4+PiAgICAgIC9hdWQvIDM6ICJzNkJoZFJrcXQz IiwNCj4+PiAgICAgIC9leHAvIDQgOiAxMzExMjgxOTcwLA0KPj4+ICAgICAgL2lhdC8gNSA6IDEz MTEyODA5NzAsDQo+Pj4gICAgICAvY25mLyA4IDogew0KPj4+ICAgICAgL0NPU0VfRW5jcnlwdDAv IDIgOiBbDQo+Pj4NCj4+PiBTaG91bGQgdGhpcyBiZSAiL0VuY3J5cHRlZF9DT1NFX0tleS8iIGFu ZCBub3QgIi9DT1NFX0VucnlwdDAvIj8NCj4+Pg0KPj4+IFtJIGRpZCBub3QgdmFsaWRhdGUgdGhl IENPU0VfRW5jcnlwdDAgb3V0cHV0XQ0KPj4+DQo+Pg0KPj4gQ09TRV9FbmNyeXB0MCBpcyBhIGRl ZmluZWQgY29uc3RydWN0IG9mIENPU0UsIHdoaWxlIEVuY3J5cHRlZF9DT1NFX0tleQ0KPj4gaXMg bm90LiBXZSdkIGhhdmUgdG8gZGVmaW5lIGl0IG9yIHdyaXRlIGFuIGV4cGxhbmF0b3J5IGNvbW1l bnQuDQo+IA0KPiBNYXliZSBJJ20gY29uZnVzZWQgYWJvdXQgaG93IHRoZSBkaWFnbm9zdGljIG5v dGF0aW9uIHdvcmtzLCBidXQgdGhlDQo+IHRvcC1sZXZlbCBDV1QgbWFwIGtleSBuYW1lICgiY2xh aW0iKSBpcyAiRW5jcnlwdGVkX0NPU0VfS2V5IiwgYXMgbWF0Y2hlcw0KPiBpc3Mvc3ViL2F1ZC9l dGMuIGluIHRoZSBwcmVjZWRpbmcgbm90YXRpb24uICBJZiB0aGUgcnVsZXMgYXJlIGRpZmZlcmVu dCBmb3INCj4gbWFwIGtleXMgd2hvc2UgY29ycmVzcG9uZGluZyB2YWx1ZXMgYXJlIHRoZW1zZWx2 ZXMgc3RydWN0dXJlZCBkYXRhIHR5cGVzLA0KPiB0aGVuIEkgc2hvdWxkIGp1c3QgdW5jb25mdXNl IG15c2VsZiBhbmQgd2UgY2FuIG1vdmUgb24gd2l0aCB0aGluZ3MuLi4NCj4gDQo+DQoNCklzc3Vl IGNyZWF0ZWQgaGVyZSBodHRwczovL2dpdGh1Yi5jb20vY3d0LWNuZi9pLWQvaXNzdWVzLzIwDQpX aWxsIGZpeC4NCg0KDQo+Pg0KPj4+ICAgICAgbyAgQSByZWNpcGllbnQgY2FuIGRlY2lkZSBub3Qg dG8gdXNlIGEgQ1dUIGJhc2VkIG9uIGEgY3JlYXRlZCBLZXkgSUQNCj4+PiAgICAgICAgIGlmIGl0 IGRvZXMgbm90IGZpdCB0aGUgcmVjaXBpZW50J3MgcmVxdWlyZW1lbnRzLg0KPj4+DQo+Pj4gSSdt IG5vdCBzdXJlIEkgdW5kZXJzdGFuZCB0aGUgc2VtYW50aWNzIGJlaW5nIGRlc2NyaWJlZCBoZXJl LiAgQXJlIHdlDQo+Pj4gc2F5aW5nIHRoYXQgdGhlIGlzc3VlciBtaWdodCBnaXZlIGEgcHJlc2Vu dGVyIGEgQ1dULCBhbmQgYnkgdGhlIHRpbWUgdGhlDQo+Pj4gcHJlc2VudGVyIHByZXNlbnRzIHRo ZSBDV1QgdG8gdGhlIHJlY2lwaWVudCwgdGhlIHJlY2lwaWVudCBzYXlzICJ0aGlzIGlzDQo+Pj4g bm8gZ29vZCIgYW5kIGRlbmllcyB0aGUgdHJhbnNhY3Rpb24gaW4gcXVlc3Rpb24sIGZvcmNpbmcg dGhlIHByZXNlbnRlcg0KPj4+IHRvIGdvIGJhY2sgdG8gdGhlIGlzc3VlciBhbmQgdHJ5IGFnYWlu PyAgKEhvdyBkbyB3ZSBrbm93IHRoYXQgdGhlIGlzc3Vlcg0KPj4+IHdvdWxkIG1ha2UgYW55IGRp ZmZlcmVudCBjaG9pY2VzIHRoZSBzZWNvbmQgdGltZSBhcm91bmQ/KQ0KPj4NCj4+IFRoaXMgcmlz ayBhbHdheXMgZXhpc3RzLiBJbiBhIGNvbnN0cmFpbmVkIGRldmljZSB3b3JsZCwgdGhlIHJlY2lw aWVudA0KPj4gbWF5IGFscmVhZHkgaGF2ZSBjbGVhcmVkIG91dCB0aGUga2V5IHJlZmVyZW5jZWQg YnkgdGhlIGtleSBJRCwgd2hpY2gNCj4+IHdvdWxkIGZvcmNlIGl0IHRvIHJlamVjdCBhIENXVCB1 c2luZyB0aGlzIGFzIHByb29mLW9mLXBvc3Nlc3Npb24uDQo+Pg0KPj4gSSdtIG5vdCBzdXJlIGhv dyB0byBnaXZlIGdvb2QgZ3VpZGFuY2UgaW4gdGhpcyBjYXNlLiBUaGUgZXJyb3IgbWVzc2FnZQ0K Pj4gZGVsaXZlcmVkIGJ5IHRoZSByZWNpcGllbnQgcmVqZWN0aW5nIHRoZSBDV1QgbWlnaHQgYmUg aGVscGZ1bCBJIHN1cHBvc2UuDQo+PiBEbyB5b3UgdGhpbmsgdGhpcyBtZXJpdHMgc29tZSB0ZXh0 Pw0KPiANCj4gSXQncyBub3QgZW50aXJlbHkgY2xlYXIgdG8gbWUgdGhhdCB3ZSBuZWVkIHRvIGFk ZCBtb3JlIHRleHQgaGVyZSwgYnV0IGlmIHdlDQo+IGRpZCwgaXQgd291bGQgZm9jdXMgb24gd2hh dCAiZGVjaWRlIG5vdCB0byB1c2UiIG1lYW5zIGF0IGEgcHJvdG9jb2wgbGV2ZWwsDQo+IGFuZCBw ZXJoYXBzIGhvdyB0aGUgQ1dUIG1pZ2h0IG5vdCAiZml0IHRoZSByZWNpcGllbnQncyByZXF1aXJl bWVudHMiIChlLmcuLA0KPiB0aGUga2V5IGlkIGhhdmluZyBmYWxsZW4gb3V0IG9mIGNhY2hlIGFz IHlvdSBkZXNjcmliZSkuDQoNCklzc3VlIGNyZWF0ZWQgaGVyZTogaHR0cHM6Ly9naXRodWIuY29t L2N3dC1jbmYvaS1kL2lzc3Vlcy8yMQ0KV2lsbCBmaXguDQoNCj4+DQo+Pj4gICAgICBmcm9tIGNo YW5naW5nIGFueSBlbGVtZW50cyBjb252ZXllZCB3aXRoaW4gdGhlIENXVCBwYXlsb2FkLiAgU3Bl Y2lhbA0KPj4+ICAgICAgY2FyZSBoYXMgdG8gYmUgYXBwbGllZCB3aGVuIGNhcnJ5aW5nIHN5bW1l dHJpYyBrZXlzIGluc2lkZSB0aGUgQ1dUDQo+Pj4gICAgICBzaW5jZSB0aG9zZSBub3Qgb25seSBy ZXF1aXJlIGludGVncml0eSBwcm90ZWN0aW9uIGJ1dCBhbHNvDQo+Pj4gICAgICBjb25maWRlbnRp YWxpdHkgcHJvdGVjdGlvbi4NCj4+Pg0KPj4+IERvIHdlIHdhbnQgdG8gcmVpdGVyYXRlIHRoZSBj b21tb24gbWVjaGFuaXNtcyBmb3IgcHJvdmlkaW5nDQo+Pj4gY29uZmlkZW50aWFsaXR5IHByb3Rl Y3Rpb24gaGVyZSwgb3IganVzdCBsZWF2ZSB0aGUgZXhpc3RpbmcgdGV4dCBlYXJsaWVyDQo+Pj4g aW4gdGhlIGRvY3VtZW50IHRvIGNvdmVyIGl0Pw0KPj4+DQo+PiBEb2Vzbid0IGl0IHNheSBhIGZl dyBzZW50ZW5jZXMgYmVmb3JlOiAiaXQgaXMNCj4+ICAgICAgbmVjZXNzYXJ5IHRvIGFwcGx5IGRh dGEgb3JpZ2luIGF1dGhlbnRpY2F0aW9uIGFuZCBpbnRlZ3JpdHkNCj4+ICAgICAgcHJvdGVjdGlv biAodmlhIGEga2V5ZWQgbWVzc2FnZSBkaWdlc3Qgb3IgYSBkaWdpdGFsIHNpZ25hdHVyZSkuIiA/ DQo+Pg0KPj4gSSB3b3VsZCBjb25zaWRlciB0aGlzIHRvIGJlIGVub3VnaC4NCj4gDQo+IFRoYXQg ZG9lc24ndCBjb3ZlciB0aGUgKmNvbmZpZGVudGlhbGl0eSogcHJvdGVjdGlvbiwgc3BlY2lmaWNh bGx5LiAgKFNvIGl0DQo+IHNlZW1zIHRoZSBhbnN3ZXIgdG8gbXkgb3JpZ2luYWwgcXVlc3Rpb24g aXMgc3RpbGwgdW5jbGVhciwgYXQgbGVhc3QgdG8gbWUuKQ0KPiANCg0KSXNzdWUgY3JlYXRlZCBo ZXJlOiBodHRwczovL2dpdGh1Yi5jb20vY3d0LWNuZi9pLWQvaXNzdWVzLzIyDQpXaWxsIGZpeC4N Cg0KPiANCj4+PiBTZWN0aW9uIDYNCj4+Pg0KPj4+ICAgICAgZW5zdXJlIGNvcnJlY3QgcHJvY2Vz c2luZy4gIFRoZSByZWNpcGllbnQgbmVlZHMgdG8gYmUgYWJsZSB0byB1c2UNCj4+PiAgICAgIGNy ZWRlbnRpYWxzIHRvIHZlcmlmeSB0aGUgYXV0aGVudGljaXR5LCBpbnRlZ3JpdHksIGFuZCBwb3Rl bnRpYWxseQ0KPj4+ICAgICAgdGhlIGNvbmZpZGVudGlhbGl0eSBvZiB0aGUgQ1dUIGFuZCBpdHMg Y29udGVudC4gIFRoaXMgcmVxdWlyZXMgdGhlDQo+Pj4NCj4+PiBKdXN0IGZyb20gYSByaGV0b3Jp Y2FsIHBvaW50IG9mIHZpZXcsIGNhbiB5b3UgaGVscCBtZSB1bmRlcnN0YW5kIGhvdw0KPj4+IGNy ZWRlbnRpYWxzIHdvdWxkIGJlIHVzZWQgdG8gdmVyaWZ5IHRoZSBjb25maWRlbnRpYWxpdHkgb2Yg YSBDV1Q/ICBJdA0KPj4+IHNlZW1zIGxpa2UgdGhpcyBkZXBlbmRzIG9uIGVpdGhlciAob3IgYm90 aCBvZikgaG93IHRoZSBDV1QgaXMNCj4+PiB0cmFuc21pdHRlZCBvciBob3cgaXQgaXMgcHJlcGFy ZWQsIGFuZCBJIGFtIG5vdCBzdXJlIGhvdyB0aGUgcmVjaXBpZW50J3MNCj4+PiBjcmVkZW50aWFs cyBjb21lIGludG8gcGxheS4NCj4+Pg0KPj4NCj4+IFRoaXMgdGV4dCBpcyByZWZlcnJpbmcgdG8g dGhlIGlzc3VlcidzIGNyZWRlbnRpYWxzIChlLmcuIHRoZQ0KPj4gQXV0aG9yaXphdGlvbiBTZXJ2 ZXIgaXNzdWluZyB0aGUgQ1dUKSwgdGhhdCB0aGUgcmVjaXBpZW50IG5lZWRzIHRvDQo+PiB2ZXJp ZnkgdGhlIENXVC4gRG8geW91IHdhbnQgdXMgdG8gY2xhcmlmeSB0aGlzIHNlbnRlbmNlPw0KPiAN Cj4gTm90ZSB0aGF0IEkgd2FzIHNwZWNpZmljYWxseSBhc2tpbmcgYWJvdXQgInBvdGVudGlhbGx5 IHRoZQ0KPiBjb25maWRlbnRpYWxpdHkiOyBJIGRvbid0IHVuZGVyc3RhbmQgdGhlIGludGVuZGVk IHdvcmtmbG93IGZvciB2ZXJpZmljYXRpb24NCj4gb2YgY29uZmlkZW50aWFsaXR5IChhbmQgdGh1 cyB3aGljaCBjcmVkZW50aWFscyBhcmUgaW52b2x2ZWQpLiAgSSBkb24ndA0KPiByZWFsbHkgc2Vl IGhvdyBhIGNyZWRlbnRpYWwgaGVsZCBzb2xlbHkgYnkgdGhlIGlzc3VlciBjb3VsZCBwcm9pZGUN Cj4gY29uZmlkZW50aWFsaXR5IHByb3RlY3Rpb24gd2hlbiBpdCBuZWVkcyB0byBiZSB1bmRlcnN0 b29kIGJ5IHNvbWUgb3RoZXINCj4gcHJvdG9jb2wgcGFydGljaXBhbnQuDQoNCklzc3VlIGNyZWF0 ZWQgaGVyZTogaHR0cHM6Ly9naXRodWIuY29tL2N3dC1jbmYvaS1kL2lzc3Vlcy8yMw0KV2lsbCBm aXguDQoNCg0KPj4+IFNlY3Rpb24gNw0KPj4+DQo+Pj4gICAgICBDcml0ZXJpYSB0aGF0IHNob3Vs ZCBiZSBhcHBsaWVkIGJ5IHRoZSBEZXNpZ25hdGVkIEV4cGVydHMgaW5jbHVkZQ0KPj4+ICAgICAg ZGV0ZXJtaW5pbmcgd2hldGhlciB0aGUgcHJvcG9zZWQgcmVnaXN0cmF0aW9uIGR1cGxpY2F0ZXMg ZXhpc3RpbmcNCj4+PiAgICAgIGZ1bmN0aW9uYWxpdHksIGRldGVybWluaW5nIHdoZXRoZXIgaXQg aXMgbGlrZWx5IHRvIGJlIG9mIGdlbmVyYWwNCj4+PiAgICAgIGFwcGxpY2FiaWxpdHkgb3Igd2hl dGhlciBpdCBpcyB1c2VmdWwgb25seSBmb3IgYSBzaW5nbGUgYXBwbGljYXRpb24sDQo+Pj4gICAg ICBhbmQgZXZhbHVhdGluZyB0aGUgc2VjdXJpdHkgcHJvcGVydGllcyBvZiB0aGUgaXRlbSBiZWlu ZyByZWdpc3RlcmVkDQo+Pj4gICAgICBhbmQgd2hldGhlciB0aGUgcmVnaXN0cmF0aW9uIG1ha2Vz IHNlbnNlLg0KPj4+DQo+Pj4gSSBrbm93IHdlJ3ZlIGJlZW4gdXNpbmcgKHZhcmlhdGlvbnMgb2Yp IHRoaXMgdGV4dCBmb3IgYSB3aGlsZSwgYnV0IGl0DQo+Pj4gc2VlbXMgdG8gbWUgdGhhdCBpdCBj b3VsZCBiZSBtb3JlIGNsZWFyIHRoYW4gaXQgY3VycmVudGx5IGlzIC0tIGlzDQo+Pj4gZHVwbGlj YXRpb24gb2YgZnVuY3Rpb25hbGl0eSBncm91bmRzIGZvciBkZW5pYWwgb2YgcmVnaXN0cmF0aW9u PyAgV2hhdA0KPj4+IGFib3V0IGdlbmVyYWwgdnMuIHNwZWNpZmljIGFwcGxpY2FiaWxpdHk/ICBU aGUgbGF0dGVyIHNlZW1zIG1vcmUgY2xlYXJseQ0KPj4+IGFwcGxpY2FibGUgZm9yIGRldGVybWlu aW5nIHdoaWNoIHJhbmdlIGZyb20gd2hpY2ggdG8gYWxsb2NhdGUsIHNpbmNlDQo+Pj4gdGhhdCBo YXMgaW1wYWN0IG9uIHRoZSBlbmNvZGluZyBzaXplLiAgQ2FuIHRoZSBleHBlcnRzIGluc2lzdCBv biB1cGRhdGVzDQo+Pj4gdG8gdGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIHRleHQgb2YgYSBz cGVjaWZpY2F0aW9uIHByaW9yIHRvIGdyYW50aW5nDQo+Pj4gYXBwcm92YWwsIG9yIGFyZSB0aGV5 IGxpbWl0ZWQgdG8gZGVueWluZyByZWdpc3RyYXRpb24gb2YgdmFsdWVzIHdpdGgNCj4+PiBwb29y IHNlY3VyaXR5IHByb3BlcnRpZXMgb3IgaW5zdWZmaWNpZW50IGRvY3VtZW50YXRpb24gdGhlcmVv Zj8NCj4+Pg0KPj4NCj4+IEknbSB0b28gdW5mYW1pbGlhciB3aXRoIHRoZSBkZXNpZ25hdGVkIGV4 cGVydCBzeXN0ZW0gdG8gcHJvdmlkZSBhIGdvb2QNCj4+IGFuc3dlciBvbiB0aGlzIG9uZS4gQ2Fu IG9uZSBvZiBteSBjby1hdXRob3JzIGNoaXAgaW4gaGVyZT8NCj4+DQpJc3N1ZSBjcmVhdGVkIGhl cmU6IGh0dHBzOi8vZ2l0aHViLmNvbS9jd3QtY25mL2ktZC9pc3N1ZXMvMjUNCldpbGwgZml4Lg0K DQoNCi0tIA0KTHVkd2lnIFNlaXR6LCBQaEQNClNlY3VyaXR5IExhYiwgUklTRQ0KUGhvbmUgKzQ2 KDApNzAtMzQ5IDkyIDUxDQoNCg== From nobody Mon Aug 26 23:52:35 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5901B120DB8; Mon, 26 Aug 2019 23:52:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=risecloud.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WOTwSyaxqJuV; Mon, 26 Aug 2019 23:52:29 -0700 (PDT) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40068.outbound.protection.outlook.com [40.107.4.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A24E120D6A; Mon, 26 Aug 2019 23:52:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kXKO7mTMiB3pjpUE3/zy/GPneFyVYHwwdyOxgAfSXAQMdePPNs3njXBwe8wYvxPiaQCTGKge6DgCDGkS8kgq5nQj2ce7rMTINgzF28D2skTT1ayiHac4SbY11+8gfwc+X5XZ7CJAzPtS0tSMvbws8J47su8WQ3hESJTMWvOSPwEKLSVt5LOSWwtRldtoAJvUISJSkZ3za0ltysiSdmJr7s78D6ds+cpVOSOL9QVtKy2gIF+X9IRpVQusqPf2ztDWponBQP9DbqQ0X7ziHQ+oPsA4UQz/4DBJ45NR7mK9GWmyiNnUrNFC93vjNH9lWzoNpCuQD/tyVK1ugu6Nv1yUpg== 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=rBg1GI8FCLpMscdW2J9HqNEUHrSn9/GG3bQ9x6CfDS8=; b=KLXVOOXoc1IBYreslZ6eOqaiLoEFF/xUs/A9xPA9geI8EvXzc1SSgSnIflbJtAyGG2ftxddX6E+CgH3BwmRmhi83ShJ56/9vbT91zeNMKqmtAaF0MWP+uLkfMCn6ByqXVL1aRt3ma1FBBL0JT6c3y3dvauLhI3RfGhEO15/cczhSyMd9w8mvm6b4jO0dUmZpoc3p+ERvyZbFKfx3cZsukah6asZiyCwBjYWBLJuTd2yd2poIS17ywJXdI/WcsIyPt59V7O8bWLQeAaTDFmDeXrXWoYDZSdQibzle/5NWhnV5CVg6xMkFsz46HujC4nxbPnPKRe3O22vCeaNiPBUGNQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 194.218.146.197) smtp.rcpttodomain=ietf.org smtp.mailfrom=ri.se; dmarc=pass (p=none sp=none pct=100) action=none header.from=ri.se; dkim=none (message not signed); arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=RISEcloud.onmicrosoft.com; s=selector2-RISEcloud-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=rBg1GI8FCLpMscdW2J9HqNEUHrSn9/GG3bQ9x6CfDS8=; b=XeeLc5mLHXkpRQeLa/zB/3dAMQo669gz6jVYVL8oC36kMWWphq14ax4KKfoVKSNUmy7GeUWVVVbQ0uiUMewNBrkfjKhpSgRSzaM60+OPYijOsYf5RPwg52RUSa4sAG8carfWbimyJlISXYrxcDfFNoNGCW8mEKCi1hYtTznwbI4= Received: from VI1P18901CA0010.EURP189.PROD.OUTLOOK.COM (2603:10a6:801::20) by AM7P189MB0757.EURP189.PROD.OUTLOOK.COM (2603:10a6:20b:114::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2199.21; Tue, 27 Aug 2019 06:52:25 +0000 Received: from HE1EUR02FT021.eop-EUR02.prod.protection.outlook.com (2a01:111:f400:7e05::208) by VI1P18901CA0010.outlook.office365.com (2603:10a6:801::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2199.15 via Frontend Transport; Tue, 27 Aug 2019 06:52:25 +0000 Authentication-Results: spf=pass (sender IP is 194.218.146.197) smtp.mailfrom=ri.se; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=pass action=none header.from=ri.se; Received-SPF: Pass (protection.outlook.com: domain of ri.se designates 194.218.146.197 as permitted sender) receiver=protection.outlook.com; client-ip=194.218.146.197; helo=mail.ri.se; Received: from mail.ri.se (194.218.146.197) by HE1EUR02FT021.mail.protection.outlook.com (10.152.10.85) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.20.2199.13 via Frontend Transport; Tue, 27 Aug 2019 06:52:24 +0000 Received: from [10.112.134.122] (10.100.0.158) by sp-mail-2.sp.se (10.100.0.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Tue, 27 Aug 2019 08:52:23 +0200 To: Jim Schaad , 'Benjamin Kaduk' CC: , References: <20190730155605.GM47715@kduck.mit.edu> <92fc4816-3447-62e3-e2fa-e6d92ea772e3@ri.se> <20190812231518.GF88236@kduck.mit.edu> <00dc01d55c28$5860e510$0922af30$@augustcellars.com> From: Ludwig Seitz Message-ID: <4581be90-4cb1-3bce-0a5f-6c494e205442@ri.se> Date: Tue, 27 Aug 2019 08:52:23 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <00dc01d55c28$5860e510$0922af30$@augustcellars.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms040102000403000107040704" X-Originating-IP: [10.100.0.158] X-ClientProxiedBy: sp-mail-2.sp.se (10.100.0.162) To sp-mail-2.sp.se (10.100.0.162) X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:194.218.146.197; IPV:NLI; CTRY:SE; EFV:NLI; SFV:NSPM; SFS:(10009020)(4636009)(376002)(136003)(39860400002)(396003)(346002)(2980300002)(199004)(189003)(14444005)(86362001)(7736002)(5660300002)(305945005)(186003)(16526019)(31686004)(2171002)(2906002)(5024004)(4326008)(356004)(36756003)(16586007)(235185007)(106002)(336012)(476003)(81156014)(8676002)(44832011)(76176011)(229853002)(22746008)(6246003)(126002)(8936002)(40036005)(486006)(2616005)(568964002)(22756006)(446003)(11346002)(478600001)(26005)(53936002)(3846002)(316002)(6116002)(58126008)(81166006)(31696002)(70586007)(110136005)(53546011)(70206006)(386003)(54906003)(16576012)(65806001)(6306002)(66574012)(65956001)(33964004)(71190400001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM7P189MB0757; H:mail.ri.se; FPR:; SPF:Pass; LANG:en; PTR:InfoDomainNonexistent; A:1; MX:1; X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: d02596ce-967e-486b-2e2d-08d72abb1e40 X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600166)(711020)(4605104)(4709080)(1401327)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:AM7P189MB0757; X-MS-TrafficTypeDiagnostic: AM7P189MB0757: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-Forefront-PRVS: 0142F22657 X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Message-Info: cRdpDbQNABGITcO6KZcigvY1BRaHXOrIId3HDqRievLgqweUeVILuDAL6EO+h5di+Qle9dmp/rmuejGqx26hxkv9uhT7FfwKHnmw4hhBwIpGsxo9BO8SHWhPvd6c5gBk9t0/oIm3f2Go2e24ecljp8FHCZ/8c/8ayjRpLuR/p/GpOeobkPsw/Egz7JZCSYiADa0wBd8DKF4v7ppcifwyCtNj4xjjyzmF9jVn8JJEz5d5zzZQzXBXFyPwgaIO4QlTui5B80WjKTUuJQt67UVn89b5nfnmIYh0s7XQGHAPQ2VUVCqQVQD/ANr5XiZrsrGmPvf+/NQtHY2AY6MaF95bV2pMVobuWBP5Nueto9KLQ0cu6qf8JpZ1If041rWSfXmJenT0OapjktmuNyoMKRMjaHHanixQL0uJ1eHmOZQBDPs= X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Aug 2019 06:52:24.9006 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: d02596ce-967e-486b-2e2d-08d72abb1e40 X-MS-Exchange-CrossTenant-Id: 5a9809cf-0bcb-413a-838a-09ecc40cc9e8 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=5a9809cf-0bcb-413a-838a-09ecc40cc9e8; Ip=[194.218.146.197]; Helo=[mail.ri.se] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM7P189MB0757 Archived-At: 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2019 06:52:33 -0000 --------------ms040102000403000107040704 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 26/08/2019 18:07, Jim Schaad wrote: > On 13/08/2019 01:15, Benjamin Kaduk wrote: >=20 >>>> 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. >>>>=20 >>>> 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. >>>>=20 >>>=20 >>> This mirrors the corresponding procedure in RFC 7800. Would it be >>> OK to just refer to that document=20 >>> (https://tools.ietf.org/html/rfc7800#section-3 or actually 3.3)? >>=20 >> (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. >>=20 >=20 > G=C3=B6ran and I have discussed this, and we agree that it is indeed=20 > underspecified (e.g. which key is used to encrypt this "inner"=20 > COSE_Encrypt0 contained in the cnf element?). Additionally I can=20 > personally confirm that this is a headache to implement (and I > haven't even touched a constrained implementation). >=20 > [JLS] I am not sure that I understand why you believe that this is > underspecified.=20 Because the AD said so ;-) Seriously: I believe that this warrants more text, since it must be at=20 least clarified that this construct assumes two pre-configured keys=20 shared between AS and RS: one for encrypting the inner cnf element and=20 one for integrity protecting the whole CWT. > Despite the fact that I have not implemented this, I > do not believe that it would be all that problematic to implement in > general, and would be even easier to implement in a constrained > system as only one format of CWT should ever be expected by a single > small device so that the structure can be hard coded. Perhaps 'headache' was a hyperbole on my part, but there is definitely a = code-complexity difference between "parsing CBOR" and "parsing CBOR,=20 interrupt the parsing to decrypt stuff, continue parsing CBOR". > [JLS] There is a potential case for the first of those options, > having different authority servers that are passing things back and > forth and a desire to do validation that the correct permissions > exist. That is the client AS sends a request to the Resource AS > which creates a token for the RS and the client AS wants to double > check the permissions granted to the client. But I have not heard > that anybody is planning to do such an implementation yet. So far > everybody is combining the two AS roles into a single system. If you > are ever in the second case, I would argue that you are better off > using asymmetric keys all the way around. I can see this use case. That rules out my option 1. of removing this=20 construct. /Ludwig --=20 Ludwig Seitz, PhD Security Lab, RISE Phone +46(0)70-349 92 51 --------------ms040102000403000107040704 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DT0wggYWMIID/qADAgECAg8BaKlzCTJTye3phLaz/cIwDQYJKoZIhvcNAQELBQAwRzELMAkG A1UEBhMCU0UxFDASBgNVBAoMC1RlbGlhU29uZXJhMSIwIAYDVQQDDBlUZWxpYVNvbmVyYSBD bGFzcyAyIENBIHYyMB4XDTE5MDIwMTE0MjUxNVoXDTIxMDIwMTE0MjUxNFowgYsxCzAJBgNV BAYTAlNFMS4wLAYDVQQKDCVSSVNFIFJlc2VhcmNoIEluc3RpdHV0ZXMgb2YgU3dlZGVuIEFC MRUwEwYDVQQDDAxMdWR3aWcgU2VpdHoxEjAQBgNVBAUTCUx1ZHdpZ1NlaTEhMB8GCSqGSIb3 DQEJARYSbHVkd2lnLnNlaXR6QHJpLnNlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAlJNmRfcsto5I/yXrBIi9QroZtfAMttc1Eznv5iPCK++eFUArODhITO7k9rtlQX5D8vYF v4vzZex58YWZhvGMzDj9FdpD/PHKOxL/frlrreChuissPWo5M88DmL3V1oyGzvgeRqaafpEi 0/2+gezMFlABm/BXj3/0Fiw5Sxub7essE27EtDK05nAbUB69kfLHBEytbTAuuSb11hC1dpTf itMZkzSFwsBCyPtIv3GRt9xgnOPK4RRpHidv1GLYXNQQ7xEGhFy4qbZ2NSfM+56SSRswvW9P 5n81ZmZ4FWkiJouUIYtZ2ifncBJL4DC2chjsywDEz5No7kYrGxc5oOm1YQIDAQABo4IBuDCC AbQwHwYDVR0jBBgwFoAUnhn/5Q06/gCXFT9p8dxaPKoMlIMwHQYDVR0OBBYEFKZHZ8MZNNP5 tXMPjeFiw01pUWbtMA4GA1UdDwEB/wQEAwIFoDBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEB DDA6MDgGCCsGAQUFBwIBFixodHRwczovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEu Y29tL0NQUzAdBgNVHREEFjAUgRJsdWR3aWcuc2VpdHpAcmkuc2UwTQYDVR0fBEYwRDBCoECg PoY8aHR0cDovL2NybC0yLnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYWNsYXNz MmNhdjIuY3JsMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjB+BggrBgEFBQcBAQRy MHAwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnRydXN0LnRlbGlhLmNvbTBFBggrBgEFBQcw AoY5aHR0cDovL2NhLnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYWNsYXNzMmNh djIuY2VyMA0GCSqGSIb3DQEBCwUAA4ICAQCk0GOalOCjEJObuBeMg0QREtBP/2ona16npn+T v5R3Vjk5UsQdOaOosgVjADX68C83dyfPiWR4UfNJoTBcM8JLpEXIm+xC4BiDPTPHYvgkhgXt 9VWCRWXOMfT/UPXjiGsbPuNWja1LQzF5KOmM826kHVZItHuDY6kJLE4OZ+apFvVKtSLQJJLA 4MlDVwp5+XsZi4cftcX5HdgLdChodUPKq3XVfALfXM/p81XEFBTYOHNplr3cQytDQjsnCZnS Ic4UpsxrArNxDO9+AKu/s1Fbq494AhHj4oHcg4DIjhHUzbPCLP19Gqp4dflr/V7Ulg3d+4Zh bmSAn1cffrzvvkjVrqMgQOoHQTl2QyO9n/oJ/9CSYRmhFsQMPun9LM/p5l58dTZp53B3LgA6 FFrxnntlZnTPh3bvsMJvUQ+AoiXyQwnkdxUrhoM+gUz36t3JSA8g48h7BhPsnwQ/YrarAhJ8 ifuzykTQmDseWLjJKyFflddy/azAlPQjgSMMWOZCo2s+l+WwPISf33nls2Aec/vvG5auYHS6 pwWuVKuwZTPgJfHanZTNpBM5y0jVBz6tr8AHZypnCONgyUYA4uec3v5oWz4FvLEnlKnMGoK3 OeFGvfHG0tbP25HbdN3AJYP0EUo56wfkBOYsnmn4mEYdk2GHkJNfaQRBJljH0T7TOcmcDjCC Bx8wggUHoAMCAQICEGN8C9eFpb8p2mAtfE16cLEwDQYJKoZIhvcNAQELBQAwNzEUMBIGA1UE CgwLVGVsaWFTb25lcmExHzAdBgNVBAMMFlRlbGlhU29uZXJhIFJvb3QgQ0EgdjEwHhcNMTQx MDE2MDgzOTMwWhcNMzIxMDE2MDUwNDAwWjBHMQswCQYDVQQGEwJTRTEUMBIGA1UECgwLVGVs aWFTb25lcmExIjAgBgNVBAMMGVRlbGlhU29uZXJhIENsYXNzIDIgQ0EgdjIwggIiMA0GCSqG SIb3DQEBAQUAA4ICDwAwggIKAoICAQC0PpW2qcWGnStqfa5DjrUi79Kz2SySUlJ1kiEQ1Pd/ LWbnsEwFYPqOJwAf6ZtEDtQ/9Z1VkVNQ6MkD++keqk7648x0YANgMyiJsWrbd0TKOObtlXdJ pb5qesJ5nOAdVeL3z6lgrkZx+fsUfTV+lLRGRh2+RWzZTjPAvKotY3nAwXCHtwI5v3FKuR10 aJ9+CEOka02KSUzGjcGZwMk2io0DxLELf1gPRvqE9xmn4ioXLqpluozb4Fo9ewydufTLQc3/ I63uPQh8BlLPPIGzWb4iBDq2zbWlbx0KlH/UlUZ7fjzp6N6cAqZ2NnDaCOnnIRfUYeNXFG8/ aiBeFOpEeEpclr5QUwr9HLKL1QiyQtc/wW8acQFoKuGi8myiAch7k7S0rmU5gT05je+OTzWh Oaw7gmDdndYY1mjkPkzpQ+hxyfnwUsAitUq9j0imFOLxKWLH4QNbyuDIMvDyezzJWzMy3XPB LiLSH9CBLVQHRoQ+WW8xD4rnmvQtoGZM72og2iNf4/JCHL1AJYhQtaRjYgm3rhvAP0HhSVAB Z5aHM52ylJHC3JwUyuFm8S9A2ffY9rUTffMLWmDCnX0QAP9bKr6+ACogm4DBUj3ftYodI2TD 6F8+VjSFuCzGDPuCjK+fQ2c3wqziwFl+NgoGI9Vgc6x5+0ocKkiQAIYFaQ3SyGmI6QIDAQAB o4ICFTCCAhEwgYoGCCsGAQUFBwEBBH4wfDAtBggrBgEFBQcwAYYhaHR0cDovL29jc3AudHJ1 c3QudGVsaWFzb25lcmEuY29tMEsGCCsGAQUFBzAChj9odHRwOi8vcmVwb3NpdG9yeS50cnVz dC50ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5jZXIwEgYDVR0TAQH/BAgw BgEB/wIBADBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEBAjA6MDgGCCsGAQUFBwIBFixodHRw czovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQUzAOBgNVHQ8BAf8EBAMC AQYwgcYGA1UdHwSBvjCBuzBAoD6gPIY6aHR0cDovL2NybC0zLnRydXN0LnRlbGlhc29uZXJh LmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNybDB3oHWgc4ZxbGRhcDovL2NybC0xLnRydXN0 LnRlbGlhc29uZXJhLmNvbS9jbj1UZWxpYVNvbmVyYSUyMFJvb3QlMjBDQSUyMHYxLG89VGVs aWFTb25lcmE/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnkwHQYDVR0OBBYEFJ4Z /+UNOv4AlxU/afHcWjyqDJSDMB8GA1UdIwQYMBaAFPCPWTgAs/WPmpYM1ev6e6oX6BMSMA0G CSqGSIb3DQEBCwUAA4ICAQB5wuZFNXR5ko9cu7PcpIyH8xaoGfpimP2GTg7qVuL92D/idIlj pqMm93WC9mgL/Uy6DExoF8xSLurLaiajoU+VG6ZWg0F7P1AXARNt0RpWI5SphxBQYM2751S8 vC/22k8Vi+qpQVIREqQPVXCIEH7U6eCY9gEVzdq9l1yPoI8n0D2a8V6GCv0RVkmIpa16rNYD tTw4j3Ha56/Ua33C3qeZh1dIfkaU2h4CGHd2Em3v5LLMsEh8dqUeG9yIcCU+8RUgDahNxWMe MGxzrhwk8WBV6xeoQp20p7cSHbSbyHJURC1n+nVrgdh8hbw6WOgFhNA5tCPDZ0oSF+uHfj+b ioZE3AlYdcEqHJA9A9sO58F4/Qg/yp9oYuT0ZpKb4hmzeqDXvk5KRFNfHlhTt35i+qmas9wB 11MXbYd5WwqEhZH6HWO5H7XKJP7olxmEC0W3OKlpKafq1iPsBN5ycRfUrXFss0Ax6vpCq0XA 3LYePpQ44hOU+qrkR1M0a7Eo3++3TpP4cV+FZiO4aZYZ3yZftSRHwWpGiDBdWOdTKR2GJi7Z z/OxacrmwmM1Z+WcigldbG8f3IMnOLK4X0uXjhVeAHrhuttQuM8i+4TNXgsZbmfEKNDQIQPO /lbacsGHWFB/U2y6SXVEkZs2xIciRA0iZNTv7mbIL8SZmf5wpbjDCYHiCjGCAzgwggM0AgEB MFowRzELMAkGA1UEBhMCU0UxFDASBgNVBAoMC1RlbGlhU29uZXJhMSIwIAYDVQQDDBlUZWxp YVNvbmVyYSBDbGFzcyAyIENBIHYyAg8BaKlzCTJTye3phLaz/cIwDQYJYIZIAWUDBAIBBQCg ggGvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE5MDgyNzA2 NTIyM1owLwYJKoZIhvcNAQkEMSIEIKuzPYzj5/mtbsVdP8FuAhYvzGI62gqDWmAcqFjdqoSW MGkGCSsGAQQBgjcQBDFcMFowRzELMAkGA1UEBhMCU0UxFDASBgNVBAoMC1RlbGlhU29uZXJh MSIwIAYDVQQDDBlUZWxpYVNvbmVyYSBDbGFzcyAyIENBIHYyAg8BaKlzCTJTye3phLaz/cIw awYLKoZIhvcNAQkQAgsxXKBaMEcxCzAJBgNVBAYTAlNFMRQwEgYDVQQKDAtUZWxpYVNvbmVy YTEiMCAGA1UEAwwZVGVsaWFTb25lcmEgQ2xhc3MgMiBDQSB2MgIPAWipcwkyU8nt6YS2s/3C MGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0D BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwIC ASgwDQYJKoZIhvcNAQEBBQAEggEAdroH6TULS53cKo6o/jKJ4VWwpIg7Z7E1GGLmPBsxKnz2 Q+PCqO3o0RzPy56PMsaMaldXeia1edw7bpIey2UQp/wa5FDJPmc044FpkkCSMI+j1AhstvLb IJ7O+XzXNCiK1/bpxoRZhGQDErQMbOdrcyYCHJ/HDCXUQH8xcpPVua+e0m9rX6Vd8WMWMIz5 AVib2PD3ag1cS4GkJgcXloK3dYiOxaE6sTGv9/ls7KotTzOsMDjx7jbsGdxZ6TloFIgEuXMV lqL31xfywQVk4bEhAquzgOLehUc15UNIHMq0cSEWnfnSY5jxCf/okcRzw2cPjZ+WmvOLzfkB xiExb3KHEQAAAAAAAA== --------------ms040102000403000107040704-- From nobody Wed Aug 28 16:36:57 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16A5B120130; Wed, 28 Aug 2019 16:36:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 40GVs-4Jf7oG; Wed, 28 Aug 2019 16:36:51 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CBD712011A; Wed, 28 Aug 2019 16:36:47 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x7SNaf1r025061 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 28 Aug 2019 19:36:45 -0400 Date: Wed, 28 Aug 2019 18:36:40 -0500 From: Benjamin Kaduk To: draft-ietf-ace-coap-est.all@ietf.org Cc: ace@ietf.org Message-ID: <20190828233639.GI84368@kduck.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: [Ace] AD review of draft-ietf-ace-coap-est-12 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2019 23:36:55 -0000 Hi all, A good number of comments here, though many are just nits. We may need some more in-depth discussion about only using certificates for client authentication (immediately below) and how we discuss server-keygen. Thanks, Ben %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Section 2 This document also profiles the use of EST to only support certificate-based client authentication. HTTP Basic or Digest authentication (as described in Section 3.2.3 of [RFC7030]) are not supported. Is the intent just to exclude HTTP-layer authentication, or to specifically prefer client certificate authentication? 7030 does allow for non-certificate TLS-layer authentication (e.g., TLS-SRP), which would be compatible with DTLS just fine. There's also recurrent talk of getting modern PAKE(s) integrated with TLS, which might also be an option in the constrained space. [There are subsequent parts of the document that continue to assume only-certificates, so I'm mostly assuming that the intent is specifically to prefer client certificates, and have not made specific notes at those other places in the document.] Section 4 As per sections 3.3 and 4.4 of [RFC7925], the mandatory cipher suite nit: I do see RFC 7925 in the subject heading, but the lead-in here is still a bit jarring. Without some statement in this document to that effect, RFC 7925 is not binding on the protocol specified in this document, so I think it's better to say something like "In accordance with", or even to flat out state that "this document conforms to the DTLS 1.2 profile specified in RFC 7925". DTLS 1.2 implementations must use the Supported Elliptic Curves and Supported Point Formats Extensions in [RFC8422]. Uncompressed point format must also be supported. DTLS 1.3 [I-D.ietf-tls-dtls13] implementations differ from DTLS 1.2 because they do not support point format negotiation in favor of a single point format for each curve. Thus, support for DTLS 1.3 does not mandate point format extensions and negotiation. DTLS 1.3 uses the "supported_groups" extension in contrast to Supported Elliptic Curves for 1.2; we should mention that disparity as well. o a previously issued client certificate (e.g., an existing certificate issued by the EST CA); this could be a common case for simple re-enrollment of clients. Is "re-enrollment" intended to cover renewal operations? o a previously installed certificate (e.g., manufacturer IDevID [ieee802.1ar] or a certificate issued by some other party); the server is expected to trust that certificate. IDevID's are "trust" can cover a lot of things, many of which we don't really need here; would "expected to be able to validate" suffice? As described in Section 2.1 of [RFC5272] proof-of-identity refers to a value that can be used to prove that the private key corresponding to the public key is in the possession of and can be used by an end- entity or client. Additionally, channel-binding information can link nit: "the certified public key", I think, since the certificate is what binds the identity to the public key. Also, this sentence is a bit awkward, though I don't have any concrete rewording suggestions at present. When proof-of-possession is desired, a set of actions are required regarding the use of tls-unique, described in Section 3.5 in [RFC7030]. The tls-unique information consists of the contents of I see the note in the shepherd writeup about converting EST to use TLS exporters rather than tls-unique in a separate update document. Where is that work happening? The discussion in Section 10.1 is helpful (and we could do well to reference it from here) but does not inspire great confidence in the reader that such work will come to fruition. I think we also need to at least mandate extended-master-secret to be used on the underlying DTLS connection. (That is, assuming that we don't want to lock down to specific, non-vulnerable, ciphersuites -- RFC 7925 only has TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 as MTI, not MTU.) Given that after a successful enrollment, it is more likely that a new EST transaction will take place after a significant amount of time, the DTLS connections SHOULD only be kept alive for EST messages that are relatively close to each other. In some cases, like NAT rebinding, keeping the state of a connection is not possible when devices sleep for extended periods of time. In such occasions, [I-D.ietf-tls-dtls-connection-id] negotiates a connection ID that can eliminate the need for new handshake and its additional cost. Do we also want to mention DTLS 1.3 session resumption here as less expensive than a full handshake? It's not as cheap as "just keep using the same connection ID", of course, but has somewhat different other properties. Section 5 o Simple enroll and re-enroll for a CA to sign public client identity key. nit(?): is this "public client identity key" or "client identity public key" or something else? o Certificate Signing Request (CSR) attribute messages that inform the client of the fields to include in a CSR. nit: "informs" o Server-side key generation messages to provide a private client identity key when the client choses so. (similar nit(?) as above) Section 5.1 With the current text, I expect us to get several IESG questions about "why do you have both discovery and well-known URIs?". I think we need to treat this more prominently in the first few paragraphs of the section, perhaps just after we discuss the short-est strings, so we could tie into the constrained nature of things and how some devices may need to hardcode assumptions about the endpoint location. Figure 5 in Section 3.2.2 of [RFC7030] enumerates the operations and corresponding paths which are supported by EST. Table 1 provides the mapping from the EST URI path to the shorter EST-coaps URI path. Our table has the entries in a different order than 7030's table. We also don't say anything about the (lack of the) fullcmc endpoint. The serverkeygen endpoints could perhaps have some notation to indicate that the private key is always returned, in addition to the PKCS#7 vs. pkix-cert question that distinguishes skg and skc. The /skg message is the EST /serverkeygen equivalent where the client requests for a certificate in PKCS#7 format and a private key. If nit: s/requests for a/requests a/ Clients and servers MUST support the short resource EST-coaps URIs. Are they expected to also support the long EST URIs over CoAP? In the context of CoAP, the presence and location of (path to) the EST resources are discovered by sending a GET request to "/.well- known/core" including a resource type (RT) parameter with the value "ace.est*" [RFC6690]. The example below shows the discovery over Is that a literal asterisk, for ace dot est star? (1) Why? (2) It probably merits a mention in the text to confirm it for the reader. It's a little unfortunate that we can only indicate ct=62 for the last two, and there's no way to indicate what content types we expect within that container. The first three lines of the discovery response above MUST be returned if the server supports resource discovery. The last three It may be worth listing out ace.est.crts, ace.est.sen, and ace.est.sren explicitly for clarity (especially since line breaks are "only for readability") lines are only included if the corresponding EST functions are implemented. The Content-Formats in the response allow the client to request one that is supported by the server. These are the values that would be sent in the client request with an Accept option. It seems that these specific values (or a subset thereof) are mandatory; a forward reference might be in order. Section 5.2 Did we consider merging this table with Table 1? Section 5.2 While [RFC7030] permits a number of these functions to be used without authentication, this specification requires that the client MUST be authenticated for all functions. Perhaps this divergence from 7030 should be noted more prominently, perhaps in the section title or a dedicated "Differences from RFC 7030" section? Section 5.3 EST-coaps is designed for low-resource devices and hence does not need to send Base64-encoded data. Simple binary is more efficient (30% smaller payload) and well supported by CoAP. Thus, the payload for a given Media-Type follows the ASN.1 structure of the Media-Type and is transported in binary format. This last sentence is only true when scoped to this document, for which all the content we're handling is specified using ASN.1. I don't know whether we want to tweak the wording to reflect that or not, though. Also, we probably should say DER-encoded ASN.1 structure (or BER? I'd have to check what the requirements are) since ASN.1 is just the abstract syntax and not the encoding rules. When the client makes an /skc request the certificate returned with the private key is a single X.509 certificate (not a PKCS#7 container) with Content-Format identifier TBD287 (0x011F) instead of 281. In cases where the private key is encrypted with CMS (as explained in Section 5.8) the Content-Format identifier is 280 (0x0118) instead of 284. The key and certificate representations are ASN.1 encoded in binary format. An example is shown in Appendix A.3. I think these relationships might be more clear in tabular form; I dind't really understand the scheme at this point in the document, and needed to get a ways further in before it really "clicked". Section 5.4 o EST-coaps servers sometimes need to provide delayed responses which are conveyed with an empty ACK or an ACK containing response code 5.03 as explained in Section 5.7. Thus, it is RECOMMENDED nit: the response itself (delayed or not) is not in the ACK, so maybe "the need for which is conveyed". Section 5.6 layer. In addition, invokers residing on a 6LoWPAN over IEEE 802.15.4 [ieee802.15.4] network should attempt to size CoAP messages such that each DTLS record will fit within one or two IEEE 802.15.4 frames. Is this intended to be a normative SHOULD? If not, it feels like we need a reference or justification. Section 5.7 certificate to the client after a short delay. If the certificate response is large, the server will need more than one Block2 blocks to transfer it. nit: "Block2 block" singular POST [2001:db8::2:1]:61616/est/sen (CON)(1:0/1/256) {CSR (frag# 1)} --> <-- (ACK) (1:0/1/256) (2.31 Continue) Where is this notation documented? (Is Appendix B.1 of this document the first place it's introduced?) We need some kind of reference on first usage. If the server is very slow (i.e. minutes) in providing the response (i.e. when a manual intervention is needed), he SHOULD respond with nit: RFC style puts commas after (and before) "i.e." and "e.g.". the identical CSR to the server. As long as the server responds with response code 5.03 (Service Unavailable) with a Max-Age Option, the client SHOULD keep resending the enrollment request until the server responds with the certificate or the client abandons for other reasons. nit: the transitive verb "abandons" has no direct object response. Note that the server asks for a decrease in the block size when acknowledging the first Block2. nit: From the trace, it looks like the server is the first one to use a 128-byte block size, and it does happen in an ack message, but that ack is not acking a block2 (though it contains one). (That ack message also happens to contain part of the response.) POST [2001:db8::2:1]:61616/est/sen(CON)(1:N1/0/256){CSR (frag# 1)}--> <-- (ACK) (1:0/1/256) (2.31 Continue) POST [2001:db8::2:1]:61616/est/sen (CON)(1:1/1/256) {CSR (frag# 2)} --> <-- (ACK) (1:1/1/256) (2.31 Continue) The first line doesn't seem to match up -- doesn't the "N1" mean "fragment N1+1" but the descriptive text at the end say "frag# 1"? Or is this supposed to be 1:0/1/256? Also, it surprised me somewhat that the client has to re-send the whole request (i.e., all fragments thereof) after the Max-Age interval when the server says it's ready, since that feels wasteful of bandwidth, but I assume that's just how CoAP works and not relevant for this document. Section 5.8 In scenarios where it is desirable that the server generates the private key, server-side key generation should be used. Such nit: suggest s/should be used/is available/ to avoid the appearance of tautology. scenarios could be when it is considered more secure to generate at the server the long-lived random private key that identifies the client, or when the resources spent to generate a random private key at the client are considered scarce, or when the security policy requires that the certificate public and corresponding private keys are centrally generated and controlled. Of course, that does not I can (grudgingly) accept that people are going to do server-side key generation, so I do not propose to remove it from the document. The policy case is a clear example of why the feature needs to be available, but I'm not 100% sure that I believe that server-keygen could be "more secure" given that the client needs to be able to produce secure random numbers for DTLS (though I do accept that some people will believe it to be so!). It seems likely to only be possible in some intermediate situation where the client-generated random numbers could be attacked but at substantial expense, such that paying that expense for a single handshake is "too much" for the attacker to bear, but doing it for the key generation that would give the attacker all transactions would make the expense worthwhile; this intermediate situation seems to also be transitory, since attacks only get better/cheaper. For the other case, if we were doing RSA keygen, then going from random numbers to prime generation could be enough incremental expense that offloading to the server would make sense, but I didn't think the elliptic curve stuff had the same kind of issues, so I'd like to hear more about the resource-consumption aspect as well. When requesting server-side key generation, the client asks for the server or proxy to generate the private key and the certificate which are transferred back to the client in the server-side key generation response. In all respects, the server SHOULD treat the CSR as it would treat any enroll or re-enroll CSR; the only distinction here is that the server MUST ignore the public key values and signature in the CSR. These are included in the request only to allow re-use of existing codebases for generating and parsing such requests. We need to reword this; the SHOULD is in conflict with the MUST. certificate and a private key. The private key Content-Format requested by the client is depicted in the PKCS#10 CSR request. If nit: I suggest s/depicted/indicated/ (Section 5.3) . The two representations (each consisting of two CBOR array items) do not have to be in a particular order since each [side note: core-multipart-ct is looking to land on "multipart/mixed" semantics to resolve my outstanding Discuss point; RFC 2046 is pretty clear about the component parts "need[ing] to be in a particular order", which this is in conflict with] representation is preceded by its Content-Format ID. The private key can be in unprotected PKCS#8 [RFC5958] format (Content-Format 284) or protected inside of CMS SignedData (Content-Format 280). The Phrasing it like this makes it soun like the server can just spontaneously decide that it wants to sign the key content, as opposed to having it be dependant on the CSR's contents. Also... SignedData is signed by the party that generated the private key, which may be the EST server or the EST CA. The SignedData is further protected by placing it inside of a CMS EnvelopedData as explained in Section 4.4.2 of [RFC7030]. In summary, the symmetrically encrypted ... if the SignedData is not the outermost container, then we don't care what the relevant Content-Format for it is; we only care about the Content-Format for the EnvelopedData. Also, did we explicitly consider and reject AuthEnvelopedData? key is included in the encryptedKey attribute in a KEKRecipientInfo structure. In the case where the asymmetric encryption key is suitable for transport key operations the generated private key is encrypted with a symmetric key which is encrypted by the client defined (in the CSR) asymmetric public key and is carried in an nit: hyphenate "client-defined" encryptedKey attribute in a KeyTransRecipientInfo structure. Finally, if the asymmetric encryption key is suitable for key agreement, the generated private key is encrypted with a symmetric key which is encrypted by the client defined (in the CSR) asymmetric In the key-agreement case, the symmetric key-encryption key is the result of the key-agreement operation, no? In which case it is not itself encrypted, but rather the server's ephemeral public value is sent. public key and is carried in an recipientEncryptedKeys attribute in a KeyAgreeRecipientInfo. [RFC7030] recommends the use of additional encryption of the returned private key. For the context of this specification, clients and servers that choose to support server-side key generation MUST support unprotected (PKCS#8) private keys (Content-Format 284). Symmetric or asymmetric encryption of the private key (CMS EnvelopedData, Content-Format 280) SHOULD be supported for deployments where end-to-end encryption needs to be provided between the client and a server. Such cases could include architectures where an entity between the client and the CA terminates the DTLS connection (Registrar in Figure 4). This carefully says nothing about recommendations for use, only for software support. Are we letting 7030's recommendation for use of encryption stand? It's probably worth being explicit, either way. Section 6 The EST-coaps-to-HTTPS Registrar MUST terminate EST-coaps downstream and initiate EST connections over TLS upstream. The Registrar MUST authenticate and OPTIONALLY authorize the clients and it MUST be Why OPTIONAL? (Also, nit: OPTIONALLY isn't a 2119 keyword; only OPTIONAL.) client. For example, it could be configured to accept POP linking information that does not match the current TLS session because the authenticated EST client Registrar has verified this information when acting as an EST server. This is close enough to a literal quote that we might think about actually quoting and using quotation marks. nit: s/POP/PoP/ if we don't do the literal quote. For some use cases, clients that leverage server-side key generation might prefer for the enrolled keys to be generated by the Registrar if the CA does not support server-side key generation. Such Registrar is responsible for generating a new CSR signed by a new key which will be returned to the client along with the certificate from nit: "Such a Registrar" the CA. In these cases, the Registrar MUST support random number generation using proper entropy. Not just support -- use! Additionally, a conversion from CBOR major type 2 to Base64 encoding MUST take place at the Registrar when server-side key generation is supported. [...] Not always? key, the encrypted CMS EnvelopedData blob MUST be converted to binary in CBOR type 2 downstream to the client. I think we should reword this -- my first reading of "downstream to the client" is "after the client in the processing path", which doesn't actually help the client. Presumably we mean at the registrar, in the downstream direction, towards the client. The EST-coaps-to-HTTP Registrar MUST support resource discovery according to the rules in Section 5.1. Section 5.1. Do we need to say anything about translation of discovered URIs? Section 7 This section addresses transmission parameters described in sections 4.7 and 4.8 of [RFC7252]. EST does not impose any unique values on the CoAP parameters in [RFC7252], but the EST parameter values need to be tuned to the CoAP parameter values. I don't understand what "but the EST parameter values need to be tuned to the CoAP parameter values" means. It is recommended, based on experiments, to follow the default CoAP configuration parameters ([RFC7252]). However, depending on the implementation scenario, retransmissions and timeouts can also occur on other networking layers, governed by other configuration parameters. A change in a server parameter MUST ensure the adjusted value is also available to all the endpoints with which these adjusted values are to be used to communicate. I don't understand who this is a normative requirement upon. Is it the network operator's, to propagate configuration changes? Or is there supposed to be some automated protocol that makes adjusted values available? o NSTART: A parameter that controls the number of simultaneous outstanding interactions that a client maintains to a given server. An EST-coaps client is not expected to interact with more than one servers at the same time, which is the default NSTART value defined in [RFC7252]. nit: there's a mismatch between "to a given server" and "more than one servers at the same time". (Also, s/one servers/one server/.) o PROBING_RATE: A parameter which specifies the rate of re-sending non-confirmable messages. The EST messages are defined to be sent as CoAP confirmable messages, hence this setting is not applicable. Section 5.4 only has it as RECOMMENDED to send requests in CON messages, so we should still say something here. Section 9.1 I think we probably need this document as a reference for all the allocations; as the document effectuating the registration, we are still of interest even if most details of content encoding lie elsewhere. Section 9.2 The grammar for these entries is a bit stilted, though the existing registrations are not so far off. nit: should ace.est.att include the word "get" like ace.est.crts does? Section 10.1 The security considerations of Section 6 of [RFC7030] are only partially valid for the purposes of this document. As HTTP Basic Authentication is not supported, the considerations expressed for using passwords do not apply. It may be worth explicitly stating that "the other portions of the security considerations of RFC 7030 continue to apply". Modern security protocols require random numbers to be available during the protocol run, for example for nonces, ephemeral (EC) Diffie-Hellman key generation. This capability to generate random nit: the comma expects a 3+ element list but we only have two elements. Just "and" suffices? Analysis SHOULD be done to establish whether server-side key generation increases or decreases the probability of digital identity theft. In the abstract sense, this seems like a non-normative "should". But if we make it apply specifically to those deploying server-side key generation then it is appropriately normative. It is important to note that sources contributing to the randomness pool used to generate random numbers on laptops or desktop PCs are not available on many constrained devices, such as mouse movement, timing of keystrokes, air turbulence on the movement of hard drive heads, as pointed out in [PsQs]. Other sources have to be used or nit: need an "and" (or "or") to close the list. It is also RECOMMENDED that the Implicit Trust Anchor database used for EST server authentication is carefully managed to reduce the chance of a third-party CA with poor certification practices jeopardizing authentication. Disabling the Implicit Trust Anchor We may want to call out that since the implicit database is used for the initial /crts request, that single jeporadized exchange could cause all subsequent exchanges from that client to be compromised as well. database after successfully receiving the Distribution of CA certificates response (Section 4.1.3 of [RFC7030]) limits any risk to the first DTLS exchange. Alternatively, in a case where a /sen request immediately follows a /crts, a client MAY choose to keep the connection authenticated by the Implicit TA open for efficiency reasons (Section 4). A client that pipelines EST-coaps /crts request nit: is "pipelines" the right word here, given that HTTP pipelining is a thing and CoAP pipelining (probably?) isn't, and the former isn't what we're doing anyway? with other requests in the same DTLS connection SHOULD revalidate the server certificate chain against the updated Explicit TA from the /crts response before proceeding with the subsequent requests. If the server certificate chain does not authenticate against the database, the client SHOULD close the connection without completing the rest of the requests. The updated Explicit TA MUST continue to be used in new DTLS connections. I'm not going to say you shouldn't do this check, but it seems pretty easy for an attacker that knows it's servicing a /crts request to supply a response that includes a (potentially bogus) trust anchor that can certify the certificate it used for the current connection. So it's not clear how much protection this really provides. As described in CMC, Section 6.7 of [RFC5272], "For keys that can be used as signature keys, signing the certification request with the private key serves as a POP on that key pair". The inclusion of tls- unique in the certificate request links the proof-of-possession to the TLS proof-of-identity. This implies but does not prove that only the authenticated client currently has access to the private key. Do we want to further clarify that this means the PoP is weaker than it could be? ("no" is a fine answer, as always.) What's more, POP linking uses tls-unique as it is defined in [RFC5929]. The 3SHAKE attack [tripleshake] poses a risk by allowing nit: "such POP linking" or "the CMC POP linking" a man-in-the-middle to leverage session resumption and renegotiation to inject himself between a client and server even when channel binding is in use. The attack was possible because of certain (D)TLS implementation imperfections. In the context of this specification, I don't think we can solely blame the attacks on implementation imperfections (though they were certainly compounding factors). Does this sentence really add any value to the current document? binding mechanism. Such a mechanism could include an updated tls- unique value generation like the tls-unique-prf defined in [I-D.josefsson-sasl-tls-cb] by using a TLS exporter [RFC5705] in TLS 1.2 or TLS 1.3's updated exporter (Section 7.5 of [RFC8446]). Such mechanism has not been standardized yet. Adopting a channel binding We probably should be explicit about "using a TLS Exporter value in place of the tls-unique value in the CSR", just from a writing clarity perspective. It might be worth splitting the triple-handshake bits (including open question) into a separate subsection so that we can make a forward reference to it from earlier in the document. value generated from an exporter would break backwards compatibility. Thus, in this specification we still depend on the tls-unique mechanism defined in [RFC5929], especially since a 3SHAKE attack does not expose messages exchanged with EST-coaps. I suppose that new endpoint names would be one way to work through the backwards-compatibility break, though it's not entirely clear that we need to say so in this document. We probably do want to say that even though EST-coaps looks like a new protocol that could get away with changing the default, we want to preserve the ability for the RA to proxy through to a "classic" EST HTTPS server, so we are in fact constrained to use the compatible choice. Regarding the Certificate Signing Request (CSR), an EST-coaps server is expected to be able to recover from improper CSR requests. What does "recover" mean? Is it just "not crash" or is it expected to somehow still be able to issue a certificate? (If the former, that might be implicit in an RFC 3552 threat model, though saying it explicitly probably doesn't hurt.) Section 10.2 The Registrar proposed in Section 6 must be deployed with care, and only when the recommended connections are impossible. When POP Do we actually explicitly say that the direct connection is recommended anywhere? If not, we should. linking is used the Registrar terminating the TLS connection establishes a new one with the upstream CA. Thus, it is impossible I think technically it terminates DTLS and esablishes a new TLS connection. for POP linking to be enforced end-to-end for the EST transaction. The EST server could be configured to accept POP linking information that does not match the current TLS session because the authenticated EST Registrar client has verified this information when acting as an EST server. I think we need to say that the EST server "assumes" or "trusts" that the registrar has verified this information -- it is to some extent a leap of faith. The introduction of an EST-coaps-to-HTTP Registrar assumes the client can trust the registrar using its implicit or explicit TA database. I'm not entirely sold on "trust" as the best word here (vs., e.g., validate), but don't object to it. It also assumes the Registrar has a trust relationship with the upstream EST server in order to act on behalf of the clients. When a client uses the Implicit TA database for certificate validation, she SHOULD confirm if the server is acting as an RA by the presence of the id-kp-cmcRA EKU [RFC6402] in the server certificate. Why is this only a SHOULD? generating the key. In such cases, the existence of a Registrar requires the client to put its trust on the registrar doing the right thing if it is generating the private key. This is true, though it (probably correctly, for our purposes) does not give any indication of what "the right thing" is intended to be :) Section 11.2 I think draft-ietf-lamps-rfc5751-bis, RFC 5958, RFC 8075, and RFC 8422 should be normative references. If we're going to say that this spec requires conformance to RFC 7925's DTLS profile (which we currently don't, but I suggest above that we do), it will need to be a normative reference as well. I don't understand why RFC 7231 is in the 'reference' column for application/csrattrs in Table 4; its presence there would normally suggest that it should be a normative reference. RFC 5929 is interesting, as it is of course a normative reference for RFC 7030, which we use normatively, but we may not need to cite it directly as a normative reference from this document. It may be worth citing RFC 7525 as BCP 195 where it appears. Appendix A transported in hex, but in binary. The payloads are shown unencrypted. In practice the message content would be transferred over an encrypted DTLS tunnel. I expect a tsvart reviewer to complain about the use of the word "tunnel" here, and suggest "channel" as an alternative. The certificate responses included in the examples contain Content- Format 281 (application/pkcs7). If the client had requested Content- Format TBD287 (application/pkix-cert) by querying /est/skc, the server would respond with a single DER binary certificate. Just to check my own understanding: this will always appear within a multipart-core container, right? Appendix A.1 Option (Uri-Port) Option Delta = 0x4 (option# 3+4=7) Option Length = 0x4 Option Value = 9085 Option (Uri-Path) Option Delta = 0x4 (option# 7+4=11) Option Length = 0x5 Option Value = "est" This is more for my own edification than the document's sake, so thank you for your time, but what accounts for the "extra" length here? The "est" is three bytes, and what makes up for the other two? Also, I assume that the port value of 9805 is the decimal value, which gets CBOR encoded into two bytes of integer encoding plus the byte with additional information 25 to indicate the two-byte integer, and another byte that I need help accounting for. Appendix A.2 Do we want to say anything about the IDevID in the CSR/cert? I note that the breakdown in Appendix C.2 (looks like openssl output) does not decode the otherName (though asn1parse can be convinced to do so). Appendix A.3 I'm having trouble validating the private key in the PKCS#8 component: asn1parse says: $ unhex|openssl asn1parse -inform der 308187020100301306072a8648ce3d020106082a8648ce3d030107046d30 6b02010104200b9a67785b65e07360b6d28cfc1d3f3925c0755799deeca7 45372b01697bd8a6a144034200041bb8c1117896f98e4506c03d70efbe82 0d8e38ea97e9d65d52c8460c5852c51dd89a61370a2843760fc859799d78 cd33f3c1846e304f1717f8123f1a284cc99f 0:d=0 hl=3 l= 135 cons: SEQUENCE 3:d=1 hl=2 l= 1 prim: INTEGER :00 6:d=1 hl=2 l= 19 cons: SEQUENCE 8:d=2 hl=2 l= 7 prim: OBJECT :id-ecPublicKey 17:d=2 hl=2 l= 8 prim: OBJECT :prime256v1 27:d=1 hl=2 l= 109 prim: OCTET STRING [HEX DUMP]:306B02010104200B9A67785B65E07360B6D28CFC1D3F3925C0755799DEECA745372B01697BD8A6A144034200041BB8C1117896F98E4506C03D70EFBE820D8E38EA97E9D65D52C8460C5852C51DD89A61370A2843760FC859799D78CD33F3C1846E304F1717F8123F1A284CC99F which doesn't look like an RFC5208 PrivateKeyInfo: PrivateKeyInfo ::= SEQUENCE { version Version, privateKeyAlgorithm PrivateKeyAlgorithmIdentifier, privateKey PrivateKey, attributes [0] IMPLICIT Attributes OPTIONAL } Version ::= INTEGER PrivateKeyAlgorithmIdentifier ::= AlgorithmIdentifier PrivateKey ::= OCTET STRING Attributes ::= SET OF Attribute due to the lack of OID for privateKeyAlgorithm, etc. (`openssl pkcs8` also chokes on it, but I don't have a working example and can't rule out user error there.) Even that giant OCTET STRING 27 bytes in doesn't seem to match a PrivateKeyInfo: $ unhex|openssl asn1parse -inform der -strparse 27 308187020100301306072a8648ce3d020106082a8648ce3d030107046d30 6b02010104200b9a67785b65e07360b6d28cfc1d3f3925c0755799deeca7 45372b01697bd8a6a144034200041bb8c1117896f98e4506c03d70efbe82 0d8e38ea97e9d65d52c8460c5852c51dd89a61370a2843760fc859799d78 cd33f3c1846e304f1717f8123f1a284cc99f 0:d=0 hl=2 l= 107 cons: SEQUENCE 2:d=1 hl=2 l= 1 prim: INTEGER :01 5:d=1 hl=2 l= 32 prim: OCTET STRING [HEX DUMP]:0B9A67785B65E07360B6D28CFC1D3F3925C0755799DEECA745372B01697BD8A6 39:d=1 hl=2 l= 68 cons: cont [ 1 ] 41:d=2 hl=2 l= 66 prim: BIT STRING though the OCTET STRING does have the private key and the BIT STRING has the public key's contents as depicted in C.3 (details of that too boring to show). So I have to wonder if I'm messing something up, somewhere. Section A.4 I'm not sure how useful repeating the RFC 7030 csrattrs is: do we expect (e.g.) brainpoolP384r1 to be relevant for our readers? Appendix B.1 and BLOCK option Block2. The minimum PMTU is 1280 bytes, which is the example value assumed for the DTLS datagram size. The example I'm not seeing how this relates to the rest of the section. The CoAP message adds around 10 bytes, the DTLS record 29 bytes. To avoid IP fragmentation, the CoAP Block The DTLS overhead can also vary based on cipher suite, padding, etc., so a bit more qualification ("we assume", "around", etc.) might be in order. tenth packet of 63 bytes. The client sends an IPv6 packet containing the UDP datagram with the DTLS record that encapsulates the CoAP request 10 times. The server returns an IPv6 packet containing the UDP datagram with the DTLS record that encapsulates the CoAP response. The CoAP request-response exchange with block option is The definite vs. indefinite articles here don't seem quite right, and each of the 10 datagrams do not encapsulate the entire CoAP request. with exponent (2**(SZX+4)) separated by slashes. The Length 64 is used with SZX=2 to avoid IP fragmentation. The CoAP Request is sent We just said "to avoid IP fragmentation" ten lines ago. Should we be using the same Token value in two different exchanges in this document? Appendix B.2 In this example, the requested Block2 size of 256 bytes, required by the client, is transferred to the server in the very first request message. The block size 256=(2**(SZX+4)) which gives SZX=4. The I don't see a Block2 size in the first request message, just Block1: POST [2001:db8::2:321]:61616/est/sen (CON)(1:0/1/256) {CSR req} --> <-- (ACK) (1:0/1/256) (2.31 Continue) Also, we seem to have stopped using the "{CSR req frag#2}" notation that we had in the main body text. Appendix C.2 [I mentioned otherName's non-decoding earlier] Appendix C.3 I find it kind of amusing that we have a "Netscape Comment" in the generated cert :) From nobody Thu Aug 29 16:15:20 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06FD7120129; Thu, 29 Aug 2019 16:15:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1EKuJ6kSaaB9; Thu, 29 Aug 2019 16:15:15 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 622261200D6; Thu, 29 Aug 2019 16:15:14 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 29 Aug 2019 16:15:07 -0700 From: Jim Schaad To: 'Benjamin Kaduk' , CC: References: <20190828233639.GI84368@kduck.mit.edu> In-Reply-To: <20190828233639.GI84368@kduck.mit.edu> Date: Thu, 29 Aug 2019 16:15:05 -0700 Message-ID: <027701d55ebf$994184b0$cbc48e10$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQIXV+tDlosvqNImECv+N/+Ud7Gh26aOxDBw Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Ace] AD review of draft-ietf-ace-coap-est-12 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Aug 2019 23:15:18 -0000 A couple of answers from my own perspective -----Original Message----- From: Ace On Behalf Of Benjamin Kaduk Sent: Wednesday, August 28, 2019 4:37 PM To: draft-ietf-ace-coap-est.all@ietf.org Cc: ace@ietf.org Subject: [Ace] AD review of draft-ietf-ace-coap-est-12 Hi all, A good number of comments here, though many are just nits. We may need some more in-depth discussion about only using certificates for client authentication (immediately below) and how we discuss server-keygen. Thanks, Ben %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% When proof-of-possession is desired, a set of actions are required regarding the use of tls-unique, described in Section 3.5 in [RFC7030]. The tls-unique information consists of the contents of I see the note in the shepherd writeup about converting EST to use TLS exporters rather than tls-unique in a separate update document. Where is that work happening? The discussion in Section 10.1 is helpful (and we could do well to reference it from here) but does not inspire great confidence in the reader that such work will come to fruition. I think we also need to at least mandate extended-master-secret to be used on the underlying DTLS connection. (That is, assuming that we don't want to lock down to specific, non-vulnerable, ciphersuites -- RFC 7925 only has TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 as MTI, not MTU.) [JLS] If this work is going to happen it needs to be done as an update to the EST RFC. I don't know if it would be better to do that in LAMPS rather than here. Currently I do not know of anybody who is going to do this. This is my issue and I am willing to let it slide for the time being. In the context of CoAP, the presence and location of (path to) the EST resources are discovered by sending a GET request to "/.well- known/core" including a resource type (RT) parameter with the value "ace.est*" [RFC6690]. The example below shows the discovery over Is that a literal asterisk, for ace dot est star? (1) Why? (2) It probably merits a mention in the text to confirm it for the reader. [JLS] This is standard CoAP searching with the "rt" parameter. The start is a) literal and b) means a wild chard with the expected meaning. I don't think that this needs any additional text. It's a little unfortunate that we can only indicate ct=62 for the last two, and there's no way to indicate what content types we expect within that container. [JLS] This was a big topic of discussion both in ace and more importantly in core for the multipart content type. If this is solved it should be solved in CoRE and not here. (I recognize from the text that you don't expect it to be solved in this document.) I can (grudgingly) accept that people are going to do server-side key generation, so I do not propose to remove it from the document. The policy case is a clear example of why the feature needs to be available, but I'm not 100% sure that I believe that server-keygen could be "more secure" given that the client needs to be able to produce secure random numbers for DTLS (though I do accept that some people will believe it to be so!). It seems likely to only be possible in some intermediate situation where the client-generated random numbers could be attacked but at substantial expense, such that paying that expense for a single handshake is "too much" for the attacker to bear, but doing it for the key generation that would give the attacker all transactions would make the expense worthwhile; this intermediate situation seems to also be transitory, since attacks only get better/cheaper. For the other case, if we were doing RSA keygen, then going from random numbers to prime generation could be enough incremental expense that offloading to the server would make sense, but I didn't think the elliptic curve stuff had the same kind of issues, so I'd like to hear more about the resource-consumption aspect as well. [JLS] I would disagree that there is any requirement for a client using DTLS to have any type of secure random numbers to still get a secure channel. If you do PSK authentication, then it is not required. The "random numbers" in the protocol are not really random, this is really true because they are public numbers, you would like them to be non-predictable but I do not know that this is even a requirement. The only question is how much you want to avoid some type of static-ephemeral key agreement state which looses the PFS but is still potentially not horrid to have. with other requests in the same DTLS connection SHOULD revalidate the server certificate chain against the updated Explicit TA from the /crts response before proceeding with the subsequent requests. If the server certificate chain does not authenticate against the database, the client SHOULD close the connection without completing the rest of the requests. The updated Explicit TA MUST continue to be used in new DTLS connections. I'm not going to say you shouldn't do this check, but it seems pretty easy for an attacker that knows it's servicing a /crts request to supply a response that includes a (potentially bogus) trust anchor that can certify the certificate it used for the current connection. So it's not clear how much protection this really provides. [JLS] Right, of course the attacker that is going to do this needs to have gotten a trusted channel set up initially to provide that (potentially bogus) trust anchor over. If you can do that then there is no longer any trust in the system at all. As described in CMC, Section 6.7 of [RFC5272], "For keys that can be used as signature keys, signing the certification request with the private key serves as a POP on that key pair". The inclusion of tls- unique in the certificate request links the proof-of-possession to the TLS proof-of-identity. This implies but does not prove that only the authenticated client currently has access to the private key. Do we want to further clarify that this means the PoP is weaker than it could be? ("no" is a fine answer, as always.) [JLS] My response would be no. I have spent hours describing the issues that arise here without it always being clear that I have succeeded. Trying to do this in text and get the corner cases well described is extremely difficult. It also assumes the Registrar has a trust relationship with the upstream EST server in order to act on behalf of the clients. When a client uses the Implicit TA database for certificate validation, she SHOULD confirm if the server is acting as an RA by the presence of the id-kp-cmcRA EKU [RFC6402] in the server certificate. Why is this only a SHOULD? [JLS] Because it could be done by a different method. Jim _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace From nobody Fri Aug 30 04:12:55 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14D29120814; Fri, 30 Aug 2019 04:12:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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=bbhmail.nl Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U86QF7O4CTeB; Fri, 30 Aug 2019 04:12:49 -0700 (PDT) Received: from smtprelay.hostedemail.com (smtprelay0033.hostedemail.com [216.40.44.33]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8E4A120018; Fri, 30 Aug 2019 04:12:48 -0700 (PDT) Received: from filter.hostedemail.com (clb03-v110.bra.tucows.net [216.40.38.60]) by smtprelay08.hostedemail.com (Postfix) with ESMTP id 83FB9182CF665; Fri, 30 Aug 2019 11:12:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bbhmail.nl; h= mime-version:content-type:date:from:to:cc:subject:reply-to :in-reply-to:references:message-id; s=key; bh=hUs+LgUZDCAQXsoI3m rfA86v0MVglzAvrBM4MuLa6lE=; b=C4auUkM6HikmZbkv2YVFS/41rA2DYDh8tK fXVBpbJIeGDDExbGNLnOcBJYhY33cxsXTyXWp11LOegJrm6uPXHwYOXIObUcEaaW PmZs+n6CiG1fjM7Zj7PRXyqCw873tKVSiAmpgUsDhH+eM0Nd4t1Z+hrvLZnah1Bo WTQfyntQs= X-Session-Marker: 73746F6B636F6E73406262686D61696C2E6E6C X-Spam-Summary: 2, -10, 0, , d41d8cd98f00b204, stokcons@bbhmail.nl, :::::::, RULES_HIT:41:72:152:327:355:379:582:599:800:960:962:967:968:973:983:988:989:1152:1189:1208:1212:1221:1260:1313:1314:1345:1359:1431:1436:1437:1516:1517:1518:1575:1588:1589:1592:1594:1605:1617:1712:1730:1776:1792:2068:2069:2197:2198:2199:2200:2525:2527:2528:2551:2553:2559:2564:2638:2682:2685:2689:2691:2693:2731:2859:2892:2895:2897:2898:2901:2906:2909:2910:2911:2922:2923:2924:2925:2926:2933:2937:2939:2942:2945:2947:2951:2954:3022:3138:3139:3140:3141:3142:3622:3865:3866:3867:3868:3870:3871:3872:3873:3874:3934:3936:3938:3941:3944:3947:3950:3953:3956:3959:4250:4321:4425:4860:5007:6117:6119:6261:6657:6659:6678:7576:7774:7875:7903:7974:8545:8557:8568:8603:9010:9025:9040:9177:9545:10004:10848:11026:11232:11473:11657:11658:11854:11914:12043:12050:12109:12114:12291:12295:12379:12438:12663:12679:12683:12740:12895:13139:13141:13161:13180:13200:13229:13230:13439:13846:13972:14095:14110:14799:21060:21080:21324:21433:21450:21451:2 X-HE-Tag: shake01_527f7a10a1824 X-Filterd-Recvd-Size: 23548 Received: from mail.bbhmail.nl (imap-ext [216.40.42.5]) (Authenticated sender: webmail@stokcons@bbhmail.nl) by omf01.hostedemail.com (Postfix) with ESMTPA; Fri, 30 Aug 2019 11:12:46 +0000 (UTC) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_fa2fcbc5f8adccdd6342e33e0fe12a62" Date: Fri, 30 Aug 2019 13:12:46 +0200 From: Peter van der Stok To: Jim Schaad Cc: 'Benjamin Kaduk' , draft-ietf-ace-coap-est.all@ietf.org, ace@ietf.org Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <027701d55ebf$994184b0$cbc48e10$@augustcellars.com> References: <20190828233639.GI84368@kduck.mit.edu> <027701d55ebf$994184b0$cbc48e10$@augustcellars.com> Message-ID: X-Sender: stokcons@bbhmail.nl User-Agent: Roundcube Webmail/1.2.7 X-Originating-IP: [5.206.216.229] Archived-At: Subject: Re: [Ace] AD review of draft-ietf-ace-coap-est-12 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2019 11:12:53 -0000 --=_fa2fcbc5f8adccdd6342e33e0fe12a62 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII HI Jim and Ben, Ben, many thanks for a nice and elaborate review of the draft. beginning next week I will provide partial answers to the review. Some small remarks below to the much appreciated explanations by Jim. An initial answer to the first point precedes the answers by Jim. cheerio, Peter _____________________________________________________________ Section 2 This document also profiles the use of EST to only support certificate-based client authentication. HTTP Basic or Digest authentication (as described in Section 3.2.3 of [RFC7030]) are not supported. Is the intent just to exclude HTTP-layer authentication, or to specifically prefer client certificate authentication? 7030 does allow for non-certificate TLS-layer authentication (e.g., TLS-SRP), which would be compatible with DTLS just fine. There's also recurrent talk of getting modern PAKE(s) integrated with TLS, which might also be an option in the constrained space. [There are subsequent parts of the document that continue to assume only-certificates, so I'm mostly assuming that the intent is specifically to prefer client certificates, and have not made specific notes at those other places in the document.] client certificate authentication is preferred based on the following history: est_coaps was initially written as extension to anima BRSKI for small devices. In that context the only reasonable use case is client certificate authentication. In a later stage a wider audience of the document was identified beyond BRSKI also with a certificate authentication use case. The draft is limited to the certificate authentication, other authentications are not considered. I am not sure if this falls under preference of certificate authentication or exclusion of http layer authentication. If http layer authentication is wanted, my suggestion is that another document specifies this. This draft does not forbid the use of http layer authentication. Did I interpret your remark as you intended? Jim Schaad schreef op 2019-08-30 01:15: > A couple of answers from my own perspective > > -----Original Message----- > From: Ace On Behalf Of Benjamin Kaduk > Sent: Wednesday, August 28, 2019 4:37 PM > To: draft-ietf-ace-coap-est.all@ietf.org > Cc: ace@ietf.org > Subject: [Ace] AD review of draft-ietf-ace-coap-est-12 > > Hi all, > > A good number of comments here, though many are just nits. We may need some > more in-depth discussion about only using certificates for client > authentication (immediately below) and how we discuss server-keygen. > > Thanks, > > Ben > > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > > When proof-of-possession is desired, a set of actions are required > regarding the use of tls-unique, described in Section 3.5 in > [RFC7030]. The tls-unique information consists of the contents of > > I see the note in the shepherd writeup about converting EST to use TLS > exporters rather than tls-unique in a separate update document. Where is > that work happening? The discussion in Section 10.1 is helpful (and we > could do well to reference it from here) but does not inspire great > confidence in the reader that such work will come to fruition. > I think we also need to at least mandate extended-master-secret to be used > on the underlying DTLS connection. (That is, assuming that we don't want to > lock down to specific, non-vulnerable, ciphersuites -- RFC 7925 only has > TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 as MTI, not MTU.) > > [JLS] If this work is going to happen it needs to be done as an update to > the EST RFC. I don't know if it would be better to do that in LAMPS rather > than here. Currently I do not know of anybody who is going to do this. > This is my issue and I am willing to let it slide for the time being. > > I am happy with an update to LAMPS > > In the context of CoAP, the presence and location of (path to) the > EST resources are discovered by sending a GET request to "/.well- > known/core" including a resource type (RT) parameter with the value > "ace.est*" [RFC6690]. The example below shows the discovery over > > Is that a literal asterisk, for ace dot est star? > (1) Why? > (2) It probably merits a mention in the text to confirm it for the reader. > > [JLS] This is standard CoAP searching with the "rt" parameter. The start is > a) literal and b) means a wild chard with the expected meaning. I don't > think that this needs any additional text. > agree; new text will look much like repetition of text in other documents > > It's a little unfortunate that we can only indicate ct=62 for the last two, > and there's no way to indicate what content types we expect within that > container. > > [JLS] This was a big topic of discussion both in ace and more importantly in > core for the multipart content type. If this is solved it should be solved > in CoRE and not here. (I recognize from the text that you don't expect it > to be solved in this document.) > finding the other ct's means parsing the CBOR content > > I can (grudgingly) accept that people are going to do server-side key > generation, so I do not propose to remove it from the document. The policy > case is a clear example of why the feature needs to be available, but I'm > not 100% sure that I believe that server-keygen could be "more secure" given > that the client needs to be able to produce secure random numbers for DTLS > (though I do accept that some people will believe it to be so!). It seems > likely to only be possible in some intermediate situation where the > client-generated random numbers could be attacked but at substantial > expense, such that paying that expense for a single handshake is "too much" > for the attacker to bear, but doing it for the key generation that would > give the attacker all transactions would make the expense worthwhile; this > intermediate situation seems to also be transitory, since attacks only get > better/cheaper. > For the other case, if we were doing RSA keygen, then going from random > numbers to prime generation could be enough incremental expense that > offloading to the server would make sense, but I didn't think the elliptic > curve stuff had the same kind of issues, so I'd like to hear more about the > resource-consumption aspect as well. > > [JLS] I would disagree that there is any requirement for a client using > DTLS to have any type of secure random numbers to still get a secure > channel. If you do PSK authentication, then it is not required. The > "random numbers" in the protocol are not really random, this is really true > because they are public numbers, you would like them to be non-predictable > but I do not know that this is even a requirement. The only question is how > much you want to avoid some type of static-ephemeral key agreement state > which looses the PFS but is still potentially not horrid to have. > I would prefer my co-authors to react to this aspect > > with other requests in the same DTLS connection SHOULD revalidate the > server certificate chain against the updated Explicit TA from the > /crts response before proceeding with the subsequent requests. If > the server certificate chain does not authenticate against the > database, the client SHOULD close the connection without completing > the rest of the requests. The updated Explicit TA MUST continue to > be used in new DTLS connections. > > I'm not going to say you shouldn't do this check, but it seems pretty easy > for an attacker that knows it's servicing a /crts request to supply a > response that includes a (potentially bogus) trust anchor that can certify > the certificate it used for the current connection. So it's not clear how > much protection this really provides. > > [JLS] Right, of course the attacker that is going to do this needs to have > gotten a trusted channel set up initially to provide that (potentially > bogus) trust anchor over. If you can do that then there is no longer any > trust in the system at all. > > As described in CMC, Section 6.7 of [RFC5272], "For keys that can be > used as signature keys, signing the certification request with the > private key serves as a POP on that key pair". The inclusion of tls- > unique in the certificate request links the proof-of-possession to > the TLS proof-of-identity. This implies but does not prove that only > the authenticated client currently has access to the private key. > > Do we want to further clarify that this means the PoP is weaker than it > could be? ("no" is a fine answer, as always.) > > [JLS] My response would be no. I have spent hours describing the issues > that arise here without it always being clear that I have succeeded. Trying > to do this in text and get the corner cases well described is extremely > difficult. > > It also assumes the Registrar has a trust relationship with the > upstream EST server in order to act on behalf of the clients. When a > client uses the Implicit TA database for certificate validation, she > SHOULD confirm if the server is acting as an RA by the presence of > the id-kp-cmcRA EKU [RFC6402] in the server certificate. > > Why is this only a SHOULD? > > [JLS] Because it could be done by a different method. > > Jim > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace --=_fa2fcbc5f8adccdd6342e33e0fe12a62 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8 HI Jim and Ben,

Ben, many thanks for a nice and elaborate  = review of the draft.

beginning next week I will provide partial = answers to the review.
Some small remarks below to the much appreciate= d explanations by Jim.

An initial answer to the first point prec= edes the answers by Jim.

cheerio,

Peter
________= _____________________________________________________

Sect= ion 2

   This document also profiles= the use of EST to only support
   certifi= cate-based client authentication.  HTTP Basic or Digest
   authentication (as described in Section 3.2.3 of [RFC= 7030]) are not
   supported.
<= br />Is the intent just to exclude HTTP-layer authentication, or to
specifically prefer client certificate authentication? &nb= sp;7030 does allow
for non-certificate TLS-layer authenti= cation (e.g., TLS-SRP), which
would be compatible with DT= LS just fine.  There's also recurrent talk of
gettin= g modern PAKE(s) integrated with TLS, which might also be an
option in the constrained space.
[There are subsequen= t parts of the document that continue to assume
only-cert= ificates, so I'm mostly assuming that the intent is
speci= fically to prefer client certificates, and have not made specificnotes at those other places in the document.]

&l= t;pvds>
client certificate authentication is preferred based on the= following history:
est_coaps was initially written as extension to an= ima BRSKI for small devices.
In that context the only reasonable use c= ase is client certificate authentication.
In a later stage a wider aud= ience of the document was identified beyond BRSKI also with a certificate a= uthentication use case.
The draft is limited to the certificate authen= tication, other authentications are not considered.
I am not sure if t= his falls under preference of certificate authentication or exclusion of ht= tp layer authentication.
If http layer authentication is wanted, my su= ggestion is that another document specifies this. This draft does not forbi= d the use of http layer authentication.
Did I interpret your remark as= you intended?
</pvds>



Jim Schaad schreef op 2019-08-30 01:15:

= A couple of answers from my own perspective

-----Original Mess= age-----
From: Ace <ace-bounces@ietf.org> On Behalf Of Benjamin Kaduk
= Sent: Wednesday, August 28, 2019 4:37 PM
To: draft-ietf-ace-coap-est= =2Eall@ietf.org
Cc: ace@ietf.org
Subject: [Ace] AD review of draft-ietf-ace-coa= p-est-12

Hi all,

A good number of comments here, = though many are just nits.  We may need some
more in-depth discu= ssion about only using certificates for client
authentication (immedi= ately below) and how we discuss server-keygen.

Thanks,
<= br /> Ben

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%= %%%%%%%%%%%%%%%%%%%%


   When proof-of-po= ssession is desired, a set of actions are required
   = regarding the use of tls-unique, described in Section 3.5 in
 &n= bsp; [RFC7030].  The tls-unique information consists of the conte= nts of

I see the note in the shepherd writeup about converting= EST to use TLS
exporters rather than tls-unique in a separate update= document.  Where is
that work happening?  The discussion i= n Section 10.1 is helpful (and we
could do well to reference it from = here) but does not inspire great
confidence in the reader that such w= ork will come to fruition.
I think we also need to at least mandate e= xtended-master-secret to be used
on the underlying DTLS connection. &= nbsp;(That is, assuming that we don't want to
lock down to specific, = non-vulnerable, ciphersuites -- RFC 7925 only has
TLS_ECDHE_ECDSA_WIT= H_AES_128_CCM_8 as MTI, not MTU.)

[JLS]  If this work is = going to happen it needs to be done as an update to
the EST RFC. &nbs= p;I don't know if it would be better to do that in LAMPS rather
than = here.  Currently I do not know of anybody who is going to do this.
This is my issue and I am willing to let it slide for the time being.
<pvds> I am happy with an update to LAMPS </pvds>


   In the context of CoAP, the presence and = location of (path to) the
   EST resources are discove= red by sending a GET request to "/.well-
   known/core= " including a resource type (RT) parameter with the value
  = ; "ace.est*" [RFC6690].  The example below shows the discovery ov= er

Is that a literal asterisk, for ace dot est star?
(1)= Why?
(2) It probably merits a mention in the text to confirm it for = the reader.

[JLS] This is standard CoAP searching with the "rt= " parameter.  The start is
a) literal and b) means a wild chard = with the expected meaning.  I don't
think that this needs any ad= ditional text.
<pvds> agree; new text will look much like repeti= tion of text in other documents </pvds>

It's a little un= fortunate that we can only indicate ct=3D62 for the last two,
and the= re's no way to indicate what content types we expect within that
cont= ainer.

[JLS] This was a big topic of discussion both in ace an= d more importantly in
core for the multipart content type.  If t= his is solved it should be solved
in CoRE and not here.  (I reco= gnize from the text that you don't expect it
to be solved in this doc= ument.)
<pvds> finding the other ct's means parsing the CBOR con= tent</pvds>


I can (grudgingly) accept that people= are going to do server-side key
generation, so I do not propose to r= emove it from the document.  The policy
case is a clear example = of why the feature needs to be available, but I'm
not 100% sure that = I believe that server-keygen could be "more secure" given
that the cl= ient needs to be able to produce secure random numbers for DTLS
(thou= gh I do accept that some people will believe it to be so!).  It seems<= br /> likely to only be possible in some intermediate situation where the client-generated random numbers could be attacked but at substantial expense, such that paying that expense for a single handshake is "too = much"
for the attacker to bear, but doing it for the key generation t= hat would
give the attacker all transactions would make the expense w= orthwhile; this
intermediate situation seems to also be transitory, s= ince attacks only get
better/cheaper.
For the other case, if we= were doing RSA keygen, then going from random
numbers to prime gener= ation could be enough incremental expense that
offloading to the serv= er would make sense, but I didn't think the elliptic
curve stuff had = the same kind of issues, so I'd like to hear more about the
resource-= consumption aspect as well.

[JLS] I would disagree that there = is any requirement for a client using
DTLS to have any type of secure= random numbers to still get a secure
channel.  If you do PSK au= thentication, then it is not required.  The
"random numbers" in = the protocol are not really random, this is really true
because they = are public numbers, you would like them to be non-predictable
but I d= o not know that this is even a requirement.  The only question is how<= br /> much you want to avoid some type of static-ephemeral key agreement st= ate
which looses the PFS but is still potentially not horrid to have= =2E
<pvds> I would prefer my co-authors to react to this aspect = </pvds>

   with other requests in the sam= e DTLS connection SHOULD revalidate the
   server cert= ificate chain against the updated Explicit TA from the
  &n= bsp;/crts response before proceeding with the subsequent requests.  If=
   the server certificate chain does not authenticate= against the
   database, the client SHOULD close the = connection without completing
   the rest of the reque= sts.  The updated Explicit TA MUST continue to
   = ;be used in new DTLS connections.

I'm not going to say you sho= uldn't do this check, but it seems pretty easy
for an attacker that k= nows it's servicing a /crts request to supply a
response that include= s a (potentially bogus) trust anchor that can certify
the certificate= it used for the current connection.  So it's not clear how
much= protection this really provides.

[JLS] Right, of course the a= ttacker that is going to do this needs to have
gotten a trusted chann= el set up initially to provide that (potentially
bogus) trust anchor = over.  If you can do that then there is no longer any
trust in t= he system at all.

   As described in CMC, Secti= on 6.7 of [RFC5272], "For keys that can be
   used as = signature keys, signing the certification request with the
 &nbs= p; private key serves as a POP on that key pair".  The inclusion = of tls-
   unique in the certificate request links the= proof-of-possession to
   the TLS proof-of-identity= =2E  This implies but does not prove that only
   = ;the authenticated client currently has access to the private key.
Do we want to further clarify that this means the PoP is weaker than i= t
could be?  ("no" is a fine answer, as always.)

[J= LS] My response would be no.  I have spent hours describing the issues=
that arise here without it always being clear that I have succeeded= =2E  Trying
to do this in text and get the corner cases well des= cribed is extremely
difficult.


   = It also assumes the Registrar has a trust relationship with the
 = ;  upstream EST server in order to act on behalf of the clients= =2E  When a
   client uses the Implicit TA databa= se for certificate validation, she
   SHOULD confirm i= f the server is acting as an RA by the presence of
   = the id-kp-cmcRA EKU [RFC6402] in the server certificate.

Why i= s this only a SHOULD?

[JLS] Because it could be done by a diff= erent method.


Jim

________________________= _______________________
Ace mailing list
Ace@ietf.org
http= s://www.ietf.org/mailman/listinfo/ace
--=_fa2fcbc5f8adccdd6342e33e0fe12a62--