Subject: [dtn-security] BSP draft issues
From: "Peter Lovell" <[email-masked]>
To: <[email-masked]>
Date: Wed, 25 Apr 2007 16:42:24 -0400
List-Id: DTN Security Discussion <dtn-security.mailman.dtnrg.org>

Working through the notes from Howie's Big Red Pen, I come across a
couple of not-quite-editing questions. I'm sure I'll find more :)

Anyhow, we might be able to deal also with these before Dublin so please
let me have your opinions.

----------------
The discussion of confidentiality in section 2.4 makes mention of a way
to collect several blocks together and encrypt them as a single clump.
Do we really want to allow this, or should we have blocks encrypted on a
one-to-one basis? Because of the block-sequence issues, I would like to
remove this "collection" and have it one-to-one only.

There may have been a size-efficiency reason for doing the collection
but now we have EID-references that's much better.

------------------
In section 3.2.2 on mutable canonicalization, there's a discussion about
what's included and what isn't. In the part about the payload, it says
that we include the "block was forwarded without being processed" flag
because no-one should ever set it, as all nodes must be able to process it. 

I'm not sure that is really true. Maybe the flag isn't set, but it's not
always possible to "process" the payload block. It might be an admin
record, or encrypted, or maybe something else. 

I don't want to get into the issue of what might or might not happen to
that bit, as it's more properly a bundle protocol issue rather than BSP.
But unless someone has an objection, I'd like to treat the bit in
payload flags the same way we do for extension blocks - regard it as
mutable and exclude it from canonicalization.

------------------

Thanks.....Peter

From: "Peter Lovell" <[email-masked]>
To: Susan <[email-masked]>
Cc: <[email-masked]>
Date: Tue, 24 Apr 2007 13:39:26 -0400
Subject: [dtn-security] Re(7): [dtn-interest] block-sequencing issue
Sender: [email-masked]
Reply-To: [email-masked]

On Thu, Apr 19, 2007, Symington, Susan F. <[email-masked]> wrote:

>Peter, 
>
>I have a question about the BSP that relates to the below message that
>you sent out in February.
>You argued eloquently for the requirement that the ordering of blocks
>be preserved at all nodes, and now this change has been made to the BP.
>Which this change, the ordering of the bundles can be used to indicate
>in what order they should be processed. 
>
>What I'm not clear about is where in the BSP the text actually
>specifies what order certain operations should be performed in.  For
>example, If node 1 calculates and inserts a PSB1 on the bundle and then
>the next node, node 2, calculates and inserts a PSB2 on the bundle
>(including the BSP1 that was inserted by node 1) then some later node
>that wants to verify the security result of BSP 1 needs to know to
>exclude BSP2 and a node that wants to verify the security result of
>BSP2 needs to know to include BSP1. From your email, it seems that the
>relative order of BSP1 and BSP2 in the bundle is what indicates which
>signature covers which. My concern is that (unless I am missing it),
>the specification isn't very clear on how the relative ordering of two
>blocks determines how the security result of one does (or doesn't)
>include the other block.
>
>The only text in the spec that I could find that seems to address this
>issue is in 3.2.2, where it says, 
>    " - the ciphersuite will likely specify that the "current" security
>      block security result field not be considered part of the
>      canonical form.  This differs from the case in strict
>      canonicalisation since we might use the mutable canonicalisation
>      algorithm to handle sequential signatures, where later signatures
>      should cover earlier ones."
>
>Am I missing some text somewhere?
>
>Don't we need to add text to the PSB-RSA-SHA256 section, for example,
>that says something like:
>
>"If a PSB with this ciphersuite is being inserted into a bundle then:
> - it must be added after all other PSBs (if any) that are in the
>bundle,
> - its canonical form must include all PSBs that precede the PSB in
>question and must exclude the security result field of the PSB in
>question. 
>
>When verifying the security result in a PSB that uses this ciphersuite,
>all PSBs that precede the PSB in question must be included as part of
>the canonical form, all PSBs that follow the PSB in question must be
>excluded, and all fields of the PSB in question except for the security
>result field must be included?"
>
>(I'm assuming that this is how your implementation works.) 
>
>-susan

Hi Susan,

You are correct - there is additional language needed in BSP to discuss
the sequencing, as Keith's email had also suggested.

The block sequence is critical for things such as PS digests, as I
mentioned and as is now described in the spec. A second reason for
maintaining order is to determine the process sequence, which was
mentioned only lightly during the discussion.

Although we need language to define the processing order, that has been
hard to pin down. I've been trying to leave it open and use the BSP code
development as a guide to what we need to codify. 

There are some general principles I've been using ...

1. some actions don't need sequence at all, and can be done any time

2. some actions don't cause a change but must happen at a specific point
in the sequence, digest creation is a typical example

3. some actions change data and must happen at a specific point,
encryption being an example of this

4. the "layering" outward from the payload block is an indicator of the
processing sequence

There are some actions which don't have a marker in the sequence, with
fragmentation being the most obvious. Although there may be ways to
determine in some cases just when a bundle was fragmented, I'm not sure
if we can generally do it. For example, can we always tell whether
fragmentation was before encryption, or after it? We certainly can
sometimes tell, but I'm not certain about "always". 

I'm thinking about establishing a new extension block type to track
modifications, for those situations where there isn't a block already.
Although it would be a "block", core code would understand it. I'm
thinking of having it as a block mainly so the sequence/layering is
quite clear. It would then be easy to determine, for example, that a
bundle was fragmented, then encrypted, and fragmented again -- no
uncertainty at all.

This might also be a good alternative for bundle-in-bundle
encapsulation. The payload would then not be an administrative record,
with all the side effects you described in your recent email. Instead,
we'd have an extension block processor which deals with BiB, just as a
confidentiality ciphersuite does encryption. One advantage of this
approach is that the block can have the "relicate in every fragment"
flag set, so all fragments carry the BiB labeling (having the admin-
record information at the front of the payload means that it it's only
in the zero-offset fragment).

Regards.....Peter

From: "Peter Lovell" <[email-masked]>
To: <[email-masked]>, Susan <[email-masked]>
Cc: "Peter Lovell" <[email-masked]>
Subject: Re: [dtn-security] A comment on BSP draft -03
Date: Fri, 20 Apr 2007 13:22:45 -0400
Sender: [email-masked]
Reply-To: [email-masked]

Hi Susan,

On Fri, Apr 20, 2007, Symington, Susan F. <[email-masked]> wrote:

>
>1. The EID references could contain ZERO, one or two EIDs.

That's true. I guess I was thinking of the reference code implementation
which omits the field entirely if there are no entries.

>2. I dont' think you should call it bit 6.  Just call it by the flag
>name, in case the flags change place sometime in the BP.

I had suggested that BP include short names for these, in addition to
the very-long-winded-descriptive-labels-which-lose-people's-attention-as-
they-read-to-the-end. I'll catch this next time around.

>3. I don't think that using only the ordering of the EIDs is
>sufficient.  What if only one EID is present.  How does the node know
>whether this is the security-source or the security-destination? I
>think we need some other indicator to be able to tell the difference. 

This was a KISS call on my part when we were doing the suggestion. The
only extension blocks with two EIDs are security ones, and we already
have flags in the ciphersuite field to say which are present. It's like
moving those fields from the block-specific-data into the preamble --
the same rules apply. If there are two in the list, it's sec-source then
sec-dest just as it was previously in the block data. If there's only
one, the flags in ciphersuite tell you which, and the other is null,
just as it was previously. If the count is zero then they're both null.

No other blocks presently have more than one EID, so the issue does not
come up elsewhere. If/when new blocks are defined with more, they'll
have to include some way to deal with this.

I was mindful of this issue during the discussions, and tried to get
some way to simply define a null EID. That, of course, is not the same
as "dtn:none" but more like the usage in BSP where, for example, a null
sec-dest means that sec-dest is the bundle destination. Obviously this
is not at all the same as "dtn:none" as a destination.

My suggestion was to include a single NULL byte as the start of the
dictionary. That way, a reference of {0, 0} would be guaranteed to refer
to a null EID. Unfortunately that suggestion was not adopted, so if you
need a null EID in the list then you have to actually create one and add it.

Cheers.....Peter

Content-class: urn:content-classes:message
Date: Fri, 20 Apr 2007 10:55:31 -0400
From: "Symington, Susan F." <[email-masked]>
To: <[email-masked]>
Subject: [dtn-security] A comment on BSP draft -03
Sender: [email-masked]
Reply-To: [email-masked]

This is a multi-part message in MIME format.

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

Peter,=20

=20

Below are some comments on the following text from the version -03
draft of the BSP that you recently sent to dtn-dev:

=20

- EID references - composite field defined in [2] containing

      references to one or two EIDs.  Presence of EIDs is indicated by

      by the setting of bit 6 ("block contains an EID-reference field")

      of the block processing control flags.  If one or more is
present,

      flags in the ciphersuite ID field, described below, specify
which.

      The possible EIDs are, in order:-

=20

      - (optional) Security-source - specifies the security source for

      the service.  If this is omitted, then the source of the bundle
is

      assumed to be the security-source.

=20

      - (optional) Security-destination - specifies the security

      destination for the service.  If this is omitted, then the

      destination of the bundle is assumed to be the security-

      destination.

=20

      Both EID fields may be omitted, in which case the composite field

      itself is empty, as defined in [2].  In this case neither count

      nor references appear, and bit 6 is not set.

-------------------------------------------------------

=20

1. The EID references could contain ZERO, one or two EIDs.

2. I dont' think you should call it bit 6.  Just call it by the flag
name, in case the flags change place sometime in the BP.

3. I don't think that using only the ordering of the EIDs is
sufficient.  What if only one EID is present.  How does the node know
whether this is the security-source or the security-destination? I
think we need some other indicator to be able to tell the difference.=20

=20

-susan

=20

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

------_=_NextPart_001_01C7835B.F1981BCE
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.3059" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DArial>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
class=3D350125014-20042007><FONT face=3D"Courier New" size=3D2>Peter,=20
</FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
class=3D350125014-20042007><FONT face=3D"Courier New"=20
size=3D2></FONT></SPAN>&nbsp;</P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
class=3D350125014-20042007><FONT face=3D"Courier New" size=3D2>Below are =
some comments=20
on the following text from the version -03 draft of the BSP that you =
recently=20
sent to dtn-dev:</FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><FONT =
face=3D"Courier New"=20
size=3D2><SPAN class=3D350125014-20042007></SPAN></FONT>&nbsp;</P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><FONT =
face=3D"Courier New"=20
size=3D2>- EID references - composite field defined in [2] =
containing</FONT></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><FONT =
face=3D"Courier New"><FONT=20
size=3D2><SPAN style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN>references to one or two EIDs. <SPAN=20
style=3D"mso-spacerun: yes">&nbsp;</SPAN>Presence of EIDs is indicated=20
by</FONT></FONT></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><FONT =
face=3D"Courier New"><FONT=20
size=3D2><SPAN style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>by=20
the setting of bit 6 ("block contains an EID-reference =
field")</FONT></FONT></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><FONT =
face=3D"Courier New"><FONT=20
size=3D2><SPAN style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>of=20
the block processing control flags.<SPAN style=3D"mso-spacerun: =
yes">&nbsp;=20
</SPAN>If one or more is present,</FONT></FONT></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><FONT =
face=3D"Courier New"><FONT=20
size=3D2><SPAN style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN>flags in the ciphersuite ID field, described below, specify=20
which.</FONT></FONT></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><FONT =
face=3D"Courier New"><FONT=20
size=3D2><SPAN style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>The=20
possible EIDs are, in order:-</FONT></FONT></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><?xml:namespace =
prefix =3D o ns=20
=3D "urn:schemas-microsoft-com:office:office" /><o:p><FONT =
face=3D"Courier New"=20
size=3D2>&nbsp;</FONT></o:p></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><FONT =
face=3D"Courier New"><FONT=20
size=3D2><SPAN style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>-=20
(optional) Security-source - specifies the security source =
for</FONT></FONT></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><FONT =
face=3D"Courier New"><FONT=20
size=3D2><SPAN style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>the=20
service.<SPAN style=3D"mso-spacerun: yes">&nbsp; </SPAN>If this is =
omitted, then=20
the source of the bundle is</FONT></FONT></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><FONT =
face=3D"Courier New"><FONT=20
size=3D2><SPAN style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN>assumed to be the security-source.</FONT></FONT></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><o:p><FONT =
face=3D"Courier New"=20
size=3D2>&nbsp;</FONT></o:p></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><FONT =
face=3D"Courier New"><FONT=20
size=3D2><SPAN style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>-=20
(optional) Security-destination - specifies the =
security</FONT></FONT></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><FONT =
face=3D"Courier New"><FONT=20
size=3D2><SPAN style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN>destination for the service.<SPAN style=3D"mso-spacerun: =
yes">&nbsp;=20
</SPAN>If this is omitted, then the</FONT></FONT></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><FONT =
face=3D"Courier New"><FONT=20
size=3D2><SPAN style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN>destination of the bundle is assumed to be the=20
security-</FONT></FONT></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><FONT =
face=3D"Courier New"><FONT=20
size=3D2><SPAN style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN>destination.</FONT></FONT></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><o:p><FONT =
face=3D"Courier New"=20
size=3D2>&nbsp;</FONT></o:p></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><FONT =
face=3D"Courier New"><FONT=20
size=3D2><SPAN style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN>Both EID fields may be omitted, in which case the composite=20
field</FONT></FONT></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><FONT =
face=3D"Courier New"><FONT=20
size=3D2><SPAN style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN>itself is empty, as defined in [2].<SPAN style=3D"mso-spacerun: =
yes">&nbsp;=20
</SPAN>In this case neither count</FONT></FONT></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><FONT =
face=3D"Courier New"><FONT=20
size=3D2><SPAN style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>nor=20
references appear, and bit 6 is not set.</FONT></FONT></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
class=3D350125014-20042007><FONT face=3D"Courier New"=20
size=3D2>-------------------------------------------------------</FONT></=
SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
class=3D350125014-20042007><FONT face=3D"Courier New"=20
size=3D2></FONT></SPAN>&nbsp;</P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
class=3D350125014-20042007><FONT face=3D"Courier New" size=3D2>1. The =
EID references=20
could contain ZERO, one or two EIDs.</FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
class=3D350125014-20042007><FONT face=3D"Courier New" size=3D2>2. I =
dont' think you=20
should call it bit 6.&nbsp; Just call it by the flag name, in case the =
flags=20
change place sometime&nbsp;in the BP.</FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
class=3D350125014-20042007><FONT face=3D"Courier New" size=3D2>3. I =
don't think that=20
using only the ordering of the EIDs is sufficient.&nbsp; What if only =
one EID is=20
present.&nbsp; How does the node know whether this is the =
security-source or the=20
security-destination? I think we need some other indicator to be able to =
tell=20
the difference. </FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
class=3D350125014-20042007><FONT face=3D"Courier New"=20
size=3D2></FONT></SPAN>&nbsp;</P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
class=3D350125014-20042007><FONT face=3D"Courier New"=20
size=3D2>-susan</FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
class=3D350125014-20042007><FONT face=3D"Courier New"=20
size=3D2></FONT></SPAN>&nbsp;</P></FONT></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></BODY></HTML>

------_=_NextPart_001_01C7835B.F1981BCE--