[Sis-dtn] BPsec for CCSDS Updates

[Dr. Keith L Scott]

OK, now that we’re well-along with BPv7 and are waiting on ESA to provide draft text for high-speed-capable LTP, let’s see if we can move the BPsec book along.  In looking at the book with the latest comments, I think we’re not as far along as I’d thought (maybe in a good way: i.e. due to lots of good comments from the SEA-SEC folks), but certainly making progress.


  1.  Thanks to all the SEA-SEC folks who looked at the book.
  2.  I’ve accepted most comments, responded to a few, and have added some text on security associations vs. security contexts.  The main changes / open questions are listed below.

The current draft red book is in this directory: https://drive.google.com/drive/folders/1U8AyMBEDLT8U2mjowhK7B9ZJbtt6dcsF?usp=share_link

Definitions
We now just reference the definitions from the various normative reference documents instead of repeating them.

Security Contexts
I moved some text and added text to a SECURITY ASSOCIATIONS AND SECURITY CONTEXTS section in Section 2.  My hope is that this addresses the question on the difference between a SA and a security context, but we’ll see.

Authenticity
There were several questions around using the integrity service to provide authenticity.  I added some text saying that we’re following RFC9172 in referring to an integrity service, but that with appropriate mechanisms (e.g. digital signatures and the application of integrity to the primary block) that the integrity service may also provide data authenticity.  In a very few places I replaced “integrity” with “integrity / authenticity” to be explicit.

I could see using integrity protection without authentication for e.g. housekeeping telemetry or some other non-critical data.  I would think that integrity and authenticity would always be used for commanding, e.g.

Security Context Identifiers Registry
Are we OK requiring that folks create and register security context identifiers with IANA, or do we want to request that IANA delegate some of that registry space to SANA?

Annex D (CCSDS Security Context)
Does anybody want to take a cut at generating a default security context?  Can we just use the ones from RFC9173 (maybe profiling the key lengths)?  If nobody else will do it I’ll make something up here for folks to laugh at.

Annexes F and G
I suggest we take Mehmet’s comment and drop Annex F (Bundle Protocol Security Policy Considerations) (or rather, move it to the Green Book).  I think we should move Annex G (Service Specification for Bundle Protocol Security Policy) to the Green Book as well (we HAVE the service spec defined in CCSDS-style in section 4).

                                v/r,

                                --keith

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sis-dtn/attachments/20221118/c06cb540/attachment-0001.htm>