From nobody Tue Mar 22 05:52:54 2022 Return-Path: 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 41C323A1280 for ; Tue, 22 Mar 2022 05:52:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.109 X-Spam-Level: X-Spam-Status: No, score=-2.109 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, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net header.b=rem0RSD5; dkim=pass (1024-bit key) header.d=juniper.net header.b=PMxnCFa1 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 61Wu7s5TO_ho for ; Tue, 22 Mar 2022 05:52:19 -0700 (PDT) Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (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 378353A0FF3 for ; Tue, 22 Mar 2022 05:52:19 -0700 (PDT) Received: from pps.filterd (m0108163.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.1.2/8.16.1.2) with ESMTP id 22MC2cgu030794; Tue, 22 Mar 2022 05:52:15 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : content-type : mime-version; s=PPS1017; bh=Q9VEHwQtoxW/vGa/3KPs2uvtgs5lAG4icpFi1q3aSMI=; b=rem0RSD5QQBOBFmWxIIMBYXsUG6yEffB+QFX+2Jf40FEkIMeJ0Z7wgBZO4eTTh9zsi5y WmcTflT1NcTSKxC7HEVCHTSEjH2YGgFWelSnsIvyvPNLwUtkUMv7Rw54syDMR19C9mFP nGy1ArizSwotdFqkcBOKRfm29YKG74dABO3CoAxEfCOGN3PFlEraEyphXeSVIs/W2SrH U/RlXg6qyRkQRZ+ieVVlh4yXCvsiIZpLXG9P2HgRoUDQwdNW989czZL7jog7eg41oloP 0lU6RYWdaD9/ALFvvCt3XrYPoimJ1EEKOHVWVk6S9+YOPNeclLdDEUuHwbvh9Z+z1MEx Gw== Received: from nam11-bn8-obe.outbound.protection.outlook.com (mail-bn8nam11lp2169.outbound.protection.outlook.com [104.47.58.169]) by mx0b-00273201.pphosted.com (PPS) with ESMTPS id 3exqye33f1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 22 Mar 2022 05:52:15 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=dG4LHzXinGC7Ktqi/yCRIDQXGQjhCrkdIyZDMYfaQHFWmhcoOORiMo9eqOvC/j8cMhaBfZ/z224zgO41N0zA9fdrhUBSHhxTqSnYwlIA73tRWjYySRNvzDpIKrQSfUbhNa7XCPYorSczyJwOAl3rASsWT1ip/6PJzxiWRctFAR8spC5IWFdP9s6zDoz7q1a9/0URxeequw2e4sD2JXQvtV5beCjrC9ahmaGsgjono+VroB5qS2H58nO0WOpmIc/OeZjn6H6avbhSxCWaoe9Q7GcJaW7AoXvghYUs3yItujpz2tw+XrRLSbLwM5kFJEjCPXaCoqScK+J7DfKdsd0GUQ== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Q9VEHwQtoxW/vGa/3KPs2uvtgs5lAG4icpFi1q3aSMI=; b=Mm8YvD1YqaIrb9fV08WRyUQ4vJOfRK/lD5s6+S0A0wQ+Y3dnExPjElSpkifDUIGVU/3L3vRFLUI0mfHTlRGXknxxNqMRiQeLqMMWnWHcrpUNTPCVrGtsiDxFEPNZ/Rh8+ba9XVrUFG2XyV6HFXEEffrrU9N3FbAE7kGXwblg6dNgdq8VfToG19951mMSmCvBL7mNqyhpJw5fdHBkiuENzrabBo05kM4k8d3DuZNY9eSRcdQ9DzdyoB/2fkp8zWyLjas+qvkNz7iGIKvg560Ibt8tNrAL9Oi6NnULEGOMA5o3XCX0lfPTqtXjLWNfxnec1GeA0q75k3kJMJQQW2dfWQ== 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=Q9VEHwQtoxW/vGa/3KPs2uvtgs5lAG4icpFi1q3aSMI=; b=PMxnCFa1nWGfaKkC37quBWXZQVoLPEBbcQjmbDqw0Im/RGs0kFbJG+j6nZlivptmPSieLRgcrMR5MpAluzPGCAkEygOU+bd8HSei8/e7SORRZjByw2KSF9820c06tLZ6J6lVk3HL4jvGpXCuNZ/6v43uzKf85Sy3432D40jdEmk= Received: from BLAPR05MB7378.namprd05.prod.outlook.com (2603:10b6:208:298::10) by MW4PR05MB8748.namprd05.prod.outlook.com (2603:10b6:303:12b::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5102.11; Tue, 22 Mar 2022 12:52:13 +0000 Received: from BLAPR05MB7378.namprd05.prod.outlook.com ([fe80::541b:d93f:9060:8b1c]) by BLAPR05MB7378.namprd05.prod.outlook.com ([fe80::541b:d93f:9060:8b1c%3]) with mapi id 15.20.5102.016; Tue, 22 Mar 2022 12:52:13 +0000 From: Guy Fedorkow To: "rats@ietf.org" CC: "jmfitz2@cyber.nsa.gov" , "Eric Voit (evoit)" Thread-Topic: RIV draft version 14 Thread-Index: Adg96k/TEvJ8pwurQRuIY+oGVZp1cg== Date: Tue, 22 Mar 2022 12:52:13 +0000 Message-ID: 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_Enabled=true; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2022-03-22T12:52:11Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Method=Standard; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=0633b888-ae0d-4341-a75f-06e04137d755; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=5d7d9279-8241-43a8-8458-3c3184b8073c; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=2 x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 81c8fe0b-eb8d-4ab3-1ac0-08da0c02c93d x-ms-traffictypediagnostic: MW4PR05MB8748:EE_ x-ms-exchange-atpmessageproperties: SA|SL x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: JBirq9Ge0p6STdCw1FUhKcGXK0yu2OEGz1S1PkOONYxmdmHpI8Stx0V51WwAYrx4UybmNAgg6Ji83MpmniDX5b3yN+hSNk70AtvmtoZaNGCk3vx5BBTZ43JgLewVqSCp4vSUc8ud50bZuKQvK6XndJhaad1jlEpsJQCsxaQJluh72ug5IN7yUr3lPM+M6azNzV9gCoy/a8Bs+gT6b9KDIQzTnovlSjTRNt8Gs4zcgvbhUUk/7FTvijXK1YVSYa9M+zXVX+MBrfFpZ+h+gQPRM8LiofA4sPnzOG1V3tRebOY/JvdlzAFnt/SMdzOaKGD6sS0p5kU7h2rbaqqDCkuj6dLCQ71TmZVfzQB7oAZnrifF3YLYqkmbNTW322ic1TTcFv9Wq9tuEWezFfgLGDd1Stc03lBWYrC4naZVmQbpKjP+etK2wbrQuGoVZCtclB57oUSVFpcuBb7YFUgE3oFTInLXeHyPD/5pCG4JpkdEwXWN7TwGUWJ1Q7m1zPrIRxuSgFD/+1wmCgULQBC9xWKekGghFI8R2+HNm1z3Vdw432DeZQ+hJyl3C0woTBmSKfDAaqOW6vGRBIXYRKe1Yt2r/w6NlQLx3wfVUZ69D5J0oaIXXY0rCbC1SxIkU7CKMXsFovUj17CVqiJHdbKhlV2gyhu0eyC3nq0JevQkFGXzXMq0BB1025uoSoQgDHxo3w6v80KwrVcK8/aPD8GsDrQD9w== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BLAPR05MB7378.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(4636009)(366004)(52536014)(8936002)(9686003)(508600001)(186003)(26005)(64756008)(66446008)(66476007)(8676002)(4326008)(66556008)(66946007)(76116006)(7116003)(71200400001)(33656002)(6506007)(7696005)(38070700005)(55016003)(86362001)(6916009)(54906003)(38100700002)(316002)(83380400001)(5660300002)(122000001)(2906002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?UfqiVYQDuN2jqhXBTlO/FVA8D+DmYLaBLoN/AWfk9SD7FnSdEEB5FMdyKkcr?= =?us-ascii?Q?H6hneZG6RQ9VERCBFQ7yd0NWxkRoUmBDSqT9Qd7q73MfEXdvvKZN9fePHAwM?= =?us-ascii?Q?ywA4LnVKmJrpqfRQaa8yNROLBD/DMTCaIHFpMWsF181bXvdtvZgf2+SCxOF4?= =?us-ascii?Q?vhmIazrqEtyv6ZpR/XeMqAoAdB3NhkV6yaMQ7ij4+QxzN0y+EJg1/bjYtCyf?= =?us-ascii?Q?RKjfdA+3g663xlfZ9cJfr0XurG2RFVuAN/Wlv7cdjVK101Zf5mDkB6mz8FDi?= =?us-ascii?Q?j6cd5x/L8RyHY5AqxuLSVirnUETFGi5Rl5eOaElFPS28c+4yIr2VSoIucHq0?= =?us-ascii?Q?CKunifdSxMQeKyvpaDv1JqlCn4gCexWYQD5evV0bYl8PWkaD7nZFiwJk7K4b?= =?us-ascii?Q?ExkpJHix+gdq+y5PpQLOJ+ht3K28XcTWOBOmAK8ZyknnuFKeQsrYFfBQ0jKJ?= =?us-ascii?Q?5MEdBSWS5JI1w0blgClp3T0dqfq9ZSbVoDYyGSZxBwFFnWH2A4l/Br4nE4vN?= =?us-ascii?Q?RPl//O9f/hb6XFKe1tMj70TNHdCrOTlaDL9EdbvMAn9RkpQe9/2iEdsJDVf/?= =?us-ascii?Q?a11P43xEQZrcHKlJffZ7F16nL9GWu1KpjLrkr+P6eY/6xznjSFGd+Q1PSLHe?= =?us-ascii?Q?K9XzNEFjOZUQ8vhDA2Q3HG5GzrIy9Y9PFQrqntFpemsAWRj2syAXnKY19fhe?= =?us-ascii?Q?Q3J5ZF6du/7JXQmI3mrTnmGg7p4hUjlo90kGUBQuEPhEZZPZKZ2rYJtUf2A0?= =?us-ascii?Q?yb/d8I+SA7RmwmN4Q/usF7JOcFEZmtzB0FZ2aMvi0mql3VmVCvocm5ouPHw6?= =?us-ascii?Q?TbJzV5jVEBJ1f7kKviYh4c+FPH23M6aL4vWEEy8itVRZZt/lHhqGMCBE8Kh4?= =?us-ascii?Q?+ffcgRJpRSWb/IP0AXTvOwKfeMDlvubNq4IoFyFiN5s965EAozE7+jMQypDv?= =?us-ascii?Q?VhVQBWwm7phJQvkVwZuZYfpB3xf/4CJkSc+hdr8W7SWVHiGjoBOFUejZ8zzc?= =?us-ascii?Q?mKtE+XNwTYfRHlmBwPy7nzfqjwLtFkP5QfFFklkr5/EitBWTMbD72FAOMwZ2?= =?us-ascii?Q?ARftYaN18LV+Lb1elUoUNlokN3NH9+bL0bPHR1CQ9XjmUpJnvabIyqUbOat8?= =?us-ascii?Q?XVzp4aiWxJHXSxie+whHF6aRXJDu+v/Pg9xGA7jPq9dx8UdN2isEsfYRx13J?= =?us-ascii?Q?buoqc+SmzaiGBNPxUwD/XG3CaMz9h4FLO96uMkfhAZhFexxyQNO1Y6DMQARt?= =?us-ascii?Q?ALVFCirDEQGW68G/8W+ckbkJNukOJwh6xelhLfUQHALOLR8FiqXr9dDP+UIr?= =?us-ascii?Q?0vcrOezriOsXM86yrP7yfcoXKOZtkZHgxSst1yCM7u424gufIHmHbzXsKTTW?= =?us-ascii?Q?AIgc0Ds/XRZqELHQA5zIdSExXb/Gyr2EQB7OtYQRqlHMfkCl4u7S5Wazs0J9?= =?us-ascii?Q?2DUbAeD2bD7i7xeDcBQp2uPxaFTyTHwy?= Content-Type: multipart/alternative; boundary="_000_BLAPR05MB7378B36DB99D33883C2D78A0BA179BLAPR05MB7378namp_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BLAPR05MB7378.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 81c8fe0b-eb8d-4ab3-1ac0-08da0c02c93d X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Mar 2022 12:52:13.0945 (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: Ac0vwI3ndPBpP6AuH5HS06Uz6u/TDjbzpkA6vK+vz2WNf3ZwTlFEJ+z9PhF7Ckm4mKUyg5RBc3w1UZz6vORGQg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW4PR05MB8748 X-Proofpoint-GUID: 9sJHSn5pbgKXcia0ZrKSZF9JceNSRiY3 X-Proofpoint-ORIG-GUID: 9sJHSn5pbgKXcia0ZrKSZF9JceNSRiY3 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.850,Hydra:6.0.425,FMLib:17.11.64.514 definitions=2022-03-22_04,2022-03-22_01,2022-02-23_01 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 clxscore=1015 spamscore=0 suspectscore=0 adultscore=0 malwarescore=0 priorityscore=1501 impostorscore=0 lowpriorityscore=0 phishscore=0 mlxlogscore=791 bulkscore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2202240000 definitions=main-2203220074 Archived-At: Subject: [Rats] RIV draft version 14 X-BeenThere: rats@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Remote ATtestation procedureS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2022 12:52:29 -0000 --_000_BLAPR05MB7378B36DB99D33883C2D78A0BA179BLAPR05MB7378namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Greetings Fellow Rodents, I uploaded a Version 14 of the RIV draft to address a couple of remaining= comments from IESG review, and a few typos. In the process of doing this,= I noticed yet another typo ('encyption') which I'll fix with the next batc= h of editorial updates. Enclosed are the diffs. /guy ----------------------------- The first diff in Section 1.5 strives to eliminate an accidentally-implie= d dependence on an encrypted channel for reliable TPM-based attestation. T= his is not the case, as the attestation evidence is separately signed by ke= ys known only to the TPM. 4c4 < docname: draft-ietf-rats-tpm-based-network-device-attest-14 --- > docname: draft-ietf-rats-tpm-based-network-device-attest-13 386,392c386,391 < reliably transports the collected Evidence from Attester to a Verifier t= o allow a management station to perform < a meaningful appraisal in Step 4. The transport < is typically carried out via a management network. < While not required for reliable attestation, an encrypted channel may be= used to < provide integrity, authenticity, or confidentiality once attestation is = complete. < It should be noted that critical attestation evidence from the TPM is si= gned by a key known only to TPM, and is not < dependent on encyption carried out as part of a reliable transport. --- > reliably transports the collected Evidence from Attester to a Verifier to= allow a management station to perform > a meaningful appraisal in Step 4. The transport > is typically carried out via a management network. The channel must provi= de > integrity and authenticity, and, in some use cases, may also require conf= identiality. > It should be noted that critical attestation evidence from the TPM is sig= ned by a key known only to TPM, and is not > dependent on encyption carried out as part of a reliable transport. In Section 3.3 I changed the location of an "out of scope" note to get it c= loser to the place where the out-of-scope work is noted 956c955 < {{IETF-Attestation-Information-Flow}} above assumes that the Verifier is = trusted, while the Attester is not. In a Peer-to-Peer application such as = two routers negotiating a trust relationship, the two peers can each ask th= e other to prove software integrity. In this application, the information = flow is the same, but each side plays a role both as an Attester and a Veri= fier. Each device issues a challenge, and each device responds to the othe= r's challenge, as shown in {{Peer-to-peer-Information-Flow}}. Peer-to-peer= challenges, particularly if used to establish a trust relationship between= routers, require devices to carry their own signed reference measurements = (RIMs). Devices may also have to carry Appraisal Policy for Evidence for e= ach possible peer device so that each device has everything needed for remo= te attestation, without having to resort to a central authority. --- > {{IETF-Attestation-Information-Flow}} above assumes that the Verifier is = trusted, while the Attester is not. In a Peer-to-Peer application such as = two routers negotiating a trust relationship, the two peers can each ask th= e other to prove software integrity. In this application, the information = flow is the same, but each side plays a role both as an Attester and a Veri= fier. Each device issues a challenge, and each device responds to the othe= r's challenge, as shown in {{Peer-to-peer-Information-Flow}}. Peer-to-peer= challenges, particularly if used to establish a trust relationship between= routers, require devices to carry their own signed reference measurements = (RIMs). Devices may also have to carry Appraisal Policy for Evidence for e= ach possible peer device so that each device has everything needed for remo= te attestation, without having to resort to a central authority. Details o= f peer-to-peer operation are out of scope for this document. 992d990 < Details of peer-to-peer operation are out of scope for this document. The rest are literally commas and dashes. 396c395 < Attestation Result, used to inform decision-making. In practice, this = means comparing --- > Attestation Result, used to inform decision making. In practice, this = means comparing 398c397 < by the Verifier. Subsequently, the Appraisal Policy for Evidence might --- > by the Verifier. Subsequently the Appraisal Policy for Evidence might 598c597 < | (e.g. GRUB2 for Linux) | | | --- > | (e.g GRUB2 for Linux) | | | 864c863 < is based on the standard roles defined in {{I-D.ietf-rats-architecture}}.= However, additional prerequisites have been established to allow for inte= roperable RIV use case implementations. These prerequisites are intended t= o provide sufficient context information so that the Verifier can acquire a= nd evaluate measurements collected by the Attester. --- > is based on the standard roles defined in {{I-D.ietf-rats-architecture}}.= However additional prerequisites have been established to allow for inter= operable RIV use case implementations. These prerequisites are intended to= provide sufficient context information so that the Verifier can acquire an= d evaluate measurements collected by the Attester. 1102c1100 < A critical feature of the YANG model described in {{I-D.ietf-rats-yang-tp= m-charra}} is the ability to carry TPM data structures in their TCG-defined= format, without requiring any changes to the structures as they were signe= d and delivered by the TPM. While alternate methods of conveying TPM quote= s could compress out redundant information, or add another layer of signing= using external keys, the implementation MUST preserve the TPM signing, so = that tampering anywhere in the path between the TPM itself and the Verifier= can be detected. --- > A critical feature of the YANG model described in {{I-D.ietf-rats-yang-tp= m-charra}} is the ability to carry TPM data structures in their native form= at, without requiring any changes to the structures as they were signed and= delivered by the TPM. While alternate methods of conveying TPM quotes cou= ld compress out redundant information, or add an additional layer of signin= g using external keys, the implementation MUST preserve the TPM signing, so= that tampering anywhere in the path between the TPM itself and the Verifie= r can be detected. Juniper Business Use Only --_000_BLAPR05MB7378B36DB99D33883C2D78A0BA179BLAPR05MB7378namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Greetings Fellow Rodents,

  I uploaded a Version 14 of the RIV draft to a= ddress a couple of remaining comments from IESG review, and a few typos.&nb= sp; In the process of doing this, I noticed yet another typo (‘encypt= ion’) which I’ll fix with the next batch of editorial updates.

 

Enclosed are the diffs.

 

/guy

-----------------------------

 

  The first diff in Section 1.5 strives to elim= inate an accidentally-implied dependence on an encrypted channel for reliab= le TPM-based attestation.  This is not the case, as the attestation ev= idence is separately signed by keys known only to the TPM.

 

4c4

< docname: draft-ietf-rats-tpm-based-network-devi= ce-attest-14

---

> docname: draft-ietf-rats-tpm-based-network-devi= ce-attest-13

386,392c386,391

<  reliably transports the collected Evidenc= e from Attester to a Verifier to allow a management station to perform=

<  a meaningful appraisal in Step 4. The tra= nsport

<  is typically carried out via a management= network.

<  While not required for reliable attestati= on, an encrypted channel may be used to

<  provide integrity, authenticity, or confi= dentiality once attestation is complete.

<  It should be noted that critical attestat= ion evidence from the TPM is signed by a key known only to TPM, and is not<= o:p>

<  dependent on encyption carried out as par= t of a reliable transport.

---

> reliably transports the collected Evidence from= Attester to a Verifier to allow a management station to perform=

> a meaningful appraisal in Step 4. The transport=

> is typically carried out via a management netwo= rk. The channel must provide

> integrity and authenticity, and, in some use ca= ses, may also require confidentiality.

> It should be noted that critical attestation ev= idence from the TPM is signed by a key known only to TPM, and is not

> dependent on encyption carried out as part of a= reliable transport.

 

 

In Section 3.3 I changed the location of an “o= ut of scope” note to get it closer to the place where the out-of-scop= e work is noted

 

956c955

< {{IETF-Attestation-Information-Flow}} above ass= umes that the Verifier is trusted, while the Attester is not.  In a Pe= er-to-Peer application such as two routers negotiating a trust relationship= , the two peers can each ask the other to prove software integrity.  In this application, the information flow = is the same, but each side plays a role both as an Attester and a Verifier.=   Each device issues a challenge, and each device responds to the othe= r's challenge, as shown in {{Peer-to-peer-Information-Flow}}.  Peer-to-peer challenges, particularly if used to establish a trust relatio= nship between routers, require devices to carry their own signed reference = measurements (RIMs).  Devices may also have to carry Appraisal Policy = for Evidence for each possible peer device so that each device has everything needed for remote attestation, without = having to resort to a central authority.

---

> {{IETF-Attestation-Information-Flow}} above ass= umes that the Verifier is trusted, while the Attester is not.  In a Pe= er-to-Peer application such as two routers negotiating a trust relationship= , the two peers can each ask the other to prove software integrity.  In this application, the information flow = is the same, but each side plays a role both as an Attester and a Verifier.=   Each device issues a challenge, and each device responds to the othe= r's challenge, as shown in {{Peer-to-peer-Information-Flow}}.  Peer-to-peer challenges, particularly if used to establish a trust relatio= nship between routers, require devices to carry their own signed reference = measurements (RIMs).  Devices may also have to carry Appraisal Policy = for Evidence for each possible peer device so that each device has everything needed for remote attestation, without = having to resort to a central authority.  Details of peer-to-peer oper= ation are out of scope for this document.

992d990

< Details of peer-to-peer operation are out of sc= ope for this document.

 

 

The rest are literally commas and dashes.=

 

396c395

<   Attestation Result, used to inform = decision-making.  In practice, this means comparing

---

>   Attestation Result, used to inform = decision making.  In practice, this means comparing

398c397

<   by the Verifier.  Subsequently= , the Appraisal Policy for Evidence might

---

>   by the Verifier.  Subsequently= the Appraisal Policy for Evidence might

598c597

< | (e.g. GRUB2 for Linux)    = ;            &n= bsp;    |      |   &= nbsp;          |

---

> | (e.g GRUB2 for Linux)    =             &nb= sp;     |      |  &n= bsp;           |

864c863

< is based on the standard roles defined in {{I-D= .ietf-rats-architecture}}.  However, additional prerequisites have bee= n established to allow for interoperable RIV use case implementations. = ; These prerequisites are intended to provide sufficient context information so that the Verifier can acquire and evaluate measurem= ents collected by the Attester.

---

> is based on the standard roles defined in {{I-D= .ietf-rats-architecture}}.  However additional prerequisites have been= established to allow for interoperable RIV use case implementations. = These prerequisites are intended to provide sufficient context information so that the Verifier can acquire and evaluate measurem= ents collected by the Attester.

1102c1100

< A critical feature of the YANG model described = in {{I-D.ietf-rats-yang-tpm-charra}} is the ability to carry TPM data struc= tures in their TCG-defined format, without requiring any changes to the str= uctures as they were signed and delivered by the TPM.  While alternate methods of conveying TPM quotes could co= mpress out redundant information, or add another layer of signing using ext= ernal keys, the implementation MUST preserve the TPM signing, so that tampe= ring anywhere in the path between the TPM itself and the Verifier can be detected.

---

> A critical feature of the YANG model described = in {{I-D.ietf-rats-yang-tpm-charra}} is the ability to carry TPM data struc= tures in their native format, without requiring any changes to the structur= es as they were signed and delivered by the TPM.  While alternate methods of conveying TPM quotes could co= mpress out redundant information, or add an additional layer of signing usi= ng external keys, the implementation MUST preserve the TPM signing, so that= tampering anywhere in the path between the TPM itself and the Verifier can be detected.

 

 


Juniper Business= Use Only

--_000_BLAPR05MB7378B36DB99D33883C2D78A0BA179BLAPR05MB7378namp_--