rfc3012.txt

<VC++网络游戏建摸与实现>源代码

   with the same Challenge Value that was included in the Registration
   Request.  The Foreign Agent MUST send the rejected Registration
   message to the mobile node, and change the status in the Registration
   Reply to the value MISSING_CHALLENGE (see section 10).

   If the Foreign Agent does remove the Challenge extension and
   applicable authentication from the Registration Request message, then
   it SHOULD insert the Identification field from the Registration
   Request message along with its record-keeping information about the
   particular Mobile Node in order to protect against replays.








Perkins & Calhoun           Standards Track                     [Page 6]

RFC 3012             Mobile IPv4 Challenge/Response        November 2000


3.3. Foreign Agent Processing for Registration Replies

   The Foreign Agent MAY include a new 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 MN-FA authentication extension.

   Suppose the Registration Reply includes a Challenge extension from
   the Home Agent, and 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 FA-HA authentication extension, before appending the new
   Challenge extension to the Registration Reply.

3.4. Home Agent Processing for the Challenge Extensions

   If the Home Agent receives a Registration Request with the MN-FA
   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.

   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 [8].
   In this case, the Home Agent will send a Registration Reply to the
   Foreign Agent that does not include the Challenge extension.

4. MN-FA 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 MN-FA Challenge Extension

      Type        132 (skippable) (see [8])

      Length      Length of the Challenge value



Perkins & Calhoun           Standards Track                     [Page 7]

RFC 3012             Mobile IPv4 Challenge/Response        November 2000


      Challenge   The Challenge field is copied from the Challenge field
                  found in the Agent Advertisement Challenge extension
                  (see section 2).

5. Generalized Mobile IP Authentication Extension

   Several new authentication extensions have been designed for various
   control messages proposed for extensions to Mobile IP (see, for
   example, [9]).  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 [8] are the home agent and the foreign agent.
   It is the purpose of the generalized authentication extension defined
   here 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 [8])

       Subtype         a number assigned to identify the kind of
                       endpoints or characteristics of the particular
                       authentication strategy

       Length          4 plus the number of bytes 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               MN-AAA Authentication subtype (see section 6)







Perkins & Calhoun           Standards Track                     [Page 8]

RFC 3012             Mobile IPv4 Challenge/Response        November 2000


6. MN-AAA Authentication subtype

   The Generalized Authentication extension with subtype 1 will be
   referred to as a MN-AAA Authentication extension.  If the mobile node
   does not include a Mobile-Foreign Authentication [8] extension, then
   it MUST include the MN-AAA Authentication extension whenever the
   Challenge extension is present.  If the MN-AAA Authentication
   extension is present, then the Registration Message sent by the
   mobile node MUST contain the Mobile-HA Authentication extension [8]
   if it shares a security association with the Home Agent.  If present,
   the Mobile-HA Authentication Extension MUST appear prior to the MN-
   AAA Authentication extension.  The mobile node MAY include a MN-AAA
   Authentication extension in any Registration Request.  The
   corresponding response MUST include the MN-HA Authentication
   Extension, and MUST NOT include the MN-AAA Authentication Extension.

   The default algorithm for computation of the authenticator is HMAC-
   MD5 [5] 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 resulting function call, as described in [5], 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,
   this default algorithm MUST be able to be configured for selection at
   any arbitrary 32-bit SPI outside of the SPIs in the reserved range
   0-255.

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) which 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/numbers.html









Perkins & Calhoun           Standards Track                     [Page 9]

RFC 3012             Mobile IPv4 Challenge/Response        November 2000


8. SPI 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 (see section 7) for
   indicating the following procedure for computing authentication data
   (called the "authenticator"), which is used by many RADIUS servers
   [10] today.

   To compute the authenticator, apply MD5 [11] computed on the
   following data, in the order shown:

      High-order byte from Challenge || Key ||
      MD5(Preceding Mobile IP data ||
      Type, Subtype (if present), Length, SPI) ||
      Least-order 237 bytes from Challenge

   where the 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.  Since the RADIUS protocol
   cannot carry attributes greater than 253 in size, the preceding
   Mobile IP data, type, subtype (if present), length and SPI are hashed
   using MD5.  Finally, the least significant 237 bytes of the challenge
   are concatenated.

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(s) of Document
      --------------     -------------   ----------------------
      CHALLENGE_WINDOW   2               3.2
      CHAP_SPI           2               8

10. Error Values

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



Perkins & Calhoun           Standards Track                    [Page 10]

RFC 3012             Mobile IPv4 Challenge/Response        November 2000


      Error Name               Value   Section of Document
      ----------------------   -----   -------------------
      UNKNOWN_CHALLENGE        104     3.2
      BAD_AUTHENTICATION       67      3.2 - also see [8]
      MISSING_CHALLENGE        105     3.1,3.2
      STALE_CHALLENGE          106     3.2

11. IANA Considerations

   The Generalized Mobile IP Authentication extension defined in Section
   5 is a Mobile IP registration extension as defined in RFC 2002 [8]
   and extended in RFC 2356 [7].  IANA should assign 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.

   The MN-FA Challenge Extension defined in Section 4 is a router
   advertisement extension as defined in RFC 1256 [3] and extended in
   RFC 2002 [8].  IANA should assign a value of 132 for this purpose.

   The Code values defined in Section 10 are error codes as defined in
   RFC 2002 [8] and extended in RFC 2344 [6] and RFC 2356 [7].  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 which is to be used in some cases
   with the extension defined in this specification.  IANA should record
   the values as defined in Section 10.

   A new section for enumerating algorithms identified by specific SPIs
   within the range 0-255 is to be added to

      http://www.isi.edu/in-notes/iana/assignments/mobileip-numbers.

   The CHAP_SPI number (2) discussed in section 8 is to be 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.







Perkins & Calhoun           Standards Track                    [Page 11]

RFC 3012             Mobile IPv4 Challenge/Response        November 2000


12. Security Considerations

   In the event that a malicious mobile node attempts to replay the
   authenticator for an old MN-FA 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, because the
   authentication data provided by the mobile node will be computed over
   data that is different (at least by the bytes of the mobile nodes' IP
   addresses).

   Whenever a Foreign Agent updates a field of the Registration Reply
   (as suggested in section 3.2), it invalidates the authentication data
   supplied by the Home Agent in the MN-HA Authentication extension to
   the Registration Reply.  Thus, this opens up a security exposure