NIAP: View Technical Decision Details
NIAP/CCEVS
  NIAP  »»  Protection Profiles  »»  Technical Decisions  »»  View Details  
TD0105:  MACsec Key Agreement

Publication Date
2016.09.13

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

The FCS_MKA_EXT.1 MACsec Key Agreement requirement includes the following test for FCS_ MKA_EXT.1.5 - "The TSF shall enforce an MKA Lifetime Timeout limit of 6.0 seconds and Hello Timeout limit of 2.0 seconds."  Based on both IEEE Std 802.1X-2010 and IEEE Std 802.1Xbx-2014 for the MKA participant timer values, the prescribed test is not clear if the delay is testing the various activities as defined in Table 9-3 of the Standards. In addition, for FCS_MKA_EXT.1.8 test 4, it is unclear whether the TOE is the sender or receiver of broken packets.

Resolution

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 data frames protected by MACsec 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 traffic delayed longer than 2.0 seconds is 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 1: The evaluator shall send a fresh SAK that includes both peers as active participants. The evaluator shall start an MKA session between the TOE and the two active participant peers and send MKPDUs.  The evaluator shall verify from packet captures that MKPDUs are sent at least once every half-second.

Test 2: Disconnect one of the peers. Using a man-in-the-middle device, arbitrarily introduce an artificial delay in sending a fresh SAK following the change in the Live Peer List. Repeat Test 1 delaying a fresh SAK for MKA Lifetime traffic and observe that the timeout 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: 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

For FCS_MKA_EXT.1.5, the intention behind including Test 2 was to enforce data delay protection of 2 seconds, but the author incompletely specified this as an SFR in EXT.1.2.  The requirement for data delay protection is derived from 802.1X, Section 9.1, requirement (k): “It allows its participants to ensure that the data frames protected by MACsec are not being delayed by more than 2 seconds.”  The part of the current Test 1 that tests for rejection of delayed packets should more appropriately go under EXT.1.2 as an assurance activity.

Section 9.10 states that to achieve a maximum delay of 2 seconds, it is necessary to send MKPDUs every half-second.

NOTE—Enforcement of bounded received delay necessitates transmission of MKPDUs at frequent (0.5 s) intervals, to meet a maximum data delay of 2 s while minimizing connectivity interruption due to the possibility of lost or delayed MKPDUs. MKPDU can therefore operate without data delay protection, to lessen its processing requirements.

This points to the timeout parameter MKA Bounded Hello Time of 0.5 seconds as the more appropriate requirement rather than setting the requirement of MKA Hello Time of 2.0 seconds.

For FCS_MKA_EXT.1.8, Test 4, the TOE is the receiver and not the sender of the broken packets.

 
 
Site Map              Contact Us              Home