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

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

Received: from imx2.tcd.ie (imx2.tcd.ie [134.226.1.156]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id kAHCVEY16941 for <dtn-security@mailman.dtnrg.org>; Fri, 17 Nov 2006 04:31:14 -0800
Received: from Vams.imx2 (imx2.tcd.ie [134.226.1.156]) by imx2.tcd.ie (Postfix) with SMTP id 6049D680F2; Fri, 17 Nov 2006 12:31:08 +0000 (GMT)
Received: from imx2.tcd.ie ([134.226.1.156]) by imx2.tcd.ie ([134.226.1.156]) with SMTP (gateway) id A07CFB5BC62; Fri, 17 Nov 2006 12:31:08 +0000
Received: from [127.0.0.1] (unknown [134.226.144.16]) by imx2.tcd.ie (Postfix) with ESMTP id 575D4680F2; Fri, 17 Nov 2006 12:31:08 +0000 (GMT)
Message-ID: <455DABC2.6050200@cs.tcd.ie>
Date: Fri, 17 Nov 2006 12:32:02 +0000
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Thunderbird 1.5.0.8 (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: <8E507634779E22488719233DB3DF9FF0012295D9@IMCSRV4.MITRE.ORG>
In-Reply-To: <8E507634779E22488719233DB3DF9FF0012295D9@IMCSRV4.MITRE.ORG>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-AntiVirus-Status: MessageID = A17CFB5BC62
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:
> 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.