[Rats] EAT and Attestation Results schemes

Laurence Lundblade <lgl@island-resort.com> Wed, 03 November 2021 19:42 UTC

Return-Path: <lgl@island-resort.com>
X-Original-To: rats@ietfa.amsl.com
Delivered-To: rats@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92FFD3A0FD0 for <rats@ietfa.amsl.com>; Wed, 3 Nov 2021 12:42:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.919
X-Spam-Level:
X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-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 vPFDX1n5vj4F for <rats@ietfa.amsl.com>; Wed, 3 Nov 2021 12:42:46 -0700 (PDT)
Received: from p3plsmtpa07-05.prod.phx3.secureserver.net (p3plsmtpa07-05.prod.phx3.secureserver.net [173.201.192.234]) (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 5D0623A0FCF for <rats@ietf.org>; Wed, 3 Nov 2021 12:42:46 -0700 (PDT)
Received: from [192.168.1.7] ([75.80.148.243]) by :SMTPAUTH: with ESMTPA id iM9lmzwV0EvsyiM9lm0f9F; Wed, 03 Nov 2021 12:42:46 -0700
X-CMAE-Analysis: v=2.4 cv=O4n8ADxW c=1 sm=1 tr=0 ts=6182e636 a=VPU1mRQhDhA4uSX60JRRww==:117 a=VPU1mRQhDhA4uSX60JRRww==:17 a=NEAV23lmAAAA:8 a=V1xMNqhdRw3yrrfM-iwA:9 a=QEXdDO2ut3YA:10 a=xBUqPl6juDjXdoeYMuMA:9 a=KYZNROBPp7_yy07z:21 a=_W_S_7VecoQA:10
X-SECURESERVER-ACCT: lgl@island-resort.com
From: Laurence Lundblade <lgl@island-resort.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_406F303A-771C-470F-B4BB-58243DDD10A3"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\))
Message-Id: <0FD2ADD7-25A5-4881-AC9C-0E2950A50458@island-resort.com>
Date: Wed, 03 Nov 2021 12:42:45 -0700
To: rats@ietf.org
X-Mailer: Apple Mail (2.3445.104.17)
X-CMAE-Envelope: MS4xfNSQWwg1cjGKko8u8/zAnXDKpccLPzefrOSLVBEcWaeQL0tuUDvh1RfBZaSczDPfCdm0yfyj5C+jZnYyvoBuCT3CY6EO6gjgxugAxhF9aBlE/aoNCtR8 uUeZfdgt/lUNsukw1I/DdXltIBfRbfPR5Q3kBP6u3ag7Zf+iEWADfXrgQ7OhHw0s2EgbIHkmwBVmOw==
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/rJuTFsea3yUnOr-cdBMFp9obHGQ>
Subject: [Rats] EAT and Attestation Results schemes
X-BeenThere: rats@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Remote ATtestation procedureS <rats.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rats>, <mailto:rats-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rats/>
List-Post: <mailto:rats@ietf.org>
List-Help: <mailto:rats-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rats>, <mailto:rats-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Nov 2021 19:42:51 -0000

Hi folks,

There’s been a side discussion on Attestation Results and I want to bring some of it to the general list. To start, here’s some framing on how I see Attestation Results and EAT.


First, I think there will be several, perhaps many, schemes/drafts/claims for Attestation Results because of varying use cases and requirements. Financial use cases may be different than phones which may be different from routers, tiny IoT devices… I don’t think one-size-fits all is possible.

Here’s some examples:
HTTPS/JSON/EAT-based with a very simple yeah/nay result for allowing devices onto the network
Eric’s proposal using HTTP/JWT/EAT for encoding, perhaps for TPM-using devices
Eric’s proposal using YANG
Composite chain of Verifiers with partially results using EAT with both CBOR and JSON (we have composite Attester so we’ll probably have corresponding composite Verifiers) involving high-security devices with both a TEE and SE
RP uses a ML-based risk engine and wants every claim from the Attester plus all the implicit claims added by the Verifier for a widely used financial use case


Just like with Attestation Evidence, I see EAT as a basis to serve many different use cases for Attestation Results, roughly as follows:

Other AR encodings and formats (YANG,...) are fine, along side of EAT
EAT has a few claims for AR now, and I expect lots of others to be added
Easy to use CDDL to define new AR claims that go into EAT and can be encoded in both JSON and CBOR
EAT is not an AR solution in and of itself; it is more of a framework
EAT profiles can be made for locked down specific AR solutions

Last, I’ve made a PR for a very simple enumerated result code for EAT <https://github.com/ietf-rats-wg/eat/pull/137> — success, fail, malfunction, wrong input type. It is intended for use for AR, but not exclusively, nor is there any requirement that every AR format use it (or every AR format use EAT). It just seems like a very useful addition to EAT to have such a general result code.

It is not extensible or a framework for error codes. If you want more detail, strings and such create your own claims.

It is intended to be complementary to Eric’s AR draft.

LL