[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