Re: [Rats] comments on draft-birkholz-rats-uccs

Jeremy O'Donoghue <jodonogh@qti.qualcomm.com> Mon, 09 November 2020 16:39 UTC

Return-Path: <jodonogh@qti.qualcomm.com>
X-Original-To: rats@ietfa.amsl.com
Delivered-To: rats@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7434E3A11B5; Mon, 9 Nov 2020 08:39:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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=qti.qualcomm.com header.b=I1Njk6ju; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=qualcomm.onmicrosoft.com header.b=oOzhkFTy
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 bffqIiuk2FyA; Mon, 9 Nov 2020 08:39:04 -0800 (PST)
Received: from alexa-out-sd-02.qualcomm.com (alexa-out-sd-02.qualcomm.com [199.106.114.39]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11F663A044E; Mon, 9 Nov 2020 08:38:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1604939943; x=1636475943; h=from:to:cc:subject:date:message-id:mime-version; bh=Pe8apHXgoWxOkh3hTxFrikn2DkQAtyPpnO9/1toIK6s=; b=I1Njk6ju8IXxRT3VPmTRm/pN4aXxra9k3ujOPhHt/mbNS0vy4P2ATcNS jh++UXSogoYTxa6BeVEwZKxVRxQHQmfpFyA9StCa/vi14eaV4N1q5gN2K bnZxaPtgHvESL8zuNeTeZjiScl81dZpgESMpy1ncNkatlvoKwvCTiaUu7 4=;
Received: from unknown (HELO ironmsg05-sd.qualcomm.com) ([10.53.140.145]) by alexa-out-sd-02.qualcomm.com with ESMTP; 09 Nov 2020 08:38:59 -0800
X-QCInternal: smtphost
Received: from nasanexm03a.na.qualcomm.com ([10.85.0.103]) by ironmsg05-sd.qualcomm.com with ESMTP/TLS/AES256-SHA; 09 Nov 2020 08:38:58 -0800
Received: from nasanexm03b.na.qualcomm.com (10.85.0.98) by nasanexm03a.na.qualcomm.com (10.85.0.103) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 9 Nov 2020 08:38:58 -0800
Received: from NAM12-DM6-obe.outbound.protection.outlook.com (199.106.107.6) by nasanexm03b.na.qualcomm.com (10.85.0.98) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Mon, 9 Nov 2020 08:38:57 -0800
Received: from CY4PR0201MB3588.namprd02.prod.outlook.com (2603:10b6:910:93::25) by CY4PR0201MB3587.namprd02.prod.outlook.com (2603:10b6:910:8c::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3541.22; Mon, 9 Nov 2020 16:38:55 +0000
Received: from CY4PR0201MB3588.namprd02.prod.outlook.com ([fe80::e9ec:4397:4ba4:baec]) by CY4PR0201MB3588.namprd02.prod.outlook.com ([fe80::e9ec:4397:4ba4:baec%3]) with mapi id 15.20.3541.024; Mon, 9 Nov 2020 16:38:55 +0000
From: Jeremy O'Donoghue <jodonogh@qti.qualcomm.com>
To: Henk Birkholz <henk.birkholz@sit.fraunhofer.de>, "jmfmckay@gmail.com" <jmfmckay@gmail.com>, "rats@ietf.org" <rats@ietf.org>
CC: "jmfitz2@cyber.nsa.gov" <jmfitz2@cyber.nsa.gov>, "ietf@augustcellars.com" <ietf@augustcellars.com>, "draft-birkholz-rats-uccs@ietf.org" <draft-birkholz-rats-uccs@ietf.org>
Thread-Topic: [Rats] comments on draft-birkholz-rats-uccs
Thread-Index: AQHWtqX/fGyctUruJkSdhby379olcg==
Date: Mon, 9 Nov 2020 16:38:55 +0000
Message-ID: <CY4PR0201MB35886059C406E707EC9F11AEF2EA0@CY4PR0201MB3588.namprd02.prod.outlook.com>
Accept-Language: en-GB, en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: sit.fraunhofer.de; dkim=none (message not signed) header.d=none;sit.fraunhofer.de; dmarc=none action=none header.from=qti.qualcomm.com;
x-originating-ip: [163.116.162.115]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: a189ad36-630d-48c3-2c04-08d884cdf35f
x-ms-traffictypediagnostic: CY4PR0201MB3587:
x-microsoft-antispam-prvs: <CY4PR0201MB35877B6FCB3EB3242DE1667BF2EA0@CY4PR0201MB3587.namprd02.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:8882;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: kkjNEL1GtEbBLGKDstAqBixZ/zGibvz46HEmXIhSXctfmxJgCduJi/xEFYH1vwMzQ+M5ZPL11XeJaRm+weeMxPkn4gpyRy27jSbmxM1Uazr+los1bV0nC/kA/KYvpRHo5sNDjNd4KHt5GYiL52jWPEJUmp5tDkBDYwc3KsjVTm6YZ0FMj4kM6kMexVMTteDccGFMKG43RIlW80YcghoZu6gp1JXkP8fSlNK1MjoFEEh3xmouQww4VZPLig+BlMIMAA4soprEavaizW5k9V8/tlh4SwEN6Mxd0rbHTu2kDAHfWPdXzz03lmia+CT0KQeTFCF6gkJUiCheFjMA5/DO9H0LWY1NoYxUTj4qdUkawiDeEWVcp0d+rnVhDid4h+AZYRCIf0/rI1CcC1vG3z5Z1g==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CY4PR0201MB3588.namprd02.prod.outlook.com; PTR:; CAT:NONE; SFS:(376002)(396003)(346002)(136003)(39860400002)(366004)(186003)(83380400001)(316002)(71200400001)(9686003)(6506007)(7696005)(966005)(91956017)(55016002)(2906002)(5660300002)(8676002)(8936002)(66946007)(53546011)(52536014)(64756008)(26005)(166002)(66476007)(478600001)(66446008)(33656002)(110136005)(66556008)(76116006)(54906003)(4326008)(86362001); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: 1j7KKMeMx8tBuiLX4Jft/94odbAuOj5f5pUFP8tKGo9uN73qUGiSBtbWqEGiD4COUGzVPlDwmE3t0lJ1b7dD1aHxKmz9goygtYGpCowdgC7CtROeZ1HmiQUVuLUuYFDHeVmRKTCPHeKBKoUBbQduqNAFb60GUZumTcWRIoyBYTIGA2Mmt0iD2WqfaXzHMml0mvic8DVLhH3v10AeemWiflPRoUi+u5mokp8ZVAK/SysSFvhjWOSNlPsHnMROB45/seCiVk5CIg7IjEMq68qWRapsI2S2rp1z7YpwLj8bq7bUFZhIZgdMTSBm13S+54RaCSlI1hDx+dVYSm8eBvqhNCAuIX8PQ7ZLYN3rb8zA8nZPttN4yG07iW7Mh1RrBM8h1k4WLglepyTawAEL7gTdvFbF3GZv/UCTN8ZZ6XzISp9gByRcWCml/adycKea2/58HRAJoJwxGfcWmO3QriVcf1zbeazB2RKFW4/1+NzN1fSQ1osCcJubaEDHEOJ3Waf1DSstFg1nmn89FeanCf7ESASck5zs2+gyKaBg8OUe5RG1FJOYeh7JSdsX+qSXb9C2XLCWzqT5IVCVbTCHf1LrIHc+SlqDKWMSoU9ZxVjAC3RftKf09FBEkBDRfmthB2avAUSeLy6aHndzdmmxo96q59J3rLEjQesbuyuozRpYwDXaWoNf/EmxKJ1LkBU47dr1VlhlzRQwm/hUgOnwGXLtZcgUpZfIqzMn6WrX2WJReVAEA1pVzsBsp7omPOEMitZcKLGLHgXojVlu8maiirDtfN+ZRx+CBrxOCcjSRs/9GJ2Yude8qAVTs426hHjB2ilrzbQxwXnfedHXngy/VRpHFwzaR0iiNcg7ORc+uiTBiAKhTd5HWZwPg13mT5ZtNHDH7pCSeeGZL6O3R51yh06vkA==
x-ms-exchange-transport-forked: True
arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=QZ1bkRQKFo9/ur3LKuclwVPk9ch0lIRtDfP6JHbQvPYlbKu7MvwmXPEqtI0SS9UKfg1G7EunjxOjFERYm+wVoqqLXV5qB+rkdYvAI+4Lxg473N5HtBHc6qUsyzPfm0horp0CKzafUcbAeFohVVA3U75OIw7CQ+K7yNBUZ5OHJ+4vcNlidOWEvxgPmHqY4bB8EFbCSLvhE7bLQKpe6UW5nJVLnUzDt9Kmij8MAZZvtgn2zJ9g9k2lpPDX5gRO5bIcdakdRWWMEkO5Lnoay9Oz3qjC9UouxDvXTY3bv7hM0X2z7464AZxeePaH38b8oO+L6NSuIP741WpVSuNbF6TREw==
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=ZiFXpGmEz3mXn5MGnB0xPLauH0PTNRnk+5O1GStgEWg=; b=B65O9nS6gHToqwJKCOwWZxGwJmG3ZWoCkluf9a9kMmthqe6rBu1+p6acA1LHYlbaXTW+phevSF9+EIkDiTdOdM3iHsECqsOpCUNadXYDGqmkwgjlQoPd+mBYy1DxMXIq8Wf4J1A/XPn534ol8tufXhBaL1bL2G20c+2jSDNjcciMn6J9xkg+LJFSeRj64GRl1C+p2+dWKKpMoFBoPpRfGWgktZmvoNo8UP2c97+JwT7a0R2eUAQPcVnBJTqe7Q6+E+Q0UobcioBqh7SRODsu9TXjsMyrGYP3fww4/y1LdsNIE6odmAJ4K/YRwup+s1CwsCcQv5kDNdijblYnQXo84A==
arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=qti.qualcomm.com; dmarc=pass action=none header.from=qti.qualcomm.com; dkim=pass header.d=qti.qualcomm.com; arc=none
dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qualcomm.onmicrosoft.com; s=selector1-qualcomm-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ZiFXpGmEz3mXn5MGnB0xPLauH0PTNRnk+5O1GStgEWg=; b=oOzhkFTypSFmlaXqBAJCQVLS1w5bCpxtuqZl+Ti2JP1Hey86gcpW2yrH5RXdaeHsr5Lkn9rMzPuwuJsq9nfrqGYr+fKNeYj0HQPxAMt3JkSnaQSTuubngOe40C/064A1rSrtUAmsaZKSrHE7TShFC+XP5zkmR+IfqqPRERbFp7k=
x-ms-exchange-crosstenant-authas: Internal
x-ms-exchange-crosstenant-authsource: CY4PR0201MB3588.namprd02.prod.outlook.com
x-ms-exchange-crosstenant-network-message-id: a189ad36-630d-48c3-2c04-08d884cdf35f
x-ms-exchange-crosstenant-originalarrivaltime: 09 Nov 2020 16:38:55.8028 (UTC)
x-ms-exchange-crosstenant-fromentityheader: Hosted
x-ms-exchange-crosstenant-id: 98e9ba89-e1a1-4e38-9007-8bdabc25de1d
x-ms-exchange-crosstenant-mailboxtype: HOSTED
x-ms-exchange-crosstenant-userprincipalname: 5fSeajhM5XfctrhR0E+ZRtZmbOgifyhBZQnIpz/vq0kuygdR25E5U0XJy/0adhyVA34kI0vjvVvM/3f5lZKM34onshb3T1ll4USJjdUfwGk=
x-ms-exchange-transport-crosstenantheadersstamped: CY4PR0201MB3587
x-originatororg: qti.qualcomm.com
Content-Type: multipart/alternative; boundary="_000_CY4PR0201MB35886059C406E707EC9F11AEF2EA0CY4PR0201MB3588_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/QT4JUahSfqqcXjexzpiAPD7zKho>
Subject: Re: [Rats] comments on draft-birkholz-rats-uccs
X-BeenThere: rats@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Remote ATtestation procedureS <rats.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rats>, <mailto:rats-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rats/>
List-Post: <mailto:rats@ietf.org>
List-Help: <mailto:rats-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rats>, <mailto:rats-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 Nov 2020 16:39:06 -0000

Hi all,

Apologies for a very late response to some of the issues raised below.

Best regards

Jeremy

Jim Schaad <ietf@augustcellars.com> Mon, 17 August 2020 20:14 UTC

-----Original Message-----

From: Henk Birkholz <henk.birkholz@sit.fraunhofer.de<mailto:henk.birkholz@sit.fraunhofer.de>>

Sent: Monday, August 17, 2020 3:49 AM

To: Jessica Fitzgerald-McKay <jmfmckay@gmail.com<mailto:jmfmckay@gmail.com>>; rats@ietf.org<mailto:rats@ietf.org>

Cc: Jessica Fitzgerald-McKay <jmfitz2@cyber.nsa.gov<mailto:jmfitz2@cyber.nsa.gov>>; Jim Schaad <ietf@augustcellars.com<mailto:ietf@augustcellars.com>>; draft-birkholz-rats-uccs@ietf.org<mailto:draft-birkholz-rats-uccs@ietf.org>

Subject: Re: [Rats] comments on draft-birkholz-rats-uccs



Thanks Jess!



the discussion on where this is incubated was deliberately scoped down to provide:



* a finite and still useful set of Security/Privacy considerations, and

* relatively specific guidance and context on how prerequisites for usage look like.



The concept of an UCCS tag goes beyond RATS, of course. The usage of an UCCS tag alas requires some application-specific "rules".



That said, we will discuss this topic specifically asap. Also, Jim is now in CC (Hi Jim) and maybe he can weigh in on this topic?



With respect to your technical comments, please give us some time to come back with well-formed answers. I do not want to barge ahead with half-baked replies :-)



Viele Grüße,



Henk



On 07.08.20 16:01, Jessica Fitzgerald-McKay wrote:

> Hi, UCCS authors,

>

> Mike Jenkins and I reviewed the UCCS draft. Our comments are below.

> Happy to talk through any of them with the group.

>

> Thanks,

> Jess

>

> The intent of this draft is similar to the key concept of EST - use

> the authentication of the secure session connection. Most schemes

> build on this concept leave a lot of banana peels laying around, some

> of which we describe here. In general, this does not seem appropriate

> to the scope of RATS. We feel that COSE might be a more appropriate

> work group to think these issues through.





[JLS] To me COSE is exactly the wrong place to do this.  If it is not done in RATS then ACE would be the appropriate location.  Doing it in COSE would be something along the lines of "If you don't use the core technology of this group then you should?"



>

> - If you're using a static symmetric key for authentication (as one

> might with highly-constrained devices), you can only authenticate a

> net, not an entity. The receiver cannot differentiate between

> authenticating the sender and authenticating itself.



[JLS] I don't see this as being interesting for this document  The exact same set of problems exist if you use HMAC or symmetric encryption with COSE where a static symmetric key is used.  The thing that might be interesting would be to talk about correspondences of the secure channel security and the equivalent COSE objects.



[JOD] I prefer to focus on the security UCCS over a Secure Channel in comparison

To COSE as Jim suggested – this seems reasonable approach. Since

ID.ietf-cose-rfc8152bis-struct and ID.ietf-cose-rfc8152bis-algs have

extensive security considerations. I have proposed text modelled on the

structure used in I-D.ietf-cose-rfc8152bis-struct and

I-D.ietf-cose-rfc8152bis-algs.



>

> - The authentication happens at the secure channel termination, not in

> the channel-contents-using application. It's important how the

> termination process vouches the authentication to the application. (In

> EST, this question is how the EST server vouches the requestor's

> identity to the CA server.)

>

> - A TEE only helps if the TEE application can punch through the REE

> and set up the secure channel completely on its own. If the TEE relies

> on the REE to set up the secure channel, you might as well just

> operate in the REE.



[JOD] Given the many ways in which Secure Channels for UCCS can be implemented, I suggest

including text that indicates the need for the Secure Channel and Attester to exist within

a common security environment.



Text could read along the lines of:



“A Secure Channel established or maintained using weak cryptography, or that exists in a

different security context to the Attester, may not provide the assurance required by a

relying party of the authenticity and integrity of the UCCS.”



>

> - There is a comment at the end of the introduction (!) about

> transitioning back and forth between self-protected and

> channel-protected CWT, "in a well-defined scope". Define the security

> characteristics of that scope or get rid of the comment. You're

> handing someone an awful lot of rope there.



[JOD] This text has been deleted.



> - The claims set should be treated as ephemeral by the recipient. It

> shouldn't be stored, and can't be forwarded except as data originated

> by the recipient. As soon as it emerges from the secure channel, it's

> no more valid or meaningful than any other piece of unprotected data

> in the application environment.



[JOD] Proposed text:



“When UCCS emerge from the Secure Channel and into the Verifier, the security

properties of the Secure Channel no longer apply and UCCS have the same properties

as any other unprotected data in the Verifier environment.



If the Verifier subsequently forwards UCCS, they are treated as though they

originated within the Verifier.”



> _______________________________________________

> RATS mailing list

> RATS@ietf.org<mailto:RATS@ietf.org>

> https://www.ietf.org/mailman/listinfo/rats

>


--
Jeremy O’Donoghue
Director, Secure Systems Group, Farnborough, UK
jodonogh@qti.qualcomm.com