Re: [dtn-security] 00 version of the Bundle Security Protocol Spec.
Scott Burleigh <Scott.Burleigh@jpl.nasa.gov> Tue, 31 May 2005 17:52 UTC
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 <dtn-security@mailman.dtnrg.org>; 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 <Scott.Burleigh@jpl.nasa.gov>
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' <howard.weiss@sparta.com>, 'Stephen Farrell' <stephen.farrell@cs.tcd.ie>
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: <http://mailman.dtnrg.org/mailman/listinfo/dtn-security>, <mailto:dtn-security-request@mailman.dtnrg.org?subject=unsubscribe>
List-Id: DTN Security Discussion <dtn-security.mailman.dtnrg.org>
List-Post: <mailto:dtn-security@mailman.dtnrg.org>
List-Help: <mailto:dtn-security-request@mailman.dtnrg.org?subject=help>
List-Subscribe: <http://mailman.dtnrg.org/mailman/listinfo/dtn-security>, <mailto:dtn-security-request@mailman.dtnrg.org?subject=subscribe>
List-Archive: <http://mailman.dtnrg.org/pipermail/dtn-security/>
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
- Re: [dtn-security] Re: [dtn-dev] Re: SDNV-new Scott Burleigh
- Re: [dtn-security] Re: [dtn-dev] Re: SDNV-new Michael Demmer
- Re: [dtn-security] Re: [dtn-dev] Re: SDNV-new Rajesh Krishnan
- Re: [dtn-security] Re: [dtn-dev] Re: SDNV-new Scott Burleigh
- Re: [dtn-security] 00 version of the Bundle Secur… Scott Burleigh
- Re: [dtn-security] Re: [dtn-dev] Re: SDNV-new Michael Demmer
- Re: [dtn-security] Re: [dtn-dev] Re: SDNV-new Howard Weiss
- Re: [dtn-security] Re: [dtn-dev] Re: SDNV-new Rajesh Krishnan
- Re: [dtn-security] Re: [dtn-dev] Re: SDNV-new Scott Burleigh
- Re: [dtn-security] Re: [dtn-dev] Re: SDNV-new Michael Demmer
- Re: are offsets enough? --was: (dictionary or not… Michael Demmer
- Re: [dtn-security] Re: [dtn-dev] Re: SDNV-new Michael Demmer
- [dtn-security] Re: [dtn-dev] Re: SDNV-new Scott Burleigh
- I18N (was: Re: (dictionary or not) Re: [dtn-secur… Stephen Farrell
- [dtn-security] Re: are offsets enough? --was: (di… Stephen Farrell
- Re: [dtn-security] Re: [dtn-dev] Re: SDNV-new Stephen Farrell
- [dtn-security] Re: [dtn-dev] Re: SDNV-new Michael Demmer
- RE:are offsets enough? --was: (dictionary or not)… Susan F. Symington
- Re: [dtn-dev] Re: [dtn-security] 00 version of th… Michael Demmer
- [dtn-security] Re: [dtn-dev] Re: SDNV-new Michael Demmer
- Re: (dictionary or not) Re: [dtn-security] 00 ver… Scott Burleigh
- [dtn-security] Re: [dtn-dev] Re: SDNV-new Scott Burleigh
- Re: [dtn-dev] Re: [dtn-security] 00 version of th… Scott Burleigh
- Re: (dictionary or not) Re: [dtn-security] 00 ver… Michael Demmer
- Re: SDNV-new (was: Re: [dtn-security] 00 version … Michael Demmer
- Re: [dtn-security] 00 version of the Bundle Secur… Wesley Eddy
- SDNV-new (was: Re: [dtn-security] 00 version of t… Stephen Farrell
- Re: (dictionary or not) Re: [dtn-security] 00 ver… Stephen Farrell
- Re: (dictionary or not) Re: [dtn-security] 00 ver… Michael Demmer
- RE: [dtn-security] 00 version of the Bundle Secur… Susan F. Symington
- (dictionary or not) Re: [dtn-security] 00 version… Stephen Farrell
- Re: [dtn-security] 00 version of the Bundle Secur… Michael Demmer
- Re: [dtn-security] 00 version of the Bundle Secur… Michael Demmer
- Re: [dtn-security] 00 version of the Bundle Secur… Stephen Farrell
- [dtn-security] 00 version of the Bundle Security … Susan F. Symington
- Re: [dtn-security] Re: SDNV-new : OK Stephen Farrell
- Re: [dtn-security] 00 version of the Bundle Secur… Stephen Farrell
- [dtn-security] Re: SDNV-new : OK Manikantan Ramadas
- Re: [dtn-security] 00 version of the Bundle Secur… Howard Weiss
- Re: [dtn-security] 00 version of the Bundle Secur… Scott Burleigh
- Re: [dtn-security] Re: [dtn-dev] Re: SDNV-new Manikantan Ramadas
- RE: [dtn-security] 00 version of the Bundle Secur… Susan F. Symington
- Re: [dtn-security] Re: [dtn-dev] Re: SDNV-new stephen.farrell
- Re: [dtn-security] meeting at IETF? Kevin Fall
- [dtn-security] meeting at IETF? Sandra Murphy