Re: [Rats] RIV and the RATS architecture

Guy Fedorkow <gfedorkow@juniper.net> Wed, 06 November 2019 20:57 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 5375F1201A3 for <rats@ietfa.amsl.com>; Wed, 6 Nov 2019 12:57:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 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, HTTPS_HTTP_MISMATCH=0.1, 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=NYkodn4J; dkim=pass (1024-bit key) header.d=juniper.net header.b=O+rWBlVp
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 LPgCu69v5Her for <rats@ietfa.amsl.com>; Wed, 6 Nov 2019 12:57:13 -0800 (PST)
Received: from mx0a-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 2354E1200A4 for <rats@ietf.org>; Wed, 6 Nov 2019 12:57:13 -0800 (PST)
Received: from pps.filterd (m0108158.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id xA6KvBLF018300; Wed, 6 Nov 2019 12:57:11 -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=nJRKqmbZZA+hmvzUBaQHwu7/XoTHSTShYUEQlCDwlto=; b=NYkodn4JcKcCm2moRcjHvJS0jkhjGOuZhpX15dLSrCbNB338cUwE7HVrQD+oQCNGLTcc 6gjAo8FUwCDm3yKBpWxLZZZ3jSDICP+h53e8KRcIt/j7jtL7trOG+udzzqOWJi9GHSNP oxSd1xIu8hmGSGoMxQWxKwaKsUMq8uO9RVGv6lYybGX9coOWOcbkvSJCcj0yz6OfvOjz 3TrpRNAFD6zhIm849Jq8Ngs/nPKedf6gCxHLZxyihrcqMGtCG3w5m29p7HQpEMEWRW9H 8SCDqmH/rDB4kTXMvG5KhLdTO9tdmjwabWW8f3xBYVnAXA1FXHeD/DK8um2eCJCBfxjN +g==
Received: from nam05-co1-obe.outbound.protection.outlook.com (mail-co1nam05lp2056.outbound.protection.outlook.com [104.47.48.56]) by mx0a-00273201.pphosted.com with ESMTP id 2w41vb0efe-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 06 Nov 2019 12:57:11 -0800
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=bV3gRVJXxYKskPVRnLFNwOnrXFnvlY0QMgYuCDRuSbOpKUW0KPo1+4apbrw8ciUJTGAADMo6Nbo/atclbrTWX2pX3FA608Q5UT2pi7qRYSauUtc5AhCL0lXavAF5cpfDVLnwAvcMIPw9kJQ62YZfAIk3fyAzHSQLcz5U3YZTAPiSMWNyD9KSM/VVlLNY7gvWDkbjG59YzXA3c/mrplwNArUJ6stIRWrvktQCanjvaGMYSPBA5w+oOK0/4SMNyVomDqTSPpLyB33U8cCCirkWcjN9DIoYFuRdEjHFvWvePfnwQmuvL3v8qdk8/VZbHKcMa1kVAhqL40ewQpvlvgj0EA==
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=nJRKqmbZZA+hmvzUBaQHwu7/XoTHSTShYUEQlCDwlto=; b=Gw6F7MjvHwbsqd6FIM8cNKy6GmD0BhI1qdN7NiUL5SQUcxLOMrMKo2L9wRMMfTjdWw+5S+sJv+XP2OLa1zEui7fPTfi+Ab2ETrlmRNr8cn6BI6MyzlgUmGgVLtFB62ScAnsH1id4nJzbF8RDp5NZczFLtQoG+Ck+pv7Qp0mMjYbPj9a5gFtZYDfwb7QU758NHJ8aahXQkxo+ITSNiq8KKO3wxX3taNGJco/unpikS7DZs6sqr/q1LRIXsUsGH33MgdD2W8K6H3+YkdZL5ZvZuShns4mFHyZfrozMNNUcb0cX2l0Q/9ys9o+aecheeWZJyuU1h6x5PV79Wwjb3uwDGw==
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=nJRKqmbZZA+hmvzUBaQHwu7/XoTHSTShYUEQlCDwlto=; b=O+rWBlVpAvLkBolGoqRyxHBEXTgCpEm/bMElOtGaUuTqNiPZsr3paNywUEOMcYgCgBUYTDHQFT7Sxdm67VABSIr7P6SZUwEYWlr+Dq/PIOU3xxA5z7MF5AZIsx6ceGTSQjvjL4FD5ZERa2HxLZMUePl8ee6YTVcuZkIFC5ZM0kY=
Received: from BYAPR05MB4248.namprd05.prod.outlook.com (20.176.251.147) by BYAPR05MB4646.namprd05.prod.outlook.com (52.135.234.161) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2430.16; Wed, 6 Nov 2019 20:57:08 +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.2430.020; Wed, 6 Nov 2019 20:57:08 +0000
From: Guy Fedorkow <gfedorkow@juniper.net>
To: Dave Thaler <dthaler=40microsoft.com@dmarc.ietf.org>
CC: "rats@ietf.org" <rats@ietf.org>, Thomas Hardjono <hardjono@mit.edu>, "Smith, Ned" <ned.smith@intel.com>, Henk Birkholz <henk.birkholz@sit.fraunhofer.de>, Jessica Fitzgerald-McKay <jmfmckay@gmail.com>
Thread-Topic: RIV and the RATS architecture
Thread-Index: AdWQISZnKaC7gFC9RTeTGiVYLOxchQDLr02gAGHv6oA=
Date: Wed, 6 Nov 2019 20:57:08 +0000
Message-ID: <BYAPR05MB42485F30F5B5E23220227E3BBA790@BYAPR05MB4248.namprd05.prod.outlook.com>
References: <BYAPR05MB4248980FA30CDF1ABCCC7E78BA630@BYAPR05MB4248.namprd05.prod.outlook.com> <MWHPR21MB0784B018797AB320A5B7C54CA37F0@MWHPR21MB0784.namprd21.prod.outlook.com>
In-Reply-To: <MWHPR21MB0784B018797AB320A5B7C54CA37F0@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_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=dc0a14cb-52f7-481f-9452-45415e41c007; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2019-11-04T20:56:07.9046064Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=dthaler@ntdev.microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=True; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Owner=gfedorkow@juniper.net; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2019-10-31T19:26:53.5191743Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=Juniper Business Use Only; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Application=Microsoft Azure Information Protection; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=c07f85d3-3baa-4bca-9285-7a27b371dd42; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Extended_MSFT_Method=Automatic
dlp-product: dlpe-windows
dlp-version: 11.3.2.8
dlp-reaction: no-action
x-originating-ip: [18.20.141.107]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 32c24d3e-9b3c-491a-c003-08d762fbe313
x-ms-traffictypediagnostic: BYAPR05MB4646:
x-ms-exchange-purlcount: 3
x-microsoft-antispam-prvs: <BYAPR05MB4646319780B54AAC0250C5CFBA790@BYAPR05MB4646.namprd05.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 02135EB356
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(396003)(376002)(39860400002)(366004)(136003)(199004)(189003)(6436002)(6506007)(316002)(186003)(71200400001)(71190400001)(74316002)(53546011)(6246003)(102836004)(446003)(54906003)(7736002)(476003)(76116006)(256004)(99286004)(76176011)(486006)(66946007)(64756008)(66446008)(66066001)(66556008)(7696005)(66476007)(26005)(6116002)(52536014)(229853002)(3846002)(8676002)(236005)(14444005)(11346002)(9686003)(2906002)(5660300002)(55016002)(6306002)(9326002)(54896002)(33656002)(25786009)(478600001)(8936002)(81166006)(81156014)(86362001)(790700001)(606006)(14454004)(966005)(4326008); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR05MB4646; H:BYAPR05MB4248.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX: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: h6nWRVkNm7m47PbAErM0vXRlUq7JHUhoXhNqQQ2FKQMV56sxhCKeqX7ARN+Kyp8XnKuhjRgsDeu3WbJdaDoGcF8mzBwBwW3yqgg3IEdMDkhjhCk8Rq7mMzReYqX0oVEKPmzU5UrhAOeRvTFnRE0pDLurG5J9xfk6AoB9sAmhbEC9lRnTso7LFlniIoc0YgVWfLQ61Zbdi4FUfW3hJamYfa8iwM6byj4yS1Ms3IDH4WkEN+hP1iNibIVHIrfEvWgPRIcWxuh6r7cVQYSRvXtI2N8XXDyxAZACsspJXFyi2ZBnkcu0KGRgBAeguPiX9zKW2nfdXSSfBvkxf/pUfl+Lga2kAgAGb8TIvpVvwZRFxAdcFa5Ri+DvEWIF2VnnyodMxx6P2UyX7V6YrHL0Q+poMAYf9Oletoq0U2LFXiscAI3WMar432jiVzw0ZNi7xLYuoM+8I3pFp2oxpcTTgwPsRu9is1upW/t7MG1cITZTFhM=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_BYAPR05MB42485F30F5B5E23220227E3BBA790BYAPR05MB4248namp_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: 32c24d3e-9b3c-491a-c003-08d762fbe313
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Nov 2019 20:57:08.1430 (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: b/GzNOOumFMhS6KZJZLnD6nfZ6Lgi9dhh7TuNeJrRter7Rki467PLMnqgkxrbbKwI0y39pUVC3dya0PH4Q0QEA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR05MB4646
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,18.0.572 definitions=2019-11-06_07:2019-11-06,2019-11-06 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 mlxscore=0 clxscore=1015 priorityscore=1501 phishscore=0 malwarescore=0 mlxlogscore=999 impostorscore=0 bulkscore=0 spamscore=0 suspectscore=0 adultscore=0 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-1911060207
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/XqcZ2L-OncIyGO1wOopQCNgtaDU>
Subject: Re: [Rats] RIV and the RATS architecture
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, 06 Nov 2019 20:57:15 -0000

Hi Dave,
  Ok, I suppose the model where the verifier communicates directly with the attested device is a kind of sub-contracted full-service background check.  That's ok with me, as long as no one interprets the diagram as meaning that the relying party must somehow insert itself into the exchange between Verifier and Attester.

  And I see what you mean about lining up the scope of RIV.  The draft has gone through a number of changes as we've tried to disentangle it from TCG tribal knowledge.
  I think the scope is set by a couple factors.
  The doc as written is clearly limited to TPM-based systems.  That's certainly not the only way to manage a root of trust, but it's the one that's available on a lot of gear already, and it's fairly stable and tightly spec'd.  From the TCG side, I'd expect there would be interest in extending the ideas to other TCG roots of trust such as DICE, but it seems that should be driven out of TCG.

  The limitation to Network Equipment is entirely a matter of expedience.  I think the approach would work easily in other embedded applications, although YANG is likely a fixation only relevant to networking guys.  Other domains would presumably need other domain-specific protocols.

  I'll connect with Jessica to see if we can figure out how to align the name and scope a bit better with the rest of the RATS world.

  Thanks
/guy




Juniper Business Use Only
From: Dave Thaler <dthaler=40microsoft.com@dmarc.ietf.org>
Sent: Monday, November 4, 2019 3:56 PM
To: Guy Fedorkow <gfedorkow@juniper.net>
Cc: rats@ietf.org; Thomas Hardjono <hardjono@mit.edu>du>; Smith, Ned <ned.smith@intel.com>om>; Henk Birkholz <henk.birkholz@sit.fraunhofer.de>de>; Jessica Fitzgerald-McKay <jmfmckay@gmail.com>
Subject: RE: RIV and the RATS architecture

Hi Guy, sorry for the delay, I was at a conference (Open Source Summit, Confidential Computing Consortium, and Linux Security Summit were all co-located) all last week and traveling there/back.

Responses inline below...

From: RATS <rats-bounces@ietf.org<mailto:rats-bounces@ietf.org>> On Behalf Of Guy Fedorkow
Sent: Thursday, October 31, 2019 12:27 PM
To: Dave Thaler <dthaler=40microsoft.com@dmarc.ietf.org<mailto:dthaler=40microsoft.com@dmarc.ietf.org>>
Cc: rats@ietf.org<mailto:rats@ietf.org>; Thomas Hardjono <hardjono@mit.edu<mailto:hardjono@mit.edu>>; Smith, Ned <ned.smith@intel.com<mailto:ned.smith@intel.com>>; Henk Birkholz <henk.birkholz@sit.fraunhofer.de<mailto:henk.birkholz@sit.fraunhofer.de>>; Jessica Fitzgerald-McKay <jmfmckay@gmail.com<mailto:jmfmckay@gmail.com>>
Subject: [Rats] RIV and the RATS architecture

Hi Dave,
  Thanks for your doc https://tools.ietf.org/html/draft-thaler-rats-architecture-00<https://urldefense.com/v3/__https:/nam06.safelinks.protection.outlook.com/?url=https*3A*2F*2Ftools.ietf.org*2Fhtml*2Fdraft-thaler-rats-architecture-00&data=02*7C01*7Cdthaler*40microsoft.com*7C520adf8cc884437d639508d75e385c4d*7C72f988bf86f141af91ab2d7cd011db47*7C1*7C0*7C637081468537546960&sdata=20zFPTGCbLybPlTaNB2E6uSb3re0G2bYPGC8F9TNXis*3D&reserved=0__;JSUlJSUlJSUlJSUlJSU!8WoA6RjC81c!Rpme4JKWETjOw_zisYJRdztjgIgNvTA_HZoPymMV_ggWZP8BkjOlbCzLuKc18WRBFIY$>zLuKc18WRBFIY$>.
  Do you have a view as to how the TPM-based attestation described in RIV would fit with the proposed categorization?
https://tools.ietf.org/html/draft-fedorkow-rats-network-device-attestation-00<https://urldefense.com/v3/__https:/nam06.safelinks.protection.outlook.com/?url=https*3A*2F*2Ftools.ietf.org*2Fhtml*2Fdraft-fedorkow-rats-network-device-attestation-00&data=02*7C01*7Cdthaler*40microsoft.com*7C520adf8cc884437d639508d75e385c4d*7C72f988bf86f141af91ab2d7cd011db47*7C1*7C0*7C637081468537556953&sdata=VTByXHpjuEMkojKjjly0i0BbnvujhB4fIpQaqiPFDKA*3D&reserved=0__;JSUlJSUlJSUlJSUlJSU!8WoA6RjC81c!Rpme4JKWETjOw_zisYJRdztjgIgNvTA_HZoPymMV_ggWZP8BkjOlbCzLuKc1fEcZrRQ$>

Great question. From my reading of draft-fedorkow-rats-network-device-attestation-00, it's a background check model, as section 2.3 of your doc explains:
>   3.  A Relying Party, which has access to the Verifier to request
>       attestation and to act on results.

That sentence above is by definition the background check model.
That is, the Attester talks to the Relying Party, the Relying Party then requests a background check by consulting a Verifier,
and will accept whatever answer the Verifier decides.
There are ways where you could use the passport model for network device attestation,
but your document only covers the background check model.

  It doesn't seem to be a passport, since the attester only provides raw evidence, not a pre-approved passport

Agreed, from my reading of your document.

  It doesn't seem to be a background check, as it's the verifier that collects and analyzes the evidence.

If I understand your point here, you're saying that the verifier talks directly to the attester (e.g., by querying the yang module), without going back through the relying party, and that that seemed to you to be different from a classic "background check" diagram.  Did I get your point correctly?

If so, then I see it as a variation of the background check model, as opposed to a separate model per se.

  I'm not sure it matters to RIV, as we haven't drawn much distinction between the relying party and the verifier...  As you say, if they're on the same machine, the distinction is almost moot.

Agree.

And if they're not, I think the communication is out of scope for RIV (if not for RATS).

I disagree that it's out of scope for RATS.

I have no opinion on whether it's out of scope for RIV, since I still have some confusion on the intended scope of RIV.
I note that your document constrains its scope (in section 1.5) to only TPM-based embedded devices, and not other
types of devices.   I couldn't tell if the scope of RIV and the scope of the draft (which does not have RIV in the name, or in
section 1.5) are similar or one is a subset of the other.   Indeed, the title of the document is far wider than just TPM-based
embedded devices, so in that sense the title doesn't match the scoping in section 1.5.   Just explaining why there's not
enough information for me to have an opinion on verifier-relying party communication in RIV.

There can be other network attestation solutions that look quite different from the flow in your draft
(and I have no skin in this game, so don't have a bias towards any solution in particular).   For example,
some other solution might involve a RADIUS server being a Verifier, so the verifier - relying party communication might
be RADIUS in that example.   There's many ways to construct solutions, and so I imagine there's probably multiple
solutions already out there, since the NEA problem is not new even in the IETF (https://tools.ietf.org/wg/nea/<https://urldefense.com/v3/__https:/tools.ietf.org/wg/nea/__;!8WoA6RjC81c!Rpme4JKWETjOw_zisYJRdztjgIgNvTA_HZoPymMV_ggWZP8BkjOlbCzLuKc1mSGm10I$> has
pointers to RFCs for anyone reading this who's not already aware of it).

  But it would be good ensure the architecture and the applications of it actually do fit together...

Absolutely.

Dave

  Thanks
/guy






Juniper Business Use Only