rfc3012.txt

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

Network Working Group                                         C. Perkins
Request for Comments: 3012                         Nokia Research Center
Category: Standards Track                                     P. Calhoun
                                           Sun Microsystems Laboratories
                                                           November 2000


               Mobile IPv4 Challenge/Response Extensions

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 Internet Society (2000).  All Rights Reserved.

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, this extension does not provide ironclad replay
   protection for the foreign agent, and does not allow for the use of
   existing techniques (such as 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.


















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


Table of Contents

    1. Introduction . . . . . . . . . . . . . . . . . . . . . . . .  2
    2. Mobile IP Agent Advertisement Challenge Extension  . . . . .  3
    3. Operation  . . . . . . . . . . . . . . . . . . . . . . . . .  3
        3.1. Mobile Node Processing for Registration Requests . . .  3
        3.2. Foreign Agent Processing for Registration Requests . .  5
        3.3. Foreign Agent Processing for Registration Replies  . .  7
        3.4. Home Agent Processing for the Challenge Extensions . .  7
    4. MN-FA Challenge Extension  . . . . . . . . . . . . . . . . .  7
    5. Generalized Mobile IP Authentication Extension . . . . . . .  8
    6. MN-AAA Authentication subtype. . . . . . . . . . . . . . . .  9
    7. Reserved SPIs for Mobile IP. . . . . . . . . . . . . . . . .  9
    8. SPI For RADIUS AAA Servers . . . . . . . . . . . . . . . . . 10
    9. Configurable Parameters. . . . . . . . . . . . . . . . . . . 10
   10. Error Values  . . . . . . . . . . . . . . . . .. . . . . . . 10
   11. IANA Considerations  . . . . . . . . . . . . . . . . . . . . 11
   12. Security Considerations  . . . . . . . . . . . . . . . . . . 12
   13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
   References . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
    A. Verification Infrastructure  . . . . . . . . . . . . . . . . 14
   Addresses  . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
   Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 17

1. Introduction

   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, this extension does not provide ironclad replay
   protection, from the point of view of the foreign agent, and does not
   allow for the use of existing techniques (such as CHAP [12]) 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 a use
   challenge/response mechanism to authenticate the mobile node.

   All SPI values defined in this document refer to values for the
   Security Parameter Index, as defined in RFC 2002 [8].  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 [1].








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


2. Mobile IP Agent Advertisement Challenge Extension

   This section defines a new extension to the Router Discovery Protocol
   [3] 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 bytes; 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
   the latest challenge value that can be used by the mobile node to
   compute an authentication for its 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. [4] provides more information on
   generating pseudo-random numbers suitable for use as values for the
   challenge.

3. Operation

   This section describes modifications to the Mobile IP registration
   process which may occur after the Foreign Agent issues a Mobile IP
   Agent Advertisement containing the Challenge on its local link.

3.1. Mobile Node Processing for Registration Requests

   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 MN-FA 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.





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


   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 [8].  When the Registration Request contains the MN-FA
   Challenge extension specified in section 4, the Mobile-Foreign
   Authentication MUST follow the Challenge extension in the
   Registration Request.

   If the Mobile Node does not have a security association with the
   Foreign Agent, the Mobile Node MUST include the MN-AAA Authentication
   extension as defined in section 6.  In addition, the Mobile Node
   SHOULD include the NAI extension [2], to enable the foreign agent to
   make use of any available verification infrastructure.  The SPI field
   of the MN-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 [12]
   using MD5 [11].

   In either case, the MN-FA Challenge extension and one of the above
   specified authentication extensions MUST follow the Mobile-Home
   Authentication extension, if present.

   A successful Registration Reply from the Foreign Agent MAY include a
   new Challenge value (see section 3.3).  The Mobile Node MAY use
   either the value found in the latest Advertisement, or the one found
   in the last Registration Reply from the Foreign Agent.  This approach
   enables the Mobile Node to make use of the challenge without having
   to wait for advertisements.

   A Mobile Node might receive an UNKNOWN_CHALLENGE error (see section
   9) if it moves to a new Foreign Agent that cannot validate the
   challenge provided in the Registration Request.  In such instances,
   the Mobile Node MUST use a new Challenge value in any new
   registration, obtained either from an Agent Advertisement, or from a
   Challenge extension to the Registration Reply containing the error.

   A Mobile Node that does not include a Challenge when the Mobile-
   Foreign Authentication extension is present may receive a
   MISSING_CHALLENGE (see section 10) error.  In this case, the foreign
   agent will not process the request from the mobile node unless the
   request contains a valid Challenge.








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


   A Mobile Node that receives a BAD_AUTHENTICATION error code (see
   section 10) SHOULD include the MN-AAA Authentication Extension in the
   next Registration Request.  This will make it possible for the
   Foreign Agent to use its AAA infrastructure in order to authenticate
   the Mobile Node.

3.2. Foreign Agent Processing for Registration Requests

   Upon receipt of the Registration Request, 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 MUST check that the MN-FA 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.  If the challenge
   extension is needed and does not exist, the Foreign Agent MUST send a
   Registration Reply to the mobile node with the error code
   MISSING_CHALLENGE.

   A foreign agent that sends Agent Advertisements containing a
   Challenge value MAY send a Registration Reply message with a
   MISSING_CHALLENGE error if the mobile node sends a Registration
   Request with a Mobile-Foreign Authentication extension without
   including a Challenge.  In other words, such a foreign agent MAY
   refuse to process a Registration Request request from the mobile node
   unless the request contains a valid Challenge.

   If a mobile node retransmits a Registration Request with the same
   Identification field and the same Challenge extension, and 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.  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 last successful Registration Reply
   issued to the Mobile Node, or else 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 UNKNOWN_CHALLENGE (see section 10).






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


   Furthermore, the Foreign Agent MUST check that there is either a
   Mobile-Foreign, or a MN-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
   BAD_AUTHENTICATION (see Section 10).

   If the MN-AAA Authentication extension (see Section 6) is present in
   the message, or if an 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.
   The Foreign Agent MUST NOT remove the MN-AAA Authentication Extension
   from the Registration Request prior to the completion of the
   authentication performed by the AAA infrastructure.  The appendix
   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, the Foreign Agent MAY
   remove the Challenge Extension from the Registration Request without
   disturbing the authentication value computed by the Mobile Node for
   use by the AAA or the Home Agent.  If the Challenge extension is not
   removed, it MUST precede the Foreign-Home Authentication extension.

   If the Foreign Agent does not remove the Challenge extension, then
   the Foreign Agent SHOULD store the Challenge value as part of the
   pending registration request list [8].  Also in this case, the
   Foreign Agent MUST reject any Registration Reply message coming from
   the Home Agent that does not also include the Challenge Extension