Re: [EAT] EAT additions to Charter (was Re: Scope, Goals & Background for RATS)

Suresh Marisetty <Suresh.Marisetty@arm.com> Tue, 25 September 2018 19:31 UTC

Return-Path: <Suresh.Marisetty@arm.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 348F712785F; Tue, 25 Sep 2018 12:31:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.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 qPLZpTC9nXz5; Tue, 25 Sep 2018 12:31:16 -0700 (PDT)
Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00062.outbound.protection.outlook.com [40.107.0.62]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E00D12F1AB; Tue, 25 Sep 2018 12:31:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=F1NTjgbTg4L+VUowVm7Ux4BSrdJ9giQANjZa38izr1c=; b=kM+Xi6yD5r5tJrQZXtnVU3Sp4h8PDgnZ3v1CL78HvjidY3E/qS0W+ItniH5fjiE2OBvA/T5B3PGlnTKtRsOks2cSeuJDbENZZtceU08HYhsDiSQzLL+fRu0tdjM3JaEguf6J9Y5CdUblxmv+3QdypG4g0g2D0MyZa0OLCc+Myyg=
Received: from DB7PR08MB3401.eurprd08.prod.outlook.com (20.176.238.94) by DB7PR08MB3305.eurprd08.prod.outlook.com (52.134.111.31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1164.22; Tue, 25 Sep 2018 19:31:12 +0000
Received: from DB7PR08MB3401.eurprd08.prod.outlook.com ([fe80::9505:6d7c:35e9:cd92]) by DB7PR08MB3401.eurprd08.prod.outlook.com ([fe80::9505:6d7c:35e9:cd92%5]) with mapi id 15.20.1143.019; Tue, 25 Sep 2018 19:31:12 +0000
From: Suresh Marisetty <Suresh.Marisetty@arm.com>
To: Laurence Lundblade <lgl@island-resort.com>, Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
CC: "rats@ietf.org" <rats@ietf.org>, "eat@ietf.org" <eat@ietf.org>
Thread-Topic: [EAT] EAT additions to Charter (was Re: Scope, Goals & Background for RATS)
Thread-Index: AQHUVP5TFxUU2ndPBUSJ/vBHhwsh/6UBYKHg
Date: Tue, 25 Sep 2018 19:31:12 +0000
Message-ID: <DB7PR08MB34014702BC6C4942F9C8588897160@DB7PR08MB3401.eurprd08.prod.outlook.com>
References: <710df01c-c45f-9d26-b578-e4baa53c6de8@sit.fraunhofer.de> <9DD41A8E-CE74-45EE-B969-F42DA130FC07@island-resort.com>
In-Reply-To: <9DD41A8E-CE74-45EE-B969-F42DA130FC07@island-resort.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Suresh.Marisetty@arm.com;
x-originating-ip: [217.140.105.40]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DB7PR08MB3305; 6:Sk3sFIS0bhB7AHnIrLprUBPT0MjTuQ5IMmk4qdCbqSQ9dbDCACxHI/WaQE3hCQUezm7LI2vNneSOoTEoXkgvZAmwLgdm+OYlZkZOT3eMqBASd5Ade1tMFbLotd70tD+ozgDce9x1UzA561RUZDwNXrTcpSqAbvB5aLK36+EaVXciRAEHSKsr+ZyoeBg7ovTsoXTb048bPaTSkp241c45un0lpEJVZDV+4RT91xEc42SDdkwdTX6E1ZghnnZjyIVhoA8xSIW6CM8MceFKxqrUcFV3CP3nGf4uooeAUeIdlYKWkHy9fS91j2o7TkqIMcpWqWT92fcUlDGKGf8dHfPA/ZbXVvY1hwoqxw2j0pFvxsvdQFyNwiE0JVgCzkMv0TOa8BP1RqVEshCwK4yMSQ3CId4QOWa4sf8iviXTwi1yQubPTZEXk6uq7pKLtbMxhVCjkNkOZdI8m3l2kfsDH/kIYw==; 5:/nGlPkWDkisQodwg//pa215jy1YbPxHnzNslmxjxCr6oMfQ2P5vg6x9fzrC+X4uRgX34Btk+MiqVKHsNq9AnU4//lIiew35/mgzbeuHr1ObvjJ2BaaSVPiTfG75Cx5J/YrWdBIrFJ8J3pJXFSG8ncE5GASu0hQDt2EGSRxAvs6M=; 7:tIuEp1VuTladDvrh5w+SZ72hUvtGjPdsmn3Mn2MXUo+3HPX+3F5hex9K7YCvAQ7eVcRlGf4FMhmIue6uUrVHXqoK2tDvm0KsIHzDssQ0QmXWiEM3xSqufi0VbdPkcq4IWh+/e7W9r772e0HioOdEomYm12JH5EjEzUd4s1HwrvllI/CXj6xZh0NFjaOo7krxN6AmdRHUqpPemhmS65yWv+PZCHVxWFhDhP9k7W2svkbJqaG3ANunTh5BtDLf2l7b
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 9d279a9f-b0e5-4f34-2da4-08d6231d73c7
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534165)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(4618075)(2017052603328)(7153060)(7193020); SRVR:DB7PR08MB3305;
x-ms-traffictypediagnostic: DB7PR08MB3305:
x-microsoft-antispam-prvs: <DB7PR08MB3305FF3784651C69B2DD4A3597160@DB7PR08MB3305.eurprd08.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(60795455431006)(192374486261705)(278428928389397)(166708455590820)(21748063052155)(28532068793085)(190501279198761)(227612066756510);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3231355)(944501410)(52105095)(10201501046)(93006095)(93001095)(3002001)(6055026)(149066)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123558120)(20161123562045)(20161123560045)(201708071742011)(7699051); SRVR:DB7PR08MB3305; BCL:0; PCL:0; RULEID:; SRVR:DB7PR08MB3305;
x-forefront-prvs: 08062C429B
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(376002)(346002)(136003)(366004)(396003)(40434004)(53754006)(199004)(189003)(74316002)(86362001)(25786009)(102836004)(66066001)(105586002)(106356001)(446003)(256004)(26005)(5024004)(2900100001)(6436002)(81156014)(8936002)(14444005)(7736002)(110136005)(34290500001)(71200400001)(53546011)(76176011)(229853002)(99286004)(6506007)(9326002)(55016002)(5660300001)(186003)(4326008)(476003)(486006)(97736004)(790700001)(3846002)(6306002)(9686003)(966005)(236005)(54896002)(53936002)(8676002)(7696005)(71190400001)(6116002)(81166006)(11346002)(54906003)(551934003)(68736007)(2906002)(14454004)(316002)(33656002)(478600001)(5250100002)(72206003)(6246003)(606006); DIR:OUT; SFP:1101; SCL:1; SRVR:DB7PR08MB3305; H:DB7PR08MB3401.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: gZpoD+SzLgG2AjUEvEJl6Rw0sgN1NqMxiJ5m2uGVwOhBFT407gDwSOGSIBCWf71nIaPKPgxZGpwXa3UeetiTa6dR0gDygesZA+xtnLfajTpPfkxv3j+6MiuRsMWh7NXicBBspBFuEDCpE126JTjtqX609/SxsQk2GXq5SMY6avQH5XeuUM0XdOUo1cf7Jxz3Bxnv1iKPqrdfyfIIMqQJHdbfLXteqfbuytx93jAXu0kPJJ8mTj46ujQtETIBBG7Unph8Q4UT3HqshjEa0y2fVY7+csI38ymeENFvPYrNWJY6ctn/0ga7+8I0RsblxntcdD7KL1+MbN72uHpyQKxSGrrvxXROEChvDPHAp/R5rQE=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_DB7PR08MB34014702BC6C4942F9C8588897160DB7PR08MB3401eurp_"
MIME-Version: 1.0
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 9d279a9f-b0e5-4f34-2da4-08d6231d73c7
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Sep 2018 19:31:12.1359 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR08MB3305
Archived-At: <https://mailarchive.ietf.org/arch/msg/eat/wT_0WqVUzUs9Mi4fvkuSoqdWj2Q>
Subject: Re: [EAT] EAT additions to Charter (was Re: 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: Tue, 25 Sep 2018 19:31:22 -0000

Hi Laurence,

So, it appears that the charter and scope of the CREAT/EAT does not include (Attestation Key Options and Zero Touch Device Onboarding with ownership transfers across entities in the supply chain).

It would be good to mention this as in/out of scope in the charter and refer to other relevant standards/specs for it as appropriate.

For example, IETF has the following for onboarding:

  1.  BRSKI ( Bootstrapping Remote Secure Key Infrastructures)
  2.  SZTP (secure zero touch provisioning - Juniper)

Thanks
Suresh Marisetty


From: EAT <eat-bounces@ietf.org> On Behalf Of Laurence Lundblade
Sent: Tuesday, September 25, 2018 11:32 AM
To: Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
Cc: rats@ietf.org; eat@ietf.org
Subject: [EAT] EAT additions to Charter (was Re: Scope, Goals & Background for RATS)

Here’s my changes for the charter to bring EAT in. The big things are rewrite of (4) and addition of (5).

Also combined (Program Work) and (Goals)

Some edits to first program of (Program Work).

The diffs are in the attached PDF.

LL



(Problem statement)

The problem statement addressed by the working group can be segregated into five inter-connected problems:

(1) Establishing a sufficient level of confidence that a communication partner is a trustworthy endpoint. This is a fundamental challenge. Currently, there are no agreed upon standards that define a minimal set of Reference Values and Attestation Evidence that distinguishes a trustworthy execution environment over one that isn't. There isn't agreement on how to convey it appropriately, how to appraise evidence and how to present the appraisal results in an interoperable fashion. In essence, there is increasing vendor demand for an overall communication, trust and assurance model to establish trust in potentially lying endpoints that is not currently met by other standards.

(2) Current and emerging protocols oftentimes do not contain interfaces for trust establishment in the communication endpoints. Some protocols may contain extensibility features that could serve this purpose, but have not yet been defined.

(3) There is no central alignment process or place for resolving issues related to the application of remote attestation techniques to existing and emerging IETF protocols, e.g. Initial Implicit Attestation via TLS Token Binding, complementary Attestation in OSCORE, YANG modules for conveying Explicit Attestation Evidence about composite devices (e.g. I-D.birkholz-yang-basic-remote-attestation), the Attestation procedures for virtualized network security functions in I2NSF (I-D.pastor-i2nsf-nsf-remote-attestation), or Time-Based Uni-Directional Attestation procedures (e.g. I-D.birkholz-i2nsf-tuda).

(4) Today, there is no common, standard way for Relying Parties to know the provenance and characteristics of the end-user devices that are requesting services of them. For example, there is no common, standard, secure way for a Relying Party to tell if an end-user device is a Linux box pretending to be a phone that is presenting and confirming a financial transaction or not. There are several domain-specific ways to do this such as the various attestation formats used by FIDO and the Android Keystore Attestation format.  Today, risk engines collect large amounts of information from end-user device that are used to determine whether an access to data, a financial transaction or such will be allowed. That data, defined as Claims here, is not standardized for interoperability, is poorly secured in transit and there are few means to prove the provenance of it. Thus, the problems to be solved are:

  *   Definition of a set of interoperable, cross-platform Claims that can be made by Entities (end-user devices, IoT devices, device subsystems and submodules)
  *   Syntax for each Claim in CBOR, JSON and YANG
  *   A framework for securing (e.g., signing) Claims Conveyed to the Relying Party
  *   The Claims and means to secure them should be general and interoperable and as platform and technology neutral as possible (e.g., minimally tied to TPM, TrustZone, JavaCard…).
  *   The definition of the Claims should be largely independent of how they are secured. That is, it should be possible to secure each Claim in different ways without affecting the semantics of the Claim.
  *   The definition of the Claims should be independent of the means of Conveyance (e.g., independent of the transport protocol)
  *   Privacy and GDPR compliance should be considered for each Claim. While not possible for many, Claims should be defined to be privacy preserving.

(5) It is often the case that the manufacturer of an Entity (e.g., a chip, a phone, a tablet) puts some base private key in each device they make. That base key material can then be used to establish key material for specific use cases. Some Entities will host a plethora of use cases and it will be very enabling and efficient to be able to reuse this base private key material over and over (e.g., the Android KeyStore). It is also very beneficial to receive detailed Claims about the Entity’s trustworthiness when establishing use case specific keys. The base private key mentioned here is the key material used to perform the attestation. They problem to be solved then is the definition of Claims that carry use case specific public keys, possibly including proof of possession of those keys (e.g., a Certificate Signing Request).

 (Program of work)

This working group will consolidate the various methods for creating and conveying Attestation Evidence using network protocols created in the IETF to enable semantic interoperability. This solutions created by this working group will consider extant and related technologies from these: the IETF I2NSF WG, Global Platform, the Trusted Computing Group, the Cloud Native Computing Foundation, the Open Connectivity Foundation, the Alliance for Telecommunications Industry Solutions, and the ETSI NFV Industry Specification Group. There should be reuse of, and interoperability with, these when possible.

The following is within this working group's scope:

  *   Architectural components, such as roles, relationships, work-flows and actions
  *   Data formats and protocols for Remote, Explicit, and Implicit Attestation
  *   Protocols and new bindings of protocols (e.g. CoAP) to supply Attestation Policies to a Verifier or Relying Party
  *   Terminology and the interconnected relationships of existing solutions (also as a basis for identifying gaps and new applications)
  *   Attestation procedures for authentication that are based on the operational state of the Attester

The following is outside this working group's scope:

  *   Local Attestation and corresponding "in-box" APIs.
  *   Attestation Policy Formats
  *   Authentication procedure extension that do not convey Attestation Evidence.

As Attestation has acquired many definitions, an early goal for this working group will be a document defining the terms used by attestation, coordinating terminology with the groups and organizations listed above. This provides the various standards a consistent set of terms for their subjects, objects and their relationships.

Architectural Documents (informational):

  *   (1.1) Terminology & Architecture
  *   (1.2) Reference Interaction Models

Solution Documents (standards-track):

  *   (1.3) Definition of a Common set of Claims for Semantic Interoperability
  *   (2.1) YANG Module for Explicit Attestation
  *   (2.2) Explicit Attestation Extension to the I2NSF Architecture using EAT
  *   (2.3) Time-Based Uni-Directional Attestation







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<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

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.