Protocol++® (Protocolpp®)
v5.6.2
|
#include "include/jmacsec.h"
Information provided by IEEE https://standards.ieee.org/getieee802/download/802.1AE-2006.pdf
Encoding of MACsec protocol data units
This clause specifies the structure and encoding of the MACsec Protocol Data Units (MPDUs) exchanged between MAC Security Entities (SecYs). It
NOTE—The MPDU validation checks specified in this clause are deliberately limited to ensuring successful decoding, and do not overlap with the specification of SecY operation (Clause 10).
Structure, representation, and encoding
All MPDUs shall contain an integral number of octets. The octets in a MPDU are numbered starting from 1 and increasing in the order they are put into the MAC Service Data Unit (MSDU) that accompanies a request to or indication from the instance of the MAC Internal Sublayer Service (ISS) used by a SecY. The bits in an octet are numbered from 1 to 8 in order of increasing bit significance, where 1 is the least significant bit in the octet. Where octets and bits within a MPDU are represented using a diagram, octets shown higher on the page than subsequent octets and octets shown to the left of subsequent octets at the same height on the page are lower numbered, bits shown to the left of other bits within the same octet are higher numbered. Where two or more consecutive octets are represented as hexadecimal values, lower numbered octet(s) are shown to the left and each octet following the first is preceded by a hyphen, e.g., 01-80-C2-00-00-00.
When consecutive octets are used to encode a binary number, the lower octet number has the more significant value. When consecutive bits within an octet are used to encode a binary number, the higher bit number has the most significant value. When bits within consecutive octets are used to encode a binary number, the lower octet number composes the more significant bits of the number. A flag is encoded as a single bit, and is set (True) if the bit takes the value 1, and clear (False) otherwise. The remaining bits within the octet can be used to encode other protocol fields.
Major components
Each MPDU comprises
Each of these components comprises an integral number of octets and is encoded in successive octets of the MPDU as illustrated in Figure 9-1
NOTE—The MPDU does not include the source and destination MAC addresses, as these are separate parameters of the service requests and indications to and from the insecure service that supports MACsec
Security TAG
The Security TAG (SecTAG) is identified by the MACsec EtherType, and conveys the
The format of the SecTAG is illustrated in Figure 9-2
MACsec EtherType
The MACsec EtherType comprises octet 1 and octet 2 of the SecTAG. It is included to allow
The encoding of the MACsec EtherType in the MPDU is illustrated in the next figure
TAG Control Information (TCI)
The TCI field comprises bits 8 through 3 of octet 3 (Figure 9-4) of the SecTAG. These bits facilitate
The encoding of the MACsec TCI in the MPDU is illustrated in Figure 9-4.
TCIAN bit encoding is as follows:
Association Number (AN)
The AN is encoded as an integer in bits 1 and 2 of octet 3 of the SecTAG (Figure 9-4) and identifies up to four different SAs within the context of an SC. NOTE—Although each receiving SecY only needs to maintain two SAs per SC, the use of a 2-bit AN simplifies the design of protocols that update values associated with each of the SAs.
Short Length (SL)
SL is an integer encoded in bits 1 through 6 of octet 4 of the SecTAG and is set to the number of octets in the Secure Data (9.10) field, i.e., the number of octets between the last octet of the SecTAG and the first octet of the ICV, if that number is less than 48. Otherwise, SL is set to zero. If the number is zero then the frame is deemed not to have been short. The Secure Data field always comprises at least one octet. Bits 7 and 8 of octet 4 shall be zero.
Packet Number (PN)
The PN is encoded in octets 5 through 8 of the SecTAG to
NOTE—As specified in this clause, the IV used by the default Cipher Suite (GCM-AES-128) comprises the SCI (even if the SCI is not transmitted in the SecTAG) and the PN. Subject to proper unique MAC Address allocation procedures, the SCI is a globally unique identifier for a SecY. To satisfy the IV uniqueness requirements of CTR mode of operation, a fresh key is used before PN values are reused.
Secure Channel Identifier (SCI)
If the SC bit in the TCI is set, the SCI (7.1.2, 8.2.1) is encoded in octets 9 through 16 of the SecTAG, and facilitates
NOTE —The 64-bit value FF-FF-FF-FF-FF-FF is never used as an SCI and is reserved for use by implementations to indicate the absence of an SC or an SCI in contexts where an SC can be present.
An explicitly encoded SCI field in the SecTAG is not required on point-to-point links, which are identified by the operPointToPointMAC status parameter of the service provider. In the point-to-point case, the secure association created by the SecY for the peer SecYs, together with the direction of transmission of the secured MPDU, can be used to identify the transmitting SecY and therefore an explicitly encoded SCI is unnecessary. Although the SCI does not have to be repeated in each frame when only two SecYs participate in a CA (see Clause 8, Clause9, and Clause10), the SCI still forms part of the cryptographic computation.
Secure Data
The Secure Data comprises all the octets that follow the MACsec TAG and precede the ICV. The Secure Data field is never of zero length, since the primitives of the MAC Service require a non-null MSDU (User Data) parameter.
NOTE 1—In practice, if the MSDU composed by the operation of the current Cipher Suite following MPDU reception contains less than two octets, it will be discarded by the user of the SecY’s controlled port, since it is too short to contain an EtherType or an LLC length field. Such discard is, however, determined by the user of the Controlled Port and not by the SecY itself.
NOTE 2—Ethernet transports frames of a minimum size, and provides no explicit indication of PDU length if the PDU is composed of fewer octets. The SL field allows the originator of the frame, which is not necessarily aware of the need of an intervening Ethernet component to pad the frame, to specify the number of octets in the MPDU, thus allowing the receiver to unambiguously locate the ICV.
Integrity Check Value (ICV)
The length of the ICV is Cipher Suite dependent, but is not less than 8 octets and not more than 16 octets, depending on the Cipher Suite.
NOTE—The ICV protects the destination and source MAC address parameters, as well as all the fields of the MPDU.
PDU validation
A received MPDU is valid if and only if it comprises a valid SecTAG, one or more octets of Secure Data, and an ICV, i.e.,
802.1Q VLAN Tagging
Tagging a frame with a VLAN tag
a. Allows a VID to be conveyed, facilitating consistent VLAN classification of the frame throughout the network and enabling segregation of frames assigned to different VIDs
b. Allows priority (IEEE Std 802.1AC, 6.8) to be conveyed with the frame when using IEEE 802 LAN media access control methods that provide no inherent capability to signal priority
Tag Format
Each tag comprises the following sequential information elements:
a. A Tag Protocol Identifier (TPID)
b. Tag Control Information (TCI) that is dependent on the tag type
c. Additional information, if and as required by the tag type and TCI
The tag encoding function supports each EISS (6.8) instance by using an instance of the ISS to transmit and receive frames and encodes the above information in the first and subsequent octets of the MSDU that will accompany an ISS M_UNITDATA.request, immediately prior to encoding the sequence of octets that constitute the corresponding EISS M_UNITDATA.request’s MSDU. On reception the tag decoding function is selected by the TPID and decodes the TCI and additional information octets (if present) prior to issuing an EISS M_UNITDATA.indication with an MSDU that comprises the subsequent octets
The following types of tags are specified:
a. A C-TAG, for general use by C-VLAN Bridges and C-VLAN components of Provider Edge Bridges
b. An S-TAG, reserved for use by S-VLAN Bridges, the S-VLAN component of Provider Edge Bridges and BEBs, and C-VLAN Bridges signaling priority to a PBN or a PBBN
c. An I-TAG, reserved for use by BEBs
NOTE—The S-TAG is identical to the B-TAG
A distinct EtherType has been allocated (see table below) for use in the TPID field of each tag type so they can be distinguished from each other, and from other protocols
Tag Type | Name | Value |
---|---|---|
Customer VLAN Tag | IEEE 802.1Q Tag Protocol EtherType (802.1QTagType) | 81-00 |
Service or Backbone VLAN Tag | IEEE 802.1Q Tag Protocol EtherType (802.1QSTagType) | 88-A8 |
Backbone Service Instance Tag | IEEE 802.1Q Backbone Service Instance Tag EtherType (802.1QITagType) | 88-E7 |
VLAN Tag Control Information (TCI)
The VLAN TCI field is two octets in length and encodes the vlan_identifier, drop eligible, and priority parameters of the corresponding EISS M_UNITDATA.request as unsigned binary numbers
The VID is encoded in a 12-bit field. A VLAN Bride may not support the full range of VID values but shall support the use of all VID values in the range 0 through a maximum N, less than or equal to 4094 and specified for that implementation. The following table identifies VID values that have specific meanings or uses
NOTE 1 - There is a distinction between the range of VIDs that an implementation can support and the maximum number of active VIDs supported at any one time. An implementation supports only 16 active VIDs, for example, may use VIDs chosen from anywhere in the identifier space, or from a limited range. The latter can result in difficulties where different Bridges in the same network support different maximums. It is recommended that new implementations of this standard support the full range of VIDs, even if the number of active VIDs is limited
The priority and drop eligible parameters are conveyed in the 3-bit PCP field and the DEI field
NOTE 2 - Previous versions of this standard used bit 5 of octet 1 of the TCI in C-TAGs as a Canonical Format Indicator (CFI). Bridges conformant to this version of the standard will not interoperate with Bridges that set the CFI as a result of inserting C-TAGs in frames received from an IEEE 802.5 Token Ring LAN. Bridges conformant to this version of the standard will interoperate with Bridges that forward bit 5 of octet 1 as a CFI but do not 802.5 Token Ring interfaces
Support for double tags
When using a single VLAN tag, the tag in the security association name VLANTAG1 will be used. If a second tag is used, the tag in the security association named VLANTAG2 will be inserted between VLANTAG1 and the EthType of the packet as shown below
Secure frame generation
For each transmit request at the Controlled Port, the Secure Frame Generation process
a. Assigns the frame to an SA (10.5.1)
b. Assigns the nextPN variable for that SA to be used as the value of the PN in the SecTAG (10.5.2)
c. Encodes the octets of the SecTAG (10.5.3)
d. Provides the protection function (14.1, 10.5.4) of the Current Cipher Suite with
e. Receives the following parameters from the Cipher Suite protection operation
f. Issues a request to the Transmit Multiplexer with the destination and source MAC addresses, and priority of the frame as received from the Controlled Port, and an MPDU comprising the octets of the SecTAG, Secure Data, and the ICV concatenated in that order (10.5.5)
If the management control protectFrames is False, the preceding steps are omitted, an identical transmit request is made to the Transmit Multiplexer, and the OutPktsUntagged counter incremented
NOTE—This model of operation supports the externally observable behavior that can result when the Cipher Suite implementation calculates the Secure Data and ICV parameters for a number of frames in parallel, and the responses to protection and validation requests are delayed. Transmitted frames are not misordered
Transmit SA assignment
Each SA is identified by its Association Number (AN). Each frame is assigned to the SA identified by the current value of the encodingSA variable. This is updated following an LMI request from the KaY to start transmitting using the SA and can be read but not written by network management. Frames will be protected using the encodingSA immediately after the last frame assigned to the previous SA has been protected.
If the SA identified by the encodingSA is not available for use, and the management control protectFrames is set, MAC_Operational transitions to False for the Controlled Port, and frames are neither accepted or delivered using the port
Transmit PN assignment
The frame’s PN is set to the value of nextPN for the SA, and nextPN is incremented. If the nextPN variable for the encodingSA is zero (or 2 32 ) and the protectFrames control is set, MAC_Operational transitions to False for the Controlled Port and frames are neither accepted or delivered. The initial value of nextPN is set by the KaY via the LMI prior to use of the SA, and its current value can be read both while and after the SA is used to transmit frames. The value of nextPN can be read, but not written, by network management.
SecTAG encoding
The SecTAG is encoded as specified in Clause 9
Cryptographic protection
If the Cipher Suite is currently protecting frames using the previous SA and its SA Key, as reflected by the value of the encipheringSA, the frame can be queued awaiting protection. The value of the encipheringSA is updated, and protection of the frame parameters is started within a minimum frame size transmission delay, after the last frame has been protected using the previous key
The use of each of the Cipher Suites specified by this standard is specified in Clause 14, which takes precedence over any explanation in this or other clauses
The appropriate octet counter is incremented by the number of octets in the User Data (OutOctetsEncrypted if confidentiality protection was provided, and OutOctetsProtected otherwise)
Transmit request
If the MPDU composed of the concatenated octets of the SecTAG, Secure Data, and ICV exceeds the size of the MSDU supported by the Common Port, the frame is discarded and a counter incremented. Details of the discarded frame may be recorded to assist network management resolution of the problem. Otherwise, the parameters of the service request are submitted to the Transmit Multiplexer
Receive Secure frame verification
For each receive indication from the Receive Demultiplexer, the Secure Frame Verification process
a. Examines the user data for a SecTAG
b. Validates frames with a SecTAG as specified in 9.12
c. Extracts and decodes the SecTAG as specified in 9.3 through 9.9
d. Extracts the User Data and ICV as specified in 9.10 and 9.11
e. Assigns the frame to an SA (10.6.1)
f. Performs a preliminary replay check against the last validated PN for the SA (10.6.2)
g. Provides the validation function (14.1, 10.6.3) of the Current Cipher Suite with
h. Receives the following parameters from the Cipher Suite validation operation
i. Updates the replay check (10.6.4)
j. Issues an indication to the Controlled Port with the DA, SA, and priority of the frame as received from the Receive Demultiplexer, and the User Data provided by the validation operation (10.6.5).
If the management control validateFrames is not Strict, frames without a SecTAG are received, counted, and delivered to the Controlled Port; otherwise, they are counted and discarded. If validateFrames is Disabled, cryptographic validation is not applied to tagged frames, but frames whose original service user data can be recovered are delivered. Frames with a SecTAG that has the TCI E bit set but the C bit clear are discarded, as this reserved encoding is used to identify frames with a SecTAG that are not to be delivered to the Controlled Port. Figure 10-5 summarizes the operation of management controls and counters
Receive SA assignment
An SCI is associated with the received frame, and used to locate the receive SC. If an SCI is not explicitly encoded in the SecTAG, the default value established by the KaY for a single peer is used. If the SC is not found, it may be recorded to assist network management resolution of the problem, and:
a. If validateFrames is Strict or the C bit in the SecTAG is set, the InPktsNoSCI counter is incremented and the frame is discarded; otherwise
b. The InPktsUnknownSCI counter is incremented and the frame (with the SecTAG and ICV removed) is delivered to the Controlled Port
If the receive SC has been identified, the frame’s AN is used to locate the receive SA received frame and processing continues with the preliminary replay check. If the SA is not in use:
c. If validateFrames is Strict or the C bit is set, the frame is discarded and the InPktsNotUsingSA counter incremented; otherwise
d. The InPktsUnusedSA counter is incremented and the frame delivered to the Controlled Port
NOTE—The short phrase “the frame is discarded” is commonly used to express the more formal notion of not processing a service primitive (an indication or request) further and recovering the resources that embody the parameters of that service primitive. No further processing is applied. However, if a duplicate of the primitive has been submitted to another process, by the Receive Demultiplexer in this case, processing of that duplicate is unaffected
Preliminary replay check
If replayProtect control is enabled and the PN of the received frame is less than the lowest acceptable packet number (see 10.6.5) for the SA, the frame is discarded and the InPktsLate counter incremented.
NOTE—If the SC is supported by a network that includes buffering with priority queueing, such as a provider bridged network, delivered frames can be reordered.
Cryptographic validation
The frame can be queued awaiting validation. If the frame reception rate exceeds the Cipher Suite’s validation capabilities, the frame may be discarded and the InPktsOverrun counter incremented
If the validateFrames control is Disabled, the Cipher Suite validation is not used to validate the frame
If validateFrames is not Disabled, and the E bit in the SecTAG is set, the Cipher Suite is used to validate and decrypt the frame. If the Cipher Suite does not provide confidentiality protection, it shall not return VALID
The InOctetsDecrypted counter is incremented by the number of octets in the resulting User Data (or an estimate of that number, if VALID is not returned)
If validateFrames is not Disabled, and the E bit in the SecTAG is clear, the Cipher Suite is used to validate the frame. If the Cipher Suite does not provide integrity protection without confidentiality it shall not return VALID. The InOctetsValidated counter is incremented by the number of octets in the resulting User Data (or an estimate of that number, if VALID is not returned)
The frame is marked valid if the Cipher Suite is used and returns VALID, and is marked invalid otherwise. The use of each of the Cipher Suites specified by this standard is specified in Clause 14, which takes precedence over any explanation in this or other clauses
Replay check update
If the PN of the received frame is less than the lowest acceptable packet number for the SA, and replayProtect is enabled, the frame is discarded and the InPktsLate counter incremented.
NOTE—This model of operation assumes that any queuing within the verification process occurs prior to frame validation, and the check described uses the lowest acceptable PN updated by prior frames as described below (10.6.5). Implementations can process frames as convenient, provided the externally observable result is the same.
Receive indication
If the received frame is marked as invalid, and the validateFrames control is Strict or the C bit in the SecTAG was set, the frame is discarded and the InPktsNotValid counter incremented. Otherwise the frame is delivered to the Controlled Port, and the appropriate counter incremented as follows:
a. If the frame is not valid and validateFrames is set to Check, InPktsInvalid, otherwise
b. If the received PN is less than the lowest acceptable PN (treating a PN value of zero as 2 32 ), InPktsDelayed, otherwise
c. If the frame is not valid, InPktsUnchecked, otherwise
d. InPktsOK
If the PN for the frame was equal to or greater than the nextPN variable for the SA, nextPN is set to the value for the received frame, incremented by one. The lowest acceptable PN variable is set to the greater of its existing value and the value of nextPN minus the replayWindow variable.
NOTE—The lowest acceptable packet number can also be set or incremented by the KaY to ensure timely delivery.
A Cipher Suite is an interoperable specification of cryptographic algorithms together with the values of parameters (for example, key size) to be used by those algorithms. Specification of the cryptographic functions required by MAC Security in terms of Cipher Suites increases interoperability by providing a clear default and a limited number of alternatives.
This clause specifies
NOTE —The choice and combination of cryptographic methods is notorious for the introduction of unexpected security exposures. Each Cipher Suite is an algorithm or combination of algorithms whose interactions have been studied by the professional security community
Cipher Suite use
A Cipher Suite is initialized with one or more Cipher Suite dependent keys, and then used to protect protocol parameters. Any implementation of the same Cipher Suite, initialized with the same key values, can be used to validate and recover the protected parameters. The protect and validate operations are illustrated in Figure 14-1, and their inputs and outputs specified below
The SAK (Secure Association Key, 3.36, 7.1) is the value of the Cipher Suite dependent key(s)
The SCI (Secure Channel Identifier, 3.36, 7.1.2) is a 64-bit identifier that is globally unique amongst all correctly configured Cipher Suite implementation instances protecting MACsec protocol parameters
The PN (Packet Number, 3.27, 8.3) is a 32-bit number that is never zero, is incremented each time a protect request is made for a given SCI, and is never repeated for an SCI unless the SAK is changed
The Destination Address and Source Address are the MAC addresses of the frame. MAC Addresses are specified as octet strings, using the canonical format specified in IEEE Std 802
The SecTAG is as specified in Clause 9
The ICV (Integrity Check Value, 3.13, 8.3) is a string of octets. VALID is a Boolean parameter. If TRUE the validation was successful
Given the SAK, SCI, PN, Source Address, Destination Address, SecTAG, and the User Data, the Protect operation returns the Secure Data and ICV.
Given the same SAK, SCI, PN, Source Address, Destination Address, and SecTAG, and the Secure Data and ICV, the Verify operation returns the original User Data and VALID. If any of the parameters were modified, VALID is returned False.
Cipher Suite capabilities
Any Cipher Suite used with MACsec shall
and may
and shall not
An implementation of MACsec for which conformance to this standard is claimed includes at least one Cipher Suite that provides integrity without confidentiality, with the Secure Data the same as the User Data, and the ICV comprising 16 octets. This requirement is met by the mandatory Default Cipher Suite.
Cipher Suite specification
Each Cipher Suite specification shall comprise an interoperable specification of the protection and verification procedures in terms of the parameters specified in 14.1 and shall state
NOTE—While this standard provides definitive specifications of the Cipher Suites that support full conformance, those specifications make the greatest possible use of other public and established standards, and are principally concerned with ensuring unambiguous application of those standards in the context of MAC Security.
Cipher Suite conformance
An implementation of MAC Security that claims full conformance to this standard shall implement the mandatory Cipher Suites in Table 14-1, may implement one or more of the Optional Cipher Suites in the table, and shall not implement any other Cipher Suite. Every conformant implementation shall include at least one Cipher Suite that does not encrypt User Data.
NOTE —Currently, Table 14-1 does not include any optional Cipher Suites.
Table 14-1 assigns a Cipher Suite reference number for use in protocol identification within a MACsec context, provides a short name for use in this standard, indicates the type of cryptographic algorithm used and the security services provided, specifies whether the Cipher Suite is mandatory or optional for conformance to this standard, and references the clause of this standard that provides the definitive description of the Cipher Suite.
Conformance with Cipher Suite variance
An implementation of MAC Security that claims conformance to this standard with Cipher Suite variance, shall implement the mandatory Cipher Suites in Table 14-1, may implement one or more of the optional Cipher Suites in Table 14-1, and may implement alternate Cipher Suites that meet the requirements of 14.2 and 14.3, and the following guidelines, and shall not implement any other Cipher Suite, or other combination of cryptographic algorithms and parameters.
The use of additional Cipher Suites shall meet the following guidelines:
Default Cipher Suite (GCM–AES–128)
The Default Cipher Suite uses the Galois/Counter Mode of Operation with the AES-128 symmetric block cipher, as specified in this clause by reference to the terms K, IV, A, P, C, T used in section 2.1 of the GCM specification (GCM) as submitted to NIST.
K is the 128 bit SAK. The 64 most significant bits of the 96-bit IV are the octets of the SCI, encoded as a binary number (9.1). The 32 least significant bits of the 96-bit IV are the octets of the PN, encoded as a binary number (9.1). T is the ICV and is 128 bits long. When the bit-strings A, P, and C are specified in terms of octet strings, earlier octets compose earlier bits, and more significant bits in each octet are earlier.
NOTE—The bit strings obtained by transforming MAC Address and data octets using these rules do not correspond to IEEE 802.3 “wire order” for frame transmission.
When the Default Cipher Suite is used for Integrity Protection
When the Default Cipher Suite is used for Confidentiality Protection without a confidentiality offset
When the Default Cipher Suite is used for Confidentiality Protection with a confidentiality offset
Amendment 2: Extended Packet Numbering
This amendment to IEEE Std 802.1AE-2006 allows more than MACsec protected frames to be sent using a single Secure Association Key (SAK) by enabling the use of a 64-bit Packet Number (PN) and specifying two Cipher Suites (GCM-AES-XPN-128 and GCM-AES-XPN-256) that use that extended packet numbering as part of their Initial Value (IV) construction. MACsec frame formats and principles of MAC Security Entity operation remain unchanged. Changes are applied to the base text of IEEE Std 802.1AE-2006 as amended by IEEE Std 802.1AEbn-2011
The 32 least significant bits of the PN is are encoded in octets 5 through 8 of the SecTAG to
NOTE 1 — As specified in this clause, the IV used by the default Cipher Suite (GCM-AES-128) comprises the SCI (even if the SCI is not transmitted in the SecTAG) and the a 32-bit PN. Subject to proper unique MAC Address allocation procedures, the SCI is a globally unique identifier for a SecY. To satisfy the IV uniqueness requirements of CTR mode of operation, a fresh key is used before PN values are reused
NOTE 2 — If the Current Cipher Suite provides extended packet numbering, i.e. uses a 64-bit PN, the 32 least significant bits of the PN are conveyed in this SecTAG field and the 32 most significant bits are recovered on receipt as specified in 10.6. The IV used by such a Cipher Suite (e.g. GCM-AES-XPN-128, 14.7) comprises a 32-bit SSCI distributed by key agreement protocol and unique for each SCI within the scope of the CA (and hence within potential users of the same SAK) and the 64-bit non-repeating PN
If the Current Cipher Suite does not use extended packet numbering, i.e. the PN comprises 32-bits, the value of the PN is that of the lower 32 bits decoded from the SecTAG of the received frame. If extended packet numbering is used, the 32 most significant bits are recovered for each received frame as specified in by applying the assumption that they have remained unchanged since their use in the frame with the lowest acceptable PN (10.6.2) — unless the most significant of the 32 least significant bits of the lowest acceptable PN is set and the corresponding bit of the received PN is not set, in which case the 32 most significant bits of the PN are those of the lowest acceptable PN incremented by one
NOTE—If a large number of successive frames were to be lost ( , corresponding to approximately 9 seconds of full utilization of a 400 Gb/s link by minimum sized Ethernet frames) subsequent receipt of MACsec frames might fail to establish a correct PN value. MKA, the MACsec Key Agreement protocol specified in IEEE Std 802.1X and its amendments communicates the value of the high order bits periodically to recover from this eventuality
If the Current Cipher Suite uses extended packet numbering, i.e. a 64-bit PN, then the maximum value of replayWindow used in the Secure Frame Verification process (10.6) is , but any higher value set by network management is retained for possible subsequent use with a different Cipher Suite and will be reported if read by network management. This provision provides compatibility with prior revisions of this standard, though it is unlikely that such a high value of replayWindow would have been used
A receive SA is created for an existing SC on request from the KaY, with the following parameters:
and, if the Current Cipher Suite uses extended packet numbering (e.g. 14.7, 14.8), the following parameter:
An SA is created for the transmit SC on request from the KaY, with the following parameters:
and, if the Current Cipher Suite uses extended packet numbering(e.g. 14.7, 14.8), the following parameter:
An SAK record is created on request from the KaY, with the following parameters:
and, if the Current Cipher Suite uses extended packet numbering, the following parameter:
The PN (Packet Number, 3.27, 8.3) is a 32-bit number that is never zero, is incremented each time a protect request is made for a given SCI, and is never repeated for an SCI unless the SAK is changed. The size of the PN depends on the Cipher Suite, and is 32-bits unless otherwise specified. Cipher suites that provide extended packet numbering use a 64-bit PN. Irrespective of the size of the PN, only the least significant 32- bits are conveyed in the SecTAG. If extended packet numbering is used, the most significant 32-bits are recovered for each received frame as specified in 10.6.2.
GCM–AES–256
GCM-AES-256 uses the Galois/Counter Mode of operation with the AES-256 symmetric block cipher, as specified in this clause by reference to the terms K, IV, A, P, C, T used in NIST SP 800-38D. K is the 256 bit SAK. The 64 most significant bits of the 96-bit IV are the octets of the SCI, encoded as a binary number (9.1). The 32 least significant bits of the 96-bit IV are the octets of the PN, encoded as a binary number (9.1). T is the ICV, and is 128 bits long. When the bit-strings A, P, and C are specified in terms of octet strings, earlier octets compose earlier bits, and more significant bits in each octet are earlier
NOTE — The bit strings obtained by transforming MAC Address and data octets using these rules do not correspond to 802.3 'wire order' for frame transmission.
When the Default Cipher Suite is used for Integrity Protection
When the Default this Cipher Suite is used for Confidentiality Protection without a confidentiality offset
When the Default this Cipher Suite is used for Confidentiality Protection with a confidentiality offset
GCM–AES–XPN-128
Each instance of the GCM-AES-XPN-128 Cipher Suite, i.e. the protection and validation capabilities created for a given SAK at the request of the KaY (10.7.26, Figure 10-6) maintains an instance of the following parameter as specified in 10.7.23:
The MACsec Key Agreement (MKA) protocol specified in IEEE 802.1X-2010 does not include explicit parameters for distributing the Salt (applicable to all SAs using a given SAK) or the SSCI (applicable to a given SA, using a given SAK) explicitly. Each KaY computes these parameters from the MKA protocol information as follows. The 64 least-significant bits of the Salt comprise the SCI of the MKA Key Server, and the 32 most significant bits of the Salt comprise the value obtain by the exclusive-or of the 32 most significant and the 32 least significant bits of that SCI. The KaY with numerically greatest SCI uses the SSCI value 0x0001, the KaY with the next to the greatest SCI uses the SSCI value 0x0002, and so on
NOTE 1 — This procedure does not ensure that the Salt is secret. Readers of this standard are encouraged to consult the latest revision of 802.1X and its amendments
NOTE 2 — MKA guarantees that each KaY that receives a given SAK has a unique SCI, and these SCIs are present in every MKPDU that conveys a (key-wrapped) SAK
GCM-AES-XPN-128 uses the Galois/Counter Mode of operation with the AES-128 symmetric block cipher, as specified in this clause by reference to the terms K, IV, A, P, C, T used in NIST SP 800-38D. K is the 128 bit SAK. The 32 most significant bits of the 96-bit IV are the octets of the SSCI, encoded as a binary number (9.1) and exclusive-or’d with the 32 most significant bits of the Salt. The 64 least significant bits of the 96-bit IV are the octets of the PN, encoded as a binary number (9.1) and exclusive-or’d with the 64 least significant bits of the Salt. T is the ICV, and is 128 bits long. When the bit-strings A, P, and C are specified in terms of octet strings, earlier octets compose earlier bits, and more significant bits in each octet are earlier
NOTE 3 — The bit strings obtained by transforming MAC Address and data octets using these rules do not correspond to 802.3 'wire order' for frame transmission
When this Cipher Suite is used for Integrity Protection
When this Cipher Suite is used for Confidentiality Protection without a confidentiality offset
This Cipher Suite does not provide Confidentiality Protection with a confidentiality offset
GCM–AES–XPN-256
Each instance of the GCM-AES-XPN-256 Cipher Suite, i.e. the protection and validation capabilities created for a given SAK at the request of the KaY (10.7.26, Figure 10-6) maintains an instance of the following parameter as specified in 10.7.23:
The MACsec Key Agreement (MKA) protocol specified in IEEE 802.1X-2010 does not include explicit parameters for distributing the Salt (applicable to all SAs using a given SAK) or the SSCI (applicable to a given SA, using a given SAK) explicitly. Each KaY computes these parameters from the MKA protocol information as follows. The 64 least-significant bits of the Salt comprise the SCI of the MKA Key Server, and the 32 most significant bits of the Salt comprise the value obtain by the exclusive-or of the 32 most significant and the 32 least significant bits of that SCI. The KaY with numerically greatest SCI uses the SSCI value 0x0001, the KaY with the next to the greatest SCI uses the SSCI value 0x0002, and so on
NOTE 1 — This procedure does not ensure that the Salt is secret. Readers of this standard are encouraged to consult the latest revision of 802.1X and its amendments
NOTE 2 — MKA guarantees that each KaY that receives a given SAK has a unique SCI, and these SCIs are present in every MKPDU that conveys a (key-wrapped) SAK
GCM-AES-XPN-256 uses the Galois/Counter Mode of operation with the AES-256 symmetric block cipher, as specified in this clause by reference to the terms K, IV, A, P, C, T used in NIST SP 800-38D
K is the 256 bit SAK. The 32 most significant bits of the 96-bit IV are the octets of the SSCI, encoded as a binary number (9.1) and exclusive-or’d with the 32 most significant bits of the Salt. The 64 least significant bits of the 96-bit IV are the octets of the PN, encoded as a binary number (9.1) and exclusive-or’d with the 64 least significant bits of the Salt. T is the ICV, and is 128 bits long. When the bit-strings A, P, and C are specified in terms of octet strings, earlier octets compose earlier bits, and more significant bits in each octet are earlier
NOTE 3 — The bit strings obtained by transforming MAC Address and data octets using these rules do not correspond to 802.3 'wire order' for frame transmission
When this Cipher Suite is used for Integrity Protection
When this Cipher Suite is used for Confidentiality Protection without a confidentiality offset
This Cipher Suite does not provide Confidentiality Protection with a confidentiality offset
For API Documentation:
For Additional Documentation:
The source code contained or described herein and all documents related to the source code (herein called "Material") are owned by John Peter Greninger and Sheila Rocha Greninger. Title to the Material remains with John Peter Greninger and Sheila Rocha Greninger. The Material contains trade secrets and proprietary and confidential information of John Peter Greninger and Sheila Rocha Greninger. The Material is protected by worldwide copyright and trade secret laws and treaty provisions. No part of the Material may be used, copied, reproduced, modified, published, uploaded, posted, transmitted, distributed, or disclosed in any way without prior express written consent of John Peter Greninger and Sheila Rocha Greninger (both are required)
No license under any patent, copyright, trade secret, or other intellectual property right is granted to or conferred upon you by disclosure or delivery of the Materials, either expressly, by implication, inducement, estoppel, or otherwise. Any license under such intellectual property rights must be express and approved by John Peter Greninger and Sheila Rocha Greninger in writing
Licensing information can be found at www.protocolpp.com/license with use of the binary forms permitted provided that the following conditions are met:
Use of the source code requires purchase of the source code. Source code can be purchased at www.protocolpp.com/shop
The name of its contributor may not be used to endorse or promote products derived from this software without specific prior written permission and licensing
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDER AND CONTRIBUTOR "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE