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

Ludwig Seitz <ludwig.seitz@ri.se> Mon, 26 August 2019 06:40 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 1EDB61200A4; Sun, 25 Aug 2019 23:40:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 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] 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 FOLs_MfYAgcF; Sun, 25 Aug 2019 23:40:00 -0700 (PDT)
Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30045.outbound.protection.outlook.com [40.107.3.45]) (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 A2A661200D7; Sun, 25 Aug 2019 23:39:58 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=lYVKgEslSbUP/B1Y2wqkrfz/6fIs1R30RSY2J8z6OsGAgIlGvSNQdqCS0bDO+gMUMB0Hr2pu1iDKkdWjaDCJ/ZrRUmfWe1L4XwZRv+b7aFaLVhtKOJKmtYh53UWohvb4QxJSWnHrtOZriUFADf3Uud6/ENCfzzhKtlbTy3CuuNwcpauMOr2+8cbmmpeoCCfJiwvt9soLf4yryW+iTUmjNmT8HRTKPF6aq6yEaxGuEWZ4N42M3kxoLdmsyDOnAP61x5HDIyPWZeuHU5LmM26tRq2L6LF1mHnXwQVIsZWE1Q5NOzWOyQZ9tO55+EgroT/PWd1rGx7q2gm4PCJnW/d3qw==
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=i5nNWjgDpf+mKEq0nzgfkKuRQNnteSpHLRDe/rWnn7A=; b=SUUr6ZWMNpe87IScVzUNb+F/QFBGDbOHoXNuJetWmB08gFQlZ5PnMci5GFCYgonKox+US0LhfSLt3b0Rr5ozjBQx3STu3bD4LVdWPrX2z/IMFZvDHtuT114FMCuOyv9OLGCWf7rSFt2t19b8L9s2wvkcSoPxe+u61rfmJR00VQBfd1oPawmSyNg3jqzgz5+UMjNLq4vfvZQuJ7lrRwD2jxV7xcqW/NY/Z219PXa4clgSFfEdfuSD1V/XEZPy/koETN1PYLXM4UyZBNxQljZOd45E6vUXdZEsCxBA8RG41c5ri10pZ7floa7cjhfOxq4frqFBiIfRqxVo3hIYh8Dfsw==
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=i5nNWjgDpf+mKEq0nzgfkKuRQNnteSpHLRDe/rWnn7A=; b=ewDwxHxKEHO0LzDALbtSqcPF8/5sf5crxFHW4KfvYrVSOE7pqnhKQLtEOUmQltiPi63EzkT4CT5VApPVZ7k2T77UxT7aTblcjn1wxAbYdeNwthf4F7hroxiDTpTHscJ+kGQZBPXM+vCRRTedFfmd6SNQBfzTQQr5uBpNYEf+D14=
Received: from HE1P189CA0014.EURP189.PROD.OUTLOOK.COM (2603:10a6:7:53::27) by AM5P18901MB0209.EURP189.PROD.OUTLOOK.COM (2603:10a6:203:6f::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2199.21; Mon, 26 Aug 2019 06:39:56 +0000
Received: from AM5EUR02FT040.eop-EUR02.prod.protection.outlook.com (2a01:111:f400:7e1e::209) by HE1P189CA0014.outlook.office365.com (2603:10a6:7:53::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.2199.14 via Frontend Transport; Mon, 26 Aug 2019 06:39:55 +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 AM5EUR02FT040.mail.protection.outlook.com (10.152.9.8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.20.2199.13 via Frontend Transport; Mon, 26 Aug 2019 06:39:55 +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; Mon, 26 Aug 2019 08:39:55 +0200
To: 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>
From: Ludwig Seitz <ludwig.seitz@ri.se>
Message-ID: <caa055a8-cc1a-7341-3f5c-5c988056de45@ri.se>
Date: Mon, 26 Aug 2019 08:39:54 +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: <20190812231518.GF88236@kduck.mit.edu>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms060608030101070009020000"
X-Originating-IP: [10.100.0.158]
X-ClientProxiedBy: sp-mail-3.sp.se (10.100.0.163) 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)(136003)(346002)(376002)(396003)(39850400004)(2980300002)(189003)(199004)(58126008)(16586007)(2906002)(81156014)(81166006)(40036005)(66574012)(54906003)(6306002)(229853002)(7736002)(36756003)(16576012)(22746008)(106002)(5660300002)(235185007)(31696002)(356004)(305945005)(26005)(16526019)(186003)(70586007)(22756006)(76176011)(53546011)(386003)(11346002)(5024004)(476003)(2616005)(44832011)(486006)(33964004)(65806001)(65956001)(14444005)(126002)(446003)(6116002)(2171002)(6246003)(966005)(336012)(70206006)(31686004)(3846002)(86362001)(6916009)(568964002)(4326008)(8676002)(8936002)(478600001)(71190400001)(53936002)(316002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM5P18901MB0209; H:mail.ri.se; FPR:; SPF:Pass; LANG:en; PTR:InfoDomainNonexistent; MX:1; A:1;
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 9cf06a50-5e6c-469f-225a-08d729f0353d
X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600166)(711020)(4605104)(4709080)(1401327)(2017052603328)(7193020); SRVR:AM5P18901MB0209;
X-MS-TrafficTypeDiagnostic: AM5P18901MB0209:
X-Microsoft-Antispam-PRVS: <AM5P18901MB0209614A2AD3E7C8A4591F3482A10@AM5P18901MB0209.EURP189.PROD.OUTLOOK.COM>
X-MS-Oob-TLC-OOBClassifiers: OLM:10000;
X-Forefront-PRVS: 01415BB535
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam-Message-Info: xVNlCBdHO4wX1OUofNy2BfGJNnwQIsk264kZvIBSO9O8RmVaBslldXqo6cHBrXxbtm1QtcPrSDd1tXqqRwePQ7SDyAY3VgX2+FgCFaNnnJN+lzWHF2jxWX6QuPPEm0PvT8QG0bOPLjW/tw36fbEf7mYtGiTwD9z343zCzkzRZOnZhtX+JfNNuMAFbeZ3rntc1reEdXVV/ar7EgZ3lkCoswQl+yvzmei8Gwej+APcdWF0qsRx1/IUJzbqCk1YInftVekg05nneFnR+lz2LZFWkBxi+H7dO9qqasigv/jSP9gNQcjZS106QiWU9IF/IAb4AQASaAwGBPfpXfckUgFS05gzwguD2ryn4XqTzw90rOEbFG71Gmvh8NCAZDWeHTOxrN2LQPDsL3Uf0EofWAtmXo4HqChxZJsx+nHhI6RwbUY=
X-OriginatorOrg: ri.se
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Aug 2019 06:39:55.7412 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 9cf06a50-5e6c-469f-225a-08d729f0353d
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: AM5P18901MB0209
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/BQmC0q8dnM4EJQOkes_zwN0zeog>
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: Mon, 26 Aug 2019 06:40:04 -0000

Hi Ben,

fixed more of your comments here: https://github.com/cwt-cnf/i-d/pull/24 
(waiting for Mike to double-check and merge them).

As for those that are still open, comments are inline.

/Ludwig

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).

We see two alternatives here:

1.) Remove the possibility to have a separate encrypted cnf element. 
Instead mandate that the whole CWT should be encrypted if it contains a 
secret key.

+ make spec easier (to implement) and doesn't requires a long 
specification on how to handle this case

- breaks direct equivalence with RFC 7800

2.) Add some dedicated section that explains how the key for this inner 
encrypted cnf element is selected and communicated to the RS.

+ The draft remains functionally equivalent to RFC 7800

- Increased draft complexity at questionable gain
- Possible implementer headaches, especially on constrained devices

There is an issue about this here:
https://github.com/cwt-cnf/i-d/issues/19


>>>      The following example CWT Claims Set of a CWT (using CBOR diagnostic
>>>      notation, with linebreaks for readability) illustrates the use of an
>>>      encrypted symmetric key as the "Encrypted_COSE_Key" member value:
>>>
>>>     {
>>>      /iss/ 1 : "coaps://server.example.com",
>>>      /sub/ 2 : "24400320",
>>>      /aud/ 3: "s6BhdRkqt3",
>>>      /exp/ 4 : 1311281970,
>>>      /iat/ 5 : 1311280970,
>>>      /cnf/ 8 : {
>>>      /COSE_Encrypt0/ 2 : [
>>>
>>> Should this be "/Encrypted_COSE_Key/" and not "/COSE_Enrypt0/"?
>>>
>>> [I did not validate the COSE_Encrypt0 output]
>>>
>>
>> COSE_Encrypt0 is a defined construct of COSE, while Encrypted_COSE_Key
>> is not. We'd have to define it or write an explanatory comment.
> 
> Maybe I'm confused about how the diagnostic notation works, but the
> top-level CWT map key name ("claim") is "Encrypted_COSE_Key", as matches
> iss/sub/aud/etc. in the preceding notation.  If the rules are different for
> map keys whose corresponding values are themselves structured data types,
> then I should just unconfuse myself and we can move on with things...
> 
>

Issue created here https://github.com/cwt-cnf/i-d/issues/20
Will fix.


>>
>>>      o  A recipient can decide not to use a CWT based on a created Key ID
>>>         if it does not fit the recipient's requirements.
>>>
>>> I'm not sure I understand the semantics being described here.  Are we
>>> saying that the issuer might give a presenter a CWT, and by the time the
>>> presenter presents the CWT to the recipient, the recipient says "this is
>>> no good" and denies the transaction in question, forcing the presenter
>>> to go back to the issuer and try again?  (How do we know that the issuer
>>> would make any different choices the second time around?)
>>
>> This risk always exists. In a constrained device world, the recipient
>> may already have cleared out the key referenced by the key ID, which
>> would force it to reject a CWT using this as proof-of-possession.
>>
>> I'm not sure how to give good guidance in this case. The error message
>> delivered by the recipient rejecting the CWT might be helpful I suppose.
>> Do you think this merits some text?
> 
> It's not entirely clear to me that we need to add more text here, but if we
> did, it would focus on what "decide not to use" means at a protocol level,
> and perhaps how the CWT might not "fit the recipient's requirements" (e.g.,
> the key id having fallen out of cache as you describe).

Issue created here: https://github.com/cwt-cnf/i-d/issues/21
Will fix.

>>
>>>      from changing any elements conveyed within the CWT payload.  Special
>>>      care has to be applied when carrying symmetric keys inside the CWT
>>>      since those not only require integrity protection but also
>>>      confidentiality protection.
>>>
>>> Do we want to reiterate the common mechanisms for providing
>>> confidentiality protection here, or just leave the existing text earlier
>>> in the document to cover it?
>>>
>> Doesn't it say a few sentences before: "it is
>>      necessary to apply data origin authentication and integrity
>>      protection (via a keyed message digest or a digital signature)." ?
>>
>> I would consider this to be enough.
> 
> That doesn't cover the *confidentiality* protection, specifically.  (So it
> seems the answer to my original question is still unclear, at least to me.)
> 

Issue created here: https://github.com/cwt-cnf/i-d/issues/22
Will fix.

> 
>>> Section 6
>>>
>>>      ensure correct processing.  The recipient needs to be able to use
>>>      credentials to verify the authenticity, integrity, and potentially
>>>      the confidentiality of the CWT and its content.  This requires the
>>>
>>> Just from a rhetorical point of view, can you help me understand how
>>> credentials would be used to verify the confidentiality of a CWT?  It
>>> seems like this depends on either (or both of) how the CWT is
>>> transmitted or how it is prepared, and I am not sure how the recipient's
>>> credentials come into play.
>>>
>>
>> This text is referring to the issuer's credentials (e.g. the
>> Authorization Server issuing the CWT), that the recipient needs to
>> verify the CWT. Do you want us to clarify this sentence?
> 
> Note that I was specifically asking about "potentially the
> confidentiality"; I don't understand the intended workflow for verification
> of confidentiality (and thus which credentials are involved).  I don't
> really see how a credential held solely by the issuer could proide
> confidentiality protection when it needs to be understood by some other
> protocol participant.

Issue created here: https://github.com/cwt-cnf/i-d/issues/23
Will fix.


>>> Section 7
>>>
>>>      Criteria that should be applied by the Designated Experts include
>>>      determining whether the proposed registration duplicates existing
>>>      functionality, determining whether it is likely to be of general
>>>      applicability or whether it is useful only for a single application,
>>>      and evaluating the security properties of the item being registered
>>>      and whether the registration makes sense.
>>>
>>> I know we've been using (variations of) this text for a while, but it
>>> seems to me that it could be more clear than it currently is -- is
>>> duplication of functionality grounds for denial of registration?  What
>>> about general vs. specific applicability?  The latter seems more clearly
>>> applicable for determining which range from which to allocate, since
>>> that has impact on the encoding size.  Can the experts insist on updates
>>> to the security considerations text of a specification prior to granting
>>> approval, or are they limited to denying registration of values with
>>> poor security properties or insufficient documentation thereof?
>>>
>>
>> I'm too unfamiliar with the designated expert system to provide a good
>> answer on this one. Can one of my co-authors chip in here?
>>
Issue created here: https://github.com/cwt-cnf/i-d/issues/25
Will fix.


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