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

Guy Fedorkow <gfedorkow@juniper.net> Mon, 18 November 2019 20:00 UTC

Return-Path: <gfedorkow@juniper.net>
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 346ED120B3D for <rats@ietfa.amsl.com>; Mon, 18 Nov 2019 12:00:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 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_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net header.b=QePvy+nS; dkim=pass (1024-bit key) header.d=juniper.net header.b=S+iDuE6q
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 foWyoLs3FqAR for <rats@ietfa.amsl.com>; Mon, 18 Nov 2019 12:00:00 -0800 (PST)
Received: from mx0b-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (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 CACFD120B3B for <rats@ietf.org>; Mon, 18 Nov 2019 12:00:00 -0800 (PST)
Received: from pps.filterd (m0108157.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id xAIJuw5H019072; Mon, 18 Nov 2019 11:59:58 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=PPS1017; bh=UOHIxqut9D6is8gQQCHooji7TfGEsXYE3Ru5pxHI23g=; b=QePvy+nStZLOpfrL+NjLNsSeoY85vLnhgF3Sz80maJGH07/z/DlPyv4804KvIYmDfi8s 3lgLvVFvSnJPWkVcRK+ER/qUPu3QHTV2uXlIqLUiLtxzztnWIs2l3QTzuS7QOWV4kBaM 247gou+3lI9AFju72P43NekjuSlkJvf1lgUY4u9I2iOh75EwkRfK8jZ7nFMwQeYXQAKz pgEh8oCmJ0/mkYg3KdtsN1aIGhMBmXGf1ELPHJLRAjAe4dXBEIGjzLMDux3vKOLg44kZ tmr7Y3B5X5zS/VWRac7VeaW3+Pv8JYqFtrAPQ+q1w/HLN7t4qM3nMaUOdlYFWAwHaDzX 4Q==
Received: from nam04-sn1-obe.outbound.protection.outlook.com (mail-sn1nam04lp2052.outbound.protection.outlook.com [104.47.44.52]) by mx0a-00273201.pphosted.com with ESMTP id 2wah8pk872-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 18 Nov 2019 11:59:57 -0800
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=EVr0bmLkdWQktBoBuHYRL9Jx73FSDq/HhiBFyo7QT9uaFUC/GHiRTL7FSrkky8sR4Av9tKiQNLeM28hoaCjyKPmx33khw3uuzCrEoqX9ObREQAczyH7yKg60i5ug3wjq5y1T8m09edbLRX/r53L3rj4z0tzl3B3v9PiFZsRsNce1ZEfCPL/GR6htmp4zXuQLdsTZg+2IT9aSmdsN6kqC1NJRhprFL5nZhDSqFXuBPmZca6FJZsafwLL35YblPJ6K568JX+GEvB0ah8rhTSYVV5Eui+aljsbqPFzVZ2oLBt/3MJ5nx3HDTpZhp7RYRoaFhekkHYyo9Rr16XRv95A0sw==
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=UOHIxqut9D6is8gQQCHooji7TfGEsXYE3Ru5pxHI23g=; b=EW6Q5VCXuoEkEcvyFF2oNzbB5woed3LvRGs2olAIykK+Z6znClRYp+Ch7xRmG9j7/lsfUtA6ohfNFz0nJl2ym/YaqPAJbWJ+lXn+Psre0PMh/H7PSJC6PUZp22/jJB+x1R/C2uAo3pkaj0jgulHmPP66JJPfVKLKpkdhyNbOXPZmhaVIVfoM1e2SNAeP66pXco0WfpZos4zgkgLl0nn4N2cOYIox7/u9y2OcGjjzLdwnWxtBSP9EW45cRcp2n6gMmqBts8jtNB447qpU7TDa47yxJfrLLmP1UCpV33mClCKUXsAZbYRMfZ2iLCSDV+OAK4uilFpDKksCeKDkam+yFA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=juniper.net; dmarc=pass action=none header.from=juniper.net; dkim=pass header.d=juniper.net; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=UOHIxqut9D6is8gQQCHooji7TfGEsXYE3Ru5pxHI23g=; b=S+iDuE6qA+R2w9B/BvgLVO1/DfvSl0xkIoC3jxAmJzVi2pSzht671ve26KvEGA5KUc0uWP4bDNG4Q8jlBsCtUG65zbyEKSZatA77HFBBtijd8da1+mT1pD4FA/KMnIQOzqkUhzcxtDARX/05dC6YWi49Lf7PLYd19ipDYfu+e44=
Received: from BYAPR05MB4248.namprd05.prod.outlook.com (20.176.251.147) by BYAPR05MB4423.namprd05.prod.outlook.com (52.135.211.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2474.8; Mon, 18 Nov 2019 19:59:55 +0000
Received: from BYAPR05MB4248.namprd05.prod.outlook.com ([fe80::dd02:9d00:19f6:b4e]) by BYAPR05MB4248.namprd05.prod.outlook.com ([fe80::dd02:9d00:19f6:b4e%6]) with mapi id 15.20.2474.012; Mon, 18 Nov 2019 19:59:55 +0000
From: Guy Fedorkow <gfedorkow@juniper.net>
To: Dave Thaler <dthaler=40microsoft.com@dmarc.ietf.org>, "Smith, Ned" <ned.smith@intel.com>, "Oliver, Ian (Nokia - FI/Espoo)" <ian.oliver@nokia-bell-labs.com>, Laurence Lundblade <lgl@island-resort.com>, "Nancy Cam-Winget (ncamwing)" <ncamwing@cisco.com>
CC: "rats@ietf.org" <rats@ietf.org>, Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
Thread-Topic: [Rats] Call for adoption (after draft rename) for Yang module draft
Thread-Index: AQHVlCwI8/lytau3hU+AhCwtIdg/0ad+jL2AgAAHhQCAAAO1AIAF46wAgACM2YCAAJAzgIAAtdsAgAB9XUCACkfwcA==
Content-Class:
Date: Mon, 18 Nov 2019 19:59:55 +0000
Message-ID: <BYAPR05MB42483709CE65A1344DB5C0A6BA4D0@BYAPR05MB4248.namprd05.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>
In-Reply-To: <MWHPR21MB07844F61BEFAE03F9E7DD290A3770@MWHPR21MB0784.namprd21.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Extended_MSFT_Method=Automatic; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=9381b09f-5c8c-495e-9366-6883fd25afee; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Application=Microsoft Azure Information Protection; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=Juniper Business Use Only; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2019-11-18T15:13:16.7265260Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Owner=gfedorkow@juniper.net; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=True; 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-12T01:43:10.0511305Z; 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=a49e9ecc-8e3e-4bf2-b759-08bb20f89aec; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic
dlp-product: dlpe-windows
dlp-version: 11.3.2.8
dlp-reaction: no-action
x-originating-ip: [76.14.1.154]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: d5abcba7-245c-46fe-f68b-08d76c61e227
x-ms-traffictypediagnostic: BYAPR05MB4423:
x-microsoft-antispam-prvs: <BYAPR05MB4423FEAF96BC771730654FB9BA4D0@BYAPR05MB4423.namprd05.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0225B0D5BC
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(396003)(39860400002)(346002)(366004)(136003)(189003)(15404003)(199004)(66574012)(3846002)(99286004)(74316002)(7736002)(76116006)(6116002)(790700001)(71200400001)(316002)(110136005)(54906003)(86362001)(52536014)(66066001)(14454004)(26005)(25786009)(6246003)(478600001)(33656002)(256004)(229853002)(4326008)(14444005)(486006)(8936002)(81166006)(66476007)(55016002)(6306002)(64756008)(66446008)(66556008)(76176011)(71190400001)(81156014)(476003)(7696005)(6436002)(11346002)(5660300002)(8676002)(186003)(446003)(6506007)(53546011)(2906002)(66946007)(102836004)(9686003)(54896002); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR05MB4423; H:BYAPR05MB4248.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: OzIN8tbQ3GD+HJbyi0L0uJUOJWzrXGUbdAV8c0wP90KLeJGTjq6frF8b2AvoVhVNHyqaD68A/bll0Qtk/g87aRhFVnI4dKedlU2rMnv0wcDl003IDj5vsEwlch/L/+bcngPxxceZb5o87gTigwWdMEkq/laqKtFVmt57oJShLI/McLKIc+8rljG3BwROJT88wNzkvt7XhfEcru7/A9uUFD0U8n73gQbWYDZSeu/+Q6v7k5pJ2YP9TXTgBj61EY8KuB3R1poWZRe2ZycR+u+EcDbUtapFyxIdeYRzyu81vXu0j5DF4EKzLx49V/WFQT8Bs7Yo4ZvZF16m8IAvBQLvXvgWunro8xPBYNuv63as9Yr0KcSHmeNiRshU2rUTUU1gl06hR66bwIHPnkaMLn5100Fd9yoeCsAO7QXyLSR1tU/BBxFnW4ZWVym02Iohgfyb
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_BYAPR05MB42483709CE65A1344DB5C0A6BA4D0BYAPR05MB4248namp_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: d5abcba7-245c-46fe-f68b-08d76c61e227
X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Nov 2019 19:59:55.6832 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 6O1Nru3AYVzLN1OdFIy4tOdOuGuwdD9fEbTYo31O5gQIq3kLJSMCIlGKVVuS6+Y6qYfux0ubZN8xqQMGMs43TQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR05MB4423
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,18.0.572 definitions=2019-11-18_06:2019-11-15,2019-11-18 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 mlxscore=0 priorityscore=1501 clxscore=1011 spamscore=0 adultscore=0 phishscore=0 lowpriorityscore=0 bulkscore=0 mlxlogscore=999 malwarescore=0 suspectscore=0 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-1911180171
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/44xsXPpiLILs4gknQtom6wMZGjY>
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 20:00:05 -0000

  I know I’m responding to a message from the ancient past, but I’d like to try to clarify a couple of the characterizations of RIV.
  It’s true that I asked Dave whether the relying party was required to shuttle information between the attester and the verifier, as shown in the Background Check model.  If the two are processes on the same network management machine, such a requirement seems odd.  But if they have different network reachability due to separate machines and firewalls and all, then of course the relying party can proxy information to the Verifier.  We specifically avoided distinguishing the two roles in the RIV draft, but I don’t think that can be taken to mean that the solution cannot work with firewalls.  But let me know if there was some other restriction that motivated the table entry
  The non-privacy clause in the RIV draft is also coincidental.  The TPM has a wide range of mechanisms to deal with degrees of privacy expectations, all of which relate to key provisioning.  For routers, we haven’t seen a need for complex measures to hide identity, and in fact I think most operators would not want routers with a secret identity on their network.  But if someone does want preservation of privacy, they can change to Local DevID keys and coordinate those keys between device and verifier using whatever approach they want.  I don’t think it has any impact on the RIV workflow.
  But I should probably say more explicitly somewhere in the draft that we’d want to the solution to work with zero touch provisioning, such as RFC 8572.  That’s not ‘required’ for RIV, but may help explain two things:

  *   sZTP assumes the device can identify itself.  Hence the non-privacy-preserving statement, and the request that manufacturers pre-provision identity and attestation keys.
  *   sZTP requires that the device announce itself so that it can be configured.  By the time it would be possible to do attestation, the device has already revealed its presence.  And indeed one might link the two – I don’t think it’s part of anyone’s spec, but a ZTP provisioning system might well want to run software integrity attestation once it’s figured out what the device is and whether it has a plausible to reason to want to connect.  But again, that seems out of scope to the draft.
  Finally, I don’t see YANG as the exclusive protocol for TPM-based attestation; it happens to be the one that’s already there for routers, and it’s a lot easier to get someone to add a YANG model to their router for network management, than to convince them to bring in a new protocol suite.
  But for other applications, YANG wouldn’t be the right thing…  Industrial IoT probably would ask for attestation via a protocol I’ve never heard of 😊  And I think there would be different protocols more suitable to end user computing, such as laptops and servers.  Glad to talk it over if someone wants to extend the scope.

  Thanks for reading a long response…  Let me know if this is clarifying or muddying!
/guy




Juniper Business Use Only
From: RATS <rats-bounces@ietf.org>; On Behalf Of Dave Thaler
Sent: Monday, November 11, 2019 8:43 PM
To: Smith, Ned <ned.smith@intel.com>;; Oliver, Ian (Nokia - FI/Espoo) <ian.oliver@nokia-bell-labs.com>;; Laurence Lundblade <lgl@island-resort.com>;; Nancy Cam-Winget (ncamwing) <ncamwing@cisco.com>;
Cc: rats@ietf.org; Henk Birkholz <henk.birkholz@sit.fraunhofer.de>;
Subject: Re: [Rats] Call for adoption (after draft rename) for Yang module draft

As far as I can understand from draft-birkholz-rats-basic-yang-module-01 and
draft-fedorkow-rats-network-device-attestation-01, they break down the use case
space as follows:

                        Requirements?
         +--------------+---------------+---------++---------------
         |  RoT         | Host Firewall | Privacy ||   Solution
         |  Type        |   Enabled     | Needed  ||    Pieces
         +--------------+---------------+---------++---------------
      1  |  SGX         | No            | No      ||
      2  |  SGX         | No            | Yes     ||
      3  |  SGX         | Yes           | No      ||
      4  |  SGX         | Yes           | Yes     ||
      5  |  TrustZone   | No            | No      ||
      6  |  TrustZone   | No            | Yes     ||
      7  |  TrustZone   | Yes           | No      ||
      8  |  TrustZone   | Yes           | Yes     ||
      9  |  TPM         | No            | No      || draft-birkholz-rats-basic-yang-module-01
     10  |  TPM         | No            | Yes     ||
     11  |  TPM         | Yes           | No      ||
     12  |  TPM         | Yes           | Yes     ||
     13  |SecureElement | No            | No      ||
     14  |SecureElement | No            | Yes     ||
     15  |SecureElement | Yes           | No      ||
     16  |SecureElement | Yes           | Yes     ||
     17  | Firmware     | No            | No      ||
     18  | Firmware     | No            | Yes     ||
     19  | Firmware     | Yes           | No      ||
     20  | Firmware     | Yes           | Yes     ||
     ... |   ...        |               |         ||

And draft-fedorkow-rats-network-device-attestation-01 further scopes itself down
by only being applicable to cases with "embedded" apps only = Yes, and where
the security policy is only an Exact match against reference values = Yes.
I believe that the yang draft doesn't have those two restrictions, from my reading.
However, the point is that both drafts are VERY narrow, and in the table shown above,
only address 1 out of 20 possibilies in that space.

In contrast, the TEEP WG decided that it was not interested in narrow scopings
(specifically something Global Platform specific), but instead wanted one general solution.

If the RATS WG spends effort on something that only addresses a single row out of 20+ rows,
then do we expect 19+ other solutions to also be done in the WG?  Or could we work on things
that are broader and happen to also work for row 9?

I've seen others commenting on the fact that the YANG module only supports TPMs and not
other things (EATs etc), which would just add support for a couple more rows, but still not
be general.

Personally, I would much rather see the WG spend effort on things that really are generic,
i.e., work with or without host firewalls, work with multiple RoT/TEE types, etc., rather
than seeing an explosion of point solutions.

Dave