idnits 2.17.1 draft-birkholz-rats-information-model-01.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 (January 09, 2020) is 1568 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: 'P' is mentioned on line 333, but not defined == Missing Reference: 'H' is mentioned on line 313, but not defined == Missing Reference: 'S' is mentioned on line 333, but not defined == Missing Reference: 'O' is mentioned on line 195, but not defined == Missing Reference: 'V' is mentioned on line 333, but not defined == Unused Reference: 'I-D.birkholz-rats-tuda' is defined on line 362, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-rats-yang-tpm-charra' is defined on line 377, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 390, but no explicit reference was found in the text == Unused Reference: 'I-D.birkholz-rats-reference-interaction-model' is defined on line 402, but no explicit reference was found in the text == Unused Reference: 'I-D.richardson-rats-usecases' is defined on line 414, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-birkholz-rats-tuda-01 == Outdated reference: A later version (-22) exists of draft-ietf-rats-architecture-00 ** Downref: Normative reference to an Informational draft: draft-ietf-rats-architecture (ref. 'I-D.ietf-rats-architecture') == Outdated reference: A later version (-25) exists of draft-ietf-rats-eat-01 == Outdated reference: A later version (-22) exists of draft-ietf-rats-yang-tpm-charra-00 == Outdated reference: A later version (-22) exists of draft-tschofenig-rats-psa-token-04 ** Downref: Normative reference to an Informational draft: draft-tschofenig-rats-psa-token (ref. 'I-D.tschofenig-rats-psa-token') == Outdated reference: A later version (-03) exists of draft-birkholz-rats-reference-interaction-model-02 == Outdated reference: A later version (-08) exists of draft-richardson-rats-usecases-06 Summary: 3 errors (**), 0 flaws (~~), 18 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 M. Eckel 4 Intended status: Standards Track Fraunhofer SIT 5 Expires: July 12, 2020 January 09, 2020 7 An Information Model for Claims used in RATS 8 draft-birkholz-rats-information-model-01 10 Abstract 12 This document defines a standardized information model (IM) for 13 Claims that can be used in remote attestation procedures (RATS). The 14 information elements defined include attestation Claims which provide 15 information about system components characteristics, as well as 16 commonly used attributes and attribute structures that are required 17 by protocols facilitating remote attestation. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on July 12, 2020. 36 Copyright Notice 38 Copyright (c) 2020 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 1.1. Document Structure . . . . . . . . . . . . . . . . . . . 3 55 2. RATS Information Elements . . . . . . . . . . . . . . . . . . 4 56 3. Security Considerations . . . . . . . . . . . . . . . . . . . 8 57 4. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 58 5. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 8 59 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 8 60 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 61 7.1. Normative References . . . . . . . . . . . . . . . . . . 8 62 7.2. Informative References . . . . . . . . . . . . . . . . . 9 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 65 1. Introduction 67 Remote attestation procedures (RATS) are used to increase the trust 68 in the trustworthiness of an Attester. This is typically 69 accomplished by conveying Attestation Evidence from an Attester to a 70 Verifier that is able to appraise the Evidence. The exact 71 definitions of RATS roles, such as an Attester or a Verifier, are 72 specified in the RATS architecture [I-D.ietf-rats-architecture]. 73 This document defines the common information elements (IE) that are 74 able to express the characteristics of an Attester. Ultimately, 75 these IE can be used to compose Attestation Evidence (attestation 76 Claims that are accompanied by a proof of their validity). 78 In general, RATS convey information elements that: 80 o enable the functionality of remote attestation protocols, 82 o are able to express Claims about an Attester's composition, 83 configuration, or operational state, 85 o represent the provenance of Claims, including entities that 86 provide assertions on behalf of the Attester, 88 o compose a type of proof of validity with respect to other Claims, 89 and that 91 o are either verifiable (via comparison with trusted reference 92 values) or non-verifiable. 94 1.1. Document Structure 96 Every information element listed is annotated with one or more of 97 these attributes: 99 Protocol (P): This IE is used on a remote attestation protocol 100 layer, typically on the control plane or as protocol-specific data 101 plane content. 103 Hardware (H): This IE expresses characteristics about an Attester's 104 hardware components or the composition of its hardware components. 106 Software (S): This IE expresses characteristics about an Attester's 107 software components or their semantic relationship. The term 108 software component - in the scope of this document - subsumes 109 firmware, bootloader, BIOS/(U)EFI, and microcode. 111 Operational State (O): This IE is used to convey information about 112 the combination of applied configuration and system state as 113 defined in [RFC8342]. 115 Verifiable (V): This IE requires reference integrity measurements 116 (RIM), compliance-policy, certification-path, or another type of 117 trust-chain in order to be appraised appropriately by a Verifier. 119 Additionally, every IE definition includes a reference to the source 120 of its definition, if it is not specified in this document for the 121 first time (which is the most likely case). If a source of a 122 definition is not a specification or (proposed) standard, but a 123 draft, a web resource, or source that cannot be attribute with a DOI 124 or ISSN, the following attribute is associated. 126 Unstable (U): The source of the definition of this IE may change in 127 the future and is not considered to be stable at the time of 128 publication of this document. 130 Information elements might reference other information elements or 131 have to be associated in a set (with or without a specific order) in 132 order to convey the intended meaning to a Verifier. Reference to 133 other IE inside this documents simply use their name as reference. 134 In consequence, an IE can be a superstructure composed of other IE 135 with its own name (and potentially additional definition text that 136 defines its purpose and or usage). 138 The RATS Information Model allows for expressing a hierarchical 139 taxonomy. If an IE is a specialisation of another IE, the last 140 sentence in the definition includes a "This IE is a specialization of 141 _IE NAME_". 143 The ordering of IE is in descending alphabetical order; independent 144 of source or semantic relationship to other IE, or other types of 145 hierarchy. 147 2. RATS Information Elements 149 Age: The latency between the creation of a Claim value (e.g. by 150 asserters such as hardware sensors or the Linux Integrity 151 Measurement Architecture) including its composition into 152 Attestation Evidence and its following conveyance to another RATS 153 Actor/Role in RATS. The Age IE does not require a threshold at 154 which point another information element is considered "old" and an 155 age information element has to be included. 157 Reference: [I-D.ietf-rats-eat] 159 Claim Selection: [P] 161 A filter expression that enables the conveyance of a subset of all 162 attestation Claims available to the Attester, if requested by a 163 Verifier. 165 Attestation Evidence: [H, S, O, V] 167 A composite IE that must include at least an Authentication-Secret 168 Identifier, an Attester Identity, and at least one Attestation 169 Claim. Attestation Evidence is always signed via the 170 Authentication Secret and thereby binds the listed information 171 elements cryptographically. Attestation Evidence can only be 172 trusted by a Verifier if it is associated with a trust anchor the 173 Verifier also trusts. 175 Attester Identifier: [P, O, V] 177 A value associated or bound to a distinguishable Attester that is 178 intended to uniquely identify it, but is not directly associated 179 with a trust anchor. Additional Endorsement Documents can 180 increase the level of confidence in an Attester Identifier. 182 Attester Identity: [P, S, V] 184 A document about a distinguishable Attester issued and signed by a 185 third party. If not cryptographically associated with a trust 186 anchor directly or indirectly, this IE is a specialization of 187 Attester Identifier. 189 Attestation Result: [P] 190 A set of one or more values that are created by an appraisal 191 action of a Verifier. Attestation Result is the most generic 192 definition of the output of RATS and are typically consumed by 193 relying parties. 195 Authentication-Secret Identifier: [O, V] 197 An identifier that is associated with an authentication secret 198 used to sign Attestation Evidence. 200 Authorization Challenge: [P] 202 The input to an challenge-response protocol hand-shake. This IE 203 can be Nonce, but also the output of a local attestation 204 procedure. 206 Reference [I-D.tschofenig-rats-psa-token] 208 Endorsement Document: [P, H, S, V] 210 A document about the capabilities and functionality of one or more 211 sub-components of a distinguishable Attester issued and signed by 212 a third party. Endorsement Documents are intended to render 213 Attestation Evidence trustworthy. If not cryptographically 214 associated with a trust anchor directly or indirectly, this IE is 215 a specialization of System Component Identifier. 217 Location: A global standardized set of coordinates and related 218 attributes representing the geographic position of a device based 219 on a geodetic system, such as Navstar GPS. The coordinate values 220 can have different meaning with respect to the geographic position 221 of a device depending on the geodetic system used. The default is 222 WGS-84. 224 The basic location attributes include: latitude, longitude, 225 altitude, accuracy, altitude accuracy, heading, and velocity. 227 Reference [I-D.ietf-rats-eat] 229 Measured Boot Characteristics: [H, S, V] 231 If every piece of software is measured by a root-of-trust for 232 measuring during boot time and across staged execution 233 environments (e.g. UEFI, Bootloader, Kernel, Rich OS), associated 234 information about how and in which operational states these 235 measurements are conducted is vital to RATS. This IE represents 236 several states of a (composite) device with respect to measured 237 boot (previously often called secure boot) including: "Secure Boot 238 Enabled", "Debug Disabled", "Debug Disabled Since Boot", "Debug 239 Permanent Disable", "Debug Full Permanent Disable". 241 Nonce: [P] 243 An information element with two major uses: the prevention of 244 replay-attacks and as an IE that can be used in a challenge- 245 response interaction model. It is created by the requester to 246 provide Evidence about the freshness of the corresponding 247 response. It is important to highlight that a nonce by itself 248 does not protect from relay-attacks. 250 OEM Identifier: [H, S, V] 252 A organizationally unique identifier (OUI) assigned by the IEEE 253 Registration Authority (IEEE RA). This IE is associated with a 254 device or a distinguishable sub-component of a composite device 255 with its own execution environment. It intended to identify a 256 device(component) during its life-cycle. This is a specialization 257 of System Component Identifier. 259 Reference [I-D.ietf-rats-eat] 261 Origination: [P, S, V]] 263 An IE representing attestation provenance. Attestation Claims or 264 Attestation Evidence are produced by a specific source of 265 information that is intended to be uniquely identifiable. The 266 source of information is a distinguishable type of execution 267 environment (see [I-D.ietf-rats-architecture]) of a device or the 268 sub-components of a composite device. 270 Reference [I-D.ietf-rats-eat] 272 Universal Entity ID: [P, H, V] 274 A unique identifier permanently associated with an individual 275 manufactured entity / device, such as a mobile phone, a water 276 meter, a Bluetooth speaker or a networked security camera. This 277 IE is intended to either identify an device or a submodule or 278 subsystem of a device. It does not identify types, models or 279 classes of devices. It is akin to a serial number, though it does 280 not have to be sequential. This IE is a specialization of System 281 Component Identifier. 283 Reference [I-D.ietf-rats-eat] 285 Uptime: [H, S] 286 An IE representing the number of seconds since the first execution 287 environment of a (composite) device is able to measure it. 289 Reference [I-D.ietf-rats-eat] 291 Security Level: [H, S, V] 293 A level of confidence with respect to the resilience against 294 attacks intended to compromise Attestation Evidence. A Security 295 Level can be associated with an Origination. This IE is context 296 specific and requires a scope-specific definition of values as 297 part of a security framework. The [I-D.ietf-rats-eat] document, 298 for example, provides an enumeration of security levels that is 299 similar to the Metadata Service defined by the Fast Identity 300 Online (FIDO) Alliance. 302 Reference [I-D.ietf-rats-eat] 304 Software Component Identifier: [S, V] 306 An IE representing one or more distinguishable Software Components 307 [I-D.ietf-sacm-terminology] that were loaded and measured by an 308 appropriate root-of-trust. The use of this IE typically requires 309 the use of Measured Boot. 311 Reference [I-D.tschofenig-rats-psa-token] 313 System Component Identifier: [H, S, V] 315 An identifier intended to uniquely identify a distinguishable 316 system component. System components can be hardware components or 317 software components (e.g. a virtual machine). The system 318 component can be an "atomic" device (i.e. a composite device with 319 only one hardware component) or a part of a composite device. 321 Timestamp: [P, S] 323 A generic information element that represents a certain point of 324 time in the past. The level of confidence in the value of a 325 timestamp is based on the trustworthiness of the source of time, 326 which can be local or remote, a composite of multiple time sources 327 to represent the state synchronization, as well as the precision 328 and the accuracy of the source of time itself. 330 Timestamps can be time-zone specific and therefore change their 331 meaning if the definition of time zones changes. 333 Verification Service Indicator: [P, S, V] 334 This IE provides a hint (typically consumed by a Relying Party) 335 that enables the discovery of an appropriate Verification Service 336 or Remote Attestation Service, e.g. a URL. 338 Reference [I-D.tschofenig-rats-psa-token] 340 3. Security Considerations 342 Probably none 344 4. Acknowledgments 346 TBD 348 5. Change Log 350 Initial version -00 352 Refresh to version -01 for visibility 354 6. Contributors 356 TBD 358 7. References 360 7.1. Normative References 362 [I-D.birkholz-rats-tuda] 363 Fuchs, A., Birkholz, H., McDonald, I., and C. Bormann, 364 "Time-Based Uni-Directional Attestation", draft-birkholz- 365 rats-tuda-01 (work in progress), September 2019. 367 [I-D.ietf-rats-architecture] 368 Birkholz, H., Thaler, D., Richardson, M., and N. Smith, 369 "Remote Attestation Procedures Architecture", draft-ietf- 370 rats-architecture-00 (work in progress), December 2019. 372 [I-D.ietf-rats-eat] 373 Mandyam, G., Lundblade, L., Ballesteros, M., and J. 374 O'Donoghue, "The Entity Attestation Token (EAT)", draft- 375 ietf-rats-eat-01 (work in progress), July 2019. 377 [I-D.ietf-rats-yang-tpm-charra] 378 Birkholz, H., Eckel, M., Bhandari, S., Sulzen, B., Voit, 379 E., Xia, L., Laffey, T., and G. Fedorkow, "A YANG Data 380 Model for Challenge-Response-based Remote Attestation 381 Procedures using TPMs", draft-ietf-rats-yang-tpm-charra-00 382 (work in progress), January 2020. 384 [I-D.tschofenig-rats-psa-token] 385 Tschofenig, H., Frost, S., Brossard, M., Shaw, A., and T. 386 Fossati, "Arm's Platform Security Architecture (PSA) 387 Attestation Token", draft-tschofenig-rats-psa-token-04 388 (work in progress), November 2019. 390 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 391 Requirement Levels", BCP 14, RFC 2119, 392 DOI 10.17487/RFC2119, March 1997, 393 . 395 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 396 and R. Wilton, "Network Management Datastore Architecture 397 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 398 . 400 7.2. Informative References 402 [I-D.birkholz-rats-reference-interaction-model] 403 Birkholz, H. and M. Eckel, "Reference Interaction Models 404 for Remote Attestation Procedures", draft-birkholz-rats- 405 reference-interaction-model-02 (work in progress), January 406 2020. 408 [I-D.ietf-sacm-terminology] 409 Birkholz, H., Lu, J., Strassner, J., Cam-Winget, N., and 410 A. Montville, "Security Automation and Continuous 411 Monitoring (SACM) Terminology", draft-ietf-sacm- 412 terminology-16 (work in progress), December 2018. 414 [I-D.richardson-rats-usecases] 415 Richardson, M., Wallace, C., and W. Pan, "Use cases for 416 Remote Attestation common encodings", draft-richardson- 417 rats-usecases-06 (work in progress), November 2019. 419 Authors' Addresses 420 Henk Birkholz 421 Fraunhofer SIT 422 Rheinstrasse 75 423 Darmstadt 64295 424 Germany 426 Email: henk.birkholz@sit.fraunhofer.de 428 Michael Eckel 429 Fraunhofer SIT 430 Rheinstrasse 75 431 Darmstadt 64295 432 Germany 434 Email: michael.eckel@sit.fraunhofer.de