idnits 2.17.1 draft-ietf-teep-protocol-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 : ---------------------------------------------------------------------------- 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 (July 13, 2020) is 1376 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 (-25) exists of draft-ietf-rats-eat-03 ** Obsolete normative reference: RFC 2560 (Obsoleted by RFC 6960) ** Obsolete normative reference: RFC 7049 (Obsoleted by RFC 8949) ** Obsolete normative reference: RFC 8152 (Obsoleted by RFC 9052, RFC 9053) == Outdated reference: A later version (-19) exists of draft-ietf-teep-architecture-11 Summary: 3 errors (**), 0 flaws (~~), 4 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: January 14, 2021 Broadcom 6 D. Wheeler 7 Intel 8 D. Thaler 9 Microsoft 10 A. Tsukamoto 11 AIST 12 July 13, 2020 14 Trusted Execution Environment Provisioning (TEEP) Protocol 15 draft-ietf-teep-protocol-03 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 http://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 January 14, 2021. 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 (http://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 . . . . . . . . . . . . . . . . . . . . . 18 79 8.1. Media Type Registration . . . . . . . . . . . . . . . . . 18 80 8.2. Error Code Registry . . . . . . . . . . . . . . . . . . . 19 81 8.3. Ciphersuite Registry . . . . . . . . . . . . . . . . . . 19 82 8.4. CBOR Tag Registry . . . . . . . . . . . . . . . . . . . . 19 83 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 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 and SHOULD 723 use encryption in EATs as discussed in [I-D.ietf-rats-eat] since 724 confidentiality is not provided by the TEEP protocol itself, and 725 the transport protocol under the TEEP protocol might be 726 implemented outside of any TEE. 728 TA Binaries 729 TA binaries are provided by the SP. It is the responsibility of 730 the TAM to relay only verified TAs from authorized SPs. Delivery 731 of that TA to the TEEP Agent is then the responsibility of the TAM 732 and the TEEP Broker, using the security mechanisms provided by the 733 TEEP protocol. To protect the TA binary the SUIT manifest is re- 734 used and it offers a varity of security features, including 735 digitial signatures and symmetric encryption. 737 Personalization Data 738 An SP or a TAM can supply personalization data along with a TA. 739 This data is also protected by a SUIT manifest. The 740 personalization data may be opaque to the TAM. 742 TEEP Broker 743 The TEEP protocol relies on the TEEP Broker to relay messages 744 between the TAM and the TEEP Agent. When the TEEP Broker is 745 compromised it can drop messages, delay the delivery of messages, 746 and replay messages but it cannot modify those messages. (A 747 replay would be, however, detected by the TEEP Agent.) A 748 compromised TEEP Broker could reorder messages in an attempt to 749 install an old version of a TA. Information in the manifest 750 ensures that the TEEP Agents are protected against such 751 downgrading attacks based on features offered by the manifest 752 itself. 754 CA Compromise 755 The QueryRequest message from a TAM to the TEEP Agent may include 756 OCSP stapling data for the TAM's signer certificate and for 757 intermediate CA certificates up to the root certificate so that 758 the TEEP Agent can verify the certificate's revocation status. A 759 certificate revocation status check on a TA signer certificate is 760 OPTIONAL by a TEEP Agent. A TAM is responsible for vetting a TA 761 and before distributing them to TEEP Agents. TEEP Agents will 762 trust a TA signer certificate's validation status done by a TAM. 764 CA Compromise 765 The CA issuing certificates to a TAM or an SP may get compromised. 766 A compromised intermediate CA certificates can be detected by a 767 TEEP Agent by using OCSP information, assuming the revocation 768 information is available. Additionally, it is RECOMMENDED to 769 provide a way to update the trust anchor store used by the device, 770 for example using a firmware update mechanism. If the CA issuing 771 certificates to devices gets compromised then these devices might 772 be rejected by a TAM, if revocation is available to the TAM. 774 Compromised TAM 775 The TEEP Agent SHOULD use OCSP information to verify the validity 776 of the TAM-provided certificate (as well as the validity of 777 intermediate CA certificates). The integrity and the accuracy of 778 the clock within the TEE determines the ability to determine an 779 expired or revoked certificate since OCSP stapling includes 780 signature generation time, certificate validity dates are compared 781 to the current time. 783 8. IANA Considerations 785 8.1. Media Type Registration 787 IANA is requested to assign a media type for application/teep+cbor. 789 Type name: application 791 Subtype name: teep+cbor 793 Required parameters: none 795 Optional parameters: none 797 Encoding considerations: Same as encoding considerations of 798 application/cbor 800 Security considerations: See Security Considerations Section of this 801 document. 803 Interoperability considerations: Same as interoperability 804 considerations of application/cbor as specified in [RFC7049] 806 Published specification: This document. 808 Applications that use this media type: TEEP protocol implementations 810 Fragment identifier considerations: N/A 812 Additional information: 814 Deprecated alias names for this type: N/A 816 Magic number(s): N/A 818 File extension(s): N/A 820 Macintosh file type code(s): N/A 822 Person to contact for further information: teep@ietf.org 824 Intended usage: COMMON 826 Restrictions on usage: none 828 Author: See the "Authors' Addresses" section of this document 830 Change controller: IETF 832 8.2. Error Code Registry 834 IANA is also requested to create a new registry for the error codes 835 defined in Section 4. 837 Registration requests are evaluated after a three-week review period 838 on the teep-reg-review@ietf.org mailing list, on the advice of one or 839 more Designated Experts [RFC8126]. However, to allow for the 840 allocation of values prior to publication, the Designated Experts may 841 approve registration once they are satisfied that such a 842 specification will be published. 844 Registration requests sent to the mailing list for review should use 845 an appropriate subject (e.g., "Request to register an error code: 846 example"). Registration requests that are undetermined for a period 847 longer than 21 days can be brought to the IESG's attention (using the 848 iesg@ietf.org mailing list) for resolution. 850 Criteria that should be applied by the Designated Experts includes 851 determining whether the proposed registration duplicates existing 852 functionality, whether it is likely to be of general applicability or 853 whether it is useful only for a single extension, and whether the 854 registration description is clear. 856 IANA must only accept registry updates from the Designated Experts 857 and should direct all requests for registration to the review mailing 858 list. 860 8.3. Ciphersuite Registry 862 IANA is also requested to create a new registry for ciphersuites, as 863 defined in Section 6. 865 8.4. CBOR Tag Registry 867 IANA is requested to register a CBOR tag in the "CBOR Tags" registry 868 for use with TEEP messages. 870 The registry contents is: 872 o CBOR Tag: TBD1 874 o Data Item: TEEP Message 876 o Semantics: TEEP Message, as defined in [[TBD: This RFC]] 878 o Reference: [[TBD: This RFC]] 879 o Point of Contact: TEEP working group (teep@ietf.org) 881 9. References 883 9.1. Normative References 885 [I-D.ietf-rats-eat] 886 Mandyam, G., Lundblade, L., Ballesteros, M., and J. 887 O'Donoghue, "The Entity Attestation Token (EAT)", draft- 888 ietf-rats-eat-03 (work in progress), February 2020. 890 [I-D.ietf-suit-manifest] 891 Moran, B., Tschofenig, H., Birkholz, H., and K. Zandberg, 892 "A Concise Binary Object Representation (CBOR)-based 893 Serialization Format for the Software Updates for Internet 894 of Things (SUIT) Manifest", draft-ietf-suit-manifest-08 895 (work in progress), July 2020. 897 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 898 Requirement Levels", BCP 14, RFC 2119, 899 DOI 10.17487/RFC2119, March 1997, . 902 [RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. 903 Adams, "X.509 Internet Public Key Infrastructure Online 904 Certificate Status Protocol - OCSP", RFC 2560, 905 DOI 10.17487/RFC2560, June 1999, . 908 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 909 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 910 2003, . 912 [RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network 913 Interchange", RFC 5198, DOI 10.17487/RFC5198, March 2008, 914 . 916 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 917 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 918 October 2013, . 920 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 921 RFC 8152, DOI 10.17487/RFC8152, July 2017, 922 . 924 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 925 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 926 May 2017, . 928 9.2. Informative References 930 [I-D.ietf-teep-architecture] 931 Pei, M., Tschofenig, H., Thaler, D., and D. Wheeler, 932 "Trusted Execution Environment Provisioning (TEEP) 933 Architecture", draft-ietf-teep-architecture-11 (work in 934 progress), July 2020. 936 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 937 Writing an IANA Considerations Section in RFCs", BCP 26, 938 RFC 8126, DOI 10.17487/RFC8126, June 2017, 939 . 941 [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data 942 Definition Language (CDDL): A Notational Convention to 943 Express Concise Binary Object Representation (CBOR) and 944 JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, 945 June 2019, . 947 A. Contributors 949 We would like to thank Brian Witten (Symantec), Tyler Kim (Solacia), 950 Nick Cook (Arm), and Minho Yoo (IoTrust) for their contributions to 951 the Open Trust Protocol (OTrP), which influenced the design of this 952 specification. 954 B. Acknowledgements 956 We would like to thank Eve Schooler for the suggestion of the 957 protocol name. 959 We would like to thank Kohei Isobe (TRASIO/SECOM), Kuniyasu Suzaki 960 (TRASIO/AIST), Tsukasa Oi (TRASIO), and Yuichi Takita (SECOM) for 961 their valuable implementation feedback. 963 We would also like to thank Carsten Bormann and Henk Birkholz for 964 their help with the CDDL. 966 C. Complete CDDL 968 Valid TEEP messages MUST adhere to the following CDDL data 969 definitions, except that "SUIT_Envelope" is specified in 970 [I-D.ietf-suit-manifest]. 972 teep-message = $teep-message-type .within teep-message-framework 974 SUIT_Envelope = any 975 teep-message-framework = [ 976 type: 0..23 / $teep-type-extension, 977 token: uint, 978 options: { * teep-option }, 979 * int; further integers, e.g. for data-item-requested 980 ] 982 teep-option = (uint => any) 984 ; messages defined below: 985 $teep-message-type /= query-request 986 $teep-message-type /= query-response 987 $teep-message-type /= trusted-app-install 988 $teep-message-type /= trusted-app-delete 989 $teep-message-type /= teep-error 990 $teep-message-type /= teep-success 992 ; message type numbers 993 TEEP-TYPE-query-request = 1 994 TEEP-TYPE-query-response = 2 995 TEEP-TYPE-trusted-app-install = 3 996 TEEP-TYPE-trusted-app-delete = 4 997 TEEP-TYPE-teep-success = 5 998 TEEP-TYPE-teep-error = 6 1000 version = uint .size 4 1001 ext-info = uint 1003 ; data items as bitmaps 1004 data-item-requested = $data-item-requested .within uint .size 8 1005 attestation = 1 1006 $data-item-requested /= attestation 1007 trusted-apps = 2 1008 $data-item-requested /= trusted-apps 1009 extensions = 4 1010 $data-item-requested /= extensions 1011 suit-commands = 8 1012 $data-item-requested /= suit-commands 1014 query-request = [ 1015 type: TEEP-TYPE-query-request, 1016 token: uint, 1017 options: { 1018 ? supported-cipher-suites => suite, 1019 ? nonce => bstr .size (8..64), 1020 ? version => [ + version ], 1021 ? oscp-data => bstr, 1022 * $$query-request-extensions 1023 * $$teep-option-extensions 1024 }, 1025 data-item-requested 1026 ] 1028 ; ciphersuites as bitmaps 1029 suite = $TEEP-suite .within uint .size 8 1031 TEEP-AES-CCM-16-64-128-HMAC256--256-X25519-EdDSA = 1 1032 TEEP-AES-CCM-16-64-128-HMAC256--256-P-256-ES256 = 2 1034 $TEEP-suite /= TEEP-AES-CCM-16-64-128-HMAC256--256-X25519-EdDSA 1035 $TEEP-suite /= TEEP-AES-CCM-16-64-128-HMAC256--256-P-256-ES256 1037 query-response = [ 1038 type: TEEP-TYPE-query-response, 1039 token: uint, 1040 options: { 1041 ? selected-cipher-suite => suite, 1042 ? selected-version => version, 1043 ? eat => bstr, 1044 ? ta-list => [ + bstr ], 1045 ? ext-list => [ + ext-info ], 1046 * $$query-response-extensions, 1047 * $$teep-option-extensions 1048 } 1049 ] 1051 trusted-app-install = [ 1052 type: TEEP-TYPE-trusted-app-install, 1053 token: uint, 1054 option: { 1055 ? manifest-list => [ + SUIT_Envelope ], 1056 * $$trusted-app-install-extensions, 1057 * $$teep-option-extensions 1058 } 1059 ] 1061 trusted-app-delete = [ 1062 type: TEEP-TYPE-trusted-app-delete, 1063 token: uint, 1064 option: { 1065 ? ta-list => [ + bstr ], 1066 * $$trusted-app-delete-extensions, 1067 * $$teep-option-extensions 1068 } 1069 ] 1070 teep-success = [ 1071 type: TEEP-TYPE-teep-success, 1072 token: uint, 1073 option: { 1074 ? msg => text, 1075 * $$teep-success-extensions, 1076 * $$teep-option-extensions 1077 } 1078 ] 1080 teep-error = [ 1081 type: TEEP-TYPE-teep-error, 1082 token: uint, 1083 options: { 1084 ? err-msg => text, 1085 ? cipher-suites => [ + suite ], 1086 ? versions => [ + version ], 1087 * $$teep-error--extensions, 1088 * $$teep-option-extensions 1089 } 1090 err-code: uint, 1091 ] 1093 cipher-suites = 1 1094 nonce = 2 1095 versions = 3 1096 oscp-data = 4 1097 selected-cipher-suite = 5 1098 selected-version = 6 1099 eat = 7 1100 ta-list = 8 1101 ext-list = 9 1102 manifest-list = 10 1103 msg = 11 1104 err-msg = 12 1106 Authors' Addresses 1108 Hannes Tschofenig 1109 Arm Ltd. 1110 Absam, Tirol 6067 1111 Austria 1113 Email: hannes.tschofenig@arm.com 1114 Mingliang Pei 1115 Broadcom 1116 350 Ellis St 1117 Mountain View, CA 94043 1118 USA 1120 Email: mingliang.pei@broadcom.com 1122 David Wheeler 1123 Intel 1124 US 1126 Email: david.m.wheeler@intel.com 1128 Dave Thaler 1129 Microsoft 1130 US 1132 Email: dthaler@microsoft.com 1134 Akira Tsukamoto 1135 AIST 1136 JP 1138 Email: akira.tsukamoto@aist.go.jp