Re: [dtn-security] Key Distribution

"Iannicca, Dennis C. (GRC-RHN0)" <dennis.c.iannicca@nasa.gov> Tue, 29 November 2011 22:23 UTC

Return-Path: <dennis.c.iannicca@nasa.gov>
X-Original-To: dtn-security@ietfa.amsl.com
Delivered-To: dtn-security@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 898C311E8139 for <dtn-security@ietfa.amsl.com>; Tue, 29 Nov 2011 14:23:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gd8+zxKOhacn for <dtn-security@ietfa.amsl.com>; Tue, 29 Nov 2011 14:23:20 -0800 (PST)
Received: from ndmsnpf01.ndc.nasa.gov (ndmsnpf01.ndc.nasa.gov [198.117.0.121]) by ietfa.amsl.com (Postfix) with ESMTP id 66B0D11E8129 for <dtn-security@irtf.org>; Tue, 29 Nov 2011 14:23:19 -0800 (PST)
Received: from ndjsppt03.ndc.nasa.gov (ndjsppt03.ndc.nasa.gov [198.117.1.102]) by ndmsnpf01.ndc.nasa.gov (Postfix) with ESMTP id 9E81D260584; Tue, 29 Nov 2011 16:23:18 -0600 (CST)
Received: from ndjshub02.ndc.nasa.gov (ndjshub02-pub.ndc.nasa.gov [198.117.1.161]) by ndjsppt03.ndc.nasa.gov (8.14.4/8.14.4) with ESMTP id pATMNIfQ028842; Tue, 29 Nov 2011 16:23:18 -0600
Received: from NDJSSCC04.ndc.nasa.gov ([10.58.58.14]) by ndjshub02.ndc.nasa.gov ([198.117.1.161]) with mapi; Tue, 29 Nov 2011 16:23:18 -0600
From: "Iannicca, Dennis C. (GRC-RHN0)" <dennis.c.iannicca@nasa.gov>
To: Ian Glennon <ianglennon@gmail.com>
Date: Tue, 29 Nov 2011 16:23:17 -0600
Thread-Topic: [dtn-security] Key Distribution
Thread-Index: Acyu5X6oPsXSJqQKS+OVqrMwUYPNlQ==
Message-ID: <9F2C0FCD-1720-469C-B7C2-576EAEEA7EC9@nasa.gov>
References: <CAJCiAQ2PrKM5WkCbs3CuLNy8HpxvzdkJw8uavx0qpdjF4yF0bQ@mail.gmail.com>
In-Reply-To: <CAJCiAQ2PrKM5WkCbs3CuLNy8HpxvzdkJw8uavx0qpdjF4yF0bQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.5.7110, 1.0.211, 0.0.0000 definitions=2011-11-29_08:2011-11-29, 2011-11-29, 1970-01-01 signatures=0
Cc: "dtn-security@irtf.org" <dtn-security@irtf.org>
Subject: Re: [dtn-security] Key Distribution
X-BeenThere: dtn-security@irtf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Security." <dtn-security.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/dtn-security>, <mailto:dtn-security-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/dtn-security>
List-Post: <mailto:dtn-security@irtf.org>
List-Help: <mailto:dtn-security-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/dtn-security>, <mailto:dtn-security-request@irtf.org?subject=subscribe>
X-List-Received-Date: Tue, 29 Nov 2011 22:23:20 -0000

On Nov 29, 2011, at 4:26 PM, Ian Glennon 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.

	I would think you'd want to build that into the DTN protocol since I would imagine you would want to implement some kind of distributed key caching mechanism into the system so the first node in the path to the key distribution node with the valid public key can respond to the originator with it.  That way as your network grows and nodes communicate with each other the public keys will trickle out toward the edges of the network.

> 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.

	We also need to be aware of certificate revocation in the network.  Since the network is presumably disconnected, do we rely on disseminating the CRL via some kind of epidemic distribution model?