Re: [Ace] AD review of draft-ietf-ace-cwt-proof-of-possession-06

Ludwig Seitz <ludwig.seitz@ri.se> Tue, 27 August 2019 06:52 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 5901B120DB8; Mon, 26 Aug 2019 23:52:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 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, 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 WOTwSyaxqJuV; Mon, 26 Aug 2019 23:52:29 -0700 (PDT)
Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40068.outbound.protection.outlook.com [40.107.4.68]) (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 2A24E120D6A; Mon, 26 Aug 2019 23:52:28 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kXKO7mTMiB3pjpUE3/zy/GPneFyVYHwwdyOxgAfSXAQMdePPNs3njXBwe8wYvxPiaQCTGKge6DgCDGkS8kgq5nQj2ce7rMTINgzF28D2skTT1ayiHac4SbY11+8gfwc+X5XZ7CJAzPtS0tSMvbws8J47su8WQ3hESJTMWvOSPwEKLSVt5LOSWwtRldtoAJvUISJSkZ3za0ltysiSdmJr7s78D6ds+cpVOSOL9QVtKy2gIF+X9IRpVQusqPf2ztDWponBQP9DbqQ0X7ziHQ+oPsA4UQz/4DBJ45NR7mK9GWmyiNnUrNFC93vjNH9lWzoNpCuQD/tyVK1ugu6Nv1yUpg==
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=rBg1GI8FCLpMscdW2J9HqNEUHrSn9/GG3bQ9x6CfDS8=; b=KLXVOOXoc1IBYreslZ6eOqaiLoEFF/xUs/A9xPA9geI8EvXzc1SSgSnIflbJtAyGG2ftxddX6E+CgH3BwmRmhi83ShJ56/9vbT91zeNMKqmtAaF0MWP+uLkfMCn6ByqXVL1aRt3ma1FBBL0JT6c3y3dvauLhI3RfGhEO15/cczhSyMd9w8mvm6b4jO0dUmZpoc3p+ERvyZbFKfx3cZsukah6asZiyCwBjYWBLJuTd2yd2poIS17ywJXdI/WcsIyPt59V7O8bWLQeAaTDFmDeXrXWoYDZSdQibzle/5NWhnV5CVg6xMkFsz46HujC4nxbPnPKRe3O22vCeaNiPBUGNQ==
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=rBg1GI8FCLpMscdW2J9HqNEUHrSn9/GG3bQ9x6CfDS8=; b=XeeLc5mLHXkpRQeLa/zB/3dAMQo669gz6jVYVL8oC36kMWWphq14ax4KKfoVKSNUmy7GeUWVVVbQ0uiUMewNBrkfjKhpSgRSzaM60+OPYijOsYf5RPwg52RUSa4sAG8carfWbimyJlISXYrxcDfFNoNGCW8mEKCi1hYtTznwbI4=
Received: from VI1P18901CA0010.EURP189.PROD.OUTLOOK.COM (2603:10a6:801::20) by AM7P189MB0757.EURP189.PROD.OUTLOOK.COM (2603:10a6:20b:114::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2199.21; Tue, 27 Aug 2019 06:52:25 +0000
Received: from HE1EUR02FT021.eop-EUR02.prod.protection.outlook.com (2a01:111:f400:7e05::208) by VI1P18901CA0010.outlook.office365.com (2603:10a6:801::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2199.15 via Frontend Transport; Tue, 27 Aug 2019 06:52:25 +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 HE1EUR02FT021.mail.protection.outlook.com (10.152.10.85) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.20.2199.13 via Frontend Transport; Tue, 27 Aug 2019 06:52:24 +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, 27 Aug 2019 08:52:23 +0200
To: Jim Schaad <ietf@augustcellars.com>, 'Benjamin Kaduk' <kaduk@mit.edu>
CC: <draft-ietf-ace-cwt-proof-of-possession.all@ietf.org>, <ace@ietf.org>
References: <20190730155605.GM47715@kduck.mit.edu> <92fc4816-3447-62e3-e2fa-e6d92ea772e3@ri.se> <20190812231518.GF88236@kduck.mit.edu> <caa055a8-cc1a-7341-3f5c-5c988056de45@ri.se> <00dc01d55c28$5860e510$0922af30$@augustcellars.com>
From: Ludwig Seitz <ludwig.seitz@ri.se>
Message-ID: <4581be90-4cb1-3bce-0a5f-6c494e205442@ri.se>
Date: Tue, 27 Aug 2019 08:52:23 +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: <00dc01d55c28$5860e510$0922af30$@augustcellars.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms040102000403000107040704"
X-Originating-IP: [10.100.0.158]
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)(376002)(136003)(39860400002)(396003)(346002)(2980300002)(199004)(189003)(14444005)(86362001)(7736002)(5660300002)(305945005)(186003)(16526019)(31686004)(2171002)(2906002)(5024004)(4326008)(356004)(36756003)(16586007)(235185007)(106002)(336012)(476003)(81156014)(8676002)(44832011)(76176011)(229853002)(22746008)(6246003)(126002)(8936002)(40036005)(486006)(2616005)(568964002)(22756006)(446003)(11346002)(478600001)(26005)(53936002)(3846002)(316002)(6116002)(58126008)(81166006)(31696002)(70586007)(110136005)(53546011)(70206006)(386003)(54906003)(16576012)(65806001)(6306002)(66574012)(65956001)(33964004)(71190400001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM7P189MB0757; 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: d02596ce-967e-486b-2e2d-08d72abb1e40
X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600166)(711020)(4605104)(4709080)(1401327)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:AM7P189MB0757;
X-MS-TrafficTypeDiagnostic: AM7P189MB0757:
X-Microsoft-Antispam-PRVS: <AM7P189MB0757C09D2D88648F205BFF8082A00@AM7P189MB0757.EURP189.PROD.OUTLOOK.COM>
X-MS-Oob-TLC-OOBClassifiers: OLM:10000;
X-Forefront-PRVS: 0142F22657
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam-Message-Info: cRdpDbQNABGITcO6KZcigvY1BRaHXOrIId3HDqRievLgqweUeVILuDAL6EO+h5di+Qle9dmp/rmuejGqx26hxkv9uhT7FfwKHnmw4hhBwIpGsxo9BO8SHWhPvd6c5gBk9t0/oIm3f2Go2e24ecljp8FHCZ/8c/8ayjRpLuR/p/GpOeobkPsw/Egz7JZCSYiADa0wBd8DKF4v7ppcifwyCtNj4xjjyzmF9jVn8JJEz5d5zzZQzXBXFyPwgaIO4QlTui5B80WjKTUuJQt67UVn89b5nfnmIYh0s7XQGHAPQ2VUVCqQVQD/ANr5XiZrsrGmPvf+/NQtHY2AY6MaF95bV2pMVobuWBP5Nueto9KLQ0cu6qf8JpZ1If041rWSfXmJenT0OapjktmuNyoMKRMjaHHanixQL0uJ1eHmOZQBDPs=
X-OriginatorOrg: ri.se
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Aug 2019 06:52:24.9006 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: d02596ce-967e-486b-2e2d-08d72abb1e40
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: AM7P189MB0757
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/S9WuFOXrYAUHe2_s4EX3YoOEmWY>
Subject: Re: [Ace] AD review of draft-ietf-ace-cwt-proof-of-possession-06
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, 27 Aug 2019 06:52:33 -0000

On 26/08/2019 18:07, Jim Schaad wrote:

> On 13/08/2019 01:15, Benjamin Kaduk wrote:
> 
>>>> The "COSE_Key" member MAY also be used for a COSE_Key
>>>> representing a symmetric key, provided that the CWT is
>>>> encrypted so that the key is not revealed to unintended
>>>> parties.  The means of encrypting a CWT is explained in
>>>> [RFC8392].  If the CWT is not encrypted, the symmetric key MUST
>>>> be encrypted as described in Section 3.3.
>>>> 
>>>> It's hard for me to escape the conclusion that this paragraph
>>>> needs to be a dedicated section with a bit more discussion
>>>> about how exactly this usage is performed and encoded.
>>>> 
>>> 
>>> This mirrors the corresponding procedure in RFC 7800. Would it be
>>> OK to just refer to that document 
>>> (https://tools.ietf.org/html/rfc7800#section-3 or actually 3.3)?
>> 
>> (Section 3.2, it seems -- JWT and CWT cover aysmmetric and
>> symmetric in the opposite order.) Well, I still wouldn't like it.
>> But I don't think I have grounds to block the document from
>> advancing if you just refer back to JWT.
>> 
> 
> Göran and I have discussed this, and we agree that it is indeed 
> underspecified (e.g. which key is used to encrypt this "inner" 
> COSE_Encrypt0 contained in the cnf element?). Additionally I can 
> personally confirm that this is a headache to implement (and I
> haven't even touched a constrained implementation).
> 
> [JLS]  I am not sure that I understand why you believe that this is
> underspecified. 

Because the AD said so ;-)

Seriously: I believe that this warrants more text, since it must be at 
least clarified that this construct assumes two pre-configured keys 
shared between AS and RS: one for encrypting the inner cnf element and 
one for integrity protecting the whole CWT.

> Despite the fact that I have not implemented this, I
> do not believe that it would be all that problematic to implement in
> general, and would be even easier to implement in a constrained
> system as only one format of CWT should ever be expected by a single
> small device so that the structure can be hard coded.

Perhaps 'headache' was a hyperbole on my part, but there is definitely a 
code-complexity difference between "parsing CBOR" and "parsing CBOR, 
interrupt the parsing to decrypt stuff, continue parsing CBOR".

> [JLS] There is a potential case for the first of those options,
> having different authority servers that are passing things back and
> forth and a desire to do validation that the correct permissions
> exist.  That is the client AS sends a request to the Resource AS
> which creates a token for the RS and the client AS wants to double
> check the permissions granted to the client.  But I have not heard
> that anybody is planning to do such an implementation yet.  So far
> everybody is combining the two AS roles into a single system.  If you
> are ever in the second case, I would argue that you are better off
> using asymmetric keys all the way around.

I can see this use case. That rules out my option 1. of removing this 
construct.

/Ludwig

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