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

Marco Tiloca <marco.tiloca@ri.se> Wed, 21 August 2019 06:53 UTC

Return-Path: <marco.tiloca@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 EF54A120142 for <ace@ietfa.amsl.com>; 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 <ace@ietfa.amsl.com>; 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 <ace@ietf.org>; 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 <ietf@augustcellars.com>, 'Ludwig Seitz' <ludwig.seitz@ri.se>, <ace@ietf.org>
From: Marco Tiloca <marco.tiloca@ri.se>
Message-ID: <B030561C-921B-41B6-9EBA-FFD0E42B5DC0@ri.se>
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: <HE1P18901MB0220CBB11ED496F54FE6737C99AA0@HE1P18901MB0220.EURP189.PROD.OUTLOOK.COM>
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: <https://mailarchive.ietf.org/arch/msg/ace/AaLcXdLx7wYpdVVw6Ms7XC40DrU>
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: Wed, 21 Aug 2019 06:53:53 -0000

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.  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?
>
>[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]  
>
>/Ludwig
>
>
>
>
>--
>Ludwig Seitz, PhD
>Security Lab, RISE
>Phone +46(0)70-349 92 51
>
>
>_______________________________________________
>Ace mailing list
>Ace@ietf.org
>https://www.ietf.org/mailman/listinfo/ace

-- 
Marco Tiloca
Ph.D., Senior Researcher

RISE Research Institutes of Sweden
Division ICT
Isafjordsgatan 22 / Kistagången 16
SE-164 40 Kista (Sweden)

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