Subject: [mobile-ip] MIPv6 Security: Assessment of Proposals

From: gabriel montenegro <[email-masked]>
Date: Tue, 06 Nov 2001 09:18:14 +0100

Folks,

The chairs had asked me if I would be able to help with a document evaluating the different
proposals against the requirements document (soon to appear in its rev02 version
at your favorite drafts repository as draft-ietf-mobileip-mipv6-scrty-reqts-02.txt).
I've been neglecting this terribly.

Unfortunately, the problem won't go away. Given the shortness of time, the
impending draft deadline next week, the urgency to have some progress
by Salt Lake City, and the numerous proposals on the table, in consultation
with the chairs, we've decided to involve all of you in a distributed effort to
start this document.

I've provided a skeleton, and a nomenclature based on the items in the
requirements document. The idea is that each proposal has its own section in which
it is assessed in a well-defined format. We have already asked the authors for
help with their respective protocol assessments.

We believe that involving the authors
early on is a good way to get us all thinking critically (pros and cons)
about our own proposals, and it would be a quick way to jump start the
review and evaluation process.

But we hope and anticipate that all interested working group members will
participate as well. You will find further info on how to assess the proposals
in the attached document. If you have time to assess only one proposal: great.
More than that? Wonderful.

In order to make the deadline, it would be great if you could send me
the evaluations for your proposals by next Tuesday November 13. That would give me
a little over a day to include them into the evaluation document in time for
submission. Any feedback received after Tuesday will be taken into consideration
for the post Salt Lake City revision.

Thanks in advance for your cooperation,

-gabriel
--
Gabriel Montenegro (Sun Microsystems Laboratories, Europe)
29, chemin du Vieux Chêne         Email: [email-masked]
38240 Meylan, France              Mobile: +33 673 99 56 62
Office: +33 476 18 80 45 (sun internal: x38045)
Fax:    +33 476 18 88 88

Internet Engineering Task Force                    G. Montenegro, editor
INTERNET DRAFT                                            November, 2001

                MIPv6 Security: Assessment of Proposals
                 draft-montenegro-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 [email-masked].

   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

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] draft-perkins-bake-00.txt
   - [BU3WAY] draft-nordmark-mobileip-bu3way-01.txt
   - [DHMIPv6] draft-le-mobileip-dh-00.txt
   - [HACOOKIES] draft-thomas-mobileip-ha-cookies-00.txt
   - [PBK] draft-bradner-pbk-frame-00.txt.
   - [SAP] draft-mkhalil-mobileip-ipv6-sap-02.txt
   - [SUCV] draft-montenegro-sucv-01.txt
   - [UPDATEAUTH] draft-roe-mobileip-updateauth-00.txt

todo: any others?

   In order to arrive at an assessment of each of the above, this

Expires May, 2002                                               [Page 3]

INTERNET DRAFT   MIPv6 Security: Assessment of Proposals   November 2001

   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.

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

Expires May, 2002                                               [Page 4]

INTERNET DRAFT   MIPv6 Security: Assessment of Proposals   November 2001

   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:

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
      already the case for MIPv6 and as such is not a new

Expires May, 2002                                               [Page 6]

INTERNET DRAFT   MIPv6 Security: Assessment of Proposals   November 2001

      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
      further BUs to that CN (for a period of time).

Expires May, 2002                                               [Page 7]

INTERNET DRAFT   MIPv6 Security: Assessment of Proposals   November 2001

     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.

      7.1 A router on a subnet willing to take on the role of an HA

Expires May, 2002                                               [Page 8]

INTERNET DRAFT   MIPv6 Security: Assessment of Proposals   November 2001

      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: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.
   2.7:N.
   2.8:N.
   2.9:N.
   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.

Expires May, 2002                                               [Page 9]

INTERNET DRAFT   MIPv6 Security: Assessment of Proposals   November 2001

   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.

5.0 [BU3WAY] 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.
   2.7:N.
   2.8:N.
   2.9:N.
   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.

Expires May, 2002                                              [Page 10]

INTERNET DRAFT   MIPv6 Security: Assessment of Proposals   November 2001

6.0  [DHMIPv6] 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.
   2.7:N.
   2.8:N.
   2.9:N.
   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.

7.0  [HACOOKIES] 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.

Expires May, 2002                                              [Page 11]

INTERNET DRAFT   MIPv6 Security: Assessment of Proposals   November 2001

   2. Specific to Mobile IPv6
   2.1:N.
   2.2:N.
   2.3:N.
   2.4:N.
   2.5:N.
   2.6:N.
   2.7:N.
   2.8:N.
   2.9:N.
   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.

8.0  [PBK] 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.
   2.7:N.
   2.8:N.

Expires May, 2002                                              [Page 12]

INTERNET DRAFT   MIPv6 Security: Assessment of Proposals   November 2001

   2.9:N.
   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.

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.
   2.7:N.
   2.8:N.
   2.9:N.
   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.

Expires May, 2002                                              [Page 13]

INTERNET DRAFT   MIPv6 Security: Assessment of Proposals   November 2001

   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: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.
   2.7:N.
   2.8:N.
   2.9:N.
   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.

Expires May, 2002                                              [Page 14]

INTERNET DRAFT   MIPv6 Security: Assessment of Proposals   November 2001

11.0  [UPDATEAUTH] 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.
   2.7:N.
   2.8:N.
   2.9:N.
   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.

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

Expires May, 2002                                              [Page 15]

INTERNET DRAFT   MIPv6 Security: Assessment of Proposals   November 2001

13.0 Recommendations

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

   TO BE DONE

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-01.txt

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

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

[HACOOKIES] draft-thomas-mobileip-ha-cookies-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

[UPDATEAUTH] draft-roe-mobileip-updateauth-00.txt

Expires May, 2002                                              [Page 16]

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: [email-masked]

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.

Changes

Expires May, 2002                                              [Page 17]

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 . . . . . . . . . . . . . . .   4
4.0 [BAKE] Assessment  . . . . . . . . . . . . . . . . . . . . . . .   9
5.0 [BU3WAY] Assessment  . . . . . . . . . . . . . . . . . . . . . .  10
6.0  [DHMIPv6] Assessment  . . . . . . . . . . . . . . . . . . . . .  11
7.0  [HACOOKIES] Assessment  . . . . . . . . . . . . . . . . . . . .  11
8.0  [PBK] Assessment  . . . . . . . . . . . . . . . . . . . . . . .  12
9.0  [SAP] Assessment  . . . . . . . . . . . . . . . . . . . . . . .  13
10.0  [SUCV] Assessment  . . . . . . . . . . . . . . . . . . . . . .  14
11.0  [UPDATEAUTH] Assessment  . . . . . . . . . . . . . . . . . . .  15
12.0 Comparison of the Proposals . . . . . . . . . . . . . . . . . .  15
13.0 Recommendations . . . . . . . . . . . . . . . . . . . . . . . .  16
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  16
Authors' addresses . . . . . . . . . . . . . . . . . . . . . . . . .  17
Changes  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  17

Expires May, 2002                                               [Page 2]

---

From: Jean-Michel COMBES <[email-masked]>
Date: Tue, 06 Nov 2001 16:19:02 +0100

Hi,

some comments/questions :

*** table of contents ***

Problem of place/page

*** Section 2, point 5 ***
"It SHOULD be possible to negociate alternative mechanisms."

What do you mean ? For example, a MN may have many mechanisms (eg. PBK, BAKE, etc.), before
using such a mechanism, are there some exchanges between MN and "random" CN to decide what
mechanism to use ? Or, have all IPv6 nodes the same mechanism ?

*** Section 2, point 6 ***
"A soon to be published I-D will identify the issues of using IPsec in conjonction with Mobile
IPv6."

I thought that it was out of scope for the moment ... Will this I-D be published before next
IETF Meeting ?

*** Section 3 ***
Problem of numbering

*** Section 3, point 2.3 ***
"The MN SHOULD be capable of ascertaining the identity of the access point to which is is
attaching and authenticate it."

Typo : twice "is".

When you say "access point", is it the Access Router (L3) or the L2 access point ?

*** Section 3, point 8.3 ***

Typo : twice "that".

Regards.
JMC.

--

France Telecom R&D - DTL/SSR
Jean-Michel COMBES, Internet/Intranet Security
E-Mail : [email-masked]
Phone +33 (0)1 45 29 45 94, Fax +33 (0)1 45 29 65 19
PGP fingerprint : 07C6 37BF 4DE5 1CE1 EEB1 1F13 5D75 9E33 CFA7 0214

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 06 Nov 2001 15:09:05 -0500

Hello Gabriel,
  Profiting the occasion, may I ask you what you think on the notorious debate on piggybacking
BUs, i.e. Arkko draft options 6.1-6.4?

Regards,

gabriel montenegro wrote:

>   ------------------------------------------------------------------------

--
Behcet