Protocol Authentication Extensions

In a routing protocol, it is important for peers to trust one another and to ensure that the messages they exchange have not been altered in transit. False routing updates from untrusted peers or altered updates from trusted peers can wreak havoc on a network, for example, causing traffic for multiple prefixes to be routed incorrectly or even blackholed.

Even though Mobile IP limits the impact of rogue updates because each routing update is for an individual host and only affects that host, it is just as important to secure the routing control messages. In fact, because Mobile IP is an overlay routing protocol often used across multiple autonomous systems, it is more vulnerable to attack. Because the Mobile IP control messages traverse multiple routers, or those claiming to be routers, it is necessary to ensure that a control message is from who it says it is from and says what it was intended to say. If the RRQ and RRP messages are not properly secured, a roaming Mobile Node's traffic can easily be hijacked. You have probably realized that a Mobile Node at home is not subject to the same vulnerabilities as a roaming Mobile Node.

The Mobile IP protocol uses security authentication extensions to provide peer authentication and message integrity. As the name suggests, the authentication extension is an extension containing relevant security information that is appended to the end of the message. The authentication extensions are designed to allow extensive flexibility through their extension type and placement within the message. That is, different types of authentication extensions secure messages between different Mobile IP entities. Moreover, the authentication extensions secure a specific part of the Mobile IP messages, depending on where the part is placed within the message.

The critical purpose of the authentication extension is to verify the sender of the message and to ensure that the message was not altered while in transit.

The extension types are allocated to allow authentication between various pairs of peers. The following four Mobile IP extension types, allocated for authentication, currently exist:

• Mobile NodeHome Agent Authentication Extension (abbreviated as MN-HA or MHAE)

• Mobile NodeFA Authentication Extension (abbreviated as MN-FA or MFAE)

• FAHome Agent Authentication Extension (abbreviated as HA-FA or FHAE)

• Generalized Authentication Extension (abbreviated as GNAE)

The GNAE is a catchall for new types of Mobile IP authentication extensions. It allows more authentication extensions to be created without consuming more Mobile IP extension types, which are limited. The only current use of the GNAE is to define the Mobile Nodeauthentication, authorization, and accounting (AAA) Server Authentication Extension (MN-AAA).

Authentication extensions allow flexibility in authenticating various parts of the registration message with various peers. Thus, as information is added to the registration control messages, it can be protected without altering the protection to pre-existing portions of the control message. For example, a Mobile Node can secure its RRQ with an MHAE and forward the request to its FA. The MHAE protects the information preceding it, namely, the base RRQ. In turn, the FA might want to append an extension to the RRQ and secure the extension with an FHAE. The two extensions secure different subsets of the message and are between different Mobile IP entity pairs. That is, the base RRQ is secured between the Mobile Node and Home Agent, and the entire message, including the appended extension, is secured between the FA and Home Agent. Figure 3-1 shows a Mobile IP RRQ and mandatory MHAE that is appended by an extension by the FA and then secured with the FHAE.

Figure 3-1. Authentication Extension Placement and Protection

Security Associations

The next natural question then is "What relevant security information do authentication extensions contain, and how do these extensions secure messages?"

For Mobile IP entities to use an authentication extension between them, they must first share a security relationship. This relationship is in the form of a set of predefined parameters configured into each node, which are collectively known as a security context. A security context is comprised of the following components:

• Algorithm and mode to be used in crypto computations

• Shared key between the peers

• Replay protection method

(We look at each of these components in more detail in subsequent sections.)

Theoretically, each node can have more than 4 billion individual security contexts per peer. A group of one or more security contexts that are shared with an individual peer is referred to as a security association. It is also common for the term security association to be used interchangeably with the term security context. This is likely because security associations are often made up of only one security context.

NOTE

The ability to support multiple security contexts gives Mobile IP operators enormous flexibility and control over security association management. Multiple contexts can be used between each node to minimize the impact of brute-force attacks by rotating through the keys with each registration. You can also change keys without requiring both nodes to be updated at the same time. For example, an administrator could add the new security context to the Home Agent. Then, when the Mobile Node is available for update, the new context can be added and the old one removed. Finally, the old context can be removed from the Home Agent.

After the shared association is in place, the entities can now send messages securely.

The sender computes a cryptographic keyed hash of the message using an algorithm and shared key, places this value in the authentication field of the authentication extension, and sends the message. The algorithm and keys that protect a message are implied by the sender within the authentication extension, which is part of the protected portion of the message. To verify the integrity of a message, the recipient computes its own cryptographic keyed hash of the same portion of the message (the message not including the authenticator value) using the same algorithm and shared key. It then compares the computed hash to the authenticator value in the appropriate authentication extension, as shown in Figure 3-2. If the two match, the message is considered to be authenticated.

Figure 3-2. Authentication in Mobile IP Using Extensions

SPI

A specific security context is identified in the authentication extension by the security parameter index (SPI) value. The SPI is a 4-byte value that is configured as either a hexadecimal or decimal value. (Unfortunately, this can often lead to confusion because the peer devices can require the SPI value to be specified in different formats.) If a security violation is received on a RRQ, the SPI value is the first item that should be verified, because it identifies the security context to use in authenticating the message.

Of the over four billion values, the values 0 through 255 are reserved for specific contexts defined in IETF standards. The only reserved SPI values currently allocated are the Challenge Handshake Authentication Protocol (CHAP) and CHAP Hash-based Message Authentication Code (HMAC), 2 and 3 respectively, which are used in the MN-AAA Authentication Extension. This is discussed in the section "MN-AAA Authentication," later in this chapter.

NOTE

It is common to use SPI value 100 hex or 256 decimal when configuring the first security context because it is the first nonreserved value.

Algorithm and Mode

The authenticator value in the authentication extension is a message authentication code (MAC), which can be thought of as a fingerprint. For each registration message, a hash algorithm calculates the unique fingerprint value, which is of smaller total length than the original message. Thus, given that more possible values exist for the original message than do unique fingerprint results, the algorithms are designed so that the result is as unique as possible. The ideal algorithm results in 50 percent of the bits in the hash changing by changing just 1 bit in the message.

It is difficult to derive a message that would produce the same result. For example, if the message is the classic sentence "The quick brown fox jumped over the lazy dog," an algorithm whose result identified the message as "containing 36 letters, 3 of which are es" would be less than ideal. Many sentences would produce the same result, and it is easy to create one. It would be more secure to say that it "contains 36 letters and at least 1 of each letter in the alphabet." Coming up with a sentence to match this identification would be much more difficult!

The Mobile IP standard originally defined MD5, as described in Request For Comment (RFC) 1321, as the required algorithm for the Mobile Node-Home Agent and FA-Home Agent authentication extensions. However, this was later determined to be vulnerable to attack. MD5, as defined in RFC 1321, is often described as prefix-suffix mode. The standard was later amended to define HMAC, as described in RFC 2104, as the required algorithm and mode instead of prefix-suffix MD5. HMAC is a method of computing a hash of the message and is cryptographically stronger.

The MN-AAA Authentication Extension uses CHAP and CHAP-HMAC for computing the authenticator, as described in the section "MN-AAA Authentication," later in this chapter. The standard also allows implementers to use other methods such as Secure Hash Algorithm (SHA) or RIPEMD-160 in their implementations, but this is not common.

Key

The authenticator is computed using a key that is shared between the two peers. The node that initiates the message uses the key to compute the value in the authentication extension. The node that receives the message uses the same key value and computes the authenticator over the registration message and compares the result to the value in the authentication extension. If the two values match, the authentication is accepted. The default key is 128 bits long and is usually represented by 32 hex characters. RFC 3344, "IP Mobility Support for IPv4," states the following:

The default algorithm is HMAC-MD5 [23], with a key size of 128 bits. The FA MUST also support authentication using HMAC-MD5 and key sizes of 128 bits or greater, with manual key distribution. Keys with arbitrary binary values MUST be supported.

…More authentication algorithms, algorithm modes, key distribution methods, and key sizes MAY also be supported for all of these extensions.

This leaves the implementation open for software developers and has lead to many different keying options. Specifically, key length varies widely, some vendors support keys of only 128 bits, and others support longer or shorter keys. This problem becomes even worse when vendors attempt to use plain-text keys and convert them. Some vendors take text of any length and convert it straight to hex; others add 0s to the key to ensure that it is 128 bits long. This results in some interoperability problems among different vendors' components. Fortunately, almost every vendor supports a 128-bit key configured in hex so that interoperability is still possible.

Selection of the key is important. Keys should be unique to each user and should be random. Good random keys can usually be used because a user does not need to remember them. These keys are typically typed in once and stored.

Replay Protection Methods

Authentication in the Mobile IP control messages can be strong if proper keys are selected, but because no data is guaranteed to be unique in each registration message, these messages are vulnerable to replay attacks. That is, a malicious third party could capture the registration message used in a given location and then resend that message after the Mobile Node has left, disrupting the data flow and redirecting traffic to the attacker. To avoid this kind of attack, Mobile IP offers the following two replay protection methods:

• Timestamp Timestamp support is required in all Mobility Agent and nodes

• Nonces Optional

By using timestamps or nonces, a unique value is placed in a field of the registration message. The receiver can then verify that it is a unique message and ignore the message if it is not unique, suspecting it to be a replay. Whichever method is used, the unique identifier that makes every message different is contained in the 64-bit identification field of the registration message.

Timestamp Replay Protection

Timestamp replay protection relies on the availability of a real-time timestamp placed in each registration message and the algorithm, as shown in Figure 3-3. The timestamp is sent in the identification field and is encoded in the manner specified by the Network Time Protocol (NTP).

Figure 3-3. Mobile IP Timestamp Replay Protection Algorithm

The NTP timestamp format is a 64-bit unsigned fixed-point number. The first (higher) 32 bits, known as the integer portion, represent the number of seconds since 12:00 a.m. on January 1, 1900. The remaining (lower) 32 bits, or fractional portion, represent the fraction seconds. Unlike NTP, when insufficient clock granularity is available, the data should be padded with quality random data rather than 0s. When generating random data, the timestamp must be greater than any previously used timestamp, or the message will be discarded as being out of sequence.

When a message is received, the timestamp is verified to ensure that the time in the identification field is within a configured interval of its current time. This interval is typically 7 seconds and should not be less than 3 seconds. If the Home Agent finds that the difference between the timestamp and the current time is greater than the allowed interval, it rejects the registration with an error code of 133, registration id mismatch. The Home Agent also updates the higher 32 bits with the current timestamp in the RRP. Upon receipt of the RRP, the Mobile Node matches the sent RRQ message to the received reply by comparing the lower 32 bits and then updating its time by computing an offset. The offset is the difference between the Mobile Node's time and the Home Agent's time, plus the estimated latency of the link. The latency is estimated by halving the time difference from when the RRQ was sent and when the reply was received. The Mobile Node then attempts to reregister with this updated timestamp.

Nonces Replay Protection

Nonces are a concept where the identification field is split into two 32-bit values; the low-order values are allocated by the Mobile Node and the high-order values are allocated by the Home Agent. For every RRQ, the Mobile Node generates a new lower-order value. The Home Agent copies that value into the lower-order portion of the identification field in the reply and generates a new random value for the high-order portion. The values generated by the Home Agent are then saved and used as the high-order portion of the identification field in the next RRQ sent by the Mobile Node. Because the Home Agent always knows what the next high-order portion of the identification field is supposed to be and the Mobile Node changes the lower-order portion, it can easily determine whether a message is being replayed.

Mobile Node and Foreign Agent Authentication and Challenge Mechanism

The Mobile Node-FA Authentication Extension is intended to provide authenticated communication between the Mobile Node and FA. However, it suffers from several deployment problems that have kept it from widespread adoption. Use of the original Mobile Node-FA Authentication Extension would require every Mobile Node to have a key for every FA it visited, and every FA to have a key for every potential Mobile Node. Clearly, key management and distribution on such a scale is simply not practical. Moreover, the MFAE also does not provide replay protection because the timestamp and nonces methods are between the Home Agent and Mobile Node only. (Refer to the section "Replay Protection Methods," earlier in this chapter.)

In most deployment cases, this was not an issue because Mobile Node-FA authentication was not needed. However, when Mobile IP was adopted as part of the CDMA 2000 standard, authentication at the FA was deemed necessary precisely for replay concerns, but it could not be easily achieved using the Mobile Node-FA Authentication Extension. Again, one of the major problems was key distribution. Not only was it not part of the standard, but with intercarrier roaming, it was also not desirable to send actual key values to roaming partners.

A more practical and easily achievable security mechanism was needed. It was cleverly realized that the solution might already be in the air, so to speak! AAA servers based on the Remote Authentication Dial-In User Service (RADIUS) protocol (which is described in Chapter 5, "Campus Mobility: Client-Based Mobile IP") were already widely deployed and had a proven method for authenticating roaming users in a dial-up environment. This existing capability, along with the existing replay protection used in dial-up, was then leveraged to provide secure authentication at the FA, namely, authentication through a AAA server and the CHAP for replay protection. The Mobile IP Working Group formalized the technique in RFC 3012 and introduced the following new extensions to Mobile IP to support the technique:

• FA Challenge Extension for agent advertisements

• Generalized Authentication Extension with MN-AAA authentication subtype

• Mobile Node-FA Challenge Extension for RRQs

NOTE

The Generalized Authentication Extension with subtype 1 (MN-AAA authentication) is simply referred to as the MN-AAA Authentication Extension.

FA Challenge

Point-to-Point Protocol (PPP)-based dial-up uses an authentication mechanism referred to as the CHAP. CHAP integrates authentication and replay protection into a single protocol. The authenticating device, in this case the FA, issues a challenge, which is a random number that is valid for a specified amount of time, and then expires.

The FA often offers multiple challenge values that are valid for a specified amount of time, known as the challenge window, as shown in Figure 3-4. By issuing a challenge, the FA is basically saying, "For a RRQ to be valid, you must include a challenge value from within my challenge window. And by the way, you can only use a particular challenge value once." The challenge is sent in an extension to the agent advertisement called the Mobile IP Agent Advertisement Challenge Extension and, when copied into the RRQ, allows the FA to ensure that the request is not a replay.

Figure 3-4. Challenge Window

A challenge can also be sent in a RRP so that the Mobile Node does not have to wait to learn of new challenges in agent advertisements. For example, if a RRQ is denied by the FA because of a bad challenge, the FA can inform the Mobile Node of a new challenge in the RRP. Because agent advertisements and registration replies are confined to the link on which they are sent, only Mobile Nodes on that link would learn the challenge values.

A Mobile Node copies a valid challenge value into an extensionthe Mobile Node-FA Challenge Extensionand appends the extension to the RRQ it sends to the FA. This extension must be secured by either an MFAE, if one exists, or the Mobile Node-AAA extension described in the next section. Ah, the raised eyebrows! Yes, the notion that the MFAE exists seems to contradict the need for this mechanism, but keep in mind that while the MFAE provides authentication, it doesn't provide replay protection.

Upon receiving the challenge in the RRQ, the FA first checks whether the challenge is indeed valid before authenticating the message. This is simply because validating the challenge is an easier and faster process than authenticating the Mobile Node. This is a process similar to the nonces' process described in the section "Nonces Replay Protection," earlier in this chapter. If the FA determines that the challenge is not valid, it rejects the RRQ and sends a RRP with one of the following newly defined error codes:

• 104 Challenge Value is unknown.

• 105 Challenge Value is missing in the RRQ.

• 106 Challenge Value has expired or has already been used.

At this point, the Mobile Node must reregister with a valid challenge value. Note that RFC 3012 does not mandate that a FA must reject the RRQ if a challenge is invalid. However, accepting invalid challenge values is as good as not having the mechanism to begin with. Figure 3-5 illustrates the FA Challenge (FA Challenge) mechanism.

Figure 3-5. Mobile IP FA Challenge Flow

MN-AAA Authentication

The MN-AAA Authentication Extension is similar to other authentication extensions, but is intended to be processed by a AAA server, which is discussed in more depth in Chapter 5. Recall that the MN-AAA Authentication Extension is the Generalized Authentication Extension with Subtype 1, as defined in RFC 3012.

NOTE

When using the AAA model for authentication, a AAA server typically exists for the home domain, and a AAA server for the foreign domain. Sometimes, they can in fact be the same physical server; however, the functionality is distinct.

The MN-AAA extension can only be generated by the Mobile Node, because the Mobile Node and its home AAA server are the only entities with the proper credentials. The Mobile Node appends the MN-AAA Authentication Extension to a RRQ. Although this might be stating the obvious, the MN-AAA Authentication Extension can authenticate RRQs, but it cannot be used in the RRP because the reply is generated by a FA or Home Agent.

The most common use of the MN-AAA Authentication Extension is with a specialized SPI called the CHAP_SPI, an SPI value of 2, which is designed to mimic a PPP CHAP authentication request to a RADIUS server. This allows off-the-shelf RADIUS servers to be used rather than requiring a custom AAA infrastructure. RFC 3012, "Mobile IPv4 Challenge/Response Extensions," has also been amended to support CHAP-HMAC to eliminate the same MD5 vulnerability, as discussed in the section "Algorithm and Mode," earlier in this chapter.

With the MN-AAA Authentication Extension and the FA Challenge, FAs can now authenticate RRQs without needing the pre-existing security key. When the FA receives a RRQ with the MN-AAA extension, it computes a hash on the message and sends a portion of this hash, along with the authenticator value sent in the MN-AAA, to its AAA server, which likely consults the Mobile Node's home network AAA server. A trust relationship is assumed to exist between the two AAA servers. The appropriate AAA server completes the hash computation using the stored password for the Mobile Node and compares the hash that it computed with the authenticator value that was sent. If they match, an authentication accept message is returned to the FA. In this way, the FA can authenticate the Mobile Node. Figure 3-6 shows the same call flow for an FA Challenge as in Figure 3-5, but with the Mobile Node using the MN-AAA Authentication Extension.

Figure 3-6. Mobile IP FA Challenge Flow Using the MN-AAA Authentication Extension

Unlike the other authentication extensions, the MN-AAA is designed to accommodate a textual password. This password is typically used for dial-up authentication as well. The use of a single authentication infrastructure allows a simplified deployment and management. Note that the MN-AAA is not a replacement for the Mobile Node-Home Agent Authentication Extension.