[Rats] Reviewing EAT for enterprise/cloud use cases

Yaron Sheffer <yaronf.ietf@gmail.com> Fri, 22 November 2019 05:57 UTC

Return-Path: <yaronf.ietf@gmail.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 C373512025D for <rats@ietfa.amsl.com>; Thu, 21 Nov 2019 21:57:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.642
X-Spam-Level:
X-Spam-Status: No, score=-0.642 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MALFORMED_FREEMAIL=1.355, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 5jck8j-n7fUj for <rats@ietfa.amsl.com>; Thu, 21 Nov 2019 21:57:44 -0800 (PST)
Received: from mail-pl1-x62d.google.com (mail-pl1-x62d.google.com [IPv6:2607:f8b0:4864:20::62d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C88A120232 for <rats@ietf.org>; Thu, 21 Nov 2019 21:57:44 -0800 (PST)
Received: by mail-pl1-x62d.google.com with SMTP id j12so2649444plt.9 for <rats@ietf.org>; Thu, 21 Nov 2019 21:57:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=user-agent:date:subject:from:to:message-id:thread-topic :mime-version; bh=aqPgJqoWAUDq5i67XQmdvE7DrDEPOuXbvqQxGs8kf/s=; b=XH2bBnckoL2OpHBj2GGFsQbA4IYu/4APSmEjHAE3jycVX2iNZvTFofxaTk+aP2qFPp M+XQUO8bWLdr/Fd2UwufpNInUtu7xGZk8V94bVNRmo8PKQRVi2EW5NC05mArs2wu/IaG ndwjK8HZyrne81CRHjj78NGUGheFKh5U9CofZi0G6Pns4zQ6/vwOAAcjGo+mn5QAYVw5 I5awv03yLteMAjiCmPWj9KkyPyeKBHpwy6cGSikLtqewYB27V/kAHh7RaRs2n9Gqk6dE 2/oiKjwXlU44guJ3iKztZXd/rzVdJFewz96HQhfjFNsJPM3Wmgi5c9U+36oaqQQpeQSj luvw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:message-id :thread-topic:mime-version; bh=aqPgJqoWAUDq5i67XQmdvE7DrDEPOuXbvqQxGs8kf/s=; b=D5stwxPQbPs/lgefWgkA7ljdV2EOo1KkVk8kz0FpnnwfTlIACH8dJr1kxZAzTPOEtK g++9r0M2GebdO3ZI4Z/PGHm+wXXoKLH7fKhTFOaEFpfbyCHFNh5FbRU5U88pEQxOsp6u UnzOMLlD6D0mm7EVY95KyWZN2h0DTHgCDHDuAKuoynr/LwWAL+bExsZfYEpnRk0YPonj 8iewRKRdrhUPyJDu+cCwiDBlvGK2h/oWj5xDBALd4sTGFR57KDUTIHfw197ewh83lWTd 3fR3bGskz0hTlGD5Pdm1zzCiM0EZ9RNKYxDgQ6RctXo84VWINrEcBOJi/xLkWVNbG0XX PrZg==
X-Gm-Message-State: APjAAAWbzh1E6EeQfvltrgv9gZUH+3nYhkNxNqlHjsRIwIONmWrqENWN OzURUPJVDVSSetIyOVpHGfAKTj8H82o=
X-Google-Smtp-Source: APXvYqw3/1+9T0tEzT1DVEQrI1lePdghh3o1yv3k8OcUaV32ClXCy/BNa4ugBmu2RUAzRgEScZlaNQ==
X-Received: by 2002:a17:90a:610:: with SMTP id j16mr16773456pjj.85.1574402263603; Thu, 21 Nov 2019 21:57:43 -0800 (PST)
Received: from [31.133.155.172] (dhcp-9bac.meeting.ietf.org. [31.133.155.172]) by smtp.gmail.com with ESMTPSA id w7sm5610364pfb.101.2019.11.21.21.57.42 for <rats@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 21 Nov 2019 21:57:42 -0800 (PST)
User-Agent: Microsoft-MacOutlook/10.1f.0.191110
Date: Fri, 22 Nov 2019 13:57:41 +0800
From: Yaron Sheffer <yaronf.ietf@gmail.com>
To: "rats@ietf.org" <rats@ietf.org>
Message-ID: <4EEB506F-5ED6-4DEC-873F-D6D5ABBA04B3@gmail.com>
Thread-Topic: Reviewing EAT for enterprise/cloud use cases
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3657275862_1088954942"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/_pNE-dqcZddAGXCMM2DIjQ5u670>
Subject: [Rats] Reviewing EAT for enterprise/cloud use cases
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, 22 Nov 2019 05:57:46 -0000

I have read the EAT draft, specifically with a “cloud” use case in mind. To clarify, what I'm looking for is the capability:

 

- To attest to software components that are running inside VMs, containers (either on VMs or bare metal), and anonymous containers (function-as-a-service, such as AWS Lambda).

- Such components may be deployed in arbitrary hierarchies (VM-in-VM etc.).

- Attestation of running (as opposed to installed) components. For example, container code may be pulled from a remote repository shortly before it is run.

- To support diverse roots-of-trust, such that when a hardware root-of-trust is unavailable, we can have a hypervisor or an orchestration server (e.g. Kubernetes) as the RoT, even if that means a lower level of trust.

 

I think in general, EAT can be made to fit these use cases, given its recursive structure. But not surprisingly given its origins, the draft would need quite a few changes.

 

* 1.2 (and 3.12): why not spell out that a submodule can be either a hardware or software component?

* 1.2: why *dedicated* root of trust, what is it dedicated to? A RoT may have other functions; a system may in general have multiple RoTs. The word "dedicated" is not repeated anywhere else in the document, nor is it explained.

* 1.3 continues to only talk hardware, e.g. when defining the "manufacturer". Software has a manufacturer too.

* 3.3: the notion of UEID is fundamentally incompatible with some component types that we would wish to attest. For example, the lifetime of a function-as-a-service container may be less than a second, and even if it has an identity during its lifetime, there is no registry or persistent record of this identity. Is a UEID required in this scheme?

* 3.4: hey, finally some software!

 

I think we still don't have a handle on identifying running software, and CosWID may not be the whole answer. CosWID is more like traditional software inventorying, and we need something that will cover dynamic modern software.

 

Thanks,

                Yaron