Internet DRAFT - draft-hb-pquip-dot1x-over-ip
draft-hb-pquip-dot1x-over-ip
Network Working Group H. Bidgoli, Ed.
Internet-Draft Nokia
Intended status: Standards Track 10 July 2023
Expires: 11 January 2024
EAP over IP
draft-hb-pquip-dot1x-over-ip-00
Abstract
Extensible Authentication Protocol (EAP) is described in [RFC3748].
EAP typically runs directly over data link layers such as Point-to-
Point Protocol (PPP) or IEEE 802, without requiring IP.
IEEE802.1X-2004 clarifies some aspect of the EAP over Layer 2 PDUs.
IEEE802.1X-2010 introduces MACsec Key Agreement Protocol (MKA) which
uses EAPOL. In IEEE 802.1X-2010 the existing EAPOL (EAP over LANs)
PDU formats have not been modified, but additional EAPOL PDUs have
been added to support MKA. MKA is used for discovering peers and
their mutual authentication, to agree the secrete keys (SAKs) used by
MACsec for symmetric shared key cryptography. This document
describes procedures to transport EAP and ultimately MKA PDUs over a
IP network to distribute SAKs for symmetric key cryptography.
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 11 January 2024.
Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved.
Bidgoli Expires 11 January 2024 [Page 1]
Internet-Draft EAP over IP July 2023
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
2. Conventions used in this document . . . . . . . . . . . . . . 3
3. EAP over IP . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Use of UDP to identify MKA . . . . . . . . . . . . . . . 4
3.2. IP header . . . . . . . . . . . . . . . . . . . . . . . . 4
3.3. Packet format . . . . . . . . . . . . . . . . . . . . . . 4
4. IANA Consideration . . . . . . . . . . . . . . . . . . . . . 5
5. Security Considerations . . . . . . . . . . . . . . . . . . . 5
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5
7. Informative References . . . . . . . . . . . . . . . . . . . 5
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5
1. Introduction
Currently, most encryption protocols use Public Key Infrastructure
(PKI) to distribute symmetric shared keys. Current PKIs algorithms
and key lengths are vulnerable to post quantum computers attacks such
as "steal/harvest now, decrypt later" and most highly secure
organizations are looking for options of quantum safe key
distribution.
IEEE802.1X-2010 introduces MKA which comprises a secure fully
distributed point-to-point or multipoint-to-multipoint transport and
a number of applications of that transport, including the
distribution of SAKs by an elected key server using AES Key Wrap.
MKA is fully described in section 9 of IEEE802.1X-2010. One of the
strengths of MKA is using AES ciphers in CMAC mode with key length of
256 as a Key Wrap for the SAK. It is widely accepted that AES
ciphers with key length of 256 are safe Post-quantum Cryptography
(PQC). IEEE802.1X-2010 farther explains in section 9.3.3 that the
keys derived for AES cipher is from a secure Connectivity Association
Key (CAK) and a Key Derivation Function (KDF), the CAK can be drived
from multiple methods including Pre-shared keys (PSKs), as an example
these PSKs can be manually configured and consist of a 64 Hex string
for CMAC-AES-256 key wrap.
Bidgoli Expires 11 January 2024 [Page 2]
Internet-Draft EAP over IP July 2023
As it can be seen MKA can be a PQC protocol to distribute symmetric
shared keys within a network.
As such, it would be ideal to extend EAP and MKA into IP networks to
allow MKA to distribute symmetric shared keys within an IP domain.
This document describes a simple method to identify EAP packet with
in a IP network and process them according, including MKA PDUs.
2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
3. EAP over IP
802.1x-2010 section 9 explains the MKA (MACSec Key Agreement
Protocol) in detail. The first and most important note is section
9.4 last paragraph which points out that MKA is designed for mutual
authentication of participants in a connectivity association (CA),
and can be used for any application.
Section 9 of IEEE802.1x-2010 also points out that MKA:
1. allows PEERs to discover each other and authenticate each other
via the CAK, and agree on a symmetric secret keys (SAKs) used by the
application.
2. MKA protects the distributed SAKs via AES Key wrap, and more
importantly a PQC AES-256 key wrap
3. The SAK is created by the Key Server and distributed to the PEERs
with in the connectivity association, section 9 of the
IEEE802.1x-2010 describes the key server selection.
4. MKA manages the SAK installation which is used by the application
that secure the data transmitted and received.
5. The root of key hierarchy for any given instance of MKA is the
secure CAK. Each CAK is identified by CA key NAME (CKN) that allows
each of the MKA participants to select which CAK to use to process a
received MKA PDUs.
As such it is ideal to use MKA to authenticate peers and distribute
symmetric keys in a PQC fashion even in an IP network. As an example
MKA over IP can be used for signaling symmetric keys for proprietary
MPLS encryption or such.
Bidgoli Expires 11 January 2024 [Page 3]
Internet-Draft EAP over IP July 2023
To distribute MKA over an IP network there is two concerns to be
solved:
1. How to identify the MKA PDUs with in an IP domain
2. How to transport MKA PDUs from one PEER to another
3.1. Use of UDP to identify MKA
To solve the first problem of identifying EAP or MKA PDUs with in an
IP domain, the destination PEER needs to identify this packet as an
MKA packet and extract it to be processed as described in IEEE802.1X-
2010. To identify the PDU as a MKA PDU with in IP domain, UDP can be
used. More precisely, a specific UDP port assigned to MKA, to
identify MKA PDUs uniquely in the network. This UDP port can be
configured network wide, or it can be a well known UDP port assigned
by IANA. UDP is ideal for this MKA identification, as it is best
effort protocol and does not have a retransmission mechanism as TCP
does, in case of lost packets. This is ideal for MKA as it has a
heart beat build in to it, where if few MKA packets are lost, it
would bring the MKA session down.
3.2. IP header
Any IP address family (AF) can be used to transport the MKA over UDP
through the IP domain. The source IP can be the loopback IP address
used by the application and the destination IP can be the loopback IP
used by the application on the PEER. Of course the IP protocol will
be set to UDP. With this method when the packet arrives on the PEER
router, the UDP port can be examined and the packet processed
accordingly. In this case the UDP packet will identify the PDU as a
MKA PDU and will extract it to the MKA application to authenticate
the PEER and extract the symmetric key by decrypting the key wrap via
the CAK that is identified by the CKN and AES-256 using CMAC. From
this point on the symmetric key can be used by the application to
encrypt the datapath. As an example if the symmetric key size is 256
is can be used with AES algorithm to create a PQC secure datapath for
the application.
3.3. Packet format
The packet format reuses the entire 802.1x packet format as described
in the IEEE802.1X-2010 (i.e. it reuses the packet format that follows
the Ethernet header with ethertype (0x888e) minus the Ethernet
header.). Doing so will allow the routers that have implementations
of MACsec and MKA, to leverag the current EAPoL and MKA
implementations, and extend these implemention to be used to process
the EAP over IP packet. As an example by removing the IP and UDP
Bidgoli Expires 11 January 2024 [Page 4]
Internet-Draft EAP over IP July 2023
header and sending the 802.1x-2010 packet (with type MKA) to the MKA
application to process the MKA PDU without reinventing the wheel.
As such the final packet format is Ethernet header with ethertype of
(IP) followed by IP header with protocol (UDP) where the UDP port is
a well known MKA UDP port or a a UDP port that is assigned within the
network to identify the MKA PDU.
4. IANA Consideration
Assign a UDP port for EAP over IP identification.
5. Security Considerations
NA
6. Acknowledgments
7. Informative References
[RFC2119] "S. Bradner "Key words for use in RFCs to Indicate
Requirements Levels"".
[RFC3748] "B. Aboda, L. Blunk, J. Vollbrecht, J.Carlson "Extensible
Authentication Protocol"", June 2004.
Author's Address
Hooman Bidgoli (editor)
Nokia
Ottawa
Canada
Email: hooman.bidgoli@nokia.com
Bidgoli Expires 11 January 2024 [Page 5]
