wdiff draft-ietf-mip6-aaa-ha-goals-02.txt draft-ietf-mip6-aaa-ha-goals-03.txt

Mobile IPv6 WG G. Giaretta
Internet-Draft I. Guardini
Expires: December 28, 2006
Intended status: Standards Track E. Demaria
Expires: March 16, 2007 Telecom Italia
J. Bournelle
GET/INT
R. Lopez
Univ. of Murcia
June 26,
September 12, 2006

AAA Goals for AAA-HA interface
draft-ietf-mip6-aaa-ha-goals-02 Mobile IPv6
draft-ietf-mip6-aaa-ha-goals-03

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 December 28, 2006. March 16, 2007.

Abstract

In commercial deployments Mobile IPv6 can be a service offered by a
Mobility Services Provider (MSP). In this case all protocol
operations may need to be explicitly authorized and traced, requiring
the interaction between Mobile IPv6 and the AAA infrastructure.
Integrating the AAA infrastructure offers also a solution component
for Mobile IPv6 bootstrapping in integrated and split scenarios.

This document describes various scenarios where a AAA interface for
Mobile IPv6 is actually required. Additionally, it lists design
goals and requirements for such an interface.

Table of Contents

1. Terminology Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Bootstrapping scenarios Scenarios . . . . . . . . . . . . . . . . . . . 4
4.1. Split Scenario . . . . . . . . . . . . . . . . . . . . . . 4
4.2. Integrated Scenario . . . . . . . . . . . . . . . . . . . 5
5. Goals for the split scenario Split Scenario . . . . . . . . . . . . . . . . . 6
5.1. General goals . . . . . . . . . . . . . . . . . . . . . . 6
5.2. Service Authorization . . . . . . . . . . . . . . . . . . 7
5.3. Accounting . . . . . . . . . . . . . . . . . . . . . . . . 7
5.4. Mobile Node Authentication . . . . . . . . . . . . . . . . 8
5.5. Provisioning of configuration parameters Configuration Parameters . . . . . . . . . 8
6. Goals for the Integrated scenario Scenario . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 9
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
10.1. Normative References . . . . . . . . . . . . . . . . . . . 9
10.2. Informative References . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 10
Intellectual Property and Copyright Statements . . . . . . . . . . 12

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

2. Introduction

Mobile IPv6 [2] [1] was originally designed as a protocol without any
integration with the AAA infrastructure of the Mobility Service
Provider (MSP) that offers mobility service. infrastructure. Nonetheless, in some
environments it might be desirable to authenticate the user based on
existing credentials stored in at the AAA infrastructure, server to authorize protocol operations and
operations, to enable accounting. accounting and credit control. Due to this
requirement, Mobile IPv6 might require the interaction with the AAA
infrastructure. Integrating the AAA infrastructure offers also a
solution component for Mobile IPv6 bootstrapping [3] [2] in split [4] [3] and
integrated [5] [4] scenarios.

This document describes various scenarios where a AAA interface is
required. Additionally, it lists design goals and requirements for
such an interface.

This document only describes requirements, goals and scenarios. It
does not provide solutions.

Notice that this document builds on the security model of the AAA
infrastructure. As such, the end host host/user shares credentials with
the home AAA server and the communication between the AAA server and
the AAA client may be protected. If the AAA server and the AAA
client are not part of the same administrative domain, then some sort
of contractual relationship between the involved administrative
domains is typically in place in form of roaming agreements.

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

Some of the terms are also extracted from [2].

3. Motivation

Mobile IPv6 specification [2] [1] requires that Mobile Nodes (MNs) are
provisioned with a set of configuration parameters, namely the Home
Address and the Home Agent Address, in order to accomplish a home
registration. Moreover Moreover, MNs and Home Agents (HAs) must share the
cryptographic material needed in order to setup IPsec security
associations to protect Mobile IPv6 signaling (e.g. shared keys or certificates to setup IPsec security associations).
certificates).

One approach is to statically provision the necessary configuration
parameters at MNs and HAs. This solution is sub-optimal from a
deployment perspective, especially in large networks with a lot of
users (e.g., a mobile operator network). For this reason the Mobile
IPv6 bootstrapping problem was investigated [3]. and is described in [2].
Based on the analysed scenarios (i.e. integrated and split), scenarios, two solutions were developed. The
solution for the split scenario is described in [4] [3] and the one for
the integrated scenario can be found at [5]. [4]. A key point behind
these mechanisms scenarios is that, whenever static provisioning is not
feasible, the AAA infrastructure of the MSP can be used as the
central element to enable dynamic Mobile IPv6 bootstrapping. In this
case the AAA infrastructure can be exploited to offload the end
host's authentication to the AAA server as well as to deliver the
necessary configuration parameters to the HA.

Moreover, in case Mobile IPv6 is a service offered by a Mobility
Service Provider (MSP), all protocol operations (e.g. (e.g., home
registrations) may need to be explicitly authorized and monitored
(e.g.
(e.g., for accounting purposes). This can be accomplished relying on
the AAA infrastructure of the MSP, MSP that stores users' service user profiles and
credentials.

The

In the split scenario, the deployment of this service model requires
the availability of an interface between the AAA infrastructure Home Agent and the HA, that can be seen
as the Network Access Server (NAS) for Mobile IPv6. AAA
infrastructure. The core capabilities that should be supported by
this interface include Mobile IPv6 service authorization and
maintenance (e.g. asynchronous service termination) as well as the
exchange of accounting data. This basic set of features is needed in
any Mobile IPv6 bootstrapping scenario.

There is therefore space for the definition of a general AAA-HA
communication interface capable to support In the basic features
described above (e.g. authorization and accounting) as well as integrated scenario,
the
extended capabilities (e.g. transfer of configuration data) needed to
enable various dynamic AAA server also delivers some Mobile IPv6 bootstrapping scenarios. parameters to the NAS.

4. Bootstrapping scenarios Scenarios

This section describes some bootstrapping scenarios in which a
communication between the AAA infrastructure of the Mobility Service
Provider and the Home Agent is needed.

4.1. Split Scenario

In the split scenario [4], [3], there is the assumption that the mobility
service and network access service are separate. not provided by the same
administrative entity. This implies that the mobility service can be
authorized by a different entity deploying its own AAA
infrastructure. The entity offering the mobility service is called
Mobility Service Provider (MSP) while the entity authorizing the
service is the Mobility Service Authorizer (MSA).

In this scenario, the Mobile Node discovers the Home Agent Address
using the Domain Name Service (DNS). It queries the address based on
the Home Agent name or by service name. In the former case, the
Mobile Node is configured with the Fully Qualified Domain Name (FDQN)
of the Home Agent. In the latter case, the document [4] [3] defines a new service
resource record (SRV RR).

Then the Mobile Node performs an IKEv2 [6] exchange with the HA to
setup IPsec SAs (to protect Mobile IPv6 signaling) and to configure
its Home Address (HoA). The IKEv2 Mobile Node to Home Agent
authentication can be done using either public key signatures or the
Extensible Authentication Protocol (EAP).

If EAP is used for authentication, the operator can choose any
available EAP authentication methods. Note that even if EAP is used, the MN
authenticates the HA using public key signature based authentication. The Based on
IKEv2, the HA may rely on a remote EAP server. In this case, a AAA
protocol such as RADIUS EAP [7] or Diameter [7]/Diameter EAP [8] must be used between
the HA and the home EAP server. This allows a pool of HAs to rely on
the same EAP server to authenticate Mobile Nodes. It also allows the
roaming mobility case in which the Mobile Node obtains the mobility
service in a different administrative domain (MSP != MSA).

The Mobile Node may also want to update its FQDN in the DNS with the
newly allocated Home Address. The document [4] [3] recommends that the HA performs the
DNS entry update on behalf of the Mobile Node. For that purpose, the
Mobile Node indicates its FDQN in the IKEv2 exchange (IDii field in
IKE_AUTH) and adds a DNS Update Option in the Binding Update message
sent to the HA.

When the Mobile Node uses a Home Agent belonging to a different
administrative domain (MSP != MSA), the local HA may not share a
security association with the home DNS server. In this case, the
document [4] [3]
suggests that the home AAA server to be is responsible of for the update. Thus
Thus, the HA should send to the home AAA server the FDQN-HoA
pair through the AAA protocol. (FDQN, HoA) pair.
Note that the AAA exchange between the HA and the AAA infrastructure server is
normally terminated before the HA receives the Binding Update
message. The reason is that the authentication has succeeded if the
Mobile Node is able to send the BU.

4.2. Integrated Scenario

In the integrated scenario [5], [4], the assumption is which that the mobile
user's mobility service user is
authenticated and authorized by the same authorizer than network
access service. Basically The Mobility Service Authorizer (MSA) and the Access
Service Authorizer (ASA) are the same entity. The
scenario considers two cases:

1. Mobile Node requests a home agent to its home domain (ASA/MSA).

2. Mobile Node requests a home agent to the Access Service Provider
(ASP)

Two scenarios are possible. In the first case, the Home Agent is
allocated by the user's home domain. In the second case it is
allocated by user's an entity in the visited domain. In both cases, it is
assumed that the AAA server in the home domain (AAAH) authorizes both
network access service and mobility service.

In this scenario, Mobile Node discovers the Home Agent Address using
DHCPv6. During network access service authentication and
authorization, AAAH also verifies if authenticating user is
authorized to use mobility service. In affirmative case, the AAAH
sends the information about the assigned home agent to the Network
Access Server (NAS) where the Mobile Node is attached,
the information about currently attached.
Then, the assigned home agent. Then NAS stores that the received information. To request home agent
data, the Mobile Node sends a DHCPv6 Information Request to the
All_DHCP_Relay_Agents_and_Servers multicast address. With this
request, the Mobile Node can specify if it wants a home agent
provided by the visited domain (ASP) (ASP/MSP) or by the home domain (ASA). (ASA/
MSA). In both cases, the NAS acts a DHCPv6 relay. When the NAS
receives the DHCPv6 Information Request then it attaches sends home agent
information received from AAAH in a new DHC Relay Agent Option as
defined in [9].

In case the Mobile Node cannot acquire home agent information via
DHCPv6, it can try the default mechanism based on DNS described in [4].
[3]. After the Mobile Node has acquired the home agent information,
the mechanism used to bootstrap the HoA, IPsec Security Association,
and Authentication and Authorization with the MSA is the same
described in the bootstrapping solution for split scenario [4]. [3].

5. Goals for the split scenario

The motivations and scenarios illustrated for the split scenario
raise Split Scenario

Section 4 raises the need to define an interface extensions for the AAA protocol
used between the AAAH server and the HA. The following sections list
a set of goals for this interface. goals.

5.1. General goals

G1.1 The AAAH server and the HA MUST be able to authenticate each
other (mutual authentication) in order to prevent the installation
of unauthorized state on the HA. In some deployment scenarios, it
may not be feasible for HA and AAAH to mutually authenticate each
other. For example, let us consider the case where MSP is not the
MSA. In such a case, several AAA intermediate proxies could
forward MIP6 bootstrapping information back and forth between HA
and AAA. Thus, to prevent the installation of unauthorized state
on the HA, the path between HA and AAAH should be trustworthy>/

G1.2 The AAA-HA interface MUST provide integrity protection in order
to prevent any alteration of exchanged data (e.g. (e.g., Mobile IPv6
configuration parameters).

G1.3 The AAA-HA interface MUST provide replay protection.

G1.4 The AAA-HA interface SHOULD provide confidentiality since it
may be used to transfer keying material (e.g. (e.g., shared key
generated during EAP method authentication).

G1.5 The AAA-HA interface SHOULD support inactive peer detection.
This functionality can be used by the AAAH server to maintain a
list of active HAs (e.g. useful for HA selection). HAs.

5.2. Service Authorization

G2.1 The AAA-HA interface SHOULD allow the use of Network Access
Identifier (NAI) to identify the mobile node. user.

G2.2 The HA SHOULD be able to query the AAAH server to verify Mobile
IPv6 service authorization for the mobile node.

G2.3 The AAAH server MAY assign explicit operational limitations and
authorization restrictions on the HA (e.g. (e.g., packet filters, QoS
parameters).

G2.4 The AAAH server MUST be able to send an authorization lifetime
to the HA to limit Mobile IPv6 session duration for the MN.

G2.5 The HA MUST be able to request to the AAAH server an extension
of the authorization lifetime granted to the MN.

G2.6 The AAAH server MUST be able to force the HA to terminate an
active Mobile IPv6 session for authorization policy reasons (e.g. (e.g.,
credit exhaustion).

5.3. Accounting

G3.1 The AAA-HA interface MUST support the transfer of accounting
records needed for service control and charging. These include
(but may not be limited to): time of binding cache entry creation
and deletion, octets sent and received by the mobile node in Bi- bi-
directional Tunneling, tunneling, etc.

5.4. Mobile Node Authentication

G4.1 The AAA-HA interface MUST support pass-through EAP
authentication with the HA working as EAP authenticator operating
in pass-through mode and the AAAH server working as back-end
authentication server.

5.5. Provisioning of configuration parameters Configuration Parameters

G5.1 The HA SHOULD be able to communicate to the AAAH server the
Home Address allocated to the MN (e.g. (e.g., for allowing the AAAH
server to perform a DNS update on behalf of the MN).

G5.2 The AAAH SHOULD be able to indicate to the HA if the MN is
authorized to autoconfigure its Home Address.

6. Goals for the Integrated scenario Scenario

In the integrated scenario, the AAA server provides the HA
information to the NAS as part of the whole AAA operations for
network access. Next goals are considered in addition to those
described in section Section 5.

G6.1 The AAAH server MUST be able to communicate the Home-Agent Home Agent
Information (Address (IP Address or FQDN) to the NAS.

G6.2 The NAS SHOULD be able to notify to the AAA infrastructure that it supports the
functionalities described in [5]. [4].

G6.3 The ASP/MSP SHOULD be able to indicate to the MSA if it can
allocate a Home Agent to the MN.

G6.4 The AAA server of the MSA MUST be able to indicate to the NAS
whether the MN is authorized to use a local Home Agent (i.e. a
Home Agent in the ASP/MSP)

7. IANA Considerations

No new message formats or services are defined in this document.

This document does not require actions by IANA.

8. Security Considerations

As stated in section Section 5.1 the AAA-HA interface must provide mutual
authentication, integrity and replay protection. Furthermore, if
security parameters (e.g. (e.g., IKE pre-shared key) are transferred
through this interface, confidentiality is a feature that is strongly recommended to be
supported. However note that some suitable
interfaces may AAA protocols does not provide end-to-end confidentiality support this
unless it exists a direct connection between AAA and
HA (e.g. AAA protocols). corresponding entities.

9. Acknowledgements

The authors would like to thank James Kempf, Alper Yegin, Vijay
Devarapalli, Basavaraj Patil, Gopal Dommety and Madjid Nakhjiri for
their comments and feedback. Moreover the authors would like to
thank Hannes Tschofenig for his deep technical and editorial review
of the draft. Finally
the authors would like to thank also the European Commission support
in the co-funding of the ENABLE project, where this work is partly
being developed.

10. References

10.1. Normative References

[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.

[2] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.

10.2. Informative References

[3]

[2] Giaretta, G. and A. Patel, "Problem Statement for bootstrapping
Mobile IPv6", draft-ietf-mip6-bootstrap-ps-05 (work in
progress), May 2006.

[4]

[3] Giaretta, G., "Mobile IPv6 bootstrapping in split scenario",
draft-ietf-mip6-bootstrapping-split-02 (work in progress),
March 2006.

[5]

[4] Chowdhury, K. and A. Yegin, "MIP6-bootstrapping via DHCPv6 for
the Integrated Scenario",
draft-ietf-mip6-bootstrapping-integrated-dhc-01 (work in
progress), June 2006.

[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.

10.2. Informative References

[6] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005.

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

[8] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible
Authentication Protocol (EAP) Application", RFC 4072,
August 2005.

[9] Yegin, A., "DHCP Option for Home Agent Discovery in MIPv6",
draft-jang-dhc-haopt-02 (work in progress), March 2006.

[10] Chowdhury, K. and A. Lior, "RADIUS Attributes for Mobile IPv6
bootstrapping", draft-chowdhury-mip6-bootstrap-radius-01 (work
in progress), November 2004.

[11] Giaretta, G., "MIPv6 Authorization and Configuration based on
EAP", draft-giaretta-mip6-authorization-eap-03 (work in
progress), March 2006.

Authors' Addresses

Gerardo Giaretta
Telecom Italia Lab
via G. Reiss Romoli, 274
TORINO, 10148
Italy

Email: gerardo.giaretta@telecomitalia.it

Ivano Guardini
Telecom Italia Lab
via G. Reiss Romoli, 274
TORINO, 10148
Italy

Email: ivano.guardini@telecomitalia.it

Elena Demaria
Telecom Italia Lab
via G. Reiss Romoli, 274
TORINO, 10148
Italy

Email: elena.demaria@telecomitalia.it
Julien Bournelle
GET/INT
9 rue Charles Fourier
Evry 91011
France

Email: julien.bournelle@int-evry.fr

Rafa Marin Lopez
University of Murcia
30071 Murcia
Spain

Email: rafa@dif.um.es

Full Copyright Statement

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 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

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.

Acknowledgment

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