idnits 2.17.1 draft-ietf-rats-eat-03.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 6 instances of too long lines in the document, the longest one being 13 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 (February 20, 2020) is 1519 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) == Unused Reference: 'Webauthn' is defined on line 1264, but no explicit reference was found in the text ** Obsolete normative reference: RFC 7049 (Obsoleted by RFC 8949) ** Obsolete normative reference: RFC 8152 (Obsoleted by RFC 9052, RFC 9053) -- Possible downref: Non-RFC (?) normative reference: ref. 'WGS84' Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 2 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: August 23, 2020 Security Theory LLC 6 M. Ballesteros 7 J. O'Donoghue 8 Qualcomm Technologies Inc. 9 February 20, 2020 11 The Entity Attestation Token (EAT) 12 draft-ietf-rats-eat-03 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 August 23, 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 . . . . . . . . . . . . . . . . . . . . . . . . 4 64 1.1. CDDL, CWT and JWT . . . . . . . . . . . . . . . . . . . . 4 65 1.2. Entity Overview . . . . . . . . . . . . . . . . . . . . . 5 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 . . . . . . . . . . . . . . . . . . . 7 70 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 71 3. The Claims . . . . . . . . . . . . . . . . . . . . . . . . . 8 72 3.1. Token ID Claim (cti and jti) . . . . . . . . . . . . . . 8 73 3.2. Timestamp claim (iat) . . . . . . . . . . . . . . . . . . 9 74 3.3. Nonce Claim (nonce) . . . . . . . . . . . . . . . . . . . 9 75 3.3.1. nonce CDDL . . . . . . . . . . . . . . . . . . . . . 9 76 3.4. Universal Entity ID Claim (ueid) . . . . . . . . . . . . 9 77 3.4.1. ueid CDDL . . . . . . . . . . . . . . . . . . . . . . 12 78 3.5. Origination Claim (origination) . . . . . . . . . . . . . 12 79 3.5.1. origination CDDL . . . . . . . . . . . . . . . . . . 12 80 3.6. OEM Identification by IEEE (oemid) . . . . . . . . . . . 12 81 3.6.1. oemid CDDL . . . . . . . . . . . . . . . . . . . . . 13 82 3.7. The Security Level Claim (security-level) . . . . . . . . 13 83 3.7.1. security-level CDDL . . . . . . . . . . . . . . . . . 14 84 3.8. Secure Boot and Debug Enable State Claims (boot-state) . 14 85 3.8.1. Secure Boot Enabled . . . . . . . . . . . . . . . . . 14 86 3.8.2. Debug Disabled . . . . . . . . . . . . . . . . . . . 15 87 3.8.3. Debug Disabled Since Boot . . . . . . . . . . . . . . 15 88 3.8.4. Debug Permanent Disable . . . . . . . . . . . . . . . 15 89 3.8.5. Debug Full Permanent Disable . . . . . . . . . . . . 15 90 3.8.6. boot-state CDDL . . . . . . . . . . . . . . . . . . . 15 91 3.9. The Location Claim (location) . . . . . . . . . . . . . . 15 92 3.9.1. location CDDL . . . . . . . . . . . . . . . . . . . . 16 93 3.10. The Age Claim (age) . . . . . . . . . . . . . . . . . . . 16 94 3.10.1. age CDDL . . . . . . . . . . . . . . . . . . . . . . 16 95 3.11. The Uptime Claim (uptime) . . . . . . . . . . . . . . . . 16 96 3.11.1. uptime CDDL . . . . . . . . . . . . . . . . . . . . 16 97 3.12. The Submods Part of a Token (submods) . . . . . . . . . . 17 98 3.12.1. Two Types of Submodules . . . . . . . . . . . . . . 17 99 3.12.1.1. Non-token Submodules . . . . . . . . . . . . . . 17 100 3.12.1.2. Nested EATs . . . . . . . . . . . . . . . . . . 17 101 3.12.2. No Inheritance . . . . . . . . . . . . . . . . . . . 18 102 3.12.3. Security Levels . . . . . . . . . . . . . . . . . . 18 103 3.12.4. Submodule Names . . . . . . . . . . . . . . . . . . 18 104 3.12.5. submods CDDL . . . . . . . . . . . . . . . . . . . . 18 105 4. Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . 18 106 4.1. Common CDDL Types . . . . . . . . . . . . . . . . . . . . 19 107 4.2. CDDL for CWT-defined Claims . . . . . . . . . . . . . . . 19 108 4.3. JSON . . . . . . . . . . . . . . . . . . . . . . . . . . 19 109 4.3.1. JSON Labels . . . . . . . . . . . . . . . . . . . . . 19 110 4.3.2. JSON Interoperability . . . . . . . . . . . . . . . . 20 111 4.4. CBOR . . . . . . . . . . . . . . . . . . . . . . . . . . 20 112 4.4.1. CBOR Labels . . . . . . . . . . . . . . . . . . . . . 20 113 4.4.2. CBOR Interoperability . . . . . . . . . . . . . . . . 21 114 4.5. Collected CDDL . . . . . . . . . . . . . . . . . . . . . 22 115 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 116 5.1. Reuse of CBOR Web Token (CWT) Claims Registry . . . . . . 23 117 5.1.1. Claims Registered by This Document . . . . . . . . . 23 118 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 24 119 6.1. UEID Privacy Considerations . . . . . . . . . . . . . . . 24 120 7. Security Considerations . . . . . . . . . . . . . . . . . . . 25 121 7.1. Key Provisioning . . . . . . . . . . . . . . . . . . . . 25 122 7.1.1. Transmission of Key Material . . . . . . . . . . . . 25 123 7.2. Transport Security . . . . . . . . . . . . . . . . . . . 25 124 7.3. Multiple EAT Consumers . . . . . . . . . . . . . . . . . 26 125 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 126 8.1. Normative References . . . . . . . . . . . . . . . . . . 26 127 8.2. Informative References . . . . . . . . . . . . . . . . . 28 128 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 30 129 A.1. Very Simple EAT . . . . . . . . . . . . . . . . . . . . . 30 130 A.2. Example with Submodules, Nesting and Security Levels . . 30 131 Appendix B. UEID Design Rationale . . . . . . . . . . . . . . . 30 132 B.1. Collision Probability . . . . . . . . . . . . . . . . . . 30 133 B.2. No Use of UUID . . . . . . . . . . . . . . . . . . . . . 33 134 Appendix C. Changes from Previous Drafts . . . . . . . . . . . . 34 135 C.1. From draft-rats-eat-01 . . . . . . . . . . . . . . . . . 34 136 C.2. From draft-mandyam-rats-eat-00 . . . . . . . . . . . . . 34 137 C.3. From draft-ietf-rats-eat-01 . . . . . . . . . . . . . . . 34 138 C.4. From draft-ietf-rats-eat-02 . . . . . . . . . . . . . . . 34 139 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35 141 1. Introduction 143 Remote device attestation is a fundamental service that allows a 144 remote device such as a mobile phone, an Internet-of-Things (IoT) 145 device, or other endpoint to prove itself to a relying party, a 146 server or a service. This allows the relying party to know some 147 characteristics about the device and decide whether it trusts the 148 device. 150 Remote attestation is a fundamental service that can underlie other 151 protocols and services that need to know about the trustworthiness of 152 the device before proceeding. One good example is biometric 153 authentication where the biometric matching is done on the device. 154 The relying party needs to know that the device is one that is known 155 to do biometric matching correctly. Another example is content 156 protection where the relying party wants to know the device will 157 protect the data. This generalizes on to corporate enterprises that 158 might want to know that a device is trustworthy before allowing 159 corporate data to be accessed by it. 161 The notion of attestation here is large and may include, but is not 162 limited to the following: 164 o Proof of the make and model of the device hardware (HW) 166 o Proof of the make and model of the device processor, particularly 167 for security-oriented chips 169 o Measurement of the software (SW) running on the device 171 o Configuration and state of the device 173 o Environmental characteristics of the device such as its GPS 174 location 176 1.1. CDDL, CWT and JWT 178 An EAT token is either a CWT as defined in [RFC8392] or a JWT as 179 defined in [RFC7519]. This specification defines additional claims 180 for entity attestation. 182 This specification uses CDDL, [RFC8610], as the primary formalism to 183 define each claim. The implementor then interprets the CDDL to come 184 to either the CBOR [RFC7049] or JSON [ECMAScript] representation. In 185 the case of JSON, Appendix E of [RFC8610] is followed. Additional 186 rules are given in Section 4.3.2 of this document where Appendix E is 187 insufficient. (Note that this is not to define a general means to 188 translate between CBOR and JSON, but only to define enough such that 189 the claims defined in this document can be rendered unambiguously in 190 JSON). 192 1.2. Entity Overview 194 An "entity" can be any device or device subassembly ("submodule") 195 that can generate its own attestation in the form of an EAT. The 196 attestation should be cryptographically verifiable by the EAT 197 consumer. An EAT at the device-level can be composed of several 198 submodule EAT's. It is assumed that any entity that can create an 199 EAT does so by means of a dedicated root-of-trust (RoT). 201 Modern devices such as a mobile phone have many different execution 202 environments operating with different security levels. For example, 203 it is common for a mobile phone to have an "apps" environment that 204 runs an operating system (OS) that hosts a plethora of downloadable 205 apps. It may also have a TEE (Trusted Execution Environment) that is 206 distinct, isolated, and hosts security-oriented functionality like 207 biometric authentication. Additionally, it may have an eSE (embedded 208 Secure Element) - a high security chip with defenses against HW 209 attacks that can serve as a RoT. This device attestation format 210 allows the attested data to be tagged at a security level from which 211 it originates. In general, any discrete execution environment that 212 has an identifiable security level can be considered an entity. 214 1.3. EAT Operating Models 216 At least the following three participants exist in all EAT operating 217 models. Some operating models have additional participants. 219 The Entity. This is the phone, the IoT device, the sensor, the sub- 220 assembly or such that the attestation provides information about. 222 The Manufacturer. The company that made the entity. This may be a 223 chip vendor, a circuit board module vendor or a vendor of finished 224 consumer products. 226 The Relying Party. The server, service or company that makes use of 227 the information in the EAT about the entity. 229 In all operating models, the manufacturer provisions some secret 230 attestation key material (AKM) into the entity during manufacturing. 231 This might be during the manufacturer of a chip at a fabrication 232 facility (fab) or during final assembly of a consumer product or any 233 time in between. This attestation key material is used for signing 234 EATs. 236 In all operating models, hardware and/or software on the entity 237 create an EAT of the format described in this document. The EAT is 238 always signed by the attestation key material provisioned by the 239 manufacturer. 241 In all operating models, the relying party must end up knowing that 242 the signature on the EAT is valid and consistent with data from 243 claims in the EAT. This can happen in many different ways. Here are 244 some examples. 246 o The EAT is transmitted to the relying party. The relying party 247 gets corresponding key material (e.g. a root certificate) from the 248 manufacturer. The relying party performs the verification. 250 o The EAT is transmitted to the relying party. The relying party 251 transmits the EAT to a verification service offered by the 252 manufacturer. The server returns the validated claims. 254 o The EAT is transmitted directly to a verification service, perhaps 255 operated by the manufacturer or perhaps by another party. It 256 verifies the EAT and makes the validated claims available to the 257 relying party. It may even modify the claims in some way and re- 258 sign the EAT (with a different signing key). 260 All these operating models are supported and there is no preference 261 of one over the other. It is important to support this variety of 262 operating models to generally facilitate deployment and to allow for 263 some special scenarios. One special scenario has a validation 264 service that is monetized, most likely by the manufacturer. In 265 another, a privacy proxy service processes the EAT before it is 266 transmitted to the relying party. In yet another, symmetric key 267 material is used for signing. In this case the manufacturer should 268 perform the verification, because any release of the key material 269 would enable a participant other than the entity to create valid 270 signed EATs. 272 1.4. What is Not Standardized 274 The following is not standardized for EAT, just the same they are not 275 standardized for CWT or JWT. 277 1.4.1. Transmission Protocol 279 EATs may be transmitted by any protocol the same as CWTs and JWTs. 280 For example, they might be added in extension fields of other 281 protocols, bundled into an HTTP header, or just transmitted as files. 282 This flexibility is intentional to allow broader adoption. This 283 flexibility is possible because EAT's are self-secured with signing 284 (and possibly additionally with encryption and anti-replay). The 285 transmission protocol is not required to fulfill any additional 286 security requirements. 288 For certain devices, a direct connection may not exist between the 289 EAT-producing device and the Relying Party. In such cases, the EAT 290 should be protected against malicious access. The use of COSE and 291 JOSE allows for signing and encryption of the EAT. Therefore, even 292 if the EAT is conveyed through intermediaries between the device and 293 Relying Party, such intermediaries cannot easily modify the EAT 294 payload or alter the signature. 296 1.4.2. Signing Scheme 298 The term "signing scheme" is used to refer to the system that 299 includes end-end process of establishing signing attestation key 300 material in the entity, signing the EAT, and verifying it. This 301 might involve key IDs and X.509 certificate chains or something 302 similar but different. The term "signing algorithm" refers just to 303 the algorithm ID in the COSE signing structure. No particular 304 signing algorithm or signing scheme is required by this standard. 306 There are three main implementation issues driving this. First, 307 secure non-volatile storage space in the entity for the attestation 308 key material may be highly limited, perhaps to only a few hundred 309 bits, on some small IoT chips. Second, the factory cost of 310 provisioning key material in each chip or device may be high, with 311 even millisecond delays adding to the cost of a chip. Third, 312 privacy-preserving signing schemes like ECDAA (Elliptic Curve Direct 313 Anonymous Attestation) are complex and not suitable for all use 314 cases. 316 Over time to faciliate interoperability, some signing schemes may be 317 defined in EAT profiles or other documents either in the IETF or 318 outside. 320 2. Terminology 322 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 323 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 324 "OPTIONAL" in this document are to be interpreted as described in BCP 325 14 [RFC2119] [RFC8174] when, and only when, they appear in all 326 capitals, as shown here. 328 This document reuses terminology from JWT [RFC7519], COSE [RFC8152], 329 and CWT [RFC8392]. 331 Claim Name. The human-readable name used to identify a claim. 333 Claim Key. The CBOR map key or JSON name used to identify a claim. 335 Claim Value. The CBOR map or JSON object value representing the 336 value of the claim. 338 CWT Claims Set. The CBOR map or JSON object that contains the claims 339 conveyed by the CWT or JWT. 341 Attestation Key Material (AKM). The key material used to sign the 342 EAT token. If it is done symmetrically with HMAC, then this is a 343 simple symmetric key. If it is done with ECC, such as an IEEE 344 DevID [IDevID], then this is the private part of the EC key pair. 345 If ECDAA is used, (e.g., as used by Enhanced Privacy ID, i.e. 346 EPID) then it is the key material needed for ECDAA. 348 3. The Claims 350 This section describes new claims defined for attestation. It also 351 mentions several claims defined by CWT and JWT that are particularly 352 important for EAT. 354 Note also: * Any claim defined for CWT or JWT may be used in an EAT 355 including those in the CWT [IANA.CWT.Claims] and JWT IANA 356 [IANA.JWT.Claims] claims registries. 358 o All claims are optional 360 o No claims are mandatory 362 o All claims that are not understood by implementations MUST be 363 ignored 365 CDDL along with text descriptions is used to define each claim 366 indepdent of encoding. Each claim is defined as a CDDL group (the 367 group is a general aggregation and type definition feature of CDDL). 368 In the encoding section Section 4, the CDDL groups turn into CBOR map 369 entries and JSON name/value pairs. 371 3.1. Token ID Claim (cti and jti) 373 CWT defines the "cti" claim. JWT defines the "jti" claim. These are 374 equivalent to each other in EAT and carry a unique token identifier 375 as they do in JWT and CWT. They may be used to defend against re use 376 of the token but are distinct from the nonce that is used by the 377 relying party to guarantee freshness and defend against replay. 379 3.2. Timestamp claim (iat) 381 The "iat" claim defined in CWT and JWT is used to indicate the date- 382 of-creation of the token. 384 3.3. Nonce Claim (nonce) 386 All EATs should have a nonce to prevent replay attacks. The nonce is 387 generated by the relying party, the end consumer of the token. It is 388 conveyed to the entity over whatever transport is in use before the 389 token is generated and then included in the token as the nonce claim. 391 This documents the nonce claim for registration in the IANA CWT 392 claims registry. This is equivalent to the JWT nonce claim that is 393 already registered. 395 The nonce must be at least 8 bytes (64 bits) as fewer are unlikely to 396 be secure. A maximum of 64 bytes is set to limit the memory a 397 constrained implementation uses. This size range is not set for the 398 already-registered JWT nonce, but it should follow this size 399 recommendation when used in an EAT. 401 Multiple nonces are allowed to accommodate multistage verification 402 and consumption. 404 3.3.1. nonce CDDL 406 nonce-type = [ + bstr .size (8..64) ] 408 nonce-claim = ( 409 nonce => nonce-type 410 ) 412 3.4. Universal Entity ID Claim (ueid) 414 UEID's identify individual manufactured entities / devices such as a 415 mobile phone, a water meter, a Bluetooth speaker or a networked 416 security camera. It may identify the entire device or a submodule or 417 subsystem. It does not identify types, models or classes of devices. 418 It is akin to a serial number, though it does not have to be 419 sequential. 421 UEID's must be universally and globally unique across manufacturers 422 and countries. UEIDs must also be unique across protocols and 423 systems, as tokens are intended to be embedded in many different 424 protocols and systems. No two products anywhere, even in completely 425 different industries made by two different manufacturers in two 426 different countries should have the same UEID (if they are not global 427 and universal in this way, then relying parties receiving them will 428 have to track other characteristics of the device to keep devices 429 distinct between manufacturers). 431 There are privacy considerations for UEID's. See Section 6.1. 433 The UEID should be permanent. It should never change for a given 434 device / entity. In addition, it should not be reprogrammable. 435 UEID's are variable length. All implementations MUST be able to 436 receive UEID's that are 33 bytes long (1 type byte and 256 bits). 437 The recommended maximum sent is also 33 bytes. 439 When the entity constructs the UEID, the first byte is a type and the 440 following bytes the ID for that type. Several types are allowed to 441 accommodate different industries and different manufacturing 442 processes and to give options to avoid paying fees for certain types 443 of manufacturer registrations. 445 Creation of new types requires a Standards Action [RFC8126]. 447 +------+------+-----------------------------------------------------+ 448 | Type | Type | Specification | 449 | Byte | Name | | 450 +------+------+-----------------------------------------------------+ 451 | 0x01 | RAND | This is a 128, 192 or 256 bit random number | 452 | | | generated once and stored in the device. This may | 453 | | | be constructed by concatenating enough identifiers | 454 | | | to make up an equivalent number of random bits and | 455 | | | then feeding the concatenation through a | 456 | | | cryptographic hash function. It may also be a | 457 | | | cryptographic quality random number generated once | 458 | | | at the beginning of the life of the device and | 459 | | | stored. It may not be smaller than 128 bits. | 460 | 0x02 | IEEE | This makes use of the IEEE company identification | 461 | | EUI | registry. An EUI is either an EUI-48, EUI-60 or | 462 | | | EUI-64 and made up of an OUI, OUI-36 or a CID, | 463 | | | different registered company identifiers, and some | 464 | | | unique per-device identifier. EUIs are often the | 465 | | | same as or similar to MAC addresses. This type | 466 | | | includes MAC-48, an obsolete name for EUI-48. (Note | 467 | | | that while devices with multiple network interfaces | 468 | | | may have multiple MAC addresses, there is only one | 469 | | | UEID for a device) [IEEE.802-2001], [OUI.Guide] | 470 | 0x03 | IMEI | This is a 14-digit identifier consisting of an | 471 | | | 8-digit Type Allocation Code and a 6-digit serial | 472 | | | number allocated by the manufacturer, which SHALL | 473 | | | be encoded as a binary integer over 48 bits. The | 474 | | | IMEI value encoded SHALL NOT include Luhn checksum | 475 | | | or SVN information. [ThreeGPP.IMEI] | 476 +------+------+-----------------------------------------------------+ 478 Table 1: UEID Composition Types 480 UEID's are not designed for direct use by humans (e.g., printing on 481 the case of a device), so no textual representation is defined. 483 The consumer (the relying party) of a UEID MUST treat a UEID as a 484 completely opaque string of bytes and not make any use of its 485 internal structure. For example, they should not use the OUI part of 486 a type 0x02 UEID to identify the manufacturer of the device. Instead 487 they should use the oemid claim that is defined elsewhere. The 488 reasons for this are: 490 o UEIDs types may vary freely from one manufacturer to the next. 492 o New types of UEIDs may be created. For example, a type 0x07 UEID 493 may be created based on some other manufacturer registration 494 scheme. 496 o Device manufacturers are allowed to change from one type of UEID 497 to another anytime they want. For example, they may find they can 498 optimize their manufacturing by switching from type 0x01 to type 499 0x02 or vice versa. The main requirement on the manufacturer is 500 that UEIDs be universally unique. 502 3.4.1. ueid CDDL 504 ueid-claim = ( 505 ueid => bstr .size (7..33) 506 ) 508 3.5. Origination Claim (origination) 510 This claim describes the parts of the device or entity that are 511 creating the EAT. Often it will be tied back to the device or chip 512 manufacturer. The following table gives some examples: 514 +-------------------+-----------------------------------------------+ 515 | Name | Description | 516 +-------------------+-----------------------------------------------+ 517 | Acme-TEE | The EATs are generated in the TEE authored | 518 | | and configured by "Acme" | 519 | Acme-TPM | The EATs are generated in a TPM manufactured | 520 | | by "Acme" | 521 | Acme-Linux-Kernel | The EATs are generated in a Linux kernel | 522 | | configured and shipped by "Acme" | 523 | Acme-TA | The EATs are generated in a Trusted | 524 | | Application (TA) authored by "Acme" | 525 +-------------------+-----------------------------------------------+ 527 TODO: consider a more structure approach where the name and the URI 528 and other are in separate fields. 530 TODO: This needs refinement. It is somewhat parallel to issuer claim 531 in CWT in that it describes the authority that created the token. 533 3.5.1. origination CDDL 535 origination-claim = ( 536 origination => string-or-uri 537 ) 539 3.6. OEM Identification by IEEE (oemid) 541 The IEEE operates a global registry for MAC addresses and company 542 IDs. This claim uses that database to identify OEMs. The contents 543 of the claim may be either an IEEE MA-L, MA-M, MA-S or an IEEE CID 545 [IEEE.RA]. An MA-L, formerly known as an OUI, is a 24-bit value used 546 as the first half of a MAC address. MA-M similarly is a 28-bit value 547 uses as the first part of a MAC address, and MA-S, formerly known as 548 OUI-36, a 36-bit value. Many companies already have purchased one of 549 these. A CID is also a 24-bit value from the same space as an MA-L, 550 but not for use as a MAC address. IEEE has published Guidelines for 551 Use of EUI, OUI, and CID [OUI.Guide] and provides a lookup services 552 [OUI.Lookup] 554 Companies that have more than one of these IDs or MAC address blocks 555 should pick one and prefer that for all their devices. 557 Commonly, these are expressed in Hexadecimal Representation 558 [IEEE.802-2001] also called the Canonical format. When this claim is 559 encoded the order of bytes in the bstr are the same as the order in 560 the Hexadecimal Representation. For example, an MA-L like "AC-DE-48" 561 would be encoded in 3 bytes with values 0xAC, 0xDE, 0x48. For JSON 562 encoded tokens, this is further base64url encoded. 564 3.6.1. oemid CDDL 566 oemid-claim = ( 567 oemid => bstr 568 ) 570 3.7. The Security Level Claim (security-level) 572 EATs have a claim that roughly characterizes the device / entities 573 ability to defend against attacks aimed at capturing the signing key, 574 forging claims and at forging EATs. This is done by roughly defining 575 four security levels as described below. This is similar to the 576 security levels defined in the Metadata Service defined by the Fast 577 Identity Online (FIDO) Alliance (TODO: reference). 579 These claims describe security environment and countermeasures 580 available on the end-entity / client device where the attestation key 581 reside and the claims originate. 583 1 - Unrestricted There is some expectation that implementor will 584 protect the attestation signing keys at this level. Otherwise the 585 EAT provides no meaningful security assurances. 587 2- Restricted Entities at this level should not be general-purpose 588 operating environments that host features such as app download 589 systems, web browsers and complex productivity applications. It 590 is akin to the Secure Restricted level (see below) without the 591 security orientation. Examples include a Wi-Fi subsystem, an IoT 592 camera, or sensor device. 594 3 - Secure Restricted Entities at this level must meet the criteria 595 defined by FIDO Allowed Restricted Operating Environments (TODO: 596 reference). Examples include TEE's and schemes using 597 virtualization-based security. Like the FIDO security goal, 598 security at this level is aimed at defending well against large- 599 scale network / remote attacks against the device. 601 4 - Hardware Entities at this level must include substantial defense 602 against physical or electrical attacks against the device itself. 603 It is assumed any potential attacker has captured the device and 604 can disassemble it. Example include TPMs and Secure Elements. 606 This claim is not intended as a replacement for a proper end-device 607 security certification schemes such as those based on FIPS (TODO: 608 reference) or those based on Common Criteria (TODO: reference). The 609 claim made here is solely a self-claim made by the Entity Originator. 611 3.7.1. security-level CDDL 613 security-level-type = &( 614 unrestricted: 1, 615 restricted: 2, 616 secure-restricted: 3, 617 hardware: 4 618 ) 620 security-level-claim = ( 621 security-level => security-level-type 622 ) 624 3.8. Secure Boot and Debug Enable State Claims (boot-state) 626 This claim is an array of five Boolean values indicating the boot and 627 debug state of the entity. 629 3.8.1. Secure Boot Enabled 631 This indicates whether secure boot is enabled either for an entire 632 device or an individual submodule. If it appears at the device 633 level, then this means that secure boot is enabled for all 634 submodules. Secure boot enablement allows a secure boot loader to 635 authenticate software running either in a device or a submodule prior 636 allowing execution. 638 3.8.2. Debug Disabled 640 This indicates whether debug capabilities are disabled for an entity 641 (i.e. value of 'true'). Debug disablement is considered a 642 prerequisite before an entity is considered operational. 644 3.8.3. Debug Disabled Since Boot 646 This claim indicates whether debug capabilities for the entity were 647 not disabled in any way since boot (i.e. value of 'true'). 649 3.8.4. Debug Permanent Disable 651 This claim indicates whether debug capabilities for the entity are 652 permanently disabled (i.e. value of 'true'). This value can be set 653 to 'true' also if only the manufacturer is allowed to enabled debug, 654 but the end user is not. 656 3.8.5. Debug Full Permanent Disable 658 This claim indicates whether debug capabilities for the entity are 659 permanently disabled (i.e. value of 'true'). This value can only be 660 set to 'true' if no party can enable debug capabilities for the 661 entity. Often this is implemented by blowing a fuse on a chip as 662 fuses cannot be restored once blown. 664 3.8.6. boot-state CDDL 666 boot-state-type = [ 667 secure-boot-enabled => bool, 668 debug-disabled => bool, 669 debug-disabled-since-boot => bool, 670 debug-permanent-disable => bool, 671 debug-full-permanent-disable => bool 672 ] 674 boot-state-claim = ( 675 boot-state => boot-state-type 676 ) 678 3.9. The Location Claim (location) 680 The location claim is a CBOR-formatted object that describes the 681 location of the device entity from which the attestation originates. 682 It is comprised of a map of additional sub claims that represent the 683 actual location coordinates (latitude, longitude and altitude). The 684 location coordinate claims are consistent with the WGS84 coordinate 685 system [WGS84]. In addition, a sub claim providing the estimated 686 accuracy of the location measurement is defined. 688 3.9.1. location CDDL 690 location-type = { 691 latitude => number, 692 longitude => number, 693 ? altitude => number, 694 ? accuracy => number, 695 ? altitude-accuracy => number, 696 ? heading => number, 697 ? speed => number 698 } 700 location-claim = ( 701 location => location-type 702 ) 704 3.10. The Age Claim (age) 706 The "age" claim contains a value that represents the number of 707 seconds that have elapsed since the token was created, measurement 708 was made, or location was obtained. Typical attestable values are 709 sent as soon as they are obtained. However, in the case that such a 710 value is buffered and sent at a later time and a sufficiently 711 accurate time reference is unavailable for creation of a timestamp, 712 then the age claim is provided. 714 3.10.1. age CDDL 716 age-claim = ( 717 age => uint 718 ) 720 3.11. The Uptime Claim (uptime) 722 The "uptime" claim contains a value that represents the number of 723 seconds that have elapsed since the entity or submod was last booted. 725 3.11.1. uptime CDDL 727 uptime-claim = ( 728 uptime => uint 729 ) 731 3.12. The Submods Part of a Token (submods) 733 Some devices are complex, having many subsystems or submodules. A 734 mobile phone is a good example. It may have several connectivity 735 submodules for communications (e.g., Wi-Fi and cellular). It may 736 have subsystems for low-power audio and video playback. It may have 737 one or more security-oriented subsystems like a TEE or a Secure 738 Element. 740 The claims for each these can be grouped together in a submodule. 742 The submods part of a token a single map/object with many entries, 743 one per submodule. There is only one submods map in a token. It is 744 identified by its specific label. It is a peer to other claims, but 745 it is not called a claim because it is a container for a claim set 746 rather than an individual claim. This submods part of a token allows 747 what might be called recursion. It allows claim sets inside of claim 748 sets inside of claims sets... 750 3.12.1. Two Types of Submodules 752 Each entry in the submod map one of two types: 754 o A non-token submodule that is a map or object directly containing 755 claims for the submodule. 757 o A nested EAT that is a fully-formed, independently signed EAT 758 token 760 3.12.1.1. Non-token Submodules 762 Essentially this type of submodule, is just a sub-map or sub-object 763 containing claims. It is recognized from the other type by being a 764 data item of type map in CBOR or by being an object in JSON. 766 The contents are claims about the submodule of types defined in this 767 document or anywhere else claims types are defined. 769 3.12.1.2. Nested EATs 771 This type of submodule is a fully formed EAT as described here. In 772 this case the submodule has key material distinct from the containing 773 EAT token that allows it to sign on its own. 775 When an EAT is nested in another EAT as a submodule the nested EAT 776 MUST use the CBOR CWT tag. This clearly distinguishes it from the 777 non-token submodules. 779 3.12.2. No Inheritance 781 The subordinate modules do not inherit anything from the containing 782 token. The subordinate modules must explicitly include all of their 783 claims. This is the case even for claims like the nonce and age. 785 This rule is in place for simplicity. It avoids complex inheritance 786 rules that might vary from one type of claim to another. (TODO: fix 787 the boot claim which does have inheritance as currently described). 789 3.12.3. Security Levels 791 The security level of the non-token subordinate modules should always 792 be less than or equal to that of the containing modules in the case 793 of non-token submodules. It makes no sense for a module of lesser 794 security to be signing claims of a module of higher security. An 795 example of this is a TEE signing claims made by the non-TEE parts 796 (e.g. the high-level OS) of the device. 798 The opposite may be true for the nested tokens. They usually have 799 their own more secure key material. An example of this is an 800 embedded secure element. 802 3.12.4. Submodule Names 804 The label or name for each submodule in the submods map is a text 805 string naming the submodule. No submodules may have the same name. 807 3.12.5. submods CDDL 809 submods-type = { + submodule } 811 submodule = ( 812 submod_name => eat-claims / eat-token 813 ) 815 submod_name = tstr / int 817 submods-part = ( 818 submods => submod-type 819 ) 821 4. Encoding 823 This makes use of the types defined in CDDL Appendix D, Standard 824 Prelude. 826 4.1. Common CDDL Types 828 string-or-uri = uri / tstr; See JSON section below for JSON encoding of string-or-uri 830 4.2. CDDL for CWT-defined Claims 832 This section provides CDDL for the claims defined in CWT. It is non- 833 normative as [RFC8392] is the authoritative definition of these 834 claims. 836 rfc8392-claim //= ( issuer => text ) 837 rfc8392-claim //= ( subject => text ) 838 rfc8392-claim //= ( audience => text ) 839 rfc8392-claim //= ( expiration => time ) 840 rfc8392-claim //= ( not-before => time ) 841 rfc8392-claim //= ( issued-at => time ) 842 rfc8392-claim //= ( cwt-id => bytes ) 844 issuer = 1 845 subject = 2 846 audience = 3 847 expiration = 4 848 not-before = 5 849 issued-at = 6 850 cwt-id = 7 852 cwt-claim = rfc8392-claim 854 4.3. JSON 856 4.3.1. JSON Labels 857 ueid = "ueid" 858 origination = "origination" 859 oemid = "oemid" 860 security-level = "security-level" 861 boot-state = "boot-state" 862 location = "location" 863 age = "age" 864 uptime = "uptime" 865 nested-eat = "nested-eat" 866 submods = "submods" 868 latitude = "lat" 869 longitude = "long"" 870 altitude = "alt" 871 accuracy = "accry" 872 altitude-accuracy = "alt-accry" 873 heading = "heading" 874 speed = "speed" 876 4.3.2. JSON Interoperability 878 JSON should be encoded per RFC 8610 Appendix E. In addition, the 879 following CDDL types are encoded in JSON as follows: 881 o bstr - must be base64url encoded 883 o time - must be encoded as NumericDate as described section 2 of 884 [RFC7519]. 886 o string-or-uri - must be encoded as StringOrURI as described 887 section 2 of [RFC7519]. 889 4.4. CBOR 891 4.4.1. CBOR Labels 892 ueid = To_be_assigned 893 origination = To_be_assigned 894 oemid = To_be_assigned 895 security-level = To_be_assigned 896 boot-state = To_be_assigned 897 location = To_be_assigned 898 age = To_be_assigned 899 uptime = To_be_assigned 900 submods = To_be_assigned 901 nonce = To_be_assigned 903 latitude = 1 904 longitude = 2 905 altitude = 3 906 accuracy = 4 907 altitude-accuracy = 5 908 heading = 6 909 speed = 7 911 4.4.2. CBOR Interoperability 913 Variations in the CBOR serializations supported in CBOR encoding and 914 decoding are allowed and suggests that CBOR-based protocols specify 915 how this variation is handled. This section specifies what formats 916 MUST be supported in order to achieve interoperability. 918 The assumption is that the entity is likely to be a constrained 919 device and relying party is likely to be a very capable server. The 920 approach taken is that the entity generating the token can use 921 whatever encoding it wants, specifically encodings that are easier to 922 implement such as indefinite lengths. The relying party receiving 923 the token must support decoding all encodings. 925 These rules cover all types used in the claims in this document. 926 They also are recommendations for additional claims. 928 Canonical CBOR encoding, Preferred Serialization and 929 Deterministically Encoded CBOR are explicitly NOT required as they 930 would place an unnecessary burden on the entity implementation, 931 particularly if the entity implementation is implemented in hardware. 933 o Integer Encoding (major type 0, 1) - The entity may use any 934 integer encoding allowed by CBOR. The server MUST accept all 935 integer encodings allowed by CBOR. 937 o String Encoding (major type 2 and 3) - The entity can use any 938 string encoding allowed by CBOR including indefinite lengths. It 939 may also encode the lengths of strings in any way allowed by CBOR. 940 The server must accept all string encodings. 942 o Major type 2, bstr, SHOULD be have tag 21 to indicate conversion 943 to base64url in case that conversion is performed. 945 o Map and Array Encoding (major type 4 and 5) - The entity can use 946 any array or map encoding allowed by CBOR including indefinite 947 lengths. Sorting of map keys is not required. Duplicate map keys 948 are not allowed. The server must accept all array and map 949 encodings. The server may reject maps with duplicate map keys. 951 o Date and Time - The entity should send dates as tag 1 encoded as 952 64-bit or 32-bit integers. The entity may not send floating-point 953 dates. The server must support tag 1 epoch-based dates encoded as 954 64-bit or 32-bit integers. The entity may send tag 0 dates, 955 however tag 1 is preferred. The server must support tag 0 UTC 956 dates. 958 o URIs - URIs should be encoded as text strings and marked with tag 959 32. 961 o Floating Point - The entity may use any floating-point encoding. 962 The relying party must support decoding of all types of floating- 963 point. 965 o Other types - Use of Other types like bignums, regular expressions 966 and such, SHOULD NOT be used. The server MAY support them but is 967 not required to so interoperability is not guaranteed. 969 4.5. Collected CDDL 971 A generic-claim is any CBOR map entry or JSON name/value pair. 973 eat-claims = { ; the top-level payload that is signed using COSE or JOSE 974 * claim 975 } 977 claim = ( 978 ueid-claim // 979 origination-claim // 980 oemid-claim // 981 security-level-claim // 982 boot-state-claim // 983 location-claim // 984 age-claim // 985 uptime-claim // 986 submods-part // 987 cwt-claim // 988 generic-claim-type // 989 ) 991 eat-token ; This is a set of eat-claims signed using COSE 993 TODO: copy the rest of the CDDL here (wait until the CDDL is more 994 settled so as to avoid copying multiple times) 996 5. IANA Considerations 998 5.1. Reuse of CBOR Web Token (CWT) Claims Registry 1000 Claims defined for EAT are compatible with those of CWT so the CWT 1001 Claims Registry is re used. No new IANA registry is created. All 1002 EAT claims should be registered in the CWT and JWT Claims Registries. 1004 5.1.1. Claims Registered by This Document 1006 o Claim Name: UEID 1008 o Claim Description: The Universal Entity ID 1010 o JWT Claim Name: N/A 1012 o Claim Key: 8 1014 o Claim Value Type(s): byte string 1016 o Change Controller: IESG 1018 o Specification Document(s): *this document* 1020 TODO: add the rest of the claims in here 1022 6. Privacy Considerations 1024 Certain EAT claims can be used to track the owner of an entity and 1025 therefore, implementations should consider providing privacy- 1026 preserving options dependent on the intended usage of the EAT. 1027 Examples would include suppression of location claims for EAT's 1028 provided to unauthenticated consumers. 1030 6.1. UEID Privacy Considerations 1032 A UEID is usually not privacy-preserving. Any set of relying parties 1033 that receives tokens that happen to be from a single device will be 1034 able to know the tokens are all from the same device and be able to 1035 track the device. Thus, in many usage situations ueid violates 1036 governmental privacy regulation. In other usage situations UEID will 1037 not be allowed for certain products like browsers that give privacy 1038 for the end user. It will often be the case that tokens will not 1039 have a UEID for these reasons. 1041 There are several strategies that can be used to still be able to put 1042 UEID's in tokens: 1044 o The device obtains explicit permission from the user of the device 1045 to use the UEID. This may be through a prompt. It may also be 1046 through a license agreement. For example, agreements for some 1047 online banking and brokerage services might already cover use of a 1048 UEID. 1050 o The UEID is used only in a particular context or particular use 1051 case. It is used only by one relying party. 1053 o The device authenticates the relying party and generates a derived 1054 UEID just for that particular relying party. For example, the 1055 relying party could prove their identity cryptographically to the 1056 device, then the device generates a UEID just for that relying 1057 party by hashing a proofed relying party ID with the main device 1058 UEID. 1060 Note that some of these privacy preservation strategies result in 1061 multiple UEIDs per device. Each UEID is used in a different context, 1062 use case or system on the device. However, from the view of the 1063 relying party, there is just one UEID and it is still globally 1064 universal across manufacturers. 1066 7. Security Considerations 1068 The security considerations provided in Section 8 of [RFC8392] and 1069 Section 11 of [RFC7519] apply to EAT in its CWT and JWT form, 1070 respectively. In addition, implementors should consider the 1071 following. 1073 7.1. Key Provisioning 1075 Private key material can be used to sign and/or encrypt the EAT, or 1076 can be used to derive the keys used for signing and/or encryption. 1077 In some instances, the manufacturer of the entity may create the key 1078 material separately and provision the key material in the entity 1079 itself. The manfuacturer of any entity that is capable of producing 1080 an EAT should take care to ensure that any private key material be 1081 suitably protected prior to provisioning the key material in the 1082 entity itself. This can require creation of key material in an 1083 enclave (see [RFC4949] for definition of "enclave"), secure 1084 transmission of the key material from the enclave to the entity using 1085 an appropriate protocol, and persistence of the private key material 1086 in some form of secure storage to which (preferably) only the entity 1087 has access. 1089 7.1.1. Transmission of Key Material 1091 Regarding transmission of key material from the enclave to the 1092 entity, the key material may pass through one or more intermediaries. 1093 Therefore some form of protection ("key wrapping") may be necessary. 1094 The transmission itself may be performed electronically, but can also 1095 be done by human courier. In the latter case, there should be 1096 minimal to no exposure of the key material to the human (e.g. 1097 encrypted portable memory). Moreover, the human should transport the 1098 key material directly from the secure enclave where it was created to 1099 a destination secure enclave where it can be provisioned. 1101 7.2. Transport Security 1103 As stated in Section 8 of [RFC8392], "The security of the CWT relies 1104 upon on the protections offered by COSE". Similar considerations 1105 apply to EAT when sent as a CWT. However, EAT introduces the concept 1106 of a nonce to protect against replay. Since an EAT may be created by 1107 an entity that may not support the same type of transport security as 1108 the consumer of the EAT, intermediaries may be required to bridge 1109 communications between the entity and consumer. As a result, it is 1110 RECOMMENDED that both the consumer create a nonce, and the entity 1111 leverage the nonce along with COSE mechanisms for encryption and/or 1112 signing to create the EAT. 1114 Similar considerations apply to the use of EAT as a JWT. Although 1115 the security of a JWT leverages the JSON Web Encryption (JWE) and 1116 JSON Web Signature (JWS) specifications, it is still recommended to 1117 make use of the EAT nonce. 1119 7.3. Multiple EAT Consumers 1121 In many cases, more than one EAT consumer may be required to fully 1122 verify the entity attestation. Examples include individual consumers 1123 for nested EATs, or consumers for individual claims with an EAT. 1124 When multiple consumers are required for verification of an EAT, it 1125 is important to minimize information exposure to each consumer. In 1126 addition, the communication between multiple consumers should be 1127 secure. 1129 For instance, consider the example of an encrypted and signed EAT 1130 with multiple claims. A consumer may receive the EAT (denoted as the 1131 "receiving consumer"), decrypt its payload, verify its signature, but 1132 then pass specific subsets of claims to other consumers for 1133 evaluation ("downstream consumers"). Since any COSE encryption will 1134 be removed by the receiving consumer, the communication of claim 1135 subsets to any downstream consumer should leverage a secure protocol 1136 (e.g.one that uses transport-layer security, i.e. TLS), 1138 However, assume the EAT of the previous example is hierarchical and 1139 each claim subset for a downstream consumer is created in the form of 1140 a nested EAT. Then transport security between the receiving and 1141 downstream consumers is not strictly required. Nevertheless, 1142 downstream consumers of a nested EAT should provide a nonce unique to 1143 the EAT they are consuming. 1145 8. References 1147 8.1. Normative References 1149 [IANA.CWT.Claims] 1150 IANA, "CBOR Web Token (CWT) Claims", 1151 . 1153 [IANA.JWT.Claims] 1154 IANA, "JSON Web Token (JWT) Claims", 1155 . 1157 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1158 Requirement Levels", BCP 14, RFC 2119, 1159 DOI 10.17487/RFC2119, March 1997, 1160 . 1162 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 1163 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 1164 October 2013, . 1166 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 1167 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 1168 . 1170 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1171 Writing an IANA Considerations Section in RFCs", BCP 26, 1172 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1173 . 1175 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 1176 RFC 8152, DOI 10.17487/RFC8152, July 2017, 1177 . 1179 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1180 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1181 May 2017, . 1183 [RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, 1184 "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, 1185 May 2018, . 1187 [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data 1188 Definition Language (CDDL): A Notational Convention to 1189 Express Concise Binary Object Representation (CBOR) and 1190 JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, 1191 June 2019, . 1193 [ThreeGPP.IMEI] 1194 3GPP, "3rd Generation Partnership Project; Technical 1195 Specification Group Core Network and Terminals; Numbering, 1196 addressing and identification", 2019, 1197 . 1200 [TIME_T] The Open Group Base Specifications, "Vol. 1: Base 1201 Definitions, Issue 7", Section 4.15 'Seconds Since the 1202 Epoch', IEEE Std 1003.1, 2013 Edition, 2013, 1203 . 1206 [WGS84] National Imagery and Mapping Agency, "National Imagery and 1207 Mapping Agency Technical Report 8350.2, Third Edition", 1208 2000, . 1211 8.2. Informative References 1213 [ASN.1] International Telecommunication Union, "Information 1214 Technology -- ASN.1 encoding rules: Specification of Basic 1215 Encoding Rules (BER), Canonical Encoding Rules (CER) and 1216 Distinguished Encoding Rules (DER)", ITU-T Recommendation 1217 X.690, 1994. 1219 [BirthdayAttack] 1220 "Birthday attack", 1221 . 1223 [ECMAScript] 1224 "Ecma International, "ECMAScript Language Specification, 1225 5.1 Edition", ECMA Standard 262", June 2011, 1226 . 1229 [IDevID] "IEEE Standard, "IEEE 802.1AR Secure Device Identifier"", 1230 December 2009, . 1233 [IEEE.802-2001] 1234 "IEEE Standard For Local And Metropolitan Area Networks 1235 Overview And Architecture", 2007, 1236 . 1239 [IEEE.RA] "IEEE Registration Authority", 1240 . 1243 [OUI.Guide] 1244 "Guidelines for Use of Extended Unique Identifier (EUI), 1245 Organizationally Unique Identifier (OUI), and Company ID 1246 (CID)", August 2017, 1247 . 1250 [OUI.Lookup] 1251 "IEEE Registration Authority Assignments", 1252 . 1255 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 1256 Unique IDentifier (UUID) URN Namespace", RFC 4122, 1257 DOI 10.17487/RFC4122, July 2005, 1258 . 1260 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 1261 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, 1262 . 1264 [Webauthn] 1265 Worldwide Web Consortium, "Web Authentication: A Web API 1266 for accessing scoped credentials", 2016. 1268 Appendix A. Examples 1270 A.1. Very Simple EAT 1272 This is shown in CBOR diagnostic form. Only the payload signed by 1273 COSE is shown. 1275 { 1276 / nonce / 9:h'948f8860d13a463e8e', 1277 / UEID / 10:h'0198f50a4ff6c05861c8860d13a638ea4fe2f', 1278 / boot-state / 12:{true, true, true, true, false} 1279 / time stamp (iat) / 6:1526542894, 1280 } 1282 A.2. Example with Submodules, Nesting and Security Levels 1284 { 1285 / nonce / 9:h'948f8860d13a463e8e', 1286 / UEID / 10:h'0198f50a4ff6c05861c8860d13a638ea4fe2f', 1287 / boot-state / 12:{true, true, true, true, false} 1288 / time stamp (iat) / 6:1526542894, 1289 / seclevel / 11:3, / secure restricted OS / 1291 / submods / 17: 1292 { 1293 / first submod, an Android Application / "Android App Foo" : { 1294 / seclevel / 11:1, / unrestricted / 1295 / app data / -70000:'text string' 1296 }, 1297 / 2nd submod, A nested EAT from a secure element / "Secure Element Eat" : 1298 / eat / 61( 18( 1299 / an embedded EAT, bytes of which are not shown / 1300 )) 1301 / 3rd submod, information about Linux Android / "Linux Android": { 1302 / seclevel / 11:1, / unrestricted / 1303 / custom - release / -80000:'8.0.0', 1304 / custom - version / -80001:'4.9.51+' 1305 } 1306 } 1307 } 1309 Appendix B. UEID Design Rationale 1311 B.1. Collision Probability 1313 This calculation is to determine the probability of a collision of 1314 UEIDs given the total possible entity population and the number of 1315 entities in a particular entity management database. 1317 Three different sized databases are considered. The number of 1318 devices per person roughly models non-personal devices such as 1319 traffic lights, devices in stores they shop in, facilities they work 1320 in and so on, even considering individual light bulbs. A device may 1321 have individually attested subsystems, for example parts of a car or 1322 a mobile phone. It is assumed that the largest database will have at 1323 most 10% of the world's population of devices. Note that databases 1324 that handle more than a trillion records exist today. 1326 The trillion-record database size models an easy-to-imagine reality 1327 over the next decades. The quadrillion-record database is roughly at 1328 the limit of what is imaginable and should probably be accommodated. 1329 The 100 quadrillion datadbase is highly speculative perhaps involving 1330 nanorobots for every person, livestock animal and domesticated bird. 1331 It is included to round out the analysis. 1333 Note that the items counted here certainly do not have IP address and 1334 are not individually connected to the network. They may be connected 1335 to internal buses, via serial links, Bluetooth and so on. This is 1336 not the same problem as sizing IP addresses. 1338 +---------+------------+--------------+------------+----------------+ 1339 | People | Devices / | Subsystems / | Database | Database Size | 1340 | | Person | Device | Portion | | 1341 +---------+------------+--------------+------------+----------------+ 1342 | 10 | 100 | 10 | 10% | trillion | 1343 | billion | | | | (10^12) | 1344 | 10 | 100,000 | 10 | 10% | quadrillion | 1345 | billion | | | | (10^15) | 1346 | 100 | 1,000,000 | 10 | 10% | 100 | 1347 | billion | | | | quadrillion | 1348 | | | | | (10^17) | 1349 +---------+------------+--------------+------------+----------------+ 1351 This is conceptually similar to the Birthday Problem where m is the 1352 number of possible birthdays, always 365, and k is the number of 1353 people. It is also conceptually similar to the Birthday Attack where 1354 collisions of the output of hash functions are considered. 1356 The proper formula for the collision calculation is 1358 p = 1 - e^{-k^2/(2n)} 1360 p Collision Probability 1361 n Total possible population 1362 k Actual population 1364 However, for the very large values involved here, this formula 1365 requires floating point precision higher than commonly available in 1366 calculators and SW so this simple approximation is used. See 1367 [BirthdayAttack]. 1369 p = k^2 / 2n 1371 For this calculation: 1373 p Collision Probability 1374 n Total population based on number of bits in UEID 1375 k Population in a database 1377 +----------------------+--------------+--------------+--------------+ 1378 | Database Size | 128-bit UEID | 192-bit UEID | 256-bit UEID | 1379 +----------------------+--------------+--------------+--------------+ 1380 | trillion (10^12) | 2 * 10^-15 | 8 * 10^-35 | 5 * 10^-55 | 1381 | quadrillion (10^15) | 2 * 10^-09 | 8 * 10^-29 | 5 * 10^-49 | 1382 | 100 quadrillion | 2 * 10^-05 | 8 * 10^-25 | 5 * 10^-45 | 1383 | (10^17) | | | | 1384 +----------------------+--------------+--------------+--------------+ 1386 Next, to calculate the probability of a collision occurring in one 1387 year's operation of a database, it is assumed that the database size 1388 is in a steady state and that 10% of the database changes per year. 1389 For example, a trillion record database would have 100 billion states 1390 per year. Each of those states has the above calculated probability 1391 of a collision. 1393 This assumption is a worst-case since it assumes that each state of 1394 the database is completely independent from the previous state. In 1395 reality this is unlikely as state changes will be the addition or 1396 deletion of a few records. 1398 The following tables gives the time interval until there is a 1399 probability of a collision based on there being one tenth the number 1400 of states per year as the number of records in the database. 1402 t = 1 / ((k / 10) * p) 1404 t Time until a collision 1405 p Collision probability for UEID size 1406 k Database size 1408 +---------------------+---------------+--------------+--------------+ 1409 | Database Size | 128-bit UEID | 192-bit UEID | 256-bit UEID | 1410 +---------------------+---------------+--------------+--------------+ 1411 | trillion (10^12) | 60,000 years | 10^24 years | 10^44 years | 1412 | quadrillion (10^15) | 8 seconds | 10^14 years | 10^34 years | 1413 | 100 quadrillion | 8 | 10^11 years | 10^31 years | 1414 | (10^17) | microseconds | | | 1415 +---------------------+---------------+--------------+--------------+ 1417 Clearly, 128 bits is enough for the near future thus the requirement 1418 that UEIDs be a minimum of 128 bits. 1420 There is no requirement for 256 bits today as quadrillion-record 1421 databases are not expected in the near future and because this time- 1422 to-collision calculation is a very worst case. A future update of 1423 the standard may increase the requirement to 256 bits, so there is a 1424 requirement that implementations be able to receive 256-bit UEIDs. 1426 B.2. No Use of UUID 1428 A UEID is not a UUID [RFC4122] by conscious choice for the following 1429 reasons. 1431 UUIDs are limited to 128 bits which may not be enough for some future 1432 use cases. 1434 Today, cryptographic-quality random numbers are available from common 1435 CPUs and hardware. This hardware was introduced between 2010 and 1436 2015. Operating systems and cryptographic libraries give access to 1437 this hardware. Consequently, there is little need for 1438 implementations to construct such random values from multiple sources 1439 on their own. 1441 Version 4 UUIDs do allow for use of such cryptographic-quality random 1442 numbers, but do so by mapping into the overall UUID structure of time 1443 and clock values. This structure is of no value here yet adds 1444 complexity. It also slightly reduces the number of actual bits with 1445 entropy. 1447 UUIDs seem to have been designed for scenarios where the implementor 1448 does not have full control over the environment and uniqueness has to 1449 be constructed from identifiers at hand. UEID takes the view that 1450 hardware, software and/or manufacturing process directly implement 1451 UEID in a simple and direct way. It takes the view that 1452 cryptographic quality random number generators are readily available 1453 as they are implemented in commonly used CPU hardware. 1455 Appendix C. Changes from Previous Drafts 1457 The following is a list of known changes from the previous drafts. 1458 This list is non-authoritative. It is meant to help reviewers see 1459 the significant differences. 1461 C.1. From draft-rats-eat-01 1463 o Added UEID design rationale appendix 1465 C.2. From draft-mandyam-rats-eat-00 1467 This is a fairly large change in the orientation of the document, but 1468 not new claims have been added. 1470 o Separate information and data model using CDDL. 1472 o Say an EAT is a CWT or JWT 1474 o Use a map to structure the boot_state and location claims 1476 C.3. From draft-ietf-rats-eat-01 1478 o Clarifications and corrections for OEMID claim 1480 o Minor spelling and other fixes 1482 o Add the nonce claim, clarify jti claim 1484 C.4. From draft-ietf-rats-eat-02 1486 o Roll all EUIs back into one UEID type 1488 o UEIDs can be one of three lengths, 128, 192 and 256. 1490 o Added appendix justifying UEID design and size. 1492 o Submods part now includes nested eat tokens so they can be named 1493 and there can be more tha one of them 1495 o Lots of fixes to the CDDL 1497 o Added security considerations 1499 Authors' Addresses 1501 Giridhar Mandyam 1502 Qualcomm Technologies Inc. 1503 5775 Morehouse Drive 1504 San Diego, California 1505 USA 1507 Phone: +1 858 651 7200 1508 EMail: mandyam@qti.qualcomm.com 1510 Laurence Lundblade 1511 Security Theory LLC 1513 EMail: lgl@island-resort.com 1515 Miguel Ballesteros 1516 Qualcomm Technologies Inc. 1517 5775 Morehouse Drive 1518 San Diego, California 1519 USA 1521 Phone: +1 858 651 4299 1522 EMail: mballest@qti.qualcomm.com 1524 Jeremy O'Donoghue 1525 Qualcomm Technologies Inc. 1526 279 Farnborough Road 1527 Farnborough GU14 7LS 1528 United Kingdom 1530 Phone: +44 1252 363189 1531 EMail: jodonogh@qti.qualcomm.com