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

Versions: 00

Internet Engineering Task Force                    G. Montenegro, editor
INTERNET DRAFT                                        A.Petrescu, editor
                                                          November, 2001
                MIPv6 Security: Assessment of Proposals
             draft-montenegro-mobileip-mipv6-seceval-00.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 Mobile IP mailing list
   at mobile-ip@sunroof.eng.sun.com.

   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

   The IESG has identified several security issues with the
   current Mobile IPv6 specification [MIPv6]. A subsequent effort
   [MIPv6SecReq] details the security threats introduced by
   MIPv6. Two major issues are (1) how to obtain a security
   association between an arbitrary MN and CN such that the
   binding update (BU) is secure, and, assuming such a mechanism
   is in place, (2) how to secure the individual BU messages.
   This document is an assessment of the proposed solutions for
   problem (1).







Expires May, 2002                                               [Page 1]


INTERNET DRAFT  MIPv6 Security: Assessment of Proposals    November 2001


Table of Contents

1.0 Introduction ..................................................    3
2.0 Methodology ...................................................    3
   2.1 Schedule ...................................................    4
3.0 Format for the Security Assessment ............................    5
4.0 [BAKE] Assessment .............................................    9
5.0 [BU3WAY] Assessment ...........................................   11
6.0  [DHMIPv6] Assessment .........................................   12
7.0  [BUSEC] Assessment ...........................................   13
8.0  [PBK] Assessment .............................................   14
9.0  [SAP] Assessment .............................................   17
10.0  [SUCV] Assessment ...........................................   18
11.0  [CAM-DH] Assessment .........................................   19
12.0 Comparison of the Proposals ..................................   21
13.0 Recommendations ..............................................   21
Acknowledgements ..................................................   21
References ........................................................   22
Authors' addresses ................................................   23
Changes ...........................................................   24































Expires May, 2002                                               [Page 2]


INTERNET DRAFT  MIPv6 Security: Assessment of Proposals    November 2001


1.0 Introduction

   The IESG has identified several security issues with the current
   Mobile IPv6 specification [MIPv6]. A subsequent effort
   [MIPv6SecReq] details the security threats introduced by MIPv6.
   Two major issues are (1) how to obtain a security association
   between an arbitrary MN and CN such that the binding update (BU)
   is secure, and, assuming such a mechanism is in place, (2) how
   to secure the individual BU messages.

   Problem (1) is essentially one of key establishment, whereas (2)
   deals with the mechanisms to protect the traffic.  (2) is the
   domain of IPsec. Accordingly, the ensuing debates are about AH
   versus ESP, for example.

   (1), on the other hand, is the domain of IKE, for example, and
   IKE is what MIPv6 has been counting on as a solution.
   Nevertheless, even though IKE may apply to securing BU's between
   MN's and HA's, as identified by the IESG, it is not scalable to
   secure BU's between as an MN and any arbitrary (hence unknown)
   CN.  So alternate solutions are being sought.

   The solution space for (1) includes a series of recent
   proposals, all of which aim at providing some security to the BU
   between arbitrary MN's and CN's in the absence of any global
   infrastructure like a PKI or a global AAA.


2.0 Methodology

   This document is an assessment of the proposed solutions for
   problem (1) above. This is the issue of securing BU's between an
   MN and another node, a CN, with which it does not have a
   security association in place.  In this regard, the currently
   proposed solutions are:

   - [BAKE] Binding Authentication Key Establishment Protocol for
     Mobile IPv6

   - [BU3WAY] Securing MIPv6 BUs using return routability

   - [DHMIPv6] Dynamic Diffie Hellman based Key Distribution for
     Mobile IPv6

   - [BUSEC] draft-thomas-mobileip-bu-sec-00.txt

   - [PBK] A Framework for Purpose Built Keys (PBK)




Expires May, 2002                                               [Page 3]


INTERNET DRAFT  MIPv6 Security: Assessment of Proposals    November 2001


   - [SAP] Dynamic Security Association Establishment Protocol For
     IPv6

   - [SUCV] SUCV Identifiers and Addresses

   - [CAM-DH] Authentication of Mobile IPv6 Binding Updates and
     Acknowledgments

   In order to arrive at an assessment of each of the above, this
   document collects the evaluations of each of the above with
   respect to the security requirements issued by the Mobile IP
   working group [MIPv6SecReq]. The hope is that initial
   assessments will be provided by the authors of the proposals, as
   part of making their proposals available to the working group.
   All internet drafts MUST have a security considerations
   section.  This document specifies that all internet drafts which
   propose solutions to secure arbitrary MN-CN BU's MUST have a
   more stringent security considerations section in the format
   specified below.

   Essentially, the proposals MUST provide a self-assessment with
   respect to [MIPv6SecReq]. These assessments can also be provided
   by any interested member of the working group, but it is hoped
   that the individual authors will be very actively involved.
   This document will serve to collect all the assessments in one
   place and to provide the public forum for working group
   commentary and modifications.


2.1 Schedule

   In order for the working group to arrive at the required
   decision, the following schedule should be adhered to. There may
   be more revisions than these ones, but no less.

   Rev -00, Initial version (incomplete):  To be issued by November
      14, 2001, in time for discussion at the 52nd IETF meeting,
      Salt Lake City (Dec 9-14, 2001).

   Rev -01, To be issued before end of January, 2002.  This version
      will have most of the assessments done, and will also include
      a first version of the tabular comparison and recommendations
      sections.

   Rev -02, final version To be issued for discussion at the 53rd
       IETF, Minneapolis, MN, March 17-22, 2002.





Expires May, 2002                                               [Page 4]


INTERNET DRAFT  MIPv6 Security: Assessment of Proposals    November 2001


3.0 Format for the Security Assessment

   [MIPv6SecReq] includes an exhaustive list of potential threats
   introduced by or made easier by MIPv6. These threats are
   distilled into a list of requirements. Each proposals must
   state with respect to each requirement if it is:

   o addressed ('A'): briefly explain how

   o partially addressed ('P'): identify the residual issues

   o ignored ('I'): some explanation is in order (is the problem
     impossible to solve?, too costly?)

   o no assessment ('N'): this is the initial state of assessement
     for each item, before it transitions to any of the above
     three.

   Assessments MUST use the shorthand notation alluded to above via
   the single characters 'A', 'P', 'I' and 'N'.  These SHOULD be
   followed by an explanation The requirements to be addressed are
   (from [MIPv6SecReq]):





























Expires May, 2002                                               [Page 5]


INTERNET DRAFT  MIPv6 Security: Assessment of Proposals    November 2001



   1.  General Requirements

      1  Should be no worse than IPv4 as it is today.

      2  Should be as secure as if the mobile node was on the home
         link without using Mobile IP.

      3  Identity verification MUST not rely on the existence of a
         global PKI.

      4  Any solution that is developed for securing the binding
         updates (MN-HA and MN-CN) should be able to use whatever
         security associations may already exist to minimize the
         threats created by on-axis attackers. In particular:

      4.1 It is assumed that in all schemes there will be some form
         of pre- established security association between a mobile
         node and its home agent. Such a security association
         should be used to minimize the threats.  In this context
         it makes sense exploring the complexity of handling
         mobile-to-mobile communication differently than
         mobile-to-nonmobile communication. As an example, if two
         MNs are communicating while visiting fairly untrusted
         visited links, it may make sense to take advantage of the
         fact that each mobile has a security association with its
         home agent when exchanging the messages needed to
         establish the binding. Thus these messages might travel
         MN1->HA1->HA2->MN2 (and in the reverse direction) so that
         the risks for a MITM attack are limited to the HA1<->HA2
         path.

      4.2 In some deployments a PKI may exist (encompassing for e.g
         some home "domain" which includes a set of MNs, their HAs
         and some CNs). In that case it should be possible to use
         the local PKI to prevent MITM attacks when the CN is
         covered by that PKI. (For instance, if both MN and CN
         share a trust chain in the PKI sense it should be possible
         to take advantage of that.)

      4.3 If a method to validate public keys (without the
         existence of CAs and PKI) is created or exists, then it
         should be possible to take advantage of that mechanism for
         improved security of the BUs.

   2. Specific to Mobile IPv6:

      1  Security for  binding updates is MANDATORY. This is



Expires May, 2002                                               [Page 6]


INTERNET DRAFT  MIPv6 Security: Assessment of Proposals    November 2001


         already the case for MIPv6 and as such is not a new
         requirement. However the mechanism used for securing
         binding updates MUST be one that is scalable and does not
         rely on existence of PKIs.

      2  It SHOULD be extremely difficult for an attacker
         "off-axis" i.e.  an attacker that cannot snoop packets on
         either of the three legs of the paths, to divert traffic.
         This difficulty should be on the order of correctly
         guessing a very large random number.

      3  It SHOULD be possible to leverage the only security
         association that can be preconfigured (the MN-HA SA) to
         secure BUs to CNs.

      4  It MUST be possible for a mobile node to be anonymous
         while still taking advantage of route optimization. Thus
         if a Mobile Node is using RFC 3041 temporary addresses for
         its home and/or COA it must be able to use a different
         visible identity when it uses a different temporary
         address.

      5  It SHOULD be possible to negotiate alternative cypher
         suites/algorithms.  It SHOULD be possible to negotiate
         alternative mechanisms.  All implementations MUST
         implement one designated mechanism and algorithm for
         interoperability reasons.

      6  If IPsec is used as part of the solution it SHOULD not
         place additional requirements on the set of IPsec SPD
         selectors beyond what is in common implementations.
         (Note:  This is however debatable. A soon to be published
         I-D will identify the issues of using IPsec in conjunction
         with Mobile IPv6.)

      7  Router Advertisements sent by the HA to the MN MUST be
         secured.

      8  Scalability of mechanisms using symmetric or asymmetric
         keys MUST be considered in any solution.

      9  SHOULD optimize the number of message exchanges and bytes
         sent between the participating entities (MN, CN, HA). This
         is an important consideration for some MNs which may
         operate over bandwidth constrained wireless links.

     10  A CN SHOULD be capable of rejecting BUs sent by a MN. If a
         CN rejects a BU, the MN SHOULD refrain from sending



Expires May, 2002                                               [Page 7]


INTERNET DRAFT  MIPv6 Security: Assessment of Proposals    November 2001


         further BUs to that CN (for a period of time).

     11  Any approach MUST consider the scalability issues and
         computational capabilities of the entities in a mobile
         environment, especially MNs and CNs. The expense
         associated with generating keys or public key operations
         or Diffie Hellman computations SHOULD be accounted for.

   3.  Requirements from Threats

      1.1 A correspondent node MUST not update its binding cache on
         receiving a binding update from any IPv6 node without
         verifying that the packet was sent by a node authorized to
         create binding cache entries for the home address carried
         in the home address option of the BU.

      1.2 No Mobile IPv6 specific requirements can be generated
         from this threat.

      1.4.1. An IPv6 node that receives binding updates SHOULD NOT
             create state until it has verified the authenticity of
             the sender.

      1.4.2 An IPv6 node SHOULD have the capability to reject
            binding updates.

      2.3 The Mobile Node SHOULD be capable of ascertaining the
         identity of the access point to which is is attaching and
         authenticate it.

      2.4 Upon receiving a packet carrying a Binding
         Acknowledgement, a mobile node SHOULD ensure it trusts the
         sender of that Binding Acknowledgment.

      4.2 The MN SHOULD be capable of authenticating binding
         requests. The MN SHOULD/MAY only process binding requests
         which are originated by nodes that are in the binding
         update list of the MN.

      4.3 The HA MUST authenticate any binding update received by
         it before making any changes to the binding cache
         entries.

      5.1 Any requirements to address this threat is outside the
         scope of Mobile IPv6 as the threat described above is a
         generic one.  However MIPv6 itself SHOULD not cause
         further grief in establishing end-to-end security either
         using IPsec or other mechanisms.



Expires May, 2002                                               [Page 8]


INTERNET DRAFT  MIPv6 Security: Assessment of Proposals    November 2001


      7.1 A router on a subnet willing to take on the role of an HA
         for a MN (even on a temporary basis) MUST establish a
         security association before the router will accept BUs for
         a MN with the H bit set.

      8.1 An HA which responds to an ICMP home agent discovery
         message MUST only do so after authenticating the MN's
         identity.

      8.2 The MN and HA MUST have a strong security association and
         the HA MUST verify the BUs sent by any IPv6 node
         requesting the HA to intercept packets destined for it and
         tunnel them to it's COA.

      8.3 CNs SHOULD NOT/MAY NOT process any packet (BU or not)
         containing a Home Address option unless they have verified
         that that the node sending the packets is authorized to
         use the home address in the destination option.



4.0 [BAKE] Assessment

   1. General Requirements

   1.1:A: BAKE avoids un-authenticated address bindings which has been
          identified as the distinctive threat introduced by Mobile
          IPv6.  However, BAKE is not resistant against certain types
          of attacks that are currently possible in IPv4 (traffic
          analysis on the path CN-HA could reveal sensitive
          information).
   1.2:N.
   1.3:A: BAKE does not rely on a global PKI.

   1.4.1:N.
   1.4.2:I.
   1.4.3:I.

   2. Specific to Mobile IPv6
   2.1:A.
   2.2:A.
   2.3:A: The HA-MN ESP tunnel is used (optionally) to relay the
          Binding Request from CN to HA to MN.
   2.4:N.
   2.5:P: The cryptographic algorithms used in BAKE are specified in
          generic terms and particularized as SHA-1, MD5 and the
          corresponding HMAC's.  The draft does not specify how to use
          other MAC's but these extensions seem easy to introduce.



Expires May, 2002                                               [Page 9]


INTERNET DRAFT  MIPv6 Security: Assessment of Proposals    November 2001


          Also, the draft does not specify how during BAKE message
          exchanges to dynamically select one cypher suite.
   2.6:N.
   2.7:N.
   2.8:N.
   2.9:A: This requirement is explicitely addressed in the draft as a
          design requirement.
   2.10:N.
   2.11:N.

   3. Requirements from Threats

   3.1.1:A: A correspondent node updates its binding cache only (1) as
            a result of receiving a Binding Key Establisment together
            with a Binding Update or (2) if a BAKE Security
            Association has previously been established by a BAKE
            exchange.
   3.1.2:N.
   3.1.4.1:A: A correspondent node will not create state until
              succesfull verification of tokens in the last BAKE
              message from MN to CN (BKE).
   3.1.4.2:A: A correspondent node that receives a BKE that does
              not succesfully pass checks will not set up a
              security association.
   3.2.3:I: The BAKE draft does not develop a security association
            between the Mobile Node and an Access Router.
   3.2.4:A: The BAKE Security Association is used to protect Binding
            Acknowledgments sent by the Correspondent Node to the
            Mobile Node.
   3.4.2:P: In BAKE, a Correspondent Node sends Binding Key Requests
            to Home Agent to Mobile Node; a Binding Key Request is
            authenticated by the Mobile Node with two types of checks:
            one functional check where tunnelling constraints are
            verified and one crypto check where N1 and T1 are
            verified.

            BAKE does not specify that MN SHOULD/MAY only process
            binding requests which are originated by nodes that are in
            the binding update list of the MN.

   3.4.3:I: BAKE does not address security associations between home
            agent and mobile node.
   3.5.1:N.
   3.7.1:I: The BAKE draft is not developping a security association
            between the Mobile Node and an Access Router willing to
            take on a Home Agent role.
   3.8.1:I: BAKE does not address security associations between home
            agent and mobile node.



Expires May, 2002                                              [Page 10]


INTERNET DRAFT  MIPv6 Security: Assessment of Proposals    November 2001


   3.8.2:P: In BAKE, a security association between MN and HA is
            optional (MAY, SHOULD).
   3.8.3:P: In BAKE, only Binding Updates and Acknowledgments are
            protected.  Home Address options are not protected in
            messages other than BU's/BAck's.


5.0 [BU3WAY] Assessment

   Note: this assesment is based on what is called bu3way-conf in
   the draft i.e. always do a 3way handshake and assuming
   confidentiality for the MN-HA part of the path used by the
   binding update related messages.

   1. General Requirements
   1.1:P -  It is possible to accomplish redirection without having
            the ability to supress packets from being delivered.
            For instance, an attacker between the CN and HA can
            redirect packets as long as it is able to observe the
            packets flying by. In IPv4 today such an attack would
            require that the attacker could also prevent the
            packets from being delivered.
   1.2:P - Same as above.
   1.3:A - Using a return routability check for each binding update.
   1.4.1:A - Including for MN to MN communication.
   1.4.2:A - PKI+IKE+IPsec works assuming that there are selectors
             on ICMP types.
   1.4.3:A - assuming IKE does the work of authenticating the
             public keys.

   2. Specific to Mobile IPv6
   2.1:A - 3-way handshake for each BY
   2.2:A - guess 128/160 bit cookie.
   2.3:A - using the HA-MN SA to provide confidentiality of cookie.
   2.4:A - no problem with multiple Home Address and/or CoAs.
   2.5:Not applicable. No cypher suites or algorithms used where
       both ends are involved (just cookie creation and
       verification by the CN).
   2.6:P - Assumes the ICMP type can be used as a selector.
   2.7:I - Not specified. Could be done.
   2.8:A - no symmetric or assymetric crypto used.
   2.9:I - conflicts with simplicity and 2.11.
   2.10:A - Using [MIPv6] mechanism - ICMP parameter problem.
   2.11:A - no public key calculations.

   3. Requirements from Threats
   3.1.1:A - return routability check.
   3.1.2:XXX This should be dropped from the list.



Expires May, 2002                                              [Page 11]


INTERNET DRAFT  MIPv6 Security: Assessment of Proposals    November 2001


   3.1.4.1:A - cookie based on single secret in the CN.
   3.1.4.2:A - don't respond to BUR or BU or use [MIPv6] ICMP
               parameter problem.
   3.2.3:I - the threat is not specific to MIPv6 BUs.
   3.2.4:A - 64 bit random acknowledgement cookie.
   3.4.2:I - Not yet specified. The acknowledgement cookie can be
             used for this by revising the binding request message
             format.
   3.4.3:A - the BUC messages are sent without creating a binding
             cache entry.
   3.5.1:A -  if binding update messages are to be protected
              separately then the spec assumes that ICMP types can
              be used as IPsec selectors.
   3.7.1:P - the draft doesn't say it but the authors opinion is to
             re-evaluate the need for that MIPv6 featurett.
   3.8.1:I - Not yet. The spec silently assumes that IPsec can be
             used for HA-MN communication, but the issues of
             anycast IPsec SAs has not been looked at.
   3.8.2:I - IPsec SA pair between HA and MN.
   3.8.3:I - Possible solution outlined in the specification.


6.0  [DHMIPv6] Assessment

   1. General Requirements
   1.1:N.
   1.2:N.
   1.3:P: DHMIPv6 does not rely on IKE but it relies optionally on AAA
          as a key distribution infrastructure.
   1.4.1:N.
   1.4.2:N.
   1.4.3:N.

   2. Specific to Mobile IPv6
   2.1:N.
   2.2:A: In order to redirect the traffic addressed to MN, the
          "off-axis" attacker must discover the secret Diffie-Hellman
          values of both MN and CN.
   2.3:I: No mechanism is proposed to possibly take advantage of an
          existing MN<->HA security association.
   2.4:N.
   2.5:P: The cryptographic part of DHMIPv6 is exclusively based on
          Diffie-Hellman algorithm.  No other algorithms that could be
          used to securely generate the key are presented.
   2.6:N.
   2.7:N.
   2.8:A: DHMIPv6 is scalable since it relies on a Diffie-Hellman
          peer-to-peer exchange with no need of a PKI.



Expires May, 2002                                              [Page 12]


INTERNET DRAFT  MIPv6 Security: Assessment of Proposals    November 2001


   2.9:I: The number of message exchanges is somewhat large for setting
          up a security association.
   2.10:N.
   2.11:I: The method makes heavy use of DH exchanges.

   3. Requirements from Threats
   3.1.1:N.
   3.1.2:N.
   3.1.4.1:N.
   3.1.4.2:N.
   3.2.3:N.
   3.2.4:N.
   3.4.2:N.
   3.4.3:N.
   3.5.1:N.
   3.7.1:N.
   3.8.1:N.
   3.8.2:N.
   3.8.3:N.


7.0  [BUSEC] Assessment

     1. General Requirements
     1.1: A. Uses return routability test to determine the
              node's presense. Also provides strong authentication
              via IPsec for use where practical
     1.2: A. Assuming link characteristics which prevent snooping
             to the same degree which would prevent TCP DOS,
             etc, attacks, this is met by the return routability
             test. With IPsec use, it is met in all cases.
     1.3: A. Return routability does not require PKI at all,
              IPsec keying may or may not use PKI.
     1.4.1: I. MN/MN security is treated no different; leaves open
                the possibility for optimiztions in the future.
     1.4.2: A. Uses IPsec for strong authentication/authorization
     1.4.3: A. IKE/KINK can be used to key SA's

     2. Specific to Mobile IPv6
     2.1: A. See 1.1
     2.2: A. Uses large random numbers similar to TCP ISS
     2.3: I. Leaves this possibility open for the future
     2.4: A. All that is required is reachability via the home
             address.
     2.5: A. IKE/KINK provide cipher suite negotiation.
     2.6: A. Does not place any more requirements on [IPSEC] and
             allows use of [ESP] in addition to [AH]
     2.7: A. Router advertisements can be secured using IPsec



Expires May, 2002                                              [Page 13]


INTERNET DRAFT  MIPv6 Security: Assessment of Proposals    November 2001


     2.8: A. IPsec is only required where trust localization is
             a reasonable assumption. Return routability is
             computationally inexpensive, and scalable
     2.9: P. IPsec secured flows will be optimized. Return
             routability explicitly defines only base test
             mechanisms leaving optimized versions open for
             future standardization on an as-needed basis.
     2.10:A. No change from -15 treatment
     2.11:A. Public key cryptography is not required whatsoever
             since the return routability test doesn't require
             it, and IPsec can be keyed manually or with KINK

     3. Requirements from Threats
     3.1.1:   A. Both IPsec and Return Routability can be used
                 to authenticate and authorize binding updates.
     3.1.2:   I. No requirement here.
     3.1.4.1: A. Uses [SYN-COOKIE] like mechanism for return
                 routability
     3.1.4.2: A. If tests fail (IPsec, Return routability),
                 it will fail.
     3.2.3:   P. Not in scope of this draft, and should not
                 be in requirements since MIPv6 does not
                 define any special relationship with the
                 access point/router. Could be ascertained
                 by strong authentication using IPsec.
     3.2.4: A. Both methods provide a means of establishing
               trust of the Binding Acknowledgment
     3.4.2: A. Same as 3.1.1
     3.4.3: A. Use of IPsec provides authentication
     3.5.1: A. No further grief found.
     3.7.1: A. Requires use of IPsec for strong authentication
     3.8.1: I. This draft doesn't address this, and questions
               the requirement in general since it seems to
               imply digital signatures for ICMP messages
     3.8.2: A. Uses IPsec to protect BU's and other control
               traffic between MN/HA
     3.8.3: A. Requires return routability test or appropriate
               authorization in security policy database when
               using strong authentication

8.0  [PBK] Assessment

   1. General Requirements
   1.1:N.
   1.2:N.
   1.3:P: PBK does not require that any support infrastructure
          (e.g. PKI) exist since it relies on host-generated temporary
          keys confined to the parties in communication and does not



Expires May, 2002                                              [Page 14]


INTERNET DRAFT  MIPv6 Security: Assessment of Proposals    November 2001


          require that the keys be registered with or known by any
          third party. However, the Purpose Built Keys (PBKs) do not
          provide a mean to verify the identity of the source but only
          to verify that the source is the same one as started the
          communication. Hence PBK framework assumes that the
          verification of the identity of the source has been
          performed securely at least one before PBK can be used for
          that purpose.
   1.4.1:I: [PBK] does not specify how the pre-established MN-HA
            security association can be made use of to optimize its
            operation.
   1.4.2:I: [PBK] does not specify how PKI, in case it is available,
            can be made use of to optimize its operation. However,
            existence of a PKI between MN and CN (i.e. MN and CN share
            a trust chain in the PKI sense) can obviously optimize PBK
            behavior since it can be used to performed the initial
            verification of the source identity required by the PBK
            framework.
   1.4.3:A: PBK provides a method to validate the public keys it
            relies on by establishing a binding between the EID
            (Endpoint ID) used by a host and its auto-generated public
            key: The EID is a hash pf the public part of the PKB.

   2. Specific to Mobile IPv6
   2.1:P: PBK does not rely on existence of PKIs and is scalable since
          its operations are confined to the end systems involved in
          the communications. However, as explained above (8.1.3) PKB
          does not provide real source identity verification.
   2.2:A: In order to redirect the traffic addressed to MN, The
          "off-axis" attacker must discover the private part of MN's
          PBK which is only known by MN.
   2.3:I: [PBK] does not specify how the pre-established MN-HA
          security association can be made use of to optimize its
          operation.
   2.4:A: By not using registred keys, PBK preserves user
          anonymity. In addition a MN PBK temporary public/private key
          pair used for a communication toward a CN can be used to
          generate new PBKs for this communication when needed.
   2.5:I: [PBK] does not specify how to negociate cypher
          suites/algorithms neither which ones must be implemented and
          which ones are optionals. However, it seems that any
          existing cypher algorithms applicable for public/private key
          pairs could be used. In addition, it seems that PBK could be
          easily extended to include cypher suites/algorithms
          negociation.

   2.6:N.
   2.7:N.



Expires May, 2002                                              [Page 15]


INTERNET DRAFT  MIPv6 Security: Assessment of Proposals    November 2001


   2.8:A: PBK does not rely on existence of PKIs and is scalable since
          its operations (and host-generated keys) are confined to the
          peers involved in the communications.
   2.9:I: [PBK] does not specify the format and size of messages
          exchanged. However, it seems that very few messages (with
          reasonnable size) are required and several approach can be
          used for implementation (IPv6 Destination option header,
          application specific payload...). In addition messages are
          only exchanged between MN and CN (HA is not involved).
   2.10:P: CN can verify the signature of the BU using the public part
           of MN PBK and ignore this BU if signature is not
           correct. However, [PBK] does not specify MN behavior in
           case BU is rejected by CN.
   2.11:I: PBK relies on the capability of MN to generate
           public/private key pairs that may be questionnable. In
           addition, [PBK] does not evaluate the complexity of
           generating public/private key pair for a Mobile Node.

   3. Requirements from Threats
   3.1.1:I: The Purpose Built Key (PBKs) does not provide a mean to
            verify the identity of the source but only to verify that
            the source is the same one as started the
            communication. Hence PBK framework assumes that the
            verification of the identity of the source has been
            performed securely at least one before PBK can be used for
            that purpose. In that context, PBK on its own does not
            provide a solution to CN problem of verifying whether a
            Node sending a BU for a certain Home Address is authorized
            to do so.
   3.1.2:N.
   3.1.4.1:I: As specified in [PBK] some states are created on CN to
              store the MN's EID and public part of MN PBK without
              prior verification of the authenticity of the sender
              (MN). Again, this is due to the fact that PBK on its own
              does not provide a mean to verify the identity of the
              source.
   3.1.4.2:N.
   3.2.3:I: This is not addressed in [PBK].
   3.2.4:I: Even if not explicitly mentioned in [PBK], PBK covers
            authentication of BA received by MN by having CN
            generating its own PBKs and communicating them to MN (in
            the same way MN would do it to authenticate its BUs to
            CN). However, once again PBK on its own does not provide a
            mean to verify the identity of the source.
   3.4.2:I: Even if not explicitly mentioned in [PBK], PBK covers
       authentication of BR received by MN by having CN generating its
       own PBKs and communicating them to MN (in the same way MN would
       do it to authenticate its BUs to CN). However, once again PBK



Expires May, 2002                                              [Page 16]


INTERNET DRAFT  MIPv6 Security: Assessment of Proposals    November 2001


       on its own does not provide a mean to verify the identity of
       the source.
   3.4.3:P: Authentication of BU received by HA is not explicitly
            covered in [PBK], however this requirement will be met
            easily in the case a pre-established security association
            exist between MN and HA.
   3.5.1:N.
   3.7.1:I: Even if not explicitly mentioned in [PBK], PBK enables a
            router on a subnet willing to take on the role of an HA
            for a MN to establish a security association with MN (and
            vice versa). However, once again PBK on its own does not
            provide a mean to verify the identity of the source which
            means MN and the routers will have no guarantee on their
            respective real identity.
   3.8.1:I: Not covered in PBK.
   3.8.2:P: Authentication of BU received by HA is not explicitly
            covered in [PBK], however this requirement will be met
            easily in the case a pre-established security association
            exist between MN and HA.

   3.8.3:I: The Purpose Built Key (PBKs) does not provide a mean to
       verify the identity of the source but only to verify that the
       source is the same one as started the communication. Hence PBK
       framework assumes that the verification of the identity of the
       source has been performed securely at least one before PBK can
       be used for that purpose. In that context, PBK on its own does
       not provide a solution to CN problem of verifying whether a
       Node sending a BU for a certain Home Address is authorized to
       do so.


9.0  [SAP] Assessment

   1. General Requirements
   1.1:N.
   1.2:N.
   1.3:N.
   1.4.1:N.
   1.4.2:N.
   1.4.3:N.

   2. Specific to Mobile IPv6
   2.1:N.
   2.2:N.
   2.3:N.
   2.4:N.
   2.5:N.
   2.6:N.



Expires May, 2002                                              [Page 17]


INTERNET DRAFT  MIPv6 Security: Assessment of Proposals    November 2001


   2.7:N.
   2.8:N.
   2.9:A: The number of messages exchanged is minimized.
   2.10:N.
   2.11:N.

   3. Requirements from Threats
   3.1.1:N.
   3.1.2:N.
   3.1.4.1:N.
   3.1.4.2:N.
   3.2.3:N.
   3.2.4:N.
   3.4.2:N.
   3.4.3:N.
   3.5.1:N.
   3.7.1:N.
   3.8.1:N.
   3.8.2:N.
   3.8.3:N.


10.0  [SUCV] Assessment

   1. General Requirements
   1.1:A.
   1.2:A.
   1.3:A: SUCV binds an IPv6 address with a public key through a hash
          function that is very  difficult to invert.
          Verification of the supplied public key is easily done
          through a simple comparison between the hash and the
          identifier part of the address, so there is no need of
          global PKI.
   1.4.1:I: SUCV does not take advantage of an existing security
            association between MN and HA.
   1.4.2:I: SUCV is not designed to make use of an existing PKI
            between MN and CN. However, nothing prevents the
protocol from employing properly signed certificates             in
addition to the currently employed self-signed             certificates.
Notice that signed certificates are             the default used by HIP,
which was a point of             departure for SUCV.
   1.4.3:I.

   2. Specific to Mobile IPv6
   2.1:A: The proposed mechanism to secure binding updates is scalable
          and does not rely on the use of PKI.
   2.2:A.
   2.3:I.



Expires May, 2002                                              [Page 18]


INTERNET DRAFT  MIPv6 Security: Assessment of Proposals    November 2001


   2.4:A.
   2.5:A. Very simple 'negotiation' based on offer/response.
   2.6:A. Places restrictions on, say, piggybacking for this.
   2.7:I.
   2.8:A.
   2.9:A. Optimization but not at the expense of DoS protection.
   2.10:A.
   2.11:P. Further improvements to follow.

   3. Requirements from Threats
   3.1.1:A.
   3.1.4.1:A.
   3.1.4.2:A.
   3.2.3:I. Requirement not applicable.
   3.2.4:A.
   3.4.2:P. Possible if the other system uses SUCV.
   3.4.3:A.
   3.5.1:A.
   3.7.1:I.
   3.8.1:I.
   3.8.2:I.
   3.8.3:A.


11.0  [CAM-DH] Assessment

   1. General Requirements
   1.1 A
   1.2 A
   1.3 A
   1.4.1 A
   1.4.2 P
   1.4.3 P

   2. Specific to Mobile IPv6
   2.1 A
   2.2 A
   2.3 A
   2.4 P
   2.5 P
   2.6 A
   2.7 I
   2.8 A
   2.9 A
   2.10 A
   2.11 A

   3. Requirements from Threats



Expires May, 2002                                              [Page 19]


INTERNET DRAFT  MIPv6 Security: Assessment of Proposals    November 2001


   3.1.1 A
   3.1.4.1 A
   3.1.4.2 A
   3.2.3 I
   3.2.4 N
   3.4.2 A
   3.4.3 A
   3.5.1 A
   3.7.1 A
   3.8.1 I
   3.8.2 A
   3.8.3 P

   Authentication of routers

   The CAM-DH authorse agree that there is a need for a mechanism
   to authenticate router advertisements. However, they think that
   this is a separate problem that should be solved with a separate
   protocol. For this reason, requirements 2.7 and 3.2.3 are not
   addressed by the CAM-DH protocol.

   Use of an existing PKI

   The CAM-DH protocol can be combined with an existing key
   distribution mechanism. However, the current version of the
   document doesn't explain how to do this. Requirements 1.4.2 and
   1.4.3 are only partially addressed.

   Authenticating packets other than binding updates

   The CAM-DH protocol is only designed for authenticating binding
   updates.  However, the key it exchanges could be used for
   authenticating other packets that contain a home address
   option.  Alternatively, nodes can protect themselves against
   falsified home address options by refusing to accept packets
   containing a home address option unless there exists a binding
   cache entry (established using CAM-DH) for that combination of
   home address and care-of address. Requirement 3.8.3 is only
   partially addressed.

   Negotiation of Cipher Algorithms

   CAM-DH provides a means by which a host can announce which
   cryptographic algorithm it is using. However, this falls short
   of being a negotiation mechanism because there is no means to
   find out which mechanisms a peer will accept. Requirement 2.5 is
   only partially addressed.




Expires May, 2002                                              [Page 20]


INTERNET DRAFT  MIPv6 Security: Assessment of Proposals    November 2001


   Use of existing security associations

   CAM-DH can make use of an existing IPSEC security association
   between the mobile node and the home agent, as long as it
   provides confidentiality, not just integrity. That is, ESP is
   required and AH is not sufficient.

   Authenticating Home Agent Discovery Messages

   The CAM-DH authors do not believe that there is a genuine need
   to authenticate home agent discovery messages. Requirement 3.8.1
   is ignored.

   Anonymity

   There is a conflict between anonymity and the denial of service
   protection mechanisms provided by CAM-DH. Whatever protocol is
   used, servers cannot ration out limited resources between
   clients if they can't tell where requests come from. The CAM-DH
   protocol can be used either with anonymity (and no resource
   rationing) or with resource rationing (and no anonymity).  There
   is probably a need for a protocol to cover the case where the
   mobile is not anonymous to its home agent, but is anonymous to
   other correspondents. CAM-DH can be extended to do this, but the
   current document doesn't explain how. Requirement 2.4 is
   partially addressed.


12.0 Comparison of the Proposals

   This section is a tabular side-by-side comparison of the above
   proposals in order to understand the tradeoffs involved.

   TO BE DONE


13.0 Recommendations

   It also issues a recommendation or series of recommendations
   towards an official working group solution.

   TO BE DONE


Acknowledgements

   The authors are deeply grateful to the members of the working
   group and proposal authors who participated in this security



Expires May, 2002                                              [Page 21]


INTERNET DRAFT  MIPv6 Security: Assessment of Proposals    November 2001


   assessment effort: Michael Thomas, Erik Nordmark, Michael Roe,
   Alexis Olivereau, Damien Routier and Christophe Janneteau..

   This was truly a distributed effort.


References

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

[BAKE] draft-perkins-bake-00.txt

[BU3WAY] draft-nordmark-mobileip-bu3way-00.txt

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

[CAM-DH] draft-roe-mobileip-updateauth-01.txt

[DHMIPv6] draft-le-mobileip-dh-00.txt

[BUSEC] draft-thomas-mobileip-bu-sec-00.txt

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

[MIPv6] D. Johnson, C. Perkins, "Mobile IP for IPv6",
   draft-ietf-mobileip-ipv6-14.txt, July 2001. Work in progress.

[MIPv6SecReq] Mankin, Patil, Harkins, Nordmark, Nikander, Roberts,
   Narten, "Threat Models Introduced by Mobile IPv6 and
   Requirements for Security in Mobile IPv6",
   draft-ietf-mobileip-mipv6-scrty-reqts-01.txt, October 2001.
   Work in progress.

[PBK] draft-bradner-pbk-frame-00.txt.

[SAP] draft-mkhalil-mobileip-ipv6-sap-02.txt

[SUCV] draft-montenegro-sucv-01.txt










Expires May, 2002                                              [Page 22]


INTERNET DRAFT  MIPv6 Security: Assessment of Proposals    November 2001


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



    Alexandru Petrescu
    Motorola Labs, Paris
    Espace Technologique - Saint Aubin
    91193 Gif-sur-Yvette Cedex, France

    Phone: +33 1 69 35 48 27
    Email: Alexandru.Petrescu@motorola.com

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.

   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 May, 2002                                              [Page 23]


INTERNET DRAFT  MIPv6 Security: Assessment of Proposals    November 2001


Changes


















































Expires May, 2002                                              [Page 24]


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