[Rats] More claims? When is EAT done?

Laurence Lundblade <lgl@island-resort.com> Wed, 13 November 2019 20:21 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 087391208A4 for <rats@ietfa.amsl.com>; Wed, 13 Nov 2019 12:21:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Level:
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 HGoYU4CSYlw7 for <rats@ietfa.amsl.com>; Wed, 13 Nov 2019 12:21:13 -0800 (PST)
Received: from p3plsmtpa09-04.prod.phx3.secureserver.net (p3plsmtpa09-04.prod.phx3.secureserver.net [173.201.193.233]) (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 1D617120831 for <rats@ietf.org>; Wed, 13 Nov 2019 12:21:13 -0800 (PST)
Received: from [192.168.1.80] ([76.167.193.86]) by :SMTPAUTH: with ESMTPA id Uz8TiaShTMx9SUz8Vi8vyf; Wed, 13 Nov 2019 13:21:12 -0700
From: Laurence Lundblade <lgl@island-resort.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_C6EAC7A6-6FAA-44BC-AA75-6B70AC84A93F"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Message-Id: <F3E47CB1-93F0-4B0B-8195-A127321F5A73@island-resort.com>
Date: Wed, 13 Nov 2019 12:21:03 -0800
To: rats@ietf.org
X-Mailer: Apple Mail (2.3445.9.1)
X-CMAE-Envelope: MS4wfB5MerFfJGhQqU4ugWHTcoAxALWCY5IBxqUCixPwnYkDvYWBa6nJCxZ7qkv12BcdZaW7XF1dPo6YA6q7/P6ggDoJpAu6lRnWKqQr/ZFZCKqPRF3xuaQ+ e7yY+szKUeWt+Z4TUTFmvv4jg6uKqQn/Up2MWHyEQSfoXKQw2aH5d4rj
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/LXq1JH-w16L6qXeyBblKTkQ_-FA>
Subject: [Rats] More claims? When is EAT done?
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, 13 Nov 2019 20:21:15 -0000

One of my requested topics for Singapore is that of which new claims we should add to the current EAT draft and which ones should be left for subsequent work. This list here is a bit rough, but I wanted to get it in front of everyone sooner rather than later for some think / discussion time before meeting.

SW Inventory
This claim / set of claims would list SW installed on the device. It would probably include:
Name
Version
Checksum
Who signed it
This seems important for a lot of use cases including routers and IoT. It is important in RIV.
This seems like a relatively complex topic.

Measurements and Integrity Checks
The claims here could either be measurements that need to be checked or the result of a measurement after comparison with k-g-v. Note that systems like TIMA check against k-g-v on the device. So claims might look like:
Name
Measurement value
Measurement result (likely a Boolean)
Timestamp
This seems important for use cases including routers and mobile phones. It shows up in RIV.
This seems like a relatively complex topic.

Public Key
The claim would be a public key and its characteristics. Something like this:
The public key
How it is protected (TEE, secure element…)
User verification required to use it
Other key use and ownership characteristics (Android key store has implemented many of these)
This seems important for the mobile app world, particularly that this is supported by Android now. FIDO and WeChat pay have options to use the Android Keystore. This also seems important for IoT on boarding, particularly establishing a certificate for use with DTLS.

Attestation Result
An attestation result can be expressed as an EAT. For example a TPM / YANG interaction between the device and verifier might happen. The verifier outputs the result in EAT format. This is also likely where implicit claims are made explicit for the relying party. Interesting claims here might be:
Origination (an existing claim)
Certifications received
All other existing claims

While new claims can be added anytime through the IANA registry, I’d like to see the EAT document have a very solid set of well thought out core claims. My inclination is to do the work on all of these, even if it takes longer to get EAT done.

LL