Internet Engineering Task Force Wassim Haddad Internet Draft Ericsson Research Canada Expires in October 2004 Helsinki University of Technology Lila Madour Ericsson Research Canada Jari Arkko Ericsson Research Nomadic Lab Francis Dupont GET/ENST Bretagne April 2004 Applying Cryptographically Generated Addresses to OMIPv6 (OMIPv6+) draft-haddad-mip6-cga-omipv6-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 Cryptographically Generated Addresses [CGA] offers a proof of ownership and provides answers to many concerns raised in the past around the "Mobile IPv6" [MIPv6] standard and recently around the "Optimizing MIPv6" [OMIPv6] proposal. This memo describes a method to incorporate and exploit the CGA features in order to add strong security feature to the optimization suggested in the OMIPv6 proposal. Haddad, et al. Expires October 2004 [Page 1] INTERNET-DRAFT Applying CGA to OMIPv6 April 2004 Table of Contents 1. Introduction...............................................2 2. Terminology................................................2 3. Glossary...................................................2 4. Quick Overview of CGA......................................3 5. Quick Overview of OMIPv6...................................4 6. Applying CGA to OMIPv6.....................................5 7. New Options Format.........................................6 7.1 The Home Token Option Format...........................6 7.2 The Care-of Token Option Format........................7 7.3 The Home Nonce Index (HoNI) Option Format..............7 7.4 The Care-of Nonce Index (CoNI) Option Format...........8 7.5 The Shared Secret (S) bit..............................8 8. Security Considerations...................................10 9. Normative References......................................10 10. Informative References...................................10 11. Authors'Addresses........................................11 Intellectual Property and Copyright Statements...............12 1. Introduction The OMIPv6 proposal offers a strong optimization to the MIPv6 standard by narrowing the window of vulnerability to only few seconds and eliminating most of the signaling messages thus substantially reducing the latency. This draft describes a method to incorporate the strong security feature offered by using the CGA to close the window of vulnerability in OMIPv6. The main goals are to offer a simple secure and highly efficient solution for the mobility problem. 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 introduces two new binding acknowledgment messages, as an extension and replacement to the BA message role defined in [MIPv6]. The two messages use the same format defined for the BA message. These messages are: Haddad, et al. Expires October 2004 [Page 2] INTERNET-DRAFT Applying CGA to OMIPv6 April 2004 BAH Binding Acknowledgment related to the mobile node's home address. This message is sent by the CN and uses the MN's IPv6 home address as destination address. BAC Binding Acknowledgment related to the mobile node's new care-of address. This message is sent by the CN and uses the MN's new care-of address as destination address. This draft defines 4 new options to carry the Nonce Indices and the keygen tokens and a new bit. The bit is called the "Shared Secret" (S) bit and will be set by the MN in the BU message only when it needs the CN to create/refresh the Kbm shared secret. 4. Quick overview of the CGA As described in [CGA] and [Aura], a Cryptographically Generated Address (CGA) is an IPv6 address, which contains a set of bits generated by hashing the IPv6 address owner's public key. Such feature allows the user 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 and allows to sign messages with the owner's private key. CGA does not require any upgrade or modification in the infrastructure. The CGA offers a method for binding a public 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. Note that an attacker can always create its own CGA address but he will not be able to spoof someone else's address since he needs to sign the message with the corresponding private key, which is supposed to be known only by the real owner. Each CGA is associated with a public key and auxiliary parameters. For OMIPv6, the key pair SHOULD be an RSA public/private key type ASN.1 RSAPublicKey and RSAPrivateKey. The CGA verification takes as input an IPv6 address and auxiliary parameters. These parameters are the following: - a 128-bit modifier, which can be any value, Haddad, et al. Expires October 2004 [Page 3] INTERNET-DRAFT Applying CGA to OMIPv6 April 2004 - a 64-bit subnet prefix, which is equal to the subnet prefix of the CGA, - an 8-bit collision count, which can have values 0, 1 and 2. If the verification succeeds, the verifier knows that the public key in the CGA parameters is the authentic public key of the address owner. In order to sign a message, a node needs the CGA, the associated CGA parameters, the message and the private cryptographic key that corresponds to the public key in the CGA parameters. The node needs to use a 128 bit type tag for the message from the CGA Message Type name space. The type tag is an IANA-allocated 128 bit integer. To sign a message, a node SHOULD do the following two steps: a) Concatenate the 128 bit type tag (in the network byte order) and message with the type tag to the left and message to the right. The concatenation is the message to be signed in the next step. b) Generate the RSA signature. The inputs to the generation procedure are the private key and the concatenation created in a). 5. Quick Overview of OMIPv6 OMIPv6 describes a method to optimize the MIPv6 protocol by narrowing the window of vulnerability to the minimum and eliminating most of the signaling messages associated to the MIPv6 protocol. The suggested optimization is a direct application of the trade-off described in the Purpose-Built Key Framework [PBK]. The OMIPv6 trade-off assumes that if an RR procedure (e.g. the first RR procedure) is done securely, then we can secure all the rest of the session. By doing that, OMIPv6 eliminates the need for the HoTI/HoT/CoTI/CoT messages. OMIPv6 can use the signaling extension for alternate care-of address support defined in [MIPsec] in order to check the validity of the new MN's care-of address, if/when it is sent in alternate care-of address option and is different from the BU source address and the MN's home address. OMIPv6 uses the result of a specific RR procedure (i.e., the Kbm) to sign the DH messages exchanged between the MN and the CN. The DH procedure will allow the two endpoints to compute a strong shared secret and to use it to sign the BU/BA messages. Haddad, et al. Expires October 2004 [Page 4] INTERNET-DRAFT Applying CGA to OMIPv6 April 2004 6. Applying CGA to OMIPv6 The main goal of this proposal is to exploit the CGA features in order to make the OMIPv6 proposal more secure and optimized. For this purpose, this memo suggests dropping entirely the RR procedure. This proposal assumes that the MN has at least its IPv6 home address based on CGA. Incorporating CGA in OMIPv6 consists on signing the very first binding update (BU) message sent by the MN, with the private key corresponding to the key pair in the CGA parameters and sending the public key to the CN in an IPv6 destination header option. The BU message is sent on the direct path. The MN MUST set the (S) bit in this BU message. Upon receiving a BU message signed with the private key corresponding to the MN's key pair and with the (S) bit set, the CN MUST reply by sending two Binding Acknowledgments (BA) messages, i.e., the BAH and BAC messages. The CN MUST use the new care-of address sent in the BU message as the IPv6 destination address of the BAC message. Note that the CN will send the two messages ONLY after a successful verification of the address owner's public key and the signature in the BU message. The two BA messages MUST have the same sequence number and MUST contain parts of the binding management key (Kbm). For this purpose, the BAH message will carry the home keygen token in a new option, defined in 7.1, and the BAC message will carry the care-of keygen token in another new option defined in 7.2. The CN MUST also send the home nonce index (HoNI) in the BAH message and the care-of nonce index (CoNI) in the BAC message. The two nonces will be carried by two new options in 7.3 and 7.4. The CN MUST sign the two BA messages with the MN's public key except for the token field in the token options, which MUST be encrypted. Encrypting the keygen tokens is as per password encryption as defined in [RAD], section 3.5. Note that the MN MUST include the two nonce indices in all BU messages sent after receiving the BAC and BAH messages. After receiving the two BA messages, the MN will establish a bidirectional security association (SA) with the CN and both nodes will use ONLY the Kbm to sign all subsequent BU/BA messages. Note that after computing the Kbm, the CN SHOULD reply to any BU message sent with the acknowledgment (A) bit set, by sending only a BAC message. Both nodes MUST silently drop any signaling messages sent and/or received, to/from any of them and not signed with the Kbm and MUST use the sequence number in the BU/BA messages. Haddad, et al. Expires October 2004 [Page 5] INTERNET-DRAFT Applying CGA to OMIPv6 April 2004 One main advantage offered by OMIPv6+ is the extension of the lifetime of the BCE. Such longer lifetime substantially reduces the frequency of re-keying. Note that when re-keying is needed, the MN MUST send a BU message signed ONLY with its private key and MUST set the (S) bit. After receiving such BU message, the CN MUST reply by sending the two tokens in the BAH and BAC messages. Note that the CN MUST perform a care-of address test each time it receives a BU message, which carries an alternate care-of address different from the BU source address and from the MN's home address. As it has been mentioned above, the care-of address test can be done by using a signaling extension described in [MIPsec]. 7. New Options Format 7.1 The Home Token Option Format As it has been mentioned above, the CN MUST send a BAH message each time it receives a BU message signed with the MN's private key and with the (S) bit set. The BAH message MUST carry the home keygen token. For this purpose, this proposal uses a new option called "home token" option, which MUST be inserted in the BAH message when it is used. The format of the new option 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type | Option Length | Home Token +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Option Type TBD Option Length Length of the option = 8 Option Data This field contains the home keygen token. Note that the content of this field MUST be encrypted with the MN's public key. Haddad, et al. Expires October 2004 [Page 6] INTERNET-DRAFT Applying CGA to OMIPv6 April 2004 7.2 The Care-of Token Option Format When the CN has to create/refresh the Kbm shared secret, it MUST send a BAC message, which MUST carry the care-of keygen token. For this purpose, this proposal uses a new option called "care-of token" option, which MUST be inserted in the BAC message when it is used. The format of the new option 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type | Option Length | Care-of Token +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Option Type TBD Option Length Length of the option = 8 Option Data This field contains the care-of keygen token. Note that the content of this field MUST be encrypted with the MN's public key. 7.3 The Home Nonce Index (HoNI) Option Format This option MUST be inserted in the BAH message sent by the CN to the MN after receiving a BU message signed with the MN's corresponding private key and with the bit (S) set. The format of this option 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type | Option Length | HoNI +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Haddad, et al. Expires October 2004 [Page 7] INTERNET-DRAFT Applying CGA to OMIPv6 April 2004 Option Type TBD Option Length Length of the option = 2 Option Data This value will be echoed back by the MN to the CN in all subsequent BU messages. 7.4 The Care-of Nonce Index (CoNI) Option Format This option MUST be inserted in the BAC message sent by the CN to the MN after receiving a BU message signed with the MN's corresponding private key and with the bit (S) set. The format of this option 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type | Option Length | CoNI +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Option Type TBD Option Length Length of the option = 2 Option Data This value will be echoed back by the MN to the CN in all subsequent BU messages. 7.5 The Shared Secret (S) bit As it has been mentioned, a new bit is defined in the binding update message. This bit, called the shared secret (S) bit, MUST be set by the MN ONLY when it needs to ask the CN to create/refresh the Kbm. In both cases, setting the S bit will trigger the CN to reply to the BU message with the two BA Haddad, et al. Expires October 2004 [Page 8] INTERNET-DRAFT Applying CGA to OMIPv6 April 2004 messages carrying the components of a new Kbm shared secret. The format of the BU message with the new bit is as follows: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence # | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A|H|L|K|S| Reserved | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Haddad, et al. Expires October 2004 [Page 9] INTERNET-DRAFT Applying CGA to OMIPv6 April 2004 8. Security Considerations This draft describes a method to exploit the CGA features in order to authenticate the BU message. In fact, the CGA replaces the authentication by providing a proof of ownership while the RR procedure replaces the authentication by a routing property. However, it should be mentioned that while the CGA can provide a protection against unauthenticated BUs, it can expose the involved nodes to DoS attacks since it is computationally expensive. The draft limits the use of CGA to only the first BU and when re-keying is needed. Note that, as it has been mentioned, a main advantage in OMIPv6+ is that it allows a longer lifetime for the BCE, thus substantially reducing the frequency of re-keying. 9. Normative References [MIPv6] D. Johnson, C. Perkins, J. Arkko, "Mobility Support in IPv6", draft-ietf-mobileip-ipv6-24.txt, June 2003. [RAD] Zorn, G., et al. "RADIUS Attributes for Tunnel Protocol Support", RFC 2868, June 2000. [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. [CGA] Aura, T. "Cryptographically Generated Address (CGA)", draft-ietf-send-cga-05, February 2004. [MIPsec] Dupont, F., Combes, J.M., "Using IPsec between Mobile and Correspondent IPv6 Nodes", draft-dupont-mipv6-cn-ipsec-00, April 2004. [OMIPv6] Haddad, W., Dupont, F., Madour, L., Krishnan, S., Park, SD, "Optimizing Mobile IPv6 (OMIPv6)", draft-haddad-mipv6-omipv6-01, February 2004. [PBK] Bradner, S., Mankin, A., Schiller, J., "A Framework for Purpose-Built Key", draft-bradner-pbk-frame-06, June 2003. Haddad, et al. Expires October 2004 [Page 10] INTERNET-DRAFT Applying CGA to OMIPv6 April 2004 11. Author's 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 11] INTERNET-DRAFT Applying CGA to OMIPv6 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 12] INTERNET-DRAFT Applying CGA to OMIPv6 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 13]