Received: from nmta3.jpl.nasa.gov (nmta.jpl.nasa.gov [137.78.160.108]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id j4VM3NV31628; Tue, 31 May 2005 15:03:23 -0700 Received: from xmta1.jpl.nasa.gov (xmta1.jpl.nasa.gov [137.78.160.144]) by nmta3.jpl.nasa.gov (Switch-3.1.7/Switch-3.1.7) with ESMTP id j4VM3IK4013354; Tue, 31 May 2005 15:03:18 -0700 Received: from [127.0.0.1] (dhcp-79-22-229.jpl.nasa.gov [137.79.22.229]) by xmta1.jpl.nasa.gov (Switch-3.1.7/Switch-3.1.7) with ESMTP id j4VM3HcT009192; Tue, 31 May 2005 15:03:17 -0700 Message-ID: <429CDF24.9010907@jpl.nasa.gov> Date: Tue, 31 May 2005 15:03:16 -0700 From: Scott Burleigh User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: dtn-security@mailman.dtnrg.org, dtn-dev@mailman.dtnrg.org Subject: Re: [dtn-security] Re: [dtn-dev] Re: SDNV-new References: <200505241854.j4OIsx724035@smtp-bedford-dr.mitre.org> <42944BEF.7090007@cs.tcd.ie> <20050525152006.GA7633@pisco.cs.berkeley.edu> <42949E83.9050000@cs.tcd.ie> <20050525163707.GB14911@pisco.cs.berkeley.edu> <4294ABB9.5010009@jpl.nasa.gov> <4295D547.9080808@cs.tcd.ie> <20050531172941.GA30682@pisco.cs.berkeley.edu> <429CA577.8000705@jpl.nasa.gov> <20050531215551.GB30682@pisco.cs.berkeley.edu> In-Reply-To: <20050531215551.GB30682@pisco.cs.berkeley.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: dhcp-79-22-229.jpl.nasa.gov [137.79.22.229] X-Source-Sender: Scott.Burleigh@jpl.nasa.gov X-AUTH: Internal IP 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: Michael Demmer wrote: >As Rajesh said, the main rational for the byte savings is for small >values. Therefore, for things we expect to be big, like crypto keys, >we can send the length of the key first as an SDNV, then the >value. This won't waste too much over just sending the key as an SDNV >by itself (at most it wastes a byte or two). > >As such, my instinct is to just go with 1-2-3-4-5-6-7-8. > That sounds fine to me. Received: from pisco (pisco.CS.Berkeley.EDU [128.32.37.175]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id j4VLtpV31535; Tue, 31 May 2005 14:55:51 -0700 Received: from demmer by pisco with local (Exim 4.50) id 1DdEiF-0000V4-3R; Tue, 31 May 2005 14:55:51 -0700 Date: Tue, 31 May 2005 14:55:51 -0700 From: Michael Demmer To: Scott Burleigh Cc: dtn-security@mailman.dtnrg.org, dtn-dev@mailman.dtnrg.org Subject: Re: [dtn-security] Re: [dtn-dev] Re: SDNV-new Message-ID: <20050531215551.GB30682@pisco.cs.berkeley.edu> References: <200505241854.j4OIsx724035@smtp-bedford-dr.mitre.org> <42944BEF.7090007@cs.tcd.ie> <20050525152006.GA7633@pisco.cs.berkeley.edu> <42949E83.9050000@cs.tcd.ie> <20050525163707.GB14911@pisco.cs.berkeley.edu> <4294ABB9.5010009@jpl.nasa.gov> <4295D547.9080808@cs.tcd.ie> <20050531172941.GA30682@pisco.cs.berkeley.edu> <429CA577.8000705@jpl.nasa.gov> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <429CA577.8000705@jpl.nasa.gov> User-Agent: Mutt/1.4.2i 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: As Rajesh said, the main rational for the byte savings is for small values. Therefore, for things we expect to be big, like crypto keys, we can send the length of the key first as an SDNV, then the value. This won't waste too much over just sending the key as an SDNV by itself (at most it wastes a byte or two). As such, my instinct is to just go with 1-2-3-4-5-6-7-8. -m Received: from a.bbn.com (a.bbn.com [128.89.80.80]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id j4VK4IV30893 for ; Tue, 31 May 2005 13:04:19 -0700 Received: (from krash@localhost) by a.bbn.com (8.11.0/8.11.0) id j4VK49209721 for dtn-security@mailman.dtnrg.org; Tue, 31 May 2005 16:04:09 -0400 From: Rajesh Krishnan Message-Id: <200505312004.j4VK49209721@a.bbn.com> Subject: Re: [dtn-security] Re: [dtn-dev] Re: SDNV-new To: dtn-security@mailman.dtnrg.org Date: Tue, 31 May 2005 16:04:08 -0400 (EDT) In-Reply-To: <429CA577.8000705@jpl.nasa.gov> from "Scott Burleigh" at May 31, 2005 10:57:11 AM X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 X-Reply-To: krash@bbn.com List-Unsubscribe: , List-Id: DTN Security Discussion List-Post: List-Help: List-Subscribe: , List-Archive: > >I took a pass at changing the language from the original LTP spec to > >match my new proposal for SDNV encodings: > > > > > This is really good, Mike. What we still need to settle on is the > encoding scheme: 1-2-3-4-5-6-7-8, 1-2-3-4-5-6-8-16, > 1-2-4-8-16-32-64-128, or something else. Anybody have any strong > feelings on this? The case for byte-savings can be made primarily for small sizes such as 1,2, and 4. OTOH, large numbers (say, up to 4096-bits) are useful for encoding cryptographic keys. Say, how about: 1-2-4-8-16-128-256-512 (2^x bytes) 0-1-2-3-4-7-8-9 (x: integers congruent to {0 1 2 3 4} mod 7) 1-2-4-8-16-256-1024-8192 (2^x bytes) 0-1-2-3-4-8-10-14 (x: integers s.t. 3^x+2 is a prime) 1-2-4-8-16-256-512-1024 (2^x bytes) 0-1-2-3-4-8-9-10 (x: integers s.t. x is a sum of at most 4 cubes) 1-2-4-8-32-128-2048-8192 (2^x) 0-1-2-3-5-7-11-13 (x: 0, 1, then integers s.t. x is a prime ) See http://www.research.att.com/~njas/sequences/ Best Regards, Rajesh Received: from nmta1.jpl.nasa.gov (nmta.jpl.nasa.gov [137.78.160.214]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id j4VHvIV30089; Tue, 31 May 2005 10:57:18 -0700 Received: from xmta1.jpl.nasa.gov (xmta1.jpl.nasa.gov [137.78.160.144]) by nmta1.jpl.nasa.gov (Switch-3.1.7/Switch-3.1.7) with ESMTP id j4VHvC2O004294; Tue, 31 May 2005 10:57:12 -0700 Received: from [127.0.0.1] (dhcp-79-22-229.jpl.nasa.gov [137.79.22.229]) by xmta1.jpl.nasa.gov (Switch-3.1.7/Switch-3.1.7) with ESMTP id j4VHvCpD004195; Tue, 31 May 2005 10:57:12 -0700 Message-ID: <429CA577.8000705@jpl.nasa.gov> Date: Tue, 31 May 2005 10:57:11 -0700 From: Scott Burleigh User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: dtn-security@mailman.dtnrg.org CC: dtn-dev@mailman.dtnrg.org Subject: Re: [dtn-security] Re: [dtn-dev] Re: SDNV-new References: <200505241854.j4OIsx724035@smtp-bedford-dr.mitre.org> <42944BEF.7090007@cs.tcd.ie> <20050525152006.GA7633@pisco.cs.berkeley.edu> <42949E83.9050000@cs.tcd.ie> <20050525163707.GB14911@pisco.cs.berkeley.edu> <4294ABB9.5010009@jpl.nasa.gov> <4295D547.9080808@cs.tcd.ie> <20050531172941.GA30682@pisco.cs.berkeley.edu> In-Reply-To: <20050531172941.GA30682@pisco.cs.berkeley.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: dhcp-79-22-229.jpl.nasa.gov [137.79.22.229] X-Source-Sender: Scott.Burleigh@jpl.nasa.gov X-AUTH: Internal IP 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: Michael Demmer wrote: >I took a pass at changing the language from the original LTP spec to >match my new proposal for SDNV encodings: > > This is really good, Mike. What we still need to settle on is the encoding scheme: 1-2-3-4-5-6-7-8, 1-2-3-4-5-6-8-16, 1-2-4-8-16-32-64-128, or something else. Anybody have any strong feelings on this? Scott Received: from nmta1.jpl.nasa.gov (nmta1.jpl.nasa.gov [137.78.160.214]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id j4VHqRV30028 for ; Tue, 31 May 2005 10:52:27 -0700 Received: from xmta1.jpl.nasa.gov (xmta1.jpl.nasa.gov [137.78.160.144]) by nmta1.jpl.nasa.gov (Switch-3.1.7/Switch-3.1.7) with ESMTP id j4VHqCVl002522; Tue, 31 May 2005 10:52:12 -0700 Received: from [127.0.0.1] (dhcp-79-22-229.jpl.nasa.gov [137.79.22.229]) by xmta1.jpl.nasa.gov (Switch-3.1.7/Switch-3.1.7) with ESMTP id j4VHqBMC001528; Tue, 31 May 2005 10:52:12 -0700 Message-ID: <429CA44A.4000405@jpl.nasa.gov> Date: Tue, 31 May 2005 10:52:10 -0700 From: Scott Burleigh User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: dtn-security@mailman.dtnrg.org CC: "'Howard Weiss'" , "'Stephen Farrell'" Subject: Re: [dtn-security] 00 version of the Bundle Security Protocol Spec. References: <200505241854.j4OIsx724035@smtp-bedford-dr.mitre.org> In-Reply-To: <200505241854.j4OIsx724035@smtp-bedford-dr.mitre.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Source-IP: dhcp-79-22-229.jpl.nasa.gov [137.79.22.229] X-Source-Sender: Scott.Burleigh@jpl.nasa.gov X-AUTH: Internal IP 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: Susan F. Symington wrote: > All, > Attached is our first draft of the DTN Bundle Security Protocol > Specification. Please read it and provide comments. Ideally we would > like to have an 01 draft available by mid July, in time to be > considered at the next IETF meeting, so we would appreciate receiving > your comments in time to be considered for the next draft. Hi. I've got a few comments on the substance of the spec, but not many; you guys know plenty more about this stuff than I do. Most of my comments are on its form, and many of them respond to the points you raise below. > This Bundle Security Protocol will require the following changes to > the base Bundle Protocol Specification: > - need a Statment in the Bundle Protocol that security is RECOMMENDED > to implement and OPTIONAL to use Sure. > –- need a new Confidentiality header type I don't think this should be in the Bundle Protocol (BP) spec, though. All three security headers are extension headers; they should be documented in the Security spec, just as any other extension header should be documented in the spec that defines its content and use. > - need to remove text about authenticating the BAH from the bundle > processing steps Yes. In general, I think the clearest way to link these two documents in a cleanly decoupled fashion is this: 1. Number most of the paragraphs in the BP spec individually, so that other documents can easily refer to them. 2. Include in the BP spec, somewhere at the start of the procedure specifications, a note to the effect that "the procedures mandated by this specification are neither exhaustive nor exclusive; supplementary DTN protocol specifications (including, but not restricted to, the Bundle Security Protocol) may require that additional measures be taken at specified junctures in these procedures; such additional measures shall not override or supersede the mandated BP procedures, except that they may in some cases make these procedures moot by requiring, for example, that implementations conforming to the supplementary protocol terminate the processing of a given incoming or outgoing bundle due to a fault condition recognized by that protocol." 3. Remove all other security-specific language from the BP spec. 4. Modify the Security spec to say things like "The following procedure MUST be performed immediately before the start of the BP procedure described in w.x.y.z: blah blah blah." > - need to remove BAH and PSH header format descriptions Yes. > - need an at-most-once delivery parameter of the Register.request > primitive Here I think what's needed is a notion of extension parameters, along the same lines as the extension headers and extension procedures. That is, at the start of the service interface section of the BP spec we can say "the list of parameters specified for each BP service primitive is not to be understood as exhaustive or exclusive; supplementary DTN protocol specifications (including, but not restricted to, the Bundle Security Protocol) may require that implementations conforming to these protocols provide additional parameters with specified primitives." Then the Bundle Security Protocol can say which additional parameters are needed with which primitives, and what they mean, without constantly having to go back and tweak the BP spec whenever anything changes. > - need to remove the primary bundle header security flags field Yes. > - need to add a sender field to the primary bundle header I don't think so. I went back through the document and didn't find any mention of the "sender" being used for any purpose other than security. I think it belongs in the BAH. > - in description of forwarding steps, need to put the endpoint ID of > the sending bundle protocol agent into > the dictionary (if it's not already there) and place its offset in the > sender field before forwarding the bundle Let's say this in the Bundle Security Protocol spec instead. > - need modifications to the send.Request and Data.Indication Delivery > Options Security parameters to > be able to pass appropriate parameter (e.g., ciphersuite parameters) Again, I think this is covered by the "extension parameters" idea; let's document these modification in the Bundle Security Protocol spec. Other comments: 1. The terminology is of course completely messed up by our decisions of two weeks ago. I will try to have a revised draft of the BP spec out by the end of next week, which may (or may not) help clarify everything. 2. In section 2.2: is it your intent that the CH remains in the bundle even after decryption by the CH security destination, so that it can appear in the Data.indication at a bundle destination that isn't the decryptor? If so, what's the rationale for that? Likewise, does the PSH remain in the bundle even after verification by a PSH security destination that isn't the bundle destination? 3. A note on 2.3: now that everything that sends or receives a bundle -- including routers -- is a node, this capability protects routers as well as end systems from replay. 4. In section 3.1: if you use really big keys, does this cause the security result (the result of applying a key in a calculation) to be really big as well? Too big to fit into 16 bytes? Do we need SDNVs to be coded for 1-2-4-8-16-32-64-128 for this purpose, or will the 1-2-3-4-5-6-8-16 coding Mike proposed be sufficient? 5. In section 3.4, a minor typo: in the first paragraph you say PSH when you mean CH. 6. Section 4.2: I don't think we really need to have a canonical form for bundles; instead, the Bundle Protocol Specification needs to define the canonical sequence in which bundle data elements are considered in the calculation of signatures, MACs, etc. The former is the physical form -- the on-the-wire format -- of the bundle, which doesn't matter; the latter is the *logical* form -- the Security Protocol's view -- of the bundle, which can always be readily computed from the former. You're already implicitly recognizing this by talking about headers that are "(logically) removed" from the bundle prior to calculation and endpoint ID strings that must be "substituted for their corresponding fields in the concatenated bundle header." I think it would greatly simplify the spec to simply say something like "the BSP view of a bundle shall comprise the logical concatenation of the following data elements" and then talk about performing calculations on the BSP view of the bundle. (You do something like this in the third paragraph of 4.3, third sentence. I think it's the right approach.) 7. Did we ever finally decide whether or not the Override Report-to Header was in the Bundle Protocol spec? I've lost track; I'll do some research in my email archive. 8. In section 4.8: what do we do if one node that's registered at some endpoint ID says "at most once" and another one says it wants all copies? We can't simply "discard" the replay. 9. In section 4.12: it's starting to look as if we could end up with a large and maybe open-ended number of possible bundle status values, and I don't know of many cases where these values aren't mutually exclusive. I'm thinking it's time to switch from having a Flags byte here to using a status code number; might as well make it a 16-bit number to allow for lots of extensions. And, again, the BP spec is going to have to say that the values it defines for this code are not the exclusive and exhaustive list. 10. In section 4.13: I think the "extension parameters" idea needs to be applied to the "services required from the convergence layer" section of the BP spec as well. Then the Bundle Authenticity parameter can be discussed in the BSP spec -- as an extension to the BP spec -- where it belongs. Very clean. 11. Re Comment.26: the security policy database has to be discussed in this document, where it makes sense, not in the BP spec. Scott Received: from pisco (pisco.CS.Berkeley.EDU [128.32.37.175]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id j4VHTgV29864; Tue, 31 May 2005 10:29:42 -0700 Received: from demmer by pisco with local (Exim 4.50) id 1DdAYf-0008BH-VA; Tue, 31 May 2005 10:29:41 -0700 Date: Tue, 31 May 2005 10:29:41 -0700 From: Michael Demmer To: dtn-security@mailman.dtnrg.org Cc: dtn-dev@mailman.dtnrg.org Subject: Re: [dtn-security] Re: [dtn-dev] Re: SDNV-new Message-ID: <20050531172941.GA30682@pisco.cs.berkeley.edu> References: <200505241854.j4OIsx724035@smtp-bedford-dr.mitre.org> <42944BEF.7090007@cs.tcd.ie> <20050525152006.GA7633@pisco.cs.berkeley.edu> <42949E83.9050000@cs.tcd.ie> <20050525163707.GB14911@pisco.cs.berkeley.edu> <4294ABB9.5010009@jpl.nasa.gov> <4295D547.9080808@cs.tcd.ie> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4295D547.9080808@cs.tcd.ie> User-Agent: Mutt/1.4.2i 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: I took a pass at changing the language from the original LTP spec to match my new proposal for SDNV encodings: --- Self-Delimiting Numeric Value (SDNV) The design of LTP attempts to reconcile minimal consumption of transmission bandwidth with (a) extensibility to satisfy requirements not yet identified and (b) scalability across a very wide range of network sizes and transmission payload sizes. A key strategic element in the design is the use of self-delimiting numeric values (SDNVs) that are similar in design to the Abstract Syntax Notation One [ASN1] encoding of data structures. An SDNV can be used to encode a numeric value in the range 0 .. (2^68 - 1), using 1 to 9 octets. The first octet of an SDNV -- the "discriminant" -- characterizes the SDNV. If the most significant bit of the discriminant is zero, the length of the SDNV is 1 octet and the remaining 7 bits of the discriminant, treated as an unsigned integer, is the value of the SDNV. An integer in the range of 0 to 127 can be encoded this way. Otherwise (if the most significant bit of the discriminant is 1), the next 3 bits of the discriminant encode the length of the SDNV. If the content of these 3 length bits, treated as an unsigned integer, has the value N, then N+1 additional octets are used to represent the value. The value is found by concatenating the remaining 4 bits of the discriminant with octets 2 through N+2 of the SDNV, and treating this result as an unsigned integer. The following table outlines the SDNV encoding for all value ranges, their associated discriminant encodings, and the total length in octets of the SDNV. Value Range Discriminant SDNV Length ---------------- ------------ ----------- 0 127 0XXX XXXX 1 128 4095 1000 XXXX 2 4096 1048575 1001 XXXX 3 2^20 2^28 - 1 1010 XXXX 4 2^28 2^36 - 1 1011 XXXX 5 2^36 2^44 - 1 1100 XXXX 6 2^44 2^52 - 1 1101 XXXX 7 2^52 2^60 - 1 1110 XXXX 8 2^60 2^68 - 1 1111 XXXX 9 An SDNV can therefore be used to efficiently represent both large and small integer values. However, SDNV is clearly not the best way to represent every numeric value. When the maximum possible value of a number is known without question, the cost of an additional 8 bits of discriminant may not be justified. For example, an SDNV is a poor way to represent an integer whose value typically falls in the range 128 to 255. In general, though, we believe that SDNV representation of selected numeric values in LTP segments yields the smallest segment sizes without sacrificing scalability. Received: from M4.sparta.com (IDENT:GAgCFC6/UbWxpvS+uimQ4qAh6JuqqWdx@M4.sparta.com [157.185.61.2]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id j4RJJVV17200; Fri, 27 May 2005 12:19:31 -0700 Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.1/8.13.1) with ESMTP id j4RJJSim026205; Fri, 27 May 2005 14:19:28 -0500 Received: from columbia.sparta.com ([157.185.80.32]) by Beta5.sparta.com (8.12.11/8.12.11) with ESMTP id j4RJJRWh005419; Fri, 27 May 2005 14:19:27 -0500 Received: from [127.0.0.1] (testjk3.columbia.ads.sparta.com [157.185.81.160]) by columbia.sparta.com (8.12.10+Sun/8.12.10) with ESMTP id j4RJJQ6i013594; Fri, 27 May 2005 15:19:27 -0400 (EDT) Message-ID: <429772BE.6030207@sparta.com> Date: Fri, 27 May 2005 15:19:26 -0400 From: Howard Weiss User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Scott Burleigh CC: dtn-security@mailman.dtnrg.org, dtn-dev@mailman.dtnrg.org Subject: Re: [dtn-security] Re: [dtn-dev] Re: SDNV-new References: <200505241854.j4OIsx724035@smtp-bedford-dr.mitre.org> <42944BEF.7090007@cs.tcd.ie> <20050525152006.GA7633@pisco.cs.berkeley.edu> <42949E83.9050000@cs.tcd.ie> <20050525163707.GB14911@pisco.cs.berkeley.edu> <4294ABB9.5010009@jpl.nasa.gov> <20050525172205.GD14911@pisco.cs.berkeley.edu> <20050526002442.GE28634@pisco.cs.berkeley.edu> <4295F1AF.5020607@jpl.nasa.gov> <20050526184825.GE4301@pisco.cs.berkeley.edu> <42961ED1.80400@jpl.nasa.gov> In-Reply-To: <42961ED1.80400@jpl.nasa.gov> Content-Type: multipart/alternative; boundary="------------050901090901070706060501" 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: This is a multi-part message in MIME format. --------------050901090901070706060501 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit For keys, we need (at a min) 128 bits for a symmetric key and (at a min) 1024 bits for an asymmetric key. But the key sizes will vary - 512 bits may not be unheard of for a symmetric key and 2048 for an asymmetric. Howie Scott Burleigh wrote: > Michael Demmer wrote: > >>> I don't much care one way or another. Do we really think we're >>> likely to need to represent numbers bigger than (2*68) - 1 in SDNVs? >>> >> >> >> Very doubtful if all they're used for is lengths, maybe so if they're >> used for other things like crypto keys and such. >> > If we think we really are going to use SDNVs for crypto keys then I > think 1/2/3/4/6/8/12/16 isn't going to be enough, because crypto keys > only seem to get longer as the years go by. I think that would argue > for either the original SDNV-8 (or -16) scheme or else an encoding > along the lines of 1/2/4/8/16/32/64/128. > > If not -- that is, if we're going use ordinary LV structures (an 8-bit > length followed by that many bytes of content) for encryption keys -- > then I don't see any point in moving away from 1/2/3/4/5/6/7/8. > > Scott > _______________________________________________ > dtn-dev mailing list > dtn-dev@mailman.dtnrg.org > http://mailman.dtnrg.org/mailman/listinfo/dtn-dev -- Howard Weiss SPARTA, Inc. 7075 Samuel Morse Drive Columbia, MD 21046 410.872.1515 x201 410.872.8079 (fax) --------------050901090901070706060501 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit For keys, we need (at a min) 128 bits for a symmetric key and (at a min) 1024 bits for an asymmetric key.  But the key sizes will vary - 512 bits may not be unheard of for a symmetric key and 2048 for an asymmetric.

Howie

Scott Burleigh wrote:
Michael Demmer wrote:

I don't much care one way or another.  Do we really think we're
likely to need to represent numbers bigger than (2*68) - 1 in SDNVs?
  

Very doubtful if all they're used for is lengths, maybe so if they're
used for other things like crypto keys and such.

If we think we really are going to use SDNVs for crypto keys then I think 1/2/3/4/6/8/12/16 isn't going to be enough, because crypto keys only seem to get longer as the years go by.  I think that would argue for either the original SDNV-8 (or -16) scheme or else an encoding along the lines of 1/2/4/8/16/32/64/128.

If not -- that is, if we're going use ordinary LV structures (an 8-bit length followed by that many bytes of content) for encryption keys -- then I don't see any point in moving away from 1/2/3/4/5/6/7/8.

Scott
_______________________________________________
dtn-dev mailing list
dtn-dev@mailman.dtnrg.org
http://mailman.dtnrg.org/mailman/listinfo/dtn-dev 

-- 
Howard Weiss
SPARTA, Inc.
7075 Samuel Morse Drive
Columbia, MD 21046
410.872.1515 x201
410.872.8079 (fax)
--------------050901090901070706060501-- Received: from a.bbn.com (a.bbn.com [128.89.80.80]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id j4QLQMV09725; Thu, 26 May 2005 14:26:23 -0700 Received: (from krash@localhost) by a.bbn.com (8.11.0/8.11.0) id j4QLQHq01249; Thu, 26 May 2005 17:26:17 -0400 From: Rajesh Krishnan Message-Id: <200505262126.j4QLQHq01249@a.bbn.com> Subject: Re: [dtn-security] Re: [dtn-dev] Re: SDNV-new To: dtn-security@mailman.dtnrg.org Date: Thu, 26 May 2005 17:26:17 -0400 (EDT) Cc: dtn-dev@mailman.dtnrg.org In-Reply-To: <20050526184825.GE4301@pisco.cs.berkeley.edu> from "Michael Demmer" at May 26, 2005 11:48:25 AM X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 X-Reply-To: krash@bbn.com List-Unsubscribe: , List-Id: DTN Security Discussion List-Post: List-Help: List-Subscribe: , List-Archive: > > I don't much care one way or another. Do we really think we're > > likely to need to represent numbers bigger than (2*68) - 1 in SDNVs? > > Very doubtful if all they're used for is lengths, maybe so if they're > used for other things like crypto keys and such. > > > If so, what convinces us that we're likely to need 16 bytes but not > > equally likely to need 128 bytes? Certainly we can use an encoding > > scheme like this, or lots of others (for example, 1 2 4 8 16 32 64 > > 128), but the fact that we can doesn't necessarily mean we should. > > What's the rationale for this particular system? > > Well -- mostly a gut feeling at the time that we may find 12 and 16 > more useful than 5 and 7, but I confess that I don't have any > particular proposed use cases or concrete justification for this > feeling. So I'm really fine either way as well. I do not know what possible uses are being considered for SDNVs in DTNs, but it may be worth taking a look at some common sizes of interest. 1B Bluetooth. (B = Byte). 4B IPv4. 6B Ethernet. 12D for UPC (D = decimal digit). 13D for ISBN. 13D for European Article Numbering. 15D for E.164. 16B IPv6. 20B ATM End System Address. > 16 octets. 128B 1024-bit Cryptographic keys 512B 4096-bit Cryptographic keys and signatures are supported by several implementations Best Regards, Rajesh Received: from nmta2.jpl.nasa.gov (nmta2.jpl.nasa.gov [137.78.160.215]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id j4QJAKV09026; Thu, 26 May 2005 12:10:20 -0700 Received: from xmta1.jpl.nasa.gov (xmta1.jpl.nasa.gov [137.78.160.144]) by nmta2.jpl.nasa.gov (Switch-3.1.7/Switch-3.1.7) with ESMTP id j4QJAE57026713; Thu, 26 May 2005 12:10:14 -0700 Received: from [137.79.22.227] (dhcp-79-22-227.jpl.nasa.gov [137.79.22.227]) by xmta1.jpl.nasa.gov (Switch-3.1.7/Switch-3.1.7) with ESMTP id j4QJAE5E004777; Thu, 26 May 2005 12:10:14 -0700 Message-ID: <42961ED1.80400@jpl.nasa.gov> Date: Thu, 26 May 2005 12:09:05 -0700 From: Scott Burleigh User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: dtn-security@mailman.dtnrg.org, dtn-dev@mailman.dtnrg.org Subject: Re: [dtn-security] Re: [dtn-dev] Re: SDNV-new References: <200505241854.j4OIsx724035@smtp-bedford-dr.mitre.org> <42944BEF.7090007@cs.tcd.ie> <20050525152006.GA7633@pisco.cs.berkeley.edu> <42949E83.9050000@cs.tcd.ie> <20050525163707.GB14911@pisco.cs.berkeley.edu> <4294ABB9.5010009@jpl.nasa.gov> <20050525172205.GD14911@pisco.cs.berkeley.edu> <20050526002442.GE28634@pisco.cs.berkeley.edu> <4295F1AF.5020607@jpl.nasa.gov> <20050526184825.GE4301@pisco.cs.berkeley.edu> In-Reply-To: <20050526184825.GE4301@pisco.cs.berkeley.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: dhcp-79-22-227.jpl.nasa.gov [137.79.22.227] X-Source-Sender: Scott.Burleigh@jpl.nasa.gov X-AUTH: Internal IP 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: Michael Demmer wrote: >>I don't much care one way or another. Do we really think we're >>likely to need to represent numbers bigger than (2*68) - 1 in SDNVs? >> >> > >Very doubtful if all they're used for is lengths, maybe so if they're >used for other things like crypto keys and such. > If we think we really are going to use SDNVs for crypto keys then I think 1/2/3/4/6/8/12/16 isn't going to be enough, because crypto keys only seem to get longer as the years go by. I think that would argue for either the original SDNV-8 (or -16) scheme or else an encoding along the lines of 1/2/4/8/16/32/64/128. If not -- that is, if we're going use ordinary LV structures (an 8-bit length followed by that many bytes of content) for encryption keys -- then I don't see any point in moving away from 1/2/3/4/5/6/7/8. Scott Received: from pisco (pisco.CS.Berkeley.EDU [128.32.37.175]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id j4QImQV08771; Thu, 26 May 2005 11:48:26 -0700 Received: from demmer by pisco with local (Exim 4.50) id 1DbNP8-0001Ak-4g; Thu, 26 May 2005 11:48:26 -0700 Date: Thu, 26 May 2005 11:48:25 -0700 From: Michael Demmer To: dtn-security@mailman.dtnrg.org Cc: dtn-dev@mailman.dtnrg.org Subject: Re: [dtn-security] Re: [dtn-dev] Re: SDNV-new Message-ID: <20050526184825.GE4301@pisco.cs.berkeley.edu> References: <200505241854.j4OIsx724035@smtp-bedford-dr.mitre.org> <42944BEF.7090007@cs.tcd.ie> <20050525152006.GA7633@pisco.cs.berkeley.edu> <42949E83.9050000@cs.tcd.ie> <20050525163707.GB14911@pisco.cs.berkeley.edu> <4294ABB9.5010009@jpl.nasa.gov> <20050525172205.GD14911@pisco.cs.berkeley.edu> <20050526002442.GE28634@pisco.cs.berkeley.edu> <4295F1AF.5020607@jpl.nasa.gov> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4295F1AF.5020607@jpl.nasa.gov> User-Agent: Mutt/1.4.2i 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: > I don't much care one way or another. Do we really think we're > likely to need to represent numbers bigger than (2*68) - 1 in SDNVs? Very doubtful if all they're used for is lengths, maybe so if they're used for other things like crypto keys and such. > If so, what convinces us that we're likely to need 16 bytes but not > equally likely to need 128 bytes? Certainly we can use an encoding > scheme like this, or lots of others (for example, 1 2 4 8 16 32 64 > 128), but the fact that we can doesn't necessarily mean we should. > What's the rationale for this particular system? Well -- mostly a gut feeling at the time that we may find 12 and 16 more useful than 5 and 7, but I confess that I don't have any particular proposed use cases or concrete justification for this feeling. So I'm really fine either way as well. -m Received: from pisco (pisco.CS.Berkeley.EDU [128.32.37.175]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id j4QIVDV08637 for ; Thu, 26 May 2005 11:31:13 -0700 Received: from demmer by pisco with local (Exim 4.50) id 1DbN8P-00017b-A5; Thu, 26 May 2005 11:31:09 -0700 Date: Thu, 26 May 2005 11:31:09 -0700 From: Michael Demmer To: Stephen Farrell Cc: dtn-security@mailman.dtnrg.org Subject: Re: are offsets enough? --was: (dictionary or not) Re: [dtn-security] 00 version of the Bundle Security Protocol Spec. Message-ID: <20050526183109.GA4301@pisco.cs.berkeley.edu> References: <200505251831.j4PIVRX27084@smtp-bedford.mitre.org> <4295D611.40606@cs.tcd.ie> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4295D611.40606@cs.tcd.ie> User-Agent: Mutt/1.4.2i 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: > Since we now have extensions and even, apparently, criticality, > some of those offsets might be in headers you don't know how > to parse so the dictionary encoding has to be self-contained, > other than whatever refers to the dictionary. Similarly, you > cannot move stuff about in the dictionary unless you understand > how to fix all of the headers in a bundle. that's a good point... unless a particular node can parse and understand all headers, then all it can do is append to the dictionary. -m Received: from pisco (pisco.CS.Berkeley.EDU [128.32.37.175]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id j4QIRRV08573; Thu, 26 May 2005 11:27:27 -0700 Received: from demmer by pisco with local (Exim 4.50) id 1DbN4o-00016J-QB; Thu, 26 May 2005 11:27:26 -0700 Date: Thu, 26 May 2005 11:27:26 -0700 From: Michael Demmer To: dtn-security@mailman.dtnrg.org Cc: dtn-dev@mailman.dtnrg.org Subject: Re: [dtn-security] Re: [dtn-dev] Re: SDNV-new Message-ID: <20050526182726.GA4219@pisco.cs.berkeley.edu> References: <200505241854.j4OIsx724035@smtp-bedford-dr.mitre.org> <42944BEF.7090007@cs.tcd.ie> <20050525152006.GA7633@pisco.cs.berkeley.edu> <42949E83.9050000@cs.tcd.ie> <20050525163707.GB14911@pisco.cs.berkeley.edu> <4294ABB9.5010009@jpl.nasa.gov> <4295D547.9080808@cs.tcd.ie> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4295D547.9080808@cs.tcd.ie> User-Agent: Mutt/1.4.2i 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: > Michael - can you write up the paragraph that's to go > into the LTP and/or Bundling spec and send it to the > list? Sure -- I'll take a whack at it. -m Received: from nmta3.jpl.nasa.gov (nmta.jpl.nasa.gov [137.78.160.108]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id j4QFvjV07563; Thu, 26 May 2005 08:57:45 -0700 Received: from xmta1.jpl.nasa.gov (xmta1.jpl.nasa.gov [137.78.160.144]) by nmta3.jpl.nasa.gov (Switch-3.1.7/Switch-3.1.7) with ESMTP id j4QFvdZX009495; Thu, 26 May 2005 08:57:40 -0700 Received: from [137.79.22.227] (dhcp-79-22-227.jpl.nasa.gov [137.79.22.227]) by xmta1.jpl.nasa.gov (Switch-3.1.7/Switch-3.1.7) with ESMTP id j4QFvdS4007650; Thu, 26 May 2005 08:57:39 -0700 Message-ID: <4295F1AF.5020607@jpl.nasa.gov> Date: Thu, 26 May 2005 08:56:31 -0700 From: Scott Burleigh User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: dtn-security@mailman.dtnrg.org, dtn-dev@mailman.dtnrg.org References: <200505241854.j4OIsx724035@smtp-bedford-dr.mitre.org> <42944BEF.7090007@cs.tcd.ie> <20050525152006.GA7633@pisco.cs.berkeley.edu> <42949E83.9050000@cs.tcd.ie> <20050525163707.GB14911@pisco.cs.berkeley.edu> <4294ABB9.5010009@jpl.nasa.gov> <20050525172205.GD14911@pisco.cs.berkeley.edu> <20050526002442.GE28634@pisco.cs.berkeley.edu> In-Reply-To: <20050526002442.GE28634@pisco.cs.berkeley.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: dhcp-79-22-227.jpl.nasa.gov [137.79.22.227] X-Source-Sender: Scott.Burleigh@jpl.nasa.gov X-AUTH: Internal IP Subject: [dtn-security] Re: [dtn-dev] Re: SDNV-new 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: Michael Demmer wrote: >In talking with Kevin a bit about this, I'm gonna propose a slight >modification to my original proposal. > >For the three bits that in my original proposal indicated that there >were 1-8 value bytes to follow, I'd say we should recast their meaning >to be: > >0: 1 byte to follow >1: 2 bytes to follow >2: 3 bytes to follow >3: 4 bytes to follow >4: 6 bytes to follow >5: 8 bytes to follow >6: 12 bytes to follow >7: 16 bytes to follow > >Basically, we drop the 5 byte and 7 byte encodings in favor of adding >a 12 byte and a 16 byte case. > >We still use the low-order nibble of the discriminator byte as the >high order bits of the value. > >Thoughts? > I don't much care one way or another. Do we really think we're likely to need to represent numbers bigger than (2*68) - 1 in SDNVs? If so, what convinces us that we're likely to need 16 bytes but not equally likely to need 128 bytes? Certainly we can use an encoding scheme like this, or lots of others (for example, 1 2 4 8 16 32 64 128), but the fact that we can doesn't necessarily mean we should. What's the rationale for this particular system? Scott Received: from smtp3.tcd.ie (smtp3.tcd.ie [134.226.1.158]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id j4QDwDV06832 for ; Thu, 26 May 2005 06:58:13 -0700 Received: from Vams.smtp3 (smtp3.tcd.ie [134.226.1.158]) by smtp3.tcd.ie (Postfix) with SMTP id 9B91214C047; Thu, 26 May 2005 14:58:07 +0100 (IST) Received: from smtp3.tcd.ie ([134.226.1.158]) by smtp3.tcd.ie ([134.226.1.158]) with SMTP (gateway) id A00360938FF; Thu, 26 May 2005 14:58:07 +0100 Received: from [134.226.36.26] (sfarrel2.dsg.cs.tcd.ie [134.226.36.26]) by smtp3.tcd.ie (Postfix) with ESMTP id 63AAC14C047; Thu, 26 May 2005 14:58:07 +0100 (IST) Message-ID: <4295D6E6.2010503@cs.tcd.ie> Date: Thu, 26 May 2005 15:02:14 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: dtn-security@mailman.dtnrg.org Cc: "Susan F. Symington" , "'Howard Weiss'" Subject: I18N (was: Re: (dictionary or not) Re: [dtn-security] 00 version of the Bundle Security Protocol Spec.) References: <200505241854.j4OIsx724035@smtp-bedford-dr.mitre.org> <42944BEF.7090007@cs.tcd.ie> <20050525152359.GB7633@pisco.cs.berkeley.edu> <42949AA1.5080108@cs.tcd.ie> <20050525153739.GA14911@pisco.cs.berkeley.edu> <42949E57.9000309@cs.tcd.ie> <20050525163945.GC14911@pisco.cs.berkeley.edu> <4294AC82.3060705@jpl.nasa.gov> In-Reply-To: <4294AC82.3060705@jpl.nasa.gov> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-AntiVirus-Status: Checked by TCD Vexira. (version=1.55.010 VDF=8.731) X-AntiVirus-Status: NONE X-AntiVirus-Status: Action Taken: X-AntiVirus-Status: Host: smtp3.tcd.ie X-AntiVirus-Status: MessageID = A10360938FF 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: Scott Burleigh wrote: > Michael Demmer wrote: > >>> Aha! Ok, it can work that way so long as there're no I18N >>> problems there (there aren't, right?). >> >> Well -- we need to decide on what to do re I8N. My inclination is to >> have the protocol just be in ASCII, and put the burden on the >> application interface to go to/from some multibyte encoding when >> interfacing with the application. >> >> > I agree: the external representation locally exposed to applications and > users is where the internationalization is really needed. On the wire I > don't think it's useful. I disageee - endpoint IDs are v. likely to want to include non-ASCII characters since they'll practically be used to name things. Furthermore the way we're farming out identifier scheme standardisation (via IANA or RFCs or whatever) just increases the liklihood that I18N will be needed. Read stringprep to see how bad it gets! Talk to Paul Hoffmann or someone else that knows if you want to hear to pain that iDNS invovled. Stephen. Received: from smtp3.tcd.ie (smtp3.tcd.ie [134.226.1.158]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id j4QDseV06790 for ; Thu, 26 May 2005 06:54:40 -0700 Received: from Vams.smtp3 (smtp3.tcd.ie [134.226.1.158]) by smtp3.tcd.ie (Postfix) with SMTP id 69A9E14C069; Thu, 26 May 2005 14:54:34 +0100 (IST) Received: from smtp3.tcd.ie ([134.226.1.158]) by smtp3.tcd.ie ([134.226.1.158]) with SMTP (gateway) id A0021D59B9D; Thu, 26 May 2005 14:54:34 +0100 Received: from [134.226.36.26] (sfarrel2.dsg.cs.tcd.ie [134.226.36.26]) by smtp3.tcd.ie (Postfix) with ESMTP id 4141514C069; Thu, 26 May 2005 14:54:34 +0100 (IST) Message-ID: <4295D611.40606@cs.tcd.ie> Date: Thu, 26 May 2005 14:58:41 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: dtn-security@mailman.dtnrg.org Cc: "'Michael Demmer'" References: <200505251831.j4PIVRX27084@smtp-bedford.mitre.org> In-Reply-To: <200505251831.j4PIVRX27084@smtp-bedford.mitre.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-AntiVirus-Status: Checked by TCD Vexira. (version=1.55.010 VDF=8.731) X-AntiVirus-Status: NONE X-AntiVirus-Status: Action Taken: X-AntiVirus-Status: Host: smtp3.tcd.ie X-AntiVirus-Status: MessageID = A1021D59B9D Subject: [dtn-security] Re: are offsets enough? --was: (dictionary or not) Re: [dtn-security] 00 version of the Bundle Security Protocol Spec. 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: Since we now have extensions and even, apparently, criticality, some of those offsets might be in headers you don't know how to parse so the dictionary encoding has to be self-contained, other than whatever refers to the dictionary. Similarly, you cannot move stuff about in the dictionary unless you understand how to fix all of the headers in a bundle. S. Susan F. Symington wrote: >>Personally, I think I'd rather that dictionary entries contain >>a length field (whatever encoding) since I've found lists of >>null-terminated strings are a great source for implementation >>errors. > > > Mike: Yeah -- I just feel like it's not worth the bytes. My other thought is > that we can infer the string lengths based on the various offsets > scattered throughout the bundle, in other words, if all the offsets > (i.e. src, dest, custodian, etc) were sorted, we could then infer the > various lengths based on the differences. But this is probably harder > to read (though more efficient) than just scanning for the null. > > Susan: It occurs to me that when a bundle is fragmented, we won't always be > able to infer the various dictionary string lengths based on the various > offsets scattered through the bundle, because not all headers (and therefore > not all offsets) are guaranteed to be in every fragment. The CH and PSH are > two examples of headers that may contain an offset but that most likely will > not be in every fragment. In the new FLAGS field we defined last week, one > bit is for indicating whether the header must be duplicated on all fragments > or just the first. So, it seems like the PSH and CH may not be the only > examples. > > So, if terminating the strings with nulls is not sufficient, then it seems > we need something like a length field to go along with the offset. > > -susan > > > > _______________________________________________ > dtn-security mailing list > dtn-security@mailman.dtnrg.org > http://mailman.dtnrg.org/mailman/listinfo/dtn-security > > Received: from smtp3.tcd.ie (smtp3.tcd.ie [134.226.1.158]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id j4QDpNV06735; Thu, 26 May 2005 06:51:23 -0700 Received: from Vams.smtp3 (smtp3.tcd.ie [134.226.1.158]) by smtp3.tcd.ie (Postfix) with SMTP id 5A8A714C064; Thu, 26 May 2005 14:51:12 +0100 (IST) Received: from smtp3.tcd.ie ([134.226.1.158]) by smtp3.tcd.ie ([134.226.1.158]) with SMTP (gateway) id A07F8B52B95; Thu, 26 May 2005 14:51:12 +0100 Received: from [134.226.36.26] (sfarrel2.dsg.cs.tcd.ie [134.226.36.26]) by smtp3.tcd.ie (Postfix) with ESMTP id 2E9D514C064; Thu, 26 May 2005 14:51:12 +0100 (IST) Message-ID: <4295D547.9080808@cs.tcd.ie> Date: Thu, 26 May 2005 14:55:19 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: dtn-security@mailman.dtnrg.org Cc: dtn-dev@mailman.dtnrg.org Subject: Re: [dtn-security] Re: [dtn-dev] Re: SDNV-new References: <200505241854.j4OIsx724035@smtp-bedford-dr.mitre.org> <42944BEF.7090007@cs.tcd.ie> <20050525152006.GA7633@pisco.cs.berkeley.edu> <42949E83.9050000@cs.tcd.ie> <20050525163707.GB14911@pisco.cs.berkeley.edu> <4294ABB9.5010009@jpl.nasa.gov> In-Reply-To: <4294ABB9.5010009@jpl.nasa.gov> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-AntiVirus-Status: Checked by TCD Vexira. (version=1.55.010 VDF=8.731) X-AntiVirus-Status: NONE X-AntiVirus-Status: Action Taken: X-AntiVirus-Status: Host: smtp3.tcd.ie X-AntiVirus-Status: MessageID = A17F8B52B95 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: Ok then I guess I rewrite a few lines of code. Michael - can you write up the paragraph that's to go into the LTP and/or Bundling spec and send it to the list? > If we're going to go with this, and if we're going to change it in LTP > as well (and I don't know why not), let's just call it "SDNV". Sure: "-new" was just a subject line not a suggested term. Stephen. Received: from pisco (pisco.CS.Berkeley.EDU [128.32.37.175]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id j4Q0OhV01791; Wed, 25 May 2005 17:24:43 -0700 Received: from demmer by pisco with local (Exim 4.50) id 1Db6B0-0005ls-M9; Wed, 25 May 2005 17:24:42 -0700 Date: Wed, 25 May 2005 17:24:42 -0700 From: Michael Demmer To: Scott Burleigh Cc: dtn-security@mailman.dtnrg.org, dtn-dev@mailman.dtnrg.org Message-ID: <20050526002442.GE28634@pisco.cs.berkeley.edu> References: <200505241854.j4OIsx724035@smtp-bedford-dr.mitre.org> <42944BEF.7090007@cs.tcd.ie> <20050525152006.GA7633@pisco.cs.berkeley.edu> <42949E83.9050000@cs.tcd.ie> <20050525163707.GB14911@pisco.cs.berkeley.edu> <4294ABB9.5010009@jpl.nasa.gov> <20050525172205.GD14911@pisco.cs.berkeley.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050525172205.GD14911@pisco.cs.berkeley.edu> User-Agent: Mutt/1.4.2i Subject: [dtn-security] Re: [dtn-dev] Re: SDNV-new 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: In talking with Kevin a bit about this, I'm gonna propose a slight modification to my original proposal. For the three bits that in my original proposal indicated that there were 1-8 value bytes to follow, I'd say we should recast their meaning to be: 0: 1 byte to follow 1: 2 bytes to follow 2: 3 bytes to follow 3: 4 bytes to follow 4: 6 bytes to follow 5: 8 bytes to follow 6: 12 bytes to follow 7: 16 bytes to follow Basically, we drop the 5 byte and 7 byte encodings in favor of adding a 12 byte and a 16 byte case. We still use the low-order nibble of the discriminator byte as the high order bits of the value. Thoughts? -m Received: from smtp-bedford.mitre.org (smtp-bedford-x.mitre.org [192.160.51.76]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id j4PIVkV31977 for ; Wed, 25 May 2005 11:31:46 -0700 Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.11.6/8.11.6) with SMTP id j4PIVj328531 for ; Wed, 25 May 2005 14:31:45 -0400 Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (Postfix) with ESMTP id 9AA79BF7E for ; Wed, 25 May 2005 14:31:45 -0400 (EDT) Received: from MAILHUB1 (mailhub1.mitre.org [129.83.20.31]) by smtp-bedford.mitre.org (8.11.6/8.11.6) with ESMTP id j4PIVRX27084; Wed, 25 May 2005 14:31:27 -0400 Message-Id: <200505251831.j4PIVRX27084@smtp-bedford.mitre.org> Received: from mm122433-pc.mitre.org (128.29.14.10) by mailhub1.mitre.org with SMTP id 17561840; Wed, 25 May 2005 14:31:24 -0400 From: "Susan F. Symington" To: "'Michael Demmer'" , Cc: "'Stephen Farrell'" Subject: RE:are offsets enough? --was: (dictionary or not) Re: [dtn-security] 00 version of the Bundle Security Protocol Spec. Date: Wed, 25 May 2005 14:31:19 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-index: AcVhSFwPgi7ZXVzSSgCXWnXhj4NhHQADlFIw In-reply-to: <20050525163945.GC14911@pisco.cs.berkeley.edu> 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: > Personally, I think I'd rather that dictionary entries contain > a length field (whatever encoding) since I've found lists of > null-terminated strings are a great source for implementation > errors. Mike: Yeah -- I just feel like it's not worth the bytes. My other thought is that we can infer the string lengths based on the various offsets scattered throughout the bundle, in other words, if all the offsets (i.e. src, dest, custodian, etc) were sorted, we could then infer the various lengths based on the differences. But this is probably harder to read (though more efficient) than just scanning for the null. Susan: It occurs to me that when a bundle is fragmented, we won't always be able to infer the various dictionary string lengths based on the various offsets scattered through the bundle, because not all headers (and therefore not all offsets) are guaranteed to be in every fragment. The CH and PSH are two examples of headers that may contain an offset but that most likely will not be in every fragment. In the new FLAGS field we defined last week, one bit is for indicating whether the header must be duplicated on all fragments or just the first. So, it seems like the PSH and CH may not be the only examples. So, if terminating the strings with nulls is not sufficient, then it seems we need something like a length field to go along with the offset. -susan Received: from pisco (pisco.CS.Berkeley.EDU [128.32.37.175]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id j4PHPRV31609; Wed, 25 May 2005 10:25:27 -0700 Received: from demmer by pisco with local (Exim 4.50) id 1DazdG-0004Ns-TH; Wed, 25 May 2005 10:25:26 -0700 Date: Wed, 25 May 2005 10:25:26 -0700 From: Michael Demmer To: dtn-security@mailman.dtnrg.org Cc: dtn-dev@mailman.dtnrg.org, "'Howard Weiss'" Subject: Re: [dtn-dev] Re: [dtn-security] 00 version of the Bundle Security Protocol Spec. Message-ID: <20050525172526.GF14911@pisco.cs.berkeley.edu> References: <200505241854.j4OIsx724035@smtp-bedford-dr.mitre.org> <42944BEF.7090007@cs.tcd.ie> <20050525152006.GA7633@pisco.cs.berkeley.edu> <4294AB20.2000301@jpl.nasa.gov> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4294AB20.2000301@jpl.nasa.gov> User-Agent: Mutt/1.4.2i 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: > Anyway, I like this approach but have one caveat to offer: you > actually can only have a maximum of 8 bytes following the > discriminator, not 9: Indeed you are correct -- my mistake in thinking I can be too clever early in the morning... :) > So the maximum value your number can have is (2**68 - 1). This still seems big enough to me. Anyone have objections? -m Received: from pisco (pisco.CS.Berkeley.EDU [128.32.37.175]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id j4PHM5V31535; Wed, 25 May 2005 10:22:05 -0700 Received: from demmer by pisco with local (Exim 4.50) id 1Daza1-0004Mr-Ms; Wed, 25 May 2005 10:22:05 -0700 Date: Wed, 25 May 2005 10:22:05 -0700 From: Michael Demmer To: Scott Burleigh Cc: dtn-security@mailman.dtnrg.org, dtn-dev@mailman.dtnrg.org Message-ID: <20050525172205.GD14911@pisco.cs.berkeley.edu> References: <200505241854.j4OIsx724035@smtp-bedford-dr.mitre.org> <42944BEF.7090007@cs.tcd.ie> <20050525152006.GA7633@pisco.cs.berkeley.edu> <42949E83.9050000@cs.tcd.ie> <20050525163707.GB14911@pisco.cs.berkeley.edu> <4294ABB9.5010009@jpl.nasa.gov> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4294ABB9.5010009@jpl.nasa.gov> User-Agent: Mutt/1.4.2i Subject: [dtn-security] Re: [dtn-dev] Re: SDNV-new 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: > If we're going to go with this, and if we're going to change it in > LTP as well (and I don't know why not), let's just call it "SDNV". Works for me -- so what's the plan for deciding "if we're going to go with this"? -m Received: from nmta1.jpl.nasa.gov (nmta1.jpl.nasa.gov [137.78.160.214]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id j4PGoKV31356 for ; Wed, 25 May 2005 09:50:20 -0700 Received: from xmta1.jpl.nasa.gov (xmta1.jpl.nasa.gov [137.78.160.144]) by nmta1.jpl.nasa.gov (Switch-3.1.7/Switch-3.1.7) with ESMTP id j4PGoEWq025316; Wed, 25 May 2005 09:50:14 -0700 Received: from [137.79.22.227] (dhcp-79-22-227.jpl.nasa.gov [137.79.22.227]) by xmta1.jpl.nasa.gov (Switch-3.1.7/Switch-3.1.7) with ESMTP id j4PGoD7l002315; Wed, 25 May 2005 09:50:14 -0700 Message-ID: <4294AC82.3060705@jpl.nasa.gov> Date: Wed, 25 May 2005 09:49:06 -0700 From: Scott Burleigh User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: dtn-security@mailman.dtnrg.org CC: "Susan F. Symington" , "'Howard Weiss'" Subject: Re: (dictionary or not) Re: [dtn-security] 00 version of the Bundle Security Protocol Spec. References: <200505241854.j4OIsx724035@smtp-bedford-dr.mitre.org> <42944BEF.7090007@cs.tcd.ie> <20050525152359.GB7633@pisco.cs.berkeley.edu> <42949AA1.5080108@cs.tcd.ie> <20050525153739.GA14911@pisco.cs.berkeley.edu> <42949E57.9000309@cs.tcd.ie> <20050525163945.GC14911@pisco.cs.berkeley.edu> In-Reply-To: <20050525163945.GC14911@pisco.cs.berkeley.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: dhcp-79-22-227.jpl.nasa.gov [137.79.22.227] X-Source-Sender: Scott.Burleigh@jpl.nasa.gov X-AUTH: Internal IP 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: Michael Demmer wrote: >>Aha! Ok, it can work that way so long as there're no I18N >>problems there (there aren't, right?). >> >> > >Well -- we need to decide on what to do re I8N. My inclination is to >have the protocol just be in ASCII, and put the burden on the >application interface to go to/from some multibyte encoding when >interfacing with the application. > > I agree: the external representation locally exposed to applications and users is where the internationalization is really needed. On the wire I don't think it's useful. Scott Received: from nmta2.jpl.nasa.gov (nmta2.jpl.nasa.gov [137.78.160.215]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id j4PGkxV31296; Wed, 25 May 2005 09:46:59 -0700 Received: from xmta1.jpl.nasa.gov (xmta1.jpl.nasa.gov [137.78.160.144]) by nmta2.jpl.nasa.gov (Switch-3.1.7/Switch-3.1.7) with ESMTP id j4PGkrfx008629; Wed, 25 May 2005 09:46:53 -0700 Received: from [137.79.22.227] (dhcp-79-22-227.jpl.nasa.gov [137.79.22.227]) by xmta1.jpl.nasa.gov (Switch-3.1.7/Switch-3.1.7) with ESMTP id j4PGkr2C000642; Wed, 25 May 2005 09:46:53 -0700 Message-ID: <4294ABB9.5010009@jpl.nasa.gov> Date: Wed, 25 May 2005 09:45:45 -0700 From: Scott Burleigh User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: dtn-security@mailman.dtnrg.org, dtn-dev@mailman.dtnrg.org References: <200505241854.j4OIsx724035@smtp-bedford-dr.mitre.org> <42944BEF.7090007@cs.tcd.ie> <20050525152006.GA7633@pisco.cs.berkeley.edu> <42949E83.9050000@cs.tcd.ie> <20050525163707.GB14911@pisco.cs.berkeley.edu> In-Reply-To: <20050525163707.GB14911@pisco.cs.berkeley.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: dhcp-79-22-227.jpl.nasa.gov [137.79.22.227] X-Source-Sender: Scott.Burleigh@jpl.nasa.gov X-AUTH: Internal IP Subject: [dtn-security] Re: [dtn-dev] Re: SDNV-new 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: Michael Demmer wrote: >>I don't think its really harder to code up use of >>sdnv-8 or -16 though, nor are coders likely IMO to >>get confused between these as long as we don't >>oscillate between 'em at specification time. >> >> > >Agreed -- I don't think any one of these schemes is easier and/or >harder to implement. My argument would be to settle on any one, but as >long as we're consistent, I don't really care. > >It does, however, bring a naming question as to what to call this >scheme... I don't think SDNV-new is all that appealing in the long >run. > If we're going to go with this, and if we're going to change it in LTP as well (and I don't know why not), let's just call it "SDNV". Received: from nmta2.jpl.nasa.gov (nmta2.jpl.nasa.gov [137.78.160.215]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id j4PGiSV31246; Wed, 25 May 2005 09:44:28 -0700 Received: from xmta1.jpl.nasa.gov (xmta1.jpl.nasa.gov [137.78.160.144]) by nmta2.jpl.nasa.gov (Switch-3.1.7/Switch-3.1.7) with ESMTP id j4PGiLdj008004; Wed, 25 May 2005 09:44:21 -0700 Received: from [137.79.22.227] (dhcp-79-22-227.jpl.nasa.gov [137.79.22.227]) by xmta1.jpl.nasa.gov (Switch-3.1.7/Switch-3.1.7) with ESMTP id j4PGiKwp031984; Wed, 25 May 2005 09:44:21 -0700 Message-ID: <4294AB20.2000301@jpl.nasa.gov> Date: Wed, 25 May 2005 09:43:12 -0700 From: Scott Burleigh User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 CC: dtn-security@mailman.dtnrg.org, dtn-dev@mailman.dtnrg.org, "'Howard Weiss'" Subject: Re: [dtn-dev] Re: [dtn-security] 00 version of the Bundle Security Protocol Spec. References: <200505241854.j4OIsx724035@smtp-bedford-dr.mitre.org> <42944BEF.7090007@cs.tcd.ie> <20050525152006.GA7633@pisco.cs.berkeley.edu> In-Reply-To: <20050525152006.GA7633@pisco.cs.berkeley.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: dhcp-79-22-227.jpl.nasa.gov [137.79.22.227] X-Source-Sender: Scott.Burleigh@jpl.nasa.gov X-AUTH: Internal IP 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: Michael Demmer wrote: >One thing that may be relevant to the security discussion (and to >dtn-dev in general) is that I think we should use a different SDNV >format than the ones described in the LTP spec (i.e. neither SDNV-8 >nor SDNV-16). > >Here's my proposal: > >If the value to be encoded is <= 127, then the high-order bit of the >discriminator is set to zero and the remaining 7 bits encode the >value. This is unchanged from the existing SDNV-8 format. > >If the value is larger than 127, then the high-order bit of the >discriminator is set to one, the next three bits indicate how many >length bytes there are, and the next four bits encode the high-order >nibble of the length value. Since there must be at least one >subsequent byte to encode the length (implied since the high order bit >is one), then we can use the three bits to indicate 1-9 bytes of >length that follow. > > I started off with an SDNV design that worked like this, years ago, and can't remember why I moved away from it in the early LTP specs; maybe because at that time I wanted to have a sign bit int the discriminator as well, and that didn't leave enough bits in the high-order nibble to encode the length. (Or because we wanted to encode the encryption keys themselves as SDNVs, since they're numbers, and this approach didn't support long enough numbers.) Anyway, I like this approach but have one caveat to offer: you actually can only have a maximum of 8 bytes following the discriminator, not 9: Length bits Indicated length ----------- ---------------- 000 1 001 2 010 3 011 4 100 5 101 6 110 7 111 8 So the maximum value your number can have is (2**68 - 1). >For some concreteness, the value ranges and number of bytes needed to >encode them are: > >0 - 127 1 byte >128 - 4095 2 bytes >4096 - 1048675 3 bytes >1048576 - 268435455 4 bytes >... > >The attractive thing to me about this is that since we're going to use >one of these to encode the length of each header, then it's likely >that most of the time, either one or two bytes will do. In contrast, >an SDNV-8 requires three bytes (one discriminator and two length) for >all values between 256 and 65536. So really, what we're talking about >is the range between 256 and 4096, which actually seems pretty likely >to occur. > >Now, as I can see it, the only drawback of this approach versus either >the SDNV-8 or SDNV-16 is that it has only 4 + (9 * 8) = 76 bits for >the length encoding. This seems more than sufficient for any expected >value, as the maximum value is 7.5 x 10^22, which is big enough that I >don't even know the word for it. (Out of curiosity, does anyone know >if there is a prefix like peta- or tera- for that size number?) > > Actually only 68 bits. >Finally, while in some cases, it can be argued that using one of the >other encodings may save a byte in the average case, for >implementation and specification clarity, I would advocate that all >bundle protocols that use SDNVs should use the same one (this one). > I agree with Stephen that it's actually not all that tough to keep SDNV-8 vs SDNV-16 straight, but I too am happy with this approach if it's our consensus. Scott Received: from pisco (pisco.CS.Berkeley.EDU [128.32.37.175]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id j4PGdjV31203 for ; Wed, 25 May 2005 09:39:45 -0700 Received: from demmer by pisco with local (Exim 4.50) id 1Dayv3-000494-60; Wed, 25 May 2005 09:39:45 -0700 Date: Wed, 25 May 2005 09:39:45 -0700 From: Michael Demmer To: dtn-security@mailman.dtnrg.org Cc: "Susan F. Symington" , "'Howard Weiss'" Subject: Re: (dictionary or not) Re: [dtn-security] 00 version of the Bundle Security Protocol Spec. Message-ID: <20050525163945.GC14911@pisco.cs.berkeley.edu> References: <200505241854.j4OIsx724035@smtp-bedford-dr.mitre.org> <42944BEF.7090007@cs.tcd.ie> <20050525152359.GB7633@pisco.cs.berkeley.edu> <42949AA1.5080108@cs.tcd.ie> <20050525153739.GA14911@pisco.cs.berkeley.edu> <42949E57.9000309@cs.tcd.ie> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42949E57.9000309@cs.tcd.ie> User-Agent: Mutt/1.4.2i 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: > Aha! Ok, it can work that way so long as there're no I18N > problems there (there aren't, right?). Well -- we need to decide on what to do re I8N. My inclination is to have the protocol just be in ASCII, and put the burden on the application interface to go to/from some multibyte encoding when interfacing with the application. > Personally, I think I'd rather that dictionary entries contain > a length field (whatever encoding) since I've found lists of > null-terminated strings are a great source for implementation > errors. Yeah -- I just feel like it's not worth the bytes. My other thought is that we can infer the string lengths based on the various offsets scattered throughout the bundle, in other words, if all the offsets (i.e. src, dest, custodian, etc) were sorted, we could then infer the various lengths based on the differences. But this is probably harder to read (though more efficient) than just scanning for the null. -m Received: from pisco (pisco.CS.Berkeley.EDU [128.32.37.175]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id j4PGb7V31139; Wed, 25 May 2005 09:37:07 -0700 Received: from demmer by pisco with local (Exim 4.50) id 1DaysV-00048E-GF; Wed, 25 May 2005 09:37:07 -0700 Date: Wed, 25 May 2005 09:37:07 -0700 From: Michael Demmer To: dtn-security@mailman.dtnrg.org Cc: dtn-dev@mailman.dtnrg.org Subject: Re: SDNV-new (was: Re: [dtn-security] 00 version of the Bundle Security Protocol Spec.) Message-ID: <20050525163707.GB14911@pisco.cs.berkeley.edu> References: <200505241854.j4OIsx724035@smtp-bedford-dr.mitre.org> <42944BEF.7090007@cs.tcd.ie> <20050525152006.GA7633@pisco.cs.berkeley.edu> <42949E83.9050000@cs.tcd.ie> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42949E83.9050000@cs.tcd.ie> User-Agent: Mutt/1.4.2i 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: > I guess this could work ok. Whether its better or worse > than sdnv-8/sdnv-16 depends on the frequency with which > we're encoding values in the range 4096-65535, Actually, not quite. See below... > and of course, my code currently does the -8/-16 thing, so if > we're making this change, we'll want to do it in LTP > at the same time. That'd be fine with me of course. > Also - can you give some more examples of values > and how they're encoded - the description is a bit > opaque. Ok, here's some arbitrary examples that express some of the various cases. Note that for the discriminator byte of the SDNV binary, I put in a . character to separate the relevant pieces. value hex SDNV hex SDNV binary 10 0a 0a 0.000.1010 90 5a 5a 0.101.1010 197 c5 80 c5 1.000.0000 11000101 2099 833 88 33 1.000.1000 00110011 12345 3039 90 30 39 1.001.0000 00110000 00111001 456789 6f855 96 f8 55 1.001.0110 11111000 01010101 123456789 75bcd15 a7 5b cd 15 1.010.0111 01011011 11001101 00010101 So, as I see it, the relevant range is for the values like 2099, 456789, etc in which we encode the high-order nibble in the discriminator byte itself. With SDNV-8, the value 2099 requires three bytes, whereas with this scheme it requires only two. Similarly, 456789 would require four bytes with SDNV-8, but only three with this scheme, etc. > I don't think its really harder to code up use of > sdnv-8 or -16 though, nor are coders likely IMO to > get confused between these as long as we don't > oscillate between 'em at specification time. Agreed -- I don't think any one of these schemes is easier and/or harder to implement. My argument would be to settle on any one, but as long as we're consistent, I don't really care. It does, however, bring a naming question as to what to call this scheme... I don't think SDNV-new is all that appealing in the long run. -m Received: from mx1.grc.nasa.gov (mx1.grc.nasa.gov [128.156.11.68]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id j4PGCpV30982; Wed, 25 May 2005 09:12:51 -0700 Received: from lombok-fi.grc.nasa.gov (seraph4.grc.nasa.gov [128.156.10.13]) by mx1.grc.nasa.gov (Postfix) with ESMTP id E95CFC232; Wed, 25 May 2005 12:12:45 -0400 (EDT) Received: from apataki.grc.nasa.gov (apataki.grc.nasa.gov [139.88.112.35]) by lombok-fi.grc.nasa.gov (NASA GRC TCPD 8.12.10/8.12.10) with ESMTP id j4PGCiK9002054; Wed, 25 May 2005 12:12:44 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by apataki.grc.nasa.gov (NASA GRC TCPD 8.13.1/8.13.1) with ESMTP id j4PGCibu000581; Wed, 25 May 2005 12:12:44 -0400 (EDT) Received: from apataki.grc.nasa.gov ([127.0.0.1])by localhost (apataki.grc.n asa.gov [127.0.0.1]) (amavisd-new, port 10024)with ESMTP id 25966-24; Wed, 25 May 2005 12:12:44 -0400 (EDT) Received: from drpepper.grc.nasa.gov (gr2134391.grc.nasa.gov [139.88.44.123] )by apataki.grc.nasa.gov (NASA GRC TCPD 8.13.1/8.13.1) with ESMTP id j4PGCg ho000565;Wed, 25 May 2005 12:12:42 -0400 (EDT) Received: by drpepper.grc.nasa.gov (Postfix, from userid 501)id B2C2B4FCB9; Wed, 25 May 2005 12:05:37 -0400 (EDT) Date: Wed, 25 May 2005 12:05:37 -0400 From: Wesley Eddy To: dtn-security@mailman.dtnrg.org Cc: dtn-dev@mailman.dtnrg.org, "Susan F. Symington" , "'Howard Weiss'" Subject: Re: [dtn-security] 00 version of the Bundle Security Protocol Spec. Message-ID: <20050525160537.GB21920@grc.nasa.gov> References: <200505241854.j4OIsx724035@smtp-bedford-dr.mitre.org> <42944BEF. 7090007@cs.tcd.ie> <20050525152006.GA7633@pisco.cs.berkeley.edu> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=oLBj+sq0vYjzfsbl Content-Disposition: inline In-Reply-To: <20050525152006.GA7633@pisco.cs.berkeley.edu> User-Agent: Mutt/1.5.5.1i X-imss-version: 2.19 X-imss-result: Passed X-imss-scores: Clean:0.00000 C:100 M:100 S:100 R:100 X-imss-settings: Baseline:1 C:1 M:1 S:2 R:2 (0.0000 0.0000) 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 X-Reply-To: weddy@grc.nasa.gov List-Unsubscribe: , List-Id: DTN Security Discussion List-Post: List-Help: List-Subscribe: , List-Archive: --oLBj+sq0vYjzfsbl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, May 25, 2005 at 08:20:06AM -0700, Michael Demmer wrote: >=20 > One thing that may be relevant to the security discussion (and to > dtn-dev in general) is that I think we should use a different SDNV > format than the ones described in the LTP spec (i.e. neither SDNV-8 > nor SDNV-16). >=20 > Here's my proposal: > > ... I like this idea. Reading the LTP spec, it struck me as odd (and slightly ugly) that there were 2 different types of SDNV. I couldn't instantly think of any good way to "unify" them though, so I didn't gripe about it. Now that there's a proposed alternative, I'll record my gripe with the dual-format SDNVs. -Wes=20 --=20 Wesley M. Eddy Verizon FNS / NASA GRC http://roland.grc.nasa.gov/~weddy --oLBj+sq0vYjzfsbl-- Received: from smtp3.tcd.ie (smtp3.tcd.ie [134.226.1.158]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id j4PFjOV30753; Wed, 25 May 2005 08:45:24 -0700 Received: from Vams.smtp3 (smtp3.tcd.ie [134.226.1.158]) by smtp3.tcd.ie (Postfix) with SMTP id 71C6614C04D; Wed, 25 May 2005 16:45:18 +0100 (IST) Received: from smtp3.tcd.ie ([134.226.1.158]) by smtp3.tcd.ie ([134.226.1.158]) with SMTP (gateway) id A01D505B68D; Wed, 25 May 2005 16:45:18 +0100 Received: from [134.226.145.79] (mme145079.mme.tcd.ie [134.226.145.79]) by smtp3.tcd.ie (Postfix) with ESMTP id 48F2014C04D; Wed, 25 May 2005 16:45:18 +0100 (IST) Message-ID: <42949E83.9050000@cs.tcd.ie> Date: Wed, 25 May 2005 16:49:23 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: dtn-security@mailman.dtnrg.org, dtn-dev@mailman.dtnrg.org Subject: SDNV-new (was: Re: [dtn-security] 00 version of the Bundle Security Protocol Spec.) References: <200505241854.j4OIsx724035@smtp-bedford-dr.mitre.org> <42944BEF.7090007@cs.tcd.ie> <20050525152006.GA7633@pisco.cs.berkeley.edu> In-Reply-To: <20050525152006.GA7633@pisco.cs.berkeley.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-AntiVirus-Status: Checked by TCD Vexira. (version=1.55.010 VDF=8.730) X-AntiVirus-Status: NONE X-AntiVirus-Status: Action Taken: X-AntiVirus-Status: Host: smtp3.tcd.ie X-AntiVirus-Status: MessageID = A11D505B68D 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: Michael, I guess this could work ok. Whether its better or worse than sdnv-8/sdnv-16 depends on the frequency with which we're encoding values in the range 4096-65535, and of course, my code currently does the -8/-16 thing, so if we're making this change, we'll want to do it in LTP at the same time. Also - can you give some more examples of values and how they're encoded - the description is a bit opaque. I don't think its really harder to code up use of sdnv-8 or -16 though, nor are coders likely IMO to get confused between these as long as we don't oscillate between 'em at specification time. All in all, I'd be for not changing since I've got code, but, I've no problem changing to this if that's the concensus. Cheers, Stephen. Michael Demmer wrote: > One thing that may be relevant to the security discussion (and to > dtn-dev in general) is that I think we should use a different SDNV > format than the ones described in the LTP spec (i.e. neither SDNV-8 > nor SDNV-16). > > Here's my proposal: > > If the value to be encoded is <= 127, then the high-order bit of the > discriminator is set to zero and the remaining 7 bits encode the > value. This is unchanged from the existing SDNV-8 format. > > If the value is larger than 127, then the high-order bit of the > discriminator is set to one, the next three bits indicate how many > length bytes there are, and the next four bits encode the high-order > nibble of the length value. Since there must be at least one > subsequent byte to encode the length (implied since the high order bit > is one), then we can use the three bits to indicate 1-9 bytes of > length that follow. > > For some concreteness, the value ranges and number of bytes needed to > encode them are: > > 0 - 127 1 byte > 128 - 4095 2 bytes > 4096 - 1048675 3 bytes > 1048576 - 268435455 4 bytes > ... > > The attractive thing to me about this is that since we're going to use > one of these to encode the length of each header, then it's likely > that most of the time, either one or two bytes will do. In contrast, > an SDNV-8 requires three bytes (one discriminator and two length) for > all values between 256 and 65536. So really, what we're talking about > is the range between 256 and 4096, which actually seems pretty likely > to occur. > > Now, as I can see it, the only drawback of this approach versus either > the SDNV-8 or SDNV-16 is that it has only 4 + (9 * 8) = 76 bits for > the length encoding. This seems more than sufficient for any expected > value, as the maximum value is 7.5 x 10^22, which is big enough that I > don't even know the word for it. (Out of curiosity, does anyone know > if there is a prefix like peta- or tera- for that size number?) > > Finally, while in some cases, it can be argued that using one of the > other encodings may save a byte in the average case, for > implementation and specification clarity, I would advocate that all > bundle protocols that use SDNVs should use the same one (this one). > > -m > > _______________________________________________ > dtn-security mailing list > dtn-security@mailman.dtnrg.org > http://mailman.dtnrg.org/mailman/listinfo/dtn-security > > Received: from smtp3.tcd.ie (smtp3.tcd.ie [134.226.1.158]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id j4PFifV30722 for ; Wed, 25 May 2005 08:44:41 -0700 Received: from Vams.smtp3 (smtp3.tcd.ie [134.226.1.158]) by smtp3.tcd.ie (Postfix) with SMTP id F327614C03E; Wed, 25 May 2005 16:44:34 +0100 (IST) Received: from smtp3.tcd.ie ([134.226.1.158]) by smtp3.tcd.ie ([134.226.1.158]) with SMTP (gateway) id A01D00EAE72; Wed, 25 May 2005 16:44:34 +0100 Received: from [134.226.145.79] (mme145079.mme.tcd.ie [134.226.145.79]) by smtp3.tcd.ie (Postfix) with ESMTP id C062F14C058; Wed, 25 May 2005 16:44:34 +0100 (IST) Message-ID: <42949E57.9000309@cs.tcd.ie> Date: Wed, 25 May 2005 16:48:39 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: dtn-security@mailman.dtnrg.org Cc: "Susan F. Symington" , "'Howard Weiss'" Subject: Re: (dictionary or not) Re: [dtn-security] 00 version of the Bundle Security Protocol Spec. References: <200505241854.j4OIsx724035@smtp-bedford-dr.mitre.org> <42944BEF.7090007@cs.tcd.ie> <20050525152359.GB7633@pisco.cs.berkeley.edu> <42949AA1.5080108@cs.tcd.ie> <20050525153739.GA14911@pisco.cs.berkeley.edu> In-Reply-To: <20050525153739.GA14911@pisco.cs.berkeley.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-AntiVirus-Status: Checked by TCD Vexira. (version=1.55.010 VDF=8.730) X-AntiVirus-Status: NONE X-AntiVirus-Status: Action Taken: X-AntiVirus-Status: Host: smtp3.tcd.ie X-AntiVirus-Status: MessageID = A11D00EAE72 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: > The dictionary part is a blob of consecutive null-terminated > strings Aha! Ok, it can work that way so long as there're no I18N problems there (there aren't, right?). Personally, I think I'd rather that dictionary entries contain a length field (whatever encoding) since I've found lists of null-terminated strings are a great source for implementation errors. S. Received: from pisco (pisco.CS.Berkeley.EDU [128.32.37.175]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id j4PFbdV30624 for ; Wed, 25 May 2005 08:37:39 -0700 Received: from demmer by pisco with local (Exim 4.50) id 1Daxwx-0003ts-Hr; Wed, 25 May 2005 08:37:39 -0700 Date: Wed, 25 May 2005 08:37:39 -0700 From: Michael Demmer To: dtn-security@mailman.dtnrg.org Cc: "Susan F. Symington" , "'Howard Weiss'" Subject: Re: (dictionary or not) Re: [dtn-security] 00 version of the Bundle Security Protocol Spec. Message-ID: <20050525153739.GA14911@pisco.cs.berkeley.edu> References: <200505241854.j4OIsx724035@smtp-bedford-dr.mitre.org> <42944BEF.7090007@cs.tcd.ie> <20050525152359.GB7633@pisco.cs.berkeley.edu> <42949AA1.5080108@cs.tcd.ie> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42949AA1.5080108@cs.tcd.ie> User-Agent: Mutt/1.4.2i 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: > I guess that that's possible, but I'd be for getting started > without the dictionary and changing to use it later if it > makes sense than. That'd be ok with me I guess -- though for the reference implementation at least, it should be pretty easy to use it since I'll have helper functions and the like for stuffing URIs in and out of the dictionary. > But since you've suggested it: what's the easy way to encode > the optional src and/or optional dest optionally using the > dictionary? (I'm just not up to speed on how the dictionary > encoding currently works.) The dictionary part is a blob of consecutive null-terminated strings of total length <= 64K. Encoding a scheme:ssp is therefore a pair of offsets, one for the scheme and one for the ssp, that indicate the first byte of the string in the dictionary. -m Received: from smtp-bedford.mitre.org (smtp-bedford-x.mitre.org [192.160.51.76]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id j4PFb1V30618 for ; Wed, 25 May 2005 08:37:01 -0700 Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.11.6/8.11.6) with SMTP id j4PFb1232703 for ; Wed, 25 May 2005 11:37:01 -0400 Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (Postfix) with ESMTP id 0068BBEFB for ; Wed, 25 May 2005 11:37:00 -0400 (EDT) Received: from MAILHUB2 (mailhub2.mitre.org [129.83.28.8]) by smtp-bedford.mitre.org (8.11.6/8.11.6) with ESMTP id j4PFb0N32639; Wed, 25 May 2005 11:37:00 -0400 Message-Id: <200505251537.j4PFb0N32639@smtp-bedford.mitre.org> Received: from mm122433-pc.mitre.org (128.29.14.10) by mailhub2.mitre.org with SMTP id 12460727; Wed, 25 May 2005 11:36:53 -0400 From: "Susan F. Symington" To: "'Stephen Farrell'" Cc: , "'Howard Weiss'" Subject: RE: [dtn-security] 00 version of the Bundle Security Protocol Spec. Date: Wed, 25 May 2005 11:36:50 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-reply-to: <42944BEF.7090007@cs.tcd.ie> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-index: AcVhD4mMCAQCrOSBS5CFH9DFMRpoZwAKwZxQ 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: Stephen, 1. One of the decisions that was made at the Berkeley meetings last week was that the dictionary header would contain all endpoint ids (EIDs) that appear in the bundle header, including the four in the primary bundle header, any security-related EIDs, any EIDs used in a source route header, etc. I understand your point that the security EIDs are only present in the security headers if they are different from the source and destination EIDs. At first I agreed with you that there would therefore be no gain in using the dictionary header for the security EIDs. However, after thinking about it I think that it makes sense to use the dictionary header, as decided. For one thing, a security EID might be the same as a report-to EID. Furthermore, if a source route header does eventually get defined, a security source or destination may very well be the same as an EID in the source route. So, I think there may be good reason to have the PSH-security-source and other security fields be offsets into the dictionary header than self-contained SDNVs. 2. Also according to last week's discussions, EIDs will be represented as a pair of two-byte offsets in the dictionary: one byte for scheme and 1 byte for SSP (Scheme-specific-part). If we do use the dictionary then is there still something wrong with the encoding? I'm not sure I see it. I don't think there is both and offset and length to mark the start and end of each string in the dictionary. I believe that we are using only offsets, with the end of each string being determined by the start of the next. (Now that I think about it, this may be a pain (but still doable) if the offsets are coming from lots of different headers, and not just the primary bundle header, but that's not a security issue; its an issue of how to structure the pointers into the dictionary header.) If there is still something wrong with the encoding, can you please explain it? 3. Even if there is nothing incorrect about the current encoding, it seems like we will want to make the ciphersuite field bigger. Do you want to do it now? -susan ***************************************************************** PLEASE NOTE: The exchange for Susan Symington's work numbers has changed from "883" to "983". So, her new office contact information is now: 703-983-7209 (voice) 708-983-7142 (fax) Please make a note of this change. Thanks! ****************************************************************** -----Original Message----- From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] Sent: Wednesday, May 25, 2005 5:57 AM To: Susan F. Symington Cc: dtn-security@mailman.dtnrg.org; 'Howard Weiss' Subject: Re: [dtn-security] 00 version of the Bundle Security Protocol Spec. Hi Susan, I think that this is fine to go, but I believe there was one change discussed last week that might be worth getting into the -00 version, since as currently written the encoding doesn't quite work;-) The current text uses 3 bits of the ciphersuite ID to indicate presence/absence of the of src/dest/parms. It appears (from last week's chats) that each of these is better encoded as SDNVs contained in the BAH,PSH or CH (since src/dest are only present when not the same as something already present/known, so there's no major gain in using the dictionary header). Given that, then we can use '00'H to indicate absence at the cost of 3 bytes, but if we're adding a BAH,PSH or CH the overall cost is probably so high that the additional 3 bytes are acceptable. That also solves the ciphersuite ID-size issue since 5 bits isn't really enough, but 8 bits probably is. If the 3 byte overhead (call that plan A) isn't acceptable, then I'd suggest we try plan B: a) make the change to use SDNV-8 for src & dest and not use the dictionary header for these, b) make the ciphersuite ID a 16-bit field, with the top three bits used for presence/absence of src/dest/parms, with maybe another 3 bits reserved and a 10-bit ciphersuite ID. That'd involve a 1-byte overhead on all messages, but makes messages that contain a src, dest & parms a byte bigger than otherwise. (I don't mind which plan we go with for now. I suppose plan B is very slightly better since we get those "reserved" bits:-) All the changes for this are contained in section 3.1 since later sections always (hopefully) talk about the fields being present/absent without getting into encoding details. So, if you've time before posting, I think it'd be worthwhile, but as I say, its ok as-is for a -00 IMO. (If you're stuck for time but want the change, you can fire over the xml and I'll do the editing.) Regards, Stephen. PS: The reason the current encoding doesn't work is that as I understand it the "natural" encoding of endpoint IDs can use the dictionary header so as written we're missing some offset/length field to allow the decoder to spot the end of the src field/start of the dest field when both are present. Received: from smtp3.tcd.ie (smtp3.tcd.ie [134.226.1.158]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id j4PFSpV30542 for ; Wed, 25 May 2005 08:28:51 -0700 Received: from Vams.smtp3 (smtp3.tcd.ie [134.226.1.158]) by smtp3.tcd.ie (Postfix) with SMTP id DED1814C035; Wed, 25 May 2005 16:28:44 +0100 (IST) Received: from smtp3.tcd.ie ([134.226.1.158]) by smtp3.tcd.ie ([134.226.1.158]) with SMTP (gateway) id A01590D4E71; Wed, 25 May 2005 16:28:44 +0100 Received: from [134.226.145.79] (mme145079.mme.tcd.ie [134.226.145.79]) by smtp3.tcd.ie (Postfix) with ESMTP id B48CF14C035; Wed, 25 May 2005 16:28:44 +0100 (IST) Message-ID: <42949AA1.5080108@cs.tcd.ie> Date: Wed, 25 May 2005 16:32:49 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: dtn-security@mailman.dtnrg.org Cc: "Susan F. Symington" , "'Howard Weiss'" Subject: (dictionary or not) Re: [dtn-security] 00 version of the Bundle Security Protocol Spec. References: <200505241854.j4OIsx724035@smtp-bedford-dr.mitre.org> <42944BEF.7090007@cs.tcd.ie> <20050525152359.GB7633@pisco.cs.berkeley.edu> In-Reply-To: <20050525152359.GB7633@pisco.cs.berkeley.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-AntiVirus-Status: Checked by TCD Vexira. (version=1.55.010 VDF=8.730) X-AntiVirus-Status: NONE X-AntiVirus-Status: Action Taken: X-AntiVirus-Status: Host: smtp3.tcd.ie X-AntiVirus-Status: MessageID = A11590D4E71 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: Michael, I guess that that's possible, but I'd be for getting started without the dictionary and changing to use it later if it makes sense than. But since you've suggested it: what's the easy way to encode the optional src and/or optional dest optionally using the dictionary? (I'm just not up to speed on how the dictionary encoding currently works.) Stephen. Michael Demmer wrote: > I must confess that I have as of yet only skimmed the document, but > I'd like to put a vote in against not using the dictionary > header. > > While it may save a byte or two when encoding the length of the > string, I'm betting that in the average case, the schemas of the PSH > src/dest will overlap with something in the primary header so you're > better off using the dictionary. > > -m > _______________________________________________ > dtn-security mailing list > dtn-security@mailman.dtnrg.org > http://mailman.dtnrg.org/mailman/listinfo/dtn-security > > Received: from pisco (pisco.CS.Berkeley.EDU [128.32.37.175]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id j4PFNxV30496 for ; Wed, 25 May 2005 08:23:59 -0700 Received: from demmer by pisco with local (Exim 4.50) id 1Daxjj-0003rh-5r; Wed, 25 May 2005 08:23:59 -0700 Date: Wed, 25 May 2005 08:23:59 -0700 From: Michael Demmer To: dtn-security@mailman.dtnrg.org Cc: "Susan F. Symington" , "'Howard Weiss'" Subject: Re: [dtn-security] 00 version of the Bundle Security Protocol Spec. Message-ID: <20050525152359.GB7633@pisco.cs.berkeley.edu> References: <200505241854.j4OIsx724035@smtp-bedford-dr.mitre.org> <42944BEF.7090007@cs.tcd.ie> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42944BEF.7090007@cs.tcd.ie> User-Agent: Mutt/1.4.2i 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: I must confess that I have as of yet only skimmed the document, but I'd like to put a vote in against not using the dictionary header. While it may save a byte or two when encoding the length of the string, I'm betting that in the average case, the schemas of the PSH src/dest will overlap with something in the primary header so you're better off using the dictionary. -m Received: from pisco (pisco.CS.Berkeley.EDU [128.32.37.175]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id j4PFK6V30452; Wed, 25 May 2005 08:20:06 -0700 Received: from demmer by pisco with local (Exim 4.50) id 1Daxfy-0003qz-D3; Wed, 25 May 2005 08:20:06 -0700 Date: Wed, 25 May 2005 08:20:06 -0700 From: Michael Demmer To: dtn-security@mailman.dtnrg.org, dtn-dev@mailman.dtnrg.org Cc: "Susan F. Symington" , "'Howard Weiss'" Subject: Re: [dtn-security] 00 version of the Bundle Security Protocol Spec. Message-ID: <20050525152006.GA7633@pisco.cs.berkeley.edu> References: <200505241854.j4OIsx724035@smtp-bedford-dr.mitre.org> <42944BEF.7090007@cs.tcd.ie> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42944BEF.7090007@cs.tcd.ie> User-Agent: Mutt/1.4.2i 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: One thing that may be relevant to the security discussion (and to dtn-dev in general) is that I think we should use a different SDNV format than the ones described in the LTP spec (i.e. neither SDNV-8 nor SDNV-16). Here's my proposal: If the value to be encoded is <= 127, then the high-order bit of the discriminator is set to zero and the remaining 7 bits encode the value. This is unchanged from the existing SDNV-8 format. If the value is larger than 127, then the high-order bit of the discriminator is set to one, the next three bits indicate how many length bytes there are, and the next four bits encode the high-order nibble of the length value. Since there must be at least one subsequent byte to encode the length (implied since the high order bit is one), then we can use the three bits to indicate 1-9 bytes of length that follow. For some concreteness, the value ranges and number of bytes needed to encode them are: 0 - 127 1 byte 128 - 4095 2 bytes 4096 - 1048675 3 bytes 1048576 - 268435455 4 bytes ... The attractive thing to me about this is that since we're going to use one of these to encode the length of each header, then it's likely that most of the time, either one or two bytes will do. In contrast, an SDNV-8 requires three bytes (one discriminator and two length) for all values between 256 and 65536. So really, what we're talking about is the range between 256 and 4096, which actually seems pretty likely to occur. Now, as I can see it, the only drawback of this approach versus either the SDNV-8 or SDNV-16 is that it has only 4 + (9 * 8) = 76 bits for the length encoding. This seems more than sufficient for any expected value, as the maximum value is 7.5 x 10^22, which is big enough that I don't even know the word for it. (Out of curiosity, does anyone know if there is a prefix like peta- or tera- for that size number?) Finally, while in some cases, it can be argued that using one of the other encodings may save a byte in the average case, for implementation and specification clarity, I would advocate that all bundle protocols that use SDNVs should use the same one (this one). -m Received: from smtp3.tcd.ie (smtp3.tcd.ie [134.226.1.158]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id j4P9rAV28297 for ; Wed, 25 May 2005 02:53:10 -0700 Received: from Vams.smtp3 (smtp3.tcd.ie [134.226.1.158]) by smtp3.tcd.ie (Postfix) with SMTP id 3CB5414C050; Wed, 25 May 2005 10:52:59 +0100 (IST) Received: from smtp3.tcd.ie ([134.226.1.158]) by smtp3.tcd.ie ([134.226.1.158]) with SMTP (gateway) id A00375E7782; Wed, 25 May 2005 10:52:58 +0100 Received: from [134.226.145.79] (mme145079.mme.tcd.ie [134.226.145.79]) by smtp3.tcd.ie (Postfix) with ESMTP id D5FA114C04A; Wed, 25 May 2005 10:52:57 +0100 (IST) Message-ID: <42944BEF.7090007@cs.tcd.ie> Date: Wed, 25 May 2005 10:57:03 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Susan F. Symington" Cc: dtn-security@mailman.dtnrg.org, "'Howard Weiss'" Subject: Re: [dtn-security] 00 version of the Bundle Security Protocol Spec. References: <200505241854.j4OIsx724035@smtp-bedford-dr.mitre.org> In-Reply-To: <200505241854.j4OIsx724035@smtp-bedford-dr.mitre.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-AntiVirus-Status: Checked by TCD Vexira. (version=1.55.010 VDF=8.730) X-AntiVirus-Status: NONE X-AntiVirus-Status: Action Taken: X-AntiVirus-Status: Host: smtp3.tcd.ie X-AntiVirus-Status: MessageID = A10375E7782 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: Hi Susan, I think that this is fine to go, but I believe there was one change discussed last week that might be worth getting into the -00 version, since as currently written the encoding doesn't quite work;-) The current text uses 3 bits of the ciphersuite ID to indicate presence/absence of the of src/dest/parms. It appears (from last week's chats) that each of these is better encoded as SDNVs contained in the BAH,PSH or CH (since src/dest are only present when not the same as something already present/known, so there's no major gain in using the dictionary header). Given that, then we can use '00'H to indicate absence at the cost of 3 bytes, but if we're adding a BAH,PSH or CH the overall cost is probably so high that the additional 3 bytes are acceptable. That also solves the ciphersuite ID-size issue since 5 bits isn't really enough, but 8 bits probably is. If the 3 byte overhead (call that plan A) isn't acceptable, then I'd suggest we try plan B: a) make the change to use SDNV-8 for src & dest and not use the dictionary header for these, b) make the ciphersuite ID a 16-bit field, with the top three bits used for presence/absence of src/dest/parms, with maybe another 3 bits reserved and a 10-bit ciphersuite ID. That'd involve a 1-byte overhead on all messages, but makes messages that contain a src, dest & parms a byte bigger than otherwise. (I don't mind which plan we go with for now. I suppose plan B is very slightly better since we get those "reserved" bits:-) All the changes for this are contained in section 3.1 since later sections always (hopefully) talk about the fields being present/absent without getting into encoding details. So, if you've time before posting, I think it'd be worthwhile, but as I say, its ok as-is for a -00 IMO. (If you're stuck for time but want the change, you can fire over the xml and I'll do the editing.) Regards, Stephen. PS: The reason the current encoding doesn't work is that as I understand it the "natural" encoding of endpoint IDs can use the dictionary header so as written we're missing some offset/length field to allow the decoder to spot the end of the src field/start of the dest field when both are present. Received: from smtp-bedford-dr.mitre.org (smtpproxy2.mitre.org [192.160.51.65]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id j4OIt9V22355 for ; Tue, 24 May 2005 11:55:09 -0700 Received: from smtp-bedford-dr.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford-dr.mitre.org (8.11.6/8.11.6) with SMTP id j4OIt6824950 for ; Tue, 24 May 2005 14:55:06 -0400 Received: from smtp-bedford-dr.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford-dr.mitre.org (Postfix) with ESMTP id 2D3354F93B for ; Tue, 24 May 2005 14:55:02 -0400 (EDT) Received: from MAILHUB2 (mailhub2.mitre.org [129.83.28.8]) by smtp-bedford-dr.mitre.org (8.11.6/8.11.6) with ESMTP id j4OIsx724035; Tue, 24 May 2005 14:54:59 -0400 Message-Id: <200505241854.j4OIsx724035@smtp-bedford-dr.mitre.org> Received: from mm122433-pc.mitre.org (128.29.14.10) by mailhub2.mitre.org with SMTP id 12430274; Tue, 24 May 2005 14:54:52 -0400 From: "Susan F. Symington" To: Cc: "'Howard Weiss'" , "'Stephen Farrell'" Date: Tue, 24 May 2005 14:54:49 -0400 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_012C_01C56070.88C0FD80" X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-index: AcVgkg+XakPcmHsTSt6PCeh7IcCstg== Subject: [dtn-security] 00 version of the Bundle Security Protocol Spec. 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: This is a multi-part message in MIME format. ------=_NextPart_000_012C_01C56070.88C0FD80 Content-Type: multipart/alternative; boundary="----=_NextPart_001_012D_01C56070.88C0FD80" ------=_NextPart_001_012D_01C56070.88C0FD80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit All, Attached is our first draft of the DTN Bundle Security Protocol Specification. Please read it and provide comments. Ideally we would like to have an 01 draft available by mid July, in time to be considered at the next IETF meeting, so we would appreciate receiving your comments in time to be considered for the next draft. This Bundle Security Protocol will require the following changes to the base Bundle Protocol Specification: - need a Statment in the Bundle Protocol that security is RECOMMENDED to implement and OPTIONAL to use -- need a new Confidentiality header type - need to remove text about authenticating the BAH from the bundle processing steps - need to remove BAH and PSH header format descriptions - need an at-most-once delivery parameter of the Register.request primitive - need to remove the primary bundle header security flags field - need to add a sender field to the primary bundle header - in description of forwarding steps, need to put the endpoint ID of the sending bundle protocol agent into the dictionary (if it's not already there) and place its offset in the sender field before forwarding the bundle - need modifications to the send.Request and Data.Indication Delivery Options Security parameters to be able to pass appropriate parameter (e.g., ciphersuite parameters) Thanks for your interest, susan ------=_NextPart_001_012D_01C56070.88C0FD80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
All,
 
Attached is our=20 first draft of the DTN Bundle Security Protocol Specification. Please = read it=20 and provide comments. Ideally we would like to have an 01 draft = available by mid=20 July, in time to be considered at the next IETF meeting, so we would = appreciate=20 receiving your comments in time to be considered for the next=20 draft.
 
This Bundle=20 Security Protocol  will require the following changes to the base = Bundle=20 Protocol Specification:
 
- need = a Statment in=20 the Bundle Protocol that  = security is=20 RECOMMENDED to implement and OPTIONAL to use
–-=20 need a new Confidentiality header type
- need to remove text about=20 authenticating the BAH from = the=20 bundle processing=20 steps
- need to = remove BAH=20 and PSH header format descriptions
- need an at-most-once delivery = parameter=20 of the Register.request=20 primitive
- need to remove=20 the primary bundle header security flags = field
- need to add=20 a sender field to the primary = bundle=20 header 
- in description = of forwarding=20 steps, need to put the endpoint ID of the sending bundle protocol agent = into=20
  the = dictionary=20 (if   it's not already there) and place its offset in the sender = field before=20 forwarding the bundle
- need modifications to the send.Request and=20 Data.Indication Delivery Options Security parameters to =
  be able to = pass=20 appropriate parameter (e.g., ciphersuite = parameters)
 
Thanks = for your=20 interest,
susan
------=_NextPart_001_012D_01C56070.88C0FD80-- ------=_NextPart_000_012C_01C56070.88C0FD80 Content-Type: text/plain; name="DTNSecSpec-20050524.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="DTNSecSpec-20050524.txt" DTN Research Group S. Symington Internet-Draft The MITRE Corporation Expires: November 25, 2005 S. Farrell Trinity College Dublin H. Weiss SPARTA, Inc. May 24, 2005 Bundle Security Protocol Specification draft-irtf-dtnrg-bundle-security-00 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on November 25, 2005. Copyright Notice Copyright (C) The Internet Society (2005). All Rights Reserved. Abstract This document defines the bundle security protocol, which provides data integrity and confidentiality services. We also describe various bundle security considerations including policy options. Symington, et al. Expires November 25, 2005 [Page 1] =0C Internet-Draft Bundle Security Protocol May 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1 Related Documents . . . . . . . . . . . . . . . . . . . . 5 1.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 2. Security-Specific Bundle Service Primitives and Parameters . . 8 2.1 The Delivery Options Parameter . . . . . . . . . . . . . . 8 2.2 Data indications . . . . . . . . . . . . . . . . . . . . . 9 2.3 The At-Most-Once-Delivery Option . . . . . . . . . . . . . 9 3. Security Headers . . . . . . . . . . . . . . . . . . . . . . . 11 3.1 Abstract Security Header . . . . . . . . . . . . . . . . . 11 3.2 Bundle Authentication Header . . . . . . . . . . . . . . . 13 3.3 Payload Security Header . . . . . . . . . . . . . . . . . 13 3.4 Confidentiality Header . . . . . . . . . . . . . . . . . . 14 3.5 PSH and CH combinations . . . . . . . . . . . . . . . . . 14 4. Security Processing . . . . . . . . . . . . . . . . . . . . . 15 4.1 Bundle Transmission Requests . . . . . . . . . . . . . . . 15 4.2 Canonicalisation of bundles . . . . . . . . . . . . . . . 16 4.3 Creating a Confidentiality Header . . . . . . . . . . . . 18 4.4 Creating the Payload Security Header . . . . . . . . . . . 19 4.5 Creating the Bundle Authentication Header . . . . . . . . 19 4.6 Bundles received from other bundle protocol agents . . . . 19 4.7 Local Bundle Delivery . . . . . . . . . . . . . . . . . . 20 4.8 Optionally checking for Replays . . . . . . . . . . . . . 20 4.9 Bundle Forwarding . . . . . . . . . . . . . . . . . . . . 21 4.10 Bundle Fragmentation and Reassembly . . . . . . . . . . . 22 4.11 Custodial Retransmission and Release . . . . . . . . . . . 23 4.12 Bundle Status Report Status Flags . . . . . . . . . . . . 23 4.13 Convergence Layer Security Services . . . . . . . . . . . 23 5. Ciphersuites . . . . . . . . . . . . . . . . . . . . . . . . . 24 5.1 EntireBundleHMAC Ciphersuite . . . . . . . . . . . . . . . 24 5.1.1 Ciphersuite Parameters . . . . . . . . . . . . . . . . 24 5.2 HeadOfBundleHMAC Ciphersuite . . . . . . . . . . . . . . . 24 5.2.1 Ciphersuite Parameters . . . . . . . . . . . . . . . . 25 5.3 EntireBundleSig Ciphersuite . . . . . . . . . . . . . . . 25 5.3.1 Ciphersuite Parameters . . . . . . . . . . . . . . . . 25 5.4 HeadOfBundleSig Ciphersuite . . . . . . . . . . . . . . . 25 5.4.1 Ciphersuite Parameters . . . . . . . . . . . . . . . . 26 5.5 CombinationSig Ciphersuite . . . . . . . . . . . . . . . . 26 5.5.1 Ciphersuite Parameters . . . . . . . . . . . . . . . . 26 5.6 EntireBundleMAC . . . . . . . . . . . . . . . . . . . . . 26 5.6.1 Ciphersuite Parameters . . . . . . . . . . . . . . . . 27 5.7 TP-type Ciphersuites . . . . . . . . . . . . . . . . . . . 27 5.7.1 Ciphersuite Parameters . . . . . . . . . . . . . . . . 27 6. Default Values . . . . . . . . . . . . . . . . . . . . . . . . 28 7. Security Considerations . . . . . . . . . . . . . . . . . . . 31 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 Editorial Comments . . . . . . . . . . . . . . . . . . . . . . 36 Symington, et al. Expires November 25, 2005 [Page 2] =0C Internet-Draft Bundle Security Protocol May 2005 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 36 Intellectual Property and Copyright Statements . . . . . . . . 37 Symington, et al. Expires November 25, 2005 [Page 3] =0C Internet-Draft Bundle Security Protocol May 2005 1. Introduction The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [1]. This document defines security features for the bundle protocol [2] intended for use in delay tolerant networks, in order to provide the DTN security services as described in the DTN Security Overview and Motivations document [3]. The bundle protocol is used in DTNs which overlay on top of multiple networks, some of which are challenged by limitations such as intermittent and possibly unpredictable loss of connectivity, long or variable delay, asymmetric data rates, and high error rates. The purpose of the bundle protocol is to support interoperability across such stressed networks. The bundle protocol is layered on top of underlay-network-specific convergence layers, on top of network-specific lower layers, to enable an application in one network to communicate with an application in another network, both of which are spanned by the DTN. Security will be important for the bundle protocol. The stressed environment of the underlying networks over which the bundle protocol will operate makes it important that the DTN be protected from unauthorized use, and this stressed environment poses unique challenges on the mechanisms needed to secure the bundle protocol. Furthermore, DTNs may very likely be deployed in environments where a portion of the network might become compromised, posing the usual security challenges related to confidentiality, integrity and availability. The security features described in this document are RECOMMENDED for deployment with the Bundle Protocol. Bundle Protocol implementations SHOULD support these features, except where they cannot, e.g. due to processor or bandwidth constraints. [Comment.1] Implementation of these security features is not mandatory because it is recognized that some bundle nodes will be so constrained that they are simply unable to use the mechanisms defined here. For example, if a communications subsystem is limited to emitting 40-byte segments, then we cannot use a 2048-bit RSA signature to secure such segments. The implications of omitting or not using these security features however, need to be fully understood, especially with regard to the ability of an implementation to interact with bundle protocol implementations that do implement security and that may be configured Symington, et al. Expires November 25, 2005 [Page 4] =0C Internet-Draft Bundle Security Protocol May 2005 to require that incoming bundles include specific security headers. [Comment.2] 1.1 Related Documents This document is best read and understood within the context of the following other DTN documents: [Comment.3] The Delay-Tolerant Network Architecture [4] defines the architecture for delay-tolerant networks, but does not discuss security at any length. The DTN Bundle Protocol [2] defines the format and processing of the headers used to implement the bundle protocol, excluding the security-specific headers defined here. The Delay-Tolerant Network Security Overview and Motivations [3] document provides an informative overview and high-level description of DTN security; it defines a security architecture for DTNs by describing the aspects of the DTN architecture requiring protection and the security mechanisms that can be used to provide this protection, along with motivating rationale. 1.2 Terminology We introduce the following terminology for purposes of clarity: source - the bundle node (application, bundle protocol agent, etc.) from which the application data unit originates destination - the bundle node (application, bundle protocol agent, etc.) to which the application data unit is ultimately destined sender - the bundle protocol agent that forwarded the bundle on its most recent hop recipient or "next hop" - the neighboring bundle protocol agent to which a sender forwards a bundle. [Comment.4] In the figure below, which is adapted from figure 1 in the Bundle Protocol Specification [2], four bundle protocol agents (denoted BPA 1, BPA 2, BPA 3, and BPA 4) that implement the bundle protocol reside above some transport layer(s). Three distinct transport and network protocols (denoted T1/N1, T2/N2, and T3/N3) are also shown. Bundle protocol agents BPA 1 and BPA 4 expose the bundle service interface to BundleNodeX and BundleNodeY, respectively. Symington, et al. Expires November 25, 2005 [Page 5] =0C Internet-Draft Bundle Security Protocol May 2005 +-----------+ +-----------+ |BundleNodeX| |BundleNodeY| +---------v-| +->>>>>>>>>>v-+ +->>>>>>>>>>v-+ +-^---------+ |BPA 1 v | | ^ BPA 2 v | | ^ BPA 3 v | | ^ BPA 4 | +---------v-+ +-^---------v-+ +-^---------v-+ +-^---------+ |Trans1 v | + ^ T1/T2 v | + ^ T2/T3 v | | ^ Trans3 | +---------v-+ +-^---------v-+ +-^---------v + +-^---------+ |Net1 v | | ^ N1/N2 v | | ^ N2/N3 v | | ^ Net3 | +---------v-+ +-^---------v + +-^---------v-+ +-^---------+ | >>>>>>>>^ >>>>>>>>>>^ >>>>>>>>^ | +-----------+ +------------+ +-------------+ +-----------+ | | | | |<-- An Internet --->| |<--- An Internet --->| | | | | BPA =3D "Bundle Protocol Agent"--the implementation of the bundle protocol at the bundle layer The protocol stacks on four DTN nodes. Figure 1 Bundle node "BundleNodeX" originates data that is sent to its underlying bundle protocol agent BPA1. That data is formatted into a bundle and forwarded to BPA2, BPA3, and BPA4 and then transmitted up to bundle node "BundleNodeY". BundleNodeX is the source and BundleNodeY is the destination for this data. BPA1 is the first sender, and BPA2 is the first recipient; BPA2 then becomes the sender, and BPA3 the recipient; BPA3 then becomes the last sender, and BPA4 the last recipient. If bundle protocol agent BPA1 originates data (for example, an administrative payload such as a bundle status report or custodial signal), which is then forwarded on to BPA2, BPA3, and finally BPA4, then BPA1 is the source of the bundle (as well as being the first sender of the bundle) and BPA4 is the destination of the bundle (as well as being the final recipient). We introduce the following security-specific DTN terminology: [Comment.5][Comment.6] security-source - a bundle node that adds an "end-to-end" security header security-destination - a bundle node that processes an "end-to-end" security header Referring to figure 1 again: If the bundle that originates at BundleNodeX as source is given a Symington, et al. Expires November 25, 2005 [Page 6] =0C Internet-Draft Bundle Security Protocol May 2005 Payload Security Header (PSH) by BPA1, then BPA1 is the security-source of this bundle, even though BundleNodeX is its source. If the bundle that originates at BundleNodeX as source is given a Payload Security Header (PSH) by BPA2, then BPA2 is the security-source of this bundle, even though BundleNodeX is its source. If the bundle that originates at BundleNodeX as source is given a Confidentiality Header (CH) by BPA1 protected using a key held by BPA2, then the BPA1 is the security-source of this bundle, and BPA-2 is the security destination. Symington, et al. Expires November 25, 2005 [Page 7] =0C Internet-Draft Bundle Security Protocol May 2005 2. Security-Specific Bundle Service Primitives and Parameters 2.1 The Delivery Options Parameter [Comment.7][Comment.8] The bundle service consumes a Send.request primitive that is used by the bundle node to request transmission of an application data unit from the source bundle endpoint to a destination bundle endpoint. One of the parameters of this primitive is "delivery options". The bundle service uses the Data.indication primitive to deliver the content of a bundle to one or more bundle nodes indicated by the bundle's destination endpoint. One of the parameters of this primitive is also "delivery options". The Delivery Options parameter indicates the optional security-specific procedures to be followed when transmitting and delivering the application data unit. Separate options MAY be specified for each of the confidentiality, authentication and error detection services. In each case, we use a ciphersuite ID to indicate how the service is to be provided. The ciphersuite ID can be omitted, leaving the decision up to the implementation. If the ciphersuite ID is provided, the additional ciphersuite parameters MAY be provided. The details of valid parameters are part of the definition of each of the ciphersuites. Even if the ciphersuite ID for a service is omitted, the implementation MAY decide to apply that service, based on some policy settings. However, if a ciphersuite ID is supplied, then the implementation MUST NOT send the bundle without successfully applying the required service. The following service-specific parameters are defined: Confidentiality - indicates that a CH header MUST be applied to the bundle, and at least the bundle payload (and possibly other bundle headers) MUST be encrypted appropriately[Comment.9] Authentication - indicates that a PSH MUST be applied to the bundle, and the (relevant parts of the) bundle digitally signed or MACed appropriately Error detection - indicates that a PSH MUST be applied to the bundle and the (relevant parts of the) bundle digested appropriately [Comment.10] Notes: 1) The above means that a given bundle can only use one of the authentication or error detection services 2) Hop-by-hop authentication is not controlled using this interface Symington, et al. Expires November 25, 2005 [Page 8] =0C Internet-Draft Bundle Security Protocol May 2005 3) Throughout this specification we use the standard security usage of the acronym MAC - meaning "message authentication code" 2.2 Data indications As with Send.request, Data.indication primitives SHOULD indicate the security services which were applied to the message. In each case the indication MUST contain a ciphersuite ID and MAY contain a ciphersuite-specified ciphersuite parameters item. Note that the ciphersuite parameters may differ between the Send.request and Data.indication primitives, e.g. for a confidentiality item in a Send.request, the security-destination will often be a parameter, whereas the security-source is what is of interest for the Data.indication (if the ciphersuite allows). We define the following indications: The presence of the Confidentiality item in the Data.indication primitive indicates that the bundle contained a CH and that its payload was encrypted. Note that it is possible that this bundle protocol agent is not the CH security-destination, i.e. the payload may have been decrypted by a bundle protocol agent earlier in the route. The presence of the Authentication Item in the Data.indication primitive indicates that the bundle contained a PSH with an authentication ciphersuite. Note that it is possible that this bundle protocol agent is not the PSH security-destination, i.e. the PSH MAY have been verified by a bundle protocol agent earlier in the route. The presence of the Error Detection item in the Data.indication primitive indicates that the received bundle included a PSH with an error detection ciphersuite. 2.3 The At-Most-Once-Delivery Option The bundle service consumes a Register.request primitive that is used to notify the bundle protocol agent of a bundle node's interest in bundles destined for a specified bundle endpoint and of the action to take on the bundle node's behalf with regard to those bundles. One of the parameters of this primitive is "at-most-once-delivery". [Comment.11] If this parameter is set, then the bundle node registering interest in receiving bundles is indicating that the receiving bundle protocol agent SHALL check for replayed bundles, discard duplicates, and deliver at most one copy of each received bundle to the registering bundle node. If this parameter is not set, the bundle node is indicating that the receiving bundle protocol agent SHALL deliver all received bundle copies to the registering bundle node. If this parameter is not set, the bundle protocol agent MAY (subject to policy) deliver all bundles or else behave as if this Symington, et al. Expires November 25, 2005 [Page 9] =0C Internet-Draft Bundle Security Protocol May 2005 parameter had been set.[Comment.12] A method that the receiving bundle protocol agent MAY [Comment.13] use to detect duplicates is to look at the (source, timestamp) pair value of each received bundle and determine if this pair value, which uniquely identifies a bundle, has been received before. If it has, then the bundle is a duplicate and SHALL be discarded. If it has not, then the bundle SHALL be delivered to the bundle node and the (source, timestamp) pair value SHALL be added to the list of pair values already received by that bundle protocol agent. Symington, et al. Expires November 25, 2005 [Page 10] =0C Internet-Draft Bundle Security Protocol May 2005 3. Security Headers There are three security headers that MAY be included in a bundle as listed in the Bundle Protocol [2]. These are the Bundle Authentication Header (BAH), the Payload Security Header (PSH), and the Confidentiality Header (CH). The BAH is used to assure the authenticity of the bundle along a single hop from sender to recipient. The PSH is used to assure the authenticity of the bundle from the PSH security-source, which creates the PSH, to the PSH security-destination, which verifies the PSH authenticator. The authentication information in the PSH may (if the ciphersuite allows) be verified by any bundle protocol agent in between the PSH security-source and the PSH security-destination that has access to the cryptographic keys and revocation status information required to do so. The CH indicates that the bundle payload (and possibly other bundle fields) has been encrypted while en route between the CH security-source and the CH security-destination. 3.1 Abstract Security Header Since the three security headers have most fields in common, we can shorten the description of them if we first define an abstract security header (ASH) and then specify each of the real headers in terms of the fields which are present/absent in an ASH. Note that no bundle ever contains an ASH, which is simply a specification artifact An ASH consists of the following mandatory and optional fields: [Comment.14] Header-type - as in all bundle protocol headers except the primary bundle header Flags - as in all bundle protocol headers[Comment.15] Length - the overall length of this header encoded as an SDNV-8 (see below). This includes the bytes required for the header type and ciphersuite ID fields. Ciphersuite ID - identifies the ciphersuite in use. This is one byte long, though the top three bytes are used to indicate the presence or absence of the three optional fields (see below). (optional) Ciphersuite parameters - parameters to be used with the ciphersuite in use, e.g. a key identifier or initialization vector (IV). This is encoded as an SDNV-8. (optional) Security-source - specifies the security source for the service. If this is omitted, then the source of the bundle is assumed to be the security-source. This is encoded using the normal bundle identity encoding scheme (see below). (optional) Security-destination - specifies the security destination for the service. If this is omitted, then the Symington, et al. Expires November 25, 2005 [Page 11] =0C Internet-Draft Bundle Security Protocol May 2005 destination of the bundle is assumed to be the security-destination. This is encoded using the normal bundle identity encoding scheme (see below). Security result - contains the results of the appropriate ciphersuite-specific calculation (e.g. a signature, or MAC or encrypted session key). This is encoded as an SDNV-16. The ciphersuite ID is an eight bit value with the top three bits indicating which of the optional fields are present (value =3D "1") = or absent (value=3D"0"). The remaining five bits indicate the ciphersuite. Some ciphersuites are specified in Section 5, which also specifies the rules which MUST be satisfied by ciphersuite specifications. Additional ciphersuites MAY be defined in separate specifications. The structure of the ciphersuite ID byte is shown in Figure 2 src - the most significant bit (bit 7) indicates whether the ASH contains an optional security source (value=3D"1") or not (value=3D"0") dest - the 2nd most significant bit (bit 6) indicates whether the ASH contains an optional security destination (value=3D"1") or not (value=3D"0") parm - the 3rd most significant bit (bit 5) indicates whether the ASH contains an optional ciphersuite parameters (value=3D"1") or = not (value=3D"0") Ciphersuite ID Bit Bit Bit Bit Bit Bit Bit Bit 7 6 5 4 3 2 1 0 +-----+-----+-----+-----+-----+-----+-----+-----+ |src |dest |parm | ciphersuite ID | +-----+-----+-----+-----+-----+-----+-----+-----+ Figure 2 The Self-Delimiting Numeric Value (SDNV) scheme is a way of encoding variable length values and is described in the Licklider Transmission Protocol [5]. There are two variants described there: SDNV-8 and SDNV-16 and we use both. The security source and destination fields are encoded as are all other bundle endpoint IDs using the schema/mark scheme specified in the base Bundle Protocol Specification. [2] A little bit more terminology: when the header is a PSH then we refer to the PSH-source when we mean the security source field in the PSH. Symington, et al. Expires November 25, 2005 [Page 12] =0C Internet-Draft Bundle Security Protocol May 2005 Similarly we may refer to the CH-dest, meaning the security-destination field of the CH. 3.2 Bundle Authentication Header A BAH is an ASH with the following additional restrictions: the header-type value MUST be 0x07 as defined in the Bundle Protocol Specification [2] the flags field MUST be present as defined in the Bundle Protocol Specification the ciphersuite ID MUST be documented as a hop-by-hop authentication-ciphersuite the ciphersuite parameters field MAY be present the security-source field MUST NOT be present[Comment.16] the security-destination field MUST NOT be present the security result is effectively the "output" from the ciphersuite calculation (e.g. the MAC or signature) applied to the (relevant parts of) the bundle. 3.3 Payload Security Header A PSH is an ASH with the following additional restrictions: the header-type value MUST be 0x08 as defined in the Bundle Protocol Specification [2] the flags field MUST be present as defined in the Bundle Protocol Specification. It SHOULD indicate that the header does not need to be duplicated on all fragments. the ciphersuite ID MUST be documented as an end-to-end authentication-ciphersuite or as an end-to-end error-detection-ciphersuite; the type of protection provided by the PSH (authentication versus error-detection) is indicated by the type of ciphersuite used the ciphersuite parameters field MAY be present the security-source field MAY be present the security-destination field MAY be present the security result is effectively the "output" from the ciphersuite calculation (e.g. the MAC or signature) applied to the (relevant parts of) the bundle. For some ciphersuites, (e.g. those using asymmetric keying to produce signatures or those using symmetric keying with a group key), the security information can be checked at any hop on the way to the destination that has access to the required keying information. Most symmetric PSH-ciphersuites will not require a PSH-source but simply a PSH-destination to indicate which node has access to the key needed to verify the PSH authenticator. Most asymmetric PSH-ciphersuites will use the PSH-source to indicate the signer and Symington, et al. Expires November 25, 2005 [Page 13] =0C Internet-Draft Bundle Security Protocol May 2005 will not require the PSH-dest field because the key needed to verify the PSH authenticator will be a public key associated with the PSH-source. 3.4 Confidentiality Header [Comment.17] A PSH is an ASH with the following additional restrictions: the header-type value MUST be 0xTBD [Comment.18] the flags field MUST be present as defined in the Bundle Protocol Specification. It SHOULD indicate that the header does not need to be duplicated on all fragments. the ciphersuite ID MUST be documented as a confidentiality-ciphersuite the ciphersuite parameters field MAY be present the security-source field MAY be present the security-destination field MAY be present the security result normally represents an encrypted bundle encryption key A typical confidentiality ciphersuite will encrypt the payload using a randomly generated payload encrypting key (PEK) and then use the security result to carry the PEK encrypted with some long term key encryption key (KEK). The CH-dest field will typically indicate the decryption key with which the PEK can be recovered.[Comment.19] 3.5 PSH and CH combinations [Comment.20] Symington, et al. Expires November 25, 2005 [Page 14] =0C Internet-Draft Bundle Security Protocol May 2005 4. Security Processing This section describes the security aspects of bundle processing. The subsections here parallel the subsections of section 4, Bundle Processing, in the Bundle Protocol Specification [2] to make it easier for the reader to understand how the security steps described herein fit into the Bundle Protocol. [Comment.21] All Bundle Protocol Agents are required to have and enforce their own configurable security policies, whether these policies be explicit or default, as defined in Section 6. 4.1 Bundle Transmission Requests As described in Section 4.1 of the Bundle protocol [2], which enumerates the steps in processing a Send.request primitive, all bundle protocol agents serve as Policy Enforcement Points (PEP) insofar as they enforce polices that may restrict the permissions of bundle nodes to inject traffic into the network. If a particular Send.request satisfies the bundle protocol agent's policy and is therefore accepted, then an outbound bundle SHALL be created and dispatched. The security-specific steps in processing a Send.request primitive to create the outbound bundle are as follows: For clarity, the text below ignores the fact that the policy enforcing code MAY override all of the processing steps described. For example, it is valid to implement a bundle protocol agent which always attempts to attach a PSH. Similarly it is also valid to implement a bundle protocol agent which always rejects all requests which imply the use of a PSH. Basically, the policy code is allowed to override the algorithm described below, except in the case in which the Send.request asks for some service that is not allowed by the policy code. In this case, the bundle protocol agent MUST NOT send a bundle because to do so by sending a bundle without the requested service would mean that the bundle protocol agent would be transmitting data in a manner that is not as secure as was requested, but without the bundle node's knowledge. If the Send.request primitive includes a Delivery Options parameter and that Delivery Options parameter includes a Payload Security Requirements item, the following steps SHALL be taken, in order, depending on the values of the Confidentiality, Authentication, and Error-detection elements of the Payload Security Requirements item. If the Send.request primitive does not include a Delivery Options parameter with a Payload Security Requirements item, processing SHALL proceed beginning at Section 4.5 below. Confidentiality Symington, et al. Expires November 25, 2005 [Page 15] =0C Internet-Draft Bundle Security Protocol May 2005 If the Confidentiality element is present in the Delivery Options parameter of the Send.request primitive, this indicates that the payload MUST be encrypted and a CH header MUST be added to the bundle. If the Confidentiality element is not present, a CH header SHALL NOT be created for this bundle, unless indicated by local policy. Authentication If the authentication element is present in the Delivery Options parameter of the Send.request primitive a PSH SHALL be created. (If both the authentication and error-detection options are indicated in the Send.request primitive, the authentication option takes precedence and authentication is provided, because authentication encompasses both authentication and error-detection.) Error-detection If the Error-detection element is present in the Delivery Options parameter of the Send.request primitive but the Authentication element is not present, a PSH SHALL be created. If neither the Authentication nor the Error-detection elements of the Delivery Options parameter of the Send.request primitive are present, a Payload Security Header SHALL NOT be created for this bundle, unless indicated by local policy. Ciphersuites and Ciphersuite Parameters The following rules hold for each of the confidentiality, authentication, and error-detection elements: If any element (confidentiality, authentication, or error-detection) includes a ciphersuite ID then the corresponding header (CH or PSH) and calculation MUST use this ciphersuite or else the bundle MUST NOT be transmitted/forwarded. All rules specified in the ciphersuite definition MUST be followed. If any element does not include a ciphersuite ID then the corresponding header and calculation MUST use the default ciphersuite or else the bundle MUST NOT be transmitted/forwarded. All rules specified in the default ciphersuite definition MUST be followed. If ciphersuite parameters are provided they MUST be honored. It is an error to emit a bundle using some other parameters. If ciphersuite parameters are not provided then the default parameters for that ciphersuite MUST be used. 4.2 Canonicalisation of bundles In order to verify a signature or MAC on a bundle the exact same bits must be input to the calculation upon verification as were input upon initial computation of the original signature or MAC value. Since bundles may be modified while in transit (either correctly or due to Symington, et al. Expires November 25, 2005 [Page 16] =0C Internet-Draft Bundle Security Protocol May 2005 implementation errors), a canonical form of any given bundle (that contains a PSH) must be defined. This section defines the default bundle canonicalisation algorithm.[Comment.22] In order for the PSH to be useful, all bundle information over which the PSH is calculated at the source must be the same, and in the same order, as all bundle information over which the PSH is calculated at the point at which the PSH is being validated. Therefore, the following transmission requirements SHALL hold: Once any of the following headers are placed in a bundle, they MUST both remain in the bundle and continue to be positioned in the same order relative to one another in the bundle as the bundle travels through the DTN to its destination. Neither the presence nor the position of these headers relative to one another is allowed to change at any time. If the bundle becomes fragmented, each of these headers MUST be present in some fragment and they must continue to be positioned in the same order following bundle re-assembly: Primary Bundle Header Dictionary Header Override Report-to Header Source Routing Header Payload Security Header Confidentiality Header Bundle Payload Header If a Payload Security Header is placed in a bundle, it MUST remain in the bundle and continue to be positioned in the same order relative to the other bundle headers as the bundle travels throughout the DTN. However, if the bundle becomes fragmented, at least the fragment containing the initial portion of the original payload (that is, the fragment that has a Fragment Offset field value of zero) MUST contain the PSH and at least some fragment MUST contain the CH. The following additional headers MAY be present in the bundle when it arrives at a bundle protocol agent or at the destination, and if they are present, they must be (logically) removed from the bundle before the PSH is verified: Custody related headers Bundle Authentication Header Bundle Fragment Header Before the PSH is initially calculated and before it is verified by applying the appropriate ciphersuite to the appropriate parts of the Symington, et al. Expires November 25, 2005 [Page 17] =0C Internet-Draft Bundle Security Protocol May 2005 bundle, the fields of the bundle that are mutable as the bundle travels from source to destination must be temporarily made irrelevant to the calculation by performing the following: the BAH, if present, MUST be removed from the bundle the offset values in the source, destination, reply-to endpoint, sender, CH security-source (if present), CH security-destination (if present), PSH security-source (if present), and PSH security-destination (if present) fields must be used to obtain the corresponding scheme/mark format of the endpoint IDs from the dictionary header and these endpoint IDs MUST be substituted for their corresponding fields in the concatenated bundle header for purposes of calculating the PSH authenticator over the bundle. Note that if additional bundle headers that contain offsets into the dictionary header are defined (e.g., a source route header), then the definition of the new header SHOULD specify whether or not the referenced endpoint IDs should be substituted for the corresponding offset fields in the new header when constructing the canonical form of the bundle for purposes of computing the PSH. If a new header is defined and its definition does not specify whether or not the referenced endpoint IDs should be substituted for the corresponding fields in the header, then by default they SHALL be. the portion of the dictionary header corresponding to the custodian field (as indicated by the offset value in the custodian field of the Primary Bundle Header) MUST be zeroed out the portion of the dictionary header corresponding to the sender field (as indicated by the offset value in the sender field of the Primary Bundle Header) MUST be zeroed out the security information field of the PSH MUST be zeroed out[Comment.23] 4.3 Creating a Confidentiality Header This subsection describes the steps taken to create the CH and populate it with the appropriate values as well as modify the payload field of the Bundle Payload Header. If the CH is being created by some entity other than the bundle source, then a CH-source field MUST be placed in the CH and populated with the endpoint ID of the entity creating the CH. [Comment.24] The values of the CH MUST be populated as described in Section 3 and according to the rules of the relevant ciphersuite described in Section 5. All ciphersuites will require the input to the security result calculation to include at least the bundle payload. Some ciphersuites will require the input to include the bundle payload concatenated with some canonical sequence of bundle header fields (e.g., source, destination, portions of the dictionary header) for Symington, et al. Expires November 25, 2005 [Page 18] =0C Internet-Draft Bundle Security Protocol May 2005 which confidentiality will also be provided. Note that the security result calculated will be placed in the payload field of the bundle payload header. The CH does not include a field for the security result.[Comment.25] 4.4 Creating the Payload Security Header This subsection describes the steps taken to create the PSH and populate it with the appropriate values. A PSH MUST be created after all other bundle headers except for the BAH have been added to the bundle and populated with their correct values. If the PSH is being created by some entity other than the bundle source, then a PSH-source field MUST be placed in the PSH and populated with the endpoint ID of the entity creating the PSH. The values of the PSH MUST be populated as described in Section 3 and according to the rules of the relevant ciphersuite described in Section 5. Almost all ciphersuites will require the input to the security result calculation to be the canonical form (see Section 4.2) of the bundle. 4.5 Creating the Bundle Authentication Header Regardless of whether or not the Send.request primitive includes a delivery options parameter, the bundle protocol agent SHALL consult its security policy to determine whether or not the bundle MUST be provided with a Bundle Authentication Header before being forwarded. If the bundle does not need to be provided with a BAH, no additional security-related processing is required. The optional ciphersuite parameters field of the BAH SHOULD (if bandwidth permits) be included in the BAH. The authentication information field of the PSH SHALL be zeroed out before the ciphersuite is applied to the (relevant parts of) the bundle. 4.6 Bundles received from other bundle protocol agents The security-specific steps in processing a bundle received from another bundle protocol agent are as follows: The receiving bundle protocol agent SHALL consult its security policy to determine whether or not the bundle is required to include a BAH. If the bundle is not required to have a BAH, then security processing Symington, et al. Expires November 25, 2005 [Page 19] =0C Internet-Draft Bundle Security Protocol May 2005 on the received bundle is complete and the bundle is ready to be processed for either local delivery or forwarding. If the bundle is required to have a BAH but it does not, then the bundle MUST be discarded and processed no further; in this case a bundle status report indicating the authentication failure MAY be generated, destined for the receiving bundle protocol agent's own endpoint. Otherwise, if the bundle does have a BAH, then the value in the authentication information field of the BAH of the received bundle MUST be verified according to the ciphersuite specification. If the check fails, the bundle has failed to authenticate and the bundle SHALL be discarded and processed no further; in this case, a bundle status report indicating the authentication failure MAY be generated, destined for the receiving bundle protocol agent's own endpoint. Otherwise, if the BAH verifies, it is ready to be processed for either local delivery or forwarding. 4.7 Local Bundle Delivery The security-specific steps in processing a bundle if one or more bundle nodes have registered with the bundle protocol agent to receive bundles sent to the bundle's destination endpoint ID are as follows: These steps SHALL be performed after the payload of the original bundle has been reassembled from the payloads of received fragments, if necessary, to reconstruct the original bundle in its entirety. If the bundle does not include a Payload Security Header, then security processing on the received bundle should proceed from Section 4.8 below. Otherwise, if the bundle does include a PSH, then the value in the security results field of the PSH of the received bundle MUST be verified according to the rules of the ciphersuite. If the received value fails verification, the bundle has failed to authenticate and the bundle SHALL be discarded and processed no further; in this case, a bundle status report indicating the authentication failure MAY be generated, destined for the receiving bundle protocol agent's own endpoint. Otherwise, if the check passes, the bundle has been authenticated as having been sent from the claimed source and as not having been modified since being sent. 4.8 Optionally checking for Replays If one or more bundle nodes have indicated that they want to use the "at most once" delivery option when they registered with the bundle Symington, et al. Expires November 25, 2005 [Page 20] =0C Internet-Draft Bundle Security Protocol May 2005 protocol agent using the destination endpoint ID that is in the bundle, then the bundle protocol agent MUST compare the (source, timestamp) pair values of the bundle with the local list of such values of already-received bundles. If the pair value is a duplicate, the bundle MUST be discarded and a bundle status report indicating the failure MAY be generated, destined for the receiving bundle protocol agent's own endpoint. If the pair value is unique, the pair MUST be added to the local list. 4.9 Bundle Forwarding The security-specific steps in processing a bundle if no bundle nodes have registered with the bundle protocol agent to receive bundles sent to the bundle's destination endpoint ID are as follows: The bundle protocol agent SHALL determine the next hop for the bundle. The bundle protocol agent SHALL consult its security policy to determine the criteria that the received bundle ought to meet before it will be forwarded. These criteria MAY include a determination of whether or not the received bundle must include a valid BAH, PSH or CH. If the bundle does not meet the bundle protocol agent's policy criteria, then the bundle MUST be discarded and processed no further; in this case, a bundle status report indicating the failure MAY be generated, destined for the forwarding bundle protocol agent's own endpoint. [Comment.26][Comment.27] If the bundle does meet the bundle protocol agent's policy criteria, then the bundle protocol agent's endpoint ID SHALL be inserted into the Data Dictionary, if it is not already there, and a pointer to this string SHALL be placed in the sender ID field of the Primary Bundle Header. If the bundle is not a bundle fragment, and if the bundle does not already have a PSH, the bundle protocol agent SHALL consult its security policy to determine whether or not it should add a PSH to the bundle. If so, the PSH SHALL be created and have its fields populated with all of the appropriate values as described in "Creating the Payload Security Header" (see Section 4.4). In particular, the forwarding bundle protocol agent MUST populate the Security Source field of the PSH with its own endpoint ID. Next, the bundle protocol agent SHALL consult its security policy to determine whether or not the bundle needs to be given a BAH. If so, the BAH SHALL be created and have its fields populated with all of the appropriate values as described in "Creating the Bundle Authentication Header" (Section 4.5). Symington, et al. Expires November 25, 2005 [Page 21] =0C Internet-Draft Bundle Security Protocol May 2005 If the bundle is to be fragmented before being forwarded, each of the fragments MUST be given its own BAH that is specific to that fragment. At this point, the bundle is ready for forwarding. 4.10 Bundle Fragmentation and Reassembly If it is necessary for a bundle protocol agent to fragment a bundle and security is being used on that bundle, the following security-specific processing is REQUIRED: If the bundle is required by the security policy to have a BAH before being forwarded, all fragments resulting from that bundle MUST contain individual BAH values. If the original bundle had a PSH, then the fragment that is given a Fragment Offset field value of zero MUST include an exact copy of the PSH that was in the original bundle. If the original bundle had a CH, then some fragment MUST include an exact copy of the CH that was in the original bundle. When original bundle transmission is terminated before the entire payload has been transmitted, the receiving bundle protocol agent SHALL consult its security policy to determine whether it is permitted to transform the received portion of the bundle into a bundle fragment for further forwarding. Whether or not such reactive fragmentation is permitted SHALL be dependent on the security policy in combination with the ciphersuite used to calculate the BAH authentication information. [Comment.28] In such cases, if the original bundle is fragmented by the recipient (reactively), and the BAH-ciphersuite is a TP-ciphersuite (see Section 5), the bundle MUST be fragmented immediately after the last hash value in the partial payload that is received. Any data received after the last hash value MUST be dropped. If an original bundle transmission is terminated before the entire payload has been transmitted, if the truncated bundle arriving at the receiving bundle protocol agent is reactively fragmented and forwarded, only the part of the bundle that was not received must be retransmitted at the source (providing it has not yet expired). Before retransmitting this portion of the bundle, it SHALL be changed into a fragment and, if the original bundle included a BAH, the fragmented bundle MUST also, and its BAH SHALL be recalculated. If a TP-type ciphersuite is in use for this bundle, all of the hashes interspersed in its payload shall be recalculated. Symington, et al. Expires November 25, 2005 [Page 22] =0C Internet-Draft Bundle Security Protocol May 2005 4.11 Custodial Retransmission and Release No security-specific steps relating to the custodial retransmission and release phase of bundle processing have yet been identified. 4.12 Bundle Status Report Status Flags The following security-specific values for Bundle Status Report Status Flags have been defined in addition to those already present in Table 5 of the Bundle Protocol Specification [2]: A source was found to lack the appropriate permissions to use the requested COS The security policy does not permit acceptance of a bundle is received without a BAH. A bundle failed the hop-by-hop bundle authentication check (using the Bundle Authentication Header). A bundle failed the end-to-end authentication check (using the Payload Security Header) at an intermediate DTN security policy node. A bundle was found to be an illegitimate replay at an intermediate node. (Note that no method of detecting such replays has yet been defined.) A bundle failed the end-to-end authentication check (using the Payload Security Header) at the destination host. A bundle was found to be an illegitimate replay at the destination host. Received a payload longer than that defined by the preceding bundle header. The indicated BAH ciphersuite is not implemented. The indicated PSH ciphersuite is not implemented. the indicated CH ciphersuite is not implemented. 4.13 Convergence Layer Security Services As discussed in the Bundle Protocol Specification [2], the convergence layer SHALL deliver the Bundle.indication primitive to the bundle protocol, and one of the parameters of this primitive, Bundle Authenticity, is security-specific. The meaning of this parameter and its possible values are defined in the Bundle Protocol Specification [2]. Symington, et al. Expires November 25, 2005 [Page 23] =0C Internet-Draft Bundle Security Protocol May 2005 5. Ciphersuites Four types of ciphersuites are defined: hop-by-hop authentication ciphersuites for use in the BAH end-to-end authentication ciphersuites for use in the PSH end-to-end error-detection ciphersuites for use in the PSH confidentiality ciphersuites The ciphersuite field of the BAH, PSH and CH are 5-bit integer values as defined below: [Comment.29] EntireBundleHMAC - value 000 HeadOfBundleHMAC - value 001 EntireBundleSig - value 011 HeadOfBundleSig - value 010 CombinationSig - value 100 EntireBundleMAC - value 101 TP-HMAC - value 1111 TP-HSIG - value 1110 TP-DSS - value 1101[Comment.30] 5.1 EntireBundleHMAC Ciphersuite This ciphersuite involves computing a MAC over the entire bundle using HMAC-SHA1. It is both a hop-by-hop authentication ciphersuite and an end-to-end authentication ciphersuite, so it may be used to calculate the BAH security result and/or the PSH security result. If used to calculate the BAH security result, the authentication information field of the BAH MUST be zeroed out before the ciphersuite is applied, and the ciphersuite MUST be applied to the entire bundle. If used to calculate the PSH security result, the bundle must be put into canonical form as described in Section 4.2 before the ciphersuite is applied, and the ciphersuite MUST be applied to the entire bundle. 5.1.1 Ciphersuite Parameters This ciphersuite has one associated parameter, which identifies the cryptographic key used in the HMAC computation. This parameter is encoded in SDNV-8 format. 5.2 HeadOfBundleHMAC Ciphersuite This ciphersuite involves computing a MAC over the entire bundle except for the payload field of the Bundle Payload Header using HMAC-SHA1. It is both a hop-by-hop authentication ciphersuite and an Symington, et al. Expires November 25, 2005 [Page 24] =0C Internet-Draft Bundle Security Protocol May 2005 end-to-end authentication ciphersuite, so it may be used to calculate the BAH security result and/or the PSH security result. If used to calculate the BAH security result, the authentication information field of the BAH MUST be zeroed out before the ciphersuite is applied, and the ciphersuite MUST be applied to the entire bundle except for the payload field. If used to calculate the PSH security result, the bundle must be put into canonical form as described in Section 4.2 before the ciphersuite is applied, and the ciphersuite MUST be applied to the entire bundle except for the payload field. 5.2.1 Ciphersuite Parameters This ciphersuite has one associated parameter, which identifies the cryptographic key used in the HMAC computation. This parameter is encoded in SDNV-8 format. 5.3 EntireBundleSig Ciphersuite This ciphersuite involves using SHA-1 to compute a hash over the entire bundle and then signing this hash by generating a Digital Signature Standard (DSS) signature. It is both a hop-by-hop authentication ciphersuite and an end-to-end authentication ciphersuite, so it may be used to calculate the BAH security result and/or the PSH security result. If used to calculate the BAH security result, the authentication information field of the BAH MUST be zeroed out before the ciphersuite is applied, and the ciphersuite MUST be applied to the entire bundle. If used to calculate the PSH security result, the bundle must be put into canonical form as described in Section 4.2 before the ciphersuite is applied, and the ciphersuite MUST be applied to the entire bundle. 5.3.1 Ciphersuite Parameters This ciphersuite has one associated parameter, which identifies the cryptographic key used to create the signature. This parameter is encoded in SDNV-8 format. 5.4 HeadOfBundleSig Ciphersuite This ciphersuite involves using SHA-1 to compute a hash over the entire bundle except for the payload field of the Bundle Payload Symington, et al. Expires November 25, 2005 [Page 25] =0C Internet-Draft Bundle Security Protocol May 2005 Header and then signing this hash by generating a DSS signature. It is both a hop-by-hop authentication ciphersuite and an end-to-end authentication ciphersuite, so it may be used to calculate the BAH security result and/or the PSH security result. If used to calculate the BAH security result, the authentication information field of the BAH MUST be zeroed out before the ciphersuite is applied, and the ciphersuite MUST be applied to the entire bundle except for the payload field. If used to calculate the PSH security result, the bundle must be put into canonical form as described in Section 4.2 before the ciphersuite is applied, and the ciphersuite MUST be applied to the entire bundle except for the payload field. 5.4.1 Ciphersuite Parameters This ciphersuite has one associated parameter, which identifies the cryptographic key used to create the signature. This parameter is encoded in SDNV-8 format. 5.5 CombinationSig Ciphersuite [Comment.31] This ciphersuite involves using SHA-1 to compute two hash values: a hash over just the head of the bundle (the entire bundle except for the payload field of the Bundle Payload Header), and a hash over the entire bundle. These two hash values are concatenated (the hash of the head of the bundle preceding the hash of the entire bundle) and the concatenated result is signed by generating a DSS signature. It is only a hop-by-hop authentication ciphersuite, so it may only be used to calculate the BAH security result. The authentication information field of the BAH MUST be zeroed out before this ciphersuite is applied. 5.5.1 Ciphersuite Parameters This ciphersuite has one associated parameter, which identifies the cryptographic key used to create the signature. This parameter is encoded in SDNV-8 format. 5.6 EntireBundleMAC This ciphersuite involves using SHA-1 to compute a hash value over the entire bundle. No keys are involved. It is only an end-to-end error-detection ciphersuite, so it may only be used to calculate the PSH security result. Symington, et al. Expires November 25, 2005 [Page 26] =0C Internet-Draft Bundle Security Protocol May 2005 The bundle must be put into canonical form as described in Section 4.2 before this ciphersuite is applied, and the ciphersuite MUST be applied to the entire bundle. 5.6.1 Ciphersuite Parameters This ciphersuite has no associated parameters, so no associated parameters fields are included in the PSH when this ciphersuite is used. 5.7 TP-type Ciphersuites [Comment.32] All TP-type ciphersuites involve breaking the bundle payload into segments of a given size, computing authentication information for the bundle header concatenated with that payload segment, and inserting the authentication information for a given segment into the payload itself right after the given segment. Therefore, the payload of a bundle on which the TP Ciphersuite was used to calculate the authentication information would be formatted as a sequence of payload segments of a given size interspersed with authentication information of a given size. [Comment.33] There are several TP-type ciphersuites that have been defined. All involve formatting the payload as fixed-length segments of payload followed by fixed-length authentication information calculated over the bundle header concatenated with the previous payload segment. The only differences between the various TP-type ciphersuites is the method used to calculate the authentication information. [Comment.34] We may define the following TP-ciphersuites: TP-HMAC Ciphersuites TP-HSIG Ciphersuites TP-DSS Ciphersuites [Comment.35] 5.7.1 Ciphersuite Parameters The following two parameters must be included with TP-type ciphersuites that use fixed-length payload and segment sizes: segment-length, authenticator-length. These two fields MUST be included in the BAH and PSH headers that use such TP-type ciphersuites and they MUST be encoded in SDNV-8 format. Symington, et al. Expires November 25, 2005 [Page 27] =0C Internet-Draft Bundle Security Protocol May 2005 6. Default Values Several of the security headers include optional fields that MAY contain ciphersuite parameter information. If a bundle includes a security header that does not contain one of these optional fields, then the default value for that field SHALL be used. The default values are as follows: BAH Ciphersuite ID: EntireBundleSig [Comment.36] BAH EntireBundleSig parameters: The key associated with the endpoint indicated in the sender field of the Primary Bundle Header. If this value is not valid, use the key associated with the endpoint ID that was passed up as a parameter of the Bundle.Indication primitive. PSH Ciphersuite ID when Authentication is being used: TBD PSH Ciphersuite ID when Error Detection is being used: TBD PSH ciphersuite parameters: If the PSH includes an optional PSH Security-Source field, use the key associated with the endpoint indicated in this field. Otherwise, use the key associated with the endpoint indicated by the source field of the primary bundle header. CH ciphersuite ID: TBD CH ciphersuite parameter: If the CH includes an optional CH Security-Source field, use the key associated with the endpoint indicated in this field. Otherwise, use the key associated with the endpoint indicated by the source field of the primary bundle header. Default Security Policy. Every bundle protocol agent serves as a Policy Enforcement Point (PEP) insofar as it enforces some policy that controls the forwarding and delivery of bundles via one or more interfaces. Consequently, every bundle protocol agent SHALL have and operate according to its own configurable security policy, whether the policy be explicit or default. The policy SHALL specify: Under what conditions received bundles SHALL be forwarded. Under what conditions received bundles SHALL be required to include valid BAHs. Under what conditions the authentication information provided in a bundle's BAH SHALL be deemed adequate to authenticate the bundle. Under what conditions received bundles SHALL be required to have valid PSHs. Under what conditions the authentication information provided in a bundle's PSH SHALL be deemed adequate to authenticate the bundle. Under what conditions a BAH SHALL be added to a received bundle before that bundle is forwarded. Symington, et al. Expires November 25, 2005 [Page 28] =0C Internet-Draft Bundle Security Protocol May 2005 Under what conditions a PSH SHALL be added to a received bundle before that bundle is forwarded. The actions that SHALL be taken in the event that a received bundle does not meet the receiving bundle protocol agent's security policy criteria. This specification does not address how security policies get distributed to bundle protocol agents. It only REQUIRES that bundle protocol agents have and enforce security policies. [Comment.37] If no security policy is specified at a given bundle protocol agent, or if a security policy is only partially specified, that bundle protocol agent's default policy regarding unspecified criteria SHALL consist of the following: Bundles that are not well-formed do not meet the security policy criteria. All bundles received MUST either have their authenticity asserted by the convergence layer or by valid authentication information present in a BAH. If the value of the Bundle Authenticity parameter of the convergence layer Bundle.indication primitive is "Bundle authenticity is asserted", then bundle authentication is complete. If the value of the Bundle Authenticity parameter is "Bundle authenticity is denied", or "Bundle authenticity is unknown", then the bundle MUST have a BAH and the value of the authentication information field of the BAH must be verified. In this case, if the bundle does not have a BAH, then the bundle must be discarded and processed no further; a bundle status report indicating the authentication failure may be generated, destined for the receiving bundle protocol agent's own endpoint. If the bundle does have a BAH, then the value in its authentication information field SHALL be verified. The authentication information value in the BAH MUST be calculated using the YADA-YADA-YADA ciphersuite; that is, the value MUST be calculated over the entire/head/specific segmented portion of the bundle, using the yada-yada-yada algorithms. No received bundles SHALL be required to have a PSH; if a received bundle does have a PSH, however, that can be ignored unless the receiving protocol agent is the destination bundle protocol agent, in which case the PSH MUST be verified. The security information value in the PSH MUST be calculated using the YADA-YADA-YADA ciphersuite; that is, the value MUST be calculated over the entire/head of the bundle, using the yada-yada-yada algorithms. A PSH SHALL NOT be added to a bundle before sourcing or forwarding it. A BAH MUST always be added to a bundle before that bundle is forwarded. Symington, et al. Expires November 25, 2005 [Page 29] =0C Internet-Draft Bundle Security Protocol May 2005 If a received bundle does not satisfy the bundle protocol agent's security policy for any reason, then the bundle MUST be discarded and processed no further; in this case, a bundle status report indicating the failure SHOULD be generated, destined for the receiving bundle protocol agent's own endpoint. Symington, et al. Expires November 25, 2005 [Page 30] =0C Internet-Draft Bundle Security Protocol May 2005 7. Security Considerations TBD. We have to add text here describing the downside of using these mechanisms (e.g. new DoS opportunities), issues with key mgmt, implementation hints, ciphersuite strength considerations etc. etc. Ok to do it a bit later though, but we should start collecting items now. 8. References [1] Bradner, S. and J. Reynolds, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, October 1997. [2] Scott, K., "Bundle Protocol Specification", draft-irtf-dtnrg-bundle-spec-02.txt , September 2004. [3] Symington, S., "Delay-Tolerant Network Security Overview and Motivation", draft-irtf-dtnrg-securityOverview-spec-01.txt , March 2005. [4] Cerf, V., "Delay-Tolerant Network Architecture", draft-irtf-dtnrg-arch-02.txt , July 2004, . [5] Burleigh, S., "Licklider Transmission Protocol", draft-irtf-dtnrg-ltp-01.txt , July 2004. [6] Durst, R., "An Infrastructure Security Model for Delay Tolerant Networks", http://www.dtnrg.org/ , July 2002. [7] Warthman, F., "Delay-Tolerant Networks (DTNs) A Tutorial", http://www.dtnrg.org/ , March 2003. Symington, et al. Expires November 25, 2005 [Page 31] =0C Internet-Draft Bundle Security Protocol May 2005 Editorial Comments [Comment.1] Editors: Actually, the "bundle security is RECOMMENDED" statement needs to be in the core Bundle Protocol spec and not here. But for now, let's put it here until we get agreement with the larger group. [Comment.2] Editors: We're using the xml2rfc tools so embedded comments are marked like this. [Comment.3] Editors: This is the first informative reference. We should, if we want to look like a standards-track RFC, distinguish between normative and informative but I'm not sure how to with this tool yet. [Comment.4] Editors: There may be some (valid) question marks over this terminology. We weren't entirely sure ourselves. [Comment.5] Editors: There is still work to be done on how to handle potential combinations of security services (e.g., confidentiality with authenticity). [Comment.6] Editors: We discussed whether to model e.g. the "signer" as the bundle node or the bundle protocol agent that provides the bundle service to the bundle node. In the end, we didn't care too much and are happy to allow either term. The main reasons we didn't care were a) due to the fact that there's mainly no real security difference since a suitable API that properly isolates which layer is trusting which other layer for what is at least very hard, and b) the destination mostly doesn't care which layer of the cake signed in any case. [Comment.7] Editors: This section needs to be coordinated with the Bundle Protocol Spec. [Comment.8] Editors: The extent to which the interfaces defined in this section should reflect a 1:1 correspondence with the protocol data units is to be determined. The issue is that we want to allow policy code below the interface to influence matters, so, e.g. if the interface omits to specify, or defaults, an algorithm parameter then the implementation could select anything, presumably after running some policy code. The net effect is that the PDUs reflect some combination of the interface inputs and the policy settings. Symington, et al. Expires November 25, 2005 [Page 32] =0C Internet-Draft Bundle Security Protocol May 2005 [Comment.9] Editors: Basic confidentiality requires that the payload be encrypted; we may also want to define a confidentiality service that also keeps certain fields like source and destination confidential. It is not clear if we should define specific ciphersuites to provide specific types of confidentiality or if we should specify that a tunnel be created and used to provide confidentiality of the entire bundle. Note that encrypting certain fields like source and destination would not be sufficient, given that these fields only contain offsets into the Dictionary Header. Appropriate portions of the dictionary header would have to be encrypted as well. [Comment.10] Editors: This might be done this way or else changed to not use the PSH in order to make it clearer that we're not getting data integrity from this service (alone). The reason to do it this way is that it provides a nice debugging option to verify much of the non-key management code in a bundle-security stack. That may, or may not be considered sufficient benefit for the potential confusion caused. [Comment.11] Editors: Note, this parameter still has to be added to the Bundle Spec. [Comment.12] Editors: there's definitely more to be said about replay, so consider this as a placeholder until decisions on replay get made. [Comment.13] Editors: This can't be a MAY. There has to be some MUST somewhere. [Comment.14] Editors: Details of this encoding scheme will change. The next-header mightn't become header-type; depending on how the sources are encoded (a moving target elsewhere) we may need to include an offset to point to the start of those and 32 is really a factor of ~3 too small for specifying all standard ciphersuites ever. [Comment.15] This flags field is brand new; we still have to discuss how the sittings of its various bits get selected (Send.Request interface parameters, possibly overridden by security policy) as well as how it is treated. Security policy will take precedence. Will the flags be obeyed if the policy is silent? [Comment.16] Editors: This is assuming that the primary bundle Symington, et al. Expires November 25, 2005 [Page 33] =0C Internet-Draft Bundle Security Protocol May 2005 header has a "sender" field, as has been discussed. If not, the security source field MUST be present. Requires coordination with the Bundle Protocol Spec. [Comment.17] Editors: Note that we are defining a new Confidentiality Header and its type has to be added to Table 1 of the Bundle Protocol. [Comment.18] Editors: Note that we are defining a new Confidentiality Header and its type has to be added to Table 1 of the Bundle Protocol. [Comment.19] Howie: It may be nice to be able to signal both confidentiality and authentication using only one header instead of using two separate headers (PSH and CH). [Comment.20] Editors: As you can see - this is TBD! [Comment.21] Editors: Not sure if paralleling the bundle spec. will be a good or bad idea - it might be simpler to just do our own thing here. I guess we'll see. [Comment.22] Editors: ...but is still mainly tbd [Comment.23] Editors: These instruction for canonicalisation may not be exactly correct, but we think they're on the right track. [Comment.24] Susan: What drives the inclusion of a CH (or PSH) security destination in the CH (or PSH), and where does this value come from? Is it security-policy driven? Should there be a parameter in the Send.Request service primitive to enable the bundle node to specify these security destinations, if desired? [Comment.25] Susan: We will eventually want to say more about possibly providing confidentiality for some bundle header fields in addition to simply providing payload confidentiality. [Comment.26] Howie: The security policy database will need to be discussed somewhere. Does it belong in this document, the bundle protocol spec., both, some other document? [Comment.27] Editors: The paragraph below should be elsewhere; unfortunately it isn't anywhere else yet, because it was a security discussion that brought up the need for Symington, et al. Expires November 25, 2005 [Page 34] =0C Internet-Draft Bundle Security Protocol May 2005 a "sender" field. This field has not yet made it into the Bundle protocol. We must coordinate with the Bundle Protocol spec authors to insert this text into the Bundle Protocol. I have it here for now so it is at least somewhere. [Comment.28] Editors: These are initial thoughts and may be wrong, or changed! [Comment.29] Editors: These are really placeholders; very sketchy at this point. [Comment.30] Add DSS, with variations for entire bundle, head of bundle... (should use of DSS be the default? Over entire bundle or just front?) [Comment.31] Editors: this one is more efficient if we're not pkcs1v1.5 compliant. [Comment.32] Editors: we need another name, or else have to explain what TP expands to...:-) [Comment.33] This explanation needs to be more detailed, saying exactly what parts of the canonical form of the bundle each authenticator is calculated over. [Comment.34] Editors: It isn't clear what entity decides the size of the payload segments and breaks the payload into these segments--the source bundle node or the source bundle protocol agent? If the source bundle node, why doesn't it just send each of these segments as separate bundles? if the source bundle node, then wouldn't the send.Request primitive need to be modified to enable the segment size to be specified? If the bundle protocol agent decides the segment size, on what does it base this decision? [Comment.35] Howie: Should the TP segments sizes be fixed or random (smaller than some maximum)? If they are fixed, what compelling argument is there that any of them will get through? If they are random in size (and we define a TLV format for conveying the appropriate information) then maybe something will get through. [Comment.36] Editors: this still needs to be defined in the Bundle Protocol. [Comment.37] Howie: Eventually we will need to state where the Symington, et al. Expires November 25, 2005 [Page 35] =0C Internet-Draft Bundle Security Protocol May 2005 security policy information/DB does get discussed/specified. Authors' Addresses Susan Flynn Symington The MITRE Corporation 7515 Colshire Drive McLean, VA 22102 US Phone: +1 (703) 983-7209 Email: susan@mitre.org URI: http://mitre.org/ Stephen Farrell Trinity College Dublin Distributed Systems Group Department of Computer Science Trinity College Dublin Ireland Phone: +353-1-608-1539 Email: stephen.farrell@cs.tcd.ie Howard Weiss SPARTA, Inc. 7075 Samuel Morse Drive Columbia, MD 21046 US Phone: +1-410-872-1515 x201 Email: hsw@sparta.com Symington, et al. Expires November 25, 2005 [Page 36] =0C Internet-Draft Bundle Security Protocol May 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP 11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2005). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Symington, et al. Expires November 25, 2005 [Page 37] =0C Internet-Draft Bundle Security Protocol May 2005 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Symington, et al. Expires November 25, 2005 [Page 38] =0C ------=_NextPart_000_012C_01C56070.88C0FD80--