Mobility Optimizations RG J. Kempf Internet Draft C. Gentry Expires: November, 2005 DoCoMo Labs USA May 6, 2005 Secure IPv6 Address Proxying using Multi-Key Cryptographically Generated Addresses (MCGAs) draft-kempf-mobopts-ringsig-ndproxy-00.txt Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 November 6, 2005. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract RFC 3971 and 3972 (SEND) define a protocol for securing resolution of a statelessly autoconfigured IPv6 address to a link address as defined by IPv6 Neighbor Discovery. SEND does this by requiring the autoconfigured addresses to be cryptographically generated by the host from an RSA public key. However, one drawback of SEND is that Kempf & Gentry Expires November, 2005 [Page 1] Internet-Draft Secure IPv6 Address Proxying May 2005 such addresses cannot be securely proxied. Proxy Neighbor Discovery is important for Mobile IPv6 and in certain other cases. In this document, we describe an extension of SEND to addresses that are cryptographically generated using multiple public keys, called multi- key CGAs. Neighbor Discovery messages for multi-key CGAs are signed with an RSA ring signature, a type of signature that can be generated using the private key of any node but which requires the public keys of all nodes to verify. Multi-key CGAs can be securely proxied by all nodes that contribute keys to the address. The advantage of multi-key CGAs over other techniques of secure address proxying, such as trusting the router or using an attribute certificate, is that it preserves location privacy. A receiver cannot determine from the IPv6 address, ring signature, or cryptographic parameters whether the node or the proxy is defending the address, and hence whether the node is on or off the link. Conventions used in this document 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 [1]. Table of Contents 1. Introduction...................................................3 2. Existing Work..................................................4 3. Extension to SEND for Secure Proxying..........................5 3.1. Processing Rules for Routers..............................5 3.2. Processing Rules for Address-configuring Nodes............6 3.3. Processing Rules for Address-verifying Nodes..............7 3.4. Error Conditions..........................................7 3.5. Backward Compatibility with Standard SEND Nodes...........7 4. Multi-key CGAs and Ring Signatures.............................8 4.1. Generating and Validating Multi-key CGA Addresses.........8 4.2. Generating and Validating Ring Signatures.................8 5. SEND Extensions...............................................10 5.1. CGA Parameters Suboption.................................10 5.2. RSA Ring Signature Key Suboption.........................11 5.3. RSA Ring Signature Option................................12 6. Mobile IPv6 Extensions........................................13 7. Security Considerations.......................................15 8. IANA Considerations...........................................16 9. References....................................................16 9.1. Normative References.....................................16 9.2. Informative References...................................17 Author's Addresses...............................................17 Kempf & Gentry Expires November, 2005 [Page 2] Internet-Draft Secure IPv6 Address Proxying May 2005 Intellectual Property Statement..................................17 Disclaimer of Validity...........................................18 Copyright Statement..............................................18 Acknowledgment...................................................18 1. Introduction SEcure Neighbor Discovery (SEND) [2] is a protocol for securing the mapping between an IPv6 address and a link address. The protocol provides nodes on an IPv6 link assurance that responses to an address resolution requested through the IPv6 Neighbor Discovery protocol [3] originate from a node on the link that is authorized to claim the address. The principle mechanism for address resolution security is cryptographically generated addresses (CGAs) [4]. CGAs are autoconfigured IPv6 addresses in which the interface identifier portion of the address (bottom 64 bits) is generated by taking the hash of an RSA public key generated by the node, together with some additional parameters. A Neighbor Advertisement resolving the CGA to a link address is signed with the matching private key, establishing that the message originated from the node in possession of the public key used to generate the address, and, thereby, proving the originating node's authorization to claim the address. One drawback of SEND as specified is that it does not allow CGAs to be defended by proxies. Proxy defense of addresses is especially important in Mobile IPv6 [5]. When a mobile node moves off its home link, the home agent is required to defend the address for the mobile node. This allows other nodes on the link to continue to send traffic to the mobile node as if it were on the link, and, more importantly, prevents any new node arriving on the link from claiming the mobile node's address. Proxy defense cannot be done securely, however, because only the mobile node possesses the private key allowing it to sign the Neighbor Advertisement messages. While there are other cases in which secure proxying of autoconfigured IPv6 addresses is necessary, the mobility case seems most challenging, because any solution should avoid disclosing whether the mobile node or the proxy is performing the claim and defense, and thus whether the mobile node is on or off link. In this document, we describe an extension of CGAs and the SEND protocol that allows a node to construct a CGA such that it can be securely proxied by another node. The next section describes a few techniques for secure proxying that have been discussed in the context of a problem statement on secure proxying. Section 3 presents an overview of the protocol. In Section 4, the two important cryptographic components of the protocol are discussed - multi-key CGAs and ring signatures. Section 5 contains the wire Kempf & Gentry Expires November, 2005 [Page 3] Internet-Draft Secure IPv6 Address Proxying May 2005 format for extensions to implement multi-key CGAs and ring signatures for SEND. Section 5 discusses Mobile IPv6 home agent proxying as an example of how secure proxying is triggered. In Section 7, security considerations are discussed, concluding the paper. Note that the MCGA technique requires a node to know when it first comes on the link whether or not it will require secure proxying. While this may be fairly obvious for some kinds of IPv6 nodes (for example, Mobile IPv6 nodes), for others it may not be. In such cases, the techniques described in Section 2 may be sufficient, as long as there is no strong requirement for location privacy. 2. Existing Work In draft-daley [9], two scenerios are discussed for secure address proxying, namely: 1. Proxying of a mobile node's home address by the mobile node's Mobile IPv6 home agent, 2. Proxying by a bridge-like proxy. The draft recommends the following two techniques: 1. For home agent proxying, the mobile node generates an authorization certificate specifically authorizing the home agent to proxy the address. The home agent includes the authorization certificate in Neighbor Discovery, allowing the sender to establish an authorization path back to the mobile node. 2. For bridge-like proxies, the proxy obtains a certificate from the router authorizing it to proxy. By extension, certified routers would have this right too. In this case, the sender of a Neighbor Discovery message trusts a certified router or certified proxy by virtue of the trust established through the certificate chain from the root of trust shared between the host and the router or proxy. To make the process more rigorous, the certificate granted by the router to the proxy or configured on the router might have an attribute in it indicating that it is authorized to proxy. Note that Solution 2 would work for Mobile IPv6 home agents as well. A major disadvantage of both these solutions is that a querying node can tell from the signature and security parameters on the Neighbor Advertisement message whether the message originated from a proxy or from the original owner of the address. On a wired link with a bridge-like proxy, this may not pose such a problem, since the Kempf & Gentry Expires November, 2005 [Page 4] Internet-Draft Secure IPv6 Address Proxying May 2005 information would only tell the querying node whether the original owner was on the same topological segment of the network. This information is of varying value to an attacker, and would require the attacker to know the wiring diagram of the local network to be of any real use. However, on a wireless network, typically a direct geographical mapping exists between a local link, in the form of a collection of wireless cells, and the geographical area covered by the cells. Depending on how large the cells are and how much geographical area is covered by them, an attacker could use the information about whether or not the original owner was defending the address to determine whether or not the owner was on its home link. This information could then be used for a variety of purposes, some of which might not be in the interest of the original address owner. 3. Extension to SEND for Secure Proxying 3.1. Processing Rules for Routers Prior to issuing any Router Advertisements, a router that offers secure IPv6 address proxying service, such as a Mobile IPv6 home agent, generates an AES encryption key [5], MCGA-ENCRYPTION-KEY. This key is used for encrypting the private key part of the node-specific RSA ring signature public key/private key pair, and it should not be disclosed to any other party in order to keep the node-specific private key confidential. The private key is encrypted and sent to the node in order to avoid accumulating node-specific state on the router, and thereby avoid an opportunity for a state depletion DoS attack. When the router receives a Router Solicitation having a source address as a unicast link local IPv6 address, it replies by sending a unicast Router Advertisement, signing the Router Advertisement with a RSA ring signature instead of a standard single key RSA signature. Two keys are used to generate ring signature and the multi-key CGA for the Router Advertisement source address: 1. The router's certified public key. This provides the soliciting node with the assurance that the routing information is from a router authorized to route and not from a rogue, 2. A public key generated specifically for the soliciting node that issued the Router Solicitation to use in generating multi-key CGAs that the router can proxy. Multicast Router Advertisements are handled as in RFC 3971. Kempf & Gentry Expires November, 2005 [Page 5] Internet-Draft Secure IPv6 Address Proxying May 2005 The router constructs the CGA Parameters Option for the Router Advertisement by putting the certified public key directly into the Public Key Field of the option. The node-specific key is inserted into the Ring Signature Public Key Field of a new CGA Parameters Suboption (see Section 5.1) of type RSA Ring Signature Key Suboption (see Section 5.2). The router also encrypts the private key using MCGA-ENCRYPTION-KEY and inserts it into the Encrypted Private Key Field of the RSA Ring Signature Key Suboption. The RSA Ring Signature Key Suboption is added to the CGA Parameters Option in the Extension Field. The Router Advertisement also includes an RSA Ring Signature Option (see Section 5.3) where the router places the RSA ring signature generated as described in Section 4.2, to provide the receiving node with proof of authorization to route. The ring signature can be generated using either the private key part of the certified public key/private key pair, or the node-specific private key. The actual trigger for a router to begin secure proxying depends on what protocol is being used. Section 5.3 discusses how secure proxying is triggered in Mobile IPv6 home agents. One requirement for initiating proxying is that the initiating node MUST supply both the node-specific public key and the matching encrypted private key to the router, since the router does not keep track of the node-specific public key/private key pair. The router uses MCGA-ENCRYPTION-KEY to decrypt the encrypted private key. When the router is called upon to proxy, it uses the procedure described in Section 3.2. Note that the router MUST construct the CGA Parameters Option in exactly the same way as the address- configuring node, in order to avoid disclosing whether or not the address is being proxied. 3.2. Processing Rules for Address-configuring Nodes To obtain a router generated node-specific public key/encrypted private key pair for a multi-key CGA, a node configuring an address MUST multicast a unicast Router Solicitation having a link local address as the source address to the All_Routers_Multicast_Address, as described in RFC 2641. A router that is capable of secure proxying responds with a CGA Parameters Option containing a RSA Signature Key Suboption with a node-specific public key and matching encrypted private key for the soliciting node. The node then generates a multi-key CGA as described in Section 4.1, using an RSA public key that it generated and the node-specific public key generated by the router. The node records the node- specific public key and the matching encrypted private key from the Kempf & Gentry Expires November, 2005 [Page 6] Internet-Draft Secure IPv6 Address Proxying May 2005 router for later use when address proxy service is required. The node then performs duplicate address detection, address claim and defense, and address resolution on the link exactly as described in RFC 3971, except the node uses a RSA Ring Signature Option instead of a standard SEND RSA Signature Option, and the node includes a RSA Ring Signature Key Suboption in the CGA Parameters Option. The CGA Parameters Option is constructed in the following way. The public key generated by the node is inserted into the Public Key Field of the CGA Parameters Option. The node-specific public key generated by the router is inserted into the Ring Signature Public Key Field of the RSA Ring Signature Key Suboption. The Encrypted Private Key Field of the RSA Ring Signature Key Suboption is left blank. 3.3. Processing Rules for Address-verifying Nodes A node receiving a Neighbor Advertisement, Neighbor Solicitation, Router Advertisement, Router Solicitation, or Redirect message with a RSA Ring Signature Option and a CGA Parameters Option containing an RSA Ring Signature Key Suboption performs verification exactly as described in RFC 3971, except verification of the address is done as described in Section 4.1 and verification of the signature is done as described in Section 4.2. 3.4. Error Conditions If a multi-CGA capable node receives a message with an RSA Ring Signature Option but the CGA Parameters Option has no RSA Ring Signature Key Suboption, the node SHOULD treat the message as if it were unsecured, as described in RFC 3971. If a multi-CGA capable node receives a message with a standard RFC 3971 RSA Signature Option but the CGA Parameters Option contains an RSA Ring Signature Key Suboption, the node SHOULD ignore the RSA Ring Signature Option and treat the message like a standard RFC 3791 SEND- secured message. The node SHOULD use the standard RSA signature verification algorithm and the key in the Public Key Field of the CGA Parameters Option to verify the signature. 3.5. Backward Compatibility with Standard SEND Nodes A standard SEND node receiving a message with a RSA Ring Signature Option ignores the option according to RFC 2461, and also ignores the CGA Parameters Option, due to the lack of a standard SEND RSA Signature Option. Consequently, a standard SEND node treats a multi- key CGA message as if it were unsecured. Multi-CGA capable nodes MUST Kempf & Gentry Expires November, 2005 [Page 7] Internet-Draft Secure IPv6 Address Proxying May 2005 be prepared to issue Neighbor Discovery messages with standard SEND RSA signatures if other nodes on the link do not support multi-key CGAs. A multi-key CGA node receiving a message with a standard SEND RSA Signature Option and a CGA Parameters Option MUST treat the message as a secured Neighbor Discovery message. Since standard SEND nodes are not capable of secure proxying, a multi-key CGA node SHOULD treat a standard CGA address that is proxied as insecure. 4. Multi-key CGAs and Ring Signatures 4.1. Generating and Validating Multi-key CGA Addresses Multi-key CGA addresses are formed as described in RFC 3972, except for the following change. In Step 2 of the algorithm in Section 4 of RFC 3972, instead of concatenating the DER-encoded ASN.1 structure for the public key, the generating host performs the following operation: concat-val = SHA1(pk(1) | pk(2) | ... | pk(n) ) where | is the bit-wise concatenation function, SHA1() is the SHA1 cryptographic hash function [7], pk(1)- pk(n) are the n DER-encoded ASN.1 structures for the public keys of the nodes that will be claiming or proxying the address, and concat-val is the value that is concatenated in place of DER-encoded key. Note that, in the current case n = 2 and the two keys are the node's own public key and the node-specific public key generated by the router, but this algorithm generalizes to any number of keys. When validating a multi-key CGA, the validating node performs calculation as described in RFC 3972 with the exception of Steps 3 and 6 in Section 5. In Step 3, the Extension Field is stripped out of the CGA Parameters Option prior to calculating Hash1. In Step 6, instead of concatenating the Extension Field to form Hash2, concat- val from above is calculated using the node public key from the Public Key Field of the CGA Parameters Option and the ring signature key from RSA Ring Signature Key Field of the CGA Parameters Suboption. 4.2. Generating and Validating Ring Signatures To generate a ring signature, a digest of the message is first generated exactly as described in Section 5.2 of RFC 3971, except that instead of using the CGA type tag, the MCGA type tag of TBD is used. Call the digest DIGEST-F(m). Kempf & Gentry Expires November, 2005 [Page 8] Internet-Draft Secure IPv6 Address Proxying May 2005 We use the Rivest-Shamir-Tauman ring signature scheme [8]. Assume that the output of the SHA1 digest produces a d-bit string. Let E() be an encryption scheme that uses d-bit keys and has b-bit input and output. (We impose an additional condition on b below.) Let t be a parameter - e.g., t may equal 80. Let ~ denote the XOR function. The public keys in the Rivest-Shamir-Tauman ring signature scheme are exactly the same as public keys in RSA. Specifically pk(i) = (N(i), e(i)), where N(i) is a large (e.g., 1024-bit) composite integer that is the product of two large prime numbers p(i) and q(i) and where e(i) is an integer that is relatively prime to (p(i)-1)*(q(i)-1). Let b be an integer such that 2**b > (2**t) * N(i) for all i. The signature is calculated as follows. Let pk(i) be the public key of the "real" signer. The signer: 1. Sets symmetric encryption key k to be DIGEST-F(m); 2. Picks a random b-bit string v; 3. For j from 1 to n (except j is not equal to i): a. Picks random b-bit string x(j); b. Computes (q(j), r(j)) such that x(j) = q(j) * N(j) + r(j) for r(j) in the interval [0, N(j)]; c. Computes y'(j) = (x(j)**e(j)) mod N(j) for y'(j) in the interval [0, N(j)]; d. Sets y(j) = q(j)* N(j) + y'(j); e. Goes to Step 3a if y(j) is greater than or equal to 2**b; 4. Computes y(i) such that: E(k)(y(n) ~ E(k)(y(n-1) ~ E(k)(...~ E(k)(y(1) ~ v)...))) = v; 5. Computes (q(i), r(i)) such that: y(i) = q(i) * N(i) + r(i) for r(i) in the interval [0, N(i)]; 6. Computes x'(i) = (y(i)**1/e(i)) mod N(i) for x'(i) in the interval [0, N(i)]; 7. Sets x(i) = q(i) * N(i) + x(i); 8. Goes to Step 3 if x(i) is greater than or equal to 2**b; 9. Outputs the ring signature (x(1), ..., x(n), v). Above, if t is large enough, there will be only a negligibly small probability that the signature generation algorithm will abort in Step 3e or Step 8 because y(j) or x(i) spills out of the permitted range of [0,2**b). Regarding Step 4 of signature generation above, notice that: Kempf & Gentry Expires November, 2005 [Page 9] Internet-Draft Secure IPv6 Address Proxying May 2005 y(i) = E(k)**-1(y(n) ~ E(k)**-1(... y(i+1)~ E(k)**-1(v))) ~ E(k)(y(i-1)~ E(k)(...~ E(k)(y(1)~ v))) For validation, if DIGEST-F(m) is the SHA1 digest of the message calculated as above, and public keys pk(1), ..., pk(n) are the public keys of potential signers, the ring signature (x(1), ... x(n), v) can be verified as follows. The verifier: 1. Sets symmetric encryption key k to be DIGEST-F(m); 2. For j from 1 to n: a. Computes (q(j), r(j)) such that: x(j) = q(j) * N(j) + r(j) for r(j) in the interval [0, N(j)]; b. Computes y'(j) = (x(j)**e(j)) mod N(j) for y'(j) in the interval [0, N(j)]; c. Sets y(j) = q(j) * N(j) + y'(j); 3. Confirms that: E(k)(y(n) ~ E(k)(y(n-1) ~ E(k)(...~ E(k)(y(1) ~ v)...))) == v. The above ring signature scheme by Rivest, Shamir, and Tauman is just one example of a ring signature scheme allowing a signer to sign anonymously within a ring of possible signers. Many other ring signature schemes exist in the literature and could be used. 5. SEND Extensions 5.1. CGA Parameters Suboption A CGA Parameters Suboption has the following format: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Suboption Data ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type Suboption type code, assigned by IANA. Length Kempf & Gentry Expires November, 2005 [Page 10] Internet-Draft Secure IPv6 Address Proxying May 2005 Two octet suboption length, in units of octets, including the type and length fields. Reserved Set by the sender to zero and ignored by the receiver. Suboption Data Variable length field containing the suboption data. 5.2. RSA Ring Signature Key Suboption The RSA Ring Signature Key Suboption has the following format: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Public Key Length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Public Key (variable) | ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Encrypted Private Key Length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Encrypted Private Key (variable) | ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type TBA1 Length Two octet suboption length, in units of octets, including the type and length fields. Public Key Length Kempf & Gentry Expires November, 2005 [Page 11] Internet-Draft Secure IPv6 Address Proxying May 2005 Two octet field containing the length of the public key, in octets. Public Key Variable length field containing the node-specific public key from the proxying router. Encrypted Private Key Length Two octet field containing the length of the encrypted private key, in octets. Encrypted Private Key Variable length field containing the encrypted private key corresponding to the node-specific public key. 5.3. RSA Ring Signature Option The RSA Ring Signature Option has the following format: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Key Hash + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Digital Signature (variable) + | | ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Padding + | | ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Kempf & Gentry Expires November, 2005 [Page 12] Internet-Draft Secure IPv6 Address Proxying May 2005 Type TBA2 Length One octet option length, in units of 8 octets, including the type and length fields. Reserved A 2 octet field reserved for future use. The value MUST be initialized to zero by the sender, and MUST be ignored by the receiver. Key Hash A 16 octet field containing the most significant (leftmost) 128 bits of a SHA-1 [7] hash of the public key used for constructing the signature. The SHA-1 hash is taken over the presentation used in the Public Key Field of the CGA Parameters Field carried in the CGA Option. Its purpose is to associate the signature to a particular key known by the receiver. Such a key can either be stored in the certificate cache of the receiver be received in the CGA Option in the same message. Digital Signature A variable-length field containing a PKCS#1 v1.5 signature, constructed by using the sender's private key as described in Section 4.2. 6. Mobile IPv6 Extensions One important application of secure proxying is in Mobile IPv6 [5]. When a mobile node leaves the home link, the home agent is responsible for proxying the address. If the address is an MCGA, the home agent can perform the proxying in a secure manner. The signal for the home agent to begin proxying is when the mobile node sends a Binding Update message to the home agent indicating that it has moved to a new link. The mobile node includes a Secure Proxy Mobility Option into the Binding Update sent to the home agent. The Secure Proxy Mobility Option includes the public keys used in calculating the MCGA, and the encrypted private key received from the home agent for secure proxying. Kempf & Gentry Expires November, 2005 [Page 13] Internet-Draft Secure IPv6 Address Proxying May 2005 The Secure Proxy Mobility Option has the following format: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Public Key Length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Node Public Key (variable) | ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Public Key Length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Node-specific Router Public Key (variable) | ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Encrypted Private Key Length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Encrypted Private Key (variable) | ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type TBA3 Length Two octet suboption length, in units of octets, not including the type and length fields. Public Key Length Two octet field containing the length of the public key generated by the node, in octets. Node Public Key Kempf & Gentry Expires November, 2005 [Page 14] Internet-Draft Secure IPv6 Address Proxying May 2005 Variable length field containing the public key generated by the node. Public Key Length Two octet field containing the length of the node-specific public key generated by the router (home agent), in octets. Node Public Key Variable length field containing the node-specific public key generated by the router (home agent). Encrypted Private Key Length Two octet field containing the length of the encrypted private key, in octets. Encrypted Private Key Variable length field containing the encrypted private key corresponding to the node-specific public key generated by the router. 7. Security Considerations Since MCGAs and secure proxying are an extension of RFC 3971 and 3972, most of the same security considerations apply. The router SHOULD add some additional bytes to the private key before encrypting it, to increase the size and reduce the risk of dictionary attack. Note that the SEND messages have been formatted so that an attacker can't tell whether the Neighbor Advertisement defending an address comes from the proxy or the original address-generating node. However, the attacker may be able to deduce whether or not the node is on the home link from other information in the signaling, for example, by comparing the link layer address to the link layer address of the home agent. To achieve complete location privacy, the link must be configured so that an attacker cannot use the link layer address of the home agent for this purpose. Kempf & Gentry Expires November, 2005 [Page 15] Internet-Draft Secure IPv6 Address Proxying May 2005 8. IANA Considerations IANA SHALL set up a new registry as part of the SEND registry, the CGA Parameters Suboption registry. TBA1 SHALL be assigned by IANA from the CGA Parameters Suboption registry. TBA2 SHALL be assigned by IANA from the IPv6 Neighbor Discovery Option registry. TBA3 SHALL be assigned by IANA from the Mobile IPv6 Mobility Options registry. 9. References 9.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Arkko, J., Kempf, J., Zill, B., and Nikander, P., "SEcure Neighbor Discovery (SEND)", RFC 3971, March, 2005. [3] Narten, T., Nordmark, E., and Simpson, W., "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December, 1998. [4] Aurea, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, March, 2005. [5] Johnson, D., Perkins, C., and Arkko, J., "Mobility Support in IPv6", RFC 3775, June, 2004. [6] National Institute of Standards and Technology. FIPS Publication 197: Advanced Encryption Standard (AES). 26 November 2001. [7] "Secure Hash Standard", United States of America, National Institute of Science and Technology, Federal Information Processing Standard (FIPS) 180-1, April, 1993. [8] Rivest, R., Shamir, A., and Tauman, Y., "How to Leak a Secret", Proc. of Asiacrypt 2001, pages 552-565, 2001. Kempf & Gentry Expires November, 2005 [Page 16] Internet-Draft Secure IPv6 Address Proxying May 2005 9.2. Informative References [9] Daley, G., "Securing Proxy Neighbour Discovery Problem Statement", Internet Draft, work in progress. Author's Addresses James Kempf DoCoMo Labs USA 181 Metro Drive Suite 300 San Jose, CA 95110 Email: kempf@docomolabs-usa.com Craig Gentry DoCoMo Labs USA 181 Metro Drive Suite 300 San Jose, CA 95110 Email: cgentry@docomolabs-usa.com 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 Kempf & Gentry Expires November, 2005 [Page 17] Internet-Draft Secure IPv6 Address Proxying May 2005 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. By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 (2004). 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. Kempf & Gentry Expires November, 2005 [Page 18]