]>

cfm@acm.org

hannes.tschofenig@gmx.net

Usable Formal Methods Proposed Research Group This draft follows the invitation of to propose another sample problem for demonstration, training, and evaluation of formal methods in IETF work. It draws on recent work from the Software Updates for the Internet of Things and Trusted Execution Environment Provisioning working groups to define a sample modeling problem for a novel rather than a familiar IETF protocol. Status information for this document may be found at . Discussion of this document takes place on the Usable Formal Methods Research Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction In this draft we take the Trusted Execution Environment Provisioning protocol to be a good domain from which to draw a sample modeling problem for slightly different reasons than those proposed in . TEEP is a proposed standard under active development, at working-group consensus as of this writing. Formal modeling, even for demonstration or training purposes, can therefore increase familiarity with the TEEP protocol, including outside of the SUIT and TEEP working groups directly involed in its development. The TEEP protocol is expressly concerned with security, so it has security properties amenable to formal description, modeling, and analysis. Any findings may have valuble security implications. The TEEP protocol has well-defined use cases and includes provisions for constrained environments. Modeling the entire protocol is a reasonble learning or training exercise, whereas limits itself to just the SEARCH command of . The TEEP protocol follows a typical protocol design in the IETF where various already standardized technologies are re-used. In this case, protocols from the Software Updates for Internet of Things (SUIT) architecture and from the Remote attestation procedures (RATS) architecture are incorporated into the design. The architecture of the TEEP protocol is also representative for IETF protocol development since more than two parties are involved in the communication even in a single deployment setup. Whether the formal model also has to consider all parties or a simplified design is subject for discussion. The TEEP protocol also provides a number of options to offer flexibility in different deployments. This is also a characteristic found in many IETF protocols. Dealing with the formal analysis of all options is a challenge.

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

The Trusted Execution Environment Provisioning (TEEP) Protocol The Trusted Execution Environment Provisioning protocol specifies communication between a Trusted Application Manager and a TEEP agent. Importantly, this communication is relayed by an untrusted TEEP Broker . Two security sensitive payloads are communicated via the TEEP protocol, namely: Trusted Applications (TAs) and Trusted Components (TCs), and Attestation Evidence. A Trusted Application is an application (or, in some implementations, an application component) that runs in a TEE. A Trusted Component is a set of code and/or data in a TEE managed as a unit by a Trusted Application Manager. Trusted Applications and Personalization Data are thus managed by being included in Trusted Components. TCs are provided by developers, or authors, and integrity and (optionally) confidentiality protected with the help of SUIT manifests. The TEEP protocol specification uses the term 'Trusted Component Signer' to refer to authors. Neither the TAM nor the TEEP Broker should be able to modify TCs. TEEP Agents only install TCs from sources they trust. Attestation Evidence on the other hand is typically communicated from the TEEP Agent to the TAM although there is the option to offer attestation capabilities in both directions. In the description below we only focus on attestation of the Device containing the TEEP Agent to the TAM rather than the other direction. The description below illustrates the basic communication interaction with details of the TEEP protocol abstracted away.

Verifier: NonceRequest TAM <- Verifier: NonceResponse Nonce ]]>

Legend: The 'challenge' is a random number provided by the Verifier. It is used to demonstrate freshness of attestation evidence.

TEEP Agent: QueryRequest {token, challenge, supported-teep-cipher-suites, supported-suit-cose-profiles, data-item-requested(trusted-components, attestation)}SK_TAM ]]>

Legend: The 'token' is a random number that is used to match the QueryRequest against the QueryRespose. 'supported-teep-cipher-suites' and 'supported-suit-cose-profiles' offer cipher suite negotation. 'data-item-requested(X)' indicates the functionality the TAM requests the TEEP Agent to perform. {_}SK_TAM indicates the a digital signature operation over the payload of the message using a private (or secret) key that is only known to the TAM.

Attester: EvidenceRequest Challenge TEEP Agent <- Attester: EvidenceResponse {Challenge, Claims}SK_Attester ]]>

Legend: '{Challenge, Claims}SK_Attester' represents the Evidence, which is signed by the Attester using its private key SK_Attester. In addition to the inclusion of the 'Challenge', the random number provided by the Verifier, it also includes further (unspecified) claims. While those claims are important for the overall system, they are not in scope of this analysis.

Legend: 'selected-teep-cipher-suite' indicates the selected cipher suite. 'attestation-payload-format(EAT)' indicates the format of the attached attestation evidence. 'tc-list' conveys the list of Trusted Components installed on the device. 'attestation-payload(_)' contains the evidence provided by the Attester in the previous step. The TEEP Agent signes the QueryResponse message with its private key, SK_AGENT.

TAM: SoftwareUpdate {manifest, sequence_nr, TC}SK_AUTHOR ]]>

Legend: The 'manifest' contains instructions for how to install the software. 'sequence_nr', as the name indicates, allows the TEEP Agent to distingush this update from earlier versions of the software. 'TC' is the Trusted Component to be installed. This could be a binary, configuration data, or both. The author, i.e. Trusted Component Signer, uses his private key, SK_AUTHOR, to sign the bundle.

TEEP Agent: Update {token2, {manifest, sequence_nr, software}SK_AUTHOR}SK_TAM ]]>

Legend: 'token2' is a new random number, which is again used by the TAM to match requests against responses. The TAM transmits an update to the TEEP Agent containing the previously obtained payloaded provided by the author. This payload is additionally signed with the TAM's private key, SK_TAM.

The TEEP Agent returns this message when the software installation was successful. The message is signed with the private key of the TEEP Agent, SK_AGENT.

Security Properties In addition to integrity and authentication properties, an important aspect is replay protection. At the meeting, the following editorial addition was proposed in TEEP's security consideration ():

• The TEEP protocol supports replay protection as follows. The transport protocol under the TEEP protocol might provide replay protection, but may be terminated in the TEEP Broker which is not trusted by the TEEP Agent and so the TEEP protocol does replay protection itself. If attestation of the TAM is used, the attestation freshness mechanism provides replay protection for attested QueryRequest messages. If non-attested QueryRequest messages are replayed, the TEEP Agent will generate QueryResponse or Error messages, but the REE can already conduct Denial of Service attacks against the TEE and/or the TAM even without the TEEP protocol. QueryResponse messages have replay protection via attestation freshness mechanism, or the token field in the message if attestation is not used. Update messages have replay protection via the suit-manifest-sequence-number (see Section 8.4.2 of [I-D.ietf-suit-manifest]). Error and Success messages have replay protection via SUIT Reports and/or the token field in the message, where a TAM can detect which message it is in response to.

Any formal model of TEEP should be able to prove this replay protection. While confidentiality protection is possible for both attestation evidence as well as Trusted Components, it is not mandatory-to-implement functionality.

Security Considerations This document has no security considerations of its own, although it may contribute indirectly to the development of new security considerations for the TEEP protocol.

IANA Considerations This document has no IANA actions.

Broadcom Amazon Microsoft ALAXALA Networks Corp. This document specifies a protocol that installs, updates, and deletes Trusted Components in a device with a Trusted Execution Environment (TEE). This specification defines an interoperable protocol for managing the lifecycle of Trusted Components. Vulnerabilities in Internet of Things (IoT) devices have raised the need for a reliable and secure firmware update mechanism suitable for devices with resource constraints. Incorporating such an update mechanism is a fundamental requirement for fixing vulnerabilities, but it also enables other important capabilities such as updating configuration settings and adding new functionality. In addition to the definition of terminology and an architecture, this document provides the motivation for the standardization of a manifest format as a transport-agnostic means for describing and protecting firmware updates. In network protocol exchanges, it is often useful for one end of a communication to know whether the other end is in an intended operating state. This document provides an architectural overview of the entities involved that make such tests possible through the process of generating, conveying, and evaluating evidentiary Claims. It provides a model that is neutral toward processor architectures, the content of Claims, and protocols. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. IETF IETF Trinity College, Dublin This draft provides reasoning as to why the Usable Formal Methods research group might benefit from having an IETF-relevant sample problem and describes one such (IMAP search). This is just an initial draft aiming to help move discussion forward so may be dropped or replaced by other drafts or the research group may prefer some non I-D format, or the research group may decide that sample problems aren't sufficiently useful. Early days, basically! The Internet Message Access Protocol Version 4rev2 (IMAP4rev2) allows a client to access and manipulate electronic mail messages on a server. IMAP4rev2 permits manipulation of mailboxes (remote message folders) in a way that is functionally equivalent to local folders. IMAP4rev2 also provides the capability for an offline client to resynchronize with the server. IMAP4rev2 includes operations for creating, deleting, and renaming mailboxes; checking for new messages; removing messages permanently; setting and clearing flags; parsing per RFCs 5322, 2045, and 2231; searching; and selective fetching of message attributes, texts, and portions thereof. Messages in IMAP4rev2 are accessed by the use of numbers. These numbers are either message sequence numbers or unique identifiers. IMAP4rev2 does not specify a means of posting mail; this function is handled by a mail submission protocol such as the one specified in RFC 6409. A Trusted Execution Environment (TEE) is an environment that enforces the following: any code within the environment cannot be tampered with, and any data used by such code cannot be read or tampered with by any code outside the environment. This architecture document discusses the motivation for designing and standardizing a protocol for managing the lifecycle of Trusted Applications running inside such a TEE.