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

"Eric Voit (evoit)" <evoit@cisco.com> Thu, 14 November 2019 20:42 UTC

Return-Path: <evoit@cisco.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 56D29120072 for <rats@ietfa.amsl.com>; Thu, 14 Nov 2019 12:42:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.502
X-Spam-Level:
X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=X7Q3QnhS; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=cisco.onmicrosoft.com header.b=fyLIz1g2
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 e9q40GJADAKg for <rats@ietfa.amsl.com>; Thu, 14 Nov 2019 12:42:48 -0800 (PST)
Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4645E1200A1 for <rats@ietf.org>; Thu, 14 Nov 2019 12:42:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10195; q=dns/txt; s=iport; t=1573764166; x=1574973766; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=05kIcu2DKqkkReYhEqoAop1Tw3Soqip+6oz+CMpd4bc=; b=X7Q3QnhSHKDyvfKPbf/s+OfJsGuCFqHUYfxbYFdjkbHqJIXqjXowJcyV ZAzOGb4ZYUpqj9hnsvGyusO+1yil+Hw/ZaNb9I/cjUzytCTjhHPOc4gUG 0aN09U3/oUo2A2CY9OYR3Ckp02PL+9qCgcRCt/am6ZMQk3qXQG4lO+R96 I=;
X-Files: smime.p7s : 3975
IronPort-PHdr: =?us-ascii?q?9a23=3AuF5Ybxaw+X5LA9GelhAVH0P/LSx94ef9IxIV55?= =?us-ascii?q?w7irlHbqWk+dH4MVfC4el20Q+bRp3VvvRDjeee87vtX2AN+96giDgDa9QNMn?= =?us-ascii?q?1NksAKh0olCc+BB1f8KavncSs7AOxJVURu+DewNk0GUMs=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AOAABsu81d/5tdJa1mGgEBAQEBAQE?= =?us-ascii?q?BAQMBAQEBEQEBAQICAQEBAYFrBAEBAQELAYFKUAVsKy0gBAsqCoQfg0YDinK?= =?us-ascii?q?CXpgAgS6BJANUAgcBAQEJAwEBGAsKAgEBhEACgiAkNQgOAgMLAQEEAQEBAgE?= =?us-ascii?q?FBG2FNwyFUQEBAQEDAQEQCwYdAQEsCwEPAgEGAhIGDAEdAgICJQsXDgIEAQ0?= =?us-ascii?q?FCAYUgwGBeU0DHw8BAgyWPJBjAoE4iGB1gTKCfgEBBYUaGIIQBwMGgTYBgVK?= =?us-ascii?q?KQhiBQD+BEUaCTD6CYgEBgWMVgnkygiyQEp0ibgqCKoNMgjSPZ5oEjkeaBAI?= =?us-ascii?q?EAgQFAg4BAQWBUwE3gVhwFTuCbFARFII3jmMMF4NQhRSFP3SBKI9JAYEOAQE?=
X-IronPort-AV: E=Sophos;i="5.68,305,1569283200"; d="p7s'?scan'208";a="372916991"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 14 Nov 2019 20:42:44 +0000
Received: from XCH-RCD-010.cisco.com (xch-rcd-010.cisco.com [173.37.102.20]) by rcdn-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id xAEKgi8r003870 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 14 Nov 2019 20:42:44 GMT
Received: from xhs-aln-003.cisco.com (173.37.135.120) by XCH-RCD-010.cisco.com (173.37.102.20) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 14 Nov 2019 14:42:44 -0600
Received: from xhs-aln-002.cisco.com (173.37.135.119) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 14 Nov 2019 14:42:43 -0600
Received: from NAM05-CO1-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Thu, 14 Nov 2019 14:42:43 -0600
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=VsUpWk3ilzyjKDhMYnEITezQeaf8sVLVpSDfTZ0PaMUbeDmz/uuHc+f6yaslSCdp2cBWf5Lc19FryxCvWq1i47Rx1MEPNsS544RJ1lCLoqVda/QPI6S5APszG5RNd/wDTLdsL73JeixYyOBFpheLmmSix3FjOLRtRjSZ7+JMZrxGn2s337sUbKE3zQkGyPSfbB/YlRrahsHovlgA3RfGZMtVklcYbPFbjb0808qC+zgXMpE8Cozwo8k09bsDQ4pnqkqNFgdq7m2P5TQDYGv4EQCNtKhYufWHMzuQVxU0pXbwiIwoSmv/ZCvAYUL9Se8Je/3aFBmI+EhxZcnmqbfvzA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=sy5ynjqf1JtoZ9mPQlnNPp7AL1P0lYCusEnMzROnu9k=; b=aTCNpL5TbSWKN2U28BcV0tTOp7fKNFcTg2p/mkXXvWuYoOCpBsFlJ5pV8zAnFtHs6KKEcg8guofJf43YBq3l2qYxXg77xdDFZ+fm3hpIsmyQT8L6vSmoc7FCrcLvIo2sBHJACZzJo0bdN3u6ux8JIPesepOhAlAAq+VlOAgKgnGUtpv4foJa6vCnSJKUNriZQWBKO7OGPOdwMOd7l5P/z6/IaCWurjI8Ni32g0oS+ML8f0JeLM9KrDHsFRmTV2GZExNEVfiHq6M5zexG+tpLtqBxvJtsbTgK7dheHkVGEvRp698TNomw8xO1lq/yeMsl5CNhiN3Pl4s+FnzLhBJQLA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=sy5ynjqf1JtoZ9mPQlnNPp7AL1P0lYCusEnMzROnu9k=; b=fyLIz1g2J64QAQeBvqCwwqIF/sm44XCZf6sMpYxhuI+yOeier50Dmi4XEoAfb9HGl1gvkfvinh72tcaJhjTT8mw8cQgq31FiwZfSbDSZ6LjADOScU1AJAtqVwF9OBWxUdz9qJGU7C6IyFt4T687RhbM6Zj+LhPEPz4XfDHuu26E=
Received: from DM6PR11MB4154.namprd11.prod.outlook.com (20.176.126.215) by DM6PR11MB4297.namprd11.prod.outlook.com (52.132.248.93) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2451.23; Thu, 14 Nov 2019 20:42:42 +0000
Received: from DM6PR11MB4154.namprd11.prod.outlook.com ([fe80::64fd:c810:5c47:243f]) by DM6PR11MB4154.namprd11.prod.outlook.com ([fe80::64fd:c810:5c47:243f%3]) with mapi id 15.20.2430.028; Thu, 14 Nov 2019 20:42:42 +0000
From: "Eric Voit (evoit)" <evoit@cisco.com>
To: "Smith, Ned" <ned.smith@intel.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: AQHVmvyW8/lytau3hU+AhCwtIdg/0aeKzjHAgABIPICAAABN4A==
Date: Thu, 14 Nov 2019 20:42:42 +0000
Message-ID: <DM6PR11MB41548D92CF35A134264E56E1A1710@DM6PR11MB4154.namprd11.prod.outlook.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>
In-Reply-To: <5C6D6C7C-05DC-4103-9A80-A029F0151996@intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=evoit@cisco.com;
x-originating-ip: [173.38.117.91]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 8de0fc2d-ae6d-4734-5e8d-08d769433252
x-ms-traffictypediagnostic: DM6PR11MB4297:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <DM6PR11MB42977424EDCA41FB8239C514A1710@DM6PR11MB4297.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:2887;
x-forefront-prvs: 02213C82F8
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(39860400002)(396003)(136003)(376002)(346002)(199004)(189003)(6436002)(74316002)(4326008)(2906002)(478600001)(9686003)(3846002)(6116002)(6306002)(14454004)(966005)(6246003)(66574012)(86362001)(55016002)(66616009)(66946007)(316002)(229853002)(25786009)(66476007)(52536014)(110136005)(71200400001)(71190400001)(5660300002)(66446008)(64756008)(54906003)(11346002)(446003)(486006)(476003)(186003)(33656002)(99286004)(66556008)(7696005)(53546011)(6506007)(76176011)(102836004)(8936002)(8676002)(256004)(66066001)(14444005)(81156014)(81166006)(7736002)(305945005)(26005)(76116006); DIR:OUT; SFP:1101; SCL:1; SRVR:DM6PR11MB4297; H:DM6PR11MB4154.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: /BjPLSQOU5DFHH/xSYiHDBUHaq0csvMyhBaEPUVeUMy1Su5wEw0F4OwSc78QKsFRshCWYd0tD8m4j/1r1e95lpxus3rDUh+x/SrgJq/CPEJsB9REwgyGIXsUN0nO5owrqD/HaxisfH+l8s3ZMPZibxuuDdkYDDRr2Q2Z3E36zTN02fkyxr4sfRxWeiQQXLfRudh3m6pLVk7iXUyGhrOFFSznUuD+fhgyKsLlFFgq/yfx9ckQT8ah58SX2ECNQs4u5BX01IEctFi8U0NVMlXg6298skauNBVpOWYwc1Dvavxx2RRkeIEzvWv6D6bYHgXSF8vregRRk4DQB9vN1ywDfx1jq7nYOd9o0Orwu10jN3DJfWbjZL1a2KXsHwXicyCus3RPhhp5e4zSN9ZfH3wiZv2tuppAwQIWt9aIeKR1ZDlcpMArctZqWH5hzTsqQqdl
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_00AE_01D59B01.FC692740"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 8de0fc2d-ae6d-4734-5e8d-08d769433252
X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Nov 2019 20:42:42.3199 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: D/p0zjhqlWNAmSYtt6lNt3f8V/7++LpMHVKxoaTENeMkjSVc3u9UK0Ivy6V7qfVI
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB4297
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.20, xch-rcd-010.cisco.com
X-Outbound-Node: rcdn-core-4.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/mxOmwru9fLEZIFIfehlTBqbIoRY>
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:42:50 -0000

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
>