MACsec MKA Validation - Why Back-to-Back Tests Fall Short
2020-07-30 | 14 min read
By Yuanwen (Daisy) Sun |
In my previous blog, I focused on validation for MACsec hardware implementations. In this one, I will focus on validation for the MACsec control plane - MACsec key agreement (MKA) protocol.
MKA protocol is defined in the IEEE 802.1X – 2010 standard. It is used to discover members in a connectivity association (CA) and establish a secured relation among members to coordinate crypto algorithms and keys used for encryption/decryption to protect data transfer over the local area network (LAN) network.
Before we talk about how MKA works, let’s get familiar with some terminologies.
- CA is an important terminology to understand. There are 2 types of CA: pairwise CA and group CA. It is pretty straight forward. Pairwise CA has exactly two members, while group CA has more than 2 members. If a physical port supports multiple CAs, then it is typically separated by VLAN.
- Within a CA, it can have one or multiple SCs. SC is unidirectional. Each member has one Tx SC to all members in the same CA and multiple Rx SCs, one from each remote peer in the CA. If there are X members in a CA, then each member has X SCs that include 1 Tx SC and X-1 Rx SCs.
- SA is supported by a single secret key within an SC. When a new key is needed, either due to packet number exhaustion or due to adding/removing a member, a new SA is started. During the life span, an SC can have multiple SAs.
- The root of key hierarchy for any given instance of MKA is the secure Connectivity Association Key (CAK). ICK, KEK, and SAK are derived from CAK.
- For members in the same CA, they possess the same CAK identified by the CKN.
- To discover MACsec peers in same CA and establish a secured connection, each MACsec device sends EAPOL-MKA packet, advertising CKN and its own key server priority.
- The devices with same CKN belongs to same CA and establish an MKA session.
- The device with the highest key server priority (or SCI if a tie) is elected as key server. It is responsible to derive the SAK from CAK and distribute to the members in the same CA. The SAK is AES-wrapped using KEK for distribution to other members.
- ICK is used to authenticate messages from other members in the same CA.
There are 3 security modes for generating and managing a MACsec encryption key.
1. Pre-shared Keys (PSK) - Static CAK mode
- Manually configured CAK and CKN
- Derive ICK, KEK, and SAK from CAK
- Key server distributes SAK to CA member(s)
2. Master Session Key (802.1X/EAP) – Dynamic CAK mode
- EAP authentication
- Acquire MSK from radius server
- Derive CAK and CKN from MSK
- Derive SAK and other keys from CAK
- Key server distributes AES wrapped SAK to CA member(s)
3. Static SAK mode
- SAK is manually provisioned to hardware for encryption
Except for the last one where SAK is provisioned directly to hardware, the first two modes require MKA to discover CA members and manage crypto algorithms and keys among CA members.
TESTING MKA IMPLEMENTATIONS
MKA is considered a control plane protocol to manage MACsec devices for proper data protection. The implementation is typically done in software. It is important to ensure proper MKA session establishment, peer authentication, key exchange, scale and performance, and interoperability. Thorough validation of protocol function and scale is critical for successful MACsec operation. Now, let’s discuss the key validation focus for various aspects.
Validate CA member discovery and key server election
MACsec devices identify CA membership using CKN. The device with the same CKN will form an MKA session. A key server is elected based on key server priority, or SCI as a tie-breaker. Validation should provide answers to questions such as:
- Does the device properly discover all members in the same CA?
- Does the device properly list potential and live peers per mutual discovery?
- Does the device properly remove a member that has stopped sending MKPDUs for more than the MKA lifetime from the live peer list?
- Does the device properly elect the key server under various combinations of key server priority as well as tie-breaker with SCI?
- Does key server election happen when adding/removing peers?
- If the same key server is re-elected, does it initiate a new SAK distribution as a result of change in live members of the CA?
- Does the device advertise various parameters properly, such as MACsec capability, confidentiality offset?
- Does MKA operate properly with VLAN tagging?
To test CA member discovery and key server election under various conditions, you need a quick and easy way to set up multiple devices, different key server priorities and SCI, bring up/down a device, manipulate MKA hello time and lifetime; etc. A third-party test tool can conduct these tests with ease and good coverage.
Validate MACsec device acting as key server
The key server derives SAK from CAK and distributes it in a secure way to other members in a CA. Validation should provide answers to questions such as:
- Does the key server properly advertise the cipher suite, default GCM-AES-128, or non-default GCM-AES-256, GCM-AES-XPN-128, and GCM-AES-XPN-256?
- Does the key server properly derive SAK and KEK, and distribute SAK in MKPDU after wrapping with KEK?
- Does the key server properly advertise confidentiality offset, key number, AN, etc.?
- Does the key server initiate and distribute new SAK upon PN exhaustion?
- Does the key server continue to distribute SAKs until all CA members indicate that they are capable of receiving traffic with the new key?
These tests need to be done under various conditions to ensure full coverage. A third-party test tool specialized in creating these conditions, including corner cases, increases the quality of test execution. For example, a tester can allow a user to configure initial PN and wrap-around PN threshold to expedite SAK refresh. This provides great flexibility and efficiency to exercise boundary conditions.
Validate MKA session scale
MACsec devices can support multiple CAs, hence they need to manage multiple MKA instances per port or per system. Each CA (group CA) can have multiple members. it is important to validate the MKA session scale required by various customer deployment scenarios. The typical scale includes 32, 64, and all the way up to 256 CAs per port or per system, and up to 200 members in a CA, although the MKA standard mentioned a design goal of just 30 members in a CA. For each peer, MACsec devices need to authenticate MKPDU and keep track of message numbers from each member in the CA, hence increase the stress. Validation needs to consider the following:
- MKA sessions per port, per system
- Number of members supported per MKA session
- Mixed scale with multiple MKA sessions and multiple members per MKA session
- MKPDU handling with many peers with default Ethernet MTU, and Jumbo frame
- Keep track and properly provision SAKs for many MKA instances to difference CA and refresh SAK under scale condition
Similar to other standard control plane protocol testing, this kind of test must be done with a third-party test tool that provides emulation of many MACsec devices to effectively validate the scale without requiring many physical devices. This not only saves R&D costs but also improves the efficiency with ease of managing MACsec device emulation and many knobs to conduct scale tests under different permutation.
Validate MKA interaction with hardware
There are direct interactions between MKA and hardware periodically (every 2 seconds with the default hello timer), unlike most other control and data plane operations that operate standalone after the initial setup. The MACsec devices receive cipher suites and SAK through MKA (if non-key server) and then provision them to hardware for encryption/decryption. It indicates ready for receiving traffic with the SAK and advertises the lowest acceptable packet number for the latest key (LLPN) and older key (OLPN) so that the key server can generate and distribute a new SAK upon packet number (PN) reaching the upper boundary. Validation should provide answers to questions such as:
- Does the MACsec device extract received cipher suite and SAK correctly?
- Does the MACsec device provision the proper SAK for each CA when managing one or more CAs per port or per system?
- Does the MACsec device provision the new SAK properly without delay during SAK refresh?
- Does the MACsec device advertise SAK usage parameters correctly in MKA in sync with hardware under various traffic rates?
- Do the above functions continue to work as expected under scale?
MKA and hardware interaction is critical for successful MACsec operation. The integration test at the system level combines control plane and data plane validation and assesses the impact between them under various conditions to ensure robust implementation and reduce failure in the field. This cannot be done without a specialized third-party test tool.
Interoperability and negative test for MKA
Testing MKA interoperability between different implementations is essential to reduce issues in the field. A third-party test tool with comprehensive parameter settings can help validate interoperability and error handling with different implementations. Some of the example test cases include:
- Malformed MKPDU
- Out of order MKPDU
- Detect duplicate MAC address or SCI
- MKPDU sent to unicast destination instead of allocated multicast MAC 01:80:C2:00:00:03
- MKPDU with customized destination MAC and Ether-type
- MKPDU with unknown field
Apparently, these interoperability and negative tests cannot be done with back-to-back vendor devices. A third-party test tool with different implementation and rich parameter set for negative conditions greatly increases test coverage, ensures robustness, and reduces potential failure in the field.
Considering the above key validation areas and how to conduct quality tests, it is vital to test MKA implementation and hardware interaction with an effective third-party test tool to emulate various customer deployment scenarios and provide flexible control to create different conditions as needed. This helps to ensure complete test coverage, saves costs, and reduces time to market.
As a leader in the network test and measurement market, Keysight’s mission is to help our customers accelerate innovation to connect and secure the world. We offer a comprehensive MACsec test solution to help you overcome MACsec test challenges, stay competitive, and avoid major issues in the field. For more details about the Keysight solution, please review the MACsec Test Solution datasheet.