idnits 2.17.00 (12 Aug 2021) /tmp/idnits7177/draft-ietf-teep-protocol-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 14, 2020) is 766 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'CDDL' is mentioned on line 533, but not defined == Outdated reference: A later version (-12) exists of draft-ietf-rats-eat-03 == Outdated reference: A later version (-17) exists of draft-ietf-suit-manifest-04 ** Obsolete normative reference: RFC 2560 (Obsoleted by RFC 6960) ** Obsolete normative reference: RFC 7049 (Obsoleted by RFC 8949) == Outdated reference: A later version (-17) exists of draft-ietf-teep-architecture-08 Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TEEP H. Tschofenig 3 Internet-Draft Arm Ltd. 4 Intended status: Standards Track M. Pei 5 Expires: October 16, 2020 Broadcom 6 D. Wheeler 7 Intel 8 D. Thaler 9 Microsoft 10 A. Tsukamoto 11 AIST 12 April 14, 2020 14 Trusted Execution Environment Provisioning (TEEP) Protocol 15 draft-ietf-teep-protocol-02 17 Abstract 19 This document specifies a protocol that installs, updates, and 20 deletes Trusted Applications (TAs) in a device with a Trusted 21 Execution Environment (TEE). This specification defines an 22 interoperable protocol for managing the lifecycle of TAs. 24 The protocol name is pronounced teepee. This conjures an image of a 25 wedge-shaped protective covering for one's belongings, which sort of 26 matches the intent of this protocol. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on October 16, 2020. 45 Copyright Notice 47 Copyright (c) 2020 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 64 3. Message Overview . . . . . . . . . . . . . . . . . . . . . . 3 65 4. Detailed Messages Specification . . . . . . . . . . . . . . . 5 66 4.1. Creating and Validating TEEP Messages . . . . . . . . . . 5 67 4.1.1. Creating a TEEP message . . . . . . . . . . . . . . . 5 68 4.1.2. Validating a TEEP Message . . . . . . . . . . . . . . 6 69 4.2. QueryRequest . . . . . . . . . . . . . . . . . . . . . . 6 70 4.3. QueryResponse . . . . . . . . . . . . . . . . . . . . . . 8 71 4.4. TrustedAppInstall . . . . . . . . . . . . . . . . . . . . 10 72 4.5. TrustedAppDelete . . . . . . . . . . . . . . . . . . . . 11 73 4.6. Success . . . . . . . . . . . . . . . . . . . . . . . . . 11 74 4.7. Error . . . . . . . . . . . . . . . . . . . . . . . . . . 12 75 5. Mapping of TEEP Message Parameters to CBOR Labels . . . . . . 15 76 6. Ciphersuites . . . . . . . . . . . . . . . . . . . . . . . . 15 77 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 78 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 79 8.1. Media Type Registration . . . . . . . . . . . . . . . . . 17 80 8.2. Error Code Registry . . . . . . . . . . . . . . . . . . . 18 81 8.3. Ciphersuite Registry . . . . . . . . . . . . . . . . . . 19 82 8.4. CBOR Tag Registry . . . . . . . . . . . . . . . . . . . . 19 83 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 84 9.1. Normative References . . . . . . . . . . . . . . . . . . 20 85 9.2. Informative References . . . . . . . . . . . . . . . . . 21 86 A. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 21 87 B. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 88 C. Complete CDDL . . . . . . . . . . . . . . . . . . . . . . . . 21 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 91 1. Introduction 93 The Trusted Execution Environment (TEE) concept has been designed to 94 separate a regular operating system, also referred as a Rich 95 Execution Environment (REE), from security-sensitive applications. 96 In an TEE ecosystem, device vendors may use different operating 97 systems in the REE and may use different types of TEEs. When 98 application providers or device administrators use Trusted 99 Application Managers (TAMs) to install, update, and delete Trusted 100 Applications (TAs) on a wide range of devices with potentially 101 different TEEs then an interoperability need arises. 103 This document specifies the protocol for communicating between a TAM 104 and a TEEP Agent, involving a TEEP Broker. 106 The Trusted Execution Environment Provisioning (TEEP) architecture 107 document [I-D.ietf-teep-architecture] has set to provide a design 108 guidance for such an interoperable protocol and introduces the 109 necessary terminology. Note that the term Trusted Application may 110 include more than code; it may also include configuration data and 111 keys needed by the TA to operate correctly. 113 2. Requirements Language 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 117 "OPTIONAL" in this document are to be interpreted as described in 118 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 119 capitals, as shown here. 121 This specification re-uses the terminology defined in 122 [I-D.ietf-teep-architecture]. 124 3. Message Overview 126 The TEEP protocol consists of a couple of messages exchanged between 127 a TAM and a TEEP Agent via a TEEP Broker. The messages are encoded 128 in CBOR and designed to provide end-to-end security. TEEP protocol 129 messages are signed by the endpoints, i.e., the TAM and the TEEP 130 Agent, but trusted applications may as well be encrypted and signed 131 by the service provider. The TEEP protocol not only re-use CBOR but 132 also the respective security wrapper, namely COSE [RFC8152]. 133 Furthermore, for attestation the Entity Attestation Token (EAT) 134 [I-D.ietf-rats-eat] and for software updates the SUIT manifest format 135 [I-D.ietf-suit-manifest] are re-used. 137 This specification defines six messages. 139 A TAM queries a device's current state with a QueryRequest message. 140 A TEEP Agent will, after authenticating and authorizing the request, 141 report attestation information, list all TAs, and provide information 142 about supported algorithms and extensions in a QueryResponse message. 143 An error message is returned if the request could not be processed. 144 A TAM will process the QueryResponse message and determine whether 145 subsequent message exchanges to install, update, or delete trusted 146 applications shall be initiated. 148 +------------+ +-------------+ 149 | TAM | |TEEP Agent | 150 +------------+ +-------------+ 152 QueryRequest -------> 154 QueryResponse 156 <------- or 158 Error 160 With the TrustedAppInstall message a TAM can instruct a TEEP Agent to 161 install a TA. The TEEP Agent will process the message, determine 162 whether the TAM is authorized and whether the TA has been signed by 163 an authorized SP. In addition to the binary, the TAM may also 164 provide personalization data. If the TrustedAppInstall message was 165 processed successfully then a Success message is returned to the TAM, 166 an Error message otherwise. 168 +------------+ +-------------+ 169 | TAM | |TEEP Agent | 170 +------------+ +-------------+ 172 TrustedAppInstall ----> 174 Success 176 <---- or 178 Error 180 With the TrustedAppDelete message a TAM can instruct a TEEP Agent to 181 delete one or multiple TA(s). A Success message is returned when the 182 operation has been completed successfully, and an Error message 183 otherwise. 185 +------------+ +-------------+ 186 | TAM | |TEEP Agent | 187 +------------+ +-------------+ 189 TrustedAppDelete ----> 191 Success 193 <---- or 195 Error 197 4. Detailed Messages Specification 199 TEEP messages are protected by the COSE_Sign1 structure. The TEEP 200 protocol messages are described in CDDL format [RFC8610] below. 202 teep-message => (QueryRequest / 203 QueryResponse / 204 TrustedAppInstall / 205 TrustedAppDelete / 206 Error / 207 Success ), 208 } 210 4.1. Creating and Validating TEEP Messages 212 4.1.1. Creating a TEEP message 214 To create a TEEP message, the following steps are performed. 216 1. Create a TEEP message according to the description below and 217 populate it with the respective content. 219 2. Create a COSE Header containing the desired set of Header 220 Parameters. The COSE Header MUST be valid per the [RFC8152] 221 specification. 223 3. Create a COSE_Sign1 object using the TEEP message as the 224 COSE_Sign1 Payload; all steps specified in [RFC8152] for creating 225 a COSE_Sign1 object MUST be followed. 227 4. Prepend the COSE object with the TEEP CBOR tag to indicate that 228 the CBOR-encoded message is indeed a TEEP message. 230 4.1.2. Validating a TEEP Message 232 When validating a TEEP message, the following steps are performed. 233 If any of the listed steps fail, then the TEEP message MUST be 234 rejected. 236 1. Verify that the received message is a valid CBOR object. 238 2. Remove the TEEP message CBOR tag and verify that one of the COSE 239 CBOR tags follows it. 241 3. Verify that the message contains a COSE_Sign1 structure. 243 4. Verify that the resulting COSE Header includes only parameters 244 and values whose syntax and semantics are both understood and 245 supported or that are specified as being ignored when not 246 understood. 248 5. Follow the steps specified in Section 4 of [RFC8152] ("Signing 249 Objects") for validating a COSE_Sign1 object. The COSE_Sign1 250 payload is the content of the TEEP message. 252 6. Verify that the TEEP message is a valid CBOR map and verify the 253 fields of the TEEP message according to this specification. 255 4.2. QueryRequest 257 A QueryRequest message is used by the TAM to learn information from 258 the TEEP Agent. The TAM can learn the features supported by the TEEP 259 Agent, including ciphersuites, and protocol versions. Additionally, 260 the TAM can selectively request data items from the TEEP Agent via 261 the request parameter. Currently, the following features are 262 supported: 264 o Request for attestation information, 266 o Listing supported extensions, 268 o Querying installed software (trusted apps), and 270 o Listing supporting SUIT commands. 272 Like other TEEP messages, the QueryRequest message is signed, and the 273 relevant CDDL snippet is shown below. The complete CDDL structure is 274 shown in [CDDL]. 276 query-request = [ 277 type: TEEP-TYPE-query-request, 278 token: uint, 279 options: { 280 ? supported-cipher-suites => suite, 281 ? nonce => bstr .size (8..64), 282 ? version => [ + version ], 283 ? oscp-data => bstr, 284 * $$query-request-extensions 285 * $$teep-option-extensions 286 }, 287 data-item-requested 288 ] 290 The message has the following fields: 292 type 293 The value of (1) corresponds to a QueryRequest message sent from 294 the TAM to the TEEP Agent. 296 token 297 The value in the token parameter is used to match responses to 298 requests. This is particualrly useful when a TAM issues multiple 299 concurrent requests to a TEEP Agent. 301 request 302 The request parameter indicates what information the TAM requests 303 from the TEEP Agent in form of a bitmap. Each value in the bitmap 304 corresponds to an IANA registered information element. This 305 specification defines the following initial set of information 306 elements: 308 attestation (1) With this value the TAM requests the TEEP Agent 309 to return an entity attestation token (EAT) in the response. 310 If the TAM requests an attestation token to be returned by the 311 TEEP Agent then it MUST also include the nonce in the message. 312 The nonce is subsequently placed into the EAT token for replay 313 protection. 315 trusted_apps (2) With this value the TAM queries the TEEP Agent 316 for all installed TAs. 318 extensions (4) With this value the TAM queries the TEEP Agent for 319 supported capabilities and extensions, which allows a TAM to 320 discover the capabilities of a TEEP Agent implementation. 322 suit_commands (8) With this value the TAM queries the TEEP Agent 323 for supported commands offered by the SUIT manifest 324 implementation. 326 Further values may be added in the future via IANA registration. 328 cipher-suites 329 The cipher-suites parameter lists the ciphersuite(s) supported by 330 the TAM. Details about the ciphersuite encoding can be found in 331 Section 6. 333 nonce 334 The none field is an optional parameter used for ensuring the 335 refreshness of the Entity Attestation Token (EAT) returned with a 336 QueryResponse message. When a nonce is provided in the 337 QueryRequest and an EAT is returned with the QueryResponse message 338 then the nonce contained in this request MUST be copied into the 339 nonce claim found in the EAT token. 341 version 342 The version field parameter the version(s) supported by the TAM. 343 For this version of the specification this field can be omitted. 345 ocsp_data 346 The ocsp_data parameter contains a list of OCSP stapling data 347 respectively for the TAM certificate and each of the CA 348 certificates up to the root certificate. The TAM provides OCSP 349 data so that the TEEP Agent can validate the status of the TAM 350 certificate chain without making its own external OCSP service 351 call. OCSP data MUST be conveyed as a DER-encoded OCSP response 352 (using the ASN.1 type OCSPResponse defined in [RFC2560]). The use 353 of OCSP is optional to implement for both the TAM and the TEEP 354 Agent. A TAM can query the TEEP Agent for the support of this 355 functionality via the capability discovery exchange, as described 356 above. 358 4.3. QueryResponse 360 The QueryResponse message is the successful response by the TEEP 361 Agent after receiving a QueryRequest message. 363 Like other TEEP messages, the QueryResponse message is signed, and 364 the relevant CDDL snippet is shown below. The complete CDDL 365 structure is shown in [CDDL]. 367 query-response = [ 368 type: TEEP-TYPE-query-response, 369 token: uint, 370 options: { 371 ? selected-cipher-suite => suite, 372 ? selected-version => version, 373 ? eat => bstr, 374 ? ta-list => [ + bstr ], 375 ? ext-list => [ + ext-info ], 376 * $$query-response-extensions, 377 * $$teep-option-extensions 378 } 379 ] 381 The message has the following fields: 383 type 384 The value of (2) corresponds to a QueryResponse message sent from 385 the TEEP Agent to the TAM. 387 token 388 The value in the token parameter is used to match responses to 389 requests. The value MUST correspond to the value received with 390 the QueryRequest message. 392 selected-cipher-suite 393 The selected-cipher-suite parameter indicates the selected 394 ciphersuite. Details about the ciphersuite encoding can be found 395 in Section 6. 397 selected-version 398 The selected-version parameter indicates the protocol version 399 selected by the TEEP Agent. 401 eat 402 The eat parameter contains an Entity Attestation Token following 403 the encoding defined in [I-D.ietf-rats-eat]. 405 ta-list 406 The ta-list parameter enumerates the trusted applications 407 installed on the device in form of TA_ID byte strings. 409 ext-list 410 The ext-list parameter lists the supported extensions. This 411 document does not define any extensions. 413 4.4. TrustedAppInstall 415 The TrustedAppInstall message is used by the TAM to install software 416 (trusted apps) via the TEEP Agent. 418 Like other TEEP messages, the TrustedAppInstall message is signed, 419 and the relevant CDDL snippet is shown below. The complete CDDL 420 structure is shown in [CDDL]. 422 trusted-app-install = [ 423 type: TEEP-TYPE-trusted-app-install, 424 token: uint, 425 option: { 426 ? manifest-list => [ + SUIT-envelope ], 427 * $$trusted-app-install-extensions, 428 * $$teep-option-extensions 429 } 430 ] 432 The TrustedAppInstall message has the following fields: 434 type 435 The value of (3) corresponds to a TrustedAppInstall message sent 436 from the TAM to the TEEP Agent. In case of successful processing, 437 an Success message is returned by the TEEP Agent. In case of an 438 error, an Error message is returned. Note that the 439 TrustedAppInstall message is used for initial TA installation but 440 also for TA updates. 442 token 443 The value in the token field is used to match responses to 444 requests. 446 manifest-list 447 The manifest-list field is used to convey one or multiple SUIT 448 manifests. A manifest is a bundle of metadata about the trusted 449 app, where to find the code, the devices to which it applies, and 450 cryptographic information protecting the manifest. The manifest 451 may also convey personalization data. TA binaries and 452 personalization data is typically signed and encrypted by the SP. 453 Other combinations are, however, possible as well. For example, 454 it is also possible for the TAM to sign and encrypt the 455 personalization data and to let the SP sign and/or encrypt the TA 456 binary. 458 4.5. TrustedAppDelete 460 The TrustedAppDelete message is used by the TAM to remove software 461 (trust apps) from the device. 463 Like other TEEP messages, the TrustedAppDelete message is signed, and 464 the relevant CDDL snippet is shown below. The complete CDDL 465 structure is shown in [CDDL]. 467 trusted-app-delete = [ 468 type: TEEP-TYPE-trusted-app-delete, 469 token: uint, 470 option: { 471 ? ta-list => [ + bstr ], 472 * $$trusted-app-delete-extensions, 473 * $$teep-option-extensions 474 } 475 ] 477 The TrustedAppDelete message has the following fields: 479 type 480 The value of (4) corresponds to a TrustedAppDelete message sent 481 from the TAM to the TEEP Agent. In case of successful processing, 482 an Success message is returned by the TEEP Agent. In case of an 483 error, an Error message is returned. 485 token 486 The value in the token parameter is used to match responses to 487 requests. 489 ta-list 490 The ta-list parameter enumerates the TAs to be deleted. 492 4.6. Success 494 The TEEP protocol defines two implicit success messages and this 495 explicit Success message for the cases where the TEEP Agent cannot 496 return another reply, such as for the TrustedAppInstall and the 497 TrustedAppDelete messages. 499 Like other TEEP messages, the Success message is signed, and the 500 relevant CDDL snippet is shown below. The complete CDDL structure is 501 shown in [CDDL]. 503 teep-success = [ 504 type: TEEP-TYPE-teep-success, 505 token: uint, 506 option: { 507 ? msg => text, 508 * $$teep-success-extensions, 509 * $$teep-option-extensions 510 } 511 ] 513 The Success message has the following fields: 515 type 516 The value of (5) corresponds to corresponds to a Success message 517 sent from the TEEP Agent to the TAM. 519 token 520 The value in the token parameter is used to match responses to 521 requests. 523 msg 524 The msg parameter contains optional diagnostics information 525 encoded in UTF-8 [RFC3629] returned by the TEEP Agent. 527 4.7. Error 529 The Error message is used by the TEEP Agent to return an error. 531 Like other TEEP messages, the Error message is signed, and the 532 relevant CDDL snippet is shown below. The complete CDDL structure is 533 shown in [CDDL]. 535 teep-error = [ 536 type: TEEP-TYPE-teep-error, 537 token: uint, 538 err-code: uint, 539 options: { 540 ? err-msg => text, 541 ? cipher-suites => [ + suite ], 542 ? versions => [ + version ], 543 * $$teep-error--extensions, 544 * $$teep-option-extensions 545 } 546 ] 548 The Error message has the following fields: 550 type 551 The value of (6) corresponds to an Error message sent from the 552 TEEP Agent to the TAM. 554 token 555 The value in the token parameter is used to match responses to 556 requests. 558 err-code 559 The err-code parameter is populated with values listed in a 560 registry (with the initial set of error codes listed below). Only 561 selected messages are applicable to each message. 563 err-msg 564 The err-msg parameter is a human-readable diagnostic text that 565 MUST be encoded using UTF-8 [RFC3629] using Net-Unicode form 566 [RFC5198]. 568 cipher-suites 569 The cipher-suites parameter lists the ciphersuite(s) supported by 570 the TEEP Agent. This field is optional but MUST be returned with 571 the ERR_UNSUPPORTED_CRYPTO_ALG error message. 573 versions 574 The version parameter enumerates the protocol version(s) supported 575 by the TEEP Agent. This otherwise optional parameter MUST be 576 returned with the ERR_UNSUPPORTED_MSG_VERSION error message. 578 This specification defines the following initial error messages: 580 ERR_ILLEGAL_PARAMETER (1) 581 The TEEP Agent sends this error message when a request contains 582 incorrect fields or fields that are inconsistent with other 583 fields. 585 ERR_UNSUPPORTED_EXTENSION (2) 586 The TEEP Agent sends this error message when it recognizes an 587 unsupported extension or unsupported message. 589 ERR_REQUEST_SIGNATURE_FAILED (3) 590 The TEEP Agent sends this error message when it fails to verify 591 the signature of the message. 593 ERR_UNSUPPORTED_MSG_VERSION (4) 594 The TEEP Agent receives a message but does not support the 595 indicated version. 597 ERR_UNSUPPORTED_CRYPTO_ALG (5) 598 The TEEP Agent receives a request message encoded with an 599 unsupported cryptographic algorithm. 601 ERR_BAD_CERTIFICATE (6) 602 The TEEP Agent returns this error when processing of a certificate 603 failed. For diagnosis purposes it is RECOMMMENDED to include 604 information about the failing certificate in the error message. 606 ERR_UNSUPPORTED_CERTIFICATE (7) 607 The TEEP Agent returns this error when a certificate was of an 608 unsupported type. 610 ERR_CERTIFICATE_REVOKED (8) 611 The TEEP Agent returns this error when a certificate was revoked 612 by its signer. 614 ERR_CERTIFICATE_EXPIRED (9) 615 The TEEP Agent returns this error when a certificate has expired 616 or is not currently valid. 618 ERR_INTERNAL_ERROR (10) 619 The TEEP Agent returns this error when a miscellaneous internal 620 error occurred while processing the request. 622 ERR_RESOURCE_FULL (11) 623 This error is reported when a device resource isn't available 624 anymore, such as storage space is full. 626 ERR_TA_NOT_FOUND (12) 627 This error will occur when the target TA does not exist. This 628 error may happen when the TAM has stale information and tries to 629 delete a TA that has already been deleted. 631 ERR_TA_ALREADY_INSTALLED (13) 632 While installing a TA, a TEE will return this error if the TA has 633 already been installed. 635 ERR_TA_UNKNOWN_FORMAT (14) 636 The TEEP Agent returns this error when it does not recognize the 637 format of the TA binary. 639 ERR_TA_DECRYPTION_FAILED (15) 640 The TEEP Agent returns this error when it fails to decrypt the TA 641 binary. 643 ERR_TA_DECOMPRESSION_FAILED (16) 644 The TEEP Agent returns this error when it fails to decompress the 645 TA binary. 647 ERR_MANIFEST_PROCESSING_FAILED (17) 648 The TEEP Agent returns this error when manifest processing 649 failures occur that are less specific than ERR_TA_UNKNOWN_FORMAT, 650 ERR_TA_UNKNOWN_FORMAT, and ERR_TA_DECOMPRESSION_FAILED. 652 ERR_PD_PROCESSING_FAILED (18) 653 The TEEP Agent returns this error when it fails to process the 654 provided personalization data. 656 Additional error code can be registered with IANA. 658 5. Mapping of TEEP Message Parameters to CBOR Labels 660 In COSE, arrays and maps use strings, negative integers, and unsigned 661 integers as their keys. Integers are used for compactness of 662 encoding. Since the word "key" is mainly used in its other meaning, 663 as a cryptographic key, this specification uses the term "label" for 664 this usage as a map key. 666 This specification uses the following mapping: 668 +-----------------------+-------+ 669 | Name | Label | 670 +-----------------------+-------+ 671 | cipher-suites | 1 | 672 | nonce | 2 | 673 | version | 3 | 674 | ocsp-data | 4 | 675 | selected-cipher-suite | 5 | 676 | selected-version | 6 | 677 | eat | 7 | 678 | ta-list | 8 | 679 | ext-list | 9 | 680 | manifest-list | 10 | 681 | msg | 11 | 682 | err-msg | 12 | 683 +-----------------------+-------+ 685 6. Ciphersuites 687 A ciphersuite consists of an AEAD algorithm, a HMAC algorithm, and a 688 signature algorithm. Each ciphersuite is identified with an integer 689 value, which corresponds to an IANA registered ciphersuite. This 690 document specifies two ciphersuites. 692 +-------+------------------------------------------------+ 693 | Value | Ciphersuite | 694 +-------+------------------------------------------------+ 695 | 1 | AES-CCM-16-64-128, HMAC 256/256, X25519, EdDSA | 696 | 2 | AES-CCM-16-64-128, HMAC 256/256, P-256, ES256 | 697 +-------+------------------------------------------------+ 699 7. Security Considerations 701 This section summarizes the security considerations discussed in this 702 specification: 704 Cryptographic Algorithms 705 TEEP protocol messages exchanged between the TAM and the TEEP 706 Agent are protected using COSE. This specification relies on the 707 cryptographic algorithms provided by COSE. Public key based 708 authentication is used to by the TEEP Agent to authenticate the 709 TAM and vice versa. 711 Attestation 712 A TAM may rely on the attestation information provided by the TEEP 713 Agent and the Entity Attestation Token is re-used to convey this 714 information. To sign the Entity Attestation Token it is necessary 715 for the device to possess a public key (usually in the form of a 716 certificate) along with the corresponding private key. Depending 717 on the properties of the attestation mechanism it is possible to 718 uniquely identify a device based on information in the attestation 719 information or in the certificate used to sign the attestation 720 token. This uniqueness may raise privacy concerns. To lower the 721 privacy implications the TEEP Agent MUST present its attestation 722 information only to an authenticated and authorized TAM. 724 TA Binaries 725 TA binaries are provided by the SP. It is the responsibility of 726 the TAM to relay only verified TAs from authorized SPs. Delivery 727 of that TA to the TEEP Agent is then the responsibility of the TAM 728 and the TEEP Broker, using the security mechanisms provided by the 729 TEEP protocol. To protect the TA binary the SUIT manifest is re- 730 used and it offers a varity of security features, including 731 digitial signatures and symmetric encryption. 733 Personalization Data 734 An SP or a TAM can supply personalization data along with a TA. 735 This data is also protected by a SUIT manifest. The 736 personalization data may be opaque to the TAM. 738 TEEP Broker 739 The TEEP protocol relies on the TEEP Broker to relay messages 740 between the TAM and the TEEP Agent. When the TEEP Broker is 741 compromised it can drop messages, delay the delivery of messages, 742 and replay messages but it cannot modify those messages. (A 743 replay would be, however, detected by the TEEP Agent.) A 744 compromised TEEP Broker could reorder messages in an attempt to 745 install an old version of a TA. Information in the manifest 746 ensures that the TEEP Agents are protected against such 747 downgrading attacks based on features offered by the manifest 748 itself. 750 CA Compromise 751 The QueryRequest message from a TAM to the TEEP Agent may include 752 OCSP stapling data for the TAM's signer certificate and for 753 intermediate CA certificates up to the root certificate so that 754 the TEEP Agent can verify the certificate's revocation status. A 755 certificate revocation status check on a TA signer certificate is 756 OPTIONAL by a TEEP Agent. A TAM is responsible for vetting a TA 757 and before distributing them to TEEP Agents. TEEP Agents will 758 trust a TA signer certificate's validation status done by a TAM. 760 CA Compromise 761 The CA issuing certificates to a TAM or an SP may get compromised. 762 A compromised intermediate CA certificates can be detected by a 763 TEEP Agent by using OCSP information, assuming the revocation 764 information is available. Additionally, it is RECOMMENDED to 765 provide a way to update the trust anchor store used by the device, 766 for example using a firmware update mechanism. If the CA issuing 767 certificates to devices gets compromised then these devices might 768 be rejected by a TAM, if revocation is available to the TAM. 770 Compromised TAM 771 The TEEP Agent SHOULD use OCSP information to verify the validity 772 of the TAM-provided certificate (as well as the validity of 773 intermediate CA certificates). The integrity and the accuracy of 774 the clock within the TEE determines the ability to determine an 775 expired or revoked certificate since OCSP stapling includes 776 signature generation time, certificate validity dates are compared 777 to the current time. 779 8. IANA Considerations 781 8.1. Media Type Registration 783 IANA is requested to assign a media type for application/teep+cbor. 785 Type name: application 786 Subtype name: teep+cbor 788 Required parameters: none 790 Optional parameters: none 792 Encoding considerations: Same as encoding considerations of 793 application/cbor 795 Security considerations: See Security Considerations Section of this 796 document. 798 Interoperability considerations: Same as interoperability 799 considerations of application/cbor as specified in [RFC7049] 801 Published specification: This document. 803 Applications that use this media type: TEEP protocol implementations 805 Fragment identifier considerations: N/A 807 Additional information: 809 Deprecated alias names for this type: N/A 811 Magic number(s): N/A 813 File extension(s): N/A 815 Macintosh file type code(s): N/A 817 Person to contact for further information: teep@ietf.org 819 Intended usage: COMMON 821 Restrictions on usage: none 823 Author: See the "Authors' Addresses" section of this document 825 Change controller: IETF 827 8.2. Error Code Registry 829 IANA is also requested to create a new registry for the error codes 830 defined in Section 4. 832 Registration requests are evaluated after a three-week review period 833 on the teep-reg-review@ietf.org mailing list, on the advice of one or 834 more Designated Experts [RFC8126]. However, to allow for the 835 allocation of values prior to publication, the Designated Experts may 836 approve registration once they are satisfied that such a 837 specification will be published. 839 Registration requests sent to the mailing list for review should use 840 an appropriate subject (e.g., "Request to register an error code: 841 example"). Registration requests that are undetermined for a period 842 longer than 21 days can be brought to the IESG's attention (using the 843 iesg@ietf.org mailing list) for resolution. 845 Criteria that should be applied by the Designated Experts includes 846 determining whether the proposed registration duplicates existing 847 functionality, whether it is likely to be of general applicability or 848 whether it is useful only for a single extension, and whether the 849 registration description is clear. 851 IANA must only accept registry updates from the Designated Experts 852 and should direct all requests for registration to the review mailing 853 list. 855 8.3. Ciphersuite Registry 857 IANA is also requested to create a new registry for ciphersuites, as 858 defined in Section 6. 860 8.4. CBOR Tag Registry 862 IANA is requested to register a CBOR tag in the "CBOR Tags" registry 863 for use with TEEP messages. 865 The registry contents is: 867 o CBOR Tag: TBD1 869 o Data Item: TEEP Message 871 o Semantics: TEEP Message, as defined in [[TBD: This RFC]] 873 o Reference: [[TBD: This RFC]] 875 o Point of Contact: TEEP working group (teep@ietf.org) 877 9. References 878 9.1. Normative References 880 [I-D.ietf-rats-eat] 881 Mandyam, G., Lundblade, L., Ballesteros, M., and J. 882 O'Donoghue, "The Entity Attestation Token (EAT)", draft- 883 ietf-rats-eat-03 (work in progress), February 2020. 885 [I-D.ietf-suit-manifest] 886 Moran, B., Tschofenig, H., Birkholz, H., and K. Zandberg, 887 "A Concise Binary Object Representation (CBOR)-based 888 Serialization Format for the Software Updates for Internet 889 of Things (SUIT) Manifest", draft-ietf-suit-manifest-04 890 (work in progress), March 2020. 892 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 893 Requirement Levels", BCP 14, RFC 2119, 894 DOI 10.17487/RFC2119, March 1997, 895 . 897 [RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. 898 Adams, "X.509 Internet Public Key Infrastructure Online 899 Certificate Status Protocol - OCSP", RFC 2560, 900 DOI 10.17487/RFC2560, June 1999, 901 . 903 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 904 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 905 2003, . 907 [RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network 908 Interchange", RFC 5198, DOI 10.17487/RFC5198, March 2008, 909 . 911 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 912 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 913 October 2013, . 915 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 916 RFC 8152, DOI 10.17487/RFC8152, July 2017, 917 . 919 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 920 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 921 May 2017, . 923 9.2. Informative References 925 [I-D.ietf-teep-architecture] 926 Pei, M., Tschofenig, H., Thaler, D., and D. Wheeler, 927 "Trusted Execution Environment Provisioning (TEEP) 928 Architecture", draft-ietf-teep-architecture-08 (work in 929 progress), April 2020. 931 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 932 Writing an IANA Considerations Section in RFCs", BCP 26, 933 RFC 8126, DOI 10.17487/RFC8126, June 2017, 934 . 936 [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data 937 Definition Language (CDDL): A Notational Convention to 938 Express Concise Binary Object Representation (CBOR) and 939 JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, 940 June 2019, . 942 A. Contributors 944 We would like to thank Brian Witten (Symantec), Tyler Kim (Solacia), 945 Nick Cook (Arm), and Minho Yoo (IoTrust) for their contributions to 946 the Open Trust Protocol (OTrP), which influenced the design of this 947 specification. 949 B. Acknowledgements 951 We would like to thank Eve Schooler for the suggestion of the 952 protocol name. 954 We would like to thank Kohei Isobe (TRASIO/SECOM), Kuniyasu Suzaki 955 (TRASIO/AIST), Tsukasa Oi (TRASIO), and Yuichi Takita (SECOM) for 956 their valuable implementation feedback. 958 We would also like to thank Carsten Bormann and Henk Birkholz for 959 their help with the CDDL. 961 C. Complete CDDL 963 teep-message = $teep-message-type .within teep-message-framework 965 SUIT-envelope = bstr ; placeholder 967 teep-message-framework = [ 968 type: 0..23 / $teep-type-extension, 969 token: uint, 970 options: { * teep-option }, 971 * int; further integers, e.g. for data-item-requested 972 ] 974 teep-option = (uint => any) 976 ; messages defined below: 977 $teep-message-type /= query-request 978 $teep-message-type /= query-response 979 $teep-message-type /= trusted-app-install 980 $teep-message-type /= trusted-app-delete 981 $teep-message-type /= teep-error 982 $teep-message-type /= teep-success 984 ; message type numbers 985 TEEP-TYPE-query-request = 1 986 TEEP-TYPE-query-response = 2 987 TEEP-TYPE-trusted-app-install = 3 988 TEEP-TYPE-trusted-app-delete = 4 989 TEEP-TYPE-teep-error = 5 990 TEEP-TYPE-teep-success = 6 992 version = uint .size 4 993 ext-info = uint 995 ; data items as bitmaps 996 data-item-requested = $data-item-requested .within uint .size 8 997 attestation = 1 998 $data-item-requested /= attestation 999 trusted-apps = 2 1000 $data-item-requested /= trusted-apps 1001 extensions = 4 1002 $data-item-requested /= extensions 1003 suit-commands = 8 1004 $data-item-requested /= suit-commands 1006 query-request = [ 1007 type: TEEP-TYPE-query-request, 1008 token: uint, 1009 options: { 1010 ? supported-cipher-suites => suite, 1011 ? nonce => bstr .size (8..64), 1012 ? version => [ + version ], 1013 ? oscp-data => bstr, 1014 * $$query-request-extensions 1015 * $$teep-option-extensions 1016 }, 1017 data-item-requested 1018 ] 1019 ; ciphersuites as bitmaps 1020 suite = $TEEP-suite .within uint .size 8 1022 TEEP-AES-CCM-16-64-128-HMAC256--256-X25519-EdDSA = 1 1023 TEEP-AES-CCM-16-64-128-HMAC256--256-P-256-ES256 = 2 1025 $TEEP-suite /= TEEP-AES-CCM-16-64-128-HMAC256--256-X25519-EdDSA 1026 $TEEP-suite /= TEEP-AES-CCM-16-64-128-HMAC256--256-P-256-ES256 1028 query-response = [ 1029 type: TEEP-TYPE-query-response, 1030 token: uint, 1031 options: { 1032 ? selected-cipher-suite => suite, 1033 ? selected-version => version, 1034 ? eat => bstr, 1035 ? ta-list => [ + bstr ], 1036 ? ext-list => [ + ext-info ], 1037 * $$query-response-extensions, 1038 * $$teep-option-extensions 1039 } 1040 ] 1042 trusted-app-install = [ 1043 type: TEEP-TYPE-trusted-app-install, 1044 token: uint, 1045 option: { 1046 ? manifest-list => [ + SUIT-envelope ], 1047 * $$trusted-app-install-extensions, 1048 * $$teep-option-extensions 1049 } 1050 ] 1052 trusted-app-delete = [ 1053 type: TEEP-TYPE-trusted-app-delete, 1054 token: uint, 1055 option: { 1056 ? ta-list => [ + bstr ], 1057 * $$trusted-app-delete-extensions, 1058 * $$teep-option-extensions 1059 } 1060 ] 1062 teep-success = [ 1063 type: TEEP-TYPE-teep-success, 1064 token: uint, 1065 option: { 1066 ? msg => text, 1067 * $$teep-success-extensions, 1068 * $$teep-option-extensions 1069 } 1070 ] 1072 teep-error = [ 1073 type: TEEP-TYPE-teep-error, 1074 token: uint, 1075 options: { 1076 ? err-msg => text, 1077 ? cipher-suites => [ + suite ], 1078 ? versions => [ + version ], 1079 * $$teep-error--extensions, 1080 * $$teep-option-extensions 1081 } 1082 err-code: uint, 1083 ] 1085 cipher-suites = 1 1086 nonce = 2 1087 versions = 3 1088 oscp-data = 4 1089 selected-cipher-suite = 5 1090 selected-version = 6 1091 eat = 7 1092 ta-list = 8 1093 ext-list = 9 1094 manifest-list = 10 1095 msg = 11 1096 err-msg = 12 1098 Authors' Addresses 1100 Hannes Tschofenig 1101 Arm Ltd. 1102 Absam, Tirol 6067 1103 Austria 1105 Email: hannes.tschofenig@arm.com 1107 Mingliang Pei 1108 Broadcom 1109 350 Ellis St 1110 Mountain View, CA 94043 1111 USA 1113 Email: mingliang.pei@broadcom.com 1114 David Wheeler 1115 Intel 1116 US 1118 Email: david.m.wheeler@intel.com 1120 Dave Thaler 1121 Microsoft 1122 US 1124 Email: dthaler@microsoft.com 1126 Akira Tsukamoto 1127 AIST 1128 JP 1130 Email: akira.tsukamoto@aist.go.jp