[dtn-security] Bundle Security Protocol details

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

Stephen, Peter, and Howie:

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.

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

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.

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.

In summary, we don't want to change the values of any fields of the
bundle. We want the security result calculated over all the fields as
they are, with the one exception that the security result field is
omitted. 

Do we all agree on 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: Tuesday, November 14, 2006 7:15 PM
>To: Symington, Susan F.; Stephen Farrell; Scott Burleigh
>Cc: hsw; Peter Lovell; Michael Demmer; DTNRG
>Subject: discussion items
>
>
>
>Format of security blocks (ASB)
>-------------------------------
>
>There's an open question about one item with strict canonicalization,
>which was discussed on email last week. It woulld be helpful to look
at
>security spec section 3.2.1 [page 17] and the general diagram Figure 2
>on page 8.
>
>The question is what value to use for the header (block) data length
>field "len".
>
>The notes on canonicalization say that the security result 
>(data and its
>length field) is to be omitted, but don't say what value to 
>use for "len". 
>
>I suspect that it should be the length the block would be if the
>security result were omitted, that is, size of the block less the size
>of the security result and the size of the security result size field
>itself (SDNV).
>
>The second part of the issue is that it's hard to arrive at that value
>-- you have to slog your way through all the fields one by one. 
>
>Stephen has suggested two changes to help here ...
>1. change the "params" field to be param-length (SDNV) followed by 
>   param-data (that many octets). 
>   
>2. add a "security offset" field immediately after the 
>ciphersuite field. 
>   This is an optional SDNV, present only if the "res" bit is 
>set indicating 
>   that a security-result field is present in this block. The 
>value in the
>   field is the offset of the start of the "res-len" field 
>relative to the 
>   start of the block.
>   
>
>I propose that we make these two changes, and define the "len" field
>more closely.
>