draft-ietf-teep-protocol-00.txt | draft-ietf-teep-protocol-01.txt | |||
---|---|---|---|---|
TEEP H. Tschofenig | TEEP H. Tschofenig | |||
Internet-Draft Arm Ltd. | Internet-Draft Arm Ltd. | |||
Intended status: Standards Track M. Pei | Intended status: Standards Track M. Pei | |||
Expires: June 9, 2020 Broadcom | Expires: September 10, 2020 Broadcom | |||
D. Wheeler | D. Wheeler | |||
Intel | Intel | |||
D. Thaler | D. Thaler | |||
Microsoft | Microsoft | |||
December 7, 2019 | March 9, 2020 | |||
Trusted Execution Environment Provisioning (TEEP) Protocol | Trusted Execution Environment Provisioning (TEEP) Protocol | |||
draft-ietf-teep-protocol-00 | draft-ietf-teep-protocol-01 | |||
Abstract | Abstract | |||
This document specifies a protocol that installs, updates, and | This document specifies a protocol that installs, updates, and | |||
deletes Trusted Applications (TAs) in a device with a Trusted | deletes Trusted Applications (TAs) in a device with a Trusted | |||
Execution Environment (TEE). This specification defines an | Execution Environment (TEE). This specification defines an | |||
interoperable protocol for managing the lifecycle of TAs. | interoperable protocol for managing the lifecycle of TAs. | |||
The protocol name is pronounced teepee. This conjures an image of a | The protocol name is pronounced teepee. This conjures an image of a | |||
wedge-shaped protective covering for one's belongings, which sort of | wedge-shaped protective covering for one's belongings, which sort of | |||
skipping to change at page 1, line 42 ¶ | skipping to change at page 1, line 42 ¶ | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
Drafts is at https://datatracker.ietf.org/drafts/current/. | Drafts is at https://datatracker.ietf.org/drafts/current/. | |||
Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
This Internet-Draft will expire on June 9, 2020. | This Internet-Draft will expire on September 10, 2020. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2019 IETF Trust and the persons identified as the | Copyright (c) 2020 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
(https://trustee.ietf.org/license-info) in effect on the date of | (https://trustee.ietf.org/license-info) in effect on the date of | |||
publication of this document. Please review these documents | publication of this document. Please review these documents | |||
carefully, as they describe your rights and restrictions with respect | carefully, as they describe your rights and restrictions with respect | |||
to this document. Code Components extracted from this document must | to this document. Code Components extracted from this document must | |||
include Simplified BSD License text as described in Section 4.e of | include Simplified BSD License text as described in Section 4.e of | |||
the Trust Legal Provisions and are provided without warranty as | the Trust Legal Provisions and are provided without warranty as | |||
described in the Simplified BSD License. | described in the Simplified BSD License. | |||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | |||
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 | 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 | |||
3. Message Overview . . . . . . . . . . . . . . . . . . . . . . 3 | 3. Message Overview . . . . . . . . . . . . . . . . . . . . . . 3 | |||
4. Detailed Messages Specification . . . . . . . . . . . . . . . 5 | 4. Detailed Messages Specification . . . . . . . . . . . . . . . 5 | |||
4.1. QueryRequest . . . . . . . . . . . . . . . . . . . . . . 5 | 4.1. QueryRequest . . . . . . . . . . . . . . . . . . . . . . 5 | |||
4.2. QueryResponse . . . . . . . . . . . . . . . . . . . . . . 7 | 4.2. QueryResponse . . . . . . . . . . . . . . . . . . . . . . 7 | |||
4.3. TrustedAppInstall . . . . . . . . . . . . . . . . . . . . 9 | 4.3. TrustedAppInstall . . . . . . . . . . . . . . . . . . . . 7 | |||
4.4. TrustedAppDelete . . . . . . . . . . . . . . . . . . . . 9 | 4.4. TrustedAppDelete . . . . . . . . . . . . . . . . . . . . 8 | |||
4.5. Success . . . . . . . . . . . . . . . . . . . . . . . . . 10 | 4.5. Success . . . . . . . . . . . . . . . . . . . . . . . . . 9 | |||
4.6. Error . . . . . . . . . . . . . . . . . . . . . . . . . . 10 | 4.6. Error . . . . . . . . . . . . . . . . . . . . . . . . . . 9 | |||
5. Ciphersuites . . . . . . . . . . . . . . . . . . . . . . . . 12 | 5. Ciphersuites . . . . . . . . . . . . . . . . . . . . . . . . 11 | |||
6. Security Consideration . . . . . . . . . . . . . . . . . . . 13 | 6. Security Consideration . . . . . . . . . . . . . . . . . . . 12 | |||
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 | 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 | |||
7.1. Media Type Registration . . . . . . . . . . . . . . . . . 14 | 7.1. Media Type Registration . . . . . . . . . . . . . . . . . 13 | |||
7.2. Error Code Registry . . . . . . . . . . . . . . . . . . . 16 | 7.2. Error Code Registry . . . . . . . . . . . . . . . . . . . 14 | |||
7.3. Ciphersuite Registry . . . . . . . . . . . . . . . . . . 17 | 7.3. Ciphersuite Registry . . . . . . . . . . . . . . . . . . 15 | |||
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 | 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 | |||
8.1. Normative References . . . . . . . . . . . . . . . . . . 17 | 8.1. Normative References . . . . . . . . . . . . . . . . . . 15 | |||
8.2. Informative References . . . . . . . . . . . . . . . . . 18 | 8.2. Informative References . . . . . . . . . . . . . . . . . 16 | |||
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 19 | Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 16 | |||
Appendix B. Contributors . . . . . . . . . . . . . . . . . . . . 19 | Appendix B. Contributors . . . . . . . . . . . . . . . . . . . . 17 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 | |||
1. Introduction | 1. Introduction | |||
The Trusted Execution Environment (TEE) concept has been designed to | The Trusted Execution Environment (TEE) concept has been designed to | |||
separate a regular operating system, also referred as a Rich | separate a regular operating system, also referred as a Rich | |||
Execution Environment (REE), from security-sensitive applications. | Execution Environment (REE), from security-sensitive applications. | |||
In an TEE ecosystem, different device vendors may use different | In an TEE ecosystem, device vendors may use different operating | |||
operating systems in the REE and may use different types of TEEs. | systems in the REE and may use different types of TEEs. When | |||
When application providers or device administrators use Trusted | application providers or device administrators use Trusted | |||
Application Managers (TAMs) to install, update, and delete Trusted | Application Managers (TAMs) to install, update, and delete Trusted | |||
Applications (TAs) on a wide range of devices with potentially | Applications (TAs) on a wide range of devices with potentially | |||
different TEEs then an interoperability need arises. | different TEEs then an interoperability need arises. | |||
This document specifies the protocol for communicating between a TAM | This document specifies the protocol for communicating between a TAM | |||
and a TEEP Agent, involving a TEEP Broker. | and a TEEP Agent, involving a TEEP Broker. | |||
The Trusted Execution Environment Provisioning (TEEP) architecture | The Trusted Execution Environment Provisioning (TEEP) architecture | |||
document [I-D.ietf-teep-architecture] has set to provide a design | document [I-D.ietf-teep-architecture] has set to provide a design | |||
guidance for such an interoperable protocol and introduces the | guidance for such an interoperable protocol and introduces the | |||
skipping to change at page 3, line 28 ¶ | skipping to change at page 3, line 28 ¶ | |||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | |||
document are to be interpreted as described in [RFC2119]. | document are to be interpreted as described in [RFC2119]. | |||
This specification re-uses the terminology defined in | This specification re-uses the terminology defined in | |||
[I-D.ietf-teep-architecture]. | [I-D.ietf-teep-architecture]. | |||
3. Message Overview | 3. Message Overview | |||
The TEEP protocol consists of a couple of messages exchanged between | The TEEP protocol consists of a couple of messages exchanged between | |||
a TAM and a TEEP Agent via a TEEP Broker. The messages are encoded | a TAM and a TEEP Agent via a TEEP Broker. The messages are encoded | |||
either in JSON or CBOR and designed to provide end-to-end security. | in CBOR and designed to provide end-to-end security. TEEP protocol | |||
TEEP protocol messages are signed and/or encrypted by the endpoints, | messages are signed by the endpoints, i.e., the TAM and the TEEP | |||
i.e., the TAM and the TEEP Agent, but trusted applications may as | Agent, but trusted applications may as well be encrypted and signed | |||
well be encrypted and signed by the service provider. The TEEP | by the service provider. The TEEP protocol not only re-use CBOR but | |||
protocol not only re-use JSON and CBOR but also the respective | also the respective security wrapper, namely COSE [RFC8152]. | |||
security wrappers, namely JOSE (JWS [RFC7515] and JWE [RFC7516], to | Furthermore, for attestation the Entity Attestation Token (EAT) | |||
be more specific) and COSE [RFC8152]. Furthermore, for attestation | [I-D.ietf-rats-eat] and for software updates the SUIT manifest format | |||
the Entity Attestation Token (EAT) [I-D.ietf-rats-eat] and for | [I-D.ietf-suit-manifest] are re-used. | |||
software updates the SUIT manifest format [I-D.ietf-suit-manifest] | ||||
are re-used. | ||||
This specification defines six messages. | This specification defines six messages. | |||
A TAM queries a device's current state with a QueryRequest message. | A TAM queries a device's current state with a QueryRequest message. | |||
A TEEP Agent will, after authenticating and authorizing the request, | A TEEP Agent will, after authenticating and authorizing the request, | |||
report attestation information, list all TAs, and provide information | report attestation information, list all TAs, and provide information | |||
about supported algorithms and extensions in a QueryResponse message. | about supported algorithms and extensions in a QueryResponse message. | |||
An error message is returned if the request could not be processed. | An error message is returned if the request could not be processed. | |||
A TAM will process the QueryResponse message and determine whether | A TAM will process the QueryResponse message and determine whether | |||
subsequent message exchanges to install, update, or delete trusted | subsequent message exchanges to install, update, or delete trusted | |||
skipping to change at page 5, line 7 ¶ | skipping to change at page 5, line 7 ¶ | |||
TrustedAppDelete ----> | TrustedAppDelete ----> | |||
Success | Success | |||
<---- or | <---- or | |||
Error | Error | |||
4. Detailed Messages Specification | 4. Detailed Messages Specification | |||
For a CBOR-based encoding the following security wrapper is used | The CBOR-encoded messages are protected by COSE, as described in CDDL | |||
(described in CDDL format [I-D.ietf-cbor-cddl]). | format [I-D.ietf-cbor-cddl] below. | |||
Outer_Wrapper = { | Outer_Wrapper = { | |||
msg-authenc-wrapper => bstr .cbor | msg-authenc-wrapper => bstr .cbor | |||
Msg_AuthEnc_Wrapper / nil, | Msg_AuthEnc_Wrapper / nil, | |||
teep-message => (QueryRequest / | teep-message => (QueryRequest / | |||
QueryResponse / | QueryResponse / | |||
TrustedAppInstall / | TrustedAppInstall / | |||
TrustedAppDelete / | TrustedAppDelete / | |||
Error / | Error / | |||
Success ), | Success ), | |||
} | } | |||
msg-authenc-wrapper = 1 | msg-authenc-wrapper = 1 | |||
teep-message = 2 | teep-message = 2 | |||
Msg_AuthEnc_Wrapper = [ * (COSE_Mac_Tagged / | Msg_AuthEnc_Wrapper = [ * (COSE_Mac_Tagged / | |||
COSE_Sign_Tagged / | COSE_Sign_Tagged / | |||
COSE_Mac0_Tagged / | COSE_Mac0_Tagged / | |||
COSE_Sign1_Tagged)] | COSE_Sign1_Tagged)] | |||
A future version of this specification will also describe the | ||||
security wrapper for JSON (in CDDL format). | ||||
4.1. QueryRequest | 4.1. QueryRequest | |||
suite = int | suite = int | |||
version = int | version = int | |||
data_items = ( | data_item = int | |||
attestation: 1, | ||||
trusted_apps: 2, | ||||
extensions: 3, | ||||
suit_commands: 4 | ||||
) | ||||
QueryRequest = ( | QueryRequest = { | |||
TYPE : int, | TYPE : int, | |||
TOKEN : bstr, | TOKEN : bstr, | |||
REQUEST : [+data_items], | REQUEST : [+data_item], | |||
? CIPHER_SUITE : [+suite], | ? CIPHER_SUITE : [+suite], | |||
? NONCE : bstr, | ? NONCE : bstr, | |||
? VERSION : [+version], | ? VERSION : [+version], | |||
? OCSP_DATA : bstr, | ? OCSP_DATA : bstr, | |||
* $$extensions | * $$extensions | |||
) | } | |||
A QueryRequest message is signed by the TAM and has the following | A QueryRequest message is signed by the TAM and has the following | |||
fields: | fields: | |||
TYPE TYPE = 1 corresponds to a QueryRequest message sent from the | TYPE TYPE = 1 corresponds to a QueryRequest message sent from the | |||
TAM to the TEEP Agent. | TAM to the TEEP Agent. | |||
TOKEN The value in the TOKEN field is used to match requests to | TOKEN The value in the TOKEN field is used to match requests to | |||
responses. | responses. | |||
skipping to change at page 7, line 28 ¶ | skipping to change at page 6, line 47 ¶ | |||
VERSION The VERSION field lists the version(s) supported by the TAM. | VERSION The VERSION field lists the version(s) supported by the TAM. | |||
For this version of the specification this field can be omitted. | For this version of the specification this field can be omitted. | |||
OCSP_DATA The OCSP_DATA field contains a list of OCSP stapling data | OCSP_DATA The OCSP_DATA field contains a list of OCSP stapling data | |||
respectively for the TAM certificate and each of the CA | respectively for the TAM certificate and each of the CA | |||
certificates up to the root certificate. The TAM provides OCSP | certificates up to the root certificate. The TAM provides OCSP | |||
data so that the TEEP Agent can validate the status of the TAM | data so that the TEEP Agent can validate the status of the TAM | |||
certificate chain without making its own external OCSP service | certificate chain without making its own external OCSP service | |||
call. OCSP data MUST be conveyed as a DER-encoded OCSP response | call. OCSP data MUST be conveyed as a DER-encoded OCSP response | |||
(using the ASN.1 type OCSPResponse defined in [RFC2560]). The use | (using the ASN.1 type OCSPResponse defined in [RFC2560]). The use | |||
of OCSP is optional to implement for both the TAM and the TEEP | of OCSP is optional to implement for bo th the TAM and the TEEP | |||
Agent. A TAM can query the TEEP Agent for the support of this | Agent. A TAM can query the TEEP Agent for the support of this | |||
functionality via the capability discovery exchange, as described | functionality via the capability discovery exchange, as described | |||
above. | above. | |||
4.2. QueryResponse | 4.2. QueryResponse | |||
ta_id = ( | ||||
Vendor_ID = bstr, | ||||
Class_ID = bstr, | ||||
Device_ID = bstr, | ||||
* $$extensions | ||||
) | ||||
ext_info = int | ext_info = int | |||
QueryResponse = ( | QueryResponse = { | |||
TYPE : int, | TYPE : int, | |||
TOKEN : bstr, | TOKEN : bstr, | |||
? SELECTED_CIPHER_SUITE : suite, | ? SELECTED_CIPHER_SUITE : suite, | |||
? SELECTED_VERSION : version, | ? SELECTED_VERSION : version, | |||
? EAT : bstr, | ? EAT : bstr, | |||
? TA_LIST : [+ta_id], | ? TA_LIST : [+bstr], | |||
? EXT_LIST : [+ext_info], | ? EXT_LIST : [+ext_info], | |||
* $$extensions | * $$extensions | |||
) | } | |||
The QueryResponse message is signed and encrypted by the TEEP Agent | The QueryResponse message is signed and encrypted by the TEEP Agent | |||
and returned to the TAM. It has the following fields: | and returned to the TAM. It has the following fields: | |||
TYPE TYPE = 2 corresponds to a QueryResponse message sent from the | TYPE TYPE = 2 corresponds to a QueryResponse message sent from the | |||
TEEP Agent to the TAM. | TEEP Agent to the TAM. | |||
TOKEN The value in the TOKEN field is used to match requests to | TOKEN The value in the TOKEN field is used to match requests to | |||
responses. The value MUST correspond to the value received with | responses. The value MUST correspond to the value received with | |||
the QueryRequest. | the QueryRequest. | |||
skipping to change at page 8, line 45 ¶ | skipping to change at page 7, line 41 ¶ | |||
selected ciphersuite. Details about the ciphersuite encoding can | selected ciphersuite. Details about the ciphersuite encoding can | |||
be found in Section 5. | be found in Section 5. | |||
SELECTED_VERSION The SELECTED_VERSION field indicates the protocol | SELECTED_VERSION The SELECTED_VERSION field indicates the protocol | |||
version selected by the TEEP Agent. | version selected by the TEEP Agent. | |||
EAT The EAT field contains an Entity Attestation Token following the | EAT The EAT field contains an Entity Attestation Token following the | |||
encoding defined in [I-D.ietf-rats-eat]. | encoding defined in [I-D.ietf-rats-eat]. | |||
TA_LIST The TA_LIST field enumerates the trusted applications | TA_LIST The TA_LIST field enumerates the trusted applications | |||
installed on the device in form of ta_ids, i.e., a vendor id/class | installed on the device in form of TA ID strings. | |||
id/device id triple. | ||||
EXT_LIST The EXT_LIST field lists the supported extensions. This | EXT_LIST The EXT_LIST field lists the supported extensions. This | |||
document does not define any extensions. | document does not define any extensions. | |||
4.3. TrustedAppInstall | 4.3. TrustedAppInstall | |||
TrustedAppInstall = { | ||||
TrustedAppInstall = ( | ||||
TYPE : int, | TYPE : int, | |||
TOKEN : bstr, | TOKEN : bstr, | |||
? MANIFEST_LIST : [+ SUIT_Outer_Wrapper], | ? MANIFEST_LIST : [+ SUIT_Outer_Wrapper], | |||
* $$extensions | * $$extensions | |||
) | } | |||
The TrustedAppInstall message is MACed and encrypted by the TAM and | The TrustedAppInstall message is MACed and encrypted by the TAM and | |||
has the following fields: | has the following fields: | |||
TYPE TYPE = 3 corresponds to a TrustedAppInstall message sent from | TYPE TYPE = 3 corresponds to a TrustedAppInstall message sent from | |||
the TAM to the TEEP Agent. In case of successful processing, an | the TAM to the TEEP Agent. In case of successful processing, an | |||
Success message is returned by the TEEP Agent. In case of an | Success message is returned by the TEEP Agent. In case of an | |||
error, an Error message is returned. Note that the | error, an Error message is returned. Note that the | |||
TrustedAppInstall message is used for initial TA installation but | TrustedAppInstall message is used for initial TA installation but | |||
also for TA updates. | also for TA updates. | |||
skipping to change at page 9, line 40 ¶ | skipping to change at page 8, line 37 ¶ | |||
cryptographic information protecting the manifest. The manifest | cryptographic information protecting the manifest. The manifest | |||
may also convey personalization data. TA binaries and | may also convey personalization data. TA binaries and | |||
personalization data is typically signed and encrypted by the SP. | personalization data is typically signed and encrypted by the SP. | |||
Other combinations are, however, possible as well. For example, | Other combinations are, however, possible as well. For example, | |||
it is also possible for the TAM to sign and encrypt the | it is also possible for the TAM to sign and encrypt the | |||
personalization data and to let the SP sign and/or encrypt the TA | personalization data and to let the SP sign and/or encrypt the TA | |||
binary. | binary. | |||
4.4. TrustedAppDelete | 4.4. TrustedAppDelete | |||
TrustedAppDelete = ( | TrustedAppDelete = { | |||
TYPE : int, | TYPE : int, | |||
TOKEN : bstr, | TOKEN : bstr, | |||
? TA_LIST : [+ta_id], | ? TA_LIST : [+bstr], | |||
* $$extensions | * $$extensions | |||
) | } | |||
The TrustedAppDelete message is MACed and encrypted by the TAM and | The TrustedAppDelete message is MACed and encrypted by the TAM and | |||
has the following fields: | has the following fields: | |||
TYPE TYPE = 4 corresponds to a TrustedAppDelete message sent from | TYPE TYPE = 4 corresponds to a TrustedAppDelete message sent from | |||
the TAM to the TEEP Agent. In case of successful processing, an | the TAM to the TEEP Agent. In case of successful processing, an | |||
Success message is returned by the TEEP Agent. In case of an | Success message is returned by the TEEP Agent. In case of an | |||
error, an Error message is returned. | error, an Error message is returned. | |||
TOKEN The value in the TOKEN field is used to match requests to | TOKEN The value in the TOKEN field is used to match requests to | |||
responses. | responses. | |||
TA_LIST The TA_LIST field enumerates the TAs to be deleted. | TA_LIST The TA_LIST field enumerates the TAs to be deleted. | |||
4.5. Success | 4.5. Success | |||
Success = ( | Success = { | |||
TYPE : int, | TYPE : int, | |||
TOKEN : bstr, | TOKEN : bstr, | |||
? MSG : tstr, | ? MSG : tstr, | |||
* $$extensions | * $$extensions | |||
) | } | |||
The Success message is MACed and encrypted by the TEEP Agent and has | The Success message is MACed and encrypted by the TEEP Agent and has | |||
the following fields: | the following fields: | |||
TYPE TYPE = 5 corresponds to a Error message sent from the TEEP | TYPE TYPE = 5 corresponds to a Error message sent from the TEEP | |||
Agent to the TAM. | Agent to the TAM. | |||
TOKEN The value in the TOKEN field is used to match requests to | TOKEN The value in the TOKEN field is used to match requests to | |||
responses. | responses. | |||
MSG The MSG field contains optional diagnostics information encoded | MSG The MSG field contains optional diagnostics information encoded | |||
in UTF-8 [RFC3629] returned by the TEEP Agent. | in UTF-8 [RFC3629] returned by the TEEP Agent. | |||
4.6. Error | 4.6. Error | |||
Error = ( | Error = { | |||
TYPE : int, | TYPE : int, | |||
TOKEN : bstr, | TOKEN : bstr, | |||
ERR_CODE : int, | ERR_CODE : int, | |||
? ERR_MSG : tstr, | ? ERR_MSG : tstr, | |||
? CIPHER_SUITE : [+suite], | ? CIPHER_SUITE : [+suite], | |||
? VERSION : [+version], | ? VERSION : [+version], | |||
* $$extensions | * $$extensions | |||
) | } | |||
If possible, the Error message is MACed and encrypted by the TEEP | If possible, the Error message is MACed and encrypted by the TEEP | |||
Agent. Unprotected Error messages MUST be handled with care by the | Agent. Unprotected Error messages MUST be handled with care by the | |||
TAM due to possible downgrading attacks. It has the following | TAM due to possible downgrading attacks. It has the following | |||
fields: | fields: | |||
TYPE TYPE = 6 corresponds to a Error message sent from the TEEP | TYPE TYPE = 6 corresponds to a Error message sent from the TEEP | |||
Agent to the TAM. | Agent to the TAM. | |||
TOKEN The value in the TOKEN field is used to match requests to | TOKEN The value in the TOKEN field is used to match requests to | |||
skipping to change at page 11, line 27 ¶ | skipping to change at page 10, line 24 ¶ | |||
supported by the TEEP Agent. This field is optional but MUST be | supported by the TEEP Agent. This field is optional but MUST be | |||
returned with the ERR_UNSUPPORTED_MSG_VERSION error message. | returned with the ERR_UNSUPPORTED_MSG_VERSION error message. | |||
CIPHER_SUITE The CIPHER_SUITE field lists the ciphersuite(s) | CIPHER_SUITE The CIPHER_SUITE field lists the ciphersuite(s) | |||
supported by the TEEP Agent. This field is optional but MUST be | supported by the TEEP Agent. This field is optional but MUST be | |||
returned with the ERR_UNSUPPORTED_CRYPTO_ALG error message. | returned with the ERR_UNSUPPORTED_CRYPTO_ALG error message. | |||
This specification defines the following initial error messages. | This specification defines the following initial error messages. | |||
Additional error code can be registered with IANA. | Additional error code can be registered with IANA. | |||
ERR_ILLEGAL_PARAMETER The TEEP Agent sends this error message when a | ERR_ILLEGAL_PARAMETER (1) The TEEP Agent sends this error message | |||
request contains incorrect fields or fields that are inconsistent | when a request contains incorrect fields or fields that are | |||
with other fields. | inconsistent with other fields. | |||
ERR_UNSUPPORTED_EXTENSION The TEEP Agent sends this error message | ERR_UNSUPPORTED_EXTENSION (2) The TEEP Agent sends this error | |||
when it recognizes an unsupported extension or unsupported | message when it recognizes an unsupported extension or unsupported | |||
message. | message. | |||
ERR_REQUEST_SIGNATURE_FAILED The TEEP Agent sends this error message | ERR_REQUEST_SIGNATURE_FAILED (3) The TEEP Agent sends this error | |||
when it fails to verify the signature of the message. | message when it fails to verify the signature of the message. | |||
ERR_UNSUPPORTED_MSG_VERSION The TEEP Agent receives a message but | ERR_UNSUPPORTED_MSG_VERSION (4) The TEEP Agent receives a message | |||
does not support the indicated version. | but does not support the indicated version. | |||
ERR_UNSUPPORTED_CRYPTO_ALG The TEEP Agent receives a request message | ERR_UNSUPPORTED_CRYPTO_ALG (5) The TEEP Agent receives a request | |||
encoded with an unsupported cryptographic algorithm. | message encoded with an unsupported cryptographic algorithm. | |||
ERR_BAD_CERTIFICATE The TEEP Agent returns this error when | ERR_BAD_CERTIFICATE (6) The TEEP Agent returns this error when | |||
processing of a certificate failed. For diagnosis purposes it is | processing of a certificate failed. For diagnosis purposes it is | |||
RECOMMMENDED to include information about the failing certificate | RECOMMMENDED to include information about the failing certificate | |||
in the error message. | in the error message. | |||
ERR_UNSUPPORTED_CERTIFICATE The TEEP Agent returns this error when a | ERR_UNSUPPORTED_CERTIFICATE (7) The TEEP Agent returns this error | |||
certificate was of an unsupported type. | when a certificate was of an unsupported type. | |||
ERR_CERTIFICATE_REVOKED The TEEP Agent returns this error when a | ERR_CERTIFICATE_REVOKED (8) The TEEP Agent returns this error when a | |||
certificate was revoked by its signer. | certificate was revoked by its signer. | |||
ERR_CERTIFICATE_EXPIRED The TEEP Agent returns this error when a | ERR_CERTIFICATE_EXPIRED (9) The TEEP Agent returns this error when a | |||
certificate has expired or is not currently valid. | certificate has expired or is not currently valid. | |||
ERR_INTERNAL_ERROR The TEEP Agent returns this error when a | ERR_INTERNAL_ERROR (10) The TEEP Agent returns this error when a | |||
miscellaneous internal error occurred while processing the | miscellaneous internal error occurred while processing the | |||
request. | request. | |||
ERR_RESOURCE_FULL This error is reported when a device resource | ERR_RESOURCE_FULL (11) This error is reported when a device resource | |||
isn't available anymore, such as storage space is full. | isn't available anymore, such as storage space is full. | |||
ERR_TA_NOT_FOUND This error will occur when the target TA does not | ERR_TA_NOT_FOUND (12) This error will occur when the target TA does | |||
exist. This error may happen when the TAM has stale information | not exist. This error may happen when the TAM has stale | |||
and tries to delete a TA that has already been deleted. | information and tries to delete a TA that has already been | |||
deleted. | ||||
ERR_TA_ALREADY_INSTALLED While installing a TA, a TEE will return | ERR_TA_ALREADY_INSTALLED (13) While installing a TA, a TEE will | |||
this error if the TA has already been installed. | return this error if the TA has already been installed. | |||
ERR_TA_UNKNOWN_FORMAT The TEEP Agent returns this error when it does | ERR_TA_UNKNOWN_FORMAT (14) The TEEP Agent returns this error when it | |||
not recognize the format of the TA binary. | does not recognize the format of the TA binary. | |||
ERR_TA_DECRYPTION_FAILED The TEEP Agent returns this error when it | ERR_TA_DECRYPTION_FAILED (15) The TEEP Agent returns this error when | |||
fails to decrypt the TA binary. | it fails to decrypt the TA binary. | |||
ERR_TA_DECOMPRESSION_FAILED The TEEP Agent returns this error when | ERR_TA_DECOMPRESSION_FAILED (16) The TEEP Agent returns this error | |||
it fails to decompress the TA binary. | when it fails to decompress the TA binary. | |||
ERR_MANIFEST_PROCESSING_FAILED The TEEP Agent returns this error | ERR_MANIFEST_PROCESSING_FAILED (17) The TEEP Agent returns this | |||
when manifest processing failures occur that are less specific | error when manifest processing failures occur that are less | |||
than ERR_TA_UNKNOWN_FORMAT, ERR_TA_UNKNOWN_FORMAT, and | specific than ERR_TA_UNKNOWN_FORMAT, ERR_TA_UNKNOWN_FORMAT, and | |||
ERR_TA_DECOMPRESSION_FAILED. | ERR_TA_DECOMPRESSION_FAILED. | |||
ERR_PD_PROCESSING_FAILED The TEEP Agent returns this error when it | ERR_PD_PROCESSING_FAILED (18) The TEEP Agent returns this error when | |||
fails to process the provided personalization data. | it fails to process the provided personalization data. | |||
5. Ciphersuites | 5. Ciphersuites | |||
A ciphersuite consists of an AEAD algorithm, a HMAC algorithm, and a | A ciphersuite consists of an AEAD algorithm, a HMAC algorithm, and a | |||
signature algorithm. Each ciphersuite is identified with an integer | signature algorithm. Each ciphersuite is identified with an integer | |||
value, which corresponds to an IANA registered ciphersuite. This | value, which corresponds to an IANA registered ciphersuite. This | |||
document specifies two ciphersuites. | document specifies two ciphersuites. | |||
Value | Ciphersuite | Value | Ciphersuite | |||
------+------------------------------------------------ | ------+------------------------------------------------ | |||
0 | AES-CCM-16-64-128, HMAC 256/256, X25519, EdDSA | 0 | AES-CCM-16-64-128, HMAC 256/256, X25519, EdDSA | |||
1 | AES-CCM-16-64-128, HMAC 256/256, P-256, ES256 | 1 | AES-CCM-16-64-128, HMAC 256/256, P-256, ES256 | |||
6. Security Consideration | 6. Security Consideration | |||
This section summarizes the security considerations discussed in this | This section summarizes the security considerations discussed in this | |||
specification: | specification: | |||
Cryptographic Algorithms This specification relies on the | Cryptographic Algorithms TEEP protocol messages exchanged between | |||
cryptographic algorithms provided by the security wrappers JOSE | the TAM and the TEEP Agent are protected using COSE. This | |||
and COSE, respectively. A companion document makes algorithm | specification relies on the cryptographic algorithms provided by | |||
recommendations but this document is written in an algorithm- | COSE. Public key based authentication is used to by the TEEP | |||
agnostic way. TEEP protocol messages exchanged between the TAM | Agent to authenticate the TAM and vice versa. | |||
and the TEEP Agent are protected using JWS and JWE (for JSON- | ||||
encoded messages) and COSE (for CBOR-encoded messages). Public | ||||
key based authentication is used to by the TEEP Agent to | ||||
authenticate the TAM and vice versa. | ||||
Attestation A TAM may rely on the attestation information provided | Attestation A TAM may rely on the attestation information provided | |||
by the TEEP Agent and the Entity Attestation Token is re-used to | by the TEEP Agent and the Entity Attestation Token is re-used to | |||
convey this information. To sign the Entity Attestation Token it | convey this information. To sign the Entity Attestation Token it | |||
is necessary for the device to possess a public key (usually in | is necessary for the device to possess a public key (usually in | |||
the form of a certificate) along with the corresponding private | the form of a certificate) along with the corresponding private | |||
key. Depending on the properties of the attestation mechanism it | key. Depending on the properties of the attestation mechanism it | |||
is possible to uniquely identify a device based on information in | is possible to uniquely identify a device based on information in | |||
the attestation information or in the certificate used to sign the | the attestation information or in the certificate used to sign the | |||
attestation token. This uniqueness may raise privacy concerns. | attestation token. This uniqueness may raise privacy concerns. | |||
skipping to change at page 13, line 44 ¶ | skipping to change at page 12, line 40 ¶ | |||
responsibility of the TAM to relay only verified TAs from | responsibility of the TAM to relay only verified TAs from | |||
authorized SPs. Delivery of that TA to the TEEP Agent is then the | authorized SPs. Delivery of that TA to the TEEP Agent is then the | |||
responsibility of the TAM and the TEEP Broker, using the security | responsibility of the TAM and the TEEP Broker, using the security | |||
mechanisms provided by the TEEP protocol. To protect the TA | mechanisms provided by the TEEP protocol. To protect the TA | |||
binary the SUIT manifest is re-used and it offers a varity of | binary the SUIT manifest is re-used and it offers a varity of | |||
security features, including digitial signatures and symmetric | security features, including digitial signatures and symmetric | |||
encryption. | encryption. | |||
Personalization Data An SP or a TAM can supply personalization data | Personalization Data An SP or a TAM can supply personalization data | |||
along with a TA. This data is also protected by a SUIT manifest. | along with a TA. This data is also protected by a SUIT manifest. | |||
The personalization data may be itself is (or can be) opaque to | The personalization data may be opaque to the TAM. | |||
the TAM. | ||||
TEEP Broker The TEEP protocol relies on the TEEP Broker to relay | TEEP Broker The TEEP protocol relies on the TEEP Broker to relay | |||
messages between the TAM and the TEEP Agent. When the TEEP Broker | messages between the TAM and the TEEP Agent. When the TEEP Broker | |||
is compromised it can drop messages, delay the delivery of | is compromised it can drop messages, delay the delivery of | |||
messages, and replay messages but it cannot modify those messages. | messages, and replay messages but it cannot modify those messages. | |||
(A replay would be, however, detected by the TEEP Agent.) A | (A replay would be, however, detected by the TEEP Agent.) A | |||
compromised TEEP Broker could reorder messages in an attempt to | compromised TEEP Broker could reorder messages in an attempt to | |||
install an old version of a TA. Information in the manifest | install an old version of a TA. Information in the manifest | |||
ensures that the TEEP Agents are protected against such | ensures that the TEEP Agents are protected against such | |||
downgrading attacks based on features offered by the manifest | downgrading attacks based on features offered by the manifest | |||
skipping to change at page 14, line 43 ¶ | skipping to change at page 13, line 39 ¶ | |||
validity of intermediate CA certificates). The integrity and the | validity of intermediate CA certificates). The integrity and the | |||
accuracy of the clock within the TEE determines the ability to | accuracy of the clock within the TEE determines the ability to | |||
determine an expired or revoked certificate since OCSP stapling | determine an expired or revoked certificate since OCSP stapling | |||
includes signature generation time, certificate validity dates are | includes signature generation time, certificate validity dates are | |||
compared to the current time. | compared to the current time. | |||
7. IANA Considerations | 7. IANA Considerations | |||
7.1. Media Type Registration | 7.1. Media Type Registration | |||
IANA is requested to assign a media type for application/teep+json. | ||||
Type name: application | ||||
Subtype name: teep+json | ||||
Required parameters: none | ||||
Optional parameters: none | ||||
Encoding considerations: Same as encoding considerations of | ||||
application/json as specified in Section 11 of [RFC7159] | ||||
Security considerations: See Security Considerations Section of this | ||||
document. | ||||
Interoperability considerations: Same as interoperability | ||||
considerations of application/json as specified in [RFC7159] | ||||
Published specification: This document. | ||||
Applications that use this media type: TEEP protocol implementations | ||||
Fragment identifier considerations: N/A | ||||
Additional information: | ||||
Deprecated alias names for this type: N/A | ||||
Magic number(s): N/A | ||||
File extension(s): N/A | ||||
Macintosh file type code(s): N/A | ||||
Person to contact for further information: teep@ietf.org | ||||
Intended usage: COMMON | ||||
Restrictions on usage: none | ||||
Author: See the "Authors' Addresses" section of this document | ||||
Change controller: IETF | ||||
IANA is requested to assign a media type for application/teep+cbor. | IANA is requested to assign a media type for application/teep+cbor. | |||
Type name: application | Type name: application | |||
Subtype name: teep+cbor | Subtype name: teep+cbor | |||
Required parameters: none | Required parameters: none | |||
Optional parameters: none | Optional parameters: none | |||
skipping to change at page 17, line 29 ¶ | skipping to change at page 15, line 29 ¶ | |||
IANA is also requested to create a new registry for ciphersuites, as | IANA is also requested to create a new registry for ciphersuites, as | |||
defined in Section 5. | defined in Section 5. | |||
8. References | 8. References | |||
8.1. Normative References | 8.1. Normative References | |||
[I-D.ietf-rats-eat] | [I-D.ietf-rats-eat] | |||
Mandyam, G., Lundblade, L., Ballesteros, M., and J. | Mandyam, G., Lundblade, L., Ballesteros, M., and J. | |||
O'Donoghue, "The Entity Attestation Token (EAT)", draft- | O'Donoghue, "The Entity Attestation Token (EAT)", draft- | |||
ietf-rats-eat-01 (work in progress), July 2019. | ietf-rats-eat-03 (work in progress), February 2020. | |||
[I-D.ietf-suit-manifest] | [I-D.ietf-suit-manifest] | |||
Moran, B., Tschofenig, H., and H. Birkholz, "A Concise | Moran, B., Tschofenig, H., and H. Birkholz, "A Concise | |||
Binary Object Representation (CBOR)-based Serialization | Binary Object Representation (CBOR)-based Serialization | |||
Format for the Software Updates for Internet of Things | Format for the Software Updates for Internet of Things | |||
(SUIT) Manifest", draft-ietf-suit-manifest-02 (work in | (SUIT) Manifest", draft-ietf-suit-manifest-03 (work in | |||
progress), November 2019. | progress), February 2020. | |||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
Requirement Levels", BCP 14, RFC 2119, | Requirement Levels", BCP 14, RFC 2119, | |||
DOI 10.17487/RFC2119, March 1997, | DOI 10.17487/RFC2119, March 1997, | |||
<https://www.rfc-editor.org/info/rfc2119>. | <https://www.rfc-editor.org/info/rfc2119>. | |||
[RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. | [RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. | |||
Adams, "X.509 Internet Public Key Infrastructure Online | Adams, "X.509 Internet Public Key Infrastructure Online | |||
Certificate Status Protocol - OCSP", RFC 2560, | Certificate Status Protocol - OCSP", RFC 2560, | |||
DOI 10.17487/RFC2560, June 1999, | DOI 10.17487/RFC2560, June 1999, | |||
skipping to change at page 18, line 17 ¶ | skipping to change at page 16, line 17 ¶ | |||
<https://www.rfc-editor.org/info/rfc4648>. | <https://www.rfc-editor.org/info/rfc4648>. | |||
[RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network | [RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network | |||
Interchange", RFC 5198, DOI 10.17487/RFC5198, March 2008, | Interchange", RFC 5198, DOI 10.17487/RFC5198, March 2008, | |||
<https://www.rfc-editor.org/info/rfc5198>. | <https://www.rfc-editor.org/info/rfc5198>. | |||
[RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object | [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object | |||
Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, | Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, | |||
October 2013, <https://www.rfc-editor.org/info/rfc7049>. | October 2013, <https://www.rfc-editor.org/info/rfc7049>. | |||
[RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data | ||||
Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March | ||||
2014, <https://www.rfc-editor.org/info/rfc7159>. | ||||
[RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web | ||||
Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May | ||||
2015, <https://www.rfc-editor.org/info/rfc7515>. | ||||
[RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", | ||||
RFC 7516, DOI 10.17487/RFC7516, May 2015, | ||||
<https://www.rfc-editor.org/info/rfc7516>. | ||||
[RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517, | ||||
DOI 10.17487/RFC7517, May 2015, | ||||
<https://www.rfc-editor.org/info/rfc7517>. | ||||
[RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, | ||||
DOI 10.17487/RFC7518, May 2015, | ||||
<https://www.rfc-editor.org/info/rfc7518>. | ||||
[RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", | [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", | |||
RFC 8152, DOI 10.17487/RFC8152, July 2017, | RFC 8152, DOI 10.17487/RFC8152, July 2017, | |||
<https://www.rfc-editor.org/info/rfc8152>. | <https://www.rfc-editor.org/info/rfc8152>. | |||
8.2. Informative References | 8.2. Informative References | |||
[I-D.ietf-cbor-cddl] | [I-D.ietf-cbor-cddl] | |||
Birkholz, H., Vigano, C., and C. Bormann, "Concise data | Birkholz, H., Vigano, C., and C. Bormann, "Concise data | |||
definition language (CDDL): a notational convention to | definition language (CDDL): a notational convention to | |||
express CBOR and JSON data structures", draft-ietf-cbor- | express CBOR and JSON data structures", draft-ietf-cbor- | |||
cddl-08 (work in progress), March 2019. | cddl-08 (work in progress), March 2019. | |||
[I-D.ietf-teep-architecture] | [I-D.ietf-teep-architecture] | |||
Pei, M., Tschofenig, H., Wheeler, D., Atyeo, A., and D. | Pei, M., Tschofenig, H., Thaler, D., and D. Wheeler, | |||
Liu, "Trusted Execution Environment Provisioning (TEEP) | "Trusted Execution Environment Provisioning (TEEP) | |||
Architecture", draft-ietf-teep-architecture-04 (work in | Architecture", draft-ietf-teep-architecture-07 (work in | |||
progress), December 2019. | progress), March 2020. | |||
[I-D.ietf-teep-opentrustprotocol] | [I-D.ietf-teep-opentrustprotocol] | |||
Pei, M., Atyeo, A., Cook, N., Yoo, M., and H. Tschofenig, | Pei, M., Atyeo, A., Cook, N., Yoo, M., and H. Tschofenig, | |||
"The Open Trust Protocol (OTrP)", draft-ietf-teep- | "The Open Trust Protocol (OTrP)", draft-ietf-teep- | |||
opentrustprotocol-03 (work in progress), May 2019. | opentrustprotocol-03 (work in progress), May 2019. | |||
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for | [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for | |||
Writing an IANA Considerations Section in RFCs", BCP 26, | Writing an IANA Considerations Section in RFCs", BCP 26, | |||
RFC 8126, DOI 10.17487/RFC8126, June 2017, | RFC 8126, DOI 10.17487/RFC8126, June 2017, | |||
<https://www.rfc-editor.org/info/rfc8126>. | <https://www.rfc-editor.org/info/rfc8126>. | |||
Appendix A. Acknowledgements | Appendix A. Acknowledgements | |||
This work is based on the initial version of OTrP | This work is based on the initial version of OTrP | |||
[I-D.ietf-teep-opentrustprotocol] and hence credits go to those who | [I-D.ietf-teep-opentrustprotocol] and hence credits go to those who | |||
have contributed to it. | have contributed to it. | |||
We would like to thank Eve Schooler for the suggestion of the | We would like to thank Eve Schooler for the suggestion of the | |||
protocol name. | protocol name. | |||
We would like to thank Akira Tsukamoto, Isobe Kohei, Kohei Isobe, | ||||
Tsukasa Ooi, and Yuichi Takita for their valuable implementation | ||||
feedback. | ||||
Appendix B. Contributors | Appendix B. Contributors | |||
We would like to thank the following individuals for their | We would like to thank the following individuals for their | |||
contributions to an earlier version of this specification. | contributions to an initial version of this specification. | |||
- Brian Witten | - Brian Witten | |||
Symantec | Symantec | |||
brian_witten@symantec.com | brian_witten@symantec.com | |||
- Tyler Kim | - Tyler Kim | |||
Solacia | Solacia | |||
tylerkim@iotrust.kr | tylerkim@iotrust.kr | |||
- Nick Cook | - Nick Cook | |||
skipping to change at page 20, line 9 ¶ | skipping to change at page 17, line 34 ¶ | |||
nicholas.cook@arm.com | nicholas.cook@arm.com | |||
- Minho Yoo | - Minho Yoo | |||
IoTrust | IoTrust | |||
minho.yoo@iotrust.kr | minho.yoo@iotrust.kr | |||
Authors' Addresses | Authors' Addresses | |||
Hannes Tschofenig | Hannes Tschofenig | |||
Arm Ltd. | Arm Ltd. | |||
110 Fulbourn Rd | Absam, Tirol 6067 | |||
Cambridge, CB1 9NJ | Austria | |||
Great Britain | ||||
Email: hannes.tschofenig@arm.com | Email: hannes.tschofenig@arm.com | |||
Mingliang Pei | Mingliang Pei | |||
Broadcom | Broadcom | |||
350 Ellis St | 350 Ellis St | |||
Mountain View, CA 94043 | Mountain View, CA 94043 | |||
USA | USA | |||
Email: mingliang.pei@broadcom.com | Email: mingliang.pei@broadcom.com | |||
End of changes. 58 change blocks. | ||||
190 lines changed or deleted | 108 lines changed or added | |||
This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |