Does EAP exist as an authentication protocol itself, or will it only be found implemented as one of its methods (EAP-TLS, EAP-TTLS, etc)?

If EAP is only a framework, what additional detail do its methods provide that allows them to be utilised? Said differently, what stops EAP from being used as an authentication protocol rather than just a framework?


RFC 3748, the EAP specification, does two things: it specifies the EAP messaging protocol, and it provides threat modeling and security guidelines for authentication methods that run on top of it. So in a sense, EAP is both a protocol and a standard. EAP methods could be viewed as part of the EAP standard, but as merely running on top of the EAP protocol.

(RFC 3748 also defines three EAP methods -- MD5, OTP, and GTC -- by specifying how the pre-existing non-EAP versions of these authentication protocols are conducted over EAP.)

The EAP protocol is a transport protocol. It provides a set of common features useful for authentication on top of an unspecified communications layer. It could be viewed as the same sort of protocol as TCP, but designed specifically for authentication instead of bulk data transport.

What the EAP protocol provides:

  • A packet format for requests and responses.
  • Rules for transmitting requests and responses, and for matching responses to requests, with an eye towards eliminating meaningful opportunities for spoofing.
  • Rules for retransmitting dropped messages and for handling duplicate messages.
  • Rules for selecting an authentication method.
  • A facility for the authenticator to allow a back-end server to perform the actual authentication.

What the EAP protocol leaves up to the communications layer to provide:

  • Discovery and transport. EAP assumes the supplicant and authenticator already know how to deliver messages to each other.
  • In-order message delivery. The lower layer can drop or duplicate messages, but EAP assumes the messages will be delivered in order.

What the EAP protocol leaves up to the method to provide:

  • All of the details of how the supplicant and authenticator each decide that the other is trustworthy; including authentication, authorization, encryption, etc., subject to the security requirements in the standard.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.