]> Guidelines for Security Considerations of RATS TU Dresden
muhammad_usama.sardar@tu-dresden.de
RATS Working Group security considerations remote attestation This document aims to provide guidelines and best practices for writing security considerations for technical specifications for RATS targeting the needs of implementers, researchers, and protocol designers. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Source for this draft and an issue tracker can be found at .
Introduction While provides excellent guidelines, remote attestation has several distinguishing features which necessitate a separate document. One specific example of such feature is architectural complexity.
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.
General Hierarchy of Authentication proposes general hierarchy of one-way authentication, which can help precisely state the intended level of authentication (in decreasing order):
  • One-way injective agreement
  • One-way non-injective agreement
  • Aliveness
Recentness can be added to each of these levels of authentication.
Attacks Security considerations in RATS specifications need to clarify how the following attacks are avoided or mitigated:
  • Diversion attacks
  • Relay attacks
  • Replay attacks
Examples of Specifications That Could Be Improved
RFC9334
Unprotected Evidence has:
A conveyance protocol that provides authentication and integrity protection can be used to convey Evidence that is otherwise unprotected (e.g., not signed).
Using a conveyance protocol that provides authentication and integrity protection, such as TLS 1.3 , to convey Evidence that is otherwise unprotected (e.g., not signed) undermines all security of remote attestation. Essentially, this breaks the chain up to the trust anchor (such as hardware manufacturer) for remote attestation. Hence, remote attestation effectively provides no protection in this case and the security guarantees are limited to those of the conveyance protocol only. In order to benefit from remote attestation, Evidence MUST be protected using dedicated keys chaining back to the trust anchor for remote attestation.
Missing Roles and Conceptual Messages
  • Identity Supplier and its corresponding conceptual message Identity are missing and need to be added to the architecture .
  • Attestation Challenge as conceptual message needs to be added to the architecture .
Examples of Specifications That Are Detrimental for Security We believe that the following drafts are detrimental for the RATS ecosystem:
  • Multi-Verifiers : the design of multi-verifiers not only increase security risks in terms of increasing the Trusted Computing Base (TCB), but also increases the privacy risks, as potentially sensitive information is sent to multiple verifiers.
  • Aggregator-based design : Aggregator is an explicit trust anchor and the addition of new trust anchor needs to have a strong justification.
Security Considerations All of this document is about security considerations.
IANA Considerations This document has no IANA actions.
References Normative References Remote ATtestation procedureS (RATS) Architecture 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. Key words for use in RFCs to Indicate Requirement Levels 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. Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words 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. Informative References The Transport Layer Security (TLS) Protocol Version 1.3 This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations. Identity Crisis in Attested TLS for Confidential Computing Perspicuity of Attestation Mechanisms in Confidential Computing: Technical Concepts Perspicuity of Attestation Mechanisms in Confidential Computing: General Approach Guidelines for Writing Cryptography Specifications Cryptography Consulting LLC Cloudflare, Inc. This document provides guidelines and best practices for writing technical specifications for cryptography protocols and primitives, targeting the needs of implementers, researchers, and protocol designers. It highlights the importance of technical specifications and discusses strategies for creating high-quality specifications that cater to the needs of each community, including guidance on representing mathematical operations, security definitions, and threat models. Remote Attestation with Multiple Verifiers Arm Ltd Huawei Technologies France S.A.S.U. Huawei Technologies France S.A.S.U. Fraunhofer SIT IETF RATS Architecture, defines the key role of a Verifier. In a complex system, this role needs to be performed by multiple Verfiers coordinating together to assess the full trustworthiness of an Attester. This document focuses on various topological patterns for a multiple Verifier system. It only covers the architectural aspects introduced by the Multi Verifier concept, which is neutral with regard to specific wire formats, encoding, transport mechanisms, or processing details. Concise Selector for Endorsements and Reference Values Arm Linaro Fraunhofer SIT Fujitsu AMD Alibaba Cloud In the Remote Attestation Procedures (RATS) architecture, Verifiers require Endorsements and Reference Values to assess the trustworthiness of Attesters. This document specifies the Concise Selector for Endorsements and Reference Values (CoSERV), a structured query/result format designed to facilitate the discovery and retrieval of these artifacts from various providers. CoSERV defines a query language and corresponding result structure using CDDL, which can be serialized in CBOR format, enabling efficient interoperability across diverse systems.
Acknowledgments The author wishes to thank Ira McDonald for insightful discussion. The author also gratefully acknowledges the authors of , which serves as the inspiration of this work.