Internet DRAFT - draft-kempf-mobopts-ringsig-ndproxy
draft-kempf-mobopts-ringsig-ndproxy
Mobility Optimizations RG J. Kempf
Internet Draft C. Gentry
Expires: March, 2006 DoCoMo Labs USA
August 22, 2005
Secure IPv6 Address Proxying using Multi-Key Cryptographically
Generated Addresses (MCGAs)
draft-kempf-mobopts-ringsig-ndproxy-02.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 January 22, 2006.
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 March, 2006 [Page 1]
Internet-Draft Secure IPv6 Address Proxying August 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 from a group of nodes but which
requires the public keys of all group members 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..............................................10
5.1 CGA Parameters Suboption..................................10
5.2 RSA Ring Signature Key Suboption..........................10
5.3 RSA Ring Signature Option.................................11
6.0 Mobile IPv6 Extensions.......................................13
7.0 Security Considerations......................................14
8.0 IANA Considerations..........................................15
9.0 References...................................................15
9.1 Normative References......................................15
9.2 Informative References....................................16
Author's Addresses...............................................16
Kempf & Gentry Expires March, 2006 [Page 2]
Internet-Draft Secure IPv6 Address Proxying August 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 assurance to nodes on an IPv6 link 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 which allows a node to construct a CGA such that the CGA can
be securely proxied by another node. The proxying is done in a way
that does not disclose whether the address owner 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 [8]. Section 3.0 presents processing rules for
routers and nodes capable of supporting secure proxying using multi-
Kempf & Gentry Expires March, 2006 [Page 3]
Internet-Draft Secure IPv6 Address Proxying August 2005
key CGAs. In Section 4.0 , the two important cryptographic components
of the protocol are discussed - multi-key CGAs and ring signatures.
Section 5.0 contains the message formats for the SEND extensions to
implement multi-key CGAs and ring signatures. 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 IANA considerations are presented, concluding the
paper.
Note that the MCGA technique requires a node to know at the time it
first comes up 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 [8], 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.
Kempf & Gentry Expires March, 2006 [Page 4]
Internet-Draft Secure IPv6 Address Proxying August 2005
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
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 node
owning the address. 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
Kempf & Gentry Expires March, 2006 [Page 5]
Internet-Draft Secure IPv6 Address Proxying August 2005
the router's delegation chain and certificate in the process of
verifying the signature on the Router Advertisement.
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 RST Ring Signature Option (see Section 5.3 ) instead of a
standard SEND RSA Signature Option, and the node includes a RST 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 RST 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
RST Ring Signature Option and a CGA Parameters Option containing an
RST 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 RST Ring Signature Key Suboption are used to
verify the ring signature.
Prior to verifying the CGA or signature, the verifying node MUST
check that the router public key in the CGA Parameters Option matches
a certified public key from a router on the link. This step assures
that the keys used in signing the signature are both legitimate
members of the group, which in this case consists of the node owning
the address and a certified router on the link. If this step is not
taken, an attacker not authorized to route can sign a message with
its own key and the victim node's public key, then claim to securely
proxy the address on the victim's behalf.
3.4 Error Conditions
If a multi-CGA capable node receives a message with an RST Ring
Signature Option but the CGA Parameters Option has no RST Ring
Kempf & Gentry Expires March, 2006 [Page 6]
Internet-Draft Secure IPv6 Address Proxying August 2005
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
RST Ring Signature Key Suboption, the node SHOULD ignore the RST 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 RST 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.
An indication from the router whether it supports multi-key CGAs and
secure proxying could foster better backward compatibility. A future
version of this document may define some means to indicate this. If a
multi-key CGA capable node knows that the router does not support
multi-key CGAs, it can fall back to using standard RFC 3971 SEND on
the link immediately.
4.0 Multi-key CGAs and Ring Signatures
4.1 Generating and Validating Multi-key CGAs
Multi-key CGAs 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) )
Kempf & Gentry Expires March, 2006 [Page 7]
Internet-Draft Secure IPv6 Address Proxying August 2005
where | is the bit-wise concatenation function, SHA1() is the SHA1
cryptographic hash function [6], 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 both steps, instead of calculating the has
values directly from the CGA Parameters Option, the individual fields
of the CGA Parameters Option are used in the algorithms for Hash1 and
Hash2 in Section 4. As for a generating node, concat-val is used
instead of the public key.
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 (RST) ring signature scheme [7].
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);
Kempf & Gentry Expires March, 2006 [Page 8]
Internet-Draft Secure IPv6 Address Proxying August 2005
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:
y(i) = E(k)**-1(y(i+1) ~ E(k)**-1(... y(n)~ 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.
Kempf & Gentry Expires March, 2006 [Page 9]
Internet-Draft Secure IPv6 Address Proxying August 2005
The above 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 RST Ring Signature Key Suboption
The RST Ring Signature Key Suboption is a CGA Parameters Suboption
that is used to convey a certified router public key, for use in
generating a multi-key CGA and ring signature. The RST Ring Signature
Key Suboption has the following format:
Kempf & Gentry Expires March, 2006 [Page 10]
Internet-Draft Secure IPv6 Address Proxying August 2005
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) |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 RST Ring Signature Option
The RST 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
Kempf & Gentry Expires March, 2006 [Page 11]
Internet-Draft Secure IPv6 Address Proxying August 2005
+ +
| |
+ Key Hash +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Digital Signature (variable) +
| |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Padding +
| |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 [6] 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 RST 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.
Kempf & Gentry Expires March, 2006 [Page 12]
Internet-Draft Secure IPv6 Address Proxying August 2005
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 first sends a Binding Update message to the home agent to bind
its home address to a new care-of address. 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. 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Node Public Key Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
+ +
| Node Public Key (variable) |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HA Public Key Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
+ +
| HA Certified Public Key (variable) |
Kempf & Gentry Expires March, 2006 [Page 13]
Internet-Draft Secure IPv6 Address Proxying August 2005
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
TBA3
Length
Two octet suboption length, in units of octets, not including the
type and length fields.
Reserved
A 1 octet field reserved for future use. The value MUST be
initialized to zero by the sender, and MUST be ignored by the
receiver Public Key Length
Node 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.
HA Public Key Length
Two octet field containing the length of the home agent's
certified public key, in octets.
HA Certified Public Key
Variable length field containing the home agent's certified public
key.
7.0 Security Considerations
Since MCGAs and secure proxying are an extension of RFC 3971 and
3972, the same security considerations apply.
Kempf & Gentry Expires March, 2006 [Page 14]
Internet-Draft Secure IPv6 Address Proxying August 2005
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.
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.
Kempf & Gentry Expires March, 2006 [Page 15]
Internet-Draft Secure IPv6 Address Proxying August 2005
[6] "Secure Hash Standard", United States of America,
National Institute of Science and Technology, Federal
Information Processing Standard (FIPS) 180-1, April
1993.
[7] Rivest, R., Shamir, A., and Tauman, Y., "How to Leak a Secret",
Proc. of Asiacrypt 2001, pages 552-565.
9.2 Informative References
[8] 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.
Kempf & Gentry Expires March, 2006 [Page 16]
Internet-Draft Secure IPv6 Address Proxying August 2005
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
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 March, 2006 [Page 17]
