NIAP: View Technical Decision Details
NIAP/CCEVS
  NIAP  »»  Protection Profiles  »»  Technical Decisions  »»  View Details  
Archived TD0654:  MACsec data delay protection and updated conditional support for group CAK

Publication Date
2023.08.23

Protection Profiles
PP_NDCPP_MACSEC_EP_V1.2

Other References
FCS_MKA_EXT.1.2, FCS_MKA_EXT.1.5, FCS_MKA.1.8

Issue Description

A previous TD modifying assurance activities incorrectly assumed that group CAK would be selected in FCS_MKA_EXT.1.5, and implied that data delay protection was required for for MACsec frames instead of just MKA frames.

Resolution

This TD supersedes TD0618.

EP for MACSEC v1.2 is modified as follows:

FCS_MKA_EXT 1.2 is revised as follows and adds an Assurance Activity:

FCS_MKA_EXT.1.2 The TSF shall enable data delay protection for MKA that ensures MKA data frames are not delayed by more than 2 seconds.

Assurance Activity - Test         

The test below requires the TOE to be deployed in an environment with two MACsec-capable peers, identified as devices B and C, that the TOE can communicate with. Prior to performing these tests, the evaluator shall follow the steps in the guidance documentation to configure the TOE as the Key Server and principal actor. The evaluator shall then perform the following test:

The evaluator shall use a peer device to send traffic to the TOE, arbitrarily inducing artificial delays in their transmission using a man-in-the-middle setup. The evaluator shall observe that MKA frames delayed longer than 2.0 seconds are rejected.

 

FCS_MKA_EXT 1.5 is revised to add an Assurance Activity:

FCS_ MKA_EXT.1.5 The TSF shall enforce an MKA Lifetime Timeout limit of 6.0 seconds and MKA Bounded Hello Time limit of 0.5 seconds.

Application Note: The Key Server may distribute a group CAK established by pairwise CAKs.

Assurance Activity - Test         

The tests below require the TOE to be deployed in an environment with two MACsec-capable peers, identified as devices B and C, that the TOE can communicate with.

Prior to performing these tests, the evaluator shall follow the steps in the guidance documentation to configure the TOE as the Key Server and principal actor (peer). The evaluator shall then perform the following tests using a traffic sniffer to capture this traffic.

Test 1a: The evaluator shall configure the TOE to establish a MKA session with a new peer. The evaluator shall verify that the TOE sends a fresh SAK to the peer and sends other MKPDUs required for a new session. The evaluator shall verify from packet captures that MKPDUs are sent at least once every half-second. 

Test 1b: (Conditional - If "EAPTLS with DevIDs" is selected in FCS_MACSEC_EXT.4.1) The evaluator shall use EAP-TLS to derive a CAK and configure the TOE's peer to send "0" in the MKA parameter field for MACsec Capability (Table 11-6 in 802.1X-2020). The evaluator shall observe that the peer is deleted from the connected after MKA Life Time has passed.

Test 2: (Conditional - If "group CAK" is selected in FCS_MKA_EXT.1.6) The evaluator shall configure the TOE to send a fresh SAK with two peers as active participants. The evaluator shall verify that the TOE sends a fresh SAK to the peers and sends other MKPDUs required for a new session. The evaluator shall verify from packet captures that MKPDUs are sent at least one every half-second in accordance with the MKA Bounded Hello Time. Disconnect one of the peers. Arbitrarily introduce an artificial delay in sending a fresh SAK following the change in the Live Peer List. For this delayed fresh SAK, use a man-in-the-middle device to observe that the MKA Life Time of 6.0 seconds is enforced by the TSF.

 

FCS_MKA_EXT 1.8 is revised to reflect that Tests 1 & 2 are removed as tests were added more appropriately to  FCS_MKA_EXT.1.2 and FCS_MKA_EXT.1.5. Also, test 4 is revised to clarify that the TOE is the receiver and not the sender of the broken packets. Therefore, the test Assurance Activities for FCS_MKA_EXT.1.8 are as follows:

The tests below require the TOE to be deployed in an environment with two MACsec-capable peers, identified as devices B and C, that the TOE can communicate with. Prior to performing these tests, the evaluator shall follow the steps in the guidance documentation to configure the TOE as the Key Server and principal actor. The evaluator shall then perform the following tests:

Test 1 [conditional]: If the TOE supports group CAKs, the evaluator shall perform the following steps:

1. Load one PSK onto the TOE and device B and a second PSK onto the TOE and device C. This defines two pairwise CAs.

2. Generate a group CAK for the group of 3 devices using ieee8021XKayCreateNewGroup.

3. Observe via packet capture that the TOE distributes the group CAK to the two peers, protected by AES key wrap using their respective PSKs.

4. Verify that B can form a SA with C and connect securely.

5. Disable the KaY functionality of device C using ieee8021XPaePortKayMkaEnable.

6. Generate a group CAK for the TOE and B using ieee8021XKayCreateNewGroup and observe they can connect.

7. The evaluator shall have B attempt to connect to C and observe this fails.

8. Re-enable the KaY functionality of device C.

9. Invoke ieee8021XKayCreateNewGroup again.

10. Verify that both the TOE can connect to C and that B can connect to C.

 

Test 2: The evaluator shall start an MKA session between the TOE and the two environmental MACsec peers and then perform the following steps:

1. Send an MKPDU to the TOE's individual MAC address from a peer. Verify the frame is dropped and logged.

2. Send an MKPDU to the TOE that is less than 32 octets long. Verify the frame is dropped and logged.

3. Send an MKPDU to the TOE whose length in octets is not a multiple of 4. Verify the frame is dropped and logged.

4. Send an MKPDU to the TOE that is one byte short. Verify the frame is dropped and logged.

5. Send an MKPDU to the TOE with unknown Agility Parameter. Verify the frame is dropped and logged.

Justification

Tests 1 and 2 for MCS_MKA_EXT.1.5 were modified to make the group CAK tests conditional upon the selection and updated to address inconsistencies with the timeout limit, and MCS_MKA_EXT.1.2 and its test were modified to make clear that only MKA frames require data delay protection. All other aspects of TD0612 and their corresponding justifications remain intact.

 
 
Site Map              Contact Us              Home