MIPSHOP Working Group Jaeduck Choi
Internet Draft Doohwan Kim
Expires: January 7, 2009 Souhwan Jung
Soongsil University
July 7, 2008
A Handover Authentication based on AAA server in FMIPv6
draft-choi-mipshop-handover-authentication-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 January 7, 2009.
Choi, et al. Expires January 7, 2009 [Page 1]
Internet-Draft Handover Authentication in FMIPv6 July 2008
Abstract
This document describes a handover authentication protocol based on
the AAA server in FMIPv6. The proposed scheme employs the Diffie-
Hellman (DH) algorithm to enhance security aspects, and modifies the
DH key exchange to reduce computational cost at the Mobile Node (MN)
by delegating exponential operation to the AAA server. The MN and
Access Router (AR) establish the handover key HK through the AAA
server. The main advantage of this document is more secure and
suitable to a light-weight mobile terminal.
Table of Contents
1. Introduction.................................................3
2. Terminology..................................................3
3. Protocol Operations..........................................4
3.1. Overview................................................4
3.2. Protocol Details........................................6
3.2.1. MN Behavior........................................7
3.2.2. AR Behavior........................................8
3.2.3. AAA Server Behavior................................8
4. Message Formats..............................................9
4.1. Handover Authentication Request (HAReq).................9
4.2. Handover Authentication Response (HAResp)..............10
4.3. Options................................................11
5. Security Considerations.....................................12
6. IANA Considerations.........................................13
7. References..................................................13
7.1. Normative References...................................13
Authors' Addresses.............................................14
Intellectual Property Statement................................15
Disclaimer of Validity.........................................15
Copyright Statement............................................15
Acknowledgment.................................................15
Choi, et al. Expires January 7, 2009 [Page 2]
Internet-Draft Handover Authentication in FMIPv6 July 2008
1. Introduction
In the mobile IP networks [2],[3], the handover authentication should
be provided to protect signaling messages against security
vulnerabilities such as the Denial of Service (DoS) attack or the
intercept attack by packet redirection. Also, it should require less
computing power to be suitable for a light-weight mobile terminal.
This document describes a handover authentication based on a light-
weight DH key exchange with the AAA server. The MN and the AR
establish the handover key HK through the AAA while the MN belongs to
the AR domain. The proposed protocol also supports a robust security
feature such as Perfect Forward Secrecy (PFS) and Perfect Backward
Secrecy (PBS). Also, it requires less computation at the MN by
delegating the DH half-key generation to the AAA server.
This document defines two messages HAReq and HAResp, and new options
to carry out handover authentication.
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 [1].
New terminologies are defined in this document.
Handover Authentication Request (HAReq):
HAReq is a message to deliver parameters for the handover
authentication to the AAA.
Handover Authentication Response (HAResp):
HAResp is a message to deliver parameters for the handover
authentication to the MN, and notify the MN of the success or
failure of the handover authentication.
HK_i :
Handover key between the MN and AR_i for securing FBU message
AK :
Authentication key derived from the master key after an initial
full EAP authentication
Choi, et al. Expires January 7, 2009 [Page 3]
Internet-Draft Handover Authentication in FMIPv6 July 2008
3. Protocol Operations
3.1. Overview
In the proposed scheme, we assume that the MN and AAA server perform
an initial full EAP authentication [4][5] during a bootstrapping
resulting that a master key is established between them. And then,
the MN and AAA server derive the Authentication Key (AK) from the
master key, and the MN and AR share a Handover Key (HK) that is also
derived from the master key. In the future, the AAA server
authenticates the MN using the AK when the MN requests the handover
authentication to the AAA server. Also, we assume that a secure
channel exists between the AR and AAA server using the TLS or IPSec
to protect handover authentication messages.
The basic idea of our scheme is using the DH key exchange to enhance
security aspects, and is modifying the DH algorithm to reduce
computational cost at the MN by delegating exponential operation to
the AAA server. Figure 1 shows the sequential steps of a proposed
protocol in FMIPv6. The MN and the AR_1 share the handover key HK_1
after the bootstrapping authentication. When the MN moves from the
AR_1 to the AR_2, the MN protects the FBU message using the HK_1. The
MN in the AR_2 domain may exchange the HK_2 with the AAA server to
protect the FBU message for the next handover. This key exchange
procedure is achieved among the MN, AR_2, and AAA server.
The AAA server authenticates the MN using the Message Authentication
Code (MAC) with the AK. If the validation is successful, the MN and
AR_2 generate a new handover key HK_2 using the DH key exchange. The
HK_2 is used for handover authentication when the MN moves from the
AR_2 to the next AR (AR_3). The MN repeats the same procedure
whenever it handovers.
Step 1
- Bootstrapping authentication
Step 2
- FBU procedure protected by HK_1 when MN moves from AR_1 to AR_2
Step 3
- Handover from AR_1 to AR_2
Step 4
- Authentication procedure between the MN and AAA server using AK
- Key exchange (HK_2) based on DH key algorithm
Step 5
- FBU procedure protected by HK_2 when MN moves from AR_2 to AR_3
Step 6
- Handover from AR_2 to AR_3
Choi, et al. Expires January 7, 2009 [Page 4]
Internet-Draft Handover Authentication in FMIPv6 July 2008
_ +-----+
+--------------------->| AAA | AK
| +-------->+-----+
| |
|1 |
| |4
| |
|HK_1 | HK_2 HK_i HK_i+1
+------+ +------+ +------+ +------+
| AR_1 | | AR_2 | ... | AR_i | |AR_i+1|
+------+ +------+ +------+ +------+
| ^ | ^
| | | |
| |2 |4 |5
| | | |
| | | |
V V V V
+------+ 3 +------+ 6 +------+
| MN |------>| MN |----->| MN |
+------+ +------+ +------+
AK, HK_1 AK, HK_2 AK, HK_3
Figure 1 Protocol Overview.
Choi, et al. Expires January 7, 2009 [Page 5]
Internet-Draft Handover Authentication in FMIPv6 July 2008
3.2. Protocol Details
Figure 2 shows the protocol of the handover authentication. In Figure
2, the MN SHOULD generate and store a random number r and value g^r
after a bootstrapping authentication. Two values are reused to reduce
computational overhead at the MN during their lifetime.
The MN moves from the AR (AR_i-1) to the current AR (AR_i) at the
time T_1. The MN and AR MUST exchange a handover key HK_i to protect
the FBU message for the next handover when the MN belongs to the AR
(AR_i) domain as shown in the following figure.
MN AR (AR_i) AAA Server
| | |
r,g^r, AK | | AK
| | |
--- T_1 : MN handovers to AR_i | |
| | |
| | |
x| HAReq (M_1, r+x, g^r) | |
|---------------------------->| |(g^(r+x)
| |g^y | /g^r)
| | HAReq (M_1, r+x, g^r, g^y)| =g^x
| |--------------------------->|
| | |
| | HAResp (M_2, g^x) |
| HAResp (M_2, M_3, g^y) |<---------------------------|
|<----------------------------| |
| | |
HK_i = g^(xy) HK_i = g^(xy)
Figure 2 Procedure of Handover Authentication.
The MN generates a new random value x and computes the message M_1.
And then, the MN sends the HAReq message to the AR. The HAReq message
contains following values.
M_1=H(AK, ID_MN||ID_AR||ID_AAA||r+x||g^r)
HAReq [M_1, ID_MN, ID_AR, ID_AAA, r+x, g^r]
Upon receiving the messages, the AR generates a random number y and
computes its DH public key g^y. The AR forwards the receiving
Choi, et al. Expires January 7, 2009 [Page 6]
Internet-Draft Handover Authentication in FMIPv6 July 2008
messages with the g^y to the AAA. The HAReq message contains
following values.
HAReq [M_1, ID_MN, ID_AR, ID_AAA, r+x, g^r, g^y]
The AAA server verifies the message M_1. If the validation is
successful, the AAA server computes a value g^(r+x), and then
extracts the value g^x, the MN's DH public key, by computing
g^(r+x)/g^r. The AAA server computes the M_2, and then replies with
the HAResp message to the AR. The AAA server also notifies the
success of authentication to the AR. The HAResp message contains
following values.
M_2=H(AK, ID_MN||ID_AR||ID_AAA||g^y)
HAResp ["Success", M_2, ID_MN, ID_AR, ID_AAA, g^x]
If the AR receives the messages including the failure notification
from the AAA server, the AR notifies the MN of the failure of the
handover authentication. Otherwise, the AR computes the new handover
authentication key HK_i=(g^x)^y= g^(xy) using the private key y and
the received value g^x from the AAA server. The AR computes M_3, and
sends the message HAResp to the MN. Note that the AR SHOULD cache the
HK_i and ID_MN for securing FBU procedure when the MN will move from
the AR (AR_i) to the next AR (AR_i+1). The HAResp message contains
following values.
M_3=H(g^(xy), M_2||ID_MN||ID_AR||ID_AAA)
HAResp ["Success", M_2, M_3, ID_MN, ID_AR, ID_AAA, g^y]
The MN verifies the M_2 using the AK. If a success, the MN computes
the new handover authentication key HK_i=(g^y)^x=g^(yx) using the
private key x and the public key g^y, and then verifies the M_3. If
the MN fails to verify the M_2 or M_3, the authentication fails. In
the future, the MN MUST perform securing FBU using the HK_i when it
moves from the AR (AR_i) to the next AR (AR_i+1).
- Securing FBU procedure: FBU, H(HK_i, FBU)
3.2.1. MN Behavior
The MN MUST share the AK with the AAA server after initial
bootstrapping authentication. Also, the MN SHOULD store a random
value r and value g^r during their lifetime.
Choi, et al. Expires January 7, 2009 [Page 7]
Internet-Draft Handover Authentication in FMIPv6 July 2008
The MN MUST use the HK_i for protecting the FBU message when the MN
handovers to the next AR (AR_i+1). After moving to the AR_i+1, the MN
MUST initiate a HAReq message to exchange the HK_i+1 with the AR_i+1.
If the MN receives the HAResp message including the success
notification from the AAA server, the MN MUST generate the HK_i and
cache it for next handover authentication. In the future, the MN MUST
use HK_i for securing FBU between the MN and AR_i when the MN moves
from the AR (AR_i) to the next AR (AR_i+1).
The MN that belongs to the AR (AR_i+1) domain MUST store the HK_i
until the MN and AR_i+1 exchange the HK_i+1. Also, the MN SHOULD
cache HK_i for its life time. If the MN comes back to the AR_i
domain, the MN SHOULD reuse its HK_i.
3.2.2. AR Behavior
Upon receiving the message HAReq from the MN, the AR MUST generate a
random number y and a value g^y. Also, the AR MUST forward the
received message HAReq with the value g^y to the AAA server, and
create cache table including the ID_MN, ID_AR, ID_AAA, y, and g^y.
The AR (AR_i) MUST compute the new handover authentication key HK_i
using its DH private key y in cache table and the received value g^x
from the AAA server, when the AR receives the message HAResp
including the success notification. Also, the AR MUST compute the
message M_3 to confirm the handover key HK_i with the MN. The AR MUST
send the message HAResp including the life time of the HK_i to
the MN. If the AR receives the failure of authentication from
the AAA server, the AR MUST delete the MN's cache table except
the DH parameters y and g^y that are not used for generating
handover key. The AR SHOULD reuse the stored value y and g^y without
computing new DH public keys.
The AR MUST verify a FBU message using the HK_i when the MN moves
from the AR (AR_i) to the next AR (AR_i+1).
3.2.3. AAA Server Behavior
The channels between the AAA server and ARs SHOULD be established by
the IPsec or TLS. Upon receiving a HAReq message from the AR (AR_i),
the AAA server MUST verify the value M_1 in the HAReq message using
the AK shared with the MN. If the AAA server fails to verify the M_1,
the AAA server MUST send a HAResp message including the failure of
authentication to the AR, and ignore the received HAReq message.
Choi, et al. Expires January 7, 2009 [Page 8]
Internet-Draft Handover Authentication in FMIPv6 July 2008
Otherwise, the AAA server MUST compute a g^x by computing
g^(r+x)/g^r. And then the AAA server MUST generate the message M_2.
The AAA server MUST send the HAResp message with the result of M_1
verification to the AR.
4. Message Formats
This document defines two messages HAReq and HAResp, and new options
to carry out handover authentication.
4.1. Handover Authentication Request (HAReq)
The HAReq MUST be sent from the MN to the AAA server through the AR
for the handover authentication. Receiving the HAReq message from the
MN, the AR MUST forward it to the AAA server. The HAReq message
SHOULD use Options to deliver extra variables for authentication (to
be assigned by IANA).
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Code | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3 Handover Authentication Request (HAReq) Message.
HAReq Fields
Message Code
8-bit field indicates the handover authentication protocol, the
value of which is taken from the IANA. A value of '1' (to be
assigned by IANA) indicates the HAReq message.
Length
8-bit field is the length of the HAReq message.
Choi, et al. Expires January 7, 2009 [Page 9]
Internet-Draft Handover Authentication in FMIPv6 July 2008
Reserved
16-bit field reserved for future use. This field is unused. It
MUST be initialized to zero by the sender and MUST be ignored by
the receiver.
Options
Options field includes extra variables for handover
authentication.
4.2. Handover Authentication Response (HAResp)
The HAResp MUST be sent to the MN in responding to a HAReq message.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Code | Length | Result Code | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4 Handover Authentication Response (HAResp) Message.
HAResp Fields
Message Code
8-bit field indicates the handover authentication protocol, the
value of which is taken from the IANA. A value of '2' (to be
assigned by IANA) indicates the HAResp message.
Length
8-bit field is the length of the HAResp message.
Result Code
8-bit field indicates the result of authentication. A value of
'200' (to be assigned by IANA) indicates the "Success", and
'400' (to be assigned by IANA) indicates the "Fail"
Choi, et al. Expires January 7, 2009 [Page 10]
Internet-Draft Handover Authentication in FMIPv6 July 2008
Reserved
16-bit field reserved for future use. This field is unused. It
MUST be initialized to zero by the sender and MUST be ignored by
the receiver.
Options
Options field includes extra variables for handover
authentication.
4.3. Options
The HAReq and HAResp messages SHOULD accommodate various options as
follows.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Code | Option Length | Option Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
. ... .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5 Option Message.
Option Fields
Option Code
8-bit field indicates extra variables as follows.
M_1 (Code number: to be assigned by IANA)
M_2 (Code number: to be assigned by IANA)
M_3 (Code number: to be assigned by IANA)
ID_MN (Code number: to be assigned by IANA)
ID_AR (Code number: to be assigned by IANA)
ID_AAA (Code number: to be assigned by IANA)
Choi, et al. Expires January 7, 2009 [Page 11]
Internet-Draft Handover Authentication in FMIPv6 July 2008
Random_1 (Code number: to be assigned by IANA)
: This value is r+x.
Random_2 (Code number: to be assigned by IANA)
: This value is g^r
DH_MN (Code number: to be assigned by IANA)
: This value is g^x.
DH_AR (Code number: to be assigned by IANA)
: This value is g^y.
HK_LifeTime (Code number: to be assigned by IANA)
Option Length
8-bit field is the length of the Options field.
5. Security Considerations
The proposed scheme assumes that there are secure channels among the
AAA server and ARs. Therefore, communications between the AAA server
and AR are secure against the MITM (Man-in-the-Middle) attack.
Although there is no secure channel between the MN and the AR, the MN
secures the messages using the MAC with the AK shared with the AAA
server. This can also protect the MN and the AR against MITM attack.
The DoS attack for exhausting resource has become a major security
threat. The DoS attack considered on our scheme is the CPU exhaustion
attack such as exponent operation when an attacker sends a number of
fake requests to the AR. In the proposed scheme, by reusing unused DH
public keys, ARs protect themselves against malicious attackers who
will try to exhaust their computing power. The AR requires two
exponent operations per handover procedure: a DH public value g^y and
handover key (g^x)^y. Upon receiving the fake requests, the AR will
generate DH public keys and forward the fake requests with the DH
public keys to the AAA server. However, the AAA server may fail to
verify the fake requests due to unknown AK, and then it notifies the
failure of authentication to the AR. For the resistance against DoS
attack, if the AR receives the failure of authentication from the AAA
server, the AR should keep the generated DH public key (g^y) to be
reused for the next request. The proposed protocol can also protect
the nodes against replay attack by using a random number and caching
the MN's ID and HK_i.
Choi, et al. Expires January 7, 2009 [Page 12]
Internet-Draft Handover Authentication in FMIPv6 July 2008
The proposed scheme provides the PFS and PBS. The PFS and PBS mean
that even if a handover key HK_i is compromised by some reasons, it
never reveals all the previous and next handover keys. We use the DH
key agreement protocol to provide the PFS and PBS. If the HK_i is
exposed by some attacks, an attacker gives no clues to guess the
previous and next handover keys. The reason is that the MN and AR
generate the handover key HK_i using new DH private key x_i and y_i
whenever the MN performs the handover authentication.
Our protocol is robust to the ping-pong problem. If the MN quickly
changes its position between the ARs, there may be the ping-pong
problem. When the MN frequently moves between the AR_i and AR_i+1,
the handover key HK_i and HK_i+1 should be changed according to its
movement area. The proposed scheme securely caches the MN's HK at the
MN and the AR. Hence, the MN can securely reuse the HK without
disclosing it and performing redundant handover authentication
procedure.
6. IANA Considerations
The IANA will allocate the numbers to the HAReq, HAResp, and options.
7. References
7.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Koodli, R., "Mobile IPv6 Fast Handovers", RFC 5268, June 2008.
[3] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.
[4] Aboba, B., "Extensible Authentication Protocol (EAP)", RFC 3748,
June 2004.
[5] Aboba, B., "Extensible Authentication Protocol (EAP) Key
Management Framework", draft-ietf-eap-keying-22 (work in
progress), October 2006.
[6] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko,
"Diameter Base Protocol", RFC 33588, September 2003.
[7] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote
Authentication Dial In User Service (RADIUS)", RFC 2865, June
2000.
Choi, et al. Expires January 7, 2009 [Page 13]
Internet-Draft Handover Authentication in FMIPv6 July 2008
Authors' Addresses
Jaeduck Choi
Soongsil University
1-1, Sangdo-dong, Dongjak-gu
Seoul 156-743
KOREA
Email: cjduck@cns.ssu.ac.kr
Doohwan Kim
Soongsil University
1-1, Sangdo-dong, Dongjak-gu
Seoul 156-743
KOREA
Email: shapja@cns.ssu.ac.kr
Souhwan Jung
Soongsil University
1-1, Sangdo-dong, Dongjak-gu
Seoul 156-743
KOREA
Email: souhwanj@ssu.ac.kr
Choi, et al. Expires January 7, 2009 [Page 14]
Internet-Draft Handover Authentication in FMIPv6 July 2008
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, 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.
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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Choi, et al. Expires January 7, 2009 [Page 15]