Re: [dtn-security] Key Distribution

Peter Lovell <plovell@mac.com> Wed, 30 November 2011 01:47 UTC

Return-Path: <plovell@mac.com>
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 92B7A21F899D for <dtn-security@ietfa.amsl.com>; Tue, 29 Nov 2011 17:47:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.203
X-Spam-Level:
X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1]
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 qY5f19OG1MvJ for <dtn-security@ietfa.amsl.com>; Tue, 29 Nov 2011 17:47:20 -0800 (PST)
Received: from asmtpout203.mac.com (st11b01mm-asmtp203.mac.com [17.172.48.66]) by ietfa.amsl.com (Postfix) with ESMTP id 1363E21F888A for <dtn-security@irtf.org>; Tue, 29 Nov 2011 17:47:19 -0800 (PST)
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1
Received: from [192.168.1.98] (pool-71-178-36-205.washdc.fios.verizon.net [71.178.36.205]) by st11b01mm-asmtp203.mac.com (Oracle Communications Messaging Server 7u4-23.01(7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTPSA id <0LVG00AACAASGO30@st11b01mm-asmtp203.mac.com> for dtn-security@irtf.org; Tue, 29 Nov 2011 17:47:18 -0800 (PST)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.5.7110, 1.0.211, 0.0.0000 definitions=2011-11-29_09:2011-11-30, 2011-11-29, 1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1012030000 definitions=main-1111290279
From: Peter Lovell <plovell@mac.com>
To: Ian Glennon <ianglennon@gmail.com>
Date: Tue, 29 Nov 2011 20:47:15 -0500
Message-id: <20111130014715.2143405755@smtp.mac.com>
In-reply-to: <CAJCiAQ2PrKM5WkCbs3CuLNy8HpxvzdkJw8uavx0qpdjF4yF0bQ@mail.gmail.com>
References: <CAJCiAQ2PrKM5WkCbs3CuLNy8HpxvzdkJw8uavx0qpdjF4yF0bQ@mail.gmail.com>
X-Mailer: CTM PowerMail version 6.1 build 4643 English (intel) <http://www.ctmdev.com>
Content-transfer-encoding: quoted-printable
Cc: Peter Lovell <dtnbsp@gmail.com>, 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: Wed, 30 Nov 2011 01:47:20 -0000

On Tue, Nov 29, 2011, Ian Glennon <ianglennon@gmail.com> 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
>ianglennon@gmail.com

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