©À
Network Working Group A. Yegin
Internet-Draft Samsung AIT
Expires: January 30, 2005 August 2004
AAA Mobile IPv6 Application Framework
draft-yegin-mip6-aaa-fwk-00.txt
Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with
RFC 3668.
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.
This Internet-Draft will expire on January 30, 2005.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
This document describes a framework for using AAA backend protocols
(e.g., RADIUS, Diameter) between home agents and AAA servers for
centralizing Mobile IPv6 service management. Implementation of this
framework requires definition of a new AAA application on the
aforementioned protocols.
Yegin Expires January 30, 2005 [Page 1]
Internet-Draft MIP6 AAA August 2004
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. New AAA Application . . . . . . . . . . . . . . . . . . . . . 8
4. Relation to Mobile IPv6 Bootstrapping . . . . . . . . . . . . 9
5. Other Ways to Talk About Mobile IPv6 and AAA . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.1 Normative References . . . . . . . . . . . . . . . . . . . . 13
8.2 Informative References . . . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 15
Intellectual Property and Copyright Statements . . . . . . . . 16
Yegin Expires January 30, 2005 [Page 2]
Internet-Draft MIP6 AAA August 2004
1. Introduction
AAA backend protocols, such as RADIUS [RFC2865] and Diameter
[RFC3588], enable centralized management of authentication,
authorization, and accounting (AAA) for a limited type of services
(Mobile IPv4 [I-D.ietf-aaa-diameter-mobileip], network access
[I-D.ietf-aaa-diameter-nasreq], SIP [I-D.ietf-aaa-diameter-sip-app]).
Currently there is no standard mechanism to centralize AAA for Mobile
IPv6 [RFC3775]" services.
The current Mobile IPv6 protocol design assumes pre-established
static configuration between a mobile node (MN, the client) and a
home agent (HA, the server) for authentication and authorization of
the mobility service. Although there are no standard protocols to
retrieve accounting information from a HA yet, SNMP will be useful in
the near future with the development of Mobile IPv6 MIBs
[I-D.ietf-mip6-mipv6-mib].
The distributed AAA management model could be sufficient in the
presence of one static HA per MN, but this is not always the case.
In the presence of multiple HAs on a home subnet, reliance on
pre-configuration increases the network management overhead.
Additionally, there may be more than one home subnet that can be used
by a mobile node, in which case the number of possible HAs is further
increased. A central AAA infrastructure that is in charge of
authentication, authorization, and accounting for the Mobile IPv6
service between any MN and any HA in a domain would benefit
deployments by preventing AAA information replication and management
across the domain.
Furthermore, at times Mobile IPv6 service may have to cross operator
domain boundaries. For example, an (serving) operator may wish to
provide Mobile IPv6 service to another operator's customers for whom
it does not have any per-MN configuration in its local servers. A
scalable and secure Mobile IPv6 roaming service
[I-D.ietf-mip6-bootstrap-ps] cannot be made possible by solely
relying on the HA pre-configuration. The MN can only be
authenticated and authorized by an entity in its home operatorÇÖs
domain. The serving HA has to get in touch with the local AAA
infrastructure, which in turn must contact the AAA infrastructure of
the home operator. Upon successful authorization and delivery of the
service, associated accounting information can be delivered from the
serving operator to the home operator.
This document describes AAA Mobile IPv6 application framework that
enables AAA centralization and roaming for Mobile IPv6 services.
There is more than one way to use AAA technologies with Mobile IPv6.
The reader should note that the framework advocated in this document
Yegin Expires January 30, 2005 [Page 3]
Internet-Draft MIP6 AAA August 2004
constitutes only a subset of those possibilities. See Section 5 for
more on this subject.
Yegin Expires January 30, 2005 [Page 4]
Internet-Draft MIP6 AAA August 2004
2. Framework
The following figure depicts the interaction among various entities
using AAA for Mobile IPv6.
Mobile <---------------> Home agent/ <--------------> AAA
node Mobile IPv6, AAA client RADIUS or server
IKE Diameter
Figure 1: MIP6-AAA framework
In this framework, Mobile IPv6 protocol is executed between the MN
and the HA, as it normally would. Unlike a HA that relies on the
preconfigured information, the AAA-enabled HA (more precisely: AAA
client on HA) communicates with a AAA server in order to authenticate
and authorize the MN before starting the Mobile IPv6 service, and
later for making the accounting information available.
The current Mobile IPv6 design relies on use of IPsec for
authentication of protocol signaling between the MN and the HA. The
associated IPsec SA is created by running IKE [RFC3776] between the
two. The initial authentication and authorization of MN and HA
should be performed during the IKE execution. This is where HA must
consult the AAA infrastructure. The authorization at this stage is
for establishing an IPsec SA for Mobile IPv6 service. Authorization
parameters (e.g., max allowed lifetime) for the subsequent Mobile
IPv6 binding updates may also be delivered to the HA at this stage.
Upon successful IPsec SA establishment for Mobile IPv6 service, MN
can send binding updates to the HA. By the help of IPsec SA, the HA
can authenticate the MN without AAA serverÇÖs help. Furthermore,
the HA can also authorize the binding update if it already has the
authorization parameters from its earlier interaction with the AAA
server. Otherwise, the HA must contact the AAA server again to
perform binding update authorization.
Figure 2 is an illustration of a Mobile IPv6 session that starts with
IPsec SA establishment and includes one initial and one refreshing
binding updates.
Yegin Expires January 30, 2005 [Page 5]
Internet-Draft MIP6 AAA August 2004
MN HA AAA server
| | Auth/Authz for |
| IKE | MIPv6 IPsec SA |
|<------------------->|<-------------------->|
| | |
| Binding Update | Authz for BU |
|<------------------->|<-------------------->|
| | |
| | |
| | |
| Binding Update | Authz for BU |
|<------------------->|<-------------------->|
| | |
v
time
Figure 2: Message flow
Accounting-oriented HA-AAA interaction can take place any time MN is
authorized for the service, and it can be piggybacked with the
authentication/authorization messaging.
This framework is built upon following trust model.
(1) (2)
HA <------> AAA server <------> MN
^ ^
. .
................................
(3)
Figure 3: Trust model
It is assumed that HA-AAA (1) and MN-AAA (2) trust relations are
pre-configured. HA-AAA may have an indirect trust relation, that
spans multiple intermediate server and operator domains. MN-HA (3)
trust relation is dynamically created as a result of the AAA
interaction. MN can create trust relations with several HAs. These
trust relations should not outlive neither the MN-AAA nor the HA-AAA
trust relations.
An instance of this framework that relies on EAP-based authentication
is depicted in Figure 4.
Yegin Expires January 30, 2005 [Page 6]
Internet-Draft MIP6 AAA August 2004
Mobile <---------------> Home agent/ <--------------> AAA
node Mobile IPv6, AAA client EAP/RADIUS server
EAP/IKEv2
Figure 4: EAP-based IKE authentication
EAP [RFC3748] can provide end-to-end authentication between the MN
and AAA server. It can be used for IPsec SA authentication and
authorization by being transported on IKEv2 between the MN and HA,
and by a AAA-backend protocol between the HA and AAA. EAP framework
enables authentication between the peer (MN) and authentication
server (AAA server) via an authenticator (HA), and produces a
security association between the peer and the authenticator as a
result. While the produced security association is not an IPsec SA,
it can be used in building one. EAP is not used with Mobile IPv6
binding update authentication and authorization.
This framework can also be used with scenarios where other
authentication methods (non-EAP-based) are used with IKE.
Furthermore, future extensions to Mobile IPv6 specification may
involve IPsec/IKEless operation [I-D.ietf-mip6-auth-protocol]. They
should readily fit this framework as well.
[TBD: Consider using AAA with the CN as well. Now that alternatives
to RR-based BU security are being considered, and MN-CN pre-shared
key concept is around, leveraging AAA may come into the picture.]
Yegin Expires January 30, 2005 [Page 7]
Internet-Draft MIP6 AAA August 2004
3. New AAA Application
The architectural differences between Mobile IPv4 and Mobile IPv6
necessitate different AAA application framework for each.
Mobile IPv4 involves an intermediate server between the MN and the
HA, namely foreign agent (FA) which can be co-located with a network
access server (NAS). This impacts the end-to-end AAA flow.
The signaling authentication is built-in with the Mobile IPv4
protocol, whereas an additional protocol (IPsec) is used for Mobile
IPv6. Use of IPsec requires yet another protocol (IKE) for session
establishment. This nature of Mobile IPv6 leads to additional
authentication and authorization exchanges between the HA and AAA
server. The triggering event dictates the nature of exchange (e.g.,
for authentication and authorization of a Mobile IP IPsec SA
creation, vs. authorization of a Mobile IPv6 binding update). In
Mobile IPv4, a single interaction between the serving agent (FA or
HA) and the AAA server is sufficient to accomplish authentication and
authorization of a registration request (equivalent of a Mobile IPv6
binding update).
The new AAA application is required to associate a given
authorization and accounting to the Mobile IPv6 service. When a AAA
client contacts a AAA server, it should be able to convey that the
request is for Mobile IPv6 service, as opposed to any other services
(network access, SIP, etc.). Additionally, service authorization
should take into account parameters like home address and binding
lifetime, which are specific to a Mobile IPv6 service. Finally,
accounting should support Mobile IPv6-specific MIBs
[I-D.ietf-mip6-mipv6-mib]. A formal list of requirements on this
interface must be worked out [TBD: future work].
Yegin Expires January 30, 2005 [Page 8]
Internet-Draft MIP6 AAA August 2004
4. Relation to Mobile IPv6 Bootstrapping
Mobile IPv6 bootstrapping mechanisms [I-D.ietf-mip6-bootstrap-ps] are
potentially useful for providing three pieces of information to a MN:
HA address or home subnet prefix, home address, and a security
association between the MN and HA. The security association does not
have to be an IPsec SA, but something that helps creation of an IPsec
SA eventually.
Use of this framework assumes the MN already knows the HA address.
Hence an implementation of this framework cannot help with HA
discovery.
The security association between MN and HA can be created by using
the HA-AAA interface (see EAP-based example).
Home address can be obtained before or after running the AAA
protocol. For example, the home address may be known by the MN by
the time it engages in IKE or Mobile IPv6 with the HA, or it may be
dynamically assigned by the HA or the AAA server. An implementation
of the framework should work with any of these options.
Overall, this framework can be used as part of a Mobile IPv6
bootstrapping operation, but not necessarily as a complete solution
to that problem.
Yegin Expires January 30, 2005 [Page 9]
Internet-Draft MIP6 AAA August 2004
5. Other Ways to Talk About Mobile IPv6 and AAA
Talking about AAA does not make sense without specifying the
associated service. There is a difference between AAA for network
access and AAA for Mobile IPv6 services [8]. This distinction may be
blurry in certain cases (e.g., when Mobile IPv4 authentication is
used for network access as well), but otherwise they are at least
logically separate services.
There are several ways to mix the keywords ǣMobile IPv6ǥ with
Ç£AAAÇ¥ in addition the one described in this document. They are
listed here for the sake of identification, but not necessarily for
advocating them.
(a) Using network access AAA to deliver Mobile IPv6 bootstrapping
information directly to a node (MN)
[I-D.giaretta-mip6-authorization-eap][I-D.le-aaa-mipv6-requirements]
[I-D.ohnishi-mip6-aaa-problem-statement].
(b) Using network access AAA to deliver Mobile IPv6 bootstrapping
information to the network access server (NAS)
[I-D.chowdhury-mip6-bootstrap-radius]. It is assumed that the
information is delivered from NAS to the MN via some additional
protocol [I-D.jang-dhc-haopt]
(c) Piggybacking Mobile IPv6 signaling with network access AAA
[I-D.le-aaa-mipv6-requirements] This approach assumes that the AAA
servers for network access and Mobile IPv6 services are the same.
Yegin Expires January 30, 2005 [Page 10]
Internet-Draft MIP6 AAA August 2004
6. Security Considerations
The framework defined in this document is aligned with the AAA
backend protocols and the existing AAA applications. Therefore there
are no new security considerations stemming from the general
framework.
Details of the authorization are Mobile IPv6 specific. Exact
parameters, their semantics and processing details must be described
in an implementation of this framework.
Yegin Expires January 30, 2005 [Page 11]
Internet-Draft MIP6 AAA August 2004
7. Acknowledgements
Thanks to Kent Leung and Alpesh Patel for useful feedback.
Yegin Expires January 30, 2005 [Page 12]
Internet-Draft MIP6 AAA August 2004
8. References
8.1 Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
8.2 Informative References
[I-D.chowdhury-mip6-bootstrap-radius]
Chowdhury, K. and A. Lior, "RADIUS Attributes for Mobile
IPv6 bootstrapping",
draft-chowdhury-mip6-bootstrap-radius-00 (work in
progress), July 2004.
[I-D.giaretta-mip6-authorization-eap]
Giaretta, G., "MIPv6 Authorization and Configuration based
on EAP", draft-giaretta-mip6-authorization-eap-01 (work in
progress), July 2004.
[I-D.ietf-aaa-diameter-mobileip]
Calhoun, P., Johansson, T., Perkins, C. and T. Hiller,
"Diameter Mobile IPv4 Application",
draft-ietf-aaa-diameter-mobileip-20 (work in progress),
August 2004.
[I-D.ietf-aaa-diameter-nasreq]
Calhoun, P., Zorn, G., Spence, D. and D. Mitton, "Diameter
Network Access Server Application",
draft-ietf-aaa-diameter-nasreq-17 (work in progress), July
2004.
[I-D.ietf-aaa-diameter-sip-app]
Garcia-Martin, M., Belinchon, M., Pallares-Lopez, M.,
Canales-Valenzuela, C. and K. Tammi, "Diameter Session
Initiation Protocol (SIP) Application",
draft-ietf-aaa-diameter-sip-app-03 (work in progress),
July 2004.
[I-D.ietf-mip6-auth-protocol]
"Authentication Protocol for Mobile IPv6",
draft-ietf-mip6-auth-protocol-00 (work in progress), July
2004.
[I-D.ietf-mip6-bootstrap-ps]
Patel, A., "Problem Statement for bootstrapping Mobile
IPv6", draft-ietf-mip6-bootstrap-ps-00 (work in progress),
July 2004.
Yegin Expires January 30, 2005 [Page 13]
Internet-Draft MIP6 AAA August 2004
[I-D.ietf-mip6-mipv6-mib]
Keeni, G., Nagami, K., Koide, K. and S. Gundavelli, "A
Management Information Base for Mobile IPv6",
draft-ietf-mip6-mipv6-mib-03 (work in progress), July
2004.
[I-D.jang-dhc-haopt]
Yegin, A., "DHCP Option for Home Agent Discovery in
MIPv6", draft-jang-dhc-haopt-00 (work in progress), June
2004.
[I-D.le-aaa-mipv6-requirements]
Faccin, S., "Mobile IPv6 Authentication, Authorization,
and Accounting Requirements",
draft-le-aaa-mipv6-requirements-03 (work in progress),
February 2004.
[I-D.ohnishi-mip6-aaa-problem-statement]
Ohnishi, H., "Mobile IPv6 AAA Problem Statement",
draft-ohnishi-mip6-aaa-problem-statement-00 (work in
progress), February 2004.
[RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)", RFC
2865, June 2000.
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J.
Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H.
Levkowetz, "Extensible Authentication Protocol (EAP)", RFC
3748, June 2004.
[RFC3775] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
[RFC3776] Arkko, J., Devarapalli, V. and F. Dupont, "Using IPsec to
Protect Mobile IPv6 Signaling Between Mobile Nodes and
Home Agents", RFC 3776, June 2004.
Yegin Expires January 30, 2005 [Page 14]
Internet-Draft MIP6 AAA August 2004
Author's Address
Alper E. Yegin
Samsung Advanced Institute of Technology
75 West Plumeria Drive
San Jose, CA 95134
USA
Phone: +1 408 544 5656
EMail: alper.yegin@samsung.com
Yegin Expires January 30, 2005 [Page 15]
Internet-Draft MIP6 AAA August 2004
Intellectual Property Statement
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.
Disclaimer of Validity
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.
Copyright Statement
Copyright (C) The Internet Society (2004). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Yegin Expires January 30, 2005 [Page 16]