Internet Engineering Task Force Wassim Haddad Internet Draft Lila Madour Expires in November 2004 Jari Arkko Ericsson Research Francis Dupont GET/ENST Bretagne May 2004 Applying Cryptographically Generated Addresses to OMIPv6 (OMIPv6+) draft-haddad-mip6-cga-omipv6-01 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 suggests a new and enhanced route optimization security mechanism, CGA-OMIPv6 (OMIPv6+), for Mobile IPv6 (MIPv6). The primary motivations for OMIPv6+ are the reduction of signaling load, handoff delay and enabling semi-long term security associations. Haddad, et al. Expires November 2004 [Page 1] INTERNET-DRAFT Applying CGA to OMIPv6 May 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. Description of CGA-OMIPv6 (OMIPv6+)........................4 7. New Options Format.........................................7 7.1 The Key Option Format..................................7 7.2 The Key Nonce Index (KeNI) Option Format...............8 7.3 The Timestamp (TiST) Option Format.....................9 7.4 The BU Signature (BUS) Option Format..................10 7.5 The Shared Secret (S) bit.............................10 8. IANA Considerations.......................................11 9. Security Considerations...................................12 10. Normative References.....................................12 11. Informative References...................................13 12. Authors'Addresses........................................13 Intellectual Property........................................14 Full Copyright Statements....................................15 1. Introduction This memo describes a method to incorporate the CGAs described in [CGA] and [Aura] in the OMIPv6 [OMIPv6] proposal. OMIPv6+ suggests a new and enhanced route optimization (RO) security mechanism for MIPv6 [MIPv6]. The main goals for OMIPv6+, when compared to MIPv6 are a substantial reduction of the signaling load, the handoff delay times and enabling semi-long term security associations. OMIPv6+ improves also the security in MIPv6 and the previously defined OMIPv6 by closing the window of vulnerabilities in both protocols. 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 defines 4 new options to enable a secure exchange of the Binding Management Key (Kbm). These options are: Haddad, et al. Expires November 2004 [Page 2] INTERNET-DRAFT Applying CGA to OMIPv6 May 2004 the Key option, the Key Nonce Index (KeNI) option, the Timestamp (TiST) option and the BU Signature (BUS) option. The draft defines also a new bit called the "Shared Secret" (S) bit, which will be set by the MN in the BU message when it needs the CN to create or refresh the 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 public key MUST be formatted as a DER-encoded [ITU.X690.2002] ASN.1 structure of the type SubjectPublicKeyInfo defined in the Internet X.509 certificate profile [PKIC]. 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, - 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 Haddad, et al. Expires November 2004 [Page 3] INTERNET-DRAFT Applying CGA to OMIPv6 May 2004 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 performs 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 [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 a Return Routability (RR) procedure (e.g. the first one), defined in [MIPv6], is done securely, then we can secure all the rest of the session and, at the same time, eliminates the need for the HoTI/HoT/CoTI/CoT messages in the ongoing session. 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 allows the two endpoints to compute a strong shared secret and to use it to sign the BU/BA messages. 6. Description of CGA-OMIPv6 (OMIPv6+) The main goal of this proposal is to exploit the CGA features in order to improve the security and the suggested optimization in the OMIPv6 proposal, which in turn is based on the MIPv6 protocol. 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 using the first BU message sent by the MN on the direct path, to ask the CN to create and return a shared secret, i.e., the Kbm. Haddad, et al. Expires November 2004 [Page 4] INTERNET-DRAFT Applying CGA to OMIPv6 May 2004 For this purpose, the MN MUST send in the first BU message a timestamp (defined in 7.3), set the "S" bit (defined in 7.5) and sign the message with the private key corresponding to its key pair in the CGA parameters (defined in 7.4). Note that the MN's public key SHOULD be sent to the CN in an IPv6 destination header option. Rules for signing the BU message with the MN's private key are the following: Mobility Data = care-of address | correspondent | MH Data Signature = ENCRYPT( SHA1 (Mobility Data))) Where | denotes concatenation and "correspondent" is the CN's IPv6 address. Note that in case the CN is mobile, correspondent refers to the CN's home address. MH Data is the content of the mobility message without including the MH header. The RSA signature is generated by using the RSASSA-PKCS1-v1_5 [PKCS] signature algorithm with the SHA-1 hash algorithm. Note that the CN MUST reject any BU message carrying a home address (i.e., CGA) not included in its destination cache entry. Upon receiving the BU message, the CN MUST reply by sending a Binding Acknowledgment (BA) message, which MUST contain a Kbm inserted in the Key option (defined in 7.1) and a Key Nonce Index (KeNI) (defined in 7.2), which MUST be returned by the MN in all subsequent BU messages. The CN MUST use the new care-of address sent in the BU message as the IPv6 destination address of the BA message. Note that the CN will send the BA message ONLY after a successful verification of the address owner's public key and the signature in the BU message. The CN SHOULD use the timestamp sent in the BU message to prevent against replay attacks using the first BU message. The CN MUST authenticate the BA message with the Kbm and MUST encrypt the Kbm field in the Key token option with the MN's public key. Rules for authenticating the BA message are the following: Mobility Data = care-of address | correspondent | MH Data Authenticator = First (96, HMAC_SHA1 (Kbm, Mobility Data)) where | denotes concatenation and "correspondent" is the CN's IPv6 address. Haddad, et al. Expires November 2004 [Page 5] INTERNET-DRAFT Applying CGA to OMIPv6 May 2004 "MH Data" is the content of the Mobility Header excluding the authenticator itself. The Authenticator value is calculated as if the Checksum field in the Mobility Header was zero. Encrypting the Kbm is as per password encryption as defined in [RAD], section 3.5. Note that the CN MUST encrypt the Kbm and then authenticate the MH data with the shared secret. After receiving the BA message, the MN sets up a bidirectional security association (SA) with the CN, and both nodes MUST use ONLY the new Kbm to sign subsequent BU/BA messages. The two endpoints MUST silently discard any signaling message 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. The only exception to this rule applies for the valid BU messages sent by the MN and signed with its private key. One key advantage offered by OMIPv6+ is the extension of the lifetime of the BCE. Since, re-keying MAY be needed, OMIPv6+ considers two scenarios: creating and refreshing the Kbm. In order to create a new Kbm, the MN MUST send a BU message with a higher timestamp, set the bit "S" and MUST sign the message with its private key. Such scenario occurs at the beginning of the session and when, for some reason, the MN reboots during an ongoing session. In order to refresh the Kbm, i.e., the bidirectional SA expires during the ongoing session, the MN MUST send a BU message with the bit "S" set, a valid sequence number, the KeNI and MUST sign the message with its private key. When the CN receives a Kbm refresh request in a valid BU message, it MUST send a new shared secret in a BA message, and SHOULD authenticate the BA message with the previous Kbm. 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. The care-of address test can be done by either using the standard return routability procedure or some alternative scheme, which may have better characteristics, e.g., using a signaling extension described in [MIPsec] or the Credit-Based Long-Term Address Tests [CBA]. Haddad, et al. Expires November 2004 [Page 6] INTERNET-DRAFT Applying CGA to OMIPv6 May 2004 7. New Options Format 7.1 The Key Option Format As it has been mentioned above, the CN MUST send a new Kbm each time it receives a BU message signed with the MN's private key and with the (S) bit set. For this purpose, this proposal uses a new option called Key option, which MUST be inserted in the BA message. 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 | Length = 16 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Binding Key Management (Kbm) + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Option Type TBD Option Length Length of the option = 16 Option Data This field contains the Kbm value. Note that the content of this field MUST be encrypted with the MN's public key. Haddad, et al. Expires November 2004 [Page 7] INTERNET-DRAFT Applying CGA to OMIPv6 May 2004 7.2 The Key Nonce Index (KeNI) Option Format The CN MUST insert this option in the BA message sent to the MN after receiving a BU message signed with the MN's corresponding private key and with the bit (S) set. The KeNI option format 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 | Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Key Nonce Index + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Option Type TBD Option Length Length of the option = 8 Option Data This value will be echoed back by the MN to the CN in all subsequent BU messages. Haddad, et al. Expires November 2004 [Page 8] INTERNET-DRAFT Applying CGA to OMIPv6 May 2004 7.3 The Timestamp (TiST) Option Format The MN MUST use the timestamp (TiST) in any BU message sent to the CN and carrying a request to create a new shared secret (i.e., the BU message is signed with the MN's private key and has the "S" bit set). The TiST option format 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Timestamp + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Option Type TBD Option Length Length of the option = 16 Option Data Timestamps are represented as a 64-bit unsigned fixed point number, in seconds relative to January 1, 1970 00:00 UTC. In this format the integer number of seconds is contained in the first 32 bits of the field, and the remaining 32 bits indicate the fraction part. The non-significant low order bits in the fraction part of the timestamp MUST be filled with zero and a random, unbiased 64-bitstring, will be added both to avoid systematic roundoff errors and as a means of loop detection and replay detection. Haddad, et al. Expires November 2004 [Page 9] INTERNET-DRAFT Applying CGA to OMIPv6 May 2004 7.4 The BU Signature (BUS) Option When the MN signs the BU message with its CGA private key, it MUST insert the signature in the BUS option. Such scenario occurs when the MN sends its first BU message to the CN and if the MN reboots during an ongoing session. The BUS option format 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + . Signature . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Option Type TBD Option Length Length of the option Option Data This field contains the signature of the BU message. 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 a BA message carrying a new Kbm shared secret. Haddad, et al. Expires November 2004 [Page 10] INTERNET-DRAFT Applying CGA to OMIPv6 May 2004 The format of the BU message with the new bit is as follows: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence # | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A|H|L|K|S| Reserved | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8. IANA Considerations This document defines a new CGA Message Type name space for use as type tags in messages that may be signed using CGA signatures. The values in this name space are 128-bit unsigned integers. Values in this name space are allocated on a First Come First Served basis [IANA]. IANA assigns new 128-bit values directly without a review. CGA Message Type values for private use MAY be generated with a strong random-number generator without IANA allocation. This document defines a new 128-bit value under the CGA Message Type [CGA] namespace, 0x5F27 0586 8D6C 4C56 A246 9EBB 9B2A 2E13. This document defines four new mobility options, which must be assigned Option Type values within the option numbering space of [MIPv6]. Haddad, et al. Expires November 2004 [Page 11] INTERNET-DRAFT Applying CGA to OMIPv6 May 2004 9. 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 if/when re-keying is needed. 10. Normative References [IANA] T. Narten, H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", RFC 2434, October 1998. [ITU.X690.2002] International Telecommunications Union, "Information Technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)", ITU-T Recommendation X.690, July 2002. [MIPv6] D. Johnson, C. Perkins, J. Arkko, "Mobility Support in IPv6", draft-ietf-mobileip-ipv6-24.txt, June 2003. [PKCS] Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC 3447, February 2003. [PKIC] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002. [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. Haddad, et al. Expires November 2004 [Page 12] INTERNET-DRAFT Applying CGA to OMIPv6 May 2004 11. Informative References [Aura] Aura, T. "Cryptographically Generated Address (CGA)", 6th Information Security Conference (ISC'03), Bristol, UK, October 2003. [CBLA] Arkko, J., Vogt, C., "Credit Based Long-Term Address Tests", draft-arkko-mipv6-agecredit-00, May 2004. [CGA] Aura, T. "Cryptographically Generated Address (CGA)", draft-ietf-send-cga-06, April 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. 12. 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 Haddad, et al. Expires November 2004 [Page 13] INTERNET-DRAFT Applying CGA to OMIPv6 May 2004 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 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. Haddad, et al. Expires November 2004 [Page 14] INTERNET-DRAFT Applying CGA to OMIPv6 May 2004 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 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 November 2004 [Page 15]