Scalable voip mobility intedration and deployment- P34 ppsx

330 Chapter 8 www.newnespress.com Failure. The Identifier serves the same purpose as with RADIUS (though it need not be equal), and keeps track of requests and responses. The Type field is for requests and responses only. A type field of 1 is for Identity. EAP transactions start off by the RADIUS server sending a Request-Identity message, meaning that the Code is Request and the Type is Identity. The client then responds with a Response-Identity, with the Data field containing the text username the client has. After this transaction, the EAP mechanism is entirely dictated by the type of authentication in use. These mechanisms are referred to as EAP Types, and are where the administrator has the most influence. The following sections describe the authentication type and architecture, then dig into the protocol. 8.2.3 Certificate-Based Authentication Certificate-based authentication replaces username and password authentication. Every user (or his machine, as the case may be) is issued a certificate. This certificate of authenticity contains the name and information about the user, including what roles they can take with that certificate. The certificate is then signed cryptographically by a signing authority, a trusted agent who signs certificates as proof of validity. 8.2.3.1 Public-Key Cryptography We now enter the world of public-key cryptography. Public-key cryptography is a set of mathematical procedures and theorems that allows one party to send an unauthenticated message that only the other party can read. This might sound shocking—why would we want to allow a party to send messages without authentication, especially for an authentication protocol?—but you will see shortly how this is put together. The first notion of public key cryptography is that there is not one key, but two keys. One of the keys is the private, secret key. The other key, however, is a public key. Using the public key algorithms, a message encrypted with one key can be decrypted only with the other. The two possible keys gives us two possible ways of sending messages. Encrypt with the private key, decrypt with the public, or encrypt with the public key, decrypt with the private. From this point, we can now begin to see shadows of the usefulness of public key cryptography appear. Shared key cryptography requires that both parties have the same information, and there is no cryptographic difference in their roles. Any party that can send messages can just as easily receive them. But that’s not what we want. We want to make a distinction that allows us to draw a clear line. The two keys—public and private—are derived at once by the entity that wishes to use them. The choice of which key is public and which is private is normally arbitrary, because Securing Voice 331 www.newnespress.com of the mathematics behind the procedure, but once one is chosen as public and one is private, they must each keep to their respective roles forever. The public key is widely disseminated. The private key is always kept hidden. Now, we can take the two keys and derive two different operations, based on applying the same public key encryption functions but using the opposite keys. Any entity whatsoever can take any arbitrary message and encrypt it using the public key. This message has no proof of which entity sent it. But now, once encrypted, it is private, and only the owner of the keys can decrypt the message. This is called the encryption operation, because it establishes privacy. On the other hand, the key owner can take a message and encrypt it using the private key. This message has no privacy whatsoever, because everyone has the public key, and anyone with the public key can decrypt this message and read the contents. Instead, this message has authenticity: it has now been signed. The mathematics of public key cryptography are more advanced than that of the private key cryptography we have seen so far, and drift into the world of computational algebra, a much more involved subject than the algebra people learn in high school. The most famous public key cryptography mechanism, and by far the most popular, is Rivest, Shamir, and Adleman (RSA). Named after the three authors of the work that laid out this mechanism, RSA uses the now well-known fact that the product of two very large prime numbers is computationally difficult to factor back into those prime numbers. The RSA algorithm has both keys created from three numbers, rather than two. Each key has an exponent. Furthermore, both keys share a common modulus. Let’s see quickly how this works. The key generator creates the modulus n as the multiple of two very large, random prime numbers p and q. The public exponent e is chosen to be relatively prime to the number (p – 1)(q – 1). Practically, this number is often fixed to be 65,537, and the selector of p and q ensures that this works. The public key, then, is simply the number e and the more random number pq. The private exponent d is derived, by ensuring that de is equal to 1 modulo (p – 1) (q – 1). The operation for encryption is taking an appropriately padded message m and raising it to the power of the public exponent e (mod n). The decryption step is longer, and raises the encrypted message c to the power of the private exponent d (mod n). In the end, the original message is recovered. The opposite actions of signing and verification work the same way, but by swapping the keys. The other algorithm that is used is the Digital Signature Algorithm (DSA), created by the United State government. This was popular for a while, as RSA was under patent. However, the RSA patent has expired a while ago, and DSA is not as common as it once was. 332 Chapter 8 www.newnespress.com 8.2.3.2 Certificates The usefulness of public-key cryptography has been baked into the concept of the certificate. The certificate contains the public key of the party it represents. Thus, the owner of the certificate has the matching private key, which he keeps safe. Certificates are used in web security, so most major website operators are in possession of one. Certificates are stored in the X.509 format, an ITU standard (just as G.711 is) that defines what is stored in a certificate. The following is the textual representation of a publicly available certificate used by Google for their website (the symbol ⇒ is used to show where one line wrapped to another): Certificate: Data: Version: 3 (0x2) Serial Number: 3c:8d:3a:64:ee:18:dd:1b:73:0b:a1:92:ee:f8:98:1b Signature Algorithm: sha1WithRSAEncryption Issuer: C=ZA, O=Thawte Consulting (Pty) Ltd., CN=Thawte SGC CA Validity Not Before: May 2 17:02:55 2008 GMT Not After : May 2 17:02:55 2009 GMT Subject: C=US, ST=California, L=Mountain View, O=Google Inc, ⇒ CN=www.google.com Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (1024 bit) Modulus (1024 bit): 00:9b:19:ed:5d:a5:56:af:49:66:db:79:fd:c2:1c: 78:4e:4f:11:a5:8a:ac:e2:94:ee:e3:e2:4b:c0:03: 25:a7:99:cc:65:e1:ec:94:ae:ae:f0:a7:99:bc:10: d7:ed:87:30:47:cd:50:f9:af:d3:d3:f4:0b:8d:47: 8a:2e:e2:ce:53:9b:91:99:7f:1e:5c:f9:1b:d6:e9: 93:67:e3:4a:f8:cf:c4:8c:0c:68:d1:97:54:47:0e: 0a:24:30:a7:82:94:ae:de:ae:3f:bf:ba:14:c6:f8: b2:90:8e:36:ad:e1:d0:be:16:9a:b3:5e:72:38:49: da:74:a1:3f:ff:d2:87:81:ed Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Extended Key Usage: TLS Web Server Authentication, TLS Web Client Netscape Server Gated Crypto X509v3 CRL Distribution Points: URI:http://crl.thawte.com/ThawteSGCCA.crl Authority Information Access: OCSP - URI:http://ocsp.thawte.com Securing Voice 333 www.newnespress.com CA Issuers - URI:http://www.thawte.com/repository/ Thawte_⇒SGC_CA.crt X509v3 Basic Constraints: critical CA:FALSE Signature Algorithm: sha1WithRSAEncryption 31:0a:6c:a2:9e:e9:54:19:16:68:99:91:d6:43:cb:6b:b4:cc: 6c:cc:b0:fb:f1:ee:81:bf:00:2b:6f:50:12:c6:af:02:2a:36: c1:28:de:c5:4c:56:20:6d:f5:3d:42:b9:18:81:20:b2:dd:57: 5d:eb:be:32:84:50:45:51:6e:cd:e4:2e:2a:38:88:9f:52:ed: 28:ff:fc:8d:57:b5:ad:64:ae:4d:0e:0e:d9:3d:ac:b8:fe:66: 4c:15:8f:44:52:fa:7c:3c:04:ed:7f:37:61:04:fe:d5:e9:b9: b0:9e:fe:a5:11:69:c9:63:d6:46:81:6f:00:d8:72:2f:82:37: 44:c1 Let us take this line by line and extract the relevant information. The first important line is the version, which states that this is an X.509v3, or version 3, certificate. The next line is the serial number for this certificate, and is unique for the authority who signed the certificate. Following that is the signature algorithm that is used by the signing authority. Specifically, the signature algorithm here is the SHA-1 hash over the entire certificate, which is a 128-bit number which is then signed using RSA. The issuer of the certificate is “Thawte Consulting,” one of the main certificate authorities and a part of Verisign. The next two lines state when the certificate is good. It is not good past a certain time, to allow for the signing authority to make sure the possessor of the private key is still represented by the certificate. The subject line is the name of the organization who owns the certificate. This one is Google’s. The CN field at the end is matched directly with the web address to verify that the name of the machine matches. The meat of the certificate is in the public key. The algorithm, as it mentions, is RSA. The key itself is given in two parts. The first part is the 1024-bit modulus, which was mentioned in the previous section. Not surprisingly, the public exponent is 65,537. The X.509 v3 extensions provide what rights the certificate owner has with the certificate. This one is marked for use for web servers and clients. More information appears about the signing authority, including the location where certificates that have been revoked can be found. Finally, the signature appears. When the other party to the transaction—in this case, a web browser—looks up Google’s services, the server sends this certificate. The client will then look up the certificate of the authority from a locally stored, always-trusted set of signing authority certificates. Thawte’s 334 Chapter 8 www.newnespress.com certificate is on every computer, so the client will take the public key from it and use it to undo the encryption on the SHA-1 signature in Google’s certificate, then to compare the SHA-1 hash it calculates with the one in the certificate. If they match, then the certificate checks out and the server is authenticated. Certificates can be signed in chains. The top-level authority can sign certificates, for a fee, of a next-level authority, who can sign more certificates, and so on. This allows for a longer hierarchy, which is useful in enterprises, in which an enterprise will get a signing certificate for itself, validated with one of the well-known root authorities, and then sign the client certificates that way. The reverse process is used for client authentication. The server will validate the client’s certificate. Of course, there is a bit more going on behind the scenes. 8.2.3.3 TLS and SSL Certificate exchanges are useful for validating that the certificate is valid, but it does not say anything about the holder of the certificate. For that, a protocol is needed. The Transport Layer Security protocol (RFC 5246) is designed to both validate that everyone who has a certificate should have it, and to establish a session key that can be used for encrypting later traffic. TLS is the replacement for SSL, the Secure Socket Layer that is used for HTTPS. As a protocol, TLS has a simple structure. First, the client connects to the server. The server provides its identity with a certificate, as well as a nonce. The client then responds with its certificate—an optional step for some applications, such as HTTPS—and its own nonce. The client also picks a special key, called the premaster secret, which is used for any subsequent steps. This is a random number that is encrypted with the server’s public key and sent, encrypted, to the server, which decrypts and installs it. From that point, the server and the client have a secure channel with which to finish the operation. For TLS, this operation is rather straightforward, and the server and the client can derive their master session keys. 8.2.3.3.1 EAP-TLS TLS can be embedded directly into EAP to allow RADIUS servers to authenticate clients using it. TLS itself uses its record protocol to provide basic messages as a part of the exchange. This is shown in Table 8.8. Securing Voice 335 www.newnespress.com This concept of one or more record protocols layers very nicely onto the EAP message. One or more of the client TLS records are sent in one or more EAP Request-TLS messages, and the server’s records come in EAP Response-TLS messages. This communication is layered on top of the protocols from the client to the NAS, and from the NAS, using RADIUS, to the RADIUS server. The only last detail is the EAP type for TLS, which is 13. The example exchange for security in Chapter 5, on Wi-Fi, shows a PEAP-based TLS session, and gives a good idea on how the exchange works when the client does not have a certificate. Table 8.8: TLS record format Type Version Length Payload 1 byte 2 bytes 2 bytes variable Table 8.9: TLS record types Type Subtype Name Meaning 20 — Change Cipher Spec Used to switch all further TLS communication to encryption using the premaster key. 21 — Alert Sends a warning or error that can abort the TLS operation, if one of the parties does not have the right credentials. 22 Handshake Used for back-and-forth requests 0 Hello Request Sent by the server to start the protocol, if the client hasn’t already sent a Client Hello. 1 Client Hello Starts the process with a nonce, and provides what cipher suites the client supports. 2 Server Hello Responds to the Client Hello with a nonce, the selected cipher suite, and a session ID for resuming TLS later. 11 Certificate Provides a certificate or chain of certificates 12 Server Key Exchange Used for Diffie-Hellman key exchanges. 13 Certificate Request Sent to request a certificate from the client. 14 Server Hello Done Marks the end of the Server Hello group of records. 15 Certificate Verify Sent by the client to prove that it has the private key to the certificate it offered. 16 Client Key Exchange Sends the premaster secret, encrypted to the server using the server’s public key 20 Finished The TLS session is finished. 23 — Application Data For extensibility; used in derivatives such as TTLS and PEAP. The Version field is given as 0x0301, which means TLS version 1, but looks like SSL version 3. This allows for SSLv3 peers to work with TLS. The types fall into the categories listed in Table 8.9. 336 Chapter 8 www.newnespress.com 8.2.4 Secure Password-Based Authentication Password authentication can be dicey, because sending passwords or anything predictably derived from them over the network will expose the user to having his or her credentials stolen. Passwords need to be sent in an already-encrypted channel. HTTPS web servers already do this right, by setting up a TLS connection without a client certificate, and then using traditional web pages to request the passwords. The password is just sent over the encrypted HTTP session, so no one can eavesdrop. For more automated applications, something else is needed. The most popular way to do password authentication across the entire network without the risks of exposure is to do Protected EAP (PEAP). PEAP works by setting up a TLS connection, normally without client certificates. Once the TLS session gets to the point where both sides have agreed to a premaster key, then instead of TLS finishing up and establishing a session key, the client and RADIUS server drop into using the encrypted Application Data protocol of TLS to embed a second, inner EAP session. This nesting of an encrypted EAP session over an unencrypted TLS session allows PEAP to protect any of the EAP methods that needlessly expose information. As it turns out, PEAP version 0, the most common PEAP version, happens to use a particular form of a challenge-and-response password protocol called MSCHAPv2. This protocol was designed for integration directly with Microsoft Active Directory systems, and it uses the typical Windows NT password hashing mechanisms to verify the username and password. PEAP itself is flexible enough to conceivably have any EAP protocol run over it, but implementations are strictly limited. PEAP uses a different EAP type than TLS: 25. A far less common alternative to PEAP is EAP-TTLS, for tunneled TLS. TTLS is conceptually very close to PEAP, and was actually created a bit earlier than PEAP. It uses a few more fields between the inner and outer tunnel, and the details are not significant enough to go into here. 8.2.5 Cardkey Authentication In cardkey authentication, each user carries on his or her person a small device. This device, which is anywhere from the size of a miniature pocket calculator to a small USB flash, carries a cryptographic random number generator and a clock that has been synchronized to a central authentication server. When the user wants to log in, the server asks the user to pull out the cardkey and read the number on the display. This number, which changes every minute or less, will serve, along with the user’s name and password, that the user is at least in physical possession of the device. As these devices are very difficult to copy—they Securing Voice 337 www.newnespress.com self-destruct electronically—this provides a higher grade of authentication than just a password alone. These systems have the requirement, however, that some authentication server be able to engage the user in a two-way interactive session, with text messages and so on. To prevent those messages from being shown in the clear—especially because an attacker who might have electronic access the username, password, and cardkey display could open up all of the network if it acted quickly enough—these exchanges should be tunneled as well. PEAPv1 is an extension to PEAP that uses an inner EAP method called EAP-GTC, for Generic Token Card. EAP-GTC is an arbitrary text-based protocol, riding over EAP, to perform challenges and responses with the user. EAP-GTC is defined in the same RFC that defines EAP itself, and is EAP type number 6. Cardkey authentication can also be done using proprietary protocols, and are often integrated into virtual private network (VPN) access clients for large networks. 8.2.6 SIM and AKA: Cellular Authentication over IP SIM authentication uses the GSM SIM card to authenticate the user. This can have an immediate application to voice mobility. EAP-SIM is defined in RFC 4186, and uses multiple invocations of the GSM SIM authentication mechanism to verify that the client is what is claims to be. The Authentication and Key Agreement (AKA) protocol is used in UMTS networks to provide the mutual authentication between the phone and the network. EAP-AKA is defined in RFC 4187, and layers the request for AKA negotiation on top of EAP. Both of these mechanisms would allow for out-of-the-box authentication of mobile devices. Unfortunately, they do require that the RADIUS server have access to the identity information for the clients, something that only the mobile operator has. Therefore, private voice mobility networks will not have access to these mechanisms. 8.3 Protecting Your Network End-to-End Once the user is authenticated using a strong authentication technique, the problem becomes protecting the network. End-to-end security means that the eventual endpoints in any conversation directly authenticate each other, establish a session key, and then enforce the encryption from there. Any device in the middle will see only integrity-protected, encrypted, and authenticated traffic, and thus can only observe that some unknown activity is taking place. End-to-end protection does require that both ends, or every end, have access to enough information to authenticate the other party. Furthermore, with voice mobility, it is always 338 Chapter 8 www.newnespress.com somewhat difficult to figure out exactly who the other end is. SIP, RTP, and other protocols are often proxied by the PBXs and switches. Therefore, we will use the term “end-to-end” to refer to the application-level endpoint, in the appropriate architecture, that the traffic is being sent to. 8.3.1 Generic IP Encryption: IPsec The first approach to encryption works for any IP network. IPsec is a protocol that works for any IP packet, assuming the two endpoints are participating. IPsec (RFC 4301 and related) defines an encrypted or authenticated transport mechanism that allows individual IP frames to be protected. IPsec, by itself, does not assume how the two endpoints authenticate or derive keys. What it does is provide a format for the encryption or authentication cryptographic algorithm to be applied to the IP packet. IPsec defines two types of encryption or authentication that can be done to a packet: transport mode or tunnel mode. Transport mode is designed to protect an IP packet which is being send from an originating source to a final destination. In this case, IPsec only encrypts or authenticates the payload of the packet, of course binding the header fields to the cryptographic operation to prevent static fields from being modified in flight. Tunnel mode works on top of an IP-IP tunnel, in which one IP packet is placed inside the other. In tunnel mode, the packet to be encrypted is encrypted, in its entirety, and is then placed inside another IP packet. This allows the outer IP packet to be modified without concern to the security properties of the connection. The two flavors of IPsec cryptography—encryption and authentication—reflect that some traffic does not need to be encrypted but just signed so that the receiver can know that the packet was received without modification from the authentic source. Encryption is more important for voice mobility networks, so we will start there. The encryption protocol is called Encapsulating Security Payload (ESP), and uses IP protocol type 50. The format of the ESP header is shown in Table 8.10. Table 8.10: IPSec encapsulating security payload format SPI Sequence Number Payload (encrypted) Padding (encrypted) Pad Length (encrypted) Next Header (encrypted) ICV 4 bytes 4 bytes variable variable variable 1 byte variable The SPI, or Security Parameters Index, is an arbitrary four-byte value, used to identify the security association between the two endpoints. This allows multiple sessions of IPsec to be Securing Voice 339 www.newnespress.com set up between two devices, or even one session to be shared among multiple devices (such as for multicast). The Sequence Number defines the replay counter for the packet. This number always increments by one for each packet that is sent by the sender in the secure connection. If a receiver gets a valid packet with one sequence number followed by a valid packet with a lesser sequence number, it can drop that lesser one as being a replay. The payload is the data that is being encrypted. In transport mode, the data is the payload of the unencrypted IP packet. In tunnel mode, that unencrypted payload is another IP packet. At the start of the payload, the type of encryption negotiated beforehand may require an initialization vector (IV). This will come before the encrypted payload, and the decryption and encryption algorithms are responsible to know where to look for them. Following the payload may come any padding required by the encryption, followed by a byte specifying the number of pad bytes that were used. The Next Header field has the type of the packet that was encrypted. A special value (56) exists, which refers to a dummy packet. A dummy packet is inserted by the sender to mask the overall statistical properties of the encrypted flow, if the sender wishes to do that. This value is otherwise the value in the original packet, such as 6 for TCP. If this is a tunnel-mode packet, the value will be 4 for IP-in-IP. The receiver needs to drop all dummy packets. Finally, the integrity check value (ICV) is calculated, which covers the entire ESP header, the payload, and the trailer fields. This field, if present, provides integrity protection for the packet. Packets that just have authentication information use the Authentication Header (AH) protocol, IP protocol 51. AH provides integrity and replay protection, on top of authentication, but does not protect the contents of the frame from being spied on. Usually, authentication is a computationally faster process, which explains why some devices may want to use it. It is admittedly hard to see how AH would be useful with voice mobility. The format for AH is shown in Table 8.11. Table 8.11: IPSec authentication header format Next Header Payload Length Reserved SPI Sequence Number ICV Payload 1 byte 1 byte 2 bytes 4 bytes 4 bytes variable variable Apart from a bit of rearranging, and the elimination of any potential IV, the fields mean the same as with ESP. For both approaches, when integrity is applied to the IP header, some of the fields are allowed to change, and others are not. Specifically, the only fields that can change in the outer IP header (or only header for transport mode) are the DSCP field, the flags, the fragment offset, the TTL, and the header checksum. Replay protection is provided by employing a window algorithm, to allow for a limited amount of reordering. The size of the window is up to the negotiation between the two . same purpose as with RADIUS (though it need not be equal), and keeps track of requests and responses. The Type field is for requests and responses only. A type field of 1 is for Identity. EAP. privacy. On the other hand, the key owner can take a message and encrypt it using the private key. This message has no privacy whatsoever, because everyone has the public key, and anyone with the. very large, random prime numbers p and q. The public exponent e is chosen to be relatively prime to the number (p – 1)(q – 1). Practically, this number is often fixed to be 65,537, and the selector