Update to the Extensible Authentication Protocol (EAP) Applicability Statement for Application Bridging for Federated Access Beyond Web (ABFAB)
updates
- rfc-3748 — Extensible Authentication Protocol (EAP)
Extracted elements (20)
Channel bindings are required for application-layer EAP because, without them, a peer cannot verify if an authenticator is authorized to provide an advertised service. As more services adopt EAP, distinguishing which service is being contacted becomes critical, especially across organizational boundaries in federated environments.
Re-authentication value depends on session characteristics: short-lived sessions or easily replaced sessions likely do not benefit (e.g., HTTP, SMTP where a new connection suffices), while long-lived or costly-to-disrupt connections, or protocols where only one party can initiate reconnection, are prime candidates for re-authentication support.
The original EAP applicability statement limited EAP to 'network access authentication where IP layer connectivity may not be available' and stated that use for bulk data transport is NOT RECOMMENDED. The bulk data prohibition remains valid, but the scope restriction proved too narrow given ABFAB application-layer authentication use cases.
Applications using EAP may need to perform conversion of identities from an application-specific character set to UTF-8 or another character set required by a particular EAP method. See also RADEXT-NAI Section 2.6 for normalization of identifiers.
All EAP servers and all application access EAP peers MUST support channel bindings. All network access EAP peers SHOULD support channel bindings.
Any new usage of EAP MUST use channel bindings including the EAP lower-layer attribute to prevent confusion with network access usage.
Applications MUST handle discarded EAP messages. Options include failing the authentication at the application level, requesting an EAP retransmit, or waiting for additional EAP input.
Channel binding MUST be used for all application authentication. The EAP server MUST require that either the correct EAP lower-layer attribute or another attribute indicating the purpose of the authentication be present in the channel binding data.
Channel binding SHOULD be used for all network access authentication, and when channel binding data is present, the EAP server MUST require that it contain the correct EAP lower-layer attribute to explicitly identify the reason for authentication.
EAP lower layers MAY provide a mechanism for re-authentication to happen within an existing session, permitting security associations to be updated without establishing a new session.
In cases where EAP is used for application authentication, support for EAP channel bindings is REQUIRED on the EAP peer and EAP server to validate that the host is authorized to provide the services requested. The application MUST define channel binding attributes sufficient to validate that the service is correctly represented to the peer.
It is REQUIRED for the application layer to prove that both the EAP peer and EAP authenticator possess the EAP Master Session Key (MSK). Failing to validate MSK possession can allow an attacker to insert himself into the conversation and impersonate the peer or authenticator.
The protocol carrying EAP MUST prove possession of the EAP MSK between the EAP peer and EAP authenticator when EAP is used for application access.
To fully mitigate NAS impersonation risk when weak server authentication is used, it is RECOMMENDED that mutual channel bindings be used to bind the authentications together as described in RFC 7029.
When doing channel binding, it is REQUIRED that the authenticator is not able to modify the channel binding data passed between the peer and the authenticator as part of the authentication process.
EAP re-authentication within an existing session allows security associations to be updated without session teardown. Application designers must determine whether re-authentication is needed and which parties can initiate it.
In the ABFAB application-layer EAP context, the authenticator is responsible for retransmission. The lower layer can either use a default unreliable mode (retransmission timer-driven) or set the retransmission timer to infinite, making the lower layer responsible for reliable delivery.
In federated environments, authenticating the EAP server is insufficient: the peer must also validate that the contacted host is authorized to provide the requested service. A low-value compromised service could impersonate a high-value service, limiting overall system security to the weaker service.
Some deployments may allow for weak server authentication later validated with an existing exchange providing mutual authentication. Mutual channel bindings (RFC 7029) are RECOMMENDED in such cases, and the authenticator MUST NOT be able to modify channel binding data in transit.
When channel binding is not required and EAP authentication is introduced into an existing non-network-access service, a device can be created that impersonates a NAS to peers while proxying authentication to the new application service. This may decrease security even for users who previously used non-EAP authentication.