Scalable voip mobility intedration and deployment- P19 pdf

10 364 0
Scalable voip mobility intedration and deployment- P19 pdf

Đang tải... (xem toàn văn)

Thông tin tài liệu

180 Chapter 5 www.newnespress.com when the PSK had been in use. Furthermore, because preshared keys are text and are common for all devices, they are easy to share and impossible to revoke. Good users can be fooled into giving the PSK away, or bad users—such as employees who have left the organization—can continue to use the preshared keys as often as they desire. These problems are solved, however, by moving away from preshared keys to using 802.1X and EAP. Recently, some vendors have been introducing the ability to create per-user preshared keys. The advantage of having per-user keys is that one user’s access can be revoked without allowing that user to compromise the rest of the network. The problem with this scheme, however, is the continued lack of forward secrecy, meaning that a user who has his password stolen can still have decrypted every packet ever sent or will send using that key. For this reason, 802.1X is still recommended, using strong EAP methods that provide forward secrecy. 5.6.2 802.1X, EAP, and Centralized Authentication Up to now, we’ve discussed Wi-Fi’s self contained security mechanisms. With WPA2, the encryption and integrity protection of the data messages can be considered strong. But we’ve only seen preshared keys, or global passwords, as the method the network authenticates the user, and preshared keys are not strong enough for many needs. The solution is to rely on the infrastructure provided by centralized authentication using a dedicated Authentication, Authorization, and Accounting (AAA) server. These servers maintain a list of users, and for each user, the server holds the authentication credentials required by the user to access the network. When the user does attempt to access the network, the user is required to exercise a series of steps from the authentication protocol demanded by the AAA server. The server drives its end of the protocol, challenging the user, by way of a piece of software called a supplicant that exists on the user’s device, to prove that the user has the necessary credentials. The network exists as a pipe, relaying the protocol from the AAA server to the client. Once the user has either proven that she has the right credentials—she apparently is who she says she is—the AAA server will then tell the network that the user can come in. The entire design of RADIUS was originally centered around providing password prompts for dial-up users on old modem banks. However, with the addition of the Extensible Authentication Protocol (EAP) framework on top of RADIUS, and built into every modern RADIUS server, more advanced and secure authentication protocols have been constructed. See Figure 5.22. The concept behind EAP is to provide a generic framework where the RADIUS server and the client device can communicate to negotiate the security credentials that the network administrator requires, without having to concern or modify the underlying network access technology. To accomplish this last feat, the local access network must support 802.1X. Introduction to Wi-Fi 181 www.newnespress.com 5.6.2.1 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 RADIUS Server Phone Wireless ControllerAccess Point Supplicant EAPOL EAP over RADIUS User Credentials Authenticator/ NAS Figure 5.22: The Components of RADIUS Authentication Over Wi-Fi 182 Chapter 5 www.newnespress.com provide more than a password. A thorough description of public key cryptography will be given in Chapter 8 security for voice mobility, as it is such a crucial topic, and you may want to skip ahead and read that part for the details. 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 network Introduction to Wi-Fi 183 www.newnespress.com administrator, 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. 5.6.2.2 802.1X 802.1X, also known as EAPOL, for EAP over LAN, is a basic protocol supported by enterprise-grade Wi-Fi networks, as well as modern wired Ethernet switches and other network technologies. The idea behind 802.1X is to allow the user’s device to connect to the network as if the RADIUS server and advanced authentication systems did not exist, but to then block the network link for the device for all other protocols except 802.1X, until authentication is complete. The network’s only requirements are twofold: prevent all data traffic from or to the client except for EAPOL (using Ethernet protocol 0x888E) from passing; and taking the EAPOL frames, removing the EAP messages embedded within, and tunneling those over the RADIUS protocol to the AAA server. The job of the network, then, is rather simple. However, the sheer number of protocols can make the process seem complex. We’ll go through the details slowly. The important thing to keep in mind is that 802.1X is purely a way of opening what acts like a direct link between the AAA server and the client device, to allow the user to be authenticated by whatever means the AAA server and client deem necessary. The protocols are all layered, allowing the highest-level security protocols to ride on increasingly more specific frames that each act as blank envelopes for its contents. Once the AAA server and the client have successfully authenticated, the AAA server will use its RADIUS link to inform the network that the client can pass. The network will tear down its EAPOL-only firewall, allowing generic data traffic to pass. In the same message that the AAA server tells the network to allow the client (an EAP Success), it also passes the PMK—the master key that the client also has and will be used for encryption—to the network, which can then drop into the four-way handshake to derive the PTK and start the encrypted channel. This PMK exchange goes in an encrypted portion of the EAP response from the RADIUS server, and is removed when the EAP Success is forwarded over the air. The encryption is rather simple, and is based on the shared password that the RADIUS server and controller or access point have. Along with the PMK comes a session lifetime. The RADIUS server tells the controller or access point how long the authentication, and subsequent use of the keys derived from it, is valid. Once that time expires, both the access point and the client are required to erase any knowledge of the key, and the client must reauthenticate using EAP to get a new one and continue using the network. 184 Chapter 5 www.newnespress.com For network administrators, it is important to keep in mind that the EAP traffic in EAPOL is not encrypted. Because the AAA server and the client have not agreed on the keys yet, all of the traffic between the client and the RADIUS server can be seen by passive observers. This necessarily limits the EAP methods—the specific types of authentication—that can be used. For example, in the early days of 802.1X, an EAP method known as EAP-MD5 was used, where the user typed a password (or the client used the user’s computer account password), which was then hashed with the MD5 one-way cryptographic hash algorithm, and then sent across the network. Now, MD5 is flawed, but is still secure enough that an attacker would have a very hard time reverse-engineering the password from the hash of it. However, the attacker wouldn’t need to do this, as he could just replay the same MD5 hashed version himself, as if he were the original user, and gain access to the network. For this reason, no modern wireless device supports EAP-MD5 for wireless authentication. 5.6.2.3 Key Caching Because the work required establishing a PMK when 802.1X and RADIUS are used is significant, WPA2 provides for a way for the PMK to be cached for the client to use, if it should leave the access point and return before the PMK expires. This is done using key caching. Key caching works because each PMK is given a label, called a PMKID, that represents the name of the RADIUS association and the PMK that was derived from it. The PMKID is specifically a 128-bit string, produced by the function PMKID = HMAC-SHA1-128(PMK, “PMK Name” || AA || SPA), where AA is the BSSID Ethernet address, SPA is the Ethernet address of the client, and HMAC-SHA1-128 is the first 128 bits of the well-known SHA1-based HMAC function for producing a cryptographic one-way signature with the PMK as the key. The double-pipes (“||”) represent bitwise concatenation. The “PMK Name” ASCII string is used to prevent implementers from putting the wrong function results in the wrong places and having it work by accident. From this, it is pretty clear to see that a client and access point can share the same PMKID only if they have the same PMK and are referring to each other. When the client associates, it places into its Reassociation message’s RSN information element (Table 5.16) the PMKID it may have remembered from a previous association to the access point. If the access point also remembers the previous association, and still has the PMK, then the access point will skip starting 802.1X and will proceed to sending the first message in the four-way handshake, basing it on the remembered PMK. This caching behavior is not mandatory, in the sense that either side can forget about the PMK and the connection will still proceed. If the client does not request a PMKID, or the access point does not recognize or remember the PMKID, the access point will still send an Introduction to Wi-Fi 185 www.newnespress.com EAP Request Identity message, and the 802.1X protocol will continue as if no caching had taken place. 5.6.3 Putting It All Together: An Example The client passes through a number of phases when associating to a Wi-Fi network that uses enterprise-grade security. To help understand how everything fits together, we will go through one example authentication, using WPA2 and the EAP method EAP-PEAP, which requires each mobile device to have a username and password. The password will be sent, securely tunneled through PEAP, to the RADIUS server, which is usually attached to a Microsoft Active Directory server. Each message that is sent will be represented by a table, showing the relevant contents of the message. The aim is to allow the reader to follow along, when analyzing wireless packet capture traces, what the individual steps mean, when a client associates to the network. As a matter of presentation, when information that might be important is repeated in subsequent messages, it will be omitted for those messages. Step 1: Associate with the Wi-Fi Network The mobile device, having scanned for the SSID of the network desired—let’s call it voice for this example—has found an access point that is advertising the voice SSID. The client requests a connection with the access point by sending an 802.11 Authentication message, requesting open authentication, meaning that the client does not want to use WEP. See Table 5.19. Table 5.19: 802.11 Authentication message from client to AP Frame Control Destination Address Source Address BSSID Algorithm Number Authentication Sequence Authentication AP Address Client Address AP Address 0 (Open System) 1 Table 5.20: 802.11 Authentication message from AP to client Frame Control Destination Address Source Address BSSID Algorithm Number Authentication Sequence Status Code Authentication Client Address AP Address Client Address 0 (Open System) 1 0 (Success) The access point accepts the open connection by responding with its own 802.11 Authentication message, to the client, simply stating that the request is a success. See Table 5.20. 186 Chapter 5 www.newnespress.com The access point accepts the association request and sends an 802.11 Association Response message to the client, announcing success, providing the client with the access point’s capabilities and its network-wide configuration parameters. At this point, the client cannot speak to any other access point without disconnecting or being disconnected, but it cannot send or receive any real data traffic. The client must first use EAPOL to authenticate. Step 2: Authenticate with the AAA Server The sends an EAPOL Start message (Table 5.22), encoded as a Wi-Fi Data frame with Ethernet protocol 0x888E, sent to the Ethernet address of the access point. This message is optional, but when sent is meant to request that the access point should start the EAP exchange. Table 5.21: 802.11 Association request message from client to AP Frame Control Destination Address Source Address BSSID Capabilities SSID Information Elements Association Request AP Address Client Address AP Address Capabilities voice Radio, Security, and QoS Capabilities Table 5.22: 802.11 EAPOL start message Frame Control Destination Address Source Address BSSID EtherType EAPOL Type Data AP Address Client Address AP Address 0x888E Start Table 5.23: 802.11 EAP request identity Destination Address Source Address Ether-type EAPOL Type EAP Code EAP Type Identity Client Address AP Address 0x888E 0=EAP 1=Request 1=Identity hello At around the same time, the access point will usually voluntarily send an EAPOL message with an EAP Request Identity message inside (Table 5.23), triggering the start of the authentication process. The Request Identity message is the EAP way of asking the client to announce who he or she is. The client then sends an 802.11 Association Request message to the access point, informing the access point of its Wi-Fi capabilities, supported extensions and 802.11 features (Table 5.21). Introduction to Wi-Fi 187 www.newnespress.com This response triggers the start of the PEAP protocol, tunneled over EAP, tunneled over EAPOL, carried over 802.11. The first message is from the RADIUS server, through the access point, and informs the client that PEAP is beginning (Table 5.25). PEAP uses TLS as the outer tunnel, within which the encrypted username and password are passed. The first message in the TLS exchange is what is known as a TLS Client Hello (Table 5.26). The Client Hello passes the client’s nonce, used as a part of the key derivation protocol. The client will specify a number of cipher suites, but must specify RSA public key encryption with RC4 stream encryption and either MD5 or SHA hashes. Table 5.24: 802.11 EAP response identity Destination Address Source Address Ether-type EAPOL Type EAP Code EAP Type Identity AP Address Client Address 0x888E EAP 2=Response Identity LOCATION\ user Table 5.25: 802.11 EAP request PEAP Destination Address Source Address Ether-type EAPOL Type EAP Code EAP Type Flags Client Address AP Address 0x888E EAP Request 25=PEAP Start Table 5.26: 802.11 PEAP client hello Destination Address Source Address EAP Code EAP Type TLS Type Handshake Type Nonce Cipher Suites AP Address Client Address Response PEAP 22=Handshake 1=Client Hello random Many The client receives the request for the identity and responds with identity to use (Table 5.24). Let’s call the user “user”, in the domain “LOCATION”. PEAP uses a separate protocol (MSCHAPv2) for the presentation of the real username and password. The identity given in the outer protocol may or may not matter, depending on the RADIUS server. In this example, the outer identity is the same one given as the real, inner identity: “LOCATION\user”. The server will respond with a Server Hello. The Server Hello message will specify the server’s nonce, a session ID (which is usually not taken advantage of by wireless clients), one of the client’s cipher suite to use for the rest of the process, and the beginning of a chain of certificates for the RADIUS server, which identifies itself as being valid. The client will usually verify that the server is signed by a valid certificate authority somewhere along the path and is allowed to serve the role it does, unless the client’s administrator has 188 Chapter 5 www.newnespress.com explicitly disabled this check. Because certificates are much longer than the maximum EAPOL packet, the PEAP Server Hello and Certificate will be divided up over many consecutive EAPOL frames from the access point. After the certificate, the server may include a request for the client to send a certificate. This would be used by PEAP to short- circuit the inner tunnel and revert to plain TLS, if the client has a certificate. Usually, PEAP is not used with client certificates, so the client will ignore this request and trigger the password exchange. If requested, the types of certificates and distinguished names of acceptable certificate authorities, one of whom needed to have signed any client certificate given, will be provided. The message ends with a Server Hello Done. See Table 5.27. Table 5.27: 802.11 PEAP server hello and certificate, usually split across multiple EAPOL messages Destination Address Source Address EAP Code Flags TLS Type Handshake Type Session ID Nonce Client Address AP Address Request 0x40 = More Handshake 2=Server Hello arbitrary random … Handshake Type Server Certificate Handshake Type Certificate Types Distinguished Names Handshake Type … 11=Certificate X509 Certificate 13=Certificate Request RSA, DSS… Any Names 14=Server Hello Done Table 5.28: 802.11 EAP response PEAP Destination Address Source Address Ether-type EAPOL Type EAP Code EAP Type AP Address Client Address 0x888E EAP Response PEAP The client will respond to the intermediate server certificate messages with empty responses, to keep the request/response protocol going (Table 5.28). When the Server Hello Done message arrives at the client, the client will kick off the second, inner phase of PEAP. First, the client responds with a Certificate handshake message. If the client were going to provide a certificate, it would do so here. However, with normal PEAP, the certificate message will be empty. Following this is the Client Key Exchange. Let’s assume that the server and client agreed to RSA public key encryption. The client chooses a random 48-byte premaster key, which is encrypted by the server certificate’s RSA public key, and then packaged in the key field. Following this comes the Change Cipher Spec message (Table 5.29), to inform the server that all future communications will take place using encryption based on the key. Finally, the first encrypted message is introduced, which is a marker, encrypted by the key, that states that the cipher change is done. Introduction to Wi-Fi 189 www.newnespress.com Table 5.29: 802.11 PEAP client change cipher spec Destination Address Source Address EAP Code Flags TLS Type Handshake Type Client Certificate AP Address Client Address Response none Handshake Certificate none … Handshake Type Key Handshake Type Handshake Type Encrypted Handshake … 22=Client Key Exchange Pre-master Key 20=Change Cipher Spec 32=Encrypted Handshake Message Finished (encrypted with TLS PRF) Table 5.30: 802.11 PEAP server change cipher spec Destination Address Source Address EAP Code TLS Type Handshake Type Handshake Type Encrypted Handshake Client Address AP Address Request Handshake Change Cipher Spec Encrypted Handshake Message Finished (encrypted with TLS PRF) Table 5.31: 802.11 EAP response PEAP Destination Address Source Address Ether-type EAPOL Type EAP Code EAP Type AP Address Client Address 0x888E EAP Response PEAP Table 5.32: 802.11 PEAP encrypted request identity Destination Address Source Address EAP Code TLS Type EAP Code (encrypted with RC4) EAP Type (encrypted) Client Address AP Address Request 23=Application Data Request Identity The server now responds with a Change Cipher Spec and Finished message (Table 5.30), to mark the switch over of the protocol completely to the inner TLS tunnel. The client, once again, sends an empty response (Table 5.31). Now, the inner MSCHAPv2 protocol can take place. Table 5.32 will peel back the inner TLS tunnel and reveal the contents. The inner tunnel will also present an EAP exchange, but using MSCHAPv2, rather than TLS. . Flags TLS Type Handshake Type Client Certificate AP Address Client Address Response none Handshake Certificate none … Handshake Type Key Handshake Type Handshake Type Encrypted Handshake … 22=Client. Address Request 0x40 = More Handshake 2=Server Hello arbitrary random … Handshake Type Server Certificate Handshake Type Certificate Types Distinguished Names Handshake Type … 11=Certificate X509. Type TLS Type Handshake Type Nonce Cipher Suites AP Address Client Address Response PEAP 22=Handshake 1=Client Hello random Many The client receives the request for the identity and responds

Ngày đăng: 03/07/2014, 19:20

Từ khóa liên quan

Mục lục

  • NewNes Publishing - Scalable VoIP Mobility (2009) (ATTiCA)

  • Dedication

  • Introduction to Voice Mobility

    • Introduction to Voice Mobility

      • Why Voice Mobility?

      • Audience and Expected Background

      • How to Read This Book (Chapter Layout)

      • Voice Mobility Technologies

        • Voice Mobility Technologies

          • Introduction

          • The Anatomy of a Voice Call

            • The People and Their Devices: Phones

            • The Separate Channels: Signaling and Bearer

            • Dialing Plans and Digits: The Difference Between Five- and Ten-Digit Dialing

            • Why PBXs: PBX Features

            • Signaling Protocols in Detail

              • The Session Initiation Protocol (SIP)

                • SIP Architecture

                • SIP Registration

                • Placing a SIP Call

                • A Rejected SIP Call

                • Hanging Up

                • SIP Response Codes

                  • In-Progress Codes

                  • Success Code

                  • Redirection Codes

                  • Request Failure Codes

                  • Server Failure Codes

Tài liệu cùng người dùng

  • Đang cập nhật ...

Tài liệu liên quan