<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; font-family: Calibri, sans-serif; font-size: 14px; color: rgb(0, 0, 0);">
<div>
<div>Charles,</div>
<div><br>
</div>
<div>I think this is a good start, but we’re going to have to define the requirements ourselves (in concert with the Security WG) rather than look for an existing punch-list. I don’t propose to do an entire CCSDS Book to codify these set if we can come to
a consensus within the WG (and in conjunction with the security WG) as to what they are. I think Scott’s and Kiyo’s responses are a good start towards tightening up the requirements list, then we can ask which of the methods we know of or could invent can
meet those requirements. Then we write the book.</div>
<div><br>
</div>
<div>I think we can take as a starting point the documents from the Security WG:</div>
<div>
<div id="">
<div>
<div><br>
</div>
<div><a href="http://public.ccsds.org/publications/archive/350x0g2.pdf">The Application of CCSDS Protocols to Secure Systems. Green Book</a>. Issue 2. January 2006.</div>
</div>
<ul>
<li>[Section 4] I think we want Confidentiality, Authentication, and Integrity of some portions of bundles (e.g. Payload, information needed to route, etc.)</li><li>[Section 5] I think we’re talking about Network-Layer security (Bundle-layer)</li></ul>
</div>
</div>
</div>
<div>
<div><br>
</div>
<div><a href="http://public.ccsds.org/publications/archive/350x1g1.pdf">Security Threats against Space Missions. Green Book</a>. Issue 1. October 2006.</div>
</div>
<ul>
<li>Section 3 runs down some common threats, some of which I think we should defend against in the CCSDS Bundle Security Protocol.
<ul>
<li>I think the ability to apply Confidentiality, Authentication, and Integrity to the ‘right parts’ of bundles should address all that we need, but we should look.</li></ul>
</li></ul>
<div>
<div>There are some other 350-series documents, but I think the above ones are the most relevant w.r.t. Our figuring out what the CBSP needs to implement.</div>
</div>
<div><br>
</div>
<div><br>
</div>
<div><span class="Apple-tab-span" style="white-space:pre"></span>—keith</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div>On 6/22/15, 8:53 AM, "Sheehe, Charles J. (GRC-LCA0)" <<a href="mailto:charles.j.sheehe@nasa.gov">charles.j.sheehe@nasa.gov</a>> wrote:</div>
<div><br>
</div>
<blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;">
<div>Thanks Scott for replying.</div>
<div><br>
</div>
<div>The list is from a spread sheet which was intended to do an A vs. B comparison in order to determine the what services are most important to the community.</div>
<div><br>
</div>
<div>Since you said basically all the services are needed do you have reference documentation from CCSDS or the IOAG that requires them? I have looked and I have been unable to find security requirements for DTN except putting together the IOAG SSI document
would require some kind IP compatible information payload security service.</div>
<div><br>
</div>
<div>I have not found an operational concept document, an approved architecture, the CCSDS requirements document I did find, did not address security of the network or the security of the payload. I did not find a threat and vulnerability assessment of the
current DTN systems from which to work. I have attached simple views of what I think the systems look like in reference to the world. They are not like the draft Mission Operations Configurations.</div>
<div><br>
</div>
<div>So if you know of definitive documentation that addresses security requirements of the CCSDS DTN networks or the information passing through them, would you share them with me please. (I have a security clearance and receipt of the information can be handled
via my center's security office if this is an issue)</div>
<div><br>
</div>
<div>I work from Needs Goals and Objectives, then put in constraints thus formulating requirements that need to be complied with.</div>
<div>It is a different way of looking at things and to most it seems a waste of time. In very complex activities figuring out the must haves, should haves and like to have has a way of clarifying the activity.</div>
<div><br>
</div>
<div>I try never to interject my views on how something should be done, I stick to agreed processes so the answer at the end is accepted.</div>
<div><br>
</div>
<div>Thanks</div>
<div>Chuck </div>
<div><br>
</div>
<div>Charles J. Sheehe III</div>
<div>Electronics Engineer</div>
<div>System Architectures and Networks Branch</div>
<div>21000 Brookpark Rd</div>
<div>Cleveland, OH 44135</div>
<div><a href="mailto:Charles.J.Sheehe@nasa.gov">Charles.J.Sheehe@nasa.gov</a></div>
<div>Office: 216-433-5179</div>
<div><br>
</div>
<div><br>
</div>
<div>-----Original Message-----</div>
<div>From: Burleigh, Scott C (312B) [<a href="mailto:scott.c.burleigh@jpl.nasa.gov">mailto:scott.c.burleigh@jpl.nasa.gov</a>]
</div>
<div>Sent: Friday, June 19, 2015 12:58 PM</div>
<div>To: Scott, Keith L (9730-Affiliate); <a href="mailto:'sis-dtn@mailman.ccsds.org">
'sis-dtn@mailman.ccsds.org</a>'</div>
<div>Cc: Sheehe, Charles J. (GRC-LCA0); Howie Weiss (<a href="mailto:howard.weiss@sparta.com">howard.weiss@sparta.com</a>)</div>
<div>Subject: RE: Securing the CCSDDS Bundle Protocol</div>
<div><br>
</div>
<div>Hi, Keith. My comments in-line below.</div>
<div><br>
</div>
<div></div>
<div><br>
</div>
<div>Scott</div>
<div><br>
</div>
<div></div>
<div><br>
</div>
<div>From: <a href="mailto:sis-dtn-bounces@mailman.ccsds.org">sis-dtn-bounces@mailman.ccsds.org</a> [<a href="mailto:sis-dtn-bounces@mailman.ccsds.org">mailto:sis-dtn-bounces@mailman.ccsds.org</a>] On Behalf Of Scott, Keith L.</div>
<div>Sent: Wednesday, June 17, 2015 9:26 AM</div>
<div>To: <a href="mailto:'sis-dtn@mailman.ccsds.org">'sis-dtn@mailman.ccsds.org</a>'</div>
<div>Cc: Sheehe, Charles J. (GRC-LCA0); Howie Weiss (<a href="mailto:howard.weiss@sparta.com">howard.weiss@sparta.com</a>)</div>
<div>Subject: [Sis-dtn] Securing the CCSDDS Bundle Protocol</div>
<div><br>
</div>
<div></div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div></div>
<div><br>
</div>
<div>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'.</div>
<div><br>
</div>
<div></div>
<div><br>
</div>
<div>* Protocol can distinguish between Sender of bundle and the Security-Sender</div>
<div><br>
</div>
<div>* 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.</div>
<div><br>
</div>
<div>* Protocol provides security services which are; hop-by-hop basis</div>
<div><br>
</div>
<div>* Needed to choke off DOS attacks.</div>
<div><br>
</div>
<div>* Protocol provides security services which are; end-to-end basis</div>
<div><br>
</div>
<div>* Needed, except note that the sending "end" might be a Security-Sender rather than the original source of the bundle.</div>
<div><br>
</div>
<div>* Protocol provides security services which are hop-by-hop basis and End-to-end basis</div>
<div><br>
</div>
<div>* I think this is covered by the preceding three bullets. </div>
<div><br>
</div>
<div>* Protocol mechanisms secure information at rest</div>
<div><br>
</div>
<div>* Mandatory. Otherwise forwarding along a multi-agency path may be impossible.</div>
<div><br>
</div>
<div>* Protocol provides a means to encrypt protocol elements so that messages in transit cannot practically be read</div>
<div><br>
</div>
<div>* Needed.</div>
<div><br>
</div>
<div>* Protocol supports pre-shared-keys (and/or known irrevocable certificates).</div>
<div><br>
</div>
<div>* Needed.</div>
<div><br>
</div>
<div>* 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.</div>
<div><br>
</div>
<div>* I think what is needed is a means of integrity-checking any block(s) of a bundle, not the bundle as a whole.</div>
<div><br>
</div>
<div>* Protocol allows combination of confidentiality and integrity services</div>
<div><br>
</div>
<div>* Both confidentiality and integrity services may be needed for any single bundle. Is that what this means?</div>
<div><br>
</div>
<div>* Protocol prevents changing the intended destination</div>
<div><br>
</div>
<div>* Needed.</div>
<div><br>
</div>
<div>* Protocol prevents falsifying a bundle's source</div>
<div><br>
</div>
<div>* Needed.</div>
<div><br>
</div>
<div>* Protocol prevents changing a bundle's control fields</div>
<div><br>
</div>
<div>* In general, the protocol needs to prevent changing anything in the primary block.</div>
<div><br>
</div>
<div>* Protocol prevents changing other block or payload fields</div>
<div><br>
</div>
<div>* Needed.</div>
<div><br>
</div>
<div>* Protocol prevents replay of bundles</div>
<div><br>
</div>
<div>* Not needed. Bundles have IDs, and duplicate arrival of bundles is already possible. Applications need to provide their own application-specific safeguards here.</div>
<div><br>
</div>
<div>* Protocol prevents copying or disclosing bundle data as it passes</div>
<div><br>
</div>
<div>* Not needed. If encryption is supported then this is moot.</div>
<div><br>
</div>
<div>* Protocol is a Standard</div>
<div><br>
</div>
<div>* If not already a standard, the protocol must have strong prospects of becoming a standard.</div>
<div><br>
</div>
<div>* Protocol has implementations</div>
<div><br>
</div>
<div>* If not already implemented, implementation of the protocol must be affordable.</div>
<div><br>
</div>
<div></div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div></div>
<div><br>
</div>
<div> --keith</div>
<div><br>
</div>
<div></div>
<div><br>
</div>
<div><br>
</div>
</blockquote>
</body>
</html>