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

"Smith, Ned" <ned.smith@intel.com> Thu, 14 November 2019 20:00 UTC

Return-Path: <ned.smith@intel.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 19DC9120932 for <rats@ietfa.amsl.com>; Thu, 14 Nov 2019 12:00:49 -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 I3Gvk7ti7kog for <rats@ietfa.amsl.com>; Thu, 14 Nov 2019 12:00:47 -0800 (PST)
Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) (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 0013C12096F for <rats@ietf.org>; Thu, 14 Nov 2019 12:00:46 -0800 (PST)
X-Amp-Result: SKIPPED(no attachment in message)
X-Amp-File-Uploaded: False
Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga103.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Nov 2019 12:00:46 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.68,305,1569308400"; d="scan'208";a="235806339"
Received: from orsmsx110.amr.corp.intel.com ([10.22.240.8]) by fmsmga002.fm.intel.com with ESMTP; 14 Nov 2019 12:00:45 -0800
Received: from orsmsx109.amr.corp.intel.com ([169.254.11.161]) by ORSMSX110.amr.corp.intel.com ([169.254.10.52]) with mapi id 14.03.0439.000; Thu, 14 Nov 2019 12:00:45 -0800
From: "Smith, Ned" <ned.smith@intel.com>
To: "Eric Voit (evoit)" <evoit@cisco.com>, Henk Birkholz <henk.birkholz@sit.fraunhofer.de>, =?utf-8?B?U2Now7Zud8OkbGRlciwgSsO8cmdlbg==?= <J.Schoenwaelder@jacobs-university.de>, Laurence Lundblade <lgl@island-resort.com>
CC: "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>
Thread-Topic: [Rats] Call for adoption (after draft rename) for Yang module draft
Thread-Index: AQHVlCwI8/lytau3hU+AhCwtIdg/0ad/EtmAgAAHhgCAAAO0AIAGacyAgAAGuoCAAJAygIAAL78AgAEETQCAAqU5AIABTv6AgAAP44CAABCHAP//vJUA
Date: Thu, 14 Nov 2019 20:00:45 +0000
Message-ID: <5C6D6C7C-05DC-4103-9A80-A029F0151996@intel.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>
In-Reply-To: <DM6PR11MB4154A67956517DF2D9D305ADA1710@DM6PR11MB4154.namprd11.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.1f.0.191110
x-originating-ip: [10.24.10.107]
Content-Type: text/plain; charset="utf-8"
Content-ID: <0B545A5939EF9448942718258FD652B2@intel.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/hgaQP8JiKakmjGZfXvA5gRp1-g8>
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: Thu, 14 Nov 2019 20:00:56 -0000

@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