rfc2977.txt

RFC 的详细文档！

   end not scalable; the AAA framework MUST provide for more scalable
   mechanisms, as suggested below in section 6.

   Finally, in the figure, it is clear that the attendant can naturally
   share a security association with the AAAL.  This is necessary in
   order for the model to work because the attendant has to know that it
   is permissible to allocate the local resources to the client.

   As an example in today's Internet, we can cite the deployment of
   RADIUS [16] to allow mobile computer clients to have access to the
   Internet by way of a local ISP. The ISP wants to make sure that the
   mobile client can pay for the connection.  Once the client has
   provided credentials (e.g., identification, unique data, and an
   unforgeable signature), the ISP checks with the client's home
   authority to verify the signature, and to obtain assurance that the
   client will pay for the connection.  Here, the attendant function can
   be carried out by the NAS, and the local and home authorities can use
   RADIUS servers.  Credentials allowing authorization at one attendant
   SHOULD be unusable in any future negotiations at the same or any
   other attendant.

   From the description and example above, we can identify several
   requirements.

   -  Each local attendant has to have a security relationship with the
      local AAA server (AAAL)
   -  The local authority has to share, or dynamically establish,
      security relationships with external authorities that are able to
      check client credentials




Glass, et al.                Informational                      [Page 6]

RFC 2977               Mobile IP AAA Requirements           October 2000


   -  The attendant has to keep state for pending client requests while
      the local authority contacts the appropriate external authority
   -  Since the mobile node may not necessarily initiate network
      connectivity from within its home domain, it MUST be able to
      provide complete, yet unforgeable credentials without ever having
      been in touch with its home domain.
   -  Since the mobile node's credentials have to remain unforgeable,
      intervening nodes (e.g., neither the attendant or the local
      authority (AAAL) or any other intermediate nodes) MUST NOT be able
      to learn any (secret) information which may enable them to
      reconstruct and reuse the credentials.

   From this last requirement, we can see the reasons for the natural
   requirement that the client has to share, or dynamically establish, a
   security relationship with the external authority in the Home Domain.
   Otherwise, it is technically infeasible (given the implied network
   topology) for the client to produce unforgeable signatures that can
   be checked by the AAAH.  Figure 2 illustrates the natural security
   associations we understand from our proposed model.  Note that,
   according to the discussion in section 6, there may, by mutual
   agreement between AAAL and AAAH, be a third party inserted between
   AAAL and AAAH to help them arbitrate secure transactions in a more
   scalable fashion.

                               +------+              +------+
                               |      |              |      |
                               | AAAL +--------------+ AAAH |
                               |      |              |      |
                               +---+--+              +--+---+
                                   |                    |
                                   |                    |
                               +---+--+              +--+---+
   C    =  client              |      |              |      |
   A    =  attendant           |   A  |              |  C   |
   AAAL =  local authority     |      |              |      |
   AAAH =  home authority      +------+              +------+

                    Figure 2: Security Associations

   In addition to the requirements listed above, we specify the
   following requirements which derive from operational experience with
   today's roaming protocols.

   -  There are scenarios in which an attendant will have to manage
      requests for many clients at the same time.
   -  The attendant MUST protect against replay attacks.





Glass, et al.                Informational                      [Page 7]

RFC 2977               Mobile IP AAA Requirements           October 2000


   -  The attendant equipment should be as inexpensive as possible,
      since it will be replicated as many times as possible to handle as
      many clients as possible in the foreign domain.
   -  Attendants SHOULD be configured to obtain authorization, from a
      trusted local AAA server (AAAL) for Quality of Service
      requirements placed by the client.

   Nodes in two separate administrative domains (for instance, AAAH and
   AAAL) often must take additional steps to verify the identity of
   their communication partners, or alternatively to guarantee the
   privacy of the data making up the communication.  While these
   considerations lead to important security requirements, as mentioned
   above in the context of security between servers, we consider the
   exact choice of security associations between the AAA servers to be
   beyond the scope of this document.  The choices are unlikely even to
   depend upon any specific features of the general model illustrated in
   figure 1.  On the other hand, the security associations needed
   between Mobile IP entities will be of central importance in the
   design of a suitable AAA infrastructure for Mobile IP.  The general
   model shown above is generally compatible with the needs of Mobile
   IP. However, some basic changes are needed in the security model of
   Mobile IP, as detailed in section 5.

   Lastly, recent discussion in the mobile-ip working group has
   indicated that the attendant MUST be able to terminate service to the
   client based on policy determination by either AAAH or AAAL server.

3.1. AAA Protocol Roaming Requirements

   In this section we will detail additional requirements based on
   issues discovered through operational experience of existing roaming
   RADIUS networks.  The AAA protocol MUST satisfy these requirements in
   order for providers to offer a robust service.  These requirements
   have been identified by TR45.6 as part of their involvement with the
   Mobile IP working group.

   -  Support a reliable AAA transport mechanism.
      *  There must be an effective hop-by-hop retransmission and
         failover mechanism so that reliability does not solely depend
         on end-to-end retransmission
      *  This transport mechanism will be able indicate to an AAA
         application that a message was delivered to the next peer AAA
         application or that a time out occurred.
      *  Retransmission is controlled by the reliable AAA transport
         mechanism, and not by lower layer protocols such as TCP.






Glass, et al.                Informational                      [Page 8]

RFC 2977               Mobile IP AAA Requirements           October 2000


      *  Even if the AAA message is to be forwarded, or the message's
         options or semantics do not conform with the AAA protocol, the
         transport mechanism will acknowledge that the peer received the
         AAA message.
      *  Acknowledgements SHOULD be allowed to be piggybacked in AAA
         messages
      *  AAA responses have to be delivered in a timely fashion so that
         Mobile IP does not timeout and retransmit
   -  Transport a digital certificate in an AAA message, in order to
      minimize the number of round trips associated with AAA
      transactions.  Note:  This requirement applies to AAA applications
      and not mobile stations.  The certificates could be used by
      foreign and home agents to establish an IPSec security association
      to secure the mobile node's tunneled data.  In this case, the AAA
      infrastructure could assist by obtaining the revocation status of
      such a certificate (either by performing online checks or
      otherwise validating the certificate) so that home and foreign
      agents could avoid a costly online certificate status check.
   -  Provide message integrity and identity authentication on a hop-
      by-hop (AAA node) basis.
   -  Support replay protection and optional non-repudiation
      capabilities for all authorization and accounting messages.  The
      AAA protocol must provide the capability for accounting messages
      to be matched with prior authorization messages.
   -  Support accounting via both bilateral arrangements and via broker
      AAA servers providing accounting clearinghouse and reconciliation
      between serving and home networks.  There is an explicit agreement
      that if the private network or home ISP authenticates the mobile
      station requesting service, then the private network or home ISP
      network also agrees to reconcile charges with the home service
      provider or broker.  Real time accounting must be supported.
      Timestamps must be included in all accounting packets.

4. Requirements related to basic IP connectivity

   The requirements listed in the previous section pertain to the
   relationships between the functional units, and don't depend on the
   underlying network addressing.  On the other hand, many nodes (mobile
   or merely portable) are programmed to receive some IP-specific
   resources during the initialization phase of their attempt to connect
   to the Internet.

   We place the following additional requirements on the AAA services in
   order to satisfy such clients.

   -  Either AAA server MUST be able to obtain, or to coordinate the
      allocation of, a suitable IP address for the customer, upon
      request by the customer.



Glass, et al.                Informational                      [Page 9]

RFC 2977               Mobile IP AAA Requirements           October 2000


   -  AAA servers MUST be able to identify the client by some means
      other than its IP address.

   Policy in the home domain may dictate that the home agent instead of
   the AAAH manages the allocation of an IP address for the mobile node.
   AAA servers MUST be able to coordinate the allocation of an IP
   address for the mobile node at least in this way.

   AAA servers today identify clients by using the Network Access
   Identifier (NAI) [1].  A mobile node can identify itself by including
   the NAI along with the Mobile IP Registration Request [6].  The NAI
   is of the form "user@realm"; it is unique and well suited for use in
   the AAA model illustrated in figure 1.  Using a NAI (e.g.,
   "user@realm") allows AAAL to easily determine the home domain (e.g.,
   "realm") for the client.  Both the AAAL and the AAAH can use the NAI
   to keep records indexed by the client's specific identity.

5. AAA for Mobile IP

   Clients using Mobile IP require specific features from the AAA
   services, in addition to the requirements already mentioned in
   connection with the basic AAA functionality and what is needed for IP
   connectivity.  To understand the application of the general model for
   Mobile IP, we consider the mobile node (MN) to be the client in
   figure 1, and the attendant to be the foreign agent (FA).  If a
   situation arises that there is no foreign agent present, e.g., in the
   case of an IPv4 mobile node with a co-located care of address or an
   IPv6 mobile node, the equivalent attendant functionality is to be
   provided by the address allocation entity, e.g., a DHCP server.  Such
   an attendant functionality is outside the scope of this document.
   The home agent, while important to Mobile IP, is allowed to play a
   role during the initial registration that is subordinate to the role
   played by the AAAH. For application to Mobile IP, we modify the
   general model (as illustrated in figure 3).  After the initial
   registration, the mobile node is authorized to continue using Mobile
   IP at the foreign domain without requiring further involvement by the
   AAA servers.  Thus, the initial registration will probably take
   longer than subsequent Mobile IP registrations.

   In order to reduce this extra time overhead as much as possible, it
   is important to reduce the time taken for communications between the
   AAA servers.  A major component of this communications latency is the
   time taken to traverse the wide-area Internet that is likely to
   separate the AAAL and the AAAH.  This leads to a further strong
   motivation for integration of the AAA functions themselves, as well
   as integration of AAA functions with the initial Mobile IP
   registration.  In order to reduce the number of messages that
   traverse the network for initial registration of a Mobile Node, the



Glass, et al.                Informational                     [Page 10]

RFC 2977               Mobile IP AAA Requirements           October 2000


   AAA functions in the visited network (AAAL) and the home network
   (AAAH) need to interface with the foreign agent and the home agent to
   handle the registration message.  Latency would be reduced as a
   result of initial registration being handled in conjunction with AAA
   and the mobile IP mobility agents.  Subsequent registrations,
   however, would be handled according to RFC 2002 [13].  Another way to
   reduce latency as to accounting would be the exchange of small
   records.

   As there are many different types of sub-services attendants may
   provide to mobile clients, there MUST be extensible accounting
   formats.  In this way, the specific services being provided can be
   identified, as well as accounting support should more services be
   identified in the future.

   The AAA home domain and the HA home domain of the mobile node need
   not be part of the same administrative domain.  Such an situation can
   occur if the home address of the mobile node is provided by one
   domain, e.g., an ISP that the mobile user uses while at home, and the
   authorization and accounting by another (specialized) domain, e.g., a
   credit card company.  The foreign agent sends only the authentication
   information of the mobile node to the AAAL, which interfaces to the
   AAAH. After a successful authorization of the mobile node, the
   foreign agent is able to continue with the mobile IP registration
   procedure.  Such a scheme introduces more delay if the access to the
   AAA functionality and the mobile IP protocol is sequentialized.
   Subsequent registrations would be handled according to RFC 2002 [13]
   without further interaction with the AAA. Whether to combine or
   separate the Mobile IP protocol data with/from the AAA messages is
   ultimately a policy decision.  A separation of the Mobile IP protocol
   data and the AAA messages can be successfully accomplished only if
   the IP address of the mobile node's home agent is provided to the
   foreign agent performing the attendant function.

   All needed AAA and Mobile IP functions SHOULD be processed during a
   single Internet traversal.  This MUST be done without requiring AAA
   servers to process protocol messages sent to Mobile IP agents.  The
   AAA servers MUST identify the Mobile IP agents and security
   associations necessary to process the Mobile IP registration, pass
   the necessary registration data to those Mobile IP agents, and remain
   uninvolved in the routing and authentication processing steps
   particular to Mobile IP registration.