Extensible Authentication Protocol (EAP) Mutual Cryptographic Binding

Abstract

As the Extensible Authentication Protocol (EAP) evolves, EAP peers rely increasingly on information received from the EAP server. EAP extensions such as channel binding or network posture information are often carried in tunnel methods; peers are likely to rely on this information. Cryptographic binding is a facility described in RFC 3748 that protects tunnel methods against man-in-the-middle attacks. However, cryptographic binding focuses on protecting the server rather than the peer. This memo explores attacks possible when the peer is not protected from man-in-the-middle attacks and recommends cryptographic binding based on an Extended Master Session Key, a new form of cryptographic binding that protects both peer and server along with other mitigations.

Tunnel Extensible Authentication Protocol (TEAP) Version 1

“…The TEAP encrypting/decrypting gateway MUST, at a minimum, provide support for IPsec, TLS, or similar protection in order to provide confidentiality for the portion of the conversation between the gateway and the EAP server. In addition, separation of the inner and outer method servers allows for crypto-binding based on the inner method MSK to be thwarted as described in [RFC7029]. Implementation and deployment SHOULD adopt various mitigation strategies described in [RFC7029].…”

“…In addition, separation of the inner and outer method servers allows for crypto-binding based on the inner method MSK to be thwarted as described in [RFC7029]. Implementation and deployment SHOULD adopt various mitigation strategies described in [RFC7029].…”

“…If the inner method is deriving EMSK, then this threat is mitigated as TEAP utilizes the mutual crypto-binding based on EMSK as described in [RFC7029]. It should be noted that in TEAP, as in many other authentication protocols, a denial-of-service attack can be mounted by adversaries sending erroneous traffic to disrupt the protocol.…”

Short paper

“…From our experiments we determined that other devices, for example Android devices, do not employ certificate pinning by default. If the victim user did not configure a server certificate, we believe a more generic MITM attack may be executed as described in RFC 7029 [10]. Note that in this case, the preconditions are stricter: it is required that server certificates are not used by the Android device, which was not the case for Apple devices.…”

Update to the Extensible Authentication Protocol (EAP) Applicability Statement for Application Bridging for Federated Access Beyond Web (ABFAB)

“…Some deployments may allow for weak server authentication that is then validated with an additional existing exchange that provides mutual authentication. In order to fully mitigate the risk of NAS impersonation when these mechanisms are used, it is RECOMMENDED that mutual channel bindings be used to bind the authentications together as described in [RFC7029]. When doing channel binding it is REQUIRED that the authenticator is not able to modify the channel binding data passed between the peer to the authenticator as part of the authentication process.…”