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

Laurence Lundblade <lgl@island-resort.com> Fri, 15 November 2019 19:13 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 734EE1209BF for <rats@ietfa.amsl.com>; Fri, 15 Nov 2019 11:13:53 -0800 (PST)
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, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 9xY3Uuwuv-nL for <rats@ietfa.amsl.com>; Fri, 15 Nov 2019 11:13:50 -0800 (PST)
Received: from p3plsmtpa06-01.prod.phx3.secureserver.net (p3plsmtpa06-01.prod.phx3.secureserver.net [173.201.192.102]) (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 81114120A3D for <rats@ietf.org>; Fri, 15 Nov 2019 11:13:50 -0800 (PST)
Received: from [10.141.0.74] ([45.56.150.139]) by :SMTPAUTH: with ESMTPA id Vh2QiucA5MfejVh2SiRd2n; Fri, 15 Nov 2019 12:13:48 -0700
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Laurence Lundblade <lgl@island-resort.com>
In-Reply-To: <DM6PR11MB41548D92CF35A134264E56E1A1710@DM6PR11MB4154.namprd11.prod.outlook.com>
Date: Fri, 15 Nov 2019 11:13:46 -0800
Cc: "Smith, Ned" <ned.smith@intel.com>, Henk Birkholz <henk.birkholz@sit.fraunhofer.de>, =?utf-8?B?IlNjaMO2bnfDpGxkZXIsIErDvHJnZW4i?= <J.Schoenwaelder@jacobs-university.de>, "Nancy Cam-Winget (ncamwing)" <ncamwing@cisco.com>, "Oliver, Ian (Nokia - FI/Espoo)" <ian.oliver@nokia-bell-labs.com>, Dave Thaler <dthaler@microsoft.com>, "rats@ietf.org" <rats@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <B6DF89B0-6BB9-430D-8741-A3010045414D@island-resort.com>
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> <HE1PR0702MB375366C5F7FE5C497C35D73B8F740@HE1PR0702MB3753.eurprd07.prod.outlook.com> <7106C9D3-8ED1-419E-81F8-4CDA799BEDAE@intel.com> <MWHPR21MB07844F61BEFAE03F9E7DD290A3770@MWHPR21MB0784.namprd21.prod.outlook.com> <6E7D64B4-2049-4D0A-ADC5-CA3F0647779B@island-resort.com> <20191114140600.itrr5mjiysgutsj5@anna.jacobs.jacobs-university.de> <59707a99-8cec-2005-b1ee-72f171234cbe@sit.fraunhofer.de> <DM6PR11MB4154A67956517DF2D9D305ADA1710@DM6PR11MB4154.namprd11.prod.outlook.com> <5C6D6C7C-05DC-4103-9A80-A029F0151996@intel.com> <DM6PR11MB41548D92CF35A134264E56E1A1710@DM6PR11MB4154.namprd11.prod.outlook.com>
To: "Eric Voit (evoit)" <evoit@cisco.com>
X-Mailer: Apple Mail (2.3445.104.11)
X-CMAE-Envelope: MS4wfH/ktVRj273FyuuHixHX5fb+7jC9vk6GAyKqc5YV+g6I9PgptgtVcRgk/yleJo1AqStEW6eJEy1JphwWIdENACBa44A2SR0qNLWCDBpLNce29f9rr8cj /5XLVLp+30aXGaM15mMmsZTHp42Z91WScVDdhe+Oz3tcHy+jf2F5vaA9G0I1qmk5OeFwvtihTljkN+ISxQYG4n/mmpfrF9HTuYVeW3msUH5ZXXuPGFr2PSDn mrGVkKXBqTo0uTfiMgphSDBmxrJug4Cbv4Ae+MlY7elPxC3GjjhgJZ5L/l3O2fwZ0BFZn7XPmEg/o3XJ0Gb/Wn3DaV7dN8w0qOkWvjYaQYRqUkSoPM5YAeYW Sv5AAkxS0GchykLVimvJNyBl6haGxibszpmQ72BzVFim1dhU7ChM5WdUfypX3vbhbLfpw1sQ
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/OWoyJr9E8JtRNtjY1SIH-o-DlFM>
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: Fri, 15 Nov 2019 19:13:54 -0000

Here’s a try at an analogy of EAT Tokens with X.509 Certificates.

For both the core of the definition is of the signed serialized data format. A set of fields / claims is defined in the core standard. That core standard is solely focused on the definition of those fields / claims and shouldn't get intertwined with other protocol definitions.

However, other protocols may decide to have fields that are the same as, maybe even defined in terms of the fields  / claims in the token / certificate. Those definitions are probably normative references to the fields / claims in the core token / certificate standard. TLS makes normative references to PKIX this way in section 4.2.5. I think this is perfectly reasonable things to do.

So, I have no trouble with some EAT claims being used in YANG designs, but I’d like it to be by reference to EAT. I’d also like EAT to only use CDDL for the data model and nothing else.

I think trying for a single information model that is common to EAT and YANG designs is too big, too much intertwining and is scary. It will lead to schedule interlocks between the documents.

Another reason is that I view router / YANG use of attestation as only one (well-represented) use case for EAT. YANG-based use cases shouldn’t be central to EAT's design. If we were to intertwine with YANG, maybe we should intertwine with JavaScript and a bunch of IoT protocols too.

LL




> On Nov 14, 2019, at 12:42 PM, Eric Voit (evoit) <evoit@cisco.com>; wrote:
> 
> My belief is that a Relying Party will rarely want the full universe of signed claims coming from some Attester's chip.   We need ways to pre-filter the results.  How would we do this without a model?
> 
> To fill this need, I always hoped that EAT claims could become leafs of some future YANG data model.  This would allow GET and SUBSCRIBE requests to be made to an Attester.  What would be returned to the Relying Party would be the signed results of interest from some chip within the Attester.  
> 
> I have no position on whether the WG wants to integrate GET and SUBSCRIBE requests so that they can provision claims are ultimately placed within the EAT token.
> 
> Eric
> 
>> @Eric Voit (evoit) Is this suggesting that RATS architecture should define a
>> token-like DM structure that is a *request* "token" having only tags
>> identifying interesting claims while a *response* "token" would have claims
>> with data values populated?
>> 
>> On 11/14/19, 8:02 AM, "Eric Voit (evoit)" <evoit@cisco.com>; wrote:
>> 
>>    Hi Jürgen,
>>    Hi Henk,
>> 
>>    What routers need is exactly what you said.
>>     - currently: the retrieval of TPM originated/signed quotes.
>>     - in the future: the retrieval EAT Tokens
>> 
>>    Knowing when to retrieve these items is a function of the value of specific
>> claims inside those structures.  For example, I might want to use RFC-8641 to
>> make a YANG Subscription to a router so that I will be pushed the latest TPM
>> quote when a specific PCR changes.  For this to work in the router world, we
>> must have the structures of Quotes/Tokens exposed by a YANG model.
>> 
>>    Eric
>> 
>>> Hi Jürgen,
>>> 
>>> I think this is very useful input.
>>> 
>>> On the list, Laurence and I already started to discuss Claims for "YANG
>>> modeled data" and Claims for "TPM modled data" (referred to as tpm
>> tokens
>>> recently).
>>> 
>>> The remaining questions are about: What do you think is the
>> upcoming/TBD
>>> impact on the current YANG module for challenge-response RATS?
>>> 
>>> Leveraging YANG modeled data comes up again and again. Maybe there
>> is
>>> good approach here.
>>> 
>>> The TPM Interface based YANG Module does not simply convey native
>> TPM
>>> structure, but decomposes them down the values that are useful and
>>> common on the management plane because the building blocks
>> themselves
>>> have well defined semantics (always ensuring canonical re-composition).
>>> 
>>> Viele Grüße,
>>> 
>>> Henk
>>> 
>>> On 14.11.19 15:06, Schönwälder, Jürgen wrote:
>>>> On Wed, Nov 13, 2019 at 10:07:02AM -0800, Laurence Lundblade
>> wrote:
>>>>> 
>>>>> I see EAT as applicable to all these worlds, where the YANG module is
>> just
>>> for the smallish router world. So I mostly agree with Dave about
>> proportions,
>>> however this is the IETF where YANG modules are created.  (Maybe I
>> should
>>> go join the W3C world and work on attestations APIs for browsers after
>> RATS
>>> is done).
>>>>> 
>>>> 
>>>> If EAT is the common format for "token", then it does not make sense
>>>> to me to define a YANG version of it. It may make sense to carry EAT
>>>> token over protocols such as NETCONF or RESTCONF and to have a
>> YANG
>>>> module defining this may make sense for the networking device world.
>>>> This is then a definition of an interaction protocol, but not the
>>>> token format itself.
>>>> 
>>>> If EAT is the common format for "token", then it may make sense to be
>>>> able to include "claims" that are YANG defined data. That may be an
>>>> extension of the core EAT definition (but EAT would have to allow for
>>>> such an extension to work). There is a lot of formally defined data in
>>>> YANG modules that would be convenient to reuse as claims in a
>>>> networking world.
>>>> 
>>>> /js
>>>> 
>>> 
>>> _______________________________________________
>>> RATS mailing list
>>> RATS@ietf.org
>>> https://www.ietf.org/mailman/listinfo/rats
>> 
> 
> _______________________________________________
> RATS mailing list
> RATS@ietf.org
> https://www.ietf.org/mailman/listinfo/rats