]> Security Theory LLC

lgl@securitytheory.com

Fraunhofer Institute for Secure Information Technology

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

arm

thomas.fossati@arm.com

Security RATS 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.

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 DEB in its JSON and CBOR flavours), whilst defines the remaining two: UCCS and UJCS.

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 profile parameter that can be used to mirror the eat_profile 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 profile parameter with the corresponding OID or URL.

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

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 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.

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,
EAT CBOR DEB	application/eat-deb+cbor	RFCthis,
EAT JSON DEB	application/eat-deb+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:

"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:

"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-deb+cbor Registration

Type name:

application

Subtype name:

eat-deb+cbor

Required parameters:

n/a

Optional parameters:

"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-deb+json Registration

Type name:

application

Subtype name:

eat-deb+json

Required parameters:

n/a

Optional parameters:

"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:

"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:

"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-deb+cbor	-	TBD3	RFCthis
application/eat-deb+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. In the registry as defined by at the time of writing, the column "Content-Type" is called "Media type" and the column "Content Coding" is called "Encoding". RFC editor: please remove this paragraph.

References Normative References Security Theory LLC Qualcomm Technologies Inc. Qualcomm Technologies Inc. An Entity Attestation Token (EAT) provides an attested claims set that describes state and characteristics of an entity, a device like a phone, 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. To a large degree, all this document does is extend CWT and JWT. Fraunhofer SIT Qualcomm Technologies Inc. Cisco Systems Universität Bremen TZI CBOR Web Token (CWT, RFC 8392) Claims Sets sometimes do 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 present version (-01) has a few editorial improvements over // -00 and attempts to address points from Thomas Fossati's // 2021-03-16 review, for further discussion at IETF 111. 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. 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 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 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. An attempt is made to provide for a model that is neutral toward processor architectures, the content of claims, and protocols.

Acknowledgments TODO