Mobility Optimizations RG J. Kempf Internet Draft C. Gentry Expires: November, 2005 DoCoMo Labs USA May 16, 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, 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 November 16, 2005. Copyright Notice Copyright (C) The Internet Society (2005). 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 multiple 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.0 Introduction..................................................3 2.0 Existing Work.................................................4 3.0 Extension to SEND for Secure Proxying.........................5 3.1 Processing Rules for Routers...............................5 3.2 Processing Rules for Address-configuring Nodes.............5 3.3 Processing Rules for Address-verifying Nodes...............6 3.4 Error Conditions...........................................6 3.5 Backward Compatibility with Standard SEND Nodes............7 4.0 Multi-key CGAs and Ring Signatures............................7 4.1 Generating and Validating Multi-key CGA Addresses..........7 4.2 Generating and Validating Ring Signatures..................8 5.0 SEND Extensions...............................................9 5.1 CGA Parameters Suboption...................................9 5.2 RSA Ring Signature Key Suboption..........................10 5.3 RSA Ring Signature Option.................................11 6.0 Mobile IPv6 Extensions.......................................12 7.0 Security Considerations......................................14 8.0 IANA Considerations..........................................14 9.0 References...................................................15 9.1 Normative References......................................15 9.2 Informative References....................................15 Author's Addresses...............................................16 Kempf & Gentry Expires November, 2005 [Page 2] Internet-Draft Secure IPv6 Address Proxying May 2005 Intellectual Property Statement..................................16 Disclaimer of Validity...........................................17 Copyright Statement..............................................17 Acknowledgment...................................................17 1.0 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 in a way that does not disclose whether the node is on or off the link. 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.0 presents processing rules for routers and nodes capable of supporting secure proxying using mulit-key CGAs. In Section 4.0 , the two Kempf & Gentry Expires November, 2005 [Page 3] Internet-Draft Secure IPv6 Address Proxying May 2005 important cryptographic components of the protocol are discussed - multi-key CGAs and ring signatures. Section 5.0 contains the message format for extensions to implement multi-key CGAs and ring signatures for SEND. Section 6.0 discusses Mobile IPv6 home agent proxying as an example of how secure proxying is triggered. In Section 7.0 , security considerations are discussed and in Section 8.0 are presented, 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.0 may be sufficient, as long as there is no strong requirement for location privacy. 2.0 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 Kempf & Gentry Expires November, 2005 [Page 4] Internet-Draft Secure IPv6 Address Proxying May 2005 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 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 and have access to it 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.0 Extension to SEND for Secure Proxying 3.1 Processing Rules for Routers The actual trigger for a router to begin secure proxying depends on what protocol is being used. Section 6.0 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 public key it generated and the router's certified public key that was used in generating the multi-key CGA. The router checks the certified public key, and if the key does not belong to the router, it returns an error indication to the node. The router MAY perform insecure proxying in this case. When the router is called upon to proxy, it uses the procedure described in Section 3.2 which is the same procedure used by the address-configuring node. Note that when proxying, 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 A node capable of secure proxying MUST first obtain the router's certificate and certified public key, using DCS/DCA as described in RFC 3971, or by some other means. Typically, a SEND node will obtain the router's delegation chain and certificate in the process of verifying the signature on the Router Advertisement. Kempf & Gentry Expires November, 2005 [Page 5] Internet-Draft Secure IPv6 Address Proxying May 2005 After checking the signature on the Router Advertisement in accordance with RFC 3971 to make sure it is valid, the node generates a multi-key CGA as described in Section 4.1 , using an RSA public key that it generates and the router's certified public key. The node records the public/private key it generated, and the certified public key for use in secure Neighbor Discovery. 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 (see Section 5.3) 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 router's certified public key is inserted into the Ring Signature Public Key Field of the RSA Ring Signature Key Suboption. 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 . The public keys from CGA Parameters Option Public Key Field and the RSA Ring Signature Key Suboption are used to verify the ring signature. 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. Kempf & Gentry Expires November, 2005 [Page 6] Internet-Draft Secure IPv6 Address Proxying May 2005 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. Therefore, multi-CGA capable nodes MUST 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.0 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 the single 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. Kempf & Gentry Expires November, 2005 [Page 7] Internet-Draft Secure IPv6 Address Proxying May 2005 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). 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). Kempf & Gentry Expires November, 2005 [Page 8] Internet-Draft Secure IPv6 Address Proxying May 2005 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: 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.0 SEND Extensions 5.1 CGA Parameters Suboption The CGA Parameters Suboption format is a general format used to add additional fields to the CGA Parameters Option defined in RFC 3972. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Kempf & Gentry Expires November, 2005 [Page 9] Internet-Draft Secure IPv6 Address Proxying May 2005 | Suboption Data ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type Suboption type code, assigned by IANA. Length 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 is a CGA Parameters Suboption that is used to convey an additional public key and possibly an encrypted private key, for use in generating a multi-key CGA and ring signature. 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 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + + | Router's Certified Public Key (variable) | ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Kempf & Gentry Expires November, 2005 [Page 10] Internet-Draft Secure IPv6 Address Proxying May 2005 Type TBA1 Length Two octet suboption length, in units of octets, including the type and length fields. Public Key Length Two octet field containing the length of the public key, in octets. Router's Certified Public Key Variable length field containing the certified public key from the proxying router. 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 11] 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 keys 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 and RSA Ring Signature Key Suboption carried in the CGA Option. Its purpose is to associate the signature to a set of keys known by the receiver. Such a key can either be stored in the certificate cache of the receiver or be received in the CGA Option in the same message. Digital Signature A variable-length field containing a PKCS#1 v1.5 format signature, constructed as described in Section 4.2 by using the sender's private key and the public keys in the CGA Parameters Option. 6.0 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 Kempf & Gentry Expires November, 2005 [Page 12] Internet-Draft Secure IPv6 Address Proxying May 2005 Secure Proxy Mobility Option includes the public keys used in calculating the MCGA. If the key included in the Router's Certified Public Key Field of the Secure Proxy Mobility Option does not match the home agent's certified public key, the home agent SHOULD return an TBA4 status code in the Binding Acknowledgement, but SHOULD NOT reject the binding. 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 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + + | Router' Certified Public Key (variable) | ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Encrypted Private Key Length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Encrypted Router Private Key (variable) | ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type TBA3 Length Kempf & Gentry Expires November, 2005 [Page 13] Internet-Draft Secure IPv6 Address Proxying May 2005 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 Variable length field containing the public key generated by the node. Public Key Length Two octet field containing the length of the router's certified public key (home agent), in octets. Router's Certified Public Key Variable length field containing the router's certified public key (home agent). 7.0 Security Considerations Since MCGAs and secure proxying are an extension of RFC 3971 and 3972, the same security considerations apply. 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. 8.0 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. Kempf & Gentry Expires November, 2005 [Page 14] Internet-Draft Secure IPv6 Address Proxying May 2005 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. TBA4 SHALL be assigned by IANA from the Mobile IPv6 Binding Update status codes greater than 128. 9.0 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. 9.2 Informative References [9] Daley, G., "Securing Proxy Neighbour Discovery Problem Statement", Internet Draft, work in progress. Kempf & Gentry Expires November, 2005 [Page 15] Internet-Draft Secure IPv6 Address Proxying May 2005 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 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 Kempf & Gentry Expires November, 2005 [Page 16] Internet-Draft Secure IPv6 Address Proxying May 2005 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 17]