Subject: Re: [dtn-security] bundle security protocol changes...
From: Scott Burleigh <[email-masked]>
To: [email-masked]
Cc: "Susan F. Symington" <[email-masked]>, Howard Weiss <[email-masked]>
Date: Wed, 07 Dec 2005 13:25:53 -0800
List-Id: DTN Security Discussion <dtn-security.mailman.dtnrg.org>

Stephen Farrell wrote:

> Folks,
>
> Susan, Howie and I just had a call (thanks skype!) about things
> to do with the next rev of the bundle security draft [1] and
> the list below are my rough notes about the main changes we're
> planning. We'd welcome any comments before doing the I-D
> production donkey-work:-)
>
> We're aiming a bit optimisitically at having -01 out before
> the holidays.
>
> Cheers,
> Stephen.
>
> [1] http://tools.ietf.org/id/draft-irtf-dtnrg-bundle-security-00.txt
>
> - Align terminology with the latest bundle spec.
>
> - Allow a header to follow the payload in order to carry
> signatures and MACs. I think the easiest way to do that
> is to just let it be defined per ciphersuite, so that e.g.
> HMAC-in-front would be a different ciphersuite from
> HMAC-at-the-end (which would require two BAH/PSH headers
> in the bundle). Security result is therefore also
> optional in an ASH and we add a bit to indicate its
> presence.
>
> - I think that we ought to allow more bits for the
> ciphersuite say adding another byte to get 13 bits.
>
> - Accomodate the changed SDNV. Some fields (e.g.
> security result) will now be an SDNV encoded length
> followed by the required number of octets.
>
> - Define a type for this header since its no longer
> in the bundle spec. I guess '2' is fine?

Sure.  Or, as you point out in your response to Mike, maybe '2' and '3' 
and '4' because you've got three new header types.

> I don't think
> an ASH needs an overall length since the flags and
> thereafter individual optional fields each specify
> their own lengths.

I think we're now all agreed that all of these headers need header data 
length (and also header processing control flags), as per 3.1 of the 
Bundle Protocol spec.

> - C14N. I dunno what to do here yet. This might have
> to wait on someone coding it all up to be something we
> can do correctly. But we'll probably think of stuff
> as we edit it.
>
> - Since the bundle spec has gotten rid of most of
> its API stuff, can we do the same?

I would say Sure.

> - Deal with combinations of PSH/BAH & CH. There's
> more needed there:
>
> - Just for a starter let's say that we add a new field
> to the ASH so we can correlate the front-end and rear-end
> pairs (say if >1 PSH is applied). We could call that
> the 'marker' and make it optional for the 1st
> application of an ASH - all subsequent ASH's would
> have to include a unique marker. (Might a counter
> be better?)
>
> - Next for CH we include the enciphered payloads in
> the additional CH header. What I mean is that the
> first CH of a (marker-matching-set) should contain
> the keying material and subsequent ones should contain
> (n the security result field) the ciphertext (e.g.
> encrypted payloads). A single CH can contain
> ciphertext for >1 header. The 1st CH can also contain
> ciphertext for some headers.
>
> - PSH and CH service (with markers) can be applied to
> any headers you like in the obvious way, except that
> each service applicaiton has to envelope the others.
>
> - One exception is that if you're using a signature
> ciphersuite then if subsequent encryption has to include
> both the signed data and the signature and not just
> the signed data.
>
> - And since that's all very complicated, we mandate
> support for only one of each type of ciphersuite (or
> even fewer), and we also mandate that nodes only
> need support say one level of combining. Other nodes
> could of course do more, but that'd be subject to
> further specification/profiling in some other RFC.

This sounds okay to me, Stephen.

Scott

Date: Tue, 06 Dec 2005 20:22:49 +0000
From: Stephen Farrell <[email-masked]>
To: [email-masked]
CC: "Susan F. Symington" <[email-masked]>, Howard Weiss <[email-masked]>
Subject: Re: [dtn-security] bundle security protocol changes...
Sender: [email-masked]
Reply-To: [email-masked]

Hi Mike,

Michael Demmer wrote:
>>- Allow a header to follow the payload in order to carry
>>signatures and MACs. I think the easiest way to do that
>>is to just let it be defined per ciphersuite, so that e.g.
>>HMAC-in-front would be a different ciphersuite from
>>HMAC-at-the-end (which would require two BAH/PSH headers
>>in the bundle). Security result is therefore also
>>optional in an ASH and we add a bit to indicate its
>>presence.
> 
> Can you briefly explain why two BAH/PSH headers are required for the
> case where the sig/MAC follows the payload. This may be obvious but I
> don't get it.

So the ciphersuite is up-front, so a node with only small buffers can
still handle large bundles. Using the same header type before and
after is just one possible design, but seems simplest to me given
the way we'll be mixing multiple applications of security headers
later on.

> Also, just so we're on the same page, the rational for having the sig
> at the end is that you can start sending the payload bits before
> you've calculated the signature on the whole thing? As such you don't
> need to pull the whole payload into memory, generate the MAC, then
> send the MAC and send the payload?

Yes, exactly. Its for nodes with small buffers who handle large
bundles (or where scaling creates the same effect).

>>- Define a type for this header since its no longer
>>in the bundle spec. I guess '2' is fine? I don't think
>>an ASH needs an overall length since the flags and
>>thereafter individual optional fields each specify
>>their own lengths.
> 
> 
> But for implementations that don't include the security support, we
> need these headers to follow the standard header preamble (with
> length) so they can be skipped when processing the bundle.

Very true. And I'd forgotten about it. (Susan had also pointed
out that we need three different header values for BAH, PSH and CH
too.) Thanks for catching that.

[...]

> For the above points, I'm too far removed to understand all of what
> you're proposing to even begin to comment :)

Yep they're just abbreviated notes. Basically though what we want to
be able to eventually support is something a bit like a mixture of
s/mime's ability to forward encrypted mail adding a new signature
and a sequence of VPN tunnels. Clearly some ascii-art is needed.

Stephen.

Date: Tue, 6 Dec 2005 11:02:44 -0800
From: Michael Demmer <[email-masked]>
To: [email-masked]
Cc: "Susan F. Symington" <[email-masked]>, Howard Weiss <[email-masked]>
Subject: Re: [dtn-security] bundle security protocol changes...
Sender: [email-masked]
Reply-To: [email-masked]

> - Allow a header to follow the payload in order to carry
> signatures and MACs. I think the easiest way to do that
> is to just let it be defined per ciphersuite, so that e.g.
> HMAC-in-front would be a different ciphersuite from
> HMAC-at-the-end (which would require two BAH/PSH headers
> in the bundle). Security result is therefore also
> optional in an ASH and we add a bit to indicate its
> presence.

Can you briefly explain why two BAH/PSH headers are required for the
case where the sig/MAC follows the payload. This may be obvious but I
don't get it.

Also, just so we're on the same page, the rational for having the sig
at the end is that you can start sending the payload bits before
you've calculated the signature on the whole thing? As such you don't
need to pull the whole payload into memory, generate the MAC, then
send the MAC and send the payload?

> - Define a type for this header since its no longer
> in the bundle spec. I guess '2' is fine? I don't think
> an ASH needs an overall length since the flags and
> thereafter individual optional fields each specify
> their own lengths.

But for implementations that don't include the security support, we
need these headers to follow the standard header preamble (with
length) so they can be skipped when processing the bundle.

> - C14N. I dunno what to do here yet. This might have
> to wait on someone coding it all up to be something we
> can do correctly. But we'll probably think of stuff
> as we edit it.
> 
> - Since the bundle spec has gotten rid of most of
> its API stuff, can we do the same?
> 
> - Deal with combinations of PSH/BAH & CH. There's
> more needed there:
> 
> - Just for a starter let's say that we add a new field
> to the ASH so we can correlate the front-end and rear-end
> pairs (say if >1 PSH is applied). We could call that
> the 'marker' and make it optional for the 1st
> application of an ASH - all subsequent ASH's would
> have to include a unique marker. (Might a counter
> be better?)
> 
> - Next for CH we include the enciphered payloads in
> the additional CH header. What I mean is that the
> first CH of a (marker-matching-set) should contain
> the keying material and subsequent ones should contain
> (n the security result field) the ciphertext (e.g.
> encrypted payloads). A single CH can contain
> ciphertext for >1 header. The 1st CH can also contain
> ciphertext for some headers.
> 
> - PSH and CH service (with markers) can be applied to
> any headers you like in the obvious way, except that
> each service applicaiton has to envelope the others.
> 
> - One exception is that if you're using a signature
> ciphersuite then if subsequent encryption has to include
> both the signed data and the signature and not just
> the signed data.
> 
> - And since that's all very complicated, we mandate
> support for only one of each type of ciphersuite (or
> even fewer), and we also mandate that nodes only
> need support say one level of combining. Other nodes
> could of course do more, but that'd be subject to
> further specification/profiling in some other RFC.

For the above points, I'm too far removed to understand all of what
you're proposing to even begin to comment :)

-m

Date: Tue, 06 Dec 2005 17:49:25 +0000
From: Stephen Farrell <[email-masked]>
To: [email-masked]
Cc: "Susan F. Symington" <[email-masked]>, Howard Weiss <[email-masked]>
Subject: [dtn-security] bundle security protocol changes...
Sender: [email-masked]
Reply-To: [email-masked]

Folks,

Susan, Howie and I just had a call (thanks skype!) about things
to do with the next rev of the bundle security draft [1] and
the list below are my rough notes about the main changes we're
planning. We'd welcome any comments before doing the I-D
production donkey-work:-)

We're aiming a bit optimisitically at having -01 out before
the holidays.

Cheers,
Stephen.

[1] http://tools.ietf.org/id/draft-irtf-dtnrg-bundle-security-00.txt

- Align terminology with the latest bundle spec.

- Allow a header to follow the payload in order to carry
signatures and MACs. I think the easiest way to do that
is to just let it be defined per ciphersuite, so that e.g.
HMAC-in-front would be a different ciphersuite from
HMAC-at-the-end (which would require two BAH/PSH headers
in the bundle). Security result is therefore also
optional in an ASH and we add a bit to indicate its
presence.

- I think that we ought to allow more bits for the
ciphersuite say adding another byte to get 13 bits.

- Accomodate the changed SDNV. Some fields (e.g.
security result) will now be an SDNV encoded length
followed by the required number of octets.

- Define a type for this header since its no longer
in the bundle spec. I guess '2' is fine? I don't think
an ASH needs an overall length since the flags and
thereafter individual optional fields each specify
their own lengths.

- C14N. I dunno what to do here yet. This might have
to wait on someone coding it all up to be something we
can do correctly. But we'll probably think of stuff
as we edit it.

- Since the bundle spec has gotten rid of most of
its API stuff, can we do the same?

- Deal with combinations of PSH/BAH & CH. There's
more needed there:

- Just for a starter let's say that we add a new field
to the ASH so we can correlate the front-end and rear-end
pairs (say if >1 PSH is applied). We could call that
the 'marker' and make it optional for the 1st
application of an ASH - all subsequent ASH's would
have to include a unique marker. (Might a counter
be better?)

- Next for CH we include the enciphered payloads in
the additional CH header. What I mean is that the
first CH of a (marker-matching-set) should contain
the keying material and subsequent ones should contain
(n the security result field) the ciphertext (e.g.
encrypted payloads). A single CH can contain
ciphertext for >1 header. The 1st CH can also contain
ciphertext for some headers.

- PSH and CH service (with markers) can be applied to
any headers you like in the obvious way, except that
each service applicaiton has to envelope the others.

- One exception is that if you're using a signature
ciphersuite then if subsequent encryption has to include
both the signed data and the signature and not just
the signed data.

- And since that's all very complicated, we mandate
support for only one of each type of ciphersuite (or
even fewer), and we also mandate that nodes only
need support say one level of combining. Other nodes
could of course do more, but that'd be subject to
further specification/profiling in some other RFC.