Re: [Rats] About current RATS drafts

Laurence Lundblade <lgl@island-resort.com> Fri, 01 November 2019 14:25 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 A38781200E7 for <rats@ietfa.amsl.com>; Fri, 1 Nov 2019 07:25:07 -0700 (PDT)
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, DC_PNG_UNO_LARGO=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=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 iunnza740Jj8 for <rats@ietfa.amsl.com>; Fri, 1 Nov 2019 07:25:05 -0700 (PDT)
Received: from p3plsmtpa09-02.prod.phx3.secureserver.net (p3plsmtpa09-02.prod.phx3.secureserver.net [173.201.193.231]) (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 76EE5120043 for <rats@ietf.org>; Fri, 1 Nov 2019 07:25:05 -0700 (PDT)
Received: from [10.122.0.250] ([45.56.150.85]) by :SMTPAUTH: with ESMTPA id QXrKiLDQsyg8JQXrLiNnhi; Fri, 01 Nov 2019 07:25:04 -0700
From: Laurence Lundblade <lgl@island-resort.com>
Message-Id: <26A6D463-2635-456F-B0F9-78075B07FDC4@island-resort.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_CC279F7F-A670-4759-9E9F-1F2FE7B021A7"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Fri, 1 Nov 2019 07:25:02 -0700
In-Reply-To: <CAA8pjUMnQ7defSFS8Wz6uw5V1ahiGZMUdSrgmwM6Bh25WN8Ohw@mail.gmail.com>
Cc: rats@ietf.org
To: H Y <yuuhei.hayashi@gmail.com>
References: <CAA8pjUMnQ7defSFS8Wz6uw5V1ahiGZMUdSrgmwM6Bh25WN8Ohw@mail.gmail.com>
X-Mailer: Apple Mail (2.3445.104.11)
X-CMAE-Envelope: MS4wfInoXyeR5Oc2UcU1noyUKoYZs/n0uGD78HfRXwq4025uXftNgp5VxmJlRJfFirAbIWHJZGRw55/bN78LOJlLV4F5OPYi1WZfXjLYjhfzfudj9GkCKXL6 +tJjhdRi5VZ/f0IlGMUBjTwHG9MCQE7/bCIuAE/Rk7TBUqtwYMGCk7kDIvAIQMAvz/kGrss/xSBWSUR5NFs9efU8sB56BmfFbe8=
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/hJUmF4gXAQ-2ekP58TIHh_jm8io>
Subject: Re: [Rats] About current RATS drafts
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, 01 Nov 2019 14:25:08 -0000

Hello,

A frame up that works for me is to think about 1) the claims, the attestation format and its details and 2) the transport / conveyance and its details.

In the TPM/TCG world the claims and attestation format is locked down by what TPM chips do today. It is a set of registers that hold hash values used to measure software.  In the EAT world, which typically implements on fully functional CPUs, the claims and attestation format is not at all locked down and our work is to define it (the eat draft).

A lot of the network and router folks have been putting TPMs into their routers and now need a way to get the TPM output off the router to the network management center. This world runs off of Yang protocols. The main interest there is a very specific Yang-based way to move TPM output. This is the yang, tuda and pubsub drafts.

The EAT use cases are more about TEE’s and lining up with end-user-application-oriented uses like FIDO and the Android key store. They make use of all the existing transports used by application protocol (mainly HTTP) so there’s no worry about defining transport.

I think a few of us see EAT as the more general and flexible attestation format that will eventually replace the TPM format. Because EAT can use CBOR and COSE which are carefully designed for constrained devices there is some hope that it can go into TPM-like HW.

The architecture draft is trying to tie the two together in a sort of unified field theory. Seems possible, but hard to me.

LL





> On Nov 1, 2019, at 5:08 AM, H Y <yuuhei.hayashi@gmail.com> wrote:
> 
> Hi all,
> 
> I'm Yuhei Hayashi, network security researcher of NTT in Japan. I
> learned about the existence of RATS WG at IETF 105.
> 
> I'm interested in the work of RATS WG and I'm trying to understand it.
> So, I'm firstly trying to understand which drafts contain the
> standards listed in the charter.
> 
> I will attach the result of organizing it from my own point of view.
> I'm glad if you confirm that my understanding is correct, if possible.
> 
> Thanks,
> Yuhei
> -- 
> ----------------------------------
> Yuuhei HAYASHI
> yuuhei.hayashi@gmail.com
> ----------------------------------
> <RATS_drafts.pdf>_______________________________________________
> RATS mailing list
> RATS@ietf.org
> https://www.ietf.org/mailman/listinfo/rats