Skip to main content

Forward Secrecy for the Extensible Authentication Protocol Method for Authentication and Key Agreement (EAP-AKA' FS)
draft-ietf-emu-aka-pfs-12

Approval announcement
Draft of message to be sent after approval:

Announcement

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: The IESG <iesg@ietf.org>, draft-ietf-emu-aka-pfs@ietf.org, emu-chairs@ietf.org, emu@ietf.org, paul.wouters@aiven.io, peter@akayla.com, rfc-editor@rfc-editor.org
Subject: Protocol Action: 'Forward Secrecy for the Extensible Authentication Protocol Method for Authentication and Key Agreement (EAP-AKA' FS)' to Proposed Standard (draft-ietf-emu-aka-pfs-12.txt)

The IESG has approved the following document:
- 'Forward Secrecy for the Extensible Authentication Protocol Method for
   Authentication and Key Agreement (EAP-AKA' FS)'
  (draft-ietf-emu-aka-pfs-12.txt) as Proposed Standard

This document is the product of the EAP Method Update Working Group.

The IESG contact persons are Paul Wouters and Deb Cooley.

A URL of this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-emu-aka-pfs/


Ballot Text

Technical Summary

 This document updates RFC 9048, the improved Extensible Authentication Protocol Method for 3GPP Mobile Network Authentication and Key Agreement (EAP-AKA'), with an optional extension providing ephemeral key exchange. Similarly, this document also updates the earlier version of the EAP-AKA' specification in RFC 5448. The extension EAP-AKA' Forward Secrecy (EAP-AKA' FS), when negotiated, provides forward secrecy for the session keys generated as a part of the authentication run in EAP-AKA'. This prevents an attacker who has gained access to the long-term key from obtaining session keys established in the past, assuming these have been properly deleted. In addition, EAP-AKA' FS mitigates passive attacks (e.g., large scale pervasive monitoring) against future sessions. This forces attackers to use active attacks instead.

Working Group Summary

 This document reflects strong consensus from members of the working group
interested in improving the EAP-AKA' method. There were zero objections raised
to moving this work forward.

Document Quality

There is at least one closed-source implementation of this specification. The
authors have indicated business interest in implementing this specification in
the near future.

This document is built on AKA, but it does not modify AKA. 3GPP, which
specifies AKA and uses the underlying RFC 5448 and 9048, have seen this
work and provided feedback.

Personnel

  Document Shepherd: Peter Yee
  Responsible AD: Paul Wouters

RFC Editor Note