[dtn-security] RE: Bundle Security Protocol: one more item

["Symington, Susan F." <[e-mail]>]

The point of the bit is to indicate that the bundle passed through a
node that doesn't support the block, and that node that doesn't support
the block didn't delete the block (obviously) or delete the bundle
(obviously).

It first came up when we were trying to define a block that essentially
accumulated the EIDs of all the nodes that the bundle passed through.
We wanted a way to know that the bundle had passed through some nodes
that didn't add their EIDs to the accumulating path log (because the
nodes didn't support the optional block). 

Now that I think about it, there may be more to consider with regard to
how this bit works in relation to the security blocks.  It is all bound
up in the issue of how security works if some nodes don't support it.

Suppose for example there are nodes 1, 2, and 3 and only nodes 1 and 3
implement the Bundle Security Protocol. This means that if node 1
inserts a BAB and forwards the bundle to node 2, and node 2 doesn't
understand the BAB and isn't configured to delete the BAB or delete the
bundle, then node 2 will forward the bundle to node 3 with this "block
was forwarde without being processed" bit set in the BAB. When node 3
receives the bundle and tries to authenticate the security result in
the BAB, it won't authenticate (because of this bit change). This may
be okay for the BAB, but it would work the same for the PSH and I'm not
sure that's okay.  

If node 1 is a PSH-source, node 2 doesn't understand the PSH and node 3
is a PSH-dest, then if node 2 forwards the bundle with this bit set in
the PSH, then I think we either have to specify that this bit must be
reset by a node before the node validates the security result in the
PSH or that this bit must be masked out so that it is omitted from the
mutable canonicalization form of the bundle. (same for CH I think.)

Assuming this is true, does anyone have a preference for whether we
should mandate that nodes processing the PSH reset this bit before
calculating the security result or whether we should just leave this
bit out of the mutable canoncial form?

Any other thoughts?

-susan
*****************************************************************
Susan Symington
The MITRE Corporation
[e-mail]
703-983-7209 (voice)
703-983-7142 (fax)
******************************************************************
 

>-----Original Message-----
>From: Stephen Farrell [mailto:[e-mail]] 
>Sent: Friday, November 17, 2006 7:32 AM
>To: Symington, Susan F.
>Cc: Peter Lovell; Howard Weiss; [e-mail]
>Subject: Re: Bundle Security Protocol: one more item
>
>
>
>Symington, Susan F. wrote:
>> Security pundits:
>>  
>> One more item that I would like to address in the next 
>revision of the 
>> Bundle Security Protocol:
>>  
>> Currently, section 3.7 of the Bundle Protocol says the following:
>>  
>> "Whenever a bundle is forwarded that contains one or more extension
>>    blocks that could not be processed, the "Block was 
>forwarded without
>>    being processed" flag must be set to 1 within the block
processing
>>    flags of each such block.  For each block flagged in this way,
the
>>    flag may optionally be cleared (i.e., set to zero) by another
node
>>    that subsequently receives the bundle and is able to process that
>>    block; the specifications defining the various extension 
>blocks are
>>    expected to define the circumstances under which this flag may be
>>    cleared, if any. "
>>  
>>  
>> This means that in the Bundle Security Protocol we need to 
>define the 
>> circumstances under
>> which the "Block was forwarded without being processed" flag may be 
>> cleared, if any.
>>  
>> Anyone care to take a stab at this?
>
>If you decrypt then you'll be deleting blocks anyway so I think
>that'd be ok. Any such bit will disappear (a good thing IMO).
>
>BAB is irrelevant here I hope since they don't get forwarded.
>
>So that leaves the PSB and our one mandatory ciphersuite.
>
>If you successfully verify a signature, but don't remove the
>PSB, I'd say leave the bit alone and forward whatever you
>got.
>
>The reason being that it'd be bogus to have a flag that says
>"someone once verified a signature here" with no further
>details. Subsequent nodes can all verify the signature
>if they so choose (with this ciphersuite), since verification
>is sort-of idempotent if you know what I mean.
>
>In future, someone may want to define a brand new "security
>result analysis" block that might say "bob checked alice's signature
>yesterday and it was ok then, including a check with charlie's
>OSCP repsonder for alice's cert serial #1234 issued by dave's
>CA and bob also generated an evidence token for alice's signature
>(using eddy for trusted time) and lodged that with fred." Doing
>that sensibly requires more than one bit, and really requires
>that bob add his own PSB as well, so we don't want the "processed"
>flag to be mistakenly used as a "signature is good" signal.
>
>Or, I could agree to setting the bit to a random value (a generic
>way to remove meaning:-).
>
>[As an aside - what is that bit good for anyway?]
>
>Stephen.
>
>
>