[dtn-security] Re: Bundle Security Protocol details

["Peter Lovell" <[e-mail]>]

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