Supported in IPsec

RFC 3748 - Extensible Authentication Protocol (EAP)

Every requirement this repository extracted from RFC 3748, the tests bound to it, and what a reader has verified about them. This summary is enrolled and gated by ./le rfc check.

Overview

Positive

what Ze has

Tested both ways62.3%33 of 53 binding obligations

a positive test proves Ze does what the requirement demands and a negative one proves it refuses what the requirement forbids

One polarity plus reason9.4%5 of 53 binding obligations

the requirement admits no counter-case, so one polarity plus a recorded reason is the whole proof available for it

One polarity, unexcused0.0%0 of 53 binding obligations

one direction is tested, the other is neither tested nor excused, and nothing states which

Proven by a recorded break44.2%34 of 77 tagged units

a red was observed once under a recorded procedure, and the unit, the claim and the producer it rested on still hash to what was recorded. The break is not re-run. A test pair is not a proof until one has been observed

Neutral

measures that are neither good news nor bad

Gated MUSTs61of 67 this summary declares

MUST-level requirements the gate HOLDS. A population, not a result: the shares beside it are what says how Ze stands

Out of scope8of 61 gated MUSTs

a {not-applicable} annotation says the obligation does not bind Ze. Scope, not coverage: it is in no share below

Negative

what Ze owes

No test at all28.3%15 of 53 binding obligations

no test carries the requirement id, whether or not a gap states why

The 4 shares marked as a part above are the whole of the 53 obligations that bind Ze: they add to 100%. Proven by a recorded break is a share of TAGGED UNITS, a different population, so it is not one of them.

How to read the colors

A color names what the measure MEANS, not how well Ze scores on it. Green is a good outcome at any value, red is a bad one, and neither a population nor a scope count is an outcome, so both take no color. The number under the label is what says how far Ze has got.

Card	Tone here	Why that color
Gated MUSTs	neutral	no color: a population is a scale, and a larger one is neither good news nor bad. It is the accounting total
Out of scope	neutral	no color: an obligation that never bound Ze is neither an achievement nor a failure, and counting it either way would be a claim
Tested both ways	ok	green at every value: a test pair is the outcome this gate exists to produce, and the share under the label is what says how far Ze has got
One polarity plus reason	ok	green at every value: where no counter-case exists, one polarity IS the complete answer, and a recorded reason is what the gate demands beside it
One polarity, unexcused	ok	green at zero, RED above it: half a proof with no reason for the other half
No test at all	bad	green at zero, RED above it: a binding obligation nothing exercises is a claim with nothing behind it, whether or not a reason is stated
Proven by a recorded break	ok	green at every value: an observed break is the outcome the discrimination gate exists to produce. The denominator is TAGGED UNITS, not obligations, so this share is not one of the parts above
Audit verdicts	warn	RED on the first weak, wrong or unimplemented verdict, amber while a verdict is no longer current or a gated MUST is unjudged, green when every one is judged sound and current

At a glance

Field	Value
Public status	Supported in IPsec
Enrolment	Enrolled
Requirements	67
Gated MUST-level	61
Obligations that bind Ze	53
Not applicable, so out of scope	8
Declared gaps	0
Gated with no test	15
Nightly-only evidence	0
Test tags	77
Tagged units	77
Recorded audit verdicts	0
Discrimination records	34
Summary	`rfc/short/rfc3748.md`
Requirement shard	`rfc/requirements/rfc3748.md`
RFC text	`rfc/full/rfc3748.txt`

Enrolment

Enrolled: Extensible Authentication Protocol / EAP (RFC 3748): IKEv2-carried EAP peer + co-located authenticator (EAP-TLS, EAP-MSCHAPv2, local termination, no pass-through). Both roles are gated: the packet format and its length handling, the Identifier and Type rules that bind a Request to its Response, one method per conversation, method completion -> Success/Failure, the 4-octet terminal packet, the peer's end of an unsuccessful method, and four silent discards -- a Code outside 1-4 by either role, and by the peer a canned Success, a Success the method does not permit yet, and a Failure after both ends indicated success. A non-Response carrying a DEFINED Code is still answered with EAP-Failure; a Code outside 1-4 is discarded, which corrects a row that claimed the first behavior for every non-Response (2026-09-01). Lower-layer ordering, error detection, MTU and duplicate detection are the IKEv2 carrier's, pass-through and Expanded Types are out of scope, and no EMSK is derived.

What the public ledger says

Status: Supported in IPsec

What the ledger says is covered

EAP framework inside IKEv2 IKE_AUTH, Success and Failure handling, and the Section 4.2 discards that stop a rogue authenticator bypassing the method: the peer reads an EAP-Success only once the method conversation concluded, drops an EAP-Failure once both ends indicated success, and both roles drop a Code outside 1-4 (PeerSession.Process and Session.Process, internal/component/ike/eap). The peer answers Type 1 (Identity), Type 2 (Notification) and Type 3 (Nak): a Notification Request draws a five-octet Notification Response and its message reaches the operator log, and a Request for an authentication Type ze does not run draws a six-octet legacy Nak naming the configured method, until the peer has answered a method Request and Section 2.1 closes the Nak (PeerSession.handleRequest, internal/component/ike/eap/peer.go). A Type-254 Request draws the same legacy Nak, which is what Section 5.7 prescribes for a peer not equipped to interpret an Expanded Type. Type 4 (MD5-Challenge) runs on both roles and is the authentication { mode eap-md5 } an operator selects. It is never a default, and adopting a configuration that names it writes one warning quoting the RFC 7296 Section 2.16 sentence that discourages a method establishing no shared key (warnKeylessEAPModes, internal/component/ike/engine/eap_auth.go).

What the ledger says remains

Ze reads no Expanded Type (254), which Section 5 states as a SHOULD, and answers a Type-254 Request with the legacy Nak Section 5.7 prescribes rather than composing an Expanded Nak. Ze's authenticator sends no Notification Request, which RFC 3748 Section 5.2 states as an option ("An authenticator MAY send a Notification Request to the peer at any time when there is no outstanding Request, prior to completion of an EAP authentication method") and which the owner declined on 2026-09-01; Ze's peer answers one, which is the mandatory half. Two further features are absent by decision rather than by omission, and neither is a conformance gap. Ze's authenticator terminates every EAP method locally and does not act as a pass-through agent for a backend authentication server; Section 2 says "Support for pass-through is optional". Ze offers neither the One Time Password method (Type 5) nor the Generic Token Card method (Type 6), which Section 5 leaves to the implementation ("Implementations MAY support other Types defined here or in future RFCs"). A later scope decision can revisit any of the three. The Type 4 (MD5-Challenge) deviation authorized on 2026-08-30 was WITHDRAWN by the owner on 2026-09-01, who ordered the method implemented; both roles now run it.

Coverage

Bucket	Count	What it counts
Positive and negative tests	33	one part of the gated population
Annotated instead of tested	13	one part of the gated population
One polarity only	0	one part of the gated population
No test and no annotation	15	one part of the gated population
Evidence that runs nightly only	0	an overlay: each of these is also counted by the part it falls in
Gated MUST-level requirements	61	every gated MUST falls in exactly one bucket above

Positive and negative tests (33): RFC3748-4-1, RFC3748-4-2, RFC3748-2-2, RFC3748-2.1-1, RFC3748-2.1-2, RFC3748-2.1-3, RFC3748-4.2-2, RFC3748-4-4, RFC3748-4.1-3, RFC3748-4.1-4, RFC3748-4.1-5, RFC3748-4.2-5, RFC3748-4.2-6, RFC3748-4-5, RFC3748-4.2-7, RFC3748-4.2-8, RFC3748-4.2-9, RFC3748-4.1-10, RFC3748-4.1-11, RFC3748-2.1-4, RFC3748-5-1, RFC3748-5-2, RFC3748-5.2-1, RFC3748-5.2-2, RFC3748-5.3.1-1, RFC3748-5.3.1-2, RFC3748-5.3.1-3, RFC3748-5.3.1-4, RFC3748-5.4-1, RFC3748-5.4-2, RFC3748-5.1-2, RFC3748-7.5-1, RFC3748-7.10-4

Annotated instead of tested (13): RFC3748-2-1, RFC3748-4.1-1, RFC3748-4.1-2, RFC3748-4.2-1, RFC3748-4.2-4, RFC3748-2.3-1, RFC3748-3.1-1, RFC3748-3.1-2, RFC3748-3.1-3, RFC3748-3.1-4, RFC3748-5.7-1, RFC3748-7.10-1, RFC3748-7.10-2

No test and no annotation (15): RFC3748-2-3, RFC3748-2.2-1, RFC3748-4.1-6, RFC3748-4.1-7, RFC3748-4.1-8, RFC3748-4.1-9, RFC3748-4.2-15, RFC3748-4.2-10, RFC3748-4.2-11, RFC3748-4.2-12, RFC3748-4.2-13, RFC3748-4.2-14, RFC3748-7.10-5, RFC3748-7.10-6, RFC3748-7.10-7

Requirements

Requirement	Level	Section	Tests
`RFC3748-4-1`	Packets shorter than the Length field indicates MUST be silently discarded (S4)
	MUST	4	positive`unit/verifyTestRFC3748PacketLengthDiscard` negative`unit/verifyTestRFC3748PacketLengthDiscard`
`RFC3748-4-2`	Minimum EAP packet length is 4 octets (S4)
	MUST	4	positive`unit/verifyTestRFC3748MinimumPacketLength` negative`unit/verifyTestRFC3748MinimumPacketLength`
`RFC3748-2-1`	The authenticator MUST operate in lock-step: only one outstanding Request at a time (S2)
	MUST	2	positive`unit/verifyTestRFC3748AuthenticatorLockStep` negative`no test`no negative test {single-polarity}: the authenticator Session emits one packet per call -- Begin returns a single Request (internal/component/ike/eap/eap.go:164) and each Process returns a single *Packet (eap.go:176), so a new Request cannot precede its Response and no path leaves two outstanding, giving no negative case
`RFC3748-2-2`	The authenticator MUST receive a valid Response before sending a new Request (S2)
	MUST	2	positive`unit/verifyTestRFC3748AuthenticatorRequiresValidResponse` negative`unit/verifyTestRFC3748AuthenticatorRequiresValidResponse`
`RFC3748-2.1-1`	Only one authentication method (Type >= 4) per EAP conversation (S2.1)
	MUST	2.1	positive`unit/verifyTestRFC3748OneMethodPerConversation` negative`unit/verifyTestRFC3748OneMethodPerConversation`
`RFC3748-2.1-2`	After the method completes, the authenticator MUST send Success or Failure (S2.1)
	MUST	2.1	positive`unit/verifyTestRFC3748MethodCompletionSendsResult` negative`unit/verifyTestRFC3748MethodCompletionSendsResult`
`RFC3748-2.1-3`	The peer MUST NOT send a NAK (Type 3) after the first non-NAK Response in a conversation (S2.1, S5.3)
	MUST	2.1	positive`unit/verifyTestRFC3748PeerNaksBeforeItCommitsToAMethod` negative`unit/verifyTestRFC3748PeerNaksBeforeItCommitsToAMethod`
`RFC3748-4.1-1`	Only the authenticator retransmits on timer; the peer MUST NOT retransmit on its own timer (S4.1)
	MUST	4.1	positive`unit/verifyTestRFC3748PeerHasNoRetransmitTimer` negative`no test`no negative test {single-polarity}: the EAP peer (PeerSession.Process, internal/component/ike/eap/peer.go:97) is a synchronous request-driven transform with no timer -- it emits a Response only when handed a Request and never self-retransmits; lower-layer retransmission is IKEv2's (internal/component/ike/engine/fsm.go:138), so there is no forbidden self-timer to test negatively
`RFC3748-4.1-2`	The peer MUST re-send its last Response when a duplicate Request arrives (S4.1)
	MUST	4.1	positive`no test`no positive test negative`no test`no negative test {not-applicable}: duplicate-Request handling is delegated to the IKEv2 carrier -- on timeout the initiator (EAP peer) re-sends its last IKE_AUTH message, which carries its last EAP Response (sa.LastSentMsg, internal/component/ike/engine/fsm.go:138); the EAP peer state machine holds no per-Request retransmission state
`RFC3748-4.2-1`	Success and Failure packets MUST NOT be retransmitted (S4.2)
	MUST	4.2	positive`unit/verifyTestRFC3748SuccessFailureNotRetransmitted` negative`no test`no negative test {single-polarity}: the authenticator Session emits Success or Failure once and then enters a terminal state where Process returns nil (internal/component/ike/eap/eap.go:186), so the EAP layer never retransmits them; there is no negative case
`RFC3748-4.2-2`	Success and Failure contain only Code, Identifier, and Length (4 octets, no Type field) (S4.2)
	MUST	4.2	positive`unit/verifyTestRFC3748SuccessFailureFormat` negative`unit/verifyTestRFC3748SuccessFailureFormat`
`RFC3748-4.2-4`	The Identifier of a Success or Failure MUST match the Identifier of the Response it answers (S4.2)
	MUST	4.2	positive`unit/verifyTestFailureIdentifierMatchesResponse` positive`unit/verifyTestFailureIdentifierMatchesResponseOnNAK` positive`unit/verifyTestIdentityFailureIdentifierMatchesResponse` positive`unit/verifyTestSuccessIdentifierMatchesResponse` negative`no test`no negative test {single-polarity}: this obligation is on the SENDER. The authenticator's terminal packets are produced by Session.failure and the result.Done arm of Session.handleMethod (internal/component/ike/eap/eap.go), and both now stamp the answered Response's Identifier. A negative case would need a RECEIVER that discards a mismatched Success or Failure, which Section 4.2 does not require of a sender and which ze's PeerSession.Process (internal/component/ike/eap/peer.go) does not do: it switches on request.Code alone
`RFC3748-2.3-1`	A pass-through authenticator MUST forward packets of any Type without interpreting method-specific data (S2.3)
	MUST	2.3	positive`no test`no positive test negative`no test`no negative test {not-applicable}: ze's authenticator always terminates the EAP method locally (eap.Session, internal/component/ike/eap/eap.go:130); there is no AAA/RADIUS back end in the IKE engine, so it never operates as a pass-through
`RFC3748-3.1-1`	Lower layer MUST provide in-order delivery for EAP (S3.1)
	MUST	3.1	positive`no test`no positive test negative`no test`no negative test {not-applicable}: in-order delivery is a lower-layer obligation; ze carries EAP only inside IKEv2, whose message-ID sequencing delivers each IKE_AUTH request/response in order (RFC 7296 Section 2.3; internal/component/ike/engine/msgid.go:76), so the EAP framework code neither provides nor can violate it
`RFC3748-3.1-2`	Lower layer MUST provide error detection (CRC, checksum, or MIC) (S3.1)
	MUST	3.1	positive`no test`no positive test negative`no test`no negative test {not-applicable}: bit-error detection is a lower-layer obligation; ze's EAP packets travel inside the IKEv2 SK payload whose AEAD/ICV check rejects any corrupted frame on decrypt (internal/component/ike/engine/fsm.go:658), so the EAP framework code adds no CRC of its own
`RFC3748-3.1-3`	Lower layer MUST support a minimum MTU of 1020 octets for EAP packets (S3.1)
	MUST	3.1	positive`no test`no positive test negative`no test`no negative test {not-applicable}: the 1020-octet minimum MTU is a lower-layer obligation; ze carries EAP inside IKEv2 SK payloads over UDP, which admit EAP packets far larger than 1020 octets, and EAP-TLS method data is itself fragmented in 1024-octet chunks (internal/component/ike/eap/eap_tls.go:28)
`RFC3748-3.1-4`	Lower layer MUST provide duplicate detection (S3.1)
	MUST	3.1	positive`no test`no positive test negative`no test`no negative test {not-applicable}: duplicate detection is a lower-layer obligation; IKEv2 detects a duplicated message by message ID and replays the cached response (internal/component/ike/engine/msgid.go:79; responder.go:81), so the EAP framework code neither provides nor can violate it
`RFC3748-5.7-1`	When Type = 254 (Expanded Types), Vendor-Id 0 = IETF namespace (S5.7)
	MUST	5.7	positive`no test`no positive test negative`no test`no negative test {not-applicable}: ze offers MD5-Challenge (4), EAP-TLS (13) and EAP-MSCHAPv2 (26); NewSession rejects every other type (NewSession, internal/component/ike/eap/eap.go) and the codec never encodes or parses an Expanded Type (254) packet or its Vendor-Id field, so no Vendor-Id namespace rule can bind. The peer reads TypeExpandedEAP only to route a Type-254 Request to the legacy Nak that Section 5.7 prescribes for a peer not equipped to interpret it (PeerSession.naks, internal/component/ike/eap/peer.go), and that Nak carries no Vendor-Id
`RFC3748-7.10-1`	MSK MUST be at least 64 octets (S7.10)
	MUST	7.10	positive`unit/verifyTestRFC3748MSKSize` negative`no test`no negative test {single-polarity}: the MSK is the compile-time fixed [64]byte returned by DeriveMSK (internal/component/ike/eap/mschapv2.go:206) and by the EAP-TLS ExportKeyingMaterial(...,64) (eap_tls.go:262), so the 64-octet floor cannot be undershot and has no negative case
`RFC3748-7.10-2`	EMSK MUST be at least 64 octets (S7.10)
	MUST	7.10	positive`no test`no positive test negative`no test`no negative test {not-applicable}: ze derives only the MSK (exported for the IKEv2 AUTH payload) and never derives or consumes the EMSK -- no EMSK is produced anywhere in internal/component/ike/eap, so there is no EMSK to size-check
`RFC3748-7.10-3`	An EAP method that establishes no shared key, such as MD5-Challenge, SHOULD NOT be used with IKEv2 (RFC 7296 S2.16 states the rule; S7.10 anchors this id)
	SHOULD NOT	7.10	positive`unit/verifyTestRFC3748IKEv2EAPModesSelectAKeyDerivingMethod` negative`unit/verifyTestRFC3748IKEv2NoAuthModeSelectsAKeylessMethod`
`RFC3748-4-4`	Octets outside the range of the Length field MUST be ignored upon reception (S4, S4.1)
	MUST	4	positive`unit/verifyTestRFC3748LengthBoundsTypeData` negative`unit/verifyTestRFC3748LengthBoundsTypeData`
`RFC3748-4.1-3`	A retransmitted Request MUST carry the same Identifier value, and a new (non-retransmission) Request MUST carry one different from the previous Request (S4.1)
	MUST	4.1	positive`unit/verifyTestRFC3748NewRequestChangesIdentifier` negative`unit/verifyTestRFC3748NewRequestChangesIdentifier`
`RFC3748-4.1-4`	The Identifier field of a Response MUST match that of the currently outstanding Request (S4.1)
	MUST	4.1	positive`unit/verifyTestRFC3748ResponseEchoesRequestIdentifier` negative`unit/verifyTestRFC3748ResponseEchoesRequestIdentifier`
`RFC3748-4.1-5`	The Type field of a Response MUST match that of the Request, or be a legacy or Expanded NAK (S4.1)
	MUST	4.1	positive`unit/verifyTestRFC3748ResponseTypeMatchesRequest` negative`unit/verifyTestRFC3748ResponseTypeMatchesRequest`
`RFC3748-4.2-5`	Once the method completes unsuccessfully, the peer MUST terminate the conversation and indicate failure to the lower layer (S4.2)
	MUST	4.2	positive`unit/verifyTestRFC3748PeerEndsAnUnsuccessfulConversation` negative`unit/verifyTestRFC3748PeerEndsAnUnsuccessfulConversation`
`RFC3748-4.2-6`	Where the authenticator has sent no result indication, the peer MUST NOT silently discard the Success or Failure it waits for (S4.2)
	MUST NOT	4.2	positive`unit/verifyTestRFC3748PeerActsOnTheTerminalPacket` negative`unit/verifyTestRFC3748PeerActsOnTheTerminalPacket`
`RFC3748-4-5`	EAP packets carrying a Code outside 1-4 MUST be silently discarded by both authenticators and peers (S4)
	MUST	4	positive`unit/verifyTestRFC3748UndefinedCodesAreSilentlyDiscarded` negative`unit/verifyTestRFC3748UndefinedCodesAreSilentlyDiscarded`
`RFC3748-4.2-7`	By default, an EAP peer MUST silently discard a "canned" Success packet, one sent immediately upon connection (S4.2)
	MUST	4.2	positive`unit/verifyTestRFC3748PeerDiscardsACannedSuccess` negative`unit/verifyTestRFC3748PeerDiscardsACannedSuccess`
`RFC3748-4.2-8`	A peer receiving a Success or Failure packet where sending one is not explicitly permitted MUST silently discard it (S4.2)
	MUST	4.2	positive`unit/verifyTestRFC3748PeerDiscardsASuccessTheMethodDoesNotPermitYet` negative`unit/verifyTestRFC3748PeerDiscardsASuccessTheMethodDoesNotPermitYet`
`RFC3748-4.2-9`	On the peer, after success result indications have been exchanged by both sides, a Failure packet MUST be silently discarded (S4.2)
	MUST	4.2	positive`unit/verifyTestRFC3748PeerDiscardsAFailureAfterMutualSuccess` negative`unit/verifyTestRFC3748PeerDiscardsAFailureAfterMutualSuccess`
`RFC3748-2-3`	The authenticator MUST NOT send a Success or Failure packet when retransmitting or when it fails to get a response from the peer (S2)
	MUST NOT	2	positive`no test`no positive test negative`no test`no negative test
`RFC3748-2.2-1`	The Success, Failure, Nak Response and Notification Request/Response messages MUST NOT be used to carry data destined for delivery to other EAP methods (S2.2)
	MUST NOT	2.2	positive`no test`no positive test negative`no test`no negative test
`RFC3748-4.1-6`	Additional Request packets MUST be sent until a valid Response packet is received, an optional retry counter expires, or a lower layer failure indication is received (S4.1)
	MUST	4.1	positive`no test`no positive test negative`no test`no negative test
`RFC3748-4.1-7`	The peer MUST send a Response packet in reply to a valid Request packet (S4.1)
	MUST	4.1	positive`no test`no positive test negative`no test`no negative test
`RFC3748-4.1-8`	Requests MUST be processed in the order that they are received, and MUST be processed to their completion before inspecting the next Request (S4.1)
	MUST	4.1	positive`no test`no positive test negative`no test`no negative test
`RFC3748-4.1-9`	A single Type MUST be specified for each EAP Request or Response (S4.1)
	MUST	4.1	positive`no test`no positive test negative`no test`no negative test
`RFC3748-4.1-10`	An authenticator receiving a Response whose Identifier value does not match that of the currently outstanding Request MUST silently discard the Response (S4.1)
	MUST	4.1	positive`unit/verifyTestAuthenticatorDiscardsAResponseAnsweringNoOutstandingRequest` negative`unit/verifyTestAuthenticatorProcessesAResponseAnsweringTheOutstandingRequest`
`RFC3748-4.1-11`	An EAP server receiving a Response whose Type is neither the outstanding Request's nor a legacy Nak MUST silently discard it (S4.1)
	MUST	4.1	positive`unit/verifyTestAuthenticatorDiscardsAResponseOfAnotherType` negative`unit/verifyTestAuthenticatorProcessesAResponseOfTheMethodType`
`RFC3748-2.1-4`	A peer receiving a Request of a Type other than the one under way MUST silently discard it, because an authenticator MUST NOT send a Request of a different Type before the method's final round completes (S2.1)
	MUST	2.1	positive`unit/verifyTestPeerDiscardsARequestOfAnotherType` negative`unit/verifyTestPeerProcessesARequestOfTheMethodType`
`RFC3748-4.2-15`	The peer MUST silently discard a Success packet that arrives after the peer has ended the session (S4.2)
	MUST	4.2	positive`no test`no positive test negative`no test`no negative test
`RFC3748-4.2-10`	Success and Failure packets MUST NOT be sent by an EAP authenticator if the specification of the given method does not explicitly permit the method to finish at that point (S4.2)
	MUST NOT	4.2	positive`no test`no positive test negative`no test`no negative test
`RFC3748-4.2-11`	A peer MUST allow for the circumstance that a Success or Failure packet, being unacknowledged, can be lost (S4.2)
	MUST	4.2	positive`no test`no positive test negative`no test`no negative test
`RFC3748-4.2-12`	After the authenticator sends a failure result indication to the peer, regardless of the response from the peer, it MUST subsequently send a Failure packet (S4.2)
	MUST	4.2	positive`no test`no positive test negative`no test`no negative test
`RFC3748-4.2-13`	After the authenticator sends a success result indication to the peer and receives a success result indication from the peer, it MUST subsequently send a Success packet (S4.2)
	MUST	4.2	positive`no test`no positive test negative`no test`no negative test
`RFC3748-4.2-14`	If the peer attempts to authenticate to the authenticator and fails to do so, the authenticator MUST send a Failure packet and MUST NOT grant access by sending a Success packet (S4.2)
	MUST	4.2	positive`no test`no positive test negative`no test`no negative test
`RFC3748-7.10-5`	The MSK and EMSK MUST NOT be used directly to protect data (S7.10)
	MUST NOT	7.10	positive`no test`no positive test negative`no test`no negative test
`RFC3748-7.10-6`	The EMSK MUST remain on the EAP peer and EAP server where it is derived, and MUST NOT be transported to, shared with, or used to derive keys for additional parties (S7.10)
	MUST	7.10	positive`no test`no positive test negative`no test`no negative test
`RFC3748-7.10-7`	EAP peers, authenticators and authentication servers MUST be prepared for situations in which one of the parties discards the key state, which remains valid on another party (S7.10)
	MUST	7.10	positive`no test`no positive test negative`no test`no negative test
`RFC3748-5-1`	NAK (Type 3) and Expanded NAK (Type 254) MUST NOT be sent in a Request (S5)
	MUST NOT	5	positive`unit/verifyTestRFC3748NoNAKInARequest` negative`unit/verifyTestRFC3748NoNAKInARequest`
`RFC3748-5-2`	All EAP implementations MUST support Types 1-4, which are defined in this document (S5)
	MUST	5	positive`unit/verifyTestRFC3748PeerSupportsTypesOneToFour` negative`unit/verifyTestRFC3748PeerRefusesATypeOutsideOneToFour`
`RFC3748-5.2-1`	The peer MUST respond to a Notification Request with a Notification Response, unless the EAP authentication method specification prohibits the use of Notification messages (S5.2)
	MUST	5.2	positive`unit/verifyTestPeerAnswersANotificationRequest` negative`unit/verifyTestPeerNeverNaksANotificationRequest`
`RFC3748-5.2-2`	A Nak Response MUST NOT be sent in response to a Notification Request (S5.2)
	MUST NOT	5.2	positive`unit/verifyTestPeerNeverNaksANotificationRequest` negative`unit/verifyTestPeerNaksAnAuthenticationTypeButNotANotification`
`RFC3748-5.3.1-1`	Where a peer receives a Request for an unacceptable authentication Type (4-253,255), or a peer lacking support for Expanded Types receives a Request for Type 254, a Nak Response (Type 3) MUST be sent (S5.3.1, S5.7)
	MUST	5.3.1	positive`unit/verifyTestPeerNaksAnExpandedTypeRequestWithALegacyNak` positive`unit/verifyTestPeerNaksAnUnacceptableAuthenticationType` negative`unit/verifyTestPeerDoesNotNakATypeItHandles`
`RFC3748-5.3.1-2`	The Type-Data field of the Nak Response (Type 3) MUST contain one or more octets indicating the desired authentication Type(s), one octet per Type, or the value zero (0) to indicate no proposed alternative (S5.3.1)
	MUST	5.3.1	positive`unit/verifyTestPeerNaksAnUnacceptableAuthenticationType` negative`unit/verifyTestNakNamesTheConfiguredMethod`
`RFC3748-5.3.1-3`	The Identifier field of a legacy Nak Response MUST match the Identifier field of the Request packet that it is sent in response to (S5.3.1)
	MUST	5.3.1	positive`unit/verifyTestNakIdentifierMatchesTheRequest` negative`unit/verifyTestNakIdentifierMatchesTheRequest`
`RFC3748-5.3.1-4`	The legacy Nak MUST NOT be used as a general purpose error indication, such as for communication of error messages or negotiation of method-specific parameters (S5.3.1)
	MUST NOT	5.3.1	positive`unit/verifyTestPeerDoesNotNakAMethodError` negative`unit/verifyTestPeerDoesNotNakAMethodError`
`RFC3748-5.4-1`	A Response MUST be sent in reply to an MD5-Challenge Request (S5.4)
	MUST	5.4	positive`unit/verifyTestRFC3748MD5ChallengeRequestDrawsAResponse` negative`unit/verifyTestRFC3748MD5ChallengeRequeryDrawsNoResponse`
`RFC3748-5.4-2`	EAP peer and EAP server implementations MUST support the MD5-Challenge mechanism (S5.4)
	MUST	5.4	positive`unit/verifyTestRFC3748MD5ChallengeSupportedByBothRoles` negative`unit/verifyTestRFC3748MD5ChallengeIsTheConfiguredMethod`
`RFC3748-5.1-2`	The Identity Response field MUST NOT be null terminated (S5.1)
	MUST NOT	5.1	positive`unit/verifyTestRFC3748IdentityResponseIsNotNullTerminated` negative`unit/verifyTestRFC3748IdentityResponseIsNotNullTerminated`
`RFC3748-7.5-1`	Where an EAP method employs a per-packet MIC, the peer and an authenticator not in pass-through mode MUST validate it (S7.5)
	MUST	7.5	positive`unit/verifyTestRFC3748EAPTLSValidatesItsPerPacketMIC` negative`unit/verifyTestRFC3748EAPTLSValidatesItsPerPacketMIC`
`RFC3748-7.10-4`	EAP methods deriving keys MUST provide for mutual authentication between the EAP peer and the EAP server (S7.10)
	MUST	7.10	positive`unit/verifyTestRFC3748KeyDerivingMethodAuthenticatesBothEnds` negative`unit/verifyTestRFC3748KeyDerivingMethodAuthenticatesBothEnds`
`RFC3748-5.1-1`	Identity (Type 1) SHOULD NOT be relied upon for authentication; it is sent in cleartext (S5.1, S7.1)
	SHOULD	5.1	positive`no test`no positive test negative`no test`no negative test
`RFC3748-7.4-1`	EAP methods used in environments subject to MITM attacks SHOULD provide mutual authentication (S7.4)
	SHOULD	7.4	positive`no test`no positive test negative`no test`no negative test
`RFC3748-4.2-3`	Peer SHOULD treat lower-layer success as implicit EAP Success if EAP Success is lost (S4.2)
	SHOULD	4.2	positive`no test`no positive test negative`no test`no negative test
`RFC3748-2.3-2`	The authenticator MAY act as a pass-through, forwarding EAP to a back-end server via AAA (S2.3)
	MAY	2.3	positive`no test`no positive test negative`no test`no negative test
`RFC3748-4-3`	Octets beyond the Length field MAY be ignored (S4)
	MAY	4	positive`no test`no positive test negative`no test`no negative test

Gaps and untested MUSTs

Requirement	State	Reason
`RFC3748-4.1-2` The peer MUST re-send its last Response when a duplicate Request arrives (S4.1)	no test	no test carries this requirement id; annotated {not-applicable}: duplicate-Request handling is delegated to the IKEv2 carrier -- on timeout the initiator (EAP peer) re-sends its last IKE_AUTH message, which carries its last EAP Response (sa.LastSentMsg, internal/component/ike/engine/fsm.go:138); the EAP peer state machine holds no per-Request retransmission state
`RFC3748-2.3-1` A pass-through authenticator MUST forward packets of any Type without interpreting method-specific data (S2.3)	no test	no test carries this requirement id; annotated {not-applicable}: ze's authenticator always terminates the EAP method locally (eap.Session, internal/component/ike/eap/eap.go:130); there is no AAA/RADIUS back end in the IKE engine, so it never operates as a pass-through
`RFC3748-3.1-1` Lower layer MUST provide in-order delivery for EAP (S3.1)	no test	no test carries this requirement id; annotated {not-applicable}: in-order delivery is a lower-layer obligation; ze carries EAP only inside IKEv2, whose message-ID sequencing delivers each IKE_AUTH request/response in order (RFC 7296 Section 2.3; internal/component/ike/engine/msgid.go:76), so the EAP framework code neither provides nor can violate it
`RFC3748-3.1-2` Lower layer MUST provide error detection (CRC, checksum, or MIC) (S3.1)	no test	no test carries this requirement id; annotated {not-applicable}: bit-error detection is a lower-layer obligation; ze's EAP packets travel inside the IKEv2 SK payload whose AEAD/ICV check rejects any corrupted frame on decrypt (internal/component/ike/engine/fsm.go:658), so the EAP framework code adds no CRC of its own
`RFC3748-3.1-3` Lower layer MUST support a minimum MTU of 1020 octets for EAP packets (S3.1)	no test	no test carries this requirement id; annotated {not-applicable}: the 1020-octet minimum MTU is a lower-layer obligation; ze carries EAP inside IKEv2 SK payloads over UDP, which admit EAP packets far larger than 1020 octets, and EAP-TLS method data is itself fragmented in 1024-octet chunks (internal/component/ike/eap/eap_tls.go:28)
`RFC3748-3.1-4` Lower layer MUST provide duplicate detection (S3.1)	no test	no test carries this requirement id; annotated {not-applicable}: duplicate detection is a lower-layer obligation; IKEv2 detects a duplicated message by message ID and replays the cached response (internal/component/ike/engine/msgid.go:79; responder.go:81), so the EAP framework code neither provides nor can violate it
`RFC3748-5.7-1` When Type = 254 (Expanded Types), Vendor-Id 0 = IETF namespace (S5.7)	no test	no test carries this requirement id; annotated {not-applicable}: ze offers MD5-Challenge (4), EAP-TLS (13) and EAP-MSCHAPv2 (26); NewSession rejects every other type (NewSession, internal/component/ike/eap/eap.go) and the codec never encodes or parses an Expanded Type (254) packet or its Vendor-Id field, so no Vendor-Id namespace rule can bind. The peer reads TypeExpandedEAP only to route a Type-254 Request to the legacy Nak that Section 5.7 prescribes for a peer not equipped to interpret it (PeerSession.naks, internal/component/ike/eap/peer.go), and that Nak carries no Vendor-Id
`RFC3748-7.10-2` EMSK MUST be at least 64 octets (S7.10)	no test	no test carries this requirement id; annotated {not-applicable}: ze derives only the MSK (exported for the IKEv2 AUTH payload) and never derives or consumes the EMSK -- no EMSK is produced anywhere in internal/component/ike/eap, so there is no EMSK to size-check
`RFC3748-2-3` The authenticator MUST NOT send a Success or Failure packet when retransmitting or when it fails to get a response from the peer (S2)	no test	no test carries this requirement id
`RFC3748-2.2-1` The Success, Failure, Nak Response and Notification Request/Response messages MUST NOT be used to carry data destined for delivery to other EAP methods (S2.2)	no test	no test carries this requirement id
`RFC3748-4.1-6` Additional Request packets MUST be sent until a valid Response packet is received, an optional retry counter expires, or a lower layer failure indication is received (S4.1)	no test	no test carries this requirement id
`RFC3748-4.1-7` The peer MUST send a Response packet in reply to a valid Request packet (S4.1)	no test	no test carries this requirement id
`RFC3748-4.1-8` Requests MUST be processed in the order that they are received, and MUST be processed to their completion before inspecting the next Request (S4.1)	no test	no test carries this requirement id
`RFC3748-4.1-9` A single Type MUST be specified for each EAP Request or Response (S4.1)	no test	no test carries this requirement id
`RFC3748-4.2-15` The peer MUST silently discard a Success packet that arrives after the peer has ended the session (S4.2)	no test	no test carries this requirement id
`RFC3748-4.2-10` Success and Failure packets MUST NOT be sent by an EAP authenticator if the specification of the given method does not explicitly permit the method to finish at that point (S4.2)	no test	no test carries this requirement id
`RFC3748-4.2-11` A peer MUST allow for the circumstance that a Success or Failure packet, being unacknowledged, can be lost (S4.2)	no test	no test carries this requirement id
`RFC3748-4.2-12` After the authenticator sends a failure result indication to the peer, regardless of the response from the peer, it MUST subsequently send a Failure packet (S4.2)	no test	no test carries this requirement id
`RFC3748-4.2-13` After the authenticator sends a success result indication to the peer and receives a success result indication from the peer, it MUST subsequently send a Success packet (S4.2)	no test	no test carries this requirement id
`RFC3748-4.2-14` If the peer attempts to authenticate to the authenticator and fails to do so, the authenticator MUST send a Failure packet and MUST NOT grant access by sending a Success packet (S4.2)	no test	no test carries this requirement id
`RFC3748-7.10-5` The MSK and EMSK MUST NOT be used directly to protect data (S7.10)	no test	no test carries this requirement id
`RFC3748-7.10-6` The EMSK MUST remain on the EAP peer and EAP server where it is derived, and MUST NOT be transported to, shared with, or used to derive keys for additional parties (S7.10)	no test	no test carries this requirement id
`RFC3748-7.10-7` EAP peers, authenticators and authentication servers MUST be prepared for situations in which one of the parties discards the key state, which remains valid on another party (S7.10)	no test	no test carries this requirement id

Proof state

A tagged unit reads unproven where no discrimination record exists for it: nothing in this tree has been observed to break it, so the claim its tag makes is unproven.