[secdir] [new-work] WG Review: Remote ATtestation ProcedureS (rats)

The IESG <iesg@ietf.org> Tue, 19 February 2019 04:49 UTC

Return-Path: <new-work-bounces@ietf.org>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A4A0130E77; Mon, 18 Feb 2019 20:49:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1550551761; bh=fLM4GiDy+mII/ZfmVEFZZBtJq/4enmKYcaH5aOeFne0=; h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=qwoqAq+EFzS/o6PJTQVoQbUOvB6PELUXB+OF4WacqekkmJ7S7RGeFLZ4h+psQG5LM prLiX9ztMu9FQjej68kfSzqOPLkGcPB1cdmObLORu6Njc08M5OkA64Xw69E+edJ+ux xxMeaCWs3mWq0o9Fwy9078cMBsliYyTvXEiopqIo=
X-Mailbox-Line: From new-work-bounces@ietf.org Mon Feb 18 20:49:17 2019
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A4D6C131027; Mon, 18 Feb 2019 20:49:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1550551756; bh=fLM4GiDy+mII/ZfmVEFZZBtJq/4enmKYcaH5aOeFne0=; h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=guVzjBMXvJPU3+wv/b9p9geqKVao/eqNuS5itr3MKawUkqRI5ek1v/WtLfc7PE69Y 4wz7w38XS6Vg+XupHXPsMDTiR5QYdd6IOTXNe2wsT9ePw+mxVNdzC8wo6T8RttH/9E Q60V5SmYcl8UjhMlTtOT+bJ7V4zcUZZIzy2EOsnM=
X-Original-To: new-work@ietf.org
Delivered-To: new-work@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3ABDD130E6D for <new-work@ietf.org>; Mon, 18 Feb 2019 20:49:08 -0800 (PST)
MIME-Version: 1.0
From: The IESG <iesg@ietf.org>
To: <new-work@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.91.0
Auto-Submitted: auto-generated
Precedence: bulk
MIME-Version: 1.0
Reply_to: <iesg@ietf.org>
Message-ID: <155055174823.25950.11953954322952379120.idtracker@ietfa.amsl.com>
Date: Mon, 18 Feb 2019 20:49:08 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/new-work/XXoT5gfMrLm8-r0SAbz6KX0nkJ4>
X-BeenThere: new-work@ietf.org
X-Mailman-Version: 2.1.29
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: new-work-bounces@ietf.org
Sender: "new-work" <new-work-bounces@ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/HZ7VViUVYSAYEmJJvViqzo0E2U0>
X-Mailman-Approved-At: Tue, 19 Feb 2019 08:04:54 -0800
Subject: [secdir] [new-work] WG Review: Remote ATtestation ProcedureS (rats)
X-BeenThere: secdir@ietf.org
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 19 Feb 2019 04:49:26 -0000

A new IETF WG has been proposed in the Security Area. The IESG has not made
any determination yet. The following draft charter was submitted, and is
provided for informational purposes only. Please send your comments to the
IESG mailing list (iesg@ietf.org) by 2019-02-28.

Remote ATtestation ProcedureS (rats)
-----------------------------------------------------------------------
Current status: BOF WG

Chairs:
  Nancy Cam-Winget <ncamwing@cisco.com>
  Roman Danyliw <rdd@cert.org>

Assigned Area Director:
  Benjamin Kaduk <kaduk@mit.edu>

Security Area Directors:
  Eric Rescorla <ekr@rtfm.com>
  Benjamin Kaduk <kaduk@mit.edu>

Mailing list:
  Address: rats@ietf.org
  To subscribe: https://www.ietf.org/mailman/listinfo/rats
  Archive: https://mailarchive.ietf.org/arch/browse/rats/

Group page: https://datatracker.ietf.org/group/rats/

Charter: https://datatracker.ietf.org/doc/charter-ietf-rats/

Introduction
==========

In network protocol exchanges, it is often the case that one entity (a relying
party) requires evidence about the remote peer (and system components
[RFC4949] thereof), in order to assess the trustworthiness of the peer. 
Remote attestation procedures (RATS) enable relying parties to establish a
level of confidence in the trustworthiness of remote system components
through the creation of attestation evidence by remote system components and
a processing chain towards the relying party.  A relying party can then
decide whether to consider a remote system component trustworthy or not.

To improve the confidence in a system component's trustworthiness, a relying
party may require evidence about:
* system component identity,
* composition of system components, including nested components,
* roots of trust,
* assertion/claim origination or provenance,
* manufacturing origin,
* system component integrity,
* system component configuration,
* operational state and measurements of steps which led to the operational
state, or * other factors that could influence trust decisions.

While domain-specific attestation mechanisms such as Trusted Computing Group
(TCG) Trusted Platform Module (TPM)/Trusted Software Stack (TSS), Fast
Identity Online (FIDO) Alliance attestation, and Android Keystore attestation
exist, there is no interoperable way to create and process attestation
evidence to make determinations about system components among relying parties
of different manufactures and origins.

Goals
=====

This WG will standardize formats for describing assertions/claims about system
components and associated evidence; and procedures and protocols to convey
these assertions/claims to relying parties.  Given the security and privacy
sensitive nature of these assertions/claims, the WG will specify approaches to
protect this exchanged data.  While a relying party may use reference, known,
or expected values or thresholds to assess the assertions/claims, the
procedures for this activity are out of scope for this WG (without
rechartering).

The working group will cooperate and coordinate with other IETF WGs such as
TEEP, SUIT, and SACM, and work with organizations in the community, such as
the TCG and the FIDO Alliance, as appropriate.  The WG will also evaluate
prior work such as NEA and proprietary attestation technologies like the
Android Keystore.

Program of Work
==============

The working group will develop standards supporting interoperable remote
attestation procedures for system components. The main deliverables are as
follows:

1. Specify use cases for remote attestation (to document and achieve WG
consensus but not expected to be published as an RFC).

2. Specify terminology and architecture that enable attestation techniques.
The architecture may include a system security model for the signing key
material and involve at least the system component, system component provider,
and the relying authority.

3. Standardize an information model for assertions/claims which provide
information about system components characteristics scoped by the specified
use-cases.

4. Standardize data models that implement and secure the defined information
model (e.g., CBOR Web Token structures [RFC8392], JSON Web Token structures
[RFC7519]).

5. Standardize interoperable protocols to securely convey assertions/claims.

Milestones:

TBD

_______________________________________________
new-work mailing list
new-work@ietf.org
https://www.ietf.org/mailman/listinfo/new-work