Mobile IPv4 RADIUS Requirements
draft-ietf-mip4-radius-requirements-04

Network Working Group                                   M. Nakhjiri, Ed.
Internet-Draft                                                Huawei USA
Intended status: Informational                              K. Chowdhury
Expires: January 21, 2008                               Starent Networks
                                                                 A. Lior
                                                     Bridgewater Systems
                                                                K. Leung
                                                           Cisco Systems
                                                           July 20, 2007

                    Mobile IPv4 RADIUS requirements
               draft-ietf-mip4-radius-requirements-04.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   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 21, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Abstract

   This document provides an applicability statement as well as a scope
   definition for specifying RADIUS extensions to support Mobile IPv4.
   The goal is to allow specification of RADIUS attributes to assist the

Nakhjiri, et al.        Expires January 21, 2008                [Page 1]
Internet-Draft       Mobile IP4 RADIUS Requirements            July 2007

   Mobile IPv4 signaling procedures.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Goals and Non-Goals  . . . . . . . . . . . . . . . . . . . . .  4
     3.1.  Goals  . . . . . . . . . . . . . . . . . . . . . . . . . .  5
     3.2.  Non-Goals  . . . . . . . . . . . . . . . . . . . . . . . .  5
   4.  Attributes . . . . . . . . . . . . . . . . . . . . . . . . . .  6
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  6
   6.  Security considerations  . . . . . . . . . . . . . . . . . . .  6
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  7
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  7
     8.1.  Normative References . . . . . . . . . . . . . . . . . . .  7
     8.2.  Informative References . . . . . . . . . . . . . . . . . .  8
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . .  8
   Intellectual Property and Copyright Statements . . . . . . . . . . 10

Nakhjiri, et al.        Expires January 21, 2008                [Page 2]
Internet-Draft       Mobile IP4 RADIUS Requirements            July 2007

1.  Introduction

   To kick start the Mobile IPv4 [RFC3344] processing of its packets by
   Mobile IP agents, a mobile node (MN) needs to be able to acquire a
   pair of home and care of addresses (HoA and CoA, respectively), find
   a willing agent to act as a Home Agent, HA, for the MN and perform a
   registration process with the HA.  The registration process consists
   of an exchange of a registration request and reply message between
   the MN and the HA.  The specification in [RFC3344] allows an MN to
   start the registration process prior to having acquired its home
   address or the address of its HA.  Acquiring those parameters by the
   MN is typically part of a process referred to as bootstrapping.

   Successful processing of registration requests, and replies among
   other things depends on successful creation and verification of a
   number of authentication extensions developed specifically to protect
   the integrity and security of the registration requests and replies
   and the entities processing them, i.e.  MN, HA and some times,
   foreign agents, FA [RFC3344].  Creation as well as verification of
   these extensions requires existence of trust relationships and shared
   keys between MN and each of the mobility agents.  However, creation
   of these trust relationships, typically referred to as mobility
   security associations, MSA, is considered outside scope of the base
   Mobile IPv4 specification defined in [RFC3344].  It is desired to
   avoid the scalability issues arising from creating static security
   associations between an MN and all possible mobility agents.  Thus it
   is preferred to establish the associations dynamically using the pre-
   existing relationship between the MN and the AAA server.

   To allow for utilization of an existing AAA infrastructure in the
   bootstrapping of the Mobile IPv4 parameters and security
   relationships, the Mobile IPv4 working group has developed extensions
   to allow the MN to authenticate to the home AAA server [RFC4721] and
   to request assistance from the AAA server in creation of security
   associations [RFC3957] with the mobility agents, all based on the
   pre-established trust relationship between the MN and its home AAA
   server.

   However, utilization of the AAA infrastructure for Mobile IPv4
   purposes, involves both Mobile IP and AAA signaling, where the
   interaction between the MN and the mobility agents (HA and FA) is
   based on Mobile IP signaling, while the signaling beyond the mobility
   agents to the AAA server is based on AAA protocols.  Around the same
   time, when the specification was being developed, the AAA community
   was in the process of designing Diameter as a successor to RADIUS.
   Thus, the Mobile IP group developed a set of guidelines and
   requirements specifically from Mobile IP standpoint [RFC2977] for
   such a successor.  These requirements, led to development of an

Nakhjiri, et al.        Expires January 21, 2008                [Page 3]
Internet-Draft       Mobile IP4 RADIUS Requirements            July 2007

   specification for use of Diameter in Mobile IPv4 bootstrapping
   [RFC4004], while the requirement document is essentially standardized
   [RFC2977] after standardization of RADIUS [RFC2865]

   Thus it is obvious that RADIUS does not and cannot meet all the
   requirements listed In [RFC2977] without undergoing an extensive
   design change and thus no RADIUS attributes have been standardized
   for Mobile IP support thus far.  However, in the absence of IETF
   standardized RADIUS attributes for support of MIPv4, different
   wireless SDOs have taken the path of developing VSAs for dynamic
   bootstrapping of Mobile IPv4 registration procedure.  The use of
   different VSAs and different RADIUS procedures for the same purpose
   of Mobile IPv4 bootstrapping at different SDOs will cause a lack
   interoperability between these wireless standards, potentially
   hindering mobility across these wireless networks.

   To respond to the described issue, it is desired to standardize a set
   of RADIUS attributes within IETF to allow a consistent and
   interoperable interaction with RADIUS based AAA infrastructure during
   the Mobile IPv4 Registration procedure.  The bootstrapping attributes
   can include configuration parameters as well as material used for
   provisioning security of Mobile IPv4 messaging (authentication) as
   defined by [RFC4721] and [RFC3957].

   Given that RADIUS as it stands today cannot meet all the requirements
   in [RFC2977], the purpose of this requirement is to define a set of
   goals and nongoals specifically defined for RADIUS when it comes to
   assisting mobile nodes and mobility agents in bootstrapping Mobile
   IPv4 operation.

2.  Terminology

   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 [RFC2119].

3.  Goals and Non-Goals

   Since this document serves as requirement specification for RADIUS
   extensions supporting Mobile IPv4 interaction with RADIUS
   infrastructure, the goals and non-goals refer to only those RADIUS
   extensions that are required for support of Mobile IPv4.

Nakhjiri, et al.        Expires January 21, 2008                [Page 4]
Internet-Draft       Mobile IP4 RADIUS Requirements            July 2007

3.1.  Goals

   The scope of the work is to standardize RADIUS attributes and to
   define the procedure by which the Mobile IPv4 agents, e.g.  Home
   agent (HA) and Foreign Agent (FA) map the Mobile IP registration
   message fields into the proposed RADIUS attributes and vice versa.
   o  It is required of the RADIUS servers to be able to understand and
      process the attributes to be defined for Mobile IPv4 support and
      to perform verification of authentication extensions specified in
      [RFC4721].  RADIUS proxies are expected to be able to forward
      messages including the Mobile IPv4 related attributes as they
      would with any other RADIUS messages and attributes.
   o  All RADIUS work MUST be backward compatible with existing RADIUS
      RFCs, including RFCs as follows: [RFC2865], [RFC2866], [RFC2867],
      [RFC2868], [RFC2869], [RFC3576], [RFC3579], and [RFC3580].
   o  It is also required of the Mobile IP agents (FA and HA) to operate
      as RADIUS clients (NASes in context of [RFC2865]) when translating
      RADIUS signaling into Mobile IP signaling and vice versa.  Details
      on the behavior of Mobile IP agents as RADIUS clients are to be
      provided by the solution draft describing the RADIUS extensions
      for Mobile IP support.

3.2.  Non-Goals

   The scope of this work is to only standardize RADIUS attributes and
   to define the procedure by which the Mobile IPv4 agents, e.g.  Home
   agent (HA) and Foreign Agent (FA) map the Mobile IP registration
   message fields into the proposed RADIUS attributes and vice versa.
   It is not the intention to extend the functionality of existing
   RADIUS servers or protocol.  More specifically, the following are
   NON-GOALS:
   o  Enhancing RADIUS Security: Creating new security properties for
      RADIUS, such as creating key transport capabilities is not the
      goal.  No new security mechanisms are to be defined for the
      transport of RADIUS Access Requests in relation to support of
      Mobile IPv4 bootstrapping.  Existing RADIUS authentication
      procedures, e.g.  Message-Authenticator (80) described in
      [RFC2869], are used.  The security considerations for use of
      RADIUS in bootstrapping Mobile IPv4 are described in a later
      section of this document.
   o  Enhancing RADIUS transport reliability: Transport properties of
      RADIUS remain intact.  No new reliability mechanisms are defined
      in the transport of such Access Requests.
   o  Extending RADIUS message set: RADIUS extensions for bootstrapping
      Mobile IPv4 are not to define new RADIUS messages.  Diameter
      Mobile IP application [RFC4004] has defined new command codes for
      support of Mobile IP signaling, depending on whether Diameter
      server is dealing with a Mobile IP HA or an FA.  RADIUS currently

Nakhjiri, et al.        Expires January 21, 2008                [Page 5]
Internet-Draft       Mobile IP4 RADIUS Requirements            July 2007

      does not have any messages that correspond to these Diameter
      commands.  Instead, RADIUS extensions for Mobile IPv4
      bootstrapping need to provide proposals for new RADIUS attributes
      that facilitates Diameter-RADIUS messaging translation without
      defining any new RADIUS messaging.  At the same time, the RADIUS
      extensions for Mobile IPv4 need to re-use Diameter AVPs to the
      fullest extent possible.
   o  RFC2977 compatibility: Extending RADIUS in a way that fulfills the
      full list of requirements in [RFC2977] will not be attempted.

4.  Attributes

   A specification of the RADIUS extensions for Mobile IPv4 needs to
   describe the full set of attributes required for RADIUS-Mobile IP
   interaction.  While some of the attributes may already be
   standardized, others will require standardization and IANA type
   assignments.

5.  IANA Considerations

   This requirement document does not allocate any numbers, so there are
   no IANA considerations.  On the other hand, solution documentations
   for RADIUS support of Mobile IPv4 will likely introduce new RADIUS
   attributes.  Thus those documents will need new attribute type
   numbers assigned by IANA.

6.  Security considerations

   Enhancing security properties of RADIUS are a specific non-goal for
   the RADIUS extensions providing support for Mobile IP.  Also, as this
   is a requirement document and not a solution specification document,
   no new security considerations aside from those that already exist
   for RADIUS are noted.  As such, the existing RADIUS security
   considerations described previously apply, and no additional security
   considerations are added here.  For instance, the assumption in
   RADIUS is that intermediary nodes are trusted, while at the same time
   there is a concern on using AAA protocols that use hop by hop
   security to distribute keys.  Use of hop by hop security for key
   distribution can be in conflict with some of the requirements stated
   in [housley-aaa-key-mgmt], such as the requirement on binding a key
   to its context and the requirement on limitation of the key scope.
   The former for instance states that a key Must be bound to the
   parties that are expected to have access to the keying material,
   while the latter implies that parties that do not require access to a
   key to perform their role MUST not have access to the key.  Both of

Nakhjiri, et al.        Expires January 21, 2008                [Page 6]
Internet-Draft       Mobile IP4 RADIUS Requirements            July 2007

   these requirements rule against trusting intermediary nodes and
   proxies with distribution of keys.  Due to lack of end to end
   security mechanisms for RADIUS, imposing a MUST requirement for not
   trusting proxies is not possible.  RADIUS extension working group is
   in the process of specifying procedures for wrapping key materials
   within RADIUS attributes.  For the time being, support of Mobile IP
   within RADIUS may need to be based on trust of intermediaries,
   despite the security considerations described.

   When it comes to protecting attributes in Access Request, [RFC2868]
   section 3.5 provides a mechanism for encrypting RADIUS attributes,
   such as passwords.  There is also work under progress for specifying
   wrapping of sensitive attributes, such as key material within RADIUS
   Access Accept messages.  This work is currently considered as part of
   RADIUS crypto-agility extensions and when completed can be used in
   the process of distributing sensitive attributes, such as keying
   material from RADIUS servers.

   It is also possible to protect RADIUS transactions using IPsec (e.g.
   as in RFC3579).

7.  Acknowledgements

   The authors would like to thank Alan DeKok for review and feedback,
   Pete McCann and Jari Arkko for diligent shepherding of this document.

8.  References

8.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", March 1997.

   [RFC2865]  Rigney, C., "Remote Authentication Dial In User Service",
              June  2000.

   [RFC2866]  Rigney, C., "RADIUS Accounting", June  2000.

   [RFC2867]  Zorn, G., "Remote Accounting Modification for Tunnel
              Protocol Support", June  2000.

   [RFC2977]  Glass, S. and Perkins, "Mobile IP Authentication,
              Authorization, and Accounting Requirements", October 2000.

   [RFC3344]  Perkins, C., "IP Mobility Support", August 2002.

Nakhjiri, et al.        Expires January 21, 2008                [Page 7]
Internet-Draft       Mobile IP4 RADIUS Requirements            July 2007

   [RFC3957]  Perkins, C. and P. Calhoun, "AAA Registration Keys for
              Mobile IP", March 2005.

   [RFC4004]  Calhoun, P. and C. Perkins, "Diameter Mobile IP
              application", May  2004.

   [RFC4721]  Perkins, C. and P. Calhoun, "Mobile IP Challenge/Response
              Extensions (Revised)", January 2007.

   [housley-aaa-key-mgmt]
              Housley, R., "Guidance for AAA key management",
              draft-housley-aaa-key-mgmt-09 (work in progress).

8.2.  Informative References

   [RFC2868]  Zorn, G., "RADIUS Attributes for Tunnel Protocol Support",
              June  2000.

   [RFC2869]  Rigney, C., "RADIUS Extensions", June  2000.

   [RFC3576]  Chiba, M., "Dynamic Authorization Extensions to Remote
              Authentication Dial In User Service (RADIUS)", July 2003.

   [RFC3579]  Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication
              Dial In User Service) Support For Extensible
              Authentication Protocol (EAP)", September 2003.

   [RFC3580]  Cogdon, P., "IEEE 802.1X Remote Authentication Dial In
              User Service (RADIUS) Usage Guidelines", September 2003.

Authors' Addresses

   Madjid Nakhjiri (editor)
   Huawei USA

   Email: mnakhjiri@huawei.com

   Kuntal Chowdhury
   Starent Networks

   Email: kchowdhury@starentnetworks.com

Nakhjiri, et al.        Expires January 21, 2008                [Page 8]
Internet-Draft       Mobile IP4 RADIUS Requirements            July 2007

   Avi Lior
   Bridgewater Systems

   Email: avi@bridgewatersystems.com

   Kent Leung
   Cisco Systems
   170 West Tasman Drive
   San Jose, CA  95134
   US

   Email: kleung@cisco.com

Nakhjiri, et al.        Expires January 21, 2008                [Page 9]
Internet-Draft       Mobile IP4 RADIUS Requirements            July 2007

Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   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, THE IETF TRUST 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.

Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).

Nakhjiri, et al.        Expires January 21, 2008               [Page 10]