PP-Module for MACsec Ethernet Encryption

Version: 1.0
2022-12-16
National Information Assurance Partnership

Revision History

Version	Date	Comment
1.0	2022-12-16	Initial Release

1 Introduction 1.1 Overview 1.2 Terms 1.2.1 Common Criteria Terms 1.2.2 Technical Terms 1.3 Compliant Targets of Evaluation 1.4 TOE Boundary 1.5 Use Cases 2 Conformance Claims 3 Security Problem Description 3.1 Threats 3.2 Assumptions 3.3 Organizational Security Policies 4 Security Objectives 4.1 Security Objectives for the TOE 4.2 Security Objectives for the Operational Environment 4.3 Security Objectives Rationale 5 Security Requirements 5.1 NDcPP Security Functional Requirements Direction 5.1.1 Modified SFRs 5.2 TOE Security Functional Requirements 5.2.1 Security Audit (FAU) 5.2.2 Cryptographic Support (FCS) 5.2.3 Identification and Authentication (FIA) 5.2.4 Security Management (FMT) 5.2.5 Protection of the TSF (FPT) 5.2.6 Trusted Path/Channels (FTP) 5.3 TOE Security Functional Requirements Rationale 6 Consistency Rationale 6.1 NDcPP 6.1.1 Consistency of TOE Type 6.1.2 Consistency of Security Problem Definition 6.1.3 Consistency of Objectives 6.1.4 Consistency of Requirements Appendix A - Optional SFRs A.1 Strictly Optional Requirements A.1.1 Identification and Authentication (FIA) A.1.2 Protection of the TSF (FPT) A.1.3 Trusted Path/Channels (FTP) A.2 Objective Requirements A.3 Implementation-based Requirements Appendix B - Selection-based Requirements B.1 Cryptographic Support (FCS) B.2 Security Management (FMT) Appendix C - Extended Component Definitions C.1 Extended Components Table C.2 Extended Component Definitions C.2.1 Cryptographic Support (FCS) C.2.1.1 FCS_MACSEC_EXT MACsec C.2.1.2 FCS_MKA_EXT MACsec Key Agreement C.2.1.3 FCS_DEVID_EXT Secure Device Identifiers C.2.1.4 FCS_EAPTLS_EXT EAP-TLS Protocol C.2.1.5 FCS_SNMP_EXT SNMP Protocol C.2.2 Identification and Authentication (FIA) C.2.2.1 FIA_PSK_EXT Pre-Shared Key Composition C.2.2.2 FIA_AFL_EXT Authentication Failure Handling C.2.3 Protection of the TSF (FPT) C.2.3.1 FPT_CAK_EXT Protection of CAK Data C.2.3.2 FPT_DDP_EXT Data Delay Protection C.2.3.3 FPT_RPL_EXT Replay Protection C.2.4 Security Management (FMT) C.2.4.1 FMT_SNMP_EXT SNMP Management Appendix D - Implicitly Satisfied Requirements Appendix E - Allocation of Requirements in Distributed TOEs Appendix F - Entropy Documentation and Assessment Appendix G - Acronyms Appendix H - Bibliography

1 Introduction

1.1 Overview

The scope of this Protection Profile Module (PP-Module) is to describe the security functionality of Media Access Control Security (MACsec) encryption in terms of the Common Criteria [CC] and to define functional and assurance requirements for such products. This PP-Module is intended for use with the following Base Protection Profiles (Base-PPs):

collaborative Protection Profile for Network Devices, Version 2.2e (NDcPP)

This Base-PP is valid because a device that implements MACsec encryption is a specific type of network device, and there is nothing about the implementation of MACsec that would prevent any of the security capabilities defined by the Base-PP from being satisfied.

A Target of Evaluation (TOE) that conforms to a PP-Configuration containing this PP-Module may be a ‘Distributed TOE’ as defined in the NDcPP. This PP-Module does not prohibit the TOE from implementing other security functionality in a distributed manner. For example, a TOE may be deployed in such a manner that distributed nodes establish MACsec connectivity with physically separated networks while a centralized management device is used to configure the behavior of individual nodes.

1.2 Terms

The following sections list Common Criteria and technology terms used in this document.

1.2.1 Common Criteria Terms

Assurance	Grounds for confidence that a TOE meets the SFRs [CC].
Base Protection Profile (Base-PP)	Protection Profile used as a basis to build a PP-Configuration.
Collaborative Protection Profile (cPP)	A Protection Profile developed by international technical communities and approved by multiple schemes.
Common Criteria (CC)	Common Criteria for Information Technology Security Evaluation (International Standard ISO/IEC 15408).
Common Criteria Testing Laboratory	Within the context of the Common Criteria Evaluation and Validation Scheme (CCEVS), an IT security evaluation facility accredited by the National Voluntary Laboratory Accreditation Program (NVLAP) and approved by the NIAP Validation Body to conduct Common Criteria-based evaluations.
Common Evaluation Methodology (CEM)	Common Evaluation Methodology for Information Technology Security Evaluation.
Distributed TOE	A TOE composed of multiple components operating as a logical whole.
Operational Environment (OE)	Hardware and software that are outside the TOE boundary that support the TOE functionality and security policy.
Protection Profile (PP)	An implementation-independent set of security requirements for a category of products.
Protection Profile Configuration (PP-Configuration)	A comprehensive set of security requirements for a product type that consists of at least one Base-PP and at least one PP-Module.
Protection Profile Module (PP-Module)	An implementation-independent statement of security needs for a TOE type complementary to one or more Base-PPs.
Security Assurance Requirement (SAR)	A requirement to assure the security of the TOE.
Security Functional Requirement (SFR)	A requirement for security enforcement by the TOE.
Security Target (ST)	A set of implementation-dependent security requirements for a specific product.
Target of Evaluation (TOE)	The product under evaluation.
TOE Security Functionality (TSF)	The security functionality of the product under evaluation.
TOE Summary Specification (TSS)	A description of how a TOE satisfies the SFRs in an ST.

1.2.2 Technical Terms

Carrier Ethernet	Metro Ethernet Forum (MEF) Carrier Ethernet standards define technology-agnostic layer-2 services. The standards include services aimed at end users (Subscriber Ethernet Services) and service providers (Operator Ethernet Services). Other related terms include Metro Ethernet Services, Provider Bridging and Provider Backbone Bridging.
Connectivity Association Key (CAK)	A symmetric key that is used as the master key for MACsec connectivity and is shared between connected MACsec endpoints.
Connectivity Association Key Name (CKN)	A unique identifier for a specific Connectivity Association Key.
Ethernet Private Line (EPL)	A service transporting customer data form one User Network Interface (UNI) to another UNI.
Ethernet Virtual Private Line (EVPL)	A Virtual Local Area Network (VLAN)-based service transporting customer data. The UNI is capable of service multiplexing.
Extended Packet Numbering (XPN)	A scheme that allows MACsec communications to persist using a single Secure Association Key for a larger number of frames to reduce overhead and latency associated with key agreement.
Extensible Authentication Protocol over LAN (EAPOL)	A port authentication protocol specified in IEEE 802.1X that is used to facilitate network authentication.
MACsec Key Agreement (MKA)	A key agreement protocol used for distribution of MACsec keys to distributed peers.
MACsec Protocol Data Unit (MPDU)	The basic MACsec frame structure that contains protcol and payload data.
Media Access Control (MAC) Security Entity	An entity (e.g., computer) that is implementing MACsec.
Media Access Control Security (MACsec)	A standard for connectionless data confidentiality and integrity protection at the data link layer of a network connection. Formally defined in IEEE 802.1AE.
Metro Ethernet Forum (MEF)	A non-profit international industry consortium.
Packet Number (PN)	A monotonically increasing value that is guaranteed to be unique for each MACsec frame transmitted using a given Secure Association Key (SAK)
SecTag	MAC Security Tag - a protocol header comprising a number of octets, beginning with an EtherType, that is prepended to the service data unit supplied by the client of the protocol and is used to provide security guarantees.
Secure Association (SA)	A mechanism that uses a SAK to provide the MACsec service guarantees and security services for a sequence of transmitted frames.
Secure Association Key (SAK)	A key derived from the CAK that is used to encrypt and decrypt traffic for a given SA.
Secure Channel (SC)	A unidirectional channel (one to one or one to many) that uses symmetric key cryptography to provide a (possibly long lived) Secure Channel.
Secure Device Identifier	A device authentication credential that can be used for EAPOL and is formally defined in IEEE 802.1AR.

1.3 Compliant Targets of Evaluation

This PP-Module specifically addresses MACsec, which allows authorized systems using Ethernet Transport to maintain confidentiality of transmitted data and to take measures against frames that are transmitted or modified by unauthorized devices.

MACsec protects communication between trusted components of the network infrastructure, thus protecting the network operation. It facilitates maintenance of correct network connectivity and services as well as isolation of denial of service attacks.

The hardware, firmware, and software of the MACsec device define the physical boundary. All of the security functionality is contained and executed within the physical boundary of the device. For example, given a device with an Ethernet card, the whole device is considered to be within the boundary.

Since this PP-Module builds on the NDcPP, conformant TOEs are obligated to implement the functionality required in the NDcPP along with the additional functionality defined in this PP-Module in response to the threat environment discussed later in this document.

1.4 TOE Boundary

The physical boundary for a TOE that conforms to this PP-Module is a hardware appliance that also provides generalized network device functionality, such as auditing, I&A, and cryptographic services for network communications. The TOE’s logical boundary includes all functionality required by the claimed Base-PP as well as the MACsec functionality and related capabilities that are defined in this PP-Module. Any functionality that is provided by the network device that is not relevant to the security requirements defined by this PP-Module or the Base-PP is considered to be outside the scope of the TOE.

1.5 Use Cases

A pair of MACsec devices connected by a physical medium can protect Ethernet frames switched or routed from one device to the other. The two MACsec devices are provided with a CAK and use the MKA protocol to create a secure tunnel. MKA is used by the two MACsec devices to agree upon MACsec keys. A policy should be installed to protect traffic between the devices, with the exception of the MKA or Ethernet control traffic such as Extensible Authentication Protocol (EAP) over LAN (EAPOL) frames.

This PP-Module defines two potential use cases for the MACsec TOE.

[USE CASE 1] Classic Hop by Hop Deployment

MACsec can be deployed in a hop by hop manner between Ethernet devices. Two devices will protect traffic originating in protected networks traversing an untrusted link between them. The devices will first exchange MKA frames, which serve to determine the peer is an authorized peer, and agree upon a shared key and MACsec ciphersuite used to set up a transmit (Tx) SA and a receive (Rx) SA. Once the SAs are set up, MACsec-protected frames traverse the unprotected link.

[USE CASE 2] Over Carrier Ethernet Services

In some markets network service providers have standardized their offerings according to various versions of the MEF specifications. One recent MEF specification is the “E-Line” (*) service type which is based on the use of point-to-point (P2P) Ethernet Virtual Circuits. A port-based service is known as an EPL and a VLAN-based service is known as an EVPL. EPL provides a P2P Ethernet virtual connection between a pair of dedicated user–network interfaces (UNIs), with a high degree of transparency. EVPL provides a P2P or point-to-multipoint connection between UNIs. A difference between the EVPL and EPL is the degree of transparency - while EPL is highly transparent, filtering only the pause frames, EVPL is required to either peer or drop most of the Layer 2 Control Protocols. The MEF has also defined other service types such as E-LAN and E-Tree.

(*) From MEF 6.3 – Subscriber Ethernet Services Definition – November 2019 – Table 3

2 Conformance Claims

Conformance Statement

This PP-Module inherits exact conformance as required from the specified Base-PP and as defined in the CC and CEM addenda for Exact Conformance, Selection-Based SFRs, and Optional SFRs (dated May 2017).

The following PP-Modules are allowed to be specified in a PP-Configuration with this PP-Module:

PP-Module for Stateful Traffic Filter Firewalls Version 1.4 + Errata 20200625 (MOD_FW)
PP-Module for Virtual Private Network (VPN) Gateways Version 1.2 (MOD_VPNGW)

CC Conformance Claims

This PP-Module is conformant to Parts 2 (extended) and 3 (conformant) of Common Criteria Version 3.1, Release 5 [CC].

Package Claims

This PP-Module does not claim conformance to any packages.

3 Security Problem Description

The security problem is described in terms of the threats that the TOE is expected to address, assumptions about its Operational Environment, and any organizational security policies that the TOE is expected to enforce.

3.1 Threats

The following threats that are defined in this PP-Module extend the threats that are defined by the Base-PP.

T.DATA_INTEGRITY

An attacker may modify data transmitted over the layer 2 link in a way that is not detected by the recipient.

Devices on a network may be exposed to attacks that attempt to corrupt or modify data in transit without authorization. If malicious devices are able to modify and replay data that is transmitted over a layer 2 link, then the data contained within the communications may be susceptible to a loss of integrity.

T.NETWORK_ACCESS

An attacker may send traffic through the TOE that enables them to access devices in the TOE’s operational environment without authorization.

A MACsec device may sit on the periphery of a network, which means that it may have an externally-facing interface to a public network. Devices located in the public network may attempt to exercise services located on the internal network that are intended to be accessed only from within the internal network or externally accessible only from specifically authorized devices. If the MACsec device allows unauthorized external devices access to the internal network, these devices on the internal network may be subject to compromise. Similarly, if two MACsec devices are deployed to facilitate end-to-end encryption of traffic that is contained within a single network, an attacker could use an insecure MACsec device as a method to access devices on a specific segment of that network such as an individual LAN.

T.UNTRUSTED_MACSEC_COMMUNICATION_CHANNELS

An attacker may acquire sensitive TOE or user data that is transmitted to or from the TOE because an untrusted communication channel causes a disclosure of data in transit.

A generic network device may be threatened by the use of insecure communications channels to transmit sensitive data. The attack surface of a MACsec device also includes the MACsec trusted channels. Inability to secure communications channels, or failure to do so correctly, would expose user data that is assumed to be secure to the threat of unauthorized disclosure.

3.2 Assumptions

These assumptions are made on the Operational Environment (OE) in order to be able to ensure that the security functionality specified in the PP-Mod can be provided by the TOE. If the TOE is placed in an OE that does not meet these assumptions, the TOE may no longer be able to provide all of its security functionality. All assumptions for the OE of the Base-PP also apply to this PP-Module. A.NO_THRU_TRAFFIC_PROTECTION is still operative, but only for the interfaces in the TOE that are defined by the Base-PP and not the PP-Module. This document does not define any additional assumptions.

3.3 Organizational Security Policies

An organization deploying the TOE is expected to satisfy the organizational security policy listed below in addition to all organizational security policies defined by the claimed Base-PP.

This document does not define any additional OSPs.

4 Security Objectives

4.1 Security Objectives for the TOE

O.AUTHENTICATION_MACSEC: To further address the issues associated with unauthorized disclosure of information, a compliant TOE’s authentication ability (MKA) will allow a MACsec peer to establish connectivity associations (CAs) with another MACsec peer. MACsec endpoints authenticate each other to ensure they are communicating with an authorized MAC Security Entity (SecY) entity.
Addressed by: FCS_MACSEC_EXT.4, FCS_MKA_EXT.1, FIA_PSK_EXT.1, FCS_DEVID_EXT.1 (selection-based), FCS_EAP-TLS_EXT.1 (selection-based)
O.AUTHORIZED_ADMINISTRATION: All network devices are expected to provide services that allow the security functionality of the device to be managed. The MACsec device, as a specific type of network device, has a refined set of management functions to address its specialized behavior. In order to further mitigate the threat of a compromise of its security functionality, the MACsec device prescribes the ability to limit brute-force authentication attempts by enforcing lockout of accounts that experience excessive failures and by limiting access to security-relevant data that administrators do not need to view.
Addressed by: FMT_SMF.1/MACSEC, FPT_CAK_EXT.1, FIA_AFL_EXT.1 (optional), FTP_TRP.1/MACSEC (optional), FMT_SNMP_EXT.1 (selection-based)
O.CRYPTOGRAPHIC_FUNCTIONS_MACSEC: To address the issues associated with unauthorized modification and disclosure of information, compliant TOEs will implement cryptographic capabilities. These capabilities are intended to maintain confidentiality and allow for detection and modification of data that is transmitted outside of the TOE.
Addressed by: FCS_COP.1/CMAC, FCS_COP.1/MACSEC, FCS_MACSEC_EXT.2, FCS_MACSEC_EXT.3, FTP_ITC.1/MACSEC, FTP_TRP.1/MACSEC (optional), FCS_SNMP_EXT.1 (selection-based)
O.PORT_FILTERING_MACSEC: To further address the issues associated with unauthorized network access, a compliant TOE’s port filtering capability will restrict the flow of network traffic through the TOE based on layer 2 frame characteristics and whether or not the traffic represents valid MACsec frames and MACsec Key Agreement Protocol Data Units (MKPDUs).
Addressed by: FCS_MACSEC_EXT.1, FIA_PSK_EXT.1, FPT_DDP_EXT.1
O.REPLAY_DETECTION: A MACsec device is expected to help mitigate the threat of MACsec data integrity violations by providing a mechanism to detect and discard replayed traffic for MPDUs.
Addressed by: FPT_RPL.1, FPT_RPL_EXT.1 (optional)
O.SYSTEM_MONITORING_MACSEC: To address the issues of administrators being able to monitor the operations of the MACsec device, compliant TOEs will implement the ability to log the flow of Ethernet traffic. Specifically, the TOE will provide the means for administrators to configure rules to ‘log’ when Ethernet traffic grants or restricts access. As a result, the ‘log’ will result in informative event logs whenever a match occurs. In addition, the establishment of security CAs is auditable, not only between MACsec devices, but also with MAC Security Key Agreement Entities (KaYs).
Addressed by: FAU_GEN.1/MACSEC
O.TSF_INTEGRITY: To mitigate the security risk that the MACsec device may fail during startup, it is required to fail-secure if any self-test failures occur during startup. This ensures that the device will only operate when it is in a known state.
Addressed by: FPT_FLS.1

4.2 Security Objectives for the Operational Environment

This PP-Module does not define any objectives for the OE. All objectives for the operational environment of the Base-PP also apply to this PP-Module. OE.NO_THRU_TRAFFIC_PROTECTION is still operative, but only for the interfaces in the TOE that are defined by the Base-PP and not the PP-Module.

4.3 Security Objectives Rationale

This section describes how the assumptions, threats, and organizational security policies map to the security objectives.

Table 1: Security Objectives Rationale
Threat, Assumption, or OSP	Security Objectives	Rationale
T.DATA_INTEGRITY	O.CRYPTOGRAPHIC_FUNCTIONS_MACSEC	The TOE mitigates the threat of data integrity violations by implementing cryptographic functionality that includes integrity protection.
T.DATA_INTEGRITY	O.REPLAY_DETECTION	The TOE mitigates the threat of data integrity violations by providing a mechanism to detect and discard replayed traffic for MPDUs.
T.NETWORK_ACCESS	O.PORT_FILTERING_MACSEC	The TOE’s port filtering capability reduces the threat of unauthorized access to devices in the TOE’s operational environment by restricting the flow of network traffic entering through the TOE interfaces based on layer 2 frame characteristics and whether or not the traffic represents valid MACsec frames and MKPDUs.
T.UNTRUSTED_MACSEC_COMMUNICATION_CHANNELS	O.CRYPTOGRAPHIC_FUNCTIONS_MACSEC	The TOE mitigates the threat of unauthorized disclosure of information via untrusted thru traffic by providing MKA authentication functions to authorize endpoints.
T.UNAUTHORIZED_ADMINISTRATOR_ACCESS (from NDcPP)	O.AUTHORIZED_ADMINISTRATION	The TOE further mitigates this threat originally defined in the Base-PP by defining additional management functions that require authorization and additional interfaces that can be used securely to execute management activities.
T.UNDETECTED_ACTIVITY (from NDcPP)	O.SYSTEM_MONITORING_MACSEC	The TOE further mitigates this threat originally defined in the Base-PP by implementing measures to generate audit records for security-relevant events that are specific to the functionality defined by this PP-Module.

5 Security Requirements

The following conventions are used for the completion of operations:

Refinement operation (denoted by bold text or ~~strikethrough text~~): Is used to add details to a requirement (including replacing an assignment with a more restrictive selection) or to remove part of the requirement that is made irrelevant through the completion of another operation, and thus further restricts a requirement.
Selection(denoted by italicized text): Is used to select one or more options provided by the [CC] in stating a requirement.
Assignment operation (denoted by italicized text): Is used to assign a specific value to an unspecified parameter, such as the length of a password. Showing the value in square brackets indicates assignment.
Iteration operation: Is indicated by appending the SFR name with a slash and unique identifier suggesting the purpose of the operation, e.g. "/EXAMPLE1."

5.1 NDcPP Security Functional Requirements Direction

In a PP-Configuration that includes the NDcPP,the TOE is expected to rely on some of the security functions implemented by theNetwork Device as a whole and evaluated against the NDcPP. The following sections describe any modifications that the ST author must make to the SFRs defined in the NDcPP in addition to what is mandated by section 5.2.

5.1.1 Modified SFRs

The SFRs listed in this section are defined in the NDcPP and are relevant to the secure operation of the TOE. This PP-Module does not modify any SFRs defined by the NDcPP.

5.2 TOE Security Functional Requirements

The following section describes the SFRs that must be satisfied by any TOE that claims conformance to this PP-Module.These SFRs must be claimed regardless of which PP-Configuration is used to define the TOE.

5.2.1 Security Audit (FAU)

FAU_GEN.1/MACSEC Audit Data Generation (MACsec)

FAU_GEN.1.1/MACSEC

The TSF shall be able to generate an audit record of the following auditable events:

Start-up and shutdown of the audit functions;
All auditable events for the [not specified] level of audit;
All administrative actions;
[Specifically defined auditable events listed in the Auditable Events table (Table 2)]

Requirement	Auditable Events	Additional Audit Record Contents
FCS_MACSEC_EXT.1	Session establishment	Secure Channel Identifier (SCI)
FCS_MACSEC_EXT.3	Creation and update of SAK	Creation and update times
FCS_MACSEC_EXT.4	Creation of CA	Connectivity Association Key Names (CKNs)
FPT_RPL.1	Detected replay attempt	None

Table 2: Auditable Events

FAU_GEN.1.2/MACSEC

The TSF shall record within each audit record at least the following information:

Date and time of the event, type of event, subject identity (if applicable), and the outcome (success or failure) of the event; and
For each audit event type, based on the auditable event definitions of the functional components included in the PP-Module/ST, [information specified in column three of the Auditable Events table (Table 2)].

5.2.2 Cryptographic Support (FCS)

FCS_COP.1/CMAC Cryptographic Operation (AES-CMAC Keyed Hash Algorithm)

FCS_COP.1.1/CMAC

The TSF shall perform [keyed-hash message authentication] in accordance with a specified cryptographic algorithm [AES-CMAC] and cryptographic key sizes [selection: 128, 256] bits and message digest size of 128 bits that meets the following: [NIST SP 800-38B].
Application Note: AES-CMAC is a keyed hash function that is used as part of the key derivation function (KDF) that is used for key generation.

Evaluation Activities

FCS_COP.1/CMAC

TSS

The evaluator shall examine the TSS to ensure that it specifies the following values used by the AES-CMAC function: key length, hash function used, block size, and output MAC length.

Guidance

There are no guidance evaluation activities (EAs) for this component.

Tests

The evaluator shall perform the following tests:

Test FCS_COP.1/CMAC:1:CMAC Generation Test
To test the generation capability of AES-CMAC, the evaluator shall provide to the TSF, for each key length-message length-CMAC length tuple (in bytes), a set of eight arbitrary key-plaintext tuples that will result in the generation of a known MAC value when encrypted. The evaluator shall then verify that the correct MAC was generated in each case.
Test FCS_COP.1/CMAC:2:CMAC Verification Test

To test the verification capability of AES-CMAC, the evaluator shall provide to the TSF, for each key length-message length-CMAC length tuple (in bytes), a set of 20 arbitrary key-MAC tuples that will result in the generation of known messages when verified. The evaluator shall then verify that the correct message was generated in each case.
The following information should be used by the evaluator to determine the key length-message length-CMAC length tuples that should be tested:
- Key length: Values will include the following:
  - 16
  - 32
- Message length: Values will include the following:
  - 0 (optional)
  - Largest value supported by the implementation (no greater than 65536)
  - Two values divisible by 16
  - Two values not divisible by 16
- CMAC length:
  - Smallest value supported by the implementation (no less than 1)
  - 16
  - Any supported CMAC length between the minimum and maximum values

FCS_COP.1/MACSEC Cryptographic Operation (MACsec AES Data Encryption and Decryption)

FCS_COP.1.1/MACSEC

The TSF shall perform [encryption and decryption] in accordance with a specified cryptographic algorithm [AES used in AES Key Wrap, GCM] and cryptographic key sizes [selection: 128, 256] bits that meets the following: [AES as specified in ISO 18033-3, AES Key Wrap as specified in NIST SP 800-38F, GCM as specified in ISO 19772].

Evaluation Activities

FCS_COP.1/MACSEC

TSS

The evaluator shall verify that the TSS describes the supported AES modes that are required for this PP-Module in addition to the ones already required by the NDcPP in FCS_COP.1/DataEncryption.

Guidance

There are no guidance EAs for this component.

Tests

The evaluator shall perform testing for AES-GCM as required by the NDcPP in FCS_COP.1/DataEncryption.

In addition to the tests specified in the NDcPP for other iterations of FCS_COP.1, the evaluator shall perform the following tests:

Test FCS_COP.1/MACSEC:1: KW-AE Test: To test the authenticated encryption capability of AES key wrap (KW), the evaluator shall provide five sets of 100 messages and keys to the TOE for each key length supported by the TSF. Each set of messages and keys shall correspond to one of five plaintext message lengths (detailed below). The evaluator shall have the TSF encrypt the messages with the associated key. The evaluator shall verify that the correct ciphertext was generated in each case.
Test FCS_COP.1/MACSEC:2: KW-AD Test: To test the authenticated decryption capability of AES KW, the evaluator shall provide five sets of 100 messages and keys to the TOE for each key length supported by the TSF. Each set of ciphertexts and keys shall correspond to one of five plaintext message lengths (detailed below). For each set of 100 ciphertext values, 20 shall not be authentic (i.e., fail authentication). The evaluator shall have the TSF decrypt the ciphertext messages with the associated key. The evaluator shall then verify the correct plaintext was generated or the failure to authenticate was correctly detected.
The messages in each set for both tests shall be the following lengths:
- two that are non-zero multiples of 128 bits (two semiblock lengths)
- two that are odd multiples of the semiblock length (64 bits)
- the largest supported plaintext length less than or equal to 4096 bits

FCS_MACSEC_EXT.1 MACsec

FCS_MACSEC_EXT.1.1

The TSF shall implement MACsec in accordance with IEEE Standard 802.1AE-2018.

FCS_MACSEC_EXT.1.2

The TSF shall derive a Secure Channel Identifier (SCI) from a peer’s MAC address and port to uniquely identify the originator of an MPDU.

FCS_MACSEC_EXT.1.3

The TSF shall reject any MPDUs during a given session that contain an SCI other than the one used to establish that session.

FCS_MACSEC_EXT.1.4

The TSF shall permit only EAPOL (Port Access Entity (PAE) EtherType 88-8E), MACsec frames (EtherType 88-E5), and MAC control frames (EtherType is 88-08) and shall discard others.
Application Note: Depending on the Carrier Ethernet service provider a TOE might need basic VLAN tag handling abilities such as a simple add or discard to be suitable for Use Case 2.

Evaluation Activities

FCS_MACSEC_EXT.1

TSS

The evaluator shall examine the TSS to verify that it describes the ability of the TSF to implement MACsec in accordance with IEEE 802.1AE-2018. The evaluator shall also determine that the TSS describes the ability of the TSF to derive SCI values from peer MAC address and port data and to reject traffic that does not have a valid SCI. Finally, the evaluator shall check the TSS for an assertion that only EAPOL, MACsec Ethernet frames, and MAC control frames are accepted by the MACsec interface.

Guidance

There are no guidance EAs for this component.

Tests

The evaluator shall perform the following tests:

Test FCS_MACSEC_EXT.1:1: The evaluator shall successfully establish a MACsec channel between the TOE and a MACsec-capable peer in the operational environment and verify that the TSF logs the communications. The evaluator shall capture the traffic between the TOE and the operational environment to determine the SCI that the TOE uses to identify the peer. The evaluator shall then configure a test system to capture traffic between the peer and the TOE to modify the SCI that is used to identify the peer. The evaluator then verifies that the TOE does not reply to this traffic and logs that the traffic was discarded.
Test FCS_MACSEC_EXT.1:2: The evaluator shall send Ethernet traffic to the TOE’s MAC address that iterates through the full range of supported EtherType values (refer to List of Documented EtherTypes) and observes that traffic for all EtherType values is discarded by the TOE except for the traffic which has an EtherType value of 88-8E, 88-E5, or 8808. Note that there are a large number of EtherType values so the evaluator is encouraged to execute a script that automatically iterates through each value.

FCS_MACSEC_EXT.2 MACsec Integrity and Confidentiality

FCS_MACSEC_EXT.2.1

The TOE shall implement MACsec with support for integrity protection with a confidentiality offset of [selection: 0, 30, 50].

FCS_MACSEC_EXT.2.2

The TSF shall provide assurance of the integrity of protocol data units (MPDUs) using an Integrity Check Value (ICV) derived with the SAK.
Application Note: The length of the ICV is dependent on the ciphersuite used but will not be less than 8 octets or more than 16 octets at the end of the MPDU. The ICV protects the destination and source MAC address parameters, as well as all the fields of the MPDU.

FCS_MACSEC_EXT.2.3

The TSF shall provide the ability to derive an Integrity Check Value Key (ICK) from a Connectivity Association Key (CAK) using a KDF.

FCS_MACSEC_EXT.3 MACsec Randomness

FCS_MACSEC_EXT.3.1

The TSF shall generate unique Secure Association Keys (SAKs) using [selection: key derivation from Connectivity Association Key (CAK) per section 9.8.1 of IEEE 802.1X-2010, the TOE’s random bit generator as specified by FCS_RBG_EXT.1] such that the likelihood of a repeating SAK is no less than 1 in 2 to the power of the size of the generated key.

FCS_MACSEC_EXT.3.2

The TSF shall generate unique nonces for the derivation of SAKs using the TOE’s random bit generator as specified by FCS_RBG_EXT.1.
Application Note: FCS_RBG_EXT.1 is defined in the Base-PP so a conformant MACsec TOE will include this dependency.

FCS_MACSEC_EXT.4 MACsec Key Usage

FCS_MACSEC_EXT.4.1

The TSF shall support peer authentication using pre-shared keys (PSKs) [selection: EAP-TLS with DevIDs, no other method].
Application Note: The definition of the peer’s CAK as defined by IEEE 802.1X-2010 is synonymous with the peer authentication performed here. If "EAP-TLS with DevIDs" is selected, the FCS_DEVID_EXT.1 and FCS_EAPTLS_EXT.1 SFRs must be claimed.

FCS_MACSEC_EXT.4.2

The TSF shall distribute SAKs between MACsec peers using AES key wrap as specified in FCS_COP.1/MACSEC.
Application Note: This requirement applies to the SAKs that are generated by the TOE. They must be wrapped by the AES Key Wrap method specified in NIST SP 800-38F.

FCS_MACSEC_EXT.4.3

The TSF shall support specifying a lifetime for CAKs.

FCS_MACSEC_EXT.4.4

The TSF shall associate Connectivity Association Key Names (CKNs) with SAKs that are defined by the KDF using the CAK as input data (per IEEE 802.1X-2010, Section 9.8.1).

FCS_MACSEC_EXT.4.5

The TSF shall associate CKNs with CAKs. The length of the CKN shall be an integer number of octets, between 1 and 32 (inclusive).

Evaluation Activities

FCS_MACSEC_EXT.4

TSS

The evaluator shall check the TSS to ensure that it describes how the SAK is wrapped prior to being distributed using the AES implementation specified in this PP-Module.

Guidance

If the method of peer authentication is configurable, the evaluator shall verify that the guidance provides instructions on how to configure this. The evaluator shall also verify that the method of specifying a lifetime for CAKs is described.

Tests

The evaluator shall perform the following tests:

Test FCS_MACSEC_EXT.4:1: For each supported method of peer authentication in FCS_MACSEC_EXT.4.1, the evaluator shall follow the operational guidance to configure the supported method (if applicable). The evaluator shall set up a packet sniffer between the TOE and a MACsec-capable peer in the operational environment. The evaluator shall then initiate a connection between the TOE and the peer such that authentication occurs and a secure connection is established. The evaluator shall wait one minute and then disconnect the TOE from the peer and stop the sniffer. The evaluator shall use the packet captures to verify that the SC was established via the selected mechanism and that the non-VLAN EtherType of the first data frame sent between the TOE and the peer is 88-E5.
Test FCS_MACSEC_EXT.4:2: The evaluator shall capture traffic between the TOE and a MACsec-capable peer in the operational environment. The evaluator shall then cause the TOE to distribute a SAK to that peer, capture the MKPDUs from that operation, and verify the key is wrapped in the captured MKPDUs.

FCS_MKA_EXT.1 MACsec Key Agreement

FCS_MKA_EXT.1.1

The TSF shall implement Key Agreement Protocol (MKA) in accordance with IEEE 802.1X-2010 and 802.1Xbx-2014.

FCS_MKA_EXT.1.2

The TSF shall provide assurance of the integrity of MKA protocol data units (MKPDUs) using an Integrity Check Value (ICV) derived from an Integrity Check Value Key (ICK).
Application Note: The ICV has length 128 bits and is computed according to Section 9.4.1 of IEEE 802.1X-2010. The ICV protects the destination and source MAC address parameters, as well as all the fields of the MAC Service Data Unit of the MKPDU including the allocated EtherType, and up to but not including, the generated ICV.

FCS_MKA_EXT.1.3

The TSF shall provide the ability to derive an Integrity Check Value Key (ICK) from a CAK using a KDF.

FCS_MKA_EXT.1.4

The TSF shall enforce an MKA Lifetime Timeout limit of 6.0 seconds and MKA Bounded Hello Timeout limit of 0.5 seconds.
Application Note: The key server may also distribute a group CAK established by pairwise CAKs.

FCS_MKA_EXT.1.5

The key server shall refresh a SAK when it expires. The key server shall distribute a SAK by [selection: a group CAK, distributed by a group CAKa group CAK, distributed by pairwise CAKs derived from MKAa group CAK, distributed by pre-shared key (PSK)pairwise CAKs, derived from MKApairwise CAKs that are PSKs].

FCS_MKA_EXT.1.6

The key server shall distribute a fresh SAK whenever a member is added to or removed from the live membership of the CA.

FCS_MKA_EXT.1.7

The TSF shall validate MKPDUs according to IEEE 802.1X-2010 Section 11.11.2. In particular, the TSF shall discard without further processing any MKPDUs to which any of the following conditions apply:

The destination address of the MKPDU was an individual address
The MKPDU is less than 32 octets long
The MKPDU comprises fewer octets than indicated by the Basic Parameter Set body length, as encoded in bits 4 through 1 of octet 3 and bits 8 through 1 of octet 4, plus 16 octets of ICV
The CAK Name is not recognized

If an MKPDU passes these tests, then the TSF will begin processing it as follows:

If the Algorithm Agility parameter identifies an algorithm that has been implemented by the receiver, the ICV shall be verified as specified in IEEE 802.1X-2010 Section 9.4.1.
If the Algorithm Agility parameter is unrecognized or not implemented by the receiver, its value can be recorded for diagnosis but the received MKPDU shall be discarded without further processing.

Each received MKPDU that is validated as specified in this clause and verified as specified in IEEE 802.1X-2010 Section 9.4.1 shall be decoded as specified in IEEE 802.1X-2010 Section 11.11.4.

Evaluation Activities

FCS_MKA_EXT.1.3

TSS

The evaluator shall examine the TSS to verify that it describes the methods that the TOE implements to provide assurance of MKA integrity, including the use of an ICV and the ability to use a KDF to derive an ICK.

Guidance

There are no guidance EAs for this element.

Tests

The evaluator shall perform the following tests:

Test FCS_MKA_EXT.1.3:1: The evaluator shall transmit MKA traffic (MKPDUs) to the TOE from an MKA-capable peer in the operational environment. The evaluator shall verify via packet captures, audit logs, or both that the last 16 octets of the MKPDUs in the received traffic do not appear to be predictable.
Test FCS_MKA_EXT.1.3:2: The evaluator shall transmit valid MKA traffic to the TOE from an MKA-capable peer in the operational environment that is routed through a test system set up as a man-in-the-middle. The evaluator shall use the test system to intercept this traffic to modify one bit in a packet payload before retransmitting to the TOE. The evaluator shall verify that the traffic is discarded due to an integrity failure.

FCS_MKA_EXT.1.4

TSS

There are no TSS EAs for this element.

Guidance

There are no guidance EAs for this element.

Tests

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:

Test FCS_MKA_EXT.1.4: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 FCS_MKA_EXT.1.4: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.7

TSS

The evaluator shall verify that the TSS describes the TOE’s compliance with IEEE 802.1X-2010 and 802.1Xbx-2014 for MKA, including the values for MKA and Hello timeout limits and support for data delay protection. The evaluator shall also verify that the TSS describes the ability of the PAE of the TOE to establish unique CAs with individual peers and group CAs using a group CAK such that a new group SAK is distributed every time the group’s membership changes. The evaluator shall also verify that the TSS describes the invalid MKPDUs that are discarded automatically by the TSF in a manner that is consistent with the SFR, and that valid MKPDUs are decoded in a manner consistent with IEEE 802.1X-2010 section 11.11.4.

Guidance

The evaluator shall verify that the guidance documentation provides instructions on how to configure the TOE to act as the key server in an environment with multiple MACsec-capable devices.

Tests

Test FCS_MKA_EXT.1.7: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 three 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 an 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 FCS_MKA_EXT.1.7: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 four. 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.

5.2.3 Identification and Authentication (FIA)

FIA_PSK_EXT.1 Pre-Shared Key Composition

FIA_PSK_EXT.1.1

The TSF shall use PSKs for MKA as defined by IEEE 802.1X-2010, [selection: no other protocols, [assignment: other protocols that use PSKs]].
Application Note: If other protocols can use PSKs, they should be listed in the assignment as well; otherwise “no other protocols” should be chosen.

FIA_PSK_EXT.1.2

The TSF shall be able to [selection: accept, generate using the random bit generator specified in FCS_RBG_EXT.1] bit-based PSKs.
Application Note: The ST author specifies whether the TSF merely accepts bit-based PSKs or if it is also capable of generating them. If it generates them, the requirement specifies that they must be generated using the RBG provided by the TOE.

Evaluation Activities

FIA_PSK_EXT.1

TSS

The evaluator shall examine the TSS to ensure it describes the process by which the bit-based PSKs are generated (if the TOE supports this functionality), and confirm that this process uses the RBG specified in FCS_RBG_EXT.1.

Guidance

The evaluator shall examine the operational guidance to determine that it provides guidance to administrators on the composition of strong PSKs, and (if the selection indicates keys of various lengths can be entered) that it provides information on the range of lengths supported.

The evaluator shall confirm the operational guidance contains instructions for either entering bit-based PSKs for each protocol identified in the requirement, generating a bit-based PSK, or both.

Tests

The evaluator shall also perform the following tests for each protocol (or instantiation of a protocol, if performed by a different implementation on the TOE). Note that one or more of these tests can be performed with a single test case.

Test FIA_PSK_EXT.1:1: (conditional, the TOE supports PSKs of multiple lengths) The evaluator shall use the minimum length, the maximum length, a length inside the allowable range, and invalid lengths beyond the supported range (both higher and lower). The minimum, maximum, and included length tests should be successful, and the invalid lengths must be rejected by the TOE.
Test FIA_PSK_EXT.1:2: (conditional, the TOE does not generate bit-based PSKs) The evaluator shall obtain a bit-based PSK of the appropriate length and enter it according to the instructions in the operational guidance. The evaluator shall then demonstrate that a successful protocol negotiation can be performed with the key.
Test FIA_PSK_EXT.1:3: (conditional, the TOE can generate bit-based PSKs) The evaluator shall generate a bit-based PSK of the appropriate length and use it according to the instructions in the operational guidance. The evaluator shall then demonstrate that a successful protocol negotiation can be performed with the key.

5.2.4 Security Management (FMT)

FMT_SMF.1/MACSEC Specification of Management Functions (MACsec)

FMT_SMF.1.1/MACSEC

The TSF shall be capable of performing the following management functions related to MACsec functionality: [Ability of a Security Administrator to:

Manage a PSK-based CAK and install it in the device

Manage the key server to create, delete, and activate MKA participants [selection: as specified in IEEE 802.1X-2020, Sections 9.13 and 9.16 (cf. MIB object ieee8021XKayMkaParticipant Entry) and section 12.2 (cf. function createMKA(), [assignment: other management function]]

Specify the lifetime of a CAK

Enable, disable, or delete a PSK-based CAK using [selection: the MIB object ieee8021XKayMkaPartActivateControl, [assignment: other management function]]

[selection: Cause key server to generate a new group CAK (i.e., rekey the CA) using [selection: MIB object ieee8021XKayCreateNewGroup, [assignment: other management function]]Manage generation of a PSK-based CAKNo other MACsec management functions]].
Application Note:

IEEE 802.1X-2010 specifies Management Information Base (MIB) objects for management functionality but configuration of management functions via other approved methods is acceptable. The ST author should select either the MIB object or provide the function used to achieve this management functionality.

If a selection containing “group CAK” is chosen in FCS_MKA_EXT.1.5, then “Cause key server to generate a new group CAK…” must be selected.

Evaluation Activities

FMT_SMF.1/MACSEC

TSS

The evaluator shall verify that the TSS describes the ability of the TOE to provide the management functions defined in this SFR.

Guidance

The evaluator shall examine the operational guidance to determine that it provides instructions on how to perform each of the management functions defined in this SFR.

Tests

The evaluator shall set up an environment where the TOE can connect to two other MACsec devices, identified as devices B and C, with the ability of PSKs to be distributed between them. The evaluator shall configure the devices so that the TOE will be elected key server and principal actor, i.e., has highest key server priority.

The evaluator shall follow the relevant operational guidance to perform the tests listed below. Note that if the TOE claims multiple management interfaces, the tests should be performed for each interface that supports the functions.

Test FMT_SMF.1/MACSEC:1: The evaluator shall connect to the PAE of the TOE and install a PSK. The evaluator shall then specify a CKN and that the PSK is to be used as a CAK.
- Repeat this test for both 128-bit and 256-bit key sizes.
- Repeat this test for a CKN of valid length (1-32 octets), and observe success.
- Repeat this test again for CKN of invalid lengths zero and 33, and observe failure.
Test FMT_SMF.1/MACSEC:2: The evaluator shall test the ability of the TOE to enable and disable MKA participants using the management function specified in the ST. The evaluator shall install PSKs in devices B and C, and take any necessary additional steps to create corresponding MKA participants. The evaluator shall disable the MKA participant on device C, then observe that the TOE can communicate with B but neither the TOE nor B can communicate with device C. The evaluator shall re-enable the MKA participant of device B and observe that the TOE is now able to communicate with devices B and C.
Test FMT_SMF.1/MACSEC:3: For TOEs using only PSKs, the TOE should be the key server in both tests and only one peer (B) needs to be tested. The tests are:
- Test FMT_SMF.1/MACSEC:3.1: Switch to unexpired CKN: TOE and Peer B have CKN1(10 minutes) and CKN2. CKN2 can either be configured with a longer overlapping lifetime (20 minutes) or be configured with a lifetime starting period of more than 10 minutes after the CKN1 start. The TOE and Peer B start using CKN1 and after 10 minutes, verify that the TOE expires SAK1. This can be verified by either 1) seeing the TOE immediately distribute a new SAK to the peer if the lifetime of CKN2 overlaps CKN1, or 2) by terminating the connection with CKN1 and distributing a new SAK once the lifetime period of CKN2 begins.
- Test FMT_SMF.1/MACSEC:3.2: Reject CA with expired CKN: TOE has CKN1 (10 minutes). Peer B has CKN1 (20 minutes). TOE and Peer B start using CKN1 and after 10 minutes, verify that the TOE rejects (or ignores) peer’s request to use (or distribute) a SAK using CKN1.
Test FMT_SMF.1/MACSEC:4: (conditional, "Cause key server to generate a new group CAK..." is selected) The evaluator shall connect to the PAE of the TOE, set the management function specified in the ST (e.g., set ieee8021XKayCreateNewGroup to true), and observe that the TOE distributes a new group CAK.

5.2.5 Protection of the TSF (FPT)

FPT_CAK_EXT.1 Protection of CAK Data

FPT_CAK_EXT.1.1

The TSF shall prevent reading of CAK values by administrators.
Application Note: The intent is for the TOE to protect CAK data from unauthorized disclosure. This data should only be accessed for the purposes of its assigned security functionality and there is no need for it to be displayed or accessed at any other time. This requirement does not prevent the device from providing indication that these exist, are in use, or are still valid. It does, however, restrict the reading of the values outright.

FPT_FLS.1 Failure with Preservation of Secure State

FPT_FLS.1.1

The TSF shall fail-secure when any of the following types of failures occur: [failure of the power-on self-tests, failure of integrity check of the TSF executable image, failure of noise source health tests].
Application Note: The intent of this requirement is to express the fail secure capabilities that the TOE possesses. This means that the TOE must be able to attain a secure/safe state (shutdown) when any of the identified failures occur. For a TOE with redundant failover capability (that continues to operate if power-on self-test (POST) passes on the redundant component), in the event of a POST failure on a redundant component, the specific component that received the POST failure will be shut down. For conformance with other PP-Modules it might be a requirement for the fail-secure state to be “shut down.”

FPT_RPL.1 Replay Detection

FPT_RPL.1.1

The TSF shall detect replay for the following entities: [MPDUs, MKA frames].

FPT_RPL.1.2

The TSF shall perform [discarding of the replayed data, logging of the detected replay attempt] when replay is detected.
Application Note: As per IEEE 802.1AE-2018, replay is detected by examining the PN value that is embedded in the SecTag that is at the header of the MPDU. The PN is encoded in octets 5 through 8 of the SecTag to support replay protection.

Evaluation Activities

FPT_RPL.1

TSS

The evaluator shall examine the TSS to determine that it describes how replay is detected for MPDUs and how replayed MPDUs are handled by the TSF.

Guidance

There are no guidance EAs for this component.

Tests

The evaluator shall perform the following tests:

Before performing each test, the evaluator shall successfully establish a MACsec channel between the TOE and a MACsec-capable peer in the operational environment sending enough traffic to see it working and verify the PN values increase for each direction.

Test FPT_RPL.1:1: The evaluator shall set up a MACsec connection with an entity in the operational environment. The evaluator shall then capture traffic sent from this remote entity to the TOE. The evaluator shall retransmit copies of this traffic to the TOE in order to impersonate the remote entity where the PN values in the SecTag of these packets are less than the lowest acceptable PN for the SA. The evaluator shall observe that the TSF does not take action in response to receiving these packets and that the audit log indicates that the replayed traffic was discarded.
The evaluator shall establish a MACsec connection between the TOE and a test system. The evaluator shall then capture traffic sent from the test system to the TOE. The evaluator shall retransmit copies of this traffic to the TOE in order to impersonate the remote entity where the PN values in the SecTag of these packets are less than the lowest acceptable PN for the SA. The evaluator shall observe that the TSF does not take action in response to receiving these packets and that the audit log indicates that the replayed traffic was discarded.
Test FPT_RPL.1:2: The evaluator shall capture frames during an MKA session and record the lowest PN observed in a particular time range. The evaluator shall then send a frame with a lower PN, and then verify that this frame is dropped. The evaluator shall verify that the device logged this event.

5.2.6 Trusted Path/Channels (FTP)

FTP_ITC.1/MACSEC Inter-TSF Trusted Channel (MACsec Communications)

FTP_ITC.1.1/MACSEC

The TSF shall provide a communication channel between itself and a MACsec peer that is logically distinct from other communication channels and provides assured identification of its end points and protection of the channel data from modification or disclosure.

FTP_ITC.1.2/MACSEC

The TSF shall permit [selection: the TSF, another trusted IT product] to initiate communication via the trusted channel.

FTP_ITC.1.3/MACSEC

The TSF shall initiate communication via the trusted channel for [communications with MACsec peers that require the use of MACsec].

5.3 TOE Security Functional Requirements Rationale

The following rationale provides justification for each security objective for the TOE, showing that the SFRs are suitable to meet and achieve the security objectives:

Table 3: SFR Rationale
Objective	Addressed by	Rationale
O.AUTHENTICATION_MACSEC	FCS_MACSEC_EXT.4	This SFR helps satisfy the TOE objective by defining the methods used for MACsec peer authentication and the handling of MACsec keys.
	FCS_MKA_EXT.1	This SFR helps satisfy the TOE objective by defining the method used to perform MACsec key agreement.
	FIA_PSK_EXT.1	This SFR helps satisfy the TOE objective by defining requirements for the composition and use of PSKs that can be used for MACsec peer authentication.
	FCS_DEVID_EXT.1 (selection-based)	This SFR helps satisfy the TOE objective by optionally implementing DevIDs as a method for authenticating MACsec peers.
	FCS_EAPTLS_EXT.1 (selection-based)	This SFR helps satisfy the TOE objective by optionally implementing EAP-TLS as a method for authenticating MACsec peers.
O.AUTHORIZED_ADMINISTRATION	FMT_SMF.1/MACSEC	This SFR helps satisfy the TOE objective by defining management functions that are applicable to MACsec functionality.
	FPT_CAK_EXT.1	This SFR helps satisfy the TOE objective by protecting data that could be used to compromise the security of remote administration.
	FIA_AFL_EXT.1 (optional)	This SFR helps satisfy the TOE objective by optionally enforcing specific limitations on how the TSF throttles local authentication attempts to prevent brute-force impersonation.
	FTP_TRP.1/MACSEC (optional)	This SFR helps satisfy the TOE objective by defining an optional method of remote administration for the management functionality defined in this PP-Module.
	FMT_SNMP_EXT.1 (selection-based)	This SFR helps satisfy the TOE objective by defining how Simple Network Management Protocol (SNMP) must be securely implemented if it is used for remote administration.
O.CRYPTOGRAPHIC_FUNCTIONS_MACSEC	FCS_COP.1/CMAC	This SFR helps satisfy the TOE objective by defining the AES-CMAC algorithm that is used for MACsec communications.
	FCS_COP.1/MACSEC	This SFR helps satisfy the TOE objective by defining the AES Key Wrap algorithm that is used for MACsec communications.
	FCS_MACSEC_EXT.2	This SFR helps satisfy the TOE objective by implementing integrity protection for MACsec.
	FCS_MACSEC_EXT.3	This SFR helps satisfy the TOE objective by randomizing keys used for MACsec with sufficient entropy.
	FTP_ITC.1/MACSEC	This SFR helps satisfy the TOE objective by defining the ability of the TOE to interact with external entities using MACsec, which is a cryptographically-secured communications channel.
	FTP_TRP.1/MACSEC (optional)	This SFR helps satisfy the TOE objective by defining additional optional methods of secure remote administration for the TOE beyond those specified in the Base-PP.
	FCS_SNMP_EXT.1 (selection-based)	This SFR helps satisfy the TOE objective by ensuring that SNMP, if implemented, is implemented securely using TLS.
O.PORT_FILTERING_MACSEC	FCS_MACSEC_EXT.1	This SFR helps satisfy the TOE objective by implementing MACsec functionality in such a way that only authorized packet frames are permitted.
	FIA_PSK_EXT.1	This SFR helps satisfy the TOE objective by using PSKs to determine which connections are authenticated and should therefore not be filtered.
	FPT_DDP_EXT.1 (optional)	This SFR adds a time-based port filtering function.
O.REPLAY_DETECTION	FPT_RPL.1	This SFR helps satisfy the TOE objective by requiring the TSF to detect and discard replayed MACsec traffic.
O.REPLAY_DETECTION	FPT_RPL_EXT.1 (optional)	This SFR helps satisfy the TOE objective by optionally defining the ability of the TSF to use XPN for replay detection.
O.SYSTEM_MONITORING_MACSEC	FAU_GEN.1/MACSEC	This SFR helps satisfy the TOE objective by defining auditable events for security-relevant functions that are specific to this PP-Module.
O.TSF_INTEGRITY	FPT_FLS.1	This SFR helps satisfy the TOE objective by defining a fail-secure method that preserves the integrity of the TSF by ensuring that it does not operate when it’s in an insecure or unknown state.

6 Consistency Rationale

6.1 NDcPP

6.1.1 Consistency of TOE Type

When this PP-Module is used to extend the NDcPP, the TOE type for the overall TOE is still a network device. The TOE boundary is simply extended to include MACsec functionality that is provided by the network device.

6.1.2 Consistency of Security Problem Definition

The threats defined by this PP-Module (see section 3.1) supplement those defined in the NDcPP as follows:

PP-Module Threat, Assumption, OSP	Consistency Rationale
T.DATA_INTEGRITY	The threat of data integrity compromise at the layer 2 level is a specific threat that can be countered by MACsec technology.
T.NETWORK_ACCESS	The threat of a malicious entity accessing protected network resources without authorization is a specific example of the T.UNTRUSTED_COMMUNICATION_CHANNELS threat defined in the Base-PP.
T.UNTRUSTED_MACSEC_COMMUNICATION_CHANNELS	The threat of disclosure of data in protected communications channels is the same as the T.UNTRUSTED_COMMUNICATION_CHANNELS threat in the NDcPP. This PP-Module expands on that by introducing additional logical interfaces (MACsec, SNMP) that this threat applies to.

6.1.3 Consistency of Objectives

The objectives for the TOEs are consistent with the NDcPP based on the following rationale:

PP-Module TOE Objective	Consistency Rationale
O.AUTHENTICATION_MACSEC	The Base-PP does not define any TOE objectives so PP-Module objectives do not conflict with it.
O.AUTHORIZED_ADMINISTRATION	The Base-PP does not define any TOE objectives so PP-Module objectives do not conflict with it.
O.CRYPTOGRAPHIC_FUNCTIONS_MACSEC	The Base-PP does not define any TOE objectives so PP-Module objectives do not conflict with it.
O.PORT_FILTERING_MACSEC	The Base-PP does not define any TOE objectives so PP-Module objectives do not conflict with it.
O.REPLAY_DETECTION	The Base-PP does not define any TOE objectives so PP-Module objectives do not conflict with it.
O.SYSTEM_MONITORING_MACSEC	The Base-PP does not define any TOE objectives so PP-Module objectives do not conflict with it.
O.TSF_INTEGRITY	The Base-PP does not define any TOE objectives so PP-Module objectives do not conflict with it.

This PP-Module does not define any environmental objectives, but does note that OE.NO_THRU_TRAFFIC_PROTECTION from the NDcPP only applies to the Base-PP external interfaces. This is because the MACsec interface defined by this PP-Module does enforce through-traffic protection.

6.1.4 Consistency of Requirements

This PP-Module identifies several SFRs from theNDcPP that are needed to support MACsec Ethernet Encryption functionality. This is considered to be consistent because the functionality provided by theNDcPP is being used for its intended purpose. The rationale for why this does not conflict with the claims defined by the NDcPP are as follows:

PP-Module Requirement	Consistency Rationale
Modified SFRs
This PP-Module does not modify any requirements when the NDcPP is the base.
Additional SFRs
This PP-Module does not levy any addition requirements when the NDcPP is the base.
Mandatory SFRs
FAU_GEN.1/MACSEC	This SFR is an iteration of a Base-PP requirement that defines additional auditable events for MACsec functionality that the Base-PP could not be expected to cover.
FCS_COP.1/CMAC	This PP-Module iterates an SFR defined in the Base-PP to define new cryptographic operations that are specific to the protocols defined in the PP-Module.
FCS_COP.1/MACSEC	This PP-Module iterates an SFR defined in the Base-PP to define new cryptographic operations that are specific to the protocols defined in the PP-Module.
FCS_MACSEC_EXT.1	This SFR applies to MACsec functionality, which is beyond the original scope of the Base-PP.
FCS_MACSEC_EXT.2	This SFR applies to MACsec functionality, which is beyond the original scope of the Base-PP.
FCS_MACSEC_EXT.3	This SFR applies to MACsec functionality, which is beyond the original scope of the Base-PP.
FCS_MACSEC_EXT.4	This SFR applies to MACsec functionality, which is beyond the original scope of the Base-PP.
FCS_MKA_EXT.1	This SFR applies to a MACsec peer authentication mechanism, which is beyond the original scope of the Base-PP, though it is based on the TLS implementation specified in the Base-PP.
FIA_PSK_EXT.1	This SFR applies to PSKs for MKA, which is beyond the original scope of the Base-PP.
FMT_SMF.1/MACSEC	This SFR applies to management functions related to MACsec, which is beyond the original scope of the Base-PP.
FPT_CAK_EXT.1	This SFR requires that keys specific to MACsec be protected. This is similar to FPT_SKP_EXT.1 in the Base-PP but applies to keys that were beyond the original scope of the Base-PP.
FPT_FLS.1	This SFR requires the TSF to react in a specific manner upon failure of specific self-tests. The Base-PP defines FPT_TST_EXT.1 for self-test functionality, but does not define specific self-tests. This PP-Module implies that certain self-tests must be done at minimum, but this does not conflict with what is permitted by the Base-PP.
FPT_RPL.1	This SFR applies to replay detection functionality, which is beyond the original scope of the Base-PP.
FTP_ITC.1/MACSEC	This PP-Module defines an additional trusted channel function for MACsec communications, which is beyond the original scope of the Base-PP.
Optional SFRs
FIA_AFL_EXT.1	This SFR defines a specific authentication limiting mechanism that exists on top of what FIA_AFL.1 in the Base-PP may also require.
FPT_DDP_EXT.1	Data delay protection uses packet counting information from MKA packets to drop differentially delayed MACsec packets at the receiver.
FPT_RPL_EXT.1	This SFR applies to replay detection functionality, which is beyond the original scope of the Base-PP.
FTP_TRP.1/MACSEC	This PP-Module defines an optional method of administration for MACsec functionality using trusted protocols that are not defined in the Base-PP. As this functionality is optional, a conformant TOE may also use the Base-PP’s trusted path to administer these functions.
Objective SFRs
This PP-Module does not define any Objective requirements.
Implementation-based SFRs
This PP-Module does not define any Implementation-based requirements.
Selection-based SFRs
FCS_DEVID_EXT.1	This SFR applies to a MACsec peer authentication mechanism, which is beyond the original scope of the Base-PP.
FCS_EAPTLS_EXT.1	This SFR applies to a MACsec peer authentication mechanism, which is beyond the original scope of the Base-PP, though it is based on the TLS implementation specified in the Base-PP.
FCS_SNMP_EXT.1	This SFR applies to implementation of the SNMP protocol, which is beyond the original scope of the Base-PP, though it is based on the TLS implementation specified in the Base-PP.
FMT_SNMP_EXT.1	This SFR defines requirements for use of SNMP as a management interface, which is beyond the original scope of the Base-PP.

Appendix A - Optional SFRs

A.1 Strictly Optional Requirements

A.1.1 Identification and Authentication (FIA)

FIA_AFL_EXT.1 Authentication Attempt Limiting

FIA_AFL_EXT.1.1

When three unsuccessful authentication attempts have been made to the local console, the TSF shall limit the rate of login attempts to one per minute.
Application Note: This requirement applies to an administrator at a local console. This anti-hammering requirement is to slow down brute force password guessing.

A.1.2 Protection of the TSF (FPT)

FPT_DDP_EXT.1 Data Delay Protection

FPT_DDP_EXT.1.1

The TSF shall enable data delay protection for MKA that ensures data frames protected by MACsec are not delayed by more than two seconds.

FPT_RPL_EXT.1 Replay Protection for XPN

FPT_RPL_EXT.1.1

The TSF shall support extended packet numbering (XPN) as per IEEE 802.1AE-2018.

FPT_RPL_EXT.1.2

The TSF shall support [selection: GCM-AES-XPN-128, GCM-AES-XPN-256] as per IEEE 802.1AE-2018.
Application Note: XPN support is expected for devices that are capable of 40 Gbps or higher throughput. This SFR is optional because not all conformant TOEs are expected to provide this level of bandwidth. For XPN the full 64-bit PN is recovered using the 32 least significant bits conveyed in the SecTag and the 32 most significant bits are recovered on receipt of a frame.

Evaluation Activities

FPT_RPL_EXT.1

TSS

The evaluator shall examine the TSS to determine that it includes XPN in the description of how replay is detected for MPDUs and how replayed MPDUs are handled by the TSF.

Guidance

If the use of XPN or the XPN ciphersuites used by the TOE are configurable, the evaluator shall examine the guidance documentation to determine that it describes how this is configured.

Tests

The evaluator shall perform the following tests:

Test FPT_RPL_EXT.1:1: The evaluator shall establish a MACsec connection between the TOE and a test system using the GCM-AES-XPN-128 ciphersuite if selected, otherwise use GCM-AES-XPN-256. The evaluator shall write or obtain a script to send a small frame with a known payload (such as five bytes of all zeroes) to the TOE. The evaluator shall activate a packet capture tool on the connection between the TOE and the test system and then use the test system to send this frame to the TOE 4,294,967,267 (2^32 + 1) times. The evaluator shall use the packet capture tool to verify that for the first and last frames sent, the least significant 32 bits are the same. This means the most significant bits should have been incremented during this test. Since the IV is different the two encrypted frames should be different.
Note that if traffic is sent to the TOE at a rate of 10 GB/s, this will take approximately five minutes as per IEEE 802.1AE-2018.
Test FPT_RPL_EXT.1:2: If both ciphersuites were selected, then the evaluator shall reconfigure the TOE using the second ciphersuite and rerun Test 1 to demonstrate support for both ciphersuites.

A.1.3 Trusted Path/Channels (FTP)

FTP_TRP.1/MACSEC Trusted Path (MACsec Administration)

FTP_TRP.1.1/MACSEC

The TSF shall provide a communication path between itself and [remote] users using [selection: MACsec, SNMPv3] that is logically distinct from other communication paths and provides assured identification of its end points and protection of the communicated data from [modification, disclosure].

FTP_TRP.1.2/MACSEC

The TSF shall permit [remote users] to initiate communication via the trusted path.

FTP_TRP.1.3/MACSEC

The TSF shall require the use of the trusted path for [remote administration of MACsec management functions as defined in FMT_SMF.1/MACSEC].
Application Note: This SFR is optional because it is permissible for the management functions defined in this PP-Module to be implemented solely through the trusted path defined in FTP_TRP.1/Admin in the Base-PP. If SNMP is selected, the FCS_SNMP_EXT.1 and FMT_SNMP_EXT.1 SFRs must be claimed.

A.2 Objective Requirements

This PP-Mod does not define any Objective SFRs.

A.3 Implementation-based Requirements

This PP-Mod does not define any Implementation-based SFRs.

Appendix B - Selection-based Requirements

As indicated in the introduction to this PP-Module, the baseline requirements (those that must be performed by the TOE or its underlying platform) are contained in the body of this PP-Module. There are additional requirements based on selections in the body of the PP-Module: if certain selections are made, then additional requirements below must be included.

B.1 Cryptographic Support (FCS)

FCS_DEVID_EXT.1 Secure Device Identifiers

The inclusion of this selection-based component depends upon selection in: FCS_MACSEC_EXT.4.1.

FCS_DEVID_EXT.1.1

The TSF shall implement Secure Device Identifiers (DevIDs) following IEEE Standard 802.1AR-2018.

FCS_DEVID_EXT.1.2

The TSF shall contain an Initial DevID (IDevID) as specified in Section 6 of IEEE 802.1AR-2018.

FCS_DEVID_EXT.1.3

The TSF shall contain the credential chain as specified in Section 6.3 of IEEE 802.1AR-2018.

FCS_DEVID_EXT.1.4

The TSF shall verify that both the Supplicant and Authenticator DevIDs presented for EAP-TLS have credentials that chain to one of the specified Certificate Authorities.

FCS_DEVID_EXT.1.5

The TSF shall not establish a trusted channel if the Supplicant DevID is invalid.

FCS_DEVID_EXT.1.6

The TSF shall support mutual authentication using DevIDs.

FCS_DEVID_EXT.1.7

The TSF shall support the following operations as specified in Section 7.2 of IEEE 802.1AR-2018:

Enable or disable DevID credential
Enable or disable DevID key

Evaluation Activities

FCS_DEVID_EXT.1.5

TSS

The evaluator shall check the TSS to verify that it describes how the TSF implements and validates DevIDs.

Guidance

There are no guidance EAs for this element.

Tests

The evaluator shall perform the following tests:

Test FCS_DEVID_EXT.1.5:1:
1. The evaluator shall install a DevID in the Supplicant that has one octet changed to invalidate the signature.
2. The evaluator shall cause the Supplicant to initiate an EAP-TLS session with the Authenticator.
3. The evaluator shall verify that the connection fails.
Test FCS_DEVID_EXT.1.5:2:
1. The evaluator shall install a DevID in the Supplicant with a valid signature but from an issuer not recognized by the Authenticator.
2. The evaluator shall cause the Supplicant to initiate an EAP-TLS session with the Authenticator.
3. The evaluator shall verify that the connection fails.
Test FCS_DEVID_EXT.1.5:3:
1. The evaluator shall cause the Supplicant to initiate an EAP-TLS session with the Authenticator.
2. The evaluator shall intercept, manipulate, and retransmit the packets sent by the Supplicant so that the presented name differs from the name in the DevID.
3. The evaluator shall verify that the connection fails.

FCS_DEVID_EXT.1.6

TSS

The evaluator shall check the TSS to verify that it describes the ability of the TSF to support mutual authentication using DevIDs.

Guidance

There are no guidance EAs for this element.

Tests

The evaluator shall perform the following test:

Test FCS_DEVID_EXT.1.6:1:
- Step 1: The evaluator shall cause the Supplicant to initiate an EAP-TLS session with the Authenticator in which mutual authentication is requested.
- Step 2: The evaluator shall verify that the EAP-TLS packet with a Client Certificate Request message is sent and that the Supplicant responds with its DevID.

FCS_DEVID_EXT.1.7

TSS

The evaluator shall check the TSS to verify that it describes the ability of the TSF to support the signing, enable and disable DevID credential, and enable and disable DevID key operations.

Guidance

There are no guidance EAs for this element.

Tests

The evaluator shall perform the following tests:

Test FCS_DEVID_EXT.1.7:1:
1. The evaluator shall disable the Supplicant public key by setting MIB object devIDPublicKeyEnabled to false.
2. The evaluator shall cause Supplicant to initiate an EAP-TLS session with the Authenticator.
3. The evaluator shall verify that the Supplicant is unable to authenticate.
4. The evaluator shall re-enable the public key, then verify the Supplicant can authenticate.
Test FCS_DEVID_EXT.1.7:2:
1. The evaluator shall disable the Supplicant DevID by setting MIB object devIDCredentialEnabled to false.
2. The evaluator shall cause Supplicant to initiate an EAP-TLS session with the Authenticator.
3. The evaluator shall verify that the Supplicant is unable to authenticate.
4. The evaluator shall re-enable the DevID, then verify the Supplicant can authenticate.

FCS_EAPTLS_EXT.1 EAP-TLS Protocol

The inclusion of this selection-based component depends upon selection in: FCS_MACSEC_EXT.4.1.

FCS_EAPTLS_EXT.1.1

The TSF shall implement the Extensible Authentication Protocol (EAP) as specified in RFC 3748 and EAP-Transport Layer Security (EAP-TLS) as specified in RFC 5216 as updated by RFC 8996 with TLS implemented using mutual authentication in accordance with [selection: FCS_DTLSC_EXT.1 and FCS_DTLSC_EXT.2FCS_DTLSS_EXT.1 and FCS_DTLSS_EXT.2FCS_TLSC_EXT.1 and FCS_TLSC_EXT.2FCS_TLSS_EXT.1 and FCS_TLSS_EXT.2] from the Base-PP.
Application Note:

If this SFR is selected, the FCS_(D)TLSC_EXT or FCS_(D)TLSS_EXT SFRs from the Base-PP must be included.

RFC 8996 deprecates TLS 1.1.

FCS_SNMP_EXT.1 SNMP Protocol

The inclusion of this selection-based component depends upon selection in: FTP_TRP.1.1/MACSEC.

FCS_SNMP_EXT.1.1

The TSF shall support SNMP using TLS as specified in RFC 6353 as updated by RFC 8996 with TLS implemented using mutual authentication in accordance with [selection: FCS_DTLSC_EXT.1 and FCS_DTLSC_EXT.2FCS_DTLSS_EXT.1 and FCS_DTLSS_EXT.2FCS_TLSC_EXT.1 and FCS_TLSC_EXT.2FCS_TLSS_EXT.1 and FCS_TLSS_EXT.2] from the Base-PP.
Application Note:

If this SFR is selected, the appropriate FCS_(D)TLSC_EXT and FCS_(D)TLSS_EXT SFRs from the Base-PP must be included.

B.2 Security Management (FMT)

FMT_SNMP_EXT.1 SNMP Management

The inclusion of this selection-based component depends upon selection in: FTP_TRP.1.1/MACSEC.

FMT_SNMP_EXT.1.1

The TSF shall implement Simple Network Management Protocol (SNMP) with TLS security in conformance with RFC 6353 “Transport Layer Security (TLS) Transport Model for the Simple Network Management Protocol (SNMP).”

FMT_SNMP_EXT.1.2

The TSF shall permit access to TSF management functions using only SNMP version 3.

FMT_SNMP_EXT.1.3

The TSF shall support the following password quality metrics for SNMPv3 passwords: [character selections and minimum length defined in FIA_PMG_EXT.1].
Application Note: FIA_PMG_EXT.1 is defined in the Base-PP so a conformant MACsec TOE will include this dependency.

Appendix C - Extended Component Definitions

This appendix contains the definitions for all extended requirements specified in the PP-Module.

C.1 Extended Components Table

All extended components specified in the PP-Module are listed in this table:

Table 4: Extended Component Definitions
Functional Class	Functional Components
Cryptographic Support (FCS)

	FCS_MACSEC_EXT - MACsec
	FCS_MKA_EXT - MACsec Key Agreement
	FCS_DEVID_EXT - Secure Device Identifiers
	FCS_EAPTLS_EXT - EAP-TLS Protocol
	FCS_SNMP_EXT - SNMP Protocol
Identification and Authentication (FIA)

	FIA_PSK_EXT - Pre-Shared Key Composition
	FIA_AFL_EXT - Authentication Failure Handling
Protection of the TSF (FPT)

	FPT_CAK_EXT - Protection of CAK Data
	FPT_DDP_EXT - Data Delay Protection
	FPT_RPL_EXT - Replay Protection
Security Management (FMT)

	FMT_SNMP_EXT - SNMP Management

C.2 Extended Component Definitions

C.2.1 Cryptographic Support (FCS)

This PP-Module defines the following extended components as part of the FCS class originally defined by CC Part 2:

C.2.1.1 FCS_MACSEC_EXT MACsec

Family Behavior

This family defines requirements for implementation of MACsec functionality.

Component Leveling

FCS_MACSEC_EXT.1, MACsec, requires the TSF to implement MACsec in a specified manner.

FCS_MACSEC_EXT.2, MACsec Integrity and Confidentiality, requires the TSF to implement MACsec with support for integrity and confidentiality protection.

FCS_MACSEC_EXT.3, MACsec Randomness, requires the TSF to generate keys and key data using sufficient randomness.

FCS_MACSEC_EXT.4, MACsec Key Usage, requires the TSF to specify the supported methods of MACsec peer authentication and to define the lifecycle for keys used in support of this.

Management: FCS_MACSEC_EXT.1

No specific management functions are identified.

Audit: FCS_MACSEC_EXT.1

The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST:

Session establishment.

FCS_MACSEC_EXT.1 MACsec

Hierarchical to: No other components.

Dependencies to: No dependencies.

FCS_MACSEC_EXT.1.1

The TSF shall implement MACsec in accordance with IEEE Standard 802.1AE-2018.

FCS_MACSEC_EXT.1.2

The TSF shall derive a Secure Channel Identifier (SCI) from a peer’s MAC address and port to uniquely identify the originator of an MPDU.

FCS_MACSEC_EXT.1.3

The TSF shall reject any MPDUs during a given session that contain an SCI other than the one used to establish that session.

FCS_MACSEC_EXT.1.4

The TSF shall permit only EAPOL (Port Access Entity (PAE) EtherType 88-8E), MACsec frames (EtherType 88-E5), and MAC control frames (EtherType is 88-08) and shall discard others.

Management: FCS_MACSEC_EXT.2

No specific management functions are identified.

Audit: FCS_MACSEC_EXT.2

There are no auditable events foreseen.

FCS_MACSEC_EXT.2 MACsec Integrity and Confidentiality

Hierarchical to: No other components.

Dependencies to: FCS_MACSEC_EXT.1 MACsec

FCS_MACSEC_EXT.2.1

The TOE shall implement MACsec with support for integrity protection with a confidentiality offset of [assignment: supported confidentiality offset value(s)].

FCS_MACSEC_EXT.2.2

The TSF shall provide assurance of the integrity of protocol data units (MPDUs) using an Integrity Check Value (ICV) derived with the SAK.

FCS_MACSEC_EXT.2.3

The TSF shall provide the ability to derive an Integrity Check Value Key (ICK) from a Connectivity Association Key (CAK) using a KDF.

Management: FCS_MACSEC_EXT.3

No specific management functions are identified.

Audit: FCS_MACSEC_EXT.3

The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST:

Creation and update of Secure Association Key.

FCS_MACSEC_EXT.3 MACsec Randomness

Hierarchical to: No other components.

Dependencies to: FCS_MACSEC_EXT.1 MACsec
FCS_RBG_EXT.1 Random Bit Generation

FCS_MACSEC_EXT.3.1

The TSF shall generate unique Secure Association Keys (SAKs) using [assignment: key generation or derivation method] such that the likelihood of a repeating SAK is no less than 1 in 2 to the power of the size of the generated key.

FCS_MACSEC_EXT.3.2

The TSF shall generate unique nonces for the derivation of SAKs using the TOE’s random bit generator as specified by FCS_RBG_EXT.1.

Management: FCS_MACSEC_EXT.4

The following actions could be considered for the management functions in FMT:

Specify the lifetime of a CAK.

Audit: FCS_MACSEC_EXT.4

The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST:

Creation of CA.

FCS_MACSEC_EXT.4 MACsec Key Usage

Hierarchical to: No other components.

Dependencies to: FCS_COP.1 Cryptographic Operation
FCS_MACSEC_EXT.1 MACsec
FIA_PSK_EXT.1 Pre-Shared Key Composition

FCS_MACSEC_EXT.4.1

The TSF shall support peer authentication using pre-shared keys (PSKs) [selection: EAP-TLS with DevIDs, no other method].

FCS_MACSEC_EXT.4.2

The TSF shall distribute SAKs between MACsec peers using AES key wrap as specified in FCS_COP.1.

FCS_MACSEC_EXT.4.3

The TSF shall support specifying a lifetime for CAKs.

FCS_MACSEC_EXT.4.4

The TSF shall associate Connectivity Association Key Names (CKNs) with SAKs that are defined by the KDF using the CAK as input data (per IEEE 802.1X-2010, Section 9.8.1).

FCS_MACSEC_EXT.4.5

The TSF shall associate CKNs with CAKs. The length of the CKN shall be an integer number of octets, between 1 and 32 (inclusive).

C.2.1.2 FCS_MKA_EXT MACsec Key Agreement

Family Behavior

This family defines requirements for MKA.

Component Leveling

FCS_MKA_EXT.1, MACsec Key Agreement, defines the TSF’s implementation of the Key Agreement Protocol.

Management: FCS_MKA_EXT.1

The following actions could be considered for the management functions in FMT:

Ability to create, delete, and activate MKA participants.
Ability to generate a group CAK.

Audit: FCS_MKA_EXT.1

There are no auditable events foreseen.

FCS_MKA_EXT.1 MACsec Key Agreement

Hierarchical to: No other components.

Dependencies to: FCS_MACSEC_EXT.1 MACsec

FCS_MKA_EXT.1.1

The TSF shall implement Key Agreement Protocol (MKA) in accordance with IEEE 802.1X-2010 and 802.1Xbx-2014.

FCS_MKA_EXT.1.2

The TSF shall provide assurance of the integrity of MKA protocol data units (MKPDUs) using an Integrity Check Value (ICV) derived from an Integrity Check Value Key (ICK).

FCS_MKA_EXT.1.3

The TSF shall provide the ability to derive an Integrity Check Value Key (ICK) from a CAK using a KDF.

FCS_MKA_EXT.1.4

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

FCS_MKA_EXT.1.5

The key server shall refresh a SAK when it expires. The key server shall distribute a SAK by [assignment: key type and distribution method].

FCS_MKA_EXT.1.6

The key server shall distribute a fresh SAK whenever a member is added to or removed from the live membership of the CA.

FCS_MKA_EXT.1.7

The TSF shall validate MKPDUs according to IEEE 802.1X-2010 Section 11.11.2. In particular, the TSF shall discard without further processing any MKPDUs to which any of the following conditions apply:

The destination address of the MKPDU was an individual address
The MKPDU is less than 32 octets long
The MKPDU comprises fewer octets than indicated by the Basic Parameter Set body length, as encoded in bits 4 through 1 of octet 3 and bits 8 through 1 of octet 4, plus 16 octets of ICV
The CAK Name is not recognized

If an MKPDU passes these tests, then the TSF will begin processing it as follows:

If the Algorithm Agility parameter identifies an algorithm that has been implemented by the receiver, the ICV shall be verified as specified in IEEE 802.1X-2010 Section 9.4.1.
If the Algorithm Agility parameter is unrecognized or not implemented by the receiver, its value can be recorded for diagnosis but the received MKPDU shall be discarded without further processing.

Each received MKPDU that is validated as specified in this clause and verified as specified in IEEE 802.1X-2010 Section 9.4.1 shall be decoded as specified in IEEE 802.1X-2010 Section 11.11.4.

C.2.1.3 FCS_DEVID_EXT Secure Device Identifiers

Family Behavior

This family defines requirements for the implementation and use of Secure DevIDs.

Component Leveling

FCS_DEVID_EXT.1, Secure Device Identifiers, requires the TSF to implement and use DevIDs according to acceptable standards.

Management: FCS_DEVID_EXT.1

No specific management functions are identified.

Audit: FCS_DEVID_EXT.1

There are no auditable events foreseen.

FCS_DEVID_EXT.1 Secure Device Identifiers

Hierarchical to: No other components.

Dependencies to: FCS_EAPTLS_EXT.1 EAP-TLS Protocol

FCS_DEVID_EXT.1.1

The TSF shall implement Secure Device Identifiers (DevIDs) following IEEE Standard 802.1AR-2018.

FCS_DEVID_EXT.1.2

The TSF shall contain an Initial DevID (IDevID) as specified in Section 6 of IEEE 802.1AR-2018.

FCS_DEVID_EXT.1.3

The TSF shall contain the credential chain as specified in Section 6.3 of IEEE 802.1AR-2018.

FCS_DEVID_EXT.1.4

The TSF shall verify that both the Supplicant and Authenticator DevIDs presented for EAP-TLS have credentials that chain to one of the specified Certificate Authorities.

FCS_DEVID_EXT.1.5

The TSF shall not establish a trusted channel if the Supplicant DevID is invalid.

FCS_DEVID_EXT.1.6

The TSF shall support mutual authentication using DevIDs.

FCS_DEVID_EXT.1.7

The TSF shall support the following operations as specified in Section 7.2 of IEEE 802.1AR-2018:

Enable or disable DevID credential
Enable or disable DevID key

C.2.1.4 FCS_EAPTLS_EXT EAP-TLS Protocol

Family Behavior

This family defines requirements for how the TSF implements EAP and EAP-Transport Layer Security.

Component Leveling

FCS_EAPTLS_EXT.1, EAP-TLS Protocol, requires the TSF to implement EAP and EAP-TLS according to appropriate standards.

Management: FCS_EAPTLS_EXT.1

No specific management functions are identified.

Audit: FCS_EAPTLS_EXT.1

There are no auditable events foreseen.

FCS_EAPTLS_EXT.1 EAP-TLS Protocol

Hierarchical to: No other components.

Dependencies to: [(FCS_DTLSC_EXT.1 DTLS Client Protocol and
FCS_DTLSC_EXT.2 DTLS Client Support for Mutual Authentication), or
FCS_DTLSS_EXT.1 DTLS Server Protocol and
FCS_DTLSS_EXT.2 DTLS Server Support for Mutual Authentication), or
(FCS_TLSC_EXT.1 TLS Client Protocol and
FCS_TLSC_EXT.2 TLS Client Support for Mutual Authentication), or
FCS_TLSS_EXT.1 TLS Server Protocol and
FCS_TLSS_EXT.2 TLS Server Support for Mutual Authentication)]

FCS_EAPTLS_EXT.1.1

The TSF shall implement the Extensible Authentication Protocol (EAP) as specified in RFC 3748 and EAP-Transport Layer Security (EAP-TLS) as specified in RFC 5216 as updated by RFC 8996 with TLS implemented using mutual authentication in accordance with [assignment: TLS or DTLS implementation that supports mutual authentication].

C.2.1.5 FCS_SNMP_EXT SNMP Protocol

Family Behavior

This family defines requirements for implementation of SNMP.

Component Leveling

FCS_SNMP_EXT.1, SNMP Protocol, requires the TSF to implement and support SNMP using TLS using only algorithms that meet certain standards.

Management: FCS_SNMP_EXT.1

No specific management functions are identified.

Audit: FCS_SNMP_EXT.1

There are no auditable events foreseen.

FCS_SNMP_EXT.1 SNMP Protocol

Hierarchical to: No other components.

FCS_SNMP_EXT.1.1

The TSF shall support SNMP using TLS as specified in RFC 6353 as updated by RFC 8996 with TLS implemented using mutual authentication in accordance with [assignment: TLS or DTLS implementation that supports mutual authentication].

C.2.2 Identification and Authentication (FIA)

This PP-Module defines the following extended components as part of the FIA class originally defined by CC Part 2:

C.2.2.1 FIA_PSK_EXT Pre-Shared Key Composition

Family Behavior

This family defines requirements for the generation and use of PSKs.

Component Leveling

FIA_PSK_EXT.1, Pre-Shared Key Composition, defines the TSF’s uses for PSKs and how they are obtained by the TOE.

Management: FIA_PSK_EXT.1

The following actions could be considered for the management functions in FMT:

Generate and install a PSK-based CAK.
Enable, disable, or delete a PSK-based CAK.

Audit: FIA_PSK_EXT.1

There are no auditable events foreseen.

FIA_PSK_EXT.1 Pre-Shared Key Composition

Hierarchical to: No other components.

Dependencies to: No dependencies

FIA_PSK_EXT.1.1

The TSF shall use PSKs for MKA as defined by IEEE 802.1X-2010, [selection: no other protocols, [assignment: other protocols that use PSKs]].

FIA_PSK_EXT.1.2

The TSF shall be able to [selection: accept, generate using the random bit generator specified in FCS_RBG_EXT.1] bit-based PSKs.

C.2.2.2 FIA_AFL_EXT Authentication Failure Handling

Family Behavior

This family defines requirements for handling of authentication failures beyond those defined in the Part 2 family FIA_AFL.

Component Leveling

FIA_AFL_EXT.1, Authentication Attempt Limiting, requires the TSF to limit the rate of login attempts to a certain interval after a certain number of failed authentication attempts have occurred.

Management: FIA_AFL_EXT.1

No specific management functions are identified.

Audit: FIA_AFL_EXT.1

There are no auditable events foreseen.

FIA_AFL_EXT.1 Authentication Attempt Limiting

Hierarchical to: No other components.

Dependencies to: FIA_UAU.1 Timing of Authentication

FIA_AFL_EXT.1.1

When three unsuccessful authentication attempts have been made to the local console, the TSF shall limit the rate of login attempts to one per minute.

C.2.3 Protection of the TSF (FPT)

This PP-Module defines the following extended components as part of the FPT class originally defined by CC Part 2:

C.2.3.1 FPT_CAK_EXT Protection of CAK Data

Family Behavior

This family defines confidentiality requirements for CAK data.

Component Leveling

FPT_CAK_EXT.1, Protection of CAK Data, requires the TSF to prevent administrators from being able to read the CAK values.

Management: FPT_CAK_EXT.1

No specific management functions are identified.

Audit: FPT_CAK_EXT.1

There are no auditable events foreseen.

FPT_CAK_EXT.1 Protection of CAK Data

Hierarchical to: No other components.

Dependencies to: No dependencies

FPT_CAK_EXT.1.1

The TSF shall prevent reading of CAK values by administrators.

C.2.3.2 FPT_DDP_EXT Data Delay Protection

Family Behavior

This family defines requirements for enforcement of data delay protection.

Component Leveling

FPT_DDP_EXT.1, Data Delay Protection, requires the TSF to use MKA PN information to enforce a data delay protection check of two seconds on MACsec protected frames.

Management: FPT_DDP_EXT.1

No specific management functions are identified.

Audit: FPT_DDP_EXT.1

There are no auditable events foreseen.

FPT_DDP_EXT.1 Data Delay Protection

Hierarchical to: No other components.

Dependencies to: FCS_MACSEC_EXT.4 MACsec Key Usage
FCS_MKA_EXT.1 MACsec Key Agreement

FPT_DDP_EXT.1.1

The TSF shall enable data delay protection for MKA that ensures data frames protected by MACsec are not delayed by more than two seconds.

C.2.3.3 FPT_RPL_EXT Replay Protection

Family Behavior

This family defines replay detection methods that are not defined in the Part 2 family FPT_RPL.

Component Leveling

FPT_RPL_EXT.1, Replay Protection for XPN, requires the TSF to support XPN as a method for detection of replayed traffic.

Management: FPT_RPL_EXT.1

No specific management functions are identified.

Audit: FPT_RPL_EXT.1

There are no auditable events foreseen.

FPT_RPL_EXT.1 Replay Protection for XPN

Hierarchical to: No other components.

Dependencies to: FCS_COP.1 Cryptographic Operation

FPT_RPL_EXT.1.1

The TSF shall support extended packet numbering (XPN) as per IEEE 802.1AE-2018.

FPT_RPL_EXT.1.2

The TSF shall support [selection: GCM-AES-XPN-128, GCM-AES-XPN-256] as per IEEE 802.1AE-2018.

C.2.4 Security Management (FMT)

This PP-Module defines the following extended components as part of the FMT class originally defined by CC Part 2:

C.2.4.1 FMT_SNMP_EXT SNMP Management

Family Behavior

This family defines the TOE’s use of SNMP as a management interface.

Component Leveling

FMT_SNMP_EXT.1, SNMP Management, requires the TSF to implement SNMP with (D)TLS in conformance with specific standards for use as a management interface.

Management: FMT_SNMP_EXT.1

No specific management functions are identified.

Audit: FMT_SNMP_EXT.1

There are no auditable events foreseen.

FMT_SNMP_EXT.1 SNMP Management

Hierarchical to: No other components.

Dependencies to: FCS_SNMP_EXT.1 SNMP Protocol

FMT_SNMP_EXT.1.1

FMT_SNMP_EXT.1.2

The TSF shall permit access to TSF management functions using only SNMP version 3.

FMT_SNMP_EXT.1.3

The TSF shall support the following password quality metrics for SNMPv3 passwords: [assignment: password quality metrics].

Appendix D - Implicitly Satisfied Requirements

Table 5: Implicitly Satisfied Requirements

Requirement	Rationale for Satisfaction
FIA_UAU.1 – Timing of Authentication	FIA_AFL_EXT.1 has a dependency on FIA_UAU.1 because the notion of authentication failure handling implies the existence of an authentication mechanism. This dependency is addressed by a conformant TOE through the Base-PP requirement FIA_UAU_EXT.2, which defines authentication mechanisms specific to network devices.

Appendix E - Allocation of Requirements in Distributed TOEs

For a distributed TOE, the SFRs in this PP-Module need to be met by the TOE as a whole, but not all SFRs will necessarily be implemented by all components. The following categories are defined in order to specify when each SFR must be implemented by a component:

All Components ("All"): All components that comprise the distributed TOE must independently satisfy the requirement.
At least one Component ("One"): This requirement must be fulfilled by at least one component within the distributed TOE.
Feature Dependent ("Feature Dependent"): These requirements will only be fulfilled where the feature is implemented by the distributed TOE component (note that the requirement to meet the PP-Module as a whole requires that at least one component implements these requirements if they are claimed by the TOE).

The table below specifies how each of the SFRs in this PP-Module must be met, using the categories above.

Requirement	Description	Distributed TOE SFR Allocation
FAU_GEN.1/MACSEC	Audit Data Generation (MACsec)	All
FCS_COP.1/CMAC	Cryptographic Operation (AES-CMAC Keyed Hash Algorithm)	Feature Dependent
FCS_COP.1/MACSEC	Cryptographic Operation (MACsec AES Data Encryption and Decryption)	Feature Dependent
FCS_MACSEC_EXT.1	MACsec	Feature Dependent
FCS_MACSEC_EXT.2	MACsec Integrity and Confidentiality	Feature Dependent
FCS_MACSEC_EXT.3	MACsec Randomness	Feature Dependent
FCS_MACSEC_EXT.4	MACsec Key Usage	Feature Dependent
FCS_MKA_EXT.1	MACsec Key Agreement	Feature Dependent
FIA_PSK_EXT.1	Pre-Shared Key Composition	Feature Dependent
FMT_SMF.1/MACSEC	Specification of Management Functions (MACsec)	One
FPT_CAK_EXT.1	Protection of CAK Data	Feature Dependent
FPT_FLS.1	Failure with Preservation of Secure State	All
FPT_RPL.1	Replay Detection	Feature Dependent
FPT_ITC.1/MACSEC	Inter-TSF Trusted Channel (MACsec Communications)	Feature Dependent
FIA_AFL_EXT.1	Authentication Attempt Limiting	One
FPT_DDP_EXT.1	Data Delay Protection	Feature Dependent
FPT_RPL_EXT.1	Replay Detection for XPN	Feature Dependent
FTP_TRP.1/MACSEC	Trusted Path (MACsec Administration)	One
FCS_DEVID_EXT.1	Secure Device Identifiers	Feature Dependent
FCS_EAPTLS_EXT.1	EAP-TLS Protocol	Feature Dependent
FCS_SNMP_EXT.1	SNMP Protocol	Feature Dependent
FMT_SNMP_EXT.1	SNMP Management	Feature Dependent

Appendix F - Entropy Documentation and Assessment

The TOE does not require any additional supplementary information to describe its entropy source beyond the requirements outlined in the Base-PP. As with other Base-PP requirements, the only additional requirement is that the entropy documentation also applies to the specific MACsec Ethernet encryption capabilities of the TOE that require random data, in addition to any functionality required by the Base-PP.

Appendix G - Acronyms

Acronym	Meaning
Base-PP	Base Protection Profile
CA	Connectivity Association
CAK	Connectivity Association Key
CC	Common Criteria
CEM	Common Evaluation Methodology
CKN	Connectivity Association Key Name
CMAC	Cipher-based Message Authentication Code
cPP	Collaborative Protection Profile
DevID	Device Identifier
EA	Evaluation Activity
EAP	Extensible Authentication Protocol
EAP-TLS	EAP Transport Layer Security
EAPOL	Extensible Authentication Protocol over LAN
EPL	Ethernet Private Line
EVPL	Ethernet Virtual Private Line
ICK	Integrity Check Value Key
ICV	Integrity Check Value
IEEE	Institute of Electrical and Electronics Engineers
IV	Initialization Vector
KaY	Key Agreement Entity
KDF	Key Derivation Function
KW	Key Wrap
LAN	Local Area Network
MAC	Media Access Control
MACsec	Media Access Control Security
MEF	Metro Ethernet Forum
MIB	Management Information Base
MKA	MACsec Key Agreement
MKPDU	MACsec Key Agreement Protocol Data Unit
MPDU	MACsec Protocol Data Unit
NDcPP	collaborative Protection Profile for Network Devices
OE	Operational Environment
P2P	Point-to-Point
PAE	Port Access Entity
PN	Packet Number
POST	Power On Self Test
PP	Protection Profile
PP-Configuration	Protection Profile Configuration
PP-Module	Protection Profile Module
PSK	Pre-Shared Key
RFC	Request for Comment
SA	Secure Association
SAK	Secure Association Key
SAR	Security Assurance Requirement
SC	Secure Channel
SCI	Secure Channel Identifier
SFR	Security Functional Requirement
SNMP	Simple Network Management Protocol
ST	Security Target
TOE	Target of Evaluation
TSF	TOE Security Functionality
TSFI	TSF Interface
TSS	TOE Summary Specification
UNI	User Network Interface
VLAN	Virtual Local Area Network
XPN	Extended Packet Numbering

Appendix H - Bibliography

Identifier	Title
[CC]	Common Criteria for Information Technology Security Evaluation - Part 1: Introduction and General Model, CCMB-2017-04-001, Version 3.1 Revision 5, April 2017. Part 2: Security Functional Components, CCMB-2017-04-002, Version 3.1 Revision 5, April 2017. Part 3: Security Assurance Components, CCMB-2017-04-003, Version 3.1 Revision 5, April 2017.
[MOD_FW]	PP-Module for Stateful Traffic Filter Firewalls, Version 1.4 + Errata 20200625, June 25, 2020
[MOD_VPNGW]	PP-Module for VPN Gateways, Version 1.2, March 31, 2022
[NDcPP SD]	Supporting Document - Evaluation Activities for Network Device cPP, Version 2.2, December 2019
[NDcPP]	collaborative Protection Profile for Network Devices, Version 2.2e, March 23, 2020

PP-Module for MACsec Ethernet Encryption

Revision History

Contents

1 Introduction

1.1 Overview

1.2 Terms

1.2.1 Common Criteria Terms

1.2.2 Technical Terms

1.3 Compliant Targets of Evaluation

1.4 TOE Boundary

1.5 Use Cases

2 Conformance Claims

3 Security Problem Description

3.1 Threats

3.2 Assumptions

3.3 Organizational Security Policies

4 Security Objectives

4.1 Security Objectives for the TOE

4.2 Security Objectives for the Operational Environment

4.3 Security Objectives Rationale

5 Security Requirements

5.1 NDcPP Security Functional Requirements Direction

5.1.1 Modified SFRs

5.2 TOE Security Functional Requirements

5.2.1 Security Audit (FAU)

FAU_GEN.1/MACSEC Audit Data Generation (MACsec)

5.2.2 Cryptographic Support (FCS)

FCS_COP.1/CMAC Cryptographic Operation (AES-CMAC Keyed Hash Algorithm)

FCS_COP.1/MACSEC Cryptographic Operation (MACsec AES Data Encryption and Decryption)

FCS_MACSEC_EXT.1 MACsec

FCS_MACSEC_EXT.2 MACsec Integrity and Confidentiality

FCS_MACSEC_EXT.3 MACsec Randomness

FCS_MACSEC_EXT.4 MACsec Key Usage

FCS_MKA_EXT.1 MACsec Key Agreement

5.2.3 Identification and Authentication (FIA)

FIA_PSK_EXT.1 Pre-Shared Key Composition

5.2.4 Security Management (FMT)

FMT_SMF.1/MACSEC Specification of Management Functions (MACsec)

5.2.5 Protection of the TSF (FPT)

FPT_CAK_EXT.1 Protection of CAK Data

FPT_FLS.1 Failure with Preservation of Secure State

FPT_RPL.1 Replay Detection

5.2.6 Trusted Path/Channels (FTP)

FTP_ITC.1/MACSEC Inter-TSF Trusted Channel (MACsec Communications)

5.3 TOE Security Functional Requirements Rationale

6 Consistency Rationale

6.1 NDcPP

6.1.1 Consistency of TOE Type

6.1.2 Consistency of Security Problem Definition

6.1.3 Consistency of Objectives

6.1.4 Consistency of Requirements

Appendix A - Optional SFRs

A.1 Strictly Optional Requirements

A.1.1 Identification and Authentication (FIA)

FIA_AFL_EXT.1 Authentication Attempt Limiting

A.1.2 Protection of the TSF (FPT)

FPT_DDP_EXT.1 Data Delay Protection

FPT_RPL_EXT.1 Replay Protection for XPN

A.1.3 Trusted Path/Channels (FTP)

FTP_TRP.1/MACSEC Trusted Path (MACsec Administration)

A.2 Objective Requirements

A.3 Implementation-based Requirements

Appendix B - Selection-based Requirements

B.1 Cryptographic Support (FCS)

FCS_DEVID_EXT.1 Secure Device Identifiers

FCS_EAPTLS_EXT.1 EAP-TLS Protocol

FCS_SNMP_EXT.1 SNMP Protocol

B.2 Security Management (FMT)

FMT_SNMP_EXT.1 SNMP Management

Appendix C - Extended Component Definitions

C.1 Extended Components Table

C.2 Extended Component Definitions

C.2.1 Cryptographic Support (FCS)

C.2.1.1 FCS_MACSEC_EXT MACsec

Family Behavior

Component Leveling

Management: FCS_MACSEC_EXT.1

Audit: FCS_MACSEC_EXT.1

FCS_MACSEC_EXT.1 MACsec

FCS_MACSEC_EXT.1.1