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.. 0 Hello Request Sent by the server to start th
Trang 1Failure. 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
Trang 2of 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
Trang 38.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
Trang 4CA 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
Trang 5certificate 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
Trang 6This 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
Table 8.9: TLS record types
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.
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
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
Trang 78.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
Trang 8self-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
Trang 9somewhat 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
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
Trang 10set 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
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