One document matched: draft-haddad-mipshop-hmipv6-security-01.txt
Differences from draft-haddad-mipshop-hmipv6-security-00.txt
MIPSHOP Working Group W. Haddad
Internet-Draft S. Krishnan
Expires: April 26, 2006 Ericsson Research
October 23, 2005
Combining Cryptographically Generated Address and Crypto-Based
Identifiers to Secure HMIPv6
draft-haddad-mipshop-hmipv6-security-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 April 26, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This memo describes a method for establishing a security association
between the mobile node and the selected mobility anchor point in an
hierarchical mobile IPv6 domain. The suggested solution is based on
combining the cryptographically generated address (CGA) and crypto-
based identifiers (CBID) technologies.
Haddad & Krishnan Expires April 26, 2006 [Page 1]
Internet-Draft HMIPv6sec October 2005
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions used in this document . . . . . . . . . . . . . . 4
3. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Proposed Solution . . . . . . . . . . . . . . . . . . . . . . 7
5. New Messages and Options Format . . . . . . . . . . . . . . . 9
5.1. The Pre-Binding Update (PBU) Message Format . . . . . . . 9
5.2. Third Party Shared Key (TPSK) Option . . . . . . . . . . . 10
5.3. The Cypto Identifier Option (CIO) . . . . . . . . . . . . 11
5.4. The MAP Shared Secret (MSS) Option . . . . . . . . . . . . 11
5.5. Third Party Hash Secret (TPHS) Option . . . . . . . . . . 12
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 14
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
8.1. Normative References . . . . . . . . . . . . . . . . . . . 15
8.2. Informative References . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
Intellectual Property and Copyright Statements . . . . . . . . . . 17
Haddad & Krishnan Expires April 26, 2006 [Page 2]
Internet-Draft HMIPv6sec October 2005
1. Introduction
The Hirarchical Mobile IPv6 Mobility Management [HMIPv6] did not
specify nor favor any particular mechanism for establishing a
Security Association (SA) between the Mobile Node (MN) and the
Mobility Anchor Point (MAP) located within an HMIPv6 domain.
This memo describes a method allowing to establish an SA between the
MN and the selected MAP. The suggested solution is based on
combining the Cyptographically Generated Addresses [CGA] and Crypto-
Based Identifiers [CBID].
Haddad & Krishnan Expires April 26, 2006 [Page 3]
Internet-Draft HMIPv6sec October 2005
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 [TERM].
Haddad & Krishnan Expires April 26, 2006 [Page 4]
Internet-Draft HMIPv6sec October 2005
3. Glossary
Access Router
The Access Router is the Mobile Node's default router. The AR
aggregates the outband traffic of mobile nodes.
Mobility Anchor Point (MAP)
A Mobility Anchor Point is a router located in a network visited by
the mobile node, which is used by the MN as a local Home Agent (HA).
Regional Care-of Address (RCoA)
A Regional Care-of Address is an address obtained by the MN from the
visited network. An RCoA is an address on the MAP's subnet and is
auto-configured by the MN when receiving the MAP option.
On-link Care-of Address (LCoA)
The LCoA is the on-link CoA configured on a mobile node's interface
based on the prefix advertised by its default router.
Local Binding Update (LBU) Message
The MN sends a Local Binding Update message to the MAP in order to
establish a binding between the RCoA and the LCoA.
Pre-Binding Update (PBU) Message
The MN's default router sends a Pre-Binding Update message to the MAP
upon receiving a Router Solicitation (RtSol) message carrying a 128-
bit CBID and a valid CGA signature.
Cryptographically Generated Address (CGA)
A technique described in [CGA] whereby an IPv6 address of a node is
cryptographically generated by using a one-way hash function from the
node's public key and some other parameters.
Crypto-Based Identifier (CBID)
A technique described in [CBID] whereby a non-routable identifier is
cryptographically generated by using a one-way hash function from the
node's public key and an imprint.
Pre-Binding Update (PBU) Message
Haddad & Krishnan Expires April 26, 2006 [Page 5]
Internet-Draft HMIPv6sec October 2005
The MN's default router sends a Pre-Binding Update message to the MAP
upon receiving a Router Solicitation (RtSol) message carrying a 128-
bit CBID and a valid CGA signature.
Binding Acknowledgment (BA) Message
The MAP sends a binding acknowledgment message to the MN in response
to an LBU message.
Haddad & Krishnan Expires April 26, 2006 [Page 6]
Internet-Draft HMIPv6sec October 2005
4. Proposed Solution
We assume that the MN's LCoA is always computed based on the CGA
technology, in order to allow the MN to run the secure neighbor
discovery procedure described in [SEND]. Such assumption has also
been made in [FMIPsec], to provide a security mechanism for the
[FMIPv6] proposal.
In addition, we assume that the MN can discover the presence of an
HMIPv6 domain before sending a RtSol message. However, it should be
noted that the proposed solution works without such assumption. In
fact, our assumption is based on using technologies described in
[FRD], which aim above all to reduce the handoff latency.
Based on that, we suppose in the following that an FRD technology is
implemented in all Access Points (APs).
The suggested solution introduces a new signaling message, i.e., the
Pre-Binding Update (PBU) message, which is sent by the AR to the MAP
upon receiving a RtSol message from the MN carrying a valid signature
(i.e., the message is signed with the MN's CGA private key) and a
128-bit CBID.
Note that the Crypto-based ID (CBID) is used to provide the MAP
sufficient proof of ownership of the MN's suggested RCoA.
The following figure shows the signaling diagram for establishing a
bidirectional SA between the MN and the MAP:
1. MN to AR: Router Solicitation [CGA Signature + CBID] (RtSol)
2a. AR to MN: Router Acknowledgement [Ks] (RtAdv)
2b. AR to MAP: Pre-Binding Update [Ks] (PBU)
3. MN to MAP: Local Binding Update (LBU)
4. MAP to MN: Binding Acknowledgement [Km + HKs] (BA)
The suggested solution is described in the following steps:
o When the MN discovers that it has entered an HMIPv6 domain, it
computes an LCoA address by using its CGA key pair, and a 128-bit
CBID by hashing the CGA public key together with a 64-bit imprint.
o The MN inserts the CBID in the RtSol message, then signs the
message as described in SEND and sends it to the AR.
o Upon receiving a valid RtSol message carrying a CBID, the AR
replies immediately by sending a unicast RtAdv message to the MN
and in parallel, a PBT message to the MAP. For this purpose, the
AR MUST compute a secret (Ks), encrypts it with the MN's CGA
public key and sends it in the RtAdv message.
The AR MUST send Ks to the MAP in the PBT message, in addition to
Haddad & Krishnan Expires April 26, 2006 [Page 7]
Internet-Draft HMIPv6sec October 2005
the MN's CGA public key, its LCoA and CBID. Note that it is
assumed that the PBT messages are signed by the ARs and the paths
between the ARs and the MAP are secure.
o After receiving the PBT message, the MAP creates a BCE for the MN,
in which it stores the LCoA, Ks and the CGA public key carried by
the PBT message. Once the BCE is created, the MAP waits for a
limited amount of time for the owner of the LCoA to send the LBU
message.
o When the MN gets a valid RtAdv message, it configures its RCoA by
using as interface identifier (IID), the 64-bit imprint, which has
been used to generate the CBID. Then, it sends an LBU message to
request the MAP to bind its LCoA to its new RCoA.
o Upon receiving an LBU message, the MAP searches its BCEs table for
an LCoA, which matches the one sent in the LBU message. If the
same LCoA is found, then the MAP hashes the RCoA IID, i.e., the
imprint, with the stored CGA public key and compares it to the
CBID. If the two hash values are the same, then the MAP generates
a long term shared secret, Km, encrypts it with Ks and sends it to
the MN in the BA message. The length for the Km SHOULD be no less
than 160 bits. In addition, the MAP MUST insert in the BA message
the hash of Ks (i.e., hash(Ks) = HKs).
However, if the two hash values are not equal then the MAP simply
discards the LBU message.
o When the MN gets a BA message, it searches first if it carries
HKs. If the correct HKs is found, then the MN decrypts the shared
secret with Ks, and establishes a bidirectional security
association (SA) with the MAP.
o Finally, both nodes MUST use Ks to authenticate all subsequent
LBU/BA messages exchanged between them.
Note that the SA lifetime is set to 24 hours, after which the MN has
to request the MAP to renew it.
Haddad & Krishnan Expires April 26, 2006 [Page 8]
Internet-Draft HMIPv6sec October 2005
5. New Messages and Options Format
In the following, we describe the PBU message structure and the
format of the four new options.
5.1. The Pre-Binding Update (PBU) Message Format
When the AR receives a RtSol message carrying a valid RSA signature
and a CBID, it sends a PBU message to the MAP, which carries the MN's
LCoA, CGA public key, CBID and Ks.
The format of the PBU message is 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ LCoA +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ CBID +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. Ks .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. CGA Public Key (Kp) .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
<To Be Assigned By IANA>
Haddad & Krishnan Expires April 26, 2006 [Page 9]
Internet-Draft HMIPv6sec October 2005
Code 0
Checksum
The ICMP checksum. For more details see [ICMPv6].
Reserved
This field is unused. It MUST be initialized to zero by the sender
and MUST be ignored by the receiver.
LCoA
This field contains the MN's LCoA.
CBID
This field contains the MN's 128-bit CBID.
Ks
The shared secret sent by the AR to the MN and to the MAP
Kp
The CGA public key
5.2. Third Party Shared Key (TPSK) Option
The Third Party Shared Key Option is carried by the unicast RtAdv
message sent by the AR to the MN, in response to a RtSol message
carrying a valid signature and a CBID. The TPSK option MUST carry
the shared secret Ks.
When used, the TPSK option has the following format:
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 | Option Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. Option Data = Ks .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option Type
<To Be Assigned By IANA>
Option Length
Length of the option.
Haddad & Krishnan Expires April 26, 2006 [Page 10]
Internet-Draft HMIPv6sec October 2005
Option Data
This field contains the shared secret Ks.
5.3. The Cypto Identifier Option (CIO)
The CIO option contains the 128-bit CBID. It is carried by the RtSol
message sent by the MN to the AR and signed with the CGA private key.
As mentioned above, a RtSol message carrying a 128-bit CBID and a
valid RSA signature triggers the AR to generate a shared secret Ks
and send it to the MN and the MAP.
When used, the CIO has the following format:
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 | Option Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Option Data = CBID +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option Type
<To Be Assigned By IANA>
Option Length
Length of the option: 16 octets
Option Data
This field contains the 128-bit CBID sent by the MN to the AR.
5.4. The MAP Shared Secret (MSS) Option
The MSS Option is used by the MAP to carry the shared secret Kp sent
in the BA message, in response to the first LBU message. The Ks MUST
be used to authenticate all subsequent BU/BA messages exchanged
between the MN and the MAP.
The MSS option has the following format:
Haddad & Krishnan Expires April 26, 2006 [Page 11]
Internet-Draft HMIPv6sec October 2005
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 | Option Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. Option Data = Kp .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option Type
<To Be Assigned By IANA>
Option Length
Length of the option.
Option Data
The Option Data field contains the MAP shared secret Kp. Note that
this field MUST be encrypte with Ks.
5.5. Third Party Hash Secret (TPHS) Option
When sending a BA message carrying an MSS option, the MAP MUST insert
the hash of Ks (HKs) in the BA message. For this purpose, the TPHS
option is used to carry the HKs in the BA message.
The TPHS option has the following format:
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 | Option Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. Option Data = HKs .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option Type
<To Be Assigned By IANA>
Option Length
Length of the option.
Option Data
The Option Data field contains the hash of Ks.
Haddad & Krishnan Expires April 26, 2006 [Page 12]
Internet-Draft HMIPv6sec October 2005
6. IANA Considerations
This document introduces 4 new types of options and one new type of
message. The values of these types are 8-bit unsigned integers.
These values are allocated according to the Standards Actions or IESG
approval policies defined in [IANA].
Haddad & Krishnan Expires April 26, 2006 [Page 13]
Internet-Draft HMIPv6sec October 2005
7. Security Considerations
This proposal suggests using the CBID and CGA technologies in order
to avoid increasing the number of messages that need to be signed
with an RSA key beyond the SEND procedure. This is recommended due
to the fact that public key signature is a computationally expensive
and lengthy procedure.
The suggested proposal does not create nor enhance any new and/or
existing threats. In particular, launching a man-in the middle
attack against the MN is not possible because the attacker is not
aware of the shared secret Ks. In addition, launching a denial of
service attack against the MAP or the MN is not easy due to the fact
that both nodes can scan incoming messages for a partial authenticity
before validating the authenticity and (for the MN) decrypting the
shared secret.
Haddad & Krishnan Expires April 26, 2006 [Page 14]
Internet-Draft HMIPv6sec October 2005
8. References
8.1. Normative References
[CGA] Aura, T., "Cryptographically Generated Addresses (CGA)",
RFC 3792, March 2005.
[HMIPv6] Soliman, H., Castelluccia, C., El Malki, K., and L.
Bellier, "Hierarchical Mobile IPv6 (HMIPv6)", RFC 4140,
August 2005.
[IANA] Narten, T. and H. Alverstrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", RFC 2434, BCP 26,
October 1998.
[ICMPv6] Conta, A. and S. Deering, "Internet Control Message
Protocol (ICMPv6) for the Internet Protocol version 6
(IPv6) Specification", RFC 2463, July 2005.
[SEND] Arkko, J., Kempf, J., Nikander, P., and B. Zill, "Secure
Neighbor Discovery (SEND)", RFC 3971, March 2005.
[TERM] Bradner, S., "Key Words for Use in RFCs to Indicate
Requirement Levels", RFC 2119, BCP , March 1997.
8.2. Informative References
[CBID] Montenegro, G. and C. Castelluccia, "Crypto-Based
Identifiers (CBID): Concepts and Applications", ACM
Transaction on Information and System Security (TISSEC),
February 2004.
[FMIPsec] Kempf, J. and R. Koodli, "Bootstrapping a Symmetric IPv6
Key Handover Key from SEND", Internet
Draft, draft-kempf-mobopts-handover-key-01.txt, July 2005.
[FMIPv6] Koodli, R., "Fast Handovers for Mobile IPv6", Internet
Draft, draft-koodli-mipshop-rfc4068bis-00.txt, July 2005.
[FRD] Choi, J., Chin, D., and W. Haddad, "Fast Router Discovery
with L2 Support", Internet
Draft, draft-ietf-dna-frd-00.txt, October 2005.
Haddad & Krishnan Expires April 26, 2006 [Page 15]
Internet-Draft HMIPv6sec October 2005
Authors' Addresses
Wassim Haddad
Ericsson Research
8400 Decarie Blvd.
Town of Mount Royal, QC
Canada
Phone: +1 514 345 7900 #2334
Email: Wassim.Haddad@ericsson.com
Suresh Krishnan
Ericsson Research
8400 Decarie Blvd.
Town of Mount Royal, QC
Canada
Phone: +1 514 345 7900
Email: Suresh.Krishnan@ericsson.com
Haddad & Krishnan Expires April 26, 2006 [Page 16]
Internet-Draft HMIPv6sec October 2005
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 (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.
Haddad & Krishnan Expires April 26, 2006 [Page 17]
| PAFTECH AB 2003-2026 | 2026-04-24 03:19:34 |