rfc2905.txt

来自「著名的RFC文档,其中有一些文档是已经翻译成中文的的.」· 文本 代码 · 共 1,607 行 · 第 1/5 页

      session):

      1. One Authentication, One Authorization
      2. One Authentication, Multiple Authorization
      3. Multiple Authentication, Multiple Authorization

3.  Mobile-IP

   The Mobile-IP protocol is used to manage mobility of an IP host
   across IP subnets [10].  Recent activity within the Mobile-IP Working
   Group has defined the interaction between Mobile-IP and AAA in order
   to provide:



Vollbrecht, et al.           Informational                      [Page 6]

RFC 2905         AAA Authorization Application Examples      August 2000


      -  Better scaling of security associations
      -  Mobility across administrative domain boundaries
      -  Dynamic assignment of Home Agent

   The Mobile IP protocol, as defined in [10], works well when all
   mobile nodes belong to the same administrative domain.  Some of the
   current work within the Mobile IP Working Group is to allow Mobile IP
   to scale across administrative domains.  This changes the trust model
   that is currently defined in [10].

   The requirements for Mobile-IP authorization are documented in [11].
   In this section, we develop a multi-domain model for Mobile-IP
   authorization and present it in the terms of the framework presented
   in [2].

   Figure 2 depicts the new AAA trust model for Mobile-IP.  In this
   model each network contains mobile nodes (MN) and a AAA server (AAA).
   Each mobility device shares a security association (SA) with the AAA
   server within its own home network.  This means that none of the
   mobility devices initially share a security association.  Both
   administrative domains' AAA servers can either share a security
   association, or can have a security association with an intermediate
   broker.

                             Broker AAA
                             +--------+
                             |        |
                             |  AAA   |
                       /=====|        |=====\
                      //     +--------+     \\
            Foreign  // SA                SA \\   Home
              AAA   //                        \\  AAA
             +--------+                      +--------+
             |        |          SA          |        |
             |  AAA   |======================|  AAA   |
             |        | (in lieu of broker)  |        |
             +--------+                      +--------+
                 ||                           ||    ||
              SA ||                        SA ||    || SA
                 ||                           ||    ||
                 ||                           ||    ||
             +---------+              +---------+  +---------+
             |         |              |         |  |         |
             |   FA    |              |   HA    |  |   MN    |
             |         |              |         |  |         |
             +---------+              +---------+  +---------+

                    Fig. 2 -- Mobile-IP AAA Trust Model



Vollbrecht, et al.           Informational                      [Page 7]

RFC 2905         AAA Authorization Application Examples      August 2000


   Figure 3 provides an example of a Mobile-IP network that includes
   AAA. In the integrated Mobile-IP/AAA Network, it is assumed that each
   mobility agent shares a security association between itself and its
   local AAA server.  Further, the Home and Foreign AAA servers both
   share a security association with the broker's AAA server.  Lastly,
   it is assumed that each mobile node shares a trust relationship with
   its home AAA Server.

           Visited Access      Broker          Home IP
           Provider Network    Network         Network
             +--------+      +--------+      +--------+
             |        |      |        |      |        |
             |  AAA   |------|  AAA   |------|  AAA   |
             |        |      |        |      |        |
             +--------+      +--------+      +--------+
                  |                              |
                  |                              |
              AAA |                              | AAA
                  |                              |
                  |                              |
             +---------+                    +---------+
             |         |                    |         |
             |   FA    |                    |   HA    |
             |         |                    |         |
             +---------+                    +---------+
                  |
                  |   Visited Access     Home Network
                  |  Provider Network       -Private Network
           Mobile |                         -Home Provider
             IP   |                         -Home ISP
                  |
             +--------+
             | Mobile |
             | Node   |
             +--------+

    Fig. 3 -- General Wireless IP Architecture for Mobile-IP AAA

   In this example, a Mobile Node appears within a foreign network and
   issues a registration to the Foreign Agent.  Since the Foreign Agent
   does not share any security association with the Home Agent, it sends
   a AAA request to its local AAA server, which includes the
   authentication information and the Mobile-IP registration request.
   The Mobile Node cannot communicate directly with the home AAA Server
   for two reasons:






Vollbrecht, et al.           Informational                      [Page 8]

RFC 2905         AAA Authorization Application Examples      August 2000


      -  It does not have access to the network.  The registration
         request is sent by the Mobile Node to request access to the
         network.
      -  The Mobile Node may not have an IP address, and may be
         requesting that one be assigned to it by its home provider.

   The Foreign AAA Server will determine whether the request can be
   satisfied locally through the use of the Network Access Identifier
   [7] provided by the Mobile Node.  The NAI has the format of
   user@realm and the AAA Server uses the realm portion of the NAI to
   identify the Mobile Node's home AAA Server. If the Foreign AAA Server
   does not share any security association with the Mobile Node's home
   AAA Server, it may forward the request to its broker.  If the broker
   has a relationship with the home network, it can forward the request,
   otherwise a failed response is sent back to the Foreign AAA Server.

   When the home AAA Server receives the AAA Request, it authenticates
   the user and begins the authorization phase.  The authorization phase
   includes the generation of:

      -  Dynamic Session Keys to be distributed among all Mobility
         Agents
      -  Optional Dynamic assignment of a Home Agent
      -  Optional Dynamic assignment of a Home Address (note this could
         be done by the Home Agent).
      -  Optional Assignment of QOS parameters for the Mobile Node [12]

   Once authorization is complete, the home AAA Server issues an
   unsolicited AAA request to the Home Agent, which includes the
   information in the original AAA request as well as the authorization
   information generated by the home AAA server.  The Home Agent
   retrieves the Registration Request from the AAA request and processes
   it, then generates a Registration Reply that is sent back to the home
   AAA server in a AAA response.  The message is forwarded through the
   broker back to the Foreign AAA server, and finally to the Foreign
   Agent.

   The AAA servers maintain session state information based on the
   authorization information.  If a Mobile Node moves to another Foreign
   Agent within the foreign domain, a request to the foreign AAA server
   can immediately be done in order to immediately return the keys that
   were issued to the previous Foreign Agent.  This minimizes an
   additional round trip through the internet when micro mobility is
   involved, and enables smooth hand-off.







Vollbrecht, et al.           Informational                      [Page 9]

RFC 2905         AAA Authorization Application Examples      August 2000


3.1.  Relationship to the Framework

   Mobile-IP uses the roaming pull model described in [2].  The Mobile
   Node is the User.  The Foreign Network is the Service Provider with
   the Foreign Agent as the Service Equipment.  The Home Network is the
   User Home Organization.  Note that the User Home Organization
   operates not only a AAA Server, but also the Home Agent.  Note, also,
   that a broker has been inserted between the Service Provider and the
   User Home Organization.

3.2.  Minimized Internet Traversal

   Although it would have been possible for the AAA interactions to be
   performed for basic authentication and authorization, and the
   Registration flow to be sent directly to the Home Agent from the
   Foreign Agent, one of the key Mobile-IP AAA requirements is to
   minimize Internet Traversals. Including the Registration Request and
   Replies in the AAA messages allows for a single traversal to
   authenticate the user, perform authorization and process the
   Registration Request.  This streamlined approach is required in order
   to minimize the latency involved in getting wireless (cellular)
   devices access to the network.  New registrations should not increase
   the connect time more than what the current cellular networks
   provide.

3.3.  Key Distribution

   In order to allow the scaling of wireless data access across
   administrative domains, it is necessary to minimize the security
   associations required. This means that each Foreign Agent does not
   share a security association with each Home Agent on the Internet.
   The Mobility Agents share a security association with their local AAA
   server, which in turn shares a security association with other AAA
   servers.  Again, the use of brokers, as defined by the Roaming
   Operations (roamops) Working Group, allows such services to scale by
   allowing the number of relationships established by the providers to
   be reduced.

   After a Mobile Node is authenticated, the authorization phase
   includes the generation of Sessions Keys.  Specifically, three keys
   are generated:

      -  k1 - Key to be shared between the Mobile Node and the Home
         Agent
      -  k2 - Key to be shared between the Mobile Node and the Foreign
         Agent
      -  k3 - Key to be shared between the Foreign Agent and the Home
         Agent



Vollbrecht, et al.           Informational                     [Page 10]

RFC 2905         AAA Authorization Application Examples      August 2000


   Each Key is propagated to each mobility device through the AAA
   protocol (for the Foreign and Home Agent) and via Mobile-IP for the
   Mobile Node (since the Mobile Node does not interface directly with
   the AAA servers).

   Figure 4 depicts the new security associations used for Mobile-IP
   message integrity using the keys derived by the AAA server.

             +--------+                      +--------+
             |        |          k3          |        |
             |   FA   |======================|   HA   |
             |        |                      |        |
             +--------+                      +--------+
                   \\                          //
                    \\ k2                  k1 //
                     \\      +--------+      //
                      \\     |        |     //
                       \=====|   MN   |=====/
                             |        |
                             +--------+

       Fig. 4 -- Security Association after Key Distribution

   Once the session keys have been established and propagated, the
   mobility devices can exchange registration information directly
   without the need of the AAA infrastructure.  However the session keys
   have a lifetime, after which the AAA infrastructure must be used in
   order to acquire new session keys.

3.4.  Mobile-IP Authorization Requirements

   To summarize, Mobile-IP has the following authorization requirements:

   1. Mobile-IP requires an AAA protocol that makes use of the pull
      model.

   2. Mobile-IP requires broker support, and data objects must contain
      data integrity and confidentiality end-to-end.  This means that
      neither the broker nor any other intermediate AAA node should be
      able to decrypt the data objects, but they must be able to verify
      the objects' validity.

   3. Authorization includes Resource Management.  This allows the AAA
      servers to maintain a snapshot of a mobile node's current
      location, keying information, etc.






Vollbrecht, et al.           Informational                     [Page 11]

RFC 2905         AAA Authorization Application Examples      August 2000


   4. Due to the nature of the service being offered, it is imperative
      that the AAA transaction add minimal latency to the connect time.
      Ideally, the AAA protocol should allow for a single round trip for
      authentication and authorization.

   5. If the AAA protocol allows for the Mobile-IP registration messages
      to be embedded within the authentication/authorization request,
      this will further reduce the number of round trips required and
      hence reduce the connect time.

   6. It must be possible to pass Mobile-IP specific key management data
      along with the authorization data.  This allows the AAA server to
      act as a Key Distribution Center (KDC).

   7. It must be possible to pass other application-specific data units
      such as home agent selection and home address assignment to be
      carried along with the authorization data units.

   8. The authorization response should allow for diffserv (QOS)
      profiles, which can be used by the mobility agents to provide some
      quality of service to the mobile node.