Internet Engineering Task Force Wassim Haddad
Internet Draft Lila Madour
Expires in October 2004 Jari Arkko
Ericsson Research
Francis Dupont
GET/ENST Bretagne
April 2004
Applying Cryptographically Generated Addresses to BUB (BUB+)
draft-haddad-mip6-cga-bub-00
Status of this Memo
This document is an Internet Draft and is in full conformance with
all provisions of Section 10 of RFC 2026.
This document is an Internet-Draft. 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.
Distribution of this memo is unlimited.
Abstract
This memo describes a method to exploit the Cryptographically
Generated Address (CGA) features in highly mobile environment.
The draft introduces a new optimization to the "Binding Update
Backhauling (BUB)" proposal, which eliminates the need for
running a return routability (RR) procedure at the beginning
and improves its security.
Haddad, et al. Expires October 2004 [Page 1]
INTERNET-DRAFT Applying CGA to BUB (BUB+) April 2004
1. Introduction
The Binding Update Backhauling [BUB] proposal is a new mode,
which has been designed to address scenarios involving two
mobile endpoints. BUB offers a highly efficient solution, and
substantially reduces the amount of signaling messages.
This draft describes a method, which incorporates the security
features provided by the CGA in the BUB mode. The suggested
solution adopts the same procedure described in [OMIPv6+].
2. Terminology
The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", "MAY"
in this document are to be interpreted as described in RFC 2219
[TERM].
3. Glossary
This draft uses the Key option, the Timestamp (TiST) option,
the Key Nonce Index (KeNI) option and the Shared Secret (S) bit
defined [OMIPv6+]. In addition, this draft defines a new bit
called the BUB (B) bit, which will be used in the BU and BA
messages to test the other endpoint's willingness to switch to
the BUB mode.
4. Quick Overview of CGA
As described in [CGA] and [Aura], a Cryptographically Generated
Address (CGA) is an IPv6 address in which the interface
identifier is generated from hashing the address owner's public
key. The address owner can then use the corresponding private
key to provide a "proof of ownership" of its IPv6 address.
The CGA offers three main advantages: it makes the spoofing
attack against the IPv6 address much harder, allows to sign
messages with the owner's private key and does not require any
additional security infrastructure.
The CGA offers a method for binding a public signature key to an
IPv6 address. The binding between the public key and the address
can be verified by re-computing and comparing the hash value of
the public key and other parameters sent in the specific message
with the interface identifier in the IPv6 address belonging to
the owner. If the verification succeeds, the verifier knows that
the public key in the CGA parameters is the authentic public key
of the address owner. Note that an attacker can always create
its own CGA address but he won't be able to spoof someone else's
Haddad, et al. Expires October 2004 [Page 2]
INTERNET-DRAFT Applying CGA to BUB (BUB+) April 2004
CGA address since he needs to sign the message with the
corresponding private key, which is supposed to be known only
by the real owner.
5. Quick Overview of BUB
BUB is a new mode, which has been especially designed to deal
with scenarios involving two mobile endpoints. For this purpose,
BUB uses the RR procedure defined in [MIPv6] to allow one MN to
check the willingness of the other mobile node about switching
to the BUB mode (i.e., defined as BUB procedure). After a
successful BUB procedure, the two MNs compute a strong shared
secret by running a Diffie-Hellman (DH) exchange. The shared
secret is then used it to sign subsequent binding updates (BU)
and binding acknowledgments (BA) messages.
After computing a shared secret, the RR procedure is eliminated
and the two MNs exchange only BU/BA messages when switching to
new links.
6. Applying CGA to BUB
This memo assumes that the two MNs use CGAs as their home
addresses. By providing a proof of ownership, incorporating CGA
in the BUB mode (i.e., BUB+), allows signing the BU messages
carrying the BUB test and the BA messages carrying the shared
secret with the MN's private keys. As a result, return
routability tests associated with the home address can be
eliminated during the initialization phase of BUB+.
In BUB+, the two MNs MUST sign with their private keys, any BU
message sent with the bit "S" set, in order to create/refresh
the shared secret. For this purpose, a MN SHOULD launch a BUB
test in the first BU message sent to the other MN. In BUB+,
launching a BUB test consists on setting the BUB "B" bit in the
BU message. In response to a BUB test, the receiver MUST set the
"B" bit in the BA message ONLY if it is willing to switch to
the BUB mode. Otherwise, the bit MUST always be cleared.
In the following, MN1 is using its first BU message to run a
BUB test in parallel with sending a request to MN2 to send a
new Kbm:
MN1 sends the first BU message to MN2's home address. The BU
message SHOULD go through MN2's HA and SHOULD use the new MN1's
CoA as its IPv6 source address. As it has been described in
[OMIPv6+], MN1 MUST insert in the first BU message a Timestamp
(TiST) option and set the "S" bit and sign the message with its
private key. In addition, MN1 MUST set the "B" bit. Note that
Haddad, et al. Expires October 2004 [Page 3]
INTERNET-DRAFT Applying CGA to BUB (BUB+) April 2004
MN1 SHOULD also send its public key in the first BU message.
When MN2 receives such BU message, it MUST reply by sending a
BA message on the direct path between the two MNs. If MN2 is
willing to switch to the BUB mode, then, in addition to sending
a shared secret and a Key Nonce Index (KeNI), it MUST set the
"B" bit in the BA message and send its public key. In BUB+, MN2
MUST sign the BA message carrying a shared secret with its CGA
private key and MUST encrypt the key field in the key option
with MN1's public key as described in [OMIPv6+].
After receiving a BA message from MN2 with the "B" bit set, both
nodes will start using the path going through the two HAs as the
main path to exchange the BU messages. However, BUB+ recommends
that both nodes duplicates their BU messages and send another
copy on the direct path in order to reduce the latency. Note
that when duplicating the BU messages, both messages MUST carry
the same sequence number. The BA messages SHOULD be exchanged
only on the direct path.
If MN2 is not willing to switch to the BUB mode, it MUST clear
the "B" bit in the BA and proceed in the same way as described
in [OMIPv6+]. Note that in such scenario, MN2 MUST use its
private key to sign the BA message carrying a new shared secret.
A particular case arises when the two MNs exchange BU messages
with the bit "S" set, at the same time. In such scenario, the
two MNs' home IPv6 addresses SHOULD be compared by each MN, and
only the owner of the lower address MUST create the Kbm and send
it to the other endpoint.
7. The BUB (B) bit
BUB+ introduces a new bit called the BUB (B) bit in the BU/BA
messages, which replaces the BUB procedure used in [BUB]. This
bit MUST be set only to ask the receiver about switching to the
BUB mode. Otherwise, the "B" bit MUST always be cleared.
The format of the BU message with the new bit is as follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|H|L|K|S|B| Reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility options .
Haddad, et al. Expires October 2004 [Page 4]
INTERNET-DRAFT Applying CGA to BUB (BUB+) April 2004
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
If the sender of the BA message is willing to switch to the BUB
mode, then it MUST set the "B" bit in the BA message. Otherwise,
the "B" bit MUST always be cleared.
The format of the BA message with the new bit is as follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status |K|B| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8. Security Considerations
This memo explains how to use CGA in order to switch to the BUB
mode. When both endpoints are mobile, it is recommended that
both MNs agree on switching to the BUB mode after the first BUB
test.
Haddad, et al. Expires October 2004 [Page 5]
INTERNET-DRAFT Applying CGA to BUB (BUB+) April 2004
9. Normative References
[MIPv6] D. Johnson, C. Perkins, J. Arkko, "Mobility Support in
IPv6", draft-ietf-mobileip-ipv6-24.txt, June 2003.
[TERM] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119.
10. Informative References
[Aura] Aura, T. "Cryptographically Generated Address (CGA)",
6th Information Security Conference (ISC'03), Bristol,
UK, October 2003.
[BUB] Haddad, W., Dupont, F., Kavanagh, A., Krishnan, S.,
Madour, L., Park, SD., "Binding Update Backhauling",
draft-haddad-mipv6-bub-01, Februray 2004.
[CGA] Aura, T. "Cryptographically Generated Address (CGA)",
draft-ietf-send-cga-06, April, 2004.
[OMIPv6+] Haddad, W., Arkko, J., Dupont, F., "Applying
Cryptographically Generated Address (CGA) to OMIPv6",
draft-haddad-mipv6-cga-omipv6-01, May 2004.
Haddad, et al. Expires October 2004 [Page 6]
INTERNET-DRAFT Applying CGA to BUB (BUB+) April 2004
11. Authors' Addresses
Wassim Haddad
Ericsson Research Canada
8400, Decarie Blvd
Town of Mount Royal
Quebec H4P 2N2
Canada
Tel: +1 514 345 7900
Fax: +1 514 345 6105
E-mail: Wassim.Haddad@ericsson.com
Lila Madour
Ericsson Research Canada
8400, Decarie Blvd
Town of Mount Royal
Quebec H4P 2N2
CANADA
Phone: +1 514 345 7900
Fax: +1 514 345 6195
E-Mail: Lila.Madour@ericsson.com
Jari Arkko
Ericsson Research Nomadic Laboratory
Jorvas 02420
Finland
E-mail: Jari.Arkko@ericsson.com
Francis Dupont
ENST Bretagne
Campus de Rennes
2, rue de la Chataigneraie
CS 17607
35576 Cesson-Sevigne Cedex
FRANCE
Fax: +33 2 99 12 70 30
E-mail: Francis.Dupont@enst-bretagne.fr
Haddad, et al. Expires October 2004 [Page 7]
INTERNET-DRAFT Applying CGA to BUB (BUB+) April 2004
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of
any intellectual property 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; neither does
it represent that it has made any effort to identify any such
rights. Information on the IETF's procedures with respect to
rights in standards-track and standards-related documentation
can be found in BCP-11. Copies of claims of rights made
available for publication 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 implementors or users of this specification can be
obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention
any copyrights, patents or patent applications, or other
proprietary rights which may cover technology that may be
required to practice this standard. Please address the
information to the IETF Executive Director.
The IETF has been notified of intellectual property rights
claimed in regard to some or all of the specification contained
in this document. For more information consult the online list
of claimed rights.
Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished
to others, and derivative works that comment on or otherwise
explain it or assist in its implementation may be prepared,
copied, published and distributed, in whole or in part, without
restriction of any kind, provided that the above copyright
notice and this paragraph are included on all such copies and
derivative works. However, this document itself may not be
modified in any way, such as by removing the copyright notice or
references to the Internet Society or other Internet
organizations, except as needed for the purpose of developing
Internet standards in which case the procedures for copyrights
defined in the Internet Standards process must be followed, or
as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not
be revoked by the Internet Society or its successors or
assignees.
This document and the information contained herein is provided
on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
Haddad, et al. Expires October 2004 [Page 8]
INTERNET-DRAFT Applying CGA to BUB (BUB+) April 2004
ENGINEERING TASK FORCE DISCLAIMS 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.
Haddad, et al. Expires October 2004 [Page 9]