[Search] [pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00 01                                                         
©À
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]