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]