Transport Layer Security (TLS)

In the early years of the World Wide Web, Netscape dominated the design of browsers. In fact, most of the innovations in the area during those years came from Netscape. One of those innovations related to security. The early use of the Web was mostly technical. However, the potential for Web trading soon became apparent. A major obstacle to trading was the problem of securing the transaction information. Netscape invented a security approach that came to be known as SSL to help address this problem.

SSL was based on the use of digital certificates. Although it allows for certificates in both the server and the client, the most common model is that the server identifies itself with a certificate and the client uses a password or some other method such as credit card details. The use of a certificate on the server has the tremendous advantage that purchasers do not need to register with the site prior to making purchases. Registration is a nuisance and it may be necessary to distribute the password by a method separate from the Internet. Sometimes password distribution is done by post office mail. You would have to go to the Web site and register. Then you would be mailed a letter containing your password, which could be used to log in and make purchases. But such delays and inconvenience put people off shopping. By contrast, the use of certificates with SSL offers a way to identify and validate Internet traders immediately as well as providing a secure link so sensitive information like credit card details can be sent. No prior arrangement is necessary, enabling the all important impulse purchase.

SSL was built into the Netscape browser and eventually became a standard method for secure Web transactions. It provides a way to authenticate one or both parties and then to open a private communication channel with encryption and integrity checking. However, although the specifications for SSL were made available, it was still a proprietary solution controlled by a single vendor. Vendors and customers prefer technology that is built on international standards rather than proprietary solutions. Therefore, a decision was made to standardize SSL (or a related version) within the IETF.

The result is TLS, which is described in IETF RFC-2246 released in 1999. TLS is the standardized version of SSL. In fact the RFC clearly states this in its introduction:

This document and the TLS protocol itself are based on the SSL 3.0 Protocol Specification as published by Netscape.

However, as the RFC also points out, the differences are such that the two do not interoperate directly. TLS is entirely concerned with the transport protocol layer and builds on to the TCP/IP layer. It does not concern itself with browsers, operating systems, or sockets (originally a UNIX concept but now extended to Microsoft Windows, Apple Macintosh, and other systems).

Functions of TLS

TLS provides more services than we need for WPA/RSN upper-layer authentication. Full TLS provides authentication, encryption, and, in principle, data compression functions.^[2] WPA and RSN have their own built-in encryption methods such as TKIP or AES CCMP, and neither WPA nor RSN specifies the use of data compression. However, the authentication method of TLS is very suitable and fits well into the EAP/IEEE 802.1X model.

^[2] As far as we are aware, the compression functions have never been used in practice.

We'll look at TLS overall first before focusing on the WPA/RSN capabilities. TLS is divided into two layers: the record protocol and the handshake protocol. The record protocol is responsible for shifting data between the two ends of the link using the parameters agreed via the handshake protocol.

The layers are shown diagrammatically in Figure 9.1. You can see how TLS relies on a reliable connection such as TCP/IP to send messages backward and forward. Data comes from the application to the TLS record protocol, where it gets encrypted and compressed as appropriate prior to being sent to the other end. Assuming the other end is valid, the message is then decrypted and uncompressed before delivery.

Figure 9.1. TLS Layers

Notice how the TLS handshake protocol also uses the record protocol to send its messages during the handshake phase. This seems counterintuitive because the handshake protocol is used to negotiate the parameters of the record protocol layer over which it is communicating. TLS is design to handle this bootstrap process; in its initial state, the record protocol just forwards data without any encryption or compression. The record protocol layer operates according to a group of settings or parameters called a connection state. The connection state should be thought of as the configuration settings for the layer. It includes things like "which encryption algorithm is in use" and "what are the encryption keys." The record protocol layer can store four connection states: two connection states for each direction of communication. Two of the states are current and two are pending, as follows:

• Current transmit connection state

• Pending transmit connection state

• Current receive connection state

• Pending receive connection state

The difference between current and pending is quite simple. Current refers to the settings that are in effect now. Pending is a group of settings that are being prepared for use next. When the change occurs, the pending state becomes the current state and a new empty pending set is created, as shown in Figure 9.2. When the connection is first initialized, the current state is NULL: Everything just passes through. There are no keys, no encryption method, and no compression. During this time the handshake protocol can operate and build up the security parameters in the pending states. When everything is ready, the pending states become the current states and the security goes into effect.

Figure 9.2. Changing Connection State

TLS uses certificates for authentication (see the discussion of certificates earlier in the chapter). There are a number of different types of certificate, all working on similar principles. TLS is flexible enough to deal with all the cases, but it makes reading the TLS specification rather tedious. Suffice it to say, a certificate is typically delivered by the server for the client to verify. In rare applications, the server may also request a certificate from the client. Client certificates are typically used only when there is an in-house certificate authority for example, when a corporation issues its own certificates for its employees.

Certificates are based on public key cryptography. It is a clever technique, but it is expensive in processing requirements. The nature of public key crypto methods means that many more computations are needed to encode and decode messages than for symmetric key operations. As a result, TLS does not use public key encryption for bulk data transfers of the record layer; instead, it uses symmetric keys that are agreed upon between the parties during the public key phase. The handshake protocol uses the certificates to perform public key cryptography during the authentication process. It also uses the public key cryptography to exchange some session keys that can be used by the record layer to encrypt data during the session. This approach greatly reduces the workload and, as it happens, fits in very nicely with the way in which WPA/RSN is organized.

Handshake Exchange

A relationship is established between two parties in TLS by using a handshake exchange. This involves a series of messages sent between the parties in a specific order, as summarized in Figure 9.3 and explained in the following sections.

Figure 9.3. TLS Message Exchange Summary

There are several options concerning which messages are sent and what information they contain, but the order is important and, before the end of the handshake, every message is checked for validity. At the start of the handshake, the two parties exchange hello messages, rather like people actually. Remember that TLS is not symmetrical, so one party must take the role of the server and the other the client. Ideally, the client should send the hello message first.

Client Hello (client server)

The client hello is more than just a courtesy message; it contains a list of the ciphersuites and compression methods that the client can support. A cipher suite is a combination of cryptographic methods used together to perform security. In TLS the ciphersuite defines the type of certificates, the encryption method, and the integrity-checking method. The TLS RFC defines some standard combinations, and the client can indicate which ones it supports, in order of preference. Importantly, the Client Hello also carries a random number called ClientHello.random, which can be any value but should be completely unpredictable to everyone (except the client). This random number is used to generate liveness.

A Note on Liveness

When watching sports on TV, you will often hear reference to a live broadcast. This means the broadcast is happening in real time and is not a recording made earlier. It is in this context that we refer to liveness in security. You need to know that the negotiation is live and that you are not dealing with a recording of a previous exchange. Generating and incorporating a different number with each session makes it much harder to use recorded data in an attack. A truly random number has the disadvantage that there is a small probability that the same value will occur twice. A number that is guaranteed never to be used again is called a nonce.

Server Hello (server client)

When the server receives the Client Hello message, it must check that it is able to support one of the chosen ciphersuites and compression methods; then it replies with a Server Hello message. The Server Hello contains two more important items. First, it contains another random number, called ServerHello.random, which is different from the client's random value. Second, it contains a session ID that the client and server use to refer to the session from then on. One of the features of TLS is that a security session, once established, can be resumed multiple times by the client indicating current session ID in the Client Hello message. This is useful for browsers to quickly return to pages that have already been visited. At this stage the client and server have exchanged greetings with the result:

1. They have synchronized their states.

2. They have agreed on a session ID.

3. They have agreed on a ciphersuite.

4. They have exchanged two random numbers (nonces).

"Synchronizing their states" simply means that they both have the same understanding of what is going on. It's no good if one thinks the handshake is just starting and the other thinks it's nearly finished. Also, during the handshake both the client and the server must carefully keep copies of all the messages they have sent or received. At the end of the handshake, they will be required to prove that they have these copies to help ensure that no one has altered or inserted any messages.

Server Certificate (server client)

The next phase involves the certificate exchanges. If the session is being resumed, this stage can be skipped. The server sends its certificate to the client. Remember that there are two important things in the certificate. First, it contains the name and public key of the server. These can be used to encrypt messages to the server and validate signed messages from the server. Second, it is signed by a certificate authority to prove that it is authentic. The client validates the certificate using the certificate authority's public key and then remembers the server's public key to encrypt further messages to the server. Although a bogus server could copy and send the valid certificate, it would not subsequently be able to decrypt the correct pre-master secret because it does not have the secret part of the public/private key pair.

Client Certificate (client server)

The server may require the client to send a certificate. For Web browsing applications, it is unusual for the client to have a certificate though this might change in the future as credit card use becomes more integrated with Web security. Already some services have emerged that allow members of the public to register and obtain digital certificates, which may then be used for access to subscription services. However, the financial industry is reluctant to adopt new technology too quickly, for very good reasons. The majority of transactions are still done using the traditional (and pitifully insecure) method of giving a credit card number and expiry date, albeit over a secure communications channel. For these types of transaction, the server sends a certificate but the client does not.

If a corporation is using TLS for internal network security, it might choose to give out certificates to its own employees. In this case, the IT department becomes a certificate authority and issues certificates for its own servers and all the users. If this approach is taken, the server can be configured to request a certificate from the user. The fact that the client produces a certificate proves nothing, of course, because it could easily have been copied from a previous session. However, the client can subsequently prove that it also has the certificate secret key by digitally signing a message to the server. This is done in the certificate verify stage that we explore later.

So far the client and server have exchanged hello messages. The server has sent a certificate and may have requested the client to do the same. At this point the server sends a Server Hello Done message and waits for the client to take the next step. If the server requested a certificate, the first thing the client should do is send it over; it will be checked later. Now comes the interesting part: The client and server establish a mutual secret key for use in further communications.

Client Key Exchange (client server)

The goal of this phase is to create a mutual secret key between the client and the server, called the master secret. This key binds together the random numbers that were exchanged in the hello message with a secret value that is created dynamically and known only by the two parties (the client and the server). Note that the random numbers (nonces) sent during the hello phase could be seen by anybody monitoring the link; they are exchanged in the clear and not encrypted. By contrast, the random value created at this stage is known as the pre-master secret to reflect the fact that it is secret and will be used to generate the master key. The simplest way to generate the pre-master key and get it securely to both the server and the client is to take advantage of the server's certificate. The client simply generates a random number (48 bytes), encrypts it using the server's public key, and sends it to the server using a client key exchange message. The server decrypts it with its private key and, bingo, both sides have the pre-master secret.

Client Certificate Verification

If the client sent a certificate, now is the time for it to prove that it is the legal owner of that certificate. This is where those copies of all the messages come in useful. The client proves itself by hashing together all the messages up to this point (see the sidebar "A Note on Hashing"), including both the ones sent and the ones received. It then sends the result to the server and signs the message with the secret key of its certificate. The server receives the message and checks the signature using the client's public key as delivered in the client's certificate. If the signature checks out, the server also computes the hash of messages and checks that the result matches. If the signature or the hash check fails, the server should assume that the client is bogus. If it checks out, the server can be sure that the client knows the secret key for the certificate.

The client and server are now in a position to compute the master secret. The details of how this is done are rather complicated, but the concept is simple. Both parties have the following identical information:

• Pre-master secret

• Client random number (nonce)

• Server random number (nonce)

They both now cryptographically combine these values by hashing to produce a 48-byte (384-bit) master key. Because they both have the same values and use the same algorithm, they will, of course, both compute the same key. The incorporation of the random numbers ensures liveness and guarantees that no one can use a recording of a previous exchange. The quality of the random number generator on both sides needs to be high. Some so-called random numbers generate a random distribution of numbers, but in an entirely predictable way. For example, the Rand() function available in many programming languages always produces the same "random" sequence after initialization. The random number used in security must really be unpredictable even after reinitialization.

A Note on Hashing

Hashing is an operation used frequently in cryptography. Its purpose is to combine two or more numbers to produce a result in such a way that it is extremely hard or impossible to reverse the process. In other words, if A and B are hashed together to produce the result C, then knowledge of C tells you nothing about A or B.

Consider normal arithmetic. The basic adding rule is a + b = c. If we know a and b, we can easily work out c. However, if we know b and c, we can, as easily, work out a (a = c b). Hash algorithms do not have this reversible property. So a hash b = c may be easy to compute; but given b and c, it is effectively impossible to work out a.

One application of hashing is to protect a master key by generating a temporary session key. Suppose a = 128-bit master key and b = time of day, then you could generate a new 128-bit key c by hashing together a and b. Even if the attacker knows the time of day and discovers the new key c, he cannot derive the original master key. In this example the new key is the same length as the original one.

Another use of hashes is to combine a large number of bits into a small number. This is used to generate messages' integrity checks. Suppose you hash a 1,000-byte message (8,000 bits) with a secret key to produce a result, which is only 64 bits long. Given the result, an attacker cannot compute the secret key or the original message. However, there is only one correct result that corresponds to the message. By sending the result with the message, the receiver can check that a message is intact and unaltered. Even if a single bit of the 1,000-byte message was altered, the resulting 64-bit hash result would be totally different.

Change Connection State

The object of the handshake has been to authenticate and create a new pending connection state ready to be turned on when all the keys and other required information have been obtained. Remember that there is a current state and a pending state. After initialization, the current state is "no encryption." The master key that has been created is now used to initialize the pending state according to the cipher suite in use. How this is done depends of the details of the cipher suite. For example, the cipher might not need all 384 bits of the master key or will want to derive different keys for receive and transmit, which it can do by further hashing the master key. This is done in WPA/RSN, for example. Suffice it to say that once the master key is established, both the client and the server are able to fully set up the pending connection state and then switch it to become the current state. When the switch is performed, each side sends a change connection state message to the other.

Finished

The handshake performs one more operation before completing confirming that the new cipher suite is operating and that there was no tampering with any of the handshake messages. Each side sends a finished message for this purpose. Remember that the new cipher suite has now been activated, so this message will be encrypted with the new master key. The finished message contains a hash value covering the new master secret and all the handshake messages that have been exchanged from the hello message up to (but not including) the finished message. Assuming the message is received correctly, the new cipher suite is operational. The receiving party can compute the corresponding hash value from its own records and check that the result matches. If it does, everything is valid and it is safe to start passing data using the new master key.

If the TLS session was being resumed, the client and server go straight from the hello message to the finished message, computing a new master key from the new random numbers (in the hello messages) and the old master secret. This process avoids the expensive certificate operations but still prevents bogus clients or servers because knowledge of the pre-master secret is exclusively held by the original authenticated client and server.

Relationship of TLS Handshake and WPA/RSN

This TLS handshake process accomplishes three things:

• It has authenticated the server (and optionally the client).

• It has generated a secret master key for the session.

• It has initialized and put into effect a ciphersuite to protect communications.

Now we need to consider how this method can be applied to support WPA or IEEE 802.11i RSN networks. In WPA, encryption and integrity protection is provided by WEP or TKIP. RSN may support TKIP or AES CCMP. These functions operate only between an access point and a wireless device. The TLS handshake described here is exclusively concerned with two parties: the authentication server and the client. There is no mention of the three-way model we have adopted for IEEE 802.1X with a supplicant, authenticator, and authentication server.

For WPA and RSN, all we need from TLS is the authentication function and the master key generation function. WPA/RSN deals with its own cipher suites. WPA/RSN takes the master secret generated by TLS and then derives a set of keys for use in encrypting the wireless link (see Chapter 10). In this case, although the master key is generated, the TLS record protocol connection state is not updated that is, for WPA/RSN we don't use the TLS record protocol for encryption; we just hijack its handshake exchange to generate a secure master key.

In this way, TLS does integrate well with the IEEE 802.1X model and is specified to run over EAP. It is the default mandatory mode for WPA.

TLS over EAP

Although the designers of TLS probably thought that it would most often be used over a TCP/IP connection, they defined it in a more general way. RFC2246 simply says:

At the lowest level, layered on top of some reliable transport protocol (e.g., TCP), is the TLS Record Protocol.

The key words are "layered on top of some reliable transport protocol." This general definition left the door open to implement parts of TLS directly over EAP "parts" because EAP does not deal with normal data transfer; it is specifically concerned with the authentication phase. When we use TLS in conjunction with WPA/RSN, we want it to run over EAP because that allows us to tie it into the IEEE 802.1X.

RFC2716, PPP EAP TLS Authentication Protocol, defines how to perform the TLS handshake over EAP. As the name suggests, it was originally considered (like EAP itself) in the context of dial-in access authentication using PPP. But we can adapt it for use also with IEEE 802.1X and RSN.

EAP always starts and ends with a similar sequence. Usually, an identity request/response message is exchanged. Then a series of EAP requests and responses are sent that are specific to the authentication method, as identified by a Type field in each message. Finally an EAP-Success or EAP-Failure message is sent to indicate the result (see Chapter 8 for more detail on these structures). RFC2716 defines all the middle messages that we were somewhat vague about in Chapter 8. The general format of the EAP-Request/Response messages is shown in Figure 9.4.

Figure 9.4. Format of EAP Message

For TLS, the RFC defines the Type field for these EAP requests and responses to be the value 13. Only clients and servers that understand EAP-TLS will attempt to decode these messages. RFC2716 also defines two new fields to go after the Type field. These fields are Flags and Length, as shown in Figure 9.5.

Figure 9.5. Format of EAP-TLS Message

Why does length appear twice? The first Length field refers to the length of this EAP frame. However, the second Length field refers to the length of an EAP-TLS packet. EAP-TLS packets can be quite long, exceeding the maximum size of an EAP message. In such a case, the EAP-TLS packet is fragmented that is, broken into multiple pieces and sent in several exchanges. The second length value, in the TLS field, refers to the overall TLS message and not the current frame. Actually this second Length field is optional and is not normally included if the EAP-TLS data fits into the current frame.

The Flags field contains three bits:

• Length included flag: Indicates whether the Length field is present

• More fragments flag: Set if more fragments are to follow in subsequent exchanges

• Start flag: Used to signal start of handshake

The sequence of exchanges that make up the EAP-TLS handshake are outlined in Figure 9.6. We assume that the server has become aware of the client through some method such as EAP-Start. Study the diagram for a minute before we work through it. Here is a commentary of the steps:

1. {request} This is the start of the EAP exchange. Server requests identity of client.

2. {response} Here the client sends an identity message. For corporate use, this could identify the owner of the client certificate that will be sent. If the client does not intend to send a certificate, it will effectively be anonymous and could therefore send any identity here, such as the string "anonymous".

3. {request} The server sends an empty EAP-TLS request with the flag bit start set. This is the only time the start bit is set.

4. {response} The client sends it Client Hello message containing the same information as for normal TLS.

5. {request} The server sends two or three TLS messages in a single request: The server hello, optionally the client certificate request, and the server finished message.

6. {response} The client now replies with several TLS messages in a single response:

   • Client certificate (if requested)

   • Pre-master secret in key exchange message

   • Client certificate verification information

   • Change cipher

   • Finished

   Notice how the client goes ahead, creates the pre-master secret, computes the master secret, and "puts the cipher into effect," all in one go. However, note that the entire EAP message is sent in the original ciphersuite, which is usually open (that is, no encryption). The new ciphersuite is not put into effect until after the end of the EAP messages.

7. {request} The server sends all its remaining messages in a single EAP request.

8. {response} The client has nothing more to say but must respond so it sends an empty response message.

9. Finally to complete the EAP handshake, the server sends an EAP-Success, assuming everything has gone well. If any of the steps failed, the server would have previously sent an EAP-Fail at the point the problem was detected.

Figure 9.6. EAP-TLS Handshake

The use of EAP provides the key for implementing TLS with WPA or RSN. For one thing, the use of EAP means that no IP address is needed and the wireless device can exchange EAP messages to the access point and perform the entire handshake prior to being granted access to the wired network. The access point does not need to understand TLS to complete the transaction, providing it has an authentication server on the network to which to send the EAP messages. And the access point can watch out for the EAP-Success message to learn when it should connect the IEEE 802.1X switch and allow access to the network. However, there are still two unanswered questions:

• How does the access point send EAP messages to the authentication server?

• How does the access point get a copy of the master key for use with TKIP or AES CCMP encryption?

The answer to these questions lies in the use of RADIUS (see Chapter 8). RADIUS is a protocol that allows a device to communicate with an authentication server. It has been much extended over the years although the basic principles are unchanged. One of the key enhancements in relation to WPA/RSN was the inclusion of messages that allow the forwarding of EAP requests and responses directly to the server. The issue of how to get the master key back to the access point is not one that is currently covered by the RADIUS RFCs. Also it is not covered directly by the IEEE 802.11 standard because this is out of scope for the standard. However, WPA specifies the use of a specific Microsoft-defined attribute to ensure interoperability between vendors. This turns out to be the same attribute that is already used in a similar way to send key information to a dial-up modem pool.

Summary of TLS

This section describes how TLS works. TLS is not specifically designed for use with wireless networks. It is based on SSL, a security method used at the application level. However, the invention of a method to support TLS over EAP, combined with changes to the RADIUS protocol to support EAP over RADIUS, has opened a path whereby WPA and RSN can build on the substantial existing support for the protocol. SSL is very widely deployed in Web browsers and servers and it is highly proven. Certificate authorities are well established and provide the infrastructure needed for SSL operation. Now the adoption of TLS for WPA will take advantage of SSL's success.

The next section looks at another popular authentication approach Kerberos V5. Although this has not been specified for WPA, it is still a viable option for RSN and may be more appropriate for customers that already have extensive Kerberos installations.