[Rats] Attestation key material in architecture document

Laurence Lundblade <lgl@island-resort.com> Wed, 29 July 2020 20:14 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 B37BA3A0EC4 for <rats@ietfa.amsl.com>; Wed, 29 Jul 2020 13:14:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.916
X-Spam-Level:
X-Spam-Status: No, score=-1.916 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_IMAGE_ONLY_32=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 ZgQMHrYMbqvt for <rats@ietfa.amsl.com>; Wed, 29 Jul 2020 13:14:05 -0700 (PDT)
Received: from p3plsmtpa06-06.prod.phx3.secureserver.net (p3plsmtpa06-06.prod.phx3.secureserver.net [173.201.192.107]) (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 F05D63A0EC2 for <rats@ietf.org>; Wed, 29 Jul 2020 13:14:04 -0700 (PDT)
Received: from [192.168.1.78] ([76.167.193.86]) by :SMTPAUTH: with ESMTPA id 0sShkLEQwcPrZ0sShku7Ff; Wed, 29 Jul 2020 13:14:03 -0700
X-CMAE-Analysis: v=2.3 cv=K7hc4BeI c=1 sm=1 tr=0 a=t2DvPg6iSvRzsOFYbaV4uQ==:117 a=t2DvPg6iSvRzsOFYbaV4uQ==:17 a=0XtbOteLAAAA:20 a=tAm32k8MKl9q44iI0Q0A:9 a=g3NJU1hXpT0_Vnhu:21 a=xdCcs7yVuViPddhK:21 a=QEXdDO2ut3YA:10 a=VrleLgnnUxF5ARPw:21 a=PHqvCIgSlQ4GIiCO:21 a=PNK2rG6TL9fDkzpn:21 a=_W_S_7VecoQA:10 a=eK4R_HXFp2ADZQbCsP8A:9 a=UOJ2KywT7WH4NfZ5:18 a=HXjIzolwW10A:10 a=T6a71-JsGAwA:10
X-SECURESERVER-ACCT: lgl@island-resort.com
From: Laurence Lundblade <lgl@island-resort.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_FD633D9E-C7DD-4EF6-B497-FD8284D7EB9E"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Message-Id: <830EC75F-B44E-4F3A-9972-D2196E480DBC@island-resort.com>
Date: Wed, 29 Jul 2020 13:14:03 -0700
To: rats@ietf.org
X-Mailer: Apple Mail (2.3445.104.11)
X-CMAE-Envelope: MS4wfPLrG1quGi1gwSLg+n5Hv5Kcqth+lBU/Aak46j2NgmiZRWIbrAbknQZ/cJBzXupnfPWmKzYXzANzi89zs3kwa3N0UPjZzFXVAeBoSy4tQc6MqNbiJ8Kz Tw7lFMKnpCckefvTjUwIYO+O+FpHXWL0e0lj7uB7cN3q+C7mynrR4Kvg
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/xktCk4CIZ2hIxD9WRu39E8we58I>
Subject: [Rats] Attestation key material 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: Wed, 29 Jul 2020 20:14:08 -0000

I presented this slide below the IETF 108 RATS meeting today. I believe it is critical that the RATS architecture allow for all uses case in the slide. 

In particular RATS architecture must allow for symmetric keys. TPMs and public-key based crypto is too expensive for low-cost, large-scale IoT. There are real use cases supported my multiple companies using symmetric keys. Symmetric keys can be made secure at the verifier — we secure keys for TLS at servers all the time using HSMs and such.

I do NOT want to put this taxonomy into the RATS architecture document. I don’t think that is necessary. I created the taxonomy as background information and as illustrative examples of real world designs. 

I think there are options for adjusting the architecture document to accommodate this.

Option 1) Expand the notion of an Endorsement quite a lot. Endorsements are not longer just static documents like X.509 certs and/or COSE/CMS signed blobs. They are anything that conveys the attestation key material into the Verifier or allows Verification of the attester. They must support confidentiality.

Option 2) Replace the term “Endorsement” with something like “Verifier Input” or “Attester Trust Criteria” in the architecture document as the means by which key material goes into the Verifier. Endorsements still exist, but are just one type of Verifier Input or Attester Trust Criteria just like EAT is one kind of Attestation Evidence.

I have a slight preference for Option 2). I’m interested in opinions of which option to choose.

This is issue #65 <https://github.com/ietf-rats-wg/architecture/issues/65>, opened in GitHub four months ago. It is not a last-minute/new issue. I believe it is in scope with the RATS charter as the charter explicitly mentions attestation key material in the Program of Work.

LL

My main point of this taxonomy was to affect the RATS architecture document. There was discussion today of it being a separate document perhaps outside of RATS. I’m happy for that to happen, but I don’t want to write it because I have enough RATS/EAT work to do. I’m very happy if other folks want to pick it up and use in other documents :-).