Lightweight Authenticated Key Exchange
charter-ietf-lake-01-01

EDHOC (draft-ietf-lake-edhoc), an output of the LAKE working group, defines a
lightweight authenticated key exchange protocol between two peers. EDHOC
provides forward secrecy, mutual peer authentication, identity protection of
the protocol initiator, and crypto agility. EDHOC was formally studied in
different security models: its design reflects the academic community feedback
that analyzed its security properties. EDHOC is intended to be used in
constrained network environments such as NB-IoT, 6TiSCH and LoRaWAN.

The primary purpose of EDHOC is to key the Object Security for Constrained
RESTful Environments protocol (OSCORE, RFC 8613). EDHOC is based on Concise
Binary Object Representation (CBOR, RFC 8949) and CBOR Object Signing and
Encryption (COSE, RFC 9052 and RFC 9053) to minimize the message sizes and the
memory footprint when used with other CBOR-based protocols.
Draft-ietf-lake-edhoc is a dependency of documents in the CoRE, ACE, EMU and
IOTOPS working groups.

By publishing EDHOC, the base protocol specification, and the lake-traces
document, the LAKE working group has completed its initial goal. The working
group will continue to work on maintaining and extending the base protocol
specification as appropriate.

The initial design scope of EDHOC ruled out authentication based on pre-shared,
symmetric keys and focused on asymmetric authentication credentials (e.g., raw
public keys and public key certificates) in order to streamline the working
group activities. Similarly, the base protocol specification does not define a
protocol for rekeying but rather a rekeying function to use as an inner
building block for key update.

The working group will define an EDHOC rekeying protocol reusing the protocol
elements from the base specification that uses symmetric keys for
authentication, as usable both during a key update and a first-time key
exchange.

Within each protocol message, EDHOC provides External Authorization Data (EAD)
fields. These fields may be used by external security applications to reduce
the number of messages and round trips, or to simplify processing. The working
group will specify the following uses of EAD fields to augment the EDHOC key
exchange: 3rd party-assisted authorization of EDHOC peers.
Draft-selander-lake-authz is a candidate starting point for this work. Remote
attestation of EDHOC peers, for instance using the available work from the RATS
working group. Status verification of EDHOC peer authentication credentials
transported during an EDHOC key exchange (e.g. OCSP stapling).

The working group will also work on a means for coordinating the use and
discovery of EDHOC application profiles, the definition of a well-known
application profile and processing extensions through EDHOC’s defined extension
points, such as registering new schemes and new EAD registrations.

In addition, the working group will work on a document gathering implementation
considerations and guidance for the base protocol specification.