doc: Add RFC documents

1 files changed, 1459 insertions, 0 deletions

diff --git a/doc/rfc/rfc4721.txt b/doc/rfc/rfc4721.txt
new file mode 100644
index 0000000..1231ecf
--- /dev/null
+++ b/doc/rfc/rfc4721.txt
@@ -0,0 +1,1459 @@
+
+
+
+
+
+
+Network Working Group                                         C. Perkins
+Request for Comments: 4721                         Nokia Research Center
+Obsoletes: 3012                                               P. Calhoun
+Updates: 3344                                        Cisco Systems, Inc.
+Category: Standards Track                                    J. Bharatia
+                                                         Nortel Networks
+                                                            January 2007
+
+
+          Mobile IPv4 Challenge/Response Extensions (Revised)
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The IETF Trust (2007).
+
+Abstract
+
+   Mobile IP, as originally specified, defines an authentication
+   extension (the Mobile-Foreign Authentication extension) by which a
+   mobile node can authenticate itself to a foreign agent.
+   Unfortunately, that extension does not provide the foreign agent any
+   direct guarantee that the protocol is protected from replays and does
+   not allow for the use of existing techniques (such as Challenge
+   Handshake Authentication Protocol (CHAP)) for authenticating portable
+   computer devices.
+
+   In this specification, we define extensions for the Mobile IP Agent
+   Advertisements and the Registration Request that allow a foreign
+   agent to use a challenge/response mechanism to authenticate the
+   mobile node.
+
+   Furthermore, this document updates RFC 3344 by including a new
+   authentication extension called the Mobile-Authentication,
+   Authorization, and Accounting (AAA) Authentication extension.  This
+   new extension is provided so that 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.  This
+   document obsoletes RFC 3012.
+
+
+
+Perkins, et al.             Standards Track                     [Page 1]
+
+RFC 4721       Mobile IPv4 Challenge/Response Extensions    January 2007
+
+
+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 ......24
+
+1.  Introduction
+
+   Mobile IP defines the Mobile-Foreign Authentication extension to
+   allow a mobile node to authenticate itself to a foreign agent.  Such
+   authentication mechanisms are mostly external to the principal
+   operation of Mobile IP, since the foreign agent can easily route
+   packets to and from a mobile node whether or not the mobile node is
+   reporting a legitimately owned home address to the foreign agent.
+   Unfortunately, that extension does not provide the foreign agent any
+   direct guarantee that the protocol is protected from replays and does
+   not allow for the use of CHAP [RFC1994] for authenticating portable
+   computer devices.  In this specification, we define extensions for
+   the Mobile IP Agent Advertisements and the Registration Request that
+   allow a foreign agent to use a challenge/ response mechanism to
+   authenticate the mobile node.  Furthermore, an additional
+
+
+
+Perkins, et al.             Standards Track                     [Page 2]
+
+RFC 4721       Mobile IPv4 Challenge/Response Extensions    January 2007
+
+
+   authentication extension, the Mobile-AAA authentication extension, is
+   provided so that 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 obtain a
+   secure indication that the mobile node is authorized to use the local
+   network resources.
+
+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].  All
+   SPI values defined in this document refer to values for the SPI as
+   defined in that specification.
+
+   The following additional terminology is used in addition to that
+   defined 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.
+
+
+
+
+Perkins, et al.             Standards Track                     [Page 3]
+
+RFC 4721       Mobile IPv4 Challenge/Response Extensions    January 2007
+
+
+2.  Mobile IP Agent Advertisement Challenge Extension
+
+   This section defines a new extension to the Router Discovery Protocol
+   [RFC1256] for use by 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 Extension
+
+   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, illustrated in Figure 1, is inserted in the
+   Agent Advertisements by the foreign agent in order to communicate a
+   previously unused challenge value that can be used by the mobile node
+   to compute an authentication for its next registration request
+   message.  The challenge is selected by the foreign agent to provide
+   local assurance that the mobile node is not replaying any earlier
+   registration request.  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
+
+   When a foreign agent generates an Agent Advertisement in response to
+   a Router Solicitation [RFC1256], some additional considerations come
+   into play.  According to the Mobile IP base specification [RFC3344],
+   the resulting Agent Advertisement may be either multicast or unicast.
+
+
+
+
+
+Perkins, et al.             Standards Track                     [Page 4]
+
+RFC 4721       Mobile IPv4 Challenge/Response Extensions    January 2007
+
+
+   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
+
+   Retransmission behavior for Registration Requests is identical to
+   that specified in Mobile IP specification [RFC3344].  A retransmitted
+   Registration Request MAY use the same Challenge value as given in the
+   original Registration Request.
+
+   Whenever the Agent Advertisement contains the Challenge extension, if
+   the mobile node does not have a security association with the foreign
+   agent, then it MUST include the Challenge value in a Mobile-Foreign
+   Challenge extension to the Registration Request message.  If, on the
+   other hand, the mobile node does have a security association with the
+   foreign agent, it SHOULD 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, according to the base Mobile IP
+   specification [RFC3344].  When the Registration Request contains the
+   Mobile-Foreign Challenge extension specified in Section 4, the
+   Mobile-Foreign Authentication MUST follow the Challenge extension in
+   the Registration Request.  The mobile node MAY also include the
+   Mobile-AAA Authentication extension.
+
+
+
+
+
+Perkins, et al.             Standards Track                     [Page 5]
+
+RFC 4721       Mobile IPv4 Challenge/Response Extensions    January 2007
+
+
+   If both the Mobile-Foreign Authentication and the Mobile-AAA
+   Authentication extensions are present, 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, when it includes
+   the Mobile-Foreign Challenge extension.  In addition, the mobile node
+   SHOULD include the NAI extension [RFC2794] to enable the foreign
+   agent to make use of available verification infrastructure that
+   requires this.  The SPI field of the Mobile-AAA Authentication
+   extension specifies the particular secret and algorithm (shared
+   between the mobile node and the verification infrastructure) that
+   must be used to perform 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].
+
+   In either case, the Mobile-Foreign Challenge extension followed by
+   one of the above specified authentication extensions MUST follow the
+   Mobile-Home Authentication extension, if present.
+
+   A mobile node MAY include the Mobile-AAA Authentication extension in
+   the Registration Request when the mobile node 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 MUST NOT include the Mobile-Foreign
+   Challenge extension.  Also, replay protection for the Registration
+   Request in this case is provided by the Identification field defined
+   by [RFC3344].
+
+3.2.  Foreign Agent Processing of Registration Requests
+
+   Upon receipt of the Registration Request, if the foreign agent has
+   issued a Challenge as part of its Agent Advertisements, and if 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 previously
+   unused by the mobile node.  This ensures that the mobile node is not
+   attempting to replay a previous advertisement and authentication.  In
+   this case, if the Registration Request does not include a Challenge
+   extension, the foreign agent MUST send a Registration Reply with the
+   Code field set to missing_challenge.
+
+
+
+
+
+
+Perkins, et al.             Standards Track                     [Page 6]
+
+RFC 4721       Mobile IPv4 Challenge/Response Extensions    January 2007
+
+
+   If a mobile node retransmits a Registration Request with the same
+   Challenge extension, and if the foreign agent still has a pending
+   Registration Request record in effect for the 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
+   actually performing a retransmission, by verifying that the relevant
+   fields of the retransmitted request (including, if present, the
+   mobile node NAI extension [RFC2794]) are the same as represented 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, since those values are likely to change even
+   for requests that are merely retransmissions and not new Registration
+   Requests.  In all other circumstances, if the foreign agent receives
+   a Registration Request with a Challenge extension containing a
+   Challenge value previously used by that mobile node, 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 is not one of the recently advertised values, the foreign
+   Agent SHOULD send a Registration Reply with Code value
+   unknown_challenge (see Section 10).  The foreign agent MUST maintain
+   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, see Section 3.2.1 for a possible
+   algorithm that can be used to satisfy 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 containing 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 Code value mobile node
+   failed authentication (see Section 10).
+
+   If the Mobile-AAA Authentication extension (see Section 6) is present
+   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
+
+
+
+Perkins, et al.             Standards Track                     [Page 7]
+
+RFC 4721       Mobile IPv4 Challenge/Response Extensions    January 2007
+
+
+   of the mobile node.  If the registration message contains 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 Code value fa_bad_aaa_auth.  If the Mobile-
+   AAA Authentication extension is present in the Registration Request,
+   the foreign agent MUST NOT remove the Mobile-AAA Authentication
+   extension and the Mobile-Foreign Challenge extension from the
+   Registration Request before forwarding to the home agent.  Appendix C
+   provides an example of an action that could be taken by a foreign
+   agent.
+
+   In the event that the Challenge extension is authenticated through
+   the Mobile-Foreign Authentication extension and the Mobile-AAA
+   Authentication extension is not present, the foreign agent MAY remove
+   the Challenge extension from the Registration Request without
+   disturbing 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
+   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 information about the
+   particular mobile node in order to protect against replays.
+
+3.2.1.  Foreign Agent Algorithm for Tracking Used Challenges
+
+   If the foreign agent maintains a large CHALLENGE_WINDOW, it becomes
+   more important for scalability purposes to compare incoming
+   challenges efficiently against the set of Challenge values that have
+   been advertised recently.  This can be done by keeping the Challenge
+   values in order of advertisement, and by making use of the mandated
+   behavior that mobile nodes MUST NOT use Challenge values that were
+   advertised before the last advertised Challenge value that the mobile
+   node attempted to use.  The pseudo-code in Appendix E accomplishes
+   this objective.  The maximum amount of total storage required by this
+   algorithm is equal to Size*(CHALLENGE_WINDOW + (2*N)), where N is the
+   current number of mobile nodes for which the foreign agent is storing
+   challenge values.  Note that whenever the stored challenge value is
+   no longer in the CHALLENGE_WINDOW, it can be deleted from the foreign
+   agent's records, perhaps along with all other registration
+   information for the mobile node if it is no longer registered.
+
+
+
+
+
+
+
+Perkins, et al.             Standards Track                     [Page 8]
+
+RFC 4721       Mobile IPv4 Challenge/Response Extensions    January 2007
+
+
+   It is presumed that the foreign agent keeps an array of advertised
+   Challenges, a record of the last advertised challenge used by a
+   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 responding 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
+
+   The foreign agent SHOULD include a new Mobile-Foreign Challenge
+   extension in any Registration Reply, successful or not.  If the
+   foreign agent includes this extension in a successful Registration
+   Reply, the extension SHOULD precede a Mobile-Foreign authentication
+   extension if present.  Suppose that the Registration Reply includes a
+   Challenge extension from the home agent, and that the foreign agent
+   wishes to include another Challenge extension with the Registration
+   Reply for use by the mobile node.  In that case, the foreign agent
+   MUST delete the Challenge extension from the home agent from the
+   Registration Reply, along with any Foreign-Home authentication
+   extension, before appending the new Challenge extension to the
+   Registration Reply.
+
+   One example of a situation where the foreign agent MAY omit the
+   inclusion of a Mobile-Foreign Challenge extension in the Registration
+   Reply would be when a new challenge has been multicast recently.
+
+   If a foreign agent has conditions in which it omits the inclusion of
+   a Mobile-Foreign Challenge extension in the Registration Reply, it
+   still MUST respond with an agent advertisement containing a
+   previously unused challenge in response to a subsequent agent
+   solicitation from the same mobile node.  Otherwise (when the said
+   conditions are not met), the foreign agent MUST include a previously
+   unused challenge in any Registration Reply, successful or not.
+
+   If the foreign agent does not remove the Challenge extension from the
+   Registration Request received 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
+   coming from the home agent does not include the Challenge extension,
+   the foreign agent SHOULD NOT reject the registration request.  If the
+   Challenge extension is present in the Registration Reply, it MUST be
+   the same Challenge value that was included in the Registration Reply
+
+
+
+Perkins, et al.             Standards Track                     [Page 9]
+
+RFC 4721       Mobile IPv4 Challenge/Response Extensions    January 2007
+
+
+   received from the home agent, 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).
+
+   A mobile node MUST be prepared to use a challenge from a unicast or
+   multicast Agent Advertisement in lieu of one returned in a
+   Registration Reply, and it MUST solicit for one if it has not already
+   received one either in a Registration Reply or a recent
+   advertisement.
+
+   If the foreign agent receives a Registration Reply with the Code
+   value ha_bad_aaa_auth, the 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,
+   unless the Registration Reply has already been received from the home
+   agent.  In this case, 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]).
+
+3.4.  Home Agent Processing of Challenge Extensions
+
+   If the home agent receives 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 may receive a Registration Request with the Mobile-AAA
+   Authentication extension.  If the Mobile-AAA Authentication extension
+   is used by the home agent as an authorization-enabling extension and
+   the verification fails due to an incorrect authenticator, the home
+   agent MAY reject the Registration Reply with the error code
+   ha_bad_aaa_auth.
+
+   Since the extension type for the Challenge extension is within the
+   range 128-255, the home agent MUST process such a Registration
+   Request even if it does not recognize the Challenge extension
+   [RFC3344].  In this case, the home agent will send a Registration
+   Reply to the foreign agent that does not include the Challenge
+   extension.
+
+
+
+
+
+
+
+
+Perkins, et al.             Standards Track                    [Page 10]
+
+RFC 4721       Mobile IPv4 Challenge/Response Extensions    January 2007
+
+
+3.5.  Mobile Node Processing of Registration Replies
+
+   A mobile node might receive the error code in the Registration Reply
+   from the foreign agent as a response to the Registration Request.
+   The error codes are defined in Section 10.
+
+   In any case, if the mobile node attempts to register again after such
+   an error, it MUST use a new Challenge value in such a registration,
+   obtained either from an Agent Advertisement, or from a Challenge
+   extension to the Registration Reply containing the error.
+
+   In the co-located care-of address mode, the mobile node receives a
+   Registration Reply without the Challenge extension and processes the
+   Registration Reply as specified in [RFC3344].  In this case, when 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 is
+   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 attempting 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 Extension
+
+   Type:
+
+      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.
+
+   Suppose that the mobile node has successfully registered using one of
+   the Challenge Values within the CHALLENGE_WINDOW values advertised by
+
+
+
+Perkins, et al.             Standards Track                    [Page 11]
+
+RFC 4721       Mobile IPv4 Challenge/Response Extensions    January 2007
+
+
+   the foreign agent.  In that case, 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.
+
+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 other 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 purpose of
+   the generalized authentication extension defined here is to collect
+   together data for all such 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 Extension
+
+   Type:
+
+      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
+
+
+
+
+
+Perkins, et al.             Standards Track                    [Page 12]
+
+RFC 4721       Mobile IPv4 Challenge/Response Extensions    January 2007
+
+
+   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 will be
+   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 does not
+   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 computation of the authenticator is HMAC-
+   MD5 [RFC2104] computed on the following data, in the order shown:
+
+      Preceding Mobile IP data || Type, Subtype, Length, SPI
+
+   where 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.
+
+
+
+Perkins, et al.             Standards Track                    [Page 13]
+
+RFC 4721       Mobile IPv4 Challenge/Response Extensions    January 2007
+
+
+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-numbers
+
+8.  SPIs for RADIUS AAA Servers
+
+   Some AAA servers only admit a single security association and thus do
+   not use the SPI numbers for Mobile IP authentication extensions for
+   use when determining the security association that would be necessary
+   for verifying the authentication information included with the
+   Authentication extension.
+
+   SPI number CHAP_SPI (see Section 9) is reserved for indicating the
+   following procedure for computing authentication data (called the
+   "authenticator"), which is used by many RADIUS servers [RFC2865]
+   today.
+
+   To compute the authenticator, apply MD5 [RFC1321] computed on the
+   following data, in the order shown:
+
+      High-order octet from Challenge || Key ||
+
+      MD5(Preceding Mobile IP data ||
+
+      Type, Subtype (if present), Length, SPI) ||
+
+      Least-order 237 octets from Challenge
+
+   where Type, Length, SPI, and possibly Subtype are the fields of the
+   authentication extension in use.  For instance, all four of these
+   fields would be in use when SPI == CHAP_SPI is used with the
+   Generalized Authentication extension.  In case of co-located care-of
+   address, the Challenge value 0 is used (refer to Section 3.5).  Since
+   the RADIUS protocol cannot carry attributes of length greater than
+   253, the preceding Mobile IP data, type, subtype (if present),
+   length, and SPI are hashed using MD5.  Finally, the least significant
+   237 octets of the challenge are concatenated.  If the challenge has
+   fewer than 238 octets, this algorithm includes the high-order octet
+   in the computation twice but ensures that the challenge is used
+
+
+
+
+
+Perkins, et al.             Standards Track                    [Page 14]
+
+RFC 4721       Mobile IPv4 Challenge/Response Extensions    January 2007
+
+
+   exactly as is.  Additional padding is never used to increase the
+   length of the challenge; the input data is allowed to be shorter than
+   237 octets long.
+
+9.  Configurable Parameters
+
+   Every Mobile IP agent supporting the extensions defined in this
+   document SHOULD be able to configure each parameter in the following
+   table.  Each table entry contains the name of the parameter, the
+   default value, and the section of the document in which the parameter
+   first appears.
+
+      +------------------+---------------+---------------------+
+      | Parameter Name   | Default Value | Section of Document |
+      +------------------+---------------+---------------------+
+      | CHALLENGE_WINDOW | 2             | 3.2                 |
+      |                  |               |                     |
+      | CHAP_SPI         | 2             | 8                   |
+      +------------------+---------------+---------------------+
+
+                      Table 1.  Configurable Parameters
+
+   Note that CHALLENGE_WINDOW SHOULD be at least 2.  This makes it far
+   less likely that mobile nodes will register using a Challenge value
+   that is outside the set of values allowable by the foreign agent.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Perkins, et al.             Standards Track                    [Page 15]
+
+RFC 4721       Mobile IPv4 Challenge/Response Extensions    January 2007
+
+
+10.  Error Values
+
+   Each entry in the following table contains the name of the Code
+   [RFC3344] to be returned in a Registration Reply, the value for the
+   Code, and the section in which the error is mentioned in this
+   specification.
+
+      +--------------------+-------+--------------------------+
+      | 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 Values
+
+11.  IANA Considerations
+
+   The following are currently assigned by IANA for RFC 3012 [RFC3012]
+   and are applicable to this document.  IANA has recorded these values
+   as part of this document.
+
+      The Generalized Mobile IP Authentication extension defined in
+      Section 5 is a Mobile IP registration extension.  IANA has
+      assigned a value of 36 for this extension.
+
+      A new number space is to be created for enumerating subtypes of
+      the Generalized Authentication extension (see Section 5).  New
+      subtypes of the Generalized Authentication extension, other than
+      the number (1) for the MN-AAA authentication extension specified
+      in Section 6, must be specified and approved by a designated
+      expert.
+
+
+
+
+
+
+
+Perkins, et al.             Standards Track                    [Page 16]
+
+RFC 4721       Mobile IPv4 Challenge/Response Extensions    January 2007
+
+
+      The Mobile Node - Foreign Agent (MN-FA) Challenge extension,
+      defined in Section 4, is a router advertisement extension as
+      defined in RFC 1256 [RFC1256] and extended in RFC 3344 [RFC3344].
+      IANA has assigned a value of 132 for this purpose.
+
+      The Code values defined in Section 10 are error codes as defined
+      in RFC 3344 ([RFC3344]).  They correspond to error values
+      conventionally associated with rejection by the foreign agent
+      (i.e., values from the range 64-127).  The Code value 67 is a
+      pre-existing value that is to be used in some cases with the
+      extension defined in this specification.  IANA has recorded the
+      values as defined in Section 10.
+
+      A new section for enumerating algorithms identified by specific
+      SPIs within the range 0-255 has been added by IANA.  The CHAP_SPI
+      number (2) discussed in Section 8 is assigned from this range of
+      reserved SPI numbers.  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 in the future the
+      Mobile IP working group decides that SKIP is not important for
+      enumeration in the list of reserved numbers.  SPI number 0 should
+      not be assigned.
+
+   Additionally, the new error codes fa_bad_aaa_auth, ha_bad_aaa_auth,
+   and ha_wrong_challenge are defined by this document.  Among these,
+   ha_wrong_challenge may appear in the Status code of the FA Error
+   extension, defined in [RFC4636].
+
+12.  Security Considerations
+
+   In the event that a malicious mobile node attempts to replay the
+   authenticator for an old Mobile-Foreign Challenge, the foreign agent
+   would detect it, since the agent always checks whether it has
+   recently advertised the Challenge (see Section 3.2).  Allowing mobile
+   nodes with different IP addresses or NAIs to use the same Challenge
+   value does not represent a security vulnerability, as the
+   authentication data provided by the mobile node will be computed over
+   data that is different (at least the mobile node's IP address will
+   vary).
+
+   If the foreign agent chooses a Challenge value (see Section 2) with
+   fewer than 4 octets, the foreign agent SHOULD include the value of
+   the Identification field in the records it maintains for the mobile
+   node.  The foreign agent can then determine whether the Registration
+   messages using the short Challenge value are in fact unique and thus
+   assuredly not replayed from any earlier registration.
+
+
+
+
+
+Perkins, et al.             Standards Track                    [Page 17]
+
+RFC 4721       Mobile IPv4 Challenge/Response Extensions    January 2007
+
+
+   Section 8 (SPI For RADIUS AAA Servers) defines a method of computing
+   the Generalized Mobile IP Authentication extension's authenticator
+   field, using MD5 in a manner that is consistent with RADIUS
+   [RFC2865].  The use of MD5 in the method described in Section 8 is
+   less secure than HMAC-MD5 [RFC2104] and MUST be avoided whenever
+   possible.
+
+   Note that an active attacker may try to prevent successful
+   registrations by sending a large number of Agent Solicitations or
+   bogus Registration Requests, each of which could cause the foreign
+   agent to respond with a fresh challenge, invalidating the challenge
+   that the MN is currently trying to use.  To prevent such attacks, the
+   foreign agent MUST NOT invalidate previously unused challenges when
+   responding to unauthenticated Registration Requests or Agent
+   Solicitations.  In addition, the foreign agent MUST NOT allocate new
+   storage when responding to such messages, as this would also create
+   the possibility of denial of service.
+
+   The Challenge extension specified in this document need not be used
+   for co-located care-of address mode.  In this case, replay protection
+   is provided by the Identification field in the Registration Request
+   message [RFC3344].
+
+   The Generalized Mobile IP Authentication extension includes a subtype
+   field that is used to identify characteristics of the particular
+   authentication strategy.  This document only defines one subtype, the
+   Mobile-AAA Authentication subtype that uses HMAC-MD5.  If it is
+   necessary to move to a new message authentication algorithm in the
+   future, this could be accomplished by defining a new subtype that
+   uses a different one.
+
+13.  Acknowledgements
+
+   The authors would like to thank Pete McCann, Ahmad Muhanna, Henrik
+   Levkowetz, Kent Leung, Alpesh Patel, Madjid Nakhjiri, Gabriel
+   Montenegro, Jari Arkko, and 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.
+
+
+
+Perkins, et al.             Standards Track                    [Page 18]
+
+RFC 4721       Mobile IPv4 Challenge/Response Extensions    January 2007
+
+
+   [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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Perkins, et al.             Standards Track                    [Page 19]
+
+RFC 4721       Mobile IPv4 Challenge/Response Extensions    January 2007
+
+
+Appendix A.  Changes since RFC 3012
+
+   The following is the list of changes from RFC 3012 ([RFC3012]):
+
+   o  Foreign agent recommended to include a Challenge in every
+      Registration Reply, so that mobile node can re-register without
+      waiting for an Advertisement.
+
+   o  Foreign agent MUST record applicable challenge values used by each
+      mobile node.
+
+   o  Mobile node forbidden to use Challenge values which were
+      advertised previous to the last Challenge value which it had used
+      for a registration.
+
+   o  Challenge definitions are cleaned up.
+
+   o  Programming suggestion added as an appendix.
+
+   o  HMAC_CHAP_SPI option is added for Generalized Mobile IP
+      Authentication extension.  Upon receipt of HMAC_CHAP_SPI, HMAC-MD5
+      is used instead of MD5 for computing the authenticator.
+
+   o  Added fa_bad_aaa_auth and ha_bad_aaa_auth error codes to report
+      authentication errors caused while processing Mobile-AAA
+      Authentication extension.  Also, added the error code
+      ha_wrong_challenge to indicate that Challenge value differs in the
+      Registration Reply received from the home agent compare to the one
+      sent to the home agent in the Registration Request.
+
+   o  Processing of the Mobile-AAA Authentication extension is clarified
+      for the foreign agent and the home agent.
+
+   o  Co-existence of the Mobile-AAA Authentication extension in the
+      same Registration Request is made explicit.
+
+   o  The situation in which the foreign agent sets missing_challenge is
+      clarified further.
+
+   o  The use of Mobile-AAA Authentication extension is allowed by the
+      mobile node with co-located care-of address.
+
+   o  Added protection against bogus Registration Reply and Agent
+      Advertisement.  Also, the processing of the Challenge is clarified
+      if it is received in the multicast/unicast Agent Advertisement.
+
+   o  Added reference of FA Error extension in the References section
+      and also updated relevant text in section 3.2 and section 11.
+
+
+
+Perkins, et al.             Standards Track                    [Page 20]
+
+RFC 4721       Mobile IPv4 Challenge/Response Extensions    January 2007
+
+
+Appendix B.  Verification Infrastructure
+
+   The Challenge extensions in this protocol specification are expected
+   to be useful to help the foreign agent manage connectivity for
+   visiting mobile nodes, even in situations where the foreign agent
+   does not have any security association with the mobile node or the
+   mobile node's home agent.  In order to carry out the necessary
+   authentication, it is expected that the foreign agent will need the
+   assistance of external administrative systems, which have come to be
+   called AAA systems.  For the purposes of this document, we call the
+   external administrative support the "verification infrastructure".
+   The verification infrastructure is described to motivate the design
+   of the protocol elements defined in this document and is not strictly
+   needed for the protocol to work.  The foreign agent is free to use
+   any means at its disposal to verify the credentials of the mobile
+   node.  It could, for instance, rely on a separate protocol between
+   the foreign agent and the Mobile IP home agent and still not require
+   any modification to the mobile node.
+
+   In order to verify the credentials of the mobile node, we assume that
+   the foreign agent has access to a verification infrastructure that
+   can return a secure notification to the foreign agent that the
+   authentication has been performed, along with the results of that
+   authentication.  This infrastructure may be visualized as shown in
+   Figure 4.
+
+      +----------------------------------------------------+
+      |                                                    |
+      |  Verification and Key Management Infrastructure    |
+      |                                                    |
+      +----------------------------------------------------+
+               ^ |                                  ^ |
+               | |                                  | |
+               | v                                  | v
+        +---------------+                    +---------------+
+        |               |                    |               |
+        | foreign agent |                    |   home agent  |
+        |               |                    |               |
+        +---------------+                    +---------------+
+
+                  Figure 4.  The Verification Infrastructure
+
+   After the foreign agent gets the Challenge authentication, it MAY
+   pass the authentication to the (here unspecified) infrastructure and
+   await a Registration Reply.  If the Reply has a positive status
+   (indicating that the registration was accepted), the foreign agent
+   accepts the registration.  If the Reply contains the Code value
+
+
+
+
+Perkins, et al.             Standards Track                    [Page 21]
+
+RFC 4721       Mobile IPv4 Challenge/Response Extensions    January 2007
+
+
+   BAD_AUTHENTICATION (see Section 10), the foreign agent takes actions
+   indicated for rejected registrations.
+
+   Implicit in this picture is the important observation that the
+   foreign agent and the home agent have to be equipped to make use of
+   whatever protocol is required by the challenge verification and key
+   management infrastructure shown in the figure.
+
+   The protocol messages for handling the authentication within the
+   verification infrastructure and the identity of the agent performing
+   the verification of the foreign agent challenge are not specified in
+   this document, as those operations do not have to be performed by any
+   Mobile IP entity.
+
+Appendix C.  Message Flow for FA Challenge Messaging with Mobile-AAA
+             Extension
+
+   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 Messaging
+
+   In Figure 5, the following informational message flow is illustrated:
+
+   1.  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).
+
+   2.  The mobile node creates a Registration Request including the
+       advertised Challenge Value in the Challenge extension, along with
+       a Mobile-AAA authentication extension.
+
+
+
+Perkins, et al.             Standards Track                    [Page 22]
+
+RFC 4721       Mobile IPv4 Challenge/Response Extensions    January 2007
+
+
+   3.  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.
+
+   4.  The foreign agent receives a Registration Reply with the
+       appropriate indications for authorizing connectivity for the
+       mobile node.
+
+   5.  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
+
+         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
+                              Authentication
+
+   In Figure 6, the following informational message flow is illustrated:
+
+   1.  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).
+
+   2.  The mobile node creates a Registration Request including the
+       advertised Challenge Value in the Challenge extension, along with
+       a Mobile-Foreign Authentication extension.
+
+   3.  The foreign agent relays the Registration Request to the home
+       agent specified by the mobile node.
+
+
+
+
+Perkins, et al.             Standards Track                    [Page 23]
+
+RFC 4721       Mobile IPv4 Challenge/Response Extensions    January 2007
+
+
+   4.  The foreign agent receives a Registration Reply with the
+       appropriate indications for authorizing connectivity for the
+       mobile node.
+
+   5.  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 actions indicated for rejected
+       registrations.
+
+Appendix E.  Example Pseudo-Code for Tracking Used Challenges
+
+   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);
+   }
+
+
+
+
+
+
+
+
+
+
+
+
+Perkins, et al.             Standards Track                    [Page 24]
+
+RFC 4721       Mobile IPv4 Challenge/Response Extensions    January 2007
+
+
+Authors' Addresses
+
+   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.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Perkins, et al.             Standards Track                    [Page 25]
+
+RFC 4721       Mobile IPv4 Challenge/Response Extensions    January 2007
+
+
+Full Copyright Statement
+
+   Copyright (C) The IETF Trust (2007).
+
+   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.
+
+   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, THE IETF TRUST,
+   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 regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+Perkins, et al.             Standards Track                    [Page 26]
+