WG Action: Formed Remote ATtestation ProcedureS (rats)
The IESG <iesg-secretary@ietf.org> Thu, 07 March 2019 19:59 UTC
Return-Path: <iesg-secretary@ietf.org>
X-Original-To: ietf-announce@ietf.org
Delivered-To: ietf-announce@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 385B51310F0; Thu, 7 Mar 2019 11:59:13 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Subject: WG Action: Formed Remote ATtestation ProcedureS (rats)
X-Test-IDTracker: no
X-IETF-IDTracker: 6.93.0
Auto-Submitted: auto-generated
Precedence: bulk
Cc: rats@ietf.org, rats-chairs@ietf.org, The IESG <iesg@ietf.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-ID: <155198875322.5377.13783028392555492168.idtracker@ietfa.amsl.com>
Date: Thu, 07 Mar 2019 11:59:13 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-announce/qOmHkhyleiuTJ_aw9AhPNYzDo3o>
X-BeenThere: ietf-announce@ietf.org
X-Mailman-Version: 2.1.29
List-Id: "IETF announcement list. No discussions." <ietf-announce.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf-announce>, <mailto:ietf-announce-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf-announce/>
List-Post: <mailto:ietf-announce@ietf.org>
List-Help: <mailto:ietf-announce-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-announce>, <mailto:ietf-announce-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Mar 2019 19:59:14 -0000
A new IETF WG has been formed in the Security Area. For additional information, please contact the Area Directors or the WG Chairs. Remote ATtestation ProcedureS (rats) ----------------------------------------------------------------------- Current status: BOF WG Chairs: Kathleen Moriarty <Kathleen.Moriarty.ietf@gmail.com> Nancy Cam-Winget <ncamwing@cisco.com> Ned Smith <ned.smith@intel.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.