Re: [Rats] Call for adoption (after draft rename) for Yang module draft

Henk Birkholz <henk.birkholz@sit.fraunhofer.de> Mon, 11 November 2019 09:57 UTC

Return-Path: <henk.birkholz@sit.fraunhofer.de>
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 818F512080F for <rats@ietfa.amsl.com>; Mon, 11 Nov 2019 01:57:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-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 3LL_l7kIowWv for <rats@ietfa.amsl.com>; Mon, 11 Nov 2019 01:57:49 -0800 (PST)
Received: from mailext.sit.fraunhofer.de (mailext.sit.fraunhofer.de [141.12.72.89]) (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 64E4112081F for <rats@ietf.org>; Mon, 11 Nov 2019 01:57:47 -0800 (PST)
Received: from mail.sit.fraunhofer.de (mail.sit.fraunhofer.de [141.12.84.171]) by mailext.sit.fraunhofer.de (8.15.2/8.15.2/Debian-10) with ESMTPS id xAB9vcia016321 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA256 bits=128 verify=NOT); Mon, 11 Nov 2019 10:57:39 +0100
Received: from [134.102.155.87] (134.102.155.87) by mail.sit.fraunhofer.de (141.12.84.171) with Microsoft SMTP Server (TLS) id 14.3.468.0; Mon, 11 Nov 2019 10:57:33 +0100
To: "Nancy Cam-Winget (ncamwing)" <ncamwing@cisco.com>, Michael Richardson <mcr+ietf@sandelman.ca>, "rats@ietf.org" <rats@ietf.org>
References: <8B173958-FC2A-4D1D-A81C-F324AB632CD7@cisco.com> <147F9159-6055-4E55-ABDC-43DFE3498BF1@island-resort.com> <ce5f8206-74dc-36bb-0093-a93045d5c67f@sit.fraunhofer.de> <0A7E3A4F-8534-4E98-BCB7-1454E07699F4@island-resort.com> <C3AE2645-49C8-4313-BCED-02FEB576B614@cisco.com> <1C8A1884-A37D-45E3-8C11-2FC5A083B245@island-resort.com> <ba12a686-1b34-21a3-388c-bbe01c01a408@sandelman.ca> <1DFA7D52-7294-4705-9407-C34F5BC82EA6@cisco.com>
From: Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
Message-ID: <5f57dd25-f561-e07d-4b24-fef05627bac9@sit.fraunhofer.de>
Date: Mon, 11 Nov 2019 10:57:32 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <1DFA7D52-7294-4705-9407-C34F5BC82EA6@cisco.com>
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Originating-IP: [134.102.155.87]
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/jZbE0hO9Frq42PxVX8hF5ZWUclU>
Subject: Re: [Rats] Call for adoption (after draft rename) for Yang module draft
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: Mon, 11 Nov 2019 09:57:53 -0000

Hi all,

on one hand, we have to address the overlap between YANG and EAT 
information elements (statements & Claims) and how to deal with them 
(one obvious issue, for example, would be potential redundant 
information model content in two different drafts).

On the other hand, Laurence's original point was the payload of 
conveyance protocols used by RATS. Specializations of this topic are 
apparently:

* Web Tokens via YANG Interfaces, and
* YANG modeled data via other conveyance protocols (other than *CONF) 
that can transport Web Tokens.

There are examples of how YANG modeled data is used outside of *CONF 
protocols, for example MUD. We have to understand and agree about:

* this is possible on a technical level, and
* this is useful wrt to protocol scope, intent & semantics, I think.

This is one items of the 5 minutes slot I gave back. And I am happy to 
see this on the list.

Viele Grüße,

Henk

On 11.11.19 06:39, Nancy Cam-Winget (ncamwing) wrote:
> Hi Michael,
> See comments below:
> 
> On 11/10/19, 9:21 PM, "RATS on behalf of Michael Richardson" <rats-bounces@ietf.org on behalf of mcr+ietf@sandelman.ca>; wrote:
> 
>      
>      
>      On 2019-11-11 6:44 a.m., Laurence Lundblade wrote:
>      >
>      >> On Nov 10, 2019, at 2:20 PM, Nancy Cam-Winget (ncamwing)
>      >> <ncamwing@cisco.com <mailto:ncamwing@cisco.com>> wrote:
>      >>
>      >> So, Laurence, are you still OK with the adoption of the current draft
>      >> with a rename for now?
>      >> Thanks, Nancy
>      
>      You suggested the name:
>      
>      “Yang Module for TPM based Remote Attestations”
>      
>      But, I think that it should say instead, "Yang Interface to TPM 2.0"
> [NCW] That is a fair point.....my point is that it should be named to reflect core of description which is based around TPMs.
>      
>      >
>      > I think the value add to the larger RATS effort of adding EAT support
>      > to this YANG protocol is really high. It a core thing to do that helps
>      > bring together the two attestation worlds and make the TPM and EAT
>      > work here less like ships in the night.
>      
>      Can you explain what it would mean to add EAT support for a YANG module?
>      Maybe I'm daft here.
> [NCW]. Hmmm, I did NOT state that?  I think that was Laurence.  I view EAT as defining claims that use  JWT/CWT data structures.
> If there are claims (not format) that can be represented in Yang, then yes (and I think some can).  But the "general EAT", I'm not
> sure how those structures map to the TPM interfaces...but they certainly could be represented in YANG.
>      
>      The current document is essentially a YANG wrapper around the TPM 2.0
>      specification.  It's RPC, data in motion.
>      
>      While EAT is primary a JWT/CWT object, which is data-at-rest.
>      I think that you are looking for a way to express non-TCG defined
>      evidence containers.
> [NCW] I'm not sure why these object would be data-at-rest?  I view them as claims represented in specific structures, e.g. JWT/CWT
> But can be transported using any transport (e.g. TLS, et al)....similar to YANG?
> While it is true that the YANG draft also exposes the TPM interface, it also contains the claims albeit that are TPM specific.
> So perhaps you are referring to the interface aspect?
> 
> Best, Nancy
>      
>      
>      
>      
> 
> _______________________________________________
> RATS mailing list
> RATS@ietf.org
> https://www.ietf.org/mailman/listinfo/rats
>