[Sis-dtn] RE: Securing the CCSDDS Bundle Protocol

[Burleigh, Scott C (312B)]

Hi, Keith.  My comments in-line below.

Scott

From: sis-dtn-bounces at mailman.ccsds.org [mailto:sis-dtn-bounces at mailman.ccsds.org] On Behalf Of Scott, Keith L.
Sent: Wednesday, June 17, 2015 9:26 AM
To: 'sis-dtn at mailman.ccsds.org'
Cc: Sheehe, Charles J. (GRC-LCA0); Howie Weiss (howard.weiss at sparta.com)
Subject: [Sis-dtn] Securing the CCSDDS Bundle Protocol

At the Spring meeting we started the work on a security protocol for the CCSDS Bundle Protocol.  While Dennis and Charles have been working that, we need to get some final consensus from the WG (and all the agencies we can) on what the actual requirements for the security services (in a protocol-agnostic way) are.

To that end, below is a bag of possible services.  Please look these over and let's select / refine the set that we think we need to support for the CCSDS BP Security protocol.  Note that this is not yet the trade of S/MIME vs. SBSP - first we need to establish the 'what it is we want'.


*       Protocol can distinguish between Sender of bundle and the Security-Sender

?  This enables a forwarding node to attach security mechanisms to a bundle.  It might be useful in missions where edge nodes reside on machines with limited power for crypto.  Potentially useful, but not a critical requirement.

*       Protocol provides security services which are; hop-by-hop basis

?  Needed to choke off DOS attacks.

*       Protocol provides security services which are; end-to-end basis

?  Needed, except note that the sending "end" might be a Security-Sender rather than the original source of the bundle.

*       Protocol provides security services which are hop-by-hop basis and End-to-end basis

?  I think this is covered by the preceding three bullets.

*       Protocol mechanisms secure information at rest

?  Mandatory.  Otherwise forwarding along a multi-agency path may be impossible.

*       Protocol provides a means to encrypt protocol elements so that messages in transit cannot practically be read

?  Needed.

*       Protocol supports pre-shared-keys (and/or known irrevocable certificates).

?  Needed.

*       Protocol provides a means to apply an integrity check to a bundle so that the identity of the security-sender can be established and changes in sensitive parts of the message can be detected.

?  I think what is needed is a means of integrity-checking any block(s) of a bundle, not the bundle as a whole.

*       Protocol allows combination of confidentiality and integrity services

?  Both confidentiality and integrity services may be needed for any single bundle.  Is that what this means?

*       Protocol prevents changing the intended destination

?  Needed.

*       Protocol prevents falsifying a bundle's source

?  Needed.

*       Protocol prevents changing a bundle's control fields

?  In general, the protocol needs to prevent changing anything in the primary block.

*       Protocol prevents changing other block or payload fields

?  Needed.

*       Protocol prevents replay of bundles

?  Not needed.  Bundles have IDs, and duplicate arrival of bundles is already possible.  Applications need to provide their own application-specific safeguards here.

*       Protocol prevents copying or disclosing bundle data as it passes

?  Not needed.  If encryption is supported then this is moot.

*       Protocol is a Standard

?  If not already a standard, the protocol must have strong prospects of becoming a standard.

*       Protocol has implementations

?  If not already implemented, implementation of the protocol must be affordable.

We need to move out on this, so I'm going to ask people to comment by COB next Monday.  You can say yes or no to the services above and/or propose new ones.  I'll set up a telecon at a mutually-inconvenient time next Tuesday.

                        --keith

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sis-dtn/attachments/20150619/b14bb882/attachment.html>