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, 1 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