Re: [EAT] Scope, Goals & Background for RATS

Henk Birkholz <henk.birkholz@sit.fraunhofer.de> Fri, 21 September 2018 16:24 UTC

Return-Path: <henk.birkholz@sit.fraunhofer.de>
X-Original-To: eat@ietfa.amsl.com
Delivered-To: eat@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B3A9130DBE; Fri, 21 Sep 2018 09:24:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-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 0c-tYyHMwfPY; Fri, 21 Sep 2018 09:24:19 -0700 (PDT)
Received: from mailext.sit.fraunhofer.de (mailext.sit.fraunhofer.de [141.12.72.89]) (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 098E412777C; Fri, 21 Sep 2018 09:24:17 -0700 (PDT)
Received: from mail.sit.fraunhofer.de (mail.sit.fraunhofer.de [141.12.84.171]) by mailext.sit.fraunhofer.de (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id w8LGOEWP032271 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 21 Sep 2018 18:24:15 +0200
Received: from [134.102.163.186] (134.102.163.186) by mail.sit.fraunhofer.de (141.12.84.171) with Microsoft SMTP Server (TLS) id 14.3.408.0; Fri, 21 Sep 2018 18:24:09 +0200
To: Laurence Lundblade <lgl@island-resort.com>
CC: "rats@ietf.org" <rats@ietf.org>, "eat@ietf.org" <eat@ietf.org>
References: <710df01c-c45f-9d26-b578-e4baa53c6de8@sit.fraunhofer.de> <000D27F1-C5C0-4F14-A628-42A321077A52@island-resort.com>
From: Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
Message-ID: <5c64c380-3460-0c13-c1a5-b6f7f1a2a73c@sit.fraunhofer.de>
Date: Fri, 21 Sep 2018 18:24:08 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <000D27F1-C5C0-4F14-A628-42A321077A52@island-resort.com>
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Originating-IP: [134.102.163.186]
Archived-At: <https://mailarchive.ietf.org/arch/msg/eat/MHwbBObAG4aAurobfFqeY8-lqGs>
Subject: Re: [EAT] Scope, Goals & Background for RATS
X-BeenThere: eat@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: EAT - Entity Attestation Token <eat.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/eat>, <mailto:eat-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/eat/>
List-Post: <mailto:eat@ietf.org>
List-Help: <mailto:eat-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/eat>, <mailto:eat-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 21 Sep 2018 16:24:23 -0000

Hello Laurence,

please find replies and comments in-line:

On 09/20/2018 10:18 PM, Laurence Lundblade wrote:
> It’s a bit buried, but I see you do intend that this include the EAT 
> work. Thus the work would not be TPM/TCG centric. It would include use 
> cases like FIDO and Android Keystore attestation that are often based on 
> TrustZone. It could also include EPID-related use cases. Please confirm.

I am not sure, if I am the authority to confirm this, as kickstarting 
RATS is a group effort. What I can do is to agree with the statement 
that RATS is abstracting from specific hardware solutions that provide, 
for example trust anchors and shielded locations (which keystores are a 
subset of, I think), or restrict secret key access (protection of 
execution, I think) based on system status (or more generic - system 
health).

Conveyance of Attestation Claims is a big part of implicit attestation 
and the comparison of (amongst other information) claims wrt to 
appraisal of Attestation Evidence in explicit attestation. As EAT 
provides a data format to express these claim sets in a state-of-the art 
representation (and, if signed, via a state-of-the-art COSE envelope) 
they are compose a perfect option to address the data model part of 
conveyance.

> 
> My preference would be to choose another name for the group that is 
> neither EAT or RATS to help make this clear. I don’t really think there 
> is a “procedure” with EAT. To be honest, I don’t really like “RATS” as a 
> name. My suggestions are “RA” for Remote Attestation or “CAT” for Common 
> Attestation Technology (and besides cats caused us to invent the 
> Internet so we share pictures of them (securely)).
> 
> I propose a more high-level intro with examples:
> 
>     The purpose of RA/CAT is to allow a Relying Party (e.g. a web
>     service, network management center...) to securely receive Claims
>     from an Entity requesting service (e.g. a phone, router, IoT
>     device...) that allow the Relying Party to determine if and how that
>     entity is trusted.  For example:
> 
>       o An IoT management back-end receives a signed nonce that proves
>         the IoT device is the genuine article manufactured by the
>         expected OEM and is not a Linux box or such emulating such a device.
>       o A network management center receives a set of measurement claims
>         from a router to know that the configuration has not been
>         tampered with.
>       o An online banking service receives many claims about the device
>         including location, SW versions and measurements and determines
>         that it will allow a higher-than-usual value transaction.
>       o A government online document server receives claims indicating
>         manufacture and location of the device, determines they are from
>         the correct country and grants access to classified documents.
> 
>     There are protocols for determining and securing the identity of a
>     server or service (TLS and IPsec). There are many protocols for
>     authenticating end users (SASL, TLS client auth, EAP…). There are no
>     general protocols for managing the characteristics, security and
>     identity of an end client device (an Entity). RA/CAT aims to address
>     that gap.
> 
>     There is no goal here to set criteria for what is trustworthy or not
>     as that is an impossible task as it will vary widely from use case
>     to use case. The goal here is to securely provide information
>     (Claims) to the Relying Party so it can make that determination
>     based on its own criteria and needs.

RATS addresses a vital domain that I feel is missing here: critical 
infrastructure or safety critical systems.

Examples given: voting machines, rail-road object controllers, air plane 
cabin and avionic control systems & corresponding airports, cell-phone 
towers, or domains with high levels of confidentiality, in general.

Of course, there is the high demand to convey information to assess a 
system's trustworthiness in a trusted and resilient way coming from 
network equipment (or network function services) vendors. But managing 
the integrity (and actual composition) of a large number of end-user 
devices is also a requirement with continuously growing importances - 
not only for governments, but also for enterprises.

The scope of numbers of devices expanding due to encompassing 
constrained-node environments will render RATS a very interesting effort 
(that is why "offloading the burden of appraisal" and differentiating 
the roles of Verifier, Relying Party & "measured system (component)" is 
so vital, I think).

> 
> 
> 
> I don’t think the intro should mention public key crypto. I know of 
> attestation solutions that do not use it.
> 

This is a good point, we added proof-of-possession to enable readers to 
better intuitively grasp the context in the IETF. Could you reference 
some of the solutions? I think that would help address that comment.


> I tend to prefer “attestation” when the goal is whether and how a device 
> is to be trusted and “authentication” when the goal is how a human is to 
> be identified. FIDO, OAuth, SASL are all about users and use the word 
> authentication.

Yes - I think we are in agreement here. I am not sure if we can skip the 
term entirely, but the focus is on more than "stronger authentication".

> 
> LL
> 

Viele Grüße,

Henk

> 
>> On Sep 18, 2018, at 1:26 AM, Henk Birkholz 
>> <henk.birkholz@sit.fraunhofer.de 
>> <mailto:henk.birkholz@sit.fraunhofer.de>> wrote:
>>
>> Hi all,
>>
>> we pushed an initial document to the RATS github in order to focus the 
>> discussion about remote attestation procedures a bit.
>>
>>> https://github.com/ietf-rats/charter/blob/master/ietf-rats-charter.md
>>
>> We included a background section to better highlight the meaning of 
>> the term "attestation" in general. Hence, there is a trade-off between 
>> clarity and conciseness, which is one of the things we would like to 
>> get feedback about.
>>
>> Naturally, we are also very interested in feedback about the 
>> illustrated difference between explicit attestation and implicit 
>> attestation.
>>
>> Viele Grüße,
>>
>> Henk
>>
>>
>>
>>
>>
>> _______________________________________________
>> EAT mailing list
>> EAT@ietf.org <mailto:EAT@ietf.org>
>> https://www.ietf.org/mailman/listinfo/eat
>