Internet-Draft | EAP-MPSK | March 2024 |
Yan | Expires 5 September 2024 | [Page] |
This document defines an Extensible Authentication Protocol (EAP) method for supporting the negotiation of a PSK among multiple PSKs.¶
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.¶
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.¶
The existing PSK-based EAP methods, EAP-GPSK [RFC5433], EAP-PSK [RFC4764], EAP-SAKE [RFC4763] and EAP-PAX [RFC4746], assumed that only one PSK had been configured for the EAP peer and server.
A single PSK does not provide perfect forward secrecy [RFC5433].
Compromise of the PSK leads to compromise of recorded past sessions.
Moreover, compromise of the PSK enables the attacker to impersonate the peer and the server, and it allows the adversary to compromise future sessions.
One solution is to use multiple PSKs between the EAP peer and server.¶
Traditional manual configuration of PSKs lacks automation and is less efficient. Currently, there are some new manners of configuring PSKs more efficiently. Quantum keys generated by a quantum network can be automatically obtained through a network and configured as PSKs. In the mobile communication scenario, plenty of quantum keys can be offline implanted into mobile terminals. In the post-quantum scenario, each communication peer is typically assumed to have a list of post-quantum PSKs [RFC8784]. If there are ample PSKs, using each PSK only once will provide perfect forward secrecy. Moreover, the attacker cannot impersonate the peer and the server by compromising a used PSK; one PSK's compromise will not influence future sessions.¶
Furthermore, the issue of PSK identity collisions should be considered when managing multiple PSKs. PSKs can be configured in different manners, for example, through traditional manual configuration or obtained through quantum key generators. The PSK identities in different configuration methods usually do not have a unified plan. Thus, it is possible that a PSK identity may clash with another PSK identity configured in a different manner. Even obtained from different quantum key generators, the PSKs' identity may have a collision. Thus, multiple PSKs should be managed by category.¶
This document modifies the EAP-GPSK to support the negotiation of a PSK among multiple PSKs.¶
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.¶