RFC 3957

Authentication, Authorization, and Accounting (AAA) Registration Keys for Mobile IPv4

📅 published March 2005, from ietf

RFC 3957: Authentication, Authorization, and Accounting (AAA) Registration Keys for Mobile IPv4 🦋

Part 1 of 6 ✨

Okay bestie, so this spec came out in March 2005 and it's on the Standards Track, which means it's a real protocol spec people build against 💅. It came from the Network Working Group and was written by C. Perkins (Nokia Research Center) and P. Calhoun (Airespace). The title block doesn't list any RFCs it obsoletes or updates, so it's standing on its own 💜.

Status of This Memo 📋

This document specifies an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 🙏. For the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited, so share away 🌈.

Copyright (C) The Internet Society (2005).

Abstract 🧚

AAA servers like RADIUS and DIAMETER already handle authentication and authorization for dial-up computers on the Internet today. Mobile IP for IPv4 needs strong authentication between the mobile node and its home agent 🔐. Here's the cute part: if the mobile node already shares an AAA Security Association with its home AAA server, it can use that to derive new Mobility Security Associations. One goes between the mobile node and its home agent, and another goes between the mobile node and the foreign agent that's currently giving it connectivity 🦋. This document defines extensions to Mobile IP registration messages that create Mobility Security Associations between the mobile node and its home agent, and/or between the mobile node and a foreign agent. It's giving efficiency and I'm obsessed 😭.

Table of Contents 📚

1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
2.  Terminology. . . . . . . . . . . . . . . . . . . . . . . . . .  4
3.  Overview of Operations with Key Generation Nonce Extensions. .  5
4.  Mobility Security Associations . . . . . . . . . . . . . . . .  7
5.  Key Generation Nonce Creation and Key Derivation . . . . . . .  8
6.  Key Generation Extensions. . . . . . . . . . . . . . . . . . .  9
    6.1.  Generalized MN-FA Key Generation Nonce Request Extension 10
    6.2.  Generalized MN-FA Key Generation Nonce Reply Extension . 11
    6.3.  Generalized MN-HA Key Generation Nonce Request Extension 13
    6.4.  Generalized MN-HA Key Generation Nonce Reply Extension . 14
7.  Error Values . . . . . . . . . . . . . . . . . . . . . . . . . 16
8.  IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 16
9.  Security Considerations. . . . . . . . . . . . . . . . . . . . 17
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
    11.1. Normative References . . . . . . . . . . . . . . . . . . 18
    11.2. Informative References . . . . . . . . . . . . . . . . . 19
Appendices . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
    A. AAA Infrastructure. . . . . . . . . . . . . . . . . . . . . 20
    B. Message Flow for Requesting and Receiving Registration Keys 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 27

1. Introduction 🌸

AAA servers like RADIUS [11] and DIAMETER [12] are already in use across the Internet for authentication and authorization for dial-up computers 💻. That kind of service is likely to be super valuable for mobile nodes running Mobile IP for IPv4 [1], especially when they try to connect to foreign domains that have AAA servers 🌍. In this document, Mobile IP for IPv4 is shortened to "Mobile IPv4" or just "Mobile IP", since no one is expected to get confused with other versions 🙃.

The requirements for how AAA and Mobile IP talk to each other are laid out in RFC 2977 [13]. That document describes an infrastructure that lets AAA servers authenticate and authorize network access requests from mobile nodes 🔑. See also appendix A. A Mobile IP Registration Request counts as a request for network access. That means you can beef up the Mobile IP mobility agents so they translate between Mobile IP registration messages and the messages used inside the AAA infrastructure, as described in RFC 2977 ✨. Mobility agents and AAA servers that follow the RFC 2977 requirements can be treated as appropriate network entities to support the message types in this document. Check RFC 2977 [13] for the full details 📖.

This spec uses one AAA Security Association to make derivative Mobility Security Associations. A Mobility Security Association here is a simplex connection that authenticates MIPv4 control traffic between a MN and HA, and/or between a MN and FA 🦋. Each one is identified by its two endpoints, like a MN IP address and a HA IP address, plus an SPI. Two nodes can have one or more Mobility Security Associations between them, but there's usually no reason to have more than one 🙈.

This document defines extensions to Mobile IP registration messages that create Mobility Security Associations between the MN and FA and/or the MN and HA. These are built from the AAA Security Association between the MN and the AAA server 🫶. The new Mobility Security Associations can then be used to calculate the Authentication Data needed by the authentication extensions in Mobile IP control messages 🔥.

We're assuming the security association between the mobile node and its AAA server has been set up properly, so the AAA server can hand over key material. That key material becomes the basis for the Mobility Security Association(s) needed between the mobile node and its potential mobility agents 🎀.

AAA servers usually use the Network Access Identifier (NAI) [2] to uniquely identify the mobile node. The mobile node's home address isn't always needed for that job 🧚. So a mobile node can authenticate itself and get authorized to connect to the foreign domain without having any home address at all 👑. But for Mobile IP to work, the mobile node is required to have a home address and a Mobility Security Association [1] with its home agent 💅. When the Mobile IP Registration Reply packet is authenticated by the MN-AAA Authentication Extension [3], the mobile node can verify that the key material in the extensions was produced by the AAA server. That means it can be reliably used to create Mobility Security Associations with the home agent and/or the foreign agent 💖.

We're also assuming that the AAA entities involved (the AAAH, the AAAL, and the AAA interface features of the foreign agents and home agents) each have a way of exchanging keys that's outside the scope of this document 🤝. The extensions here are meant to work with any AAA protocol suite that allows that kind of key exchange, as long as it meets the requirements in RFC 2977 [13]. One such AAA protocol is defined within the Diameter framework [14] 🌈.

2. Terminology 📝

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [4] 🎀.

AAA: Authentication, Authorization, and Accounting (see [10]) 💜.

AAA entity: A network node that processes AAA messages according to the requirements for AAA protocols (see [10]) 🖥️.

AAA Security Association: A security association between an AAA entity and another node that needs that AAA entity's services. In this document, every AAA Security Association is between a mobile node and its home AAA server (AAAH). A mobile node's AAA Security Association with its AAAH can be based on either the mobile node's IP address or its NAI [2]. The key is called "AAA-key" in this specification 🔑.

Key: A number that's kept secret. Only nodes holding the key have any hope of using the security transform to get correct results 🤫.

Key Generation Nonce: Nonce data used to create a key 🎲.

Mobility Security Association: A simplex connection that applies security services to RFC 3344 MIPv4 control traffic between a MN and HA (or between a MN and FA), using RFC 3344 Authentication Extensions. A Mobility Security Association is uniquely identified by its peer source and destination IP addresses and an SPI. Two nodes can have one or more Mobility Security Associations, but there's typically no reason to have more than one between two nodes, except as a temporary state during re-keying events 🔄.

Registration Key: A key used in the MN-FA or MN-HA Mobility Security Association. A registration key is typically only used once or a very few times, and only to verify a small amount of Authentication data 🧾.

Security Algorithm: A set of rules for taking input data and a secret key and producing data for use in security protocols 🧮.

SPI: Security Parameters Index. The SPI is an arbitrary 32-bit value that helps identify an AAA, IP, or Mobility Security Association 🆔.

Other terminology is used as defined in the base Mobile IP specification [1]. To keep the discussion simpler, we often use the word "Extension" instead of "Subtype of the Generalized Extension" 🦋. For example, instead of saying "The MN-FA Key Generation Nonce From AAA Subtype of the Generalized MN-FA Key Generation Nonce Reply Extension", we just say The MN-FA Key Generation Nonce From AAA Extension 💅.

Part 2 is next, and it's where the Overview of Operations gets good 🧚✨

3. Overview of Operations with Key Generation Nonce Extensions ✨

Okay bestie, picture a mobile node that's relying on AAA infrastructure to get permission for network connectivity and Mobile IP registration 💅. It might have zero pre-existing Mobility Security Associations with its home agent, or with the foreign agent running the show on the visited network 🙈. That's where the extensions in this doc come in. They let an AAA entity hand key material to mobile nodes, and that material becomes the basis of their Mobility Security Association with mobile agents 🔑. The AAA entity doing this is part of the AAA infrastructure and is typically found within the foreign domain by methods outside this spec (see appendix A 🫶).

The key material can be requested by the mobile node through new extensions (defined below) in Mobile IP Registration Request messages, and then delivered in extensions to the Mobile IP Registration Reply messages 💖. Or, plot twist, the AAA server MAY provide unsolicited key material through mobility agents to mobile nodes 👀. In that case the mobile node MUST calculate new keys and update or create its relevant Mobility Security Association 🔥. How the key material gets to the mobility agents themselves is out of scope here. It depends on the security architecture of the AAA servers in the foreign and home domains (see RFC 2977 and appendix A) 🧚. For this document we're just assuming there's a suitable AAA infrastructure available to the home and foreign agents, and that the mobile node has an AAA Security Association with at least one AAA server in its home domain 🌸.

When a mobile node travels away from home, it may not have a Mobility Security Association with its home agent, perhaps because it doesn't have a home address yet [5] 🧳. The protocol and messages in this document are meant to make these operations happen between the mobile node, foreign agent, home agent, and AAA servers in both the visited (local) domain (Authentication, Authorization and Accounting Local or AAAL) and the home domain (Authentication, Authorization, and Accounting Home or AAAH) 🌍. In the message sequence below, the only flows this document actually specifies are the Registration Request (mobile node to foreign agent) and the Registration Reply (foreign agent to mobile node). Everything else comes from the AAA entities doing their thing as described in RFC 2977. See also appendix B 💜.

  1. If the mobile node doesn't have a Mobility Security Association with the foreign agent, it SHOULD include an MN-FA Key Generation Nonce Request extension (see Section 6.1) as part of its Registration Request that it sends to the Foreign Agent.
  2. If the mobile node doesn't have a Mobility Security Association with the home agent, it MUST add an MN-HA Key Generation Nonce Request extension (see Section 6.3) as part of its Registration Request that it sends to the Foreign Agent.
  3. If one or more AAA Key Generation Nonce Request extensions were added, the mobile node MUST add the MN-AAA Authentication extension to its Registration Request.
  4. By action of the foreign agent (which is presumed to be an AAA entity too), the mobile node's key requests and authentication data get passed to the local AAA server (AAAL). This typically happens after reformatting into the appropriate AAA messages, which are out of scope for this document 📦.
  5. After the information within the MN-AAA Authentication extension is verified by the AAA server in the home domain (AAAH), that server also generates the key material the mobile node requested, for the necessary Mobility Security Associations 🔐.
  6. The respective keys for the Mobility Security Associations are distributed to the Home Agent and Foreign Agent via the AAA protocol.
  7. The mobile node receives the Registration Reply message from the Foreign Agent.
  8. If a MN-HA Key Generation Nonce Request From AAA extension is present in the Registration Request message, then the mobile node MUST create or update its Mobility Security Association with the Home Agent indicated in the corresponding Registration Reply, using the key computed from the key material in the MN-HA Key Generation Nonce From AAA extension. In this case, if no MN-HA Key Generation Nonce Reply extension is present, the mobile node MUST discard the Registration Reply 🚫.
  9. Using its (perhaps newly created) Mobility Security Association with the home agent, the mobile node authenticates the Registration Reply message by checking the Authentication Data in the Mobile-Home Authentication extension. If the check fails, the MN MUST discard the Registration Reply and the new Mobility Security Association, reverting to the old Mobility Security Association with the home agent, if any 🙅‍♀️.
  10. If the Registration Reply passes authentication and contains a MN-FA Key Generation Nonce From AAA extension (see section 6.2), the mobile node generates the registration key using the Key Generation Nonce provided, according to its AAA Security Association with the AAA. The resulting registration key is used to establish the mobile node's Mobility Security Association with its foreign agent, and is used to compute the authentication data used in the Mobile-Foreign authentication extension.

If verification of the Mobile-Foreign authentication extension fails, and if the MN-FA Key Generation Nonce Reply extension was not protected by another, valid authentication extension, the MN MUST discard the new Mobility Security Association, reverting to the old Mobility Security Association with the foreign agent, if any 💔.

Any registration reply containing the MN-HA Key Generation Nonce From AAA extension MUST also contain a subsequent Mobile Home Authentication extension, created using the generated MN-HA key. Similarly, a reply containing the MN-FA Key Generation Nonce From AAA extension MUST also contain a subsequent Mobile Foreign Authentication extension, created using the registration key 🎀.

4. Mobility Security Associations 🦋

Mobility Security Associations between Mobile IP entities (mobile nodes, home agents, foreign agents) hold two things: the necessary cryptographic key information, and a way to identify the cryptographic transform that uses that key to produce the authentication information in the Mobile-Home Authentication extension or the Mobile-Foreign Authentication extension 🔐. So for a mobile node to actually use key material created by the AAA server, it also has to be able to identify and select the right cryptographic transform that uses the key to produce the authentication. Main character energy 👑.

The transform identifiers are the same ones used in IPsec ✨. They're tabulated in the list of Authentication Algorithms allowable as values for the "Attribute Type" (5) (i.e., "Authentication Algorithm"), which is one of the classifications in the tabulated Attribute Types for "IPsec Security Association Attributes". For the full listing of all Attribute Types and other Attributes for IPsec Security Associations, check http://www.iana.org/assignments/isakmp-registry 🌈.

Mobility Security Associations shared between mobile nodes and home agents also need a replay protection method 🙈. Here's the table of supported replay detection methods:

      Replay Method       Name           Reference
      --------------    ------------   --------------
      0,1               Reserved
      2                 Timestamps       RFC 3344 [1]
      3                 Nonces           RFC 3344 [1]
      4-65535           Unallocated

5. Key Generation Nonce Creation and Key Derivation 🔐

This section is the procedure lineup for creating the Key Generation Nonce on the AAA server side, and for the key derivation that mobile nodes do 🧠. Note that the AAA servers will also deliver the keys to the mobility agents (home agent, foreign agent) via the AAA protocol. AAA servers that follow these procedures will produce results that mobile nodes can understand 💕. The mobility agents will faithfully transcribe those results into the appropriate Mobile IP extensions 📝.

The following example uses HMAC-SHA1 [6]. All mobile nodes and mobility agents implementing Mobile IP [1] and implementing the extensions specified in this document MUST implement HMAC-SHA1 [1]. Other message authentication codes or keyed hash functions MAY also be used. The particular algorithm used is configured as part of the AAA Security Association between the MN and the AAAH server, which is in turn indexed by the AAA SPI 🔑.

The following steps are performed on the AAAH server:

  1. The AAA server identifies the mobile node. If the NAI field is present in the Registration Request, then the NAI is used as the mobile node identifier. Otherwise, the Home Address field of the Registration Request is used.
  2. The AAA server generates a random [7] value of at least 128 bits to be used as the Key Generation Nonce 🎲.
  3. The AAA server inserts the random value into the Key Generation Nonce Reply extension in the "Key Generation Nonce" field.

The following steps are performed by the mobile node (here || represents concatenation) 🧁:

  1. The mobile node calculates
      key = HMAC-SHA1 (AAA-key, {Key Generation Nonce || mobile node
      identifier})

Here the Key Generation Nonce is from the extension in the Registration Reply, and the mobile node identifier is the MN's NAI, if present in the Registration Request, or the Home Address from the Registration Request otherwise.

  1. The mobile node creates the Mobility Security Association(s), using the resulting key and the other relevant information in the Key Generation Nonce Extension 🎉.

The secret key used within the HMAC-SHA1 computation is indicated by the AAA Security Association indexed by the AAA SPI. That association has been previously configured as the basis for the AAA Security Association between the mobile node and the AAA server creating the key material 🗝️.

6. Key Generation Extensions 🎀

This section defines new Extensions to Mobile IP Registration Requests and Replies [1] 💅.

6.1. Generalized MN-FA Key Generation Nonce Request Extension ✨

Okay bestie, first up is the MN-FA KeyGen Request 🦋. Figure 1 shows the layout, and it is giving very organized energy 💅

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Subtype    |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Mobile Node SPI                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           MN-FA Key Generation Nonce Request Subtype Data ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 1: The Generalized Mobile IP MN-FA Key Generation Nonce Request Extension

  • Type 🌸 is 40 (not skippable) (see [1] and section 8).
  • Subtype 🎀 is a number that says how the MN-FA Key Generation Nonce Request Subtype Data gets used when the registration key is generated.
  • Length 📏 is a 16-bit field with the length of the extension. It equals the number of bytes in the MN-FA Key Generation Nonce Request Subtype Data plus 4 (for the Mobile Node SPI field).
  • Mobile Node SPI 🔑 is the Security Parameters Index that the mobile node will assign for the Mobility Security Association that gets created for the registration key.
  • MN-FA Key Generation Nonce Request Subtype Data 📦 is the data needed to create the registration key on behalf of the mobile node.

So the MN-FA KeyGen Request is a whole set of extensions, told apart by subtype, that a mobile node can put in a Mobile IP Registration Request. It basically asks some other entity to make a Registration Key for the mobile node to use with its new foreign agent 🧚

This document defines subtype 1, which is the MN-FA Key Generation Nonce From AAA Request (MN-FA AAA KeyGen Request for short) 💜. The MN-FA AAA KeyGen Request has a zero-length Subtype Data field. It MUST appear in the Registration Request before the MN-AAA Authentication extension, so don't mess up the order, bestie 😭

6.2. Generalized MN-FA Key Generation Nonce Reply Extension

The Generalized MN-FA Key Generation Nonce Reply extension (MN-FA KeyGen Reply for short) is the one that hands over the keying material that the MN-FA KeyGen Request asked for 🎁 Figure 2 shows its format.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Subtype    |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             MN-FA Key Generation Nonce Reply Subtype Data ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 2: The Generalized Mobile IP MN-FA Key Generation Nonce Reply Extension

  • Type 🌈 is 41 (not skippable) (see [1] and section 8).
  • Subtype 🍓 is a number that says how the MN-FA Key Generation Nonce Reply Subtype Data gets used to obtain the registration key.
  • Length 📏 is a 16-bit field equal to the number of bytes in the MN-FA Key Generation Nonce Reply Subtype Data.
  • MN-FA Key Generation Nonce Reply Subtype Data 💌 is an encoded copy of the keying material, plus any other info the recipient needs to create the designated Mobility Security Association.

For each subtype, the format of the MN-FA Key Generation Nonce Reply Subtype Data has to be defined separately, depending on the specific method used to set up the Mobility Security Association ✨

For the subtype defined in this document, the MN-FA Key Generation Nonce in the data can come from a request that used a subtype of the Generalized MN-FA Key Generation Nonce Request Extension. When that happens, the SPI used with the Mobility Security Association defined by the registration key is the same one given in the original request 🔁

Once the mobile node creates the Mobility Security Association with the foreign agent, using the transform indexed by the AAA SPI, it stores that Mobility Security Association indexed by the FA SPI in its list of Mobile Security Associations 🗂️

If the foreign agent gets a Registration Reply with no MN-FA Key Generation Nonce Reply extension, and it has no existing Mobility Security Association with the mobile node, the foreign agent MAY change the Code value of the Registration Reply to MISSING_MN_FA (see section 7). That effectively makes the registration fail 🙈

This document defines subtype 1 of the MN-FA KeyGen Reply, which is the MN-FA Key Generation Nonce From AAA extension (MN-FA AAA KeyGen Reply for short) 🧁 It's shown in Figure 3.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            Lifetime                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            AAA SPI                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             FA SPI                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Algorithm Identifier     |      Key Generation Nonce ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 3: The MN-FA Key Generation Nonce From AAA Subtype-Specific Data

  • lifetime ⏳ is how long (in seconds) the keying material used to create the registration key stays valid.
  • AAA SPI 🪪 is a 32-bit opaque value. It tells the mobile node which SPI to use to figure out the transform for setting up the Mobility Security Association between the mobile node and its prospective foreign agent.
  • FA SPI 🎯 is the SPI for the Mobility Security Association with the FA, which the mobile node creates using the Key Generation Nonce.
  • Algorithm Identifier 🧮 says which transform to use. It gets stored with the Mobility Security Association with the foreign agent, and it's picked from the values in the "Authentication Algorithm" table cited in section 4. It's used for future computations of the Mobile-Foreign Authentication Extension.
  • Key Generation Nonce 🎲 is a random [7] value of at least 128 bits.

The MN-FA AAA KeyGen Reply extension MUST appear in the Registration Reply before the Mobile-Foreign Authentication extension 🛑

The AAA server gives the Key Generation Nonce to the mobile node so it can make the registration key. That key is what secures future Mobile IP registrations with the same foreign agent 🔐

6.3. Generalized MN-HA Key Generation Nonce Request Extension

Figure 4 shows the Generalized MN-HA Key Generation Nonce Request Extension (MN-HA KeyGen Request for short) 🌷 Here's the rundown before the picture:

  • Type 💖 is 42 (not skippable) (see [1] and section 8).
  • Subtype 🧸 is a number that says how the MN-HA Key Generation Nonce Request Subtype Data gets used when the registration key is generated.
  • Length 📐 is a 16-bit field with the length of the extension. It equals the number of bytes in the MN-HA Key Generation Nonce Request.
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Subtype    |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Mobile Node SPI                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            MN-HA Key Generation Nonce Request Subtype Data ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 4: The Generalized Mobile IP MN-HA Key Generation Nonce Request Extension

Subtype Data plus 4 (for the Mobile Node SPI field).

  • Mobile Node SPI 🔑 is the Security Parameters Index that the mobile node will assign for the Mobility Security Association created for use with the registration key.
  • MN-HA Key Generation Nonce Request Subtype Data 📦 is the data needed to create the MN-HA key on behalf of the mobile node.

The MN-HA KeyGen Request Extension is a set of extensions, told apart by subtype, that a mobile node can put in a Mobile IP Registration Request. It asks some other entity to make an MN-HA key for the mobile node to use with its new home agent 🏠

This document defines subtype 1, which is the MN-HA Key Generation Nonce from AAA Request (MN-HA AAA KeyGen Request for short) 🌟 The MN-HA AAA KeyGen Request has a zero-length Subtype Data field. It MUST appear in the Registration Request before the MN-AAA Authentication extension, so keep that order locked in, bestie 🫶

6.4. Generalized MN-HA Key Generation Nonce Reply Extension 🔑

okay so the Generalized MN-HA Key Generation Nonce Reply extension (MN-HA KeyGen Reply for short) is the one that delivers the keying material that the MN-HA KeyGen Request extension asked for 💖 Figure 5 shows the format:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Subtype    |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            Lifetime                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              MN-HA Key Generation Nonce Reply Subtype Data ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

          Figure 5: The Generalized Mobile IP MN-HA Key
                    Generation Nonce Reply Extension

Here's what each field does ✨

  • Type is 43 (not skippable) (see [1] and section 8) 🎀
  • Subtype is a number assigned to identify the way in which the MN-HA Key Generation Nonce Reply Subtype Data is to be used to obtain the MN-HA key.
  • Length is a 16-bit field that indicates the length of the extension. It equals the number of bytes in the MN-HA Key Generation Nonce Reply Subtype Data plus 4 (for the Lifetime field).
  • Lifetime indicates the duration of time (in seconds) for which the MN-HA key is valid ⏰
  • MN-HA Key Generation Nonce Reply Subtype Data is data used to derive the MN-HA key, along with any other information needed by the mobile node to create the designated Mobility Security Association with the home agent.

For each subtype, the format of the MN-HA Key Generation Nonce Reply Subtype Data has to be separately defined according to the particular method required to set up the Mobility Security Association. It's giving customization 🌈

This document defines subtype 1 of the MN-HA KeyGen Reply for the MN-HA Key Generation Nonce From AAA extension (MN-HA AAA KeyGen Reply for short), shown in figure 6 🦋

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            AAA SPI                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             HA SPI                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Algorithm Identifier      |         Replay Method         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Key Generation Nonce ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        Figure 6: The MN-HA Key Generation Nonce From AAA
                  Subtype-Specific Data

The fields in figure 6 work like this 🧚

  • AAA SPI is a 32-bit opaque value, indicating the SPI that the mobile node must use to determine the transform to use for establishing the Mobility Security Association between the mobile node and its home agent.
  • HA SPI is the SPI for the Mobility Security Association to the HA that the mobile node creates using the Key Generation Nonce.
  • Algorithm Identifier indicates the transform to be used for future computations of the Mobile-Home Authentication Extension (see section 4).
  • Replay Method contains the replay method to be used for future Registration messages (see section 4).
  • Key Generation Nonce is a random [7] value of at least 128 bits.

The MN-HA AAA KeyGen Reply subtype-specific data is shown in figure 6. The Mobile Node calculates the MN-HA key using the Key Generation Nonce provided by the AAA server. The calculation proceeds by using the key shared between the mobile node and the AAA server that has previously been configured for securing all such communication requirements with the AAA server which will be contacted within the AAA infrastructure (see appendix A). The MN-HA key is intended for use by the mobile node to secure future Mobile IP registrations with its home agent. The MN-HA AAA KeyGen Reply extension MUST appear in the Registration Reply before the MN-HA Authentication extension. 🚨

Once the mobile node creates the MN-HA Key, by using the transform specified in the AAA SPI, it stores the HA Security Information indexed by the HA SPI in its list of Mobile Security Associations. The mobile node uses the Identification field data from the Registration Reply as its initial synchronization data with the home agent. ✅

7. Error Values 💀

Each entry in the following table contains the name of the Code [1] value to be returned in a Registration Reply, the value for that Code, and the section in which the error is first mentioned in this specification.

   Error Name               Value   Section
   ----------------------   -----   ---------
   MISSING_MN_FA             107      6.2

8. IANA Considerations 🧾

This document defines 4 new extensions (see Section 6) taken from the (non-skippable) numbering space defined for Mobile IP registration extensions defined in RFC 3344 [1] as extended in RFC 2356 [8]. The values for these extensions are:

   Name                   Value   Section
   --------------------- ------- ---------
   MN-FA-KeyGen Request    40      6.1
   MN-FA-KeyGen Reply      41      6.2
   MN-HA-KeyGen Request    42      6.3
   MN-HA-KeyGen Reply      43      6.4

IANA has created and will maintain a new registry for the KeyGen Request/Reply subtypes. The initial contents of the registry is a single entry for the subtypes defined in this document:

   Name                           Value   Section
   ----------------------------- ------- ---------
   KeyGen Request/Reply from AAA    1        6

New subtypes for these two registries are assigned through Standards Action as defined in [9].

IANA has assigned a code value for error MISSING_MN_FA, listed in section 7. This value has been taken from the space of error values conventionally associated with rejection by the foreign agent (i.e., 64-127).

IANA has created and will maintain a namespace for the Replay Method Identifier. This specification makes use of 2 and 3; all other values other than zero (0) and (1) are available for assignment, pending review and approval by a Designated Expert [9].

9. Security Considerations 🔥😭

okay this section is serious, bestie 🙈 The extensions in this document are intended to provide the appropriate level of security for Mobile IP entities (mobile node, foreign agent, and home agent) to calculate the Authentication Data needed by authentication extensions used with Mobile IP registration messages. The Mobility Security Associations resulting from use of these extensions do not offer any higher level of security than what is already implicit in use of the AAA Security Association between the mobile node and the AAAH. In order to deny any adversary the luxury of unbounded time to analyze and break the secrecy of the AAA Security Association between the mobile node and the AAA server, that AAA Security Association MUST be refreshed periodically. 💥

The provisioning and refreshing of the AAA key in the MN and AAA server is outside the scope of this document.

Since the Reply extensions defined in this specification only carry Key Generation Nonces, which are used to derive keys, they do not expose any data that could be used in an attack aimed at recovering the key shared between the mobile node and the AAA. The authors do not believe this specification introduces any new security vulnerability. 🛡️

10. Acknowledgements 🫶

Thanks to Fredrik Johansson, Tom Hiller, and the members of the IESG for their useful comments. Thanks especially to Tom Hiller who has contributed many textual improvements to later revisions of this document. 💜

11. References 📚

11.1. Normative References

  • [1] Perkins, C., Ed., "IP Mobility Support for IPv4", RFC 3344, August 2002.
  • [2] Aboba, B. and M. Beadles, "The Network Access Identifier", RFC 2486, January 1999.
  • [3] Perkins, C. and P. Calhoun, "Mobile IPv4 Challenge/Response Extension", RFC 3012, November 2000.
  • [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [5] Calhoun, P. and C. Perkins, "Mobile IP Network Access Identifier Extension for IPv4", RFC 2794, March 2000.
  • [6] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
  • [7] Eastlake, D., Crocker, S., and J. Schiller, "Randomness Recommendations for Security", RFC 1750, December 1994.
  • [8] Montenegro, G. and V. Gupta, "Sun's SKIP Firewall Traversal for Mobile IP", RFC 2356, June 1998.
  • [9] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.

11.2. Informative References

  • [10] Mitton, D., St.Johns, M., Barkley, S., Nelson, D., Patil, B., Stevens, M., and B. Wolff, "Authentication, Authorization, and Accounting: Protocol Evaluation", RFC 3127, June 2001.
  • [11] Rigney, C., Willens, S., Rubens, A., and A. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
  • [12] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
  • [13] Glass, S., Hiller, T., Jacobs, S., and C. Perkins, "Mobile IP Authentication, Authorization, and Accounting Requirements", RFC 2977, October 2000.
  • [14] Calhoun, P. and C. Perkins, "DIAMETER mobile IP extensions", Work in Progress, February 2004.

Appendix A. AAA Infrastructure 🧚

okay so this appendix is where we lay out the main features of a basic model for how AAA servers operate. the Mobile IP registration extensions in this doc are built on that model, so you need it to get them. this info is adapted from the discussion in RFC 2977 [13], so go check there for the full tea 🫖

Within the Internet, a mobile node that belongs to one administrative domain (called the home domain) often needs to use resources from another administrative domain (called the foreign domain) 🌍. A foreign agent that handles the mobile node's Registration Request is likely to require that the mobile node provide some credentials that can be authenticated before access to the resources is permitted. These credentials may be provided as part of the Mobile-AAA Authentication extension [3], relying on the existence of an AAA infrastructure such as the one described in this section, and also described in RFC 2977 and RFC 3012 [3]. Such credentials are typically managed by entities within the mobile node's home domain. They may also be used for setting up secure communications with the mobile node and the foreign agent, or between the mobile node and its home agent if necessary 🔐.

              Local Domain                  Home Domain
              +--------------+           +----------------------+
              |   +------+   |           |   +------+           |
              |   |      |   |           |   |      |           |
              |   | AAAL |   |           |   | AAAH |           |
              |   |      +-------------------+      |           |
              |   +---+--+   |           |   +------+           |
              |       |      |           |                      |
              |       |      |           +----------------------+
   +------+   |   +---+--+   |
   |      |   |   |      |   |       MN   =  mobile node
   |  MN  |- -|- -|  FA  |   |       FA   =  foreign agent
   |      |   |   |      |   |       AAAL =  local authority
   +------+   |   +------+   |       AAAH =  home authority
              |              |
              +--------------+
          Figure 7: AAA Servers in Home and Local Domains

The foreign agent often can't access the data it needs to verify the credentials directly 🙈. Instead, it's expected to consult an authority (typically in the same foreign domain) to request proof that the mobile node has acceptable credentials. Since the foreign agent and the local authority (AAAL) are part of the same administrative domain, they are expected to have established, or be able to establish for the necessary lifetime, a secure channel for exchanging sensitive (access) information and keeping it private from (at least) the visiting mobile node.

The local authority (AAAL) itself may not have enough information stored locally to carry out the verification of the mobile node's credentials. Unlike the foreign agent, though, the AAAL is expected to be configured with enough information to negotiate the verification of mobile node credentials with its home domain 🤝. The home and foreign domains should be configured with sufficient IP Security Associations (i.e., IPsec) and access controls so that they can negotiate the authorization, and also enable the mobile node to acquire Mobility Security Associations with the mobility agents within the foreign domain. For the purposes of the key exchanges specified within this document, the authorization is expected to depend only upon secure authentication of the mobile node's credentials.

Once the local authority has obtained the authorization, and has notified the foreign agent about the successful negotiation, the foreign agent can deliver the Registration Reply to the mobile node along with the key material 🎁.

In figure 7, there might be many mobile nodes from many different Home Domains. Each Home Domain provides an AAAH that can check credentials originating from mobile nodes administered by that Home Domain. There is a security model implicit in figure 7, and it is crucial to identify the specific security associations assumed in that model. These IP Security Associations are illustrated in figure 8, and are considered to be relatively long-lived security associations ⏳.

First, it is natural to assume that the mobile node has an AAA Security Association with the AAAH, since that is roughly what it means for the mobile node to belong to the home domain.

Second, from the model illustrated in figure 7 it is clear that AAAL and AAAH have to share an IP Security Association, because otherwise they could not rely on the authentication results, authorizations, or even the accounting data that might be transacted between them. Requiring such bilateral IP Security Associations is, however, in the end not scalable. The AAA framework must provide for more scalable mechanisms, but the methods by which such a broker model is to be created are out of scope for this document. See RFC 2977 for more details 📚.

Finally, from figure 7, it is clear that the foreign agent can naturally share an IP Security Association with the AAAL. This is necessary for the model to work, because the foreign agent has to have a way to find out that it is permissible to allocate the local resources to the mobile node, and further to transmit any successful Registration Reply to the mobile node 💌.

Figure 8 illustrates the IP Security Associations we understand from our proposed model. Note that there may be, by mutual agreement between AAAL and AAAH, a third party inserted between them to help arbitrate secure transactions in a more scalable fashion. The broker model designed to enable such third-party processing should not have any effect on the Mobile IP extensions specified in this document, so no description is provided here. See RFC 2977 [13] for more details ✨.

                               +------+              +------+
                               |      |              |      |
                               | AAAL +--------------+ AAAH |
                               |      |              |      |
                               +---+--+              +--+---+
                                   |                    |
                                   |                    |
                               +---+--+              +--+---+
   MN   =  mobile node         |      |              |      |
   FA   =  foreign agent       |  FA  |              |  MN  |
   AAAL =  local authority     |      |              |      |
   AAAH =  home authority      +------+              +------+
                   Figure 8: IP Security Associations

Nodes in two separate administrative domains (for instance, AAAH and AAAL) often must take additional steps to verify the identity of their communication partners, or to guarantee the privacy of the data making up the communication. While these considerations lead to important security requirements, as mentioned above in the context of security between servers, we consider the exact choice of IP Security Associations between the AAA servers to be beyond the scope of this document. The choices are unlikely to depend upon Mobile IP, or any specific features of the general model illustrated in figure 7. On the other hand, the Mobility Security Associations needed between Mobile IP entities are of central importance in the design of the key derivation extensions in this document 🔑.

One further detail deserves mention. The Mobility Security Association to be established between the mobile node and the foreign agent has to be communicated to the foreign agent as well as to the mobile node. The following requirements are placed on the mechanism used by the AAA infrastructure to effect key distribution 🫶:

  • The AAAH must establish strong, fresh session keys.
  • The mechanism must maintain algorithm independence, allowing for the distribution of authentication algorithm identification along with the keys.
  • The mechanism must include replay detection.
  • The mechanism must authenticate all parties, including the AAA servers and the FA and HA.
  • The mechanism must provide for authorization of the client, FA, and HA.
  • The mechanism must not rely on plaintext passwords.
  • The mechanism must maintain confidentiality of session keys.
  • The mechanism must uniquely name session keys.
  • The mechanism must be such that the compromise of a single FA and HA cannot compromise any other part of the system, including session keys and long-term keys.
  • The mechanism must bind key(s) to an appropriate context.
  • The mechanism must not expose the keys to entities other than the AAAH and FA (or HA in the case of key distribution to the HA).

The way the key is distributed to the foreign agent (or home agent) is expected to be handled as part of the AAA protocol processing between the AAAH and AAAL, and the further AAA protocol processing between the AAAL and the foreign agent. Such processing is outside the scope of this document, but it must satisfy the above requirements 💜.

Appendix B. Message Flow for Requesting and Receiving Registration Keys ✨

Okay bestie, this is the storytime part 🎬 We're walking through the actual message flows for asking for and receiving a registration key from the AAA infrastructure (the one from section A, so go check that out 💅). Quick side note: challenge values from [3] could be added to the Advertisement and Registration messages for extra replay protection 🛡️ but we're not drawing those here, so don't panic if you don't see them.

Diagram 9 is the case where the mobile node explicitly asks for keying material so it can make its registration keys 🔑

   MN                     FA                  AAA Infrastructure
    |                       |                           |
    |<--- Advertisement-----|                           |
    |      (if needed)      |                           |
    |                       |                           |
    |-- RReq+AAA Key Req.-->|                           |
    |                       |--- RReq + AAA Key Req.--->|
    |                       |                           |
    |                       |<--- RRep + AAA Key Rep.---|
    |<-- RRep+AAA Key Rep.--|                           |
    |                       |                           |

          Figure 9: Message Flows for Requesting and
                    Receiving Key Generation Nonce

So in diagram 9, here's the play-by-play:

  1. The foreign agent disseminates an Agent Advertisement. This advertisement MAY have been produced after receiving an Agent Solicitation from the mobile node (not shown in the diagram).
  2. The mobile node creates a Registration Request including the MN-HA AAA KeyGen Request and/or MN-FA AAA KeyGen Request, as needed, along with an authorization-enabling authentication extension as required by Mobile IP [1]. Main character energy 🎀
  3. The foreign agent relays the Registration Request and/or Key Request(s) to its locally configured AAA Infrastructure (see appendix A), according to local policy.
  4. The foreign agent receives a AAA Response with the appropriate indications for authorizing connectivity for the mobile node. Along with this AAA Response, the foreign agent may also receive key material by some secure method appropriate for communications between it and its local AAA infrastructure. At this point, if the foreign agent has not relayed the Registration Request, it forwards it directly to the Home Agent and waits for a Registration Reply (not shown in the figure). 🦋
  5. The foreign agent relays the Registration Reply to the mobile node, along with the new AAA KeyGen Reply extensions to be used by the mobile node to establish Mobility Security Associations with the relevant mobility agents (foreign agent and/or home agent). And that's the whole glow-up ✨

Diagram 10 is the case where the mobile node receives unsolicited keying material from the AAA Infrastructure 🌸 nobody asked, but here it comes anyway, iconic.

   MN                     FA                  AAA Infrastructure
    |                       |                           |
    |<--- Advertisement-----|                           |
    |      (if needed)      |                           |
    |                       |                           |
    | ------ RReq --------->|                           |
    |                       |------- RReq ------------->|
    |                       |                           |
    |                       |<--- RRep + AAA Key Rep.---|
    |<-- RRep+AAA Key Rep.--|                           |
    |                       |                           |

      Figure 10: Message Flow for Receiving Unsolicited
                 Key Generation Nonce

And for diagram 10, the flow goes like this:

  1. The foreign agent disseminates an Agent Advertisement. This advertisement MAY have been produced after receiving an Agent Solicitation from the mobile node (not shown in the diagram).
  2. The mobile node creates a Registration Request including an authorization-enabling authentication extension as required by Mobile IP [1].
  3. The foreign agent sends a AAA Request (possibly containing the Registration Request) to its locally configured AAA Infrastructure (see appendix A), according to local policy.
  4. The foreign agent receives a AAA Response with the appropriate indications for authorizing connectivity for the mobile node. Along with this AAA Response, the foreign agent may also receive key material by some secure method appropriate for communications between it and its local AAA infrastructure. At this point, if the foreign agent has not relayed the Registration Request, it forwards it directly to the Home Agent and waits for a Registration Reply (not shown in the figure). 💜
  5. The foreign agent relays the Registration Reply to the mobile node, along with the new KeyGen Reply extensions to be used by the mobile node to establish Mobility Security Associations with the relevant mobility agents (foreign agent and/or home agent). Bestie, it's a wrap 🎬👑

Authors' Addresses 🧑‍💻

Charles E. Perkins
Nokia Research Center
313 Fairchild Drive
Mountain View, California 94043
USA

Phone:  +1 650 625-2986
Fax:    +1 650 625-2502
EMail:  charles.perkins@nokia.com


Pat R. Calhoun
Airespace, Inc.
110 Nortech Parkway
San Jose, CA 95134
USA

Phone:  +1 408 635 2000
Fax:    +1 408 635 2020
EMail:  pcalhoun@airespace.com

Copyright (C) The Internet Society (2005).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. 🔒

The lawyer-y part, and I'm keeping every word of it 🙈 This document and the information contained herein are provided on an "AS IS" basis and:

THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property 💖

The IETF takes no position on whether any Intellectual Property Rights or other rights might be claimed to cover the implementation or use of the technology in this document, or whether any license under those rights might or might not be available. It also doesn't claim to have made any independent effort to find those rights. If you want the procedures for rights in RFC documents, check BCP 78 and BCP 79 🌈

Copies of IPR disclosures made to the IETF Secretariat, any assurances of licenses to be made available, and the results of any attempt to get a general license or permission for implementers or users to use those proprietary rights can be found in the IETF's online IPR repository at http://www.ietf.org/ipr. 🔍

The IETF also invites any interested party to bring to its attention any copyrights, patents, patent applications, or other proprietary rights that may cover technology required to implement this standard. Send that info to the IETF at ietf-ipr@ietf.org 📬

Acknowledgement 🫶

Funding for the RFC Editor function is currently provided by the Internet Society. ⭐

📦 where this page comes from