Internet DRAFT - draft-nakhjiri-pmip-key
draft-nakhjiri-pmip-key
Internet Draft Madjid Nakhjiri
draft-nakhjiri-pmip-key-02.txt Narayanan
Venkitaraman
Category: Internet draft Motorola Labs
Expires: August 2006
February 2006
EAP based Proxy Mobile IP key bootstrapping:
A WiMAX applicability example
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 in July 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
The specification for a EAP based keying methodology for Proxy Mobile
IP security is a topic of interest within some standard bodies such
as WiMAX and is still under consideration. In this document, the
authors intend to provide an first pass illustration on how the EAP
Nakhjiri et. al. Expires - August 2006 [Page 1]
keying framework may be used for bootstrapping keys between two
agents performing a network service such as Proxy Mobile IP function.
Care is taken so that the solution is aligned as closely as possible
to the guidelines provided by the EAP Keying framework [EAPKEY]. The
solution is, however, fitted to the constraints of the existing SDO
scenarios and may not fully fit a future generic application keying
solutions defined by HOAKEY.
Conventions used in this document
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.
Table of Contents
1. Introduction...................................................2
2. Terminology and Assumptions....................................3
3. Overview.......................................................5
4. Security considerations........................................8
5. References.....................................................8
6. Appendix A Use of PMIP-AMSK as PMN-AAA key.....................9
Acknowledgments..................................................10
Author's Addresses...............................................10
1. Introduction
Mobile IP [X] specifies a protocol for a node to receive packets
destined to its home IP address even when the node is not present in
its home network. It specifies registration request (RRQ) and
response (RRP) messages between the mobile node and a Home Agent. The
HA then receives packets on behalf of the mobile node and tunnels the
packets to the present location of the mobile node. The RRQ and RRP
messages must be authenticated using key shared by the mobile node
and its home agent.
In some cases, such as cases where nodes connecting to the network do
not have a Mobile IP stack but require mobility services, the network
may have to rely on a proxy (called the Proxy Mobile Node, PMN) to
generate the registration requests and process the registration
responses on behalf of the node. To ensure Mobile IP compatible
behavior, the control packets from the PMN must be sent via the
current subnet of the mobile node. So the MIP control packets
generated by the PMN are tunneled via an assistant function that
resides in the current subnet of the mobile node (located say in a
foreign agent or an access point). Thus the PMN (and the PMN-HA key)
Nakhjiri et. al. Expires - August 2006 [Page 2]
can reside in a single/secure location even as the mobile nodes moves
from one subnet to another
This document describes a scheme by which a proxy mobile node can
obtain the keys to generate registration requests and validate the
response from the Home agent. The process explained here is being
2. Terminology and Assumptions
Mobile Node (MN) (peer)
The entity that includes EAP peer functionality as described by
[EAP3748] and keying frameworks [EAPKEY], with the exception that
mobile node may not have a direct link to the EAP pass-through
authenticator. In this document we may use the terms MN and EAP
peer interchangeably. MN is the entity whose records are kept at
the AAA server and is authorized for various network services.
Proxy Mobile Node (PMN):
An entity in that generates RRQs on behalf of a mobile node and
processes the RRPs. PMN is also the entity that is final key
holder for the PMIP Key.
Proxy MIP key (PMIP key):
A key that is shared between the Proxy Mobile Node (PMN) and the
home agent and is used to generate the Mobile-Home-Authentication
extension to be included in Mobile IP registration requests (RRQ)
and/or responses (RRP).
MN-AAA key
The MN-AAA key is the basis for the creation of all the keys that
are created dynamically between MN and its mobility agents. MN-AAA
key is used for calculation of the authenticator field inside an
MN-AAA-Authentication extension [RFC3012bis04] included in a
Mobile IP registration request for the home agent and verified by
the home AAA server. The details of Mobile IPv4 key bootstrapping
are covered in [RFC3957] and [RADIUS-MIP]. Note that this key is
different from a possible PMN-AAA key, that may be established
between PMN and the AAA server (if needed).
Home agent (HA)
A Mobile IP Home Agent that is responsible for generating and
keeping a binding between mobile node home address and its care of
address.
Nakhjiri et. al. Expires - August 2006 [Page 3]
EAP server
EAP server is the entity that engages in EAP method exchange and
terminates the EAP authentication method with peer as defined in
[EAP3748]. EAP server is capable of generating and exporting
relevant EAP keys as defined in [EAP-KEY].
Home AAA server
HAAA server is the entity that is the main point of trust and
authorization (AAA) in the administrative domain, and maintains
peer information and possibly keying information. The AAA server
relies on EAP server for execution of EAP-method authentications.
EAP pass-through Authenticator
The pass-through authenticator is the entity between a peer and a
backend EAP server that is passing through EAP Request and Response
messages ([RFC3748]) without understanding their data content. It
can understand EAP success and failure messages. The authenticator
may not necessarily be the terminating point for the physical
access link to the peer.
AAA client
The first AAA entity (from mobile node side), that engages in AAA
protocol conversation with the AAA infrastructure leading to the
home AAA server. This entity is also responsible for encapsulating
EAP messaging inside AAA protocol messages (RADIUS, [RFC3579] or
Diameter). The logical AAA client is not responsible for
understanding EAP messaging, however, it is the physical entity
that receives any transported master keys produced as part EAP
keying process, if the transport is performed through AAA
protocols. According to current EAP keying documentation AAA layer
entities are to delete the transported keys and this may mean a
logical AAA client will not have an authority to act as a key
holder.
Key holder
This entity is the one that holds the master key received from AAA
server and possibly performs further key derivations and
distribution functions for access nodes. In newer wireless
architectures, such as WiMAX, the authenticator function is split
between a key holder that receives the master keys from the AAA
server and key receiver that also performs functions utilizing the
key. In this document we assume the key holder is part of
authenticator that receives the PMIP-key (also the AAA client) and
use authenticator and key holder definitions interchangeably.
Nakhjiri et. al. Expires - August 2006 [Page 4]
3. Overview
The objective for a PMIP keying solution is to establish a shared key
between the PMN and HA so that they are able exchange authenticated
MIP registration messages.
Our basic idea is to enable the AAA server derive a PMIP key and
transport the key to the PMN in conjunction with the EAP access
network authentication. So that the PMN can generate authenticated
Mobile IP registration requests (RRQ) towards the HA by using the
PMIP key as message authentication key.
When a HA receives its first registration request corresponding to a
mobile node from the PMN, the HA can obtain the corresponding key
from the AAA.
Note that this requires the AAA server to cache the PMIP key or
related keying material and later retrieve the key for delivery to HA
upon request.
The following diagram provides a summary of the entities in the
system, the flow of PMIP keying material to the PMN and the Home
Agent and the data path from the Home agent to the MN via a optional
foreign Agent.
EAP/AAA
Authenticator< =====================> AAA/EAP
PMN <-----------AAA client ^^ <-----------------------Server
PMIP-key || AAA (PMIP-key) |
|| |
||EAP |
|| |
|| |
VV V
MN<-+--+-+-+-++-+-+-+-+-Home Agent
==== EAP signaling
---- PMIP Key Path
-+-+- Data Path
Figure 1: Interactions between various entities in PMIP keying
The operation is as follows (shown in Figure 2)
. During network entry the mobile node (MN) performs an EAP
authentication with the EAP server collocated with home AAA server
via the pass-through authenticator.
. After successful EAP authentication, the home AAA server after
examining the MN service policies and/or possibly receiving
specific requests (through initial AAA requests) for Proxy Mobile
Nakhjiri et. al. Expires - August 2006 [Page 5]
IP service, authorizes the MN for Proxy Mobile IP service. Upon
this authorization, the AAA server (acting as AAA layer in EAP
framework) requests a specific AMSK for proxy Mobile IP application
from the EAP layer. The EAP layer at AAA server based on the
request from the AAA layer calculates the PMIP-AMSK from the EMSK
as follows:
PMIP AMSK = PRF (EMSK, MN_ID |Authenticator_ID| "PMIP Application
Key"| Key length)
. Note that Home Agent ID is not used in the key binding to allow
flexibility towards alternative dynamic home agent assignments.
Peer aPMN Authenticator HA EAP/ AAA
---- --- ------------- --- ----------
| | | EAP authentication |
|< --------------------------------------------- >|
| | | PMIP-key transport |
| | PMIP-key |< ----------------------|
| |< --------------| | |
| | RRQ+Auth | | |
| |-------------------------- >| Req for key|
| | | |---------- >|
| | | | Key tx |
| | | RRP+Auth |< ----------|
| | < -------------------------| |
| | | | |
Figure 2: PMIP key bootstrapping using EAP and AAA mechanisms.
. The AAA server has now access to the PMIP-AMSK and can either use
the PMIP-AMSK to generate the PMIP-key (PMN-HA key) or send the
PMIP-AMSK to the authenticator/ AAA client to do so instead. The
latter alternative however may cause problems if the EAP Keying
framework [EAPKEY] requires the AAA entities to delete all
transported keys (including AMSKs) after transport, as the AAA
server later needs to supply this to HA later upon request.
Therefore, we recommend the AAA server to calculate the PMIP-key
from the PMIP-AMSK locally as one of the following alternatives:
PMIP-key=Truncate(PMIP-AMSK, required PMIP-key length)
PMIP-key=PRF(PMIP-AMSK, other information)
Nakhjiri et. al. Expires - August 2006 [Page 6]
. When the AAA server calculates the PMIP-key from the PMIP AMSK, the
PMIP-key is then sent securely to the AAA client using appropriate
AAA protocol mechanisms (RADIUS attributes or Diameter AVP)
following or around the same time as when an EAP success is being
sent to the EAP peer through the EAP pass-through authenticator.
Typically the pass-through authenticator is collocated with the AAA
client, so the EAP success and the PMIP-Key may be sent through the
same AAA message, assuming proper and secure key wrapping
mechanisms are provided for that message. At any rate the AAA
client function will pass the PMIP-key to the authenticator for
storage.
. It is also expected that the AAA server may also needs to also
provide proper authorization information for the 802.16e access
link, mobile node network operation (e.g. an assigned Home Address
information, HoA and other entities, such the Proxy Mobile Node for
performing Proxy Mobile IP service, including necessary
authorizations for the PMN (e.g. IP address for a Home Agent, HA,
if available), as well as other necessary information such as key
lifetimes, and possible SPI information. This information is sent
through the AAA protocol to the AAA client function to the final
destination. The life time for PMIP-key and related PMIP
authorization must never exceed the life time of the EAP session.
. The authenticator co-located with the AAA client will access the
PMIP-Key and other related information and passes the key to the
Proxy Mobile Node (PMN) function. It is possible for the PMN and
the authenticator to be physically collocated to avoid compromise
of the PMIP key due to additional transfers. It is possible that
the PMN function is in another entity physically separate (such as
inside a base station or foreign agent) from the authenticator, in
which case, care must be taken in transferring the PMIP-key to the
PMN.
. When the PMN generates a registration request (RRQ) it uses the
PMIP key to create the Mobile-Home Authentication Extension (MHAE)
to authenticate the registration request to the HA.
. When a HA receives a registration request, if it does not have the
SPI/keys corresponding to the security association with the PMN, it
queries the AAA server via an AAA Request message.
. The AAA server validates the request and sends the PMIP key (PMN-HA
key) corresponding to the requesting HA in a AAA Response message.
Nakhjiri et. al. Expires- August 2006 [Page 7]
. After receiving the PMIP key, the HA validates the MHAE in RRQ, and
processes the RRQ and generates a registration response with a
valid authentication extension using the same PMN-HA key.
Note: An alternative method for generation of PMIP-key has been
suggested as follows:
Instead of generating the PMIP-key from PMIP-AMSK directly, it has
been suggested to use the PMIP-AMSK to derive a so called PMN-AAA key
that can be used to bootstrap the PMIP-key through direct
interactions between the PMN (rather than the mobile node) and AAA
server at a later time using [RFC3957]. We will cover a short
description of this method in an appendix.
4. Security considerations
The PMN may be co-located with the authenticator itself or may reside
separately. In any case the PMIP or PMIP-AAA key must be securely
provided from the authenticator function to the PMN function. The
protocol between the PMN and the authenticator is beyond the scope of
this document.
It should be noted that, peer mobility may result in need of handover
between the physical entities the PMN is associated with. In such
cases, to avoid the security issues with compromise of PMIP-key and
to avoid the need for new interactions with the backend server, the
initial PMN, so called PMN anchor will hold on to the PMIP-key and
will perform any needed PMIP security functions in interacting with
other Mobile IP entities.
5. References
[MIPv4] C. Perkins, IP Mobility Support, IETF, RFC 3344, August
2002.
[3012bis04] C. Perkins, P. Calhoun, Mobile IP Challenge/Response
Extensions, draft-ietf-mip4-rfc3012bis-04.txt., June 2005.
[RFC3957] C. Perkins, P. Calhoun, AAA Registration Keys for Mobile
IP, IETF, RFC 3957, March 2005.
[KEYWRAP], G. Zorn, Et. Al., RADIUS Attributes for Key Delivery,
draft-zorn-radius-keywrap-08.txt.
[EAPKEY] B. Aboba, Et. Al., Extensible Authentication Protocol (EAP)
Key Management Framework, Internet Draft, IETF, draft-ietf-eap-
keying-08 (work in progress), October 2005.
Nakhjiri et. al. Expires - August 2006 [Page 8]
[EAP3748], B. Aboba, Et. Al., Extensible Authentication Protocol
(EAP)’’, RFC 3748, IETF, June 2004.
[RADIUS-MIP], M. Nakhjiri, Et. Al., RADIUS Mobile IP extensions,
Internet Draft, IETF, draft-nakhjiri-radius-mip4-02.txt, October
2005.
[RADEAP3579], B. Aboba, P. Calhoun, RADIUS (Remote Authentication
Dial In User Service) Support For Extensible Authentication Protocol
(EAP), RFC 3579, IETF, September 2003.
6. Appendix A Use of PMIP-AMSK as PMN-AAA key
This section describes an second alternative to bootstrapping the
Proxy Mobile IP keys using the PMIP-AMSK derived from EAP
authentication as PMN-AAA key. According to this proposal the PMN-AAA
key is used instead of the MN-AAA key in the process defined in
[RFC3957] and [RADIUS-MIP] to bootstrap PMN-HA key through the AAA
server. In this method:
. The AAA server after receiving the PMIP-AMSK from the EAP layer
(following EAP authentication) calculates a PMN-AAA key from the
PMIP-AMSK through a straightforward method (PMN-AAA key=PRF( PMIP-
AMSK, other PMIP info)) and sends a copy of PMN-AAA and sends
another copy to the authenticator through the AAA client.
. The authenticator passes the PMN-AAA key to the PMN for further
PMIP key bootstrapping with the AAA server.
. When the PMN needs to send a registration request to the HA, since
the PMN does not have access to the PMN-HA key, it indicates the
need for PMN-HA key by including an MN-AAA Authentication extension
in the RRQ submitted to HA, where the PMN-AAA key is used for
calculation of the authenticator field within the extension. When
the HA receives an RRQ with MN-AAA AE, it needs to refer to the AAA
server for retrieval of a PMN-HA key. It should be noted that this
method would require the AAA server to have access to a copy
(generate and/or store) of the PMN-AAA key for verification of MN-
AAA Authentication extension, when the AAA server receives the RRQ
submitted by the HA later on.
. Upon verification of the MN-AAA AE and access to MN profile, the
AAA calculates a PMIP-nonce (PMN-HA nonce) and a corresponding
PMIP-key (PMN-HA key), using the PMN-AAA key and procedures defined
in [RFC3957], and sends the nonce to the PMN in the clear and the
encrypted PMIP-key to the HA.
Nakhjiri et. al. Expires - August 2006 [Page 9]
The authors believe that due to the transitive security associations
provided between the AAA server and PMN (through AAA server-AAA
client/ authenticator SA and authenticator-PMN SA), the nonce
creation is unnecessarily complex. Furthermore, RFC3957 will still
require the HA to query AAA server for retrieval of the PMIP key and
furthermore, it requires distribution of nonces to the PMN even
though the PMN may be a trusted by the authenticator.
Acknowledgments
Authors would like to acknowledge Anand Bedekar and Avi Lior for the
discussions leading to creation of this draft.
Author's Addresses
Madjid Nakhjiri
Motorola Labs
Contact Email: Madjid.Nakhjiri@motorola.com
Narayanan Venkitaraman
Motorola Labs
Contact Email : Narayanan.Venkitaraman@motorola.com
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.
Nakhjiri et. al. Expires - August 2006 [Page 10]
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 (2005). 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.
This Internet-Draft will expire on June, 2006.
Nakhjiri et. al. Expires -
- August 2006 [Page 11]
