[Sis-dtn] RE: CCSDS BP Security Trade Status
Sheehe, Charles J. (GRC-LCA0)
charles.j.sheehe at nasa.gov
Mon Aug 31 19:39:56 UTC 2015
Hi
CMS please.
So we are going to allow CMS as a payload and modify SBSP to allow CCB block is that what we are saying?
1) CMS in a payload: No changes to DTN BP, No changes to SBSP
2) CMS block type: Change to SBSP Additional block, CCB: 0x05
Skip 3)
Just wish to get consensus on what is going to be done.
I just want to get it recorded, so we it is clear.
Then we can specify the data formats.
Thanks
Chuck
Charles J. Sheehe III
Electronics Engineer
System Architectures and Networks Branch
21000 Brookpark Rd
Cleveland, OH 44135
Charles.J.Sheehe at nasa.gov
Office: 216-433-5179
-----Original Message-----
From: Jeremy.Mayer at dlr.de [mailto:Jeremy.Mayer at dlr.de]
Sent: Monday, August 31, 2015 3:10 PM
To: Burleigh, Scott C (JPL-312B)[Jet Propulsion Laboratory]; Iannicca, Dennis C. (GRC-LCA0); Edward.Birrane at jhuapl.edu; stephen.farrell at cs.tcd.ie; Sheehe, Charles J. (GRC-LCA0)
Cc: kscott at mitre.org; susan at mitre.org; plovell at mac.com; Howard.Weiss at parsons.com; sis-dtn at mailman.ccsds.org
Subject: RE: CCSDS BP Security Trade Status
I agree,
It might be a good idea to start considering the canonical representation now, so that we can merge that into the encoding documents. I would say that either using a key:value pair with UTF8 strings for key and pre-defined types for value -OR- a sort of MID structure, with a MID:pre-defined type structure.
________________________________________
From: Burleigh, Scott C (312B) [scott.c.burleigh at jpl.nasa.gov]
Sent: Monday, August 31, 2015 9:05 PM
To: Mayer, Jeremy; dennis.c.iannicca at nasa.gov; Edward.Birrane at jhuapl.edu; stephen.farrell at cs.tcd.ie; charles.j.sheehe at nasa.gov
Cc: Scott, Keith L (9730-Affiliate); susan at mitre.org; plovell at mac.com; Howard.Weiss at parsons.com; sis-dtn at mailman.ccsds.org
Subject: RE: CCSDS BP Security Trade Status
A note on the multi-representation concept that is brewing in the IETF WG concept: my expectation, based on my understanding of where we ended up in the telecon last Friday, is that:
1. All BSP security results would be computed upon a "security-canonical" representation of the subject data.
2. But then the security results themselves would always be serialized in whichever transmission representation was applicable over the next hop, just like everything else (including the other fields of the abstract security block).
No deliberations yet on just what this security-canonical representation would be.
Scott
-----Original Message-----
From: Jeremy.Mayer at dlr.de [mailto:Jeremy.Mayer at dlr.de]
Sent: Monday, August 31, 2015 11:19 AM
To: dennis.c.iannicca at nasa.gov; Edward.Birrane at jhuapl.edu; stephen.farrell at cs.tcd.ie; charles.j.sheehe at nasa.gov
Cc: Scott, Keith L (9730-Affiliate) <kscott at mitre.org>; Burleigh, Scott C (312B) <scott.c.burleigh at jpl.nasa.gov>; susan at mitre.org; plovell at mac.com; Howard.Weiss at parsons.com; sis-dtn at mailman.ccsds.org
Subject: RE: CCSDS BP Security Trade Status
Dennis,
Before I go on (and for everyone who is just tuning in), a summary of the use cases for CMS (from earlier in the thread, helpfully provided by Charles):
1) CMS in a payload: No changes to DTN BP, No changes to SBSP
2) CMS block type: Change to SBSP Additional block, CCB: 0x05
3) CMS in a current block: BCB; CMS processing flag, Change to SBSP
For case 1), I think that this is largely solved with few caveats, the largest being that (for 5050) it's totally unnecessary to use the textual S/MIME form as opposed to encoding the whole thing as BER/DER and pushing it down the wire.
For case 2), we need to add a block type, and devise a way to store which blocks are being referenced within the CMS operations. I propose that we add an attribute type, but the "indvidual block identifier" is still something which is up in the air... It would certainly be helpful.
For case 3) At this point in time, I think this is unnecessary, as we can use the CMS block.... Agreed?
Your assumptions in regards to the signed and enveloped data types are correct, hence the attribute type(s). In addition, my rationale in regards to the CMS/SBSP interoperability standards is that CMS certainly has higher overhead, compared to SBSP. Now, for many applications, I don't think this is an issue, but for certain ones (such as sensor networks, deep-space, insert your favorite bandwidth-constrained application here) using SBSP might be enough. For these cases, we should guarantee a baseline supported set of cipher suites which nodes utilizing both standards will support. Following the concept which the IETF WG is following, I think it's also worthwhile to use that suite to allow interoperability between the standards, e.g. where a CMS-signed bundle (encoded in whichever encoding) can be reduced to 5050/SBSP, if required. I have no problem writing a CMS block section, but would defer back to the group in order so specify such a suite, as my experience of implementing crypto on spacecrafts is non-existent... Dennis, want to take that on? Or is this something that should be debated in the longer-term.
Thanks,
Jeremy
________________________________________
From: Iannicca, Dennis C. (GRC-LCA0) [dennis.c.iannicca at nasa.gov]
Sent: Saturday, August 29, 2015 12:15 AM
To: Mayer, Jeremy; 'Birrane, Edward J.'; stephen.farrell at cs.tcd.ie; Sheehe, Charles J. (GRC-LCA0)
Cc: Scott, Keith L.; Burleigh, Scott C (JPL-312B)[Jet Propulsion Laboratory]; Symington, Susan F.; plovell at mac.com; Howard.Weiss at parsons.com; sis-dtn at mailman.ccsds.org
Subject: Re: CCSDS BP Security Trade Status
Jeremy,
I missed this message in the original thread I read so if you have some ideas already you want to draft up for an SBSP section I'll defer to you on that since you've already been experimenting with it. The more I've been reading through the full thread, the more I'm having difficulty envisioning how much CMS and SBSP really need to co-exist in a single specification though.
You've already demonstrated signing and encrypting data end-to-end and embedding that into a bundle payload. Does the process really need to be more complicated than that? For a user that is interested in protecting their data from modification or eavesdropping that takes care of the problem and is simple to implement without needing to change any existing gateway implementations. It totally decouples the data security from the protocol and you could just as easily replace CMS with PGP/GPG to follow the e-mail analogy.
Now on the flip side, even with that said, I can still see a case for tying CMS into SBSP in certain cases. I suppose I could see duplicating the functionality of the SBSP BAB to authenticate an entire bundle by using a CMS Authenticated-Data type, but haven't there been discussions about decoupling BAB and BSP and moving that function to the convergence layer?
That still leaves BIB and BCB which have a useful characteristic in that they can operate over any specified target blocks. I believe the thinking in this thread was that you would retain all of the CMS fields from the Signed-Data and Enveloped-Data types, but your implementation would replace the encapsulated data and encrypted data fields respectively with pointers to a block specified in the "target block" ASB header field. Is that a correct assumption?
On 8/26/15, 5:46 AM, "Mayer, Jeremy P. (JSC-OT/ESA)[EUROPEAN SPACE AGENCY]" <jeremy.mayer at dlr.de> wrote:
>I can do a preliminary draft in the next week or two. There is still
>one open item from my side: How do we describe which block that a CMS
>block is acting upon, in the cases where we're doing so. I would
>suggest that we create a CMS attribute which does so, as that fits
>within the spirit of CMS.
>Any other ideas?
>
>In terms of other next steps, I/we can modify CMSProxy in order to test
>a CMS block, though it would take some (larger amount of work) to
>actually integrate that into ION, work that I won't have time for until
>November at the earliest.
>
>Thanks,
>Jeremy
>
>-
>
>-----Original Message-----
>From: Birrane, Edward J. [mailto:Edward.Birrane at jhuapl.edu]
>Sent: Dienstag, 25. August 2015 23:16
>To: stephen.farrell at cs.tcd.ie; charles.j.sheehe at nasa.gov
>Cc: kscott at mitre.org; jeremy.mayer at dlr.de;
>sis-dtn-owner at mailman.ccsds.org; scott.c.burleigh at jpl.nasa.gov;
>susan at mitre.org; plovell at mac.com; Howard.Weiss at parsons.com
>Subject: RE: RE: CCSDS BP Security Trade Status
>
>I am currently editing an sbsp-01 internet-draft, but would welcome a
>co-author to write up the CMS block. Would like to have something out
>and used as a basis for discussion in the next 3 weeks.
>
>-Ed
>
>---
>Edward J. Birrane, III, Ph.D.
>Embedded Applications Group Supervisor
>Space Exploration Sector
>Johns Hopkins Applied Physics Laboratory
>(W) 443-778-7423 / (F) 443-228-3839
>
>
>
>> -----Original Message-----
>> From: stephen.farrell at cs.tcd.ie [mailto:stephen.farrell at cs.tcd.ie]
>> Sent: Tuesday, August 25, 2015 12:49 PM
>> To: charles.j.sheehe at nasa.gov
>> Cc: Birrane, Edward J.; kscott at mitre.org; jeremy.mayer at dlr.de;
>> sis-dtn- owner at mailman.ccsds.org; scott.c.burleigh at jpl.nasa.gov;
>> susan at mitre.org; plovell at mac.com; Howard.Weiss at parsons.com
>> Subject: Re: RE: CCSDS BP Security Trade Status
>>
>>
>>
>> On Tue Aug 25 17:26:21 2015 GMT+0100, Sheehe, Charles J. (GRC-LCA0)
>> wrote:
>> > Hi
>> > As I understand what was agreed to;
>> >
>> > We are going to change the SBSP to include a new block & Update,
>> > Security
>> implementations.
>> > Specify a Sub set of SBSP/CMS interoperability guidance for cipher
>> > suites;
>> RNG's, as well as cryptographic and digest algorithms DTN is going to
>> support across SBSP and CMS.
>> >
>> > "CMS Block would be an extension block followed by CMS content.
>> > **CMS block
>> > > type: Change to SBSP Additional block, CCB: 0x05?"
>> >
>> >
>> > Any corrections?
>>
>> Just that there is an active ietf wg on the topic that ought be part
>> of
>this.
>>
>> S.
>>
>> >
>> > If none what is our next step
>> >
>> > Chuck
>> >
>> >
>> > Charles J. Sheehe III
>> > Electronics Engineer
>> > System Architectures and Networks Branch 21000 Brookpark Rd
>> > Cleveland, OH 44135 Charles.J.Sheehe at nasa.gov
>> > Office: 216-433-5179
>> >
>> >
>> > -----Original Message-----
>> > From: Weiss, Howard [mailto:Howard.Weiss at parsons.com]
>> > Sent: Tuesday, August 25, 2015 11:22 AM
>> > To: Birrane, Edward J.; Sheehe, Charles J. (GRC-LCA0); Scott, Keith
>> > L.; Mayer, Jeremy P. (JSC-OT/ESA)[EUROPEAN SPACE AGENCY];
>> > sis-dtn-owner at mailman.ccsds.org; Burleigh, Scott C (JPL-312B)[Jet
>> > Propulsion Laboratory]
>> > Cc: stephen.farrell at cs.tcd.ie; Symington, Susan F.; plovell at mac.com
>> > Subject: RE: CCSDS BP Security Trade Status
>> >
>> > Yes, correct.
>> >
>> > Howie
>> >
>> > ________________________________
>> > Howard Weiss
>> > Technical Director
>> >
>> > PARSONS
>> > 7110 Samuel Morse Drive
>> > Columbia, MD 21046
>> > 443-430-8089 (office)
>> > 410-262-1479 (cell)
>> > 443-430-8238 (fax)
>> > howard.weiss at parsons.com
>> > www.parsons.com
>> >
>> > Please consider the environment before printing this message
>> >
>> > ________________________________________
>> > From: Birrane, Edward J. [Edward.Birrane at jhuapl.edu]
>> > Sent: Tuesday, August 25, 2015 10:03 AM
>> > To: Weiss, Howard; Sheehe, Charles J. (GRC-LCA0); Scott, Keith L.;
>> > Mayer, Jeremy P. (JSC-OT/ESA)[EUROPEAN SPACE AGENCY];
>> > sis-dtn-owner at mailman.ccsds.org; Burleigh, Scott C (JPL-312B)[Jet
>> > Propulsion Laboratory]
>> > Cc: stephen.farrell at cs.tcd.ie; Symington, Susan F.; plovell at mac.com
>> > Subject: RE: CCSDS BP Security Trade Status
>> >
>> > "Never in my wildest imagination would I have thought of wrapping
>> > CMS
>> inside of SBSP blocks!"
>> >
>> > I think you mean "extension blocks" as a CMS Block would be an
>> > extension
>> block followed by CMS content. Specifically, a CMS would have no
>> block- data-type-specific fields, it would all be in the CMS
>> "envelope" payload. A CMS block would be a type of SBSP block, not
>> something stuffed inside an SBSP block.
>> >
>> > Putting CMS inside a bundle is less complicated than putting a
>> > bundle inside
>> of CMS, unless you are tunneling - which I thought we understood to
>> be a separate issue.
>> >
>> > -Ed
>> >
>> > ---
>> > Edward J. Birrane, III, Ph.D.
>> > Embedded Applications Group Supervisor Space Exploration Sector
>> > Johns Hopkins Applied Physics Laboratory
>> > (W) 443-778-7423 / (F) 443-228-3839
>> >
>> >
>> >
>> > > -----Original Message-----
>> > > From: Weiss, Howard [mailto:Howard.Weiss at parsons.com]
>> > > Sent: Tuesday, August 25, 2015 9:45 AM
>> > > To: Sheehe, Charles J. (GRC-LCA0); Scott, Keith L.; Mayer, Jeremy P.
>> > > (JSC- OT/ESA)[EUROPEAN SPACE AGENCY];
>> > > sis-dtn-owner at mailman.ccsds.org; Burleigh, Scott C (JPL-312B)[Jet
>> > > Propulsion Laboratory]
>> > > Cc: Birrane, Edward J.; stephen.farrell at cs.tcd.ie; Symington,
>> > > Susan F.; plovell at mac.com
>> > > Subject: RE: CCSDS BP Security Trade Status
>> > >
>> > > Hmmm... Not to burst the euphoria bubble, but I'm getting the
>> > > drift that all of this is making things just that more
>> > > complicated where as my aim was to simplify what had already
>> > > become a very complicated security protocol. My thought was that
>> > > CMS already provided the requisite services, so why not see if it
>> > > met all of the security requirements (which we found out had
>> > > never actually been stated) and if so, then why not use an
>> > > already existing and
>well-used protocol?
>> > > Never in my wildest imagination would I have thought of wrapping
>> > > CMS
>> inside of SBSP blocks!
>> > >
>> > > Howie
>> > >
>> > > ________________________________
>> > > Howard Weiss
>> > > Technical Director
>> > >
>> > > PARSONS
>> > > 7110 Samuel Morse Drive
>> > > Columbia, MD 21046
>> > > 443-430-8089 (office)
>> > > 410-262-1479 (cell)
>> > > 443-430-8238 (fax)
>> > > howard.weiss at parsons.com
>> > > www.parsons.com
>> > >
>> > > Please consider the environment before printing this message
>> > >
>> > > ________________________________________
>> > > From: Sheehe, Charles J. (GRC-LCA0) [charles.j.sheehe at nasa.gov]
>> > > Sent: Monday, August 24, 2015 1:01 PM
>> > > To: Scott, Keith L.; Weiss, Howard; Mayer, Jeremy P. (JSC-
>> > > OT/ESA)[EUROPEAN SPACE AGENCY]; sis-dtn-owner at mailman.ccsds.org;
>> > > Burleigh, Scott C (JPL-312B)[Jet Propulsion Laboratory]
>> > > Cc: Edward.Birrane at jhuapl.edu; stephen.farrell at cs.tcd.ie;
>> > > Symington, Susan F.; plovell at mac.com
>> > > Subject: RE: CCSDS BP Security Trade Status
>> > >
>> > > Hi
>> > > This is what I think you are saying.
>> > > Options:
>> > > **CMS in a payload: No change to DTN BP, No change to SBSP **CMS
>> > > block
>> > > type: Change to SBSP Additional block, CCB: 0x05 **CMS in current
>> blocks:
>> > > BCB? CMS processing flag, change to SBSP
>> > >
>> > > Block-Type Code (Byte) - as described in [RFC5050]. The block-
>> > > type codes for security blocks are:
>> > > . BundleAuthenticationBlock - BAB: 0x02
>> > > . BlockIntegrityBlock - BIB: 0x03
>> > > . BlockConfidentialityBlock - BCB: 0x04
>> > > **. CMSBlock - CCB: 0x05
>> > >
>> > > Each security block uses the Canonical Bundle Block Format as
>> > > defined in [RFC5050]. That is, each security block is comprised
>> > > of the following
>> > > elements:
>> > > . Block-type code
>> > > . Block processing control flags
>> > > . Block EID-reference list (OPTIONAL)
>> > > . Block data length
>> > > . Block-type-specific data fields
>> > > Since the three security blocks have most fields in common, we
>> > > can shorten the description of the Block-type-specific data
>> > > fields of each security block if we first define an abstract
>> > > security block
>> > > (ASB) and then specify each of the real blocks in terms of the
>> > > fields that are present/absent in an ASB. Note that no bundle
>> > > ever contains an actual ASB, which is simply a specification
>>artifact.
>> > >
>> > > Charles J. Sheehe III
>> > > Electronics Engineer
>> > > System Architectures and Networks Branch 21000 Brookpark Rd
>> > > Cleveland, OH 44135 Charles.J.Sheehe at nasa.gov
>> > > Office: 216-433-5179
>> > >
>> > >
>> > > -----Original Message-----
>> > > From: Scott, Keith L. [mailto:kscott at mitre.org]
>> > > Sent: Monday, August 24, 2015 11:45 AM
>> > > To: Weiss, Howard; Sheehe, Charles J. (GRC-LCA0); Mayer, Jeremy P.
>> > > (JSC- OT/ESA)[EUROPEAN SPACE AGENCY];
>> > > sis-dtn-owner at mailman.ccsds.org; Burleigh, Scott C (JPL-312B)[Jet
>> > > Propulsion Laboratory]
>> > > Cc: Edward.Birrane at jhuapl.edu; stephen.farrell at cs.tcd.ie;
>> > > Symington, Susan F.; plovell at mac.com
>> > > Subject: Re: CCSDS BP Security Trade Status
>> > >
>> > > OK, so if we:
>> > >
>> > > 1. Keep the existing BSP framework / structure (security blocks
>> separate
>> > > from targets)
>> > > 2. Use CMS' 'non-envelope' mechanisms for integrity and
>> authentication
>> > > mechanisms
>> > >
>> > > * CMS stuff goes in those separate security blocks,
>leaving the
>> target
>> > > blocks unmodified
>> > >
>> > > 3. Maybe use CMS' envelope structure for encrypted block
>>content
>> where
>> > > reasonable
>> > >
>> > > * Maybe with the envelope identifying the contents and
>the block
>> > > type containing the CMS envelope as 'CMS enveloped block'?
>> > >
>> > > 4. We use come cipher suites within CMS to actually do the
>security
>> stuff
>> > >
>> > > Does that make sense?
>> > >
>> > >
>> > > -keith
>> > >
>> > >
>> > > From: <mailman-bounces at mailman.ccsds.org <mailto:mailman-
>> > > bounces at mailman.ccsds.org> > on behalf of Howie Weiss
>> > > Date: Monday, August 24, 2015 at 11:00 AM
>> > > To: Keith Scott, "Sheehe, Charles J. (GRC-LCA0)", "Mayer, Jeremy P.
>> > > (JSC- OT/ESA)[EUROPEAN SPACE AGENCY]",
>> > > "sis-dtn-owner at mailman.ccsds.org
>> > > <mailto:sis-dtn-owner at mailman.ccsds.org> ", Scott Burleigh
>> > > Cc: "Edward.Birrane at jhuapl.edu <mailto:Edward.Birrane at jhuapl.edu>
>> > > ", Stephen Farrell, Susan Symington, "plovell at mac.com
>> > > <mailto:plovell at mac.com> "
>> > > Subject: RE: CCSDS BP Security Trade Status
>> > >
>> > >
>> > > Keith
>> > >
>> > > I don't understand what you mean by using CMS "essential as a
>> > > cipher suite, not as an encapsulation/envelope mechanism." CMS
>> > > *uses* existing ciphersuites - it defines how data is enveloped
>> > > and then applies the cipher suites.
>> > >
>> > > Howie
>> > >
>> > >
>> > >
>> > >
>> > > ________________________________
>> > >
>> > > Howard Weiss
>> > > Technical Director
>> > >
>> > > PARSONS
>> > > 7110 Samuel Morse Drive
>> > > Columbia, MD 21046
>> > > 443-430-8089 (office)
>> > > 410-262-1479 (cell)
>> > > 443-430-8238 (fax)
>> > > howard.weiss at parsons.com <mailto:howard.weiss at parsons.com>
>> > > www.parsons.com
>> > >
>> > > Please consider the environment before printing this message
>> > >
>> > > ________________________________
>> > >
>> > > From: Scott, Keith L. [kscott at mitre.org <mailto:kscott at mitre.org>
>> > > ]
>> > > Sent: Monday, August 24, 2015 9:33 AM
>> > > To: Sheehe, Charles J. (GRC-LCA0); Mayer, Jeremy P. (JSC-
>> > > OT/ESA)[EUROPEAN SPACE AGENCY]; Weiss, Howard; sis-dtn-
>> > > owner at mailman.ccsds.org <mailto:sis-dtn-owner at mailman.ccsds.org>
>> > > ; Burleigh, Scott C (312B)
>> > > Cc: Edward.Birrane at jhuapl.edu <mailto:Edward.Birrane at jhuapl.edu>
>> > > ; stephen.farrell at cs.tcd.ie <mailto:stephen.farrell at cs.tcd.ie> ;
>> > > Symington, Susan F.; plovell at mac.com <mailto:plovell at mac.com>
>> > > Subject: Re: CCSDS BP Security Trade Status
>> > >
>> > >
>> > > I think what I'm trying to drive towards is something like:
>> > >
>> > > * Leave the overall structure of BSP the same (security blocks
>> separated
>> > > from 'target' blocks)
>> > > * MAYBE designate a 'CMS variant' that uses CMS security info
>>in
>the
>> > > security blocks; this might be a CMS cipher suite.
>> > > * See if we can get a quick read from the IETF on how they
>>plan
>to
>> > > proceed (I.e. If they plan to continue with a BSP-like format or
>> > > if things will change radically)
>> > >
>> > > * Possibly adjust our work to follow suit
>> > >
>> > > Howie: would using CMS in this way (essentially as a cipher
>> > > suite, not as an encapsulation/envelope mechanism for blocks) in
>> > > order to maintain the ability for non-security-aware nodes to
>> > > process the
>>'raw'
>> > > blocks (in the cases of integrity / authentication) seem
>> > > reasonable to
>> you?
>> > >
>> > > The current JSON/HTTP/etc. discussion in the IETF WG certainly
>> > > bears on this, as a complete restructuring of the BP would mean
>> > > that even
>> > > near- compatibility on the security protocol would have little
>> > > benefit (I
>> think).
>> > >
>> > > Then again, CCSDS is baselined off of RFC5050 for now, and we
>> > > need a security mechanism compatible with that (meaning we should
>> > > watch the IETF for now, and inject our requirements / desires
>> > > into their thinking, but we don't have to be compatible with /
>> > > adapt to what they're
>> doing at this point).
>> > >
>> > > -keith
>> > >
>> > >
>> > > On 8/24/15, 9:23 AM, "Sheehe, Charles J. (GRC-LCA0)"
>> > > <charles.j.sheehe at nasa.gov <mailto:charles.j.sheehe at nasa.gov> >
>> wrote:
>> > >
>> > >
>> > > Hi
>> > > I just wish to be very clear.
>> > > I think you are saying:
>> > > CMS will have payload block designated by a flag.
>> > > SBSP will continue as is.
>> > >
>> > > I just want to make sure we are all on the same page.
>> > >
>> > > Chuck
>> > >
>> > > Charles J. Sheehe III
>> > > Electronics Engineer
>> > > System Architectures and Networks Branch
>> > > 21000 Brookpark Rd
>> > > Cleveland, OH 44135
>> > > Charles.J.Sheehe at nasa.gov <mailto:Charles.J.Sheehe at nasa.gov>
>> > > Office: 216-433-5179
>> > >
>> > >
>> > > -----Original Message-----
>> > > From: Jeremy.Mayer at dlr.de <mailto:Jeremy.Mayer at dlr.de>
>> > > [mailto:Jeremy.Mayer at dlr.de]
>> > > Sent: Friday, August 21, 2015 1:53 PM
>> > > To: kscott at mitre.org <mailto:kscott at mitre.org> ;
>> > > Howard.Weiss at parsons.com <mailto:Howard.Weiss at parsons.com> ;
>> Sheehe,
>> > > Charles J. (GRC-LCA0); sis-dtn-owner at mailman.ccsds.org
>> > > <mailto:sis-dtn-owner at mailman.ccsds.org>
>> > > Cc: Edward.Birrane at jhuapl.edu
>> > > <mailto:Edward.Birrane at jhuapl.edu> ; stephen.farrell at cs.tcd.ie
>> > > <mailto:stephen.farrell at cs.tcd.ie> ; susan at mitre.org
>> > > <mailto:susan at mitre.org> ; plovell at mac.com
>> <mailto:plovell at mac.com>
>> > > Subject: RE: CCSDS BP Security Trade Status
>> > >
>> > > Sorry for the silence here as well,
>> > >
>> > > CMS can do out-of-band signing, where the envelope
>> > > contains a reference to the block which has been signed (as
>> > > MIME), and exclusively contains the signing parameters. Any
>> > > operation which doesn't inherently modify the content
>> > > (compression and encryption, for
>> > > example) could be handled this way, although it would take some
>> adaptation.
>> > >
>> > > I would propose that CMS can settle in one of two places,
>> > > either a new CMS block or in the payload block. For the CMS
>> > > block, all CMS operations would reference other blocks, and for
>> > > the payload block it would be all- encompassing, with data stored
>> > > within the CMS
>> envelope or other blocks.
>> > > The second method is for BIBE-like systems, where the block
>> > > payload is signed, encrypted, compressed, etc at the transmitter.
>> > > There is also no reason (besides sanity) to say that you couldn't
>> > > have both, a CMS block signing the primary block, and a CMS "blob"
>> > > in the payload, which contains compressed data. I am also still
>> > > of the opinion that there is a place for both systems, SBSP in
>> > > super-bandwidth-constrained applications and CMS in other places.
>> > > Once
>> again, sanity is the question.
>> > >
>> > > Thanks,
>> > > Jeremy
>> > >
>> > >
>> > >
>> > > ________________________________
>> > >
>> > > From: Scott, Keith L. [kscott at mitre.org
><mailto:kscott at mitre.org> ]
>> > > Sent: Friday, August 21, 2015 7:13 PM
>> > > To: Weiss, Howard; Sheehe, Charles J. (GRC-LCA0);
>> > > sis-dtn- owner at mailman.ccsds.org <mailto:sis-dtn-owner at mailman.ccsds.org>
>> > > Cc: Edward Birrane; Stephen Farrell; Symington, Susan F.;
>> > > Mayer, Jeremy; Peter Lovell
>> > > Subject: Re: CCSDS BP Security Trade Status
>> > >
>> > >
>> > > OK, so if CMS can provide a useful set of
>> > > non-encapsulation services (including signing, encryption,
>> > > authentication) WITHOUT being an envelope (in order to support
>> > > the notion of incremental deployment), then I think it's a valid
>candidate.
>> > >
>> > > The 'maintain the current architecture' was a reference
>> > > to the way the BSP is structured now, with the security blocks
>> > > separate from
>> their targets.
>> > > Again, if CMS can do that then cool, we would just need to figure
>> > > out the right way to put the CMS bits into the right kinds of
>> > > blocks, point those at their targets, etc. (sort of the way that
>> > > BSP does
>> now).
>> > >
>> > > I think (now, given Ed's advocation for the possibility
>> > > of incremental
>> > > deployment) that I'm opposed to an 'all-encapsulation' approach.
>> > >
>> > > I'm also very interested in keeping CCSDS and the IETF WG
>> > > in sync, so if CCSDS thinks that CMS is a good possible approach,
>> > > I'd like to try to argue that to the IETF.
>> > >
>> > > -keith
>> > >
>> > >
>> > > From: Howie Weiss
>> > > Date: Friday, August 21, 2015 at 1:04 PM
>> > > To: Keith Scott, "Sheehe, Charles J. (GRC-LCA0)",
>> > > "sis-dtn- owner at mailman.ccsds.org
>> > > <mailto:sis-dtn-owner at mailman.ccsds.org>
>> > > <mailto:sis-dtn-owner at mailman.ccsds.org> "
>> > > Cc: Edward Birrane, Stephen Farrell, Susan Symington,
>> > > Jeremy
>> > > Pierce- Mayer, "plovell at mac.com <mailto:plovell at mac.com>
>> > > <mailto:plovell at mac.com> "
>> > > Subject: RE: CCSDS BP Security Trade Status
>> > >
>> > >
>> > >
>> > > Keith
>> > >
>> > >
>> > > Sorry for the radio silence on this end....
>> > >
>> > >
>> > > I guess I don't understand what you mean when you say
>> > > that "CMS is sort of a red herring."
>> > >
>> > >
>> > > My suggestion at the last CCSDS meeting was to look at
>> > > CMS as a means to use an already existing security protocol with
>> > > wide deployment (and well
>> > > understood) as a means of not reinventing the wheel with another
>> > > security protocol. Personally, I'd rather adopt and adapt than
>> > > spend the time & resources to reinvent.
>> > >
>> > >
>> > > CMS provides both encapsulation and non-encapsulation
>> > > services. It supports "signed-data," "enveloped-data,"
>> > > "digested-data," encrypted- data," and "authenticated-data"
>> > > content types. This allows the user/implementer the freedom to
>> > > select the security services needed. As its use with S/MIME, one
>> > > can sign an email but leave the contents visible (as in your
>> > > scenario with a non-security aware router being able to do
>> > > something with the bundle), or it can obscure the contents so
>> > > only the recipient who can authenticate the signature can see it.
>> > > Just think of all of the ways in which S/MIME email traverses the
>> > > network today and the wide
>> variety of its uses.
>> > >
>> > >
>> > > I'm also not sure what you mean by "if we do want to
>> > > maintain the current architecture, what would CMS bring to the
>> > > table?" The current bundle architecture is not affected by the
>> > > use of CMS - just as its not (supposed to be ) affected by the
>> > > use of BSP. CMS would replace BSP. As I said previously, its
>> > > various content types would be used to provide the same security
>> > > functionality but using an already existing (and illustrated by
>> > > Jeremy's
>> testing) easily adaptable to the bundle protocol.
>> > >
>> > >
>> > > Regards
>> > >
>> > >
>> > > howie
>> > >
>> > >
>> > > From: Scott, Keith L. [mailto:kscott at mitre.org]
>> > > Sent: Monday, August 17, 2015 10:21 AM
>> > > To: Sheehe, Charles J. (GRC-LCA0);
>> > > sis-dtn-owner at mailman.ccsds.org
>> > > <mailto:sis-dtn-owner at mailman.ccsds.org> <mailto:sis-dtn-
>> owner at mailman.ccsds.org>
>> > > Cc: Edward Birrane; Weiss, Howard; Stephen Farrell;
>> > > Symington, Susan F.; Peter Lovell; Jeremy Pierce-Mayer
>> > > Subject: CCSDS BP Security Trade Status
>> > >
>> > >
>> > > Sorry for the radio silence and thanks to Chuck for
>> > > kicking the
>> flywheel!
>> > >
>> > >
>> > > I think the thing I'm looking for is what the overall
>> > > structure of the bundle security protocol should be. CMS is sort
>> > > of a red herring in that respect, as I think (and Ed's working on
>> > > clarifying this as part of the IETF work) that the main issue
>> > > deals with whether the security protocol can 'eat' a bundle block
>> > > (essentially replacing its contents with a security block type
>> > > that
>> encapsulates the protected block).
>> > >
>> > >
>> > > At first glance, having the security capabilities 'eat'
>> > > the blocks they target seems like the easy way to go (IPSec
>> > > Tunnel
>> > > Mode) but it has some implications w.r.t. the actual bundle
>> > > protocol (that says things like: there WILL be a payload block)
>> > > and, and I think this is the most important bit, with incremental
>deployment of security.
>> > >
>> > >
>> > > Say I have an immutable block that is protected by
>> > > integrity (not
>> > > confidentiality) and the bundle containing that block passes
>> > > through a node that doesn't implement security but wants to do
>> > > something based on that block's contents. If the security is
>> > > applied the way the current BSP does (the security block is
>> > > separate from the target
>> > > block) then the non-security-aware bundle agent can read the
>> > > block, do whatever it needs to, and forward the bundle (without
>> > > checking the integrity, which it can't do because we assumed it
>> > > was non-security-aware). The non-security-aware bundle agent
>> > > could not do this if the integrity block replaced (ate, consumed)
>> > > the block for which it was providing integrity. If there are
>> > > other motivators similar to the above, possibly produced as part
>> > > of the original BSP spec but not included in the RFC or in the
>> > > rational for the IETF BSP work,
>> I'd be very interested in our considering them.
>> > >
>> > >
>> > > With that, the questions seem to be:
>> > >
>> > > 1. Does CCSDS really need incremental deployment or could
>> > > we get away with assuming homogeneity of deployment and use
>> > > security blocks that consume their targets?
>> > > 2. What are the implications to the base protocol of
>> > > having security encapsulate the target block(s)?
>> > > 3. What are the implications w.r.t. interoperability with
>> > > the emerging wider terrestrial infrastructure that looks like it
>> > > DOES need to support incremental deployment?
>> > >
>> > > *By going our own way, what do we lose in terms of
>> > > interoperability / ability to leverage (hopefully) commercial
>> implementations?
>> > >
>> > > 4. If we DO want to maintain the current architecture,
>> > > what would CMS bring to the table? Could we use it as a cipher
>> > > suite, e.g.? Would that make sense?
>> > >
>> > >
>> > >
>> > > -keith
>> > >
>> > >
>> > > From: "Sheehe, Charles J. (GRC-LCA0)"
>> > > Date: Monday, August 17, 2015 at 8:27 AM
>> > > To: Keith Scott
>> > > Subject: DTN
>> > >
>> > >
>> > > Hi
>> > >
>> > >
>> > > I sent an e-mail to you while you were on vacation.
>> > >
>> > > I was unable to attend the second DTN/Security telecon.
>> > >
>> > > Were there any notes that I should be aware of?
>> > >
>> > > Was there a direction set?
>> > >
>> > >
>> > > Is there still be a trade performed, what are the metrics
>> > > the group agreed to.
>> > >
>> > >
>> > > Thanks
>> > >
>> > > Chuck
>> > >
>> > >
>> > >
>> > > Charles J. Sheehe III
>> > >
>> > > Electronics Engineer
>> > >
>> > > System Architectures and Networks Branch
>> > >
>> > > 21000 Brookpark Rd
>> > >
>> > > Cleveland, OH 44135
>> > >
>> > > Charles.J.Sheehe at nasa.gov
>> > > <mailto:Charles.J.Sheehe at nasa.gov>
>> > > <mailto:Charles.J.Sheehe at nasa.gov>
>> > >
>> > > Office: 216-433-5179
>> > >
>> > >
>> > >
>> > >
>> >
>> >
>
>
More information about the SIS-DTN
mailing list