MIPSHOP Working Group W. Haddad
Internet-Draft S. Krishnan
Expires: March 25, 2007 Ericsson Research
September 21, 2006
Authenticating FMIPv6 Handovers
draft-haddad-mipshop-fmipv6-auth-02
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 March 25, 2007.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document specifies a scheme to secure the handover signaling in
FMIPv6 using one way hash chains. The values generated in a one way
hash chain will be used one at a time during each handoff to
authenticate the signaling messages.
Haddad & Krishnan Expires March 25, 2007 [Page 1]
Internet-Draft FMIPv6 Authentication September 2006
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions used in this document . . . . . . . . . . . . . . 4
3. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Protocol Operation . . . . . . . . . . . . . . . . . . . . . . 6
5. New Options . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.1. Hash Handoff Option (HHO) . . . . . . . . . . . . . . . . 9
5.2. Hash Extension Option (HEO) . . . . . . . . . . . . . . . 9
5.3. Handoff Vector Option (HVO) . . . . . . . . . . . . . . . 10
5.4. Handoff Option (HO) . . . . . . . . . . . . . . . . . . . 11
5.5. Hash Chain Option (HCO) . . . . . . . . . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . . . . 15
Haddad & Krishnan Expires March 25, 2007 [Page 2]
Internet-Draft FMIPv6 Authentication September 2006
1. Introduction
FMIPv6 protocol (described in [RFC4068]) specifies a fast handoff
procedure for IPv6 mobile nodes, which is based on tunneling data
packets between the mobile node's previous and new access routers
(ARs). The FMIPv6 protocol specification does not provide a method
to establish a handoff key to secure the FMIPv6 signaling messages
between the MN and the AR. Current proposed schemes require
generation of a handoff key at each handover in order to secure the
handoff signaling.
This draft suggests a mechanism based on the one-way hash chain
technique to authenticate the handoff signaling messages without the
burden of generating one "handoff key" by using public keys, per
handoff procedure. Values generated in a OWHC will be used one at a
time during each handoff to authenticate the signaling messages.
Haddad & Krishnan Expires March 25, 2007 [Page 3]
Internet-Draft FMIPv6 Authentication September 2006
2. 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 [RFC2119].
Haddad & Krishnan Expires March 25, 2007 [Page 4]
Internet-Draft FMIPv6 Authentication September 2006
3. Glossary
One Way Hash Chain (OWHC)
A one way chain (Vo...Vn) is a collection of values such that each
value Vi (except the last value Vn) is a one-way function of the
next value Vi+1. In particular, we have Vi = H(Vi+1), for i
belonging to [0,n[. For clarity purpose and to avoid confusion,
we'll use in the rest of this document the notation V[i] instead
of Vi, which means V[i+1] points to Vi+1...
Fast Binding Update (FBU)
A message from the MN instructing its PAR to redirect its traffic
towards the nAR.
Previous Access Router (pAR)
The MN's default router prior to its handover.
New Access Router (nAR)
The MN's default router subsequent to its handover.
Fast Binding Acknowledgment (FBA)
A message from the pAR in response to an FBU.
Haddad & Krishnan Expires March 25, 2007 [Page 5]
Internet-Draft FMIPv6 Authentication September 2006
4. Protocol Operation
In order to avoid using heavy cryptographic operations and redundant
signaling messages to generate a handoff key each time the MN
switches to a new AR, the MN should be able to use simpler mechanisms
such as OWHC technique in order to authenticate the FBU message sent
to its pAR. On the other side, the network access infrastructure
should also provide the MN enough assurance that the FBA message is
coming from the same AR, which received the FBU message.
Furthermore, it is important to mention that a fast growing class of
mobile devices tend to have very limited battery and processing
power. Thus the available energy must be meticulously controlled and
consumed, i.e., not to be wasted on exchanging unnecessary redundant
signaling messages nor on computing unnecessary RSA signatures.
Consequently, care should be taken to rely whenever possible on low
processing power operations and to minimize the amount of signaling
messages sent from the MN.
The suggested protocol allows an FMIPv6 enabled MN to generate a OWHC
(e.g., 20 values) prior to triggering the first fast handoff
procedure (i.e., sending an FBU message following the receipt of a
PrRtAdv message from its AR). The length of each value of the OWHC
SHOULD be equal to 128 bits and SHOULD be used together with another
parameter to generate each nCoA interface identifier (IID).
In order to minimize using expensive processing power operations, the
MN SHOULD use the SEND procedure only at the beginning, i.e., when
switching for the first time to another AR. In this case, the MN
sends a RtSol message signed with CGA to its current AR, prior to
triggering a fast handoff procedure. The RtSol message SHOULD carry
the tip of the MN's OWHC in a new option called the "hash handoff"
option (HHO).
Upon receiving a RtSol message carrying an HHO, the AR SHOULD reply
by sending confidentially a 64-bit unique parameter called "Handoff
Vector" (HV). For this purpose, the AR MUST encrypt the HV with the
MN's CGA public key and inserts it in a unicast RtAdv message before
sending it to the MN. The AR SHOULD also store the sender's current
IPv6 address, the associated OWHC value and the corresponding HV in
its mobile cache entries (MCE) for a limited lifetime.
Note that an additional optimization would mainly target the use of
CGA technology and would consist on using the Optimized SEND protocol
(described in [OptiSEND]).
In order to respect the MN's privacy, the HV will be used to hide any
correlation between the MN's nCoA and the previous CoA (pCoA). This
Haddad & Krishnan Expires March 25, 2007 [Page 6]
Internet-Draft FMIPv6 Authentication September 2006
is achieved by using a simple computation involving the HV and the
MN's CoAs.
In addition, upon receiving a valid FBU message from the MN, the AR
SHOULD hash the current HV value then forward the first 64-bit value
of the resulting hash, i.e., new HV, to the MN's nAR. The new HV
(nHV) is inserted in a new option carried by the Handoff Initiate
(HI) message. Note that we assume that all links between ARs are
secure and the network access infrastructure can be trusted.
When the MN performs a fast handoff procedure (other than the first
one), it starts by autoconfiguring a new CoA. For this purpose, it
has to compute the nCoA IID. This is done in the following way:
nCoA (IID) = First [64, OWHC(NV)) XOR First(64, nHV)]
The rule to generate the nHV is the following:
nHV = First[64, SHA1((n-1)HV)]
Where:
- OWHC(NV) is the next 128-bit undisclosed value from the MN's OWHC.
- First(x,y) is a function which extracts the first "x" bits from
"y".
- nHV is the new HV value received by the MN's nAR and (n-1) is the
previous value used by the MN's pAR to check the validity of the FBU
message.
After generating the nCoA's IID, the MN generates another 64-bit
value from XORing the remaining 64-bit of the OWHC(NV) with nHV. The
resulting value is called "Hash Extension" (HE) value and is sent in
a new option carried by the FBU message. The last step is to
authenticate the FBU message with the 128-bit OWHC(NV) and insert the
result in the BAD.
Procedures to exchange FBU/FBA messages between the MN and ARs are
described in the following:
Upon receiving an FBU message, the AR (i.e., the pAR which has
generated the HV) checks its MCE for an entry containing the MN's
pCoA. If the MN's pCoA is found, then the pAR decodes the nCoA IID
by using its nHV then it decodes the HE value and concatenates the
result with the nCoA's IID. The next step consists on hashing the
concatenation of the two decoded values and comparing the first 128
bits of the resulting hash to the 128-bit OWHC disclosed value stored
in the MN's corresponding entry.
If the two values are equal, then the pAR proceeds to check the
authenticity of the BU message and sends an FBA message to the MN.
Haddad & Krishnan Expires March 25, 2007 [Page 7]
Internet-Draft FMIPv6 Authentication September 2006
The FBA message MUST be authenticated with the same key, i.e.,
OWHC(NV), in order for the MN to check if the FBA message has been
sent by the same entity which has received the MN's corresponding HV
and the FBU message.
Note that the 128-bit OWHC value SHOULD be forwarded by the pAR to
the nAR in the HI message. For this purpose, a new option called
"Hash Chain" Option (HCO) is defined to carry the OWHC value in the
HI message.
When the nAR gets an HI message carrying an HV, it SHOULD store it
together with the MN's nCoA in its cache memory for future use. As
mentioned earlier, after using SEND protocol with the first AR, any
subsequent AR visited by the MN MUST NOT use the same HV value used
by the previous one. The same requirement applies also to the MN,
which has to hash again its current HV value before using it to
compute the nCoA IID.
Haddad & Krishnan Expires March 25, 2007 [Page 8]
Internet-Draft FMIPv6 Authentication September 2006
5. New Options
This proposal defines 5 new options described in the following:
5.1. Hash Handoff Option (HHO)
This option is used to carry a 128-bit value, which is the tip of the
MN's OWHC. The HHO is carried by the RtSol message sent by the MN to
its current AR.
The format of the option is the following:
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 Type | 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
| Vi |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option Type
<To Be Assigned By IANA>
Option Length
16
Option Data
This contains the value at the tip of the hash chain.
5.2. Hash Extension Option (HEO)
This option is used to carry the 64-bit value, which is generated
from XORing the leftmost 64 bits extracted from the 128-bit OWHC(NV)
with the first 64 bits resulting from hashing HV (or re-hashing).
The HEO is carried by the FBU message sent by the MN to the pAR.
The format of the option is the following:
Haddad & Krishnan Expires March 25, 2007 [Page 9]
Internet-Draft FMIPv6 Authentication September 2006
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 Type | 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HE |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option Type
<To Be Assigned By IANA>
Option Length
8
Option Data
Contains the 64-bit HE, which is used by the MN to provide the pAR
the ability to discover the entire OWHC(NV), i.e., the new shared
secret, in order to check the authenticity of the FBU message and to
authenticate the FBA message.
5.3. Handoff Vector Option (HVO)
This option is carried by the RtAdv message sent by the AR after
receiving a RtSol message carrying an HHO. The HVO is used to carry
the 64-bit handoff vector.
The format of the option is the following:
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 Type | 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HV |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option Type
<To Be Assigned By IANA>
Option Length
8.
Option Data
Contains the 64-bit HV, which is the used by the MN to prevent
correlation between its different CoAs generated from the same OWHC,
Haddad & Krishnan Expires March 25, 2007 [Page 10]
Internet-Draft FMIPv6 Authentication September 2006
and by the AR to decode the MN's CoA(s) and the HE value prior to
hashing the combination and checking the validity of the FBU message.
Note that the HV value is hashed by the MN at each handoff and by
each nAR before storing it in the corresponding MCE.
5.4. Handoff Option (HO)
This option is carried by the HI message sent by the pAR to the nAR
upon receiving a valid FBU message. The HO carries the 64-bit HV in
order to allow the nAR to check the validity of the FBU message sent
by the MN to its nAR.
The format of the option is the following:
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 Type | 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HV |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option Type
<To Be Assigned By IANA>
Option Length
8.
Option Data
Contains the 64-bit HV.
5.5. Hash Chain Option (HCO)
This option is carried by the HI message sent by the pAR to the nAR
upon receiving a valid FBU message. The HCO carries the 128-bit OWHC
value computed by the MN's pAR from data received in the FBU message
sent by the MN.
The format of the option is the following:
Haddad & Krishnan Expires March 25, 2007 [Page 11]
Internet-Draft FMIPv6 Authentication September 2006
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 Type | 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| HC |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option Type
<To Be Assigned By IANA>
Option Length
16
Option Data
Contains the last disclosed 128-bit value from the MN's OWHC.
Haddad & Krishnan Expires March 25, 2007 [Page 12]
Internet-Draft FMIPv6 Authentication September 2006
6. Security Considerations
This document specifies a simple scheme to secure the handover
signaling using one way hash chains. The values generated in a one
way hash chain will be used one at a time during each handover to
secure the fast mobility signaling.
The suggested proposal relies also on the assumption that a trust
relationship between the MN and the network access infrastructure
exists in order to guarantee that the HV parameter won't be forwarded
to a malicious node at a particular time.
The suggested proposal fulfills the requirements dictated by low
processing and battery power mobile devices regarding the number of
signaling messages sent by the mobile node and the use of RSA
signatures, without creating nor amplifying new and/or existing
threats.
7. References
[OptiSEND]
Haddad, W., Krishnan, S., and J. Choi, "Secure Neighbor
Discovery (SEND) Optimization and Adaptation for Mobility:
The OptiSEND protocol", Internet
Draft, draft-haddad-mipshop-optisend- 01.txt, June 2006.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997.
[RFC4068] Koodli, R., "Fast Handovers for Mobile IPv6", Internet
Draft, draft-ietf-mipshop-fmipv6-rev-00.txt, April 2006.
Haddad & Krishnan Expires March 25, 2007 [Page 13]
Internet-Draft FMIPv6 Authentication September 2006
Authors' Addresses
Wassim Haddad
Ericsson Research
Torshamnsgatan 23
SE-164 80 Stockholm
Sweden
Phone: +46 8 4044079
Email: Wassim.Haddad@ericsson.com
Suresh Krishnan
Ericsson Research
8400 Decarie Blvd.
Town of Mount Royal, QC
Canada
Phone: +1 514 3457900
Email: Suresh.Krishnan@ericsson.com
Haddad & Krishnan Expires March 25, 2007 [Page 14]
Internet-Draft FMIPv6 Authentication September 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.
Haddad & Krishnan Expires March 25, 2007 [Page 15]