Re: [Lake] Review of draft-selander-lake-authz-00
Marco Tiloca <marco.tiloca@ri.se> Tue, 08 November 2022 10:30 UTC
Return-Path: <marco.tiloca@ri.se>
X-Original-To: lake@ietfa.amsl.com
Delivered-To: lake@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE45EC1522C8 for <lake@ietfa.amsl.com>; Tue, 8 Nov 2022 02:30:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.108
X-Spam-Level:
X-Spam-Status: No, score=-2.108 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ri.se
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id psxoygby8s7G for <lake@ietfa.amsl.com>; Tue, 8 Nov 2022 02:30:34 -0800 (PST)
Received: from emea01-obe.outbound.protection.outlook.com (mail-swedencentralazlp170110002.outbound.protection.outlook.com [IPv6:2a01:111:f403:c202::2]) (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 06D2AC1522A0 for <lake@ietf.org>; Tue, 8 Nov 2022 02:30:31 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=H85Ve66zsW0mx8yoE05Kmd2qfLfc7T43D1aO+VTtQYdl8aTP6HZ0IY1yoqdWs1t2EEcTwzr3LPJtfQhUCvNYlslVo1SPMx8gUw9Sb16Zv88t+CcRgR7Z8pCWNhzb27+HfZ+OAJh8T4fL5kYL0Y4AtJAkOYFpgyhnQXIyaltFdV8XgIvPdTlGDLvfVDGbGSRTR+FC2tHjnkrHwHeCGJOxCLLcAteI3WxRd8q35Kkl0TzS1vO62K/LBWUbI3oT1uP1K4cXxqWfer5Fz113XjvSQoL6y0oxSsEIinqga0UcCuzLmebb3yXWS/0AthSepD1mQypNT9hkqk+mUOvyBmDM4w==
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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=CYsjsXZwS3u4FoWGOE7Fba4EEmjKW+E6Pkkqf8tjMC8=; b=j7OasIm2ZJXgoC8iyElE5pmjN7LrurvufTrxj5PIfpJX5DegVMP7Btga1WMqVsd9Uip8JpGxCtDcUSC1jzqXxitQbtLY/stXyrL41ftt5mkb99n80Af/WFueqaJABR2M4Tis9y4xniJk6kH2AjPFOTDDzPW5K9zYui05zdcSUtRSsV906UrIcnoAbw6pHqlEquvjP6tD253nF3dz66VY76pIVMjWQeVJTj+2VZL9kk+juBpbTgpX6xBWS8Guu5Z68ORfZ67yLJ0PE27VztSSq61ejp8wZNBwFWRH39C9Prv2uainxYKmquY1sDCydbG2eDKjTPrXfOnXXO9o9xrm5g==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ri.se; dmarc=pass action=none header.from=ri.se; dkim=pass header.d=ri.se; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ri.se; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=CYsjsXZwS3u4FoWGOE7Fba4EEmjKW+E6Pkkqf8tjMC8=; b=NCmZgglKICqSBqXAEbXzLUsJNY0EMZZIUKl+BNbm+t3nAUKdFxAYNtXp6PiZditv2VEsFG81CowYpUk3AcabrQnQF9kkcuJ0hINevTIsHmH+ZjczdCHUIl5i1GWOt+o5rwpBK2dg55gB+DaO9hQOapPTgJtNpLXv6d6U3gY839E=
Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=ri.se;
Received: from GVYP280MB0464.SWEP280.PROD.OUTLOOK.COM (2603:10a6:150:37::17) by GVZP280MB0201.SWEP280.PROD.OUTLOOK.COM (2603:10a6:150:42::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5791.26; Tue, 8 Nov 2022 10:30:28 +0000
Received: from GVYP280MB0464.SWEP280.PROD.OUTLOOK.COM ([fe80::71cc:b821:3b5c:b564]) by GVYP280MB0464.SWEP280.PROD.OUTLOOK.COM ([fe80::71cc:b821:3b5c:b564%9]) with mapi id 15.20.5791.026; Tue, 8 Nov 2022 10:30:27 +0000
Message-ID: <34e984bf-f1bc-2588-6b82-3ef7abe3e37e@ri.se>
Date: Tue, 08 Nov 2022 10:30:25 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.2.2
Content-Language: en-US
To: Michael Richardson <mcr+ietf@sandelman.ca>
Cc: "lake@ietf.org" <lake@ietf.org>
References: <e7e16233-3bfc-56b0-1a77-dd8ce370bf44@ri.se> <176307.1667846835@dyas>
From: Marco Tiloca <marco.tiloca@ri.se>
In-Reply-To: <176307.1667846835@dyas>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="------------TtrYtZiEu0P94tGskwHIpYPU"
X-ClientProxiedBy: LO4P123CA0328.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:18c::9) To GVYP280MB0464.SWEP280.PROD.OUTLOOK.COM (2603:10a6:150:37::17)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: GVYP280MB0464:EE_|GVZP280MB0201:EE_
X-MS-Office365-Filtering-Correlation-Id: 7426d361-2fc4-4842-1618-08dac1744112
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: 8upqGvzDnCXME5RDDel/OADfQeKF/aWFg0FbFZ+xFw3FVA/limGcnEGm5mmrw6yU3wfrkYuyDbIdXwJPMcDvvmfQG0i2Cka6exL3iytFb4SAKegbRV8YMPugv1r4VMHX8bvVI+6q+aJYQclsHq4SJBpuVHk51vMxcxV/KgbzEY53ZCSPgCCIJ7dABrDrYL9P3zFHhM+Q3EFQBmzZiY9HhH9CI5zczXe3KFn7KSKvxTBm3zX/24++Cch0mU1iI36lM7kicMeD+k+4iox/Zn+PEYBrSxCqlx3uc+u2YUNHFHS3/I229yl5iKJpE+C8rhgauo0HrokFwn+c7/FZqbPa9DkYY9/VyvMR7JKzyyFE9eyAQUI4ydkOdCT0ZPjZ5kTt69UZfMMOvlImgoJYMlANc6bi8U26SWkQboufSJ29KuPLw0R2uHa78c9kWZRVawWXA/Onk4gs81Lz3iRXBK/37BuXPA7xLxfOPxRgdSBApQlCG4NAJrvkZRFrxhHb+EJg5FbWx2pia2og7vu7ZkxIfhqwk9tuEFt6Re2SVcW93PUZprMPAQVIcF+61mkWubJfHBhTcPRH0vX8fahDGh+qVdo/wqQgkiti0XSWs+29OcUdCkhfbNxBaVk1Opofnbf6DTQVYVAW3LB27kbwJKFlU8GetEdbBZJS92uDtCHnnCQRbYCkKQ2pxOfPdXHOOotozkqfDzDuD6Zl5yf1S43iKfmu5BwYi8M4bbYk6YXyWmubr2ihRLIwYo5PvXDl3gdlOEfklWAmIqD+WdxD/0DHXzu528XmxhEvkIhvEjm/7B8ZRk+Xt7YXCWAvqlT7CZxK
X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:GVYP280MB0464.SWEP280.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(13230022)(4636009)(376002)(39860400002)(136003)(346002)(366004)(396003)(451199015)(8676002)(2616005)(186003)(4326008)(66946007)(21480400003)(66556008)(31686004)(41300700001)(66476007)(6506007)(5660300002)(478600001)(26005)(6512007)(55236004)(33964004)(53546011)(235185007)(8936002)(38100700002)(36756003)(966005)(2906002)(31696002)(316002)(6486002)(44832011)(86362001)(83380400001)(43740500002)(45980500001); DIR:OUT; SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: jb8duxag+I877sVMspRUx6LDtbTfJHqczg+44X58p2yTWVz4z7aSM0i9y9mcEV3cOHPmDeGiC35yzAeI7RQxDN161TWK45ehMlYqIL+EQBKcEp38uutYpMkSlCNHqds85SyK6A7yYYy8Po/OXFk2ycA628s9Rq3XrMK+f0XlFXtg0I59kuk3TA4QuOMQ58GBzo0vZPVvxfExxAuv/syIro82Tzdw12XAF89KOG3kWKnAw/6AdmZP0kP4sXRDo1YHnTee+gEHYp6O1pVUZPGPNuHwiYc2WeKYgwXFZqb6kH3a+/BYCtaCLT/1SS21QWQaf61tCRQd6a2RNzDtGbEEtUunJ6jSmCwxt9kSSCLVm+vvN4eDRRu4XL9B/T2haiwzG74rGYA6UYJGa4Z69FMXAE5PVgae50Iyrmcv5Ybq6DHNljP7ZpG+ZxXLdWLSGJKILZaBX/SmX3WLZQPtBRPD3tjA4Y4GzYgnlzhnbPjo/6rUCfLbnHuaIRuINpZXBiPDZU0wEJzcK6KFxbJ2N/L5gf/8AROSLmv0/36OTYaIMqiXs1UjRe3006YWqSMtagFv7tAzj4GzVG9mtgGAhhKILQoHtqp70UeB+4xTq/ULyg+R8SJlFDPF13elQETC73RjUCyyjsR28Qif+mejWCBzHCWlgfD40xZ6wrlGUcvGjYlamm/h6B+APxqq+4HNcoiW0EYyPnFpG6ZBiQ7ZJm51LWJE4GK5cBUZlj8Lf6YtkSUAi9SutQRp+41ehkEbiYbzcdcgmMcsNKP/8C542I/u02kVwrSxFugQVW5ERR9JB8WBt3/tpqqxQvOrx8JdhbrQZlzGpWK26y0Mw/N1X9WAm/xwyfkg7yJWzlxBtYiN72j5WhYdLfvhaToAF0b6eNlaXg8QSKQMN7bSfK4egrQ5Ris4nuG/hKMPp6k7Y6ksDuW6EZfDjkhwZm7renWHTmWUtTHXuVx8PFZWj2G3NOMT2k+XhQnXNueS+SqyXDjRFUXtS1czLW9ruVzV/TpSr5iNhdHEJMtnXhyb+DOkDJmnOXZcWzreXCpXgIOWooPt9YuppkYd2gOzuYePMHP/ERRRRP+N80wmnLR93+NOuExEqzXtUJwprQP44ODCsupLBQZyBw37/ExYhkwapWYtJFkz5w3uz8ddxk0kGMbZlrXEVgTjFGUwjO+xjjvx9qoAtao/as4uTSjThR8k12kXcJa5vo6wULIr6U/7KmltzaaQY2DDiCRF9eIvfYS+TYSB5/oOgLJfJjlMXrC/usvIrk4KqYOgB9FMHOSJVilOfDOLOZt0W4is28OeDqdciUAv4WM7g+Dq40zFtehta0Aix6hBBXvWkBuXdFWXDqdqcyDk5cxFpt9t7qsVP2i9jylwzeJpG+Cc1F5AxHDzGV+TRk4P8/SDJ4EwiDOSYeEGIrzyZ/EY1HPjqHBZTz+N353oyRbxLOgbd/HoA34I5+hZjI6pKp4jhMp3KQHEwbG4x9tjnBgzAw1iVY8A7J2r96DbUio1l0pMwoM800H6SAKSSyjMTHEed1nauLwHiivJf1dmw8Gomz+bQMJuC4q6bCAwLQs6GaukgcpHar4WWjRB3+dW
X-OriginatorOrg: ri.se
X-MS-Exchange-CrossTenant-Network-Message-Id: 7426d361-2fc4-4842-1618-08dac1744112
X-MS-Exchange-CrossTenant-AuthSource: GVYP280MB0464.SWEP280.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Nov 2022 10:30:27.9667 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 5a9809cf-0bcb-413a-838a-09ecc40cc9e8
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: bRB/S7ZhiMazm6gNiYb60F6VABKtrtbPDInQ6nhoZrqhau4n2+fMmxqyYjZySqb6ShkTs1TUF8OTGrMJjCeofg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: GVZP280MB0201
Archived-At: <https://mailarchive.ietf.org/arch/msg/lake/-YwJfA49ZpLqbJg4A32pNGm5jjM>
Subject: Re: [Lake] Review of draft-selander-lake-authz-00
X-BeenThere: lake@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Lightweight Authenticated Key Exchange <lake.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lake>, <mailto:lake-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lake/>
List-Post: <mailto:lake@ietf.org>
List-Help: <mailto:lake-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lake>, <mailto:lake-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 08 Nov 2022 10:30:42 -0000
Hi Michael, Please see inline my replies to your two last points. Best, /Marco On 2022-11-07 18:47, Michael Richardson wrote: > Thank you for your comments, I think that I need to go through them a second > time. > > Marco Tiloca <marco.tiloca=40ri.se@dmarc.ietf.org> wrote: > > It is fine (although excessive) to assume that, but later on the > > voucher is intended to be computed over the whole authentication > > credential CRED_R, not only on the public key PK_V. > > I don't think that we can calculate the voucher across CRED_R as the protocol > is currently designed. Why do we need to do that? Why isn't PK_V enough? > > > When establishing the secure session between V and W, it might not > > have been possible to use exactly CRED_R for authenticating V. In > > particular, CRED_R has to be a CCS, which might not be accepted as is > > by the (D)TLS handshake as raw public key of the (D)TLS client. > > Ha, yes. > So, in RFC8995, we prefer client-side certificates for V's TLS client, but we > don't insist that it be identical to PK_v. In smaller systems it can often > be the case. So, that's why the Registrar Voucher Request (RVR), is signed > by PK_V. > > draft-richardson-anima-registrar-considerations, sections 4 and 5. > > > Basically, out of the secure association establishment with V, W > > knows the public key PK_V, but it might not know the exact CRED_R to > > compute the Voucher. > > > As per Section 4.3.2, "The voucher is essentially a message > > authentication code which binds the authentication credential of V to > > message_1 of EDHOC", so the whole authentication credential has to be > > considered. > > > Why not entirely decoupling the two ways that V uses to authenticate > > with U and with W? See further comments below. > > Hmm. > > > * "A future version of this draft may specify explicit proof of > > possession of the private key of PK_V in VREQ, e.g., by including a > > signature of the contents of the voucher request made with the private > > key corresponding to PK_V." > > > Yes, this would be much better and more flexible. > > And if fits into RFC8995 model better. > > > The Voucher Request can include the whole authentication credential > > CRED_R, together with the Proof-of-Possession (PoP) evidence > > PoP_V. After all, the leg V-W is supposed to rely on a non-constrained > > link. > > Seems like maybe a hash of CRED_R could be sent as part of the voucher > request, which Pledge (U) would be able to independantly calculate. > > > The Diffie-Hellman secret can be computed using the > > public/private key corresponding to CRED_R, as well as the public key > > G_W and the corresponding private key. This assumes that V has the > > Diffie-Hellman public key of W, or that it can retrieve it latest when > > preparing the Voucher Request. > > > This is the same approach used to build Proof-of-Possession in > > draft-ietf-ace-key-groupcomm-oscore and > > draft-tiloca-ace-group-oscore-profile. > > thanks. > > > [Section 4.4.2.2] > > > * This implies that, at least for this particular EDHOC execution > > involving this particular use of EAD items, U considers a TOFU policy > > for trusting any new authentication credentials as long as they are > > valid, right? > > I might need more expansion of your thoughts here. ==>MT CRED_R is going to be transported by value in ID_CRED_R. If U is not already storing that exact CRED_R as a pre-installed, trusted authentication credential, then U needs to be ok to trust and store any new CRED_R on-the-fly, as long as such CRED_R is valid (*). This means that U is adopting a TOFU trust policy for newly seen authentication credentials of other EDHOC peers. (*) In this particular case, the validation process of CRED_R also includes validating the Voucher transported in the EDHOC EAD_2 item. <== > > > This has the following advantages: > > > - You don't need to mandate (D)TLS client authentication between V > > and W. Besides, if you still use it, it does not have to necessarily > > rely on client certificates. > > I think that misses some of the sales channel integration that is desirable. ==>MT Right, in fact Section 3.2 says that the "communication between V and W is assumed to be mutually authenticated ...", so (D)TLS client authentication is definitely expected. Yet, you do not need to rely specifically on a certificate as (D)TLS authentication credential of V in the leg V-W, which is instead what the last sentence of Section 5 says now (**). This is again in the spirit of decoupling the authentication credentials that V uses in the two legs U-V and V-W, with PK_V pertaining the former. (**) "... V MUST perform client authentication to authenticate to W, using a certificate containing the PK_V public key." <== > > > -- > Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works > -= IPv6 IoT consulting =- > > > -- Marco Tiloca Ph.D., Senior Researcher Phone: +46 (0)70 60 46 501 RISE Research Institutes of Sweden AB Box 1263 164 29 Kista (Sweden) Division: Digital Systems Department: Computer Science Unit: Cybersecurity https://www.ri.se
- [Lake] Review of draft-selander-lake-authz-00 Marco Tiloca
- Re: [Lake] Review of draft-selander-lake-authz-00 Michael Richardson
- Re: [Lake] Review of draft-selander-lake-authz-00 Michael Richardson
- Re: [Lake] Review of draft-selander-lake-authz-00 Marco Tiloca