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

Stephen Farrell <stephen.farrell@cs.tcd.ie> Fri, 17 November 2006 15:48 UTC

Received: from imx2.tcd.ie (wpad.iss.tcd.ie []) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id kAHFm9Y18222 for <dtn-security@mailman.dtnrg.org>; Fri, 17 Nov 2006 07:48:09 -0800
Received: from Vams.imx2 (imx2.tcd.ie []) by imx2.tcd.ie (Postfix) with SMTP id 983FE68284; Fri, 17 Nov 2006 15:48:03 +0000 (GMT)
Received: from imx2.tcd.ie ([]) by imx2.tcd.ie ([]) with SMTP (gateway) id A07EC394C51; Fri, 17 Nov 2006 15:48:03 +0000
Received: from [] (cswireless62-182.cs.tcd.ie []) by imx2.tcd.ie (Postfix) with ESMTP id 8F95368284; Fri, 17 Nov 2006 15:48:03 +0000 (GMT)
Message-ID: <455DD9E9.1050006@cs.tcd.ie>
Date: Fri, 17 Nov 2006 15:48:57 +0000
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Thunderbird (Windows/20061025)
MIME-Version: 1.0
To: "Symington, Susan F." <susan@mitre.org>
Cc: Peter Lovell <peter.lovell@sparta.com>, Howard Weiss <howard.weiss@sparta.com>, dtn-security@mailman.dtnrg.org
References: <8E507634779E22488719233DB3DF9FF0012296F0@IMCSRV4.MITRE.ORG>
In-Reply-To: <8E507634779E22488719233DB3DF9FF0012296F0@IMCSRV4.MITRE.ORG>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-AntiVirus-Status: MessageID = A17EC394C51
X-AntiVirus-Status: Host: imx2.tcd.ie
X-AntiVirus-Status: Action Taken:
X-AntiVirus-Status: NONE
X-AntiVirus-Status: Checked by TCD Vexira. (version=1.56.3 VDF=8.1400)
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/>

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

There should be a security consideration saying that this kind of
replay can happen and why we have to live with that.