Subject: [dtn] BP Security Protocol Discussion Coordination

From: Keith Scott <[email-masked]>
Date: Mon, 31 Aug 2015 16:46:07 -0400

Greetings,

The Consultative Committee for Space Data Systems (CCSDS) working group
that is standardizing a Bundle Protocol suite for space communications is
currently working on a security protocol.  While our first notion was to
simply take a simplified profile of BSP (something very akin to an SBSP
implementation geared towards RFC5050), there has been some discussion of
using cryptographic message syntax (CMS) as the mechanism.  This suggestion
was driven mainly (speaking for members of the CCSDS Security WG here, so
please correct me if I'm wrong) based on the fact that CMS is
widely-deployed and has lots of good implementations.

Even if one chooses to use CMS, there are several ways in which it might be
implemented as a security mechanism for BP.  I believe the consensus in
CCSDS is that there is a strong desire:

   - To not change the underlying structure of the bundle protocol (i.e. a
   series of BP blocks).  That is, we can't just encapsulate each block in a
   security envelope.  This means that nodes don't HAVE to be able to dig down
   into CMS envelopes to get at bundle content, e.g.
   - To not require implementation of the security mechanisms by all
   nodes.  That is, it would be good if a node could receive a bundle
   containing security-protected blocks (esp. integrity and/or authentication,
   information that could be in-the-clear in the BP) and process / forward the
   bundle (albeit without the benefit of the security services).

To that end, I believe the overall consensus of the CCSDS group is coming
to:

   - Maintain the basic framework of (S)BSP, where security blocks contain
   security-specific information and reference 'in-the-clear' bundle blocks
   (i.e. the blocks to which security services have been applied are carried
   in the same format as if they did not have security services applied to
   them).  Use of CMS would involve defining a (set of) CMS-specific security
   block type(s).
   - I think it might be an open question as to whether a
   confidentiality-protected payload block could use CMS envelope
   encapsulation or if it might be implemented as the (notional) other types
   of services for other blocks, i.e. a special security block type containing
   the crypto-specific material (e.g. initialization vector) and a reference
   to the encrypted payload content.

This email
<http://mailman.ccsds.org/pipermail/sis-dtn/2015-August/000551.html> from
the CCSDS sis-dtn list contains much of the discussion.

We have some flexibility, since CCSDS doesn't HAVE to follow what the IETF
WG does w.r.t. security, just as the IETF is under no obligation to follow
CCSDS.  That is, I see the two groups as being 'loosely coupled' -- what I
would like to do is to ensure that each community is aware of what the
other is doing and that CCSDS, as the smaller organization, can make
progress in their specialized environment in the context of DTN while
leveraging the work of the IETF WG.  I'm cross-posing here in response to
an email by Stephen Farrell suggesting that the two groups might want to
know what each other are doing.

Finally, the above represents my interpretation of a lot of work /
discussion by several members of the CCSDS community.  Particular thanks go
to Jeremy Mayer of DLR, Dr. Ed Birrane of JHU/APL, and Charles Sheehe and
Dennis Iannicca of NASA Glenn Research Center, among others.  Any errors in
the above are mine, all good ideas are probably theirs.

  --Keith