RE: [dtn-security] 00 version of the Bundle Security Protocol Spec.
"Susan F. Symington" <susan@mitre.org> Wed, 01 June 2005 14:52 UTC
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 j51Eq5V07443 for <dtn-security@mailman.dtnrg.org>; Wed, 1 Jun 2005 07:52:05 -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 j51Eq4O19916 for <dtn-security@mailman.dtnrg.org>; Wed, 1 Jun 2005 10:52:04 -0400
Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (Postfix) with ESMTP id 659F1BF7C for <dtn-security@mailman.dtnrg.org>; Wed, 1 Jun 2005 10:52:04 -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 j51Eq1W19612; Wed, 1 Jun 2005 10:52:01 -0400
Message-Id: <200506011452.j51Eq1W19612@smtp-bedford.mitre.org>
Received: from mm122433-pc.mitre.org (128.29.14.10) by mailhub1.mitre.org with SMTP id 18087357; Wed, 01 Jun 2005 10:51:59 -0400
From: "Susan F. Symington" <susan@mitre.org>
To: dtn-security@mailman.dtnrg.org
Cc: 'Howard Weiss' <howard.weiss@sparta.com>, 'Stephen Farrell' <stephen.farrell@cs.tcd.ie>, "'Susan F. Symington'" <susan@mitre.org>
Subject: RE: [dtn-security] 00 version of the Bundle Security Protocol Spec.
Date: Wed, 01 Jun 2005 10:51:55 -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: AcVmCb2AhkZX95MqRDSH71NzztUD9QAB66XQ
In-reply-to: <429CA44A.4000405@jpl.nasa.gov>
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/>
Scott: Some replies (below). -susan >-----Original Message----- >From: dtn-security-admin@mailman.dtnrg.org >[mailto:dtn-security-admin@mailman.dtnrg.org] On Behalf Of >Scott Burleigh >Sent: Tuesday, May 31, 2005 1:52 PM >To: dtn-security@mailman.dtnrg.org >Cc: 'Howard Weiss'; 'Stephen Farrell' >Subject: Re: [dtn-security] 00 version of the Bundle Security >Protocol Spec. > >Susan F. Symington wrote: > [...] >> -- 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. > I agree that the extension headers should be documented and explained in the security spec, but how are we going to make sure that whatever type value is assigned to these headers doesn't conflict with a type chosen for use in the bundle protocol or for use in another extension header? I was envisioning us placing the header types that we know of in a table in the Bundle Protocol so when folks make up new headers, they would be aware of which types are already reserved for use. If we don't have a master list of header types somewhere, then we at least need a master list of documents that contain all header types. > >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." This works for me but only if the BP spec is not a moving target. If its paragraph numberings are going to be in flux, then this will be a royal pain in the neck. At this point I'd like to keep our spec as is until we are sure the BP spec has settled. [...] >> - 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. > I see the merits of what you are proposing and I agree, but I'm not too clear on how it will work in practice at the API level given that there will be many different possible parameter lists that could be expected with a given send.request or data.indication primitive, depending on what combination of extension headers is in use. As the number of extension headers and extension protocols multiply, so does the number of possible different send.request primitive parameter combinations. Some document will have to tie these combinations together. >> - 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. If folks want it in the BAH that's fine with me, but I seem to recall from previous meetings that there was consensus that the sender information is useful for more than just security and should be in the primary bundle header. Debugging was one example of why it would be useful, I believe. I don't have any problem putting the sender field in the BAH, but before we do folks should think about whether they would want to know the sender even in cases in which security is not in use. [...] >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. Do you mean that the terminology in the Bundle Security Protocol spec is messed up? I actually went through and changed it according to our decisions of two weeks ago. I intended for it to be in conformance with what we decided at Berkeley, so I would appreciate specific examples of where you think the terminology isn't correct. > >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? Whether or not the CH remains in the bundle after decryption by the CH security destination is something that can be determined by security policy. We wanted to leave the option open to be able to keep it in if needed. Same with the PSH, though often it will be left in after checking because if a public key scheme is used to create the authenticator, many different hops along the way may be capable of checking the PSH value, so it would make sense to leave it in. > >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. I suppose it could be used to protect routers from replays that are destined specifically toward the router, but not from replays of bundles that the router is forwarding on to another destination. > >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? As Stephen's email indicated, we can code the security result as two separate fields: length, value, so there is no security-related need to be able to accommodate the very large lengths with the above SDNV. This sounds like a good idea to me. > >5. In section 3.4, a minor typo: in the first paragraph you >say PSH when >you mean CH. Thanks! > >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.) Is this just a terminology issue? I didn't think that "canonical form" meant strictly the on-the-wire-format. What we are trying to define is the form of the bundle that will be used to calculate the PSH. > >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. I don't recall either. > >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. Thanks. I think what needs to be done in this situation needs to be fixed and made clearer. The replayed bundle MUST be forwarded to nodes that have registered without the "at most once" option but MUST NOT be forwarded to nodes that have registered with the "at most once" option. > >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. Probably a good idea. Again, though, the question arises as to how/where the codes are partitioned among the protocol extensions so that a single code isn't used to mean two different things. [...] -susan
- 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