[dtn-security] Re(many): Is there a "secure" referenceimplementation of the DTN stack?

Peter Lovell <plovell@mac.com> Tue, 30 June 2009 12:30 UTC

Received: from asmtpout020.mac.com (asmtpout020.mac.com []) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id n5UCUioC003347 for <dtn-security@maillists.intel-research.net>; Tue, 30 Jun 2009 05:30:44 -0700
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: text/plain; charset=ISO-8859-1
Received: from [] (dsl092-149-198.wdc2.dsl.speakeasy.net []) by asmtp020.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KM100JX9XBVE180@asmtp020.mac.com> for dtn-security@maillists.intel-research.net; Tue, 30 Jun 2009 05:28:46 -0700 (PDT)
From: Peter Lovell <plovell@mac.com>
To: "Graham Keellings (Leonix Solutions Pte Ltd)" <Graham@LeonixSolutions.com>, "Eddy, Wesley M. (GRC-MS00)[Verizon]" <wesley.m.eddy@nasa.gov>
Date: Tue, 30 Jun 2009 08:28:42 -0400
Message-id: <20090630122842.1049441707@smtp.mac.com>
In-reply-to: <4A497B04.3070909@LeonixSolutions.com>
References: <89E48AE60E64EF4E8EB32B0B7EC74920A1B0F5@EVS-EC1-NODE2.surrey.ac.uk> <4A12195A.6000207@LeonixSolutions.com> <"3A5AA67A8B120B48825BFFCF544385613 7E0B06196"@NDJSSCC03.ndc.nasa.gov> <4A1DD73F.50000@bbn.com> <023601c9df2a$694fd5b0$3bef8110$@com> <4A2DF7FD.5020104@LeonixSolutions.com> <3A5AA67A8B120B48825BFFCF5443856137E3553C4B@NDJSSCC03.ndc.nasa.gov> <"029d01c 9e925$1e354880$5a9fd980$"@com> <4A46C257.3040006@LeonixSolutions.com> <"2009062 8050243.1566215671"@smtp.mac.com> <4A46FBB2.3080205@LeonixSolutions.com> <"2009 0628052255.640550503"@smtp.mac.com> <4A470CD7.4010502@LeonixSolutions.com> <"20 090628141313.1532044204"@smtp.mac.com> <4A4878A6.7010707@LeonixSolutions.com> <20090629123400.1726285002@smtp.mac.com> <C304DB494AC0C04C87C6A6E2FF5603DB2217B29183@NDJSSCC01.ndc.nasa.gov> <4A497B04.3070909@LeonixSolutions.com>
X-Mailer: CTM PowerMail version 6.0.2 build 4601 English (intel) <http://www.ctmdev.com>
Cc: dtn-security@maillists.intel-research.net
Subject: [dtn-security] Re(many): Is there a "secure" referenceimplementation of the DTN stack?
X-BeenThere: dtn-security@maillists.intel-research.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DTN Security Discussion <dtn-security.maillists.intel-research.net>
List-Unsubscribe: <http://maillists.intel-research.net/mailman/listinfo/dtn-security>, <mailto:dtn-security-request@maillists.intel-research.net?subject=unsubscribe>
List-Archive: <http://maillists.intel-research.net/pipermail/dtn-security>
List-Post: <mailto:dtn-security@maillists.intel-research.net>
List-Help: <mailto:dtn-security-request@maillists.intel-research.net?subject=help>
List-Subscribe: <http://maillists.intel-research.net/mailman/listinfo/dtn-security>, <mailto:dtn-security-request@maillists.intel-research.net?subject=subscribe>
X-List-Received-Date: Tue, 30 Jun 2009 12:30:44 -0000

Hi Graham,

yes - an ad-hoc key server in a DTN environment doesn't make a lot of sense.

We've tended to use PKI keys in examples as they simplify the
distribution issue and have reasonable lifetimes for the tasks but, as
you point out, key loss is problematic. Requiring CRL access does rather
defeat the whole point of DTN.

If it is important that you react very quickly to key loss, then group
keying may be a better solution. If a node is compromised, the group is
rekeyed as quickly as the key server can do it (after it finds out).
Some nodes might be disconnected for a while and still have old keys but
they won't be getting much (or any) traffic so this can be dealt with.
The new key from the key server should arrive about the same time as any
bundles using the new key. Obviously, group membership in this scenario
is based upon being authorized, rather than which authorized nodes are
currently connected (many groups work this way).


On Tue, Jun 30, 2009, Graham Keellings (Leonix Solutions Pte Ltd)
<Graham@LeonixSolutions.com> wrote:

>Eddy, Wesley M. (GRC-MS00)[Verizon] wrote:
>> As Peter mentioned earlier, even with a complete BSP implementation,
>> you still have to figure out how to do key management on your own.
>> This is the hardest and most complex part,
>It certainly is. Since we are worried about security, we can consider
>military or banking use, and think about the use cases, for isntance,
>for 1) initial key distribution to the whole network 2) addition of a
>new member 3) individual key revocation 4) mass update of all key? (if
>even needed, and probably just use case 1)
>Some schemes, like Prophet, seem ok, but, if I understand correctly,
>keys have a specific lifetime and then expire. What if the DTN device
>falls into the wrong hands before then? One would want to revoke it
>immediately, would one not?
>How does one distribute the keys, given that it makes little on no sense
>to have a key server in an ad hoc network? (I suppose that before every
>battle or at the start of each work day, each user could bring their
>device within range of a "secure" key server, but that seems rather
>contrived). If the number of nodes will never vary, then each could be
>pre-programmed with the appropriate keys, but this seems rather
>restrictive, and again there is the problem of revocation.
>This does need some serious thinking, which is probably why I have been
>instructed to "ignore it until a  future release" (lucky me ;-)
>Thanks again for the input. I am now off to struggle with Peter's
>"stony" description of the existing security mechanism.
>With best wishes,
>>  if you need it to scale
>> to some level, be robust to disconnection, delay, and low bandwidth,
>> and if you rely on the established keys to carry critical traffic.
>> The BSP is only part of the solution you need, and the rest is left
>> as an exercise to the user ...
>> ---------------------------
>> Wes Eddy