Re: [dtn-security] Key Management hop-by-hop ciphersuite

Stephen Farrell <> Tue, 09 June 2009 10:10 UTC

Received: from ( []) by (8.13.8/8.13.8) with ESMTP id n59AAJOj030248 for <>; Tue, 9 Jun 2009 03:10:20 -0700
Received: from ( by ( with Microsoft SMTP Server id 8.1.340.0; Tue, 9 Jun 2009 10:02:14 +0000
Received: from mail2-sin (localhost.localdomain []) by (Postfix) with ESMTP id 046771650208; Tue, 9 Jun 2009 10:02:14 +0000 (UTC)
X-SpamScore: -35
X-BigFish: VPS-35(zz1418M1432R98dR148cM1805Mzz1202hzz1033ILz2dh6bh17ch87il61h)
X-Spam-TCS-SCL: 0:0
Received: by mail2-sin (MessageSwitch) id 1244541731899065_31084; Tue, 9 Jun 2009 10:02:11 +0000 (UCT)
Received: from ( []) by (Postfix) with ESMTP id 14B87A8052; Tue, 9 Jun 2009 10:02:11 +0000 (UTC)
Received: from Vams.imx2 ( []) by (Postfix) with SMTP id 21F5968005; Tue, 9 Jun 2009 11:02:09 +0100 (IST)
Received: from ([]) by ([]) with SMTP (gateway) id A02988152C8; Tue, 09 Jun 2009 11:02:09 +0100
Received: from [] ( []) by (Postfix) with ESMTP id E989668005; Tue, 9 Jun 2009 11:02:08 +0100 (IST)
Message-ID: <>
Date: Tue, 9 Jun 2009 11:02:09 +0100
From: Stephen Farrell <>
User-Agent: Thunderbird (X11/20090302)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
X-Enigmail-Version: 0.95.7
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-AntiVirus-Status: MessageID = A12988152C8
X-AntiVirus-Status: Host:
X-AntiVirus-Status: Action Taken:
X-AntiVirus-Status: NONE
X-AntiVirus-Status: Checked by TCD Vexira. (version=1.60.2 VDF=10.107.6)
Subject: Re: [dtn-security] Key Management hop-by-hop ciphersuite
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DTN Security Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 09 Jun 2009 10:10:21 -0000

Hi Nasir, wrote:
> Hi,
>>From internet-draft "Key Management Requirements", it is a requirement
> that key management should support all mandatory ciphersuites.

First I wouldn't take that (expired) draft as being something that's
gotten broad consensus - at this stage I think its really just a set
of opinions of mine, but I'm really happy to get others' input, so
thanks for bringing it up.

The point I was trying to make with that requirement is that if someone
does go and define a (generic) key management scheme for DTNs, then they
had better consider the existing ciphersuites. I've seen some papers
both in DTN and more generally related to PKI where the authors
define a key management scheme that won't do that (e.g. I guess some
of the IBE things). The problem with that would be that we'd end up with
a way to establish keys, but no (interoperable) way to use 'em. Were
the authors of such key management schemes to also fully specify
accompanying ciphersuites then I think that'd be fine. (I'm not saying
I'd agree with 'em, but at that point at least we could have a good

>       For Hop-by-Hop integrity and authentication, the ciphersuite
> BAB-HMAC only supports symmetric cryptography..
>      1.  Does this means, when we are looking for key establishment
> while assuming pre-installed public keys, then we also have to take
> assumption that symmetric keys also exist between two nodes for
> hop-by-hop authentication and integrity..

Not necessarily. If you assume pre-installed public keys, then you
could define a new bundle payload protocol (or set of extension
blocks, not sure) that'd allow you to do key transport or key
agreement in order to manage those shared secrets. I'd really like
to see someone write that I-D. The core of that is pretty easy,
it probably just needs to adopt some CMS structures for key

I think the main issue though would be how to gracefully
handle lost or badly delayed bundles.

For example, if a key manager tries to distribute new keys to nodes
1 & 2 but the relevant bundles only arrive at node 1, then how do we
ensure that we don't break BAB verification between nodes 1 & 2?
Probably by allowing some kind of window but there's work to be
done to get that right. Actually that might usefully use the
stuff about superseding bundles [1] now that I think of it.
And/or maybe node 1 could pass along the key mgmt extension
to node 2 similar to how kerberos does things.

Getting that right requires a bit of thought and consideration
of various use cases and failure modes so its non-trivial. (But
again, I'd love to see someone take it on.)

>      2. Are we not making Key Management dependent on distribution of
> symmetric keys between forwarder and intermediate receiver while using
> public key  only..

No. See #1 above:-)



> Please comment...
> thanks
> regards,
> Nasir
> ------------------------------------------------------------------------
> _______________________________________________
> dtn-security mailing list