Re: [Ace] Keeping the same key identifier for groups

Ludwig Seitz <ludwig.seitz@ri.se> Tue, 20 August 2019 09:09 UTC

Return-Path: <ludwig.seitz@ri.se>
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 <ace@ietfa.amsl.com>; 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 <ace@ietfa.amsl.com>; 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 <ace@ietf.org>; 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: <ace@ietf.org>
References: <01fc01d556ce$69f73cc0$3de5b640$@augustcellars.com>
From: Ludwig Seitz <ludwig.seitz@ri.se>
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: <AM0P189MB0754BDFFCBDCA209BE35E9B882AB0@AM0P189MB0754.EURP189.PROD.OUTLOOK.COM>
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: <https://mailarchive.ietf.org/arch/msg/ace/GS3W3dwTMFQPiHL6KL6uIjGz1yQ>
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\)" <ace.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ace>, <mailto:ace-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ace/>
List-Post: <mailto:ace@ietf.org>
List-Help: <mailto:ace-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ace>, <mailto:ace-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 20 Aug 2019 09:09:25 -0000

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




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