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

[Stephen Farrell <[e-mail]>]

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.