[dtn-security] RE: Bundle Security Protocol details

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

Peter,

My responses are inline. Thanks for your attention to this.

-susan

*****************************************************************
Susan Symington
The MITRE Corporation
[e-mail]
703-983-7209 (voice)
703-983-7142 (fax)
******************************************************************
 

>-----Original Message-----
>From: Peter Lovell [mailto:[e-mail]] 
>Sent: Thursday, November 16, 2006 7:05 PM
>To: Symington, Susan F.; Stephen Farrell
>Cc: hsw; [e-mail]
>Subject: Re: Bundle Security Protocol details
>
>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?

Good point.  We need to clarify this.

>
>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).

Yes, I agree.


>
>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. 

Well I've been assuming it is always known in advance. Is this an
invalid assumption?


>
>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.
>

Why can't it be variable length?  I guess it depends on what you mean
by variable length.
As long as the length of the security result can be known before it is
calculated, the length can be any value.

The key issue seems to be the assumption that the security result
length will be known before it is calculated. Is this a bad assumption?


>
>>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.

Yes. You are right. My example was imprecise in that it took into
account only the 1-block case.

>
>
>>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
>
>