Internet DRAFT - draft-ietf-ace-edhoc-oscore-profile
draft-ietf-ace-edhoc-oscore-profile
ACE Working Group G. Selander
Internet-Draft J. Preuß Mattsson
Intended status: Standards Track Ericsson
Expires: 5 September 2024 M. Tiloca
R. Höglund
RISE
4 March 2024
Ephemeral Diffie-Hellman Over COSE (EDHOC) and Object Security for
Constrained Environments (OSCORE) Profile for Authentication and
Authorization for Constrained Environments (ACE)
draft-ietf-ace-edhoc-oscore-profile-04
Abstract
This document specifies a profile for the Authentication and
Authorization for Constrained Environments (ACE) framework. It
utilizes Ephemeral Diffie-Hellman Over COSE (EDHOC) for achieving
mutual authentication between an ACE-OAuth Client and Resource
Server, and it binds an authentication credential of the Client to an
ACE-OAuth access token. EDHOC also establishes an Object Security
for Constrained RESTful Environments (OSCORE) Security Context, which
is used to secure communications when accessing protected resources
according to the authorization information indicated in the access
token. This profile can be used to delegate management of
authorization information from a resource-constrained server to a
trusted host with less severe limitations regarding processing power
and memory.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 5 September 2024.
Selander, et al. Expires 5 September 2024 [Page 1]
Internet-Draft EDHOC and OSCORE profile of ACE March 2024
Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6
3. Client-AS Communication . . . . . . . . . . . . . . . . . . . 8
3.1. C-to-AS: POST to /token endpoint . . . . . . . . . . . . 9
3.2. Token Series . . . . . . . . . . . . . . . . . . . . . . 10
3.3. AS-to-C: Response . . . . . . . . . . . . . . . . . . . . 11
3.3.1. Access Token . . . . . . . . . . . . . . . . . . . . 13
3.3.2. Processing in C . . . . . . . . . . . . . . . . . . . 15
3.3.3. Update of Access Rights . . . . . . . . . . . . . . . 15
3.4. EDHOC_Information . . . . . . . . . . . . . . . . . . . . 16
4. Client-RS Communication . . . . . . . . . . . . . . . . . . . 21
4.1. C-to-RS: POST to /authz-info endpoint . . . . . . . . . . 22
4.2. RS-to-C: 2.01 (Created) . . . . . . . . . . . . . . . . . 22
4.3. Access Token in External Authorization Data . . . . . . . 23
4.4. EDHOC Session and OSCORE Security Context . . . . . . . . 24
4.4.1. EDHOC message_1 . . . . . . . . . . . . . . . . . . . 24
4.4.2. EDHOC message_2 . . . . . . . . . . . . . . . . . . . 25
4.4.3. EDHOC message_3 . . . . . . . . . . . . . . . . . . . 25
4.4.4. OSCORE Security Context . . . . . . . . . . . . . . . 26
4.5. Update of Access Rights . . . . . . . . . . . . . . . . . 26
4.6. Discarding the Security Context . . . . . . . . . . . . . 27
4.7. Cases of Establishing a New OSCORE Security Context . . . 29
4.8. Access Rights Verification . . . . . . . . . . . . . . . 29
5. Secure Communication with AS . . . . . . . . . . . . . . . . 30
6. CWT Confirmation Methods . . . . . . . . . . . . . . . . . . 30
6.1. Ordered Chain of X.509 Certificates . . . . . . . . . . . 30
6.2. Unordered Bag of X.509 Certificates . . . . . . . . . . . 30
6.3. Hash of an X.509 Certificate . . . . . . . . . . . . . . 31
6.4. URI Pointing to an Ordered Chain of X.509 Certificates . 31
6.5. Ordered Chain of C509 Certificates . . . . . . . . . . . 31
6.6. Unordered Bag of C509 Certificates . . . . . . . . . . . 31
Selander, et al. Expires 5 September 2024 [Page 2]
Internet-Draft EDHOC and OSCORE profile of ACE March 2024
6.7. Hash of a C509 Certificate . . . . . . . . . . . . . . . 31
6.8. URI Pointing to an Ordered Chain of C509 Certificates . . 31
6.9. CWT Containing a COSE_Key . . . . . . . . . . . . . . . . 32
6.10. CCS Containing a COSE_Key . . . . . . . . . . . . . . . . 32
7. JWT Confirmation Methods . . . . . . . . . . . . . . . . . . 32
7.1. Ordered Chain of X.509 Certificates . . . . . . . . . . . 32
7.2. Unordered Bag of X.509 Certificates . . . . . . . . . . . 32
7.3. Hash of an X.509 Certificate . . . . . . . . . . . . . . 32
7.4. URI Pointing to an Ordered Chain of X.509 Certificates . 33
7.5. Ordered Chain of C509 Certificates . . . . . . . . . . . 33
7.6. Unordered Bag of C509 Certificates . . . . . . . . . . . 33
7.7. Hash of a C09 Certificate . . . . . . . . . . . . . . . . 33
7.8. URI Pointing to an Ordered Chain of C509 Certificates . . 33
7.9. CWT Containing a COSE_Key . . . . . . . . . . . . . . . . 34
7.10. CCS Containing a COSE_Key . . . . . . . . . . . . . . . . 34
8. Security Considerations . . . . . . . . . . . . . . . . . . . 34
9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 35
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36
10.1. ACE OAuth Profile Registry . . . . . . . . . . . . . . . 36
10.2. OAuth Parameters Registry . . . . . . . . . . . . . . . 36
10.3. OAuth Parameters CBOR Mappings Registry . . . . . . . . 37
10.4. JSON Web Token Claims Registry . . . . . . . . . . . . . 37
10.5. CBOR Web Token Claims Registry . . . . . . . . . . . . . 37
10.6. JWT Confirmation Methods Registry . . . . . . . . . . . 38
10.7. CWT Confirmation Methods Registry . . . . . . . . . . . 40
10.8. EDHOC External Authorization Data Registry . . . . . . . 43
10.9. EDHOC Information Registry . . . . . . . . . . . . . . . 43
10.10. Expert Review Instructions . . . . . . . . . . . . . . . 44
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 45
11.1. Normative References . . . . . . . . . . . . . . . . . . 45
11.2. Informative References . . . . . . . . . . . . . . . . . 48
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 49
A.1. Workflow without Optimizations . . . . . . . . . . . . . 51
A.2. Workflow with Optimizations . . . . . . . . . . . . . . . 55
A.3. Alternative Workflow (AS token posting) . . . . . . . . . 57
Appendix B. Profile Requirements . . . . . . . . . . . . . . . . 60
Appendix C. Document Updates . . . . . . . . . . . . . . . . . . 61
C.1. Version -03 to -04 . . . . . . . . . . . . . . . . . . . 61
C.2. Version -02 to -03 . . . . . . . . . . . . . . . . . . . 61
C.3. Version -02 to -03 . . . . . . . . . . . . . . . . . . . 61
C.4. Version -01 to -02 . . . . . . . . . . . . . . . . . . . 62
C.5. Version -00 to -01 . . . . . . . . . . . . . . . . . . . 62
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 62
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 63
Selander, et al. Expires 5 September 2024 [Page 3]
Internet-Draft EDHOC and OSCORE profile of ACE March 2024
1. Introduction
This document defines the "coap_edhoc_oscore" profile of the ACE-
OAuth framework [RFC9200]. This profile addresses a "zero-touch"
constrained setting where authenticated and authorized operations can
be performed with low overhead without endpoint specific
configurations.
Like in the "coap_oscore" profile [RFC9203], also in this profile a
client (C) and a resource server (RS) use the Constrained Application
Protocol (CoAP) [RFC7252] to communicate, and Object Security for
Constrained RESTful Environments (OSCORE) [RFC8613] to protect their
communications, but this profile uses the Ephemeral Diffie-Hellman
Over COSE (EDHOC) protocol [I-D.ietf-lake-edhoc] to establish the
OSCORE Security Context. The processing of requests for specific
protected resources is identical to what is defined in the
"coap_oscore" profile.
When using this profile, C accesses protected resources hosted at RS
with the use of an access token issued by a trusted authorization
server (AS) and bound to an authentication credential of C. This
differs from the "coap_oscore" profile, where the access token is
bound to a symmetric key used to derive the OSCORE Security Context.
As recommended in [RFC9200], this document recommends the use of CBOR
Web Tokens (CWTs) [RFC8392] as access tokens.
An authentication credential can be a raw public key, e.g., encoded
as a CWT Claims Set (CCS, [RFC8392]); or a public key certificate,
e.g., encoded as an X.509 certificate [RFC5280] or as a CBOR encoded
X.509 certificate (C509, [I-D.ietf-cose-cbor-encoded-cert]); or a
different type of data structure containing the public key of the
peer in question.
The ACE protocol establishes what those authentication credentials
are, and may transport the actual authentication credentials by value
or uniquely refer to them. If an authentication credential is pre-
provisioned or can be obtained over less constrained links, then it
suffices that ACE provides a unique reference such as a certificate
hash (e.g., by using the COSE header parameter "x5t", see [RFC9360]).
This is in the same spirit as EDHOC, where the authentication
credentials may be transported or referenced in the ID_CRED_x message
fields (see Section 3.5.3 of [I-D.ietf-lake-edhoc]).
In general, AS and RS are likely to have trusted access to each
other's authentication credentials, since AS acts on behalf of RS as
per the trust model of ACE. Also, AS needs to have some information
about C, including the relevant authentication credential, in order
to identify C when it requests an access token and to determine what
Selander, et al. Expires 5 September 2024 [Page 4]
Internet-Draft EDHOC and OSCORE profile of ACE March 2024
access rights it can be granted. However, the authentication
credential of C may potentially be conveyed (or uniquely referred to)
within the request for access that C makes to AS.
The establishment of an association between RS and AS in an ACE
ecosystem is out of scope, but one solution is to build on the same
primitives as used in this document, i.e., EDHOC for authentication
and OSCORE for communication security, using for example
[I-D.ietf-lake-authz] for onboarding RS with AS, and
[I-D.ietf-ace-coap-est-oscore] for establishing a trust anchor in RS.
A similar procedure can also be applied between C and AS for
registering a client and for the establishment of a trust anchor.
1.1. 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 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
Certain security-related terms such as "authentication",
"authorization", "confidentiality", "(data) integrity", "Message
Authentication Code (MAC)", "Hash-based Message Authentication Code
(HMAC)", and "verify" are taken from [RFC4949].
RESTful terminology follows HTTP [RFC9110].
Readers are expected to be familiar with the terms and concepts
defined in CoAP [RFC7252], OSCORE [RFC8613], and EDHOC
[I-D.ietf-lake-edhoc].
Readers are also expected to be familiar with the terms and concepts
of the ACE framework described in [RFC9200] and in [RFC9201].
Terminology for entities in the architecture is defined in OAuth 2.0
[RFC6749], such as the client (C), the resource server (RS), and the
authorization server (AS). It is assumed in this document that a
given resource on a specific RS is associated with a unique AS.
Note that the term "endpoint" is used here, as in [RFC9200],
following its OAuth definition, which is to denote resources such as
/token and /introspect at AS and /authz-info at RS. The CoAP
[RFC7252] definition, which is "An entity participating in the CoAP
protocol" is not used in this document.
Selander, et al. Expires 5 September 2024 [Page 5]
Internet-Draft EDHOC and OSCORE profile of ACE March 2024
The authorization information (authz-info) resource refers to the
authorization information endpoint as specified in [RFC9200]. The
term "claim" is used in this document with the same semantics as in
[RFC9200], i.e., it denotes information carried in the access token
or returned from introspection.
Concise Binary Object Representation (CBOR) [RFC8949][RFC8742] and
Concise Data Definition Language (CDDL) [RFC8610] are used in this
document. CDDL predefined type names, especially bstr for CBOR byte
strings and tstr for CBOR text strings, are used extensively in this
document.
Examples throughout this document are expressed in CBOR diagnostic
notation without the tag and value abbreviations.
2. Protocol Overview
This section gives an overview of how to use the ACE framework
[RFC9200] together with the authenticated key establishment protocol
EDHOC [I-D.ietf-lake-edhoc]. By doing so, the client (C) and the
resource server (RS) generate an OSCORE Security Context [RFC8613]
associated with authorization information, and use that Security
Context to protect their communications. The parameters needed by C
to negotiate the use of this profile with the authorization server
(AS), as well as the OSCORE setup process, are described in detail in
the following sections.
RS maintains a collection of authentication credentials. These are
associated with OSCORE Security Contexts and with authorization
information for all clients that RS is communicating with. The
authorization information is used to enforce polices for processing
requests from those clients.
This profile specifies how C requests an access token from AS for the
resources it wants to access on RS, by sending an access token
request to the /token endpoint, as specified in Section 5.8 of
[RFC9200].
This profile also supports the alternative workflow where AS uploads
the access token to RS, as defined in
[I-D.ietf-ace-workflow-and-params].
If C has retrieved an access token, there are two options for C to
upload it to RS, as further detailed in this document.
1. C posts the access token to the /authz-info endpoint by using the
mechanisms specified in Section 5.10 of [RFC9200]. If the access
token is valid, RS replies to the request with a 2.01 (Created)
Selander, et al. Expires 5 September 2024 [Page 6]
Internet-Draft EDHOC and OSCORE profile of ACE March 2024
response, after which C initiates the EDHOC protocol with RS.
The communication with the /authz-info endpoint is typically not
protected, except for the update of access rights (see
Section 4.5).
2. C initiates the EDHOC protocol and includes the access token as
External Authorization Data (EAD), see Section 3.8 of
[I-D.ietf-lake-edhoc]. In this case, the access token is
validated in parallel with the EDHOC session. This option cannot
be used for the update of access rights.
When running the EDHOC protocol, C uses the authentication credential
of RS specified by AS together with the access token, while RS uses
the authentication credential of C bound to and specified within the
access token. If C and RS complete the EDHOC session successfully,
they are mutually authenticated and they derive an OSCORE Security
Context as per Appendix A.1 of [I-D.ietf-lake-edhoc].
From then on, C effectively gains authorized and secure access to
protected resources on RS with the established OSCORE Security
Context, for as long as there is a valid access token. The Security
Context is discarded when an access token (whether the same or a
different one) is used to successfully derive a new Security Context
for C.
After the whole procedure has completed and while the access token is
valid, C can contact AS to request an update of its access rights, by
sending a similar request to the /token endpoint. This request also
includes a "session identifier" (see Section 3.4) provided by AS in
the initial request, which allows AS to find the data it has
previously shared with C. The session identifier is assigned by AS
and used to identify a series of access tokens, called a "token
series" (see Section 3.2). Upon a successful update of access rights
(see Section 4.5), the new issued access token becomes the latest in
its token series, but the session identifier remains the same. When
the latest access token of a token series becomes invalid (e.g., when
it expires or gets revoked), that token series ends.
When RS receives a request from C protected with an OSCORE Security
Context derived from an EDHOC session implementing this profile, then
the associated session identifier, together with the authentication
credential of C used in the EDHOC session, enables the RS to look up
the unique access token determining the access rights of C.
An overview of the profile flow for the "coap_edhoc_oscore" profile
in case of option 1 above is given in Figure 1. The names of
messages coincide with those of [RFC9200] when applicable.
Selander, et al. Expires 5 September 2024 [Page 7]
Internet-Draft EDHOC and OSCORE profile of ACE March 2024
C RS AS
| | |
| <==== Mutual authentication and secure channel ====> |
| | |
| ------- POST /token ------------------------------> |
| | |
| <-------------------------------- Access Token ----- |
| + Access Information |
| | |
| ---- POST /authz-info ---> | |
| (access_token) | |
| | |
| <----- 2.01 Created ------ | |
| | |
| <========= EDHOC ========> | |
| Mutual authentication | |
| and derivation of an | |
| OSCORE Security Context | |
| | |
| /Proof-of-possession and |
| Security Context storage/ |
| | |
| ---- OSCORE Request -----> | |
| | |
| <--- OSCORE Response ----- | |
| | |
/Proof-of-possession | |
and Security Context | |
storage (latest)/ | |
| | |
| ---- OSCORE Request -----> | |
| | |
| <--- OSCORE Response ----- | |
| | |
| ... | |
Figure 1: Protocol Overview Example
3. Client-AS Communication
The following subsections describe the details of the POST request
and response to the /token endpoint between C and AS.
In this exchange, AS provides C with the access token, together with
a set of parameters that enable C to run EDHOC with RS. In
particular, these include information about the authorization
credential of RS, AUTH_CRED_RS, transported by value or uniquely
referred to.
Selander, et al. Expires 5 September 2024 [Page 8]
Internet-Draft EDHOC and OSCORE profile of ACE March 2024
The access token is securely associated with the authentication
credential of C, AUTH_CRED_C, by including it or uniquely referring
to it in the access token.
AUTH_CRED_C is specified in the "req_cnf" parameter defined in
[RFC9201] of the POST request to the /token endpoint from C to AS,
either transported by value or uniquely referred to.
The request to the /token endpoint and the corresponding response can
include EDHOC_Information, which is a CBOR map object containing
information related to an EDHOC session, in particular the identifier
"session_id", see Section 3.4. This object is transported in the
"edhoc_info" parameter registered in Section 10.2 and Section 10.3.
3.1. C-to-AS: POST to /token endpoint
The client-to-AS request is specified in Section 5.8.1 of [RFC9200].
The client MUST send this POST request to the /token endpoint over a
secure channel that guarantees authentication, message integrity, and
confidentiality (see Section 5). This document describes the use of
CoAP, EDHOC and OSCORE to reduce the number of libraries that C has
to support.
An example of such a request is shown in Figure 2. In this example,
C specifies its own authentication credential by reference, as the
hash of an X.509 certificate carried in the "x5t" field of the
"req_cnf" parameter. In fact, it is expected that C can typically
specify its own authentication credential by reference, since AS is
expected to obtain the actual authentication credential during a
previous client registration process or secure association
establishment with C.
Header: POST (Code=0.02)
Uri-Host: "as.example.com"
Uri-Path: "token"
Content-Format: application/ace+cbor
Payload:
{
"audience" : "tempSensor4711",
"scope" : "read",
"req_cnf" : {
"x5t" : h'822E4879F2A41B510C1F9B'
}
}
Figure 2: Example of C-to-AS POST /token request for an access token.
Selander, et al. Expires 5 September 2024 [Page 9]
Internet-Draft EDHOC and OSCORE profile of ACE March 2024
If C wants to update its access rights without changing an existing
OSCORE Security Context, it MUST include EDHOC_Information in its
POST request to the /token endpoint. The EDHOC_Information MUST
include the "session_id" field. This POST request MUST omit the
"req_cnf" parameter. An example of such a request is shown in
Figure 3.
The identifier "session_id" is assigned by AS as discussed in
Section 3.2, and, together with other information such as audience
(see Section 5.8.1 of [RFC9200]), can be used by AS to determine the
token series to which the new requested access token has to be added.
Therefore, the session_id MUST identify the pair (AUTH_CRED_C,
AUTH_CRED_RS) associated with a still valid access token previously
issued for C and RS by AS.
AS MUST verify that the received "session_id" identifies a token
series to which a still valid access token issued for C and RS
belongs. If that is not the case, the Client-to-AS request MUST be
declined with the error code "invalid_request" as defined in
Section 5.8.3 of [RFC9200].
Header: POST (Code=0.02)
Uri-Host: "as.example.com"
Uri-Path: "token"
Content-Format: application/ace+cbor
Payload:
{
"audience" : "tempSensor4711",
"scope" : "write",
"edhoc_info" : {
"session_id" : h'01'
}
}
Figure 3: Example of C-to-AS POST /token request for updating
access rights to an access token.
3.2. Token Series
This document refers to "token series" as a series of access tokens
sorted in chronological order as they are released, characterized by
the following properties:
* issued by the same AS
* issued to the same C, and associated with the same authentication
credential of C
Selander, et al. Expires 5 September 2024 [Page 10]
Internet-Draft EDHOC and OSCORE profile of ACE March 2024
* issued for the same RS, identified by the same authentication
credential
Upon a successful update of access rights, the new issued access
token becomes the latest in its token series. When the latest access
token of a token series becomes invalid (e.g., due to its expiration
or revocation), the token series it belongs to ends.
The general token series concept is defined in
[I-D.ietf-ace-workflow-and-params]. In this profile, a token series
is characterized by access tokens used between a given pair (C, RS)
having the same "session_id" in the EDHOC_Information, see
Section 3.4.
AS assigns the "session_id" to the EDHOC_Information when issuing the
first access token of a new series and that "session_id" remains
fixed throughout the series lifetime. When assigning the identifier,
AS MUST ensure that it was not used in a previous series whose access
tokens share the following properties with the access tokens of the
new series:
* i) issued for the same RS; and
* ii) bound to the same authentication credential AUTH_CRED_C of the
requesting client (irrespectively of how the AUTH_CRED_C is
identified in the access tokens).
In case the access token is issued for a group-audience (see
Section 6.9 of [RFC9200]), what is defined above applies, with the
difference that the token series is associated with all the RSs in
the group-audience, as indicated by their respective AUTH_CRED_RS.
3.3. AS-to-C: Response
After verifying the POST request to the /token endpoint and that C is
authorized to access, AS responds as defined in Section 5.8.2 of
[RFC9200], with potential modifications as detailed below. If the
request from C was invalid, or not authorized, AS returns an error
response as described in Section 5.8.3 of [RFC9200].
AS can signal that the use of EDHOC and OSCORE as per this profile is
REQUIRED for a specific access token, by including the "ace_profile"
parameter with the value "coap_edhoc_oscore" in the access token
response. This means that C MUST use EDHOC with RS and derive an
OSCORE Security Context, as specified in Section 4.4. After that, C
MUST use the established OSCORE Security Context to protect
communications with RS, when accessing protected resources at RS
according to the authorization information indicated in the access
Selander, et al. Expires 5 September 2024 [Page 11]
Internet-Draft EDHOC and OSCORE profile of ACE March 2024
token. Usually, it is assumed that constrained devices will be pre-
configured with the necessary profile, so that this kind of profile
signaling can be omitted.
The access token may be sent in the access token response to C for
subsequent provisioning to RS, or the access token may be uploaded by
AS directly to RS, as specified in
[I-D.ietf-ace-workflow-and-params].
* In the former case, AS provides the access token to C, by
specifying it in the "access_token" parameter of the access token
response.
* In the latter case, AS uploads the access token to the /authz-info
endpoint at RS, similarly to what is defined for C in Section 4.1
and Section 4.2. In case of successful token upload, the access
token response to C does not include the parameter "access_token",
and includes the parameter "token_uploaded" encoding the CBOR
simple value "true" (0xf5). An example is given in Appendix A.3.
When issuing any access token, AS MUST send the following data in the
response to C.
* The "session_id" field of EDHOC_Information, which is the
identifier of the token series which the issued access token
belongs to.
When issuing the first access token of a token series, AS MUST send
the following data in the response to C.
* A unique identification of the authentication credential of RS,
AUTH_CRED_RS. This is specified in the "rs_cnf" parameter defined
in [RFC9201]. AUTH_CRED_RS can be transported by value or
referred to by means of an appropriate identifier.
When issuing the first access token ever to a pair (C, RS) using a
pair of corresponding authentication credentials (AUTH_CRED_C,
AUTH_CRED_RS), it is typically expected that the response to C may
include AUTH_CRED_RS by value.
When later issuing further access tokens to the same pair (C, RS)
using the same AUTH_CRED_RS, it is expected that the response to C
includes AUTH_CRED_RS by reference.
Selander, et al. Expires 5 September 2024 [Page 12]
Internet-Draft EDHOC and OSCORE profile of ACE March 2024
When issuing the first access token of a token series, AS MAY send
EDHOC_Information related to RS, see Section 3.4, in corresponding
fields of the response to C. This information is based on knowledge
that AS have about RS, e.g., from a previous onboarding process, with
particular reference to what RS supports as EDHOC peer.
Figure 4 shows an example of an AS response. The "rs_cnf" parameter
specifies the authentication credential of RS, as an X.509
certificate transported by value in the "x5chain" field. The access
token and the authentication credential of RS have been truncated for
readability.
Header: Created (Code=2.01)
Content-Format: application/ace+cbor
Payload:
{
"access_token" : h'8343a1010aa2044c53/...
(remainder of access token (CWT) omitted for brevity)/',
"ace_profile" : "coap_edhoc_oscore",
"expires_in" : "3600",
"rs_cnf" : {
"x5chain" : h'3081ee3081a1a00302/...'
(remainder of the access credential omitted for brevity)/'
}
"edhoc_info" : {
"session_id" : h'01',
"methods" : [0, 1, 2, 3],
"cipher_suites": 0
}
}
Figure 4: Example of AS-to-C Access Token response with EDHOC and
OSCORE profile.
3.3.1. Access Token
When issuing any access token of a token series, AS MUST specify the
following data in the claims associated with the access token.
* The "session_id" field of EDHOC_Information, with the same value
specified in the response to C from the /token endpoint.
* The authentication credential that C specified in its POST request
to the /token endpoint (see Section 3.1), AUTH_CRED_C. If the
access token is a CWT, this information MUST be specified in the
"cnf" claim.
Selander, et al. Expires 5 September 2024 [Page 13]
Internet-Draft EDHOC and OSCORE profile of ACE March 2024
In the access token, AUTH_CRED_C can be transported by value or
uniquely referred to by means of an appropriate identifier,
regardless of how C specified it in the request to the /token
endpoint. Thus, the specific field carried in the access token
claim and specifying AUTH_CRED_C depends on the specific way used
by AS.
When issuing the first access token ever to a pair (C, RS) using a
pair of corresponding authentication credentials (AUTH_CRED_C,
AUTH_CRED_RS), it is typically expected that AUTH_CRED_C is
included by value.
When later issuing further access tokens to the same pair (C, RS)
using the same AUTH_CRED_C, it is expected that AUTH_CRED_C is
identified by reference.
When issuing the first access token of a token series, AS MAY specify
the following EDHOC_Information (see Section 3.4) in the claims
associated with the access token. If these data are specified in the
response to C from the /token endpoint, they MUST be included with
the same values in the access token.
* osc_ms_len: The size of the OSCORE Master Secret. If it is not
included, the default value from Appendix A.1 of
[I-D.ietf-lake-edhoc] is assumed.
* osc_salt_len: The size of the OSCORE Master Salt. If it is not
included, the default value from Appendix A.1 of
[I-D.ietf-lake-edhoc] is assumed.
* osc_version: The OSCORE version. If it is not included, the
default value of 1 (see Section 5.4 of [RFC8613]) is assumed.
When CWTs are used as access tokens, EDHOC_Information MUST be
transported in the "edhoc_info" claim, defined in Section 10.5.
Since the access token does not contain secret information, only its
integrity and source authentication are strictly necessary to ensure.
Therefore, AS can protect the access token with either of the means
discussed in Section 6.1 of [RFC9200]. Nevertheless, when using this
profile, it is RECOMMENDED that the access token is a CBOR web token
(CWT) protected with COSE_Encrypt/COSE_Encrypt0 as specified in
[RFC8392].
Selander, et al. Expires 5 September 2024 [Page 14]
Internet-Draft EDHOC and OSCORE profile of ACE March 2024
Figure 5 shows an example CWT Claims Set, including the relevant
EDHOC parameters in the "edhoc_info" claim. The "cnf" claim
specifies the authentication credential of C, as an X.509 certificate
transported by value in the "x5chain" field. The authentication
credential of C has been truncated for readability.
{
"aud" : "tempSensorInLivingRoom",
"iat" : "1360189224",
"exp" : "1360289224",
"scope" : "temperature_g firmware_p",
"cnf" : {
"x5chain" : h'3081ee3081a1a00302/...
(remainder of the access credential omitted for brevity)/'
}
"edhoc_info" : {
"session_id" : h'01',
"methods" : [0, 1, 2, 3],
"cipher_suites": 0
}
}
Figure 5: Example of CWT Claims Set with EDHOC parameters.
3.3.2. Processing in C
When receiving an Access Token response including the "rs_cnf"
parameter, C checks whether it is already storing the authentication
credential of RS, namely AUTH_CRED_RS, specified in "rs_cnf" by value
or reference.
If this is not the case, C retrieves AUTH_CRED_RS, either using the
"rs_cnf" parameter or some other trusted source. After that, C
validates the actual AUTH_CRED_RS. In case of successful validation,
C stores AUTH_CRED_RS as a valid authentication credential.
Otherwise, C MUST delete the access token.
3.3.3. Update of Access Rights
If C has requested an update to its access rights using the same
OSCORE Security Context, which is valid and authorized, then:
* The response MUST NOT include the "rs_cnf" parameter.
* The EDHOC_Information in the response MUST include only the
"session_id" field.
Selander, et al. Expires 5 September 2024 [Page 15]
Internet-Draft EDHOC and OSCORE profile of ACE March 2024
* The EDHOC_Information in the access token MUST include only the
"session_id" field. In particular, if the access token is a CWT,
the "edhoc_info" claim MUST include only the "session_id" field.
The "session_id" needs to be included in the new access token in
order for RS to identify the old access token to supersede, as well
as the OSCORE Security Context already shared between C and RS and to
be associated with the new access token.
3.4. EDHOC_Information
EDHOC_Information is an object including information that guides two
peers towards executing the EDHOC protocol. In particular, the
EDHOC_Information is defined to be serialized and transported between
nodes, as specified by this document, but it can also be used by
other specifications if needed.
The EDHOC_Information can be encoded either as a JSON object or as a
CBOR map. The set of common fields that can appear in an
EDHOC_Information can be found in the IANA "EDHOC Information"
registry (see Section 10.9), defined for extensibility, and the
initial set of parameters defined in this document is specified
below. All parameters are optional.
Figure 6 provides a summary of the EDHOC_Information parameters
defined in this section.
+---------------+-------+----------+----------------+-----------------+
| Name | CBOR | CBOR | Registry | Description |
| | label | type | | |
+---------------+-------+----------+----------------+-----------------+
| session_id | 0 | bstr | | Identifier of |
| | | | | a session |
+---------------+-------+----------+----------------+-----------------+
| methods | 1 | int / | EDHOC Method | Set of |
| | | array | Type Registry | supported |
| | | | | EDHOC methods |
+---------------+-------+----------+----------------+-----------------+
| cipher_suites | 2 | int / | EDHOC Cipher | Set of |
| | | array | Suites | supported EDHOC |
| | | | Registry | cipher suites |
+---------------+-------+----------+----------------+-----------------+
| message_4 | 3 | simple | | Support for |
| | | value | | EDHOC message_4 |
| | | "true" / | | |
| | | simple | | |
| | | value | | |
| | | "false" | | |
Selander, et al. Expires 5 September 2024 [Page 16]
Internet-Draft EDHOC and OSCORE profile of ACE March 2024
+---------------+-------+----------+----------------+-----------------+
| comb_req | 4 | simple | | Support for the |
| | | value | | EDHOC + OSCORE |
| | | "true" / | | combined |
| | | simple | | request |
| | | value | | |
| | | "false" | | |
+---------------+-------+----------+----------------+-----------------+
| uri_path | 5 | tstr | | URI-path of the |
| | | | | EDHOC resource |
+---------------+-------+----------+----------------+-----------------+
| osc_ms_len | 6 | uint | | Length in bytes |
| | | | | of the OSCORE |
| | | | | Master Secret |
| | | | | to derive |
+---------------+-------+----------+----------------+-----------------+
| osc_salt_len | 7 | uint | | Length in bytes |
| | | | | of the OSCORE |
| | | | | Master Salt to |
| | | | | derive |
+---------------+-------+----------+----------------+-----------------+
| osc_version | 8 | uint | | OSCORE version |
| | | | | number to use |
+---------------+-------+----------+----------------+-----------------+
| cred_types | 9 | int / | EDHOC | Set of |
| | | array | Authentication | supported |
| | | | Credential | types of |
| | | | Types Registry | authentication |
| | | | | credentials |
| | | | | for EDHOC |
+---------------+-------+----------+----------------+-----------------+
| id_cred_types | 10 | int / | COSE Header | Set of |
| | | tstr / | Parameters | supported |
| | | array | Registry | types of |
| | | | | authentication |
| | | | | credential |
| | | | | identifiers for |
| | | | | EDHOC |
+---------------+-------+----------+----------------+-----------------+
| eads | 11 | uint / | EDHOC External | Set of |
| | | array | Authorization | supported EDHOC |
| | | | Data Registry | External |
| | | | | Authorization |
| | | | | Data (EAD) |
| | | | | items |
+---------------+-------+----------+----------------+-----------------+
| initiator | 12 | simple | | Support for the |
| | | value | | EDHOC Initiator |
Selander, et al. Expires 5 September 2024 [Page 17]
Internet-Draft EDHOC and OSCORE profile of ACE March 2024
| | | "true" / | | role |
| | | simple | | |
| | | value | | |
| | | "false" | | |
+---------------+-------+----------+----------------+-----------------+
| responder | 13 | simple | | Support for the |
| | | value | | EDHOC Responder |
| | | "true" / | | role |
| | | simple | | |
| | | value | | |
| | | "false" | | |
+---------------+-------+----------+----------------+-----------------+
Figure 6: EDHOC_Information Parameters
* session_id: This parameter identifies a 'session' which the EDHOC
information is associated with, but does not necessarily identify
a specific EDHOC session. In this document, "session_id"
identifies a token series. In JSON, the "session_id" value is a
Base64 encoded byte string. In CBOR, the "session_id" type is a
byte string, and has label 0.
* methods: This parameter specifies a set of supported EDHOC methods
(see Section 3.2 of [I-D.ietf-lake-edhoc]). If the set is
composed of a single EDHOC method, this is encoded as an integer.
Otherwise, the set is encoded as an array of integers, where each
array element encodes one EDHOC method. In JSON, the "methods"
value is an integer or an array of integers. In CBOR, the
"methods" is an integer or an array of integers, and has label 1.
* cipher_suites: This parameter specifies a set of supported EDHOC
cipher suites (see Section 3.6 of [I-D.ietf-lake-edhoc]). If the
set is composed of a single EDHOC cipher suite, this is encoded as
an integer. Otherwise, the set is encoded as an array of
integers, where each array element encodes one EDHOC cipher suite.
In JSON, the "cipher_suites" value is an integer or an array of
integers. In CBOR, the "cipher_suites" is an integer or an array
of integers, and has label 2.
* message_4: This parameter indicates whether the EDHOC message_4
(see Section 5.5 of [I-D.ietf-lake-edhoc]) is supported. In JSON,
the "message_4" value is a boolean. In CBOR, "message_4" is the
simple value "true" or "false", and has label 4.
* comb_req: This parameter indicates whether the combined EDHOC +
OSCORE request defined in [I-D.ietf-core-oscore-edhoc]) is
supported. In JSON, the "comb_req" value is a boolean. In CBOR,
"comb_req" is the simple value "true" or "false", and has label 5.
Selander, et al. Expires 5 September 2024 [Page 18]
Internet-Draft EDHOC and OSCORE profile of ACE March 2024
* uri_path: This parameter specifies the path component of the URI
of the EDHOC resource where EDHOC messages have to be sent as
requests. In JSON, the "uri_path" value is a string. In CBOR,
"uri_path" is a text string, and has label 6.
* osc_ms_len: This parameter specifies the size in bytes of the
OSCORE Master Secret to derive after the EDHOC session, as per
Appendix A.1 of [I-D.ietf-lake-edhoc]. In JSON, the "osc_ms_len"
value is an integer. In CBOR, the "osc_ms_len" type is unsigned
integer, and has label 7.
* osc_salt_len: This parameter specifies the size in bytes of the
OSCORE Master Salt to derive after the EDHOC session, as per
Appendix A.1 of [I-D.ietf-lake-edhoc]. In JSON, the
"osc_salt_len" value is an integer. In CBOR, the "osc_salt_len"
type is unsigned integer, and has label 8.
* osc_version: This parameter specifies the OSCORE Version number
that the two EDHOC peers have to use when using OSCORE. For more
information about this parameter, see Section 5.4 of [RFC8613].
In JSON, the "osc_version" value is an integer. In CBOR, the
"osc_version" type is unsigned integer, and has label 9.
* cred_types: This parameter specifies a set of supported types of
authentication credentials for EDHOC (see Section 3.5.2 of
[I-D.ietf-lake-edhoc]). If the set is composed of a single type
of authentication credential, this is encoded as an integer.
Otherwise, the set is encoded as an array of integers, where each
array element encodes one type of authentication credential. In
JSON, the "cred_types" value is an integer or an array of
integers. In CBOR, "cred_types" is an integer or an array of
integers, and has label 9. The integer values are taken from the
"EDHOC Authentication Credential Types" registry defined in
[I-D.ietf-core-oscore-edhoc].
* id_cred_types: This parameter specifies a set of supported types
of authentication credential identifiers for EDHOC (see
Section 3.5.3 of [I-D.ietf-lake-edhoc]). If the set is composed
of a single type of authentication credential identifier, this is
encoded as an integer or a text string. Otherwise, the set is
encoded as an array, where each array element encodes one type of
authentication credential identifier, as an integer or a text
string. In JSON, the "id_cred_types" value is an integer, or a
text string, or an array of integers and text strings. In CBOR,
"id_cred_types" is an integer or a text string, or an array of
integers and text strings, and has label 10. The integer or text
string values are taken from the 'Label' column of the "COSE
Header Parameters" registry [COSE.Header.Parameters].
Selander, et al. Expires 5 September 2024 [Page 19]
Internet-Draft EDHOC and OSCORE profile of ACE March 2024
* eads: This parameter specifies a set of supported EDHOC External
Authorization Data (EAD) items, identified by their ead_label (see
Section 3.8 of [I-D.ietf-lake-edhoc]). If the set is composed of
a single ead_label, this is encoded as an unsigned integer.
Otherwise, the set is encoded as an array of unsigned integers,
where each array element encodes one ead_label. In JSON, the
"eads" value is an unsigned integer or an array of unsigned
integers. In CBOR, "eads" is an unsigned integer or an array of
unsigned integers, and has label 11. The unsigned integer values
are taken from the 'Label' column of the "EDHOC External
Authorization Data" registry defined in [I-D.ietf-lake-edhoc].
* initiator: This parameter specifies whether the EDHOC Initiator
role is supported. In JSON, the "initiator" value is a boolean.
In CBOR, "initiator" is the simple value "true" (0xf5) or "false"
(0xf4), and has label 12.
* responder: This parameter specifies whether the EDHOC Responder
role is supported. In JSON, the "responder" value is a boolean.
In CBOR, "responder" is the simple value "true" (0xf5) or "false"
(0xf4), and has label 13.
An example of JSON EDHOC_Information is given in Figure 7.
"edhoc_info" : {
"session_id" : b64'AQ==',
"methods" : 1,
"cipher_suites" : 0
}
Figure 7: Example of JSON EDHOC_Information
The CDDL grammar describing the CBOR EDHOC_Information is:
Selander, et al. Expires 5 September 2024 [Page 20]
Internet-Draft EDHOC and OSCORE profile of ACE March 2024
EDHOC_Information = {
? 0 => bstr, ; id
? 1 => int / array, ; methods
? 2 => int / array, ; cipher_suites
? 3 => true / false, ; message_4
? 4 => true / false, ; comb_req
? 5 => tstr, ; uri_path
? 6 => uint, ; osc_ms_len
? 7 => uint, ; osc_salt_len
? 8 => uint, ; osc_version
? 9 => int / array, ; cred_types
? 10 => int / tstr / array, ; id_cred_types
? 11 => uint / array, ; eads
? 12 => true / false, ; initiator
? 13 => true / false, ; responder
* int / tstr => any
}
4. Client-RS Communication
This section describes the exchanges between C and RS, which comprise
the token uploading to RS, and the execution of the EDHOC protocol.
Note that AS may have uploaded the access token directly to RS (see
Section 3.3).
In order to upload the access token to RS, C can send a POST request
to the /authz-info endpoint at RS. This is detailed in Section 4.1
and Section 4.2, and shown by the example in Appendix A.1.
Alternatively, C can upload the access token while executing the
EDHOC protocol, by transporting the access token in an EAD field of
an EDHOC message sent to RS. This is further discussed in
Section 4.3 and Section 4.4, and shown by the example in
Appendix A.2.
In either case, C and RS run the EDHOC protocol by exchanging POST
requests and related responses to a dedicated EDHOC resource at RS
(see Section 4.4). Once completed the EDHOC session, C and RS have
agreed on a common secret key PRK_out (see Section 4.1.3 of
[I-D.ietf-lake-edhoc]), from which they establish an OSCORE Security
Context (see Section 4.4). After that, C and RS use the established
OSCORE Security Context to protect their communications when
accessing protected resources at RS, as per the access rights
specified in the access token (see Section 4.8).
C and RS are mutually authenticated once they have successfully
completed the EDHOC protocol. RS gets key confirmation of PRK_out by
C at the end of the successful EDHOC session. Conversely, C get key
Selander, et al. Expires 5 September 2024 [Page 21]
Internet-Draft EDHOC and OSCORE profile of ACE March 2024
confirmation of PRK_out by RS either when receiving and successfully
verifying the optional EDHOC message_4 from RS, or when successfully
verifying a response from RS protected with the generated OSCORE
Security Context.
4.1. C-to-RS: POST to /authz-info endpoint
The access token can be uploaded to RS by using the /authz-info
endpoint at RS. To this end, C uses CoAP [RFC7252] and the
Authorization Information endpoint described in Section 5.10.1 of
[RFC9200] in order to transport the access token.
That is, C sends a POST request to the /authz-info endpoint at RS,
with the request payload conveying the access token without any CBOR
wrapping. As per Section 5.10.1 of [RFC9200], the Content-Format of
the POST request has to reflect the format of the transported access
token. In particular, if the access token is a CWT, the Content-
Format MUST be "application/cwt".
The communication with the /authz-info endpoint is in general not
protected, except in the case of updating the access rights (see
Section 4.5).
4.2. RS-to-C: 2.01 (Created)
Upon receiving an access token from C, RS MUST follow the procedures
defined in Section 5.10.1 of [RFC9200]. That is, RS must verify the
validity of the access token. RS may make an introspection request
(see Section 5.9.1 of [RFC9200]) to validate the access token.
If the access token is valid, RS proceeds as follows.
RS checks whether it is already storing the authentication credential
of C, AUTH_CRED_C, specified in the "cnf" claim of the access token
by value or by reference. If not, RS retrieves AUTH_CRED_C, either
using the "cnf" claim or some other trusted source.
If RS fails to find or validate AUTH_CRED_C, then RS MUST respond
with an error response code equivalent to the CoAP code 4.00 (Bad
Request). RS may provide additional information in the payload of
the error response, in order to clarify what went wrong.
If, instead, the access token is valid but associated with claims
that RS cannot process (e.g., an unknown scope), or if any of the
expected parameters is missing (e.g., any of the mandatory parameters
from AS or the identifier "session_id"), or if any parameters
received in the EDHOC_Information is unrecognized, then RS MUST
respond with an error response code equivalent to the CoAP code 4.00
Selander, et al. Expires 5 September 2024 [Page 22]
Internet-Draft EDHOC and OSCORE profile of ACE March 2024
(Bad Request). In the latter two cases, RS may provide additional
information in the payload of the error response, in order to clarify
what went wrong.
If all validations are successful, RS MUST reply to the POST request
with a 2.01 (Created) response. The access token is stored such that
it is possible to retrieve it based on "session_id" and AUTH_CRED_C.
When an access token becomes invalid (e.g., due to its expiration or
revocation), RS MUST delete the access token and the associated
OSCORE Security Context, and MUST notify C with an error response
with code 4.01 (Unauthorized) for any long running request, as
specified in Section 5.8.3 of [RFC9200].
4.3. Access Token in External Authorization Data
Instead of uploading the access token to the /authz-info endpoint at
RS as described in Section 4.1, C MAY include the access token in
EDHOC message_3 by making use of the External Authorization Data
field EAD_3 (see Section 3.8 of [I-D.ietf-lake-edhoc]), see example
in Appendix A.2. In this case, the access token is encrypted between
C and RS enabling protection of potential sensitive information.
This document defines the EAD item EAD_ACCESS_TOKEN = (ead_label,
ead_value), where:
* ead_label is the integer value TBD registered in Section 10.8 and
* ead_value is a CBOR byte string, with value the binary
serialization of a CBOR map. The CBOR map includes one field,
whose label is a CBOR unsigned integer with value either 0 or 1,
and whose value is a CBOR byte string:
- For label 0, ead_value = { 0 : access_token }, where
access_token is a CBOR byte string equal to the value of the
"access_token" field of the access token response from AS, see
Section 3.3.
- For label 1, ead_value = { 1 : session_id }, where session_id
is a CBOR byte string equal to the value of the "session_id"
field of the access token response from AS, see Section 3.2.
Selander, et al. Expires 5 September 2024 [Page 23]
Internet-Draft EDHOC and OSCORE profile of ACE March 2024
This EAD item, which is used in EAD_3, is critical, i.e., it is used
only with the negative value of its ead_label, indicating that the
receiving RS must either process the access token or abort the EDHOC
session (see Section 3.8 of [I-D.ietf-lake-edhoc]). A Client or
Resource Server supporting the profile of ACE defined in this
document MUST support this EAD item. When EDHOC is used with this
profile, this EAD item is included in EAD_3, see Section 4.4.3.
Access tokens are transported in EAD fields only for the first access
token of a token series, and not for the update of access rights, see
Section 4.5.
4.4. EDHOC Session and OSCORE Security Context
In order to mutually authenticate and establish secure communication
for authorized access according to the profile described in this
document, C and RS run the EDHOC protocol [I-D.ietf-lake-edhoc] with
C as EDHOC Initiator and RS as EDHOC Responder. When a new EDHOC
session is established, previous EDHOC sessions associated with the
same access token and the same pair (session_id, AUTH_CRED_C) are
deleted, see Section 4.4.3. The OSCORE Security Contexts derived
from those EDHOC sessions are also deleted.
As per Appendix A.2 of [I-D.ietf-lake-edhoc], C sends EDHOC message_1
and EDHOC message_3 to an EDHOC resource at RS, as CoAP POST
requests. RS sends EDHOC message_2 and (optionally) EDHOC message_4
as 2.04 (Changed) CoAP responses. C MUST target the EDHOC resource
at RS with the URI path specified in the "uri_path" field of the
EDHOC_Information in the access token response received from AS (see
Section 3.1), if present.
In order to seamlessly run EDHOC, a client does not have to first
upload to RS an access token whose scope explicitly indicates
authorized access to the EDHOC resource. At the same time, RS has to
ensure that attackers cannot perform requests on the EDHOC resource,
other than sending EDHOC messages. Specifically, it SHOULD NOT be
possible to perform anything else than POST on an EDHOC resource.
4.4.1. EDHOC message_1
The processing of EDHOC message_1 is specified in Section 5.2 of
[I-D.ietf-lake-edhoc]. Additionally, the following applies:
* The EDHOC method MUST be one of the EDHOC methods specified in the
"methods" field (if present) in the EDHOC_Information of the
access token response to C.
Selander, et al. Expires 5 September 2024 [Page 24]
Internet-Draft EDHOC and OSCORE profile of ACE March 2024
* The selected cipher suite MUST be an EDHOC cipher suite specified
in the "cipher_suites" field (if present) in the EDHOC_Information
of the access token response to C.
4.4.2. EDHOC message_2
The processing of EDHOC message_2 is specified in Section 5.3 of
[I-D.ietf-lake-edhoc] with the following additions:
* The authentication credential CRED_R indicated by the message
field ID_CRED_R is AUTH_CRED_RS.
4.4.3. EDHOC message_3
The processing of EDHOC message_3 is specified in Section 5.4 of
[I-D.ietf-lake-edhoc] with the following additions:
* The authentication credential CRED_I indicated by the message
field ID_CRED_I is AUTH_CRED_C.
* The EAD item EAD_ACCESS_TOKEN = (-ead_label, ead_value) MUST be
included in the EAD_3 field. If the access token is provisioned
with EDHOC message_3 as specified in Section 4.3, then ead_value =
{ 0 : access_token}, otherwise ead_value = { 1 : session_id},
where session_id is equal to the value of the "session_id" field
of the access token response from AS, see Section 3.2.
* The RS MUST ensure that the access token is valid, potentially
first retrieving it using session_id and AUTH_CRED_C, the
validation follows the procedure specified in Section 4.2. If
such a process fails, RS MUST reply to C with an EDHOC error
message with ERR_CODE = 1 (see Section 6 of
[I-D.ietf-lake-edhoc]), and it MUST abort the EDHOC session. RS
MUST have successfully validated the processing of the access
token before completing the EDHOC session. If completed
successfully, then the EDHOC session is associated with both the
access token and the pair (session_id, AUTH_CRED_C). Any old
existing EDHOC session associated with the same access token and
with the same pair (session_id, AUTH_CRED_C) MUST be deleted,
together with the OSCORE Security Context derived from the EDHOC
session.
Editor's note: Instead of ERR_CODE = 1, consider to use ERR_CODE = 3
"Access Denied" defined in draft-ietf-lake-authz
Selander, et al. Expires 5 September 2024 [Page 25]
Internet-Draft EDHOC and OSCORE profile of ACE March 2024
4.4.4. OSCORE Security Context
Once successfully completed the EDHOC session, C and RS derive an
OSCORE Security Context, as defined in Appendix A.1 of
[I-D.ietf-lake-edhoc]. In addition, the following applies.
* The length in bytes of the OSCORE Master Secret (i.e., the
oscore_key_length parameter, see Appendix A.1 of
[I-D.ietf-lake-edhoc]) MUST be the value specified in the
"osc_ms_size" field (if present) in the EDHOC_Information of the
access token response to C, and of the access token provisioned to
RS, respectively.
* The length in bytes of the OSCORE Master Salt (i.e., the
oscore_salt_length parameter, see Appendix A.1 of
[I-D.ietf-lake-edhoc]) MUST be the value specified in the
"osc_salt_size" field (if present) in the EDHOC_Information of the
access token response to C, and of the access token provisioned to
RS, respectively.
* C and RS MUST use the OSCORE version specified in the
"osc_version" field (if present) in the EDHOC_Information of the
access token response to C, and of the access token provisioned to
RS, respectively.
* RS associates the latest EDHOC session and the derived OSCORE
Security Context with the stored access token, which is bound to
the authentication credential (AUTH_CRED_C = CRED_I) used in the
EDHOC session and with the session_id identifying the token series
to which the access token belongs.
If supported by C, C MAY use the EDHOC + OSCORE combined request
defined in [I-D.ietf-core-oscore-edhoc], unless the "comb_req" field
of the EDHOC_Information was present in the access token response and
set to the CBOR simple value "false" (0xf4). In the combined
request, both EDHOC message_3 and the first OSCORE-protected
application request are combined together in a single OSCORE-
protected CoAP request, thus saving one round trip. For an example,
see Appendix A.2. This requires C to derive the OSCORE Security
Context with RS already after having successfully processed the
received EDHOC message_2 and before sending EDHOC message_3.
4.5. Update of Access Rights
If C has already established access rights and an OSCORE Security
Context with RS, then C can update its access rights by posting a new
access token to the /authz-info endpoint.
Selander, et al. Expires 5 September 2024 [Page 26]
Internet-Draft EDHOC and OSCORE profile of ACE March 2024
The new access token contains the updated access rights for C to
access protected resources at RS, and C has to obtain it from AS as a
new access token in the same token series of the current one (see
Section 3). When posting the new access token to the /authz-info
endpoint, C MUST protect the POST request using the current OSCORE
Security Context shared with RS. After successful verification (see
Section 4.2), RS will replace the old access token with the new one,
while preserving the same OSCORE Security Context. In particular, C
and RS do not re-run the EDHOC protocol and they do not establish a
new OSCORE Security Context.
Editor's note: Add description about the alternative when the AS
uploads the new access token to RS.
If RS receives an access token in an OSCORE protected request, it
means that C is requesting an update of access rights. In this case,
RS MUST check the following conditions:
* RS checks whether it stores an access token T_OLD, such that the
"session_id" field of EDHOC_Information matches the "session_id"
field of EDHOC_Information in the new access token T_NEW.
* RS checks whether the OSCORE Security Context CTX used to protect
the request matches the OSCORE Security Context associated with
the stored access token T_OLD.
If both the conditions above hold, RS MUST replace the old access
token T_OLD with the new access token T_NEW, and associate T_NEW with
the OSCORE Security Context CTX. Then, RS MUST respond with a 2.01
(Created) response protected with the same OSCORE Security Context,
with no payload.
Otherwise, RS MUST respond with a 4.01 (Unauthorized) error response.
RS may provide additional information in the payload of the error
response, in order to clarify what went wrong.
As specified in Section 5.10.1 of [RFC9200], when receiving an
updated access token with updated authorization information from C
(see Section 4.1), it is recommended that RS overwrites the previous
access token. That is, only the latest authorization information in
the access token received by RS is valid. This simplifies the
process needed by RS to keep track of authorization information for a
given client.
4.6. Discarding the Security Context
There are a number of cases where C or RS have to discard the OSCORE
Security Context, and possibly establish a new one.
Selander, et al. Expires 5 September 2024 [Page 27]
Internet-Draft EDHOC and OSCORE profile of ACE March 2024
C MUST discard the current OSCORE Security Context shared with RS
when any of the following occurs.
* The OSCORE Sender Sequence Number space of C is exhausted.
* The access token associated with the OSCORE Security Context
becomes invalid, for example due to expiration or revocation.
* C receives a number of unprotected 4.01 (Unauthorized) responses
to OSCORE-protected requests, which are sent to RS and protected
using the same OSCORE Security Context. The exact number of such
received responses needs to be specified by the application. This
may for example happen due to lack of storage in RS, which then
sends the "AS Request Creation Hints" message (see Section 5.3 of
[RFC9200]).
* The authentication credential of C (of RS) becomes invalid, e.g.,
due to expiration or revocation, and it was used as CRED_I
(CRED_R) in the EDHOC session to establish the OSCORE Security
Context.
RS MUST discard the current OSCORE Security Context shared with C
when any of the following occurs:
* The OSCORE Sender Sequence Number space of RS is exhausted.
* The access token associated with the OSCORE Security Context
becomes invalid, for example due to expiration or revocation.
* The authentication credential of C (of RS) becomes invalid (e.g.,
due to expiration or revocation), and it was used as CRED_I
(CRED_R) in the EDHOC session to establish the OSCORE Security
Context.
After a new access token is successfully uploaded to RS, and a new
OSCORE Security Context is established between C and RS, messages
still in transit that were protected with the previous OSCORE
Security Context might not be successfully verified by the recipient,
since the old OSCORE Security Context might have been discarded.
This means that messages sent shortly before C has uploaded the new
access token to RS might not be successfully accepted by the
recipient.
Selander, et al. Expires 5 September 2024 [Page 28]
Internet-Draft EDHOC and OSCORE profile of ACE March 2024
Furthermore, implementations may want to cancel CoAP observations at
RS, if registered before the new OSCORE Security Context has been
established. Alternatively, applications need to implement a
mechanism to ensure that, from then on, messages exchanged within
those observations are going to be protected with the newly derived
OSCORE Security Context.
4.7. Cases of Establishing a New OSCORE Security Context
The procedure of provisioning a new access token to RS specified in
this section applies to various cases when an OSCORE Security Context
shared between C and RS has been deleted, for example as described in
Section 4.6.
Another exceptional case is when there is still a valid OSCORE
Security Context but it needs to be updated, e.g., due to a policy
limiting its use in terms of time or amount of processed data, or to
the imminent exhaustion of the OSCORE Sender Sequence Number space.
In this case, C and RS SHALL attempt to run the KUDOS key update
protocol [I-D.ietf-core-oscore-key-update], which is a lightweight
alternative independent of ACE and EDHOC that does not require the
posting of an access token. If KUDOS is not supported, then C and RS
falls back to EDHOC as outlined above.
In either case, C and RS establish a new OSCORE Security Context that
replaces the old one and will be used for protecting their
communications from then on. In particular, RS MUST associate the
new OSCORE Security Context with the current (potentially re-posted)
access token. Unless C and RS re-run the EDHOC protocol, they
preserve their OSCORE identifiers, i.e., the OSCORE Sender/Recipient
IDs.
4.8. Access Rights Verification
RS MUST follow the procedures defined in Section 5.10.2 of [RFC9200].
That is, if RS receives an OSCORE-protected request targeting a
protected resource from C, then RS processes the request according to
[RFC8613], when Version 1 of OSCORE is used. Future specifications
may define new versions of OSCORE, which AS can indicate C and RS to
use by means of the "osc_version" field of EDHOC_Information (see
Section 3).
If OSCORE verification succeeds and the target resource requires
authorization, RS retrieves the authorization information using the
access token associated with the OSCORE Security Context. Then, RS
must verify that the authorization information covers the target
resource and the action intended by C on it.
Selander, et al. Expires 5 September 2024 [Page 29]
Internet-Draft EDHOC and OSCORE profile of ACE March 2024
5. Secure Communication with AS
As specified in the ACE framework (see Sections 5.8 and 5.9 of
[RFC9200]), the requesting entity (RS and/or C) and AS communicates
via the /token or /introspect endpoint. When using this profile, the
use of CoAP [RFC7252] and OSCORE [RFC8613] for this communication is
RECOMMENDED. Other protocols fulfilling the security requirements
defined in Section 5 of [RFC9200] (such as HTTP and DTLS [RFC9147] or
TLS [RFC8446]) MAY be used instead.
If OSCORE is used, the requesting entity and AS need to have an
OSCORE Security Context in place. While this can be pre-installed,
the requesting entity and AS can establish such an OSCORE Security
Context, for example, by running the EDHOC protocol, as shown between
C and AS by the examples in Appendix A.1, Appendix A.2, and
Appendix A.3.
Furthermore, as discussed in Section 3.3 and shown by the example in
Appendix A.3, AS may upload an access token directly to the /authz-
info endpoint at RS. Unless encryption is applied, that exchange
between AS and RS discloses the plain text token, just like when C
uses the /authz-info endpoint at RS to upload a first token in a
series.
Editor's note: Elaborate on how to encrypt the token from AS to RS,
since there is a pre-established security context.
6. CWT Confirmation Methods
This document defines a number of new CWT confirmation methods (see
Section 10.7). The semantics of each confirmation method is defined
below.
6.1. Ordered Chain of X.509 Certificates
The confirmation method "x5chain" specifies an ordered array of X.509
certificates [RFC5280]. The semantics of "x5chain" is like that of
the "x5chain" COSE Header Parameter specified in [RFC9360].
6.2. Unordered Bag of X.509 Certificates
The confirmation method "x5bag" specifies a bag of X.509 certificates
[RFC5280]. The semantics of "x5bag" is like that of the "x5bag" COSE
Header Parameter specified in [RFC9360].
Selander, et al. Expires 5 September 2024 [Page 30]
Internet-Draft EDHOC and OSCORE profile of ACE March 2024
6.3. Hash of an X.509 Certificate
The confirmation method "x5t" specifies the hash value of the end-
entity X.509 certificate [RFC5280]. The semantics of "x5t" is like
that of the "x5t" COSE Header Parameter specified in [RFC9360].
6.4. URI Pointing to an Ordered Chain of X.509 Certificates
The confirmation method "x5u" specifies the URI [RFC3986] of an
ordered chain of X.509 certificates [RFC5280]. The semantics of
"x5u" is like that of the "x5u" COSE Header Parameter specified in
[RFC9360].
6.5. Ordered Chain of C509 Certificates
The confirmation method "c5c" specifies an ordered array of C509
certificates [I-D.ietf-cose-cbor-encoded-cert]. The semantics of
"c5c" is like that of the "c5c" COSE Header Parameter specified in
[I-D.ietf-cose-cbor-encoded-cert].
6.6. Unordered Bag of C509 Certificates
The confirmation method "c5b" specifies a bag of C509 certificates
[I-D.ietf-cose-cbor-encoded-cert]. The semantics of "c5b" is like
that of the "c5b" COSE Header Parameter specified in
[I-D.ietf-cose-cbor-encoded-cert].
6.7. Hash of a C509 Certificate
The confirmation method "c5t" specifies the hash value of the end-
entity C509 certificate [I-D.ietf-cose-cbor-encoded-cert]. The
semantics of "c5t" is like that of the "c5t" COSE Header Parameter
specified in [I-D.ietf-cose-cbor-encoded-cert].
6.8. URI Pointing to an Ordered Chain of C509 Certificates
The confirmation method "c5u" specifies the URI [RFC3986] of a
COSE_C509 containing an ordered chain of C509 certificates
[I-D.ietf-cose-cbor-encoded-cert]. COSE_C509 is defined in
[I-D.ietf-cose-cbor-encoded-cert]. The semantics of "c5u" is like
that of the "c5u" COSE Header Parameter specified in
[I-D.ietf-cose-cbor-encoded-cert].
Selander, et al. Expires 5 September 2024 [Page 31]
Internet-Draft EDHOC and OSCORE profile of ACE March 2024
6.9. CWT Containing a COSE_Key
The confirmation method "kcwt" specifies a CBOR Web Token (CWT)
[RFC8392] containing a COSE_Key [RFC9053] in a 'cnf' claim and
possibly other claims. The semantics of "kcwt" is like that of the
"kcwt" COSE Header Parameter specified in [I-D.ietf-lake-edhoc].
6.10. CCS Containing a COSE_Key
The confirmation method "kccs" specifies a CWT Claims Set (CCS)
[RFC8392] containing a COSE_Key [RFC9053] in a 'cnf' claim and
possibly other claims. The semantics of "kccs" is like that of the
"kccs" COSE Header Parameter specified in [I-D.ietf-lake-edhoc].
7. JWT Confirmation Methods
This document defines a number of new JWT confirmation methods (see
Section 10.6). The semantics of each confirmation method is defined
below.
7.1. Ordered Chain of X.509 Certificates
The confirmation method "x5c" specifies an ordered array of X.509
certificates [RFC5280]. The semantics of "x5c" is like that of the
"x5c" JSON Web Signature and Encryption Header Parameter specified in
[RFC7515], with the following difference. The public key contained
in the first certificate is the proof-of-possession key and does not
have to correspond to a key used to digitally sign the JWS.
7.2. Unordered Bag of X.509 Certificates
The confirmation method "x5b" specifies a bag of X.509 certificates
[RFC5280]. The semantics of the "x5b" is like that of the "x5c" JWT
confirmation method defined in Section 7.1, with the following
differences. First, the set of certificates is unordered and may
contain self-signed certificates. Second, the composition and
processing of "x5b" are like for the "x5bag" COSE Header Parameter
defined in [RFC9360].
7.3. Hash of an X.509 Certificate
The confirmation method "x5t" specifies the hash value of the end-
entity X.509 certificate [RFC5280]. The semantics of "x5t" is like
that of the "x5t" JSON Web Signature and Encryption Header Parameter
specified in [RFC7515].
Selander, et al. Expires 5 September 2024 [Page 32]
Internet-Draft EDHOC and OSCORE profile of ACE March 2024
7.4. URI Pointing to an Ordered Chain of X.509 Certificates
The confirmation method "x5u" specifies the URI [RFC3986] of an
ordered chain of X.509 certificates [RFC5280]. The semantics of
"x5u" is like that of the "x5u" COSE Header Parameter specified in
[RFC9360], with the following difference. The public key contained
in the first certificate is the proof-of-possession key and does not
have to correspond to a key used to digitally sign the JWS.
7.5. Ordered Chain of C509 Certificates
The confirmation method "c5c" specifies an ordered array of C509
certificates [I-D.ietf-cose-cbor-encoded-cert]. The semantics of
"c5c" is like that of the "x5c" JWT confirmation method defined in
Section 7.1, with the following difference. Each string in the JSON
array is a base64-encoded (Section 4 of [RFC4648] - not base64url-
encoded) C509 certificate.
7.6. Unordered Bag of C509 Certificates
The confirmation method "c5b" specifies a bag of C509 certificates
[I-D.ietf-cose-cbor-encoded-cert]. The semantics of "c5b" is like
that of the "c5c" JWT confirmation method defined in Section 7.5,
with the following differences. First, the set of certificates is
unordered and may contain self-signed certificates. Second, the
composition and processing of "c5b" is like for the "c5b" COSE Header
Parameter defined in [I-D.ietf-cose-cbor-encoded-cert].
7.7. Hash of a C09 Certificate
The confirmation method "c5t" specifies the hash value of the end-
entity C509 certificate [I-D.ietf-cose-cbor-encoded-cert]. The
semantics of "c5t" is like that of the "x5t" JWT confirmation method
defined in Section 7.3, with the following differences. First, the
base64url-encoded SHA-1 thumbprint is computed over the C509
certificate. Second, the public key contained in the C509
certificate does not have to correspond to a key used to digitally
sign the JWS.
7.8. URI Pointing to an Ordered Chain of C509 Certificates
The confirmation method "c5u" specifies the URI [RFC3986] of
COSE_C509 containing an ordered chain of C509 certificates
[I-D.ietf-cose-cbor-encoded-cert]. COSE_C509 is defined in
[I-D.ietf-cose-cbor-encoded-cert]. The semantics of "c5u" is like
that of the "x5u" JWT confirmation method defined in Section 7.4,
with the following differences. First, the URI refers to a resource
for the C509 certificate chain. Second, the public key contained in
Selander, et al. Expires 5 September 2024 [Page 33]
Internet-Draft EDHOC and OSCORE profile of ACE March 2024
one of the C509 certificates and acting as proof-of-possession key
does not have to correspond to a key used to digitally sign the JWS.
7.9. CWT Containing a COSE_Key
The confirmation method "kcwt" specifies a CBOR Web Token (CWT)
[RFC8392] containing a COSE_Key [RFC9053] in a 'cnf' claim and
possibly other claims. The format of "kcwt" is the base64url-encoded
serialization of the CWT.
7.10. CCS Containing a COSE_Key
The confirmation method "kccs" specifies a CWT Claims Set (CCS)
[RFC8392] containing a COSE_Key [RFC9053] in a 'cnf' claim and
possibly other claims. The format of "kcwt" is the base64url-encoded
serialization of the CWT.
8. Security Considerations
This document specifies a profile for the Authentication and
Authorization for Constrained Environments (ACE) framework [RFC9200].
Thus, the general security considerations from the ACE framework also
apply to this profile.
Furthermore, the security considerations from OSCORE [RFC8613] and
from EDHOC [I-D.ietf-lake-edhoc] also apply to this specific use of
the OSCORE and EDHOC protocols.
As previously stated, once completed the EDHOC session, C and RS are
mutually authenticated through their respective authentication
credentials, whose retrieval has been facilitated by AS. Also once
completed the EDHOC session, C and RS have established a long-term
secret key PRK_out enjoying forward secrecy. This is in turn used by
C and RS to establish an OSCORE Security Context.
Furthermore, RS achieves confirmation that C has PRK_out (proof-of-
possession) when completing the EDHOC session. Rather, C achieves
confirmation that RS has PRK_out (proof-of-possession) either when
receiving the optional EDHOC message_4 from RS, or when successfully
verifying a response from RS protected with the established OSCORE
Security Context.
Selander, et al. Expires 5 September 2024 [Page 34]
Internet-Draft EDHOC and OSCORE profile of ACE March 2024
OSCORE is designed to secure point-to-point communication, providing
a secure binding between a request and the corresponding response(s).
Thus, the basic OSCORE protocol is not intended for use in point-to-
multipoint communication (e.g., enforced via multicast or a publish-
subscribe model). Implementers of this profile should make sure that
their use case of OSCORE corresponds to the expected one, in order to
prevent weakening the security assurances provided by OSCORE.
When using this profile, it is RECOMMENDED that RS stores only one
access token per client. The use of multiple access tokens for a
single client increases the strain on RS, since it must consider
every access token associated with the client and calculate the
actual permissions that client has. Also, access tokens indicating
different or disjoint permissions from each other may lead RS to
enforce wrong permissions. If one of the access tokens expires
earlier than others, the resulting permissions may offer insufficient
protection. Developers SHOULD avoid using multiple access tokens for
a same client. Furthermore, RS MUST NOT store more than one access
token per client per PoP-key (i.e., per client's authentication
credential).
9. Privacy Considerations
This document specifies a profile for the Authentication and
Authorization for Constrained Environments (ACE) framework [RFC9200].
Thus, the general privacy considerations from the ACE framework also
apply to this profile.
Furthermore, the privacy considerations from OSCORE [RFC8613] and
from EDHOC [I-D.ietf-lake-edhoc] also apply to this specific use of
the OSCORE and EDHOC protocols.
An unprotected response to an unauthorized request may disclose
information about RS and/or its existing relationship with C. It is
advisable to include as little information as possible in an
unencrypted response. When an OSCORE Security Context already exists
between C and RS, more detailed information may be included.
Except for the case where C attempts to update its access rights, the
(encrypted) access token is sent in an unprotected POST request to
the /authz-info endpoint at RS. Thus, if C uses the same single
access token from multiple locations, it can risk being tracked by
the access token's value even when the access token is encrypted.
The identifiers used in OSCORE, i.e., the OSCORE Sender/Recipient
IDs, are negotiated by C and RS during the EDHOC session. That is,
the EDHOC Connection Identifier C_I of C is going to be the OSCORE
Recipient ID of C (the OSCORE Sender ID of RS). Conversely, the
Selander, et al. Expires 5 September 2024 [Page 35]
Internet-Draft EDHOC and OSCORE profile of ACE March 2024
EDHOC Connection Identifier C_R of RS is going to be the OSCORE
Recipient ID of RS (the OSCORE Sender ID of C). These OSCORE
identifiers are privacy sensitive (see Section 12.8 of [RFC8613]).
In particular, they could reveal information about C, or may be used
for correlating different requests from C, e.g., across different
networks that C has joined and left over time. This can be mitigated
if C and RS dynamically update their OSCORE identifiers, e.g., by
using the method defined in [I-D.ietf-core-oscore-key-update].
10. IANA Considerations
This document has the following actions for IANA.
Note to RFC Editor: Please replace all occurrences of "[RFC-XXXX]"
with the RFC number of this specification and delete this paragraph.
10.1. ACE OAuth Profile Registry
IANA is asked to add the following entry to the "ACE OAuth Profile"
Registry following the procedure specified in [RFC9200].
* Profile name: coap_edhoc_oscore
* Profile Description: Profile for delegating client authentication
and authorization in a constrained environment by establishing an
OSCORE Security Context [RFC8613] between resource-constrained
nodes, through the execution of the authenticated key
establishment protocol EDHOC [I-D.ietf-lake-edhoc].
* Profile ID: TBD (value between 1 and 255)
* Change Controller: IESG
* Reference: [RFC-XXXX]
10.2. OAuth Parameters Registry
IANA is asked to add the following entries to the "OAuth Parameters"
registry.
* Name: "edhoc_info"
* Parameter Usage Location: token request, token response
* Change Controller: IESG
* Reference: [RFC-XXXX]
Selander, et al. Expires 5 September 2024 [Page 36]
Internet-Draft EDHOC and OSCORE profile of ACE March 2024
10.3. OAuth Parameters CBOR Mappings Registry
IANA is asked to add the following entries to the "OAuth Parameters
CBOR Mappings" following the procedure specified in [RFC9200].
* Name: "edhoc_info"
* CBOR Key: TBD
* Value Type: map
* Reference: [RFC-XXXX]
10.4. JSON Web Token Claims Registry
IANA is asked to add the following entries to the "JSON Web Token
Claims" registry following the procedure specified in [RFC7519].
* Claim Name: "edhoc_info"
* Claim Description: Information for EDHOC session
* Change Controller: IETF
* Reference: [RFC-XXXX]
10.5. CBOR Web Token Claims Registry
IANA is asked to add the following entries to the "CBOR Web Token
Claims" registry following the procedure specified in [RFC8392].
* Claim Name: "edhoc_info"
* Claim Description: Information for EDHOC session
* JWT Claim Name: "edhoc_info"
* Claim Key: TBD
* Claim Value Type(s): map
* Change Controller: IESG
* Specification Document(s): [RFC-XXXX]
Selander, et al. Expires 5 September 2024 [Page 37]
Internet-Draft EDHOC and OSCORE profile of ACE March 2024
10.6. JWT Confirmation Methods Registry
IANA is asked to add the following entries to the "JWT Confirmation
Methods" registry following the procedure specified in [RFC7800].
* Confirmation Method Value: "x5c"
* Confirmation Method Description: An ordered chain of X.509
certificates
* Change Controller: IESG
* Specification Document(s): Section 7.1 of [RFC-XXXX]
* Confirmation Method Value: "x5b"
* Confirmation Method Description: An unordered bag of X.509
certificates
* Change Controller: IESG
* Specification Document(s): Section 7.2 of [RFC-XXXX]
* Confirmation Method Value: "x5t"
* Confirmation Method Description: Hash of an X.509 certificate
* Change Controller: IESG
* Specification Document(s): Section 7.3 of [RFC-XXXX]
* Confirmation Method Value: "x5u"
* Confirmation Method Description: URI pointing to an ordered chain
of X.509 certificates
* Change Controller: IESG
* Specification Document(s): Section 7.4 of [RFC-XXXX]
* Confirmation Method Value: "c5c"
* Confirmation Method Description: An ordered chain of C509
certificates
Selander, et al. Expires 5 September 2024 [Page 38]
Internet-Draft EDHOC and OSCORE profile of ACE March 2024
* Change Controller: IESG
* Specification Document(s): Section 7.5 of [RFC-XXXX]
* Confirmation Method Value: "c5b"
* Confirmation Method Description: An unordered bag of C509
certificates
* Change Controller: IESG
* Specification Document(s): Section 7.6 of [RFC-XXXX]
* Confirmation Method Value: "c5t"
* Confirmation Method Description: Hash of a C509 certificate
* Change Controller: IESG
* Specification Document(s): Section 7.7 of [RFC-XXXX]
* Confirmation Method Value: "c5u"
* Confirmation Method Description: URI pointing to a COSE_C509
containing an ordered chain of C509 certificates
* Change Controller: IESG
* Specification Document(s): Section 7.8 of [RFC-XXXX]
* Confirmation Method Value: "kcwt"
* Confirmation Method Description: A CBOR Web Token (CWT) containing
a COSE_Key in a 'cnf' claim and possibly other claims
* Change Controller: IESG
* Specification Document(s): Section 7.9 of [RFC-XXXX]
* Confirmation Method Value: "kccs"
* Confirmation Method Description: A CWT Claims Set (CCS) containing
a COSE_Key in a 'cnf' claim and possibly other claims
Selander, et al. Expires 5 September 2024 [Page 39]
Internet-Draft EDHOC and OSCORE profile of ACE March 2024
* Change Controller: IESG
* Specification Document(s): Section 7.10 of [RFC-XXXX]
10.7. CWT Confirmation Methods Registry
IANA is asked to add the following entries to the "CWT Confirmation
Methods" registry following the procedure specified in [RFC8747].
* Confirmation Method Name: x5chain
* Confirmation Method Description: An ordered chain of X.509
certificates
* JWT Confirmation Method Name: "x5c"
* Confirmation Key: TBD
* Confirmation Value Type(s): COSE_X509
* Change Controller: IESG
* Specification Document(s): Section 6.1 of [RFC-XXXX]
* Confirmation Method Name: x5bag
* Confirmation Method Description: An unordered bag of X.509
certificates
* JWT Confirmation Method Name: "x5b"
* Confirmation Key: TBD
* Confirmation Value Type(s): COSE_X509
* Change Controller: IESG
* Specification Document(s): Section 6.2 of [RFC-XXXX]
* Confirmation Method Name: x5t
* Confirmation Method Description: Hash of an X.509 certificate
* JWT Confirmation Method Name: "x5t"
* Confirmation Key: TBD
Selander, et al. Expires 5 September 2024 [Page 40]
Internet-Draft EDHOC and OSCORE profile of ACE March 2024
* Confirmation Value Type(s): COSE_CertHash
* Change Controller: IESG
* Specification Document(s): Section 6.3 of [RFC-XXXX]
* Confirmation Method Name: x5u
* Confirmation Method Description: URI pointing to an ordered chain
of X.509 certificates
* JWT Confirmation Method Name: "x5u"
* Confirmation Key: TBD
* Confirmation Value Type(s): uri
* Change Controller: IESG
* Specification Document(s): Section 6.4 of [RFC-XXXX]
* Confirmation Method Name: c5c
* Confirmation Method Description: An ordered chain of C509
certificates
* JWT Confirmation Method Name: "c5c"
* Confirmation Key: TBD
* Confirmation Value Type(s): COSE_C509
* Change Controller: IESG
* Specification Document(s): Section 6.5 of [RFC-XXXX]
* Confirmation Method Name: c5b
* Confirmation Method Description: An unordered bag of C509
certificates
* JWT Confirmation Method Name: "c5b"
* Confirmation Key: TBD
Selander, et al. Expires 5 September 2024 [Page 41]
Internet-Draft EDHOC and OSCORE profile of ACE March 2024
* Confirmation Value Type(s): COSE_C509
* Change Controller: IESG
* Specification Document(s): Section 6.6 of [RFC-XXXX]
* Confirmation Method Name: c5t
* Confirmation Method Description: Hash of a C509 certificate
* JWT Confirmation Method Name: "c5t"
* Confirmation Key: TBD
* Confirmation Value Type(s): COSE_CertHash
* Change Controller: IESG
* Specification Document(s): Section 6.7 of [RFC-XXXX]
* Confirmation Method Name: c5u
* Confirmation Method Description: URI pointing to a COSE_C509
containing an ordered chain of C509 certificates
* JWT Confirmation Method Name: "c5u"
* Confirmation Key: TBD
* Confirmation Value Type(s): uri
* Change Controller: IESG
* Specification Document(s): Section 6.8 of [RFC-XXXX]
* Confirmation Method Name: kcwt
* Confirmation Method Description: A CBOR Web Token (CWT) containing
a COSE_Key in a 'cnf' claim and possibly other claims
* JWT Confirmation Method Name: "kcwt"
* Confirmation Key: TBD
* Confirmation Value Type(s): COSE_Messages
Selander, et al. Expires 5 September 2024 [Page 42]
Internet-Draft EDHOC and OSCORE profile of ACE March 2024
* Change Controller: IESG
* Specification Document(s): Section 6.9 of [RFC-XXXX]
* Confirmation Method Name: kccs
* Confirmation Method Description: A CWT Claims Set (CCS) containing
a COSE_Key in a 'cnf' claim and possibly other claims
* JWT Confirmation Method Name: "kccs"
* Confirmation Key: TBD
* Confirmation Value Type(s): map / #6(map)
* Change Controller: IESG
* Specification Document(s): Section 6.10 of [RFC-XXXX]
10.8. EDHOC External Authorization Data Registry
IANA is asked to add the following entry to the "EDHOC External
Authorization Data" registry defined in Section 9.5 of
[I-D.ietf-lake-edhoc].
The ead_label = TBD and the ead_value defines an access token in
EAD_3, with processing specified in Section 4.3.
* Label: TBD
* Value Type: bstr
* Description: Access Token
* Reference: [RFC-XXXX]
10.9. EDHOC Information Registry
It is requested that IANA create a new registry entitled "EDHOC
Information" registry. The registry is to be created with
registration policy Expert Review [RFC8126]. Guidelines for the
experts are provided in Section 10.10. It should be noted that in
addition to the expert review, some portions of the registry require
a specification, potentially on Standards Track, be supplied as well.
The columns of the registry are:
Selander, et al. Expires 5 September 2024 [Page 43]
Internet-Draft EDHOC and OSCORE profile of ACE March 2024
* Name: A descriptive name that enables easier reference to this
item. Because a core goal of this document is for the resulting
representations to be compact, it is RECOMMENDED that the name be
short.
This name is case sensitive. Names may not match other registered
names in a case-insensitive manner unless the Designated Experts
determine that there is a compelling reason to allow an exception.
The name is not used in the CBOR encoding.
* CBOR label: The value to be used as CBOR abbreviation of the item.
The value MUST be unique. The value can be a positive integer, a
negative integer or a string. Integer values between -256 and 255
and strings of length 1 are to be registered by Standards Track
documents (Standards Action). Integer values from -65536 to -257
and from 256 to 65535 and strings of maximum length 2 are to be
registered by public specifications (Specification Required).
Integer values greater than 65535 and strings of length greater
than 2 are subject to the Expert Review policy. Integer values
less than -65536 are marked as private use.
* CBOR type: The CBOR type of the item, or a pointer to the registry
that defines its type, when that depends on another item.
* Registry: The registry that values of the item may come from, if
one exists.
* Description: A brief description of this item.
* Specification: A pointer to the public specification for the item,
if one exists.
This registry will be initially populated by the values in Figure 6.
The "Specification" column for all of these entries will be this
document and [I-D.ietf-lake-edhoc].
10.10. Expert Review Instructions
The IANA registry established in this document is defined to use the
registration policy Expert Review. This section gives some general
guidelines for what the experts should be looking for, but they are
being designated as experts for a reason so they should be given
substantial latitude.
Expert reviewers should take into consideration the following points:
Selander, et al. Expires 5 September 2024 [Page 44]
Internet-Draft EDHOC and OSCORE profile of ACE March 2024
* Point squatting should be discouraged. Reviewers are encouraged
to get sufficient information for registration requests to ensure
that the usage is not going to duplicate one that is already
registered and that the point is likely to be used in deployments.
The zones tagged as private use are intended for testing purposes
and closed environments; code points in other ranges should not be
assigned for testing.
* Specifications are required for the Standards Action range of
point assignment. Specifications should exist for Specification
Required ranges, but early assignment before a specification is
available is considered to be permissible. Specifications are
needed for the first-come, first-serve range if they are expected
to be used outside of closed environments in an interoperable way.
When specifications are not provided, the description provided
needs to have sufficient information to identify what the point is
being used for.
* Experts should take into account the expected usage of fields when
approving point assignment. The fact that there is a range for
Standards Track documents does not mean that a Standards Track
document cannot have points assigned outside of that range. The
length of the encoded value should be weighed against how many
code points of that length are left, the size of device it will be
used on, and the number of code points left that encode to that
size.
11. References
11.1. Normative References
[COSE.Header.Parameters]
IANA, "COSE Header Parameters",
<https://www.iana.org/assignments/cose/cose.xhtml#header-
parameters>.
[I-D.ietf-ace-workflow-and-params]
Tiloca, M. and G. Selander, "Alternative Workflow and
OAuth Parameters for the Authentication and Authorization
for Constrained Environments (ACE) Framework", Work in
Progress, Internet-Draft, draft-ietf-ace-workflow-and-
params-00, 2 January 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-ace-
workflow-and-params-00>.
[I-D.ietf-core-oscore-edhoc]
Palombini, F., Tiloca, M., Höglund, R., Hristozov, S., and
G. Selander, "Using Ephemeral Diffie-Hellman Over COSE
Selander, et al. Expires 5 September 2024 [Page 45]
Internet-Draft EDHOC and OSCORE profile of ACE March 2024
(EDHOC) with the Constrained Application Protocol (CoAP)
and Object Security for Constrained RESTful Environments
(OSCORE)", Work in Progress, Internet-Draft, draft-ietf-
core-oscore-edhoc-10, 29 November 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-core-
oscore-edhoc-10>.
[I-D.ietf-cose-cbor-encoded-cert]
Mattsson, J. P., Selander, G., Raza, S., Höglund, J., and
M. Furuhed, "CBOR Encoded X.509 Certificates (C509
Certificates)", Work in Progress, Internet-Draft, draft-
ietf-cose-cbor-encoded-cert-09, 4 March 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-cose-
cbor-encoded-cert-09>.
[I-D.ietf-lake-edhoc]
Selander, G., Mattsson, J. P., and F. Palombini,
"Ephemeral Diffie-Hellman Over COSE (EDHOC)", Work in
Progress, Internet-Draft, draft-ietf-lake-edhoc-23, 22
January 2024, <https://datatracker.ietf.org/doc/html/
draft-ietf-lake-edhoc-23>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/rfc/rfc3986>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<https://www.rfc-editor.org/rfc/rfc4648>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/rfc/rfc5280>.
[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
RFC 6749, DOI 10.17487/RFC6749, October 2012,
<https://www.rfc-editor.org/rfc/rfc6749>.
Selander, et al. Expires 5 September 2024 [Page 46]
Internet-Draft EDHOC and OSCORE profile of ACE March 2024
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Application Protocol (CoAP)", RFC 7252,
DOI 10.17487/RFC7252, June 2014,
<https://www.rfc-editor.org/rfc/rfc7252>.
[RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web
Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
2015, <https://www.rfc-editor.org/rfc/rfc7515>.
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
<https://www.rfc-editor.org/rfc/rfc7519>.
[RFC7800] Jones, M., Bradley, J., and H. Tschofenig, "Proof-of-
Possession Key Semantics for JSON Web Tokens (JWTs)",
RFC 7800, DOI 10.17487/RFC7800, April 2016,
<https://www.rfc-editor.org/rfc/rfc7800>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/rfc/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig,
"CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392,
May 2018, <https://www.rfc-editor.org/rfc/rfc8392>.
[RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data
Definition Language (CDDL): A Notational Convention to
Express Concise Binary Object Representation (CBOR) and
JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,
June 2019, <https://www.rfc-editor.org/rfc/rfc8610>.
[RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
"Object Security for Constrained RESTful Environments
(OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019,
<https://www.rfc-editor.org/rfc/rfc8613>.
[RFC8742] Bormann, C., "Concise Binary Object Representation (CBOR)
Sequences", RFC 8742, DOI 10.17487/RFC8742, February 2020,
<https://www.rfc-editor.org/rfc/rfc8742>.
Selander, et al. Expires 5 September 2024 [Page 47]
Internet-Draft EDHOC and OSCORE profile of ACE March 2024
[RFC8747] Jones, M., Seitz, L., Selander, G., Erdtman, S., and H.
Tschofenig, "Proof-of-Possession Key Semantics for CBOR
Web Tokens (CWTs)", RFC 8747, DOI 10.17487/RFC8747, March
2020, <https://www.rfc-editor.org/rfc/rfc8747>.
[RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", STD 94, RFC 8949,
DOI 10.17487/RFC8949, December 2020,
<https://www.rfc-editor.org/rfc/rfc8949>.
[RFC9053] Schaad, J., "CBOR Object Signing and Encryption (COSE):
Initial Algorithms", RFC 9053, DOI 10.17487/RFC9053,
August 2022, <https://www.rfc-editor.org/rfc/rfc9053>.
[RFC9200] Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and
H. Tschofenig, "Authentication and Authorization for
Constrained Environments Using the OAuth 2.0 Framework
(ACE-OAuth)", RFC 9200, DOI 10.17487/RFC9200, August 2022,
<https://www.rfc-editor.org/rfc/rfc9200>.
[RFC9201] Seitz, L., "Additional OAuth Parameters for Authentication
and Authorization for Constrained Environments (ACE)",
RFC 9201, DOI 10.17487/RFC9201, August 2022,
<https://www.rfc-editor.org/rfc/rfc9201>.
[RFC9203] Palombini, F., Seitz, L., Selander, G., and M. Gunnarsson,
"The Object Security for Constrained RESTful Environments
(OSCORE) Profile of the Authentication and Authorization
for Constrained Environments (ACE) Framework", RFC 9203,
DOI 10.17487/RFC9203, August 2022,
<https://www.rfc-editor.org/rfc/rfc9203>.
[RFC9360] Schaad, J., "CBOR Object Signing and Encryption (COSE):
Header Parameters for Carrying and Referencing X.509
Certificates", RFC 9360, DOI 10.17487/RFC9360, February
2023, <https://www.rfc-editor.org/rfc/rfc9360>.
11.2. Informative References
[I-D.ietf-ace-coap-est-oscore]
Selander, G., Raza, S., Furuhed, M., Vučinić, M., and T.
Claeys, "Protecting EST Payloads with OSCORE", Work in
Progress, Internet-Draft, draft-ietf-ace-coap-est-oscore-
03, 23 October 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-ace-
coap-est-oscore-03>.
Selander, et al. Expires 5 September 2024 [Page 48]
Internet-Draft EDHOC and OSCORE profile of ACE March 2024
[I-D.ietf-core-oscore-key-update]
Höglund, R. and M. Tiloca, "Key Update for OSCORE
(KUDOS)", Work in Progress, Internet-Draft, draft-ietf-
core-oscore-key-update-07, 4 March 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-core-
oscore-key-update-07>.
[I-D.ietf-lake-authz]
Selander, G., Mattsson, J. P., Vučinić, M., and M.
Richardson, "Lightweight Authorization using Ephemeral
Diffie-Hellman Over COSE", Work in Progress, Internet-
Draft, draft-ietf-lake-authz-00, 23 October 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-lake-
authz-00>.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2",
FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007,
<https://www.rfc-editor.org/rfc/rfc4949>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/rfc/rfc8446>.
[RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Semantics", STD 97, RFC 9110,
DOI 10.17487/RFC9110, June 2022,
<https://www.rfc-editor.org/rfc/rfc9110>.
[RFC9147] Rescorla, E., Tschofenig, H., and N. Modadugu, "The
Datagram Transport Layer Security (DTLS) Protocol Version
1.3", RFC 9147, DOI 10.17487/RFC9147, April 2022,
<https://www.rfc-editor.org/rfc/rfc9147>.
Appendix A. Examples
This appendix provides examples where this profile of ACE is used.
In particular:
* Appendix A.1 does not make use of use of any optimization.
* Appendix A.2 makes use of the optimizations defined in this
specification, hence reducing the roundtrips of the interactions
between the Client and the Resource Server.
* Appendix A.3 considers an alternative workflow where AS uploads
the access token to RS.
Selander, et al. Expires 5 September 2024 [Page 49]
Internet-Draft EDHOC and OSCORE profile of ACE March 2024
All these examples build on the following assumptions, as relying on
expected early procedures performed at AS. These include the
registration of RSs by the respective Resource Owners as well as the
registrations of Clients authorized to request access token for those
RSs.
* AS knows the authentication credential AUTH_CRED_C of the Client
C.
* The Client knows the authentication credential AUTH_CRED_AS of AS.
* AS knows the authentication credential AUTH_CRED_RS of RS.
* RS knows the authentication credential AUTH_CRED_AS of AS.
This is relevant in case AS and RS actually require a secure
association (e.g., for RS to perform token introspection at AS, or
for AS to upload an access token to RS on behalf of the Client).
As a result of the assumptions above, it is possible to limit the
transport of AUTH_CRED_C and AUTH_CRED_RS by value only to the
following two cases, and only when the Client requests an access
token for RS in question for the first time when considering the pair
(AUTH_CRED_C, AUTH_CRED_RS).
* In the Token Response from AS to the Client, where AUTH_CRED_RS is
specified by the 'rs_cnf' parameter.
* In the access token, where AUTH_CRED_C is specified by the 'cnf'
claim.
Note that, even under the circumstances mentioned above, AUTH_CRED_C
might rather be indicated by reference. This is possible if RS can
effectively use such a reference from the access token to retrieve
AUTH_CRED_C (e.g., from a trusted repository of authentication
credentials reachable through a non-constrained link), and if AS is
in turn aware of that.
In any other case, it is otherwise possible to indicate both
AUTH_CRED_C and AUTH_CRED_RS by reference, when performing the ACE
access control workflow as well as later on when the Client and RS
run EDHOC.
Selander, et al. Expires 5 September 2024 [Page 50]
Internet-Draft EDHOC and OSCORE profile of ACE March 2024
A.1. Workflow without Optimizations
The example below considers the simplest (though least efficient)
interaction between the Client and RS. That is: first C uploads the
access token to RS; then C and RS run EDHOC; and, finally, the Client
accesses the protected resource at RS.
C AS RS
| | |
| EDHOC message_1 to /edhoc | |
M01 |--------------------------------->| |
| | |
| | |
| EDHOC message_2 | |
M02 |<---------------------------------| |
| ID_CRED_R identifies | |
| CRED_R = AUTH_CRED_AS | |
| by reference | |
| | |
| | |
| EDHOC message_3 to /edhoc | |
M03 |--------------------------------->| |
| ID_CRED_I identifies | |
| CRED_I = AUTH_CRED_C | |
| by reference | |
| | |
| | |
| Token request to /token | |
| (OSCORE-protected message) | |
M04 |--------------------------------->| |
| 'req_cnf' identifies | |
| AUTH_CRED_C by reference | |
| | |
| | |
| Token response | |
| (OSCORE-protected message) | |
M05 |<---------------------------------| |
| 'rs_cnf' specifies | |
| AUTH_CRED_RS by value | |
| | |
| 'ace_profile' = | |
| coap_edhoc_oscore | |
| | |
| 'edhoc_info' specifies: | |
| { | |
| session_id : h'01', | |
| cipher_suites : 2, | |
| methods : 3 | |
Selander, et al. Expires 5 September 2024 [Page 51]
Internet-Draft EDHOC and OSCORE profile of ACE March 2024
| } | |
| | |
| In the access token: | |
| * the 'cnf' claim specifies | |
| AUTH_CRED_C by value | |
| * the 'edhoc_info' claim | |
| specifies the same as | |
| 'edhoc_info' above | |
| | |
Possibly after chain verification, the Client adds AUTH_CRED_RS
to the set of its trusted peer authentication credentials,
relying on AS as trusted provider/
| | |
| Token upload to /authz-info | |
| (unprotected message) | |
M06 |---------------------------------------------------------------->|
| | |
Possibly after chain verification, RS adds AUTH_CRED_C
to the set of its trusted peer authentication credentials,
relying on AS as trusted provider/
| | |
| 2.01 (Created) | |
| (unprotected message) | |
M07 |<----------------------------------------------------------------|
| | |
| | |
| EDHOC message_1 to /edhoc | |
| (no access control is enforced) | |
M08 |---------------------------------------------------------------->|
| | |
| | |
| EDHOC message_2 | |
M09 |<----------------------------------------------------------------|
| ID_CRED_R identifies | |
| CRED_R = AUTH_CRED_RS | |
| by reference | |
| | |
| | |
| EDHOC message_3 to /edhoc | |
| (no access control is enforced) | |
M10 |---------------------------------------------------------------->|
| ID_CRED_I identifies | |
| CRED_I = AUTH_CRED_C | |
| by reference | |
Selander, et al. Expires 5 September 2024 [Page 52]
Internet-Draft EDHOC and OSCORE profile of ACE March 2024
| | |
| | |
| Access to protected resource | |
| (OSCORE-protected message) | |
| (access control is enforced) | |
M11 |---------------------------------------------------------------->|
| | |
| Response | |
| (OSCORE-protected message) | |
M12 |<----------------------------------------------------------------|
| | |
Later on, the access token expires ...
- The Client and RS delete their OSCORE Security Context and
purge the EDHOC session used to derive it (unless the same
session is also used for other reasons).
- RS retains AUTH_CRED_C as still valid,
and AS knows about it.
- The Client retains AUTH_CRED_RS as still valid,
and AS knows about it.
| | |
| | |
Time passes ...
| | |
| | |
The Client asks for a new access token; now all the
authentication credentials can be indicated by reference
The price to pay is on AS, about remembering that at least
one access token has been issued for the pair (Client, RS)
and considering the pair (AUTH_CRED_C, AUTH_CRED_RS)
| | |
| Token request to /token | |
| (OSCORE-protected message) | |
M13 |--------------------------------->| |
| 'req_cnf' identifies | |
| CRED_I = AUTH_CRED_C | |
| by reference | |
| | |
| | |
| Token response | |
| (OSCORE-protected message) | |
M14 |<---------------------------------| |
Selander, et al. Expires 5 September 2024 [Page 53]
Internet-Draft EDHOC and OSCORE profile of ACE March 2024
| 'rs_cnf' identifies | |
| AUTH_CRED_RS by reference | |
| | |
| 'ace_profile' = | |
| coap_edhoc_oscore | |
| | |
| 'edhoc_info' specifies: | |
| { | |
| session_id : h'05', | |
| cipher_suites : 2, | |
| methods : 3 | |
| } | |
| | |
| In the access token: | |
| * the 'cnf' claim specifies | |
| AUTH_CRED_C by reference | |
| * the 'edhoc_info' claim | |
| specifies the same as | |
| 'edhoc_info' above | |
| | |
| | |
| Token upload to /authz-info | |
| (unprotected message) | |
M15 |---------------------------------------------------------------->|
| | |
| | |
| 2.01 (Created) | |
| (unprotected message) | |
M16 |<----------------------------------------------------------------|
| | |
| | |
| EDHOC message_1 to /edhoc | |
| (no access control is enforced) | |
M17 |---------------------------------------------------------------->|
| | |
| | |
| EDHOC message_2 | |
| (no access control is enforced) | |
M18 |<----------------------------------------------------------------|
| ID_CRED_R specifies | |
| CRED_R = AUTH_CRED_RS | |
| by reference | |
| | |
| | |
| EDHOC message_3 to /edhoc | |
| (no access control is enforced) | |
M19 |---------------------------------------------------------------->|
| ID_CRED_I identifies | |
Selander, et al. Expires 5 September 2024 [Page 54]
Internet-Draft EDHOC and OSCORE profile of ACE March 2024
| CRED_I = AUTH_CRED_C | |
| by reference | |
| | |
| | |
| Access to protected resource /r | |
| (OSCORE-protected message) | |
| (access control is enforced) | |
M20 |---------------------------------------------------------------->|
| | |
| | |
| Response | |
| (OSCORE-protected message) | |
M21 |<----------------------------------------------------------------|
| | |
A.2. Workflow with Optimizations
The example below builds on the example in Appendix A.1, while
additionally relying on the two following optimizations.
* The access token is not separately uploaded to the /authz-info
endpoint at RS, but rather included in the EAD_3 field of EDHOC
message_3 sent by C to RS.
* The Client uses the EDHOC+OSCORE request defined in
[I-D.ietf-core-oscore-edhoc] is used, when running EDHOC both with
AS and with RS.
These two optimizations used together result in the most efficient
interaction between C and RS, as consisting of only two roundtrips to
upload the access token, run EDHOC and access the protected resource
at RS.
C AS RS
| | |
| EDHOC message_1 to /edhoc | |
M01 |--------------------------------->| |
| | |
| | |
| EDHOC message_2 | |
M02 |<---------------------------------| |
| ID_CRED_R identifies | |
| CRED_R = AUTH_CRED_AS | |
| by reference | |
| | |
| | |
| EDHOC+OSCORE request to /token | |
M03 |--------------------------------->| |
Selander, et al. Expires 5 September 2024 [Page 55]
Internet-Draft EDHOC and OSCORE profile of ACE March 2024
| * EDHOC message_3 | |
| ID_CRED_I identifies | |
| CRED_I = AUTH_CRED_C | |
| by reference | |
| --- --- --- | |
| * OSCORE-protected part | |
| Token request | |
| 'req_cnf' identifies | |
| AUTH_CRED_C by reference | |
| | |
| | |
| Token response | |
| (OSCORE-protected message) | |
M04 |<---------------------------------| |
| 'rs_cnf' specifies | |
| AUTH_CRED_RS by value | |
| | |
| 'ace_profile' = | |
| coap_edhoc_oscore | |
| | |
| 'edhoc_info' specifies: | |
| { | |
| session_id : h'01', | |
| cipher_suites : 2, | |
| methods : 3 | |
| } | |
| | |
| In the access token: | |
| * the 'cnf' claim specifies | |
| AUTH_CRED_C by value | |
| * the 'edhoc_info' claim | |
| specifies the same as | |
| 'edhoc_info' above | |
| | |
Possibly after chain verification, the Client adds AUTH_CRED_RS
to the set of its trusted peer authentication credentials,
relying on AS as trusted provider
| | |
| EDHOC message_1 to /edhoc | |
| (no access control is enforced) | |
M05 |---------------------------------------------------------------->|
| | |
Possibly after chain verification, RS adds AUTH_CRED_C
to the set of its trusted peer authentication credentials,
relying on AS as trusted provider
Selander, et al. Expires 5 September 2024 [Page 56]
Internet-Draft EDHOC and OSCORE profile of ACE March 2024
| | |
| EDHOC message_2 | |
M06 |<----------------------------------------------------------------|
| ID_CRED_R identifies | |
| CRED_R = AUTH_CRED_RS | |
| by reference | |
| | |
| | |
| EDHOC+OSCORE request to /r | |
M07 |---------------------------------------------------------------->|
| * EDHOC message_3 | |
| EAD_3 contains access token | |
| ID_CRED_I identifies | |
| CRED_I = AUTH_CRED_C | |
| by reference | |
| --- --- --- | |
| * OSCORE-protected part | |
| Application request to /r | |
| | |
After the EDHOC processing is completed, access control
is enforced on the rebuilt OSCORE-protected request,
like if it had been sent stand-alone
| | |
| Response | |
| (OSCORE-protected message) | |
M08 |<----------------------------------------------------------------|
| | |
A.3. Alternative Workflow (AS token posting)
The example below builds on the example in Appendix A.2, but assumes
that AS is uploading the access token to RS as specified in
[I-D.ietf-ace-workflow-and-params].
C AS RS
| | |
| | |
| | |
| EDHOC message_1 to /edhoc | |
M01 |--------------------------------->| |
| | |
| | |
| EDHOC message_2 | |
M02 |<---------------------------------| |
| ID_CRED_R identifies | |
| CRED_R = AUTH_CRED_AS | |
Selander, et al. Expires 5 September 2024 [Page 57]
Internet-Draft EDHOC and OSCORE profile of ACE March 2024
| by reference | |
| | |
| | |
| EDHOC+OSCORE request to /token | |
M03 |--------------------------------->| |
| * EDHOC message_3 | |
| ID_CRED_I identifies | |
| CRED_I = AUTH_CRED_C | |
| by reference | |
| --- --- --- | |
| * OSCORE-protected part | |
| Token request | |
| 'req_cnf' identifies | |
| AUTH_CRED_C by reference | |
| | |
| | |
| | Token upload to /authz-info |
M04 | |----------------------------->|
| | In the access token: |
| | * the 'cnf' claim |
| | specifies AUTH_CRED_C |
| | by value |
| | * the 'edhoc_info' |
| | claim specifies |
| | { |
| | session_id : h'01', |
| | cipher_suites : 2, |
| | methods: 3 |
| | } |
| | |
Possibly after chain verification, RS adds AUTH_CRED_C
to the set of its trusted peer authentication credentials,
relying on AS as trusted provider
| | |
| | 2.01 (Created) |
M05 | |<-----------------------------|
| | |
| | |
| Token response | |
| (OSCORE-protected message) | |
M06 |<---------------------------------| |
| 'rs_cnf' specifies | |
| AUTH_CRED_RS by value | |
| | |
| 'ace_profile' = | |
| coap_edhoc_oscore | |
Selander, et al. Expires 5 September 2024 [Page 58]
Internet-Draft EDHOC and OSCORE profile of ACE March 2024
| | |
| 'token_uploaded' = true | |
| | |
| 'edhoc_info' specifies: | |
| { | |
| session_id : h'01', | |
| cipher_suites : 2, | |
| methods : 3 | |
| } | |
| | |
Possibly after chain verification, the Client adds AUTH_CRED_RS
to the set of its trusted peer authentication credentials,
relying on AS as trusted provider
| | |
| EDHOC message_1 to /edhoc | |
| (no access control is enforced) | |
M07 |---------------------------------------------------------------->|
| | |
| | |
| EDHOC message_2 | |
M08 |<----------------------------------------------------------------|
| ID_CRED_R identifies | |
| CRED_R = AUTH_CRED_RS | |
| by reference | |
| | |
| | |
| EDHOC+OSCORE request to /r | |
M09 |---------------------------------------------------------------->|
| * EDHOC message_3 | |
| ID_CRED_I identifies | |
| CRED_I = AUTH_CRED_C | |
| by reference | |
| --- --- --- | |
| * OSCORE-protected part | |
| Application request to /r | |
| | |
After the EDHOC processing is completed, access control
is enforced on the rebuilt OSCORE-protected request,
like if it had been sent stand-alone
| | |
| Response | |
| (OSCORE-protected message) | |
M10 |<----------------------------------------------------------------|
| | |
Selander, et al. Expires 5 September 2024 [Page 59]
Internet-Draft EDHOC and OSCORE profile of ACE March 2024
Appendix B. Profile Requirements
This section lists the specifications of this profile based on the
requirements of the framework, as requested in Appendix C of
[RFC9200].
* Optionally, define new methods for the client to discover the
necessary permissions and AS for accessing a resource, different
from the one proposed in [RFC9200]: Not specified
* Optionally, specify new grant types: Not specified
* Optionally, define the use of client certificates as client
credential type: C can use authentication credentials of any type
admitted by the EDHOC protocol, including public key certificates
such as X.509 and C509 certificates.
* Specify the communication protocol the client and RS must use:
CoAP
* Specify the security protocol the client and RS must use to
protect their communication: OSCORE
* Specify how the client and RS mutually authenticate: Explicitly,
by successfully executing the EDHOC protocol, after which a common
OSCORE Security Context is exported from the EDHOC session. As
per the EDHOC authentication method used during the EDHOC session,
authentication is provided by digital signatures, or by Message
Authentication Codes (MACs) computed from an ephemeral-static ECDH
shared secret.
* Specify the proof-of-possession protocol(s) and how to select one,
if several are available. Also specify which key types (e.g.,
symmetric/asymmetric) are supported by a specific proof-of-
possession protocol: proof-of-possession is first achieved by RS
when successfully processing EDHOC message_3 during the EDHOC
session with C, through EDHOC algorithms and symmetric EDHOC
session keys. Also, proof-of-possession is later achieved by C
when receiving from RS: i) the optional EDHOC message_4 during the
EDHOC session with RS, through EDHOC algorithms and symmetric
EDHOC session keys; or ii) the first response protected with the
OSCORE Security Context established after the EDHOC session with
RS, through OSCORE algorithms and OSCORE symmetric keys derived
from the completed EDHOC session.
* Specify a unique ace_profile identifier: coap_edhoc_oscore
Selander, et al. Expires 5 September 2024 [Page 60]
Internet-Draft EDHOC and OSCORE profile of ACE March 2024
* If introspection is supported, specify the communication and
security protocol for introspection: HTTP/CoAP (+ TLS/DTLS/OSCORE)
* Specify the communication and security protocol for interactions
between client and AS: HTTP/CoAP (+ TLS/DTLS/OSCORE)
* Specify if/how the authz-info endpoint is protected, including how
error responses are protected: Not protected
* Optionally, define methods of token transport other than the
authz-info endpoint: C can upload the access token when executing
EDHOC with RS, by including the access token in the EAD_3 field of
EDHOC message_3 (see Section 4.4).
Appendix C. Document Updates
RFC EDITOR: PLEASE REMOVE THIS SECTION.
C.1. Version -03 to -04
* Removed the case of transporting access token in EAD_1
* Removed redundant normative text
* Clarifications of association between access token, session_id,
EDHOC session and OSCORE security context
C.2. Version -02 to -03
* Fixed column name and prefilling of the "EDHOC Information"
registry.
* Added EDHOC_Information Parameters originally in draft-tiloca-
lake-app-profiles-00.
* Updated references.
* Editorial fixes and improvements.
C.3. Version -02 to -03
* Restructured presentation of content.
* Simplified description of the use of EDHOC_Information.
* Merged the concepts of EDHOC "session_id" and identifier of token
series.
Selander, et al. Expires 5 September 2024 [Page 61]
Internet-Draft EDHOC and OSCORE profile of ACE March 2024
* Enabled the transport of the access token also in EDHOC EAD_3.
* Defined semantics of the newly defined CWT/JWT Confirmation
Methods.
* Clarifications and editorial improvements.
C.4. Version -01 to -02
* Removed use of EDHOC_KeyUpdate.
* The Security Context is updated either by KUDOS or a rerun of
EDHOC.
* The alternative workflow (AS token posting) is specified in
separate draft.
* Fixed and updated examples.
* Editorial improvements.
C.5. Version -00 to -01
* Fixed semantics of the ead_value for transporting an Access Token
in the EAD_1 field.
* Error handling aligned with EDHOC.
* Precise characterization of the EDHOC execution considered for
EDHOC-KeyUpdate.
* Fixed message exchange examples.
* Added appendix with profile requirements.
* Updated references.
* Clarifications and editorial improvements.
Acknowledgments
The authors sincerely thank Christian Amsüss and Carsten Bormann for
their comments and feedback.
Work on this document has in part been supported by the H2020 project
SIFIS-Home (grant agreement 952652).
Selander, et al. Expires 5 September 2024 [Page 62]
Internet-Draft EDHOC and OSCORE profile of ACE March 2024
Authors' Addresses
Göran Selander
Ericsson
Email: goran.selander@ericsson.com
John Preuß Mattsson
Ericsson
Email: john.mattsson@ericsson.com
Marco Tiloca
RISE
Email: marco.tiloca@ri.se
Rikard Höglund
RISE
Email: rikard.hoglund@ri.se
Selander, et al. Expires 5 September 2024 [Page 63]
