RFC 4721
Mobile IPv4 Challenge/Response Extensions (Revised)
Mobile IPv4 Challenge/Response Extensions (Revised) 🦋
Okay bestie, let's get into RFC 4721 💅 It's a Standards Track doc from the Network Working Group, written by C. Perkins (Nokia Research Center), P. Calhoun (Cisco Systems, Inc.), and J. Bharatia (Nortel Networks), dated January 2007. It's giving "revised" because it obsoletes RFC 3012 and updates RFC 3344 🎀 So if you're working with the older stuff, this is the newer, glow-up version 🌸
Status of This Memo 🧚
So this doc specifies an Internet standards track protocol for the Internet community, and it literally wants discussion and suggestions for improvements 💬 For where this protocol stands right now, check the current edition of the "Internet Official Protocol Standards" (STD 1). And distribution of this memo is unlimited 🌈
Copyright Notice 🎀
Copyright (C) The IETF Trust (2007).
Abstract ✨
Okay so Mobile IP, as originally specified, has an authentication extension called the Mobile-Foreign Authentication extension, which lets a mobile node prove itself to a foreign agent 🦋 The tea is that this extension doesn't give the foreign agent any direct guarantee that the protocol is protected from replays 🙈 It also doesn't let you use existing techniques, like Challenge Handshake Authentication Protocol (CHAP), for authenticating portable computer devices. Not it 💀
So in this spec, we define extensions for the Mobile IP Agent Advertisements and the Registration Request. These let a foreign agent use a challenge/response mechanism to authenticate the mobile node, and it's giving main character energy 👑
Also, this document updates RFC 3344 by adding a new authentication extension called the Mobile-Authentication, Authorization, and Accounting (AAA) Authentication extension 🫶 It exists so a mobile node can supply credentials for authorization, using commonly available AAA infrastructure elements. This authorization-enabling extension MAY co-exist in the same Registration Request with authentication extensions defined for Mobile IP Registration by RFC 3344. And yes, this document obsoletes RFC 3012. Iconic 💖
Table of Contents 🌈
1. Introduction ....................................................2
1.1. Terminology ................................................3
2. Mobile IP Agent Advertisement Challenge Extension ...............4
2.1. Handling of Solicited Agent Advertisements .................4
3. Operation .......................................................5
3.1. Mobile Node Processing of Registration Requests ............5
3.2. Foreign Agent Processing of Registration Requests ..........6
3.2.1. Foreign Agent Algorithm for Tracking Used
Challenges .........................................8
3.3. Foreign Agent Processing of Registration Replies ...........9
3.4. Home Agent Processing of Challenge Extensions .............10
3.5. Mobile Node Processing of Registration Replies ............11
4. Mobile-Foreign Challenge Extension .............................11
5. Generalized Mobile IP Authentication Extension .................12
6. Mobile-AAA Authentication Subtype ..............................13
7. Reserved SPIs for Mobile IP ....................................14
8. SPIs for RADIUS AAA Servers ....................................14
9. Configurable Parameters ........................................15
10. Error Values ..................................................16
11. IANA Considerations ...........................................16
12. Security Considerations .......................................17
13. Acknowledgements ..............................................18
14. Normative References ..........................................18
Appendix A. Changes since RFC 3012 ................................20
Appendix B. Verification Infrastructure ...........................21
Appendix C. Message Flow for FA Challenge Messaging with
Mobile-AAA Extension ..................................22
Appendix D. Message Flow for FA Challenge Messaging with
MN-FA Authentication ..................................23
Appendix E. Example Pseudo-code for Tracking Used Challenges ......241. Introduction ✨
Okay so Mobile IP defines the Mobile-Foreign Authentication extension, which lets a mobile node authenticate itself to a foreign agent 💅 Honestly, these authentication mechanisms are mostly outside the main operation of Mobile IP. The foreign agent can route packets to and from a mobile node no matter whether or not that node is reporting a legitimately owned home address to it 🧚
But here's the problem: that extension doesn't give the foreign agent any direct guarantee that the protocol is protected from replays, and it doesn't let you use CHAP [RFC1994] for authenticating portable computer devices 😭 So in this specification, we define extensions for the Mobile IP Agent Advertisements and the Registration Request. These let a foreign agent use a challenge/ response mechanism to authenticate the mobile node 🔥
There's also a new authentication extension, the Mobile-AAA authentication extension, so a mobile node can supply credentials for authorization using commonly available AAA infrastructure elements 🎀 The foreign agent may be able to interact with an AAA infrastructure (using protocols outside the scope of this document) to get a secure indication that the mobile node is authorized to use the local network resources. Slay 👑
1.1. 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 RFC 2119 [RFC2119].
This document uses the term Security Parameters Index (SPI) as defined in the base Mobile IP protocol specification [RFC3344]. Every SPI value defined in this document refers to values for the SPI as defined in that specification 🌸
Here's the extra terminology on top of what's in [RFC3344] 🫶
- previously used challenge: The challenge is a previously used challenge if the mobile node sent the same challenge to the foreign agent in a previous Registration Request, and if that previous Registration Request passed all validity checks performed by the foreign agent. The foreign agent may not be able to keep records for all previously used challenges, but see Section 3.2 for minimal requirements. 🙈
- security association: A "mobility security association", as defined in [RFC3344]. 💜
- unknown challenge: Any challenge from a particular mobile node that the foreign agent has no record of having put either into one of its recent Agent Advertisements or into a registration reply message to that mobile node. 👀
- unused challenge: A challenge that has not already been accepted by the foreign agent from the mobile node in the Registration Request, i.e., a challenge that is neither unknown nor previously used. ✨
2. Mobile IP Agent Advertisement Challenge Extension 🧚
This section defines a brand new extension to the Router Discovery Protocol [RFC1256]. It's for foreign agents that need to issue a challenge for authenticating mobile nodes 💖
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 | Length | Challenge ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1. The Challenge ExtensionHere's the vibe check on the fields 🍓
- Type:
24 - Length: The length of the Challenge value in octets; SHOULD be at least 4.
- Challenge: A random value that SHOULD be at least 32 bits.
The Challenge extension (see Figure 1) gets inserted in the Agent Advertisements by the foreign agent. Its job is to communicate a previously unused challenge value that the mobile node can use to compute an authentication for its next registration request message 🌈 The foreign agent picks the challenge to give local assurance that the mobile node isn't replaying any earlier registration request, which is honestly so smart 🧠 Eastlake et al. [RFC4086] provides more information on generating pseudo-random numbers suitable for use as values for the challenge.
Note that the storage of different Challenges received in Agent Advertisements from multiple foreign agents is implementation specific, and hence out of scope for this specification 🔥
2.1. Handling of Solicited Agent Advertisements 💅
Okay so when a foreign agent generates an Agent Advertisement in response to a Router Solicitation [RFC1256], some extra considerations come into play ✨ According to the Mobile IP base specification [RFC3344], the resulting Agent Advertisement may be either multicast or unicast 🦋
If the solicited Agent Advertisement is multicast, the foreign agent MUST NOT generate a new Challenge value and update its window of remembered advertised Challenges. It must instead re-use the most recent of the CHALLENGE_WINDOW Advertisement Challenge values (Section 9). 🙈
If the agent advertisement is unicast back to the soliciting mobile node, it MUST be handled as follows: If the challenge most recently unicast to the soliciting mobile node has not been previously used (as defined in Section 1.1), it SHOULD be repeated in the newly issued unicast agent advertisement. Otherwise, a new challenge MUST be generated and remembered as the most recent challenge issued to the mobile node. For further discussion of this, see Section 12. 🫶
3. Operation 👑
This section describes modifications to the Mobile IP registration process [RFC3344] that may occur after the foreign agent issues a Mobile IP Agent Advertisement containing the Challenge on its local link. See Appendix C for a diagram showing the canonical message flow for messages related to the processing of the foreign agent challenge values. 🌸
3.1. Mobile Node Processing of Registration Requests ✨
Okay bestie, retransmitting a Registration Request works exactly the same as in the Mobile IP spec [RFC3344] 💅. A retransmitted Registration Request MAY use the same Challenge value as the original one 🦋.
Whenever the Agent Advertisement has the Challenge extension, and the mobile node does not have a security association with the foreign agent, then it MUST put the Challenge value into a Mobile-Foreign Challenge extension in the Registration Request message 🎀. If the mobile node DOES have a security association with the foreign agent, it SHOULD still include the Challenge value in its Registration Request message 🌸.
If the mobile node has a security association with the Foreign Agent, it MUST include a Mobile-Foreign Authentication extension in its Registration Request message, following the base Mobile IP spec [RFC3344] 🔐. When the Registration Request has the Mobile-Foreign Challenge extension from Section 4, the Mobile-Foreign Authentication MUST follow the Challenge extension. The mobile node MAY also include the Mobile-AAA Authentication extension 💜.
If both the Mobile-Foreign Authentication and Mobile-AAA Authentication extensions are there, the Mobile-Foreign Challenge extension MUST precede the Mobile-AAA Authentication extension, and the Mobile-AAA Authentication extension MUST precede the Mobile-Foreign Authentication extension ⭐.
If the mobile node does not have a security association with the foreign agent, the mobile node MUST include the Mobile-AAA Authentication extension, as defined in Section 6, whenever it includes the Mobile-Foreign Challenge extension. On top of that, the mobile node SHOULD include the NAI extension [RFC2794] so the foreign agent can use any verification infrastructure that needs it 🧚. The SPI field of the Mobile-AAA Authentication extension picks out the particular secret and algorithm (shared between the mobile node and the verification infrastructure) that must be used to do the authentication. If the SPI value is chosen as CHAP_SPI (see Section 9), then the mobile node specifies CHAP-style authentication [RFC1994] using MD5 [RFC1321] 🔑.
Either way, the Mobile-Foreign Challenge extension followed by one of the authentication extensions above MUST follow the Mobile-Home Authentication extension, if that one is present 🫶.
A mobile node MAY include the Mobile-AAA Authentication extension in the Registration Request when it registers directly with its home agent (using a co-located care-of address) 🏡. In this case, the mobile node uses an SPI value of CHAP_SPI (Section 8) in the Mobile Node-Authentication, Authorization, and Accounting (MN-AAA) Authentication extension, and it MUST NOT include the Mobile-Foreign Challenge extension. Replay protection for the Registration Request in this case comes from the Identification field defined by [RFC3344] ⏳.
3.2. Foreign Agent Processing of Registration Requests 🎀
Okay, so when the Registration Request arrives, if the foreign agent has issued a Challenge as part of its Agent Advertisements, and it does not have a security association with the mobile node, then the foreign agent SHOULD check that the Mobile-Foreign Challenge extension exists and that it contains a challenge value the mobile node hasn't used before 👀. This makes sure the mobile node isn't trying to replay an old advertisement and authentication. In this case, if the Registration Request has no Challenge extension, the foreign agent MUST send a Registration Reply with the Code field set to missing_challenge 🙅♀️.
If a mobile node retransmits a Registration Request with the same Challenge extension, and the foreign agent still has a pending Registration Request record for that mobile node, then the foreign agent forwards the Registration Request to the Home Agent again 🔁. The foreign agent SHOULD check that the mobile node is really doing a retransmission by verifying that the relevant fields of the retransmitted request (including, if present, the mobile node NAI extension [RFC2794]) match what's in the visitor list entry for the pending Registration Request (Section 3.7.1 of [RFC3344]) 🔍. This verification MUST NOT include the "remaining Lifetime of the pending registration" or the Identification field, because those values are likely to change even for requests that are just retransmissions and not brand new Registration Requests 🙈. In all other situations, if the foreign agent gets a Registration Request with a Challenge extension containing a Challenge value that mobile node already used, the foreign agent SHOULD send a Registration Reply to the mobile node containing the Code value stale_challenge 💀.
The foreign agent MUST NOT accept any Challenge in the Registration Request unless it was offered in the last Registration Reply or unicast Agent Advertisement sent to the mobile node, or advertised as one of the last CHALLENGE_WINDOW (see Section 9) Challenge values inserted into the immediately preceding Agent Advertisements 🚫. If the Challenge isn't one of the recently advertised values, the foreign agent SHOULD send a Registration Reply with the Code value unknown_challenge (see Section 10). The foreign agent MUST keep track of the last challenge used by each mobile node that has registered using any one of the last CHALLENGE_WINDOW challenge values 📝. This last challenge value can be stored as part of the mobile node's registration records. Also, check out Section 3.2.1 for a possible algorithm that can meet this requirement 🧠.
Furthermore, the foreign agent MUST check that there is either a Mobile-Foreign or a Mobile-AAA Authentication extension after the Challenge extension 🛡️. Any registration message that has the Challenge extension without either of these authentication extensions MUST be silently discarded 🤫. If the registration message contains a Mobile-Foreign Authentication extension with an incorrect authenticator that fails verification, the foreign agent MAY send a Registration Reply to the mobile node with the Code value mobile node failed authentication (see Section 10) 😬.
If the Mobile-AAA Authentication extension (see Section 6) is in the message, or if a Network Access Identifier (NAI) extension is included indicating that the mobile node belongs to a different administrative domain, the foreign agent may take actions outside the scope of this protocol specification to carry out the authentication of the mobile node 🌍. If the registration message has a Mobile-AAA Authentication extension with an incorrect authenticator that fails verification, the foreign agent MAY send a Registration Reply to the mobile node with the Code value fa_bad_aaa_auth ❌. If the Mobile-AAA Authentication extension is in the Registration Request, the foreign agent MUST NOT remove the Mobile-AAA Authentication extension or the Mobile-Foreign Challenge extension from the Registration Request before forwarding it to the home agent 🚚. Appendix C gives an example of an action a foreign agent could take 📖.
If the Challenge extension is authenticated through the Mobile-Foreign Authentication extension and the Mobile-AAA Authentication extension is not there, the foreign agent MAY remove the Challenge extension from the Registration Request without messing up the authentication value used for the computation ✂️. If the Mobile-AAA Authentication extension is present and a security association exists between the foreign agent and the home agent, the Mobile-Foreign Challenge extension and the Mobile-AAA Authentication extension MUST precede the Foreign-Home Authentication extension 📦.
If the foreign agent does remove the Challenge extension and the applicable authentication from the Registration Request message, then it SHOULD store the Identification field from the Registration Request message as part of its record-keeping for that mobile node, so it can protect against replays 🛑.
3.2.1. Foreign Agent Algorithm for Tracking Used Challenges 🧮
If the foreign agent keeps a large CHALLENGE_WINDOW, it gets way more important (for scalability reasons) to compare incoming challenges efficiently against the set of Challenge values advertised recently 📈. One way to do this is to keep the Challenge values in order of advertisement, and to use the mandated behavior that mobile nodes MUST NOT use Challenge values advertised before the last advertised Challenge value the mobile node tried to use 🔢. The pseudo-code in Appendix E gets this done 🧑💻. The maximum total storage this algorithm needs is equal to Size*(CHALLENGE_WINDOW + (2*N)), where N is the current number of mobile nodes the foreign agent is storing challenge values for 💾. Note that whenever a stored challenge value is no longer in the CHALLENGE_WINDOW, it can be deleted from the foreign agent's records, maybe along with all the other registration information for that mobile node if it's no longer registered 🧹.
The foreign agent is presumed to keep an array of advertised Challenges, a record of the last advertised challenge used by each mobile node, and also a record of the last challenge provided to a mobile node in a Registration Reply or unicast Agent Advertisement 🗂️.
To meet the security obligations outlined in Section 12, the foreign agent SHOULD use one of the already stored, previously unused challenges when it responds to an unauthenticated Registration Request or Agent Solicitation 🔐✨. If none of the already stored challenges are previously unused, the foreign agent SHOULD generate a new challenge, include it in the response, and store it in the per-Mobile data structure 🌈.
3.3. Foreign Agent Processing of Registration Replies ✨
okay so the foreign agent SHOULD include a new Mobile-Foreign Challenge extension in any Registration Reply, successful or not 💅. If it's a successful reply and the foreign agent does include that extension, the extension SHOULD precede a Mobile-Foreign authentication extension, if one is there 🎀.
Now here's the tricky bit 👀. Say the Registration Reply already has a Challenge extension from the home agent, and the foreign agent wants to add its own Challenge for the mobile node to use. Then the foreign agent MUST delete the home agent's Challenge extension from the Registration Reply, along with any Foreign-Home authentication extension, before it attaches the new Challenge extension. Clean slate, no drama 🧹✨.
One example of when the foreign agent MAY skip the Mobile-Foreign Challenge extension in the Registration Reply is when a new challenge has been multicast recently 🦋.
If a foreign agent is in one of those skip situations, it still MUST respond to a later agent solicitation from the same mobile node with an agent advertisement that contains a previously unused challenge 🫶. Otherwise (when those conditions aren't met), the foreign agent MUST include a previously unused challenge in any Registration Reply, successful or not 💖.
Okay, the pending list stuff is lowkey important 🧠. If the foreign agent doesn't remove the Challenge extension from the Registration Request it got from the mobile node, then the foreign agent SHOULD store the Challenge value as part of the pending registration request list [RFC3344]. Also, if the Registration Reply from the home agent doesn't include the Challenge extension, the foreign agent SHOULD NOT reject the registration request. Not rejecting is the vibe here 🌈.
If the Challenge extension is in the Registration Reply, it MUST be the same Challenge value that was included in the Registration Reply received from the home agent. If it's not, the foreign agent MUST insert a Foreign Agent (FA) Error extension with Status value ha_wrong_challenge in the Registration Reply sent to the mobile node (see Section 10). Total "not me…" moment 💀.
The mobile node MUST be prepared to use a challenge from a unicast or multicast Agent Advertisement instead of one returned in a Registration Reply. And if it hasn't already gotten one, either in a Registration Reply or a recent advertisement, it MUST solicit for one 🙏.
Last but not least, the error code stuff 🚨. If the foreign agent receives a Registration Reply with the Code value ha_bad_aaa_auth, that Registration Reply with this Code value MUST be relayed to the mobile node. In this document, whenever the foreign agent is required to reject a Registration Request, it MUST put the given code in the usual Code field of the Registration Reply. The exception is when the Registration Reply has already come in from the home agent. Then the foreign agent MUST preserve the value of the Code field set by the home agent, and MUST put its own rejection code in the Status field of the FA Error extension (defined in [RFC4636]). Respect the home agent's code, bestie 🫶.
3.4. Home Agent Processing of Challenge Extensions 🧚
If the home agent gets a Registration Request with the Mobile-Foreign Challenge extension and recognizes the extension, the home agent MUST include the Challenge extension in the Registration Reply. The Challenge extension MUST be placed after the Mobile-Home authentication extension, and the extension SHOULD be authenticated by a Foreign-Home Authentication extension 🔐.
The home agent might also get a Registration Request with the Mobile-AAA Authentication extension. If the home agent uses the Mobile-AAA Authentication extension as an authorization-enabling extension, and verification fails because of an incorrect authenticator, the home agent MAY reject the Registration Reply with the error code ha_bad_aaa_auth 🙅♀️.
Here's the thing: the extension type for the Challenge extension is in the range 128-255. So the home agent MUST process such a Registration Request even if it doesn't recognize the Challenge extension [RFC3344] 🥹. In that case, the home agent sends a Registration Reply to the foreign agent that does not include the Challenge extension. Ate that for the home agent, no notes 💅.
3.5. Mobile Node Processing of Registration Replies 📱
A mobile node might get an error code in the Registration Reply from the foreign agent as a response to its Registration Request. The error codes are defined in Section 10 💀.
Either way, if the mobile node tries to register again after an error like that, it MUST use a new Challenge value in that registration. It can get that value either from an Agent Advertisement, or from a Challenge extension in the Registration Reply that had the error 🔄.
In the co-located care-of address mode, the mobile node gets a Registration Reply without the Challenge extension, and it processes that Registration Reply as specified in [RFC3344]. In this case, if the mobile node includes the MN-AAA Authentication Extension, the Challenge value 0 is recommended for the authenticator computation mentioned in Section 8 🍓.
4. Mobile-Foreign Challenge Extension 🎀
This section specifies a new Mobile IP Registration extension that's used to satisfy a Challenge in an Agent Advertisement. The Challenge extension to the Registration Request message is used to indicate the challenge that the mobile node is trying to satisfy 💜.
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 | Length | Challenge ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2. The Mobile-Foreign Challenge ExtensionType: 132 (skippable). (See [RFC3344]).
Length: Length of the Challenge value.
Challenge: The Challenge field is copied from the Challenge field found in the received Challenge extension.
Okay, here's the rule 📜. Say the mobile node has successfully registered using one of the Challenge Values within the CHALLENGE_WINDOW values advertised by the foreign agent. Then, in any new Registration Request, the mobile node MUST NOT use any Challenge Value that was advertised by the foreign agent before the Challenge Value in the mobile node's last Registration Request. No going back to old challenges, periodt 🚫.
5. Generalized Mobile IP Authentication Extension 🔑
Several new authentication extensions have been designed for various control messages proposed for extensions to Mobile IP. A new authentication extension is required for a mobile node to present its credentials to any entity other than the ones already defined. The only entities defined in the base Mobile IP specification [RFC3344] are the home agent and the foreign agent. The point of the generalized authentication extension defined here is to collect all of that data for these new authentication applications into a single extension type with subtypes 🧩.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authenticator ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3. The Generalized Mobile IP Authentication ExtensionType: 36 (not skippable). (See [RFC3344]).
Subtype: A number assigned to identify the kind of endpoints or other characteristics of the particular authentication strategy.
Length: 4 plus the number of octets in the Authenticator; MUST be at least 20.
SPI: Security Parameters Index
Authenticator: The variable length Authenticator field
In this document, only one subtype is defined:
1 Mobile-AAA Authentication subtype
(Hashed Message Authentication Code-MD5 (HMAC-MD5))
(see Section 6).6. Mobile-AAA Authentication Subtype 🦋
The Generalized Authentication extension with subtype 1 is referred to as a Mobile-AAA Authentication extension. The mobile node MAY include a Mobile-AAA Authentication extension in any Registration Request. This extension MAY co-exist in the same Registration Request with Authentication extensions defined for Mobile IP Registration ([RFC3344]). If the mobile node doesn't include a Mobile-Foreign Authentication extension, then it MUST include the Mobile-AAA Authentication extension whenever the Challenge extension is present. If both are present, the Mobile-AAA Authentication extension MUST precede the Mobile-Foreign Authentication extension 🧁.
If the Mobile-AAA Authentication extension is present, the Mobile-Home Authentication extension MUST appear prior to the Mobile-AAA Authentication extension. The corresponding response MUST include the Mobile-Home Authentication extension and MUST NOT include the Mobile-AAA Authentication extension 🙅♀️.
The default algorithm for computing the authenticator is HMAC-MD5 [RFC2104], computed on the following data, in the order shown:
Preceding Mobile IP data || Type, Subtype, Length, SPIWhere the Type, Length, Subtype, and SPI are as shown in Section 5. The Preceding Mobile IP data refers to the UDP payload (the Registration Request or Registration Reply data) and all prior extensions in their entirety. The resulting function call, as described in [RFC2104], would be:
hmac_md5(data, datalen, Key, KeyLength, authenticator);Each mobile node MUST support the ability to produce the authenticator by using HMAC-MD5 as shown. Just as with Mobile IP, it must be possible to configure the use of any arbitrary 32-bit SPI outside of the SPIs in the reserved range 0-255 for selection of this default algorithm 🔐✨.
7. Reserved SPIs for Mobile IP 🌸
Mobile IP defines several authentication extensions for use in Registration Requests and Replies. Each authentication extension carries a Security Parameters Index (SPI) that should be used to index a table of security associations. Values in the range 0-255 are reserved for special use. A list of reserved SPI numbers is to be maintained by IANA at the following URL:
http://www.iana.org/assignments/mobileip-numbers8. SPIs for RADIUS AAA Servers ✨
okay so some AAA servers only admit a single security association 💅 which means they don't really use the SPI numbers for the Mobile IP authentication extensions to figure out which security association applies when they check the authentication info in the Authentication extension. 🫶
SPI number CHAP_SPI (see Section 9) is reserved for a procedure that computes the authentication data (called the "authenticator") 🔐. Lots of RADIUS servers use this one today [RFC2865] 🌸
To compute the authenticator, you apply MD5 [RFC1321] to the following data, in this order:
High-order octet from Challenge || Key ||
MD5(Preceding Mobile IP data ||
Type, Subtype (if present), Length, SPI) ||
Least-order 237 octets from ChallengeHere, Type, Length, SPI, and maybe Subtype are the fields of the authentication extension you're using. For example, when SPI == CHAP_SPI is used with the Generalized Authentication extension, all four of those fields show up 🎀 When the co-located care-of address is in play, the Challenge value is 0 (check out Section 3.5 for that 🧚).
RADIUS can't carry attributes longer than 253 octets, so the preceding Mobile IP data, Type, Subtype (if present), Length, and SPI all get hashed with MD5 first ✨ After that, you tack on the least significant 237 octets of the challenge. If the challenge has fewer than 238 octets, the high-order octet gets counted twice in the computation, but the challenge still gets used exactly as it is 🙈 Padding is never added to make the challenge longer, and the input data is allowed to be shorter than 237 octets. no padding drama here 💅
9. Configurable Parameters 🍓
Every Mobile IP agent that supports the extensions in this document SHOULD be able to configure each parameter in the table below. Each entry has the parameter's name, its default value, and the section where the parameter first shows up 📋
+------------------+---------------+---------------------+
| Parameter Name | Default Value | Section of Document |
+------------------+---------------+---------------------+
| CHALLENGE_WINDOW | 2 | 3.2 |
| | | |
| CHAP_SPI | 2 | 8 |
+------------------+---------------+---------------------+
Table 1. Configurable ParametersQuick note 💖 CHALLENGE_WINDOW SHOULD be at least 2. This makes it way less likely that mobile nodes register with a Challenge value the foreign agent doesn't allow. Main character energy for the foreign agent 👑
10. Error Values 💀
Each row below has the name of the Code [RFC3344] that gets returned in a Registration Reply, the value of that Code, and the section where this spec mentions the error 🌈
+--------------------+-------+--------------------------+
| Error Name | Value | Section of Document |
+--------------------+-------+--------------------------+
| unknown_challenge | 104 | 3.2 |
| | | |
| mobile node failed | 67 | 3.2; also see [RFC3344] |
| authentication | | |
| | | |
| missing_challenge | 105 | 3.1, 3.2 |
| | | |
| stale_challenge | 106 | 3.2 |
| | | |
| fa_bad_aaa_auth | 108 | 3.2 |
| | | |
| ha_bad_aaa_auth | 144 | 3.4 |
| | | |
| ha_wrong_challenge | 109 | 3.2 |
+--------------------+-------+--------------------------+
Table 2. Error Values11. IANA Considerations 🦋
IANA has already assigned the following for RFC 3012 [RFC3012], and they apply to this document too. IANA recorded these values as part of this document 📝
- Generalized Mobile IP Authentication extension (Section 5): this is a Mobile IP registration extension, and IANA assigned it the value 36 🎀
- Generalized Authentication extension subtypes: a new number space is being created to enumerate them (see Section 5). Any new subtype other than the number (1), which is for the MN-AAA authentication extension in Section 6, must be specified and approved by a designated expert 🔥
- Mobile Node - Foreign Agent (MN-FA) Challenge extension (Section 4): this is a router advertisement extension, as defined in RFC 1256 [RFC1256] and extended in RFC 3344 [RFC3344]. IANA assigned it the value 132 🌸
- Error codes (Section 10): these are error codes as defined in RFC 3344 ([RFC3344]). They match error values usually tied to rejection by the foreign agent (basically the range 64-127). The Code value 67 was already around and gets used in some cases with the extension in this spec. IANA recorded the values as defined in Section 10 ✨
- SPIs in the range 0-255: IANA added a new section for enumerating algorithms that are identified by specific SPIs in this range.
CHAP_SPI(number 2, from Section 8) comes from this reserved range. New assignments from this reserved range must be specified and approved by the Mobile IP working group. SPI number 1 should not be assigned unless the Mobile IP working group someday decides that SKIP isn't important for enumeration in the list of reserved numbers. SPI number 0 should not be assigned 🧚
Also, this document defines the new error codes fa_bad_aaa_auth, ha_bad_aaa_auth, and ha_wrong_challenge. Out of those, ha_wrong_challenge may show up in the Status code of the FA Error extension, which is defined in [RFC4636] 💜
12. Security Considerations 🔐
⚠️ This section is serious business, bestie. Read it carefully.
If a malicious mobile node tries to replay the authenticator for an old Mobile-Foreign Challenge, the foreign agent catches it 🚨 The agent always checks whether it has recently advertised the Challenge (see Section 3.2). Letting mobile nodes with different IP addresses or NAIs use the same Challenge value is not a security vulnerability. The authentication data from the mobile node gets computed over data that's different (at the very least, the mobile node's IP address changes) 💖
If the foreign agent picks a Challenge value with fewer than 4 octets (see Section 2), the foreign agent SHOULD include the value of the Identification field in the records it keeps for the mobile node 📚 That way the foreign agent can check whether the Registration messages using the short Challenge value are actually unique, and so definitely not replayed from an earlier registration 🕵️♀️
Section 8 (SPI For RADIUS AAA Servers) defines a way to compute the Generalized Mobile IP Authentication extension's authenticator field. It uses MD5 in a manner that's consistent with RADIUS [RFC2865]. The MD5 method in Section 8 is less secure than HMAC-MD5 [RFC2104], so it MUST be avoided whenever possible 🙅♀️ This is non-negotiable, bestie.
Heads up 👀 an active attacker might try to block successful registrations by sending a ton of Agent Solicitations or bogus Registration Requests. Each one could make the foreign agent answer with a fresh challenge, which invalidates the challenge the MN is currently trying to use. To stop these attacks, the foreign agent MUST NOT invalidate previously unused challenges when it responds to unauthenticated Registration Requests or Agent Solicitations. The foreign agent also MUST NOT allocate new storage when it responds to those messages, because that would open up the possibility of denial of service 😭
The Challenge extension in this document doesn't need to be used for the co-located care-of address mode. In that case, replay protection comes from the Identification field in the Registration Request message [RFC3344] 🦋
The Generalized Mobile IP Authentication extension has a subtype field that identifies the characteristics of the particular authentication strategy. This document only defines one subtype, the Mobile-AAA Authentication subtype, which uses HMAC-MD5. If a new message authentication algorithm is ever needed, a new subtype that uses a different one could be defined 🌈
13. Acknowledgements 🫶
The authors want to thank Pete McCann, Ahmad Muhanna, Henrik Levkowetz, Kent Leung, Alpesh Patel, Madjid Nakhjiri, Gabriel Montenegro, Jari Arkko, and the other MIP4 WG participants for their useful discussions 💜
14. Normative References 📚
[RFC1256] Deering, S., "ICMP Router Discovery Messages", RFC 1256,
September 1991.
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
April 1992.
[RFC1994] Simpson, W., "PPP Challenge Handshake Authentication
Protocol (CHAP)", RFC 1994, August 1996.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, February
1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)", RFC
2865, June 2000.
[RFC2794] Calhoun, P. and C. Perkins, "Mobile IP Network Access
Identifier Extension for IPv4", RFC 2794, March 2000.
[RFC3012] Perkins, C. and P. Calhoun, "Mobile IPv4
Challenge/Response Extensions", RFC 3012, November 2000.
[RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344,
August 2002.
[RFC4086] Eastlake, D., 3rd, Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086,
June 2005.
[RFC4636] Perkins, C., "Foreign Agent Error Extension for Mobile
IPv4", RFC 4636, October 2006.Appendix A. Changes since RFC 3012 ✨
okay so Appendix A is basically the changelog, and it's giving glow-up 💅 Here's everything that changed since [RFC3012]:
- The foreign agent is recommended to include a Challenge in every Registration Reply, so the mobile node can re-register without waiting for an Advertisement 🦋
- The foreign agent MUST record the applicable challenge values used by each mobile node 🔥
- The mobile node is forbidden from using Challenge values that were advertised before the last Challenge value it had used for a registration 🙈
- Challenge definitions got cleaned up 🧹✨
- A programming suggestion was added as an appendix 🍓
- The
HMAC_CHAP_SPIoption was added to the Generalized Mobile IP Authentication extension. WhenHMAC_CHAP_SPIis received,HMAC-MD5is used instead ofMD5for computing the authenticator 👑 - The error codes
fa_bad_aaa_authandha_bad_aaa_authwere added to report authentication errors caused while processing the Mobile-AAA Authentication extension. The error codeha_wrong_challengewas also added, to indicate that the Challenge value in the Registration Reply from the home agent differs from the one sent to the home agent in the Registration Request 😭 - Processing of the Mobile-AAA Authentication extension is clarified for the foreign agent and the home agent 💜
- Co-existence of the Mobile-AAA Authentication extension in the same Registration Request is made explicit 🌈
- The situation in which the foreign agent sets
missing_challengeis clarified further 🧚 - The mobile node is now allowed to use the Mobile-AAA Authentication extension with a co-located care-of address 🫶
- Protection against bogus Registration Reply and Agent Advertisement was added. The processing of the Challenge is also clarified if it is received in the multicast/unicast Agent Advertisement 🛡️
- The FA Error extension reference was added to the References section, and the relevant text in section 3.2 and section 11 was updated too 🎀
Appendix B. Verification Infrastructure 🔐
okay bestie, so the Challenge extensions in this protocol are expected to be really useful for the foreign agent when it's managing connectivity for visiting mobile nodes. This works even when the foreign agent has no security association with the mobile node or the mobile node's home agent 💖 To do the authentication, the foreign agent will probably need help from external administrative systems, which people have started calling AAA systems. In this document, we call that external admin support the "verification infrastructure" ✨
The verification infrastructure is described to explain why the protocol elements in this document are designed the way they are. It is not strictly needed for the protocol to work 🌸 The foreign agent is free to use whatever means it has to verify the mobile node's credentials. For example, it could rely on a separate protocol between the foreign agent and the Mobile IP home agent, and it still wouldn't require any modification to the mobile node 🦋
To verify the mobile node's credentials, we assume the foreign agent can reach a verification infrastructure that can send back a secure notification saying the authentication was performed, along with the results. Picture it like this (Figure 4) 👑
+----------------------------------------------------+
| |
| Verification and Key Management Infrastructure |
| |
+----------------------------------------------------+
^ | ^ |
| | | |
| v | v
+---------------+ +---------------+
| | | |
| foreign agent | | home agent |
| | | |
+---------------+ +---------------+
Figure 4. The Verification InfrastructureOnce the foreign agent gets the Challenge authentication, it MAY pass the authentication to the (here unspecified) infrastructure and wait for a Registration Reply 💅 If the Reply has a positive status, which means the registration was accepted, the foreign agent accepts the registration ✅ If the Reply contains the Code value BAD_AUTHENTICATION (see Section 10), the foreign agent takes the actions listed for rejected registrations 😭
The important thing to notice here is that the foreign agent and the home agent both have to be able to use whatever protocol the challenge verification and key management infrastructure in the figure requires 🔥
The protocol messages used for authentication inside the verification infrastructure, and the identity of the agent doing the foreign agent challenge verification, are not specified in this document. That's because none of those operations have to be performed by any Mobile IP entity 🧚
Appendix C. Message Flow for FA Challenge Messaging with Mobile-AAA Extension 🦋
here's the message flow for FA Challenge messaging with the Mobile-AAA extension. Check out Figure 5 below 💜
MN FA Verification home agent
|<-- Adv+Challenge--| Infrastructure |
| (if needed) | | |
| | | |
|-- RReq+Challenge->| | |
| + Auth.Ext. | | |
| | Auth. Request, incl. | |
| |--- RReq + Challenge --->| |
| | + Auth.Ext | RReq + |
| | |-- Challenge -->|
| | | |
| | | |
| | |<--- RRep ----- |
| | Authorization, incl. | |
| |<-- RRep + Auth.Ext.-----| |
| | | |
|<-- RRep+Auth.Ext--| | |
| + New Challenge | | |
Figure 5. Message Flows for FA Challenge MessagingIn Figure 5, this informational message flow is illustrated:
- The foreign agent includes a Challenge Value in a unicast Agent Advertisement, if needed. This advertisement MAY have been produced after receiving an Agent Solicitation from the mobile node (not shown in the diagram) 🌟
- The mobile node creates a Registration Request that includes the advertised Challenge Value in the Challenge extension, along with a Mobile-AAA authentication extension 🎀
- The foreign agent relays the Registration Request either to the home agent specified by the mobile node or to its locally configured Verification Infrastructure (see Appendix B), according to local policy 🍓
- The foreign agent receives a Registration Reply with the appropriate indications for authorizing connectivity for the mobile node 💖
- The foreign agent relays the Registration Reply to the mobile node, often along with a new Challenge Value to be used by the mobile node in its next Registration Request message 🫶
Appendix D. Message Flow for FA Challenge Messaging with MN-FA Authentication 🌈
next up is the message flow for FA Challenge messaging with MN-FA authentication. Figure 6 is the one to look at 👀
MN FA home agent
|<-- Adv+Challenge--| |
| (if needed) | |
| | |
|-- RReq+Challenge->| |
| + Auth.Ext. | |
| |--- RReq + Challenge --->|
| | + HA-FA Auth.Ext |
| | |
| |<-- RRep + Challenge ----|
| | + HA-FA Auth.Ext |
| | |
|<-- RRep+Auth.Ext--| |
| + New Challenge | |
Figure 6. Message Flows for FA Challenge Messaging with MN-FA
AuthenticationIn Figure 6, this informational message flow is illustrated:
- The foreign agent disseminates a Challenge Value in an Agent Advertisement, if needed. This advertisement MAY have been produced after receiving an Agent Solicitation from the mobile node (not shown in the diagram) 📡
- The mobile node creates a Registration Request that includes the advertised Challenge Value in the Challenge extension, along with a Mobile-Foreign Authentication extension 💅
- The foreign agent relays the Registration Request to the home agent specified by the mobile node 🦋
- The foreign agent receives a Registration Reply with the appropriate indications for authorizing connectivity for the mobile node 🌸
- The foreign agent relays the Registration Reply to the mobile node, possibly along with a new Challenge Value to be used by the mobile node in its next Registration Request message. If the Reply contains the Code value
ha_bad_aaa_auth(see Section 10), the foreign agent takes the actions listed for rejected registrations 😭
Appendix E. Example Pseudo-Code for Tracking Used Challenges 🧠
last one! here's some example pseudo-code showing how to keep track of the challenges that were already used ✨
current_chal := RegistrationRequest.challenge_extension_value
last_chal := mobile_node_record.last_used_adv_chal
if (current_chal == mobile_node_record.RegReply_challenge) {
update (mobile_node_record, current_chal)
return (OK)
}
else if (current_chal "among" VALID_ADV_CHALLENGES[]{
if (last_chal "among" VALID_ADV_CHALLENGES[]) {
if (current_chal is "before" last_chal) {
send_error(STALE_CHALLENGE)
return (FAILURE)
}
else {
update (mobile_node_record, current_chal)
return (OK)
}
}
else {
update (mobile_node_record, current_chal)
return (OK)
}
}
else {
send_error(UNKNOWN_CHALLENGE);
}Authors' Addresses 💌
the authors, and how to reach them 🫶
Charles E. Perkins
Nokia Research Center
Communications Systems Lab
313 Fairchild Drive
Mountain View, California 94043
Phone: +1 650 625-2986
EMail: charles.perkins@nokia.com
Pat R. Calhoun
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134
Phone: +1 408-853-5269
EMail: pcalhoun@cisco.com
Jayshree Bharatia
Nortel Networks
2221, Lakeside Blvd
Richardson, TX 75082
Phone: +1 972-684-5767
EMail: jayshree@nortel.comFull Copyright Statement 💅
Copyright (C) The IETF Trust (2007). 🎀
This document is under the rules in BCP 78. Except for what those rules say, the authors keep all of their rights. 🦋
Okay, real talk, this next part is the legal stuff, but it matters. The document and everything in it is handed over "AS IS". The contributor, whatever organization they represent or are sponsored by, the Internet Society, the IETF Trust, and the Internet Engineering Task Force all say no to every warranty, express or implied. That includes no promise that using the info won't infringe anybody's rights, and no implied promise of merchantability or fitness for a particular purpose. 🙅♀️💀
Intellectual Property 🌸
Ngl, the IETF doesn't claim to know whether any intellectual property rights apply to the tech in this doc, or whether you can get a license to use it. It also hasn't gone looking for any. 🕵️♀️ If you want the rules on RFC documents and rights, check out BCP 78 and BCP 79. 📚
Copies of IPR disclosures sent to the IETF Secretariat live in the IETF online IPR repository at http://www.ietf.org/ipr. The same goes for any license assurances, and for the results of anyone trying to get a general license or permission to use the proprietary rights. Implementers and users can look there. 🔍✨
The IETF also invites anyone to flag copyrights, patents, patent applications, or other proprietary rights that might cover technology needed to implement this standard. Send those to the IETF at ietf-ipr@ietf.org. Bestie, speak up if you spot something! 📣🫶
Acknowledgement 🧚
Funding for the RFC Editor function is currently coming from the Internet Society. Thank you, Internet Society, you're literally keeping the lights on for all of these RFCs. 🌈👑
📦 where this page comes from
- ietf: rfc4721 2007-01
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms