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 >
- [EAT] Scope, Goals & Background for RATS Henk Birkholz
- Re: [EAT] Scope, Goals & Background for RATS Denis
- Re: [EAT] [Rats] Scope, Goals & Background for RA… Fuchs, Andreas
- Re: [EAT] Scope, Goals & Background for RATS Henk Birkholz
- Re: [EAT] Scope, Goals & Background for RATS Denis
- Re: [EAT] Scope, Goals & Background for RATS Carsten Bormann
- Re: [EAT] Scope, Goals & Background for RATS Michael Richardson
- Re: [EAT] Scope, Goals & Background for RATS Michael Richardson
- Re: [EAT] Scope, Goals & Background for RATS Eric Voit (evoit)
- Re: [EAT] Scope, Goals & Background for RATS Carsten Bormann
- Re: [EAT] Scope, Goals & Background for RATS Melinda Shore
- Re: [EAT] Scope, Goals & Background for RATS Smith, Ned
- Re: [EAT] Scope, Goals & Background for RATS Laurence Lundblade
- [EAT] Implicit vs Explicit Attestation (was Re: S… Laurence Lundblade
- Re: [EAT] Scope, Goals & Background for RATS Diego R. Lopez
- [EAT] Terminology definitions (was Re: Scope, Goa… Laurence Lundblade
- Re: [EAT] Terminology definitions (was Re: Scope,… Henk Birkholz
- Re: [EAT] Implicit vs Explicit Attestation (was R… Henk Birkholz
- Re: [EAT] Scope, Goals & Background for RATS Henk Birkholz
- Re: [EAT] [Rats] Terminology definitions (was Re:… Smith, Ned
- Re: [EAT] Scope, Goals & Background for RATS Laurence Lundblade
- Re: [EAT] Scope, Goals & Background for RATS Henk Birkholz
- Re: [EAT] Scope, Goals & Background for RATS Diego R. Lopez
- Re: [EAT] Implicit vs Explicit Attestation (was R… Laurence Lundblade
- Re: [EAT] [Rats] Implicit vs Explicit Attestation… Fuchs, Andreas
- Re: [EAT] Implicit vs Explicit Attestation (was R… Henk Birkholz
- Re: [EAT] [Rats] Implicit vs Explicit Attestation… Laurence Lundblade
- Re: [EAT] [Rats] Implicit vs Explicit Attestation… Wheeler, David M
- Re: [EAT] Implicit vs Explicit Attestation (was R… Laurence Lundblade
- Re: [EAT] [Rats] Implicit vs Explicit Attestation… Smith, Ned
- [EAT] Naming (was Re: Scope, Goals & Background f… Laurence Lundblade
- [EAT] EAT additions to Charter (was Re: Scope, Go… Laurence Lundblade
- Re: [EAT] EAT additions to Charter (was Re: Scope… Suresh Marisetty
- Re: [EAT] Naming (was Re: Scope, Goals & Backgrou… Diego R. Lopez
- Re: [EAT] EAT additions to Charter (was Re: Scope… Carl Wallace
- Re: [EAT] Naming (was Re: Scope, Goals & Backgrou… Laurence Lundblade