idnits 2.17.1 draft-birkholz-rats-mud-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 10, 2020) is 1501 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'I-D.birkholz-rats-coswid-rim' is mentioned on line 133, but not defined == Outdated reference: A later version (-22) exists of draft-ietf-rats-architecture-02 == Outdated reference: A later version (-25) exists of draft-ietf-rats-eat-03 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RATS Working Group H. Birkholz 3 Internet-Draft Fraunhofer SIT 4 Intended status: Standards Track March 10, 2020 5 Expires: September 11, 2020 7 MUD-Based RATS Resources Discovery 8 draft-birkholz-rats-mud-00 10 Abstract 12 Manufacturer Usage Description (MUD) files and the MUD URI that point 13 to them are defined in RFC 8520. This document introduces a new type 14 of MUD file to be delivered in conjunction with a MUD file signature 15 and/or to be referenced via a MUD URI embedded in an IEEE 802.1AR 16 Secure Device Identifier (DevID). A DevID is a device specific pub- 17 key identity document that can be presented to other entities, e.g. a 18 network management system. If this entity is also a verifier as 19 defined by the IETF Remote ATtestation procedureS (RATS) 20 architecture, this verifier can use the references found in the MUD 21 file specified in this document in order to discover appropriate 22 Reference Integrity Measurements (RIM), Endorsement Documents, or 23 even globally suitable Remote Attestation Services (RAS). All three 24 types of theses resources are required to conduct RATS. Hence, the 25 MUD file defined in this document enables remote attestation 26 procedures by supporting the discovery of these required resources or 27 services. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on September 11, 2020. 46 Copyright Notice 48 Copyright (c) 2020 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (https://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 4 65 2. MUD URIs in DevIDs . . . . . . . . . . . . . . . . . . . . . 4 66 3. MUD File Signatures . . . . . . . . . . . . . . . . . . . . . 4 67 4. Trusting MUD URIs and MUD Files . . . . . . . . . . . . . . . 4 68 4.1. Trusting RATS Resources referenced by a MUD File . . . . 5 69 5. Specification of RATS MUD files referenced by MUD URIs . . . 5 70 5.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 5 71 5.2. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 5 72 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 8 73 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 74 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 75 8.1. Normative References . . . . . . . . . . . . . . . . . . 8 76 8.2. Informative References . . . . . . . . . . . . . . . . . 9 77 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 79 1. Introduction 81 Verifiers, Endorsers, and Attesters are roles defined in the RATS 82 Architecture [I-D.ietf-rats-architecture]. In the RATS architecture, 83 the Attester role relies on the Verifier and Endorser roles to enable 84 the appraisal of Attestation Evidence produced by said Attesters; and 85 to create corresponding Attestation Results. Attestation Results 86 compose a believable chunk of information that can be digested by 87 Relying Parities in order to assess an Attester's trustworthiness. 88 The assessment of a remote peer's trustworthiness is vital to steer 89 any future protocol interaction between the Attester and the remote 90 Relying Party. To create these Attestation Results to be consumed by 91 Relying Parties, the Attestation Evidence an Attester creates has to 92 be processed by one or more appropriate Verifiers. 94 This document defines a procedure that enables the discovery of 95 viable resources for RATS services in a local scope: 1.) Reference 96 Integrity Measurements, and 2.) Endorsement documents. 98 Additionally, a third option is provided: this document defines the 99 option to enable the discovery of remote Verfiers: 3.) Remote 100 Attestation Services (RAS) in a global scope (if no local trusted 101 authorities are available). 103 Attestation Policies and Endorsements are required to enable an 104 appropriate appraisal of Attestation Evidence in a fashion that helps 105 Relying Parties to digest the corresponding Attestation Results. 106 This document defines the use of MUD URIs embedded in Secure Device 107 Identifiers (IEEE 802.1AR DevIDs) as defined by [RFC8520]. These 108 DevIDs are enrolled on the Attester by manufacturers or related 109 supply chain entities with appropriate authority. The DevIDs can be 110 presented to local Network Management Systems, AAA-services (e.g. via 111 IEEE 802.1X), or other points of first contact (e.g. [RFC8071]) in a 112 local scope. These local entities of authority can digest the DevID 113 and conduct trust decisions based on the DevID by tracing associated 114 certification paths and trust anchors [RFC4949]. If the DevID 115 presented by the Attester is deemed to be trusted by the local trust 116 authority, the MUD URI embedded is considered to be a trusted source 117 of viable (and if their Identity Documents are also to be trusted - 118 believable) Attestation Policies, Endorsements, and even globally 119 available RAS. 121 In essence, the MUD file that is referenced by the DevID presented 122 refers to sources of Attestation Policies and Endorsements 123 recommended by the manufacturer or related supply chain entities with 124 appropriate authority. These sources are required by appraisal 125 procedures conducted by Verifiers in order to create well-founded 126 Attestation Results. For example, trusted Endorses can enrich 127 Attestation Results by vouching for the quality of hardware 128 components, the composition of a Composite Attester, or other 129 security characteristics of an Attester. 131 This specification does not define the format of Attestation Policies 132 and Endorsement documents. A type of Attestation Policies and their 133 representation is defined in [I-D.birkholz-rats-coswid-rim]. A 134 specific format of Endorsements for hardware components based on 135 [I-D.ietf-rats-eat] is defined in [I-D.birkholz-rats-endorsement- 136 eat]. 138 1.1. Requirements Notation 140 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 141 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 142 "OPTIONAL" in this document are to be interpreted as described in 143 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 144 capitals, as shown here. 146 2. MUD URIs in DevIDs 148 The MUD URI embedded in a DevID presented by an Attester points to a 149 MUD file. [RFC8520] defines the format of how to embed MUD URIs in 150 Secure Device Identifiers. This document uses this specification and 151 does neither modify nor augment the definition about how to compose a 152 MUD URI. 154 3. MUD File Signatures 156 As the resources required by a Verifier's appraisal procedures have 157 to be trustworthy, a MUD signature file for a corresponding MUD File 158 MUST be available. The MUD File MUST also include a reference to its 159 MUD signature file via the 'mud-signature' statement. A MUD 160 signature MAY be referenced in the DevID, but entities consuming this 161 information must be aware that a MUD File can change. If MUD file 162 changed (the MUD signature in the DevID does not match any more), a 163 MUD signature file referenced in the MUD File itself MUST exist and 164 MUST be available. If both the signature embedded in a DevID and 165 referenced by a MUD File do not match, the MUD File SHOULD NOT be 166 trusted. 168 4. Trusting MUD URIs and MUD Files 170 The level of assurance about the integrity of a MUD URI embedded in a 171 DevID is based on the level of trust put into the corresponding trust 172 anchor associated with the DevID. If you cannot establish a level of 173 trust towards the entity that signed a DevID (the signer), the 174 embedded MUD URI SHOULD NOT be trusted. 176 The level of assurance about the integrity of a MUD file is based on 177 the level of trust put into the entity that created the corresponding 178 MUD File Signature. If you cannot establish a level of trust put 179 into the corresponding trust anchor associated with the MUD signature 180 file, the referenced MUD File SHOULD NOT be trusted. 182 4.1. Trusting RATS Resources referenced by a MUD File 184 Reference Integrity Measurements and Endorsement documents that are 185 referenced by a MUD File MUST be signed. The signing procedures, the 186 format of corresponding Identity documents, and the establishment of 187 trust relationships associated with these resources are out-of-scope 188 of this document. 190 5. Specification of RATS MUD files referenced by MUD URIs 192 The MUD URI embedded in a DevID presented by an Attester points to a 193 MUD File. At the time of writing this -00 I-D, MUD URIs always point 194 to a piece of data that is a YANG-modeled XML file with a structure 195 specified in the style of a YANG module definition ([RFC7950] and 196 corresponding updates: [RFC8342], [RFC8526]). This document 197 specifies a YANG module augment definition for generic MUD files to 198 create RATS MUD files. The following definition MUST be used, if a 199 MUD URI points to a RATS MUD file. 201 5.1. Tree Diagram 203 The following tree diagram [RFC8340] provides an overview of the data 204 model for the "ietf-mud-rats" module augment. 206 208 module: ietf-mud-rats 209 augment /mud:mud: 210 +--rw ras 211 | +--rw ras-uris* inet:uri 212 +--rw rim 213 | +--rw rim-uris* inet:uri 214 +--rw edt 215 +--rw edt-uris* inet:uri 216 218 5.2. YANG Module 220 This YANG module has normative references to [RFC6991] and augments 221 [RFC8520]. 223 file ietf-mud-rats@2019-03-09.yang 224 module ietf-mud-rats { 225 yang-version 1.1; 226 namespace "urn:ietf:params:xml:ns:yang:ietf-mud-rats"; 227 prefix "mud-rats"; 229 import ietf-mud { 230 prefix "mud"; 231 } 233 import ietf-inet-types { 234 prefix "inet"; 235 } 237 organization 238 "IETF RATS (Remote ATtestation procedureS) Working Group"; 240 contact 241 "WG Web: http://tools.ietf.org/wg/rats/ 242 WG List: rats@ietf.org 243 Author: Eliot Lear 244 Author: Henk Birkholz "; 246 description 247 "This YANG module augments the ietf-mud model to provide for three 248 optional lists to enable Remote Attestation Procedures so that 249 this device type may be used as a controller for other 250 MUD-enabled devices. 252 Copyright (c) 2020 IETF Trust and the persons identified as 253 authors of the code. All rights reserved. 255 Redistribution and use in source and binary forms, with or 256 without modification, is permitted pursuant to, and subject to 257 the license terms contained in, the Simplified BSD License set 258 forth in Section 4.c of the IETF Trust's Legal Provisions 259 Relating to IETF Documents 260 (https://trustee.ietf.org/license-info). 262 This version of this YANG module is part of RFC XXXX 263 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself 264 for full legal notices. 266 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL 267 NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 268 'MAY', and 'OPTIONAL' in this document are to be interpreted as 269 described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, 270 they appear in all capitals, as shown here."; 272 revision 2020-03-09 { 273 description 274 "Initial proposed standard."; 275 reference "RFC XXXX: MUD Extension to find RATS supply chain 276 entity resources: remote attestation services, endorsement 277 documents, and reference integrity measurement"; 279 } 281 grouping mud-rats-grouping { 282 description 283 "Grouping to locate RATS services"; 284 container ras { 285 description 286 "Lists of Remote Attestation Service 287 (RAS/Verifiers) candidates."; 288 leaf-list ras-uris { 289 type inet:uri; 290 description 291 "A list of Verifiers that can appraise evidence produced by 292 the entity that presents a DevID including this MUD URI."; 293 } 294 } 295 container rim { 296 description 297 "Lists of Reference Integrity Measurement (RIM) candidates."; 298 leaf-list rim-uris { 299 type inet:uri; 300 description 301 "A list of RIM CoSWID that provide reference integrity 302 measurements represented as signed CoSWID using 303 the CoSWID RIM extension."; 304 } 305 } 306 container edt { 307 description 308 "List of Endorsements for Roots of Trusts (e.g. Endorsement 309 Key Certificates)."; 310 leaf-list edt-uris { 311 type inet:uri; 312 description 313 "A list of Endorsements that vouch for the characteristics 314 of Roots of Trusts the entity possesses."; 315 } 316 } 317 } 318 augment "/mud:mud" { 319 uses mud-rats-grouping; 320 description 321 "add mud-rats URI resources"; 322 } 323 } 324 326 6. Privacy Considerations 328 Potentially 330 7. Security Considerations 332 Most likely a summary of the trust relationship corresponding to the 333 RATS architecture 335 8. References 337 8.1. Normative References 339 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 340 Requirement Levels", BCP 14, RFC 2119, 341 DOI 10.17487/RFC2119, March 1997, 342 . 344 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 345 RFC 6991, DOI 10.17487/RFC6991, July 2013, 346 . 348 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 349 RFC 7950, DOI 10.17487/RFC7950, August 2016, 350 . 352 [RFC8071] Watsen, K., "NETCONF Call Home and RESTCONF Call Home", 353 RFC 8071, DOI 10.17487/RFC8071, February 2017, 354 . 356 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 357 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 358 May 2017, . 360 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 361 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 362 . 364 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 365 and R. Wilton, "Network Management Datastore Architecture 366 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 367 . 369 [RFC8520] Lear, E., Droms, R., and D. Romascanu, "Manufacturer Usage 370 Description Specification", RFC 8520, 371 DOI 10.17487/RFC8520, March 2019, 372 . 374 [RFC8526] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 375 and R. Wilton, "NETCONF Extensions to Support the Network 376 Management Datastore Architecture", RFC 8526, 377 DOI 10.17487/RFC8526, March 2019, 378 . 380 8.2. Informative References 382 [I-D.ietf-rats-architecture] 383 Birkholz, H., Thaler, D., Richardson, M., Smith, N., and 384 W. Pan, "Remote Attestation Procedures Architecture", 385 draft-ietf-rats-architecture-02 (work in progress), March 386 2020. 388 [I-D.ietf-rats-eat] 389 Mandyam, G., Lundblade, L., Ballesteros, M., and J. 390 O'Donoghue, "The Entity Attestation Token (EAT)", draft- 391 ietf-rats-eat-03 (work in progress), February 2020. 393 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 394 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, 395 . 397 Author's Address 399 Henk Birkholz 400 Fraunhofer SIT 401 Rheinstrasse 75 402 Darmstadt 64295 403 Germany 405 Email: henk.birkholz@sit.fraunhofer.de