Re: [dtn-security] Re(2): Re(2): Is there a "secure" referenceimplementation of the DTN stack?
"Graham Keellings (Leonix Solutions Pte Ltd)" <Graham@LeonixSolutions.com> Tue, 30 June 2009 02:42 UTC
Received: from sky.fastbighost.net (sky.fastbighost.net [76.76.22.153]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id n5U2g62v008627 for <dtn-security@maillists.intel-research.net>; Mon, 29 Jun 2009 19:42:06 -0700
Received: from dyn98-b60-access.superdsl.com.sg ([202.73.60.98] helo=[192.9.200.138]) by sky.fastbighost.net with esmtpa (Exim 4.69) (envelope-from <Graham@LeonixSolutions.com>) id 1MLTGM-0006uo-LG; Mon, 29 Jun 2009 22:40:08 -0400
Message-ID: <4A497B04.3070909@LeonixSolutions.com>
Date: Tue, 30 Jun 2009 10:40:04 +0800
From: "Graham Keellings (Leonix Solutions Pte Ltd)" <Graham@LeonixSolutions.com>
Organization: Leonix Solutions Pte Ltd
User-Agent: Thunderbird 2.0.0.22 (X11/20090608)
MIME-Version: 1.0
To: "Eddy, Wesley M. (GRC-MS00)[Verizon]" <wesley.m.eddy@nasa.gov>
References: <89E48AE60E64EF4E8EB32B0B7EC74920A1B0F5@EVS-EC1-NODE2.surrey.ac. uk><4A12195A.6000207@LeonixSolutions.com><3A5AA67A8B120B48825BFFCF544385613 7E0B06196@NDJSSCC03.ndc.nasa.gov><4A1DD73F.50000@bbn.com> <023601c9df2a$694fd5b0$3bef8110$@com><4A2DF7FD.5020104@LeonixSolutions.com> <3A5AA67A8B120B48825BFFCF5443856137E3553C4B@NDJSSCC03.ndc.nasa.gov><029d01c 9e925$1e354880$5a9fd980$@com><4A46C257.3040006@LeonixSolutions.com><2009062 8050243.1566215671@smtp.mac.com><4A46FBB2.3080205@LeonixSolutions.com><2009 0628052255.640550503@smtp.mac.com><4A470CD7.4010502@LeonixSolutions.com><20 090628141313.1532044204@smtp.mac.com><4A4878A6.7010707@LeonixSolutions.com> <20090629123400.1726285002@smtp.mac.com> <C304DB494AC0C04C87C6A6E2FF5603DB2217B29183@NDJSSCC01.ndc.nasa.gov>
In-Reply-To: <C304DB494AC0C04C87C6A6E2FF5603DB2217B29183@NDJSSCC01.ndc.nasa.gov>
Content-Type: multipart/mixed; boundary="------------090301010606060002070700"
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - sky.fastbighost.net
X-AntiAbuse: Original Domain - maillists.intel-research.net
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - LeonixSolutions.com
X-Source:
X-Source-Args:
X-Source-Dir:
Cc: "dtn-security@maillists.intel-research.net" <dtn-security@maillists.intel-research.net>
Subject: Re: [dtn-security] Re(2): Re(2): Is there a "secure" referenceimplementation of the DTN stack?
X-BeenThere: dtn-security@maillists.intel-research.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DTN Security Discussion <dtn-security.maillists.intel-research.net>
List-Unsubscribe: <http://maillists.intel-research.net/mailman/listinfo/dtn-security>, <mailto:dtn-security-request@maillists.intel-research.net?subject=unsubscribe>
List-Archive: <http://maillists.intel-research.net/pipermail/dtn-security>
List-Post: <mailto:dtn-security@maillists.intel-research.net>
List-Help: <mailto:dtn-security-request@maillists.intel-research.net?subject=help>
List-Subscribe: <http://maillists.intel-research.net/mailman/listinfo/dtn-security>, <mailto:dtn-security-request@maillists.intel-research.net?subject=subscribe>
X-List-Received-Date: Tue, 30 Jun 2009 02:42:07 -0000
Eddy, Wesley M. (GRC-MS00)[Verizon] wrote: > As Peter mentioned earlier, even with a complete BSP implementation, > you still have to figure out how to do key management on your own. > This is the hardest and most complex part, It certainly is. Since we are worried about security, we can consider military or banking use, and think about the use cases, for isntance, for 1) initial key distribution to the whole network 2) addition of a new member 3) individual key revocation 4) mass update of all key? (if even needed, and probably just use case 1) Some schemes, like Prophet, seem ok, but, if I understand correctly, keys have a specific lifetime and then expire. What if the DTN device falls into the wrong hands before then? One would want to revoke it immediately, would one not? How does one distribute the keys, given that it makes little on no sense to have a key server in an ad hoc network? (I suppose that before every battle or at the start of each work day, each user could bring their device within range of a "secure" key server, but that seems rather contrived). If the number of nodes will never vary, then each could be pre-programmed with the appropriate keys, but this seems rather restrictive, and again there is the problem of revocation. This does need some serious thinking, which is probably why I have been instructed to "ignore it until a future release" (lucky me ;-) Thanks again for the input. I am now off to struggle with Peter's "stony" description of the existing security mechanism. With best wishes, Graham > if you need it to scale > to some level, be robust to disconnection, delay, and low bandwidth, > and if you rely on the established keys to carry critical traffic. > The BSP is only part of the solution you need, and the rest is left > as an exercise to the user ... > > --------------------------- > Wes Eddy > Network & Systems Architect > Verizon FNS / NASA GRC > Office: (216) 433-6682 > --------------------------- > > >> -----Original Message----- >> From: dtn-security-bounces@maillists.intel-research.net [mailto:dtn- >> security-bounces@maillists.intel-research.net] On Behalf Of Peter Lovell >> Sent: Monday, June 29, 2009 8:34 AM >> To: Graham Keellings (Leonix Solutions Pte Ltd) >> Cc: dtn-security@maillists.intel-research.net >> Subject: [dtn-security] Re(2): Re(2): Is there a "secure" >> referenceimplementation of the DTN stack? >> >> Hi Graham, >> >> the best document at this time is the Bundle Security Protocol >> Specification, available at <http://tools.ietf.org/id/draft-irtf-dtnrg- >> bundle-security-08.txt> >> >> This is quite a long document and describes both the general approach >> with ciphersuites and the specific implementation of suites for Bundle >> Authentication (BA), Payload Integrity (PI), Payload Confidentiality >> (PC) and Extension Security (EA). In your search for A Rosetta Stone, >> you'll find that this is about as stony as it gets. It will take some >> time to discern the humour in that statement :) >> >> Regards.....Peter >> >> >> >> On Mon, Jun 29, 2009, Graham Keellings (Leonix Solutions Pte Ltd) >> <Graham@LeonixSolutions.com> wrote: >> >> >>> hi, Peter, >>> >>> firs dumb question - is here a single document which discusses the >>> security aspects built into the reference stack? >>> >>> What I have is someone who "wants DTN with security" but only because >>> >> he >> >>> has been told from above that that is what he wants. >>> >>> He wants to take "a slow, phased approach, maybe just starting with >>> adding (H)MAC to the link establish, then working up to more in later >>> phases". It sounds from what you say that HMAC is already there (for >>> data bundles only? Control plane too?) >>> >>> He is not too clear about what he wants, possibly because he himself >>> >> is >> >>> being given instructions which vary. He has a cryptography (but not >>> necessarily a security) expert from the local university who is >>> "analyzing the code to find weak points" - some weeks I am just >>> >> supposed >> >>> to fill these weak points with code, and other weeks I am supposed to >>> >> be >> >>> providing security analysis and advice >>> >>> I have been looking around, but I suppose that I ought have started by >>> asking if there is a Rosseta Stone for security in the reference stack. >>> >>> Sorry to be such a nuisance. >>> >>> Thanks, as always, for your help. >>> >>> With best wishes, >>> >>> Graham >>> >>> >>> >>> Peter Lovell wrote: >>> Hi Graham, >>> >>> threats such as the ones you describe are handled by the Bundle >>> >> Security >> >>> Protocol (BSP) code in the RI. Your application does not have to do >>> encryption etc - that is part of BSP RI code. >>> >>> You *do* have to handle management of keys and that means that you have >>> to write some code that the RI code will call. The thumbnail sketch is >>> that the RI code needs protection applied to something (small, such as >>> an ephemeral key) and your code needs to select an appropriate key and >>> do it. There will be some sample code for this but it's not there yet. >>> >>> Each bundle can have HMAC to protect against changes and also against >>> DOS injection attacks. This is standard already. >>> >>> In short, you'll find that the fundamental capabilities you need are >>> already present but you have to supply the key-management code as >>> appropriate for your key mechanism. >>> >>> Regards.....Peter >>> >>> >>> On Sun, Jun 28, 2009, Graham Keellings (Leonix Solutions Pte Ltd) >>> <Graham@LeonixSolutions.com> wrote: >>> >>> >>> That;'s the problem - I am not a security expert? >>> >>> I guess encryption would be provided by the application which uses DTN? >>> >>> What about add a MAC (or HMAC) for the link established stuff (or even >>> every bundle)? >>> >>> How to denying man in the middle attacks or spoofed bundles, DOS at the >>> network layer by injecting many fake packets? That sort of thing ... >>> >>> Thanks again for your help, Peter. >>> >>> >>> >>> Peter Lovell wrote: >>> >>> Hi Graham, >>> >>> >>> >>> there is an agreed upon standard "reference implementation" of DTN 2.6 >>> and Oasys 1.3, but it lacks security features. >>> >>> >>> what security features do you find missing? The RI is not a turnkey >>> solution but more of a "reference framework". >>> >>> I'm trying to help but am unsure of what's lacking. >>> >>> Regards.....Peter >>> >>> >>> >>> On Sun, Jun 28, 2009, Graham Keellings (Leonix Solutions Pte Ltd) >>> <Graham@LeonixSolutions.com> wrote: >>> >>> >>> >>> hi, Peter, >>> >>> there is an agreed upon standard "reference implementation" of DTN 2.6 >>> and Oasys 1.3, but it lacks security features. >>> >>> Now, let us say that someone wants a "secure" implementation - but >>> doesn't care about the details of "secure", just that it is generally >>> agreed to be "secure" (or (much) more so than the standard >>> implementation. Is there a reference build for that which can be >>> >>> downloaded? >>> >>> My guess is that everyone's perception of "secure" differs and that >>> >> even >> >>> for one person it is a matter of trade-offs, but I just though that I >>> would ask if there is some consensus on what it means for DTN to be >>> "secure". >>> >>> Thanks very much for taking the time to reply. >>> >>> With best wishes, >>> >>> Graham >>> >>> >>> Peter Lovell wrote: >>> >>> >>> On Sun, Jun 28, 2009, Graham Keellings (Leonix Solutions Pte Ltd) >>> <Graham@leonixsolutions.com> wrote: >>> >>> >>> >>> >>> Is there a "secure" reference implementation of the DTN stack available >>> for download? Is there even agreement of what a "secure" implementation >>> should be, or is it all a question of trade-offs? >>> >>> Thanks in advance for any help. >>> >>> Graham >>> >>> >>> >>> Hi Graham, >>> >>> I'm not sure what you're expecting when you refer to a "secure" >>> reference implementation. Do you mean one with the security protocols, >>> or one that had been hardened, or one that has been certified by some >>> organization or other? >>> >>> If you can give a little more context we can help fill in what you >>> >> need. >> >>> Cheers.....Peter >>> >>> >>> >>> >>> >>> -- >>> Technical Director >>> Leonix Solutions (Pte) Ltd >>> 18 Boon Lay Way >>> #09-95 TradeHub 21 >>> Singapore 609966 >>> Telephone:+65 6316 9968 >>> Fax: +65 6316 9208 >>> >>> >>> >>> >>> >>> >>> -- >>> Technical Director >>> Leonix Solutions (Pte) Ltd >>> 18 Boon Lay Way >>> #09-95 TradeHub 21 >>> Singapore 609966 >>> Telephone:+65 6316 9968 >>> Fax: +65 6316 9208 >>> >>> >>> >>> >>> _______________________________________________ >>> dtn-security mailing list >>> dtn-security@maillists.intel-research.net >>> http://maillists.intel-research.net/mailman/listinfo/dtn-security >>> >>> >>> >>> >>> -- >>> Technical Director >>> Leonix Solutions (Pte) Ltd >>> 18 Boon Lay Way >>> #09-95 TradeHub 21 >>> Singapore 609966 >>> Telephone:+65 6316 9968 >>> Fax: +65 6316 9208 >>> >> _______________________________________________ >> dtn-security mailing list >> dtn-security@maillists.intel-research.net >> http://maillists.intel-research.net/mailman/listinfo/dtn-security >> > > -- Technical Director Leonix Solutions (Pte) Ltd 18 Boon Lay Way #09-95 TradeHub 21 Singapore 609966 Telephone:+65 6316 9968 Fax: +65 6316 9208
- [dtn-security] Re(2): [dtn-interest] Bundle Secur… Peter Lovell
- Re: [dtn-security] [dtn-interest] Bundle Security… Hans Kruse
- [dtn-security] Bundle Security Protocol Implement… M.Bhutta
- Re: [dtn-security] Newbie seeking some security r… Armando Caro
- Re: [dtn-security] Newbie seeking some security r… Ivancic, William D. (GRC-RHN0)
- Re: [dtn-security] Newbie seeking some security r… Graham Keellings (Leonix Solutions Pte Ltd)
- Re: [dtn-security] Newbie seeking some security r… Jason Redi
- Re: [dtn-security] Newbie seeking some security r… Armando Caro
- Re: [dtn-security] Newbie seeking some security r… Kristian Erik Hermansen
- Re: [dtn-security] Newbie seeking some security r… Ivancic, William D. (GRC-RHN0)
- Re: [dtn-security] Newbie seeking some security r… Stephen Farrell
- Re: [dtn-security] Newbie seeking some security r… Graham Keellings (Leonix Solutions Pte Ltd)
- Re: [dtn-security] Newbie seeking some security r… Kristian Erik Hermansen
- [dtn-security] Newbie seeking some security relat… Graham Keellings (Leonix Solutions Pte Ltd)
- [dtn-security] Re(many): Is there a "secure" refe… Peter Lovell
- Re: [dtn-security] Re(2): Re(2): Is there a "secu… Graham Keellings (Leonix Solutions Pte Ltd)
- Re: [dtn-security] Is there a "secure" reference … Peter Lovell
- [dtn-security] Re(2): Re(2): Re(2): Is there a "s… Peter Lovell
- [dtn-security] Re(2): Re(2): Is there a "secure" … Peter Lovell
- Re: [dtn-security] Re(2): Is there a "secure" ref… Graham Keellings (Leonix Solutions Pte Ltd)
- [dtn-security] Re(2): Is there a "secure" referen… Peter Lovell
- Re: [dtn-security] Is there a "secure" reference … Graham Keellings (Leonix Solutions Pte Ltd)
- [dtn-security] Re(2): Is there a "secure" referen… Peter Lovell
- Re: [dtn-security] Is there a "secure" reference … Graham Keellings (Leonix Solutions Pte Ltd)
- [dtn-security] Is there a "secure" reference impl… Graham Keellings (Leonix Solutions Pte Ltd)
- [dtn-security] Re(2): Newbie seeking some securit… Peter Lovell
- Re: [dtn-security] Newbie seeking some security r… Jason Redi
- Re: [dtn-security] Newbie seeking some security r… Stephen Farrell
- Re: [dtn-security] Newbie seeking some security r… Ivancic, William D. (GRC-RHN0)
- Re: [dtn-security] Newbie seeking some security r… Graham Keellings (Leonix Solutions Pte Ltd)
- Re: [dtn-security] Encrypted IP headers Graham Keellings (Leonix Solutions Pte Ltd)
- [dtn-security] Re(2): Encrypted IP headers Peter Lovell
- Re: [dtn-security] Encrypted IP headers Graham Keellings (Leonix Solutions Pte Ltd)
- [dtn-security] Re(2): Re(2): How do you feel abou… Peter Lovell
- Re: [dtn-security] Re(2): How do you feel about B… Graham Keellings (Leonix Solutions Pte Ltd)
- Re: [dtn-security] Re(2): Re(2): Re(2): Is there … Ivancic, William D. (GRC-RHN0)
- [dtn-security] Re(2): Re(2): Re(2): Is there a "s… Peter Lovell
- [dtn-security] Re(2): How do you feel about Bonjo… Peter Lovell
- Re: [dtn-security] How do you feel about Bonjour/… Graham Keellings (Leonix Solutions Pte Ltd)
- Re: [dtn-security] How do you feel about Bonjour/… Graham Keellings (Leonix Solutions Pte Ltd)
- Re: [dtn-security] Re(2): Re(2): Is there a "secu… Graham Keellings (Leonix Solutions Pte Ltd)
- Re: [dtn-security] How do you feel about Bonjour/… Peter Lovell
- [dtn-security] How do you feel about Bonjour/Avah… Graham Keellings (Leonix Solutions Pte Ltd)