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

"Smith, Ned" <ned.smith@intel.com> Mon, 18 November 2019 21:33 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 7BB61120B5C for <rats@ietfa.amsl.com>; Mon, 18 Nov 2019 13:33:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Level:
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 tcI2mfpo24mZ for <rats@ietfa.amsl.com>; Mon, 18 Nov 2019 13:33:21 -0800 (PST)
Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) (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 2DF05120B56 for <rats@ietf.org>; Mon, 18 Nov 2019 13:33:21 -0800 (PST)
X-Amp-Result: SKIPPED(no attachment in message)
X-Amp-File-Uploaded: False
Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga101.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Nov 2019 13:33:20 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.68,321,1569308400"; d="scan'208,217";a="380792868"
Received: from orsmsx106.amr.corp.intel.com ([10.22.225.133]) by orsmga005.jf.intel.com with ESMTP; 18 Nov 2019 13:33:20 -0800
Received: from orsmsx109.amr.corp.intel.com ([169.254.11.161]) by ORSMSX106.amr.corp.intel.com ([169.254.1.150]) with mapi id 14.03.0439.000; Mon, 18 Nov 2019 13:33:20 -0800
From: "Smith, Ned" <ned.smith@intel.com>
To: Laurence Lundblade <lgl@island-resort.com>, Dave Thaler <dthaler=40microsoft.com@dmarc.ietf.org>
CC: Henk Birkholz <henk.birkholz@sit.fraunhofer.de>, "Nancy Cam-Winget (ncamwing)" <ncamwing@cisco.com>, "rats@ietf.org" <rats@ietf.org>, =?utf-8?B?IlNjaMO2bnfDpGxkZXIsIErDvHJnZW4i?= <J.Schoenwaelder@jacobs-university.de>, "Oliver, Ian (Nokia - FI/Espoo)" <ian.oliver@nokia-bell-labs.com>
Thread-Topic: [Rats] Call for adoption (after draft rename) for Yang module draft
Thread-Index: AQHVlCwI8/lytau3hU+AhCwtIdg/0ad/EtmAgAAHhgCAAAO0AIAGacyAgAAGuoCAAJAygIAAL78AgAEETQCAAqU5AIACdRAAgAOa1YCAATDPAIAAAeiAgAABVYCAAAF4gIAAAjIAgABHkgA=
Date: Mon, 18 Nov 2019 21:33:19 +0000
Message-ID: <1C54B922-276A-46A8-AFF9-04A2E6829EF5@intel.com>
References: <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> <MWHPR21MB07840B6CF7BEE0A11ABE54BFA3700@MWHPR21MB0784.namprd21.prod.outlook.com> <20191117144129.llvg7fsrqgaqtgkn@anna.jacobs.jacobs-university.de> <MWHPR21MB0784B0111EADA4A9A6C766D0A34D0@MWHPR21MB0784.namprd21.prod.outlook.com> <FADBA46B-5B70-4B21-A159-B22593310B53@island-resort.com> <MWHPR21MB078427872BAEEBA45B34E589A34D0@MWHPR21MB0784.namprd21.prod.outlook.com> <MWHPR21MB07848E815323D3414344263FA34D0@MWHPR21MB0784.namprd21.prod.outlook.com> <F9B5FCC9-4385-4C9B-A0FD-58B51AC38B97@island-resort.com>
In-Reply-To: <F9B5FCC9-4385-4C9B-A0FD-58B51AC38B97@island-resort.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.254.0.106]
Content-Type: multipart/alternative; boundary="_000_1C54B922276A46A8AFF904A2E6829EF5intelcom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/0L4oQv0d7dcrQJZbdwmneiXTcMw>
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, 18 Nov 2019 21:33:26 -0000

The log is merely a way to defer actions taken by a Relying Party. Presumably, there is not reason to log something if the log is never processed.

The Roles workflow isn’t necessarily time dependent while possibly the arch models (passport, BGC) are?

From: Laurence Lundblade <lgl@island-resort.com>;
Date: Monday, November 18, 2019 at 1:17 AM
To: Dave Thaler <dthaler=40microsoft.com@dmarc.ietf.org>;
Cc: "Smith, Ned" <ned.smith@intel.com>;, Henk Berkholz <henk.birkholz@sit.fraunhofer.de>;, Nancy Cam-Winget <ncamwing@cisco.com>;, "rats@ietf.org"; <rats@ietf.org>;, ""Schönwälder, Jürgen"" <J.Schoenwaelder@jacobs-university.de>;, "Oliver, Ian (Nokia - FI/Espoo)" <ian.oliver@nokia-bell-labs.com>;
Subject: Re: [Rats] Call for adoption (after draft rename) for Yang module draft

If a tree falls in a forest, even if no one hears it, there is a log.

LL





On Nov 18, 2019, at 5:09 PM, Dave Thaler <dthaler=40microsoft.com@dmarc.ietf.org<mailto:dthaler=40microsoft.com@dmarc.ietf.org>> wrote:

I do think it would be useful to keep your statement true, so I will think about how to define Relying Party since I suspect there’s a way around it that we would both like.

From: RATS <rats-bounces@ietf.org<mailto:rats-bounces@ietf.org>> On Behalf Of Dave Thaler
Sent: Monday, November 18, 2019 5:04 PM
To: Laurence Lundblade <lgl@island-resort.com<mailto:lgl@island-resort.com>>
Cc: Smith, Ned <ned.smith@intel.com<mailto:ned.smith@intel.com>>; Henk Birkholz <henk.birkholz@sit.fraunhofer.de<mailto:henk.birkholz@sit.fraunhofer.de>>; Nancy Cam-Winget (ncamwing) <ncamwing@cisco.com<mailto:ncamwing@cisco.com>>; rats@ietf.org<mailto:rats@ietf.org>; "Schönwälder, Jürgen" <J.Schoenwaelder@jacobs-university.de<mailto:J.Schoenwaelder@jacobs-university.de>>; Oliver, Ian (Nokia - FI/Espoo) <ian.oliver@nokia-bell-labs.com<mailto:ian.oliver@nokia-bell-labs.com>>
Subject: Re: [Rats] Call for adoption (after draft rename) for Yang module draft

If all you do is log, then there is no enforcement, and since the device doesn’t talk to the log, you can’t call the log a “Relying Party”.
I didn’t say there was never a Relying Party (if you do enforcement and kick the device off the network or something then yes there’s a Relying Party), I said “might be no”.
So I disagree with “Attestation always has a relying party” based on my discussion with Nancy.
Before the hackathon I would have agreed with that statement ☺

From: Laurence Lundblade <lgl@island-resort.com<mailto:lgl@island-resort.com>>
Sent: Monday, November 18, 2019 4:59 PM
To: Dave Thaler <dthaler@microsoft.com<mailto:dthaler@microsoft.com>>
Cc: "Schönwälder, Jürgen" <J.Schoenwaelder@jacobs-university.de<mailto:J.Schoenwaelder@jacobs-university.de>>; Smith, Ned <ned.smith@intel.com<mailto:ned.smith@intel.com>>; Henk Birkholz <henk.birkholz@sit.fraunhofer.de<mailto:henk.birkholz@sit.fraunhofer.de>>; Nancy Cam-Winget (ncamwing) <ncamwing@cisco.com<mailto:ncamwing@cisco.com>>; Oliver, Ian (Nokia - FI/Espoo) <ian.oliver@nokia-bell-labs.com<mailto:ian.oliver@nokia-bell-labs.com>>; rats@ietf.org<mailto:rats@ietf.org>
Subject: Re: [Rats] Call for adoption (after draft rename) for Yang module draft


On Nov 18, 2019, at 4:52 PM, Dave Thaler <dthaler=40microsoft.com@dmarc.ietf.org<mailto:dthaler=40microsoft.com@dmarc.ietf.org>> wrote:

Case 1) The network notices anomalous traffic coming from a device already on the network, which triggers a verifier to ask the device to attest to its health (which may have changed since it was last attested).  Here there might even be no Relying Party involved per se.
Case 2) The network has not noticed anything odd, but wants to proactively query a device anyway, e.g., because the network's appraisal policy of what is considered trustworthy has just changed.  Again there might even be no Relying Party involved.

I would call the network the relying party. Attestation always has a relying party because there would be no point if no one cared (if a tree falls in a forest…)

LL


_______________________________________________
RATS mailing list
RATS@ietf.org<mailto:RATS@ietf.org>
https://www.ietf.org/mailman/listinfo/rats