| | AAAL | | | | AAAH | |
| | +-------------------+ | |
| +---+--+ | | +------+ |
| | | | |
| | | +----------------------+
+------+ | +---+--+ |
| | | | | | MN = mobile node
| MN |- -|- -| FA | | FA = foreign agent
| | | | | | AAAL = local authority
+------+ | +------+ | AAAH = home authority
| |
+--------------+
Figure 7: AAA Servers in Home and Local Domains
The foreign agent often does not have direct access to the data
needed to verify the credentials. Instead, the foreign agent is
expected to consult an authority (typically in the same foreign
domain) in order to request proof that the mobile node has acceptable
credentials. Since the foreign agent and the local authority (AAAL)
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 mobile node. In contrast to the foreign agent, however, the AAAL
is expected to be configured with enough information to negotiate the
verification of mobile node credentials with its home domain. The
home and foreign domains should be configured with sufficient IP
Security Associations (i.e., IPsec) and access controls so that they
can negotiate the authorization, and also enable the mobile node to
acquire Mobility Security Associations with the mobility agents
within the foreign domain. For the purposes of the key exchanges
specified within this document, the authorization is expected to
depend only upon secure authentication of the mobile node’s
credentials.
Once the authorization has been obtained by the local authority, and
the authority has notified the foreign agent about the successful
negotiation, the foreign agent can deliver the Registration Reply to
the mobile node along with the key material.
In figure 7, there might be many mobile nodes from many different
Home Domains. Each Home Domain provides a AAAH that can check
credentials originating from mobile nodes administered by that Home
Domain. There is a security model implicit in figure 7, and it is
crucial to identify the specific security associations assumed in the
security model. These IP Security Associations are illustrated in
figure 8, and are considered to be relatively long-lived security
associations.
First, it is natural to assume that the mobile node has an AAA
Security Association with the AAAH, since that is roughly what it
means for the mobile node to belong to the home domain.
Second, from the model illustrated in figure 7 it is clear that AAAL
and AAAH have to share an IP 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 IP Security Associations is, however, in the
end not scalable; the AAA framework must provide for more scalable
mechanisms, but the methods by which such a broker model is to be
created are out of scope for this document. See RFC 2977 for more
details.
Finally, from figure 7, it is clear that the foreign agent can
naturally share an IP Security Association with the AAAL. This is
necessary in order for the model to work because the foreign agent
has to have a way to find out that it is permissible to allocate the
local resources to the mobile node, and further to transmit any
successful Registration Reply to the mobile node.
Figure 8 illustrates the IP Security Associations we understand from
our proposed model. Note that there may be, by mutual agreement
between AAAL and AAAH, a third party inserted between AAAL and AAAH
to help them arbitrate secure transactions in a more scalable
fashion. The broker model which has been designed to enable such
third-party processing should not have any effect on the Mobile IP
extensions specified in this document, and so no description is
provided here; see RFC 2977 [13] for more details.
+------+ +------+
| | | |
| AAAL +--------------+ AAAH |
| | | |
+---+--+ +--+---+
| |
| |
+---+--+ +--+---+
MN = mobile node | | | |
FA = foreign agent | FA | | MN |
AAAL = local authority | | | |
AAAH = home authority +------+ +------+
Figure 8: IP Security Associations
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 IP Security Associations between the AAA servers to
be beyond the scope of this document. The choices are unlikely to
depend upon Mobile IP, or any specific features of the general model
illustrated in figure 7. On the other hand, the Mobility Security
Associations needed between Mobile IP entities are of central
importance in the design of the key derivation extensions in this
document.
One further detail deserves mention. The Mobility Security
Association to be established between the mobile node and the foreign
agent has to be communicated to the foreign agent as well as to the
mobile node. The following requirements are placed on the mechanism
used by the AAA infrastructure to effect key distribution:
- The AAAH must establish strong, fresh session keys.
- The mechanism must maintain algorithm independence, allowing for
the distribution of authentication algorithm identification along
with the keys.
- The mechanism must include replay detection.
- The mechanism must authenticate all parties, including the AAA
servers and the FA and HA.
- The mechanism must provide for authorization of the client, FA,
and HA.
- The mechanism must not rely on plaintext passwords.
- The mechanism must maintain confidentiality of session keys.
- The mechanism must uniquely name session keys.
- The mechanism must be such that the compromise of a single FA and
HA cannot compromise any other part of the system, including
session keys and long-term keys
- The mechanism must bind key(s) to an appropriate context
- The mechanism must not expose the keys to entities other than the
AAAH and FA (or HA in the case of key distribution to the HA).
The way that the key is distributed to the foreign agent (or home
agent) is expected to be handled as part of the AAA protocol
processing between the AAAH and AAAL, and the further AAA protocol
processing between the AAAL and the foreign agent. Such processing
is outside the scope of this document, but must satisfy the above
requirements.
Appendix B. Message Flow for Requesting and Receiving Registration Keys
In this section, we show message flows for requesting and receiving a
registration key from the AAA infrastructure, described in section A.
Challenge values, as specified in [3], might be added to the
Advertisement and Registration messages for additional replay
protection, but are not illustrated here.
Diagram 9 illustrates the message flow for the case when the mobile
node explicitly requests keying material to create registration keys.
MN FA AAA Infrastructure
| | |
|<--- Advertisement-----| |
| (if needed) | |
| | |
|-- RReq+AAA Key Req.-->| |
| |--- RReq + AAA Key Req.--->|
| | |
| |<--- RRep + AAA Key Rep.---|
|<-- RRep+AAA Key Rep.--| |
| | |
Figure 9: Message Flows for Requesting and
Receiving Key Generation Nonce
In diagram 9, the following message flow is illustrated:
1. The foreign agent disseminates an Agent Advertisement. This
advertisement MAY have been produced after receiving an Agent
Solicitation from the mobile node (not shown in the diagram).
2. The mobile node creates a Registration Request including the MN-HA
AAA KeyGen Request and/or MN-FA AAA KeyGen Request, as needed,
along with an authorization-enabling authentication extension as
required by Mobile IP [1].
3. The foreign agent relays the Registration Request and/or Key
Request(s) to its locally configured AAA Infrastructure (see
appendix A), according to local policy.
4. The foreign agent receives a AAA Response with the appropriate
indications for authorizing connectivity for the mobile node.
Along with this AAA Response, the foreign agent may also receive
key material by some secure method appropriate for communications
between it and its local AAA infrastructure. At this point if the
foreign agent has not relayed the Registration Request, it
forwards it directly to the Home Agent and waits for a
Registration Reply (not shown in the figure).
5. The foreign agent relays the Registration Reply to the mobile
node, along with the new AAA KeyGen Reply extensions to be used by
the mobile node to establish Mobility Security Associations with
the relevant mobility agents (foreign agent and/or home agent).
Diagram 10 illustrates the message flow for the case when the mobile
node receives unsolicited keying material from the AAA
Infrastructure.
MN FA AAA Infrastructure
| | |
|<--- Advertisement-----| |
| (if needed) | |
| | |
| ------ RReq --------->| |
| |------- RReq ------------->|
| | |
| |<--- RRep + AAA Key Rep.---|
|<-- RRep+AAA Key Rep.--| |
| | |
Figure 10: Message Flow for Receiving Unsolicited
Key Generation Nonce
In diagram 10, the following message flow is illustrated:
1. The foreign agent disseminates an Agent Advertisement. This
advertisement MAY have been produced after receiving an Agent
Solicitation from the mobile node (not shown in the diagram).
2. The mobile node creates a Registration Request including an
authorization-enabling authentication extension as required by
Mobile IP [1].
3. The foreign agent sends a AAA Request (possibly containing the
Registration Request) to its locally configured AAA Infrastructure
(see appendix A), according to local policy.
4. The foreign agent receives a AAA Response with the appropriate
indications for authorizing connectivity for the mobile node.
Along with this AAA Response, the foreign agent may also receive
key material by some secure method appropriate for communications
between it and its local AAA infrastructure. At this point, if
the foreign agent has not relayed the Registration Request, it
forwards it directly to the Home Agent and waits for a
Registration Reply (not shown in the figure).
5. The foreign agent relays the Registration Reply to the mobile
node, along with the new KeyGen Reply extensions to be used by the
mobile node to establish Mobility Security Associations with the
relevant mobility agents (foreign agent and/or home agent).
Authors’ Addresses
Charles E. Perkins
Nokia Research Center
313 Fairchild Drive
Mountain View, California 94043
USA
Phone: +1 650 625-2986
Fax: +1 650 625-2502
EMail: charles.perkins@nokia.com
Pat R. Calhoun
Airespace, Inc.
110 Nortech Parkway
San Jose, CA 95134
USA
Phone: +1 408 635 2000
Fax: +1 408 635 2020
EMail: pcalhoun@airespace.com
Full Copyright Statement
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.