]> Arm Limited

brendan.moran.ietf@gmail.com

Security IOTOPS Internet-Draft The IETF has developed security technologies that help to secure the Internet of Things even over constrained networks and when targetting constrained nodes. These technologies can be used independenly or can be composed into larger systems to mitigate a variety of threats. This documents illustrates an overview over these technologies and highlights their relationships. Ultimately, a threat model is presented as a basis to derive requirements that interconnect existing and emerging solution technologies.

Introduction This memo serves as an entry-point to detail which technologies are available for use in IoT networks and to enable IoT designers to discover technologies that may solve their problems. This draft addresses. Many baseline security requirements documents have been drafted by standards setting organisations, however these documents typically do not specify the technologies available to satisfy those requirements. They also do not express the next steps if an implementor wants to go above and beyond the baseline in order to differentiate their products and enable even better security. This memo defines the mapping from some IoT baseline security requirements definitions to ietf and related security technologies. It also highlights some gaps in those IoT baseline security requirements.

Conventions and Terminology 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.

Survey of baseline security requirements At time of writing, there are IoT baseline security requirements provided by several organisations: ENISA's Baseline Security Recommendations for IoT in the context of Critical Information Infrastructures () ETSI's Cyber Security for Consumer Internet of Things: Baseline Requirements NIST's IoT Device Cybersecurity Capability Core Baseline

Requirement Mapping Requirements that pertain to hardware, procedure, and policy compliance are noted, but do not map to ietf and related technologies. NIST's requirements () are very broad and already have mappings to ENISA baseline security recommendations.

Hardware Security

Identity ENISA GP-PS-10: Establish and maintain asset management procedures and configuration controls for key network and information systems. NIST Device Identification: The IoT device can be uniquely identified logically and physically. These requirements are architectural requirements, however can be used for identifiers.

Hardware Immutable Root of Trust ENISA GP-TM-01: Employ a hardware-based immutable root of trust. This is an architectural requirement.

Hardware-Backed Secret Storage ENISA GP-TM-02: Use hardware that incorporates security features to strengthen the protection and integrity of the device - for example, specialized security chips / coprocessors that integrate security at the transistor level, embedded in the processor, providing, among other things, a trusted storage of device identity and authentication means, protection of keys at rest and in use, and preventing unprivileged from accessing to security sensitive code. Protection against local and physical attacks can be covered via functional security. NIST Data Protection: The ability to use demonstrably secure cryptographic modules for standardized cryptographic algorithms (e.g., encryption with authentication, cryptographic hashes, digital signature validation) to prevent the confidentiality and integrity of the device’s stored and transmitted data from being compromised This is an architectural requirement.

Software Integrity & Authenticity

Boot Environment Trustworthiness and Integrity ENISA GP-TM-03: Trust must be established in the boot environment before any trust in any other software or executable program can be claimed. Satisfying this requirement can be done in several ways, increasing in security guarantees: Implement secure boot to verify the bootloader and boot environment. Trust is established purely by construction: if code is running in the boot environment, it must have been signed, therefore it is trustworthy. Record critical measurements of each step of boot in a TPM. Trust is established by evaluating the measurements recorded by the TPM. Use Remote Attestation. Remote attestation allows a device to report to third parties the critical measurements it has recorded (either in a TPM or signed by each stage) in order to prove the trustworthiness of the boot environment and running software. Remote Attestation is implemented in .

Code Integrity and Authenticity ENISA GP-TM-04: Sign code cryptographically to ensure it has not been tampered with after signing it as safe for the device, and implement run-time protection and secure execution monitoring to make sure malicious attacks do not overwrite code after it is loaded. Satisfying this requirement requires a secure invocation mechanism. In monolithic IoT software images, this is accomplished by Secure Boot. In IoT devices with more fully-featured operating systems, this is accomplished with an operating system-specific code signing practice. Secure Invocation can be achieved using the SUIT Manifest format, which provides for secure invocation procedures. See . To satisfy the associated requirement of run-time protection and secure execution monitoring, the use of a TEE is recommended to protect sensitive processes. The TEEP protocol (see ) is recommended for managing TEEs.

Secure Firmware Update ENISA GP-TM-05: Control the installation of software in operating systems, to prevent unauthenticated software and files from being loaded onto it. NIST Software Update: The ability to update the device’s software through remote (e.g., network download) and/or local means (e.g., removable media) The ability to verify and authenticate any update before installing it The ability for authorized entities to roll back updated software to a previous version The ability to restrict updating actions to authorized entities only The ability to enable or disable updating Configuration settings for use with the Device Configuration capability including, but not limited to: The ability to configure any remote update mechanisms to be either automatically or manually initiated for update downloads and installations The ability to enable or disable notification when an update is available and specify who or what is to be notified Many fully-featured operating systems have dedicated means of implementing this requirement. The SUIT manifest (See ) is recommended as a means of providing secure, authenticated software update. Where the software is deployed to a TEE, TEEP (See ) is recommended for software update and management.

Configuration NIST Device Configuration: The ability to change the device’s software configuration settings The ability to restrict configuration changes to authorized entities only The ability for authorized entities to restore the device to a secure configuration defined by an authorized entity Configuration can be delivered to a device either via a firmware update, such as in , or via a runtime configuration interface, such as .

Resilience to Failure ENISA GP-TM-06: Enable a system to return to a state that was known to be secure, after a security breach has occured or if an upgrade has not been successful. While there is no specificaiton for this, it is also required in

Trust Anchor Management ENISA GP-TM-07: Use protocols and mechanisms able to represent and manage trust and trust relationships. EST () and LwM2M Bootstrap () provide a mechanism to replace trust anchors (manage trust/trust relationships).

Default Security & Privacy

Security ON by Default ENISA GP-TM-08: Any applicable security features should be enabled by default, and any unused or insecure functionalities should be disabled by default. NIST Logical Access to Interfaces: The ability to logically or physically disable any local and network interfaces that are not necessary for the core functionality of the device The ability to logically restrict access to each network interface to only authorized entities (e.g., device authentication, user authentication) Configuration settings for use with the Device Configuration capability including, but not limited to, the ability to enable, disable, and adjust thresholds for any ability the device might have to lock or disable an account or to delay additional authentication attempts after too many failed authentication attempts These are procedural requirements, rather than a protocol or document requirement.

Default Unique Passwords ENISA GP-TM-09: Establish hard to crack, device-individual default passwords. This is a procedural requirement, rather than a protocol or document requirement.

Data Protection The data protection requirements are largely procedural/architectural. While this memo can recommend using TEEs to protect data, and TEEP () to manage TEEs, implementors must choose to architect their software in such a way that TEEs are helpful in meeting these requirements. ENISA Data Protection requirements: GP-TM-10: Personal data must be collected and processed fairly and lawfully, it should never be collected and processed without the data subject's consent. GP-TM-11: Make sure that personal data is used for the specified purposes for which they were collected, and that any further processing of personal data is compatible and that the data subjects are well informed. GP-TM-12: Minimise the data collected and retained. GP-TM-13: IoT stakeholders must be compliant with the EU General Data Protection Regulation (GDPR). GP-TM-14: Users of IoT products and services must be able to exercise their rights to information, access, erasure, rectification, data portability, restriction of processing, objection to processing, and their right not to be evaluated on the basis of automated processing. NIST Data Protection: The ability to use demonstrably secure cryptographic modules for standardized cryptographic algorithms (e.g., encryption with authentication, cryptographic hashes, digital signature validation) to prevent the confidentiality and integrity of the device’s stored and transmitted data from being compromised The ability for authorized entities to render all data on the device inaccessible by all entities, whether previously authorized or not (e.g., through a wipe of internal storage, destruction of cryptographic keys for encrypted data) Configuration settings for use with the Device Configuration capability including, but not limited to, the ability for authorized entities to configure the cryptography use itself, such as choosing a key length

System Safety and Reliability Safety and reliability requirements are procedural/architectural. Implementors should ensure they have processes and architectures in place to meet these requirements. ENISA Safety and Reliability requirements: GP-TM-15: Design with system and operational disruption in mind, preventing the system from causing an unacceptable risk of injury or physical damage. GP-TM-16: Mechanisms for self-diagnosis and self-repair/healing to recover from failure, malfunction or a compromised state. GP-TM-17: Ensure standalone operation - essential features should continue to work with a loss of communications and chronicle negative impacts from compromised devices or cloud-based systems.

Secure Software / Firmware updates Technical requirements for Software Updates are provided for in SUIT () and TEEP (). Procedural and architectural requirements should be independently assessed by the implementor. ENISA Software Update Requirements: GP-TM-18: Ensure that the device software/firmware, its configuration and its applications have the ability to update Over-The-Air (OTA), that the update server is secure, that the update file is transmitted via a secure connection, that it does not contain sensitive data (e.g. hardcoded credentials), that it is signed by an authorised trust entity and encrypted using accepted encryption methods, and that the update package has its digital signature, signing certificate and signing certificate chain, verified by the device before the update process begins. GP-TM-19: Offer an automatic firmware update mechanism. GP-TM-20: (Procedural / Architectural) Backward compatibility of firmware updates. Automatic firmware updates should not modify user-configured preferences, security, and/or privacy settings without user notification.

Authentication

Align Authentication Schemes with Threat Models ENISA GP-TM-21: Design the authentication and authorisation schemes (unique per device) based on the system-level threat models. This is a procedural / architectural requirement.

Password Rules ENISA applies the following requirements to Password-based authentication: GP-TM-22: Ensure that default passwords and even default usernames are changed during the initial setup, and that weak, null or blank passwords are not allowed. GP-TM-23: Authentication mechanisms must use strong passwords or personal identification numbers (PINs), and should consider using two-factor authentication (2FA) or multi-factor authentication (MFA) like Smartphones, Biometrics, etc., on top of certificates. GP-TM-24: Authentication credentials shall be salted, hashed and/or encrypted. GP-TM-25: Protect against 'brute force' and/or other abusive login attempts. This protection should also consider keys stored in devices. GP-TM-26: Ensure password recovery or reset mechanism is robust and does not supply an attacker with information indicating a valid account. The same applies to key update and recovery mechanisms. As an alternative, implementors are encouraged to consider passwordless schemes, such as FIDO.

Authorisation

Principle of Least Privilege ENISA GP-TM-27: Limit the actions allowed for a given system by Implementing fine-grained authorisation mechanisms and using the Principle of least privilege (POLP): applications must operate at the lowest privilege level possible. This is a procedural / architectural requirement, however at the network level, this can be implemented using Manufacturer Usage Descriptions (see ).

Software Isolation ENISA GP-TM-28: Device firmware should be designed to isolate privileged code, processes and data from portions of the firmware that do not need access to them. Device hardware should provide isolation concepts to prevent unprivileged from accessing security sensitive code. Implementors should use TEEs to address this requirement. The provisioning and management of TEEs can be accomplished using TEEP (see ).

Access Control ENISA GP-TM-29: Data integrity and confidentiality must be enforced by access controls. When the subject requesting access has been authorised to access particular processes, it is necessary to enforce the defined security policy. ENISA GP-TM-30: Ensure a context-based security and privacy that reflects different levels of importance. These requirements are complex and require a variety of technologies to implement. Use of TEEs can provide a building block for these requirements, but is not sufficient in itself to meet these requiremnents.

Environmental and Physical Security ENISA defines the following physical security requirements. These are hardware-architectural requirements and not covered by protocol and format specifications. GP-TM-31: Measures for tamper protection and detection. Detection and reaction to hardware tampering should not rely on network connectivity. GP-TM-32: Ensure that the device cannot be easily disassembled and that the data storage medium is encrypted at rest and cannot be easily removed. GP-TM-33: Ensure that devices only feature the essential physical external ports (such as USB) necessary for them to function and that the test/debug modes are secure, so they cannot be used to maliciously access the devices. In general, lock down physical ports to only trusted connections.

Cryptography ENISA makes the following architectural cryptography requirements for IoT devices: GP-TM-34: Ensure a proper and effective use of cryptography to protect the confidentiality, authenticity and/or integrity of data and information (including control messages), in transit and in rest. Ensure the proper selection of standard and strong encryption algorithms and strong keys, and disable insecure protocols. Verify the robustness of the implementation. GP-TM-35: Cryptographic keys must be securely managed. GP-TM-36: Build devices to be compatible with lightweight encryption and security techniques. GP-TM-37: Support scalable key management schemes.

Secure and Trusted Communications

Data Security GP-TM-38: Guarantee the different security aspects -confidentiality (privacy), integrity, availability and authenticity- of the information in transit on the networks or stored in the IoT application or in the Cloud. This Data Security requirement can be fulfilled using COSE for ensuring the authenticity, integrity, and confidentiality of data either in transit or at rest. Secure Transport (see ) technologies can be used to protect data in transit.

Secure Transport ENISA GP-TM-39: Ensure that communication security is provided using state-of-the-art, standardised security protocols, such as TLS for encryption. ENISA GP-TM-40: Ensure credentials are not exposed in internal or external network traffic. This requirement is satisfied by several standards: TLS (). DTLS (). QUIC (). OSCORE ().

Data Authenticity ENISA GP-TM-41: Guarantee data authenticity to enable reliable exchanges from data emission to data reception. Data should always be signed whenever and wherever it is captured and stored. The authenticity of data can be protected using COSE . ENISA GP-TM-42: Do not trust data received and always verify any interconnections. Discover, identify and verify/authenticate the devices connected to the network before trust can be established, and preserve their integrity for reliable solutions and services. Verifying communication partners can be done in many ways. Key technologies supporting authentication of communication partners are: RATS: Remote attestation of a communication partner (See ). TLS/DTLS: Mutual authentication of communication partners (See / ). ATLS: Application-layer TLS for authenticating a connection that may traverse multiple secure transport connections. Attested TLS: The use of attestation in session establishment in TLS (See ).

Least Privilege Communication ENISA GP-TM-43: IoT devices should be restrictive rather than permissive in communicating. This Requirement can be enabled and enforced using Manufacturer Usage Descriptions, which codify expected communication (See ) ENISA GP-TM-44: Make intentional connections. Prevent unauthorised connections to it or other devices the product is connected to, at all levels of the protocols. This requirement can be satisfied through authenticating connections (TLS / DTLS mutual authentication. See / ) and declaring communication patterns (Manufacturer Usage Descriptions. See ) Architectural / Procedural requirements: ENISA GP-TM-45: Disable specific ports and/or network connections for selective connectivity. ENISA GP-TM-46: Rate limiting. Controlling the traffic sent or received by a network to reduce the risk of automated attacks.

Secure Interfaces and network services ENISA Architectural / Procedural requirements: GP-TM-47: Risk Segmentation. Splitting network elements into separate components to help isolate security breaches and minimise the overall risk. GP-TM-48: Protocols should be designed to ensure that, if a single device is compromised, it does not affect the whole set. GP-TM-49: Avoid provisioning the same secret key in an entire product family, since compromising a single device would be enough to expose the rest of the product family. GP-TM-50: Ensure only necessary ports are exposed and available. GP-TM-51: Implement a DDoS-resistant and Load-Balancing infrastructure. GP-TM-53: Avoid security issues when designing error messages.

Encrypted User Sessions ENISA GP-TM-52: Ensure web interfaces fully encrypt the user session, from the device to the backend services, and that they are not susceptible to XSS, CSRF, SQL injection, etc. This requirement can be partially satisfied through use of TLS or QUIC (See and )

Secure input and output handling Architectural / Procedural requirements: ENISA GP-TM-54: Data input validation (ensuring that data is safe prior to use) and output filtering.

Logging Architectural / Procedural requirements: ENISA GP-TM-55: Implement a logging system that records events relating to user authentication, management of accounts and access rights, modifications to security rules, and the functioning of the system. Logs must be preserved on durable storage and retrievable via authenticated connections. NIST Cybersecurity State Awareness The ability to report the device’s cybersecurity state The ability to differentiate between when a device will likely operate as expected from when it may be in a degraded cybersecurity state The ability to restrict access to the state indicator so only authorized entities can view it The ability to prevent any entities (authorized or unauthorized) from editing the state except for those entities that are responsible for maintaining the device’s state information The ability to make the state information available to a service on another device, such as an event/state log server Certain logs and indicators of cybersecurity state can be transported via RATS: See . Where associated with SUIT firmware updates, logs can be transported using SUIT Reports. See .

Monitoring and Auditing Architectural / Procedural requirements: ENISA GP-TM-56: Implement regular monitoring to verify the device behaviour, to detect malware and to discover integrity errors. ENISA GP-TM-57: Conduct periodic audits and reviews of security controls to ensure that the controls are effective. Perform penetration tests at least biannually.

Security Considerations No additional security considerations are required; they are laid out in the preceeding sections.

This specification defines a Uniform Resource Name namespace for UUIDs (Universally Unique IDentifier), also known as GUIDs (Globally Unique IDentifier). A UUID is 128 bits long, and can guarantee uniqueness across space and time. UUIDs were originally used in the Apollo Network Computing System and later in the Open Software Foundation\'s (OSF) Distributed Computing Environment (DCE), and then in Microsoft Windows platforms. This specification is derived from the DCE specification with the kind permission of the OSF (now known as The Open Group). Information from earlier versions of the DCE specification have been incorporated into this document. [STANDARDS-TRACK] This memo specifies a component-based architecture for Manufacturer Usage Descriptions (MUDs). The goal of MUD is to provide a means for end devices to signal to the network what sort of access and network functionality they require to properly function. The initial focus is on access control. Later work can delve into other aspects. This memo specifies two YANG modules, IPv4 and IPv6 DHCP options, a Link Layer Discovery Protocol (LLDP) TLV, a URL, an X.509 certificate extension, and a means to sign and verify the descriptions. This document specifies automated bootstrapping of an Autonomic Control Plane. To do this, a Secure Key Infrastructure is bootstrapped. This is done using manufacturer-installed X.509 certificates, in combination with a manufacturer's authorizing service, both online and offline. We call this process the Bootstrapping Remote Secure Key Infrastructure (BRSKI) protocol. Bootstrapping a new device can occur when using a routable address and a cloud service, only link-local connectivity, or limited/disconnected networks. Support for deployment models with less stringent security requirements is included. Bootstrapping is complete when the cryptographic identity of the new key infrastructure is successfully deployed to the device. The established secure connection can be used to deploy a locally issued certificate to the device as well. This document profiles certificate enrollment for clients using Certificate Management over CMS (CMC) messages over a secure transport. This profile, called Enrollment over Secure Transport (EST), describes a simple, yet functional, certificate management protocol targeting Public Key Infrastructure (PKI) clients that need to acquire client certificates and associated Certification Authority (CA) certificates. It also supports client-generated public/private key pairs as well as key pairs generated by the CA. 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. 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. This document specifies a profile for the Authentication and Authorization for Constrained Environments (ACE) framework. It utilizes Object Security for Constrained RESTful Environments (OSCORE) to provide communication security and proof-of-possession for a key owned by the client and bound to an OAuth 2.0 access token. Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need for the ability to have basic security services defined for this data format. This document defines the CBOR Object Signing and Encryption (COSE) protocol. This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization. This specification additionally describes how to represent cryptographic keys using CBOR. This document defines the core of the QUIC transport protocol. QUIC provides applications with flow-controlled streams for structured communication, low-latency connection establishment, and network path migration. QUIC includes security measures that ensure confidentiality, integrity, and availability in a range of deployment circumstances. Accompanying documents describe the integration of TLS for key negotiation, loss detection, and an exemplary congestion control algorithm. This document specifies version 1.3 of the Datagram Transport Layer Security (DTLS) protocol. DTLS 1.3 allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. The DTLS 1.3 protocol is based on the Transport Layer Security (TLS) 1.3 protocol and provides equivalent security guarantees with the exception of order protection / non-replayability. Datagram semantics of the underlying transport are preserved by the DTLS protocol. This document obsoletes RFC 6347. Security Theory LLC Qualcomm Technologies Inc. Qualcomm Technologies Inc. Red Hound Software, Inc. An Entity Attestation Token (EAT) provides an attested claims set that describes state and characteristics of an entity, a device like a smartphone, IoT device, network equipment or such. This claims set is used by a relying party, server or service to determine how much it wishes to trust the entity. An EAT is either a CBOR Web Token (CWT) or JSON Web Token (JWT) with attestation-oriented claims. Arm Limited Arm Limited Fraunhofer SIT Inria Nordic Semiconductor This specification describes the format of a manifest. A manifest is a bundle of metadata about code/data obtained by a recipient (chiefly the firmware for an IoT device), where to find the that code/data, the devices to which it applies, and cryptographic information protecting the manifest. Software updates and Trusted Invocation both tend to use sequences of common operations, so the manifest encodes those sequences of operations, rather than declaring the metadata. Fraunhofer SIT National Security Agency The MITRE Corporation National Institute of Standards and Technology ISO/IEC 19770-2:2015 Software Identification (SWID) tags provide an extensible XML-based structure to identify and describe individual software components, patches, and installation bundles. SWID tag representations can be too large for devices with network and storage constraints. This document defines a concise representation of SWID tags: Concise SWID (CoSWID) tags. CoSWID supports a set of semantics and features that are similar to those for SWID tags, as well as new semantics that allow CoSWIDs to describe additional types of information, all in a more memory-efficient format. Fraunhofer SIT arm arm Intel Huawei Technologies Remote Attestation Procedures (RATS) enable Relying Parties to assess the trustworthiness of a remote Attester and therefore to decide whether to engage in secure interactions with it. Evidence about trustworthiness can be rather complex and it is deemed unrealistic that every Relying Party is capable of the appraisal of Evidence. Therefore that burden is typically offloaded to a Verifier. In order to conduct Evidence appraisal, a Verifier requires not only fresh Evidence from an Attester, but also trusted Endorsements and Reference Values from Endorsers and Reference Value Providers, such as manufacturers, distributors, or device owners. This document specifies Concise Reference Integrity Manifests (CoRIM) that represent Endorsements and Reference Values in CBOR format. Composite devices or systems are represented by a collection of Concise Module Identifiers (CoMID) and Concise Software Identifiers (CoSWID) bundled in a CoRIM document. Broadcom Arm Limited Microsoft Amazon A Trusted Execution Environment (TEE) is an environment that enforces that any code within that environment cannot be tampered with, and that any data used by such code cannot be read or tampered with by any code outside that environment. This architecture document motivates the design and standardization of a protocol for managing the lifecycle of trusted applications running inside such a TEE. 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. Fraunhofer SIT Microsoft Sandelman Software Works Intel Corporation Huawei Technologies 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. Arm Limited Fraunhofer SIT The Software Update for the Internet of Things (SUIT) manifest provides a way for many different update and boot workflows to be described by a common format. However, this does not provide a feedback mechanism for developers in the event that an update or boot fails. This specification describes a lightweight feedback mechanism that allows a developer in possession of a manifest to reconstruct the decisions made and actions performed by a manifest processor. Intuit Arm Limited Arm Limited Arm Limited Attestation is the process by which an entity produces evidence about itself that another party can use to evaluate the trustworthiness of that entity. In use cases that require the use of remote attestation, such as confidential computing or device onboarding, an attester has to convey evidence or attestation results to a relying party. This information exchange may happen at different layers in the protocol stack. This specification provides a generic way of passing evidence and attestation results in the TLS handshake. Functionality-wise this is accomplished with the help of key attestation. 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.