operator that authenticates a mobile node and authorizes mobility
service is called a mobility service authorizer (MSA). If both types
of operation are performed by the same operator, that operator is
called a home mobility service provider. If authentication and
authorization is provided by one operator and the actual service is
provided by another, the operator providing the service is called the
serving mobility service provider. The serving MSP must contact the
mobile node’s mobility service authorizer to check the mobile node’s
authorization prior to granting mobility service.
The service model defined here clearly separates the entity providing
the service from the entity that authenticates and authorizes the
service. In the case of basic network access, this supports the
traditional and well-known roaming model, in which inter-operator
roaming agreements allow a host to obtain network access in areas
where their home network access provider does not have coverage. In
the case of mobility service, this allows a roaming mobile node to
obtain mobility service in the local operator’s network while having
that service authorized by the home operator. The service model also
allows mobility service and network access service to be provided by
different entities. This allows a network operator with no wireless
access, such as, for example, an enterprise network operator, to
deploy a Mobile IPv6 home agent for mobility service while the actual
wireless network access is provided by the serving network access
providers with which the enterprise operator has a contract. Here
are some other possible combinations of ASPs and MSPs:
o The serving ASP might be the home ASP. Similarly, the serving MSP
might be the home MSP.
o The home ASP and the home MSP may be the same operator, or not.
When they are the same, the same set of credentials may be used
for both services.
o The serving ASP and the serving MSP may be the same operator, or
not.
o It is possible that serving ASP and home MSP are the same
operator.
Similarly the home ASP and serving MSP may be the same. Also, the
ASA and MSA may be the same.
These entities and all combinations that are reasonable from a
deployment perspective must be taken into consideration to solve the
Mobile IPv6 bootstrapping problem. They impact home agent discovery,
home address configuration, and mobile node-to-home agent
authentication aspects.
7. Deployment Scenarios
This section describes the various network deployment scenarios. The
various combinations of service providers described in Section 6 are
considered.
For each scenario, the underlying assumptions are described. The
basic assumption is that there is a trust relationship between mobile
user and the MSA. Typically, this trust relationship is between the
mobile user and AAA in the MSA’s network. Seed information needed to
bootstrap the mobile node is considered in two cases:
o AAA authentication is mandatory for network access.
o AAA authentication is not part of network access.
The seed information is described further in Section 8.
7.1. Mobility Service Subscription Scenario
Many commercial deployments are based on the assumption that mobile
nodes have a subscription with a service provider. In this scenario
the MN has a subscription with an MSA, also called the home MSP, for
Mobile IPv6 service. As stated in Section 6, the MSP is responsible
for setting up a home agent on a subnet that acts as a Mobile IPv6
home link. As a consequence, the home MSP should explicitly
authorize and control the whole bootstrapping procedure.
Since the MN is assumed to have a pre-established trust relationship
with its home provider, it must be configured with an identity and
credentials; for instance, an NAI and a shared secret by some out-
of-band means (i.e., manual configuration) before bootstrapping.
In order to guarantee ubiquitous service, the MN should be able to
bootstrap MIPv6 operations with its home MSP from any possible access
location, such as an open network or a network managed by an ASP,
that may be different from the MSP and that may not have any pre-
established trust relationship with it.
7.2. Integrated ASP Network Scenario
In this scenario, the ASA and MSA are the same entity. The MN has
security credentials for access to the network, and these credentials
can also be used to bootstrap MIPv6.
Figure 1 describes an AAA design example for integrated ASP scenario.
+----------------------------+
| IASP(ASA+MSA) |
+----+ +-----+ +----+ |
| MN |--- | NAS | | HA | |
+----+ +-----+ +----+ |
| \ \ |
| \ +------+ \ +-------+ |
| -|AAA-NA| -|AAA-MIP| |
| +------+ +-------+ |
+----------------------------+
NAS: Network Access Server
AAA-NA: AAA for network access
AAA-MIP: AAA for Mobile IP service
Figure 1. Integrated ASP network
7.3. Third-Party MSP Scenario
Mobility service has traditionally been provided by the same entity
that authenticates and authorizes the subscriber for network access.
This is certainly the only model supported by the base Mobile IPv6
specification.
In the third-party mobility service provider scenario, the
subscription for mobility service is made with one entity (the MSA,
is for instance, a corporate), but the actual mobility service is
provided by yet another entity (such as an operator specializing in
this service, the serving MSP). These two entities have a trust
relationship. Transitive trust among the mobile node and these two
entities may be used to assure the participants that they are dealing
with trustworthy peers.
This arrangement is similar to the visited - home operator roaming
arrangement for network access.
Figure 2 describes an example of a network for the third-party MSP
scenario.
+--------------+ +--------+
| | |Serving |
| ASP | | MSP |
+----+ +-----+ | | +----+ |
| MN |--- | NAS | | | | HA | | +-------------------+
+----+ +-----+ |===| +----+ | | MSA |
| \ | | \ || (e.g., corporate NW)|
| \ +------+ | | \ | +-------+ |
| -|AAA-NA| | | -------|AAA-MIP| |
| +------+ | | | | +-------+ |
+------------ + +--------+ +-------------------+
Figure 2. Third-Party MSP network
7.4. Infrastructure-less Scenario
Infrastructure refers to network entities like AAA, Public-Key
Infrastructure (PKI), and Home Location Register (HLR).
"Infrastructure-less" implies that there is no dependency on any
elements in the network with which the user has any form of trust
relationship.
In such a scenario, there is absolutely no relationship between host
and infrastructure.
A good example of infrastructure-less environment for MIPv6
bootstrapping is the IETF network at IETF meetings. It is possible
that there could be MIP6 service available on this network (i.e., a
MIPv6 HA). However, there is not really any AAA infrastructure or,
for that matter, any trust relationship that a user attending the
meeting has with any entity in the network.
This specific scenario is not supported in this document. The reason
for this is described in Section 9.
8. Parameters for Authentication
The following is a list of parameters that are used as the seed for
the bootstrapping procedure. The parameters vary depending on
whether authentication for network access is independent of
authentication for mobility services. If different client identities
are used for network access and mobility services, authentication for
network access is independent of authentication for mobility
services.
o Parameter Set 1
In this case, authentication for network access is independent of
authentication for mobility services.
If the home agent address is not known to the mobile node, the
following parameter is needed for discovering the home agent
address:
* The domain name or Fully Qualified Domain Name (FQDN) of the
home agent
This parameter may be derived in various ways, such as (but not
limited to) static configuration, use of the domain name from the
network access NAI (even if AAA for network access is not
otherwise used), or use of the domain name of the serving ASP,
where the domain name may be obtained via DHCP in the serving ASP.
If the home agent address is not known but the home subnet prefix
is known, Dynamic Home Agent Address Discovery of Mobile IPv6 may
be used for discovering the home agent address, and the above
parameter may not be used.
When the home agent address is known to the mobile node, the
following parameter is needed for performing mutual authentication
between the mobile node and the home agent by using IKE:
* IKE credentials (*)
In the case where the home agent does not have the entire set of
IKE credentials, the home agent may communicate with another
entity (for example, an AAA server) to perform mutual
authentication in IKE. In such a case, the IKE credentials
include the credentials used between the mobile node and the other
entity. In the case where an AAA protocol is used for the
communication between the home agent and the other entity during
the IKE procedure, AAA for Mobile IPv6 service may be involved in
IKE. If the authentication protocol [RFC4285] is used, the shared
key-based security association with the home agent is needed.
o Parameter Set 2
In this case, some dependency exists between authentication for
network access and authentication for mobility services in that a
security association that is established as a result of
authentication for network access is re-used for authentication
for mobility services.
All required information, including IKE credentials, is
bootstrapped from the following parameter:
* Network access credentials(*)
(*) A pair of an NAI and a pre-shared secret is an example of a set
of credentials. A pair of an NAI and a public key, which may be
provided as a digital certificate, is another example of a set of
credentials.
9. Security Considerations
There are two aspects of security for the Mobile IPv6 bootstrapping
problem:
1. The security requirements imposed on the outcome of the
bootstrapping process by RFC 3775 and other RFCs used by Mobile
IPv6 for security.
2. The security of the bootstrapping process itself, in the sense of
threats to the bootstrapping process imposed by active or passive
attackers.
Note that the two are related; if the bootstrapping process is
compromised, the level of security required by RFC 3775 may not be
achieved.
The following two sections discuss these issues.
9.1. Security Requirements of Mobile IPv6
The Mobile IPv6 specification in RFC 3775 requires the establishment
of a collection of IPsec SAs between the home agent and mobile node
to secure the signaling traffic for Mobile IP, and, optionally, also
to secure data traffic. The security of an IPsec SA required by the
relevant IPsec RFCs must be quite strong. Provisioning of keys and
other cryptographic material during the establishment of the SA
through bootstrapping must be done in a manner such that authenticity
is proved and confidentiality is ensured. In addition, the
generation of any keying material or other cryptographic material for
the SA must be done in a way such that the probability of compromise
after the SA is in place is minimized. The best way to minimize the
probability of such a compromise is to have the cryptographic
material only known or calculable by the two end nodes that share the
SA -- in this case, the home agent and mobile node. If other parties
are involved in establishing the SA (through key distribution, for
example) the process should follow the constraints designed to
provide equivalent security.
RFC 3775 also requires a trust relationship, as defined in Section
1.3, between the mobile node and its home agent(s). This is
necessary, for instance, to ensure that fraudulent mobile nodes that
attempt to flood other mobile nodes with traffic be not only shut off
but tracked down. An infrastructureless relationship as defined in
Section 1.3 does not satisfy this requirement. Any bootstrapping
solution must include a trust relationship between mobile node and
mobility service provider. Solutions that depend on an
infrastructureless relationship are out of scope for bootstrapping.
Another requirement is that a home address be authorized to one
specific host at a time. RFC 3775 requires this so that misbehaving
mobile nodes can be shut down. This implies that, in addition to the
IPsec SA, the home agent must somehow authorize the mobile node for a
home address. The authorization can be either implicit (for example,
as a side effect of the authentication for mobility service) or
explicit. The authorization can either be done at the time the SA is
created or be dynamically managed through a first come, first served
allocation policy.
9.2. Threats to the Bootstrapping Process
Various attacks are possible on the bootstrapping process itself.
These attacks can compromise the process such that the RFC 3775
requirements for Mobile IP security are not met, or they can serve
simply to disrupt the process such that bootstrapping cannot be
completed. Here are some possible attacks:
o An attacking network entity purporting to offer the mobile node a
legitimate home agent address or bootstrapping for the IPsec SAs
may instead offer a bogus home agent address or configure bogus
SAs that allow the home agent to steal the mobile node’s traffic
or otherwise disrupt the mobile node’s mobility service.
o An attacking mobile node may attempt to steal mobility service by
offering up fake credentials to a bootstrapping network entity or
otherwise disrupting the home agent’s ability to offer mobility
service.
o A man in the middle on the link between the mobile node and the
bootstrapping network entity could steal credentials or other
sensitive information and use that to steal mobility service or
deny it to the legitimate owner of the credentials. Refer to
Section 7.15 in [RFC3748] and [AAA-EAP-LLA] for further
information.
o An attacker could arrange for a distributed denial-of-service
attack on the bootstrapping entity, to disrupt legitimate users
from bootstrapping.
In addition to these attacks, there are other considerations that are
important in achieving a good security design. As mobility and
network access authentication are separate services, keys generated
for these services need to be cryptographically separate, to be
separately named, and to have separate lifetimes. This needs to be
achieved even though the keys are generated from the same
authentication credentials. This is necessary because a mobile node
must be able to move from one serving (or roaming) network access
provider to another without needing to change its mobility access
provider. Finally, basic cryptographic processes must provide for
multiple algorithms in order to accommodate the widely varying
deployment needs; the need for replacement of algorithms when attacks
become possible must also be considered in the design.
10. Contributors
This contribution is a joint effort of the problem statement design
team of the Mobile IPv6 WG. The contributors include Basavaraj
Patil, Gerardo Giaretta, Jari Arkko, James Kempf, Yoshihiro Ohba,
Ryuji Wakikawa, Hiroyuki Ohnishi, Mayumi Yanagiya Samita Chakrabarti,
Gopal Dommety, Kent Leung, Alper Yegin, Hannes Tschofenig, Vijay
Devarapalli, and Kuntal Chowdury.
The design team members can be reached at the following email
addresses:
Basavaraj Patil: basavaraj.patil@nokia.com
Gerardo Giaretta: gerardo.giaretta@telecomitalia.it
Jari Arkko: jari.arkko@kolumbus.fi
James Kempf: kempf@docomolabs-usa.com
Yoshihiro Ohba: yohba@tari.toshiba.com
Ryuji Wakikawa: ryuji@sfc.wide.ad.jp
Hiroyuki Ohnishi: ohnishi.hiroyuki@lab.ntt.co.jp
Mayumi Yanagiya: yanagiya.mayumi@lab.ntt.co.jp
Samita Chakrabarti: Samita.Chakrabarti@eng.sun.com
Gopal Dommety: gdommety@cisco.com
Kent Leung: kleung@cisco.com
Alper Yegin: alper.yegin@samsung.com
Hannes Tschofenig: hannes.tschofenig@siemens.com
Vijay Devarapalli: vijayd@iprg.nokia.com
Kuntal Chowdhury: kchowdhury@starentnetworks.com
11. Acknowledgements
Special thanks to James Kempf and Jari Arkko for writing the initial
version of the bootstrapping statement. Thanks to John Loughney and
T.J. Kniveton for their detailed reviews.
12. Informative References
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and
H. Levkowetz, "Extensible Authentication Protocol
(EAP)", RFC 3748, June 2004.
[AAA-EAP-LLA] Mariblanca, D., "EAP lower layer attributes for AAA
protocols", Work in Progress, May 2004.
[RFC2794] Calhoun, P. and C. Perkins, "Mobile IP Network Access
Identifier Extension for IPv4", RFC 2794, March 2000.
[RFC3041] Narten, T. and R. Draves, "Privacy Extensions for
Stateless Address Autoconfiguration in IPv6", RFC 3041,
January 2001.
[RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology",
RFC 3753, June 2004.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility
Support in IPv6", RFC 3775, June 2004.
[RFC3776] Galvin, J., "IAB and IESG Selection, Confirmation, and
Recall Process: Operation of the Nominating and Recall
Committees", BCP 10, RFC 3777, June 2004.
[RFC4283] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K.
Chowdhury, "Mobile Node Identifier Option for Mobile
IPv6 (MIPv6)", RFC 4283, November 2005.
[RFC4285] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K.
Chowdhury, "Authentication Protocol for Mobile IPv6",
RFC 4285, January 2006.
Authors’ Addresses
Alpesh Patel
Cisco
170 W. Tasman Drive
San Jose, CA 95134
USA
Phone: +1 408 853 9580
EMail: alpesh@cisco.com
Gerardo Giaretta
Telecom Italia
via Reiss Romoli 274
Torino 10148
Italy
Phone: +39 011 228 6904
EMail: gerardo.giaretta@telecomitalia.it
Full Copyright Statement
Copyright (C) The Internet Society (2006).
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 provided by the IETF
Administrative Support Activity (IASA).