[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: 00 01 02

     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]
     

Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/