Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.227]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id k3QKdpg23914 for ; Wed, 26 Apr 2006 13:39:51 -0700 Received: by wproxy.gmail.com with SMTP id i22so1335075wra for ; Wed, 26 Apr 2006 13:39:50 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:mime-version:content-type; b=MAKbYFiiMO++GciOo58LgvwczCutZwhHhRVSPob1V7OXIS0mY1zupSquydmz3xPxI0BhugGnrbzEB+b0kAue1OfhC8TW3PeONbByUcIbd/CBAjODNbVRGKA255211WpIsL5JKnLEMnBd2TWLIU4VWYenkfSQ7jus3TmwoboA4jw= Received: by 10.54.115.20 with SMTP id n20mr3905819wrc; Wed, 26 Apr 2006 13:39:50 -0700 (PDT) Received: by 10.54.69.15 with HTTP; Wed, 26 Apr 2006 13:39:50 -0700 (PDT) Message-ID: <380141b20604261339p2648895fj94c98a8902abd2fe@mail.gmail.com> Date: Wed, 26 Apr 2006 13:39:50 -0700 From: "Mooi Choo Chuah" To: dtn-security@mailman.dtnrg.org Cc: "S. Keshav" , chuah@cse.lehigh.edu MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_5752_25225637.1146083990657" Subject: [dtn-security] dtn security implementation code Sender: dtn-security-admin@mailman.dtnrg.org Errors-To: dtn-security-admin@mailman.dtnrg.org X-BeenThere: dtn-security@mailman.dtnrg.org X-Mailman-Version: 2.0.13 Precedence: bulk Reply-To: dtn-security@mailman.dtnrg.org List-Unsubscribe: , List-Id: DTN Security Discussion List-Post: List-Help: List-Subscribe: , List-Archive: ------=_Part_5752_25225637.1146083990657 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Dear all, we are releasing our dtn security implementation code. This version implements the June 2005 security draft. http://winslab.cse.lehigh.edu/bundlesec.html We plan to provide a brief implementation description document in 2-3 weeks time frame. Thanks Mooi Choo ------=_Part_5752_25225637.1146083990657 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Dear all,
we are releasing our dtn security implementation code. This version im= plements the June 2005 security draft.
 
 
We plan to provide a brief implementation description document in 2-3 = weeks time frame.
 
Thanks
Mooi Choo
------=_Part_5752_25225637.1146083990657-- Received: from relay.imagine.ie (dns2.dns.imagine.ie [87.232.1.41]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id k3IBKbg30751 for ; Tue, 18 Apr 2006 04:20:38 -0700 Received: from mail2.int.imagine.ie (mail2 [87.232.1.153]) by relay.imagine.ie (Postfix) with ESMTP id C53D34370 for ; Tue, 18 Apr 2006 12:20:36 +0100 (IST) Received: from [127.0.0.1] (dsl-102-234.cust.imagine.ie [87.232.102.234]) by mail2.int.imagine.ie (8.13.4/8.13.4/Debian-3) with ESMTP id k3IBKXEr005740 for ; Tue, 18 Apr 2006 12:20:35 +0100 Message-ID: <4444CB8A.8090608@cs.tcd.ie> Date: Tue, 18 Apr 2006 12:20:42 +0100 From: Stephen Farrell User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: dtn-security@mailman.dtnrg.org Subject: Re: [dtn-security] comments on security draft 01 References: <380141b20604110519x28490227oba8cc8299453ff06@mail.gmail.com> <380141b20604171351p786e210w90b8402d7180c1ba@mail.gmail.com> In-Reply-To: <380141b20604171351p786e210w90b8402d7180c1ba@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Bayes-Prob: 0.0001 (Score 0) X-Spam-Score: 0.00 () [Hold at 8.00] X-Canit-Stats-ID: 867223 - fce50795566e (trained as not-spam) X-CanItPRO-Stream: outgoing X-Scanned-By: CanIt (www . roaringpenguin . com) on 87.232.1.53 Sender: dtn-security-admin@mailman.dtnrg.org Errors-To: dtn-security-admin@mailman.dtnrg.org X-BeenThere: dtn-security@mailman.dtnrg.org X-Mailman-Version: 2.0.13 Precedence: bulk Reply-To: dtn-security@mailman.dtnrg.org List-Unsubscribe: , List-Id: DTN Security Discussion List-Post: List-Help: List-Subscribe: , List-Archive: Thanks for those comments, its great to start seeing feedback on this finally! We might get back to you on the detailed ones when we're editing the document, but they look fine at first glance. Couple of remarks inline below though, Cheers, Stephen. Mooi Choo Chuah wrote: > Dear all, > Susan encouraged me to send these comments to all so that others can > respond too. I already got some answers from her. > > Mooi Choo > ========================================== > > Hi Susan, > here are the comments/questions Walter and I have on your security draft 01. > > 1. pg 5, 3rd line BN4 not BPA4. > > 2, pg 7: header processing flags - I think a clear definition (even if > this is not finalized) of the different flags will be helpful to the > readers. > > 3. pg 9: an example of when the two instances: an "up front" BAH > instance containing ciphersuite and another that contains security > result will be used will be helpful. > The correlator field is not well explained. Again, an example will help. > > 4. pg 12: The sentence "Subsequent CH security results will contain > headers encrypted using the BEK if non-payload headers are to be > encrypted" needs to be expanded with an example. > Can we include an ASCII version of the slide that we have exchanged in > the document? I think it will help to clarify this. We can put this in > the Appendix. It will help the readers understand certain sentences. > > 5. pg 13: The sentence "This would result in uses of PSH which > presumably all protect the payload, and which cannot in general protect > one another" is confusing. An example explaining this will be helpful. > 6. pg 22 - explain more about mulitple security results embedded in the > payload) > > Also, explain more about what you meant by "the bundle MUST be > fragmented immediately after the last security result value in the > partial payload that is received". > > Say I have an original bundle that has CH and PSH invoked. The encrypted > payload is 1000 bytes but I only manage to transmit 230 bytes out (the > 1st fragment has the CH and PSH as drawn in the slide we exchanged). > Then, what do I do with the 2nd fragment that I sent out? Do I include > just the BAH (if it is invoked) and the remaining 770 bytes of encrypted > payload? I think you'd have to include the CH again - the receiver might have forgotten the BEK or the bundle may take a different route. But this will only work for some ciphersuites. I think we can support it with the current one, but we have to change to a counter-mode mode of operation, CBC mode would only work if the same decryptor maintains internal crypto state and no API that I know of allows that. Certainly nothing with a FIPS 1402-2 label anyway. > also, although it may be obvious, I think it will help if we say we > treat custody transfer ack the same as regular bundle - meaning if > security feature is invoked, it will apply to custody transfer too. If you're saying that a node can use CH and/or PSH to secure a bundle who's content is administrative, then yes, absolutely. If OTOH, you're saying that all custody acks must have a PSH, or even that custody acks must be "as well protected" as the bundles they are acking, then I'd disagree. One could write up yet another document describing reasonable scenarios along those lines, but I don't think there's anything normative we can add right now. (Yes, this is part of my overall rant about not liking the reporting stuff in the bundle protocol, but I guess that argument's done already;-) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.238]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id k3HKpbg25212 for ; Mon, 17 Apr 2006 13:51:38 -0700 Received: by wproxy.gmail.com with SMTP id 50so629086wri for ; Mon, 17 Apr 2006 13:51:37 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=kPjAUwNDj301zB+gkVBBprUNitUFPF92X5KyH9PsOIJXXYSDbxUWkdr+GtNDiQ0LpkT+8r+n9sk8CIztLvk/OpObBmB9koUCMbCfFwdWik1pyUwej/u14WuFOXznJQfv64N1L6t+3ztVpXsNyjxFLCHzzm4E9aiL+hf/8Ul19P8= Received: by 10.54.72.4 with SMTP id u4mr3569308wra; Mon, 17 Apr 2006 13:51:37 -0700 (PDT) Received: by 10.54.69.15 with HTTP; Mon, 17 Apr 2006 13:51:37 -0700 (PDT) Message-ID: <380141b20604171351p786e210w90b8402d7180c1ba@mail.gmail.com> Date: Mon, 17 Apr 2006 13:51:37 -0700 From: "Mooi Choo Chuah" To: dtn-security@mailman.dtnrg.org In-Reply-To: <380141b20604110519x28490227oba8cc8299453ff06@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_12909_13143867.1145307097155" References: <380141b20604110519x28490227oba8cc8299453ff06@mail.gmail.com> Subject: [dtn-security] comments on security draft 01 Sender: dtn-security-admin@mailman.dtnrg.org Errors-To: dtn-security-admin@mailman.dtnrg.org X-BeenThere: dtn-security@mailman.dtnrg.org X-Mailman-Version: 2.0.13 Precedence: bulk Reply-To: dtn-security@mailman.dtnrg.org List-Unsubscribe: , List-Id: DTN Security Discussion List-Post: List-Help: List-Subscribe: , List-Archive: ------=_Part_12909_13143867.1145307097155 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Dear all, Susan encouraged me to send these comments to all so that others can respon= d too. I already got some answers from her. Mooi Choo =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Hi Susan, here are the comments/questions Walter and I have on your security draft 01= . 1. pg 5, 3rd line BN4 not BPA4. 2, pg 7: header processing flags - I think a clear definition (even if this is not finalized) of the different flags will be helpful to the readers. 3. pg 9: an example of when the two instances: an "up front" BAH instance containing ciphersuite and another that contains security result will be used will be helpful. The correlator field is not well explained. Again, an example will help. 4. pg 12: The sentence "Subsequent CH security results will contain headers encrypted using the BEK if non-payload headers are to be encrypted" needs t= o be expanded with an example. Can we include an ASCII version of the slide that we have exchanged in the document? I think it will help to clarify this. We can put this in the Appendix. It will help the readers understand certain sentences. 5. pg 13: The sentence "This would result in uses of PSH which presumably all protect the payload, and which cannot in general protect one another" i= s confusing. An example explaining this will be helpful. 6. pg 22 - explain more about mulitple security results embedded in the payload) Also, explain more about what you meant by "the bundle MUST be fragmented immediately after the last security result value in the partial payload tha= t is received". Say I have an original bundle that has CH and PSH invoked. The encrypted payload is 1000 bytes but I only manage to transmit 230 bytes out (the 1st fragment has the CH and PSH as drawn in the slide we exchanged). Then, what do I do with the 2nd fragment that I sent out? Do I include just the BAH (i= f it is invoked) and the remaining 770 bytes of encrypted payload? also, although it may be obvious, I think it will help if we say we treat custody transfer ack the same as regular bundle - meaning if security feature is invoked, it will apply to custody transfer too. Thanks, Mooi Choo ------=_Part_12909_13143867.1145307097155 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Dear all,<= /div>
Susan encouraged = me to send these comments to all so that others can respond too. = I already got some answers from her.
 
Mooi Choo
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D
 
Hi Susan,
here are the comments/questions Walter and I have on your security dra= ft 01.
 
1. pg 5, 3rd line BN4 not BPA4.
 
2, pg 7: header processing flags - I think a clear definition (even if= this is not finalized) of the different flags will be helpful to the reade= rs.
 
3. pg 9: an example of when the two instances: an "up f= ront" BAH instance containing ciphersuite and another that contains se= curity result will be used will be helpful.
The correlator field is not well explained. Again, an example will hel= p.
 
4. pg 12: The sentence "Subsequent CH security results will conta= in headers encrypted using the BEK if non-payload headers are to be encrypt= ed" needs to be expanded with an example.
Can we include an ASCII v= ersion of the slide that we have exchanged in the document? I think it will= help to clarify this. We can put this in the Appendix. It will help the re= aders understand certain sentences.=20
 
5.  pg 13: The sentence "This would result in uses of PSH wh= ich presumably all protect the payload, and which cannot in general protect= one another" is confusing. An example explaining this will be helpful= .=20
6. pg 22 - explain more about mulitple security results embedded in th= e payload)
 
Also, explain more about what you meant by "the bundle MUST be fr= agmented immediately after the last security result value in the partial pa= yload that is received".
 
Say I have an original bundle that has CH and PSH invoked. The encrypt= ed payload is 1000 bytes but I only manage to transmit 230 bytes out (the 1= st fragment has the CH and PSH as drawn in the slide we exchanged). Then, w= hat do I do with the 2nd fragment that I sent out? Do I include just the BA= H (if it is invoked) and the remaining 770 bytes of encrypted payload?=20
 
also, although it may be obvious, I think it will help if we say we tr= eat custody transfer ack the same as regular bundle - meaning if security f= eature is invoked, it will apply to custody transfer too.
 
Thanks,
Mooi Choo
 
------=_Part_12909_13143867.1145307097155--