[dtn-security] Re: Bundle Security Protocol items for discussion

[Stephen Farrell <[e-mail]>]

Susan,

A bit late but I want to come back to a bit of this.

Symington, Susan F. wrote:
> Stephen and Howie,
>  
> The following are Items we need to discuss wrt the bundle security 
> protocol that were brought up by BBN:
>  
> 1. If a bundle includes a previous hop insertion block (defined in its 
> own internet draft) with an EID-only or EID-with-Timestamp-formatted 
> information record, then this means that the bundle already includes the 
> EID of its previous hop (in its dictionary), with pointers to this 
> previous hop EID (in its previous-hop insertion block). In this case, it 
> would be redundant to include the EID of the previous hop in the 
> security-source field of the BAB. Therefore, I propose that we no longer 
> make inclusion of the security-source field mandatory in the BAB. It 
> should be optional. If the security-source field is not present, 
> however, and the EID of the previous hop cannot be inferred from some 
> other part of the bundle, then processing of the BAB shall fail. The 
> proposed text would say, "If the forwarder of the bundle is not 
> identified in any other blocks of the bundle (e.g. the optional 
> Previous-hop insertion block), then the security-source field MUST be 
> present and MUST identify the forwarder of the bundle."

I don't think that works. If the BAB doesn't include the source but
the next hop doesn't support the other block that has the info, then
the BAB check will probably fail.

I could accept something like the source SHOULD NOT be omitted unless
the node "knows" the BAB needn't contain it (due to it being elsewhere
in the block or from lower layer information or whatever).

A better way is to say that the BAB SHOULD contain the source.

> 2. Under the "Notes" section of 3.2.2, it says, "URI encoding will be a 
> cause for errors if any node rewrites the dectionary...we simple hae to 
> live with this problem".  BBN wonders why we can't just put in a 
> statement like, "A node SHOULD NOT change the encoding of any URI in the 
> dictionary field (elg. changing the DNS part of some HTTP URL from lower 
> case to upper case)."  I don't understand the problem sufficiently be 
> able to respond on this.

The problem is that this usually happens transparently when the bundle
is synched to disk using s/w 'A' and then read from disk and forwarded
by s/w 'B' and they do different things with upper/lower case (or things
like "%20" vs " " etc).

So, no harm to say this, but its probably an unavoidable source of
integrity failures. If we can provide some test vectors that'd
help - can we Pete?

> 3. In section 3.4, Bundles received from other nodes, 5th paragraph, it 
> says that "...the node MUST decrypt the relevant parts of the bundle 
> according to the ciphersuite specification and delete the CH in 
> question."  BBN wants to know what to do if decryption fails.  I propose 
> we add a sentence here that says, "If the relevant parts of the bundle 
> cannot be decrypted (i.e., the decription key cannot be deduced or 
> decryption fails), the behavior of the bundle protocol agent will be as 
> specified in the CB Block Processing Flags, unless overridden by the 
> local security policy." Is this okay with you?

Sure. (What's the CB Block Processing Flags say?)

> 4. If the CH-RSA-AES-PAYLOAD-PSH ciphersuite is used, the first CH must 
> have a ciphersuite parameter that contains a 16-byte IV, optionally 
> followed by a key identifier. Is it true that the way we tell whether or 
> not there is only an IV versus an IV followed by a key ID is by the 
> length specified in the ciphersuite parameters SDNV?  If this SDNV shows 
> the ciphersuite parameters field to be 16 bytes long, then we know only 
> an IV is included.  If this SDNV shows the ciphersuite parameters field 
> to be longer than 16 bytes, then we know that both an IV and a key ID is 
> included, and the length of the key ID is the length shown in the SDNV 
> minus 16 bytes. Is this correct?  If so, BBN was unsure of it so we 
> should probably explicitly say this in the spec.

All correct. Good to spell it out (as long as we don't use too many
words:-)

> 5. To be sure I am correct, in the CH-RSA-AES-PAYLOAD-PSH ciphersuite 
> definition, the input to the KDF is the BEK catenated wtih the IV from 
> the ciphersuite parameter of the first CH, right?  (BBN was unclear on 
> whether there is a single IV in the first CH or whether each CH includes 
> an IV).  It is my understanding that there is a single IV in the first 
> CH. Subsequent CHs do not contain any of the optional fields (such as 
> ciphersuite parameters) that are included in the first CH.  Is my 
> understanding correct?

Think so. Would be happy to change this kind of stuff for either
implementation reasons or because someone's security analysis shows
a reason. (And I'd also still like to start using a counter mode.)

S.