What is Authentication in 802.1X?

Let's first define exactly what authentication is, and what the technology expects out of the authentication process. We've mentioned credentials immediately preceding this section. An authentication credential is something that one party to communication has that the other parties can use to verify whether the user is really who he claims he is and is authorized to join the network.

In the preshared key case, the authentication credential is just the preshared key, a global password that every user shares. This is not very good, because every user appears identical, and there is no way for users to know that their networks are also authentic. Authentication should be a two-way street, and it is important for the clients to know that the network they are connecting to is not a fraud. With preshared keys, anyone with the key can set up a fraudulent rogue access point, install the key, and appear to be real to the users, just as they can arbitrarily decrypt over-the-air traffic.

Normal computer account security, such as what is provided by email servers, enterprise personal computers, and Active Directory (AD) networks, generally uses the notion that a user has a unique, secret password. When the user wants to access the network, or the machine, or the email account, she enters her password. If this password matches, then the user is allowed in. Otherwise, he or she is not.

(In fact, to prevent the system administrators from having access to the user's password, which the user might use in other systems and might not want to share, these systems will record a cryptographically hashed version of the password. This version, such as the MD5-hashed one mentioned in the next section, prevents anyone looking at it from knowing what the original password is, yet at the same time allows the user to type their password at any time, which leads to a new MD5-hashed string that will be identical to the one recorded by the system if and only if the passwords are identical.)

This identifies the user, but what about the network, which can't type a password to prove itself to the user? More advanced authentication methods use public key cryptography to provide more than a password. The background is quite simple, however. Public key cryptography is based on the notion of a certificate. A certificate is a very small electronic document, of an exact and precise format, containing some basic information about the user, network, or system that the certificate represents. I might have a certificate that states that it is written for jepstein@somecompany.com, pretending for a moment that that is the name of my user account at some company. The network might have a certificate that states it is written for network.somecompany.com, using the DNS name of the server running the network. To ensure that the contents of the certificate are not downright lies made up in the moment, each certificate is signed using another certificate, that of a certificate authority who both parties need to trust in advance. Finally, each certificate includes some cryptographic material: a public key, that is shouted out in the certificate, and a private key, which the owner of the certificate keeps hidden and tells no one. This private key is like a very big, randomly generated password. The difference is that the private key can be used to encrypt data that the public key can decrypt, and the public key can be used to encrypt data that the private key can decrypt. This allows the holder of the certificate to prove his or her identity by encrypting something using his or her private key. It also allows anyone else in the world to send the holder of the certificate a private message that only the holder can decrypt.

Certificates are necessary for network authentication. When the user tries to authenticate to the network, the network will prove its identity by using its private key and certificate, and the client will accept it only if the network gives the right information based on that certificate. Certificates are also useful for user authentication, because the same properties work in reverse. The EAP method known as EAP-TLS requires client certificates. Most of the other Wi-Fi-appropriate EAP methods use only server certificates, and require client passwords instead.

To recap, authentication over Wi-Fi means that the user enters a password or sends his certificate to the AAA server, which proves his identity, while the network sends its certificate to the client, whose supplicant automatically verifies the network's identity—just like how web browsers using HTTPS verify the server's identity.

It is the EAP method's job to specify whether passwords or certificates are required, how they are sent, and what other information may be required. The EAP method also is required to allow the AAA server and the client to securely agree to a master key—the PMK—which is used long after authentication to encrypt the user's data. The EAP method also must ensure that the authentication process is secure even though it is sent over an open, unencrypted network, as you will see in the following section on 802.1X.

The administrator is allowed to control quite a bit about what types of authentication methods are supported. The AAA administrator (not, you may note, the networkadministrator, unless this is the same person) determines the EAP methods, and thus the certificate and authentication requirements. The AAA administrator also chooses how long a user can keep network access until he or she has to reauthenticate using EAP. The network administrator controls the encryption algorithm—whether to use WPA or WPA2. Together, the two administrators can use extensions to RADIUS to also introduce network access policies based on the results of the AAA authentication.

Authentication, Authorization, and Accounting (AAA)

Authentication, authorization, and accounting have become so important that the IETF has started a separate working group (www.ietf.org/html.charters/aaa-charter.html ) that is focusing on a general AAA architecture for the Internet in order to “create a set of base protocols applicable to a number of specific AAA applications.” The applications include IP telephony and access server AAA. Note that the IETF does not get involved in the issues of business models or billing; the first two As were standardized as part of Remote Authentication Dial-In User Service (RADIUS), defined in RFC 2138, while the accounting part is published in the informational RFC 2139. RADIUS has been implemented and deployed in remote access servers ; the aaa working group was created as a follow-up to RADIUS.

Authentication of an entity can be done via a Password Authentication Protocol (PAP), which sends the request for password and then verifies the response, or a Challenge Handshake Authentication Protocol (CHAP), which “challenges” the entity to be authenticated by sending it a random string S.

The entity uses a function f (identified by a secret key, which may otherwise be known only to the authenticator) to compute f(S). The computed value is sent to the authenticator, who computes the same function on the same string, checks the response, and confirms or fails the entity depending on whether the computed and received values are equal. In a communication session, this process can repeat at random intervals.

PPP CHAP is standardized in RFC 1994, which, among other things, provides a thorough review of its advantages and disadvantages (there are some) as well as some practical considerations. RFC 1994 specifies four messages: Challenge, Response, Success, and Failure. Challenge is sent during the authentication phase (but it may be sent at other times, too); it is sent again and again until a satisfactory Response message is received (or an optional counter exceeds a specified value). The Failure message is sent if the Response value is unsatisfactory; otherwise, naturally, the Success message is sent.

Although authentication is performed in only one direction, the processes on the both ends of the PPP link can use it to authenticate each other. RFC 1994 effectively requires that Message Digest Algorithm Five (MD5) (RFC 1321) be supported for hashing with CHAP. In practice, either specialized hardware (typically, a card) or software is employed to compute the challenge. Although we don’t cover cryptography in detail, it is worth at least explaining why the words message digest are used in the name of the algorithm. This happens because the algorithm, which takes a message M of any length as an input, produces as the output a string MD5(M), whose length is fixed. Computing this string is much faster than encrypting the whole message. For more information on cryptography, see Tanenbaum (1996).

RFC 2138 defines RADIUS as a client-server protocol. One client of the RADIUS server is the Network Access Server (NAS), which can perform the LAC or LNS function (or both). In turn, a RADIUS server may also act as a proxy client to other RADIUS or (non-RADIUS) authenticating servers. When a user requests a connection, the NAS makes a corresponding request to an appropriate RADIUS server, which then attempts to authenticate the users. If the authentication is successful, the RADIUS server sends to the NAS the configuration information pertinent to the user in order to establish the requested connection and otherwise provide all services that the user is entitled to. Specifically, RADIUS server queries the user database, whose entries include lists of requirements (such as password verification) to be met in order to establish the connection. The user database entries may contain specific resources (for example, servers) that a particular user may access as well as specific port numbers.

All transactions between the client and server are authenticated through the use of the shared secret, which is never sent over the network. (The users’ passwords, however, are sent to RADIUS servers over the network, but they are always encrypted before they are sent.) The shared secret is put through the MD5 algorithm to create a 16-octet-long digest value used to authenticate messages between the RADIUS client and RADIUS server. Before we continue our discussion of the RADIUS messages, note that ultimately it is the NAS that is responsible for authenticating the end user (with or without RADIUS). Thus the NAS is the first entity to receive the user’s password. (This is done by either prompting the user or employing the information that arrived in the PPP authentication packets.)

Once the NAS has the password, it may submit it to a RADIUS server in the Access-Request message, whose attributes include the user’s ID and password (hidden using the MD5 algorithm). The RADIUS server considers such a request valid only if it shares a secret with the client. All invalid Access-Request messages are discarded; every valid Access-Request message is responded to (after a lookup in the user database) with one of the following three messages:

§  Access-Reject. This message is issued if the requirements pertinent to the user requesting access are not met.

§  Access-Accept. This message is issued if such requirements are met.

§  Access-Challenge. This message is issued if the user is to be authenticated via the challenge mechanism.

The latter message may include the text (typically obtained from an external server) to be displayed to the user (for example, Challenge 90778976. Please respond at the prompt =>). The NAS issues the request to the user, collects the response, encrypts it, and sends it back to the RADIUS server in the password field of yet another Access-Request message. The RADIUS server may then issue another challenge or reply with either Access-Reject or Access-Accept, depending on whether the user’s response to the challenge matches the expected response.

For the cases where PAP and CHAP are employed by the NAS, RFC 2138 specifies interworking with these protocols, which in most cases amounts to one-to-one mapping of respective attributes. In some cases, however, the RADIUS server may be unable to perform the requested CHAP-compliant authentication. In the example given in RFC 2138, the user password may be unknown to the RADIUS server in cleartext. Since CHAP needs the cleartext password value in order to encrypt the CHAP challenge, RADIUS cannot perform the authentication. RFC 2138 leaves no ambiguity, however, by requesting that the RADIUS server send Access-Reject when it cannot go through with authentication.

The remaining RADIUS messages are:

§  Accounting Request and Accounting Response. Described in the informational RADIUS RFC (2139), although their codes are assigned by RFC 2138.

§  Status-Server and Status-Client. Designated experimental by RFC 2138.

All the RADIUS messages are assigned codes specified in RFC 2138. In addition, one RADIUS message code is reserved for the future.

RFC 2138 has deliberately chosen UDP as the transport layer for RADIUS messages. Four reasons for doing so include:

1.  Presence of alternative servers.

2.  Timing requirements.

3.  Stateless nature of the protocol.

4.  Simplification of server implementation.

Simple Telecom : Security

Security management of a network involves identity validation (authentication), service authorization, and information privacy protection. Authentication processes identifies the device or person that is requesting the use of the telecommunications device or network services. Authorization is the process of determining what services devices are customers are permitted to use. Privacy or encryption services are used to help ensure that the information transmitted or received is not available to unauthorized recipients.

Authentication
Authentication is a process during where information is exchanged between a communications device (typically a user device such as a mobile phone) and a communications network that allows the carrier or network operator to confirm the true identity of the user (or device). Validation of the authenticity of the user or device allows a service provider to deny service to users that cannot be identified. Thus, authentication inhibits fraudulent use of a communication device that does not contain the proper identification information.

Authorization
Authorization is the enabling of services to a device or customer that requests services. Authorization is often part of the billing and customer care (BCC) system and is maintained in a customer database service profile. Services are initially enabled in a network as a result of provisioning. Provisioning is a process within a company that allows for establishment of new accounts, activation, termination of features, and coordinating and dispatching the resources necessary to fill those service orders. Provisioning is usually part of customer care systems.

Networks sometimes use mediation devices to help manage provisioning and authorizing services to customers. A mediation device is device in a telecommunications network that receives, processes, reformats, and sends information to other formats between network elements. Mediation devices are can take non-standard proprietary information (such as proprietary digital call detail records) from switches and other network equipment and reformat them into messages billing systems can understand.

Information Privacy
Information privacy is a process of protecting transmitted or received information from being understood by unauthorized recipients. Information privacy typically involves encrypting of the voice signal with a shared secret key so only authorized users with the correct key and decryption program can listen to the communication information.

Encryption is a process of a protecting voice or data information from being obtained by unauthorized users. Encryption involves the use of a data processing algorithm (formula program) that uses one or more secret keys that both the sender and receiver of the information use to encrypt and decrypt the information. Without the encryption algorithm and key(s), unauthorized listeners cannot decode the message.