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

Dave Thaler <dthaler@microsoft.com> Wed, 13 November 2019 00:20 UTC

Return-Path: <dthaler@microsoft.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 652C1120803 for <rats@ietfa.amsl.com>; Tue, 12 Nov 2019 16:20:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.99
X-Spam-Level:
X-Spam-Status: No, score=-1.99 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com
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 zNfKsBIrTbR4 for <rats@ietfa.amsl.com>; Tue, 12 Nov 2019 16:20:23 -0800 (PST)
Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-eopbgr750108.outbound.protection.outlook.com [40.107.75.108]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0531D12089E for <rats@ietf.org>; Tue, 12 Nov 2019 16:20:22 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=DrvJ7QQFEwAtuI9fVRoXgwCC8K2K+2vs6t1PpmtItOJ+LEeQStiVvpo6U0Tu14IQFZ2zoYf24ozwN6t6ycl/iTmdNMqGX7zmj72AP1HJTv+XciODSnw2B3vib0wYG3YaEs+4WEe6cVAuyYjjsvD1gDmT3JldsBxqd4J5ulxplXlPwX1BC0TyOJzPdXKBsj1enjbwmcmbeTOH4cZJ0zwCgUMI/7FJLhO0Dkb4afVr2kZvauD76wHO6QG0bMS6j7W3PRJFpI0P96RABTVk1+alRH7dgK7gxIhKmcD9MAVC13K3abFL4My/AxP5nL/m8aCReFjq53MNuU7iRt235jnKsA==
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=YH5Aal6q1daq08uGW/fw1mmTom2coUerZvx89zukTso=; b=m3Y1/35hvPxZVayqUUSZpgE10+TEb7odWRtoWRi7p4REMcfRZzgRe/vkVil1bZYKH6yFko4tsiH2UOzChoUJho/Y8y71Bj6IUbTUfbY80ZPZY/9/OtdP9VZPHb5J+uaeMb7Ul6hcmKCiF91nPCuXxJjjqW4uRa/XUhDUFWbAKFV8dcvsHN/BrYd2r6oM9Lo2yAjfs2BuqiuMVpQhLjIvsP2zstJBxmps/uKICDQrXx9rP4T6wMZUCDrARnziJqdOf5hPZB/DQVn+Bt7ud+uhSikODCtC1KGGb/ajLMROZr/DRpIwR8EkdN03Ai4vuEgdjRMK7DPgGyUpYzmaXCVtyA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=YH5Aal6q1daq08uGW/fw1mmTom2coUerZvx89zukTso=; b=LvYtJYaZFx4O6WPVQeLGaZQgI3lpDHBpq7yu7OlhC7doQgITvrJSumoDQMJF0BRpmnM4Q2i/F8imav0ryGwlssQf6A4qZe5W16OTkWZF82+eGToeDwWR+K85bjuxsmPXaw7qeUzxD0cXtzUsdoOphCPHjqvT59d7cS7AsrnHTH4=
Received: from MWHPR21MB0784.namprd21.prod.outlook.com (10.173.51.150) by MWHPR21MB0479.namprd21.prod.outlook.com (10.172.102.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2474.6; Wed, 13 Nov 2019 00:20:18 +0000
Received: from MWHPR21MB0784.namprd21.prod.outlook.com ([fe80::8d41:8f86:8654:8439]) by MWHPR21MB0784.namprd21.prod.outlook.com ([fe80::8d41:8f86:8654:8439%12]) with mapi id 15.20.2474.001; Wed, 13 Nov 2019 00:20:18 +0000
From: Dave Thaler <dthaler@microsoft.com>
To: Henk Birkholz <henk.birkholz@sit.fraunhofer.de>, "Smith, Ned" <ned.smith@intel.com>, Michael Richardson <mcr+ietf@sandelman.ca>, "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+jL2AgAAHhQCAAAO1AIAF46wAgACM2YCAAG6hAP//f1YAgADOEwCAABvMgIAACkiAgABGoACAAMXLwIAAROUAgAEJ/GA=
Date: Wed, 13 Nov 2019 00:20:18 +0000
Message-ID: <MWHPR21MB0784D315CBA68C8CA0B723E7A3760@MWHPR21MB0784.namprd21.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> <ba12a686-1b34-21a3-388c-bbe01c01a408@sandelman.ca> <1DFA7D52-7294-4705-9407-C34F5BC82EA6@cisco.com> <5f57dd25-f561-e07d-4b24-fef05627bac9@sit.fraunhofer.de> <c61b3ccd-6427-5801-c149-4e93af5c9fb1@sandelman.ca> <0eb003f7-34c3-af36-74ac-097841d2ac6c@sit.fraunhofer.de> <D6CA54EA-67F1-4BE6-8D11-32C6597D58E0@intel.com> <MWHPR21MB078487DA04C7C17F2019E7E6A3770@MWHPR21MB0784.namprd21.prod.outlook.com> <29e641b7-3077-2b7d-8029-631698012c74@sit.fraunhofer.de>
In-Reply-To: <29e641b7-3077-2b7d-8029-631698012c74@sit.fraunhofer.de>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=dthaler@ntdev.microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2019-11-13T00:20:17.9977098Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=a718117a-0d30-484d-b198-5f2051e5c452; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic
authentication-results: spf=none (sender IP is ) smtp.mailfrom=dthaler@microsoft.com;
x-originating-ip: [2001:4898:80e8:0:f8a5:16bc:386f:88f5]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: f04ae6e5-3795-4da9-895e-08d767cf43b5
x-ms-traffictypediagnostic: MWHPR21MB0479:
x-microsoft-antispam-prvs: <MWHPR21MB04797A5DBCA2E352A25DFE9BA3760@MWHPR21MB0479.namprd21.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:4502;
x-forefront-prvs: 0220D4B98D
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(346002)(376002)(366004)(39860400002)(396003)(189003)(199004)(53754006)(13464003)(2501003)(25786009)(486006)(236005)(476003)(33656002)(6506007)(966005)(6306002)(54896002)(102836004)(53546011)(55016002)(14454004)(7736002)(186003)(478600001)(606006)(9686003)(256004)(10290500003)(6246003)(14444005)(52536014)(10090500001)(6436002)(46003)(99286004)(86362001)(71190400001)(81166006)(11346002)(446003)(8990500004)(74316002)(71200400001)(76116006)(66946007)(22452003)(316002)(8936002)(2906002)(66476007)(66446008)(64756008)(6116002)(66556008)(790700001)(76176011)(81156014)(110136005)(5660300002)(8676002)(7696005)(229853002); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR21MB0479; H:MWHPR21MB0784.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: Yx4F12U17XvWRPdprrm5HuKkD5FVAU/H4SSns5bEEhzh614LoXH7miaKevCJGPwMvLpUrOgvJYD3pUgiTGaEAFdBPHxJan2Msws+GO5QfpEcUUEWMfwivsbFl/un5i9F2JBjMI2sbzjdZ/RUn4j1r9I88bX7zkHmJdcdOVGxElZLRD+YRzBsYKdHie+sBEdTLZ+c7Olj7Tit41Ev1+f1ywi3NHn1I8CJAFrvb5frzqmV/wtDnyuUdQRSPq8dvqdSInLyT2AYxtuZqzj6jEbTubL+EV57uOErE5yS5BIdIppXZ8JDZ1Yv8THMuHDuFS30Vfhq8B2J6FpNnNIl08cBt42HtpIU01RU24jRj93ezIIfEBcsDvZzpSF6ILee81bh+djRCSjLpJ491ZokJlC7gIu6NCCJyNpVJJlxim9owfulO5+vOHdvrK04bQLcxT8k
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_MWHPR21MB0784D315CBA68C8CA0B723E7A3760MWHPR21MB0784namp_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-Network-Message-Id: f04ae6e5-3795-4da9-895e-08d767cf43b5
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Nov 2019 00:20:18.6197 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: EA80x3YlMhZt1lUtF7e1NYwRrsDX3IGdsgGlvjbPXjSiCK09rg5KyV9t1TQ+GjqHwycDP2dAwMWGFS79wx77YydRb2PjXUZR21Wnt31lX1E=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR21MB0479
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/xuXkDga2izmEgiDzbguQZmPwhYk>
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: Wed, 13 Nov 2019 00:20:35 -0000

Response below…



-----Original Message-----
From: RATS <rats-bounces@ietf.org>; On Behalf Of Henk Birkholz
Sent: Tuesday, November 12, 2019 12:21 AM
To: Dave Thaler <dthaler@microsoft.com>;; Smith, Ned <ned.smith@intel.com>;; Michael Richardson <mcr+ietf@sandelman.ca>;; rats@ietf.org
Subject: Re: [Rats] Call for adoption (after draft rename) for Yang module draft



Hi Dave,

hi all,



is it correct that the intent of tokens - in general - is that they have a life-span and are somehow like... certificates, but with a smaller life-cycle? The claims defined by the Web Token RFCs are indicating as such, I'd assume.



I think so too, yes.



Having said that, the features we use are the object / tagged map structure, the continuous list of defined Claims & corresponding registry, and the imperative guidance how to use {C|J}OSE. In combination with the fact that all Web Token Claims are optional, we can use these features for purposes other than the original intent of tokens and that is okay. Simply calling them tokens, though, might be confusing to readers that already use tokens?



Not sure I understand your point (e.g., who’s “we”?).  Can you rephrase?



In conveyance protocols for RATS I would like to see at least three things defined and differentiated:



* the Interaction Models the protocols use, most prominent, challenge/response, time-based, and subscription,

* the Message (Content) that is conveyed, most prominent Evidence, Endorsements, Reference Values (aka Known Good Values), and Attestation Results, and

* the Roles between which Messages are conveyed via protocols, most prominent .



This is applicable to EAT (specific claim set serializations) and YANG (specific statements serializations, APIs, and conveyance protocols) or others - and unless there are really good reasons against this, I'd consider these definitions/categorizations a MUST.



Personally, I don’t see a strong requirement to differentiate an interaction model from a message descriptions, in any concrete solution/protocol document.

(Some people are just confused by extra complexity in documents that isn’t necessary to understand and implement the protocol, and I’m all for avoiding gratuitous complexity.)



I’m fine with docs that do so, and I’m fine with docs that don’t.

I agree it is important to define which Roles (Attester, Verifier, Relying Party…) a message is intended to go between.

As elaborated on in my doc, I disagree however that “Reference Values (aka Known Good Values)” should be a top-level concept, but is fine as a common example.

In general, exact match is too narrow a concept for the types of security policies I see people wanting to do, which may be exact match, may be a test that a claimed value is a member of a specified set of values,

may be range checks, may be even more complex logic.



After the discussions we had, I am a bit at a loss how to deal with "the same information elements used in different message types and content"

or "how to not use the same term as something else" (aka the Information Model), I have to admit. I do not see a viable solution at the moment.



Sounds like more work is needed on solutions.



Dave



Viele Grüße,



Henk





On 12.11.19 05:19, Dave Thaler wrote:

> Ned Smith wrote:

>

>  > So far the group has used the term "EAT" to refer to both the

> information model and data serialization expressions.

>

> I would rather see the term EAT (and any other terms ending in Token,

> like JWT and CWT) only be used to refer to

>

> data serialization expressions, not the information model.

>

>  > When extending information model to YANG or some other

> serialization (e.g. ASN.1). Given the possibility for an IM

>

>  > expression to be realized by different serializations, what term

> should we give to the IM description?

>

> That’s a fine question, and I don’t have any strong preference right

> now, other than to not use the same term as something else.

>

> Offhand, my preference would be to not define a term, and just use

> Evidence and Attestation Result as the terms for

>

> format-independent discussion.  I think it is useful to distinguish

> between Evidence vs Attestation Results in many cases.

>

> And if you need to refer to both, then we can always use both

> together, such as “Evidence and Attestation Results”.

>

>  > The term "Claim" has been used extensively. Do we want to agree to

> use "claim" to refer to anything that is an IM  > expression in RATS

> and "Token" for any serialization (realization) even if it isn't a JWT

> or CWT?

>

> I would say no. To me, a claim is one particular piece of information,

> where a “Token” or whatever else has a set of claims.

>

> Dave

>



_______________________________________________

RATS mailing list

RATS@ietf.org<mailto:RATS@ietf.org>

https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Frats&amp;data=02%7C01%7Cdthaler%40microsoft.com%7C3fc94f07304b4be4ef2f08d767494ed4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637091436880001200&amp;sdata=xcH8jcr%2FEqf7etD%2BC3%2Brmeu3tB1%2FR3XOkXEwQhENk7Y%3D&amp;reserved=0