EAP

This document defines the Extensible Authentication Protocol (EAP),
 an authentication framework which supports multiple authentication
 methods. EAP typically runs directly over data link layers such as
 Point-to-Point Protocol (PPP) or IEEE 802, without requiring IP. 

EAP (Extensible Authentication Protocol)
 provides its own support for duplicate elimination and
 retransmission, but is reliant on lower layer ordering guarantees.
 Fragmentation is not supported within EAP itself; however, individual
 EAP methods may support this.

 While EAP provides support for retransmission, it assumes ordering
 guarantees provided by the lower layer, so out of order reception is
 not supported.

 Since EAP does not support fragmentation and reassembly, EAP
 authentication methods generating payloads larger than the minimum
 EAP MTU need to provide fragmentation support.

While authentication methods such as EAP-TLS [RFC2716] provide
 support for fragmentation and reassembly, the EAP methods defined in
 this document do not. As a result, if the EAP packet size exceeds
 the EAP MTU of the link, these methods will encounter difficulties.

Note that EAP Success and Failure packets are not retransmitted.
 Without a reliable lower layer, and with a non-negligible error rate,
 these packets can be lost, resulting in timeouts. It is therefore
 desirable for implementations to improve their resilience to loss of
 EAP Success or Failure packets, as described in Section 4.2.


EAP
 encapsulation on IEEE 802 wired media is described in [IEEE-802.1X],
 and encapsulation on IEEE wireless LANs in [IEEE-802.11i].
The encapsulation of EAP over IEEE 802 is defined in [IEEE-802.1X].

Extensible Authentication Protocol (EAP) over LAN (EAPoL Protocol) is a network port authentication protocol 
used in IEEE 802.1X (Port Based Network Access Control) developed to give a generic network sign-on to access network resources.

[1] Unreliable transport. In EAP, the authenticator retransmits
 Requests that have not yet received Responses so that EAP does
 not assume that lower layers are reliable. Since EAP defines its
 own retransmission behavior, it is possible (though undesirable)
 for retransmission to occur both in the lower layer and the EAP
 layer when EAP is run over a reliable lower layer.

[2] Lower layer error detection. While EAP does not assume that the
 lower layer is reliable, it does rely on lower layer error
 detection (e.g., CRC, Checksum, MIC, etc.). EAP methods may not
 include a MIC, or if they do, it may not be computed over all the
 fields in the EAP packet, such as the Code, Identifier, Length,
 or Type fields. As a result, without lower layer error
 detection, undetected errors could creep into the EAP layer or
 EAP method layer header fields, resulting in authentication
 failures.
 For example, EAP TLS [RFC2716], which computes its MIC over the
 Type-Data field only, regards MIC validation failures as a fatal
 error. Without lower layer error detection, this method, and
 others like it, will not perform reliably.

[3] Lower layer security. EAP does not require lower layers to
 provide security services such as per-packet confidentiality,
 authentication, integrity, and replay protection. However, where
 these security services are available, EAP methods supporting Key
 Derivation (see Section 7.2.1) can be used to provide dynamic
 keying material. This makes it possible to bind the EAP
 authentication to subsequent data and protect against data
 modification, spoofing, or replay. See Section 7.1 for details.

[4] Minimum MTU. EAP is capable of functioning on lower layers that
 provide an EAP MTU size of 1020 octets or greater.

EAP does not support path MTU discovery, and fragmentation and
 reassembly is not supported by EAP, nor by the methods defined in
 this specification: Identity (1), Notification (2), Nak Response
 (3), MD5-Challenge (4), One Time Password (5), Generic Token Card
 (6), and expanded Nak Response (254) Types.

Typically, the EAP peer obtains information on the EAP MTU from
 the lower layers and sets the EAP frame size to an appropriate
 value. Where the authenticator operates in pass-through mode,
 the authentication server does not have a direct way of
 determining the EAP MTU, and therefore relies on the
 authenticator to provide it with this information, such as via
 the Framed-MTU attribute, as described in [RFC3579], Section 2.4.

EAP methods can assume a minimum EAP MTU of 1020 octets in the
 absence of other information. EAP methods SHOULD include support
 for fragmentation and reassembly if their payloads can be larger
 than this minimum EAP MTU.

[5] Possible duplication. Where the lower layer is reliable, it will
 provide the EAP layer with a non-duplicated stream of packets.
 However, while it is desirable that lower layers provide for
 non-duplication, this is not a requirement. The Identifier field
 provides both the peer and authenticator with the ability to
 detect duplicates.
 [6] Ordering guarantees. EAP does not require the Identifier to be
 monotonically increasing, and so is reliant on lower layer
 ordering guarantees for correct operation. EAP was originally
 defined to run on PPP, and [RFC1661] Section 1 has an ordering
 requirement:

The EAP authentication exchange proceeds as follows:
 [1] The authenticator sends a Request to authenticate the peer. The
 Request has a Type field to indicate what is being requested.
 Examples of Request Types include Identity, MD5-challenge, etc.
 The MD5-challenge Type corresponds closely to the CHAP
 authentication protocol [RFC1994]. Typically, the authenticator
 will send an initial Identity Request; however, an initial
 Identity Request is not required, and MAY be bypassed. For
 example, the identity may not be required where it is determined
 by the port to which the peer has connected (leased lines,dedicated switch or dial-up ports), or where the identity is
 obtained in another fashion (via calling station identity or MAC
 address, in the Name field of the MD5-Challenge Response, etc.).

 [2] The peer sends a Response packet in reply to a valid Request. As
 with the Request packet, the Response packet contains a Type
 field, which corresponds to the Type field of the Request.

 [3] The authenticator sends an additional Request packet, and the
 peer replies with a Response. The sequence of Requests and
 Responses continues as long as needed. EAP is a ’lock step’
 protocol, so that other than the initial Request, a new Request
 cannot be sent prior to receiving a valid Response. The
 authenticator is responsible for retransmitting requests as
 described in Section 4.1. After a suitable number of
 retransmissions, the authenticator SHOULD end the EAP
 conversation. The authenticator MUST NOT send a Success or
 Failure packet when retransmitting or when it fails to get a
 response from the peer.

 [4] The conversation continues until the authenticator cannot
 authenticate the peer (unacceptable Responses to one or more
 Requests), in which case the authenticator implementation MUST
 transmit an EAP Failure (Code 4). Alternatively, the
 authentication conversation can continue until the authenticator
 determines that successful authentication has occurred, in which
 case the authenticator MUST transmit an EAP Success (Code 3).

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Code        |    Identifier |                        Length   |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Data ...
 +-+-+-+-+

The Code field is one octet and identifies the Type of EAP packet.
 EAP Codes are assigned as follows:
 1 Request
 2 Response
 3 Success
 4 Failure

Identifier
 The Identifier field is one octet and aids in matching Responses
 with Requests.

Length
 The Length field is two octets and indicates the length, in
 octets, of the EAP packet including the Code, Identifier, Length,
 and Data fields. Octets outside the range of the Length field
 should be treated as Data Link Layer padding and MUST be ignored
 upon reception. A message with the Length field set to a value
 larger than the number of received octets MUST be silently
 discarded.

Data
 The Data field is zero or more octets. The format of the Data
 field is determined by the Code field.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Code        |    Identifier |                        Length   |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Type        | Type-Data ...
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

 Code
 1 for Request
 2 for Response

 Type
 The Type field is one octet. This field indicates the Type of
 Request or Response. A single Type MUST be specified for each EAP
 Request or Response. An initial specification of Types follows in
 Section 5 of this document.

 1 Identity
 2 Notification
 3 Nak (Response only)
 4 MD5-Challenge
 5 One Time Password (OTP)
 6 Generic Token Card (GTC)
 254 Expanded Types
 255 Experimental use

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Code        |    Identifier |                        Length   |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Code
 3 for Success
 4 for Failure

https://networklessons.com/cisco/ccnp-encor-350-401/eapol-extensible-authentication-protocol-over-lan

EAP-TLS是EAP的一种authenticate method.可以安全的进行双向认证。通过EAP-TLS报文封装TLS报文实现TLS协商。
MACsec是在EAP验证通过之后会生成一个master session key (CAK?)，然后根据CAK并通过EAPOL-MKA协商出MACSec tunnel去保护用户数据.

https://www.autosar.org/fileadmin/standards/R23-11/AP/AUTOSAR_AP_EXP_MACsec.pdf

4.1 MACsec
MACsec is a network security standard that operates at the Media Access Control
(MAC) layer (Layer 2) and defines connectionless data confidentiality and integrity for
media access independent protocols. MACsec stands for Media Access Control Security and it is defined and specified on the IEEE 802.1AE standard ([3, IEEE-802.1AE2018]). It is a point-to-point (P2P) protection mechanism, which provides secure communication for Ethernet Networks, specifically protects communication channels within
the vehicle network.

4.2 MACsec Key Agreement protocol (MKA)
The purpose of the MACsec Key Agreement (MKA) protocol is to provide a mechanism
to discover MACsec peers and negotiate the security keys required to secure the link.
There are two mechanisms defined within the 802.1X standard for the generation of
key material for the use with MKA:
• Pre-shared Keys (PSK).
• The master session key which is a product of a successful Extensible Authentication Protocol (EAP) authentication. (More information on the [4, IEEE-802.1X2020])