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

Versions: 00 01 02 03

Internet Engineering Task Force                            G. Montenegro
INTERNET DRAFT                                           C. Castelluccia
                                                           July 20, 2001
                     SUCV Identifiers and Addresses
                      draft-montenegro-sucv-01.txt

Status of This Memo

   This document is an Internet-Draft and is in full conformance
   with all provisions of Section 10 of RFC 2026.

   Comments should be submitted to the HIP and Mobile IP mailing lists
   at hipsec@mail.freeswan.org and mobile-ip@sunroof.eng.sun.com,
   respectively.

   Distribution of this memo is unlimited.

   This document is an Internet-Draft.  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.

Abstract

   This document addresses the identifier ownership problem.  It
   does so by using characteristics of Statistic Uniqueness and
   Cryptographic Verifiability (SUCV) of certain entities which
   this document calls SUCV Identifiers (SUCV ID's).  This note
   also proposes using these SUCV characteristics in related
   entities called SUCV Addresses in order to severely limit
   certain classes of denial of service attacks and hijacking
   attacks. SUCV addresses are particularly applicable to solve the
   'address ownership' problem that severely undermines confidence
   in mechanisms like Binding Updates in Mobile IP for IPv6.





Expires January 20, 2001                                        [Page 1]


INTERNET DRAFT       SUCV Identifiers and Addresses            July 2001


Table of Contents

1.0 Introduction ..................................................    3
2.0 Related Issues ................................................    3
   2.1 Address Ownership ..........................................    3
   2.2 Purpose Built Keys [PBK] ...................................    4
3.0 Overview of the Proposal ......................................    4
4.0 Statistical Uniqueness and Cryptographic Verifiability
(SUCV) ............................................................    5
   4.1 SUCV ID's ..................................................    6
   4.2 SUCV ID's versus Addresses .................................    7
   4.3 SUCV Addresses .............................................    8
   4.4 Hash ID Size Considerations ................................    8
5.0 SUCV Derivation and Formats ...................................    9
   5.1 Generating SUCV ID's, HID's and Addresses ..................   10
   5.2 HIP IPv6 Accomodation Mode .................................   10
6.0 Use of SUCV Addresses for Mobile IPv6 .........................   12
   6.1 Protocol Overview ..........................................   13
   6.2 Security Analysis ..........................................   15
      6.2.1 Intruder-in-the-middle attacks ........................   15
      6.2.2 Denial-of-Service Attacks .............................   18
7.0 Future Work ...................................................   19
   7.1  SUCV Sublayer .............................................   19
   7.2  Applications to Micro-Mobility ............................   20
8.0 Security Considerations .......................................   20
9.0 Conclusions ...................................................   21
References ........................................................   21
Authors' addresses ................................................   22























Expires January 20, 2001                                        [Page 2]


INTERNET DRAFT       SUCV Identifiers and Addresses            July 2001


1.0 Introduction

   This document addresses the identifier ownership problem
   [ADDROWN] by using characteristics of Statistic Uniqueness and
   Cryptographic Verifiability (SUCV) of certain entities which
   this document calls SUCV Identifiers (SUCV ID's).  This note
   also proposes using these SUCV characteristics in related
   entities called SUCV Addresses in order to severely limit
   certain classes of denial of service attacks and hijacking
   attacks. SUCV addresses can solve the 'address ownership'
   problem that severely undermines confidence in mechanisms like
   Binding Updates in Mobile IP for IPv6.


2.0 Related Issues



2.1 Address Ownership

   [ADDROWN] argues that there is a fundamental problem in handling
   operations like Binding Updates (BU's) in Mobile IP for IPv6
   [MIPv6], source routing, etc) that allows hosts to modify how
   other hosts route packets to a certain destination.  The problem
   is that these operations can be misused by rogue nodes to
   redirect traffic away from its legitimate destination.
   Authentication does not solve this problem. Even if a node
   unequivocally identifies itself, this has no bearing on its
   rights to modify how packets to any given address are routed.
   This is true even if its packets currently seem to emanate from
   the address in question. This last point is obvious if one
   considers DHCP leased addresses. It is imperative not to allow
   any node to redirect traffic for a DHCP address for which it
   held a valid lease previously. This would allow it to hijack
   traffic meant for the current valid user of the address in
   question. Hence, protection against hijacking of valid addresses
   requires cryptographic authorization for operations that modify
   routing (BU's, source routing, etc). One way to show
   authorization is by showing that the requesting node owns the
   address for which routing information is being altered. Quoting
   [ADDROWN]:

      Currently there exists no specified mechanism for proving
      address ownership in Internet-wide scale.







Expires January 20, 2001                                        [Page 3]


INTERNET DRAFT       SUCV Identifiers and Addresses            July 2001


2.2 Purpose Built Keys [PBK]

   Purpose built keys [PBK] have been proposed as a foundation for
   solving scaling and cost concerns associated with some uses of
   BU's [MIPv6]. It has also been suggested that such keys [PBK]
   can solve the authorization problem that is at the heart of the
   address ownership issue.

   The proposal is succintly to:

   1. Generate a temporary public/private pair

   2. Generate an EID = hash(public component)

       a. the initiator sends EID to responder along with initial
          protocol exchanges.

       b. the initiator sends public component to responder along
          with subsequent exchanges.

   3. The initiator sends the BU and its EID signed with its
      private key to the responder.

   Notice that the exchange at step 2 must be secure in order to
   avoid intruder-in-the-middle attacks, but it is an improvement
   over cookies.

   Several problems linger:

   1. This does NOT really address the address ownership problem of
      any publicly routable addresses

   2. It is not specified how the EID and public component of the
      PK are sent by the initiator to the responder

   3. Preventing or limiting hijacking and intruder-in-the-middle
      attacks depend on this sequence if not clearly specified.

   By the time the issues are worked out, [PBK] will look very
   similar to an existing proposal [HIPARCH].  Because of this, it
   may be simpler to base a solution on HIP.


3.0 Overview of the Proposal

   We assume that we have a network in which the nodes inherently
   distrust each other, and in which a global or centralized PKI
   (Public Key Infrastructure) or KDC (Key Distribution Center) is



Expires January 20, 2001                                        [Page 4]


INTERNET DRAFT       SUCV Identifiers and Addresses            July 2001


   not available.

   The goal is to arrive at some fundamental assumptions about
   trust on top of which one can build some useful peer-to-peer
   communication using opportunistic security.

   But in such a network, is there a default rule we can follow
   safely?  We posit this is it:

      Default Trust Rule:

         Redirect operations are allowed only with addresses which
         are bound (via a cryptographically sound binding) to the
         requesting entity.

   The above rule (to be refined later) constitutes the only rule
   that operates by default, allowing any other more dangerous
   operation only if authorized by strong cryptographic
   mechanisms.

   Furthermore, we suggest it be based on HIP for the following
   reasons:

   - HIP provides the types of identifiers required by the above
     rule.

   - The HIP protocol handshake [HIPPROT] is a foundation for a
     very solid sequence resistant to denial-of-service attacks.

   Nevertheless, this document proposes a specific use or 'profile'
   of HIP as applied to environments without DNS (particularly
   secure DNS), a centralized PKI, or a Key Distribution Center.
   Rather, we favor the opportunistic mode in HIP [HIPIMPL], and
   adapt and apply it to Mobile IPv6 (as detailed below). In order
   not to hinder deployment, a primary consideration has been to
   minimize the modifications of existing protocols and network
   support.

   Furthermore, at the end of this document we note that there are
   other areas that can benefit from similar adaptations of HIP's
   opportunistic mode. Their details, however, are left for further
   exploration.


4.0 Statistical Uniqueness and Cryptographic Verifiability (SUCV)

   In the absence of a third party, how does a principal prove
   ownership of its identity to a peer?



Expires January 20, 2001                                        [Page 5]


INTERNET DRAFT       SUCV Identifiers and Addresses            July 2001


   Notice that usual owner verification relies on a third party to
   provide this function.

   In this proposal, the principal self-generates a private/public
   key pair. It uses material obtained via a one-way hash of the
   public key as its identity (or as part of its address) and
   proves its ownership by signing it with its private key. The
   recipient verifies the signature, and, consequently, the
   ownership of the identity.


4.1 SUCV ID's

   It is much more practical for protocols to use fixed length
   identifiers (representations of identities). Because of this, we
   do not use the public key itself as the identifier, but its hash
   (as in HIP).

   These identifiers have a strong cryptographic binding with their
   public components (of their private-public keys). This is
   exactly the purpose that certificates have.  Let's call them
   Statistically Unique Cryptographically Verifiable ID's, or SUCV
   ID's.

   Because of this, once a CN obtains information about one of
   these identifiers, it has a strong cryptographic assurance about
   which entity created it. Not only that, it knows that this
   identifier is owned and used exclusively by only one node in the
   universe: its peer in the current exchange. Thus, it is safe to
   allow that peer to effect changes (via BU's, for example) on how
   this address or identifier is routed to. Notice that with
   publically routable addresses, this assurance is much harder to
   arrive at, given that the address may be 'loaned' to (not owned
   by) the peer in question, perhaps thanks to the good service of
   a DHCP server.

   Despite the fact that currently there is no way to prove address
   ownership in the Internet, these considerations lead to the
   following fundamental assumption:

      Default Trust Rule

         Redirect operations are only allowed to affect routing for
         entities which have the SUCV property.

   The above constitutes perhaps the only rule that operates by
   default, allowing any other more dangerous operation only if
   authorized by strong cryptographic mechanisms



Expires January 20, 2001                                        [Page 6]


INTERNET DRAFT       SUCV Identifiers and Addresses            July 2001


4.2 SUCV ID's versus Addresses

   What should one use: pure identifiers with no routing
   significance or addresses?

   For example, in the Mobile IPv6 case, a node starts using its
   home address, and issues binding updates as it moves.

   With a home address that is not an SUCV ID it is never evident
   to the CN that whoever was sitting on this address actually owns
   it. At the very most, the mobile node can prove that at some
   point it was sitting on a certain address, and later it can
   prove it is still the same node, but now sitting on another
   address.

   But it cannot prove ownership.  Ignoring this subtle distinction
   leads to DOS and hijacking attacks.

   Problems may also arise because of honest mistakes in
   configuration. For example, say node A was originally sitting on
   CoA, and then moved on to CoA'. Suppose it then asks its CN's
   to redirect traffic to CoA'. In the meanwhile, the original
   CoA may have been assigned to another node B, perhaps by the
   DHCP server that rightfully 'owns' that address. The result is
   that now traffic meant for B has been redirected to A at its new
   location.

   Relying on ingress filtering may limit the risk, but
   essentially, the only way for a node to prove ownership of an
   identifier (in the absence of any other centralized or global
   mechanism), is for it to prove that it created this
   statistically unique series of bits.

   The intent is to use an identifier instead of an address.  Using
   identifiers that satisfy the SUCV conditions outlined above, it
   is possible to gain the tremendous advantage that other nodes
   can safely believe the node when it claims ownership of that
   identifier.  Hence they can safely heed its redirects when it
   says that it is now available at some different CoA (and later
   at another).  Furthermore, you do not rely on ingress filtering
   to limit exposure.

   A major advantage to using an address is that the data traffic
   need not carry extra information in the packet to guarantee
   proper delivery by routing. Because of this it is advantageous
   to create addresses that are both routable and satisfy the SUCV
   property: SUCV addresses.




Expires January 20, 2001                                        [Page 7]


INTERNET DRAFT       SUCV Identifiers and Addresses            July 2001


   Another advantage to using an SUCV address is that this address
   can be registered in the DNS and the host does not have to worry
   about communicating securely this identifier to its correspondent
   node. The correspondent node will just get it from the DNS.


4.3 SUCV Addresses

   In IPv6, addresses that satisfy the SUCV property may be
   obtained as follows (this is very similar to [CAM]):

   - use the top 64 bits from your routing prefix (as in rfc3041)

   - define the bottom 64 bits as an SUCV ID (called the HID or
     'hash' ID). Use these 64 bits instead of the 'interface
     identifier' in IPv6 [IPV6ADDR].

   The resultant 128 bit field is an identifier that is also
   routable, avoiding the need for taking extra space in the packet
   by sending routing options. Notice that even after moving, it is
   possible to reuse the 'HID' portion of the address with the new
   network prefix at the new location. Thus it is possible to reuse
   the HID with different CoA's.

   Nevertheless, by snooping on binding updates, it is possible for
   an attacker to learn the original network prefix used by the
   home address. This tells an eavesdropper where this home address
   began to be used, and to which network it belongs, potentially
   important information.

   On the other hand, if you use a 'pure' SUCV ID (without any
   routing significance), then your packets will always need extra
   information somewhere to assure they are routed properly.
   Eavesdroppers may still know where that identity is at any
   particular point in time. Nevertheless, this is a tangible
   improvement over always including a valid 64 bit prefix, as this
   divulges information about an identity's topological
   connectivity or under what prefix a given identity began to be
   used.

   For further details on SUCV address please refer to section
   5.0.


4.4 Hash ID Size Considerations

   In SUCV addresses, one of the lower 64 bits is reserved as the
   local/universal bit (the 'u' bit), so only 63 bits are actually



Expires January 20, 2001                                        [Page 8]


INTERNET DRAFT       SUCV Identifiers and Addresses            July 2001


   usable as a hash.

   Suppose the hash function produces an n-bit long output. If we
   are trying to find some input which will produce some target
   output value y, then since each output is equally likely we
   expect to have to try 2^(n-1) possible input values on average.

   On the other hand, if we are worried about naturally ocurring
   SUCV address duplications, then then by the birthday paradox we
   would expect that after trying 1.2*2^n/2 possible input values
   we would a 50% probability of collision [BIRTH].

   So if n=63, you need a population of 1.2*2^31.5 i.e. 3.64*10^9
   nodes on average before any two produce duplicate addresses.
   This is acceptable especially if you consider that this
   collision is actually harmfull only if the 2 hosts (that
   collide) are in the same site (i.e.  they have the same 64 bit
   prefix), and have the same correspondent nodes.  This is very
   unlikely.  Additionally, assuming the collision is not
   deliberate the duplicate address detection (DAD) will detect
   it.

   If an attacker wishes to impersonate a given SUCV address, it
   must attempt 2^62 (i.e. approximately 4.8*10^18) tries to find a
   public key that hashes to this SUCV address.  If the attacker
   can do 1 million hashes per second it will need 142,235 years.
   If the attacker can hash 1 billion hashes per second it will
   still need 142 years

   If we consider that the SUCV Addresses are renewed every 24
   hours (as suggested in RFC3041), an attacker would then have to
   to hash 5.3*10^13 hashes/second in order to be able to find a
   public key that hashes to the SUCV HID of a given host...

   Note that the previous analysis only considers the cost of
   computing the hash of the public key. Prior to this step, an
   attacker must also generate a valid (public, private) key pair.
   This is also a very computionally expensive operation.

   As a conclusion SUCV addresses as used in this document provide
   more than enough security.


5.0 SUCV Derivation and Formats

   This section describes how to generate an SUCV ID (128 bits) and
   SUCV HID (64 bits). It also defines extensions to HIP formats
   for SUCV support.



Expires January 20, 2001                                        [Page 9]


INTERNET DRAFT       SUCV Identifiers and Addresses            July 2001


5.1 Generating SUCV ID's, HID's and Addresses

   First of all, the node generates a public/private key pair.
   Then we define the required quantities as:

   128-bit SUCV Identifier:

      sucvID = prfID(PublicKey, k)

   64-bit SUCV Host ID (HID):

      sucvHID = prfHID(PublicKey, j)

   128-bit IPv6 SUCV Address:

      sucvADDR = 64-bitPrefix + sucvHID

   Where:

      k and j = 16 bit counters

      prfID = least significant 128 bits of:
                SHA-1 hash of the PublicKey concatenated with k.

      prfHID = least significant 64 bits of:
                SHA-1 hash of the PublicKey concatenated with j,
                with bit 6 (the left-most bit is numbered 0) set to
                0.  This creates an interface identifier with local
                significance.

      PublicKey = public key host identity as defined in HIP

   The counter is used to generate new SUCV ID's and Addresses
   from the same public/private key pair.


5.2 HIP IPv6 Accomodation Mode

   Using these ID's or addresses depends on also communicating
   safely the SUCV portion, and this, in turn is dependent on the
   packet sequencing, etc. Given that HIP includes mechanisms and
   detailed considerations in this regard (protection against
   replay, DOS and MITM attacks), our proposed solution is based
   heavily on HIP [HIPARCH, HIPPROT, HIPIMPL].

   To obtain an IPv6 SUCV address, we define a HIT-64 format and
   use its lower 64 bits to form the relevant IPv6 addresses (this
   constitutes HIP's IPv6 accomodation mode). So, for example, the



Expires January 20, 2001                                       [Page 10]


INTERNET DRAFT       SUCV Identifiers and Addresses            July 2001


   HIT-64 is used to form global aggregatable addresses which start
   thus [IPV6ADDR]:

      Aggregatable Global Unicast Addresses 001

   As well as to derive link-local and site-local addresses which
   start thus:

      Link-Local Unicast Addresses          1111 1110 10
      Site-Local Unicast Addresses          1111 1110 11

   The HIT-64 format (section 5.2 of [HIPARCH]) is defined as
   follows:

   - first 64 bits:
      - Bit 0 is one
      - HAA field (next 63 bits) formed as follows:
         - RAA: 23 bits of registered assigning authority assigned
           by ICANN (suggested value: 0)
         - RI: 40 bits of  registered identity assigned
           sequentially by the RAA. (suggested value: 0)
   - last 64 bits:
        - sucvHID as defined above
        - used as the interface identifier in IPv6 addresses

   The IPv6 accomodation mode consists in using a HIT-64 to form an
   IPv6 address.

   A HIT-64 derived IPv6 Aggregatable Global Unicast Address
   (RFC2374) is formed as follows:

   - top 64 bits: as per the valid prefix at the link the device is on

   - bottom 64 bits:  interface identifier obtained by taking the
     last 64 bits of the above HIT-64, and setting bit 6 (the
     left-most bit is numbered 0) to 0.  This creates an interface
     identifier with local significance.

   From this IPv6 address, other non-global scope addresses are
   derived. For example,  a node uses the bottom 64 bits to form
   the site-local and link-local addresses on the same prefix
   (link) as the aggregatable global unicast address
   (alternatively, if a non-global address is formed first, it is
   used to form the others). Furthermor, if this address is used in
   conjuction with Mobile IP for IPv6 [MIPV6], the Home Agent uses
   the Prefix Length information within a "home registration"
   binding update to form the corresponding link-local and
   site-local addresses for the Mobile Node, and defend them for



Expires January 20, 2001                                       [Page 11]


INTERNET DRAFT       SUCV Identifiers and Addresses            July 2001


   purposes of Duplicate Address Detection.

   Any of the addresses formed as described above constitute SUCV
   addresses.


6.0 Use of SUCV Addresses for Mobile IPv6

   In Mobile IPv6, a mobile host obtains a new address, a CoA, each
   time it moves. It then registers the binding between its home
   address and its new CoA with its home agent and correspond
   nodes.  Correspondent nodes in posession of such a binding can
   send packets to the mobile node directly at its current CoA.
   Instead, sending packets to the mobile node's home address
   implies sub-optimal routing as they first proceed to the mobile
   node's home link, where they are intercepted by the home agent
   and forwarded to the mobile node's CoA.

   However, the correspond nodes MUST verify that the home address
   actually belongs to the mobile node. Otherwise, an attacker
   could send a binding update with a victim's home address, thus
   redirecting all the victim's packets.

   Additionally, the correspond nodes SHOULD verify that the CoA
   actually belongs to the mobile node.  Otherwise, any host could
   use the address of a victim as its CoA. The packets that were
   initially addressed to the first host will then be sent to the
   victim. Depending on how much traffic this implies, this could
   be used as a denial-of-service attack.

   These attacks can be avoided if, in order to accept and process
   a binding update, a correspond host requires a mobile node to
   prove ownership of its home address and its CoA. If ownership is
   proven, the correspondent node has the assurance that the mobile
   node is not hijacking some other node's address, or that it is
   not directing packets at some other node's address.

   The solution that we propose is that a mobile node uses the
   method describes previously to configure its Home Address and
   its CoA (the same HID and public/private key pair is used for
   the home address and the CoA).

   By verifying the signature and the HID, the correspond host has
   the assurance that the mobile host is not using some other
   node's home address and CoA.

   As described in [MIPPRIV], the use of SUCV Identifier for Mobile
   IPv6 is useful when a mobile node wishes to hide its home



Expires January 20, 2001                                       [Page 12]


INTERNET DRAFT       SUCV Identifiers and Addresses            July 2001


   address. Indeed the home address can reveal a lot of information
   about a mobile node. [MIPPRIV] proposes to use a random
   Temporary Mobile Identifier (TMI) in place of the home address.
   By using a SUCV ID as a TMI, a mobile node will be able to prove
   ownership of the TMI and avoid hijacking attacks.


6.1 Protocol Overview

   The following protocol, SUCVp, has been designed based on the
   following considerations:

   - the goal is to secure binding updates sent by a mobile node to
     an arbitrary correspondent node

   - the protocol should not rely on a third party (i.e. a global
     PKI, central key distribution center, etc), although it could
     use one if available

   - not all nodes need to use SUCV addresses, only those that wish
     their binding updates to be heeded (mobile nodes)

   - not all nodes need to verify the validity of SUCV addresses,
     only those that wish to safely heed binding updates in order
     to populate its binding cache

   The proposed protocol that a mobile host uses to send a BU to its CN
   is the following:

      SUCVp1- The MN sends a SUCVp1 message (just to initiate the
           exchange) to its correspond node.  This message contains a
           Nonce, N1.

           This packet MUST contain a MIP HomeAddress Option
           containing the MN's home address. The source address of
           the packet is the MN's current CoA.

      SUCVp2- The CN replies with a SUCVp2 message that contains the
            following:  N1, Client puzzle request, Diffie-Hellman
            value, Session_Key_lifetime)











Expires January 20, 2001                                       [Page 13]


INTERNET DRAFT       SUCV Identifiers and Addresses            July 2001



            In order to defend against SUCVp1 storms, a host might
            use the same DH value for a period of time.  The SUCVp2
            contains a client puzzle to prevent DoS attacks
            [PUZZLES].  When the MN receives SUCVp2, it verifies
            that the nonce N1 is the same than the one that was
            sent in the SUCVp1.  It then resolves the puzzle
            request and replies with SUCVp3. This message also
            contains a DH value used to generate a session key and
            a suggested lifetime for the generated session key.

            Note that this message is sent to the MN's Home Address
            and forwarded by the Home Agent to the Mobile current
            CoA.  We make the assumption that the MN and the HA
            share a secret key and that the MN has already
            registered its current CoA with the Home Agent.


      SUCVp3- The MN replies with a SUCVp3 message that contains
            the following:  Puzzle reply, the Public key it has
            used to generate its HID, a Diffie-Hellman value, a
            suggested SKey lifetime and a MIPv6 BU.  This message
            MUST be signed by the MN with its private key (the
            public key is used to generate the HID).  The MIPv6 BU
            is possibly encrypted using the session key that is
            derived from the DH value.

            Note that the home address contained in the BU is
            either a SUCV Address or a SUCV Identifier. The CoA is
            either a SUCV Address or a regular address. By using a
            CoA SUCV address, a CN has the assurance the the CoA
            belongs to the MN and has not been stolen.


   When the CN receives the SUCVp3, it can verify the ownership of
   the Home and CoA addresses and authenticate the BU because it is
   signed.

   The MN and CN then derive a session key, SKey, (using the
   ephemeral D-H value), and use it with an authentication
   algorithm (for example HMAC) to authenticate other subsequent BU
   (if any) as it is done in current MIPv6. The lifetime of SKey is
   the minimum of the lifetime suggested by the MN and the CN.

   As long as the MN uses the same HID interface identifier for its
   CoA, it does not have to prove the CoA ownership and BU
   authentication is enough.  If for any reason the MN configures
   its CoA with a new interface identifier, it MUST restart the



Expires January 20, 2001                                       [Page 14]


INTERNET DRAFT       SUCV Identifiers and Addresses            July 2001


   whole protocol (i.e. SUCVp1, SUCVp2, SUCVp3).

   This proposal does not require any previously established
   relationship between the MN and the CN. By using a Home Address
   in SUCV address format (that is, generated by hashing a public
   key), and signing SUCVp2 with the corresponding private key, a
   mobile node can prove ownership of its Home Address.

   Our proposal is heavily inspired by HIP, including its
   protection against denial-of-service attacks. Also, the SUCV
   home addresses as the base mechanism affords it protection
   against man-in-the-middle attacks.  An attacker will not be able
   to redirect the traffic destined to a particular SUCV Home
   Address unless it can find a (public, private) key pair such
   that the hash of the public component is equal to the least
   significant 64 bits in the SUCV Home Address (see Section 6.2).
   This is computationally infeasible (see section 4.4).


6.2 Security Analysis

   In this section we analyse the security of our proposals against
   intruder-in-the-middle and DoS attacks.


6.2.1 Intruder-in-the-middle attacks

   As described in 6.1, a Mobile node uses an SUCV home address
   (and possibly an SUCV CoA), and signs its binding updates with
   its private key An intruder between the mobile node and its
   correspond node could intercept the BU but will not be able to
   alter it (for example with another CoA) without invalidating the
   signature.  Furthermore the intruder won't be able to send a
   fake BU to the correspond node for the MN's home address because
   it does not know the (pub,priv) key pair that was used to
   generate the home address and signs the BU.  The only attack
   that the intruder can perform is to drop the BU sent by the
   mobile host, preventing the correspond host from using the
   direct route to the Mobile node.

   An intruder will NEVER be able to redirect the trafic addressed
   to the MN to another address.

   As described in Section 6.1, a mobile node and its correspond
   node can derive a shared (symetric) key to authenticate the
   subsequent Binding updates sent by the MN.  Note that the first
   BU must be signed by the MN to prove the HID interface
   identifier owernship (used by the home address and possibly by



Expires January 20, 2001                                       [Page 15]


INTERNET DRAFT       SUCV Identifiers and Addresses            July 2001


   the CoA) but then as long as this HID interface identifier does
   not change, BU authentication is enough.

   We propose that the MN and its CN derive the shared key using
   Diffie-Hellman algorithm.

   -  The CN chooses a random secret y and sends g^y mod p to the
      MN (in the DH value field of SUCVp2)

   -  The MN chooses a random secret x and sends g^x mod p to its
      CN (in the DH value field SUCVp3)

   The session key shared by the MN and its CN is then a hash
   digest of g^x.y mod p (g and p are known by the MN and CN).

   Diffie Hellman is know to be vulnerable to the
   "intruder-in-the-middle" attack on un-authenticated DH key
   agreement:

   CN ---> g^y -----> Intruder  ------> g^y'  -----> MN
   CN <--- g^x'-----> Intruder  <------ g^x   <----- MN

   The intruder intercepts g^y sent by the CN and sends g^y' to the
   MN.  The intruder also intercepts g^x sent by the MN and sends
   g^x' to the CN.  As a result, MN shares the key g^x.y' with the
   intruder (it actually thinks that it is sharing this key with
   its CN). The CN shares the key g^x'.y with the intruder (it
   actually thinks that it is sharing this key with the MN). The
   Intruder can then impersonate the MN and the CN.

   In our protocol, SUCVp2 is sent via the home agent. As a result,
   an intruder will be able to intercept only if it is on the
   CN-HA-MN and CN-MN paths (i.e. if it can hear the packets that
   go from the CN to the MN via the Home Agent and the packets that
   are sent directly from the CN to the MN). This condition limits
   significantly the potential attackers.

   However even if the intruder was able to be on both paths
   (CN-HA-MN and MN-CN), the MN signs SUCVp3 (with contains g^x).
   As a result, the intruder can not modify nor replace this
   message.  This only thing that the intruder could do is to
   replace the CN's DH value, g^y, by g^y':

   CN ---> g^y -----> Intruder  ------> g^y'   -----> MN
   CN <--- g^x -----> Intruder  <------ g^x    <----- MN

   MN will then generate the key : g^x.y',  CN the key : g^x.y and
   the intruder the key g^x.y.



Expires January 20, 2001                                       [Page 16]


INTERNET DRAFT       SUCV Identifiers and Addresses            July 2001


   As a result, the MN will authenticate its BU with g^x.y' but the
   CN will not accept them (because is uses g^x.y to verify the
   authentication).  The intruder will be able to verify the MN's
   BU but can not generate any BU that would be accepted by the
   CN.  As a result, the intruder is not able to redirect the MN's
   trafic to an alternate CoA.

   The only thing that the intruder is able to do is to prevent the
   CN from using the direct route to the MN. This might lead to
   some packets losses before the CN realises that the MN has moved
   and that it should use the MN's home address (this leads to
   service degradation not disruption).

   In some case, a MN might request to its CN to acknowledge the
   reception of the BU.  The intruder could actually fool the MN by
   sending an acknowledgement with the CN address as source address
   (note that the intruder could also authenticate this
   acknowlegement since it know the key used by the MN, g^x.y).
   This might confused the MN that has received an acknowledgement
   but keeps receiving the packets from the CN via its home agent
   (note that the same problem exists also will current Mobile IPv6
   specification)!

   Another problem might occur if the MN encrypts its BU with the
   shared key (for privacy reason for example).  The intruder is
   able to decrypt the BU and read its contents.

   One solution to these problems is for the the CN to use an SUCV
   address and to sign SUCVp2 (the message that contains the DH
   value).  Then, the intruder will not be able to substitute g^y
   by g^y'.

   The previous security analysis shows that the protocol described
   in Section 6.1 prevents any intruders from redirecting the
   traffic addressed to a mobile host's home address and
   consequently provides the minimal Mobile IP security requirement
   [MIPv6SecReq].  An intruder can really be harmful if (1) it is
   able to find a public/private key that hash to the MN's HID
   (this is very difficult) and (2) it can hear the packets that go
   from the CN to the MN via the HA and the packets that go from
   the CN to the MN.

   If additional security is required, SUCV addresses should be
   also used by the CN. This probably means that a 5 messages
   protocol, such as "opportunistic" HIP should have to be used
   between the MN and the CN (see Section 7.1)...





Expires January 20, 2001                                       [Page 17]


INTERNET DRAFT       SUCV Identifiers and Addresses            July 2001


6.2.2 Denial-of-Service Attacks

   Denial-of-service (DOS) attacks that exhaust a host resource
   (memory and computional resources) is a major security threat on
   the Internet.  In the section we study the behaviors of the
   protocol described in Section 6.1 against  DoS attacks.

   SUCVp1 storm:

      Malicious hosts, could try to attack a host, by sending a
      storm of SUCVp1 messages. We prevent this potential attack as
      follows:

      -  when receiving a SUCVp1, a host does not create any state
         and replies with a constant message (SUCVp2) that contains
         a client puzzle [PUZZLES].

      -  An host only creates a state only if it receives a valid
         puzzle reply to its puzzle request (in SUCVp3).

   SUCVp2 storm:

      Malicious host could try to attack a host by sending a storm
      of SUCVp2 messages. We prevent this attack by inserting a
      nonce, N1, in the SUCVp1.  If a host receives a SUCVp2 with a
      nonce N1 that is not equal to the nonce N1 that it has set in
      the initial SUCVp1, this SUCVp2 must be rejected.

      Note that an intruder (between the MN and its CN) could
      intercept the SUCVp1 and reply to the MN with a fake SUCVp2
      containing a valid N1 and an intentionally difficult puzzle
      request. The MN would then spend a lot of CPU and power
      computing the puzzle reply. This attack can be avoided if the
      MN had a mean to authenticate the address used by its CN.
      One solution is that the CN uses a SUCV address and signs
      SUCVp2.  We believe that this solution make the protocol much
      too complex for what it has been designed for (the MN then
      has to verify the SUCVp2's signature and the protocol would
      then probably have to be extended with additional messages as
      in HIP "opportunistic mode").

            MN   --SUCVp1--->   Intruder            CN
            MN  <--SUCVp2---    Intruder

      The Mobile IPv6 route optimization is beneficial but it is
      not essential. A mobile host is still reachable even if route
      optimization is not available.  There is always a tradeoff
      between service availability and complexity of the



Expires January 20, 2001                                       [Page 18]


INTERNET DRAFT       SUCV Identifiers and Addresses            July 2001


      authentication protocol.  For the Mobile IPv6 route
      optimization service, we believe that the protocol should be
      kept as simple as possible at the expense of service
      degradation sometimes.

      Therefore we suggest that a MN simply reject any SUCVp2
      messages that contain an overly complex client puzzle request
      Of course, the MN itself defines the complexity threshold of
      the puzzle request as a function of its processing power.

      As a result, the attack that consists of sending complex
      puzzles (in SUCVp2) to a MN, in order to exhaust its
      computing resources, will not be sucessful, because the MN
      will drop the SUCVp2.  The MN service will be degraded
      (because its incoming packets will then be routed through its
      home agent) but not disrupted.

   SUCVp3 storm:

      Malicious host could try to attack a host by sending a storm
      of SUCVp3 messages.  We prevent this attack by using a client
      puzzle. A host accepts a SUCVp3 message only after verifying
      that the puzzle reply (contained in the SUCVp3) is valid.


7.0 Future Work



7.1  SUCV Sublayer


   In this draft we propose a protocol for a MN to prove the
   ownership of its addresses and to authenticate the BU that it
   sends to its CN. This protocol was made part of Mobile IPv6 for
   deployment reasons.  However the address owernship problem is
   more general than Mobile IPv6 and other protocols and
   applications might need this functionality.

   In the long run it might be more efficient to have a "SUCV"
   sublayer below the IP layer (such as in the IPSec sublayer) that
   could be used by  all protocols and applications above it.  This
   protocol would be used between two communicating hosts to prove
   the address ownership of each host and to derive shared keys
   that could be used by the hosts' protocols and applications.

   This protocol should provide mutual owernship proof (i.e. proves
   the address ownership of both hosts) and/or unilateral owernship



Expires January 20, 2001                                       [Page 19]


INTERNET DRAFT       SUCV Identifiers and Addresses            July 2001


   proof (i.e. proves only the address ownership of one of the
   hosts).

   A host communicating with a mobile host would then use this
   service to prove the ownership of the MN's home address and
   CoA.

   We believe that the "opportunistic mode" of HIP
   [HIPARCH,HIPIMPL,HIPPROT] (with the IPv6 accomodation mode
   described in Section 5.0) is a good candidate for the SUCV
   sublayer. However more studies are needed.  We leave this SUCV
   sublayer design for future work.


7.2  Applications to Micro-Mobility

   Recent micro-mobility management protocols (such as HAWAII or
   Cellular IP) propose to use specialized path setup schemes which
   install host-based forwarding entries in specific routers to
   support intra-domain micro-mobility. In order to avoid trafic
   redirection, routers need to verify the ownership of an address
   used by a mobile host before adding an entry for that particular
   mobile host in its routing table. SUCV addresses or identifiers
   also can be very useful for that purpose.


8.0 Security Considerations

   The technique introduced in this document is meant to increase
   the level of security in the Internet.

   This document explains the concept of statistical uniqueness and
   cryptographic verifiability (SUCV), specially as it applies to
   IPv6 addresses in the form of SUCV addresses. The SUCV
   characteristics are used to prove address ownership, thus
   preventing a class of attacks which exploit this fault in many
   types of commands.  In particular, commands which alter how an
   address is treated by peers or by the routing infrastructure can
   be used to launch denial of service attacks or hijacking
   attacks. Proving address ownership eliminates these attacks.
   However, given that this technique is meant to be used primarily
   in the absence of global infrastructures, the possibility of man
   in the middle attacks does remain. Nevertheless, since the
   protocol used here is based on HIP, these attacks are limited by
   the use of cookies and client puzzles.






Expires January 20, 2001                                       [Page 20]


INTERNET DRAFT       SUCV Identifiers and Addresses            July 2001


9.0 Conclusions

   The present document focuses on the use of the SUCV property to
   enhance the security of exchanges between an arbitrary pair of
   peers in the absence of any third party.  In particular, we
   propose that SUCV addresses be used to solve the issue of
   securing binding updates in Mobile IPv6.


References

[ADDROWN] Pekka Nikander, "An Address Ownership Problem in IPv6",
   draft-nikander-ipng-address-ownership-00.txt, February 2001.

[BIRTH] http://www.rsasecurity.com/rsalabs/faq/2-4-6.html

[CAM] Greg O'Shea and Michael Roe, "Child-proof Authentication for
   MIPv6 (CAM)", ACM Computer Communications Review, April 2001.

[HIPARCH] Bob Moskowitz, "HIP Architecture",
   draft-ietf-moskowitz-hip-arch-02.txt

[HIPIMPL] Bob Moskowitz, "HIP Implementation",
   draft-moskowitz-hip-impl-01.txt

[HIPPROT] Bob Moskowitz, "Host Identity Payload and Protocol",
   draft-moskowitz-hip-03.txt

[IPV6ADDR] Hinden, Deering, "IPv6 Addressing Architecture,"
   draft-ietf-ipngwg-addr-arch-v3-05.txt

[MIPPRIV] Castelluccia, Dupont, "A Simple Privacy Extension for
   Mobile IPv6," draft-castelluccia-mobileip-privacy-00.txt,
   February 2001.

[MIPV6] C. Perkins, "Mobile IP for IPv6",
   draft-ietf-mobileip-ipv6-13.txt

[PBK] Bradner, Mankin, Schiller, "Purpose Built Keys",
   draft-bradner-pbk-frame-00.txt

[PUZZLES] Tuomas Aura, Pekka Nikander and J. Leiwo. DOS-resistant
   Authentication with Client Puzzles.

[RFC3041] T. Narten, R. Draves "Privacy Extensions for Stateless
   Address Autoconfiguration in IPv6," RFC 3041.

[WeakMD5] H. Dobbertin, "Cryptanalysis of MD5 Compress",



Expires January 20, 2001                                       [Page 21]


INTERNET DRAFT       SUCV Identifiers and Addresses            July 2001


   http://www.cs.ucsd.edu/users/bsy/dobbertin.ps

[MIPv6SecReq] Nikander, Harkins, Patil, Roberts, Nordmark, Narten,
   Mankin, "Threat Models Introduced by Mobile IPv6 and
   Requirements for Security in Mobile IPv6",
   draft-team-mobileip-mipv6-sec-reqts-00.txt

Authors' addresses

   Questions about this document may be directed to:

          Gabriel Montenegro
          Sun Microsystems Laboratories, Europe
          29, chemin du Vieux Chene
          38240 Meylan, FRANCE

          Voice:  +33 476 18 80 45
          E-Mail: gab@sun.com


          Claude Castelluccia
          INRIA Rhone-Alpes
          655 avenue de l'Europe
          38330 Montbonnot Saint-Martin
          FRANCE
          email: claude.castelluccia@inria.fr
          phone: +33 4 76 61 52 15
          fax:   +33 4 76 61 52 52

Copyright (c) The Internet Society (2000). All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.




Expires January 20, 2001                                       [Page 22]


INTERNET DRAFT       SUCV Identifiers and Addresses            July 2001


   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS 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.













































Expires January 20, 2001                                       [Page 23]


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