< draft-ietf-teep-protocol-05.txt   draft-ietf-teep-protocol-06.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: August 26, 2021 Broadcom Expires: January 13, 2022 Broadcom
D. Wheeler D. Wheeler
Intel Amazon
D. Thaler D. Thaler
Microsoft Microsoft
A. Tsukamoto A. Tsukamoto
AIST AIST
February 22, 2021 July 12, 2021
Trusted Execution Environment Provisioning (TEEP) Protocol Trusted Execution Environment Provisioning (TEEP) Protocol
draft-ietf-teep-protocol-05 draft-ietf-teep-protocol-06
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 Components in a device with a Trusted Execution
Execution Environment (TEE). This specification defines an Environment (TEE). This specification defines an interoperable
interoperable protocol for managing the lifecycle of TAs. protocol for managing the lifecycle of Trusted Components.
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 Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 http://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 August 26, 2021. This Internet-Draft will expire on January 13, 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 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
(http://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 . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Message Overview . . . . . . . . . . . . . . . . . . . . . . 4 3. Message Overview . . . . . . . . . . . . . . . . . . . . . . 4
4. Detailed Messages Specification . . . . . . . . . . . . . . . 5 4. Detailed Messages Specification . . . . . . . . . . . . . . . 5
4.1. Creating and Validating TEEP Messages . . . . . . . . . . 6 4.1. Creating and Validating TEEP Messages . . . . . . . . . . 5
4.1.1. Creating a TEEP message . . . . . . . . . . . . . . . 6 4.1.1. Creating a TEEP message . . . . . . . . . . . . . . . 5
4.1.2. Validating a TEEP Message . . . . . . . . . . . . . . 6 4.1.2. Validating a TEEP Message . . . . . . . . . . . . . . 6
4.2. QueryRequest Message . . . . . . . . . . . . . . . . . . 7 4.2. QueryRequest Message . . . . . . . . . . . . . . . . . . 6
4.3. QueryResponse Message . . . . . . . . . . . . . . . . . . 9 4.3. QueryResponse Message . . . . . . . . . . . . . . . . . . 9
4.3.1. Evidence . . . . . . . . . . . . . . . . . . . . . . 12 4.3.1. Evidence . . . . . . . . . . . . . . . . . . . . . . 11
4.4. Update Message . . . . . . . . . . . . . . . . . . . . . 13 4.4. Update Message . . . . . . . . . . . . . . . . . . . . . 12
4.5. Success Message . . . . . . . . . . . . . . . . . . . . . 14 4.5. Success Message . . . . . . . . . . . . . . . . . . . . . 14
4.6. Error Message . . . . . . . . . . . . . . . . . . . . . . 15 4.6. Error Message . . . . . . . . . . . . . . . . . . . . . . 15
5. Mapping of TEEP Message Parameters to CBOR Labels . . . . . . 18 5. Mapping of TEEP Message Parameters to CBOR Labels . . . . . . 17
6. Behavior Specification . . . . . . . . . . . . . . . . . . . 19 6. Behavior Specification . . . . . . . . . . . . . . . . . . . 18
6.1. TAM Behavior . . . . . . . . . . . . . . . . . . . . . . 19 6.1. TAM Behavior . . . . . . . . . . . . . . . . . . . . . . 18
6.2. TEEP Agent Behavior . . . . . . . . . . . . . . . . . . . 20 6.2. TEEP Agent Behavior . . . . . . . . . . . . . . . . . . . 19
7. Ciphersuites . . . . . . . . . . . . . . . . . . . . . . . . 21 7. Ciphersuites . . . . . . . . . . . . . . . . . . . . . . . . 20
8. Security Considerations . . . . . . . . . . . . . . . . . . . 21 8. Freshness Mechanisms . . . . . . . . . . . . . . . . . . . . 21
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 9. Security Considerations . . . . . . . . . . . . . . . . . . . 21
9.1. Media Type Registration . . . . . . . . . . . . . . . . . 23 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
9.2. Ciphersuite Registry . . . . . . . . . . . . . . . . . . 24 10.1. Media Type Registration . . . . . . . . . . . . . . . . 23
9.3. CBOR Tag Registry . . . . . . . . . . . . . . . . . . . . 24 10.2. Ciphersuite Registry . . . . . . . . . . . . . . . . . . 24
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 10.3. Freshness Mechanism Registry . . . . . . . . . . . . . . 24
10.1. Normative References . . . . . . . . . . . . . . . . . . 25 10.4. CBOR Tag Registry . . . . . . . . . . . . . . . . . . . 25
10.2. Informative References . . . . . . . . . . . . . . . . . 26 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
A. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 26 11.1. Normative References . . . . . . . . . . . . . . . . . . 25
11.2. Informative References . . . . . . . . . . . . . . . . . 26
A. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 27
B. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27 B. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27
C. Complete CDDL . . . . . . . . . . . . . . . . . . . . . . . . 27 C. Complete CDDL . . . . . . . . . . . . . . . . . . . . . . . . 27
D. Examples of Diagnostic Notation and Binary Representation . . 30 D. Examples of Diagnostic Notation and Binary Representation . . 31
D.1. Some assumptions in examples . . . . . . . . . . . . . . 30 D.1. Some assumptions in examples . . . . . . . . . . . . . . 31
D.2. QueryRequest Message . . . . . . . . . . . . . . . . . . 31 D.2. QueryRequest Message . . . . . . . . . . . . . . . . . . 31
D.2.1. CBOR Diagnostic Notation . . . . . . . . . . . . . . 31 D.2.1. CBOR Diagnostic Notation . . . . . . . . . . . . . . 32
D.2.2. CBOR Binary Representation . . . . . . . . . . . . . 31 D.2.2. CBOR Binary Representation . . . . . . . . . . . . . 32
D.3. Entity Attestation Token . . . . . . . . . . . . . . . . 31 D.3. Entity Attestation Token . . . . . . . . . . . . . . . . 32
D.3.1. CBOR Diagnostic Notation . . . . . . . . . . . . . . 32 D.3.1. CBOR Diagnostic Notation . . . . . . . . . . . . . . 33
D.4. QueryResponse Message . . . . . . . . . . . . . . . . . . 32 D.4. QueryResponse Message . . . . . . . . . . . . . . . . . . 33
D.4.1. CBOR Diagnostic Notation . . . . . . . . . . . . . . 32 D.4.1. CBOR Diagnostic Notation . . . . . . . . . . . . . . 33
D.4.2. CBOR Binary Representation . . . . . . . . . . . . . 33 D.4.2. CBOR Binary Representation . . . . . . . . . . . . . 34
D.5. Update Message . . . . . . . . . . . . . . . . . . . . . 34 D.5. Update Message . . . . . . . . . . . . . . . . . . . . . 35
D.5.1. CBOR Diagnostic Notation . . . . . . . . . . . . . . 34 D.5.1. CBOR Diagnostic Notation . . . . . . . . . . . . . . 35
D.5.2. CBOR Binary Representation . . . . . . . . . . . . . 35 D.5.2. CBOR Binary Representation . . . . . . . . . . . . . 35
D.6. Success Message . . . . . . . . . . . . . . . . . . . . . 35 D.6. Success Message . . . . . . . . . . . . . . . . . . . . . 36
D.6.1. CBOR Diagnostic Notation . . . . . . . . . . . . . . 35 D.6.1. CBOR Diagnostic Notation . . . . . . . . . . . . . . 36
D.6.2. CBOR Binary Representation . . . . . . . . . . . . . 35 D.6.2. CBOR Binary Representation . . . . . . . . . . . . . 36
D.7. Error Message . . . . . . . . . . . . . . . . . . . . . . 35 D.7. Error Message . . . . . . . . . . . . . . . . . . . . . . 36
D.7.1. CBOR Diagnostic Notation . . . . . . . . . . . . . . 35 D.7.1. CBOR Diagnostic Notation . . . . . . . . . . . . . . 36
D.7.2. CBOR binary Representation . . . . . . . . . . . . . 36 D.7.2. CBOR binary Representation . . . . . . . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37
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 a TEE ecosystem, device vendors may use different operating In a TEE ecosystem, device vendors may use different operating
systems in the REE and may use different types of TEEs. When TA systems in the REE and may use different types of TEEs. When Trusted
Developers or Device Administrators use Trusted Application Managers Component Developers or Device Administrators use Trusted Application
(TAMs) to install, update, and delete Trusted Applications (TAs) on a Managers (TAMs) to install, update, and delete Trusted Applications
wide range of devices with potentially different TEEs then an and their dependencies on a wide range of devices with potentially
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. and a TEEP Agent.
The Trusted Execution Environment Provisioning (TEEP) architecture The Trusted Execution Environment Provisioning (TEEP) architecture
document [I-D.ietf-teep-architecture] provides design guidance and document [I-D.ietf-teep-architecture] provides design guidance and
introduces the necessary terminology. introduces the necessary terminology.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
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].
As explained in Section 4.4 of that document, the TEEP protocol As explained in Section 4.4 of that document, the TEEP protocol
treats each TA, any dependencies the TA has, and personalization data treats each Trusted Application (TA), any dependencies the TA has,
as separate components that are expressed in SUIT manifests, and a and personalization data as separate components that are expressed in
SUIT manifest might contain or reference multiple binaries (see SUIT manifests, and a SUIT manifest might contain or reference
[I-D.ietf-suit-manifest] for more details). multiple binaries (see [I-D.ietf-suit-manifest] for more details).
As such, the term Trusted Component in this document refers to a set As such, the term Trusted Component (TC) in this document refers to a
of binaries expressed in a SUIT manifest, to be installed in a TEE. set of binaries expressed in a SUIT manifest, to be installed in a
Note that a Trusted Component may include one or more TAs and/or TEE. Note that a Trusted Component may include one or more TAs and/
configuration data and keys needed by a TA to operate correctly. or configuration data and keys needed by a TA to operate correctly.
Each Trusted Component is uniquely identified by a SUIT Component Each Trusted Component is uniquely identified by a SUIT Component
Identifier (see [I-D.ietf-suit-manifest] Section 8.7.2.2). Identifier (see [I-D.ietf-suit-manifest] Section 8.7.2.2).
3. Message Overview 3. Message Overview
The TEEP protocol consists of messages exchanged between a TAM and a The TEEP protocol consists of messages exchanged between a TAM and a
TEEP Agent. The messages are encoded in CBOR and designed to provide TEEP Agent. The messages are encoded in CBOR and designed to provide
end-to-end security. TEEP protocol messages are signed by the end-to-end security. TEEP protocol messages are signed by the
endpoints, i.e., the TAM and the TEEP Agent, but Trusted Applications endpoints, i.e., the TAM and the TEEP Agent, but Trusted Applications
may also be encrypted and signed by a TA Developer or Device may also be encrypted and signed by a Trusted Component Developer or
Administrator. The TEEP protocol not only uses CBOR but also the Device Administrator. The TEEP protocol not only uses CBOR but also
respective security wrapper, namely COSE [RFC8152]. Furthermore, for the respective security wrapper, namely COSE [RFC8152]. Furthermore,
software updates the SUIT manifest format [I-D.ietf-suit-manifest] is for software updates the SUIT manifest format
used, and for attestation the Entity Attestation Token (EAT) [I-D.ietf-suit-manifest] is used, and for attestation the Entity
[I-D.ietf-rats-eat] format is supported although other attestation Attestation Token (EAT) [I-D.ietf-rats-eat] format is supported
formats are also permitted. although other attestation formats are also permitted.
This specification defines five messages. This specification defines five messages: QueryRequest,
QueryResponse, Update, Success, and Error.
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 Trusted Components, and report attestation information, list all Trusted Components, and
provide information about supported algorithms and extensions in a provide information about supported algorithms and extensions in a
QueryResponse message. An error message is returned if the request QueryResponse message. An error message is returned if the request
could not be processed. A TAM will process the QueryResponse message could not be processed. A TAM will process the QueryResponse message
and determine whether to initiate subsequent message exchanges to and determine whether to initiate subsequent message exchanges to
install, update, or delete Trusted Applications. install, update, or delete Trusted Applications.
skipping to change at page 5, line 20 skipping to change at page 5, line 5
QueryResponse QueryResponse
<------- or <------- or
Error Error
With the Update message a TAM can instruct a TEEP Agent to install With the Update message a TAM can instruct a TEEP Agent to install
and/or delete one or more Trusted Components. The TEEP Agent will and/or delete one or more Trusted Components. The TEEP Agent will
process the message, determine whether the TAM is authorized and process the message, determine whether the TAM is authorized and
whether the Trusted Component has been signed by an authorized TA whether the Trusted Component has been signed by an authorized
Signer. A Success message is returned when the operation has been Trusted Component Signer. A Success message is returned when the
completed successfully, or an Error message otherwise. operation has been completed successfully, or an Error message
otherwise.
+------------+ +-------------+ +------------+ +-------------+
| TAM | |TEEP Agent | | TAM | |TEEP Agent |
+------------+ +-------------+ +------------+ +-------------+
Update ----> Update ---->
Success Success
<---- or <---- or
skipping to change at page 6, line 12 skipping to change at page 5, line 42
teep-error ), teep-error ),
} }
4.1. Creating and Validating TEEP Messages 4.1. Creating and Validating TEEP Messages
4.1.1. Creating a TEEP message 4.1.1. Creating a TEEP message
To create a TEEP message, the following steps are performed. To create a TEEP message, the following steps are performed.
1. Create a TEEP message according to the description below and 1. Create a TEEP message according to the description below and
populate it with the respective content. populate it with the respective content. TEEP messages sent by
TAMs (QueryRequest and Update) can include a "token". The first
usage of a token generated by a TAM MUST be randomly created.
Subsequent token values MUST be different for each subsequent
message created by a TAM.
2. Create a COSE Header containing the desired set of Header 2. Create a COSE Header containing the desired set of Header
Parameters. The COSE Header MUST be valid per the [RFC8152] Parameters. The COSE Header MUST be valid per the [RFC8152]
specification. specification.
3. Create a COSE_Sign1 object using the TEEP message as the 3. Create a COSE_Sign1 object using the TEEP message as the
COSE_Sign1 Payload; all steps specified in [RFC8152] for creating COSE_Sign1 Payload; all steps specified in [RFC8152] for creating
a COSE_Sign1 object MUST be followed. a COSE_Sign1 object MUST be followed.
4. Prepend the COSE object with the TEEP CBOR tag to indicate that 4. Prepend the COSE object with the TEEP CBOR tag to indicate that
skipping to change at page 7, line 19 skipping to change at page 6, line 52
including ciphersuites, and protocol versions. Additionally, the TAM including ciphersuites, and protocol versions. Additionally, the TAM
can selectively request data items from the TEEP Agent via the can selectively request data items from the TEEP Agent via the
request parameter. Currently, the following features are supported: request parameter. Currently, the following features are supported:
o Request for attestation information, o Request for attestation information,
o Listing supported extensions, o Listing supported extensions,
o Querying installed Trusted Components, and o Querying installed Trusted Components, and
o Listing supporting SUIT commands. o Listing supported SUIT commands.
Like other TEEP messages, the QueryRequest message is signed, and the Like other TEEP messages, the QueryRequest message is signed, and the
relevant CDDL snippet is shown below. The complete CDDL structure is relevant CDDL snippet is shown below. The complete CDDL structure is
shown in [CDDL]. shown in Appendix C.
query-request = [ query-request = [
type: TEEP-TYPE-query-request, type: TEEP-TYPE-query-request,
options: { options: {
? token => bstr .size (8..64), ? token => bstr .size (8..64),
? supported-cipher-suites => [ + suite ], ? supported-cipher-suites => [ + suite ],
? challenge => bstr .size (8..64), ? supported-freshness-mechanisms => [ + freshness-mechanism ],
? challenge => bstr .size (8..512),
? versions => [ + version ], ? versions => [ + version ],
? ocsp-data => bstr, ? ocsp-data => bstr,
* $$query-request-extensions * $$query-request-extensions
* $$teep-option-extensions * $$teep-option-extensions
}, },
data-item-requested: data-item-requested data-item-requested: data-item-requested
] ]
The message has the following fields: The message has the following fields:
type type
The value of (1) corresponds to a QueryRequest message sent from The value of (1) corresponds to a QueryRequest message sent from
the TAM to the TEEP Agent. the TAM to the TEEP Agent.
token token
The value in the token parameter is used to match responses to The value in the token parameter is used to match responses to
requests. This is particularly useful when a TAM issues multiple requests. This is particularly useful when a TAM issues multiple
concurrent requests to a TEEP Agent. The token is not needed when concurrent requests to a TEEP Agent. The token MUST be present if
the attestation bit is set in the data-item-requested value. The and only if the attestation bit is clear in the data-item-
size of the token is at least 8 bytes (64 bits) and maximum of 64 requested value. The size of the token is at least 8 bytes (64
bytes, which is the same as in an EAT Nonce Claim (see bits) and maximum of 64 bytes, which is the same as in an EAT
[I-D.ietf-rats-eat] Section 3.3). The first usage of a token Nonce Claim (see [I-D.ietf-rats-eat] Section 3.3).
generated by a TAM MUST be randomly created. Subsequent token
values MUST be different for each request message to distinguish
the correct response from multiple requests. The token value MUST
NOT be used for other purposes, such as a TAM to identify the
devices and/or a device to identify TAMs or Trusted Components.
The TAM MUST expire the token value after receiving the first
responce from the device and ignore any subsequent messages that
have the same token value.
data-item-requested data-item-requested
The data-item-requested parameter indicates what information the The data-item-requested parameter indicates what information the
TAM requests from the TEEP Agent in the form of a bitmap. Each TAM requests from the TEEP Agent in the form of a bitmap. Each
value in the bitmap corresponds to an IANA registered information value in the bitmap corresponds to an IANA registered information
element. This specification defines the following initial set of element. This specification defines the following initial set of
information elements: information elements:
attestation (1) With this value the TAM requests the TEEP Agent attestation (1) With this value the TAM requests the TEEP Agent
to return attestation evidence (e.g., an EAT) in the response. to return attestation evidence (e.g., an EAT) in the response.
skipping to change at page 8, line 43 skipping to change at page 8, line 22
Further values may be added in the future via IANA registration. Further values may be added in the future via IANA registration.
supported-cipher-suites supported-cipher-suites
The supported-cipher-suites parameter lists the ciphersuite(s) The supported-cipher-suites parameter lists the ciphersuite(s)
supported by the TAM. If this parameter is not present, it is to supported by the TAM. If this parameter is not present, it is to
be treated the same as if it contained both ciphersuites defined be treated the same as if it contained both ciphersuites defined
in this document. Details about the ciphersuite encoding can be in this document. Details about the ciphersuite encoding can be
found in Section 7. found in Section 7.
supported-freshness-mechanisms
The supported-freshness-mechanisms parameter lists the freshness
mechanism(s) supported by the TAM. Details about the encoding can
be found in Section 8. If this parameter is absent, it means only
the nonce mechanism is supported.
challenge challenge
The challenge field is an optional parameter used for ensuring the The challenge field is an optional parameter used for ensuring the
refreshness of the attestation evidence returned with a freshness of the attestation evidence returned with a
QueryResponse message. When a challenge is provided in the QueryResponse message. It MUST be absent if the attestation bit
QueryRequest and an EAT is returned with the QueryResponse message is clear (since the token is used instead in that case). When a
then the challenge contained in this request MUST be copied into challenge is provided in the QueryRequest and an EAT is returned
the nonce claim found in the EAT. If any format other than EAT is with the QueryResponse message then the challenge contained in
used, it is up to that format to define the use of the challenge this request MUST be copied into the nonce claim found in the EAT.
field. If any format other than EAT is used, it is up to that format to
define the use of the challenge field.
versions versions
The versions parameter enumerates the TEEP protocol version(s) The versions parameter enumerates the TEEP protocol version(s)
supported by the TAM A value of 0 refers to the current version of supported by the TAM. A value of 0 refers to the current version
the TEEP protocol. If this field is not present, it is to be of the TEEP protocol. If this field is not present, it is to be
treated the same as if it contained only version 0. treated the same as if it contained only version 0.
ocsp-data ocsp-data
The ocsp-data parameter contains a list of OCSP stapling data The ocsp-data parameter 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, but not including, the trust anchor. The TAM
data so that the TEEP Agent can validate the status of the TAM provides OCSP data so that the TEEP Agent can validate the status
certificate chain without making its own external OCSP service of the TAM certificate chain without making its own external OCSP
call. OCSP data MUST be conveyed as a DER-encoded OCSP response service call. OCSP data MUST be conveyed as a DER-encoded OCSP
(using the ASN.1 type OCSPResponse defined in [RFC2560]). The use response (using the ASN.1 type OCSPResponse defined in [RFC6960]).
of OCSP is OPTIONAL to implement for both the TAM and the TEEP
Agent. A TAM can query the TEEP Agent for the support of this The use of OCSP is OPTIONAL to implement for both the TAM and the
functionality via the capability discovery exchange, as described TEEP Agent. A TAM can query the TEEP Agent for the support of
above. this functionality via the capability discovery exchange, as
described above.
4.3. QueryResponse Message 4.3. QueryResponse Message
The QueryResponse message is the successful response by the TEEP The QueryResponse message is the successful response by the TEEP
Agent after receiving a QueryRequest message. Agent after receiving a QueryRequest message.
Like other TEEP messages, the QueryResponse message is signed, and Like other TEEP messages, the QueryResponse message is signed, and
the relevant CDDL snippet is shown below. The complete CDDL the relevant CDDL snippet is shown below. The complete CDDL
structure is shown in [CDDL]. structure is shown in Appendix C.
query-response = [ query-response = [
type: TEEP-TYPE-query-response, type: TEEP-TYPE-query-response,
options: { options: {
? token => bstr .size (8..64), ? token => bstr .size (8..64),
? selected-cipher-suite => suite, ? selected-cipher-suite => suite,
? selected-version => version, ? selected-version => version,
? evidence-format => text, ? evidence-format => text,
? evidence => bstr, ? evidence => bstr,
? tc-list => [ + tc-info ], ? tc-list => [ + tc-info ],
skipping to change at page 12, line 24 skipping to change at page 11, line 36
the Trusted Component, if a SUIT manifest was used. the Trusted Component, if a SUIT manifest was used.
The requested-tc-info message has the following fields: The requested-tc-info message has the following fields:
component-id component-id
A SUIT Component Identifier. A SUIT Component Identifier.
tc-manifest-sequence-number tc-manifest-sequence-number
The minimum suit-manifest-sequence-number value from a SUIT The minimum suit-manifest-sequence-number value from a SUIT
manifest for the Trusted Component. If not present, indicates manifest for the Trusted Component. If not present, indicates
that any version will do. that any sequence number will do.
have-binary have-binary
If present with a value of true, indicates that the TEEP agent If present with a value of true, indicates that the TEEP agent
already has the Trusted Component binary and only needs an Update already has the Trusted Component binary and only needs an Update
message with a SUIT manifest that authorizes installing it. If message with a SUIT manifest that authorizes installing it. If
have-binary is true, the tc-manifest-sequence-number field MUST be have-binary is true, the tc-manifest-sequence-number field MUST be
present. present.
4.3.1. Evidence 4.3.1. Evidence
skipping to change at page 13, line 39 skipping to change at page 12, line 39
| proof | | 3.3 | | proof | | 3.3 |
+------------+---------------------+--------------------------------+ +------------+---------------------+--------------------------------+
4.4. Update Message 4.4. Update Message
The Update message is used by the TAM to install and/or delete one or The Update message is used by the TAM to install and/or delete one or
more Trusted Components via the TEEP Agent. more Trusted Components via the TEEP Agent.
Like other TEEP messages, the Update message is signed, and the Like other TEEP messages, the Update message is signed, and the
relevant CDDL snippet is shown below. The complete CDDL structure is relevant CDDL snippet is shown below. The complete CDDL structure is
shown in [CDDL]. shown in Appendix C.
update = [ update = [
type: TEEP-TYPE-update, type: TEEP-TYPE-update,
options: { options: {
? token => bstr .size (8..64), ? token => bstr .size (8..64),
? manifest-list => [ + bstr .cbor SUIT_Envelope ], ? manifest-list => [ + bstr .cbor SUIT_Envelope ],
* $$update-extensions, * $$update-extensions,
* $$teep-option-extensions * $$teep-option-extensions
} }
] ]
skipping to change at page 14, line 20 skipping to change at page 13, line 20
is used for initial Trusted Component installation as well as for is used for initial Trusted Component installation as well as for
updates and deletes. updates and deletes.
token token
The value in the token field is used to match responses to The value in the token field is used to match responses to
requests. requests.
manifest-list manifest-list
The manifest-list field is used to convey one or multiple SUIT The manifest-list field is used to convey one or multiple SUIT
manifests to install. A manifest is a bundle of metadata about a manifests to install. A manifest is a bundle of metadata about a
TA, such as where to find the code, the devices to which it Trusted Component, such as where to find the code, the devices to
applies, and cryptographic information protecting the manifest. which it applies, and cryptographic information protecting the
The manifest may also convey personalization data. TA binaries manifest. The manifest may also convey personalization data.
and personalization data can be signed and encrypted by the same Trusted Component binaries and personalization data can be signed
TA Signer. Other combinations are, however, possible as well. and encrypted by the same Trusted Component Signer. Other
For example, it is also possible for the TAM to sign and encrypt combinations are, however, possible as well. For example, it is
the personalization data and to let the TA Developer sign and/or also possible for the TAM to sign and encrypt the personalization
encrypt the TA binary. data and to let the Trusted Component Developer sign and/or
encrypt the Trusted Component binary.
Note that an Update message carrying one or more SUIT manifests will Note that an Update message carrying one or more SUIT manifests will
inherently involve multiple signatures, one by the TAM in the TEEP inherently involve multiple signatures, one by the TAM in the TEEP
message and one from a Trusted Component signer inside each manifest. message and one from a Trusted Component signer inside each manifest.
This is intentional as they are for different purposes. This is intentional as they are for different purposes.
The TAM is what authorizes apps to be installed, updated, and deleted The TAM is what authorizes apps to be installed, updated, and deleted
on a given TEE and so the TEEP signature is checked by the TEEP Agent on a given TEE and so the TEEP signature is checked by the TEEP Agent
at protocol message processing time. (This same TEEP security at protocol message processing time. (This same TEEP security
wrapper is also used on messages like QueryRequest so that Agents wrapper is also used on messages like QueryRequest so that Agents
skipping to change at page 15, line 7 skipping to change at page 14, line 12
some other update mechanism. See section 5 of some other update mechanism. See section 5 of
[I-D.ietf-teep-architecture] for further discussion. [I-D.ietf-teep-architecture] for further discussion.
4.5. Success Message 4.5. Success Message
The Success message is used by the TEEP Agent to return a success in The Success message is used by the TEEP Agent to return a success in
response to an Update message. response to an Update message.
Like other TEEP messages, the Success message is signed, and the Like other TEEP messages, the Success message is signed, and the
relevant CDDL snippet is shown below. The complete CDDL structure is relevant CDDL snippet is shown below. The complete CDDL structure is
shown in [CDDL]. shown in Appendix C.
teep-success = [ teep-success = [
type: TEEP-TYPE-teep-success, type: TEEP-TYPE-teep-success,
options: { options: {
? token => bstr .size (8..64), ? token => bstr .size (8..64),
? msg => text .size (1..128), ? msg => text .size (1..128),
? suit-reports => [ + suit-report ], ? suit-reports => [ + suit-report ],
* $$teep-success-extensions, * $$teep-success-extensions,
* $$teep-option-extensions * $$teep-option-extensions
} }
skipping to change at page 15, line 52 skipping to change at page 15, line 12
value MUST match the value of the token parameter in the Update value MUST match the value of the token parameter in the Update
message the Success message is in response to. message the Success message is in response to.
4.6. Error Message 4.6. Error Message
The Error message is used by the TEEP Agent to return an error in The Error message is used by the TEEP Agent to return an error in
response to an Update message. response to an Update message.
Like other TEEP messages, the Error message is signed, and the Like other TEEP messages, the Error message is signed, and the
relevant CDDL snippet is shown below. The complete CDDL structure is relevant CDDL snippet is shown below. The complete CDDL structure is
shown in [CDDL]. shown in Appendix C.
teep-error = [ teep-error = [
type: TEEP-TYPE-teep-error, type: TEEP-TYPE-teep-error,
options: { options: {
? token => bstr .size (8..64), ? token => bstr .size (8..64),
? err-msg => text .size (1..128), ? err-msg => text .size (1..128),
? supported-cipher-suites => [ + suite ], ? supported-cipher-suites => [ + suite ],
? supported-freshness-mechanisms => [ + freshness-mechanism ],
? versions => [ + version ], ? versions => [ + version ],
? suit-reports => [ + suit-report ], ? suit-reports => [ + suit-report ],
* $$teep-error-extensions, * $$teep-error-extensions,
* $$teep-option-extensions * $$teep-option-extensions
}, },
err-code: uint (0..23) err-code: uint (0..23)
] ]
The Error message has the following fields: The Error message has the following fields:
skipping to change at page 16, line 44 skipping to change at page 16, line 5
be encoded using UTF-8 [RFC3629] using Net-Unicode form [RFC5198] be encoded using UTF-8 [RFC3629] using Net-Unicode form [RFC5198]
with max 128 bytes. with max 128 bytes.
supported-cipher-suites supported-cipher-suites
The supported-cipher-suites parameter lists the ciphersuite(s) The supported-cipher-suites parameter lists the ciphersuite(s)
supported by the TEEP Agent. Details about the ciphersuite supported by the TEEP Agent. Details about the ciphersuite
encoding can be found in Section 7. This field is optional but encoding can be found in Section 7. This field is optional but
MUST be returned with the ERR_UNSUPPORTED_CRYPTO_ALG error MUST be returned with the ERR_UNSUPPORTED_CRYPTO_ALG error
message. message.
supported-freshness-mechanisms
The supported-freshness-mechanisms parameter lists the freshness
mechanism(s) supported by the TEEP Agent. Details about the
encoding can be found in Section 8. If this parameter is absent,
it means only the nonce mechanism is supported.
versions versions
The versions parameter enumerates the TEEP protocol version(s) The versions parameter enumerates the TEEP protocol version(s)
supported by the TEEP Agent. This otherwise optional parameter supported by the TEEP Agent. This otherwise optional parameter
MUST be returned with the ERR_UNSUPPORTED_MSG_VERSION error MUST be returned with the ERR_UNSUPPORTED_MSG_VERSION error
message. message.
suit-reports suit-reports
If present, the suit-reports parameter contains a set of SUIT If present, the suit-reports parameter contains a set of SUIT
Reports as defined in Section 4 of [I-D.moran-suit-report]. If Reports as defined in Section 4 of [I-D.moran-suit-report]. If
the suit-report-nonce field is present in the SUIT Report, is the suit-report-nonce field is present in the SUIT Report, is
skipping to change at page 19, line 5 skipping to change at page 18, line 5
5. Mapping of TEEP Message Parameters to CBOR Labels 5. Mapping of TEEP Message Parameters to CBOR Labels
In COSE, arrays and maps use strings, negative integers, and unsigned In COSE, arrays and maps use strings, negative integers, and unsigned
integers as their keys. Integers are used for compactness of integers as their keys. Integers are used for compactness of
encoding. Since the word "key" is mainly used in its other meaning, encoding. Since the word "key" is mainly used in its other meaning,
as a cryptographic key, this specification uses the term "label" for as a cryptographic key, this specification uses the term "label" for
this usage as a map key. this usage as a map key.
This specification uses the following mapping: This specification uses the following mapping:
+-----------------------------+-------+ +--------------------------------+-------+
| Name | Label | | Name | Label |
+-----------------------------+-------+ +--------------------------------+-------+
| supported-cipher-suites | 1 | | supported-cipher-suites | 1 |
| challenge | 2 | | challenge | 2 |
| version | 3 | | version | 3 |
| ocsp-data | 4 | | ocsp-data | 4 |
| selected-cipher-suite | 5 | | selected-cipher-suite | 5 |
| selected-version | 6 | | selected-version | 6 |
| evidence | 7 | | evidence | 7 |
| tc-list | 8 | | tc-list | 8 |
| ext-list | 9 | | ext-list | 9 |
| manifest-list | 10 | | manifest-list | 10 |
| msg | 11 | | msg | 11 |
| err-msg | 12 | | err-msg | 12 |
| evidence-format | 13 | | evidence-format | 13 |
| requested-tc-list | 14 | | requested-tc-list | 14 |
| unneeded-tc-list | 15 | | unneeded-tc-list | 15 |
| component-id | 16 | | component-id | 16 |
| tc-manifest-sequence-number | 17 | | tc-manifest-sequence-number | 17 |
| have-binary | 18 | | have-binary | 18 |
| suit-reports | 19 | | suit-reports | 19 |
| token | 20 | | token | 20 |
+-----------------------------+-------+ | supported-freshness-mechanisms | 21 |
+--------------------------------+-------+
6. Behavior Specification 6. Behavior Specification
Behavior is specified in terms of the conceptual APIs defined in Behavior is specified in terms of the conceptual APIs defined in
section 6.2.1 of [I-D.ietf-teep-architecture]. section 6.2.1 of [I-D.ietf-teep-architecture].
6.1. TAM Behavior 6.1. TAM Behavior
When the ProcessConnect API is invoked, the TAM sends a QueryRequest When the ProcessConnect API is invoked, the TAM sends a QueryRequest
message. message.
When the ProcessTeepMessage API is invoked, the TAM first does When the ProcessTeepMessage API is invoked, the TAM first does
validation as specified in Section 4.1.2, and drops the message if it validation as specified in Section 4.1.2, and drops the message if it
is not valid. Otherwise, it proceeds as follows. is not valid. Otherwise, it proceeds as follows.
If the message includes a token, it can be used to match the response
to a request previously sent by the TAM. The TAM MUST expire the
token value after receiving the first response from the device that
has a valid signature and ignore any subsequent messages that have
the same token value. The token value MUST NOT be used for other
purposes, such as a TAM to identify the devices and/or a device to
identify TAMs or Trusted Components.
If a QueryResponse message is received that contains evidence, the If a QueryResponse message is received that contains evidence, the
evidence is passed to an attestation Verifier (see evidence is passed to an attestation Verifier (see
[I-D.ietf-rats-architecture]) to determine whether the Agent is in a [I-D.ietf-rats-architecture]) to determine whether the Agent is in a
trustworthy state. Based on the results of attestation, and the trustworthy state. Based on the results of attestation, and the
lists of installed, requested, and unneeded Trusted Components lists of installed, requested, and unneeded Trusted Components
reported in the QueryResponse, the TAM determines, in any reported in the QueryResponse, the TAM determines, in any
implementation specific manner, which Trusted Components need to be implementation specific manner, which Trusted Components need to be
installed, updated, or deleted, if any. If any Trusted Components installed, updated, or deleted, if any. If any Trusted Components
need to be installed, updated, or deleted, the TAM sends an Update need to be installed, updated, or deleted, the TAM sends an Update
message containing SUIT Manifests with command sequences to do the message containing SUIT Manifests with command sequences to do the
relevant installs, updates, or deletes. relevant installs, updates, or deletes. It is important to note that
the TEEP Agent's Update Procedure requires resolving and installing
any dependencies indicated in the manifest, which may take some time,
and the resulting Success or Error message is generated only after
completing the Update Procedure. Hence, depending on the freshness
mechanism in use, the TAM may need to store data (e.g., a nonce) for
some time.
If a Success or Error message is received, the TAM also validates If a Success or Error message is received containing one or more SUIT
that the nonce in any SUIT Report matches the token sent in the Reports, the TAM also validates that the nonce in any SUIT Report
Update message, and drops the message if it does not match. matches the token sent in the Update message, and drops the message
Otherwise, the TAM handles the update in any implementation specific if it does not match. Otherwise, the TAM handles the update in any
way, such as updating any locally cached information about the state implementation specific way, such as updating any locally cached
of the TEEP Agent, or logging the results. information about the state of the TEEP Agent, or logging the
results.
If an Error message is received, the TAM can handle it in any If any other Error message is received, the TAM can handle it in any
implementation specific way, but Section 4.6 provides recommendations implementation specific way, but Section 4.6 provides recommendations
for such handling. for such handling.
6.2. TEEP Agent Behavior 6.2. TEEP Agent Behavior
When the RequestTA API is invoked, the TEEP Agent first checks When the RequestTA API is invoked, the TEEP Agent first checks
whether the requested TA is already installed. If it is already whether the requested TA is already installed. If it is already
installed, the TEEP Agent passes no data back to the caller. installed, the TEEP Agent passes no data back to the caller.
Otherwise, if the TEEP Agent chooses to initiate the process of Otherwise, if the TEEP Agent chooses to initiate the process of
requesting the indicated TA, it determines (in any implementation requesting the indicated TA, it determines (in any implementation
skipping to change at page 20, line 50 skipping to change at page 20, line 18
When the ProcessError API is invoked, the TEEP Agent can handle it in When the ProcessError API is invoked, the TEEP Agent can handle it in
any implementation specific way, such as logging the error or using any implementation specific way, such as logging the error or using
the information in future choices of TAM URI. the information in future choices of TAM URI.
When the ProcessTeepMessage API is invoked, the Agent first does When the ProcessTeepMessage API is invoked, the Agent first does
validation as specified in Section 4.1.2, and drops the message if it validation as specified in Section 4.1.2, and drops the message if it
is not valid. Otherwise, processing continues as follows based on is not valid. Otherwise, processing continues as follows based on
the type of message. the type of message.
When a QueryRequest message is received, the Agent responds with a When a QueryRequest message is received, the Agent responds with a
QueryResponse message. QueryResponse message if all fields were understood, or an Error
message if any error was encountered.
When an Update message is received, the Agent attempts to update the When an Update message is received, the Agent attempts to update the
Trusted Components specified in the SUIT manifests by following the Trusted Components specified in the SUIT manifests by following the
Update Procedure specified in [I-D.ietf-suit-manifest], and responds Update Procedure specified in [I-D.ietf-suit-manifest], and responds
with a Success message if all SUIT manifests were successfully with a Success message if all SUIT manifests were successfully
installed, or an Error message if any error was encountered. installed, or an Error message if any error was encountered. It is
important to note that the Update Procedure requires resolving and
installing any dependencies indicated in the manifest, which may take
some time, and the Success or Error message is generated only after
completing the Update Procedure.
7. Ciphersuites 7. Ciphersuites
A ciphersuite consists of an AEAD algorithm, an HMAC algorithm, and a A ciphersuite consists of an AEAD algorithm, a MAC 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 (see value, which corresponds to an IANA registered ciphersuite (see
Section 9.2. This document specifies two ciphersuites. Section 10.2. This document specifies two ciphersuites.
+-------+------------------------------------------------+ +-------+------------------------------------------------+
| Value | Ciphersuite | | Value | Ciphersuite |
+-------+------------------------------------------------+ +-------+------------------------------------------------+
| 1 | AES-CCM-16-64-128, HMAC 256/256, X25519, EdDSA | | 1 | AES-CCM-16-64-128, HMAC 256/256, X25519, EdDSA |
| 2 | AES-CCM-16-64-128, HMAC 256/256, P-256, ES256 | | 2 | AES-CCM-16-64-128, HMAC 256/256, P-256, ES256 |
+-------+------------------------------------------------+ +-------+------------------------------------------------+
A TAM MUST support both ciphersuites. A TEEP Agent MUST support at A TAM MUST support both ciphersuites. A TEEP Agent MUST support at
least one of the two but can choose which one. For example, a TEEP least one of the two but can choose which one. For example, a TEEP
Agent might choose ciphersuite 2 if it has hardware support for it. Agent might choose ciphersuite 2 if it has hardware support for it.
8. Security Considerations Any ciphersuites without confidentiality protection can only be added
if the associated specification includes a discussion of security
considerations and applicability, since manifests may carry sensitive
information. For example, Section 6 of [I-D.ietf-teep-architecture]
permits implementations that terminate transport security inside the
TEE and if the transport security provides confidentiality then
additional encryption might not be needed in the manifest for some
use cases. For most use cases, however, manifest confidentiality
will be needed to protect sensitive fields from the TAM as discussed
in Section 9.8 of [I-D.ietf-teep-architecture].
8. Freshness Mechanisms
A freshness mechanism determines how a TAM can tell whether evidence
provided in a Query Response is fresh. There are multiple ways this
can be done as discussed in Section 10 of
[I-D.ietf-rats-architecture].
Each freshness mechanism is identified with an integer value, which
corresponds to an IANA registered freshness mechanism (see
Section 10.3. This document defines the following freshness
mechanisms:
+-------+---------------------+
| Value | Freshness mechanism |
+-------+---------------------+
| 1 | Nonce |
| 2 | Timestamp |
| 3 | Epoch ID |
+-------+---------------------+
In the Nonce mechanism, the evidence MUST include a nonce provided in
the QueryRequest challenge. In other mechanisms, a timestamp or
epoch ID determined via mechanisms outside the TEEP protocol is used,
and the challenge is only needed in the QueryRequest message if a
challenge is needed in generating evidence for reasons other than
freshness.
9. Security Considerations
This section summarizes the security considerations discussed in this This section summarizes the security considerations discussed in this
specification: specification:
Cryptographic Algorithms Cryptographic Algorithms
TEEP protocol messages exchanged between the TAM and the TEEP TEEP protocol messages exchanged between the TAM and the TEEP
Agent are protected using COSE. This specification relies on the Agent are protected using COSE. This specification relies on the
cryptographic algorithms provided by COSE. Public key based cryptographic algorithms provided by COSE. Public key based
authentication is used by the TEEP Agent to authenticate the TAM authentication is used by the TEEP Agent to authenticate the TAM
and vice versa. and vice versa.
Attestation Attestation
A TAM can rely on the attestation evidence provided by the TEEP A TAM can rely on the attestation evidence provided by the TEEP
Agent. To sign the attestation evidence, it is necessary for the Agent. To sign the attestation evidence, it is necessary for the
device to possess a public key (usually in the form of a device to possess a public key (usually in the form of a
certificate) along with the corresponding private key. Depending certificate [RFC5280]) along with the corresponding private key.
on the properties of the attestation mechanism, it is possible to Depending on the properties of the attestation mechanism, it is
uniquely identify a device based on information in the attestation possible to uniquely identify a device based on information in the
evidence or in the certificate used to sign the attestation attestation evidence or in the certificate used to sign the
evidence. This uniqueness may raise privacy concerns. To lower attestation evidence. This uniqueness may raise privacy concerns.
the privacy implications the TEEP Agent MUST present its To lower the privacy implications the TEEP Agent MUST present its
attestation evidence only to an authenticated and authorized TAM attestation evidence only to an authenticated and authorized TAM
and when using EATS, it SHOULD use encryption as discussed in and when using EATS, it SHOULD use encryption as discussed in
[I-D.ietf-rats-eat], since confidentiality is not provided by the [I-D.ietf-rats-eat], since confidentiality is not provided by the
TEEP protocol itself and the transport protocol under the TEEP TEEP protocol itself and the transport protocol under the TEEP
protocol might be implemented outside of any TEE. If any protocol might be implemented outside of any TEE. If any
mechanism other than EATs is used, it is up to that mechanism to mechanism other than EATs is used, it is up to that mechanism to
specify how privacy is provided. specify how privacy is provided.
TA Binaries Trusted Component Binaries
Each TA binary is signed by a TA Signer. It is the responsibility Each Trusted Component binary is signed by a Trusted Component
of the TAM to relay only verified TAs from authorized TA Signers. Signer. It is the responsibility of the TAM to relay only
Delivery of a TA to the TEEP Agent is then the responsibility of verified Trusted Components from authorized Trusted Component
the TAM, using the security mechanisms provided by the TEEP Signers. Delivery of a Trusted Component to the TEEP Agent is
protocol. To protect the TA binary, the SUIT manifest format is then the responsibility of the TAM, using the security mechanisms
used and it offers a variety of security features, including provided by the TEEP protocol. To protect the Trusted Component
digitial signatures and symmetric encryption. binary, the SUIT manifest format is used and it offers a variety
of security features, including digitial signatures and symmetric
encryption.
Personalization Data Personalization Data
A TA Signer or TAM can supply personalization data along with a A Trusted Component Signer or TAM can supply personalization data
TA. This data is also protected by a SUIT manifest. along with a Trusted Component. This data is also protected by a
Personalization data signed and encrypted by a TA Signer other SUIT manifest. Personalization data signed and encrypted by a
than the TAM is opaque to the TAM. Trusted Component Signer other than the TAM is opaque to the TAM.
TEEP Broker TEEP Broker
As discussed in section 6 of [I-D.ietf-teep-architecture], the As discussed in section 6 of [I-D.ietf-teep-architecture], the
TEEP protocol typically relies on a TEEP Broker to relay messages TEEP protocol typically relies on a TEEP Broker to relay messages
between the TAM and the TEEP Agent. When the TEEP Broker is between the TAM and the TEEP Agent. When the TEEP Broker is
compromised it can drop messages, delay the delivery of messages, compromised it can drop messages, delay the delivery of messages,
and replay messages but it cannot modify those messages. (A and replay messages but it cannot modify those messages. (A
replay would be, however, detected by the TEEP Agent.) 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 Trusted Component. Information in the
ensures that TEEP Agents are protected against such downgrade manifest ensures that TEEP Agents are protected against such
attacks based on features offered by the manifest itself. downgrade attacks based on features offered by the manifest
itself.
TA Signer Compromise Trusted Component Signer Compromise
The QueryRequest message from a TAM to the TEEP Agent can include The QueryRequest message from a TAM to the TEEP Agent can include
OCSP stapling data for the TAM's certificate and for intermediate OCSP stapling data for the TAM's certificate and for intermediate
CA certificates up to the root certificate so that the TEEP Agent CA certificates up to, but not including, the trust anchor so that
can verify the certificate's revocation status. A certificate the TEEP Agent can verify the certificate's revocation status. A
revocation status check on a TA Signer certificate is OPTIONAL by certificate revocation status check on a Trusted Component Signer
a TEEP Agent. A TAM is responsible for vetting a TA and before certificate is OPTIONAL by a TEEP Agent. A TAM is responsible for
distributing them to TEEP Agents, so TEEP Agents can instead vetting a Trusted Component and before distributing them to TEEP
simply trust that a TA Signer certificate's status was done by the Agents, so TEEP Agents can instead simply trust that a Trusted
TAM. Component Signer certificate's status was done by the TAM.
CA Compromise CA Compromise
The CA issuing certificates to a TAM or a TA Signer might get The CA issuing certificates to a TAM or a Trusted Component Signer
compromised. A compromised intermediate CA certificate can be might get compromised. A compromised intermediate CA certificate
detected by a TEEP Agent by using OCSP information, assuming the can be detected by a TEEP Agent by using OCSP information,
revocation information is available. Additionally, it is assuming the revocation information is available. Additionally,
RECOMMENDED to provide a way to update the trust anchor store used it is RECOMMENDED to provide a way to update the trust anchor
by the TEE, for example using a firmware update mechanism. If the store used by the TEE, for example using a firmware update
CA issuing certificates to devices gets compromised then these mechanism. If the CA issuing certificates to devices gets
devices might be rejected by a TAM, if revocation is available to compromised then these devices might be rejected by a TAM, if
the TAM. revocation is available to the TAM.
Compromised TAM Compromised TAM
The TEEP Agent SHOULD use OCSP information to verify the validity The TEEP Agent SHOULD use OCSP information to verify the validity
of the TAM's certificate (as well as the validity of intermediate of the TAM's certificate (as well as the validity of intermediate
CA certificates). The integrity and the accuracy of the clock CA certificates). The integrity and the accuracy of the clock
within the TEE determines the ability to determine an expired or within the TEE determines the ability to determine an expired or
revoked certificate. OCSP stapling data includes signature revoked certificate. OCSP stapling data includes signature
generation time, allowing certificate validity dates to be generation time, allowing certificate validity dates to be
compared to the current time. compared to the current time.
Compromised Time Source Compromised Time Source
As discussed above, certificate validity checks rely on comparing As discussed above, certificate validity checks rely on comparing
validity dates to the current time, which relies on having a validity dates to the current time, which relies on having a
trusted source of time, such as [RFC8915]. A compromised time trusted source of time, such as [RFC8915]. A compromised time
source could thus be used to subvert such validity checks. source could thus be used to subvert such validity checks.
9. IANA Considerations 10. IANA Considerations
9.1. Media Type Registration 10.1. Media Type Registration
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
Encoding considerations: Same as encoding considerations of Encoding considerations: Same as encoding considerations of
application/cbor. application/cbor.
Security considerations: See Security Considerations Section of this Security considerations: See Security Considerations Section of this
document. document.
Interoperability considerations: Same as interoperability Interoperability considerations: Same as interoperability
considerations of application/cbor as specified in [RFC7049]. considerations of application/cbor as specified in [RFC7049].
skipping to change at page 24, line 26 skipping to change at page 24, line 41
Person to contact for further information: teep@ietf.org Person to contact for further information: teep@ietf.org
Intended usage: COMMON Intended usage: COMMON
Restrictions on usage: none Restrictions on usage: none
Author: See the "Authors' Addresses" section of this document Author: See the "Authors' Addresses" section of this document
Change controller: IETF Change controller: IETF
9.2. Ciphersuite Registry 10.2. Ciphersuite Registry
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 7. defined in Section 7.
9.3. CBOR Tag Registry 10.3. Freshness Mechanism Registry
IANA is also requested to create a new registry for freshness
mechanisms, as defined in Section 8.
10.4. CBOR Tag Registry
IANA is requested to register a CBOR tag in the "CBOR Tags" registry IANA is requested to register a CBOR tag in the "CBOR Tags" registry
for use with TEEP messages. for use with TEEP messages.
The registry contents is: The registry contents is:
o CBOR Tag: TBD1 o CBOR Tag: TBD1
o Data Item: TEEP Message o Data Item: TEEP Message
o Semantics: TEEP Message, as defined in [[TBD: This RFC]] o Semantics: TEEP Message, as defined in draft-ietf-teep-protocol
(TODO: replace with RFC once published)
o Reference: [[TBD: This RFC]] o Reference: draft-ietf-teep-protocol (TODO: replace with RFC once
published)
o Point of Contact: TEEP working group (teep@ietf.org) o Point of Contact: TEEP working group (teep@ietf.org)
10. References 11. References
10.1. Normative References 11.1. Normative References
[I-D.ietf-rats-architecture] [I-D.ietf-rats-architecture]
Birkholz, H., Thaler, D., Richardson, M., Smith, N., and Birkholz, H., Thaler, D., Richardson, M., Smith, N., and
W. Pan, "Remote Attestation Procedures Architecture", W. Pan, "Remote Attestation Procedures Architecture",
draft-ietf-rats-architecture-08 (work in progress), draft-ietf-rats-architecture-12 (work in progress), April
December 2020. 2021.
[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-06 (work in progress), December 2020. ietf-rats-eat-10 (work in progress), June 2021.
[I-D.ietf-suit-manifest] [I-D.ietf-suit-manifest]
Moran, B., Tschofenig, H., Birkholz, H., and K. Zandberg, Moran, B., Tschofenig, H., Birkholz, H., and K. Zandberg,
"A Concise Binary Object Representation (CBOR)-based "A Concise Binary Object Representation (CBOR)-based
Serialization Format for the Software Updates for Internet Serialization Format for the Software Updates for Internet
of Things (SUIT) Manifest", draft-ietf-suit-manifest-11 of Things (SUIT) Manifest", draft-ietf-suit-manifest-14
(work in progress), December 2020. (work in progress), July 2021.
[I-D.moran-suit-report] [I-D.moran-suit-report]
Moran, B., "Secure Reporting of Update Status", draft- Moran, B., "Secure Reporting of Update Status", draft-
moran-suit-report-00 (work in progress), October 2020. moran-suit-report-01 (work in progress), February 2021.
[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, <https://www.rfc- DOI 10.17487/RFC2119, March 1997,
editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[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, <https://www.rfc-
editor.org/info/rfc2560>.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
2003, <https://www.rfc-editor.org/info/rfc3629>. 2003, <https://www.rfc-editor.org/info/rfc3629>.
[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>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/info/rfc5280>.
[RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A.,
Galperin, S., and C. Adams, "X.509 Internet Public Key
Infrastructure Online Certificate Status Protocol - OCSP",
RFC 6960, DOI 10.17487/RFC6960, June 2013,
<https://www.rfc-editor.org/info/rfc6960>.
[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>.
[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>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
10.2. Informative References 11.2. Informative References
[I-D.birkholz-rats-suit-claims] [I-D.birkholz-rats-suit-claims]
Birkholz, H. and B. Moran, "Trustworthiness Vectors for Birkholz, H. and B. Moran, "Trustworthiness Vectors for
the Software Updates of Internet of Things (SUIT) Workflow the Software Updates of Internet of Things (SUIT) Workflow
Model", draft-birkholz-rats-suit-claims-01 (work in Model", draft-birkholz-rats-suit-claims-02 (work in
progress), January 2021. progress), July 2021.
[I-D.ietf-teep-architecture] [I-D.ietf-teep-architecture]
Pei, M., Tschofenig, H., Thaler, D., and D. Wheeler, Pei, M., Tschofenig, H., Thaler, D., and D. Wheeler,
"Trusted Execution Environment Provisioning (TEEP) "Trusted Execution Environment Provisioning (TEEP)
Architecture", draft-ietf-teep-architecture-13 (work in Architecture", draft-ietf-teep-architecture-15 (work in
progress), November 2020. progress), July 2021.
[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>.
[RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data
Definition Language (CDDL): A Notational Convention to Definition Language (CDDL): A Notational Convention to
Express Concise Binary Object Representation (CBOR) and Express Concise Binary Object Representation (CBOR) and
JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,
skipping to change at page 28, line 4 skipping to change at page 28, line 33
; message type numbers, uint (0..23) ; message type numbers, uint (0..23)
TEEP-TYPE-query-request = 1 TEEP-TYPE-query-request = 1
TEEP-TYPE-query-response = 2 TEEP-TYPE-query-response = 2
TEEP-TYPE-update = 3 TEEP-TYPE-update = 3
TEEP-TYPE-teep-success = 5 TEEP-TYPE-teep-success = 5
TEEP-TYPE-teep-error = 6 TEEP-TYPE-teep-error = 6
version = .within uint .size 4 version = .within uint .size 4
ext-info = .within uint .size 4 ext-info = .within uint .size 4
; data items as bitmaps ; data items as bitmaps
data-item-requested = $data-item-requested .within uint .size 8 data-item-requested = $data-item-requested .within uint .size 8
attestation = 1 attestation = 1
$data-item-requested /= attestation $data-item-requested /= attestation
trusted-components = 2 trusted-components = 2
$data-item-requested /= trusted-components $data-item-requested /= trusted-components
extensions = 4 extensions = 4
$data-item-requested /= extensions $data-item-requested /= extensions
suit-commands = 8 suit-commands = 8
$data-item-requested /= suit-commands $data-item-requested /= suit-commands
query-request = [ query-request = [
type: TEEP-TYPE-query-request, type: TEEP-TYPE-query-request,
options: { options: {
? token => bstr .size (8..64), ? token => bstr .size (8..64),
? supported-cipher-suites => [ + suite ], ? supported-cipher-suites => [ + suite ],
? challenge => bstr .size (8..64), ? supported-freshness-mechanisms => [ + freshness-mechanism ],
? challenge => bstr .size (8..512),
? versions => [ + version ], ? versions => [ + version ],
? ocsp-data => bstr, ? ocsp-data => bstr,
* $$query-request-extensions * $$query-request-extensions
* $$teep-option-extensions * $$teep-option-extensions
}, },
data-item-requested: data-item-requested data-item-requested: data-item-requested
] ]
; ciphersuites ; ciphersuites
suite = $TEEP-suite .within uint .size 4 suite = $TEEP-suite .within uint .size 4
TEEP-AES-CCM-16-64-128-HMAC256--256-X25519-EdDSA = 1 TEEP-AES-CCM-16-64-128-HMAC256--256-X25519-EdDSA = 1
TEEP-AES-CCM-16-64-128-HMAC256--256-P-256-ES256 = 2 TEEP-AES-CCM-16-64-128-HMAC256--256-P-256-ES256 = 2
$TEEP-suite /= TEEP-AES-CCM-16-64-128-HMAC256--256-X25519-EdDSA $TEEP-suite /= TEEP-AES-CCM-16-64-128-HMAC256--256-X25519-EdDSA
$TEEP-suite /= TEEP-AES-CCM-16-64-128-HMAC256--256-P-256-ES256 $TEEP-suite /= TEEP-AES-CCM-16-64-128-HMAC256--256-P-256-ES256
; freshness-mechanisms
freshness-mechanism = $TEEP-freshness-mechanism .within uint .size 4
FRESHNESS_NONCE = 0
FRESHNESS_TIMESTAMP = 1
FRESHNESS_EPOCH_ID = 2
$TEEP-freshness-mechanism /= FRESHNESS_NONCE
$TEEP-freshness-mechanism /= FRESHNESS_TIMESTAMP
$TEEP-freshness-mechanism /= FRESHNESS_EPOCH_ID
query-response = [ query-response = [
type: TEEP-TYPE-query-response, type: TEEP-TYPE-query-response,
options: { options: {
? token => bstr .size (8..64), ? token => bstr .size (8..64),
? selected-cipher-suite => suite, ? selected-cipher-suite => suite,
? selected-version => version, ? selected-version => version,
? evidence-format => text, ? evidence-format => text,
? evidence => bstr, ? evidence => bstr,
? tc-list => [ + tc-info ], ? tc-list => [ + tc-info ],
? requested-tc-list => [ + requested-tc-info ], ? requested-tc-list => [ + requested-tc-info ],
skipping to change at page 29, line 4 skipping to change at page 29, line 46
? selected-cipher-suite => suite, ? selected-cipher-suite => suite,
? selected-version => version, ? selected-version => version,
? evidence-format => text, ? evidence-format => text,
? evidence => bstr, ? evidence => bstr,
? tc-list => [ + tc-info ], ? tc-list => [ + tc-info ],
? requested-tc-list => [ + requested-tc-info ], ? requested-tc-list => [ + requested-tc-info ],
? unneeded-tc-list => [ + SUIT_Component_Identifier ], ? unneeded-tc-list => [ + SUIT_Component_Identifier ],
? ext-list => [ + ext-info ], ? ext-list => [ + ext-info ],
* $$query-response-extensions, * $$query-response-extensions,
* $$teep-option-extensions * $$teep-option-extensions
} }
] ]
tc-info = { tc-info = {
component-id => SUIT_Component_Identifier, component-id => SUIT_Component_Identifier,
? tc-manifest-sequence-number => .within uint .size 8 ? tc-manifest-sequence-number => .within uint .size 8
} }
requested-tc-info = { requested-tc-info = {
component-id => SUIT_Component_Identifier, component-id => SUIT_Component_Identifier,
? tc-manifest-sequence-number => .within uint .size 8 ? tc-manifest-sequence-number => .within uint .size 8
? have-binary => bool ? have-binary => bool
} }
update = [ update = [
type: TEEP-TYPE-update, type: TEEP-TYPE-update,
options: { options: {
? token => bstr .size (8..64), ? token => bstr .size (8..64),
? unneeded-tc-list => [ + SUIT_Component_Identifier ],
? manifest-list => [ + bstr .cbor SUIT_Envelope ], ? manifest-list => [ + bstr .cbor SUIT_Envelope ],
* $$update-extensions, * $$update-extensions,
* $$teep-option-extensions * $$teep-option-extensions
} }
] ]
teep-success = [ teep-success = [
type: TEEP-TYPE-teep-success, type: TEEP-TYPE-teep-success,
options: { options: {
? token => bstr .size (8..64), ? token => bstr .size (8..64),
skipping to change at page 29, line 47 skipping to change at page 30, line 40
* $$teep-option-extensions * $$teep-option-extensions
} }
] ]
teep-error = [ teep-error = [
type: TEEP-TYPE-teep-error, type: TEEP-TYPE-teep-error,
options: { options: {
? token => bstr .size (8..64), ? token => bstr .size (8..64),
? err-msg => text .size (1..128), ? err-msg => text .size (1..128),
? supported-cipher-suites => [ + suite ], ? supported-cipher-suites => [ + suite ],
? supported-freshness-mechanisms => [ + freshness-mechanism ],
? versions => [ + version ], ? versions => [ + version ],
? suit-reports => [ + suit-report ], ? suit-reports => [ + suit-report ],
* $$teep-error-extensions, * $$teep-error-extensions,
* $$teep-option-extensions * $$teep-option-extensions
}, },
err-code: uint (0..23) err-code: uint (0..23)
] ]
; The err-code parameter, uint (0..23) ; The err-code parameter, uint (0..23)
ERR_PERMANENT_ERROR = 1 ERR_PERMANENT_ERROR = 1
ERR_UNSUPPORTED_EXTENSION = 2 ERR_UNSUPPORTED_EXTENSION = 2
ERR_UNSUPPORTED_MSG_VERSION = 4 ERR_UNSUPPORTED_MSG_VERSION = 4
ERR_UNSUPPORTED_CRYPTO_ALG = 5 ERR_UNSUPPORTED_CRYPTO_ALG = 5
ERR_BAD_CERTIFICATE = 6 ERR_BAD_CERTIFICATE = 6
ERR_CERTIFICATE_EXPIRED = 9 ERR_CERTIFICATE_EXPIRED = 9
ERR_TEMPORARY_ERROR = 10 ERR_TEMPORARY_ERROR = 10
skipping to change at page 30, line 45 skipping to change at page 31, line 38
have-binary = 18 have-binary = 18
suit-reports = 19 suit-reports = 19
token = 20 token = 20
D. Examples of Diagnostic Notation and Binary Representation D. Examples of Diagnostic Notation and Binary Representation
D.1. Some assumptions in examples D.1. Some assumptions in examples
o OCSP stapling data = h'010203' o OCSP stapling data = h'010203'
o TEEP Device will have 2 TAs with the following SUIT Component o TEEP Device will have two TCs with the following SUIT Component
Identifiers: Identifiers:
* [ 0x0102030405060708090a0b0c0d0e0f ] * [ 0x000102030405060708090a0b0c0d0e0f ]
* [ 0x1102030405060708090a0b0c0d0e0f ] * [ 0x100102030405060708090a0b0c0d0e0f ]
o SUIT manifest-list is set empty only for example purposes o SUIT manifest-list is set empty only for example purposes
D.2. QueryRequest Message D.2. QueryRequest Message
D.2.1. CBOR Diagnostic Notation D.2.1. CBOR Diagnostic Notation
/ query-request = / / query-request = /
[ [
1, / type : TEEP-TYPE-query-request = 1 (uint (0..23)) / 1, / type : TEEP-TYPE-query-request = 1 (uint (0..23)) /
/ options : / / options : /
{ {
20 : 0xa0a1a2a3a4a5a6a7, 20 : 0xa0a1a2a3a4a5a6a7a8a9aaabacadaeaf,
/ token = 20 (mapkey) : / token = 20 (mapkey) :
h'a0a1a2a3a4a5a6a7' (bstr .size (8..64)), h'a0a1a2a3a4a5a6a7a8a9aaabacadaeaf' (bstr .size (8..64)),
generated by TAM / generated by TAM /
1 : [ 1 ], / supported-cipher-suites = 1 (mapkey) : 1 : [ 1 ], / supported-cipher-suites = 1 (mapkey) :
TEEP-AES-CCM-16-64-128-HMAC256--256-X25519-EdDSA = TEEP-AES-CCM-16-64-128-HMAC256--256-X25519-EdDSA =
[ 1 ] (array of .within uint .size 4) / [ 1 ] (array of .within uint .size 4) /
3 : [ 0 ], / version = 3 (mapkey) : 3 : [ 0 ], / version = 3 (mapkey) :
[ 0 ] (array of .within uint .size 4) / [ 0 ] (array of .within uint .size 4) /
4 : h'010203' / ocsp-data = 4 (mapkey) : 0x010203 (bstr) / 4 : h'010203' / ocsp-data = 4 (mapkey) : 0x010203 (bstr) /
}, },
3 / data-item-requested : 3 / data-item-requested :
attestation | trusted-components = 3 (.within uint .size 8) / attestation | trusted-components = 3 (.within uint .size 8) /
] ]
D.2.2. CBOR Binary Representation D.2.2. CBOR Binary Representation
83 # array(3) 83 # array(3)
01 # unsigned(1) uint (0..23) 01 # unsigned(1) uint (0..23)
A4 # map(4) A4 # map(4)
14 # unsigned(20) uint (0..23) 14 # unsigned(20) uint (0..23)
48 # bytes(8) (8..64) 4F # bytes(16) (8..64)
A0A1A2A3A4A5A6A7 A0A1A2A3A4A5A6A7A8A9AAABACADAEAF
01 # unsigned(1) uint (0..23) 01 # unsigned(1) uint (0..23)
81 # array(1) 81 # array(1)
01 # unsigned(1) within uint .size 4 01 # unsigned(1) within uint .size 4
03 # unsigned(3) uint (0..23) 03 # unsigned(3) uint (0..23)
81 # array(1) 81 # array(1)
00 # unsigned(0) within uint .size 4 00 # unsigned(0) within uint .size 4
04 # unsigned(4) uint (0..23) 04 # unsigned(4) uint (0..23)
43 # bytes(3) 43 # bytes(3)
010203 # "\x01\x02\x03" 010203 # "\x01\x02\x03"
03 # unsigned(3) .within uint .size 8 03 # unsigned(3) .within uint .size 8
D.3. Entity Attestation Token D.3. Entity Attestation Token
This is shown below in CBOR diagnostic form. Only the payload signed This is shown below in CBOR diagnostic form. Only the payload signed
by COSE is shown. by COSE is shown.
D.3.1. CBOR Diagnostic Notation D.3.1. CBOR Diagnostic Notation
/ eat-claim-set = / / eat-claim-set = /
{ {
/ issuer / 1: "joe", / issuer / 1: "joe",
/ timestamp (iat) / 6: 1(1526542894) / timestamp (iat) / 6: 1(1526542894)
/ nonce / 10: h'948f8860d13a463e8e', / nonce / 10: h'948f8860d13a463e8e',
/ secure-boot / 15: true, / secure-boot / 15: true,
/ debug-status / 16: 3, / disabled-permanently / / debug-status / 16: 3, / disabled-permanently /
/ security-level / <TBD>: 3, / secure-restricted / / security-level / <TBD>: 3, / secure-restricted /
/ device-identifier / <TBD>: h'e99600dd921649798b013e9752dcf0c5', / device-identifier / <TBD>: h'e99600dd921649798b013e9752dcf0c5',
/ vendor-identifier / <TBD>: h'2b03879b33434a7ca682b8af84c19fd4', / vendor-identifier / <TBD>: h'2b03879b33434a7ca682b8af84c19fd4',
/ class-identifier / <TBD>: h'9714a5796bd245a3a4ab4f977cb8487f', / class-identifier / <TBD>: h'9714a5796bd245a3a4ab4f977cb8487f',
/ chip-version-scheme / <TBD35>: "MyTEE v1.0", / chip-version-scheme / <TBD>: "MyTEE v1.0",
/ component-identifier / <TBD>: h'60822887d35e43d5b603d18bcaa3f08d', / component-identifier / <TBD>: h'60822887d35e43d5b603d18bcaa3f08d',
/ version / <TBD>: "v0.1" / version / <TBD>: "v0.1"
} }
D.4. QueryResponse Message D.4. QueryResponse Message
D.4.1. CBOR Diagnostic Notation D.4.1. CBOR Diagnostic Notation
/ query-response = / / query-response = /
[ [
2, / type : TEEP-TYPE-query-response = 2 (uint (0..23)) / 2, / type : TEEP-TYPE-query-response = 2 (uint (0..23)) /
/ options : / / options : /
{ {
20 : 0xa0a1a2a3a4a5a6a7, 20 : 0xa0a1a2a3a4a5a6a7a8a9aaabacadaeaf,
/ token = 20 (mapkey) : / token = 20 (mapkey) :
h'a0a1a2a3a4a5a6a7' (bstr .size (8..64)), h'a0a1a2a3a4a5a6a7a8a9aaabacadaeaf' (bstr .size (8..64)),
given from TAM's QueryRequest message / given from TAM's QueryRequest message /
5 : 1, / selected-cipher-suite = 5 (mapkey) : 5 : 1, / selected-cipher-suite = 5 (mapkey) :
TEEP-AES-CCM-16-64-128-HMAC256--256-X25519-EdDSA = TEEP-AES-CCM-16-64-128-HMAC256--256-X25519-EdDSA =
1 (.within uint .size 4) / 1 (.within uint .size 4) /
6 : 0, / selected-version = 6 (mapkey) : 6 : 0, / selected-version = 6 (mapkey) :
0 (.within uint .size 4) / 0 (.within uint .size 4) /
7 : ... / evidence = 7 (mapkey) : 7 : ... / evidence = 7 (mapkey) :
Entity Attestation Token / Entity Attestation Token /
8 : [ / tc-list = 8 (mapkey) : (array of tc-info) / 8 : [ / tc-list = 8 (mapkey) : (array of tc-info) /
{ {
16 : [ 0x0102030405060708090a0b0c0d0e0f ] / component-id = 16 : [ 0x000102030405060708090a0b0c0d0e0f ] / component-id =
16 (mapkey) : [ h'0102030405060708090a0b0c0d0e0f' ] 16 (mapkey) : [ h'000102030405060708090a0b0c0d0e0f' ]
(SUIT_Component_Identifier = [* bstr]) / (SUIT_Component_Identifier = [* bstr]) /
}, },
{ {
16 : [ 0x1102030405060708090a0b0c0d0e0f ] / component-id = 16 : [ 0x100102030405060708090a0b0c0d0e0f ] / component-id =
16 (mapkey) : [ h'1102030405060708090a0b0c0d0e0f' ] 16 (mapkey) : [ h'100102030405060708090a0b0c0d0e0f' ]
(SUIT_Component_Identifier = [* bstr]) / (SUIT_Component_Identifier = [* bstr]) /
}
]
} }
] ]
}
]
D.4.2. CBOR Binary Representation D.4.2. CBOR Binary Representation
82 # array(2) 82 # array(2)
02 # unsigned(2) uint (0..23) 02 # unsigned(2) uint (0..23)
A5 # map(5) A5 # map(5)
14 # unsigned(20) uint (0..23) 14 # unsigned(20) uint (0..23)
48 # bytes(8) (8..64) 4F # bytes(16) (8..64)
A0A1A2A3A4A5A6A7 A0A1A2A3A4A5A6A7A8A9AAABACADAEAF
05 # unsigned(5) uint (0..23) 05 # unsigned(5) uint (0..23)
01 # unsigned(1) .within uint .size 4 01 # unsigned(1) .within uint .size 4
06 # unsigned(6) uint (0..23) 06 # unsigned(6) uint (0..23)
00 # unsigned(0) .within uint .size 4 00 # unsigned(0) .within uint .size 4
07 # unsigned(7) uint (0..23) 07 # unsigned(7) uint (0..23)
... # Entity Attestation Token ... # Entity Attestation Token
08 # unsigned(8) uint (0..23) 08 # unsigned(8) uint (0..23)
82 # array(2) 82 # array(2)
81 # array(1) 81 # array(1)
4F # bytes(15) 4F # bytes(16)
0102030405060708090A0B0C0D0E0F 000102030405060708090A0B0C0D0E0F
81 # array(1) 81 # array(1)
4F # bytes(15) 4F # bytes(16)
1102030405060708090A0B0C0D0E0F 100102030405060708090A0B0C0D0E0F
D.5. Update Message D.5. Update Message
D.5.1. CBOR Diagnostic Notation D.5.1. CBOR Diagnostic Notation
/ update = / / update = /
[ [
3, / type : TEEP-TYPE-update = 3 (uint (0..23)) / 3, / type : TEEP-TYPE-update = 3 (uint (0..23)) /
/ options : / / options : /
{ {
20 : 0xaba1a2a3a4a5a6a7, 20 : 0xa0a1a2a3a4a5a6a7a8a9aaabacadaeaf,
/ token = 20 (mapkey) : / token = 20 (mapkey) :
h'aba1a2a3a4a5a6a7' (bstr .size (8..64)), h'a0a1a2a3a4a5a6a7a8a9aaabacadaeaf' (bstr .size (8..64)),
generated by TAM / generated by TAM /
15 : [ [ h'0102030405060708090a0b0c0d0e0f' ] ] 10 : [ ] / manifest-list = 10 (mapkey) :
/ unneeded-tc-list = 15 (mapkey) : [ ] (array of bstr wrapped SUIT_Envelope(any)) /
[ [ h'0102030405060708090a0b0c0d0e0f' ] ] / empty, example purpose only /
(array of SUIT_Component_Identifier = [* bstr]) / }
10 : [ ] / manifest-list = 10 (mapkey) : ]
[ ] (array of bstr wrapped SUIT_Envelope(any)) /
/ empty, example purpose only /
}
]
D.5.2. CBOR Binary Representation D.5.2. CBOR Binary Representation
82 # array(2) 82 # array(2)
03 # unsigned(3) uint (0..23) 03 # unsigned(3) uint (0..23)
A3 # map(3) A3 # map(3)
14 # unsigned(20) uint (0..23) 14 # unsigned(20) uint (0..23)
48 # bytes(8) (8..64) 4F # bytes(16) (8..64)
ABA1A2A3A4A5A6A7 A0A1A2A3A4A5A6A7A8A9AAABACADAEAF
0F # unsigned(15) uint (0..23)
81 # array(1)
81 # array(1)
4F # bytes(15)
0102030405060708090A0B0C0D0E0F
0A # unsigned(10) uint (0..23) 0A # unsigned(10) uint (0..23)
80 # array(0) 80 # array(0)
D.6. Success Message D.6. Success Message
D.6.1. CBOR Diagnostic Notation D.6.1. CBOR Diagnostic Notation
/ teep-success = / / teep-success = /
[ [
5, / type : TEEP-TYPE-teep-success = 5 (uint (0..23)) / 5, / type : TEEP-TYPE-teep-success = 5 (uint (0..23)) /
/ options : / / options : /
{ {
20 : 0xaba1a2a3a4a5a6a7, 20 : 0xa0a1a2a3a4a5a6a7a8a9aaabacadaeaf,
/ token = 20 (mapkey) : / token = 20 (mapkey) :
h'aba1a2a3a4a5a6a7' (bstr .size (8..64)), h'a0a1a2a3a4a5a6a7a8a9aaabacadaeaf' (bstr .size (8..64)),
given from TAM's Update message / given from TAM's Update message /
} }
] ]
D.6.2. CBOR Binary Representation D.6.2. CBOR Binary Representation
82 # array(2) 82 # array(2)
05 # unsigned(5) uint (0..23) 05 # unsigned(5) uint (0..23)
A1 # map(1) A1 # map(1)
14 # unsigned(20) uint (0..23) 14 # unsigned(20) uint (0..23)
48 # bytes(8) (8..64) 4F # bytes(16) (8..64)
ABA1A2A3A4A5A6A7 A0A1A2A3A4A5A6A7A8A9AAABACADAEAF
D.7. Error Message D.7. Error Message
D.7.1. CBOR Diagnostic Notation D.7.1. CBOR Diagnostic Notation
/ teep-error = / / teep-error = /
[ [
6, / type : TEEP-TYPE-teep-error = 6 (uint (0..23)) / 6, / type : TEEP-TYPE-teep-error = 6 (uint (0..23)) /
/ options : / / options : /
{ {
20 : 0xaba1a2a3a4a5a6a7, 20 : 0xa0a1a2a3a4a5a6a7a8a9aaabacadaeaf,
/ token = 20 (mapkey) : / token = 20 (mapkey) :
h'aba1a2a3a4a5a6a7' (bstr .size (8..64)), h'a0a1a2a3a4a5a6a7a8a9aaabacadaeaf' (bstr .size (8..64)),
given from TAM's Update message / given from TAM's Update message /
12 : "disk-full" / err-msg = 12 (mapkey) : 12 : "disk-full" / err-msg = 12 (mapkey) :
"disk-full" (text .size (1..128)) / "disk-full" (text .size (1..128)) /
}, },
17, / err-code : ERR_MANIFEST_PROCESSING_FAILED = 17 (uint (0..23)) / 17, / err-code : ERR_MANIFEST_PROCESSING_FAILED = 17 (uint (0..23)) /
] ]
D.7.2. CBOR binary Representation D.7.2. CBOR binary Representation
83 # array(3) 83 # array(3)
06 # unsigned(6) uint (0..23) 06 # unsigned(6) uint (0..23)
A2 # map(2) A2 # map(2)
14 # unsigned(20) uint (0..23) 14 # unsigned(20) uint (0..23)
48 # bytes(8) (8..64) 4F # bytes(16) (8..64)
ABA1A2A3A4A5A6A7 A0A1A2A3A4A5A6A7A8A9AAABACADAEAF
0C # unsigned(12) uint (0..23) 0C # unsigned(12) uint (0..23)
69 # text(9) (1..128) 69 # text(9) (1..128)
6469736b2d66756c6c # "disk-full" 6469736B2D66756C6C # "disk-full"
11 # unsigned(17) uint (0..23) 11 # unsigned(17) uint (0..23)
Authors' Addresses Authors' Addresses
Hannes Tschofenig Hannes Tschofenig
Arm Ltd. Arm Ltd.
Absam, Tirol 6067 Absam, Tirol 6067
Austria Austria
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
David Wheeler David Wheeler
Intel Amazon
US US
Email: david.m.wheeler@intel.com Email: davewhee@amazon.com
Dave Thaler Dave Thaler
Microsoft Microsoft
US US
Email: dthaler@microsoft.com Email: dthaler@microsoft.com
Akira Tsukamoto Akira Tsukamoto
AIST AIST
JP JP
 End of changes. 104 change blocks. 
351 lines changed or deleted 439 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/