- [Instructor] Extensible Authentication Protocol
is an authentication framework that we use
for lots of different authentication methods.
You'll often hear this referred to as EAP or EAP for short.
Now this is a way that we can encapsulate
usernames, passwords, certificates,
and all kinds of other sensitive data
used for purposes of authentication on a network.
The most common form of this is 802.1x,
which is the IEEE standard defining
port-based network control using EAP over LAN
to control access to the local area network.
Within 802.1x, we have three main components.
We have the supplicant,
which is the endpoint requesting access,
we have the authenticator,
which is the network device
that controls physical access to the network
based on the authentication status of the client,
and we have the authentication server,
which is the server that is performing
the actual authentication of the client.
It does that by validating the identity of the supplicant.
In this simplified topology,
we have a laptop acting as our supplicant,
which is requesting network access.
We have a wireless LAN controller
acting as the authenticator middleman.
In a wireless environment, this will be very commonly seen
or you might even see LAN switches used
as the authenticator as well.
And we have the Cisco ISE,
the identity services engine acting as
our authentication server.
The authentication server could be any radius-based server
that is able to validate the identity of the endpoint.
So let's take a look at the steps
for authentication with 802.1x.
We start with our supplicant,
which is a wireless laptop in our case.
This laptop is going to have special software installed
that will allow the client to communicate
with EAP at layer two.
The supplicant is going to initiate authentication
by sending an EAPoL Start frame
that stands for EAP over LAN.
Now know that the authentication can be initiated
by either the authenticator or the supplicant.
The authenticator could initiate authentication
when a port link state changes from down to up
or it's possible that the authenticator is configured
to periodically send out requests,
maybe every five seconds,
and say, "Hey, are there any new clients out there?"
We call this an EAP request identity frame.
So the EAPoL Start frame may or may not
initiate the process,
but regardless the authenticator will send out
an EAP request identity frame to the supplicant.
The supplicant will now send an EAP response identity frame
to the authenticator.
This is going to contain maybe a username and a password,
maybe some sort of certificate,
it could even use
multifactor authentication methods as well.
But the supplicant is going to send
this identity authentication information
back to the authenticator.
It's also important to keep in mind
that with the authenticator,
in this case a wireless LAN controller,
this is simply acting as a proxy.
The authenticator has absolutely no idea
if the credentials are valid or not.
It simply takes the EAP frames arriving from the supplicant
and re-encapsulates those for the authentication server,
so it's going to re-encapsulate the EAP frame
within a radius frame and then send that packet
to the authentication server.
This message is known as radius access request message.
The authentication server is going to respond
with a radius access challenge message,
which is another authentication challenge
for the supplicant.
This challenge is going to use one of several EAP types
to define the authentication mechanism,
and we'll look at those EAP types more in just a bit.
This request passes through the authenticator
which re-encapsulates the radius message as an EAP message
and that will continue to translate these messages
as they're passed back and forth.
The number of messages exchanged at this point is going
to depend on how complicated the authentication method is.
For example, is it just asking for a username and password
or is it asking for multifactor authentication?
So that's going to determine how many messages
are passed back and forth during this challenge phase.
So the client is going to send back an EAP response message
which goes to the authenticator and is re-encapsulated
into a radius access request message,
which then reaches the authentication server.
The authentication server is going to verify
the client credentials and it's going to respond
with a final message.
That message will be either a radius accept
or radius reject packet.
In the case of a radius access accept message,
the authenticator will authorize the port for use
by the supplicant with permission
from the authentication server
and that will complete a successful authentication process.
Again, notice that the EAP authentication process itself
is completely transparent to the authenticator.
It simply re-encapsulates and forwards frames back and forth
waiting for the authentication server
to validate the access.
Now, when we looked at that radius access challenge method
passed from the authentication server,
we noted that there are several different types of EAP
that might be used,
and depending on the type we'll determine
the access challenge method that's used
by the authentication server.
Currently there are about 40 different methods defined,
but most of those aren't very common.
So we're going to take a look at a few
of the most commonly EAP types.
We can divide those into two main categories,
which are native EAP types and tunneled EAP types.
So first let's take a look at native EAP types
starting with EAP-TLS.
EAP-TLS is considered one of the most secure EAP types
and it's one of the original authentication methods
defined by the IEEE 802.1x standard.
EAP-TLS uses X.509 certificates for authentication where
the client must trust the server certificate and vice versa.
This means that it does require a certificate authority
to use EAP-TLS.
With the rise of a BYOD, Bring Your Own Device policies
in our enterprise networks,
this is highly regarded as one of
the most desirable EAP types these days.
EAP-MD5 uses a message digest algorithm
to hide the credentials in a hash.
The hash is sent to the server where it's compared
to a local hash to see whether the credentials were correct.
EAP-MD5 does not have a mechanism for mutual authentication
as was described with EAP-TLS.
So that means that the server is validating the client,
but the client does not check to see whether
it should trust the server or not.
We most commonly see MD5 on IP phones.
And then there's EAP-MSCHAPv2.
This is an EIP type in which the client's credentials
are sent to the server encrypted within an MSCHAPv2 session.
This allows for the simple transmission of usernames
and passwords to the radius server,
which in turn authenticates them to active directory.
This is also a fairly popular type due to the prevalence
of Windows directory servers in our enterprise networks.
And we have EAP-GTC.
This method was created by Cisco
as an alternative to MSCHAPv2.
This enables generic authentications to identity stores
such as token servers, LDAP servers, and several more.
In addition to native EAP types, we have tunneled EAP types.
A tunneled EAP type simply uses a native EAP type
inside of an encrypted tunnel.
The two types of those we want to look at first are PEAP
or Protected EAP.
PEAP was originally proposed by Microsoft
and is an EAP tunnel type that has quickly become
one of the most popular and one of the most
widely deployed methods in the world.
PEAP can form an encrypted TLS tunnel
between the client and server using X.509 certificates
on the server, much in the same way that the SSL tunnel
is established between a web browser and a secure website.
So for example, when you go to your personal banking site,
first an encrypted tunnel is established and then
your sensitive credentials are passed over that tunnel.
PEAP will use another EAP type as its inner method
authenticating the client using EAP within the outer tunnel.
So these tunnel types have an outer method
and an inner method.
The outer method being the encryption,
the inner method being
the actual authentication type being used.
And then there's EAP-FAST,
Flexible Authentication via Secure Tunnel.
EAP-FAST was also created by Cisco
and it was made as an alternative to PEAP
that enables faster re-authentications
and faster wireless roaming.
And just as PEAP does, EAP-FAST forms a TLS outer tunnel
and then transmits the client credentials
within that TLS tunnel.
Where EAP-FAST differs from PEAP,
is the ability to use protected access credentials or packs.
Pack can be thought of as a secure cookie,
which will be stored locally on a host
as proof of a successful authentication.
Both of these tunnel types use a TLS tunnel
as the outer method and the inner method
would be the actual EAP authentication method,
and it will be one of those previously mentioned
native EAP types.
So for example, a common configuration would be
an EAP-FAST tunneled method,
which would use a TLS outer tunnel
with an EAP-MSCHAPv2 inner authentication method.
So that's an overview
of the Extensible Authentication Protocol, or EAP.
We looked at the most common form of EAP, which is 802.1x,
we also looked at the three components of 802.1x,
the supplicant, the authenticator,
and the authentication server.
We looked at the message exchange that happens
during a typical 802.1x authentication requests,
and we looked at the most popular types of EAP in use today.