Internet DRAFT - draft-qiu-mipshop-mn-map-security
draft-qiu-mipshop-mn-map-security
Network Working Group Feng BAO
INTERNET-DRAFT Robert DENG
Expires: April 15, 2006 Ying QIU
Network Working Group Jianying ZHOU
October 16, 2005
A Scheme for the Security between Mobile Node
and Mobility Anchor Point in Hierarchical Mobile IPv6
<draft-qiu-mipshop-mn-map-security-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 April 15, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005). All Rights Reserved.
Expires: April 15, 2006 [Page 1]
Internet Draft MN-MAP Security October 16, 2005
Abstract
The document proposes the solution for the security between mobile
nodes and MAPs. According to the requirements of the security
statement in the working group, two modes for two scenarios are
considered in the draft: authentication-only mode and
authentication and authorization mode.
Table of Contents
1. INTRODUCTION ................................................. 2
2. NOTATIONS .................................................... 4
3. AUTHENTICATION-ONLY MODE ..................................... 4
4. AUTHENTICATION AND AUTHORIZATION MODE ........................ 6
5. SECURITY CONSIDERATIONS ...................................... 9
6. CONCLUSION ................................................... 9
7. ACKNOWLEDGEMENTS ............................................. 9
8. REFERENCES ................................................... 9
9. AUTHORS' ADDRESSES .......................................... 10
Intellectual Property and Copyright Statements .................. 10
1. INTRODUCTION
In the protocol of HMIPv6 [1], the concept of Mobility Anchor Point
(MAP) is introduced. MAP is a router located in a domain visited by
the mobile nodes. MAP provides the localized mobility management for
the visiting mobile nodes.
Every mobile node bundles three addresses: Home Address (HoA),
Regional Care-of-Address (RCoA), and On-Link Care-of-Address (LCoA).
RCoA is an address on the MAP subnet, and obtained by the mobile
Node (MN) from the visited domain. LCoA is configured on a MN's
interface based on the prefix advertised by its default router. In
fact, it is a care-of-address in normal MIPv6. Figure 1 shows the
architecture of HMIPv6.
Expires: April 15, 2006 [Page 2]
Internet Draft MN-MAP Security October 16, 2005
+----+ +----+
| HA | | CN |
+----+ +----+
| |
+---+ +---+
| |
+-------+
| MAP | RCoA
+-------+
| |
+---+ +---+
| |
+-----+ +-----+
LCoA1 | AR1 | | AR2 | LCoA2
+-----+ +-----+
+----+
| MN | movement
+----+ --------->
Figure 1. Hierarchical MIPv6 domain.
In HMIPv6, when CN sends packets to MN's RCoA, MAP intercepts the
packets and forwards the packets to MN's LCoA. However, as the
binding update (BU) message from MN to MAP is not authenticated when
MN changes its Access Router (AR), attackers can easily launch
"Redirect Attacks", i.e., the attacks which redirect the traffic
from MAP to fake destinations chosen by the attackers. On the other
hand, in some scenarios, the MAP is only open to the authorized
users.
Two security models are described in the email discussion [2]:
(1) Authentication-only model: In this model, a MAP only need to
ensure that the same MN is sending the BUs to the MAP. It is not
necessary for the MN to prove that it is authorized to use a MAP to
manage its mobility.
(2) Authentication and Authorization model: In this model, the MAP
and the MN need to know that the other end is "trusted". The MAP
also needs to know if the MN is authorized for using it.
In this document, we propose a protocol to protect the BU messages
from MN to MAP as well as the method of authenticating MN's
identification without the global PKI.
Expires: April 15, 2006 [Page 3]
Internet Draft MN-MAP Security October 16, 2005
2. NOTATIONS
The notations used throughout this paper are listed below for easy
reference:
h(): a one-way hash function, such as MD5 or SHA.
prf(k, m): a keyed pseudo random function -- often a keyed hash
function. It accepts a secret key k and a message m, and
generates a pseudo random output. This function is used for both
message authentication and cryptographic key derivations.
e(k ,m): encryption of message m with a secret key k.
Px/Sx: a public and private key pair of node X in a digital
signature scheme such as RSA or DSS.
Sig(Sx, m): node X's digital signature on a message m using a
private key Sx.
m|n: concatenation of two messages m and n.
3. AUTHENTICATION-ONLY MODE
In many scenarios the managers of MAP would like to provide free
connection for their customers, such as in conferences, hotels,
coffee bars, etc. In these scenarios, the MAP only needs to ensure
any binding update messages (BU) are from the claimed mobile nodes
(MN). The MAP not needs to check if the MNs have the right to
connect the MAP [2].
Figure 2 shows message exchange between a MN and a MAP in the
Authentication-only mode. Below is a detailed description of the
protocol.
MN MAP
| |
|==COOKIE0====>|
| |
|<===COOKIE1===| long term
| | messages
|====BU_1=====>|
| |
|<=====BA_1====|
| |
------------------------------------------
| |
|=====BU_i====>|
| | short term
|<=====BA_i====| message for BU
| |
| |
Figure 2. Message exchange in Authentication-only mode
Expires: April 15, 2006 [Page 4]
Internet Draft MN-MAP Security October 16, 2005
When a mobile node MN roams and enters to the domain of MAP, MN
creates a cookie C0 and sends
COOKIE0 = {Src=LCoA, Des= MAP, Opt=HoA, C0}
to MAP. In reply, MAP generates a nonce N1 and a cookie C1, and
sends to MN the message
COOKIE1 = {Src=MAP, Des=LCoA, Opt=HoA, C0, C1, N1}.
The use of cookies during the key exchange is a weak form of
protection against an attacker who generates a series of request
packets, each with a different spoofed source IP address, and sends
them to a protocol party. For each request, the protocol party will
first validate cookies before performing computational expensive
public key cryptographic operations and memory allocation.
Upon receiving COOKIE1, MN checks on the validity of C0, generates a
nonce N2 and replies MAP with
BU_1 = {Src=LCoA, Des=MAP, Opt=HoA, C0, C1, N1, N2,
TS, SIG_MN, Cert_MN},
where SIG_MN is MN¡¯s signature signed by its private key SK_MN
SIG_MN = Sig(SK_MN, LCoA|HoA|MAP|N1|N2|TS).
Note that the values of N1 and N2 are included in the signature
SIG_MN in order to counter replay of old signatures and to resist
chosen message attacks to the signature scheme, respectively. TS is
a time stamp. This time stamp does not have to be checked by the
recipient during the message exchange. It will be used to trace back
the culprit should a malicious mobile node flooding attack have
occurred. The Cert_MN is the public key certificate of the mobile
node that is issued by the MN¡¯s home agent and is not necessary to
be verified in this scenario.
When MAP receives BU_1, it validates the cookies, extract MN¡¯s
public key from the certificate Cert_MN, and verify the signature.
If all the validations and checking are positive, MAP assigns the
RCoA to the MN and creates an entry for the MN, which includes HoA,
RCoA, LCoA, TS, certificate, etc. Then MAP adds the entry to its BU
cache. Finally, MAP sends to MN the binding acknowledgement
BA_1 = {Src=MAP, Des=LCoA, Opt=HoA, RCoA, C0, C1, N1, N2},
Since the binding acknowledgement is not important to MN in the
scenarios, the BA message is not necessary to do any secure process.
The process for the following binding updates in the same domain is
simple. When MN moves to a new AR and gets a new LCoA, MN just needs
to send MAP the binding update message
Expires: April 15, 2006 [Page 5]
Internet Draft MN-MAP Security October 16, 2005
BU_i = {Src=LCoA, Des=MAP, Opt=HoA, old_LCoA, TS, SIG_MN_i}
where
SIG_MN_i = Sig(SK_MN, LCoA|MAP|HoA|old_LCoA|TS).
The reason of binding the old LCoA is to avoid the reply attack.
After receiving the BU_i, MAP retrieves the entry based on HoA from
its binding cache and gets the Cert_MN. If the verification of the
signature is positive, MAP accepts the new LCoA and updates its
binding cache. Meanwhile MAP replies MN
BA_i = {Src=MAP, Des=LCoA, Opt=HoA}
4. AUTHENTICATION AND AUTHORIZATION MODE
In some scenarios, the MAP and MN need to know the other end is
¡°trusted¡± and the MAP also need to know if the MN is authorized for
using it [2].
Figure 3 shows message exchange among a MN, a MAP and MN¡¯s HA in the
Authentication-Authorization mode. Below is a detailed description
of the protocol.
MN MAP HA
| | |
|===COOKIE0===>| |
| | |
|<===COOKIE1===| | long term
| | | messages
|====BU_1=====>| |
| |==REQ_Cert===>| |
| | |
| |<===REP_Cert==|
|<====BA_1=====| |
| | |
------------------------------------------------------
| | |
|====BU_i=====>| |
| | | short term
|<=====BA_i====| | message for BU
| | |
| | |
Figure 3. Message exchange in Authentication and Authorization mode
When a mobile node MN roams and enters to the domain of MAP, MN
creates a cookie C0 and sends
Expires: April 15, 2006 [Page 6]
Internet Draft MN-MAP Security October 16, 2005
COOKIE0 = {Src=LCoA, Des= MAP, Opt=HoA, C0}
to MAP. In reply, MAP generates a nonce N1 and a cookie C1, and
sends
COOKIE1 = {Src=MAP, Des=LCoA, Opt=HoA, C0, C1, N1}
to MN.
The use of cookies during the key exchange is a weak form of
protection against an attacker who generates a series of request
packets, each with a different spoofed source IP address, and sends
them to a protocol party. For each request, the protocol party will
first validate cookies before performing computational expensive
public key cryptographic operations and memory allocation. These two
messages are similar to the authentication-only mode.
Upon receiving COOKIE1, MN checks on the validity of C0, generates a
nonce N2 and a Diffie-Hellman secret value x < p, computes its
Diffie-Hellman public value g^x and its signature
SIG_MN = Sig(SK_MN, LCoA|HoA|MAP|g^x|N1|N2|TS)
using MN¡¯s private key SK_MN, where TS is a time stamp. This time
stamp does not have to be checked by the recipient during the
message exchange. It will be used to trace back the culprit should a
malicious mobile node flooding attack have occurred. Note that the
values of N1 and N2 are included in the signature SIG_MN in order to
counter replay of old signatures and to resist chosen message
attacks to the signature scheme, respectively. Finally, MN replies
MAP with the first binding update message
BU_1 = {Src=LCoA, Des=MAP, Opt=HoA, C0, C1, N1, N2,
g^x, TS, SIG_MN, Cert_MN},
where
Cert_MN = {HoA, PK_MN, Valid_Iinterval, SIG_HA}.
is the public key certificate of the mobile node which is issued by
its home agent. SK_MN and PK_MN are the private and public key pair
for MN.
When MAP receives BU_1, if the validation of the cookies is positive,
MAP then begins to verify the MN's public key certificate Cert_MN by
public key of MN¡¯s home agent. If MAP does not have the HA¡¯s
certificate in its cache, MAP will send a requesting message for
certificate to HA,
REQ_Cert = {Src=MAP, Des=HA, request_cert}.
Expires: April 15, 2006 [Page 7]
Internet Draft MN-MAP Security October 16, 2005
Then, HA will return to MAP its public key certificate issued by a
trusted CA,
REP_Cert = {Src=HA, Des=MAP, Cert_HA}.
Upon getting HA's public key certificate and verifying the
certificate through the trusted CA, MAP can verify HA's signature
SIG_HA and then trust the MN's public key certificate Cert_MN. With
the Cert_MN, MAP can further verify MN's signature. After double
checking the equality of home link's subnet prefix string embedded
in both Cert_HA and HoA, MAP can finally trust the first MN's new
binding update message BU_1 and create an entry for the MN and add
the entry to MAP¡¯s binding cache.
MAP next generates its Diffie-Hellman secret value y < p. It then
computes its Diffie-Hellman public value g^y, the Diffie-Hellman
master key
k_DH = (g^x)^y,
and a session secret
k_secret = prf(k_DH, N1|N2 )
for future security purpose.
Then MAP assigns a RCoA to MN and sends to MN the binding
acknowledgement
BA_1 = {Src=MAP, Des=LCoA, Opt=HoA, RCoA,
C0, C1, g^y, SIG_MAP, Cert_MAP},
where
SIG_MAP = Sig(SK_MAP, MAP|LCoA|HoA|RCoA|g^y|BU_1)
and
Cert_MAP = {MAP, PK_MAP, Valid_Interval, SIG_CA}
is MAP's certificate from a trusted CA, SK_MAP and PK_MAP is the
security key pair of MAP. Therefore, both parties MN and MAP could
identify each other.
After getting this message, MN first validates the cookies,
calculates the Diffie-Hellman master key k_DH = (g^y)^x and the
session secret k_master = prf(k_DH, N1|N2) for future security
purpose. Then MN also creates an entry for this channel and stores
the entry into its binding cache.
The process for following binding update in the same domain is
simple. When MN moves to a new AR and gets a new LCoA, MN just needs
to send MAP the binding update message
Expires: April 15, 2006 [Page 8]
Internet Draft MN-MAP Security October 16, 2005
BU_i = {Src=LCoA, Des=MAP, Opt=HoA, old_LCoA, TS, SIG_MN_i}
where
SIG_MN_i = Sig(SK_MN, LCoA|MAP|HoA|old_LCoA|TS).
The reason of binding the old LCoA is to avoid the reply attack.
After receiving the BU_i, MAP retrieves the entry based on HoA from
its binding cache and gets the Cert_MN. If the verification of the
signature is positive, MAP accepts the new LCoA and updates its
binding cache. Meanwhile MAP replies MN
BA_i = {Src=MAP, Des=LCoA, Opt=HoA, SIG_MAP_i}
where
SIG_MAP_i = Sig(SK_MAP, MAP|LCoA|HoA|BU_i).
5. SECURITY CONSIDERATIONS
The proposal consider the security binding update between mobile
nodes and the mobility anchor points.
6. CONCLUSION
The document proposes the solution for the security between mobile
nodes and MAPs as well as the method of authenticating MN¡¯s
identification without the global PKI. In the proposal, two security
modes are considered for different scenarios.
7. ACKNOWLEDGEMENTS
8. REFERENCES
[1] H. Soliman, C. Castelluccia, K. El Malki, "Hierarchical Mobile
IPv6 Mobility Management (HMIPv6)", RFC 4140, Aug. 2005.
[2] Discussions in MIPSHOP working group, July 2005.
[3] D. B. Johson and C. Perkins, "Mobility Support in IPv6",
RFC 3775, June 2004.
[4] F. Bao, R.Deng, Y. Qiu, J.y Zhou, "Certificate-based Binding
Update Protocol (CBU)", draft-qiu-mip6-certificated-binding-
update-03.txt, March 2005
Expires: April 15, 2006 [Page 9]
Internet Draft MN-MAP Security October 16, 2005
9. AUTHORS' ADDRESSES
Feng BAO
Institute for Infocomm Research
21 Heng Mui Keng Terrace
Singapore 119613
Phone: +65-6874-8456
EMail: baofeng@i2r.a-star.edu.sg
Robert DENG
Singapore Management University
469 Bukit Timah Road
Singapore 259756
Phone: +65-6822-0920
EMail: robertdeng@smu.edu.sg
Ying QIU
Institute for Infocomm Research
21 Heng Mui Keng Terrace
Singapore 119613
Phone: +65-6874-6742
EMail: qiuying@i2r.a-star.edu.sg
Jianying ZHOU
Institute for Infocomm Research
21 Heng Mui Keng Terrace
Singapore 119613
Phone: +65-6874-6668
EMail: jyzhou@i2r.a-star.edu.sg
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.
Expires: April 15, 2006 [Page 10]
Internet Draft MN-MAP Security October 16, 2005
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 (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.
Expires: April 15, 2006 [Page 11]
