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

"Symington, Susan F." <susan@mitre.org> Fri, 17 November 2006 15:54 UTC

Received: from smtp-bedford.mitre.org (smtpproxy1.mitre.org [192.160.51.76]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id kAHFsFY18283 for <dtn-security@mailman.dtnrg.org>; Fri, 17 Nov 2006 07:54:16 -0800
Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.12.11.20060308/8.12.11) with SMTP id kAHFsFAw005464 for <dtn-security@mailman.dtnrg.org>; Fri, 17 Nov 2006 10:54:15 -0500
Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (Postfix) with ESMTP id 189C5BF7C for <dtn-security@mailman.dtnrg.org>; Fri, 17 Nov 2006 10:54:15 -0500 (EST)
Received: from IMCFE1.MITRE.ORG (imcfe1.mitre.org [129.83.29.3]) by smtp-bedford.mitre.org (8.12.11.20060308/8.12.11) with ESMTP id kAHFsEeN005448; Fri, 17 Nov 2006 10:54:14 -0500
Received: from IMCSRV4.MITRE.ORG ([129.83.20.161]) by IMCFE1.MITRE.ORG with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Nov 2006 10:54:14 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 17 Nov 2006 10:54:12 -0500
Message-ID: <8E507634779E22488719233DB3DF9FF001229708@IMCSRV4.MITRE.ORG>
In-Reply-To: <455DD9E9.1050006@cs.tcd.ie>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Bundle Security Protocol: one more item
Thread-Index: AccKX8XXA34frHP3RfacprBsIUJdgAAAHRnw
From: "Symington, Susan F." <susan@mitre.org>
To: "Stephen Farrell" <stephen.farrell@cs.tcd.ie>
Cc: "Peter Lovell" <peter.lovell@sparta.com>, "Howard Weiss" <howard.weiss@sparta.com>, <dtn-security@mailman.dtnrg.org>
X-OriginalArrivalTime: 17 Nov 2006 15:54:14.0241 (UTC) FILETIME=[A1491D10:01C70A60]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by webbie.berkeley.intel-research.net id kAHFsFY18283
Subject: [dtn-security] RE: Bundle Security Protocol: one more item
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/>

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
susan@mitre.org
703-983-7209 (voice)
703-983-7142 (fax)
******************************************************************
 

>-----Original Message-----
>From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] 
>Sent: Friday, November 17, 2006 10:49 AM
>To: Symington, Susan F.
>Cc: Peter Lovell; Howard Weiss; dtn-security@mailman.dtnrg.org
>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.
>
>