EAP-TLS

An important element of authentication is ensuring only the authentication server can read the credentials that the
client sends and that the credentials are sent to the correct authentication server.

Certificates and Digital Signatures

The credentials can be encrypted before they are sent. Two types of encryptions exist: symmetric and asymmetric.
Symmetric encryption is also referred to as encryption using symmetric keys, which means that the same algorithm
and key that are used to encrypt the message are used, in reverse, to decrypt the message. The key can be
generated on one side and transmitted to the other side over a secured transmission, or it can be a common
password that is configured the same way on both sides.

A typical example of this system is letter shifting. In this encryption technique, if letters in a word are
shifted forward using an index of two, "a" becomes "c," "b" becomes "d," and so on. To decrypt the
message, the letters are shifted in the opposite direction (toward "a" rather than toward "z"), using the
same algorithm (index of two).
Symmetric key encoding is good for encryption because it is usually simple and fast.
Asymmetric keys are more robust. With asymmetric keys, a user generates two keys (in the example that is shown
in the figure, public [Key 1] and private [Key 2]). These keys are built on a mathematical algorithm so that they work
in pairs. Only Key 2 can decrypt what is encrypted by Key 1 and vice versa. Using one key to guess the second
key is not easy to do.

To understand how asymmetric keys can be used to encrypt, suppose that users Pat and Bob (for A and B) want to
exchange a secret message. Pat wants to make sure that Bob will be the only person who can read what he
sends.

Pat generates a pair of keys (1 and 2), and Bob generates another pair of keys (3 and 4). Data that is encrypted
using Key 1 can be decrypted only using Key 2. Data that is encrypted using Key 2 can be decrypted only using
Key 1. Data that is encrypted using Key 3 can be decrypted only using Key 4, and data that is encrypted using Key
4 can be decrypted only using Key 3.

To exchange the secret message, Bob sends one of his keys to Pat (for example, Key 3). This key is the public key
of Bob because it is given away. Pat uses Key 3 to encrypt the message, because he knows that Bob, who has
Key 4, will be the only person who can decrypt what he encrypts with Key 3. Bob does not give away Key 4, which
is the private key.

When Bob wants to answer Pat, he asks Pat to send him his public key (for example, Key 1). He encrypts his
message with Key 1, knowing that only Key 2 (Pat) can decrypt it.

Digital Signatures
This level of secrecy is sufficient for message exchange. Bob can freely give his public key to anyone who wants to
send a message to him, knowing that he will be the only one who can read what is encrypted with this public key.
He can even post his public key on the Internet in a public key repository. So, as long as Bob keeps his private key
secret, he is protected.
Public keys that are made widely available and private keys that are kept secret are used for secure exchanges in
networks. A server sends its public key to a client, who uses this key to encrypt a password, knowing that only the
server can decrypt the password.

In this system, the identity of the sender is not protected. If Pat wants to send a message to Bob, and if Bob
receives the message, decrypts it, and reads Pat as the sender name, Bob assumes that Pat wrote and sent the
message. However, this fact cannot be guaranteed because the public key that belongs to Bob can be given to
another person. Another person can pretend to be Pat, write a message, encrypt it with the public key that belongs
to Bob, and post it. Bob has no way of knowing if Pat was truly the original sender.

At this point, the system must become a little more complex to become far more effective. Pat has two keys. Only
Key 2 (his private key) can decrypt what is encrypted with Key 1 (his public key). The opposite is also true: only
Key 1 (his public key) can decrypt what is encrypted with Key 2 (his private key). To enhance security, when Pat
wants to send a message to Bob, he starts by encrypting it with Key 2 (his private key). Only Key 1 (his public key)
can decrypt the result. Next, Pat uses Key 3, the public key that belongs to Bob, to re-encrypt the result a second
time. Only Bob can decrypt this encryption using Key 4 (his private key). When Bob receives the message, he tries
to use Key 4 to decrypt it and obtains an unreadable result. He understands that there is a second level of
encryption. Because he knows that the message supposedly comes from Pat, he tries to use Key 1 (Pat’s public
key) and gets a readable message. He can thus be certain that Pat sent the message, because he could decrypt it
with the public key that belongs to Pat.

Applying the public key that belongs to Bob allows Pat to encrypt the message so that only Bob can decrypt it;
applying his own private key is proof of his identity. This process guarantees that Bob can identify Pat as the
sender. The keys cannot be duplicated or forged, and because they are unique pairs, only Key 2 can decrypt what
is encrypted by Key 1, which also means that if Key 2 can decrypt the message, the only possibility is that Key 1
encrypted it. No other key can produce an identical result.

Pat does not need to encrypt the entire message that he sends to Bob. Pat could choose instead to use a hashing
algorithm and encrypt the output. This approach has the same effect and is much less compute-intensive. This
process is known as digitally signing his message with an electronic signature.

One of the downsides of using asymmetric encryption is that the keys need to be much larger than symmetric keys
(8 to 10 times larger), and asymmetric encryption and decryption requires considerable compute power.
Trusted Third Party
Pat applies his private key for encryption before encrypting the data a second time, using the public key that
belongs to Bob, to prove his identity. This approach provides a higher level of security, but the level needs to be
higher still. Therefore, a last step must be added to the process.

What proves to Bob that the public key that he has for Pat is truly Pat’s public key? Someone else could have
created a pair of keys, labeled one as the public key that belongs to Pat, sent it to Bob, and used the other key to
sign the message. If Bob answers this type of message, the attacker could read this answer.

Bob needs a guarantee that the public key genuinely belongs to Pat. The best way to achieve this guarantee is to
physically exchange the keys. Bob and Pat meet and exchange a medium with a key on it. If Pat and Bob know
each other and live in the same neighborhood, such an exchange is possible; otherwise, it is not.

Another possibility is to use a third person. Pat can give his public key to someone he trusts to give it to Bob. But
how can Bob be sure that the person he meets is the one that Pat sent? Bob would need another person to testify
to the identity of this person.

Simply put, the problem lies in finding a third person who Bob and Pat trust to confirm their identities. For a
nontechnical comparison, consider the use of a driving license. A local agent (for example, the Department of
Motor Vehicles in California) issues a license, which serves as proof of identity. The rest of the state and the rest of
the entire United States trusts this local agent. If you want to open a bank account, the bank will trust your driving
license as proof of identity.

In computer terms, the same logic applies. A few hundred trusted authorities act as the third party that can testify
that a particular public key genuinely belongs to Pat. To accomplish this task, these authorities use the key that
belongs to Pat and add to the end of it some data that contains his name, the validity duration, and a hash that
contains a signed message that is encrypted with a private key that belongs to the authority.

Because the authority is well known, its public key is implemented in the operating system of most computers.
When receiving the public key that belongs to Pat, the computer that belongs to Bob tries to read the authority
hash using the public key of that authority, which is installed on the computer. If the process is successful, the
public key truly belongs to Pat. If the process fails, a pop-up window appears that warns Bob that the key is not
correctly signed and asks if he wants to trust it.

To have a public key that a trusted third-party signs, Pat must prove his identity and usually pay a fee for this level
of security.
Certificate Function
The process of the authority adding some data to the end of Pat’s public key creates a certificate. This authority is
more commonly referred to as a CA. A certificate is therefore a document that transports a public key to which a
trusted third-party CA has added a message, such as the one that is described in the previous example, and
signed using its private key. Certificates are used for transporting public keys.

If device A receives a certificate that device B sends to it, device A can use the certificate signature to verify that the
certificate is genuine and the certificate truly holds the public key of device B. Device A can use the key from the
certificate to encrypt the messages that it sends to device B, knowing that device B, using its private key, will be the
only one that can decrypt these messages.

There are cases in which the third-party signature is unnecessary. When a wireless LAN controller reboots after its
initial configuration, a certificate is generated. This certificate is called self-signed because no external authority
confirms it. When the administrator connects to the web interface of this controller, a warning appears, signaling
that the CA for this certificate is not known. Because the administrator trusts the physical cable that links to the
controller, the certificate can be accepted as valid, although it is self-signed. CAs are usually required in public
networks, in which the level of trust is low.

PKI Terminology and Components

A Public Key Infrastructure (PKI) provides a framework on which you can base security services, such as
encryption, authentication, and nonrepudiation. A PKI allows for very scalable solutions, and it is becoming an
extremely important authentication solution for VPNs. A PKI uses certain terminology to name its components.
Terminology Components and Definitions

PKI A service framework that is needed to support large-scale, public key-based technologies.

CA The trusted third party that signs public keys in a network.

Certificates Documents that bind names to public keys that the CA signs.
PKI Terminology
When you apply these concepts in practice, it is important to understand the supporting framework. A PKI is the
service framework that is needed to support large-scale, public key-based technologies. It is a set of technical,
organizational, and legal components that are needed to establish a system. The public key infrastructure enables
large-scale use of public key cryptography to provide authenticity, confidentiality, integrity, and nonrepudiation
services.

Two very important terms must be defined when talking about a PKI:
• CA: This component is the trusted third party that signs the public keys of entities in a PKI-based system.
• Certificate: This component is a document that binds the name of the entity and its public key, which the CA
signed.

PKI Components

PKI is more than just a CA and its users. Along with implementing the enabling technology, building a large PKI
involves a significant amount of organizational and legal work. There are five main areas of a PKI:
• CAs for key management
• PKI users, such as people, devices, and servers
• Storage and protocols
• Supporting organizational framework, which is known as practices and user authentication using LRAs
• Supporting legal framework

Retrieval of CA Certificates
Retrieval of CA certificates is a process that is used for proper authentication in the wireless network.

• In-band retrieval of a CA certificate

• Out-of-band authentication of a CA certificate

In the figure, the following steps occur:

1. Pat and Bob request the CA certificate that contains the CA public key.
2. On receipt of the CA certificate, their systems verify the validity of the certificate, using public key cryptography.
 3. Pat and Bob follow up the technical verification that their system does by contacting the CA administrator and
verifying the public key and serial number of the certificate.

Certificate Enrollment
Certificate enrollment is another procedure that you would use in a wireless network to obtain proper
authentication.

• In-band request for a certificate

• Verification of user credentials and privileges
• Out-of-band authentication of a user public key

After retrieving the CA certificate, Pat and Bob perform the following steps to submit certificate requests to the CA:
1. Each of their two systems forwards a certificate request that includes their public key with some identifying
information. All this information is encrypted using the public key of the CA.
2. On receipt of the certificate requests, the CA administrator contacts Pat and Bob to confirm their submittal and
the public key.
3. The CA administrator issues the certificate by adding more data to the certificate request and digitally signing all
of it.
4. The end user manually retrieves the certificate or the SCEP automatically retrieves the certificate, and the
certificate is installed on the system.

Certificates That Use Authentication

These certificates have the following attributes:

• Authentication no longer requires the presence of the CA server.
• Users exchange their certificates that contain public keys.
When the certificates that the same CA signed are installed, Bob and Pat are ready to authenticate each other, as
follows:
• Bob and Pat exchange certificates. The CA is no longer involved.
• Each party verifies the digital signature on the certificate by hashing the plaintext portion of the certificate,
decrypting the digital signature using the CA public key, and comparing the results. If the results match, the
certificate is verified as being signed by a trusted third party. The verification by the CA that Bob is Bob and Pat
is Pat will be accepted.

PKI in the WLAN

The PKI provides you with a scalable and manageable way to implement strong encryption using digital
certificates. The PKI manages encryption keys and identity information for the human and mechanical components
of a network that participates in secured communications.

In the enterprise WLAN, PKI is used as follows:

 • CAs generate digital certificates for users (clients) and servers. CAs have CA certificates that validate the user
and server certificates.
• Clients request a user certificate from a CA and use the certificate to authenticate to the server using the EAP
process. Not all EAP variants use client certificates (EAP-TLS does).
• Servers request a server certificate from the CA, which the client uses to validate the authenticity of the server.
A server can also use a self-signed certificate in which it acts as its own CA.
• Cisco WLCs use preinstalled server certificates or can request a server certificate from a CA.

EAP Types ( the EXAM covers EAP-TLS only )

There are several EAP types, which are variations of the protocol to facilitate differentiations in usage.

Extensible Authentication Protocol-Transport Layer Security

EAP-TLS is used extensively in wireless authentication with 802.1X and EAP.

Certificates are used extensively in wireless authentication with 802.1X and EAP, because they are a way to
authenticate and generate encryption material over an untrusted link. EAP-TLS is the most typical method of
applying these certificates.
Windows (7, 8, 10, or 11)

Client support Linux, Mac OS X 10.3 (and later), Apple iOS, and Android

Each client requires a user certificate

EAP-TLS-supported RADIUS server

Infrastructure requirements RADIUS server requires a server certificate

CA server (PKI)

Certificate management Client and RADIUS server certificates are managed

To use EAP-TLS, you must install a certificate (a public and a private key) on the authentication server and the
client. An authentication server pair of keys and a client pair of keys must be generated and signed using a PKI and
installed on the authentication server and client.

TLS is intended to be an alternative, standardized version of the widely deployed SSL encryption mechanism. SSL
has long been used for secure web exchanges.

TLS 1.2 is the protocol that is used when you use HTTPS on the Internet to validate the web server
identity so that you can send protected information, such as your credit card details. A certificate is
usually sent from the web server side so that your browser can confirm the server identity and encrypt
the content that is sent to the server.
EAP-TLS uses a certificate to authenticate a user or machine. Certificates are issued to users and computers by a
CA or an RA (most likely an LRA) and are used to validate identity. The maintenance of this CA (which is part of a
PKI) might be a barrier to EAP-TLS deployment for some customers. Each client (user) must have their own
certificate that is personally issued and installed on their machine to perform TLS authentication. Each RADIUS
server must also have its own certificates.

EAP-TLS has native support on Windows 7, 8, 10, and 11. It also has native support on the Apple iOS, Mac OS X,
and Android platforms. Third-party supplicants can be used for non-Windows support.
At the beginning of the authentication process, EAP-TLS uses the 802.1X authentication framework. Therefore, to
allow end-to-end EAP, the WLAN portion uses open authentication until the association phase.

The client sends a start frame to the AP to show that it uses 802.1X and EAP. The authenticator returns a request
identity message to the client. The client sends its identity, user, or machine name. The authentication server then
sends its certificate, which proves its identity and provides the client with a means of sending back encrypted
frames. The client answers with its own certificate.

The start EAPOL is the initial message that the client or AP sends to initiate an EAP dialog.

The client can answer with the machine certificate, user certificate, or the machine certificate and the
user certificate, depending on the type of EAP-TLS that is used.
At this stage, the client and authentication server have proven their identities and have a way to send encrypted
messages to each other. Which kind of encrypted messages can they send? They can use the other end certificate
to directly encrypt the data that they want to transmit over the air. This method is fine for exchange of information
between supplicant and authentication server, but it is insufficient for client data encryption, for two reasons:
• Public and private keys are an efficient way to protect information, but they are too CPU-intensive for fast data
encryption and decryption.
• Public and private keys allow the creation of an encrypted tunnel between the endpoints (in this case, the
authentication server and the client). The AP (or controller) is transparent and cannot read the encrypted
dialogue for authentication. In a wireless environment, the encryption must occur in the wireless space, which
means it must stop at the AP level. The AP is responsible for encrypting and decrypting all data packets. The AP
does not need to extend encryption into the wired network. Using only certificates is insufficient for wireless
encryption in an EAP-TLS authentication scheme.

Instead, you would use the encrypted tunnel between the authentication server and the client to generate a
symmetric key, which is used for the encryption of the data packets. From the exchanged certificates and randomly
generated numbers that are exchanged immediately after the authentication phase, the two ends generate a
common value that is called the master session key.

The authentication server sends the master key to the controller. The encryption occurs between the client and the
AP.
EAP-TLS is used in environments in which deploying and maintaining certificates for all users is necessary to
ensure a high level of security. EAP-TLS is secure, but the need to deploy certificates on each client is sometimes
a burden.

© 2024 Cisco et/ou ses filiales. Tous droits réservés. Contenus imprimés de 00u3u2gd2roHta8UC5d7