[dtn-security] Re: Bundle Security Protocol details

Stephen Farrell <stephen.farrell@cs.tcd.ie> Fri, 17 November 2006 12:19 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 kAHCJFY16848 for <dtn-security@mailman.dtnrg.org>; Fri, 17 Nov 2006 04:19:15 -0800
Received: from Vams.imx2 (imx2.tcd.ie [134.226.1.156]) by imx2.tcd.ie (Postfix) with SMTP id 88523680E4; Fri, 17 Nov 2006 12:19:09 +0000 (GMT)
Received: from imx2.tcd.ie ([134.226.1.156]) by imx2.tcd.ie ([134.226.1.156]) with SMTP (gateway) id A074127ADDD; Fri, 17 Nov 2006 12:19:09 +0000
Received: from [127.0.0.1] (unknown [134.226.144.16]) by imx2.tcd.ie (Postfix) with ESMTP id 5FEBA680E4; Fri, 17 Nov 2006 12:19:09 +0000 (GMT)
Message-ID: <455DA8F3.9020603@cs.tcd.ie>
Date: Fri, 17 Nov 2006 12:20:03 +0000
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Thunderbird 1.5.0.8 (Windows/20061025)
MIME-Version: 1.0
To: Peter Lovell <peter.lovell@sparta.com>
Cc: Susan <susan@mitre.org>, hsw <hsw@sparta.com>, dtn-security@mailman.dtnrg.org
References: <20061115001449.1919806739@127.0.0.1> <8E507634779E22488719233DB3DF9FF0012295BA@IMCSRV4.MITRE.ORG> <20061117000457.309686795@127.0.0.1>
In-Reply-To: <20061117000457.309686795@127.0.0.1>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-AntiVirus-Status: MessageID = A174127ADDD
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 details
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/>

Hi Pete,

I'd be happy with everything that Susan wrote.

I also agree with you that the result-length & result are to be
kept together in the same block. We should say that.

You seem to be implying that there may be ciphersuites where
you don't know the result length in advance, is that right?
I'm not aware of any such ciphersuite as it happens. Are you?

If not, then I think its fine to assume that the length is
known before digesting (the c14n & digest fnc. are specified
by the ciphersuite, so you've been to that code already).

S.

Peter Lovell wrote:
> Hi Susan,
> 
>> I am in the process of making the changes to the Bundle Security
>> Protocol based on the comments that BBN had in their requirements
>> document and also on the suggestion below by Peter Lovell. 
>>
>> In actually making the edits with regard to Peter's suggestion (below),
>> I was forced to look at this more carefully and in so doing I realized
>> that my understanding of the spec seems to differ a little from the
>> assertions made in Peter's suggestion, so I would like to get a few
>> details clarified and make sure we all agree on the following:
>>
>> 1. The notes on canonicalization say that the security result is to be
>> omitted. These notes do not say (or mean to imply) that the security
>> result length field is to be omitted. In fact, the security result
>> length field and its value is to be included in the calculation of the
>> BAB security result. We want the BAB security result to be calculated
>> over the entire bundle exactly as it appears, with all its fields and
>> their values except for the security result field.
> 
> I had been regarding the term "security result" field as a general
> reference to length+data. The description though does name them separately.
> 
> However, in several places the language seems to suggest that length
> +data are closely related and are to be regarded as a compound field.
> For example, the "res" bit (bit 11) says that it "...indicates whether
> or not the ASH contains security result length and security result fields." 
> 
> What happens then for a two-part block scenario? The description at the
> bottom of page 10 says that the security result must be absent from the
> first block, and must be in the second block. Where is the security-
> result-length? In the first block, or does it precede the security
> result data in the second block? And is the "res" flag set in the first
> block if it contains length but not the data?
> 
> My interpretation is that the source, destination and security are
> compound fields, as suggested by having a single bit for each. As such,
> security-result-length and security-result would both be in the first
> block (res bit set) or both be in the second (res bit off).
> 
> In addition, there is no requirement that the security-result-length be
> known in advance. Of course, in many cases it will be but I'm not aware
> that it is required to be. 
> 
> If the security-result-length is included in the canonicalization then
> it must be fixed before any digesting begins. If it is not fixed, then
> canonicalization must exclude the security result data (as it already
> does), the security result length (because it is not known, nor is its
> size known since it's SDNV) and the block-length field must be adjusted
> to exclude the size for these two.
> 
> If we digest the length field than it can't ever be variable-length.
> 
> 
>> 2. The new "security result offset" field that is being suggested
>> should indicte the offset of the start of the security result field
>> (not of the security result length field).
> 
> This depends upon what we decide for the previous item.
> 
> However, having it point to the length field is slightly nicer. If it
> does, we can find the length and process the data. But if it points to
> the data, we cannot discover the length except by walking through the
> block. Not a big deal either way.
> 
> 
>> 3. We should add an additional canonicalization note to say that the
>> new security result offset field (like the "res" bit of the ciphersuite
>> ID) is part of the canonical form. In other words, when the BAB is
>> calculated on the bundle, the res field will have a value of 1 and the
>> security result offset field will have its correct offset value.
> 
> I assume that res would be 1 in a single-block scenario, and 0 if the
> result is in a trailer block.
> 
> 
>> 4. Similarly, the value of the block data length field should be the
>> length of the entire bundle, including the security result field. It
>> should not change to subtract the length of the security result field
>> when we calculate the security result, even though we won't calculate
>> the security result over the security result field.
> 
> Depends upon whether or not the security-result-length is fixed
> 
> Cheers.....Peter
>