[dtn-security] Thoughts from a phone call today...

Stephen Farrell <stephen.farrell@cs.tcd.ie> Mon, 04 April 2005 18:07 UTC

Received: from smtp3.tcd.ie (smtp3.tcd.ie []) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id j34I7KV20680 for <dtn-security@mailman.dtnrg.org>; Mon, 4 Apr 2005 11:07:21 -0700
Received: from Vams.smtp3 (smtp3.tcd.ie []) by smtp3.tcd.ie (Postfix) with SMTP id A54ED14C027 for <dtn-security@mailman.dtnrg.org>; Mon, 4 Apr 2005 19:07:14 +0100 (IST)
Received: from smtp3.tcd.ie ([]) by smtp3.tcd.ie ([]) with SMTP (gateway) id A07D0B8822B; Mon, 04 Apr 2005 19:07:14 +0100
Received: from [] (mme145079.mme.tcd.ie []) by smtp3.tcd.ie (Postfix) with ESMTP id 73CB414C027 for <dtn-security@mailman.dtnrg.org>; Mon, 4 Apr 2005 19:07:14 +0100 (IST)
Message-ID: <425182F0.9070906@cs.tcd.ie>
Date: Mon, 04 Apr 2005 19:09:52 +0100
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: dtn-security@mailman.dtnrg.org
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-AntiVirus-Status: Checked by TCD Vexira. (version=1.55.010 VDF=8.663)
X-AntiVirus-Status: NONE
X-AntiVirus-Status: Action Taken:
X-AntiVirus-Status: Host: smtp3.tcd.ie
X-AntiVirus-Status: MessageID = A17D0B8822B
Subject: [dtn-security] Thoughts from a phone call today...
Sender: dtn-security-admin@mailman.dtnrg.org
Errors-To: dtn-security-admin@mailman.dtnrg.org
X-BeenThere: dtn-security@mailman.dtnrg.org
X-Mailman-Version: 2.0.13
Precedence: bulk
Reply-To: dtn-security@mailman.dtnrg.org
List-Unsubscribe: <http://mailman.dtnrg.org/mailman/listinfo/dtn-security>, <mailto:dtn-security-request@mailman.dtnrg.org?subject=unsubscribe>
List-Id: DTN Security Discussion <dtn-security.mailman.dtnrg.org>
List-Post: <mailto:dtn-security@mailman.dtnrg.org>
List-Help: <mailto:dtn-security-request@mailman.dtnrg.org?subject=help>
List-Subscribe: <http://mailman.dtnrg.org/mailman/listinfo/dtn-security>, <mailto:dtn-security-request@mailman.dtnrg.org?subject=subscribe>
List-Archive: <http://mailman.dtnrg.org/pipermail/dtn-security/>

Since we'd all read & commented Susan's document, Susan,
Howie and I had a phone call today to chat about that.
(If anyones interested in being part of any future such
phone calls, let us know, though we've nothing planned right

Subject to Susan or Howie correcting me, I think we more-or-
less agreed about the things below. We figured it'd be good
to first have whatever discussion (if any) we need on this
list and then forward the resulting concensus (if any!) to
the main dtn-interest list, since some of these positions
do represent changes. After that we can reflect the
appropriate changes to the security overview and (TBD)
protocol documents and go from there.

So, you should comment here if you care about this stuff.
(And if you don't: why are you reading this? :-)

Anyway here goes:-

- We think that whatever security primitives we define
   ought to be RECOMMENDED to implement and OPTIONAL to use
   (using RFC 2119 terminology). The main reasons for this
   are the very constrained hosts that may exist in some
   networks (e.g. sensor nets) which simply won't be able
   to implement crypto stuff, but also more practically,
   the fact that whatever key management scheme you care
   to define, there'll always be some cases where you
   can't get the keys in place before you want to send
   some bundles.

- On a related topic, if some DTN nodes which don't
   implement security (e.g. a collection of sensors) send
   their bundles via some more capable gateway bundle
   router, then we believe that that router ought to be
   able to "turn on" security for those bundles, for both
   end-to-end and hop-by-hop services. (This is not quite
   the same as a VPN tunnel, since there is only one
   "middlebox" which is required.)

- Due to the optional nature of security, we believe that
   each and every bundle router has to at least implicitly
   make a security policy decision as to how to handle
   all inbound bundles, and which (if any) security services
   to apply to outbound bundles. We think the PEP/PDP
   terminology common in AAA contexts might provide a useful
   way to think about this. We don't think that there's a
   need at this stage to define a standard way for DTNs to
   push/pull policy information around, given that there
   are standard ways to do that for many lower layers
   (e.g. RADIUS/DIAMETER/COPS etc.). This also calls into
   question the "special" category of security policy
   router, since every bundle router is making security
   policy decisions, even if for many routers, these are
   very, very simple ones (e.g. "well-formed=>forward").

- We think that DTNs ought to be able to provide more-or-less
   the same cryptographic security services as are provided by
   S/MIME or IPSec, but both for end-to-end and hop-by-hop uses
   (i.e. using PSH and BAH). In particular we consider that
   end-to-end confidentiality ought to be a security service
   that can be provided by DTNs. (If accepted, this would be a
   change to the status-quo.)

- We think that DTN security requires some key management
   scheme(s) be defined, but we're not sure that it'd be correct
   to pick one key management scheme and mandate that everywhere,
   i.e. saying that a kerberos or PKI or IBE based scheme is
   the one and only correct way to do DTN key managment would
   be a mistake. However, we also feel that we will need to
   define at least one key management scheme which is geared
   towards interoperability, even if this is somewhat at the
   expense of security! We may end up doing something like
   what's done with SSH, where initial connections are highly
   vulnerable against active attacks, but where, if those
   initial connections were not attacked, subsequent connections
   can be considered strongly protected.

- We still think that reactive fragmentation is a pain, but
   we can maybe handle it a bit better by having a flexible
   data structure for BAH which allows for inclusion of
   multiple authenticators each covering some headers and
   a (possibly empty) range of payload bytes. [Note: we're
   not sure where these'd be carried in the bundle.] This
   represents a slight generalisation of the "toilet paper"
   solution to reactive fragmentation.

- I probably forgot other stuff:-)