Subject: Re: [dtn-security] Detail of PSB change...
From: "Peter Lovell" <[email-masked]>
To: "Stephen Farrell" <[email-masked]>
Cc: <[email-masked]>, "Peter Lovell" <[email-masked]>
Date: Fri, 23 Feb 2007 10:31:54 -0500
List-Id: DTN Security Discussion <dtn-security.mailman.dtnrg.org>

>
>In a mail to dtn-interest I said:
>
> > PS: I'm not saying the current BSP spec has got this correct, it
> > probably needs fixing in a few ways. But I do think we can do that
> > in the BSP spec and not re-open the BP spec. E.g. perhaps we need
> > to add a optional "signature number" to the current PSB ciphersuite,
> > with the meaning that this is the n-th signature added or something.
>
>I just had a maybe-better/maybe-worse idea:
>
>We could add a "signature layer" value s.t. signatures with layer
>N cover all PSBs with layer < N. I think that's cute and maybe
>useful, but we'll have to think through the semantics.
>
>S.

Hi Stephen,

my thinking had been in that general direction. I hadn't included it in
my message as I wanted that to be mainly a description of the problem,
and not so much a speculation on possible solutions.

Rather than a "signature layer", I might call it a "layer identifier"
and apply it to all security blocks. For concreteness, let's think of it
as a one-byte field, although there is a scenario where we might need it
larger. [note 1]

Layers would be conceptually wrapped around the payload block. If you
add a new layer, its number is one greater than the largest number you
have already. You add the block (conceptually) at the front, just after
the primary. [note 2]

You can only remove or modify the outermost layer (can be recursive, though). 

The downside is that the numbers are only on security blocks, so we can
only deal with them, plus primary and payload itself, of course. We must
ignore all other extension blocks [note 3]. This is the current
situation with BSP but we had been hoping to extend coverage to metadata
- I'm not sure if we can do that now.

Regards.....Peter

Note 1: we might need this in the case of adding blocks to fragment-
bundles, so we can differentiate between them when it comes time to
reassemble the bundle

Note 2: If you use a correlated block you add that at the back as the
last block. If you have several correlated blocks, they must all
conceptually follow the payload. This is a change for Confidentiality
suite #3, by the way, but workable. We can order the multiple correlated
blocks using the scheme we discussed a couple of days ago.

Note 3: for payload security and confidentiality ciphersuites. We can
solve the problem for bundle authentication ciphersuites, so all blocks
can be included in that digest process.

Date: Fri, 23 Feb 2007 14:02:01 +0000
From: Stephen Farrell <[email-masked]>
To: [email-masked]
Subject: [dtn-security] Detail of PSB change...
Sender: [email-masked]
Reply-To: [email-masked]

In a mail to dtn-interest I said:

 > PS: I'm not saying the current BSP spec has got this correct, it
 > probably needs fixing in a few ways. But I do think we can do that
 > in the BSP spec and not re-open the BP spec. E.g. perhaps we need
 > to add a optional "signature number" to the current PSB ciphersuite,
 > with the meaning that this is the n-th signature added or something.

I just had a maybe-better/maybe-worse idea:

We could add a "signature layer" value s.t. signatures with layer
N cover all PSBs with layer < N. I think that's cute and maybe
useful, but we'll have to think through the semantics.

S.

From: "Peter Lovell" <[email-masked]>
To: <[email-masked]>, Susan <[email-masked]>
Cc: "Howard Weiss" <[email-masked]>
Subject: Re(2): [dtn-security] BSP questions
Date: Tue, 6 Feb 2007 09:41:36 -0500
Sender: [email-masked]
Reply-To: [email-masked]

Hi Susan,

this is as I expected, and how I have been doing the implementation. I
thought I'd check, though, as strictly end-to-end would make a few
things easier. Worth a try :)

Cheers.....Peter

p.s. yes - clarifying text in the spec would be good

>I believe that the term "end-to-end" here was intended to mean from
>security source to security destination, where the security source is
>not necessarily the source of the bundle, and the security destination
>is not necessarily the destination of the bundle. This
>"end-to-endishness" is described in more detail in the Security
>Overview document. An end-to-end ciphersuite is distinguished from a
>"hop-by-hop" ciphersuite by the fact that the hop-by-hop ciphersuite is
>only intended to be used between adjacent nodes and never across
>multiple nodes. 
>
>To avoid others having the same question as you, it seems we should add
>some clarifying text to explain this, because the BSP is normative
>whereas the Security Overview is not.
>
>-susan
>*****************************************************************
>Susan Symington
>The MITRE Corporation
>[email-masked]
>703-983-7209 (voice)
>703-983-7142 (fax)
>******************************************************************
> 
>
>>-----Original Message-----
>>From: [email-masked] 
>>[mailto:[email-masked]] On Behalf Of Peter
>Lovell
>>Sent: Tuesday, February 06, 2007 8:31 AM
>>To: [email-masked]
>>Cc: Howard Weiss
>>Subject: [dtn-security] BSP questions
>>
>>a question arising from doing the implementation ...
>>
>>Bundle security spec 2.3 description for PS includes the statement
>>"The ciphersuite ID MUST be documented as an end-to-end
>authentication-
>>ciphersuite or as an end-to-end error-detection-ciphersuite."
>>
>>Is it the intent that PS is only ever end-to-end? It can never be
>added
>>at intermediate points such as a bastion gateway. Gateway-to-gateway
>>would be done using encapsulation (tunneling), so the gateway would be
>>the source for the encapsulated bundle. If this is the intent then
>>several other issues no longer exist.
>>
>>Thanks.....Peter
>>

Content-class: urn:content-classes:message
Subject: RE: [dtn-security] BSP questions
Date: Tue, 6 Feb 2007 09:33:09 -0500
From: "Symington, Susan F." <[email-masked]>
To: <[email-masked]>
Cc: "Howard Weiss" <[email-masked]>
Sender: [email-masked]
Reply-To: [email-masked]

I believe that the term "end-to-end" here was intended to mean from
security source to security destination, where the security source is
not necessarily the source of the bundle, and the security destination
is not necessarily the destination of the bundle. This
"end-to-endishness" is described in more detail in the Security
Overview document. An end-to-end ciphersuite is distinguished from a
"hop-by-hop" ciphersuite by the fact that the hop-by-hop ciphersuite is
only intended to be used between adjacent nodes and never across
multiple nodes. 

To avoid others having the same question as you, it seems we should add
some clarifying text to explain this, because the BSP is normative
whereas the Security Overview is not.

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

>-----Original Message-----
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of Peter
Lovell
>Sent: Tuesday, February 06, 2007 8:31 AM
>To: [email-masked]
>Cc: Howard Weiss
>Subject: [dtn-security] BSP questions
>
>a question arising from doing the implementation ...
>
>Bundle security spec 2.3 description for PS includes the statement
>"The ciphersuite ID MUST be documented as an end-to-end
authentication-
>ciphersuite or as an end-to-end error-detection-ciphersuite."
>
>Is it the intent that PS is only ever end-to-end? It can never be
added
>at intermediate points such as a bastion gateway. Gateway-to-gateway
>would be done using encapsulation (tunneling), so the gateway would be
>the source for the encapsulated bundle. If this is the intent then
>several other issues no longer exist.
>
>Thanks.....Peter
>
>_______________________________________________
>dtn-security mailing list
>[email-masked]
>http://mailman.dtnrg.org/mailman/listinfo/dtn-security
>

From: "Peter Lovell" <[email-masked]>
To: <[email-masked]>
Cc: "Howard Weiss" <[email-masked]>
Date: Tue, 6 Feb 2007 08:58:34 -0500
Subject: [dtn-security] more BSP questions
Sender: [email-masked]
Reply-To: [email-masked]

Hi all,

are there any suggestions on what we should use for the key-derivation-
function (KDF) mentioned near the end of section 4.3 of security spec?

Paragraph 4 of the section says that there may be an optional key
identifier in the security parameters. If there is, does the security
result still contain the encrypted key? Or should this paragraph say
that we have one or the other, but not both?

Finally, I don't see any specification of key size for AES. I assume
that we therefore should infer that from the key provided. Is this the intent?

Thanks.....Peter

From: "Peter Lovell" <[email-masked]>
To: <[email-masked]>
Cc: "Howard Weiss" <[email-masked]>
Date: Tue, 6 Feb 2007 08:31:29 -0500
Subject: [dtn-security] BSP questions
Sender: [email-masked]
Reply-To: [email-masked]

a question arising from doing the implementation ...

Bundle security spec 2.3 description for PS includes the statement
"The ciphersuite ID MUST be documented as an end-to-end authentication-
ciphersuite or as an end-to-end error-detection-ciphersuite."

Is it the intent that PS is only ever end-to-end? It can never be added
at intermediate points such as a bastion gateway. Gateway-to-gateway
would be done using encapsulation (tunneling), so the gateway would be
the source for the encapsulated bundle. If this is the intent then
several other issues no longer exist.

Thanks.....Peter