[dtn-security] Thoughts from a phone call today...
Stephen Farrell <email@example.com> Mon, 04 April 2005 18:07 UTC
Received: from smtp3.tcd.ie (smtp3.tcd.ie [22.214.171.124]) by
webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id j34I7KV20680
for <firstname.lastname@example.org>; Mon, 4 Apr 2005 11:07:21 -0700
Received: from Vams.smtp3 (smtp3.tcd.ie [126.96.36.199]) by smtp3.tcd.ie (Postfix) with SMTP id A54ED14C027 for <email@example.com>; Mon, 4 Apr 2005 19:07:14 +0100 (IST)
Received: from smtp3.tcd.ie ([188.8.131.52]) by smtp3.tcd.ie ([184.108.40.206]) with SMTP (gateway) id A07D0B8822B; Mon, 04 Apr 2005 19:07:14 +0100
Received: from [220.127.116.11] (mme145079.mme.tcd.ie [18.104.22.168]) by smtp3.tcd.ie (Postfix) with ESMTP id 73CB414C027 for <firstname.lastname@example.org>; Mon, 4 Apr 2005 19:07:14 +0100 (IST)
Date: Mon, 04 Apr 2005 19:09:52 +0100
From: Stephen Farrell <email@example.com>
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
Content-Type: text/plain; charset=us-ascii; format=flowed
X-AntiVirus-Status: Checked by TCD Vexira. (version=1.55.010 VDF=8.663)
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...
List-Unsubscribe: <http://mailman.dtnrg.org/mailman/listinfo/dtn-security>, <mailto:firstname.lastname@example.org?subject=unsubscribe>
List-Id: DTN Security Discussion <dtn-security.mailman.dtnrg.org>
List-Subscribe: <http://mailman.dtnrg.org/mailman/listinfo/dtn-security>, <mailto:email@example.com?subject=subscribe>
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 now.) 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:-) Stephen.
- [dtn-security] Thoughts from a phone call today... Stephen Farrell