### Re: [Rats] Age Claim in EAT

"Oliver, Ian (Nokia - FI/Espoo)" <ian.oliver@nokia-bell-labs.com> Thu, 30 July 2020 10:01 UTC

Return-Path: <ian.oliver@nokia-bell-labs.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 2A8E93A0CD8 for <rats@ietfa.amsl.com>; Thu, 30 Jul 2020 03:01:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.891
X-Spam-Level:
X-Spam-Status: No, score=-1.891 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_SPF_HELO_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.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 D7cPGnhjSp2h for <rats@ietfa.amsl.com>; Thu, 30 Jul 2020 03:01:05 -0700 (PDT)
Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30096.outbound.protection.outlook.com [40.107.3.96]) (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 769F93A0CDC for <rats@ietf.org>; Thu, 30 Jul 2020 03:01:04 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kPbdXRuUSXsEnEcZscUvX8I3E64Mudx8xxtsOLBqfTjCttQrEhHzzJ7uUJka+G0rjCsjdAUze6hYo43c53bOUJnAYnW8TbRaaFTC1rN+3J0lksLDt9LCF0X6+iRB0FXTf561Z61lHh66TROKBDGk0OoZpVWTGk0XotNhTL3jQ/QlK6unf9DzJjW1u/J9IMlbx9hetrkdmfdP3TUX0xnWqrJ36S05En0JZbDc8EJezpvKJyqAiyRe8MlbM82QyLKDJ5Xdb2hsCFVGW1JI9t+qKgeDjx4exssZbzCcsh+2ZSsvqk9g/5JdwHHzuKRARhtmhbpGIUr+cgkk9oC5nJtMTw==
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=XbLE63OWpg29F+tJt0uNHagVnxofrT4AsGu5UP8utTg=; b=DpUkih35Cy5xHrhcq0OfxyLy20YvkhWwRPwtyONOgWAu14mVJeb9/DP1c8wKX69GOWdwR8LooS8Q0NV0rw30TUGtEzhszT3IwcMQ5Dp91hvDBvbAYwV8wyr2+IgeZTjo5hDSY/Lw321KO7kG4ewrXY8aWW0ba5LYmqGSjbK0BhkkEa0iPGHhk9qlAubd5G/uuGBBOifHarTwcuMSY0Mt8ydnsdz7EfpJHERhPhU619bjBzKT+fCaEQZgnz4bQwUueuVlCTEHY1n1aio+cOY5Ym9xHzra+mTmBkoz+a/GjONxg/zxir4iF9Bi7Dsa7KpeX6Hra8AJiUCPsoqIzOyY6A==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nokia-bell-labs.com; dmarc=pass action=none header.from=nokia-bell-labs.com; dkim=pass header.d=nokia-bell-labs.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=XbLE63OWpg29F+tJt0uNHagVnxofrT4AsGu5UP8utTg=; b=ia5OkeCO7ctdIMFOuyetSqBah6WIP0S/TojxxeuuLQ4C18A1nx0NyfpWQDdYQm/9iF/EHDni+XBlbvqnzYMHRh7fuM1LRcdoAgmD9Zin9hKwmQQgTnaId24u+kbB3cHdlbThCLViOMIR/A0WYeAwv4amwdSZwYGvm1wukDWfiL8=
Received: from HE1PR07MB4252.eurprd07.prod.outlook.com (2603:10a6:7:9f::21) by HE1PR0701MB2185.eurprd07.prod.outlook.com (2603:10a6:3:2a::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3239.11; Thu, 30 Jul 2020 10:01:02 +0000
Received: from HE1PR07MB4252.eurprd07.prod.outlook.com ([fe80::59ef:f11b:78d5:77d6]) by HE1PR07MB4252.eurprd07.prod.outlook.com ([fe80::59ef:f11b:78d5:77d6%5]) with mapi id 15.20.3239.017; Thu, 30 Jul 2020 10:01:02 +0000
From: "Oliver, Ian (Nokia - FI/Espoo)" <ian.oliver@nokia-bell-labs.com>
To: Hannes Tschofenig <Hannes.Tschofenig@arm.com>, Henk Birkholz <henk.birkholz@sit.fraunhofer.de>, "rats@ietf.org" <rats@ietf.org>
Thread-Topic: [Rats] Age Claim in EAT
Date: Thu, 30 Jul 2020 10:01:02 +0000
Message-ID: <HE1PR07MB42526CF2E3F40F73B4A7287E8F710@HE1PR07MB4252.eurprd07.prod.outlook.com>
Accept-Language: en-GB, en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [80.67.10.139]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: d5511acc-2de4-4283-c314-08d8346f77ac
x-ms-traffictypediagnostic: HE1PR0701MB2185:
x-microsoft-antispam-prvs: <HE1PR0701MB21853B379300E5C3A3898A0E8F710@HE1PR0701MB2185.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: g79ZhuGv52XqZvwhWakfczJlmO7kft2JFeog8AI1RuLjR3c6PLfssSTbV5L0Af7YCpUGPpVCB0DgSNf2Jag/xXBYsvXurr+2YnIK/6ghmOfdrGWg0G3yQ64lt6OokLGtQKwavdYl9t1d2ILDjXk4azF5MSwahpGRpQUNectJeXEdm9K1EwX1VWEHGhrhYMAc/Lv9ylQBaHdWxKhLa59PjVUgcauZFB6851RdNVYBunZhi/xwDXsx8ZUpT9j925kCsoCI3n1THn94GKp8UWHuK/0SBf89KsOffZpFd6cSniehToKM0uyQUdwGQWUK2OdI33VEDgBR6eahHaVzVxvY8eX0iFmsoulFnzfAE8pJbd2fJX16KwDE2snE/jS1bgUSyqz5MV7CR2aJr+dWcNpdSA==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR07MB4252.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(136003)(396003)(376002)(346002)(39860400002)(366004)(7696005)(55236004)(5660300002)(26005)(86362001)(478600001)(19627405001)(966005)(186003)(33656002)(6506007)(53546011)(83380400001)(2906002)(76116006)(71200400001)(8936002)(66556008)(66446008)(64756008)(166002)(8676002)(66946007)(316002)(55016002)(66476007)(110136005)(9686003)(52536014); DIR:OUT; SFP:1102;
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_HE1PR07MB42526CF2E3F40F73B4A7287E8F710HE1PR07MB4252eurp_"
MIME-Version: 1.0
X-OriginatorOrg: nokia-bell-labs.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: HE1PR07MB4252.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: d5511acc-2de4-4283-c314-08d8346f77ac
X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Jul 2020 10:01:02.5151 (UTC)
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 5nkmHI0Khk9BH++ZpoSwm59U8XUiAHNlL7ljmEQ9ikxAokvD5pGUbc3GZ67+J3VCbO88tblQmJ6s5aPOgs/bT5JgPaK7diopenPR9jmIrzc=
Subject: Re: [Rats] Age Claim in EAT
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: Thu, 30 Jul 2020 10:01:13 -0000

Interesting.

We've implemented something similar (or at least tried to be compliant with the spec as much as we can)

For each claim we have at minimum the time of the claim request (R) by the attestating authority, the time of claim creation (C) by the reporting authority and the time of receipt (T) by the attesting authority.

One of the attestation rules is thus: R < C < T

Another would then deal with timliness of the obtaining of the claim, eg:   T -R < \epsilon

I agree that some idea of the latches/stage-transitions would help.

Ian

--

Dr. Ian Oliver

Cybersecurity Research

Distinguished Member of Technical Staff

Nokia Bell Labs

+358 50 483 6237

________________________________
From: Hannes Tschofenig <Hannes.Tschofenig@arm.com>
Sent: 30 July 2020 11:28
To: Henk Birkholz <henk.birkholz@sit.fraunhofer.de>de>; rats@ietf.org <rats@ietf.org>
Subject: Re: [Rats] Age Claim in EAT

Thanks for the clarification, Henk.

Since I don't know what information consumers of Entity Attestation Tokens really need to make decisions I am not sure whether the current functionality is sufficient already or not. To me as a reader it appears underspecified.  At a minimum a reference to Appendix A of the RATS architecture document in the EAT spec would be useful.

Ciao
Hannes

-----Original Message-----
From: Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
Sent: Wednesday, July 29, 2020 11:11 AM
To: Hannes Tschofenig <Hannes.Tschofenig@arm.com>om>; rats@ietf.org
Subject: Re: [Rats] Age Claim in EAT

Hi Hannes,

in the scope of Evidence:

Signing a CWT structure is creating an EAT. This event is defined as
time(EG) here:
https://tools.ietf.org/html/draft-ietf-rats-architecture-05#appendix-A

"Creating a token" would mean "Evidence Generation", for example.

Age also is a time interval based on a time unit (units that apply to Henk are years, I claim that Henk's age is 21, of course. Trust in Henk's Claims can be established via Endorsements). Age is a time interval expressed as a duration. That means that the beginning of that time interval is set as zero (an epoch) and then counts the time units.

The semantics of age in EAT are:

the epoch is time(EG) and the unit is seconds.
This only works, if time sources for relative time-counters are available, of course.

Collection of Claims - time(CC) was proposed to the architecture, but did not find consensus yet (we are working on time(AA), though, the time at which the Attester becomes aware of a changes value in the Target Environment right now).

But! there is time(VG), the Value Generation. This time can often only be inferred or approximated (in contrast to time(AA)), but it is the best we have defined right now in the context of:

> If that's the case, I wonder whether it would also make sense to take into account that different information may be collected at a different point in time and hence the age indication would better go (somehow) with specific claims where the time difference between the collection of the data and the signature generation matters.

As a note: We have not talked at all before about the common concept of "latches" or stage transitions... this is an important concept that does capture the "this event has happened" (before/after a defined event) and represents strong security implications that are not included in the RATS architecture today. Would that maybe help in your context?

Viele Grüße,

Henk

On 29.07.20 10:37, Hannes Tschofenig wrote:
> Hi Laurence, Hi all,
>
> How does the age claim work?
>
> The spec says "represents the number of seconds that have elapsed since the token was created".
>
> By creating a token you also protect the claims with a signature and hence you cannot change the content of the claims anymore (without breaking the signature).
>
> Hence, here "creating a token" must mean something different. I suspect it means when certain values have been collected from the device and before the token with the signature was put together. Correct?
>
> If that's the case, I wonder whether it would also make sense to take into account that different information may be collected at a different point in time and hence the age indication would better go (somehow) with specific claims where the time difference between the collection of the data and the signature generation matters. I also wonder whether the number of seconds matter and whether you really want to communicate something more abstract, such as "I created a hash over the firmware during boot time" rather than "I created the hash over the firmware in real-time when I was asked".
>
> Ciao
> Hannes
>
> 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.
>
> _______________________________________________
> RATS mailing list
> RATS@ietf.org
> https://www.ietf.org/mailman/listinfo/rats
>
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.