Implementation Considerations for Ephemeral Diffie-Hellman Over COSE (EDHOC)
draft-tiloca-lake-edhoc-implem-cons-01
| Document | Type | Active Internet-Draft (lake WG) | |
|---|---|---|---|
| Author | Marco Tiloca | ||
| Last updated | 2024-02-13 (Latest revision 2024-02-12) | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | Candidate for WG Adoption | |
| Document shepherd | (None) | ||
| IESG | IESG state | I-D Exists | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-tiloca-lake-edhoc-implem-cons-01
LAKE Working Group M. Tiloca
Internet-Draft RISE AB
Intended status: Informational 12 February 2024
Expires: 15 August 2024
Implementation Considerations for Ephemeral Diffie-Hellman Over COSE
(EDHOC)
draft-tiloca-lake-edhoc-implem-cons-01
Abstract
This document provides considerations for guiding the implementation
of the authenticated key exchange protocol Ephemeral Diffie-Hellman
Over COSE (EDHOC).
Discussion Venues
This note is to be removed before publishing as an RFC.
Discussion of this document takes place on the Lightweight
Authenticated Key Exchange Working Group mailing list
(lake@ietf.org), which is archived at
https://mailarchive.ietf.org/arch/browse/lake/.
Source for this draft and an issue tracker can be found at
https://gitlab.com/crimson84/draft-tiloca-lake-edhoc-implem-cons.
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 15 August 2024.
Tiloca Expires 15 August 2024 [Page 1]
Internet-Draft Implementation Considerations for EDHOC February 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 . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Handling of Invalid EDHOC Sessions and Application Keys . . . 3
2.1. EDHOC Sessions Become Invalid . . . . . . . . . . . . . . 4
2.2. Application Keys Become Invalid . . . . . . . . . . . . . 5
2.3. Application Keys or Bound Access Rights Become Invalid . 7
3. Trust Models for Learning New Authentication Credentials . . 11
4. Side Processing of Incoming EDHOC Messages . . . . . . . . . 13
4.1. EDHOC message_1 . . . . . . . . . . . . . . . . . . . . . 15
4.2. EDHOC message_4 . . . . . . . . . . . . . . . . . . . . . 16
4.3. EDHOC message_2 and message_3 . . . . . . . . . . . . . . 16
4.3.1. Pre-Verification Side Processing . . . . . . . . . . 16
4.3.2. Post-Verification Side Processing . . . . . . . . . . 19
4.3.3. Flowcharts . . . . . . . . . . . . . . . . . . . . . 19
5. Security Considerations . . . . . . . . . . . . . . . . . . . 23
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
7.1. Normative References . . . . . . . . . . . . . . . . . . 23
7.2. Informative References . . . . . . . . . . . . . . . . . 24
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 25
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction
Ephemeral Diffie-Hellman Over COSE (EDHOC) [I-D.ietf-lake-edhoc] is a
lightweight authenticated key exchange protocol, especially intended
for use in constrained scenarios.
During the development of EDHOC, a number of side topics were raised
and discussed, as emerging from reviews of the protocol latest design
and from implementation activities. These topics were identified as
strongly pertaining to the implementation of EDHOC rather than to the
Tiloca Expires 15 August 2024 [Page 2]
Internet-Draft Implementation Considerations for EDHOC February 2024
protocol in itself. Hence, they are not discussed in
[I-D.ietf-lake-edhoc], which rightly focuses on specifying the actual
protocol.
At the same time, implementors of an application using the EDHOC
protocol or of an "EDHOC library" enabling its use cannot simply
ignore such topics, and will have to take them into account
throughout their implementation work.
In order to prevent multiple, independent re-discoveries and
assessments of those topics, as well as to facilitate and guide
implementation activities, this document collects such topics and
discusses them through considerations about the implementation of
EDHOC. At a high-level, the topics in question are summarized below.
* Handling of completed EDHOC sessions when they become invalid, and
of application keys derived from an EDHOC session when those
become invalid. This topic is discussed in Section 2.
* Enforcing of different trust models, with respect to learning new
authentication credentials during an execution of EDHOC. This
topic is discussed in Section 3.
* Branched-off, side processing of incoming EDHOC messages, with
particular reference to: i) fetching and validation of
authentication credentials; and ii) processing of External
Authorization Data (EAD) items, which in turn might play a role in
the fetching and validation of authentication credentials. This
topic is discussed in Section 4.
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.
The reader is expected to be familiar with terms and concepts related
to the EDHOC protocol and defined in [I-D.ietf-lake-edhoc].
2. Handling of Invalid EDHOC Sessions and Application Keys
This section considers the most common situation where, given a
certain peer, only the application at that peer has visibility and
control of both:
* The EDHOC sessions at that peer; and
Tiloca Expires 15 August 2024 [Page 3]
Internet-Draft Implementation Considerations for EDHOC February 2024
* The application keys for that application at that peer, including
the knowledge of whether they have been derived from an EDHOC
session, i.e., by means of the EDHOC_Exporter interface after the
successful completion of an execution of EDHOC (see Section 4.1 of
[I-D.ietf-lake-edhoc]).
Building on the above, the following expands on three relevant cases
concerning the handling of EDHOC sessions and application keys, in
the event that any of those becomes invalid.
As a case in point to provide more concrete guidance, the following
also considers the specific case where "applications keys" stands for
the keying material and parameters that compose an OSCORE Security
Context [RFC8613] and that are derived from an EDHOC session (see
Appendix A.1 of [I-D.ietf-lake-edhoc]).
Nevertheless, the same considerations are applicable in case EDHOC is
used to derive other application keys, e.g., to key different
security protocols than OSCORE or to provide the application with
secure values bound to an EDHOC session.
2.1. EDHOC Sessions Become Invalid
The application at a peer P may have learned that a completed EDHOC
session S has to be invalidated. When S is marked as invalid, the
application at P purges S and deletes each set of application keys
(e.g., the OSCORE Security Context) that was generated from S.
Then, the applications runs a new execution of the EDHOC protocol
with the other peer. Upon successfully completing the EDHOC
execution, the two peers derive and install a new set of application
keys from this latest EDHOC session.
The flowchart in Figure 1 shows the handling of an EDHOC session that
has become invalid.
Invalid Delete the EDHOC session Rerun Derive and
EDHOC --> and the application keys --> EDHOC --> install new
session derived from it application keys
Figure 1: Handling of an EDHOC Session that has Become Invalid
Tiloca Expires 15 August 2024 [Page 4]
Internet-Draft Implementation Considerations for EDHOC February 2024
An EDHOC session may have become invalid, for example, because an
authentication credential CRED_X may have expired, or because P may
have learned from a trusted source that CRED_X has been revoked.
This effectively invalidates CRED_X, and therefore also invalidates
any EDHOC session where CRED_X was used as authentication credential
of either peer in the session (i.e., P itself or the other peer). In
such a case, the application at P has to additionally delete CRED_X
and any stored, corresponding credential identifier.
2.2. Application Keys Become Invalid
The application at a peer P may have learned that a set of
application keys is not safe to use anymore. When such a set is
specifically an OSCORE Security Context, the application may have
learned that from the used OSCORE library or from an OSCORE layer
that takes part to the communication stack.
A current set SET of application keys shared with another peer can
become unsafe to use, for example, due to the following reasons.
* SET has reached its pre-determined expiration time; or
* SET has been established for a pre-defined, now elapsed amount of
time, according to enforced application policies; or
* Some elements of SET have been used enough times to approach
cryptographic limits that should not be passed, e.g., according to
the properties of the specifically used security algorithms. With
particular reference to an OSCORE Security Context, such limits
are discussed in [I-D.ietf-core-oscore-key-limits].
When this happens, the application at the peer P proceeds as follows.
1. If the following conditions both hold, then the application moves
to step 2. Otherwise, it moves to step 3.
* Let us define S as the EDHOC session from which the peer P has
derived SET or the eldest SET's ancestor set of application
keys. Then, since the completion of S with the other peer,
the application at P has received from the other peer at least
one message protected with any set of application keys derived
from S. That is, P has persisted S (see Section 5.4.2 of
[I-D.ietf-lake-edhoc]).
Tiloca Expires 15 August 2024 [Page 5]
Internet-Draft Implementation Considerations for EDHOC February 2024
* The peer P supports a key update protocol, as an alternative
to performing a new execution of EDHOC with the other peer.
When SET is specifically an OSCORE Security Context, this
means that the peer P supports the key update protocol KUDOS
defined in [I-D.ietf-core-oscore-key-update].
2. The application at P runs the key update protocol mentioned at
step 1 with the other peer, in order to update SET. When SET is
specifically an OSCORE Security Context, this means that the
application at P runs KUDOS with the other peer.
If the key update protocol terminates successfully, the updated
application keys are installed and no further actions are taken.
Otherwise, the application at P moves to step 3.
3. The application at the peer P performs the following actions.
* It deletes SET.
* It deletes the EDHOC session from which SET was generated, or
from which the eldest SET's ancestor set of application keys
was generated before any key update occurred (e.g., by means
of the EDHOC_KeyUpdate interface defined in Appendix H of
[I-D.ietf-lake-edhoc] or other key update methods).
* It runs a new execution of the EDHOC protocol with the other
peer. Upon successfully completing the EDHOC execution, the
two peers derive and install a new set of application keys
from this latest EDHOC session.
The flowchart in Figure 2 shows the handling of a set of application
keys that has become invalid.
Tiloca Expires 15 August 2024 [Page 6]
Internet-Draft Implementation Considerations for EDHOC February 2024
Invalid application keys
|
|
v
NO
Are the ----> Delete the application ----> Rerun
application keys keys and the EDHOC session EDHOC
persisted?
^ ^ |
| | | |
| YES | | v
v | |
| | Derive and install
Is KUDOS NO | | new application keys
supported? ------------------+ |
|
| |
| YES |
v |
|
Run KUDOS |
|
| |
| |
v |
|
Has KUDOS NO |
succeeded? ---------------------------+
|
| YES
v
Install the updated
application keys
Figure 2: Handling of a set of Application Keys that has Become
Invalid
2.3. Application Keys or Bound Access Rights Become Invalid
The following considers two peers that use the ACE framework for
authentication and authorization in constrained environments (ACE)
[RFC9200], and specifically the EDHOC and OSCORE profile of ACE
defined in [I-D.ietf-ace-edhoc-oscore-profile].
Tiloca Expires 15 August 2024 [Page 7]
Internet-Draft Implementation Considerations for EDHOC February 2024
When doing so, one of the two peers acts as ACE Resource Server (RS)
hosting protected resources. The other peer acts as ACE Client,
requests from an ACE Authorization Server (AS) an Access Token that
specifies access rights for accessing protected resources at the RS,
and uploads the Access Token to the RS as part of the ACE workflow.
Consistent with the used EDHOC and OSCORE profile of ACE, the two
peers run EDHOC in order to specifically derive an OSCORE Security
Context as their shared set of application keys (see Appendix A.1 of
[I-D.ietf-lake-edhoc]). In particular, the peer acting as ACE Client
acts as EDHOC Initiator, while the peer acting as ACE RS acts as
EDHOC Responder (see Section 2 of [I-D.ietf-lake-edhoc]). The
successfully completed EDHOC session is bound to the Access Token.
After that, the peer acting as ACE Client can access the protected
resources hosted at the other peer, according to the access rights
specified in the Access Token. The communications between the two
peers are protected by means of the established OSCORE Security
Context, which is also bound to the used Access Token.
Later on, the application at one of the two peers P may have learned
that the established OSCORE Security Context CTX is not safe to use
anymore, e.g., from the used OSCORE library or from an OSCORE layer
that takes part to the communication stack. The reasons that make
CTX not safe to use anymore are the same ones discussed in
Section 2.2 when considering a set of application keys in general,
plus the event where the Access Token bound to CTX becomes invalid
(e.g., it has expired or it has been revoked).
When this happens, the application at the peer P proceeds as follows.
1. If the following conditions both hold, then the application moves
to step 2. Otherwise, it moves to step 3.
* The Access Token is still valid. That is, it has not expired
yet and the peer P is not aware that it has been revoked.
* Let us define S as the EDHOC session from which the peer P has
derived CTX or the eldest CTX's ancestor OSCORE Security
Context. Then, since the completion of S with the other peer,
the application at P has received from the other peer at least
one message protected with any set of application keys derived
from S. That is, P has persisted S (see Section 5.4.2 of
[I-D.ietf-lake-edhoc]).
Tiloca Expires 15 August 2024 [Page 8]
Internet-Draft Implementation Considerations for EDHOC February 2024
2. If the peer P supports the key update protocol KUDOS
[I-D.ietf-core-oscore-key-update], then P runs KUDOS with the
other peer, in order to update CTX. If the execution of KUDOS
terminates successfully, the updated OSCORE Security Context is
installed and no further actions are taken.
If the execution of KUDOS does not terminate successfully or if
the peer P does not support KUDOS altogether, then the
application at P moves to step 3.
3. The application at the peer P performs the following actions.
* If the Access Token is not valid anymore, the peer P deletes
all the EDHOC sessions associated with the Access Token, as
well as the OSCORE Security Context derived from each of those
sessions.
If the peer P acted as ACE Client, then P obtains a new Access
Token from the ACE AS, and uploads it to the other peer acting
as ACE RS.
Finally, the application at P moves to step 4.
* If the Access Token is valid while the OSCORE Security Context
CTX is not, then the peer P deletes CTX.
After that, the peer P deletes the EDHOC session from which
CTX was generated, or from which the eldest CTX's ancestor
OSCORE Security Context was generated before any key update
occurred (e.g., by means of KUDOS or other key update
methods).
Finally, the application at P moves to step 4.
4. The peer P runs a new execution of the EDHOC protocol with the
other peer. Upon successfully completing the EDHOC execution,
the two peers derive and install a new OSCORE Security Context
from this latest EDHOC session.
The flowchart in Figure 3 shows the handling of an Access Token or of
a set of application keys that have become invalid.
Invalid token specifying CRED_I,
or invalid application keys
|
|
v
Tiloca Expires 15 August 2024 [Page 9]
Internet-Draft Implementation Considerations for EDHOC February 2024
NO
Is the token ----> Delete the associated --> Obtain and --> Rerun ---+
still valid? EDHOC sessions and upload a EDHOC |
the application keys new token |
| derived from those ^ |
| | |
| YES | |
v | |
| |
The application keys | |
are not valid anymore | |
| |
| | |
| | |
v | |
| |
Are the NO | |
application keys -----> Delete the application keys and ------+ |
persisted? the associated EDHOC session |
|
| ^ ^ |
| YES | | |
v | | |
| | |
Is KUDOS NO | | |
supported? ---------------------+ | v
|
| | Derive and install
| YES | new application keys
v |
|
Run KUDOS |
|
| |
| |
v |
|
Has KUDOS NO |
succeeded? ------------------------------+
|
| YES
v
Install the updated
application keys
Tiloca Expires 15 August 2024 [Page 10]
Internet-Draft Implementation Considerations for EDHOC February 2024
Figure 3: Handling of an Access Token or of a set of Application
Keys that have Become Invalid
3. Trust Models for Learning New Authentication Credentials
A peer P relies on authentication credentials of other peers, in
order to authenticate those peers when running EDHOC with them.
There are different ways for P to acquire an authentication
credential CRED of another peer. For example, CRED can be supplied
to P out-of-band by a trusted provider.
Alternatively, CRED can be specified by the other peer during the
EDHOC execution with P. This relies on EDHOC message_2 or message_3,
whose respective ID_CRED_R and ID_CRED_I can specify CRED by value,
or instead a URI or other external reference where CRED can be
retrieved from (see Section 3.5.3 of [I-D.ietf-lake-edhoc]).
Also during the EDHOC execution, an External Authorization Data (EAD)
field might include an EAD item that specifies CRED by value or
reference. This is the case, e.g., for the EAD item defined in
[I-D.ietf-ace-edhoc-oscore-profile], which is used in the EAD_3 field
of EDHOC message_3 and transports (a reference to) an Access Token
that in turn specifies CRED_I by value or by reference.
When obtaining a new credential CRED, the peer P has to validate it
before storing it. The validation steps to perform depend on the
specific type of CRED (e.g., a public key certificate
[RFC5280][I-D.ietf-cose-cbor-encoded-cert]), and can rely on (the
authentication credential of) a trusted third party acting as a trust
anchor.
Upon retrieving a new CRED through the processing of a received EDHOC
message and following the successful validation of CRED, the peer P
stores CRED only if it assesses CRED to be also trusted, and must not
store CRED otherwise.
An exception applies for the two unauthenticated operations described
in Appendix D.5 of [I-D.ietf-lake-edhoc], where a trust relationship
with an unknown or not-yet-trusted endpoint is established later.
That is, CRED is verified out-of-band at a later stage, or an EDHOC
session key is bound to an identity out-of-band at a later stage.
If P stores CRED, then P will consider CRED as valid and trusted
until it possibly becomes invalid, e.g., because it expires or
because P gains knowledge that it has been revoked.
Tiloca Expires 15 August 2024 [Page 11]
Internet-Draft Implementation Considerations for EDHOC February 2024
When storing CRED, the peer P should generate the authentication
credential identifier(s) corresponding to CRED and store them as
associated with CRED. For example, if CRED is a public key
certificate, an identifier of CRED can be the hash of the
certificate. In general, P should generate and associate with CRED
one corresponding identifier for each type of authentication
credential identifier that P supports and that is compatible with
CRED.
In future executions of EDHOC with the other peer associated with
CRED, this allows such other peer to specify CRED by reference, e.g.,
by indicating its credential identifier as ID_CRED_R/ID_CRED_I in the
EDHOC message_2 or message_3 addressed to the peer P. In turn, this
allows P to retrieve CRED from its local storage.
When processing a received EDHOC message M that specifies an
authentication credential CRED, the peer P can enforce one of the
following trust policies in order to determine whether to trust CRED.
* NO-LEARNING: according to this policy, the peer P trusts CRED if
and only if P is already storing CRED at message reception time.
That is, upon receiving M, the peer P can continue the execution
of EDHOC only if both the following conditions hold.
- P currently stores CRED, as specified by reference or by value
in ID_CRED_I/ID_CRED_R or in the value of an EAD item; and
- CRED is still valid, i.e., P believes CRED to not be expired or
revoked.
* LEARNING: according to this policy, the peer P trusts CRED even if
P is not already storing CRED at message reception time.
That is, upon receiving M, the peer P performs the following
steps.
1. P retrieves CRED, as specified by reference or by value in
ID_CRED_I/ID_CRED_R or in the value of an EAD item.
2. P checks whether CRED is already being stored and if it is
still valid. In such a case, P trusts CRED and can continue
the EDHOC execution. Otherwise, P moves to step 3.
3. P attempts to validate CRED. If the validation process is not
successful, P aborts the EDHOC session with the other peer.
Otherwise, P trusts and stores CRED, and can continue the
EDHOC execution.
Tiloca Expires 15 August 2024 [Page 12]
Internet-Draft Implementation Considerations for EDHOC February 2024
Irrespective of the adopted trust policy, P actually uses CRED only
if it is determined to be fine to use in the context of the ongoing
EDHOC session, also depending on the specific identity of the other
peer (see Sections 3.5 and D.2 of [I-D.ietf-lake-edhoc]). If this is
not the case, P aborts the EDHOC session with the other peer.
4. Side Processing of Incoming EDHOC Messages
This section describes an approach that EDHOC peers can use upon
receiving EDHOC messages, in order to fetch/validate authentication
credentials and to process External Authorization Data (EAD) items.
As per Section 9.1 of [I-D.ietf-lake-edhoc], the EDHOC protocol
provides a transport mechanism for conveying EAD items, but
specifications defining those items have to set the ground for
"agreeing on the surrounding context and the meaning of the
information passed to and from the application".
The approach described in this section aims to help implementors
navigate the surrounding context mentioned above, irrespective of the
specific EAD items conveyed in the EDHOC messages. In particular,
the described approach takes into account the following points.
* The fetching and validation of the other peer's authentication
credential relies on ID_CRED_I in EDHOC message_2, or on ID_CRED_R
in EDHOC message_3, or on the value of an EAD item. When this
occurs upon receiving EDHOC message_2 or message_3, the decryption
of the EDHOC message has to be completed first.
The validation of the other peer's authentication credential might
depend on using the value of an EAD item, which in turn has to be
validated first. For instance, an EAD item within the EAD_2 field
may contain a voucher to be used for validating the other peer's
authentication credential (see [I-D.ietf-lake-authz]).
* Some EAD items may be processed only after having successfully
verified the EDHOC message, i.e., after a successful verification
of the Signature_or_MAC field.
For instance, an EAD item within the EAD_3 field may contain a
Certificate Signing Request (CSR) [RFC2986]. Hence, such an EAD
item can be processed only once the recipient peer has attained
proof of the other peer possessing its private key.
In order to conveniently handle such processing, the application can
prepare in advance one "side-processor object" (SPO), which takes
care of the operations above during the EDHOC execution.
Tiloca Expires 15 August 2024 [Page 13]
Internet-Draft Implementation Considerations for EDHOC February 2024
In particular, the application provides EDHOC with the SPO before
starting an EDHOC execution, during which EDHOC will temporarily
transfer control to the SPO at the right point in time, in order to
perform the required side-processing of an incoming EDHOC message.
Furthermore, the application has to instruct the SPO about how to
prepare any EAD item such that: it has to be included in an outgoing
EDHOC message; and it is independent of the processing of other EAD
items included in incoming EDHOC messages. This includes, for
instance, the preparation of padding EAD items.
At the right point in time during the processing of an incoming EDHOC
message M at the peer P, EDHOC invokes the SPO and provides it with
the following input:
* When M is EDHOC message_2 or message_3, an indication of whether
this invocation is happening before or after the message
verification (i.e., before or after having verified the
Signature_or_MAC field).
* The full set of information related to the current EDHOC session.
This especially includes the selected cipher suite and the
ephemeral Diffie-Hellman public keys G_X and G_Y that the two
peers have exchanged in the EDHOC session.
* The other peers' authentication credentials that the peer P
stores.
* All the decrypted information elements retrieved from M.
* The EAD items included in M.
- Note that EDHOC might do some preliminary work on M before
invoking the SPO, in order to provide the SPO only with
actually relevant EAD items. This requires the application to
additionally provide EDHOC with the ead_labels of the EAD items
that the peer P recognizes (see Section 3.8 of
[I-D.ietf-lake-edhoc]).
With such information available, EDHOC can early abort the
current session in case M includes any EAD item which is both
critical and not recognized by the peer P.
Tiloca Expires 15 August 2024 [Page 14]
Internet-Draft Implementation Considerations for EDHOC February 2024
If no such EAD items are found, EDHOC can remove any padding
EAD item (see Section 3.8.1 of [I-D.ietf-lake-edhoc]), as well
as any EAD item which is neither critical nor recognized (since
the SPO is going to ignore it anyway). As a result, EDHOC is
able to provide the SPO only with EAD items that will be
recognized and that require actual processing.
- Note that, after having processed the EAD items, the SPO might
actually need to store them throughout the whole EDHOC
execution, e.g., in order to refer to them also when processing
later EDHOC messages in the current EDHOC session.
The SPO performs the following tasks on an incoming EDHOC message M.
* The SPO fetches and/or validates the other peer's authentication
credential CRED, based on a dedicated EAD item of M or on the
ID_CRED field of M (for EDHOC message_2 or message_3).
* The SPO processes the EAD items conveyed in the EAD field of M.
* The SPO stores the results of the performed operations, and makes
such results available to the application.
* When the SPO has completed its side processing and transfers
control back to EDHOC, the SPO provides EDHOC with the produced
EAD items to include in the EAD field of the next outgoing EDHOC
message. The production of such EAD items can be triggered, e.g.,
by:
- The consumption of EAD items included in M; and
- The execution of instructions that the SPO has received from
the application, concerning EAD items to produce irrespective
of other EAD items included in M.
The following subsections describe more in detail the actions
performed by the SPO on the different, incoming EDHOC messages.
4.1. EDHOC message_1
During the processing of an incoming EDHOC message_1, EDHOC invokes
the SPO only once, after the Responder peer has successfully decoded
the message and accepted the selected cipher suite.
If the EAD_1 field is present, the SPO processes the EAD items
included therein.
Tiloca Expires 15 August 2024 [Page 15]
Internet-Draft Implementation Considerations for EDHOC February 2024
Once all such EAD items have been processed the SPO transfers control
back to EDHOC. When doing so, the SPO also provides EDHOC with any
produced EAD items to include in the EAD field of the next outgoing
EDHOC message.
Then, EDHOC resumes its execution and advances its protocol state.
4.2. EDHOC message_4
During the processing of an incoming EDHOC message_4, EDHOC invokes
the SPO only once, after the Initiator peer has successfully
decrypted the message.
If the EAD_4 field is present, the SPO processes the EAD items
included therein.
Once all such EAD items have been processed, the SPO transfers
control back to EDHOC, which resumes its execution and advances its
protocol state.
4.3. EDHOC message_2 and message_3
The following refers to "message_X" as an incoming EDHOC message_2 or
message_3, and to "message verification" as the verification of
Signature_or_MAC_X in message_X.
During the processing of a message_X, EDHOC invokes the SPO two
times:
* Right after message_X has been decrypted and before its
verification starts. Following this invocation, the SPO performs
the actions described in Section 4.3.1.
* Right after message_X has been successfully verified. Following
this invocation, the SPO performs the actions described in
Section 4.3.2.
The flowcharts in Section 4.3.3 show the high-level interaction
between the core EDHOC processing and the SPO, as well as the
different steps taken for processing an incoming message_X.
4.3.1. Pre-Verification Side Processing
The pre-verification side processing occurs in two sequential phases,
namely PHASE_1 and PHASE_2.
Tiloca Expires 15 August 2024 [Page 16]
Internet-Draft Implementation Considerations for EDHOC February 2024
PHASE_1 - During PHASE_1, the SPO at the recipient peer P determines
CRED, i.e., the other peer's authentication credential to use in the
ongoing EDHOC session. In particular, the SPO performs the following
steps.
1. The SPO determines CRED based on ID_CRED_X or on an EAD item in
message_X.
Those may specify CRED by value or by reference, including a URI
or other external reference where CRED can be retrieved from.
If CRED is already installed, the SPO moves to step 2.
Otherwise, the SPO moves to step 3.
2. The SPO determines if the stored CRED is currently valid, e.g.,
by asserting that CRED has not expired and has not been revoked.
Performing such a validation may require the SPO to first
process an EAD item included in message_X. For example, it can
be an EAD item in EDHOC message_2, which confirms or revokes the
validity of CRED_R specified by ID_CRED_R, as the result of an
OCSP process [RFC6960].
In case CRED is determined to be valid, the SPO moves to step 9.
Otherwise, the SPO moves to step 11.
3. The SPO attempts to retrieve CRED, and then moves to step 4.
4. If the retrieval of CRED has succeeded, the SPO moves to step 5.
Otherwise, the SPO moves to step 11.
5. If the enforced trust policy for new authentication credentials
is "NO-LEARNING" (see Section 3), the SPO moves to step 11.
Otherwise, the SPO moves to step 6.
6. If this step has been reached, the peer P enforces the trust
policy "LEARNING" (see Section 3) and it is not already storing
the retrieved CRED.
Consistently, the SPO determines if CRED is currently valid,
e.g., by asserting that CRED has not expired and has not been
revoked. Then, the SPO moves to step 7.
Tiloca Expires 15 August 2024 [Page 17]
Internet-Draft Implementation Considerations for EDHOC February 2024
Validating CRED may require the SPO to first process an EAD item
included in message_X. For example, it can be an EAD item in
EDHOC message_2 that: i) specifies a voucher for validating
CRED_R as a CWT Claims Set (CCS) [RFC8392] transported by value
in ID_CRED_R (see [I-D.ietf-lake-authz]); or instead ii) an OCSP
response [RFC6960] for validating CRED_R as a certificate
transported by value or reference in ID_CRED_R.
7. If CRED has been determined valid, the SPO moves to step 8.
Otherwise, the SPO moves to step 11.
8. The SPO stores CRED as a valid and trusted authentication
credential associated with the other peer, together with
corresponding authentication credential identifiers (see
Section 3). Then, the SPO moves to step 9.
9. The SPO checks if CRED is fine to use in the context of the
ongoing EDHOC session, also depending on the specific identity
of the other peer (see Sections 3.5 and D.2 of
[I-D.ietf-lake-edhoc]).
If this is the case, the SPO moves to step 10. Otherwise, the
SPO moves to step 11.
10. P uses CRED as authentication credential of the other peer in
the ongoing EDHOC session.
Then, PHASE_1 ends, and the pre-verification side processing
moves to the next PHASE_2 (see below).
11. The SPO has not found a valid authentication credential
associated with the other peer that can be used in the ongoing
EDHOC session. Therefore, the EDHOC session with the other peer
is aborted.
PHASE_2 - During PHASE_2, the SPO processes any EAD item included in
message_X such that both the following conditions hold.
* The EAD item has _not_ been already processed during PHASE_1.
* The EAD item can be processed before performing the verification
of message_X.
Once all such EAD items have been processed, the SPO transfers
control back to EDHOC, which either aborts the ongoing EDHOC session
or continues the processing of message_X with its corresponding
message verification.
Tiloca Expires 15 August 2024 [Page 18]
Internet-Draft Implementation Considerations for EDHOC February 2024
4.3.2. Post-Verification Side Processing
During the post-verification side processing, the SPO processes any
EAD item included in message_X such that the processing of that EAD
item had to wait for completing the successful message verification.
The late processing of such EAD items is typically due to the fact
that a pre-requirement has to be fulfilled first. For example, the
recipient peer P has to have first asserted that the other peer does
possess the private key corresponding to the public key of the other
peer's authentication credential CRED determined during the pre-
verification side processing (see Section 4.3.1). This requirement
is fulfilled after a successful message verification of message_X.
Once all such EAD items have been processed, the SPO transfers
control back to EDHOC. When doing so, the SPO also provides EDHOC
with any produced EAD items to include in the EAD field of the next
outgoing EDHOC message.
Then, EDHOC resumes its execution and advances its protocol state.
4.3.3. Flowcharts
The flowchart in Figure 4 shows the high-level interaction between
the core EDHOC processing and the SPO, with particular reference to
an incoming EDHOC message_2 or message_3.
EDHOC message_X
(X = 2 or 3)
|
|
+-----|---------------------------------------------------------------+
| | Core EDHOC processing |
| v |
| +-----------+ +----------------+ +----------------+ |
| | Decode |--->| Retrieve the | | Advance the | |
| | message_X | | protocol state | | protocol state | |
| +-----------+ +----------------+ +----------------+ |
| | ^ |
| | | |
| v | |
| +--------------+ +--------------------+ | |
| | Decrypt | | Verify | | |
| | CYPHERTEXT_X | | Signature_or_MAC_X | | |
| +--------------+ +--------------------+ | |
| | ^ | | |
| | | | | |
Tiloca Expires 15 August 2024 [Page 19]
Internet-Draft Implementation Considerations for EDHOC February 2024
+----------------|-----------|-----------|---------|------------------+
| | | |
| | | | .................
Divert | Get | Divert | Get | : EAD items :
| back | | back | : for the next :
| | | | : EDHOC message :
| | | | :...............:
| | | |
+----------------|-----------|-----------|---------|------------------+
| | | | | |
| v | v | |
| +---------------------------+ +-----------------------------+ |
| | a) Retrieval and | | Processing of | |
| | validation of CRED_X; | | post-verification EAD items | |
| | b) Trust assessment | +-----------------------o-----+ |
| | of CRED_X; | | |
| | c) Processing of o-------- Shared state -------o |
| | pre-verification | |
| | EAD items | ...................... |
| | | : Instructions about : |
| | - (a) and (c) might have | : EAD items to : |
| | to occur in parallel | : unconditionally : |
| | - (b) depends on the | : produce for the : |
| | used trust model | : next EDHOC message : |
| +---------------------------+ :....................: |
| |
| Side-Processor Object |
+---------------------------------------------------------------------+
Figure 4: High-Level Interaction Between the Core EDHOC
Processing and the Side-Processor Object (SPO)
The flowchart in Figure 5 shows the different steps taken for
processing an incoming EDHOC message_2 and message_3.
Incoming
EDHOC message_X
(X = 2 or 3)
|
|
v
+-------------------+
| Decrypt message_X | (Core EDHOC Processing)
+-------------------+
|
|
Tiloca Expires 15 August 2024 [Page 20]
Internet-Draft Implementation Considerations for EDHOC February 2024
Control transferred to
the side-processor object
|
+---------|---------------------------------------------------------+
| | Pre-verification side processing (PHASE_1) |
| v |
| +---------------------+ +--------------+ +-------------+ |
| | 1. Does ID_CRED_X | NO | 3. Retrieve | | 4. Is the | |
| | or an EAD item |---->| CRED via |--->| retrieval | |
| | point to an already | | ID_CRED_X or | | of CRED | |
| | stored CRED? | | an EAD item | | successful? | |
| +---------------------+ +--------------+ +-------------+ |
| | | | |
| | | NO | YES |
| | +--------------+ | |
| | YES | | |
| v v v |
| +-----------------+ NO +-----------+ YES +----------------+ |
| | 2. Is this CRED |-------->| 11. Abort |<-----| 5. Is the | |
| | still valid? | | the EDHOC | | used policy | |
| +-----------------+ | session | | "NO-LEARNING"? | |
| | | | +----------------+ |
| | YES | | | |
| v | | The used policy | NO |
| +--------------------+ NO | | is "LEARNING" | |
| | 9. Is this CRED |----->| | v |
| | good to use in the | +-----------+ +-------------+ |
| | context of this | ^ | 6. Validate | |
| | EDHOC session? |<--+ | | CRED | |
| +--------------------+ | | +-------------+ |
| | | | | |
| | YES | | NO | |
| | | | v |
| | | +-----------------------------+ |
| | | | 7. Is CRED valid? | |
| | | +-----------------------------+ |
| | | | |
| | | | YES |
| | | v |
| v | +-----------------------------+ |
| +------------------+ | | 8. Store CRED as valid and | |
| | 10. Continue by | +--------| trusted. | |
| | considering this | | | |
| | CRED as the | | Pair CRED with consistent | |
| | authentication | | credential identifiers, for | |
| | credential of | | each supported type of | |
| | the other peer | | credential identifier. | |
Tiloca Expires 15 August 2024 [Page 21]
Internet-Draft Implementation Considerations for EDHOC February 2024
| +------------------+ +-----------------------------+ |
| | |
+---------|---------------------------------------------------------+
|
|
+---------|---------------------------------------------------------+
| | Pre-verification side processing (PHASE_2) |
| v |
| +---------------------------------------------------------+ |
| | Process the EAD items that have not been processed yet, | |
| | and that can be processed before message verification | |
| +---------------------------------------------------------+ |
| | |
+---------|---------------------------------------------------------+
|
|
Control transferred back
to the core EDHOC processing
|
|
v
+------------------+
| Verify message_X | (core EDHOC processing)
+------------------+
|
|
Control transferred to
the side-processor object
|
+---------|----------------------------------------+
| | Post-verification processing |
| v |
| +---------------------------------------------+ |
| | Process the EAD items that have to be | |
| | processed (also) after message verification | |
| +---------------------------------------------+ |
| | |
| | |
| v |
| +--------------------------------------------+ |
| | Make all the results of the EAD processing | |
| | available to build the next EDHOC message | |
| +--------------------------------------------+ |
| | |
Tiloca Expires 15 August 2024 [Page 22]
Internet-Draft Implementation Considerations for EDHOC February 2024
+---------|----------------------------------------+
|
|
Control transferred back
to the core EDHOC processing
|
|
v
+----------------+
| Advance the | (core EDHOC processing)
| protocol state |
+----------------+
Figure 5: Processing steps for EDHOC message_2 and message_3
5. Security Considerations
TBD
6. IANA Considerations
This document has no actions for IANA.
7. References
7.1. Normative References
[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>.
[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>.
Tiloca Expires 15 August 2024 [Page 23]
Internet-Draft Implementation Considerations for EDHOC February 2024
[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>.
7.2. Informative References
[I-D.ietf-ace-edhoc-oscore-profile]
Selander, G., Mattsson, J. P., Tiloca, M., and R. Höglund,
"Ephemeral Diffie-Hellman Over COSE (EDHOC) and Object
Security for Constrained Environments (OSCORE) Profile for
Authentication and Authorization for Constrained
Environments (ACE)", Work in Progress, Internet-Draft,
draft-ietf-ace-edhoc-oscore-profile-03, 23 October 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-ace-
edhoc-oscore-profile-03>.
[I-D.ietf-core-oscore-key-limits]
Höglund, R. and M. Tiloca, "Key Usage Limits for OSCORE",
Work in Progress, Internet-Draft, draft-ietf-core-oscore-
key-limits-02, 10 January 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-core-
oscore-key-limits-02>.
[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-06, 23 October 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-core-
oscore-key-update-06>.
[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-07, 20 October 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-cose-
cbor-encoded-cert-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>.
Tiloca Expires 15 August 2024 [Page 24]
Internet-Draft Implementation Considerations for EDHOC February 2024
[RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification
Request Syntax Specification Version 1.7", RFC 2986,
DOI 10.17487/RFC2986, November 2000,
<https://www.rfc-editor.org/rfc/rfc2986>.
[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>.
[RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A.,
Galperin, S., and C. Adams, "X.509 Internet Public Key
Infrastructure Online Certificate Status Protocol - OCSP",
RFC 6960, DOI 10.17487/RFC6960, June 2013,
<https://www.rfc-editor.org/rfc/rfc6960>.
[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>.
[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>.
Acknowledgments
The author sincerely thanks Christian Amsüss, Geovane Fedrecheski,
Rikard Höglund, John Preuß Mattsson, Göran Selander, and Mališa
Vučinić for their comments and feedback.
Author's Address
Marco Tiloca
RISE AB
Isafjordsgatan 22
SE-16440 Stockholm Kista
Sweden
Email: marco.tiloca@ri.se
Tiloca Expires 15 August 2024 [Page 25]