Network Working Group S. Glass
`Request for Comments: 2977 Sun Microsystems
`Category: Informational T. Hiller
` Lucent Technologies
` S. Jacobs
` GTE Laboratories
` C. Perkins
` Nokia Research Center
` October 2000
`
` Mobile IP Authentication, Authorization, and Accounting Requirements
`
`Status of this Memo
`
` This memo provides information for the Internet community. It does
` not specify an Internet standard of any kind. Distribution of this
` memo is unlimited.
`
`Copyright Notice
`
` Copyright (C) The Internet Society (2000). All Rights Reserved.
`
`Abstract
`
` The Mobile IP and Authentication, Authorization, Accounting (AAA)
` working groups are currently looking at defining the requirements for
` Authentication, Authorization, and Accounting. This document
` contains the requirements which would have to be supported by a AAA
` service to aid in providing Mobile IP services.
`
`1. Introduction
`
` Clients obtain Internet services by negotiating a point of attachment
` to a "home domain", generally from an ISP, or other organization from
` which service requests are made, and fulfilled. With the increasing
` popularity of mobile devices, a need has been generated to allow
` users to attach to any domain convenient to their current location.
` In this way, a client needs access to resources being provided by an
` administrative domain different than their home domain (called a
` "foreign domain"). The need for service from a foreign domain
` requires, in many models, Authorization, which leads directly to
` Authentication, and of course Accounting (whence, "AAA"). There is
` some argument which of these leads to, or is derived from the others,
` but there is common agreement that the three AAA functions are
` closely interdependent.
`
`Glass, et al. Informational [Page 1]
`
`Apple v. Maxell
`IPR2020-00202
`Maxell Ex. 2027
`
`Page 1 of 27
`
`

`

`RFC 2977 Mobile IP AAA Requirements October 2000
`
` An agent in a foreign domain, being called on to provide access to a
` resource by a mobile user, is likely to request or require the client
` to provide credentials which can be authenticated before access to
` resources is permitted. The resource may be as simple as a conduit
` to the Internet, or may be as complex as access to specific private
` resources within the foreign domain. Credentials can be exchanged in
` many different ways, all of which are beyond the scope of this
` document. Once authenticated, the mobile user may be authorized to
` access services within the foreign domain. An accounting of the
` actual resources may then be assembled.
`
` Mobile IP is a technology that allows a network node ("mobile node")
` to migrate from its "home" network to other networks, either within
` the same administrative domain, or to other administrative domains.
` The possibility of movement between domains which require AAA
` services has created an immediate demand to design and specify AAA
` protocols. Once available, the AAA protocols and infrastructure will
` provide the economic incentive for a wide-ranging deployment of
` Mobile IP. This document will identify, describe, and discuss the
` functional and performance requirements that Mobile IP places on AAA
` protocols.
`
` The formal description of Mobile IP can be found in [13,12,14,17].
`
` In this document, we have attempted to exhibit requirements in a
` progressive fashion. After showing the basic AAA model for Mobile
` IP, we derive requirements as follows:
`
` - requirements based on the general model
` - requirements based on providing IP service for mobile nodes
` - requirements derived from specific Mobile IP protocol needs
`
` Then, we exhibit some related AAA models and describe requirements
` derived from the related models.
`
`2. Terminology
`
` This document frequently uses the following terms in addition to
` those defined in RFC 2002 [13]:
`
` Accounting The act of collecting information on resource usage
` for the purpose of trend analysis, auditing, billing,
` or cost allocation.
`
`Glass, et al. Informational [Page 2]
`
`Apple v. Maxell
`IPR2020-00202
`Maxell Ex. 2027
`
`Page 2 of 27
`
`

`

`RFC 2977 Mobile IP AAA Requirements October 2000
`
` Administrative Domain
` An intranet, or a collection of networks, computers,
` and databases under a common administration.
` Computer entities operating in a common
` administration may be assumed to share
` administratively created security associations.
`
` Attendant A node designed to provide the service interface
` between a client and the local domain.
`
` Authentication
` The act of verifying a claimed identity, in the form
` of a pre-existing label from a mutually known name
` space, as the originator of a message (message
` authentication) or as the end-point of a channel
` (entity authentication).
`
` Authorization
` The act of determining if a particular right, such as
` access to some resource, can be granted to the
` presenter of a particular credential.
`
` Billing The act of preparing an invoice.
`
` Broker An intermediary agent, trusted by two other AAA
` servers, able to obtain and provide security services
` from those AAA servers. For instance, a broker may
` obtain and provide authorizations, or assurances that
` credentials are valid.
`
` Client A node wishing to obtain service from an attendant
` within an administrative domain.
`
` Foreign Domain
` An administrative domain, visited by a Mobile IP
` client, and containing the AAA infrastructure needed
` to carry out the necessary operations enabling Mobile
` IP registrations. From the point of view of the
` foreign agent, the foreign domain is the local
` domain.
`
` Inter-domain Accounting
` Inter-domain accounting is the collection of
` information on resource usage of an entity with an
` administrative domain, for use within another
` administrative domain. In inter-domain accounting,
` accounting packets and session records will typically
` cross administrative boundaries.
`
`Glass, et al. Informational [Page 3]
`
`Apple v. Maxell
`IPR2020-00202
`Maxell Ex. 2027
`
`Page 3 of 27
`
`

`

`RFC 2977 Mobile IP AAA Requirements October 2000
`
` Intra-domain Accounting
` Intra-domain accounting is the collection of
` information on resource within an administrative
` domain, for use within that domain. In intra-domain
` accounting, accounting packets and session records
` typically do not cross administrative boundaries.
`
` Local Domain
` An administrative domain containing the AAA
` infrastructure of immediate interest to a Mobile IP
` client when it is away from home.
`
` Real-time Accounting
` Real-time accounting involves the processing of
` information on resource usage within a defined time
` window. Time constraints are typically imposed in
` order to limit financial risk.
`
` Session record
` A session record represents a summary of the resource
` consumption of a user over the entire session.
` Accounting gateways creating the session record may
` do so by processing interim accounting events.
`
` In this document, the key words "MAY", "MUST, "MUST NOT", "optional",
` "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as
` described in [4].
`
`3. Basic Model
`
` In this section, we attempt to capture the main features of a basic
` model for operation of AAA servers that seems to have good support
` within the Mobile IP working group. Within the Internet, a client
` belonging to one administrative domain (called the home domain) often
` needs to use resources provided by another administrative domain
` (called the foreign domain). An agent in the foreign domain that
` attends to the client’s request (call the agent the "attendant") is
` likely to require that the client provide some credentials that can
` be authenticated before access to the resources is permitted. These
` credentials may be something the foreign domain understands, but in
` most cases they are assigned by, and understood only by the home
` domain, and may be used for setting up secure channels with the
` mobile node.
`
`Glass, et al. Informational [Page 4]
`
`Apple v. Maxell
`IPR2020-00202
`Maxell Ex. 2027
`
`Page 4 of 27
`
`

`

`RFC 2977 Mobile IP AAA Requirements October 2000
`
` Local Domain Home Domain
` +--------------+ +----------------------+
` | +------+ | | +------+ |
` | | | | | | | |
` | | AAAL | | | | AAAH | |
` | | +-------------------+ | |
` | +---+--+ | | +------+ |
` | | | | |
` | | | +----------------------+
` +------+ | +---+--+ |
` | | | | | | C = client
` | C |- -|- -| A | | A = attendant
` | | | | | | AAAL = local authority
` +------+ | +------+ | AAAH = home authority
` | |
` +--------------+
`
` Figure 1: AAA Servers in Home and Local Domains
`
` The attendant often does not have direct access to the data needed to
` complete the transaction. Instead, the attendant is expected to
` consult an authority (typically in the same foreign domain) in order
` to request proof that the client has acceptable credentials. Since
` the attendant and the local authority are part of the same
` administrative domain, they are expected to have established, or be
` able to establish for the necessary lifetime, a secure channel for
` the purposes of exchanging sensitive (access) information, and
` keeping it private from (at least) the visiting mobile node.
`
` The local authority (AAAL) itself may not have enough information
` stored locally to carry out the verification for the credentials of
` the client. In contrast to the attendant, however, the AAAL is
` expected to be configured with enough information to negotiate the
` verification of client credentials with external authorities. The
` local and the external authorities should be configured with
` sufficient security relationships and access controls so that they,
` possibly without the need for any other AAA agents, can negotiate the
` authorization that may enable the client to have access to any/all
` requested resources. In many typical cases, the authorization
` depends only upon secure authentication of the client’s credentials.
`
` Once the authorization has been obtained by the local authority, and
` the authority has notified the attendant about the successful
` negotiation, the attendant can provide the requested resources to the
` client.
`
`Glass, et al. Informational [Page 5]
`
`Apple v. Maxell
`IPR2020-00202
`Maxell Ex. 2027
`
`Page 5 of 27
`
`

`

`RFC 2977 Mobile IP AAA Requirements October 2000
`
` In the picture, there might be many attendants for each AAAL, and
` there might be many clients from many different Home Domains. Each
` Home Domain provides a AAAH that can check credentials originating
` from clients administered by that Home Domain.
`
` There is a security model implicit in the above figure, and it is
` crucial to identify the specific security associations assumed in the
` security model.
`
` First, it is natural to assume that the client has a security
` association with the AAAH, since that is roughly what it means for
` the client to belong to the home domain.
`
` Second, from the model illustrated in figure 1 it is clear that AAAL
` and AAAH have to share a security association, because otherwise they
` could not rely on the authentication results, authorizations, nor
` even the accounting data which might be transacted between them.
` Requiring such bilateral security relationships is, however, in the
` 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]
`
`Apple v. Maxell
`IPR2020-00202
`Maxell Ex. 2027
`
`Page 6 of 27
`
`

`

`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]
`
`Apple v. Maxell
`IPR2020-00202
`Maxell Ex. 2027
`
`Page 7 of 27
`
`

`

`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]
`
`Apple v. Maxell
`IPR2020-00202
`Maxell Ex. 2027
`
`Page 8 of 27
`
`

`

`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]
`
`Apple v. Maxell
`IPR2020-00202
`Maxell Ex. 2027
`
`Page 9 of 27
`
`

`

`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]
`
`Apple v. Maxell
`IPR2020-00202
`Maxell Ex. 2027
`
`Page 10 of 27
`
`

`

`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.
`
` For Mobile IP, the AAAL and the AAAH servers have the following
` additional general tasks:
`
` - enable [re]authentication for Mobile IP registration
`
`Glass, et al. Informational [Page 11]
`
`Apple v. Maxell
`IPR2020-00202
`Maxell Ex. 2027
`
`Page 11 of 27
`
`

`

`RFC 2977 Mobile IP AAA Requirements October 2000
`
` - authorize the mobile node (once its identity has been established)
` to use at least the set of resources for minimal Mobile IP
` functionality, plus potentially other services requested by the
` mobile node
` - initiate accounting for service utilization
` - use AAA protocol extensions specifically for including Mobile IP
` registration messages as part of the initial registration sequence
` to be handled by the AAA servers.
`
` These tasks, and the resulting more specific tasks to be listed later
` in this section, are beneficially handled and expedited by the AAA
` servers shown in figure 1 because the tasks often happen together,
` and task processing needs access to the same data at the same time.
`
` Local Domain Home Domain
` +--------------+ +----------------------+
` | +------+ | | +------+ |
` | | | | | | | |
` | | AAAL | | | | AAAH | |
` | | +-------------------+ | |
` | +---+--+ | | +--+---+ |
` | | | | | |
` | | | | | |
` +------+ | +---+--+ | | +--+---+ |
` | | | | | | | | | |
` | MN +- -|- -+ FA + -- -- -- -- - + HA | |
` | | | | | | | | | |
` +------+ | +------+ | | +------+ |
` | | | |
` +--------------+ +----------------------+
`
` Figure 3: AAA Servers with Mobile IP agents
`
` In the model in figure 1, the initial AAA transactions are handled
` without needing the home agent, but Mobile IP requires every
` registration to be handled between the home agent (HA) and the
` foreign agent (FA), as shown by the sparse dashed (lower) line in
` figure 3. This means that during the initial registration, something
` has to happen that enables the home agent and foreign agent to
` perform subsequent Mobile IP registrations. After the initial
` registration, the AAAH and AAAL in figure 3 would not be needed, and
` subsequent Mobile IP registrations would only follow the lower
` control path between the foreign agent and the home agent.
`
` Any Mobile IP data that is sent by FA through the AAAL to AAAH MUST
` be considered opaque to the AAA servers. Authorization data needed
` by the AAA servers then MUST be delivered to them by the foreign
`
`Glass, et al. Informational [Page 12]
`
`Apple v. Maxell
`