]> Security Theory LLC

lgl@securitytheory.com

Fraunhofer Institute for Secure Information Technology

Rheinstrasse 75 Darmstadt 64295 Germany henk.birkholz@sit.fraunhofer.de

Linaro

thomas.fossati@linaro.org

Security Remote ATtestation ProcedureS EAT, media type Payloads used in Remote Attestation Procedures may require an associated media type for their conveyance, for example when used in RESTful APIs. This memo defines media types to be used for Entity Attestation Tokens (EAT). Discussion Venues Discussion of this document takes place on the Remote ATtestation ProcedureS Working Group mailing list (rats@ietf.org), which is archived at . Source for this draft and an issue tracker can be found at .

Introduction Payloads used in Remote Attestation Procedures may require an associated media type for their conveyance, for example when used in RESTful APIs ().

Conveying RATS conceptual messages in REST APIs using EAT | | | 200 OK | | | EAT(Attestation Results) | | |<---------------------------+ | POST /auth | | | EAT(Attestation Results) | | |<---------------------------+ | | 201 Created | | +--------------------------->| | | | | | | | ]]>

This memo defines media types to be used for Entity Attestation Token (EAT) payloads independently of the RATS Conceptual Message in which they manifest themselves. The objective is to give protocol, API and application designers a number of readily available and reusable media types for integrating EAT-based messages in their flows, for example when using HTTP or CoAP .

Requirements Language This document uses the terms and concepts defined in . 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.

EAT Types illustrates the six EAT wire formats and how they relate to each other. defines four of them (CWT, JWT and Detached EAT Bundle in its JSON and CBOR flavours), whilst defines UCCS, and we use the abbreviation "UJCS" to refer to unprotected JWT Claims Sets as defined in .

EAT Types

A Media Type Parameter for EAT Profiles EAT is an open and flexible format. To improve interoperability, defines the concept of EAT profiles. Profiles are used to constrain the parameters that producers and consumers of a specific EAT profile need to understand in order to interoperate. For example: the number and type of claims, which serialisation format, the supported signature schemes, etc. EATs carry an in-band profile identifier using the eat_profile claim (see ). The value of the eat_profile claim is either an OID or a URI. The media types defined in this document include an optional eat_profile parameter that can be used to mirror the homonymous claim of the transported EAT. Exposing the EAT profile at the API layer allows API routers to dispatch payloads directly to the profile-specific processor without having to snoop into the request bodies. This design also provides a finer-grained and scalable type system that matches the inherent extensibility of EAT. The expectation being that a certain EAT profile automatically obtains a media type derived from the base (e.g., application/eat+cwt) by populating the eat_profile parameter with the corresponding OID or URL.

Examples The example in illustrates the usage of EAT media types for transporting attestation evidence as well as negotiating the acceptable format of the attestation result.

Example REST Verification API (request)

The example in illustrates the usage of EAT media types for transporting attestation results.

Example REST Verification API (response)

In both cases, a tag URI identifying the profile is carried as an explicit parameter.

Security Considerations The security consideration of and apply in full.

IANA Considerations RFC Editor: please replace RFCthis with this RFC number and remove this note.

+cwt Structured Syntax Suffix IANA is requested to register the +cwt structured syntax suffix in the "Structured Syntax Suffixes" registry in the manner described in , which can be used to indicate that the media type is encoded as a CWT.

Registry Contents

Name:

CBOR Web Token (CWT)

+suffix:

+cwt

References:

Encoding Considerations:

binary

Interoperability Considerations:

N/A

Fragment Identifier Considerations:

The syntax and semantics of fragment identifiers specified for +cwt SHOULD be as specified for application/cwt. (At publication of this document, there is no fragment identification syntax defined for application/cwt.)

Security Considerations:

See

Contact:

RATS WG mailing list (rats@ietf.org), or IETF Security Area (saag@ietf.org)

Author/Change Controller:

Remote ATtestation ProcedureS (RATS) Working Group. The IETF has change control over this registration.

Media Types IANA is requested to add the following media types to the "Media Types" registry . New Media Types

Name	Template	Reference
EAT CWT	application/eat+cwt	RFCthis,
EAT JWT	application/eat+jwt	RFCthis,
Detached EAT Bundle CBOR	application/eat-bun+cbor	RFCthis,
Detached EAT Bundle JSON	application/eat-bun+json	RFCthis,
EAT UCCS	application/eat-ucs+cbor	RFCthis,
EAT UJCS	application/eat-ucs+json	RFCthis,

application/eat+cwt Registration

Type name:

application

Subtype name:

eat+cwt

Required parameters:

n/a

Optional parameters:

"eat_profile" (EAT profile in string format. OIDs MUST use the dotted-decimal notation. The parameter value is case-insensitive.)

Encoding considerations:

binary

Security considerations:

of RFCthis

Interoperability considerations:

n/a

Published specification:

of RFCthis

Applications that use this media type:

Attesters, Verifiers, Endorsers and Reference-Value providers, Relying Parties that need to transfer EAT payloads over HTTP(S), CoAP(S), and other transports.

Fragment identifier considerations:

n/a

Person & email address to contact for further information:

RATS WG mailing list (rats@ietf.org)

Intended usage:

COMMON

Restrictions on usage:

none

Author/Change controller:

IETF

Provisional registration:

maybe

application/eat+jwt Registration

Type name:

application

Subtype name:

eat+jwt

Required parameters:

n/a

Optional parameters:

"eat_profile" (EAT profile in string format. OIDs MUST use the dotted-decimal notation. The parameter value is case-insensitive.)

Encoding considerations:

8bit

Security considerations:

of RFCthis

Interoperability considerations:

n/a

Published specification:

of RFCthis

Applications that use this media type

Attesters, Verifiers, Endorsers and Reference-Value providers, Relying Parties that need to transfer EAT payloads over HTTP(S), CoAP(S), and other transports.

Fragment identifier considerations:

n/a

Person & email address to contact for further information:

RATS WG mailing list (rats@ietf.org)

Intended usage:

COMMON

Restrictions on usage:

none

Author/Change controller:

IETF

Provisional registration:

maybe

application/eat-bun+cbor Registration

Type name:

application

Subtype name:

eat-bun+cbor

Required parameters:

n/a

Optional parameters:

"eat_profile" (EAT profile in string format. OIDs MUST use the dotted-decimal notation. The parameter value is case-insensitive.)

Encoding considerations:

binary

Security considerations:

of RFCthis

Interoperability considerations:

n/a

Published specification:

of RFCthis

Applications that use this media type:

Attesters, Verifiers, Endorsers and Reference-Value providers, Relying Parties that need to transfer EAT payloads over HTTP(S), CoAP(S), and other transports.

Fragment identifier considerations:

n/a

Person & email address to contact for further information:

RATS WG mailing list (rats@ietf.org)

Intended usage:

COMMON

Restrictions on usage:

none

Author/Change controller:

IETF

Provisional registration:

maybe

application/eat-bun+json Registration

Type name:

application

Subtype name:

eat-bun+json

Required parameters:

n/a

Optional parameters:

"eat_profile" (EAT profile in string format. OIDs MUST use the dotted-decimal notation. The parameter value is case-insensitive.)

Encoding considerations:

Same as

Security considerations:

of RFCthis

Interoperability considerations:

n/a

Published specification:

of RFCthis

Applications that use this media type

Attesters, Verifiers, Endorsers and Reference-Value providers, Relying Parties that need to transfer EAT payloads over HTTP(S), CoAP(S), and other transports.

Fragment identifier considerations:

n/a

Person & email address to contact for further information:

RATS WG mailing list (rats@ietf.org)

Intended usage:

COMMON

Restrictions on usage:

none

Author/Change controller:

IETF

Provisional registration:

maybe

application/eat-ucs+cbor Registration

Type name:

application

Subtype name:

eat-ucs+cbor

Required parameters:

n/a

Optional parameters:

"eat_profile" (EAT profile in string format. OIDs MUST use the dotted-decimal notation. The parameter value is case-insensitive.)

Encoding considerations:

binary

Security considerations:

of RFCthis

Interoperability considerations:

n/a

Published specification:

of RFCthis

Applications that use this media type:

Attesters, Verifiers, Endorsers and Reference-Value providers, Relying Parties that need to transfer EAT payloads over HTTP(S), CoAP(S), and other transports.

Fragment identifier considerations:

n/a

Person & email address to contact for further information:

RATS WG mailing list (rats@ietf.org)

Intended usage:

COMMON

Restrictions on usage:

none

Author/Change controller:

IETF

Provisional registration:

maybe

application/eat-ucs+json Registration

Type name:

application

Subtype name:

eat-ucs+json

Required parameters:

n/a

Optional parameters:

"eat_profile" (EAT profile in string format. OIDs MUST use the dotted-decimal notation. The parameter value is case-insensitive.)

Encoding considerations:

Same as

Security considerations:

of RFCthis

Interoperability considerations:

n/a

Published specification:

of RFCthis

Applications that use this media type

Attesters, Verifiers, Endorsers and Reference-Value providers, Relying Parties that need to transfer EAT payloads over HTTP(S), CoAP(S), and other transports.

Fragment identifier considerations:

n/a

Person & email address to contact for further information:

RATS WG mailing list (rats@ietf.org)

Intended usage:

COMMON

Restrictions on usage:

none

Author/Change controller:

IETF

Provisional registration:

maybe

Content-Format IANA is requested to register a Content-Format number in the "CoAP Content-Formats" sub-registry, within the "Constrained RESTful Environments (CoRE) Parameters" Registry , as follows: New Content-Formats

Content-Type	Content Coding	ID	Reference
application/eat+cwt	-	TBD1	RFCthis
application/eat+jwt	-	TBD2	RFCthis
application/eat-bun+cbor	-	TBD3	RFCthis
application/eat-bun+json	-	TBD4	RFCthis
application/eat-ucs+cbor	-	TBD5	RFCthis
application/eat-ucs+json	-	TBD6	RFCthis

TBD1..6 are to be assigned from the space 256..999.

Changelog RFC editor: please remove this section

 -04

• Early IANA review

 -03

• Update references

 -02

• Update references
• Register +cwt SSS (Issue#14)
• Move from eat-jwt to eat+jwt (Issue#14)
• Move from eat-cwt to eat+cwt (Issue#14)

 -01

• Rename profile to eat_profile for consistency with EAT (Issue#4)
• The DEB acronym is gone: shorthand is now "bun" from bundle (Issue#8)
• Incorporate editorial suggestions from Carl and Dave (Issue#7, Issue#9)

References Normative References Security Theory LLC Mediatek USA 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 the type and degree of trust placed in the entity. An EAT is either a CBOR Web Token (CWT) or JSON Web Token (JWT) with attestation-oriented claims. JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted. CBOR Web Token (CWT) is a compact means of representing claims to be transferred between two parties. The claims in a CWT are encoded in the Concise Binary Object Representation (CBOR), and CBOR Object Signing and Encryption (COSE) is used for added application-layer security protection. A claim is a piece of information asserted about a subject and is represented as a name/value pair consisting of a claim name and a claim value. CWT is derived from JSON Web Token (JWT) but uses CBOR rather than JSON. Fraunhofer SIT Qualcomm Technologies Inc. Cisco Systems Universität Bremen TZI When transported over secure channels, CBOR Web Token (CWT, RFC 8392) Claims Sets may not need the protection afforded by wrapping them into COSE, as is required for a true CWT. This specification defines a CBOR tag for such unprotected CWT Claims Sets (UCCS) and discusses conditions for its proper use. The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for use with constrained nodes and constrained (e.g., low-power, lossy) networks. The nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while constrained networks such as IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) often have high packet error rates and a typical throughput of 10s of kbit/s. The protocol is designed for machine- to-machine (M2M) applications such as smart energy and building automation. CoAP provides a request/response interaction model between application endpoints, supports built-in discovery of services and resources, and includes key concepts of the Web such as URIs and Internet media types. CoAP is designed to easily interface with HTTP for integration with the Web while meeting specialized requirements such as multicast support, very low overhead, and simplicity for constrained environments. This document defines procedures for the specification and registration of media types for use in HTTP, MIME, and other Internet protocols. This memo documents an Internet Best Current Practice. 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. IANA IANA JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data. This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance. IANA Informative References 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. Applications often use HTTP as a substrate to create HTTP-based APIs. This document specifies best practices for writing specifications that use HTTP to define new application protocols. It is written primarily to guide IETF efforts to define application protocols using HTTP for deployment on the Internet but might be applicable in other situations. This document obsoletes RFC 3205. Ericsson Siemens This document gives guidance for designing Internet of Things (IoT) systems that follow the principles of the Representational State Transfer (REST) architectural style. This document is a product of the IRTF Thing-to-Thing Research Group (T2TRG). This document describes the "tag" Uniform Resource Identifier (URI) scheme. Tag URIs (also known as "tags") are designed to be unique across space and time while being tractable to humans. They are distinct from most other URIs in that they have no authoritative resolution mechanism. A tag may be used purely as an entity identifier. Furthermore, using tags has some advantages over the common practice of using "http" URIs as identifiers for non-HTTP-accessible resources. This memo provides information for the Internet community.

Acknowledgments Thank you Carl Wallace, Dave Thaler, Michael Richardson for your comments and suggestions.