Lightweight Authenticated Key Exchange (lake) Internet Drafts


      
 Lightweight Authorization using Ephemeral Diffie-Hellman Over COSE (ELA)
 
 draft-ietf-lake-authz-03.txt
 Date: 21/10/2024
 Authors: Goeran Selander, John Mattsson, Malisa Vucinic, Geovane Fedrecheski, Michael Richardson
 Working Group: Lightweight Authenticated Key Exchange (lake)
Ephemeral Diffie-Hellman Over COSE (EDHOC) is a lightweight authenticated key exchange protocol intended for use in constrained scenarios. This document specifies Lightweight Authorization using EDHOC (ELA). The procedure allows authorizing enrollment of new devices using the extension point defined in EDHOC. ELA is applicable to zero-touch onboarding of new devices to a constrained network leveraging trust anchors installed at manufacture time.
 Applying Generate Random Extensions And Sustain Extensibility (GREASE) to EDHOC Extensibility
 
 draft-amsuess-lake-edhoc-grease-01.txt
 Date: 13/10/2024
 Authors: Christian Amsuess
 Working Group: Lightweight Authenticated Key Exchange (lake)
This document applies the extensibility mechanism GREASE (Generate Random Extensions And Sustain Extensibility), which was pioneered for TLS, to the EDHOC ecosystem. It reserves a set of non-critical EAD labels and unusable cipher suites that may be included in messages to ensure peers correctly handle unknown values.
 Implementation Considerations for Ephemeral Diffie-Hellman Over COSE (EDHOC)
 
 draft-ietf-lake-edhoc-impl-cons-02.txt
 Date: 21/10/2024
 Authors: Marco Tiloca
 Working Group: Lightweight Authenticated Key Exchange (lake)
This document provides considerations for guiding the implementation of the authenticated key exchange protocol Ephemeral Diffie-Hellman Over COSE (EDHOC).
 Coordinating the Use of Application Profiles for Ephemeral Diffie-Hellman Over COSE (EDHOC)
 
 draft-ietf-lake-app-profiles-00.txt
 Date: 10/12/2024
 Authors: Marco Tiloca, Rikard Hoeglund
 Working Group: Lightweight Authenticated Key Exchange (lake)
The lightweight authenticated key exchange protocol Ephemeral Diffie- Hellman Over COSE (EDHOC) requires certain parameters to be agreed out-of-band, in order to ensure its successful completion. To this end, application profiles specify the intended use of EDHOC to allow for the relevant processing and verifications to be made. This document defines a number of means to coordinate the use and discovery of EDHOC application profiles. Also, it defines a canonical, CBOR-based representation that can be used to describe, distribute, and store EDHOC application profiles. Finally, this document defines a set of well-known EDHOC application profiles.


data-group-menu-data-url="/group/groupmenu.json">

Skip to main content

Lightweight Authenticated Key Exchange (lake)

WG Name Lightweight Authenticated Key Exchange
Acronym lake
Area Security Area (sec)
State Active
Charter charter-ietf-lake-02 Approved
Document dependencies
Additional resources GitHub Page
Webpage
Zulip stream
Personnel Chairs Mališa Vučinić, Stephen Farrell
Area Director Paul Wouters
Mailing list Address lake@ietf.org
To subscribe https://www.ietf.org/mailman/listinfo/lake
Archive https://mailarchive.ietf.org/arch/browse/lake/
Chat Room address https://zulip.ietf.org/#narrow/stream/lake

Charter for Working Group

EDHOC (draft-ietf-lake-edhoc), an output of the LAKE working group, defines a
lightweight authenticated key exchange protocol between two peers. EDHOC is
intended to be used in constrained network environments such as NB-IoT, 6TiSCH
and LoRaWAN.

By publishing EDHOC, the base protocol specification, and the lake-traces
document, the LAKE working group has completed its initial goals. 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 now will define a Standards Track EDHOC rekeying protocol reusing
the protocol elements from the base specification that uses symmetric keys for
authentication, to make those 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 Standards Track documents with 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, reusing as much as possible available
    work from the RATS and TLS working groups.

  • 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 Standard Track 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 an Informational document gathering
implementation considerations and guidance for the base protocol specification.

Milestones

Date Milestone Associated documents
Mar 2025 Verification of EDHOC authentication credentials submitted to IESG as Proposed Standard
Nov 2024 Remote attestation of EDHOC peers submitted to IESG as Proposed Standard
Nov 2024 EDHOC rekeying protocol submitted to IESG as Proposed Standard
Jun 2024 3rd party-assisted authorization of EDHOC submitted to IESG as Proposed Standard
Jun 2024 Implementation considerations and guidance submitted to IESG as Informational RFC