--- 1/draft-ietf-teep-protocol-02.txt 2020-07-13 17:14:08.552700632 -0700 +++ 2/draft-ietf-teep-protocol-03.txt 2020-07-13 17:14:08.596701753 -0700 @@ -1,62 +1,62 @@ TEEP H. Tschofenig Internet-Draft Arm Ltd. Intended status: Standards Track M. Pei -Expires: October 16, 2020 Broadcom +Expires: January 14, 2021 Broadcom D. Wheeler Intel D. Thaler Microsoft A. Tsukamoto AIST - April 14, 2020 + July 13, 2020 Trusted Execution Environment Provisioning (TEEP) Protocol - draft-ietf-teep-protocol-02 + draft-ietf-teep-protocol-03 Abstract This document specifies a protocol that installs, updates, and deletes Trusted Applications (TAs) in a device with a Trusted Execution Environment (TEE). This specification defines an interoperable protocol for managing the lifecycle of TAs. The protocol name is pronounced teepee. This conjures an image of a wedge-shaped protective covering for one's belongings, which sort of matches the intent of this protocol. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- - Drafts is at https://datatracker.ietf.org/drafts/current/. + Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on October 16, 2020. + This Internet-Draft will expire on January 14, 2021. Copyright Notice Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents - (https://trustee.ietf.org/license-info) in effect on the date of + (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 @@ -68,26 +68,26 @@ 4.1.2. Validating a TEEP Message . . . . . . . . . . . . . . 6 4.2. QueryRequest . . . . . . . . . . . . . . . . . . . . . . 6 4.3. QueryResponse . . . . . . . . . . . . . . . . . . . . . . 8 4.4. TrustedAppInstall . . . . . . . . . . . . . . . . . . . . 10 4.5. TrustedAppDelete . . . . . . . . . . . . . . . . . . . . 11 4.6. Success . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.7. Error . . . . . . . . . . . . . . . . . . . . . . . . . . 12 5. Mapping of TEEP Message Parameters to CBOR Labels . . . . . . 15 6. Ciphersuites . . . . . . . . . . . . . . . . . . . . . . . . 15 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 - 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 - 8.1. Media Type Registration . . . . . . . . . . . . . . . . . 17 - 8.2. Error Code Registry . . . . . . . . . . . . . . . . . . . 18 + 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 + 8.1. Media Type Registration . . . . . . . . . . . . . . . . . 18 + 8.2. Error Code Registry . . . . . . . . . . . . . . . . . . . 19 8.3. Ciphersuite Registry . . . . . . . . . . . . . . . . . . 19 8.4. CBOR Tag Registry . . . . . . . . . . . . . . . . . . . . 19 - 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 9.1. Normative References . . . . . . . . . . . . . . . . . . 20 9.2. Informative References . . . . . . . . . . . . . . . . . 21 A. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 21 B. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 C. Complete CDDL . . . . . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 1. Introduction The Trusted Execution Environment (TEE) concept has been designed to @@ -416,21 +416,21 @@ (trusted apps) via the TEEP Agent. Like other TEEP messages, the TrustedAppInstall message is signed, and the relevant CDDL snippet is shown below. The complete CDDL structure is shown in [CDDL]. trusted-app-install = [ type: TEEP-TYPE-trusted-app-install, token: uint, option: { - ? manifest-list => [ + SUIT-envelope ], + ? manifest-list => [ + SUIT_Envelope ], * $$trusted-app-install-extensions, * $$teep-option-extensions } ] The TrustedAppInstall message has the following fields: type The value of (3) corresponds to a TrustedAppInstall message sent from the TAM to the TEEP Agent. In case of successful processing, @@ -712,21 +712,25 @@ A TAM may rely on the attestation information provided by the TEEP Agent and the Entity Attestation Token is re-used to convey this information. To sign the Entity Attestation Token it is necessary for the device to possess a public key (usually in the form of a certificate) along with the corresponding private key. Depending on the properties of the attestation mechanism it is possible to uniquely identify a device based on information in the attestation information or in the certificate used to sign the attestation token. This uniqueness may raise privacy concerns. To lower the privacy implications the TEEP Agent MUST present its attestation - information only to an authenticated and authorized TAM. + information only to an authenticated and authorized TAM and SHOULD + use encryption in EATs as discussed in [I-D.ietf-rats-eat] since + confidentiality is not provided by the TEEP protocol itself, and + the transport protocol under the TEEP protocol might be + implemented outside of any TEE. TA Binaries TA binaries are provided by the SP. It is the responsibility of the TAM to relay only verified TAs from authorized SPs. Delivery of that TA to the TEEP Agent is then the responsibility of the TAM and the TEEP Broker, using the security mechanisms provided by the TEEP protocol. To protect the TA binary the SUIT manifest is re- used and it offers a varity of security features, including digitial signatures and symmetric encryption. @@ -879,33 +884,33 @@ [I-D.ietf-rats-eat] Mandyam, G., Lundblade, L., Ballesteros, M., and J. O'Donoghue, "The Entity Attestation Token (EAT)", draft- ietf-rats-eat-03 (work in progress), February 2020. [I-D.ietf-suit-manifest] Moran, B., Tschofenig, H., Birkholz, H., and K. Zandberg, "A Concise Binary Object Representation (CBOR)-based Serialization Format for the Software Updates for Internet - of Things (SUIT) Manifest", draft-ietf-suit-manifest-04 - (work in progress), March 2020. + of Things (SUIT) Manifest", draft-ietf-suit-manifest-08 + (work in progress), July 2020. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, - DOI 10.17487/RFC2119, March 1997, - . + DOI 10.17487/RFC2119, March 1997, . [RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", RFC 2560, - DOI 10.17487/RFC2560, June 1999, - . + DOI 10.17487/RFC2560, June 1999, . [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, . [RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network Interchange", RFC 5198, DOI 10.17487/RFC5198, March 2008, . [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object @@ -918,22 +923,22 @@ [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 9.2. Informative References [I-D.ietf-teep-architecture] Pei, M., Tschofenig, H., Thaler, D., and D. Wheeler, "Trusted Execution Environment Provisioning (TEEP) - Architecture", draft-ietf-teep-architecture-08 (work in - progress), April 2020. + Architecture", draft-ietf-teep-architecture-11 (work in + progress), July 2020. [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, @@ -953,24 +958,27 @@ We would like to thank Kohei Isobe (TRASIO/SECOM), Kuniyasu Suzaki (TRASIO/AIST), Tsukasa Oi (TRASIO), and Yuichi Takita (SECOM) for their valuable implementation feedback. We would also like to thank Carsten Bormann and Henk Birkholz for their help with the CDDL. C. Complete CDDL - teep-message = $teep-message-type .within teep-message-framework + Valid TEEP messages MUST adhere to the following CDDL data + definitions, except that "SUIT_Envelope" is specified in + [I-D.ietf-suit-manifest]. - SUIT-envelope = bstr ; placeholder + teep-message = $teep-message-type .within teep-message-framework + SUIT_Envelope = any teep-message-framework = [ type: 0..23 / $teep-type-extension, token: uint, options: { * teep-option }, * int; further integers, e.g. for data-item-requested ] teep-option = (uint => any) ; messages defined below: @@ -979,22 +987,22 @@ $teep-message-type /= trusted-app-install $teep-message-type /= trusted-app-delete $teep-message-type /= teep-error $teep-message-type /= teep-success ; message type numbers TEEP-TYPE-query-request = 1 TEEP-TYPE-query-response = 2 TEEP-TYPE-trusted-app-install = 3 TEEP-TYPE-trusted-app-delete = 4 - TEEP-TYPE-teep-error = 5 - TEEP-TYPE-teep-success = 6 + TEEP-TYPE-teep-success = 5 + TEEP-TYPE-teep-error = 6 version = uint .size 4 ext-info = uint ; data items as bitmaps data-item-requested = $data-item-requested .within uint .size 8 attestation = 1 $data-item-requested /= attestation trusted-apps = 2 $data-item-requested /= trusted-apps @@ -1036,21 +1045,21 @@ ? ext-list => [ + ext-info ], * $$query-response-extensions, * $$teep-option-extensions } ] trusted-app-install = [ type: TEEP-TYPE-trusted-app-install, token: uint, option: { - ? manifest-list => [ + SUIT-envelope ], + ? manifest-list => [ + SUIT_Envelope ], * $$trusted-app-install-extensions, * $$teep-option-extensions } ] trusted-app-delete = [ type: TEEP-TYPE-trusted-app-delete, token: uint, option: { ? ta-list => [ + bstr ],