EAP

1. EAP

2. What is EAP • EAP stands for Extensible Authentication Protocol. • Offers a basic framework for authentication. • Many different authentication protocols can be used over it. • New authentication protocols can be easily added.

3. EAP Background • Originally developed for use with ppp. • Extends the ppp-chap authentication method. • Designed to work as a link layer authentication protocol.

4. PPP Overview • PPP – point to point protocol. • A link layer protocol. • Used for point to point lines, for example: dial-up lines. • Has a built in authentication protocol.

5. PPP Overview (2) • PPP’s data-link configuration is done by LCP (Link Configuration Protocol). • The LCP also configures the optional authentication mechanism. • After the LCP configures the line, authentication takes place, and the network protocols are configured by the NCP (network configuration protocol).

6. PPP Authentication • PPP’s authentication settings are set by the LCP before authentication begins. • All of the authentication protocols used must be determined at this stage. • NAS must know the protocols used for the authentication process.

7. Motivation for EAP • We want to find out more information about the user before choosing the protocol. • We want to use an unlimited number of protocols to authenticate each side. • We want to allow the NAS (Network Access Server) to work with a back-end authentication server.

8. EAP’s basic assumptions • EAP works over a secure line. • A client may not support all authentication methods so EAP must support authentication method negotiation. • To allow expandability, a NAS should be able to function without knowing all of the EAP authentication methods. • The physical layer under the link layer may not be reliable.

9. What is a “Secure Line” • In this case, “secure line” is not a strictly technical term. • A “secure line” is a line where the probability of a third party listening to the line, injecting or modifying existing traffic is ‘low enough’. • What exactly is low enough is dependant on the link’s use.

10. The EAP Protocol • The EAP protocol is a one sided authentication protocol - the PEER must identify himself to the AUTHENTICATOR. • EAP allows for mutual authentication by running the protocol in both directions.

11. The EAP Protocol (2) • A request-response protocol. • Uses 4 different kinds of messages: 1. EAP request 2. EAP response 3. EAP success 4. EAP failure

12. Code: 1 byte, representing the type of EAP message Length: 2 byte, The total message length ID: 1 byte, Used for matching requests and responses Data: any size, The message’s data 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 Code Identifier Length Data ... EAP messages • All EAP messages have a common format:

13. Type: 1 byte, The type of authentication protocol used Data: any size, Data used for the authentication process 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 Code Identifier Length Type TypeData . EAP messages 2 • EAP request and response messages have the same format , with code=1 for requests and code=2 for responses

14. EAP messages 3 • EAP Success messages are EAP messages with code 3 and no data. • A success message means that the authentication concluded successfully. • EAP failure messages are EAP messages with code 4 and no data. • A Failure message means that the authentication has failed.

15. The authentication sequence • The Authenticator sends the peer an Identity request (optional). • The Peer sends a response to the identity request identifying himself (optional). • The Authenticator sends a request with a type according to which authentication method he wants to use and the data needed for the authentication. • The Peer sends back a response of the same type or of type Nak signifying he refuses to use the requested authentication method.

16. The authentication sequence • The Authenticator may at this point send another request (to repeat the process) or a success/failure message. • If the authentication was successful and mutual authentication is required ,the sides change roles and the authentication is repeated in the other direction.

17. Notes • All the messages pass on the communication line in plain-text (unless there is a protection mechanism in the link layer below) • The messages are not signed/authenticated at the EAP level although individual EAP methods may MAC/sign/encrypt their data.

18. Identity Request Identity Request EAP Request Repeated as many times as needed Identity Response Identity Response EAP Response with the same type or a Nak EAP Success or EAP Failure message EAP Request EAP Response with the same type or a Nak Repeated as needed If mutual Auth Is required EAP Success or failure message Generic EAP Example Authenticator Peer

19. Error/duplicate handling • To overcome a possibly unreliable link-layer below, EAP has built in duplicate handling and retransmission facilities. • The authenticator is responsible for all retransmissions , if a response is lost the request will time-out and be resent. • Duplicate handling is done by discarding any unexpected messages.

20. Using a Back-End Server • The NAS forwards all the EAP messages it gets to the Back-End server. • The Back-End Server sends all outgoing EAP messages to the peer through the NAS. • If the Back-End server sends a failure message the NAS Sees it and closes the connection, if a success message is sent the NAS knows that the peer passed the authentication.

21. Basic EAP Methods • In the initial definition of EAP included several built in authentication methods: • Identity - request the other side to identify itself. • Notification - to send notifications to the other side. • Nak - peer refuses to use the authentication method. • MD5-Challenge - an implementation of chap over EAP. • One Time Password - used for one time passwords. • Generic Token Card - used for generic token cards. • Vendor Specific - *

22. Identity Request Identity Response EAP – MD5 Response EAP Success or EAP Failure message EAP-MD5 Request Code=1 Code=2 Code=1 Identifier=I Identifier=I Identifier=I Length=the total length Length=the total length Length=the total length Type=1 Type=1 Type=4 Type Data= the md5 challenge string. Type Data= peer identity Type Data= … Code=2 Identifier=I Length=the total length Type=4 Type Data=hash(I&Secret&md5-challange) Code=3 Identifier=I Length=the total length Authentication exampleusing MD5 Authenticator Peer

23. MD5 Security properties • Normal user-names and passwords may be used. • Password is not transmitted exposed, it is protected by the md5 hashing function. • Replay attack protection is done using the challenge field.

24. Security weaknesses • The MD5 challenge has serious security problems. • An offline dictionary attack on the user’s password is possible, because the challenge is known. • The protocol is completely exposed to man in the middle and session hijacking attacks. • Mounting a DOS attack is also very simple.

25. Are these attacks really a problem? • Not really, because we are supposed to be working on a SECURE line. • A man in the middle, session hijacking and DOS attacks need access to the physical communication line. • The offline dictionary attack may still be a problem. However, this can be solved.

26. Conclusion • It is reasonable to use the MD5-challenge authentication method over a secure line for non-critical data. • It is however completely irresponsible to use EAP for authentication over insecure lines. • We will see how this limitation was overcome in the next lecture.