Re: [EAT] [Rats] Attestation BoF charter updates?
Jeremy O'Donoghue <jodonogh@qti.qualcomm.com> Wed, 24 October 2018 11:36 UTC
Return-Path: <jodonogh@qti.qualcomm.com>
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 7EC01130E3A; Wed, 24 Oct 2018 04:36:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Level:
X-Spam-Status: No, score=-4.3 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, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=qti.qualcomm.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 3KJWXHlkR_XT; Wed, 24 Oct 2018 04:36:44 -0700 (PDT)
Received: from alexa-out-ams-01.qualcomm.com (alexa-out-ams-01.qualcomm.com [185.23.61.162]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70C56130DF5; Wed, 24 Oct 2018 04:36:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1540381003; x=1571917003; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=osXgUV9riGUhHEG0DZv/VQXHP0aR3gSNt+m2zRKLFuQ=; b=TCsiHPFGE9bmKYuVbk4Quh6JjfHnCTp8lzFAN6IrT2mcZPl8HyfTDdfV 0sstHoaIbaUy2sKLbTgI0teQjT7ZIlwZGDBLyNKl5u8h0CZ46qPrwmO7R ZVwKM4R713WzdOPrvqk4eptwVMXa5MP08hEDuOCHxt+Pbpuq6Td80mrd2 g=;
X-IronPort-AV: E=Sophos;i="5.54,420,1534802400"; d="scan'208,217";a="1385930"
Received: from ironmsg03-ams.qualcomm.com ([10.251.56.4]) by alexa-out-ams-01.qualcomm.com with ESMTP; 24 Oct 2018 13:36:40 +0200
X-IronPort-AV: E=McAfee;i="5900,7806,9055"; a="6108322"
Received: from euamsexm01b.eu.qualcomm.com ([10.251.127.41]) by ironmsg03-ams.qualcomm.com with ESMTP/TLS/AES256-SHA; 24 Oct 2018 13:36:40 +0200
Received: from euamsexm01a.eu.qualcomm.com (10.251.127.40) by euamsexm01b.eu.qualcomm.com (10.251.127.41) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Wed, 24 Oct 2018 13:36:38 +0200
Received: from euamsexm01a.eu.qualcomm.com ([10.251.127.40]) by euamsexm01a.eu.qualcomm.com ([10.251.127.40]) with mapi id 15.00.1365.000; Wed, 24 Oct 2018 13:36:38 +0200
From: Jeremy O'Donoghue <jodonogh@qti.qualcomm.com>
To: "Eric Voit (evoit)" <evoit@cisco.com>
CC: Michael Richardson <mcr+ietf@sandelman.ca>, "rats@ietf.org" <rats@ietf.org>, "eat@ietf.org" <eat@ietf.org>
Thread-Topic: [EAT] [Rats] Attestation BoF charter updates?
Thread-Index: AQHUakqqBJn3KZZVPEe4vVODtnqbzKUsxo8AgAA3c3CAASeGgA==
Date: Wed, 24 Oct 2018 11:36:38 +0000
Message-ID: <0771A502-32EF-46E9-95FB-55BE0FF04634@qti.qualcomm.com>
References: <5D773C02-5083-4B10-A705-782E28FD8ADB@island-resort.com> <f84515dd-2e1a-7e66-7c23-b16f8f425d2a@sit.fraunhofer.de> <3347AA26-3FA1-4067-8378-51B533BA77FB@island-resort.com> <570FEF0C-FD3A-4EBF-B8E6-7B13D2FD8E22@qti.qualcomm.com> <7544.1540242117@localhost> <46150D67-97E7-457F-9C8B-D2B3060978CA@qti.qualcomm.com> <f6602afcf1b0440d98f5ded158bfe572@XCH-RTP-013.cisco.com>
In-Reply-To: <f6602afcf1b0440d98f5ded158bfe572@XCH-RTP-013.cisco.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3445.9.1)
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.251.52.12]
Content-Type: multipart/alternative; boundary="_000_0771A50232EF46E995FB55BE0FF04634qtiqualcommcom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/eat/-OTFbxCmoX0_u6HjO9XRDy99UO8>
Subject: Re: [EAT] [Rats] Attestation BoF charter updates?
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: Wed, 24 Oct 2018 11:36:48 -0000
HI Eric, On 23 Oct 2018, at 19:04, Eric Voit (evoit) <evoit@cisco.com<mailto:evoit@cisco.com>> wrote: Hi Jeremy, Thanks for taking a cut at this charter simplification. There are a few areas covered within the GitHub Goals<https://github.com/ietf-rats/charter/blob/RC2/ietf-rats-charter.md>which I can’t easily map to your text below. Could you talk about how these elements are covered (or not)? For context, I am working from the perspective of remote attestation application<https://www.cisco.com/c/dam/en/us/td/docs/cloud-systems-management/application-policy-infrastructure-controller-enterprise-module/1-5-x/integrity_verification/user-guide/Cisco_Integrity_Verification_Application_APIC-EM_User_Guide_1_5_0_x.pdf> developer trying to standardize the interfaces between a controller (which is acting as a claim verifier) and a network element (which includes TCG based subsystems.) For my application to work properly, there are several things needed within a network controller to validate the asserted claims coming out of a router. These include: • How do we expose the attestation evidence which can be used to validate asserted claims? I think that the need to address this is covered sufficiently for a WG Charter by the statement "Produce a specification defining procedures and corresponding architectures supporting verification of Claims". If verification of Claims requires specific forms of attestation evidence (e.g. a set of measurements generated by a TPM), then it is properly a matter for an RFC to specify this, as Michael suggests. • How do we know which root of trust which was used to generate the attestation evidence (e.g., application event logs), and how does a verifier differentiate this from the root-of-trust which asserts claims made upon this evidence? Again, I think this is a matter for specification rather than charter. There are a number of different ways in which Roots of Trust can be realised and many possible device architectures. The EAT draft allows one RoT to include an attestation generated by a different RoT, for example. I believe the RATS draft also provides technical mechanisms by which this can be achieved. • What entities are allowed to read the info asserted claims? What subset of these can see the raw attestation evidence? These questions are significant because routers/switches are not monolithic devices. In fact, they are composed of subsystems with different levels of trustworthiness. As the IETF often aims at protocol specifications at the inter-device level, I am looking for coverage of such questions in the charter. I agree with you here as the same issue applies to claims with privacy implications. As an example, I may wish to present a unique device ID to a social media website but not my location. I have added bullet point 3 to the draft - which I will post separately. Let me know if you think this addresses your concerns sufficiently. Best regards Jeremy Thanks, Eric From: Jeremy O'Donoghue, October 23, 2018 10:40 AM On 22 Oct 2018, at 22:01, Michael Richardson <mcr+ietf@sandelman.ca<mailto:mcr+ietf@sandelman.ca>> wrote: Jeremy O'Donoghue <jodonogh@qti.qualcomm.com<mailto:jodonogh@qti.qualcomm.com>> wrote: This is a very useful contribution, Laurence. The current draft text is too strongly biased towards attestation based on measurement, and does not adequately cover other mechanisms which are already But, it's for the charter, for the WG, it's not a treatise on attestation itself. This is all supposed to be *meta* text about attestation, about what we want to say about attestation in the documents, not about what attestation is. Please go read some other IETF charters: https://datatracker.ietf.org/wg/6lo/about/ https://datatracker.ietf.org/wg/6tisch/about/ https://datatracker.ietf.org/wg/suit/about/ Fair comment. We have two existing proposals - EAT and RATS - which address a similar problem space but using different mechanisms. While I believe the RATS and EAT contributors are in broad agreement that there is significant benefit in bringing both work streams under a single umbrella, trying to properly incorporate EAT through incremental modification to the draft RATS WG charter text is proving challenging. The below probably diverges too far from the current text for some tastes, but it may address your point and provide a basis for discussion (at this point the GitHub draft<https://github.com/ietf-rats/charter/blob/RC2/ietf-rats-charter.md> seems a long way behind the list). It is deliberately significantly shorter than the current draft - I have tried to re-use as much existing text as possible, but it is heavily re-organised and abridged. I have taken on board the comment from Carsten that perhaps a minimum level of terminology is acceptable in charter text, but deliberately tried to keep the language simple and fairly generic to enable the proper work of terminology definition to take place in the requirements document as you suggest. Introduction ------------ Remote attestation procedures can be incorporated in network protocols to provide the basis for establishing claims about an entity in a trustworthy manner. Such claims may include, but are not limited to, device identity, manufacturing origin, system integrity, configuration, operational state and measurements of steps which led to the operational state. Such procedures expose entity characteristics in the form of claim sets which allow remote parties to establish the trustworthiness of a device, provide evidence that a particular set of operations and functions are supported and/or that the entity is actually what it claims to be. In the absence of such procedures, while domain-specific attestation mechanisms such as TCG TPM, FIDO Alliance attestation and Android Keystore attestation exist, there is no common way for a remote party to tell if data originates from a trustworthy device (e.g. a Trusted System designed to support a specific set of operations/functionalities) or not. The following minimal terminology is defined for the purposes of clarifying the Working Group charter text: - attestation: a set of claims which can be verified as originating in an entity. - claim: as defined in RFC7519. - entity: a device or device sub-module that can generate a claim or set of claims which can be verified by a remote party. - remote party: an actor remote from an entity that wishes to verify whether a claim or set of claims originated in a given entity. Description of the Working Group -------------------------------- The Working Group will define: - Standardized and interoperable mechanisms to establish a sufficient level of confidence that data originates from a trustworthy entity designed to support a specific set of operations/functionalities. - Standardized and interoperable mechanisms building on (1) to allow remote parties to know the provenance and characteristics of an entity that may be requesting services. The Working Group will identify security goals which it expects a trustworthy execution context to address, which will assume the presence of Roots of Trust (as defined by NIST [SP800-164]). The detailed specification of such contexts is out of scope. The Working Group will maintain close relationships with bodies undertaking complementary work streams in the area of remote attestation such as GlobalPlatform, Trusted Computing Group and FIDO Alliance. The Working Group will cooperate with the TEEP Working Group, which may generate requirements for claims relevant to TEE. Work Items ---------- The Working Group will develop specifications supporting the creation of interoperable remote attestation procedures for entities which incorporate Roots of Trust. The main deliverables are as follows. - Produce a requirements document establishing a common vocabulary for remote attestation, identifying mechanisms which will be supported for establishing trust between an entity and a remote party, and enumerating sample use-cases for remote attestation. - Produce specification text defining interoperable cross-platform claims which provide information about an entity in support of the required use-cases, and extending the set of claims defined in RFC7519 and RFC8392. The specification will describe the syntax for each claim in at least the following formats: - CBOR [RFC7049] - JSON [RFC7159] - YANG [RFC6020] - Produce specification text defining procedures and corresponding architectures supporting verification of claims within an attestation based on measured file execution procedures and supporting: - Explicit attestation wherein a set of claims is transported in the attestation; - Implicit attestation wherein a set of claims is implied by possession of a secret. - Produce specification text defining procedures and corresponding architectures supporting verification of claims encapsulated in: - CBOR Web Token structures [RFC8392] - JSON Web Token structures [RFC7519] - Perform privacy analysis of both claims and the cryptographic procedures used to establish trust. This information will be included as appropriate in the deliverable specifications, and may imply extension of procedures defined in other specifications in support of privacy goals. It seems to me that there are two ways to produce the main specification deliverables. I have deliberately left the text above slightly vague on this. * A claims specification common to RATS and EAT with separate RATS and EAT procedure specifications. * A claims specification also incorporating EAT procedures and a separate RATS procedure specification. This would be my preferred option. * I believe there are very few procedures needed for EAT other than the possible need to support a nonce to ensure freshness Jeremy Notice how by about the second paragraph (6tisch takes a bit longer), each gets into what the WG will do? -- Michael Richardson <mcr+IETF@sandelman.ca<mailto:mcr+IETF@sandelman.ca>>, Sandelman Software Works -= IPv6 IoT consulting =- _______________________________________________ EAT mailing list EAT@ietf.org<mailto:EAT@ietf.org> https://www.ietf.org/mailman/listinfo/eat
- [EAT] Attestation BoF charter updates? Laurence Lundblade
- Re: [EAT] Attestation BoF charter updates? Henk Birkholz
- Re: [EAT] Attestation BoF charter updates? Henk Birkholz
- Re: [EAT] [Rats] Attestation BoF charter updates? Michael Richardson
- Re: [EAT] [Rats] Attestation BoF charter updates? Carsten Bormann
- Re: [EAT] [Rats] Attestation BoF charter updates? Carl Wallace
- Re: [EAT] [Rats] Attestation BoF charter updates? Denis
- Re: [EAT] [EXTERNAL] Re: [Rats] Attestation BoF c… Jeremy O'Donoghue
- Re: [EAT] [EXTERNAL] Re: [Rats] Attestation BoF c… Denis
- Re: [EAT] [EXTERNAL] Re: [Rats] Attestation BoF c… Henk Birkholz
- Re: [EAT] [EXTERNAL] Re: [Rats] Attestation BoF c… Smith, Ned
- Re: [EAT] [EXTERNAL] Re: [Rats] Attestation BoF c… Hannes Tschofenig
- Re: [EAT] [EXTERNAL] Re: [Rats] Attestation BoF c… Denis
- Re: [EAT] [EXTERNAL] Re: [Rats] Attestation BoF c… Giridhar Mandyam
- Re: [EAT] [Rats] [EXTERNAL] Re: Attestation BoF c… Henk Birkholz
- Re: [EAT] [EXTERNAL] Re: [Rats] Attestation BoF c… Henk Birkholz
- Re: [EAT] [EXTERNAL] Re: [Rats] Attestation BoF c… Smith, Ned
- Re: [EAT] [EXTERNAL] Re: [Rats] Attestation BoF c… Laurence Lundblade
- Re: [EAT] [EXTERNAL] Re: [Rats] Attestation BoF c… Henk Birkholz
- Re: [EAT] [Rats] [EXTERNAL] Re: Attestation BoF c… Giridhar Mandyam
- Re: [EAT] [EXTERNAL] Re: [Rats] Attestation BoF c… Laurence Lundblade
- Re: [EAT] [EXTERNAL] Re: [Rats] Attestation BoF c… Diego R. Lopez
- Re: [EAT] [EXTERNAL] Re: [Rats] Attestation BoF c… Guy Fedorkow
- Re: [EAT] [EXTERNAL] Re: [Rats] Attestation BoF c… Laurence Lundblade
- Re: [EAT] [EXTERNAL] Re: [Rats] Attestation BoF c… Laurence Lundblade
- Re: [EAT] [EXTERNAL] Re: [Rats] Attestation BoF c… Henk Birkholz
- Re: [EAT] [EXTERNAL] Re: [Rats] Attestation BoF c… Henk Birkholz
- Re: [EAT] [EXTERNAL] Re: [Rats] Attestation BoF c… Smith, Ned
- Re: [EAT] Attestation BoF charter updates? Laurence Lundblade
- [EAT] Device Identity (was Re: [EXTERNAL] Re: [Ra… Laurence Lundblade
- Re: [EAT] Device Identity (was Re: [EXTERNAL] Re:… Henk Birkholz
- Re: [EAT] Device Identity (was Re: [EXTERNAL] Re:… Laurence Lundblade
- Re: [EAT] Device Identity (was Re: [EXTERNAL] Re:… Henk Birkholz
- Re: [EAT] Device Identity (was Re: [EXTERNAL] Re:… Laurence Lundblade
- Re: [EAT] Device Identity (was Re: [EXTERNAL] Re:… Henk Birkholz
- Re: [EAT] Device Identity (was Re: [EXTERNAL] Re:… Laurence Lundblade
- Re: [EAT] Device Identity (was Re: [EXTERNAL] Re:… Denis
- Re: [EAT] Device Identity (was Re: [EXTERNAL] Re:… Henk Birkholz
- Re: [EAT] Device Identity (was Re: [EXTERNAL] Re:… Carsten Bormann
- Re: [EAT] Attestation BoF charter updates? Jeremy O'Donoghue
- Re: [EAT] [Rats] Attestation BoF charter updates? Michael Richardson
- Re: [EAT] [Rats] Attestation BoF charter updates? Jeremy O'Donoghue
- Re: [EAT] [Rats] Attestation BoF charter updates? Carl Wallace
- Re: [EAT] [Rats] Attestation BoF charter updates? Jeremy O'Donoghue
- Re: [EAT] [Rats] Attestation BoF charter updates? Smith, Ned
- Re: [EAT] [Rats] Attestation BoF charter updates? Smith, Ned
- Re: [EAT] [Rats] Attestation BoF charter updates? Carl Wallace
- Re: [EAT] [Rats] Attestation BoF charter updates? Carl Wallace
- Re: [EAT] [Rats] Attestation BoF charter updates? Eric Voit (evoit)
- Re: [EAT] [Rats] Attestation BoF charter updates? Smith, Ned
- Re: [EAT] [Rats] Attestation BoF charter updates? Carl Wallace
- Re: [EAT] [Rats] Attestation BoF charter updates? Giridhar Mandyam
- Re: [EAT] [Rats] Attestation BoF charter updates? Smith, Ned
- Re: [EAT] [Rats] Attestation BoF charter updates? Carl Wallace
- Re: [EAT] [Rats] Attestation BoF charter updates? Carl Wallace
- Re: [EAT] [Rats] Attestation BoF charter updates? Michael Richardson
- Re: [EAT] [Rats] Attestation BoF charter updates? Michael Richardson
- Re: [EAT] [Rats] Attestation BoF charter updates? Eric Voit (evoit)
- Re: [EAT] [Rats] Attestation BoF charter updates? Jeremy O'Donoghue
- Re: [EAT] [Rats] Attestation BoF charter updates? Jeremy O'Donoghue
- Re: [EAT] [Rats] Attestation BoF charter updates? Jeremy O'Donoghue
- Re: [EAT] [Rats] Attestation BoF charter updates? Henk Birkholz
- Re: [EAT] [Rats] Attestation BoF charter updates? Jeremy O'Donoghue
- Re: [EAT] [Rats] Attestation BoF charter updates? Michael Richardson
- Re: [EAT] [Rats] Attestation BoF charter updates? Jeremy O'Donoghue
- Re: [EAT] [Rats] Attestation BoF charter updates? Eric Voit (evoit)
- Re: [EAT] [Rats] Attestation BoF charter updates? Michael Richardson
- Re: [EAT] [Rats] Attestation BoF charter updates? Henk Birkholz
- Re: [EAT] [Rats] Attestation BoF charter updates? Jeremy O'Donoghue
- Re: [EAT] [Rats] Attestation BoF charter updates? Henk Birkholz
- Re: [EAT] [Rats] Attestation BoF charter updates? Carl Wallace
- Re: [EAT] [Rats] Attestation BoF charter updates? Henk Birkholz
- Re: [EAT] [Rats] Attestation BoF charter updates? Carl Wallace
- Re: [EAT] [Rats] Attestation BoF charter updates? Smith, Ned