Re: [dtn-security] Key Distribution

[Peter Lovell <[e-mail]>]

On Tue, Nov 29, 2011, Ian Glennon <[e-mail]> wrote:

>I'm considering the following situation...
>
>Nodes A, B and C are Security Aware DTN Nodes.  Node B is an
>intermediate DTN node which handles bundles from Node A to Node C.  
>
>1) Node A wishes to encrypt a payload for Node C but does not have a
>local copy of the public key for Node C.  Node A will sign the payload
>using its private key.  How does Node A obtain the public key?
>
>2) Assuming Node A can obtain Node C's public key, Node B wishes to
>verify the integrity of the payload.  How does Node B obtain Node A's
>public key?
>
>3) On receiving the bundle from Node A, Node C wishes to verify the
>integrity of the payload.  How does Node C obtain Node A's public key?
>
>Now clearly the answer to 2) will be the same as that for 3), and also
>probably the same for 1).  I am considering some kind of Key
>Distribution Node, which would manage the distribution of the public
>keys to the various DTN nodes.  At what point, though, would the key
>request be made?  Would it be made within the DTN protocol, or would it
>be made by some application receiving the bundle payload?  My guess is
>it would be within the DTN protocol - certainly for 2) as the
>verification is handled by the protocol rather than some application
>overlaying the protocol.
>
>You may see where I'm going with this - a Key Distribution Network
>consisting of nodes handling the distribution of public keys - but I'm
>not sure whether requests to a node within the KDNetwork needs to be
>integrated into the DTN protocol, or whether it can be an application
>receiving requests which sits above the DTN protocol.
>
>Any help, guidance or advice gratefully received.
>
>Ian Glennon
>[e-mail]

Hi Ian,

it seems that the sample problem is to send a bundle from A to C with encryption protecting the payload, and also to have one or more intermediate nodes verify the integrity on the way.

Of course, the intermediate nodes can't verify the actual payload but only the encrypted payload. I think that's what you meant.

Nodes B and C will have A's public key if A was smart enough to include it in the PIB key-info item. The key might have a full certificate chain in which case B and C only need to satisfy themselves of the validity of the root. However if it's partial then B and C will need to have/obtain the rest of the chain some other way.

If A encrypts the bundle using ciphersuite PC3 then C gets data-integrity-check for free, as that's one of the things that AES-GCM does. C doesn't need a pubkey for this - just its own private key. This is of no help for B as it's part of the decrypt process (which we presume is not available to B since it requires C's private key). 

There's no specific mechanism for A to obtain C's public key, other than receiving a bundle from C and caching the key and certificate chain. If you want to do a distribution network then that probably would be above the DTN protocol layer. 

It would be simple to have a scheme whereby A could contact C directly with a signed echo-request (content TBD). This would include A's pubkey, which B and C could cache. The response would have C's pubkey within the PIB response. There are valid arguments
in favour of different keys for encrypting and signing so the scheme might need minor embellishment, but you have the idea. Direct-connect is simpler - as long as the network characteristics are suitable.

Cheers.....Peter