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

Hi Nasir,

M.Bhutta@surrey.ac.uk 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
argument:-)

>       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
transport/agreement.

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:-)

S.

[1]
http://www.ietf.org/internet-drafts/draft-parikh-bundle-superseding-extension-block-00.txt

> 
> Please comment...
> 
> thanks
> 
> regards,
> Nasir
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> dtn-security mailing list
> dtn-security@maillists.intel-research.net
> http://maillists.intel-research.net/mailman/listinfo/dtn-security