Supporting Document
Mandatory Technical Document
PP-Module for MACsec Ethernet Encryption
Version: 1.0
2022-12-16
National Information Assurance Partnership
This is a Supporting Document (SD), intended to complement the Common Criteria version 3 and the associated Common Evaluation Methodology for Information Technology Security Evaluation.
SDs may be “Guidance Documents”, that highlight specific approaches and application of the standard to areas where no mutual recognition of its application is required, and as such, are not of normative nature, or “Mandatory Technical Documents”, whose application is mandatory for evaluations whose scope is covered by that of the SD. The usage of the latter class is not only mandatory, but certificates issued as a result of their application are recognized under the CCRA.
Technical Editor:
National Information Assurance Partnership (NIAP)
| Version | Date | Comment |
|---|---|---|
| 1.0 | 2022-12-16 | Initial Release |
General Purpose:
The purpose of this SD is to define evaluation methods for the functional behavior of MACsec Ethernet Encryption products.
Acknowledgments:
This SD was developed with support from NIAP MACsec Ethernet Encryption Technical Community members, with representatives from industry, government agencies, Common Criteria Test Laboratories, and members of academia.
The scope of the PP-Module for MACsec Ethernet Encryption is to describe the security functionality of MACsec Ethernet Encryption products in terms of [CC] and to define functional and assurance requirements for them.
The PP-Module is intended for use with the following Base-PP:
This SD is mandatory for evaluations of TOEs that claim conformance to a PP-Configuration that includes the PP-Module for :
As such it defines Evaluation Activities for the functionality described in the PP-Module as well as any impacts to the Evaluation Activities to the Base-PP(s) it modifies.
Although Evaluation Activities are defined mainly for the evaluators to follow, in general they also help developers to prepare for evaluation by identifying specific requirements for their TOE. The specific requirements in Evaluation Activities may in some cases clarify the meaning of Security Functional Requirements (SFR), and may identify particular requirements for the content of Security Targets (ST) (especially the TOE Summary Specification), user guidance documentation, and possibly supplementary information (e.g. for entropy analysis or cryptographic key management architecture).
Evaluation Activities can be defined for both SFRs and Security Assurance Requirements (SAR), which are themselves defined in separate sections of the SD.
If any Evaluation Activity cannot be successfully completed in an evaluation, then the overall verdict for the evaluation is a 'fail'. In rare cases there may be acceptable reasons why an Evaluation Activity may be modified or deemed not applicable for a particular TOE, but this must be approved by the Certification Body for the evaluation.
In general, if all Evaluation Activities (for both SFRs and SARs) are successfully completed in an evaluation then it would be expected that the overall verdict for the evaluation is a ‘pass’. To reach a ‘fail’ verdict when the Evaluation Activities have been successfully completed would require a specific justification from the evaluator as to why the Evaluation Activities were not sufficient for that TOE.
Similarly, at the more granular level of assurance components, if the Evaluation Activities for an assurance component and all of its related SFR Evaluation Activities are successfully completed in an evaluation then it would be expected that the verdict for the assurance component is a ‘pass’. To reach a ‘fail’ verdict for the assurance component when these Evaluation Activities have been successfully completed would require a specific justification from the evaluator as to why the Evaluation Activities were not sufficient for that TOE.
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. |
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. |
The EAs presented in this section capture the actions the evaluator performs to address technology specific aspects covering specific SARs (e.g. ASE_TSS.1, ADV_FSP.1, AGD_OPE.1, and ATE_IND.1) – this is in addition to the CEM workunits that are performed in Section 3.
Regarding design descriptions (designated by the subsections labeled TSS, as well as any required supplementary material that may be treated as proprietary), the evaluator must ensure there is specific information that satisfies the EA. For findings regarding the TSS section, the evaluator’s verdicts will be associated with the CEM workunit ASE_TSS.1-1. Evaluator verdicts associated with the supplementary evidence will also be associated with ASE_TSS.1-1, since the requirement to provide such evidence is specified in ASE in the PP.
For ensuring the guidance documentation provides sufficient information for the administrators/users as it pertains to SFRs, the evaluator’s verdicts will be associated with CEM workunits ADV_FSP.1-7, AGD_OPE.1-4, and AGD_OPE.1-5.
Finally, the subsection labeled Tests is where the authors have determined that testing of the product in the context of the associated SFR is necessary. While the evaluator is expected to develop tests, there may be instances where it is more practical for the developer to construct tests, or where the developer may have existing tests. Therefore, it is acceptable for the evaluator to witness developer-generated tests in lieu of executing the tests. In this case, the evaluator must ensure the developer’s tests are executing both in the manner declared by the developer and as mandated by the EA. The CEM workunits that are associated with the EAs specified in this section are: ATE_IND.1-3, ATE_IND.1-4, ATE_IND.1-5, ATE_IND.1-6, and ATE_IND.1-7.
The EAs defined in this section are only applicable in cases where the TOE claims conformance to a PP-Configuration that includes the NDcPP.
The PP-Module does not modify any requirements when the NDcPP is the base.
The PP-Module does levy any additional requirements when the NDcPP is the base.
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.
There are no guidance evaluation activities (EAs) for this component.
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:
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.
There are no guidance EAs for this component.
In addition to the tests specified in the NDcPP for other iterations of FCS_COP.1, the evaluator shall perform the following tests:
The messages in each set for both tests shall be the following lengths:
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.
There are no guidance EAs for this component.
The evaluator shall examine the TSS to verify that it describes the methods that the TOE implements to provide assurance of MACsec integrity. This should include any confidentiality offsets used, the use of an ICV (including the supported length), and ICV generation with the SAK, using the SCI as the most significant bits of the initialization vector (IV) and the 32 least significant bits of the PN as the IV.
If any integrity verifications are configurable, such as any confidentiality offsets used or the mechanism used to derive an ICK, the evaluator shall verify that instructions for performing these functions are documented.
The evaluator shall examine the TSS to verify that it describes the method used to generate SAKs and nonces and that the strength of the CAK and the size of the CAK’s key space are provided.
There are no guidance EAs for this component.
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.
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.
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.
There are no guidance EAs for this element.
The evaluator shall perform the following tests:
There are no TSS EAs for this element.
There are no guidance EAs for this element.
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:
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.
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.
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:
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.
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.
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.
The evaluator shall verify that the TSS describes the ability of the TOE to provide the management functions defined in this SFR.
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.
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.
The evaluator shall examine the TSS to determine that it details how CAKs are stored and that they are unable to be viewed through an interface designed specifically for that purpose. If these values are not stored in plaintext, the TSS shall describe how they are protected or obscured.
There are no guidance EAs for this component.
There are no test EAs for this component.
The evaluator shall examine the TSS to determine that it indicates that the TSF will shut down if a self-test failure is detected. For TOEs with redundant failover capability, the evaluator shall examine the TSS to determine that it indicates that the failed components will shut down if a self-test failure is detected.
The evaluator shall examine the operational guidance to verify that it describes the behavior of the TOE following a self-test failure and actions that an administrator should take if it occurs.
The following test may require the vendor to provide access to a test platform that provides the evaluator with the ability to modify the TOE internals in a manner that is not provided to end customers:
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.
There are no guidance EAs for this component.
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.
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.
The evaluator shall examine the TSS to determine that it describes the ability of the TSF to limit the rate at which authentication attempts can be made at the local console following three successive failed attempts.
If the TOE requires configuration to be put into a state where authentication attempt limiting is enforced, the evaluator shall review the operational guidance to verify that it describes the procedures to configure the TOE into this state.
There are no TSS EAs for this component.
There are no guidance EAs for this component.
The test below requires the TOE to be deployed in an environment with two MACsec-capable peers, identified as devices B and C, that the TOE can communicate with. Prior to performing this test, the evaluator shall follow the steps in the guidance documentation to configure the TOE as the key server and principal actor. The evaluator shall then perform the following test:
The evaluator shall 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.
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.
The evaluator shall perform the following tests:
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.
If “MACsec” is selected in FTP_TRP.1.1/MACSEC, this SFR is addressed through evaluation of FCS_MACSEC_EXT.1 through FCS_MACSEC_EXT.4.
If “SNMPv3” is selected in FTP_TRP.1.1/MACSEC, this SFR is addressed through evaluation of FCS_SNMP_EXT.1 and FMT_SNMP_EXT.1.
For these EAs, the evaluator shall ensure that the testing is performed on the management interface (e.g., if “MACsec” is selected in FTP_TRP.1.1/MACSEC, the evaluator shall repeat the testing as needed for the management interface and not rely on the testing of an outbound connection to an arbitrary MACsec peer).
The PP-Mod does not define any objective SFRs.
The PP-Mod does not define any implementation-based SFRs.
The PP-Mod does not define any selection-based SFRs.
The PP-Module does not define any SARs beyond those defined within the base NDcPP to which it must claim conformance. It is important to note that a TOE that is evaluated against the PP-Module is inherently evaluated against this Base-PP as well. The NDcPP includes a number of Evaluation Activities associated with both SFRs and SARs. Additionally, the PP-Module includes a number of SFR-based Evaluation Activities that similarly refine the SARs of the Base-PPs. The evaluation laboratory will evaluate the TOE against the Base-PP and supplement that evaluation with the necessary SFRs that are taken from the PP-Module.
This Supporting Document has no required supplementary information beyond the ST, operational guidance, and testing.
| Identifier | Title |
|---|---|
| [CC] | Common Criteria for Information Technology Security Evaluation -
|
| [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 |