Re: [Ace] [Cbor] [Rats] RATS Entity Attestation Tokens (EAT) - to be a CWT or not to be a CWT?

Laurence Lundblade <lgl@island-resort.com> Tue, 21 April 2020 16:07 UTC

Return-Path: <lgl@island-resort.com>
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 17AE23A0D75 for <ace@ietfa.amsl.com>; Tue, 21 Apr 2020 09:07:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.894
X-Spam-Level:
X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 y3cN70o6KT-4 for <ace@ietfa.amsl.com>; Tue, 21 Apr 2020 09:07:41 -0700 (PDT)
Received: from p3plsmtpa07-06.prod.phx3.secureserver.net (p3plsmtpa07-06.prod.phx3.secureserver.net [173.201.192.235]) (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 038A93A0E99 for <ace@ietf.org>; Tue, 21 Apr 2020 09:07:22 -0700 (PDT)
Received: from [192.168.1.78] ([76.167.193.86]) by :SMTPAUTH: with ESMTPA id QvQfjZ4Pn4NFGQvQgjCxdo; Tue, 21 Apr 2020 09:07:22 -0700
X-CMAE-Analysis: v=2.3 cv=EPx4LGRC c=1 sm=1 tr=0 a=t2DvPg6iSvRzsOFYbaV4uQ==:117 a=t2DvPg6iSvRzsOFYbaV4uQ==:17 a=0XtbOteLAAAA:20 a=K6EGIJCdAAAA:8 a=gKmFwSsBAAAA:8 a=QyXUC8HyAAAA:8 a=48vgC7mUAAAA:8 a=WMtHHQaCRWcHGEDLbcIA:9 a=QEXdDO2ut3YA:10 a=UcTN6IUWVUINGMuQfjEA:9 a=4RQ5A1VLkLRPNQEQ:21 a=_W_S_7VecoQA:10 a=L6pVIi0Kn1GYQfi8-iRI:22 a=nnPW6aIcBuj1ljLj_o6Q:22 a=w1C3t2QeGrPiZgrLijVG:22
X-SECURESERVER-ACCT: lgl@island-resort.com
From: Laurence Lundblade <lgl@island-resort.com>
Message-Id: <F9BAEEF8-0CB4-4C2A-B6DD-648C330B3B64@island-resort.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_F9907CDF-6DAB-451F-93E9-2F24DC401FDA"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Tue, 21 Apr 2020 09:07:21 -0700
In-Reply-To: <3F7E9A70-18BE-454C-A5EB-F07A1EDFE7DC@island-resort.com>
Cc: "Smith, Ned" <ned.smith@intel.com>, Henk Birkholz <henk.birkholz@sit.fraunhofer.de>, "rats@ietf.org" <rats@ietf.org>, Jim Schaad <ietf@augustcellars.com>, "cbor@ietf.org" <cbor@ietf.org>, Ace Wg <ace@ietf.org>
To: Carsten Bormann <cabo@tzi.org>
References: <b1e8d7f6-426a-6b71-dc6e-62b1ef41e297@sit.fraunhofer.de> <00d501d5f26d$c34454d0$49ccfe70$@augustcellars.com> <12861.1583448208@localhost> <51BE3C8D-6AC9-424F-8600-57ADCAF9CEF5@intel.com> <017f01d5f35d$2c422c60$84c68520$@augustcellars.com> <c2d851ab-e5f6-8f4b-9602-2801e6127196@sit.fraunhofer.de> <01ae01d5f3eb$4a670fb0$df352f10$@augustcellars.com> <CF21A694-BCCF-416A-9A46-4BAA230662C8@tzi.org> <D168A416-F4D3-405B-95DF-8CF1BAD63DF6@intel.com> <D8D8887D-2B73-4764-A974-5F681B5BA3DA@tzi.org> <3F7E9A70-18BE-454C-A5EB-F07A1EDFE7DC@island-resort.com>
X-Mailer: Apple Mail (2.3445.104.11)
X-CMAE-Envelope: MS4wfF4SID21nOVc+Hqcj19ynLHV7g/QQGgOBc80lxQWhb31uVS8bzgJSRGrKKs5kEBtve7L9ao0lrmNkaN48tHAnA5q2mNwC1+caCmrbjyHqHFeZiK3ki3y AsrRKKAJLFnqgBOGaz4Q+lYRnF3ZS1x6YAaqpVG12nt8gqEcUZWdL14DFJDzLzjDg/+07PQ9+U+GHtJG7cgWYprmER7jUMINTAjlS38PFS1M5p9pCOqbq3dV hHcqjtdS/d92ofjRftV5b++eMz48n6u+QrrwxO+MxqsKJM2+QAvk1d1ADxIA8R2BjNZvjFkIgP2v34OZGtz202KV96LVfH0jfjtJiUpaPsQ=
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/mtPOTZkSBk6p2DxB-Jqn1WIqgog>
Subject: Re: [Ace] [Cbor] [Rats] RATS Entity Attestation Tokens (EAT) - to be a CWT or not to be a CWT?
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, 21 Apr 2020 16:07:44 -0000

I have created a PR <https://github.com/ietf-rats-wg/eat/pull/62> against the EAT draft for UCCS and UJCS.  I’m not sure this really belongs in the EAT draft, but I thought I’d start by putting it there.

LL

P.S. If we were do an update to CWT to accommodate this, it would also be good to add CDDL describing CWT. That is another thing I’ve got in the EAT draft, that probably belongs elsewhere.



> On Mar 6, 2020, at 6:27 PM, Laurence Lundblade <lgl@island-resort.com> wrote:
> 
> Pretty sure UCCS as Carsten describes below works for me provided:
> 
> - All the rules and requirements from CWT explicilty apply except signing/encryption
> - It uses the same registry
> - There is a tag defined for it
> - You get an (untagged) UCCS when you remove all signing and encryption layers
> 
> LL
> 
> 
>> On Mar 6, 2020, at 12:04 PM, Carsten Bormann <cabo@tzi.org> wrote:
>> 
>> Hi Ned,
>> 
>> What I was trying to say is that the Unprotected CWT Claims Set (UCCS) is not a CWT, but an UCCS.  So I wouldn’t call it a token (which implies some form of protection to me).  But it is still a useful data structure to carry around.
>> 
>>> On 2020-03-06, at 20:59, Smith, Ned <ned.smith@intel.com> wrote:
>>> 
>>> The earlier thread suggested that a naked token could be given to a parser that was programmed correctly and it would 'just work'. But if the definition of a CWT/JWT is that it must have bounding signature, mac, encryption enveloping, then the parser should reject naked tokens (tagged as such or not). 
>> 
>> A CWT decoder would diagnose an UCCS as “not a CWT”.
>> A CWT/UCCS decoder would diagnose it as “UCCS”.
>> 
>>> If the naked token is defined and the map has a tag that indicates it was formed without secure enveloping then the parser should accept it, but the code using the parser needs to find some other way to ensure security. 
>> 
>> Right.  An UCCS is only a useful assertion if received over a secure channel with the right properties to make it a useful assertion.
>> 
>>> If a parser receives a map with both security enveloping and the naked token tag, then it should return both the map and the security envelope context and let the code using the parser decide if the security context satisfies the security requirement.
>> 
>> Well, it should diagnose this as “not a CWT” (and not an UCCS either).
>> 
>> Grüße, Carsten
>> 
>> _______________________________________________
>> RATS mailing list
>> RATS@ietf.org
>> https://www.ietf.org/mailman/listinfo/rats
> 
> _______________________________________________
> CBOR mailing list
> CBOR@ietf.org
> https://www.ietf.org/mailman/listinfo/cbor