Re: [dtn-security] bundle security protocol changes...

[Scott Burleigh <[e-mail]>]

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