From daniel.hao.zhuang@gmail.com Wed Nov 2 03:44:50 2011 Return-Path: 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 513EA11E815E for ; Wed, 2 Nov 2011 03:44:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.996 X-Spam-Level: X-Spam-Status: No, score=-2.996 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_LOW=-1, WEIRD_PORT=0.001] 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 amZMTOaKPMKj for ; Wed, 2 Nov 2011 03:44:49 -0700 (PDT) Received: from mail-qy0-f175.google.com (mail-qy0-f175.google.com [209.85.216.175]) by ietfa.amsl.com (Postfix) with ESMTP id AF19621F8C0A for ; Wed, 2 Nov 2011 03:44:47 -0700 (PDT) Received: by qyc1 with SMTP id 1so1377721qyc.13 for ; Wed, 02 Nov 2011 03:44:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=JZAeXaLDQ/3IQt4gr1Gjpq5L1mwptu8A3qr96D0Gizg=; b=xblEe4NgJF77ZilEKkjQhZn/jY8Ed3Pb21oi9GzT9ZMOycd8xniqBEChKtV9h1jEuI CC8Rf29n/AnQn83QyYq3eh9qOAuHBRv+uqezz0c6UdnoL7OxiU6lBN6wCCttA5ziyk4q gWHF1Z/tpiCRfPuXFhnxf3twrdG0a+fGgHMz0= MIME-Version: 1.0 Received: by 10.182.41.69 with SMTP id d5mr760479obl.47.1320230685981; Wed, 02 Nov 2011 03:44:45 -0700 (PDT) Received: by 10.182.145.99 with HTTP; Wed, 2 Nov 2011 03:44:45 -0700 (PDT) Date: Wed, 2 Nov 2011 11:44:45 +0100 Message-ID: From: Hao Zhuang To: dtn-security@irtf.org Content-Type: multipart/alternative; boundary=f46d0444e96b0f3b2404b0be29a3 X-Mailman-Approved-At: Wed, 02 Nov 2011 03:56:27 -0700 Cc: Anitha Kathirvel , herve.ntareme@gamil.com, Xuelin Xiong Subject: [dtn-security] Security implementation in Prophet rouing X-BeenThere: dtn-security@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Security." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2011 10:46:26 -0000 --f46d0444e96b0f3b2404b0be29a3 Content-Type: text/plain; charset=ISO-8859-1 Hi all, We are going to transport the security implementation from* static routing*to *Prophet routing*. In static routing, keystore files are imported to each device and dtn software can find the correct destination's public key to encrypt the symmetric key before sending the bundles. However, in Propheting routing, how to get the right public key from the destination? In static routing, dtn configure file ************************************************************************************ * // it can get the right destination public keys* ************************************************************************************ *Now, in dynamic routing, the configure file is below* ************************************************************************************ * //nothing in the link section* ************************************************************************************ Is there any idea on key transport under the environment of* prophet routing *? Thank you for your time. Sincerely, Hao --f46d0444e96b0f3b2404b0be29a3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all,
We are going to transport the security implementation from= static routing to Prophet routing. In static routing,=A0keystore files are imported to each device and dtn softwa= re can find the correct destination's public key to encrypt the symmetr= ic key before sending the bundles. However, in Propheting routing, how to g= et the right public key from the destination?
In static = routing, dtn configure file=A0
*******************************************= *****************************************
<tns:LinksSetting>= ;
<!-- =A0Setup your links here -->
=A0 =A0 =A0<tns:L= ink id=3D"village_tcp_link" conv_layer_type=3D"tcp" des= t=3D"192.168.1.2:4556" type=3D"ONDEMAND&qu= ot;/>
=A0 =A0 =A0<tns:Link id=3D"city_tcp_link" conv_layer_type= =3D"tcp" dest=3D"192.168.2.3:4556" ty= pe=3D"ONDEMAND"/>
=A0 =A0 =A0<tns:Link id=3D"androidLaptop_tcp_link" conv_l= ayer_type=3D"tcp" dest=3D"192.168.2.25:4556" type=3D"ONDEMAND"/>
=A0 =A0 =A0<tns:Link id=3D"tattoo_tcp_link" conv_layer_ty= pe=3D"tcp" dest=3D"192.168.1.29:4556"= ; type=3D"ONDEMAND"/>
</tns:LinksSetting>
<!-- =A0Routes Section -->
<tns:RoutesSetting=A0router_type=3D"static"=A0= local_eid=3D"dtn://nexus.bytewalla.com"> = =A0// it can get the = right destination public keys
=A0 =A0 =A0<!-- =A0Setup your routes here -->
=A0 =A0 = =A0<tns:Route dest=3D"dtn://village.bytewalla.c= om/*" link_id=3D"village_tcp_link"/>
=A0 =A0 =A0<tns:Route dest=3D"dtn://city.byte= walla.com/*" link_id=3D"city_tcp_link"/>
= =A0 =A0 =A0<tns:Route dest=3D"dtn://android.byt= ewalla.com/*" link_id=3D"androidLaptop_tcp_link_viaVillage&qu= ot;/>
=A0 =A0 =A0<tns:Route dest=3D"dtn://tattoo.= bytewalla.com/*" link_id=3D"tattoo_tcp_link"/>
<= div></tns:RoutesSetting>
**********************************************************************= **************
Now, in dynamic routing, the configure fil= e is below
**************************************************= **********************************
<!-- =A0Links Section -->
=A0 =A0 <tns:LinksSe= tting>
=A0 =A0 =A0 =A0 <!-- =A0Setup your links here -->= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0=A0 =A0 =A0//nothing in the link section
=A0 =A0 </tns:LinksSetting>

=A0 =A0 <= ;!-- =A0Routes Section -->
=A0 =A0 <tns:RoutesSetting=A0= router_type=3D"prophet"=A0P_encounter=3D"0.5" =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0=A0=A0=A0//this is based on prophet routing<= /font>
=A0 =A0 =A0 =A0 P_encounter_first=3D"0.25" delta=3D"0.0= 1" alpha=3D"0.5" beta=3D"0.9" K=3D"1" qu= euing=3D"Fifo"> =A0 =A0 =A0 =A0 =A0 =A0 =A0
=A0 =A0 = =A0 =A0 <!-- =A0Setup your routes here -->
=A0 =A0 </tns:RoutesSetting>

=A0 =A0 &l= t;tns:DiscoveriesSetting>
=A0 =A0 =A0 =A0 <!-- =A0Setup you= r Discovery here -->
=A0 =A0 =A0 =A0 <tns:Discovery id=3D&q= uot;ipdisc0" address_family=3D"ip" port=3D"9556"&g= t;</tns:Discovery>
=A0 =A0 =A0 =A0 <tns:Announce interface_id=3D"tcp0" disco= very_id=3D"ipdisc0"
=A0 =A0 =A0 =A0 =A0 =A0 conv_layer_= type=3D"tcp"></tns:Announce>
=A0 =A0 </tns:= DiscoveriesSetting>

*************************************************= ***********************************
Is there any idea on key tran= sport under the environment of=A0prophet routing?
=
Thank you for your time.

Sincerely,
Hao

--f46d0444e96b0f3b2404b0be29a3-- From s.shukla@iitp.ac.in Wed Nov 2 04:19:55 2011 Return-Path: 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 9F5361F0C8E for ; Wed, 2 Nov 2011 04:19:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.799 X-Spam-Level: X-Spam-Status: No, score=-0.799 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_102=0.6, J_CHICKENPOX_56=0.6, J_CHICKENPOX_72=0.6] 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 agUNsjlZT1yS for ; Wed, 2 Nov 2011 04:19:55 -0700 (PDT) Received: from magadh.iitp.ac.in (magadh.iitp.ac.in [210.212.18.211]) by ietfa.amsl.com (Postfix) with ESMTP id 532AC1F0C91 for ; Wed, 2 Nov 2011 04:19:54 -0700 (PDT) Received: from ashoka.iitp.ac.in (ashoka.iitp.ac.in [172.16.1.11] (may be forged)) by magadh.iitp.ac.in (8.14.2/8.14.2) with ESMTP id pA2BeUv5027295; Wed, 2 Nov 2011 17:10:31 +0530 Received: from [172.16.1.11] (localhost.localdomain [127.0.0.1]) by ashoka.iitp.ac.in (Postfix) with ESMTP id 5F9B67D625E; Wed, 2 Nov 2011 16:50:35 +0530 (IST) Received: from 172.16.1.4 (SquirrelMail authenticated user s.shukla) by 172.16.1.11 with HTTP; Wed, 2 Nov 2011 16:50:35 +0530 Message-ID: <75e4cb2820331747c270a9fbc401a787.squirrel@172.16.1.11> In-Reply-To: References: Date: Wed, 2 Nov 2011 16:50:35 +0530 From: s.shukla@iitp.ac.in To: "Hao Zhuang" User-Agent: SquirrelMail/ MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: by amavisd-new Cc: Xuelin Xiong , dtn-security@irtf.org, herve.ntareme@gamil.com, Anitha Kathirvel Subject: Re: [dtn-security] Security implementation in Prophet rouing X-BeenThere: dtn-security@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Security." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2011 11:19:55 -0000 Hi Daniel, I am novice in this area but somthing strike on my mind so I want to share it with you, Prophet works on history of encounters(so whenever source node encounter relay it will store its public key for future reference). In case destination is not available in history of encounters then source will use second property of prophet i.e transitivity for 1 hop encryption. I hope my suggestions is correct and useful for you... :) best/ Shailendra. > Hi all, > We are going to transport the security implementation from* static > routing*to > *Prophet routing*. In static routing, keystore files are imported to each > device and dtn software can find the correct destination's public key to > encrypt the symmetric key before sending the bundles. However, in > Propheting routing, how to get the right public key from the destination? > In static routing, dtn configure file > ************************************************************************************ > > > > > > conv_layer_type="tcp" > dest="192.168.1.25:4556" type="ONDEMAND"/> > > > > * // it can get the right destination public keys* > > link_id="village_tcp_link"/> > link_id="city_tcp_link"/> > link_id="androidLaptop_tcp_link_viaVillage"/> > link_id="tattoo_tcp_link"/> > > ************************************************************************************ > *Now, in dynamic routing, the configure file is below* > ************************************************************************************ > > > * > //nothing > in the link section* > > > > * //this is based on prophet routing* > P_encounter_first="0.25" delta="0.01" alpha="0.5" beta="0.9" K="1" > queuing="Fifo"> > > > > > > port="9556"> > conv_layer_type="tcp"> > > > ************************************************************************************ > Is there any idea on key transport under the environment of* prophet > routing > *? > Thank you for your time. > > Sincerely, > Hao > _______________________________________________ > dtn-security mailing list > dtn-security@irtf.org > https://www.irtf.org/mailman/listinfo/dtn-security > ################################################### // Double the Pride,Double the Fall // From ianglennon@gmail.com Tue Nov 29 13:26:39 2011 Return-Path: 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 3C82B11E80C4 for ; Tue, 29 Nov 2011 13:26:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 P2JVx9q8mtIH for ; Tue, 29 Nov 2011 13:26:35 -0800 (PST) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by ietfa.amsl.com (Postfix) with ESMTP id 723E621F8BBA for ; Tue, 29 Nov 2011 13:26:34 -0800 (PST) Received: by yenq9 with SMTP id q9so9872471yen.13 for ; Tue, 29 Nov 2011 13:26:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=SJvyGkv/nd/sNwqBaNiAix+CLiZEj9Toqng+gDKczRs=; b=a+wQ+PV/LoCYkXdxvnHRrrZZveU5Z6PSt4ymEWmdNvnomvCXgiCK6Rg/aWzN5t3jsq e5YYC7cLKcRgWcbyWBBaeheVJcg0lX+wuF2bXdVDmYETgjCsUq4D2dEOQJEZC3XMrWdo k89RGCBp2xY/b56VepC0Mje/er8IDfqUHHuhI= MIME-Version: 1.0 Received: by 10.68.5.162 with SMTP id t2mr776677pbt.73.1322601993633; Tue, 29 Nov 2011 13:26:33 -0800 (PST) Received: by 10.143.163.11 with HTTP; Tue, 29 Nov 2011 13:26:33 -0800 (PST) Date: Tue, 29 Nov 2011 21:26:33 +0000 Message-ID: From: Ian Glennon To: dtn-security@irtf.org Content-Type: multipart/alternative; boundary=bcaec52159a502814404b2e646ca Subject: [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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Nov 2011 21:26:39 -0000 --bcaec52159a502814404b2e646ca Content-Type: text/plain; charset=ISO-8859-1 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 --bcaec52159a502814404b2e646ca Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I'm considering the following situation...

Nodes A, B and C are= =20 Security Aware DTN Nodes.=A0 Node B is an intermediate DTN node which=20 handles bundles from Node A to Node C.=A0

1) Node A wishes to=20 encrypt a payload for Node C but does not have a local copy of the=20 public key for Node C.=A0 Node A will sign the payload using its private=20 key.=A0 How does Node A obtain the public key?

2) Assuming Node A can obtain Node C's public key, Node B wishes to= =20 verify the integrity of the payload.=A0 How does Node B obtain Node A's= =20 public key?

3) On receiving the bundle from Node A, Node C wishes to verify the integrity of the payload.=A0 How does Node C obtain Node=20 A's public key?

Now clearly the answer to 2) will be the same as that for 3), and=20 also probably the same for 1).=A0 I am considering some kind of Key=20 Distribution Node, which would manage the distribution of the public=20 keys to the various DTN nodes.=A0 At what point, though, would the key=20 request be made?=A0 Would it be made within the DTN protocol, or would it= =20 be made by some application receiving the bundle payload?=A0 My guess is=20 it would be within the DTN protocol - certainly for 2) as the=20 verification is handled by the protocol rather than some application=20 overlaying the protocol.

You may see where I'm going with this - a Key Distribution Network= =20 consisting of nodes handling the distribution of public keys - but I'm= =20 not sure whether requests to a node within the KDNetwork needs to be=20 integrated into the DTN protocol, or whether it can be an application=20 receiving requests which sits above the DTN protocol.

Any help, guidance or advice gratefully received.

Ian Glennon
ianglennon@gmail.com --bcaec52159a502814404b2e646ca-- From dennis.c.iannicca@nasa.gov Tue Nov 29 14:23:20 2011 Return-Path: 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 ; 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 ; 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 ; 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)" To: Ian Glennon 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: In-Reply-To: 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" 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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... >=20 > 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. =20 >=20 > 1) Node A wishes to encrypt a payload for Node C but does not have a loca= l copy of the public key for Node C. Node A will sign the payload using it= s private key. How does Node A obtain the public key? >=20 > 2) Assuming Node A can obtain Node C's public key, Node B wishes to verif= y the integrity of the payload. How does Node B obtain Node A's public key= ? >=20 > 3) On receiving the bundle from Node A, Node C wishes to verify the integ= rity of the payload. How does Node C obtain Node A's public key? >=20 > Now clearly the answer to 2) will be the same as that for 3), and also pr= obably the same for 1). I am considering some kind of Key Distribution Nod= e, which would manage the distribution of the public keys to the various DT= N nodes. At what point, though, would the key request be made? Would it b= e made within the DTN protocol, or would it be made by some application rec= eiving 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 t= han 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 m= echanism into the system so the first node in the path to the key distribut= ion 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 pu= blic keys will trickle out toward the edges of the network. > You may see where I'm going with this - a Key Distribution Network consis= ting of nodes handling the distribution of public keys - but I'm not sure w= hether requests to a node within the KDNetwork needs to be integrated into = the DTN protocol, or whether it can be an application receiving requests wh= ich 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?= From plovell@mac.com Tue Nov 29 17:47:20 2011 Return-Path: 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 ; 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 ; 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 ; 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 To: Ian Glennon Date: Tue, 29 Nov 2011 20:47:15 -0500 Message-id: <20111130014715.2143405755@smtp.mac.com> In-reply-to: References: X-Mailer: CTM PowerMail version 6.1 build 4643 English (intel) Content-transfer-encoding: quoted-printable Cc: Peter Lovell , 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2011 01:47:20 -0000 On Tue, Nov 29, 2011, Ian Glennon wrote: >I'm considering the following situation... > >Nodes A, B and C are Security Aware DTN Nodes.=A0 Node B is an >intermediate DTN node which handles bundles from Node A to Node C.=A0 > >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.=A0 Node A will sign the payload >using its private key.=A0 How does Node A obtain the public key=3F > >2) Assuming Node A can obtain Node C's public key, Node B wishes to >verify the integrity of the payload.=A0 How does Node B obtain Node A's >public key=3F > >3) On receiving the bundle from Node A, Node C wishes to verify the >integrity of the payload.=A0 How does Node C obtain Node A's public key=3F > >Now clearly the answer to 2) will be the same as that for 3), and also >probably the same for 1).=A0 I am considering some kind of Key >Distribution Node, which would manage the distribution of the public >keys to the various DTN nodes.=A0 At what point, though, would the key >request be made=3F=A0 Would it be made within the DTN protocol, or would it >be made by some application receiving the bundle payload=3F=A0 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