Re: [Rats] EAT claims needed by TEEP

Laurence Lundblade <lgl@island-resort.com> Mon, 08 November 2021 21:20 UTC

Return-Path: <lgl@island-resort.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 4A9DD3A0889 for <rats@ietfa.amsl.com>; Mon, 8 Nov 2021 13:20:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 bNmgM6BMKG4b for <rats@ietfa.amsl.com>; Mon, 8 Nov 2021 13:20:21 -0800 (PST)
Received: from p3plsmtpa12-06.prod.phx3.secureserver.net (p3plsmtpa12-06.prod.phx3.secureserver.net [68.178.252.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 6FDB93A0888 for <rats@ietf.org>; Mon, 8 Nov 2021 13:20:21 -0800 (PST)
Received: from [192.168.1.3] ([75.80.148.243]) by :SMTPAUTH: with ESMTPSA id kC3wmV5KqSW1ckC3wmJjNN; Mon, 08 Nov 2021 14:20:20 -0700
X-CMAE-Analysis: v=2.4 cv=OaddsjfY c=1 sm=1 tr=0 ts=61899494 a=VPU1mRQhDhA4uSX60JRRww==:117 a=VPU1mRQhDhA4uSX60JRRww==:17 a=NEAV23lmAAAA:8 a=yMhMjlubAAAA:8 a=7CQSdrXTAAAA:8 a=K6EGIJCdAAAA:8 a=48vgC7mUAAAA:8 a=vfPLdMuGQczB4SoCKoUA:9 a=QEXdDO2ut3YA:10 a=_GvgsFb2-gyPJ0vh-tQA:9 a=egTMHxpTOfqEd1DY:21 a=_W_S_7VecoQA:10 a=a-qgeE7W1pNrGK8U0ZQC:22 a=L6pVIi0Kn1GYQfi8-iRI:22 a=w1C3t2QeGrPiZgrLijVG:22
X-SECURESERVER-ACCT: lgl@island-resort.com
From: Laurence Lundblade <lgl@island-resort.com>
Message-Id: <C9FCDB94-1734-4F6C-B6D9-DDB384827E06@island-resort.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_79E0AEEC-04A8-4425-A92B-D10C17AE5D2F"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\))
Date: Mon, 8 Nov 2021 13:20:20 -0800
In-Reply-To: <CH2PR21MB14640330E3DA58D2144659F7A3919@CH2PR21MB1464.namprd21.prod.outlook.com>
Cc: Giridhar Mandyam <mandyam@qti.qualcomm.com>, "rats@ietf.org" <rats@ietf.org>, teep <teep@ietf.org>
To: Dave Thaler <dthaler@microsoft.com>
References: <BL0PR2101MB102770B8E03B95A44497004CA3190@BL0PR2101MB1027.namprd21.prod.outlook.com> <7607E6BF-459C-4A32-AAE2-08117A97E06B@island-resort.com> <BL0PR2101MB1027EA205417DAF375BA7085A3160@BL0PR2101MB1027.namprd21.prod.outlook.com> <B1FDD70B-2530-454C-90AF-F44EEDC4F1F3@island-resort.com> <AM6PR08MB342916CCDD01E8698BB3C883EF170@AM6PR08MB3429.eurprd08.prod.outlook.com> <2D53BD60-4FA8-4153-B28B-585E902845AE@island-resort.com> <AM6PR08MB423141370A5CE9DEF6C732C69C140@AM6PR08MB4231.eurprd08.prod.outlook.com> <3370D92E-23C2-41C3-B86F-A65C168E9082@island-resort.com> <AM6PR08MB42311D76B24E866812171BDC9C140@AM6PR08MB4231.eurprd08.prod.outlook.com> <CH2PR21MB14640330E3DA58D2144659F7A3919@CH2PR21MB1464.namprd21.prod.outlook.com>
X-Mailer: Apple Mail (2.3608.120.23.2.1)
X-CMAE-Envelope: MS4xfEyrYgVPOYHWKs+pgYWIPeoAsW9wmeZEKFF9EmCTDMkud1cL2b12HMqVtYEamqAtp6ad9c6QmCIeS+rGLPB7UcsFtOzS7SQlY7Hf1+rAoDw3t/iPLefo sYzxpqH6uei5w1qPW08I+qrVlRcyOIpsssUC7BZQ8aIYXA4WKn5WhYoJshXcAt0iBufghpNbDHI5Pr66gMgY6z2U14r9AMXCPWpSvBJ5JfymWVpCEjhz9kRY ZWprgWAqbCrDzbRZQJOhEU+zJNOOWr/arjL9TQkaRgY=
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/qijWGV0H92JdKVZw6ifPowN3ZPs>
Subject: Re: [Rats] EAT claims needed by TEEP
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, 08 Nov 2021 21:20:26 -0000

This PR <https://github.com/ietf-rats-wg/eat/pull/139> now exists to address class.

I was never quite sure what it was and it seemed TEEP/SUITE specific to me, one of the reasons I didn’t do anything about it for the -11 draft. See if what I’ve got in the PR makes sense.

LL


> On Nov 8, 2021, at 9:20 AM, Dave Thaler <dthaler@microsoft.com> wrote:
> 
> Following up on the RATS meeting today, I compared the latest EAT document
> against the TEEP requirements discussed most recently at the IETF 111 RATS meeting.
>  
> There were 5 requirements from TEEP for claims, ideally general use ones not profile specific ones.
> My reading is that the latest EAT doc now meets 4 of the 5 and only “device class” is missing,
> and indeed the EAT document discussion of ueid explicitly says
> “It does not identify types, models or classes of devices.”
> but nothing else in the document I could find provides a way to identify such.
>  
> Henk’s proposal there was section 3.1.2 of draft-birkholz-rats-suit-claims:
>  
> > 3.1.2.  class-identifier
> > 
> >   A RFC 4122 UUID representing the class of the Attester or one of its
> >   hardware and/or software components.
> > 
> >   $$system-property-claim //= ( class-identifier => RFC4122_UUID )
>  
> The other four requirements from TEEP can be met as follows, if I understand
> the intent correctly:
> Device unique identifier -> use ueid claim
> Vendor of the device -> use oemid
> Firmware type -> use sw-name
> Firmware version -> use sw-version
>  
> The above claims would go in a claimset about the TEE (which may or may not be
> a separate processor), but EAT already supports different claimsets for different
> components as I understand it, so that’s fine.
>  
> https://github.com/ietf-rats-wg/eat/issues/138 <https://github.com/ietf-rats-wg/eat/issues/138> tracks this issue and my belief
> is it should be simple to add a device class claim into a draft -12 of EAT.
>  
> I will also cover this in the TEEP WG meeting on Friday where I will discuss
> what we need to change in the TEEP protocol spec, where this is tracked by
> https://github.com/ietf-teep/teep-protocol/issues/165 <https://github.com/ietf-teep/teep-protocol/issues/165>
>  
> Dave
>  
> From: Thomas Fossati <Thomas.Fossati@arm.com> 
> Sent: Thursday, October 29, 2020 2:21 PM
> To: Laurence Lundblade <lgl@island-resort.com>
> Cc: rats@ietf.org; teep <teep@ietf.org>rg>; Dave Thaler <dthaler@microsoft.com>om>; Simon Frost <Simon.Frost@arm.com>om>; Thomas Fossati <Thomas.Fossati@arm.com>
> Subject: Re: [Rats] EAT claims needed by TEEP
>  
> On 29/10/2020, 21:07, "RATS" <rats-bounces@ietf.org <mailto:rats-bounces@ietf.org>> wrote:
> > On Oct 29, 2020, at 1:45 PM, Thomas Fossati <Thomas.Fossati@arm.com <mailto:Thomas.Fossati@arm.com>> wrote:
> > 
> > Hi Laurence,
> > 
> > > My understanding is that they are always encoded as CBOR text strings,
> > > so floating-point doesn’t mean #7.25 or such.
> > 
> > Correct.  In (Co)SWID software-version is just a text string and version-scheme
> > is there to do some semantic polishing.  But the underlying type is always #3.
> > 
> > Maybe I'm misunderstanding your proposal here, but I would be circumspect
> > in mixing SWIDs attributes, which are scoped to software artifacts, with HW
> > identifiers.
> > 
> > 
> > Hi Thomas,
> > 
> > All the SW Version stuff would fall under a single EAT claims that
> > contains a full CoSWID.
> > 
> > For HW Version, I was thinking of two EAT claims, one for the version
> > text, another for the version scheme (or we could go off and define a
> > full CoHWID).
>  
> OK, looks like I had misunderstood your plan :-) thanks for the
> clarification!
> IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.