One document matched: draft-kempf-cgaext-ringsig-ndproxy-00.txt
CGA Extensions BOF J. Kempf
Internet Draft DoCoMo Labs USA
Expires: Feburary, 2008 August 1, 2007
Intended Status: Proposed Standard
Secure IPv6 Address Proxying using Multi-Key
Cryptographically Generated Addresses (MCGAs)
draft-kempf-cgaext-ringsig-ndproxy-00.txt
Status of this Memo
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 February 1, 2008.
IPR Disclosure Acknowledgement
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.
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 such addresses
Kempf Expires Feburary, 2008 [Page 1]
Internet-Draft Secure IPv6 Address Proxying July 2007
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........6
3.3 Processing Rules for Address-verifying Nodes..........6
3.4 Error Conditions......................................7
3.5 Backward Compatibility with Standard SEND Nodes.......7
4.0 Multi-key CGAs and Ring Signatures.......................8
4.1 Generating and Validating Multi-key CGAs..............8
4.2 Generating and Validating Ring Signatures.............9
5.0 SEND Extensions.........................................10
5.1 CGA Parameters Suboption.............................10
5.2 RST Ring Signature Key Suboption.....................11
5.3 RST Ring Signature Option............................12
6.0 Mobile IPv6 Extensions..................................14
7.0 Security Considerations.................................15
8.0 IANA Considerations.....................................16
9.0 Contributors............................................16
Kempf Expires Feburary, 2008 [Page 2]
Internet-Draft Secure IPv6 Address Proxying July 2007
10.0 References.............................................16
10.1 Normative References................................16
10.2 Informative References..............................17
Author's Addresses..........................................17
Acknowledgment..............................................17
Copyright Notice............................................18
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.
Kempf Expires Feburary, 2008 [Page 3]
Internet-Draft Secure IPv6 Address Proxying July 2007
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-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.
Kempf Expires Feburary, 2008 [Page 4]
Internet-Draft Secure IPv6 Address Proxying July 2007
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 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
Kempf Expires Feburary, 2008 [Page 5]
Internet-Draft Secure IPv6 Address Proxying July 2007
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 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
Kempf Expires Feburary, 2008 [Page 6]
Internet-Draft Secure IPv6 Address Proxying July 2007
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 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.
Kempf Expires Feburary, 2008 [Page 7]
Internet-Draft Secure IPv6 Address Proxying July 2007
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) )
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.
Kempf Expires Feburary, 2008 [Page 8]
Internet-Draft Secure IPv6 Address Proxying July 2007
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);
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)];
Kempf Expires Feburary, 2008 [Page 9]
Internet-Draft Secure IPv6 Address Proxying July 2007
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.
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:
Kempf Expires Feburary, 2008 [Page 10]
Internet-Draft Secure IPv6 Address Proxying July 2007
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:
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 Expires Feburary, 2008 [Page 11]
Internet-Draft Secure IPv6 Address Proxying July 2007
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Key Hash +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Digital Signature (variable) +
| |
~ ~
| |
Kempf Expires Feburary, 2008 [Page 12]
Internet-Draft Secure IPv6 Address Proxying July 2007
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ 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.
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.
Kempf Expires Feburary, 2008 [Page 13]
Internet-Draft Secure IPv6 Address Proxying July 2007
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 Expires Feburary, 2008 [Page 14]
Internet-Draft Secure IPv6 Address Proxying July 2007
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.
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
Kempf Expires Feburary, 2008 [Page 15]
Internet-Draft Secure IPv6 Address Proxying July 2007
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 Contributors
The author would like to acknowledge the contribution of Craig
Gentry, Stanford University, during the initial research phase
of this work when this document was discussed in the IRTF
MOBOPTS research group. Craig developed the ring signature
version of RSA described in Section 4.0.
10.0 References
10.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.
Kempf Expires Feburary, 2008 [Page 16]
Internet-Draft Secure IPv6 Address Proxying July 2007
[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] "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.
10.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
3240 Hillview Avenue
Palo Alto, CA
94304
Email: kempf@docomolabs-usa.com
Acknowledgment
Funding for the RFC Editor function is currently provided by
the Internet Society.
Disclaimer of Validity:
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
Kempf Expires Feburary, 2008 [Page 17]
Internet-Draft Secure IPv6 Address Proxying July 2007
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.
Copyright Notice
Copyright (C) The IETF Trust (2007).
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.
Disclaimer
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, THE IETF TRUST 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.
Kempf Expires Feburary, 2008 [Page 18]
| PAFTECH AB 2003-2026 | 2026-04-23 10:43:48 |