idnits 2.17.00 (12 Aug 2021) /tmp/idnits59794/draft-ietf-rats-eat-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 : ---------------------------------------------------------------------------- ** There are 5 instances of too long lines in the document, the longest one being 21 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 04, 2019) is 1051 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'Webauthn' is defined on line 1079, but no explicit reference was found in the text ** Obsolete normative reference: RFC 7049 (Obsoleted by RFC 8949) -- Possible downref: Non-RFC (?) normative reference: ref. 'WGS84' Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RATS Working Group G. Mandyam 3 Internet-Draft Qualcomm Technologies Inc. 4 Intended status: Standards Track L. Lundblade 5 Expires: January 5, 2020 Security Theory LLC 6 M. Ballesteros 7 J. O'Donoghue 8 Qualcomm Technologies Inc. 9 July 04, 2019 11 The Entity Attestation Token (EAT) 12 draft-ietf-rats-eat-01 14 Abstract 16 An Entity Attestation Token (EAT) provides a signed (attested) set of 17 claims that describe state and characteristics of an entity, 18 typically a device like a phone or an IoT device. These claims are 19 used by a relying party to determine how much it wishes to trust the 20 entity. 22 An EAT is either a CWT or JWT with some attestation-oriented claims. 23 To a large degree, all this document does is extend CWT and JWT. 25 Contributing 27 TBD 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 January 5, 2020. 46 Copyright Notice 48 Copyright (c) 2019 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 64 1.1. CDDL, CWT and JWT . . . . . . . . . . . . . . . . . . . . 4 65 1.2. Entity Overview . . . . . . . . . . . . . . . . . . . . . 4 66 1.3. EAT Operating Models . . . . . . . . . . . . . . . . . . 5 67 1.4. What is Not Standardized . . . . . . . . . . . . . . . . 6 68 1.4.1. Transmission Protocol . . . . . . . . . . . . . . . . 6 69 1.4.2. Signing Scheme . . . . . . . . . . . . . . . . . . . 6 70 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 71 3. The Claims Information Model . . . . . . . . . . . . . . . . 8 72 3.1. Nonce Claim (cti and jti) . . . . . . . . . . . . . . . . 8 73 3.2. Timestamp claim (iat) . . . . . . . . . . . . . . . . . . 8 74 3.3. Universal Entity ID Claim (ueid) . . . . . . . . . . . . 8 75 3.4. Origination Claim (origination) . . . . . . . . . . . . . 11 76 3.4.1. CDDL . . . . . . . . . . . . . . . . . . . . . . . . 12 77 3.5. OEM identification by IEEE OUI (oemid) . . . . . . . . . 12 78 3.5.1. CDDL . . . . . . . . . . . . . . . . . . . . . . . . 12 79 3.6. The Security Level Claim (security_level) . . . . . . . . 12 80 3.6.1. CDDL . . . . . . . . . . . . . . . . . . . . . . . . 13 81 3.7. Secure Boot and Debug Enable State Claims (boot_state) . 13 82 3.7.1. Secure Boot Enabled . . . . . . . . . . . . . . . . . 13 83 3.7.2. Debug Disabled . . . . . . . . . . . . . . . . . . . 13 84 3.7.3. Debug Disabled Since Boot . . . . . . . . . . . . . . 14 85 3.7.4. Debug Permanent Disable . . . . . . . . . . . . . . . 14 86 3.7.5. Debug Full Permanent Disable . . . . . . . . . . . . 14 87 3.7.6. CDDL . . . . . . . . . . . . . . . . . . . . . . . . 14 88 3.8. The Location Claim (location) . . . . . . . . . . . . . . 14 89 3.8.1. CDDL . . . . . . . . . . . . . . . . . . . . . . . . 15 90 3.9. The Age Claim (age) . . . . . . . . . . . . . . . . . . . 15 91 3.10. The Uptime Claim (uptime) . . . . . . . . . . . . . . . . 15 92 3.10.1. CDDL . . . . . . . . . . . . . . . . . . . . . . . . 15 93 3.11. Nested EATs, the EAT Claim (nested_eat) . . . . . . . . . 15 94 3.11.1. CDDL . . . . . . . . . . . . . . . . . . . . . . . . 16 95 3.12. The Submods Claim (submods) . . . . . . . . . . . . . . . 16 96 3.12.1. The submod_name Claim . . . . . . . . . . . . . . . 16 97 3.12.2. CDDL . . . . . . . . . . . . . . . . . . . . . . . . 16 98 4. Data Model . . . . . . . . . . . . . . . . . . . . . . . . . 17 99 4.1. Common CDDL Types . . . . . . . . . . . . . . . . . . . . 17 100 4.2. CDDL for CWT-defined Claims . . . . . . . . . . . . . . . 17 101 4.3. JSON . . . . . . . . . . . . . . . . . . . . . . . . . . 18 102 4.3.1. JSON Labels . . . . . . . . . . . . . . . . . . . . . 18 103 4.3.2. JSON Interoperability . . . . . . . . . . . . . . . . 19 104 4.4. CBOR . . . . . . . . . . . . . . . . . . . . . . . . . . 19 105 4.4.1. Labels . . . . . . . . . . . . . . . . . . . . . . . 19 106 4.4.2. CBOR Interoperability . . . . . . . . . . . . . . . . 20 107 4.5. Collected CDDL . . . . . . . . . . . . . . . . . . . . . 21 108 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 109 5.1. Reuse of CBOR Web Token (CWT) Claims Registry . . . . . . 21 110 5.1.1. Claims Registered by This Document . . . . . . . . . 22 111 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 22 112 6.1. UEID Privacy Considerations . . . . . . . . . . . . . . . 22 113 7. Security Considerations . . . . . . . . . . . . . . . . . . . 23 114 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 115 8.1. Normative References . . . . . . . . . . . . . . . . . . 23 116 8.2. Informative References . . . . . . . . . . . . . . . . . 24 117 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 26 118 A.1. Very Simple EAT . . . . . . . . . . . . . . . . . . . . . 26 119 A.2. Example with Submodules, Nesting and Security Levels . . 26 120 Appendix B. Changes from Previous Drafts . . . . . . . . . . . . 27 121 B.1. From draft-mandyam-rats-eat-00 . . . . . . . . . . . . . 27 122 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 124 1. Introduction 126 Remote device attestation is a fundamental service that allows a 127 remote device such as a mobile phone, an Internet-of-Things (IoT) 128 device, or other endpoint to prove itself to a relying party, a 129 server or a service. This allows the relying party to know some 130 characteristics about the device and decide whether it trusts the 131 device. 133 Remote attestation is a fundamental service that can underlie other 134 protocols and services that need to know about the trustworthiness of 135 the device before proceeding. One good example is biometric 136 authentication where the biometric matching is done on the device. 137 The relying party needs to know that the device is one that is known 138 to do biometric matching correctly. Another example is content 139 protection where the relying party wants to know the device will 140 protect the data. This generalizes on to corporate enterprises that 141 might want to know that a device is trustworthy before allowing 142 corporate data to be accessed by it. 144 The notion of attestation here is large and may include, but is not 145 limited to the following: 147 o Proof of the make and model of the device hardware (HW) 149 o Proof of the make and model of the device processor, particularly 150 for security-oriented chips 152 o Measurement of the software (SW) running on the device 154 o Configuration and state of the device 156 o Environmental characteristics of the device such as its GPS 157 location 159 1.1. CDDL, CWT and JWT 161 An EAT token is either a CWT as defined in [RFC8392] or a JWT as 162 defined in [RFC7519]. This specification defines additional claims 163 for entity attestation. 165 This specification uses CDDL, [RFC8610], as the primary formalism to 166 define each claim. The implementor then interprets the CDDL to come 167 to either the CBOR [RFC7049] or JSON [ECMAScript] representation. In 168 the case of JSON, Appendix E of [RFC8610] is followed. Additional 169 rules are given in Section 4.3.2 of this document where Appendix E is 170 insufficient. (Note that this is not to define a general means to 171 translate between CBOR and JSON, but only to define enough such that 172 the claims defined in this document can be rendered unambiguously in 173 JSON). 175 1.2. Entity Overview 177 An "entity" can be any device or device subassembly ("submodule") 178 that can generate its own attestation in the form of an EAT. The 179 attestation should be cryptographically verifiable by the EAT 180 consumer. An EAT at the device-level can be composed of several 181 submodule EAT's. It is assumed that any entity that can create an 182 EAT does so by means of a dedicated root-of-trust (RoT). 184 Modern devices such as a mobile phone have many different execution 185 environments operating with different security levels. For example, 186 it is common for a mobile phone to have an "apps" environment that 187 runs an operating system (OS) that hosts a plethora of downloadable 188 apps. It may also have a TEE (Trusted Execution Environment) that is 189 distinct, isolated, and hosts security-oriented functionality like 190 biometric authentication. Additionally, it may have an eSE (embedded 191 Secure Element) - a high security chip with defenses against HW 192 attacks that can serve as a RoT. This device attestation format 193 allows the attested data to be tagged at a security level from which 194 it originates. In general, any discrete execution environment that 195 has an identifiable security level can be considered an entity. 197 1.3. EAT Operating Models 199 At least the following three participants exist in all EAT operating 200 models. Some operating models have additional participants. 202 The Entity. This is the phone, the IoT device, the sensor, the sub- 203 assembly or such that the attestation provides information about. 205 The Manufacturer. The company that made the entity. This may be a 206 chip vendor, a circuit board module vendor or a vendor of finished 207 consumer products. 209 The Relying Party. The server, service or company that makes use of 210 the information in the EAT about the entity. 212 In all operating models, the manufacturer provisions some secret 213 attestation key material (AKM) into the entity during manufacturing. 214 This might be during the manufacturer of a chip at a fabrication 215 facility (fab) or during final assembly of a consumer product or any 216 time in between. This attestation key material is used for signing 217 EATs. 219 In all operating models, hardware and/or software on the entity 220 create an EAT of the format described in this document. The EAT is 221 always signed by the attestation key material provisioned by the 222 manufacturer. 224 In all operating models, the relying party must end up knowing that 225 the signature on the EAT is valid and consistent with data from 226 claims in the EAT. This can happen in many different ways. Here are 227 some examples. 229 o The EAT is transmitted to the relying party. The relying party 230 gets corresponding key material (e.g. a root certificate) from the 231 manufacturer. The relying party performs the verification. 233 o The EAT is transmitted to the relying party. The relying party 234 transmits the EAT to a verification service offered by the 235 manufacturer. The server returns the validated claims. 237 o The EAT is transmitted directly to a verification service, perhaps 238 operated by the manufacturer or perhaps by another party. It 239 verifies the EAT and makes the validated claims available to the 240 relying party. It may even modify the claims in some way and re- 241 sign the EAT (with a different signing key). 243 All these operating models are supported and there is no preference 244 of one over the other. It is important to support this variety of 245 operating models to generally facilitate deployment and to allow for 246 some special scenarios. One special scenario has a validation 247 service that is monetized, most likely by the manufacturer. In 248 another, a privacy proxy service processes the EAT before it is 249 transmitted to the relying party. In yet another, symmetric key 250 material is used for signing. In this case the manufacturer should 251 perform the verification, because any release of the key material 252 would enable a participant other than the entity to create valid 253 signed EATs. 255 1.4. What is Not Standardized 257 The following is not standardized for EAT, just the same they are not 258 standardized for CWT or JWT. 260 1.4.1. Transmission Protocol 262 EATs may be transmitted by any protocol the same as CWTs and JWTs. 263 For example, they might be added in extension fields of other 264 protocols, bundled into an HTTP header, or just transmitted as files. 265 This flexibility is intentional to allow broader adoption. This 266 flexibility is possible because EAT's are self-secured with signing 267 (and possibly additionally with encryption and anti-replay). The 268 transmission protocol is not required to fulfill any additional 269 security requirements. 271 For certain devices, a direct connection may not exist between the 272 EAT-producing device and the Relying Party. In such cases, the EAT 273 should be protected against malicious access. The use of COSE and 274 JOSE allows for signing and encryption of the EAT. Therefore, even 275 if the EAT is conveyed through intermediaries between the device and 276 Relying Party, such intermediaries cannot easily modify the EAT 277 payload or alter the signature. 279 1.4.2. Signing Scheme 281 The term "signing scheme" is used to refer to the system that 282 includes end-end process of establishing signing attestation key 283 material in the entity, signing the EAT, and verifying it. This 284 might involve key IDs and X.509 certificate chains or something 285 similar but different. The term "signing algorithm" refers just to 286 the algorithm ID in the COSE signing structure. No particular 287 signing algorithm or signing scheme is required by this standard. 289 There are three main implementation issues driving this. First, 290 secure non-volatile storage space in the entity for the attestation 291 key material may be highly limited, perhaps to only a few hundred 292 bits, on some small IoT chips. Second, the factory cost of 293 provisioning key material in each chip or device may be high, with 294 even millisecond delays adding to the cost of a chip. Third, 295 privacy-preserving signing schemes like ECDAA (Elliptic Curve Direct 296 Anonymous Attestation) are complex and not suitable for all use 297 cases. 299 Over time to faciliate interoperability, some signing schemes may be 300 defined in EAT profiles or other documents either in the IETF or 301 outside. 303 2. Terminology 305 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 306 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 307 "OPTIONAL" in this document are to be interpreted as described in BCP 308 14 [RFC2119] [RFC8174] when, and only when, they appear in all 309 capitals, as shown here. 311 This document reuses terminology from JWT [RFC7519], COSE [RFC8152], 312 and CWT [RFC8392]. 314 Claim Name. The human-readable name used to identify a claim. 316 Claim Key. The CBOR map key or JSON name used to identify a claim. 318 Claim Value. The CBOR map or JSON object value representing the 319 value of the claim. 321 CWT Claims Set. The CBOR map or JSON object that contains the claims 322 conveyed by the CWT or JWT. 324 Attestation Key Material (AKM). The key material used to sign the 325 EAT token. If it is done symmetrically with HMAC, then this is a 326 simple symmetric key. If it is done with ECC, such as an IEEE 327 DevID [IDevID], then this is the private part of the EC key pair. 328 If ECDAA is used, (e.g., as used by Enhanced Privacy ID, i.e. 329 EPID) then it is the key material needed for ECDAA. 331 3. The Claims Information Model 333 This section describes new claims defined for attestation. It also 334 mentions several claims defined by CWT and JWT are particularly 335 important for EAT. 337 Note also: * Any claim defined for CWT or JWT may be used in an EAT 338 including those in the CWT [IANA.CWT.Claims] and JWT IANA 339 [IANA.JWT.Claims] claims registries. * All claims are optional * No 340 claims are mandatory * All claims that are not understood by 341 implementations MUST be ignored 343 CDDL along with text descriptions is used to define the information 344 model. Each claim is defined as a CDDL group (the group is a general 345 aggregation and type definition feature of CDDL). In the data model, 346 described in the Section 4, the CDDL groups turn into CBOR map 347 entries and JSON name/value pairs. 349 3.1. Nonce Claim (cti and jti) 351 All EATs should have a nonce to prevent replay attacks. The nonce is 352 generated by the relying party, sent to the entity by any protocol, 353 and included in the token. Note that intrinsically by the nature of 354 a nonce no security is needed for its transport. 356 CWT defines the "cti" claim. JWT defines the "jti" claim. These 357 carry the nonce in an EAT. 359 TODO: what about the JWT claim "nonce"? 361 3.2. Timestamp claim (iat) 363 The "iat" claim defined in CWT and JWT is used to indicate the date- 364 of-creation of the token. 366 3.3. Universal Entity ID Claim (ueid) 368 UEID's identify individual manufactured entities / devices such as a 369 mobile phone, a water meter, a Bluetooth speaker or a networked 370 security camera. It may identify the entire device or a submodule or 371 subsystem. It does not identify types, models or classes of devices. 372 It is akin to a serial number, though it does not have to be 373 sequential. 375 UEID's must be universally and globally unique across manufacturers 376 and countries. UEIDs must also be unique across protocols and 377 systems, as tokens are intended to be embedded in many different 378 protocols and systems. No two products anywhere, even in completely 379 different industries made by two different manufacturers in two 380 different countries should have the same UEID (if they are not global 381 and universal in this way, then relying parties receiving them will 382 have to track other characteristics of the device to keep devices 383 distinct between manufacturers). 385 There are privacy considerations for UEID's. See Section 6.1. 387 The UEID should be permanent. It should never change for a given 388 device / entity. In addition, it should not be reprogrammable. 389 UEID's are variable length. The recommended maximum is 33 bytes (1 390 type byte and 256 bits). The recommended minimum is 17 bytes (1 type 391 and 128 bits) because fewer bytes endanger the universal uniqueness. 393 When the entity constructs the UEID, the first byte is a type and the 394 following bytes the ID for that type. Several types are allowed to 395 accommodate different industries and different manufacturing 396 processes and to give options to avoid paying fees for certain types 397 of manufacturer registrations. 399 Creation of new types requires a Standards Action [RFC8126]. 401 +------+--------+---------------------------------------------------+ 402 | Type | Type | Specification | 403 | Byte | Name | | 404 +------+--------+---------------------------------------------------+ 405 | 0x01 | RAND | This is a 128- to 256-bit random number generated | 406 | | | once and stored in the device. This may be | 407 | | | constructed by concatenating enough identifiers | 408 | | | to be universally unique and then feeding the | 409 | | | concatenation through a cryptographic hash | 410 | | | function. It may also be a cryptographic quality | 411 | | | random number generate once at the beginning of | 412 | | | the life of the device and stored. | 413 | 0x02 | IEEE | This makes use of the IEEE company identification | 414 | | EUI | registry. An EUI is made up of an OUI and OUI-36 | 415 | | | or a CID, different registered company | 416 | | | identifiers, and some unique per-device | 417 | | | identifier. EUIs are often the same as or similar | 418 | | | to MAC addresses. (Note that while devices with | 419 | | | multiple network interfaces may have multiple MAC | 420 | | | addresses, there is only one UEID for a device) | 421 | | | TODO: normative references to IEEE. | 422 | 0x03 | IMEI | This is a 14-digit identifier consisting of an | 423 | | | 8-digit Type Allocation Code and a 6-digit serial | 424 | | | number allocated by the manufacturer, which SHALL | 425 | | | be encoded as a binary integer over 48 bits. The | 426 | | | IMEI value encoded SHALL NOT include Luhn | 427 | | | checksum or SVN information. | 428 | 0x04 | EUI-48 | This is a 48-bit identifier formed by | 429 | | | concatenating the 24-bit OUI with a 24-bit | 430 | | | identifier assigned by the organisation that | 431 | | | purchased the OUI. | 432 | 0x05 | EUI-60 | This is a 60-bit identifier formed by | 433 | | | concatenating the 24-bit OUI with a 36-bit | 434 | | | identifier assigned by the organisation that | 435 | | | purchased the OUI. | 436 | 0x06 | EUI-64 | This is a 64-bit identifier formed by | 437 | | | concatenating the 24-bit OUI with a 40-bit | 438 | | | identifier assigned by the organisation that | 439 | | | purchased the OUI. | 440 +------+--------+---------------------------------------------------+ 442 Table 1: UEID Composition Types 444 UEID's are not designed for direct use by humans (e.g., printing on 445 the case of a device), so no textual representation is defined. 447 The consumer (the relying party) of a UEID MUST treat a UEID as a 448 completely opaque string of bytes and not make any use of its 449 internal structure. For example, they should not use the OUI part of 450 a type 0x02 UEID to identify the manufacturer of the device. Instead 451 they should use the OUI claim that is defined elsewhere. The reasons 452 for this are: 454 o UEIDs types may vary freely from one manufacturer to the next. 456 o New types of UEIDs may be created. For example, a type 0x07 UEID 457 may be created based on some other manufacturer registration 458 scheme. 460 o Device manufacturers are allowed to change from one type of UEID 461 to another anytime they want. For example, they may find they can 462 optimize their manufacturing by switching from type 0x01 to type 463 0x02 or vice versa. The main requirement on the manufacturer is 464 that UEIDs be universally unique. 466 ### CDDL 468 ueid_claim = ( 469 ueid: bstr ) 471 3.4. Origination Claim (origination) 473 This claim describes the parts of the device or entity that are 474 creating the EAT. Often it will be tied back to the device or chip 475 manufacturer. The following table gives some examples: 477 +-------------------+-----------------------------------------------+ 478 | Name | Description | 479 +-------------------+-----------------------------------------------+ 480 | Acme-TEE | The EATs are generated in the TEE authored | 481 | | and configured by "Acme" | 482 | Acme-TPM | The EATs are generated in a TPM manufactured | 483 | | by "Acme" | 484 | Acme-Linux-Kernel | The EATs are generated in a Linux kernel | 485 | | configured and shipped by "Acme" | 486 | Acme-TA | The EATs are generated in a Trusted | 487 | | Application (TA) authored by "Acme" | 488 +-------------------+-----------------------------------------------+ 490 TODO: consider a more structure approach where the name and the URI 491 and other are in separate fields. 493 TODO: This needs refinement. It is somewhat parallel to issuer claim 494 in CWT in that it describes the authority that created the token. 496 3.4.1. CDDL 498 origination_claim = ( 499 origination: string_or_uri ) 501 3.5. OEM identification by IEEE OUI (oemid) 503 This claim identifies a device OEM by the IEEE OUI. Reference TBD. 504 It is a byte string representing the OUI in binary form in network 505 byte order (TODO: confirm details). 507 Companies that have more than one IEEE OUI registered with IEEE 508 should pick one and prefer that for all their devices. 510 Note that the OUI is in common use as a part of MAC Address. This 511 claim is only the first bits of the MAC address that identify the 512 manufacturer. The IEEE maintains a registry for these in which many 513 companies participate. 515 3.5.1. CDDL 517 oemid_claim = ( 518 oemid: bstr ) 520 3.6. The Security Level Claim (security_level) 522 EATs have a claim that roughly characterizes the device / entities 523 ability to defend against attacks aimed at capturing the signing key, 524 forging claims and at forging EATs. This is done by roughly defining 525 four security levels as described below. This is similar to the 526 security levels defined in the Metadata Service defined by the Fast 527 Identity Online (FIDO) Alliance (TODO: reference). 529 These claims describe security environment and countermeasures 530 available on the end-entity / client device where the attestation key 531 reside and the claims originate. 533 1 - Unrestricted There is some expectation that implementor will 534 protect the attestation signing keys at this level. Otherwise the 535 EAT provides no meaningful security assurances. 537 2- Restricted Entities at this level should not be general-purpose 538 operating environments that host features such as app download 539 systems, web browsers and complex productivity applications. It 540 is akin to the Secure Restricted level (see below) without the 541 security orientation. Examples include a Wi-Fi subsystem, an IoT 542 camera, or sensor device. 544 3 - Secure Restricted Entities at this level must meet the criteria 545 defined by FIDO Allowed Restricted Operating Environments (TODO: 546 reference). Examples include TEE's and schemes using 547 virtualization-based security. Like the FIDO security goal, 548 security at this level is aimed at defending well against large- 549 scale network / remote attacks against the device. 551 4 - Hardware Entities at this level must include substantial defense 552 against physical or electrical attacks against the device itself. 553 It is assumed any potential attacker has captured the device and 554 can disassemble it. Example include TPMs and Secure Elements. 556 This claim is not intended as a replacement for a proper end-device 557 security certification schemes such as those based on FIPS (TODO: 558 reference) or those based on Common Criteria (TODO: reference). The 559 claim made here is solely a self-claim made by the Entity Originator. 561 3.6.1. CDDL 563 security_level_type = ( 564 unrestricted: 1, 565 restricted: 2, 566 secure_restricted: 3, 567 hardware: 4 568 ) 570 security_level_claim = ( 571 security_level: security_level_type ) 573 3.7. Secure Boot and Debug Enable State Claims (boot_state) 575 This claim is an array of five Boolean values indicating the boot and 576 debug state of the entity. 578 3.7.1. Secure Boot Enabled 580 This indicates whether secure boot is enabled either for an entire 581 device or an individual submodule. If it appears at the device 582 level, then this means that secure boot is enabled for all 583 submodules. Secure boot enablement allows a secure boot loader to 584 authenticate software running either in a device or a submodule prior 585 allowing execution. 587 3.7.2. Debug Disabled 589 This indicates whether debug capabilities are disabled for an entity 590 (i.e. value of 'true'). Debug disablement is considered a 591 prerequisite before an entity is considered operational. 593 3.7.3. Debug Disabled Since Boot 595 This claim indicates whether debug capabilities for the entity were 596 not disabled in any way since boot (i.e. value of 'true'). 598 3.7.4. Debug Permanent Disable 600 This claim indicates whether debug capabilities for the entity are 601 permanently disabled (i.e. value of 'true'). This value can be set 602 to 'true' also if only the manufacturer is allowed to enabled debug, 603 but the end user is not. 605 3.7.5. Debug Full Permanent Disable 607 This claim indicates whether debug capabilities for the entity are 608 permanently disabled (i.e. value of 'true'). This value can only be 609 set to 'true' if no party can enable debug capabilities for the 610 entity. Often this is implemented by blowing a fuse on a chip as 611 fuses cannot be restored once blown. 613 3.7.6. CDDL 615 boot_state_type = [ 616 secure_boot_enabled=> bool, 617 debug_disabled=> bool, 618 debug_disabled_since_boot=> bool, 619 debug_permanent_disable=> bool, 620 debug_full_permanent_disable=> bool 621 ] 623 boot_state_claim = ( 624 boot_state: boot_state_type 625 ) 627 3.8. The Location Claim (location) 629 The location claim is a CBOR-formatted object that describes the 630 location of the device entity from which the attestation originates. 631 It is comprised of a map of additional sub claims that represent the 632 actual location coordinates (latitude, longitude and altitude). The 633 location coordinate claims are consistent with the WGS84 coordinate 634 system [WGS84]. In addition, a sub claim providing the estimated 635 accuracy of the location measurement is defined. 637 3.8.1. CDDL 639 location_type = { 640 latitude => number, 641 longitude => number, 642 altitude => number, 643 accuracy => number, 644 altitude_accuracy => number, 645 heading_claim => number, 646 speed_claim => number 647 } 649 location_claim = ( 650 location: location_type ) 652 3.9. The Age Claim (age) 654 The "age" claim contains a value that represents the number of 655 seconds that have elapsed since the token was created, measurement 656 was made, or location was obtained. Typical attestable values are 657 sent as soon as they are obtained. However, in the case that such a 658 value is buffered and sent at a later time and a sufficiently 659 accurate time reference is unavailable for creation of a timestamp, 660 then the age claim is provided. 662 age_claim = ( 663 age: uint) 665 3.10. The Uptime Claim (uptime) 667 The "uptime" claim contains a value that represents the number of 668 seconds that have elapsed since the entity or submod was last booted. 670 3.10.1. CDDL 672 uptime_claim = ( 673 uptime: uint ) 675 3.11. Nested EATs, the EAT Claim (nested_eat) 677 It is allowed for one EAT to be embedded in another. This is for 678 complex devices that have more than one subsystem capable of 679 generating an EAT. Typically, one will be the device-wide EAT that 680 is low to medium security and another from a Secure Element or 681 similar that is high security. 683 The contents of the "eat" claim must be a fully signed, optionally 684 encrypted, EAT token. 686 3.11.1. CDDL 688 nested_eat_claim = ( 689 nested_eat: nested_eat_type) 691 A nested_eat_type is defined in words rather than CDDL. It is either 692 a full CWT or JWT including the COSE or JOSE signing. 694 3.12. The Submods Claim (submods) 696 Some devices are complex, having many subsystems or submodules. A 697 mobile phone is a good example. It may have several connectivity 698 submodules for communications (e.g., Wi-Fi and cellular). It may 699 have subsystems for low-power audio and video playback. It may have 700 one or more security-oriented subsystems like a TEE or a Secure 701 Element. 703 The claims for each these can be grouped together in a submodule. 705 Specifically, the "submods" claim is an array. Each item in the 706 array is a CBOR map containing all the claims for a particular 707 submodule. 709 The security level of the submod is assumed to be at the same level 710 as the main entity unless there is a security level claim in that 711 submodule indicating otherwise. The security level of a submodule 712 can never be higher (more secure) than the security level of the EAT 713 it is a part of. 715 3.12.1. The submod_name Claim 717 Each submodule should have a submod_name claim that is descriptive 718 name. This name should be the CBOR txt type. 720 3.12.2. CDDL 722 In the following a generic_claim_type is any CBOR map entry or JSON 723 name/value pair. 725 submod_name_type = ( 726 submod_name: tstr ) 728 submods_type = [ * submod_claims ] 730 submod_claims = { 731 submod_name_type, 732 * generic_claim_type 733 } 735 submods_claim = ( 736 submods: submod_type ) 738 4. Data Model 740 This makes use of the types defined in CDDL Appendix D, Standard 741 Prelude. 743 4.1. Common CDDL Types 745 string_or_uri = #6.32(tstr) / tstr; See JSON section below for JSON encoding of string_or_uri 747 4.2. CDDL for CWT-defined Claims 749 This section provides CDDL for the claims defined in CWT. It is non- 750 normative as [RFC8392] is the authoritative definition of these 751 claims. 753 cwt_claim = ( 754 issuer_claim // 755 subject_claim // 756 audience_claim // 757 expiration_claim // 758 not_before_claim // 759 issued_at_calim // 760 cwt_id_claim 761 ) 763 issuer_claim = ( 764 issuer: string_or_uri ) 766 subject_claim = ( 767 subject: string_or_uri ) 769 audience_claim = ( 770 audience: string_or_uri ) 772 expiration_claim = ( 773 expiration: time ) 775 not_before_claim = ( 776 not_before: time ) 778 issued_at_calim = ( 779 issued_at: time ) 781 cwt_id_claim = ( 782 cwt_id: bstr ) 784 issuer = 1 785 subject = 2 786 audience = 3 787 expiration = 4 788 not_before = 5 789 issued_at = 6 790 cwt_id = 7 792 4.3. JSON 794 4.3.1. JSON Labels 795 ueid = "ueid" 796 origination = "origination" 797 oemid = "oemid" 798 security_level = "security_level" 799 boot_state = "boot_state" 800 location = "location" 801 age = "age" 802 uptime = "uptime" 803 nested_eat = "nested_eat" 804 submods = "submods" 806 4.3.2. JSON Interoperability 808 JSON should be encoded per RFC 8610 Appendix E. In addition, the 809 following CDDL types are encoded in JSON as follows: 811 o bstr - must be base64url encoded 813 o time - must be encoded as NumericDate as described section 2 of 814 [RFC7519]. 816 o string_or_uri - must be encoded as StringOrURI as described 817 section 2 of [RFC7519]. 819 4.4. CBOR 821 4.4.1. Labels 823 ueid = 8 824 origination = 9 825 oemid = 10 826 security_level = 11 827 boot_state = 12 828 location = 13 829 age = 14 830 uptime = 15 831 nested_eat = 16 832 submods = 17 833 submod_name = 18 835 latitude 1 836 longitude 2 837 altitude 3 838 accuracy 4 839 altitude_accuracy 5 840 heading_claim 6 841 speed_claim 7 843 4.4.2. CBOR Interoperability 845 Variations in the CBOR serializations supported in CBOR encoding and 846 decoding are allowed and suggests that CBOR-based protocols specify 847 how this variation is handled. This section specifies what formats 848 MUST be supported in order to achieve interoperability. 850 The assumption is that the entity is likely to be a constrained 851 device and relying party is likely to be a very capable server. The 852 approach taken is that the entity generating the token can use 853 whatever encoding it wants, specifically encodings that are easier to 854 implement such as indefinite lengths. The relying party receiving 855 the token must support decoding all encodings. 857 These rules cover all types used in the claims in this document. 858 They also are recommendations for additional claims. 860 Canonical CBOR encoding, Preferred Serialization and 861 Deterministically Encoded CBOR are explicitly NOT required as they 862 would place an unnecessary burden on the entity implementation, 863 particularly if the entity implementation is implemented in hardware. 865 o Integer Encoding (major type 0, 1) - The entity may use any 866 integer encoding allowed by CBOR. The server MUST accept all 867 integer encodings allowed by CBOR. 869 o String Encoding (major type 2 and 3) - The entity can use any 870 string encoding allowed by CBOR including indefinite lengths. It 871 may also encode the lengths of strings in any way allowed by CBOR. 872 The server must accept all string encodings. 874 o Major type 2, bstr, SHOULD be have tag 21 to indicate conversion 875 to base64url in case that conversion is performed. 877 o Map and Array Encoding (major type 4 and 5) - The entity can use 878 any array or map encoding allowed by CBOR including indefinite 879 lengths. Sorting of map keys is not required. Duplicate map keys 880 are not allowed. The server must accept all array and map 881 encodings. The server may reject maps with duplicate map keys. 883 o Date and Time - The entity should send dates as tag 1 encoded as 884 64-bit or 32-bit integers. The entity may not send floating-point 885 dates. The server must support tag 1 epoch-based dates encoded as 886 64-bit or 32-bit integers. The entity may send tag 0 dates, 887 however tag 1 is preferred. The server must support tag 0 UTC 888 dates. 890 o URIs - URIs should be encoded as text strings and marked with tag 891 32. 893 o Floating Point - The entity may use any floating-point encoding. 894 The relying party must support decoding of all types of floating- 895 point. 897 o Other types - Use of Other types like bignums, regular expressions 898 and such, SHOULD NOT be used. The server MAY support them but is 899 not required to so interoperability is not guaranteed. 901 4.5. Collected CDDL 903 A generic_claim is any CBOR map entry or JSON name/value pair. 905 eat_claims = { ; the top-level payload that is signed using COSE or JOSE 906 * claim 907 } 909 claim = ( 910 ueid_claim // 911 origination_claim // 912 oemid_claim // 913 security_level_claim // 914 boot_state_claim // 915 location_claim // 916 age_claim // 917 uptime_claim // 918 nested_eat_claim // 919 cwt_claim // 920 generic_claim_type // 921 ) 923 TODO: copy the rest of the CDDL here (wait until the CDDL is more 924 settled so as to avoid copying multiple times) 926 5. IANA Considerations 928 5.1. Reuse of CBOR Web Token (CWT) Claims Registry 930 Claims defined for EAT are compatible with those of CWT so the CWT 931 Claims Registry is re used. No new IANA registry is created. All 932 EAT claims should be registered in the CWT and JWT Claims Registries. 934 5.1.1. Claims Registered by This Document 936 o Claim Name: UEID 938 o Claim Description: The Universal Entity ID 940 o JWT Claim Name: N/A 942 o Claim Key: 8 944 o Claim Value Type(s): byte string 946 o Change Controller: IESG 948 o Specification Document(s): *this document* 950 TODO: add the rest of the claims in here 952 6. Privacy Considerations 954 Certain EAT claims can be used to track the owner of an entity and 955 therefore, implementations should consider providing privacy- 956 preserving options dependent on the intended usage of the EAT. 957 Examples would include suppression of location claims for EAT's 958 provided to unauthenticated consumers. 960 6.1. UEID Privacy Considerations 962 A UEID is usually not privacy-preserving. Any set of relying parties 963 that receives tokens that happen to be from a single device will be 964 able to know the tokens are all from the same device and be able to 965 track the device. Thus, in many usage situations ueid violates 966 governmental privacy regulation. In other usage situations UEID will 967 not be allowed for certain products like browsers that give privacy 968 for the end user. it will often be the case that tokens will not 969 have a UEID for these reasons. 971 There are several strategies that can be used to still be able to put 972 UEID's in tokens: 974 o The device obtains explicit permission from the user of the device 975 to use the UEID. This may be through a prompt. It may also be 976 through a license agreement. For example, agreements for some 977 online banking and brokerage services might already cover use of a 978 UEID. 980 o The UEID is used only in a particular context or particular use 981 case. It is used only by one relying party. 983 o The device authenticates the relying party and generates a derived 984 UEID just for that particular relying party. For example, the 985 relying party could prove their identity cryptographically to the 986 device, then the device generates a UEID just for that relying 987 party by hashing a proofed relying party ID with the main device 988 UEID. 990 Note that some of these privacy preservation strategies result in 991 multiple UEIDs per device. Each UEID is used in a different context, 992 use case or system on the device. However, from the view of the 993 relying party, there is just one UEID and it is still globally 994 universal across manufacturers. 996 7. Security Considerations 998 TODO: Perhaps this can be the same as CWT / COSE, but not sure yet 999 because it involves so much entity / device security that those do 1000 not. 1002 8. References 1004 8.1. Normative References 1006 [IANA.CWT.Claims] 1007 IANA, "CBOR Web Token (CWT) Claims", n.d., 1008 . 1010 [IANA.JWT.Claims] 1011 IANA, "JSON Web Token (JWT) Claims", n.d., 1012 . 1014 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1015 Requirement Levels", BCP 14, RFC 2119, 1016 DOI 10.17487/RFC2119, March 1997, 1017 . 1019 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 1020 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 1021 October 2013, . 1023 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 1024 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 1025 . 1027 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1028 Writing an IANA Considerations Section in RFCs", BCP 26, 1029 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1030 . 1032 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 1033 RFC 8152, DOI 10.17487/RFC8152, July 2017, 1034 . 1036 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1037 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1038 May 2017, . 1040 [RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, 1041 "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, 1042 May 2018, . 1044 [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data 1045 Definition Language (CDDL): A Notational Convention to 1046 Express Concise Binary Object Representation (CBOR) and 1047 JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, 1048 June 2019, . 1050 [TIME_T] The Open Group Base Specifications, "Vol. 1: Base 1051 Definitions, Issue 7", Section 4.15 'Seconds Since the 1052 Epoch', IEEE Std 1003.1, 2013 Edition, 2013, 1053 . 1056 [WGS84] National Imagery and Mapping Agency, "National Imagery and 1057 Mapping Agency Technical Report 8350.2, Third Edition", 1058 2000, . 1061 8.2. Informative References 1063 [ASN.1] International Telecommunication Union, "Information 1064 Technology -- ASN.1 encoding rules: Specification of Basic 1065 Encoding Rules (BER), Canonical Encoding Rules (CER) and 1066 Distinguished Encoding Rules (DER)", ITU-T Recommendation 1067 X.690, 1994. 1069 [ECMAScript] 1070 "Ecma International, "ECMAScript Language Specification, 1071 5.1 Edition", ECMA Standard 262", June 2011, 1072 . 1075 [IDevID] "IEEE Standard, "IEEE 802.1AR Secure Device Identifier"", 1076 December 2009, . 1079 [Webauthn] 1080 Worldwide Web Consortium, "Web Authentication: A Web API 1081 for accessing scoped credentials", 2016. 1083 Appendix A. Examples 1085 A.1. Very Simple EAT 1087 This is shown in CBOR diagnostic form. Only the payload signed by 1088 COSE is shown. 1090 { 1091 / nonce (cti) / 7:h'948f8860d13a463e8e', 1092 / UEID / 8:h'0198f50a4ff6c05861c8860d13a638ea4fe2f', 1093 / boot_state / 12:{true, true, true, true, false} 1094 / time stamp (iat) / 6:1526542894, 1095 } 1097 A.2. Example with Submodules, Nesting and Security Levels 1099 { 1100 / nonce / 7:h'948f8860d13a463e8e', 1101 / UEID / 8:h'0198f50a4ff6c05861c8860d13a638ea4fe2f', 1102 / boot_state / 12:{true, true, true, true, false} 1103 / time stamp (iat) / 6:1526542894, 1104 / seclevel / 11:3, / secure restricted OS / 1106 / submods / 17: 1107 [ 1108 / 1st submod, an Android Application / { 1109 / submod_name / 18:'Android App "Foo"', 1110 / seclevel / 11:1, / unrestricted / 1111 / app data / -70000:'text string' 1112 }, 1113 / 2nd submod, A nested EAT from a secure element / { 1114 / submod_name / 18:'Secure Element EAT', 1115 / eat / 16:61( 18( 1116 / an embedded EAT / [ /...COSE_Sign1 bytes with payload.../ ] 1117 )) 1118 } 1119 / 3rd submod, information about Linux Android / { 1120 / submod_name/ 18:'Linux Android', 1121 / seclevel / 11:1, / unrestricted / 1122 / custom - release / -80000:'8.0.0', 1123 / custom - version / -80001:'4.9.51+' 1124 } 1125 ] 1126 } 1127 Appendix B. Changes from Previous Drafts 1129 The following is a list of known changes from the previous drafts. 1130 This list is non-authoritative. It is meant to help reviewers see 1131 the significant differences. 1133 B.1. From draft-mandyam-rats-eat-00 1135 This is a fairly large change in the orientation of the document, but 1136 not new claims have been added. 1138 o Separate information and data model using CDDL. 1140 o Say an EAT is a CWT or JWT 1142 o Use a map to structure the boot_state and location claims 1144 Authors' Addresses 1146 Giridhar Mandyam 1147 Qualcomm Technologies Inc. 1148 5775 Morehouse Drive 1149 San Diego, California 1150 USA 1152 Phone: +1 858 651 7200 1153 EMail: mandyam@qti.qualcomm.com 1155 Laurence Lundblade 1156 Security Theory LLC 1158 EMail: lgl@island-resort.com 1160 Miguel Ballesteros 1161 Qualcomm Technologies Inc. 1162 5775 Morehouse Drive 1163 San Diego, California 1164 USA 1166 Phone: +1 858 651 4299 1167 EMail: mballest@qti.qualcomm.com 1168 Jeremy O'Donoghue 1169 Qualcomm Technologies Inc. 1170 279 Farnborough Road 1171 Farnborough GU14 7LS 1172 United Kingdom 1174 Phone: +44 1252 363189 1175 EMail: jodonogh@qti.qualcomm.com