idnits 2.17.1 draft-ietf-rats-eat-02.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 (January 09, 2020) is 1568 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'Webauthn' is defined on line 1147, 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: July 12, 2020 Security Theory LLC 6 M. Ballesteros 7 J. O'Donoghue 8 Qualcomm Technologies Inc. 9 January 09, 2020 11 The Entity Attestation Token (EAT) 12 draft-ietf-rats-eat-02 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 July 12, 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 . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . 7 70 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 71 3. The Claims Information Model . . . . . . . . . . . . . . . . 8 72 3.1. Token ID Claim (cti and jti) . . . . . . . . . . . . . . 8 73 3.2. Timestamp claim (iat) . . . . . . . . . . . . . . . . . . 8 74 3.3. Nonce Claim (nonce) . . . . . . . . . . . . . . . . . . . 8 75 3.3.1. CDDL . . . . . . . . . . . . . . . . . . . . . . . . 9 76 3.4. Universal Entity ID Claim (ueid) . . . . . . . . . . . . 9 77 3.4.1. CDDL . . . . . . . . . . . . . . . . . . . . . . . . 11 78 3.5. Origination Claim (origination) . . . . . . . . . . . . . 11 79 3.5.1. CDDL . . . . . . . . . . . . . . . . . . . . . . . . 12 80 3.6. OEM Identification by IEEE (oemid) . . . . . . . . . . . 12 81 3.6.1. CDDL . . . . . . . . . . . . . . . . . . . . . . . . 12 82 3.7. The Security Level Claim (security_level) . . . . . . . . 12 83 3.7.1. CDDL . . . . . . . . . . . . . . . . . . . . . . . . 13 84 3.8. Secure Boot and Debug Enable State Claims (boot_state) . 13 85 3.8.1. Secure Boot Enabled . . . . . . . . . . . . . . . . . 14 86 3.8.2. Debug Disabled . . . . . . . . . . . . . . . . . . . 14 87 3.8.3. Debug Disabled Since Boot . . . . . . . . . . . . . . 14 88 3.8.4. Debug Permanent Disable . . . . . . . . . . . . . . . 14 89 3.8.5. Debug Full Permanent Disable . . . . . . . . . . . . 14 90 3.8.6. CDDL . . . . . . . . . . . . . . . . . . . . . . . . 14 91 3.9. The Location Claim (location) . . . . . . . . . . . . . . 15 92 3.9.1. CDDL . . . . . . . . . . . . . . . . . . . . . . . . 15 93 3.10. The Age Claim (age) . . . . . . . . . . . . . . . . . . . 15 94 3.11. The Uptime Claim (uptime) . . . . . . . . . . . . . . . . 15 95 3.11.1. CDDL . . . . . . . . . . . . . . . . . . . . . . . . 15 96 3.12. Nested EATs, the EAT Claim (nested_eat) . . . . . . . . . 16 97 3.12.1. CDDL . . . . . . . . . . . . . . . . . . . . . . . . 16 98 3.13. The Submods Claim (submods) . . . . . . . . . . . . . . . 16 99 3.13.1. The submod_name Claim . . . . . . . . . . . . . . . 16 100 3.13.2. CDDL . . . . . . . . . . . . . . . . . . . . . . . . 17 101 4. Data Model . . . . . . . . . . . . . . . . . . . . . . . . . 17 102 4.1. Common CDDL Types . . . . . . . . . . . . . . . . . . . . 17 103 4.2. CDDL for CWT-defined Claims . . . . . . . . . . . . . . . 17 104 4.3. JSON . . . . . . . . . . . . . . . . . . . . . . . . . . 18 105 4.3.1. JSON Labels . . . . . . . . . . . . . . . . . . . . . 18 106 4.3.2. JSON Interoperability . . . . . . . . . . . . . . . . 19 107 4.4. CBOR . . . . . . . . . . . . . . . . . . . . . . . . . . 19 108 4.4.1. Labels . . . . . . . . . . . . . . . . . . . . . . . 19 109 4.4.2. CBOR Interoperability . . . . . . . . . . . . . . . . 20 110 4.5. Collected CDDL . . . . . . . . . . . . . . . . . . . . . 21 111 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 112 5.1. Reuse of CBOR Web Token (CWT) Claims Registry . . . . . . 22 113 5.1.1. Claims Registered by This Document . . . . . . . . . 22 114 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 23 115 6.1. UEID Privacy Considerations . . . . . . . . . . . . . . . 23 116 7. Security Considerations . . . . . . . . . . . . . . . . . . . 24 117 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 118 8.1. Normative References . . . . . . . . . . . . . . . . . . 24 119 8.2. Informative References . . . . . . . . . . . . . . . . . 25 120 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 27 121 A.1. Very Simple EAT . . . . . . . . . . . . . . . . . . . . . 27 122 A.2. Example with Submodules, Nesting and Security Levels . . 27 123 Appendix B. Changes from Previous Drafts . . . . . . . . . . . . 28 124 B.1. From draft-mandyam-rats-eat-00 . . . . . . . . . . . . . 28 125 B.2. From draft-ietf-rats-eat-01 . . . . . . . . . . . . . . . 28 126 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 128 1. Introduction 130 Remote device attestation is a fundamental service that allows a 131 remote device such as a mobile phone, an Internet-of-Things (IoT) 132 device, or other endpoint to prove itself to a relying party, a 133 server or a service. This allows the relying party to know some 134 characteristics about the device and decide whether it trusts the 135 device. 137 Remote attestation is a fundamental service that can underlie other 138 protocols and services that need to know about the trustworthiness of 139 the device before proceeding. One good example is biometric 140 authentication where the biometric matching is done on the device. 141 The relying party needs to know that the device is one that is known 142 to do biometric matching correctly. Another example is content 143 protection where the relying party wants to know the device will 144 protect the data. This generalizes on to corporate enterprises that 145 might want to know that a device is trustworthy before allowing 146 corporate data to be accessed by it. 148 The notion of attestation here is large and may include, but is not 149 limited to the following: 151 o Proof of the make and model of the device hardware (HW) 153 o Proof of the make and model of the device processor, particularly 154 for security-oriented chips 156 o Measurement of the software (SW) running on the device 158 o Configuration and state of the device 160 o Environmental characteristics of the device such as its GPS 161 location 163 1.1. CDDL, CWT and JWT 165 An EAT token is either a CWT as defined in [RFC8392] or a JWT as 166 defined in [RFC7519]. This specification defines additional claims 167 for entity attestation. 169 This specification uses CDDL, [RFC8610], as the primary formalism to 170 define each claim. The implementor then interprets the CDDL to come 171 to either the CBOR [RFC7049] or JSON [ECMAScript] representation. In 172 the case of JSON, Appendix E of [RFC8610] is followed. Additional 173 rules are given in Section 4.3.2 of this document where Appendix E is 174 insufficient. (Note that this is not to define a general means to 175 translate between CBOR and JSON, but only to define enough such that 176 the claims defined in this document can be rendered unambiguously in 177 JSON). 179 1.2. Entity Overview 181 An "entity" can be any device or device subassembly ("submodule") 182 that can generate its own attestation in the form of an EAT. The 183 attestation should be cryptographically verifiable by the EAT 184 consumer. An EAT at the device-level can be composed of several 185 submodule EAT's. It is assumed that any entity that can create an 186 EAT does so by means of a dedicated root-of-trust (RoT). 188 Modern devices such as a mobile phone have many different execution 189 environments operating with different security levels. For example, 190 it is common for a mobile phone to have an "apps" environment that 191 runs an operating system (OS) that hosts a plethora of downloadable 192 apps. It may also have a TEE (Trusted Execution Environment) that is 193 distinct, isolated, and hosts security-oriented functionality like 194 biometric authentication. Additionally, it may have an eSE (embedded 195 Secure Element) - a high security chip with defenses against HW 196 attacks that can serve as a RoT. This device attestation format 197 allows the attested data to be tagged at a security level from which 198 it originates. In general, any discrete execution environment that 199 has an identifiable security level can be considered an entity. 201 1.3. EAT Operating Models 203 At least the following three participants exist in all EAT operating 204 models. Some operating models have additional participants. 206 The Entity. This is the phone, the IoT device, the sensor, the sub- 207 assembly or such that the attestation provides information about. 209 The Manufacturer. The company that made the entity. This may be a 210 chip vendor, a circuit board module vendor or a vendor of finished 211 consumer products. 213 The Relying Party. The server, service or company that makes use of 214 the information in the EAT about the entity. 216 In all operating models, the manufacturer provisions some secret 217 attestation key material (AKM) into the entity during manufacturing. 218 This might be during the manufacturer of a chip at a fabrication 219 facility (fab) or during final assembly of a consumer product or any 220 time in between. This attestation key material is used for signing 221 EATs. 223 In all operating models, hardware and/or software on the entity 224 create an EAT of the format described in this document. The EAT is 225 always signed by the attestation key material provisioned by the 226 manufacturer. 228 In all operating models, the relying party must end up knowing that 229 the signature on the EAT is valid and consistent with data from 230 claims in the EAT. This can happen in many different ways. Here are 231 some examples. 233 o The EAT is transmitted to the relying party. The relying party 234 gets corresponding key material (e.g. a root certificate) from the 235 manufacturer. The relying party performs the verification. 237 o The EAT is transmitted to the relying party. The relying party 238 transmits the EAT to a verification service offered by the 239 manufacturer. The server returns the validated claims. 241 o The EAT is transmitted directly to a verification service, perhaps 242 operated by the manufacturer or perhaps by another party. It 243 verifies the EAT and makes the validated claims available to the 244 relying party. It may even modify the claims in some way and re- 245 sign the EAT (with a different signing key). 247 All these operating models are supported and there is no preference 248 of one over the other. It is important to support this variety of 249 operating models to generally facilitate deployment and to allow for 250 some special scenarios. One special scenario has a validation 251 service that is monetized, most likely by the manufacturer. In 252 another, a privacy proxy service processes the EAT before it is 253 transmitted to the relying party. In yet another, symmetric key 254 material is used for signing. In this case the manufacturer should 255 perform the verification, because any release of the key material 256 would enable a participant other than the entity to create valid 257 signed EATs. 259 1.4. What is Not Standardized 261 The following is not standardized for EAT, just the same they are not 262 standardized for CWT or JWT. 264 1.4.1. Transmission Protocol 266 EATs may be transmitted by any protocol the same as CWTs and JWTs. 267 For example, they might be added in extension fields of other 268 protocols, bundled into an HTTP header, or just transmitted as files. 269 This flexibility is intentional to allow broader adoption. This 270 flexibility is possible because EAT's are self-secured with signing 271 (and possibly additionally with encryption and anti-replay). The 272 transmission protocol is not required to fulfill any additional 273 security requirements. 275 For certain devices, a direct connection may not exist between the 276 EAT-producing device and the Relying Party. In such cases, the EAT 277 should be protected against malicious access. The use of COSE and 278 JOSE allows for signing and encryption of the EAT. Therefore, even 279 if the EAT is conveyed through intermediaries between the device and 280 Relying Party, such intermediaries cannot easily modify the EAT 281 payload or alter the signature. 283 1.4.2. Signing Scheme 285 The term "signing scheme" is used to refer to the system that 286 includes end-end process of establishing signing attestation key 287 material in the entity, signing the EAT, and verifying it. This 288 might involve key IDs and X.509 certificate chains or something 289 similar but different. The term "signing algorithm" refers just to 290 the algorithm ID in the COSE signing structure. No particular 291 signing algorithm or signing scheme is required by this standard. 293 There are three main implementation issues driving this. First, 294 secure non-volatile storage space in the entity for the attestation 295 key material may be highly limited, perhaps to only a few hundred 296 bits, on some small IoT chips. Second, the factory cost of 297 provisioning key material in each chip or device may be high, with 298 even millisecond delays adding to the cost of a chip. Third, 299 privacy-preserving signing schemes like ECDAA (Elliptic Curve Direct 300 Anonymous Attestation) are complex and not suitable for all use 301 cases. 303 Over time to faciliate interoperability, some signing schemes may be 304 defined in EAT profiles or other documents either in the IETF or 305 outside. 307 2. Terminology 309 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 310 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 311 "OPTIONAL" in this document are to be interpreted as described in BCP 312 14 [RFC2119] [RFC8174] when, and only when, they appear in all 313 capitals, as shown here. 315 This document reuses terminology from JWT [RFC7519], COSE [RFC8152], 316 and CWT [RFC8392]. 318 Claim Name. The human-readable name used to identify a claim. 320 Claim Key. The CBOR map key or JSON name used to identify a claim. 322 Claim Value. The CBOR map or JSON object value representing the 323 value of the claim. 325 CWT Claims Set. The CBOR map or JSON object that contains the claims 326 conveyed by the CWT or JWT. 328 Attestation Key Material (AKM). The key material used to sign the 329 EAT token. If it is done symmetrically with HMAC, then this is a 330 simple symmetric key. If it is done with ECC, such as an IEEE 331 DevID [IDevID], then this is the private part of the EC key pair. 332 If ECDAA is used, (e.g., as used by Enhanced Privacy ID, i.e. 333 EPID) then it is the key material needed for ECDAA. 335 3. The Claims Information Model 337 This section describes new claims defined for attestation. It also 338 mentions several claims defined by CWT and JWT that are particularly 339 important for EAT. 341 Note also: * Any claim defined for CWT or JWT may be used in an EAT 342 including those in the CWT [IANA.CWT.Claims] and JWT IANA 343 [IANA.JWT.Claims] claims registries. 345 o All claims are optional 347 o No claims are mandatory 349 o All claims that are not understood by implementations MUST be 350 ignored 352 CDDL along with text descriptions is used to define the information 353 model. Each claim is defined as a CDDL group (the group is a general 354 aggregation and type definition feature of CDDL). In the data model, 355 described in the Section 4, the CDDL groups turn into CBOR map 356 entries and JSON name/value pairs. 358 3.1. Token ID Claim (cti and jti) 360 CWT defines the "cti" claim. JWT defines the "jti" claim. These are 361 equivalent to each other in EAT and carry a unique token identifier 362 as they do in JWT and CWT. They may be used to defend against re use 363 of the token but are distinct from the nonce that is used by the 364 relying party to guarantee freshness and defend against replay. 366 3.2. Timestamp claim (iat) 368 The "iat" claim defined in CWT and JWT is used to indicate the date- 369 of-creation of the token. 371 3.3. Nonce Claim (nonce) 373 All EATs should have a nonce to prevent replay attacks. The nonce is 374 generated by the relying party, the end consumer of the token. It is 375 conveyed to the entity over whatever transport is in use before the 376 token is generated and then included in the token as the nonce claim. 378 This documents the nonce claim for registration in the IANA CWT 379 claims registry. This is equivalent to the JWT nonce claim that is 380 already registered. 382 The nonce must be at least 8 bytes (64 bits) as fewer are unlikely to 383 be secure. A maximum of 64 bytes is set to limit the memory a 384 constrained implementation uses. This size range is not set for the 385 already-registered JWT nonce, but it should follow this size 386 recommendation when used in an EAT. 388 3.3.1. CDDL 390 nonce_claim = ( 391 nonce => bstr .size (8..64) 392 ) 394 3.4. Universal Entity ID Claim (ueid) 396 UEID's identify individual manufactured entities / devices such as a 397 mobile phone, a water meter, a Bluetooth speaker or a networked 398 security camera. It may identify the entire device or a submodule or 399 subsystem. It does not identify types, models or classes of devices. 400 It is akin to a serial number, though it does not have to be 401 sequential. 403 UEID's must be universally and globally unique across manufacturers 404 and countries. UEIDs must also be unique across protocols and 405 systems, as tokens are intended to be embedded in many different 406 protocols and systems. No two products anywhere, even in completely 407 different industries made by two different manufacturers in two 408 different countries should have the same UEID (if they are not global 409 and universal in this way, then relying parties receiving them will 410 have to track other characteristics of the device to keep devices 411 distinct between manufacturers). 413 There are privacy considerations for UEID's. See Section 6.1. 415 The UEID should be permanent. It should never change for a given 416 device / entity. In addition, it should not be reprogrammable. 417 UEID's are variable length. The recommended maximum is 33 bytes (1 418 type byte and 256 bits). The recommended minimum is 17 bytes (1 type 419 and 128 bits) because fewer bytes endanger the universal uniqueness. 421 When the entity constructs the UEID, the first byte is a type and the 422 following bytes the ID for that type. Several types are allowed to 423 accommodate different industries and different manufacturing 424 processes and to give options to avoid paying fees for certain types 425 of manufacturer registrations. 427 Creation of new types requires a Standards Action [RFC8126]. 429 +------+--------+---------------------------------------------------+ 430 | Type | Type | Specification | 431 | Byte | Name | | 432 +------+--------+---------------------------------------------------+ 433 | 0x01 | RAND | This is a 128- to 256-bit random number generated | 434 | | | once and stored in the device. This may be | 435 | | | constructed by concatenating enough identifiers | 436 | | | to be universally unique and then feeding the | 437 | | | concatenation through a cryptographic hash | 438 | | | function. It may also be a cryptographic quality | 439 | | | random number generate once at the beginning of | 440 | | | the life of the device and stored. | 441 | 0x02 | IEEE | This makes use of the IEEE company identification | 442 | | EUI | registry. An EUI is made up of an OUI and OUI-36 | 443 | | | or a CID, different registered company | 444 | | | identifiers, and some unique per-device | 445 | | | identifier. EUIs are often the same as or similar | 446 | | | to MAC addresses. (Note that while devices with | 447 | | | multiple network interfaces may have multiple MAC | 448 | | | addresses, there is only one UEID for a device) | 449 | | | TODO: normative references to IEEE. | 450 | 0x03 | IMEI | This is a 14-digit identifier consisting of an | 451 | | | 8-digit Type Allocation Code and a 6-digit serial | 452 | | | number allocated by the manufacturer, which SHALL | 453 | | | be encoded as a binary integer over 48 bits. The | 454 | | | IMEI value encoded SHALL NOT include Luhn | 455 | | | checksum or SVN information. | 456 | 0x04 | EUI-48 | This is a 48-bit identifier formed by | 457 | | | concatenating the 24-bit OUI with a 24-bit | 458 | | | identifier assigned by the organisation that | 459 | | | purchased the OUI. | 460 | 0x05 | EUI-60 | This is a 60-bit identifier formed by | 461 | | | concatenating the 24-bit OUI with a 36-bit | 462 | | | identifier assigned by the organisation that | 463 | | | purchased the OUI. | 464 | 0x06 | EUI-64 | This is a 64-bit identifier formed by | 465 | | | concatenating the 24-bit OUI with a 40-bit | 466 | | | identifier assigned by the organisation that | 467 | | | purchased the OUI. | 468 +------+--------+---------------------------------------------------+ 470 Table 1: UEID Composition Types 472 UEID's are not designed for direct use by humans (e.g., printing on 473 the case of a device), so no textual representation is defined. 475 The consumer (the relying party) of a UEID MUST treat a UEID as a 476 completely opaque string of bytes and not make any use of its 477 internal structure. For example, they should not use the OUI part of 478 a type 0x02 UEID to identify the manufacturer of the device. Instead 479 they should use the OUI claim that is defined elsewhere. The reasons 480 for this are: 482 o UEIDs types may vary freely from one manufacturer to the next. 484 o New types of UEIDs may be created. For example, a type 0x07 UEID 485 may be created based on some other manufacturer registration 486 scheme. 488 o Device manufacturers are allowed to change from one type of UEID 489 to another anytime they want. For example, they may find they can 490 optimize their manufacturing by switching from type 0x01 to type 491 0x02 or vice versa. The main requirement on the manufacturer is 492 that UEIDs be universally unique. 494 3.4.1. CDDL 496 ueid_claim = ( 497 ueid: bstr ) 499 3.5. Origination Claim (origination) 501 This claim describes the parts of the device or entity that are 502 creating the EAT. Often it will be tied back to the device or chip 503 manufacturer. The following table gives some examples: 505 +-------------------+-----------------------------------------------+ 506 | Name | Description | 507 +-------------------+-----------------------------------------------+ 508 | Acme-TEE | The EATs are generated in the TEE authored | 509 | | and configured by "Acme" | 510 | Acme-TPM | The EATs are generated in a TPM manufactured | 511 | | by "Acme" | 512 | Acme-Linux-Kernel | The EATs are generated in a Linux kernel | 513 | | configured and shipped by "Acme" | 514 | Acme-TA | The EATs are generated in a Trusted | 515 | | Application (TA) authored by "Acme" | 516 +-------------------+-----------------------------------------------+ 518 TODO: consider a more structure approach where the name and the URI 519 and other are in separate fields. 521 TODO: This needs refinement. It is somewhat parallel to issuer claim 522 in CWT in that it describes the authority that created the token. 524 3.5.1. CDDL 526 origination_claim = ( 527 origination: string_or_uri ) 529 3.6. OEM Identification by IEEE (oemid) 531 The IEEE operates a global registry for MAC addresses and company 532 IDs. This claim uses that database to identify OEMs. The contents 533 of the claim may be either an IEEE MA-L, MA-M, MA-S or an IEEE CID 534 [IEEE.RA]. An MA-L, formerly known as an OUI, is a 24-bit value used 535 as the first half of a MAC address. MA-M similarly is a 28-bit value 536 uses as the first part of a MAC address, and MA-S, formerly known as 537 OUI-36, a 36-bit value. Many companies already have purchased one of 538 these. A CID is also a 24-bit value from the same space as an MA-L, 539 but not for use as a MAC address. IEEE has published Guidelines for 540 Use of EUI, OUI, and CID [OUI.Guide] and provides a lookup services 541 [OUI.Lookup] 543 Companies that have more than one of these IDs or MAC address blocks 544 should pick one and prefer that for all their devices. 546 Commonly, these are expressed in Hexadecimal Representation 547 [IEEE.802-2001] also called the Canonical format. When this claim is 548 encoded order of bytes in the bstr are the same as the order in the 549 Hexadecimal Representation. For example, an MA-L like "AC-DE-48" 550 would be encoded in 3 bytes with values 0xAC, 0xDE, 0x48. For JSON 551 encoded tokens, this is further base64url encoded. 553 3.6.1. CDDL 555 oemid_claim = ( 556 oemid: bstr ) 558 3.7. The Security Level Claim (security_level) 560 EATs have a claim that roughly characterizes the device / entities 561 ability to defend against attacks aimed at capturing the signing key, 562 forging claims and at forging EATs. This is done by roughly defining 563 four security levels as described below. This is similar to the 564 security levels defined in the Metadata Service defined by the Fast 565 Identity Online (FIDO) Alliance (TODO: reference). 567 These claims describe security environment and countermeasures 568 available on the end-entity / client device where the attestation key 569 reside and the claims originate. 571 1 - Unrestricted There is some expectation that implementor will 572 protect the attestation signing keys at this level. Otherwise the 573 EAT provides no meaningful security assurances. 575 2- Restricted Entities at this level should not be general-purpose 576 operating environments that host features such as app download 577 systems, web browsers and complex productivity applications. It 578 is akin to the Secure Restricted level (see below) without the 579 security orientation. Examples include a Wi-Fi subsystem, an IoT 580 camera, or sensor device. 582 3 - Secure Restricted Entities at this level must meet the criteria 583 defined by FIDO Allowed Restricted Operating Environments (TODO: 584 reference). Examples include TEE's and schemes using 585 virtualization-based security. Like the FIDO security goal, 586 security at this level is aimed at defending well against large- 587 scale network / remote attacks against the device. 589 4 - Hardware Entities at this level must include substantial defense 590 against physical or electrical attacks against the device itself. 591 It is assumed any potential attacker has captured the device and 592 can disassemble it. Example include TPMs and Secure Elements. 594 This claim is not intended as a replacement for a proper end-device 595 security certification schemes such as those based on FIPS (TODO: 596 reference) or those based on Common Criteria (TODO: reference). The 597 claim made here is solely a self-claim made by the Entity Originator. 599 3.7.1. CDDL 601 security_level_type = ( 602 unrestricted: 1, 603 restricted: 2, 604 secure_restricted: 3, 605 hardware: 4 606 ) 608 security_level_claim = ( 609 security_level: security_level_type ) 611 3.8. Secure Boot and Debug Enable State Claims (boot_state) 613 This claim is an array of five Boolean values indicating the boot and 614 debug state of the entity. 616 3.8.1. Secure Boot Enabled 618 This indicates whether secure boot is enabled either for an entire 619 device or an individual submodule. If it appears at the device 620 level, then this means that secure boot is enabled for all 621 submodules. Secure boot enablement allows a secure boot loader to 622 authenticate software running either in a device or a submodule prior 623 allowing execution. 625 3.8.2. Debug Disabled 627 This indicates whether debug capabilities are disabled for an entity 628 (i.e. value of 'true'). Debug disablement is considered a 629 prerequisite before an entity is considered operational. 631 3.8.3. Debug Disabled Since Boot 633 This claim indicates whether debug capabilities for the entity were 634 not disabled in any way since boot (i.e. value of 'true'). 636 3.8.4. Debug Permanent Disable 638 This claim indicates whether debug capabilities for the entity are 639 permanently disabled (i.e. value of 'true'). This value can be set 640 to 'true' also if only the manufacturer is allowed to enabled debug, 641 but the end user is not. 643 3.8.5. Debug Full Permanent Disable 645 This claim indicates whether debug capabilities for the entity are 646 permanently disabled (i.e. value of 'true'). This value can only be 647 set to 'true' if no party can enable debug capabilities for the 648 entity. Often this is implemented by blowing a fuse on a chip as 649 fuses cannot be restored once blown. 651 3.8.6. CDDL 653 boot_state_type = [ 654 secure_boot_enabled=> bool, 655 debug_disabled=> bool, 656 debug_disabled_since_boot=> bool, 657 debug_permanent_disable=> bool, 658 debug_full_permanent_disable=> bool 659 ] 661 boot_state_claim = ( 662 boot_state: boot_state_type 663 ) 665 3.9. The Location Claim (location) 667 The location claim is a CBOR-formatted object that describes the 668 location of the device entity from which the attestation originates. 669 It is comprised of a map of additional sub claims that represent the 670 actual location coordinates (latitude, longitude and altitude). The 671 location coordinate claims are consistent with the WGS84 coordinate 672 system [WGS84]. In addition, a sub claim providing the estimated 673 accuracy of the location measurement is defined. 675 3.9.1. CDDL 677 location_type = { 678 latitude => number, 679 longitude => number, 680 altitude => number, 681 accuracy => number, 682 altitude_accuracy => number, 683 heading => number, 684 speed => number 685 } 687 location_claim = ( 688 location: location_type ) 690 3.10. The Age Claim (age) 692 The "age" claim contains a value that represents the number of 693 seconds that have elapsed since the token was created, measurement 694 was made, or location was obtained. Typical attestable values are 695 sent as soon as they are obtained. However, in the case that such a 696 value is buffered and sent at a later time and a sufficiently 697 accurate time reference is unavailable for creation of a timestamp, 698 then the age claim is provided. 700 age_claim = ( 701 age: uint) 703 3.11. The Uptime Claim (uptime) 705 The "uptime" claim contains a value that represents the number of 706 seconds that have elapsed since the entity or submod was last booted. 708 3.11.1. CDDL 710 uptime_claim = ( 711 uptime: uint ) 713 3.12. Nested EATs, the EAT Claim (nested_eat) 715 It is allowed for one EAT to be embedded in another. This is for 716 complex devices that have more than one subsystem capable of 717 generating an EAT. For example, one might be the device-wide EAT 718 that is low to medium security and another from a Secure Element or 719 similar that is high security. 721 The contents of the "nested_eat" claim must be a fully signed, 722 optionally encrypted, EAT token. 724 3.12.1. CDDL 726 nested_eat_claim = ( 727 nested_eat: nested_eat_type) 729 A nested_eat_type is defined in words rather than CDDL. It is either 730 a full CWT or JWT including the COSE or JOSE signing. 732 3.13. The Submods Claim (submods) 734 Some devices are complex, having many subsystems or submodules. A 735 mobile phone is a good example. It may have several connectivity 736 submodules for communications (e.g., Wi-Fi and cellular). It may 737 have subsystems for low-power audio and video playback. It may have 738 one or more security-oriented subsystems like a TEE or a Secure 739 Element. 741 The claims for each these can be grouped together in a submodule. 743 Specifically, the "submods" claim is an array. Each item in the 744 array is a CBOR map containing all the claims for a particular 745 submodule. 747 The security level of the submod is assumed to be at the same level 748 as the main entity unless there is a security level claim in that 749 submodule indicating otherwise. The security level of a submodule 750 can never be higher (more secure) than the security level of the EAT 751 it is a part of. 753 3.13.1. The submod_name Claim 755 Each submodule should have a submod_name claim that is descriptive 756 name. This name should be the CBOR txt type. 758 3.13.2. CDDL 760 In the following a generic_claim_type is any CBOR map entry or JSON 761 name/value pair. 763 submod_name_type = ( 764 submod_name: tstr ) 766 submods_type = [ * submod_claims ] 768 submod_claims = { 769 submod_name_type, 770 * generic_claim_type 771 } 773 submods_claim = ( 774 submods: submod_type ) 776 4. Data Model 778 This makes use of the types defined in CDDL Appendix D, Standard 779 Prelude. 781 4.1. Common CDDL Types 783 string_or_uri = #6.32(tstr) / tstr; See JSON section below for JSON encoding of string_or_uri 785 4.2. CDDL for CWT-defined Claims 787 This section provides CDDL for the claims defined in CWT. It is non- 788 normative as [RFC8392] is the authoritative definition of these 789 claims. 791 cwt_claim = ( 792 issuer_claim // 793 subject_claim // 794 audience_claim // 795 expiration_claim // 796 not_before_claim // 797 issued_at_calim // 798 cwt_id_claim 799 ) 801 issuer_claim = ( 802 issuer: string_or_uri ) 804 subject_claim = ( 805 subject: string_or_uri ) 807 audience_claim = ( 808 audience: string_or_uri ) 810 expiration_claim = ( 811 expiration: time ) 813 not_before_claim = ( 814 not_before: time ) 816 issued_at_calim = ( 817 issued_at: time ) 819 cwt_id_claim = ( 820 cwt_id: bstr ) 822 issuer = 1 823 subject = 2 824 audience = 3 825 expiration = 4 826 not_before = 5 827 issued_at = 6 828 cwt_id = 7 830 4.3. JSON 832 4.3.1. JSON Labels 833 ueid = "ueid" 834 origination = "origination" 835 oemid = "oemid" 836 security_level = "security_level" 837 boot_state = "boot_state" 838 location = "location" 839 age = "age" 840 uptime = "uptime" 841 nested_eat = "nested_eat" 842 submods = "submods" 844 latitude = "lat"" 845 longitude = "long"" 846 altitude = "alt" 847 accuracy = "accry" 848 altitude_accuracy = "alt_accry" 849 heading = "heading" 850 speed = "speed" 852 4.3.2. JSON Interoperability 854 JSON should be encoded per RFC 8610 Appendix E. In addition, the 855 following CDDL types are encoded in JSON as follows: 857 o bstr - must be base64url encoded 859 o time - must be encoded as NumericDate as described section 2 of 860 [RFC7519]. 862 o string_or_uri - must be encoded as StringOrURI as described 863 section 2 of [RFC7519]. 865 4.4. CBOR 867 4.4.1. Labels 868 ueid = 8 869 origination = 9 870 oemid = 10 871 security_level = 11 872 boot_state = 12 873 location = 13 874 age = 14 875 uptime = 15 876 nested_eat = 16 877 submods = 17 878 submod_name = 18 879 nonce = 19 881 latitude = 1 882 longitude = 2 883 altitude = 3 884 accuracy = 4 885 altitude_accuracy = 5 886 heading = 6 887 speed = 7 889 4.4.2. CBOR Interoperability 891 Variations in the CBOR serializations supported in CBOR encoding and 892 decoding are allowed and suggests that CBOR-based protocols specify 893 how this variation is handled. This section specifies what formats 894 MUST be supported in order to achieve interoperability. 896 The assumption is that the entity is likely to be a constrained 897 device and relying party is likely to be a very capable server. The 898 approach taken is that the entity generating the token can use 899 whatever encoding it wants, specifically encodings that are easier to 900 implement such as indefinite lengths. The relying party receiving 901 the token must support decoding all encodings. 903 These rules cover all types used in the claims in this document. 904 They also are recommendations for additional claims. 906 Canonical CBOR encoding, Preferred Serialization and 907 Deterministically Encoded CBOR are explicitly NOT required as they 908 would place an unnecessary burden on the entity implementation, 909 particularly if the entity implementation is implemented in hardware. 911 o Integer Encoding (major type 0, 1) - The entity may use any 912 integer encoding allowed by CBOR. The server MUST accept all 913 integer encodings allowed by CBOR. 915 o String Encoding (major type 2 and 3) - The entity can use any 916 string encoding allowed by CBOR including indefinite lengths. It 917 may also encode the lengths of strings in any way allowed by CBOR. 918 The server must accept all string encodings. 920 o Major type 2, bstr, SHOULD be have tag 21 to indicate conversion 921 to base64url in case that conversion is performed. 923 o Map and Array Encoding (major type 4 and 5) - The entity can use 924 any array or map encoding allowed by CBOR including indefinite 925 lengths. Sorting of map keys is not required. Duplicate map keys 926 are not allowed. The server must accept all array and map 927 encodings. The server may reject maps with duplicate map keys. 929 o Date and Time - The entity should send dates as tag 1 encoded as 930 64-bit or 32-bit integers. The entity may not send floating-point 931 dates. The server must support tag 1 epoch-based dates encoded as 932 64-bit or 32-bit integers. The entity may send tag 0 dates, 933 however tag 1 is preferred. The server must support tag 0 UTC 934 dates. 936 o URIs - URIs should be encoded as text strings and marked with tag 937 32. 939 o Floating Point - The entity may use any floating-point encoding. 940 The relying party must support decoding of all types of floating- 941 point. 943 o Other types - Use of Other types like bignums, regular expressions 944 and such, SHOULD NOT be used. The server MAY support them but is 945 not required to so interoperability is not guaranteed. 947 4.5. Collected CDDL 949 A generic_claim is any CBOR map entry or JSON name/value pair. 951 eat_claims = { ; the top-level payload that is signed using COSE or JOSE 952 * claim 953 } 955 claim = ( 956 ueid_claim // 957 origination_claim // 958 oemid_claim // 959 security_level_claim // 960 boot_state_claim // 961 location_claim // 962 age_claim // 963 uptime_claim // 964 nested_eat_claim // 965 cwt_claim // 966 generic_claim_type // 967 ) 969 TODO: copy the rest of the CDDL here (wait until the CDDL is more 970 settled so as to avoid copying multiple times) 972 5. IANA Considerations 974 5.1. Reuse of CBOR Web Token (CWT) Claims Registry 976 Claims defined for EAT are compatible with those of CWT so the CWT 977 Claims Registry is re used. No new IANA registry is created. All 978 EAT claims should be registered in the CWT and JWT Claims Registries. 980 5.1.1. Claims Registered by This Document 982 o Claim Name: UEID 984 o Claim Description: The Universal Entity ID 986 o JWT Claim Name: N/A 988 o Claim Key: 8 990 o Claim Value Type(s): byte string 992 o Change Controller: IESG 994 o Specification Document(s): *this document* 996 TODO: add the rest of the claims in here 998 6. Privacy Considerations 1000 Certain EAT claims can be used to track the owner of an entity and 1001 therefore, implementations should consider providing privacy- 1002 preserving options dependent on the intended usage of the EAT. 1003 Examples would include suppression of location claims for EAT's 1004 provided to unauthenticated consumers. 1006 6.1. UEID Privacy Considerations 1008 A UEID is usually not privacy-preserving. Any set of relying parties 1009 that receives tokens that happen to be from a single device will be 1010 able to know the tokens are all from the same device and be able to 1011 track the device. Thus, in many usage situations ueid violates 1012 governmental privacy regulation. In other usage situations UEID will 1013 not be allowed for certain products like browsers that give privacy 1014 for the end user. It will often be the case that tokens will not 1015 have a UEID for these reasons. 1017 There are several strategies that can be used to still be able to put 1018 UEID's in tokens: 1020 o The device obtains explicit permission from the user of the device 1021 to use the UEID. This may be through a prompt. It may also be 1022 through a license agreement. For example, agreements for some 1023 online banking and brokerage services might already cover use of a 1024 UEID. 1026 o The UEID is used only in a particular context or particular use 1027 case. It is used only by one relying party. 1029 o The device authenticates the relying party and generates a derived 1030 UEID just for that particular relying party. For example, the 1031 relying party could prove their identity cryptographically to the 1032 device, then the device generates a UEID just for that relying 1033 party by hashing a proofed relying party ID with the main device 1034 UEID. 1036 Note that some of these privacy preservation strategies result in 1037 multiple UEIDs per device. Each UEID is used in a different context, 1038 use case or system on the device. However, from the view of the 1039 relying party, there is just one UEID and it is still globally 1040 universal across manufacturers. 1042 7. Security Considerations 1044 TODO: Perhaps this can be the same as CWT / COSE, but not sure yet 1045 because it involves so much entity / device security that those do 1046 not. 1048 8. References 1050 8.1. Normative References 1052 [IANA.CWT.Claims] 1053 IANA, "CBOR Web Token (CWT) Claims", 1054 . 1056 [IANA.JWT.Claims] 1057 IANA, "JSON Web Token (JWT) Claims", 1058 . 1060 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1061 Requirement Levels", BCP 14, RFC 2119, 1062 DOI 10.17487/RFC2119, March 1997, 1063 . 1065 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 1066 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 1067 October 2013, . 1069 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 1070 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 1071 . 1073 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1074 Writing an IANA Considerations Section in RFCs", BCP 26, 1075 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1076 . 1078 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 1079 RFC 8152, DOI 10.17487/RFC8152, July 2017, 1080 . 1082 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1083 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1084 May 2017, . 1086 [RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, 1087 "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, 1088 May 2018, . 1090 [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data 1091 Definition Language (CDDL): A Notational Convention to 1092 Express Concise Binary Object Representation (CBOR) and 1093 JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, 1094 June 2019, . 1096 [TIME_T] The Open Group Base Specifications, "Vol. 1: Base 1097 Definitions, Issue 7", Section 4.15 'Seconds Since the 1098 Epoch', IEEE Std 1003.1, 2013 Edition, 2013, 1099 . 1102 [WGS84] National Imagery and Mapping Agency, "National Imagery and 1103 Mapping Agency Technical Report 8350.2, Third Edition", 1104 2000, . 1107 8.2. Informative References 1109 [ASN.1] International Telecommunication Union, "Information 1110 Technology -- ASN.1 encoding rules: Specification of Basic 1111 Encoding Rules (BER), Canonical Encoding Rules (CER) and 1112 Distinguished Encoding Rules (DER)", ITU-T Recommendation 1113 X.690, 1994. 1115 [ECMAScript] 1116 "Ecma International, "ECMAScript Language Specification, 1117 5.1 Edition", ECMA Standard 262", June 2011, 1118 . 1121 [IDevID] "IEEE Standard, "IEEE 802.1AR Secure Device Identifier"", 1122 December 2009, . 1125 [IEEE.802-2001] 1126 "IEEE Standard For Local And Metropolitan Area Networks 1127 Overview And Architecture", 2007, 1128 . 1131 [IEEE.RA] "IEEE Registration Authority", 1132 . 1135 [OUI.Guide] 1136 "Guidelines for Use of Extended Unique Identifier (EUI), 1137 Organizationally Unique Identifier (OUI), and Company ID 1138 (CID)", August 2017, 1139 . 1142 [OUI.Lookup] 1143 "IEEE Registration Authority Assignments", 1144 . 1147 [Webauthn] 1148 Worldwide Web Consortium, "Web Authentication: A Web API 1149 for accessing scoped credentials", 2016. 1151 Appendix A. Examples 1153 A.1. Very Simple EAT 1155 This is shown in CBOR diagnostic form. Only the payload signed by 1156 COSE is shown. 1158 { 1159 / nonce (cti) / 7:h'948f8860d13a463e8e', 1160 / UEID / 8:h'0198f50a4ff6c05861c8860d13a638ea4fe2f', 1161 / boot_state / 12:{true, true, true, true, false} 1162 / time stamp (iat) / 6:1526542894, 1163 } 1165 A.2. Example with Submodules, Nesting and Security Levels 1167 { 1168 / nonce / 7:h'948f8860d13a463e8e', 1169 / UEID / 8:h'0198f50a4ff6c05861c8860d13a638ea4fe2f', 1170 / boot_state / 12:{true, true, true, true, false} 1171 / time stamp (iat) / 6:1526542894, 1172 / seclevel / 11:3, / secure restricted OS / 1174 / submods / 17: 1175 [ 1176 / 1st submod, an Android Application / { 1177 / submod_name / 18:'Android App "Foo"', 1178 / seclevel / 11:1, / unrestricted / 1179 / app data / -70000:'text string' 1180 }, 1181 / 2nd submod, A nested EAT from a secure element / { 1182 / submod_name / 18:'Secure Element EAT', 1183 / eat / 16:61( 18( 1184 / an embedded EAT / [ /...COSE_Sign1 bytes with payload.../ ] 1185 )) 1186 } 1187 / 3rd submod, information about Linux Android / { 1188 / submod_name/ 18:'Linux Android', 1189 / seclevel / 11:1, / unrestricted / 1190 / custom - release / -80000:'8.0.0', 1191 / custom - version / -80001:'4.9.51+' 1192 } 1193 ] 1194 } 1195 Appendix B. Changes from Previous Drafts 1197 The following is a list of known changes from the previous drafts. 1198 This list is non-authoritative. It is meant to help reviewers see 1199 the significant differences. 1201 B.1. From draft-mandyam-rats-eat-00 1203 This is a fairly large change in the orientation of the document, but 1204 not new claims have been added. 1206 o Separate information and data model using CDDL. 1208 o Say an EAT is a CWT or JWT 1210 o Use a map to structure the boot_state and location claims 1212 B.2. From draft-ietf-rats-eat-01 1214 o Clarifications and corrections for OEMID claim 1216 o Minor spelling and other fixes 1218 o Add the nonce claim, clarify jti claim 1220 Authors' Addresses 1222 Giridhar Mandyam 1223 Qualcomm Technologies Inc. 1224 5775 Morehouse Drive 1225 San Diego, California 1226 USA 1228 Phone: +1 858 651 7200 1229 EMail: mandyam@qti.qualcomm.com 1231 Laurence Lundblade 1232 Security Theory LLC 1234 EMail: lgl@island-resort.com 1235 Miguel Ballesteros 1236 Qualcomm Technologies Inc. 1237 5775 Morehouse Drive 1238 San Diego, California 1239 USA 1241 Phone: +1 858 651 4299 1242 EMail: mballest@qti.qualcomm.com 1244 Jeremy O'Donoghue 1245 Qualcomm Technologies Inc. 1246 279 Farnborough Road 1247 Farnborough GU14 7LS 1248 United Kingdom 1250 Phone: +44 1252 363189 1251 EMail: jodonogh@qti.qualcomm.com