Mobile IP Working Group S. Glass
INTERNET DRAFT Sun Microsystems
5 October 1999 S. Jacobs
GTE Laboratories
C. Perkins
Nokia Research Center
Mobile IP Authentication, Authorization, and Accounting Requirements
draft-ietf-mobileip-aaa-reqs-00.txt
Status of This Memo
This document is a submission by the mobile-ip Working Group of the
Internet Engineering Task Force (IETF). Comments should be submitted
to the MOBILE-IP@STANDARDS.NORTELNETWORKS.COM mailing list.
Distribution of this memo is unlimited.
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at
any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at:
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at:
http://www.ietf.org/shadow.html.
Abstract
The Mobile IP and 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.
Glass,Jacobs,Perkins Expires 5 April 2000 [Page i]
Internet Draft Mobile IP Requirements for AAA 5 October 1999
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.
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 are 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, 11, 12, 15].
Glass,Jacobs,Perkins Expires 5 April 2000 [Page 1]
Internet Draft Mobile IP Requirements for AAA 5 October 1999
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.
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
Glass,Jacobs,Perkins Expires 5 April 2000 [Page 2]
Internet Draft Mobile IP Requirements for AAA 5 October 1999
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.
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].
Glass,Jacobs,Perkins Expires 5 April 2000 [Page 3]
Internet Draft Mobile IP Requirements for AAA 5 October 1999
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.
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 obtain 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 security
relationships that enable them to securely transact information
locally.
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
Glass,Jacobs,Perkins Expires 5 April 2000 [Page 4]
Internet Draft Mobile IP Requirements for AAA 5 October 1999
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 the
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.
As an example in today's Internet, we can cite the deployment of
RADIUS [14] 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.
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 be know that
it is permissible to allocate the local resources to the client.
Glass,Jacobs,Perkins Expires 5 April 2000 [Page 5]
Internet Draft Mobile IP Requirements for AAA 5 October 1999
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
- 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
Glass,Jacobs,Perkins Expires 5 April 2000 [Page 6]
Internet Draft Mobile IP Requirements for AAA 5 October 1999
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 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.
- The attendant MUST protect against replay attacks.
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
identified the following additional requirements:
- The local AAA server MUST support anonymous access.
- The attendant MUST be able to terminate service to the client
based on policy determination by the AAA 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
Glass,Jacobs,Perkins Expires 5 April 2000 [Page 7]
Internet Draft Mobile IP Requirements for AAA 5 October 1999
have been identified by TR45.6 as part of their involvement with the
Mobile IP working group.
- Support a reliable AAA transport mechanism.
* 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.
* 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
- 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 the foreign and home agents to establish an IPSec
security association to secure the mobile node's tunneled data.
- Provide message integrity and identity authentication on a per
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.
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.
Glass,Jacobs,Perkins Expires 5 April 2000 [Page 8]
Internet Draft Mobile IP Requirements for AAA 5 October 1999
We place the following additional requirements on the AAA services in
order to satisfy such clients.
- Either AAA server MUST be able obtain, or to coordinate the
allocation of, a suitable IP address for the customer.
- 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.
We propose that an unambiguous identifier, such as the Network Access
Identifier (NAI) [1, 6], be used for clients. The NAI could be used
by any client, whether or not it has an IP address, to identify
itself for the purposes of obtaining authorizations. The form of
the NAI ("user@realm") allows AAAL to easily determine the home
domain ("realm") for the client. Both the AAAL and the AAAH can use
the NAI to keep records indexed by the client's specific identity.
Therefore, the NAI is well suited for use in the general AAA model
illustrated in figure 1.
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). 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
Glass,Jacobs,Perkins Expires 5 April 2000 [Page 9]
Internet Draft Mobile IP Requirements for AAA 5 October 1999
traverse the network for initial registration of a Mobile Node, the
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 RFC2002 [13].
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 authentication for Mobile IP registration
- 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.
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,Jacobs,Perkins Expires 5 April 2000 [Page 10]
Internet Draft Mobile IP Requirements for AAA 5 October 1999
Local Domain Home Domain
+--------------+ +----------------------+
| +------+ | | +------+ |
| | | | | | | |
| | AAAL | | | | AAAH | |
| | +-------------------+ | |
| +---+--+ | | +--+---+ |
| | | | | |
| | | | | |
+------+ | +---+--+ | | +--+---+ |
| | | | | | | | | |
| MN +- -|- -+ FA + -- -- -- -- - + HA | |
| | | | | | | | | |
+------+ | +------+ | | +------+ |
| | | |
+--------------+ +----------------------+
Figure 3: AAA Servers with Mobile IP agents
agent from the data supplied by the mobile node. The foreign agent
becomes a translation agent between the Mobile IP registration
protocol and AAA.
As mentioned in section 3, nodes in two separate administrative
domains often must take additional steps to guarantee their security
and privacy. In today's Internet, such security measures may be
provided by using several different algorithms. Some algorithms rely
on the existence of a public-key infrastructure [8]; others rely on
distribution of symmetric keys to the communicating nodes [9]. AAA
servers SHOULD be able to verify credentials using either style in
their interactions with Mobile IP entities.
In order to enable subsequent registrations, the AAA servers MUST
be able to perform some key distribution during the initial Mobile
IP registration process from any particular administrative domain.
Glass,Jacobs,Perkins Expires 5 April 2000 [Page 11]
Internet Draft Mobile IP Requirements for AAA 5 October 1999
This key distribution MUST be able to provide the following security
functions:
- identify or create a security association between MN and
home agent (HA); this is required for the MN to produce the
authentication data for the MN--HA authentication extension,
which is mandatory on Mobile IP registrations.
- identify or create a security association between mobile node and
foreign agent, for use with subsequent registrations at the same
foreign agent, so that the foreign agent can continue to obtain
assurance that the same mobile node has requested the continued
authorization for Mobile IP services.
- identify or create a security association between home agent
and foreign agent, for use with subsequent registrations at
the same foreign agent, so that the foreign agent can continue
to obtain assurance that the same home agent has continued the
authorization for Mobile IP services for the mobile node.
- participate in the distribution of the security association (and
Security Parameter Index, or SPI) to the Mobile IP entities
- The AAA server MUST also be able to validate certificates
provided by the mobile node and provide reliable indication to
the foreign agent.
- The AAAL SHOULD accept an indication from the foreign agent about
the acceptable lifetime for its security associations with the
mobile node and/or the mobile node's home agent. This lifetime
for those security associations SHOULD be an integer multiple of
registration lifetime offered by the foreign agent to the mobile
node.
- The AAA servers SHOULD be able to condition their acceptance of
a Mobile IP registration authorization depending upon whether
the registration requires broadcast or multicast service to the
mobile node tunneled through the foreign agent.
The lifetime of any security associations distributed by the AAA
server for use with Mobile IP SHOULD be great enough to avoid
too-frequent initiation of the AAA key distribution, since each
invocation of this process is likely to cause lengthy delays between
registrations [5]. Registration delays in Mobile IP cause dropped
packets and noticeable disruptions in service. Note that any key
distributed by AAAH to the foreign agent and home agent MAY be used
to initiate Internet Key Exchange (IKE) [7]. Note further that the
mobile node and home agent may well have a security association
established that does not depend upon any action by the AAAH.
5.1. Mobile IP with Dynamic IP Addresses
According to section 4, many people would like their mobile nodes to
be identified by their NAI, and to obtain a dynamically allocated IP
Glass,Jacobs,Perkins Expires 5 April 2000 [Page 12]
Internet Draft Mobile IP Requirements for AAA 5 October 1999
address for use in the foreign domain. These people may often be
unconcerned with details about how their computers implement Mobile
IP, and indeed may not have any knowledge of their home agent or any
security association except that between themselves and the AAAH (see
figure 2.
Mobile IP requires the home address assigned to the mobile node
belong to the same subnet as the Home Agent providing service to the
mobile node. For effective use of IP home addresses, the home AAA
(AAAH) SHOULD be able to select a home agent for use with the newly
allocated home address. In many cases, the mobile node will already
know the address of its home agent, even if the mobile node does
not already have an existing home address. Therefore, the home AAA
(AAAH) MUST be able to coordinate the allocation of a home address
with a home agent that might be designated by the mobile node.
Allocating a home address and a home agent for the mobile would
provide a further simplification in the configuration needs for the
client's mobile node. Currently, in the Proposed Standard Mobile IP
specification [13] a mobile node has to be configured with a home
address and the address of a home agent, as well as with a security
association with that home agent. In contrast, the proposed AAA
features would only require the mobile node to be configured with
its NAI and a secure shared secret for use by the AAAH. The mobile
node's home address, the address of its home agent, the security
association between the mobile node and the home agent, and even the
identity (DNS name or IP address) of the AAAH can all be dynamically
determined as part of Mobile IP initial registration with the
mobility agent in the foreign domain (i.e., a foreign agent with AAA
interface features).
The reason for all this simplification is that the NAI encodes the
client's identity as well as the name of the client's home domain;
this follows existing industry practice for the way NAIs are used
today (see section 4). The home domain name is then available for
use by the local AAA (AAAL) to locate the home AAA serving the
client's home domain. In the general model, the AAAL would also have
to identify the appropriate security association for use with that
AAAH. Section 6 discusses a way to reduce the number of security
associations that have to be maintained between pairs of AAA servers
such as the AAAL and AAAH just described.
5.2. Firewalls and AAA
Mobile IP has encountered some deployment difficulties related to
firewall traversal; see for instance [10]. Since the firewall and
AAA server can be part of the same administrative domain, we propose
that the AAA server SHOULD be able to issue control messages and keys
Glass,Jacobs,Perkins Expires 5 April 2000 [Page 13]
Internet Draft Mobile IP Requirements for AAA 5 October 1999
to the firewall at the boundary of its administrative domain that
will configure the firewall to be permeable to Mobile IP registration
and data traffic from the mobile node.
5.3. Mobile IP with Local Home Agents
+-------------------------+ +--------------+
| +------+ +------+ | | +------+ |
| | | | | | | | | |
| | HA +----+ AAAL | | | | AAAH | |
| | | | +-------------------+ | |
| +-+----+ +---+--+ | | +------+ |
| | | | | Home Domain |
| | +- - - - - + | +--------------+
+------+ | +-+--+-+ |
| | | | | |
| MN +------+ FA | |
| | | | | Local Domain |
+------+ | +------+ |
+-------------------------+
Figure 4: Home Agent Allocated by AAAL
In some Mobile IP models, mobile nodes boot on subnets which are
technically foreign subnets, but the services they need are local,
and hence communication with the home subnet as if they were residing
on the home is not necessary. As long as the mobile node can get an
address routable from within the current domain (be it publicly, or
privately addressed) it can use mobile IP to roam around that domain,
calling the subnet on which it booted its temporary home. This
address is likely to be dynamically allocated upon request by the
mobile node.
In such situations, when the client is willing to use a dynamically
allocated IP address and does not have any preference for the
location of the home network (either geographical or topological),
the local AAA server (AAAL) may be able to offer this additional
allocation service to the client. Then, the home agent will be
located in the local domain, which is likely to be offer smaller
delays for new Mobile IP registrations.
In figure 4, AAAL has received a request from the mobile node to
allocate a home agent in the local domain. The new home agent
receives keys from AAAL to enable future Mobile IP registrations.
From the picture, it is evident that such a configuration avoids
Glass,Jacobs,Perkins Expires 5 April 2000 [Page 14]
Internet Draft Mobile IP Requirements for AAA 5 October 1999
problems with firewall protection at the domain boundaries, such
as were described briefly in section 5.2. On the other hand, this
configuration makes it difficult for the mobile node to receive
data from any communications partners in the mobile node's home
administrative domain. Note that, in this model, the mobile node's
home address is affiliated with the foreign domain for routing
purposes, and that any dynamic update to DNS, to associate the mobile
node's home FQDN with its new IP address, will require insertion of a
foreign IP address into the home DNS server database.
5.4. Mobile IP with Local Payments
+-------------------------+
| +------+ +------+ |
| | | | | |
| | HA +----+ AAAL | |
| | | | | |
| +--+---+ +----+-+ |
| | | |
| +- - - - - + | |
+------+ | +-+--+-+ |
| | | | | |
| MN +- -|- - - - - - - + FA | |
| | | Local Domain | | |
+------+ | +------+ |
+-------------------------+
Figure 5: Local Payment for Local Mobile IP services
Since the AAAL is expected to be enabled to allocate a local home
agent upon demand, we can make a further simplification. In cases
where the AAAL can manage any necessary authorization function
locally (e.g., if the client pays with cash or a credit card), then
there is no need for an AAA protocol or infrastructure to interact
with the AAAH. The resulting simple configuration is illustrated in
figure 5.
In this simplified model, we may consider that the role of the AAAH
is taken over either by the national government (in the case of a
cash payment), or by a card authorization service if payment is by
credit card. Then, the AAAL expects those external authorities to
guarantee the value represented by the client's payment credentials
(cash or credit). There are likely to be other cases where clients
are granted access to local resources, or access to the Internet,
without any charges at all. Such configurations may be found in
Glass,Jacobs,Perkins Expires 5 April 2000 [Page 15]
Internet Draft Mobile IP Requirements for AAA 5 October 1999
airports and other common areas where business clients are likely to
spend time. The service provider may find sufficient reward in the
goodwill of the clients, or from advertisements displayed on Internet
portals that are to be used by the clients. In such situations, the
AAAL SHOULD still allocate a home agent, appropriate keys, and the
mobile node's home address.
5.5. Fast Handover
Since the movement from cell to cell may be frequent in Mobile IP
networks, it is imperative that the latency involved in the handoff
process be minimized. When the mobile node enters a new visited
subnet, it would be desirable for it to provide the previous foreign
agent's NAI. The new FA can use this information to either contact
the previous FA to retrieve the KDC session key information, or it
can attempt to retrieve the keys from the AAAL. If the AAAL cannot
provide the necessary keying information, the request will have to be
sent to the mobile node's AAAH to retrieve new keying information.
After initial authorization, further authorizations SHOULD be done
locally within the Local Domain.
6. Broker Model
The picture in Figure 1 shows a configuration in which the local
and the home authority have to share trust. This configuration
causes a quadratic growth in the number of trust relationships as
the number of AAA authorities (AAAL and AAAH) increases. This has
been identified as a problem by the roamops working group [3], and
any AAA proposal MUST solve this problem. Using brokers solves
many of the scalability problems associated with requiring direct
business/roaming relationships between every two administrative
domains. A broker may play the role of a proxy between two
administrative domains which have security associations with the
broker, and relay AAA messages back and forth securely.
Alternatively, a broker may also enable the two domains with which
it has associations, but the domains themselves do not have a
direct association, in establishing a security association, thereby
bypassing the broker for carrying the messages between the domains.
This may be established by virtue of having the broker relay a
shared secret key to both the domains that are trying to establish
secure communication and then have the domains use the keys supplied
by the broker in setting up a security association. Since the
broker is the one who assists the two domains in setting up a secure
association, the domains can be assured of receiving payments for
services offered. This mechanism also reduces latency in the transit
Glass,Jacobs,Perkins Expires 5 April 2000 [Page 16]
Internet Draft Mobile IP Requirements for AAA 5 October 1999
of messages between the domains after the broker has completed its
involvement.
Local Domain Home Domain
+--------------+ +----------------------+
| +------+ | +------+ | +------+ |
| | | | | | | | | |
| | AAAL +-------+ AAAB +--------+ AAAH | |
| | | | | | | | | |
| +------+ | +------+ | +------+ |
| | | | |
| | | +----------------------+
+------+ | +---+--+ |
| | | | | | C = client
| C +- -|- -+ A | | A = attendant
| | | | | | AAAL = local authority
+------+ | +------+ | AAAH = home authority
| | AAAB = broker authority
+--------------+
Figure 6: AAA Servers Using a Broker
The AAAB in figure 6 is the broker's authority server. The broker
acts as a settlement agent, providing security and a central point of
contact for many service providers and enterprises.
The AAAB enables the local and home domains to cooperate without
requiring each of the networks to have a direct business or security
relationship with all the other networks. Thus, brokers offer the
needed scalability for managing trust relationships between otherwise
independent network domains. Use of the broker does not preclude
managing separate trust relationships between domains, but it does
offer an alternative to doing so. Just as with the AAAH and AAAL
(see section 5), data specific to Mobile IP control messages MUST
NOT be processed by the AAAB. Any credentials or accounting data to
be processed by the AAAB must be present in AAA message units, not
extracted from Mobile IP protocol extensions.
Glass,Jacobs,Perkins Expires 5 April 2000 [Page 17]
Internet Draft Mobile IP Requirements for AAA 5 October 1999
The following requirements come mostly from [2], which discusses
use of brokers in the particular case of authorization for roaming
dial-up users.
- allowing management of trust with external domains by way of
brokered AAA.
- accounting reliability. Accounting data that traverses
the Internet may suffer substantial packet loss. Since
accounting packets may traverse one or more intermediate
authorization points (e.g., brokers), retransmission is needed
from intermediate points to avoid long end-to-end delays.
- End to End security. The Local Domain and Home Domain must be
able to verify signatures within the message, even though the
message is passed through an intermediate authority server.
- Since the AAAH in the home domain MAY be sending sensitive
information, such as registration keys, the broker MUST be able
to pass encrypted data between the AAA servers.
The need for End-to-End security results from the following attacks
which were identified when brokered operation uses RADIUS [14]
(see [2] for more information on the individual attacks):
+ Message editing
+ Attribute editing
+ Theft of shared secrets
+ Theft and modification of accounting data
+ Replay attacks
+ Connection hijacking
+ Fraudulent accounting
These are serious problems which cannot be allowed to persist in any
acceptable AAA protocol and infrastructure.
7. Security Considerations
This is a requirements draft for AAA based on Mobile IP. Because AAA
is security driven, most of this document addresses the security
considerations AAA MUST make on behalf of Mobile IP. As with any
security proposal, adding more entities that interact using security
protocols creates new administrative requirements for maintaining
the appropriate security associations between the entities. In the
case of the AAA services proposed however, these administrative
requirements are natural, and already well understood in today's
Internet because of experience with dial up network access.
Glass,Jacobs,Perkins Expires 5 April 2000 [Page 18]
Internet Draft Mobile IP Requirements for AAA 5 October 1999
8. Acknowledgements
Thanks to Tom Hiller, Gopal Dommety, and Basavaraj Patil for
participating in the Mobile IP subcommittee of the aaa-wg which was
charged with formulating the requirements detailed in this document.
Thanks to N. Asokan for perceptive comments to the mobile-ip mailing
list. Some of the text of this document was taken from a draft
co-authored by Pat Calhoun.
The requirements in section 5.5 and section 3.1 were taken from
a draft submitted by members of the TIA's TR45.6 Working Group.
We would like to acknowledge the work done by the authors of that
draft: Tom Hiller, Pat Walsh, Xing Chen, Mark Munson, Gopal Dommety,
Sanjeevan Sivalingham, Byng-Keun Lim, Pete McCann, Brent Hirschman,
Serge Manning, Ray Hsu, Hang Koo, Mark Lipford, Pat Calhoun, Eric
Jaques, Ed Campbell, and Yingchun Xu.
References
[1] B. Aboba and M. Beadles. RFC 2486: The Network Access
Identifier, January 1999. Status: PROPOSED STANDARD.
[2] B. Aboba and J. Vollbrecht. Proxy chaining and policy
implementation in roaming. draft-ietf-roamops-auth-10.txt,
February 1999. (work in progress).
[3] B. Aboba and G. Zorn. RFC 2477: Criteria for evaluating
roaming protocols, December 1998. Status: INFORMATIONAL.
[4] S. Bradner. Key Words for Use in RFCs to Indicate Requirement
Levels. RFC 2119, March 1997.
[5] Ramon Caceres and Liviu Iftode. Improving the Performance
of Reliable Transport Protocols in Mobile Computing
Environments. IEEE Journal on Selected Areas in Communications,
13(5):850--857, June 1995.
[6] Pat R. Calhoun and Charles E. Perkins. Mobile IP Network
Address Identifier Extension. draft-ietf-mobileip-mn-nai-04.txt,
September 1999. (work in progress).
[7] D. Harkins and D. Carrel. RFC 2409: The Internet Key Exchange
(IKE), November 1998. Status: PROPOSED STANDARD.
[8] et. al. Housley, R. Internet Public Key Infrastructure X.509
Certificate and CRL Profile. draft-ietf-pkix-ipki-part1-06.txt,
October 1997. (work in progress).
Glass,Jacobs,Perkins Expires 5 April 2000 [Page 19]
Internet Draft Mobile IP Requirements for AAA 5 October 1999
[9] J. Kohl and C. Newman. The Kerberos Network Authentication
Service (V5). RFC 1510, September 1993.
[10] G. Montenegro and V. Gupta. Sun's SKIP Firewall Traversal for
Mobile IP. RFC 2356, June 1998.
[11] Charles Perkins. IP Encapsulation within IP. RFC 2003, May
1996.
[12] Charles Perkins. Minimal Encapsulation within IP. RFC 2004,
May 1996.
[13] C. Perkins, Editor. IP Mobility Support. RFC 2002, October
1996.
[14] C. Rigney, A. Rubens, W. Simpson, and S. Willens. Remote
Authentication Dial In User Service (RADIUS). RFC 2138, April
1997.
[15] J. Solomon and S. Glass. Mobile-IPv4 Configuration Option for
PPP IPCP. RFC 2290, February 1998.
Glass,Jacobs,Perkins Expires 5 April 2000 [Page 20]
Internet Draft Mobile IP Requirements for AAA 5 October 1999
Addresses
The working group can be contacted via the current chairs:
Basavaraj Patil Phil Roberts
Nortel Networks Inc. Motorola
2201 Lakeside Blvd. 1501 West Shure Drive
Richardson, TX. 75082-4399 Arlington Heights, IL 60004
USA USA
Phone: +1 972-684-1489 Phone: +1 847-632-3148
EMail: bpatil@nortelnetworks.com EMail: QA3445@email.mot.com
Questions about this memo can be directed to:
Pat R. Calhoun Gopal Dommety
Network and Security Center IOS Network Protocols
Sun Microsystems Laboratories Cisco Systems, Inc.
15 Network Circle 170 West Tasman Drive
Menlo Park, California 94025 San Jose, CA 95134-1706
USA USA
Phone: +1 650-786-7733 Phone: +1-408-525-1404
pcalhoun@eng.sun.co EMail: gdommety@cisco.com
Fax: +1 650-786-6445 Fax: +1 408-526-4952
Steven M. Glass Stuart Jacobs
Sun Microsystems Secure Systems Department
1 Network Drive GTE Laboratories
Burlington, MA 40 Sylvan Road
01803 Waltham, MA 02451-1128
USA USA
Phone: +1-781-442-0504 Phone: +1 781-466-3076
EMail: steven.glass@sun.com EMail: sjacobs@gte.com
Fax: +1 781-466-2838
Basavaraj Patil Charles E. Perkins
Wireless Technology Labs Communications Systems Lab
Nortel Networks Nokia Research Center
2221 Lakeside Blvd. 313 Fairchild Drive
Richardson, TX 75082-4399 Mountain View, California
94043
USA USA
Phone: +1 972-684-1489 Phone: +1-650 625-2986
EMail: bpatil@nortelnetworks.com EMail:
charliep@iprg.nokia.com
Fax: +1 972-685-3207 Fax: +1 650 691-2170
Glass,Jacobs,Perkins Expires 5 April 2000 [Page 21]
