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: /> Authority Information Access:
OCSP - URI:
Securing Voice 333

www.newnespress.com
CA Issuers - URI: />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