draft-ietf-mext-aaa-ha-goals-01.txt   rfc5637.txt 
MEXT Working Group G. Giaretta Network Working Group G. Giaretta
Internet-Draft Qualcomm Request for Comments: 5637 Qualcomm
Intended status: Informational I. Guardini Category: Informational I. Guardini
Expires: November 3, 2008 E. Demaria E. Demaria
Telecom Italia Telecom Italia
J. Bournelle J. Bournelle
Orange Labs Orange Labs
R. Lopez R. Lopez
Univ. of Murcia University of Murcia
May 2, 2008 September 2009
AAA Goals for Mobile IPv6 Authentication, Authorization, and Accounting (AAA) Goals
draft-ietf-mext-aaa-ha-goals-01 for Mobile IPv6
Status of this Memo Abstract
By submitting this Internet-Draft, each author represents that any In commercial and enterprise deployments, Mobile IPv6 can be a
applicable patent or other IPR claims of which he or she is aware service offered by a Mobility Services Provider (MSP). In this case,
have been or will be disclosed, and any of which he or she becomes all protocol operations may need to be explicitly authorized and
aware will be disclosed, in accordance with Section 6 of BCP 79. traced, requiring the interaction between Mobile IPv6 and the AAA
infrastructure. Integrating the Authentication, Authorization, and
Accounting (AAA) infrastructure (e.g., Network Access Server and AAA
server) also offers a solution component for Mobile IPv6
bootstrapping. This document describes various scenarios where a AAA
interface for Mobile IPv6 is required. Additionally, it lists design
goals and requirements for such an interface.
Internet-Drafts are working documents of the Internet Engineering Status of This Memo
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 This memo provides information for the Internet community. It does
and may be updated, replaced, or obsoleted by other documents at any not specify an Internet standard of any kind. Distribution of this
time. It is inappropriate to use Internet-Drafts as reference memo is unlimited.
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at Copyright Notice
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at Copyright (c) 2009 IETF Trust and the persons identified as the
http://www.ietf.org/shadow.html. document authors. All rights reserved.
This Internet-Draft will expire on November 3, 2008. This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.
Abstract RFC 5637 AAA Goals for Mobile IPv6 September 2009
In commercial and enterprise deployments Mobile IPv6 can be a service This document may contain material from IETF Documents or IETF
offered by a Mobility Services Provider (MSP). In this case all Contributions published or made publicly available before November
protocol operations may need to be explicitly authorized and traced, 10, 2008. The person(s) controlling the copyright in some of this
requiring the interaction between Mobile IPv6 and the AAA material may not have granted the IETF Trust the right to allow
infrastructure. Integrating the AAA infrastructure (e.g. NAS and modifications of such material outside the IETF Standards Process.
AAA server) offers also a solution component for Mobile IPv6 Without obtaining an adequate license from the person(s) controlling
bootstrapping. This document describes various scenarios where a AAA the copyright in such materials, this document may not be modified
interface for Mobile IPv6 is required. Additionally, it lists design outside the IETF Standards Process, and derivative works of it may
goals and requirements for such an interface. not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction ....................................................3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology .....................................................3
3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Motivation ......................................................4
4. Bootstrapping Scenarios . . . . . . . . . . . . . . . . . . . 4 4. Bootstrapping Scenarios .........................................4
4.1. Split Scenario . . . . . . . . . . . . . . . . . . . . . . 4 4.1. Split Scenario .............................................5
4.2. Integrated Scenario . . . . . . . . . . . . . . . . . . . 5 4.2. Integrated Scenario ........................................6
5. Goals for AAA-HA interface . . . . . . . . . . . . . . . . . . 6 5. Goals for AAA-HA Interface ......................................6
5.1. General goals . . . . . . . . . . . . . . . . . . . . . . 6 5.1. General Goals ..............................................6
5.2. Service Authorization . . . . . . . . . . . . . . . . . . 6 5.2. Service Authorization ......................................7
5.3. Accounting . . . . . . . . . . . . . . . . . . . . . . . . 7 5.3. Accounting .................................................8
5.4. Mobile Node Authentication . . . . . . . . . . . . . . . . 8 5.4. Mobile Node Authentication .................................8
5.5. Provisioning of Configuration Parameters . . . . . . . . . 8 5.5. Provisioning of Configuration Parameters ...................8
6. Goals for the AAA-NAS interface . . . . . . . . . . . . . . . 8 6. Goals for the AAA-NAS Interface .................................9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 7. Security Considerations .........................................9
8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 8. Acknowledgements ................................................9
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 9. References .....................................................10
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 9.1. Normative References ......................................10
10.1. Normative References . . . . . . . . . . . . . . . . . . . 10 9.2. Informative References ....................................10
10.2. Informative References . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 RFC 5637 AAA Goals for Mobile IPv6 September 2009
Intellectual Property and Copyright Statements . . . . . . . . . . 12
1. Introduction 1. Introduction
Mobile IPv6 [1] provides the basic IP mobility functionality for Mobile IPv6 [1] provides the basic IP mobility functionality for
IPv6. When Mobile IPv6 is used in tightly managed environments with IPv6. When Mobile IPv6 is used in tightly managed environments with
the use of the AAA (Authentication, Authorization and Accounting) the use of the AAA (Authentication, Authorization, and Accounting)
infrastructure, an interface between Mobile IPv6 and AAA protocols infrastructure, an interface between Mobile IPv6 and AAA protocols
needs to be defined. Also, two scenarios for bootstrapping Mobile needs to be defined. Also, two scenarios for bootstrapping Mobile
IPv6 service [2] , i.e., split [3] and integrated [4] scenarios, IPv6 service [2], i.e., split [3] and integrated [6] scenarios,
require the specification of a message exchange between the HA and require the specification of a message exchange between the Home
AAA infrastructure for authentication and authorization purposes and Agent (HA) and AAA infrastructure for authentication and
a message exchange between the AAA server and the NAS in order to authorization purposes and a message exchange between the AAA server
provide the visited network with the necessary configuration and the NAS in order to provide the visited network with the
information (e.g. Home Agent address). necessary configuration information (e.g., Home Agent address).
This document describes various scenarios where a AAA interface is This document describes various scenarios where a AAA interface is
required. Additionally, it lists design goals and requirements for required. Additionally, it lists design goals and requirements for
the communication between the HA and the AAA server and the NAS and the communication between the HA and the AAA server and between the
the AAA server needed in the split and integrated scenarios. NAS and the AAA server needed in the split and integrated scenarios.
Requirements are listed in case either IPsec or rfc 4285 [5] is used Requirements are listed in case either IPsec or RFC 4285 [4] is used
for Mobile IPv6 authentication. for Mobile IPv6 authentication.
This document only describes requirements, goals and scenarios. It This document only describes requirements, goals, and scenarios. It
does not provide solutions. does not provide solutions.
Notice that this document builds on the security model of the AAA Notice that this document builds on the security model of the AAA
infrastructure. As such, the end host/user shares credentials with infrastructure. As such, the end host/user shares credentials with
the home AAA server and the communication between the AAA server and 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 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 client are not part of the same administrative domain, then some sort
of contractual relationship between the involved administrative of contractual relationship between the involved administrative
domains is typically in place in form of roaming agreements. domains is typically in place in the form of roaming agreements.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [6], with the document are to be interpreted as described in RFC 2119 [5], with the
qualification that unless otherwise stated these words apply to the qualification that, unless otherwise stated, these words apply to the
design of the AAA protocol extension, not its implementation or its design of the AAA protocol extension, not its implementation or its
usage. usage.
Some of the terms are also extracted from [2]. The following terms are extracted from [2].
o Access Service Authorizer (ASA). A network operator that o Access Service Authorizer (ASA). A network operator that
authenticates a mobile node and establishes the mobile node's authenticates a Mobile Node and establishes the Mobile Node's
authorization to receive Internet service. authorization to receive Internet service.
RFC 5637 AAA Goals for Mobile IPv6 September 2009
o Access Service Provider (ASP). A network operator that provides o Access Service Provider (ASP). A network operator that provides
direct IP packet forwarding to and from the end host. direct IP packet forwarding to and from the end host.
o Mobility Service Authorizer (MSA). A service provider that o Mobility Service Authorizer (MSA). A service provider that
authorizes Mobile IPv6 service. authorizes Mobile IPv6 service.
o Mobility Service Provider (MSP). A service provider that provides o Mobility Service Provider (MSP). A service provider that provides
Mobile IPv6 service. In order to obtain such service, the mobile Mobile IPv6 service. In order to obtain such service, the Mobile
node must be authenticated and prove authorization to obtain the Node must be authenticated and prove authorization to obtain the
service. service.
3. Motivation 3. Motivation
Mobile IPv6 specification [1] requires that Mobile Nodes (MNs) are Mobile IPv6 specification [1] requires that Mobile Nodes (MNs) are
provisioned with a set of configuration parameters, namely the Home provisioned with a set of configuration parameters -- namely, the
Address and the Home Agent Address, in order to accomplish a home Home Address and the Home Agent Address, in order to accomplish a
registration. Moreover, MNs and Home Agents (HAs) must share the home registration. Moreover, MNs and Home Agents (HAs) must share
cryptographic material needed in order to setup IPsec security the cryptographic material needed in order to set up IPsec security
associations to protect Mobile IPv6 signaling (e.g. shared keys or associations to protect Mobile IPv6 signaling (e.g., shared keys or
certificates). This is referred as the bootstrapping problem: as certificates). This is referred as the bootstrapping problem: as
described in [2], the AAA infrastructure can be used as the central described in [2], the AAA infrastructure can be used as the central
element to enable dynamic Mobile IPv6 bootstrapping. In this case element to enable dynamic Mobile IPv6 bootstrapping. In this case,
the AAA infrastructure can be exploited to offload the end host's the AAA infrastructure can be exploited to offload the end host's
authentication to the AAA server as well as to deliver the necessary authentication to the AAA server as well as to deliver the necessary
configuration parameters to the visited network (e.g. Home Agent configuration parameters to the visited network (e.g., Home Agent
address as specified in [4]). address as specified in [6]).
Moreover, in case Mobile IPv6 is a service offered by a Mobility Moreover, in case Mobile IPv6 is a service offered by a Mobility
Service Provider (MSP), all protocol operations (e.g., home Service Provider (MSP), all protocol operations (e.g., home
registrations) may need to be explicitly authorized and monitored registrations) may need to be explicitly authorized and monitored
(e.g., for accounting purposes). This can be accomplished relying on (e.g., for accounting purposes). This can be accomplished relying on
the AAA infrastructure of the MSA that stores user profiles and the AAA infrastructure of the Mobility Service Authorizer (MSA) that
credentials. stores user profiles and credentials.
4. Bootstrapping Scenarios 4. Bootstrapping Scenarios
This section describes some bootstrapping scenarios in which a This section describes some bootstrapping scenarios in which
communication between the AAA infrastructure of the Mobility Service communication between the AAA infrastructure of the Mobility Service
Provider and the Home Agent is needed. The need of a MIPv6-aware Provider and the Home Agent is needed. The need of MIPv6-aware
communication between the AAA server and the Network Access Server communication between the AAA server and the Network Access Server
(NAS) is also described. For more details, please refer to the (NAS) is also described. The purpose of this section is only to
bootstrapping documents [2], [3] and [4]. explain the situation where bootstrapping is required. The actual
mechanisms and additional details are specified elsewhere or are left
for future work (see, e.g., [2], [3], and [6]).
RFC 5637 AAA Goals for Mobile IPv6 September 2009
4.1. Split Scenario 4.1. Split Scenario
In the split scenario [3], there is the assumption that the mobility In the split scenario [3], there is the assumption that the mobility
service and network access service are not provided by the same service and network access service are not provided by the same
administrative entity. This implies that the mobility service is administrative entity. This implies that the mobility service is
authorized by the MSA that is a different entity from the ASA. authorized by the MSA that is a different entity from the ASA.
In this scenario, the Mobile Node discovers the Home Agent Address In this scenario, the Mobile Node discovers the Home Agent Address
using the Domain Name Service (DNS). It queries the address based on 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 the Home Agent name or by service name. In the former case, the
Mobile Node is configured with the Fully Qualified Domain Name (FDQN) Mobile Node is configured with the Fully Qualified Domain Name (FDQN)
of the Home Agent. In the latter case, [3] defines a new service of the Home Agent. In the latter case, [3] defines a new service
resource record (SRV RR). resource record (SRV RR).
Then the Mobile Node performs an IKEv2 [8] exchange with the HA to Then the Mobile Node performs an IKEv2 [7] exchange with the HA to
setup IPsec SAs (to protect Mobile IPv6 signaling) and to configure set up IPsec Security Associations (SAs) to protect Mobile IPv6
its Home Address (HoA). Mutual authentication for IKEv2 between signaling and to configure its Home Address (HoA). Mutual
Mobile Node and Home Agent can be done with or without use of authentication for IKEv2 between Mobile Node and Home Agent can be
Extensible Authentication Protocol (EAP). done with or without use of the Extensible Authentication Protocol
(EAP).
If EAP is used for authentication, the operator can choose any If EAP is used for authentication, the operator can choose any
available EAP methods. Use of EAP with the AAA infrastructure allows available EAP methods. Use of EAP with the AAA infrastructure allows
the HA for not necessarily maintaining authentication credentials for the HA to check the validity of each MN's credentials with the AAA
each Mobile Node by itself, checking the validity of the credentials infrastructure, rather than having to maintain credentials for each
with the AAA infrastructure. It also allows roaming in terms of MN itself. It also allows roaming in terms of Mobile IPv6 service
Mobile IPv6 service where MSP and MSA belong to different where the MSP and MSA belong to different administrative domains. In
administrative domains. In this case the HA in the MSP can check the this case, the HA in the MSP can check the validity of the
vailidity of the credentials provided by the MN with the AAA credentials provided by the MN with the AAA infrastructure of MSA,
infrastructure of MSA, receiving the relevant authorization receiving the relevant authorization information.
information.
The Mobile Node may also want to update its FQDN in the DNS with the The Mobile Node may also want to update its FQDN in the DNS with the
newly allocated Home Address. [3] recommends that the HA performs the newly allocated Home Address. [3] recommends that the HA performs the
DNS entry update on behalf of the Mobile Node. For that purpose, the DNS entry update on behalf of the Mobile Node. For that purpose, the
Mobile Node indicates its FDQN in the IKEv2 exchange (IDi field in Mobile Node indicates its FDQN in the IKEv2 exchange (in the IDi
IKE_AUTH) and adds a DNS Update Option in the Binding Update message field in IKE_AUTH) and adds a DNS Update Option in the Binding Update
sent to the HA. message sent to the HA.
When the Mobile Node uses a Home Agent belonging to a different When the Mobile Node uses a Home Agent belonging to a different
administrative domain (MSP != MSA), the local HA may not share a administrative domain (MSP != MSA), the local HA may not share a
security association with the home DNS server. In this case, [3] security association with the home DNS server. In this case, [3]
suggests that the home AAA server is responsible for the update. suggests that the home AAA server is responsible for the update.
Thus, the HA should send to the home AAA server the (FDQN, HoA) pair. Thus, the HA should send to the home AAA server the (FDQN, HoA) pair.
RFC 5637 AAA Goals for Mobile IPv6 September 2009
4.2. Integrated Scenario 4.2. Integrated Scenario
In the integrated scenario [4], the assumption is that the Access In the integrated scenario, the assumption is that the Access Service
Service Authorizer (ASA) is same as the Mobility Service Authorizer Authorizer (ASA) is the same as the Mobility Service Authorizer
(MSA). (MSA). Further details of this type of a scenario are being worked
on separately [6].
The Home Agent can the assigned either in the Access Service The Home Agent can be assigned either in the Access Service
Provider's network or in the separate network. In the former case, Provider's network or in the separate network. In the former case,
the MSP is the same entity as the ASP, whereas in the latter case MSP the MSP is the same entity as the ASP, whereas in the latter case the
and ASP are different entities. MSP and ASP are different entities.
In this scenario, Mobile Node discovers the Home Agent Address using In this scenario, the Mobile Node discovers the Home Agent Address
DHCPv6. If the user is authorized for Mobile IPv6 service, during using DHCPv6. If the user is authorized for Mobile IPv6 service,
the network access authentication the AAAH sends the information during the network access authentication the AAAH (the AAA server in
about the assigned Home Agent to the Network Access Server (NAS) the home network) sends the information about the assigned Home Agent
where the Mobile Node is currently attached. To request Home Agent to the NAS where the Mobile Node is currently attached. To request
data, the Mobile Node sends a DHCPv6 Information Request to the Home Agent data, the Mobile Node sends a DHCPv6 Information Request
All_DHCP_Relay_Agents_and_Servers multicast address. With this to the All_DHCP_Relay_Agents_and_Servers multicast address. With
request, the Mobile Node can specify if it wants a Home Agent this request, the Mobile Node can specify if it wants a Home Agent
provided by the visited domain (ASP/MSP) or by the home domain (ASA/ provided by the visited domain (ASP/MSP) or by the home domain
MSA). In both cases, the NAS acts a DHCPv6 relay. When the NAS (ASA/MSA). In both cases, the NAS acts a DHCPv6 relay. When the NAS
receives the DHCPv6 Information Request then it sends Home Agent receives the DHCPv6 Information Request, it passes Home Agent
information received from AAAH in a new DHC Relay Agent Option as information received from the AAAH server to the DHCP server, for
defined in [4]. instance using mechanisms defined in [6].
In case the Mobile Node cannot acquire Home Agent information via In case the Mobile Node cannot acquire Home Agent information via
DHCPv6, it can try the default mechanism based on DNS described in DHCPv6, it can try the default mechanism based on DNS described in
[3]. After the Mobile Node has acquired the Home Agent information, [3]. After the Mobile Node has acquired the Home Agent information,
the mechanism used to bootstrap the HoA, IPsec Security Association, the mechanisms used to bootstrap the HoA, the IPsec Security
and Authentication and Authorization with the MSA is the same Association, and the authentication and authorization with the MSA
described in the bootstrapping solution for split scenario [3]. are the same as described in the bootstrapping solution for the split
scenario [3].
5. Goals for AAA-HA interface 5. Goals for AAA-HA Interface
Section 4 raises the need to define extensions for the AAA protocol Section 4 raises the need to define extensions for the AAA protocol
used between the AAA server of the MSA and the HA. The following used between the AAA server of the MSA and the HA. The following
sections list the goals for such an interface. This communication is sections list the goals for such an interface. This communication is
needed for both split and integrated scenario. needed for both the split and integrated scenarios.
5.1. General goals 5.1. General Goals
G1.1 The communication between the AAAH server and the HA MUST reuse G1.1 The communication between the AAAH server and the HA MUST reuse
existing AAA security mechanisms with regard to authentication, existing AAA security mechanisms with regard to authentication,
replay, integrity, and confidentiality protection. These replay, integrity, and confidentiality protection. These
communication security mechanisms prevent a number of classical communication security mechanisms prevent a number of classical
threats, including the alteration of exchanged data (e.g., Mobile
IPv6 configuration parameters) and the installation of RFC 5637 AAA Goals for Mobile IPv6 September 2009
unauthorized state.
threats, including the alteration of exchanged data (e.g.,
Mobile IPv6 configuration parameters) and the installation of
unauthorized state.
5.2. Service Authorization 5.2. Service Authorization
G2.1 The AAA-HA interface MUST allow the use of Network Access
Identifier (NAI) to identify the user. G2.1 The AAA-HA interface MUST allow the use of a Network Access
Identifier (NAI) to identify the user.
G2.2 The HA MUST be able to query the AAAH server to verify Mobile G2.2 The HA MUST be able to query the AAAH server to verify Mobile
IPv6 service authorization for the mobile node. IPv6 service authorization for the Mobile Node.
G2.3 The AAAH server MAY assign explicit operational limitations and G2.3 The AAAH server MAY assign explicit operational limitations and
authorization restrictions on the HA (e.g., packet filters, QoS authorization restrictions on the HA (e.g., packet filters, QoS
parameters). parameters).
G2.4 The AAAH server MUST be able to send an authorization lifetime 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. 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 G2.5 The HA MUST be able to request that the AAAH server grant an
of the authorization lifetime granted to the MN. extension of the authorization lifetime to the MN.
G2.6 The AAAH server MUST be able to force the HA to terminate an 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., active Mobile IPv6 session for authorization policy reasons
credit exhaustion). (e.g., credit exhaustion).
G2.7 The HA MUST be able to indicate to the AAAH the IPv6 HoA that G2.7 The HA MUST be able to indicate to the AAAH server the IPv6 HoA
will be assigned to the MN. that will be assigned to the MN.
G2.8 The AAAH server MUST be able to authorize the MN to use an IPv6 G2.8 The AAAH server MUST be able to authorize the MN to use an IPv6
HoA and MUST indicate that to the HA. HoA and MUST indicate that to the HA.
G2.9 The AAAH server MUST be able to indicate to the HA whether G2.9 The AAAH server MUST be able to indicate to the HA whether or
return routability test (HoT, HoTi) shall be permitted or not via not the return routability test (HoT (Home Test) and HoTi (Home
the HA for a given MN. Test Init)) shall be permitted via the HA for a given MN.
G2.10 The AAAH server MUST be able to support different levels of G2.10 The AAAH server MUST be able to support different levels of
Mobile IPv6 authorization. For example, the AAAH server may Mobile IPv6 authorization. For example, the AAAH server may
authorize the MN to use of MIPv6 (as defined in [1]) or may authorize the MN to use MIPv6 (as defined in [1]) or may
authorize the MN to utilize an IPv4 HoA assigned for Dual Stack authorize the MN to utilize an IPv4 HoA assigned for Dual Stack
MIPv6 [9]. MIPv6 [8].
G2.11 The AAAH server MUST be able to indicate to the HA whether the G2.11 The AAAH server MUST be able to indicate to the HA whether the
bearer traffic for the MN needs to receive IPsec ESP protection. bearer traffic for the MN needs to receive IPsec Encapsulating
Security Payload (ESP) protection.
G2.12 The HA MUST be able to authenticate the MN through the AAAH in RFC 5637 AAA Goals for Mobile IPv6 September 2009
case a pre-share key is used in IKEv2 for user authentication.
The exact procedure is part of the solution space. G2.12 The HA MUST be able to authenticate the MN through the AAAH
server in case a pre-shared key is used in IKEv2 for user
authentication. The exact procedure is part of the solution
space.
5.3. Accounting 5.3. Accounting
G3.1 The AAA-HA interface MUST support the transfer of accounting G3.1 The AAA-HA interface MUST support the transfer of accounting
records needed for service control and charging. These include records needed for service control and charging. These include
(but may not be limited to): time of binding cache entry creation (but may not be limited to): time of binding cache entry
and deletion, octets sent and received by the mobile node in bi- creation and deletion, octets sent and received by the Mobile
directional tunneling, etc. Node in bi-directional tunneling, etc.
5.4. Mobile Node Authentication 5.4. Mobile Node Authentication
G4.1 The AAA-HA interface MUST allow the HA to act as a pass-through G4.1 The AAA-HA interface MUST allow the HA to act as a pass-through
EAP authenticator. EAP authenticator.
G4.2 The AAA - HA interface MUST support authentication based on the G4.2 The AAA-HA interface MUST support authentication based on the
Mobility Message Authentication Options defined in [5]. Mobility Message Authentication Options defined in [4].
G4.3 The AAAH MUST be able to provide a MN-HA key (or data used for G4.3 The AAAH server MUST be able to provide a MN-HA key (or data
subsequent key derivation of the MN-HA key by the HA) to the HA if used for subsequent key derivation of the MN-HA key by the HA)
requested. Additional data, such as the SPI or lifetime to the HA if requested. Additional data, such as the Security
parameters, are sent along with the keying material. Parameter Index (SPI) or lifetime parameters, are sent along
with the keying material.
G4.4 The HA SHOULD be able to request the AAAH server to G4.4 The HA supporting the Authentication Protocol MUST be able to
authenticate the MN with the value in the MN-AAA Mobility Message request that the AAAH server authenticate the MN with the value
Authentication Option. in the MN-AAA Mobility Message Authentication Option.
G4.5 The HA MUST include an identifier of the mobile node in the AAA G4.5 The HA MUST include an identifier of the Mobile Node in the AAA
transactions with the AAAH server. transactions with the AAAH server.
5.5. Provisioning of Configuration Parameters 5.5. Provisioning of Configuration Parameters
o The HA SHOULD be able to communicate to the AAAH server the Home o The HA SHOULD be able to communicate to the AAAH server the Home
Address allocated to the MN and the FQDN of the MN (e.g., for Address allocated to the MN and the FQDN of the MN (e.g., for
allowing the AAAH server to perform a DNS update on behalf of the allowing the AAAH server to perform a DNS update on behalf of the
MN). MN).
o The AAAH SHOULD be able to indicate to the HA if the MN is o The AAAH server SHOULD be able to indicate to the HA if the MN is
authorized to autoconfigure its Home Address. authorized to autoconfigure its Home Address. If the AAAH does
not indicate to the HA if a MN is authorized to autoconfigure its
address, the MN is not authorized.
6. Goals for the AAA-NAS interface RFC 5637 AAA Goals for Mobile IPv6 September 2009
6. Goals for the AAA-NAS Interface
In the integrated scenario, the AAA server provides the HA In the integrated scenario, the AAA server provides the HA
information to the NAS as part of the whole AAA operations for information to the NAS as part of the whole AAA operation for network
network access. access.
G6.1 The AAAH server MUST be able to communicate the Home Agent G6.1 The AAAH server MUST be able to communicate the Home Agent
Information (IP Address or FQDN) to the NAS. Information (IP address or FQDN) to the NAS.
G6.2 The NAS MUST be able to notify the AAAH if it supports the AAA G6.2 The NAS MUST be able to notify the AAAH server if it supports
extensions designed to receive the HA assignment information the AAA extensions designed to receive the HA assignment
described in [4]. information.
G6.3 The ASP/MSP SHOULD be able to indicate to the MSA if it can G6.3 The ASP/MSP supporting the allocation of a Home Agent MUST be
allocate a Home Agent to the MN. Therefore the NAS SHOULD be able able to indicate to the MSA if it can allocate a Home Agent to
to include suggested HA address in the ASP in the NAS - AAA the MN. Therefore, the NAS MUST be able to include a suggested
interaction. HA address in the ASP in the AAA-NAS interaction.
G6.4 The AAA server of the MSA MUST be able to indicate to the NAS 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 whether the MN is authorized to use a local Home Agent (i.e., a
Home Agent in the ASP/MSP). Home Agent in the ASP/MSP).
G6.5 The overall AAA solution for integrated scenario MUST support
the scenario where the AAA server of the ASA/MSA used for network
access authentication is different from the AAA server used for
mobility service authentication and authorization.
7. IANA Considerations
This document does not require actions by IANA. G6.5 The overall AAA solution for the integrated scenario MUST
support the scenario where the AAA server of the ASA/MSA used
for network access authentication is different from the AAA
server used for mobility service authentication and
authorization.
8. Security Considerations 7. Security Considerations
As stated in Section 5.1 the AAA-HA interface must provide mutual As stated in Section 5.1, the AAA-HA interface must provide mutual
authentication, integrity and replay protection. Furthermore, if authentication, integrity, and replay protection. Furthermore, if
security parameters (e.g., IKE pre-shared key) are transferred security parameters (e.g., IKE pre-shared key) are transferred
through this interface, confidentiality is strongly recommended to be through this interface, confidentiality is strongly recommended to be
supported. In this case the links between the HA and the AAA server supported. In this case, the links between the HA and the AAA server
of the MSA and between the NAS and the AAA server MUST be secure. of the MSA and between the NAS and the AAA server MUST be secure.
9. Acknowledgements 8. Acknowledgements
The authors would like to thank James Kempf, Alper Yegin, Vijay The authors would like to thank James Kempf, Alper Yegin, Vijay
Devarapalli, Basavaraj Patil, Gopal Dommety, Marcelo Bagnulo and Devarapalli, Basavaraj Patil, Gopal Dommety, Marcelo Bagnulo, and
Madjid Nakhjiri for their comments and feedback. Moreover the Madjid Nakhjiri for their comments and feedback. Moreover, the
authors would like to thank Hannes Tschofenig for his deep technical authors would like to thank Hannes Tschofenig for his deep technical
and editorial review of the draft. Finally the aithors would like to and editorial review of the document. Finally the authors would like
thank Kuntal Chowdhury who contribbuted identifying the goals related to thank Kuntal Chowdhury who contributed by identifying the goals
to rfc4285 authentication. related to RFC 4285 authentication.
10. References RFC 5637 AAA Goals for Mobile IPv6 September 2009
10.1. Normative References 9. References
9.1. Normative References
[1] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in [1] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004. IPv6", RFC 3775, June 2004.
[2] Patel, A. and G. Giaretta, "Problem Statement for bootstrapping [2] Patel, A. and G. Giaretta, "Problem Statement for bootstrapping
Mobile IPv6 (MIPv6)", RFC 4640, September 2006. Mobile IPv6 (MIPv6)", RFC 4640, September 2006.
[3] Giaretta, G., Kempf, J., and V. Devarapalli, "Mobile IPv6 [3] Giaretta, G., Kempf, J., and V. Devarapalli, "Mobile IPv6
Bootstrapping in Split Scenario", RFC 5026, October 2007. Bootstrapping in Split Scenario", RFC 5026, October 2007.
[4] Chowdhury, K. and A. Yegin, "MIP6-bootstrapping for the [4] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. Chowdhury,
Integrated Scenario", "Authentication Protocol for Mobile IPv6", RFC 4285, January
draft-ietf-mip6-bootstrapping-integrated-dhc-06 (work in 2006.
progress), April 2008.
[5] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. Chowdhury,
"Authentication Protocol for Mobile IPv6", RFC 4285,
January 2006.
[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[7] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. Chowdhury, 9.2. Informative References
"Mobile Node Identifier Option for Mobile IPv6 (MIPv6)",
RFC 4283, November 2005.
10.2. Informative References [6] Chowdhury, K., Ed., and A. Yegin, "MIP6-bootstrapping for the
Integrated Scenario", Work in Progress, April 2008.
[8] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, [7] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306,
December 2005. December 2005.
[9] Soliman, H., "Mobile IPv6 support for dual stack Hosts and [8] Soliman, H., Ed., "Mobile IPv6 Support for Dual Stack Hosts and
Routers (DSMIPv6)", draft-ietf-mip6-nemo-v4traversal-06 (work in Routers", RFC 5555, June 2009.
progress), November 2007.
RFC 5637 AAA Goals for Mobile IPv6 September 2009
Authors' Addresses Authors' Addresses
Gerardo Giaretta Gerardo Giaretta
Qualcomm Qualcomm
5775 Morehouse Drive 5775 Morehouse Drive
San Diego, 92109 San Diego, CA 92109
USA USA
Email: gerardo@qualcomm.com EMail: gerardo@qualcomm.com
Ivano Guardini Ivano Guardini
Telecom Italia Lab Telecom Italia Lab
via G. Reiss Romoli, 274 via G. Reiss Romoli, 274
TORINO, 10148 TORINO 10148
Italy Italy
Email: ivano.guardini@telecomitalia.it EMail: ivano.guardini@telecomitalia.it
Elena Demaria Elena Demaria
Telecom Italia Lab Telecom Italia Lab
via G. Reiss Romoli, 274 via G. Reiss Romoli, 274
TORINO, 10148 TORINO 10148
Italy Italy
Email: elena.demaria@telecomitalia.it EMail: elena.demaria@telecomitalia.it
Julien Bournelle Julien Bournelle
Orange Labs Orange Labs
Email: julien.bournelle@gmail.com EMail: julien.bournelle@gmail.com
Rafa Marin Lopez Rafa Marin Lopez
University of Murcia University of Murcia
30071 Murcia 30071 Murcia
Spain Spain
Email: rafa@dif.um.es EMail: rafa@dif.um.es
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
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.
 End of changes. 94 change blocks. 
237 lines changed or deleted 267 lines changed or added

This html diff was produced by rfcdiff 1.37a. The latest version is available from http://tools.ietf.org/tools/rfcdiff/