[Rats] Out-of-band key material set up in architecture document

Laurence Lundblade <lgl@island-resort.com> Tue, 05 November 2019 20:17 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 A153D120B45 for <rats@ietfa.amsl.com>; Tue, 5 Nov 2019 12:17: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 1TEM0X9Ls3wo for <rats@ietfa.amsl.com>; Tue, 5 Nov 2019 12:17:13 -0800 (PST)
Received: from p3plsmtpa07-01.prod.phx3.secureserver.net (p3plsmtpa07-01.prod.phx3.secureserver.net [173.201.192.230]) (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 CE25F120B7E for <rats@ietf.org>; Tue, 5 Nov 2019 12:17:13 -0800 (PST)
Received: from [10.122.1.38] ([45.56.150.85]) by :SMTPAUTH: with ESMTPA id S5GKiD677KgoPS5GLiTVf4; Tue, 05 Nov 2019 13:17:13 -0700
From: Laurence Lundblade <lgl@island-resort.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_0F0F033C-3AAC-4121-A0B5-7ABD4B8A50A3"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Message-Id: <9B93F41C-3707-4822-B3F5-5F9978872786@island-resort.com>
Date: Tue, 5 Nov 2019 12:17:12 -0800
To: rats@ietf.org
X-Mailer: Apple Mail (2.3445.104.11)
X-CMAE-Envelope: MS4wfF7Tf4jtjZVppibxeb0GiPi+JsF7/kSGBZOSJd3682AumDApFAAp/JzMHuzDg6uIvEcu9vAwGowdTtSKRzJVR5pJeFUmH+cJsjs1YYlNCVtLRFlTbAVm 9cuyoYJBK82bKBApZS/Ygbx2Zkulmuu4aWvPOngQRORduIsPxWCIRddE
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/kWLLIJQmeaRzlnyXb-mVgyX1zVs>
Subject: [Rats] Out-of-band key material set up in architecture document
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: Tue, 05 Nov 2019 20:17:16 -0000

An issue I have with both the current architecture documents is that they do not discuss the need for some out of band key material set up to make verification work.

The manufacturer of the device must put some private key into each device so that the device can sign attestation evidence. Most likely the manufacturer also creates the verifying key material, but they may or may not be the verifier.  If they are not the verifier, somehow the verifier of attestation evidence must have corresponding key material to verify the signature.

This paragraph could be a start of the text. I think this is a critical part of the architecture because attestation doesn’t work without it. 

I do NOT want to specify any details for how this happens in the architecture doc. It needs to stay at a high level. It stays at a high level in other places. For example it discusses claims, but doesn’t defined individual claims.

I think there’s a large parallel with HTTPS. HTTPS wouldn’t work without some out-of-band distribution of certs/keys for verification.

Just like with HTTPS, there are a lot of different business models, protocols and end-end systems that this out-of-band set can be done. Here’s a few that are real today and publicly described:

- Intel EPID (no X.509, the ECDAA algorithm, a service run exclusively by Intel for Intel chips for fee)
- Android Attestation (buckets of keys distributed to phone makers, X.509, a verification service run exclusively by Google)
- FIDO Metadata service (a 3rd party doing X.509 certificate distribution for many FIDO vendors)

I also know of some that are not publicly described that do not use X.509, some even using symmetric key material.

I think business models will drive architecture in some cases. I also think the cost of putting keys into chips and devices is a another driver. A third driver is big IoT back-end service providers like Amazon and Google.

I mention all these only illustrate the variety and thus the futility of trying to come up with one standard way.

However, I think to help the world get their heads around how attestation works; leaving this out of the architecture would be leaving a critical part out.

LL