PP-Module for MACsec Ethernet Encryption

Version: 2.0
2025-02-28
National Information Assurance Partnership

Revision History

TDs Applied

Contents

1 Introduction

1.1 Overview

• Network Device collaborative Protection Profile, Version 4.0

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

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

An ST must claim exact conformance to this PP-Module.

The evaluation methods used for evaluating the TOE are a combination of the workunits defined in [CEM] as well as the Evaluation Activities for ensuring that individual SFRs and SARs have a sufficient level of supporting evidence in the Security Target and guidance documentation and have been sufficiently tested by the laboratory as part of completing ATE_IND.1. Any functional packages this PP claims similarly contain their own Evaluation Activities that are used in this same manner.

CC Conformance Claims

This PP-Module is conformant to Part 2 (extended) and Part 3 (conformant) of Common Criteria CC:2022, Revision 1.

PP Claim

This PP-Module does not claim conformance to any Protection Profile.

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

• Network Device collaborative Protection Profile Version 4.0
• PP-Module for Stateful Traffic Filter Firewalls Version 2.0 (MOD_FW)
• PP-Module for Virtual Private Network (VPN) Gateways Version 2.0 (MOD_VPNGW)

Package Claim

• This PP-Module is Functional Package for Transport Layer Security, Version 2.1 conformant.
• This PP-Module does not conform to any assurance packages.

The functional packages to which the PP conforms may include SFRs that are not mandatory to claim for the sake of conformance. An ST that claims one or more of these functional packages may include any non-mandatory SFRs that are appropriate to claim based on the capabilities of the TSF and on any triggers for their inclusion based inherently on the SFR selections made.

3 Security Problem Definition

3.1 Threats

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

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.

4 Security Objectives

4.1 Security Objectives for the Operational Environment

5 Security Requirements

• Refinement operation (denoted by bold text or strikethrough text): Is used to add details to a requirement 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 Collaborative Protection Profile for Network Devices Security Functional Requirements Direction

5.1.1 Modified SFRs

5.2 TOE Security Functional Requirements

5.2.1 Auditable Events for Mandatory SFRs

5.2.2 Security Audit (FAU)

5.2.3 Cryptographic Support (FCS)

5.2.4 Identification and Authentication (FIA)

5.2.5 Security Management (FMT)

5.2.6 Protection of the TSF (FPT)

5.2.7 Trusted Path/Channels (FTP)

5.3 TOE Security Functional Requirements Rationale

The following rationale provides justification for each SFR for the TOE, showing that the SFRs are suitable to address the specified threats:

Table 2: SFR Rationale

Threat	Addressed by	Rationale
T.DATA_​INTEGRITY	FCS_COP.1/CMAC	Mitigates the threat by using a secure keyed-hash function as part of the process generate MACsec keys.
	FCS_COP.1/MACSEC	Mitigates the threat by using secure encryption/decryption functions to encrypt traffic over MACsec.
	FCS_MACSEC_EXT.2	Mitigates the threat by utilizing integrity protection features of MACsec.
	FCS_MACSEC_EXT.3	Mitigates the threat by using a secure process to generate traffic-protecting keys.
	FTP_ITC.1/MACSEC	Mitigates the threat by providing a secure communication channel for the use of MACsec.
	FTP_TRP.1/MACSEC (optional)	Mitigates the threat by providing a secure communication channel for the administration of the TSF over a secure protocol.
	FCS_SNMP_EXT.1 (selection-based)	Mitigates the threat by using a secure configuration of SNMP to administer the TSF.
	FPT_RPL.1	Mitigates the threat by detecting and blocking replay attempts.
	FPT_RPL_EXT.1 (optional)	Mitigates the threat by utilizing extended standards to number packets, thus enabling the detection of replay attempts.
T.NETWORK_​ACCESS	FCS_MACSEC_EXT.1	Mitigates the threat by utilizing the MACsec protocol to secure traffic transmitted between an external and internal network.
	FCS_MACSEC_EXT.4	Mitigates the threat by authenticating the communication peers utilizing a secure credential (pre-shared key or EAP-TLS).
	FCS_MKA_EXT.1	Mitigates the threat by securely generating, agreeing upon, and transmitting keys used for MACsec traffic.
	FIA_PSK_EXT.1	Mitigates the threat by utilizing secure pre-shared keys as part of the authentication process for MACsec.
	FPT_DDP_EXT.1	Mitigates the threat by preventing traffic that is delayed from being accepted, reducing the risk of replay or other modifications to the traffic.
	FCS_DEVID_EXT.1 (selection-based)	Mitigates the threat by identifying devices using a secure device identifier.
	FCS_EAPTLS_EXT.1 (selection-based)	Mitigates the threat by utilizing the EAP-TLS protocol to authenticate communication peers.
T.UNTRUSTED_​MACSEC_​COMMUNICATION_​CHANNELS	FCS_COP.1/CMAC	Mitigates the threat by utilizing keyed-hash functions to ensure message authentication.
	FCS_COP.1/MACSEC	Mitigates the threat by utilizing encryption/decryption functions to ensure message integrity and confidentiality.
	FCS_MACSEC_EXT.2	Mitigates the threat by utilizing MACsec in a configuration to protect the integrity of transmissions to or from the TOE.
	FCS_MACSEC_EXT.3	Mitigates the threat by ensuring that MACsec Secure Association Keys are generated unpredictably, thus lessening the possibility of a loss in integrity.
	FTP_ITC.1/MACSEC	Mitigates the threat by providing a secure channel for communication that utilizes the prescribed configurations of MACsec.
	FTP_TRP.1/MACSEC (optional)	Mitigates the threat by providing a secure channel for administrative configuration that utilizes MACsec, preventing passwords or other secure values from disclosure.
	FCS_SNMP_EXT.1 (selection-based)	Mitigates the threat by providing a secure channel for administrative configuration that utilizes SNMP, preventing passwords or other secure values from disclosure.
T.UNAUTHORIZED_​ADMINISTRATOR_​ACCESS	FMT_SMF.1/MACSEC	Mitigates the threat by specifying functionality that must be restricted to administrators.
	FPT_CAK_EXT.1	Mitigates the threat by preventing sensitive data (CAK values) from being disclosed, even to an administrator.
	FIA_AFL_EXT.1 (optional)	Mitigates the threat by limiting the rate of authentication if too many authentication failures have occurred.
	FTP_TRP.1/MACSEC (optional)	Mitigates the threat by using a secure path to administer the TSF, preventing secure values from being recorded, replayed, or otherwise impersonated.
	FMT_SNMP_EXT.1 (selection-based)	Mitigates the threat by utilizing a secure configuration of SNMP to administer the TSF.
T.UNDETECTED_​ACTIVITY	FAU_GEN.1/MACSEC	Mitigates the threat by logging traffic and actions relevant to secure operations.
T.SECURITY_​FUNCTIONALITY_​FAILURE	FPT_FLS.1/MACSEC	Mitigates the threat by attaining a secure state (e.g., shutdown) upon the failure of TSF-relevant health tests.

5.4 TOE Security Assurance Requirements

6 Consistency Rationale

6.1 Collaborative Protection Profile for Network Devices

6.1.1 Consistency of TOE Type

6.1.2 Consistency of Security Problem Definition

6.1.3 Consistency of OE Objectives

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

Appendix A - Optional SFRs

A.1 Strictly Optional Requirements

A.1.1 Auditable Events for Strictly Optional SFRs

A.1.2 Identification and Authentication (FIA)

A.1.3 Protection of the TSF (FPT)

A.1.4 Trusted Path/Channels (FTP)

A.2 Objective Requirements

This PP-Module does not define any Objective SFRs.

A.3 Implementation-dependent Requirements

This PP-Module does not define any Implementation-dependent SFRs.

Appendix B - Selection-based Requirements

B.1 Auditable Events for Selection-based SFRs

B.2 Cryptographic Support (FCS)

B.3 Security Management (FMT)

Appendix C - Extended Component Definitions

C.1 Extended Components Table

C.2 Extended Component Definitions

Appendix D - Implicitly Satisfied Requirements

This appendix lists requirements that should be considered satisfied by products successfully evaluated against this PP-Module. These requirements are not featured explicitly as SFRs and should not be included in the ST. They are not included as standalone SFRs because it would increase the time, cost, and complexity of evaluation. This approach is permitted by [CC] Part 1, 8.3 Dependencies between components.

This information benefits systems engineering activities which call for inclusion of particular security controls. Evaluation against the PP-Module provides evidence that these controls are present and have been evaluated.

Appendix E - Allocation of Requirements in Distributed TOEs

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

Appendix F - Entropy Documentation and Assessment

Appendix G - Acronyms

Appendix H - Bibliography