Subject: psreq issue #13: part II: Assessment criteria

From: Pekka Nikander <[email-masked]>
Date: Wed, 12 Mar 2003 11:20:04 +0200

I am in the process of resolving issue #13.

The second part of the comment concerned the qualities of
the potential solutions in the various trust models.  Since
I could not figure out how to exactly apply the comment to
the current document structure, I ended up adding a new
section, Assessment criteria.

5. Assessment criteria for solutions

    In this section we discuss a few criteria that may be used to assess
    the quality of solutions.  This list is not meant to be exhaustive.
    Rather than that, it represents a collection of qualities people paid
    attention at during the drafting of this document.

    Zero configuration.  The original Neighbor Discovery protocol was
       carefully designed to support zero configuration.  The secure
       protocol should support zero configuration to the extend possible.

    Access control.  It should be possible to use the solution both in
       scenarios where the devices need to gain access permission to
       access the network before running Neighbor Discovery, and in
       scenarios where the devices first gain access to a local network
       and run Neighbor Discovery, and are then later subject to access
       control for accessing some resources.

    Possession of keys.  The solutions should be evaluated in respect to
       the which parties possess keys and other valuable information, and
       on the threats created if these parties disclose this information
       to unauthorized parties.  For example, the solution should limit
       the damage caused if an authorized client discloses its private
       key to an attacker, either intentionally or as a consequence of a
       security breach.

    Scalability.  The solutions should be evaluated in respect to the
       number of keys, security associations, and other items used.  It
       is desirable that these numbers grow at most linearly with
       resepect to the number of nodes.

Is this OK?  Are there other important, general level criteria
that should be added to this list?

--Pekka Nikander

--------------------------------------------------------------------
To unsubscribe from this list, send email with "UNSUBSCRIBE" in the
body to <[email-masked]>.
Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html
--------------------------------------------------------------------

---

From: "James Kempf" <[email-masked]>
Date: Wed, 12 Mar 2003 09:14:16 -0800

General comment:

I had been thinking that the assessment of the solution would regress against
the requirements, in the sense of how the protocol blocked the threats in the
threats draft. I don't see a need for any detailed requirement list, the threats
make that clear.What's below seem like high level goals, and I would phrase them
as such (i.e. goals rather than assessment criteria). Also, I would formulate an
overall goal of attempting to maintain fidelity with the base ND design goals in
RFC 2461. It probably doesn't hurt to re-iterate those here, but it should be
made clear that it is just a re-iteration.

>     attention at during the drafting of this document.

I think the final sentence is unnecessary. It is always the case that something
may be left out. See general comments about how to beef up the introduction.

>        protocol should support zero configuration to the extend possible.

^^^^^

extent
>        key to an attacker, either intentionally or as a consequence of a

Isn't it true that any security solution should exhibit this property? If so, is
there a real need to restate it here?

>        resepect to the number of nodes.

Again, I think this is a basic scalability goal and I question the need to
restate it. The Seamoby WG became hung up and spent months discussing exactly
how to quantify scalability. I'd rather not see that happen here. This design,
as an extension of the base ND design, should have the same scalability
properties, the security part as well.

            jak

---

From: Pekka Nikander <[email-masked]>
Date: Wed, 12 Mar 2003 21:30:37 +0200

> made clear that it is just a re-iteration.

I have no problem leaving the new section completely out.
I just tried to incorporate Craig's comment, filed as issue#13.

I'll do whatever the WG feels is the right thing.

--Pekka

---

From: "James Kempf" <[email-masked]>
Date: Wed, 12 Mar 2003 12:45:26 -0800

IMHO, I think a single paragraph with a statement of basic goals would be
sufficient.

            jak

---

From: Pekka Nikander <[email-masked]>
Date: Thu, 13 Mar 2003 11:46:44 +0200

> IMHO, I think a single paragraph with a statement of basic goals would be

I removed the new section, and replaced it with a single paragraph
in the introduction.  The new introduction reads as below.

Everybody happy?

--Pekka

1. Introduction

    The IPv6 Neighbor Discovery RFC2461 [3] and Address Autoconfiguration
    RFC2462 [4] mechanisms are used by nodes in an IPv6 network to learn
    the local topology, including the IP to MAC address mappings for the
    local nodes, the IP and MAC addresses of the routers present in the
    local network, and the routing prefixes served by the local routers.
    The current specifications suggest that IPsec AH RFC2402 [2] may be
    used to secure the mechanisms, but does not specify how.  It appears
    that using current AH mechanisms is problematic due to key management
    problems [11].

    To solve the problem, the Secure Neighbor Discovery (SEND) working
    group was chartered in fall 2002.  The goal of the working group is
    to define protocol support for securing IPv6 Neighbor Discovery
    without requiring excessive manual keying.

    The purpose of this document is to define the types of networks in
    which the Secure IPv6 Neighbor Discovery mechanisms are expected to
    work, and the threats that the security protocol(s) must address.  To
    fulfill this purpose, this document first defines three different
    trust models, roughly corresponding to secured corporate intranets,
    public wireless access networks, and pure ad hoc networks.  After
    that, a number of threats are discussed in the light of these trust
    models.  The threat catalog is aimed to be exhaustive, but it is
    likely that some threats are still missing.  Thus, ideas for new
    threats to consider are solicited.

1.1 Remarks

    Note that the SEND WG charter limits the scope of the working group
    to secure Neighbor Discovery functions.  Furthermore, the charter
    explicitly mentions zero configuration as a fundamental goal behind
    Neighbor discovery.  Network access authentication and access control
    are outside the scope of this work.

    During the discussions while preparing this document, the following
    aspects that may help to evaluate the eventual solutions were
    mentioned.

       Zero configuration

       Interaction with access control solutions

       Scalability

       Efficiency

    However, The main evaluation criteria is formed by the trust models
    and threat lists.

    [[This document occasionally discusses solution proposals, such as
    CGA [10]  and ABK [9]. However, the discussion is solely for
    illustrative purposes.  It is meant to give the readers a more
    concrete idea of some possible solutions.  It does NOT indicate any
    preference on solutions on the behalf of the authors or the working
    group.  In this version of this draft, all "solution talk" is
    enclosed in double brackets, just like this paragraph.]]

    It should be noted that the term "trust" is used here in a rather
    non-technical manner.  The most appropriate interpretation is to
    consider it as an expression of an organizational or collective
    belief, i.e., an expression of commonly shared beliefs about the
    future behavior of the other involved parties. Conversely, the term
    "trust relationship" denotes a mutual a priori relationship between
    the involved organizations or parties where the parties believe that
    the other parties will behave correctly even in the future.  A trust
    relationship makes it possible to configure authentication and
    authorization information between the parties, while the lack of such
    a relationship makes it impossible to pre-configure such information.

---

From: "James Kempf" <[email-masked]>
Date: Thu, 13 Mar 2003 09:08:51 -0800

looks good.

            jak