Subject: [dtn-security] Re: Bundle Security Protocol: one more item
From: Stephen Farrell <[email-masked]>
To: Peter Lovell <[email-masked]>
Cc: Susan <[email-masked]>, Howard Weiss <[email-masked]>, [email-masked]
Date: Sat, 18 Nov 2006 17:37:57 +0000
List-Id: DTN Security Discussion <dtn-security.mailman.dtnrg.org>

Pete,

Those are really broader that the security spec. You should
raise these issues on dtn-interest/dtn-dev and see what
consensus emerges there. (And quickly would be good since we
want to finish the BP spec asap.)

S.

Peter Lovell wrote:
> Hi Susan,
> 
>> Now that I think about it, there may be more to consider with regard to
>> how this bit works in relation to the security blocks.  It is all bound
>> up in the issue of how security works if some nodes don't support it.
>>
>> Suppose for example there are nodes 1, 2, and 3 and only nodes 1 and 3
>> implement the Bundle Security Protocol. This means that if node 1
>> inserts a BAB and forwards the bundle to node 2, and node 2 doesn't
>> understand the BAB and isn't configured to delete the BAB or delete the
>> bundle, then node 2 will forward the bundle to node 3 with this "block
>> was forwarde without being processed" bit set in the BAB. When node 3
>> receives the bundle and tries to authenticate the security result in
>> the BAB, it won't authenticate (because of this bit change). This may
>> be okay for the BAB, but it would work the same for the PSH and I'm not
>> sure that's okay.  
>>
>> If node 1 is a PSH-source, node 2 doesn't understand the PSH and node 3
>> is a PSH-dest, then if node 2 forwards the bundle with this bit set in
>> the PSH, then I think we either have to specify that this bit must be
>> reset by a node before the node validates the security result in the
>> PSH or that this bit must be masked out so that it is omitted from the
>> mutable canonicalization form of the bundle. (same for CH I think.)
>>
>> Assuming this is true, does anyone have a preference for whether we
>> should mandate that nodes processing the PSH reset this bit before
>> calculating the security result or whether we should just leave this
>> bit out of the mutable canoncial form?
>>
>> Any other thoughts?
> 
> in fact, yes :)  Two of them.
> 
> -----
> 
> First is that we need to better define what "processing" is. I mentioned
> this the other day in a somewhat different context (intermediate
> validation) but it certainly is a big issue here.
> 
> Do the various block-processors define what processing is, and what is
> meant by "success" and "failure", or are these topics for the bundle spec? 
> 
> And when the bit can be turned on here and off there and on again in yet
> a third place, what real meaning does it have??
> 
> With regard to processing, what does it mean, for example, for a PS
> block if the current node is not the security destination? Does that
> change if the current node does in fact have sufficient information to
> verify the payload? If it does and the verification fails, does the
> current node still forward the bad bundle?
> 
> Another example is to think of what it means to receive a bundle but not
> have the extension necessary to interpret it, and then to receive a
> bundle with a security block and have that block fail the validation
> check. The latter is clearly a "failure" but what about the former? It's
> not a success but is it a failure? If we mark it as "could not be
> processed" then might other nodes interpret that to mean it really failed.
> 
> I'm sure we can't specify "processing" in particular detail but we
> should define how it is specified, and the various limits.
> 
> -----
> 
> My second issue is less closely related to your original question. The
> bundle spec at present refers to extensions but doesn't define them,
> which is OK. But there are problems which arise because, as you
> describe, a bundle may be processed differently at various nodes. Your
> 1-2-3 example in the second paragraph above is a good example.
> 
> I believe that the base bundle specification should contain a certain
> minimum requirement with regard to extension blocks in order that
> predictable processing can happen. For example, the bundle specification
> describes extension blocks but does not specify that block types 2, 3
> and 4 are used by and reserved for the security protocol. So an
> implementation could define its own set of 2,3 and 4 and still be
> conformant with the bundle protocol. What a mess that would be.
> 
> We need the base specification to require that extensions are
> implemented in accord with the appropriate specification. The extensions
> are optional and you can omit them and be in conformance, but you can't
> be in conformance if your implementation + extensions violates the
> various specifications. So, you don't have to do them, but you can't do
> them differently.
> 
> Especially in the case of security, we might provide a small description
> in the base spec which defines 2, 3 and 4 and specifies what a non-
> security implementation should do if it encounters blocks of those
> types. I suggest that this specify that 2 [BA] be discarded and 3 and 4
> [PS and C] be forwarded unchanged for someone else to deal with. This
> might override the "discard" flag setting, or might not. That's an open
> question, and should be decided and specified [there are good arguments
> for and against].
> 
> -----
> 
> 
> Regards.....Peter
> 
> 

Date: Sat, 18 Nov 2006 16:50:01 +0000
From: Stephen Farrell <[email-masked]>
To: "Symington, Susan F." <[email-masked]>
Cc: Howard Weiss <[email-masked]>, Peter Lovell <[email-masked]>, [email-masked]
Subject: [dtn-security] Re: Bundle Security Protocol items for discussion
Sender: [email-masked]
Reply-To: [email-masked]

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.

From: "Peter Lovell" <[email-masked]>
To: Susan <[email-masked]>, "Stephen Farrell" <[email-masked]>
Cc: "Howard Weiss" <[email-masked]>, <[email-masked]>
Date: Fri, 17 Nov 2006 23:23:20 -0500
Subject: [dtn-security] Re(2): Bundle Security Protocol: one more item
Sender: [email-masked]
Reply-To: [email-masked]

Hi Susan,

>Now that I think about it, there may be more to consider with regard to
>how this bit works in relation to the security blocks.  It is all bound
>up in the issue of how security works if some nodes don't support it.
>
>Suppose for example there are nodes 1, 2, and 3 and only nodes 1 and 3
>implement the Bundle Security Protocol. This means that if node 1
>inserts a BAB and forwards the bundle to node 2, and node 2 doesn't
>understand the BAB and isn't configured to delete the BAB or delete the
>bundle, then node 2 will forward the bundle to node 3 with this "block
>was forwarde without being processed" bit set in the BAB. When node 3
>receives the bundle and tries to authenticate the security result in
>the BAB, it won't authenticate (because of this bit change). This may
>be okay for the BAB, but it would work the same for the PSH and I'm not
>sure that's okay.  
>
>If node 1 is a PSH-source, node 2 doesn't understand the PSH and node 3
>is a PSH-dest, then if node 2 forwards the bundle with this bit set in
>the PSH, then I think we either have to specify that this bit must be
>reset by a node before the node validates the security result in the
>PSH or that this bit must be masked out so that it is omitted from the
>mutable canonicalization form of the bundle. (same for CH I think.)
>
>Assuming this is true, does anyone have a preference for whether we
>should mandate that nodes processing the PSH reset this bit before
>calculating the security result or whether we should just leave this
>bit out of the mutable canoncial form?
>
>Any other thoughts?

in fact, yes :)  Two of them.

-----

First is that we need to better define what "processing" is. I mentioned
this the other day in a somewhat different context (intermediate
validation) but it certainly is a big issue here.

Do the various block-processors define what processing is, and what is
meant by "success" and "failure", or are these topics for the bundle spec? 

And when the bit can be turned on here and off there and on again in yet
a third place, what real meaning does it have??

With regard to processing, what does it mean, for example, for a PS
block if the current node is not the security destination? Does that
change if the current node does in fact have sufficient information to
verify the payload? If it does and the verification fails, does the
current node still forward the bad bundle?

Another example is to think of what it means to receive a bundle but not
have the extension necessary to interpret it, and then to receive a
bundle with a security block and have that block fail the validation
check. The latter is clearly a "failure" but what about the former? It's
not a success but is it a failure? If we mark it as "could not be
processed" then might other nodes interpret that to mean it really failed.

I'm sure we can't specify "processing" in particular detail but we
should define how it is specified, and the various limits.

-----

My second issue is less closely related to your original question. The
bundle spec at present refers to extensions but doesn't define them,
which is OK. But there are problems which arise because, as you
describe, a bundle may be processed differently at various nodes. Your
1-2-3 example in the second paragraph above is a good example.

I believe that the base bundle specification should contain a certain
minimum requirement with regard to extension blocks in order that
predictable processing can happen. For example, the bundle specification
describes extension blocks but does not specify that block types 2, 3
and 4 are used by and reserved for the security protocol. So an
implementation could define its own set of 2,3 and 4 and still be
conformant with the bundle protocol. What a mess that would be.

We need the base specification to require that extensions are
implemented in accord with the appropriate specification. The extensions
are optional and you can omit them and be in conformance, but you can't
be in conformance if your implementation + extensions violates the
various specifications. So, you don't have to do them, but you can't do
them differently.

Especially in the case of security, we might provide a small description
in the base spec which defines 2, 3 and 4 and specifies what a non-
security implementation should do if it encounters blocks of those
types. I suggest that this specify that 2 [BA] be discarded and 3 and 4
[PS and C] be forwarded unchanged for someone else to deal with. This
might override the "discard" flag setting, or might not. That's an open
question, and should be decided and specified [there are good arguments
for and against].

-----

Regards.....Peter

Content-class: urn:content-classes:message
Date: Fri, 17 Nov 2006 15:25:54 -0500
From: "Symington, Susan F." <[email-masked]>
To: "Symington, Susan F." <[email-masked]>, "Stephen Farrell" <[email-masked]>, "Howard Weiss" <[email-masked]>, "Peter Lovell" <[email-masked]>
Cc: <[email-masked]>
Subject: [dtn-security] RE: Bundle Security Protocol items for discussion
Sender: [email-masked]
Reply-To: [email-masked]

This is a multi-part message in MIME format.

------_=_NextPart_001_01C70A86.9585752C
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Security authors and pundits,
=20
Thanks for your input in the past few days. It is helping to improve
the spec.
=20
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.
=20
Thanks.
=20
-susan
=20
*****************************************************************
Susan Symington
The MITRE Corporation
[email-masked]
703-983-7209 (voice)
703-983-7142 (fax)
******************************************************************
=20

________________________________

	From: Symington, Susan F.=20
	Sent: Monday, November 13, 2006 3:39 PM
	To: Stephen Farrell; 'Howard Weiss'
	Cc: Symington, Susan F.
	Subject: Bundle Security Protocol items for discussion
=09
=09
	Stephen and Howie,
	=20
	The following are Items we need to discuss wrt the bundle
security protocol that were brought up by BBN:
	=20
	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."=20
	=20
	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.
	=20
	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?
	=20
	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.
	=20
	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?
	=20
	-susan
	=20
=09
*****************************************************************
	Susan Symington
	The MITRE Corporation
	[email-masked]
	703-983-7209 (voice)
	703-983-7142 (fax)
=09
******************************************************************
	=20

------_=_NextPart_001_01C70A86.9585752C
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2900.2963" name=3DGENERATOR></HEAD>
<BODY>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D206181420-17112006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Security authors and =
pundits,</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D206181420-17112006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D206181420-17112006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Thanks for&nbsp;your input in the past few =
days. It is=20
helping to improve the spec.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D206181420-17112006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D206181420-17112006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>As far as I can tell, below are the only =
remaining items=20
that we need to resolve before we can wrap up this next revision of the =
Bundle=20
Security Protocol. I would appreciate receiving your input on these =
issues. Once=20
I roll in whatever revisions these generate,&nbsp;I will circulate =
version 3 of=20
the Bundle Security Protocol for your review.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D206181420-17112006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D206181420-17112006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Thanks.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D206181420-17112006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D206181420-17112006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>-susan</FONT></SPAN></DIV>
<DIV>&nbsp;</DIV>
<DIV align=3Dleft><FONT face=3DArial=20
size=3D2>****************************************************************=
*</FONT></DIV>
<DIV align=3Dleft><FONT face=3D"Courier New">Susan =
Symington</FONT></DIV>
<DIV align=3Dleft><FONT face=3D"Courier New">The MITRE =
Corporation</FONT></DIV>
<DIV align=3Dleft><FONT face=3D"Courier =
New">[email-masked]</FONT></DIV>
<DIV align=3Dleft><FONT face=3D"Courier New">703-983-7209 =
(voice)</FONT></DIV>
<DIV align=3Dleft><FONT face=3D"Courier New">703-983-7142 =
(fax)</FONT></DIV>
<DIV align=3Dleft><FONT face=3DArial=20
size=3D2>****************************************************************=
**</FONT></DIV>
<DIV>&nbsp;</DIV><BR>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
  <HR tabIndex=3D-1>
  <FONT face=3DTahoma size=3D2><B>From:</B> Symington, Susan F. =
<BR><B>Sent:</B>=20
  Monday, November 13, 2006 3:39 PM<BR><B>To:</B> Stephen Farrell; =
'Howard=20
  Weiss'<BR><B>Cc:</B> Symington, Susan F.<BR><B>Subject:</B> Bundle =
Security=20
  Protocol items for discussion<BR></FONT><BR></DIV>
  <DIV></DIV>
  <DIV><FONT face=3DArial size=3D2><SPAN =
class=3D829441319-13112006>Stephen and=20
  Howie,</SPAN></FONT></DIV>
  <DIV><FONT face=3DArial size=3D2><SPAN=20
  class=3D829441319-13112006></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2><SPAN class=3D829441319-13112006>The =
following are=20
  Items we need to discuss wrt the bundle security protocol that were =
brought up=20
  by BBN:</SPAN></FONT></DIV>
  <DIV><FONT face=3DArial size=3D2><SPAN=20
  class=3D829441319-13112006></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2><SPAN class=3D829441319-13112006>1. =
If a bundle=20
  includes a previous hop insertion block (defined in its own internet =
draft)=20
  with an EID-only or EID-with-Timestamp-formatted information record, =
then this=20
  means that the bundle already includes the EID of its previous hop (in =
its=20
  dictionary), with pointers to this previous hop EID (in its =
previous-hop=20
  insertion block). In this case, it would be redundant to include the =
EID of=20
  the previous hop in the security-source field of the BAB. Therefore, I =
propose=20
  that we no longer make inclusion of the security-source field =
mandatory in the=20
  BAB. It should be optional. If the security-source field is not =
present,=20
  however, and the EID of the previous hop cannot be inferred from some =
other=20
  part of the bundle, then processing of the BAB shall fail. The =
proposed text=20
  would say, "If the forwarder of the bundle is not identified in any =
other=20
  blocks of the bundle (e.g. the optional Previous-hop insertion block), =
then=20
  the security-source field MUST be present and MUST identify the =
forwarder of=20
  the bundle." </SPAN></FONT></DIV>
  <DIV><FONT face=3DArial size=3D2><SPAN=20
  class=3D829441319-13112006></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2><SPAN class=3D829441319-13112006>2. =
Under the=20
  "Notes" section of 3.2.2, it says, "URI encoding will be a cause for =
errors if=20
  any node rewrites the dectionary...we simple hae to live with this=20
  problem".&nbsp; BBN wonders why we can't just put in a statement like, =
"A node=20
  SHOULD NOT change the encoding of any URI in the dictionary field =
(elg.=20
  changing the DNS part of some HTTP URL from lower case to upper =
case)."&nbsp;=20
  I don't understand the problem sufficiently be able to respond on=20
  this.</SPAN></FONT></DIV>
  <DIV><FONT face=3DArial size=3D2><SPAN=20
  class=3D829441319-13112006></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2><SPAN class=3D829441319-13112006>3. =
In section 3.4,=20
  Bundles received from other nodes, 5th paragraph, it says that "...the =
node=20
  MUST decrypt the relevant parts of the bundle according to the =
ciphersuite=20
  specification and delete the CH in question."&nbsp; BBN wants to know =
what to=20
  do if decryption fails.&nbsp; I propose we add a sentence here that =
says, "If=20
  the relevant parts of the bundle cannot be decrypted (i.e., the =
decription key=20
  cannot be deduced or decryption fails), the behavior of the bundle =
protocol=20
  agent will be as specified in the CB Block Processing Flags, unless =
overridden=20
  by the local security policy." Is this okay with =
you?</SPAN></FONT></DIV>
  <DIV><FONT face=3DArial size=3D2><SPAN=20
  class=3D829441319-13112006></SPAN></FONT>&nbsp;</DIV>
  <DIV><SPAN class=3D829441319-13112006><FONT face=3DArial><FONT =
size=3D2>4. If the=20
  CH-RSA-AES-PAYLOAD-PSH ciphersuite is used, the first CH must have a=20
  ciphersuite parameter that contains a 16-byte IV, optionally followed =
by a key=20
  identifier. Is it true that the way we tell whether or not there is =
only an IV=20
  versus an IV followed by a key ID is by the length specified in the=20
  ciphersuite parameters SDNV?&nbsp; If this SDNV shows the ciphersuite=20
  parameters field to be 16 bytes long, then we know only an IV is=20
  included.&nbsp; If this SDNV shows the ciphersuite parameters field to =
be=20
  longer than 16 bytes, then we know that both an IV and a key ID is =
included,=20
  and the length of the key ID is the length shown in the SDNV minus 16 =
bytes.=20
  Is this correct?&nbsp; If so, BBN was unsure of it so we should =
probably=20
  explicitly say this in the spec.<BR><SPAN =
class=3D206181420-17112006><FONT=20
  color=3D#0000ff>[Susan]&nbsp;Now that we have redefined the format of =
the=20
  Abstrace&nbsp;Security&nbsp;Block such that the parameters =
field&nbsp;morphed=20
  into&nbsp;a&nbsp; compound field&nbsp;(parameters-length field and=20
  &nbsp;parameters data field), I propose that we specify in teh=20
  CH-RSA_AES-PAYLOAD-PSH ciphersuite that if the parameters-length field =
has a=20
  value equal to 16, then the parameters data field consists of only a =
16-bye=20
  IV. If the parameters-length field has a value greater than 16, then =
the=20
  parameters data field consists of a 16-byte IV followed by a key =
identifier,=20
  and the length of that key identifier is the value in the parameters =
length=20
  field minus 16.</FONT></SPAN></FONT></FONT></SPAN></DIV>
  <DIV><FONT face=3DArial size=3D2><SPAN=20
  class=3D829441319-13112006></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2><SPAN class=3D829441319-13112006>5. =
To be sure I am=20
  correct, in the CH-RSA-AES-PAYLOAD-PSH ciphersuite definition, the =
input to=20
  the KDF is the BEK catenated wtih the IV from the ciphersuite =
parameter of the=20
  first CH, right?&nbsp; (BBN was unclear on whether there is a single =
IV in the=20
  first CH or whether each CH includes an IV).&nbsp; It is my =
understanding that=20
  there is a single IV in the first CH. Subsequent CHs do not contain =
any of the=20
  optional fields (such as ciphersuite parameters) that are included in =
the=20
  first CH.&nbsp; Is my understanding correct?</SPAN></FONT></DIV>
  <DIV><FONT face=3DArial size=3D2><SPAN=20
  class=3D829441319-13112006></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2><SPAN=20
  class=3D829441319-13112006>-susan</SPAN></FONT></DIV>
  <DIV><FONT face=3DArial size=3D2><SPAN=20
  class=3D829441319-13112006></SPAN></FONT>&nbsp;</DIV>
  <DIV align=3Dleft><FONT face=3DArial=20
  =
size=3D2>****************************************************************=
*</FONT></DIV>
  <DIV align=3Dleft><FONT face=3D"Courier New">Susan =
Symington</FONT></DIV>
  <DIV align=3Dleft><FONT face=3D"Courier New">The MITRE =
Corporation</FONT></DIV>
  <DIV align=3Dleft><FONT face=3D"Courier =
New">[email-masked]</FONT></DIV>
  <DIV align=3Dleft><FONT face=3D"Courier New">703-983-7209 =
(voice)</FONT></DIV>
  <DIV align=3Dleft><FONT face=3D"Courier New">703-983-7142 =
(fax)</FONT></DIV>
  <DIV align=3Dleft><FONT face=3DArial=20
  =
size=3D2>****************************************************************=
**</FONT></DIV>
  <DIV>&nbsp;</DIV></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C70A86.9585752C--

Date: Fri, 17 Nov 2006 18:08:06 +0000
From: Stephen Farrell <[email-masked]>
To: Peter Lovell <[email-masked]>
Cc: "Symington, Susan F." <[email-masked]>, hsw <[email-masked]>, [email-masked]
Subject: [dtn-security] Re: Bundle Security Protocol details
Sender: [email-masked]
Reply-To: [email-masked]

Peter Lovell wrote:
> I don't know of a digest mechanism which produces results which vary in
> length but I can imagine that there are some. 

I don't believe there are any such.

> However, I don't think this is a big deal. If we require fixed length
> then that's OK with me. We just need to clarify what we mean.

Yes, let's do that.

S.

From: "Peter Lovell" <[email-masked]>
To: "Symington, Susan F." <[email-masked]>, "Stephen Farrell" <[email-masked]>
Cc: hsw <[email-masked]>, <[email-masked]>
Date: Fri, 17 Nov 2006 13:04:03 -0500
Subject: [dtn-security] Re(4): Bundle Security Protocol details
Sender: [email-masked]
Reply-To: [email-masked]

Hi Susan,

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

I suggest that we clarify the language to indicate that "security
result" is a compound field, consisting of "security result length" and
"security result data". The phrase "security result" refers to the
compound field.

Bit 11 ("res" bit) indicates whether or not the "security result" (length
+data) is in a block (bit is set) or not (bit is zero). Length+data
always go together and are never split.

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

I don't think it's invalid, it's just that I had not also made that
assumption. 

I don't know of a digest mechanism which produces results which vary in
length but I can imagine that there are some. 

>>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
>>size known since it's SDNV) and the block-length field must be
>>not known, nor is its 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?  

The problem comes if you have multiple BA blocks. Not the "split block"
kind, but where there are multiple BAs for some reason, such as key-
rollover or whatever. Which one do you canonicalize first and what value
can you use for the length of the second, if you don't know that until
you do the second?

The answer is that you can't do this unless the lengths for ALL BAs are
known before you start digesting for ANY of them. And these lengths also
are part of the overall block length for each block.

Since I didn't want to preclude variable-length, and also because it
seemed that "security result" intended to mean "length+data", I had
thought to exclude both parts of that field from canonicalization.

However, I don't think this is a big deal. If we require fixed length
then that's OK with me. We just need to clarify what we mean.

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

In line with the definition suggested at the top, I prefer that it point
to the start of the "security result" field and not the start of the
data field ["security result data"]. This is the same start point as the
length field["security result length"], of course.

Thanks.....Peter

Date: Fri, 17 Nov 2006 16:06:19 +0000
From: Stephen Farrell <[email-masked]>
To: [email-masked]
Cc: Peter Lovell <[email-masked]>, Howard Weiss <[email-masked]>
Subject: Re: [dtn-security] RE: Bundle Security Protocol: one more item
Sender: [email-masked]
Reply-To: [email-masked]

Symington, Susan F. wrote:
> I don't understand the replay threat. What do you mean by, "It means an
> attacker could force
> the processing of blocks in PSB's bundles and could replay those"?

Maybe not too big a deal but if its not digested, then a bad guy
can keep modifying this bit on all the bundles he sees emerging
from a forwarded and in that way affect the operation of the DTN,
maybe consuming resources or forcing wrong routes or whatever.

> I agree that we need to put in a statement saying that this bit should
> be masked in the PSB and CB (what about the BAB?) so that it is omitted
> from the mutable canonical form.  I don't believe that this bit should
> be masked in the primary bundle block, since every node is required to
> be able to process this block.

Why on earth would the primary block have such a bit? Since that'd carry
no useful information at all, I've no problem with it being in or out of
digesting.

The BAB emitter can do whatever it wants to with this. Doesn't matter
since the BAB will be checked before anyone is supposed to get a chance
to muck with any flag so its ok to include this in BAB digesting.

S.

Content-class: urn:content-classes:message
Date: Fri, 17 Nov 2006 10:54:12 -0500
From: "Symington, Susan F." <[email-masked]>
To: "Stephen Farrell" <[email-masked]>
Cc: "Peter Lovell" <[email-masked]>, "Howard Weiss" <[email-masked]>, <[email-masked]>
Subject: [dtn-security] RE: Bundle Security Protocol: one more item
Sender: [email-masked]
Reply-To: [email-masked]

I don't understand the replay threat. What do you mean by, "It means an
attacker could force
the processing of blocks in PSB's bundles and could replay those"?

I agree that we need to put in a statement saying that this bit should
be masked in the PSB and CB (what about the BAB?) so that it is omitted
from the mutable canonical form.  I don't believe that this bit should
be masked in the primary bundle block, since every node is required to
be able to process this block.

-susan

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

>-----Original Message-----
>From: Stephen Farrell [mailto:[email-masked]] 
>Sent: Friday, November 17, 2006 10:49 AM
>To: Symington, Susan F.
>Cc: Peter Lovell; Howard Weiss; [email-masked]
>Subject: Re: Bundle Security Protocol: one more item
>
>
>
>Symington, Susan F. wrote:
>> Suppose for example there are nodes 1, 2, and 3 and only 
>nodes 1 and 3
>> implement the Bundle Security Protocol. This means that if node 1
>> inserts a BAB and forwards the bundle to node 2, and node 2 doesn't
>> understand the BAB and isn't configured to delete the BAB or 
>delete the
>> bundle, then node 2 will forward the bundle to node 3 with 
>this "block
>> was forwarde without being processed" bit set in the BAB. When node
3
>> receives the bundle and tries to authenticate the security result in
>> the BAB, it won't authenticate (because of this bit change). This
may
>> be okay for the BAB, but it would work the same for the PSH 
>and I'm not
>> sure that's okay.  
>
>If the BAB verifies in that case, then something is quite weird.
>If the BAB fails, then the bundle's toast so this bit is irrelevant.
>
>> 
>> If node 1 is a PSH-source, node 2 doesn't understand the PSH 
>and node 3
>> is a PSH-dest, then if node 2 forwards the bundle with this 
>bit set in
>> the PSH, then I think we either have to specify that this bit must
be
>> reset by a node before the node validates the security result in the
>> PSH or that this bit must be masked out so that it is 
>omitted from the
>> mutable canonicalization form of the bundle. (same for CH I think.)
>> 
>> Assuming this is true, does anyone have a preference for whether we
>> should mandate that nodes processing the PSH reset this bit before
>> calculating the security result or whether we should just leave this
>> bit out of the mutable canoncial form?
>
>Ignore the bit for c14n purposes. Easy.
>
>Ok, that doesn't quite work though. It means an attacker could force
>the processing of blocks in PSB's bundles and could replay those. So
>it has to be an input to digesting in the PSB. OTOH, this silly bit
>is supposed to be modified en-route, so it has to be mutable. Bummer.
>
>So, in the end, we have to ignore the bit for c14n purposes.
>
>We can (and MUST) certainly ignore the bit for security processing
>purposes.
>
>There should be a security consideration saying that this kind of
>replay can happen and why we have to live with that.
>
>Stephen.
>
>

Date: Fri, 17 Nov 2006 15:48:57 +0000
From: Stephen Farrell <[email-masked]>
To: "Symington, Susan F." <[email-masked]>
Cc: Peter Lovell <[email-masked]>, Howard Weiss <[email-masked]>, [email-masked]
Subject: [dtn-security] Re: Bundle Security Protocol: one more item
Sender: [email-masked]
Reply-To: [email-masked]

Symington, Susan F. wrote:
> Suppose for example there are nodes 1, 2, and 3 and only nodes 1 and 3
> implement the Bundle Security Protocol. This means that if node 1
> inserts a BAB and forwards the bundle to node 2, and node 2 doesn't
> understand the BAB and isn't configured to delete the BAB or delete the
> bundle, then node 2 will forward the bundle to node 3 with this "block
> was forwarde without being processed" bit set in the BAB. When node 3
> receives the bundle and tries to authenticate the security result in
> the BAB, it won't authenticate (because of this bit change). This may
> be okay for the BAB, but it would work the same for the PSH and I'm not
> sure that's okay.  

If the BAB verifies in that case, then something is quite weird.
If the BAB fails, then the bundle's toast so this bit is irrelevant.

> 
> If node 1 is a PSH-source, node 2 doesn't understand the PSH and node 3
> is a PSH-dest, then if node 2 forwards the bundle with this bit set in
> the PSH, then I think we either have to specify that this bit must be
> reset by a node before the node validates the security result in the
> PSH or that this bit must be masked out so that it is omitted from the
> mutable canonicalization form of the bundle. (same for CH I think.)
> 
> Assuming this is true, does anyone have a preference for whether we
> should mandate that nodes processing the PSH reset this bit before
> calculating the security result or whether we should just leave this
> bit out of the mutable canoncial form?

Ignore the bit for c14n purposes. Easy.

Ok, that doesn't quite work though. It means an attacker could force
the processing of blocks in PSB's bundles and could replay those. So
it has to be an input to digesting in the PSB. OTOH, this silly bit
is supposed to be modified en-route, so it has to be mutable. Bummer.

So, in the end, we have to ignore the bit for c14n purposes.

We can (and MUST) certainly ignore the bit for security processing
purposes.

There should be a security consideration saying that this kind of
replay can happen and why we have to live with that.

Stephen.

Content-class: urn:content-classes:message
Date: Fri, 17 Nov 2006 10:40:34 -0500
From: "Symington, Susan F." <[email-masked]>
To: "Stephen Farrell" <[email-masked]>
Cc: "Peter Lovell" <[email-masked]>, "Howard Weiss" <[email-masked]>, <[email-masked]>
Subject: [dtn-security] RE: Bundle Security Protocol: one more item
Sender: [email-masked]
Reply-To: [email-masked]

The point of the bit is to indicate that the bundle passed through a
node that doesn't support the block, and that node that doesn't support
the block didn't delete the block (obviously) or delete the bundle
(obviously).

It first came up when we were trying to define a block that essentially
accumulated the EIDs of all the nodes that the bundle passed through.
We wanted a way to know that the bundle had passed through some nodes
that didn't add their EIDs to the accumulating path log (because the
nodes didn't support the optional block). 

Now that I think about it, there may be more to consider with regard to
how this bit works in relation to the security blocks.  It is all bound
up in the issue of how security works if some nodes don't support it.

Suppose for example there are nodes 1, 2, and 3 and only nodes 1 and 3
implement the Bundle Security Protocol. This means that if node 1
inserts a BAB and forwards the bundle to node 2, and node 2 doesn't
understand the BAB and isn't configured to delete the BAB or delete the
bundle, then node 2 will forward the bundle to node 3 with this "block
was forwarde without being processed" bit set in the BAB. When node 3
receives the bundle and tries to authenticate the security result in
the BAB, it won't authenticate (because of this bit change). This may
be okay for the BAB, but it would work the same for the PSH and I'm not
sure that's okay.  

If node 1 is a PSH-source, node 2 doesn't understand the PSH and node 3
is a PSH-dest, then if node 2 forwards the bundle with this bit set in
the PSH, then I think we either have to specify that this bit must be
reset by a node before the node validates the security result in the
PSH or that this bit must be masked out so that it is omitted from the
mutable canonicalization form of the bundle. (same for CH I think.)

Assuming this is true, does anyone have a preference for whether we
should mandate that nodes processing the PSH reset this bit before
calculating the security result or whether we should just leave this
bit out of the mutable canoncial form?

Any other thoughts?

-susan
*****************************************************************
Susan Symington
The MITRE Corporation
[email-masked]
703-983-7209 (voice)
703-983-7142 (fax)
******************************************************************

>-----Original Message-----
>From: Stephen Farrell [mailto:[email-masked]] 
>Sent: Friday, November 17, 2006 7:32 AM
>To: Symington, Susan F.
>Cc: Peter Lovell; Howard Weiss; [email-masked]
>Subject: Re: Bundle Security Protocol: one more item
>
>
>
>Symington, Susan F. wrote:
>> Security pundits:
>>  
>> One more item that I would like to address in the next 
>revision of the 
>> Bundle Security Protocol:
>>  
>> Currently, section 3.7 of the Bundle Protocol says the following:
>>  
>> "Whenever a bundle is forwarded that contains one or more extension
>>    blocks that could not be processed, the "Block was 
>forwarded without
>>    being processed" flag must be set to 1 within the block
processing
>>    flags of each such block.  For each block flagged in this way,
the
>>    flag may optionally be cleared (i.e., set to zero) by another
node
>>    that subsequently receives the bundle and is able to process that
>>    block; the specifications defining the various extension 
>blocks are
>>    expected to define the circumstances under which this flag may be
>>    cleared, if any. "
>>  
>>  
>> This means that in the Bundle Security Protocol we need to 
>define the 
>> circumstances under
>> which the "Block was forwarded without being processed" flag may be 
>> cleared, if any.
>>  
>> Anyone care to take a stab at this?
>
>If you decrypt then you'll be deleting blocks anyway so I think
>that'd be ok. Any such bit will disappear (a good thing IMO).
>
>BAB is irrelevant here I hope since they don't get forwarded.
>
>So that leaves the PSB and our one mandatory ciphersuite.
>
>If you successfully verify a signature, but don't remove the
>PSB, I'd say leave the bit alone and forward whatever you
>got.
>
>The reason being that it'd be bogus to have a flag that says
>"someone once verified a signature here" with no further
>details. Subsequent nodes can all verify the signature
>if they so choose (with this ciphersuite), since verification
>is sort-of idempotent if you know what I mean.
>
>In future, someone may want to define a brand new "security
>result analysis" block that might say "bob checked alice's signature
>yesterday and it was ok then, including a check with charlie's
>OSCP repsonder for alice's cert serial #1234 issued by dave's
>CA and bob also generated an evidence token for alice's signature
>(using eddy for trusted time) and lodged that with fred." Doing
>that sensibly requires more than one bit, and really requires
>that bob add his own PSB as well, so we don't want the "processed"
>flag to be mistakenly used as a "signature is good" signal.
>
>Or, I could agree to setting the bit to a random value (a generic
>way to remove meaning:-).
>
>[As an aside - what is that bit good for anyway?]
>
>Stephen.
>
>
>

Date: Fri, 17 Nov 2006 15:07:30 +0000
From: Stephen Farrell <[email-masked]>
To: "Symington, Susan F." <[email-masked]>
Cc: Peter Lovell <[email-masked]>, hsw <[email-masked]>, [email-masked]
Subject: [dtn-security] Re: Bundle Security Protocol details
Sender: [email-masked]
Reply-To: [email-masked]

Symington, Susan F. wrote:
> 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?

I think its a fine assumption, so long as "known," means "known to the
module that implements the ciphersuite."

But if someone has a counterexample I'd be interested in seeing that.

S.

Content-class: urn:content-classes:message
Date: Fri, 17 Nov 2006 10:03:17 -0500
From: "Symington, Susan F." <[email-masked]>
To: "Peter Lovell" <[email-masked]>, "Stephen Farrell" <[email-masked]>
Cc: "hsw" <[email-masked]>, <[email-masked]>
Subject: [dtn-security] RE: Bundle Security Protocol details
Sender: [email-masked]
Reply-To: [email-masked]

Peter,

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

-susan

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

>-----Original Message-----
>From: Peter Lovell [mailto:[email-masked]] 
>Sent: Thursday, November 16, 2006 7:05 PM
>To: Symington, Susan F.; Stephen Farrell
>Cc: hsw; [email-masked]
>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
>
>

Date: Fri, 17 Nov 2006 12:32:02 +0000
From: Stephen Farrell <[email-masked]>
To: "Symington, Susan F." <[email-masked]>
Cc: Peter Lovell <[email-masked]>, Howard Weiss <[email-masked]>, [email-masked]
Subject: [dtn-security] Re: Bundle Security Protocol: one more item
Sender: [email-masked]
Reply-To: [email-masked]

Symington, Susan F. wrote:
> Security pundits:
>  
> One more item that I would like to address in the next revision of the 
> Bundle Security Protocol:
>  
> Currently, section 3.7 of the Bundle Protocol says the following:
>  
> "Whenever a bundle is forwarded that contains one or more extension
>    blocks that could not be processed, the "Block was forwarded without
>    being processed" flag must be set to 1 within the block processing
>    flags of each such block.  For each block flagged in this way, the
>    flag may optionally be cleared (i.e., set to zero) by another node
>    that subsequently receives the bundle and is able to process that
>    block; the specifications defining the various extension blocks are
>    expected to define the circumstances under which this flag may be
>    cleared, if any. "
>  
>  
> This means that in the Bundle Security Protocol we need to define the 
> circumstances under
> which the "Block was forwarded without being processed" flag may be 
> cleared, if any.
>  
> Anyone care to take a stab at this?

If you decrypt then you'll be deleting blocks anyway so I think
that'd be ok. Any such bit will disappear (a good thing IMO).

BAB is irrelevant here I hope since they don't get forwarded.

So that leaves the PSB and our one mandatory ciphersuite.

If you successfully verify a signature, but don't remove the
PSB, I'd say leave the bit alone and forward whatever you
got.

The reason being that it'd be bogus to have a flag that says
"someone once verified a signature here" with no further
details. Subsequent nodes can all verify the signature
if they so choose (with this ciphersuite), since verification
is sort-of idempotent if you know what I mean.

In future, someone may want to define a brand new "security
result analysis" block that might say "bob checked alice's signature
yesterday and it was ok then, including a check with charlie's
OSCP repsonder for alice's cert serial #1234 issued by dave's
CA and bob also generated an evidence token for alice's signature
(using eddy for trusted time) and lodged that with fred." Doing
that sensibly requires more than one bit, and really requires
that bob add his own PSB as well, so we don't want the "processed"
flag to be mistakenly used as a "signature is good" signal.

Or, I could agree to setting the bit to a random value (a generic
way to remove meaning:-).

[As an aside - what is that bit good for anyway?]

Stephen.

Date: Fri, 17 Nov 2006 12:20:03 +0000
From: Stephen Farrell <[email-masked]>
To: Peter Lovell <[email-masked]>
Cc: Susan <[email-masked]>, hsw <[email-masked]>, [email-masked]
Subject: [dtn-security] Re: Bundle Security Protocol details
Sender: [email-masked]
Reply-To: [email-masked]

Hi Pete,

I'd be happy with everything that Susan wrote.

I also agree with you that the result-length & result are to be
kept together in the same block. We should say that.

You seem to be implying that there may be ciphersuites where
you don't know the result length in advance, is that right?
I'm not aware of any such ciphersuite as it happens. Are you?

If not, then I think its fine to assume that the length is
known before digesting (the c14n & digest fnc. are specified
by the ciphersuite, so you've been to that code already).

S.

Peter Lovell wrote:
> 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
> 

From: "Peter Lovell" <[email-masked]>
To: Susan <[email-masked]>, "Stephen Farrell" <[email-masked]>
Cc: hsw <[email-masked]>, <[email-masked]>
Date: Thu, 16 Nov 2006 19:04:57 -0500
Subject: [dtn-security] Re: Bundle Security Protocol details
Sender: [email-masked]
Reply-To: [email-masked]

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

Content-class: urn:content-classes:message
Date: Thu, 16 Nov 2006 16:12:34 -0500
From: "Symington, Susan F." <[email-masked]>
To: "Stephen Farrell" <[email-masked]>, "Peter Lovell" <[email-masked]>, "Howard Weiss" <[email-masked]>
Cc: <[email-masked]>
Subject: [dtn-security] Bundle Security Protocol: one more item
Sender: [email-masked]
Reply-To: [email-masked]

This is a multi-part message in MIME format.

------_=_NextPart_001_01C709C3.EFFC30D7
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Security pundits:
=20
One more item that I would like to address in the next revision of the
Bundle Security Protocol:
=20
Currently, section 3.7 of the Bundle Protocol says the following:
=20
"Whenever a bundle is forwarded that contains one or more extension=20
   blocks that could not be processed, the "Block was forwarded without

   being processed" flag must be set to 1 within the block processing=20
   flags of each such block.  For each block flagged in this way, the=20
   flag may optionally be cleared (i.e., set to zero) by another node=20
   that subsequently receives the bundle and is able to process that=20
   block; the specifications defining the various extension blocks are=20
   expected to define the circumstances under which this flag may be=20
   cleared, if any. "
=20
=20
This means that in the Bundle Security Protocol we need to define the
circumstances under
which the "Block was forwarded without being processed" flag may be
cleared, if any.
=20
Anyone care to take a stab at this?
=20
-susan
=20
*****************************************************************
Susan Symington
The MITRE Corporation
[email-masked]
703-983-7209 (voice)
703-983-7142 (fax)
******************************************************************
=20

------_=_NextPart_001_01C709C3.EFFC30D7
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2900.2963" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DArial size=3D2><SPAN =
class=3D238160821-16112006>Security=20
pundits:</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D238160821-16112006></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D238160821-16112006>One =
more item that I=20
would like to address in the next revision of the Bundle Security=20
Protocol:</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D238160821-16112006></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN =
class=3D238160821-16112006>Currently, section=20
3.7 of the Bundle Protocol says the following:</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial><FONT size=3D2><SPAN=20
class=3D238160821-16112006>"</SPAN>Whenever a bundle is forwarded that =
contains=20
one or more extension <BR>&nbsp;&nbsp; blocks that could not be =
processed, the=20
"Block was forwarded without <BR>&nbsp;&nbsp; being processed" flag must =
be set=20
to 1 within the block processing <BR>&nbsp;&nbsp; flags of each such=20
block.&nbsp; For each block flagged in this way, the <BR>&nbsp;&nbsp; =
flag may=20
optionally be cleared (i.e., set to zero) by another node =
<BR>&nbsp;&nbsp; that=20
subsequently receives the bundle and is able to process that =
<BR>&nbsp;&nbsp;=20
block; the specifications defining the various extension blocks are=20
<BR>&nbsp;&nbsp; expected to define the circumstances under which this =
flag may=20
be <BR>&nbsp;&nbsp; cleared, if any.&nbsp;<SPAN=20
class=3D238160821-16112006>"</SPAN></FONT></FONT></DIV>
<DIV><FONT face=3DArial><FONT size=3D2><SPAN=20
class=3D238160821-16112006></SPAN></FONT></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial><FONT size=3D2><SPAN=20
class=3D238160821-16112006></SPAN></FONT></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial><FONT size=3D2><SPAN =
class=3D238160821-16112006>This means=20
that in the Bundle Security Protocol we need to define the circumstances =

under</SPAN></FONT></FONT></DIV>
<DIV><FONT face=3DArial><FONT size=3D2><SPAN =
class=3D238160821-16112006>which the=20
"Block was forwarded without being processed" flag may be cleared, if=20
any.</SPAN></FONT></FONT></DIV>
<DIV><FONT face=3DArial><FONT size=3D2><SPAN=20
class=3D238160821-16112006></SPAN></FONT></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial><FONT size=3D2><SPAN =
class=3D238160821-16112006>Anyone care to=20
take a stab at this?</SPAN></FONT></FONT></DIV>
<DIV><FONT face=3DArial><FONT size=3D2><SPAN=20
class=3D238160821-16112006></SPAN></FONT></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial><FONT size=3D2><SPAN=20
class=3D238160821-16112006>-susan</SPAN></FONT></FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV align=3Dleft><FONT face=3DArial=20
size=3D2>****************************************************************=
*</FONT></DIV>
<DIV align=3Dleft><FONT face=3D"Courier New">Susan =
Symington</FONT></DIV>
<DIV align=3Dleft><FONT face=3D"Courier New">The MITRE =
Corporation</FONT></DIV>
<DIV align=3Dleft><FONT face=3D"Courier =
New">[email-masked]</FONT></DIV>
<DIV align=3Dleft><FONT face=3D"Courier New">703-983-7209 =
(voice)</FONT></DIV>
<DIV align=3Dleft><FONT face=3D"Courier New">703-983-7142 =
(fax)</FONT></DIV>
<DIV align=3Dleft><FONT face=3DArial=20
size=3D2>****************************************************************=
**</FONT></DIV>
<DIV>&nbsp;</DIV></BODY></HTML>

------_=_NextPart_001_01C709C3.EFFC30D7--

Content-class: urn:content-classes:message
Date: Thu, 16 Nov 2006 15:33:45 -0500
From: "Symington, Susan F." <[email-masked]>
To: "Peter Lovell" <[email-masked]>, "Stephen Farrell" <[email-masked]>
Cc: "hsw" <[email-masked]>, <[email-masked]>
Subject: [dtn-security] Bundle Security Protocol details
Sender: [email-masked]
Reply-To: [email-masked]

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
[email-masked]
703-983-7209 (voice)
703-983-7142 (fax)
******************************************************************

>-----Original Message-----
>From: Peter Lovell [mailto:[email-masked]] 
>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.
>