Upper-Layer Authentication

Symmetric Keys

The concept of the symmetric secret key is simple. Each party has a copy of some secret information. Authentication occurs when each party proves to the other that they know the secret. This is like the child's method, "You can't come in unless you tell me the password." When each party has proved itself, they can both create matching session keys for use in the security context. Such keys are derived from the secret master key but may also incorporate other information, such as the time and arbitrary numbers created for the session (called nonces). The purpose of these extra items is to ensure that the session keys are usable only in the current session and cannot be reused later.

The main limitation with the secret key approach is that you have to get the secret to both parties in the first place. Sometimes that is not a problem. To communicate with your domestic partner, for example, you could agree on your secret Wi-Fi LAN key during a private moment when no one else is listening. This scenario, or at least the key exchange part, also works in corporate environments in which there is a secure place for the two parties, such as the employee and the IT manager, to meet. However, the approach doesn't scale at all for widespread use. In a huge corporation it is hard to distribute such keys and, in the case of Internet commerce, it is impossible. When you want to make a secure exchange with another party in another country whom you have never met, and never will, there is no practical way to safely agree on secret keys by informal communication.

Asymmetric Keys

To deal with the situation in which you can't easily distribute the secret key, the idea of asymmetric key encryption was invented, leading to the use of public keys. Public key encryption is supported by a set of components often referred to as PKI (public key infrastructure).

First, let's look at the encryption part of public key use. The very words "public key" sound like a contradiction in terms. If the key is public, what use can it be for privacy? However, this name is misleading because a person who uses public key encryption actually has two keys. One key is made public and the other must be kept private. Furthermore, these are not any two keys; the public and the private copies are a mathematically connected pair. The way public key encryption works is fascinating and almost counterintuitive.

As an analogy, suppose a wizard wants to send you a message. He writes the message on a piece of paper and puts it in a magic box. Now he closes the box and recites your name three times. The box is immediately sealed and cannot now be opened by anyone except you; not even the wizard can open it. When the box arrives, you recite a secret word three times and the box opens. The wizard knows your name and can seal the box with it; that is your public key. But only you know the secret word to open the box again; that is your private key.

How does this work with encryption? Many encryption systems are symmetric in that the same key is used to encrypt and then decrypt the message. However, public key systems use an asymmetrical method in which different keys are used for encryption and decryption. You encrypt with key E and decrypt with key D. Furthermore, you can't decrypt with key E, and knowing E doesn't enable you to compute D. In public key encryption, E is the spell to seal the box, or the public key. D is the spell to open the box, or the private key.

When you want to use public key encryption through programs such as PGP (Pretty Good Privacy), you first use a key-generating utility. You run this utility and usually enter some personal information to help ensure your keys are unique to you. The utility then generates two key values, a public key and a private key. The public key can be given to anyone. And the key can be used to encrypt a message using your public key and send it to you. Only you can decrypt the message because only you know the private key. It's like magic!

A subtle and important variant of this method lets you sign messages. Signing a message is like signing a document: It is intended to prove that the message came from a particular person. Message signing works in the reverse way from encryption. You use a private key to create a signature and a public key to check the signature. In a simple case, you take your name and encrypt it with your private key. The result is added to the end of your message. Anyone who receives the message (friend or foe) can decrypt the signature using your public key. If the signature successfully decrypts and reveals your name, it proves that you must have sent the message because no one else knows the secret key that was used to encrypt it. A forger could not have encrypted your name correctly because she wouldn't know your secret key. So this proves that you approved the message in the same way that signing a letter does—actually, much stronger.

In reality, the above scheme doesn't prevent someone from creating a new bogus message and copying your encrypted signature from a valid message (like photocopying your signature on a letter). To protect against this, you must do more than include your name in the signature; you must include other information as well. In practice, the entire contents of the message are usually included in the signature computation to protect against tampering.

Because verifying that a message really came from the sender is very important, systems like PGP do both encryption and message signing. Remember that public key encryption by itself provides privacy but does not authenticate the sender. Suppose you receive an encrypted message saying, "Sally, come quickly, I need your help. Meet me at the bar downtown, Fred." How do you know the message is real (ignoring the fact that your name probably isn't Sally)? The message is encrypted with your public key, so anyone could have forged it. A burglar may want you to leave your house, or worse. But if Fred signed the message with his private key, you can verify that it was really him who sent it, right?

Well, maybe … it depends. Now we are back to our original key distribution problem. How do you know that Fred's public key really belongs to Fred? In this case, it's probably because you met Fred face to face and he told you the public key. Or more likely, you have had various exchanges of e-mail with Fred using his key and you trust that it really is him. But suppose you just started using public key yesterday and you received an e-mail (unencrypted) from Fred two days ago that said, "Hi. This PGP stuff is cool—let's use it. My public key is: FREDSKEY." Can you be sure that Fred sent this message and not some (computer-literate) burglar? This is reminiscent of the sort of problem that we had with the distribution of symmetric secret keys.

Certificates and Certification Authorities

What is needed is a way to certify that public keys are legitimate. This issue of certifying that a public key really belongs to the expected person becomes even more important when you use the method for Internet transactions with complete strangers or corporations. Think about e-commerce. You really want to be sure that the Web site you are giving your credit card details to is who they say they are. When your order doesn't show up, and you call to inquire, you don't want to hear, "Sorry, we have no record of that transaction" because someone was impersonating the vendor. The solution comes by using a trusted third party: a certificate authority.

Essentially, a certificate authority is a trusted independent organization that certifies a set of public and private keys for use with PKI transactions. The authority handles this task by generating certificates in a standard format. A certificate is just a bunch of data. It has no physical form. However, when another party sends you a certificate, it contains enough information for you to validate who they are and establish a secure context. With most Web purchases, this is a one-way context that protects the consumer. The vendor gets protection through your credit card details!

Suppose you set up a Web company selling flags. You get a Web domain name such as www.myflagsarebest.com. You want this address to be certified to you so, when people come to your site and go to the secure purchase area, they are sure that no one is hijacking the connection. You can go to a certificate authority and purchase a certificate that binds your company and its Web site into your public and private key pair.

Functions of TLS

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

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

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.

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:

"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

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.

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.

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 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?

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.

Kerberos

Using Tickets

Kerberos Tickets

A ticket is just a piece of data in a special format. All Kerberos tickets have the same basic structure but, to help the explanation, we'll say that there are three types of ticket:

• Ticket-granting

• Service access

• Referral

The introduction to this chapter notes that a master ticket must be obtained before all others. In Kerberos there is nothing quite so strong as a master ticket but, instead, there is a similar concept called a ticket-granting ticket (TGT). The ticket-granting ticket lets you get other tickets from a key distribution center (KDC) for the local security domain (called "realm" in Kerberos).

Obtaining the Ticket-Granting Ticket

It is the job of the authentication server to check the client and confirm that it is allowed access to the network. Kerberos uses the approach of shared secrets. The client has some secret information and a copy of this information is stored in a protected user datab