One document matched: draft-haddad-mipshop-fmipv6-auth-01.txt
Differences from draft-haddad-mipshop-fmipv6-auth-00.txt
MIPSHOP Working Group W. Haddad
Internet-Draft S. Krishnan
Expires: December 28, 2006 Ericsson Research
June 26, 2006
Authenticating FMIPv6 Handovers
draft-haddad-mipshop-fmipv6-auth-01
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 December 28, 2006.
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 secure
the signaling messages.
Haddad & Krishnan Expires December 28, 2006 [Page 1]
Internet-Draft FMIPv6 Authentication June 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. Token Achnowledgment Option (TAO) . . . . . . . . . . . . 9
5.3. Handoff Vector Option (HVO) . . . . . . . . . . . . . . . 10
5.4. Handoff Option (HO) . . . . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
Intellectual Property and Copyright Statements . . . . . . . . . . 14
Haddad & Krishnan Expires December 28, 2006 [Page 2]
Internet-Draft FMIPv6 Authentication June 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 chains to
authenticate the handoff signaling messages without the burden of
generating one "handoff key" per handoff procedure. Values generated
in a OWHC will be used one at a time during each handoff to secure
the signaling messages.
Haddad & Krishnan Expires December 28, 2006 [Page 3]
Internet-Draft FMIPv6 Authentication June 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 December 28, 2006 [Page 4]
Internet-Draft FMIPv6 Authentication June 2006
3. Glossary
+---------------------+---------------------------------------------+
| Term | Definition |
+---------------------+---------------------------------------------+
| One Way Hash Chain | A one way chain (Vo...Vn) is a collection |
| (OWHC) | 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 | A message from the MN instructing its PAR |
| (FBU) | to redirect its traffic towards the NAR. |
| | |
| Previous Access | The MN's default router prior to its |
| Router (pAR) | handover. |
| | |
| New Access Router | The MN's default router subsequent to its |
| (nAR) | handover. |
| | |
| Fast Binding | A message from the PAR in response to an |
| Acknowledgment | FBU. |
| (FBA) | |
+---------------------+---------------------------------------------+
Table 1: Glossary
Haddad & Krishnan Expires December 28, 2006 [Page 5]
Internet-Draft FMIPv6 Authentication June 2006
4. Protocol Operation
In order to avoid generating a handoff key each time the MN switches
to a new AR, the MN should be able to use a OWHC 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. In
fact, it has been shown that the wireless transmission of one bit can
require over 1000 times more energy than a single 32-bit computation
[EALDC]. 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.
Finally, it should be noted that using OWHC to authenticate the FBU
messages should not increase nor create new vulnerabilities, which
can be exploited by malicious nodes to violate the MN's privacy. For
this purpose, the suggested proposal prevents a malicious node
located on the direct path between the MN and the CN from correlating
different CoAs sent in different binding updates (BU) messages with
the same identity, especially that OWHC values can easily be
correlated.
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 64 bits and SHOULD be used together with another
parameter to generate the interface identifier (IID) to configure the
nCoA.
In order to minimize using expensive processing power operations, the
MN SHOULD use the SEND procedure only at the beginning, i.e., when
preparing its first fast handoff 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 encrypts the HV with the MN's
Haddad & Krishnan Expires December 28, 2006 [Page 6]
Internet-Draft FMIPv6 Authentication June 2006
CGA public key and inserts it in a unicast RtAdv message then sends
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 as mentioned earlier, the HV
will be used to hide any correlation between the MN's nCoA and the
previous one (pCoA). This is achieved by using a simple computation
involving the HV and the MN's CoAs.
The HV should also be sent by the MN's current AR to the new one in a
new option carried by the Handoff Initiate (HI) message and MUST
remain unchanged as long as the MN is using the same OWHC. Note that
we assume that all links between ARs are secure and the network
access infrastructure can be trusted.
Following the above, when the MN needs to autoconfigure a new CoA, it
has to compute the correspondent IID in the following way:
nCoA (IID) = OWHC(NV) XOR HV
Where OWHC(NV) is the next 64-bit undisclosed value from the MN's
OWHC.
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 an entry is found, then the pAR decodes the nCoA IID by
using the corresponding HV, then hashes the resulting value and
compares it to the 64-bit OWHC disclosed value stored in the MN's
corresponding entry (i.e., the "tip" of the OWHC in case it is the
first fast handoff). If the two values are equal, then the pAR
SHOULD send an FBA message. The FBA message MUST carry a Token
Acknowledgment (TAck) value, which allows 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.
The TAck value SHOULD be equal to the first 64 bits generated from
hashing the MN's nCoA sent in the FBU message, after decoding it
(i.e., using the corresponding HV). The procedure to generate the
TAck is the following:
TAck = First[ 64, SHA1[ nCoA(prefix) | (nCoA(IID) XOR HV) ] ]
When the nAR gets an HI message carrying an HV, it SHOULD store it
Haddad & Krishnan Expires December 28, 2006 [Page 7]
Internet-Draft FMIPv6 Authentication June 2006
together with the MN's nCoA in its cache memory for future use. In
fact, after using SEND protocol with the first AR, any subsequent AR
visited by the MN MUST NOT accept an FBU message sent by the MN if
the claimed nCoA (IID) is not valid. In order to check the validity
of the nCoA, the nAR MUST first decode the two MN's IPv6 addresses,
i.e., it has to compute the following:
- pCoA (IID) XOR HV (1)
- nCoA (IID) XOR HV (2)
After decoding the two addresses, the nAR hashes the value obtained
in (2) and compares the result to (1). If the two values are equal
then the FBU is accepted and an FBA message is sent. Otherwise, the
nAR MUST discard the FBU message.
Haddad & Krishnan Expires December 28, 2006 [Page 8]
Internet-Draft FMIPv6 Authentication June 2006
5. New Options
This proposal defines 4 new options described in the following:
5.1. Hash Handoff Option (HHO)
This option is used to carry a 64 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 | 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vi |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option Type
<To Be Assigned By IANA>
Option Length
8.
Option Data
This contains the value at the tip of the hash chain.
5.2. Token Achnowledgment Option (TAO)
This option is used to carry the 128-bit value, which is generated
from hashing the MN's nCoA after decoding its IID with the MN's
corresponding HV then appending to it the 64-bit nCoA prefix. The
TAO is carried by the FBA message sent by the MN's pAR upon receiving
a valid FBU message.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TA |
Haddad & Krishnan Expires December 28, 2006 [Page 9]
Internet-Draft FMIPv6 Authentication June 2006
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option Type
<To Be Assigned By IANA>
Option Length
8
Option Data
Contains the 64-bit TA, which is used by the MN as a proof that the
FBA message has been sent by a node, which possesses its HV and has
also received its valid FBU 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,
and by the AR to decode the MN's CoA(s) prior to hashing it and
checking the validity of the FBU message.
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 option carries the 64-bit HV
Haddad & Krishnan Expires December 28, 2006 [Page 10]
Internet-Draft FMIPv6 Authentication June 2006
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.
Haddad & Krishnan Expires December 28, 2006 [Page 11]
Internet-Draft FMIPv6 Authentication June 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
[EALDC] Barr, K. and K. Asanovic, "Energy Aware Lossless Data
Compression", ACM Proceedings of MobiSys, May 2003.
[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 December 28, 2006 [Page 12]
Internet-Draft FMIPv6 Authentication June 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 December 28, 2006 [Page 13]
Internet-Draft FMIPv6 Authentication June 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 December 28, 2006 [Page 14]
| PAFTECH AB 2003-2026 | 2026-04-24 01:48:50 |