Mipshop V. Narayanan
Internet-Draft Qualcomm
Expires: August 28, 2006 N. Venkitaraman
Motorola
M. Khalil
H. Akhtar
Nortel
February 24, 2006
Optimized Derivation of AAA-based Handover Keys
draft-vidya-mipshop-hk-opt-aaa-00.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 August 28, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
AAA-HK [1] provides a method for a MN and an AR to establish a shared
key using a AAA server. To ensure that the round trip to the AAA
server does not delay handoff, the handover key must be derived
independent of and well ahead of the actual handoff, preferably
Narayanan, et al. Expires August 28, 2006 [Page 1]
Internet-Draft HK Optimized February 2006
immediately after moving to a new access router. This document
describes one such method of optimizing the handover key derivation
by using an AR as an authenticating server, once the MN and AR have
established a security association.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. Authenticating Server ID Mobility Option . . . . . . . . . 4
4.2. Handover Nonce Mobility Option . . . . . . . . . . . . . . 5
5. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 5
5.1. Mobile Node Considerations . . . . . . . . . . . . . . . . 6
5.2. pAR Considerations . . . . . . . . . . . . . . . . . . . . 6
5.3. nAR Considerations . . . . . . . . . . . . . . . . . . . . 6
6. Using FMIPv6 Signaling to Carry Handover Key Signaling . . . . 7
6.1. FMIPv6 Predictive Mode . . . . . . . . . . . . . . . . . . 7
6.2. FMIPv6 Reactive Mode . . . . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
10. Normative References . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
Intellectual Property and Copyright Statements . . . . . . . . . . 13
Narayanan, et al. Expires August 28, 2006 [Page 2]
Internet-Draft HK Optimized February 2006
1. Introduction
AAA-HK [1] provides a method for a MN and an AR to establish a shared
key using a AAA server. When a mobile node is handing off rapidly
from one AR to another, the round trips to the AAA server can
increase handoff. This document describes a method of optimizing the
handover key derivation between a MN and a NAR by using a PAR as an
authenticating server, once the MN and PAR have established a
security association. Additionally this document also describes a
method to piggyback the key derivation requests with the FMIP
messages.
The method provided in this document will be applicable in deployment
scenarios where the nAR and pAR share a secure trust relationship,
and , based on domain policies, the pAR can broker a trust
relationship between a mobile node and the nAR, once the MN and pAR
have a security association. A salient feature of the proposed
method is that the pAR does not get to know the actual key that MN
and nAR will share, but only enables them to establish trust.
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 [2].
In addition, this document uses the following terms:
Handover Key (HK):
Key used by a mobile node to establish its authorization to
perform routing changes and possibly other handover-related
operations (such as context transfer) on a particular care of
address on the mobile node's old access router.
3. Overview
When the mobile node first enters that domain it would utilize the
AAA server to establish a shared key with its AR using the procedure
in AAA-HK [1]. Once that key has been established, the pAR and MN
share a key and so do pAR and nAR (the latter may be preconfigured or
established by other means and is outside the scope of this
document). The nAR and MN can now establish a shared key by
exchanging public part of DH key value that is authenticated by the
pAR. Thus in this process, the pAR the pAR does not get to know the
actual key that MN and nAR will share, but only enables them to
Narayanan, et al. Expires August 28, 2006 [Page 3]
Internet-Draft HK Optimized February 2006
establish trust.
4. Message Formats
The protocol uses the same messages as described in X. In addition,
the following options are defined.
4.1. Authenticating Server ID Mobility Option
This option is used to carry the IP address or name of the entity
that the mobile node wishes to use as the authenticating server. For
instance, the IP address of the pAR may be provided in this option
contained in the HKReq message to the nAR, to indicate that the MN
wishes to use th pAR as the authenticating entity. The AR may
suggest an alternate authenticating server in the HKResp if the one
provided by the MN was not acceptable.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ AS IP Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Authenticating Server ID Mobility Option
Option Fields
Option Type
AS ID (to be assigned by IANA)
Option Length
8-bit unsigned integer, representing the length in octets of
the IP address. Value is 16.
Narayanan, et al. Expires August 28, 2006 [Page 4]
Internet-Draft HK Optimized February 2006
AS IP Address
IP Address of the entity that the MN opts to use as the
authenticating server. Typically, this is the IP Address of
the pAR. If this option is included in the HKResp, it may
contain a different AS IP address suggested by the AR.
4.2. Handover Nonce Mobility Option
This option has already been defined in AAA-HK [1]. Two additional
sub-types are introduced in this document. A subtype of '3'
indicates a DH Public Value generated by the nAR with which the MN
attempts to establish a handover key. A subtype of '4' indicates a
DH Public Value generated by the MN. All other fields are as
described in AAA-HK [1].
5. Protocol Details
Upon first entering a domain (administratively defined), the mobile
node establishes a handover key with the AR as described in AAA-HK
[1]. When the MN hands off to a nAR in the same domain, it
establishes a handover key with the NAR using the following
procedure.
The MN sends a HKReq message to the nAR, including the pAR IP address
in the Authenticating Server ID mobility option and its Diffie-
Hellman public value in the Handover Nonce Mobility Option (with
subtype 4). The MN includes the MN-AR authentication option
described in MN-AR Auth [3] in the HKReq, creating the authentication
data using the MN-pAR handover key. The nAR then sends the HKReq to
the pAR for authentication. The nAR also includes its DH public
value in another Handover Nonce Mobility Option (with sub-type 3).
This message from the nAR to the pAR is protected by some means that
is outside the scope of this document.
The pAR sends a HKResp in response to the HKReq. If the MN was
authenticated successfully by the pAR, the pAR includes both the DH
public values (of the MN and the nAR) in the HKResp, along with the
other appropriate fields as described in AAA-HK [1]. The HKResp must
contain the MN-AR Authentication Option described in MN-AR Auth
Option [3], with the authentication data created by the pAR using the
MN-pAR handover key. This message is also protected by some means
between the nAR and the pAR. As stated earlier, the method of
protection between the pAR and the nAR is outside the scope of this
document.
The nAR, upon receiving an authenticated HKResp from the pAR, notes
Narayanan, et al. Expires August 28, 2006 [Page 5]
Internet-Draft HK Optimized February 2006
the DH public value of the MN from the Handover Nonce mobility option
of sub-type 4 in the message. The nAR then sends the HKResp to the
MN. The MN notes the DH public value of the nAR from the Handover
Nonce mobility option of sub-type 3 in the message. Both the nAR and
the MN now can compute, using DH, the new handover key that is to be
shared between them.
5.1. Mobile Node Considerations
This section describes additional mobile node considerations while
using a pAR as the authenticating server for obtaining a handover key
with a nAR. In general, the mobile node considerations specified in
AAA-HK [1] apply in this document as well.
The mobile node, while using a pAR as the authenticating server, MUST
include the Authenticating Server ID Mobility Option in the HKReq.
The pAR IP address MUST be provided in that option. Also, the MN
MUST include the MN-AR Authentication Option, with the authentication
data created using the MN-pAR key. Further, the MN MUST include its
Diffie-Hellman public value in the Handover Nonce mobility option of
sub-type 4.
5.2. pAR Considerations
This section describes additional considerations for a pAR in this
document. In general, the AAA server considerations specified in
AAA-HK [1] apply to the pAR processing the HKReq in this document.
The pAR, upon receiving a HKReq from an MN (either directly or
through a nAR), MUST verify that the message contains its IP address
in the AS ID Mobility option. Further, the pAR MUST check that the
MN-AR Authentication option is present and that the authentication
data in it is valid. The pAR MUST also verify that the MN has
included a Handover Key Nonce option with a sub-type of 4. Further,
the pAR MUST also verify that the nAR has included a Handover Key
Nonce option with a sub-type of 3, proctected with an existing pAR-
nAR security association.
If the pAR is unable to process the HKReq - for instance, due to the
pAR and nAR not sharing a security association or the pAR not having
a valid handover key for the MN, the pAR MUST send a HKResp with the
status code set to INVALID_AS_ID. Otherwise, if the pAR successfully
authenticated the MN, the pAR sends back a HKResp, including the
MN-AR authentication option.
5.3. nAR Considerations
This section describes additional considerations for a nAR in this
Narayanan, et al. Expires August 28, 2006 [Page 6]
Internet-Draft HK Optimized February 2006
document. In general, the access router considerations specified in
AAA-HK [1] apply to the nAR in this document.
When a nAR receives a HKReq from an MN, it SHOULD verify that it
shares a security association with the pAR whose IP address is
included in the AS ID mobility option. If the nAR does not have an
SA with the pAR specified, it SHOULD silently drop the HKReq. If the
nAR does have an SA with the pAR, it MUST send the HKReq to the pAR,
protected by the SA. It MUST include a Handover Nonce mobility
option of sub-type 3, specifying its DH public value.
When the nAR receives the HKResp from the pAR, it MUST note the DH
public value of the MN specified in the Handover Nonce mobility
option of sub-type 4, provided the HKResp shows a status code of 0.
It MUST then send the HKResp to the MN.
6. Using FMIPv6 Signaling to Carry Handover Key Signaling
While the messaging for establishing handover keys may happen
independently, it can also be done along with the FMIP signaling
without adding latency to the critical path. This section describes
that process. This is only feasible when all the FMIP messages are
used for FMIP signaling (i.e., FBU, HI, HAck and FBAck are all
supported and used). This method of riding on top of FMIP signaling
can be used only when the pAR is being used as the authenticating
server and when the MN already shares a security association with the
pAR. An MN initiates this process by including the HKReq mobility
header in the FBU. This header must follow the binding update
mobility header. If the pAR and nAR are provisioned to enable the
pAR broker a trust relationship between the MN and nAR, the following
procedure is performed.
6.1. FMIPv6 Predictive Mode
Narayanan, et al. Expires August 28, 2006 [Page 7]
Internet-Draft HK Optimized February 2006
MN PAR NAR
| | |
|------RtSolPr------->| |
|<-----PrRtAdv--------| |
| FBU | |
|-------------------->| |
| | |
| FBU[HKReq (MN-AR auth,ID,MN PK)] |
|-------------------->| |
| | |
| |HI(HKReq,MN PK) |
| |-------------------> |
| |FBack (HKResp,NAR PK)|
| |<------------------- |
| FBack (HKResp,MN-AR auth,ID, NAR PK) |
|<------FBack---------|----FBack----------> |
| | |
disconnect forward |
| packets===============> |
| | |
| | |
connect | |
| | |
|--------- FNA ---------------------------> |
|<=================================== deliver packets
Figure 2: FMIPv6 Predictive Mode with Handover Key Signaling
In this case, the MN sends an FBU to the pAR just before handover to
nAR. As with any other FBU, the destination IP address in this
message must be the pAR. The HKReq that follows the BU mobility
option must include the MN-AR authentication option created using the
MN-pAR key. The MN must also include the public part of the DH key
in the HKReq. Once the pAR has authenticated the FBU, it must also
authenticate the HKReq. If successful, the pAR must forward the
HKReq to the nAR in the HI message. When the nAR receives this
message it creates its own DH key and SPI. It saves the MNs DH
public value and sends back a HKresp along with the HAck message and
includes the SPI and nAR's public DH part in the HKResp. The nAR
should not delay sending HKResp for calculating the DH key itself.
That computation be done after sending the HKResp. The nAR must
however verify that the address specified in the HKReq is not being
used by any other mobile node (just as it would on receiving HI with
a proposed CoA or FNA).
The pAR must then send the FBack and HKResp to the MN . The HKResp
will have the DH public part of the key from nAR. This will be
Narayanan, et al. Expires August 28, 2006 [Page 8]
Internet-Draft HK Optimized February 2006
authenticated by the pAR with which the MN already shares a key. (the
same key is used to authenticate the FBU). On successfully
authenticating the HKResp using MN-pAR key, the MN obtains the public
DH key of nAR and can compute the shared key.
If the MN did receive the key at the pAR it should send a FNA to nAR
authenticated with the MN-nAR key. If the MN did not receive the
HKResp at pAR, it must send the same HKReq (along with the FBU) in
the FNA. In that case if the nAR has already received the FBAck and
HKResp the nAR will verify that the FNA uses the same IP and MAC
address that was in the HI message received from pAR (MAC address
will be in LLA option in HI) and responds with FBAck+HKRsp that was
received from pAR. Note that even though the HKResp was originally
created by the nAR, it needs to have been authenticated by the pAR
using the pAR-MN key.
6.2. FMIPv6 Reactive Mode
MN PAR NAR
| | |
|------RtSolPr------->| |
|<-----PrRtAdv--------| |
| | |
disconnect | |
| | |
| | |
connect | |
|------FNA[FBU,HReq(MN-AR Auth,ID, MN PK)]->|
| |<-[FBU,HReq,NAR PK]--|
| | |
| |FBack(HKResp,MN-AR Auth,ID)
| |-------------------->|
| HKResp(MN-AR Auth,ID, NAR PK] |
|<------------------------------------------|
| forward |
| packets================>|
| | |
|<==================================== deliver packets
| |
Figure 3: FMIPv6 Reactive Mode with Handover Key Signaling
In this case, the MN sends an FBU to the pAR from the nAR. Here the
FNA includes the FBU and HKReq and will be authenticated
(independently) using the MN-pAR key. This will be sent from nAR to
Narayanan, et al. Expires August 28, 2006 [Page 9]
Internet-Draft HK Optimized February 2006
pAR along with the DH public part of nAR inside the HI message). The
FNA can also be authenticated using MN-pAR key if authentication of
FNA is required. In that case, the FNA will also need to be sent to
nAR. On receiving FBAck+HKResp, if authentication/authorization has
succeeded, the nAR notes the public part of DH key corresponding to
the MN and forwards FBack+HKRsp to MN. The HKResp will have the
public part of DH from nAR authenticated by pAR. So the MN can also
create the shared handover key.
7. Security Considerations
In general, the security considerations documented in AAA-HK [1]
apply to this protocol as well. In addition, this document relies on
the presence of a trust relationship between the nAR and pAR to
enable a pAR broker trust between MN and nAR. A security association
between pAR and nAR is also required to enable the pAR establish a
shared key between the nAR and MN. However the pAR does not get
access to the shared key itself.
The protocol assumes that the ARs belong to a secure network and have
security associations with each other. Hence, the compromise of a
pAR is considered rather rare and it is assumed that the network will
have mechanisms to quickly detect such a compromise. This section,
however, explains the security implications in the unlikely event of
a pAR being compromised.
If the pAR is compromised, the following cases exist: (a) the pAR may
erroneously indicate that the mobile node is not authenticated. In
this case, the MN may use the AAA server to authenticate to the nAR.
(b) the nAR may provide different DH parameters to the mobile and the
AR, resulting in the MN and nAR not having a shared key, but instead
the pAR and nAR (and the pAR and the MN) having a shared key. In
this case, a pAR would be able to send an FBU to the nAR as if the
mobile generated this FBU, thereby redirecting traffic destined to
the MN from the nAR to itself.
In cases where the HKResp is sent from the nAR directly to the MN, it
is possible for the nAR to sign the HKResp with the HK it shares with
the MN so that the MN can verify that it indeed shares a key with the
nAR. In the case where the HKResp is carried in the FBAck via the
pAR to the MN, this is not reliable enough, as the pAR may still
replace the nAR's signature in the HKResp with the key it just
generated with the MN. In this case, if the FNA is protected using
the HK shared between the nAR and MN, the nAR would realize that it
has the wrong HK upon receiving the FNA. Alternately, the HKResp can
be delayed and sent directly to the MN from the nAR, after the MN
attaches to the nAR.
Narayanan, et al. Expires August 28, 2006 [Page 10]
Internet-Draft HK Optimized February 2006
The next version of this draft will attempt to provide clarifications
to protocol behavior to address some of the concerns mentioned in
this section.
8. IANA Considerations
TBD
9. Acknowledgments
10. Normative References
[1] Narayanan, V., "Handover Keys Using AAA",
draft-vidya-mipshop-handover-keys-aaa-01 (work in progress),
October 2005.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[3] Venkitaraman, N., "Mobile Node-Access Router Authentication
Option", draft-narayanan-mipshop-mn-ar-auth-option-00 (work in
progress), October 2005.
[4] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.
[5] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
Neighbor Discovery (SEND)", RFC 3971, March 2005.
[6] Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068,
July 2005.
Narayanan, et al. Expires August 28, 2006 [Page 11]
Internet-Draft HK Optimized February 2006
Authors' Addresses
Vidya Narayanan
Qualcomm
5775 Morehouse Dr
San Diego, CA 92121
US
Email: vidyan@qualcomm.com
Narayanan Venkitaraman
Motorola
1301 E. Algonquin Road
Schaumburg, IL 60196
US
Email: narayanan.venkitaraman@motorola.com
Mohamed Khalil
Nortel Networks
2221 Lakeside Blvd
Richardson, TX 75082
US
Email: mkhalil@nortelnetworks.com
Haseeb Akhtar
Nortel Networks
2221 Lakeside Blvd
Richardson, TX 75082
US
Email: haseebak@nortelnetworks.com
Narayanan, et al. Expires August 28, 2006 [Page 12]
Internet-Draft HK Optimized February 2006
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (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.
Narayanan, et al. Expires August 28, 2006 [Page 13]