Network Working Group N. Venkitaraman Internet-Draft Motorola Expires: December 24, 2006 V. Narayanan L. Dondeti QUALCOMM, Inc. June 22, 2006 Symmetric-key Based IPv6 Addresses draft-narayanan-pba-01.txt 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 December 24, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract A cryptographically generated address (CGA) is an IPv6 address generated by applying a hash function over the public key of a node and some additional parameters. CGA ownership can be asserted only by the node claiming the address, but is readily verifiable using the public-key of that node by any other entity. Such address authorization is also plausible using symmetric keys, where a node Venkitaraman, et al. Expires December 24, 2006 [Page 1] Internet-Draft SBA June 2006 generating the self-identifying address shares a key with the verifier or its agent. This document specifies symmetric-key based address (SBA) generation. The infrastructure support comes with several advantages including proxy-mode operation; the symmetric key usage results in efficient operation; and finally the use of keyed hashing provides security advantages over CGAs. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Symmetric Key based IPv6 address Generation . . . . . . . . . 4 3.1. Input key considerations for SBA . . . . . . . . . . . . . 5 3.2. Input key generation for SBA . . . . . . . . . . . . . . . 5 4. SBA Generation and Verification . . . . . . . . . . . . . . . 6 4.1. Parameters for SBA Generation . . . . . . . . . . . . . . 6 4.2. SBA Generation . . . . . . . . . . . . . . . . . . . . . . 8 4.3. SBA Verification . . . . . . . . . . . . . . . . . . . . . 9 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 5.1. On the input parameters to SBA generation . . . . . . . . 10 5.2. Strength of the SBA derivation . . . . . . . . . . . . . . 11 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 8.1. Normative References . . . . . . . . . . . . . . . . . . . 12 8.2. Informative References . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . . . . 14 Venkitaraman, et al. Expires December 24, 2006 [Page 2] Internet-Draft SBA June 2006 1. Introduction Cryptographically generated addresses (CGAs) [RFC3972] are IPv6 addresses where the interface identifier -- the lower 64 bits of the address -- is generated using a cryptographic hash of a public key and other parameters. The corresponding private key can be used to assert the claim to the generated address. Any node can verify whether a node claiming the address indeed owns that address by using the known public key. While the asymmetric key based operations can be expensive, the key advantage of CGA generation and verification is that it works without the need for infrastructure support. Many systems employ AAA-based infrastructure support with pre- provisioned symmetric keys; such existing key sharing relationships can be used for generation and verification of IPv6 addresses. Address generation using symmetric keys have a number of benefits. In many systems, especially those involving mobile nodes, trusted entities other than the node which owns the address may have to generate messages on behalf of the node. For instance a Home Agent (HA) may need to generate a proxy neighbor advertisement when a mobile node is away from its home network. In such a case, generating a HoA of the mobile node using a shared key between the HA and the MN enables the HA to simply proxy for the mobile when the mobile node is away from home. Similarly an access router (AR) may need to generate advertisement messages to defend an IP address corresponding to a mobile node that is presently under a different subnet. Generating a CoA using a shared key between the AR and the MN enables the AR to generate advertisements on behalf of the mobile node. In many of the above mentioned situations, a shared key is already available between the mobile node and the entity generating messages on behalf of it. For example, the MN shares a security association with the HA in the case of Mobile IP. In the case of FMIPv6 operation, the MN shares a handover key with the AR. Both these SAs could have been generated with the aid of a AAA server: running IKEv2/EAP with the HA to generate an SA for MIP6 involves the shared secret the MN shares with the AAA server; similarly, AAA-based handover keys may be generated for FMIPv6. In the presence of such SAs, it is desirable to extend that trust relationship to provide address authorization. In a number of systems, packets always flow via an access router. In such systems, in the presence of a shared key between a node and the AR, it is more efficient to generate IP addresses to prove address ownership using symmetric keys rather than asymmetric cryptography. Venkitaraman, et al. Expires December 24, 2006 [Page 3] Internet-Draft SBA June 2006 This draft provides a means of IPv6 address generation using a shared secret so that the IP address of a node can be verified by the entity with which the node shares the secret. This is generally applicable to systems where a node generating an address needs to prove the ownership only to a selected number of nodes with which it has a direct or a derived trust relationship. 2. Terminology 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 RFC 2119 [RFC2119]. In addition, this document uses the following terms: Symmetric Key Based Address (SBA) An IPv6 address generated cryptographically using a pre-shared key. SBAs are self-identifying addresses in that the verifier can independently determine the validity of the address by running the address generation process. Address Generation Key (AGK) A key generated from the PSK specifically for use in the generation of SBAs. SBA Generator This is an entity that generates a self-identifying IPv6 address using a shared-key. SBA Verifier SBA Verifier is the entity that needs to determine the validity of the generator's claim to an IPv6 SBA, either using a key available locally or with the help of a third party that holds the key used to generate the address. The third party is typically a AAA server. 3. Symmetric Key based IPv6 address Generation This section describes a method using symmetric keys to derive the interface identifier part of the IPv6 address of a node. Similar to the CGA specification [RFC3972], this document refers to IPv6 addresses where the leftmost 64 bits form the IPv6 prefix and the Venkitaraman, et al. Expires December 24, 2006 [Page 4] Internet-Draft SBA June 2006 rightmost 64 bits of the address form the interface identifier. Unlike the CGA addresses, there is no 'Sec' field. An SBA is the truncated output of a PRF, keyed with the symmetric key known to the generator and the verifier or its agent; other inputs to the PRF are the IPv6 prefix, generator or IPv6 node's identity (used to look up the symmetric key), and a random nonce selected by the generator. The leftmost 64bits of the output of the PRF are taken and masked with 0xfcffffffffffffff to set bits 6 and 7 (i.e., the "u" and "g" bits) [RFC3513] to zero. These bits are ignored by the verifier in comparing the locally generated IPv6 suffix, based on the input parameters and the shared symmetric key, and the claimed suffix. 3.1. Input key considerations for SBA SBAs are derived using a symmetric key shared between the IPv6 suffix generator and the verifier. Alternatively, the verifier may use the help of a third party (e.g., AAA server) which shares a key with the generator. In either case, there may already be a key specifically designated for the purpose of address generation. If there is only a generic shared key between the generator and the verifier, it is desirable to generate a separate key for the purpose of address generation to avoid using a single key for different purposes. Note that address generation keys (AGK) may be static as in case of a key generated from a PSK (see the next section) or dynamic when the it is derived as part of another authentication process (note that the PSK may or may not be used for that authentication). 3.2. Input key generation for SBA When a designated key for IPv6 address generation is not available, the pre-shared key (PSK) may be used to derive an AGK using the following key derivation function (KDF). AGK = PRF+ (PSK, "Address Generation Key", Op-data) Op-data or optional data is NULL when the AGK is derived within the entity that holds the PSK, and is equal to the Verifier's ID, when the AGK is derived for a verifier. The third party, typically a AAA server, generates an AGK and sends it on demand to the verifier using the AAA protocol. The AGK has the following properties. Venkitaraman, et al. Expires December 24, 2006 [Page 5] Internet-Draft SBA June 2006 o The length, l, of the AGK is dependent on the PRF algorithm used in generating the SBA. We may use a cipher-based or a hash-based PRF. In some cases, for instance in AES-256 based PRFs, the output size of the PRF is less than the AGK length. Thus, we specify the use of PRF+ as defined in [RFC4306] to generate the AGK. The first l bits of the PRF+ output serves as the AGK. o The AGK may be delivered to another entity in some special cases. This applies when the verifier is authorized to possess the key for subsequent verifications without any interaction with the third party. o The AGK is cryptographically separate from any other keys derived from the PSK. o This document does not mandate a lifetime value for the AGK. However, protocols specifying the derivation and use of such AGKs must specify a lifetime depending on the usage scenario. The maximum lifetime of a dynamically derived AGK MUST NOT exceed 8 hours. o A given AGK MUST NOT be shared by multiple verifiers. o AGKs have a name associated with them. If an AGK is derived from a PSK, the AGK name is derived as follows: AGK-name = trunc-64(SHA-256(VerifierID, NodeID, ServerID, "AGK- name")), where trunc-64 indicates that the output of SHA-256 is truncated to 64 bits. 4. SBA Generation and Verification 4.1. Parameters for SBA Generation SBAs rely on a symmetric key shared between the address generator and the verifier (or the verifier's agent, such as a AAA server) either via pre-configuration or a bootstrapping protocol. To identify the shared key, an identity of the shared key (e.g., key name) or that of the address generator (e.g., NAI) is included as one of the parameters. This is required for the verifier to lookup the AGK, or if that is not available, to lookup the PSK and generate the AGK from there following the procedure in Section 3.1. The simplest technique to identify the key is to use the generator's ID; given that and the context of the key lookup, the search semantics are unambiguous. Alternatively, the generator may use the AGK's key name as the identity. In that case, the AGK is known to be a key designated for the purpose of address generation and known to be readily available (for instance, the key and the key name might be pre-computed and cached for easy lookup) at the verifier or its agent. Note that the key identity is required to be included in the SBA data structure so that the verifier can lookup the AGK. It is included in Venkitaraman, et al. Expires December 24, 2006 [Page 6] Internet-Draft SBA June 2006 the SBA generation to increase the work of a brute-force attacker. Another technique to expand the work involved in a brute-force attack is to include the IPv6 prefix in the data structure and the SBA generation. The prefix is included to prevent the use of the same interface identifier across multiple prefixes. The prefix MAY be set to zero when the node wishes to re-use the same suffix across multiple prefixes. A verifier MAY require the use of the actual prefix for which the suffix is being generated. Finally, a 16-octet random nonce is added to SBA generation. The nonce serves a couple of different purposes: First, whereas the earlier parameters are static during a single derivation process, the nonce can be modified as necessary by the generator. After SBA generation, the generator runs the duplicate address detection (DAD) [RFC2462] procedure and if the generated address is already being used, it needs to derive a new address. The generator picks a new random nonce and derives a new SBA and repeats DAD. This is the primary purpose of the nonce. In case of address collisions, the number of SBAs generated using varying nonces MAY be restricted to a certain number based on local policy. Next, changing the nonce allows generation of different addresses for privacy purposes. Note that the generator's ID, prefix and the AGK might be static or semi-static (the IPv6 node may move and use a different prefix or the AGK might be periodically changed, especially if it is not directly derived from a PSK along the lines of the derivation in Section 3.2), but the nonce can be changed by the generator at will. With that background, we specify the SBA data structure; Venkitaraman, et al. Expires December 24, 2006 [Page 7] Internet-Draft SBA June 2006 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CR-ID |ID Type| Length | | +++++++++++++++++++++++++++++++++ Node/Key identity (variable) | ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Subnet Prefix (8 octets) + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + nonce (16 octets) + | | + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: Data structure of parameters used in SBA Generation and Verification CR-ID: This is a 4-bit field indicating the cryptographic suite ID. The value 0000 indicates HMAC-SHA-256, the default transform. ID Type: ID Type is a 4-bit indicating the type of the identity. The following values are currently defined: 0000 Node ID 0001 AGK derived from a PSK 0010 AGK derived through other means Length: The Length field indicates the size of the Node/Key Identity field in octets. When Node ID is 0001, the Length is in fact fixed, as specified in Section 3.2, and is 8 octets. Node/Key Identity This field, whose type and length are indicated by the preceding two fields, namely ID Type and Length, is used to indicate the identity of the generator (node ID), or the identity of the key used by the generator (key ID). Subnet Prefix: This field contains the 8-octet subnet prefix. It may be all 0s if the verifier's policy allows it and the generator wants to generate and use an address across multiple prefixes. 4.2. SBA Generation The IPv6 suffix of the address of the node is derived as follows: Address Suffix = trunc-64(PRF(AGK, node or key identity || subnet prefix || nonce)), where || denotes concatenation. Venkitaraman, et al. Expires December 24, 2006 [Page 8] Internet-Draft SBA June 2006 The default PRF is HMAC-SHA-256. The SBA generation procedure is as follows: 1. The generator identifies the AGK and it's identity. The identity forms the first component of the SBA data structure. 2. Then the generator selects the IPv6 suffix it wants to use. Generally this is advertised by a router. 3. Finally, the generator selects a random nonce and completes the formation of the SBA data structure. 4. The generator then uses the AGK to compute the PRF over the node/ key identity, subnet prefix and the nonce. 5. The output of the PRF is truncted to 64 bits and then AND'ed with 0xfcffffffffffffff to set bits 6 and 7 (i.e., the "u" and "g" bits) [RFC3513] to zero. The result is the interface identifier. 6. The generator runs the IPv6 duplicate address detection process. If there is an address collision, the procedure above, starting at step 3, is repeated. 7. The generated suffix is then concatenated with the advertised prefix to form a complete IPv6 address for the node. 4.3. SBA Verification The SBA verification procedure is as follows: 1. The verifier compares IPv6 prefix of the claimed address with the IPv6 prefix in the SBA data structure. 2. Next, the verifier uses the ID type field to determine the type of the identity specified by the Generator. The ID length field is then used to extract the Node/Key Identity value. 1. If the ID type is NAI, the verifier may have to route (based on the NAI) the request for address verification to a third party. 2. If the ID type is a key ID, it is plausible that the verifier has the key cached locally. The verifier looks up the key ID in its key cache/store. 3. If the ID is not found, the verifier sends the request to its agent. 3. The verifier's agent, typically a AAA server, uses the following steps: 1. If the ID type is NAI, the AAA server looks up the PSK and derives an AGK to compute the SBA, using the SBA generation parameters. 2. If the ID type is key ID, the server looks up the key and computes the SBA. 4. The verifier or its agent then uses the AGK to compute the PRF, following the procedure specified in Section 4.2. The Crypto ID field indicates the PRF to be used in the computation. Venkitaraman, et al. Expires December 24, 2006 [Page 9] Internet-Draft SBA June 2006 5. The output of the PRF is truncted to 64 bits and then AND'ed with 0xfcffffffffffffff to set bits 6 and 7 (i.e., the "u" and "g" bits) [RFC3513] to zero. 6. The locally computed suffix is compared with the claimed suffix. If any of the comparisons fail, the verifier stops immediately and logs an error. 5. Security Considerations The goal of SBA generation is to prevent arbitrary claims to IPv6 addresses. To that end, the only means of address generation are algorithms that can be independently executed by the verifier of claims to addresses using keys that are known to the generator, and possible the verifier. CGAs generation uses asymmetric key cryptography for this purpose and SBAs use symmetric key cryptography. 5.1. On the input parameters to SBA generation The simplest technique to generate the SBA might be to generate a PRF over a constant string, say, "SBA Generation", using a key shared between the generator and the verifier or its agent. Given that the key is secret, a third party should not be able to claim an address generated using that method. However, this procedure allows the adversary to build a database of PRFs over the constant string and use that to determine the AGK being used for key derivation. We propose to include some additional parameters in the SBA generation function to avoid such brute force attacks. o First, the node or key ID is added to the derivation process. Addition of this parameter forces the brute-force attacker to build the database on a per NAI or a per key ID (which is a random number of length, typically around 64 bits) basis. o Second, the prefix is added to the derivation process. This also increases the burden on the attacker. Furthermore, inclusion of the prefix allows the verifier to enforce a policy on the generator to change its interface id when the generator moves into the verifier's subnet. Note that the prefix MAY be all 0s depending on the verifier's policy. Thus, in those cases, the node or key ID mitigates the effectiveness of brute-force attacks. o Finally, a random nonce is used in the derivation process. The primary property of the nonce is that it is a dynamic parameter: if the SBA is a duplicate address, the generator is to change the nonce to derive another address. The nonce also allows the generator to change its address for privacy purposes. Note that the Cryptographic Suite ID, ID Type and Length are not used Venkitaraman, et al. Expires December 24, 2006 [Page 10] Internet-Draft SBA June 2006 in the derivation. There is no real advantage to adding those fields to the derivation and if those fields are tampered with the key look-up will fail or an incorrect key and/or algorithm will be used in the derivation causing the verification to fail. In other words any modifications to those fields are detectable even without adding them as inputs to the PRF. 5.2. Strength of the SBA derivation SBA generation uses 62 bits from the output of a PRF. Thus the effective strength of the derivation is 2^62 computations. Given similar strength, CGAs use a modifier to increase the computational requirements on brute-force attacks. Such modifiers are not required to increase the strength of SBAs. Suppose an attacker succeeds in finding a random key that results in the same SBAs as the victim. Note that the attacker cannot really use the key to assert ownership on any generated addresses. To get the verifier to accept the SBA, the generator would have to have established its random key as the AGK with the verifier or its agent. Since the AGK is generated from the PSK or other keying material using a PRF, this is not possible. Note that the attacker could send an SBA that it generates with the victim's NAI. Under the assumptions of this attack (the attacker having found a collision in SBA generation in 2^62 computations), the attacker would be able to change the address of the victim. We feel that is sufficient strength at the moment. Note that such an attack could be mitigated by protecting the messages that contain SBAs (e.g., neighbor discovery) with a MAC of sufficient strength. 6. IANA Considerations IANA registration requirements will be specified in a future version of this document. 7. Acknowledgments We thank Greg Rose for his help with the security analysis of shared- key based address generation. 8. References Venkitaraman, et al. Expires December 24, 2006 [Page 11] Internet-Draft SBA June 2006 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005. 8.2. Informative References [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998. [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, March 2005. [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003. [RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor Discovery (ND) Trust Models and Threats", RFC 3756, May 2004. Venkitaraman, et al. Expires December 24, 2006 [Page 12] Internet-Draft SBA June 2006 Authors' Addresses Narayanan Venkitaraman Motorola 1301 E. Algonquin Road Schaumburg, IL 60196 US Email: narayanan.venkitaraman@motorola.com Vidya Narayanan QUALCOMM, Inc. 5775 Morehouse Dr San Diego, CA 92121 US Email: vidyan@qualcomm.com Lakshminath Dondeti QUALCOMM, Inc. 5775 Morehouse Dr San Diego, CA USA Phone: +1 858-845-1267 Email: ldondeti@qualcomm.com Venkitaraman, et al. Expires December 24, 2006 [Page 13] Internet-Draft SBA June 2006 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 (2006). 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. Venkitaraman, et al. Expires December 24, 2006 [Page 14]