MKA over IP

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. 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.

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: 1. How to identify the MKA PDUs with in an IP domain 2. How to transport MKA PDUs from one PEER to another

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.

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.

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.

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.