[Lake] Review of draft-selander-lake-authz-00
Marco Tiloca <marco.tiloca@ri.se> Mon, 07 November 2022 17:27 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 C0EC3C1524D2 for <lake@ietfa.amsl.com>; Mon, 7 Nov 2022 09:27:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.097
X-Spam-Level:
X-Spam-Status: No, score=-7.097 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, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, T_SPF_HELO_TEMPERROR=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 msY04etduYVq for <lake@ietfa.amsl.com>; Mon, 7 Nov 2022 09:27:24 -0800 (PST)
Received: from emea01-obe.outbound.protection.outlook.com (mail-swedencentralazlp170120004.outbound.protection.outlook.com [IPv6:2a01:111:f403:c202::4]) (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 567DFC15DD66 for <lake@ietf.org>; Mon, 7 Nov 2022 09:27:00 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=knQ3v14VQPBcsnzCeHvdNVkf3t7Nxd0/4CmFpm3H/F1csqN9wRVJ6X/4THIKncDLVSfooG0f9txeJdnVXtzkCBYF7xDWn3b8jAbplsAFpLq/QpAMUMCIPPAFiqsZRJJufyqIWKpBxA2cZVI2By9f0KKjFxMPfIL5h0IHj6t330LksfcVP+X30lySu75PM4j53LHwCWZpg10KRALzZuiNGZPQkU9GLAIkpkBZmO7ChoE4uHoFJQBry4UsjJrnEcbB34e+cic8T21wDfb+Do1SCTNlm6NV7YXfNbWl0hOll/8JKqAdhtzi74IIbrHtWOIXGGhWGSk8B7UUuQmuoa6A5A==
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=cvr5/+KqT9ZimADodN0akg99YSkc9/+KQYpQC0RG8cc=; b=j3e7ndF2z9iM9BZHDpHxCmjVDxSWp2blkhONgrgJKO8K8FFM64t4pa9SlW0PqEz4FlpuoEShgLnC5Ik0zk3DVzVCcimWeTb4eFGgDsZ6Fo7YIczT8SwQTx40deMW1k9l4Kcn32weupJ7+MYEgMjrWfz8OiNCSYb4sMyLEfLHMOjXngUC4xnzzTq/FTFKUnKkywXmexTytdwecltL5Ns2mS7kWNaeBaAw8v/sKJVEh3IZiycKcHbiLSVMev7PjF0TsTrl6mxIBgB3Myz9tHjWlvm6njVQ90u36vEo96SDoE7s0raC3lS+A5/P7SPey4YjkmYh86u+kAOJSYxcXszY7Q==
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=cvr5/+KqT9ZimADodN0akg99YSkc9/+KQYpQC0RG8cc=; b=G5PaKQv4ITlDqW6S+cu/e5ofp8mnWFP4HXYl6Ooi7hPgA4nwVXLwc9vRhAqL0aAKr2GLShaaNKz8sD12sX7K5LiO6znZqJkRUUvaWhp0j0DscAb9H/O84FHYP2NeXhBQSkj0OdNDAqFTbqEfSrRVqIoAbMC2e6dDsSpyaCFQZyE=
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 GV3P280MB0113.SWEP280.PROD.OUTLOOK.COM (2603:10a6:150:c::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5791.26; Mon, 7 Nov 2022 17:26:53 +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; Mon, 7 Nov 2022 17:26:53 +0000
Message-ID: <e7e16233-3bfc-56b0-1a77-dd8ce370bf44@ri.se>
Date: Mon, 07 Nov 2022 17:26:51 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.2.2
Content-Language: en-US
To: "lake@ietf.org" <lake@ietf.org>
From: Marco Tiloca <marco.tiloca@ri.se>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="------------JjndyMe4nTaNljVR8iQU4kL9"
X-ClientProxiedBy: LO4P123CA0680.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:351::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_|GV3P280MB0113:EE_
X-MS-Office365-Filtering-Correlation-Id: b3dfb419-b957-4b0e-7e23-08dac0e54327
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: H/TuktKnjAXLo3ekioNaswTioSgXeG/bKEwEk3Dzcr9dKW97HexPEStZK9C2lOGuBcGLj7rDPJFL4tklJo0Kv2IAhZI3LHaAlv/ILlHXZOvU55d7jtw9U0HRWzsBTHlu/s2dofLNyXEotduQ68HqxxN/TJtXVfbGZyPXdQ2GedK3pdGUVl3KLZPlckZJsAzhHx1N4yqmlT3o0wlYMLRnxKK07UvY+04LENmBmQV0T/b4nE4mvsDApUsUY5nrVIcCdsY2qEl4Y0yDOSz+RD900intpNrcUT/SVyfkEWqeHuS159Orm7Q8KExSrxd1tVtnDqi1dnq2n+FAncDm2sJNZZ+qVnFw5tjE7J8zlL+GVVrnQ4fxNgqZjGtoLtkH5+bYUaNrprf2xoippqluDVlZ2CZI9L4XosllIODZC8PmFwbIfY3PsM9fvvjypx4rj574OAPgAZRBrGEUuFgkm0mGy0M+qW4HIYlgJZ/gRnrmKdZzQr+eR5YfVuDqTY994IqNPaBS29yNHltviMyCnAGlbOLadzpZ6ZFsWPcv0ytb+ZN8rC2a3g1omboWuOKsDrLV6QY5MyzIXbaK/YhiTZZIdpE+Ny9PhQd1UNeui+x0JU4everZqoKbWGapAIN6pktAHt9vtWMxPHB9hOPz3UypaxGXckwMIK7ok8CnQHEIbVIcn4J0AB3JnQ3sUvYuhuOZO34buEqENsy+QusLsAr3wJDQbtSQfq3mcRPEwuVhjoqEvMthoS+VN30Yv7NHE+hImMNBX12IxvsmvMvoc09gnWQbuFZkVoTwhalDKEgNo8bDU359Xl+aYMqgNjZNylb/
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)(366004)(346002)(136003)(39860400002)(376002)(396003)(451199015)(186003)(6512007)(6506007)(44832011)(2616005)(33964004)(83380400001)(21480400003)(2906002)(6916009)(478600001)(235185007)(6486002)(966005)(38100700002)(5660300002)(41300700001)(8936002)(316002)(66556008)(66946007)(66476007)(8676002)(36756003)(31696002)(86362001)(31686004)(45980500001)(43740500002); DIR:OUT; SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: +h81QqZYcFWWyCYb7Uq+ulcNi3uk+Ctf4YX4G3noNEWt55vnxZmxQqmN9m0y3D1/SBzwrUAZy+IhvWQRVn6pJa5BhxN7RYlqHdr5TT72ZM1sLqxxpHBCsdB/o0mTQU1NxR/DkRlrExM1r32UN349gIW92YV02xCg/4HIOs1RNykX3dVACmPj9w3RmNb/wGl5L6xl9OxYiEYBO6TJrI5uZYfBeiSNFY936UsU6NCTqJiYgx5kp5pVyNMFzzDfojeLX8gBYEQd/9L4Le8aUcOPRKaOqBKuerWsW++WfPjcokR4SP7ZhHeNckay4uc78qIW0wcBPYjDn4T1uf2kiOyA7GQKoRYGCzQdOuET/cZSLC6XHhszYC10I6mFpdyVnloErPsl5FCVX0pbHvWPgpmuvg0eAw2RT40fFWfA1AAlkVD6xfe0/zA4QtQaVLMflOkC1xg7rVzLaxnHfFvw9bDPp2lfxSUwwYTZLKFqCxGOaK7MIETt/4Sb9omoPpcT0sj9gMMbJASlqqFJd0A3JiJXDW4/5Qs/LJp9OMS+nTIFhCfpV5M23eSA8MYhJ6b83TBqgWIlnvsmY0lE/nPr9cBRJ46Sds1PHGyhhibJzmSIbR2adKc3LR+28yBll5Z/m6zbBq5cg4AybWHSZXy5NjaTzAnCRsCUg+9mTZEfjqHLo6WUWdXUlNmhCIWrGEoKfqayWuexMcjHBGk+fAytNIHvvDCJGH6iQGGBG94dTYKz1emJLlwZBqSDqQYTg/uCENYpwGzMKb3nIn65RxaeoABDM6erUaGxksKB/itQTSZZ9vvpE7qGImi48ZiSh7JUswKT7NIbLKLFIx8v5nuJIGSiOipffnlkXAMMtjIBN/PzFKkR4vyD+cFY+k+i/MuTTFsICMmAh822NwnxCOXhVkC4wa6wUOwRVCKfo1xNykQdAcyrmUmXC7565elqIxjFxPEYnxaFKRv3/23OW6FTBSraj0TuGq9kvLPvlXUwuB2th1s2xofsJAE0JALNHyPxL/OmjFLHVUCDHj7Gs+nftWURLkH1CTItxE2AQHvqFXeelVRAcAeRC4ulpocYS26Q3kStPrzD5E48teQ1Zbyl3y9PCXP63VimTHatz+YInuKo86r8pOlhCrZxvvvs9rzwfO2+NPVQWWejWduATymYCojI8CbOi9Dt87BKHzIl76IixUJG219BxjOTo5zr5z8hMdyuEYA3YyEpMy4oxrfGTVezJkozoOxwOAD6JbUx+VDIK2a/ofS1E/wTbjG4kL9FmTzIHfNdmVst5lg6n8GsUrg3v/uh2TFCOfAHTfS7g97EbrXDj6BHitmT8KxtAsvJbvjB45qW0wg6KTCxv4KQJGDpF75CfIY357eJgd8Q8eosZzv+Tw2AK2ySyRkLJC+o/mamWkE4fJjMw3ppbrhV1kmzXGopZBJ5nT6AR32mBnHXQfLBXyXT6qud24KjaDblU0LcrhbMvltp6M+0FbhdLzI+mlUpShcbVYXAtWO3GmOTLTDosELUNSJgsoG6zvmtFasXRAuTbDsEPEwzYZrjBcddZYfRgU1n1sADmfLRdWUtqXt+Pba8qat2Xg4yIBxt7lMGzYh3fpW8xMjRJjUITJ4dfIrMHVa4/LnBC/+YO+b+leOcwi4wqNFEmaiRaF+pkU4J
X-OriginatorOrg: ri.se
X-MS-Exchange-CrossTenant-Network-Message-Id: b3dfb419-b957-4b0e-7e23-08dac0e54327
X-MS-Exchange-CrossTenant-AuthSource: GVYP280MB0464.SWEP280.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Nov 2022 17:26:53.4627 (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: zpCgSRToqTehIpBQ4rKCTPalZnLswEc6vIS0nSjKRYxUUwTIPo/nfewMl20zYmOtdtbRYzuqP9agG5q1DXexaw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: GV3P280MB0113
Archived-At: <https://mailarchive.ietf.org/arch/msg/lake/5fR1AitD4XRuWf18OgGbtwge40U>
Subject: [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: Mon, 07 Nov 2022 17:27:30 -0000
Hi all, Please see below my comments about draft-selander-lake-authz-00 [1]. Best, /Marco [1] https://datatracker.ietf.org/doc/html/draft-selander-lake-authz-00 ====================== [Section 3.2] * "In this version of the draft is assumed that V authenticates to W with the public key PK_V using some authentication protocol providing proof of possession of the private key, for example TLS 1.3 [RFC8446]." 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. 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. 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. * "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. 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. To admit both signing and Diffie-Hellman CRED_R (without mixing up authentication in the U-V leg with that in the V-W leg), the PoP evidence PoP_V can be: - A signature, if CRED_R includes a signing public key. - A MAC, if CRED_R includes a Diffie-Hellman public key. The MAC can be computed be means of a key, derived from a Diffie-Hellman secret and the EDHOC G_X as salt. 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. [Section 3.3] * "W may provide V with the authorization credential of U, CRED_I, after V has learnt the identity of U." Do you mean "authentication credential", right? But isn't that in fact the identity of U? Do you rather mean "after V has learnt ID_CRED_I", i.e., following the decryption of message_3? That's what Figure 2 and the text in Section 4.4.3.2 suggest. As to "may provide": this is just to still admit U to specify its certificate by value in CRED_I, correct? So this still remains possible. If the idea is for V to request CRED_I from W, what is specified in ID_CRED_I as a reference to CRED_I? Since such a reference is relevant for W (and it might collide with other references stored at V as related to totally different peers than U), how do you tell V that such a reference is actually to be forwarded to W and consumed by W? Perhaps you can have ID_CRED_I specifying a URI, which points to a resource at W and whose path includes an identifier that W understands as related to the CRED_I to provide to V. [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? [Section 4.5.1.1] * See the comments above for Section 3.2, i.e., I would always include CRED_R and PoP_V, unless exactly CRED_R was used when establishing the secure association between V and W together with V's authentication (which feels like a corner case). That approach would also dismiss the problem when V authenticates to U with static Diffie-Hellman and to W with a signature. * "Editor's note: Define PoP_V (include G_X, ENC_ID in the calculation for binding to this EDHOC session)." When working on draft-ietf-ace-key-groupcomm-oscore, Jim suggested that a PoP evidence (like PoP_V here) should always cover also information generated by the peer that computes the PoP evidence. Instead, none of the pieces of information intended to be covered by the PoP evidence is genered by V. Hence, you may need anyway also a further nonce generated by V and different than the EDHOC G_X, to be included in the Voucher Request and covered by PoP_V. Perhaps the EDHOC G_Y would do the work? [Section 4.5.2.1] * "W retrieves the public key of V, PK_V, used to authenticate the secure connection with V, and constructs the CCS ... Editor's note: Make sure the CCS is defined to allow W generate it uniquely from PK_V." Right, which exact CCS? Simply the public key as COSE_Key, surrounded by 'cnf' as the only element of an outer map? That's not flexible in general, as the outer map can also include additional information that W may not be aware of. As above, I think that, except in very particular corner cases, V has to provide W with the full authentication credential CRED_R in the Voucher Request, together with PoP_V. [Section 5] * "In both cases, V MUST perform client authentication to authenticate to W, using a certificate containing the PK_V public key." As above, I would totally decouple the secure association between V and W from the CRED_R used by V to authenticate to U in EDHOC. 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. - You don't need to come up with a canonical way for W to build a CCS including the public key PK_V. - You don't need to worry about V authenticating to W with a signature and to U with static Diffie-Hellman. [Section 6] * "W may be used for lookup of CRED_I from ID_CRED_I, or this credential lookup function may be separate from the authorization function of W." This is easier to visualize when looking at Figure 2 in Section 4.1, so it would be good to refer it in this sentence. Also related to a previous comment about Section 3.3, a possible construction for this particular EDHOC execution can be: - If ID_CRED_I contains CRED_I by value, V takes CRED_I from ID_CRED_I. This assumes that V is already storing CRED_I or that it relies on a TOFU trust model, at the very least for this EDHOC execution using these particular EAD items. - If ID_CRED_I contains a reference to CRED_I different than a URI, V fetches CRED_I from its local storage as normally expected. - If ID_CRED_I contains a reference to CRED_I as a URI, V fetches CRED_I from the indicated URI, which has to include an identifier of CRED_I that is meaningful for the contacted server where to fetch CRED_I from. As per a comment above, this URI can practically point to a resource at W. -- 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