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

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

Security authors and pundits,
 
Thanks for your input in the past few days. It is helping to improve
the spec.
 
As far as I can tell, below are the only remaining items that we need
to resolve before we can wrap up this next revision of the Bundle
Security Protocol. I would appreciate receiving your input on these
issues. Once I roll in whatever revisions these generate, I will
circulate version 3 of the Bundle Security Protocol for your review.
 
Thanks.
 
-susan
 
*****************************************************************
Susan Symington
The MITRE Corporation
[e-mail]
703-983-7209 (voice)
703-983-7142 (fax)
******************************************************************
 


________________________________

	From: Symington, Susan F. 
	Sent: Monday, November 13, 2006 3:39 PM
	To: Stephen Farrell; 'Howard Weiss'
	Cc: Symington, Susan F.
	Subject: Bundle Security Protocol items for discussion
	
	
	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." 
	 
	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.
	 
	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?
	 
	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.
	[Susan] Now that we have redefined the format of the Abstrace
Security Block such that the parameters field morphed into a  compound
field (parameters-length field and  parameters data field), I propose
that we specify in teh CH-RSA_AES-PAYLOAD-PSH ciphersuite that if the
parameters-length field has a value equal to 16, then the parameters
data field consists of only a 16-bye IV. If the parameters-length field
has a value greater than 16, then the parameters data field consists of
a 16-byte IV followed by a key identifier, and the length of that key
identifier is the value in the parameters length field minus 16.
	 
	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?
	 
	-susan
	 
	
*****************************************************************
	Susan Symington
	The MITRE Corporation
	[e-mail]
	703-983-7209 (voice)
	703-983-7142 (fax)
	
******************************************************************