EAP
Proven, extensible authentication is provided in the Moonshot architecture by the Extensible Authentication Protocol (EAP). This page gives an overview of EAP, and where it fits within Moonshot.
Contents
1. What is EAP?
The Extensible Authentication Protocol (EAP) is an IETF standard for an authentication framework. It provides a great deal of flexibility; EAP is not itself a specific authentication mechanism. It is an extensible framework that allows for specific authentication mechanisms to be implemented and negotiated. This means that when a new authentication mechanism is defined, all of the parties do not need to be modified to support it; they are just "plugged in" to the framework. EAP also permits the use of a back-end authentication server, which may implement some or all authentication methods with the authenticator acting as a pass-through for some or all methods and peers.
EAP is commonly used as the underpinning for enterprise authentication in wireless networks.
2. Key Concepts and Terminology
EAP provides some common functions and negotiation of authentication mechanisms called 'EAP methods'.
2.1. Terminology
- Authenticator - the entity that initiates the authentication process. In the wireless network world, this is often the Access Point or controller. In Moonshot, it is the Service.
- Channel bindings - EAP channel bindings (not to be confused with GSS channel bindings) are a method to solve some issues within standard EAP whereby malicious or compromised authenticators could present false information to peers (see RFC 6677).
- Method - an implementation of EAP that provides a specific type of authentication.
- Peer - the entity that responds to the authenticator. In the Moonshot world, this is the Cient.
- Server - the EAP server authenticates the user. In the Moonshot world, this is the Identity Provider.
- Tunnel - some EAP methods are tunnel-based; that is, they have two phases: in the first phase, a tunnel protocol (e.g., TLS) establishes a secure tunnel between the EAP peer and the EAP server, and in the second phase, EAP is run again inside the protected tunnel. This allows for mutual authentication and for EAP methods that exchange information such as passwords to be able to do so without being eavesdropped upon.
2.2. EAP Methods
EAP methods defined by the IETF include EAP-MD5, EAP-OTP, EAP-GTC, EAP-TLS, EAP-IKEv2, EAP-SIM, and EAP-AKA, PEAP, LEAP and EAP-TTLS.
3. Moonshot and EAP
When designing the ABFAB technologies, EAP was chosen as a way of providing extensibility of authentication methods rather than choosing one or more particular authentication mechanisms. This allows for new authentication mechanisms to be deployed without having to update the core specifications and code to support new methods in the future.
3.1. How Moonshot uses EAP
GSS-EAP standardises how EAP messages should be carried over the GSS-API channel.
Moonshot requires the use of EAP methods that implement channel bindings due to the security guarantees these provide. This currently is only EAP-TTLS - although this is a tunnelled method that allows the use of any other EAP method inside the tunnel.
3.2. Where Moonshot uses EAP
GSS-EAP defines how EAP traffic is carried over the GSS-API. So, when an application client and server have chosen to use GSS-EAP, an EAP transaction is started.
EAP is used to allow the Moonshot client to authenticate to an Identity Provider via a Relying Party in such a way that the authentication is secure and extensible.