[Rats] Yang module comments, plus relation to EAT

Laurence Lundblade <lgl@island-resort.com> Fri, 18 October 2019 17:56 UTC

Return-Path: <lgl@island-resort.com>
X-Original-To: rats@ietfa.amsl.com
Delivered-To: rats@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 3812712000F for <rats@ietfa.amsl.com>; Fri, 18 Oct 2019 10:56:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id C1y7Hk8RaHjx for <rats@ietfa.amsl.com>; Fri, 18 Oct 2019 10:55:59 -0700 (PDT)
Received: from p3plsmtpa06-03.prod.phx3.secureserver.net (p3plsmtpa06-03.prod.phx3.secureserver.net []) (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 F1BFE1200F8 for <rats@ietf.org>; Fri, 18 Oct 2019 10:55:58 -0700 (PDT)
Received: from [] ([]) by :SMTPAUTH: with ESMTPA id LWTjiKfINtyxRLWTlibVAP; Fri, 18 Oct 2019 10:55:58 -0700
From: Laurence Lundblade <lgl@island-resort.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_2723B9BF-67AB-457A-89F5-7FBA8B186701"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Message-Id: <0DFF26D3-5C57-4882-9107-43BC0FFB9006@island-resort.com>
Date: Fri, 18 Oct 2019 10:55:55 -0700
To: rats@ietf.org
X-Mailer: Apple Mail (2.3445.104.11)
X-CMAE-Envelope: MS4wfKDGoGCq6D4FvOiMD26LCQ+XnuuxACkksiZ89KMU5aULJqdmWSMoBZVc77auaO4hdmDuscC+/Wq3/it+pBw4mm2RUQi7Wj0eETkqjNOhKwPJjjClukmo GWvslSCR2LQNw5tQFBHxweQ+fDf9bX2LT0dk2u3BzqSDFpGZGjVA7lGI
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/ChMEb2SJHbwlyMTouucla2mkXWw>
Subject: [Rats] Yang module comments, plus relation to EAT
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: Fri, 18 Oct 2019 17:56:01 -0000

Here’s a few thoughts / questions / comments on the Yang module, some oriented to make EAT and the Yang attestation procedure less ships in the night.

The yang module describes a conveyance protocol, a means of moving attestations over yang-based transports. It should support EAT format attestations as well as TPM-format attestations. 

It is probably be wrong to call the yang module "ietf-basic-remote-attestation” if all it can do is TPM-based attestation. It needs to be able to carry EATs to have that name.

EAT eventually should have claims that can carry the tpml2-quote fields, particularly the PCRs to start paving a path for transition to the more rich and flexible EAT format. I would expect this to be discussed when we work on the EAT measurement issue <https://github.com/ietf-rats-wg/eat/issues/31>.

Seems like there’s some parallel between YANG compute-nodes and EAT submodules. Need a normative reference to know what a compute-node really is.

Seems like uptime is defined identically in EAT and YANG. There is one thing in common for sure. :-)

The draft seems to allows both IETF and TCG schemes for hash algorithm identification. It uses the RFC6920 IDs for IETF hash identification, not the COSE IDs. However it doesn’t seem to use “ni:” URLS or have normative reference to RFC6920. This seems a bit confused. Can we just use one scheme for hash algorithm identification? Seems like COSE would be the one to choose.

Similarly for signature algorithms, can’t we just use COSE IDs?

It looks like UUID are used as a key id. If it is used as a think it is, then it seems a simple random number would be better. COSE key IDs can basically be like that. The internal details of UUID with the clock and time fields seems arcane complexity from a time when good RNGs weren’t available. Implementations can still make them in UUID format. It is just an implementation detail. No one is going actually parse a UUID to get the clock and time fields out.

Is ima this one? https://sourceforge.net/p/linux-ima/wiki/Home/. I’m not sure how that relates to TPMs and TCG. Maybe it doesn’t. IMA is something we want to take into account in work on the EAT measurement issue <https://github.com/ietf-rats-wg/eat/issues/31>.

The document is lacking normative references, for example to IMA (and TCG documents).