MKA over IP
draft-hb-intarea-eap-mka-00

Network Working Group                                    H. Bidgoli, Ed.
Internet-Draft                                                     Nokia
Intended status: Standards Track                               N. Morris
Expires: 1 September 2024                                        Verizon
                                                               N. Cocker
                                                                  Redhat
                                                        29 February 2024

                              MKA over IP
                      draft-hb-intarea-eap-mka-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 1 September 2024.

Copyright Notice

   Copyright (c) 2024 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

Bidgoli, et al.         Expires 1 September 2024                [Page 1]
Internet-Draft                 MKA over IP                 February 2024

   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.  Security Channel Identifier . . . . . . . . . . . . . . .   4
     3.4.  Packet format . . . . . . . . . . . . . . . . . . . . . .   5
   4.  IANA Consideration  . . . . . . . . . . . . . . . . . . . . .   5
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   6.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .   5
   7.  Informative References  . . . . . . . . . . . . . . . . . . .   5
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   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.

   IIEEE802.1X-2010 introduces MKA, a secure fully distributed point-to-
   point or multipoint-to-multipoint transport.  MKA consists of a
   number of applications for that transport, including the distribution
   of SAKs by an elected key server using AES Key Wrap.. 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 via a secure management connection and consist of a 64 Hex
   string for CMAC-AES-256 key wrap.

   With those attributes in mind, MKA can be a PQC protocol to
   distribute symmetric shared keys within a network.

Bidgoli, et al.         Expires 1 September 2024                [Page 2]
Internet-Draft                 MKA over IP                 February 2024

   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 in the
   last paragraph of section 9.4 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 and distributes 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
   applications 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 the CA key NAME (CKN) that
   allows each of the MKA participants to select which CAK to use to
   process a received MKA PDUs.

   These attributes are ideal to use MKA to authenticate peers and
   distribute symmetric keys in a PQC fashion even in an IP or MPLS
   network.  As an example MKA over IP can be used for signaling
   symmetric keys for proprietary MPLS encryption or such.

   To distribute MKA over an IP network there is two concerns to be
   solved:

Bidgoli, et al.         Expires 1 September 2024                [Page 3]
Internet-Draft                 MKA over IP                 February 2024

   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 within 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 within 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 a random UDP port chosen by the provider, or it can be a well
   known UDP port assigned by IANA, either case it has to be same
   network wide.  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.  MKA fits well with this use-case
   because it has a heartbeat built in, where loss of MKA packets 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 source of the application and the destination IP can be
   the loopback IP used by the application on its 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 SAK by
   decrypting the key wrap via the CAK that is identified by the CKN and
   CMAC AES-256.  From this point on the SAK can be used by the
   application to encrypt the datapath.  As an example, if the symmetric
   key size is 256 it can be used with the AES algorithm to create a PQC
   secure datapath for the application.

3.3.  Security Channel Identifier

   MACsec uses the PORT ID as its security channel Identifier (SCI).
   The SCI, for IP or MPLS applications can be modified based on the
   application requirements and how the application flow can be uniquely
   identified within the network.  As an example for MPLS the SCI can be
   a unique encryption SID that identifies the encrypting node within
   the network and the MPLS flowID or tunnelID within that encrypting
   node.  The assignment of SCI for different IP/MPLS applications is
   beyond the scope of this document.

Bidgoli, et al.         Expires 1 September 2024                [Page 4]
Internet-Draft                 MKA over IP                 February 2024

3.4.  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 leverage the current EAPoL and MKA
   implementations, and extend these implemention to be used to process
   the EAP over IP packet.  An example of this without reinventing the
   wheel would be to remove the IP and UDP headers and send the
   802.1x-2010 packet (with type MKA) to the MKA application to process
   the MKA PDU.

   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.

Authors' Addresses

   Hooman Bidgoli (editor)
   Nokia
   Ottawa
   Canada
   Email: hooman.bidgoli@nokia.com

Bidgoli, et al.         Expires 1 September 2024                [Page 5]
Internet-Draft                 MKA over IP                 February 2024

   Nicklous Morris
   Verizon
   United States of America
   Email: nicklous.morris@verizonwireless.com

   Nabeel Cocker
   Redhat
   New York,
   United States of America
   Email: ncocker@redhat.com

Bidgoli, et al.         Expires 1 September 2024                [Page 6]