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

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

I don't understand the replay threat. What do you mean by, "It means an
attacker could force
the processing of blocks in PSB's bundles and could replay those"?

I agree that we need to put in a statement saying that this bit should
be masked in the PSB and CB (what about the BAB?) so that it is omitted
from the mutable canonical form.  I don't believe that this bit should
be masked in the primary bundle block, since every node is required to
be able to process this block.

-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 10:49 AM
>To: Symington, Susan F.
>Cc: Peter Lovell; Howard Weiss; [e-mail]
>Subject: Re: Bundle Security Protocol: one more item
>
>
>
>Symington, Susan F. wrote:
>> 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 the BAB verifies in that case, then something is quite weird.
>If the BAB fails, then the bundle's toast so this bit is irrelevant.
>
>> 
>> 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?
>
>Ignore the bit for c14n purposes. Easy.
>
>Ok, that doesn't quite work though. It means an attacker could force
>the processing of blocks in PSB's bundles and could replay those. So
>it has to be an input to digesting in the PSB. OTOH, this silly bit
>is supposed to be modified en-route, so it has to be mutable. Bummer.
>
>So, in the end, we have to ignore the bit for c14n purposes.
>
>We can (and MUST) certainly ignore the bit for security processing
>purposes.
>
>There should be a security consideration saying that this kind of
>replay can happen and why we have to live with that.
>
>Stephen.
>
>