One document matched: draft-ohnishi-mip6-aaa-problem-statement-00.txt
IETF Mobile IPv6 Working Group
Internet Draft H. Ohnishi
Expires: August 2004 M.Yanagiya
NTT
Y.Ohba
Toshiba
February 2004
Mobile IPv6 AAA Problem Statement
<draft-ohnishi-mip6-aaa-problem-statement-00.txt>
Status of this Memo
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
Mobile IP achieves that Mobile Node(MN) moves from one subnet to
another. If MN moves across different administrative domains in a
commercial network, Mobile IPv6 requires AAA's support. This document
describes the problem statement to use AAA functions in Mobile IPv6.
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [i].
Ohnishi, Ed., et al. Expires - August 2004 [Page 1]
MIPv6 AAA problem statement February 2004
Table of Contents
1. Introduction...................................................2
2. AAA usage scenario for Mobile IPv6.............................3
2.1 Roaming to foreign domain..................................3
2.2 Dynamic home address prefix assignment via AAA.............3
2.3 Dynamic HA address assignment via AAA......................3
2.4 Bootstrapping Mobile IPv6 SA from AAA......................3
3. Problem Statement..............................................4
4. Mobile IPv4 AAA solution (informative).........................4
5. Security Consideration.........................................5
Reference.........................................................6
Acknowledgments...................................................6
Author's Addresses................................................7
1. Introduction
Mobile IP(v4/v6) [RFC3344][I-D.ietf-mobileip-ipv6] achieves that
Mobile Node (MN) moves from one subnet to another. If MN moves
across different administrative domains where authentication,
authorization and accounting (AAA) is always an issue especially in
commercial-based deployments. Mobile IPv4 already defines an
interface to AAA functionality [I-D.ietf-mip4-rfc3012bis]
[I-D.ietf-aaa-diameter-mobileip] [I-D.ietf-mip4-aaa-nai]. Mobile
IPv6 requires an interface to AAA as well. However such an interface
has been a missing piece that needs to be filled with an appropriate
solution.
This document describes several usage cases that deemed necessary to
support when Mobile IPv6 is used in an environment where the users
subscribe to commercial Mobile IPv6 services with credentials
(username, password, certificate, etc.) that are used by the
operators as the basis to perform the task of AAA for the Mobile IPv6
services.
The usage cases are described in terms of service bootstrapping and
security, both are important in large-scale deployments. This
document then addresses the fundamental issue that needs to be taken
into account when designing an interface between AAA and Mobile IPv6.
This document also contains informative description on the approach
which is taken by Mobile IPv4 to support AAA, however, it should be
noted that the informative description is not advocating or
recommending the same approach adopted to Mobile IPv4 to be used for
Mobile IPv6.
For more information related to IPv6 address assignment in
3GPP, it is recommended to read [RFC3314].
Ohnishi, Ed. et.al Expires - August 2004 [Page 2]
MIPv6 AAA problem statement February 2004
2. AAA usage scenario for Mobile IPv6
In this section, we show some application that we are going to solve
by using AAA function. 2.1 shows the application to authenticate an
MN when the MN accesses to the visiting network. From 2.2 to 2.4
shows service bootstrapping scenarios. Operators may choose a
combination of scenarios from these for their services.
2.1 Roaming to foreign domain
Mobile IPv6 supports MN's mobility. But if MN moves to a foreign
domain, the foreign domain requires the way of Authentication,
Authorization and Accounting. RFC2977 shows requirements for this
scheme. RFC2977 shows the applications of AAA to the Mobile IP, e.g.
the basic model, the local payment model, the local home agent model
and so on.
2.2 Dynamic home address prefix assignment via AAA
In some cases, operators want to assign home address prefix to mobile
node dynamically for the purpose of reducing management cost, etc.
Mobile IPv6 prescribes Mobile Prefix Solicitation(MPS) and Mobile
Prefix Advertisement(MPA). But in this method, MN needs to know HA
address previously. A solution for dynamically and securely assigning
home address prefix to mobile node with involving an appropriate
authentication and authorization protocol is demanded.
2.3 Dynamic HA address assignment via AAA
In some cases, operators want to assign HA to the MN dynamically from
the perspective of load balancing. Mobile IPv6 prescribes dynamic HA
allocation mechanism in which it sends anycast address to find HA and
the HA sends back HAs' list to the MN. HA sends this list without
authenticating the MN. A solution for dynamically and securely
assigning HA's address to mobile node with involving an appropriate
authentication and authorization protocol is demanded.
2.4 Bootstrapping Mobile IPv6 SA from AAA
Mobile IPv6 [I-D.ietf-mobileip-ipv6] requires an IPsec SA (Security
Association) established between mobile node and its home agent to
protect Binding Updates to the home agent. This SA is referred to as
Mobile IPv6 SA(MSA). When a home agent is dynamically allocated, it
is difficult to assume pre-established security association (such as
an IKE [RFC2409] pre-shared secret) between the mobile node and every
potential home agent, unless a trusted third-party is involved in the
Ohnishi, Ed. et.al Expires - August 2004 [Page 3]
MIPv6 AAA problem statement February 2004
authentication procedure between a mobile node and its home agent.
Among several alternative models (e.g., Kerberos) that rely on a
trusted third-party, there is demand for AAA-based solutions possibly
with leveraging the EAP keying framework [I-D.ietf-eap-keying] which
allows the key material generated by an EAP authentication algorithm
to turn into a credential needed for mutually authenticating mobile
node and home agent in the IPsec key management protocol.
3. Problem Statement
In Mobile IPv4, AAA for network access service and AAA for Mobile
IPv4 service are integrated for optimization purpose. These two
types of AAA are different in functionality
[I-D.ietf-pana-usage-scenarios], and such an integration is possible
in the architecture where an agent that acts as an AAA attendant for
both types of AAA is placed in the visiting network. In the case of
Mobile IPv4, mobility agent itself (i.e., FA) is such an integrated
agent.
In Mobile IPv6 architecture, there is no FA unlike Mobile IPv4. The
fundamental problem that needs to be solved is to support the usage
cases described in Section 2 without introducing FA in Mobile IPv6.
This would lead to a need to define a MIPv6 Service Aware AAA
Attendant (MSAAA), which is an AAA attendant to provide AAA for
Mobile IPv6 service for MN. The MSAAA may be integrated with an AAA
attendant of other protocol or service, or may be integrated with
MIPv6 home agent, depending on Mobile IPv6 service models. The
protocol to transfer information between HA and AAA server is needed
in every above MSAAA deployment scenarios.
4. Mobile IPv4 AAA solution (informative)
Mobile IPv4 defines two different registration procedures, one via
foreign agent that relays the registration to mobile node's home
agent, and the other directly with the mobile node's home agent. Both
registration procedures involve the exchange of Registration Request
and Registration Reply messages. In order to prevent spoofing, Mobile
IPv4 defines authentication extension in Registration Request and
Reply message [RFC3344]. MN sends Registration Request with
authentication extension which includes authenticator to FA or HA. FA
or HA evaluates the authenticator by using shared key or
public/private key pair. In a large scale roaming service network
such as public wireless LAN access service network, it is difficult
to distribute all key material to FA and/or HA. Thus, AAA
architecture is used to manage key materials of MNs or/and verify
credential. Fig 1 shows an example of sequence using RADIUS. It is
assumed that MN does not have a security association with FA. MN
sends Registration Request which includes challenge value and Network
Ohnishi, Ed. et.al Expires - August 2004 [Page 4]
MIPv6 AAA problem statement February 2004
Access Identifier (NAI). According to NAI, FA makes a decision on AAA
message routing, and passes the authenticator to AAA server. AAA
server verifies the authenticator and sends authentication reply. If
an authentication is success, FA sends Agent Reply to MN.
MN FA AAA
|Agent Advertisement | |
|[Challenge ext.] | |
|<---------------------| |
|Registration Request | |
|[MN-FA Challenge Ext.,| |
| MN-HA Auth. ext., | |
| MN-AAA Auth. ext., | |
| NAI. ext.] | |
|--------------------->| |
| |Authentication Request |
| |---------------------> |
| | |
| |Authentication Reply |
| |<--------------------- |
|Registration Reply | |
|(registration accept) | |
|<-------------------- | |
| | |
Figure 1: MN-FA authentication with AAA in Mobile IPv4
In [I-D.ietf-aaa-diameter-mobileip], a similar method is specified by
using Diameter application. MN sends Registration Request to FA. FA
invokes the local AAA infrastructure (AAAF) to request that a mobile
node be authenticated. If AAAF is not aware of the identity of MN,
AAAF will forward authentication data to home AAA server (AAAH).
5. Security Consideration
This draft identifies a need for bootstrapping Mobile IPv6 by
leveraging the AAA infrastructure. Although any solution is not
specified in this document, a AAA-based solution for dynamically
assigning Mobile IPv6 home agent address is expected to improve
Mobile IPv6 security by not relying on the anycast-based scheme built
in Mobile IPv6 but relying on the AAA infrastructure instead. More
security analysis on bootstrapping MSA should be made when designing
a solution. Although security consideration section of
[I-D.ietf-eap-keying] covers general security issues for EAP-based
service bootstrapping, there may be Mobile IPv6 specific security
issues in bootstrapping MSA.
Ohnishi, Ed. et.al Expires - August 2004 [Page 5]
MIPv6 AAA problem statement February 2004
Reference
[RFC3344] C. Perkins, "IP Mobility Support", RFC 3344, August 2002.
[I-D.ietf-mobileip-ipv6] Johnson, D., "Mobility Support in IPv6",
draft-ietf-mobileip-ipv6-24.txt, (work in progress), June 30 2003.
[I-D.ietf-mip4-rfc3012bis] C. Perkins, et al., "Mobile IPv4
Challenge/Response Extensions (revised)",
draft-ietf-mip4-rfc3012bis-00.txt (work in progress), 7 October 2003.
[I-D.ietf-aaa-diameter-mobileip] P. Calhoun, et al., "Diameter Mobile
IP Application", draft-ietf-aaa-diameter-mobileip-15.txt (work in
progress), November 2003.
[I-D.ietf-mip4-aaa-nai] F. Johansson and T. Johansson, "Mobile IPv4
Extension for carrying Network Access Identifiers",
draft-ietf-mip4-aaa-nai-02.txt (work in progress), December 12, 2003
[RFC3314] M. Wasserman, "Recommendations for IPv6 in Third Generation
Partnership Project (3GPP) Standards", RFC 3314, September 2002.
[I-D.ietf-pana-usage-scenarios] Y. Ohba, et al., "Problem Statement
and Usage Scenarios for PANA", draft-ietf-pana-usage-scenarios-06.txt
(work in progress), April 28, 2003.
[RFC2977] S. Glass, et al.,"Mobile IP Authentication, Authorization,
and Accounting Requirements", RFC 2977, October 2000
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998.
[I-D.ietf-eap-keying] Aboba, B., "EAP Key Management Framework",
draft-ietf-eap-keying-01 (work in progress), October 2003.
[I-D.ietf-ipsec-ikev2] Kaufman, C., "Internet Key Exchange (IKEv2)
Protocol", draft-ietf-ipsec-ikev2-12 (work in progress), January 2004.
Acknowledgments
We would like to thank Alper Yegin and Rafa Marin Lopez for their
valuable contributions to the discussions and preparation of this
document.
We also would like to thank Basavaraj Patil and Gopal Dommety for
their encouraging us to submit this document.
Ohnishi, Ed. et.al Expires - August 2004 [Page 6]
MIPv6 AAA problem statement February 2004
Author's Addresses
Hiroyuki Ohnishi
NTT Network service systems laboratories, NTT Corporation
9-11, Midori-Cho, 3-Chome
Musashino-Shi, Tokyo 180-8585
Japan
Phone: +81 422 59 4132
Email: ohnishi.hiroyuki@lab.ntt.co.jp
Mayumi Yanagiya
NTT Network service systems laboratories, NTT Corporation
9-11, Midori-Cho, 3-Chome
Musashino-Shi, Tokyo 180-8585
Japan
Phone: +81 422 59 6783
Email: yanagiya.mayumi @lab.ntt.co.jp
Yoshihiro Ohba
Toshiba America Information Systems, Inc.
9740 Irvine Blvd.
Irvine, CA 92619-1697
USA
Phone: +1 973 829 5174
EMail: yohba@tari.toshiba.com
Ohnishi, Ed. et.al Expires - August 2004 [Page 7]
| PAFTECH AB 2003-2026 | 2026-04-22 22:48:48 |